Исходное сообщение
"CentOS Stream станет единственным публичным источником кода ..." Отправлено Neandertalets, 22-Июн-23 16:59
> Сам тоже нисколько не претендую на звание соляровода. > Но вот проклятий от настоящих соляроводов наслушался изрядно. > Возможно Ваш коллега занимался той областью, где на подводные камни он не > натыкался. > В любом случае, что-то сказать об опыте незнакомого мне человека, который занимался > тем, в чём я специалистом не являюсь - я не способен.    Коллега работал и в техподдержке, когда для замены проца/памяти мотался по миру с железом. И, собственно, это его впечатлило больше всего: когда на нагруженном серьёзном сервере даёт команду на отключение девайся, заменяет его, включает снова и всё совершенно без перерыва в работе сервера и приклада. >> И не всё и не всегда решается виртуализацией. Если у вас серьёзный кластер СУБД >> (на пару сотен ТБ и высоконагруженный), например, то виртуализация тут противопоказана. > Не скажите. > Тут ещё очень сильно зависит от того, в каком режим работает такой > гипотетический кластер. > Даже в телекоме и банках никто не будет требовать чтобы вся эта > пара сотен кластеризованных ТБ находились в одинаковом классе доступности. То есть > для горячего доступа всегда будет нужна гораздо меньшая часть данных.    Вы, вероятно, мало общались с ДБА и разработчиками СУБД. А мне приходилось участвовать в проектах федерального уровня, где 250 ТБ базы - это не самые большие. Средненькие. И - очень даже высоконагруженные. И там всё четко: на разных массивах (RAID) разные секции БД (тейблспейсы, базы и даже очень большие отдельные таблицы), кешы и прочее и прочее. Требования и рекомендации спецов ПостгресПро были однозначные: надо выносить на железо, тогда можно правильно оптимизировать. И стало гора-аздо лучше, чем с "рекомендациями лучших собаководов от виртуализации" при тех же ресурсах. Доверять своим ДБА и спецам ПП я уже привык и ни разу это не подводило. А вот рекомендатели "да мы тут всё навиртуализируем" уже не раз садились в лужу. > Это Вы просто, наверное, не интересуетесь, что там сейчас в мире k8s происходит со всякими > cloud-native db. Пройдет ещё совсем немного времени, и это, скорее всего, будет доступно даже > тем, кто и подумать об этом не мог.    Я сторонник подхода, когда statefull приложения не должны быть в куберах и контейнерах вообще. за исключением, например, какого-нибудь редиса, который только как кэш работает.    Вообще считаю, что пихать всё подряд "в кубеня" - очень плохой подход. Хотя сейчас это "стильно, модно, молодёжно".

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	>> Сам тоже нисколько не претендую на звание соляровода. >> Но вот проклятий от настоящих соляроводов наслушался изрядно. >> Возможно Ваш коллега занимался той областью, где на подводные камни он не >> натыкался. >> В любом случае, что-то сказать об опыте незнакомого мне человека, который занимался >> тем, в чём я специалистом не являюсь - я не способен. > Коллега работал и в техподдержке, когда для замены проца/памяти > мотался по миру с железом. И, собственно, это его впечатлило больше > всего: когда на нагруженном серьёзном сервере даёт команду на отключение девайся, > заменяет его, включает снова и всё совершенно без перерыва в работе > сервера и приклада. >>> И не всё и не всегда решается виртуализацией. Если у вас серьёзный кластер СУБД >>> (на пару сотен ТБ и высоконагруженный), например, то виртуализация тут противопоказана. >> Не скажите. >> Тут ещё очень сильно зависит от того, в каком режим работает такой >> гипотетический кластер. >> Даже в телекоме и банках никто не будет требовать чтобы вся эта >> пара сотен кластеризованных ТБ находились в одинаковом классе доступности. То есть >> для горячего доступа всегда будет нужна гораздо меньшая часть данных. > Вы, вероятно, мало общались с ДБА и разработчиками СУБД. > А мне приходилось участвовать в проектах федерального уровня, где 250 ТБ > базы - это не самые большие. Средненькие. И - очень даже > высоконагруженные. И там всё четко: на разных массивах (RAID) разные секции > БД (тейблспейсы, базы и даже очень большие отдельные таблицы), кешы и > прочее и прочее. Требования и рекомендации спецов ПостгресПро были однозначные: надо > выносить на железо, тогда можно правильно оптимизировать. И стало гора-аздо лучше, > чем с "рекомендациями лучших собаководов от виртуализации" при тех же ресурсах. > Доверять своим ДБА и спецам ПП я уже привык и ни > разу это не подводило. А вот рекомендатели "да мы тут всё > навиртуализируем" уже не раз садились в лужу. >> Это Вы просто, наверное, не интересуетесь, что там сейчас в мире k8s происходит со всякими >> cloud-native db. Пройдет ещё совсем немного времени, и это, скорее всего, будет доступно даже >> тем, кто и подумать об этом не мог. > Я сторонник подхода, когда statefull приложения не должны быть > в куберах и контейнерах вообще. за исключением, например, какого-нибудь редиса, который > только как кэш работает. > Вообще считаю, что пихать всё подряд "в кубеня" - > очень плохой подход. Хотя сейчас это "стильно, модно, молодёжно".
	Введите код, изображенный на картинке: