Ebben a cikkben az összes Flash AccelStor tömb funkcióiról szeretnék beszélni, amelyek az egyik legnépszerűbb virtualizációs platformmal - VMware vSphere - működnek. Különösen összpontosítson azokra a paraméterekre, amelyek segítenek a maximális hatás elérésében egy olyan hatékony eszköz használatával, mint az All Flash.
AccelStor NeoSapphire™ Minden Flash tömb vagy SSD-meghajtókra épülő csomóponti eszközök, amelyek alapvetően más megközelítést alkalmaznak az adattárolás koncepciójának megvalósításában és a hozzáférés megszervezésében, szabadalmaztatott technológiával a nagyon népszerű RAID-algoritmusok helyett. A tömbök blokkos hozzáférést biztosítanak a gazdagépekhez Fibre Channel vagy iSCSI interfészeken keresztül. Az igazságosság kedvéért megjegyezzük, hogy az ISCSI interfésszel rendelkező modellek fájlhozzáféréssel is kedveskednek. Ebben a cikkben azonban a blokkprotokollok használatára fogunk összpontosítani, mivel ezek a leghatékonyabbak az All Flash esetében.
Az AccelStor tömb és a VMware vSphere virtualizációs rendszer teljes üzembe helyezési és konfigurálási folyamata több szakaszra osztható:
- Csatlakozási topológia megvalósítása és SAN hálózat konfigurációja;
- Összes Flash tömb beállítása;
- ESXi gazdagépek konfigurálása;
- Virtuális gépek beállítása.
Az AccelStor NeoSapphire™ Fibre Channel tömböket és az iSCSI tömböket mintahardverként használták. Az alapszoftver a VMware vSphere 6.7U1.
A cikkben ismertetett rendszerek üzembe helyezése előtt erősen ajánlott, hogy olvassa el a VMware dokumentációját a teljesítményproblémákkal kapcsolatban ( ) és az iSCSI beállítások ()
Csatlakozási topológia és SAN hálózati konfiguráció
A SAN-hálózatok fő összetevői az ESXi gazdagépekben található HBA-k, SAN-kapcsolók és tömbcsomópontok. Egy ilyen hálózat tipikus topológiája így néz ki:
A Switch kifejezés itt egy különálló fizikai kapcsolót vagy kapcsolókészletet (Fabric), valamint egy különböző szolgáltatások között megosztott eszközt (VSAN Fibre Channel és VLAN iSCSI esetén) egyaránt jelent. Két független kapcsoló/szövet használata kiküszöböli az esetleges meghibásodási pontokat.
A gazdagépek közvetlen csatlakoztatása a tömbhöz, bár támogatott, erősen nem ajánlott. Az All Flash tömbök teljesítménye meglehetősen magas. A maximális sebességhez pedig a tömb összes portját használni kell. Ezért legalább egy kapcsoló megléte kötelező a gazdagépek és a NeoSapphire™ között.
A gazda HBA-n két port jelenléte szintén kötelező követelmény a maximális teljesítmény eléréséhez és a hibatűrés biztosításához.
Fibre Channel interfész használatakor a zónákat úgy kell konfigurálni, hogy kiküszöböljék a kezdeményezők és a célpontok közötti esetleges ütközéseket. A zónák az „egy kezdeményező port – egy vagy több tömbport” elvén épülnek fel.
Ha iSCSI-n keresztüli kapcsolatot használ más szolgáltatásokkal megosztott switch használata esetén, akkor feltétlenül el kell különíteni az iSCSI-forgalmat egy külön VLAN-on belül. Szintén erősen ajánlott engedélyezni a Jumbo Frames (MTU = 9000) támogatását, hogy növelje a hálózaton lévő csomagok méretét, és ezáltal csökkentse a többletterhelési információ mennyiségét az átvitel során. Nem szabad azonban elfelejteni, hogy a helyes működéshez az MTU paramétert minden hálózati komponensen módosítani kell az „iniciator-switch-target” lánc mentén.
Összes Flash tömb beállítása
A tömböt a már kialakított csoportokkal rendelkező ügyfelek kapják meg . Ezért nincs szükség a meghajtók egyetlen struktúrába való egyesítéséhez. Csak a szükséges méretű és mennyiségű köteteket kell létrehoznia.
A kényelem érdekében lehetőség van egy adott méretű több kötet kötegelt létrehozására. Alapértelmezés szerint vékony kötetek jönnek létre, mivel ez lehetővé teszi a rendelkezésre álló tárterület hatékonyabb felhasználását (beleértve a Space Reclamation támogatását). A teljesítmény tekintetében a „vékony” és a „vastag” térfogatok közötti különbség nem haladja meg az 1%-ot. Ha azonban egy tömbből „minden levet” szeretne kifacsarni, bármikor bármilyen „vékony” kötetet „vastaggá” alakíthat. De nem szabad elfelejteni, hogy egy ilyen művelet visszafordíthatatlan.
Ezután hátra van a létrehozott kötetek „közzététele”, és a hozzáférési jogok beállítása a gazdagépektől ACL-ek (IP-címek az iSCSI-hez és WWPN-címek az FC-hez) és a tömbportok általi fizikai elkülönítés segítségével. Az iSCSI modellek esetében ez egy cél létrehozásával történik.
Az FC modellek esetében a közzététel egy LUN létrehozásával történik a tömb minden portjához.
A beállítási folyamat felgyorsítása érdekében a gazdagépeket csoportokba lehet vonni. Sőt, ha a gazdagép többportos FC HBA-t használ (ami a gyakorlatban leggyakrabban előfordul), akkor a rendszer automatikusan megállapítja, hogy egy ilyen HBA portjai egyetlen gazdagéphez tartoznak az eggyel eltérő WWPN-eknek köszönhetően. A Target/LUN kötegelt létrehozása szintén támogatott mindkét interfészen.
Az iSCSI interfész használatakor fontos megjegyzés, hogy a teljesítmény növelése érdekében egyszerre több célt kell létrehozni a kötetekhez, mivel a célon lévő sor nem módosítható, és gyakorlatilag szűk keresztmetszetet jelent.
Az ESXi Hosts konfigurálása
Az ESXi gazdagép oldalán az alapkonfiguráció egy teljesen elvárt forgatókönyv szerint történik. Az iSCSI-csatlakozás menete:
- Szoftver hozzáadása iSCSI Adapter (nem szükséges, ha már hozzá lett adva, vagy ha Hardveres iSCSI Adaptert használ);
- Egy vSwitch létrehozása, amelyen keresztül az iSCSI-forgalom áthalad, és fizikai uplink és VMkernal hozzáadása hozzá;
- Tömbcímek hozzáadása a Dynamic Discoveryhez;
- Adattár létrehozása
Néhány fontos megjegyzés:
- Általános esetben természetesen használhatunk egy meglévő vSwitchet, de egy különálló vSwitch esetén sokkal egyszerűbb lesz a gazdagép beállításainak kezelése.
- A teljesítményproblémák elkerülése érdekében a felügyeleti és az iSCSI-forgalmat külön fizikai hivatkozásokra és/vagy VLAN-okra kell elkülöníteni.
- A VMkernal IP-címének és az All Flash tömb megfelelő portjainak ugyanazon az alhálózaton belül kell lenniük, szintén teljesítményproblémák miatt.
- A VMware szabályok szerinti hibatűrés biztosítása érdekében a vSwitchnek legalább két fizikai felfelé irányuló kapcsolattal kell rendelkeznie
- Ha Jumbo Frame-et használ, módosítania kell a vSwitch és a VMkernal MTU-ját
- Hasznos lenne emlékeztetni arra, hogy a VMware azon fizikai adapterekre vonatkozó ajánlásai szerint, amelyek az iSCSI-forgalommal fognak működni, be kell állítani a Teaming és a Failover funkciót. Minden VMkernalnak csak egy felfelé irányuló kapcsolaton keresztül kell működnie, a második felfelé irányuló kapcsolatot nem használt módba kell kapcsolni. A hibatűrés érdekében két VMkernalt kell hozzáadnia, amelyek mindegyike saját uplinken keresztül működik.
VMkernel Adapter (vmk#)
Fizikai hálózati adapter (vmnic#)
vmk1 (Storage01)
Aktív adapterek
vmnic2
Nem használt adapterek
vmnic3
vmk2 (Storage02)
Aktív adapterek
vmnic3
Nem használt adapterek
vmnic2
A Fibre Channel csatlakozáshoz nincs szükség előzetes lépésekre. Azonnal létrehozhat egy adattárat.
Az adattár létrehozása után meg kell győződnie arról, hogy a Cél/LUN elérési útjaira vonatkozó Round Robin házirendet használja a legjobban.
Alapértelmezés szerint a VMware beállításai lehetővé teszik ennek a házirendnek a használatát a séma szerint: 1000 kérés az első útvonalon, a következő 1000 kérés a második útvonalon stb. Az ilyen interakció a gazdagép és a kétvezérlős tömb között kiegyensúlyozatlan lesz. Ezért javasoljuk a Round Robin házirend = 1 paraméter beállítását az Esxcli/PowerCLI segítségével.
Paraméterek
Esxcli esetén:
- Sorolja fel az elérhető LUN-okat
esxcli tároló nmp eszközök listája
- Eszköznév másolása
- Változtassa meg a Round Robin szabályzatot
esxcli tároló nmp psp roundrobin deviceconfig set —type=iops —iops=1 —device=“Device_ID”
A legtöbb modern alkalmazást nagy adatcsomagok cseréjére tervezték a sávszélesség maximalizálása és a CPU terhelés csökkentése érdekében. Ezért az ESXi alapértelmezés szerint legfeljebb 32767 KB-os darabokban küldi ki az I/O kéréseket a tárolóeszköznek. Egyes forgatókönyvek esetén azonban a kisebb darabok cseréje hatékonyabb lesz. Az AccelStor tömbök esetében a következők a forgatókönyvek:
- A virtuális gép UEFI-t használ a Legacy BIOS helyett
- vSphere replikációt használ
Ilyen forgatókönyvek esetén javasolt a Disk.DiskMaxIOSize paraméter értékét 4096-ra módosítani.
iSCSI-kapcsolatok esetén ajánlatos a Bejelentkezési időtúllépés paramétert 30-ra módosítani (alapértelmezett 5), hogy növelje a kapcsolat stabilitását, és letiltja a DelayedAck késleltetést a továbbított csomagok megerősítéséhez. Mindkét lehetőség megtalálható a vSphere Clientben: Gazda → Konfigurálás → Tárhely → Tárhelyadapterek → Speciális beállítások az iSCSI-adapterhez
Egy meglehetősen finom szempont az adattárhoz használt kötetek száma. Nyilvánvaló, hogy a könnyebb kezelés érdekében egy nagy kötetet kívánnak létrehozni a tömb teljes kötetéhez. A több kötet és ennek megfelelően az adattár jelenléte azonban jótékony hatással van az általános teljesítményre (a sorokról lentebb). Ezért legalább két kötet létrehozását javasoljuk.
Egészen a közelmúltig a VMware azt tanácsolta, hogy korlátozzák az egy adattárban lévő virtuális gépek számát, ismét a lehető legnagyobb teljesítmény elérése érdekében. Most azonban, különösen a VDI terjedésével, ez a probléma már nem annyira akut. Ez azonban nem szünteti meg a régóta fennálló szabályt – az intenzív IO-t igénylő virtuális gépek elosztását a különböző adattárak között. A virtuális gépek kötetenkénti optimális számának meghatározásához semmi sem jobb, mint infrastruktúráján belül.
Virtuális gépek beállítása
A virtuális gépek beállításakor nincsenek különleges követelmények, vagy inkább teljesen hétköznapiak:
- A lehető legmagasabb virtuálisgép-verzió használata (kompatibilitás)
- Óvatosabb a RAM méretének beállítása virtuális gépek sűrű elhelyezésekor, például VDI-ben (mivel alapértelmezés szerint induláskor a RAM-nak megfelelő méretű oldalfájl jön létre, ami hasznos kapacitást fogyaszt és hatással van a a végső előadás)
- Használja az IO szempontjából a leghatékonyabb adapterverziókat: VMXNET 3 típusú hálózat és PVSCSI SCSI típusú
- Használja a Thick Provision Eager Zeroed lemeztípust a maximális teljesítmény és a Thin Provisioning használatával a maximális tárhelykihasználás érdekében
- Ha lehetséges, korlátozza a nem I/O kritikus gépek működését a Virtual Disk Limit segítségével
- Feltétlenül telepítse a VMware Tools programot
Megjegyzések a sorokról
A várakozási sor (vagy Outstanding I/Os) azon bemeneti/kimeneti kérések (SCSI-parancsok) száma, amelyek egy adott eszköz/alkalmazás feldolgozásra várnak egy adott időpontban. A várakozási sor túlcsordulása esetén QFULL hibákat adnak ki, ami végső soron a késleltetési paraméter növekedését eredményezi. Lemezes (orsós) tárolórendszerek használatakor elméletileg minél magasabb a várakozási sor, annál nagyobb a teljesítményük. Nem szabad azonban visszaélni vele, mert könnyen belefuthat a QFULL. Az All Flash rendszerek esetében egyrészt minden valamivel egyszerűbb: elvégre a tömbnek nagyságrendekkel kisebb késleltetési ideje van, ezért legtöbbször nem kell külön szabályozni a sorok méretét. Másrészt viszont bizonyos használati forgatókönyvek esetén (erős torzulás az IO-követelményekben bizonyos virtuális gépeknél, tesztek a maximális teljesítmény érdekében stb.) szükséges, ha nem is módosítani kell a sorok paramétereit, de legalább megérteni, hogy milyen mutatók lehet elérni, és a lényeg az, hogy milyen módon.
Magán az AccelStor All Flash tömbön nincsenek korlátozások a kötetekre vagy az I/O portokra vonatkozóan. Szükség esetén akár egyetlen kötet is megkaphatja a tömb összes erőforrását. A várakozási sor egyetlen korlátozása az iSCSI-célokra vonatkozik. Emiatt jeleztük fent, hogy minden kötethez több (ideális esetben legfeljebb 8 darab) célpontot kell létrehozni, hogy ezt a határt leküzdjük. Ismételjük meg, hogy az AccelStor tömbök nagyon hatékony megoldások. Ezért a maximális sebesség elérése érdekében a rendszer összes interfész portját használja.
Az ESXi fogadóoldalán teljesen más a helyzet. A fogadó maga alkalmazza azt a gyakorlatot, hogy minden résztvevő számára egyenlő hozzáférést biztosít az erőforrásokhoz. Ezért külön IO-sorok vannak a vendég operációs rendszerhez és a HBA-hoz. A vendég operációs rendszerhez vezető várólisták a virtuális SCSI-adapterhez és a virtuális lemezhez vezető várólistákból egyesülnek:
A HBA-hoz vezető sor az adott típustól/szállítótól függ:
A virtuális gép végső teljesítményét a gazdagép összetevői közül a legalacsonyabb sormélység-korlát határozza meg.
Ezeknek az értékeknek köszönhetően ki tudjuk értékelni, hogy egy adott konfigurációban milyen teljesítménymutatókat kaphatunk. Például egy 0.5 ms-os késleltetésű virtuális gép elméleti teljesítményét szeretnénk megtudni (blokkkötés nélkül). Ekkor az IOPS = (1,000/latencia) * Rendkívüli I/O-k (sormélység-korlát)
Примеры
Példa 1
- FC Emulex HBA adapter
- Adattáronként egy virtuális gép
- VMware Paravirtuális SCSI Adapter
Itt a sormélység határát az Emulex HBA határozza meg. Ezért IOPS = (1000/0.5)*32 = 64K
Példa 2
- VMware iSCSI szoftveradapter
- Adattáronként egy virtuális gép
- VMware Paravirtuális SCSI Adapter
Itt a sormélység határát már a Paravirtual SCSI Adapter határozza meg. Ezért IOPS = (1000/0.5)*64 = 128K
Az összes Flash AccelStor tömb legjobb modelljei (például ) 700K IOPS írási teljesítményt képesek nyújtani 4K blokkon. Ilyen blokkméret mellett teljesen nyilvánvaló, hogy egyetlen virtuális gép nem képes ilyen tömb betöltésére. Ehhez 11 (például 1) vagy 6 (például 2) virtuális gépre lesz szüksége.
Ennek eredményeként a virtuális adatközpont összes leírt összetevőjének megfelelő konfigurálásával nagyon lenyűgöző eredményeket érhet el a teljesítmény tekintetében.
4K véletlenszerű, 70% olvasás/30% írás
Valójában a való világ sokkal összetettebb, mint azt egy egyszerű képlettel le lehetne írni. Egy gazdagép mindig több virtuális gépet tárol különböző konfigurációkkal és IO-követelményekkel. Az I/O feldolgozást pedig a gazdagép processzor végzi, amelynek teljesítménye nem végtelen. Tehát, hogy feltárja a teljes potenciált ugyanaz a valóságban három gazdára lesz szüksége. Ráadásul a virtuális gépeken futó alkalmazások saját maguk módosítják. Ezért a pontos méretezéshez ajánljuk Minden Flash tömb az ügyfél infrastruktúráján belül a valós aktuális feladatokon.
Forrás: will.com