ESX / ESXi - Hilfethread

Servus,

Was müsste ich denn alles installieren wenn ich zwei Server habe und einen HA-Cluster errichten will? Wie Ausfallsicher ist denn sowas überhaupt? Hab schon recherchiert bin jedoch nicht grad kluger davon geworden. :)

Vielen Dank schonmal für eure Hilfe!
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
das kommt auf die Lizenz an.
Am Ausfallsichersten im Sinne von Verfügbarkeit wäre wohl Fault-Tolerance.

Wir betreiben hier einen HA-Cluster mit ner Essentials-Plus Lizenz, dediziertem Storage und wenn der eine Host - warum auch immer down is - übernimmt der andere - einzigre Nachteil, die VMs starten quasi neu, wie nach Stecker ziehen - Downtime ~ 3-10 Minuten bei knapp 40VMs auf aktueller HP-G10 Hardware.

Hatten leider erste letzte Woche nen Host mit Purple-Screen of Death :( - ging aber - die Anwender haben außer beim ERP nichts davon mitbekommen.
 
konfetti schrieb:
das kommt auf die Lizenz an.
Am Ausfallsichersten im Sinne von Verfügbarkeit wäre wohl Fault-Tolerance.

Wir betreiben hier einen HA-Cluster mit ner Essentials-Plus Lizenz, dediziertem Storage und wenn der eine Host - warum auch immer down is - übernimmt der andere - einzigre Nachteil, die VMs starten quasi neu, wie nach Stecker ziehen - Downtime ~ 3-10 Minuten bei knapp 40VMs auf aktueller HP-G10 Hardware.

Hatten leider erste letzte Woche nen Host mit Purple-Screen of Death :( - ging aber - die Anwender haben außer beim ERP nichts davon mitbekommen.
Zum Vergrößern anklicken....

Danke schonmal für die Info, würde erstmal alles auf Evaluation laufen lassen. Welche Version verwendest du denn? Hätten vor einen 6.7 zu konfigurieren. Dazu hatte ich vor auf beiden erstmal ESX zu installieren, die vCenter Server Appliance und dann einen HA-Cluster zu erstellen. Wäre das soweit richtig?
 
Hi, jup - aber wir setzen atm noch 6.5 ein, weil unser Storage nicht für 6.7 Freigegeben ist - an sich ja Schwachsinn, aber bevor in der Umgebung etwas unsupportet läuft ;)
 
Ein NAS reicht, ja.
Du kannst auch mit lokalem Datenspeicher VMs migrieren, allerdings nur manuell. Nennt sich "shared-nothing vMotion". High Availability, Fault Tolerance und Distributed Resource Scheduler brauchen shared Storage.
 
Oh, stimmt. Allerdings setzt Fault Tolerance HA voraus, und HA wiederum braucht shared Storage. Bin mir nicht sicher, das kann bestimmt jemand anderes beantworten.
 
Zentaria schrieb:
Ein NAS würde reichen oder? Kann man ab 6.7 nicht die Interne Storage auch "sharen"?
Zum Vergrößern anklicken....

Der Zugriff auf den lokalen ESXi Storage geht per sftp z.B. WinSCP, ist aber sehr langsam.
Richtig gut wird es mit einer ZFS Storage VM (FreeNAS/XigmaNAS oder Solarish mit meinem napp-it).
Da nutzt man NFS oder SMB für den Zugriff und Copy/Clone/Backup inkl ZFS Snaps/Versionierung und Replikation.

https://napp-it.org/doc/downloads/napp-in-one.pdf


So ein All-In-One (ESXI + Storage VM) kann man auch zu einem virtuellen HA Cluster erweitern
http://www.napp-it.org/doc/downloads/z-raid.pdf
 
Wie erstellt man denn einen HA in 5.5? Brauche ich noch was dazu?

PS: Finde kein Vcenter zum downloaden, hat hier wer vielleicht noch die iso bzw vmdk oder so?
 
Zuletzt bearbeitet:
Die kleinste Lizenz kaufen dann gibt es auch den Vcenter.

Gesendet von meinem SM-N960F mit Tapatalk
 
das vCenter gibts zum testen auch 60 Tage ohne Kauflizenz, müsste doch bei den Downloads im Portal drin sein.
Zumindest haben wir das für die LAN so gemacht - da reichen bei der Appliance die 60Tage ja in der Regel locker aus ;)
 
Das sieht echt mal gut aus. Ich hatte eine Lizenz für 1jahr gekauft, das waren ähnliche Kosten.

Edit: Und hat sich direkt erledigt
for personal use in a non-production environment and includes the products listed to the right:
Zum Vergrößern anklicken....
 
Zuletzt bearbeitet:
-INU- schrieb:
Aber nur diese Krüppelversion ohne HA etc. Finde das auch recht mies, sobald man mehr als zwei Systeme hat gibts bei HyperV ein deutlich besseres Featureset zum Nulltarif.
Zum Vergrößern anklicken....

Das wage ich zu bezweifeln - wir haben das mit nem M$ Licensing Heinz mal durchgerechnet - das is gegen VMware erst im 4. Jahr Preisgleich und nach 6 Jahren günstiger - wenn man das gleiche Featureset haben will!
 
Was genau habt Ihr da verglichen? Standardfeatures wie HA sind abgsehen von VMware bei den gängigen Lösungen schon in der "freien" Version enthalten.
 
Kleine Randnotiz/Info: Mir ist grad mein 6.7 U1 (bei CPU-Auslastung am Anschlag) abgenippelt und hat dann beim Booten nur noch PSODs geworfen. Und zwar Exceptions am Intel NVME-Treiber.
ESXI 6.7 U1 zusammen mit einer Optane scheint immer noch eine starke Abhängigkeit zwischen Firmware und VIB-Version zu haben => prüft also bei einer Optane 900p/905p die Firmware-Version.

Die Kompatibilitätsinfo Firmware<>VIB auf Vmware-Seite findet ihr unter der der Optane P4800X (nicht der 900/905P; die hat aber zumindest bei mir gleiche Firmware-Versionsnummern ;-) )

Dank AIO-ZFS-Konzept nix passiert, ESXI neu installiert, VMs eingehängt und ratzfatz bin ich wieder im Geschäft. :cool:

PS: So sieht übrigens die 900p-Leistung als vdisk auf VMFS6 (also nicht via NFS) in einer Win8-VM bei mir aus:
cdm_900p_vmfs6.png
 
Zuletzt bearbeitet:
Trambahner schrieb:
ESXI 6.7 U1 zusammen mit einer Optane scheint immer noch eine starke Abhängigkeit zwischen Firmware und VIB-Version zu haben => prüft also bei einer Optane 900p/905p die Firmware-Version.
Zum Vergrößern anklicken....

Was genau bedeutet das? Welche FW Version benötige ich? Und wie kann ich die überhaupt auslesen? Habe gerade eben nämlich meine Optane 900p eingebaut und alles hat mal auf Anhieb funktioniert. :)

Trambahner schrieb:
PS: So sieht übrigens die 900p-Leistung als vdisk auf VMFS6 (also nicht via NFS) in einer Win8-VM bei mir aus:
Anhang anzeigen 453816
Zum Vergrößern anklicken....

Das hier war mein erster Leistungstest:

Code: 
root@napp-it:/# dd of=/testfile.dd if=/dev/zero bs=1M count=10000
10000+0 records in
10000+0 records out
10485760000 bytes transferred in 3,357796 secs (3122810150 bytes/sec)

Das kommt mir etwas zu hoch vor. Wären ja 2,9 GB/s. Läuft ja auch direkt auf die napp-it vdisk. Da ist bestimmt noch irgendein Cache dazwischen, oder?
 
Das geht auf der ESXI-Shell, also z.B. via SSH/Putty, per esxcli-Kommando.

Code: 
esxcli nvme device get -A vmhba2

Statt vmhba2 kann es auch ein anderes Gerät sein; welches sieht man im Speicher-Gerätemanager in der GUI z.B..

Firmware Revision: E2010325 => VMW-ESX-6.7.0-intel-nvme-vmd-1.4.0.1016-offline_bundle-8733247.zip lt. Vmware.
E2010423 => Version 1.6.0.irgendwas.

siehe da bei Vmware und auch ggf. lesenswert bei Paul Braren

Edit: grad wieder per Psod abgesoffen. :mad: Aber diesmal hat Keule nach nem reboot wieder getan. Also richtig happy bin ich derzeit nich. 6.5.0U2 war deutlich stabiler bei mir; der is nie eingegangen.

Edit2: Läuft zwar jetzt ne Stunde, aber im vmkernel.log stehen sich kurz vor dem 2. Crash doch haufenweise Fehler mit dem o.g. 1.4.0 :
Code: 
2018-12-26T17:39:44.964Z cpu2:2097586)ScsiDeviceIO: 3082: Cmd(0x459a40d34c00) 0x93, CmdSN 0x27c4 from world 2097304 to dev "t10.NVMe____INTEL_SSDPE21D280GA_____________________xxxxxxxxxxxxxxxxx__00000001" failed H:0x0 D:0x2 P:0x0 Valid sense data:
Für mich sieht das nach Kommunikationsfehlern des Treibers mit der SSD oder aus, wenn ESXI auf die Optane zugreifen will. Mit 6.5.0U2 hatte ich das nicht. Also passt wohl mit dem Treiber was nicht.
Läuft grad ein Job, aber ich muss danach mal schaun mit anderen Treiberversionen.

Edit3: Und Crash. :hwluxx: So langsam werd ich hantig.
 
Zuletzt bearbeitet:
Meiner läuft jetzt gerade seit 3,5h.Bislang ohne Probleme. Wo liegt denn das Logfile? Würde dann gleich auch mal reinschauen, ob ich da was sehe.
 
/var/log/vmkernel.log

Ich hab jetzt mal das Intel-VIB entfernt und bin zurück auf den Basistreiber, der standardmässig installiert wird und teste damit mal.
Ich könnte mir vorstellen, dass es ein Timing-Issue ist, da ich es bislang nur unter Last gesehen hab; k.a. obs Idle auch passiert. Mal sehn mit dem Vmware-Treiber.

Hab sicherheitshalber mal die L2Arc und Slog von der Optane abgeklemmt, solang das nicht wieder stabil läuft riskier ich nix.

Die 900p würd ich ja zu gern durchreichen, aber dat klappt ja nicht immer. Und dann müsst ich die 2. NVME-SSD hernehmen, wo ich viel temporäres Zeug drauf hab und "umrangieren". Meh.


Edit 21:20 Uhr: Etwa 2hr lang ist nun nix mehr passiert; mit dem Treiber der im ISO out-of-the-box dabei ist.
 
Zuletzt bearbeitet:
Resignature > Ihre Suchanfrage erzielte keine Treffer.

Falls euch das Thema auch mal trifft und da ich dazu einige Threads im Netz gefunden habe, wo am Ende aufgegeben wurde:

Symptom: Nach Controller-Wechsel lässt sich der Datastore nicht mehr mounten. Er ist aber noch vorhanden.

Ursache:
When you attempt to mount a device that contains a VMFS datastore copy/storage snapshot, you are given the option to either mount the datastore using the existing signature or you can assign the datastore a new signature.

ESX detects a lun as being a snapshot/copy by comparing the SCSI_DiskID information returned from the storage array, with the SCSI_DiskID information stored in the LVM header. If the two values do not match, the volume is deemed to be a snapshot/copy and is not mounted.
Zum Vergrößern anklicken....

Kurzfassung:

  • Im /var/logs/vmkernel.log findet sich "Device <devicename (partition)> detected to be a snapshot"
  • "esxcli storage vmfs snapshot list" listet dann tatsächlich mindestens einen Snapshot auf.
  • Mit "voma -m vmfs -f check -d /vmfs/devices/disks/<devicename (partition)>" kann man herausfinden, welcher Snapshot (volume-uuid) sich auf dem <devicename (partition)> befindet.
  • Mounten wird in der Regel nicht funktionieren, kann man aber ausprobieren: esxcli storage filesystem mount --volume-label=<label>|--volume-uuid=<VMFS-UUID>
  • Wenn man sich sicher ist, dass der Snapshot unbeabsichtigt erzeugt wurde (eben z.B. durch den Controllerwechsel), dann kann man eine neue Signatur vergeben:
    esxcli storage vmfs snapshot resignature --volume-uuid=<snapshot uuid>
Das hat dann noch kleinere Nebenwirkungen, da die Volume-Signatur auch in den .vmx Dateien Verwendung findet. Das muss man dann manuell per Texteditor in den .vmx, .vmdk, .vmsd, and .vmsn. Dateien beheben.

Weitere Infos:
VMFS Resignaturing
VMware® VMFS Volume Management
VMFS Re-Signaturing Virtual Reality
EnableResignature and/or DisallowSnapshotLUN - Yellow Bricks
vSphere handling of LUNs detected as snapshot LUNs (1011387)
ESXi datastore missing after swapping RAID cont... |VMware Communities

Es gibt wohl eine alternative, bessere Methode namens NAA (National Address Authority disk identification), die in bestimmten Fällen sinnvoll ist. Weiß dazu vielleicht jemand näheres? Eigentlich heißen die Devices ja naa.... Komisch.

Update:
Wieder Array umgesteckt von einem Controller auf den anderen und wieder das gleiche Phänomen. Auch mit neuen Datastores.

Damit man die VMs wieder einbinden kann, muss man die ungültigen VMs deregistrieren:
vim-cmd /vmsvc/getallvms
vim-cmd /vmsvc/unregister <Vmid>
 
Zuletzt bearbeitet:
Wer sich erinnern kann Ich möchte immer noch einen 2te Server/ Pc zusammen stellen der als Virtueller Desktop arbeitet.
Logischerweise wird dort auch ein Virtuelles NAS oder wie Ihr das auch immer nenne wollt rennen das sich mit den "guten alten" HP Server Synct wo die 2te Virtuelle NAS rennt. Ich hoffe mal da gibts schon was für den kleinen Geldbäutel.
Abgesehen davon müssen die Daten von A nach B und wieder retour. Nicht nur die Daten aus den "Hot Sync" sondern auch andere Daten müssen von ESXi A nach ESXi B. Es geht hier NICHT um das Verschieben von Maschienen oder so sondern nur Daten die bei den selbigen erzeugt werden.
Kann Ich hierfür 2x 10GB/s Karte einsetzen welche direkt verbunden sind so wie man es in der Antike der Pcs mit einen Laptop gerne gemacht hatte?
Beide bekommen "irgend eine IP" und schon rennen die Daten drüber.
Jetzt habe Ich bei Delock geschaut (auf die schnelle) und eine Karte gefunden mit nen Intel Chipsatz: Delock Produkte 89521 Delock PCI Express Karte 1 x 10 Gigabit LAN RJ45
zumindest bei VMware ist der Chipsatz drinnen: VMware Compatibility Guide - I/O Device Search
 
Delock mit Intel X550? Seit wann gibts denn dieeee Dinger? Aber "kleines Geld" sind die nicht. Aber vielleicht ne Alternative zu den günstigen X540 vom China-Mann.
Die Frage ist, ob ESXI die Karten wirklich sauber erkennt, denn ich würde erwarten dass die Teile andere PCI-ID-Nummern als die Intels haben. K.a. wie empfindlich ESXI da ist oder ob es den Chipsatz trotzdem erkennt.

Generell machst Du mit Intel X540/X550 nichts falsch. Erwarte aber keine Wunder bei der Leistungsaufnahme. Eine Solo zieht etwa 7-8W, eine Dual 12-13W.

Wenn Du nur 2 Maschinen die nahe beieinander sind direkt miteinander verbinden willst, kannst Du günstiger Glas mit SFP+ (10G) oder ggf. auch welche mit 40G nutzen und DAC-Kabel nutzen.

PS: Meine ganzen Maschinen, ausser Notebook natürlich, im LAN sind mit X540+X550 ausgerüstet. Originale aber. :coffee:

Daten schubsen zwischen Storages geht bei mir mit "zfs send/recv". :d Bei physikalischen Win-Clients mit FreeFileSync in Bezahlversion (kann parallelisierte Transfers; genial wenn man viele kleine Files hat).
 
Zuletzt bearbeitet:
Von den Delock dingern würde ich absehen die rennen nicht sauber unter Esxi. Ich habe sehr gute Erfahrungen mit den meli x2-x4 und den HP NC 550 SFP gemacht laufen unter Esxi 6.7 out of the box. Hier dann jenachdem was gebraucht wird DAC Kabel oder SR-Reciever. Zu dem Storage kann ich dir die HPE Store Virtual VSA Lösung empfehlen. kostenfrei bis 1TB alles andere dann jenach Größe buchbar. Zwei VMs auf dem jeweiligen host und eine Beobachtungs/Management VM auf einem 3. Host kann auch irgendeine klapperkiste sein. Ansonsten omni-os + nappit mit zfs send/rec
 
Ah, also fast wie befürchtet. Der Chipsatz alleine hilft nix, wenn die Karten sich anders als die original Intel bei Hw und Sw melden.
 
Anmelden, um zu antworten.
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh