Häufig gestellte Fragen zur Anwendungsresilienz in Azure NetApp Files
In diesem Artikel werden häufig gestellte Fragen (FAQs) zur Anwendungsresilienz in Azure NetApp Files beantwortet.
Was empfehlen Sie für die Behandlung potenzieller Anwendungsunterbrechungen aufgrund von Wartungsereignissen des Speicherdiensts?
Azure NetApp Files kann gelegentlich geplant gewartet werden (z. B. Plattformupdates, Dienst- oder Softwareupgrades). Aus sicht eines Dateiprotokolls (NFS/SMB) sind die Standard Tenance-Vorgänge nicht unterbrochen, solange die Anwendung die E/A-Pausen verarbeiten kann, die während dieser Ereignisse kurz auftreten können. Die E/A-Pausen sind für gewöhnlich kurz, zwischen ein paar Sekunden bis zu 30 Sekunden. Das NFS-Protokoll ist besonders robust, und Client-Server-Dateivorgänge werden normal fortgesetzt. Einige Anwendungen erfordern möglicherweise eine Optimierung, um E/A-Pausen von bis zu 30 bis 45 Sekunden zu verarbeiten. Stellen Sie daher sicher, dass Sie die Resilienzeinstellungen der Anwendung kennen, um mit den Wartungsereignissen der Speicherdienste umgehen zu können. Für interaktive Anwendungen, die das SMB-Protokoll nutzen, reichen die Standardprotokolleinstellungen in der Regel aus.
Wichtig
Um eine robuste Architektur zu gewährleisten, ist es wichtig zu erkennen, dass die Cloud unter einem Modell für gemeinsame Verantwortung arbeitet. Dieses Modell umfasst die Azure-Cloudplattform, ihre Infrastrukturdienste, die Betriebssystemebene und Anwendungsanbieter. Jede dieser Komponenten spielt eine wichtige Rolle bei der ordnungsgemäßen Behandlung potenzieller Anwendungsunterbrechungen, die während des Speicherdiensts auftreten können, Standard abwendungsereignisse auftreten können.
Muss ich besondere Vorsichtsmaßnahmen für SMB-basierte Apps treffen?
Ja, für bestimmte SMB-basierte Apps ist SMB Transparent Failover erforderlich. SMB Transparent Failover ermöglicht Wartungsvorgänge für den Azure NetApp Files-Dienst ohne Unterbrechung der Verbindung mit Serveranwendungen, die Daten auf SMB-Volumes speichern und auf diese Daten zugreifen. Zur Unterstützung von SMB Transparent Failover für bestimmte Apps unterstützt Azure NetApp Files jetzt die Freigabe-Option für SMB Continuous Availability. Die Verwendung der kontinuierlichen Verfügbarkeit von SMB wird nur für Workloads unterstützt:
- Citrix App Layering
- FSLogix-Benutzerprofilcontainer
- FSLogix ODFC-Container
- Microsoft SQL Server (nicht Linux SQL Server)
- MSIX-Feature zum Anfügen von Apps
Achtung
Benutzerdefinierte Anwendungen werden mit SMB Continuous Availability nicht unterstützt und können nicht mit aktivierten Volumes für die kontinuierliche SMB-Verfügbarkeit verwendet werden.
Ich führe IBM MQ auf Azure NetApp Files aus. Welche Vorsichtsmaßnahmen kann ich ergreifen, um Unterbrechungen aufgrund von Wartungsereignissen des Speicherdiensts zu vermeiden, obwohl ich das NFS-Protokoll verwende?
Wenn Sie die IBM MQ-App in einer Konfiguration mit freigegebenen Dateien nutzen, in der die IBM MQ-Daten und -Protokolle auf einem Azure NetApp Files-Volume gespeichert werden, folgen Sie diesen Empfehlungen, um die Resilienz bei Wartungsereignissen des Speicherdiensts zu verbessern:
- Sie dürfen nur das NFS V4.1-Protokoll verwenden.
- Sie sollten eine IBM MQ-Konfiguration mit mehreren Instanzen, die freigegebene NFS V4.1-Volumes nutzt, für Hochverfügbarkeit verwenden.
- Sie sollten die Funktionalität der IBM-Konfiguration mit mehreren Instanzen, die freigegebene NFS V4.1-Volumes nutzt, überprüfen.
- Sie sollten eine IBM MQ-Architektur mit horizontaler Skalierung einführen, anstatt eine große IBM MQ-Konfiguration mit mehreren Instanzen zu verwenden. Durch das Verteilen der Nachrichtenverarbeitungslast auf mehrere IBM MQ-Paare mit mehreren Instanzen kann die Wahrscheinlichkeit von Dienstunterbrechungen verringert werden, da jedes MQ-Paar mit mehreren Instanzen weniger Nachrichten verarbeiten muss.
Hinweis
Die Anzahl der Nachrichten, die jedes MQ-Paar mit mehreren Instanzen verarbeiten sollte, hängt stark von Ihrer spezifischen Umgebung ab. Sie müssen entscheiden, wie viele MQ-Paare mit mehreren Instanzen benötigt werden, oder wie die Regeln zum Hoch- oder Herunterskalieren lauten werden.
Die Architektur für die horizontale Skalierung besteht aus mehreren IBM MQ-Paaren mit mehreren Instanzen, die hinter einem Azure Load Balancer bereitgestellt werden. Apps, die für die Kommunikation mit IBM MQ konfiguriert sind, werden dann für die Kommunikation mit den IBM MQ-Instanzen über Azure Load Balancer konfiguriert. Um Unterstützung im Zusammenhang mit IBM MQ auf freigegebenen NFS-Volumes zu erhalten, wenden Sie sich an den Anbietersupport bei IBM.
Ich führe Apache ActiveMQ mit LevelDB oder KahaDB auf Azure NetApp Files aus. Welche Vorsichtsmaßnahmen kann ich ergreifen, um Unterbrechungen aufgrund von Wartungsereignissen des Speicherdiensts zu vermeiden, obwohl ich das NFS-Protokoll verwende?
Wenn Sie Apache ActiveMQ ausführen, wird empfohlen, ActiveMQ-Hochverfügbarkeit mit Pluggable Storage Lockers bereitzustellen.
ActiveMQ-Hochverfügbarkeitsmodelle (HA-Modelle) stellen sicher, dass stets eine Brokerinstanz online ist und den Nachrichtendatenverkehr verarbeiten kann. Bei den beiden häufigsten ActiveMQ-HA-Modellen muss ein Dateisystem über ein Netzwerk geteilt werden. Der Zweck ist die Bereitstellung von LevelDB oder KahaDB für die aktiven und passiven Brokerinstanzen. Diese HA-Modelle erfordern, dass eine Sperrung auf Betriebssystemebene abgerufen und Standard in einer Datei in den Verzeichnissen LevelDB oder KahaDB enthalten ist, die als "sperren" bezeichnet werden. Es gibt einige Probleme mit diesem ActiveMQ HA-Modell. Sie können zu einer "No-Master"-Situation führen, in der das Replikat nicht weiß, dass sie die Datei sperren kann. Es kann auch zu einer „Master-Master“-Konfiguration kommen, die zu einer Beschädigung des Indexes oder Journals und letztendlich zu Nachrichtenverlusten führt. Die meisten dieser Probleme sind auf Faktoren zurückzuführen, auf die ActiveMQ keinen Einfluss hat. Zum Beispiel kann ein schlecht optimierter NFS-Client dafür sorgen, dass Sperrdaten unter Last veralten, was während dem Failover zu „No Master“-Downtime führt.
Da die meisten Probleme mit dieser Hochverfügbarkeitslösung auf ungenaue Dateisperren auf Betriebssystemebene zurückzuführen sind, hat die ActiveMQ-Community das Konzept eines Pluggable Storage Lockers in Version 5.7 des Brokers eingeführt. Dieser Ansatz ermöglicht es Benutzer*innen, eine andere Art gemeinsame Sperre zu nutzen, und zwar eine JDBC-Datenbanksperre auf Zeilenebene anstatt einer Dateisystemsperre auf Betriebssystemebene. Wenn Sie Unterstützung bei ActiveMQ-HA-Architekturen und -Bereitstellungen erhalten möchten, wenden Sie sich an OpenLogic von Perforce.
Ich führe Apache ActiveMQ mit LevelDB oder KahaDB auf Azure NetApp Files aus. Welche Vorsichtsmaßnahmen kann ich ergreifen, um Unterbrechungen aufgrund von Wartungsereignissen des Speicherdiensts zu vermeiden, obwohl ich das SMB-Protokoll verwende?
Die allgemeine Branchenempfehlung ist, Ihren freigegebenen KahaDB-Speicher nicht unter CIFS/SMB zu nutzen. Wenn Sie Probleme beim Aufrechterhalten eines genauen Sperrzustands haben, sehen Sie sich den JDBC Pluggable Storage Locker an, der über einen zuverlässigeren Sperrmechanismus verfügt. Wenn Sie Unterstützung bei ActiveMQ-HA-Architekturen und -Bereitstellungen erhalten möchten, wenden Sie sich an OpenLogic von Perforce.
Ich führe Boomi auf Azure NetApp Files aus. Welche Vorsichtsmaßnahmen kann ich ergreifen, um Unterbrechungen aufgrund von Wartungsereignissen des Speicherdiensts zu vermeiden?
Wenn Sie Boomi ausführen, empfiehlt es sich, die Bewährten Methoden für Boomi für Hochverfügbarkeit und Notfallwiederherstellung der Runtime zu befolgen.
Boomi empfiehlt die Verwendung von Boomi Molecule, um Hochverfügbarkeit für Boomi Atom zu implementieren. Die Systemanforderungen für Boomi Molecule besagen, dass entweder NFS mit aktivierter NFS-Sperre (NLM-Unterstützung) oder SMB-Dateifreigaben verwendet werden können. Im Kontext von Azure NetApp Files verfügen NFSv4.1-Volumes über NLM-Unterstützung.
Boomi empfiehlt, dass die SMB-Dateifreigabe mit Windows-VMs verwendet wird. Für NFS empfiehlt Boomi Linux-VMs.
Hinweis
Azure NetApp Files-Freigaben für fortlaufende Verfügbarkeit werden von Boomi nicht unterstützt.
Nächste Schritte
- Erstellen einer Azure-Supportanfrage
- Häufig gestellte Fragen zum Netzwerk
- Häufig gestellte Fragen zur Sicherheit
- Häufig gestellte Fragen zur Leistung
- Häufig gestellte Fragen zu NFS
- Häufig gestellte Fragen zu SMB
- Häufig gestellte Fragen zur Kapazitätsverwaltung
- Häufig gestellte Fragen zur Datenmigration und zum Schutz
- Häufig gestellte Fragen zur Azure NetApp Files-Sicherung
- Häufig gestellte Fragen zur Integration
- Bereitstellen von NFS-Volumes für Linux- oder Windows-VMs
- Bereitstellen von SMB-Volumes für Windows-VMs
Feedback
https://aka.ms/ContentUserFeedback.
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Tickets als Feedbackmechanismus für Inhalte auslaufen lassen und es durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter:Einreichen und Feedback anzeigen für