L'année 2018 se terminait ...Une fois, par une journée claire de décembre, notre société a décidé d'acheter un nouveau matériel. Non, bien sûr, cela ne s'est pas produit du jour au lendemain. La décision a été prise plus tôt. Beaucoup plus tôt. Mais, comme d'habitude, nos désirs ne coïncident pas toujours avec les capacités des actionnaires. Et il n'y avait pas d'argent, et nous avons tenu bon. Mais finalement, ce moment joyeux est venu lorsque l'acquisition a été approuvée à tous les niveaux. Tout allait bien, les cols blancs applaudissaient joyeusement, ils étaient fatigués de traiter les documents pendant 25 heures par mois sur des serveurs de 7 ans, et ils ont très constamment demandé au service informatique de trouver quelque chose pour leur donner plus de temps pour d'autres choses tout aussi importantes. .Nous avons promis de réduire le temps de traitement des documents de 3 fois, jusqu'à 8 heures. Pour cela, un moineau a été tiré d'un canon. Cette option semblait la seule, car notre équipe n'avait pas, et n'avait jamais eu, d'administrateur de base de données pour appliquer toutes sortes d'optimisation de requêtes (DBA).La configuration de l'équipement sélectionné était, bien entendu, exorbitante. Il s'agissait de trois serveurs de la société HPE - DL560 Gen10. Chacun d'eux comptait 4 processeurs Intel Xeon Platinum 8164 2,0 GHz avec 26 cœurs, 256 DDR4 RAM, ainsi que 8 SSD 800 Go SAS (800 Go WD Ultrastar DC SS530 WUSTR6480ASS204 SSD) + 8 1,92 To SSD (Western Digital Ultrastar DC SS530 )Ces «morceaux de fer» étaient destinés au cluster VMware (HA + DRS + vSAN). Qui travaille avec nous depuis près de 3 ans sur des serveurs similaires des 7e et 8e générations, également de HPE. À propos, il n'y a eu aucun problème jusqu'à ce que HPE refuse de les prendre en charge et de mettre à niveau ESXi de la version 6.0, même vers 6.5, sans tambourin. Eh bien, d'accord, il a été possible de mettre à jour. En modifiant l'image d'installation, en supprimant les modules incompatibles de l'image d'installation, etc. Cela a également alimenté le feu de notre désir de faire correspondre tout ce qui est nouveau. Bien sûr, sans les nouveaux "trucs" vSAN, dans le cercueil, nous avons vu une mise à jour de l'ensemble du système de la version 6.0 à une version plus récente, et il ne serait pas nécessaire d'écrire un article, mais nous ne cherchons pas de moyens faciles ...Nous avons donc acheté cet équipement et décidé de remplacer celui obsolète depuis longtemps. Nous avons appliqué le dernier SPP à chaque nouveau serveur, installé dans chacune d'elles deux cartes réseau Ethernet 10G (une pour les réseaux d'utilisateurs et la seconde pour le SAN, 656596-B21 HP Ethernet 10Gb 2 ports 530T). Oui, chaque nouveau serveur était livré avec une carte réseau SFP + sans modules, mais notre infrastructure réseau impliquait Ethernet (deux piles de commutateurs DELL 4032N pour les réseaux LAN et SAN), et le distributeur HP à Moscou ne disposait pas de modules HPE 813874-B21 et nous ils n'ont pas attendu.Quand est venu le temps d'installer ESXi et d'incorporer de nouveaux nœuds dans un centre de données VMware commun, un «miracle» s'est produit. Il s'est avéré que HPE ESXi Custom ISO version 6.5 et inférieure n'est pas conçu pour être installé sur les nouveaux serveurs Gen10. Hardcore uniquement, seulement 6,7. Et nous avons dû involontairement suivre les préceptes de la «société virtuelle».Un nouveau cluster HA + DRS a été créé, un cluster vSAN a été créé, le tout en stricte conformité avec VMware HCL et ce document . Tout a été configuré selon le Feng Shui et seules les «alarmes» périodiques étaient suspectes dans la surveillance de vSAN sur les valeurs des paramètres non nuls dans cette section:
Nous avons, en toute sérénité, déplacé toutes les machines virtuelles (environ 50 pièces) vers de nouveaux serveurs et vers un nouveau stockage vSAN construit sur des disques SSD, nous avons vérifié les performances du traitement des documents dans le nouvel environnement (au fait, il s'est avéré gagner beaucoup plus de temps que prévu) . Jusqu'à ce que la base la plus lourde soit transférée au nouveau cluster, l'opération, qui était mentionnée au début de l'article, a pris environ 4 heures au lieu de 25! Ce fut une contribution significative à l'ambiance du Nouvel An de tous les participants au processus. Certains ont probablement commencé à rêver d'un prix. Ensuite, tout le monde est parti joyeusement pour les vacances du Nouvel An.Lorsque les jours de semaine de la nouvelle année 2019 ont commencé, rien n'annonçait une catastrophe. Tous les services, transférés à de nouvelles capacités, sans exagération, ont décollé! Seuls les événements de la section de resynchronisation des objets sont devenus beaucoup plus. Et après quelques semaines, des problèmes se sont produits. Tôt le matin, presque tous les services clés de la société (1s, MSSQL, SMB, Exchange, etc.) ont cessé de répondre ou ont commencé à répondre avec un long retard. L'infrastructure entière a plongé dans un chaos complet, et personne ne savait ce qui s'était passé et quoi faire. Toutes les machines virtuelles dans vCenter semblaient «vertes», il n'y avait aucune erreur dans leur surveillance. Le redémarrage n'a pas aidé. De plus, après un redémarrage, certaines machines ne pouvaient même pas démarrer, affichant diverses erreurs de processus dans la console. L'enfer semblait venir à nous et le diable se frottait les mains d'anticipation.Sous la pression d'un stress important, il a été possible de déterminer la source de la catastrophe. Ce problème s'est avéré être un stockage distribué vSAN. Une corruption de données non contrôlée sur les disques de machines virtuelles s'est produite, à première vue - sans raison. À cette époque, la seule solution qui semblait rationnelle était de contacter le support technique de VMware avec des cris: SOS, save-help!Et cette décision, par la suite, a sauvé la société de la perte de données pertinentes, y compris les boîtes aux lettres des employés, les bases de données et les fichiers partagés. Ensemble, nous parlons de plus de 30 téraoctets d'informations.Il est tenu de rendre hommage au personnel de support de VMware qui n'a pas «joué au football» avec le titulaire de l'abonnement de support technique de base, mais a inclus ce cas dans le segment Enterpise, et le processus a tourné 24h / 24.Que s'est-il passé ensuite:- Le support technique de VMware a posé deux questions principales: comment récupérer des données et comment résoudre le problème de corruption de données «fantôme» dans les disques de machines virtuelles du cluster de combat «vSAN». Soit dit en passant, les données n'étaient nulle part récupérables, car le stockage supplémentaire était occupé par des copies de sauvegarde et il n'y avait tout simplement nulle part où déployer des services de «combat».
- Alors que j'essayais, conjointement avec VMware, de rassembler les objets «endommagés» dans le cluster vSAN, mes collègues ont extrait de toute urgence un nouveau stockage qui pourrait accueillir les 30+ téraoctets de données de la société.
- , , VMware , , «» - - . , ?
- .
- , « » .
- , , «» .
- J'ai dû temporairement (pendant quelques jours) sacrifier l'efficacité du courrier, au profit de 6 téraoctets supplémentaires d'espace libre dans le magasin, pour lancer les services clés dont dépendaient les revenus de la société.
- Des milliers de lignes de discussion avec des collègues anglophones de VMware ont été enregistrées «pour mémoire», voici un court extrait de nos conversations:
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
Comment ce problème s'est manifesté (en plus des services d'organisation fermement ancrés).Croissance exponentielle des erreurs de somme de contrôle (CRC) «à l'improviste» lors de l'échange de données avec des disques en mode HBA. Comment vérifier cela - entrez la commande suivante dans la console de chaque nœud 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
À la suite de l'exécution, vous pouvez voir des erreurs CRC pour chaque disque dans le cluster vSAN de ce nœud (les valeurs nulles ne seront pas affichées). Si vous avez des valeurs positives, et en plus, elles augmentent constamment, alors il y a une raison pour que des tâches surgissent constamment dans la section Monitor -> vSAN -> Resincing objects du cluster.Comment récupérer des disques de machines virtuelles qui ne clonent pas ou ne migrent pas par des moyens standard?Qui aurait pensé utiliser la puissante commande 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]
Comment reconnaître les disques naa.xxxx ... dans les groupes de disques:[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
Comment trouver les UUID vUAN pour chaque 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
Et la chose la plus importante.Le problème s'est avéré être le mauvais fonctionnement du micrologiciel du contrôleur RAID et du pilote HPE avec vSAN.Auparavant, dans VMware 6.7 U1, le micrologiciel compatible pour le contrôleur HPE Smart Array P816i-a SR Gen10 dans vSAN HCL était la version 1.98 (qui s'est avérée fatale pour notre organisation), et maintenant il dit 1.65 .De plus, la version 1.99, qui a résolu le problème à ce moment-là (31 janvier 2019), était déjà dans les bacs HPE, mais ils ne l'ont transmise ni à VMware ni à nous, invoquant le manque de certification, malgré nos dénis de responsabilité et tout cela. , disent-ils, l'essentiel pour nous est de résoudre le problème du stockage et c'est tout.En conséquence, le problème n'a finalement été résolu qu'après trois mois, lorsque la version 1.99 du micrologiciel pour le contrôleur de disque a été publiée!Quelles conclusions ai-je tirées?- ( ), .
- ! .
- «» , «» «» , 30% «».
- HPE, , .
- , :
- HPE - . , Enterprise . , , ).
- Je ne prévoyais pas une situation où de l'espace disque supplémentaire pourrait être nécessaire pour placer des copies de tous les serveurs de la Société en cas d'urgence.
- De plus, à la lumière de ce qui s'est passé, pour VMware, je n'achèterai plus de matériel pour les grandes entreprises, les fournisseurs autres que DELL. Pourquoi, parce que DELL, pour autant que je sache, a acquis VMware, et maintenant l'intégration du matériel et des logiciels dans cette direction devrait être aussi proche que possible.
Comme on dit, brûlé dans du lait, soufflez dans l'eau.C'est tout les gars. Je vous souhaite de ne jamais vous retrouver dans des situations aussi terribles.Si je me souviens bien, je vais déjà surprendre!