VERTRIEB: 1-800-867-1380

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

Letzte Aktualisierung: April 2014

Unternehmenskritische Anwendungen müssen ohne Unterbrechung selbst dann ausgeführt werden, wenn es zu ungeplanten Ausfällen oder Notfällen kommt. In diesem Thema werden Techniken beschrieben, die Sie zum Schutz von Anwendungen vor potenziellen Microsoft Azure Service Bus-Ausfällen oder -Notfällen verwenden können.

Ein Ausfall wird als die vorübergehende Nichtverfügbarkeit von Microsoft Azure Service Bus definiert. Der Ausfall kann sich auf einige Komponenten von Servicebus (z. B. einen Messagingspeicher oder sogar den ganzen Datencenter) auswirken. Nachdem das Problem behoben wurde, wird Servicebus wieder verfügbar. Normalerweise verursacht ein Ausfall keinen Verlust von Nachrichten oder anderen Daten. Ein Beispiel für den Ausfall einer Komponente ist die Nichtverfügbarkeit von Zugriffssteuerung für Microsoft Azure Active Directory (auch Zugriffssteuerungsdienst oder ACS) oder die Nichtverfügbarkeit eines bestimmten Messagingspeichers. Ein Beispiel für einen Ausfall des ganzen Datencenters ist ein Stromausfall des Datencenters oder ein fehlerhafter Netzwerkswitch des Datencenters. Ein Ausfall kann zwischen wenigen Minuten bis hin zu einigen Tagen dauern.

Ein Notfall wird als dauerhafter Verlust einer Servicebus-Skalierungseinheit oder eines -Datencenters definiert. Das Datencenter kann ggf. erneut verfügbar werden, dies muss aber nicht der Fall sein. Normalerweise verursacht ein Notfall den Verlust einiger oder aller Nachrichten oder von anderen Daten. Beispiele für Notfälle sind Brände, Überflutungen oder Erdbeben.

Servicebus verwendet zur Speicherung von Nachrichten, die zu Warteschlangen oder Themen gesendet werden, mehrere Messagingspeicher. Einem Messagingspeicher wird eine nicht partitionierte Warteschlange oder ein nicht partitioniertes Thema zugewiesen. Wenn dieser Messagingspeicher nicht verfügbar ist, sind alle Vorgänge auf dieser Warteschlange bzw. auf diesem Thema nicht erfolgreich.

Alle Servicebus-Messagingentitäten (Warteschlangen, Themen, Relays) befinden sich in einem Dienstnamespace. Das Gleiche gilt für ACS, der die Token bereitstellt, die für den Zugriff auf Servicebus-Entitäten erforderlich sind. Ein Dienstnamespace ist einem Datencenter zugeordnet. Servicebus und ACS ermöglichen keine automatische Georeplikation der Daten, und ein Dienstnamespace, der mehrere Datencenter umfasst, ist unzulässig.

Wenn ACS nicht mehr verfügbar ist, können Clients Token nicht mehr abrufen. Ohne ein gültiges Token können diese Clients auf den Servicebus-Entitäten keine Vorgänge ausführen. Clients, die ein Token haben, wenn ACS ausfällt, können Servicebus weiterhin verwenden, bis die Token ablaufen. Die Standardlebensdauer von Token beträgt 3 Stunden.

Zum Schutz gegen ACS-Ausfälle verwenden Sie SAS-Token (Shared Access Signature). In diesem Fall wird der Client durch Signieren eines selbsterstellten Tokens mit einem geheimen Schlüssel direkt bei Servicebus authentifiziert. Aufrufe an ACS sind nicht mehr erforderlich. Themenbereich SAS-Token finden Sie unter Service Bus-Authentifizierung.

Einem Messagingspeicher wird eine nicht partitionierte Warteschlange oder ein nicht partitioniertes Thema zugewiesen. Wenn dieser Messagingspeicher nicht verfügbar ist, sind alle Vorgänge auf dieser Warteschlange bzw. auf diesem Thema nicht erfolgreich. Eine partitionierte Warteschlange besteht hingegen aus mehreren Fragmenten. Jedes Fragment wird in einem anderen Messagingspeicher gespeichert. Wenn eine Nachricht an eine partitionierte Warteschlange oder ein Thema gesendet wird, weist Servicebus die Nachricht einem der Fragmente zu. Wenn der entsprechende Messagingspeicher nicht verfügbar ist, schreibt Servicebus die Nachricht in ein anderes Fragment, wenn möglich. Themenbereich partitionierte Entitäten finden Sie unter Partitionieren von Messagingentitäten.

Wenn Sie einen Failovervorgang zwischen zwei Datencentern ermöglichen möchten, können Sie einen Servicebus- und einen ACS-Dienstnamespace in jedem Datencenter erstellen. Der Servicebus-Dienstnamespace contosoPrimary.servicebus.windows.net kann sich z. B. in der Region USA (Nord/Zentral) befinden, und contosoSecondary.servicebus.windows.net kann sich z. B. in der Region USA (Süd/Zentral) befinden. Wenn der Zugriff auf eine Servicebus-Messagingentität bei einem Ausfall des Datencenters erhalten bleiben muss, können Sie diese Entität in beiden Dienstnamespaces erstellen.

Die Georeplikation von Relayendpunkten ermöglicht es, dass ein Dienst, der einen Relayendpunkt bereitstellt, bei Auftreten eines Servicebus-Ausfalls erreichbar bleibt. Wenn Georeplikation verwendet werden soll, muss der Dienst zwei Relayendpunkte in verschiedenen Dienstnamespaces erstellen. Beide Dienstnamespaces müssen sich in verschiedenen Datencentern befinden, und beide Endpunkte müssen verschiedene Namen besitzen. Ein primärer Endpunkt kann z. B. unter contosoPrimary.servicebus.windows.net/myPrimaryService erreicht werden, sein sekundäres Gegenstück unter contosoSecondary.servicebus.windows.net/mySecondaryService.

Der Dienst lauscht dann an beiden Endpunkten, und ein Client kann den Dienst über jeden der beiden Endpunkte aufrufen. Eine Clientanwendung wählt einen der Relayserver zufällig als primären Endpunkt aus und sendet ihre Anforderung an den aktiven Endpunkt. Wenn ein Vorgangsfehler mit einem Fehlercode auftritt, zeigt dieser Fehler an, dass der Relayendpunkt nicht verfügbar ist. Die Anwendung öffnet dann einen Kanal zum Sicherungsendpunkt und stellt die Anforderung erneut aus. An diesem Punkt tauschen der aktive und der Sicherungsendpunkt ihre Rollen: Die Clientanwendung betrachtet den alten aktiven Endpunkt als neuen Sicherungsendpunkt und den alten Sicherungsendpunkt als neuen aktiven Endpunkt. Wenn bei beiden Sendevorgängen ein Fehler auftritt, bleiben die Rollen der beiden Entitäten unverändert, und es wird ein Fehler zurückgegeben.

Das Beispiel Georeplikation mit Service Bus-Relaynachrichten zeigt, wie Relays repliziert werden.

Servicebus unterstützt zwei Ansätze, um Schutz vor Datencenterausfällen bei der Verwendung von Brokermessaging zu bieten: aktive und passive Replikation. Wenn der Zugriff auf eine bestimmte Warteschlange oder ein Thema bei einem Ausfall des Datencenters erhalten bleiben muss, können Sie diese für jeden dieser Ansätze in beiden Dienstnamespaces erstellen. Beide Entitäten können den gleichen Namen aufweisen. 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.

Wenn die Anwendung keine permanente Kommunikation zwischen dem Absender und dem Empfänger erfordert, kann die Anwendung eine dauerhafte clientseitige Warteschlange implementieren, um Nachrichtenverluste zu vermeiden und den Absender von vorübergehenden Servicebus-Fehlern abzuschirmen.

Die aktive Replikation verwendet Entitäten in beiden Dienstnamespaces für jeden Vorgang. Jeder Client, der eine Nachricht sendet, sendet zwei Kopien der gleichen Nachricht. Die erste Kopie wird an die primäre Entität gesendet (z. B. an contosoPrimary.servicebus.windows.net/sales), und die zweite Kopie der Nachricht wird an die sekundäre Entität gesendet (z. B. an contosoSecondary.servicebus.windows.net/sales).

Ein Client empfängt Nachrichten aus beiden Warteschlangen. Der Empfänger verarbeitet die erste Kopie einer Nachricht. Die zweite Kopie wird unterdrückt. Damit doppelt vorhandene Nachrichten unterdrückt werden können, muss der Absender jede Nachricht mit einem eindeutigen Bezeichner kennzeichnen. Beide Kopien der Nachricht müssen mit dem gleichen Bezeichner gekennzeichnet sein. Sie können MessageId, Label oder eine benutzerdefinierte Eigenschaft zum Kennzeichnen der Nachricht verwenden. Der Empfänger muss eine Liste der Nachrichten verwalten, die er bereits empfangen hat.

Das Beispiel Georeplikation mit Service Bus-Brokernachrichten zeigt die aktive Replikation von Messagingentitäten.

noteHinweis
Der Ansatz der aktiven Replikation verdoppelt die Anzahl der Vorgänge. Dieser Ansatz kann daher zu höheren Kosten führen.

Im Fall eines fehlerfreien Szenarios verwendet die passive Replikation nur eine der zwei Messagingentitäten. Ein Client sendet die Nachricht an die aktive Entität. Wenn der Vorgang für die aktive Entität mit einem Fehlercode fehlschlägt, der angibt, dass das Datencenter, das die aktive Entität hostet, ggf. nicht verfügbar ist, sendet der Client eine Kopie der Nachricht an die Sicherheitsentität. An diesem Punkt tauschen die aktive 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 bei beiden Sendevorgängen ein Fehler auftritt, bleiben die Rollen der beiden Entitäten unverändert, und es wird ein Fehler zurückgegeben.

Ein Client empfängt Nachrichten aus beiden Warteschlangen. Weil die Möglichkeit besteht, dass der Empfänger zwei Kopien der gleichen Nachricht empfängt, muss der Empfänger doppelt vorhandene Nachrichten unterdrücken. Duplikate können auf die gleiche Weise wie für die aktive Replikation beschrieben unterdrückt werden.

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

Wenn passive Replikation verwendet wird, können unter den folgenden Umständen Nachrichten verlorengehen oder zwei Mal empfangen werden:

  • Nachrichtenverzögerung oder -verlust: Angenommen, der Absender hat eine Nachricht m1 erfolgreich an die primäre Warteschlange gesendet, und die Warteschlange ist anschließend nicht mehr verfügbar, bevor der Empfänger m1 empfängt. Der Absender sendet eine nachfolgende Nachricht m2 an die sekundäre Warteschlange. Wenn die primäre Warteschlange vorübergehend nicht verfügbar ist, empfängt der Empfänger m1, nachdem die Warteschlange erneut verfügbar ist. Sollte ein Notfall eintreten, empfängt der Empfänger m1 ggf. niemals.

  • Doppelter Empfang: Angenommen, der Absender sendet eine Nachricht m an die primäre Warteschlange. Servicebus verarbeitet m erfolgreich, sendet jedoch keine Antwort. Nach dem Timeout des Sendevorgangs sendet der Absender eine identische Kopie von m an die sekundäre Warteschlange. Wenn der Empfänger in der Lage ist, die erste Kopie von m zu empfangen, bevor die Warteschlange nicht mehr verfügbar ist, empfängt der Empfänger beide Kopien von m zum ungefähr gleichen Zeitpunkt. Wenn der Empfänger nicht in der Lage ist, die erste Kopie von m zu empfangen, bevor die Warteschlange nicht mehr verfügbar ist, empfängt der Empfänger anfangs nur die zweite Kopie von m, dann jedoch noch eine zweite Kopie von m, wenn die primäre Warteschlange verfügbar wird.

Das Beispiel Georeplikation mit Service Bus-Brokernachrichten zeigt die passive Replikation von Messagingentitäten.

Wenn die Anwendung tolerieren kann, dass eine Servicebus-Entität nicht verfügbar ist, jedoch keine Nachrichten verlieren darf, kann der Absender eine dauerhafte clientseitige Warteschlange bereitstellen, die alle Nachrichten, die nicht an Servicebus gesendet werden können, lokal speichert. Nachdem die Servicebus-Entität erneut verfügbar ist, werden alle gepufferten Nachrichten an diese Entität gesendet. Das Beispiel Dauerhafter Nachrichtenabsender implementiert eine solche Warteschlange mithilfe von MSMQ. Alternativ kann die Nachricht auf den lokalen Datenträger geschrieben werden.

Eine dauerhafte clientseitige Warteschlange behält die Nachrichtenreihenfolge bei und schirmt die Clientanwendung von Ausnahmen für den Fall ab, dass die Servicebus-Entität nicht verfügbar ist. Sie kann mit einfachen und mit verteilten Transaktionen verwendet werden.

Siehe auch

Fanden Sie dies hilfreich?
(1500 verbleibende Zeichen)
Vielen Dank für Ihr Feedback.
Anzeigen:
© 2014 Microsoft