Не е ли по-добре да използваме един собствен голям сървър

Оригиналът е на Nima Badizadegan, който прави интересно сравнение на използването на електронен облак, виртуален сървър под наем или реален физически сървър.

Много думи са казани в спора относно монолитите и микроуслугите. Но всъщност реалната дилема е в това дали разработчикът трябва да си губи времето с разпределената архитектура.

Всички много добре знаят какво е виртуализацията. Това е софтуерен слой от абстракции между вашето програмно осигуряване и сървърите, на които то реално работи. В наши дни безсървърните изчисления са буквално навсякъде. И дори заделеният за определен тип задачи сървър, вече е виртуален. Само че всеки софтуер работи на съвсем реален хардуер. А в ерата на виртуализацията хардуерът стана много по-мощен и по-евтин, отколкото бихте очаквали.

Показаната най-горе снимка е на сървър, базиран на процесорите на AMD, който се използва в дата центъра Microsoft Azure. Големите метални пластини с медните тръби към тях са радиаторите на охлаждането. Тези радиатори са свързани с медни тръби към топлообменници, като това е направено за всеки един процесор от този тип сървъри. Конкретно в този случай се използват сървърни процесори на AMD от трето поколение със следните основни технически характеристики:

• 64 физически ядра
• 128 логически ядра
• Тактова честота 2,0-2,5 GHz
• Ядрата изпълняват от 4 до 6 инструкции на такт
• 256 MB кеш памет от трето ниво

Тоест, този сървър има общо 128 физически/256 логически ядра. При тяхната съвместна работа изчислителната мощност на тази машина възлиза на 4 терафлопа. Интересно е, че в началото на 2000-та година този сървър би заел първото място в рейтинга Top500 на най-мощните суперкомпютри на планетата и би останал в този рейтинг чак до 2007 година. Всяко едно ядро на този чип е  значително по-мощно от който и да било едноядрен процесор отпреди 10 години, като едновременно с това неговият изчислителен конвейер е много по-широк.

Над и под всеки процесор в този сървър е поставена памет – има по 8х слота за DDR4-3200 оперативна памет. Максималният капацитет на икономически изгодните плочки DIMM памет е 64 GB. Тоест, ако целта е да се направят икономии, то този сървър ще побере 16*64 GB = 1 TB оперативна памет. А ако бъдат поставени специализираните DIMM плочки с голям капацитет, които са по-скъпи и малко по-бавни, то този сървър ще има до 8 TB оперативна памет. При използването на DDR4-3200 с 16 канала на паметта, сървърът ще има пропускателна способност на паметта около 200 Gb/s за всяко от своите ядра.

Що се отнася до входно/изходните операции, то всеки CPU поддържа до 64 линии PCIe gen 4. При общ брой 128 линии PCIe от 4-то поколение този сървър може да поддържа и работи с 30  бързи NVMe флаш диска плюс една мрежова карта. Един от важните компоненти в тази снимка е мрежовата карта в горния десен ъгъл. Най-вероятно скоростта на мрежовата връзка на тази машина е между 50 и 100 Gb/s.

Възможностите на този сървър

Ето на какво е способен този сървър:

• Споделяне на видеофайлове със скорост 400 Gb/s (поправка, вече е 800 Gb/s)
• 1 милион IOPS при NoSQL база данни
• 70 хиляди IOPS при PostgreSQL
• Половин милион запитвания в секунда при nginx
• Компилиране на Linux ядрото за 20 секунди
• Рендиране на 4К видео с помощта на x264 кодек при скорост 75 FPS

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

Цената на подобен сървър

От големия хостинг доставчик OVHCloud можете да вземете под наем сървъра HGR-HCI-6 със 128 физически/256 логически ядра, 512 GB оперативна памет и пропускателна способност 50 Gb/s при цена $1318 месечно.

От популярния бюджетен хостинг доставчик Hetzner може да се наеме сървър с 32 ядра и 128 GB оперативна памет при цена 140 евро на месец. Това е много по-малък сървър с размери едва една четвърт от предишния, но дава представа за ценовата вариация между доставчиците.

В AWS от друга страна, един от най-големите сървъри, който може да бъде нает е M6a.metal. Той предлага пропускателна способност от 50 Gb/s, 192 vCPU (96 физически ядра) и 768 GB оперативна памет. Само че неговата цена в източния регион на САЩ е $8,294 на час. Или около $6055 на месец.

А аналогичен съвсем реален, а не виртуален сървър със 128 физически ядра и 512 GB оперативна памет плюс съответните мрежови карти и флаш дискове плюс договор за техническа поддръжка, може да бъде купен директно от сайта на Dell при цена приблизително $40 000. Ясно е, че на подобно ниво цената подлежи на договаряне и продавачът със сигурност ще направи отстъпка. А тя може да се използва за монтирането на сървъра и неговото мрежово включване.

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

Размисли за електронния облак

„Облачната ера“ започна някъде в началото на 2010 година. Тогава най-съвременни бяха „Зийоните“ с архитектура Nehalem с поддръжката на наскоро измислената „хиперпоточност“ (най-мощната сървърна фамилия Xeon 6500/7500 (Beckton) имаше 8 физически/16 логически ядра).

По това време нямаше хардуерно AES криптиране, а процесорът използваше векторни инструкции с размер едва 128 бита. Най-големите процесори имаха 24 MB кеш, а сървърът можеше да адресира максимум 256 GB оперативна памет тип DDR3-1066. За записването и съхранението на данните Seagate представи хард диск с капацитет 3 GB. Всяко ядро даваше 4 FLOPS на цикъл – тоест, 8-ядреният сървър с тактова честота 2,5 Ghz осигуряваше максимум 80 GFLOPS.

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

Оттогава мощността на сървърите значително нарасна, а SSD ускориха входно/изходните операции с над 100 пъти, но размерът на стандартните VM и на контейнерите на практика не се промени. Ние  както преди продължаваме да използваме виртуални дискове, които повече приличат на HDD, отколкото на SSD (последно време има напредък в това отношение).

Обикновено е достатъчен един сървър (плюс бекъп)

Ако не се занимаваме с обработката на поточно видео, а системата обработва под 10 000 заявки в секунда, то един сървър е напълно достатъчен. При действително несложните приложения той може да осигури до един милион QPS. Твърде малко са уеб услугите с подобен трафик. За примерна оценка на възможностите на системите от този род се предлагат таблици с бенчмарковете на най-типичните задачи (specbranch.com/posts/common-perf-numbers).

Големите сървъри и сривовете

Главният недостатък от използването на един голям сървър е недостатъчната резерва и надеждност. Сървърът може да се срине, може да се повреди. Обикновено препоръката е да има основен и резервен сървър в различни дата центрове. 

Конфигурацията 2х2 би трябвало да успокои параноиците: два сървъра в основния център за обработка на данните (или при облачния провайдър) плюс два резервни сървъра от друг провайдър или център. Ако искате да използвате дори и трети възел, то той може да бъде много по-малък от двата основни.

Дори и при подобна конфигурация има риск от едновременен хардуерен срив. Известно е, че HDD и SSD сравнително често едновременно излизат от строя, ако са от една и съща партида. Опитните системни администратори на онлайн услуги от нивото на Backblaze купуват многобройни, но различни модели SSD и HDD  от различни производители и по този начин не допускат създаването на хомогенна среда.

Ако вашият доставчик ви дава под наем готови сървъри, то има смисъл да се вземат различни типове сървъри в основния Център за обработка на данните, като и в резервния. Това ще осигури защита от различните видове корелирани сривове.

Защо да плащаме за пиковото натоварване

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

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

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

Като цяло, колкото повече пикове има в натоварването, толкова по-облачна архитектура трябва да се използва.

Цената на електронния облак

Облачната архитектура е скъпа. Като правило, можете да очаквате увеличение на разходите от 5 до 30 пъти в зависимост от това, какви услуги на електронния облак използвате – базови или от високо ниво. Не става дума за 5-30%, а за от пет до тридесет пъти по-големи разходи.

Ето един пример – AWS:  $0,20 за един милион заявки плюс $0,0000166667 за използването на 1 GB в секунда оперативна памет. Това са цените за X86, за да може да бъде направено сравнение със споменатия по-горе M6a.metal. Интересно е, че големите ARM сървъри и безсървърните ARM изчисления са по-евтини.

Да предположим, че сървърът струва $8,2944 на час и обработва 1000 QPS с 768 GB оперативна памет.

• 1000 QPS са 60 000 заявки в минута или 3,6 милиона заявки на час
• Всяка заявка получава по  0,768 GB в секунда оперативна памет
• Подобен обем облачни изчисления ще струва около $46/час

Могат да бъдат дадени и други примери, които са твърде сходни.

При електронните облаци няма системни администратори

Така е. Само че те сега се наричат Cloud Ops и работят под ръководството на друг мениджър. Те трябва добре да разбират сложната документация на облачните компании и да следят за всички обновявания, които при облачните технологии текат като поток. Ето защо те печелят над пет пъти повече от системните администратори.

Изводи

Когато растете и вече сте стигнали предела на възможностите на днешните сървъри е по-добре да преминете към облачна архитектура, където мащабирането е заложено още при нейното проектиране.

От друга страна, използването на един голям физически сървър излиза много евтино. Разходите не са големи, а  надеждността е съвсем достойна, ако има нормално архивиране и са взети мерки срещу корелационните хардуерни сривове. Това не е много бляскаво и едва ли ще озари вашето CV, но един сравнително голям и мощен сървър ще ви свърши перфектна работа.