Veeam Backup v10 auf vSAN 7.0

Linux Proxys

Unmittelbar nach installation der Veeam Anwendung erhält der Veeam Server auch die Proxy- und Repository-Rollen. Das ist jedoch meist nicht die beste Wahl. Weder in klassischen Bare-Metal SAN Umgebungen, noch in vSAN Clustern.

Seit Veeam Version v10 ist es möglich, Linux VMs als Proxys bereitzustellen. Die für den Proxy notwendigen Ressourcen kann man im Sizing Summary nachlesen.

  • 1 CPU Core pro Task (ein Task ist eine virtuelle Disk)
  • 2GB RAM pro Task
  • Ein Minimum von 500MB Disk-Speicher pro Task

Das ist nicht wirklich viel. Da mein Lab-Cluster aus 4 vSAN Knoten besteht, muss ich auch vier Proxy VMs bereitstellen. Hierfür habe ich das aktuelle Ubuntu Server 20.04 LTS ausgewählt. Ein graphischer Desktop wird nicht benötigt und auch alle anderen Paketvorschläge bei der Installation kann man getrost ablehnen. Keep it simple!

Template vorbereiten

Nach der Ubuntu Basisinstallation bedarf es noch zweier zusätzlicher Pakete. Open-vm-tools und Perl.

sudo apt-get install open-vm-tools
sudo apt-get install perl

Perl sollte beim aktuellen Ubuntu Server bereits vorinstalliert sein. Apt wird uns darüber informieren. Der Befehl ist nur zur Kontrolle.

Feste IP vergeben

Aktuelleere Ubuntu Versionen verwalten die Netzwerkeinstellungen mit netplan. Eine gute Einführung zu netplan gibt es auf dem Ubuntu Blog. Nach der Installation des open-vm-tools Pakets findet man zwei YAML Dateien. Der Name der urspünglichen Konfiguration beginnt mit 00- und eine weitere, deren Namen mit 99- beginnt, wurde von den open-vm-tools erzeugt. Diese müssen wir anpassen.

cd /etc/netplan

Egal welchen Editor Ihr verwendet, startet ihn mit sudo.

sudo nano 99-netcfg-vmware.yaml

Standardmäßig ist DHCP konfiguriert. Wir müssen hinter dhcp4 das yes zu einem no ändern. Zusätzlich müssen weitere Zeilen mit der Bezeichnung “addresses:” und “gateway4:” eingefügt werden. In diesem Beispiel ist meine statische IP Adresse des ersten Proxys 10.0.10.131 mit einer Netzmaske von 255.255.255.0 (/24), sowie 10.0.10.1 als Gateway. Meine Suchdomäne ist “lab.local” und der DNS Server ist 10.0.10.2.

# Generated by VMWare customization engine.
network:
   version: 2
   renderer: networkd
   ethernets:
      ens160:
      dhcp4: no
      dhcp4-overrides:
         use-dns: false
      dhcp6: yes
      dhcp6-overrides:
         use-dns: false
      addresses: [10.0.10.131/24]
      gateway4: 10.0.10.1
      nameservers:
         search:
            - lab.local
         addresses:
            - 10.0.10.2

Das YAML File wird gespeichert und der Editor beendet. Zur Aktivierung der Konfiguration wird folgender Befehl abgesetzt.

sudo netplan apply

Keine Sorge. Wenn sich Fehler in der Konfiguration befinden wird netplan dies mitteilen. Ich hatte zuerst zwei Tippfehler im YAML File.

VM Parameter disk.EnableUUID

Unser Proxy Template ist fast fertig. Damit die Linux VM aber im Hotadd-Modus arbeiten kann muss die VM die UUID des physischen Datenspeichers “sehen”. Dazu müssen wir einen erweiterten Parameter in der VM Konfiguration setzen. Die VM muss hierfür ausgeschaltet sein. In der VM Konfiguration klicken wir auf “Add Configuration Params”. Als Name geben wir disk.EnableUUID ein und setzen den Wert auf TRUE.

Ich habe meine erste Proxy VM in einTemplate gewandelt und eine Ableitungsrichtlinie dafür erstellt. Name der VM als Hostnamen setzen, nach IP Adresse fragen, VM nach Bereitstellung starten. Mehr nicht.

Proxy VM vom Template ableiten

Die Bereitstellung vom Template ist einfach und geht recht schnell. Daher wird im Beispiel hier eine nicht-redundante Speicherrichtlinie verwendet (RAID 0). Somit wird weniger des kostbaren AF Speichers belegt.

Beim Ableiten wird die zuvor erstellte Richtlinie ausgewählt.

Nach dem Start haben wir eine fertige Linux VM. Es ist empfehlenswert, die DNS Auflösung und Netzverbindung vom Veeam Server zur VM zu testen (PING). Wenn das reibungslos funktioniert, können wir den ersten Proxy hinzufügen.

Da wir den Default-Proxy (Veeam Server) nicht verwenden wollen, fügen wir einen neuen hinzu (Add New).

Hier muss der FQDN des Proxys angegeben werden.

Damit Veeam auf den Proxy zugreifen kann, müssen wir dessen Zugangsdaten hinterlegen.

Der von mir definierte Admin-User heisst “veeam”. In modernen Linux Systemen wird der User root nicht zum arbeiten verwendet. Daher ist es wichtig, die Rechte des gewählten Benutzers anzuheben und ihn in die Grupper der “sudoers” aufzunehmen. Dafür ist ein gesondertes Passwort notwendig (das Passwort, das man nach einem sudo Befehl auf der CLI eingeben muss).

Veeam öffnet eine SSH Verbindung zur Linux VM. Der digitale Fingerabdruck stellt sicher, dass wir mit der richtigen VM sprechen.

Im POC wenden wir keine besonderen Regeln für den Datenverkehr an.

Veeam wird einige Perl Skripte auf der Linux VM starten. Daher war es wichtig, zuvor die Perl Runtime zu installieren.

Glückwunsch! Wir haben unseren ersten Linux Proxy im Rennen. Diesen Vorgang müssen wir so lange wiederholen, bis alle Hosts im vSAN Cluster mit einem Proxy ausgestattet sind.

Wie man im Bild unten erkennen kann, gibt es im Cluster vier Proxys. Einen für jeden ESXi Host. Spätestens jetzt sollte man auch die Proxy Rolle auf dem Windows Veeam Server deaktivieren.

DRS Regeln für Proxys einrichten

Wir möchten einen Proxy für jeden Host haben. Diese arbeiten gegen den lokalen Datenspeicher. Wir müssen also sicherstellen, dass diese auf ihrem zugeteilten Host verbleiben. Dies kann leicht über eine weiche DRS Regel erreicht werden. Dazu habe ich vier Hostgruppen esx01 bis esx04 mit jeweils einem ESXi darin definiert, sowie vier VM-Gruppen prox01 bis prox04 mit jeweils einem Proxy. Danach werden Host-Affinitätsregeln definiert. Sie sind unten dargestellt.

Auf Seite 3 werde ich zeigen, wie man ein Linux-Repository erzeugt, das die Fast Cloning Technik unterstützt.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert