Beiträge

Veröffentlicht am

vSAN Cluster Objekte als invalid deklariert

Nach einem gescheiterten Firmwareupgrade auf den Intel x722 NICs kam der betroffene Host ohne seine 10 Gbit Kerneladapter (vSAN-Network) hoch. Alle Versuche der Wiederherstellung scheiterten und ich musste den Server zu Supermicro einschicken. Klassischer Fall von “bricked device“. Nach Update so funktional wie ein Ziegelstein. Normalerweise wäre das in einem 4-Knoten Cluster keine große Sache. Da aber die Management Adapter funktional waren und die vSAN-Netzwerk Adapter nicht, kam es wohl im Cluster zu Störungen und alle Objekte wurden auf den drei verbleibenden Hosts als “invalid” deklariert.

Ich war zu sehr mit Projektarbeit beschäftigt und hatte ohnehin keine Zeit für Experimente im Lab, also wartete ich bis der 4. Host aus der Reparatur zurück kam. Letzte Woche wurde er endlich geliefert. Sofort baute ich Bootmedium, Cache- und Capacity-Disks wieder ein. Ich prüfte die MAC Adressen und Einstellungen. Alles sah gut aus. Sogar die Firmware war auf neuestem Stand. Nachdem ich den wiedervereinigten Cluster gestartet hatte, blieben die Objekte jedoch weiterhin im Status “invalid”.

Zeit für Troubleshooting

Zuerst startete ich SSH auf allen Hosts. Es gibt zwar einen cleveren powerCLI Befehl der das cluster-weit erledigt, aber ich hatte ja kein vCenter (invalid). Also blieb nur der Hostclient.

Auf der Shell des reparierten Hosts prüfte ich die vSAN-Netzwerk Verbindungen zu allen anderen Hosts im Cluster. Das unten dargestellte Kommando pingt beispielsweise vom Interface vmk1 (vSAN) zur IP 10.0.100.11 (vSAN Kernelport esx01).

vmkping -I vmk1 10.0.100.11

Ich erhielt Antworten aller Kernelports aller Hosts. Ein physische Störung im vSAN Netzwerk konnte also ausgeschlossen werden.

„vSAN Cluster Objekte als invalid deklariert“ weiterlesen
Veröffentlicht am

ExaGrid Time-Lock – Keine Angst vor Ransomware

Einleitung

Ransomware stellt aktuell eine der herausragenden Bedrohungen für IT Infrastrukturen dar. Berichte über erfolgreiche Angriffe häufen sich, die Einschläge kommen näher. Über 30% aller Unternehmen, Institute, Universitäten oder Behörden in Deutschland hatten bereits mit derartigen Attacken zu tun. Zum Teil wurde ein Lösegeld bezahlt, um wieder an die eigenen Daten zu gelangen.

Selbst bei Zahlung ist der Erfolg niemals sicher. Schließlich verhandelt man mit Verbrechern. Die Behörden raten daher von der Zahlung ab.

Die wesentliche Schutzmaßnahme gegen die Folgen einer solchen Attacke ist ein aktuelles und konsistentes Backup.

Ransomware vs. Backup

Leider wissen auch die Angreifer um die Wichtigkeit der Backups. Die aktuell kursierenden Schädlinge, wie z.B. Emotet oder Ryuk, enthalten Code der aktiv nach Datensicherungen im Netz fahndet. Mit vorher erlangten Zugangsdaten für Active Directory Konten oder durch Attacken auf z.B. RDP Lücken oder die brandaktuelle Zerologon Lücke wird versucht die Systeme zu übernehmen, welche die Datensicherung im Unternehmen betreiben bzw. die Backupdaten halten.

Oftmals folgen der automatischen Attacke sogar Hacker aus Fleisch und Blut, die sich aktiv im Netz umsehen und versuchen alle Backups zu zerstören. Ein vielfach leiches Unterfangen, da Backups heute vorzugsweise auf Festplattensystemen permanent mit der Infrastruktur verbunden sind.

Der Grund liegt auf der Hand: Sind alle Backups gelöscht oder ebenfalls verschlüsselt, steigt die Compliance des “Kunden” zur Zahlung eines Lösegeldes massiv.

Viele Ansätze wurden daher schon erdacht, die Backupdaten sicher im Netz abzulegen. Eine sehr einfache und sichere Variante ist ein Air-Gap – also eine echte Trennung der Backupmedien vom System. Beispielsweise können LTO Tapes physisch aus der Library entnommen werden.

Ohne eine solche aufwändige manuelle Entnahme – die zudem täglich erfolgen müsste – bleiben die Daten latent verwundbar. Ganz egal, ob sie auf Plattensystemen, Dedup-Appliances, Tapes in einer Library oder sogar in einem S3 Cloud Repository liegen.

S3 Cloud Anbieter haben daher schon vor einiger Zeit eine API Erweiterung mit dem Namen “Object Lock” vorgeschlagen. Hiermit können zumindest die Backups im Cloud Layer eine gewisse Zeit immun gegen Änderungen gemacht werden.

Einige dieser Lösungen werden inzwischen nativ von Veeam unterstützt. Amazon AWS gehört z.B. dazu. Microsoft Azure fehlt z.B. aktuell noch. Außerdem ist S3 Speicher nicht für jeden Anwendungsfall geeignet. Ein Primärbackup mit Veeam auf S3 ist z.B. nicht direkt möglich. Der S3 Layer ist ausschließlich als Erweiterung eines Scale-Out-Backup Repositories verfügbar.

„ExaGrid Time-Lock – Keine Angst vor Ransomware“ weiterlesen
Veröffentlicht am

VMware Cloud Foundation 4.1 angekündigt

Gemeinsam mit vSphere7 und vSAN7 erschien im März dieses Jahres VMware Cloud Foundation (VCF) 4.0 mit Tanzu. Nun hat VMware zusammen mit vSphere 7.0 Update1 und vSAN 7 U1 VMware Cloud Foundation 4.1 angekündigt, das auf einigen der neuen Funktionen von vSAN aufbaut.

Was ist neu?

  • vSAN Data Persistence Platform – Dies ist ein wichtiger Schritt für Hersteller virtueller Appliances und Container Lösungen, die auf vSAN respektive VCF ausgeführt werden sollen. Nicht alle Container Workloads sind statuslos (stateless). Einige von ihnen wie zum Beispiel Objectstorage oder NoSQL sind stateful applications. Bisher waren eigene Replikationsmechanismen in der Anwendung notwendig. Mit vSAN Persistence Platform wird den Anbieitern ermöglicht, direkt die Hochverfügbarkeit von vSAN zu nutzen. Erste Anbieter zind beispielsweise MinIO, DataStax, Dell EMC ObjectScale oder Cloudian.
  • VMware Cloud Foundation Remote Clusters – Ein Feature, das auf vSAN HCI Mesh aufbaut. Damit können vSAN Datastores anderer Cluster eingebunden werden. Dies ist inbesondere für Remotestandorte interessant.
  • vVols in der Workload Domain – Damit können Workload Domains nicht mehr nur auf vSAN Datatores aufgesetzt werden, sondern auch auf klassischer Storage mit vVol Funktion. Als Protokolle werden FC, iSCSI und NFS unterstützt.
  • Automatisierte Bereitstellung der vRealize Suite 8.1 – Der vRealize Suite Life Cycle Manager (vRSLCM) interagiert nun mit dem SDDC Manager. Somit können alle vRealize Produkte vom vRSLCM installiert und aktualisiert werden.
  • Neuerungen und Bugfixes im SDDC Manager
  • VMware Skyline Support für VCF

Das Update wird wahrscheinlich Anfang Oktober zur VMworld oder kurz danach verfügbar sein.

Veröffentlicht am

Update Problem VCSA 7 – vCenter Server not operational

Beim Update (Patch) einer vCenter Server Appliance (VCSA) kann es zu Störungen kommen, oder das Update wird vor dem Start abgebrochen. Versucht man dann erneut das Update einzuspielen, so kann es zu der unten dargestellten Fehlermeldung kommen.

Update Installation failed. VCenter Server is not operational.

Im Management Interface der VCSA (VAMI) lässt sich kein Problem erkennen. Alle Dienste sind aktiv und der Status ist grün. Das Problem bleibt auch nach einem Neustart der Appliance bestehen. Die Ursache liegt in einem zuvor abgebrochenen oder gescheiterten Updateversuch. Dabei wird im Dateisystem der Appliance ein File zurückgelassen, das wir zunächst entfernen müssen.

Dazu starten wir eine SSH Sitzung auf die vCenter Server Appliance.

# cd /etc/applmgmt/appliance

Im dortigen Verzeichnis findet sich eine Datei software_update_state.conf, welche üblicherweise nur während eines Updatevorganges vorhanden ist. Wir können uns den Inhalt näher anschauen.

# cat software_update_state.conf
{
"state": "INSTALL_FAILED",
"version": "7.0.0.10700",
"latest_query_time": "2020-09-17T11:42:37Z"
}

Man sieht den Vermerk in der Datei, dass zuvor ein Update gescheiter war. Die Datei wird vor einem neuen Versuch nicht bereinigt, daher müssen wir das selbst übernehmen.

# rm software_update_state.conf

Danach kann das Update regulär neu gestartet werden und läuft problemlos durch.