A HCI reggelire prezentációra történő felkészülésem során próbáltam összeszedni egy olyan anyagot, ami összehasonlíthatóságot ad a HCI megoldásokra nézve. Majd lesz erről egy részletes poszt is, de talán az egyik legnagyobb ködöt és lebegtetést a lokalitás kapcsán találtam a gyártói anyagokban.
Mi az a lokalitás?
Egyszerű – annak hangzik – megérteni, hogy egy HCI rendszerben, amelyik amolyan tükörben tárolja a virtuális gépek lemezeit, a lokalitást azt jelenti, hogyha a virtuális gép azon a HCI hoszton fut, ahol az egyik ilyen másolat/példány helyben van.
A másolatok száma elég erősen befolyásolja, hogy ha törődünk a lokalitással, akkor a gyártók megoldásai mentén, hány node-on értelmezett a lokalitás.
RAID1 – node szempontból
| Gyártó | Példány – RAID1 |
| HPE Simplivity | 2 |
| Cisco Hyperflex | 2 v 3 |
| VMware VSAN | 2 v 3 |
Látható, hogy ha két hosztunk van – már aki támogatja, a Cisco például nem, ott három hoszt a minimum – akkor lokalitásunk mindenképp lesz, de kérdés még mindig hogy van-e értelme.
Nézzük meg hogyan megy egy írás ezekben az esetekben:
Mivel tükörről beszélünk, egy írási művelet csak akkor kerül visszaigazolásra, ha azt legalább két hoszt is „leírta”. Az világosan érthető, hogy a VM-et futtató és példánnyal rendelkező hoszt ezt meg is teszi nagyon gyorsan, de a másik példány egy hálózat mögött lévő hoszton van, ebből fakadóan az mindenképp megjárja egyszer a hálózatot oda, majd a visszaigazolás ugyanazt a hálózatot mégegyszer. És a lokálisan történő írás hiába érkezik meg előbb, addig úgysem kerül ACK-ra az írási IO, amíg a másik meg nem érkezik. Ebből kiindulva írásnál nem értelmezhető semmiféle előnye a lokalitásnak.
Olvasásnál ezzel szemben elépzelhető némi előny, ugyanakkor minden SDS megoldás épít olvasási cache-re – hibrid esetén általánosan igaz – azaz a caching algoritmus arra van kihegyezve, hogy elég intelligens legyen és tudja honnan fog majd olvasni a VM és mennyit. All flash esetén nincs read cache, viszont hadd tegyek be ide egy táblázatot az késleltetésekről:
Ha ezek mellé tesszük a hálózati eszköz port to port késleltetését:
Ha nem egy ilyen komolyabb Arista a switch, hanem egy áltagosabb, akkor sem tölt el több mint 0,05 ms-ot a kapcsolással. Számít-e ez jelenleg? Mármint kell e félni attól, hogy a hálózaton keresztül történik meg az írás? Aki szerint ez baj, annak gondolom nincs SAN hálózata és semmiféle központi tárolója. Egy olyan rendszerben minden IO a hálózaton keresztül történik – FC vagy FCOE lényegtelen – semmi sincs helyben, még cache sincs – tároló oldalon van az is.
Alább például a saját AF1000 késleltetése teljes terhelés alatt.
Nem RAID1, hanem RAID5/RAID6 – erasure coding
Itt olvasásnál sincs lokalitás, hiszen az adatok több node-ra szétterítve kerülnek letárolásra valamennyi paritással együtt néhány hoszton. Attól függően kellene a VM-nek ott futnia, hogy éppen melyik hoszton van a blokk amit egyébként írni vagy olvasni akar. Ezt elképzelni is nagyon nehéz.
Összefoglaló
Mindettől függelenül van olyan gyártó, ahol például VMware Distributed Resource Scheduler-el együttműködve az SDS réteg képes VM/Host affinity csoportokkal biztosítani a gépek futási helyét olyan hosztokon, ahol a gép lemezének egy példánya elérhető. Ettől függetlenül azért az érthető, hogy ha van három nagyobb VM a rendszerben és ha ezek példányai azonos két hoszton vannak eltárolva, ugyanakkor a három VM nem fér el ezen a két hoszton együtt – mert nincs elég RAM,CPU – akkor máris sérül a funkció.
A VSAN-nál például annyira nincs lokalitás, hogy a VMware-nél kell support jegyet nyitni, hogy segístenek a VM-ek példányai hoszthoz kötni – HADOOP-nál fontos lehet.
A tervezési szempontoknál a lokalitás véleményem szerint nem szempont, ezzel nem szabad hogy befolyásolja sem a kiválasztott HCI gyártót, sem a végső design-t.
