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

Как обновить Xen с минимальным риском и временем простоя?

Недавно я заметил, что один из моих серверов работает на довольно старой версии Xen: 

$ dpkg-query -l | grep xen
ii  libc6-xen                          2.11.3-4                     Embedded GNU C Library: Shared libraries [Xen version]
ii  libxenstore3.0                     4.0.1-5.10                   Xenstore communications library for Xen
ii  linux-image-2.6.32-5-xen-686       2.6.32-48squeeze1            Linux 2.6.32 for modern PCs, Xen dom0 support
ii  xen-hypervisor-4.0-amd64           4.0.1-5.10                   The Xen Hypervisor on AMD64
ii  xen-linux-system-2.6-xen-686       2.6.32+29                    Xen system with Linux 2.6 for modern PCs (meta-package)
ii  xen-linux-system-2.6.32-5-xen-686  2.6.32-48squeeze1            Xen system with Linux 2.6.32 on modern PCs (meta-package)
ii  xen-tools                          4.2-1                        Tools to manage Xen virtual servers
ii  xen-utils-4.0                      4.0.1-5.10                   XEN administrative tools
ii  xen-utils-common                   4.0.0-1                      XEN administrative tools - common files
ii  xenstore-utils                     4.0.1-5.10                   Xenstore utilities for Xen

Dom0 тоже довольно старый: 

$ uname -a 
Linux Dom0 2.6.32-5-xen-686 #1 SMP Mon Feb 25 05:55:06 UTC 2013 i686 GNU/Linux

Я не очень знаком с таким производственным сервером, и я бы дважды подумал, прежде чем делать:

$ apt-get update
$ apt-get upgrade

Что мне нужно проверить перед обновлением, и нужно ли выключить и перезагрузить всю мою виртуальную машину во время обновления?

Я могу сказать это только по своему опыту работы с Citrix XenServer (бесплатная версия). Там апгрейд действительно детская игра. Загрузите .iso из Citrix, запишите / запишите его на CD / USB-накопитель, загрузитесь с него и выберите обновление. Он только отредактирует существующие разделы / файлы вашей установки и не коснется вашего репозитория хранилища, где находятся виртуальные диски ваших виртуальных машин. После перезагрузки все как прежде, даже автозагрузочные машины снова в сети.

Но, насколько я понимаю, вы не используете версию Citrix и не собираетесь этого делать. Исходя из моего опыта работы с KVM-QEMU, у вас не должно возникнуть проблем с обновлением среды виртуализации (в прошлый раз серьезное обновление работало даже без перезагрузки). Во всех случаях (если это возможно) я бы рекомендовал выключить или приостановить работу виртуальных машин, ваше обновление должно проходить как минимум быстрее. Если вы можете пережить небольшой простой.

И, кстати, Aptitude всегда спрашивает вас, хочет ли он установить больше пакетов или есть какие-либо конфликты. Или вы можете запустить его с --show-upgradeded, тогда он покажет только то, что он хочет обновить.

В этом случае минимальный риск и время простоя могут быть несколько субъективными терминами, а также могут быть ограничены доступными ресурсами.

'идеальный'способ обновления без простоев и с минимальными рисками для данных виртуальной машины будет включать несколько серверов, по крайней мере, 3, возможно, больше, в зависимости от нагрузки и требований к хранилищу:

  • Внутреннее хранилище для виртуальных машин, в идеале не на гипервизоре, здесь могут храниться образы виртуальных машин и моментальные снимки, а также данные, которые потенциально могут быть доступны для нескольких виртуальных машин.
  • Две системы гипервизора
  • В зависимости от общего количества гипервизоров, требований ввода-вывода, требуемого хранилища выделенная высокоскоростная сеть между гипервизорами и серверами хранения может повысить производительность.

Как только системы будут установлены, относительно просто перенести живую виртуальную машину. После того, как миграция с server0 на server1 будет выполнена и все будет проверено на правильность работы на server1, соответствующие службы на server0 могут быть остановлены и обновлены.

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

Минимальная настройка инфраструктуры, позволяющая даже временную миграцию сервисов между гипервизорами, может снизить влияние и прозрачность для клиентов, если / когда критические исправления безопасности необходимо применить к производственным системам.

В случаях, когда некоторое время простоя является приемлемым и инфраструктура дляидеальный'сценарий обновления, я обычно успешно использовал этот процесс, хотя иногда могут возникать непредвиденные проблемы; основываясь на прошлом опыте, сохраняя Горячий запас по возможности для критически важных систем и инфраструктуры - это всегда хорошая идея. Я использовал некоторые варианты этого набора шагов с KVM и Xen в openSUSE и CentOS:

  1. Убедитесь, что все резервные копии и снимки с виртуальных машин обновлены.
  2. Завершение работы виртуальных машин наиболее изящным способом
  3. Обновите / исправьте гипервизор
  4. Перезагрузите гипервизор, что, строго говоря, не обязательно, хотя в зависимости от выполненных обновлений это может быть самым простым способом убедиться, что все изменения вступят в силу.
  5. Прогуляйтесь по серверной в ожидании перезагрузки гипервизора.
  6. Перезагрузите виртуальные машины
  7. Проверьте, все ли работает