Redundans och korrigering för Azure cache för RedisFailover and patching for Azure Cache for Redis

För att kunna bygga elastiska och lyckade klient program är det viktigt att förstå redundansväxlingen i kontexten för Azure cache för Redis-tjänsten.To build resilient and successful client applications, it's critical to understand failover in the context of the Azure Cache for Redis service. En redundansväxling kan vara en del av planerade hanterings åtgärder eller kan orsakas av oplanerade maskin-eller nätverks fel.A failover can be a part of planned management operations, or might be caused by unplanned hardware or network failures. En vanlig användning av cachelagring av cachen kommer när hanterings tjänsten återanvänder Azure-cachen för Redis-binärfiler.A common use of cache failover comes when the management service patches the Azure Cache for Redis binaries. Den här artikeln beskriver vad en redundansväxling är, hur det sker under korrigeringen och hur du skapar ett elastiskt klient program.This article covers what a failover is, how it occurs during patching, and how to build a resilient client application.

Vad är en redundansväxling?What is a failover?

Vi börjar med en översikt över redundans för Azure cache för Redis.Let's start with an overview of failover for Azure Cache for Redis.

En snabb översikt över cache-arkitekturenA quick summary of cache architecture

En cache är konstruerad av flera virtuella datorer med separata, privata IP-adresser.A cache is constructed of multiple virtual machines with separate, private IP addresses. Varje virtuell dator, som även kallas nod, är ansluten till en delad belastningsutjämnare med en enda virtuell IP-adress.Each virtual machine, also known as a node, is connected to a shared load balancer with a single virtual IP address. Varje nod kör Redis-serverns process och är tillgänglig med hjälp av värd namnet och Redis-portarna.Each node runs the Redis server process and is accessible by means of the host name and the Redis ports. Varje nod anses vara antingen en primär eller en replikerad nod.Each node is considered either a primary or a replica node. När ett klient program ansluter till ett cacheminne går dess trafik genom belastningsutjämnaren och dirigeras automatiskt till den primära noden.When a client application connects to a cache, its traffic goes through this load balancer and is automatically routed to the primary node.

I en grundläggande cache är den enskilda noden alltid en primär.In a Basic cache, the single node is always a primary. I en standard-eller Premium-cache finns det två noder: en väljs som primär och den andra är repliken.In a Standard or Premium cache, there are two nodes: one is chosen as the primary and the other is the replica. Eftersom standard-och Premium-cachen har flera noder, kan en nod vara otillgänglig medan den andra fortsätter att bearbeta begär Anden.Because Standard and Premium caches have multiple nodes, one node might be unavailable while the other continues to process requests. Klustrade cacheminnen består av många Shards, var och en med distinkta primära noder och noder.Clustered caches are made of many shards, each with distinct primary and replica nodes. En Shard kan vara nere medan de andra är tillgängliga.One shard might be down while the others remain available.

Anteckning

En grundläggande cache har inte flera noder och erbjuder inte något service nivå avtal (SLA) för dess tillgänglighet.A Basic cache doesn't have multiple nodes and doesn't offer a service-level agreement (SLA) for its availability. Basic-cacheminnen rekommenderas endast för utvecklings-och testnings ändamål.Basic caches are recommended only for development and testing purposes. Använd en standard-eller Premium-cache för en distribution med flera noder för att öka tillgängligheten.Use a Standard or Premium cache for a multi-node deployment, to increase availability.

Förklaring av redundansExplanation of a failover

En redundansväxling inträffar när en nod på en nod höjer sig själv för att bli en primär nod och den gamla primära noden stänger befintliga anslutningar.A failover occurs when a replica node promotes itself to become a primary node, and the old primary node closes existing connections. När den primära noden har säkerhetskopierats visas ändringarna i rollerna och degraderas som en replik.After the primary node comes back up, it notices the change in roles and demotes itself to become a replica. Den ansluter sedan till den nya primära och synkroniserar data.It then connects to the new primary and synchronizes data. En redundansväxling kan vara planerad eller oplanerad.A failover might be planned or unplanned.

En planerad redundansväxling sker under system uppdateringar, t. ex. Redis korrigering eller uppgraderingar av operativ system samt hanterings åtgärder, till exempel skalning och omstarter.A planned failover takes place during system updates, such as Redis patching or OS upgrades, and management operations, such as scaling and rebooting. Eftersom noderna tar emot ett meddelande om uppdateringen kan de enkelt byta ut roller och snabbt uppdatera belastnings Utjämnings ändringen.Because the nodes receive advance notice of the update, they can cooperatively swap roles and quickly update the load balancer of the change. En planerad redundansväxling slutförs normalt på mindre än 1 sekund.A planned failover typically finishes in less than 1 second.

En oplanerad redundansväxling kan inträffa på grund av maskin varu fel, nätverks fel eller andra oväntade avbrott till den primära noden.An unplanned failover might happen because of hardware failure, network failure, or other unexpected outages to the primary node. Noden replikering befordras till primär, men processen tar längre tid.The replica node promotes itself to primary, but the process takes longer. En nod för replikering måste först identifiera att den primära noden inte är tillgänglig innan den kan initiera redundansväxlingen.A replica node must first detect that its primary node is not available before it can initiate the failover process. Replik-noden måste också kontrol lera att detta oplanerat fel inte är tillfälligt eller lokalt, för att undvika onödig redundans.The replica node must also verify that this unplanned failure is not transient or local, to avoid an unnecessary failover. Den här fördröjningen innebär att en oplanerad redundansväxling vanligt vis slutförs inom 10 till 15 sekunder.This delay in detection means that an unplanned failover typically finishes within 10 to 15 seconds.

Hur sker uppdatering?How does patching occur?

Azure cache för Redis-tjänsten uppdaterar regelbundet din cache med de senaste plattforms funktionerna och korrigeringarna.The Azure Cache for Redis service regularly updates your cache with the latest platform features and fixes. För att korrigera en cache följer tjänsten dessa steg:To patch a cache, the service follows these steps:

  1. Hanterings tjänsten väljer en nod som ska korrigeras.The management service selects one node to be patched.
  2. Om den valda noden är en primär nod, marknadsförs motsvarande nod för replikering av sig själv.If the selected node is a primary node, the corresponding replica node cooperatively promotes itself. Den här kampanjen betraktas som planerad redundansväxling.This promotion is considered a planned failover.
  3. Den valda noden startas om för att ta de nya ändringarna och kommer att säkerhets kopie ras som en Replica-nod.The selected node reboots to take the new changes and comes back up as a replica node.
  4. Noden replikering ansluter till den primära noden och synkroniserar data.The replica node connects to the primary node and synchronizes data.
  5. När datasynkroniseringen är klar upprepas korrigerings processen för de återstående noderna.When the data sync is complete, the patching process repeats for the remaining nodes.

Eftersom korrigeringen är en planerad redundansväxling, höjer noden replikering snabbt sig själv för att bli en primär och påbörjar betjäna begär Anden och nya anslutningar.Because patching is a planned failover, the replica node quickly promotes itself to become a primary and begins servicing requests and new connections. Basic-cacheminnen har ingen nod för replikering och är inte tillgängliga förrän uppdateringen har slutförts.Basic caches don't have a replica node and are unavailable until the update is complete. Varje Shard i en klustrad cache korrigeras separat och stänger inte anslutningar till en annan Shard.Each shard of a clustered cache is patched separately and won't close connections to another shard.

Viktigt

Noderna korrigeras en i taget för att förhindra data förlust.Nodes are patched one at a time to prevent data loss. Grundläggande cacheminnen kommer att ha data förlust.Basic caches will have data loss. Klustrade cacheminnen korrigeras en Shard i taget.Clustered caches are patched one shard at a time.

Flera cacheminnen i samma resurs grupp och region har också uppdaterats en i taget.Multiple caches in the same resource group and region are also patched one at a time. Cacheminnen som finns i olika resurs grupper eller olika regioner kan komma att korrigeras samtidigt.Caches that are in different resource groups or different regions might be patched simultaneously.

Eftersom fullständig datasynkronisering sker innan processen upprepas, är det osannolikt att data förlust uppstår om du använder en standard-eller Premium-cache.Because full data synchronization happens before the process repeats, data loss is unlikely to occur when you use a Standard or Premium cache. Du kan ytterligare skydda dig mot data förlust genom att Exportera data och aktivera persistence.You can further guard against data loss by exporting data and enabling persistence.

Ytterligare cache-belastningAdditional cache load

När en redundansväxling inträffar måste standard-och Premium-cachen replikera data från en nod till en annan.Whenever a failover occurs, the Standard and Premium caches need to replicate data from one node to the other. Den här replikeringen orsakar en belastnings ökning i både server minne och CPU.This replication causes some load increase in both server memory and CPU. Om cache-instansen redan är hårt inläst kan klient programmen uppleva en ökad fördröjning.If the cache instance is already heavily loaded, client applications might experience increased latency. I extrema fall kan klient program ta emot timeout-undantag.In extreme cases, client applications might receive time-out exceptions. För att minska effekten av den här extra belastningen konfigurerar du inställningen för cacheminnet maxmemory-reserved .To help mitigate the impact of this additional load, configure the cache's maxmemory-reserved setting.

Hur påverkar en redundansväxling mitt klient program?How does a failover affect my client application?

Antalet fel som visas av klient programmet beror på hur många åtgärder som var beroende av anslutningen vid redundansväxlingen.The number of errors seen by the client application depends on how many operations were pending on that connection at the time of the failover. Alla anslutningar som dirigeras via noden som stängde dess anslutningar kommer att se fel.Any connection that's routed through the node that closed its connections will see errors. Många klient bibliotek kan utlösa olika typer av fel när anslutningar bryts, inklusive timeout-undantag, anslutnings undantag eller socket-undantag.Many client libraries can throw different types of errors when connections break, including time-out exceptions, connection exceptions, or socket exceptions. Antalet och typen av undantag beror på var i kod Sök vägen som begäran kommer när cachen stänger dess anslutningar.The number and type of exceptions depends on where in the code path the request is when the cache closes its connections. Till exempel kan en åtgärd som skickar en begäran men inte har fått ett svar när redundansväxlingen inträffar kan få ett timeout-undantag.For instance, an operation that sends a request but hasn't received a response when the failover occurs might get a time-out exception. Nya begär Anden för det stängda anslutningsobjektet tar emot anslutnings undantag tills åter anslutningen har genomförts.New requests on the closed connection object receive connection exceptions until the reconnection happens successfully.

De flesta klient bibliotek försöker återansluta till cachen om de är konfigurerade att göra det.Most client libraries attempt to reconnect to the cache if they're configured to do so. Oväntade buggar kan dock ibland placera biblioteks objekt i ett oåterkalleligt tillstånd.However, unforeseen bugs can occasionally place the library objects into an unrecoverable state. Om felet kvarstår under längre tid än en förkonfigurerad tids period ska anslutningsobjektet återskapas.If errors persist for longer than a preconfigured amount of time, the connection object should be recreated. I Microsoft.NET och andra objektorienterade språk kan du återskapa anslutningen utan att starta om programmet genom att använda ett Lazy- <T> mönster.In Microsoft.NET and other object-oriented languages, recreating the connection without restarting the application can be accomplished by using a Lazy<T> pattern.

Hur gör jag för att göra programmet elastiskt?How do I make my application resilient?

Eftersom du inte kan undvika redundans helt kan du skriva dina klient program för återhämtning till anslutnings avbrott och misslyckade förfrågningar.Because you can't avoid failovers completely, write your client applications for resiliency to connection breaks and failed requests. Även om de flesta klient bibliotek automatiskt återansluter till cache-slutpunkten så försöker några av dem att försöka utföra misslyckade förfrågningar igen.Although most client libraries automatically reconnect to the cache endpoint, few of them attempt to retry failed requests. Beroende på program scenariot kan det vara klokt att använda omprövnings logik med backoff.Depending on the application scenario, it might make sense to use retry logic with backoff.

Om du vill testa ett klient programs återhämtning använder du en omstart som en manuell utlösare för anslutnings avbrott.To test a client application's resiliency, use a reboot as a manual trigger for connection breaks. Dessutom rekommenderar vi att du schemalägger uppdateringar på en cache.Additionally, we recommend that you schedule updates on a cache. Be hanterings tjänsten att tillämpa Redis runtime-korrigeringsfiler under angivna vecko Visa fönster.Tell the management service to apply Redis runtime patches during specified weekly windows. Dessa fönster är vanligt vis perioder när klient program trafiken är låg, för att undvika potentiella incidenter.These windows are typically periods when client application traffic is low, to avoid potential incidents.

Klient nätverk – konfigurations ändringarClient network-configuration changes

Vissa nätverks konfigurations ändringar på klient sidan kan utlösa fel meddelande om att anslutningen inte är tillgänglig.Certain client-side network-configuration changes can trigger "No connection available" errors. Sådana ändringar kan vara:Such changes might include:

  • Växling av klient programmets virtuella IP-adress mellan mellanlagrings-och produktions platser.Swapping a client application's virtual IP address between staging and production slots.
  • Skalar storlek eller antal instanser av programmet.Scaling the size or number of instances of your application.

Sådana ändringar kan orsaka ett anslutnings problem som varar mindre än en minut.Such changes can cause a connectivity issue that lasts less than one minute. Klient programmet kommer förmodligen att förlora sin anslutning till andra externa nätverks resurser utöver Azure-cachen för Redis-tjänsten.Your client application will probably lose its connection to other external network resources in addition to the Azure Cache for Redis service.

Nästa stegNext steps