Geo-Service Bus van Azure
Tolerantie tegen uitval van gegevensverwerkingsresources is een vereiste voor veel ondernemingen en in sommige gevallen zelfs vereist door branchevoorschriften.
Azure Service Bus verspreidt al het risico op onherstelbare storingen van afzonderlijke machines of zelfs complete racks over clusters die meerdere foutdomeinen binnen een datacenter omvatten. Het implementeert transparante foutdetectie- en failovermechanismen, zodat de service blijft werken binnen de gegarandeerde serviceniveaus en meestal zonder merkbare onderbrekingen wanneer dergelijke fouten optreden. Als een Service Bus-naamruimte is gemaakt met de ingeschakelde optie voor beschikbaarheidszones,wordt het risico op uitval verder verdeeld over drie fysiek gescheiden faciliteiten en heeft de service voldoende capaciteitsreserves om direct te kunnen omgaan met het volledige, onherstelbare verlies van de hele faciliteit.
Het volledig actieve Azure Service Bus-clustermodel met ondersteuning voor beschikbaarheidszone is beter dan elk on-premises berichtbrokerproduct wat betreft tolerantie tegen ernstige hardwarestoringen en zelfs onherstelbaar verlies van volledige datacenterfaciliteiten. Toch kunnen er ernstige situaties zijn met wijdverbreide fysieke destructie, waar zelfs die maatregelen onvoldoende bescherming tegen kunnen bieden.
De functie Service Bus geo-herstel na noodgevallen is ontworpen om het gemakkelijker te maken om te herstellen van een noodgevallen van deze omvang en om een mislukte Azure-regio te verlaten voor een goede en zonder dat u de configuraties van uw toepassing moet wijzigen. Het verlaten van een Azure-regio omvat doorgaans verschillende services en deze functie is voornamelijk bedoeld om de integriteit van de samengestelde toepassingsconfiguratie te behouden. De functie is wereldwijd beschikbaar voor de Service Bus Premium SKU.
De Geo-Disaster-herstelfunctie zorgt ervoor dat de volledige configuratie van een naamruimte (wachtrijen, onderwerpen, abonnementen, filters) continu wordt gerepliceerd van een primaire naamruimte naar een secundaire naamruimte wanneer deze is gekoppeld, en dat u op elk moment een eensgevolgde failover kunt initiëren van de primaire naar de secundaire. De failover verplaatst de gekozen aliasnaam voor de naamruimte naar de secundaire naamruimte en verbreekt vervolgens de koppeling. De failover wordt vrijwel onmiddellijk gestart.
Belangrijk
- De functie maakt directe continuïteit van bewerkingen met dezelfde configuratie mogelijk, maar repliceert de berichten in wachtrijen, onderwerpabonnementen of wachtrijen voor niet-geplaatste berichten niet. Om wachtrijsemantiek te behouden, vereist een dergelijke replicatie niet alleen de replicatie van berichtgegevens, maar van elke statuswijziging in de broker. Voor de meeste Service Bus-naamruimten zou het vereiste replicatieverkeer veel groter zijn dan het toepassingsverkeer en met wachtrijen met een hoge doorvoer, zouden de meeste berichten nog steeds worden gerepliceerd naar de secundaire terwijl ze al van de primaire worden verwijderd, wat overmatig onnodig verkeer veroorzaakt. Voor replicatieroutes met hoge latentie, die van toepassing zijn op veel paren die u kiest voor geo-noodherstel, is het mogelijk ook onmogelijk voor het replicatieverkeer om het toepassingsverkeer duurzaam bij te houden als gevolg van latentie-geïnduceerde beperkingseffecten.
- Azure Active Directory (Azure AD) op rollen gebaseerd toegangsbeheer (RBAC) aan Service Bus-entiteiten in de primaire naamruimte worden niet gerepliceerd naar de secundaire naamruimte. Maak handmatig roltoewijzingen in de secundaire naamruimte om de toegang tot de toewijzingen te beveiligen.
Tip
Voor het repliceren van de inhoud van wachtrijen en onderwerpabonnementen en het gebruiken van bijbehorende naamruimten in actieve/actieve configuraties om te kunnen omgaan met uitval en rampen, moet u niet afhankelijk zijn van deze functieset voor herstel na geo-nood, maar volgt u de replicatie-richtlijnen.
Uitval en noodscenario's
Het is belangrijk om te weten wat het verschil is tussen 'uitval' en 'noodscenario's'.
Een storing is de tijdelijke onbeschikbaarheid van Azure Service Bus en kan van invloed zijn op bepaalde onderdelen van de service, zoals een berichtenopslag of zelfs het hele datacenter. Nadat het probleem is opgelost, Service Bus weer beschikbaar. Normaal gesproken veroorzaakt een storing niet het verlies van berichten of andere gegevens. Een voorbeeld van een dergelijke storing kan een stroomstoring in het datacenter zijn. Sommige uitval is slechts een korte verbindingsverlies vanwege tijdelijke problemen of netwerkproblemen.
Een noodlot wordt gedefinieerd als het permanente of langere verlies van een Service Bus cluster, Azure-regio of datacenter. De regio of het datacenter wordt mogelijk wel of niet weer beschikbaar, of is mogelijk uren of dagen niet beschikbaar. Voorbeelden van dergelijke rampen zijn brand, overstromingen of aardbevingen. Een noodlot dat permanent wordt, kan leiden tot het verlies van bepaalde berichten, gebeurtenissen of andere gegevens. In de meeste gevallen mag er echter geen gegevens verloren gaan en kunnen berichten worden hersteld zodra er een back-up van het datacenter is.
De functie geo-herstel na noodherstel van Azure Service Bus is een oplossing voor herstel na noodherstel. De concepten en werkstroom die in dit artikel worden beschreven, zijn van toepassing op noodscenario's en niet op tijdelijke of tijdelijke uitval. Zie dit artikel voor een gedetailleerde Microsoft Azure over herstel na noodherstel.
Basisconcepten en -termen
De functie voor herstel na noodherstel implementeert metagegevens voor noodherstel en is afhankelijk van primaire en secundaire naamruimten voor herstel na noodherstel. De functie Geo-noodherstel is alleen beschikbaar voor de Premium SKU. U hoeft geen wijzigingen aan te connection string, omdat de verbinding wordt gemaakt via een alias.
In dit artikel worden de volgende termen gebruikt:
Alias: de naam voor een configuratie voor herstel na noodherstel die u hebt ingesteld. De alias biedt één stabiele FQDN-naam (Fully Qualified Domain Name) connection string. Toepassingen gebruiken deze alias om connection string verbinding te maken met een naamruimte. Het gebruik van een alias zorgt ervoor dat connection string niet wordt gewijzigd wanneer de failover wordt geactiveerd.
Primaire/secundaire naamruimte: de naamruimten die overeenkomen met de alias. De primaire naamruimte is 'actief' en ontvangt berichten (dit kan een bestaande of nieuwe naamruimte zijn). De secundaire naamruimte is 'passief' en ontvangt geen berichten. De metagegevens tussen beide zijn gesynchroniseerd, zodat beide naadloos berichten kunnen accepteren zonder toepassingscode of connection string wijzigingen. Om ervoor te zorgen dat alleen de actieve naamruimte berichten ontvangt, moet u de alias gebruiken.
Metagegevens: entiteiten zoals wachtrijen, onderwerpen en abonnementen; en de eigenschappen van de service die aan de naamruimte zijn gekoppeld. Alleen entiteiten en hun instellingen worden automatisch gerepliceerd. Berichten worden niet gerepliceerd.
Failover: het proces van het activeren van de secundaire naamruimte.
Instellen
In de volgende sectie wordt een overzicht gegeven van het instellen van de koppeling tussen de naamruimten.
Eerst maakt of gebruikt u een bestaande primaire naamruimte en een nieuwe secundaire naamruimte en vervolgens koppelt u de twee. Deze koppeling biedt u een alias die u kunt gebruiken om verbinding te maken. Omdat u een alias gebruikt, hoeft u de verbindingsreeksen niet te wijzigen. Alleen nieuwe naamruimten kunnen worden toegevoegd aan uw failover-koppeling.
Maak de primaire naamruimte.
Maak de secundaire naamruimte in een andere regio. Deze stap is optioneel. U kunt de secundaire naamruimte maken tijdens het maken van de koppeling in de volgende stap.
Navigeer in Azure Portal naar uw primaire naamruimte.
Selecteer Geo-herstel in het menu links en selecteer Koppelen initiëren op de werkbalk.
Volg deze stappen op de pagina Koppelen initiëren:
Selecteer een bestaande secundaire naamruimte of maak er een in een andere regio. In dit voorbeeld wordt een bestaande naamruimte gebruikt als de secundaire naamruimte.
Voer bij Alias een alias in voor de geo-dr-koppeling.
Ten slotte selecteert u Create.
U ziet de pagina Service Bus Geo-DR Alias, zoals wordt weergegeven in de volgende afbeelding. U kunt ook navigeren naar de pagina Geo-DR Alias op de pagina primaire naamruimte door geo-herstel te selecteren in het menu links.
Selecteer op de pagina Geo-DR Alias beleid voor gedeelde toegang in het menu links voor toegang tot de primaire connection string voor de alias. Gebruik deze connection string in plaats van de connection string rechtstreeks naar de primaire/secundaire naamruimte te gebruiken. In eerste instantie wijst de alias naar de primaire naamruimte.
Ga naar de pagina Overzicht. U kunt de volgende acties uitvoeren:
- Verbreed de koppeling tussen primaire en secundaire naamruimten. Selecteer Koppeling met onderbrekingen op de werkbalk.
- Fail over naar de secundaire naamruimte handmatig.
Selecteer Failover op de werkbalk.
Bevestig dat u een fail over wilt maken naar de secundaire naamruimte door uw alias te typen.
Schakel de optie Safe failover in om veilig een failover uit te brengen naar de secundaire naamruimte. Deze functie zorgt ervoor dat in behandeling zijnde geo-DR-replicaties zijn voltooid voordat u overschakelt naar de secundaire replica.
Selecteer vervolgens Failover.
Belangrijk
Als u een andere fout maakt, wordt de secundaire naamruimte geactiveerd en wordt de primaire naamruimte verwijderd uit Geo-Disaster Recovery-koppeling. Maak een andere naamruimte om een nieuw geo-noodherstelpaar te hebben.
Ten slotte moet u bewaking toevoegen om te detecteren of een failover nodig is. In de meeste gevallen maakt de service deel uit van een groot ecosysteem, waardoor automatische failovers zelden mogelijk zijn, omdat failovers vaak synchroon moeten worden uitgevoerd met het resterende subsysteem of de resterende infrastructuur.
Service Bus standard naar premium
Als u uw Azure Service Bus Standard-naamruimte hebt gemigreerd naar Azure Service Bus Premium,moet u de bestaande alias (dat wil zeggen uw Service Bus Standard-naamruimte connection string) gebruiken om de configuratie voor herstel na noodherstel te maken via de PS/CLI of REST API.
Dit komt doordat uw Azure Service Bus Standard-naamruimte connection string/DNS-naam zelf een alias wordt voor uw Azure Service Bus Premium-naamruimte.
Uw clienttoepassingen moeten gebruikmaken van deze alias (dat wil zeggen, de Azure Service Bus Standard-naamruimte connection string) om verbinding te maken met de Premium-naamruimte waar het koppelen na noodherstel is ingesteld.
Als u de portal gebruikt om de configuratie voor herstel na noodherstel in te stellen, wordt dit nadeel van u geabstraheerd.
Failoverstroom
Een failover wordt handmatig geactiveerd door de klant (expliciet via een opdracht of via bedrijfslogica die eigendom is van de client die de opdracht activeert) en nooit door Azure. Het biedt de klant volledig eigendom en inzicht in uitvaloplossing op de backbone van Azure.
Nadat de failover is geactiveerd -
De alias connection string is bijgewerkt om te wijzen naar de secundaire Premium naamruimte.
Clients (afzenders en ontvangers) maken automatisch verbinding met de secundaire naamruimte.
De bestaande koppeling tussen de primaire en secundaire Premium-naamruimte is verbroken.
Zodra de failover is gestart -
Als er een andere storing optreedt, wilt u een fail over kunnen doen. Stel dus een andere passieve naamruimte in en werk de koppeling bij.
Haal berichten op uit de voormalige primaire naamruimte zodra deze weer beschikbaar is. Daarna gebruikt u die naamruimte voor reguliere berichten buiten uw geo-herstelconfiguratie of verwijdert u de oude primaire naamruimte.
Notitie
Alleen fail forward-semantiek wordt ondersteund. In dit scenario kunt u een fail over en vervolgens opnieuw koppelen met een nieuwe naamruimte. Een mislukte back wordt niet ondersteund; bijvoorbeeld in een SQL cluster.
U kunt failover automatiseren met bewakingssystemen of met aangepaste bewakingsoplossingen. Voor dergelijke automatisering is echter extra planning en werk nodig, wat buiten het bereik van dit artikel valt.
Beheer
Als u een fout hebt gemaakt; Als u bijvoorbeeld de verkeerde regio's hebt gekoppeld tijdens de eerste installatie, kunt u het koppelen van de twee naamruimten op elk moment breken. Als u de gekoppelde naamruimten als gewone naamruimten wilt gebruiken, verwijdert u de alias.
Bestaande naamruimte als alias gebruiken
Als u een scenario hebt waarin u de verbindingen van producenten en consumenten niet kunt wijzigen, kunt u de naam van uw naamruimte opnieuw gebruiken als aliasnaam. Bekijk de voorbeeldcode op GitHub hier.
Voorbeelden
De voorbeelden op GitHub laten zien hoe u een failover kunt instellen en initiëren. In deze voorbeelden worden de volgende concepten gedemonstreerd:
- Een .NET-voorbeeld en -instellingen die zijn vereist in Azure Active Directory voor het gebruik van Azure Resource Manager met Service Bus, om geo-noodherstel in te stellen en in te stellen.
- Stappen die nodig zijn om de voorbeeldcode uit te voeren.
- Een bestaande naamruimte gebruiken als alias.
- Stappen voor het inschakelen van geo-noodherstel via PowerShell of CLI.
- Verzend en ontvang van de huidige primaire of secundaire naamruimte met behulp van de alias .
Overwegingen
Houd rekening met de volgende overwegingen bij deze release:
In uw failoverplanning moet u ook rekening houden met de tijdsfactor. Als u bijvoorbeeld de verbinding langer dan 15 tot 20 minuten verliest, kunt u besluiten om de failover te initiëren.
Het feit dat er geen gegevens worden gerepliceerd, betekent dat actieve sessies momenteel niet worden gerepliceerd. Bovendien werken detectie van duplicaten en geplande berichten mogelijk niet. Nieuwe sessies, nieuwe geplande berichten en nieuwe duplicaten werken.
Als u een complexe gedistribueerde infrastructuur niet kunt gebruiken, moet deze ten minste één keer worden geseed.
Het synchroniseren van entiteiten kan enige tijd duren, ongeveer 50-100 entiteiten per minuut. Abonnementen en regels worden ook als entiteiten geteld.
Beschikbaarheidszones
De Service Bus Premium-SKU ondersteunt Beschikbaarheidszones,waardoor foutgeisoleerde locaties binnen dezelfde Azure-regio worden gebruikt. Service Bus beheert drie kopieën van de berichtenopslag (1 primaire en 2 secundaire). Service Bus worden alle drie de kopieën gesynchroniseerd voor gegevens- en beheerbewerkingen. Als de primaire kopie mislukt, wordt een van de secundaire kopieën zonder waargenomen downtime gepromoveerd naar de primaire kopie. Als de verbinding met de toepassing tijdelijk Service Bus, wordt de logica voor opnieuw proberen in de SDK automatisch opnieuw verbinding met de Service Bus.
Wanneer u beschikbaarheidszones gebruikt, worden metagegevens en gegevens (berichten) gerepliceerd in datacenters in de beschikbaarheidszone.
Notitie
De Beschikbaarheidszones ondersteuning voor Azure Service Bus Premium is alleen beschikbaar in Azure-regio's waar beschikbaarheidszones aanwezig zijn.
U kunt de Beschikbaarheidszones alleen voor nieuwe naamruimten inschakelen met behulp van de Azure Portal. Service Bus biedt geen ondersteuning voor de migratie van bestaande naamruimten. U kunt zone-redundantie niet uitschakelen nadat u deze hebt inschakelen in uw naamruimte.
Privé-eindpunten
Deze sectie bevat meer overwegingen bij het gebruik van geo-noodherstel met naamruimten die gebruikmaken van privé-eindpunten. Zie Azure-eindpunten integreren met Service Bus voor meer informatie over het gebruik van privé Service Bus eindpunten met Azure Private Link.
Nieuwe koppelen
Als u een koppeling probeert te maken tussen een primaire naamruimte met een privé-eindpunt en een secundaire naamruimte zonder een privé-eindpunt, mislukt het koppelen. Het koppelen slaagt alleen als zowel primaire als secundaire naamruimten privé-eindpunten hebben. U wordt aangeraden dezelfde configuraties te gebruiken in de primaire en secundaire naamruimten en in virtuele netwerken waarin privé-eindpunten worden gemaakt.
Notitie
Wanneer u de primaire naamruimte probeert te koppelen aan een privé-eindpunt en de secundaire naamruimte, controleert het validatieproces alleen of er een privé-eindpunt bestaat in de secundaire naamruimte. Er wordt niet gekeken of het eindpunt werkt of werkt na een failover. Het is uw verantwoordelijkheid om ervoor te zorgen dat de secundaire naamruimte met een privé-eindpunt werkt zoals verwacht na een failover.
Als u wilt testen of de configuraties van het privé-eindpunt hetzelfde zijn, verzendt u een aanvraag Wachtrijen ontvangen naar de secundaire naamruimte van buiten het virtuele netwerk en controleert u of u een foutbericht van de service ontvangt.
Bestaande paren
Als het koppelen tussen de primaire en secundaire naamruimte al bestaat, mislukt het maken van een privé-eindpunt in de primaire naamruimte. Als u dit wilt oplossen, maakt u eerst een privé-eindpunt op de secundaire naamruimte en maakt u er vervolgens een voor de primaire naamruimte.
Notitie
Hoewel we alleen-lezentoegang tot de secundaire naamruimte toestaan, zijn updates van de configuraties van het privé-eindpunt toegestaan.
Aanbevolen configuratie
Wanneer u een configuratie voor herstel na noodherstel maakt voor uw toepassing en Service Bus, moet u privé-eindpunten maken voor zowel primaire als secundaire Service Bus-naamruimten voor virtuele netwerken die als host dienen voor zowel primaire als secundaire exemplaren van uw toepassing.
Stel dat u twee virtuele netwerken hebt: VNET-1, VNET-2 en deze primaire en tweede naamruimten: ServiceBus-Namespace1-Primary, ServiceBus-Namespace2-Secondary. U moet de volgende stappen volgen:
- Maak op ServiceBus-Namespace1-Primary twee privé-eindpunten die gebruikmaken van subnetten van VNET-1 en VNET-2
- Maak op ServiceBus-Namespace2-Secondary twee privé-eindpunten die gebruikmaken van dezelfde subnetten van VNET-1 en VNET-2
Het voordeel van deze benadering is dat failover kan plaatsvinden op de toepassingslaag, onafhankelijk van Service Bus naamruimte. Denk eens na over de volgende scenario's:
Alleen-toepassings-failover: Hier bestaat de toepassing niet in VNET-1, maar wordt deze verplaatst naar VNET-2. Omdat beide privé-eindpunten zijn geconfigureerd op zowel VNET-1 als VNET-2 voor zowel primaire als secundaire naamruimten, werkt de toepassing gewoon.
Service Bus-alleen-naamruimte-failover: hier opnieuw, omdat beide privé-eindpunten zijn geconfigureerd op beide virtuele netwerken voor zowel primaire als secundaire naamruimten, werkt de toepassing gewoon.
Notitie
Zie Virtual Network - Bedrijfscontinuïteit voor hulp bij geo-noodherstel van een virtueel netwerk.
Op rollen gebaseerd toegangsbeheer
Azure Active Directory (Azure AD) op rollen gebaseerd toegangsbeheer (RBAC) aan Service Bus-entiteiten in de primaire naamruimte worden niet gerepliceerd naar de secundaire naamruimte. Maak handmatig roltoewijzingen in de secundaire naamruimte om de toegang tot de toewijzingen te beveiligen.
Volgende stappen
- Zie de naslag voor geo-noodherstel REST API hier.
- Voer het voorbeeld van geo-noodherstel uit op GitHub.
- Zie het voorbeeld van geo-noodherstel dat berichten naar een alias verzendt.
Zie de volgende artikelen Service Bus meer informatie over uw berichten: