Category: Контейнери

Домашен дейтацентър или лаборатория|HomeLab, Home Data center

Много devops, програмисти, системни и мрежови администратори изграждат свои домашни лаборатории, мини дейтацентрове, включително доста амбициозни и сериозно направени системи…

В тази статия разглеждам някои от съществените лимити, с които следва да се съобразяваме в амбициите и инвестициите си.

Тъй като е удобно и дори изглежда изгодно да натоварим домашната си лаборатория със сериозни задачи (например проекти за клиенти) – изхождайки от опита си за проектиране и изграждане на сериозна домашна лаборатория (от клас мини дейта център :), споделям лош опит, в желанието си да спестя на читателя настъпването на някоя и друга мотика по пътя. 😉

1. Не правете голяма инвестиция – в крайна сметка домашната лаборатория е за тестове и PoC (Proof of Concept), използването и за други цели рано или късно води до задънена улица и по някое време ще се наложи да отпишете инвестираното и направите нещата както трябва.
Все пак, по-долу (т. 7.) описвам добра (макар не изключителна) идея, която може да осмисли сериозното използване на домашната инфраструктура.

Така че – инвестирайте разумно и пестеливо, за да не загубите много (пари, време, нерви, недоволни клиенти и пропуснати възможности).

2. Причината да отпишете инвестицията е, че домашният дейтацентър не скалира добре – нито в посока повече оборудване, но винаги ще е зле в посока отказоустойчивост и надеждност на работата.

Винаги! Винаги!!

Дали съм достатъчно категоричен?

Винаги!!!

3. Имайте предвид, че много рядко електрическите инсталации в стандартните жилища са оразмерени добре, за да поддържат
7 x 24 x 365 дори малки товари от 1-2KW. Това не винаги се забелязва и никога не е проблем в началото, но е добре да се провери след няколко месеца работа дали предпазителите и изходните шини не греят. Следващите индикатори са черни конвективни следи над таблото, миризма на изгоряло и вой на пожарни сирени.

4. Проблемите с шума са добре известни и всеки чувал стартиращ или натоварен сървър има ясна звукова представа за тях. :). Ще добавя само, че шумът от вентилаторите на средномощен сървър, в някои сгради се чува и през нощта, включително И от съседите.
Разбира се, те не са чак такъв проблем, но помислете за отношенията си с партньора… 🙂  

5. Охлаждането – няма лесен и смислен начин да направите добро охлаждане, ако ще имате повече сървъри. Студеният въздух трябва да се движи отдолу нагоре и фронт/гръб спрямо сървърите (ако са за рак монтаж). Това, което можете да направите е да държите достатъчно ниска температурата в помещението, за да осигурите генерално температурния режим на оборудването, но тази схема консумира повече енергия и поради това е ценово неефективна.

Е, ако имате достатъчно средства може да заложите на рак със собствена климатизация, но това е инвестиция, която не си струва предвид описаното в т. 2.

6. Възможните компромиси –

– Ако просто имате нужда от домашен лаб – използвайте втора ръка мобилни работни станции – те дават доста мощност и са относително тихи (стига да не спите в едно и също помещение с тях). Предимствата им – не ви трябва UPS или KVM имате си вградени монитор, мишка и клавиатура.

– За ML (Machine Learning) – сглобете си машина с големи бавни вентилатори, не повече от един, но възможно най-мощен ускорител, например NVidia GeForce RTX 2080Ti. Пак ще шуми, но ако е в съседно помещение се търпи. Или не се търпи – зависи…

7. Направете си (или използвайте “as a service”) мониторинг – като минимум – температура на околната среда и на системите – трябва да знаете температурното им състояние и да получавате известия при надвишаване на допустимите рамки.

Разбира се мониторинга е необходим и за други цели – например: параметри на експлоатация, надеждност, сигурност, контрол на SLA.

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

8. Ако правилно изберете оркестрацията на виртуализация/контейнеризация – ще можете лесно да мигрирате приложенията си към ваши ресурси в частни или публични клауд платформи. Така ще си запазите възможноста да правите бързи и евтини тестове и PoC в домашната среда, същевременно ще можете лесно да мигрирате продакшън системите на правилните платформи.

9. Спестете си проблеми със сигурността и надеждността и разделете правилно инфраструктурата за тестове и PoC от домашния си интернет, не ги смесвайте от самото начало най-добре – т.е. организирайте си файъруол (може и виртуализиран, но с много мисъл), умен суич/и.

Повтарям – от самото начало разделете едното от другото, никакъв компромис, временно решение и прочие.

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