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. In diesem Artikel werden Verfahren beschrieben, mit denen Sie Service Bus-Anwendungen vor einem potenziellen Dienstausfall oder Notfällen schützen können.

Ein Ausfall wird als vorübergehende Nichtverfügbarkeit von Azure Service Bus definiert. Der Ausfall kann nur einige Komponenten von Service Bus betreffen, z. B. einen Nachrichtenspeicher, oder auch das gesamte Rechenzentrum. Nachdem das Problem behoben wurde, ist Service Bus 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.

Ein Notfall wird als dauerhafter Verlust einer Service Bus-Skalierungseinheit oder eines Rechenzentrums definiert. Möglicherweise ist das Rechenzentrum wieder verfügbar. Häufig gehen bei einem Notfall einige oder alle Nachrichten oder anderen Daten verloren. Beispiele für Notfälle sind Feuer, Überflutung und Erdbeben.

Schutz vor Ausfällen und Notfällen – Premium-Tarif

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).

Georedundante Notfallwiederherstellung

Die Premium-Ebene für Service Bus unterstützt die georedundante Notfallwiederherstellung auf Namespaceebene. Weitere Informationen finden Sie unter Georedundante Notfallwiederherstellung in Azure Service Bus. Bei der Funktion zur Notfallwiederherstellung, die nur für die Premium-SKU verfügbar ist, wird die Notfallwiederherstellung von Metadaten implementiert. Diese basiert auf speziellen 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.

Verfügbarkeitszonen

Die Premium-Ebene für Service Bus unterstützt Verfügbarkeitszonen, die fehlerisolierte Standorte innerhalb einer Azure-Region bieten. Service Bus verwaltet drei Kopien des Messagingstores (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 für die Premium-Ebene ist nur in Azure-Regionen verfügbar, in denen Verfügbarkeitszonen vorhanden sind.

Wenn Sie einen Premium-Namespace erstellen, wird die Unterstützung für Verfügbarkeitszonen (sofern in der ausgewählten Region verfügbar) automatisch für den Namespace aktiviert. Beim Erstellen eines Premium-Namespace über andere Mechanismen, z. B. Azure Resource Manager / Bicep Vorlagen, CLI oder PowerShell, muss die zoneRedundant-Eigenschaft explizit auf true festgelegt werden, um Verfügbarkeitszonen (sofern in der ausgewählten Region verfügbar) zu aktivieren. 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.

Schutz vor Ausfällen und Notfällen – Standard-Tarif

Um Resilienz gegenüber Rechenzentrumsausfällen mit dem standardmäßigen Preisniveau für Messaging 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.

Im Beispiel für die [Georeplikation mit dem Standard-Tarif von Service Bus][Georeplikation mit dem Standard-Tarif von Service Bus] wird die aktive Replikation von Nachrichtenentitäten veranschaulicht.

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: