На неделе пытался (разумеется, безуспешно) собрать свою версию bluez5. Собрать-то собрал, да никакого осмысленного эффекта старый пульсаудио с новым блюзом не дают
( Read more... )
> Если же мы переходим в массовый режим, где сервера многочисленны и безлики, плюс добавляем к этому виртуализацию (где provision ещё сервера - это десятки секунд времени), то ситуация сильно меняется. > Есть ли в этой ситуации необходимость в длительном комфортном сосуществовании? Нет.
Не обязательно. Если это продакт, то эти машины должны максимально долго комфортно жить.
А следовательно, в тесте и стресс-тестовых окружениях эти же машины должны быть так же приготовлены, как на продакте. (грош цена тестированию, проведенному с отличающимся окружением). То есть в итоге все виртуалки все равно должны быть готовы к "длительном комфортном сосуществовании".
> по каким-то важным причинам сервер надо капитально переделать - никто не будет это делать "на живую".
Если это "дешевле" полного редеплоя (по вермени, ресурсам, деньгам) - будут делать.
> Развёртывание сервера очень быстрое.
Зависит от. Скажем развертывание компонент на базе win2003 может занимать час и более. Да, параллелится, но не более десятка-другого копий.
ITIL сдох. Примерно как ЕСКД, СКС и X.400. Да, там есть хорошые практики (дажэ в ЕСКД они есть) -- но по факту оно почему-то невзлетело, и, скорее всего, требует выкинуть наработки и придумать что-то другое.
>Более того, если выясняется, что по каким-то важным причинам сервер надо капитально переделать - никто не будет это делать "на живую".
Это в меньшей степени применимо к БД. Т.е., если есть stateless сервер приложения - его можно (почти) безболезненно погасить/переподнять. Но как только появляется состояние, которое хранится на сервере, надо уже думать о том, как сервер будет жить. Репликация данных от этого полностью не спасает (да и не может, в общем-то).
По большому счету не важно, что за помойка на сервере, процедура подготовки образа оси и установки компонент автоматизируется всякими чиф/папет/свой вариант и работает. Важно сколько серверов и сколько времени занимает такой редеплой.
Comments 58
emerge --depclean --exclude sys-kernel/gentoo-sources
revdep-rebuild
Reply
> Есть ли в этой ситуации необходимость в длительном комфортном сосуществовании? Нет.
Не обязательно. Если это продакт, то эти машины должны максимально долго комфортно жить.
А следовательно, в тесте и стресс-тестовых окружениях эти же машины должны быть так же приготовлены, как на продакте. (грош цена тестированию, проведенному с отличающимся окружением). То есть в итоге все виртуалки все равно должны быть готовы к "длительном комфортном сосуществовании".
> по каким-то важным причинам сервер надо капитально переделать - никто не будет это делать "на живую".
Если это "дешевле" полного редеплоя (по вермени, ресурсам, деньгам) - будут делать.
> Развёртывание сервера очень быстрое.
Зависит от. Скажем развертывание компонент на базе win2003 может занимать час и более. Да, параллелится, но не более десятка-другого копий.
Reply
В энторнетах проще задеплоить с нуля параллельно, протестировать и переключить балансер.
Reply
У нас в продакшене тысячи виртуалок, задолбаешься передеплаивать по каждому чиху то, что можно пробежать скриптом и обновить.
Reply
Reply
(The comment has been removed)
Да, там есть хорошые практики (дажэ в ЕСКД они есть) -- но по факту оно почему-то невзлетело, и, скорее всего, требует выкинуть наработки и придумать что-то другое.
Reply
(The comment has been removed)
Reply
Это в меньшей степени применимо к БД. Т.е., если есть stateless сервер приложения - его можно (почти) безболезненно погасить/переподнять. Но как только появляется состояние, которое хранится на сервере, надо уже думать о том, как сервер будет жить. Репликация данных от этого полностью не спасает (да и не может, в общем-то).
Reply
Reply
Важно сколько серверов и сколько времени занимает такой редеплой.
Reply
Reply
Reply
Leave a comment