De alguma forma foi necessário integrar o Rosplatform (R-Virtualization e R-Storage) com o sistema de armazenamento de hardware ( 3PAR ), e isso pode ser muito útil em vários cenários.
Configuração de sinergia
Anteriormente, esse tipo de integração foi testado nos blades (Blade CH121 v5) do blade central Huawei com sistema de armazenamento Dorado 5000 v3, onde SDS (armazenamento definido por software) do P-Storage do Rosplatforma no topo do sistema de armazenamento mostrou-se muito bem devido ao flash, mas com Sinergia , se Discos JBOD do módulo D3940, tudo é muito mais interessante e flexível.
3 Blades de servidor (Synergy 480 Gen10 (871940-B21)):
- Cada um possui duas CPUs Intel® Xeon® Platinum 8270.
- Rede duas portas de 20 Gb / s.
- RAM 256GB.
- Não há discos rígidos nas lâminas.
- No módulo de disco Synergy 2HDD, 900GB em RAID1 para cada SO / hipervisor e 3SSD HPE VK0960GFDKK 960GB para a função de metadados + cache (cada um para um servidor), bem como 9HDD EG0900JFCKB para 900GB.
O sistema operacional foi carregado por meio de um canal por meio de um controlador RAID de um módulo de disco Synergy.
SDS local implantado em um canal JBOD do módulo de disco Synergy.
Configuração 3PAR
O Synergy está conectado a 3PAR (FC16 Gb / s):
Um LUN (um para muitos) RAID6 de SSD com capacidade de 200 GB. 9 LUN RAID6 do HDD, cada um com uma capacidade de 150 GB (três LUNs por blade).
Figura: 1 Diagrama de bancada de teste.
Descrição dos cenários
Testamos várias opções de integração com 3PAR, que também podem ser usadas simultaneamente, todas de uma vez em uma configuração mista.
Cenário com implantação SDS de Rosplatform em LUNs separados de 150 GB cada de 3PAR:
Fig. 2 Cenário com implantação SDS de Rosplatform em LUNs separados
com sistemas de armazenamento para cada nó dos três foi apresentado FC com 3 LUNs de 150 GB.
Em sistemas de armazenamento, eles foram configurados em RAID6 a partir de discos HDD. Na Fig. 2 mostra esquematicamente 10 Gb e switch, mas a implementação foi no nível do switch Synergy com portas de 20 Gb, em que uma interface é para gerenciamento e virtualização e a outra para armazenamento SDS.
Este cenário foi testado para verificar se as seguintes opções funcionam:
- SDS Rosplatform funciona em cima de 3PAR.
- Fortalecimento do SDS de Rosplatforma sobre 3PAR adicionando cache SSD local.
- Criando um pequeno SDS Rosplatform para armazenar arquivos de configuração de VM, onde as próprias VMs são criadas no LUN 3PAR.
- Testando SDS Rosplatforma sobre 3PAR, definindo-o para um traço ligeiramente mais lento do que um traço de discos locais.
2) Um cenário com a criação de uma VM em um LUN de 3PAR:
Fig. 3 Cenário com a criação de uma VM em um LUN de 3PAR.
LUN 200GB RAID6 de SSD para VM foi apresentado com armazenamento. A configuração do LUN é um para muitos.
Este cenário foi testado para verificar os recursos:
- Anexe ao VM LUN diretamente do 3PAR.
- Usando o VM LUN anexado como o disco primário sem usar qcow2.
- Usando várias VMs com o mesmo 200 GB LUN anexado para a instalação subsequente do sistema de arquivos de cluster convidado.
- Migrar uma VM com um LUN de 200 GB do 3PAR e uma falha do nó ao reiniciar esta VM nos nós restantes.
- Usando SDS de 3PAR como armazenamento de arquivos de configuração de VM e o sistema operacional convidado com implantação em LUNs de 3PAR diretamente.
- Usando SDS em discos locais do módulo Synergy como armazenamento de arquivos de configuração de VM e o sistema operacional convidado com implantação em LUN 200 GB diretamente de 3PAR.
Descrição das configurações
Para todos os cenários em cada nó, antes da implantação normal do cluster, as mesmas configurações foram feitas anteriormente, que foram realizadas imediatamente após a instalação de três nós das imagens Rosplatform. Instruções breves para instalação e configuração do próprio cluster estão disponíveis no artigo anterior .
1. habilitando o serviço multipath para carregamento automático:
#chkconfig multipathd on2. habilitar o carregamento de módulos:
#modprobe dm-multipath
#modprobe dm-round-robin3. copiar o modelo de configuração para a pasta da configuração de trabalho:
#cp /usr/share/doc/device-mapper-multipath-0.4.9/multipath.conf /etc/4. Verifique o padrão de inclusão abaixo dos seguintes parâmetros:
defaults {
user_friendly_names yes
find_multipaths yes
}5. adicionar um alias para um disco compartilhado para uma VM:
multipaths {
multipath {
# wwid 3600508b4000156d700012000000b0000
# alias yellow
# path_grouping_policy multibus
# path_selector "round-robin 0"
# failback manual
# rr_weight priorities
# no_path_retry 5
# }
multipath {
wwid 360002ac0000000000000000f000049f4
alias test3par
}
}
6. verificar o início do serviço:
#systemctl start multipathd7. Verificando o serviço e exibindo dispositivos com mpath:
#multipath –ll8. Reinicialização obrigatória:
#reboot9. Verificando o serviço e exibindo dispositivos com mpath:
#multipath –llEm seguida, as configurações de cluster padrão foram realizadas.
Figura: 4 UI da web antes de habilitar o serviço multipath.
Figura: 5 Após habilitar o serviço multipath, os dispositivos dm apareceram.
Captura de tela após a criação do cluster Rosplatforma, onde 200 GB de LUN para VMs são especialmente com uma função não atribuída:
Fig. 6 Captura de tela após a criação do cluster Rosplatforma.
A captura de tela mostra dois tier0 e tier1, onde tier0 é o SDS local e tier1 é SDS sobre 3PAR:
Fig. 7 SDS local e mais 3PAR.
Em seguida, uma VM foi criada sem um disco local com um LUN de 200 GB de 3PAR anexado em seu lugar:
#prlctl set testVM --device-add hdd --device /dev/mapper/ test3parA VM foi criada com os seguintes parâmetros:
- Tipo - CentOS Linux
- vCPU - 4
- RAM - 8
- SO convidado - Centos 7 (1908)
Testes de migração
Os testes de migração foram realizados com ou sem as ferramentas de convidado instaladas.
Em todos os casos, a VM migrou com sucesso sem parar.
Figura: 8 Resultado e tempo de migração da VM.
Test1 - uma VM normal com os mesmos parâmetros apenas com uma imagem de disco local QCOW2 64 GB e migração ao vivo de uma VM test10 com 200 GB de LUN de 3PAR.
O tempo de migração é menor devido ao fato de que durante o processo não há etapa de alternar para uma cópia da imagem do disco VM em outro nó, apenas o arquivo de configuração é copiado com um link para o LUN 200GB, que é visível de qualquer nó do cluster.
Figura: 9 Resultados do Ping.
Durante a migração ao vivo, um ping foi feito para a VM com um LUN de 200 GB de 3PAR.
Foi registrada a perda de apenas um pacote, o mesmo acontece com uma VM normal no SDS, mas a VM permanece acessível pela rede e continua funcionando.
Testes de desligamento de emergência
Quando o servidor foi desligado, no qual havia uma VM com um LUN 200 GB de 3PAR, e depois que o serviço HA detectou o nó ausente, a VM testada foi reiniciada com sucesso em outro nó selecionado pelo algoritmo drs padrão, round robin, continuando a funcionar. Durante o ping, 7 pacotes foram perdidos. Ao alternar, apenas o arquivo de configuração da VM foi iniciado e o sistema operacional convidado sempre foi acessível por meio do caminho anexado ao LUN.
Também testamos a criação de um backup, em que o backup do arquivo de configuração da VM foi feito com sucesso e, ao restaurar a partir desta cópia da VM, foi iniciado com sucesso.
Testes de gravação sequencial para VM com 200GB LUN de 3PAR, que mostraram o desempenho desse LUN de 3PAR, onde Rosplatforma não era uma camada intermediária, e o teste mostra a operação dos sistemas de armazenamento OS convidado e 3PAR.
Parâmetros de fio usados dentro da VM com 200 GB LUN de 3PAR:
[seqwrite]
rw=write
size=4g
numjobs=4
bs=1m
ioengine=libaio
iodepth=32
time_based
#runtime=60
direct=1
filename_format=__testfile'$jobnum'
thread
directory=/sdb/
Testes com um sistema de arquivos em cluster dentro do sistema operacional convidado
Figura: 10 Sistema de arquivos em cluster dentro do sistema operacional convidado.
Um cenário com um LUN de 200 GB conectado a duas VMs foi testado com sucesso, no qual o sistema de arquivos de cluster GFS2 é instalado dentro da VM usando o sistema operacional convidado. Durante o teste, uma das VMs ou o host foi desligado, após o que a outra VM continuou a trabalhar com esse LUN e a gravar / ler arquivos a partir dele. Abaixo está uma captura de tela com as configurações do GFS2 dentro do VM, as saídas dos comandos do marcapasso também são mostradas:
Mais SDS do Rosplatforma no topo do LUN:
Fig. 11 Configurando com SDS Rosplatform implementado em um 3PAR LUN.
O mesmo cenário foi testado com sucesso com um LUN de 200 GB conectado a duas VMs, em que um sistema de arquivos de cluster foi instalado dentro da VM usando o sistema operacional convidado, mas o armazenamento de dados do SDS Rosplatforma criado no LUN do 3PAR foi usado como o local da VM. Durante o teste, uma das VMs ou o host foi desligado, após o que a outra VM continuou a trabalhar com esse LUN e a gravar / ler arquivos a partir dele.
Figura: 12 Teste adicionando SSD para a função de cache do módulo de disco Synergy.
O mesmo cenário foi testado com sucesso com um LUN de 200 GB conectado a duas VMs, em que um sistema de arquivos de cluster foi instalado dentro da VM usando o sistema operacional convidado, mas o armazenamento de dados do SDS Rosplatforma criado no LUN do 3PAR foi usado como o local da VM. Além disso, este armazenamento de dados foi aprimorado em desempenho ao adicionar um SSD como um cache do módulo de disco Synergy. Durante o teste, uma das VMs ou o host foi desligado, após o que a outra VM continuou a trabalhar com esse LUN e a gravar / ler arquivos a partir dele.
Testes de sistema de arquivos de cluster em nós Rosplatform
Figura: 13 Foi apresentado o teste com arquivos de configuração VM localizados no SDS Rosplatforma, do 3PAR LUN 200GB.
Um cenário foi testado com armazenamento compartilhado de 3PAR para imagens de disco VM em um sistema de arquivos de cluster, que foi instalado nos nós Rosplatforma, e os arquivos de configuração dessas VMs foram localizados no SDS do Rosplatforma. Durante o teste, um dos hosts foi desligado, após o que as VMs tiveram que continuar trabalhando com suas imagens de disco devido ao trabalho de dois outros hosts de acordo com a réplica 3 no cluster SDS para arquivos de configuração de VM e 3 logs do sistema de arquivos de cluster para imagens de disco VM.
Figura: 14 SDS é trazido para LUN de 3PAR.
Um cenário foi testado com armazenamento compartilhado de 3PAR para imagens de disco VM em um sistema de arquivos de cluster, que foi instalado nos nós Rosplatforma, e os arquivos de configuração dessas VMs foram localizados no SDS do Rosplatforma, onde SDS foi elevado para o LUN de 3PAR. Durante o teste, um dos hosts foi desligado, após o que as VMs tiveram que continuar trabalhando com suas imagens de disco devido ao trabalho de dois outros hosts de acordo com a réplica 3 no cluster SDS para arquivos de configuração de VM e 3 logs do sistema de arquivos de cluster para imagens de disco VM.
Figura: 15 SDS tier0 em LUNs de 3PAR, SDS tier1 em discos do módulo Synergy.
Um cenário foi testado com armazenamento compartilhado de 3PAR para imagens de disco VM em um sistema de arquivos de cluster, que foi instalado nos nós Rosplatforma, e os arquivos de configuração dessas VMs foram localizados em SDS de Rosplatform, onde SDS tier0 foi gerado em LUN de 3PAR e o segundo SDS tier1 em discos do módulo Sinergia. Durante o teste, um dos hosts foi desligado, após o que as VMs tiveram que trabalhar com suas imagens de disco devido ao trabalho de dois outros hosts de acordo com a réplica 3 no cluster SDS para arquivos de configuração de VM e 3 logs do sistema de arquivos de cluster para imagens de disco VM. Mas houve problemas com o trabalho do kvm-qemu com o GFS2, após uma longa investigação, o gerenciador de bloqueio do GFS2 falhou e o Rosplatforma não pôde iniciar a VM em outro host do cluster por causa disso. A questão permanece aberta. O mesmo com as opções nas Figuras 13 e 14.Um possível problema com este cenário está na maneira como o kvm-qemu funciona com o qcow2 e a imagem bruta, onde as operações de gravação são síncronas e o gerenciador de bloqueio GFS2 é limitado para tais operações.
Conclusão
As opções de SDS para LUN de 3PAR e apresentação de LUN de 3PAR funcionam bastante e podem ser usadas para trabalhar em infraestrutura, mas é claro que têm algumas desvantagens.
Por exemplo, no caso do SDS nas luas, o desempenho sempre será ligeiramente inferior ao do SDS nos discos locais. Você pode melhorar isso usando SSDs locais com a função de cache, mas o SDS regular sempre será predominantemente mais rápido. Como opção, o SDS no armazenamento pode ser configurado em uma galeria de tiro separada. Outro ponto negativo não sem importância é a tolerância a falhas, no SDS cada nó é um controlador, onde pelo menos um cluster começa com três nós, então no caso de sistemas de armazenamento há sempre dois controladores por rack. Para o SDS, esse é um único ponto de falha, mas, apesar dessas desvantagens, esses cenários ocorrem durante uma transição gradual do armazenamento externo para o SDS ou ao descartar um sistema de armazenamento existente. Além disso, existem recursos do próprio sistema de armazenamento, como desduplicação, compressão, que, devido às peculiaridades da abordagem arquitetônicanão no SDS Rosplatforma, mas o 3PAR tem e, graças aos cenários descritos acima, eles podem ser usados no nível de armazenamento.
Cenários com apresentação de LUN para VMs, para sistemas convidados com seu próprio sistema de cluster também são relevantes. No caso da apresentação do LUN para cada VM separadamente, existem desvantagens como a falta de automação durante o ciclo de vida de um grande número de VMs, o que poderia ser devido ao sistema de arquivos do cluster nos nós Rosplatforma, mas GFS2 com kvm-qemu neste caso falhou, se usar para quaisquer outros arquivos, então tudo funciona mesmo em testes de emergência no Rosplatform, mas assim que as imagens VM são colocadas lá, o gerenciador de bloqueio GFS2 falha nos testes de emergência. Talvez esse problema seja resolvido.
Os cenários acima para usar caminhos múltiplos podem ser úteis para vincular bibliotecas de fitas. Rosplatform tem um sistema de backup embutido (SRK), que pode gravar cópias na pasta de cluster de armazenamento P ou em uma pasta local, mas não pode trabalhar com dispositivos de fita até que você escreva um script ou, para esses fins, você pode usar SRK externo, por exemplo rubackup , que além de trabalhar com fita, ajudará a fazer cópias de VMs com LUNs anexados, o que é importante na integração com sistemas de armazenamento.