Не редко меня спрашивают “почему не VMware?”… ну так вышло блин … я попробовал XenServer, и проект взлетел. Некоторое время, пару-тройку лет все шло хорошо, но когда количество клиентов уперлось в ресурсы, начались проблемы. Чтобы немного отсрочить апгрейд памяти, на некоторых не критичных ВМках которые размещал бесплатно или по пониженным тарифам, была включена технология Ballooning для экономии физической памяти серванта. И все-бы ничего, но время от времени начались перезагрузки… причем речь не о гостевых системах, а о самом гипервизоре. Сыпля ошибками на подобии:

….
[ 84961.960488] WARN: [<ffffffff8117557c>] ? vfs_writev+0x3c/0x60
[ 84961.960490] WARN: [<ffffffff8106d85e>] SyS_reboot+0xe/0x10
[ 84961.960496] WARN: [<ffffffff81554ab9>] system_call_fastpath+0x16/0x1b
[ 84961.960497] WARN: Code: 0f 1f 44 00 00 5d c3 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 8b 87 28 02 00 00 48 89 e5 8b 80 bc 00 00 00 <a8> 04 75 25 f6 c4 01 74 11 c1 e8 10 0f b6 c0 eb 21 66 0f 1f 84
[ 84961.960522] EMERG: Kernel panic – not syncing: softlockup: hung tasks

или

….

[ 732518.581519] WARN: [<ffffffff810a3912>] ? cpu_startup_entry+0x1c2/0x280
[ 732518.581526] WARN: [<ffffffff8153195d>] ? cpu_bringup_and_idle+0x13/0x15
[ 732518.581528] WARN: Code: 85 e4 fe ff ff e9 d3 fe ff ff 0f 1f 80 00 00 00 00 5b 41 5c 41 5d 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 55 48 89 e5 53 <48> f7 07 00 c0 00 00 48 89 fb 74 0a e8 35 fe ff ff eb 22 0f 1f
[ 732518.581557] ALERT: RIP [<ffffffff8112bb1a>] put_page+0xa/0x50
[ 732518.581560] WARN: RSP <ffff880188643d58>
[ 732518.625200] WARN: —[ end trace 1b10b00732a8de7c ]—
[ 732518.675156] EMERG: Kernel panic – not syncing: Fatal exception in interrupt

Натуральный эпик-фейл в натуре…

Сами понимаете, ситуэйшен не очень приятный, 5-10 минут даунтайма серванта, и всех виртуалок на нем – не приносят клиентам радости в середине рабочего для. С последующим насилованием клиентами моего анального отверстия, из расчета 1 час любимого наслаждения Маркиза де Сада за каждую минуту даунтайма.

В рабочем порядке, согласованно с клиентами, выполнил полное обновление всего… прошивки материнки, прошивки контроллеров, установку всех патчей на гипервизор, все железо было протестировано стресс-тестами, ошибок в железе найдено небыло. По этому проблемы железа были в принципе исключены. Но проблема не решилась, спонтанные паники с интервалами через 1-5 недель продолжились.

Рассматривал вариант накатить Citrix XenServer 7.6, но редиски из Citrix выпилили из его бесплатной версии функционал Баллонинга памяти. По этому заменить гипервизор сразу – не мог. Ну а поскольку услугу надо было расширять и наращивать объемы оперативки в любом случае – заказал оперативку, зарядил ее в слоты серванта, и выключил функцию  Баллонинга. Вроде-как ситуация стабилизировалась, перезагрузок более не наблюдал. За одно перевел все ВМ-ки с PV на HVM виртуализацию.

Сначала несколько расстроило то что выше XenServer 7.6 апгрейдиться было некуда, Citrix закрыл эту линейку устранив редакцию Free, и переименовал продукт в Citrix Hypervisor 8.0. Но недавно все-таки свершилось чудо! Citrix’ы добавили в линейку Citrix Hypervisor 8.0 редакцию Express – это бесплатная редакция, продолжение традиций XenServer Free, но без шаринга исходных кодов, и со всеми новоиспеченными ограничениями последнего бесплатного XenServer 7.6. Новые лимиты на Express можно посмотреть тут. Поскольку оперативки мне теперь хватает с запасом, отсутствие Баллонинга меня не смущает. Недавно я накатил апдейт с Citrix XenServer 7.0 Free до Citrix Hypervisor 8.0 Express, апдейт встал хорошо, без особых проблем.

Рассматривался и вариант миграции виртуалок на VMware, но это влечет за собой нуждик по временной(на срок миграции) аренде не менее мощного серванта, что само по себе влетает в достаточно солидную копеечку. Поскольку лишнего достаточно мощного серванта у меня на колокейшене пока нет. А так-же проблемно то, что методов прямой миграции нет, и каждую виртуалку пришлось-бы мигрировать по схеме:

• На временный сервант ставить еще один Citrix, мигрировать на него все ВМ-ки(Citrix->Citrix).
• На донор ставить идейно-правильный VMware.
• Побайтово/пофайлово!!! переносить с времянки с Citrix’ом на новый гипервизор VMware на доноре всю внутрянку каждой отдельно взятой ВМки.(Citrix->VMware)
• Восстанавливать загрузчик на каждой ВМ-ке, менять имена дисков, править сетевухи, проверять успешность загрузки и при необходимости чинить ее. Этот этап можно делать только по ночам, и только при уведомлении клиентов.
• Заниматься всякими мелочами типа замены тулзов для гипервизора внутри ВМок.

Очень геморройная схема! За неделю-другую, при условии написания скриптов автоматизации мигрировать можно. По прикидкам, потом еще хотя-бы пол месяца держать арендованный сервер с старым Citrix’ом и старыми виртуалками на случай проблем. Сами понимаете, без особой нужды заниматься таким BDSM, не радует… Если проблем не будет, делать этого не вижу смысла. Поскольку ручная миграция – это не только нуждик по аренде сервака на время миграции но и очень большие затраты времени(которые никто не оплатит), но и некоторая весьма специфичная проблематика веб-хостинга…

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

В целом – Citrix’овые Xen’ы – не плохи сами по себе, весь нужный функционал там есть, а с отсутствием некоторого можно мирится. ВМки работают так-же быстро как на Bare Metall, но всю малину испортил негатив по нестабильной работе…. впечатление из положительного изменилось на резко отрицательное. Причем сначала, пока можно было еще легко заменить гипервизор – проблем никаких не было вообще, они появились через года эксплуатации системы, когда миграция усложнилась из за объемов ВМок и их количества.

Надеюсь Citrix 8-ка будет работать без сбоев, но если нет, план уничтожения Citrix-а разработан, финансы готовы, админ морально готов.

PS. Ну а поскольку за 3 с небольшим года проект хостинга вышел их разряда экспериментального в разряд типовой услуги – заодно прокачал железо в плане резервирования… к типичной схеме резервирования винтов 1+1, добавилось резервирование БП 1+1 от разных вводов, резервирование сети с LACP по схеме 1000BASE-T+1000BASE-T от разных 2-х коммутаторов(это помимо резервирования дало еще увеличение пропускной способности до 2-х ГигаБит). Конечно цена аренды колокейшена за юнит для меня из за этого возросла, но обороты это позволяют.