HPE Nimble – második rész – Infosight

Egy tároló beüzemelése és alapbeállítása sokszor nem igényel túl sok erőforrást vagy komplex ismeretet. Nyilván a méretezés és konfiguráció összeállítása igen, de azért van olyan tároló a piacon, ahol az Out of the Box folyamat egészen egyszerű. Ilyen a Nimble is egyébként. Ahol a probléma kezdődik, az az üzemeltetés során elvégzendő felügyeleti feladatok (kapacitás és teljesítmény-menedzsment) és a hibakeresés. Ez utóbbi kapcsán nem az a bonyolult ha a tároló egyébként teljesen elérhetetlen, hanem ha egy köteten az írás például lassú, nem megy a replikáció, mikor telik meg az a kiadott datastore ha így növekszik a foglalt terület.

A Nimble tároló beépített menedzsment felülete is sok információt ad, könnyen megérthető formában, de ha elfogadjuk hogy az Infosight rendszerbe is küldhet telemetria adatokat, akkor lehet igazán okos dolgokat kinyerni a monitoring adatokból.

Tehát mikor belépünk a tároló webes felületére ez fogad:

A legfontosabb információkat látjuk, késleltetés, IOPS és átviteli sebesség, szabad hely, deduplikációs és tömörítési arány, védelemmel kapcsolatos dolgok, a hardver állapota és egy apró sor az alján, ha van elérhető frissítés. (részletesen majd egy következő posztban ismertetem mit és hogy kell itt használni)

Természetesen a teljesítménnyel és kapacitással kapcsolatos információk is elérhetőek – valós időben – azonban az elemzési logika, AI vagy a fejlettebb riportokhoz szükség van valami másra, valami olyan rendszerre ami nem a tárolót terheli a sok mérési adat tárolásával és az azokon végzett számításokkal, modellezéssel.

Ezt biztosítja az Infosight. Már itt fontos kijelenteni, hogy az Infosight read only felület, abban a tekintetben, hogy olyan akciók nem hajthatóak végre ott, amelyek visszahatással lennének a tárolóra. Az is lényeges, hogy a telemetria engedélyezése kell hozzá, azaz a tároló bizonyos információi – szériaszám, IP, virtuális gépek neve, kötetek neve, ESXi/HyperV gépek neve stb. – elküldésre kerülnek, természetesen az adatvédelmi szabályok betartásával.

Engedélyezni tehát explicit kell – proxy használható ha kell – illetve még az is eldönthető, hogy akarunk-e nyitni egy biztonságos csatornát a HPE Nimble support számára, hogy ha szükséges úgy is tudjanak segíteni a probléma megoldásában – később is be lehet kapcsolni ha szükségét érezzük.

Az Infosight-tól függetlenül én mindenképpen javaslom a VMware integráció konfigurációját – az Infosight-hoz is jól jön egyébként – hogy például a vCenter Server-be beépülő modullal legyen lehetséges végrehajtani a datastore-okon végzendő műveleteket, anélkül hogy a tároló menedzsmentjét kellene erre használni. Amennyiben VVol-t is használunk, akkor a VASA provider-t is telepíti automatikusan.

Ha ezeket beállítottuk – és már van Infosight hozzáférésünk, továbbá a vásárlás összekapcsolható az Infosight regisztráció során megadottakkal – akkor már látni is lehet a tárolót az Infosight oldalon. (https://infosight.hpe.com)

De mielőtt rátérnék a részletekre egy dolgot még be kell állítani, nekem elment pár órám azzal, hogy nem jelentek meg a VMFS köteteken a VM-ek a rendszerben. Használunk VVol-okat is, azokkal nem volt gond, de ott minden VM-et alkotó komponens egy egy objektum, ezáltal “lényegében” külön volume is. Szóval ezt a beállítást én a tároló felületén kerestem, de végül – furcsa azért – az Infosight oldalon találtam meg.

Itt kell beállítani a “Streaming” kapcsolót, illetve a VMware gépekkel kapcsolatos diagnosztikai információk elküldését.

Ha ezek megvannak, akkor el kell telnie 24-48 órának, hogy az ilyen szintű adatok megjelenjenek az oldalon, egyébként minden más, ami ezek nélkül elérhető a tároló beállítását követő 1-2 órában feldolgozásra kerül és elérhető az oldalon. A vCenter API-t használja egyébként és segítségével képes kinyerni a következő adatokat:

  • VM késleltése – ez nem tudom értelmezni de gondolom a VM komponenseinek átlagolt késleltetése
  • Host CPU, memória és késleltetés
  • VMDK IOPS, MBPS és késleltetés
  • Datastore IOPS, MBPS és késleltetés

Ezeken a mérési adatokon alapulva már futtatható sokféle elemzés – ami akár automatikus eszkalációig is vihető – illetve összetettebb kép alakítható ki a teljesítményről.

  • Az ESXi hosztokat képes azonosítani, megmondani melyik túlterhelt CPU,RAM tekintetében – még a ballooning-ot is tudja 😀
  • A VMFS datastore-okon vizsgálni az egyes VMDK-k IOPS/Latency adatait (itt esett le az állam és ezért is kell fentebb a VMware diagnostics data bekapcsolása)
  • A zajos VM-ek felderítése (noisy neighbours)

Na de hogy is néz ki maga az Infosight? Már a főoldalon érdekességeket tár elénk. Itt például az látható, hogy van olyan virtuális gép, ami rengeteget ír, olyan is aminél a latency 5ms, ráadásul ezek a gépek mind VMFS datastore-on vannak, tehát egy LUN-ként kiajánlott a Nimble szempontjából, mégis tudja melyik VM, melyik VMDK fájljában történik aktivitás.

Látható a tároló egészségi állapota, az hogy ad e életjelet, jönnek e telemetria-adatok. Bármelyik virtuális gépre rákatttinva, átvált egy részletesebb nézetre amiben egész mélyen el lehet veszni. A késleltetés itt például felöleli a tároló, a tároló és az ESXi kiszolgáló közötti hálózat és maga a virtualizációs réteg komponenseit is és lebonva látjuk, hol kell keresni a hibát, ha például van egy hibabejelentésünk hogy lassú a VM. Ha egy VM több VMDK lemezzel rendelkezik, akkor a VMDK szintre is le lehet menni, tehát ha az SQL alatt a log drive problémás, akkor meg fogjuk találni és nem csak találgatunk hogy melyik kötettel van baj.

Válthatunk Datacenter, Cluster, ESXi, Datastore és VM nézebe is. Ami nekem igazán tetszik, hogy például a Datastore nézet nagy segítség a VMFS-LUN-Tárolón kiadott volume összerendelés meghatározására. Sokszor azt látom, hogy a VMware admin elnevezi valahogyan a datastore-t, a storage admin pedig szintén a saját ízlésének megfelelően – vagy ha van akkor a “naming convention” szerint – de általában a két név nem egyezik és probléma van, ha bővíteni, elvenni, kiadni kell később. Na itt kerek perec megmutatja a relációt.

Korábban említettem, hogy a frissítések kezelése is egyedi, hiszen rengeteg ügyfél minden telemetriára engedélyezett Nimble tárolójából érkeznek adatok az Infosight-ba, ezáltal tényleg óriási mennyiségű szenzoradat, konfigurációs részlet áll készen korrelációk felállítására – amire a gyártó szerint AI-t használnak. Ezáltal lehetséges az eladott Nimble tárolókra szabni a frissítéseket, azaz amennyiben az adott tároló konfigurációja alapján problémát okozna egy frissítés, akkor az automatikusan blacklist-re kerül, így elkerülvén a problémát.

Például itt alább az látszik, hogy a mi Nimble tárolónkra van újabb firmware – amit majd egy rendezvény keretében teszünk fel, miközben 100%-ig terheljük a tárolót :)) – és annak telepítése nem jár kockázattal.

Látható fentebb a “Hardware Recommendations” rész. Itt üres, de ha például az előrejelzések szerint a rendszer hamarosan kifut a kapacitásból, teljesítményből, akkor javaslatokat tesz azok feloldására – erősebb kontroller, még egy shelf stb. Hisztorikusan jegyzi hogy milyen mértékben nő a foglaltság és azok alapján számol.

Fentebb az utolsó oszlop jelzi a változást 30/60/90 napra visszamenően és a “Days until full” oszlop pedig, azt az időt amennyi még legalább hátravan a boldog napjainkból. Nálunk ez a mező üres, mert nem fut elég ideje a rendszer, illetve nincs túl sok növekmény a VMFS datastore-okon. Tároló nézetben már más a helyzet:

Ha valakinek ismerősen a VMware Fling-ek, akkor itt is hasonlót találhat a “Labs” szekcióban.

A saját tárolónkra vonatkozóan lehet például megvizsgálni a teljesítményt, perces granularitással – vagy órással/napival.

De ott az “AI Performance Recommendations” riport is, ami javaslatokat tesz a teljesítmény javítására.

Az adatokat le lehet tölteni raw formátumba is – CSV – tehát ha valaki Excel mágus, akkor semmi sem állhat az útjába.

Egy szó mint száz, az Infosight egyszerre segít az ügyfeleknek, integrátoroknak és a gyártónak. Az elsőnek azért, mert fejlett analitikát kap és egyedi figyelmet, az utóbbinak pedig azért mert az amúgy is rengeteg szenzor, konfigurációs részlet, deduplikációs és tömörítési arány egy helyben dolgozható fel, párhuzamokat keresve egy beállítás hatásában, magabiztosságot adva egy bizonyos deduplikációs arány elérésére.