Přehled replikace Apache HBase

Apache HBase Replication je způsob kopírování dat z jednoho clusteru HBase do jiného a případně vzdáleného clusteru HBase. Funguje na principu, že transakce z původního clusteru jsou tlačeny do jiného clusteru. V žargonu HBase se klastr provádějící push nazývá hlavní a ten, který přijímá transakce, se nazývá slave. Toto odeslání transakcí se provádí asynchronně a tyto transakce jsou dávkovány v konfigurovatelné velikosti (výchozí je 64 MB). Asynchronní režim vyžaduje minimální režii na hlavní a odesílání úprav v dávce zvyšuje celkovou propustnost.

Tento blogový příspěvek pojednává o možných případech použití, základní architektuře a režimech replikace HBase, jak jsou podporovány v CDH4 (který je založen na 0.92). Konfiguraci replikace, bootstrapping a odolnost proti chybám probereme v následném blogpostu.

Případy použití

Replikace HBase podporuje replikaci dat napříč datovými centry. To lze použít pro scénáře obnovy po havárii, kde můžeme nechat podřízený cluster obsluhovat provoz v reálném čase v případě, že hlavní web nefunguje. Vzhledem k tomu, že replikace HBase není určena pro automatické převzetí služeb při selhání, přepnutí z hlavního na podřízený klastr, aby bylo možné zahájit provoz, provádí uživatel. Poté, jakmile bude hlavní cluster opět spuštěn, je možné provést úlohu CopyTable pro zkopírování deltas do hlavního clusteru (poskytnutím časových razítek spuštění/zastavení), jak je popsáno v blogpostu CopyTable.

Dalším případem použití replikace je situace, kdy uživatel chce spouštět náročné úlohy MapReduce na svém clusteru HBase; lze tak učinit na podřízeném clusteru, zatímco u hlavního clusteru dojde k mírnému snížení výkonu.

Architektura

Základním principem replikace HBase je přehrání všech transakcí od hlavního k podřízenému. To se provádí přehráním WALEdits (položky protokolu zápisu dopředu) ve WAL (protokol zápisu dopředu) z hlavního clusteru, jak je popsáno v další části. Tyto úpravy WALEdit jsou odesílány na servery oblasti podřízeného clusteru po filtrování (bez ohledu na to, zda je konkrétní úprava určena pro replikaci či nikoli) a odeslání v přizpůsobené velikosti dávky (výchozí je 64 MB). V případě, že čtečka WAL dosáhne konce aktuální WAL, odešle všechny úpravy WALEdit, které byly do té doby přečteny. Vzhledem k tomu, že se jedná o asynchronní režim replikace, může podřízený cluster zaostávat za hlavním v aplikacích náročných na zápis v řádu minut.

WAL/WALEdits/Memstore

V HBase jsou všechny operace mutace (Puts/Deletes) zapsány do paměťového úložiště, které patří do určité oblasti, a také připojeno k souboru protokolu před zápisem (WAL)  ve formě WALEdit. WALEdit je objekt, který představuje jednu transakci a může mít více než jednu operaci mutace. Protože HBase podporuje transakci na úrovni jednoho řádku, jeden WALEdit může mít záznamy pouze pro jeden řádek. Hodnoty WAL jsou opakovaně rolovány po nakonfigurovaném časovém období  (výchozí je 60 minut), takže v daném okamžiku existuje pouze jedna aktivní WAL na regionální server.

IncrementColumnValue, operace CAS (kontrola a nahrazení), je také převedena na Put při zápisu do WAL.

Memstore je v paměti seřazená mapa obsahující klíčové hodnoty oblasti skládání; existuje jedno paměťové úložiště pro každou rodinu sloupců a oblast. Paměťové úložiště se vyprázdní na disk jako soubor HF, jakmile dosáhne nakonfigurované velikosti (výchozí je 64 MB).

Zápis do WAL je volitelný, ale je nutný, aby se zabránilo ztrátě dat, protože v případě selhání regionálního serveru může HBase ztratit všechna paměťová úložiště hostovaná na tomto regionálním serveru. V případě selhání regionserveru jsou jeho WAL přehrány procesem rozdělení logu, aby se obnovila data uložená v WAL.

Aby replikace fungovala, musí být povolen zápis do WAL.

ClusterId

Každý cluster HBase má clusterID, typ UUID automaticky generovaný HBase. Je uchováván v základním souborovém systému (obvykle HDFS), takže se mezi restarty nemění. To je uloženo v uzlu /hbase/hbaseid. Toto id se používá k dosažení master-master/acyklické replikace. WAL obsahuje položky pro řadu oblastí, které jsou hostovány na serveru regionů. Replikační kód čte všechny klíčové hodnoty a filtruje klíčové hodnoty, které jsou určeny pro replikaci. Dělá to tak, že se podívá na atribut rodiny sloupců klíčové hodnoty a porovná jej s datovou strukturou rodiny sloupců ve WALEdit. V případě, že je specifická hodnota klíče určena pro replikaci, upraví parametr clusterId hodnoty klíče na ID clusteru HBase.

Zdroj replikace

ReplicationSource je objekt Java Thread v procesu regionserver a je zodpovědný za replikaci položek WAL do konkrétního slave clusteru. Má prioritní frontu, která obsahuje soubory protokolu, které mají být replikovány. Jakmile je protokol zpracován, je odstraněn z fronty. Fronta priority používá komparátor, který porovnává soubory protokolu na základě jejich časového razítka vytvoření (které je připojeno k názvu souboru protokolu); protokoly jsou tedy zpracovávány ve stejném pořadí, v jakém byly vytvořeny (starší protokoly jsou zpracovávány jako první). Pokud je v prioritní frontě pouze jeden soubor protokolu, nebude odstraněn, protože představuje aktuální WAL.

Role správce zoo

Zookeeper hraje klíčovou roli v HBase Replication, kde spravuje/koordinuje téměř všechny hlavní replikační aktivity, jako je registrace slave clusteru, spouštění/zastavování replikace, zařazování nových WAL do fronty, zpracovávání regionserver failover atd. Je vhodné mít zdravý Kvorum Zookeeper (alespoň 3 nebo více uzlů), aby bylo neustále v provozu. Zookeeper by měl být provozován nezávisle (a nikoli HBase). Následující obrázek ukazuje příklad struktury znodes související s replikací v hlavním clusteru (text za dvojtečkou je data uzlu):

/hbase/hbaseid: b53f7ec6-ed8a-4227-b088-fd6552bd6a68
….
/hbase/rs/foo1.bar.com,40020,1339435481742:
/hbase/rs/foo2.bar.com,40020,1339435481973:
/hbase/rs/foo3.bar.com,40020,1339435486713:
/hbase/replication:
/hbase/replication/state: true
/hbase/replication/peers:
/hbase/replication/peers/1: zk.quorum.slave:281:/hbase
/hbase/replication/rs:
/hbase/replication/rs/foo1.bar.com.com,40020,1339435084846:
/hbase/replication/rs/foo1.bar.com,40020,1339435481973/1:
/hbase/replication/rs/foo1.bar.com,40020,1339435481973/1/foo1.bar.com.1339435485769: 1243232
/hbase/replication/rs/foo3.bar.com,40020,1339435481742:
/hbase/replication/rs/foo3.bar.com,40020,1339435481742/1:
/hbase/replication/rs/foo3.bar.com,40020,1339435481742/1/foo3.bar..com.1339435485769: 1243232
/hbase/replication/rs/foo2.bar.com,40020,1339435089550:
/hbase/replication/rs/foo2.bar.com,40020,1339435481742/1:
/hbase/replication/rs/foo2.bar.com,40020,1339435481742/1/foo2.bar..com.13394354343443: 1909033

            Obrázek 1. Hierarchie uzlů replikace

Podle obrázku 1 jsou v hlavním clusteru tři regionální servery, konkrétně foo[1-3].bar.com. S replikací souvisí tři uzly:

1. stav :Tento uzel říká, zda je replikace povolena nebo ne. Všechny základní kroky (např. zda zařadit nově srolovaný protokol do fronty replikace, přečíst soubor protokolu za účelem odeslání WALEdits atd.), před zpracováním zkontrolujte tuto booleovskou hodnotu. Toto je nastaveno nastavením vlastnosti „hbase.replication“ na hodnotu true v souboru hbase-conf.xml. Dalším způsobem, jak změnit jeho hodnotu, je použití příkazu „start/stop replikace“ v prostředí hbase. O tom bude řeč ve druhém příspěvku na blogu.
2. vrstevníci :Tento uzel má připojené vrstevníky/otroky jako děti. Na obrázku je jeden slave s peerId =1 a jeho hodnota je připojovací řetězec (Zookeeper_quorum_of_slave:Zookeeper_client_port:root_hbase_znode), kde Zookeeper_quorum_of_slave je čárkami oddělený seznam serverů zookeeper. Název peerId uzlu je stejný jako ten, který byl zadán při přidávání peer.
3. rs :Tento uzel obsahuje seznam aktivních regionserverů v hlavním clusteru. Každý uzel regionserver má seznam uzlů WAL, které mají být replikovány, a hodnota těchto uzlů protokolu je buď null (v případě, že protokol ještě není otevřen pro replikaci), nebo bajtový offset k bodu, kde byl protokol přečten. Hodnota bajtového offsetu pro znode WAL označuje bajtový offset odpovídajícího souboru WAL, do kterého byl přečten a replikován. Protože může existovat více než jeden podřízený cluster a postup replikace se může mezi nimi lišit (jeden může být například nefunkční), jsou všechny WAL obsaženy v peerId uzlu pod rs. Na obrázku výše jsou tedy uzly WAL pod are /rs//1, kde „1“ je peerId.

Režimy replikace

Existují tři režimy nastavení replikace HBase:

1. Master-Slave:V tomto režimu se replikace provádí jedním směrem, tj. transakce z jednoho clusteru se přenášejí do jiného clusteru. Všimněte si, že podřízený cluster je stejný jako jakýkoli jiný cluster a může mít své vlastní tabulky, provoz atd.
2. Master-Master:V tomto režimu je replikace odesílána v obou směrech, pro různé nebo stejné tabulky, tj. oba clustery fungují jako hlavní i podřízené. V případě, že replikují stejnou tabulku, lze si myslet, že to může vést k nikdy nekončící smyčce, ale tomu se lze vyhnout nastavením clusterId mutace (Put/Delete) na clusterId původního clusteru. Obrázek 2 to vysvětluje pomocí dvou shluků, jmenovitě Slunce a Země. Na obrázku 2 máme dva bloky představující dva shluky HBase. Mají clusterId 100, respektive 200. Každý z klastrů má instanci ReplicationSource odpovídající podřízenému klastru, do kterého se chce replikovat; zná cluster #Ids obou shluků.

   

               Obrázek 2. Slunce a Země, dvě shluky HBase

   Řekněme, že cluster#Sun obdrží čerstvou a platnou mutaci M na tabulce a rodině sloupců, která je určena pro replikaci v obou clusterech. Bude mít výchozí clusterID (0L). Instance zdroje replikace ReplicationSrc-E nastaví svůj cluster#Id na hodnotu id původce (100) a odešle jej do clusteru#Earth. Když cluster#Earth přijme mutaci, přehraje ji a mutace se uloží do jeho WAL, podle normálního toku. Cluster#Id mutace zůstává nedotčen v tomto souboru protokolu na cluster#Earth. Instance zdroje replikace na cluster#Earth, (ReplicationSrc-S, přečte mutaci a zkontroluje její cluster#ID pomocí slaveCluster# (100, rovno cluster#Sun). Protože jsou stejné, přeskočí tento záznam WALEdit.

3. Cyklický:V tomto režimu se nastavení replikace účastní více než dva clustery HBase a mezi libovolnými dvěma clustery lze nastavit různé možné kombinace master-slave a master-master. Výše uvedené dva případy dobře pokrývají; jedna rohová situace je, když jsme nastavili cyklus

   

   Obrázek 3. Nastavení kruhové replikace

Obrázek 3. ukazuje nastavení kruhové replikace, kde se shluk#Slunce replikuje do shluku#Země, shluk#Země se replikuje do shluku#Venuše a shluk#Venuše se replikuje do shluku#Slunce.
Řekněme shluk#Slunce obdrží čerstvou mutaci M a je zaměřen na replikaci ve všech výše uvedených klastrech. Bude replikován do clusteru#Earth, jak je vysvětleno výše v hlavní hlavní replikaci. Instance zdroje replikace na cluster#Earth, ReplicationSrc-V, přečte WAL a uvidí mutaci a replikuje ji do clusteru#Venus. Cluster#Id mutace je udržován nedotčený (jako klastr#Slunce), v klastru#Venuše. V tomto clusteru zdrojová instance replikace pro cluster#Sun, ReplicationSrc-S, uvidí, že mutace má stejné clusterId jako jeho slaveCluster# (od clusteru#Sun), a proto  to z replikace vynechá.

Závěr

HBase Replication je výkonná funkce, kterou lze použít ve scénáři obnovy po havárii. Byla přidána jako funkce náhledu ve verzi 0.90 a vyvíjela se společně s HBase obecně, s přidáním funkcí, jako je replikace master-master, acyklická replikace (obě přidány ve verzi 0.92) a povolení a zakázání replikace na úrovni peer. (přidáno za 0,94).

V příštím blogpostu probereme různé provozní funkce, jako je konfigurace atd., a další problémy s replikací HBase.