Die deutsche Sprachversion wurde als Serviceleistung für Sie durch maschinelle Übersetzung erstellt. Bei eventuellen Unstimmigkeiten hat die englische Sprachversion Vorrang.

TR-4923: SQL Server auf AWS EC2 unter Verwendung von Amazon FSX für NetApp ONTAP

04/12/2024 Beitragende

PDFs

Autoren: Pat Sithusan und Niyaz Mohamed, NetApp

Einführung

Viele Unternehmen, die Applikationen von lokalen Storage-Systemen und Cloud-Storage-Services migrieren möchten, stellen fest, dass sie diesem Aufwand durch die Unterschiede in den Funktionen von On-Premises-Storage-Systemen und Cloud-Storage-Services gedient haben. Diese Lücke hat die Migration von Enterprise-Applikationen wie Microsoft SQL Server erheblich problematisch gemacht. Insbesondere Mängel bei den Services, die zur Ausführung einer Enterprise-Applikation erforderlich sind, wie beispielsweise zuverlässige Snapshots, Storage-Effizienz-Funktionen, hohe Verfügbarkeit, Zuverlässigkeit und konsistente Performance, haben Kunden gezwungen, Kompromisse beim Design einzugehen oder Applikationsmigration zu gehen. Mit FSX für NetApp ONTAP müssen Kunden keine Kompromisse mehr eingehen. FSX für NetApp ONTAP ist ein nativer AWS-Service (vom ersten Anbieter), der von AWS vertrieben, unterstützt, abgerechnet und vollständig gemanagt wird. Mit der leistungsstarken ONTAP bietet diese Architektur dieselben Storage- und Datenmanagement-Funktionen der Enterprise-Klasse, die NetApp seit drei Jahrzehnten in AWS als Managed Service vor Ort bietet.

Mit SQL Server auf EC2 Instanzen können Datenbankadministratoren ihre Datenbankumgebung und das zugrunde liegende Betriebssystem aufrufen und anpassen. Eine SQL Server auf EC2-Instanz in Kombination mit "AWS FSX ONTAP" Zum Speichern der Datenbankdateien bietet das Unternehmen hohe Performance, Datenmanagement und einen einfachen und einfachen Migrationspfad über Replizierung auf Blockebene. Daher können Sie Ihre komplexe Datenbank auf AWS VPC mit einem einfachen „Lift-and-Shift“-Ansatz, weniger Klicks und keine Schemakonvertierung ausführen.

Vorteile bei der Verwendung von Amazon FSX für NetApp ONTAP mit SQL Server

Amazon FSX für NetApp ONTAP ist die ideale File-Storage-Lösung für SQL Server-Implementierungen in AWS. Dies bietet unter anderem folgende Vorteile:

Konsistent hohe Performance und hoher Durchsatz mit niedriger Latenz
Intelligentes Caching mit NVMe-Cache für bessere Performance
Flexible Dimensionierung, um Kapazität, Durchsatz und IOPS im Handumdrehen zu erhöhen oder zu reduzieren
Effiziente Block-Replizierung zwischen On-Premises-Systemen und AWS
Verwendung von iSCSI, einem bekannten Protokoll für die Datenbankumgebung
Storage-Effizienzfunktionen wie Thin Provisioning und Klone ohne zusätzlichen Platzbedarf
Verkürzung der Backup-Zeit von Stunden auf Minuten und dadurch Reduzierung der RTO
Granulares Backup und Recovery von SQL-Datenbanken mit der intuitiven SnapCenter UI von NetApp
Die Möglichkeit, vor der eigentlichen Migration mehrere Testmigrationen durchzuführen
Kürzere Ausfallzeiten während der Migration und Bewältigung von Migrationsherausforderungen mit Kopien auf Datei- oder I/O-Ebene
Verringerung der MTTR durch Ermittlung der Ursache nach einem Major Release oder Patch-Update

Die Implementierung von SQL Server Datenbanken auf FSX ONTAP mit dem iSCSI-Protokoll, wie in der Regel vor Ort, bietet eine ideale Storage-Umgebung für Datenbanken mit überlegener Performance, Storage-Effizienz und Datenmanagement-Funktionen. Es wurden mehrere iSCSI-Sitzungen verwendet, bei einer Arbeitsmenge von 5 %, vorausgesetzt, der Einsatz eines Flash Cache liefert über 100.000 IOPS mit dem FSX ONTAP Service. Diese Konfiguration bietet eine vollständige Kontrolle über die Performance für anspruchsvollste Applikationen. SQL Server, der auf kleineren EC2 Instanzen ausgeführt wird, die mit FSX für ONTAP verbunden sind, kann dieselben Vorgänge ausführen wie SQL Server, der auf einer viel größeren EC2 Instanz ausgeführt wird, da nur Bandbreitenbeschränkungen für Netzwerke auf FSX für ONTAP angewendet werden. Durch die Verringerung der Größe von Instanzen werden auch die Computing-Kosten gesenkt, wodurch eine TCO-optimierte Implementierung ermöglicht wird. Die Kombination von SQL mit iSCSI und SMB3.0 mit Multichannel-Freigaben für die kontinuierliche Verfügbarkeit auf FSX für ONTAP bietet große Vorteile für SQL-Workloads.

Bevor Sie beginnen

Die Kombination von Amazon FSX für NetApp ONTAP und SQL Server auf EC2 Instanzen ermöglicht die Erstellung von Datenbank-Storage-Designs der Enterprise-Klasse, die die anspruchsvollsten Applikationsanforderungen bis heute erfüllen können. Zur Optimierung beider Technologien ist es wichtig, die I/O-Muster und Eigenschaften von SQL Server zu verstehen. Ein gut geplantes Storage-Layout für eine SQL Server Datenbank unterstützt die Performance von SQL Server und das Management der SQL Server Infrastruktur. Ein gutes Storage-Layout sorgt auch dafür, dass die ursprüngliche Implementierung erfolgreich ist und die Umgebung mit dem Laufe der Zeit reibungslos wachsen kann, wenn Ihr Unternehmen wächst.

Voraussetzungen

Bevor Sie die Schritte in diesem Dokument ausführen, sollten Sie die folgenden Voraussetzungen erfüllen:

Ein AWS Konto
Entsprechende IAM-Rollen zur Bereitstellung von EC2 und FSX für ONTAP
Eine Windows Active Directory-Domäne auf EC2
Alle SQL Server-Knoten müssen miteinander kommunizieren können
Stellen Sie sicher, dass die DNS-Auflösung funktioniert und die Hostnamen aufgelöst werden können. Falls nicht, verwenden Sie den Eintrag für die Host-Datei.
Allgemeine Kenntnisse zur SQL Server-Installation

Weitere Informationen finden Sie auch in den NetApp Best Practices für Umgebungen mit SQL Server, um die beste Storage-Konfiguration zu gewährleisten.

Best Practice-Konfigurationen für SQL Server-Umgebungen auf EC2

Mit FSX ONTAP ist die Beschaffung von Speicher die einfachste Aufgabe und kann durch Aktualisierung des Dateisystems durchgeführt werden. Dieser einfache Prozess ermöglicht bei Bedarf dynamische Kosten- und Performance-Optimierung, sorgt für den Ausgleich des SQL Workloads und liefert außerdem Thin Provisioning. FSX ONTAP Thin Provisioning wurde entwickelt, um EC2-Instanzen, die SQL Server ausführen, mehr logischen Storage anzubieten, als im Filesystem bereitgestellt wird. Storage muss nicht im Voraus verteilt werden, sondern wird den einzelnen Volumes oder LUNs dynamisch beim Schreiben der Daten zugewiesen. In den meisten Konfigurationen wird freier Speicherplatz wieder freigegeben, wenn Daten auf dem Volume oder der LUN gelöscht werden (und nicht durch Snapshot Kopien gespeichert werden). Die folgende Tabelle enthält Konfigurationseinstellungen für die dynamische Zuweisung von Speicher.

Einstellung

Konfiguration

Volume-Garantie

Keine (standardmäßig festgelegt)

LUN-Reservierung

Aktiviert

Fraktionale_Reserve

0% (standardmäßig festgelegt)

Snap_Reserve

0 %

Automatisches Löschen

Volume / älteste_First

Autosize

Ein

Versuchen Sie es zuerst

Autogrow

Volume Tiering-Richtlinie

Nur Snapshot

Snapshot-Richtlinie

Keine

Mit dieser Konfiguration kann die Gesamtgröße der Volumes größer sein als der tatsächlich im Dateisystem verfügbare Speicher. Wenn die LUNs oder Snapshot Kopien mehr Speicherplatz benötigen, als im Volume verfügbar ist, wachsen die Volumes automatisch und nehmen mehr Speicherplatz aus dem zugehörigen File-System in Anspruch. Autogrow ermöglicht FSX ONTAP, die Volume-Größe automatisch auf eine maximale Größe zu erhöhen, die Sie vorab bestimmen. Um das automatische Wachstum des Volumes zu unterstützen, muss im Filesystem Platz vorhanden sein. Bei aktiviertem Autogrow sollten Sie daher den freien Speicherplatz im Dateisystem überwachen und bei Bedarf das Dateisystem aktualisieren.

Stellen Sie außerdem das ein "Speicherplatzzuweisung" Option bei LUN aktivieren, damit FSX ONTAP den EC2-Host benachrichtigt, wenn der Speicherplatz des Volume knapp wird, und die LUN im Volume keine Schreibvorgänge akzeptieren kann. Mit dieser Option kann FSX für ONTAP außerdem automatisch Speicherplatz zurückgewinnen, wenn SQL Server auf EC2 Host Daten löscht. Die Option für die Speicherplatzzuweisung ist standardmäßig auf deaktiviert eingestellt.

Wenn eine space-reservierte LUN in einem ohne garantierte Performance-Volume erstellt wird, verhält sich die LUN wie eine nicht-space-reservierte LUN. Das liegt daran, dass ein nicht garantiertes Volume keinen Platz hat, der LUN zuzuweisen. Das Volume selbst kann aufgrund seiner keinen Garantie nur Speicherplatz zuweisen, da es geschrieben wird.

Mit dieser Konfiguration können FSX ONTAP-Administratoren die Größe des Volumes in der Regel so festlegen, dass sie den belegten Speicherplatz auf der LUN-Seite auf der Host-Seite und im Filesystem managen und überwachen müssen.

NetApp empfiehlt die Verwendung eines separaten Filesystems für SQL Server Workloads. Wenn das Dateisystem für mehrere Anwendungen verwendet wird, überwachen Sie die Speicherplatznutzung sowohl des Dateisystems als auch der Volumes innerhalb des Dateisystems, um sicherzustellen, dass die Volumes nicht auf verfügbaren Speicherplatz konkurrieren.

Snapshot Kopien, die zur Erstellung von FlexClone Volumes genutzt werden, werden durch die Option Autodelete nicht gelöscht.

Eine Überbelegung von Storage muss für eine geschäftskritische Applikation wie SQL Server sorgfältig geprüft und gemanagt werden. Selbst ein minimaler Ausfall ist nicht tolerierbar. In solch einem Fall ist es am besten, Trends in der Storage-Nutzung zu überwachen, um festzustellen, wie viel oder wann überhaupt eine Überbelegung akzeptabel ist.

Best Practices

Für eine optimale Storage-Performance sollten Sie die Filesystem-Kapazität bis zum 1,35-fachen der gesamten Datenbankauslastung bereitstellen.
Zur Vermeidung von Applikations-Downtime ist eine angemessene Überwachung sowie ein effektiver Aktionsplan mit Thin Provisioning erforderlich.
Achten Sie darauf, die Warnmeldungen zu CloudWatch und anderen Monitoring-Tools so einzurichten, dass jederzeit Kontakt mit Mitarbeitern aufgenommen wird, wenn der Storage gefüllt ist.

Konfiguration von Storage für SQL Server und Bereitstellung von SnapCenter für Backup-, Restore- und Klonvorgänge

Um SQL-Servervorgänge mit SnapCenter durchzuführen, müssen Sie zuerst Volumes und LUNs für SQL Server erstellen.

Erstellung von Volumes und LUNs für SQL Server

Führen Sie die folgenden Schritte aus, um Volumes und LUNs für SQL Server zu erstellen:

Öffnen Sie die Amazon FSX-Konsole bei https://console.aws.amazon.com/fsx/
Erstellen Sie mit der Option „Standard erstellen“ unter „Erstellungsmethode“ ein Amazon FSX für das Filesystem von NetApp ONTAP. So können Sie FSxadmin- und vsadmin-Anmeldeinformationen definieren.
Geben Sie das Passwort für fsxadmin an.
Geben Sie das Passwort für SVMs an.
Erstellen Sie Volumes, indem Sie den Schritt befolgen, der in aufgeführt ist "Erstellung eines Volumes auf FSX für NetApp ONTAP".

Best Practices
- Deaktivieren Sie Zeitpläne für Storage Snapshot Kopien und Aufbewahrungsrichtlinien. Verwenden Sie stattdessen NetApp SnapCenter, um Snapshot Kopien der SQL Server Daten und Protokoll-Volumes zu koordinieren.
- Konfigurieren Sie Datenbanken auf einzelnen LUNs auf separaten Volumes, um von einer schnellen und granularen Restore-Funktion zu profitieren.
- Platzieren Sie Benutzerdatendateien (.mdf) auf separaten Volumes, da es sich um Workloads mit zufälligen Lese-/Schreibzugriffen handelt. Es ist üblich, Transaktions-Log-Backups häufiger zu erstellen als Datenbank-Backups. Aus diesem Grund legen Sie Transaktions-Log-Dateien (.ldf) auf ein separates Volume von den Datendateien ab, so dass für jedes einzelne unabhängige Backup-Zeitpläne erstellt werden können. Durch diese Trennung werden auch die I/O-Vorgänge bei sequenziellen Schreibvorgängen aus den I/O-Vorgängen für zufällige Lese-/Schreibzugriffe von Datendateien isoliert und die SQL Server Performance deutlich verbessert.
- Tempdb ist eine Systemdatenbank, die von Microsoft SQL Server als temporärer Arbeitsbereich verwendet wird, insbesondere für I/O-intensive DBCC CHECKDB-Vorgänge. Platzieren Sie daher diese Datenbank auf einem dedizierten Volume. In großen Umgebungen, in denen die Volume-Anzahl eine Herausforderung ist, können Sie tempdb in weniger Volumes konsolidieren und im gleichen Volume wie andere Systemdatenbanken nach einer sorgfältigen Planung speichern. Datensicherung für tempdb ist keine hohe Priorität, da diese Datenbank bei jedem Neustart von Microsoft SQL Server neu erstellt wird.

Verwenden Sie den folgenden SSH-Befehl zum Erstellen von Volumes:

vol create -vserver svm001 -volume vol_awssqlprod01_data -aggregate aggr1 -size 800GB -state online -tiering-policy snapshot-only -percent-snapshot-space 0 -autosize-mode grow -snapshot-policy none -security-style ntfs
volume modify -vserver svm001 -volume vol_awssqlprod01_data -fractional-reserve 0
volume modify -vserver svm001 -volume vol_awssqlprod01_data -space-mgmt-try-first vol_grow
volume snapshot autodelete modify -vserver svm001 -volume vol_awssqlprod01_data -delete-order oldest_first

Starten Sie den iSCSI-Dienst mit PowerShell unter Verwendung erhöhter Berechtigungen in Windows-Servern.
```
Start-service -Name msiscsi
Set-Service -Name msiscsi -StartupType Automatic
```
Installieren Sie Multipath IO mit PowerShell unter Verwendung erhöhter Berechtigungen in Windows Servern.
```
 Install-WindowsFeature -name Multipath-IO -Restart
```
Suchen Sie den Windows-Initiatornamen mit PowerShell unter Verwendung von erhöhten Berechtigungen in Windows-Servern.
```
Get-InitiatorPort | select NodeAddress
```

Stellen Sie eine Verbindung zu Storage Virtual Machines (SVM) mithilfe von putty her und erstellen Sie eine iGroup.

igroup create -igroup igrp_ws2019sql1 -protocol iscsi -ostype windows -initiator iqn.1991-05.com.microsoft:ws2019-sql1.contoso.net

Verwenden Sie den folgenden SSH-Befehl, um LUNs zu erstellen:

lun create -path /vol/vol_awssqlprod01_data/lun_awssqlprod01_data -size 700GB -ostype windows_2008 -space-allocation enabled lun create -path /vol/vol_awssqlprod01_log/lun_awssqlprod01_log -size 100GB -ostype windows_2008 -space-allocation enabled

Fehler: Fehlendes Grafikbild

Verwenden Sie Windows_2008 als empfohlenen LUN-Typ, um die I/O-Ausrichtung mit dem OS-Partitionierungsschema zu erreichen. Siehe "Hier" Finden Sie weitere Informationen.

Verwenden Sie den folgenden SSH-Befehl für die Zuordnung der Initiatorgruppe zu den LUNs, die Sie gerade erstellt haben.

lun show
lun map -path /vol/vol_awssqlprod01_data/lun_awssqlprod01_data -igroup igrp_awssqlprod01lun map -path /vol/vol_awssqlprod01_log/lun_awssqlprod01_log -igroup igrp_awssqlprod01

Fehler: Fehlendes Grafikbild

Führen Sie für eine freigegebene Festplatte, die Windows Failover Cluster verwendet, einen SSH-Befehl aus, um die gleiche LUN der Initiatorgruppe zuzuordnen, die zu allen Servern gehört, die am Windows Failover Cluster teilnehmen.
Windows Server mit einer SVM mit einem iSCSI-Ziel verbinden. Suchen Sie die Ziel-IP-Adresse aus dem AWS Portal.
Wählen Sie im Server Manager und im Menü Extras den iSCSI-Initiator aus. Wählen Sie die Registerkarte Ermittlung aus, und wählen Sie dann Portal ermitteln aus. Geben Sie im vorherigen Schritt die iSCSI-IP-Adresse ein, und wählen Sie Erweitert. Wählen Sie im lokalen Adapter Microsoft iSCSI Initiator aus. Wählen Sie in Initiator-IP die IP des Servers aus. Wählen Sie anschließend OK, um alle Fenster zu schließen.
Wiederholen Sie Schritt 12 für die zweite iSCSI-IP-Adresse der SVM.
Wählen Sie die Registerkarte Ziele aus, wählen Sie Verbinden und wählen Sie muti-Pfad aktivieren.
Fügen Sie für eine optimale Performance weitere Sitzungen hinzu. NetApp empfiehlt die Erstellung von fünf iSCSI-Sitzungen. Wählen Sie Eigenschaften *> *Sitzung hinzufügen *> *Erweitert aus, und wiederholen Sie Schritt 12.
```
$TargetPortals = ('10.2.1.167', '10.2.2.12')
foreach ($TargetPortal in $TargetPortals) {New-IscsiTargetPortal -TargetPortalAddress $TargetPortal}
```

Best Practices

Konfigurieren Sie fünf iSCSI-Sitzungen pro Zielschnittstelle, um eine optimale Performance zu erzielen.
Konfiguration einer Round Robin-Richtlinie zur besten iSCSI-Performance insgesamt

Stellen Sie beim Formatieren der LUNs sicher, dass die Zuordnungseinheit für Partitionen auf 64K eingestellt ist

Führen Sie den folgenden PowerShell-Befehl aus, um sicherzustellen, dass die iSCSI-Sitzung beibehalten wird.

$targets = Get-IscsiTarget
foreach ($target in $targets)
{
Connect-IscsiTarget -IsMultipathEnabled $true -NodeAddress $target.NodeAddress -IsPersistent $true
}

Fehler: Fehlendes Grafikbild

Initialisieren Sie die Festplatten mit dem folgenden PowerShell-Befehl.

$disks = Get-Disk | where PartitionStyle -eq raw
foreach ($disk in $disks) {Initialize-Disk $disk.Number}

Fehler: Fehlendes Grafikbild

Führen Sie die Befehle Partition erstellen und Disk formatieren mit PowerShell aus.

New-Partition -DiskNumber 1 -DriveLetter F -UseMaximumSize
Format-Volume -DriveLetter F -FileSystem NTFS -AllocationUnitSize 65536
New-Partition -DiskNumber 2 -DriveLetter G -UseMaximumSize
Format-Volume -DriveLetter G -FileSystem NTFS -AllocationUnitSize 65536

Sie können die Erstellung von Volumes und LUNs mit dem PowerShell Skript aus Anhang B. automatisieren LUNs können auch mit SnapCenter erstellt werden.

Sobald die Volumes und LUNs definiert sind, müssen Sie SnapCenter einrichten, um die Datenbankvorgänge ausführen zu können.

Übersicht über SnapCenter

NetApp SnapCenter ist eine Datensicherungssoftware der nächsten Generation für Tier-1-Enterprise-Applikationen. Mit der zentralen Management-Oberfläche automatisiert und vereinfacht SnapCenter manuelle, komplexe und zeitintensive Prozesse, die im Zusammenhang mit Backup, Recovery und dem Klonen zahlreicher Datenbanken und anderer Applikations-Workloads anfallen. SnapCenter nutzt NetApp Technologien, darunter NetApp Snapshot, NetApp SnapMirror, SnapRestore und NetApp FlexClone. Dank dieser Integration können IT-Abteilungen ihre Storage-Infrastruktur skalieren, zunehmend anspruchsvolle SLA-Verpflichtungen erfüllen und die Produktivität der Administratoren im gesamten Unternehmen verbessern.

Anforderungen für SnapCenter Server

In der folgenden Tabelle sind die Mindestanforderungen für die Installation des SnapCenter-Servers und des Plug-ins unter Microsoft Windows Server aufgeführt.

Komponenten	Anforderungen
Minimale CPU-Anzahl	Vier Kerne/vCPUs
Speicher	Minimum: 8 GB empfohlen: 32 GB
Speicherplatz	Minimaler Installationsspeicherplatz: 10 GB für das Repository: 10 GB
Unterstütztes Betriebssystem	Windows Server 2012 Windows Server 2012 R2 Windows Server 2016 Windows Server 2019
Softwarepakete	.NET 4.5.2 oder höher Windows Management Framework (WMF) 4.0 oder höher PowerShell 4.0 oder höher

Komponenten

Anforderungen

Minimale CPU-Anzahl

Vier Kerne/vCPUs

Speicher

Minimum: 8 GB empfohlen: 32 GB

Speicherplatz

Minimaler Installationsspeicherplatz: 10 GB für das Repository: 10 GB

Unterstütztes Betriebssystem

Windows Server 2012
Windows Server 2012 R2
Windows Server 2016
Windows Server 2019

Softwarepakete

.NET 4.5.2 oder höher
Windows Management Framework (WMF) 4.0 oder höher
PowerShell 4.0 oder höher

Weitere Informationen finden Sie unter "Platz- und Dimensionierungsanforderungen".

Informationen zur Versionskompatibilität finden Sie im "NetApp Interoperabilitäts-Matrix-Tool".

Datenbank-Storage-Layout

Die folgende Abbildung zeigt einige Überlegungen beim Erstellen des Microsoft SQL Server Datenbank-Storage-Layouts beim Backup mit SnapCenter.

Fehler: Fehlendes Grafikbild

Best Practices

Platzieren Sie Datenbanken mit I/O-intensiven Abfragen oder einer großen Datenbankgröße (beispielsweise 500 GB oder mehr) auf einem separaten Volume, um eine schnellere Recovery zu ermöglichen. Dieses Volumen sollte auch durch separate Jobs gesichert werden.
Konsolidierung von Datenbanken kleiner bis mittlerer Größe, die weniger kritisch sind oder weniger I/O-Anforderungen auf ein einzelnes Volume haben Wenn eine große Anzahl von Datenbanken auf demselben Volume gesichert wird, benötigen Sie weniger Snapshot Kopien. Als Best Practice wird außerdem empfohlen, Microsoft SQL Server Instanzen zu konsolidieren, um dieselben Volumes zu verwenden, um die Anzahl der erstellten Backup-Snapshot-Kopien zu steuern.
Erstellen Sie separate LUNs, um Dateien zu vollständigen Text und Datei-Streaming zu speichern.
Weisen Sie separate LUNs pro Host zu, um Microsoft SQL Server-Protokoll-Backups zu speichern.
Systemdatenbanken, in denen Metadaten des Datenbankservers konfiguriert und Einzelheiten zu Jobs gespeichert sind, werden nicht häufig aktualisiert. Legen Sie Systemdatenbanken/tempdb in separate Laufwerke oder LUNs. Platzieren Sie keine Systemdatenbanken auf demselben Volume wie die Benutzerdatenbanken. Benutzerdatenbanken haben eine andere Backup-Richtlinie, und die Häufigkeit der Backups in der Benutzerdatenbank ist bei Systemdatenbanken nicht identisch.
Legen Sie für die Einrichtung der Microsoft SQL Server Availability Group Daten und Protokolldateien für Replikate in einer identischen Ordnerstruktur auf allen Knoten ab.

Neben dem Performance-Vorteil, den das Benutzerdatenbanklayout in verschiedene Volumes aufzuteilen, wirkt sich die Datenbank auch deutlich auf die für Backups und Restores erforderliche Zeit aus. Die Verwendung separater Volumes für Daten- und Log-Dateien verkürzt die Wiederherstellungszeit erheblich, im Vergleich zu einem Volume, das mehrere Benutzerdatendateien hostet. Außerdem sind Benutzerdatenbanken mit einer hohen I/O-intensiven Applikation anfällig für eine höhere Backup-Zeit. Eine ausführlichere Erläuterung der Backup- und Restore-Verfahren finden Sie weiter unten in diesem Dokument.

Beginnend mit SQL Server 2012 (11.x), Systemdatenbanken (Master, Model, MSDB und tempdb), Zudem können Datenbanken mit Database Engine Benutzern als Storage-Option mit einem SMB-Dateiserver installiert werden. Dies gilt sowohl für Standalone SQL Server als auch für SQL Server Failover Cluster-Installationen. Damit können Sie FSX für ONTAP mit sämtlichen Performance- und Datenmanagementfunktionen einsetzen, einschließlich Volume-Kapazität, Performance-Skalierbarkeit und Datensicherungsfunktionen, die SQL Server nutzen kann. Freigaben, die von den Applikationsservern verwendet werden, müssen mit der kontinuierlich verfügbaren Eigenschaft konfiguriert werden. Das Volume sollte dann mit dem NTFS-Sicherheitsstil erstellt werden. NetApp SnapCenter kann nicht zusammen mit Datenbanken verwendet werden, die auf SMB-Freigaben von FSX für ONTAP platziert sind.

Für SQL Server-Datenbanken, die keine Backups mit SnapCenter durchführen, empfiehlt Microsoft, die Daten und Log-Dateien auf separaten Laufwerken zu platzieren. Bei Anwendungen, die gleichzeitig Daten aktualisieren und anfordern, ist die Protokolldatei schreibintensiv und die Datendatei (je nach Anwendung) ist Lese-/schreibintensiv. Für den Datenabruf wird die Protokolldatei nicht benötigt. Daher können Datenanfragen aus der Datendatei auf dem eigenen Laufwerk bearbeitet werden.

Wenn Sie eine neue Datenbank erstellen, empfiehlt Microsoft, getrennte Laufwerke für die Daten und Protokolle anzugeben. Um Dateien nach der Datenbankerstellung zu verschieben, muss die Datenbank offline geschaltet werden. Weitere Empfehlungen von Microsoft finden Sie unter Daten und Protokolldateien auf separaten Laufwerken platzieren.

Installation und Einrichtung für SnapCenter

Folgen Sie den "Installieren Sie den SnapCenter-Server" Und "Installieren des SnapCenter Plug-ins für Microsoft SQL Server" Um SnapCenter zu installieren und einzurichten.

Führen Sie nach der Installation von SnapCenter die folgenden Schritte aus, um sie einzurichten.

Um Anmeldeinformationen einzurichten, wählen Sie Einstellungen > Neu und geben Sie die Anmeldeinformationen ein.
Fügen Sie das Storage-System hinzu, indem Sie Storage-Systeme > Neu auswählen und die entsprechende FSX für ONTAP-Storage-Informationen bereitstellen.
Fügen Sie Hosts hinzu, indem Sie Hosts > Add auswählen und dann die Hostinformationen angeben. SnapCenter installiert das Windows und SQL Server Plug-in automatisch. Dieser Vorgang kann einige Zeit in Anspruch nehmen.

Nachdem alle Plug-ins installiert sind, müssen Sie das Protokollverzeichnis konfigurieren. Dies ist der Speicherort, an dem sich das Transaktions-Log-Backup befindet. Sie können das Protokollverzeichnis konfigurieren, indem Sie den Host auswählen und dann das Protokollverzeichnis konfigurieren auswählen.

SnapCenter verwendet ein Host-Protokollverzeichnis zum Speichern von Backup-Daten für Transaktionsprotokolle. Dieser Punkt befindet sich auf Host- und Instanzebene. Jeder von SnapCenter verwendete SQL Server-Host muss über ein Host-Protokollverzeichnis für die Durchführung von Protokoll-Backups verfügen. Bei SnapCenter gibt es ein Datenbank-Repository, sodass Metadaten, die mit Backup-, Restore- oder Klonvorgängen verbunden sind, in einem zentralen Datenbank-Repository gespeichert werden.

Die Größe des Host-Protokollverzeichnisses wird wie folgt berechnet:

Größe des Host-Log-Verzeichnisses = Größe der Systemdatenbank + (maximale DB LDF-Größe × tägliche Log-Änderungsrate % × (Snapshot-Kopie-Aufbewahrung) ÷ (1 – LUN-Overhead-Platz %)

Die Größenformel für das Host-Protokoll-Verzeichnis setzt folgende voraus:

Eine Systemdatenbank-Sicherung, die die tempdb-Datenbank nicht enthält
Eine 10% LUN Overheadfläche somit ist das Host-Log-Verzeichnis auf einem dedizierten Volume oder einer LUN vorhanden. Die Datenmenge im Host-Log-Verzeichnis hängt von der Größe der Backups und der Anzahl der Tage ab, die Backups aufbewahrt werden.

Wenn die LUNs bereits bereitgestellt wurden, können Sie den Bereitstellungspunkt auswählen, der das Host-Protokollverzeichnis darstellt.

Sie können nun Backup-, Restore- und Klonvorgänge für SQL Server ausführen.

Backup der Datenbank mit SnapCenter

Nachdem Sie die Datenbank und die Protokolldateien auf den FSX ONTAP LUNs platziert haben, kann SnapCenter zum Sichern der Datenbanken verwendet werden. Mit den folgenden Prozessen wird ein vollständiges Backup erstellt.

Best Practices

In SnapCenter wird RPO als Backup-Häufigkeit identifiziert, beispielsweise wie oft das Backup geplant werden soll, damit sich der Datenverlust auf bis zu wenige Minuten reduzieren lässt. Mit SnapCenter lassen sich Backups alle fünf Minuten planen. Allerdings kann es einige Instanzen geben, in denen ein Backup während der Transaktionszeiten nicht innerhalb von fünf Minuten abgeschlossen wird, oder wenn die Änderungsrate der Daten in der gegebenen Zeit eher liegt. Als Best Practice empfiehlt es sich, häufige Transaktions-Log-Backups anstelle vollständiger Backups zu planen.
Es gibt zahlreiche Ansätze für RPO und RTO. Eine Alternative zu diesem Backup-Ansatz besteht darin, separate Backup-Richtlinien für Daten und Protokolle mit unterschiedlichen Intervallen zu verwenden. Von SnapCenter aus sollten Sie beispielsweise Backup-Protokolle in 15-Minuten-Intervallen planen und Daten-Backups in 6-Stunden-Intervallen durchführen.
Verwenden Sie eine Ressourcengruppe für eine Backup-Konfiguration zur Snapshot-Optimierung und zur Anzahl der zu verwaltenden Jobs.
1. Wählen Sie Ressourcen, und wählen Sie dann Microsoft SQL Server *im Dropdown-Menü oben links. Wählen Sie *Ressourcen Aktualisieren.
2. Wählen Sie die zu sichernde Datenbank aus, und wählen Sie dann Weiter und (*), um die Policy hinzuzufügen, falls noch keine Policy erstellt wurde. Befolgen Sie die * Neue SQL Server Backup Policy, um eine neue Richtlinie zu erstellen.
3. Wählen Sie ggf. den Überprüfungsserver aus. Dieser Server ist der Server, auf dem SnapCenter DBCC CHECKDB ausgeführt wird, nachdem eine vollständige Sicherung erstellt wurde. Klicken Sie auf Weiter, um eine Benachrichtigung zu erhalten, und wählen Sie zur Überprüfung Zusammenfassung. Klicken Sie nach der Überprüfung auf Fertig stellen.
4. Klicken Sie auf Jetzt sichern, um das Backup zu testen. Wählen Sie in den Popup-Fenstern die Option Backup aus.
5. Wählen Sie Monitor, um zu überprüfen, ob die Sicherung abgeschlossen wurde.

Best Practices

Sichern Sie das Transaktions-Log-Backup von SnapCenter, damit SnapCenter während des Wiederherstellungsprozesses alle Backup-Dateien lesen und automatisch nacheinander wiederherstellen kann.
Wenn Produkte von Drittanbietern für Backups verwendet werden, wählen Sie Backup in SnapCenter kopieren aus, um Probleme mit der Protokollsequenz zu vermeiden, und testen Sie die Wiederherstellungsfunktion, bevor Sie in die Produktion gehen.

Datenbank mit SnapCenter wiederherstellen

Einer der größten Vorteile von FSX ONTAP mit SQL Server auf EC2 ist die Möglichkeit, auf jeder Datenbankebene schnelle und granulare Wiederherstellungen durchzuführen.

Führen Sie die folgenden Schritte aus, um eine individuelle Datenbank auf einen bestimmten Zeitpunkt oder bis zu einer Minute mit SnapCenter wiederherzustellen.

Wählen Sie Ressourcen und dann die Datenbank aus, die Sie wiederherstellen möchten.
Wählen Sie den Backupnamen aus, von dem die Datenbank wiederhergestellt werden soll, und wählen Sie anschließend Wiederherstellen.
Folgen Sie den * Restore* Pop-up-Fenstern, um die Datenbank wiederherzustellen.
Wählen Sie Monitor, um zu überprüfen, ob der Wiederherstellungsprozess erfolgreich ist.

Überlegungen für eine Instanz mit einer großen Anzahl von Datenbanken kleiner bis großer Größe

SnapCenter kann eine große Anzahl an umfangreichen Datenbanken in einer Instanz oder Gruppe von Instanzen innerhalb einer Ressourcengruppe sichern. Die Größe einer Datenbank ist kein entscheidender Faktor für die Backup-Zeit. Die Dauer eines Backups kann je nach Anzahl der LUNs pro Volume, der Belastung von Microsoft SQL Server, der Gesamtzahl der Datenbanken pro Instanz und insbesondere der I/O-Bandbreite und -Nutzung variieren. Während Sie die Richtlinie für das Backup von Datenbanken aus einer Instanz oder Ressourcengruppe konfigurieren, empfiehlt NetApp, die maximal pro Snapshot-Kopie gesicherte Datenbank auf 100 pro Host einzuschränken. Stellen Sie sicher, dass die Gesamtzahl an Snapshot Kopien die Begrenzung von 1,023 Kopien nicht überschreitet.

NetApp empfiehlt zudem, die laufenden Backup-Jobs parallel zu begrenzen, indem Sie die Anzahl der Datenbanken gruppieren, anstatt für jede Datenbank oder jede Instanz mehrere Jobs zu erstellen. Für eine optimale Performance der Backup-Dauer ist die Anzahl der Backup-Jobs auf eine Anzahl reduziert, die rund 100 oder weniger Datenbanken gleichzeitig sichern kann.

Wie bereits erwähnt, ist die I/O-Nutzung ein wichtiger Faktor für den Backup-Prozess. Der Backup-Prozess muss warten, bis alle I/O-Vorgänge einer Datenbank abgeschlossen sind. Datenbanken mit sehr intensiven I/O-Vorgängen sollten auf eine andere Backup-Zeit zurückgestellt werden oder von anderen Backup-Jobs isoliert werden, um zu vermeiden, dass andere Ressourcen innerhalb derselben Ressourcengruppe, die gesichert werden soll, beeinträchtigt werden.

Setzen Sie für eine Umgebung mit sechs Microsoft SQL Server Hosts, die 200 Datenbanken pro Instanz hosten. Angenommen, vier LUNs pro Host und eine LUN pro erstelltem Volume sollten Sie die vollständige Backup-Richtlinie mit der maximalen Anzahl an Datenbanken, die pro Snapshot Kopie gesichert werden, auf 100 ein. Zweihundert Datenbanken auf jeder Instanz werden als 200 Datendateien verteilt auf zwei LUNs verteilt, und 200 Log-Dateien werden gleichmäßig auf zwei LUNs verteilt: 100 Dateien pro LUN pro Volume.

Planen Sie drei Backup-Jobs, indem Sie drei Ressourcengruppen erstellen, wobei jeweils zwei Instanzen mit insgesamt 400 Datenbanken gruppiert werden.

Alle drei Backup-Jobs werden parallel ausgeführt und sichern gleichzeitig 1,200 Datenbanken. Abhängig von der Last für den Server und der I/O-Nutzung können die Start- und Endzeit jeder Instanz variieren. In dieser Instanz werden insgesamt 24 Snapshot Kopien erstellt.

Zusätzlich zum vollständigen Backup empfiehlt NetApp, ein Transaktions-Log-Backup für kritische Datenbanken zu konfigurieren. Stellen Sie sicher, dass die Datenbankeigenschaft auf ein vollständiges Recovery-Modell eingestellt ist.

Best Practices

Nehmen Sie die tempdb-Datenbank nicht in ein Backup auf, da die darin enthaltenen Daten temporär sind. Platzieren Sie tempdb auf eine LUN oder eine SMB-Freigabe, die sich in einem Storage-System-Volume befindet, in dem keine Snapshot Kopien erstellt werden.
Eine Microsoft SQL Server Instanz mit einer hohen I/O-intensiven Applikation sollte in einem anderen Backup-Job isoliert werden, um die gesamte Backup-Zeit für andere Ressourcen zu reduzieren.
Begrenzen Sie die Anzahl der Datenbanken, die gleichzeitig auf etwa 100 gesichert werden sollen, und Staffeln Sie die übrigen Datenbank-Backups, um einen gleichzeitigen Prozess zu vermeiden.
Verwenden Sie den Instanznamen für Microsoft SQL Server in der Ressourcengruppe anstelle mehrerer Datenbanken, da SnapCenter beim Erstellen neuer Datenbanken in der Microsoft SQL Server-Instanz automatisch eine neue Datenbank für das Backup berücksichtigt.
Wenn Sie die Datenbankkonfiguration ändern, wie beispielsweise das Datenbank-Recovery-Modell in das vollständige Recovery-Modell ändern, führen Sie sofort ein Backup durch, um up-to-the-minute-Wiederherstellungsvorgänge zu ermöglichen.
SnapCenter kann Transaktions-Log-Backups, die außerhalb von SnapCenter erstellt wurden, nicht wiederherstellen.
Stellen Sie beim Klonen von FlexVol Volumes sicher, dass ausreichend Speicherplatz für die Klon-Metadaten vorhanden ist.
Stellen Sie beim Wiederherstellen von Datenbanken sicher, dass auf dem Volume ausreichend Speicherplatz verfügbar ist.
Erstellen einer separaten Richtlinie für das Management und die Sicherung von Systemdatenbanken mindestens einmal pro Woche

Klonen von Datenbanken mit SnapCenter

Um eine Datenbank an einem anderen Standort in einer Entwicklungs- oder Testumgebung oder zur Erstellung einer Kopie für geschäftliche Analysen zu wiederherstellen, empfiehlt NetApp die Nutzung der Cloning-Methodik, um eine Kopie der Datenbank auf derselben Instanz oder einer alternativen Instanz zu erstellen.

Das Klonen von Datenbanken, die 500 GB auf einer iSCSI-Festplatte sind, die auf einer FSX für ONTAP-Umgebung gehostet wird, dauert normalerweise weniger als fünf Minuten. Nach Abschluss des Klonens kann der Benutzer anschließend alle erforderlichen Lese-/Schreibvorgänge für die geklonte Datenbank ausführen. Die meiste Zeit wird für das Scannen von Festplatten benötigt (diskpart). Das Klonverfahren von NetApp dauert unabhängig von der Größe der Datenbanken normalerweise weniger als 2 Minuten.

Das Klonen einer Datenbank kann mit der dualen Methode durchgeführt werden: Sie können einen Klon aus dem letzten Backup erstellen oder das Lebenszyklusmanagement von Klonen verwenden, mit dem die neueste Kopie auf der sekundären Instanz zur Verfügung gestellt werden kann.

SnapCenter ermöglicht Ihnen, die Klonkopie auf der erforderlichen Festplatte zu mounten, um das Format der Ordnerstruktur auf der sekundären Instanz beizubehalten und Backup-Jobs weiterhin zu planen.

Klonen von Datenbanken auf den neuen Datenbanknamen in derselben Instanz

Mit den folgenden Schritten können Datenbanken in derselben SQL Server Instanz geklont werden, die auf EC2 ausgeführt wird:

Wählen Sie Ressourcen und dann die Datenbank aus, die geklont werden soll.
Wählen Sie den Backup-Namen aus, den Sie klonen möchten, und wählen Sie Clone aus.
Befolgen Sie die Anweisungen zum Klonen im Backup-Fenster, um den Klonprozess abzuschließen.
Wählen Sie Überwachen, um sicherzustellen, dass das Klonen abgeschlossen ist.

Klonen von Datenbanken in der neuen SQL Server-Instanz, die auf EC2 ausgeführt wird

Mit dem folgenden Schritt werden Datenbanken zu der neuen SQL Server-Instanz geklont, die auf EC2 läuft:

Einen neuen SQL Server auf EC2 in derselben VPC erstellen.
Aktivieren Sie das iSCSI-Protokoll und MPIO, und richten Sie dann die iSCSI-Verbindung zu FSX für ONTAP ein, indem Sie Schritt 3 und 4 im Abschnitt „Volumes und LUNs für SQL Server erstellen“ befolgen.
Fügen Sie einen neuen SQL Server auf EC2 in SnapCenter durch folgen Sie Schritt 3 im Abschnitt „Installieren und Einrichten für SnapCenter.“
Wählen Sie Ressource > Instanz anzeigen, und wählen Sie Ressource aktualisieren.
Wählen Sie Ressourcen und dann die Datenbank aus, die Sie klonen möchten.
Wählen Sie den Backup-Namen aus, den Sie klonen möchten, und wählen Sie dann Klonen aus.
Befolgen Sie die Anweisungen zum Klonen aus Backup, indem Sie die neue SQL Server Instanz auf EC2 und den Instanznamen angeben, um den Klonprozess abzuschließen.
Wählen Sie Überwachen, um sicherzustellen, dass das Klonen abgeschlossen ist.

Sehen Sie sich das folgende Video an, um mehr über diesen Prozess zu erfahren:

Klonen von Datenbanken in der neuen SQL Server-Instanz, die auf EC2 ausgeführt wird

Anhänge

Anhang A: YAML-Datei zur Verwendung in Cloud-Formationsvorlage

Die folgende .yaml-Datei kann mit der Cloud-Formationsvorlage in der AWS-Konsole verwendet werden.

"https://github.com/NetApp/fsxn-iscsisetup-cft"

Um DIE ISCSI-LUN-Erstellung und die NetApp SnapCenter-Installation mit PowerShell zu automatisieren, klonen Sie die repo von "Dieser GitHub-Link".

Anhang B: PowerShell Skripte für die Bereitstellung von Volumes und LUNs

Das folgende Skript wird verwendet, um Volumes und LUNs bereitzustellen und iSCSI auf der Grundlage der oben angegebenen Anleitung einzurichten. Es gibt zwei PowerShell Skripte:

_EnableMPIO.ps1

Function Install_MPIO_ssh {
    $hostname = $env:COMPUTERNAME
    $hostname = $hostname.Replace('-','_')

    #Add schedule action for the next step
    $path = Get-Location
    $path = $path.Path + '\2_CreateDisks.ps1'
    $arg = '-NoProfile -WindowStyle Hidden -File ' +$path
    $schAction = New-ScheduledTaskAction -Execute "Powershell.exe" -Argument $arg
    $schTrigger = New-ScheduledTaskTrigger -AtStartup
    $schPrincipal = New-ScheduledTaskPrincipal -UserId "NT AUTHORITY\SYSTEM" -LogonType ServiceAccount -RunLevel Highest
    $return = Register-ScheduledTask -Action $schAction -Trigger $schTrigger -TaskName "Create Vols and LUNs" -Description "Scheduled Task to run configuration Script At Startup" -Principal $schPrincipal
    #Install -Module Posh-SSH
    Write-host 'Enable MPIO and SSH for PowerShell' -ForegroundColor Yellow
    $return = Find-PackageProvider -Name 'Nuget' -ForceBootstrap -IncludeDependencies
    $return = Find-Module PoSH-SSH | Install-Module -Force
    #Install Multipath-IO with PowerShell using elevated privileges in Windows Servers
    Write-host 'Enable MPIO' -ForegroundColor Yellow
    $return = Install-WindowsFeature -name Multipath-IO -Restart
}
Install_MPIO_ssh
Remove-Item -Path $MyInvocation.MyCommand.Source

_CreateDisks.ps1

....
#Enable MPIO and Start iSCSI Service
Function PrepISCSI {
    $return = Enable-MSDSMAutomaticClaim -BusType iSCSI
    #Start iSCSI service with PowerShell using elevated privileges in Windows Servers
    $return = Start-service -Name msiscsi
    $return = Set-Service -Name msiscsi -StartupType Automatic
}
Function Create_igroup_vols_luns ($fsxN){
    $hostname = $env:COMPUTERNAME
    $hostname = $hostname.Replace('-','_')
    $volsluns = @()
    for ($i = 1;$i -lt 10;$i++){
        if ($i -eq 9){
            $volsluns +=(@{volname=('v_'+$hostname+'_log');volsize=$fsxN.logvolsize;lunname=('l_'+$hostname+'_log');lunsize=$fsxN.loglunsize})
        } else {
            $volsluns +=(@{volname=('v_'+$hostname+'_data'+[string]$i);volsize=$fsxN.datavolsize;lunname=('l_'+$hostname+'_data'+[string]$i);lunsize=$fsxN.datalunsize})
        }
    }
    $secStringPassword = ConvertTo-SecureString $fsxN.password -AsPlainText -Force
    $credObject = New-Object System.Management.Automation.PSCredential ($fsxN.login, $secStringPassword)
    $igroup = 'igrp_'+$hostname
    #Connect to FSx N filesystem
    $session = New-SSHSession -ComputerName $fsxN.svmip -Credential $credObject -AcceptKey:$true
    #Create igroup
    Write-host 'Creating igroup' -ForegroundColor Yellow
    #Find Windows initiator Name with PowerShell using elevated privileges in Windows Servers
    $initport = Get-InitiatorPort | select -ExpandProperty NodeAddress
    $sshcmd = 'igroup create -igroup ' + $igroup + ' -protocol iscsi -ostype windows -initiator ' + $initport
    $ret = Invoke-SSHCommand -Command $sshcmd -SSHSession $session
    #Create vols
    Write-host 'Creating Volumes' -ForegroundColor Yellow
    foreach ($vollun in $volsluns){
        $sshcmd = 'vol create ' + $vollun.volname + ' -aggregate aggr1 -size ' + $vollun.volsize #+ ' -vserver ' + $vserver
        $return = Invoke-SSHCommand -Command $sshcmd -SSHSession $session
    }
    #Create LUNs and mapped LUN to igroup
    Write-host 'Creating LUNs and map to igroup' -ForegroundColor Yellow
    foreach ($vollun in $volsluns){
        $sshcmd = "lun create -path /vol/" + $vollun.volname + "/" + $vollun.lunname + " -size " + $vollun.lunsize + " -ostype Windows_2008 " #-vserver " +$vserver
        $return = Invoke-SSHCommand -Command $sshcmd -SSHSession $session
        #map all luns to igroup
        $sshcmd = "lun map -path /vol/" + $vollun.volname + "/" + $vollun.lunname + " -igroup " + $igroup
        $return = Invoke-SSHCommand -Command $sshcmd -SSHSession $session
    }
}
Function Connect_iSCSI_to_SVM ($TargetPortals){
    Write-host 'Online, Initialize and format disks' -ForegroundColor Yellow
    #Connect Windows Server to svm with iSCSI target.
    foreach ($TargetPortal in $TargetPortals) {
        New-IscsiTargetPortal -TargetPortalAddress $TargetPortal
        for ($i = 1; $i -lt 5; $i++){
            $return = Connect-IscsiTarget -IsMultipathEnabled $true -IsPersistent $true -NodeAddress (Get-iscsiTarget | select -ExpandProperty NodeAddress)
        }
    }
}
Function Create_Partition_Format_Disks{

    #Create Partion and format disk
    $disks = Get-Disk | where PartitionStyle -eq raw
    foreach ($disk in $disks) {
        $return = Initialize-Disk $disk.Number
        $partition = New-Partition -DiskNumber $disk.Number -AssignDriveLetter -UseMaximumSize | Format-Volume -FileSystem NTFS -AllocationUnitSize 65536 -Confirm:$false -Force
        #$return = Format-Volume -DriveLetter $partition.DriveLetter -FileSystem NTFS -AllocationUnitSize 65536
    }
}
Function UnregisterTask {
    Unregister-ScheduledTask -TaskName "Create Vols and LUNs" -Confirm:$false
}
Start-Sleep -s 30
$fsxN = @{svmip ='198.19.255.153';login = 'vsadmin';password='net@pp11';datavolsize='10GB';datalunsize='8GB';logvolsize='8GB';loglunsize='6GB'}
$TargetPortals = ('10.2.1.167', '10.2.2.12')
PrepISCSI
Create_igroup_vols_luns $fsxN
Connect_iSCSI_to_SVM $TargetPortals
Create_Partition_Format_Disks
UnregisterTask
Remove-Item -Path $MyInvocation.MyCommand.Source
....

Führen Sie die Datei aus EnableMPIO.ps1 Zuerst und das zweite Skript wird automatisch ausgeführt, nachdem der Server neu gestartet wurde. Diese PowerShell Skripte können aufgrund von Berechtigungen für den SVM entfernt werden, nachdem sie ausgeführt wurden.