Tag: Data Center

Експлоатация на сървъри. Част 1. Натоварване

  • Кое е оптималното натоварване на един сървър?
  • Под какво натоварване може да смятаме, че инфраструктурата се използва неефективно?
  • Над какво натоварване считаме, че сървърът е претоварен?

В тази статия ще дам някои насоки и възможни отговори. IT инфраструктурата е комплекс от много взаимозависимости и няма еднозначен отговор. Освен това натоварването само по себе си не е проблем, проблем са страничните ефекти от него.

Винаги, когато планираме и експлоатираме IT инфраструктура (за целите на статията нека разглеждаме уеб сървър), следва да отчитаме TCO (Total Cost of Ownership) като параметър. Като пример за важността – в рамките на средностатистическия полезен живот на хардуера, управлението на електрическата консумация е съществена необходимост (грубо може да се приеме, че 10% от свързания оперативен разход подлежи на оптимизация).

Изключително важно е да си осигурим добра видимост към инфраструктурата, което предполага тотален (но разумен и не изкривяващ профила на натоварването) мониторинг върху работата на системите. Добрият мониторинг дава възможност за предвиждане и изследване потенциалните проблеми още преди да сме стигнали до етапа на продукция.

Нещата са кардинално различни, ако ги оценяваме в клауд инфраструктура (т.е. имаме чиста себестойност от тип „сървис като инфраструктура“) или уебсървъра работи върху „собствен“ сървър, консумиращ „собствено“ електричество и топлоотделящ в „собственото“ помещение, което отново „собствено“ охлаждаме. На тази тема ще посветя една от следващите статии.

TCO зависи от хардуера и начина, по който го експлоатираме. Най-силна и видима е зависимостта от броя и типа сървърни захранвания. Това е така, защото ефективността на захранването е най-висока, ако натоварването му е над 60% и оптимална при ~80%.

Ако сървърът е слабо натоварен, с малко памет и дискове – консумацията му е ниска и ако използва две балансиращи натоварването захранвания – то всяко от тях ще работи извън оптималния си режим.

  • В този случай е необходимо ръчно конфигуриране за работа в режим hot/cold stand-by на едно от захранванията
  • Така другото ще се натовари повече и ще работи в оптималните граници
  • По-новите сървъри поддържат автоматизирано управление на консумацията, но е необходимо да са включени в съответния режим (обикновено не е по подразбиране)

От гледна точка разходи за електричество – колкото повече натоварите сървъра – толкова по-добре, стига системата да се държи предвидимо. Друга зависимост се проявява в случаите, когато сървърът работи върху bare metal или виртуализиран хардуер. Ако е виртуализиран, хайпървайзъра ще се погрижи голямо натоварване (70%+) на сървъра да не се отрази (в някакви граници) на латентността на другите виртуализирани услуги.

Някои конкретни съвети

Насочени са основно към системни администратори и devops. Всъщност препоръчително е CIO и IT мениджърите да са наясно с материята, доколкото TCO и качеството на услугите са тяхна отговорност.

  • Някои комбинации сървърен софтуер (например Apache/PHP) предизвикват и въобще са чувствителни към латентност. Не допускайте в продукция всичко да зависи от фронтенд перманентно натоварен над, да речем, 50%, защото:
    • Няма място за реакция на инцидентни (пикови натоварвания)
    • Влияе и усложнява откриването на други свързани или несвързани проблеми
    • В крайна сметка усложнява и оскъпява експлоатацията на цялостната система
  • Планирайте и от самото начало използвайте лоудбалансър(и) и поне два фронтенда
    • Може да бъдат виртуализирани напълно или да се използва хибридна схема за оптимално TCO
    • Когато натоварването нарастне, за да си струва – тогава може да преминете към bare metal хардуер
  • В общи линии най-изгодно е инфраструктурата да е виртуализирана (контейнеризирана в частност)
  • Контролирайте (по възможност) архитектурата на приложението и качествения код на разработчиците
  • По възможност (особено, ако разработвате бизнес критични системи) избягвайте да съчетавате множество функции в един сървър (например уеб, дейтабейс, файлов и прочие)
    • Ако това не е възможно – оставете достатъчно резерв например средно натоварване на сървърен процес под 20% (за да имате резерв за абсорбиране на пикови натоварвания)
    • Не лош вариант е да управлявате прецизно натоварването в рамките на един сървър с cgroups, но е доста времеемко, а крайният резултат не винаги е достатъчен и често проблемите само се отлагат за известно време

В тази връзка препоръчваме виртуализация на ниво сървърна услуга (например уеб сървър), а още по-добре контейнеризация, защото получавате възможност за много по-фино настройване на производителност и отказоустойчивост и прецизен контрол по отношение на сигурност. Повече по темата:

Виртуализация –

Контейнеризация –

Съвети за избор и експлоатация на дейта център

Увод

Целта на документа е да дефинира обща методологична и организационна рамка за избор на дейта център и последващото изграждане и експлоатация на информационна инфраструктура. Документът няма претенции за всеобхватност и отразява опита на автора в:

  • Изграждане и експлоатация на дейта център бизнес
  • Избор на дейта център за различни услуги в спектъра голям бизнес – доставчик на услуги – интернет и телеком оператор

Описани са цялостният процес за подготовка, избор, изпълнение и успешна експлоатация.

Контрол на качеството

Контролът на качеството е от ключово значение за IT операциите на организацията, както въобще и за цялостната ѝ дейност. Ето защо описвам в по-големи детайли методологията за осигуряване на качество.

Контрол на качеството на монтаж на оборудване
  • Принципи
    • Изготвяне на подробен работен проект
    • Детайлно разработен план график за монтаж, тестване и пуск в експлоатация
    • Детайлно описани дейности по инсталация и монтаж
    • След доставка оборудването се подлага на функционални тестове преди окончателен монтаж
    • Оборудването се инсталира съгласно утвърдената практика – инсталация от обучен екип, притежаващ всички необходими за дейността сертификати, при пълно спазване на определената от проектанта и доставчиците технология и в координация с персонала на организацията или трети лица, който осигурява методическа подкрепа и необходимите проводи за електрически и мрежови свързаности
    • Спазване на правилата за безопасност на труда и пожарна безопасност
    • Преди въвеждането на оборудването в редовна експлоатация се извършват необходимите огледи и изпитания за удостоверяване на съответствието им с проекта и с действащите правилници и нормативни документи третиращи дадения вид дейност
    • Изработва се подробна техническа документация на направените инсталации и към нея се прилагат всички протоколи от извършени измервания, тествания и сертифициране на системите, включително с описания и снимков материал
  • Методи
    • Изработването на тестови казуси при които се проследяват номиналните експлоатационни параметри и се предприемат действия за влизане в номинал
    • След инсталация оборудването се включва в система за наблюдение и управление
    • Оборудването се включва в система за наблюдение на производителност, и наличност на услугата на ниво система за наблюдение и управление през мрежовата свързаност
    • Непрекъснато следене параметрите на хардуера – температура, захранващо напрежение по компоненти, състояние на вентилатори
    • Непрекъснато следене SMART параметрите на твърдите дискове и SSD, за да се реагира своевременно при излизане на параметър извън допустимите граници
    • Тестови период, в който се проследяват номиналните експлоатационни параметри и се предприемат действия за влизане в номинал
    • Установява се процедура за взаимодействие  за известяване на събития между отговорните страни за поддръжка на организацията и оператора на дейта центъра
    • Установява се връзка между системата за наблюдение и управление на организацията и оператора на дейта център услугата
      • Система за сигнализация при проблем
      • Система за ескалация на проблем, съгласно параметрите на договореното ниво на обслужване (SLA)
Контрол на качеството на дейности по осигуряване на мрежова свързаност

Контролът на качеството на дейностите по осигуряване на мрежова свързаност се осъществява с прилагане на следните принципи и методи:

  • Принципи
    • Детайлно разработен план график за изграждане на свързаности, тестване и пуск в експлоатация
    • Наемане на услуги от надеждни телекомуникационни оператори,  с дългогодишен опит в експлоатацията на градски и мобилни мрежи
    • Използване на надеждно и отказоустойчиво оборудване от реномирани доставчици, разполагащи с отлична сервизна база
    • Пълна документация на направените свързаности, включително с описания и където е уместно – снимков материал
  • Методи
    • След провизиране на услуга, комуникационното трасе се включва в системата за наблюдение на производителност, качество и наличност на услугата
    • Непрекъснато следене на качествените параметри и ескалация при деградация на параметър извън договореното ниво на обслужване
    • Тестови период, в който се измерва качеството на изградените свързаности и се синхронизира взаимодействието между центровете за поддръжка на организацията и телекомуникационните оператори
    • Връзка между системата за наблюдение и управление на организацията и телекомуникационни оператори
      • Автоматизирана сигнализация при проблем
      • Автоматизирана ескалация на проблем, съгласно параметрите на договореното ниво на обслужване
Предварителна подготовка

Правилно подготвеното задание е предпоставка за получаване на добре обмислена и остойностена оферта от страна на дейта център оператора. Трябва да отговорите на следните въпроси на ниво организация:

  • Как изглежда, каква е архитектурата и какви са параметрите на цялостната информационна система – на ниво дейта център и (ако има) информационни системи на огранизацията извън дейта центъра 
  • Какви SLA ангажименти следва да гарантира тази инфраструктура (например SLA към клиентите на организацията, към вътрешни за организацията потребители), за да можете да определите своите изисквания към оператора на дейта центъра и телекомуникационните оператори (ако са различни)
  • Какви са възможностите на организацията да обслужва своя SLA – налични човешки ресурси и специализирани информационни системи
  • За препоръчване е да имате количествено изражение на SLA – време, дължимо/очаквано обезщетение. Можете да използвате този SLA Calculator, за да проиграете различни варианти
  • Направете цялостна технологична оценка
    • Размер на оборудването – дълбочината на сървърите е съществен параметър
    • Вентилационен поток – фронт към гръб или странично
    • Начин за монтаж на оборудването в шкафовете
      • Носещи шейни
      • Лавици
      • Кабелни водачи или прикрепващи скоби
    • Захранване – брой на захранванията на единица оборудване – необходимо е, за да се предвидят достатъчно на брой разклонители. Имайте предвид, че последващото добавяне на разклонители не винаги е удобна опция, а понякога не е възможно без сериозно пренареждане на оборудване, което предполага и прекъсване на услуги
    • Обща консумация в начален и максимален капацитет
    • Брой и вид на мрежова свързаност за всяко оборудване
    • Потенциална необходимост от изграждане на повече свързаности към разпределителни табла в дейта центъра
    • Логистика на оборудването
      • Начална – при инсталация – рампи, подходи, асансьори
      • Експлоатационна – оперативна доставка или съхранение на резервни части (дискове, сървъри, мрежово оборудване) 
      • Достъп до дейта центъра в работно/извън работно време.
    • Упълномощени лица и процедура за идентификация – на място и отдалечено (например телефон, мейл)
    • Имайте предвид, че ако получавате мрежови услуги от трети оператори на територията на дейтацентъра, е необходимо да отчитате правилно точния ангажимент, който дейта център оператора и телеком оператора имат към Вас. Не очаквайте да получите нещо повече или различно от това, което е описано в договора 
  • Направете оценка за цялостната цена на дейта център услугата. Определете TCO (Total Cost of Ownership), като отчитате следните компоненти
    • Цена на колокация на оборудване. Обикновено се отчита на 1RU (rack unit) или кратно на капацитет на шкаф
    • Цена за електрическа консумация – може да се смята по номинал на инсталираното оборудване, да се измерва с контролен електромер или да се подава като информация от захранващата система на дейта център оператора 
      • Имайте предвид, че в дългосрочен план цената на електрическата енергия се увеличава. От тази гледна точка е разумно да се заложи на последно поколение оборудване, поради по-голямата му енергийна ефективност 
    • Цена за допълнителни услуги тип “поддръжка на място” (“remote hands”) и какво конкретно се включва в нея
    • Размер и степен на отговорност на оператора на дейта центъра към инсталираното оборудване и предоставяните услуги
Критерии за избор

Изборът на дейта център и начинът, по който се извършва експлоатацията на оборудването, свързаностите и услугите в него са елемент от стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery). Това е постоянен процес, а не еднократно планирана и извършена работа. Добрата съвместната работа с дейта център оператора е от ключово значение за този процес.

За целите на този документ приемам, че технологичните и финансови параметри на нуждите на организацията са удовлетворени.  Нека разгледаме останалите критерии, които може да определят окончателното решение:

  • Наличие в дейтацентър оператора на капацитет да обслужи нуждите на организацията – например:
    • Персонал като количество и качество
    • Наличие на информационни системи, които реализират, не само необходимата за дейта център/телеком оператора функционалност, но могат да бъдат свързани със съответните системи на организацията
    • Съветваме да проучите дългосрочната финансова и организационна стабилност на дейта център оператора
  • Съвместими организационни култури и ниво на зрялост в дейта център оператора и Вашата организация
  • Потенциал за развитие в оператора, който да гарантира дългосрочното Ви взаимодействие
    • Технологичен потенциал
    • Бизнес потенциал
  • По възможност се насочвайте към оператори, които достатъчно дълго време експлоатират дадена инфраструктура и/или технологично решение.
    • Избягвайте да бъдете първи клиент в нов център или инфраструктура, освен ако SLA, под чиито рамки работите, не позволява поемането на подобен риск
  • Анализирайте SLA предложението. То следва да демонстрира:
    • Постижими за организацията на оператора параметри. Проверете ги. 
      • Потърсете мнение от други клиенти
      • Потърсете мнения по форуми и потребителски групи
    • Зрялост – детайлно разписани отговорности и процес а работа
    • Смислен процес на ескалация – достатъчо нива, но без формално размиване на процеса
      • Плюс е, ако има механизъм, да ексалирате до висш мениджмънт
      • Минус е, ако висшият мениджмънт е необходим на всяка стъпка в процеса на офериране, преговори, предоставяне на услуга, експлоатация
    • Достатъчно точки за недвусмислен контрол –
      • Конкретни количествени критерии за качество и наличност
      •  Възможност за независимо измерване на количествените параметри
      • Интерфейс за наблюдение в реално време на параметри, които са в контрол на оператора (например електрическа консумация)
  • Дейта център операторът следва да предостави ясна и изпълнима процедура по сигурността 
Планиране и изпълнение
  • След доставка, оборудването се проверява за комплектовка и електрическа работоспособност от екип на организацията
    • Имайте предвид, че дори при използване на ново (или дори вече работило във Вашата инфраструктура) оборудване, са възможни проблеми или неработещи компоненти
    • Планирайте с излишък от време
  • Оптимално е монтажът на оборудването в дейта центровете да се извършва от обучен персонал на дейта център оператора под Ваш методически контрол и съгласно предварително съгласувана инструкция за монтаж, маркировка на оборудване и свързващи кабели
  • Фиксирането на оборудването, захранващите и мрежови кабели, се извършва съгласно добрите практики и конкретните особености на използваните шкафове за оборудване, кабелни разпределителни системи и захранващи системи
  • Монтажът на оборудването следва да отговаря на изискванията за лесен достъп за профилактика и процедури за добавяне на нови модули – например памет и дискове. Изваждането на сървър за профилактика, сервиз или добавяне на модули следва да се извършва без необходимост от прекъсване работата на останалите сървъри, като подвеждането на захранващи и комуникационни кабели трябва да изключва или намалява до минимум риска от неволно прекъсване или влошаване на устойчивост на свързване
  • Използват се само фабрично произведени и тествани преди монтаж захранващи и комуникационни кабели
  • След физически монтаж се пристъпва към електрическо оживяване и проверка за правилно свързване към захранващите А и Б подсистеми. Идентифицират се предпазителите осблужващи конкретните сървъри и шкафове
  • Описва се местоположение, маркировка, комуникационни и захранващи кабели за всяко оборудване, както и местоположението на предпазителите на електроразпределителното табло и направените комуникационни кроскънекти
  • Добра практика е документацията да се подготвя в процеса на инсталация, отколкото да се разчита на спомени от трети лица
Успешна експлоатация

Минимално необходимо е:

  • Поддръжка на актуална документация
  • Регулярни контакти с дейта център оператора
  • Регулярни посещения (несвързани с проблеми) в дейта центъра
    • Необходими са, за да имате наблюдения върху развитието на оператора и да получите ранна и изпреварваща информация за потенциални организационни и/или финансови проблеми
  • Изграждане в организацията на Оперативен център, който осигурява тотален мониторинг и контрол на всички параметри свързани със:
    • SLA на дейта център оператора към организацията 
    • SLA на организацията към нейните вътрешни и външни клиенти
  • Връзка между тикетинг системата на организацията и съответния и аналог в Дейта център и телеком операторите
  • Поддържане на актуални процедури за действие в случай на отказ на оборудване, свързаности или дейта център. Тестове на оборудване и действия на персонал в случай на необходимост
За повече информация:
Съвети към IT мениджъра:
  • Изборът на дейта център и начинът, по който се извършва експлоатацията на оборудването, свързаностите и услугите в него са елемент от стратегията на организацията за осигуряване на възстановяване след срив (Disaster Recovery). Това е постоянен процес, а не еднократно планирана и извършена работа. Добрата съвместната работа с дейта център оператора е от ключово значение за този процес
  • Доколкото смяната на дейта център е изключително тежко, времеемко и с множество скрити разходи упражнение, добрият избор е от бизнес критично значение

OpenNebula

Кратко описание

OpenNebula е мощно и гъвкаво решение с отворен код за изграждане, оркестрация и експлоатация на частни и хибридни виртуализационни и клауд решения. Позволява работа в режим инфраструктура като услуга (IaaS).

Използват се KVM, LXD и Vmware хипервайзори. Поддържа инфраструктура разположена в един или множество дейта центрове. Позволява виртуализация на ниво центрове за данни и/или облачна инфраструктура.

OpenNebula е софтуер с отворен код и Apache лиценз.

OpenNebula оркестрира сторидж, мрежа, виртуализация, мониторинг и сигурност. Разполага с инструментариум, включващ интеграция, управление, мащабируемост, сигурност и акаунтинг на предоставяните услуги. ОпънНебюла поддържа и съчетава множество йерархии от потребители и услуги (multitenancy), като осигурява съвместната работа, управление на споделени ресурси, отказоустойчивост (High Availability), възстановяване от срив (Disaster Recovery).

OpenNebula може да се използва за управление на виртуални дейта центрове, федерация на дейта центрове и хибридни решения. Заради поддържаните отворени и частни стандарти, OpenNebula позволява изграждане на хибридни решения в Amazon EC2, OpenStack, GCP.

Подходящ за:
  • Оркестрация на виртуализация на ниво голям бизнес, клауд провайдър и телеком провайдър 
Неподходящ за:
  • Решения за малък бизнес
  • Оркестрация на контейнери (изключение LXD контейнери)
За повече информация:
Защо OpenNebula:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Интегрирано решение за High Availability / Disaster Recovery
  • API за връзка с трети продукти
Недостатъци:
  • Липса на интерирано бекъп решение
  • Липса на интегрирано управление на сторидж 
  • Поддържа само LXD контейнер технология, няма директна поддръжка на Docker и Kubernetes. Т.е. те могат да се инсталират във виртуални машини под OpenNebula управление
  • Макар да има средства за визуализация на основни метрики на OpenNebula клъстера и поддържаните виртуални машини, контейнери и сторидж има какво да се желае в това отношение и е необходимо да се интегрира с продукти като Zabbix / GrayLog / Grafana, за да има функционални и богати средства за мониторинг на състоянието на клъстера и услугите
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Използване
    • Време за базово усвояване: 12-24 часа.
    • Необходимост от оперативна поддръжка: ниска до средна (под 6 часа месечно) за системи до 5 физически сървъра и 50 виртуални машини
  • Инсталация на OpenNebula – доста насипна, особено при клъстеризиране на системата за управление 
Степен на завършеност / Необходимост от развитие:

  • Комплексно решение с множество компоненти, които следва да се настроят и интегрират за съвместна работа
Съвети към IT мениджъра:
  • Подходящо е за решения в широк спектър – от няколко до хиляди сървъри, разположени в един или множество дейта центрове
  • OpenNebula е особено подходяща при изпълнение на някой от следните сценарии или произволна комбинация от тях:
    • Мащабни решения с поддръжка на множество дейта центрове
    • Изграждане и използване на хибридни клауд (hybrid cloud) решения – комбинация от частна инфраструктура на организацията и интерфейс за оркестриране на виртуализация върху публични клауд решения (например Amazon EC2)
    • Интеграция (например поради причина оптимизация на разходи) в единна система на различни хипервайзор технологии от бизнес клас (например VmWare) и Open Source  (KVM или Xen) 
  • Поради комплексния характер на OpenNebula и сценариите за използването ѝ, кривата на обучение е доста разтеглена и е необходимо наличие на администратори с много опит
  • Необходимо е да се разработят и/или интегрират допълнителни компоненти, за да се разполага с напълно развита OpenNebula система (Backup, Storage, Containers)
  • Използването на хипер конвергирана архитектура (сторидж система и виртуални машини споделят едни и същи физически сървъри) предполага добро планиране, изпълнение и непрекъснато наблюдение на пърформанс параметрите на системата

ProxMox

Кратко описание – ProxMox

ProxMox е система за оркестрация на виртуализация базирана на отворен и свободен код. Накратко:

  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите

Позволява изграждане на бизнес клас системи за управление на виртуални машини и контейнери (KVM Virtual Machines, LXC containers) и сторидж (ZFS, Ceph) върху решение с отворен код без заключване към доставчик. Това включва не само самия ProxMox, но и необходими допълнителни компоненти, например за управление на сторидж (ZFS, Ceph).

В категорията управление на виртуални машини, ProxMox е може би най-завършеният (като набор от минимално необходими функционалности) продукт. 

При ProxMox няма опити потребителите да бъдат „меко“ или „директно“ стимулирани, за да преминат към по-пълната, по-завършена, по-работеща комерсиална версия – както е подхода при Citrix Xen Server.

Подходящ за:
  • Оркестрация на виртуализация на ниво малък, среден и голям бизнес
  • На ниво малък и среден бизнес има всички характеристики на тотално решение
Неподходящ за:
  • Доставчици на виртуализационни услуги (Virtualization Service Providers)
  • Оркестрация на контейнери (изключение LXC контейнери)
За повече информация:
Защо ProxMox:
  • Макар безплатно решение, поддържа функционалности, които се реализират в индустриален стандарт като VmWare.
  • Многократно надхвърля по възможности безплатната версия на Xen Server
  • По-добре интегрирано решение спрямо Open Nebula и Open Stack и за разлика от тях огромна част от необходимата функционалност присъства в базовия продукт и е налице веднага след инсталация
  • Подходящо е за решения в спектъра – 1 до 32 сървъра
  • Добре се вписва в корпоративна среда (LDAP/AD) и в политиката за сигурност на компанията
  • Интегрирано решение за High Availability / Disaster Recovery
  • Интерирано бекъп решение (само базови функционалности, ниво snapshot на операционна система)
  • Интегрирано управление на сторидж – практически не се налага да се управлява отделно решение за сторидж.
    • Локален (LVM/ZFS)
    • Разпределен (Software Defined Storage) – Ceph
  • API за връзка с трети продукти
  • Функционален безплатен Андроид клиент за наблюдение и управление + комерсиална версия с разширени възможности. 
Недостатъци:
  • Липсва мащаба и богатството от възможности за развитие на продукти като OpenStack и Open Nebula
  • Поддържа само LXC контейнер технология, няма директна поддръжка на Docker и Kubernetes. Т.е. те могат да се инсталират във виртуални машини под ProxMox управление. 
  • Макар да има средства за визуализация на основни метрики на ProxMox клъстера и поддържаните виртуални машини, контейнери и сторидж има какво да се желае в това отношение и е необходимо да се интегрира с продукти като Zabbix / GrayLog / Grafana, за да има функционални и богати средства за мониторинг на състоянието на клъстера и услугите. 
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Използване
    • Време за базово усвояване: 8-12 часа.
    • Необходимост от оперативна поддръжка: ниска до средна (под 6 часа месечно) за системи до 5 физически сървъра и 50 виртуални машини
  • Инсталация на ProxMox – готова дистрибуция – лесна инсталация на сървър (node) в рамките на минути. 
Степен на завършеност / Необходимост от развитие:

  • Напълно завършено решение с всички необходими основни компоненти
  • Следва да се отчита, че наличието на компонент, например система за бекъп, не значи, че наличната система покрива всички възможни случаи
Съвети към IT мениджъра:
  • Струва си. Може да се разчита на ProxMox за изграждане на виртуализационна инфраструктура. 
  • Макар безплатно решение, ProxMox поддържа функционалности, които се реализират в индустриален стандарт като VmWare.
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват оптималните умения, за да използват ProxMox
  • Разполага с всички необходими компоненти (управление на виртуализация, LXC контейнери, High Availability, Disaster Recovery, Backup, Storage), за бързо изграждане на необходимата инфраструктура.
  • Използването на хипер конвергирана архитектура (сторидж система и виртуални машини споделят едни и същи физически сървъри) предполага добро планиране, изпълнение и непрекъснато наблюдение на пърформанс параметрите на системата.
  • Макар да са налични средствата за backup и организация на HA/DR, необходимо условие е разработването на съответните правила и процедури на ниво IT отдел на организацията.