rh2010 - stock.adobe.com
Mit APIs spezifische Disaster-Recovery-Reports erstellen
Mit den richtigen PowerShell-Befehlen und API-Aufrufen können Sie einen Disaster Recovery-Bericht erstellen und anpassen. Lesen Sie hier, welche Schritte dafür notwendig sind.
Ein benutzerdefinierter Disaster-Recovery-Bericht (DR) kann im DR-Prozess hilfreich sein, aber es ist nicht einfach, einen zu erstellen. APIs – ein Tool, das Disaster-Recovery-Administratoren oft übersehen – können den Prozess jedoch vereinfachen.
Benutzerdefinierte Berichte können den Status einer DR-Umgebung direkt in den Posteingang eines Administrators liefern. Sie machen manuelle Überprüfungen überflüssig, um sicherzustellen, dass alles reibungslos abläuft. Diese Berichte sind auch eine gute Option, wenn der DR-Anbieter eines Unternehmens keine optimierte Berichtsfunktion anbietet oder diese nur im Rahmen einer höheren Zahlungsstufe zur Verfügung steht.
Dieser Leitfaden führt Administratoren Schritt für Schritt durch die Erstellung eines benutzerdefinierten DR-Berichts. Sie erfahren, wie Sie die notwendigen Daten extrahieren und wie Sie API-Endpunkte nutzen, um den Disaster-Recovery-Bericht zu erstellen.
Dieser Leitfaden bezieht sich auf den Backup-Anbieter Zerto und dessen DR-API. Die Prinzipien lassen sich jedoch auch auf die APIs anderer Anbieter, wie Veeam oder Commvault, übertragen. Ein rudimentäres Verständnis von PowerShell ist hilfreich, um das meiste aus diesem Leitfaden herauszuholen.
Erste Schritte
Eine API (Application Programming Interface oder Anwendungsprogrammierschnittstelle) besteht aus einer Reihe von Endpunkten oder Uniform Resource Identifiers (URIs), die einen programmatischen Zugriff auf Software ermöglichen. Admins stellen eine Anfrage und APIs geben die entsprechenden Daten zurück.
Verwenden Sie am Beispiel von Zerto PowerShell und die API, um ein Codeschnipsel zu erstellen, mit dem eine Liste von virtuellen Maschinen (VMs) angefordert wird:
$myURL = "https://myZertoServer.local:9669/vms"
$myVmArray = Invoke-RESTMethod -Method Get -Uri $myURL -Headers $zertoHeader
Der obige Befehl fragt den in der Invoke-RESTMethode angegebenen URI ab und legt die zurückgegebenen Daten in der Variablen myVmArray ab. Wenn wir die Invoke-RESTMethode verwenden, konvertiert PowerShell das vom API-Endpunkt zurückgegebene XML standardmäßig in ein PowerShell-Array.
In diesem Beispiel gibt der Methodenparameter an, was wir mit den Informationen tun. Die GET-Methode wird nur zum Abrufen von Datengleichungen verwendet.
Der Umfang der potenziellen Elemente, auf die über die API zugegriffen werden kann, ist enorm. Admins können zum Beispiel APIs nutzen, um Daten über Datenspeicher, Netzwerke und Festplattenauslastung zu sammeln. Dies hilft bei der Erstellung von benutzerdefinierten DR-Berichten. Zunächst müssen wir jedoch sicherstellen, dass wir entsprechend autorisiert sind, diese Daten vom Endpunkt abzurufen.
Header enthalten Authentifizierungsinformationen, die für den Zugriff auf die API-Endpunkte erforderlich sind. Sie ermöglichen die Verwendung einer Autorisierungszeichenfolge, die mit jeder API-Anforderung übergeben wird, um zu beweisen, dass die Benutzer die sind, für die sie sich ausgeben.
Im Folgenden finden Sie ein Beispiel für die Verwendung von Headern mit Zerto. Fügen Sie den Authentifizierungs-Header mit dem -Headers-Teil des oben gezeigten PowerShell-Codeausschnitts.
Die Anforderungen an Header können von Plattform zu Plattform stark variieren; sie können so einfach wie eine Zeile oder sehr komplex sein. Leider fällt Zerto in den letzteren Fall. Der unten gezeigte Header stammt aus der API-Dokumentation von Zerto selbst.
$ZertoServer = @("myzertoserver")
$ZertoPort = "9669"
$ZertoBenutzer = "zertouser"
$ZertoPassword = "zertopassword"
<# Set the above to reflect your environment #>
$baseURL = "https://" + $ZertoHost + ": "+$ZertoPort+"/v1/"
$xZertoSessionURL = $baseURL + "session/add"
$authInfo = ("{0}:{1}" -f $ZertoUser,$ZertoPasswort)
$authInfo = [System.Text.Encoding]::UTF8.GetBytes($authInfo)
$authInfo = [System.Convert]::ToBase64String($authInfo)
$headers = @{Authorization=("Basic {0}" -f $authInfo)}
$sessionBody = '{"AuthenticationMethod": "1"}'
$TypeJSON = "application/json"
try
{
$xZertoSessionResponse = Invoke-WebRequest -Uri $xZertoSessionURL -Headers $headers -Method POST -Body $sessionBody -ContentType $TypeJSON
}
Catch {
Write-Host $_.Exception.ToString()
$error[0] | Format-List -Force
}
$xZertoSession = $xZertoSessionResponse.headers.get_item("x-zerto-session")
$zertoSessionHeader = @{"x-zerto-session"=$xZertoSession}
Passen Sie die ersten vier Zeilen des obigen PowerShell-Skripts an Ihre Umgebung an, rufen Sie getxZertoSession auf und geben Sie den Benutzernamen und das Kennwort ein.
Bei jeder Verwendung des Skripts wird eine neue Sitzung erstellt, die den Zugriff auf die Ressourcen ermöglicht. Stellen Sie sich das wie das Verbinden oder Trennen von einem Dienst vor. Der Sitzungsstart wird im obigen Code gefunden und in die Variable $zertoSessionHeader in der letzten Zeile eingetragen.
Verwenden Sie die API zum Abrufen von Daten
Um Berichte zu erstellen, verwenden Sie APIs, um Daten abzurufen.
Zerto bietet den Endpunkt „alerts“, der alle Fehler und Warnungen für die Zerto-Site und alle gepaarten Sites auflistet. Der nächste Schritt besteht darin, einen WebRequest-kompatiblen String zu erstellen, der an die authentifizierte Sitzung übergeben wird.
Als Best Practice wird empfohlen, eine Basis-URL zu verwenden, die die URL ohne die Endpunkte enthält. Wenn Administratoren dann eine URL erstellen müssen, verwenden sie die Basis-URL und fügen den Endpunkt hinzu. Die folgende Zeichenfolge entspricht also nicht den bewährten Verfahren zum Erstellen eines Endpunkts, sondern ist für dieses Beispiel vereinfacht:
$myAlertsURL = "https://myZertoServer.local:9669/alerts"
Rufen Sie dann die URL-Zeichenkette auf:
$alertsData = Invoke-WebRequest -Method Get -URI $myAlertsURL -Header $zertoHeader
Wenn das Skript ausgeführt wird und keine Fehler auftreten, befinden sich die Gesamtheit der Alarme und alle Informationen über sie in $alertsData. Geben Sie $alertsData ein, um dies zu überprüfen, und lesen Sie die Variable in der PowerShell-Befehlszeile.
Admins können experimentieren und andere Daten abrufen, einschließlich Site- und Bandbreiteninformationen. Gehen Sie jedoch mit Vorsicht vor, wenn Sie etwas anderes als eine GET-Methode verwenden, da weitere Änderungen die Konfigurationen verändern können.
Erstellen und Anpassen eines Berichts
Die Daten in der Variablen $alertsData sind bei weitem kein vollständiger HTML-Bericht. Zum Glück gibt es in PowerShell das Cmdlet convertTo-Html, das den Inhalt einer Variablen oder eines Objekts in einen HTML-Bericht exportiert. Um es in seiner einfachsten Form zu verwenden, übergeben Sie die Variable wie folgt über die Pipeline an das Cmdlet:
$alertsData | convertTo-Html | outputfile c:\myexample.html
In einigen Fällen möchte der DR-Administrator möglicherweise nicht, dass der Bericht alle verfügbaren Felder enthält. Anstatt einen so umfangreichen Bericht zu erstellen, verfügt PowerShell über ein Cmdlet select-Object, das Admins zwischen den Befehlen platzieren können, um nur die gewünschten Felder auszuwählen, etwa so:
$alertsData | select-Object Level, TurnedOn, Description | convertTo-Html
Führen Sie $alertsData über die PowerShell-Befehlszeile aus, um alle Fehler zurückzugeben und anzuzeigen, welche Daten zur Auswahl verfügbar sind.
An dieser Stelle ist es möglich, die gefilterten Details in eine HTML-Datei zu schreiben. Das Cmdlet convertTo-Html verfügt über viele Optionen. Das folgende Beispiel würde einen einfachen Bericht erstellen:
$alertsData | select-Object Level, TurnedOn, Level, Description | convertToHTML '
-Body "daily report $(get-date -Format "YYYY-mm-dd")$alertsData '
-OutputFile "DailyReport.html"
Im obigen Codeschnipsel gibt es einige neue Einträge. Der Parameter -Body steht für einen beliebigen Inhalt, den Admins in den HTML <body>-Tag einfügen möchten. Im obigen Beispiel wird DailyReport mit dem Datum versehen, das auf verschiedene Weise formatiert werden kann. Beachten Sie auch das ' im Codeschnipsel. Dies ermöglicht die Aufteilung eines langen Befehls auf mehrere Zeilen, um die Lesbarkeit zu verbessern.
An dieser Stelle werden die Daten in ein HTML-Dokument exportiert. Derzeit spuckt der Bericht nur Fehler und Warnungen aus, wenn er auf sie stößt. Um nach Fehlern und Warnungen zu gruppieren, verwenden Sie die Cmdlets Order-by:
$alertsData | select-Object select-Object Level, TurnedOn, Description | Order-by TurnedOn | convertToHTML '
-Body "Daily report $(get-date -Format "YYYY-mm-dd")$alertsData '
-OutputFile "DailyReport.html"
So wie der Bericht jetzt aussieht, hat er eine Tabelle, aber mit convertTo-Html und der Eigenschaft-Fragment sind mehrere Tabellen möglich. Um das Design und die Formatierung des Berichts weiter anzupassen, verwenden Sie ein Inline-Stylesheet, wie das in diesem Blogbeitrag von Adam the Automator gezeigte.
Die Standard-Tabellenüberschriften sind etwas unglücklich formuliert. Es gibt kein PowerShell-Cmdlet, um dies direkt zu beheben, aber wir können einen Filter auf die Ausgabe anwenden, bevor wir sie ausschreiben. Verwenden Sie das Cmdlet PSItem. Wir können dies zwischen convertTo-Html und der Ausgabe in die Datei einfügen:
ForEach-Object { $PSItem -replace"<th>TurnedOn</th>","<th>Alarm Activated</th>"}
Der obige Code ändert die Tabellenüberschrift TurnedOn in den aussagekräftigeren Alarm Activated.