Economizamos em um controlador RAID ou como alimentar Varia com Iops

Na nossa era de serviços em nuvem, o AWS Lambda e outras acomodações compartilhadas de recursos de computação absolutamente intangíveis, às vezes eu quero um pouco. Além do desejo, às vezes também há necessidade de distorcer cuidadosamente um ou outro produto de software com custos mínimos de plataforma. Quase sempre é possível encontrar algum excesso de equipamento; às vezes, ele acaba montando tudo e ligando-o. Se esses excedentes representam uma CPU com pelo menos 4-6 núcleos e memória de 64 GB - geralmente excelente, você pode usar o ESXi e trabalhar com qualquer coisa. Um problema: com uma capacidade de disco no hardware doméstico da VMWare - absolutamente nada. O desempenho dos HDDs locais únicos é baixo e a perda do conteúdo de um único parafuso no vácuo no século XXI é como olá. Vamos tentar conectar algo pela rede.

TL; DR> associação, balanceamento, limite de rr, isso é tudo.

Na verdade, o texto abaixo não trata do fato de que isso geralmente é possível ou de algum tipo de conhecimento. A Internet está cheia de artigos para manequins (verifique aqui, em seguida, Avançar, Avançar, Concluído) sobre como enviar uma capacidade de disco iSCSI. Estou escrevendo apenas para excluir os "erros dos sobreviventes" e compartilhar os momentos em que "tudo vai dar errado" (e vai acontecer, Murphy estava certo) e, quando você tenta carregar a solução, ela simplesmente trava.

Portanto, tentaremos sufocar nosso "hypervisor doméstico" com uma matriz de disco externa conectada pela rede. Como tudo gira em torno de "barato", sejam FreeNAS e 4 discos SATA, que são atendidos por medíocres 3 GHz a 45 nm por cento. Olhamos para o Ebay e, por dinheiro comparável a um controlador RAID usado, eles arrastam duas placas de rede i350-T4 de lá. Estes são adaptadores de quatro portas gigabit da Intel. Segundo eles, associaremos o armazenamento ao hipervisor.

Conte um pouco. A velocidade média de transferência de dados de um disco SATA médio é de 160 a 180 MB / s com uma largura de interface de 6 Gb / s. De fato, a taxa real de transferência de dados do HDD não excede 2 Gb / s. Esse não é um número tão grande, já que planejamos portas de 4 gigabit (como transformar 4x1Gbps em 4Gbps - discutiremos mais adiante). Tudo com velocidades de acesso aleatório é muito pior - aqui tudo cai quase no nível de disquetes.


Dado que o perfil de carregamento de disco de muitos sistemas operacionais convidados está longe de ser linear, eu gostaria de ver mais números divertidos. Para corrigir a situação no sistema de arquivos do hypervisor (VMFS v6), o tamanho do bloco é de 1 MB, o que ajuda a compactar muitas operações aleatórias e agiliza o acesso aos dados em discos virtuais. Mas mesmo com isso, um disco físico não será suficiente para lidar com operações de E / S de todos os "convidados".

Farei uma reserva imediatamente - tudo faz mais sentido se você tiver mais de dois adaptadores para a "rede de armazenamento". O ESXi com uma licença de processador único gratuita pode se conectar, além de discos locais, a dois tipos de armazenamento - NFS e iSCSI. O NFS envolve acesso no nível do arquivo e também é bom à sua maneira. Nele, você pode implantar convidados pouco exigentes no desempenho do disco. É um prazer apoiá-los. você pode abrir a mesma bola NFS em outro lugar e copiar snapshots vm. Em geral, com uma interface de rede (se não for 10GE, é claro) - o NFS é sua escolha.

O ISCSI tem várias vantagens sobre o NFS. Para realizá-los completamente, nós já preparamos - já estabelecemos 4 portas de gigabit para a rede de armazenamento. Como a expansão da largura de banda da rede geralmente ocorre em uma velocidade de interface conhecida? É isso mesmo, agregação. Porém, para a utilização completa do canal agregado, são necessárias várias condições, e isso é mais adequado para a comunicação entre comutadores ou para um uplink de rede de um hypervisor. A implementação do protocolo iSCSI fornece uma função como caminhos múltiplos (literalmente, muitos caminhos) - a capacidade de conectar o mesmo volume através de diferentes interfaces de rede. Obviamente, também sobre a possibilidade de balanceamento de carga, embora o principal objetivo seja a tolerância a falhas da rede de armazenamento. (Para ser honesto, o NFSv4.1 oferece suporte ao entroncamento de sessão com base na mágica mais avançada, como RDMA e MPTCP, mas essa é uma tentativa de mudar os problemas de acesso a arquivos de uma cabeça dolorida para uma saudável para níveis mais baixos.)

Então, para começar, publicaremos nosso destino. Acreditamos que o FreeNAS está instalado, o endereço IP do gerenciamento envia regularmente a interface da Web para nós, cortamos a matriz e zvol nela de acordo com nossas convicções internas. No nosso caso, trata-se de uma unidade de 4 x 500 GB combinada no raidz1 (que fornece apenas 1,3 TiB de capacidade efetiva) e o zvol tem exatamente 1 TB de tamanho. Vamos configurar as interfaces de rede do i350. Por simplicidade, aceitamos que todos pertençam a diferentes sub-redes.


Em seguida, configuramos a bola iSCSI usando o método “Next, Next, Done”. Ao configurar o portal, não esqueça de adicionar todas as interfaces de rede dedicadas ao iSCSI lá. Deve parecer algo como nas fotos.



É necessário prestar um pouco mais de atenção na definição da extensão - ao apresentar um volume, é necessário forçar um tamanho de bloco de 512 bytes. Sem isso, o iniciador do ESXi se recusou a identificar os volumes apresentados. Por uma questão de fidelidade, é melhor desativar os tamanhos dos probros do bloco físico (que no zvol não é e não pode ser) e ativar o modo de suporte do Xen.
Com o FreeNAS por enquanto.

No lado ESXi, é um pouco mais complicado com a configuração da rede. Novamente, acreditamos que o hipervisor em si está instalado e também gerenciado em uma porta separada. Você precisará selecionar 4 interfaces de VM Kernel pertencentes a 4 grupos de portas diferentes em 4 comutadores virtuais diferentes. Cada um desses comutadores possui sua própria porta física de ligação ascendente. Pegamos os endereços vmk #, é claro, nas sub-redes correspondentes, da mesma forma que na configuração das portas de armazenamento. A ordem de configuração dos endereços é, em geral, importante - conectamos placas porta a porta sem um comutador ou damos links diferentes para redes diferentes (bem, isso é de uma maneira adulta), portanto, a correspondência física de portas é importante.




Ao configurar uma rede para iSCSI, prestamos atenção especial ao parâmetro MTU. É exatamente esse o caso quando o “tamanho importa” - levamos o máximo que todos os componentes de rede podem instalar. Se as placas estiverem conectadas diretamente, você poderá apontar o mtu 9000 nos dois lados, no ESXi e no FreeNAS. No entanto, comutadores normais suportam esse valor. Se fizermos ping, vemos que a rede está normal e os pacotes do tamanho necessário são aprovados. Ótimo. Atingimos o iniciador.

Ligue o iSCSI, adicione endereços IP à seção de configuração dinâmica (Armazenamento -> Adaptadores -> Configurar iSCSI -> Destinos dinâmicos). Após salvar, os portais iSCSI serão pesquisados ​​nesses endereços, o iniciador determinará que cada um deles tem o mesmo volume e se conectará a ele em todos os endereços disponíveis (o mesmo caminho múltiplo). Em seguida, precisamos criar um armazenamento de dados no dispositivo que aparece.

Depois disso, você pode implantar a máquina virtual e medir o que conseguimos.


Resultados não tão impressionantes. Abra o console de armazenamento, exiba o status atual da rede e execute os testes.

root@freenas:~ # systat -ifstat

Somente uma das quatro portas de rede (igb1) foi utilizada. Isso acontece porque o mecanismo de balanceamento fornecido por padrão para o multipath seleciona o mesmo adaptador para cada pacote de dados. Precisamos usar tudo.
Estamos conectados ao hypervisor via SSH e comando.
Primeiro, vamos ver qual ID a lua possui com caminhos múltiplos e como funciona:

[root@localhost:~] esxcfg-mpath -b
naa.6589cfc000000b478db42ca922bb9308 : FreeNAS iSCSI Disk (naa.6589cfc000000b478db42ca922bb9308)

[root@localhost:~] esxcli storage nmp device list -d naa.6589cfc000000b478db42ca922bb9308 | grep PSP
Path Selection Policy: VMW_PSP_MRU

A política de seleção de caminho é MRU, ou seja, usada mais recentemente. Todos os dados vão para a mesma porta, a re-seleção do caminho ocorre apenas quando a conexão de rede não está disponível. Mudamos para round-robin, no qual todas as interfaces mudam após um certo número de operações:

[root@localhost:~] esxcli storage nmp device set -d naa.6589cfc000000b478db42ca922bb9308 -P VMW_PSP_RR

Reiniciamos o ESXi, monitoramos e executamos testes. Vemos que a carga é distribuída uniformemente pelos adaptadores de rede (pelo menos, valores de pico, excesso de raspagem), os resultados do teste também são mais divertidos.

  Interface Peak igb3 in 43.233 MB/s out 46.170 MB/s igb2 in 42.806 MB/s out 45.773 MB/s igb1 in 43.495 MB/s out 45.489 MB/s igb0 in 43.208 MB/s out 46.079 MB/s 

Existem alguns desvios nas portas, devido aos limites da Política de Seleção de Caminho - o número de operações ou bytes, após o qual a mudança para outra porta ocorre. Por padrão, 1000 IOPS, ou seja, se a troca de dados estiver dentro de 999 operações, ela passará por uma porta de rede. Você pode alterar, comparar e selecionar o valor apropriado. Você não pode mudar, o padrão é suficiente para a maioria das tarefas.

Tomamos medidas, testamos, trabalhamos. Os resultados são significativamente superiores aos recursos de uma única unidade; portanto, agora nossas máquinas virtuais podem não ser utilizadas nas operações de E / S. As velocidades resultantes e a tolerância a falhas da matriz dependerão do hardware e de como o volume está configurado.