In Folge der Corona-Krise musste die Deutsche VMUG UserCon auf den 11. Dezember 2020 verschoben werden. In der Zwischenzeit organisieren wir alle zwei Wochen kurze einstündige virtuelle Veranstaltungen zu einem ausgewählten Thema.
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.
