Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
In dit artikel wordt uitgelegd hoe u zich voorbereidt op een regionale storing van Azure door uw Azure Data Explorer resources, beheer en opname in verschillende Azure regio's te repliceren. Het artikel bevat een voorbeeld van gegevensopname met Azure Event Hubs. Ook worden kostenoptimalisatie voor verschillende architectuurconfiguraties besproken. 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 noodhersteloplossing nodig hebt, volgt u deze stappen om bedrijfscontinuïteit te garanderen. In deze stappen repliceert u uw clusters, beheeractiviteiten en gegevensopname in twee Azure gekoppelde regio's.
- Maak twee of meer onafhankelijke clusters in twee gekoppelde Azure-regio's.
- Repliceer alle beheeractiviteiten , zoals het maken van nieuwe tabellen of het beheren van gebruikersrollen op elk cluster.
- Gegevens parallel opnemen in elk cluster.
Meerdere onafhankelijke clusters maken
Maak meer dan één Azure Data Explorer-cluster in meer dan één regio. Maak ten minste twee van deze clusters in Azure gekoppelde regio's.
In het volgende diagram ziet u drie replicaclusters in drie verschillende regio's.
Beheeractiviteiten repliceren
Beheeractiviteiten repliceren zodat elke replica dezelfde clusterconfiguratie heeft.
Maak dezelfde resources op elke replica:
- Databases: Gebruik de Azure-portal of een van de SDK's om een nieuwe database te maken.
- Tabellen
- Koppelingen
- Beleidsregels
Beheer de verificatie en autorisatie op elke replica.
Oplossing voor herstel na noodgevallen met behulp van Event Hubs-opname
Nadat u Voorbereiden voor Azure regionale storing hebt voltooid om uw gegevens te beschermen, Azure Data Explorer uw gegevens en beheer opslaat in meerdere regio's. Als er een storing in de ene regio is, kan Azure Data Explorer de andere replica's gebruiken.
Gegevensinname instellen met Event Hubs
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
Gegevensopname via Azure Event Hubs, IoT Hub of Storage is betrouwbaar. Als een cluster tijdelijk niet beschikbaar is, haalt het die achterstand later in en voegt het eventuele wachtende berichten of blobs in. Dit proces is afhankelijk van controlepunten.
In dit diagram ziet u dat uw gegevensbronnen gebeurtenissen produceren voor Event Hubs in alle regio's en dat elke Azure Data Explorer replica deze gebeurtenissen verbruikt. Onderdelen van gegevensvisualisatie, zoals Power BI, Grafana of met SDK gemaakte web-apps, kunnen een query uitvoeren op één replica.
Kosten optimaliseren
U bent nu klaar om uw replica's te optimaliseren met behulp van een aantal van de volgende methoden:
- Maak een configuratie voor gegevensherstel op aanvraag.
- Start en stop de replica's.
- Implementeer een maximaal beschikbare toepassingsservice.
- Kosten optimaliseren in een actief-actief-configuratie.
Een configuratie voor gegevensherstel op aanvraag maken
Het repliceren en bijwerken van de Azure Data Explorer installatie verhoogt de kosten naarmate het aantal replica's toeneemt. Implementeer een architectuurvariant die tijd, failover en kosten in balans brengt om de kosten te optimaliseren. Een configuratie voor gegevensherstel op aanvraag optimaliseert de kosten met behulp van passieve Azure Data Explorer replica's. 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. Maar in de meeste gevallen worden deze replica's niet uitgevoerd en het primaire cluster. Zie De configuratie voor gegevensherstel op aanvraag voor meer informatie.
In het volgende diagram neemt slechts één cluster gegevens op uit Event Hubs. 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.
De replica's starten en stoppen
Start en stop de secundaire replica's met behulp van een van de volgende methoden:
De knop Stoppen op het tabblad Overzicht in Azure Portal. Zie Het cluster stoppen en opnieuw opstarten voor meer informatie.
Azure CLI:
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.
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.
Gebruik deze standaardcode voor een app-service. Als u een multiclusterclient wilt implementeren, gebruikt u de adxBcdrClient-klasse . Elke query die door deze client wordt uitgevoerd, wordt eerst naar het primaire cluster verzonden. Als er een fout optreedt, wordt de query verzonden naar secundaire replica's.
Gebruik aangepaste metrische gegevens van Application Insights om de prestaties en de verdeling van aanvragen over primaire en secundaire clusters te meten.
De BCDR-client van Azure App Service testen
De volgende test maakt gebruik van meerdere Azure Data Explorer replica's. Na een gesimuleerde storing van primaire en secundaire clusters gedraagt de BCDR-client van App Service zich zoals bedoeld.
De Azure Data Explorer-clusters worden verdeeld over Europa - west (primair 2xD14v2), Azië - zuidoost en VS - oost (2xD11v2).
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 aanvraagroutering. Azure Traffic Manager is een load balancer op basis van DNS die u kunt gebruiken om App Service-verkeer te 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. Grootte van secundaire clusters voor het afhandelen van de opnamebelasting. Wanneer het primaire cluster niet bereikbaar is, krijgen secundaire clusters meer verkeer en schalen volgens de configuratie.
In dit voorbeeld bespaart geoptimaliseerde automatische schaalaanpassing ongeveer 50% in kosten in vergelijking met het gebruik van dezelfde horizontale en verticale schaal op alle replica's.