第二章 Hyper-V向Azure迁移

上一章，我主要讲解了如何通过无代理服务器从Vmware迁移到Azure。这一章我详细讲解一下如何从Hyper-V向Azure迁移。因为通过Azure Migrate迁移，上面一章已经讲解的很清楚了，大部分内容都是通用的。所以这一次，我选择使用Site Recovery功能来进行迁移。本次迁移的HyperV服务器的部分，和利用Azure Migrate迁移是通用的，主要区别是在Azure部分的操作，大家正好可以进行比较。

首先是进入Recovery Service保管库，创建自己的Vault

这里，选择自己的订阅，资源组，设置保管库的名字，比如这里我用iteablue-migrate，最后选择区域

下一步，确定创建的设置内容，这里注意一下，默认是利用GRS冗余，至于什么是GRS，可以参考挨踢茶馆的AZ-103视频教程，学习一下具体内容。

确认之后，就可以开始部署了，Azure会显示部署的具体过程。

部署完成以后，可以进入创建好的保管库查看

这里，我们选择Site Recovery

然后选择右边的：准备基础结构，下面要配置保护目标的具体内容，这里选择本地，要复制到Azure，需要迁移，然后系统会推荐利用Azure Migrate来进行迁移，我们这里选择坚持用Site Recovery。

然后选择虚化类型，选择HyperV，由于我没有使用SCVMM，所以这里选择否，如果大家在生产环境中有用SCVMM，则选择是

下面要选择部署规划，这里提供了一个工具，叫Deployment Planner来对你的虚拟环境进行评估。如果你需要对大型环境进行迁移的话，建议下载下来，安装到虚拟环境的某一台管理服务器来进行评估，具体内容由于篇幅的原因就不多叙述。我这里选择我将稍后进行。

下一步，由于我们的HyperV环境还没有和Azure通讯，所以这选择添加HyperV站点，并填入站点名称

创建好站点以后，需要添加Hyper-V服务器

我们需要在Hyper-V服务器下载步骤3里面的安装程序和步骤4里面的密钥，我在这里演示一下Win2019服务器作为HyperV服务器的情况，如果大家用的是Hyper-V Server话，因为是全CLI界面，会麻烦很多，由于篇幅有限，我在这里不做过多叙述，有兴趣的朋友可以关注我以后专门的Hyper-V server迁移的文章。

以管理员身份运行步骤3下载的应用程序，这里我们可以根据实际情况来确定是否需要检查更新，一般来说最好是安装一下，这里测试用，就不安装了。

选择安装的位置，然后点击安装

安装好以后，点击注册

这里需要选取刚才步骤4下载好的密钥文件，然后系统会自动识别出订阅，保管库和hyperV站点名称，点击下一步

这里选择不使用代理，如果你的生产环境有代理，则需要配置代理信息

然后系统会自动和Azure联系并注册

注册好以后，我们在hyperV这一端的工作就告一段落，回到Azure Portal这里来，重新开始一下刚才的步骤1-3，可以看到这里已经识别出了添加好的Hyper-V服务器

下一步，选择订阅，部署模型（缺省是资源管理器，也不需要管其他的，新的服务都是基于资源管理器的，不理解的同学可以看一下茶馆的Az-103的视频教程），选择自己存放复制磁盘的存储账户，最后选择一个虚拟网络。

最后一步，创建和关联复制的策略，迁移其实是先复制，再利用复制好的备份磁盘和Azure的计算能力来创建一个虚拟机

创建好复制策略以后，就点击关联，系统会自动完成剩下的工作。

等看到这个界面以后，我们的基础结构的准备所需要的配置就完成了。

完成以后，我们回到Site Recovery界面，选择步骤1： 复制应用程序

第一步和刚才类似，照搬设置就行

第二步，设置目标，里面选择好订阅，资源组，部署模型，存储账户，虚拟网络和子网信息

第三步，选择需要复制的虚拟机，我们在hyperV平台刚好有4个虚拟机，这里直接全部选取。

下一步，配置虚拟机的类型和磁盘

最后，选择合适的复制策略，这是我们刚才创建好并关联的，如果你有多个复制策略，要选择适合的，至于什么是复制策略，请参考茶馆的AZ-103视频教程。

这里步骤1就全部完成了，我们可以看到通知里面显示正在启动保护

点击一个进去以后查看，具体信息如下

如果我们回到保管库，选择复制的项，则可以看到所有虚拟机的复制情况，现在是正在启用，过一会就开始了复制，并且有同步的百分比提供参考，请注意，这里会根据网络的速度和硬盘的大小来决定同步的时间，机器越多，硬盘越大，则复制的时间越长，这里的百分比就和windows提供的copy预估时间一样，非常不准确~~~

我们也可以点击单个虚拟机进去查看同步状态。在这里，我们可以看到底下有一个基础结构视图，这是Azure migrate所没有的。这个视图直观的告诉大家，Hyper-V和Azure的同步是通过Site Recovery来管理磁盘复制，这其实是一个HA高可用性的体现，Hyper-V环境可以作为Azure的DR灾难恢复的一个端点。

复制好以后的状态描述让人真的很无语，就不能找个中国人翻译么。。。

我们点击centos进去看一下，上面3个选项都已经可以使用了，类似于Azure migrate里面的测试，只是因为是Hyper-V，所以可以像我上面提到的那样，用来做故障转移。

这里我测试一下故障转移，点击进去看到可以选择恢复点和一个虚拟网络，请注意，这里的虚拟网络最好是和生产网络不同的网络，仅供测试使用。

确定以后，我们可以看到状态变成了：正在启动测试故障切换

点击状态进去查看，原来也是启动一个测试虚拟机

我们到虚拟机项目下查看，一个测试虚拟机已经创建好了

测试完以后，我们可以回到刚才的界面，选择清理测试故障转移，千万别自己手贱删除测试虚拟机，有的时候会导致这里卡住。

同样的，要给一个理由，我就直接跳过了。不过，生产环境中最好给一个理由，方便回溯。

确认无误以后，我们就可以选择故障转移了。类似于Azure Migrate，这里也建议关闭虚拟机以获得所有数据，我这里测试用就不在乎了。生产环节中请根据实际情况来决定，最好能选择在非工作时间关闭虚拟机，然后执行故障转移，不然一定会或多或少丢失一些数据。

启动故障转移以后，状态变了，下面的基础结构视图也变了，因为执行了故障转移，这就不再是Hyper-V和Azure的复制了，Azure已经不再是一个灾难备份，而是完全在Azure这边创建新的虚拟机了。

我们可以去虚拟机选项查看，可以看到一个完整的VM已经创建好了。

复制的项中的提示也变了

点击centos进去查看，状态已经变成了：故障转移已完成。

一般来说，如果你想继续保持Hyper-V和Azure的互相灾备的状态的话，可以就这样结束了，因为即便故障转移以后，Azure端的虚拟机和Hyper-V端的虚拟机还会继续相互复制。如果你不想再用Hyper-V端的虚拟机的话，可以在菜单里选择：完成迁移

完成迁移的意思是，Azure端的虚拟机将完全独立出来，不再和Hyper-V端有复制行为，是一个完全独立的个体了。这适合只保留Azure端，并且需要淘汰Hyper-V服务器的情况。

选择完成迁移以后，我们可以看到，Azure在两个位置上都禁止了复制，停止了两个虚拟机的所有联系。

我们在复制的项中也看不到完成迁移的Centos虚拟机了，它彻彻底底的变成了Azure虚拟机。

这样，整个迁移的过程就彻底完成了。其他的服务器都可以按照这个方式实现从Hyper-V迁移到Azure。这里我插一句，如果是用Site Recovery迁移Vmware虚拟机的话，基础结构视图会有所不同，也无法实现HA和DR等高级功能，这里大家要注意一下。毕竟Azure虚拟的本质就是基于Hyper-V，所以对Hyper-V有天然的亲和力。

总之，在迁移的过程中，如果发生问题，可以查看通知，里面会给出详细的解释并提供解决参考方案。解决以后，重试复制就可以了。本教程里面涉及到的各种概念，如果不熟悉的话，请参考挨踢茶馆的AZ-103培训课程，里面有详细的解析，并且全程实操，非常适合大家学习和查漏补缺。

第二章的内容就到这里，下一章，我将讲解从本地物理机复制到Azure，还有从AWS虚拟机复制到Azure的骚操作~~~~（点击查看向Azure迁移之本地物理机和AWS）