Eén van de doelstellingen van de hostingprovider is het maximaliseren van de benutting van bestaande apparatuur om hoogwaardige dienstverlening aan eindgebruikers te kunnen bieden. De middelen van eindservers zijn altijd beperkt, maar het aantal gehoste clientdiensten, en in ons geval hebben we het over VPS, kan aanzienlijk verschillen. Lees hoe je in de boom klimt en een burger onder de snee eet.
Het comprimeren van VPS op een node op zo'n manier dat klanten er helemaal niets van merken, helpt enorm om de economische prestaties van elke hostingprovider te verbeteren. Natuurlijk mag een knooppunt niet uit zijn voegen barsten als het vol staat met containers, en elke piek in de belasting is onmiddellijk voelbaar voor alle klanten.
Hoeveel VPS er op één knooppunt kunnen worden gehost, hangt van veel factoren af, waaronder voor de hand liggende:
1. Kenmerken van de hardware van het knooppunt zelf
2. VPS-formaat
3. Aard van de belasting van de VPS
4. Softwaretechnologieën die de dichtheid helpen optimaliseren
In dit geval zullen we onze ervaringen met het gebruik van Pfcache-technologie voor Virtuozzo delen.
Wij gebruiken de 6e tak, maar alles wat gezegd wordt geldt ook voor de 7e.
– een Virtuozzo-mechanisme dat helpt bij het dedupliceren van IOPS en RAM in containers, waarbij identieke bestanden in containers in een aparte gemeenschappelijke ruimte worden toegewezen.
Feitelijk bestaat het uit:
1. Kernelcode
2. Demon van de gebruikersruimte
3. Hulpprogramma's voor gebruikersruimte
Aan de node-kant wijzen we een hele sectie toe waarin bestanden worden aangemaakt die direct door alle VPS op de node zullen worden gebruikt. In deze sectie is een blokploopapparaat gemonteerd. Wanneer de container vervolgens start, ontvangt deze een referentie voor deze sectie:
[root@pcs13 ~]# cat /proc/mounts
...
/dev/ploop62124p1 /vz/pfcache ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
...
/dev/ploop22927p1 /vz/root/418 ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,pfcache_csum,pfcache=/vz/pfcache 0 0
/dev/ploop29642p1 /vz/root/264 ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,pfcache_csum,pfcache=/vz/pfcache 0 0
...
Hier zijn geschatte statistieken over het aantal bestanden op een van onze knooppunten:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
Het principe van pfcache is als volgt:
• De gebruikersruimte-daemon Pfcached schrijft de sha-1-hash van het bestand naar het xattr-attribuut van dit bestand. Niet alle bestanden worden verwerkt, maar alleen in de mappen /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• Het is zeer waarschijnlijk dat de bestanden in deze mappen worden “gedeeld” en door meerdere containers worden gebruikt;
• Pfcached verzamelt periodiek statistieken over het lezen van bestanden uit de kernel, analyseert deze en voegt bestanden toe aan de cache als ze vaak worden gebruikt;
• Deze mappen kunnen verschillend zijn en zijn geconfigureerd in configuratiebestanden.
• Bij het lezen van een bestand wordt gecontroleerd of het de opgegeven hash in de uitgebreide xattr-attributen bevat. Als dit het geval is, wordt het “algemene” bestand geopend in plaats van het containerbestand. Deze vervanging gebeurt onopgemerkt door de containercode en is verborgen in de kernel;
• Bij het schrijven naar een bestand wordt de hash ongeldig gemaakt. De volgende keer dat u het opent, wordt dus het containerbestand zelf geopend en niet de cache.
Door gedeelde bestanden van /vz/pfcache in de paginacache te bewaren, realiseren we besparingen in deze cache zelf, evenals besparingen in IOPS. In plaats van tien bestanden van schijf te lezen, lezen we er één, die onmiddellijk naar de paginacache gaat.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
De VMA-lijst voor het bestand blijft enkelvoudig (we ontdubbelen het geheugen) en wordt minder vaak van schijf gelezen (iops besparen). Ons gemeenschappelijke fonds bevindt zich op een SSD - een extra snelheidswinst.
Voorbeeld voor het cachen van het bestand /bin/bash:
[root@pcs13 ~]# ls -li /vz/root/2388/bin/bash
524650 -rwxr-xr-x 1 root root 1021112 Oct 7 2018 /vz/root/2388/bin/bash
[root@pcs13 ~]# pfcache dump /vz/root/2388 | grep 524650
8e3aa19fdc42e87659746f6dc8ea3af74ab30362 i:524650 g:1357611108 f:CP
[root@pcs13 ~]# sha1sum /vz/root/2388/bin/bash
8e3aa19fdc42e87659746f6dc8ea3af74ab30362 /vz/root/2388/bin/bash
[root@pcs13 /]# getfattr -ntrusted.pfcache /vz/root/2388/bin/bash
# file: vz/root/2388/bin/bash
trusted.pfcache="8e3aa19fdc42e87659746f6dc8ea3af74ab30362"
[root@pcs13 ~]# sha1sum /vz/pfcache/8e/3aa19fdc42e87659746f6dc8ea3af74ab30362
8e3aa19fdc42e87659746f6dc8ea3af74ab30362 /vz/pfcache/8e/3aa19fdc42e87659746f6dc8ea3af74ab30362
We berekenen de efficiëntie van het gebruik .
Dit script doorloopt alle containers op het knooppunt en berekent de in de cache opgeslagen bestanden van elke container.
[root@pcs16 ~]# /pcs/distr/pfcache-examine.pl
...
Pfcache cache uses 831 MB of memory
Total use of pfcached files in containers is 39837 MB of memory
Pfcache effectiveness: 39006 MB
We slaan dus vanuit het geheugen ongeveer 40 gigabyte aan bestanden op in containers, ze worden vanuit de cache geladen.
Om dit mechanisme nog beter te laten werken, is het noodzakelijk om de meest “identieke” VPS op de node te plaatsen. Bijvoorbeeld degene waartoe de gebruiker geen root-toegang heeft en waarop de omgeving van de geïmplementeerde image is geconfigureerd.
U kunt pfcache afstemmen via het configuratiebestand
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – minimale/maximale bestandsgrootte voor caching
TIMEOUT – time-out tussen cachepogingen
U kunt de volledige lijst met parameters bekijken .
Bron: www.habr.com