Auf dieser Seite wird die Ausfallsicherheit von Anwendungen für Google Cloud NetApp Volumes beschrieben und wie NFS-, SMB- und iSCSI-Clients mit E/A-Pausen umgehen. Obwohl NetApp Volumes hochverfügbar ist, können E/A-Vorgänge während geplanter Wartungsarbeiten oder ungeplanter Dienstereignisse kurz pausieren. Auf dieser Seite werden auch Timeout-Einstellungen empfohlen, um einen reibungslosen Anwendungsbetrieb zu gewährleisten, insbesondere wenn Sie Cluster-Software wie Pacemakerverwenden.
Überlegungen zur Ausfallsicherheit von Anwendungen
Obwohl NetApp Volumes hochverfügbar ist, können geplante Wartungsereignisse wie Plattformupdates, Dienstupgrades, Softwareupgrades oder ungeplante Komponentenausfälle im Dienst zu kurzen Pausen bei Eingabe- und Ausgabevorgängen (E/A) führen.
Weitere Informationen zu geplanten Wartungsereignissen und ungeplanten Dienst ausfällen finden Sie unter Wartungsereignisse überwachen und planen.
Weitere Informationen dazu, wie sich diese Wartungsereignisse auf den Status von Speicherpools auswirken, finden Sie unter Status von Speicherpools.
E/A-Pausen
Die Network File System (NFS)-, Server Message Block (SMB)- und iSCSI-Clientsoftware in Ihrem Betriebssystem verarbeitet kurze E/A-Pausen. Der Client wartet und wiederholt die E/A-Vorgänge, ohne das Problem an die Anwendung weiterzugeben. 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 potenziellen Timeouts ab, die in der Anwendung konfiguriert sind. In den folgenden Abschnitten werden protokollspezifische Details zu E/A-Pausen erläutert.
NFS-E/A-Pausen
Alle Aufrufe an eine nicht verfügbare, fest bereitgestellte NFS-Freigabe werden im NFS-Client blockiert und warten unbegrenzt, bis der NFS-Server wieder antwortet. Während Ihr NFS-Client wartet, werden in Ihren Clientlogs Meldungen angezeigt, die darauf hinweisen, dass der NFS-Server nicht antwortet.
Aus Anwendungssicht werden E/A-Vorgänge wie Lesen oder Schreiben blockiert und bleiben ausstehend, bis die NFS-Freigabe wieder verfügbar ist. Während E/A-Pausen gehen keine E/A-Vorgänge verloren und NetApp Volumes sorgt für Datenkonsistenz, es sei denn, Sie beenden ausstehende E/A-Vorgänge auf Clientseite gewaltsam.
Cluster-Softwareanwendungen zur Automatisierung von Failovern verwenden
Wenn Sie Cluster-Softwareanwendungen wie Pacemaker auf den Client-VMs verwenden, um das Failover Ihrer Anwendung zu automatisieren, konfigurieren Sie Ihre Timeouts für NFS-Freigaben so, dass sie Wartungsereignisse von NetApp Volumes überstehen. Bei solchen Failovern werden ausstehende E/A-Vorgänge auf dem Client abgebrochen und es kann zu Transaktionsverlusten kommen. Wir empfehlen die folgenden Timeouts:
| Protokolltyp | Empfohlenes Timeout | Hinweise |
|---|---|---|
| NFSv3-Freigaben | 60 Sekunden (für die Unified-Service-Levels Standard, Premium, Extreme und Flex)
120 Sekunden (für das Service-Level Flex File) |
Wir empfehlen, eine Fencing-Methode zu verwenden, bei der die
nolock Bereitstellungsoption anstelle von NFS-Sperren verwendet wird. |
| NFSv4.1 | 105 Sekunden (für die Unified-Service-Levels Standard, Premium, Extreme und Flex)
165 Sekunden (für das Service-Level Flex File) |
Das NFSv4.1-Protokoll fügt automatisch eine zuverlässige Sperrung über NFSv3 hinzu (NFSv4.x RFC, Abschnitt 9.6.2), die Sie als Fencing-Mechanismus verwenden können. Die Wiederherstellung des Sperrstatus dauert zusätzlich 45 Sekunden. |
E/A-Pausen bei SMB-Freigaben
Im Gegensatz zu NFS verwenden SMB-Sitzungen eine Verbindung, bei der ein Timeout auftreten kann. Bei NetApp Volumes werden Timeouts in der Regel vermieden.
Sitzungstimeouts
Das Sitzungstimeout wird auf dem Client definiert. Das Standardtimeout 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 ein Sitzungstimeout auftritt, wird die SMB-Sitzung unterbrochen und ein E/A-Fehler wird an die Anwendung gemeldet, die die E/A-Vorgänge ausführt. 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 zu wiederholen, während andere dies nicht tun. In der Dokumentation des Anwendungsanbieters erfahren Sie, wie die Anwendung mit SMB-Timeouts umgeht und wie sie auf SMB-Freigaben ausfallsicher funktioniert.
Kontinuierlich verfügbare (CA) Freigaben sind eine SMB3.x-Funktion, die die Failover-Ausfallsicherheit 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 neueste SMB-Version 3.1.1.
SMB-basierte Vorsichtsmaßnahmen für Anwendungen
Für bestimmte SMB-basierte Anwendungen ist ein transparentes SMB-Failover erforderlich. Das transparente SMB-Failover 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 für kontinuierlich verfügbare SMB-Freigaben, um sicherzustellen, dass bestimmte Anwendungen das transparente SMB-Failover 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 werden für benutzerdefinierte Anwendungen nicht unterstützt.
iSCSI-E/A-Pausen
In Linux- und Windows-Umgebungen verarbeiten iSCSI-Clients (Initiatoren) E/A-Pausen, indem sie Befehle wiederholen, bis das Ziel (NetApp Volumes) verfügbar ist. Bei kurzen Wartungsereignissen versucht der iSCSI-Initiator, die Verbindung wiederherzustellen und ausstehende E/A-Vorgänge fortzusetzen, was zur Ausfallsicherheit der Anwendung beiträgt.
iSCSI-Timeouts
Die richtige Konfiguration von iSCSI-Timeouts ist entscheidend, um die Ausfallsicherheit der Anwendung bei Wartungsereignissen oder unerwarteten Dienstunterbrechungen aufrechtzuerhalten.
Für Linux-Systeme verwendet NetApp Volumes die Standardeinstellungen für den iSCSI-Initiator. Diese Einstellungen umfassen NetApp-spezifische Konfigurationen im standardmäßigen Linux Device Mapper Multipath, der die Timeout-Anforderungen während Wartungsereignissen von NetApp Volumes automatisch verwaltet.
Bei Windows-Systemen müssen Sie jedoch die Windows MPIO-Einstellungen mit dem folgenden Befehl ändern, um die Wartungsereignisse von 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 Timeout überschritten wird, meldet das Betriebssystem möglicherweise E/A-Fehler an die Anwendung, was zu Transaktionsverlusten führen oder eine Wiederherstellung auf Anwendungsebene erfordern kann.
Überlegungen zu Anwendungen und Clustern
Wenn Sie Clustering-Software oder Anwendungen verwenden, die das Failover automatisieren, konfigurieren Sie Ihre iSCSI-Timeouts so, dass sie Wartungsereignisse von NetApp Volumes berücksichtigen. Ein vorzeitiges Failover kann ausstehende E/A-Vorgänge abbrechen und zu Daten- oder Transaktionsverlusten führen. Die Best Practices für iSCSI-Timeout-Einstellungen finden Sie in der Dokumentation Ihrer Anwendung und Ihres Betriebssystems.
Anwendungsunterbrechungen im Zusammenhang mit Wartungsereignissen
Geplante Wartungsereignisse wie Plattformupgrades und Dienstsoftwareupgrades können gelegentlich auftreten. Wartungsereignisse gelten aus Sicht des Dateiprotokolls (NFS oder SMB) als nicht störend, solange 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 dauern die E/A-Pausen bis zu 70 Sekunden.
Weitere Informationen dazu, wie sich diese Wartungsereignisse auf den Status von Speicherpools auswirken, finden Sie unter Status von Speicherpools.
Nächste Schritte
Informationen zu Sicherheitsüberlegungen für Google Cloud NetApp Volumes Sicherheitsüberlegungen