A Citymobilnál a MySQL adatbázist használjuk fő állandó adattárolónkként. Számos adatbázis-klaszterünk van különféle szolgáltatásokra és célokra.

A master állandó rendelkezésre állása a teljes rendszer és egyes részei teljesítményének kritikus mutatója. Az automatikus fürt-helyreállítás fő hiba esetén nagymértékben csökkenti az incidensre adott válaszidőt és a rendszerleállási időt. Ebben a cikkben egy magas rendelkezésre állású (HA) tervezést fogok megvizsgálni egy MySQL-fürthöz, amely a következőn alapul MySQL Orchestrator és virtuális IP-címek (VIP).

VIP alapú HA megoldás

Először röviden elmondom, mi az adattároló rendszerünk.

Klasszikus replikációs sémát használunk egy írható mesterrel és több csak olvasható replikával. Egy fürt tartalmazhat egy köztes mestert – egy csomópontot, amely egyben replika és egyben mester is mások számára. Az ügyfelek a HAProxy-n keresztül érhetik el a replikákat, ami egyenletes terheléselosztást és egyszerű méretezést tesz lehetővé. A HAProxy használata történelmi okokra vezethető vissza, és jelenleg a ProxySQL-re való átállás folyamatban van.

A replikáció félszinkron módban történik az alapján GTID. Ez azt jelenti, hogy legalább egy replikának naplóznia kell egy tranzakciót, mielőtt sikeresnek minősül. Ez a replikációs mód optimális egyensúlyt biztosít a teljesítmény és az adatbiztonság között a fő csomópont meghibásodása esetén. Alapvetően minden változtatás átkerül a mesterből a replikákba Row Based Replication (RBR), de egyes csomópontok rendelkezhetnek mixed binlog format.

A hangszerelő rendszeres időközönként frissíti a fürt topológia állapotát, elemzi a kapott információkat, és ha problémák merülnek fel, elindíthat egy automatikus helyreállítási eljárást. Magáért az eljárásért a fejlesztő a felelős, mivel az többféleképpen is megvalósítható: VIP, DNS alapján, szolgáltatáskeresési szolgáltatások vagy saját maga által írt mechanizmusok használatával.

A mester visszaállításának egyik egyszerű módja, ha az nem sikerül, a lebegő VIP-címek használata.

Amit erről a megoldásról tudnia kell, mielőtt továbblép:

• A VIP olyan IP-cím, amely nincs társítva egy adott fizikai hálózati interfészhez. Ha egy csomópont meghibásodik, vagy az ütemezett karbantartás során, minimális állásidővel átkapcsolhatjuk a VIP-t egy másik erőforrásra.
• A virtuális IP-cím felszabadítása és kiadása olcsó és gyors művelet.
• A VIP használatához SSH-n keresztül kell hozzáférnie a szerverhez, vagy speciális segédprogramokat kell használnia, például, keepalived.

Nézzük meg a varázslónk lehetséges problémáit, és képzeljük el, hogyan kell működnie az automatikus helyreállítási mechanizmusnak.

Megszűnt a hálózati kapcsolat a mesterrel, vagy hardverszintű probléma lépett fel, és a szerver nem elérhető

1. Az Orchestrator frissíti a fürt topológiáját, és minden replika azt jelenti, hogy a mester nem érhető el. A hangszerelő elindítja az új mester szerepére megfelelő replika kiválasztásának folyamatát, és megkezdi a helyreállítást.
2. Megpróbáljuk eltávolítani a VIP-t a régi mestertől - sikertelenül.
3. A replika átvált a mester szerepére. A topológia újjáépítése folyamatban van.
4. Új hálózati interfész hozzáadása VIP-vel. Mivel nem lehetett eltávolítani a VIP-t, ezért rendszeres időközönként kérést küldünk a háttérben ingyenes ARP. Ez a fajta kérés/válasz lehetővé teszi, hogy frissítse az IP- és MAC-címek leképezési táblázatát a csatlakoztatott kapcsolókon, ezzel értesítve Önt, hogy VIP-ünk elköltözött. Ez minimálisra csökkenti a valószínűséget split brain amikor visszatér az öreg mester.
5. Minden új kapcsolat azonnal át lesz irányítva az új mesterhez. A régi kapcsolatok meghiúsulnak, és az adatbázis ismétlődő hívása az alkalmazás szintjén történik.

A szerver normál üzemmódban működik, hiba történt DBMS szinten

Az algoritmus hasonló az előző esethez: a topológia frissítése és a helyreállítási folyamat elindítása. Mivel a szerver elérhető, sikeresen felszabadítjuk a VIP-t a régi masteren, átvisszük az újra, és több ARP kérést is küldünk. A régi mester esetleges visszaadása nem érintheti az újjáépített klasztert és az alkalmazás működését.

Egyéb problémák

Replikák vagy köztes mesterek meghibásodása nem vezet automatikus műveletekhez, és manuális beavatkozást igényel.

A virtuális hálózati interfész mindig ideiglenesen kerül hozzáadásra, vagyis a szerver újraindítása után a VIP nem kerül automatikusan hozzárendelésre. Minden adatbázispéldány alapértelmezés szerint csak olvasható módban indul, a hangszerelő automatikusan írásra kapcsolja az új mestert, és megpróbálja telepíteni read only az öreg mesteren. Ezek az intézkedések a valószínűség csökkentését célozzák split brain.

Problémák merülhetnek fel a helyreállítási folyamat során, amelyeket a szabványos felügyeleti eszközökön kívül az Orchestrator UI-n keresztül is értesíteni kell. Kibővítettük a REST API-t ennek a funkciónak a hozzáadásával (PR jelenleg felülvizsgálat alatt áll).

A HA megoldás általános diagramja az alábbiakban látható.

Új mester kiválasztása

A hangszerelő elég okos, és próbál választani a legalkalmasabb másolat új mesterként a következő kritériumok szerint:

• a replika lemarad a mester mögött;
• A mester és a replika MySQL verziója;
• replikációs típus (RBR, SBR vagy vegyes);
• hely ugyanabban vagy különböző adatközpontban;
• elérhetőség errant GTID — a replikán végrehajtott tranzakciók, amelyek nem a masteren vannak;
• az egyéni kiválasztási szabályokat is figyelembe veszik.

Nem minden jel ideális mesterjelölt. Például egy replika használható adatok biztonsági mentésére, vagy a kiszolgáló gyengébb hardverkonfigurációval rendelkezik. Zenekar támogatja kézi szabályok, amelyekkel testreszabhatja jelöltválasztási beállításait a legelőnyösebbtől a figyelmen kívül hagyottig.

Válasz és felépülési idő

Incidens esetén fontos a rendszerleállás minimalizálása, ezért vegyük figyelembe azokat a MySQL paramétereket, amelyek befolyásolják a fürt topológia irányító általi létrehozását és frissítését:

• slave_net_timeout — azon másodpercek száma, ameddig a replika új adatokra vagy szívverésjelre vár, mielőtt a kapcsolat megszakadtként kerül felismerésre és újracsatlakozik. Minél alacsonyabb az érték, a replika annál gyorsabban tudja megállapítani, hogy a mesterrel való kommunikáció megszakadt. Ezt az értéket 5 másodpercre állítjuk.
• MASTER_CONNECT_RETRY — az újracsatlakozási kísérletek közötti másodpercek száma. Hálózati problémák esetén ennek a paraméternek az alacsony értéke lehetővé teszi a gyors újracsatlakozást, és megakadályozza a fürt helyreállítási folyamatának elindítását. Az ajánlott érték 1 másodperc.
• MASTER_RETRY_COUNT — az újracsatlakozási kísérletek maximális száma.
• MASTER_HEARTBEAT_PERIOD — másodpercben megadott intervallum, amely után a master szívverés jelet küld. Alapértelmezés szerint az érték fele slave_net_timeout.

A zenekari lehetőségek:

• DelayMasterPromotionIfSQLThreadNotUpToDate - ha egyenlő true, akkor a főszerep nem kerül alkalmazásra a jelölt replikán mindaddig, amíg a replika SQL-szála be nem fejezte az összes nem alkalmazott tranzakciót a továbbítási naplóból. Ezzel a lehetőséggel elkerüljük a tranzakciók elvesztését, amikor az összes jelölt replika lemarad.
• InstancePollSeconds — a topológia felépítésének és frissítésének gyakorisága.
• RecoveryPollSeconds — a topológiaelemzés gyakorisága. Probléma észlelése esetén elindul a topológia helyreállítása. Ez állandó, egyenlő 1 másodperccel.

Minden fürtcsomópontot minden alkalommal lekérdez a hangszerelő InstancePollSeconds másodpercig Probléma észlelésekor a fürt állapota kényszerül frissítve, majd megszületik a végső döntés a helyreállítás elvégzéséről. Különböző adatbázis- és hangszerelő-paraméterekkel kísérletezve a válasz- és helyreállítási időt 30 másodpercre tudtuk csökkenteni.

Próbapad

A HA séma tesztelését egy lokális fejlesztéssel kezdtük meg próbapad és további implementáció teszt- és gyártási környezetben. A helyi stand teljesen automatizált a Dockeren, és lehetővé teszi, hogy kísérletezzen a hangszerelő és a hálózat konfigurációjával, a fürt 2-3 szerverről több tucatra méretezhető, és biztonságos környezetben végezzen gyakorlatokat.

A gyakorlatok során a probléma emulációs módszerek egyikét választjuk: azonnal lőjük le a mestert kill -9, lágyan fejezze be a folyamatot és állítsa le a szervert (docker-compose stop), szimulálja a hálózati problémákat a használatával iptables -j REJECT vagy iptables -j DROP. A következő eredményeket várjuk:

• a hangszerelő észleli a mesterrel kapcsolatos problémákat, és legfeljebb 10 másodpercen belül frissíti a topológiát;
• a helyreállítási eljárás automatikusan elindul: a hálózati konfiguráció megváltozik, a mester szerepe átkerül a replikára, a topológia újraépül;
• az új mester írhatóvá válik, az élő replikák nem vesznek el az újraépítési folyamat során;
• megkezdődik az adatok írása az új mesterre és replikálása;
• A teljes helyreállítási idő nem haladja meg a 30 másodpercet.

Mint ismeretes, a rendszer eltérően viselkedhet teszt- és éles környezetben az eltérő hardver- és hálózati konfigurációk, a szintetikus és valós terhelések különbségei stb. miatt. Ezért rendszeresen gyakorlatokat végzünk valós körülmények között, ellenőrizzük, hogyan viselkedik a rendszer, ha a hálózati kapcsolat megszakad, vagy egyes részei leromlottak. A jövőben szeretnénk mindkét környezet számára teljesen azonos infrastruktúrát kiépíteni, és automatizálni a tesztelését.

Álláspontja

A fő tárolórendszer csomópontjának állapota az SRE és az üzemeltetési csapat egyik fő feladata. A VIP alapú orchestrator és HA megoldás megvalósítása a következő eredményeket tette lehetővé:

• az adatbázis-klaszter topológiájával kapcsolatos problémák megbízható észlelése;
• automatikus és gyors reagálás a mesterrel kapcsolatos incidensekre, csökkentve a rendszer leállási idejét.

A megoldásnak azonban megvannak a maga korlátai és hátrányai:

• a HA-séma több adatközpontra való méretezéséhez egyetlen L2-hálózatra lesz szükség közöttük;
• Mielőtt hozzárendelnénk a VIP-t az új mesterhez, ki kell engednünk a régire. A folyamat szekvenciális, ami növeli a helyreállítási időt;
• A VIP felszabadításához SSH-hozzáférés szükséges a szerverhez, vagy bármilyen más módszer a távoli eljárások meghívására. Mivel a szerver vagy az adatbázis olyan problémákat tapasztal, amelyek a helyreállítási folyamatot okozták, nem lehetünk biztosak abban, hogy a VIP eltávolítás sikeresen befejeződik. Ez pedig két, azonos virtuális IP-címmel rendelkező szerver megjelenéséhez és problémához vezethet split brain.

Elkerülni split brain, használhatja a módszert STONITH („Shoot The Other Node In The Head”), amely teljesen elszigeteli vagy letiltja a problémás csomópontot. Vannak más módszerek is a fürt magas rendelkezésre állásának megvalósítására: VIP és DNS kombinációja, szolgáltatásfelderítési és proxyszolgáltatások, szinkron replikáció és egyéb módszerek, amelyeknek megvannak a maguk hátrányai és előnyei.

Beszéltem a MySQL feladatátvételi fürt létrehozásának megközelítéséről. Könnyen kivitelezhető, és a jelenlegi körülmények között elfogadható szintű megbízhatóságot biztosít. Ahogy az egész rendszer általában, és különösen az infrastruktúra fejlődik, ez a megközelítés kétségtelenül fejlődni fog.

Forrás: will.com