Hogyan méretezz tényleg értelmesen VSAN-t HPE szervereken

Volt szerencsém egy olyan webináriumot meghallgatni, amelyen megpróbálták elmagyarázni, mit és hogyan kell átgondolni, ha HPE szervereken gondolkodik valaki, VSAN-ban. Pár mondás annyira megdöbbentett, hogy nem tértem magamhoz.

Cache méretezés

Mind a hibrid, mind az all flash VSAN használ cache réteget. Első esetben írási és olvasási, a másodikban csak írási cache formában. Ezért nyilvánvalóan minden írás megjárja a node-okban lévő egy vagy több – ha több disk group is van – SSD-t. Ezért költséghatékonysági okokból inkább érdemes a cache SSD-ben valami magas DWPD értékkel rendelkezőt venni. Gyártója válogatja hogy miképp jelölik az ezen paraméter mentén csoportosított termékeket.

A HPE-nél négy elvevezéssel:

  • very read optimized: bőven 1 alatti DWPD
  • read optimized: 1 DWPD
  • mixed use: 3 DWPD
  • write intensive: 10 DWPD

Az utóbbi esetén túl sok opció nincs SAS esetén mert alább igazából három modell van csak más carrier-ben (BC,SC).

Mindenképpen kell a write intensive SSD vagy esetleg jó lehet egy 25%-al olcsóbb 1,92TB-os mixed use modell?

A VSAN 600GB-ot használ a cache-ből. De ha nagyobb cache SSD kerül bele, akkor képes ezt a 600GB-ot rotálni, azaz nem mindig ugyanazt a 600GB-nyi területet biztosító cellákat írogatja. Ha háromszor akkora SSD-t teszek bele, mint amilyet vásároltam volna write intensive-ből, akkor tulajdonképpen háromszoroztam a DWPD értékemet. Tehát mixed use SSD-vel 9-es DWPD-t el tudok érni, ha legalább 1,8TB-os amit beleteszek.

  • 800GB x 10 DWPD = 8 TBW
  • 1,92GB x 3 DWPD = 5,76 TBW

Szóval nem. Ha drága a WI, akkor érdemesebb kétszer akkora MU-t venni, de ha háromszor akkorát sikerül, akkor már a WI fölé is ér effektív DWPD értékben.

Hálózat

10GBit az alap, de mint a híres mondás állítja: a 25Gbit az új 10Gbit, a 40Gbit az új 25Gbit. Azonban a sávszélesség nem minden. Olyan switch kell ami port to port késleltetése nem túl magas, illetve port buffer nem shared. Ha mégis akkor deep buffer switch-ek kellenek. Nyilván ezek, akkor jönnek elő mint probléma, ha a végletekig kitekert rendszerről beszélünk, de jó tudni.

Intel vagy AMD

A webinar-ban erre egy sima Intel volt a válasz. Én azt mondom AMD. Miért? Mert sokszor egy foglalatból tudja azt, amit az Intel kettőből. Fele annnyi vSphere és VSAN licensz. Teljesen egyértelmű a döntés, csak még mindig él az a mondás is, hogy “sose rúgtak még ki senkit mert Cisco/Intel-t vett”.

Deduplikáció és tömörítés

A webinar-ban itt az volt a javaslat, hogy “on”. Én mindenképpen OFF-ra tenném.

Ennek praktikus okai vannak:

  • lehetetlen tervezni vele a kapacitást, mert komolyabb vizsgálat nélkül lutri hogy mi lesz a használható terület.
  • terheli a CPU-t.
  • mivel a deduplikáció határa maga a disk group, ezért bármely kapacitást adó SSD elvesztése, a teljes disk group-ot viszi magával. Ha nincs deduplikáció, akkor csak a cache SSD elvesztése okoz ilyet, egy kapacitás SSD, akkor nem visz mindent a dev0-ba. Ha két disk group van, akkor nem lesz globális a deduplikáció, tehát mindkét disk group ilyen formán más dedup tartomány lesz, tehát kb még nehezebbé válik a tervezés vele, hiszen semmiféle befolyásunk nincs arra, hogy a leklónozott fájlszervert melyikre teszi majd. Ha nincs szerencsénk, akkor a másik disk group-ba és akkor nem egyszer tároljuk egy node-on, hanem kétszer.

Szóval ha mindenképpen spórolni akarunk, akkor nyilván lehet DECO-val számolni, de konzervatívann csak a tömörítéssel kalkulálni vagy még azzal sem. A csak tömörítés, az a deduplikáció esetén a disk group szintjére emelt failure domain-t oldja fel és így egy kapacitás SSD elvesztése már nem jelent adott disk group elvesztést. CPU terhelése is alacsonyabb.

Tehát DECO az nice to have, de körbezsaluzva tervezni vele nem szabad.

HCI mesh

A HCI Mesh nem VSAN klaszterek között a VSAN datastore-ok kereszbe csatolgatását jelenti, hanem azt is, hogy compute only VSAN enabled cluster – tehát nincs bennük egyetlen média sem amit a VSAN használ – használhat egy VSAN datastore-t, amit egy olyan VSAN klaszter ad neki, amikben viszont vannak médiák. Annyi kell hozzá, hogy a VSAN hálózatban legyen interfésze minden szervernek.

VSAN a HPE szervereken

Mivel nem nagyon volt HPE specifikus része a webinar-nak ezért bátorkodom ezekről beszélni. Egy VSAN-ra kiválasztható de nem VSAN ready node szerverben három lehetőség is van:

  • direct CPU NVMe
  • SAS/SATA controller
  • tri-mode controller (NVMe/SAS/SATA)

Az első az magáért beszél, az NVMe közvetlenül a CPU-hoz kapcsolódik. (hot plug-ra figyelni kell!!!). A második az a kenyér-tej kategória – HPE-nél az E és P kezdetű vezérlők. A harmadik pedig az MR és SR kezdetű vezérlők.

Viszont nagyon fontos az, hogy ha valakiben felmerülne hogy egy tri-mode vezérlővel/vezérlőkkel rendlkező szerverbe, amikben tri-mode cage-ek vannak, a cache-re mondjuk NVMe-t tenne bele, kapacitásra meg SAS/SATA-t, az nem támogatott.

Mit lehet akkor mégis tenni? Mondjuk PCIe foglalatba helyezhető NVMe SSD-t használni cache-re és kontrollerek mögé SAS/SATA-t tenni.. Működhet akár a direct CPU NVMe és mellé, egy kontroller mögé SAS/SATA-t opció is. Esetleg egy kontroller mögé NVMe-t tenni, a másik mögé pedig SAS/SATA-t – de ez nem éppen szép megoldás ha a cache egy disk group esetén egy másik vezérlőn van.

De akkor milyen szervert pontosan?

Két dolog határozza meg véleményem szerint:

  • mekkora compute (CPU és RAM)
  • mekkora kapacitás

tehető az adott kiszolgálóba. Pont ebből fakadóan véleményem szerint a HPE Synergy platform egy nagyon korlátos megoldás VSAN-ra. Storage module nélkül nem 2-4 HDD/SSD tehető egy pengébe – ami skálázhatóságot tekintve nagyon előnytelen. Egy storage module-ba 40 HDD/SSD tehető és egy keretbe akár több ilyen module is illeszhető. Mivel a VSAN licensz összesen 40 média használatára ad lehetőséget, a maximumot nézve egy storage module-t igazából akár egy kiszolgáló is ki tud teljesen használni.

Azonban egy ilyen storage module két bay helyet vesz el és SAS interconnect module is kell a keret hátuljába. Ráadásul egy module csak a vele azonos keretben lévő kiszolgálóknak tud adni médiát.

A normál 2 disk group (1 cache, 4 capacity) modellben 4 szerver tud kiszolgálni egy module és a 12 bay-ből el is megy 6 és a további bővíthetőség nem lehetséges – maximum az SSD/HDD-k nagyobb méretűre cserélésével. Két module kiszolgálhat nyolc node-ot, ekkor azonban már 12 bay helyet folgal el a teljes rendszer, ami a maximum. Tehát bővítés csak a cserélgetéssel vagy újabb keret beszerzésével lehetséges. Már érthető, hogy miért nem vagyok a legnagyobb híve a Synergy VSAN-nak.

Szóval rack irányből közelítve rengeteg modell van:

  • DL325 (AMD) 1U
  • DL360 (Intel) 1U
  • DL380 (Intel) 2U
  • DL385 (AMD) 2U
  • Apollo r2600 2U
  • Apollo r2800 2U
  • Apollo 4200 2U

Azt aláírom, hogy a rack formátumú szerverek minden hátránya itt is jellemző, hiszen minden kiszolgálót a hálózatba kell kötni, tápellátást kell biztosítani nekik, szóval a portok és csatlakozók száma sokkal magasabb lehet mint egy “wire once” blade alapú megoldásnál, viszont pusztán a bővítési lehetőségeket nézve, könnyen előnybe kerülhetnek. De mint a tanult francia mondja: “your mileage may vary”.