HPE Nimble – első rész

Előrebocsátom, nem vagyok storage-es szakember, tudok amit tudok a VSAN-ról, Nutanix-ről és egyéb SDS közeli termékekről, de ez most kivétel.

Most több okból kifolyólag, de kapcsolatba kerültem egy újabb termékkel, amelyet a HPE felvásárolt, ezúttal a Nimble személyében, hova tovább rögvest vettünk is egy all flash modellt bemutatóra használható eszközként. A HPE TSS-en minden Nimble előadást tágra nyitott szemekkel figyeltem – aki ismeri Rich Fenton-t ő még ráadásul jó előadó is – hogy mégis mi ez a cucc, amelynek IOPS teljesítménye NEM függ a lemezek számától. Első mondásra ez így elég erős, lévén szó hogy ez hibrid – azaz SATA plusz SSD – tömbökre is igaz. Fel nem bírtam elsőre fogni, hogy mégis hogyan lehet ez, aztán olyan kazalnyi olvasgatás után végülis világossá vált, hogy a Nimble architektúrája elsősorban CPU limites. Bizony, nincs új a nap alatt, mint sokan mások Xeon processzorokkal operálnak, viszont amiben nekem tetszik, az az hogy az egész zsonglőrködést NVDIMM-ben intézik.

Lényegében minden kontroller-ben van 1 vagy 2 Intel Xeon processzor, valamennyi RAM és NVDIMM modul is – a mi kis AF1000 modellünkben 8GB NVDIMM van. Minden Nimble modellben két kontroller van, nincs hely többnek.

A Nimble-ben ezt a trükköt CASL-ként hívják (Cache Accelerated Sequential Layout). Mikor egy írás beérkezik az aktív kontroller egyik hoszt portjára, az bekerül az NVDIMM-be, áttükröződik a standby kontroller NVDIMM moduljára, majd visszaigazolásra kerül a hoszt számára, hogy az IO kérelem kiszolgálásra került. Ezek után történik a mágia, itt deduplikálódik, tömörítődik, majd mikor összegyűlik 10 MB-nyi anyag, akkor szekvenciálisan kiírja a lemezekre – függetlenül attól hogy azok SATA lemezek vagy SSD-k. Ebben a SATA lemezek is elég jók, szekvenciálisan írni, főleg ha sok van belőlük. Az hogy milyen szervezésben vannak, nem állítható, ebben a tekintetben aki ennyire mélyen szeretne belenyúlni a tárolók lelki világába, nem ez a jó választás, vegyen mást.

Tehát mi is itt a varázslat? Az az hogy az írási IO legyen az bármilyen random, sorbarendeződik, aztán szekvenciálisként kerül tárolásra. Ebben a tekintetben teljesen mindegy, hogy a tárolót hogyan terheljük, a vége úgyis szekvenciális terhelés lesz – legalább is a lemezek szempontjából.

Ahol a hibrid és a teljesen flash elválik, az az olvasás. Az all flash esetén nincs read cache, minden olvasás SSD rétegből jön, ellentétben a hibrid modellekkel, ahol az olvasás késleltetése függ attól, hogy a tároló megfelelően méretezett, illetve hogy a caching algoritmus jól végzi-e dolgát. Ezért is fontos az, hogy egy LUN kiajánlásakor a megfelelő típust válasszuk ki, mivel annak befolyása van lényegében a deduplikációtól a caching-ig mindenre. Lehet valamennyire tuningolni, például cache pinning-et alkalmazni, ahol a volume/LUN lényegében a cache-ben marad, de ez azért csak kivételes esetekben javasolt – szerintem.

Alapvetően már csak két ízben kaphatóak. Ezeket az különbözteti meg, hogy hibrid vagy teljesen flash kiépítettségűek. Éppen most volt modellfrissítés, szóval kicsit kellemetlen hogy az AF1000-en tesztelek és írom amit írok, miközben már nem is vásárolható meg többé.

Adaptive Flash – ez a hibrid – régebbi terminológiában ezek a CS modellek, most átneveződtek HF-re és az eddigi négyjegyű azonosító, lecsökkent kétjegyűre.

All Flash modellek – ezek maradtak AF jelöléssel, szintén négy helyett kettő karakterrel.

Az egyes modelleket alapvetően a belőlük kivehető IOPS és a tárhely – és ennek bővíthetősége – különbözteti meg egymástól. Tehát az AF20 22.500 IOPS-ra képes, míg az AF40 125.000-re.

Ami egyedivé teszi a terméket az a bővíthetőség többféle lehetősége:

  • kevés az IOPS – akkor csak ki kell cserélni a két kontrollert, nagyobbra. Ez nem jár kieséssel, körülbelül 5 perc alatt kivitelzhető.
  • kevés a kapacitás – újabb disk shelf-et kell betenni, bekötni őket a SAS kábelekkel – két loop van. A modell meghatározza a maximális disk shelf-ek számát azonban. AF60-hoz és AF80 már kettő kapcsolható, a kissebb modellekhez csak egy. HF fronton jobb a helyzet, ott mindegyikhez hat disk shelf kapcsolható.
  • kevés a kapacitás/kevés az IOPS, de már kinőttem a legnagyobb modellt és a teljes kiépítettséget. Ebben az esetben 4 darab – AF és HF mehet vegyesen – szervezhető egy klaszterbe, ezzel lehetővé téve az 1.200.000 IOPS-ot és 3260TB effektív kapacitást.

Az InfoSight is megér egy misét, amennyiben megengedjük hogy teljesen biztonságos csatornán keresztül, jól meghatározott portokon és célhoz csatlakozhasson, egészen okos dolgokat képes nyújtani a felhős menedzsment ami a termékhez jár. Használata mind a HPE-nek, mind az ügyfélnek egyaránt előnyös. A HPE adatokat nyerhet az eszköz rendelkezésreállásáról, arról hogy milyen deduplikációs arány elérésére képes adott workload mellett – ezzel is segítve azt a kalkulációt amivel az effektív kapacitást igen jó közelítéssel vállalni tudja. Az ügyfél számára pedig a frissítések személyreszabott változata vehető igénybe, azaz ha az ügyfél konfigurációjában egy frissítés például problémákat okozhat, akkor az InfoSight azt automatikusan képes blacklist-re tenni. A fejlett machine learning és analitika segítségével korrelációban a többi telepített Nimble eszközzel korrelálva képes prediktíven jelzni a később esélyesen kialakuló problémákat. Azt hiszem megéri az hogy kinyissuk a tűzfalat és megírjunk pár processz doksit, hogy az IT biztonság is rányomja a pecsétet.

Mikor egy LUN-t kiad a Nimble, akkor szükséges megadni, hogy milyen workload kerül majd arra a kötetre. Ez meghatározza a blokkok méretét, a deduplikáció és tömörítés állapotát és azt ha használunk quota-kat akkor annak meghaladásakor az elvárt reakciót.

Az így előálló információk alapján képes az InfoSight arra, hogy igen jó közelítéssel képes legyen megmutatni a jellemző deduplikációs arányt.

És akkor a tesztek. Mivel az első dolgunk volt minden fontos virtuális gépünket áttenni rá, ezért a mérések idejében egy nem túl magas, de 60 virtuális gép átlagos terhelése már rajta volt a tárolón.

IOmeter használatával végeztem a teszteket a következő beállítások mellett:1 worker, 64 Outstanding IO/target, 300 másodperc/teszt

32KB blokkméret – 100% olvasás – 100% szekvenciális

8KB blokkméret – 65% olvasás – 35% írás – 40% szekvenciális – 60% random

32KB blokkméret – 50% olvasás – 50% írás – 100% szekvenciális

8KB blokkméret – 70% írás – 30% olvasás – 100% random

A következő részben a replikációról lesz szó….