将 Azure 高级存储用于虚拟机上的 SQL ServerUse Azure Premium Storage with SQL Server on Virtual Machines

概述Overview

Azure 高级 SSD 是提供低延迟和高吞吐量 IO 的下一代存储。Azure premium SSDs is the next generation of storage that provides low latency and high throughput IO. 它最适用于关键 IO 密集型工作负荷,例如 IaaS 虚拟机上的 SQL Server。It works best for key IO intensive workloads, such as SQL Server on IaaS Virtual Machines.

Important

Azure 具有用于创建和处理资源的两个不同的部署模型:资源管理器部署模型和经典部署模型Azure has two different deployment models for creating and working with resources: Resource Manager and Classic. 本文介绍如何使用经典部署模型。This article covers using the Classic deployment model. Azure 建议大多数新部署使用 Resource Manager 模型。Azure recommends that most new deployments use the Resource Manager model.

本文提供迁移运行 SQL Server 的虚拟机以使用高级存储的规划和指南。This article provides planning and guidance for migrating a Virtual Machine running SQL Server to use Premium Storage. 这包括 Azure 基础结构(网络、存储)以及来宾 Windows VM 步骤。This includes Azure infrastructure (networking, storage) and guest Windows VM steps. 要全面了解端到端迁移,熟知如何将迁移较大 VM 以通过 PowerShell 利用改进的本地 SSD 存储,请参阅附录中的示例。The example in the Appendix shows a full comprehensive end to end migration of how to move larger VMs to take advantage of improved local SSD storage with PowerShell.

请务必了解将 Azure 高级存储用于 IAAS VM 上的 SQL Server 的端到端过程。It is important to understand the end-to-end process of utilizing Azure Premium Storage with SQL Server on IAAS VMs. 这包括:This includes:

  • 确定使用高级存储的先决条件。Identification of the prerequisites to use Premium Storage.
  • 针对新部署将 IaaS 上的 SQL Server 部署到高级存储的示例。Examples of deploying SQL Server on IaaS to Premium Storage for new deployments.
  • 迁移现有部署(包括独立服务器和使用 SQL AlwaysOn 可用性组的部署)的示例。Examples of migrating existing deployments, both stand-alone servers and deployments using SQL Always On Availability Groups.
  • 可能的迁移方法。Possible migration approaches.
  • 演示 Azure、Windows 和 SQL Server 如何分步迁移现有 AlwaysOn 实现的完整端到端示例。Full end-to-end example showing Azure, Windows, and SQL Server steps for the migration of an existing Always On implementation.

有关 Azure 虚拟机中的 SQL Server 的更多背景信息,请参阅 Azure 虚拟机中的 SQL ServerFor more background information on SQL Server in Azure Virtual Machines, see SQL Server in Azure Virtual Machines.

作者: Daniel Sol 技术审校: Luis Carlos Vargas Herring、Sanjay Mishra、Pravin Mital、Juergen Thomas、Gonzalo Ruiz。Author: Daniel Sol Technical Reviewers: Luis Carlos Vargas Herring, Sanjay Mishra, Pravin Mital, Juergen Thomas, Gonzalo Ruiz.

高级存储的先决条件Prerequisites for Premium Storage

使用高级存储须满足多个先决条件。There are several prerequisites for using Premium Storage.

虚拟机大小Machine size

要使用高级存储,需要使用 DS 系列虚拟机 (VM)。For using Premium Storage you need to use DS series Virtual Machines (VM). 如果以前尚未在云服务中使用 DS 系列虚拟机,则必须在重新创建 VM 作为 DS* 角色大小之前,删除现有 VM、保留附加磁盘,然后创建新的云服务。If you have not used DS Series machines in your cloud service before, you must delete the existing VM, keep the attached disks, and then create a new cloud service before recreating the VM as DS* role size. 有关虚拟机大小的详细信息,请参阅 Azure 的虚拟机和云服务大小For more information on Virtual Machine sizes, see Virtual Machine and Cloud Service Sizes for Azure.

云服务Cloud services

在新的云服务中创建 VM 时,只能将 DS* VM 用于高级存储。You can only use DS* VMs with Premium Storage when they are created in a new cloud service. 如果在 Azure 中使用 SQL Server AlwaysOn,则 AlwaysOn 侦听器会引用与云服务关联的 Azure 内部或外部负载均衡器 IP 地址。If you are using SQL Server Always On in Azure, the Always On Listener refers to the Azure Internal or External Load Balancer IP address that is associated with a cloud service. 本文重点介绍如何在此场景中迁移,同时保持可用性。This article focuses on how to migrate while maintaining availability in this scenario.

Note

DS* 系列必须是部署到新的云服务的第一个 VM。A DS* Series must be the first VM that is deployed to the new Cloud Service.

区域 VNETRegional VNETS

对于 DS* VM,必须将托管你的 VM 的虚拟网络 (VNET) 配置为区域虚拟网络。For DS* VMs you must configure the Virtual Network (VNET) hosting your VMs to be regional. 这将“加宽”虚拟网络,目的是允许在其他群集中预配更大的 VM,并允许这些 VM 相互通信。This "widens" the VNET is to allow the larger VMs to be provisioned in other clusters and allow communication between them. 在以下屏幕截图中,突出显示的位置显示的是区域 VNET,而第一个结果则显示的是“窄”VNET。In the following screenshot, the highlighted Location shows regional VNETs, whereas the first result shows a "narrow" VNET.

RegionalVNET

可提出要迁移到区域 VNET 的 Azure 支持票证。You can raise a Azure support ticket to migrate to a regional VNET. 随后,Azure 即会进行更改。Azure then makes a change. 要完成到区域 VNET 的迁移,请更改网络配置中的 AffinityGroup 属性。To complete the migration to regional VNETs, change the property AffinityGroup in the network configuration. 首先导出 PowerShell 中的网络配置,然后将 VirtualNetworkSite 元素中的 AffinityGroup 属性替换为 Location 属性。First export the Network Configuration in PowerShell, and then replace the AffinityGroup property in the VirtualNetworkSite element with a Location property. 指定 Location = XXXX,其中 XXXX 是 Azure 区域。Specify Location = XXXX where XXXX is an Azure region. 然后导入新配置。Then import the new configuration.

例如,考虑以下 VNET 配置:For example, considering the following VNET configuration:

<VirtualNetworkSite name="danAzureSQLnet" AffinityGroup="AzureSQLNetwork">
<AddressSpace>
  <AddressPrefix>10.0.0.0/8</AddressPrefix>
  <AddressPrefix>172.16.0.0/12</AddressPrefix>
</AddressSpace>
<Subnets>
...
</VirtualNetworkSite>

要将此移到中国北部的区域 VNET,请将配置更改为以下内容:To move this to a regional VNET in China North, change the configuration to the following:

<VirtualNetworkSite name="danAzureSQLnet" Location="China North">
<AddressSpace>
  <AddressPrefix>10.0.0.0/8</AddressPrefix>
  <AddressPrefix>172.16.0.0/12</AddressPrefix>
</AddressSpace>
<Subnets>
...
</VirtualNetworkSite>

存储帐户Storage accounts

需要新建一个专为高级存储配置的存储帐户。You need to create a new storage account that is configured for Premium Storage. 请注意,在存储帐户(而不是单个 VHD)上设置使用高级存储,但使用 DS* 系列 VM 时,则可以从高级和标准存储帐户附加 VHD。Note that the use of Premium Storage is set at the storage account, not on individual VHDs, however when using a DS* Series VM you can attach VHD's from Premium and Standard Storage accounts. 如果不想将操作系统 VHD 放到高级存储帐户上,则可以考虑此项。You may consider this if you do not want to place the OS VHD on to the Premium Storage account.

以下使用“Premium_LRS”类型New-AzureStorageAccountPowerShell 命令将创建高级存储帐户:The following New-AzureStorageAccountPowerShell command with the "Premium_LRS" Type creates a Premium Storage Account:

$newstorageaccountname = "danpremstor"
New-AzureStorageAccount -StorageAccountName $newstorageaccountname -Location "China North" -Type "Premium_LRS"   

VHD 缓存设置VHDs Cache Settings

在创建属于高级存储帐户的不同磁盘时,主要的区别在于磁盘缓存设置。The main difference between creating disks that are part of a Premium Storage account is the disk cache setting. 对于 SQL Server 数据卷磁盘,建议使用“读取缓存”。For SQL Server Data volume disks it is recommended that you use 'Read Caching'. 对于事务日志卷,磁盘缓存设置应设为“”。For Transaction log volumes, the disk cache setting should be set to 'None'. 这不同于针对标准存储帐户的建议。This is different from the recommendations for Standard Storage accounts.

附加 VHD 后,便不能变更缓存设置。Once the VHDs have been attached, the cache setting cannot be altered. 需分离 VHD,再使用更新后的缓存设置重新附加该 VHD。You would need to detach and reattach the VHD with an updated cache setting.

Windows 存储空间Windows storage spaces

可如在之前的标准存储操作一样使用 Windows 存储空间,这样即可对当前使用存储空间的 VM 进行迁移。You can use Windows Storage Spaces as you did with previous Standard Storage, this allows you to migrate a VM that is already utilizing Storage Spaces. 附录中的示例(步骤 9 及前面的步骤)演示了提取并导入附加了多个 VHD 的 VM 的 Powershell 代码。The example in Appendix (step 9 and forward) demonstrates the Powershell code to extract and import a VM with multiple attached VHDs.

存储池已用于标准 Azure 存储帐户以提高吞吐量并减少延迟。Storage Pools were used with Standard Azure storage account to enhance throughput and reduce latency. 在使用新部署的高级存储测试存储池时,你可能会发现价值,但这样做会增加存储设置的复杂性。You might find value in testing Storage Pools with Premium Storage for new deployments, but they do add additional complexity with storage setup.

如何查明哪些 Azure 虚拟磁盘映射到存储池How to find which Azure Virtual Disks map to storage pools

因为针对附加 VHD 有不同的缓存设置建议,你可能会决定将 VHD 复制到高级存储帐户。As there are different cache setting recommendations for attached VHDs, you might decide to copy the VHDs to a Premium Storage account. 但是,在将它们重新附加到新的 DS 系列 VM 时,可能需要变更缓存设置。However, when you reattach them to the new DS series VM, you might need to alter the cache settings. 当你对 SQL 数据文件和日志文件使用单独的 VHD(而不是同时包含这两种文件的单个 VHD)时,应用高级存储建议的缓存设置将更为简单。It is simpler to apply the Premium Storage recommended cache settings when you have separate VHDs for the SQL Data files and log files (rather than a single VHD that contains both).

Note

如果将 SQL Server 数据和日志文件存储在同一卷上,则所选的缓存选项将取决于数据库工作负荷的 IO 访问模式。If you have SQL Server data and log files on the same volume, the caching option you choose depends on the IO access patterns for your database workloads. 只有测试才能演示哪个缓存选项最适用于这种情况。Only testing can demonstrate which caching option is best for this scenario.

但是,如果使用的 Windows 存储空间由多个 VHD 构成,则需要查看原始脚本,确认每个附加的 VHD 位于哪些特定池中,然后才可相应地对每个磁盘设定缓存设置。However, if you are using Windows Storage Spaces which are made up of multiple VHDs you need to look at your original scripts to identify which attached VHDs are in what specific pool, so you can then set the cache settings accordingly for each disk.

如果没有可显示哪些 VHD 映射到存储池的原始脚本,则可以使用以下步骤来确定磁盘/存储池映射。If you do not have original script available to show you which VHDs map to the storage pool, you can use the following steps to determine the disk/storage pool mapping.

对于每个磁盘,使用以下步骤:For each disk, use the following steps:

  1. 使用 Get-AzureVM 命令获取附加到 VM 的磁盘列表:Get list of disks attached to VM with the Get-AzureVM command:

    Get-AzureVM -ServiceName <servicename> -Name <vmname> | Get-AzureDataDisk
    
  2. 记下 DiskName 和 LUN。Note the DiskName and LUN.

    DisknameAndLUN

  3. 通过远程桌面连接到 VM。Remote desktop into the VM. 然后依次转到“计算机管理” | “设备管理器” | “磁盘驱动器” 。Then go to Computer Management | Device Manager | Disk Drives. 查看每个 Microsoft 虚拟磁盘的属性Look at the properties of each of the 'Microsoft Virtual Disks'

    VirtualDiskProperties

  4. 此处的 LUN 编号是对将 VHD 附加到 VM 时指定的 LUN 编号的引用。The LUN number here is a reference to the LUN number you specify when attaching the VHD to the VM.

  5. 对于“Microsoft 虚拟磁盘”,转到“详细信息” 选项卡,然后在“属性” 列表中转到“驱动程序键” 。For the 'Microsoft Virtual Disk' go to the Details tab, then in the Property list, go to Driver Key. 在“值” 中,注意“偏移量” ,该项在下面的屏幕截图中为 0002。In the Value, note the Offset, which is 0002 in the following screenshot. 0002 表示存储池引用的 PhysicalDisk2。The 0002 denotes the PhysicalDisk2 that the storage pool references.

    VirtualDiskPropertyDetails

  6. 转储每个存储池关联的磁盘:For each storage pool, dump out the associated disks:

    Get-StoragePool -FriendlyName AMS1pooldata | Get-PhysicalDisk
    

GetStoragePool

现在,可以使用此信息将附加 VHD 关联到存储池中的物理磁盘。Now you can use this information to associate attached VHDs to Physical Disks in Storage Pools.

将 VHD 映射到存储池中的物理磁盘后,可以将其分离并复制到高级存储帐户,此后再使用正确的缓存设置进行附加。Once you have mapped VHDs to Physical Disks in Storage Pools you can then detach and copy them over to a Premium Storage account, then attach them with the correct cache setting. 请参阅附录步骤 8 至 12 中的示例。See the example in the Appendix, steps 8 through 12. 以下步骤显示了如何将 VM 附加的 VHD 磁盘配置提取到 CSV 文件、复制 VHD、变更磁盘配置缓存设置,最后将 VM 重新部署为带所有附加磁盘的 DS 系列 VM。These steps show how to extract a VM-attached VHD disk configuration to a CSV file, copy the VHDs, alter the disk configuration cache settings, and finally redeploy the VM as a DS series VM with all the attached disks.

VM 存储带宽和 VHD 存储吞吐量VM storage bandwidth and VHD storage throughput

存储量性能取决于指定的 DS* VM 大小和 VHD 大小。The amount of storage performance depends on the DS* VM size specified and the VHD sizes. 可附加到 VM 的 VHD 限额数量不同,且每个 VM 支持的最大带宽(MB/秒)也不同。The VMs have different allowances for the number of VHDs that can be attached and the maximum bandwidth they support (MB/s). 有关特定带宽数字,请参阅 Azure 的虚拟机和云服务大小For the specific bandwidth numbers, see Virtual Machine and Cloud Service Sizes for Azure.

较大的磁盘大小可提高 IOPS。Increased IOPS are achieved with larger disk sizes. 考虑迁移路径时,应考虑这一点。You should consider this when you think about your migration path. 有关详细信息,请参阅 IOPS 和磁盘类型的表For details, see the table for IOPS and Disk Types.

最后,需考虑到对于所附加的每个磁盘,VM 支持的最大磁盘带宽不同。Finally, consider that VMs have different maximum disk bandwidths that they support for all disks attached. 在高负载下可使可供该 VM 角色大小使用的最大磁盘带宽饱和。Under high load, you could saturate the maximum disk bandwidth available for that VM role size. 例如,Standard_DS14 最多支持 512MB/秒;因此,三个 P30 磁盘就能让 VM 的磁盘带宽达到饱和。For example a Standard_DS14 supports up to 512MB/s; therefore, with three P30 disks you could saturate the disk bandwidth of the VM. 但在此示例中,可以超出吞吐量限制,具体取决于读取和写入 IO 的组合。But in this example, the throughput limit could be exceeded depending on the mix of read and write IOs.

新建部署New deployments

接下来的两部分演示如何将 SQL Server VM 部署到高级存储。The next two sections demonstrate how you can deploy SQL Server VMs to Premium Storage. 如前所述,不一定需要将操作系统磁盘放到高级存储上。As mentioned before, you do not necessarily need to place the OS disk onto Premium storage. 如果打算将任何密集型 IO 工作负荷放置在操作系统 VHD 上,则可以选择这样做。You might choose to do this if you are intending to place any intensive IO workloads on the OS VHD.

第一个示例演示了如何利用现有 Azure 库映像。The first example demonstrates utilizing existing Azure Gallery Images. 第二个示例演示了如何使用现有标准存储帐户中的自定义 VM 映像。The second example shows how to use a custom VM image that you have in an existing Standard storage account.

Note

这些示例假定已创建区域 VNET。These examples assume that you have already created a Regional VNET.

下面的示例演示了如何将操作系统 VHD 放置到高级存储上并附加高级存储 VHD。The example below shows how to place the OS VHD onto premium storage and attach Premium Storage VHDs. 但是,也可以将操作系统磁盘放置在标准存储帐户中,并附加驻留在高级存储帐户中的 VHD。However, you can also place the OS disk in a Standard Storage account and then attach VHDs that reside in a Premium Storage account. 将演示这两种方案。Both scenarios are demonstrated.

$mysubscription = "DansSubscription"
$location = "China North"

#Set up subscription
Set-AzureSubscription -SubscriptionName $mysubscription
Select-AzureSubscription -SubscriptionName $mysubscription -Current  

步骤 1:创建高级存储帐户Step 1: Create a Premium Storage Account

#Create Premium Storage account, note Type
$newxiostorageaccountname = "danspremsams"
New-AzureStorageAccount -StorageAccountName $newxiostorageaccountname -Location $location -Type "Premium_LRS"  

步骤 2:创建新的云服务Step 2: Create a New Cloud Service

$destcloudsvc = "danNewSvcAms"
New-AzureService $destcloudsvc -Location $location

步骤 3:保留云服务 VIP(可选)Step 3: Reserve a Cloud Service VIP (Optional)

#check exisitng reserved VIP
Get-AzureReservedIP

$reservedVIPName = "sqlcloudVIP"
New-AzureReservedIP -ReservedIPName $reservedVIPName -Label $reservedVIPName -Location $location

步骤 4:创建 VM 容器Step 4: Create a VM Container

#Generate storage keys for later
$xiostorage = Get-AzureStorageKey -StorageAccountName $newxiostorageaccountname

##Generate storage acc contexts
$xioContext = New-AzureStorageContext -Environment AzureChinaCloud -StorageAccountName $newxiostorageaccountname -StorageAccountKey $xiostorage.Primary   

#Create container
$containerName = 'vhds'
New-AzureStorageContainer -Name $containerName -Context $xioContext

步骤 5:将操作系统 VHD 放置在标准或高级存储上Step 5: Placing OS VHD on Standard or Premium Storage

#NOTE: Set up subscription and default storage account which is used to place the OS VHD in

#If you want to place the OS VHD Premium Storage Account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount  $newxiostorageaccountname  

#If you wanted to place the OS VHD Standard Storage Account but attach Premium Storage VHDs then you would run this instead:
$standardstorageaccountname = "danstdams"

Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount  $standardstorageaccountname

步骤 6:创建 VMStep 6: Create VM

#Get list of available SQL Server Images from the Azure Image Gallery.
$galleryImage = Get-AzureVMImage | where-object {$_.ImageName -like "*SQL*2014*Enterprise*"}
$image = $galleryImage.ImageName

#Set up Machine Specific Information
$vmName = "dsDan1"
$vnet = "dansvnetwesteur"
$subnet = "SQL"
$ipaddr = "192.168.0.8"

#Remember to change to DS series VM
$newInstanceSize = "Standard_DS1"

#create new Availability Set
$availabilitySet = "cloudmigAVAMS"

#Machine User Credentials
$userName = "myadmin"
$pass = "mycomplexpwd4*"

#Create VM Config
$vmConfigsl = New-AzureVMConfig -Name $vmName -InstanceSize $newInstanceSize -ImageName $image  -AvailabilitySetName $availabilitySet  ` | Add-AzureProvisioningConfig -Windows ` -AdminUserName $userName -Password $pass | Set-AzureSubnet -SubnetNames $subnet | Set-AzureStaticVNetIP -IPAddress $ipaddr

#Add Data and Log Disks to VM Config
#Note the size specified '-DiskSizeInGB 1023', this attaches 2 x P30 Premium Storage Disk Type
#Utilising the Premium Storage enabled Storage account

$vmConfigsl | Add-AzureDataDisk -CreateNew -DiskSizeInGB 1023 -LUN 0 -HostCaching "ReadOnly"  -DiskLabel "DataDisk1" -MediaLocation "https://$newxiostorageaccountname.blob.core.chinacloudapi.cn/vhds/$vmName-data1.vhd"
$vmConfigsl | Add-AzureDataDisk -CreateNew -DiskSizeInGB 1023 -LUN 1 -HostCaching "None"  -DiskLabel "logDisk1" -MediaLocation "https://$newxiostorageaccountname.blob.core.chinacloudapi.cn/vhds/$vmName-log1.vhd"

#Create VM
$vmConfigsl  | New-AzureVM -ServiceName $destcloudsvc -VNetName $vnet ## Optional (-ReservedIPName $reservedVIPName)  

#Add RDP Endpoint
$EndpointNameRDPInt = "3389"
Get-AzureVM -ServiceName $destcloudsvc -Name $vmName | Add-AzureEndpoint -Name "EndpointNameRDP" -Protocol "TCP" -PublicPort "53385" -LocalPort $EndpointNameRDPInt  | Update-AzureVM

#Check VHD storage account, these should be in $newxiostorageaccountname
Get-AzureVM -ServiceName $destcloudsvc -Name $vmName | Get-AzureDataDisk
Get-AzureVM -ServiceName $destcloudsvc -Name $vmName |Get-AzureOSDisk

使用自定义映像创建新的 VM 以使用高级存储Create a new VM to use Premium Storage with a custom image

此方案演示了现有自定义映像驻留于标准存储帐户中的情况。This scenario demonstrates where you have existing customized images that reside in a Standard Storage account. 如前所述,如果要将操作系统 VHD 放置在高级存储上,需要复制标准存储帐户中存在的映像,并将它们传输到高级存储中,才能使用它们。As mentioned if you want to place the OS VHD on Premium Storage you need to copy the image that exists in the Standard Storage account and transfer them to a Premium Storage before it can be used. 如果在本地有一个映像,也可以使用此方法将该映像直接复制到高级存储帐户。If you have an image on-premises, you can also use this method to copy that directly to the Premium Storage account.

步骤 1:创建存储帐户Step 1: Create Storage Account

$mysubscription = "DansSubscription"
$location = "China North"

#Create Premium Storage account
$newxiostorageaccountname = "danspremsams"
New-AzureStorageAccount -StorageAccountName $newxiostorageaccountname -Location $location -Type "Premium_LRS"  

#Standard Storage account
$origstorageaccountname = "danstdams"

步骤 2:创建云服务Step 2 Create Cloud Service

$destcloudsvc = "danNewSvcAms"
New-AzureService $destcloudsvc -Location $location

步骤 3:使用现有映像Step 3: Use existing image

可以使用现有映像,You can use an existing image. 也可以创建现有虚拟机的映像Or, you can take an image of an existing machine. 请注意,执行映像的计算器不一定要是 DS* 计算机。Note the machine that you image does not have to be DS* machine. 获得映像后,以下步骤演示如何使用 Start-AzureStorageBlobCopy PowerShell commandlet 将其复制到高级存储帐户。Once you have the image, the following steps show how to copy it to the Premium Storage account with the Start-AzureStorageBlobCopy PowerShell commandlet.

Add-AzureAccount -Environment AzureChinaCloud
#Get storage account keys:
#Standard Storage account
$originalstorage =  Get-AzureStorageKey -StorageAccountName $origstorageaccountname
#Premium Storage account
$xiostorage = Get-AzureStorageKey -StorageAccountName $newxiostorageaccountname

#Set up contexts for the storage accounts:
$origContext = New-AzureStorageContext -StorageAccountName $origstorageaccountname -StorageAccountKey $originalstorage.Primary
$destContext = New-AzureStorageContext -StorageAccountName $newxiostorageaccountname -StorageAccountKey $xiostorage.Primary  

步骤 4:在存储帐户之间复制 BlobStep 4: Copy Blob between Storage Accounts

#Get Image VHD
$myImageVHD = "dansoldonorsql2k14-os-2015-04-15.vhd"
$containerName = 'vhds'

#Copy Blob between accounts
$blob = Start-AzureStorageBlobCopy -SrcBlob $myImageVHD -SrcContainer $containerName `
-DestContainer vhds -Destblob "prem-$myImageVHD" `
-Context $origContext -DestContext $destContext  

步骤 5:定期检查复制状态:Step 5: Regularly check copy status:

$blob | Get-AzureStorageBlobCopyState

步骤 6:将映像磁盘添加到订阅中的 Azure 磁盘存储库Step 6: Add Image disk to Azure disk Repository in Subscription

$imageMediaLocation = $destContext.BlobEndPoint+"/"+$myImageVHD
$newimageName = "prem"+"dansoldonorsql2k14"

Add-AzureVMImage -ImageName $newimageName -MediaLocation $imageMediaLocation

Note

你可能会发现即使状态报告为成功,也仍会收到磁盘租约错误。You may find that even though the status reports as success, you could still get a disk lease error. 在这种情况下,请等待大约 10 分钟。In this case, wait about 10 minutes.

步骤 7:构建 VMStep 7: Build the VM

在此将基于映像生成 VM 并附加两个高级存储 VHD:Here you are building the VM from your image and attaching two Premium Storage VHDs:

$newimageName = "prem"+"dansoldonorsql2k14"
#Set up Machine Specific Information
$vmName = "dansolchild"
$vnet = "westeur"
$subnet = "Clients"
$ipaddr = "192.168.0.41"

#This needs to be a new cloud service
$destcloudsvc = "danregsvcamsxio2"

#Use to DS Series VM
$newInstanceSize = "Standard_DS1"

#create new Availability Set
$availabilitySet = "cloudmigAVAMS3"

#Machine User Credentials
$userName = "myadmin"
$pass = "theM)stC0mplexP@ssw0rd!"

#Create VM Config
$vmConfigsl2 = New-AzureVMConfig -Name $vmName -InstanceSize $newInstanceSize -ImageName $newimageName  -AvailabilitySetName $availabilitySet  ` | Add-AzureProvisioningConfig -Windows ` -AdminUserName $userName -Password $pass | Set-AzureSubnet -SubnetNames $subnet | Set-AzureStaticVNetIP -IPAddress $ipaddr

$vmConfigsl2 | Add-AzureDataDisk -CreateNew -DiskSizeInGB 1023 -LUN 0 -HostCaching "ReadOnly"  -DiskLabel "DataDisk1" -MediaLocation "https://$newxiostorageaccountname.blob.core.chinacloudapi.cn/vhds/$vmName-Datadisk-1.vhd"
$vmConfigsl2 | Add-AzureDataDisk -CreateNew -DiskSizeInGB 1023 -LUN 1 -HostCaching "None"  -DiskLabel "LogDisk1" -MediaLocation "https://$newxiostorageaccountname.blob.core.chinacloudapi.cn/vhds/$vmName-logdisk-1.vhd"

$vmConfigsl2 | New-AzureVM -ServiceName $destcloudsvc -VNetName $vnet

未使用 AlwaysOn 可用性组的现有部署Existing deployments that do not use Always On Availability Groups

Note

对于现有部署,请先参阅本文的先决条件部分。For existing deployments, first see the Prerequisites section of this article.

未使用 AlwaysOn 可用性组的 SQL Server 部署和使用这些组的 SQL Server 部署有不同的注意事项。There are different considerations for SQL Server deployments that do not use Always On Availability Groups and those that do. 如果未使用 AlwaysOn 且具备现有独立 SQL Server,则可通过新的云服务和存储帐户升级到高级存储。If you are not using Always On and have an existing standalone SQL Server, you can upgrade to Premium Storage by using a new cloud service and storage account. 请考虑以下选项:Consider the following options:

  • 创建新的 SQL Server VMCreate a new SQL Server VM. 可以创建使用高级存储帐户的新 SQL Server VM,如“新建部署”中所述。You can create a new SQL Server VM that uses a Premium Storage account, as documented in New Deployments. 然后对 SQL Server 和用户数据库进行备份和还原。Then back up and restore your SQL Server configuration and user databases. 无论是从内部还是外部进行访问,都需要更新应用程序才可引用新的 SQL Server 。The application needs to be updated to reference the new SQL Server if it is being accessed internally or externally. 需要复制所有“数据库外”对象,就像执行并排 (SxS) SQL Server 迁移一样。You would need to copy all 'out of db' objects as if you were doing a Side by Side (SxS) SQL Server migration. 这包括登录名、证书和链接服务器等对象。This includes objects such as logins, certificates, and linked servers.
  • 迁移现有 SQL Server VMMigrate an existing SQL Server VM. 为此,需使 SQL Server VM 脱机,然后将其传输到新的云服务,包括将其附加的所有 VHD 复制到高级存储帐户。This requires taking the SQL Server VM offline, then transferring it to a new cloud service, which includes copying all of its attached VHDs to the Premium Storage account. VM 重新联机后,应用程序将如之前一般引用服务器主机名。When the VM comes online, the application references the server host name as before. 请注意,现有磁盘的大小会映像性能特征。Be aware that the size of the existing disk affects the performance characteristics. 例如,400 GB 磁盘将向上舍入到 P20。For example, a 400 GB disk gets rounded up to a P20. 如果确定自己不需要该磁盘性能,则可以将 VM 重新创建为 DS 系列 VM,并附加具有所需大小/性能指标的高级存储 VHD。If you know that you do not require that disk performance, then you could recreate the VM as a DS Series VM, and attach Premium Storage VHDs of the size/performance specification you require. 然后,可以分离并重新附加 SQL DB 文件。Then you could detach and reattach the SQL DB files.

Note

复制 VHD 磁盘时,应注意磁盘大小。取决于大小是指这些磁盘所属的高级存储磁盘类型,它决定了磁盘性能规格。When copying the VHD disks you should be aware of the size, depending on the size means what Premium Storage Disk type they fall into, this determines disk performance specification. Azure 向上四舍五入到最近的磁盘大小,因此如果你的磁盘为 400GB,系统将舍入为 P20。Azure rounds up to the nearest disk size, so if you have a 400GB disk, this is rounded up to a P20. 根据操作系统 VHD 的现有 IO 要求,可能不需要将此 VHD 迁移到高级存储帐户。Depending on your existing IO requirements of the OS VHD, you might not need to migrate this to a Premium Storage account.

如果是从外部访问 SQL Server,则云服务 VIP 将不同。If your SQL Server is accessed externally, then the cloud service VIP changes. 还必须更新终结点、ACL 和 DNS 设置。You also have to update end points, ACLs, and DNS settings.

使用 AlwaysOn 可用性组的现有部署Existing deployments that use Always On Availability Groups

Note

对于现有部署,请先参阅本文的先决条件部分。For existing deployments, first see the Prerequisites section of this article.

在本部分的开头,将介绍 AlwaysOn 如何与 Azure 网络进行交互。Initially in this section we look at how Always On interacts with Azure Networking. 然后将迁移细分为两个部分:可容忍某些停机情况的迁移,以及必须达到最低停机时间的迁移。We then break down migrations in to two scenarios: migrations where some downtime can be tolerated and migrations where you must achieve minimal downtime.

本地 SQL Server AlwaysOn 可用性组使用本地侦听器,该侦听器会注册虚拟 DNS 名称以及在一个或多个 SQL Server 之间共享的 IP 地址。On-premises SQL Server Always On Availability Groups use a Listener on-premises that registers a virtual DNS name along with an IP address that is shared between one or more SQL Servers. 当客户端连接时,会将它们通过侦听器 IP 路由到主 SQL Server。When clients connect they are routed through the listener IP to the Primary SQL Server. 这是当时拥有 AlwaysOn IP 资源的服务器。This is the server that owns the Always On IP resource at that time.

DeploymentsUseAlwaysOn

在 Azure 中,只能将一个 IP 地址分配给 VM 上的 NIC,因此,为了实现与本地相同的抽象层,Azure 将利用分配给内部/外部负载均衡器 (ILB/ELB) 的 IP 地址。In Azure you can have only one IP address assigned to a NIC on the VM, so in order to achieve the same layer of abstraction as on-premises, Azure utilizes the IP address that is assigned to the Internal/External Load Balancers (ILB/ELB). 在服务器间共享的 IP 资源会设置为与 ILB/ELB 相同的 IP。The IP resource that is shared between the servers is set to the same IP as the ILB/ELB. 此 IP 在 DNS 中发布,客户端流量通过 ILB/ELB 传递到主 SQL Server 副本。This is published in the DNS, and client traffic is passed through the ILB/ELB to the Primary SQL Server replica. ILB/ELB 知道哪个 SQL Server 是主服务器,因为它使用探测器来探测 AlwaysOn IP 资源。The ILB/ELB knows which SQL Server is primary since it uses probes to probe the Always On IP resource. 在前面的示例中,它会探测 ELB/ILB 引用的终结点所在的每个节点,做出响应的则是主 SQL Server。In the previous example, it probes each node that has an endpoint referenced by the ELB/ILB, whichever responds is the Primary SQL Server.

Note

ILB 和 ELB 均必须分配给特定的 Azure 云服务,因此最可能出现的情况是 Azure 中的云迁移均会造成负载均衡器 IP 发生改变。The ILB and ELB are both assigned to a particular Azure cloud service, therefore any cloud migration in Azure most likely means that the Load Balancer IP changes.

迁移允许停机一段时间的 AlwaysOn 部署Migrating Always On deployments that can allow some downtime

可通过两种策略迁移允许停机一段时间的 AlwaysOn 部署:There are two strategies to migrate Always On deployments that allow for some downtime:

  1. 将更多辅助副本添加到现有 AlwaysOn 群集Add more secondary replicas to an existing Always On Cluster
  2. 迁移到新的 AlwaysOn 群集Migrate to a new Always On Cluster

1.将更多辅助副本添加到现有 Always On 群集1. Add more Secondary Replicas to an Existing Always On Cluster

一种策略是将更多辅助副本添加到 AlwaysOn 可用性组。One strategy is to add more secondaries to the Always On Availability Group. 需要将这些辅助副本添加到新的云服务中,并使用新的负载均衡器 IP 更新侦听器。You need to add these into a new cloud service and update the listener with the new load balancer IP.

停机时间点:Points of downtime:
  • 群集验证。Cluster Validation.
  • 测试新辅助副本的 AlwaysOn 故障转移。Testing Always On failovers for New Secondaries.

如果在 VM 中使用 Windows 存储池来提高 IO 吞吐量,则这些副本在完全群集验证期间处于脱机状态。If you are using Windows Storage Pools within the VM for higher IO throughput, then these are taken offline during a Full Cluster Validation. 向群集添加节点时需要进行验证测试。The validation test is required when you add nodes to the cluster. 运行测试所花的时间不同,因此需在各自的测试环境中进行测试,了解该操作所耗费的大致时间。The time it takes to run the test can vary, so you should test this in your representative test environment to get an approximate time of how long this takes.

应设置可对新添加的节点执行手动故障转移和混沌测试的时间,确保 AlwaysOn 高可用性功能按预期工作。You should provision time where you can perform manual failover and chaos testing on the newly added nodes to ensure Always On High Availability functions as expected.

DeploymentsUseAlwaysOn2

Note

运行验证前,应停止使用存储池的所有 SQL Server 实例。You should stop all instances of SQL Server where the Storage Pools are used before the Validation runs.

高级步骤High-level steps
  1. 在使用附加高级存储的新云服务中创建两个新的 SQL Server。Create two new SQL Servers in new cloud service with attached Premium Storage.

  2. 使用 NORECOVERY复制完整备份并进行还原。Copy over FULL backups and restore with NORECOVERY.

  3. 复制“用户数据库外”依赖对象,例如登录名等。Copy over 'out of user DB' dependent objects, such as logins etc.

  4. 新建内部负载均衡器 (ILB) 或使用外部负载均衡器 (ELB),然后在这两个新节点上设置负载均衡终结点。Create new a new Internal Load Balancer (ILB) or use an External Load Balancer (ELB), and then set up Load Balanced Endpoints on both new nodes.

    Note

    继续下一步之前,检查所有节点的终结点配置是否正确Check all Nodes have the correct Endpoint configuration before you continue

  5. 禁止用户/应用程序访问 SQL Server(如果使用存储池)。Stop User/Application Access to the SQL Server (if using Storage Pools).

  6. 停止所有节点上的 SQL Server 引擎服务(如果使用存储池)。Stop SQL Server Engine Services on All Nodes (if using Storage Pools).

  7. 将新节点添加到群集并运行完整验证。Add new Nodes to cluster and run full validation.

  8. 成功验证后,启动所有 SQL Server 服务。Once Validation is successful, start all SQL Server Services.

  9. 备份事务日志并还原用户数据库。Backup Transaction logs, and restore user databases.

  10. 将新节点添加到 AlwaysOn 可用性组中,并将复制置为“同步” 。Add new nodes into the Always On Availability Group and place replication into Synchronous.

  11. 根据 附录中的多站点示例,通过 PowerShell 为 AlwaysOn 添加新云服务 ILB/ELB 的 IP 地址资源。Add the IP address resource of the new Cloud Service ILB/ELB through PowerShell for Always On based on the Multi-site example in the Appendix. 在 Windows 群集中,将 IP 地址资源的可能所有者设置为新节点 old。In Windows clustering, set the Possible owners of the IP Address resource to the new nodes old. 请参阅 附录的“在同一子网中添加 IP 地址资源”部分。See the 'Adding IP Address Resource on Same Subnet' section of the Appendix.

  12. 故障转移到新节点之一。Failover to one of the new nodes.

  13. 将新节点设为“自动故障转移伙伴”并测试故障转移。Make the new nodes Auto Failover Partners and test failovers.

  14. 从可用性组中删除原始节点。Remove original nodes from Availability Group.

优点Advantages
  • 在将新 SQL Server(SQL Server 和应用程序)添加到 Always On 之前,可以对其进行测试。New SQL Servers can be tested (SQL Server and Application) before they are added to Always On.
  • 可以根据确切需求更改 VM 大小和自定义存储。You can change the VM size and customize the storage to your exact requirements. 但是,保持所有 SQL 文件路径不变会非常有益。However, it would be beneficial to keep all the SQL file paths the same.
  • 可控制何时开始将 DB 备份转移到辅助副本。You can control when the transfer of the DB backups to the Secondary Replicas is started. 这不同于使用 Azure Start-AzureStorageBlobCopy commandlet 复制 VHD,因为这是异步复制。This differs from using Azure Start-AzureStorageBlobCopy commandlet to copy VHDs, because that is an asynchronous copy.
缺点Disadvantages
  • 使用 Windows 存储池时,在对新的附加节点进行完整群集验证的过程中,会存在群集停机时间。When using Windows Storage Pools, there is Cluster downtime during the Full Cluster Validation for the new additional nodes.
  • 根据 SQL Server 版本和现有的辅助副本数,如果不删除现有辅助副本,可能不能添加更多辅助副本。Depending on the SQL Server Version and the existing number of secondary replicas, you might not be able to add more secondary replicas without removing existing secondaries.
  • 设置辅助副本时,SQL 数据传输时间可能会很长。There could be long SQL data transfer time while setting up the secondaries.
  • 在迁移期间,并行运行新计算机时会产生额外费用。There is additional cost during migration while you have new machines running in parallel.

2.迁移到新的 Always On 群集2. Migrate to a new Always On Cluster

另一种策略是在新的云服务中创建包含全新节点的新 AlwaysOn 群集,并重定向客户端以使用该群集。Another strategy is to create a brand new Always On Cluster with brand new nodes in new cloud service and then redirect the clients to use it.

停机时间点Points of downtime

将应用程序和用户转移到新的 AlwaysOn 侦听器时会出现停机。There is downtime when you transfer applications and users to the new Always On listener. 停机时间取决于:The downtime depends on:

  • 将最后一个事务日志备份还原到新服务器上的数据库时所用的时间。The time taken to restore final transaction log backups to databases on new servers.
  • 更新客户端应用程序以使用新的 AlwaysOn 侦听器所用的时间。The time taken to update client applications to use new Always On listener.
优点Advantages
  • 可以测试实际生产环境、SQL Server 和操作系统内部更改。You can test the actual production environment, SQL Server, and OS build changes.
  • 可以选择自定义存储并可能减小 VM 的大小。You have the option to customize the storage and to potentially reduce size of VM. 这样可以降低成本。This could result in cost reduction.
  • 可以在此过程中更新 SQL Server 版本。You can update your SQL Server build or version during this process. 还可以升级操作系统。You can also upgrade the Operating System.
  • 以前的 AlwaysOn 群集可用作稳定的回滚目标。The previous Always On Cluster can act as a solid rollback target.
缺点Disadvantages
  • 如果希望同时运行两个 AlwaysOn 群集,则需要更改侦听器的 DNS 名称。You need to change the DNS name of the listener if you want both Always On clusters running simultaneously. 这会增加迁移过程中的管理开销,因为客户端应用程序字符串必须反映新的侦听器名称。This adds administration overhead during the migration as client application strings must reflect the new Listener name.
  • 必须实现两种环境之间的同步机制,使它们尽可能接近,以最大程度地降低在迁移之前执行最终同步的要求。You must implement a synchronization mechanism between the two environments to keep them as close as possible to minimize the final synchronization requirements before migration.
  • 在迁移期间运行新环境会增加成本。There is added cost during migration while you have the new environment running.

迁移 AlwaysOn 部署以实现最短停机时间Migrating Always On Deployments for minimal downtime

可通过两种策略迁移 AlwaysOn 部署以实现最短停机时间:There are two strategies for migrating Always On deployments for minimal downtime:

  1. 利用现有的辅助副本:单站点Utilize an Existing Secondary: Single-Site
  2. 利用现有的辅助副本:多站点Utilize Existing Secondary Replica(s): Multi-Site

1.利用现有的辅助副本:单站点1. Utilize an existing secondary: Single-Site

实现最短停机时间的一个策略是获取现有的云辅助版本并将其从当前云服务中删除。One strategy for minimal downtime is to take an existing cloud secondary and remove it from the current cloud service. 然后将 VHD 复制到新的高级存储帐户,并在新的云服务中创建 VM。Then copy the VHDs to the new Premium Storage account, and create the VM in the new cloud service. 然后,在群集和故障转移中更新侦听器。Then update the listener in clustering and failover.

停机时间点Points of downtime
  • 使用负载均衡终结点更新最后一个节点时会出现停机。There is downtime when you update the final node with the Load Balanced endpoint.

  • 客户端重新连接可能会延迟,具体取决于客户端/DNS 配置。Your client reconnection might be delayed depending on your client/DNS configuration.

  • 如果选择使 AlwaysOn 群集组脱机以提取 IP 地址,则停机时间会增加。There is additional downtime if you choose to take the Always On Cluster group offline to swap out the IP addresses. 可对添加的 IP 地址资源使用 OR 依赖关系和可能的所有者,进而避免出现这种情况。You can avoid this by using an OR dependency and Possible Owners for the added IP Address resource. 请参阅 附录的“在同一子网中添加 IP 地址资源”部分。See the 'Adding IP Address Resource on Same Subnet' section of the Appendix.

    Note

    如果想让添加的节点用作 AlwaysOn 故障转移伙伴,需要添加引用负载均衡集的 Azure 终结点。When you want the added node to partake in as an Always On Failover Partner, you need to add an Azure Endpoint with a reference to the Load Balanced Set. 运行 Add-AzureEndpoint 命令来执行此操作时,当前连接保持断开,但在更新负载均衡器之后,才能建立到侦听器的新连接 。When you run the Add-AzureEndpoint command to do this, current connections to remain open, but new connections to the listener are not able to be established until the load balancer has updated. 在测试时,此现像持续了 90 到 120 秒,应该对此进行测试。In testing this was seen to last 90-120seconds, this should be tested.

优点Advantages
  • 在迁移期间不会产生额外的费用。No extra cost incurred during migration.
  • 一对一迁移。A one-to-one migration.
  • 降低了复杂性。Reduced complexity.
  • 可提高高级存储 SKU 的 IOPS。Allows for increased IOPS from Premium Storage SKUs. 将磁盘与 VM 分离并复制到新的云服务中时,可以使用第三方工具来增加 VHD 大小,以便提供更高的吞吐量。When the disks are detached from the VM and copied to the new cloud service, a 3rd party tool can be used to increase the VHD size, which provides higher throughputs. 有关增加 VHD 大小的信息,请参阅此 论坛讨论For increasing VHD sizes, see this forum discussion.
缺点Disadvantages
  • 在迁移期间,会暂时失去高可用性和灾难恢复。There is a temporary loss of HA and DR during migration.
  • 由于此操作是一对一迁移,因此必须使用支持 VHD 数量的最小 VM 大小,这样可能就无法缩小 VM 的大小。As this is a 1:1 migration, you have to use a minimum VM size that supports your number of VHDs, so you might not be able to downsize your VMs.
  • 此方案会使用 Azure Start-AzureStorageBlobCopy commandlet,它是异步的。This scenario would use the Azure Start-AzureStorageBlobCopy commandlet, which is asynchronous. 复制完成后没有 SLA。There is no SLA on copy completion. 复制所用的时间不同,而这取决于在队列中的等待情况,还取决于要传输的数据量。The time of the copies varies, while this depends on wait in queue it also depends on the amount of data to transfer. 如果传输目标是支持其他区域中的高级存储的另一个 Azure 数据中心,则复制时间会增加。The copy time increases if the transfer is going to another Azure data center that supports Premium Storage in another region. 如果只有 2 个节点,请考虑可能的缓解措施,以防实际复制时间长于测试。If you just have 2 nodes, consider a possible mitigation in case the copy takes longer than in testing. 这可以包括以下建议。This could include the following ideas.
    • 在以商定的停机时间进行迁移之前,添加临时的第 3 个 SQL Server 节点以实现 HA。Add a temporary 3rd SQL Server node for HA before the migration with agreed downtime.
    • 在 Azure 计划的维护时间之外运行迁移。Run the migration outside of Azure scheduled maintenance.
    • 确保已正确配置群集仲裁。Ensure you have configured your cluster quorum correctly.
高级步骤High-level steps

本文档并不演示完整的端到端示例,但是 附录 提供了可用来执行此操作的详细信息。This document does not demonstrate a complete end to end example, however the Appendix provides details that can be leveraged to perform this.

MinimalDowntime

  • 收集磁盘配置并删除节点(不删除附加的 VHD)。Gather disk configuration, and remove the node (do not delete attached VHDs).
  • 创建高级存储帐户并从标准存储帐户复制 VHDCreate a Premium Storage account and copy VHDs from the Standard Storage account
  • 创建新的云服务并在该云服务中重新部署 SQL2 VM。Create new cloud service and redeploy the SQL2 VM in that cloud service. 使用复制的原始操作系统 VHD 创建 VM 并附加复制的 VHD。Create the VM using the copied original OS VHD and attaching the copied VHDs.
  • 配置 ILB/ELB 并添加终结点。Configure ILB / ELB and add Endpoints.
  • 通过以下任一方法更新侦听器:Update Listener by either:
    • 使 AlwaysOn 组脱机,并使用新的 ILB/ELB IP 地址更新 AlwaysOn 侦听器。Taking the Always On Group offline and updating the Always On Listener with new ILB / ELB IP address.
    • 或者通过 PowerShell 将新云服务 ILB/ELB 的 IP 地址资源添加到 Windows 群集。Or adding the IP address resource of new Cloud Service ILB/ELB through PowerShell into Windows clustering. 然后,将 IP 地址资源的可能所有者设置为已迁移节点 SQL2,并在网络名称中将此项设置为 OR 依赖关系。Then set the Possible owners of the IP Address resource to the migrated node, SQL2, and set this as OR dependency in the Network Name. 请参阅 附录的“在同一子网中添加 IP 地址资源”部分。See the 'Adding IP Address Resource on Same Subnet' section of the Appendix.
  • 检查客户端的 DNS 配置/传播。Check DNS configuration/propagation to the clients.
  • 迁移 SQL1 VM,并完成步骤 2 - 4。Migrate SQL1 VM, and go through steps 2 - 4.
  • 如果使用步骤 5ii,则将 SQL1 添加为已添加 IP 地址资源的可能所有者If using steps 5ii, then add SQL1 as a Possible Owner for the added IP Address Resource
  • 测试故障转移。Test failovers.

2.利用现有的辅助副本:多站点2. Utilize existing secondary replica(s): Multi-Site

如果在多个 Azure 数据中心 (DC) 中有节点,或者拥有混合环境,则可以在此环境中使用 Always On 配置以最大程度减少停机时间。If you have nodes in more than one Azure datacenter (DC) or if you have a hybrid environment, then you can use an Always On configuration in this environment to minimize downtime.

此方法的目的是将本地或辅助 Azure DC 的“AlwaysOn 同步”更改为“同步”,并故障转移到该 SQL Server。The approach is to change the Always On synchronization to Synchronous for the on-premises or secondary Azure DC, and then failover over to that SQL Server. 然后将 VHD 复制到一个高级存储帐户,并将计算机重新部署到新的云服务中。Then copy the VHDs to a Premium Storage account, and redeploy the machine into a new cloud service. 更新侦听器,并故障恢复。Update the listener, and then fail back.

停机时间点Points of downtime

停机时间包含故障转移到备用 DC 并返回的时间。The downtime consists of the time to failover to the alternative DC and back. 它还取决于客户端/DNS 配置,客户端重新连接可能会延迟。It also depends on your client/DNS configuration and your client reconnection may be delayed. 请考虑以下混合 AlwaysOn 配置示例:Consider the following example of a hybrid Always On configuration:

MultiSite1

优点Advantages
  • 可以利用现有基础结构。You can utilize existing infrastructure.
  • 可以选择先在 DR Azure DC 上预升级 Azure 存储。You have the option to pre-upgrade the Azure storage on the DR Azure DC first.
  • 可以重新配置 DR Azure DC 存储。The DR Azure DC storage can be reconfigured.
  • 在迁移期间,至少会进行两次故障转移,不包括测试故障转移。There is a minimum of two failovers during migration, excluding test failovers.
  • 不需要使用备份和还原移动 SQL Server 数据。You do not need to move SQL Server data with backup and restore.
缺点Disadvantages
  • 根据客户端对 SQL Server 的访问权限,当 SQL Server 在应用程序的备用 DC 中运行时,延迟时间可能会增加。Depending on client access to SQL Server, there might be increased latency when SQL Server is running in an alternative DC to the application.
  • 将 VHD 复制到高级存储的时间可能会很长。The copy time of VHDs to Premium storage could be long. 这可能会影响是否要在可用性组中保留节点的决策。This might affect your decision on whether to keep the node in the Availability Group. 请在确定何时需要在迁移期间运行日志密集型工作负荷时考虑这一点,因为主节点必须将未复制的事务保留在事务日志中。Consider this for when log intensive work loads are running during the migration is required, since the Primary node has to keep the unreplicated transactions in its transaction log. 因此,此日志可能会显著增长。Therefore this could grow significantly.
  • 此方案会使用 Azure Start-AzureStorageBlobCopy commandlet,它是异步的。This scenario would use the Azure Start-AzureStorageBlobCopy commandlet, which is asynchronous. 完成后没有 SLA。There is no SLA on completion. 复制所用的时间不同,而这取决于在队列中的等待情况,还取决于要传输的数据量。The time of the copies varies, while this depends on wait in queue, it also depend on the amount of data to transfer. 因此,在第 2 个数据中心中只有一个节点,应该采取缓解措施,以防实际复制时间长于测试。Therefore you just have one node in your 2nd data center, you should take mitigation steps in case the copy takes longer than in testing. 这些迁移步骤包括以下方面:These mitigation steps include the following ideas:
    • 在以商定的停机时间进行迁移之前,添加临时的第 2 个 SQL 节点以实现 HA。Add a temporary 2nd SQL node for HA before the migration with agreed downtime.
    • 在 Azure 计划的维护时间之外运行迁移。Run the migration outside of Azure scheduled maintenance.
    • 确保已正确配置群集仲裁。Ensure you have configured your cluster quorum correctly.

此方案假定已记录安装,并知道存储如何映射以便对最佳磁盘缓存设置进行更改。This scenario assumes that you have documented your install and know how the storage is mapped in order to make changes for optimal disk cache settings.

高级步骤High-level steps

Multisite2

  • 将本地/备用 Azure DC 设为主 SQL Server,并将设为其他自动故障转移伙伴 (AFP)。Make the on-premises / alternate Azure DC the SQL Server Primary, and make it the other Auto Failover Partner (AFP).
  • 从 SQL2 收集磁盘配置信息并删除该节点(不删除附加的 VHD)。Gather disk configuration information from SQL2, and remove the node (do not delete attached VHDs).
  • 创建高级存储帐户并从标准存储帐户复制 VHD。Create a Premium Storage account and copy VHDs from the Standard Storage account.
  • 创建新的云服务,并使用其附加高级存储磁盘创建 SQL2 VM。Create a new cloud service and create the SQL2 VM with its Premiums Storage disks attached.
  • 配置 ILB/ELB 并添加终结点。Configure ILB / ELB and add Endpoints.
  • 使用新的 ILB/ELB IP 地址更新 AlwaysOn 侦听器并测试故障转移。Update the Always On Listener with new ILB / ELB IP address and test failover.
  • 检查 DNS 配置。Check the DNS configuration.
  • 将 AFP 更改为 SQL2,并迁移 SQL1 并完成步骤 2 - 5。Change the AFP to SQL2, and then migrate SQL1 and go through steps 2 - 5.
  • 测试故障转移。Test failovers.
  • 将 AFP 切换回 SQL1 和 SQL2Switch the AFP back to SQL1 and SQL2

附录:将多站点 Always On 群集迁移到高级存储Appendix: Migrating a Multisite Always On Cluster to Premium Storage

本文的剩余部分介绍了一个将多站点 AlwaysOn 群集转换为高级存储的详细示例。The remainder of this article provides a detailed example of converting a multi-site Always On cluster to Premium storage. 它还将侦听器从使用外部负载均衡器 (ELB) 转换为使用内部负载均衡器 (ILB)。It also converts the Listener from using an external load balancer (ELB) to an internal load balancer (ILB).

环境Environment

  • Windows 2k12/SQL 2k12Windows 2k12 / SQL 2k12
  • SP 上 1 个 DB 文件1 DB Files on SP
  • 每个节点 2 个存储池2 x Storage Pools per Node

Appendix1

VM:VM:

本例中,将展示如何从 ELB 迁移到 ILB。In this example, we are going to demonstrate moving from an ELB to ILB. 在 ILB 之前推出的是 ELB,因此本例展示如何在迁移期间切换到 ILB。ELB was available before ILB, so this shows how to switch to ILB during the migration.

Appendix2

预先步骤:连接到订阅Pre Steps: Connect to Subscription

Add-AzureAccount -Environment AzureChinaCloud

#Set up subscription
Get-AzureSubscription

步骤 1:创建新的存储帐户和云服务Step 1: Create New Storage Account and Cloud Service

$mysubscription = "DansSubscription"
$location = "China North"

#Storage accounts
#current storage account where the vm to migrate resides
$origstorageaccountname = "danstdams"

#Create Premium Storage account
$newxiostorageaccountname = "danspremsams"
New-AzureStorageAccount -StorageAccountName $newxiostorageaccountname -Location $location -Type "Premium_LRS"  

#Generate storage keys for later
$originalstorage =  Get-AzureStorageKey -StorageAccountName $origstorageaccountname
$xiostorage = Get-AzureStorageKey -StorageAccountName $newxiostorageaccountname

#Generate storage acc contexts
$origContext = New-AzureStorageContext -Environment AzureChinaCloud  -StorageAccountName $origstorageaccountname -StorageAccountKey $originalstorage.Primary
$xioContext = New-AzureStorageContext -Environment AzureChinaCloud  -StorageAccountName $newxiostorageaccountname -StorageAccountKey $xiostorage.Primary  

#Set up subscription and default storage account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount $origstorageaccountname
Select-AzureSubscription -SubscriptionName $mysubscription -Current

#CREATE NEW CLOUD SVC
$vnet = "dansvnetwesteur"

##Existing cloud service
$sourceSvc="dansolSrcAms"

##Create new cloud service
$destcloudsvc = "danNewSvcAms"
New-AzureService $destcloudsvc -Location $location

步骤 2:在资源上增加允许的故障 <可选>Step 2: Increase the permitted failures on resources <Optional>

在 AlwaysOn 可用性组中包含的某些资源上,限定了在群集服务尝试重启资源组的固定时间内可出现的失败数。On certain resources that belong to your Always On Availability Group there are limits on how many failures that can occur in a period, where the cluster service attempts to restart the resource group. 在执行此过程时,建议增加此限制,因为如果未手动故障转移或通过关闭计算机来触发故障转移,则可能会接近此限制。It is recommended you increase this whilst you are walking through this procedure, since if you don't manually failover and trigger failovers by shutting down machines you can get close to this limit.

最好使允许的故障数加倍,为此,请在故障转移群集管理器中转到 AlwaysOn 资源组的属性:It would be prudent to double the failure allowance, to do this in Failover Cluster Manager, go to the Properties of the Always On resource group:

Appendix3

将最大故障数更改为 6。Change the Maximum Failures to 6.

步骤 3:为群集组添加 IP 地址资源 <可选>Step 3: Addition IP Address resource for Cluster Group <Optional>

如果群集组只有一个 IP 地址,而此地址分配给了云子网,则请注意,如果意外地使此玩过上云端的所有群集脱机,群集 IP 资源和群集网络名称将无法再联机。If you have only one IP address for the Cluster Group and this is aligned to the cloud subnet, beware, if you accidentally take offline all cluster nodes in the cloud on that network then the Cluster IP resource and Cluster Network Name are not be able to come online. 此情况下,这会阻止更新到其他群集资源。In this situation, it prevents updates to other cluster resources.

步骤 4:DNS 配置Step 4: DNS configuration

转移是否顺畅取决于如何利用和更新 DNS。Implementing a smooth transition depends on how DNS is being utilized and updated. 安装 AlwaysOn 时,会创建一个 Windows 群集资源组;如果打开群集资源管理器,会看到最低程度时具有三个资源,而文档所引用的两个资源为:When Always On is installed, it creates a Windows Cluster Resource group, if you open Failover Cluster Manager, you see that at a minimum it has three resources, the two that the document refers to are:

  • 虚拟网络名称 (VNN) - 想要通过 AlwaysOn 连接到 SQL Server 时客户端连接到的 DNS 名称。Virtual Network Name (VNN) - the DNS name that clients connect to when wanting to connect to SQL Servers via Always On.
  • IP 地址资源 - 与 VNN 关联的 IP 地址,可以有多个 IP 地址,且在多站点配置中,每个站点/子网均具有一个 IP 地址。IP Address Resource - the IP address that associated with the VNN, you can have more than one, and in a multisite configuration you have an IP address per site/subnet.

连接到 SQL Server 时,SQL Server 客户端驱动程序会检索与侦听器关联的 DNS 记录,并尝试连接到每个关联到 AlwaysOn 的 IP 地址。When connecting to SQL Server, the SQL Server Client driver retrieves the DNS records associated with the listener and tries to connect to each Always On associated IP address. 接下来,将讨论会影响此进程的一些因素。Next, we discuss some factors that can influence this.

与侦听器名称关联的并发 DNS 记录数取决于关联的 IP 地址数,还取决于 AlwaysON VNN 资源的故障转移群集的“RegisterAllIpProviders”设置。The number of concurrent DNS records that are associated with the listener name depends not only on the number of IP addresses associated, but the 'RegisterAllIpProviders'setting in Failover Clustering for the Always ON VNN resource.

在 Azure 中部署 AlwaysOn 时,可使用不同的步骤创建侦听器和 IP 地址,必须手动将“RegisterAllIpProviders”配置为 1,这与本地 Always On 部署不同,后者已设置为 1。When you deploy Always On in Azure there are different steps to create the Listener and IP Addresses, you have to manually configure the 'RegisterAllIpProviders' to 1, this is different to an on-premises Always On deployment where it is already set to 1.

如果“RegisterAllIpProviders”为 0,则与侦听器关联的 DNS 中仅显示一条 DNS 记录:If 'RegisterAllIpProviders' is 0, then you only see one DNS record in DNS associated with the Listener:

Appendix4

如果“RegisterAllIpProviders”为 1:If 'RegisterAllIpProviders' is 1:

Appendix5

以下代码会转储 VNN 设置并对其进行设置。The code below dumps out the VNN settings and sets it for you. 需要使 VNN 脱机,再将其还原到联机状态,才能使更改生效。For the change to take effect, you need to take the VNN offline and turn it back online. 这会使侦听器脱机,进而导致客户端连接中断。This takes the Listener offline causing client connectivity disruption.

##Always On Listener Name
$ListenerName = "Mylistener"
##Get AlwaysOn Network Name Settings
Get-ClusterResource $ListenerName| Get-ClusterParameter
##Set RegisterAllProvidersIP
Get-ClusterResource $ListenerName| Set-ClusterParameter RegisterAllProvidersIP  1

在之后的迁移步骤中,需要使用引用负载均衡器的更新后的 IP 地址来更新 AlwaysOn 侦听器,此操作涉及到删除和添加 IP 地址资源。In a later migration step, you need to update the Always On listener with an updated IP address that references a load balancer, this involves an IP Address resource removal and addition. 更新 IP 之后,你需要确保已在 DNS 区域中更新新的 IP 地址并且客户端将更新其本地 DNS 缓存。After the IP update, you need to ensure the new IP address has been updated in DNS Zone and that the clients are updating their local DNS cache.

如果你的客户端驻留在不同的网络段中且引用不同的 DNS 服务器,则需要考虑到迁移期间 DNS 区域复制发生的情况,因为侦听器的任意新 IP 地址的区域复制时间都会制约应用程序连接时间(可能还有其他制约情况)。If your clients reside in a different network segment and reference a different DNS server, you need to consider what happens about DNS Zone Transfer during the migration, as the application reconnect time is constrained by at least the Zone Transfer Time of any new IP addresses for the listener. 如果在此处受到时间约束,则应与 Windows 团队讨论并测试强制增量区域传送,同时还应将 DNS 主机记录设为较小的生存时间 (TTL),以使客户端更新。If you are under time constraint here, you should discuss and test forcing an incremental zone transfer with your Windows teams, and also put the DNS host record to a lower Time To Live (TTL), so the clients update. 有关详细信息,请参阅增量区域传送Start-DnsServerZoneTransferFor more information, see Incremental Zone Transfers and Start-DnsServerZoneTransfer.

与 Azure AlwaysOn 侦听器关联的 DNS 记录的 TTL 默认为 1200 秒。By default the TTL for DNS Record that is associated with the Listener in Always On in Azure is 1200 seconds. 如果在迁移期间受到时间约束,你可能希望减少此时间,以确保客户端使用侦听器更新后的 IP 地址更新其 DNS。You may wish to reduce this if you are under time constraint during your migration to ensure the clients update their DNS with the updated IP address for the listener. 可以通过转储 VNN 的配置来查看并修改该配置:You can see and modify the configuration by dumping out the configuration of the VNN:

$AGName = "myProductionAG"
$ListenerName = "Mylistener"
#Look at HostRecordTTL
Get-ClusterResource $ListenerName| Get-ClusterParameter

#Set HostRecordTTL Examples
Get-ClusterResource $ListenerName| Set-ClusterParameter -Name "HostRecordTTL" 120

Note

“HostRecordTTL”越低,DNS 流量越大。The lower the 'HostRecordTTL', a higher amount of DNS traffic occurs.

客户端应用程序设置Client application settings

如果 SQL 客户端应用程序支持 .NET 4.5 SQLClient,则可使用“MULTISUBNETFAILOVER=TRUE”关键字。If your SQL client application supports the .NET 4.5 SQLClient, then you can use 'MULTISUBNETFAILOVER=TRUE' keyword. 必须使用此关键字,因为它可加快故障转移期间到 SQL AlwaysOn 可用性组的连接速度。This keyword should be applied, because it allows for faster connection to SQL Always On Availability Group during failover. 它可在故障转移期间枚举与 AlwaysOn 侦听器并行关联的所有 IP 地址,并执行更积极、更快的 TCP 连接重试。It enumerates through all IP addresses associated with the Always On listener in parallel, and performs a more aggressive TCP connection retry speed during a failover.

有关先前设置的详细信息,请参阅MultiSubnetFailover 关键字及关联的功能For more information about the previous settings, see MultiSubnetFailover Keyword and Associated Features. 另请参阅 SqlClient 对高可用性、灾难恢复的支持Also see SqlClient Support for High Availability, Disaster Recovery.

步骤 5:群集仲裁设置Step 5: Cluster quorum settings

由于你计划一次至少关闭一个 SQL Server,因此必须修改群集仲裁设置,且如果使用带两个节点的文件共享见证 (FSW),也必须设置仲裁来实现节点多数原则和进行动态投票,这样即可使单个节点保持运行。As you are going to be taking out at least one SQL Server down at a time, you should modify the cluster quorum setting, if using File Share Witness (FSW) with two nodes, you should set the quorum to allow node majority and utilize dynamic voting, allowing for a single node to remain standing.

Set-ClusterQuorum -NodeMajority  

若要深入了解如何管理和配置群集仲裁,请参阅在 Windows Server 2012 故障转移群集中配置和管理仲裁For more information on managing and configuring the cluster quorum, see Configure and Manage the Quorum in a Windows Server 2012 Failover Cluster.

步骤 6:提取现有终结点和 ACLStep 6: Extract Existing Endpoints and ACLs

#GET Endpoint info
Get-AzureVM -ServiceName $destcloudsvc -Name $vmNameToMigrate | Get-AzureEndpoint
#GET ACL Rules for Each EP, this example is for the Always On Endpoint
Get-AzureVM -ServiceName $destcloudsvc -Name $vmNameToMigrate | Get-AzureAclConfig -EndpointName "myAOEndPoint-LB"  

将此文本保存到文件中。Save this text to a file.

步骤 7:更改故障转移伙伴和复制模式Step 7: Change Failover Partners and Replication Modes

如果使用两个以上的 SQL Server,则应将另一个 DC 或本地中的另一个辅助副本的故障转移更改为“同步”,并将其设为“自动故障转移伙伴”(AFP),这样便可以在进行更改的同时保持高可用性。If you have more than two SQL Servers, you should change the failover of another secondary in another DC or on-premises to 'Synchronous' and make it an Automatic Failover Partner (AFP), this is so you maintain HA whilst you are making changes. 可以通过修改 TSQL 来执行此操作(虽然 SSMS 也可以):You can do this through TSQL of modify though SSMS:

Appendix6

步骤 8:从云服务中删除辅助 VMStep 8: Remove Secondary VM from cloud service

必须先计划迁移云辅助节点。You should be planning to migrate a cloud secondary node first. 如果此节点当前为主节点,则必须手动进行故障转移。If this node is currently primary, you should initiate a manual failover.

$vmNameToMigrate="dansqlams2"

#Check machine status
Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate

#Shutdown secondary VM
Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | stop-AzureVM

#Extract disk configuration

##Building Existing Data Disk Configuration
$file = "C:\Azure Storage Testing\mydiskconfig_$vmNameToMigrate.csv"
$datadisks = @(Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | Get-AzureDataDisk )
Add-Content $file "lun, vhdname, hostcaching, disklabel, diskName"
foreach ($disk in $datadisks)
{
    $vhdname = $disk.MediaLink.AbsolutePath -creplace  "/vhds/"
    $disk.Lun, , $disk.HostCaching, $vhdname, $disk.DiskLabel,$disks.DiskName
    # Write-Host "copying disk $disk"
    $adddisk = "{0},{1},{2},{3},{4}" -f $disk.Lun,$vhdname, $disk.HostCaching, $disk.DiskLabel, $disk.DiskName
    $adddisk | add-content -path $file
}

#Get OS Disk
$osdisks = Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | Get-AzureOSDisk ## | select -ExpandProperty MediaLink
$osvhdname = $osdisks.MediaLink.AbsolutePath -creplace  "/vhds/"
$osdisks.OS, $osdisks.HostCaching, $osvhdname, $osdisks.DiskLabel, $osdisks.DiskName
$addosdisk = "{0},{1},{2},{3},{4}" -f $osdisks.OS,$osvhdname, $osdisks.HostCaching, $osdisks.Disklabel , $osdisks.DiskName
$addosdisk | add-content -path $file

#Import disk config
$diskobjects  = Import-CSV $file

#Check disk config, make sure below returns the disks associated with the VM
$diskobjects

#Identify OS Disk
$osdiskimport = $diskobjects | where {$_.lun -eq "Windows"}
$osdiskforbuild = $osdiskimport.diskName

#Check machibe is off
Get-AzureVM -ServiceName $sourceSvc -Name  $vmNameToMigrate

#Drop machine and rebuild to new cls
Remove-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate

步骤 9:更改 CSV 文件中的磁盘缓存设置并保存Step 9: Change disk caching settings in CSV file and save

对于数据卷,必须将这些项设置为“只读”。For data volumes, these should be set to READONLY.

对于 TLOG 卷,必须将其设置为“无”。For TLOG volumes, these should be set to NONE.

Appendix7

步骤 10:复制 VHDStep 10: Copy VHDS

#Ensure you have created the container for these:
$containerName = 'vhds'

#Create container
New-AzureStorageContainer -Name $containerName -Context $xioContext

####DISK COPYING####
#Get disks from csv, get settings for each VHDs and copy to Premium Storage accoun
ForEach ($disk in $diskobjects)
{
   $lun = $disk.Lun
   $vhdname = $disk.vhdname
   $cacheoption = $disk.HostCaching
   $disklabel = $disk.DiskLabel
   $diskName = $disk.DiskName
   Write-Host "Copying Disk Lun $lun, Label : $disklabel, VHD : $vhdname has cache setting : $cacheoption"

   #Start async copy
   Start-AzureStorageBlobCopy -srcUri "https://$origstorageaccountname.blob.core.chinacloudapi.cn/vhds/$vhdname" `
    -SrcContext $origContext `
    -DestContainer $containerName `
    -DestBlob $vhdname `
    -DestContext $xioContext
}

可以检查高级存储帐户的 VHD 的复制状态:You can check the copy status of the VHDs to the Premium Storage account:

ForEach ($disk in $diskobjects)
{
   $lun = $disk.Lun
   $vhdname = $disk.vhdname
   $cacheoption = $disk.HostCaching
   $disklabel = $disk.DiskLabel
   $diskName = $disk.DiskName

   $copystate = Get-AzureStorageBlobCopyState -Blob $vhdname -Container $containerName -Context $xioContext
   Write-Host "Copying Disk Lun $lun, Label : $disklabel, VHD : $vhdname, STATUS = " $copystate.Status
}

Appendix8

等到所有状态都记录为成功。Wait until all these are recorded as success.

如需单个 blob 的信息:For information for individual blobs:

Get-AzureStorageBlobCopyState -Blob "blobname.vhd" -Container $containerName -Context $xioContext

步骤 11:注册 OS 磁盘Step 11: Register OS disk

#Change storage account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount $newxiostorageaccountname
Select-AzureSubscription -SubscriptionName $mysubscription -Current

#Register OS disk
$osdiskimport = $diskobjects | where {$_.lun -eq "Windows"}
$osvhd = $osdiskimport.vhdname
$osdiskforbuild = $osdiskimport.diskName

#Registering OS disk, but as XIO disk
$xioDiskName = $osdiskforbuild + "xio"
Add-AzureDisk -DiskName $xioDiskName -MediaLocation  "https://$newxiostorageaccountname.blob.core.chinacloudapi.cn/vhds/$osvhd"  -Label "BootDisk" -OS "Windows"

步骤 12:将辅助副本导入到新的云服务Step 12: Import secondary into new cloud service

以下代码还使用此处添加的选项,可以导入计算机,并使用可保留的 VIP。The code below also uses the added option here you can import the machine and use the retainable VIP.

#Build VM Config
$ipaddr = "192.168.0.5"
#Remember to change to XIO
$newInstanceSize = "Standard_DS13"
$subnet = "SQL"

#Create new Availability Set
$availabilitySet = "cloudmigAVAMS"

#build machine config into object
$vmConfig = New-AzureVMConfig -Name $vmNameToMigrate -InstanceSize $newInstanceSize -DiskName $xioDiskName -AvailabilitySetName $availabilitySet  ` | Add-AzureProvisioningConfig -Windows ` | Set-AzureSubnet -SubnetNames $subnet | Set-AzureStaticVNetIP -IPAddress $ipaddr

#Reload disk config
$diskobjects  = Import-CSV $file
$datadiskimport = $diskobjects | where {$_.lun -ne "Windows"}

ForEach ( $attachdatadisk in $datadiskimport)
{
    $label = $attachdatadisk.disklabel
    $lunNo = $attachdatadisk.lun
    $hostcach = $attachdatadisk.hostcaching
    $datadiskforbuild = $attachdatadisk.diskName
    $vhdname = $attachdatadisk.vhdname

    ###Attaching disks to a VM during a deploy to a new cloud service and new storage account is different from just attaching VHDs to just a redeploy in a new cloud service
    $vmConfig | Add-AzureDataDisk -ImportFrom -MediaLocation "https://$newxiostorageaccountname.blob.core.chinacloudapi.cn/vhds/$vhdname" -LUN $lunNo -HostCaching $hostcach -DiskLabel $label

}

#Create VM
$vmConfig  | New-AzureVM -ServiceName $destcloudsvc -Location $location -VNetName $vnet ## Optional (-ReservedIPName $reservedVIPName)

步骤 13:在新的云服务上创建 ILB,添加负载均衡终结点和 ACLStep 13: Create ILB on New Cloud Svc, Add Load Balanced Endpoints and ACLs

#Check for existing ILB
GET-AzureInternalLoadBalancer -ServiceName $destcloudsvc

$ilb="sqlIntIlbDest"
$subnet = "SQL"
$IP="192.168.0.25"
Add-AzureInternalLoadBalancer -ServiceName $destcloudsvc -InternalLoadBalancerName $ilb -SubnetName $subnet -StaticVNetIPAddress $IP

#Endpoints
$epname="sqlIntEP"
$prot="tcp"
$locport=1433
$pubport=1433
Get-AzureVM -ServiceName $destcloudsvc -Name $vmNameToMigrate  | Add-AzureEndpoint -Name $epname -Protocol $prot -LocalPort $locport -PublicPort $pubport -ProbePort 59999 -ProbeIntervalInSeconds 5 -ProbeTimeoutInSeconds 11  -ProbeProtocol "TCP" -InternalLoadBalancerName $ilb -LBSetName $ilb -DirectServerReturn $true | Update-AzureVM

#SET Azure ACLs or Network Security Groups & Windows FWs

#https://msdn.microsoft.com/library/azure/dn495192.aspx

####WAIT FOR FULL AlwaysOn RESYNCRONISATION!!!!!!!!!#####

步骤 14:更新 Always OnStep 14: Update Always On

#Code to be executed on a Cluster Node
$ClusterNetworkNameAmsterdam = "Cluster Network 2" # the azure cluster subnet network name
$newCloudServiceIPAmsterdam = "192.168.0.25" # IP address of your cloud service

$AGName = "myProductionAG"
$ListenerName = "Mylistener"

Add-ClusterResource "IP Address $newCloudServiceIPAmsterdam" -ResourceType "IP Address" -Group $AGName -ErrorAction Stop |  Set-ClusterParameter -Multiple @{"Address"="$newCloudServiceIPAmsterdam";"ProbePort"="59999";SubnetMask="255.255.255.255";"Network"=$ClusterNetworkNameAmsterdam;"OverrideAddressMatch"=1;"EnableDhcp"=0} -ErrorAction Stop

#set dependency and NETBIOS, then remove old IP address

#set NETBIOS, then remove old IP address
Get-ClusterGroup $AGName | Get-ClusterResource -Name "IP Address $newCloudServiceIPAmsterdam" | Set-ClusterParameter -Name EnableNetBIOS -Value 0

#set dependency to Listener (OR Dependency) and delete previous IP Address resource that references:

#Make sure no static records in DNS

Appendix9

现在,删除旧的云服务 IP 地址。Now remove the old cloud service IP Address.

Appendix10

步骤 15:DNS 更新检查Step 15: DNS update check

现在,应检查 SQL Server 客户端网络上的 DNS 服务器,并确保群集已为添加的 IP 地址添加额外的主机记录。You should now check DNS Servers on your SQL Server client networks and make sure that clustering has added the extra host record for the added IP address. 如果这些 DNS 服务器未更新,请考虑强制进行 DNS 区域转移并确保该子网中的客户端能够解析为这两个 AlwaysOn IP 地址,如此便无需等待自动 DNS 复制。If those DNS servers have not updated, consider forcing a DNS Zone transfer and ensure that the clients in there subnet are able to resolve to both Always On IP Addresses, this is so you do not need to wait for automatic DNS replication.

步骤 16:重新配置 Always OnStep 16: Reconfigure Always On

此时,需在已迁移的辅助节点与本地节点完全同步之前稍作等待,然后切换到同步复制节点并将其设置为 AFP。At this point, you wait for the secondary that node that was migrated to fully resynchronize with the on-premises node and switch to synchronous replication node and make it the AFP.

步骤 17:迁移辅助节点Step 17: Migrate second node

$vmNameToMigrate="dansqlams1"

Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate

#Get endpoint information
$endpoint = Get-AzureVM -ServiceName $sourceSvc  -Name $vmNameToMigrate | Get-AzureEndpoint

#Shutdown VM
Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | stop-AzureVM

#Get disk config

#Building Existing Data Disk Configuration
$file = "C:\Azure Storage Testing\mydiskconfig_$vmNameToMigrate.csv"
$datadisks = @(Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | Get-AzureDataDisk )
Add-Content $file "lun, vhdname, hostcaching, disklabel, diskName"
foreach ($disk in $datadisks)
{
    $vhdname = $disk.MediaLink.AbsolutePath -creplace  "/vhds/"
    $disk.Lun, , $disk.HostCaching, $vhdname, $disk.DiskLabel,$disks.DiskName
    # Write-Host "copying disk $disk"
    $adddisk = "{0},{1},{2},{3},{4}" -f $disk.Lun,$vhdname, $disk.HostCaching, $disk.DiskLabel, $disk.DiskName
    $adddisk | add-content -path $file
}

#Get OS Disk
$osdisks = Get-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate | Get-AzureOSDisk ## | select -ExpandProperty MediaLink
$osvhdname = $osdisks.MediaLink.AbsolutePath -creplace  "/vhds/"
$osdisks.OS, $osdisks.HostCaching, $osvhdname, $osdisks.DiskLabel, $osdisks.DiskName
$addosdisk = "{0},{1},{2},{3},{4}" -f $osdisks.OS,$osvhdname, $osdisks.HostCaching, $osdisks.Disklabel , $osdisks.DiskName
$addosdisk | add-content -path $file

#Import disk config
$diskobjects  = Import-CSV $file

#Check disk configuration
$diskobjects

#Identify OS Disk
$osdiskimport = $diskobjects | where {$_.lun -eq "Windows"}
$osdiskforbuild = $osdiskimport.diskName

#Check machine is off
Get-AzureVM -ServiceName $sourceSvc -Name  $vmNameToMigrate

#Drop machine and rebuild to new cls
Remove-AzureVM -ServiceName $sourceSvc -Name $vmNameToMigrate

步骤 18:更改 CSV 文件中的磁盘缓存设置并保存Step 18: Change disk caching settings in CSV file and save

对于数据卷,应将缓存设置设为“只读”。For data volumes, the cache settings should be set to READONLY.

对于 TLOG 卷,应将缓存设置设为“无”。For TLOG volumes, the cache settings should be set to NONE.

Appendix11

步骤 19:为辅助节点创建新的独立存储帐户Step 19: Create New Independent Storage Account for Secondary Node

$newxiostorageaccountnamenode2 = "danspremsams2"
New-AzureStorageAccount -StorageAccountName $newxiostorageaccountnamenode2 -Location $location -Type "Premium_LRS"  

#Reset the storage account src if node 1 in a different storage account
$origstorageaccountname2nd = "danstdams2"

#Generate storage keys for later
$xiostoragenode2 = Get-AzureStorageKey -StorageAccountName $newxiostorageaccountnamenode2

#Generate storage acc contexts
$xioContextnode2 = New-AzureStorageContext -Environment AzureChinaCloud  -StorageAccountName $newxiostorageaccountnamenode2 -StorageAccountKey $xiostoragenode2.Primary  

#Set up subscription and default storage account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount $newxiostorageaccountnamenode2
Select-AzureSubscription -SubscriptionName $mysubscription -Current

步骤 20:复制 VHDStep 20: Copy VHDS

#Ensure you have created the container for these:
$containerName = 'vhds'

#Create container
New-AzureStorageContainer -Name $containerName -Context $xioContextnode2  

####DISK COPYING####
##get disks from csv, get settings for each VHDs and copy to Premium Storage accoun
ForEach ($disk in $diskobjects)
{
   $lun = $disk.Lun
   $vhdname = $disk.vhdname
   $cacheoption = $disk.HostCaching
   $disklabel = $disk.DiskLabel
   $diskName = $disk.DiskName
   Write-Host "Copying Disk Lun $lun, Label : $disklabel, VHD : $vhdname has cache setting : $cacheoption"

   #Start async copy
   Start-AzureStorageBlobCopy -srcUri "https://$origstorageaccountname2nd.blob.core.chinacloudapi.cn/vhds/$vhdname" `
    -SrcContext $origContext `
    -DestContainer $containerName `
    -DestBlob $vhdname `
    -DestContext $xioContextnode2
}

#Check for copy progress

#check individual blob status
Get-AzureStorageBlobCopyState -Blob "danRegSvcAms-dansqlams1-2014-07-03.vhd" -Container $containerName -Context $xioContext

可以检查所有 VHD 的 VHD 复制状态:You can check the VHD copy status for all VHDs:

ForEach ($disk in $diskobjects)
{
    $lun = $disk.Lun
    $vhdname = $disk.vhdname
    $cacheoption = $disk.HostCaching
    $disklabel = $disk.DiskLabel
    $diskName = $disk.DiskName

    $copystate = Get-AzureStorageBlobCopyState -Blob $vhdname -Container $containerName -Context $xioContextnode2
    Write-Host "Copying Disk Lun $lun, Label : $disklabel, VHD : $vhdname, STATUS = " $copystate.Status
}

Appendix12

等到所有状态都记录为成功。Wait until all these are recorded as success.

如需单个 blob 的信息:For information for individual blobs:

#Check individual blob status
Get-AzureStorageBlobCopyState -Blob "danRegSvcAms-dansqlams1-2014-07-03.vhd" -Container $containerName -Context $xioContextnode2

步骤 21:注册 OS 磁盘Step 21: Register OS disk

#change storage account to the new XIO storage account
Set-AzureSubscription -SubscriptionName $mysubscription -CurrentStorageAccount $newxiostorageaccountnamenode2
Select-AzureSubscription -SubscriptionName $mysubscription -Current

#Register OS disk
$osdiskimport = $diskobjects | where {$_.lun -eq "Windows"}
$osvhd = $osdiskimport.vhdname
$osdiskforbuild = $osdiskimport.diskName

#Registering OS disk, but as XIO disk
$xioDiskName = $osdiskforbuild + "xio"
Add-AzureDisk -DiskName $xioDiskName -MediaLocation  "https://$newxiostorageaccountnamenode2.blob.core.chinacloudapi.cn/vhds/$osvhd"  -Label "BootDisk" -OS "Windows"

#Build VM Config
$ipaddr = "192.168.0.4"
$newInstanceSize = "Standard_DS13"

#Join to existing Availability Set

#Build machine config into object
$vmConfig = New-AzureVMConfig -Name $vmNameToMigrate -InstanceSize $newInstanceSize -DiskName $xioDiskName -AvailabilitySetName $availabilitySet  ` | Add-AzureProvisioningConfig -Windows ` | Set-AzureSubnet -SubnetNames $subnet | Set-AzureStaticVNetIP -IPAddress $ipaddr

#Reload disk config
$diskobjects  = Import-CSV $file
$datadiskimport = $diskobjects | where {$_.lun -ne "Windows"}

ForEach ( $attachdatadisk in $datadiskimport)
{
    $label = $attachdatadisk.disklabel
    $lunNo = $attachdatadisk.lun
    $hostcach = $attachdatadisk.hostcaching
    $datadiskforbuild = $attachdatadisk.diskName
    $vhdname = $attachdatadisk.vhdname

    ###This is different to just a straight cloud service change
    #note if you do not have a disk label the command below will fail, populate as required.
    $vmConfig | Add-AzureDataDisk -ImportFrom -MediaLocation "https://$newxiostorageaccountnamenode2.blob.core.chinacloudapi.cn/vhds/$vhdname" -LUN $lunNo -HostCaching $hostcach -DiskLabel $label

}

#Create VM
$vmConfig  | New-AzureVM -ServiceName $destcloudsvc -Location $location -VNetName $vnet -Verbose

步骤 22:添加负载均衡终结点和 ACLStep 22: Add Load Balanced Endpoints and ACLs

#Endpoints
$epname="sqlIntEP"
$prot="tcp"
$locport=1433
$pubport=1433
Get-AzureVM -ServiceName $destcloudsvc -Name $vmNameToMigrate  | Add-AzureEndpoint -Name $epname -Protocol $prot -LocalPort $locport -PublicPort $pubport -ProbePort 59999 -ProbeIntervalInSeconds 5 -ProbeTimeoutInSeconds 11  -ProbeProtocol "TCP" -InternalLoadBalancerName $ilb -LBSetName $ilb -DirectServerReturn $true | Update-AzureVM

#STOP!!! CHECK in the Azure portal or Machine Endpoints through PowerShell that these Endpoints are created!

#SET ACLs or Azure Network Security Groups & Windows FWs

#https://msdn.microsoft.com/library/azure/dn495192.aspx

步骤 23:测试故障转移Step 23: Test failover

请在已迁移的节点与本地 AlwaysOn 节点同步之前稍作等待。Wait for the migrated node to synchronize with the on-premises Always On node. 将其置于同步复制模式中,并在同步完成前稍作等待。Place it into synchronous replication mode and wait until it is synchronized. 然后从本地故障转移到第一个已迁移的节点(即 AFP)。Then failover from on premises to the first node migrated, which is the AFP. 故障转移完成后,将最后一个已迁移的节点更改为 AFP。Once that has worked, change the last migrated node to the AFP.

应测试所有节点之间的故障转移,并运行所有混沌测试,以确保故障转移及时地正常工作。You should test failovers between all nodes and run though chaos tests to ensure failovers work as expected and in a timely manor.

步骤 24:置回群集仲裁设置/DNS TTL/故障转移伙伴/同步设置Step 24: Put back cluster quorum settings / DNS TTL / Failover Pntrs / Sync Settings

在同一子网上添加 IP 地址资源Adding IP Address Resource on Same Subnet

如果你只有两个 SQL Server,你想将它们迁移到新的云服务但希望两者位于同一子网上,可让侦听器继续保持联机,以删除原始 AlwaysOn IP 地址并添加新的 IP 地址。If you have only two SQL Servers and want to migrate them to a new cloud service, but want to keep them on the same subnet, you can avoid taking the listener offline to delete the original Always On IP Address and add the New IP Address. 如果要将 VM 迁移到其他子网,则无需执行此操作,因为还存在一个引用该子网的群集网络。If you are migrating the VMs to another subnet, you do not need to do this as there is an additional cluster network that references that subnet.

启动已迁移的辅助节点并在故障转移现有的主节点之前将其添加到新云服务的新 IP 地址资源中后,应在群集故障转移管理器执行以下步骤:Once you have brought up the migrated secondary and added in the new IP Address resource for the new cloud service before failover the existing Primary, you should take these steps within the Cluster Failover Manager:

若要添加 IP 地址,请参阅“附录”步骤 14。To add in IP Address, see the Appendix, step 14.

  1. 对于当前 IP 地址资源,将可能的所有者更改为“现有主 SQL Server”(在本例中为“dansqlams4”):For the current IP Address resource, change the possible owner to 'Existing Primary SQL Server', in the example, 'dansqlams4':

    Appendix13

  2. 对于新的 IP 地址资源,将可能的所有者更改为“迁移的辅助 SQL Server”(在本例中为“dansqlams5”):For the new IP Address resource, change the possible owner to 'Migrated secondary SQL Server', in the example, 'dansqlams5':

    Appendix14

  3. 设置了此项后便可以进行故障转移了,迁移了最后一个节点后,应编辑“可能的所有者”,以便将该节点添加为可能的所有者:Once this is set you can failover, and when the last node is migrated the Possible Owners should be edited so that node is added as a Possible Owner:

    Appendix15

其他资源Additional resources