Get best of the week

VMware vSAN 6.7 - Und der Donner schlug ein

Das Jahr 2018 ging zu Ende ...

Einmal, an einem klaren Dezembertag, entschied sich unser Unternehmen, eine neue Hardware zu kaufen. Nein, das passierte natürlich nicht über Nacht. Die Entscheidung wurde früher getroffen. Viel früher. Aber wie immer stimmen unsere Wünsche nicht immer mit den Fähigkeiten der Aktionäre überein. Und es gab kein Geld, und wir hielten fest. Aber schließlich kam dieser freudige Moment, als die Übernahme auf allen Ebenen genehmigt wurde. Alles war in Ordnung, die Angestellten applaudierten freudig, sie hatten es satt, 25 Stunden monatlich Dokumente auf 7 Jahre alten Servern zu verarbeiten, und sie baten die IT-Abteilung sehr beharrlich, sich etwas auszudenken, um ihnen mehr Zeit für andere, ebenso wichtige Dinge zu geben .

Wir haben versprochen, die Bearbeitungszeit für Dokumente um das Dreifache auf 8 Stunden zu verkürzen. Dafür wurde ein Spatz aus einer Kanone abgefeuert. Diese Option schien die einzige zu sein, da unser Team keinen Datenbankadministrator hatte und nie hatte, der alle Arten der Abfrageoptimierung (DBA) anwendete.

Die Konfiguration der ausgewählten Ausrüstung war natürlich himmelhoch. Dies waren drei Server der Firma HPE - DL560 Gen10. Jeder von ihnen verfügte über 4 Intel Xeon Platinum 8164 2,0-GHz-Prozessoren mit 26 Kernen, 256 DDR4-RAM sowie 8 SSD 800 Gb SAS (800 Gb WD Ultrastar DC SS530 WUSTR6480ASS204 SSD) + 8 1,92 TB SSD (Western Digital Ultrastar DC SS530) )

Diese "Eisenstücke" waren für den VMware-Cluster (HA + DRS + vSAN) bestimmt. Das arbeitet seit fast 3 Jahren mit uns auf ähnlichen Servern der 7. und 8. Generation, ebenfalls von HPE. Übrigens gab es keine Probleme, bis HPE sich weigerte, sie zu unterstützen und ESXi ohne Tamburin von Version 6.0 auf 6.5 zu aktualisieren. Okay, als Ergebnis war es möglich zu aktualisieren. Durch Ändern des Installationsabbilds, Entfernen inkompatibler Problemmodule aus dem Installationsabbild usw. Dies fügte auch dem Feuer unseres Wunsches hinzu, alles Neue zusammenzubringen. Wenn es nicht die neuen vSAN-Chips gäbe, hätten wir im Sarg ein Update des gesamten Systems von Version 6.0 auf eine neuere Version gesehen, und es wäre nicht nötig, einen Artikel zu schreiben, aber wir suchen nicht nach einfachen Wegen ...

Also kauften wir diese Ausrüstung und beschlossen, die längst veraltete zu ersetzen. Wir haben den letzten SPP auf jeden neuen Server angewendet , auf dem jeweils zwei Ethernet 10G-Netzwerkkarten installiert sind (eine für Benutzernetzwerke und die zweite für SAN, 656596-B21 HP Ethernet 10Gb 2-Port 530T). Ja, jeder neue Server wurde mit einer SFP + -Netzwerkkarte ohne Module geliefert, aber unsere Netzwerkinfrastruktur implizierte Ethernet (zwei Stapel von DELL 4032N-Switches für LAN- und SAN-Netzwerke), und der HP Distributor in Moskau verfügte nicht über HPE 813874-B21-Module und wir Sie haben nicht gewartet.

Als es an der Zeit war, ESXi zu installieren und neue Knoten in ein gemeinsames VMware-Rechenzentrum zu integrieren, geschah ein „Wunder“. Wie sich herausstellte, ist HPE ESXi Custom ISO Version 6.5 und niedriger nicht für die Installation auf neuen Gen10-Servern ausgelegt. Nur Hardcore, nur 6.7. Und wir mussten unabsichtlich den Vorschriften des „virtuellen Unternehmens“ folgen.

Es wurde ein neuer HA + DRS-Cluster erstellt, ein vSAN-Cluster wurde erstellt, und dies alles unter strikter Einhaltung von VMware HCL und diesem Dokument . Alles wurde gemäß Feng Shui konfiguriert und nur periodische „Alarme“ waren bei der Überwachung von vSAN auf Parameterwerte ungleich Null in diesem Abschnitt verdächtig:

Bild

Wir haben beruhigt alle virtuellen Maschinen (ca. 50 Teile) auf neue Server verschoben und auf den neuen vSAN-Speicher, der bereits auf SSD-Festplatten aufgebaut war, die Leistung der Dokumentenverarbeitung in der neuen Umgebung überprüft (übrigens hat sich herausgestellt, dass dies viel mehr Zeit spart als geplant). . Bis die schwerste Basis in den neuen Cluster übertragen wurde, dauerte die am Anfang des Artikels erwähnte Operation etwa 4 statt 25 Stunden! Dies war ein wesentlicher Beitrag zur Neujahrsstimmung aller Teilnehmer des Prozesses. Einige träumten wahrscheinlich von einem Preis. Dann gingen alle glücklich in die Neujahrsferien.

Als die Wochentage des neuen Jahres 2019 begannen, deutete nichts auf eine Katastrophe hin. Alle Dienste, die ohne Übertreibung auf neue Kapazitäten übertragen wurden, starteten! Nur Ereignisse im Bereich der Neusynchronisierung von Objekten wurden viel mehr. Und nach ein paar Wochen gab es Ärger. Am frühen Morgen reagierten fast alle wichtigen Dienste des Unternehmens (1s, MSSQL, SMB, Exchange usw.) nicht mehr oder mit einer langen Verzögerung. Die gesamte Infrastruktur stürzte in völliges Chaos, und niemand wusste, was passiert war und was zu tun war. Alle virtuellen Maschinen in vCenter sahen "grün" aus, es gab keine Fehler bei ihrer Überwachung. Ein Neustart hat nicht geholfen. Darüber hinaus konnten einige Computer nach einem Neustart nicht einmal starten und zeigten verschiedene Prozessfehler in der Konsole an. Die Hölle schien zu uns zu kommen und der Teufel rieb sich erwartungsvoll die Hände.

Unter dem Druck ernsthaften Stresses konnte die Ursache der Katastrophe ermittelt werden. Dieses Problem stellte sich als verteilter vSAN-Speicher heraus. Auf den ersten Blick kam es zu einer unkontrollierten Datenbeschädigung auf Festplatten virtueller Maschinen - ohne Grund. Zu dieser Zeit schien die einzige Lösung, die vernünftig erschien, den technischen Support von VMware mit Schreien zu kontaktieren: SOS, Save-Help!

Diese Entscheidung rettete das Unternehmen anschließend vor dem Verlust relevanter Daten, einschließlich Mitarbeiterpostfächer, Datenbanken und freigegebener Dateien. Zusammen sprechen wir über 30 Terabyte an Informationen.

Er ist verpflichtet, den Mitarbeitern des VMware-Supports Tribut zu zollen, die nicht mit dem Inhaber des Abonnements für technischen Basis-Support „Fußball gespielt“ haben, sondern diesen Fall in das Enterpise-Segment aufgenommen haben und den Prozess rund um die Uhr durchlaufen haben.

Was danach geschah:

  1. Der technische Support von VMware stellte zwei Hauptfragen: Wie können Daten wiederhergestellt und das Problem der Beschädigung von Phantomdaten auf Festplatten virtueller Maschinen im Kampfcluster "vSAN" gelöst werden? Übrigens waren die Daten nirgends wiederherzustellen, da der zusätzliche Speicher von Sicherungskopien belegt war und es einfach keinen Ort gab, an dem "Kampf" -Dienste bereitgestellt werden konnten.
  2. Während ich gemeinsam mit VMware versuchte, die „beschädigten“ Objekte im vSAN-Cluster zusammenzustellen, haben meine Kollegen dringend einen neuen Speicher abgebaut, der alle über 30 Terabyte Unternehmensdaten aufnehmen kann.
  3. , , VMware , , «» - - . , ?
  4. .
  5. , « » .
  6. , , «» .
  7. Ich musste vorübergehend (für ein paar Tage) die Effizienz der Post opfern, um zusätzliche 6 Terabyte freien Speicherplatz im Geschäft zu erhalten, um die Schlüsseldienste zu starten, von denen die Einnahmen des Unternehmens abhingen.
  8. Tausende von Chatlines mit englischsprachigen Kollegen von VMware wurden "für den Speicher" gespeichert. Hier ein kurzer Auszug aus unseren Gesprächen:

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

Wie sich dieses Problem manifestierte (zusätzlich zu den fest gesunkenen Organisationsdiensten).

Exponentielles Wachstum von Prüfsummenfehlern (CRC) aus heiterem Himmel während des Datenaustauschs mit Festplatten im HBA-Modus. So überprüfen Sie dies: Geben Sie den folgenden Befehl in die Konsole jedes ESXi-Knotens ein:

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

Als Ergebnis der Ausführung werden CRC-Fehler für jede Festplatte im vSAN-Cluster dieses Knotens angezeigt (Nullwerte werden nicht angezeigt). Wenn Sie positive Werte haben und diese darüber hinaus ständig wachsen, gibt es einen Grund für ständig auftretende Aufgaben im Abschnitt Monitor -> vSAN -> Resincing-Objekte des Clusters.

Wie kann ich Festplatten von virtuellen Maschinen wiederherstellen, die nicht mit Standardmitteln klonen oder migrieren?

Wer hätte gedacht, mit dem mächtigen Befehl 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]

So erkennen Sie naa.xxxx ... Datenträger in Datenträgergruppen:

[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

So finden Sie vUAN-UUIDs für jede Naa heraus ....:

[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

Und das Wichtigste.

Das Problem stellte sich als fehlerhafter Betrieb der Firmware des RAID-Controllers und des HPE-Treibers mit vSAN heraus.
Zuvor war in VMware 6.7 U1 die kompatible Firmware für den HPE Smart Array P816i-a SR Gen10-Controller in vSAN HCL Version 1.98 (was sich für unser Unternehmen als schwerwiegend herausstellte). Jetzt heißt es 1,65 .
Darüber hinaus befand sich die Version 1.99, mit der das Problem zu diesem Zeitpunkt (31. Januar 2019) gelöst wurde, bereits in den HPE-Behältern, wurde jedoch weder an VMware noch an uns weitergegeben, was auf die fehlende Zertifizierung trotz unserer Haftungsausschlüsse und all dessen hinweist Sie sagen, die Hauptsache für uns ist, das Problem mit dem Speicher zu lösen und das war's.

Infolgedessen wurde das Problem erst nach drei Monaten behoben, als die Firmware-Version 1.99 für den Festplattencontroller veröffentlicht wurde!

Welche Schlussfolgerungen habe ich gezogen?

  1. ( ), .
  2. ! .
  3. «» , «» «» , 30% «».
  4. HPE, , .
  5. , :

    • HPE - . , Enterprise . , , ).
    • Ich habe keine Situation vorausgesehen, in der zusätzlicher Speicherplatz erforderlich sein könnte, um im Notfall Kopien aller Server des Unternehmens zu platzieren.
  6. Angesichts der Ereignisse werde ich für VMware keine Hardware mehr für große Unternehmen und andere Anbieter als DELL kaufen. Warum, weil DELL, soweit ich weiß, VMware erworben hat und nun die Integration von Hardware und Software in diese Richtung so nah wie möglich sein dürfte.

Wie sie sagen, in Milch verbrannt, ins Wasser blasen.

Das sind alle Leute. Ich wünschte, Sie würden niemals in solch schreckliche Situationen geraten.

Soweit ich mich erinnere, werde ich schon erschrecken!

Source: https://habr.com/ru/post/undefined/

More articles:


All Articles