HPE Nimble-el kapcsolatos kérdések és válaszok – a keresések alapján

Rendszeresen nézem a keresési kifejezéseket itt a blogomon és bár angol a java ezeknek a szavaknak, azt gondolom érdemes őket megválaszolni, ha némelyik összetételre többen is keresni akarnak.

A Peer Persistence cikk és annak angol verziója – amely már 5000 megtekintésnél jár – nemzetközi viszonylatban rengeteg nem magyar ajkú látogatót hoz és ők rendszeresen megszórnak ilyen kifejezésekkel:

Bár tényleg nehéz kideríteni, mire gondolt a tisztelt kereső olvasó, de azért megpróbálkozom vele és angolul is megírom ezt a bejegyzést.

HPE Nimble witness-t érintő dolgok

Miért kell a witness? Kell-e egyáltalán?

A witness a peer persistence miatt kell, illetve annak ASO (automatic switchover) részéhez. A peer persistence csak egy kifejezés a sync replikáció és az automatikus átkapcsolás összefoglalására.

Nem kell mindig, szinkron replikációt a witness nélkül is lehet üzemeltetni, de az aktív volume-ot futtató Nimble kiesése esetén manuálisan kell az érintett kötetet aktívvá tenni a megmaradt Nimble tárolón.

Ha két replikációs kapcsolatban lévő Nimble párral tervezek, akkor hány darab witness kell?

Páronként egy, csakis egy. Egy witness ugyanakkor nem tud két párt kiszolgálni, csak egyet.

HA-t érintő dolgok

Alapvetően két HA eseményt tudok elképzelni:

Tárolón belüli HA esemény

Az egyik a tárolón belüli probléma, valamelyik kontrollerrel. Ez okozhat átállást az aktív kontrollerről a standby-ra. Ilyen akkor fordulhat elő, ha például tönkremegy a controller-ben például az NVDIMM, a kondenzátor stb.

Az átállási idő maximum 30 másodperc lehet, de az újabb Nimble OS verziókban a korábbi – méréseim szerinti – 20-25 másodpercet, már faragják lejjebb. Ezalatt sem veszik el semmi írás, de a hosztok nem kapnak ACK-t, amíg a failover meg nem történt és az új aktív controller vissza nem igazolja azt. Egyébként az ténylegesen kiemelt esemény, ha egy kontrollerrel üzemel egy ilyen tároló, mivel normál működés esetén IS csak akkor igazolja vissza egy írás sikerességét, ha a vele párban lévő standby controller NVDIMM moduljában is tárolásra került az írni kívánt csomag. Ha csak egy kontroller van “életben”, akkor ez nem így történik, ekkor a második kontroller meghibásodása – ha nincs ideje normálisan leállni vagy az NVDIMM modul DRAM chip-es oldaláról, a flash chip-es oldalára átmásolni az adatokat, akkor adatvesztés is lehet a vége. Így az egy kontrolleres működést el kell kerülni, ezért is kell rá támogatás.

Tárolók közötti HA esemény

Ha két tároló PP kapcsolatban van egymással, akkor minden egyes írás igazából négyszer kerül NVDIMM-be írásra. Az írást a hoszt oldalról fogadó tároló aktív kontrollere elküldi egyből deduplikálatlanul/tömörítetlenül a peer persistence párjának aktív kontrollerének. Amikor ez a tároló – azaz passzív volume-ot tartalmazó -, illetve annak aktív kontrollere visszaigazolja az írást az volume-ot aktívan tartalmazó, aktív kontroller-nek, na akkor igazolja vissza ez utóbbi a hosztnak az írást. Ezek után a kontrollerek, még a standby párjaiknak is átadják az írást, így lényegében négyszer lesz meg az IO.

Mi történik ha az aktív volume-ot kiszolgáló tárolóban az aktív controller megáll? Átkerül az addig készenléti kontrollerre a kiszolgálás.

HPE Nimble Peer Persistence whitepaper

Jelenleg még nincs ilyen. Annyi elmondható, hogy olyan OS-ek támogatottak, amelyeket a Nimble NCM támogat. Replikálni amúgy is csak IP-n lehet, RTT max 5ms, witness felé 250ms.

iSCSI replication configuration

A replikáció nem iSCSI-n történik, hoszt oldalon lehet iSCSI.

PP Limitations

Maximum 128 replikált volume lehet, hoszt oldalon a replikált volume minden esetben konzisztens protocol-on kell kiadni. Azaz ha az egyik tárolón egy volume FC-n van prezentálva, akkor a PP páron is FC-n lehet/kell kiadni. Egy PP-ben csak két tároló lehet.

Direct attach iSCSI

Nem támogatott. Csak FC-n lehet közvetlenül bekötni egy hosztot a Nimble tárolóra.

Különböző modellek

Alacsonyabb kategóriájú nem tud magasabbra replikálni – egyelőre. Például egy AF20 nem tud egy AF40-re szinkron replikálni.

Magasabb kategóriájú nem tud alacsonyabbra szinkron replikálni.

Azonos modell két almodell-je tud szinkron replikálni, pl HF20C tud HF20-ra replikálni és vissza.