Beiträge

Veröffentlicht am

NIC Reihenfolge bei VCF Erweiterung

VMware Cloud Foundation (VCF) ist die einheitliche SDDC-Plattform für die Hybrid Cloud. Sie basiert auf der Compute-, Storage- und Netzwerkvirtualisierung von VMware.

VMware Cloud Foundation kann modular um weitere Workload Cluster erweitert werden, oder eine vorhandene Management-Domain über eine zweite Availability-Zone (AZ) gestreckt werden. Der Erweiterungsprozess wird über den SDDC-Manager gesteuert. Der Ablauf hierzu ist im Prinzip recht einfach und der SDDC-Manager übernimmt im Hintergrund alle Konfigurations-Aufgben, wie z.B. die Erzeugung des vSAN Clusters, der Netzwerke, Kernelports, vCenter umd NSX-Manager.

  • Hosts mit ESXi Basisimage installieren
  • Management IP definieren
  • root Login definieren
  • DNS und NTP konfigurieren
  • neue Hosts in den SDDC-Manager importieren
  • WLD erzeugen

Es gibt jedoch einen kleinen Stolperstein, der leicht übersehen wird: Die NIC Reihenfolge der neuen Hosts. Vor dem Import der Hosts wir eine Checkliste angezeigt, die uns darüber informiert, welche Eigenschaften die Hosts haben müssen. Gefordert werden zwei physische NICs mit mindestens 10 GBit.

Was jedoch oft überlesen wird, ist das Prädikat “traditional numbering“. Das bedeutet, die beiden 10 GBit NICs müssen die Nummern vmnic0 und vmnic1 haben. Eine Information, die leider allzuleicht überlesen wird. Diese Reihenfolge ist hart-verdrahtet und läßt sich nicht auswählen. Erschwerend kommt hinzu, dass viele Serversysteme Onboard-Netzwerkadapter haben, die zum Teil in 1 GBit ausgelegt sind. ESXi beginnt bei der Nummerierung der vmnics bei diesen Onboard-Adaptern. In solch einem Fall hätten dann also die geplanten 10 GBit NICs höhere Nummern wie z.B. vmnic2 oder vmnic3. Damit scheitert das Rollout der VCF Erweiterung.

Es ist in der aktuellen VCF Version 4.2 nicht möglich, die NICs explizit zu wählen, wie dies beispielsweise im Bringup-Sheet der Fall ist. Auch die Verwendung von mehr als 2 NICs geht nur über API-Calls und nicht über den SDDC-Manager.

Ausweg

Der einzige Ausweg besteht gegenwärtig darin, die Onboard Adapter im BIOS der Server zu deaktivieren und ggf. den PCIe LAN Adapter in einen Slot mit niedriger Nummer zu stecken, damit die NICs die Nummern 0 und 1 erhalten.

Veröffentlicht am

Veeam Immutable Backups auf vorhandenen Linux XFS Repositories aktivieren

Veeam backup & Replication v11 steht kurz vor der Veröffentlichung. Diese ist für Mittwoch den 24.2.2021 geplant. Partner und Service Provider hatten einige Tage Vorsprung und Zugriff auf den sogenannten RTM Build (ready to manufactoring).

Eine der (wie ich meine) spannensten neuen Funktionen in Version 11 ist die Einführung der sogenannten Immutable Backups. Ich hatte bereits in meinem Beitrag “Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS” berichtet.

Einige von Euch setzen möglicherweise schon Linux Repository Server mit dem XFS Dateisystem und Fastclone produktiv ein und möchten diese nun im die Funktion Immutable-Backups erweitern. Ich werde in diesem Beitrag erklären, wie sich dies mit wenigen Schritten bewerkstelligen lässt.

Schutz aktivieren

Um die Funktion zum Schutz der Backupdaten auf bestehenden XFS Repositories zu aktivieren, müssen wir diese im Veeam Backup Client v11 bearbeiten (Bild unten). Ab Version 11 ist im Abschnitt Repository eine neue Checkbox zu sehen (“make recent backups immutable for [x] days”). Dabei ist 7 Tage der kleinstmögliche Zeitraum für den Schutz. Sobald man die Checkbox aktiviert wird sehr wahrscheinlich eine Benachrichtigung wie unten dargestellt erscheinen. “Unable to set the immutability option: cannot find the transport service on server <your repo server>. Configure the server anyway?“. Wir bestätigen diese mit [Yes].

Wir müssen zur Aktivierung des Immutable Flags den Veeam Transport Service auf dem Ziel neu konfigurieren.

„Veeam Immutable Backups auf vorhandenen Linux XFS Repositories aktivieren“ weiterlesen
Veröffentlicht am

VMware Cloud Foundation 4.2 angekündigt

VCF 4.2 steht kurz vor der Veröffentlichung und bringt einige lange erwartete Verbesserungen mit sich.

[Update: seit dem 9. Februar 2021 ist VCF 4.2 allgemein verfügbar.]

  • vSAN HCI Mesh
  • NSX-T 3.1 Federation
  • vSAN Data Persistence platform (DPp)
  • vRealize Automation for VCF
  • IP Pools für NSX-T Tunnel Endpoints (TEP)
  • Release Versionsüberblick im SDDC Manager
  • Pre-Upgrade Checks
  • Advanced Security Add-on for VMware Cloud Foundation
    • Carbon Black Workload Advanced
    • Advanced Threat Prevention Add-on for NSX Data Center
    • NSX Advanced Load Balancer with Web Application Firewall
„VMware Cloud Foundation 4.2 angekündigt“ weiterlesen
Veröffentlicht am

Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS

Angriffe auf IT-Infrastrukturen sind in letzter Zeit immer raffinierter geworden. Sie verschlüsseln nicht nur Live-Daten und ganze virtuelle Maschinen, sie haben auch gelernt, ganze Backups zu löschen, oder zu verschlüsseln. Dabei spielt es keine Rolle, ob Ihre Online-Backups in einem lokalen Repository, oder auf einem Cloud-Share gespeichert sind. Wenn dieser Fall eintritt und Sie kein Offline Backup wie beispielsweise Tape, oder einen sonstigen Plan B in der Hinterhand haben, werden Sie alt aussehen. Schlimmer noch: Wenn Sie in Ihrem Unternehmen für die Datensicherung verantwortlich sind, müssen Sie sich unangenehmen Fragen seitens der Geschäftsführung stellen.

Nun stellt sich die Frage, wie Sie die Backup-Daten schützen, falls ein Angreifer Zugriff auf Ihren Backup-Server erhält. Sobald er die Zugangsdaten zum Server hat, kann er alles tun, was der Backup-Administrator tun kann. Das Löschen von Backups zum Beispiel. Ein erster Schritt besteht darin, Ihre Backup-Systeme von Ihrer Domain zu trennen. Für den Fall, dass der Domain-Administrator-Account kompromittiert wird, gibt es immer noch eine (kleine) Barriere zwischen Angreifern und Ihren Backup-Systemen. Aber trotzdem werden Sie nie wissen, ob Angreifer Kenntnis von einem Zero-Day-Exploit haben, um Ihren Backup-Server zu übernehmen. Ein besserer Ansatz wäre es, Backups für eine definierte Zeitspanne gegen das Löschen zu schützen. Eine ähnliche Option gibt es bei AWS S3-Buckets, die üblicherweise als Offsite-Sicherungskopien verwendet werden. Das Zurückholen von Offsite-Backups nimmt eine beträchtliche Zeitspanne in Anspruch. Im Falle eines Kryptoangriffs ist die Zeit entscheidend und die Uhr tickt. Wäre es nicht großartig, unveränderliche Backups auf Ihren primären Repositories vor Ort zu haben? Gute Nachrichten. Es gibt Licht am Ende des Tunnels (und ich verspreche, es ist nicht der entgegenkommende Zug).

Unveränderliche (Immutable) Backups

Bevor wir ins Detail gehen, müssen wir klären, was unveränderliche Backups bedeuten. Die Idee ist, dass man einmal schreibt und dann die Dateien (Backups) für eine selbst definierte Zeitspanne geschützt sind. Selbst der Backup-Administrator kann sie nicht löschen, bevor die definierte Zeitspanne verstrichen ist.

Veeam Backup & Replication v11 wird eine native Funktion des Linux XFS-Dateisystems nutzen. XFS kann ein erweitertes Dateiattribut [i] setzen, das die Datei vor Umbenennung, Änderung, Löschung oder Hard-Linking schützt. Der Clou dabei ist, dass Backups mit einem nicht privilegierten Konto übertragen und geschrieben werden und das Immutable-Attribut von einem Dienst auf dem Repository-Server gesetzt und entfernt wird, der erhöhte Rechte hat und auf den von außen nicht zugegriffen werden kann.

Alles, was Sie benötigen, ist ein mit XFS formatiertes Linux-Repository und Veeam Backup & Replication v11, das demnächst erscheinen wird. (Update: Geplantes Erscheinungsdatum ist der 24.02.2021)

„Strategien zum Schutz von Veeam Backups durch unveränderliche Repository Server mit Linux XFS“ weiterlesen