HPE Nimble és az Infosight – második rész

Az előző részben ígértem, hogy megnézem mit tud az Infosight egy hibakeresés keretében és milyen dolgokat találunk a “Lab” részen. Ha a vCenter Server és a Nimble integrálva van – javasoltam is hogy legyen – akkor az egy egészen más szint nyílik meg.

Ezt leginkább az “Infrastructure -> Virtualization” tab alatt található menükben láthatjuk.

A “Datacenters” résznek nagyobb környezetben van értelme, ezek lényegében a vCenter Server(-ek)-ben definiált Datacenter objektumok. Sok információt nem jelenít meg velük kapcsolatosan, csak azt hogy hány klaszter, hány hoszt, hány datastore és mennyi VM található alattuk.

A “Clusters” nézet picit mélyebbre megy és amennyiben túlterhelt hoszt van valamelyik klaszterben, akkor szól – egyelőre nem világos, hogy mi az Infosight szerint túlterhelt.

Az “ESXi hosts” nézet már jobban használható, főleg ha valakinek nincs Veeam ONE vagy vRealize Operations felügyeleti megoldása, mivel akkor a visszamenőleges swap és balloon értékek kicsit nehezebben nyerhetőek ki. Nem szabad azonban az Infosight-ra úgy nézni, mint teljes értékű felügyeleti szoftver, ez nem valós időben jelzi – nem mindig – a kialakult problémákat. Inkább úgy kell fogyasztani, hogy trendeket mutat és egy RCA (root cause analysis) adhat plusz információkat. Alább például az elmúlt hat órák CPU/RAM és swap/balloon értékei látszanak, esetemben minden rendben.

A “Datastores” nézet már sokkal érdekesebb és kezdünk oda tévedni, ami miatt egyedi az Infosight. vCenter-ből kiolvassa a datastore nevét és azt egyezteti a Nimble tárolón a volume nevével. Szintén mutatja a használt VMFS verziót, blokkméretet és folgaltságot a teljes kapacitás mellett. Ebben nekem az tetszik, hogy nem egyszer láttam már olyat, hogy a datastore és a volume neve nem egyezett és mikor növelni kellett egy ilyen exportot, akkor a storage admin nem is azt növelte. Még rosszabb az, amikor rosszat csatolnak le.

Végül a “VMs” nézet, ami első látásra lehet hogy kusza, de egy VM-re kattintva kinyílik a világ. A “Performance” lentebb 1 napra szűrve képes megmutatni a késleltetést, a VM által generált írási és olvasási IO-t. A “Capacity” tab-on – amennyiben a VM-ben van VMware Tools – látható a VM belső felhasználása.

A “VMDKs” tab-on pedig VMDK szinten (!!!) látható az átlagos IOPS/késleltetés/throughput is. Időzzünk el itt egy picit. Egy datastore-on ha több VM van, amelyek több VMDK-t használnak, ugyanarról a datastore-ról, akkor képesek vagyunk lebontani ezeket az értékeket a VMDK szintjére.

Ugorjunk vissza a “VMs” oldalra egy kicsit. Ha a bal felsőben kattintok, akkor lenyílik egy lista, ott pedig kiválasztom a “VM I/O Contention Trend” részt.

Mituán kiválasztottam egy datastore-t, akkor az alábbi ablakot mutatja. Elsőre rémisztőnek tűnhet, de nagyon jól ábrázolja mikor melyik VM terhelte a tárolót, mivel, milyen késleltetéssel. Így feltűnhet, hogy van egy virtuális gépem amelyik rengeteg IO-t generál és 19.2 ms az átagos késleltetése.

Ha a “VM CPU Contention Trend” lekérdezést választom, akkor nagyon hasonló kimenetet kapok a VM CPU terhelés(!) és a CPU ready értékekre vonatkozóan.

Ezek után a “capacity manager” már egészen biztosan támogat ha Nimble-t akarsz.

Menjünk a “Labs” részre

Keressük meg a “Inter-Volume Performance & Contention“ riportot. Miután legenerálja az utolsó hét nap alapján, képes megmondani melyik volume szolgálja ki a legtöbb IO-t és ehhez mérten, hogy alakul a késleltetése.

Nálam a “Nimble-VMFS2” datastore dolgozik a legkeményebben és a “Nimble-VMFS1” pedig néha megugró késleltetési értékeket mutat. Ha fölé viszem az egeret akkor megmutatja a konkrét értékeket és időpontot.

A ” Recurring Performance Patterns” képes neked művészi ábrát rajzolni – szó szerint – arról, mikor és milyen mértékben dolgozik a tároló.

Nézzünk egy ilyet a random olvasásra az utolsó hónapra vizsgálva.

Minden egyes cella 5 perc átlagát jelenti. Látható, hogy ez a riport szekvenciális olvasás, random írás, szekvenciális írás esetére is generálható. Letölthető CSV formátumba, ha valamilyen külső szoftverrel szeretnénk vizsgálni. Mi értelme? Ez a kapacitás-menedzsmenttel összefüggő segítség, egy szemerkényi hibakeresési lehetőséggel, például ha lassulást szoktál érezni vasárnap este 22:00 környékén, akkor ez körvonalazza, hogy miért.

A következő elég érdekes választási lehetőség a “Pool Performance Telemetry”. Ez az az adatsor amivel az Infosight AI-t is etetik, mikor a teljesítményről van szó. (Ne nézd nálam a “Cache Hit Rate”-et, mivel ez egy all flash modell és itt nincs read cache).

A killer funkció “Resource Planner”

Tegyük fel, hogy van egy Nimble tárolód, és szeretnél valamilyen projekt keretében új virtuális gépeket tenni rá, új volume-okat fizikai gépek számára vagy csak szimplán a meglévőket kibővíteni, jobban terhelni. Na ez a funció képes neked megmondani, hogy ki fogja-e bírni a tároló, mármint mindenféle lassulás és kifutó kapacitás nélkül.

Példaképpen azt tervezem, hogy egy 1TB-os Oracle DB-t fogok a CRM-em mögé tenni és ez 2800 IOPS-ot fog burst módon jelenteni.

Az Infosight megmutatja, hogyan fog a tárolóm viselkedni “feltételezhetően”, ha ezt is rá fogom tenni. Méghozzá a meglévő AF1000 tárolómra értelmezve, beleszámolva annak terheltségét is, az mutatja, hogy a CPU 28%-ra fog felugrani, illetve hogy a kapacitásban is elegendő lesz-e.

Most növeljük meg a példa kedvéért az prognosztizált IOPS értéket 12800-ra. Ó igen. Az AF1000 processzora 108%-on kellene, hogy dolgozzon, szóval javallott magasabb szériából modellt választani, mivel ez az apró AF modell kifutna erőből.

Olyat is lehet modellezni, hogy egy P2V migrációk kapcsán mi történik, ha megduplázódik a kapacitás és teljesítmény-igény.

Megnyugtató látni, hogy nem lenne semmi probléma, minden működne tökéletesen és gyorsan tovább, ahogy eddig.

Összefoglaló

Szerintem érthető lassan, hogy az Infosight olyan lehetőségeket nyit meg a Nimble vásárlók előtt – hamarosan a Primera esetében is – amelyekkel a lehető legtöbbet lehet kihozni a tárolóból, illetve nem csak abból, hanem a VMware környezetből is. Nem mellesleg ez önmagában is képes arra, hogy alátámassza egy ilyen modern tároló beszerzését.

A harmadik részben kifejtek még pár remekül használható riportot, maradj velem!