Zotavení po havárii a převzetí služeb při selhání v účtu (Preview)Disaster recovery and account failover (preview)

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 zkopírovala do druhé oblasti.If your application requires resiliency, Microsoft recommends using geo-redundant storage, so that your data is copied to 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 je aktualizovaný a využívá nový modul Az Azure PowerShellu.This article has been updated to use the new Azure PowerShell Az module. Můžete dál využívat modul AzureRM, který bude dostávat opravy chyb nejméně do prosince 2020.You can still use the AzureRM module, which will continue to receive bug fixes until at least December 2020. Další informace o kompatibilitě nového modulu Az a modulu AzureRM najdete v tématu Seznámení s novým modulem Az Azure PowerShellu.To learn more about the new Az module and AzureRM compatibility, see Introducing the new Azure PowerShell Az module. Pokyny k instalaci modulu Az najdete v tématu věnovaném instalaci Azure PowerShellu.For Az module installation instructions, see Install Azure PowerShell.

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

Azure Storage udržuje víc kopií vašeho účtu úložiště, aby se zajistila odolnost a vysoká dostupnost.Azure Storage maintains multiple copies of your storage account to ensure durability and high availability. 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) nebo geograficky redundantní úložiště (GZRS) (Preview) kopíruje data asynchronně ve dvou geografických oblastech, které mají od sebe nejméně stovky kilometrů.Geo-redundant storage (GRS) or geo-zone-redundant storage (GZRS) (preview) copies 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) nebo geograficky redundantní úložiště s přístupem pro čtení (RA-GZRS) (ve verzi Preview) nabízí 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) or read-access geo-zone-redundant storage (RA-GZRS) (preview) 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.

Další informace o redundanci v Azure Storage najdete v tématu Azure Storage redundance.For more information about redundancy in Azure Storage, see Azure Storage redundancy.

Varování

Geograficky redundantní úložiště přináší riziko ztráty dat.Geo-redundant storage carries a risk of data loss. Data se zkopírují 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 copied 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 zkopírová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 copied to the secondary endpoint will be lost.

Návrh pro zajištění vysoké dostupnostiDesign 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:

  • Disky: 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.
  • Soubory: 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 zkopírují 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 copied 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 zápisem do primární oblasti zkopírována 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 copied to the secondary region. Pokud primární oblast nebude k dispozici, nejaktuálnější zápisy se ještě nezkopírovaly do sekundární oblasti.If the primary region becomes unavailable, the most recent writes may not yet have been copied 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á jsou už zkopírovaná do sekundárního, se při převzetí služeb při selhání uchovávají.All data already copied to the secondary is maintained when the failover happens. Veškerá data zapsaná na primární, která se také zkopírovala do sekundárního, se ale ztratí trvale.However, any data written to the primary that has not also been copied 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 po převzetí služeb při selhání nakonfigurovaný na geografickou redundanci, nová primární oblast začne okamžitě kopírovat data 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 copying 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 zkopírují do nového sekundárního.However, it may take some time before existing data in the primary is fully copied 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 se většina dat v účtu úložiště před navrácením služeb po obnovení nezkopírovala 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 copied 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:

  • Východní AsieAsia East
  • Jihovýchodní AsieAsia Southeast
  • Austrálie – východAustralia East
  • Austrálie – jihovýchodAustralia Southeast
  • USA – středUS Central
  • USA – východ 2US East 2
  • USA – středozápadUS West Central
  • USA – západ 2US West 2

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 5-7 dní.It can take 5-7 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.

Poskytovatel prostředků úložištěStorage resource provider

Po dokončení převzetí služeb při selhání mohou klienti znovu číst a zapisovat Azure Storage data v nové primární oblasti.After a failover is complete, clients can again read and write Azure Storage data in the new primary region. Poskytovatel prostředků Azure Storage ale nepřevezme služby při selhání, takže operace správy prostředků musí stále probíhat v primární oblasti.However, the Azure Storage resource provider does not fail over, so resource management operations must still take place in the primary region. Pokud není primární oblast k dispozici, nebudete moci provádět operace správy v účtu úložiště.If the primary region is unavailable, you will not be able to perform management operations on the storage account.

Vzhledem k tomu, že poskytovatel prostředků Azure Storage převezme služby při selhání, vlastnost Location po dokončení převzetí služeb při selhání vrátí původní primární umístění.Because the Azure Storage resource provider does not fail over, the Location property will return the original primary location after the failover is complete.

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. K převzetí služeb při selhání účtu taky může dojít ke ztrátě dat.Also, there is a potential data loss associated with the account failover. Microsoft doporučuje následující pokyny pro vysokou dostupnost a zotavení po havárii , které jsou specifické pro virtuální počítače v Azure.Microsoft recommends the following high availability and disaster recovery guidance specific to virtual machines in Azure.

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 a službyUnsupported features and services

Pro převzetí služeb při selhání účtu verze Preview nejsou podporované tyto funkce a služby:The following features and 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. U účtů úložiště obsahujících sdílené složky Azure, které se v Synchronizaci souborů Azure používají jako koncové body cloudu, by se nemělo provádět převzetí služeb při selhání.Storage accounts containing Azure file shares being used as cloud endpoints in Azure File Sync should not be failed over. Pokud to uděláte, synchronizace přestane fungovat a v případě nově vrstvených souborů může dojít i k neočekávané ztrátě dat.Doing so will cause sync to stop working and may also cause unexpected data loss in the case of newly tiered files.
  • Úč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.
  • Nepovedlo se převzít služby účtů úložiště obsahující jakékoli povolené kontejnery zásad neměnnosti worm .A storage account containing any WORM immutability policy enabled containers cannot be failed over. Odemčené nebo uzamčené časové uchovávání na základě času nebo zásady právního blokování brání převzetí služeb při selhání, aby se zachovalo dodržování předpisůUnlocked/locked time-based retention or legal hold policies prevent failover in order to maintain compliance.
  • Po dokončení převzetí služeb při selhání můžou přestat fungovat následující funkce: odběry událostí, Změna kanálu, zásady životního cyklua Analýza úložiště protokolování.After the failover is complete, the following features may stop working if originally enabled: Event subscriptions, Change Feed, Lifecycle policies, and 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ého účtu ú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.

Upozornění

Převzetí služeb při selhání účtu by se nemělo používat jako součást vaší strategie migrace dat.An account failover should not be used as part of your data migration strategy.

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.

Další informace najdete v tématechSee also