Bewährte Methoden zum Schützen von Anwendungen vor Service Bus-Ausfällen und Notfällen

  • Artikel

Unternehmenswichtige Anwendungen müssen ohne Unterbrechung ausgeführt werden. Dies gilt auch bei ungeplanten Ausfällen oder in Notsituationen. Die Resilienz gegen katastrophale Ausfälle von Datenverarbeitungsressourcen ist für viele Unternehmen erforderlich und in einigen Fällen sogar Branchenvorschrift. In diesem Artikel werden Verfahren beschrieben, mit denen Sie Service Bus-Anwendungen vor einem potenziellen Dienstausfall oder Notfällen schützen können.

Mit Azure Service Bus wird das Risiko von schwerwiegenden Ausfällen einzelner Computer oder sogar der kompletten Racks in Clustern, die mehrere Fehlerdomänen in einem Rechenzentrum umfassen, bereits verteilt. Außerdem werden mit Azure Service Bus transparente Fehlererkennungs- und Failovermechanismen implementiert. Somit wird der Dienst weiterhin innerhalb der garantierten Servicelevel und in der Regel ohne spürbare Unterbrechungen im Falle solcher Fehler ausgeführt.

Darüber hinaus ist das Ausfallrisiko auf drei physisch getrennte Anlagen (Verfügbarkeitszonen) verteilt, und der Dienst verfügt über genügend Kapazitätsreserven, um den vollständigen, katastrophalen Ausfall eines Rechenzentrums sofort zu bewältigen. Das umfassend aktive Azure Service Bus-Clustermodell in einer Fehlerdomäne mit Unterstützung von Verfügbarkeitszonen ist jedem lokalen Nachrichtenbroker im Hinblick auf Resilienz gegen schwerwiegende Hardwareausfälle und sogar gegen den katastrophalen Verlust gesamter Rechenzentrumseinrichtungen überlegen. Es kann jedoch bedrohliche Situationen mit großflächigen physischen Zerstörungen geben, vor denen selbst diese Maßnahmen keinen ausreichenden Schutz bieten können.

Die georedundante Notfallwiederherstellung und die Georeplikation von Service Bus erleichtert die Wiederherstellung nach einem Notfall dieser Größenordnung und das endgültige Verwerfen einer Azure-Region, ohne die Anwendungskonfigurationen ändern zu müssen.

Ausfälle und Notfälle

Es ist wichtig, dass Sie den Unterschied zwischen „Ausfällen“ und „Notfällen“ kennen.

Ein Ausfall ist die vorübergehende Nichtverfügbarkeit von Azure Service Bus und kann einige Komponenten des Diensts, z.B. einen Nachrichtenspeicher, oder selbst das gesamte Rechenzentrum betreffen. Nachdem das Problem behoben wurde, ist Service Bus aber wieder verfügbar. In der Regel führt ein Ausfall nicht zum Verlust von Nachrichten oder anderen Daten. Ein Beispiel für den Ausfall einer Komponente ist die Nichtverfügbarkeit eines bestimmten Nachrichtenspeichers. Beispiele für den Ausfall eines gesamten Rechenzentrums sind ein Stromausfall im Rechenzentrum oder ein fehlerhafter Netzwerkswitch im Rechenzentrum. Ein Ausfall kann einige Minuten oder auch bis zu einigen Tagen dauern. Bei einigen Ausfällen handelt es sich nur um kurze Verbindungsunterbrechungen aufgrund von vorübergehenden Problemen bzw. Netzwerkproblemen.

Ein Notfall ist als dauerhafter oder längerer Ausfall eines Service Bus-Clusters, einer Azure-Region oder eines Datencenters definiert. Es kann sein, dass die Region oder das Rechenzentrum noch nicht wieder verfügbar ist oder für Stunden oder Tage ausfällt. Beispiele für Notfälle sind Feuer, Überflutung und Erdbeben. Ein Notfall, der dauerhaft wird, kann zum Verlust von Nachrichten, Ereignissen oder anderen Daten führen. In den meisten Fällen sollte es jedoch zu keinem Datenverlust kommen und die Nachrichten können wiederhergestellt werden, sobald das Rechenzentrum wieder in Betrieb ist.

Schutz vor Ausfällen und Notfällen

Es gibt zwei Features, die die georedundante Notfallwiederherstellung in Azure Service Bus für die Premium-Ebene bereitstellen. Zunächst gibt es die georedundante Notfallwiederherstellung (Notfallwiederherstellung von Metadaten), die die Replikation von Metadaten (Entitäten, Konfiguration, Eigenschaften) ermöglicht. Zweitens gibt es die Georeplikation, die derzeit als öffentliche Vorschauversion verfügbar ist und die Replikation von Metadaten und den Daten selbst (Nachrichtendaten und Nachrichteneigenschaft/Statusänderungen) ermöglicht. Keines der Features für die georedundante Notfallwiederherstellung sollte mit Verfügbarkeitszonen verwechselt werden. Unabhängig davon, ob es sich um Metadaten-DR oder Georeplikation handelt, bieten beide geografischen Wiederherstellungsfeatures Resilienz zwischen Azure-Regionen wie „USA, Osten“ und „USA, Westen“.

Verfügbarkeitszonen sind für alle Service Bus-Ebenen verfügbar, und die Unterstützung bietet Resilienz innerhalb einer bestimmten geografischen Region, z. B. „USA, Osten“. Eine ausführliche Erläuterung der Notfallwiederherstellung in Microsoft Azure finden Sie in diesem Artikel.

Die Konzepte der Hochverfügbarkeit und Notfallwiederherstellung sind direkt im Premium-Tarif von Azure Service Bus integriert, sowohl innerhalb derselben Region (über Verfügbarkeitszonen) als auch in verschiedenen Regionen (über die georedundante Notfallwiederherstellung und Georeplikation).

Optionen für die georedundante Notfallwiederherstellung

Georedundante Notfallwiederherstellung

Die Premium-Ebene von Service Bus unterstützt die georedundante Notfallwiederherstellung auf Namespaceebene. Weitere Informationen finden Sie unter Georedundante Notfallwiederherstellung in Azure Service Bus. Bei der Funktion für die georedundante Notfallwiederherstellung, die nur für die Premium-Ebene verfügbar ist, wird die Notfallwiederherstellung von Metadaten implementiert. Die Funktion basiert auf primären und sekundären Namespaces. Bei der georedundanten Notfallwiederherstellung werden nur Metadaten für Entitäten zwischen primären und sekundären Namespaces repliziert.

Georeplikation

Die Premium-Ebene von Service Bus unterstützt auch die Georeplikation auf Namespaceebene. Weitere Informationen finden Sie unter Georeplikation in Azure Service Bus (Public Preview). Bei der Funktion für die Georeplikation, die nur für die Premium-Ebene und derzeit als Public Preview verfügbar ist, wird die Notfallwiederherstellung von Metadaten und Daten implementiert. Die Funktion basiert auf primären und sekundären Regionen. Bei der Georeplikation werden sowohl Metadaten als auch Daten für Entitäten zwischen primären und sekundären Regionen repliziert.

Allgemeine Funktionsunterschiede

Das Feature für die georedundante Notfallwiederherstellung (Metadaten-DR) repliziert Metadaten für einen Namespace von einem primären Namespace in einem sekundären Namespace. Sie unterstützt ein einmaliges Failover für die sekundäre Region. Während des vom Kunden initiierten Failovers wird der Aliasname für den Namespace auf den sekundären Namespace umgeleitet, und dann wird die Kopplung unterbrochen. Es werden nur Metadaten und keine anderen Daten repliziert, und es werden keine RBAC-Zuordnungen repliziert.

Das Feature für die Georeplikation repliziert Metadaten und alle Daten aus einer primären Region in einer oder mehreren sekundären Regionen. Wenn ein Failover vom Kunden ausgeführt wird, wird die ausgewählte sekundäre Region zur primären Region und die vorherige primäre Region wird zu einer sekundären Region. Benutzer können bei Bedarf ein Failover zurück auf die ursprüngliche primäre Region ausführen.

Verfügbarkeitszonen

Alle Service Bus-Ebenen unterstützen Verfügbarkeitszonen und bieten fehlerisolierte Standorte innerhalb derselben Azure-Region. Service Bus verwaltet drei Kopien des Nachrichtenspeichers (ein primäres und zwei sekundäre Replikate). Service Bus hält alle drei Kopien für Daten- und Verwaltungsvorgänge synchron. Wenn bei der primären Kopie ein Fehler auftritt, wird eine der sekundären Kopien ohne wahrnehmbare Ausfallzeit zum primären Replikat heraufgestuft. Wenn bei den Anwendungen vorübergehende Trennungen von Azure Service Bus auftreten, stellt die Wiederholungslogik im SDK automatisch erneut eine Verbindung mit Service Bus her.

Wenn Sie Verfügbarkeitszonen verwenden, werden sowohl Metadaten als auch Daten (Nachrichten) zwischen Rechenzentren in der Verfügbarkeitszone repliziert.

Hinweis

Die Unterstützung für Verfügbarkeitszonen ist nur in Azure-Regionen verfügbar, in denen Verfügbarkeitszonen vorhanden sind.

Wenn Sie einen Namespace erstellen, wird die Unterstützung für Verfügbarkeitszonen (sofern in der ausgewählten Region verfügbar) automatisch für den Namespace aktiviert. Es fallen keine zusätzlichen Kosten für die Verwendung dieses Features an, und Sie können dieses Feature nach der Namespaceerstellung nicht deaktivieren oder aktivieren.

Hinweis

Zuvor war es erforderlich, die Eigenschaft zoneRedundant auf true festzulegen, um Verfügbarkeitszonen zu aktivieren. Dieses Verhalten hat sich jedoch geändert, damit Verfügbarkeitszonen standardmäßig aktiviert werden. Vorhandene Namespaces werden nach Möglichkeit zu Verfügbarkeitszonen migriert, und die Eigenschaft zoneRedundant ist nun veraltet. Die Eigenschaft zoneRedundant kann weiterhin als false angezeigt werden, auch wenn Verfügbarkeitszonen aktiviert wurden. Vorhandene Namespaces, die migriert werden:

Schutz vor Ausfällen – Standardebene

Um Resilienz gegenüber Notfällen mit der Standardebene von Service Bus zu erzielen, können Sie die aktive oder passive Replikation verwenden. Bei beiden Ansätzen können Sie die Erstellung in beiden Namespaces durchführen, wenn eine Warteschlange oder ein Thema bei einem Rechenzentrumausfall verfügbar bleiben muss. Beide Entitäten können den gleichen Namen haben. Eine primäre Warteschlange kann z. B. unter contosoPrimary.servicebus.windows.net/myQueue erreicht werden, ihr sekundäres Gegenstück unter contosoSecondary.servicebus.windows.net/myQueue.

Hinweis

Bei der aktiven Replikation und der passiven Replikation handelt es sich um allgemeine Lösungen und nicht um spezifische Funktionen von Service Bus. Die Replikationslogik (Senden an zwei verschiedene Namespaces) befindet sich in der Senderanwendung. Der Empfänger muss für die Erkennung von Duplikaten über benutzerdefinierte Logik verfügen.

Falls die Anwendung keine permanente Kommunikation vom Absender zum Empfänger erfordert, kann die Anwendung eine dauerhafte clientseitige Warteschlange implementieren, um Nachrichtenverlust zu verhindern und den Absender gegen vorübergehende Service Bus-Fehler abzuschirmen.

Aktive Replikation

Bei der aktiven Replikation werden für jeden Vorgang Entitäten in beiden Namespaces verwendet. Von allen Clients, die eine Nachricht senden, werden jeweils zwei Exemplare derselben Nachricht gesendet. Die erste Kopie wird an die primäre Entität gesendet (z.B. contosoPrimary.servicebus.windows.net/sales), und die zweite Kopie der Nachricht wird an die sekundäre Entität gesendet (z.B. contosoSecondary.servicebus.windows.net/sales).

Ein Client empfängt Nachrichten aus beiden Warteschlangen. Der Empfänger verarbeitet die erste Kopie einer Nachricht, und die zweite Kopie wird unterdrückt. Damit doppelte Nachrichten unterdrückt werden können, muss der Absender jede Nachricht mit einem eindeutigen Bezeichner versehen. Beide Kopien der Nachricht müssen mit dem gleichen Bezeichner gekennzeichnet werden. Sie können die Eigenschaften ServiceBusMessage.MessageId oder ServiceBusMessage.Subject oder auch eine benutzerdefinierte Eigenschaft zum Kennzeichnen der Nachricht verwenden. Der Empfänger muss eine Liste der Nachrichten vorhalten, die er bereits empfangen hat.

Hinweis

Beim Ansatz mit der aktiven Replikation wird die Anzahl von Vorgängen verdoppelt. Daher kann dieser Ansatz zu höheren Kosten führen.

Passive Replikation

Wenn kein Fehler vorliegt, wird bei der passiven Replikation nur eine der beiden Nachrichtenentitäten verwendet. Ein Client sendet die Nachricht an die aktive Entität. Wenn der Vorgang auf der aktiven Entität mit einem Fehlercode fehlschlägt und angegeben wird, dass das Rechenzentrum, von dem die aktive Entität gehostet wird, ggf. nicht verfügbar ist, sendet der Client eine Kopie der Nachricht an die Backup-Entität. An diesem Punkt tauschen die aktive Entität und die Sicherungsentität ihre Rollen: Der sendende Client betrachtet die alte aktive Entität als neue Sicherungsentität und die alte Sicherungsentität als die neue aktive Entität. Wenn beide Sendevorgänge fehlschlagen, bleiben die Rollen der beiden Entitäten unverändert, und es wird ein Fehler zurückgegeben.

Ein Client empfängt Nachrichten aus beiden Warteschlangen. Da die Möglichkeit besteht, dass der Empfänger zwei Kopien derselben Nachricht erhält, muss der Empfänger doppelte Nachrichten unterdrücken. Sie können Duplikate hierbei genauso unterdrücken, wie dies für die aktive Replikation beschrieben wurde.

Im Allgemeinen ist die passive Replikation wirtschaftlicher als die aktive Replikation, da in den meisten Fällen nur ein Vorgang ausgeführt wird. Latenz, Durchsatz und Kosten sind identisch mit dem Szenario ohne Replikation.

Wenn Sie passive Replikation verwenden, können Nachrichten in den folgenden Szenarien verloren gehen oder doppelt empfangen werden:

  • Nachrichtenverzögerung oder -verlust: Angenommen, der Absender hat die Nachricht „m1“ an die primäre Warteschlange gesendet, und die Warteschlange ist dann nicht mehr verfügbar, bevor der Empfänger „m1“ erhält. Der Absender sendet die nachfolgende Nachricht „m2“ an die sekundäre Warteschlange. Wenn die primäre Warteschlange vorübergehend nicht verfügbar ist, erhält der Empfänger „m1“, wenn die Warteschlange wieder verfügbar ist. Wenn ein Notfall auftritt, erhält der Empfänger möglicherweise nie m1.
  • Doppelter Empfang: Angenommen, der Absender sendet eine Nachricht „m“ an die primäre Warteschlange. Service Bus verarbeitet „m“, aber es kann keine Antwort gesendet werden. Nach dem Timeout des Sendevorgangs sendet der Absender eine identische Kopie von „m“ an die sekundäre Warteschlange. Wenn der Empfänger die erste Kopie von „m“ empfangen kann, bevor die primäre Warteschlange nicht mehr verfügbar ist, erhält der Empfänger nahezu gleichzeitig beide Kopien von „m“. Falls der Empfänger die erste Kopie von „m“ nicht erhält, bevor die primäre Warteschlange nicht mehr verfügbar ist, erhält der Empfänger zuerst nur die zweite Kopie von „m“. Anschließend erhält er aber eine zweite Kopie von „m“, wenn die primäre Warteschlange verfügbar wird.

Im Beispiel Azure Messaging-Replikationsaufgaben mit .NET Core wird die Replikation von Nachrichten zwischen Namespaces veranschaulicht.

Nächste Schritte

Weitere Informationen zur Notfallwiederherstellung finden Sie in diesen Artikeln: