45.将国内版AWS的虚拟机迁移到国内版Azure(下)
接下来我需要到Azure上准备下相关的资源以及配置，首先需要创建一个存储帐户以及新建一个资源组，需要注意的复制选项需要选择RA-GRShttps://s1.运维网.com/images/blog/201804/20/9379e852ca0df9cbf9fb981fbe5a874d.png
新建一个虚拟网络，选择刚才创建的资源组zjunsenawsmigratedrg
https://s1.运维网.com/images/blog/201804/20/405b157595e365094a34684ec14681e2.png
接下来创建恢复保管库实例，选择之前创建的资源组zjunsenawsmigratedrg
https://s1.运维网.com/images/blog/201804/20/8995cb43266d7e47c9c39ef5c7832803.png
接下来我们需要再到AWS准备一个单独的EC2实例，以便用作 Site Recovery 配置服务器。此实例必须运行 Windows Server 2012 R2，且创建选择映像时必须是英文版的
https://s1.运维网.com/images/blog/201804/20/7d61d11230f4df39cead5909ace13515.png
如果您选择中文版后期添加语言包来修改成英文版，哪怕您修改控制面板里“区域”里的把“格式、位置、管理”全部改成英语（美国）都是不行的，安装Microsoft Azure Site Recovery Unified Setup安装程序会报如下错误
https://s1.运维网.com/images/blog/201804/20/07fa57d3248cc624180d08f6a187ada0.png
为什么会这样呢？用WMI查询下系统语言可以看到就算我把中文版加了英文语言包以后，哪怕把系统完全改成英文但WMI里查询到的首选还是zh-cn，所以导致了这个错误，除非能把en-us改成首选（我是不知道怎么改，谁知道的话教教我）
$OSInfo = Get-WmiObject -Class Win32_OperatingSystem
$languagePacks = $OSInfo.MUILanguages
$languagePacks
https://s1.运维网.com/images/blog/201804/20/b9bd658e180160579e1c8f66426dac6f.png
配置服务器的最低要求:下表列出了配置服务器的最低硬件、软件和网络要求
https://s1.运维网.com/images/blog/201804/20/6ca6994bcfcf8088d766a396071989c6.png
配置服务器的大小要求取决于潜在的数据更改率，使用此表作为参考
https://s1.运维网.com/images/blog/201804/20/bfb60bd43902111f0f4127ed41be6fd5.png
在AWS创建这台机器的过程我就不再缀诉，可以参考之前的步骤来创建，创建时这里我选择和之前的AWSWEB虚拟机在同一个网络和子网资源里（简单来说就是Azure是通过配置服务器来复制AWS上的业务虚拟机到Azure上的，配置服务器起到了中间桥梁的作用）
https://s1.运维网.com/images/blog/201804/20/5b58605c37d6e59e1342f00cdd04d247.png
这里我创建了一台AWS2AZURE-SR
https://s1.运维网.com/images/blog/201804/20/e2acef9f8c1dfe9a3d579c774122cb5b.png
同样通过密钥对解密密码登陆上虚拟机重置administrator密码以及重命名计算机名称，接下来去Azure的恢复保管库zjunsenawsRS实例进行配置，首先是准备基础结构
https://s1.运维网.com/images/blog/201804/20/be053080f686495db465a91ec2317e5d.png
选择是，确定
https://s1.运维网.com/images/blog/201804/20/4e6bde097406dac753ead9f21f5a19fd.png
添加一个配置服务器，这个配置服务器就是我们再AWS上准备的AWS2AZURE-SR的实例
https://s1.运维网.com/images/blog/201804/20/29967138e1597581e1ee37088d0520fc.png
需要确认AWS的这台AWS2AZURE-SR可以访问服务URL地址，也就是可以上网，其次下载Microsoft Azure Site Recovery Unified Setup和恢复保管库该实例的密钥
https://s1.运维网.com/images/blog/201804/20/f44217cf3f0bb9663f833997e17ae3e1.png
把下载好的Microsoft Azure Site Recovery Unified Setup和恢复保管库该实例的密钥放到AWS的这台AWS2AZURE-SR虚拟机里
https://s1.运维网.com/images/blog/201804/20/855696c94f87b00e617a61f5ae024dcb.png
右键以管理员身份执行Microsoft Azure Site Recovery Unified Setup进行安装，在“开始之前”中，选择“安装配置服务器和进程服务器”，然后单击“下一步”
https://s1.运维网.com/images/blog/201804/20/8e55bac7570e8d6f61ff124df4791d8d.png
在“第三方软件许可证”中，选择“我接受第三方许可协议。”并单击“下一步”
https://s1.运维网.com/images/blog/201804/20/b127ed9781f9be60b56b17b4879feb3c.png
在“注册”中，单击“浏览”，导航到保管库注册密钥文件所在的位置，然后单击“下一步”
https://s1.运维网.com/images/blog/201804/20/37c363b3f26800653308a6394ed64c03.png
在“Internet 设置”中，选择“在不使用代理服务器的情况下连接到 Azure Site Recovery。”并 单击“下一步”
https://s1.运维网.com/images/blog/201804/20/0fd98f6d68600153102feda3eb25884f.png
在“必备项检查”页上，它会运行多次检查。完成后，单击“下一步”
https://s1.运维网.com/images/blog/201804/20/b72b997b95d8d9cfd53981981a746181.png
在“MySQL 配置”中，提供所需的密码，然后单击“下一步”
https://s1.运维网.com/images/blog/201804/20/ad95d9805395d5b058c76ed01bbbedac.png
在“环境详细信息”中，选择“否”（无需保护 VMware 计算机），然后单击“下一步”
https://s1.运维网.com/images/blog/201804/20/07beb0e5168dd87de1cce4c5e99ba525.png
在“安装位置”中，单击“下一步”接受默认值
https://s1.运维网.com/images/blog/201804/20/7ae6c2be2e20f60b4f1dd5461a0708c9.png
在“网络选择”中，单击“下一步”接受默认值
https://s1.运维网.com/images/blog/201804/20/d71f4a76a2379d05adb735fc97dd1f21.png
在“摘要”中，单击“安装”
https://s1.运维网.com/images/blog/201804/20/8ed9c752498c1509c54ada381c1ef62b.png
“安装进度”显示有关安装进度的信息
https://s1.运维网.com/images/blog/201804/20/c89b2040fdeb9c0b85c7d7e78e6db4f7.png
完成后，单击“完成”。 系统会弹出一个窗口，指示可能需要重启，请单击“确定”，点击确定后请立即打开记事本，在记事本里Ctrl+V，将密码粘贴进去并保存在安全的地方
https://s1.运维网.com/images/blog/201804/20/4d8e688b9d780d2745d1f4a0d008e135.png
此外还会弹出一个有关配置服务器连接密码的窗口，此时请重启该服务器
https://s1.运维网.com/images/blog/201804/20/1af709801960df0e53f8fb26959cdd1a.png
重启好后，接着运行桌面上的cspsconfigtool.exe，以在配置服务器上创建一个管理帐户，该账户是AWS上的业务虚拟机awsweb的管理员帐户和密码（可以使用域帐户或本地帐户。 对于 Linux VM，该帐户应是源 Linux 服务器上的root帐户），Friendly name是指迁移到Azure上的VM名称，这里我设置还是和AWS保持一样叫awsweb
https://s1.运维网.com/images/blog/201804/20/a0034d1e9efb2d45476d4b22a4d7e792.png
设置完成
https://s1.运维网.com/images/blog/201804/20/d7ff43deb3c890216f58b870d07a6239.png
因为刚才设置的采用本地administrator帐户访问AWS的业务虚拟机AWSWEB，那么需要再AWSWEB系统里进行注册表设置（对于 Windows VM，如果使用的不是域帐户，则在本地计算机上禁用远程用户访问控制（UAC）：在注册表的 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System 下，添加 DWORD 项 LocalAccountTokenFilterPolicy 并将值设为 1）（或者通过命令提示符里执行REG ADD HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System /v LocalAccountTokenFilterPolicy /t REG_DWORD /d 1）设置完记得重启该虚拟机
https://s1.运维网.com/images/blog/201804/20/4a2a61323513f5b22f5ece2971b525b1.png
接着把AWSWEB虚拟机的Windows防火墙允许如下规则
https://s1.运维网.com/images/blog/201804/20/11bfe8b3e07020188bffa79cd9aabe3c.png
https://s1.运维网.com/images/blog/201804/20/d6d5a086ad4fe3bb84dd0ba6801c6da9.png
Windows虚拟机的RDP是否开启，并且Windows防火墙是否允许所有网络类型都运行RDP的访问
https://s1.运维网.com/images/blog/201805/11/4fbeba005e25a1c4c75f33c44aa00a1f.png
如果是Linux的虚拟机需要检查Secure Shell service是否随系统自动启动，其次防火墙规则允许SSH连接
在AWS上，还需要把AWSWEB虚拟机和AWS2AZURE-SR的安全组设置入站和出站都允许相互的所有流量和所有ICMP的访问规则（不是对所有地址哦，否则会很不安全）
AWS2AZURE-SR的入站和出站规则：
https://s1.运维网.com/images/blog/201804/20/76450482bc7d366fcbae53ca5611f346.pnghttps://s1.运维网.com/images/blog/201804/20/04b50acef83eb34e048376a8b12141cf.png
AWSWEB的入站和出站规则：
https://s1.运维网.com/images/blog/201804/20/40d90693f387c2df6b4d299746847e5e.pnghttps://s1.运维网.com/images/blog/201804/20/c5544e411d57e3c652aaca7b46206fa1.png
把AWS上的配置服务器安全组入站开放9443和443端口到所有地址的访问
https://s1.运维网.com/images/blog/201804/20/77a97cb539ab832e341f12e086adaaf3.png
确定这2台之间可以相互Ping通以及相互访问默认共享就OK了
https://s1.运维网.com/images/blog/201804/20/0a61656c59d8444047ee5639584efdef.png
接着返回Azure门户，在Azure门户上就能刷新看到注册好的这台配置服务器了
https://s1.运维网.com/images/blog/201804/20/e4e0fc6abaa022198fcb3b1a07ad0bf0.png
确定
https://s1.运维网.com/images/blog/201804/20/5de72c1e3f001e52063e61114c200980.png
创建和关联一个复制策略
https://s1.运维网.com/images/blog/201804/20/2e842edcd23a1940c6349735de7c9216.png
指定好参数后确定
https://s1.运维网.com/images/blog/201804/20/30e5b49d76c467bd81d961da8ab1c47d.png
等待复制策略创建完成后确定
https://s1.运维网.com/images/blog/201804/20/50a8824936dd34423c10ee14905bbde7.png
确定
https://s1.运维网.com/images/blog/201804/20/0c44d82e915bd3c5de6557c6786bb505.png
接着就可以开始启用复制了，对需要迁移的VM启用复制，比如我这里要迁移AWSWEB，那么Site Recobvery会自动让AWS准备好的配置服务器向AWSWEB虚拟机推送安装 Mobility Service服务，还是在Azure门户上，我们继续步骤1，复制应用程序，源是本地，源位置是选择AWS上准备好的EC2配置服务器，计算机类型选择物理，进程服务器也是选择准备好的EC2配置服务器
https://s1.运维网.com/images/blog/201804/20/359560c19fa9c54e9c1eb499f4f507f4.png
在故障转移的资源组里选择我们之前准备好的资源组zjunsenawsmigratedrg，存储帐户也是之前准备好的zjunsenawsmigrated，网络选择立即对选定的计算机进行配置，故障转移后的Azure网络也是之前准备好的zjunsenaws-vNet，子网也是
https://s1.运维网.com/images/blog/201804/20/05ff47c860393019322aebc6b7b6babc.png
看看AWSWEB的虚拟机内部IP是多少
https://s1.运维网.com/images/blog/201804/20/fc52827cc0166ca4441f6f1e5895f9e3.png
接下来添加物理计算机，输入要迁移的AWS上EC2实例的名称、IP地址以及OS类型，点击确定后，AWS上的配置服务器会去发现我输入的这台EC2实例
https://s1.运维网.com/images/blog/201804/20/eeef83ab5db4e75cf5c8dacf5a9f0c01.png
发现成功
https://s1.运维网.com/images/blog/201804/20/c7418ea8a14859450d8834d82121fa3f.png
确定
https://s1.运维网.com/images/blog/201804/20/6138cd289d4d802ccaba1dcf36fe656a.png
确保复制策略是我们之前创建的复制策略，点击确定
https://s1.运维网.com/images/blog/201804/20/eb0deadb8b7e43b820c50c20d4632db3.png
启用复制
https://s1.运维网.com/images/blog/201804/20/9135f6bab28b6c86499759b59fc78dd0.png
在作业里可以看到详细的状态，点击正在运行的作业看更详细的作业流程和状态
https://s1.运维网.com/images/blog/201804/20/90d3c1e3d996de785356f894ff0784fe.png
可以看到详细的步骤
https://s1.运维网.com/images/blog/201804/20/4224637a542faf3f49b75c77e67458c3.png
当然Mobility Service也是可以手动在需要迁移的VM上安装的，这些安装包在配置服务器的C:\ProgramData\ASR\home\svsystems\pushinstallsvc\repository
从这个agent包可以看出支持了很多Linux系统的迁移，所以我这里只是写了Windows的迁移，Linux也是同理一样的推送agent，最后做故障转移即可迁移到Azure
https://s1.运维网.com/images/blog/201804/20/9c51b40710dc8c120ac665e530e34f37.png
如果是推送安装Mobility Service可以在目标机器的这个目录查看推送安装日志C:\ProgramData\ASRSetupLogs\ASRUnifiedAgentInstaller.log
https://s1.运维网.com/images/blog/201804/20/327681a482738387c320021ac44d17ec.png
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
手动安装方法如下：
安装之前需要先在配置服务器上生成密码文件：
cd %ProgramData%\ASR\home\svsystems\bin
genpassphrase.exe -v > MobSvc.passphrase
https://s1.运维网.com/images/blog/201804/20/4849ef4b7e09d8caad212a57142486ca.png
在目标计算机上通过命令行安装：
将安装程序复制到要保护的服务器上的某个本地文件夹（例如 C:\Temp）。 以管理员身份在命令提示符处运行以下命令：
cd C:\Temp
ren Microsoft-ASR_UA*Windows*release.exe MobilityServiceInstaller.exe
MobilityServiceInstaller.exe /q /x:C:\Temp\Extracted
cd C:\Temp\Extracted.
https://s1.运维网.com/images/blog/201804/20/278059744876b50de18db5e5f866cfde.png
运行以下命令安装移动服务：
UnifiedAgent.exe /Role "MS" /InstallLocation "C:\Program Files (x86)\Microsoft Azure Site Recovery" /Platform "VmWare" /skipprereqchecks /Silent
注意：当出现安装环境检查出错时，需要添加命令行参数skipprereqchecks。
https://s1.运维网.com/images/blog/201804/20/a0100eddc67e1c064876c7952080c2b1.png
将代理注册到配置服务器：
cd C:\Program Files (x86)\Microsoft Azure Site Recovery\agent
UnifiedAgentConfigurator.exe /CSEndPoint/PassphraseFilePath
或者使用向导界面进行注册
进入目录C:\Program Files (x86)\Microsoft Azure Site Recovery\agent, 直接运行UnifiedAgentConfigurator.exe. 在向导界面选择配置服务器的IP地址。在passphrase中输入导出的passphrase文件中的字符串。
https://s1.运维网.com/images/blog/201804/20/8879ab76c892bdd233f1ef570bc2d1dc.png
关于Mobility service的安装和注册问题，具体的参数解释：
1）/Role: 这个参数是说明安装的Mobility service的类型。对于物理机客户端，需要选择MS.
2）/Platform: 这个参数需要补充说明： 如果你把EC2虚拟机作为物理服务器， 需要选择Vmware。
https://s1.运维网.com/images/blog/201804/20/aeabce9938853a2792ebbe248c38fa39.png
完成注册后，此虚拟机可以作为物理机的选项在ASR中加入复制。
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
在“完成保护”作业运行之后，计算机就可以进行故障转移了。为 VM 启用复制后，可能要等 15 分钟或更长时间，更改才会生效并显示在门户中。
https://s1.运维网.com/images/blog/201804/20/c3f7f75fe2de11615ca6eb8d35308223.pnghttps://s1.运维网.com/images/blog/201804/20/d5cd566c903d7883d7136371564bf6b0.pnghttps://s1.运维网.com/images/blog/201804/20/e2c2b06bd889e0911fb795d7e60caede.png
接下来您可以运行测试故障切换（这里我不再详细演示，之前的文章有详细写测试故障转移的步骤，原理都是一样的）
在门户中运行测试故障转移：在保管库的相应页上，转到“受保护的项” > “复制的项”> 单击该 VM >“+ 测试故障切换
https://s1.运维网.com/images/blog/201804/20/d93ed3d36500a7bba3f82c65c211ba34.png
选择要用于故障切换的恢复点：
[*] 最新（最低RPO）：此选项将所有 VM 故障转移到最新的恢复点。
[*] 最新处理（低RTO）：将 VM 故障转移到由 Site Recovery 处理的最新恢复点。 将显示时间戳。 使用此选项时，无需费时处理数据，因此 RTO（恢复时间目标）会较低。
[*] 自定义：选择任何恢复点。
在“测试故障切换”中，选择 Azure VM 在故障转移之后要连接到的目标 Azure 网络。 它应该是在准备 Azure 资源部分中创建的网络。
单击“确定”开始故障转移。可以通过单击虚拟机打开其属性来跟踪进度。 也可以在保管库相应页面上的 监视和报告 > 作业 > Site Recovery 作业 中单击测试故障转移 作业。
故障转移完成后，副本 Azure VM 会显示在 Azure 门户 >“虚拟机”中。 请确保虚拟机的大小适当、已连接到正确的网络，并且正在运行。
后续您可以连接到 Azure 中复制的虚拟机进行验证数据和业务是否OK。
若要删除在测试故障转移期间创建的 Azure VM，请在恢复计划上单击“清理测试故障转移”。 在“说明”中，记录并保存与测试故障转移相关联的任何观测结果。
在某些情况下，故障转移需要大约八到十分钟的时间完成其他进程。
最后是真正迁移到Azure了：对 EC2 实例AWSWEB运行真正的故障转移，将其迁移到 Azure VM
在“受保护的项” > “复制的项”中，单击 AWS 实例（AWSWEB） >“故障转移”
https://s1.运维网.com/images/blog/201804/20/8447618ce6a3e131fa3a966ce584303e.png
在“故障转移”中，选择要故障转移到的“恢复点”，然后点击确定
https://s1.运维网.com/images/blog/201804/20/995588b117d903106dde4c2e25aeb70b.png
请勿取消正在进行的故障转移：在故障转移开始前，停止 VM 复制。 如果取消正在进行的故障转移，故障转移会停止，但 VM 将不再进行复制；当作业处于“启动故障转移”时，请在AWS上将Awsweb虚拟机关机
https://s1.运维网.com/images/blog/201804/20/4e5dbc8a8a72b2f7be878cd6adc59c8e.png
故障转移完成，Azure上的AWSWEB副本虚拟机启动
https://s1.运维网.com/images/blog/201804/20/1cf7d14ce25a8d5ef8231f355c6ee2a8.png
连接是专用IP，意思是这个虚拟机只能通过该虚拟网络下的其他机器去连接或者部署了站点到站点的***或者点到站点的***去连接这台虚拟机
https://s1.运维网.com/images/blog/201804/20/a16efe7307552b45057394ef15ba1446.png
如果想通过Internet去连接访问这台虚拟机，首先创建一个网络安全组
https://s1.运维网.com/images/blog/201804/20/dcff6bcbfb057a11772646c193d1202a.png
定义NSG名称创建
https://s1.运维网.com/images/blog/201804/20/094155ae9ac6ee3b3f1a509e60775639.png
添加2条入站规则，其中9999端口是我们的WEB服务
https://s1.运维网.com/images/blog/201804/20/a2656a2127c3f70f415ce61d4e2a39fb.png
选择AWSWEB虚拟机——网络——网卡
https://s1.运维网.com/images/blog/201804/20/76d9633ba53d55aebd5481928184460c.png
选择IP配置，点击IP配置
https://s1.运维网.com/images/blog/201804/20/16c2c571eb3843160f3501c124492c95.png
启用公共IP，新建一个公网IP，然后保存
https://s1.运维网.com/images/blog/201804/20/3e69df2a0edf19a594e6f4c672cdb49c.png
接着在网络安全组选择刚才创建的AWSWEB-NSG保存
https://s1.运维网.com/images/blog/201804/20/4b0175b47549929824024e508182e39e.png
保存后该虚拟机就有公网IP，可以通过Internet连接和访问了，数据盘也没有问题的一并迁移过来了，并且临时盘变成了E盘（Temporary Storage不能存放永久性数据）
https://s1.运维网.com/images/blog/201804/20/b453af34d44c531e395bdb0b74864978.png
并且IIS提供服务正常（IIS站点的index.html文件是放在D盘的，能提供服务且正常那么D盘数据没有问题）
https://s1.运维网.com/images/blog/201804/20/85f5079d90f0456a5d0f5ed01ab2a06c.png
最后在Azure门户中回到恢复保管库zjunsenawsrs实例，在复制的项中右键单击每个 VM（AWSWEB） >“完成迁移”。 此操作将完成迁移过程，停止 AWS VM 复制，并停止 VM 的 Site Recovery 计费。
https://s1.运维网.com/images/blog/201804/20/165f9cf118d67e800d064bbe5bb57f11.png
点击确定，整个AWS上的虚拟机迁移Azure平台上运行就完成了
https://s1.运维网.com/images/blog/201804/20/a72037d9af615bb80dff2f97c44adda4.png
等待作业完成
https://s1.运维网.com/images/blog/201804/20/8277b9225c08f65060619b3171cdea39.png
最后可以清理下Azure恢复保管库里zjunsenawsrs里的配置服务器，先解除关联
https://s1.运维网.com/images/blog/201804/20/4bc92050947b51fdfdadd7c5fc4a5901.png
再删除复制策略
https://s1.运维网.com/images/blog/201804/20/839c3d30f8f9bbbd46199f4c6434fbab.png
接着删除配置服务器
https://s1.运维网.com/images/blog/201804/20/5dc14d50ee621d58daae30b7d102bf29.png
最后就可以删除该保管库了
https://s1.运维网.com/images/blog/201804/20/00cda8656e4dfa8f77f8d9148a624faf.png
剩下的就是可以清理AWS上的没用资源了
页:
[1]