Tag: Rancher

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

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

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

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

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