Szinkron replikáció és Peer Persistence beállítása – HPE Nimble

Egy hete tartottunk egy rendezvényt az 99999-nél, aminek keretében Vadon Péter kollégám prezentálta, hogy miért gondolja úgy, hogy a HPE Nimble kezd felnőni a nagyvállalati igényekhez. Mivel élő bemutató volt, VaPe megépítette és beállította a két HF20-as tárolónkat, hogy működjön a Peer Presistence.

A bekötés és az architektúra így néz ki:

A zöld kapcsolatok iSCSI és replikációs forgalomra használtak.

A piros kapcsolatok a menedzsment forgalomra használtak.

Kezdeném egy kis ismétléssel, mert fontos ezekre emlékezni, mielőtt bármiféle szinkron replikációban gondolkodnánk. Követelmények ezek, így ha csak egy nem teljesül, akkor nem lesz mód – vagy nem lesz támogatott – a szinkron replikáció, sem a Peer Persistence.

Követelmények

  • Azonos modellek: Csak azonos modellek között lehet Peer Persistence – továbbbiakban PP- egyelőre az alacsonyabb besorolású modell a komolyabb teljesítményűvel párban nem használható PP-re.
  • Csak IP felett lehet replikálni: Tehát a replikáció nem lehetséges FC kapcsolaton. Ez nem probléma az interfészek fajtája tekintetében, mivel minden Nimble tárolón van legalább kettő 10Gbit-T port. Az FC-s front end portokkal rendelkező telepítések esetén is csak IP felett lehet replikálni.
  • A group-ban lévő tárolók azonos protokolt kell használjanak, azaz vagy fibre channel-t vagy iSCSI-t. Keverni nem lehet őket.
  • A group kommunikációra, a replikációra, a menedzsmentre és az iSCSI-ra – ha van – használt hálózati szegmensek a két tároló esetén konzisztens L2-t kell alkossanak.
  • Lefeljebb 5ms RTT a két tároló között.
  • A witness telepítése egy harmadik telephelyen. Meglepő lesz, de ez opcionális, a PP-hez kell, mivel ott értelmezett az automatikus átállás, de ha csak szinkront akarunk megvalósítani, kézi átbillentéssel, akkor erre nincs szükség.

Nézzük a folyamatot:

  1. Első lépésként frissíteni kell a tárolókat NOS 5.1-re, melynek elérhetőségét a Nimble Support-nál nyitott jegyben lehet kérvényezni, a tároló azonosítójának megadásával.
  2. A két tároló egy group-ba vonása. Ezt nem mutatom be, mert akinek több Nimble tárolója van, annak már ismerős a folyamat. Egy group, az lényegében egy menedzsment entitás, ha ilyen kapcsolatban vannak a tárolók, akkor a már ismert web felület is eggyé válik, onnan látható és állítgatható mindkettő. Ekkor a management IP is az egyiken lesz aktív, kinevezve azt group leader-nek.

Látható, hogy a két tároló egy group-ba tartozik, a “HF” nevű group-ba, erről a CLI-ben meg is győződhetünk, illetve még több információt is kaphatunk:

3. (csak iSCSI tárolók esetén) Át kell állítani mindkét tárolón a “Volume Scoped Target”-et, “Group Scoped Target”-re. Ennek miértjében segít a következő táblázat:

Erre azért van szükség mert alapvetően egy tömb iqn-je kerül bele a kiajánlásba mint target, azonban ez nem jó, mivel itt a volume maga mozoghat a tárolók között, ezért a Nimble group IQN-je kell hogy belekerüljön.

Amennyiben nincsenek kötetek, akkor következhet a 4-ik lépés. Ha van(nak) akkor minden volume-ot unexport-álni kell (de szép szó) – kivenni az initiator group-okból őket, majd egyenként átállítani őket a “vol –edit –iscsi_target_scope” parancssal.

4. A Nimble Connection Manager telepítése a hosztokra. Nem szabad kihagyni, VMware esetén belekerül a megfelelő Path Selection Policy-t is beállítja, ami nagyon fontos.

5.Witness telepítése. Ez opcionális és az ASO-hoz kell (Automatic SwitchOver), azaz hogy az egyik tárolót érintő probléma esetén, az érintett kötetek automatikusan aktív állapotba kerüljenek a replikációs partneren. Ha erre nincs szükség, azaz elég a manuális online-ba állítás, akkor ezt a lépést ki is lehet hagyni. Mivel én Peer Persistence-t építek, ezért bemutatom. A witness komponens elérhető appliance formátumban is, de ha valaki maga szeretné feltelepíteni, akkor szüksége lesz egy CentOS-re, legalább 7.2-es verzióval. A két tároló a management IP-jéről el kell érje ez a witness gépet a 5395-es porton.

6. A witness beálíltása a Nimble menedzsment felületén.

Lehetséges tesztelni a beállítást, de CLI-n is meg lehet győződni a korrekt működéséről és elérhetőségéről.

7. Létre kell hozni a szükséges “Volume Collection” entitásokat. Elegendő egy is, de akkor csak a “Volume Collection” részét képző köteteket fogja replikálni egyik tárolóról a másikra, illetve ha failover történik, akkor a fordított irányban. Amennyiben az a cél, hogy bizonyos kötetek az egyik tárolón – példában HF01 – bizonyosak pedig a másodikon – példában HF02 – legyenek normál üzemben aktívak, akkor több ilyen Volume Collection kell.

Elsőször létrehozom a HF01->HF02 irányt:

Látható, hogy hiába nem választottam ki “No protection template”-et, akkor is létrejön majd 2 snapshot egy schedule mentén. Ez módosítható 1-re, de ha a “Do not replicate”-ot választom ki, akkor hibát dob. Nem világos, hogy miért kell egy snapshot.

Ami fontosabb, az az hogy a “Replication partner”-nél jót válasszunk ki. A fenti lépésben a replikációs partner a HF02, azaz a “NimbleHF01-to-HF02” “Volume Collection”-ban, a replikációs partner a HF02. Létrehozom a visszafelé párját is, azaz a HF02-n bizonyos köteteket, visszafelé fogok replikálni, ekkor a nevét én “NimbleHF02-to-HF01”-ben állítom be, a “Replication partner”-t pedig HF01-re. A végeredmény a következő:

8. Nincs más hátra, mint köteteket létrehozni az adott “Volume Collection”-ben. Több ilyet fogok létrehozni, az alábbi táblázat alapján:

Név Pool LUN IDMéret
Nimble-PP-LUN01-HF01HF01-Pool1500 GB
Nimble-PP-LUN02-HF02HF02-Pool2 500 GB
Nimble-LUN03-HF01 HF01-Pool 3 500 GB
Nimble-LUN03-HF02 HF02-Pool 4 500 GB

Az első két volume lesz replikált, a harmadik csak a HF01-en lesz tárolva, a negyedik sorban szereplő csak a HF02-n.

Amint létehoztuk, máris megjelenik a kötet és mindkét tárolón látható lesz, de csak az egyiken lesz “upstream” – azaz aktív – míg a másikon “‘downstream” – azaz standby/passzív.

A táblázatban szereplő második kötet lérehozása – Nimble-PP-LUN02-HF02:

Végül létrehozom a két nem replikált kötetet is:

A végső állapot így néz ki:

9. VMware beállítások, azaz formázzuk meg a kapott LUN-okat VMFS-re – csak az első példát mutatom meg. A követhetőség miatt, ezt pontosan úgy nevezem el, mint korábban a kiajánlott kötetet.

Ha minden jól megy akkor a végeredmény ez lesz a vSphere-ben – a felső négy datastore lokális:

Sikeresen beállítottuk a Peer Persistence kapcsolatot két Nimble tároló között és létrehoztunk két olyan datastore-t/LUN-t, amiket véd szinkron replikáció és a automatikus “failover”.

Tesztelés

Fentebb az architektúra-ábrán látható két virtuális gép, VM1 és VM2. VM1 a Nimble-PP-LUN02-HF01-en van, VM2 a Nimble-PP-LUN02-HF02-n. A két VMware ESXi hoszton a két virtuális gép szét van választva. Mindkettőben elindítok egy-egy IOmeter-t, négy worker-el a következő beállításokkal (16k, 50% random, 70-30 read-write):

Mindkét VM-ben stagnál a sebesség:

Nimble felületéről a két tároló kumulált teljesítménye:

Minden teszt után, megvárom hogy a tárolók szinkronizáljanak, visszaállítom az “upstream” kötetet arra a tárolóra, amelyen a teszt előtt megtalálható volt.

Első teszt: Menedzsment kapcsolat megszakadása

Az egyik tároló elveszti a kapcsolatot a witness-el, azaz mindkét kontrollere elveszti a menedzsment kapcsolatát.

Eredmény: nincs failover, nincs kiesés. A felület jelzi, hogy az adott portokok nincs kapcsolat, de a tároló továbbra is menedzselhető.

Második teszt: Az egyik tárolóból kihúzom az aktív kontrollert.

Azonnali failover a végeredmény, de a tárolón belül, a standby controller-re:

Mivel lokális failover történik, így végeredményben a virtuális gépek annyiban érintettek, hogy a VM2 IO-ja – ez volt azon a volume-on, ami alatt átadásra került a két azonos tömbben lévő controller között a kötet – 10-15 másodpercig “hold” on volt.

A peer kapcsolat továbbra is egészséges:

Harmadik teszt: Az egyik tároló mindkét tápegységét áramtalanítom.

A hibára adott válasz, teljes failover, azaz a peer persistence-el védett kötetek még a SCSI timeout előtt “upstream” állapotba kerülnek a HF01-en – az az egy, ami a HF02-n volt a hiba előtt “upstream”. Természetesen a nem replikált kötetek elérhetetlenné válnak:

A replikációban is látszik a probléma:

VMware oldaláról látszik két útvonal vesztése, amik a HF02-hez tartoznak:

A peer persistence-el védett köteteken virtuális gépek annyiban érintettek – ebben az esetben is VM2-ről van szó, hogy IO-ja, 10-15 másodpercig “hold” on volt, amíg a tárolók között megtörténik a váltás.

Egyéb érdekességek

Mi történik, ha kihúzunk két lemezt és felcseréjük őket egymással? Semmi, minden működik tovább, a tároló továbbra is egészséges.

Mi történik ha kiveszünk két SSD-t – ami az olvasási cache hibrid esetén? Szintén semmi, azon kívül hogy jelzi a hibát. Teljesítményben nincs különbség, bár nyilvánvalóan a FDR – Flash Disk Ratio – lejjebb megy az egészséges 15%-ról.

Mi történik ha kiveszem mind a 21 HDD-t és megkeverve visszarakom? Semmi! Ez a legkomolyabb trükk 🙂

Egyéb részletek

A replikált kötetekre történő írás, a forrás tárolóról a tárolóra deduplikálatlanul és/vagy tömörítetlenül kerülnek átvitelre. Így a forrás tároló aktív kontrollerében található NVDIMM-be kerülő írási művelet, azonnal átvitelre kerül a cél tároló aktív kontrollerének NVDIMM moduljába, majd a két tömb maga birkózik meg a tömörítés/deduplikáció CPU cycle szükségletével. A késleltetés sokkal fontosabb mint a replikációs forgalom mennyisége.

Az is lényeges, hogy szinkron replikált köteteket átméretezni nem lehet, ezért érdemes jól választani. Ha mégis növelni kell, akkor meg kell törni a szinkronizációt, növelni a kötetet és újra hozzáadni a szinkronizációt jelentő Volume Collection-höz.

Összegzés

Alapvetően megbízhatóan működik a HPE Nimble peer persistence, egy esetben tapasztaltunk hibát az átállásban. Összesen 20 darab teljes failover-t eredményező eseményt hajtottam végre, abból 19 esetben nem volt kiesés.

Ez betudható annak a ténynek, hogy a jelenlegi 5.1.1 Nimble OS, amely támogatja a szinkron replikációt (PP), még csak IPR (Initial Production Release), azaz a gyártó sem ajánlja még üzleti kritikus környezetbe. GA (General Availability) release-nél már az összes gyermekbetegség javításra kerül és telepíthető, akár kritikus rendszerekre. A frissítési folyamatot az InfoSight kezeli, ezzel is biztosítva, hogy az adott tárólóra csak olyan FW telepítését engedélyezi, amely az adott környezetben a legstabilabb. Maga a beállítás és üzemeltetés igazán egyszerű, tényleg intuitív.