2016. január 15., péntek

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.


Nincsenek megjegyzések:

Megjegyzés küldése