Tag: Containers

Експлоатация на сървъри. Част 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, но е доста времеемко, а крайният резултат не винаги е достатъчен и често проблемите само се отлагат за известно време

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

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

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

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)
  • Използването на хипер конвергирана архитектура (сторидж система и виртуални машини споделят едни и същи физически сървъри) предполага добро планиране, изпълнение и непрекъснато наблюдение на пърформанс параметрите на системата

Rancher – Enterprise Kubernetes Management

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

Rancher (Ранчър) е уеб базирана платформа за оркестрация на Kubernetes (Кубернетес) клъстери с отворен код.

Предлага пълен набор от средства за организации, които изграждат контейнеризирани решения. Управлява оперативните и предизвикателствата пред сигурността при работа с множество Kubernetes клъстери, като предоставя на DevOps инженерите интегрирани инструменти за управление на натоварване и реализация на HA/DR инфраструктура. Ранчър позволява изграждане на частни, публични и хибридни контейнер инфраструктури. Rancher разполага със средства и добре се интегрира в CI/CD процесите на организацията. 

Подходящ за:
  • Оркестрация на контейнери на ниво малък, среден и голям бизнес
  • На ниво малък и среден бизнес има всички характеристики на тотално решение
Неподходящ за:
  • Излишно комплексен за малки и/или индивидуални решения
За повече информация:
Защо Rancher:
  • Зрял проект с дългогодишно развитие и широка база от разработчици
  • Пълна функционалност в основна безплатна версия
  • Наличие на комерсиална поддръжка, както и на достатъчно подробна и надеждна поддръжка от общността на потребителите
  • Макар безплатно решение, поддържа функционалности, които се реализират в индустриален стандарт като OpenShift
  • Работи с всички разпространени операционни системи без специфични ограничения в тази област
  • Добре се вписва в корпоративна среда (LDAP/AD) и в политиката за сигурност на компанията
  • Интегрирано решение за High Availability / Disaster Recovery
  • Библиотека с предварително дефинирани приложения, включително Helm
  • Интегрирано управление на сторидж – практически не се налага да се управлява отделно решение за сторидж
  • API за връзка с трети продукти
  • Цялостно решение (базирано на Grafana и Prometheus) за наблюдение на метрики на клъстера и компонените му
  • Няма натиск, както е, например при OpenShift, да се използват специфични дистрибуции и платени технологии с цел постигане на по-добра надеждност и производителност
  • Няма значителен риск при необходимост да се премине към алтернативно и платено решение, доколкото Ранчър надстроява, но не променя кардинално kubernetes
Недостатъци:
  • Няма известността и реномето на OpenShift. Това е причина да се приема с известно недоверие от софтуерните архитекти и бизнес потребители, особено в областта на развитието на ентърпрайс приложения
  • Няма много материали на български език
Оценка на необходимите ресурси при внедряване:
  • Използване
    • Време за базово усвояване: 16-32 часа (включва docker, kubernetes, basic networking, basic security, basic CI/CD, basic HA/DR)
    • Необходимост от оперативна поддръжка –
      • Средна към висока, в зависимост от комплексността на приложенията и броя на клъстерите
      • Предполага специализиран персонал и по-голям екип, ако се работи за 7×24 бизнес критични решения
  • Инсталация на клъстер върху виртуални машини или отделен хардуер – отнема няколко часа 
Степен на завършеност / Необходимост от развитие:

  • Напълно завършено решение с всички необходими основни компоненти
  • Следва да се отчита, че наличието на компонент, например система за бекъп, не значи, че наличната система покрива всички възможни случаи
Съвети към IT мениджъра:
  • Rancher e тотално решение за изграждане на контейнерна инфраструктура. Може успешно да се използва вместо комерсиални решения като OpenShift
  • Kривата на обучение е приемлива, дори администратори с малко опит бързо усвояват оптималните умения, за да използват Rancher, но при всички случаи са необходими базови познания в областта на kubernetes –
    • Security, Networking, HA/DR, CI/CD и в частност YAML
  • Разполага с всички необходими компоненти (контейнери, мрежи, High Availability, Disaster Recovery, Backup, Storage), за бързо изграждане на необходимата инфраструктура
  • Може да се използва в хиперконвергирани архитектури (сторидж система, виртуални машини и контейнери споделят едни и същи физически сървъри), но системата следва да се проектира правилно и да се организира добро наблюдение на пърформанс параметрите на компонентите ѝ
  • Частните виртуализирани и контейнеризирани инфраструктури и приложения поставят допълнителни изисквания към управлението на системите.
    • Ако имате опит от използване на публични клауд услуги (AWS, Azure, GCP), следва да отчитате, че макар ценово по-изгодни (разбира се има изключения), частните инфрастрктури предполагат много повече и по-квалифицирани човешки ресурси 
    • Serverless парадигмата е смислена само при реализация в публична инфраструктура

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 отдел на организацията.