TPS (Transparent Page Sharing) változások II.

Az előző bejegyzésben arról volt szó, hogy miért változtatták meg a TPS eddigi jól bevált működését. Azt mindenkinek magának kell eldöntenie, hogy alkalmazkodik az új alapértelmezéshez, vagy azt felülírva visszatér a szokásos beállításokhoz.

Az elején fontos megjegyezni, hogy ami ebben a leírásban van, a mostani állapotot tükrözik. De a bevezetése tulajdonképpen két fontos lépésben történt:

• A bejelentés utáni első nagyobb javítások már tartalmazták a két advanced paramétert, de még nem változtatták meg a TPS működését, illetve a Mem.ShareForceSalting értéke csak 0 vagy 1 lehetett
• A végleges verzióban már alapértelmezett lett a TPS megváltozott működése, és a Mem.ShareForceSalting értéke a 0 vagy 1 mellett 2 is lehet. Illetve nem csak lehet, hanem ez a default érték.

Akkor nézzük meg, hogyan is működik a "salting".

• Bevezettek egy új host konfigurációs paramétert, a Mem.ShareForceSalting-ot. Ezzel szabhatjuk meg, hogy egy adott host hogyan kezelje az inter-vm (virtuális gépek közötti) TPS-t. Ha az értéke nulla, akkor minden marad a régiben, ha pedig 1 vagy 2, akkor megváltozik a működés.
• A megváltozott működés azt jelenti, hogy most már az kevés, ha két vagy több virtuális gépnek van azonos memória lapja, ahhoz hogy a TPS ezeket egy fizikai lapon tárolja, ahhoz az kell, hogy a virtuális gépeknek azonos legyen a "salt" értéke is. 
• Ehhez bevezettek egy új vm szintű paraméter, aminek a neve sched.mem.pshare.salt, és értéke egy tetszőleges string lehet. 
• Ezzel a paraméterrel meghatározhatunk virtuális gép csoportokat, amik között a TPS mégis működhet annak ellenére, hogy a Mem.ShareForceSalting értéke 1 vagy 2. Ehhez csak annyit kell tennünk, hogy ezt a paramétert a csoport minden tagján azonos értékre állítjuk be. Ennek értelme az, hogy bár alkalmazzuk az új biztonságosabb TPS beállításokat, de ha akarunk, tehetünk kivételeket. (pl. security szempontból kevésbé érzékeny gépek esetében)
• Ha a sched.mem.pshare.salt paraméter hiányzik, de a "salting" be van kapcsolva, akkor a "salt" vagy a vc,uuid, gépenként egyedi paraméter vagy a nulla érték lesz. Ez attól függ, hogy a Mem.ShareForceSalting 2 vagy 1. 
• Bármilyen beállítások is vannak, az intra-vm TPS működni fog, azaz egy gépen belül képes lesz a rendszer az azonos memória lapokat összevonni.

A fentiek ismeretében nézzük meg, hogy milyen különböző esetek lehetségesek.

Mem.ShareForceSalting=0
A TPS hagyományos módon működik, azaz  ha van is a virtuális géphez beállított sched.mem.pshare.salt érték, azt nem veszi figyelembe.

Mem.ShareForceSalting=1
A "salting" be van kapcsolva. Ha létezik a sched.mem.pshare.salt paraméter, akkor azt fogja használni (azaz azonos értékkel bíró gépeknél lesz inter-vm TPS), ha viszont nincs, akkor a "salt" értéke nulla lesz, azaz szintén működni fog a TPS

Mem.ShareForceSalting=2
Ez az alapértelmezett. A "salting" be van kapcsolva. Ha nem létezik a sched.mem.pshare.salt paraméter (ez a default), akkor a .vmx-ben lévő vc.uuid értéke lesz a "salt". Mivel ez gépenként egyedi érték, ez gyakorlatilag azt jelenti, hogy az inter-vm TPS nem működik. Ha a paraméter létezik, akkor viszont azt fogja használni, így azonos "salt" érték esetében lesz inter-vm TPS. Itt elméletileg előfordulhat az is, hogy sem a sched.mem.pshare.salt, sem a vc.uuid nem létezik. Ilyen esetben a host véletlen számokat használ, így szintén nem lesz inter-vm TPS.

Végül nézzük meg egy frissen telepített ESXi 6.0U1 esetében mit is látunk:

Mem.ShareForceSalting default értéke

Nincs sched.mem.pshare.salt paraméter, ez a default

A "salt" értéke default esetben

A jó megoldásnak az tűnik, ha ellenőrizzük egy esetleges host upgrade előtt, hogy általában a TPS mekkora memória megtakarítást jelent, van e balloon használat, memória tömörítés esetleg swap használat, mert ha igen, akkor az upgrade után egészen biztos, hogy még tovább fog romlani a helyzet.

Ha valami nem tiszta vagy szerintetek nem így van, kérem jelezzétek.

Update: Megtaláltam azt a cikket, ami leírja, miért is jelent a TPS kockázatot: Ez lenne az.

TPS (Transparent Page Sharing) változások I.

Mivel nem mai történet (2014 októberében lehetett róla először olvasni), ezért már biztosan mindenki tudja, hogy az új ESXi kiadásokban (nemcsak a hatosban) a virtuális gépek közötti TPS alapból letiltásra került. Ez annak fényében fura lépés, hogy a VMware memóriakezelésének egyik kulcsa volt a TPS. Ha összehasonlítottuk más virtualizációs megoldásokkal, akkor ez a képesség mindig előjött, mint az egyik erős érv a VMware mellett.

Viszont speciális körülmények között sikerült olyan helyzetet előállítani, amikor a TPS biztonsági rést okozott. Régebben megtaláltam azt a tudományos cikket ami ezt leírja, de most képtelen vagyok fellelni. Az egy gépen belüli TPS érintetlen maradt. A VMware-nek is az a hivatalos álláspontja, hogy ezek a körülmények produktív környezetben nem igen reprodukálhatóak, de mivel a "biztonság mindenekelőtt", ezért mégis a TPS alapértelmezett tiltása mellett döntött. Ahogy ők mondják:

"This technique works only in a highly controlled system configured in a non-standard way that VMware believes would not be recreated in a production environment” and “believes information being disclosed in real world conditions is unrealistic” 

A nyilvánvaló kérdés az, hogy mit is kezdjünk ezzel a helyzettel. Mivel mi jelenleg csak cégen belül szolgáltatunk, ezért számomra egyértelmű, hogy új ESXi telepítés után, vagy a már érintett verzióra való upgrade után bekapcsolom a TPS-t. Bár az is igaz, hogy jelenleg nem feltétlenül jelent igazi előnyt a hostjaink nagy részénél, mivel beleférünk a fizikai memóriába (nincs túlfoglalás), és a mai modern architektúrákban nem a szokásos 4 KB-os memória lapokkal dolgozik az ESXi, hanem ún. "large memory page"-eket használ, aminek a mérete 2 MB. Ilyen méretű lapoknál eleve kisebb az esélye, hogy azonos tartalmú darabokat találjon, illetve sok CPU erőforrásba is kerülne az azonos lapok keresése, így ilyen lapoknál nem is használja az ESXi a TPS-t. Viszont nem tudhatom, hogy a terhelés a (közel)jövőben hogyan fog megváltozni, ezért inkább már most engedélyezem. (Főleg hogy host restart is kell a módosításkor)

Azt hiszem a TPS működését mindenki ismeri, de azért egy ábrát beszúrok ide, ami összefoglalja a lényeget.

Persze felmerül a kérdés, ha 2MB-os lapok vannak és ott a TPS nem működik, akkor mi is az értelme az egésznek. Azt tudjuk, hogy a balooning, a memória tömörítés kevésbé hatékony, nem is beszélve a swap használatáról.

Természetesen használja az ESXi a TPS-t, amennyiben elkezd fogyni a szabad memória mérete. Ehhez két fogalommal kell tisztában lenni.

Az egyik a MinFree. Régebben egyszerűen a teljes memória 6 százalékában határozták meg, de a mai, akár több TB memóriát tartalmazó szerverek esetében ez elég durva lenne. Ezért ezt már sávosan határozzák meg. Valaki vette a fáradságot, és WolframAlpha segítségével felrajzolta. Így egy táblázat helyett sokkal szemléletesebben is látható a MinFree értékének alakulása a teljes memória függvényében.

A másik fogalom a memory state. A 6.0 előtti időkben ebből négy volt, az ESXi 6-ban bevezettek egy ötödiket is. Egy adott host esetében az esxtop-ban a memória értékeknél lehet megnézni az aktuális értéket.

Az egészből csak annyi lényeg, hogy amikor a memory state eléri a MinFree értékének 400%-át, elkezdi szétbontani a 2 MB-os memória lapokat 4KB-os lapokká. Azokat viszont a TPS már tudja kezelni, így mielőtt vészesen lecsökkenne a szabad memória mérete, képes bizonyos nagyságú fizikai memóriát felszabadítani.
Ezekről az állapotokról ezen az oldalon vannak hasznos információk.

A következő cikkben azt fogom röviden leírni, hogy technikailag hogyan működik a "salting", azaz hogyan oldották meg a TPS tiltását vagy engedélyezését.