Една дълготрайна информационна система трябва да бъде мащабируема (~ преоразмеряване), т.е. известен растеж без пренаписване на целия програмен код и подмяна на цялото оборудване.
Системата може да бъде мащабирана в три посоки: 1) размер (допълнителни потребители, ресурси), 2) географски обхват, 3) администрация (в много административно независими организации).
С други думи, мащабируемостта включва няколко типа растеж: броят на потребителите в мрежата, размерът на базата данни, сложността на транзакциите, появата на нови приложения.
Броят на потребителите в мрежата. Ако се удвои, тогава най-вероятно натоварването на мрежата и базата данни също ще се удвои.
Размер на базата данни. Тъй като базата данни нараства до десетки и стотици гигабайти, операциите по архивиране, възстановяване и зареждане ще се превърнат в пречка.
Сложност на сделките. Разработчиците на приложения ги правят все по-"умни", улесняват работата на потребителите, като им дават възможност да анализират данни. Но в същото време броят на връзките на данни нараства експоненциално, в резултат на което, първо, се увеличава сложността на писане и следователно вероятността от грешки се увеличава. И, второ, при извършване на такава транзакция системата трябва да обработи голямо количество данни, което може да е практически невъзможно за дадена мощност на процесора, количество RAM и т.н. Което от своя страна изисква писането на някои специални алгоритми за качване на данни, кеширане и т.н.
Появата на нови приложения. Потребителите започват да използват компютъра в нови области, което увеличава натоварването на съществуващите сървъри. Освен това е необходимо да се организира интегрирането на приложенията.
Разширяващите се системи могат да използват един (или и двата!) принципа за увеличаване на капацитета на изчислителната система: многопроцесорна, клъстерна технология.
Мащабируемите системи решават проблемите с централизацията, описани по-горе, като увеличават размера и капацитета на мрежите, сървърите, базите данни и приложенията чрез просто добавяне на хардуер. Мащабируемите интегрални схеми осигуряват пътища за растеж, които увеличават мощността без препрограмиране на приложения или поне без пълно препрограмиране.
Застанете на пътя на мащабируемостта
централизирани услуги,
централизирани данни,
централизирани алгоритми.
Централизираната услуга предполага, че дадена услуга (програма) се намира само на един компютър. Ако обажданията към тази услуга от различни клиенти се случват рядко и не едновременно, тогава това е напълно приемливо решение. В противен случай такава услуга ще бъде тясното място на системата. За да бъде централизирана услуга по-малък проблем, трябва да използвате високоскоростни комуникационни линии, а компютърът, на който се намира тази услуга, трябва да е достатъчно бърз, да има достатъчно RAM и достатъчно буфери. Безспорното предимство на такава услуга е, че е по-лесно да се актуализира. Ако услугата е процес, който изисква много изчислителни ресурси за изпълнение, тогава може да бъде много по-полезно тези ресурси да са налични само на един компютър, а не на множество клиенти. Но, от друга страна, често, когато централизирана услуга се срине, системата като цяло губи своята функционалност.
Пример за централизирана услуга би бил процесът на дефиниране на правата и разрешенията на мрежовите потребители. Вероятно сте забелязали, че когато много потребители влизат в мрежата по едно и също време сутрин, има временно А забавям се. Ако влезете в мрежата в средата на деня, това се случва бързо. Ако домейн контролерът се повреди, тогава ще остане само възможността за работа с локалния компютър.
В една мащабируема система се предлага да се използват децентрализирани услуги. Това може да се постигне по два начина: или чрез репликиране (копиране) на услугата на множество компютри, или (ако е възможно) чрез разделяне на услугата на отделни задачи, разпространявайки съответните фрагменти между различни компютри. Пример: в достатъчно голяма локална мрежа се препоръчва да има DHCP сървър (който наема IP адреси), а съхранението на роуминг профили се намира не на домейн контролер, а на отделен компютър (разбира се, включен на правилното време).
Често централизираната услуга се свързва с централизирани данни. Централизираните данни често са по-лесни за защита (по-лесно за архивиране). Но обемът на такива данни може да бъде толкова голям, че никаква разумна изчислителна мощност не е достатъчна. Намирането на правилните данни често е по-трудно в централизираните хранилища. От една страна, времето за търсене нараства с нарастването на съхранението. От друга страна, в случай на централизирано хранилище, наборът от функции - параметри за търсене - нараства, тъй като голям брой различни задачи работят с данни. За централизираните данни е много важно да се правят архивни копия, за да се намалят възможните загуби, ако централизираното хранилище се повреди. Пример за централизирани данни е сървър на база данни (MY SQL, MS SQL и др.).
Една мащабируема система трябва да работи с децентрализирани данни. Добър пример е услугата DNS, която преобразува символичното име на мрежов ресурс към неговия IP адрес. Архитектурата на дървото на DNS сървъра ви позволява да разделяте информацията на фрагменти, всеки от които се поддържа от един сървър. Установява се връзка между сървърите и се определя протокол за взаимодействието им. Осигуряването на тази връзка е цената на използването на децентрализирано съхранение. Децентрализираното съхранение има някои интересни свойства: неравен достъп до информация. За да изгладят тези разлики, тоест за да ускорят поне повторния достъп до отдалечени данни, DNS сървърите използват кеширане на информация. Но помните, че кеширането води до проблема с несъответствието на данните. Проблемите, които възникват по време на децентрализацията на данните, основната от които е несъответствието на данните на различни компютри, ще бъдат разгледани малко по-късно. Нека анализираме 13 модела на последователност.
Централизираният алгоритъм също е лош за разпределена система. Един алгоритъм може да се счита за централизиран, ако за да го завърши, тоест да вземе решение, той изисква пълна информация, получена от преки източници. Припомнете си алгоритмите за маршрутизиране, изучавани в курса Информационни мрежи. Помислете, като пример за централизиран алгоритъм, „протокола за състоянието на канала“. Този алгоритъм предполага, че таблицата рутер контактува с всеки рутер. Това води до предаване на огромен брой сервизни пакети. Този алгоритъм е взискателен към ресурсите на рутера и в мрежата, въпреки че се оказва слабо чувствителен към изчезването на рутера. Алгоритъмът "протокол за вектор на разстояние" не се прилага за централизирани алгоритми, тъй като за да вземе решение (да изгради своя собствена таблица за маршрутизиране), рутерът трябва да се свърже само със своите съседи. Този алгоритъм заема много по-малко мрежата, но може да вземе грешно решение, когато рутерът изчезне (проблемът с нарастващото разстояние до безкрайност)
Технологии, използвани за създаване на мащабируеми системи: скриване на латентността на комуникацията, разпространение, репликация.
Скриването на изчакване често се осъществява чрез асинхронна комуникация, при която процесът, който е поискал отдалечената услуга, върши известна работа (независимо от очаквания отговор), докато отговорът пристигне. За да се реализира това, е организирано многонишково приложение, една от нишките (нишките) на което при заявка се блокира и чака отговор, тоест работи с отдалечената услуга синхронно и останалите нишки работят асинхронно, тоест продължават изпълнението. Но не винаги е възможно да се организира асинхронно изпълнение, например, когато потребител взаимодейства с отдалечена база данни. В този случай се препоръчва да се организира поне частична проверка на данните от страна на клиента с помощта на скриптове, като по този начин се намали броят на обажданията към отдалечената база данни и следователно се намали времето за изчакване на клиента.
Втората важна техника за мащабиране е разпределението. Вече споменахме разпределената DNS услуга. Важен аспект от внедряването на разпространение на данни е именуването. Проблемът е, че имената трябва да са уникални, т.е. изисква се пространството от имена да се организира по един или друг начин. Както при файловете, всеки интернет обект трябва да има уникално напълно квалифицирано име, което включва имената на DNS сървърите от обекта до корена на DSN.
И накрая, третата технология е репликацията. Репликацията копира всички или част от споделените данни на множество компютри. В резултат на това данните могат да бъдат доближени до потребителя, като по този начин се намалява времето за достъп, намалявайки натоварването на компютрите, които поддържат съхранение. Цената на подобно решение е необходимостта от осигуряване на последователност на данните. Трябва да се прави разлика между репликация и кеширане. Репликацията се извършва по инициатива на сървъра на данни (собственика), а кеширането се извършва по инициатива на клиента (потребителя).
Ако се занимаваме с кеширане, тогава клиентът (например Internet Explorer) трябва независимо да следи уместността на данните. Механизмите, използвани за това са: а) заявки за актуализиране на данни след определено време, б) заявки за релевантност (неизменност на сървъра). В първия случай може да се предават непроменени данни, което ненужно натоварва мрежата. А във втория клиентът първо открива дали данните са се променили и едва ако са се променили, изпраща заявка за прехвърляне на данните. Очевидно е, че ако данните се променят рядко, тогава е за предпочитане да използвате втория метод, в противен случай първият. Сега - няколко думи за последователността. Поради факта, че в една разпределена система може да има различни клиенти, които изискват различна степен на „свежест“ за различни данни, различните данни имат различно време за актуализиране и други характеристики и прехвърлянето на данни е скъпо, в различни случаи ще са необходими различни методи осигурете последователност.
Възможността за мащабиране на информационна система - както хоризонтално, така и вертикално - е един от най-важните фактори, на които трябва да обърнете внимание при избора на средство за автоматизиране на дейността на всяка организация. Ако избраното решение не може да бъде мащабирано или всеки етап от растежа на бизнеса ще доведе до затруднения с поддръжката и развитието на такъв софтуерен продукт, тогава не трябва дори да започвате да го използвате. Разработихме LETOGRAF EDMS с оглед на високите изисквания за мащабиране.
Необходимостта от хоризонтално или вертикално мащабиране възниква във връзка със създаването на корпоративни ИТ системи с високо натоварване, които наемат хиляди или дори десетки хиляди потребители. Въпреки това, не всички EDMS могат да поддържат едновременната работа на голям брой потребители. Само ако EDMS на ниво архитектура има способността да увеличава броя на потребителите без загуба на производителност - само в този случай мащабирането ще бъде успешно. Системата LETOGRAPH, която създадохме, е проектирана да мащабира перфектно както хоризонтално, така и вертикално. Това се постига както благодарение на архитектурата на самата система и кода на приложението, който разработихме, така и благодарение на функционалността на InterSystems Caché DBMS, върху която е изградена нашата EDMS.
Caché DBMS е модерна система за управление на база данни и среда за бързо разработване на приложения. В основата на тази СУБД е технология, която осигурява скорост и висока производителност, мащабируемост и надеждност. В същото време хардуерните изисквания на системата остават доста скромни.
СУБД Caché поддържа висока производителност дори при работа с огромни количества данни и голям брой сървъри в разпределени системи. В същото време данните се достъпват чрез обекти, високопроизводителни SQL заявки и чрез директна обработка на многоизмерни структури от данни.
Вертикално мащабиране
Вертикалното мащабиране включва увеличаване на капацитета на сървъра и неговите възможности, свързани с дисковата подсистема. LETOGRAF поддържа модерна процесорна архитектура, която позволява обработка на големи количества данни в множество нишки. В същото време самите данни в EDMS са организирани по такъв начин, че да могат лесно да бъдат разпределени в системата за съхранение на различни дискове. Този подход ви позволява да разпределите равномерно натоварването върху хранилищата на данни и да го минимизирате при четене на данни директно от базата данни, което означава, че може да се избегне спад в производителността на системата дори при голям брой потребители, работещи едновременно.
Още на етапа на разработване на платформата разбрахме, че вертикалното мащабиране е една от ключовите характеристики на системата, нуждата от която ще нараства само с времето. Ние сме разработили системата по такъв начин, че работните процеси на всеки потребител са разделени на отделни системни процеси, които не се пресичат помежду си поради факта, че базите данни ефективно споделят достъпа до информация. В същото време броят на заключванията на данни в LETOGRAF EDMS е сведен до минимум и няма „тясно място“ нито при четене на данни, нито при запис.
Архитектурата на LETOGRAF EDMS позволява разпространение на данни към няколко физически или виртуални сървъра. Благодарение на това разпространение всеки от потребителите работи в изолиран процес, а необходимите данни се кешират ефективно с помощта на технологиите Caché DBMS. Времето за блокиране на данни е сведено до минимум: всички транзакции са изградени по такъв начин, че да прехвърлят данни в изключителен режим на достъп само за много кратко време. В същото време дори данни, които са силно натоварени по отношение на броя достъпи до диска, като регистрационни файлове, индекси, обектни данни, потоци, регистрационни файлове за потребителска активност, се разпределят по такъв начин, че средното натоварване на подсистемата остава еднакво и не води до забавяне. Този подход ви позволява ефективно вертикално да мащабирате системата чрез разпределяне на натоварването между сървъри или виртуални дискове.
Хоризонтално мащабиране
Хоризонталното мащабиране е разпределението на потребителските сесии между различни сървъри (равномерно зареждане на сървъри за приложения и възможност за свързване на допълнителни сървъри за приложения), както и разпределението на данни между различни сървъри на бази данни, което гарантира висока производителност на системата, без да се намалява толерантността към грешки. За хоризонтално мащабиране системата LETOGRAF предоставя редица опции.
На първо място, това е мащабиране на натоварването благодарение на Enterprise Cache Protocol (ECP, Distributed Cache Protocol), протоколът, използван в InterSystems Caché DBMS. Силата на ECP се крие в неговия новаторски подход към кеширането на данни. В рамките на този протокол потребителските процеси, които се изпълняват на сървърите на приложения (или ECP клиенти) на СУБД и обслужват заявки, получават достъп до локален кеш на наскоро използвани данни. И само ако тези данни не са достатъчни, ECP клиентът осъществява достъп до базата данни. ECP протоколът извършва автоматично управление на кеша: най-често използваните данни се съхраняват в кеша, често актуализираните данни се репликират периодично, като се гарантира постоянна цялост на данните и коректност на всички ECP клиенти. Вътрешният алгоритъм на InterSystems Caché предполага, че базите данни са синхронизирани между ECP клиента и ECP сървъра.
Всъщност използването на технологиите Caché DBMS ви позволява лесно и бързо да мащабирате натоварването на сървърите на приложения, като по този начин гарантирате, че голям брой потребители са свързани към един сървър на база данни, използвайки ECP протокола.
Тъй като информацията, поискана от конкретен потребител, може да се използва на няколко ECP клиента, е необходимо данните да се заключат за кратък период от време, бързо да се изпълняват транзакции, без да се извършват вътрешни изчисления. И ние успешно го реализирахме. Тази технология ни позволява ефективно да мащабираме системата в ситуация, в която се използват един сървър на база данни и няколко сървъра, на които се изпълняват потребителски процеси. Технологичната характеристика на СУБД Caché е, че поддържа коректността на транзакциите в рамките на един ECP сървър, независимо от броя на ECP клиентите, които са свързани към него. В случай, че имаме един ECP сървър и много ECP клиенти, тази задача е идеално решена, тъй като всички транзакции вървят на един и същ сървър на база данни.
Опитът показва, че дори при силно натоварени системи винаги е възможно ясно да се разделят данните между сървърите на бази данни въз основа на определени характеристики. Например, ако няколко организации са обединени в холдинг, тогава потребителите от една структурна единица е малко вероятно някога да имат търсене на данни, които се отнасят до друга единица. Това позволява на алгоритмите да разделят и съхраняват такива данни на различни сървъри на бази данни, като по този начин увеличават хоризонталната мащабируемост.
LETOGRAPH EDMS реализира механизъм за шардинг, благодарение на който ние, на ниво системни настройки (без използване на програмиране), позволяваме да опишем правилата и принципите за разпространение на самите данни в различни сървъри на бази данни. Въпреки факта, че от гледна точка на структурата на базата данни, информацията, съхранявана на всеки сървър, е една и съща, самата информация се различава фундаментално в зависимост от организацията или други характеристики, които са важни за конкретна задача. Използвайки технологията за шардинг, може да се постигне, че в 95-99% от случаите потребителите ще работят само със своята „част от данни“ и няма да има нужда от достъп до различни сървъри на бази данни по време на сесията.
Мащабируемостта на LETOGRAPH EDMS също се влияе от факта, че данните могат да се обработват по различен начин. Например, документите (дори тези, създадени преди няколко години) могат да бъдат модифицирани, докато записите се добавят само към регистъра на потребителската активност (нито един запис не може да бъде изтрит или променен). Механизмите, използвани в LETOGRAF EDMS, позволяват допълнително да се повиши производителността на системата и да се подобри мащабирането чрез поддържане на такива журнали на отделни сървъри на бази данни - както в случай на конфигурация с един сървър, така и в случай на много сървъри. Този подход е насочен към намаляване на натоварването на основните сървъри на бази данни.
Подобна ситуация възниква и със съдържанието („информационно съдържание“ на EDMS). Тъй като системата LETOGRAF работи с голямо количество съдържание - това са терабайти данни, милиони файлове и документи - разумно е да се предположи, че съдържанието, което влиза в системата, не трябва да бъде засегнато при никакви обстоятелства. Следователно ние също преместваме съхранението на файлове на отделни сървъри на бази данни и по този начин осигуряваме допълнително хоризонтално мащабиране.
Преден софтуер
Apache и HAProxy се използват като преден край в LETOGRAF EDMS. HAProxy отговаря за балансирането на натоварването между уеб сървърите на Apache. HAProxy, както показва опитът на системата, се е доказал като най-ефективното решение, което може да поддържа работата на голям брой потребители и необходимия контрол върху устойчивостта на грешки.
Когато потребител отвори браузър и се свърже със системата, HAProxy го „разпределя“ към един от сървърите на приложения. Освен това всички заявки, които идват от този потребител, ще бъдат изпратени до същия сървър на приложения в един и същ процес.
Изпробвахме различни системи и тестването показа, че HAProxy е най-ефективният балансьор на натоварването, осигуряващ равномерно разпределение на потребителите в свободните слотове за сървъри на приложения. HAProxy разполага с всички необходими механизми, за да следи състоянието на всеки сървър на приложения и да не разпределя нов трафик към сървър на приложения, който е неуспешен по някаква причина. В допълнение, HAProxy допълнително предоставя редица опции по отношение на кеширане на статични (непроменливи по време на работа на потребителя) данни - например стилове, икони и т.н. - което ви позволява да организирате интерфейса.
Пример за изпълнение на проекта
Архитектурата на LETOGRAF позволява да се постигнат значителни резултати при намаляване на времето за реакция и подобряване на производителността на системата. Като част от един от нашите проекти, 23,5 TB данни се съхраняват в EDMS. От тях 14,7 TB (63%) са за потоци („файлове, прикачени към карти“), 3,5 TB (15%) са за отчетни форми, като отчетни таблици, които се формират в асинхронен режим, могат да се стартират като график, и по искане на потребителя и представлява обобщена таблица, всички данни в която могат да бъдат разбити до обект. Други 1,6 TB (7%) са протокол за потребителски операции, а останалите (16%) са данни и индекси на карти.
Повече от 11 хиляди потребители работят в тази система, 2 хиляди от тях работят едновременно, а в пиковите дни броят на служителите, работещи едновременно в EDS, надхвърля 3 хиляди, Броят на записите в дневника вече надхвърли 5,5 милиарда, а регистрационните карти почти достигнаха половин милиард.
Като сървър на база данни в този проект е инсталиран failover cluster от два физически сървъра с три инсталации на СУБД, както и резервен сървър. Десет сървъра за приложения (и един резервен) обработват потребителски сесии и осигуряват асинхронно отчитане. 2 HAProxy сървъра действат като балансьори. В случай на проблеми с някой от сървърите, неговият IP адрес автоматично се прехвърля към друг сървър. Предвидени са също сървър за индексиране на файлове и сървър за разпознаване (осигуряващ разпознаване на текст на сканирани хартиени документи при поставяне на електронни изображения в системата).
Резюме
LETOGRAPH EDMS осигурява голям брой различни механизми за мащабиране. Ние предлагаме един вид пай, който се базира на сървър (физически или виртуален), на който е инсталирана операционната система. Върху него е InterSystems Caché DBMS, вътре в който се намира кодът на платформата. И вече над него са настройките на системата LETOGRAPH, благодарение на които EDMS е напълно конфигуриран. И такъв пай се поставя на всеки сървър. Сървърите са свързани помежду си по определен начин поради избраните конфигурации. И последният слой е HAProxy, който разпределя потребителските заявки между сървърите. Тази архитектура ни позволява да поддържаме мащабиране и да предоставяме всички необходими механизми за наблюдение. В резултат на това крайните потребители получават бърза EDMS, а ИТ специалистите получават лесна за управление и поддръжка унифицирана система, без огромен брой компоненти, които в случай на силно натоварени приложения трябва да бъдат постоянно наблюдавани и администрирани. . Освен това, в зависимост от променящите се нужди на организацията, LETOGRAF EDMS лесно се преконфигурира чрез добавяне на нови сървъри или дискови възможности.
Този материал е личен запис на член на общността Club.CNews.
Редакторите на CNews не носят отговорност за съдържанието му.
До края на 2012 г. повече от 50% от приложенията, работещи на платформата x86, са виртуализирани. В същото време само 20% от критичните за бизнеса приложения са виртуализирани.
Дали защото ИТ отделите не вярват на платформите за виртуализация? Смятат ли, че платформите за виртуализация не са достатъчно стабилни, за да поддържат критични приложения?
През последните 10 години VMware доказа, че виртуализацията е реалност и всъщност виртуализираните приложения често са по-стабилни, когато работят на инфраструктура, управлявана от VMware.
Тогава, ако доверието или стабилността не са проблем, каква е причината ИТ отделите все още да не са виртуализирали останалите приложения?
мащабиране
Мащабиране или хоризонтално мащабиране - добавяне на нови ресурси към инфраструктурата, например сървъри към клъстер.
Тъй като цените продължават да падат, а производителността се повишава, евтините стокови (потребителски) сървъри са идеални за мащабиране и могат да бъдат сглобени в големи клъстери за обединяване на изчислителни ресурси.
През последните седем години инфраструктурните архитекти във VMware се молят за хоризонтално мащабиране. Някой може да спори за използването на този конкретен подход, но той също има свои собствени нюанси и всичко зависи от изискванията на бизнеса. Предимството на хоризонталното мащабиране е, че стоковите сървъри са евтини и в случай на повреда на сървъра това засяга малък брой виртуални машини. Недостатъкът е по-високата цена на лицензите за vSphere, големите изисквания към площта на центъра за данни и обикновено такива стокови сървъри не разполагат с големи изчислителни ресурси.
увеличавам мащаба
Вертикално мащабиране - добавяне на изчислителни ресурси към някой вече използван сървър. Обикновено това са процесори или RAM.
Обикновено такива сървъри са доста мощни - с поддръжка на 4 процесора и 512GB памет. Освен това има системи с 8 процесора и 1TB памет, а някои имаха късмета да видят дори 16 процесорни сървъри с 4TB памет. И не, това не са мейнфрейми или нещо подобно, това са сървъри, базирани на класическата x86 архитектура.
Преходът към втората вълна на виртуализация, която осигурява гъвкавостта, която тази технология предоставя за критични за бизнеса приложения, в момента оказва огромен натиск върху инфраструктурите на VMware, които се използват днес поради следните проблеми:
- Недостатъчна мащабируемост. Тежките изчислителни натоварвания са проблем поради ограничените ресурси, налични с евтините стокови сървъри.
- Недостатъчна надеждност. Оборудването или хардуерът, използващ такива компоненти, може да бъде по-малко надежден. Проблемът с надеждността може да бъде решен с помощта на функции, които ще разгледам в следващите статии.
- Нарастваща сложност на управлението и нарастващи оперативни разходи. По-лесно е да управлявате 100 сървъра, отколкото 1000 и в резултат на това 10 сървъра са по-лесни за управление от 100. Същото важи и за оперативните разходи - 10 сървъра са много по-евтини за поддръжка от 100.
С пускането на vSphere 5 количеството ресурси, достъпни за една VM, се увеличи 4 пъти.
И с пускането на vSphere 5.1, чудовищните виртуални машини могат да бъдат още по-чудовищни.
За да може vSphere 5.1 да изпълнява чудовищната виртуална машина, планировчикът трябва да има и да планира нишки, които да работят на 64 физически процесора. Няма много сървъри, които могат да поддържат толкова много ядра, а още по-малко са сървърите, които поддържат 16 гнезда и 160 ядра.
Има два вида вертикално мащабиране на сървъра: без лепило и залепено. Тези думи се превеждат на руски, както следва: без интегриращи технологии и съответно с интегриращи технологии.
Архитектура без лепило
Тази архитектура е разработена от Intel и е представена в Intel Xeon E7.
За комуникация между I / O устройства, мрежови интерфейси и процесори се използва специално проектирана QPI шина.
При сървъри с 4 процесора всички те са свързани директно през тази шина. Процесорът без лепило използва един от каналите за свързване на процесора към I/O интерфейси, а останалите три за свързване към съседни процесори.
При 8-процесорен сървър всеки процесор е директно свързан с три съседни, а чрез друг процесор с останалите четири.
Предимствата на тази архитектура:
- Няма нужда от специално развитие или специализация от производителя на сървъра
- Всеки производител на сървъри може да произведе 8 процесорни сървъра
- Цената както на 4, така и на 8 процесорните сървъри е намалена
- Общата цена на притежание нараства с хоризонтално мащабиране
- Архитектурата е ограничена до 8 процесорни сървъра
- Трудно е да се поддържа целостта на кеша, тъй като сокетите растат
- Нелинейно нарастване на производителността
- Съотношението цена/производителност спада
- Подоптимална ефективност при използване на големи виртуални машини
- До 65% от честотната лента на шината се изразходва за излъчване на съобщения на чатливия QPI протокол
Основните приложения, чиято производителност страда от недостатъците на протокола QPI, са Java приложения, големи бази данни, чувствителни към забавяне на приложенията.
Резултатът от вертикалното мащабиране не трябва да бъде тясно място, в противен случай тази архитектура става безсмислена. По този начин линейността на увеличаването на производителността трябва да съответства на линейността на добавянето на ресурси.
Залепена архитектура
За да решат проблемите, описани по-горе, разработчиците на хардуер са разработили залепена архитектура. Тази архитектура използва контролер на външен възел за организиране на взаимното свързване на QPI острови - процесорни клъстери.
Intel QPI предлага специално мащабируемо решение - eXternal Node-Controllers (или XNC), чието практическо внедряване се разработва от OEM компании на трети страни. Контролерът на външния възел, използван, започвайки с Intel Xeon E7-4800, с интегриран контролер на паметта, също включва системата за кохерентен неравномерен достъп до паметта (ccNUMA), чиято задача е да следи уместността на данните в всеки ред от паметта на кеша на процесора беше актуална информация.
Закъсненията между процесора и паметта в ccNUMA зависят от местоположението на тези два компонента един спрямо друг, в резултат на това XNC контролерите стават критичен компонент на сървъра и много малко производители на сървъри могат да разработят сървъри с възможност за мащабиране .
Единни информационни системисе изпълняват, като правило, на самостоятелен персонален компютър (мрежата не се използва). Такава система може да съдържа няколко прости приложения, свързани с общ информационен фонд, и е предназначена за работа на един потребител или група потребители, които споделят едно работно място във времето. Такива приложения се създават с помощта на т.нар работен плот, или местен, системи за управление на бази данни (СУБД). Сред местните СУБД най-известните са Clarion, Clipper, FoxPro, Paradox, dBase и Microsoft Access.
Групови информационни системиса фокусирани върху колективното използване на информация от членовете на работната група и най-често се изграждат на базата на локална мрежа. Тези приложения са разработени с помощта на сървъри за бази данни (наричани още SQL сървъри) за работни групи. Има доста голям брой различни SQL сървъри, както търговски, така и свободно разпространявани. Сред тях най-известните сървъри за бази данни са Oracle, DB2, Microsoft SQL Server, InterBase, Sybase, Informix.
Корпоративни информационни системиса еволюция на системи за работни групи, те са фокусирани върху големи компании и могат да поддържат географски разпръснати възли или мрежи. По принцип те имат йерархична структура от няколко нива. Такива системи се характеризират с архитектура клиент-сървър със специализация на сървъри или многостепенна архитектура. При разработването на такива системи могат да се използват същите сървъри на бази данни, както при разработването на групови информационни системи. В големите информационни системи обаче най-широко използваните сървъри са Oracle, DB2 и Microsoft SQL Server. За групови и корпоративни системи изискванията за надеждност на работа и безопасност на данните са значително повишени. Тези свойства се осигуряват чрез поддържане на целостта на данните, връзките и транзакциите в сървърите на бази данни.
Централизирана база данни или разпределена.
Характеристики на дизайнаМрежа-ориентирани системи в момента
Scrumе набор от принципи, върху които се изгражда процесът на разработка, позволяващ строго фиксирани кратки периоди от време ( спринтове 2 до 4 седмици), за да предостави на крайния потребител работещ софтуер с нови функции, за които се определя най-високият приоритет. Възможностите на софтуера за внедряване в следващия спринт се определят в началото на спринта на етапа на планиране и не могат да бъдат променяни през цялото му времетраене. В същото време строго фиксираната кратка продължителност на спринта дава предвидимост и гъвкавост на процеса на разработка.
ORM- технология за програмиране, която свързва базите данни с концепциите на обектно-ориентираните езици за програмиране, създавайки "виртуална обектна база данни".
Проблем: В обектно-ориентираното програмиране обектите в една програма представляват обекти от реалния свят. Същността на проблема е да се преобразуват такива обекти във форма, в която те могат да бъдат съхранявани във файлове или бази данни и които могат лесно да бъдат извлечени в бъдеще, като същевременно се запазят свойствата на обектите и връзките между тях. Тези обекти се наричат "съхранени" (англ. упорит). Исторически има няколко подхода за решаване на този проблем.
модел-изглед-контролер- софтуерна архитектура, в която моделът на данните на приложението, потребителският интерфейс и контролната логика са разделени на три отделни компонента, така че модификацията на един от компонентите има минимално въздействие върху другите компоненти.
Мащабируемост - способността на устройството да увеличава своята
възможности
чрез увеличаване на броя на функционалните блокове,
извършване на едно и
същите задачи.
Glossary.ru
Обикновено те започват да мислят за мащабиране, когато един
Сървърът не става за работа. Какво точно не прави
справяне? Работата на всеки уеб сървър като цяло се свежда до основното
професия компютърна обработка на данни. Отговор на HTTP (или друга) заявка
включва извършване на някои операции върху някои данни. съответно
имаме две основни единици - това са данни (характеризирани с обема си) и
изчисления (характеризиращи се със сложност). Сървърът може да не успее да се справи с него
работят поради голямото количество данни (може да не се побират физически
сървър), или поради голямо изчислително натоварване. Тук се говори
разбира се, за общото натоварване - сложността на обработката на една заявка може да бъде
малки, но голям брой от тях могат да "запълнят" сървъра.
Основно ще говорим за мащабиране с пример
типичен разрастващ се уеб проект, но описаните тук принципи са приложими и за
други области на приложение. Първо разглеждаме архитектурата на проекта и просто
разпространение на съставните му части на няколко сървъра и тогава ще говорим за
мащабиране на изчисления и данни.
Типична архитектура на сайта
Животът на един типичен уебсайт започва с много проста архитектура
- това е един уеб сървър (обикновено Apache действа в неговата роля),
който се справя с цялата работа по обслужването на HTTP заявки,
идващи от посетители. Той дава на клиентите така наречената "статика", тогава
на диска на сървъра има файлове, които не изискват обработка: снимки (gif,
jpg, png), стилови таблици (css), клиентски скриптове (js, swf). същия сървър
отговаря на запитвания, които изискват изчисления - обикновено това е формирането
html страници, въпреки че понякога изображения и други документи се създават в движение.
Най-често отговорите на такива заявки се генерират от скриптове, написани на php,
perl или други езици.
Недостатъкът на такава проста схема на работа е, че е различна
естеството на заявките (връщане на файлове от диска и изчислителна работа на скриптове)
обработвани от същия уеб сървър. Изчислителните заявки изискват
съхраняват много информация в паметта на сървъра (интерпретатор на скриптов език,
самите скриптове, данните, с които работят) и може да отнеме много
изчислителни ресурси. Издаването на статика, напротив, изисква малко ресурси
процесор, но може да отнеме много време, ако клиентът има нисък
скорост на комуникация. Вътрешните елементи на сървъра на Apache предполагат, че всеки
връзката се обработва от отделен процес. Това е удобно за писане на скриптове.
обаче не е оптимален за обработка на прости заявки. Оказва се, че тежък (от
скриптове и други данни) Процесите на Apache прекарват много време в чакане (първо при получаване
заявка, след това при изпращане на отговор), загуба на памет на сървъра.
Решението на този проблем е разпределението на обработващата работа
заявки между две различни програми - т.е. разделение на frontend и
бекенд. Лек фронтенд сървър изпълнява задачите за връщане на статични и останалите
заявките се пренасочват (прокси) към бекенда, където се извършва формирането
страници. Изчакването на бавни клиенти също се поема от интерфейса и ако използва
мултиплексиране (когато един процес обслужва няколко клиента - т.н
работа, например, nginx или lighttpd), след това не чака почти нищо
разходи.
От другите компоненти на сайта трябва да се отбележи базата данни, в
който обикновено съхранява основните данни на системата - тук най-популярният
безплатни СУБД MySQL и PostgreSQL. Съхранението често е отделно
двоични файлове, съдържащи снимки (например илюстрации за статии
сайт, аватари и снимки на потребители) или други файлове.
Така получихме архитектурна диаграма, състояща се от
няколко компонента.
Обикновено, в началото на живота на сайта, всички компоненти на архитектурата
се намират на един и същи сървър. Ако не успее да се справи с натоварването, тогава
има просто решение - да преместите най-лесно отделящите се части в друга
сървър. Най-лесният начин да започнете с база данни е да я преместите на отделен сървър и
промяна на подробностите за достъп в скриптове. Между другото, в този момент ние сме изправени пред
значението на правилната архитектура на кода. Ако работите с база данни
преместен в отделен модул, общ за целия сайт - тогава коригиране на параметрите
връзките ще бъдат лесни.
Начините за допълнително разделяне на компонентите също са ясни - например можете да преместите фронтенда на отделен сървър. Но обикновено фронтенд
изисква малко системни ресурси и на този етап премахването му няма да даде значителни резултати
повишаване на производителността. Най-често сайтът почива на производителност.
скриптове - генерирането на отговор (html страница) отнема твърде много време.
Следователно следващата стъпка обикновено е мащабиране на бекенд сървъра.
Разпределение на изчислението
Типична ситуация за разрастващ се сайт е базата данни да е вече
преместен на отделна машина, завършено разделяне на фронтенд и бекенд,
трафикът обаче продължава да се увеличава и бекендът няма време за обработка
заявки. Това означава, че трябва да разпределим изчисленията на няколко
сървъри. Лесно е да се направи - просто купете втори сървър и го поставете
има програми и скриптове, необходими за работата на бекенда.
След това трябва да се уверите, че потребителските заявки се разпространяват
(балансиран) между получените сървъри. За различните начини за балансиране
ще бъдат обсъдени по-долу, но засега отбелязваме, че интерфейсът обикновено прави това,
който е конфигуриран така, че да разпределя равномерно заявките между
сървъри.
Важно е всички бекенд сървъри да могат да работят правилно
отговарят на запитвания. Това обикновено изисква всеки от тях да работи с тях
същия действителен набор от данни. Ако съхраняваме цялата информация в едно
база данни, самата СУБД ще осигури споделяне на данни и последователност.
Ако някои данни се съхраняват локално на сървъра (например php сесии
клиент), тогава трябва да помислите за преместването им в споделено хранилище или за повече
сложен алгоритъм за разпределяне на заявки.
Можете да разпределите не само работа върху няколко сървъра
скриптове, но и изчисления, извършвани от базата данни. Ако СУБД прави много
сложни заявки, заемащи процесорно време на сървъра, можете да създадете няколко
копия на базата данни на различни сървъри. Това повдига въпроса за синхронизацията.
данни за промените, като тук са приложими няколко подхода.
- Синхронизация на ниво приложение. В този случай нашата
скриптове независимо пишат промени във всички копия на базата данни (и самите те носят
отговорност за верността на данните). Това не е най-добрият вариант, защото
изисква внимателно изпълнение и е силно податлив на грешки. - репликация- тоест автоматична репликация
промени, направени на един сървър във всички останали сървъри. Обикновено когато
Използвайки репликация, промените винаги се записват на един и същ сървър - той се нарича master, а останалите копия се наричат slave. Повечето СУБД имат
вградени или външни средства за организиране на репликация. Разграничете
синхронна репликация - в този случай заявката за промяна на данните ще изчака,
докато данните се копират на всички сървъри и едва тогава ще завърши успешно - и асинхронно - в този случай промените се копират на подчинените сървъри от
латентност, но заявката за запис завършва по-бързо. - Мулти-майсторрепликация. Този подход е подобен
предишния, но тук можем да променим данните, като се позоваваме на не
един конкретен сървър, но към всяко копие на базата данни. В същото време промените
синхронно или асинхронно да стигнат до други копия. Понякога тази схема се нарича
термин "клъстер на база данни".
Има различни опции за разпространение на системата между сървърите.
Например, може да имаме един сървър на база данни и няколко бекенда (много
типична схема), или обратното - един бекенд и няколко бази данни. Ами ако мащабираме
както бекенд сървъра, така и базата данни, тогава можете да обедините бекенда и копието на базата данни в
една кола. Във всеки случай, след като имаме множество екземпляри
всеки сървър, възниква въпросът как правилно да се разпределят между тях
натоварване.
Методи за балансиране
Да предположим, че сме създали няколко сървъра (всяка цел - http, база данни и т.н.), всеки от които може да обработва заявки. Преди
изправени сме пред задачата как да разпределим работата между тях, как да разберем на кои
сървър за изпращане на заявка? Има два основни начина за разпространение на заявки.
- Балансиращ възел. В този случай клиентът изпраща заявка за такъв
известен му фиксиран сървър и той вече пренасочва заявката към един от
работещи сървъри. Типичен пример е сайт с един frontend и няколко
бекенд сървъри, към които се изпращат заявки. Клиентът обаче може
да бъде в нашата система - например скрипт може да изпрати заявка до
прокси за база данни, който ще препрати заявката към един от СУБД сървърите.
Самият балансиращ възел може да работи както на отделен сървър, така и на един
от работещи сървъри.Предимствата на този подход са
че клиентът не трябва да знае нищо за вътрешната структура на системата – за броя
сървъри, техните адреси и характеристики - цялата тази информация е известна само
балансьор. Недостатъкът обаче е, че балансиращият възел е единичен
точка на отказ на системата - ако тя се повреди, цялата система ще бъде
неработоспособен. Освен това при голямо натоварване балансьорът може просто да спре да работи.
се справят с работата си, така че този подход не винаги е приложим. - Балансиране от страна на клиента. Ако искаме да избегнем
единична точка на отказ, има алтернатива - да се повери изборът на сървър
самият клиент. В този случай клиентът трябва да е наясно с вътрешната структура на нашата
системи, за да можете да изберете правилно към кой сървър да се свържете.
Безспорното предимство е липсата на точка на повреда - ако една от
сървъри, клиентът ще може да се свързва с други. Цената за това обаче е
усложняване на клиентската логика и по-малка гъвкавост на балансиране.
Разбира се, има и комбинации от тези подходи. Например,
на такъв добре познат метод за балансиране на натоварването като DNS балансирането се основава
че при определяне на IP адреса на сайта клиентът се дава
адреса на един от няколко идентични сървъра. По този начин DNS действа като
ролята на балансиращия възел, от който клиентът получава "разпределението". въпреки това
самата структура на DNS сървърите предполага липсата на точка на повреда поради
дублиране - тоест комбинират се предимствата на два подхода. Разбира се, такива
има и недостатъци на метода на балансиране - например, такава система е трудна за динамична
възстановявам.
Работата със сайта обикновено не се ограничава до една заявка.
Следователно, когато проектирате, е важно да разберете дали последователните заявки могат
клиентът да се обработва правилно от различни сървъри, или клиентът трябва да бъде
свързани с един сървър, докато работите със сайта. Това е особено важно, ако
Сайтът запазва временна информация за сесията на потребителя (в това
случай е възможно и безплатно разпространение - тогава обаче е необходимо да се съхранява
сесия в общо хранилище за всички сървъри). Свържете посетителя към
конкретен сървър, можете да използвате неговия IP адрес (който обаче може да се промени),
или чрез бисквитка (в която идентификаторът на сървъра е предварително написан), или дори
просто като го пренасочите към желания домейн.
От друга страна, изчислителните сървъри може да не са равни.
В някои случаи е полезно да направите обратното, да посветите отделен сървър
обработка на заявки от един тип - и получаване на вертикално разделяне
функции. Тогава клиентът или балансиращият възел ще избере сървъра в
в зависимост от вида на получената заявка. Този подход дава възможност за разделяне
важни (или обратното, не критични, но тежки) искания от останалите.
Разпределение на данни
Научихме се как да разпределяме изчисления, толкова големи
присъствието не е проблем за нас. Обемите на данни обаче продължават да растат,
съхранението и обработката им стават все по-трудни - което означава, че е време за изграждане
разпределено съхранение на данни. В този случай вече няма да имаме такъв или
множество сървъри, съдържащи пълно копие на базата данни. Вместо това данни
ще бъдат разпределени на различни сървъри. Какви са възможните схеми за разпространение?
- Вертикално разпределение(vertical partitioning) - в най-простия случай
е прехвърлянето на отделни таблици на база данни към друг сървър. При
за това трябва да променим скриптовете за достъп до различни сървъри
различни данни. В крайна сметка можем да съхраняваме всяка таблица на отделен сървър
(въпреки че на практика това е малко вероятно да бъде от полза). Очевидно с такива
разпределение, ние губим способността да правим SQL заявки, които комбинират данни от
две маси, разположени на различни сървъри. Ако е необходимо, можете да приложите
логика на присъединяване в приложението, но няма да е толкова ефективна, колкото в СУБД.
Следователно, когато разделяте база данни, трябва да анализирате връзките между таблиците,
за да разположите най-независимите маси.По-сложен случай
вертикално разпределение на основата е разлагането на една маса, когато част
колоните му са на един сървър, а някои от тях са на друг. Такава техника
по-рядко, но може да се използва например за разделяне на малки
и често актуализирани данни от голямо количество рядко достъпни данни. - Хоризонтално разпределение(хоризонтално преграждане) - състои се в
разпределяне на данни от една таблица между множество сървъри. Всъщност на
всеки сървър създава таблица със същата структура и я съхранява
определена част от данните. Можете да разпространявате данни между сървърите по различни начини.
критерии: по диапазон (записи с id< 100000 идут на сервер А, остальные - на сервер Б), по списку значений (записи типа «ЗАО» и «ОАО» сохраняем на сервер
А, останалите - към сървъра Б) или по стойността на хеш функцията от някое поле
записи. Хоризонталното разделяне на данни ви позволява да съхранявате неограничен брой
броят на записите обаче усложнява избора. Най-ефективният избор
записи само когато се знае на кой сървър се съхраняват.
За да изберете правилната схема за разпространение на данни, е необходимо
внимателно анализирайте структурата на базата данни. Съществуващите таблици (и евентуално
отделни полета) могат да бъдат класифицирани по честота на достъп до записи, по честота
актуализации и по връзки (необходимостта да се правят избори от няколко
таблици).
Както бе споменато по-горе, в допълнение към базата данни, сайтът често се нуждае
хранилище за двоични файлове. Разпределени системи за съхранение на файлове
(всъщност файлови системи) могат да бъдат разделени на два класа.
- Работещ на ниво операционна система. В същото време за
приложения, работата с файлове в такава система не се различава от нормалната работа с
файлове. Обменът на информация между сървърите се управлява от операционната система.
Примери за такива файлови системи включват добре познатите
семейството NFS или по-малко известната, но по-модерна система Luster. - Внедрено на ниво приложениеразпределени
хранилищата предполагат, че работата по обмена на информация се извършва от
приложение. Обикновено за удобство се поставят функциите за работа със съхранение
отделна библиотека. Един от най-ярките примери за такова съхранение е MogileFS, разработен от
създателите на LiveJournal. Друг често срещан пример е употребата
WebDAV протокол и поддържащото го съхранение.
Трябва да се отбележи, че разпределението на данните решава не само
проблем със съхранението, но също и отчасти проблем с разпределението на натоварването - на всеки
има по-малко записи на сървъра и следователно те се обработват по-бързо.
Комбинацията от методи за изчисляване и разпространение на данни прави възможно конструирането
потенциално неограничена мащабируема архитектура, с която може да се работи
всяко количество данни и всякакви товари.
заключения
Обобщавайки казаното, формулираме заключенията под формата на кратки тези.
- Двете основни (и свързани) предизвикателства при мащабирането са разпределението на изчисленията и разпространението на данни.
- Типичната архитектура на сайта предполага разделяне на ролите и
включва фронтенд, бекенд, база данни и понякога съхранение на файлове - За малки количества данни и големи натоварвания,
дублиране на бази данни - синхронна или асинхронна репликация - При големи количества данни е необходимо базата данни да се разпредели - сплит
неговата вертикална или хоризонтална - Двоичните файлове се съхраняват в разпределени файлови системи
(имплементиран на ниво ОС или в приложението) - Балансирането (разпределението на заявките) може да бъде равномерно или
с разделение по функционалност; с балансиращ възел или от страна на клиента - Правилната комбинация от методи ще ви позволи да задържите всякакъв товар;)
Връзки
Можете да продължите да изучавате тази тема на интересни англоезични сайтове и блогове.
