HPE Nimble – szinkron replikáció (végre)

A Nimble sok tekintetben egy kategória a 3PAR és más gyártók midrange tárolóival. Ezáltal nyugodtan mellé helyezhető bárminek, ami képes sub milliszekundum alatti késleltetéssel, kipréselni magából 300 ezer IOPS-ot. Mert ebben nagyon erős a termék, amellett hogy azért elég effektív deduplikációval és tömöríttéssel képes ténylegesen sokkal több használható területet adni, mint amennyi a fizikai kapacitásából adódna. (Az Infosight-ról már beszéltem, az tényleg csak a cseresznye a hab tetején).

Eddig minden szép és jó, de volt egy nagy gond. Sokszor feljött már ügyfeleknél, akár olyanoknál akik egyébként 3PAR-t használnak, bár annak inkább a pörgő lemezes változatát.

Ügyfél: Tud-e replikálni?
Én: Tud, aszinkron módon.
Ügyfél: De most a két 3PAR-unk szinkronban replikál.
Én: Akkor a Nimble jelen tudásában nem kiváltója a 3PAR-nak.

Viszont az ára szerint majdnem kiváltója, ugyanakkor a replikációs képességei eddig nem tették lehetővé, azt hogy azokat az ügyfeleket, akik megengedhetik maguknak, komolyan vegyék. Sok ügyfél van aki Peer Persistence-t használ, főleg VMware Metro Cluster-ben. Amit a 3PAR tud, azt a Nimble nem tudja. Nem a funkciót nem tudja, hanem a sokrétű beállíthatóságot. Akinek az kell, hogy beállíthassa a RAID6+2 szintet egy CPG-n és AO-t tekergessen, annak sosem lesz jó egy Nimble. Pont.

Na ne viccelj. Miért?

Mert a Nimble az egyszerűségre törekszik. Kell 22TB tárterület? Tessék. Mi lesz rajta, VMware? Oké, tessék. Dedup kell? Oké, deduplikálva lesz. Itt nem lehet az utolsó csavarig belenyúlni a rendszerbe, végképp nem kell megérteni a CPG-VirtualVolume-chunklet szentháromságot.

Na de akkor kinek jó ez?

Annak, aki tárhelyet akar, gyors tárhelyet, ráadásul úgy, hogy nem kell tudnia hogy csak 2 x 8 lemezesével lehet bővíteni a tárolót és hogy most akkor cage vagy magazine redundancia kell.

És végre pár hete bejelentették, hogy a szinkron replikáció képesség is bekerüla Nimble OS-be, valamikor 19Q1-ben. Ez a feature upgrade nem jelenti azt, hogy a Nimble tárolók nem tudtak 99.9999% rendelkezésre állást, mert tudtak – ráadásul ez nem bemondásra, az Infosight-ból az installált bázison alapulva, bizonyíthatóan. Viszont vannak olyan esetek, hogy bár a tároló tudja ezt a magas számot, de például a terem hűtése, az FC vagy ethernet switch-ek nem, az adatközpont nem stb. Az is igaz, hogy bár a tároló sosem áll meg, de akkor is egy darab eszköz – ezt kifejtettem már a Synergy-nél is. Ezért van olyan ügyfél, akinél a telephely a fault domain, ezért nekik szükségük van replikációra. Az aszinkron eddig is támogatott volt, minden Nimble eszközön, kiviteltől függetlenül. Ezzel is el lehetett már érni bizonyos szintű telephelyek közötti hibatűrést, de azért ez nem volt mindenkinek elég.

A szinkron replikáció megjelentésével kapcsolatban még néhány részlet azért ködös. Nyilvánvalóan mindkét oldalon azonos modell kell legyen – itt felmerül a kérdés, hogy ha a cél oldalon erősebb modell van, akkor az miért nem lehet jó.

IP és FC felett is megvalósítható a szinkron, továbbá nincs szükség plusz licenszre. Becsülendő dolog, hogy a termékben minden funkció bekapcsolható, nincs szürke checkbox sehol. Ezáltal például az újonnan érkező funkciók, így a szinkron replikáció is bekerül a már meglévő tárolók képességei közé.

Az első körben a VMware és MSSQL+Windows a támogatott, de biztosra veszem hogy pár hónapon belül az Oracle is menni fog. Ahogy az lenni szokott, szükség van quorum-ra/witness-re, ami itt is jó ha harmadik telephelyen van. Kevés az információ róla, hogy egy appliance vagy csak egy sima app ami Linux-ra kell telepíteni – gondolom ez utóbbi, pont mint a Simplivity-nél az arbiter, ami egy Windows app.

A replikáció volume szinten állítható be. Nem is értem, miért lenne pool vagy teljes tárolóra alkalmazható csak, nagyon rosszul skálázható az a storage, amin legalább ennyire nem granuláris.

 


Mindkét oldalon lévő hosztokon hasznáható az adott volume, mert az ehhez tartozó hoszt-controller útvonalakat ALUA segítségével kontrollálja a megoldás ezáltal azokat az útvonalakat aktívvá téve, amelyek az volume-ot aktívan kezelő tároló felé mutatnak.

A transzparens failover érdekében ez a tároló is képes átvenni a meghibásodott volume/tároló azonosítóit – iscsi esetén IQN, FC esetén WWN stb.

Hiszem, hogy ezzel picit több Nimble tároló lesz hazánkban, mert eddig ki lehetett zárni a terméket pár ilyen képesség hiánya miatt, de ezek mind-mind megoldódni látszanak. Az lenne igazán nagy dobás, ha feloldható lenne az hogy 3PAR csak 3PAR-ral, Nimble csak Nimble-el tud replikálni legalább aszinkron módon.