Azure 云管理实用指南（一）

原文：annas-archive.org/md5/649587b180cdb9f8a1b502e61a720011

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

欢迎来到Azure 云管理实战。本书旨在帮助你入门 Azure，并指导你踏上云计算之旅。我们将从云计算的概念开始，帮助你理解云与本地基础设施的区别。基础的基础设施即服务（IaaS）和平台即服务（PaaS）服务将会被讲解，帮助你理解如何利用云服务。接下来，我们将讨论迁移和混合云，解释如何将你的服务迁移到云端，并如何将其与本地资源结合。还将讲解身份和安全，以帮助你保障和保护云资源。最后，我们将讨论一些最佳实践和基础设施即代码（Infrastructure-as-Code），以帮助你管理和监控资源。

本书将通过真实的案例和逐步的指导，帮助你理解云计算的原则，并在你的环境中应用这些知识。

本书的目标读者

本书面向 IT 专业人员、系统工程师、管理员、DevOps 从业者以及任何想要了解 Azure 和云计算概念的人。你应该具备基本的云计算知识，并具备中级的网络和服务器管理知识。

为了充分利用本书

建议具备基本的云计算知识。为了更好地理解本地基础设施与云基础设施之间的关键差异，建议具备中级的服务器和网络管理知识。本书将使用以下工具：

• Windows Server 2016

• MS SQL Server 2016

• Hyper-V

• Active Directory

• PowerShell

• Microsoft Azure

• Azure PowerShell

• Azure CLI

下载示例代码文件

你可以从www.packt.com的账户中下载本书的示例代码文件。如果你在其他地方购买了本书，可以访问www.packt.com/support，注册后将文件直接发送到你的邮箱。

你可以通过以下步骤下载代码文件：

1. 在www.packt.com登录或注册。

2. 选择 SUPPORT 标签。

3. 点击“代码下载与勘误”。

4. 在搜索框中输入书籍名称，并按照屏幕上的指示操作。

文件下载后，请确保使用以下最新版本的工具解压或提取文件夹：

• 适用于 Windows 的 WinRAR/7-Zip

• 适用于 Mac 的 Zipeg/iZip/UnRarX

• 适用于 Linux 的 7-Zip/PeaZip

本书的代码包也托管在 GitHub 上，网址是github.com/PacktPublishing/Hands-On-Cloud-Administration-in-Azure。如果代码有更新，它会在现有的 GitHub 库中进行更新。

我们还有其他来自丰富书籍和视频目录的代码包，访问**github.com/PacktPublishing/**查看！

下载彩色图像

我们还提供了一份 PDF 文件，其中包含本书中使用的截图/图表的彩色图像。你可以在这里下载它：www.packtpub.com/sites/default/files/downloads/9781789134964_ColorImages.pdf。

使用的规范

本书中使用了一些文本规范。

CodeInText：表示文本中的代码字、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟网址、用户输入和 Twitter 用户名。这里有一个例子：“基础级 VM 适用于dev/test环境，尽管它们的性能与标准级 VM 相似，但仍有一些限制。”

一段代码的格式如下所示：

{
  "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
  "contentVersion": "1.0.0.0",
  "parameters": {
    "name": {

所有的命令行输入或输出格式如下所示：

Connect-AzureRmAccount

粗体：表示新术语、重要词汇或在屏幕上看到的词汇。例如，菜单或对话框中的词汇在文本中会以这种方式出现。这里有一个例子：“要创建一个新的 Azure 虚拟机，我们需要选择‘新建资源’，然后选择‘新建虚拟机’。”

警告或重要事项以这种方式出现。

提示和技巧以这种方式出现。

联系我们

我们始终欢迎读者的反馈。

一般反馈：如果你对本书的任何部分有疑问，请在邮件主题中提及书名，并通过customercare@packtpub.com与我们联系。

勘误表：虽然我们已尽力确保内容的准确性，但错误是难免的。如果你在本书中发现了错误，请向我们报告。请访问www.packt.com/submit-errata，选择你的书籍，点击勘误提交表单链接，并填写相关信息。

盗版：如果你在互联网上发现我们作品的任何非法复制版本，我们将非常感激你能提供该材料的地址或网站名称。请通过copyright@packt.com与我们联系，并提供该材料的链接。

如果你有兴趣成为作者：如果你在某个领域有专长，并且有兴趣撰写或为书籍做贡献，请访问authors.packtpub.com。

书评

请留下评论。一旦你阅读并使用了本书，为什么不在你购买的站点上留下评论呢？潜在读者可以看到并参考你的公正意见来做出购买决策，我们 Packt 可以了解你对我们产品的看法，作者们也能看到你对他们书籍的反馈。谢谢！

如需了解更多关于 Packt 的信息，请访问packt.com。

第一章：云计算的关键概念

云计算已经成为一个流行词，并且在 IT 领域是一个大趋势。越来越多的公司开始了他们的云计算之旅，但开始这些旅程并不容易。与传统的本地 IT 环境相比，云计算需要不同的技能和思维方式，而云管理员的需求也在不断增长。在本书中，我们将共同开启云计算之旅，帮助你掌握云管理并理解 Microsoft Azure 的服务与架构。成为 Azure 专家，帮助你的公司顺利且安全地过渡到 Azure。

我们将要讨论的主题包括以下内容：

• 云计算概念

• 云服务模型

• Azure 订阅模型

云计算概念

由于我们将使用 Microsoft Azure，因此理解云计算的关键概念，尤其是公共云的概念非常重要，因为 Azure 正是一个公共云。

在过去，我们看到过许多 IT 行业的趋势；其中一些是短期的，而另一些则持续了很长时间。许多人认为云计算是一个短期趋势，未来不会存在太久，但他们并没有真正理解云计算的概念以及这一切是如何开始的。

云计算并不是从公共云服务开始的，而是始于 1990 年代。显然，云计算的形式与今天并不相同，而是更多地作为企业内部实施的一种方式，为员工提供按需创建虚拟机的选项。在这一阶段，云计算包括一个虚拟化平台，允许员工基于预先准备好的镜像按需创建开发/测试环境。云计算的基础包括两个组成部分：虚拟化和按需资源。没有服务器虚拟化，这一切都无法实现，服务器虚拟化允许我们在单一物理服务器上创建多个虚拟机。云计算将虚拟化提升到另一个层次，超越了单纯的服务器虚拟化，但我们稍后会详细讨论。

按需获取资源的能力，正是云计算的基础。如前所述，云计算始于虚拟化平台，企业通过创建平台使员工能够按需创建虚拟机。今天，我们称之为私有云。

云计算的类型

云计算有不同的类型，而且对如何分类也有不同的看法。就我个人而言，我认为以下四种类型是最合逻辑的：

• 私有：一切都托管在内部，即我们自己的数据中心。

• 托管：介于私有云和公共云之间；服务提供商在他们的数据中心创建一个独立的环境，仅为我们提供一个专用的云。

• 公共：服务提供商提供的服务对所有人开放——公共可用。虽然仍然有租户隔离，但我们稍后会讨论这个问题。

• 混合云：私有云与公共云的结合。部分服务使用公共云，但一些服务保留在本地数据中心，并且两个或多个环境之间有直接连接。根据我的经验，这是最常见的云计算形式。我们稍后会详细解释更多内容。

在私有云中，所有资源都位于本地数据中心，无需互联网访问即可访问资源。互联网和资源是分开访问的，如下图所示。构建自己的私有云以前需要大量的投资，无论是物质上还是在知识上。首先，你需要空间，并且需要考虑其他因素，如冷却和电力。然后，你需要投资硬件，如防火墙、路由器、网络交换机、服务器和存储设备。

你需要为虚拟化层、虚拟机的操作系统许可证以及各种软件购买许可证。最终，如果没有合适的人来设置和维护系统，所有的物质投资都将付之东流。一旦一切就绪，私有云投入运行后，每隔几年就需要进行新的投资，因为你需要新版本的软件（虚拟化、操作系统及其他软件），硬件也需要替换：

托管云是从私有云到公共云过渡的第一步。由于创建和维护自己的私有云需要大规模投资，一些公司开始提供租用部分数据中心的服务，将其作为自己的私有云使用。他们专注于此类服务；由于供应商提供大宗采购折扣，他们更容易购买硬件和软件。因此，在托管云中创建环境比在私有云中创建相同的环境要便宜。

另一个问题是前期投资；使用私有云要求所有硬件和大部分软件许可证需提前支付，因此许多公司决定使用托管云，因为他们不需要进行前期投资，而是每月或每年订阅。此外，数据中心更容易提供专家来维护系统，因为一个专家可以同时照看多个客户的环境。而对于私有云，你需要网络工程师、存储专家、虚拟化专家等，这些仅仅是单一数据中心所需的人员。

在托管云的情况下，仍然需要所有工作人员，但一名专家可以为多个客户设置和维护环境，且维护成本低于私有云。请注意，访问托管云通常需要某种形式的虚拟专用网络（VPN），无论是站点到站点还是点到站点。我们通过访问位于自己网络外部并位于其他托管网络中的资源，如下图所示：

在云计算发展的下一阶段，公共云应运而生。大型服务提供商提供大量的资源供按需使用。与托管云类似，你使用的资源仍然位于本地基础设施之外，并由专门提供此类服务的服务提供商托管。

有两个关键区别。第一个区别是，在托管数据中心中，资源的数量通常是预先确定的，若需要更多资源，你必须等待新资源的配置（如果资源有可用的话）。而在公共云中，服务提供商有大量的资源可供按需请求，你可以随时获取所需资源。你可以根据需要创建任何种类和数量的资源。所需的仅是创建一个订阅并连接互联网以开始部署。这也意味着你拥有高度可扩展的环境，不受初始创建的资源大小限制。例如，如果你创建了一个有四个 CPU 和 16 GB RAM 的虚拟机，并且随着时间的推移发现该虚拟机无法处理你所需的工作负载，你不需要创建新的虚拟机；你可以使用扩展选项来更改大小。扩展的详细信息将在后面解释。反过来，如果你发现最初创建的虚拟机的大小对于你的工作负载来说过大，你不需要继续保持该大小并为不需要的部分支付费用。只需缩小即可解决问题。在这种情况下，我们通过互联网访问资源，如下图所示：

托管云与私有云的另一个区别在于定价。在托管云中，您将获得一定量的资源，并且无论这些资源以何种容量使用，您都要支付每月或每年的订阅费用，无论是 10%还是 100%。在公共云中，定价是基于使用量，支付模式是您仅支付实际使用的内容。因此，在公共云中，如果您创建了虚拟机，您将仅为实际使用的时间支付该虚拟机的费用。如果停止或删除此虚拟机，您将不再支付费用。不同云服务提供商的支付模式不同，可以按每天、每小时或每分钟使用量变化而异。由于我们将讨论微软 Azure，重要的是要提到 Azure 使用的是按分钟计费系统。因此，例如，如果您在 Microsoft Azure 中创建了一个虚拟机，并在 12 天 11 小时 13 分钟后将其删除，您将按照精确的使用时间计算支付金额。在按小时计费系统中，您将支付 12 天 12 小时的费用。在按天计费系统中，您将支付 13 天的费用。

另一个不同之处是多租户。即使公共云对所有人都可用；创建自己的订阅会生成自己的租户。通过使用特定的基础结构，这个租户会将您的资源与其他租户分离开来，而在该租户中创建的资源仅对具有访问该特定租户权限的人员可用。

总之，公共云的关键概念包括：

• 通过互联网访问

• 多租户

• 资源池化

• 按需消费

• 高度可扩展

术语云或公共云并非始于现代 IT，而是始于上世纪六十年代的资源时间共享概念。该概念在上世纪九十年代随着私有云而演变。然而，云技术在二十一世纪进一步演变和转型成为现代形式。

一切都始于亚马逊网络服务（Amazon Web Services），这是亚马逊的子公司，当他们在 2006 年发布了他们的弹性云计算（EC2）。Google 在 2008 年发布了 Google App Engine。微软在 2008 年 10 月宣布了他们的云版本，并在 2010 年 2 月公开可用。其他服务提供商纷纷效仿，如 IBM 或 Oracle 都有自己的公共云服务。就市场份额和发展速度而言，我们可以将云服务提供商中的前两名列为亚马逊网络服务和微软。

Azure 的简要历史（从 ASM 到 ARM）

我们之前提到过，微软在 2008 年宣布了他们的公共云版本，公共发布是在 2010 年。那时，微软公共云平台的正式名称是 Windows Azure。2014 年 4 月，该名称更改为 Microsoft Azure。更名的原因从未公开宣布，但有很多猜测。一个理论是，微软需要更改名称以适应开源软件的拥抱。随着微软将 Linux 虚拟机添加到其产品中，名称的命名规则变得过于混乱。最初，运行 Linux 的虚拟机在微软公共云上会被称为 Windows Azure Linux 虚拟机，而 Windows 和 Linux 放在同一个名称中确实让人困惑。将其更名为 Microsoft Azure Linux 虚拟机则更为合理。现在，这只是你可以找到的理论之一，并非官方更名原因。

不仅仅是名称在这些年中发生了变化。Azure 的第一个版本，Windows Azure，拥有完全不同的规格和类型的门户。第一个 Azure 门户可以通过地址https://manage.windowsazure.net访问，并且基于 Silverlight 技术。这个门户后来被称为经典门户，而在经典门户中创建的资源管理模型被称为Azure 标准管理（ASM）。经典门户的布局如下图所示：

在这个时候，微软意识到他们的云模型存在问题，并开始着手开发全新的架构。2014 年，微软宣布了全新的 Azure 门户。伴随着新的门户，我们还迎来了全新的管理模型，称为Azure 资源管理器（ARM）。ARM 带来了像基于角色的访问控制（RBAC）和资源组等新特性。

这些特性改变了我们在云中管理资源的方式。在 ASM 中，允许某人管理 Azure 资源的唯一方式是将其添加为 Azure 订阅的共同管理员。这个人将拥有对该订阅的完全访问和控制权。通过 RBAC，我们有了为用户提供不同权限级别的选项，例如阅读者或贡献者，而不需要给予他们对订阅的完全访问权限。

资源组更进一步。Azure 中的资源组代表逻辑容器，你可以根据选择的约定将资源放入其中。例如，你可以将单个应用程序使用的所有资源放入一个资源组中。这将允许你为用户分配访问某个资源组的权限，并且该用户只能管理或访问该特定资源组。当该用户登录到租户时，他将只能看到分配给他的资源组，即使你在同一订阅或租户下有其他资源组。你还可以使用 RABC 进一步细化权限，指定用户只能访问特定资源，但这过于细化且难以管理。基于资源组的分配被认为是最佳实践，也是管理 Azure 资源的最佳方式。

新的 Azure 门户在 2015 年 12 月之前被视为预览版本。当时，它成为了正式门户，并可以通过portal.azure.com访问。该门户在 2014 年 4 月宣布时就已上线，但当时只是预览版本。新的门户布局如下截图所示：

经典门户宣布将被淘汰，并最终在 2018 年 1 月完成退役。与 RBAC 和资源组一起，ARM 为我们带来了另一个惊人的功能——ARM 模板。ARM 模板是包含 Azure 资源信息的 JSON 文件，可用于部署新资源或编辑现有资源。

通过 ARM 模型和 ARM 模板，微软提升了云计算业务，并且真正改变了云业务。在云计算和 DevOps 领域，基础设施即代码（IaC）概念非常重要，这正是 ARM 模板的作用。你可以创建一个 ARM 模板，并多次重复使用它来创建类似的环境。通过这种方式，你自动化了基础设施部署步骤，并消除了部署和配置过程中的潜在错误。

云服务模型

说到 IaC，我们在云计算领域有很多术语。微软 Azure（以及一般云计算）的主要服务类型包括：

• 基础设施即服务（IaaS）

• 平台即服务（PaaS）

• 软件即服务（SaaS）

每种类型代表不同的服务级别以及我们对该资源的控制。为了说明每种类型及其关系，最好将它们与本地数据中心的服务进行对比。所有模型的服务层在下图中展示，我们将利用此图来解释云模型之间的关系：

在私人数据中心中，我们需要负责搭建和维护所有内容。我们需要设置网络堆栈，准备和配置存储，购买和准备硬件，安装软件，配置虚拟化主机。然后，我们需要配置镜像和服务器，部署并管理数据库。安全性在所有方面都是我们的责任——物理安全、网络安全、主机和操作系统安全，最后是所有运行在我们服务器上的应用程序软件的应用安全。

使用 IaaS，事情变得更简单了。我们不再需要准备任何东西；我们只需要注册订阅，在需要时创建一个虚拟机并开始使用。我们不再需要关心购买、准备、配置和维护这些工作，这些都由云服务提供商负责，在我们的例子中是微软的 Azure。准备镜像和部署也不再是我们的责任。安全性变得更加简单，微软负责处理物理、安全、网络和主机的安全。我们仍然在安全方面有一定责任，需要保持操作系统的最新版本、修补和确保安全。应用程序安全也是我们的责任，我们需要不断应用最佳的安全实践，以保持安全和稳定。许多人忘记了，迁移到云时，我们需要加强安全性。由于云服务提供商负责了大部分安全工作，很多人因此变得舒适和放松，忽视了自己需要负责的安全部分。当迁移到云时，我们需要记住，资源和应用程序会公开暴露，相比使用本地基础设施时，它们将面临更多的“攻击”。在本地基础设施上攻击资源通常意味着突破防火墙、入侵服务器并获取数据。而现在，许多服务可以通过互联网访问，因此你需要比以往任何时候都更加重视安全性。当谈到 IaaS 时，微软 Azure 的最佳示例就是 Azure 虚拟机。微软 Azure 中既有 Windows Server 虚拟机，也有 Linux 虚拟机。一个有趣的事实是，根据微软 2017 年 10 月发布的信息，Azure 中超过 40%的虚拟机运行的是 Linux。

PaaS 比 IaaS 更容易使用。我们所说的云服务提供商负责的内容都适用，而且更多。在这种服务中，微软负责操作系统、所需的附加软件和额外的安全层。我们仍然需要维护我们放置在其中的所有内容（取决于 PaaS 服务），而剩下的安全问题仍然是我们的问题。再次强调，人们往往很快忘记这一点，认为更多的责任转嫁到了微软。然而，IaaS 通常与 VPN 连接一起使用（无论是点对点还是站点到站点），此时端点不会公开暴露。而 PaaS 则通常通过互联网进行访问。因此，我们需要非常重视安全性，除非我们希望丢失数据或无法访问我们的服务。Azure 中 PaaS 的最佳例子是 Azure 应用服务或 Azure SQL 数据库。

最后，我们来看 SaaS。在 SaaS 中，云服务提供商几乎全程负责，处理所有事情。在这种情况下，我们拥有一个完整的解决方案，只需要创建一个订阅并为用户分配不同的访问权限。通常，SaaS 需要模块、管理员和用户。管理员模块用于管理用户和访问级别；用户模块则用于实际使用我们订阅的软件功能。安全性也是我们的责任，只有在用户级别上，我们需要确保用户意识到他们需要保护好自己的凭证，并设置足够强大的密码以防止账户被暴力破解。Microsoft Cloud 中 SaaS 的最佳例子就是 Office 365。

这个解释“披萨即服务”的图表通常用来描述云服务如何与现实生活情境相关，并帮助更好地理解云计算所提供的内容：

在这种情况下，我们可以将披萨与前面图表中解释的 IaaS、PaaS、SaaS 和本地计算的四种类型进行比较。

与本地计算相比，披萨就像是自制的选择。我们需要购买所有的配料，混合所有的材料，烘烤它，买饮料，并进行服务。将披萨与 IaaS 相比，我们会买冷冻披萨并烘烤，准备好桌子并进行服务。相比 PaaS，披萨就像是外卖——我们只需要点披萨，买饮料并提供服务。最后，SaaS 版本的披萨就像是在餐馆里用餐：我们出去点餐，一切都为我们准备好了。我们得到披萨，得到饮料，一切都有人服务。

云服务模型的优缺点

我们已经讨论了每种云服务模型为我们带来的一些特点和优势。IaaS 比 PaaS 需要更多的注册和维护。SaaS 比 PaaS 更少需要人工干预，几乎不需要维护，除了用户管理。

但这也有另一面。SaaS 要求最小的维护和管理，但也提供最少的定制。如果你需要在 SaaS 中做出更改，你可能需要联系你的云服务提供商，由他们进行更改。

在 PaaS 中，你在管理、维护和定制方面拥有更多自由。然而，这些变化通常是一个预配置的选项集，你可以从中选择，但比 SaaS 有更多的选择。

IaaS 需要最多的管理和维护，但也为你提供了最好的定制选项。因为你控制着从操作系统开始的一切（你可以选择不同的预配置镜像，甚至带入自己的操作系统镜像），所以你也有最好的控制权。你可以选择你要配置的功能，服务器上要配置的角色，甚至在虚拟机上安装任何类型的软件。

关键是你需要决定在特定情况下哪种功能最适合你。在某些情况下，最简单的解决方案可能是 SaaS，因为该产品提供了你所需要的一切。如果你需要最新的设置和功能，你可能会使用 PaaS 模型。如果你有一些遗留依赖，IaaS 将是最合适的选择。通过这种方式，你将能够配置和安装与该依赖相关的所有内容。

云的其他好处

云计算的第一个好处显而易见，正如之前所说的：它更容易维护和管理。

使用云计算时，有许多专业领域你不需要自己提供；云服务提供商会为你管理这些事情。但这也可能是一种陷阱——云资源不是自我管理的，你仍然需要 IT 专业人员来管理和维护你的资源，确保它们的健康。这些 IT 专业人员与本地数据中心的有所不同，但我们仍然需要懂得核心 IT 的人。如果你使用的是 IaaS，你仍然需要 Windows 服务器管理员（或 Linux 服务器管理员，取决于你的偏好）。如果你使用的是数据库，你仍然需要数据库管理员。IT 专业人员需要调整他们的技能和角色以适应云计算，并告别本地部署，但我们依然非常需要他们。

财务上的好处也是明显的优点之一。在本地环境中，你需要预先购买并支付所有资源费用，然后才能开始使用它们。为了建设本地数据中心，我们需要准备许多不同的硬件组件，比如防火墙、网络交换机、存储设备、服务器、不间断电源等。我们还需要为这种硬件准备基础设施，比如一个合适的服务器房间。冷却系统必须保持硬件在最佳温度，或者提供足够的电力，使我们能够运行而不至于超载电网。而当所有这些都准备好之后，我们还需要为虚拟化主机购买合适的许可，为每台虚拟机购买操作系统许可，以及为任何计划使用的额外软件（如 SQL Server、端点保护或其他所需软件）购买许可证。在本地数据中心，你需要提前购买并准备一切。这对任何组织来说可能是一次巨大的财务冲击。

而且，在初期成本之后，我们还需要支付维护费用。我们需要支付电费、冷却系统费用、所需的备用零件费用，以及雇佣人员来维护这一切。

几年之后，我们的硬件和软件就会变得过时，需要重新开始一切。在这种情况下，保持跟上并保持相关性可能会很困难。

在云端，我们无需为任何东西预先支付费用；我们使用的是按需付费的服务模型，根据实际使用的资源按分钟计费。我们不需要对任何东西进行大量投资——你可以在需要时创建资源，只使用所需的时间，使用完毕后可以删除它们。

如果我们需要一台新服务器，在云端几分钟内就能完成。无需联系不同的经销商，不需要填写订单和等待交付。在 Azure 中，你只需在需要时启动虚拟机（或其他任何资源）。一旦不再需要，删除它，它就不再收费了。这也是云和本地部署之间的一个区别：你不会被你购买的资源束缚。在本地数据中心，你需要先购买资源才能使用。一旦不再需要它们，它们并不会从你的服务器室中神奇地消失。即使它们真的消失了，你仍然花了钱。

关于我们为特定服务所需资源的评估也可能是一个大问题。假设我们正在创建一个新的网站应用程序，准备向最终用户提供。应用程序已经完成，我们需要在某个地方托管它，以便用户开始注册并使用该应用程序。这个应用程序可能需要服务器、Web 服务器和数据库服务器。我们需要为这些服务器购买新硬件和许可证。这里的问题是，我们需要购买能够处理工作负载的硬件。工作负载需要根据初始用户数量以及随时间的增长来估算，但这非常难以预估。如果我们猜测初始的工作负载，很容易在增长数据上犯错。如果我们高估了工作负载，我们会被一些我们实际上不需要但已经付费的东西困住。如果我们低估了工作负载，我们就需要非常快速地进行升级。升级可能带来两个问题：时间和金钱。

升级和解决工作负载问题可能需要一些时间。在此期间，用户可能会因为高负载导致的糟糕性能而流失。由于应用程序的性能不佳而失去用户是我们绝对希望避免的，但有时这可能是不可控的，因为获取权限（特别是在大公司中）来订购升级组件、接收它们并升级我们的服务器需要时间。升级服务器还会导致一定的停机时间，因为我们需要关闭服务器以便添加新组件。同样，这也是我们想要避免的。

关于升级的第二个问题是它们需要花费金钱。增加服务器工作负载可能需要相当大的费用。在某些情况下，如果我们需要升级内存，除非我们同时升级 CPU，否则无法做到。有时，升级 CPU 需要先升级主板才能继续。但这也取决于服务器是否可以升级，因为有时我们受限于现有设备，根本无法进行升级。在这种情况下，我们需要购买全新的硬件，而我们已经支付的旧服务器却成了不需要的负担。

云计算使这些问题变得更加简单，且更容易解决。如果我们决定使用 IaaS，我们将创建两个服务器；如果我们决定使用 PaaS（我们在这里有多个选择），则会创建两个其他服务。管理工作负载和资源数量简单、快速且容易。

如果时间证明我们高估了自己的需求，我们可以简单地缩减资源，问题就得到解决。我们不会被不需要的东西困住，也不需要为其付费。我们只需缩减服务器/资源，从那时起，我们只需为一个更小的服务器付费，而这个服务器我们实际上是需要的。

如果我们低估了需求，我们也可以像扩容一样轻松快速地增加资源量。我们不需要等待零件，也不必等到升级组件最终交付。我们只需增加资源量，问题就解决了。

云计算的另一个好处与资源数量相关。在某些情况下，我们的应用程序会出现流量峰值。流量峰值是工作负载的突然增加，可能是可预测的也可能是不可预测的。例如，如果我们在运营一个在线商店应用程序，当我们对热销商品提供折扣或者节假日期间的工作负载增加时，可以预测到流量峰值。如果我们运营的是新闻门户网站，那么由于突发新闻等原因，可能会出现不可预测的流量峰值。

无论是不可预测的还是可预测的流量峰值，我们在设置将要使用的资源时都需要考虑到它们。即使我们的资源大部分时间处于闲置和未被充分利用的状态，我们仍然需要购买能够处理这些工作负载的硬件。所以，如果我们在正常情况下有 10,000 个用户，而在流量峰值时有 1,000,000 个用户，我们就需要购买能够处理 1,000,000 用户工作负载的资源。否则，在流量峰值期间，用户将面临高负载和无法响应的应用程序，最终我们将再次失去用户。然而，购买一台 90%的时间都不被充分利用的服务器是我们希望避免的，因为这很昂贵。我们只有两种选择：要么支付费用，要么失去客户。

云计算还可以帮助我们快速处理这个问题。我们可以非常轻松、简单且快速地进行扩展和缩减。根据是否是不可预测或可预测的流量峰值，可以采取两种不同的方式。

在可预测的流量峰值情况下，我们可以根据需求增加或减少资源量。通过这样做，我们就不再为我们实际不需要的资源支付费用。在正常期间，我们只为正常工作负载付费，而在流量增加的情况下，我们为高负载付费，但仅限于高负载期间，之后我们将资源缩回到正常状态时，就不会继续支付额外费用。

在不可预测的流量峰值情况下，我们可以设置性能计数器和警报，按需触发扩容（或缩容）。例如，我们可以设置一个监控 CPU 的触发器。一旦 CPU 使用率达到 90%，我们可以安排自动扩展，并增加分配给该服务的资源量。通过这种方式，用户不会因为高负载和应用程序使用量增加而遇到任何问题。我们需要注意自动扩展，因为这会导致价格上涨，除非我们缩回资源，否则我们将支付更高的费用。缩容可以手动进行，但也可以自动完成。我们可以创建另一个触发器，当 CPU 降到 50%以下时执行缩容。这样，我们就能始终只使用实际需要和使用的资源。

理解 Azure 订阅模型

大多数云服务提供商都有类似的订阅模型，但也有一些独特的功能。我们将重点介绍 Microsoft Azure，因为这是本书中将要讨论的云服务。从现在起，我们将讨论的所有功能都是针对 Azure 的。

对于 Microsoft Azure 订阅，最高级别的管理是租户。Azure 是一个公共云，拥有遍布全球的数据中心，向所有人开放。也有一些例外，比如仅供美国政府机构使用的美国政府数据中心、仅供中国官方机构使用的中国政府数据中心，或仅供注册在德国的公司使用的德国数据中心。

作为公共云提供商，Microsoft 必须为每个用户保持数据隔离。Azure 架构用于在数据中心中隔离资源，并将其绑定到特定客户。因此，即使你共享物理资源，如网络、服务器和存储，你的服务只能由你自己访问和管理。

作为 Azure 的最高级别，租户在你创建第一个 Azure 订阅时默认创建。很多人没有意识到，如果他们使用 Office 365，那么他们已经有了一个 Azure 租户。Office 365 需要 Azure Active Directory，并且会创建你的第一个 Azure 租户。我见过很多人犯这样的错误：即使他们已经在使用 Office 365，仍然创建了一个新的 Azure 租户。问题在于，租户是与 Azure Active Directory 绑定的，创建一个新租户相当于创建一个新的 Azure Active Directory 副本。这使得 Azure Active Directory 难以管理，因为你会有两个副本，并且随着时间的推移会出现差异。

创建你的第一个 Azure 订阅时，会创建一个新的 Azure 租户和一个新的 Azure Active Directory。管理 Azure Active Directory 有多种选择，但我们将在第八章中讨论，Azure Active Directory – 云中的身份管理。创建额外的 Azure Active Directory 也会创建一个新的 Azure 租户。

在租户下的下一级是 Azure 订阅。你可以在单个租户下拥有多个 Azure 订阅。创建一个新的租户将导致一个空租户，仅包含 Azure Active Directory 而没有订阅。由于 Azure Active Directory 有多个层级，你无法在没有有效订阅的情况下将 Azure Active Directory 从基础版（即免费版）升级到其他层级。为了收集使用信息、生成账单报告，并最终开具服务使用发票，必须有一个订阅。

Azure 订阅可以用来通过财务和管理逻辑将 Azure 环境进行隔离。你可以通过多种方式来实现这一点，设计方案可以根据你的需求来定制。一个例子是，企业层面使用一个租户，并为每个部门设置一个 Azure 订阅。这样，你可以为每个订阅/部门指定不同的管理员，并跟踪每个部门的开支。另一个订阅隔离的例子是使用不同的阶段环境。我见过许多公司将他们的订阅分为开发、测试和生产环境，并为每个环境设置不同的 Azure 订阅。这种方式使你能够分别管理每个环境，但同时也能洞察你在每个环境中的花费。

隔离资源的第三部分是使用资源组。资源组是在 ARM 模型中引入的，并带来了许多好处。和订阅一样，你可以使用资源组从逻辑或计费层面来隔离资源。一个例子是为每个部门或开发/测试/生产环境设置不同的资源组。然后，你可以为每个资源组分配不同的管理员，并跟踪每个资源组的计费。请注意，计费时你仍然会在月底收到一张合并账单，并需要手动管理和跟踪开支。订阅层面的计费隔离要容易得多。如果你需要按部门/环境隔离账单，应该选择订阅隔离。

Azure 中的每个资源都可以通过层级结构进行追踪。资源属于资源组，资源组属于订阅，订阅属于租户。登录到 Azure 门户将连接到默认租户。你可以管理哪个租户是默认租户，因为一个账户可以在多个租户中存在。例如，我的公司账户默认在我的公司租户中，但我还是多个客户租户中的访客用户。默认情况下，我连接到公司租户，但可以从下拉列表中选择客户租户。我还可以更改默认租户，并选择在登录到我的 Microsoft Azure 账户时，默认登录哪个租户。

从微软 Azure 的角度来看，当你使用账户登录 Microsoft Azure 时，Azure fabric 会确定你可以访问哪个租户，并将你登录到默认租户，你可以访问该租户中的所有订阅。从那里，你可以管理属于该租户的所有订阅、资源组和资源。通过切换租户，你可以访问属于不同租户的订阅、资源组和资源。所有这些操作都由 Azure fabric 处理，以便将客户端环境进行隔离。

这种方法要好得多，因为 ARM 模型引入后，事情变得与 ASM 时代大不相同。在 ASM 中，登录后你会访问所有属于该单一帐户的订阅。Azure Active Directory 并未与特定的租户绑定，一个租户中可以有多个 Azure Active Directory。在没有资源组的情况下，很难跟踪资源，唯一的区分方式是订阅级别。

类似的层级结构也可以应用到资源管理上。你也可以为用户分配一定的资源访问权限。访问级别可以具有不同的权限，例如所有者、贡献者、读取者等。你可以构建自定义权限来实现自己的规则和政策。用户角色可以在租户、订阅、资源组或单个资源级别上分配。管理资源级别的用户访问可能很困难且费时，我不建议采用这种方法。

另一方面，租户级别的访问通常是你要避免的，因为在大多数情况下，你不希望用户对所有资源具有相同的访问权限。少数管理员可以作为例外，但这种方法一般来说是你要避免的。最佳且最常见的选项是为用户分配订阅或资源组级别的访问权限。如果你为每个订阅设置不同的部门或环境，则可以使用订阅级别的访问权限，并可以为该部门或环境指定管理员作为订阅管理员。如果你在资源组中有一个单一的应用程序或环境，可以将访问权限应用到资源组级别，并为相应的资源组指定应用程序/环境管理员。这些并不是你可以使用的唯一选项或模型，但你可以根据需要调整并创建最适合你的选项。例如，我见过一些组织将相似的资源放在一个资源组中，并根据他们在本地的角色分配管理员。所有的网络资源都会放在一个资源组中，网络工程师则被分配到网络资源组中。所有数据库都会放在另一个资源组中，并为该资源组指定数据库管理员，依此类推。

Azure 订阅类型

要创建你的第一个 Azure 订阅，你需要做几件事。第一件事是提供一个电子邮件地址，必须是 Microsoft Live 账户或 Office 365 账户。你还需要提供一个电话号码。最后，你需要提供信用卡或借记卡信息以及账单地址。即使是免费订阅，也需要信用卡信息，因为 Microsoft 会用它来验证你的身份。

当谈到 Azure 订阅时，我们可以将其分为三种不同的类型：

• 赞助订阅

• 按需付费

• 企业订阅

Azure 中有几种不同的赞助订阅：试用版、Azure Pass、MSDN 订阅、Azure 赞助等。它们的共同点是都有一定数量的免费资源可以供你使用。另一个共同点是，并非所有服务都可以在所有区域使用。例如，只有在选择北欧地区时，你才可以创建 A2 标准虚拟机，而在其他任何地区都无法创建这种虚拟机。

Azure 试用版为你提供 200 美元的服务，期限为 30 天。订阅会在以下两种情况中到期：要么你用完了 200 美元，要么在月底到期。你需要提供信用卡/借记卡信息来进行这种类型的订阅。你可以随时通过该卡或提供新卡信息将试用订阅转换为按需付费模式。必须提供信用卡信息——这仅用于身份验证，除非你明确表示希望取消消费限制并在试用期结束后开始计费，否则你不会被收取任何费用。微软希望通过这种方式防止用户利用 Azure 从事非法活动。如果没有信用卡信息，任何人都可以创建一个试用订阅，并用它来托管非法内容，期限为 30 天。在试用期结束时，这个人可能会重新创建一个试用订阅，继续使用 Azure 服务来托管非法内容。在这种情况下，微软将无法提供谁在使用 Azure 从事非法活动的信息，相关当局将追究他们的责任。

Azure Pass 是另一种试用订阅类型，提供一定额度的信用，期限为 30 天。这种订阅与微软的官方课程相关联，信用额度取决于课程的类型，每种课程的信用额度不同。这种订阅不需要信用卡，你只需要注册课程，并且可以使用课程注册信息在必要时进行身份验证。与试用订阅类似，创建的资源类型、可用资源数量以及资源可创建的区域都会受到限制。

MSDN Azure 订阅与用户的 MSDN 订阅相关联，根据信息技术和开发人员 MSDN 订阅的不同级别（例如专业版和企业版），每个级别的额度也会有所不同。所提供的信用额度是按月计算的，并且你在每个计费周期的开始时会获得一定额度（计费周期取决于激活日期，激活日期将成为计费周期的开始日期，而计费周期的结束日期为 30 天后）。

只要 MSDN 订阅仍然有效，Azure 订阅就会保持激活状态。无需提供信用卡信息，因为可以使用另一种验证方式（MSDN 支付信息）。如果你在某个月达到支出限制，你的资源将在计费周期结束之前被停用并停止服务。

若要再次使用这些服务，你需要等到新计费周期开始，或者提供信用卡信息，该信息将用于收费超出赞助金额的部分。可以选择将移除限制应用到单个月份或整个订阅。单月移除将仅在该月移除支出限制，而订阅移除则会永久移除支出限制，并在每次达到支出限制时开始计费。在单月移除限制的情况下，限制只会移除指定月份，如果下个月再次发生同样的问题，服务将会被禁用。如果限制被从订阅中移除，一旦达到支出限制，系统将自动开始对你的使用进行收费。

请注意，在每种情况下，首先会使用赞助金额，然后才会激活信用卡。MSDN 的 Azure 订阅仅限于开发和测试；绝不能用于商业或生产用途。你还会遇到资源和区域的使用限制。MSDN 订阅对于资源也有不同的定价。在这种开发/测试环境下，你不需要支付软件许可费用，且资源价格也因此更便宜。

Azure 赞助与 MSDN 订阅非常相似。它不应被用于商业或生产用途。Azure 赞助也有支出限制，但这次的限制不是按月计算，而是按年计算。计费周期是 Azure 赞助与 Azure MSDN 订阅之间的两个区别之一，其中赞助是按年计费，MSDN 是按月计费。支出限制可以移除；资源和区域也有限制。第二个区别是适用正常价格，你将为软件许可付费。

按需付费是 Azure 最简单且最常见的订阅类型。你注册 Azure 订阅，提供信用卡信息，且此信用卡将在每个月底用于计费。这个名称几乎解释了所有内容：没有任何限制，你只需为自己使用的部分付费。如果你在订阅中没有任何资源，微软将不会因仅有订阅而向你收费。如果你在订阅中有资源，只有这些资源会被收费。如果你添加了一些资源，你将额外收费。如果你删除了某些资源，你将只为仍然激活的资源付费。你的订阅没有最低或最高限制；你可以每月不花费一分钱，也可以花费数百万。

企业订阅需要签订一份合同，合同中确定了你在 Azure 资源上的最低支出金额。你承诺每年花费一定金额，便可以享受资源价格的折扣。费用按月结算，基于合同中的金额。任何超过合同规定的最低金额部分，将在年底单独计费。使用企业订阅时，还可以选择将自己的许可证带入 Azure，从而允许你重用已有的本地资源许可证。

此外，还有预留实例折扣。这可以应用于按需计费和企业订阅。你需要确定在接下来一段时间内将使用的虚拟机数量和类型。时间段可以是 1 年或 2 年。一年期为你提供折扣，而两年期则给予额外折扣（因为你承诺更长时间使用服务，折扣也更大）。你可以随时编辑预留实例协议，增加或删除虚拟机。增加数量可以提供额外折扣，而减少数量则会导致处罚。

在 IaaS 和 PaaS 之间做决定

一旦订阅完成，你就可以开始创建资源，以便使用它们并部署你的应用程序。在微软 Azure 提供的广泛选择面前，选择使用什么以及何时使用可能会让人感到不知所措。在开始之前，我们需要考虑不同的方法和架构。

我们已经讨论过 IaaS、PaaS 和 SaaS。微软 SaaS 的一个例子是 Office 365，作为一种云软件，它采用订阅模式提供。Office 365 甚至运行在 Azure 数据中心（这也是这些数据中心的最初目的之一，除了身份管理——我们现在称之为 Azure Active Directory），但我们不会进一步讨论这个产品，因为它与 Azure 订阅没有直接关系。我们的目标是区分微软 Azure 在 IaaS 和 PaaS 方面的产品。

IaaS 是迁移到云的第一步。传统 IT 专业人员通常会接受这作为云之旅的第一步。创建 Azure 虚拟机非常简单，从虚拟机层面看，本地虚拟机与云虚拟机之间没有太大区别。你无法访问硬件或主机组件，这使得维护更简单、更便宜。但是，在 Azure 中管理虚拟机和管理本地版本差别不大，无论我们本地使用什么主机——Hyper-V、VMWare 或其他（微软 Azure 使用的是修改版的 Hyper-V 主机，与本地使用的版本有所不同）。

你选择操作系统的镜像，选择虚拟机的大小，以及其他一些参数。从这里开始，你可以连接到虚拟机并根据需要安装特性和软件。你可以控制所有安装在虚拟机上的软件的访问、框架和数据；你需要为其支付订阅费用，或者提供你自己的有效许可证。如果你创建一个带有 Windows Server 2016 和 SQL Server 2016 的虚拟机，你将额外支付这两项许可证费用。

创建 PaaS 资源比 IaaS 更简单。它也更容易管理和维护。但另一方面，控制权不再完全掌握在自己手中。你可以编辑一些预定义的关键特性，使它们具有不同的值或开关状态。但有些内容是默认的，你将无法编辑它们。所有的许可证都已默认包含在资源的价格中。

假设你有一个运行在 IIS 前端的 Web 应用程序和一个在 SQL Server 后端的数据库，让我们考虑一个简单的场景。

对于 IaaS，你需要创建两个虚拟机，一个 Web 服务器和一个数据库服务器。为了托管你的应用程序，你需要在将运行 Windows Server 2016 的 Web 服务器上设置 IIS。数据库服务器可以是一个运行 Windows Server 2016 上的 SQL Server 2016 的虚拟机。到目前为止，加上我们的计算价格，我们已经有了两个 Windows Server 许可证和一个 SQL Server 许可证（如果选择 Web、Standard 或 Enterprise 版本，SQL Server 的价格也会有所不同）。一旦我们安装并配置好 IIS，我们需要创建防火墙和网络安全组规则，这将允许我们通过互联网访问我们的应用程序。我们还需要设置 Web 服务器和数据库服务器之间的通信，并创建类似的规则，以便我们的应用程序与数据库之间能够相互通信。到这里，我们已经很忙了，在 IaaS 中启用一个简单的场景。

对于 IaaS，我们将设置应用服务计划，以托管我们的 Web 应用程序和后端的 Azure SQL 数据库。所有许可证已经配置好，我们不需要做其他的配置工作。这个过程更加简单易行。

请注意，PaaS 在大多数情况下的定价更便宜。

但另一方面，PaaS 并不总是能满足我们运行应用程序所需的一切。如果我们需要使用某个框架的旧版本，PaaS 将无法工作。PaaS 已经预配置了一些框架，你可以使用它们，但无法额外安装任何内容。如果你的数据库有一些在 Azure SQL 中不受支持的特性，或者存在兼容性问题，你需要在虚拟机中使用 SQL Server。

总体而言，PaaS 通常比 IaaS 更便宜且需要更少的关注，但 IaaS 提供了更好的控制和更好的传统支持。

服务产品每天都在增长，每隔几周，Microsoft Azure 就会推出新服务和新功能。我们提到的几个服务只是简单场景中的示例。IaaS 确实让我们可以控制 VM 中的内容，并提供比单一资源更好的组合，但 PaaS 的服务列表远不止于此。对于 Azure PaaS，我们可以创建应用服务、内容分发网络、Azure SQL 数据库、流量管理器、服务总线、Azure Functions、Azure CosmosDB、Azure 存储、Redis 缓存等，以上只是其中的一些。

Azure 数据平台有超过 50 种不同的 PaaS 服务，其他平台如网页、媒体、计算等也是如此。从财务角度和性能角度来看，选择合适的服务都很有利。我们需要考虑是否有些服务存在限制，迫使我们使用其他服务来弥补这一限制。同时，也有可能存在其他服务能够覆盖这两个方面，这样就无需使用额外的服务。如果我们没有全面考虑所有方面，并试图预测所有可能的场景，限制可能会导致性能问题。幸运的是，在 Azure 中，我们不会被单一的解决方案束缚，即便我们发现自己选择的服务并不能真正满足需求——我们可以随时扩展或完全切换到另一个服务。

了解 Azure 资源的定价

在 Microsoft Azure 中，关于定价有几个需要考虑的方面。有些资源有固定定价，有些资源则按消费定价。此外，固定定价的资源有时会包括基础价格中的服务级别限制。一旦达到该限制，您将根据消费量额外收费。这可能会将固定定价资源转变为消费定价资源。还有一些例外情况，适用不同的使用方式。

固定定价的资源会在您创建时立即加入到账单中。固定定价资源按月计费，具有固定价格，并在创建时加入到您的账单中。此类服务的示例包括 OMS 或 Azure Active Directory（在更高的服务等级上）。预留公共 IP 地址也是固定成本资源之一。在您删除此类资源后，它将被加入到当前计费周期的账单中。

Azure 存储基于消费模式，您为存储账户中的数据量付费。但是，数据量每个月都在变化，月初或月末可能数据较少，而月中数据量则可能较多。在这种情况下，会计算平均消费量，并且您会根据 Azure 存储的平均消费量进行计费。

一个有性能级别限制的服务的例子是带宽。传入数据传输是免费的，只要数据流向 Azure 数据中心，你不需要支付任何费用。每月前 5 GB 的外发数据是免费的，超过 5 GB 的部分需要额外收费。另一个服务限制的例子是 Azure 容器注册表，你有 100 分钟的 CPU 时间包含在内，但超过这个限制会额外收费。Azure Function 也是这种资源类型的一个例子，前 1,000,000 次执行是免费的，之后的执行则需要收费。

基于计算的资源是按分钟计算的。如果你运行虚拟机或应用服务，只要删除这些资源，计费就会停止。这同样适用于某些情况下停止的资源。Azure SQL 数据库不能停止，但定价会按分钟计算。如果你删除 Azure SQL 数据库，删除的那一刻起就停止支付费用。对于虚拟机和应用服务，你可以停止这些资源，之后就不再支付计算小时费用。需要注意的是，虚拟机的定价有一些细节。虚拟机价格信息，你可以在 Azure 门户中创建虚拟机时找到，或在 Azure 计算器中查看，它仅适用于计算小时。虚拟机还使用 Azure 存储，存储费用与计算费用分开计算，无论虚拟机是否正在运行，你都会为存储付费。某些网络组件可能会为虚拟机产生额外费用。例如，你可以预留一个公共 IP 地址，并为此单独收费。

在 Azure 中，跟踪你的资源并了解你正在使用什么，资源是否被利用，以及当前资源的限制是什么，非常重要。如果你没有正确使用某个资源，或者根本没有使用它，你仍然需要为它付费。这与传统 IT 环境不同，在传统环境中，你的资源是预付费的，只要你没有达到主机级别的资源限制，即使某个虚拟机没有被使用，也不会影响费用。在 Azure 中，你为你创建的每个资源（或在某些情况下运行的资源）付费，因此你需要跟踪活跃的资源以及你实际需要的资源。否则，云可能变成一个非常昂贵的解决方案，账单会开始堆积。财务上的好处可以是巨大的，但如果你不小心，也可能适得其反。我见过很多公司在没有控制的情况下使用开发和测试环境，许多资源是没人知道是谁创建的，更别提是否有实际使用这些资源的人了。生产环境中不太常见这种问题，但在某些情况下也会发生。

聪明一点，Azure 会帮助你，但如果你不跟踪使用情况和账单，它可能会反过来对你不利。这是你的选择：你可以被晋升，也可以被解雇！

ARM 革命

2014 年 4 月，微软宣布了对 Azure 的新方法，引入了新的门户和 ARM 模型。我们已经讨论过 ARM 和 RBAC 如何改变了 Azure 资源的管理，使得云端生活变得更加轻松。

但 ARM 带来的另一个选项是 ARM 模板。ARM 模板是 JSON 格式的文件，包含单个资源组中所有资源的信息。我们可以使用 ARM 模板来部署新资源、更新资源或从资源组中删除资源。Azure 门户中的每个资源组都有一个自动化面板，允许我们保存该资源组的 ARM 模板、重新部署资源或将模板下载到本地。这使得我们能够快速且简单地复制资源组中的资源。

这就是为什么在 Azure 中为单一应用程序放置资源是常见做法。如果我们有一个复杂的环境，部署可能需要一些时间，这时 ARM 模板就非常有用。例如，假设我们有一个 SharePoint 集群，其中有运行域控制器角色的 Windows Server，两个 SharePoint 集群服务器，以及两台额外运行 SQL Server 的服务器。这要求我们创建一个虚拟网络，创建五个服务器，并将它们加入到虚拟网络中。手动在 Azure 门户中执行这些操作需要一些时间。但使用 ARM 模板，我们可以在几秒钟内完成这些操作。

使用 ARM 模板部署基础设施只是作为代码的基础设施的一种方式。我们也可以通过 PowerShell 和 Azure CLI 实现类似的功能。使用作为代码的基础设施使我们能够以快速可靠的方式部署运行应用程序所需的基础设施。它也是一种更一致的选择，因为我们排除了部署中的手动任务，创建了自动化过程，并消除了部署中的人为错误。

关于 ARM 模板的另一个好处是，它们可以被添加到我们的应用程序项目中并存储在代码仓库中，我们可以跟踪环境的版本。不同版本的应用程序可能需要改变环境，而通过 ARM 模板和代码仓库，我们可以追踪这些变化，确保为我们要部署的应用程序版本部署正确的环境。

总结一下，ARM 模板是一种快速、可靠、一致的部署 Azure 资源的方法，能够帮助我们跟踪环境版本并自动化部署过程。这对于在软件交付中实现 DevOps 尤为有趣和有用。结合作为代码的配置（我们将在后面的章节中讨论），我们可以构建或复制任何环境，包含所有所需资源，并应用所需配置，确保一切顺利运行。

下面是一个空的 ARM 模板示例：

{
 "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 },
 "variables": {
 },
 "resources": [
 ],
 "outputs": {
 }
}

ARM 模板包含有关参数、变量、资源和输出的信息。通过这些信息，我们定义了需要部署哪些资源，使用哪些参数，以及哪些参数可以是可以更改的变量。最后，我们定义了输出作为回应，但这一部分是可选的。

总结

在本章中，我们解释了云计算类型及其随时间演变的过程，重点介绍了公有云和微软 Azure。下一步是解释公有云服务模型，以及 IaaS、PaaS 和 SaaS 的工作原理和这些公有云类型的基本概念。你还应该了解 Azure 订阅是如何工作的，资源的价格是如何计算的，以及与 Azure 订阅和 ARM 模型相关的基本管理概念。我们提供了关于 ARM 的一般信息，并解释了它如何与 RBAC 和 ARM 模板连接。

理解 Azure 订阅和 ARM 模板，以及 IaaS 和 PaaS 在 Azure 中的应用非常重要，因为我们将在接下来的章节中使用这些知识。

下一步将是 IaaS，作为云计算的第一步。IaaS（以及所有其他 Azure 服务）的基础是 Azure 网络堆栈，我们将从这一部分开始。

问题

1. 哪种类型的云需要互联网连接并允许任何人注册服务？

   1. 私有云

   2. 托管云

   3. 公有云

2. 哪种云服务模型允许我们对资源进行最多的控制？

   1. IaaS

   2. PaaS

   3. SaaS

3. 哪种云服务模型需要最少的管理和行政操作？

   1. IaaS

   2. PaaS

   3. SaaS

4. 哪种云服务模型始终提供最新的功能和更新？

   1. IaaS

   2. PaaS

   3. SaaS

5. 在 Azure 中，是什么负责将客户端环境与其他客户端分隔开？

   1. Azure 架构

   2. Azure 租户

   3. Azure 订阅

6. Microsoft Azure 中的第一个访问层是什么？

   1. Azure 架构

   2. Azure 租户

   3. Azure 订阅

7. 在 Azure 资源中，你可以分配访问权限的最低粒度是什么？

   1. Azure 资源

   2. Azure 资源组

   3. Azure 订阅

8. 应为 Azure 资源分配什么访问级别是推荐的？

   1. Azure 资源

   2. Azure 资源组

   3. Azure 订阅

9. 如何计算 Microsoft Azure 的定价？

   1. 每年

   2. 每月

   3. 每分钟

10. ARM 模板属于什么？

    1. 基础设施即代码

    2. IaaS

    3. 配置即代码

第二章：Azure 网络 - Azure IaaS 的基础

我们云旅程中的下一步是 Azure 网络。此步骤将为我们的 Azure 基础设施奠定基础，并将在接下来的章节中为 IaaS 和 PaaS 使用。设计和实施 Azure 网络时，必须考虑到未来将使用的所有 Azure 服务。这将为你节省大量麻烦，并使你的云之旅安全且稳定。

本章将涵盖以下内容：

• Azure VNet

• 地址范围

• 子网

• IP 地址类型和预留

• DNS

• 网络安全组（NSGs）

• Azure 虚拟机网络

技术要求

本章内容你需要一个 Azure 订阅。

Azure 网络基础

Microsoft Azure 中的网络栈非常重要，它是其他服务的基础，特别是当我们谈到 IaaS 时。正确设置 Azure 网络非常重要，因为它是设置 IaaS 基础设施并允许虚拟机进行通信的关键。Azure 中的网络栈由两个组成部分构成，外部和私有。外部用于通过互联网访问服务端点，私有用于 Azure 服务之间的内部通信。

几乎所有 Azure 服务默认都有外部端点配置，但在某些特殊情况下，我们不希望启用互联网访问。在这些情况下，我们可以禁用外部端点，并将这些服务设置为仅使用私有流量。这同样适用于 PaaS，尽管这些服务通常默认没有配置私有网络访问（除了某些为此设计的 PaaS 服务，例如隔离应用服务）。在本章中，我们将讨论基本的网络功能，并将在适当时继续探讨针对特定服务的网络选项。

IaaS 通常也有外部端点配置，但我们可以选择禁用这些端点，不允许通过互联网访问。另一方面，IaaS 总是会配置一个私有网络。每个 Azure 虚拟机都必须分配到一个虚拟网络，并分配一个私有 IP 地址。即使我们只配置了一个虚拟机，并希望它仅用于公共互联网访问，系统也会在后台创建一个虚拟网络，并为该虚拟机分配一个私有 IP 地址。

Azure 网络还扩展到 VPN 选项，允许你仅通过私有网络和私有 IP 地址访问服务。这使你能够进一步保护资源，并禁用任何类型的公共访问。我们将在讨论与 Microsoft Azure 的混合云时探讨这些功能和选项。

在 Azure 中创建你的第一个虚拟网络

Azure 虚拟网络（Azure VNet）有两种创建方式：一种是创建新的 VNet，另一种是创建新的 Azure 虚拟机。两者的选项相似，但我建议先创建 Azure VNet，并将虚拟机加入到现有的 VNet 中，因为这样会有更多的选项。

要创建一个新的 Azure Vnet，请打开 Azure 门户，选择“创建资源”，然后在“网络服务”中选择“虚拟网络”（或在搜索栏中搜索Virtual network），如下面的截图所示：

你需要为虚拟网络提供一些参数。资源名称在资源组级别必须唯一，并且必须是单个字符串，不允许有空格。我的资源名称是 PacktVNet，但如果我想分开这两个词，也可以使用 Packt_VNet。接下来的参数是地址空间。这将定义在此 VNet 中可用的 IP 地址数量，使用 CIDR 格式。最大的地址空间是 /8，最小的是 /29。在这种情况下，我将使用 /16，这将为我提供足够的地址空间。我们需要选择放置资源的订阅（仅当有多个订阅时需要选择；如果只有一个订阅，系统将默认选择）。资源组名称有两个选项，可以选择创建一个新的资源组，也可以选择现有的资源组。由于我通常会在创建其他资源之前配置虚拟网络，因此会与 VNet 一起创建一个新的资源组。接下来的步骤是选择我们希望创建资源的区域。我建议选择离你最近的 Azure 数据中心，因为这样将来能提供最低的网络延迟。如果选择了现有的资源组，该选项将自动选择资源组所在的相同区域。你需要为默认子网命名，并为该子网提供地址空间。子网的地址范围必须在 VNet 地址空间的地址范围内。

默认情况下提供基础的 DDoS 保护，是免费的，但你可以选择标准层，它需要单独收费。我们将在 第九章，Azure 安全与管理 中进一步讨论 DDoS。以下截图展示了虚拟网络部署所需的信息示例：

最后的选项与服务端点有关。如果我们启用此功能，会显示新的窗口，如下面的截图所示。此选项允许你将 PaaS 服务附加到你的 VNet。你可以选择 Azure Cosmos DB、事件中心、密钥保管库、服务总线、SQL 和存储，或者选择全部。在此，我将禁用端点，稍后我们会讨论它们：

最后一步是确认选项并开始创建资源的过程。Azure 虚拟网络工作相对较快，资源应该在不到一分钟的时间内创建完成。这可能取决于数据中心的工作负载和请求数量，但即使在需求量大的情况下，也应能相对快速地完成。

Azure 虚拟网络代表了你在云中的自有网络。它具备类似于本地网络的特性，例如 IP 地址范围和子网。如果你熟悉本地网络环境的网络设置，那么理解 Azure 网络将会非常容易。

Azure 虚拟网络选项

部署完成后，你会有不同的管理选项可供选择。定位到你的资源组并打开虚拟网络选项卡。在“概览”标签页中，你可以看到有关虚拟网络的不同信息，比如资源组、订阅位置等等。

在设置中，我们有多个可供配置的选项：地址空间、连接设备、子网、DDoS 保护、DNS 服务器、对等连接和服务端点。每个 Azure 资源都有属性、锁定和自动化脚本，而这些不仅仅限于 Azure 虚拟网络。属性提供关于资源的只读信息，锁定显示是否有依赖于该服务的其他服务。自动化脚本会为资源的重新部署生成 ARM 模板。请注意，此选项会为整个资源组生成 ARM 模板，而不仅仅是为某个特定资源。自动化脚本可以在未来的重新部署中使用，万一我们需要为新的客户或新环境复制资源。

在地址空间中，我们可以编辑现有的地址空间或添加新的地址空间。这里有两个限制：地址空间不能重叠，并且不能将一个地址空间缩小到比使用该地址空间的子网还要小。例如，如果你创建了地址空间10.1.0.0/16和子网10.1.0.0/16，那么该地址空间不能更改为小于10.1.0.0/16，除非先更改子网。如何使用地址空间是很重要的；在未来的 VPN 连接中，你不能将 Azure 虚拟网络连接到使用相同地址空间的网络（无论是 Azure 网络还是物理网络）。添加新地址空间可以参见以下截图。确保新的地址空间不会与现有地址空间重叠：

在子网选项卡中，你有两个选择：更改现有子网或添加一个新的子网。对于这两种选项，你必须使用现有的地址空间，且子网不能重叠。现有的子网不能更改为使用比已用的地址空间更少的空间。例如，如果你的地址空间是10.1.0.0/24并且该子网已经有 200 个虚拟机，那么你不能将其更改为小于/24的地址空间，因为/25只有 128 个可用地址。

另一个需要注意的事项是，你在子网中并没有完整的 IP 地址范围；有五个 IP 地址被保留用于 Azure 提供的网络角色，例如 DNS 或 DHCP。说到 DHCP，Azure 不支持自定义 DHCP 解决方案，你必须使用 Azure 提供的 DHCP。DNS 则不同；默认情况下，你使用的是 Azure DNS 服务，但也可以使用自定义解决方案。

要添加一个新子网，你需要提供与 VNet 部署时创建默认子网时相似的信息，但你会有几个额外的选项。你需要提供子网的名称和 IP 地址范围，这些范围必须使用你 VNet 中现有的 IP 地址，并且不能与 VNet 上的其他子网重叠。请注意，在这里你会看到关于为 Azure 网络服务保留五个 IP 地址的信息。类似的 VNet 部署选项是服务端点选项，允许你将 PaaS 服务添加到子网中。你可以将网络安全组分配到子网级别，并分配路由表。

网络安全组（NSG）是你控制 Azure VNet 流量的主要工具，我们稍后会详细讨论它们。Azure 会自动在同一 VNet 上的所有子网之间路由流量，但你可以创建自定义路由表来覆盖默认选项。这在你使用 VPN 或虚拟设备（例如第三方防火墙）时非常有用。如下图所示，这是向 VNet 添加新子网的示例：

DNS 窗格允许我们为 VNet 添加自定义 DNS 解决方案。如前所述，默认情况下这是 Azure 提供的，但你也可以使用自己的 DNS，无论是使用带有 DNS 的虚拟机还是公共 DNS。

如果你有一个 Site2Site 连接到本地网络，那么它可以作为本地网络的 DNS。如果是这种情况，我建议在 Azure 中使用 DNS 的副本。这将使响应更快，并确保在 VPN 连接或本地网络因某些原因不可用时，DNS 仍可在 Azure VNet 中使用。提供自定义 DNS 的选项如下图所示。你需要提供 DNS 服务器的 IP 地址，如果选择使用公共 DNS，则提供公共 IP 地址；如果在 VNet 中部署 DNS，则提供私有 IP 地址：

在部署过程中，我们有机会为 VNet 添加服务端点，但我们可以随时使用服务端点窗格添加，如下图所示。由于添加这些服务会启动一个配置过程，设置路由和规则，因此该过程可能需要最多 15 分钟才能完成。服务端点选项可用于 VNet 和子网级别，因此你可以为整个网络或单个子网启用端点。使用单个子网可以提供更多控制，并能够将 PaaS 服务与虚拟网络的其他部分分离：

对等连接允许你将 VNet 连接到其他 VNet，以便交换流量。这仅适用于同一个 Azure 租户中的 VNet（但可跨该租户中的订阅使用）。你需要为连接指定一个名称，然后选择适当的订阅和虚拟网络。你还有一些额外的选项可以定义，例如是否需要流量转发、是否允许网关中继以及是否使用远程网关。默认情况下，只有来自一个 VNet 的流量会被转发到第二个 VNet。来自对等连接外部的流量（例如来自第二个对等网络，只有一个 VNet 涉及，或者通过网关传输的流量）不会被转发，除非你指定这些选项。

例如，假设我们有三个 VNet：A、B 和 C。A 连接到 B，C 也连接到 B，但 A 和 C 之间没有直接连接。默认情况下，流量会被允许从 A 到 B，从 B 到 A，从 B 到 C，以及从 C 到 B。A 到 C 或 C 到 A 的流量不会被允许。如果我们启用流量转发，A 到 C 和 C 到 A 的流量将会被转发。

虚拟网关也有类似的情况。假设我们有 A 和 B 两个网络，并且这两个 VNet 之间有对等连接。VNet A 有一个虚拟网关，并且已连接到我们的本地网络。默认情况下，A 到 B、B 到 A、本地网络到 A 以及 A 到本地网络的流量都会被允许。除非我们使用额外选项允许网关中继和远程网关的使用，否则本地网络到 B 和 B 到本地网络的流量将不被允许。

另一种实现方式是为每个 VNet 创建一个虚拟网关，并创建一个 Site2Site 连接，这与连接到本地网络时所使用的连接方式相同（我们将在混合云章节讨论这个问题）。这两种方法的主要区别在于，对等连接是免费的，而虚拟网关是收费的。如果你希望连接位于不同租户的两个 VNet，你需要使用虚拟网关；而对等连接仅适用于同一个租户中的 VNet。

为了连接不同的网络，无论是 VNet 到 VNet 还是 VNet 到本地网络，IP 地址空间/子网不能重叠。如果两个网络使用相同的子网，你将无法创建该连接，因为这会造成混淆，并使路由变得不可能。将无法区分哪个设备属于哪个网络，也无法确定流量应该流向哪里。如何在你的订阅中将 VNet 连接到另一个 VNet，如下图所示：

在多个网络通过对等连接或 Site2Site 连接的情况下，建议使用路由表。自定义路由表允许我们在特定情况下创建并转发流量，并定义有关流量应该去往哪里的一些规则。

连接的设备

我们的虚拟网络已经配置好并准备就绪，但我们需要在其中添加资源才能实际使用它。第一步是将新的 Azure 虚拟机添加到虚拟网络中，以便开始使用 Azure 网络栈。

创建 Azure 虚拟机

为了通过门户创建新的 Azure 虚拟机，我们需要执行三个步骤。我们需要选择“新建资源”，然后选择新的虚拟机。我们有成百上千的镜像可供选择，稍后将在章节中讨论这些镜像：

1. 在这种情况下，我们只需要一台虚拟机来展示其网络选项，并且我们将设置所有默认参数以便快速完成。我选择了 Windows Server 2016 镜像，并开始提供所需的基本信息：名称、虚拟机磁盘类型、用户名、密码、订阅、资源组和位置。请注意，在位置选项下，你可以选择创建新的资源组或选择现有的资源组。我选择了“使用现有资源组”，即与我们的虚拟网络所在的资源组相同。

基本虚拟机创建的示例如下所示：

1. 下一步是选择虚拟机的大小。这个步骤与网络部分无关，我将选择系统提供的第一个选项，B1s，见下图：

1. 在最后一步，我们进入了包含网络选项的部分。我将所有其他选项保留默认设置，并专注于网络部分。

首先，我们需要选择虚拟机将连接的虚拟网络（VNet）。我们可以选择一个现有的虚拟网络或创建一个新的虚拟网络。如果没有找到任何虚拟网络，将自动提供新的虚拟网络参数。如果在我们放置虚拟机的资源组中已经存在一个虚拟网络，系统会自动选择该虚拟网络。在我们的案例中，第一步创建的 PacktVNet 在以下截图中显示：

我们的第二个选项是选择虚拟机的子网。如果我们在创建虚拟机的同时也创建了一个新的虚拟网络，这个选项将不可用；只有默认子网会被创建。为了能够在子网之间进行选择，虚拟网络必须在虚拟机之前创建，并且需要指定要使用的子网。在这种情况下，我将选择将虚拟机加入之前创建的 DMZ 子网。选择子网选项如下图所示：

我们还可以选择虚拟机的公共 IP 地址。我们可以选择一个现有的公共 IP 地址（一个不再使用的保留 IP 地址）或创建一个新的公共 IP 地址。网络安全组也是如此：我们可以选择现有的一个或创建一个新的。我将选择为我的虚拟机创建一个新的公共 IP 地址和新的网络安全组，如下图所示：

完成后，虚拟机的部署开始，直到过程完成通常需要几分钟。部署一个新的 Azure 虚拟机所需的时间取决于虚拟机的大小、截图以及对数据中心的请求次数。

IP 地址类型

一旦虚拟机的部署完成，我们可以在虚拟网络刃下的“已连接设备”中看到该设备。以下截图显示了连接设备刃的示例。这里显示的信息包括设备名称、连接的设备类型、私有 IP 地址以及设备分配的子网。IP 地址信息与私有 IP 地址相关，这个 IP 地址是在 VNet 级别分配给我们虚拟机的，仅用于内部流量。请注意，设备类型是网络接口。每个虚拟机都有一个网络接口卡（NIC），用于与网络通信，并且会在创建虚拟机时自动创建一个。虚拟机可以有多个 NIC，如果需要连接多个子网，或者确保虚拟机在一个 NIC 故障时仍然可用。NIC 的数量取决于虚拟机的大小，从基本层虚拟机的 1 个 NIC 到更高层虚拟机的 8 个 NIC：

如果我们点击设备，它将带我们进入 NIC 刃如以下截图所示。我们也可以通过在资源组中选择 NIC 来进入相同的页面。在 IP 配置中，我们可以启用或禁用 IP 转发，改变 NIC 连接的子网，并查看私有和公共 IP 地址的 IP 配置：

私有 IP 地址

如果我们选择 IP 配置，我们将有更多的 IP 地址选项。以下截图展示了一个示例。

默认情况下，公共 IP 地址是启用的，但如果需要，我们可以禁用它。这通常用于虚拟机位于后端且不需要公共曝光的场景。在这种情况下，我们需要确保有其他方式连接到虚拟机，通常是通过 VPN。禁用公共 IP 地址通常发生在混合云场景中，当不需要通过互联网访问时。除了使用分配的公共 IP 地址外，我们还可以在这里创建一个新的 IP 地址。

默认情况下，私有 IP 地址是动态的，并且会随着时间变化。IP 地址的变化不会无缘无故发生，而是在虚拟机重启或关闭的情况下发生。如果我们使用私有 IP 地址与 VNet 上的其他虚拟机通信，我们可能希望保持该地址不变。可以通过将 IP 地址分配方式从动态设置为静态来实现。这将为该 NIC 保留 IP 地址，即使虚拟机长时间关闭：

DNS 是 VNet 和虚拟机级别都可用的另一选项。我们可以为特定的 NIC 分配自定义 DNS。如果我们将 DNS 分配到 VNet 级别，该 DNS 将应用于连接到该 VNet 的所有虚拟机。NIC DNS 的默认选项是继承自虚拟网络设置。在这种情况下，它将是 Azure DNS 或自定义 DNS，具体取决于 VNet 设置。如果我们为 VNet 选择了自定义 DNS，则无法在 NIC 级别选择 Azure DNS。我们唯一的可选项是使用“从虚拟网络继承”或“自定义 DNS”。NIC 级别的 DNS 刀锋如下图所示：

网络安全组

NSG（网络安全组）是一组应用于您的 Azure 网络资源的安全规则。它们是执行和控制资源网络流量规则的主要工具。NSG 可以应用于两种类型的资源：子网和 NIC。如果 NSG 应用于子网，规则将应用于连接到该子网的所有设备。当 NSG 应用于 NIC 时，规则仅适用于该设备。

在 NSG 刀锋的概览中，我们可以看到当前应用的所有规则，包括入站和出站规则。默认情况下，来自外部的所有入站流量都会被禁用，除了 3389 端口，它允许我们远程连接到虚拟机。来自虚拟网络内部或 Azure 负载均衡器的所有入站流量是允许的。这些规则可以根据需要进行编辑和添加。

默认情况下，所有级别的出站流量都允许流向虚拟网络或外部。 这些规则也可以编辑，但通常无需限制出站流量。

所有规则都有一个优先级分配给它们；较低的数字表示具有较高优先级的规则。例如，我们有优先级为 1000 的 RDP 规则，以及优先级为 65500 的 DenyAllInBound 规则（该规则会阻止所有入站流量）。即使强制执行了 DenyAllInBound 规则来阻止所有入站流量，允许 RDP 的规则优先级更高，将首先执行。因此，所有入站流量都会被阻止，除了 RDP 规则，由于其优先级更高，允许连接。

NSG 设置可以通过 NIC 刀锋或通过在资源组的资源列表中选择 NSG 打开。NSG 刀锋的概览如下图所示：

要添加新规则，请转到入站安全规则并选择添加新规则。您可以选择基本或高级。如果选择基本，则只会提供一些选项供选择。我建议使用高级，这样可以让您对规则有更多的控制权：

• 源：对于源，你可以在几个选项之间进行选择。Any将允许来自任何源的流量。IP 地址将仅允许来自指定地址的流量；你可以输入单个 IP 或 CIDR 格式的 IP 地址范围。这对于限制通过端口3389的访问以及保护虚拟机非常有用。服务标签将允许来自特定服务的流量。例如，使用服务标签选项，你可以允许来自 Azure 存储的流量，但阻止其他所有流量。

  源的最后一个选项是应用程序安全组（ASG）。ASG 允许你创建规则并仅允许流量进入网络上某一特定资源组。例如，我们在 VNet 中有多个服务器，Web 服务器和数据库服务器。允许通过端口1433到数据库服务器的流量应该对 Web 服务器启用，但不允许通过互联网。将 Web 服务器放入 ASG 并创建规则，可以只允许 Web 服务器通过端口1433访问我们的数据库，并阻止任何其他流量。

• 源端口范围：通过源端口范围，我们还可以限制流量，仅允许来自特定端口或端口范围的流量。

• 目标端口范围：目标端口范围选项与源选项类似；我们有相同的可用选项集。ASG 可以用于仅允许网络中特定类型的虚拟机访问。例如，将 Web 服务器放入 ASG，并允许通过端口443或80的流量，这样就只有这些服务器可以通过这些端口进行访问，并且阻止对任何其他类型虚拟机的流量。

  目标端口范围允许我们指定流量允许经过的端口，可以将其限制为单一端口或一个范围。

• 协议：它帮助我们定义哪些协议是允许的，可以选择 TCP 或 UDP。

• 操作：它定义了这个规则是用于允许流量还是阻止流量。NSG 可以双向使用，它可以帮助我们定义是否允许特定的流量，但也可以用于拒绝流量，从而帮助我们在 Azure 中保护资源。

• 优先级：此选项非常重要，因为它帮助我们定义首先应用哪些规则，哪些规则具有优先权。如前所述，分配给规则的优先级数字越低，规则的优先级越高。规则会按顺序处理，从最高优先级的规则（数字最小）到优先级较低的规则（数字较大），直到满足条件。一旦条件满足，规则就会被处理，并且规则处理停止。例如，我们创建一个规则，阻止所有通过端口1433的流量，并给它优先级1000，然后创建一个规则，允许某些来源通过端口1433的流量，优先级为2000。由于优先级较高的规则正在阻止该流量，因此端口1433上的流量永远无法通过。

• 名称：最后的选项是为规则命名并输入描述。描述是可选的，但我建议您填写，因为这将帮助您日后跟踪和理解为何首次创建某个规则。

示例设置展示了 NSG 中高级选项的配置，如下截图所示：

NSG 可以应用于两个级别，即网络接口卡 (NIC) 和子网。如果将 NSG 应用于 NIC，则该 NSG 中定义的规则仅对连接到该 NIC 的虚拟机生效。如果将 NSG 应用于子网，则该子网上的所有虚拟机都将遵循这些规则。

在某些情况下，可以同时在子网和 NIC 上应用 NSG。在这种情况下要小心配置，因为只有在两个级别都允许的流量才会通过。如果在子网级别允许端口 80 的流量但在 NIC 级别阻止，端口 80 上将不会有流量通过。反之亦然，如果在 NIC 上允许但在子网上阻止，则端口上也不会有流量通过。如果要在已在子网和 NIC 级别应用了 NSG 的 VM 上阻止某些内容，只需在其中一个 NSG 上阻止命名端口上的流量即可。

使用 NSG 与 ASG 结合是保护和确保资源安全的最佳方式。

让我们创建一个场景，其中我们有三组服务器：web、应用和数据库。

我们需要使 web 服务器能够连接到应用服务器，应用服务器能够连接到数据库服务器。仅允许通过互联网连接到 web 服务器，而我们不希望在任何情况下通过互联网连接到数据库服务器。第一步是创建三个 Azure 安全组，每个安全组用于一个服务器角色。接下来是使用 ASG 配置 NSG 规则。

仅允许通过互联网连接到位于 web ASG 中的服务器。仅允许来自位于 web ASG 中的服务器的流量连接到应用服务器。通过设置一条规则来实现此目标，该规则允许来自应用 ASG 的流量到达应用 ASG，阻止其他一切。最后，我们创建一条规则，允许仅在流量来自应用 ASG 时连接到数据库服务器 (数据库 ASG)。

这种方法使管理和维护变得更加简单和一致。如果要将服务器添加到任何三个池中的一个，您需要设置适当的规则并应用所需的设置。很容易犯错，导致该服务器未拥有所有必要的连接，或者在最坏的情况下成为安全问题。使用 NSG 和 ASG 来跟踪所有规则时，我们只需将新服务器添加到适当的 ASG 中，所有规则和设置将自动应用。

公共 IP 地址

公共 IP 地址设置可以通过 NSG 设置进行访问，或者通过在资源组面板中选择公共 IP 地址来访问。

公共 IP 地址的设置与私有 IP 地址类似。默认情况下，它们是动态的，因此在重启或关机时，IP 可能会发生变化，但我们可以将此设置更改为静态。静态 IP 会保留我们的 IP 地址，但在这种情况下，公共 IP 地址和私有 IP 地址之间有一个区别。私有 IP 地址的保留是免费的，因为这是一个内部 IP 地址，所以你可以选择范围，甚至为特定虚拟机（VM）保留该范围内的 IP 地址。而公共 IP 地址是分配的，并且没有选择所需 IP 地址的选项。另一个区别是，公共 IP 地址的保留是收费的；每个订阅可以免费保留前五个公共 IP 地址，但超过这个数量的每次保留都将收费。超过前五个公共 IP 地址的保留价格并不高（大约每月$3），但了解你为此付费是很重要的。

如果你想限制访问，可以从 NIC 中删除公共 IP 地址（私有 IP 地址不能删除）。如果你选择使用公共 IP 地址，你可能需要它来远程连接到虚拟机，或者用于应用程序。如果你不想创建保留，还有一个选项，可以使用 DNS 名称标签。此选项将为你的 NIC 分配一个 DNS 名称，你可以使用它来访问虚拟机。任何公共 IP 地址的变化（可能由于虚拟机重启或关机而发生）将由 Azure DNS 处理。公共 IP 地址配置的选项如下图所示：

其他 Azure 网络服务

我们目前所涵盖的 Azure 服务只是 Azure 网络栈的一部分。Azure 网络栈并不止于此，还有许多其他与网络相关的 Azure 服务，例如流量管理器、负载均衡器或虚拟网关。其中一些将在后续章节中介绍。

例如，我们将讨论具有虚拟机高可用性的负载均衡器。当我们讨论 PaaS 的高可用性时，流量管理器将是一个类似的案例。虚拟网关将在关于 Microsoft Azure 混合云的章节中讨论。

混合场景和安全性可以通过虚拟设备进行管理。虚拟设备是带有第三方防火墙软件的 Azure 虚拟机。大多数领先的行业防火墙都受支持并可用（例如 Barracuda、CheckPoint、Cisco 和 PaloAlto）。虚拟设备的虚拟机镜像可以通过 Azure 市场获得，你可以轻松配置并设置虚拟设备，使用它来管理和保护你的 Azure 网络。

然而，Microsoft Azure 正在不断发展，越来越多的服务正在推出。涵盖所有服务和功能是不可能的。本书的每一章都可能成为一本独立的书。

ARM 模板

我们已经讨论了 ARM 模板以及它们如何帮助我们实现自动化。在本章中，我创建了一个虚拟网络，并将一台虚拟机加入到该网络中。

如果您转向自动化，您可以找到一个 JSON 格式的 ARM 模板，您可以使用它重新部署我的资源。该 ARM 模板将包含所有资源和所有设置：虚拟网络及其参数、包含有关镜像和大小的虚拟机、NSG 规则等。它将包含所有依赖项的信息，以及需要首先创建的内容。例如，为了创建虚拟机，需要先创建一个子网，将虚拟机加入到该子网，而子网无法在虚拟网络创建之前创建。

请注意，某些参数（例如密码）没有提供，因为密码不能以明文显示，只能作为安全字符串提供，因此您需要手动提供这些参数：

{
 "$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "virtualMachines_PacktVM1_name": {
 "defaultValue": "PacktVM1",
 "type": "String"
 },
 "virtualNetworks_PacktVNet_name": {
 "defaultValue": "PacktVNet",
 "type": "String"
 },
 "networkInterfaces_packtvm1240_name": {
 "defaultValue": "packtvm1240",
 "type": "String"
 },
 "publicIPAddresses_PacktVM1_ip_name": {
 "defaultValue": "PacktVM1-ip",
 "type": "String"
 },
 "networkSecurityGroups_PacktVM1_nsg_name": {
 "defaultValue": "PacktVM1-nsg",
 "type": "String"
 },
 "subnets_DMZ_name": {
 "defaultValue": "DMZ",
 "type": "String"
 },
 "subnets_default_name": {
 "defaultValue": "default",
 "type": "String"
 },
 "securityRules_default_allow_rdp_name": {
 "defaultValue": "default-allow-rdp",
 "type": "String"
 },
 "adminUsername": {
 "type": "string",
 "metadata": {
 "description": "Default Admin username"
 }
 },
 "adminPassword": {
 "type": "securestring",
 "metadata": {
 "description": "Default Admin password"
 }
 }
 },
 "variables": {},
 "resources": [
 {
 "type": "Microsoft.Compute/virtualMachines",
 "name": "[parameters('virtualMachines_PacktVM1_name')]",
 "apiVersion": "2017-12-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "hardwareProfile": {
 "vmSize": "Standard_B1s"
 },
 "storageProfile": {
 "imageReference": {
 "publisher": "MicrosoftWindowsServer",
 "offer": "WindowsServer",
 "sku": "2016-Datacenter",
 "version": "latest"
 },
 "osDisk": {
 "osType": "Windows",
 "name": "[concat(parameters('virtualMachines_PacktVM1_name'),'_OsDisk_1_b6ae3bba44ef491f8c2acd7bfb5aa975')]",
 "createOption": "FromImage",
 "caching": "ReadWrite",
 "managedDisk": {
 "storageAccountType": "Standard_LRS"
 },
 "diskSizeGB": 127
 },
 "dataDisks": []
 },
 "osProfile": {
 "computerName": "[parameters('virtualMachines_PacktVM1_name')]",
 "adminUsername": "[parameters('adminUsername')]",
 "adminPassword": "[parameters('adminPassword')]",
 "windowsConfiguration": {
 "provisionVMAgent": true,
 "enableAutomaticUpdates": true
 },
 "secrets": []
 },
 "networkProfile": {
 "networkInterfaces": [
 {
 "id": "[resourceId('Microsoft.Network/networkInterfaces', parameters('networkInterfaces_packtvm1240_name'))]"
 }
 ]
 },
 "diagnosticsProfile": {
 "bootDiagnostics": {
 "enabled": true,
 "storageUri": "https://nagiosdiag316.blob.core.windows.net/"
 }
 }
 },
 "dependsOn": [
 "[resourceId('Microsoft.Network/networkInterfaces', parameters('networkInterfaces_packtvm1240_name'))]"
 ] 
 },
 {
 "type": "Microsoft.Network/networkInterfaces",
 "name": "[parameters('networkInterfaces_packtvm1240_name')]",
 "apiVersion": "2018-02-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "resourceGuid": "2d51720b-041b-4248-ab04-8dd9fd3fa7d9",
 "ipConfigurations": [
 {
 "name": "ipconfig1",
 "etag": "W/\"b681e202-2d98-4d28-a30d-aaf93b9f1243\"",
 "properties": {
 "provisioningState": "Succeeded",
 "privateIPAddress": "10.1.1.4",
 "privateIPAllocationMethod": "Static",
 "publicIPAddress": {
 "id": "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPAddresses_PacktVM1_ip_name'))]"
 },
 "subnet": {
 "id": "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('virtualNetworks_PacktVNet_name'), parameters('subnets_DMZ_name'))]"
 },
 "primary": true,
 "privateIPAddressVersion": "IPv4"
 }
 }
 ],
 "dnsSettings": {
 "dnsServers": [],
 "appliedDnsServers": [],
 "internalDomainNameSuffix": "gbyhmwrx0mmutogdwlxg2i521c.ax.internal.cloudapp.net"
 },
 "macAddress": "00-0D-3A-2E-EA-03",
 "enableAcceleratedNetworking": false,
 "enableIPForwarding": false,
 "networkSecurityGroup": {
 "id": "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroups_PacktVM1_nsg_name'))]"
 },
 "primary": true
 },
 "dependsOn": [
 "[resourceId('Microsoft.Network/publicIPAddresses', parameters('publicIPAddresses_PacktVM1_ip_name'))]",
 "[resourceId('Microsoft.Network/virtualNetworks/subnets', parameters('virtualNetworks_PacktVNet_name'), parameters('subnets_DMZ_name'))]",
 "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroups_PacktVM1_nsg_name'))]"
 ]
 },
 {
 "type": "Microsoft.Network/networkSecurityGroups",
 "name": "[parameters('networkSecurityGroups_PacktVM1_nsg_name')]",
 "apiVersion": "2018-02-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "resourceGuid": "11b65174-a94e-44e1-947c-dd140c45a6c8",
 "securityRules": [
 {
 "name": "default-allow-rdp",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "protocol": "TCP",
 "sourcePortRange": "*",
 "destinationPortRange": "3389",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "*",
 "access": "Allow",
 "priority": 1000,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 }
 ],
 "defaultSecurityRules": [
 {
 "name": "AllowVnetInBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Allow inbound traffic from all VMs in VNET",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "VirtualNetwork",
 "destinationAddressPrefix": "VirtualNetwork",
 "access": "Allow",
 "priority": 65000,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "AllowAzureLoadBalancerInBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Allow inbound traffic from azure load balancer",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "AzureLoadBalancer",
 "destinationAddressPrefix": "*",
 "access": "Allow",
 "priority": 65001,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "DenyAllInBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Deny all inbound traffic",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "*",
 "access": "Deny",
 "priority": 65500,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "AllowVnetOutBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Allow outbound traffic from all VMs to all VMs in VNET",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "VirtualNetwork",
 "destinationAddressPrefix": "VirtualNetwork",
 "access": "Allow",
 "priority": 65000,
 "direction": "Outbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "AllowInternetOutBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Allow outbound traffic from all VMs to Internet",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "Internet",
 "access": "Allow",
 "priority": 65001,
 "direction": "Outbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 },
 {
 "name": "DenyAllOutBound",
 "etag": "W/\"9b7736d4-5a76-4804-a63f-6cd1875f1d5c\"",
 "properties": {
 "provisioningState": "Succeeded",
 "description": "Deny all outbound traffic",
 "protocol": "*",
 "sourcePortRange": "*",
 "destinationPortRange": "*",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "*",
 "access": "Deny",
 "priority": 65500,
 "direction": "Outbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 }
 }
 ]
 },
 "dependsOn": []
 },
{
 "type": "Microsoft.Network/publicIPAddresses",
 "sku": {
 "name": "Basic",
 "tier": "Regional"
 },
 "name": "[parameters('publicIPAddresses_PacktVM1_ip_name')]",
 "apiVersion": "2018-02-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "resourceGuid": "972b3091-fe6e-49cc-bd06-22d260608254",
 "ipAddress": "40.74.60.181",
 "publicIPAddressVersion": "IPv4",
 "publicIPAllocationMethod": "Dynamic",
 "idleTimeoutInMinutes": 4,
 "ipTags": []
 },
 "dependsOn": []
 },
{
 "type": "Microsoft.Network/virtualNetworks",
 "name": "[parameters('virtualNetworks_PacktVNet_name')]",
 "apiVersion": "2018-02-01",
 "location": "westeurope",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "resourceGuid": "5a767030-d337-4919-b8c3-b2ee6e23fcda",
 "addressSpace": {
 "addressPrefixes": [
 "10.1.0.0/16",
 "10.2.0.0/16"
 ]
 },
 "subnets": [
 {
 "name": "default",
 "etag": "W/\"98f91850-e7b2-40b6-8043-1caa5bf4865a\"",
 "properties": {
 "provisioningState": "Succeeded",
 "addressPrefix": "10.1.0.0/24",
 "serviceEndpoints": []
 }
 },
 {
 "name": "DMZ",
 "etag": "W/\"98f91850-e7b2-40b6-8043-1caa5bf4865a\"",
 "properties": {
 "provisioningState": "Succeeded",
 "addressPrefix": "10.1.1.0/24",
 "serviceEndpoints": []
 }
 }
 ],
 "virtualNetworkPeerings": [],
 "enableDdosProtection": false,
 "enableVmProtection": false
 },
 "dependsOn": []
 },
{
 "type": "Microsoft.Network/networkSecurityGroups/securityRules",
 "name": "[concat(parameters('networkSecurityGroups_PacktVM1_nsg_name'), '/', parameters('securityRules_default_allow_rdp_name'))]",
 "apiVersion": "2018-02-01",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "protocol": "TCP",
 "sourcePortRange": "*",
 "destinationPortRange": "3389",
 "sourceAddressPrefix": "*",
 "destinationAddressPrefix": "*",
 "access": "Allow",
 "priority": 1000,
 "direction": "Inbound",
 "sourcePortRanges": [],
 "destinationPortRanges": [],
 "sourceAddressPrefixes": [],
 "destinationAddressPrefixes": []
 },
 "dependsOn": [
 "[resourceId('Microsoft.Network/networkSecurityGroups', parameters('networkSecurityGroups_PacktVM1_nsg_name'))]"
 ]
 },
{
 "type": "Microsoft.Network/virtualNetworks/subnets",
 "name": "[concat(parameters('virtualNetworks_PacktVNet_name'), '/', parameters('subnets_default_name'))]",
 "apiVersion": "2018-02-01",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "addressPrefix": "10.1.0.0/24",
 "serviceEndpoints": []
 },
 "dependsOn": [
 "[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworks_PacktVNet_name'))]"
 ]
 },
{
 "type": "Microsoft.Network/virtualNetworks/subnets",
 "name": "[concat(parameters('virtualNetworks_PacktVNet_name'), '/', parameters('subnets_DMZ_name'))]",
 "apiVersion": "2018-02-01",
 "scale": null,
 "properties": {
 "provisioningState": "Succeeded",
 "addressPrefix": "10.1.1.0/24",
 "serviceEndpoints": []
 },
"dependsOn": [
"[resourceId('Microsoft.Network/virtualNetworks', parameters('virtualNetworks_PacktVNet_name'))]"
]
}
]
}

一旦我们在资源组中部署了多个资源，这将特别有帮助。使用这些模板，我们可以自动、快速且精准地配置相同的环境。手动重新部署资源组以重新创建环境可能会导致不一致和漏掉步骤。而使用 ARM 模板，每次都会产生相同的结果。

总结

我们已经覆盖了 Azure 网络的基本功能，包括虚拟网络、IP 地址类型和 NSG。这些关于 Azure 网络的基本知识将成为后续章节的基础。

理解 ARM 模板也非常重要，因为一旦我们的基础设施变得更复杂，它们将非常有帮助。

从这里开始，我们将深入探讨 Azure IaaS，它将使用 Azure 网络作为支撑，并且是将一切整合在一起的服务。我们将展示如何创建高级 VM 场景，这些场景将使用 Azure 网络，私有网络用于 VM 之间的通信，公共网络用于外部访问。我们将更详细地解释如何创建新的 Azure 虚拟机、可用性组以及在 Azure 中为 IaaS 提供高可用性的选项。

问题

1. 哪些服务依赖于 Microsoft Azure 中的 Azure 网络？

   1. IaaS

   2. PaaS

   3. 两者

2. 什么定义了 Azure 中的 IP 地址范围？

   1. 子网掩码

   2. CIDR

   3. RIP

3. 服务端点用于将哪些服务连接到您的虚拟网络？

   1. 虚拟机

   2. PaaS

   3. SaaS

4. Microsoft Azure 中的默认 DNS 服务是…?

   1. Azure DNS

   2. 公共 DNS

   3. 自定义 DNS

5. 什么时候可以添加服务端点？

   1. 创建虚拟网络时

   2. 创建虚拟网络后

   3. 任何时候

6. Azure 中的私有 IP 地址可以是…?

   1. 动态

   2. 静态

   3. 两者

7. Azure 中的公共 IP 地址可以是…?

   1. 动态

   2. 静态

   3. 两者

8. NSG 是什么？

   1. 定义流量流向的安全规则

   2. 关于 IP 地址预留的规则

   3. 两者

9. NSG 定义了什么？

   1. 出站流量规则

   2. 入站流量规则

   3. 两者

10. NSG 不能分配给什么？

    1. 虚拟网络

    2. 网络接口卡（NIC）

    3. 子网

第三章：基础设施即服务 - 云计算的第一层

在我们的云旅程中的下一步是利用 Azure 虚拟机作为 Azure IaaS 的一部分。这是将工作负载转移到云端的第一个逻辑步骤，因为管理 Azure 虚拟机与管理本地虚拟机并无多大不同。虽然我们不再访问虚拟化主机和硬件，但管理 Azure VM 与管理本地服务器或虚拟机没有任何区别。

我们将向您展示如何实现服务的高可用性以及如何扩展工作负载，这是 Microsoft Azure 提供的主要优势之一。

本章涵盖的领域包括：

• 创建 Azure 虚拟机

• 管理 Azure 虚拟机

• 创建 Azure 负载均衡器

• 配置 Azure 负载均衡器

• 创建 Azure 虚拟机规模集

技术要求

本章需要：

• Azure 订阅

部署 Azure 虚拟机

任何 Azure 资源的部署都可以通过多种方式进行，Azure 虚拟机也不例外。我们可以使用 Azure 门户、ARM 模板、Azure PowerShell 或 Azure CLI。我们将讨论所有这些方法，但目前我们将专注于使用 Azure 门户，并偶尔使用 ARM 模板。这是为了更好地了解 Azure 服务以及每次部署创建了什么。其他工具在长远来看也会对我们有所帮助，特别是当我们谈论重新部署和自动化时，但这部分我们稍后再谈。

我们已经快速创建了一个 Azure VM，但这一次我们将更仔细地查看可用的选项，因为上次我们只考虑了 Azure 网络部分作为重点。

创建新的 Azure 虚拟机

要创建新的 Azure VM，我们需要选择新资源并选择新虚拟机。

第一步是为我们的 VM 选择操作系统。Windows 和 Linux 都有数百个可供选择的镜像。重要的是要提到，越来越多的 Linux VM 每天都被部署到 Azure 中。来自 2017 年底的信息告诉我们，超过 40% 的所有 Azure 虚拟机正在运行 Linux，而该百分比可能自那时以来已经增加。

Azure 中支持的 Windows Server 版本有：

• Windows Server 2008 R2 SP1

• Windows Server 2012

• Windows Server 2012 R2

• Windows Server 2016

对于 Linux，有太多版本以至于无法一一列举，但支持的发行版包括：

• Ubuntu

• CentOS

• RHEL

• Kali

• Oracle

所有镜像都可以选择最小安装或预配置安装额外软件。例如，我们可以选择默认设置的 Windows Server 2016 或选择已安装 SQL Server 并且准备好使用的镜像。对于 Linux，我们可以选择最小安装，或者选择已配置好软件如 Chef、Puppet、Jenkins 等的镜像。

还可以选择自定义映像，使用自己选择的配置和软件。这可以是上传到 Azure 的本地虚拟机映像，也可以是从另一个 Azure 虚拟机创建的映像。

选择操作系统后，我们将进入一个新的面板，指导我们完成三个阶段。

基本 Azure 虚拟机信息

第一步是为我们的虚拟机提供基本信息。Azure 中的任何资源都需要提供名称。最好根据过程和角色为资源命名，这将有助于后续管理。当虚拟机的名称能提示其用途时，管理起来会更方便。由于我打算将其用作 web 服务器，因此我会将其命名为WebSrv1。

VM 磁盘类型让我们可以在两种值之间选择——HDD 和 SSD。磁盘类型对虚拟机性能有重大影响，因此选择合适的磁盘类型对我们非常关键。由于磁盘类型也会影响虚拟机的价格，我们需要在预期工作负载的基础上找到平衡。若我们创建的是 web 服务器，选择 HDD 可能就足够了，但如果打算部署数据库服务器，推荐选择 SSD。

用户名选项不允许我们使用如 Admin、Administrator、SysAdmin 等常见服务器用户名。这是为了保护你的云资源。由于大多数带有公网 IP 地址的 Azure 虚拟机可以通过 RDP 访问，因此限制访问非常关键。我有多台虚拟机每天都受到攻击，最常见的攻击就是使用这些用户名。我们可以为虚拟机和用户名应用额外的安全措施，但这些将在后续章节中讨论。

与其他资源类似，我们需要提供虚拟机部署所在的订阅、资源组和位置等信息。这里可以看到一个基本信息的示例：

Azure 虚拟机规格

创建虚拟机的第二步是选择虚拟机的规格。虚拟机的规格将决定三项内容——CPU 数量、内存大小以及操作系统磁盘类型。由于在第一步中也选择了磁盘类型，这将缩小可用选项范围。虚拟机规格有三个不同的定价层级：

• 基础

• 标准

• 低优先级

基础层虚拟机用于开发/测试环境，尽管它们与标准层虚拟机在性能上相似，但有一些限制。它们的 IOPS 比标准层虚拟机低，并且不支持负载均衡或自动扩展。

标准层虚拟机用于生产环境，提供更好的 CPU 和 IOPS 性能。

低优先级虚拟机根据 Azure 数据中心中空闲和未使用的资源分配。它们价格较低，但可能随时不可用，因为微软 Azure 可能会回收这些资源以满足更高优先级的请求。它们主要用于批处理和随机任务。

但定价层级并不是唯一决定虚拟机价格的因素。每个层级都有不同的大小，提供一定数量的 CPU 和内存；数量越高，价格越高。

标准层根据虚拟机的用途有额外的类别：

• 一般用途

• 计算优化型

• 内存优化型

• 存储优化型

• GPU

• 高性能计算

这些大部分都不难理解，一般用途虚拟机有平衡的 CPU 与内存比例，计算优化型有更多的 CPU，内存优化型有更多的内存，存储优化型有最佳的 IOPS。GPU 是专门用于重型图形渲染和视频编辑的虚拟机。高性能虚拟机至少有八个虚拟 CPU，并使用 DDR4 内存。

虚拟机的大小还决定了可以附加到虚拟机的网络接口卡（NIC）的数量。

这个数量从一个到八个不等，具体取决于用途和大小。

可以在以下截图中查看选择虚拟机大小的选项：

高级虚拟机选项

第三部分提供了配置许多额外设置的选项。在上一章中，我们只关注了网络部分，但这一次我们将更仔细地探索这些选项。

高可用性部分提供了两个选项——可用性区域和可用性集。

可用性区域决定了 Azure 数据中心内的区域。这些区域有独立的电源、网络和冷却系统，能够保护你的虚拟机免受数据中心内故障的影响。如果你有需要在多个虚拟机上运行的关键服务，你应该将这些虚拟机放置在不同的可用性区域中，这样如果数据中心级别发生故障，所有虚拟机受到影响的可能性就会减少。

可用性集在主机级别做类似的事情，确保你的虚拟机分布在多个物理服务器、计算机机架、存储单元和网络交换机上。如果发生硬件故障，所有虚拟机受到影响的可能性较小。

请注意，这些可用性选项在后续不能更改。在创建过程中需要定义可用性区域和可用性集。如果你计划设计高可用性解决方案和服务，这一点特别重要。

我将把这个虚拟机放入名为（new）WebSet 的可用性集，因为我打算稍后使用它。

存储选项允许我们选择磁盘类型和使用托管磁盘。磁盘类型选项与之前一样，我们可以选择 HDD 或 SSD。根据所选择的虚拟机大小，并非所有类型的磁盘都可以在此处选择。如果你想选择一个不可用的选项，你需要返回并选择一个不同的虚拟机大小。

使用托管磁盘可以让我们的工作变得更加轻松。这个选项自 2017 年 2 月起提供，在此之前，我们需要自己管理存储。创建一个磁盘实际上是创建一个存储账户，我们需要管理该存储。使用托管磁盘后，我们不必关心这些，所有的管理都会自动完成。虽然存储依然会被创建，但如果选择使用托管磁盘，一切都会在后台处理，无需用户操作。尤其是在扩展虚拟机（或虚拟机规模集）时，这个功能特别有用。托管磁盘还引入了一些非常实用的功能，如快照和备份。我强烈建议使用托管磁盘，因为它可以帮助你获得更好的性能，且管理更简便。

高可用性和磁盘设置可以在下面的截图中看到：

网络选项在前一章中已经讨论过，但我们快速回顾一下这里的选项。我们可以选择虚拟网络（VNet）、该 VNet 上的子网以及虚拟机的公共 IP 地址。最后一个网络选项是选择网络安全组（NSG）用于虚拟机。在下面的截图中，你可以看到我选择了 PacktVNet 和 DMZ（10.1.1.0/24）子网。由于我打算将其作为 Web 服务器使用，所以为我的新虚拟机创建了一个新的公共 IP 地址。由于我已经在 DMZ 子网上应用了 NSG 规则，我不想在虚拟机级别单独设置 NSG。这将帮助我简化管理，并保持所有虚拟机上的标准化规则，因此我会像下面这样保持 NSG 字段为空：

扩展功能使我们可以为虚拟机添加额外的功能。你可以从预设的软件中选择，或者执行自定义脚本来安装额外的软件或功能。

自动关机可以帮助你节省计算时长，如果你不需要虚拟机 24 小时运行。例如，如果这是一个dev环境，且下班后没有人使用它，你可以设置自动关机，每天在下午 5 点关机，这样你就不用为它支付夜间费用。当然，如果这是一个生产环境中的 Web 或数据库服务器，那就不建议使用这个选项。

监控可以启用启动诊断和客户操作系统监控。这是默认情况下提供的基本监控选项之外的功能。启用这两个选项需要一个存储账户来存储日志。避免使用虚拟机磁盘的存储，因为这可能导致性能问题。如果虚拟机在磁盘层面出现性能问题，这将生成更多日志，这些日志将进一步增加存储的负载。这会导致更多的磁盘问题，进入一个无法分辨问题是由磁盘还是日志引起的无限循环。

最后的选项是托管服务标识和备份。托管服务标识允许你使用 Azure Active Directory 来管理虚拟机，而备份将创建一个额外的备份服务（Azure 备份）。这两个服务将在后续章节中详细讨论。

以下截图显示了扩展、自动关机、监控、托管服务标识和备份的选项：

最后，我们可以开始部署，几分钟后便可以开始使用我们的虚拟机。如前所述，创建新虚拟机所需的时间可能取决于虚拟机的大小和 Azure 数据中心中的资源可用性。

管理 Azure 虚拟机

部署完成后，我们可以看到已经创建了四个不同的资源——虚拟机、磁盘、网络接口和公共 IP 地址。公共 IP 地址是可选的，如果你打算仅使用私有 IP 地址并通过 VPN 管理虚拟机，则不需要创建公共 IP 地址。如果没有选择托管磁盘，那么这里也会有一个存储账户，用来存放磁盘，如下所示：

每一个这些资源都有不同的管理选项。我们已经看过了 IP 地址和 NIC 的选项，稍后我们会探讨磁盘和存储的选项。目前，让我们集中关注虚拟机以及可用的管理选项。

虚拟机设置

在虚拟机刀片下，我们有多个选项，如设置、操作、监控和支持。在设置下，我们还有多个选项：网络、磁盘、大小、安全、扩展、可用性集和配置。属性、锁和自动化脚本也适用于所有其他 Azure 资源。请注意，我们这里还有“持续交付（预览）”。预览功能仍在开发中，不能用于生产环境。测试是可以的，但在这些功能正式发布之前，最好不要依赖它们。在这种情况下，持续交付（预览）允许我们连接到 VSTS 项目，并简化 CI/CD 流程。

这里的一些选项与虚拟机创建过程中的选项类似。大小允许我们随时打开刀片，选择不同的虚拟机大小。请注意，要完成此过程，虚拟机需要重启。扩展可以用来添加软件或执行自定义脚本，与之前一样。可用性集仅供参考，因为此设置需要在虚拟机创建时定义。安全性和配置将是我们接下来章节的重点，暂时我们将这些设置保留为默认值。

网络选项为我们提供了关于虚拟机所有网络信息的概览。我们可以看到网卡信息、与虚拟机关联的地址、与虚拟机关联的网络安全组以及所有的 NSG 规则。我们可以在此处附加额外的网卡，并添加额外的 NSG 规则。请注意，在下面的截图中，NSG 应用于子网级别。如果对 NSG 进行更改，这些更改将应用于该子网中的所有虚拟机，因此需要小心。例如，如果这个子网有多个虚拟机，并且我们想为其中的某一个虚拟机允许 RDP 访问，创建这个规则将导致所有虚拟机都可以通过 RDP 访问：

在磁盘刀片下，我们可以看到与虚拟机关联的所有磁盘。操作系统磁盘无法更改，但可以添加或移除数据磁盘。以下截图展示了磁盘刀片的示例：

Azure 虚拟机操作与监控

操作（OPERATIONS）和监控（MONITORING）为我们提供了更多的 Azure 虚拟机管理和操作选项。在操作（OPERATIONS）中，我们有自动关机、备份、灾难恢复、更新管理、清单、变更跟踪和运行命令。我们将现在解释自动关机和运行命令，但这些其他功能需要额外的服务，稍后我们会介绍。

我们在监控（MONITORING）方面有类似的情况，我们现在将介绍“指标”和“警报（经典）”，而其他服务将在后续章节中讲解。

自动关机选项使您可以安排在 Azure 中关闭虚拟机。如前所述，如果我们不需要虚拟机全天运行，这个选项可以帮助我们节省开销。此功能旨在用于 dev/test 环境，而不适用于生产环境。

然而，我也见过一些人将其用于只在工作时间需要的应用程序。在这种情况下，自动关机用于在特定时间关闭虚拟机，并使用 Azure 自动化在工作时间开始前启动虚拟机。除此之外，我们还可以在虚拟机关闭前发送通知，以告知使用该虚拟机的人员即将关闭。我们可以使用电子邮件或 Webhook 进行通知。以下截图展示了 run 脚本选项。我们可以使用各种预设脚本，如 EnableAdminAcount、SetRDPPort、ResetAccountPassword 等等，或者执行自定义脚本。脚本执行选项可以在以下截图中看到：

运行命令可以直接通过门户完成。这在我们无法以其他方式访问虚拟机时（例如，通过移动设备或没有 PowerShell 的机器）非常有用。以下截图展示了启用 PSRemoting 的脚本执行示例：

这里还有一个脚本，用于在 Azure 虚拟机上启用 PSRemote：

Enable-PSRemoting -Force
New-NetFirewallRule -Name "Allow WinRM HTTPS" -DisplayName "WinRM HTTPS" -Enabled True -Profile Any -Action Allow -Direction Inbound -LocalPort 5986 -Protocol TCP
$thumbprint = (New-SelfSignedCertificate -DnsName $env:COMPUTERNAME -CertStoreLocation Cert:\LocalMachine\My).Thumbprint
$command = "winrm create winrm/config/Listener?Address=*+Transport=HTTPS @{Hostname=""$env:computername""; CertificateThumbprint=""$thumbprint""}"
cmd.exe /C $command

监控您的 Azure 资源在多个方面都很重要。它使您能够查看资源的消耗情况，并相应地规划定价层级。如果监控显示您的资源工作负载处于某个百分比以下，可能是时候降低资源层级了。如果情况相反，您的资源长期处于高负载，可能需要更高的层级。提供了许多不同的指标，但对于 CPU 和内存监控，您需要启用客户级别的监控。指标让我们可以根据不同的时间周期改变不同的度量值。下面的截图展示了一个示例，您可以看到过去一小时磁盘 读 和 写 操作的图表：

警报是 Azure 资源管理的重要组成部分，可以在关键时刻救命。在警报中，您可以创建自定义规则，如果激活了定义的触发条件，将通知您。例如，您可以设置警报，当 CPU 使用率在超过 5 分钟的时间段内达到 90% 时，会通知您。类似于自动关机，您可以通过电子邮件或 Webhook 发送通知。

以下截图展示了这个示例：

除了发送通知外，还可以通过使用运行手册或逻辑应用程序设置警报，以触发自定义操作。两者都是在需要时执行自定义操作的强大工具。逻辑应用程序通过工作流图使其易于使用，您可以拖放需要执行的操作，以进行一些维护任务或解决问题。运行手册需要一个 Azure 自动化帐户，并且可以根据预定义的计划或使用自定义脚本执行操作。大多数管理员发现运行手册更有用，因为它们允许您使用 PowerShell 执行任何类型的操作。依我看，两者都非常有用，但管理员更熟悉运行手册，因为他们可以使用 PowerShell，这是他们用于本地管理的工具：

如果我们选择通过运行手册执行某个操作，我们可以选择用户定义的操作或内置操作。使用用户定义的操作时，您需要选择一个自动化帐户，并在该帐户中选择要执行的自定义运行手册。这可以是任何类型的脚本，将在您的 Azure 虚拟机上执行。

内置操作提供了五个选项：重启虚拟机、停止虚拟机、扩展虚拟机、缩减虚拟机和移除虚拟机。以下是一个运行手册配置的示例，其中列出了内置运行手册：

这些操作大多数是显而易见的，但请注意你有扩展虚拟机和缩减虚拟机选项。这允许我们根据需求对资源进行扩展或缩减。云计算的一个好处就是按需付费。因此，如果我们的虚拟机在 90% 的时间里能够处理工作负载，但工作负载偶尔会有高峰，我们就应该避免仅为了满足高峰期而支付更多费用。如果我们为了应对高峰工作负载而永久性地扩展虚拟机，我们就需要支付更多费用，而此时的虚拟机并未充分利用，在 90% 的时间里可能一台价格较低的虚拟机就能应对所有工作负载。设置扩展虚拟机规则可以让你在 CPU 达到 90% 时将虚拟机大小调整到更高的等级，这样就能在阈值达到时应对工作负载并按需增加虚拟机大小。为了充分利用 Microsoft Azure 提供的功能，你需要在另一方向创建一个类似的规则，以便在工作负载减少时进行缩减。当只创建扩展规则时，虚拟机的费用会增加，你最终会支付更多费用。为了防止这种情况，你可以创建一个规则，当 CPU 低于 40% 时执行缩减虚拟机操作，并将虚拟机恢复到原始大小。通过这种方式，你只会在工作负载高峰时支付更多费用，而在工作负载不高时支付更少的费用。

支持 + 故障排除部分为我们提供了一些额外的选项。资源健康和新的支持请求是所有 Azure 资源都有的选项。第一个选项可以在 Azure 数据中心层面上提供有关虚拟机是否存在问题的信息，第二个选项则会将你带到提交 Azure 支持票据的表单。资源健康可以帮助你检查当资源的表现不如预期时的情况。这可以节省你故障排除的时间，避免你浪费精力去弄清楚发生了什么问题，实际上可能是数据中心层面出现了重大问题，而你无法采取任何行动。幸运的是，这种情况并不常见。

启动诊断功能允许你查看虚拟机当前的屏幕和串行日志。当虚拟机没有响应时，它可以非常有帮助，帮助你检查当前的状态。

使用重置密码选项，你可以重置虚拟机的密码，但前提是你知道正确的用户名。一旦你登录虚拟机后，还需要再次重置密码，因为这里使用的密码只是临时的。重置密码还提供了重置远程桌面服务配置的选项。

**串行控制台（预览版）**允许你通过浏览器访问 Windows 串行控制台。不过，这项功能仍处于预览阶段，所以你不应该过于依赖它。

重新部署是一个非常有趣的功能。如果你的虚拟机没有响应，且无法连接，你可以使用这个功能。重新部署虚拟机会将虚拟机迁移到 Azure 数据中心的另一台主机上，尝试解决你的问题。迁移会导致虚拟机重启，而虚拟机本来就没有响应，因此这并不算什么问题，且可能解决你遇到的问题。

这里列出的功能和选项是特定于 Azure 虚拟机的管理选项。虚拟机的管理将继续使用标准管理员工具。我们可以通过 RDP 连接到虚拟机并执行任何我们需要的任务。我们可以为虚拟机安装角色和功能，添加任何第三方软件或我们的自定义软件。其他管理工具，如远程服务器管理工具（RSAT）或 PowerShell，也是可选的。

Azure 负载均衡器

部署 Azure 虚拟机是第一步，但商业关键服务和应用程序怎么办呢？对于这些服务，我们可能希望设计高度可用的解决方案，确保服务级别协议（SLA）和运行时间达到最佳。

这一过程的第一步必须在创建虚拟机时完成，设置可用性区域和可用性集。接下来，我们将在解决方案中添加另一台虚拟机，并选择不同的可用性区域以及相同的可用性集。这将确保虚拟机被放置在 Azure 数据中心的不同区域，并且不依赖于相同的电源、网络和冷却设施。如果 Azure 数据中心出现问题，两个虚拟机受到影响的可能性较小。

设置相同的可用性集将确保虚拟机（VM）被放置在不同的物理服务器、计算机机架、存储单元和网络交换机上。如果发生硬件故障，两个虚拟机同时受到影响的可能性较小。可用性集还会确保微软永远不会进行同时影响两个虚拟机的维护。为了保持 Azure 数据中心的安全并确保最佳性能，必须定期执行维护任务，安装主机更新或升级硬件固件。将虚拟机放入可用性集意味着这些虚拟机是为了实现高可用性而设置的，维护将考虑到这一点，并确保不会同时影响所有虚拟机。

因此，为了实现高可用性，我们需要至少设置两台虚拟机。但流量该如何处理呢？我们如何确定流量是流向第一台还是第二台虚拟机？如果第一台虚拟机不可用，我们如何将流量引导到第二台虚拟机？

这就是 Azure 负载均衡器发挥作用的地方。这是 Azure 的一项网络服务，我们之前略过了它，稍后会在合适的时机进行解释。后续章节中也会有类似的情况。Azure 负载均衡器将前端流量分配到后端池实例。它们可以支持传入和传出场景，具有低延迟和高吞吐量。在这种场景下，传入流量会到达负载均衡器的 IP 地址，然后负载均衡器会将流量分配到配置在后端池中的虚拟机。Azure 负载均衡器可以是内部的或公共的，具体取决于我们需要分配哪种类型的流量。对于 Web 服务器角色，我们可能希望使用公共负载均衡器。但对于数据库服务器，我们可能希望使用内部负载均衡器，因为我们不希望数据库暴露在互联网上。

创建一个 Azure 负载均衡器

要创建一个新的 Azure 负载均衡器，我们需要选择创建一个新资源，并从列表中选择 Azure 负载均衡器。这将打开创建负载均衡器的界面，在此界面中我们需要提供基本信息。

所有资源共有的信息包括名称、订阅、资源组和位置。

Azure 负载均衡器特有的选项包括类型、SKU 和公共 IP 地址。

负载均衡器的类型可以是内部的或外部的，具体取决于您希望路由哪种类型的流量。公共类型必须配置公共 IP 地址，并且我建议您为该 IP 地址配置静态 IP。您还可以选择启用 Azure 负载均衡器的公共 IPv6，而公共 IPv4 是默认设置。

库存单位（SKU）可以是 Basic 或 Standard。Standard 提供更多的选项和功能，但其价格是基于负载均衡规则的数量来形成的。另一方面，Basic 是免费的，唯一的费用来自于预留公共 IP 地址和外发流量。

创建新的 Azure 负载均衡器所需信息的示例如下图所示：

大多数 Azure 网络功能的部署时间都在一分钟以内，Azure 负载均衡器也不例外，部署过程应该非常快速。

配置 Azure 负载均衡器

在 Azure 负载均衡器部署完成后，我们可以进入资源并查看不同的选项。设置项对我们最为重要，我们需要它来配置我们的负载均衡器。我们可以找到所有 Azure 资源共有的标准设置，如属性、锁定和自动化脚本。前端 IP 配置使我们能够管理与负载均衡器关联的 IP 地址，添加新的 IP 地址或移除现有的 IP 地址。其他设置将用于配置负载均衡器以分配传入流量，并配置该流量应该被定向到哪里。

首先，我们需要为负载均衡器配置后端池。我将选择将我的负载均衡器与一个可用性集关联。在本章前面，我创建了一台名为 WebSrv1 的虚拟机，并将其与名为 WebSet 的可用性集关联。然后，我添加了一个名为 WebSrv2 的相同虚拟机，并将其添加到相同的可用性集中。因此，我有两台相同的虚拟机在同一个可用性集中，并且将我的 Azure 负载均衡器与这个可用性集关联。最后，我们需要定义将要使用的网络 IP 配置，并设置它以使用该可用性集中这两台虚拟机。如果我们在此可用性集中有更多虚拟机，还可以设置更多的 IP 配置来进行目标选择。如何设置后端池的示例可以在这张截图中看到：

第二步是设置健康探测。我们需要定义协议、端口、间隔和不健康阈值。协议和端口将定义需要监控的内容。由于我打算使用 WebSrv1 和 WebSrv2 作为 Web 服务器，我将设置对 80 端口的监控。间隔将定义检查的频率，以确保服务器响应。阈值定义了多少个连续的检查未能成功联系到服务器时，将其声明为无响应。如何在 80 端口上设置健康探测的示例可以在这张截图中看到：

由于我想使用 Web 服务器角色，我将在 443 端口上重复相同的操作。在这里的截图中，我们可以看到两个探测都已创建，但“使用者”信息为空：

第三步是创建负载均衡规则。我们需要提供名称、IP 版本、前端 IP 地址、协议、前端端口、后端端口、后端池、健康探测、会话保持性和空闲超时（分钟）。名称和 IP 版本是显而易见的选项，因此我们直接跳到其他选项。

对于前端 IP 地址，你可以选择任何一个负载均衡器的 IP 地址，因为它可以与多个 IP 地址关联。根据选择的 IP 版本，存在一些关于可以选择的 IP 地址的限制。如果 IP 版本设置为 IPv4，则只能选择 IPV4 地址。如果选择了 IPv6，则只能选择与负载均衡器关联的同一版本的 IP 地址。

协议和端口已连接，通过此选项，你可以选择需要从定义的端口转发到定义的后端端口的协议。例如，TCP 协议的 80 端口应转发到 80 端口。

通过后端池，我们定义了流量的转发目标。由于在一个 Azure 负载均衡器中可以有多个后端池，你可以选择这些池中的任何一个。

必须选择健康探测，以便检查虚拟机的状态。你需要选择执行检查的探测器，检查你正在创建的规则中使用的后端端口。

会话保持和空闲超时（分钟）选项与客户端连接的处理方式相关。由于您的后端池中至少有两台虚拟机，因此您需要设置流量在一个会话期间由同一台虚拟机处理。如果您选择来自相同客户端 IP 地址、相同协议的流量，这将保持会话活动。只要会话处于活动状态，客户端将被定向到同一虚拟机。

空闲超时（分钟）决定如果没有采取任何操作，会话将保持活动多长时间。默认值为 4 分钟，但可以更改为最多 30 分钟。通过此设置，您可以确定如果客户端没有使用应用程序并且没有发送任何消息以保持会话活动，连接将保持多长时间。

浮动 IP（直接服务器返回）地址的选项默认情况下是禁用的，应该仅在 SQL AlwaysOn 可用性监听器中使用。

在此屏幕截图中，您可以看到设置负载均衡规则 HTTP 的选项：

我将为端口443创建另一个名为 HTTPS 的规则。请注意，在此屏幕截图中，之前创建的探测现在被负载均衡规则使用：

负载均衡器设置中的最后一个选项是入站 NAT 规则。它具有与负载均衡规则类似的选项，唯一的区别是，在这种情况下，流量不是转发到后端池，而是转发到单个虚拟机。在此屏幕截图中，您可以看到如何设置一个入站 NAT 规则，该规则将流量从端口 5589（WinRM）转发到 WebSrv1：

那么，让我们回顾一下通过设置负载均衡器和可用性集所取得的成果。我们在后端池中有两台虚拟机作为 Web 服务器。虚拟机被放置在不同的可用性区域和相同的可用性集中，以增加至少一台虚拟机运行的机会。健康探测会检查虚拟机是否在定义的端口上可用。如果任何一台虚拟机连续两次未响应，它将被标记为失败。已经设置了一个负载均衡规则，将通过负载均衡器公共 IP 地址传入的流量转发到后端池。如果后端池中的两台虚拟机都健康，流量将根据轮询规则转发。如果健康探测将任何虚拟机标记为未响应，所有流量将转发到健康状态的虚拟机。基于客户端 IP、协议和空闲超时，保持会话存活。来自相同 IP 地址的会话，只要每隔 4 分钟发送一次保持活动信号，将会被转发到相同的虚拟机。

这将确保我们的应用程序始终运行，即使某个虚拟机发生故障。故障可能是由于 Azure 数据中心的硬件或网络错误引起的（可用性区域和可用性集确保两个虚拟机不会受到影响）。将更多虚拟机放入可用性集和后端池可以增加至少一个虚拟机正常运行的机会。

Azure 负载均衡器 ARM 模板

这是创建一个新的 Azure 负载均衡器的 ARM 模板：

{
"$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"name": {
"type": "string"
},
"location": {
"type": "string"
},
"sku": {
"type": "string"
},
"publicIPAddressName": {
"type": "string"
}
},
"resources": [
{
"apiVersion": "2017-08-01",
"name": "[parameters('name')]",
"type": "Microsoft.Network/loadBalancers",
"location": "[parameters('location')]",
"sku": {
"name": "[parameters('sku')]"
},
"dependsOn": [
"[concat('Microsoft.Network/publicIPAddresses/', parameters('publicIPAddressName'))]"
],
"properties": {
"frontendIPConfigurations": [
{
"name": "LoadBalancerFrontEnd",
"properties": {
"publicIPAddress": {
"id": "[resourceId('test', 'Microsoft.Network/publicIPAddresses', parameters('publicIPAddressName'))]"
}
}
}
]
}
},
{
"apiVersion": "2017-08-01",
"type": "Microsoft.Network/publicIPAddresses",
"name": "[parameters('publicIPAddressName')]",
"location": "[parameters('location')]",
"sku": {
"name": "[parameters('sku')]"
},
"properties": {
"publicIPAllocationMethod": "Dynamic",
"publicIPAddressVersion": "IPv4"
}
}
]
}

Azure 虚拟机规模集

弹性是云计算的一大优势。我们可以根据工作负载和需求进行扩展和缩减。如果工作负载增加，我们就扩展；如果工作负载减少，我们就缩减。采用按需付费和按分钟计费的定价模式，这使我们能够节省成本。

我们已经解释了如何在 Microsoft Azure 中设置虚拟机的扩展和缩减。扩展和缩减是指将虚拟机的大小调整为更大或更小的实例。这被称为垂直扩展。这种方式非常有用，但也有一个后果——每次更改虚拟机大小时，都会发生重启。因此，垂直扩展可以增加虚拟机的大小以处理更多的工作负载，但它总会在虚拟机重启期间导致停机。

解决方案是横向扩展，对于 Azure 虚拟机，我们可以使用 Azure 虚拟机规模集。与其调整虚拟机的大小，规模集通过创建虚拟机的额外实例，并使用 Azure 负载均衡器将工作负载分配到这些实例上。这个过程称为横向扩展。该方法类似于高可用性场景，但不同之处在于，规模集不是在可用性集中创建多个虚拟机，而是根据工作负载启动虚拟机，并且仅在需要时启动它们。另一个区别是，在可用性集中，虚拟机是独立的，一个虚拟机的问题不会影响到其他虚拟机。而在规模集中，所有虚拟机都复制了主虚拟机，如果主虚拟机出现故障，问题将反映到整个规模集。我们需要指出，规模集并不是一个高可用性解决方案，而是基于工作负载的横向扩展。

创建一个 Azure 虚拟机规模集

让我们创建一个新的 Azure 虚拟机规模集，并在过程中解释所有细节。

要创建一个新的 Azure 虚拟机规模集，所有信息都在一个屏幕中提供。为了让它更加清晰可见，我将屏幕分为三张图片——基本信息和实例、自动缩放、以及网络配置。

规模集的基本信息与虚拟机的基本信息非常相似。这是合乎逻辑的，因为规模集首先创建一个主虚拟机，然后克隆该虚拟机以进行横向扩展。我们需要提供虚拟机规模集名称、操作系统磁盘映像、订阅、资源组、位置、用户名、密码，并可以选择添加可用性区域。

接下来，我们创建实例规则。这将决定规模集中的虚拟机（VM）的大小以及规模集允许创建的实例数量。对于 Azure 提供的操作系统镜像，允许的最大实例数为 1,000 个；对于自定义操作系统镜像，最大实例数为 300 个。如果应用程序出现问题，并且应用程序本身导致 CPU 或内存过高，这将导致规模集扩展并创建新的实例。由于新实例是主虚拟机的完全副本，因此问题将在这些虚拟机上持续存在，扩展将继续，直到达到最大实例数。重要的是要设置实例数量为您实际准备支付的数量，因为即使是短时间内启动 1,000 个虚拟机也可能带来巨大的财务影响。

将规模集虚拟机部署为低优先级虚拟机可以为您节省最多 80% 的费用。低优先级虚拟机使用 Azure 数据中心中分配的未使用资源创建，但这些资源可以被更高优先级的资源抢占，并且可能随时不可用。因此，尽管此选项可以帮助您节省大量费用，但资源在需要时可能无法提供。此选项不应用于需要随时可用的服务，或关键服务。建议仅将低优先级用于低优先级服务或批处理任务。

规模集创建了多个虚拟机实例，并且所有这些虚拟机都有各自的磁盘。在扩展过程中管理这些磁盘和存储账户，尤其是当我们启动 1,000 个实例时，可能会非常具有挑战性。我建议使用 Azure 自动管理的托管磁盘，这样您就不必担心这一部分。

基本设置和实例设置的示例如下图所示：

自动扩展创建了一组规则，定义了规模集如何进行扩展和收缩。我们需要设置规模集中的虚拟机最小和最大数量。最大数量会根据之前设置的实例数量自动收集，但不一定必须相同。实例数量决定了最初要创建多少虚拟机，而最大数量则决定了可以创建多少虚拟机。

我们创建了扩展和收缩规则，这些规则将增加和减少规模集中的虚拟机数量。例如，如果 CPU 使用率达到 75%，则会启动额外的虚拟机。如果使用率降到 25%以下，则会减少规模集中的虚拟机数量。将添加/移除的虚拟机数量可以单独设置。

假设我们将虚拟机的最小数量设置为 1，实例数量设置为 10，最大虚拟机数量设置为 100。当扩展集创建时，它将创建 10 个虚拟机副本并只启动其中一个副本，作为主副本。当触发扩展阈值时，它将向扩展集添加一个新的虚拟机。这个虚拟机是最初创建的 10 个虚拟机之一。如果利用率继续上升，它将继续添加新的虚拟机，直到达到 10 个虚拟机。如果最大虚拟机数量与实例数量不同，则将创建并启动新的虚拟机。前 10 个虚拟机和后续虚拟机的区别在于，最初的虚拟机已创建，只需要启动。额外的虚拟机需要先进行配置，再启动，这使得扩展过程变得较慢。然而，即使虚拟机未运行，初始虚拟机也会产生费用，因为即使虚拟机关闭，您也需要为磁盘付费。最好在初始虚拟机数量和最大虚拟机数量之间找到一个平衡。自动扩展（AUTOSCALE）在以下截图中展示：

网络（NETWORKING）部分让我们可以选择应用程序网关（Application Gateway）和负载均衡器（Load balancer）之间的选项。无论选择哪一个，它将作为您的用户的终端，并自动将流量分配到 Azure 虚拟机扩展集中。Azure 虚拟机的负载均衡器是免费的，而应用程序网关按小时计费，但支持许多附加功能。应用程序网关支持 SSL 终止、基于 URL 的路由、多站点路由、基于 cookie 的会话亲和性、Web 应用防火墙和可路由的 IP 地址。

使用负载均衡器时，应用于可用性集和扩展集的负载均衡器的区别在于，扩展集不需要额外的管理（您可以选择设置额外的规则和设置，但这不是必需的）。负载均衡规则和将虚拟机添加到后端池的操作是自动完成的，用户无需任何操作。以下是使用 Azure 负载均衡器的网络设置示例，见下图：

Azure 虚拟机扩展集的部署依赖于许多不同的参数。扩展集所需的网络服务必须在虚拟机之前部署，但这一过程非常快速。然后，虚拟机被部署，根据实例数量和虚拟机大小，这可能需要一些时间。部署少量大型实例可以相对快速完成，但如果部署数百个小虚拟机，可能需要长达一小时。

管理 Azure 虚拟机扩展集

部署完成后，会在我们的资源组中创建多个资源，我们可以看到虚拟机规模集以及一组与网络相关的资源。创建的网络资源包括负载均衡器、公共 IP 地址（由负载均衡器使用）、虚拟网络和网络安全组。NSG（网络安全组）应用于子网级别，并且 NSG 规则将对规模集中的所有虚拟机生效。这是合理的，因为所有虚拟机都是相同的，均由同一个应用程序使用，并且具有相同的用途。我们可以在这里的截图中看到为我们的规模集创建的所有资源：

由于我们已经讨论过所有涉及的网络功能，接下来我们将重点关注虚拟机规模集以及用于管理它的选项。许多选项与虚拟机设置相同，例如大小、持续交付（预览版）、配置、属性、锁定和自动化脚本。对规模集独有的设置包括实例、扩展、存储和操作系统。操作系统仅供参考，我们只能看到如用于创建规模集的映像和操作系统版本等信息。

存储设置还为我们提供了有关所使用存储类型和磁盘的信息，并且只有一个可供选择的选项——缓存。可用选项包括无、只读和读/写。

实例选项卡显示了规模集中的所有虚拟机及其状态。我们可以看到哪些虚拟机正在运行，并执行不同的操作，如启动、停止、取消分配和删除。特别有趣的选项是重新映像和升级。重新映像将重置选定虚拟机的所有设置，并将其恢复为默认版本。升级将手动将选定虚拟机升级到最新的更改。规模集中的所有虚拟机都是主虚拟机的完全复制品，如果主虚拟机发生更改，这些更改将及时复制到所有实例。升级选项使我们能够手动执行升级，并立即强制应用更改。当规模集中有大量虚拟机时，这非常有用，因为复制更改需要时间，而更改可能需要尽快应用。然而，重新映像和升级选项都会在过程中重启虚拟机，因此也需要考虑这一点。最后，Azure 虚拟机规模集中独有的选项是扩展，但详细解释这一选项还需要一些时间。

扩展选项卡向我们展示了所有有效的扩展规则，这些规则适用于我们的规模集。如果规则是在部署过程中创建的，它们将显示在此处，我们可以编辑或删除它们。也可以创建附加规则，我们可以监控多个参数。例如，我们可以为 CPU、内存和磁盘使用率创建单独的规则。如果触发任何这些规则，它将执行相应的扩展或收缩过程。创建更多的扩展规则能为我们提供更好的灵活性和性能，因为我们不再依赖于单一的点。如果我们只监控 CPU，但遇到内存问题，则无法扩展，性能也会下降。如果我们监控内存，但磁盘使用率很高，同样不会发生自动扩展，性能也会下降：

在讨论 Azure 虚拟机规模集时，有两点非常重要。规模集与可用性集是非常不同的。在可用性集中，我们保持一个固定数量的虚拟机，以提高至少一台虚拟机始终可用并实现高可用性的概率。规模集则监控工作负载，并根据需求增加虚拟机的数量，但所有虚拟机都是副本，任何问题都可能导致所有虚拟机都复制该问题。

另一个需要明确的事项是我们可以在什么场景下使用 Azure 虚拟机规模集。由于规模集中的所有虚拟机都是初始映像的副本，任何更改都会从初始映像同步到所有其他虚拟机。但这个过程是单向的，新增实例上的更改不会应用到其他地方。因此，Azure 虚拟机规模集不适合像 SQL Server 或 Exchange Server 这样的角色，这些角色要求更改必须应用到所有实例。相反，应将规模集用于应用场景，这些场景中的更改不是由用户会话引起的，且数据会随着时间的推移保持持久。

Azure 虚拟机规模集 ARM 模板

此外，以下是用于部署新 Azure 虚拟机规模集的 ARM 模板：

{
 "$schema": "http://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json",
 "contentVersion": "1.0.0.0",
 "parameters": {
 "vmSku": {
 "type": "string",
 "defaultValue": "Standard_D1",
 "metadata": {
 "description": "Size of VMs in the VM Scale Set."
 }
 },
 "vmssName": {
 "type": "string",
 "metadata": {
 "description": "String used as a base for naming resources. Must be 3-61 characters in length and globally unique across Azure. A hash is prepended to this string for some resources, and resource-specific information is appended."
 },
 "maxLength": 61
 },
 "instanceCount": {
 "type": "int",
 "metadata": {
 "description": "Number of VM instances (100 or less)."
 },
 "defaultValue": 2,
 "maxValue": 100
 },
 "adminUsername": {
 "type": "string",
 "metadata": {
 "description": "Admin username on all VMs."
 }
 },
 "adminPassword": {
 "type": "securestring",
 "metadata": {
 "description": "Admin password on all VMs."
 }
 }
 },
 "variables": {
 "vnetName": "vnet",
 "subnetName": "subnet",
 "subnetRef": "[resourceId('Microsoft.Network/virtualNetworks/subnets', variables('vnetName'), variables('subnetName'))]",
 "publicIPAddressName": "pip",
 "loadBalancerName": "loadBalancer",
 "loadBalancerFrontEndName": "loadBalancerFrontEnd",
 "loadBalancerBackEndName": "loadBalancerBackEnd",
 "loadBalancerProbeName": "loadBalancerHttpProbe",
 "loadBalancerNatPoolName": "loadBalancerNatPool"
 },
 "resources": [
 {
 "type": "Microsoft.Compute/virtualMachineScaleSets",
 "name": "[parameters('vmssName')]",
 "location": "[resourceGroup().location]",
 "apiVersion": "2017-03-30",
 "dependsOn": [
 "[concat('Microsoft.Network/virtualNetworks/', variables('vnetName'))]",
 "[resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName'))]"
 ],
 "sku": {
 "name": "[parameters('vmSku')]",
 "capacity": "[parameters('instanceCount')]"
 },
 "properties": {
 "overprovision": "true",
 "upgradePolicy": {
 "mode": "Manual"
 },
 "virtualMachineProfile": {
 "storageProfile": {
 "osDisk": {
 "createOption": "FromImage",
 "caching": "ReadWrite"
 },
 "imageReference": {
 "publisher": "MicrosoftWindowsServer",
 "offer": "WindowsServer",
 "sku": "2016-Datacenter",
 "version": "latest"
 }
 },
 "osProfile": {
 "computerNamePrefix": "[parameters('vmssName')]",
 "adminUsername": "[parameters('adminUsername')]",
 "adminPassword": "[parameters('adminPassword')]"
 },
 "networkProfile": {
 "networkInterfaceConfigurations": [
 {
 "name": "nic",
 "properties": {
 "primary": true,
 "ipConfigurations": [
 {
 "name": "ipconfig",
 "properties": {
 "subnet": {
 "id": "[variables('subnetRef')]"
 },
 "loadBalancerBackendAddressPools": [
 {
 "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('loadBalancerName'), '/backendAddressPools/', variables('loadBalancerBackEndName'))]"
 }
 ],
 "loadBalancerInboundNatPools": [
 {
 "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('loadBalancerName'), '/inboundNatPools/', variables('loadBalancerNatPoolName'))]"
 }
 ]
 }
 }
 ]
 }
 }
 ]
 }
 }
 }
 },
 {
 "type": "Microsoft.Network/virtualNetworks",
 "name": "[variables('vnetName')]",
 "location": "[resourceGroup().location]",
 "apiVersion": "2017-04-01",
 "properties": {
 "addressSpace": {
 "addressPrefixes": [
 "10.0.0.0/16"
 ]
 },
 "subnets": [
 {
 "name": "[variables('subnetName')]",
 "properties": {
 "addressPrefix": "10.0.0.0/24"
 }
 }
 ]
 }
 },
 {
 "type": "Microsoft.Network/publicIPAddresses",
 "name": "[variables('publicIPAddressName')]",
 "location": "[resourceGroup().location]",
 "apiVersion": "2017-04-01",
 "properties": {
 "publicIPAllocationMethod": "Dynamic",
 "dnsSettings": {
 "domainNameLabel": "[toLower(parameters('vmssName'))]"
 }
 }
 },
 {
 "type": "Microsoft.Network/loadBalancers",
 "name": "[variables('loadBalancerName')]",
 "location": "[resourceGroup().location]",
 "apiVersion": "2017-04-01",
 "dependsOn": [
 "[concat('Microsoft.Network/publicIPAddresses/', variables('publicIPAddressName'))]"
 ],
 "properties": {
 "frontendIPConfigurations": [
 {
 "name": "[variables('loadBalancerFrontEndName')]",
 "properties": {
 "publicIPAddress": {
 "id": "[resourceId('Microsoft.Network/publicIPAddresses', variables('publicIPAddressName'))]"
 }
 }
 }
 ],
 "backendAddressPools": [
 {
 "name": "[variables('loadBalancerBackendName')]"
 }
 ],
 "loadBalancingRules": [
 {
 "name": "roundRobinLBRule",
 "properties": {
 "frontendIPConfiguration": {
 "id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName')), '/frontendIPConfigurations/', variables('loadBalancerFrontEndName'))]"
 },
 "backendAddressPool": {
 "id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName')), '/backendAddressPools/', variables('loadBalancerBackendName'))]"
 },
 "protocol": "Tcp",
 "frontendPort": 80,
 "backendPort": 80,
 "enableFloatingIP": false,
 "idleTimeoutInMinutes": 5,
 "probe": {
 "id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName')), '/probes/', variables('loadBalancerProbeName'))]"
 }
 }
 }
 ],
 "probes": [
 {
 "name": "[variables('loadBalancerProbeName')]",
 "properties": {
 "protocol": "Tcp",
 "port": 80,
 "intervalInSeconds": "5",
 "numberOfProbes": "2"
 }
 }
 ],
 "inboundNatPools": [
 {
 "name": "[variables('loadBalancerNatPoolName')]",
 "properties": {
 "frontendIPConfiguration": {
 "id": "[concat(resourceId('Microsoft.Network/loadBalancers', variables('loadBalancerName')), '/frontendIPConfigurations/', variables('loadBalancerFrontEndName'))]"
 },
 "protocol": "Tcp",
 "frontendPortRangeStart": 50000,
 "frontendPortRangeEnd": 50019,
 "backendPort": 3389
 }
 }
 ]
 }
 }
 ]
}

摘要

我们已经涵盖了基本的 IaaS 概念，以及如何设置 Azure 虚拟机。扩展 IaaS 场景的逻辑步骤是涵盖高可用性，我们通过 Azure 负载均衡器和可用性集成功地实现了这一目标。

云计算的一个关键概念是弹性和按需资源。我们展示了如何实现垂直扩展（通过警报和自定义操作）和水平扩展（通过 Azure 虚拟机规模集）。

在下一章中，我们将进入 PaaS 模型，并探索 Azure 应用服务，相比于 Azure 虚拟机，它提供了更抽象的模型。应用服务为我们提供了一些独特的选项，这些选项将帮助我们在云端之旅中取得进展，但相比虚拟机，它对基础设施的控制较少。我们将比较 IaaS 功能与 PaaS 的关系，并探索如何通过应用服务实现扩展和高可用性。

问题

1. 支持 Azure 虚拟机的最旧版本 Windows Server 是哪个？

   1. Windows Server 2003

   2. Windows Server 2008 R2 SP1

   3. Windows Server 2012 R2

2. 基础层虚拟机支持什么？

   1. 较低的 IOPS

   2. 负载均衡器

   3. 自动扩展

3. 低优先级虚拟机的用途是什么？

   1. 高可用性

   2. 批处理

   3. 平衡的工作负载

4. 在 Azure 虚拟机刀片中设置大小用于…？

   1. 向上扩展

   2. 缩减规模

   3. 两者

5. 运行手册可以用于执行什么？

   1. 维护任务

   2. 虚拟机的横向和纵向扩展

   3. 两者

6. Azure 负载均衡器用于…？

   1. 在后端池中分配流量到虚拟机

   2. 隔离流量并防止对虚拟机的攻击

   3. 两者

7. 将虚拟机放置在同一可用性集中将导致…？

   1. 虚拟机将被创建在不同的 Azure 数据中心

   2. 虚拟机将被放置在不同的机架上

   3. 虚拟机将被放置在同一机架上

8. 通过创建虚拟机的额外实例来扩展规模被称为…？

   1. 向上扩展

   2. 缩小规模

   3. 横向扩展

9. 横向扩展是…的例子？

   1. 纵向扩展

   2. 水平扩展

   3. 对角线扩展

10. 横向扩展 Azure 虚拟机我们使用…？

    1. 可用性区域

    2. 可用性集

    3. 扩展集

第四章：Azure 应用服务 - 无服务器托管 Web 应用程序

我们云端之旅的下一步是 PaaS，我们将介绍 Azure 应用服务。Azure 应用服务是 Azure PaaS 最简单的例子，旨在托管 Web 应用程序。我们将了解在 IaaS 和 PaaS 中托管应用程序的区别。

本章将涵盖以下内容：

• Azure 应用服务计划

• Azure Web 应用

• 流量管理器

• 应用服务环境

技术要求

本章需要一个 Azure 订阅。

Azure 应用服务计划和 Azure Web 应用

Azure 中的 PaaS（或任何公共云中的 PaaS）比 IaaS 更抽象。理解 IaaS 模型很简单，因为它与本地环境没什么不同：我们创建虚拟机，按照我们的方式进行配置，安装我们需要的软件（当然，也受限于操作系统本身；我们不能安装一些无法在本地运行的东西）。

在我们创建 Azure 虚拟机后，我们对该虚拟机上的所有内容拥有完全的控制权。例如，在上一章创建的虚拟机旨在作为 web 服务器使用。我们可以连接到该虚拟机并安装所有所需的角色、功能和软件，以开始托管我们的应用程序。

那么，如果我们想用 PaaS 做类似的事情怎么办？

Azure 应用服务计划用于在 Azure 中托管我们的 web 应用程序。我们需要创建一个 Azure 应用服务计划，然后为我们的应用程序添加 Azure Web 应 s。一个应用服务计划可以托管多个 Azure Web 应用。如果我们在 web 服务器上安装 IIS，我们也可以托管多个应用。应用服务计划可以与 IIS 类比，但有一个重要区别：使用 IIS，我们可以完全控制配置，而使用应用服务计划，我们只能选择有限的选项。这本质上是 IaaS 和 PaaS 之间的区别。

控制权减少意味着维护工作也减少，因为许多在本地环境中需要执行的任务现在已经自动化，我们不需要担心它们。例如，在本地环境中必须定期安装更新，以确保一切保持最新并保持安全。而在 PaaS 中，我们不需要安装任何更新，因为这会在主机级别自动完成。

创建应用服务计划

我们从创建一个新的应用服务计划开始。与所有 Azure 资源类似，我们需要提供名称、订阅、资源组和位置。其他可用选项是操作系统和定价层。操作系统的选项有 Windows 和 Linux。以下截图展示了创建新应用服务计划所需的所有信息示例：

应用服务计划定价层的默认值是 S1 标准或标准 1。如果我们更改此值，将会打开一个新的面板，提供更多选项。以下截图展示了应用服务计划定价面板：

App Service 计划定价分为三个部分：

• 开发/测试

• 生产环境

• 隔离

开发/测试适用于开发/测试环境中的小型工作负载。它有不同的大小：F1、D1 和 Basic（B1、B2 和 B3）。F1 是免费的，基于共享基础设施，每天的计算时间有限，并且不支持自定义域名。D1 每天有更多的计算时间，并支持自定义域名。Basic 层有专用基础设施，并支持自定义域名、SSL 和手动扩展。

生产环境适用于更大工作负载的生产环境。它提供标准和高级层，每个层都有额外的大小（S1、S2、S3、P1、P2、P3、P1v2、P2v2 和 P3v2）。生产部分的所有大小都带有额外的功能，如自动扩展、插槽、备份和流量管理器支持。App Service 计划可用的资源量取决于大小，因为每个大小有不同的内存和核心数。即使 Basic 层不适用于生产环境，这也同样适用。标准层和高级层之间的主要区别在于磁盘类型，标准层使用标准存储（HDD），而高级层使用高级存储（SSD）。高级层还可以分为 v1 和 v2，其中 v2 使用不同的处理器类型并具有更多的内存。

在创建了 App Service 计划后，你可以开始添加 Web 应用。重要的是要说明，你可以将多个 Web 应用添加到单个 App Service 计划中。计费是在 App Service 计划级别进行的，你为整个 App Service 计划付费，而不是为每个单独的应用付费。每个 App Service 计划可以添加的应用数量取决于层和大小。

创建 Azure Web 应用

要创建一个新的 Azure Web 应用，需要提供的标准值包括应用名称、订阅、资源组和 Application Insights 位置。其他必需的值包括操作系统、App Service 计划/位置和 Application Insights。操作系统的可选值包括 Windows、Linux 和 Docker。具体值将取决于你要运行的应用类型。在 App Service 计划/位置中，你可以创建一个新的 App Service 计划或使用现有的。

App Service 计划/位置将决定你的 Web 应用的位置，因为它需要与关联的 App Service 计划位于相同的位置。最后，我鼓励启用 Application Insights，因为这将让你更好地监控和报告应用的使用情况和性能。

创建 Web 应用所需的所有信息示例如下图所示：

部署完成后，我们可以看到以下资源已创建：App Service 计划、App Service 和 Application Insights。这可能有些令人困惑，因为在创建资源时和资源实际创建后使用了不同的名称。App Service 计划在两种情况下都是 App Service 计划。

在 Web 应用程序的情况下，名称是不同的。当你想创建一个新的 Web 应用时，面板会显示 Web 应用的名称，但在创建后你会看到它作为应用服务。总结来说，应用服务计划被称为应用服务计划，而 Web 应用则被称为 Web 应用和应用服务：

管理 Azure Web 应用

资源部署完成后，我们需要进行配置。由于我们无法直接访问，也不能安装软件、角色或功能，我们有一组可编辑的预配置设置。相比虚拟机面板，应用服务面板中有更多的选项，但总体而言，由于无法进行直接配置，我们的选择会较少。

让我们从 Azure Web 应用程序开始，然后继续配置。

Azure Web 应用部署设置

Azure Web 应用的第一组选项是部署。快速入门为我们提供了指向各种文档和指南的链接。

我们可以设置用于部署和 FTP 访问的部署凭据：

部署插槽是一个非常有趣的功能，它允许我们为应用程序创建多个环境。插槽是独立的环境，但也可以用于交换应用程序版本。要创建一个新的插槽，我们选择“添加插槽”，然后提供名称和配置源。配置源可以是现有的插槽之一（选定插槽的配置将被克隆），或者我们可以选择不克隆并保留默认值。添加新插槽的示例如下图所示：

插槽的名称将由应用程序名称和插槽名称组成。例如，我创建了两个插槽：staging 和 test。如下图所示：

一个很棒的功能是交换槽位的选项。例如，我们可以运行一个生产槽，并将所有用户指向此槽位来使用应用程序。我们可以在不同的槽位上进行部署和测试，这不会影响用户当前使用的生产版本。一旦我们测试完毕，就可以将新版本部署到暂存槽。交换槽位的选项使我们能够在几秒钟内在旧的生产版本和新版本之间切换，且对用户的影响最小。当我们点击交换时，暂存中的一切将变成生产版本，旧的生产版本变为暂存。槽位之间的设置不会改变，因此，暂存槽可以使用与生产环境不同的数据库。例如，另一个很棒的功能是我们也可以进行反向交换。即使我们已经进行测试和验证，用户可能会在新版本的应用程序中遇到问题和错误。在这种情况下，我们只需切换回之前的生产版本，将其从暂存槽移动到生产槽，并将新版本从生产槽移到暂存槽。这将允许用户继续使用上一个稳定版本的应用程序，同时我们可以在暂存槽中检查和排查问题。一旦解决了问题，只需再次交换，新的版本就会回到生产环境。

以下截图展示了一个槽位交换的示例：

部署选项和部署中心（预览版）为您提供了连接到代码仓库的选项。最常见的仓库是默认选项，如 Visual Studio Team Services、GitHub 或 Bitbucket。像 OneDrive 或 Dropbox 这样的文件共享也是一个选项，您也可以链接到自定义的外部仓库，比如本地 Git 仓库或团队基础服务器。不同之处在于，除了连接仓库之外，部署中心（预览版）还为您提供了建立持续集成/持续交付管道的选项。以下截图展示了部署选项的源：

Azure Web App 一般设置

Azure Web 应用设置与其他 Azure 服务有一些相似功能，例如属性和锁定。此外，大多数 Azure 服务都有“扩展”（应用服务计划）和/或“扩展”（应用服务计划）选项。一些独特的设置包括应用设置、身份验证/授权、应用洞察、托管服务身份、备份、自定义域名、SSL 设置、网络、WebJobs、推送通知和 MySQL In App。网络选项允许我们将 Web 应用连接到 Azure VNet，甚至创建与本地环境的混合连接。WebJobs 允许我们创建可以按计划执行或由事件触发的后台进程。推送通知通常用于移动应用程序，以向正在运行应用程序的移动设备发送各种通知，例如新闻、更新等。MySQL In App 创建一个 MySQL 实例，供应用程序使用。

然而，这适用于小型工作负载，我不建议除了用于开发和测试之外使用它。以下截图显示了所有设置的列表：

常规设置提供了一组预配置的选项，允许我们更改框架版本和应用程序所需的其他设置。例如，我们可以在不同版本的 .NET、PHP、Python 或 Java 之间切换。我们还可以在 32 位和 64 位平台之间切换，打开或关闭 Websockets，设置托管管道版本为经典或集成等。

有一个非常重要的选项始终处于开启状态，我强烈建议您将其设置为开启。如果应用程序在一段时间内未使用，首次连接可能需要一些时间。例如，如果应用程序在工作时间内使用，早晨首次使用时可能需要一些时间才能连接，因为应用程序在晚上未使用。设置为始终开启会定期 ping 应用程序，保持其活跃。这样，无论何时用户尝试连接，应用程序都会准备就绪，不会有等待时间：

身份验证/授权选项允许我们为应用程序设置用户登录。默认选项为匿名访问，但我们可以设置 Azure Active Directory、Microsoft Live 账户、Facebook、Google 和 Twitter。托管服务身份允许应用程序在 Azure Active Directory 中注册，并使用该注册与 Azure Active Directory 中的其他应用程序进行通信。以下是身份验证/授权面板中显示的身份验证提供者列表：

备份选项允许我们为应用程序创建备份。我们需要提供存储设置（备份将存储在哪个存储账户）、备份计划和保留期。默认的保留期为 30 天，默认计划为每天一次，但您可以更改这些设置。如果您设置了与代码仓库的连接，则此选项并不真正必要，因为您可以随时重新部署应用程序，但如果您希望快速恢复，或者如果您没有使用代码仓库，它是一个有用的功能：

自定义域名、证书和扩展

自定义域名和 SSL 设置使我们能够自定义应用程序的 URL，并应用证书来加密连接并提高安全性。这些设置是直接关联的，因为没有自定义域名，您无法为 Web 应用应用有效的 SSL 证书。

默认情况下，Azure Web 应用的 URL 为 customname.azurewebsites.net（其中 customname 是您在创建 Web 应用时提供的名称）。为了简化访问，您可以使用已经拥有的自定义 URL，或者购买一个新的域名。甚至可以通过 Azure 门户购买新域名，但该服务并非由微软提供，而是由合作伙伴提供。如果您通过 Azure 门户购买新域名，这将被添加到您的 Azure 账单中。

为了设置自定义域名，需要验证域名所有权。通过在您的 DNS 中添加 CNAME（customname.azurewebsites.net）或记录（Azure Web 应用 IP 地址）来完成此验证，这将把您的自定义域名指向 Azure Web 应用。一旦验证完成，您只需确认是否希望使用该域名为您的 Azure Web 应用。此外，您还可以将网站设置为仅使用 HTTPS，以提高安全性，特别是当您使用 SSL 时。有关 CNAME 和需要添加的 IP 地址的信息，这些信息用于验证所有权，并在稍后指向您的网站，您可以在此页面找到：

SSL 配置允许我们重新设置为仅支持 HTTPS。我强烈建议在可能的情况下使用此选项。另一个安全选项是最低 TLS 版本，您可以在 1.0、1.1 和 1.2 之间进行选择。建议使用 TLS 1.2，因为如果不使用，可能会被报告为不安全。绑定选项允许您将自定义域名与可用证书配对。由于您可以让更多自定义域名指向同一个网站，因此所有启用 SSL 的域名将显示在列表中，如下所示：

SSL 设置下的证书部分允许您管理网站的证书。您可以选择导入应用服务证书或上传证书。应用服务证书是允许您通过 Azure 门户购买证书并将该证书用于您的应用程序的选项。此证书将对租户中的所有应用程序可用。上传证书选项允许您上传已有的证书，或上传您从外部来源购买的证书。证书会根据您上传或导入的证书类型显示在公共或私有列表中。您还可以根据需要请求客户端证书。所有证书选项如以下截图所示：

Azure Web 应用的自动缩放与虚拟机规模集（VMSS）类似。在“扩展”部分，您可以找到一个与 VMSS 中的扩展面板相同的面板。为了配置扩展规则，您需要设置扩展和缩减的参数。例如，您可以设置 Web 应用，当 CPU 超过 70% 时，添加一个额外实例；而当 CPU 降低到 25% 以下时，减少实例数量。您可以设置最小、最大和默认实例数。还可以添加更多扩展和缩减规则，根据不同的指标进行扩展或缩减。这将帮助您节省成本，并且仅运行所需的最少实例数量，避免性能问题。以下截图显示了扩展条件的示例：

Azure Web App 工具

Azure Web 应用有一些独特的工具，专门针对该服务：开发工具、移动和 API。

开发工具以“克隆应用”选项开始，该选项允许我们创建一个新的 Web 应用实例，该实例将与现有的应用程序完全相同。然而，此选项仅限于高级等级，如果您使用的是其他等级，则该选项不可用，除非您进行升级。控制台为您提供了对控制台的 Web 访问，您可以在其中浏览文件并执行命令行操作。

高级工具会打开一个额外的窗口，包含一些不同的选项，如调试控制台、进程资源管理器、资源浏览器以及用于调试和部署的不同信息。我们还可以向 Web 应用添加扩展，并从网站扩展部分选择数百种不同的扩展。

应用服务编辑器（预览）允许您访问代码编辑器，您可以在其中直接修改应用程序代码，无需任何额外工具。性能测试允许您对应用进行负载测试，查看它如何处理任意数量的并发用户。资源浏览器和扩展是我们讨论过的高级工具中的选项。

一个非常有趣的选项是生产环境中的测试。它需要使用插槽，并允许你将一定比例的用户重定向到不同的插槽进行用户测试。例如，我们将应用程序的新版本部署到暂存插槽。使用此功能，我们可以将 10% 的用户指向此插槽，以验证应用程序是否按预期工作。一旦确认 10% 的用户没有问题，我们可以将其增加到 25%，然后是 50%，最后将所有用户切换到新版本。以下是所有开发工具的列表：

其他可用的部分包括 MOBILE、API 和 MONITORING：

• MOBILE：该部分有三个选项，旨在用于移动应用程序。这些选项包括 Easy tables、Easy APIs 和 Data connections。Data connections 定义了与 Azure SQL 数据库的连接，同时也是 Easy tables 和 Easy APIs 的要求。Easy tables 和 Easy APIs 都需要在 Web 应用上安装移动扩展。

• API：API 部分包含 API 定义和 CORS。API 定义让你可以配置描述 API 的 Swagger 2.0 元数据的位置。这使得其他人能够轻松发现并使用你的 API。请注意，URL 可以是相对路径或绝对路径，但必须是公开可访问的。跨域资源共享（CORS）允许在外部主机上的浏览器中运行的 JavaScript 代码与你的后台进行交互。

• MONITORING：这适用于其他资源，我们已经涵盖了其中大部分选项。监控选项包括 Alerts（经典）、诊断日志、日志流和进程资源管理器。在诊断日志中，你可以设置要保存的日志级别。日志流则提供了实时查看日志的选项。MOBILE、API 和 MONITORING 部分中的选项如下所示：

在 Azure 中监控 Web 应用

默认的 Azure Web 应用监控选项虽然有用，但它仅仅是 Web 应用监控选项的开始。如果你想要一个强大的工具来进行监控和告警，同时提供仪表盘和分析，Application Insights 是你想要使用的工具。可以在创建 Web 应用时或之后创建并将 Application Insights 链接到 Web 应用。

此外，你还可以使用单个 Application Insights 来监控多个 Azure Web 应用。值得注意的是，Application Insights 并不限于 Azure Web 应用，它可以与任何托管的应用程序一起使用，包括其他云提供商或本地数据中心。

Application Insights

初次查看应用程序洞察，你会看到几个仪表板，显示过去两小时内关于请求、响应时间和应用程序可用性的基本信息。这些仪表板可以根据不同的时间框架进行自定义，并显示不同的指标。以下是 App Insights 仪表板的示例：

在应用程序洞察下的第一个选项组位于调查（INVESTIGATE）部分。在此部分中，我们有多个指标选项，允许我们跟踪不同的性能计数器和依赖项。大多数这些选项可以编辑，我们可以提取特定信息，并创建自定义仪表板和警报。某些指标只有在应用程序中安装了应用程序洞察 SDK 时才能收集。调查部分下的所有选项列表如下所示：

这些警报的一个示例是可用性。我们可以创建一个测试，持续从不同的位置测试我们的应用程序，以确认应用程序是否可用。

我们可以编辑测试频率、测试位置、成功标准和警报。如果使用默认设置，应用程序将在五个不同的位置每 5 分钟进行一次 ping 操作。如果三个或更多位置无法联系到应用程序，将触发警报并发送通知。以下截图展示了一个可用性测试的示例：

使用情况（USAGE）部分包含有关用户、会话、事件和用户流程的各种信息。要在此部分获取指标，你需要使用应用程序洞察 JavaScript SDK 并将 JavaScript 代码片段添加到你的应用程序中。以下是用户部分下的所有选项列表：

以下是一个需要添加到应用程序中的代码片段示例，以便收集使用情况信息：

<!-- To collect end-user usage analytics about your application, insert the following script into each page you want to track. Place this code immediately before the closing </head> tag, and before any other scripts. Your first data will appear automatically in just a few seconds. --> <script type="text/javascript"> var appInsights=window.appInsights||function(a){ function b(a){c[a]=function(){var b=arguments;c.queue.push(function(){c[a].apply(c,b)})}}var c={config:a},d=document,e=window;setTimeout(function(){var b=d.createElement("script");b.src=a.url||"https://az416426.vo.msecnd.net/scripts/a/ai.0.js",d.getElementsByTagName("script")[0].parentNode.appendChild(b)});try{c.cookie=d.cookie}catch(a){}c.queue=[];for(var f=["Event","Exception","Metric","PageView","Trace","Dependency"];f.length;)b("track"+f.pop());if(b("setAuthenticatedUserContext"),b("clearAuthenticatedUserContext"),b("startTrackEvent"),b("stopTrackEvent"),b("startTrackPage"),b("stopTrackPage"),b("flush"),!a.disableExceptionTracking){f="onerror",b("_"+f);var g=e[f];e[f]=function(a,b,d,e,h){var i=g&&g(a,b,d,e,h);return!0!==i&&c"_"+f,i}}return c }({ instrumentationKey:"ebfab75c-e0ea-4d45-8aa9-ac11e656e644" }); window.appInsights=appInsights,appInsights.queue&&0===appInsights.queue.length&&appInsights.trackPageView(); </script>

配置（CONFIGURE）部分包含许多已经包含在其他应用程序洞察设置（如智能检测设置）和 Azure Web 应用设置（如性能测试）中的设置。最有趣的功能是 API 访问（允许你管理 API 密钥，从而让其他应用程序访问你的 Azure Web 应用上的 API）和工作项（允许你连接到 Visual Studio Team Services 并将工作项直接链接到你的应用程序）。在应用程序洞察的配置部分下的设置列表如下所示：

APPLICATION INSIGHTS 记录了许多不同的指标。你可以在 Application Insights Analytics 中创建自定义查询，获取不同类型的信息。这些查询的结果可以以表格或图表的形式显示。以下是 Application Insight Analytics 的截图：

这是一个 Application Insights 查询的示例：

requests
| where timestamp >= ago(24h)
| summarize percentiles(duration, 50, 90, 95) by bin(timestamp, 1h)
| render timechart

Azure App Service Plan

在创建 Azure Web App 的过程中，我们需要创建一个 Azure App Service Plan。让我们回顾一下 Azure App Service Plan 中可用的设置。

在 SETTINGS 下，我们有一些在 Azure Web Apps 中可用的选项，如网络、扩展（App Service 计划）和扩展（App Service 计划）。还有属性、锁定和自动化脚本等选项，和所有其他 Azure 资源一样。请注意，一个 App Service Plan 可以托管多个 Azure Web Apps。计费是按 Azure App Service Plan 进行的；你不需要按 Web App 计费。因此，Azure Web App 的层级变化与 Azure App Service Plan 中的层级变化是直接相关的。在 Web App 刀片中进行的扩展/缩减和横向扩展/缩减操作将在此处显示，因为层级不会在 Azure Web App 中变化，而是在 Azure App Service Plan 中变化。

以下截图显示了 Azure App Service Plan 中的所有设置选项：

Azure App Service Plan 的一个不同和独特之处是应用程序。如前所述，可以在单一 Azure App Service Plan 上托管多个 Azure Web Apps。设置下的 Apps 选项列出了所有这些 Web Apps，以及在这些 Web Apps 下创建的任何槽位。以下是应用程序列表的示例：

另一个不同的选项是文件系统存储。每个 Azure App Service Plan 都有资源限制。在文件系统存储下，我们可以查看总空间和可用空间的信息。以下是文件系统存储的截图：

Azure Web App 高可用性

我们已经看过如何为 Azure Web Apps 设置自动扩展以及如何创建扩展和缩减规则。但是，扩展可以提高性能，并且在请求增加时保持应用程序正常运行，但并不能真正保证应用程序的高可用性。如果 Azure 数据中心出现问题，或者托管主机正在进行维护，应用程序将在单一位置托管时不可用。

为了实现高可用性，我们需要引入另一个 Azure 服务：Traffic Manager。Azure Traffic Manager 在 DNS 级别操作，根据自定义路由规则将传入请求定向到端点。

让我们从创建一个新的 Azure 流量管理器开始，并通过配置过程展示如何为 Azure Web 应用设置高可用性。

创建流量管理器

要创建一个新的 Azure 流量管理器，我们需要提供名称、路由方法、订阅资源组和位置。如果使用现有的资源组，位置将自动选择。流量管理器特有的选项是路由方法，提供的可选方法有性能、加权、优先级和地理。

性能选项用于当你希望根据响应时间、网络延迟等因素将用户指向提供最佳性能的地点时。

加权将根据权重规则均匀地分配请求。例如，默认规则会将请求均匀分配，如果我们定义了两个端点，则一半的请求会发送到一个端点，另一半会发送到第二个端点。但可以定义权重规则，使得一个端点接收 70%（或任何其他数值）的请求，其余请求则发送到第二个端点。当然，你可以定义多个端点（两个是最少的）并创建任何你想要的权重比例规则。

地理选项将引导用户到最近的地理位置。例如，我们可以有两个端点，一个位于西欧，另一个位于东美洲。如果使用地理路由方法，来自欧洲的用户将被引导到西欧的端点，而来自美国的用户将被引导到东美洲的端点。

最后，优先级路由方法通常在高可用性是目标时使用。一个端点将作为主端点，因此所有流量只会指向主端点。如果主端点不可用，所有流量将指向备用实例。当然，你可以定义多个端点，而不仅仅是两个。更多的端点确保至少有一个端点是可用的，从而提高高可用性的百分比。

在某些情况下，性能方法可以用来实现类似端点跟踪的目标，用户将被引导到在特定情况下表现最佳的端点。如果端点不可用，这将表现为性能下降，用户将被引导到另一个表现更好的端点。使用这种方法的问题是，性能下降的情况可能需要一些时间才能被检测到，用户在性能下降之前可能会遇到问题，直到端点的性能被确认下降并重新定向到其他端点。使用优先级方法时，端点的可用性被监控，问题被更快地检测到，用户将更快地被引导到健康的实例，并且遇到问题的可能性较小。

以下截图显示了一个用于创建新的 Azure 流量管理器的填写模板示例：

Traffic Manager 配置和设置

一旦创建了 Azure Traffic Manager，我们可以继续配置。Traffic Manager 特定的设置包括配置、实际用户度量、流量视图和端点。

实际用户度量和流量视图可以让你监控用户行为，查看用户的指向位置以及流量的流动情况。流量视图将为你提供有关请求来源的见解，使用地图并指示请求的地理来源。实际用户度量可以为你提供更多关于请求和流量的见解，但需要一个度量密钥和一个 JavaScript 代码片段嵌入到应用程序代码中：

Endpoint 选项允许你注册流量将被指向的端点。这些端点可以是 Azure 端点或外部端点。在外部端点的情况下，只允许使用完全限定域名（FQDN）。对于 Azure 端点，可以是云服务、应用服务、应用服务插槽或公共 IP 地址。这是另一个可能会引起混淆的命名示例。在这种情况下，应用服务和应用服务插槽实际上是 Web 应用和 Web 应用插槽。以下截图展示了如何添加一个 Azure Web 应用（应用服务）的示例：

只有一个端点实际上无法帮助我们实现高可用性，我们需要至少再添加一个端点。我建议第二个端点位于不同的区域，以解决单个数据中心可能出现的维护或服务问题。所有可用端点的列表位于端点下，显示名称、状态、类型和位置。以下截图展示了一个示例：

最后一步是在配置下创建规则。请注意，我们可以在这里更改路由方式，并且在创建 Traffic Manager 后，该选项仍然可以更改。这并非所有 Azure 资源的情况，某些设置一旦创建就无法更改。例如，Azure 中的任何资源都不能重命名：如果需要更改名称，唯一的选择是删除该资源并重新创建。你可以在端点监控设置下选择你希望监控的协议、端口和路径。

最后，需要配置快速端点故障切换设置。探测间隔可以设置为 10 或 30 秒，这决定了端点状态检查的频率。容忍的失败次数可以设置为 0-9，这决定了在端点被声明为失败之前，检查失败的次数。探测超时时间决定了探测超时之前所需的时间。这个值至少需要为 5，且小于探测间隔时间。这些设置的较低数字意味着问题会更快被检测到，并且故障切换会在用户发现问题之前发生。然而，您需要小心，因为比需要的更频繁地 ping 应用程序，并设置过少的容忍失败次数，可能会导致应用程序在实例之间切换得过于频繁，进而产生额外的问题。以下截图显示了一个示例配置：

在专用环境中运行 Azure Web 应用

Azure Web 应用使用公共端点，通常通过互联网访问，没有任何限制。在需要更隔离的访问情况下，还有另一个选择：Azure 应用服务环境（ASE）。Azure ASE 为高规模的安全应用程序提供完全隔离的专用环境。Azure ASE 通常用于需要非常高规模、隔离和安全网络访问以及高内存利用率的工作负载。由于 ASE 作为专用环境提供，这消除了“吵闹邻居”问题（可能由于另一个应用程序共享同一主机而导致的性能问题），并允许您充分利用所有资源。

Azure 应用服务计划可以连接到 Azure VNet，但这需要额外的工作。另一方面，ASE 会自动连接到 VNet，并且只能通过私有连接和私有 IP 地址进行访问。

总结

Azure 应用服务计划是 Microsoft Azure 中 PaaS 模式的最佳示例。它允许我们无需服务器和虚拟机即可托管应用程序。尽管管理选项被简化到最小化，但我们仍然有很多配置选项。传统支持几乎为零，但 PaaS 模式旨在为需要最新功能和框架的现代应用程序提供服务。如果您需要运行传统软件，IaaS 是最佳选择。

我们从应用角度介绍了 Azure 中的 IaaS 和 PaaS。但是，没有数据，应用就无从谈起。在下一章中，我们将讨论 Azure 中的数据平台，并展示如何在云端创建和管理数据库。

问题

1. Azure 应用服务是…

   1. IaaS

   2. PaaS

   3. SaaS

2. 与虚拟机相比，我们在应用服务计划中有多少控制权？

   1. 更多

   2. 更少

   3. 相同

3. 与虚拟机相比，我们在 Azure 应用服务计划中的管理权限有多少？

   1. 更多

   2. 更少

   3. 相同

4. 应用服务计划用于托管…

   1. Web 应用

   2. 数据库

   3. 两者

5. 插槽用于…

   1. 托管应用程序的不同版本

   2. 在不同区域托管应用程序

   3. 处理增加的工作负载

6. Azure 应用服务计划的增加工作负载由…处理

   1. 扩展

   2. 横向扩展

   3. WebJobs

7. 最好的 Azure Web 应用监控工具是…

   1. Splunk

   2. 日志分析

   3. 应用洞察

8. Azure Web 应用的高可用性通过…实现

   1. 扩展

   2. 横向扩展

   3. 流量管理器

9. 流量管理器支持…

   1. Azure 终结点

   2. 外部终结点

   3. 两者

10. 为 Azure Web 应用提供的隔离和专用环境是…

    1. Azure 应用服务计划

    2. Azure ASE

    3. Azure 虚拟机

第五章：Azure 数据平台

任何 IT 系统中最重要的部分是数据。没有数据，应用程序和 IT 系统就没有意义。我们讨论了如何在 IaaS 和 PaaS 模型中设置应用程序，但我们如何设置数据库呢？

在本章中，我们将讨论数据库选项以及如何创建托管我们数据库的环境。

我们将涵盖以下主题：

• Azure 虚拟机中的 SQL Server

• 数据库即服务（DaaS）

• Azure SQL 数据库

• Azure 数据和分析平台

技术要求

本章您需要以下内容：

• 一个 Azure 订阅

• SQL Server 管理工作室

Azure 数据库选项

理解 Azure 中的数据库选项是我们云端旅程中的一个非常重要的部分。我们使用的所有服务最终都需要在某个地方存储信息。微软 Azure 提供了广泛的数据平台和多个服务，供我们存储数据。我们将从关系型数据库管理系统（RDBMS）开始，这是最传统的数据库模型，并将讨论 SQL Server 的云选项，作为微软的本地解决方案用于 RDBMS。

在 Azure 中运行 SQL Server 有两种不同的选项——IaaS 和 PaaS。PaaS 中的数据库通常被称为 DaaS。我们将解释这两种方法，并研究 Azure 数据平台中的其他服务。

SQL Server 作为 IaaS

将 SQL Server 作为 IaaS 运行需要创建一个 Azure 虚拟机来托管我们的 SQL Server。我们可以选择创建一个干净的虚拟机，并使用操作系统镜像自行安装 SQL Server，或者我们可以创建一个已包含 SQL Server 的虚拟机。在这两种情况下，管理数据库与在本地环境中管理数据库的方式没有太大区别。您将拥有完整版本的 SQL Server，包含您在本地版本中所有的选项。

让我们开始创建一个用于 SQL Server 的虚拟机，并解释所有细节。

创建一个包含 SQL 镜像的 Azure 虚拟机

如前所述，您可以选择创建一个虚拟机（VM）并稍后安装 SQL Server，或者选择一个已经包含 SQL Server 的镜像。在这种情况下，我将选择一个名为 SQL Server 2016 SP1 企业版的镜像，该镜像已经包含 SQL Server。这个虚拟机是基于 Windows Server 2016 的，这将是我们的操作系统。

大多数选项与我们在未包含 SQL Server 的镜像中创建虚拟机时的选项非常相似。我们从基本信息开始，需要提供名称、虚拟机磁盘类型、用户名、密码、订阅、资源组和位置。强烈建议您在创建将运行 SQL Server 的虚拟机时使用 SSD 作为虚拟机磁盘类型。

磁盘速度对 SQL Server 性能影响很大，选择更快的磁盘类型有助于获得最佳性能。以下是所有基本设置的列表和示例截图：

我们的下一步是选择虚拟机的大小。根据磁盘类型，列表将限制为仅支持所选磁盘类型的大小。在为运行 SQL Server 的虚拟机选择大小时，我建议选择更多的 CPU 和内存。SQL Server 需要大量资源，选择合适的大小有利于性能。幸运的是，如果你选择的大小过大或过小，可以稍后进行更改。这是云计算的一个优势，你不会被初始大小所束缚。基于 SSD 的虚拟机大小列表如下所示：

设置面板包含我们之前使用过的所有选项，并且我们可以为每个选项设置默认值。如果你打算为 SQL Server 设置高可用性，请确保现在选择可用性区域和可用性集，因为这些设置无法在后续进行。此外，请注意虚拟机将要连接的网络、子网和网络安全组。如果使用了多个子网，你可能不希望 SQL Server 最终出现在 DMZ 中。NSG 也是如此——你可能希望为 SQL Server 设置与 Web 服务器不同的安全设置。幸运的是，这些设置可以稍后更改。设置的示例如下图所示：

最后，我们有一组特定于包含 SQL Server 的镜像的设置，这些设置在创建不包含 SQL Server 的虚拟机时无法找到。在 SQL Server 设置中，我们可以配置 SQL 连接性、SQL 身份验证、存储配置、自动修补、自动备份、Azure 密钥保管库集成和 R 服务（高级分析）。

SQL 连接性允许我们设置连接级别和端口。对于连接级别，我们可以仅允许从虚拟机内连接 SQL Server：私有（来自虚拟网络）和公共（通过互联网）。我强烈建议不要使用公共访问 SQL Server，这将使你的数据库暴露在互联网上，任何人都可以尝试访问，且你暴露了数据库给暴力破解攻击。仅从虚拟机内访问 SQL Server 也可能不是一个选项，除非你在单一虚拟机上运行所有服务，并且打算在同一服务器上运行应用程序。最常见的情况是来自虚拟网络内的私有访问，允许同一网络上的其他虚拟机访问数据库。SQL Server 的默认端口是 1433，但可以根据需要进行更改。

SQL Server 的默认身份验证方式为 Windows 身份验证，但如果需要，可以启用 SQL 身份验证。如果启用了 SQL 身份验证，虚拟机使用的用户名和密码也将作为 SQL 登录凭据。

目前，存储配置不可用，且此设置将在虚拟机创建后使用。

自动补丁更新默认设置为每周日 2:00。你可以将此设置更改为其他时间，或者将其禁用。我建议不要禁用此功能，因为它将确保你的 SQL Server 始终是最新的并已安装最新的更新，包括安全更新。然而，在某些情况下，你需要在安装更新之前进行测试，这时你可以选择禁用它们。请注意，在这种情况下，你需要负责保持服务器的更新。

默认情况下，自动备份是禁用的。如果启用，你将有多个可用选项。你可以选择存储帐户来存放备份；默认保留期为 30 天，可以设置为较低的值（最小 1 天，最大 30 天）。备份加密可以设置为开启或关闭；如果需要，可以包括系统数据库的备份。最后一个选项是配置备份计划。默认设置的自动备份将每周执行一次备份操作。你可以将此设置更改为每天备份。你可以设置备份的时间以及频率。（可以配置为每 5 分钟备份一次，或者每天备份一次。）

最后两个选项是 Azure Key Vault 集成和 R 服务（高级分析），它们允许你在需要时启用这些功能。Azure Key Vault 将要求提供将使用的 Key Vault 信息，R 服务将简单地安装附加的分析功能。

以下是 SQL Server 设置的示例：

部署带有 SQL Server 的 Azure 虚拟机比部署没有 SQL Server 的类似虚拟机需要更长的时间。这是因为需要传递额外的信息并在虚拟机内配置 SQL Server 实例。

在 Azure 虚拟机中管理 SQL Server

一旦带有 SQL Server 的虚拟机部署完成，你可以找到与其他 Azure 虚拟机非常相似的设置。唯一的区别是可以在这里找到 SQL Server 配置。

在 SQL Server 配置下，新增了一个选项卡，它具有与创建带有 SQL Server 的新虚拟机步骤中的 SQL Server 设置相同的选项。

此选项卡中的第一个选项是存储；这是之前被禁用的选项。在这里你可以找到存储使用情况和性能。

接下来是 SQL 连接设置，你可以在其中更改访问级别和 SQL Server 端口，并启用 SQL 身份验证（如果之前已启用，则可以关闭）。

以下是显示存储和连接部分的屏幕截图：

在 SQL Server 配置下，其他可用的设置包括自动补丁更新、自动备份、Azure Key Vault 集成和 R 服务（高级分析）。这些功能的所有设置与创建虚拟机时的设置相同。以下是带有其他设置的屏幕截图：

我们可以连接到虚拟机并使用 SQL Server Management Studio 连接到 SQL Server。或者，如果 SQL Server 访问已设置为公开，您也可以从自己的计算机执行相同的操作。正如您所见，连接到 SQL Server 时，您可以使用所有本地 SQL Server 环境中可用的选项和功能。从此时起，在云中管理和维护数据库与在本地服务器或虚拟机中操作没有区别。

我们可以执行任何操作并进行任何更改，就像在本地环境中一样。以下截图显示了所有可用于本地 SQL Server 的选项也适用于 Azure 虚拟机中的 SQL Server：

管理和维护虚拟机本身与管理任何其他 Azure 虚拟机没有区别。所有设置完全相同；唯一的区别是带有 SQL 的虚拟机具有额外的功能，如 SQL Server 配置。

现在我们将转向 SQL Server 作为 PaaS，并尝试比较每个选项为我们提供的内容以及可用的选择。

Azure 虚拟机上的 SQL Server 高可用性

在 Azure 虚拟机中管理 SQL Server 与本地 SQL Server 没有太大区别。创建高可用性解决方案时也可以说类似的事情。

在 Azure 虚拟机中为 SQL Server 创建高可用性有几个选项：

• Always On 故障转移集群实例

• Always On 可用性组

• 数据库镜像

• 日志传输

请注意，为了创建这样的解决方案，虚拟机必须放置在可用区和/或可用性集内。

SQL Server 作为 PaaS

以 PaaS（平台即服务）或 DaaS（数据库即服务）形式运行数据库让我们可以利用 PaaS 的优势。这意味着我们可以使用更少的设置，但也有更少的维护需求。我们无法直接访问 SQL Server，也不能执行许多操作，但我们仍然可以通过可用的预配置选项进行管理。

让我们开始创建 Azure SQL 数据库并解释所有选项。

创建 Azure SQL 数据库

要创建一个新的 Azure SQL 数据库，我们需要提供一组标准信息，如数据库名称、订阅和资源组。额外的信息特定于 Azure SQL 数据库；我们需要选择源，提供服务器和定价层。还可以选择是否希望使用 SQL 弹性池？这个选项与定价层直接相关，稍后我们会详细介绍。对于数据库源，我们可以选择空白（空数据库）、样本（AdventureWorkLT，标准的微软样本数据库）或从备份（如果选择此选项，我们需要提供备份存储位置的信息）。

数据库的排序规则始终为 SQL_Latin1_General_CP1_CI_AS，并且无法更改。以下截图显示了设置列表：

数据库无法独立存在，必须有一个服务器，因此在创建 Azure SQL 数据库时，我们需要提供服务器。如果没有现有的服务器，我们需要创建一个新的服务器。我们需要提供一个名称（一个唯一的名称，将作为公共端点使用）、用户名、密码和位置。

Azure SQL 数据库的定价可能会让人感到困惑，因为有多种定价方式。第一种方式是单一数据库定价。在这种定价模式下，按数据库收费，服务器是免费的。您可以在单台或多台服务器上拥有多个数据库；价格是基于数据库数量，服务器数量不会影响定价。例如，我们可以拥有 10 个 Azure SQL 数据库。如果这些数据库位于同一台服务器或 10 台不同的服务器上，价格都是一样的。真正复杂的部分在于定价单位，数据库事务单位（DTU）。这是一个综合指标，衡量 CPU、内存、数据 I/O 和事务日志 I/O。传统上，在本地环境中，我们会监控 CPU、内存和磁盘 IOPS，然后将其转化为 DTU，但事情并不那么简单。幸运的是，我们有能力随时间调整选择的规格，如果我们确定数据库性能受影响或未能充分利用现有资源，可以进行更改。DTU 模型中的可用层级有 Basic、Standard 和 Premium，每个层级对应不同的 DTU 值。Basic 层提供 5 个 DTU，Premium P15 层最高可达 4000 个 DTU。可用空间也会受到层级的影响，从 Basic 层的 2 GB 到 P15 层的 4 TB 不等。以下是 DTU 层级选择的截图：

由于 DTU 模型过于复杂，微软最近决定引入一种基于 vCore 的新 Azure SQL 数据库定价模型。该模型允许您选择将分配给数据库的 vCore 数量以及可用的内存大小。vCore 的数量可以从 2 个到 80 个不等。内存大小取决于 vCore 的数量，范围从 5.5 GB 到 408 GB。以下是 vCore 层级选择的截图：

我们提到过，弹性池也是一个与定价相关的选项。这是基于资源池化的完全不同的模型。如果选择弹性池作为 Azure SQL 数据库的定价模型，则价格不由数据库数量决定，而是由池的大小决定。对于单个数据库的定价模型适用的两种定价模式也适用于弹性池，我们可以选择弹性池资源是基于 DTU 还是 vCore 来计算的。弹性池和单个数据库定价模型的区别在于，选择的资源数量是可供池使用的，并且池中的数据库共享这些资源。因此，如果我们为弹性池选择 4000 DTU，这些资源将由池中所有的数据库共享。如果所有数据库在同一时间高度利用，这种方式并不理想，此时应选择单个数据库定价模型。但如果你的数据库在一天中的不同时间有较高的工作负载，这就是理想的场景。

假设你正在为全球各地的客户托管应用程序。这将导致每个客户的数据库工作负载不同，且根据时区的不同，在不同的时间表现不同。一个数据库在欧洲的工作时间内将有较高的工作负载，而在美国的工作时间内工作负载较低。位于美国的客户的数据库在欧洲的工作时间内负载较低，但在美国的工作时间内负载较高。将这些数据库放置到弹性池中可以让你共享资源，数据库可以在不同时间段内使用更多可用资源。

Azure SQL 数据库的部署时间取决于层级和来源。来源决定了数据库的大小以及需要执行的操作类型。从逻辑上讲，创建一个空数据库的时间要比恢复一个包含数 GB 或 TB 数据的备份所需的时间短。

部署完成后，我们可以看到两个资源：SQL 服务器和 SQL 数据库：

管理 Azure SQL 数据库

管理 Azure SQL 数据库从防火墙设置开始。默认情况下，只有 Azure 服务可以连接到你的数据库。要允许其他连接，你需要设置一个防火墙规则，允许来自指定 IP 地址的连接。要添加你的 IP 地址，选择“添加客户端 IP”。Azure 门户会自动检测你当前的 IP 地址并添加防火墙规则。注意，执行更改时始终需要选择“保存”选项。如果你不保存新设置，添加新 IP 地址到防火墙规则中是没有意义的。

这种情况曾多次发生在我身上——我添加了一个新的 IP 地址，花了一些时间去弄清楚为什么无法连接，结果才意识到我忘了点击“保存”。防火墙设置如下图所示：

一旦添加了我们的 IP 地址，我们就可以使用SQL Server Management Studio（SSMS）连接到 Azure SQL Server。请注意，与本地 SQL Server 实例相比，我们可用的选项有限。除了数据库和安全性外，其他所有选项都已消失，我们不能像在本地环境中那样管理数据库。SQL Server 与 Azure SQL 之间的对比如下所示：

幸运的是，Azure 提供了许多管理数据库的选项，大多数功能都不会被错过。数据库的管理和维护在 Azure SQL 中变得前所未有的简单。

Azure SQL 的第一个独特选项是查询编辑器。这意味着我们不再需要 SSMS；可以直接通过浏览器运行任何查询。在 SSMS 中执行的一些任务也可以在 Azure 门户中完成。Web 查询编辑器的截图如下：

Azure SQL 数据库的 SETTINGS 包含常见选项，如属性、锁定和自动化脚本。配置也是 Azure 资源设置中常见的选项，但独特的选项包括地理复制、连接字符串、同步到其他数据库和添加 Azure 搜索。同步到其他数据库允许你创建同步组，并设置一组将自动同步的数据库。添加 Azure 搜索选项允许你将数据库连接到搜索服务，从而无需额外的编码或配置即可执行全文搜索。

SETTINGS 下的配置选项允许你更改数据库层级。这将打开一个新的面板，界面与创建数据库时选择数据库层级相同。数据库层级更改的截图如下：

连接字符串允许你为各种编程语言查找数据库的连接字符串。

以下是ADO.NET的连接字符串示例：

Server=tcp:packt.database.windows.net,1433;Initial Catalog=Demo;Persist Security Info=False;User ID={your_username};Password={your_password};MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;