Checklista för återhämtning för specifika Azure-tjänster

  • Artikel

Elasticitet handlar om möjligheten för ett system att hantera och återställa fel på ett bra sätt. Varje teknik har sina egna fellägen, som du måste tänka på när du utformar och implementerar ditt program. Använd den här checklistan för att granska återhämtningsöverväganden för specifika Azure-tjänster. Mer information om hur du utformar motståndskraftiga program finns i Designa tillförlitliga Azure-program.

App Service

Använd Standard- eller Premium-nivå. Dessa nivåer stöder mellanlagringsplatser och automatiserade säkerhetskopieringar. Mer information finns i Översikt över Azure App Service-planer

Undvik att skala upp eller ned. Välj i stället en nivå- och instansstorlek som uppfyller dina prestandakrav under typisk belastning och skala sedan ut instanserna för att hantera ändringar i trafikvolymen. Upp- och nedskalning kan utlösa en omstart av programmet.

Lagra konfiguration som appinställningar. Använd appinställningar för att lagra konfigurationsinställningar som appinställningar. Definiera inställningarna i dina Resource Manager-mallar eller använd PowerShell, så att du kan tillämpa dem som en del av en automatiserad distribution/uppdateringsprocess, vilket är mer tillförlitligt. Mer information finns i Konfigurera webbappar i Azure App Service.

Skapa separata App Service-planer för produktion och testning. Använd inte platser i produktionsdistributionen för testning. Alla appar i samma App Service-plan delar samma VM-instanser. Om du placerar produktions- och testdistributioner i samma plan kan det påverka produktionsdistributionen negativt. Till exempel kan belastningstester försämra den aktiva produktionsplatsen. Genom att placera testdistributioner i en separat plan isolerar du dem från produktionsversionen.

Separera webbappar från webb-API:er. Om lösningen har både en webbklientdel och ett webb-API kan du överväga att dela upp dem i separata App Service-appar. Den här designen gör det enklare att dela upp lösningen efter arbetsbelastning. Du kan köra webbappen och API:et i separata App Service-planer, så att de kan skalas separat. Om du inte behöver den skalbarhetsnivån först kan du distribuera apparna till samma plan och flytta dem till separata planer senare, om det behövs.

Distribuera zonredundanta App Service-planer. I regioner som stöds kan App Service-planer distribueras som zonredundanta, vilket innebär att instanserna distribueras automatiskt mellan tillgänglighetszoner. App Service distribuerar automatiskt trafik mellan zonerna och hanterar redundansväxling om en zon upplever ett avbrott. Mer information finns i Migrera App Service till stöd för tillgänglighetszoner.

Undvik att använda funktionen För säkerhetskopiering av App Service för att säkerhetskopiera Azure SQL-databaser. Använd i stället automatiserade säkerhetskopieringar i SQL Database. App Service-säkerhetskopiering exporterar databasen till en SQL BACPAC-fil, vilket kostar DTU:er.

Distribuera till en mellanlagringsplats. Skapa ett distributionsfack för mellanlagring. Distribuera programuppdateringar till mellanlagringsplatsen och verifiera distributionen innan du byter den till produktion. Detta minskar risken för en felaktig uppdatering i produktionen. Det säkerställer också att alla instanser värms upp innan de växlas till produktion. Många program har en betydande uppvärmning och kall starttid. Mer information finns i Konfigurera mellanlagringsmiljöer för webbappar i Azure App Service.

Skapa ett distributionsfack för att lagra LKG-distributionen (last-known-good). När du distribuerar en uppdatering till produktion flyttar du den tidigare produktionsdistributionen till LKG-facket. Det gör det enklare att återställa en felaktig distribution. Om du upptäcker ett problem senare kan du snabbt återgå till LKG-versionen. Mer information finns i Grundläggande webbprogram.

Aktivera diagnostikloggning, inklusive programloggning och webbserverloggning. Loggning är viktigt för övervakning och diagnostik. Se Aktivera diagnostikloggning för webbappar i Azure App Service

Logga till bloblagring. Det gör det enklare att samla in och analysera data.

Skapa ett separat lagringskonto för loggar. Använd inte samma lagringskonto för loggar och programdata. Detta hjälper till att förhindra att loggning minskar programmets prestanda.

Övervaka prestanda. Använd en tjänst för prestandaövervakning som New Relic eller Application Insights för att övervaka programmets prestanda och beteende under belastning. Prestandaövervakning ger dig insikter i realtid om programmet. Det gör att du kan diagnostisera problem och utföra rotorsaksanalys av fel.

Azure Load Balancer

Välj Standard SKU. Standard Load Balancer ger en dimension av tillförlitlighet som Basic inte har – tillgänglighetszoner och zonåterhämtning. Det innebär att när en zon slutar fungera påverkas inte din zonredundanta Standard Load Balancer. Detta säkerställer att dina distributioner kan motstå zonfel inom en region. Standard Load Balancer har dessutom stöd för global belastningsutjämning som säkerställer att ditt program inte påverkas av regionfel heller.

Etablera minst två instanser. Distribuera Azure LB med minst två instanser i serverdelen. En enskild instans kan resultera i en felpunkt. För att kunna skapa för skalning kanske du vill koppla lb med vm-skalningsuppsättningar.

Använd regler för utgående trafik. Regler för utgående trafik säkerställer att du inte drabbas av anslutningsfel till följd av SNAT-portöverbelastning. Läs mer om utgående anslutning. Regler för utgående trafik hjälper till att förbättra lösningen för små till medelstora distributioner, men för produktionsarbetsbelastningar rekommenderar vi koppling av Standard Load Balancer eller distribution av undernät med VNet NAT.

Application Gateway

Etablera minst två instanser. Distribuera Application Gateway med minst två instanser. En enskild instans är en felpunkt. Använd två eller flera instanser för redundans och skalbarhet. För att kvalificera dig för serviceavtalet måste du etablera två eller flera medelstora eller större instanser.

Azure Cosmos DB

Konfigurera zonredundans. När du använder zonredundans replikerar Azure Cosmos DB synkront alla skrivningar mellan tillgänglighetszoner. Den redundansväxlar automatiskt i händelse av ett zonfel. Mer information finns i Uppnå hög tillgänglighet med Azure Cosmos DB.

Replikera databasen mellan regioner. Med Azure Cosmos DB kan du associera valfritt antal Azure-regioner med ett Azure Cosmos DB-databaskonto. En Azure Cosmos DB-databas kan ha en skrivregion och flera läsregioner. Om det uppstår ett fel i skrivregionen kan du läsa från en annan replik. Klient-SDK hanterar detta automatiskt. Du kan också redundansväxla skrivregionen till en annan region. Mer information finns i How to distribute data globally with Azure Cosmos DB (Distribuera data globalt med Azure Cosmos DB).

Event Hubs

Använd kontrollpunkter. En händelsekonsument bör skriva sin aktuella position till beständig lagring med ett fördefinierat intervall. På så sätt kan en ny instans återuppta läsningen av strömmen från den senast registrerade positionen om konsumenten upplever ett fel (till exempel om konsumenten kraschar eller om värden misslyckas). Mer information finns i Händelsekonsumenter.

Hantera dubblettmeddelanden. Om en händelsekonsument misslyckas återupptas meddelandebearbetningen från den senast registrerade kontrollpunkten. Alla meddelanden som redan har bearbetats efter den senaste kontrollpunkten bearbetas igen. Därför måste logiken för meddelandebearbetning vara idempotent, annars måste programmet kunna deduplicera meddelanden.

Hantera undantag.. En händelsekonsument bearbetar vanligtvis en batch med meddelanden i en loop. Du bör hantera undantag i den här bearbetningsloopen för att undvika att förlora en hel uppsättning meddelanden om ett enda meddelande orsakar ett undantag.

Använd en kö med obeställbara meddelanden. Om bearbetningen av ett meddelande resulterar i ett icke-tillfälligt fel placerar du meddelandet i en kö med obeställbara meddelanden så att du kan spåra statusen. Beroende på scenariot kan du försöka igen senare, tillämpa en kompenserande transaktion eller vidta någon annan åtgärd. Observera att Event Hubs inte har några inbyggda köfunktioner med obeställbara meddelanden. Du kan använda Azure Queue Storage eller Service Bus för att implementera en kö med obeställbara meddelanden eller använda Azure Functions eller någon annan händelsemekanism.

Konfigurera zonredundans. När zonredundans är aktiverat på ditt namnområde replikerar Event Hubs automatiskt ändringar mellan flera tillgänglighetszoner. Om en tillgänglighetszon misslyckas sker redundans automatiskt. Mer information finns i Tillgänglighetszoner.

Implementera haveriberedskap genom att växla över till ett sekundärt Event Hubs-namnområde. Mer information finns i Geo-haveriberedskap för Azure Event Hubs.

Azure Cache for Redis

Konfigurera zonredundans. När zonredundans är aktiverat i cacheminnet sprider Azure Cache for Redis de virtuella datorer som är värdar för din cache över flera tillgänglighetszoner. Zonredundans ger hög tillgänglighet och feltolerans vid avbrott i datacenter. Mer information finns i Aktivera zonredundans för Azure Cache for Redis.

Konfigurera geo-replikering. Geo-replikering ger en mekanism för att länka två Azure Cache for Redis-instanser på Premium-nivå. Data som skrivs till den primära cachen replikeras till en sekundär skrivskyddad cache. Mer information finns i Konfigurera geo-replikering för Azure Cache for Redis

Konfigurera datapersistence. Med Redis-persistence kan du spara data som lagras i Redis. Du kan också ta ögonblicksbilder och säkerhetskopiera data, som du kan läsa in vid maskinvarufel. Mer information finns i Konfigurera datapersistence för en Azure Cache for Redis på Premium-nivå

Om du använder Azure Cache for Redis som ett tillfälligt datacacheminne och inte som ett beständigt arkiv kanske dessa rekommendationer inte gäller.

Etablera mer än en replik. Använd minst två repliker för hög lästillgänglighet eller tre för hög tillgänglighet för läsning och skrivning.

Använd zonredundans. Du kan distribuera Cognitive Search-repliker i flera tillgänglighetszoner. Den här metoden hjälper din tjänst att fortsätta fungera även vid avbrott i datacenter. Mer information finns i Tillförlitlighet i Azure Cognitive Search

Konfigurera indexerare för distributioner i flera regioner. Om du har en distribution i flera regioner bör du överväga dina alternativ för kontinuitet i indexering.

  • Om datakällan är geo-replikerad bör du vanligtvis peka varje indexerare för varje regional Azure Cognitive-tjänsten Search till dess lokala datakällreplik. Den metoden rekommenderas dock inte för stora datamängder som lagras i Azure SQL Database. Anledningen är att Azure Cognitive Search inte kan utföra inkrementell indexering från sekundära SQL Database-repliker, endast från primära repliker. Peka i stället alla indexerare på den primära repliken. Efter en redundansväxling pekar du Azure Cognitive Search-indexerarna på den nya primära repliken.

  • Om datakällan inte är geo-replikerad pekar du flera indexerare vid samma datakälla, så att Azure Cognitive tjänsten Search i flera regioner kontinuerligt och oberoende index från datakällan. Mer information finns i Prestanda- och optimeringsöverväganden för Azure Search.

Service Bus

Använd Premium-nivån för produktionsarbetsbelastningar. Service Bus Premium Messaging tillhandahåller dedikerade och reserverade bearbetningsresurser samt minneskapacitet för förutsägbar prestanda och dataflöde. Premium Messaging-nivån ger dig också åtkomst till nya funktioner som endast är tillgängliga för Premium-kunder till en början. Du kan bestämma antalet meddelandeenheter baserat på förväntade arbetsbelastningar.

Hantera dubblettmeddelanden. Om en utgivare misslyckas omedelbart efter att ha skickat ett meddelande eller upplever nätverksproblem eller systemproblem kan det felaktigt misslyckas med att registrera att meddelandet levererades och kan skicka samma meddelande till systemet två gånger. Service Bus kan hantera det här problemet genom att aktivera dubblettidentifiering. Mer information finns i Dubblettidentifiering.

Hantera undantag. API:er för meddelanden genererar undantag när ett användarfel, konfigurationsfel eller annat fel inträffar. Klientkoden (avsändare och mottagare) ska hantera dessa undantag i koden. Detta är särskilt viktigt vid batchbearbetning, där undantagshantering kan användas för att undvika att förlora en hel uppsättning meddelanden. Mer information finns i Undantag för Service Bus-meddelanden.

Återförsöksprincip. Med Service Bus kan du välja den bästa återförsöksprincipen för dina program. Standardprincipen är att tillåta 9 maximala återförsöksförsök och vänta i 30 sekunder, men detta kan justeras ytterligare. Mer information finns i Återförsöksprincip – Service Bus.

Använd en kö med obeställbara meddelanden. Om ett meddelande inte kan bearbetas eller levereras till en mottagare efter flera återförsök flyttas det till en kö med obeställbara meddelanden. Implementera en process för att läsa meddelanden från kön med obeställbara meddelanden, inspektera dem och åtgärda problemet. Beroende på scenariot kan du försöka igen i den här situationen, göra ändringar och försöka igen eller ignorera meddelandet. Mer information finns i Översikt över Service Bus-köer med obeställbara meddelanden.

Använd zonredundans. När zonredundans är aktiverat i namnområdet replikerar Service Bus automatiskt ändringar mellan flera tillgänglighetszoner. Om en tillgänglighetszon misslyckas sker redundans automatiskt. Mer information finns i Metodtips för att isolera program mot Service Bus-avbrott och katastrofer.

Använd Geo-Haveriberedskap. Geo-haveriberedskap säkerställer att databehandlingen fortsätter att fungera i en annan region eller ett annat datacenter om en hel Azure-region eller ett helt datacenter blir otillgängligt på grund av en katastrof. Mer information finns i Geo-haveriberedskap för Azure Service Bus.

Lagring

Använd zonredundant lagring. Zonredundant lagring (ZRS) kopierar dina data synkront över tre Azure-tillgänglighetszoner i den primära regionen. Om ett avbrott uppstår i en tillgänglighetszon redundansväxlar Azure Storage automatiskt till en alternativ zon. Läs mer i Redundansalternativ för Azure Storage.

När du använder geo-redundans konfigurerar du läsåtkomst. Om du använder en arkitektur för flera regioner använder du en lämplig lagringsnivå för global redundans. Med RA-GRS eller RA-GZRS replikeras dina data till en sekundär region. RA-GRS använder lokalt redundant lagring (LRS) i den primära regionen, medan RA-GZRS använder zonredundant lagring (ZRS) i den primära regionen. Båda konfigurationerna ger skrivskyddad åtkomst till dina data i den sekundära regionen. Om det uppstår ett lagringsstopp i den primära regionen kan programmet läsa data från den sekundära regionen om du har utformat dem för den här möjligheten. Läs mer i Redundansalternativ för Azure Storage.

Använd hanterade diskar för virtuella datordiskar.Hanterade diskar ger bättre tillförlitlighet för virtuella datorer i en tillgänglighetsuppsättning, eftersom diskarna är tillräckligt isolerade från varandra för att undvika enskilda felpunkter. Hanterade diskar omfattas inte heller av IOPS-gränserna för virtuella hårddiskar som skapats i ett lagringskonto. Mer information finns i Hantera tillgängligheten för virtuella Windows-datorer i Azure.

För Kölagring skapar du en säkerhetskopieringskö i en annan region. För Queue Storage har en skrivskyddad replik begränsad användning eftersom du inte kan köa eller ta bort objekt. Skapa i stället en säkerhetskopieringskö på ett lagringskonto i en annan region. Om det uppstår ett Avbrott i Azure Storage kan programmet använda säkerhetskopieringskön tills den primära regionen blir tillgänglig igen. På så sätt kan programmet fortsätta att bearbeta nya begäranden under driftstoppet.

SQL Database

Använd Standard- eller Premium-nivå. Dessa nivåer ger en längre återställningsperiod för tidpunkt (35 dagar). Mer information finns i SQL Database-alternativ och prestanda.

Aktivera SQL Database-granskning. Granskning kan användas för att diagnostisera skadliga attacker eller mänskliga fel. Mer information finns i Komma igång med SQL-databasgranskning.

Använd Active Geo-Replication Använd Aktiv geo-replikering för att skapa en läsbar sekundär i en annan region. Om din primära databas misslyckas eller helt enkelt behöver kopplas från utför du en manuell redundansväxling till den sekundära databasen. Tills du redundansväxlar förblir den sekundära databasen skrivskyddad. Mer information finns i SQL Database Active Geo-Replication.

Använd horisontell partitionering. Överväg att använda horisontell partitionering för att partitionera databasen vågrätt. Horisontell partitionering kan ge felisolering. Mer information finns i Skala ut med Azure SQL Database.

Använd återställning till tidpunkt för att återställa från mänskliga fel. Återställning till tidpunkt returnerar databasen till en tidigare tidpunkt. Mer information finns i Återställa en Azure SQL-databas med hjälp av automatiserade databassäkerhetskopior.

Använd geo-återställning för att återställa från ett tjänststopp. Geo-återställning återställer en databas från en geo-redundant säkerhetskopia. Mer information finns i Återställa en Azure SQL-databas med hjälp av automatiserade databassäkerhetskopior.

Azure Synapse Analytics

Inaktivera inte geo-säkerhetskopiering. Som standard tar Synapse Analytics en fullständig säkerhetskopia av dina data i en dedikerad SQL-pool var 24:e timme för haveriberedskap. Vi rekommenderar inte att du inaktiverar den här funktionen. Mer information finns i Geo-säkerhetskopior.

SQL Server som körs på en virtuell dator

Säkerhetskopiera databasen. Om du redan använder Azure Backup för att säkerhetskopiera dina virtuella datorer kan du överväga att använda Azure Backup för SQL Server-arbetsbelastningar med DPM. Med den här metoden finns det en administratörsroll för säkerhetskopiering för organisationen och en enhetlig återställningsprocedur för virtuella datorer och SQL Server. Annars använder du SQL Server Managed Backup till Microsoft Azure.

Traffic Manager

Utför manuell återställning efter fel. Efter en Traffic Manager-redundans utför du manuell återställning efter fel i stället för att automatiskt återställa. Kontrollera att alla programundersystem är felfria innan du misslyckas igen. Annars kan du skapa en situation där programmet vänder fram och tillbaka mellan datacenter. Mer information finns i Köra virtuella datorer i flera regioner för hög tillgänglighet.

Skapa en slutpunkt för hälsoavsökning. Skapa en anpassad slutpunkt som rapporterar om programmets övergripande hälsotillstånd. Detta gör att Traffic Manager kan redundansväxla om någon kritisk sökväg misslyckas, inte bara klientdelen. Slutpunkten ska returnera en HTTP-felkod om något kritiskt beroende är felfritt eller inte kan nås. Rapportera dock inte fel för icke-kritiska tjänster. Annars kan hälsoavsökningen utlösa redundans när den inte behövs, vilket skapar falska positiva identifieringar. Mer information finns i Traffic Manager-slutpunktsövervakning och redundans.

Virtual Machines

Undvik att köra en produktionsarbetsbelastning på en enskild virtuell dator. En distribution av en enskild virtuell dator är inte motståndskraftig mot planerat eller oplanerat underhåll. Placera i stället flera virtuella datorer i en tillgänglighetsuppsättning eller vm-skalningsuppsättning med en lastbalanserare framför.

Ange en tillgänglighetsuppsättning när du etablerar den virtuella datorn. För närvarande finns det inget sätt att lägga till en virtuell dator i en tillgänglighetsuppsättning när den virtuella datorn har etablerats. När du lägger till en ny virtuell dator i en befintlig tillgänglighetsuppsättning måste du skapa ett nätverkskort för den virtuella datorn och lägga till nätverkskortet i serverdelsadresspoolen i lastbalanseraren. Annars dirigerar lastbalanseraren inte nätverkstrafik till den virtuella datorn.

Placera varje programnivå i en separat tillgänglighetsuppsättning. Placera inte virtuella datorer från olika nivåer i samma tillgänglighetsuppsättning i ett N-nivåprogram. Virtuella datorer i en tillgänglighetsuppsättning placeras mellan feldomäner (FD) och uppdateringsdomäner (UD). Men för att få redundansförmånen för FD:er och UD:er måste varje virtuell dator i tillgänglighetsuppsättningen kunna hantera samma klientbegäranden.

Replikera virtuella datorer med Azure Site Recovery. När du replikerar virtuella Azure-datorer med Site Recovery replikeras alla virtuella datordiskar kontinuerligt till målregionen asynkront. Återställningspunkterna skapas med några minuters mellanrum. Detta ger dig ett mål för återställningspunkt (RPO) i storleksordningen minuter. Du kan utföra haveriberedskapstest så många gånger du vill, utan att påverka produktionsprogrammet eller den pågående replikeringen. Mer information finns i Köra ett haveriberedskapstest till Azure.

Välj rätt VM-storlek baserat på prestandakrav. När du flyttar en befintlig arbetsbelastning till Azure börjar du med den VM-storlek som är närmast dina lokala servrar. Mät sedan prestandan för din faktiska arbetsbelastning med avseende på CPU, minne och disk-IOPS och justera storleken om det behövs. Detta hjälper till att säkerställa att programmet fungerar som förväntat i en molnmiljö. Om du behöver flera nätverkskort bör du också vara medveten om NIC-gränsen för varje storlek.

Använd hanterade diskar för virtuella hårddiskar.Hanterade diskar ger bättre tillförlitlighet för virtuella datorer i en tillgänglighetsuppsättning, eftersom diskarna är tillräckligt isolerade från varandra för att undvika enskilda felpunkter. Hanterade diskar omfattas inte heller av IOPS-gränserna för virtuella hårddiskar som skapats i ett lagringskonto. Mer information finns i Hantera tillgängligheten för virtuella Windows-datorer i Azure.

Installera program på en datadisk, inte os-disken. Annars kan du nå diskstorleksgränsen.

Använd Azure Backup för att säkerhetskopiera virtuella datorer. Säkerhetskopior skyddar mot oavsiktlig dataförlust. Mer information finns i Skydda virtuella Azure-datorer med ett Recovery Services-valv.

Aktivera diagnostikloggar. Inkludera grundläggande hälsomått, infrastrukturloggar och startdiagnostik. Startdiagnostik kan hjälpa dig att diagnostisera ett startfel om den virtuella datorn hamnar i ett tillstånd som inte är startbart. Mer information finns i Översikt över Azure-diagnostikloggar.

Konfigurera Azure Monitor. Samla in och analysera övervakningsdata från virtuella Azure-datorer, inklusive gästoperativsystemet och de arbetsbelastningar som körs i den, se Azure Monitor och Snabbstart: Azure Monitor.

Virtual Network

Om du vill tillåta eller blockera offentliga IP-adresser lägger du till en nätverkssäkerhetsgrupp i undernätet. Blockera åtkomst från skadliga användare eller tillåt endast åtkomst från användare som har behörighet att komma åt programmet.

Skapa en anpassad hälsoavsökning. Load Balancer Health-avsökningar kan testa HTTP eller TCP. Om en virtuell dator kör en HTTP-server är HTTP-avsökningen en bättre indikator på hälsostatus än en TCP-avsökning. För en HTTP-avsökning använder du en anpassad slutpunkt som rapporterar programmets övergripande hälsa, inklusive alla kritiska beroenden. Mer information finns i Översikt över Azure Load Balancer.

Blockera inte hälsoavsökningen. Load Balancer Health-avsökningen skickas från en känd IP-adress, 168.63.129.16. Blockera inte trafik till eller från den här IP-adressen i några brandväggsprinciper eller regler för nätverkssäkerhetsgrupper. Om hälsoavsökningen blockeras skulle lastbalanseraren ta bort den virtuella datorn från rotationen.

Aktivera loggning av lastbalanserare. Loggarna visar hur många virtuella datorer på serverdelen som inte tar emot nätverkstrafik på grund av misslyckade avsökningssvar. Mer information finns i Log Analytics för Azure Load Balancer.