Nimble CLI érdekességek

Két cikkben foglalkoztam már az Infosight képességeivel egy Nimble tároló tekintetében, de az a felhő….szálljunk most le kicsit a kontroller lelki világának a szintjére és préseljünk ki még több információt. Elsősorban olyanokat, amit a GUI-n egyáltalán nem mutat vagy éppen nem ilyen részletesen.

Kezdjük úgy, hogy belépünk rá SSH-n és kiadjuk az “array –info név” parancsot. Nálam a tároló neve, nemes egyszerűséggel nimble. A parancs egészen jó információt ad például arról hogy mennyi bővítő és port van benne. Azt is remekül kiírja, hogy pontosan mennyi helyet foglal az összes snapshot és hogy milyen magas arányban sikerül ezeken helyet megtakarítani – 201.7:1.

Kiemelten hasznos parancs ha rendszeresen aditálni szeretnénk azt, hogy ki és mikor lép be a tárolóra. A szép listát az “auditlog –list” kimenete adja, természetesen lehet intervallumra, felhasználóra és célra szűrni, tehát meg lehet nézni hogy a Veeam, reggel nyolc és kilenc között API-n lépett-e be.

Még a forrást is megmutatja ha részletesebb információt kérünk egy bejegyzésről.

Kedvenc parancsom a fizikai diszkeket kilistázó “disk –list“, a GUI-n is megtalálható ez, de ott csak úgy, ha az adott diszk fölé viszem az egeret a hardware tabon. Így könnyen dokumentálható a diszkek szériaszáma, az hogy állapotuk egyébként “okay”-e.

Az elmúlt pár hét történései alapján igen fontos, hogy a SMART információkat is könnyen ki tudjuk nyerni egy tárolóból is. Ezt az adott diszkre vonatkozó részletesebb információ kérésével tudjuk elővarázsolni, “disk –info szám“. Ha éppen kicseréltünk egy hibás lemezt, akkor például így is ellenőrizhető a rebuild állapota, megnézhető a diszk firmware verziója és a SMART adatok.

A következő parancs kimenete amúgy elég könnyen előállítható a GUI-ról is, de majd mindjárt megmutatom, hogy végül miért is használható. “fc –list” kiadása után a link sebességét mutatja, és persze a vonatkozó WWNN és WWPN azonosítókat.

Kérjünk részletesebbet az egyik portról, “fc –info port_name –ctrlr A/B“. Mit látunk, hát hogy nálam pl 8Gbit-et megy de amúgy 16Gbit-re lenne képes. Mi a FW a HBA-n, mi a fabric WWN. Illetve hogy milyen initiator-okkal van kapcsolatban a tároló ezen a porton.

Ha már az initiator-okról beszélünk, akkor tisztában kell lennünk a maximumokkal, mármint miből mennyit képes kezelni az általunk használt modell. Nem csak a maximumokat mondja el, hanem hogy mennyit használunk. “group –list_limits

Ha a kontrollereken lévő ethernet portok állapotáról szeretnénk részletesebbet akkor a következőt kell futtatni “ip –list” illetve “netconfig –list“. Látható melyik az aktív kontroller, mikor volt utoljára módosítás a hálózati konfigurációban. Külön király hogy a linkek aktuális sebességét is ki tudja írni.

A performance policy már biztosan ismerős, de hogyan kaphatnánk egy ablakban információt mindről? “perfpolicy –list” kiírja mindet, blokkméret caching és tömörítés részleteivel együtt. Ha bármelyikről még többet szeretnénk kérni akkor “perfpolicy –info policy neve” parancs után látjuk.

A “pool –info pool_neve” kiadja a pool részletes kapacitás/foglaltság/space saving adatait. Nálam a pool csak egy tárolót tartalmaz, de ha valakinél több van, akkor értelemszerűen ezek összesítettjét mutatja.

Ha több shelf van egy Nimble-re kötve akkor még inkább hasznos a következő, de nem hagyagolnám el akkor sem, ha csak a base modul van valahol. “shelf –list” amit futtatni kell és véleményem szerint elég hasznos információkat ad például a ventillátorok üzeméről és a kontrollerek hőmérsékletéről. Látható amúgy hogy nálam csak head shelf van és 24 lemezzel csak – félig van tele az all flash.

Ha a snapshot-okról szeretnénk megtudni bulk információkat, legfőképpen a foglalt méretükkel kapcsolatosan, akkor azt a “snap –list –volt volume_neve” kiadásával a leghatékonyabb kinyerni. Az utolsó oszlop írja at hogy valójában menniy adat van abban a snapshot-ban.

Ha az egyikről még többet szeretnénk megtudni, akkor “snap –info snapshot_neve -vol volume_neve” Az elért tömörítést leírja, ha éppen a snapshot ki van ajánlva valakinek, replikálva van, akkor az is látható. Az “Is Unmanaged” részről majd még lesz szó.

Na nézzünk egy kis részletes performanciát. Ebben a GUI is jó, de ha valaki tényleg mélyre akar menni akkor ezt illik SSH-n megtenni. Nézzük meg a tipikus IO méreteket, amiket egy volume “lát” a “stats –perf “volume_neve” –iosize –interval 60” segítségével.

Ha az összes diszk által kiszolgált írásra/olvasásra vagyunk kíváncsiak akkor “stats –disk all –hdr 1“. Ez kiírja és másodpercenként frissíti az adatokat. Ha csak egy lemez érdekel akkor –disk all helyett a diszk száma kell.

Nézzünk egy kis késleltetést például volume szinten “stats –perf “volume_neve” –latency –interval 60“. Bár kicsit rosszul tördeli, de látható a sorokban a read és write műveletek mellett a szekvenciális és nem szekvenciális – azaza random – műveletek mellett az oszlopokban a tipikis késleltetés.

Eddig csak kérdezgettünk, most állítsuk be a véleményem szerint lefontosabb dolgot, amit GUI-ról nem lehet beállítani. Említettem korábban az “Is unmanaged” tulajdonságot a snapshot-oknál. Egy snapshot akkor unmanaged, ha nem a replikációs vagy protection policy hozta létre, hanem valaki például kézzel vagy külső termék által. Ekkor ezek automatikusan a Nimble OS által nem törtlődnek majd és könnyen előfordulhat, hogy a rendszeren maradnak ezzel is helyet elvéve, teljesen feleslegesen. Ezeknek a korára lehet beállítani egy alapértelmezett értéket, ami alapból nincs konfigurálva egy Nimble tárolón, azaz a megőrzési idő a végtelen.

Ezzel a paranccsal például meg tudjuk nézni, hogy van-e jelenleg olyan snapshot ami öregebb 30 napnál “group -autoclean_unmanaged_snapshots check –snap_ttl_unit days –snap_ttl 30“.

Ha szeretnénk beállítani hogy például minden 30 napnál régebbit amit nem maga a Nimble OS schedule-je hozott létre, automatikusan töröljön, akkor azt a “group –autoclean_unmanaged_snapshots on –snap_ttl_unit days –snap_ttl 30” tudjuk megtenni. Szerintem ez fontos lépés, nem érdemes kifelejteni.