Kategorie: Datenspeicher

Veröffentlicht am

ESXi Coredump Files verwalten

Zugegeben, das ist kein neues Thema, aber es kostete mich etwas Zeit in einem Kundenprojekt. Da dieser Blog auch als Swap-Partition meines Gehirns fungiert, habe ich es für die Zukunft niedergeschrieben. Wichtig ist die korrekte Abfolge der Schritte, damit die Änderung auch nach einem Bootvorgang erhalten bleibt.

Wofür wird ein Coredump-File benötigt?

Moderne ESXi Installationen ab Version 7 verwenden ein neues Partitions-Layout des Bootdevices. Darin werden auch Coredumps abgelegt. Jedoch nur wenn das Bootmedium kein USB-Flashmedium und keine SD-Card ist. In solchen Fällen wird der Coredump ausgelagert auf einen VMFS-Datenspeicher mit mindestens 32GB Kapazität.

Genau einen solchen Fall fand ich in einer Kundenumgebung vor. Das System wurde von vSphere 6.7 migriert und hatte daher noch das alte Boot-Layout auf einem (damals noch voll unterstützten) SD-Card RAID1. Wir fanden einen Ordner vmkdump mit Files für jeden Host auf einem der gemeinsamen VMFS-Datenspeicher. Dieser (VMFS5) Datenspeicher sollte aufgelöst und durch einen VMFS6 Datenspeicher ersetzt werden. (Randbemerkung des VCI: Es gibt keinen online Migrationspfad von VMFS5 nach VMFS6). 😉 Also mussten die vmkdump Files von dort weg.

Ablauf

Zunächst verschaffen wir uns eine Übersicht der Coredump-Files.

esxcli system coredump file list

Hier werden alle Coredump-Files aller ESXi-Hosts gelistet. Jede Zeile enthält neben dem Pfad auch die Stati Active und Configured (true oder false). Active bedeutet, dass dies das aktuelle Coredumpfile dieses Hosts ist. Wichtig ist, dass der Wert bei Configured ebenfalls den Status ‘true’ hat. Ansonsten übersteht die Einstellung keinen Reboot. Nur das Coredump-File des aktuellen Hosts hat den Status ‘active’. Alle anderen Files gehören zu anderen Hosts und sind daher active=false.

Im Standard wählt der Host den ersten passenden VMFS-Datenspeicher. Das ist nicht unbedingt der erwünschte.

Aktuelles Coredump-File entfernen

Zunächst löschen wir das aktive Coredump-File des Hosts. Wir müssen die Löschung erzwingen, da es als active=true gesetzt ist.

esxcli system coredump file remove --force

Führen wir das list Kommando von oben nochmals aus, so sollte eine Zeile weniger erscheinen.

Neues Coredump File erzeugen

Der folgende Befehl legt ein neues Coredump-File am Zielort an. Falls noch nicht vorhanden wird ein Ordner vmkdump erzeugt und darin das Dumpfile. Wir übergeben den gewünschten Filenamen ohne Endung, da diese (.dumpfile) automatisch erzeugt wird.

esxcli system coredump file add -d <Name | UUID> -f <filename>

Beispiel: Name des Hosts ist “ESX-01” und der VMFS-Datenspeicher hat den Namen “Service”. Der Datenspeicher darf entweder als Anzeigename oder Datastore_UUID übergeben werden.

esxcli system coredump file add -d Service -f ESX-01

Auf dem benannten Datenspeicher wird nun ein Ordner vmkdump erzeugt und darin ein File namens ESX-01.dumpfile. Wir können dies prüfen über das list Kommando.

esxcli system coredump file list

Es erscheint eine neue Zeile mit dem vollen Pfad zum neuen Dumpfile. Der Status ist jedoch noch active=false und configured=false. Es ist sinnvoll diesen kompletten Pfad in die Zwischenablage zu kopieren, denn wir benötigen ihn im nächsten Schritt.

Dumpfile aktivieren

Wir setzen im folgenden Schritt das neu erzeugte Dumpfile aktiv. Somit bleibt die Einstellung auch nach einen Host-Reboot erhalten. Wir übergeben dabei den vollständigen Pfad zum Dumpfile. Hier eignet sich die Kopie aus der Zwischenablage und vermeidet Tippfehler.

esxcli system coredump file set -p <path_to_dumpfile>

Beispiel:

esxcli system coredump file set -p /vmfs/volumes/<UUID>/vmkdump/ESX-01.dumpfile

Ein abschließender List Befehl bestätigt das Ergebnis.

Links

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

Veeam Storage Plugin für DataCore – Deepdive

SANsymphony trifft Veeam Backup and Replication – Ende gut, alles gut!

(der folgende Artikel wurde automatisch aus dem englischen Original übersetzt)

Fragen, Ergänzungen oder Anmerkungen zu diesem Artikel: melter[at]idicos.de

Seit Dezember 2019 ist das Plugin für den populären DataCore SANsymphony SDS veröffentlicht. Realisiert wurde es auf die einzig richtige Art und Weise: Mit voller Unterstützung und Validierung durch Veeam.

In dieser Artikelserie werden wir verschiedene Aspekte des Plugins behandeln:

„Veeam Storage Plugin für DataCore – Deepdive“ weiterlesen
Seiten: 1 2 3 4 5 6
Veröffentlicht am

Storage Praxis – Das Synchronspiegel Dilemma

Eine kleine Einführung in die Hochverfügbarkeit

Datenbestände an zwei Orten identisch zu halten, wird in der hochverfügbaren IT immer wichtiger. War dies noch vor einigen Jahren ein sehr teurer Luxus für das Enterprise Segment, so dringt diese Anforderung in den letzten Jahren immer weiter in den SMB Bereich vor. Diese Methode nennt man Spiegel und sie kann prinzipiell auf zwei Arten umgesetzt werden:

  • asynchron – Der Datenabgleich erfolgt in definierten Intervallen. Dazwischen herrscht eine Differenz zwischen Quelle und Ziel.
  • synchron – Der Abgleich erfolgt transaktionsgenau, sodaß der Datenbestand zu jedem Zeitpunkt auf beiden Seiten identisch ist. Ein Schreibvorgang gilt erst als abgeschlossen, wenn auch Spiegelziel den Schreibvorgang bestätigt hat.

Eine Voraussetzung für Hochverfügbarkeit ist die Spiegelung der Daten (synchron, oder asynchron). Sind die Daten an zwei Orten (Rechenzentren) vorhanden stellt sich eine weitere Designfrage: Soll das Speicherziel als Kopie für den Notfall fungieren (Active-Passive), oder soll an beiden Orten aktiv mit den Daten gearbeitet werden (Active-Active)?

  • Active-Passive – In diesem Fall wird nur auf der aktiven Seite gearbeitet und die Daten auf die passive Seite übertragen (synchron oder asynchron). im Fehlerfall wird automatisch oder manuell (je nach Modell) umgeschaltet und die vorher passive Seite wird zur aktiven Seite. Sie bleibt dies, bis eine erneute Umkehr ausgelöst wird (Failback). Der Vorteil dieses Verfahrens ist, dass auch im Fehlerfall konstante Leistung garantiert werden kann. Die Ausstattung der passiven Seite muss natürlich identisch mit der aktiven sein. Der Nachteil besteht darin, dass nur maximal 50% der Ressourcen genutzt werden. Die anderen 50% stehen für den Fehlerfall bereit.
  • Active-Active – Hier werden die Ressourcen beider Seiten parallel genutzt und die Hardware kann somit effizienter eingesetzt werden. Dies bedingt aber, dass im Fehlerfall die Hälfte der Ressourcen wegfällt und somit nicht die volle Leistung garantiert werden kann. Active-Active Designs erfordern einen Synchronspiegel, da beide Seiten mit identischen Daten arbeiten müssen.

Active-Active Cluster gibt es in vielfacher Ausprägung. Es gibt klassischen SAN-Storage mit integrierter Spiegelfunktion, oder Software-defined-Storage (sds) bei der die Spiegelung nicht in Hardware, sondern in der Software-Schicht erfolgt. Ein Beispiel dafür ist DataCore SANsymphony. Eine Sonderrolle nimmt hier der VMware vSAN Stretched Cluster ein, der aber nicht Gegenstand dieser Betrachtung sein wird.

Ich werde im folgenden Abschnitt auf eine Besonderheit von LUN basierten active-active Konstrukten eingehen, die leider oft übersehen wird, aber im Fehlerfall zu Datenverlust führen kann. VMware vSAN ist hiervon nicht betroffen, da dessen Stretched Cluster auf einem grundlegend anderen Verfahren beruht.

„Storage Praxis – Das Synchronspiegel Dilemma“ weiterlesen