обновление Production серверов

Хм. Если нет доступа, нет KVM, нельзя останавливать и нет дублирующих систем способных принять на себя нагрузку на время профилактики...

Тогда мы ее перепроектируем.

Удваиваю.

есть проект который не позволяет простоя в работе

Нет физического доступа, нет KVM. Это не продакшн, это facepalm.sh

Как делаете это Вы?

Легко.
apt-get update && apt-get dist-upgrade -u && apt-get autoremove && apt-get clean
yum clean all && yum update
zypper clean && zypper up

Если возникают проблемы - ССЗБ.

Интересует вопрос как правильно и безболезненно обновлять production сервера, Если есть проект который не позволяет простоя в работе?

Если проект не позволяет ВООБЩЕ простоя, он нормальными людьми помещается на кластер из 2+ машин. Лично сам видел какой-то хитрожопый сайтик, который и ресурсов то мало жрал, но был сильно важен, так он работал на кластере из нескольких амазоновых виртуалок. Если сервер один - херня это, а не «непозволяющий простоев проект».

Как правильно обновлять ядро и всю систему, если нету физического доступа к серверам и нет KVM?

Захожу по SSH и обновляю, перезагружаю. Только читаю перед этим, не будет ли каких проблем.

Сильно зависит от инфраструктуры.
А так да, все верно говорят: важные вещи должны дублироваться, кластеризоваться, виртуализоваться и тд, чтобы было удобно поднимать быстро резервные копии сервисов.

«production сервера» должны обновлять «production админы», а не школота, задающая туппые вопросы на ЛОРе.

Всегда надо иметь актуальную копию продакшн сервера.

Вот для апдейтов у меня есть копия продакшна. Сначала устанавливаю апдейты на него, потом на продакшн. Уходит в 2 раза больше времени, но не возникают сюрпризы.
Правда с редхатами сюрпризов вообще нет, но привычка осталась =).
Интересно твоё и true_admina мнение услышать. Может расскажите как у вас ?

как у вас ?

у меня один проект бесплатный хостится, я сначала на него апдейты выкатываю :).

А на самом большом проекте что я учавствовал всё делалось на горячую, увы. И там 99% проблем было отнють не из-за апдейтов серверного ПО, а из-за программистов и проблем с железом.

с редхатами сюрпризов вообще нет

тиха украинская ночь, но сало лучше перепрятать :)

Нет доступа нет знаю что жто очень плохо. Конечно если очень захотеть то можно получить доступ в ДЦ, но через это очень геморно. Дублирование есть , 1 сервер из 3 я могу спокойно отклбчить и обновить но вот с 2 другими проблема, так как на них смотрят A записи. А на горячую как то уж совсем нет желания апдейтится!

Копию продакшена очень хорошо держать, но не все готовы тратиться на это, а руководству не объяснишь... оно упертое!

Копия сервака + DNS балансировка. Но, конечно, периодически приходится и наживую обновлять, с перезагрузками, хрустом, криками и кровищей.

тиха украинская ночь, но сало лучше перепрятать :)

именно поэтому

но привычка осталась

=)

IPS + ZFS

Кстати, из последнего опыта. Поднял новый инстанс на Амазоне. Посмотрел как работает свежачок. Остановил старый инстанс, а EBS подключил к новому, уже поднятому, и смонтировал.

Время простоя минимизировано, старый инстанс жив, на случай внезапной задницы. Снапшоты тоже имеются.

А вообще сложно бывает в реальных проектах полностью исключить точки отказа. Профилактика должна быть частью процедуры эксплуатации.

На другом проекте у меня горизонтальный шардинг данных по дискам. И если я EBS снимаю, или ФС размонтирую... В проге есть конфиг в реальном времени. Ставлю suspend на сегмент данных. Она завершает транзакцию, а следующую начинает с учетом отсутствия сегмента. Тут надо при разработке плотно поработать прогеру с админом, и тогда начальство даже не заметит.

по сети можно бэкапить