Архитектури за балансиране на натоварването на сървъра, Част 1: Балансиране на натоварването на транспортно ниво

Сървърните ферми постигат висока мащабируемост и висока наличност чрез балансиране на натоварването на сървъра, техника, която кара сървърната ферма да се показва на клиентите като един сървър. В тази статия от две части Грегор Рот изследва архитектури за балансиране на натоварването на сървъра, с акцент върху решенията с отворен код. Част 1 обхваща основите за балансиране на натоварването на сървъра и обсъжда плюсовете и минусите на балансирането на натоварването на сървъра на транспортно ниво. Част 2 обхваща архитектури за балансиране на натоварването на ниво приложение, които се отнасят до някои от ограниченията на архитектурите, обсъдени в Част 1.

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

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

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

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

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

Наличност и мащабируемост

Балансирането на натоварването на сървъра разпределя заявки за услуги в група реални сървъри и прави тези сървъри да изглеждат като един голям сървър за клиентите. Често десетки реални сървъри стоят зад URL адрес, който реализира една виртуална услуга.

Как работи това? В широко използваната архитектура за балансиране на натоварването на сървъра, входящата заявка е насочена към специален балансир на натоварването на сървъра, който е прозрачен за клиента. Въз основа на параметри като наличност или текущо натоварване на сървъра, балансьорът на натоварването решава кой сървър трябва да обработи заявката и я препраща към избрания сървър. За да предостави на алгоритъма за балансиране на натоварването необходимите входни данни, балансиращият товар също извлича информация за състоянието и натоварването на сървърите, за да провери дали те могат да реагират на трафика. Фигура 1 илюстрира тази класическа архитектура за балансиране на натоварването.

Архитектурата на диспечера на натоварване, илюстрирана на фигура 1, е само един от няколкото подхода. За да решите кое решение за балансиране на натоварването е най-доброто за вашата инфраструктура, трябва да вземете предвид наличността и мащабируемостта .

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

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

В сценария на Фигура 1 се постига висока мащабируемост чрез разпределяне на входящата заявка през сървърите. Ако натоварването се увеличи, могат да се добавят допълнителни сървъри, стига балансьорът на товара да не се превърне в пречка. За да достигне висока наличност, балансиращият товар трябва да наблюдава сървърите, за да избегне препращането на заявки към претоварени или мъртви сървъри. Освен това самият балансьор на товара също трябва да е излишен. Ще обсъдя този въпрос по-късно в тази статия.

Техники за балансиране на натоварването на сървъра

Като цяло решенията за балансиране на натоварването на сървъра са два основни типа:

  • Балансиране на натоварването на транспортно ниво - като DNS-базиран подход или балансиране на натоварването на ниво TCP / IP - действа независимо от полезния товар на приложението.
  • Балансирането на натоварване на ниво приложение използва полезния товар на приложението, за да взема решения за балансиране на натоварването.

Решенията за балансиране на натоварването могат допълнително да бъдат класифицирани в базирани на софтуер балансиращи натоварвания и хардуерно-балансиращи товара. Базираните на хардуер балансиращи натоварването са специализирани хардуерни кутии, които включват специфични за приложението интегрални схеми (ASIC), персонализирани за конкретна употреба. ASIC позволяват високоскоростно препращане на мрежов трафик без режийни разходи на операционна система с общо предназначение. Хардуерно-балансиращите натоварвания често се използват за балансиране на натоварването на транспортно ниво. Като цяло хардуерно-балансиращите натоварвания са по-бързи от софтуерните решения. Техният недостатък е тяхната цена.

За разлика от хардуерните балансиращи натоварвания, базираните на софтуер балансиращи натоварвания работят на стандартни операционни системи и стандартни хардуерни компоненти като компютри. Решенията, базирани на софтуер, се изпълняват или в специален хардуерен възел за балансиране на натоварването, както е показано на фигура 1, или директно в приложението.

Базирано на DNS балансиране на натоварването

Базираното на DNS балансиране на натоварването представлява един от ранните подходи за балансиране на натоварването на сървъра. Интернет системата за имена на домейни (DNS) свързва IP адресите с име на хост. Ако въведете име на хост (като част от URL адреса) във вашия браузър, браузърът изисква DNS сървърът да разреши името на хоста до IP адрес.

Базираният на DNS подход се основава на факта, че DNS позволява да бъдат присвоени множество IP адреси (реални сървъри) на едно име на хост, както е показано в примера за търсене на DNS в Листинг 1.

Листинг 1. Примерно DNS търсене

>nslookup amazon.com Server: ns.box Address: 192.168.1.1 Name: amazon.com Addresses: 72.21.203.1, 72.21.210.11, 72.21.206.5

Ако DNS сървърът реализира кръгъл подход, редът на IP адресите за даден хост се променя след всеки DNS отговор. Обикновено клиенти като браузъри се опитват да се свържат с първия адрес, върнат от DNS заявка. Резултатът е, че отговорите на множество клиенти се разпределят между сървърите. За разлика от архитектурата за балансиране на натоварването на сървъра на Фигура 1, не се изисква хардуерен възел за междинен балансиращ товар.

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

Макар и лесен за изпълнение, DNS подходът има сериозни недостатъци. За да намали DNS заявките, клиентът има склонност да кешира DNS заявките. Ако сървърът стане недостъпен, клиентският кеш, както и DNS сървърът ще продължат да съдържат мъртъв адрес на сървъра. По тази причина DNS подходът не прави много за прилагане на висока наличност.

Балансиране на натоварването на TCP / IP сървър

TCP / IP сървърните балансиращи устройства работят на ниско ниво на превключване на слоя. Популярен базиран на софтуер балансиращ натоварването на сървър на ниско ниво е Linux Virtual Server (LVS). Истинските сървъри се появяват на външния свят като един "виртуален" сървър. Входящите заявки за TCP връзка се препращат към реалните сървъри от балансиращия товар, който изпълнява ядро ​​на Linux, закърпено, за да включва код на IP Virtual Server (IPVS).

За да се осигури висока наличност, в повечето случаи се създават чифт възли на балансиращия товар, с един възел за балансиране на товара в пасивен режим. Ако балансиращ товар не успее, програмата за сърдечен ритъм, която се изпълнява и на двата балансиращи товара, активира пасивния възел за балансиране на товара и инициира поглъщането на виртуалния IP адрес (VIP). Докато сърдечният ритъм е отговорен за управлението на отказоустойчивост между балансиращите натоварвания, прости скриптове за изпращане / очакване се използват за наблюдение на здравето на реалните сървъри.

Прозрачността за клиента се постига чрез използване на VIP, който е присвоен на балансиращия товар. Ако клиентът издава заявка, първо исканото име на хост се превежда във VIP. Когато получи пакета на заявката, балансьорът на товара решава кой реален сървър трябва да обработва пакета на заявката. Целевият IP адрес на пакета на заявката се пренаписва в реалния IP (RIP) на реалния сървър. LVS поддържа няколко алгоритми за планиране за разпространение на заявки до реалните сървъри. Често е настроен да използва планиране с кръгови програми, подобно на DNS-базирано балансиране на натоварването. При LVS решението за балансиране на натоварването се взема на ниво TCP (слой 4 от референтния модел на OSI).

След като получи пакета на заявката, реалният сървър го обработва и връща пакета за отговор. За да принуди пакета за отговор да бъде върнат чрез балансиращото натоварване, реалният сървър използва VIP като свой маршрут за отговор по подразбиране. Ако балансиращият товар получи пакета за отговор, IP източникът на пакета за отговор се пренаписва с VIP (OSI Модел слой 3). Този режим на маршрутизиране на LVS се нарича маршрутизиране на мрежови адреси (NAT). Фигура 2 показва изпълнение на LVS, което използва NAT маршрутизация.

LVS поддържа и други режими на маршрутизиране, като Direct Server Return. В този случай пакетът с отговори се изпраща директно до клиента от реалния сървър. За да направите това, VIP трябва да бъде присвоен и на всички реални сървъри. Важно е да направите VIP сървъра неразрешим за мрежата; в противен случай балансьорът на товара става недостижим. Ако балансиращият товар получи пакет заявка, MAC адресът (OSI модел слой 2) на заявката се пренаписва вместо IP адреса. Реалният сървър получава пакета на заявката и го обработва. Въз основа на IP адреса на източника, пакетът за отговор се изпраща директно до клиента, заобикаляйки балансиращия товар. За уеб трафика този подход може да намали драстично натоварването на балансьора. Обикновено се прехвърлят много повече пакети за отговор, отколкото пакетите за заявки. Например, ако поискате уеб страница, често се изпраща само един IP пакет. Ако се иска по-голяма уеб страница,за прехвърляне на заявената страница са необходими няколко IP пакета за отговор.

Кеширане

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

Въз основа на алгоритъма за планиране на балансиращия товар, заявките на потребителска сесия се обработват от различни сървъри. Ако кешът се използва от страна на сървъра, отклоняващите се заявки ще се превърнат в проблем. Един подход за справяне с това е поставянето на кеша в глобално пространство. memcached е популярно решение за разпределен кеш, което осигурява голям кеш на множество машини. Това е разделен, разпределен кеш, който използва последователно хеширане, за да определи кеш сървъра (демон) за даден запис в кеша. Въз основа на хеш кода на кеш ключа, клиентската библиотека винаги съпоставя един и същ хеш код на същия адрес на кеш сървъра. След това този адрес се използва за съхраняване на записа в кеша. Фигура 3 илюстрира този подход за кеширане.

Листинг 2 използва spymemcached, memcachedклиент, написан на Java, за кеширане на HttpResponseсъобщения на множество машини. В spymemcachedбиблиотеката изпълнява изисква логиката на клиента аз току-що описах.

Листинг 2. Кеш памет HttpResponse на базата на memcached