Vysoká dostupnost a zotavení po havárii pro SQL Server v Azure Virtual MachinesHigh availability and disaster recovery for SQL Server in Azure Virtual Machines

Microsoft Azure virtual machines (VM) pomocí serveru SQL Server může pomoct snížit náklady vysokou dostupnost a po havárii (HADR) databáze řešení pro zotavení.Microsoft Azure virtual machines (VMs) with SQL Server can help lower the cost of a high availability and disaster recovery (HADR) database solution. Většina řešení SQL Server HADR jsou podporovány na virtuálních počítačích Azure, jako jen pro Azure i hybridní řešení.Most SQL Server HADR solutions are supported in Azure virtual machines, both as Azure-only and as hybrid solutions. V řešení jen pro Azure celý systém HADR běží v Azure.In an Azure-only solution, the entire HADR system runs in Azure. V hybridní konfigurace část řešení běží v Azure a další část spustí místní ve vaší organizaci.In a hybrid configuration, part of the solution runs in Azure and the other part runs on-premises in your organization. Flexibilní prostředí Azure můžete splnit snazší plánování rozpočtu a požadavky HADR systémů databáze SQL serveru do Azure přesunout částečně nebo zcela.The flexibility of the Azure environment enables you to move partially or completely to Azure to satisfy the budget and HADR requirements of your SQL Server database systems.

Poznámka

Azure má dva různé modely nasazení pro vytváření a práci s prostředky: Resource Manager a classic.Azure has two different deployment models for creating and working with resources: Resource Manager and classic. Tento článek popisuje použití obou modelů, ale Microsoft doporučuje, aby většina nových nasazení používala model Resource Manager.This article covers using both models, but Microsoft recommends that most new deployments use the Resource Manager model.

Principy potřebné pro HADR řešeníUnderstanding the need for an HADR solution

Je jenom na vás k zajištění, že má databázový systém HADR možnosti, které vyžaduje smlouvu o úrovni služeb (SLA).It is up to you to ensure that your database system possesses the HADR capabilities that the service-level agreement (SLA) requires. Skutečnost, že Azure nabízí mechanismy, vysokou dostupnost, jako je služba opravy pro cloud services a detekce selhání pro zotavení pro virtuální počítače, sám není zaručit, že lze splnit požadované smlouvy SLA.The fact that Azure provides high availability mechanisms, such as service healing for cloud services and failure recovery detection for Virtual Machines, does not itself guarantee you can meet the desired SLA. Tyto mechanismy ochrany vysokou dostupnost virtuálních počítačů, ale ne vysokou dostupnost SQL serveru běžícího uvnitř virtuálních počítačů.These mechanisms protect the high availability of the VMs but not the high availability of SQL Server running inside the VMs. Je možné instanci systému SQL Server selže, když je virtuální počítač online a v dobrém stavu.It is possible for the SQL Server instance to fail while the VM is online and healthy. Kromě toho i vysokou dostupnost, které umožňují mechanismy, které poskytuje Azure výpadek virtuálních počítačů, protože události, například obnovení ze softwaru nebo selhání hardwaru a upgrady operačního systému.Moreover, even the high availability mechanisms provided by Azure allow for downtime of the VMs due to events such as recovery from software or hardware failures and operating system upgrades.

Kromě toho geograficky redundantního úložiště (GRS) v Azure, které je implementované pomocí funkce volána geografickou replikaci, nemusí být řešení pro zotavení po havárii odpovídající databází.In addition, Geo Redundant Storage (GRS) in Azure, which is implemented with a feature called geo-replication, may not be an adequate disaster recovery solution for your databases. Protože geografická replikace asynchronně odešle data, může dojít ke ztrátě při případné havárii nejnovější aktualizace.Because geo-replication sends data asynchronously, recent updates can be lost in the event of disaster. Další informace týkající se geografická replikace omezení jsou popsané v geografická replikace není podporována pro data a soubory protokolu na různých discích oddílu.More information regarding geo-replication limitations are covered in the Geo-replication not supported for data and log files on separate disks section.

HADR architektur nasazeníHADR deployment architectures

SQL Server HADR technologií, které se podporují v Azure zahrnují:SQL Server HADR technologies that are supported in Azure include:

Je možné kombinovat technologie společně k implementaci řešení systému SQL Server, který má vysokou dostupnost a možnosti zotavení po havárii.It is possible to combine the technologies together to implement a SQL Server solution that has both high availability and disaster recovery capabilities. V závislosti na technologii, kterou používáte může vyžadovat hybridního nasazení tunelové připojení VPN s Azure virtual network.Depending on the technology you use, a hybrid deployment may require a VPN tunnel with the Azure virtual network. Následující části popisují, můžete některé příklady architektur nasazení.The sections below show you some of the example deployment architectures.

Azure-only: Řešení s vysokou dostupnostíAzure-only: High availability solutions

Řešení vysoké dostupnosti pro SQL Server může mít na úrovni databáze pomocí skupin dostupnosti Always On - nazývají skupiny dostupnosti.You can have a high availability solution for SQL Server at a database level with Always On Availability Groups - called availability groups. Můžete také vytvořit řešení vysoké dostupnosti na úrovni instance instancemi vždy na převzetí služeb při selhání clusteru – převzetí služeb při selhání instance clusteru.You can also create a high availability solution at an instance level with Always On Failover Cluster Instances - failover cluster instances. Pro zajištění další redundance můžete vytvořit redundanci na obou úrovních vytvořením skupiny dostupnosti na převzetí služeb při selhání instance clusteru.For additional redundancy, you can create redundancy at both levels by creating availability groups on failover cluster instances.

TechnologieTechnology Příklady architekturExample Architectures
Skupiny dostupnostiAvailability groups Repliky dostupnosti spuštěných na virtuálních počítačích Azure ve stejné oblasti zajištění vysoké dostupnosti.Availability replicas running in Azure VMs in the same region provide high availability. Musíte nakonfigurovat řadič domény virtuálního počítače, protože Windows failover clustering vyžaduje doménu služby Active Directory.You need to configure a domain controller VM, because Windows failover clustering requires an Active Directory domain.
Skupiny dostupnostiAvailability Groups
Další informace najdete v tématu konfigurace skupiny dostupnosti v Azure (GUI).For more information, see Configure Availability Groups in Azure (GUI).
Instance clusteru převzetí služeb při selháníFailover cluster instances Instance clusteru převzetí služeb při selhání (FCI), které vyžadují sdílené úložiště, můžete vytvořit 3 různými způsoby.Failover Cluster Instances (FCI), which require shared storage, can be created in 3 different ways.

1. Převzetí služeb při selhání uzlu clusteru se systémem na virtuálních počítačích Azure s používáním připojené služby storage systému Windows Server 2016 prostory úložiště – přímé (S2D) k poskytování softwarových virtuální síť SAN.1. A two-node failover cluster running in Azure VMs with attached storage using Windows Server 2016 Storage Spaces Direct (S2D) to provide a software-based virtual SAN.

2. Převzetí služeb při selhání uzlu clusteru se systémem na virtuálních počítačích Azure s úložištěm podporuje Clusterové řešení třetí strany.2. A two-node failover cluster running in Azure VMs with storage supported by a third-party clustering solution. Konkrétní příklad, který používá SIOS DataKeeper, naleznete v tématu vysoká dostupnost pro sdílenou složku pomocí clusteringu převzetí služeb při selhání a 3. stran software SIOS DataKeeper.For a specific example that uses SIOS DataKeeper, see High availability for a file share using failover clustering and 3rd party software SIOS DataKeeper.

3. Převzetí služeb při selhání uzlu clusteru se systémem na virtuálních počítačích Azure s vzdálené iSCSI Target sdílené blokové úložiště přes ExpressRoute.3. A two-node failover cluster running in Azure VMs with remote iSCSI Target shared block storage via ExpressRoute. Například NetApp Private Storage (NPS) poskytuje cíl iSCSI prostřednictvím ExpressRoute s Equinix na virtuální počítače Azure.For example, NetApp Private Storage (NPS) exposes an iSCSI target via ExpressRoute with Equinix to Azure VMs.

Pro sdílené úložiště jiných výrobců a řešení replikace dat byste požádat dodavatele pro všechny problémy související se přístup k datům na převzetí služeb při selhání.For third-party shared storage and data replication solutions, you should contact the vendor for any issues related to accessing data on failover.

Všimněte si, že při použití FCI nad Azure File storage se zatím nepodporuje, protože toto řešení nevyužívá Premium Storage.Note that using FCI on top of Azure File storage is not supported yet, because this solution does not utilize Premium Storage. Pracujeme na tom pro podporu tohoto brzy.We are working to support this soon.

Azure-only: Řešení zotavení po haváriiAzure-only: Disaster recovery solutions

Můžete mít řešení zotavení po havárii pro databáze SQL serveru v Azure pomocí skupin dostupnosti, zrcadlení databáze nebo zálohování a obnovení s využitím úložiště objektů BLOB.You can have a disaster recovery solution for your SQL Server databases in Azure using availability groups, database mirroring, or backup and restore with storage blobs.

TechnologieTechnology Příklady architekturExample Architectures
Skupiny dostupnostiAvailability Groups Dostupnost replik spuštěných v různých datacentrech ve virtuálních počítačích Azure pro zotavení po havárii.Availability replicas running across multiple datacenters in Azure VMs for disaster recovery. Toto řešení mezi různými oblastmi chrání před výpadkem kompletní lokality.This cross-region solution protects against complete site outage.
Skupiny dostupnostiAvailability Groups
V rámci oblasti musí být všechny repliky v rámci stejné cloudové službě a stejné virtuální síti.Within a region, all replicas should be within the same cloud service and the same VNet. Vzhledem k tomu, že každou oblast, bude mít samostatnou virtuální síť, tato řešení vyžadovat virtuální sítě pro připojení k virtuální síti.Because each region will have a separate VNet, these solutions require VNet to VNet connectivity. Další informace najdete v tématu konfigurace připojení typu VNet-to-VNet pomocí webu Azure portal.For more information, see Configure a VNet-to-VNet connection using the Azure portal. Podrobné pokyny najdete v tématu konfigurace skupiny dostupnosti SQL Server na virtuálních počítačích Azure v různých oblastech.For detailed instructions, see Configure a SQL Server Availability Group on Azure Virtual Machines in Different Regions.
Zrcadlení databázeDatabase Mirroring Instanční objekt a zrcadlové a servery spuštěné v různých datových center pro zotavení po havárii.Principal and mirror and servers running in different datacenters for disaster recovery. Je nutné nasadit pomocí certifikátů serveru.You must deploy using server certificates. Zrcadlení databáze systému SQL Server není podporována pro SQL Server 2008 a SQL Server 2008 R2 na Virtuálním počítači Azure.SQL Server database mirroring is not supported for SQL Server 2008 nor SQL Server 2008 R2 on an Azure VM.
Zrcadlení databáze
Zálohování a obnovení pomocí služby Azure Blob StorageBackup and Restore with Azure Blob Storage Service Produkční databáze zálohovat přímo do úložiště objektů blob v jiném datovém centru pro zotavení po havárii.Production databases backed up directly to blob storage in a different datacenter for disaster recovery.
Zálohování a obnoveníBackup and Restore
Další informace najdete v tématu zálohování a obnovení pro SQL Server ve službě Azure Virtual Machines.For more information, see Backup and Restore for SQL Server in Azure Virtual Machines.
Replikace a převzetí služeb při selhání SQL serveru do Azure pomocí Azure Site RecoveryReplicate and Failover SQL Server to Azure with Azure Site Recovery Provozní Server SQL z jednoho datového centra Azure replikované přímo do služby Azure Storage jiné datové centrum Azure pro zotavení po havárii.Production SQL Server of one Azure datacenter replicated directly to Azure Storage of different Azure datacenter for disaster recovery.
Replikovat pomocí Azure Site RecoveryReplicate using Azure Site Recovery
Další informace najdete v tématu ochraně SQL serveru pomocí zotavení po havárii pro SQL Server a Azure Site Recovery.For more information, see Protect SQL Server using SQL Server disaster recovery and Azure Site Recovery.

Hybridní IT: Řešení zotavení po haváriiHybrid IT: Disaster recovery solutions

Můžete mít řešení zotavení po havárii pro databáze SQL serveru v hybridní IT prostředí pomocí skupin dostupnosti, zrcadlení databáze, přesouvání protokolu a zálohování a obnovení s úložištěm objektů BLOB Azure.You can have a disaster recovery solution for your SQL Server databases in a hybrid-IT environment using availability groups, database mirroring, log shipping, and backup and restore with Azure blog storage.

TechnologieTechnology Příklady architekturExample Architectures
Skupiny dostupnostiAvailability Groups Některé repliky dostupnosti používané virtuálními počítači Azure a ostatními replikami, místní zotavení po havárii mezi weby.Some availability replicas running in Azure VMs and other replicas running on-premises for cross-site disaster recovery. Produkční lokality může být buď místně nebo v datovém centru Azure.The production site can be either on-premises or in an Azure datacenter.
Skupiny dostupnosti
Protože všechny repliky dostupnosti musí být ve stejném clusteru převzetí služeb při selhání, clusteru musí zahrnovat model obě sítě (cluster převzetí služeb při selhání více podsítí).Because all availability replicas must be in the same failover cluster, the cluster must span both networks (a multi-subnet failover cluster). Tato konfigurace vyžaduje propojení VPN mezi Azure a v místní síti.This configuration requires a VPN connection between Azure and the on-premises network.

Pro zotavení po havárii úspěšné vašich databází nainstalujete také repliky řadiče domény v lokalitě zotavení po havárii.For successful disaster recovery of your databases, you should also install a replica domain controller at the disaster recovery site.

Je možné použít Průvodce přidáním repliky v aplikaci SSMS přidání Azure repliky existující skupiny dostupnosti Always On.It is possible to use the Add Replica Wizard in SSMS to add an Azure replica to an existing Always On Availability Group. Další informace najdete v kurzu: Rozšíření skupiny dostupnosti Always On do Azure.For more information, see Tutorial: Extend your Always On Availability Group to Azure.
Zrcadlení databázeDatabase Mirroring Jeden partnerovi běžet ve Virtuálním počítači Azure a další spuštění on-premises pro zotavení po havárii webů pomocí certifikátů serveru.One partner running in an Azure VM and the other running on-premises for cross-site disaster recovery using server certificates. Partneři nemusí být ve stejné doméně služby Active Directory a bez připojení k síti VPN je povinný.Partners do not need to be in the same Active Directory domain, and no VPN connection is required.
Zrcadlení databázeDatabase Mirroring
Jiné databáze zrcadlení scénář zahrnuje jeden partnerovi běžet ve Virtuálním počítači Azure a dalších spuštěné místně ve stejné doméně služby Active Directory pro zotavení po havárii mezi weby.Another database mirroring scenario involves one partner running in an Azure VM and the other running on-premises in the same Active Directory domain for cross-site disaster recovery. A připojení VPN mezi virtuální sítí Azure a v místní síti je povinný.A VPN connection between the Azure virtual network and the on-premises network is required.

Pro zotavení po havárii úspěšné vašich databází nainstalujete také repliky řadiče domény v lokalitě zotavení po havárii.For successful disaster recovery of your databases, you should also install a replica domain controller at the disaster recovery site. Zrcadlení databáze systému SQL Server není podporována pro SQL Server 2008 a SQL Server 2008 R2 na Virtuálním počítači Azure.SQL Server database mirroring is not supported for SQL Server 2008 nor SQL Server 2008 R2 on an Azure VM.
Přesouvání protokoluLog Shipping Jeden server spuštěný ve Virtuálním počítači Azure a další spuštění on-premises pro zotavení po havárii mezi weby.One server running in an Azure VM and the other running on-premises for cross-site disaster recovery. Přesouvání protokolu, závisí na sdílení souborů Windows, takže je nutné připojení VPN mezi virtuální sítí Azure a v místní síti.Log shipping depends on Windows file sharing, so a VPN connection between the Azure virtual network and the on-premises network is required.
Přesouvání protokolu
Pro zotavení po havárii úspěšné vašich databází nainstalujete také repliky řadiče domény v lokalitě zotavení po havárii.For successful disaster recovery of your databases, you should also install a replica domain controller at the disaster recovery site.
Zálohování a obnovení pomocí služby Azure Blob StorageBackup and Restore with Azure Blob Storage Service Místní provozních databází zálohují přímo na úložiště objektů blob v Azure pro zotavení po havárii.On-premises production databases backed up directly to Azure blob storage for disaster recovery.
Zálohování a obnoveníBackup and Restore
Další informace najdete v tématu zálohování a obnovení pro SQL Server ve službě Azure Virtual Machines.For more information, see Backup and Restore for SQL Server in Azure Virtual Machines.
Replikace a převzetí služeb při selhání SQL serveru do Azure pomocí Azure Site RecoveryReplicate and Failover SQL Server to Azure with Azure Site Recovery V místním produkčním replikované přímo do úložiště Azure pro zotavení po havárii serveru SQL Server.On-premises production SQL Server replicated directly to Azure Storage for disaster recovery.
Replikovat pomocí Azure Site RecoveryReplicate using Azure Site Recovery
Další informace najdete v tématu ochraně SQL serveru pomocí zotavení po havárii pro SQL Server a Azure Site Recovery.For more information, see Protect SQL Server using SQL Server disaster recovery and Azure Site Recovery.

Důležité informace týkající se SQL Server HADR v AzureImportant considerations for SQL Server HADR in Azure

Virtuální počítače Azure, úložiště a sítě mají jiné charakteristiky provozní než místní, nevirtualizovaných infrastruktury IT.Azure VMs, storage, and networking have different operational characteristics than an on-premises, non-virtualized IT infrastructure. Úspěšné dokončení implementace řešení HADR SQL serveru v Azure vyžaduje pochopit tyto rozdíly a navrhněte řešení jim přizpůsobit.A successful implementation of a HADR SQL Server solution in Azure requires that you understand these differences and design your solution to accommodate them.

Vysoká dostupnost uzly ve skupině dostupnostiHigh availability nodes in an availability set

Skupiny dostupnosti v Azure umožňují uzly vysoké dostupnosti umístěte do samostatných selhání (FD) a aktualizační doména (ud).Availability sets in Azure enable you to place the high availability nodes into separate Fault Domains (FDs) and Update Domains (UDs). Pro virtuální počítače Azure budou umístěny ve stejné sadě dostupnosti musíte je nasadit v rámci stejné cloudové služby.For Azure VMs to be placed in the same availability set, you must deploy them in the same cloud service. Pouze uzly ve stejné cloudové službě se můžete zúčastnit ve stejné sadě dostupnosti.Only nodes in the same cloud service can participate in the same availability set. Další informace najdete v tématu Správa dostupnosti virtuálních počítačů.For more information, see Manage the Availability of Virtual Machines.

Chování clusteru převzetí služeb při selhání v sítích AzureFailover cluster behavior in Azure networking

RFC neodpovídajících služba DHCP v Azure může způsobit vytvoření určitých převzetí služeb při selhání clusteru konfigurace, které selžou kvůli název sítě s clustery přiřazením duplicitní IP adresu, jako je například stejné IP adresy jako jeden z uzlů clusteru.The non-RFC-compliant DHCP service in Azure can cause the creation of certain failover cluster configurations to fail, due to the cluster network name being assigned a duplicate IP address, such as the same IP address as one of the cluster nodes. Jedná se o problém při implementaci skupin dostupnosti, které závisí na funkci clusteru převzetí služeb při selhání Windows.This is an issue when you implement Availability Groups, which depends on the Windows failover cluster feature.

Když clusteru se dvěma uzly se vytvoří a přepne do online režimu vezměte v úvahu scénář:Consider the scenario when a two-node cluster is created and brought online:

  1. Cluster převede do režimu online a potom NODE1 požádá o dynamicky přidělovanou adresu IP název sítě s clustery.The cluster comes online, then NODE1 requests a dynamically assigned IP address for the cluster network name.
  2. Žádné IP adresy, než NODE1 jeho vlastní IP adresu je dán službu DHCP, protože služba DHCP rozpozná, že žádost pochází z Uzel1 samotný.No IP address other than NODE1’s own IP address is given by the DHCP service, since the DHCP service recognizes that the request comes from NODE1 itself.
  3. Windows zjistí, že duplicitní adresa se přiřadí NODE1 i název sítě s clustery převzetí služeb při selhání a výchozí skupiny clusteru selže do režimu online.Windows detects that a duplicate address is assigned both to NODE1 and to the failover cluster network name, and the default cluster group fails to come online.
  4. Výchozí skupiny clusteru přesune Uzel2, která zpracovává NODE1 na IP adresu jako IP adresu clusteru a přináší výchozí skupiny clusteru online.The default cluster group moves to NODE2, which treats NODE1’s IP address as the cluster IP address and brings the default cluster group online.
  5. Když NODE2 se pokusí navázat připojení s UZEL1, pakety, zaměřuje na NODE1 nikdy neopustí NODE2 protože se překládá NODE1 na IP adresu na sebe sama.When NODE2 attempts to establish connectivity with NODE1, packets directed at NODE1 never leave NODE2 because it resolves NODE1’s IP address to itself. NODE2 nelze navázat spojení s UZEL1, pak dojde ke ztrátě kvora a vypne clusteru.NODE2 cannot establish connectivity with NODE1, then loses quorum and shuts down the cluster.
  6. Do té doby NODE1 mohou odesílat pakety Uzel2, ale nemůže odpovědět, UZEL2.In the meantime, NODE1 can send packets to NODE2, but NODE2 cannot reply. Uzel1 dojde ke ztrátě kvora a cluster vypne.NODE1 loses quorum and shuts down the cluster.

V tomto scénáři se můžete vyhnout tak, že přiřadíte nepoužívaná statická IP adresa, jako jsou specifická pro připojení IP adresu, a to jako 169.254.1.1, název sítě s clustery pamětí pro síťový název clusteru online.This scenario can be avoided by assigning an unused static IP address, such as a link-local IP address like 169.254.1.1, to the cluster network name in order to bring the cluster network name online. Pro zjednodušení tohoto procesu, naleznete v tématu Windows konfigurace převzetí služeb při selhání clusteru v Azure pro skupiny dostupnosti.To simplify this process, see Configuring Windows failover cluster in Azure for availability groups.

Další informace najdete v tématu konfigurace skupin dostupnosti v Azure (GUI).For more information, see Configure availability groups in Azure (GUI).

Podpora naslouchacího procesu skupiny dostupnostiAvailability group listener support

Naslouchacích procesů skupin dostupnosti se podporují v Azure virtuální počítače se systémem Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2 a Windows serveru 2016.Availability group listeners are supported on Azure VMs running Windows Server 2008 R2, Windows Server 2012, Windows Server 2012 R2, and Windows Server 2016. Tato podpora je možné díky použití s vyrovnáváním zatížení povolené koncové body na virtuálních počítačích Azure, které jsou uzly skupiny dostupnosti.This support is made possible by the use of load-balanced endpoints enabled on the Azure VMs that are availability group nodes. Je třeba dodržovat zvláštní konfigurační kroky pro naslouchací procesy pro oba klientské aplikace, na kterých běží v Azure a jak jsou spuštěné místně.You must follow special configuration steps for the listeners to work for both client applications that are running in Azure as well as those running on-premises.

Existují dvě hlavní možnosti pro nastavení vašemu naslouchacímu procesu: externích (veřejných) nebo interní.There are two main options for setting up your listener: external (public) or internal. Naslouchací proces externích (veřejných) používá internetový nástroj pro vyrovnávání zatížení a souvisí s veřejná virtuální IP (VIP), která je přístupná přes internet.The external (public) listener uses an internet facing load balancer and is associated with a public Virtual IP (VIP) that is accessible over the internet. Interního naslouchacího procesu interní nástroj používá a podporuje pouze klienty ve stejné virtuální síti.An internal listener uses an internal load balancer and only supports clients within the same Virtual Network. Buď typ nástroje pro vyrovnávání zatížení, je nutné povolit přímou odpověď serveru.For either load balancer type, you must enable Direct Server Return.

Pokud se skupina dostupnosti zahrnuje několik podsítí Azure (například nasazení, které překročí oblasti Azure), musí obsahovat řetězec připojení klienta "MultisubnetFailover = True".If the Availability Group spans multiple Azure subnets (such as a deployment that crosses Azure regions), the client connection string must include "MultisubnetFailover=True". Výsledkem je pokusy o paralelní připojení repliky v různých podsítích.This results in parallel connection attempts to the replicas in the different subnets. Pokyny týkající se nastavení naslouchacího procesu najdete v tématuFor instructions on setting up a listener, see

Můžete se připojit k každou repliku dostupnosti samostatně přímým připojením k instanci služby.You can still connect to each availability replica separately by connecting directly to the service instance. Navíc protože skupiny dostupnosti jsou zpětně kompatibilní s klienty zrcadlení databáze, můžete připojit k replice dostupnosti jako databáze zrcadlení partneři tak dlouho, dokud repliky jsou nakonfigurované podobný zrcadlení databáze:Also, since availability groups are backward compatible with database mirroring clients, you can connect to the availability replicas like database mirroring partners as long as the replicas are configured similar to database mirroring:

  • Jedna primární replika a jedna sekundární replikaOne primary replica and one secondary replica
  • Sekundární repliky nakonfigurován jako bez možnosti čtení (čitelné sekundární možnost nastavená na hodnotu ne)The secondary replica is configured as non-readable (Readable Secondary option set to No)

Příklad připojovacího řetězce klienta, která odpovídá tuto konfiguraci jako v zrcadlení databáze pomocí ADO.NET nebo SQL Server Native Client je nižší než:An example client connection string that corresponds to this database mirroring-like configuration using ADO.NET or SQL Server Native Client is below:

Data Source=ReplicaServer1;Failover Partner=ReplicaServer2;Initial Catalog=AvailabilityDatabase;

Další informace o připojení klienta najdete v tématu:For more information on client connectivity, see:

Latence sítě v hybridním ITNetwork latency in hybrid IT

Měli byste nasadit řešení HADR za předpokladu, že může být období s vysokou síťovou latencí mezi vaší místní sítí a Azure.You should deploy your HADR solution with the assumption that there may be periods of time with high network latency between your on-premises network and Azure. Při nasazování repliky na Azure, abyste používali asynchronního potvrzování místo synchronním potvrzováním pro režim synchronizace.When deploying replicas to Azure, you should use asynchronous commit instead of synchronous commit for the synchronization mode. Při nasazení databáze zrcadlení servery v místním i v Azure použít režim vysoce výkonné místo režimu vysokou bezpečností.When deploying database mirroring servers both on-premises and in Azure, use the high-performance mode instead of the high-safety mode.

Podpora geografické replikaceGeo-replication support

Geografická replikace disků v Azure nepodporuje datový soubor a soubor protokolu ze stejné databáze, který bude uložen na různých discích.Geo-replication in Azure disks does not support the data file and log file of the same database to be stored on separate disks. GRS replikuje změny na každém disku nezávisle a asynchronně.GRS replicates changes on each disk independently and asynchronously. Tento mechanismus zaručuje zápisu pořadí v rámci jednoho disku na geograficky replikované kopie, ale ne napříč geograficky replikované kopie několik disků.This mechanism guarantees the write order within a single disk on the geo-replicated copy, but not across geo-replicated copies of multiple disks. Pokud nakonfigurujete databázi pro ukládání jeho datového souboru a jeho soubor protokolu na různých discích, obnovené disky po havárii může obsahovat více aktuální kopii souboru dat než v souboru protokolu, což konce dávky zápisu protokolu v systému SQL Server a kyseliny vlastnosti t ctions.If you configure a database to store its data file and its log file on separate disks, the recovered disks after a disaster may contain a more up-to-date copy of the data file than the log file, which breaks the write-ahead log in SQL Server and the ACID properties of transactions. Pokud nemáte možnost zakázat geografické replikace do účtu úložiště, byste měli mít všechna data a soubory protokolu pro danou databázi na stejném disku.If you do not have the option to disable geo-replication on the storage account, you should keep all data and log files for a given database on the same disk. Pokud je nutné použít více než jeden disk z důvodu velikosti databáze, musíte nasadit některé z výše uvedených zajistit redundanci dat řešení pro zotavení po havárii.If you must use more than one disk due to the size of the database, you need to deploy one of the disaster recovery solutions listed above to ensure data redundancy.

Další postupNext steps

Pokud potřebujete vytvořit virtuální počítač Azure s SQL serverem, přečtěte si téma zřízení virtuálního počítače SQL serveru v Azure.If you need to create an Azure virtual machine with SQL Server, see Provisioning a SQL Server Virtual Machine on Azure.

Pokud chcete získat nejlepší výkon ze serveru SQL Server běžící na Virtuálním počítači Azure, přečtěte si pokyny v osvědčené postupy z hlediska výkonu pro SQL Server ve službě Azure Virtual Machines.To get the best performance from SQL Server running on an Azure VM, see the guidance in Performance Best Practices for SQL Server in Azure Virtual Machines.

Další témata související s SQL serverem na virtuálních počítačích Azure, najdete v části systému SQL Server na virtuálních počítačích Azure.For other topics related to running SQL Server in Azure VMs, see SQL Server on Azure Virtual Machines.

Jiné prostředkyOther resources