Update von 4.x auf 5.x fehlgeschlagen

[mister-man]

Hay,

habe gerade angefangen meine ESXi Hosts auf die aktuelleste Version zu bringen.
Beim ersten hat es wunderbar geklappt, doch der zweite Zickt nun rum.

Anscheinend wurde die gesamte Einstellung überschrieben, das Managementinterface hat sich geändert, die IP und das root Passwort.

Allerdings bin ich nun ratlos, wie ich mich einloggen soll ohne Passwort um das Problem zu beheben.

Danke im voraus.

MfG
Peter

[mister-man]

Habe gerade einfach neu installiert, mit der Option Datastore erhalten.
Hat alles geklappt, binde gerade wieder alles im vCenter an.

Doch eine Frage am Rande. Der Host der mit Datastore erhalten installiert wurde wirkt viel schneller bei gleicher Hardware. Alles läuft Flüssiger. War es ein Fehler auf Update statt auf Neuinstallation zu setzen?!

Gruß
Peter

[Dayworker]

DS-technisch machen Upgrade oder Neuinstallation schon einen Unterschied, da mit VMFS5 einige Beschränkungen weggefallen sind. Wenn du jedoch den DS erhalten hast, gelten für diesen auch weiterhin die mit dem VMFS3 eingeführten Begrenzungen hinsichtlich DS- und Blocksize-Grösse.
Wie äussert sich die flüssigere Funktion?

[blue_focus]

Also grundsätzlich bin ich ja grundsätzlich gegen Major-Release Migrationen ohne Neuinstallation. Da sich hier doch oft recht viel ändert untenrum läuft das notgedrungen nicht so schön wie ne Neuinstallation. Kann dich jedoch verstehen, sofern du keine Enterprise Plus mit Hostprofiles hast.

Neukonfigurationen mit allen wichtigen Einstellungen lassen sich jedoch auch gut automatisiert über Powershell realisieren. So haben wir das früher gemacht bevor wir auf Enterprise Plus und dann zu vCloud umlizenziert haben.

[mister-man]

Wir haben derzeit den fall, das alle Host sehr langsamm laufen. Es brechen selbst SSh (Putty) Verbundungen zu VM's ab. Diverse Server, wie Faxserver verarbeiten nur noch 3 bis 5 Faxe in 8 Minuten. Und der vSphere Client regiert in den menüpunkten, sowie in der Konsole sehr langsamm.

Das Booten einiger neu aufgesetzten VM' dauert machnmal 10 Minuten.

Alles in allen sieht es so aus, dass das System in Zeitlupe läuft.

Eine Neuinstallation mit erhalt des Datastore brachte hier auch keine Abhilfe.

[blue_focus]

Was verwendet ihr zum Management? Habt ihr ein vCenter?
Wenn nein bin ich mir grade nicht sicher, ob und in welchem Ausmaß die Performance Charts im vSphere Client abrufbar sind. Denke aber, dass man die Realtimecharts schon sehen müsste.
Hier wäre es interessant wie die Hosts so ausgelastet sind. CPU, RAM usw.
in den meisten fällen sind aber zu langsame Datastores das Problem.

Hast du ein paar infos zur verwendeten Hardwarekonstellation bei euch?

[mister-man]

Hay,

hatte das Posten gestern nicht geschafft.
Die Hardware sind 3 IBM Server mit 2x Xeon und 40 GB Ram... Das Cluster wird im Grunde derzeit nur zu 30 Prozent im Tagesschnitt genutzt.
Und ja ein vCenter wird genu8tzt.

Mittlerweile konnten wir das Storage, welches über eine iSCSI Karte angebunden ist), als Fehlerquelle identifizieren.

Code: Alles auswählen

Device naa.5000c5000b36354b performance has deteriorated. I/O latency increased from average value of 1832 microseconds to 19403 microsecond

Code: Alles auswählen

Frequent path state changes are occurring for path vmhba2:C0:T0:L3. This may indicate a storage problem. Affected device: naa.60060160316314002f8e4496705edd1. Affected datastores: ds1

Das Storage ist ein IBM DS3300

[blue_focus]

Mahlzeit,

dachte ich mir fast, dass das Klassiker Bottlneck wieder zugeschlagen hat

Leider hab ich mit iSCSI nicht viel Erfahrung im vmware Sektor. Kenn es nur aus dem Windows-Clusterumfeld und da war das von der Stabilität und Latenz her nicht so doll im Vergleich zu FC.

Jedoch gibt es auch sicher hier viel, was man optimieren kann. Hast du zB.: ein eigenes NIC-Team + vSwitch für Management?. Bei NFS geht der Backofficetraffic über den Management Kernel Port (in unserem Fall vmk0). Bin mir nicht 100%ig sicher ob das für iSCSI auch gilt.

Erfahrungsgemäß macht es Sinn diesen Traffic von den VM-Guest Netzen zu trennen. Hast du zB nur 1Gbit-NICs im Einsatz müssen sich VMs die verfügbare Bandbreite mit dem iSCSI-Traffic teilen. Spätestens beim Backup geht das schnell in die Knie.


Desweiteren, was verwendet ihr für eine Path-Policy für die iSCSI-Disken. VMWare nimmt standardmäßig immer nur die "fixed"-Policy. Da man in der Regel aber immer mindestens 2 Pfade zu einer LUN hat wird so immer nur einer verwendet. Ich empfehle hier lieber auf Round Robin zu stellen. Das schöpft alles aus und bleibt dennoch redundant. Das gilt natürlich nur wenn ihr nicht eigene Multipathing Treiber vom Storage-Hersteller (IBM) verwendet. Da läuft das oft wieder etwas anders.

Ach ja. Wie ist eure Storagebox bestückt. SAS od. SATA. Wieviele Spindeln usw.

Noch was: Verwendet ihr die lokalen Disken der Hosts als Datastores? Wenn nicht kannst die bei der Installation auch problemlos überschreiben lassen. Wichtig nur, dass du nicht versehentlich den ESX auf einem Datastore auf der Storage installierst und überschreibst. Das wäre fatal!

[mister-man]

Mahlzeit auch....

Okay, vielelicht muss ich ersteinmal Input liefern.

Speicheranbindung:
QLE406Xc iSCSI Host (1Port)

Netzwerk:
- vSwitch0 1GBit\s: vMotion
- vSwitch7 1GBit\s + 1GBit\s Standby: Management + Portgruppe mit vCenter
- vSwitch1 1GBit\s + 1GBit\s Team: 4 Portgruppen Taggd (für VM's)


Der ESXi ist mit dem SAN über ein Crosskabel verbunden, die Karte meldet 1GBit\s. Am sand sind Controller A Port 1, Controller A Port 2 und Controller B Port 1 belegt (cross).
Alle ESXi Server greifen auf 4 Lun's a 1,8 TB zu.

Festplatten:
Das Storage sollte eigendlich SAS Festplatten haben, leider wurde dies bei der letzten Neubestückung wohl vergessen. Deshalb sind mittlerweile SATA Festplatten verbaut.
Lokale Festplatten werden derzeit gerne für CD ISO's verwendet. vereinzelt liegen dort VM's, welche kein HA benötigen.

Konfiguration iSCSI:
Der iSCSI-Initiator ist derzeit statisch eingegeben, keine Dynamische erkennung. Jeder Host nutzt dabei einen eigenen, der Zugriff wird über eine Hostgroup am SAN gesetzt.

Der Pfad zu jedem Lun ist derzeit auf "Fest (VMware)", es ist allerdings nur ein Ziel pro Lun in der Liste. Müssten für "Round-Robin (VMware)" nicht mindestens 2 Pfäde da sein?

Bin leider kein Experte für SAN's, deshalb entschuldigt bitte falls ich Triviale fragen stellen. Lese mich gerade weiter in das Thema ein um den Fehler zu finden. Doch derzeit vermute ich ihn eher bei VMware.

Edit1:
Habe gerade mal eine VM versucht von einem lokalen Datastore auf das lun zu kopieren. Dazu habe ich den Dateispeicherbrowser verwendet. VMWare sagt mir nun 2048 Minuten verbleibend. Nach etwa 10 Minuten bricht der vorgang ab.
Da kann doch etwas nicht stimmen, besonders da die VM nur 20 GB groß war....

[blue_focus]

Hi

Also wenn ich das richtig verstehe ist der QLogic iSCSI Host ein Hardware Initiator der die LUNs schon vor dem ESXi-Boot via BIOS mounted? Sorry habe da überhaupt keine Erfahrungswerte

Wenn ja -> OK dann läuft das unterm Strich eh ähnlich ab wie bei FC von Protokollunterschieden abgesehen.

Netzwerk/vSwitch-Aufteilung sieht vernünftig aus.

SATA-Platten find ich leider nicht so prickelnd. Kenne nur wenige Storage-Hersteller, die selbst aus denen viel I/O rausbekommen -> EMC² kann das angeblich ganz gut.
Grade vmware ist furchtbar I/O Intensive.

zum Pathing:
unter FC hat man in der regel mehrere "Fabrics", also unterschiedliche Kabelwege, wie man zu seinem Ziel kommt. Jede LUN sollte im regelfall über jede Fabric angesprochen werden können. Hier funktioniert auch das MultiPathing ganz gut.

Hast du für iSCSI die Single oder die Dual-Headvariante?
Ist es nur die Single, dann wäre es verständlich warum nur ein Pfad pro LUN verfügbar ist. Sonst ist das was faul und du verwendest von deinen 2x1GBit nur 1GBit. Der Rest liegt brach oder wartet auf einen Failover.

Wie laufen VMs auf dem lokalen DS? Laufen die da normal, haben wir definitiv eine SAN oder Storage Thema.

Hast du eine Möglichkeit Performancedaten aus der Storagebox zu bekommen?

Unterstütz deine Storagebox SIOC (Storage I/O Control) Das kann man pro LUN per Hakerl aktivieren. Dann bekommst du auch ordentlich Performance Graphen bzgl. Latenzen und Gesamt IOPS auf der LUN

Zu deinem EDIT:
Das untermauert meine These, dass wir hier ein Storagethema haben.

[mister-man]

Hay

Also wenn ich das richtig verstehe ist der QLogic iSCSI Host ein Hardware Initiator der die LUNs schon vor dem ESXi-Boot via BIOS mounted?

Nein, die Einstellung erfolgt schon über VMware, allerdings wird keine "Normale" Netzwerkkarte für die Verbindung verwendet.

SATA-Platten find ich leider nicht so prickelnd. Kenne nur wenige Storage-Hersteller, die selbst aus denen viel I/O rausbekommen -> EMC² kann das angeblich ganz gut.
Grade vmware ist furchtbar I/O Intensive.

Ja, das sehe ich ja derzeit. VM's sind alle nicht nutzbar, obwohl der Server kaum auslastung hat. Weil das SAN nicht mitspielt.

unter FC hat man in der regel mehrere "Fabrics", also unterschiedliche Kabelwege, wie man zu seinem Ziel kommt. Jede LUN sollte im regelfall über jede Fabric angesprochen werden können. Hier funktioniert auch das MultiPathing ganz gut.

Derzeit sieht es wie gesagt so aus, das ich ein Kabel(weg) pro ESXi Host zum SAN habe. Sprich jeder ESXi ist über ein Crosskabel mit dem SAN direkt verbunden.

Hast du für iSCSI die Single oder die Dual-Headvariante?

Dual-Headvariante? Meinst du die ein oder zwei Port variente der iSCSI Karte? Ich habe die ein Port Variante.

Wie laufen VMs auf dem lokalen DS? Laufen die da normal, haben wir definitiv eine SAN oder Storage Thema.

Hab es gerade mal getestet. Die geschwindigkeit ist ohne Mängel. Alles top, solange die VM's nicht auf dem SAN liegen. Genauso das kopieren vom lokalen Datastore auf meinem Computer. Vom SAN auf meinem Computer (über VMware) grotten langsamm. (5 GB ca 350 Minuten)!!

Hast du eine Möglichkeit Performancedaten aus der Storagebox zu bekommen?

Ich bin gerade im Gespräch mit demjenigen der das System damals aufgebaut hatte. Dann sollte ein Zugriff nichts im Weg stehen!

Unterstütz deine Storagebox SIOC (Storage I/O Control) Das kann man pro LUN per Hakerl aktivieren. Dann bekommst du auch ordentlich Performance Graphen bzgl. Latenzen und Gesamt IOPS auf der LUN

Muss ich passen, prüfe ich wenn gleich das Login da ist....[/quote]

Edit1:

Unterstütz deine Storagebox SIOC (Storage I/O Control)

Da es in der Konfiguration (Zusammenfassung) nicht aufgeführt ist, denke ich nicht!

[weigeltchen]

Poste doch mal die Konfiguration deiner iSCSI-Konfiguration auf den Hosts.
Wenn ich das richtig verstanden habe, hängt jeder host direkt per Kabel an einem Controllerport des SAN? Wie sieht denn da das host-mapping auf der DS aus? Für einen dedizierten Switch für die iSCSI-Anbindung reichte das Budget nicht mehr?verwendet?

[blue_focus]

Guten Morgen,

ok, ich denke dann sollte das Übel gefunden sein
erfahrungsgemäß ist fast immer eine lahme Storage das Problem. Zumindest wars bei uns bisher immer so. Ins besondere wenn die Hosts alle samt offensichtlich nichts tun...

[mister-man]

@blue_focus:
Ja das stimmt, nun geht es an die Behebung...

@weigeltchen:
Habe das System so übernommen, mit der Info, das es etwas veraltet ist und nicht ganz rund läuft. Nun bin ich dabei genau dieses zu richten.
Der besagte Switch ist bereits bestellt, doch sind bei uns die internen Wege weit. Sprich der Switch kommt erst in 3 bis 6 Wochen. Bis dahin wollte ich aber das System mit übergangshardware Fir haben, sodass ich nur noch den Switch tauschen muss.

Und ja, du hast richtig verstanden, Das SAN verfügt über 2 iSCSI Controller mit jeweils 2 Ports. Jeder ESXi Host ist mit einem Port verbunden und hat einen eigenen Path.

Bisher denke ich das auch dort das Problem liegt.
Hab ein Wenig nachgelesen und bisher stehe ich auf dem Standpunkt, das ich ESXi 1,2,3 über einen Switch mit Controller A, B mit jeweils Port eins verbinden muss. Danach darf es für alle ESXi Server nur noch 2 Path geben. GGF nen Round Robin!

Oder was meinst du dazu?

[weigeltchen]

Auf den ESXi-Host ist jeweils ein vSwitch mit dem iSCSI Kernelport, und nur mit dem, konfiguriert? Dann könnte man das mal alles aufmalen.
Übrigens, wenn zukünftig alles über den dedizierten Switch läuft, wäre zu überlegen, ob nicht ein weiterer iSCSI-HBA je Host angeschafft oder eine vorhandene NIC für iSCSI mit verwendet wird. Redundanz, Lastverteilung.

[mister-man]

Auf den ESXi-Host ist jeweils ein vSwitch mit dem iSCSI Kernelport, und nur mit dem, konfiguriert?

Das iSCSI ist eine Hardwarecontroller. Sprich bei den Netzwerkkarten taucht er nicht auch.
Bei den Netzwerkkarten sind 2 Managementswitches Konfiguriert, einer für vMotion (in einem vLan), der andere für Verwaltungsdatenverkehr. Jeweils über Accessports mit dem pNetz verbunden.

Aber wie gesagt, die Speicheranbindung taucht bei den vSwitches nicht auf !