Checklista för återhämtning för specifika Azure-tjänster
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 specifika 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 elastiska program finns i Utforma 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 Azure App Service detaljerad översikt över planer
Undvik att skala upp eller ned. Välj i stället en nivå och instansstorlek som uppfyller dina prestandakrav under normal 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 innehålla konfigurationsinställningar som appinställningar. Definiera inställningarna i dina Resource Manager- eller PowerShell-mallar så att du kan tillämpa dem som en del av en automatiserad distribution/uppdateringsprocess som är mer tillförlitlig. Mer information finns i Konfigurera webbappar i Azure App Service.
Skapa separata App Service för produktion och testning. Använd inte platser i produktionsdistributionen för testning. Alla appar inom samma App Service plan delar samma VM-instanser. Om du lägger till produktions- och testdistributioner i samma plan kan det påverka produktionsdistributionen negativt. Belastningstester kan till exempel försämra den direktsända 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 frontwebb och ett webb-API bör du överväga att dela upp dem i separata App Service appar. Den här designen gör det enklare att uppdela lösningen efter arbetsbelastning. Du kan köra webbappen och API:et i App Service planer så att de kan skalas oberoende av varandra. 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.
Undvik att använda funktionen App Service säkerhetskopiering för att säkerhetskopiera Azure SQL databaser. Använd i stället SQL Database automatisk säkerhetskopiering. App Service säkerhetskopiering exporterar databasen till en SQL BACPAC-fil, vilket kostar DPU:er.
Distribuera till en mellanlagringsplats. Skapa ett distributionsfack för mellanlagring. Distribuera programuppdateringar till mellanlagringsplatsen och verifiera distributionen innan du växlar den till produktion. Detta minskar risken för en felaktig uppdatering i produktion. Det säkerställer också att alla instanser värmes upp innan de växlas till produktion. Många program har en betydande uppvärmnings- och kallstartstid. Mer information finns i Konfigurera mellanlagringsmiljöer för webbappar i Azure App Service.
Skapa ett distributionsfack för LKG-distributionen (last known-good). När du distribuerar en uppdatering till produktion flyttar du den tidigare produktionsdistributionen till LKG-platsen. Detta 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 webbapp.
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 in på Blob Storage. Detta 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 bidrar till att förhindra att loggning minskar programmets prestanda.
Övervaka prestanda. Använd en tjänst för prestandaövervakning, till exempel New Relic program eller Insights för att övervaka programmets prestanda och beteende under belastning. Prestandaövervakning ger dig insyn i programmet i realtid. 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åter återhämtning. Det innebär att zonredundant lagring inte påverkas när Standard Load Balancer hamnar i drift. Detta säkerställer att dina distributioner kan hantera zonfel inom en region. Dessutom stöder Standard Load Balancer global belastningsutjämning för att säkerställa att ditt program inte påverkas av regionfel heller.
Etablera minst två instanser Distribuera Azure LB med minst två instanser i backend. En enda instans kan resultera i en enskild felpunkt. För att kunna skapa för skalning kanske du vill koppla lb med Virtual Machine Scale Sets.
Använda regler för utgående trafik Regler för utgående trafik ser till att du inte får problem med anslutningsfel på grund av SNAT-portutmattning. Läs mer om utgående anslutningar. Utgående regler hjälper till att förbättra lösningen för små till medelstora distributioner, men för produktionsarbetsbelastningar rekommenderar vi koppling Standard Load Balancer eller undernätsdistribution 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 kunna kvalificera dig för serviceavtaletmåste du etablera två eller flera medelstora eller större instanser.
Cosmos DB
Replikera databasen mellan regioner. Cosmos DB kan du associera val av antal Azure-regioner med ett Cosmos DB databaskonto. En 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å redundans växla över 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 dataströmmen från den senast registrerade positionen om konsumenten får ett fel (till exempel om konsumenten kraschar eller om värden kraschar). 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, eller så 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 batch med meddelanden om ett enskilt meddelande orsakar ett undantag.
Använd en kö för dead-letter. Om bearbetningen av ett meddelande resulterar i ett icke-övergående fel lägger du meddelandet i en kö för obeställbara meddelanden så att du kan spåra statusen. Beroende på scenariot kan du försöka skicka meddelandet igen senare, använda en kompenserande transaktion eller utföra någon annan åtgärd. Observera att Event Hubs inte har några inbyggda funktioner för köer utan meddelanden. Du kan använda Azure Queue Storage eller Service Bus för att implementera en kö för dead-letter eller använda Azure Functions eller någon annan händelsemekanism.
Implementera haveriberedskap genom att gå över till en sekundär Event Hubs namnområde. Mer information finns i Azure Event Hubs geo-haveriberedskap.
Azure Cache for Redis
Konfigurera geo-replikering. Geo-replikering ger en mekanism för att länka två Premium-nivå Azure Cache for Redis instanser. Data som skrivs till den primära cachen replikeras till en sekundär skrivskyddad cache. Mer information finns i Så här konfigurerar du geo-replikering för Azure Cache for Redis
Konfigurera datapersistence. Med Redis-beständighet kan du bevara data som lagras i Redis. Du kan också ta ögonblicksbilder och säkerhetskopiera data, som du kan läsa in i händelse av maskinvarufel. Mer information finns i Så här konfigurerar du datapersistence för en Premium-nivå Azure Cache for Redis
Om du använder Azure Cache for Redis som en tillfällig datacache och inte som ett beständigt lager, kanske dessa rekommendationer inte gäller.
Sök
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.
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 indexeringen.
Om datakällan är geo-replikerad bör du normalt peka varje indexerare för varje regional Azure-tjänsten Search till dess lokala datakällreplik. Den metoden rekommenderas dock inte för stora datamängder som lagras i Azure SQL Database. Orsaken är att Azure 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 till den primära repliken. Efter en redundans, peka Azure Search-indexerare på den nya primära repliken.
Om datakällan inte är geo-replikerad pekar du flera indexerare på samma datakälla, så att Azure Search-tjänster i flera regioner kontinuerligt och oberoende indexerar 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 och minneskapacitet för att stödja förutsägbar prestanda och dataflöde. Premium-meddelandenivån ger dig också tillgång till nya funktioner som endast är tillgängliga för Premium-kunder först. Du kan bestämma antalet meddelandefunktionsenheter baserat på förväntade arbetsbelastningar.
Hantera dubblettmeddelanden. Om en utgivare misslyckas omedelbart efter att ett meddelande har skickats, eller om det har problem med nätverket eller systemet, kan det felaktigt misslyckas med att registrera att meddelandet har levererats 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. Meddelande-API:er genererar undantag när ett användarfel, konfigurationsfel eller andra fel inträffar. Klientkoden (avsändare och mottagare) bör 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 batch med meddelanden. Mer information finns i Service Bus undantag för meddelanden.
Återförsöksprincip. 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ö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ö för dead-letter. Om ett meddelande inte kan bearbetas eller levereras till någon mottagare efter flera återförsök flyttas det till en kö för dead letter. Implementera en process för att läsa meddelanden från kön för döda meddelanden, inspektera dem och åtgärda problemet. Beroende på scenariot kan du försöka igen med meddelandet som det är, göra ändringar och försöka igen eller ta bort meddelandet. Mer information finns i Översikt över Service Bus köer med dead-letter.
Använd Geo-Disaster Recovery. 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 datacenter blir otillgängligt på grund av en katastrof. Mer information finns i Azure Service Bus geo-haveriberedskap.
Storage
För programdata använder du read-access geo-redundant storage (RA-GRS). RA-GRS-lagring replikerar data till en sekundär region och ger skrivskyddade åtkomst från den sekundära regionen. Om det finns ett lagringsavbrott i den primära regionen kan programmet läsa data från den sekundära regionen. Mer information finns i Azure Storage replikering.
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 i Azure.
För Queue Storage skapar du en säkerhetskopieringskö i en annan region. För Queue Storage har en skrivskyddade replik begränsad användning eftersom du inte kan köa eller ta bort objekt från kön. Skapa i stället en säkerhetskopieringskö i ett lagringskonto i en annan region. Om det finns ett lagringsavbrott kan programmet använda säkerhetskopieringskön tills den primära regionen blir tillgänglig igen. På så sätt kan programmet fortfarande bearbeta nya begäranden.
SQL Database
Använd Standard eller Premium-nivå. Dessa nivåer ger en längre återställningsperiod till en viss tidpunkt (35 dagar). Mer information finns i SQL Database och prestanda.
Aktivera SQL Database granskning. Granskning kan användas för att diagnostisera skadliga attacker eller mänskliga fel. Mer information finns i Kom igång med att SQL databasgranskning.
Använda aktiv geo-replikering Använd Active Geo-Replication för att skapa en läsbar sekundär i en annan region. Om den primära databasen slutar fungera, eller bara behöver tas offline, utför du en manuell redundans till den sekundära databasen. Tills du redundansar förblir den sekundära databasen skrivskyddade. 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 horisontellt. 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 Recover an Azure SQL database using automated database backups (Återställa en Azure SQL databas med automatiserade databassäkerhetskopior).
Använd geo-återställning för att återställa efter ett avbrott i tjänsten. Geo-återställning återställer en databas från en geo-redundant säkerhetskopia. Mer information finns i Recover an Azure SQL database using automated database backups (Återställa en Azure SQL databas med automatiserade databassäkerhetskopior).
Azure Synapse Analytics
Inaktivera inte geo-säkerhetskopiering. Som standard Synapse Analytics en fullständig säkerhetskopia av dina data var 24:e timme för haveriberedskap. Vi rekommenderar inte att du inaktiverar den här funktionen. Mer information finns i Geo-säkerhetskopieringar.
SQL Server körs på en virtuell dator
Replikera databasen. Använd SQL Server Always On-tillgänglighetsgrupper för att replikera databasen. Ger hög tillgänglighet om en SQL Server instansen misslyckas. Mer information finns i Run Windows VMs for an N-tier application (Köra virtuella Windows för ett program på N-nivå)
Back up the database. Om du redan använder Azure Backup för att arbetsbelastningarna ska arbetsbelastningarna med hjälp av DPM Azure Backup SQL Serverdu använder . 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 för att Microsoft Azure.
Traffic Manager
Utför manuell återställning efter fel. Efter en Traffic Manager utför du manuell återställning efter fel i stället för att automatiskt växla tillbaka. Innan du går tillbaka kontrollerar du att alla programundersystem är felfria. 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ökningen. Skapa en anpassad slutpunkt som rapporterar om programmets övergripande hälsa. Detta gör att Traffic Manager redundans om någon kritisk väg misslyckas, inte bara frontend. Slutpunkten bör returnera en HTTP-felkod om något kritiskt beroende är felaktigt eller inte kan nås. Rapportera dock inga 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 resultat. Mer information finns i Traffic Manager slutpunktsövervakning och redundans.
Virtual Machines
Undvik att köra en produktionsarbetsbelastning på en enskild virtuell dator. En enskild VM-distribution ä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ättningmed en lastbalanserare framför.
Ange en tillgänglighetsuppsättning när du etablerar den virtuella datorn. För närvarande går det inte 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 backend-adresspoolen i lastbalanseraren. Annars dirigerar inte lastbalanseraren 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 i feldomäner (FD) och uppdateringsdomäner (UD). Men för att få redundansförmånen med FD:er och naD:er måste alla virtuella datorer i tillgänglighetsuppsättningen kunna hantera samma klientbegäranden.
Replikera virtuella datorer med Azure Site Recovery. När du replikerar virtuella Azure-Site Recoverymed hjälp av , replikeras alla virtuella datordiskar kontinuerligt till målregionen asynkront. Återställningspunkterna skapas med några minuters varannan minut. Detta ger dig ett mål för återställningspunkt (RPO) i minuter. Du kan utföra programåterställningsövningar 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 haveriberedskaps drill 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 prestanda för din faktiska arbetsbelastning med avseende på CPU, minne och disk-IOPS och justera storleken om det behövs. Detta säkerställer att programmet fungerar som förväntat i en molnmiljö. Tänk också på nätverkskortsgränsen för varje storlek om du behöver flera nätverkskort.
Använda 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 i Azure.
Installera program på en datadisk, inte OS-disken. Annars kan du nå storleksgränsen för disken.
Använd Azure Backup för att backa upp 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 icke startbart tillstånd. 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 det. Mer information finns i Azure Monitoroch 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 hälsoavsö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 Azure Load Balancer översikt.
Blockera inte hälsoavsökningen. Den Load Balancer hälsoavsö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 brandväggsprinciper eller regler för nätverkssäkerhetsgrupp. Om hälsoavsökningen blockeras kan lastbalanseraren ta bort den virtuella datorn från rotationen.
Aktivera Load Balancer loggning. Loggarna visar hur många virtuella datorer på backend-backen som inte tar emot nätverkstrafik på grund av misslyckade avsökningssvar. Mer information finns i Log Analytics för Azure Load Balancer.