Drupal е система за управление на съдържанието (CMS), предназначена да създава всичко от малки до големи корпоративни уебсайтове. Над 1 000 000 уебсайта работят на Drupal и той се използва за създаване на много от уебсайтовете и приложенията, които използвате всеки ден (включително този). Drupal има страхотен набор от стандартни функции като лесно създаване на съдържание, надеждна производителност и отлична сигурност. Това, което отличава Drupal, е неговата гъвкавост, тъй като модулността е един от основните му принципи.
Drupal също е чудесен избор за създаване на интегрирани цифрови рамки. Можете да го разширите с хилядите налични добавки. Тези модули разширяват функционалността на Drupal. Темите ви позволяват да персонализирате представянето на вашето съдържание, а дистрибуциите (Drupal bundles) са пакети, които можете да използвате като начални комплекти. Можете да използвате всички тези функции, за да комбинирате и съчетаете, за да подобрите основните способности на Drupal или да интегрирате Drupal с външни услуги. Това е софтуер за управление на съдържанието, който е мощен и мащабируем.
Drupal използва бази данни, за да съхранява своето уеб съдържание. Когато вашият базиран на Drupal уебсайт или приложение изпитва голямо количество трафик, това може да окаже влияние върху сървъра ви на база данни. Когато сте в тази ситуация, ще ви трябва балансиране на натоварването, висока наличност и резервна архитектура, за да поддържате вашата база данни онлайн.
Когато започнах да проучвам този блог, осъзнах, че има много отговори на този проблем онлайн, но препоръчаните решения бяха много остарели. Това може да е резултат от увеличаването на пазарния дял от WordPress, което води до по-малка общност с отворен код. Това, което открих, бяха някои примери за внедряване на висока наличност чрез използване на Master/Master (Висока наличност) или Master/Master/Slave (Висока достъпност/Висока производителност).
Drupal предлага поддръжка за широк спектър от бази данни, но първоначално е проектиран с помощта на MySQL варианти. Въпреки че използването на MySQL се поддържа напълно, има по-добри подходи, които можете да приложите. Прилагането на тези други подходи обаче, ако не е направено правилно, може да доведе до големи престои на уебсайта ви, да причини проблеми с производителността на приложението ви и може да доведе до проблеми при запис на вашите подчинени устройства. Извършването на поддръжка също би било трудно, тъй като се нуждаете от отказ, за да приложите надстройките или корекции на сървъра (хардуер или софтуер) без прекъсване. Това е особено вярно, ако имате голямо количество данни, което причинява потенциално голямо въздействие върху вашия бизнес.
Това са ситуации, които не искате да се случват, поради което в този блог ще обсъдим как можете да приложите отказ от база данни за вашите MySQL или PostgreSQL бази данни.
Защо вашият Drupal уебсайт се нуждае от отказ на база данни?
От Уикипедия „отказът е превключване към резервен или резервен компютърен сървър, система, хардуерен компонент или мрежа при повреда или необичайно прекратяване на предишно активно приложение, сървър, система, хардуерен компонент или мрежа. Превключването при отказ и превключването са по същество една и съща операция, с изключение на това, че превключването е автоматично и обикновено работи без предупреждение, докато превключването изисква човешка намеса."
При операциите с база данни превключването също е термин, използван за ръчно превключване при отказ, което означава, че изисква човек да управлява превключването при отказ. Отказът е полезен за всеки администратор, тъй като изолира нежелани проблеми като случайно изтриване/отпадане на таблици, дълги часове престой, причиняващи въздействие върху бизнеса, повреда на базата данни или корупция на ниво система.
Отказът на базата данни се състои от повече от един възел на базата данни, физически или виртуално. В идеалния случай, тъй като при отказ изисква да извършите превключване към различен възел, можете също да превключите към друг сървър на база данни, ако хостът изпълнява множество екземпляри на база данни на един хост. Това все още може да бъде или превключване, или отказ, но обикновено е по-скоро резервиране и висока наличност в случай, че възникне катастрофа на този текущ хост.
Отказ при отказ на MySQL за Drupal
Извършването на отказ за вашето приложение, базирано на Drupal, изисква данните, обработвани от базата данни, да не се разграничават, нито да се разделят. Има няколко налични решения и ние вече обсъдихме някои от тях в предишни блогове на Severalnines. Вероятно бихте искали да прочетете нашето Въведение в отказоустойчивостта за MySQL репликация – блогът 101.
Превключването между главен и подчинен
Най-често срещаните подходи за MySQL Failover е използването на превключването между главен-подчинен или ръчното превключване при отказ. Тук можете да използвате два подхода:
- Можете да внедрите вашата база данни с типична асинхронна репликация главен-подчинен.
- или може да се реализира с асинхронна главен-подчинен репликация, като се използва репликация, базирана на GTID.
Преминаването към друг главен може да бъде по-бързо и по-лесно. Това може да стане със следния MySQL синтаксис:
mysql> SET GLOBAL read_only = 1; /* enable read-only */
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_LOG_FILE = '<master-log-file>', MASTER_LOG_POS=<master_log_position>; /* master information to connect */
mysql> START SLAVE; /* start replication */
mysql> SHOW SLAVE STATUS\G /* check replication status */или с GTID, можете просто да направите,
...
mysql> CHANGE MASTER TO MASTER_HOST = '<hostname-or-ip>', MASTER_USER = '<user>', MASTER_PASSWORD = '<password>', MASTER_AUTO_POSITION = 1; /* master information to connect */
...
WitИзползването на подхода без GTID изисква първо да определите регистрационния файл на главния и регистрационния номер на главния. Можете да определите това, като погледнете състоянието на главния възел в главния възел, преди да превключите.
mysql> MASTER STATUS;Можете също да помислите за заздравяване на сървъра си, като добавите sync_binlog =1 и innodb_flush_log_at_trx_commit =1, тъй като в случай, че вашият главен елемент се срине, ще имате по-голям шанс транзакциите от master да бъдат несинхронизирани с вашия подчинен ( с). В такъв случай повишеният главен има по-голям шанс да бъде последователен възел на източника на данни.
Това обаче може да не е най-добрият подход за вашата база данни на Drupal, тъй като може да наложи дълги прекъсвания, ако не бъде изпълнено правилно, като например внезапно сваляне. Ако вашият главен възел на базата данни срещне грешка, водеща до срив на базата данни, ще трябва приложението ви да сочи към друга база данни, която чака в режим на готовност като ваш нов главен или като вашия подчинен е повишен като главен. Ще трябва да посочите точно кой възел трябва да поеме и след това да определите изоставането и последователността на този възел. Постигането на това не е толкова лесно, колкото просто да направите SET GLOBAL read_only=1; ПРОМЯНЕТЕ ГЛАВНИЯ НА... (и т.н.), има определени ситуации, които изискват по-задълбочен анализ, разглеждане на жизнеспособните транзакции, необходими да присъстват в този резервен сървър или повишен главен, за да се извърши.
Drupal Failover с помощта на MHA
Един от най-разпространените инструменти за автоматично и ръчно преминаване на отказ е MHA. Той съществува от доста време и все още се използва от много организации. Можете да разгледате тези предишни блогове, които имаме по темата, Най-често срещаните проблеми с MHA и Как да ги поправите или MySQL Инструменти за висока достъпност – Сравняване на MHA, MRM и ClusterControl.
Drupal Failover с помощта на Orchestrator
Orchestrator вече е широко разпространен и се използва от големи организации като Github и Booking.com. Той не само ви позволява да управлявате отказ, но и управление на топология, откриване на хост, рефакторинг и възстановяване. Тук има хубав външен блог, който намерих за много полезен да науча за неговия механизъм за преодоляване на срив с Orchestrator. Това е поредица от блогове от две части; част първа и част втора.
Drupal Failover с помощта на MaxScale
MaxScale не е просто балансьор на натоварване, предназначен за сървър на MariaDB, той също така разширява високата наличност, мащабируемост и сигурност за MariaDB, като в същото време опростява разработването на приложения, като го отделя от основната инфраструктура на базата данни. Ако използвате MariaDB, тогава MaxScale може да бъде подходяща технология за вас. Вижте предишните ни блогове за това как можете да използвате механизма за преодоляване при отказ на MaxScale.
Drupal Failover с помощта на ClusterControl
ClusterControl на Severalnines предлага широк спектър от решения за управление и мониторинг на бази данни. Част от решенията, които предлагаме, са автоматично преминаване при отказ, ръчно преминаване при отказ и възстановяване на клъстер/възел. Това е много полезно, сякаш действа като администратор на виртуална база данни, като ви уведомява в реално време, в случай че вашият клъстер е в „паник режим“, докато възстановяването се управлява от системата. Можете да разгледате този блог Как да автоматизирате отказването на база данни с ClusterControl, за да научите повече за преодоляването на отказ на ClusterControl.
Други MySQL решения
Някои от старите подходи все още са приложими, когато искате да преминете при отказ. Има MMM, MRM или можете да проверите Group Replication или Galera (забележка:Galera не използва асинхронна, а синхронна репликация). Отказът в клъстер Galera не работи по същия начин, както при асинхронната репликация. С Galera можете просто да пишете на всеки възел или, ако приложите подход главен-подчинен, можете да насочите приложението си към друг възел, който ще бъде активният записващ за клъстера.
Drupal PostgreSQL отказ
Тъй като Drupal поддържа PostgreSQL, ние също ще проверим инструментите за прилагане на процес на отказ или превключване за PostgreSQL. PostgreSQL използва вградена поточно репликация, но можете също да го настроите да използва логическа репликация (добавена като основен елемент на PostgreSQL във версия 10).
Drupal Failover с помощта на pg_ctlcluster
Ако вашата среда е Ubuntu, използването на pg_ctlcluster е прост и лесен начин за постигане на отказ. Например, можете просто да изпълните следната команда:
$ pg_ctlcluster 9.6 pg_7653 promoteили с RHEL/Centos можете да използвате командата pg_ctl точно както,
$ sudo -iu postgres /usr/lib/postgresql/9.6/bin/pg_ctl promote -D /data/pgsql/slave/data
server promotingМожете също да задействате превключване при отказ на резервен сървър за доставка на журнали, като създадете тригерен файл с името на файла и пътя, посочени от trigger_file в recovery.conf.
Трябва да внимавате с промоцията в режим на готовност или подчинената, тъй като може да се наложи да се уверите, че само един главен приемник приема заявката за четене и запис. Това означава, че докато извършвате превключването, може да се наложи да се уверите, че предишният главен елемент е отпуснат или спрян.
Грижата за превключване или ръчно превключване на отказ от първичен към резервен сървър може да бъде бърза, но изисква известно време, за да се подготви отново клъстера за отказ. Редовното превключване от първичен към режим на готовност е полезна практика, тъй като позволява редовен престой на всяка система за поддръжка. Това също служи като тест на механизма за преодоляване на срив, за да се гарантира, че той наистина ще работи, когато имате нужда от него. Винаги се препоръчват писмени административни процедури.
Автоматично отказване на Drupal PostgreSQL
Вместо ръчен подход, може да се наложи автоматично преминаване при отказ. Това е особено необходимо, когато сървърът се повреди поради повреда на хардуера или повреда на виртуалната машина. Може също да изискате приложение да извърши автоматично превключване при отказ, за да намали времето за престой на вашето приложение Drupal. Сега ще разгледаме някои от тези инструменти, които могат да се използват за автоматично преминаване при отказ.
Drupal Failover с помощта на Patroni
Patroni е шаблон, с който можете да създадете свое собствено персонализирано решение с висока достъпност с помощта на Python и - за максимална достъпност - разпределено хранилище за конфигурация като ZooKeeper, etcd, Consul или Kubernetes. Инженерите на бази данни, DBA, инженерите на DevOps и SRE, които искат бързо да внедрят HA PostgreSQL в центъра за данни - или някъде другаде - ще се надяваме, че ще го намерят за полезно
Drupal Failover с помощта на Pgpool
Pgpool-II е прокси софтуер, който се намира между сървърите на PostgreSQL и клиент на база данни на PostgreSQL. Освен че има автоматичен отказ, той има множество функции, които включват пул на връзки, балансиране на натоварването, репликация и ограничаване на превишаването на връзките. Можете да прочетете повече за този инструмент в нашия блог от три части; част първа, част втора, част трета.
Drupal Failover с помощта на pglookout
pglookout е демон за следене на репликация на PostgreSQL и отказ. pglookout следи възлите на базата данни, тяхното състояние на репликация и действа според това състояние. Например, извикване на предварително дефинирана команда за преодоляване на срив за популяризиране на нов главен елемент в случай, че предишният липсва.
pglookout поддържа два различни типа възли, такива, които са инсталирани на самите db възли и наблюдателни възли, които могат да бъдат инсталирани навсякъде. Целта на pglookout на възлите на PostgreSQL DB е да наблюдава състоянието на репликация на клъстера и да действа съответно, наблюдателите имат по-ограничени правомощия:те просто наблюдават състоянието на клъстера, за да дадат друга гледна точка към състоянието на клъстера.
Drupal Failover с помощта на repmgr
repmgr е пакет от инструменти с отворен код за управление на репликация и отказ в клъстер от PostgreSQL сървъри. Той подобрява вградените възможности на PostgreSQL за горещ режим на готовност с инструменти за настройка на сървъри в режим на готовност, наблюдение на репликацията и изпълнение на административни задачи, като например превключване при отказ или операции за ръчно превключване.
repmgr предостави разширена поддръжка за вградените механизми за репликация на PostgreSQL, откакто бяха въведени в 9.0. Настоящата серия repmgr, repmgr 4, поддържа най-новите разработки във функционалността за репликация, въведена от PostgreSQL 9.3, като каскадна репликация, превключване на времевата линия и базово архивиране чрез протокола за репликация.
Drupal Failover с помощта на ClusterControl
ClusterControl поддържа автоматично преминаване при отказ за PostgreSQL. Ако имате инцидент, вашият подчинен може да бъде повишен автоматично до статут на главен. С ClusterControl можете също да разгръщате самостоятелна, репликирана или клъстерирана PostgreSQL база данни. Можете също така лесно да добавяте или премахвате възел с едно действие.
Други PostgreSQL Drupal Failover решения
Със сигурност има решения за автоматично преминаване при отказ, които може да съм пропуснал в този блог. Ако го направих, моля, добавете вашите коментари по-долу, за да можем да разберем вашите мисли и опит с вашето внедряване и настройка за отказ, особено за уебсайтове или приложения на Drupal.
Допълнителни решения за отказ на Drupal
Докато инструментите, които споменах по-рано, определено се справят с решението на проблемите ви с преодоляване на отказ, добавянето на някои инструменти, които правят преминаването при отказ доста по-лесно, по-безопасно и има пълна изолация между слоя на вашата база данни, може да бъде задоволително.
Drupal Failover с помощта на ProxySQL
С ProxySQL можете просто да насочите вашите Drupal уебсайтове или приложения към хоста на ProxySQL сървъра и той ще определи кой възел ще получава записи и кои възли ще получат четенията. Магията се случва прозрачно в TCP слоя и не са необходими промени за конфигурацията на вашето приложение/уебсайт. В допълнение към това, ProxySQL действа и като балансьор на натоварването за вашите заявки за запис и четене за трафика на вашата база данни. Това е приложимо само ако използвате варианти на база данни на MySQL.
Drupal Failover с помощта на HAProxy с Keepalived
Използването на HAProxy и Keepalived добавя по-висока наличност и излишък в базата данни на Drupal. Ако искате да преминете при отказ, това може да стане без вашето приложение да знае какво се случва в слоя на базата данни. Просто насочете приложението си към vrrp IP, който сте настроили във вашия Keepalived и всичко ще се обработва с пълна изолация от вашето приложение. Наличието на автоматично преминаване при отказ ще се обработва прозрачно и несъзнателно от вашето приложение, така че не трябва да се извършват промени, след като например е настъпило бедствие и е приложено възстановяване или превключване при отказ. Хубавото на тази настройка е, че тя е приложима както за MySQL, така и за PostgreSQL бази данни. Предлагам ви да разгледате нашия блог PostgreSQL Балансиране на натоварването с помощта на HAProxy &Keepalived, за да научите повече за това как да направите това.
Всички опции по-горе се поддържат от ClusterControl. Можете да разположите или импортирате базата данни и след това да разположите ProxySQL, MaxScale или HAProxy &Keepalived. Всичко ще бъде управлявано, наблюдавано и ще бъде настроено автоматично, без да е необходима допълнителна конфигурация от ваша страна. Всичко се случва във фонов режим и автоматично създава готов за производство.
Заключение
Наличието на постоянно работещ уебсайт или приложение на Drupal, особено ако очаквате голямо количество трафик, може да бъде сложно за създаване. Ако обаче разполагате с правилните инструменти, правилната настройка и правилния технологичен стек, е възможно да постигнете висока наличност и резервиране.
А ако не го направите? Е, тогава ClusterControl ще го настрои и поддържа вместо вас. Като алтернатива можете да създадете настройка, като използвате технологиите, споменати в този блог, повечето от които са с отворен код, безплатни инструменти, които биха задоволили вашите нужди.
