Veeam Sure Backup PING Fehler

Ein PING Fehler bei Veeam Sure Backup “DestinationHostUnreachable” kann aufgrund von Automatic Private IP Addressing (APIPA) auf dem virtuellen LAN Adapter auftreten. Obwohl die live-VM eine statische IP Adresse hat, geht diese beim Vorgang des SureBackup verloren, wechselt zu DHCP und produziert oben genannten Fehler.

Das Problem ist bei vmware unter KB1020078 bekannt.

Ein ausführlicher Bericht ist im Blog der PepperCrew zu lesen.

Zoning Brocade 300

Einrichtung von Zonen auf einem Brocade 300 FC-Switch.

Diese Anleitung geht von einer Neueinrichtung aus, kann aber prinzipiell zur Erweiterung einer vorhandenen Zonenkonfiguration verwendet werden.

Eine Zonierung auf Basis der WWN hat den Vorteil, daß die Fasern an beliebigen Ports des Switches angeschlossen werden können. Dem gegenüber steht ein gewisser Mehraufwand bei der Einrichtung. „Zoning Brocade 300“ weiterlesen

VM restart priority vs. startup order

Ein reales Szenario:

Eine defekte USV soll getauscht werden. Alle Komponenten sind redundant mit Strom versorgt (ein Netzteil an USV, das andere direkt am Stromnetz). Vor der Abschaltung der USV kommt es zu einem kurzen Ausfall im Stromnetz. Die USV ist zu schwach um auch nur diese kleine Schwankung abzufangen. Die Folge: Ein Blackout der vSphere Infrastruktur (ESXi, Storage, Fabric, LAN). Prinzipiell ärgerlich, aber kein Problem. Denn auf allen ESXi Knoten waren zuvor Startreihenfolgen definiert, die genau regeln sollten wann welche VM startet. Leider starteten die ESXi Knoten alle vorher laufenden VMs praktisch zeitgleich, was zu einer erheblichen Belastung der Storage führte (Boot-Storm).

Was war passiert?

Man muss hier zwei unterschiedliche Szenarien unterscheiden:

  • Ordentlicher Kaltstart einer vSphere Infrastruktur nach vorherigen Shutdown aller laufenden VMs
  • Clusterneustart nach Blackout

Letzteres trifft auf den oben beschriebenen Fall zu. D.h. HA bemerkt hier, daß es zu einem Crash kam und versucht alle zuvor aktiven VMs neu zu starten. Die Startreihenfolge auf ESX Ebene ist hier ohne Belang. Alleine HA ist jetzt für den Neustart verantwortlich. Den Ablauf der Ereignisse unter vSphere 5 hat Duncan Epping kurz in einem Artikel skizziert.

Wie kann man steuern, daß nach einem solchen Ausfall nur die Kerndienste neu starten? Eine vor dem Crash zufällig laufende Test-VM sollte z.B. auf keinen Fall unnötig Last auf die Storage bringen und ausgeschaltet bleiben bis sie jemand manuell startet. Die Lösung liegt in den HA Clustereinstellungen.

Unter VM restart priority gibt es vier Optionen:

  • Disabled
  • Low
  • Medium
  • High

Ein möglicher Ansatz

  • Man setzt die VM Neustartpriorität clusterweit auf “Low”.
  • Test-VM und unwichtige VM auf “Disabled”. D.h. selbst wenn sie zum Zeitpunkt des Blackouts liefen, würden sie von HA nicht neu gestartet werden. Das schafft Luft für die elementaren Kerndienste.
  • Unter “High” könnte man z.B. Domaincontroller, DNS/DHCP Server und VirtualCenter (falls virtuell) ansiedeln.
  • Mit Priorität “Medium” kämen weitere wichtige Server, die von Servern der “High”-Klasse direkt abhängig sind. Z.B. Exchange-, Sharepoint- oder SQL-Server.
  • Der ganze Rest, der keine explizite Regel bekam, erhält die Clustereinstellung mit “Low”, also in der dritten Startwelle.

 

 

VM Autostart Einstellungen verloren

Wenn ESXi Hosts ihre Autostartreihenfolge “vergessen”, dann liegt es oft daran, daß nach der Änderung die Management-Agent nicht neu gestartet wurden. Die Folge sind nicht startende VMs nach einem Kaltstart.

Protokoll zur Änderung der VM Bootreihenfoge

  1. VM Startreihenfolge im vSphere-Client anpassen. Host > Configuration > Virtual Machine startup/shutdown
  2. Management-Agents neu starten
    1. ESXi Konsole (DCUI) öffnen
    2. F2 (customize system)
    3. Login als root
    4. “Troubleshooting Options” auswählen (ESXi 4.1, ESXi 5.x)
    5. Restart Management Agents
    6. F11
    7. nach erfolgreichem Neustart [Enter] drücken und vom DCUI abmelden.