Azure与你的工作负载真正匹配吗？

　　欢迎各位阅读本篇文章，Azure是微软基于云计算的操作系统，现在更名为“Microsoft Azure”，和Azure Services Platform一样，是微软“软件和服务”技术的名称。本篇文讲述了Azure与你的工作负载真正匹配吗?课课家教育平台提醒各位：本篇文章纯干货~因此大家一定要认真阅读本篇文章哦!

　　在迁移到Microsoft Azure公有云后，管理员需要从一系列的实例类型中做出选择，并且随后组合一系列支持服务——存储，扩展，缓存，数据库等——来优化工作负载性能。

　　本文综合介绍Microsoft Azure云实例，以及将工作负载映射到合适实例类型的最佳实践。

　　Azure实例类型分解

　　Microsoft目前列出了80个独特的Azure实例类型，用户可以从中选择。实例类型如下：

　　A系列：通用实例提供一致的处理器性能和普通的内存以及磁盘能力。一些A系列的实例可以使用额外的处理器核和更多的网络带宽，从而运行计算密集型任务。

　　D系列：和A系列相比，提供更强大的计算能力和磁盘性能，因为有更多的处理器核，每个核有更多内存和固态硬盘(SSD)以供临时存储。

　　给工作负载匹配合适的Azure实例类型，可以从原生计算需求开始。

　　Dv2系列：因为使用具有更新特性运行在turbo模式的处理器，相同的内存和磁盘配置下，比D系列实例的处理能力强35%。

　　DS系列，DSv2系列，Fs系列和Gs系列：着重高性能存储的角色，提供多样的处理器，内存和带宽特性，这些实例都可以为了快速，低延迟的I/O操作而使用SSD存储做VM磁盘以及缓存。

　　F系列：提供和Dv2系列相同的处理器核，但是每小时的运营费用更低。

　　G系列：提供最高的内存能力，并且运行在使用Intel Xeon E5 V3处理器的服务器上。

　　H系列：为计算密集型任务而设计，这些任务包括建模，高性能计算(HPC)集群和模拟。

　　N系列：增加了图像处理单元(GPU)的处理能力来处理要求最高的工作负载。

　　应该使用哪种Azure实例类型?

　　要为工作负载选择正确的Azure实例类型，需要从原生的计算需求出发。运行应用，需要多少处理器核，内存，磁盘存储，磁盘I/O和网络带宽?要回答这些问题，需要在本地环境对应用程序做评估，并且监控性能来检测可能的瓶颈。

　　接下来，选择一种能够满足，并且轻微超过这些预计需求的Azure实例。该实例类型还需要支持所有特别需求，比如GPU支持，计算密集或者高带宽。

　　给某个云实例匹配工作负载并不总是1:1的关系。比如，实例大小限制了可用虚拟磁盘的数量。因此，如果某个应用程序需要大量虚拟磁盘，管理员可能就不得不选择更大的Azure实例。使用Azure Diagnostics这样的工具来测试并且度量实例内部应用程序的性能，并且验证该核心度量是可接受的。如果不能接受，就在其他实例里再次尝试这种工作负载。

　　Azure上运行Windows VM指南

　　Azure实例类型，比如DS系列或者GS系列，在可接受的费用内，为绝大多数企业工作负载提供良好的性能。

　　低优先级工作负载，比如测试和开发，可以运行在更低廉的实例上，比如A系列或者D系列，但是通常需要在性能上作出妥协。另一方面，高性能实例通常不值得所花的费用，比如H系列或者N系列，除非工作负载能够从这样的投资里显著受益。

　　从实例大小开始，包括处理器核，内存，存储，磁盘I/O和网卡(NIC)数量，这些可以和本地服务器实例保持一致。一旦工作负载迁移后，就要收集性能度量指标，并且如果需要可以将工作负载移动到不同的实例上。记住每种实例对磁盘大小，I/O和NIC数量都有限制。

　　即使决定了合适的实例大小，一个实例通常不够。单个实例对于临时性的，低优先级的测试和开发实例来说足够了，但是不适合生产环境工作负载。如果应用程序，网络或者底层硬件发生故障，工作负载就不可用了。在Azure上的工作负载的部署要求安排在一个可用集里的多个VM上，也称之为集群。Azure不支持单台VM的服务级别协议。

　　当预配实例，存储和其他资源时，在最靠近工作负载用户的Azure region或者location里预配这些资源。这样做能够让延迟最小并且改进性能。

　　Azure实例能够垂直扩展，也能够水平扩展。垂直扩展意味着改变VM大小，通常是变大。这是工作负载需要更多资源时的最佳方案。水平扩展意味着向集群添加实例。当单个实例不能提供所需的计算能力或者处理流量，或者需要更多的可用性和弹性时，水平扩展是最佳方案。

　　如果可能的话，预配和管理资源同时进行。使用Azure的资源组来简化并且管理账单，然后以组为单元来监控并且管理这些资源。利用Azure的诊断能力，比如基础的健康度量，启动诊断和基础架构的诊断日志。对工作负载问题做故障排查以及改进部署来说，日志和诊断至关重要。

　　知识分享：

　　Microsoft Azure 的发展最早源于2006，由Amitabh Srivastava与Dave Culter所主导，当时云计算在市场上还没有受到关注，微软当时所需解决的问题是需要集成与提升在线服务的管理与运用能力，而提出的代号为 Red Dog 的项目，该项目要解决的是：

　　开发一个计算资源的管理工具，称为 Hypervisor，后来演变为 Hyper-V 平台以及 Azure 的虚拟机基础建设。

　　具有自主管理能力的分布式管理系统，以管理大量的计算资源，称为 Fabric Controller，目前为 Azure 基础建设服务的重要组件之一。

　　高度可用性与备援能力的分布式存储系统，此为 Azure Storage 的源头。

　　支持上述平台的开发工具。

　　经过数年的开发，Azure平台于2010年2月正式推出公开服务版 (General Availability)，当时的名称为 Azure Service Platform，包含Azure Cloud Service、Azure Storage、SQL Azure与 AppFabric 四种服务，且仅提供平台服务(PaaS) 一种。

　　2010年下半年更新管理接口为Microsoft Silverlight开发的管理接口，并新增 VM Role (虚拟机的前身)，以及 Azure Connect (Azure 虚拟网络的 VPN 连接的前身)。

　　2012 年是 Azure 发展的里程碑之一，共做了下列改变：

　　更新管理接口，采用 HTML5 技术。

　　首次发行基础建设服务(IaaS)，包含虚拟机与虚拟网络。

　　发行 Website 服务，并首次支持 .NET 以外的平台。

　　发行 Media Service 服务。

　　2014 年下半年发行 Mobile Service，提供移动应用必须的后台服务，包含数据、识别、通知以及 API 等。

　　2013~2014年加入 Hadoop 服务 (HDInsight)、Streaming Analytics (数据流分析)、数据工厂服务、事件中枢与机器学习等与大数据相关的服务，同时更新 SQL Azure 大幅提升性能。

　　2014 年微软将 Windows Azure 更名为 Microsoft Azure，以修正其市场方向，也为了要让外界不再认为 Azure 只能跑 Windows 操作系统。

　　2015 年将 Website 与 Mobile Service 合并，并新增 API App 与 Logic App 合称为 Azure App Services，并推出 Azure Redis Cache 取代原有的 Azure Shared Cache;推出 Azure Application Insights 以支持应用程序层级的监测数据能力;新增 Azure DNS 以支持 DNS 托管、Azure Search 支持搜索能力等。

　　2016 年微软推出 Azure Functions (函数服务) 以支持无服务器 (Serverless) 的应用，成为继 AWS Lambda 与 Google CloudFunction 之后的第三个具备无服务器应用程序开发能力的主流云供应商，同时也推出了 Service Fabric 以支持微服务 (Microservices) 的开发。

　　目前 Azure 上的服务与功能仍然在增加中。

　　小结：Azure的主要目标是为开发者提供一个平台，帮助开发可运行在 云服务器、 数据中心、Web和PC上的应用程序。其实大家私下还得多多自学，当然如果大家还想了解更多方面的详细内容的话呢，不妨关注课课家教育平台，在这里你肯定会有意想不到的收获的!