Delen via

Betrouwbaarheid in Azure Databricks

Azure Databricks is een op Apache Spark gebaseerd gegevens- en AI-platform dat is geoptimaliseerd voor Microsoft Azure. Het biedt een uniforme omgeving voor big data- en AI-workloads en combineert het beste van Databricks en Azure om data engineering, data science en machine learning te vereenvoudigen.

Wanneer u Azure gebruikt, is betrouwbaarheid een gedeelde verantwoordelijkheid. Microsoft biedt een scala aan mogelijkheden ter ondersteuning van tolerantie en herstel. U bent verantwoordelijk voor het begrijpen van de werking van deze mogelijkheden binnen alle services die u gebruikt en het selecteren van de mogelijkheden die u nodig hebt om te voldoen aan uw bedrijfsdoelstellingen en beschikbaarheidsdoelen.

In dit artikel wordt beschreven hoe Azure Databricks tolerantie behoudt tegen verschillende mogelijke storingen en problemen en hoe u tolerantie kunt configureren om aan uw vereisten te voldoen. De richtlijnen hebben betrekking op tijdelijke fouten, storingen in de beschikbaarheidszone, regiostoringen en serviceonderhoud. In dit artikel wordt ook beschreven hoe u back-ups kunt gebruiken om van andere problemen te herstellen, en wordt belangrijke informatie over de SLA (Service Level Agreement) van Azure Databricks benadrukt.

Aanbevelingen voor productie-implementatie

Als u wilt weten hoe u Azure Databricks implementeert ter ondersteuning van de betrouwbaarheidsvereisten van uw oplossing en hoe betrouwbaarheid van invloed is op andere aspecten van uw architectuur, raadpleegt u best practices voor architectuur voor Azure Databricks.

Overzicht van betrouwbaarheidsarchitectuur

U moet de betrouwbaarheid van elk primair onderdeel in Azure Databricks begrijpen:

  • Het besturingsvlak is een verzameling stateless services die werkruimtemetagegevens, gebruikerstoegang, taakplanning en clusterbeheer beheert. Deze services worden ondersteund door databases die worden gerepliceerd in beschikbaarheidszones in ondersteunde regio's.

  • De root van het Databricks File System (DBFS) is een opslagaccount dat Azure Databricks automatisch instelt wanneer u een Azure Databricks-werkruimte in uw cloudaccount maakt. U wordt aangeraden geen gegevens op te slaan in de DBFS-hoofdmap en dit opslagaccount indien mogelijk uit te schakelen.

  • Unity Catalog-opslag bevat een of meer opslagaccounts waarmee uw Unity Catalog-gegevens in uw cloudaccount worden opgeslagen. Zie het overzicht van Unity Catalog voor meer informatie.

  • Het rekenvlak voert gegevensverwerkingsworkloads uit met behulp van clusters van virtuele machines (VM's). Het rekenvlak verwerkt tijdelijke fouten en vervangt mislukte knooppunten automatisch zonder tussenkomst van de gebruiker. U kunt kiezen uit meerdere typen rekenresources. Zie Compute voor meer informatie.

    De beschikbaarheid van de werkruimte is afhankelijk van de beschikbaarheid van het besturingsvlak, maar rekenclusters kunnen taken blijven verwerken, zelfs tijdens onderbrekingen van het besturingsvlak.

Tolerantie voor tijdelijke fouten

Tijdelijke fouten zijn korte, onregelmatige fouten in onderdelen. Ze vinden vaak plaats in een gedistribueerde omgeving, zoals de cloud, en ze zijn een normaal onderdeel van de bewerkingen. Tijdelijke fouten corrigeren zichzelf na een korte periode. Het is belangrijk dat uw toepassingen tijdelijke fouten kunnen afhandelen, meestal door de betreffende aanvragen opnieuw uit te voeren.

Alle in de cloud gehoste toepassingen moeten de richtlijnen voor tijdelijke foutafhandeling van Azure volgen wanneer ze communiceren met eventuele in de cloud gehoste API's, databases en andere onderdelen. Zie Aanbevelingen voor het afhandelen van tijdelijke foutenvoor meer informatie.

U kunt het aantal pogingen voor taken binnen Lakeflow Jobs beheren om te helpen bij het herstellen van tijdelijke fouten.

Voor toepassingen die worden uitgevoerd in Azure Databricks, implementeert u logica voor opnieuw proberen met exponentieel uitstel wanneer u verbinding maakt met externe services of Azure-services, zoals Storage, Azure SQL Database of Azure Event Hubs. Databricks Runtime bevat ingebouwde tolerantie voor veel Azure-services, maar uw toepassingscode moet servicespecifieke tijdelijke fouten verwerken.

Tolerantie voor fouten in beschikbaarheidszones

Beschikbaarheidszones zijn fysiek gescheiden groepen datacenters binnen een Azure-regio. Wanneer één zone uitvalt, kunnen services een failover uitvoeren naar een van de resterende zones.

Azure Databricks ondersteunt zoneredundantie voor elk onderdeel:

  • Besturingsvlak: In regio's die beschikbaarheidszones ondersteunen, wordt het besturingsvlak uitgevoerd in meerdere beschikbaarheidszones. Het besturingsvlak verwerkt zonefouten automatisch, met minimale impact en geen tussenkomst van de gebruiker vereist.

    Werkruimtegegevens van het besturingsvlak worden opgeslagen in databases. In regio's die beschikbaarheidszones ondersteunen, worden de databases gerepliceerd over meerdere zones in de regio. Opslagaccounts die Databricks Runtime-afbeeldingen opslaan, zijn ook redundant binnen de regio. Alle regio's hebben secundaire opslagaccounts die worden gebruikt wanneer het primaire opslagaccount offline is.

  • DBFS-hoofdmap: In regio's die beschikbaarheidszones ondersteunen, kunt u het opslagaccount voor dbFS-hoofdmap configureren voor het gebruik van zone-redundante opslag (ZRS). In gekoppelde regio's die beschikbaarheidszones ondersteunen, kunt u eventueel geografisch zone-redundante opslag (GZRS) gebruiken.

  • Rekenvlak: Databricks ondersteunt automatische zonedistributie voor rekenresources, wat betekent dat uw resources worden verdeeld over meerdere beschikbaarheidszones. Deze distributie helpt uw productiewerkbelastingen veerkrachtig te maken tegen zone-uitval.

    Wanneer u serverloze berekeningen gebruikt, selecteert u niet expliciet zones voor uw berekening. Databricks beheert zoneselectie van VM's en vervanging van VM's die mogelijk verloren gaan vanwege zonestoringen.

Requirements

Als u ondersteuning voor beschikbaarheidszones in Azure Databricks wilt gebruiken, hebt u de volgende vereisten nodig:

Overwegingen

Azure Databricks distribueert automatisch clusterknooppunten over beschikbaarheidszones. De distributie is afhankelijk van de beschikbare capaciteit in elke zone. Tijdens perioden met hoge vraag kunnen de knooppunten van een cluster zich in minder zones concentreren. Wanneer u serverloze berekeningen gebruikt, beheert Azure Databricks zoneselectie van VM's en vervanging van VM's die mogelijk verloren gaan vanwege zonestoringen.

Kosten

Zonedistributie heeft geen invloed op de rekenkosten omdat u betaalt voor hetzelfde aantal VM's, ongeacht de plaatsing van de beschikbaarheidszone. Zie Azure Databricks Compute-prijzen voor meer informatie.

De standaardredundantie voor het beheerde opslagaccount, of de DBFS-hoofdmap, is geografisch redundante opslag (GRS). Als u overschakelen naar ZRS of GZRS, kan dit van invloed zijn op uw opslagkosten. Zie prijzen voor Azure Blob Storage voor meer informatie.

Ondersteuning voor beschikbaarheidszones configureren

  • Besturingsvlak: Het besturingsvlak ondersteunt automatisch zoneredundantie in regio's met beschikbaarheidszones. U hoeft niets te configureren.

  • DBFS-hoofdmap: U kunt zoneredundantie configureren voor DBFS-hoofdopslag wanneer u een nieuwe werkruimte maakt of een bestaande werkruimte wijzigt:

    • Maak een nieuwe werkruimte met zone-redundante DBFS-hoofdopslag: Wanneer u een nieuwe Azure Databricks-werkruimte maakt, kunt u desgewenst het gekoppelde opslagaccount configureren om ZRS of GZRS te gebruiken in plaats van de standaard-GRS. Zie Opties voor opslagredundantie voor werkruimten wijzigen voor meer informatie.

    • Zoneredundantie inschakelen voor DBFS-hoofdopslag: Voor bestaande werkruimten kunt u de redundantieconfiguratie van het werkruimteopslagaccount wijzigen in ZRS of GZRS. Zie Replicatie-instellingen voor een opslagaccount wijzigen voor meer informatie over het inschakelen van zoneredundantie.

  • Rekenvlak: Clusterknooppunten worden automatisch verdeeld over beschikbaarheidszones. Er is geen klantconfiguratie vereist voor zonedistributie.

Gedrag wanneer alle zones in orde zijn

In deze sectie wordt beschreven wat u kunt verwachten wanneer een werkruimte is geconfigureerd met ondersteuning voor beschikbaarheidszones en alle beschikbaarheidszones operationeel zijn.

  • Gegevensreplicatie tussen zones: Gegevensreplicatie voor werkruimteopslag vindt synchroon plaats tussen zones wanneer de DBFS-hoofdmap een ZRS- of GZRS-account gebruikt. Deze aanpak zorgt voor een sterke consistentie met minimale invloed op de prestaties.

  • Verkeersroutering tussen zones: Azure Databricks distribueert automatisch clusterknooppunten over zones tijdens het maken van het cluster. De service verdeelt de rekenbelasting over zones terwijl de locatie van de gegevens wordt behouden voor optimale prestaties.

Gedrag tijdens een zonefout

In deze sectie wordt beschreven wat u kunt verwachten wanneer een werkruimte is geconfigureerd met ondersteuning voor beschikbaarheidszones en er een storing in de beschikbaarheidszone is.

  • Detectie en reactie: Microsoft detecteert automatisch zonefouten en initieert reactieprocedures. U hoeft geen actie te ondernemen voor failover op zoneniveau.

  • Bekendmaking: Microsoft informeert u niet automatisch wanneer een zone niet beschikbaar is. Maar u kunt de statuspagina van Azure Databricks gebruiken om een overzicht te zien van alle kernservices van Azure Databricks. U kunt zich ook abonneren op statusupdates voor afzonderlijke serviceonderdelen en een waarschuwing ontvangen wanneer de status van de service die u abonneert op wijzigingen.

  • Actieve aanvragen: Als u clusters uitvoert, kunnen knooppunten in de getroffen zone verloren gaan. De clusterbeheerder vraagt automatisch vervangende knooppunten van de resterende zones aan. Als het stuurprogrammaknooppunt verloren gaat, worden het cluster en de taak volledig opnieuw opgestart.

  • Verwachte gegevensverlies:

    • Besturingsvlak: Verwacht geen gegevensverlies tijdens een zonestoring.

    • DBFS-hoofdmap: Werkruimtegegevens blijven beschikbaar als er ZRS- of GZRS-opslagconfiguraties worden gebruikt.

    • Rekenvlak: Gegevens die in de cache zijn opgeslagen op VM's, zijn kortstondig. Gegevens die verloren zijn gegaan van VM's tijdens een zonefout, worden hersteld vanuit de opslag. Als het knooppunt van het stuurprogramma verloren gaat, wordt de taak opnieuw opgestart en worden de resultaten opnieuw gecomput.

  • Verwachte downtime:

    • Besturingsvlak: Het Databricks-besturingsvlak voert binnen ongeveer 15 minuten automatische failover uit naar gezonde zones.

    • DBFS-hoofdmap: Verwacht geen downtime voor opslagaccounts die gebruikmaken van ZRS of GZRS.

    • Rekenvlak: Als knooppunten verloren gaan omdat hun VM's zich in de betrokken beschikbaarheidszone bevinden, vraagt de Azure-clusterbeheerder vervangende knooppunten aan bij de Azure-rekenprovider. Als de resterende gezonde zones voldoende capaciteit hebben om aan de aanvraag te voldoen, haalt de rekenprovider knooppunten op uit de gezonde zones om de verloren knooppunten te vervangen. Dit proces kan enkele minuten duren.

      Als het knooppunt van het stuurprogramma verloren gaat vanwege de zonefout, wordt het hele cluster opnieuw opgestart, wat langere hersteltijden kan veroorzaken in vergelijking met het verliezen van werkknooppunten. Plan dit gedrag in uw plannings- en bewakingsstrategieën voor taken.

      U kunt serverloze of exemplaarpools gebruiken om deze tijd te verminderen.

  • Verkeer omleiden:

    • Besturingsvlak: Het Databricks-besturingsvlak voert een automatische failover uit naar gezonde zones binnen ongeveer 15 minuten.

    • DBFS-hoofdmap: Azure Storage stuurt aanvragen automatisch om naar opslagclusters in gezonde zones.

    • Rekenvlak: De clusterbeheerder schakelt automatisch over naar knooppunten in gezonde zones.

Zoneherstel

Wanneer de mislukte beschikbaarheidszone wordt hersteld, hervat Azure Databricks automatisch normale bewerkingen in alle zones. De clusterbeheerder kan de distributie van knooppunten opnieuw verdelen tijdens het maken van volgende knooppunten, maar bestaande knooppunten blijven actief in hun huidige zones totdat ze worden beëindigd.

U hoeft geen actie te ondernemen voor failbackbewerkingen. Normale zonedistributie wordt hervat voor nieuwe clusterimplementaties.

Testen op zonefouten

Azure Databricks is een beheerde service waarbij Microsoft zonefailover automatisch verwerkt en regelmatig zone-downtests uitvoert. U hoeft geen zonefoutscenario's voor de service zelf te testen.

Voor uw toepassingen die worden uitgevoerd in Azure Databricks, test u taaktolerantie door fouten in stuurprogrammaknooppunten te simuleren en gedrag van het opnieuw opstarten van het cluster te bewaken. Controleer of uw gegevensverwerkingstaken het opnieuw opstarten van het cluster kunnen afhandelen en kunnen hervatten vanaf de juiste controlepunten.

Tolerantie voor storingen in de hele regio

Azure Databricks is een service met één regio. Als de regio niet beschikbaar is, is uw werkruimte ook niet beschikbaar. Als u implementaties met meerdere regio's nodig hebt, raadpleegt u Herstel na noodgevallen van Azure Databricks.

Aangepaste oplossingen voor meerdere regio's voor veerkracht

Azure Databricks biedt geen ingebouwde mogelijkheden voor meerdere regio's. Voor uitgebreide beveiliging in meerdere regio's van uw analyseworkloads moet u uw eigen benadering implementeren.

Typische oplossingen voor meerdere regio's hebben betrekking op twee of meer werkruimten. U kunt kiezen uit verschillende strategieën, waaronder actief-passief en actief-actief-architecturen.

Als u een architectuur wilt kiezen, moet u rekening houden met de volgende factoren:

  • De ernst van de workload voor uw bedrijf
  • De mogelijke duur van een onderbreking (uren of mogelijk een volledige dag)
  • De inspanning die nodig is om de werkruimte volledig operationeel te maken
  • De inspanning die nodig is om te herstellen of terug te keren naar de primaire regio

Zie Azure Databricks-herstel na noodgevallen voor workloads waarvoor beveiliging met meerdere regio's is vereist.

Back-up en herstel

Azure Databricks maakt automatisch een back-up van databases als onderdeel van de beheerde bewerkingen van de service. Dit proces omvat notebookinhoud, taakdefinities, clusterconfiguraties en instellingen voor toegangsbeheer.

Opmerking

Als er een zonefout optreedt, verwacht Azure Databricks geen gegevensverlies.

U wordt aangeraden uw gegevens op te slaan in Unity Catalog-opslag. U kunt gegevens repliceren via opslagreplicatie of deltaklonen.

Back-up- en herstelmogelijkheden op werkruimteniveau zijn niet rechtstreeks beschikbaar. Plan voor procedures voor het herstel van werkruimtes, waaronder het herstellen van configuraties, gebruikers en toegangscontroles vanuit uw synchronisatieprocessen.

Tolerantie voor serviceonderhoud

Azure Databricks voert automatisch platformonderhoud uit om beveiligingsupdates toe te passen, nieuwe functies te implementeren en de betrouwbaarheid van de service te verbeteren. U kunt de onderhoudsvensters voor uw cluster configureren om de kans op onderhoud dat van invloed is op uw productieworkloads te verminderen. Zie Automatische clusterupdatevoor meer informatie.

Diensteniveauovereenkomst

De SLA (Service Level Agreement) voor Azure-services beschrijft de verwachte beschikbaarheid van elke service en de voorwaarden waaraan uw oplossing moet voldoen om die beschikbaarheidsverwachting te bereiken. Zie SLA's voor onlineservices voor meer informatie.

Verwante inhoud

  • Last updated on