Сравняване на Oracle RAC HA Solution с Galera Cluster за MySQL или MariaDB

Бизнесът непрекъснато желае да извлича прозрения от информацията, за да взема надеждни, по-интелигентни решения в реално време, базирани на факти. Тъй като фирмите разчитат повече на данни и бази данни, информацията и обработката на данни са в основата на много бизнес операции и бизнес решения. Вярата в базата данни е пълна. Нито една от ежедневните фирмени услуги не може да работи без основните платформи за бази данни. В резултат на това необходимостта от мащабируемост и производителност на системния софтуер на база данни е по-критична от всякога. Основните предимства на системата за клъстерирана база данни са мащабируемостта и високата наличност. В този блог ще се опитаме да сравним Oracle RAC и Galera Cluster в светлината на тези два аспекта. Real Application Clusters (RAC) е първокласното решение на Oracle за клъстеризиране на бази данни на Oracle и осигурява висока достъпност и мащабируемост. Galera Cluster е най-популярната технология за клъстериране за MySQL и MariaDB.

Общ преглед на архитектурата

Oracle RAC използва софтуера на Oracle Clusterware за свързване на множество сървъри. Oracle Clusterware е решение за управление на клъстер, което е интегрирано с Oracle Database, но може да се използва и с други услуги, не само с базата данни. Oracle Clusterware е допълнителен софтуер, инсталиран на сървъри, работещи с една и съща операционна система, което позволява на сървърите да бъдат свързани заедно, за да работят така, сякаш са един сървър.

Oracle Clusterware наблюдава екземпляра и автоматично го рестартира, ако възникне срив. Ако приложението ви е добре проектирано, може да нямате прекъсване на услугата. Само група сесии (тези, които са свързани с неуспешния екземпляр) са засегнати от неуспеха. Затъмнението може да бъде ефективно маскирано за крайния потребител, като се използват разширени RAC функции като бързо известяване на приложението и Failver Fast Connection на клиента на Oracle. Oracle Clusterware контролира членството в възел и предотвратява симптомите на разделен мозък, при които два или повече екземпляра се опитват да контролират екземпляра.

Galera Cluster е синхронна технология за клъстериране на база данни активно-активна за MySQL и MariaDB. Galera Cluster се различава от това, което е известно като MySQL Cluster на Oracle - NDB. MariaDB клъстерът се основава на приставката за репликация с множество главни, предоставена от Codership. От версия 5.5 плъгинът Galera (wsrep API) е неразделна част от MariaDB. Percona XtraDB Cluster (PXC) също е базиран на приставката Galera. Архитектурата на плъгините Galera се основава на три основни слоя:сертифициране, репликация и рамка за групова комуникация. Сертификационният слой подготвя наборите за запис и извършва сертификационни проверки върху тях, като гарантира, че те могат да бъдат приложени. Репликационният слой управлява протокола за репликация и осигурява пълната способност за подреждане. Group Communication Framework внедрява архитектура на плъгини, която позволява на други системи да се свързват чрез gcomm back-end схема.

За да запази състоянието идентично в клъстера, wsrep API използва глобален идентификатор на транзакция. Уникален идентификатор на GTID се създава и асоциира с всяка транзакция, извършена на възела на базата данни. В Oracle RAC различни екземпляри на база данни споделят достъп до ресурси като блокове данни в кеша на буфера, за да поставят в опашката блокове данни. Достъпът до споделените ресурси между RAC инстанциите трябва да бъде координиран, за да се избегне конфликт. За да организира споделен достъп до тези ресурси, разпределеният кеш поддържа информация като идентификатор на блок от данни, кой екземпляр на RAC съхранява текущата версия на този блок данни и режима на заключване, в който всеки екземпляр съдържа блока данни.

Ключови концепции за съхранение на данни

Oracle RAC разчита на разпределена дискова архитектура. Файловете на базата данни, контролните файлове и онлайн регистрационните файлове за повторение за базата данни трябва да са достъпни за всеки възел в клъстера. Има различни начини за конфигуриране на споделено съхранение, включително директно свързани дискове, мрежи за съхранение (SAN) и мрежово прикачено хранилище (NAS) и Oracle ASM. Два най-популярни са OCFS и ASM. Oracle Cluster File System (OCFS) е споделена файлова система, създадена специално за Oracle RAC. OCFS елиминира изискването файловете на базата данни на Oracle да бъдат свързани към логически устройства и позволява на всички възли да споделят едно Oracle Home ASM, RAW устройство. Oracle ASM е препоръчаното решение на Oracle за управление на съхранение, което предоставя алтернатива на конвенционалните мениджъри на обеми, файлови системи и необработени устройства. Oracle ASM осигурява слой за виртуализация между базата данни и съхранението. Той третира множество дискове като една дискова група и ви позволява динамично да добавяте или премахвате устройства, като същевременно поддържате бази данни онлайн.

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

Комуникация и кеш на клъстерни възли

Oracle Real Application Clusters има споделена архитектура на кеша, използва Oracle Grid Infrastructure, за да даде възможност за споделяне на сървърни ресурси и ресурси за съхранение. Комуникацията между възлите е критичният аспект на целостта на клъстера. Всеки възел трябва да има поне два мрежови адаптера или мрежови интерфейсни карти:един за публичния мрежов интерфейс и един за взаимно свързване. Всеки клъстерен възел е свързан с всички останали възли чрез частна високоскоростна мрежа, също разпозната като взаимовръзка на клъстера.

Частната мрежа обикновено се формира с Gigabit Ethernet, но за среди с голям обем много доставчици предлагат решения с ниска латентност и висока честотна лента, предназначени за Oracle RAC. Linux също така разширява средствата за свързване на множество физически NIC в един виртуален NIC, за да осигури увеличена честотна лента и наличност.

Докато подходът по подразбиране за свързване на възлите на Galera е да се използва един NIC на хост, можете да имате повече от една карта. ClusterControl може да ви помогне с такава настройка. Основната разлика е изискването за честотна лента на междусистемната връзка. Oracle RAC изпраща блокове данни между екземпляри, така че поставя по-голямо натоварване на взаимното свързване в сравнение с наборите за запис на Galera (които се състоят от списък с операции).

С Redundant Interconnect Usage в RAC можете да идентифицирате множество интерфейси, които да използвате за частната клъстерна мрежа, без да е необходимо да използвате свързване или други технологии. Тази функционалност е налична, като се започне с Oracle Database 11gR2. Ако използвате функцията за прекомерно взаимно свързване на Oracle Clusterware, тогава трябва да използвате IPv4 адреси за интерфейсите (UDP е по подразбиране).

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

За технологията Cache Fusion на Oracle е необходима сложна настройка на мрежата, за да се свърже физическата памет във всеки хост в един кеш. Oracle Cache Fusion предоставя данни, съхранявани в кеша на един екземпляр на Oracle, за да бъдат достъпни от всеки друг екземпляр, като ги транспортира през частната мрежа. Освен това защитава целостта на данните и кохерентността на кеша чрез предаване на информация за заключване и допълнителна синхронизация извън клъстерните възли.

В допълнение към описаната настройка на мрежата, можете да зададете един адрес на база данни за вашето приложение - Име за единичен клиентски достъп (SCAN). Основната цел на SCAN е да осигури лесно управление на връзката. Например, можете да добавяте нови възли към клъстера, без да променяте низа за връзка с клиента. Тази функционалност се дължи на факта, че Oracle автоматично ще разпределя заявки съответно въз основа на SCAN IP адресите, които сочат към основните VIP. Слушателите за сканиране правят моста между клиентите и основните местни слушатели, които са зависими от VIP.

За Galera Cluster, еквивалентът на SCAN би бил добавяне на прокси на база данни пред възлите на Galera. Проксито ще бъде единна точка за контакт за приложения, може да списва неуспешни възли и да насочва заявки към здрави възли. Самото прокси може да се направи излишно с Keepalived и Virtual IP.

Отказ при отказ и възстановяване на данни

Основната разлика между Oracle RAC и MySQL Galera Cluster е, че Galera няма споделена архитектура. Вместо споделени дискове, Galera използва базирана на сертификация репликация с групова комуникация и подреждане на транзакции, за да постигне синхронна репликация. Клъстерът от база данни трябва да може да оцелее при загуба на възел, въпреки че това се постига по различни начини. В случай на Galera, критичният аспект е броят на възлите, Galera изисква кворум, за да работи. Клъстер с три възела може да оцелее при срива на един възел. С повече възли във вашия клъстер, вашата наличност ще расте. Oracle RAC не изисква кворум, за да продължи да функционира след срив на възел. Това се дължи на достъпа до разпределено хранилище, което съхранява последователна информация за състоянието на клъстера. Въпреки това, вашето съхранение на данни може да бъде потенциална точка на провал във вашия план за висока наличност. Въпреки че е сравнително проста задача да разполагате с клъстерни възли на Galera, разпръснати в центрове за данни за геолокация, няма да е толкова лесно с RAC. Oracle RAC изисква допълнително дублиране на диск от висок клас, но основното RAID като резервиране може да бъде постигнато в ASM дискова група.

Схеми за заключване

В база данни за един потребител, потребителят може да променя данните, без да се притеснява за други сесии, които променят същите данни по едно и също време. Въпреки това, в многопотребителска база данни с много възли, това става по-трудно. Многопотребителска база данни трябва да предоставя следното:

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

Клъстерните екземпляри изискват три основни типа заключване на паралелност:

• Паралелността на данните се чете на различни екземпляри,
• Паралелността на данните чете и записва в различни екземпляри,
• Паралелността на данните записва в различни екземпляри.

Oracle ви позволява да изберете политиката за заключване, песимистична или оптимистична, в зависимост от вашите изисквания. За да се получи едновременно заключване, RAC има два допълнителни буфера. Те са Global Cache Service (GCS) и Global Enqueue Service (GES). Тези две услуги покриват процеса на Cache Fusion, прехвърляне на ресурси и ескалация на ресурсите между инстанциите. GES включва заключване на кеша, заключване на речник, заключване на транзакции и заключване на таблици. GCS поддържа блоковите режими и блоковите прехвърляния между екземплярите.

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

Galera Cluster използва оптимистичен контрол за едновременност на ниво клъстер, който може да се появи в транзакции, които водят до прекратяване на COMMIT. Първият комит печели. Когато възникнат прекъсвания на ниво клъстер, Galera Cluster дава грешка в застой. Това може или не може да повлияе на архитектурата на приложението ви. Големият брой редове за репликиране в една транзакция би повлиял на отговорите на възела, въпреки че има техники за избягване на подобно поведение.

Изисквания за хардуер и софтуер

Конфигурирането на хардуера на двата клъстера не изисква мощни ресурси. Минималната конфигурация на Oracle RAC клъстер ще бъде задоволена от два сървъра с два процесора, физическа памет най-малко 1,5 GB RAM, количество суап пространство, равно на количеството RAM и две Gigabit Ethernet NIC. Минималната конфигурация на възел на Galera е три възела (един от възлите може да бъде арбитър, gardb), всеки с 1GHz едноядрен CPU 512MB RAM, 100 Mbps мрежова карта. Въпреки че това са минималните, можем спокойно да кажем, че и в двата случая вероятно бихте искали да имате повече ресурси за вашата производствена система.

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

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

Наблюдение и управление

Oracle Enterprise Manager е предпочитаният подход за наблюдение на Oracle RAC и Oracle Clusterware. Oracle Enterprise Manager е уеб-базирана унифицирана система за управление на Oracle за наблюдение и администриране на вашата среда на база данни. Той е част от Oracle Enterprise License и трябва да бъде инсталиран на отделен сървър. Наблюдението и управлението на клъстерния контрол се извършва чрез комбинация от команди crsctl и srvctl, които са част от двоични файлове на клъстера. По-долу можете да намерите няколко примерни команди.

Проверка на състоянието на ресурсите на клъстеруера:

    crsctl status resource -t (or shorter: crsctl stat res -t)

Пример:

$ crsctl stat res ora.test1.vip
NAME=ora.test1.vip
TYPE=ora.cluster_vip_net1.type
TARGET=ONLINE
STATE=ONLINE on test1

Проверете състоянието на стека на Oracle Clusterware:

    crsctl check cluster

Пример:

$ crsctl check cluster -all
*****************************************************************
node1:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online
*****************************************************************
node2:
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Проверете състоянието на Oracle High Availability Services и стека на Oracle Clusterware на локалния сървър:

    crsctl check crs

Пример:

$ crsctl check crs
CRS-4638: Oracle High Availablity Services is online
CRS-4537: Cluster Ready Services is online
CRS-4529: Cluster Synchronization Services is online
CRS-4533: Event Manager is online

Спрете Oracle High Availability Services на локалния сървър.

    crsctl stop has

Спрете Oracle High Availability Services на локалния сървър.

    crsctl start has

Показва състоянието на приложенията на възел:

    srvctl status nodeapps

Показва информацията за конфигурацията за всички SCAN VIPs

    srvctl config scan

Пример:

srvctl config scan -scannumber 1
SCAN name: testscan, Network: 1
Subnet IPv4: 192.51.100.1/203.0.113.46/eth0, static
Subnet IPv6: 
SCAN 1 IPv4 VIP: 192.51.100.195
SCAN VIP is enabled.
SCAN VIP is individually enabled on nodes:
SCAN VIP is individually disabled on nodes:

Помощната програма за проверка на клъстер (CVU) извършва системни проверки в подготовка за инсталиране, актуализации на корекция или други системни промени:

    cluvfy comp ocr

Пример:

Verifying OCR integrity
Checking OCR integrity...
Checking the absence of a non-clustered configurationl...
All nodes free of non-clustered, local-only configurations
ASM Running check passed. ASM is running on all specified nodes
Checking OCR config file “/etc/oracle/ocr.loc"...
OCR config file “/etc/oracle/ocr.loc" check successful
Disk group for ocr location “+DATA" available on all the nodes
NOTE:
This check does not verify the integrity of the OCR contents. Execute ‘ocrcheck' as a privileged user to verify the contents of OCR.
OCR integrity check passed
Verification of OCR integrity was successful.

Възлите на Galera и клъстерът изискват wsrep API да докладва няколко състояния, което е изложено. Понастоящем има 34 специални променливи за състоянието, които могат да се видят с оператор SHOW STATUS.

mysql> SHOW STATUS LIKE 'wsrep_%';

Администрирането на MySQL Galera Cluster в много аспекти е много сходно. Има само няколко изключения като стартиране на клъстера от първоначален възел или възстановяване на възли чрез SST или IST операции.

Клъстер за стартиране:

$ service mysql bootstrap # sysvinit
$ service mysql start --wsrep-new-cluster # sysvinit
$ galera_new_cluster # systemd
$ mysqld_safe --wsrep-new-cluster # command line

Еквивалентното уеб-базирано, готово решение за управление и наблюдение на Galera Cluster е ClusterControl. Той предоставя уеб-базиран интерфейс за разгръщане на клъстери, следи ключови показатели, предоставя съветници за база данни и се грижи за задачи за управление като архивиране и възстановяване, автоматично корекция, криптиране на трафика и управление на наличността.

Ограничения за натоварване

Oracle предоставя SCAN технология, която открихме, че липсва в Galera Cluster. Предимството на SCAN е, че информацията за връзката на клиента не трябва да се променя, ако добавяте или премахвате възли или бази данни в клъстера. Когато се използва SCAN, базата данни на Oracle се свързва на случаен принцип с един от наличните слушатели на SCAN (обикновено три) по кръгъл начин и балансира връзките между тях. Могат да се конфигурират два вида балансиране на натоварването:от страна на клиента, балансиране на натоварването по време на свързване и от страна на сървъра, балансиране на натоварването по време на изпълнение. Въпреки че в самия клъстер Galera няма нищо подобно, същата функционалност може да бъде адресирана с допълнителен софтуер като ProxySQL, HAProxy, Maxscale, комбиниран с Keepalived.

Когато става въпрос за дизайн на работното натоварване на приложенията за Galera Cluster, трябва да избягвате конфликтни актуализации на един и същи ред, тъй като това води до блокиране в целия клъстер. Избягвайте групови вмъквания или актуализации, тъй като те може да са по-големи от максимално разрешения набор за запис. Това също може да доведе до спиране на клъстера.

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

Редундиране на множество центрове за данни

Според документацията на Oracle максималното разстояние между две кутии, свързани по начин от точка до точка и работещи синхронно, може да бъде само 10 км. С помощта на специализирани устройства това разстояние може да се увеличи до 100 км.

Galera Cluster е добре известен със своите възможности за репликация с множество центрове за данни. Той има богата поддръжка за мрежови настройки на Wider Area Networks. Може да бъде конфигуриран за висока латентност на мрежата чрез измерване на времето за обиколно пътуване (RTT) между възлите на клъстера и коригиране на необходимите параметри. Параметрите wsrep_provider_options ви позволяват да конфигурирате настройки като suspect_timeout, interactive_timeout, join_retrans_timouts и много други.

Използване на Galera и RAC в облак

Според бележка на Oracle www.oracle.com/technetwork/database/options/.../rac-cloud-support-2843861.pdf в момента нито един облак на трета страна не отговаря на изискванията на Oracle относно споделено хранилище, предоставено в оригинал. „Вроден“ в този контекст означава, че доставчикът на облак трябва да поддържа споделено съхранение като част от тяхната инфраструктура съгласно политиката за поддръжка на Oracle.

Благодарение на своята споделена архитектура за нищо, която не е обвързана със сложно решение за съхранение, клъстерът Galera може лесно да бъде разгърнат в облачна среда. Неща като:

• оптимизиран мрежов протокол,
• репликация, съобразена с топологията,
• криптиране на трафика,
• откриване и автоматично изгонване на ненадеждни възли,

прави процеса на миграция в облак по-надежден.

Лицензи и скрити разходи

Лицензирането на Oracle е сложна тема и ще изисква отделна статия в блога. Клъстерният фактор го прави още по-труден. Цената се увеличава, тъй като трябва да добавим някои опции за лицензиране на цялостно RAC решение. Тук просто искаме да подчертаем какво да очаквате и къде да намерите повече информация.

RAC е характеристика на лиценза на Oracle Enterprise Edition. Лицензът на Oracle Enterprise е разделен на два типа, за наименуван потребител и за процесор. Ако смятате Enterprise Edition с лиценз за ядро, тогава цената на едно ядро ​​е RAC 23 000 USD + Oracle DB EE 47 500 USD и все още трябва да добавите ~ 22% такса за поддръжка. Бихме искали да се позоваваме на страхотен блог за цените, който се намира на https://flashdba.com/2013/09/18/the-real-cost-of-oracle-rac/.

Flashdba изчисли цената на Oracle RAC с четири възли. Общата сума беше 902 400 USD плюс допълнителни 595 584 USD за три години поддръжка на DB и това не включва функции като разделяне или база данни в паметта, всичко това с 60% отстъпка на Oracle.

Galera Cluster е решение с отворен код, което всеки може да изпълнява безплатно. Налични са абонаменти за производствени реализации, които изискват поддръжка от доставчик. Добро изчисление на TCO може да се намери на https://severalnines.com/blog/database-tco-calculating-total-cost-ownership-mysql-management.

Заключение

Въпреки че има значителни разлики в архитектурата, и двата клъстера споделят основните принципи и могат да постигнат сходни цели. Корпоративният продукт на Oracle се предлага с всичко извадено от кутията (и цената му). С цена в диапазона от>1 млн. USD, както се вижда по-горе, това е решение от висок клас, което много предприятия не биха могли да си позволят. Galera Cluster може да се опише като прилично решение с висока достъпност за масите. В определени случаи Galera може да бъде много добра алтернатива на Oracle RAC. Един недостатък е, че трябва да изградите свой собствен стек, въпреки че това може да бъде напълно автоматизирано с ClusterControl. Ще се радваме да чуем вашите мисли по въпроса.