Назад | Перейти на главную страницу

Удаленное обновление Ubuntu: как минимизировать риск потери сервера?

Задний план: Я вынужден удаленно обновить сервер с Ubuntu 8.04 LTS до 10.04 LTS из-за проблемы несовместимости с рейд-контроллером.

Интернет-соединение с сервером стабильно и редко прерывается. Несмотря на это, я обеспокоен потерей соединения по SSH во время обновления, оставив сервер в недоступном состоянии. Меня также беспокоит, что сервер не сможет загрузиться после обновления, на случай, если я не смогу узнать, в чем проблема.

План действий: Я ищу совета свести к минимуму риск потери сервера, я понимаю, что делаю очень рискованно. Это мой текущий план действий:

1) Резервное копирование всего, что имеет значение, локально и внешне.

2) Временно отключите проверку загрузочного диска с помощью fsck. (Я понятия не имею, что происходит, если проверка диска займет много времени). Это можно сделать с помощью fstab, изменив самый последний параметр с 1 на 0:

UUID=5b1ff964-7608-44fd-a38d-7e43ad6b4c11 /               ext3    relatime,errors=remount-ro 0       0

3) Запуск всех процессов обновления с помощью экрана, чтобы их можно было возобновить, если я потеряю соединение. Т.е.:

sudo screen apt-get upgrade

Вопросы:


Обновление: почти все ответы предлагали мне настроить DRAC / IPMI, что я уже сделал. Похоже, это действительно большое достижение, которое наверняка значительно снизит риск, поскольку я могу следить за всем циклом включения питания через перенаправление KVM / консоли. Для будущих справок вот что я сделал:

1) Установлен ipmitool для настройки IP-адреса, шлюза и т.д. для IPMI v2.0:

sudo ipmitool lan set 1 ipaddr 192.168.1.99 
sudo ipmitool lan set 1 defgw ipaddr 192.168.1.1

2) Установил free-ipmi для смены режима выбора NIC на общий (у меня к сети подключен только один сетевой интерфейс):

sudo ipmi-oem dell set-nic-selection shared 

3) Использовал https-интерфейс DRAC на https://192.168.1.99 для запуска программы просмотра перенаправления консоли. Это позволяет мне следить за всей последовательностью загрузки, а также настраивать BIOS, RAID-контроллеры и т. Д. Замечательно.


Обновление 2. Готово. Все прошло замечательно, на работу ушло менее 30 минут. В итоге я не отключил проверку диска, поскольку перенаправленная консоль давала мне возможность прерывать ее, когда я хотел, но я позволил ей работать до конца.

Спасибо вам, ребята, ваша мудрость неоценима!

Лично, в зависимости от того, насколько важен этот сервер для вашего (вашего бизнеса и т. Д.), Я бы взял в руки аналогичную систему и попытался воспроизвести среду, а затем обновить ее через SSH прямо в комнате (или физически доступной для вас. ), чтобы вы могли протестировать свою процедуру. Если вы можете обновить его, не теряя конфигурации / соединения, у вас есть довольно хорошие шансы обновить удаленный сервер.

Это не будет на 100% точным, но, по крайней мере, должно устранить ошибки, вызванные обновлениями программного обеспечения, конфигурацией программного обеспечения, изменениями и т. П., Если вы можете настроить тестовую систему как можно ближе к вашему удаленному серверу.

РЕДАКТИРОВАТЬ: Другое решение - сначала создать второй сервер в качестве аварийного. Таким образом, если сервер умирает, у вас все еще есть резервная копия для клиентов / пользователей, пока не восстановится основной сервер. Это должно облегчить некоторые проблемы, с которыми вы сталкиваетесь, имея один сервер так далеко. Опять же, это может быть излишним во многих обстоятельствах, но это зависит от того, насколько важен этот бизнес-сервер для вашей компании, и время простоя может повлиять на то, сколько вы готовы потратить на обеспечение его доступности в случае полный провал.

Если оборудование не сломалось, вы не сможете ничего сделать с последовательной консолью, так что вот способ:

  • получить некоторый удаленный доступ к последовательной консоли (последовательный порт IPMI по локальной сети, если система имеет> = IPMI-2.0, или последовательный кабель нуль-модема, подключенный к другой системе, в которой вы будете запускать minicom)
  • настроить grub и linux для использования последовательной консоли
  • перенаправить интерфейс системного BIOS на последовательный, если это возможно (многие серверные системы могут это сделать)
  • перезагрузите систему и убедитесь, что вы можете использовать (bios), grub, увидеть dmesg, увидеть сценарии инициализации и войти в систему через последовательную консоль
  • запустить обновление
  • скрестить пальцы

Кроме того, по возможности установите новую систему на другой диск или раздел, чтобы вы могли протестировать новую систему перед стиранием старой. Я обычно делаю это с двухдисковой системой: я вынимаю один диск из зеркала, создаю новое (деградированное) зеркало со свободным диском, устанавливаю его, если все в порядке, я уничтожаю старое зеркало и добавляю «старое» в горячем режиме. диск на новое зеркало и дайте ему восстановиться.

РЕДАКТИРОВАТЬ: Я читал, что это Dell R710, AFAIK, который должен иметь IPMI2. Настройте его запуск ipmitool локально в системе и протестируйте функцию последовательного порта через LAN, используя ipmitool sol enable в другой системе. Взрыв! У вас есть последовательная консоль. Dell также может перенаправить BIOS на последовательную консоль (этот IPMI, в свою очередь, будет перенаправлять на последовательную связь по локальной сети). Вы все равно должны были это сделать, чтобы получить доступ к системе, если что-то пойдет не так. Я управляю парой старых Dell PE1425 с использованием нуль-модемных кабелей с BIOS, grub, системных последовательных консолей и парой Dell R300 таким же образом, но с использованием последовательного интерфейса IPMI по локальной сети вместо фактического последовательного кабеля.

Я думаю, что вам лучше всего подойдет Out-of-Band Management (я больше всего знаком с HP iLO) или даже IP KVM.

Как упомянул Барт, тестирование бесценно, если у вас есть ресурсы (читай: запасной аналогичный ящик или другой член кластера).

Наконец (или, собственно, первое) Резервное копирование. Протестированные резервные копии. Резервные копии, которыми можно гордиться ...