Um dos objetivos do provedor de hospedagem é maximizar a utilização dos equipamentos existentes para fornecer um serviço de alta qualidade aos usuários finais. Os recursos dos servidores finais são sempre limitados, mas o número de serviços de clientes hospedados, e no nosso caso estamos falando de VPS, pode diferir significativamente. Leia sobre como subir em uma árvore e comer um hambúrguer cortado.
Compactar o VPS em um nó de forma que os clientes não sintam isso ajuda muito a aumentar o desempenho econômico de qualquer provedor de hospedagem. É claro que um nó não deve estourar se estiver abarrotado de contêineres, e qualquer aumento na carga será imediatamente sentido por todos os clientes.
Quantos VPS podem ser hospedados em um nó depende de muitos fatores, alguns óbvios como:
1. Características do hardware do próprio nó
2. Tamanho do VPS
3. Natureza da carga no VPS
4. Tecnologias de software que ajudam a otimizar a densidade
Neste caso, compartilharemos nossa experiência no uso da tecnologia Pfcache para Virtuozzo.
Usamos o 6º ramo, mas tudo o que foi dito também se aplica ao 7º.
– um mecanismo Virtuozzo que ajuda a desduplicar IOPS e RAM em contêineres, alocando arquivos idênticos em contêineres para uma área comum separada.
Na verdade consiste em:
1. Código do kernel
2. Demônio do espaço do usuário
3. Utilitários de espaço do usuário
No lado do nó, alocamos uma seção inteira na qual serão criados os arquivos que serão usados diretamente por todos os VPS do nó. Um dispositivo block ploop é montado nesta seção. Então, quando o contêiner for iniciado, ele receberá uma referência para esta seção:
[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
...
Aqui estão estatísticas aproximadas sobre o número de arquivos em um de nossos nós:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
O princípio do pfcache é o seguinte:
• O daemon de espaço do usuário Pfcached grava o hash sha-1 do arquivo no atributo xattr desse arquivo. Nem todos os arquivos são processados, mas apenas nos diretórios /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
• É mais provável que os arquivos nestes diretórios sejam “compartilhados” e utilizados por vários containers;
• O Pfcached coleta periodicamente estatísticas sobre a leitura de arquivos do kernel, analisa-os e adiciona arquivos ao cache se eles forem usados com frequência;
• Esses diretórios podem ser diferentes e estão configurados em arquivos de configuração.
• Ao ler um arquivo, é verificado se ele contém o hash especificado nos atributos estendidos do xattr. Se contiver, o arquivo “geral” será aberto em vez do arquivo contêiner. Essa substituição ocorre despercebida pelo código do contêiner e fica oculta no kernel;
• Ao gravar em um arquivo, o hash é invalidado. Assim, na próxima vez que você abri-lo, o próprio arquivo contêiner será aberto, e não seu cache.
Ao manter os arquivos compartilhados de /vz/pfcache no cache da página, conseguimos economia neste próprio cache, bem como economia no IOPS. Em vez de ler dez arquivos do disco, lemos um, que vai imediatamente para o cache da página.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
A lista VMA do arquivo permanece única (desduplicamos a memória) e é lida do disco com menos frequência (salvando iops). Nosso fundo comum está localizado em um SSD - um ganho adicional em velocidade.
Exemplo de armazenamento em cache do arquivo /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
Calculamos a eficiência de uso .
Este script percorre todos os contêineres do nó, calculando os arquivos armazenados em cache de cada contêiner.
[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
Assim, da memória salvamos cerca de 40 gigabytes de arquivos em containers, eles serão carregados do cache.
Para que este mecanismo funcione ainda melhor, é necessário colocar o VPS mais “idêntico” no nó. Por exemplo, aqueles para os quais o usuário não tem acesso root e nos quais o ambiente da imagem implementada está configurado.
Você pode ajustar o pfcache através do arquivo de configuração
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE – tamanho de arquivo mínimo/máximo para armazenamento em cache
TIMEOUT – tempo limite entre tentativas de cache
Você pode ver a lista completa de parâmetros .
Fonte: habr.com