O ano de 2018 estava terminando ...Uma vez, em um claro dia de dezembro, nossa empresa decidiu comprar um novo hardware. Não, é claro, isso não aconteceu da noite para o dia. A decisão foi tomada anteriormente. Muito mais cedo. Mas, como sempre, nem sempre nossos desejos coincidem com as capacidades dos acionistas. E não havia dinheiro, e continuamos. Mas, finalmente, esse momento de alegria chegou quando a aquisição foi aprovada em todos os níveis. Tudo estava bem, os trabalhadores de colarinho branco aplaudiam alegremente, estavam cansados de processar documentos durante 25 horas por mês em servidores de 7 anos e pediam persistentemente ao Departamento de TI que criasse algo para lhes dar mais tempo para outras coisas igualmente importantes .Prometemos reduzir o tempo de processamento de documentos em 3 vezes, em até 8 horas. Para isso, um pardal foi disparado de um canhão. Essa opção parecia a única, já que nossa equipe não tinha e nunca teve um administrador de banco de dados para aplicar todos os tipos de otimização de consulta (DBA).A configuração do equipamento selecionado era, obviamente, muito alta. Estes eram três servidores da empresa HPE - DL560 Gen10. Cada um deles possuía 4 processadores Intel Xeon Platinum 8164 2.0Ghz com 26 núcleos, 256 DDR4 RAM, além de 8 SSD de 800Gb SAS (800Gb WD Ultrastar DC SS530 WUSTR6480ASS204 SSD) + 8 1.92Tb SSD (Western Digital Ultrastar DC SS530 )Esses "pedaços de ferro" foram projetados para o cluster VMware (HA + DRS + vSAN). Que trabalha conosco há quase 3 anos em servidores similares da 7ª e 8ª gerações, também da HPE. A propósito, não houve problemas até a HPE se recusar a dar suporte a eles e atualizar o ESXi da versão 6.0, mesmo para a 6.5, sem um pandeiro. Bem, ok, como resultado, foi possível atualizar. Alterando a imagem de instalação, removendo módulos de problemas incompatíveis da imagem de instalação, etc. Isso também adicionou combustível ao fogo de nosso desejo de combinar tudo de novo. Obviamente, se não fossem os novos "truques" do vSAN, no caixão vimos uma atualização de todo o sistema da versão 6.0 para o mais recente, e não seria necessário escrever um artigo, mas não estamos procurando maneiras fáceis ...Então, compramos esse equipamento e decidimos substituir o antigo obsoleto. Aplicamos o último SPP a cada novo servidor, instalado em cada uma delas duas placas de rede Ethernet 10G (uma para redes de usuários e a segunda para SAN, 656596-B21 HP Ethernet 10Gb 2 portas 530T). Sim, cada novo servidor veio com uma placa de rede SFP + sem módulos, mas nossa infraestrutura de rede implicava em Ethernet (duas pilhas de comutadores DELL 4032N para redes LAN e SAN), e o distribuidor da HP em Moscou não possuía módulos HPE 813874-B21 e nós eles não esperaram.Quando chegou a hora de instalar o ESXi e incorporar novos nós em um data center comum da VMware, ocorreu um "milagre". Como se viu, o HPE ESXi Custom ISO versão 6.5 e inferior não foi projetado para ser instalado nos novos servidores Gen10. Apenas hardcore, apenas 6.7. E tivemos que seguir inconscientemente os preceitos da "empresa virtual".Um novo cluster HA + DRS foi criado, um cluster vSAN, tudo em estrita conformidade com o VMware HCL e este documento . Tudo foi configurado de acordo com o Feng Shui e apenas "alarmes" periódicos eram suspeitos no monitoramento do vSAN sobre valores de parâmetros diferentes de zero nesta seção:
Nós, com toda a tranquilidade, transferimos todas as máquinas virtuais (cerca de 50 peças) para novos servidores e para o novo armazenamento vSAN, que já foi construído em discos SSD, verificamos o desempenho do processamento de documentos no novo ambiente (a propósito, ele economizou muito mais tempo do que o planejado) . Até a base mais pesada ser transferida para o novo cluster, a operação, mencionada no início do artigo, levava cerca de 4 horas em vez de 25! Essa foi uma contribuição significativa para o clima de Ano Novo de todos os participantes do processo. Alguns provavelmente começaram a sonhar com um prêmio. Então todos saíram felizes para o feriado de Ano Novo.Quando os dias da semana do novo ano de 2019 começaram, nada pressagiava uma catástrofe. Todos os serviços, transferidos para novas capacidades, sem exageros, decolaram! Somente eventos na seção de ressincronização de objetos se tornaram muito mais. E depois de algumas semanas, aconteceu um problema. No início da manhã, quase todos os principais serviços da empresa (1s, MSSQL, SMB, Exchange etc.) pararam de responder ou começaram a responder com um longo atraso. Toda a infraestrutura mergulhou em um caos completo, e ninguém sabia o que havia acontecido e o que fazer. Todas as máquinas virtuais no vCenter pareciam "verdes", não havia erros no monitoramento. Reiniciar não ajudou. Além disso, após uma reinicialização, algumas máquinas não podiam nem inicializar, exibindo vários erros de processo no console. O inferno parecia chegar até nós e o diabo estava esfregando as mãos em antecipação.Sob pressão de um estresse sério, foi possível determinar a fonte do desastre. Esse problema acabou sendo o armazenamento distribuído vSAN. Ocorreu uma corrupção de dados não controlada em discos de máquinas virtuais, à primeira vista - sem motivo. Naquela época, a única solução que parecia racional era entrar em contato com o suporte técnico da VMware com gritos: SOS, salve-ajuda!E essa decisão, posteriormente, salvou a Empresa da perda de dados relevantes, incluindo caixas de correio de funcionários, bancos de dados e arquivos compartilhados. Juntos, estamos falando de mais de 30 terabytes de informação.Ele é obrigado a prestar homenagem à equipe de suporte da VMware que não "jogou futebol" com o titular da assinatura básica de suporte técnico, mas incluiu esse caso no segmento Enterpise e o processo girava 24 horas por dia.O que aconteceu depois:- O suporte técnico da VMware colocou duas questões principais: como recuperar dados e como resolver o problema de corrupção de dados "fantasma" em discos de máquina virtual no cluster de combate "vSAN". A propósito, os dados não estavam em lugar algum para se recuperar, uma vez que o armazenamento adicional era ocupado por cópias de backup e simplesmente não havia lugar para implantar serviços de “combate”.
- Enquanto eu, juntamente com a VMware, tentava reunir os objetos "danificados" no cluster vSAN, meus colegas exploraram urgentemente um novo armazenamento que poderia acomodar todos os mais de 30 terabytes de dados da empresa.
- , , VMware , , «» - - . , ?
- .
- , « » .
- , , «» .
- Eu tive que sacrificar temporariamente (por alguns dias) a eficiência do correio, por uma questão de 6 terabytes adicionais de espaço livre na loja, para lançar os principais serviços dos quais dependia a receita da empresa.
- Milhares de linhas de bate-papo com colegas de língua inglesa da VMware foram salvas "para memória", eis um pequeno trecho de nossas conversas:
I understood that you are now migrating all the VMs out of vSAN datastore.
May I know, how the migration task is going on.? How many VMs left and how much time is expected to migrate the remaining VMs. ?
There are 6 vms still need to be migrated. 1 of them is fail so far.
How much time is expected to complete the migration for the working VMs..?
I think atleast 2-3 hours
ok
Can you please SSH to vCenter server ?
you on it
/localhost/Datacenter ###CLUB/computers/###Cluster> vsan.check_state .
2019-02-02 05:22:34 +0300: Step 1: Check for inaccessible vSAN objects
Detected 3 objects to be inaccessible
Detected 7aa2265c-6e46-2f49-df40-20677c0084e0 on esxi-dl560-gen10-2.####.lan to be inaccessible
Detected 99c3515c-bee0-9faa-1f13-20677c038dd8 on esxi-dl560-gen10-3.####.lan to be inaccessible
Detected f1ca455c-d47e-11f7-7e90-20677c038de0 on esxi-dl560-gen10-1.####.lan to be inaccessible
2019-02-02 05:22:34 +0300: Step 2: Check for invalid/inaccessible VMs
Detected VM 'i.#####.ru' as being 'inaccessible'
2019-02-02 05:22:34 +0300: Step 3: Check for VMs for which VC/hostd/vmx are out of sync
Did not find VMs for which VC/hostd/vmx are out of sync
/localhost/Datacenter ###CLUB/computers/###Cluster>
Thank you
second vm with issues: sd.####.ru
Como esse problema se manifestou (além dos serviços da organização firmemente caídos).Crescimento exponencial de erros de soma de verificação (CRC) "fora do azul" durante a troca de dados com discos no modo HBA. Como verificar isso - digite o seguinte comando no console de cada nó do ESXi:while true; do clear; for disk in $(localcli vsan storage list | grep -B10 'ity Tier: tr' |grep "VSAN UUID"|awk '{print $3}'|sort -u);do echo ==DISK==$disk====;vsish -e get /vmkModules/lsom/disks/$disk/checksumErrors | grep -v ':0';done; sleep 3; done
Como resultado da execução, você pode ver erros CRC para cada disco no cluster vSAN deste nó (os valores zero não serão exibidos). Se você possui valores positivos e, além disso, eles estão em constante crescimento, há uma razão para tarefas que surgem constantemente na seção Monitor -> vSAN -> Resincing objects do cluster.Como recuperar discos de máquinas virtuais que não clonam ou migram por meios padrão?Quem pensaria usando o poderoso comando cat:1. cd vSAN
[root@esxi-dl560-gen10-1:~] cd /vmfs/volumes/vsanDatastore/estaff
2. grep vmdk uuid
[root@esxi-dl560-gen10-1:/vmfs/volumes/vsan:52f53dfd12dddc84-f712dbefac32cd1a/2636a75c-e8f1-d9ca-9a00-20677c0084e0] grep vsan *vmdk
estaff.vmdk:RW 10485760 VMFS "vsan://3836a75c-d2dc-5f5d-879c-20677c0084e0"
estaff_1.vmdk:RW 41943040 VMFS "vsan://3736a75c-e412-a6c8-6ce4-20677c0084e0"
[root@esxi-dl560-gen10-1:/vmfs/volumes/vsan:52f53dfd12dddc84-f712dbefac32cd1a/2636a75c-e8f1-d9ca-9a00-20677c0084e0]
3. VM , :
mkdir /vmfs/volumes/POWERVAULT/estaff
4. vmx
cp *vmx *vmdk /vmfs/volumes/POWERVAULT/estaff
5. , ^_^
/usr/lib/vmware/osfs/bin/objtool open -u 3836a75c-d2dc-5f5d-879c-20677c0084e0; sleep 1; cat /vmfs/devices/vsan/3836a75c-d2dc-5f5d-879c-20677c0084e0 >> /vmfs/volumes/POWERVAULT/estaff/estaff-flat.vmdk
6. cd :
cd /vmfs/volumes/POWERVAULT/estaff
7. - estaff.vmdk
[root@esxi-dl560-gen10-1:/tmp] cat estaff.vmdk
# Disk DescriptorFile
version=4
encoding="UTF-8"
CID=a7bb7cdc
parentCID=ffffffff
createType="vmfs"
# Extent description
RW 10485760 VMFS "vsan://3836a75c-d2dc-5f5d-879c-20677c0084e0" <<<<< "estaff-flat.vmdk"
# The Disk Data Base
#DDB
ddb.adapterType = "ide"
ddb.deletable = "true"
ddb.geometry.cylinders = "10402"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.longContentID = "6379fa7fdf6009c344bd9a64a7bb7cdc"
ddb.thinProvisioned = "1"
ddb.toolsInstallType = "1"
ddb.toolsVersion = "10252"
ddb.uuid = "60 00 C2 92 c7 97 ca ae-8d da 1c e2 3c df cf a5"
ddb.virtualHWVersion = "8"
[root@esxi-dl560-gen10-1:/tmp]
Como reconhecer discos naa.xxxx ... em grupos de discos:[root@esxi-dl560-gen10-1:/vmfs/volumes] vdq -Hi
Mappings:
DiskMapping[0]:
SSD: naa.5000c5003024eb43
MD: naa.5000cca0aa0025f4
MD: naa.5000cca0aa00253c
MD: naa.5000cca0aa0022a8
MD: naa.5000cca0aa002500
DiskMapping[2]:
SSD: naa.5000c5003024eb47
MD: naa.5000cca0aa002698
MD: naa.5000cca0aa0029c4
MD: naa.5000cca0aa002950
MD: naa.5000cca0aa0028cc
DiskMapping[4]:
SSD: naa.5000c5003024eb4f
MD: naa.5000c50030287137
MD: naa.5000c50030287093
MD: naa.5000c50030287027
MD: naa.5000c5003024eb5b
MD: naa.5000c50030287187
Como descobrir UUIDs vUAN para cada naa ....:[root@esxi-dl560-gen10-1:/vmfs/volumes] localcli vsan storage list | grep -B15 'ity Tier: tr' | grep -E '^naa|VSAN UUID'
naa.5000cca0aa002698:
VSAN UUID: 52247b7d-fed5-a2f2-a2e8-5371fa7ef8ed
naa.5000cca0aa0029c4:
VSAN UUID: 52309c55-3ecc-3fe8-f6ec-208701d83813
naa.5000c50030287027:
VSAN UUID: 523d7ea5-a926-3acd-2d58-0c1d5889a401
naa.5000cca0aa0022a8:
VSAN UUID: 524431a2-4291-cb49-7070-8fa1d5fe608d
naa.5000c50030287187:
VSAN UUID: 5255739f-286c-8808-1ab9-812454968734
naa.5000cca0aa0025f4: <<<<<<<
VSAN UUID: 52b1d17e-02cc-164b-17fa-9892df0c1726
naa.5000cca0aa00253c:
VSAN UUID: 52bd28f3-d84e-e1d5-b4dc-54b75456b53f
naa.5000cca0aa002950:
VSAN UUID: 52d6e04f-e1af-cfb2-3230-dd941fd8a032
naa.5000c50030287137:
VSAN UUID: 52df506a-36ea-f113-137d-41866c923901
naa.5000cca0aa002500:
VSAN UUID: 52e2ce99-1836-c825-6600-653e8142e10f
naa.5000cca0aa0028cc:
VSAN UUID: 52e89346-fd30-e96f-3bd6-8dbc9e9b4436
naa.5000c50030287093:
VSAN UUID: 52ecacbe-ef3b-aa6e-eba3-6e713a0eb3b2
naa.5000c5003024eb5b:
VSAN UUID: 52f1eecb-befa-12d6-8457-a031eacc1cab
E a coisa mais importante.O problema acabou sendo a operação incorreta do firmware do controlador RAID e do driver HPE com vSAN.Anteriormente, no VMware 6.7 U1, o firmware compatível para o controlador HPE Smart Array P816i-a SR Gen10 no vSAN HCL era a versão 1.98 (que acabou sendo fatal para a nossa organização) e agora diz 1,65 .Além disso, a versão 1.99, que resolveu o problema na época (31 de janeiro de 2019), já estava nas lixeiras da HPE, mas não a passou para a VMware ou para nós, referindo-se à falta de certificação, apesar de nossas isenções de responsabilidade e tudo o mais. , dizem eles, o principal para nós é resolver o problema do armazenamento e é isso.Como resultado, o problema foi finalmente resolvido somente após três meses, quando a versão de firmware 1.99 para o controlador de disco foi lançada!Que conclusões tirei?- ( ), .
- ! .
- «» , «» «» , 30% «».
- HPE, , .
- , :
- HPE - . , Enterprise . , , ).
- Não previ uma situação em que espaço em disco adicional possa ser necessário para colocar cópias de todos os servidores da empresa em caso de emergência.
- Além disso, à luz do que aconteceu, para a VMware, não comprarei mais hardware para grandes empresas, outros fornecedores que não a DELL. Por que, porque a DELL, até onde eu sei, adquiriu a VMware e agora a integração de hardware e software nessa direção deve estar o mais próxima possível.
Como se costuma dizer, queimado no leite, sopre na água.Isso é tudo pessoal. Desejo que você nunca entre em situações tão terríveis.Pelo que me lembro, já vou me assustar!