Delen via

Oplossingen voor bedrijfscontinuïteit en herstel na noodgevallen maken met Azure Data Explorer

In dit artikel wordt beschreven hoe u zich kunt voorbereiden op een regionale storing in Azure door uw Azure Data Explorer-resources, -beheer en -opname in verschillende Azure-regio's te repliceren. Er wordt een voorbeeld gegeven van gegevensopname met Azure Event Hubs. Kostenoptimalisatie wordt ook besproken voor verschillende architectuurconfiguraties. Zie het overzicht van bedrijfscontinuïteit voor een uitgebreider overzicht van architectuuroverwegingen en hersteloplossingen.

Voorbereiden op regionale storing in Azure om uw gegevens te beveiligen

Azure Data Explorer biedt geen ondersteuning voor automatische beveiliging tegen de storing van een hele Azure-regio. Deze onderbreking kan optreden tijdens een natuurramp, zoals een aardbeving. Als u een oplossing nodig hebt voor een noodherstelsituatie, voert u de volgende stappen uit om de bedrijfscontinuïteit te waarborgen. In deze stappen repliceert u uw clusters, beheer en gegevensopname in twee gekoppelde Azure-regio's.

  1. Maak twee of meer onafhankelijke clusters in twee gekoppelde Azure-regio's.
  2. Repliceer alle beheeractiviteiten , zoals het maken van nieuwe tabellen of het beheren van gebruikersrollen op elk cluster.
  3. Gegevens parallel opnemen in elk cluster.

Meerdere onafhankelijke clusters maken

Maak meer dan één Azure Data Explorer-cluster in meer dan één regio. Zorg ervoor dat ten minste twee van deze clusters zijn gemaakt in gekoppelde Azure-regio's.

In de volgende afbeelding ziet u replica's, drie clusters in drie verschillende regio's.

Maak onafhankelijke clusters.

Beheeractiviteiten repliceren

Repliceer de beheeractiviteiten om dezelfde clusterconfiguratie in elke replica te hebben.

  1. Maak op elke replica hetzelfde:

  2. Beheer de verificatie en autorisatie op elke replica.

    Dubbele beheeractiviteiten.

Oplossing voor herstel na noodgevallen met event hub-ingestie

Zodra u de voorbereiding op een regionale storing in Azure om uw gegevens te beschermen hebt voltooid, worden uw gegevens en beheer verspreid over meerdere regio's. Als er een storing optreedt in één regio, kan Azure Data Explorer de andere replica's gebruiken.

Gegevensinvoer instellen met behulp van een Event Hub

Als u gegevens van Azure Event Hubs wilt opnemen in het Azure Data Explorer-cluster van elke regio, moet u eerst uw Azure Event Hubs-installatie in elke regio repliceren. Configureer vervolgens de Azure Data Explorer-replica van elke regio om gegevens op te nemen uit de bijbehorende Event Hubs.

Opmerking

Gegevensinvoer door Azure Event Hubs/IoT Hub/Storage is robuust. Als een cluster gedurende een bepaalde periode niet beschikbaar is, zal het later de synchronisatie herstellen en eventuele openstaande berichten of blobs invoegen. Dit proces is afhankelijk van controlepunten.

Opnemen via Azure Event Hubs.

Zoals in het onderstaande diagram wordt weergegeven, sturen uw gegevensbronnen gebeurtenissen naar Event Hubs in alle regio's, en elke Azure Data Explorer-replica verbruikt de gebeurtenissen. Gegevensvisualisatiecomponenten zoals Power BI, Grafana, of WebApps aangedreven door een SDK, kunnen een query uitvoeren op een van de replica's.

Gegevensbronnen voor gegevensvisualisatie.

Kosten optimaliseren

U bent nu klaar om uw replica's te optimaliseren met behulp van een aantal van de volgende methoden:

Een configuratie voor gegevensherstel op aanvraag maken

Het repliceren en bijwerken van de Azure Data Explorer-installatie verhoogt de kosten lineair met het aantal replica's. Als u de kosten wilt optimaliseren, kunt u een architectuurvariant implementeren om de tijd, failover en kosten in balans te brengen. In een configuratie voor gegevensherstel op aanvraag is kostenoptimalisatie geïmplementeerd door passieve Azure Data Explorer-replica's te introduceren. Deze replica's zijn alleen ingeschakeld als er een noodgeval is in de primaire regio (bijvoorbeeld regio A). De replica's in regio's B en C hoeven niet 24/7 actief te zijn, waardoor de kosten aanzienlijk worden verlaagd. In de meeste gevallen zijn de prestaties van deze replica's echter niet zo goed als het primaire cluster. Zie De configuratie voor gegevensherstel op aanvraag voor meer informatie.

In de onderstaande afbeelding neemt slechts één cluster gegevens op uit de Event Hub. Het primaire cluster in regio A voert continue gegevensexport uit van alle gegevens naar een opslagaccount. De secundaire replica's hebben toegang tot de gegevens met behulp van externe tabellen.

architectuur voor een configuratie voor gegevensherstel op aanvraag.

De replica's starten en stoppen

U kunt de secundaire replica's starten en stoppen met een van de volgende methoden:

az kusto cluster stop --name=<clusterName> --resource-group=<rgName> --subscription=<subscriptionId>"

Een maximaal beschikbare toepassingsservice implementeren

De AZURE App Service BCDR-client maken

In deze sectie wordt beschreven hoe u een Azure App Service maakt die ondersteuning biedt voor een verbinding met één primaire en meerdere secundaire Azure Data Explorer-clusters. In de volgende afbeelding ziet u de installatie van Azure App Service.

Maak een Azure App Service.

Aanbeveling

Als u meerdere verbindingen tussen replica's in dezelfde service hebt, hebt u meer beschikbaarheid. Deze installatie is niet alleen nuttig in gevallen van regionale storingen.

  1. Gebruik deze standaardcode voor een app-service. Als u een client met meerdere clusters wilt implementeren, is de AdxBcdrClient-klasse gemaakt. Elke query die met deze client wordt uitgevoerd, wordt eerst naar het primaire cluster verzonden. Als er een fout optreedt, wordt de query verzonden naar secundaire replica's.

  2. Gebruik aangepaste metrische gegevens van Application Insights om prestaties te meten en distributie aan te vragen naar primaire en secundaire clusters.

De BCDR-client van Azure App Service testen

We hebben een test uitgevoerd met behulp van meerdere Azure Data Explorer-replica's. Na een gesimuleerde storing van primaire en secundaire clusters kunt u zien dat de BCDR-client van de app-service werkt zoals bedoeld.

Controleer de BCDR-client van de appservice.

De Azure Data Explorer-clusters worden verdeeld over Europa - west (primair 2xD14v2), Azië - zuidoost en VS - oost (2xD11v2).

Reactietijd van query's op meerdere planeten.

Opmerking

Tragere reactietijden worden veroorzaakt door verschillende SKU's en query's op meerdere planeten.

Dynamische of statische routering uitvoeren

Gebruik Azure Traffic Manager-routeringsmethoden voor dynamische of statische routering van de aanvragen. Azure Traffic Manager is een load balancer op basis van DNS waarmee u app-serviceverkeer kunt distribueren. Dit verkeer is geoptimaliseerd voor services in wereldwijde Azure-regio's en biedt hoge beschikbaarheid en reactiesnelheid.

U kunt ook routering op basis van Azure Front Door gebruiken. Zie Taakverdeling met de leveringssuite van Azure voor toepassingen voor vergelijking van deze twee methoden.

Kosten optimaliseren in een actief-actief-configuratie

Het gebruik van een actief-actief-configuratie voor herstel na noodgevallen verhoogt de kosten lineair. De kosten omvatten knooppunten, opslag, markeringen en hogere netwerkkosten voor bandbreedte.

Geoptimaliseerde automatische schaalaanpassing gebruiken om de kosten te optimaliseren

Gebruik de geoptimaliseerde functie voor automatische schaalaanpassing om horizontaal schalen voor de secundaire clusters te configureren. Ze moeten worden gedimensioneerd, zodat ze de opnamebelasting kunnen verwerken. Zodra het primaire cluster niet bereikbaar is, krijgen de secundaire clusters meer verkeer en worden ze geschaald op basis van de configuratie.

Het gebruik van geoptimaliseerde automatische schaalaanpassing in dit voorbeeld heeft ongeveer 50% van de kosten bespaard in vergelijking met dezelfde horizontale en verticale schaal op alle replica's.

Verwante inhoud

  • Last updated on