Am vergangenen Montagabend kam es zu massiven Störungen im Betrieb dieser Blog Webseite. Der Seitenaufbau war gestört und Besucher bekamen eine “Internal Server Error” Meldung anstatt der Startseite.
Wir bitten die Störung zu entschuldigen und freuen uns auf zukünftige Besuche der Seite.
Auch wenn es sich wie ein Angriff anfühlte, lag die Ursache in einem Konfigurationsfehler, der sich aber nicht sofort auswirkte, sondern erst einige Stunden nach der Änderung. Die Fehlersuche wurde erschwert, da zwei Veränderungen in kurzem Abstand vorgenommen wurden und der vermeintliche Auslöser eigentlich unschuldig an der Misere war.
Memo an mich selbst: Vorsicht mit Hosting-Funktionen, die man nicht zu 100% versteht und immer nur einen Parameter ändern.
Im ersten Quartal 2020 gab es eine Menge Neuerscheinungen. Die lange erwartete Veeam Backup Version 10, die schon 2017 auf der VeeamON angekündigt wurde und die neueste vSphere Generation aus dem Hause VMware. Im Homelab lief vSAN 7 bereits in der Betaphase, jedoch hatte ich Veeam v10 bisher nur in produktiven Kundenumgebungen gesehen. Leider gibt es dort kaum eine Möglichkeit, die vielen neuen Funktionen zu testen – es sei denn der Kunde wünscht dies. Eine der spannenden Neuerungen ist die Möglichkeit, Linux-Proxies und -Repositories einzusetzen. Verwendet man XFS als Dateisystem auf dem Repository, so kann man auch dort die Fast Cloning Technik verwenden, welche in ihren Eigenschaften ReFS unter Windows ähnlich ist.
Diese Einführung deckt folgende Themen ab:
einen Veeam Server bereitstellen
Basiskonfiguration des Servers und die Integration eines vCenters
Erzeugung, Konfiguration und Bereitstellung eines Linux Proxys und dessen integration in die Backup Infrastruktur
Erzeugung, Konfiguration und Bereitstellung eines Linux Repositorys mit dem XFS Dateisystem und dessen integration in die Backup Infrastruktur
Veeam Backup auf einer vSAN Umgebung erfordert ein besonderes Design der Backup Infrastruktur. Ein Direct SAN Backup ist beispielsweise nicht möglich, denn es gibt ja weder ein SAN, noch eine Fabric, noch einen HBA. Folglich bleiben nur zwei mögliche Backupmethoden: Network Mode (nbd) und Virtual Appliance Mode (hotadd). Letztere ist das Mittel der Wahl, jedoch muss dafür gesorgt werden, dass kein unnötiger Datenverkehr auf dem vSAN Netzwerk entsteht. Dazu wird pro vSAN Host eine Proxy Appliance VM bereitgestellt. Der Hotadd Mode verwendet den Advanced Data Fetcher (ADF).
Rechts: Backup vom vSAN Cluster mit nur einer Proxy Appliance; Backup Traffic wird über das vSAN Network geleitet, wenn Proxy und VM Disk nicht auf dem selben Host sind. Links: Eine Proxy Appliance pro vSAN Knoten; Datentransfer ohne Belastung des vSAN Netzwerks.
Bisher wurde für jeden weiteren Proxy Server eine Windows Lizenz benötigt. Diese können jetzt durch die Verwendung von Linux Proxies eingespart werden. Selbstverständlich mag man nun argumentieren, daß auf einem vSAN Cluster, der auch andere Windows Server VMs betreibt, ohnehin eine Datacenter Lizenz für alle ESX Hosts vorhanden sein muss und somit die weiteren Windows Proxies keine Mehrkosten erzeugen. Es gibt aber Anwendungsfälle, bei denen auf dem vSAN Cluster reine Linux Umgebungen betrieben werden. Hier nur für das Backup einen kompletten Cluster mit Windows Datacenter zu lizensieren wäre ein erheblicher Kostenfaktor. Ein Grund mehr, die neuen Linux Proxies zu testen. Eine Veeam Lizenz wird natürlich auch noch benötigt. Als vExpert erhält man jedoch eine NFR (not for resale) Lizenz, die ein ganzes Jahr gilt. Nur einer der Vorteile, die der vExpert Status mit sich bringt.
Lost geht’s! Wir benötigen zuerst einen Veeam Server, der die Job Datenbank und die eigentliche Applikation hält. Proxy- und Repository-Rolle wird auf individuelle Linux Maschinen ausgelagert. Dazu später mehr.
Erst kürzlich hatte ich mein Homelab von vSphere 6.7U3 auf Vsphere 7.0 gehoben. Der Ablauf ist geradlinig und nicht kompliziert. Das VMware Design Team hat hier gute Arbeit geleistet.
Vorbereitungen
Ich kann das nicht oft genug betonen: Prüft die VMware HCL. Nur weil Eure Hardware unter der jetzigen Version freigegeben ist, heisst noch lange nicht dass sie es auch unter vSphere 7.0 sein wird. Am Tag des Upgrades war vSphere 7 brandneu und es gab noch nicht viele Einträge in der HCL. Aber es ist ein Homelab – wenn etwas schief geht kümmert mich das nicht sonderlich und ich werde es neu aufbauen. Macht das nicht in Produktivumgebungen!
Obwohl mein Supermicro E300-9D zum Zeitpunkt des Upgrades noch nicht freigegeben war, funktioniert der Cluster reibungslos. Die Zertifizierung ist nur eine Frage der Zeit, denn der VMware Nano-Edge Cluster basiert auf dieser Hardware.
Vor Beginn muss zunächst die vCenter Server Appliance (VCSA) vom VMware Downloadcenter (Login erforderlich) geladen werden. Außerden wird eine neue Lizenz für ESXi und vSAN benötigt (falls vSAN zum Einsatz kommt).
Der VMware igbn Treiber für Intel 82580, I210, I350, und I354 Gigabit Ethernet Controller kann unter bestimmten Bedingungen einen PSOD auslösen. Das macht es zu einem kritischen Fehler auf allen Hosts mit den oben genannten Netzwerk Adaptern.
Aktuell gibt es keinen VMware Patch, der das Problem beseitigt. Es wird empfohlen, den VMware Treiber durch den neuen Intel Treiber ab Version 1.4.10 zu ersetzen.
Wenn wir eine SSH Sitzung zum Host öffnen, können wir die installierte igbn Treiberversion abfragen.
Zunächst müssen wir das Treiberpaket bei VMware herunterladen (Login erforderlich) und das Archiv entpacken. Es enthält eine Dokumentation, ein Offline-Bundle (ZIP) und ein VMware Installation Bundle (VIB). Man kann zwar das VIB auf der Command-Shell eines Hosts installieren, jedoch ist es wesentlich komfortabler, hierfür den VMware Update-Manager (VUM) zu verwenden. Letztere Prozedur werde ich hier schildern.
Wir öffnen den vSphere-Client und gehen zu Menu > Update-Manager. Wer noch eine vSphere Version vor 6.7 U1 betreibt, muss hierfür den ungeliebten Flashclient (Web-Client) verwenden. In der Rubrik Updates wählen wir “Upload from File”.
Im Dialog wählen wir das ZIP-File (Offline Bundle). Um hier etwas Konfusion mit geschachtelten ZIP-Dateien vorzubeugen, möchte ich noch einmal darauf hinweisen welches ZIP-File hier gemeint ist. Wir haben bei VMware ein ZIP-Archiv herunter geladen, das wir entpacken. Darin befindet sich ein weiteres ZIP-Archiv. Dieses entpacken wir nicht. Im Dialog wählen wir dieses “innere” ZIP-File aus und laden es in den VUM.
