В тази поредица от постове ще се опитам да обясня идеята и ползите от използването на Oracle Real Application Cluster. Според моя опит все повече компании поглеждат към това решение, което, без съмнение, придоби голяма стабилност и реална полза без да е необходим кой-знае-какъв специализиран хардуер в последните версии на Oracle RDBMS.
Първо трябва да изчистим идеята за клъстер. Според Wikipedia, “A computer cluster is a group of tightly coupled computers that work together closely so that in many respects they can be viewed as though they are a single computer”. Друга, по-ясна дефиниция е „A cluster environment is defined as a system built with a multitude of nodes sharing local resources (Disks, CPU power, Printer queues…) and offering cluster-wide services (Security, Synchronization, Communication)”. Като цяло идеята е да се извършва една обща работа на няколко компютъра (наречени cluster nodes, или възли), които от гледна точка на потребителя/клиента изглеждат като един (ресурс).
В началото искам да уточня някои термини, които ще използвам.
– Node (възел): това е един от „компютрите”, които формират клъстера. Представлява относително самостоятелна единица със собствени процесори и памет.
– Shared resource (споделен ресурс): това е ресурс, който се споделя между възлите в клъстера. Обикновено е общ дисков масив.
– Пакет: за да се извършва работата паралелно, тя трябва да (може да) се раздели на пакети, които могат да се обработят самостоятелно. Пакета е единица работа, която се извършва винаги само от един от възлите.
Има няколко вида клъстерни архитектури, които представят различни предимства:
– Share Nothing Clusters: това са системи, в които всеки възел управлява ексклузивно част от споделения ресурс (примерно дял от споделения диск). В този случай ресурсите са споделени само на хардуерно ниво (или изобщо не са споделени), но логически са разделени. Това е най-лесният за реализиране вариант, но е най-труден за използване. Данните са стриктно разпределени между възлите, като всеки има достъп само до своите данни. Пример: IBM SP2, Terradata, Informix OnLine XPS
– Shared Disk Cluster: Това е частен случай, в който не се получава по-висока производителност, а само отказоустойчивост. Даннтие са на споделен диск, но е активен само един възел който има екслкузивен достъп до тях. При отпадане на активния възел, работата се прехвърля към неактивния, който до тогава не е работил. Такива решения са повечето клъстерирания на приложение на ниво ОС: HP ServiceGuard, Veritas Cluster Server, Microsoft Cluster Server
– Shared Everything Clusters: това са системи, в които общия ресурс се управлява равноправно от всичките възли на клъстера. В този случай всеки от възлите може да обработи всеки от пакетите, т.е. потребителя не се интересува към кой възел е закачен в момента. Това предоставя много предимства за клиентското приложение и значително го опростява. От друга страна такъв клъстер е труден за реализиране и усложнява значително задачата за синхронизация между възлите. Може да се получи много висока производителност и отказоустойчивост, почти перфектен load balancing (разпределение на натоварването между възлите). Могат да се добавят и премахват възли динамично, като това не прекъсва достъпноста на данните. Пример са Oracle RAC, IBM HACMP
– NUMA (Non Uniform Memory Access) – NUMA е подход за изграждане на клъстер от силно специализирани хардуерни компоненти. Клъстеризирането се извършва на ниво преди операционната система от едно ниво което извършва абстракция на хардуера и предоставя на ОС ресурси като дискове, процесори, памет. При този подход не е задължително да се прави синхронизация на работните пакети. Недостатък е, че има изявена латентност при достъп до „отдалечен ресурс” (примерно процесор от един блок чете памет от друг блок). Тази латентност се избягва до колкото е възможно от ОС при разпределението на ресурсите (ако ОС е запозната с NUMA архитектурата).
Каква е целта, която се преследва с клъстеризирането?
– Отказоустойчивост: в един shared everything или NUMA клъстер, където всеки възел може да свърши всяка работа, отпадането на един възел не води до отпадане на приложението като цяло.
– Скалируемост: както при всяко решение за паралелизация на задачи, търси се повишаване на производителността. Идеята е, че съвкупността от много възли е по-производителна и от най-мощния единичен възел. Теоретично производителността на клъстера може да се изрази като
T(N) = SUM t(i)
. . . i=1->N
Където
N е броя на възлите,
t(i) е производителността на i-тия възел.
На практика се получава загуба на производителност от нуждата за синхронизация между възлите. Това може да се изрази така (за хомогенен клъстер)
T(N) = N*t*s(N)
Където
N е броя на възлите
t е производителността на 1 възел
s(N) e коефициент на синхронизацията. Тук важи 0 < s(N) <= 1
Целта на клъстерните решения е да доближат s(N) до 1, т.е. да се получи почти линейна скалируемост: двойно повече възли водят до двойно по-голяма производителност. Тук може да се каже, че когато s(N) > 1/N, приложението се скалира добре. Колкото по-блозо е s(N) до 1, толкова по-добре скалира приложението. Когато s(N) < 1/N, приложението не скалира добре – при добавяне на възли в клъстера общата производителност пада.
Факторите, които влияят върху s(N) са:
- Clusterware – това е системата, която предоставя клъстерните услуги; грижи се за синхронизацията и заключванията. Такъв софтуер е Oracle CRS (Cluster ready Services, “сърцето” на Oracle RAC).
- Application – самото приложение, което използва БД.
- Топологията на клъстера (предимно типа на връзката между възлите)
