Számít-e a lokalitás – HCI

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 Simplivity2
Cisco Hyperflex2 v 3
VMware VSAN2 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.