- Кое е оптималното натоварване на един сървър?
- Под какво натоварване може да смятаме, че инфраструктурата се използва неефективно?
- Над какво натоварване считаме, че сървърът е претоварен?
В тази статия ще дам някои насоки и възможни отговори. 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, но е доста времеемко, а крайният резултат не винаги е достатъчен и често проблемите само се отлагат за известно време
В тази връзка препоръчваме виртуализация на ниво сървърна услуга (например уеб сървър), а още по-добре контейнеризация, защото получавате възможност за много по-фино настройване на производителност и отказоустойчивост и прецизен контрол по отношение на сигурност. Повече по темата:
Виртуализация –
Контейнеризация –
