VMware vCenter Server Appliance — иметь или не иметь…

Ранее я описывал процедуру развертывания VMware vCenter Appliance как альтернативу установке онного на Windows платформу. Тогда я уже косвенно упоминал о том, чем готовое решение лучше и проще, но не упоминал о том, какие недостатки у vCenter Server Appliance.

Исправляюсь. Как и обещал — ниже короткий список наиболее весомых недостатков, по моему скромному субъективному мнению.

Во-первых, в наш любимый апплаинс, до сих пор так и не запилили Update Manager и если у вас инфраструктура больше 5-10 узлов, то обновлять эти узлы без апдейт манагера будет муторной задачкой. «Ну и что», скажете вы, «можно ведь развернуть апдейт менеджер на отдельной машинке» — и это правда! Но, развернуть его можно только на винде (тадаааам!!), которому, к тому же, понадобится еще и своя база данных, и в результате вся унификация и консолидация, плюс отвязка от винды идет по одному месту (сами догадайтесь по какому). Будем надеяться, что в ближайших релизах это недоразумение исправят.

Во-вторых, не смотря на то, что у нас вроде бы как уменьшается количество работы по первоначальной установке и настройке, при использовании vCenter Server Appliance, но не стоит забывать об обновлении и поддержке данного решения. Это значит, что после того, как мы развернули готовый самодостаточный модуль, на этом его самодостаточность заканчивается, и если сам vCenter Server мы можем обновлять с помощью специального апдейтера в системной консоли (в пределах мажорной версии), то поддерживать и обновлять операционную систему Linux, на которой построен модуль (к стати, там SLES), нам придется вручную. Для виндузятников, это бывает кошмарным сном, да и просто для компаний, в которых винда — корпоративный стандарт, это неприемлемо.

Ну и в третьих, сам апгрейд такого модуля с одной мажорной версии на другую — достаточно муторный процесс и выглядит он примерно так:

  • развертываем новую версию апплаинса рядом со старой
  • какими-то магическими внутренними средствами связываем старый и новый апплаинсы
  • новый апплаинс передирает у старого все настройки и содержимое внутренней БД
  • старый апплаинс утиллизируется

Честно скажу — детально с процедурой обновления пока что не разбирался, поэтому могу ошибаться в деталях, но в целом это выглядит так.

Для сравнения — в винде процедура обновления выглядит как стандартное обновление виндового ПО (ну не всегда, конечно) — запустили инсталлер, выбрали апгрейд -> нехт -> нехт -> финиш.

Исходя из вышесказанного, я бы рекомендовал использовать данное решения в продуктиве аккуратно, и учитывать все его ограничения.

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

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Не робот ли ты часом? * Лимит времени истёк. Пожалуйста, перезагрузите CAPTCHA.