Zotavení po havárii a převzetí služeb při selhání účtu úložiště (Preview) v Azure StorageDisaster recovery and storage account failover (preview) in Azure Storage

Microsoft usiluje o to, aby byly služby Azure vždycky dostupné.Microsoft strives to ensure that Azure services are always available. Může ale dojít k neplánovaným výpadkům služby.However, unplanned service outages may occur. Pokud vaše aplikace vyžaduje odolnost, společnost Microsoft doporučuje používat geograficky redundantní úložiště, aby se vaše data mohla replikovat do druhé oblasti.If your application requires resiliency, Microsoft recommends using geo-redundant storage, so that your data is replicated in a second region. Kromě toho by zákazníci měli mít k dispozici plán zotavení po havárii pro zpracování oblasti výpadku regionální služby.Additionally, customers should have a disaster recovery plan in place for handling a regional service outage. Důležitou součástí plánu zotavení po havárii je příprava na převzetí služeb při selhání sekundárním koncovým bodem v případě, že primární koncový bod nebude k dispozici.An important part of a disaster recovery plan is preparing to fail over to the secondary endpoint in the event that the primary endpoint becomes unavailable.

Azure Storage podporuje převzetí služeb při selhání účtu (Preview) u geograficky redundantních účtů úložiště.Azure Storage supports account failover (preview) for geo-redundant storage accounts. S převzetím služeb při selhání můžete zahájit proces převzetí služeb při selhání pro váš účet úložiště, pokud primární koncový bod nebude k dispozici.With account failover, you can initiate the failover process for your storage account if the primary endpoint becomes unavailable. Převzetí služeb při selhání aktualizuje sekundární koncový bod tak, aby se stal primárním koncovým bodem pro váš účet úložiště.The failover updates the secondary endpoint to become the primary endpoint for your storage account. Až se převzetí služeb při selhání dokončí, můžou klienti začít zapisovat do nového primárního koncového bodu.Once the failover is complete, clients can begin writing to the new primary endpoint.

Tento článek popisuje koncepty a procesy spojené s převzetím služeb při selhání a popisuje, jak připravit účet úložiště k obnovení s minimálním dopadem na zákazníky.This article describes the concepts and process involved with an account failover and discusses how to prepare your storage account for recovery with the least amount of customer impact. Informace o tom, jak iniciovat převzetí služeb při selhání účtu v Azure Portal nebo PowerShellu, najdete v tématu o inicializaci převzetí služeb při selhání (Preview).To learn how to initiate an account failover in the Azure portal or PowerShell, see Initiate an account failover (preview).

Poznámka

Tento článek byl aktualizován, aby používal nový Azure PowerShell AZ Module.This article has been updated to use the new Azure PowerShell Az module. Stále můžete používat modul AzureRM, který bude dál přijímat opravy chyb, dokud nebude aspoň 2020. prosince.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Další informace o novém rozhraní AZ Module a AzureRM Compatibility najdete v tématu představení nového Azure PowerShell AZ Module.To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Pokyny k instalaci přidaných modulů najdete v tématu Install Azure PowerShell.For Az module installation instructions, see Install Azure PowerShell.

Zvolit správnou možnost redundanceChoose the right redundancy option

Všechny účty úložiště se replikují pro redundanci.All storage accounts are replicated for redundancy. Jakou možnost redundance zvolíte pro svůj účet závisí na stupni odolnosti, kterou potřebujete.Which redundancy option you choose for your account depends on the degree of resiliency you need. Z důvodu ochrany před místními výpadky vyberte geograficky redundantní úložiště s možností přístupu pro čtení ze sekundární oblasti nebo bez něj:For protection against regional outages, choose geo-redundant storage, with or without the option of read access from the secondary region:

Geograficky redundantní úložiště (GRS) replikuje vaše data asynchronně ve dvou geografických oblastech, které mají od sebe aspoň stovky kilometrů.Geo-redundant storage (GRS) replicates your data asynchronously in two geographic regions that are at least hundreds of miles apart. Pokud primární oblast zpomaluje výpadek, pak sekundární oblast slouží jako redundantní zdroj dat.If the primary region suffers an outage, then the secondary region serves as a redundant source for your data. Můžete iniciovat převzetí služeb při selhání a transformovat sekundární koncový bod do primárního koncového bodu.You can initiate a failover to transform the secondary endpoint into the primary endpoint.

Geograficky redundantní úložiště s přístupem pro čtení (RA-GRS) poskytuje geograficky redundantní úložiště s dodatečnou výhodou přístupu pro čtení sekundárního koncového bodu.Read-access geo-redundant storage (RA-GRS) provides geo-redundant storage with the additional benefit of read access to the secondary endpoint. Pokud v primárním koncovém bodě dojde k výpadku, můžou aplikace nakonfigurované pro RA-GRS a určené pro vysokou dostupnost pokračovat v čtení ze sekundárního koncového bodu.If an outage occurs in the primary endpoint, applications configured for RA-GRS and designed for high availability can continue to read from the secondary endpoint. Microsoft doporučuje RA-GRS pro maximální odolnost vašich aplikací.Microsoft recommends RA-GRS for maximum resiliency for your applications.

Mezi další Azure Storage možnosti redundance patří úložiště redundantní v zóně (ZRS), které replikuje vaše data napříč zónami dostupnosti v jedné oblasti a místně redundantní úložiště (LRS), které replikuje vaše data v jednom datovém centru v jedné oblasti.Other Azure Storage redundancy options include zone-redundant storage (ZRS), which replicates your data across availability zones in a single region, and locally redundant storage (LRS), which replicates your data in a single data center in a single region. Pokud je váš účet úložiště nakonfigurovaný pro ZRS nebo LRS, můžete tento účet převést na použití GRS nebo RA-GRS.If your storage account is configured for ZRS or LRS, you can convert that account to use GRS or RA-GRS. Konfigurace účtu pro geograficky redundantní úložiště má za následek další náklady.Configuring your account for geo-redundant storage incurs additional costs. Další informace najdete v tématu replikace Azure Storage.For more information, see Azure Storage replication.

Poznámka

Geograficky redundantní úložiště (GZRS) a geograficky redundantní úložiště s přístupem pro čtení (RA-GZRS) jsou momentálně ve verzi Preview, ale ještě nejsou dostupné ve stejných oblastech jako převzetí služeb při selhání účtů spravovaných zákazníkem.Geo-zone-redundant storage (GZRS) and read-access geo-zone-redundant storage (RA-GZRS) are currently in preview, but are not yet available in the same regions as customer-managed account failover. Z tohoto důvodu zákazníci momentálně nemůžou spravovat události převzetí služeb při selhání účtu s GZRS a RA-GZRS účty.For this reason, customers cannot currently manage account failover events with GZRS and RA-GZRS accounts. V průběhu verze Preview bude společnost Microsoft spravovat všechny události převzetí služeb při selhání, které mají vliv na účty GZRS/RA-GZRS.During the preview, Microsoft will manage any failover events affecting GZRS/RA-GZRS accounts.

Varování

Geograficky redundantní úložiště přináší riziko ztráty dat.Geo-redundant storage carries a risk of data loss. Data se replikují do sekundární oblasti asynchronně, což znamená, že mezi daty zapsanými do primární oblasti dojde k zápisu do sekundární oblasti.Data is replicated to the secondary region asynchronously, meaning there is a delay between when data written to the primary region is written to the secondary region. V případě výpadku dojde ke ztrátě operací zápisu do primárního koncového bodu, které ještě nebyly replikovány do sekundárního koncového bodu.In the event of an outage, write operations to the primary endpoint that have not yet been replicated to the secondary endpoint will be lost.

Návrh pro vysokou dostupnostDesign for high availability

Je důležité navrhnout aplikaci pro zajištění vysoké dostupnosti od začátku.It's important to design your application for high availability from the start. Pokyny pro návrh aplikace a plánování zotavení po havárii najdete v těchto prostředcích Azure:Refer to these Azure resources for guidance in designing your application and planning for disaster recovery:

Kromě toho mějte na paměti tyto osvědčené postupy pro udržení vysoké dostupnosti dat Azure Storage:Additionally, keep in mind these best practices for maintaining high availability for your Azure Storage data:

  • Disků Použijte Azure Backup k zálohování disků virtuálních počítačů využívaných virtuálními počítači Azure.Disks: Use Azure Backup to back up the VM disks used by your Azure virtual machines. Zvažte také použití Azure Site Recovery k ochraně vašich virtuálních počítačů v případě regionálních havárií.Also consider using Azure Site Recovery to protect your VMs in the event of a regional disaster.
  • Objekty blob bloku: Zapněte obnovitelné odstranění pro ochranu proti odstranění na úrovni objektu a přepsání nebo zkopírujte objekty blob bloku do jiného účtu úložiště v jiné oblasti pomocí AzCopy, Azure PowerShellnebo knihovny pro přesun dat Azure.Block blobs: Turn on soft delete to protect against object-level deletions and overwrites, or copy block blobs to another storage account in a different region using AzCopy, Azure PowerShell, or the Azure Data Movement library.
  • Spis Pomocí AzCopy nebo Azure PowerShell zkopírujte soubory do jiného účtu úložiště v jiné oblasti.Files: Use AzCopy or Azure PowerShell to copy your files to another storage account in a different region.
  • Tabulky: pomocí AzCopy můžete exportovat data tabulky do jiného účtu úložiště v jiné oblasti.Tables: use AzCopy to export table data to another storage account in a different region.

Sledovat výpadkyTrack outages

Zákazníci se můžou přihlásit k odběru řídicího panelu Azure Service Health , aby mohli sledovat stav a stav Azure Storage a dalších služeb Azure.Customers may subscribe to the Azure Service Health Dashboard to track the health and status of Azure Storage and other Azure services.

Microsoft také doporučuje navrhovat aplikace, aby se připravila možnost selhání zápisu.Microsoft also recommends that you design your application to prepare for the possibility of write failures. Vaše aplikace by měla vystavovat chyby při psaní způsobem, který vás upozorní na možnost výpadku v primární oblasti.Your application should expose write failures in a way that alerts you to the possibility of an outage in the primary region.

Pochopení procesu převzetí služeb při selhání účtuUnderstand the account failover process

Převzetí služeb při selhání účtu spravovaného zákazníkem (ve verzi Preview) vám umožní převzít služby při selhání celého účtu úložiště do sekundární oblasti, pokud primární z nějakého důvodu nebude k dispozici.Customer-managed account failover (preview) enables you to fail your entire storage account over to the secondary region if the primary becomes unavailable for any reason. Když vynutíte převzetí služeb při selhání sekundární oblastí, můžou klienti po dokončení převzetí služeb při selhání začít zapisovat data do sekundárního koncového bodu.When you force a failover to the secondary region, clients can begin writing data to the secondary endpoint after the failover is complete. Převzetí služeb při selhání obvykle trvá přibližně hodinu.The failover typically takes about an hour.

Jak funguje převzetí služeb při selhání účtuHow an account failover works

Za normálních okolností klient zapisuje data do účtu Azure Storage v primární oblasti a tato data se replikují asynchronně do sekundární oblasti.Under normal circumstances, a client writes data to an Azure Storage account in the primary region, and that data is replicated asynchronously to the secondary region. Následující obrázek znázorňuje situaci, kdy je primární oblast k dispozici:The following image shows the scenario when the primary region is available:

Klienti zapisují data do účtu úložiště v primární oblasti.

Pokud z nějakého důvodu nebude primární koncový bod k dispozici, klient už nebude moct zapisovat do účtu úložiště.If the primary endpoint becomes unavailable for any reason, the client is no longer able to write to the storage account. Na následujícím obrázku je znázorněn scénář, ve kterém primární událost není k dispozici, ale ještě neproběhlo žádné obnovení:The following image shows the scenario where the primary has become unavailable, but no recovery has happened yet:

Primární není k dispozici, takže klienti nemůžou zapisovat data.

Zákazník zahájí převzetí služeb při selhání účtu sekundárním koncovým bodem.The customer initiates the account failover to the secondary endpoint. Proces převzetí služeb při selhání aktualizuje položku DNS, kterou poskytuje Azure Storage, aby se sekundární koncový bod stal novým primárním koncovým bodem pro váš účet úložiště, jak je znázorněno na následujícím obrázku:The failover process updates the DNS entry provided by Azure Storage so that the secondary endpoint becomes the new primary endpoint for your storage account, as shown in the following image:

Zákazník iniciuje převzetí služeb při selhání účtem sekundárního koncového bodu.

Jakmile se položka DNS aktualizuje a požadavky se přesměrují do nového primárního koncového bodu, pro účty GRS a RA-GRS se obnoví přístup pro zápis.Write access is restored for GRS and RA-GRS accounts once the DNS entry has been updated and requests are being directed to the new primary endpoint. Stávající koncové body služby úložiště pro objekty blob, tabulky, fronty a soubory zůstávají po převzetí služeb při selhání stejné.Existing storage service endpoints for blobs, tables, queues, and files remain the same after the failover.

Důležité

Po dokončení převzetí služeb při selhání se účet úložiště nakonfiguruje na místně redundantní v novém primárním koncovém bodu.After the failover is complete, the storage account is configured to be locally redundant in the new primary endpoint. Pokud chcete obnovit replikaci do nového sekundárního počítače, nakonfigurujte účet tak, aby znovu používal geograficky redundantní úložiště (buď RA-GRS nebo GRS).To resume replication to the new secondary, configure the account to use geo-redundant storage again (either RA-GRS or GRS).

Mějte na paměti, že převod účtu LRS na RA-GRS nebo GRS stojí za cenu.Keep in mind that converting an LRS account to RA-GRS or GRS incurs a cost. Tato cena se vztahuje na aktualizaci účtu úložiště v nové primární oblasti tak, aby po převzetí služeb při selhání používala RA-GRS nebo GRS.This cost applies to updating the storage account in the new primary region to use RA-GRS or GRS after a failover.

Předvídání ztráty datAnticipate data loss

Upozornění

Převzetí služeb při selhání účtu obvykle zahrnuje určitou ztrátu dat.An account failover usually involves some data loss. Je důležité pochopit důsledky zahájení převzetí služeb při selhání účtu.It's important to understand the implications of initiating an account failover.

Vzhledem k tomu, že data jsou zapsána asynchronně z primární oblasti do sekundární oblasti, je vždy zpoždění před tím, než je zápis do primární oblasti replikován do sekundární oblasti.Because data is written asynchronously from the primary region to the secondary region, there is always a delay before a write to the primary region is replicated to the secondary region. Pokud primární oblast nebude k dispozici, nejaktuálnější zápisy ještě nemusí být replikovány do sekundární oblasti.If the primary region becomes unavailable, the most recent writes may not yet have been replicated to the secondary region.

Když vynutíte převzetí služeb při selhání, všechna data v primární oblasti se ztratí, protože se sekundární oblast stala novou primární oblastí a účet úložiště se nakonfiguruje jako místně redundantní.When you force a failover, all data in the primary region is lost as the secondary region becomes the new primary region and the storage account is configured to be locally redundant. Všechna data, která se už replikují do sekundárního, se při převzetí služeb při selhání uchovávají.All data already replicated to the secondary is maintained when the failover happens. Veškerá data zapsaná na primární, která nebyla také replikována do sekundárního, se však trvale ztratí.However, any data written to the primary that has not also been replicated to the secondary is lost permanently.

Vlastnost čas poslední synchronizace označuje poslední čas, po který je zaručeno, že data z primární oblasti budou zapsána do sekundární oblasti.The Last Sync Time property indicates the most recent time that data from the primary region is guaranteed to have been written to the secondary region. Všechna data zapsaná před časem poslední synchronizace jsou k dispozici na sekundárním počítači, zatímco data zapsaná po poslední synchronizaci nemusí být zapsána do sekundárního a mohou být ztracena.All data written prior to the last sync time is available on the secondary, while data written after the last sync time may not have been written to the secondary and may be lost. Tuto vlastnost použijte v případě výpadku k odhadu množství ztráty dat, která se může vyvolávat při převzetí služeb při selhání účtu.Use this property in the event of an outage to estimate the amount of data loss you may incur by initiating an account failover.

Osvědčeným postupem je navrhnout aplikaci tak, aby bylo možné použít čas poslední synchronizace k vyhodnocení očekávané ztráty dat.As a best practice, design your application so that you can use the last sync time to evaluate expected data loss. Pokud například protokoluje všechny operace zápisu, můžete porovnat čas poslední operace zápisu s časem poslední synchronizace a určit, které zápisy nebyly synchronizovány do sekundárního.For example, if you are logging all write operations, then you can compare the time of your last write operations to the last sync time to determine which writes have not been synced to the secondary.

Při navrácení služeb po obnovení původní primární služby postupujte opatrně.Use caution when failing back to the original primary

Po převzetí služeb při selhání z primárního umístění do sekundární oblasti je váš účet úložiště nakonfigurovaný místně redundantní v nové primární oblasti.After you fail over from the primary to the secondary region, your storage account is configured to be locally redundant in the new primary region. Účet pro geografickou redundanci můžete znovu nakonfigurovat tak, že ho aktualizujete tak, aby používal GRS nebo RA-GRS.You can configure the account for geo-redundancy again by updating it to use GRS or RA-GRS. Když je účet nakonfigurovaný pro geografickou redundanci znovu po převzetí služeb při selhání, nová primární oblast okamžitě zahájí replikaci dat do nové sekundární oblasti, která byla primární před původní převzetí služeb při selhání.When the account is configured for geo-redundancy again after a failover, the new primary region immediately begins replicating data to the new secondary region, which was the primary before the original failover. Může ale nějakou dobu trvat, než se stávající data v primárním čase replikují do nového sekundárního.However, it may take a period of time before existing data in the primary is fully replicated to the new secondary.

Po překonfigurování účtu úložiště pro geografickou redundanci je možné zahájit jiné převzetí služeb při selhání z nové primární služby zpátky do nového sekundárního objektu.After the storage account is reconfigured for geo-redundancy, it's possible to initiate another failover from the new primary back to the new secondary. V takovém případě se původní primární oblast před převzetím služeb při selhání znovu vytvoří v primární oblasti a nakonfiguruje se tak, aby byla místně redundantní.In this case, the original primary region prior to the failover becomes the primary region again, and is configured to be locally redundant. Všechna data v primární oblasti po převzetí služeb při selhání (původní sekundární) se pak ztratí.All data in the post-failover primary region (the original secondary) is then lost. Pokud před navrácením služeb po obnovení není většina dat v účtu úložiště replikována do nového sekundárního, může dojít k výrazné ztrátě dat.If most of the data in the storage account has not been replicated to the new secondary before you fail back, you could suffer a major data loss.

Chcete-li se vyhnout zásadní ztrátě dat, před navrácením služeb po obnovení ověřte hodnotu vlastnosti čas poslední synchronizace .To avoid a major data loss, check the value of the Last Sync Time property before failing back. Porovnejte čas poslední synchronizace s časem, kdy byla data zapsána do nové primární pro vyhodnocení očekávané ztráty dat.Compare the last sync time to the last times that data was written to the new primary to evaluate expected data loss.

Zahájení převzetí služeb při selhání účtuInitiate an account failover

Převzetí služeb při selhání účtu můžete iniciovat z rozhraní API Azure Portal, PowerShellu, Azure CLI nebo poskytovatele prostředků Azure Storage.You can initiate an account failover from the Azure portal, PowerShell, Azure CLI, or the Azure Storage resource provider API. Další informace o tom, jak iniciovat převzetí služeb při selhání, najdete v tématu o inicializaci převzetí služeb při selhání (Preview).For more information on how to initiate a failover, see Initiate an account failover (preview).

O verzi PreviewAbout the preview

Převzetí služeb při selhání účtu je dostupné ve verzi Preview pro všechny zákazníky, kteří používají GRS nebo RA-GRS s nasazeními Azure Resource Manager.Account failover is available in preview for all customers using GRS or RA-GRS with Azure Resource Manager deployments. Podporují se typy účtů pro obecné účely V1, obecné účely v2 a BLOB Storage.General-purpose v1, General-purpose v2, and Blob storage account types are supported. převzetí služeb při selhání účtu je aktuálně dostupné v těchto oblastech:account failover is currently available in these regions:

  • USA – západ 2US West 2
  • USA – středozápadUS West Central

Verze Preview je určena pouze pro neprodukční použití.The preview is intended for non-production use only. Smlouvy o úrovni produkčních služeb (SLA) nejsou aktuálně k dispozici.Production service-level agreements (SLAs) are not currently available.

Zaregistrovat se pro verzi PreviewRegister for the preview

Pokud se chcete zaregistrovat ve verzi Preview, spusťte v PowerShellu následující příkazy.To register for the preview, run the following commands in PowerShell. Zástupný symbol v závorkách nahraďte vlastním ID předplatného:Make sure to replace the placeholder in brackets with your own subscription ID:

Connect-AzAccount -SubscriptionId <subscription-id>
Register-AzProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.Storage

Získání schválení pro verzi Preview může trvat 1-2 dní.It may take 1-2 days to receive approval for the preview. Chcete-li ověřit, zda byla registrace schválena, spusťte následující příkaz:To verify that your registration has been approved, run the following command:

Get-AzProviderFeature -FeatureName CustomerControlledFailover -ProviderNamespace Microsoft.Storage

Další aspektyAdditional considerations

Další informace popsané v této části vám pomohou pochopit, jak můžou být vaše aplikace a služby ovlivněné při vynucení převzetí služeb při selhání během období Preview.Review the additional considerations described in this section to understand how your applications and services may be affected when you force a failover during the preview period.

Virtuální počítače AzureAzure virtual machines

Virtuální počítače Azure při převzetí služeb při selhání v rámci účtu převezmou služby při selhání.Azure virtual machines (VMs) do not fail over as part of an account failover. Pokud primární region přestane být k dispozici a převezmete služby při selhání do sekundární oblasti, budete muset po převzetí služeb při selhání znovu vytvořit všechny virtuální počítače.If the primary region becomes unavailable, and you fail over to the secondary region, then you will need to recreate any VMs after the failover.

Nespravované disky AzureAzure unmanaged disks

Osvědčeným postupem je, že společnost Microsoft doporučuje převést nespravované disky na spravované disky.As a best practice, Microsoft recommends converting unmanaged disks to managed disks. Pokud ale potřebujete převzít služby při selhání účtu, který obsahuje nespravované disky připojené k virtuálním počítačům Azure, budete muset před zahájením převzetí služeb při selhání vypnout virtuální počítač.However, if you need to fail over an account that contains unmanaged disks attached to Azure VMs, you will need to shut down the VM before initiating the failover.

Nespravované disky se ukládají jako objekty blob stránky v Azure Storage.Unmanaged disks are stored as page blobs in Azure Storage. Když je virtuální počítač spuštěný v Azure, všechny nespravované disky připojené k virtuálnímu počítači se zapůjčují.When a VM is running in Azure, any unmanaged disks attached to the VM are leased. Převzetí služeb při selhání účtu nemůže pokračovat, pokud je u objektu BLOB zapůjčení.An account failover cannot proceed when there is a lease on a blob. K provedení převzetí služeb při selhání použijte následující postup:To perform the failover, follow these steps:

  1. Než začnete, poznamenejte si názvy všech nespravovaných disků, jejich logické jednotky (LUN) a virtuální počítač, ke kterému jsou připojené.Before you begin, note the names of any unmanaged disks, their logical unit numbers (LUN), and the VM to which they are attached. Díky tomu bude snazší znovu připojit disky po převzetí služeb při selhání.Doing so will make it easier to reattach the disks after the failover.
  2. Vypněte virtuální počítač.Shut down the VM.
  3. Odstraňte virtuální počítač, ale zachovejte soubory VHD pro nespravované disky.Delete the VM, but retain the VHD files for the unmanaged disks. Poznamenejte si čas, kdy jste virtuální počítač odstranili.Note the time at which you deleted the VM.
  4. Počkejte, až se aktualizuje čas poslední synchronizace , a pozdější dobu než čas, kdy jste virtuální počítač odstranili.Wait until the Last Sync Time has updated, and is later than the time at which you deleted the VM. Tento krok je důležitý, protože pokud se sekundární koncový bod v případě převzetí služeb při selhání plně neaktualizoval pomocí souborů VHD, nemusí virtuální počítač fungovat správně v nové primární oblasti.This step is important, because if the secondary endpoint has not been fully updated with the VHD files when the failover occurs, then the VM may not function properly in the new primary region.
  5. Zahajte převzetí služeb při selhání účtu.Initiate the account failover.
  6. Počkejte, než se dokončí převzetí služeb při selhání účtu a sekundární oblast se stane novou primární oblastí.Wait until the account failover is complete and the secondary region has become the new primary region.
  7. Vytvořte virtuální počítač v nové primární oblasti a znovu připojte virtuální pevné disky.Create a VM in the new primary region and reattach the VHDs.
  8. Spusťte nový virtuální počítač.Start the new VM.

Mějte na paměti, že při vypnutí virtuálního počítače dojde ke ztrátě všech dat uložených na dočasném disku.Keep in mind that any data stored in a temporary disk is lost when the VM is shut down.

Nepodporované funkce nebo službyUnsupported features or services

Pro převzetí služeb při selhání účtu verze Preview nejsou podporované tyto funkce nebo služby:The following features or services are not supported for account failover for the preview release:

  • Azure File Sync nepodporuje převzetí služeb při selhání účtu úložiště.Azure File Sync does not support storage account failover. Účty úložiště obsahující sdílené složky Azure, které se používají jako koncové body cloudu v Azure File Sync by neměly přenášet služby při selhání.Storage accounts containing Azure file shares being used as cloud endpoints in Azure File Sync should not be failed over. Tím dojde k tomu, že synchronizace přestane fungovat a může také způsobit neočekávanou ztrátu dat v případě nově vrstvených souborů.Doing so will cause sync to stop working and may also cause unexpected data loss in the case of newly tiered files.
  • Účty úložiště používající Azure Data Lake Storage Gen2 hierarchickém oborem názvů nejde převzít služby při selhání.Storage accounts using Azure Data Lake Storage Gen2 hierarchical namespace cannot be failed over.
  • Účet úložiště obsahující archivované objekty blob nejde převzít služby při selhání.A storage account containing archived blobs cannot be failed over. Udržujte archivované objekty BLOB v samostatném účtu úložiště, u kterých neplánujete převzít služby při selhání.Maintain archived blobs in a separate storage account that you do not plan to fail over.
  • Nepovedlo se převzít služby účtů úložiště obsahující objekty blob bloku Premium.A storage account containing premium block blobs cannot be failed over. Účty úložiště, které podporují objekty blob bloku Premium, v současné době nepodporují geografickou redundanci.Storage accounts that support premium block blobs do not currently support geo-redundancy.
  • Po dokončení převzetí služeb při selhání přestane následující funkce fungovat, pokud jsou původně povolené: Odběry událostí, Zásady životního cyklua protokolování analýza úložiště.After the failover is complete the following features will stop working if originally enabled: Event subscriptions, Lifecycle policies, Storage Analytics Logging.

Kopírování dat jako alternativu k převzetí služeb při selháníCopying data as an alternative to failover

Pokud je váš účet úložiště nakonfigurovaný pro RA-GRS, máte k datům přístup pro čtení pomocí sekundárního koncového bodu.If your storage account is configured for RA-GRS, then you have read access to your data using the secondary endpoint. Pokud v případě výpadku v primární oblasti nechcete převzít služby při selhání, můžete pomocí nástrojů, jako jsou AzCopy, Azure PowerShellnebo knihovny pro přesun dat Azure , kopírovat data z účtu úložiště v sekundární oblasti do jiné. účet úložiště v neovlivněné oblasti.If you prefer not to fail over in the event of an outage in the primary region, you can use tools such as AzCopy, Azure PowerShell, or the Azure Data Movement library to copy data from your storage account in the secondary region to another storage account in an unaffected region. Pak můžete své aplikace nasměrovat na tento účet úložiště pro čtení i zápis.You can then point your applications to that storage account for both read and write availability.

Převzetí služeb při selhání spravované MicrosoftemMicrosoft-managed failover

V extrémních situacích, kdy dojde ke ztrátě oblasti z důvodu významné havárie, může společnost Microsoft zahájit místní převzetí služeb při selhání.In extreme circumstances where a region is lost due to a significant disaster, Microsoft may initiate a regional failover. V takovém případě není nutná žádná akce s vaší částí.In this case, no action on your part is required. Dokud neproběhne převzetí služeb při selhání spravované Microsoftem, nebudete mít k účtu úložiště přístup pro zápis.Until the Microsoft-managed failover has completed, you won't have write access to your storage account. Vaše aplikace se můžou číst ze sekundární oblasti, pokud je váš účet úložiště nakonfigurovaný pro RA-GRS.Your applications can read from the secondary region if your storage account is configured for RA-GRS.

Viz také:See also