Auf dieser Seite finden Sie Details zur Anwendungsresilienz von Google Cloud NetApp Volumes.
Überlegungen zur Ausfallsicherheit von Anwendungen
Obwohl NetApp Volumes hochverfügbar ist, können geplante Wartungsereignisse wie Plattform-, Dienst- oder Software-Upgrades oder ungeplante Komponentenausfälle im Dienst zu kurzen Pausen bei Ein- und Ausgabevorgängen (E/A) führen.
E/A-Pausen
Die Clientsoftware für Network File System (NFS), Server Message Block (SMB) und iSCSI in Ihrem Betriebssystem verarbeitet kurze E/A-Pausen. Der Client wartet und wiederholt die E/A-Vorgänge, ohne das Problem an die Anwendung zu melden. Solche kurzen Pausen gelten als nicht störend, da die Nutzer der Anwendung zwar längere Reaktionszeiten sehen, die Anwendung aber keine E/A-Fehler meldet.
Bei längeren E/A-Pausen hängt das Verhalten vom NFS-, SMB- oder iSCSI-Client Ihres Betriebssystems und von möglichen in der Anwendung konfigurierten Zeitüberschreitungen ab. In den folgenden Abschnitten werden protokollspezifische Details für E/A-Pausen erläutert.
NFS-E/A-Pausen
Alle Aufrufe einer nicht verfügbaren, fest eingebundenen NFS-Freigabe werden im NFS-Client blockiert und warten auf unbestimmte Zeit, bis der NFS-Server wieder antwortet. Während Ihr NFS-Client wartet, werden in den Client-Logs Meldungen angezeigt, die darauf hinweisen, dass der NFS-Server nicht reagiert.
Aus Anwendungssicht werden E/A-Vorgänge wie Lese- oder Schreibvorgänge blockiert und bleiben ausstehend, bis die NFS-Freigabe erfolgreich zurückgegeben wird. Während E/A-Pausen geht kein E/A-Vorgang verloren und NetApp Volumes sorgt für Datenkonsistenz, sofern Sie ausstehende E/A-Vorgänge nicht auf Clientseite erzwingen.
Cluster-Softwareanwendungen zum Automatisieren von Failovers verwenden
Wenn Sie Cluster-Softwareanwendungen wie Pacemaker auf den Client-VMs verwenden, um das Failover Ihrer Anwendung zu automatisieren, konfigurieren Sie die Zeitüberschreitungen für NFS-Freigaben so, dass sie Wartungsereignisse für NetApp-Volumes überstehen. Bei solchen Failovers werden ausstehende E/A-Vorgänge auf dem Client abgebrochen, was zu verlorenen Transaktionen führen kann. Wir empfehlen die folgenden Zeitüberschreitungen:
| Protokolltyp | Empfohlenes Zeitlimit | Hinweise |
|---|---|---|
| NFSv3-Freigaben | 60 Sekunden (für die Service-Levels „Standard“, „Premium“ und „Extreme“)
120 Sekunden (für den Service-Level „Flex“) |
Wir empfehlen, eine Fencing-Methode zu verwenden, bei der die Bereitstellungsoption nolock anstelle von NFS-Sperren verwendet wird. |
| NFSv4.1 | 105 Sekunden (für die Service-Levels „Standard“, „Premium“ und „Extreme“)
165 Sekunden (für den Service-Level „Flex“) |
Das NFSv4.1-Protokoll fügt automatisch zuverlässige Sperren über NFSv3 hinzu (NFSv4.x RFC, Abschnitt 9.6.2), die Sie als Fencing-Mechanismus verwenden können. Die Wiederherstellung des Schlossstatus dauert zusätzlich 45 Sekunden. |
SMB-Freigabe – E/A-Pausen
Im Gegensatz zu NFS verwenden SMB-Sitzungen eine Verbindung, deren Zeit abgelaufen sein kann. NetApp Volumes überschreitet in den meisten Fällen keine Zeitlimits.
Zeitüberschreitungen bei Sitzungen
Das Sitzungs-Zeitlimit wird auf dem Client definiert. Das Standardzeitlimit für Windows-Clients beträgt 60 Sekunden. Sie können den Befehl Get-SmbClientConfiguration/Set-SmbClientConfiguration mit dem Parameter SessionTimeout ausführen, um das Sitzungstimeout zu lesen oder zu ändern.
Wenn eine Sitzungszeitüberschreitung auftritt, wird die SMB-Sitzung unterbrochen und der Anwendung, die die E/A-Vorgänge ausführt, wird ein E/A-Fehler gemeldet. Der Datei-Explorer oder Microsoft 365-Anwendungen stellen in der Regel eine neue Verbindung her, sobald der Nutzer wieder auf die SMB-Freigabe zugreift. Bei E/A-Fehlern versuchen einige Anwendungen, die Verbindung wiederherzustellen und den fehlgeschlagenen E/A-Vorgang noch einmal auszuführen, andere nicht. In der Dokumentation des Anwendungsanbieters finden Sie Informationen dazu, wie die Anwendung SMB-Timeouts verarbeitet und wie sie auf SMB-Freigaben resilient arbeiten kann.
Kontinuierlich verfügbare (CA) Freigaben sind eine SMB3.x-Funktion, die die Failover-Resilienz für datenbankähnliche Anwendungen verbessert. NetApp Volumes unterstützt kontinuierlich verfügbare Freigaben für Microsoft SQL Server und FSLogix.
Die Fehlerbehebung wird mit jeder neuen SMB-Version verbessert. NetApp Volumes unterstützt SMB 2.1, 3.0 und 3.1.1. Verwenden Sie nach Möglichkeit die neueste unterstützte SMB-Version. Windows 10/Server 2016 und höher unterstützen die aktuelle SMB-Version 3.1.1.
Anwendungsbasierte Vorsichtsmaßnahmen für kleine und mittelständische Unternehmen
Für bestimmte SMB-basierte Anwendungen ist SMB Transparent Failover erforderlich. Das transparente Failover von SMB ermöglicht Wartungsvorgänge für SMB-Volumes in NetApp-Volumes, ohne die Verbindung zu Serveranwendungen zu unterbrechen, die Daten speichern und darauf zugreifen. NetApp Volumes unterstützt die Option der Continuous Availability (CA)-Freigaben von SMB, um sicherzustellen, dass bestimmte Anwendungen das transparente Failover von SMB unterstützen. Die Verwendung von kontinuierlich verfügbaren SMB-Freigaben wird nur für die folgenden Arbeitslasten unterstützt:
FSLogix-Nutzerprofilcontainer
Microsoft SQL Server (nicht Linux SQL Server)
Kontinuierlich verfügbare SMB-Freigaben unterstützen keine benutzerdefinierten Anwendungen.
iSCSI-E/A-Pausen
Sowohl in Linux- als auch in Windows-Umgebungen werden E/A-Pausen von iSCSI-Clients (Initiatoren) durch Wiederholen von Befehlen behandelt, bis das Ziel (NetApp Volumes) wieder verfügbar ist. Bei kurzen Wartungsereignissen versucht der iSCSI-Initiator, die Verbindung wiederherzustellen und ausstehende E/A-Vorgänge fortzusetzen. So wird die Anwendungsresilienz aufrechterhalten.
iSCSI-Zeitüberschreitungen
Die richtige Konfiguration von iSCSI-Timeouts ist unerlässlich, um die Anwendungsresilienz bei Wartungsereignissen oder unerwarteten Dienstunterbrechungen aufrechtzuerhalten.
Auf Linux-Systemen werden für NetApp Volumes die Standardeinstellungen für iSCSI-Initiatoren verwendet. Diese Einstellungen umfassen NetApp-spezifische Konfigurationen innerhalb des standardmäßigen Linux Device Mapper Multipath, der Timeout-Anforderungen während Wartungsereignissen für NetApp-Volumes automatisch verwaltet.
Bei Windows-Systemen müssen Sie jedoch die Windows-MPIO-Einstellungen mit dem folgenden Befehl ändern, um die Wartungsereignisse für NetApp-Volumes zu verarbeiten.
Set-MPIOSetting -NewPathVerificationState Enabled ` -NewPDORemovePeriod 130 ` -NewRetryCount 6 ` -CustomPathRecovery Enabled ` -NewPathRecoveryInterval 30 `
Während E/A-Pausen wiederholt der iSCSI-Initiator Befehle und behält ausstehende E/A-Vorgänge für die Dauer des Timeouts bei. Wenn das Zeitlimit überschritten wird, meldet das Betriebssystem möglicherweise E/A-Fehler an die Anwendung, was zu verlorenen Transaktionen führen oder eine Wiederherstellung auf Anwendungsebene erfordern kann.
Überlegungen zu Anwendungen und Clustern
Wenn Sie Clustering-Software oder Anwendungen verwenden, die Failover automatisieren, konfigurieren Sie Ihre iSCSI-Timeouts so, dass sie Wartungsereignisse für NetApp-Volumes berücksichtigen. Ein vorzeitiges Failover kann ausstehende E/A-Vorgänge abbrechen und zu Daten- oder Transaktionsverlust führen. Informationen zu Best Practices für iSCSI-Timeout-Einstellungen finden Sie immer in der Dokumentation Ihrer Anwendung und Ihres Betriebssystems.
Anwendungsunterbrechungen im Zusammenhang mit Wartungsereignissen
Geplante Wartungsereignisse wie Plattform- und Dienstsoftware-Upgrades können gelegentlich auftreten. Wartungsereignisse gelten aus Sicht des Dateiprotokolls (NFS oder SMB) als nicht störend, sofern die Anwendung die E/A-Pausen verarbeiten kann, die während dieser Ereignisse auftreten können.
Bei den Service-Levels „Standard“, „Premium“ und „Extreme“ sind die E/A-Pausen in der Regel kurz und dauern einige Sekunden bis zu 30 Sekunden.
Beim Service-Level „Flex“ können die E/A-Pausen bis zu 70 Sekunden dauern.
Nächste Schritte
Sicherheitsaspekte für Google Cloud NetApp Volumes