V důsledku pandemie COVID-19 přechází mnoho malých a středních podniků na online platformy. Tato pandemie postihuje také osobní nebo fyzické hodiny a mnoho škol a univerzit také přechází na online a hledají nástroje, které by bylo možné použít, aby i nadále sloužily studentům nebo žákům, protože vzdělávání nebýt bráněno. Jednou ze slavných platforem, které jsou k dispozici pro vzdělávací online nebo online vzdělávací účely, je Moodle.
Co je Moodle?
Moodle je software s otevřeným zdrojovým kódem pro online systém řízení výuky neboli LMS (také známý jako Virtual Learning Environment nebo VLE) pod licencí GPL. Umožňuje pedagogům vytvořit si své vlastní soukromé webové stránky plné dynamických kurzů, které rozšiřují výuku, kdykoli a kdekoli. Moodle má veškerou podporu se snadným přístupem a funkcemi pro učitele, studenty nebo administrátory.
Vzhledem k tomu, že se jedná o platformu s otevřeným zdrojovým kódem a svobodnou softwarovou platformou, můžete tento software používat zdarma a bez licenčních poplatků, stejně jako jiný software s otevřeným zdrojovým kódem. Náklady vznikají pouze v případě, že je tento software hostován na placené hostingové platformě nebo pokud jej hostujete v jejich cloudu Moodle. Moodle je také dostupný pro kapesní zařízení, jako jsou mobily nebo tablety.
Proč potřebujete vysoce dostupnou databázi?
V 90. letech 20. století bylo vynalezeno velmi jednoduché řešení pro vysokou dostupnost (HA), konkrétně Heartbeat. Cluster Heartbeat mohl v zásadě dělat dvě věci:monitoroval dva uzly (a ne více než dva) a byl nakonfigurován tak, aby na těchto dvou uzlech spouštěl jednu nebo více služeb. Pokud uzel, který aktuálně hostoval prostředky, vypadl, restartoval prostředky clusteru na zbývajícím uzlu. Ačkoli počáteční vydání Heartbeat nemělo žádné monitorování samotných zdrojů, toto se změnilo až do vydání Heartbeat 2.0 na počátku 21. století, kdy umožňuje spravovat více než dva uzly v clusteru. V zásadě to zahrnuje stav Linux HA clustering, který je z velké části založen na Heartbeat 2.0. Od této chvíle bylo ovlivněno mnoho řešení HA, která byla vyvinuta a vytvořena tak, aby minimalizovala prostoje zejména u kritických zdrojů.
Být vysoce dostupný neznamená pouze minimalizovat prostoje. Pokrývá také míru odpovědnosti za schopnost nepřetržitě provozovat a udržovat služby, které nabízíte a slibujete svým zákazníkům. To, že jste zákazníkům k dispozici, neznamená, že jste také schopni na ně reagovat v případě, že potřebují pomoc. Musí uvést vaši obchodní aplikaci a systém do plné funkčnosti, jako by to byl vždy normální provozní stav, i když došlo k bezprecedentní katastrofě.
Pokud probíhá údržba databáze, nemůžete svou aplikaci VLE ovládat pomocí Moodle. Pokud máte pouze jeden databázový server, což je velmi běžné pro jednoduché a nenáročné nastavení aplikací, jakmile server selže, vaše aplikace se zastaví. Pokud máte databázový klastr využívající replikaci master-slave, pak se setkáte s bezprecedentním incidentem, který střídavě po incidentu zapisuje vaše aplikace na dva mastery, pak to může být obrovský nepořádek, který následně způsobí poškození dat celé vaší podnikové aplikace a datová vrstva. Pokud by v té době probíhaly platby, mohlo by to být obrovskou katastrofou a vyžadovalo by to velké množství práce při obnově dat.
Proč tedy musí být vaše databáze vysoce dostupná? Je to proto, že to tak musí být,
- Schopnost provádět údržbu nebo plánovanou odstávku proveditelně a v povoleném intervalu údržby
- Doba provozu je životně důležitá a v případě potřeby je třeba se vyhnout prostojům
- SLA je důležitá z hlediska vyššího stupně pro dosažení vysoce kvalitních zákaznických služeb
- Poskytovat nepřetržité služby a použitelnost
- Žádný jediný bod selhání
- Schopnost provést převzetí služeb při selhání, když se hlavní server rozbije nebo zhroutí
- Vyhněte se scénáři rozděleného mozku, kde více mistrů působí jako aktivní spisovatelé současně
Vytváření databázového klastru
Nyní, když jsme zdůraznili důležitost mít HA jako plán a jako řešení pro váš databázový cluster, zejména pro PostgreSQL, zaměřme se na budování clusteru shora dolů, abychom dosáhli vysoce dostupné nastavení připravené pro nastavení aplikace Moodle.
Instalace PostgreSQL
Za prvé, proč PostgreSQL? PostgreSQL má velké výhody ve srovnání s jinými databázemi podporovanými Moodle. Mám-li to shrnout, je to otázka preferencí, protože všechny databáze podporované Moodlem jsou schopny zpracovávat data a jsou také předmětem optimalizace. Záleží na tom, jak zkušení a zkušení databázi používáte. Abychom shrnuli, proč používat PostgreSQL, jde o spolehlivou databázi a její sofistikovaný open source software zejména v databázích, které lze srovnat s jinými proprietárními prodejci, jako je Oracle a MS SQL. Podporuje paralelismus dotazů, je schopen spravovat velké nebo obrovské databáze, má širokou podporu pro JSON a mnoho dalšího. Zde se můžete podívat na důvody, proč si vybrat PostgreSQL. Nyní pojďme pokračovat v instalaci PostgreSQL
Pro tento blog použijeme PostgreSQL 12 pomocí Ubuntu 18.04 (Bionic Beaver). Pak pro nastavení vysoké dostupnosti musíte mít primární a alespoň záložní uzel (repliku), za který převezme řízení, jakmile hlavní zařízení selže.
- Nastavení úložiště a podpisového klíče
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 - - Nainstalujte server PG 12
# Update the package lists: sudo apt-get update # Install server and client apt install postgresql-12 postgresql-client-12
Udělejte to také na cílové replice, ale musíte ji nakonfigurovat jako pohotovostní režim nebo repliku. Případně vám doporučuji použít ClusterControl a stáhnout si jej, protože je zdarma. Bylo by rychlejší a rychlejší nainstalovat a nastavit primární/pohotovostní nastavení. Pro mé nastavení pomocí ClusterControl a pomocí karty Zobrazení topologie jsem získal následující topologii:
Máte-li nastavení master/slave nebo primární/pohotovostní režim, není znamená, že jste plně pokryti vysoce dostupným databázovým clusterem. Zatím není příliš dostupná. Jakmile primární nebo hlavní selže, nedojde k žádnému převzetí služeb při selhání. Další věc je, že neexistuje žádné vyvážení spojení od klientů, která jdou k masteru a slave. I když vyvažování zátěže mezi master/slave neznamená, že musí být nastaveno nebo musí být použito, aby bylo dosaženo vysoce dostupného nastavení. Vyvažování zátěže mezi hlavním/primárním a podřízeným/pohotovostním režimem pomáhá vašemu hlavnímu uzlu ztěžovat výkon při vysokém zatížení, zejména při velmi vysokém provozu.
Nastavení vyrovnávání zátěže
Jak již bylo zmíněno dříve, vyvažování zátěže mezi master a slave pomáhá vašemu masteru oddělit zátěž. Není ideální, když necháte svůj pohotovostní režim používat pouze pro replikaci nebo jej převezme v případě, že hlavní zařízení vypadne. I když to může fungovat, znamená to prostoje a manuální práci, pokud master selže, protože musíte přepnout roli vašeho pohotovostního uzlu na master. To je také v pořádku, ale opět platí, že vyvažování zátěže může pomoci nasměrovat zápisy na master a poté nasměrovat čtení mezi master a slave. To v podstatě poskytuje rozdělení čtení/zápisu. Chcete-li to provést, existuje mnoho možností, ze kterých si můžete vybrat s PostgreSQL. V zásadě nejběžnějším, ale jednoduchým a lehkým nastavením je použití HAProxy.
I když existují možnosti, jako je použití PgBouncer nebo pgpool-II. Pro jednoduchost tohoto blogu použijme HAProxy. Chcete-li nainstalovat HAProxy, je to docela jednoduché, pokud používáte ClusterControl. Udělejme to přes ClusterControl. Chcete-li to provést, přejděte na kartu Spravovat a vyberte Vyrovnávání zatížení, jak je uvedeno níže,
Protože potřebujeme vysoce dostupné nastavení pro váš databázový cluster PostgreSQL, měli bychom mít alespoň dva uzly. Takže pokud váš primární uzel HAProxy selže, může to převzít pasivní nebo pohotovostní HAProxy. Podívejme se, jak to vypadá na mé straně,
I když to vypadá dobře. Toto nastavení je stále nedostatečné. Pokud si myslíte, že jsme dobří pro vysoce dostupné nastavení s touto topologií, neexistuje žádné převzetí služeb při selhání v případě, že HAProxy selže na uzlu 192.168.30.222 na portu 9600 nebo pokud selže 192.168.30.223:9600 a pokud je vaše aplikace nastavena na toto Pokud nebylo provedeno žádné proaktivní nastavení, stále dochází k výpadku. To znamená, že máte výpadek, pokud jej musíte nastavit ručně. V tomto případě použijeme a nastavíme Keepalived, aby byly instance HAProxy pečlivě sledovány z hlediska jejich stavu a převzetí služeb při selhání v případě, že druhý uzel narazí na problém.
Udržování vysoce dostupných vyvažovačů zátěže
Nyní, když máme nad databázemi nástroje pro vyrovnávání zátěže, potřebujeme, aby naše HAProxy byla vždy naživu pro případ, že by selhal primární uzel pro koncový bod aplikace. V podstatě to, co HAProxy dokáže s nastavením, které máme v předchozí části, mohou aplikace používat 192.168.30.223 nebo 192.168.30.222 s porty 5433 (port pro čtení a zápis) a 5434 (port pouze pro čtení). Nyní je tu problém v případě, že potřebujete přepnout v případě, že ostatní uzly selžou, plus špatná věc je, že poškozujete podnik, protože pokrývá prostoje, pokud neexistuje automatické převzetí služeb při selhání, které by to řešilo. Vyhnout se prostojům je zde nejlepší cesta, pokud nemáte velmi nízkou SLA a vysokou RTO a RPO.
Aby se takové katastrofě nebo výpadku zmírnily, doporučujeme nastavit Keepalived nad HAProxy. HAProxy v zásadě zatíží rovnováhu mezi čtením a zápisem za předpokladu, že budete rozdělovat čtení a zápis a Keepalived pouze monitoruje stav uzlů HAProxy a dokáže vybrat nejzdravější uzel podle požadované konfigurace. Keepalived je nástroj, který můžete použít k vytváření uzlů HAProxy, které mají být monitorovány, i když to není tak složité pro správu databází. Keepalived používá VIP (virtuální IP), který se přiřadí výchozímu primárnímu HAProxy uzlu a poté znovu přiřadí tento VIP v případě, že primární uzel HAProxy selže a nasměruje jej na následný nebo záložní uzel HAProxy.
Nyní to nastavíme pomocí ClusterControl, protože pomocí ClusterControl je správa rychlejší a jednodušší. Chcete-li to provést, je to v podstatě stejný přístup, jako nastavujeme HAProxy, ale místo toho vyberte Keepalived, jak je znázorněno níže,
V zásadě, pokud nainstalujete Keepalived ručně, vybíráme primární proti sekundární v případě, že primární HAProxy selže. Podívejme se, jak vypadá naše topologie
To by mohlo vypadat velmi slibně. V zásadě se klient aplikace Moodle připojí k VIP, tj. 192.168.30.201 pod porty 5433 (port pro čtení a zápis) a 5434 (port pouze pro čtení). Například ověření na externím hostiteli, který mám,
[[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)což odhaluje, že pouze uzel spisovatele, který mám, odkazuje na můj hlavní uzel, tj. 192.168.30.22. Potom musí můj port pouze pro čtení přejít na hlavní i podřízené uzly, jak je znázorněno níže,
[[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)To ukazuje, že můj primární i pohotovostní uzel jsou identifikovány jako uzly "čtení databáze".
Nyní to vypadá velmi slibně, jak jsem řekl dříve. Přesto zde chybí jedna část, která je ve skutečnosti velmi důležitá. Neexistuje žádný mechanismus převzetí služeb při selhání databáze, který by byl připraven pro tento typ nastavení. Přesto máme Keepalived, který monitoruje HAProxy a poté provede přepnutí při selhání přepnutím VIP v případě, že primární HAProxy selže nebo zemře. Keepalived však není nastaven tak, aby zvládl komplexní nastavení, které má PostgreSQL. Existuje velmi slušný, který je k dispozici a zdarma k nastavení. Můžete použít Slony-I, replikační systém třetí strany.
Mechanismus převzetí služeb při selhání pro váš klastr PostgreSQL
Existují způsoby, jak zajistit mechanismus převzetí služeb při selhání pro váš PostgreSQL. Slony-I nebo běžně nazývaný jen Slony je jedním z běžných nástrojů, které se používají. Ačkoli Slony vyžaduje, aby vaše nastavení bylo logickou replikací, protože vyžaduje nastavení vydavatele/odběratele, nemusí být ideální pro jiné nastavení, které používá standardní streamovací replikaci. Nevýhodou používání Slony je, že neposkytuje žádnou automatickou detekci selhání systémů nebo žádnou podporu oplocení uzlů. Proto se běžně nazývá STONITH (zastřelte druhý uzel do hlavy nebo zastřelte neúspěšný uzel do hlavy), který v podstatě odbourá scénáře se selháním, aby se nevyhnuly scénářům rozděleného mozku, kde více hlavních uzlů (aktivních zapisovacích uzlů) přijímá zápisy na stejný čas. I když to lze vhodně nastavit, ale přesto to může být časově náročné a komplikované, pokud je vytvořeno s menšími zkušenostmi a přehledy o tom, jaké scénáře pro PostgreSQL nutně nastanou, když dojde ke katastrofě. Pro Slonyho je opuštění potvrzených transakcí obchodním rozhodnutím, které nemůže učinit databázový systém. Pokud někdo chce vložit níže uvedené příkazy do skriptu, který se automaticky spouští ze systému monitorování sítě, ponechává na vaší vlastní dispozici, že jde o vaše data a je to vaše zásada převzetí služeb při selhání.
Alternativně, pokud hledáte podnikové možnosti a přesto si můžete vzít své peníze za rozumné náklady, pak ClusterControl nabízí automatické obnovení pro clustery PostgreSQL. Automatická obnova v podstatě odpovídá na výše uvedené problémy se Slony. Ačkoli naše automatické obnovení je nejlépe testováno s replikací streamování a je podporováno pouze pro typ streamingové replikace nastavení PostgreSQL. Jak to tedy funguje? V podstatě stačí zapnout tlačítka automatického obnovení, jak je uvedeno níže,
Toto podporuje oplocení uzlů, což znamená, že v případě, že dojde k vyřazení selhávajícího uzlu uzel se vrátí živý z nějakého důvodu, který se neočekává. Kromě toho automatická obnova pomocí ClusterControl podporuje obnovu uzlů a clusteru, takže pokud byl hlavní nebo podřízený uzel náhodně vypnut nebo zabit, ClusterControl se pokusí to oživit, zejména pokud k tomu dojde mimo plánovanou odstávku nebo období údržby. Tato funkce vás ochrání před vyčerpáním obav z databáze a zároveň vám také poskytuje proaktivní monitorování, které vás upozorní na nějakou možnou katastrofu dříve, než bude příliš pozdě na zotavení.
Závěr
Vysoce dostupná nastavení pro váš databázový cluster, zejména pro Moodle, se mohou lišit v závislosti na typu nastavení a požadavcích, které potřebujete. Ať už je to čistě závislé na bezplatných a open source technologiích, nebo existují další možnosti, které stojí za to investovat peníze do vaší podnikové aplikace, pokud to rozpočet pojme, protože vám může poskytnout oboustranně výhodnou situaci, zejména pokud se chcete více soustředit na obchodní stránku věci, než se zaměřit na jiné nástroje, jako je administrace a typ práce devops.