Поразени от пандемията от COVID-19, много МСП/МСП преминават към онлайн платформи. Уроците лице в лице или физическите също са засегнати от тази пандемия и много училища и университети също преминават към онлайн и търсят инструменти, които са налични за използване, за да продължат да служат на студентите или учениците, тъй като образованието да не бъде възпрепятствано. Една от известните платформи, които са достъпни за образователни онлайн или онлайн учебни цели, е Moodle.
Какво е Moodle?
Moodle е софтуер с отворен код за система за управление на онлайн обучение или LMS (известна още като виртуална среда за обучение или VLE) под лиценза на GPL. Тя позволява на преподавателите да създават свой собствен частен уебсайт, пълен с динамични курсове, които разширяват обучението по всяко време и навсякъде. Moodle има пълна поддръжка с лесен достъп и функции за учители, студенти или администратори.
Тъй като е с отворен код и безплатна софтуерна платформа, можете да използвате този софтуер безплатно и без такси за авторски права, точно както друг софтуер с отворен код. Разходите възникват само когато този софтуер се хоства на платена хостинг платформа или ако го хоствате с техния Moodle Cloud. Moodle се предлага и за преносими устройства като мобилни или таблети.
Защо имате нужда от високодостъпна база данни?
През 90-те години на миналия век беше изобретено много просто решение за висока достъпност (HA), а именно Heartbeat. Heartbeat клъстерът може да направи две неща:да наблюдава два възела (и не повече от два) и да е конфигуриран да стартира една или повече услуги на тези два възела. Ако възелът, който в момента е хоствал ресурсите, се повреди, той рестартира ресурсите на клъстера на останалия възел. Въпреки че първоначалната версия на Heartbeat нямаше наблюдение на самите ресурси, това се променя до пускането на Heartbeat 2.0 в началото на 2000-те, където позволява да се управляват повече от два възела към клъстера. По принцип това включва състоянието на Linux HA клъстериране, което се основава до голяма степен на Heartbeat 2.0. Оттук нататък много от решенията на HA бяха засегнати и бяха разработени и създадени, за да се сведе до минимум времето за престой, особено за критични ресурси.
Да бъдеш високодостъпен не означава само минимизиране на престоя. Той също така покрива степента на отговорност за възможността да работите и поддържате непрекъснато услугите, които предлагате и обещавате на клиентите си. Това, че сте на разположение на клиентите, не означава също, че сте способни да им отговорите, в случай че имат нужда от помощ. Той трябва да постави вашето бизнес приложение и система в напълно функционални, сякаш винаги е нормалното състояние на работа, дори ако се е случило безпрецедентно бедствие.
Не можете да управлявате вашето VLE приложение с Moodle, докато вашата база данни се поддържа. Ако имате само един сървър на база данни, което е много често срещано за лесна и лека настройка на приложения, след като сървърът изпадне, приложението ви спира. Ако имате клъстер от база данни, използващ репликация главен-подчинен, след това се сблъсквате с безпрецедентен инцидент, който на свой ред, че приложението ви пише на два главни устройства след инцидента, тогава това може да бъде огромна бъркотия, която от своя страна причинява повреда на данните на цялото ви бизнес приложение и слой данни. Ако е имало текущи плащания, извършени по това време, това може да бъде огромно бедствие и включва много работа при възстановяване на данни.
Така че защо вашата база данни трябва да е високодостъпна? Това е, защото трябва да бъде,
- Може да извършва поддръжка или планирано прекъсване по възможност и в рамките на разрешения прозорец за поддръжка
- Продължителността е жизненоважна и трябва да избягва престой, когато е необходимо
- SLA е важно по отношение на по-високата си степен за постигане на висококачествено обслужване на клиенти
- Осигурете непрекъснато обслужване и използваемост
- Няма единична точка на провал
- Възможност за извършване на отказ, когато главният елемент се счупи или се срине
- Избягвайте сценарий с разделен мозък, при който няколко майстори действат като активни писатели по едно и също време
Изграждане на клъстер от база данни
Сега, когато подчертахме важността на наличието на HA като план и като решение за вашия клъстер от база данни, особено за PostgreSQL, нека се съсредоточим върху изграждането на клъстера отгоре надолу, за да постигнем високо налична настройка, готова за настройка на приложението Moodle.
Инсталиране на PostgreSQL
Първо, защо PostgreSQL? PostgreSQL има големи предимства в сравнение с други бази данни, поддържани от Moodle. Въпрос на предпочитание е, ако трябва да обобщя, тъй като всички бази данни, поддържани от Moodle, са в състояние да обработват данните и също подлежат на оптимизация. Зависи от това колко квалифицирани и опитни използвате базата данни. Въпреки че да обобщим защо се използва PostgreSQL, това е надеждна база данни и нейният усъвършенстван софтуер с отворен код, особено в бази данни, които могат да бъдат сравнени с други доставчици, които са собствени, като Oracle и MS SQL. Той поддържа паралелизъм на заявки, може да управлява големи или огромни бази данни, има широка поддръжка за JSON и много повече. Можете да го разгледате тук за причините, поради които да изберете PostgreSQL. Сега нека продължим с инсталирането на PostgreSQL
За този блог ще използваме PostgreSQL 12, използвайки Ubuntu 18.04 (Bionic Beaver). След това, за настройка с висока достъпност, трябва да имате основен и поне резервен възел (реплика), за който той ще поеме управлението, след като главният изпадне.
- Настройте хранилището и ключа за подпис
sudo sh -c 'echo "deb http://apt.postgresql.org/pub/repos/apt $(lsb_release -cs)-pgdg main" > /etc/apt/sources.list.d/postgresql.list' wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add - - Инсталирайте сървъра PG 12
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Направете това и на целевата реплика, но трябва да я конфигурирате като резервна или реплика. Като алтернатива ви предлагам да използвате ClusterControl и да го изтеглите, тъй като е безплатен. Би било по-бързо и по-бързо да инсталирате и настроите основна/готовност. За моята настройка с помощта на ClusterControl и използване на раздела Topology view, получих следната топология:
Имайки настройка на главен/подчинен или първичен/готовност, няма означава, че сте напълно обхванати за клъстер от база данни с висока достъпност. Все още не е много достъпен. След като основното или главното устройство се повреди, не е задължително да се случи отказ. Друго нещо е, че няма балансиране на връзките от клиенти, които отиват към главен срещу подчинен. Въпреки че балансирането на натоварването между главен/подчинен не означава, че то трябва да бъде настроено или трябва да се приложи, за да се изпълни високодостъпна настройка. Наличието на балансиране на натоварването между главен/основен и подчинен/готовност помага на вашия главен възел да не натоварва високото натоварване, особено в часове с много голям трафик.
Настройване на балансиране на натоварването
Както споменахме по-рано, балансирането на натоварването между главен и подчинен помага на вашия главен човек да отдели натоварването. Не е идеално, ако оставите вашия режим на готовност да се използва само за репликация или ще поеме управлението, в случай че главният изпадне. Въпреки че това може да работи, обаче, това води до престой и ръчна работа, ако главният изпадне, тъй като трябва да превключите ролята на вашия резервен възел към главен. Това също е добре, но отново, наличието на балансьор на натоварването може да помогне за насочването на записите към главния, след това насочването на четенето между главния и подчинения. Това основно ви осигурява разделяне за четене/запис. За да направите това, има много опции, от които можете да избирате с PostgreSQL. По принцип най-често срещаната, но лесна настройка и е лека е използването на HAProxy.
Въпреки че има опции като използване на PgBouncer или pgpool-II. За простота на този блог, нека използваме HAProxy. За да инсталирате HAProxy, е доста лесно, ако използвате ClusterControl. Нека направим това чрез ClusterControl. За да направите това, можете просто да отидете в раздела Управление, изберете Load Balancer, както е показано по-долу,
Тъй като трябва да имаме високодостъпна настройка за вашия PostgreSQL клъстер от база данни, трябва да имаме поне два възела. Така че, ако вашият основен HAProxy възел се повреди, тогава пасивният или резервният HAProxy може да поеме. Да видим как изглежда от моята страна,
Въпреки че това изглежда добре. Тази настройка все още е недостатъчна. Ако смятате, че сме добри за високодостъпна настройка с тази топология, няма отказ в случай, че HAProxy изпадне на възел 192.168.30.222 на порт 9600 или ако 192.168.30.223:9600 се свали и ако приложението ви е настроено към това хост, все още има престой, ако не е направена проактивна настройка. Това означава, че имате престой, ако трябва да се настрои ръчно. В този случай ще използваме и настроим Keepalived, за да се следят отблизо HAProxy екземплярите за тяхното здраве и преминаване при отказ в случай, че другият възел срещне проблем.
Поддържане на високодостъпни балансьори на натоварване
Сега, когато имаме балансьори на натоварване отгоре на нашите бази данни, все пак се нуждаем от нашия HAProxy да е винаги жив, в случай че основният възел за крайната точка на приложението изпадне. По принцип това, което HAProxy може да направи с настройката, която имаме от предишния раздел, приложенията могат да използват 192.168.30.223 или 192.168.30.222 с портове 5433 (порт за четене-запис) и 5434 (порт само за четене) съответно. Сега има проблеми, в случай че трябва да превключите, в случай че другите възли изпаднат, плюс лошото е, че вреди на бизнеса, тъй като покрива времето за престой, ако няма автоматично превключване при отказ, което да се справи с него. Избягването на престой е най-добрият начин тук, освен ако нямате много нисък SLA и висок RTO и RPO.
За да облекчите подобно бедствие или престой, предлагаме да настроите Keepalived върху HAProxy. По принцип HAProxy ще балансира натоварването между четене и запис, при условие че вие разделяте четене и запис, а Keepalived следи само здравето на HAProxy възлите и ще успее да избере най-здравия възел според желаната конфигурация. Keepalived е инструмент, който можете да използвате, за да накарате HAProxy възлите да бъдат наблюдавани, въпреки че не е толкова сложно за управление на бази данни. Keepalived използва VIP (виртуален IP), който присвоява основния HAProxy възел по подразбиране и след това преназначава този VIP в случай, че основният HAProxy възел не успее и го насочва към следващия или резервен HAProxy възел.
Сега нека да настроим това с помощта на ClusterControl, тъй като е по-бързо и по-лесно за управление с ClusterControl. За да направите това, това е основно същият подход като начина, по който настройваме HAProxy, но вместо това изберете Keepalived, както е показано по-долу,
По принцип, ако инсталирате Keepalived ръчно, ние избираме основния срещу вторичният в случай, че първичният HAProxy не успее. Нека видим как изглежда нашият изглед на топология,
Това може да изглежда много обещаващо. По принцип клиентът на приложението Moodle ще се свърже с VIP, т.е. 192.168.30.201 под портове 5433 (порт за четене-запис) и 5434 (порт само за четене). Например, потвърждавайки го на външен хост, който имам,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5433
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)което разкрива, че само записващият възел, който имам, сочи към моя главен възел, т.е. 192.168.30.22. След това моят порт само за четене трябва да премине както към главни, така и към подчинени възли, както е показано по-долу,
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
SSL connection (protocol: TLSv1.2, cipher: ECDHE-RSA-AES256-GCM-SHA384, bits: 256, compression: off)
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.221
(1 row)
postgres=# \q
[[email protected] ~]# psql -h 192.168.30.201 -U dbapgadmin -W postgres -p 5434
Password:
psql (11.2, server 12.4 (Ubuntu 12.4-1.pgdg18.04+1))
WARNING: psql major version 11, server major version 12.
Some psql features might not work.
Type "help" for help.
postgres=# select inet_server_addr();
inet_server_addr
------------------
192.168.30.222
(1 row)Това разкрива, че както моите първични, така и резервни възли са идентифицирани като възли на базата данни за четене.
Сега това изглежда много обещаващо, както казах по-рано. Все пак тук липсва една част, която всъщност е много важна. Няма механизъм за преодоляване на срив на базата данни, който да е готов за този тип настройка. И все пак имаме Keepalived, който следи HAProxy и след това извършва отказ чрез превключване на VIP в случай, че основният HAProxy се повреди или умре. И все пак Keepalived не е настроен да се справи със сложната настройка, която има PostgreSQL. Има много приличен, който е наличен и безплатен за настройка. Можете да използвате Slony-I, система за репликация на трета страна.
Наличие на механизъм за отказване за вашия PostgreSQL клъстер
Има начини да осигурите механизъм за преодоляване на отказ за вашия PostgreSQL. Slony-I или обикновено наричан просто Slony е един от често използваните инструменти. Въпреки че Slony изисква вашата настройка да бъде логическа репликация, тъй като изисква настройка за издател/абонат, тя може да не е идеална за други настройки, които използват стандартна стрийминг репликация. Недостатъкът при използването на Slony е, че той не осигурява никакво автоматично откриване на неизправни системи или липса на поддръжка за ограждане на възли. Следователно, често наричан STONITH (застреляйте другия възел в главата или застреляйте неуспешния възел в главата), който по същество премахва неуспешния, за да не се избегнат сценарии с разделен мозък, при които множество главни възли (активни възли за запис) приемат записи на същото време. Въпреки че това може да бъде настроено по подходящ начин, все пак може да отнеме време и да е сложно, ако е създадено с по-малко опит и прозрения за това какви сценарии непременно ще се случат за PostgreSQL, когато възникне бедствие. За Slony, изоставянето на извършени транзакции е бизнес решение, което не може да бъде взето от система от база данни. Ако някой иска да постави командите по-долу в скрипт, изпълняван автоматично от системата за наблюдение на мрежата, той просто оставя на ваше собствено разположение, че това са вашите данни и е вашата политика за преодоляване на срив.
Алтернативно, ако търсите корпоративни опции, но все пак можете да вземете парите си на разумна цена, тогава ClusterControl има автоматично възстановяване за PostgreSQL клъстери. По принцип автоматичното възстановяване отговаря на посочените по-горе проблеми със Slony. Въпреки че нашето автоматично възстановяване е най-добре тествано с поточно репликация и се поддържа само за тип стрийминг репликация на настройка на PostgreSQL. И така, как работи? По принцип просто трябва да включите бутоните за автоматично възстановяване, както по-долу,
Това поддържа ограждане на възли, което означава, че ще събори неуспешния възел в случай възелът се връща жив по някаква неочаквана причина. Освен това, автоматичното възстановяване от ClusterControl поддържа възстановяване на възли и клъстери, че ако главен или подчинен възел е бил изключен случайно или убит, ClusterControl ще се опита да съживи това, особено ако се случи извън планирано прекъсване или прозорец за поддръжка. Тази функция ви предпазва от изчерпване на страховете от базата данни и в същото време ви осигурява проактивно наблюдение, което ще ви уведоми за евентуално бедствие, преди да е станало твърде късно за възстановяване.
Заключение
Достъпните настройки за вашия клъстер от база данни, особено за Moodle, могат да варират в зависимост от вида на настройката и изискванията, от които се нуждаете. Независимо дали разчита изцяло на безплатни технологии с отворен код или има други опции, които си струват парите за инвестиране за вашето корпоративно приложение, стига бюджетът да може да побере, тъй като може да ви осигури печеливша ситуация, особено ако искате само повече фокус от бизнес страна на нещата, отколкото да се фокусира върху други инструменти, като например администрация и devops тип работа.
