十多年前，微软宣布将Azure平台提供给广大用户。在此期间，许多公司希望利用云基础架构来解决当前的IT问题。他们中的一些人联系了我们，以获取有关在云中部署系统的建议。但是随着时间的流逝，现在企业正在考虑将诸如SAP HANA之类的资源密集型系统置于云端的可能性。反过来，我们已经实施了多个类似的项目，并准备分享这些观察结果，以确保在MS Azure云中更成功地部署SAP系统。某些观察结果不会成为发现，但我们想证明某些方法在云平台中的适用性。我们想与您分享主要的经验教训。
＃1：使用云一致优化IT架构
作为生产系统迁移的一部分，我们在测试和开发过程中面临高资源消耗的问题，这最终使我们思考了为什么我们需要大量的资源用于测试和开发环境以及如何通过生产系统优化基础结构资源的消耗。
建议的构建SAP系统的方法是基于使用SAP Quick Sizer计算器对所需容量的评估。到目前为止，SAP方法论是基于标准方法的，未考虑云技术的特殊性。我们从客户那里收到了需求，将初始数据输入到SAP估计器中，并获得了初步的格局配置。在传统基础架构的情况下，可以停在那里并继续购买设备，但是在我们的情况下，可以利用云。在云中，可以随时增加资源，因此，我们放弃了估计器中多余的资源储备，并部署了性能较低的计算机。这样可以降低成本，随着负载的增加，我们总是可以在几分钟内提高SAP虚拟机的性能。
Microsoft仅在M系列VM上提供SAP支持，在初始开发阶段就使用类似于生产环境的测试资源（在支持级别上）对我们来说似乎是多余的。
同时，E系列机器与M系列机器具有相似的特性，但是其成本要低得多。结果，我们用E系列替换了测试机，这种替换的缺点是将测试环境中系统操作的责任从提供商转移到了集成商。这就要求集成商具有SAP专业知识。
＃2：如何节省资源消耗
MS Azure使您可以在预订资源时同时预付一年或三年的费用，从而大大节省开支。
通常，在初始阶段，客户无法准确估计生产系统的启动日期，因为其开发和测试通常与业务或承包商开发人员方面的许多变量相关联。
例如，在启动一个项目时，我们计划根据客户的当前计划同时部署所有环境。通常，开发需要与业务部门进行更长的协调，这导致生产启动被推迟了几个月。
在此示例中，当使用预付款方式预订资源时，客户将损失大量资金。当然，有必要保留资源，但是在项目的后期阶段，当生产系统的大部分已稳定下来并且就资源消耗而言开发变得可预测时，这样做更为有效。通常，当预订3年的计算资源时，与现收现付方式相比，您可以节省大约70％的成本。
＃3：如何选择Azure区域
Azure具有广泛的资源托管区域。选择区域的主要标准之一是基础架构与最终用户之间的距离，这会影响系统的响应以及集成和最终用户的操作。
同样重要的第二个标准是特定区域中的服务列表。
根据地区的不同，某些服务可用。在正式发布之前，通常会以预览形式提供服务。一些地区更快地引入新技术，并尝试一种已经出现的服务。并非所有区域都提供使用全部虚拟机系列的功能。
在我们的实践中，访问速度的比较通常显示出西欧地区的优势。对于服务器和客户端位于俄罗斯欧洲部分的公司而言，这一点尤其明显。在每种特定情况下，尤其是在您的数据中心和客户位于远东地区时，检查数据中心（或客户所在的地理区域）的延迟以选择最佳的Azure区域是有意义的。
Azure Latency Test等服务使您可以主动测试数据中心网络对每个Azure区域的延迟。在我们的莫斯科办事处进行测试时，使用上述服务测量延迟的结果示例：
＃4：如何将基于地面的方法应用于云安装
在每次迁移中，我们都会问自己一个问题，即如何使用云中经典基础架构证明的传统解决方案。特别是在准备解决方案时，我们会根据供应商的建议来开发技术上正确的解决方案。 SAP HANA项目也不例外，并且还会通过各种建议和最佳实践。
在一个项目中，在解决方案的第一阶段，部署了基于Windows的Jump服务器。为了优化初始开发阶段的成本，将NFS服务器部署在同一台服务器上，以满足非生产性环境的需求，这可以满足开发人员当前的需求，并可以节省大量资源。
随着时间的流逝，环境和资源需求不断增加，NFS服务器处理了所有任务。在项目框架内，我们逐步解决了初始虚拟机资源的耗尽问题。可以在几分钟内增加MS Azure中的VM资源，但是与此同时，服务器容错性的要求也有所提高，这使我们考虑进行更大的重新配置。
为了实施，使用了Linux服务器，DRBD服务和可用性集功能，该功能解决了NFS集群节点之间的数据复制问题，并在两个集群节点之一发生故障时提高了可用性。
顺便说一句：群集解决方案实施后的几个月，NetApp文件服务已添加到Azure，这使您可以利用NetApp阵列，但需要通过即付即用模型付费。
＃5：如何自动执行VM调度
使用任何云基础架构时，分析可以使用哪些其他机制来最大程度地节省成本始终是有意义的。
在我们的案例中，系统在工作时间内进行了测试。在传统的基础架构服务器中，停机时间主要转化为增加的能源费用，而在云中，无用的服务器会消耗资金来租用容量。我们评估了测试和开发服务器上的负载图，并注意到绝大多数开发人员和测试人员在工作日的8：00至20：00使用该系统。
如果非生产系统上的负载计划是可预测的并且是周期性的，则我们尝试使用脚本来自动启动/关闭虚拟机。 Azure有几种工具：自动关闭，自动化帐户和Cloud Shell。并非所有人都适合我们。自动关闭被排除在外，因为它只能关闭VM。 Cloud Shell也没有涉及，因为它需要准备其他脚本，制定时间表以及在有冗余的情况下安全地存储所有这些内容，从而将节省的成本降至最低。
在我们的案例中，使用了更灵活的机制。 Automation Accounts以运行手册的形式提供现成的可运行的解决方案，使您可以按计划打开和关闭虚拟机。
我们为各个资源准备了图形，加载了运行手册，并在图形和资源之间形成了链接。
结果，我们进一步降低了总拥有成本。最初，这些工具没有计划实施，但已经在初步操作阶段实施。
更改时间表将在几分钟内完成。首先，形成新的时间表，然后将生成的时间表与所需资源相关联。如有必要，并且进行了大量更改，则可以使用Cloud Shell来自动执行此过程。
＃6：监控资源消耗
不幸的是，对于常规数据中心而言，运行状况监视和资源消耗通常会逐渐消失在后台，然后在Azure中不希望允许这样做。有关资源消耗历史的信息直接影响成本优化的可能性。在资源的早期保留的情况下，它可以作为架构改进的信号。
＃7：不可抗力保险
许多公司都担心将其IT系统放置在云资源上，因为担心阻塞是监管机构以前针对的。像任何其他风险一样，在设计系统时也可以考虑到这一点。在项目中，通常，我们每周执行一次系统备份从云到客户数据中心的卸载。这样可以确保在任何情况下都可以还原系统。除此之外，我们使用多云安装策略，该策略将在出现访问限制的情况下不允许访问资源。在这种情况下，替代的云提供程序将用作主云的灾难恢复站点，从而可以在发生大规模阻塞的情况下恢复系统。
第7条+个人数据处理
在我们的工作中，我们形成了一种方法，用于在包含外国云资源的系统中存储和处理个人数据。请注意，在执行此方法时应考虑到监管机构的要求。该主题涉及面很广，如果我们注意到注释中的相应内容，我们将尝试在以下文章中进行介绍。
结果
在本文中，我们回顾了在MS Azure云中托管SAP的一些实践课程。显然，该主题涉及面非常广，在迁移到云时，我们仅能涉及部分可能的优化。
您遇到了什么细微差别？如果您在评论中分享您的经验，我们将不胜感激。