xinyin025/CategoryResourceRepost
1
0
Fork 0
mirror of https://github.com/cheetahlou/CategoryResourceRepost.git synced 2025-11-17 14:43:42 +08:00
Code Issues Actions Packages Projects Releases Wiki Activity

mod

Browse Source
This commit is contained in:
louzefeng
2024-07-11 05:50:32 +00:00
parent bf99793fd0
commit d3828a7aee
6071 changed files with 0 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

180
极客时间专栏/深入浅出云计算/IaaS篇/01 | 区域和可用区：欢迎来到云端数据中心.md Normal file
View File

@@ -0,0 +1,180 @@
<audio id="audio" title="01 | 区域和可用区：欢迎来到云端数据中心" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/a5/19/a5b686127cdf91056c37b6d5f9cc3d19.mp3"></audio>
你好，我是何恺铎，欢迎来到《深入浅出云计算》专栏。这是课程的第一讲，我们就从IaaS来入手，开始对云计算的讨论。
IaaS的本质，是对云数据中心和各类IT基础设施的抽象，是基于软件技术对物理硬件进行的封装和虚拟。这为云计算用户屏蔽了大量底层细节，能让我们在较高的层面进行架构设计和资源使用，大大提高了工作效率。
说起我们大多数开发者最常用的IaaS服务，恐怕要数云上虚拟机了。没错，虚拟机肯定会是我们IaaS部分的讲解重点。不过在此之前，我想让你对整个云端数据中心，先建立起一个高屋建瓴的认识，帮助你理解宏观层面的重要概念。这会对我们后续的学习大有裨益。
所以第一讲，我们就先来谈谈云计算中的**区域**和**可用区**。
## 指点江山，云计算中的“区域”
云计算中最顶层的概念，就是**区域**（Region）了。在大家的日常认知中，它当然是一个地理概念。而在云计算行业中，区域对应的则是云计算厂商在某个地理位置提供的所有云服务的组合，是厂商对外提供云服务的基本单位和容器。
所以绝大多数的云服务，都会按区域进行部署和落地；用户使用的所有云资源，也都会隶属于一个区域，这通常是在创建资源时就确定了的。
常见的区域，我们一般以**国家或地区命名**，也经常辅以城市和序号予以区分。比如，阿里云的华北1区（青岛）、华北2区（北京），以及AWS的美国西部1区（加利福尼亚北部）、美国西部2区（俄勒冈州）等。
与此同时，每个区域还会有个字母数字构成的区域代号（Region ID或Region Code）。比方说，阿里云华北1区代号为cn-qingdao，AWS美国西部1区的代号为us-west-1等。这些代号方便我们在程序或脚本中对区域进行唯一指定，有时也会出现在门户控制台URL中。
<img src="https://static001.geekbang.org/resource/image/e9/22/e9a72227034fedd2b17976687007e322.jpg" alt="">
当然，想要开设一个新区域，绝非一件容易的事情。它有点像网络游戏中的“开服”，包含了云计算服务商在某个地区建立数据中心，安置大量的计算、存储、网络等硬件资源，以及部署虚拟化、服务组件、资源调度等各种复杂软件，最后与外界互联网相连，获得批准对外提供云服务的全过程。
**所以区域的设立和分布，相当程度地体现了云厂商的业务重点和地区倾向**。小型云厂商一般会着重在个别国家或地区深耕；而大型云厂商实力雄厚，会在全球范围内拥有众多开放区域，以便用户能够在全球范围内管理和部署自己的应用。
考虑到经济效益和地理冗余，在典型情况下，云厂商设置的不同区域之间的距离，一般为数百公里或以上，这也对应了单个区域能够辐射和服务的范围。
云厂商在选址时一般会有两种思路：
- 一种是考虑放在**人口稠密的中心城市**，离用户和商业更近，以提供较快的接入体验；
- 另一种则是在**相对偏远的地区**，当地往往能够提供良好的气候条件、充足的建设空间，以及较低的电力、带宽等运营维护成本。
AWS在中国开设的两个区域，就是典型的例子：由光环新网运营的北京区域，位处繁华都市；由宁夏西云运营的宁夏区域则地广人稀。有时这样的搭配被称为“**前店后厂**”模式。
### 如何选择云上“区域”？
区域是如此的重要，所以不仅是云厂商，我们的应用和架构，同样需要先挑选最合适的落脚点。那么，**当我们作为用户时，应该如何选择合适的区域呢？**
**首要的考量因素，当然在于区域的地理位置本身**。这很好理解，我们需要让它尽可能地靠近我们应用所面向的最终用户，来保证更快的接入速度。
比如，当我们主要面向中国大陆用户服务，那自然不需要考虑其他国家的区域。
而如果我们的应用是具有鲜明地域性特征的服务，像是搭建一个面向华东地区的本地生活服务，那就应该更细致地就近选择区域了，比如说，我可以选择阿里云的“华东1（杭州）”或者“华东2（上海）”等区域。
另外，如果你的场景中需要本地数据中心与云端进行互联，也就是混合云架构，那么同样也需要事先注意云区域的地理位置选择。**混合云的专线接入，一般以同城或短距离接入为主**，这样你也能够较好地控制费用，同时提高线路的稳定性。
**第二个考量因素，非常重要而又容易被忽视，那就是区域之间云服务的差别。**
前面我们提到，区域是云计算物理上存在的一个基本单位，所以从IaaS到PaaS各项云服务的落地，也是按照区域进行的。换句话说，**同一个云在不同的区域，所能提供的服务和规模可能是不同的。**
小提示：厂商通常会大力宣传新机型或新服务的推出，但关于这个新服务在哪些区域可用的信息时常会淡化处理，放在不那么显眼的位置。我们需要特别注意这些信息。
因此，你就非常有必要在选择区域之前，先摸清楚相关区域的具体某项服务的可用性。
比如，生产环境需要一些GPU机型来运行深度学习工作，那你就一定要通过官方网站查询，最好是进行实操验证，来确认理想的GPU机型真的存在于你所准备选择的区域；或者，你看到云厂商发布了全新数据库服务，那么在技术选型时也千万不要忘记，验证一下该服务在你选择的区域是确实可用的。
**另外，区域的“开服时间”，也往往会与区域内云服务的可用性有比较大的关联。**
一般来说，新开服的区域通常会落地最新一代的硬件和云端服务，也有非常充沛的资源可供调用，但它未必能迅速覆盖该云的所有服务，相关支持团队可能也需要进行磨合。
而历经时间考验的老区域，则通常会拥有更为丰富的产品选择和成熟的技术支持，但有时对新特性的部署和落地，可能会因为原有条件的限制而进展得缓慢一些。如果早期规划过于保守，极端情况下还可能出现局部“满服”而无法扩展某类资源的尴尬局面。
小提示：不同云不同区域的实际情况千差万别。我上面说的这些，只是给了你一定的判断思路，仅供参考。必要时，你应当咨询云销售或客服来获取更细致的信息。
总而言之，新旧区域哪个更好，并不能一概而论，需要根据你的服务需求和待选区域的实际情况来综合衡量。
**第三个区域选择的考量因素，则是成本因素。即便是同一种服务的价格，在不同区域也往往是不相同的。**
当你的应用需要大批量地采购同一种型号的虚拟机时，或者是你想利用云存储设立一个大规模的云端备份中心，我都建议你仔细比对一下不同区域相关服务的价格，也许你会有惊喜的发现。个别区域会具有明显的价格优势，比如阿里云的华北5区（呼和浩特），和AWS中国的宁夏区域，以此来吸引用户的入驻。
谈到成本，这里我还想补充说明一下**区域的流量费用，是你需要注意的**。如果把区域作为一个有边界范围的实体圈起来，这个流量可以分为三类：**入站流量、出站流量和内部流量**。在现代云计算的计费框架下，一般会倾向于让入站流量和内部流量免费或接近免费，而出站流量则单独收费。
### 多区域架构浅谈
接下来我们谈谈**多区域架构**，它指的是部分关键应用，为了追求最佳的用户体验和高可用性，需要把多个区域的资源和能力结合起来进行构建。
你首先需要了解，主流云厂商在跨区域方面也进行了大量建设和投资，主要体现为：
- **物理上**，各区域之间建设有网络互联专线，一般称为骨干网（Backbone）。骨干网的存在使得同一个云在不同区域间的通信，能够有较高的带宽和较低的延时。
- **软件层面**，允许位于不同区域的虚拟网络跨区域进行互联，使得多区域的私有内网能够借助自有骨干网无缝高速打通。
- **DNS解析层面**，通常会提供就近解析和智能路由能力，将分布广泛的C端流量引流到最近的数据中心，以获得最快的响应速度。
<img src="https://static001.geekbang.org/resource/image/d0/2a/d0fe39ce8cdda5f781b355de14b8b72a.jpg" alt="">
由此可见，公有云的基础设施（尤其是骨干网的存在）能够极大地方便我们构建多区域的应用程序。为了让你对云的骨干网有一个感性的认识，我们来进行一个**动手小实验**，实际感受一下区域间互联的吞吐能力。
我们就以AWS中国的北京区域和宁夏区域作为例子。
首先，我在两边都各自创建了一台虚拟机，在获取IP并开放相应端口后，使用**iperf3**工具进行网络吞吐能力测试。先让一端作为服务器在某个端口监听：
```
[ec2-user@ip-172-31-xx-yy ~]$ iperf3 -s -p 3390
-----------------------------------------------------------
Server listening on 3390
-----------------------------------------------------------
```
然后让另一端作为客户端，发送数据进行测试：
```
[ec2-user@ip-10-0-1-101 ~]$ iperf3 -c aa.bb.cc.dd -p 3390
Connecting to host aa.bb.cc.dd, port 3390
[ 4] local 10.0.1.101 port 43640 connected to aa.bb.cc.dd port 3389
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 53.6 MBytes 450 Mbits/sec 0 3.11 MBytes
[ 4] 1.00-2.00 sec 61.2 MBytes 514 Mbits/sec 0 3.11 MBytes
[ 4] 2.00-3.00 sec 61.2 MBytes 514 Mbits/sec 0 3.11 MBytes
[ 4] 3.00-4.00 sec 61.2 MBytes 514 Mbits/sec 0 3.11 MBytes
[ 4] 4.00-5.00 sec 60.0 MBytes 503 Mbits/sec 0 3.11 MBytes
[ 4] 5.00-6.00 sec 60.0 MBytes 503 Mbits/sec 0 3.11 MBytes
[ 4] 6.00-7.00 sec 61.2 MBytes 514 Mbits/sec 0 3.11 MBytes
[ 4] 7.00-8.00 sec 61.2 MBytes 514 Mbits/sec 0 3.11 MBytes
[ 4] 8.00-9.00 sec 61.2 MBytes 514 Mbits/sec 0 3.11 MBytes
[ 4] 9.00-10.00 sec 60.0 MBytes 503 Mbits/sec 0 3.11 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 601 MBytes 504 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 599 MBytes 502 Mbits/sec receiver
iperf Done.
```
可以看到，在并发度默认为1且未做任何调优的情况下，距离上千公里的双机点对点传输就达到了500Mbps以上，效果相当不错。
小提示：网络传输速度受到许多因素的影响。此处的测试结果数字仅供参考，不代表所测专线的实际带宽能力。事实上，通过增加并发度（如iperf3的-P选项）并加强机器配置等，你还可以成倍地提升测试效果。建议你一定要结合自己的云环境和需求场景进行实际的测试。
所以，在骨干网的加持下，通过合理架构完全可以让多个区域的云服务融为一体。**借助云的力量，小厂也能轻松拥有巨头的分布式部署能力。**
在应用架构层面，多区域并不意味着，我们需要把某区域的资源依葫芦画瓢复制到其他区域，而是可以**根据实际情况各司其职，让不同区域担任不同的角色，联动起来达到业务目的**。
比如，我们可以将面向消费者服务的触点部署到多个区域，就近服务各地区的互联网流量，而偏后台的数据分析和BI服务，则可以安置在性价比较高的非一线城市区域，业务数据可通过骨干网不断回传。这是一种经典的分工模式。
当然，多区域架构固然诱人，我们也不应当走向另一个极端：**轻率、随意地拓展区域**。因为每一个区域的增加，都会相应增加应用架构的复杂性和流量费用，也给我们的维护工作带来负担，这些额外的成本可能会抵消多区域架构带来的好处。
## 什么是“可用区”？
除了“区域”之外，很可能你还听说过“**可用区**”（Availability Zone）这个术语，它同样是非常重要的概念。因为看上去和区域有点相似，有些同学会把它们等同看待。事实并非如此。
可用区是区域的**下级概念**，是指一个具备完整而独立的电力供应、冷却系统、网络设施的数据中心单元。一个区域通常由多个可用区高速互联组成。区域内的可用区一般位于同一个城市，之间相距往往在一百公里以内。
所以物理上的“数据中心”和“机房”概念，若要严谨地对应到云端，其实是在可用区这个层面。
你可能会问，一个区域看上去拥有一个数据中心就足够了，为什么还要建造多个可用区呢？
首要的原因，当然是**为了解决区域内高可用性问题**，这也正是“可用区”名字的由来。尽管数据中心内部有着非常精密的运作系统和冗余机制，但地震、火灾、雷击等极端情况下，仍有可能造成数据中心级别的故障。
为了避免单个数据中心故障让整个区域不可用，那自然就有必要建设多个相对独立的数据中心，也就是多个可用区了。它能让区域中的服务达到相当高的可用性。许多云上的PaaS服务，正是依赖多可用区，来建设架构并保证冗余的。
所以你在设计IaaS层面架构时，也可以利用可用区来实现自己的业务效果。比如在创建云虚拟机时，我们是可以指定可用区的：
<img src="https://static001.geekbang.org/resource/image/38/8d/383b52132dca221c37a31a68fc963b8d.jpg" alt="">
多可用区架构的选择，与前面探讨的多区域架构类似，同样是一个在网络性能、成本、可用性之间权衡的问题。我们可以将资源安排在同一个可用区，以便获得较高的网络互访性能；也可以安排在不同的可用区，以实现故障隔离和服务冗余。
区域需要多个可用区的另一个原因，在于**区域本身有扩展的需求**。一些区域由于早期的容量规划和成本控制原因，很可能在若干年的运营后就会变得资源紧张、后劲不足。
这时得益于可用区的机制，区域可以通过新建可用区，不断扩展自身容量，补充新鲜血液；而老旧的可用区，则可不对新用户开放，逐步封存甚至淘汰，这让区域形成了良好的新陈代谢机制。
所以反过来讲，**可用区的数量也可以成为一个衡量区域规模的重要指标**。数量越多，意味着这个区域规模越大。在选择区域的时候，这个指标也可以作为重要参考。
## 课堂总结与思考
今天是我们《深入浅出云计算》的第一讲，主要讨论了区域和可用区这两个核心概念。我把这一讲的要点简单总结如下：
- 区域是云计算的顶层概念，云服务以区域为单位对外开放；
- 区域选择需要考虑多种因素，包括但不限于地理位置、服务丰富性、开服时间、资源成本、可用区数量等；
- 可用区是区域之下的重要层级，代表独立的数据中心，一个区域内往往有多个可用区；
- 妥善将资源分布到不同可用区，可实现故障隔离，提升架构的可用性。
在讲解这些内容的同时，今天我们也触碰到了网络和高可用架构等相当硬核的话题。如果你觉得还不过瘾，也没有关系，后续会有相关的专题章节作进一步的探讨。
**最后，我想给你留下两个思考题，欢迎你在留言区和我互动：**
- 你日常接触的云计算区域是哪些？你有察觉到区域之间的一些差别吗？
- 在2019年AWS re:Invent大会上，亚马逊还推出了全新的“本地区域”（Local Zone）概念。这又是为什么场景所设计的？层级上它更接近“区域”还是“可用区”呢？
如果你觉得有收获，也欢迎把这篇文章分享给你的朋友。感谢阅读，我们下期再见。

165
极客时间专栏/深入浅出云计算/IaaS篇/02 | 云虚拟机（一）：云端“攒机”，有哪些容易忽视的要点？.md Normal file
View File

@@ -0,0 +1,165 @@
<audio id="audio" title="02 | 云虚拟机（一）：云端“攒机”，有哪些容易忽视的要点？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/b1/73/b1e891cb8759734ee5a41409ff9c8773.mp3"></audio>
你好，我是何恺铎。
前一讲，我先从数据中心的角度入手，和你讲解了云计算中“区域”和“可用区”的概念，帮助你建立起了大局观。今天，我们就开始进入微观层面，来介绍和讨论IaaS中最重要的核心服务：云虚拟机。
我想，你可能对虚拟机并不陌生，现在虚拟机的应用已经很普遍了。传统的物理服务器上通过安装虚拟化软件，就可以虚拟出多个互相隔离的虚拟机，来帮助我们提高资源的使用效率。云计算中的虚拟机，本质上也是如此，也是底层计算存储能力的抽象和开放。
所以你也许会问，那么云虚拟机到底有什么值得讨论的呢？看上去也就是选取CPU、内存、硬盘几大件，然后启动后登录使用，似乎没有什么新鲜的东西？
没错，云虚拟机粗看起来和传统服务器较为类似。但当你对它的应用逐渐深入、规模不断加大时，就非常有必要去深入了解云虚拟机的特点了，因为你开始需要针对不同的场景进行选型，也要在性能和成本间找到最佳的平衡，让你的应用效益最大化。
因此，我接下来就会用三讲课程，为你详细讲解下云端虚拟机的“门道”。
## 云虚拟机到底是什么？
云虚拟机，顾名思义，是在云端虚拟出的服务器。这个服务器你可以完全地控制它，从底层操作系统到安装上层应用。
站在技术实现的角度来讲，虚拟化技术是云虚拟机服务的核心，它本身是一个非常宏大的技术领域。比如你可能听说过Xen、KVM、VMWare、HyperV等等虚拟化产品和技术。云计算中所使用的虚拟化技术，也大都是从这些虚拟化实现方式演化而来的。
作为开发者，我们当然不需要成为虚拟化技术专家。我们只需要知道，云端的虚拟化技术在不断进步和发展，使得云端虚拟化的性能损耗在不断减少、资源利用率不断提升就可以了。但你很有必要去了解云计算中虚拟机的体系结构，这也是云虚拟机与传统虚拟机的最大不同。
云虚拟机的体系结构，用一句话来概括一下，就是全面解耦的**计算存储分离**的设计思想。
小提示：计算存储分离是云计算设计理念中最重要的思想之一，不仅仅体现在虚拟机上，也体现在其他的云服务架构中。我们今后还会不断涉及。
传统的虚拟化，往往是对单一物理机器资源的纵向切割，计算、存储、网络等各方面的能力都是一台物理机的子集。因此，从可伸缩性的角度来说，传统虚拟机存在较大的局限，当物理机的局部出现故障时，也很容易影响到里面的虚拟机。
得益于云端大规模的专属硬件以及高速的内部网络，云虚拟机的组成则有所不同。除了核心的CPU与内存部分仍属于一台宿主机外，它的网络、硬盘等其他部分，则可以超脱于宿主机之外，享受云端其他基础设施的能力。大致架构如下图所示：
<img src="https://static001.geekbang.org/resource/image/78/f9/785d6518852a25283a5337646a19a1f9.jpg" alt="">
你要注意的是，这里我所给出的仅仅是一个简化加工之后的示意图。实际的云计算内部实现，会远比这个要复杂和精妙。不同的云的内部，也会有许多不同的专用硬件各显神通。
所以，云虚拟机，与其说是由一台宿主机虚拟而成的，不如说是云数据中心中的不同部分一起协作，“拼凑”而成的一台机器。这样虚拟出来的机器，我们在使用感受上其实与传统服务器并无不同，但在可扩展性和故障隔离方面，它就具有很大的优势了。
举个例子来说，一台云虚拟机，它可以同时挂载很多硬盘，还能够插上很多“网卡”，拥有多个不同的外部IP。这就是充分解耦带来的好处。
各家厂商的云虚拟机服务的名称会略有不同，阿里云称为云服务器ECS（Elastic Compute Service），AWS称为EC2（Elastic Compute Cloud），Azure就叫Virtual Machine，腾讯云则叫做云服务器CVM（Cloud Virtual Machine）等等。
这里，你需要注意将虚拟机服务和一些建站类服务区分开来，因为它们有时在名称上可能比较类似。比如“云主机”这个叫法，很多云上就是指云虚拟机，在个别云上对应的却是简单建站服务，请你注意不要混淆。
扩展：建站类服务主要是提供一些网站的托管运行环境，如PHP。它是一个相对受限的环境，严格来说属于PaaS服务的范畴，比较注重易用性。而虚拟机呢，则提供了一台真正意义上的服务器，从操作系统到上层应用，都可以自己控制，比起建站类服务来说要开放、通用得多。
虽然各个云厂商对云虚拟机有不同的叫法，但它们的产品形态是比较一致的。当你来到虚拟机服务的门户，一般会有一个列表界面，能够列出当前你拥有的所有虚拟机，你可以按照不同字段过滤、删选、排序。你还可以点击某个VM查看详情，界面一般会展示出VM的常用运行指标。
<img src="https://static001.geekbang.org/resource/image/f8/91/f86e8298381c2bfcf7d101ff3ea92a91.jpg" alt="">
## 云端“攒机”实战
讲到这里，你已经基本了解云虚拟机的概念了。接下来，让我们进入云虚拟机的实际操作环节。
所有的云上，创建虚拟机时一般都会有相当贴心的向导，你可以在虚拟机门户上点击“创建”，然后按照步骤一步步进行即可。今天，我们就以在阿里云上创建Linux虚拟机为例，帮你把“攒机”时最主要的环节串一串，同时顺便给你介绍一下，那些在“攒机”时容易被忽视但又非常关键的要点。
小提示：在本次实验中，建议你选择“按量付费”的付费模式，这也是云计算的经典付费模式。这种模式是按虚拟机的使用时间付费，比较适合短期实验。当然，更多付费模式都各有特点，后面的[第4讲](https://time.geekbang.org/column/article/208917)中我们会进行比较和探讨。
**第一步，当然是选择和确认虚拟机的所在区域**。区域的概念，我在上一讲中已经提到过，它决定了虚拟机的地理位置。
<img src="https://static001.geekbang.org/resource/image/e9/99/e96a0f7c49173b188154929bfbaa9499.jpg" alt="">
小提示：在部分云中，区域是顶级概念，指定新建虚拟机的区域需要你事先在门户的右上角进行选择和切换，如AWS。
这样，新建的虚拟机就会处于你当前选择的区域。你还可以指定区域内的特定可用区。
**随后，就是虚拟机的配置确认环节**，也就是我们通常所说的什么型号、几个核、几G内存的选择。配置的选择无疑非常重要，我会在下一讲着重介绍，这里我们先不妨选择默认的2核8G配置。
<img src="https://static001.geekbang.org/resource/image/90/b6/9063f760c1a2bc2fe49e266534ed29b6.jpg" alt="">
接着，就有你需要注意的一个要点：**选择操作系统镜像**。在这里，你可以选择虚拟机所要安装和使用的操作系统，比如常见的CentOS和Ubuntu，同时你也需要选择这个系统具体的版本号。
在操作系统的列表中，你往往会看到厂商的自有操作系统，比如阿里云的Aliyun Linux、AWS的Amazon Linux等。这是一个很有意思的事情。既然已经有诸多流行的Linux发行版了，为什么云厂商还要推出自己的Linux版本呢？我们什么时候才应该考虑使用它们呢？
<img src="https://static001.geekbang.org/resource/image/61/d9/61b6f428f8f492ba33a17c641af510d9.jpg" alt="">
你可以这样理解：
- 首先，厂商的Linux版本，在理论上会和自己云上的硬件有更好的适配，这样能够更充分地发挥相关硬件的性能。一般来说，厂商也会在自己的云上进行充分的测试和验证。
- 其次，在内核和基础组件的选择上，厂商专有操作系统往往会根据自己的需求判断，来进行一些取舍和裁剪，所以一般会有一个相对苗条的身材，占用比较小的磁盘空间，同时启动速度更快。这是一种更适合云环境的选择，尤其是当你的虚拟机集群规模较大时，就能够显出规模经济效应了。
- 再次，厂商操作系统会预装和云的使用操作方面的一些软件包和SDK，能够为你提供便利。比如说，厂商一般会预装该云的命令行工具（CLI，Command Line Interface），像是AWS CLI等。
- 另外，当然也有云厂商出于“自主可控”方面的考虑，想拥有自己能完全控制的操作系统，不但技术上可以自主演化，还能防范一些商务合作上的风险。厂商自家的PaaS服务，它的底层也一般是使用自己的操作系统。
所以，如果你希望操作系统有更好的软件“兼容性”，或是公司有统一的标准，就可以选择熟悉的老牌Linux系统；而如果你有一些大规模、注重性能的业务，不妨考虑尝试下厂商的Linux操作系统。
**接下来，在系统盘方面，我们选择默认给出的40G“高效云盘”即可**。云硬盘的故事非常精彩，我们[第5讲](https://time.geekbang.org/column/article/210423)中会专项讨论，这里你只需要保持这个默认选项就可以了。
<img src="https://static001.geekbang.org/resource/image/33/31/334c79beaad866a9f85b09fdf6d3aa31.jpg" alt="">
**点击“下一步”，我们来到网络和安全组的配置页面**。在这里，你可以配置私有网络、IP、带宽等重要的网络选项。虚拟私有网络（VPC）同样是一个很大的话题，我们会在[第6讲](https://time.geekbang.org/column/article/211071)展开学习。
这里我们简单起见，请勾选“分配公网IP地址”的选项。这样创建的虚拟机，会自动被分配一个公开IP地址，便于我们稍后从自己的电脑直接发起连接。
<img src="https://static001.geekbang.org/resource/image/e5/0e/e5b2880979b3c1a5019a80becb0c600e.jpg" alt="">
今天我想着重讨论的另一个重点，是接下来选项中的**网络安全组**（Network Security Group, 简称NSG）。如果这里配置不当，就会直接影响虚拟机的使用。很多新同学由于不太了解这个概念，常常会造成无法远程连接登录的情况。
你可以把网络安全组理解为一层覆盖在虚拟机之外的网络防火墙。它能够控制虚拟机入站、出站的流量，并能根据协议、端口、流向等所设定的规则，来决定是否允许流量通过。
所以某种程度上，网络安全组和操作系统中我们熟知的防火墙（如Linux的iptables和Windows防火墙）一样，都起到网络安全防护的作用。
但你需要注意的是它们的区别：网络安全组并不工作在操作系统层面，而是在操作系统层之外，是额外的一层防护。非法流量在尚未到达OS的网络堆栈之前，就已经被它阻断了。所以**NSG的一个优点在于，它不会影响VM的性能。**
另外，**网络安全组是一种可复用的配置**。如果你有大量虚拟机适用于同样的网络控制规则，那么，你就能够很方便地让它们使用同一个网络安全组，这样你管理起来会非常方便。
网络安全组是绝大多数云都支持和实现了重要特性，它体现了云计算中**软件定义网络**的特点。网络安全组非常灵活，你可以随时更改，规则也会动态生效。
小提示：当你在排查虚拟机的连通性相关问题时，比如假设你的网站或API无法被访问，那你一定要记得检查网络安全组中的设置，查看它相关的端口和协议是否已经开放。
<img src="https://static001.geekbang.org/resource/image/4a/ab/4ae25a707929d30b41c1d91c0803dfab.jpg" alt="">
OK，回到我们虚拟机创建的流程，所以我们要创建或使用一个，至少开放了**22端口**的网络安全组，以便我们能够通过SSH连接上去。阿里云中，就提供了方便的“默认安全组”，我们只需要勾选需要开放的端口，就会帮助我们生成一个安全组实例，并对这台机器启用。你也可以事先手工创建一个安全组，并在此处选择。
<img src="https://static001.geekbang.org/resource/image/99/4e/998ab7dd2987d2c2adb7aeedb05cca4e.jpg" alt="">
**再点击下一步，我们就进入了“系统配置”阶段**，在这里，你可以为实例命名，指定用于登录的用户名密码或密钥对等，这里比较简单我就不再赘述了。
<img src="https://static001.geekbang.org/resource/image/7a/91/7aefdff1f6f390eab112e0c612910991.jpg" alt="">
然后，暂时跳过一些可选的高级设置，**确认订单后，按下“创建实例”，就可以等待虚拟机的生成了**。一般数十秒至数分钟之内，一台崭新的云服务器就会就绪，进入运行状态。
<img src="https://static001.geekbang.org/resource/image/3d/03/3d6eb8164a7096fad0e1bfca06a88b03.jpg" alt="">
此时，你可以通过SSH连接上虚拟机的公开IP，使用hostnamectl命令查看一下虚拟机的信息，嗯，一切正常。
```
client@clientVM:~$ ssh -i ./geektime-ali-sh.pem root@101.133.209.214
Welcome to Alibaba Cloud Elastic Compute Service !
[root@my-ecs-vm1 ~]# hostnamectl
Static hostname: my-ecs-vm1
Icon name: computer-vm
Chassis: vm
Machine ID: 201908292149004344218446xxxxxxxx
Boot ID: 2228122a7f3c4b4eb5756824xxxxxxxx
Virtualization: kvm
Operating System: Aliyun Linux 2.1903 (Hunting Beagle)
Kernel: Linux 4.19.57-15.1.al7.x86_64
Architecture: x86-6
```
成功地登录上去之后，你就可以正常使用这台机器了。比如，通常我们会使用yum或apt等包管理器进行一些应用软件的安装。
到这里，我就带你初步体验完了云虚拟机的创建过程。VM类服务的本质就是租用，我们通过在门户上的简单操作，就能够完成一台定制服务器的“租用”过程。
从原理上说，这和租户从房东那租房子其实没有什么两样。而且云上的租用相当便捷，动动手指你就能轻松完成。唯一不同的是，云厂商一般不会把租客“扫地出门”，只要你按时付费，一般不会出现不允许续租的情况。
## 课堂总结与思考
在今天这一讲中，我先帮助你了解了云虚拟机的一些理论知识，尤其是一些体系结构方面的特点。然后，我们进入了创建云虚拟机的实操环节，了解了相关的流程和步骤，也讨论了其中所牵涉的一些注意事项。**我强烈建议你自己也动手操作一下，完成从创建到连接的全过程，形成一个直观的感受。**
我们把这一讲的要点总结如下：
- 云虚拟机是最重要的IaaS服务之一，它基于计算存储分离的架构进行构建；
- 云虚拟机的创建过程，由地域、机型、操作系统、存储、网络等多方面选项共同构成；
- 云虚拟机可使用云厂商自有操作系统，与云有较好的适配；
- 网络安全组是保护云虚拟机的网络防火墙，可以同时应用于多个虚拟机。
在今天我们实践的过程中，也引出了若干重要的概念和选项，如机型配置、云硬盘、云网络等等。后续我们会逐个地展开讨论，敬请期待。
**最后，给你留下两个思考题**：
- 在上面的实验当中，为了便于连接我们给机器自动分配了公网IP。在生产环境中为了安全性考虑，应该尽可能避免给虚拟机分配公网IP，那么这时你如何连接到这些机器呢？
- 暂时不再使用的云虚拟机，和传统服务器一样可以“关机”。关机状态的云虚拟机仍然会存在于虚拟机列表中，随时可以再启动。那么，关机之后它还会继续收费吗？
欢迎你在留言区和我互动，我会第一时间给你反馈。如果觉得有收获，也欢迎你把这篇文章分享给你的朋友。感谢阅读，我们下期再见。

141
极客时间专栏/深入浅出云计算/IaaS篇/03 | 云虚拟机（二）：眼花缭乱的虚拟机型号，我该如何选择？.md Normal file
View File

@@ -0,0 +1,141 @@
<audio id="audio" title="03 | 云虚拟机（二）：眼花缭乱的虚拟机型号，我该如何选择？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/fb/c5/fb8f13300808095714e60456fef2bec5.mp3"></audio>
你好，我是何恺铎。
在上一讲中，我带你了解了云虚拟机的大致构架和组成，实际体验了在云上建立第一台虚拟服务器的完整流程，还介绍了在创建过程中，你所需要注意的若干重要选项及其含义。
而在这些选项之中，最重要的恐怕就是**虚拟机的规格**了，因为它直接决定了虚拟机的计算能力和特点，同时，也会深刻地影响使用成本，是你在选型时需要考虑的重点问题。
很多同学在实际工作中，都会遇到这样的困惑：公司要上云，或者因为业务发展需要采购新的云服务器，但是在查看某云厂商的官网时，发现可选择的虚拟机型号列表很长，有点儿眼花缭乱。
**那么，不同种类的虚拟机到底有什么区别呢？在选择时又应该从哪儿入手呢？**
今天，我们就来详细聊聊这个话题。
## 建立对虚拟机配置的多维认知
完整形容一个虚拟机的核心配置和能力，需要从多个角度来入手和描述。弄懂了这些重要维度的含义，你才能够准确理解一个虚拟机的性能预期和使用场景，从而作出正确的型号选择。这里并非只有决定CPU核数和内存大小这么简单。那么，主要是哪几个维度呢？
**第一个维度，就是虚拟机的“类型”，或者说“系列”。**
这是一个非常重要的概念，它是指具有同一类设计目的或性能特点的虚拟机类别。
一般来讲，云厂商会提供通用均衡型、计算密集型、内存优化型、图形计算型等常见的虚拟机类型。这些类型对应着硬件资源的某种合理配比或针对性强化，方便你在面向不同场景时，选择最合适的那个型号。
而vCPU数和内存大小（按GB计算）的比例，是决定和区分虚拟机类型的重要指征之一。
**通用均衡型**的比例通常是1:4，如2核8G，这是一个经典的搭配，可用于建站、应用服务等各种常见负载，比如作为官网和企业应用程序的后端服务器等。如果你对未来工作负载的特征还没有经验和把握，那你也可以先使用通用型实例，等程序运行一段时间后再根据资源占用情况按需调整。
如果vCPU和内存比是1:2甚至1:1，那就是**计算密集型**的范畴，它可以用于进行科学计算、视频编码、代码编译等计算密集型负载。
比例为1:8及以上，一般就会被归入**内存优化型**了，比如8核64G的搭配，它在数据库、缓存服务、大数据分析等应用场景较为常见。
**图形计算型**很好理解，就是带有GPU能力的虚拟机，一般用于机器学习和深度学习模型的训练和推理。随着AI的火热，这类机器也越来越多地出现在各种研发和生产环境中。
**在主流云计算平台上，常常使用字母缩写来表达虚拟机系列。**比如，AWS的通用型是M系列，阿里云的内存优化型为R系列，Azure的计算优化型为F系列等。
**不同云平台之间使用的字母可能相同，也可能大相径庭，你在记忆时需要小心，不要混淆**。在这里，我根据各家2020年的最新情况，简单整理了一个表格供你参考：
<img src="https://static001.geekbang.org/resource/image/57/a5/57a38f221932fcb85b9bef9d4e009da5.jpg" alt="">
需要注意的是，上表中还提到了本地存储型，它是指带有高性能或大容量的本地存储的机型。我们在后续讨论云盘的课程中还会提到，这里你先了解一下就可以了。
**第二个重要的维度，是虚拟机的“代”(Generation)，用来标识这是该系列下第几代的机型。**
我们知道，数据中心硬件和虚拟化技术是在不断发展的，云厂商需要不断地将最新的技术和能力推向市场，让你享受到时代进步带来的技术提升。这和我们个人用的笔记本电脑是非常类似的，笔记本厂商也总是在不断地更新设计和配置，以赢得消费者的青睐。**所以即便是同一系列的机型，不同的代别之间也会有不小的区别。**
具体来讲呢，同类型虚拟机的更新换代，往往首先会带来相应硬件CPU的换代提升。随着一代新机型的推出，云厂商一般都会详细说明背后支撑的硬件详细信息。
比如说，AWS在2017年末，在全球发布的新一代EC2实例M5/C5/R5，它们的背后是升级到了Skylake架构的Intel至强铂金系列处理器，相比前一代采用的Broadwell或Haswell架构处理器，进步了不小，还支持了可大幅提升矢量和浮点运算能力的AVX-512指令集。
再比如，阿里云在2019年的云栖大会上，也盛大发布了第六代ECS，它全线采用了更新一代的Intel至强Cascade Lake处理器，相较前一代的Skylake实例，又在性能、价格优势等各方面有了进一步提升。你可以参考下面给出的截图：
<img src="https://static001.geekbang.org/resource/image/d6/c4/d60b7200a6614f19a2461f410ecc14c4.jpg" alt="">
这里你需要特别注意，正是由于虚拟机所采用的物理CPU在不断更新，所以**云上虚拟机的单核性能未必相同**。有时，虽然两个虚拟机的核数一致，但由于底层芯片的架构和频率原因，性能上可能有较大的差别，我们需要注意在不同机型间做好比较和区分。
像微软Azure，就引入了Azure Compute Unit（ACU）的概念，来帮助量化不同CPU的单核性能。比如其历史较久的通用型A系列，它的单核性能基准为100单位，而计算型的F系列的单核算力则高达210~250，是A系列的两倍还多。
另外，你还应当看到，**云虚拟机的换代更新并不仅仅只在CPU等硬件配置层面，很多时候也伴随着底层软硬件架构的更新和提升，尤其是虚拟化技术的改进。**
前面我提到的AWS第5代EC2实例，正是全面地构建在AWS引以为傲的Nitro System新一代虚拟化技术栈之上。
Nitro System的本质，是将许多原来占用宿主机资源的虚拟化管理工作进行了剥离，并将这部分工作负载，通过Nitro Card这样的专用硬件进行了硬件化，达到了最大化计算资源利用率的效果。在这一点上，阿里云的神龙架构也采用了类似的做法，与AWS Nitro可谓一时瑜亮，有异曲同工之妙。
**总的来说，我们消费电子产品时的“买新不买旧”，在云端同样适用**。新一代的型号，往往对应着全新的特制底层物理服务器和虚拟化设施，能够给我们提供更高的性能价格比。
所以，有些云平台在选择虚拟机型号时，会贴心地默认隐藏相对过时的型号。当然在个别情况下，比如数据中心的新机型容量不足，或者老型号有促销活动时，你也可以酌情选用之前的型号。
**第三个重要的维度，就到了我们所熟知的实例大小（Size），也就是硬件计算资源的规模。**
在选定的机器类型和代别下，我们能够自由选择不同的实例大小，以应对不同的计算负载。
如果你只是个人用来实验，那么也许单核或者双核的机器就足够了；如果是要放在大规模的生产环境当中，则可以按需选取高得多的配置，现代云计算已经能够提供多达128vCPU的机型了。
在描述实例大小时，业界常常使用medium、large、xlarge等字眼来进行命名区分，这样的描述基本已经成为事实标准，包括AWS、阿里云、腾讯云在内的多家主流厂商都在使用。
我们可以大致这样记忆：**标准large对应的是2vCPU的配备，xlarge则代表4个vCPU，而更高的配置一般用 **n**xlarge来表达，其中 **n** 与xlarge代表的4vCPU是乘法关系**。比如，8xlarge就说明这是一台8*4=32vCPU的机器。
注意：这里在进入更严谨的配置表达时，我们更多倾向于使用vCPU而非核数（Core）来描述虚拟机处理器的数量。因为超线程（HyperThreading）技术的普遍存在，常常一个核心能够虚拟出两个vCPU的算力，但也有些处理器不支持超线程，所以vCPU是更合适的表达方式，不容易引起混淆和误解。
在某些场景下，你可能还会看到“metal”或者“bare metal”这样的描述规格的字眼，中文称为“裸金属”。它们就是云服务商尽最大可能将物理裸机以云产品方式暴露出来的实例，主要用于一些追求极致性能，或是需要在非虚拟化环境下运行软件的场景。
## 理解虚拟机命名规则
经过前面的介绍，我们已经了解了决定虚拟机配置的最重要的三个要素，即**类型、代别和实例大小**。这样，一个完整的虚拟机型号命名就已经呼之欲出了。我们来看最具代表性的AWS命名规则（阿里云采用的也是非常类似的格式）：<br>
<img src="https://static001.geekbang.org/resource/image/d0/49/d0338ecfd965ff5e1a45e6f6304edc49.jpg" alt="">
这其实就是利用上述的各维度，按照某种顺序排列的一个组合。理解了这一点，当你今后看到某个具体型号的时候，就能够很快地明白该型号命名背后的含义了。
比如，对于**r5.4xlarge**这个型号，我们会很快想到，这首先是一个R类型的第5代的内存型机器，它应该有4×4=16个vCPU，内存大小则是16×8=128G（内存型机器的CPU内存比一般为1:8）。这样分解下来，原来看上去比较陌生晦涩的一个字符串，是不是就立刻变得清晰起来了？
当然，并非所有的云都一定是采用类似AWS的命名规则，像是微软Azure，就用了一个略有不同的命名体系，大致可以总结为：<br>
<img src="https://static001.geekbang.org/resource/image/7d/7e/7d7825ca39f4ce7b44731af6a64f1a7e.jpg" alt="">
比如“**E4 v3**”，就代表了微软Azure上4核32G的第三代内存型机器。掌握了Azure的格式特征后，你同样能够很快地解读标识的具体含义。
不知道你有没有注意到，在前面的命名公式中，还有一个我们称之为“**后缀**”的可选部分，在许多的型号命名中都能看到它。这个可选部分呢，它一般是作为型号硬件信息的一个重要补充，这种型号与不带此后缀的标准版本相比，会有一些显著的区别或特点，这也是你需要重点关注的地方。
这里我给你举一些型号后缀的例子吧。
比如，AMD现在凭借EPYC霄龙芯片，也开始在服务器硬件市场攻城拔寨，许多云厂商就专门推出了使用AMD CPU的云虚拟机，这些虚拟机往往会使用字母a作为后缀。AWS上的**m5a型号**，就是使用AMD EPYC 7000系列服务器CPU构建的通用型虚拟机。
再比如，AWS的C5n计算型虚拟机，其中“n”这个后缀表达的是，该规格在网络层面进行了增强，会比同型号标准机型拥有更大的带宽和网络吞吐能力。在阿里云上，表达相同“网络增强”含义的后缀则是“ne”。
有时，为了验证机型配置是否与我们的期望相符，在Linux环境下，我们可以使用**lscpu**命令，来了解手中虚拟机的CPU信息，并与机器的具体型号名称进行对照。下面的信息，是我在一台AWS的**m5a.xlarge机型**上运行的结果，你可以看到芯片提供商AMD及双核四线程等关键信息，与机型命名的含义相符：
```
[ec2-user@ip-xx-yy-zz ~]$ lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 4
On-line CPU(s) list: 0-3
Thread(s) per core: 2
Core(s) per socket: 2
Socket(s): 1
NUMA node(s): 1
Vendor ID: AuthenticAMD
CPU family: 23
Model: 1
Model name: AMD EPYC 7571
Stepping: 2
CPU MHz: 2379.224
BogoMIPS: 4399.39
Hypervisor vendor: KVM
Virtualization type: full
...
```
## 课堂总结与思考
今天，我们主要探讨了云上虚拟机的类型与规格，相关要点可总结如下：
- **云虚拟机的配置规格**主要取决于类型、代别、实例大小三个最重要的维度。
- **实例**所属的类型，决定了虚拟机相应的硬件资源配比与专项能力，分别为不同的场景优化设计。你可以根据实际场景来酌情选用，这样既能满足需求又好控制成本。
- **云虚拟机的型号名称**一般由类型、代别、实例大小这几项的缩写组合而成，有时还会带有补充后缀。了解了某个云的型号格式后，通过拆分对应，你很容易理解具体型号的含义。
**最后，作为今天的交流讨论题**，你可以回忆一下，在生产或测试环境中，使用过的最强劲的云端机型。你注意过它是什么系列、什么型号的吗？它主要被用于什么业务场景呢？
欢迎在留言区和我互动，我会第一时间给你反馈。如果觉得有收获，也欢迎你把这篇文章分享给你的朋友。我是何恺铎，感谢阅读，我们下期再见。

169
极客时间专栏/深入浅出云计算/IaaS篇/04 | 云虚拟机（三）：老板要求省省省，有哪些妙招？.md Normal file
View File

@@ -0,0 +1,169 @@
<audio id="audio" title="04 | 云虚拟机（三）：老板要求省省省，有哪些妙招？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/e8/31/e8bbe0e0545a6c1863328d8db7f03c31.mp3"></audio>
你好，我是何恺铎。让我们继续云虚拟机的话题。今天这一讲，我想从一个不一样的视角，也是你会很感兴趣的一个角度来进行讨论，那就是**成本**。
的确，很多时候，我们上云的障碍是在于价格。
打个比方吧，假设我们要为公司的业务上云进行虚拟机采购，这时如果你只是简单地将物理服务器的报价，与按量付费模式下的“通用型”云虚拟机进行对比，那你很容易就会得出云上机器太贵的结论。
但其实呢，在云上，我们有很多实用的招数来控制虚拟机的成本，是可以“少花钱、多办事”的。
**那么，都有哪些省钱的妙招呢？**今天我就来“偷偷”告诉你。
## 省钱妙招之一：使用包年包月机型
**包年包月**，可能是我们最先会想到的降低成本的办法了。
顾名思义，包年包月就是我们要提前预估好自己虚拟机的使用时间，比如半年、一年甚至三年，并提前支付相关款项的一种购买方式。这样的购买方式，通常能够给你带来较大幅度的折扣，帮你显著地节约成本。
云厂商其实是鼓励和欢迎虚拟机包年的，因为这样降低了云端动态租用的不确定性，减少了服务器空置的情况，也为厂商做中长期的数据中心容量规划提供了便利。另外一方面，包年包月一般都是先付费的模式，所以从财务层面上看，也有利于厂商的现金流。这些都是采用包年包月方式能够获得让利的原因。
在许多国内云厂商的虚拟机创建界面上，包年包月甚至成为了默认的选项，你需要注意在界面下方选择购买的时长。时长越长，你能获得的折扣越大。
那么，包年包月具体能帮我们省多少呢？这没有一个唯一确定的答案。因为，不同的云、不同的区域以不同的时长购买，折扣力度都可能有所不同。通常来讲，一般常见的机型在3~7折不等。
不过，在包年包月的模式下，也有一些你需要注意的问题。
**首先，这个模式意味着我们牺牲了一些资源安排上的灵活性。**因为在它到期之前，你一般是无法取消的，或者在某些云上，即便是允许你取消，也需要扣除一部分费用，这就像我们买了保险后中途退保一样，就要承担一些损失。
**另外，包年机给我们带来了一个后续维护工作：续费管理。**尤其是当包年虚拟机的数量陆陆续续变多时，由于创建时间不同，到期时间也就比较分散，那么续费的工作就变得更加复杂和重要起来。如果忘记续费，过了缓冲期后，机器会被自动关闭甚至删除，那就会影响业务的连续性。这是你需要小心的一个地方，千万不要错过云上的续费提醒。
## 省钱妙招之二：使用竞价实例
相比包年包月的广为人知，竞价实例（Spot Instances）的知名度似乎小一些。但如果运用得当，竞价实例其实威力巨大，这也是我十分推荐你去尝试和使用的一种省钱的办法，因为它往往能够提供相当大幅度的折扣。
竞价实例，是AWS所首创的产品形式，其他的云厂商近几年也在纷纷跟进。它的基本原理是，**把云数据中心上闲置的机器资源拿出来，进行公开的拍卖，价高者得。**让“市场机制”，也就是各个用户，来主导这些闲置资源的定价。
因为是闲置资源，所以大家的出价都会比较低，颇有一点共同来“薅羊毛”的意思。所以在很多时候，你甚至能够拿到相对标准按时计费价格1~2折的折扣力度，这无疑是非常有诱惑力的。而对于厂商而言，这也不是什么坏事，因为这些资源本就闲置，还不如顺水推舟、对外开放，以获得一些回报。所以说，竞价实例，是一个伟大的发明，是一种双赢的机制。
但也因为是闲置资源，所以**它主要的限制在于可能会被随时回收。**
当数据中心的闲置资源不足时，比如说，有人要创建大批更高优先级的、“正牌”的非竞价实例，或者当竞价市场涌入大量土豪，推动市场价格高于你的最高出价时，你的虚拟机就会被停止运行，并自动回收（一般会有一个提前数分钟通知的机制）。
因此，竞价实例能够有较低折扣的本质，是在于牺牲了**稳定性**。所以，你在使用竞价实例时，还需要注意选择场合。生为竞价实例，就要时刻有“退位让贤”的觉悟和准备。
如果你要搭建一个对外服务的网站，或者是数据库的话，这些需要24小时不间断运行的生产负载，就并不适合跑在竞价实例上。竞价实例非常适合的应用场景，包括一些后台批量计算、爬虫、性能测试等等。这些无持久化状态、可打断的工作，今后你可以第一时间想到用竞价实例来支撑。
竞价实例也是按照运行时间来付费的，你可以随时主动关闭和终止。所以，这种方式的动态性还是不错的，你可以随时按需启停。
小提示：在实操时，你需要注意一下在创建界面上选择竞价的策略。常见的竞价方式有两种，一种是手动设定你所能接受的最高价格，一种则是选择跟随市场价格的变动，也即自动出价。这和我们买卖股票时的操作选择很类似。
## 省钱妙招之三：使用突发性能类型
对于一台固定配置的服务器来说，总是会或多或少地存在**资源闲置**的情况。比如说，我们为了潜在的工作负载，申请了比较强劲的CPU资源，但也就是在业务高峰到来的时候，服务器才能够发挥出全部实力。而在相对长得多的业务低谷期，机器的CPU资源利用率其实会比较低。
因此，我们常常可以见到一些服务器CPU平均使用率非常低下，这显然是一种巨大的成本浪费。
**而云端的架构，天生就善于解决资源闲置问题。**
一种解决方法是，我们可以使用可动态调整规模的集群，来应对弹性计算场景，这样可以灵活设定动态扩缩容的机制，以达到减少低谷期资源占用的目的（我会在后面的架构部分进行专门讨论）；而另一种方法则更加简单，且适用于单机，那就是采用**突发性能类型**（Burstable Performance Instances）。这是一种非常实用而又有趣的虚拟机类型，有时它也被称为“可突增性能实例”。
突发性能类型同样拥有指定的vCPU数量、内存大小等配置，**但其成本显著小于类似配置的其他类型机器**。它的主要区别在于，这种类型的虚拟机的CPU性能表现，采用的是**积分制**，其积分会随着时间的推移匀速累加，也会随着算力的输出而被不断消耗。
当积分充裕时，CPU可按需跑满，达到CPU性能的100%，同时会较快地消耗积分；当积分不足或耗尽时，则CPU只能发挥出标称值的一小部分性能。这个小部分的比例值，我们称它为**性能基准**，它与积分匀速累加的速度相一致。
小提示：突发性能实例的性能基准，通常在峰值的5%~40%不等，具体比例按不同云厂商不同实例而定，你可以查询官方文档进行确认。
我们可以把突发性能类型，理解为性能有一定折扣和弹性的机型。
当重型计算负载来临时，积分的存在和积累，使得这些机器具备自动消耗积分，并获得临时“突增”性能的能力。就像是汽车的发动机，可以通过“涡轮增压”获得短时动力，来增强汽车的输出功率一样。
积分的积累虽然会有一个上限，但一般也足够它全速计算数个小时了。下图中，我给出了一个实际场景中某突发性能VM实例的积分曲线，你可以看到积分额度在匀速积累、到达上限，以及开始消耗的全过程：
<img src="https://static001.geekbang.org/resource/image/a3/8c/a3da93ecddca0340cd4d94fe5a955c8c.jpg" alt="">
再回到我前面所说的波峰波谷计算场景，很显然，突发性能实例的积分制特性，恰好可以大显身手。比如，对于符合流量自然特征的互联网业务来说，在负载较低的深夜和清晨，性能突增实例处于较低的CPU占用率状态，同时积攒积分；当白天流量高峰到来时，CPU则可以消耗积分，发挥其全部性能，保障业务稳定运行。
性能突增类型目前在各大云上已经比较常见了，在AWS和阿里云上对应的是T系列虚拟机，在微软Azure上则对应B系列。
从成本上来看，突发性能实例和相同配置的通用机型相比，典型情况下，其折扣大约可以达到六折或更低。所以说，性能突增类型虚拟机的引入，非常有助于提高资源利用效率，推荐你在**负载具有时效性**的情况下酌情选用。
## 省钱妙招之四：使用ARM实例
说到ARM处理器，相信你并不陌生。随着移动互联网的高速发展和智能手机的普及，ARM早已走进千家万户。而且在庞大的手机市场的催化下，ARM芯片的性能也在不断地取得突破，开始接近甚至达到x86处理器的水平。
在移动端取得了统治性的地位后，踌躇满志的ARM开始进军服务器端。低功耗、高性价比成为它开拓市场的法宝。**而极具规模效应的云计算，又可以说是ARM服务器芯片的最佳试验田。**
所以，使用ARM架构芯片的虚拟机实例，已经成为云计算IaaS层不容忽视的新潮流。
同时，因为ARM是一个相对开放的架构，具备芯片设计和制造能力的大厂商，就纷纷开始自建芯片。厂商通过自行定制，就可以针对云上场景和需求进行优化，进一步降低单位算力的成本，巩固自己的竞争优势。
举个例子，AWS近些年就在大手笔地投入它自家基于ARM的Graviton处理器。在re:Invent 2018大会上，推出了第一款基于Graviton的A1类型EC2实例，而在re:Invent 2019大会上，AWS更是再接再厉，发布了基于第二代7纳米Graviton芯片的M6g、R6g、C6g全系列的虚拟机服务。这里的后缀g就代表Graviton。
在国内，也有像阿里、华为这样具备端到端硬件研发能力的巨头，在进行芯片自研，并在云端开始落地商业化。比如，华为在2019年发布了基于ARM的鲲鹏920处理器，性能十分强大，也达到了世界领先水平。与之匹配，华为云也推出了搭载鲲鹏处理器的KC1系列的虚拟机。
那么，使用ARM处理器的机型，对用户来说有什么吸引力呢？
**答案同样是成本。**根据厂商的测算，输出相同性能的ARM机型，能够帮助用户节省30%~40%的成本，这当然也是得益于ARM处理器的高性价比特点。所以说，它是我们节约成本的又一个有力手段。
今天我们的实操部分，就来尝试一下风头正劲的鲲鹏云虚拟机。
我在华为云的北京四区创建了一台kc1.large.2的双核4G机型，操作系统选择了Ubuntu 18.04的ARM版。创建的过程和普通x86虚拟机类似，这里就略去不表了。
机器启动后，我们通过SSH登录上去，查看系统信息：
```
root@ecs-kc1-large-2-linux-20200115174501:~# uname -a
Linux ecs-kc1-large-2-linux-20200115174501 4.15.0-70-generic #79-Ubuntu SMP Tue Nov 12 10:36:10 UTC 2019 aarch64 aarch64 aarch64 GNU/Linux
```
嗯，这是如假包换的ARM架构！用Linux自带的bc命令来简单算个Pi值，跑个分：
```
root@ecs-kc1-large-2-linux-20200115174501:~# time echo &quot;scale=5000; 4*a(1)&quot; | bc -l -q
3.141592653589793238462643383279502884197169399375105820974944592307\
81640628620899862803482534211706798214808651328230664709384460955058\
...
...
74351362222477158915049530984448933309634087807693259939780541934144\
73774418426312986080998886874132604720
real 0m22.325s
user 0m22.316s
sys 0m0.009s
```
我们可以看到，机器仅用了22秒就完成了精确到小数点后5000位的PI值，成绩还是相当不错的。
注意：这里使用bc命令以及其中的三角函数来计算Pi值，只是直观展示CPU能力的简便方法。结果仅供参考，不推荐这个方法作为严肃性能测试的依据。
不过，你可能会有点担心ARM在服务器端的软件生态。诚然，ARM体系结构下的软件，的确比不上x86架构那样丰富，但在近年相关厂商的大力推动下，其实已经取得了长足的进展。比如，在我们这台KC1服务器的Linux操作系统中，已经默认安装了Java、 Python等语言和运行环境。你甚至可以使用apt包管理器来安装Docker，并在ARM服务器内运行Docker容器，你可以参考下面给出的示例：
```
root@ecs-kc1-large-2-linux-20200115174501:~# docker run hello-world
Hello from Docker!
This message shows that your installation appears to be working correctly.
To generate this message, Docker took the following steps:
...
...
For more examples and ideas, visit:
https://docs.docker.com/get-starte
```
这简直太棒了，这意味着ARM服务器同样可以支撑容器，我们可以在上面跑微服务！这会为各种应用在ARM上的部署打开方便之门。
所以说，云计算让ARM服务器这个看起来比较遥远的事情，变成了触手可及的现实。随着华为鲲鹏等相关计算生态的不断成熟，基于ARM的虚拟机系列，也会越来越成为我们在注重成本控制时的一个有力选择。
## 课堂总结与思考
今天，我们详细讨论了在云上使用虚拟机时，可以运用的一些节省成本的思路和方法。它们原理不同，各有利弊。
- **包年包月的付费方式**是最常见的降低虚拟机使用成本的方法，它通过**牺牲采购的灵活性**来换取折扣。
- **竞价实例的机制**让云端的闲置资源对外开放，基于市场竞拍的定价方式，常常能够让我们获得很大的折扣。这种方法主要是通过**牺牲稳定性**，来换取成本上的节约。
- **突发性能实例**是一种特殊的使用CPU积分制的机型，相对标准机型成本较低，适合工作负载存在较大波动的场景。它主要**牺牲的是性能**。
- **基于ARM的虚拟机实例**已陆续走向市场，随着生态的不断成熟，也将成为低成本机型中非常具有竞争力的选择。这种方法主要**在生态和兼容性方面存在一些限制**。
结合起来不难看到，第一、二种方法，是在购买模式层面的调整和创新；而第三、第四种方法，是在机型选择方面，拓宽了我们的思路。有时，这两个层面的方法是可以组合起来使用的。比如，我就曾经在AWS云上使用Spot Instance的竞价方式，启动了一批T系列的突发性能实例，取得了很好的业务效果。
好了，这一讲就到这里。**今天我留给你的思考题是：**
- 与包年包月类似的预付费折扣，还有一种叫做“预留实例”（Reserved Instance）的模式。你能说说它和包年包月的不同之处，以及独特的优势是什么吗？
- 在有些云上创建突发性能实例时，还会有一个“无性能约束模式”的高级选项。你知道这个高级选项勾选后有什么作用，能解决什么问题吗？
欢迎你给我留言，我会尽快给你反馈。如果觉得有收获，也欢迎把这篇文章分享给你的朋友。感谢阅读，我们下期再见。

268
极客时间专栏/深入浅出云计算/IaaS篇/05 | 云硬盘：云上IO到底给不给力？.md Normal file
View File

@@ -0,0 +1,268 @@
<audio id="audio" title="05 | 云硬盘：云上IO到底给不给力？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/6c/eb/6cb3aa6bb9d3451d7fd2aa9bd52d47eb.mp3"></audio>
你好，我是何恺铎。
通过前几讲的学习，我想你对云虚拟机应该有了不少的了解，也对如何根据实际情况来选择和运用虚拟机，有了一定的认识。在前面的学习过程中，我也留下了许多伏笔。其中之一，就是云虚拟机的重要组件：**云硬盘**。
那么今天这一讲，我们就来深入讨论一下这个话题，来帮助你了解不同云硬盘的差别，以及如何在实际场景中挑选最合适你的硬盘型号。
## 云硬盘是什么？
云硬盘，又叫做“云盘”或者“云磁盘”，就是云虚拟机上可以挂载和使用的硬盘。这里，它既包含了用于承载操作系统的系统盘，也包括了承载数据的数据盘。
在云计算的领域，有时，我们还会把云端磁盘服务叫做块存储（Block Storage），因为它们与Linux操作系统中的块设备相对应，是云上提供的“裸盘”，可以格式化并且施加文件系统。
既然是硬盘，那么它就与我们通常的认知相一致，当然是带有数据持久化功能的。这在专业上被称为“**非易失性存储**”（Non-ephemeral Storage），也就是说**写入的数据不会丢失**。即便所在虚拟机重启、关机甚至下线删除，这块云硬盘只要还存在，其中的数据也并不会被擦除。
事实上，云厂商对于云盘，不仅仅会保障数据的顺利写入，一般还会帮你在存储端同步和保留至少三份副本的数据。所以说，云硬盘的冗余度和可用性是非常之高的，一般极少发生云硬盘数据丢失的情况，你大可放心地使用。
重要提示：尽管云硬盘有良好的存储冗余，但你不能仅仅依赖它的可靠性。从数据的层面来看，你必须进行额外的备份。2018年7月曾有创业公司因为云厂商故障，丢失了在云硬盘上的所有重要数据，一时成为业界的热点新闻，这个教训是非常深刻的。所以，你应当通过定期为云磁盘创建快照、异地备份数据文件等方式，来保护你的关键数据。
云硬盘与传统磁盘的真正差异在于，绝大多数的云硬盘都是**远程**的。我们都知道，在经典计算机的体系结构中，硬盘是通过本地机器内部主板的高速总线，与CPU、内存等部件相连接；而在云端，你的硬盘则很可能并不在宿主机上，而是在专用的磁盘服务器阵列中，**两者是通过数据中心内部的特有IO线路进行连接**。没错，这也正是**计算存储分离架构**的一种体现。
理解了这样的一个结构，你就能明白，有些云上的“IO优化实例”（AWS上称为EBS-Optimized）是指什么了。它就是指云虚拟机与云硬盘之间的网络传输，进行了软硬件层面的优化，这样可以充分地发挥所挂载磁盘的性能。现在较新型号、较强性能的云虚拟机，一般都自动启用了这个优化。
## 云硬盘的性能等级
你可能听说过一些，网上对于云硬盘性能方面的质疑。这在云计算发展的早期尤其多见，甚至成为了很多人反对上云的主要原因之一。
不错，云硬盘的确有多副本写入的开销，同时也比较依赖于远程传输。所以，早期云硬盘的确存在一些性能上的短板。不过，那都是老黄历了。
当下的云硬盘经过了多次的软硬件迭代，尤其是SSD的迅速发展，吞吐量和随机读写能力等各项性能指标都已经不再是问题了。在现代云计算中，已经发展出了基于不同存储介质的、丰富的性能等级选择，你已经能够找到单盘IOPS在数十万量级甚至达到百万的云硬盘产品了。
所以，现在的云硬盘，性能上已经非常“给力”了。**你更多的是要考虑如何根据应用场景，选择合适介质的硬盘等级，同时权衡好相应的成本。**
那么下面，我们就分别来看一看主流云硬盘的不同性能等级，以及它们对应的磁盘类型和存储介质。
**第一个等级的云硬盘，是基于传统HDD硬盘构建而成的**。这类云盘的性能一般，最高IOPS大概在**数百**左右。在很多的云上，已经不把它作为推荐的选择了。但它并非一无是处，**成本低**就是它的最大优势，在不注重性能的测试环境，或者是个人自用的服务器，它就是一个很好的选择。
**第二个等级，往往是基于混合硬盘，也就是结合HDD和SSD硬盘构建的云硬盘**。它会综合发挥SSD的性能优势和HDD的容量优势。比如它可以用SSD部分来承载热点区域数据，或是作为缓存，来提高响应性能。在这个等级下，典型的IOPS为**数千**左右，是很多云上创建硬盘的**默认选项**，比较适合像是操作系统启动盘这样的常规负载。
**第三个等级的云硬盘，它的存储介质就是纯SSD硬盘了**。虽然贵一些，但一分价钱一分货，这个等级下的云硬盘能够提供非常稳定的IO能力，IOPS通常能够**上万**，也有相当不俗的吞吐量和较低的访问延时。你可以用它来承载生产环境中重要的关键业务应用，或是各类数据库等IO密集型应用。
**第四个等级，也是当下业界的最高等级，就是进一步优化增强的最新SSD云盘**。它一般会采用更新一代的企业级闪存硬件，配合自研或改进后的底层传输协议，和虚拟化技术栈的优化来提供服务。因此它能够达到惊人的性能水平，满足我们最为苛刻的性能场景需求，比如承载SAP HANA（SAP的高性能计算平台）、高并发OLTP数据库等等。这类SSD云盘的IOPS通常能够**突破十万以上**。
各个云对于不同等级云硬盘的命名方法各有不同，我把相应的产品类型和名称整理成了一个表格，方便你去了解和查询：
<img src="https://static001.geekbang.org/resource/image/97/13/97150c100ba7b7d25dd5750e1c01ad13.jpg" alt="">
当然，这个表格只是一个大致的划分，仅供你作为参考。在具体的情况中，云和云必然存在一些差异，也会有一些各自的产品特点，建议你在使用时针对性地确认。比如说，AWS的gp2通用型SSD类型，它具有比较宽广的性能指标范围，还具备I/O积分和性能突增机制（与性能突增VM实例的CPU类似），可以提供比较高的峰值性能，应用场景是相当广泛的。
除了云盘性能等级之外，**还有一个影响云盘性能的重要因素，就是这块云硬盘的容量**。不论是哪种磁盘类型，它的容量大小几乎都与性能正向相关。同等的性能等级下，云硬盘的容量越大，一般来说它的性能就越高，直到达到这个等级的上限。这是由云上磁盘能力共享的底层设计所决定的。
**所以在某些时候，你可能需要刻意地增大所申请的云硬盘的容量，以获取更高的性能，即便这些额外的空间不一定能被用上。**
好了，对于云盘性能的讨论就先到这里。在上面的性能讨论当中，我们主要通过**IOPS**来进行衡量。事实上，衡量IO性能还有吞吐量、访问延时等其他的重要指标。这些指标同样会由磁盘的类型和大小所决定，你可以查询云厂商文档来确认。这里限于篇幅，我就不详细展开了。
## 云硬盘实战
接下来，让我们进入实战环节，一起学习一下云硬盘的使用。在这个过程中，你也能真实地感受一下不同性能等级的区别。
这里，可以继续沿用我们在[第2讲](https://time.geekbang.org/column/article/206296)中创建的阿里云虚拟机，目前它是默认挂载了一个**40G的高效云盘**作为系统盘。
**我们可以先用lsblk和df命令查看一下磁盘的情况：**
```
[root@my-ecs-vm1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 40G 0 disk
└─vda1 253:1 0 40G 0 part /
[root@my-ecs-vm1 ~]# df -hT -x tmpfs -x devtmpfs
Filesystem Type Size Used Avail Use% Mounted on
/dev/vda1 ext4 40G 1.6G 36G 5% /
```
通过命令的输出，可以清晰地看到，这台机器有一块40G的系统盘，挂载在根目录下。
**然后，我们可以使用fio工具来测试一下这块系统盘的性能表现。**我们通过fio在系统盘上创建一个1GB的文件，接着进行4K大小的随机读取实验。
```
[root@my-ecs-vm1 ~]# fio --name=mytest1 --filename=~/testfile1 --rw=randread --refill_buffers --bs=4k --size=1G -runtime=10 -direct=1 -iodepth=128 -ioengine=libaio
mytest1: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=l
ibaio, iodepth=128
fio-3.7
Starting 1 process
mytest1: Laying out IO file (1 file / 1024MiB)
Jobs: 1 (f=1): [r(1)][100.0%][r=8560KiB/s,w=0KiB/s][r=2140,w=0 IOPS][eta 00m:00s]
mytest1: (groupid=0, jobs=1): err= 0: pid=1324: Sat Jan 25 17:03:53 2020
read: IOPS=2154, BW=8619KiB/s (8826kB/s)(84.9MiB/10090msec)
slat (nsec): min=2529, max=38138, avg=3080.22, stdev=575.39
clat (usec): min=444, max=102701, avg=59394.84, stdev=46276.36
lat (usec): min=448, max=102705, avg=59398.39, stdev=46276.34
clat percentiles (msec):
| 1.00th=[ 3], 5.00th=[ 3], 10.00th=[ 4], 20.00th=[ 4],
| 30.00th=[ 4], 40.00th=[ 5], 50.00th=[ 96], 60.00th=[ 97],
| 70.00th=[ 99], 80.00th=[ 99], 90.00th=[ 100], 95.00th=[ 100],
| 99.00th=[ 101], 99.50th=[ 102], 99.90th=[ 102], 99.95th=[ 102],
| 99.99th=[ 103]
bw ( KiB/s): min= 8552, max=10280, per=100.00%, avg=8645.20, stdev=384.80, samples=20
iops : min= 2138, max= 2570, avg=2161.30, stdev=96.20, samples=20
lat (usec) : 500=0.01%, 1000=0.03%
lat (msec) : 2=0.50%, 4=36.26%, 10=3.74%, 100=57.13%, 250=2.34%
cpu : usr=0.50%, sys=1.19%, ctx=20986, majf=0, minf=161
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, &gt;=64=99.7%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, &gt;=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, &gt;=64=0.1%
issued rwts: total=21741,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=128
Run status group 0 (all jobs):
READ: bw=8619KiB/s (8826kB/s), 8619KiB/s-8619KiB/s (8826kB/s-8826kB/s), io=84.9MiB (89.1MB
), run=10090-10090msec
Disk stats (read/write):
vda: ios=21399/2, merge=0/1, ticks=1266052/242, in_queue=1039418, util=81.1
```
实际命令输出的结果比较长，这里我们主要关注下IOPS的部分。你可以看到，平均IOPS的数值都在2100左右，这个跑分的成绩，和我们当初建立这块高效云盘时提示的性能目标值“2120”相当一致。
<img src="https://static001.geekbang.org/resource/image/83/ec/8396f50d9acd70d7e4186dbeee124fec.jpg" alt="">
如果高效云盘还不够满足你的业务要求，你可以随时为机器添加更高规格的硬盘，这也是云硬盘的灵活性所在。
**接下来，我们就来试一下动态挂载新硬盘的过程。**
首先来到这个虚拟机的“本实例磁盘”管理界面，选择“创建云盘”，这里我们选择一块300G的SSD云盘，按照提示，这样我们就能够拥有1万的IOPS。
<img src="https://static001.geekbang.org/resource/image/3f/6c/3fb419666c386c7582b17821bd3efc6c.jpg" alt="">
之后，按照提示确认创建即可。OK，阿里云很快地为我们创建好了磁盘，但此时这块SSD磁盘的状态为“未挂载”，我们可以通过界面操作，把它挂载到正在运行中的目标虚拟机里。
挂载完成后，磁盘的状态开始变为“使用中”，说明磁盘已经“上线”。这时，我们再在Linux操作系统中用lsblk命令查看：
```
[root@my-ecs-vm1 ~]# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
vda 253:0 0 40G 0 disk
└─vda1 253:1 0 40G 0 part /
vdb 253:16 0 300G 0 disk
```
你可以看到，磁盘中已经出现了一个新的块设备vdb。
这时，我们需要将这块磁盘进行格式化，并创建ext4文件系统：
```
[root@my-ecs-vm1 ~]# mkfs.ext4 /dev/vdb
mke2fs 1.42.9 (28-Dec-2013)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
Stride=0 blocks, Stripe width=0 blocks
19660800 inodes, 78643200 blocks
3932160 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=2227175424
2400 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872, 71663616
Allocating group tables: done
Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done
```
好，还差最后一步，我们要在/mnt下，创建一个data目录，并将这个新的块设备挂载到该目录。
```
[root@my-ecs-vm1 ~]# mkdir /mnt/data
[root@my-ecs-vm1 ~]# mount /dev/vdb /mnt/data/
```
终于大功告成。我们再次使用fio工具，来测试下这块SSD盘4K随机读方面的能力。**和前面不同的是**，这回我们要把测试文件路径定位到“/mnt/data”目录，因为这个目录指向的是刚刚创建的新硬盘：
```
[root@my-ecs-vm1 ~]# fio --name=mytest2 --filename=/mnt/data/testfile2 --rw=randread --refill_buffers --bs=4k --size=1G -runtime=10 -direct=1 -iodepth=128 -ioengine=libaio
mytest2: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=l
ibaio, iodepth=128
fio-3.7
Starting 1 process
Jobs: 1 (f=1): [r(1)][100.0%][r=41.1MiB/s,w=0KiB/s][r=10.5k,w=0 IOPS][eta 00m:00s]
mytest2: (groupid=0, jobs=1): err= 0: pid=1302: Sat Jan 25 16:59:30 2020
read: IOPS=10.6k, BW=41.2MiB/s (43.2MB/s)(415MiB/10067msec)
slat (usec): min=2, max=445, avg= 3.10, stdev= 1.49
clat (usec): min=828, max=77219, avg=12115.14, stdev=20941.23
lat (usec): min=841, max=77222, avg=12118.74, stdev=20941.22
clat percentiles (usec):
| 1.00th=[ 2737], 5.00th=[ 3326], 10.00th=[ 3523], 20.00th=[ 3687],
| 30.00th=[ 3785], 40.00th=[ 3884], 50.00th=[ 3949], 60.00th=[ 4047],
| 70.00th=[ 4146], 80.00th=[ 4359], 90.00th=[56361], 95.00th=[71828],
| 99.00th=[73925], 99.50th=[73925], 99.90th=[74974], 99.95th=[76022],
| 99.99th=[76022]
bw ( KiB/s): min=41916, max=43600, per=100.00%, avg=42464.60, stdev=724.17, samples=20
iops : min=10479, max=10900, avg=10616.15, stdev=181.04, samples=20
lat (usec) : 1000=0.02%
lat (msec) : 2=0.17%, 4=55.50%, 10=29.30%, 20=0.83%, 50=3.47%
lat (msec) : 100=10.71%
cpu : usr=3.24%, sys=5.58%, ctx=96090, majf=0, minf=163
IO depths : 1=0.1%, 2=0.1%, 4=0.1%, 8=0.1%, 16=0.1%, 32=0.1%, &gt;=64=99.9%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, &gt;=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, &gt;=64=0.1%
issued rwts: total=106300,0,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=128
Run status group 0 (all jobs):
READ: bw=41.2MiB/s (43.2MB/s), 41.2MiB/s-41.2MiB/s (43.2MB/s-43.2MB/s), io=415MiB (435MB),
run=10067-10067msec
Disk stats (read/write):
vdb: ios=105123/3, merge=0/1, ticks=1265938/41, in_queue=1266532, util
```
上面的测试结果表明，这块SSD盘对/mnt/data目录中文件的4K随机读，成功地达到了1万IOPS的标称水准。也就是说，新创建的SSD磁盘性能还是相当给力的。
在实际的使用场景中，你就可以把一些读写较为密集的负载，比如数据库的数据目录，配置到这个SSD盘对应的目录下。
好了，通过上面的实验，相信你对云盘的挂载和使用有了比较直观的认识。**云盘的热挂载特性让它使用起来特别灵活方便，而且大小性能任你调度。挂载后的云硬盘真正使用起来，和你熟悉的硬盘操作也并没有什么两样。**
## 认识和使用本地磁盘
前面我们对于云虚拟机的硬盘作了许多讨论，都是围绕着“远程硬盘”这个产品形态来展开的。的确，远程云硬盘的好处很多，是计算存储分离架构的体现，也是云虚拟机硬盘的主流方式。
不过，有时我们还是会有点怀念“本地磁盘”，也就是直接位于宿主机上的硬盘。因为看似传统的本地硬盘，与远程硬盘相比起来，还是会有它自己的优点。毕竟它和计算单元离得近，而且没有三副本的负担，所以往往性能不俗，价格又相对便宜。
**那么，云上能否使用本地磁盘呢？**
**答案是肯定的。**而且本地磁盘一般不需要自行创建，只要你选择了带有本地磁盘的机型，启动后，该型号对应大小和规格的本地磁盘就会自动被挂载。
你应该还记得，我在介绍虚拟机型号的[第3讲](https://time.geekbang.org/column/article/208288)中，提到了“本地存储”系列的虚拟机吧？那些正是自带有大容量、高性能本地磁盘的虚拟机型号。它们或是配备了高性能的本地NVMe SSD磁盘，或是装备有高吞吐的先进HDD，数量可能还不止一块。妥善使用这些本地磁盘，在合适的场景下，能够帮你发挥很大的作用。
比如，你要在云上用虚拟机自己搭建一个经典的Hadoop集群，要用虚拟机的磁盘组合成HDFS（Hadoop的分布式文件系统），并希望使用MapReduce或Spark等支持数据本地性（Data Locality）的计算框架。这时，你就应该考虑使用带有本地磁盘的机型了。
所以，当一些应用软件系统本身考虑到了硬件的不可靠性，设计了上层的存储冗余机制时，你就可以考虑采用本地磁盘。因为这种情况下，本地磁盘的可靠性缺陷得到了弥补，**它的相对高性能和低成本就成为了优势**。这时如果选用三副本的远程云硬盘，反倒显得有些笨重了。
还有一类，对数据丢失不敏感的**临时性存储**的场景，也是本地磁盘可以发挥的舞台。这些场景包括操作系统的pagefile或swap分区，以及数据库的硬盘缓存区（如SQL Server的Buffer Pool Extension）等等。
不过，我还是要提醒你本地磁盘的缺点，它在本质上，还是易失性（Ephemeral）的存储，**当机器关机或删除，以及出现硬件故障时，本地磁盘上的数据就可能损坏或丢失。**这一点我们必须牢记，不适用的场合必须使用更可靠的远程云硬盘。
## 课堂总结与思考
今天我们围绕云硬盘，进行了一系列的讲解，可以简单总结如下：
- 云硬盘是云虚拟机的主要持久化存储，与宿主机往往是分离的；
- 云硬盘支持动态添加和删除，使用起来灵活方便；
- 云硬盘一般提供多种性能等级，最终性能会受存储介质和容量大小的共同影响；
- 部分虚拟机型号会自带高性能的本地磁盘，在可以容忍数据丢失风险时，是你值得考虑的一个选择。
最后，我还想补充一点，**云硬盘的付费模式，同样有按量付费和包年包月之分。**在很多的云上，你能够为一块云盘启用包年，长期租用的确定性也能够给你带来折扣，这和虚拟机资源的包年包月是一样的。
**今天，我想和你讨论的问题如下：**
- 我们说云硬盘可以动态地挂载和卸载，使用起来十分方便。那么更进一步的问题是，已经挂载的云硬盘能够支持在线扩容吗？
- 还有一种云端常见的存储类产品，如阿里云的文件存储NAS、AWS的EFS等，也可以挂载到云虚拟机。那么，你知道这种产品形态和云硬盘有什么区别，主要用于什么场景吗？
你可以在留言区和我互动。如果觉得有收获，也欢迎你把这篇文章分享给你的朋友。感谢阅读，我们下期再见。

198
极客时间专栏/深入浅出云计算/IaaS篇/06 | 云上虚拟网络：开合有度，编织无形之网.md Normal file
View File

@@ -0,0 +1,198 @@
<audio id="audio" title="06 | 云上虚拟网络：开合有度，编织无形之网" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/0c/31/0cb14fb27d6ff22970bfb749148d5b31.mp3"></audio>
你好，我是何恺铎。
我们对于IaaS的介绍已经渐入佳境了。前面，我们主要涉及了与云虚拟机相关的计算和存储方面的内容。今天这一讲，我想要和你讨论的，则是“计算/存储/网络”三要素中的最后一项：**网络**。
在互联网时代，网络的重要性不言而喻，我们必须好好掌握。通过合理的网络拓扑设置，既能够帮助我们实现架构上的隔离性和安全性，又能够让各组件互联互通、有序配合。
不过网络对于许多开发者而言，有时会让人感觉是一个挺困难的话题。它复杂的设置、晦涩的术语，尤其是各种连而不通的场景，可能让你望而生畏。
请你不要担心，云上的网络经过了一定程度的抽象以后，已经为我们屏蔽了一定的复杂度。只要宏观的思路梳理得足够清晰，你很快就能够理解云上的网络组件，并让它们听你指挥、投入使用。
## 什么是虚拟私有网络？
虚拟私有网络（Virtual Private Cloud，简称VPC），是云计算网络端最重要的概念之一，它是指构建在云上的、相互隔离的、用户可以自主控制的私有网络环境。虚拟私有网络有时也称为专有网络（阿里云）或虚拟网络（Virtual Network或VNet，Azure的叫法）。
上面的概念解释也许不太好理解，其实用通俗的话来讲，**私有网络就是一张属于你自己的内网。**内网之内的服务器和设备，可以比较自由地互相通信，与外界默认是隔离的。如果外部互联网，或者其他虚拟网络需要连接，则需要额外的配置。
所以说，虚拟私有网络，就是你在云上的保护网，能够有效地保护网内的各种设施。有的时候，你可能还要同时创建多个虚拟网络，让它们各司其职，实现更精细的隔离。
小提示：在一些云上，除了私有网络，你可能还会看到“经典网络”的选项。这是上一代的云上内网基础设施，虽然它配置起来相对简单，但在隔离性、可配置性上有许多局限。现在已不推荐使用了。
虚拟私有网络麻雀虽小，但五脏俱全。在传统数据中心里，经典网络架构中的概念和组件，在虚拟网络中你几乎都能找到对应。这里比较重要的一些概念包括：
- **网段**，私有网络的内部IP区段，通常用CIDR形式来表达，如192.168.0.0/16。
- **子网**，私有网络的下级网络结构，一个私有网络可以划分多个子网，这和通常意义上的子网也是对应和一致的。阿里云中把子网形象地称为“交换机”。
- **路由表**，用于定义私有网络内流量的路由规则，决定着数据包的“下一跳”去向何方。每个子网都必须有一张关联的路由表，通常情况下，系统会自动帮你创建一个默认的路由表。
- **网关**，是对进出私有网络的流量进行把守和分发的重要节点，根据用途的不同，有多种类型，后面我们还会讲到。
- **安全组**，私有网络里虚拟机进出流量的通行或拦截规则，可以起到虚拟机网络防火墙的作用，我们曾经在[第2讲](https://time.geekbang.org/column/article/206296)中提到过它。
所以在创建虚拟网络时，你就需要对上面这些重要属性进行按需设定。
下面，我就以**阿里云VPC**为例，来带你实际操作体验一下。
首先，我们来到阿里云的专有网络管理控制台，选择新建一个VPC，这里的**网段**我们选择**192.168.0.0/16**：
<img src="https://static001.geekbang.org/resource/image/2d/87/2d755b5f2574da9c9608c20091680187.jpg" alt="">
注意：VPC属于局域网，按照RFC规范，能够使用的IPv4区段必须为192.168.0.0/16、172.16.0.0/12、10.0.0.0/8这三个或它们的子集。
同时，我们还**至少要创建一个子网**，也就是交换机。我们选择一个子IP段192.168.0.0/24，并且设置所属可用区为“**可用区D**”：
<img src="https://static001.geekbang.org/resource/image/f8/fd/f8dc763e2e83bda0d7b4e670cd56d0fd.jpg" alt="">
我们再来创建另外一个交换机，网段设置为192.168.1.0/24。**这里的关键在于，我们可以让第二个交换机位于另外一个可用区E：**
<img src="https://static001.geekbang.org/resource/image/ec/4e/ec26ce81aa6b28314cdd38df9011414e.jpg" alt="">
这就说明，**我们可以建立跨可用区，也就是跨同区域内不同数据中心的私有网络。**这是VPC的一个强大的特性，能够为我们私有网络的高可用性提供保障。比如，你可以让主力集群在一个可用区工作，备用集群在另一个可用区随时待命，需要时迅速切换；你也可以把流量同时分发到不同的可用区，动态控制分发策略。
就这样，我们收获了一个包含两个交换机的VPC。
<img src="https://static001.geekbang.org/resource/image/35/39/357ccf28ed22b1e0630f8deb626ac339.jpg" alt="">
<img src="https://static001.geekbang.org/resource/image/06/1a/0693033babfe8fde3681876ce64f5a1a.jpg" alt="">
查看一下它的路由表，你可以发现，它自动为我们包含了两个子网的路由信息：
<img src="https://static001.geekbang.org/resource/image/ed/56/ed182d9478e414b6cb6d98601f110456.jpg" alt="">
你看，创建VPC其实并不困难。这里的关键还是要规划好VPC和各子网的网段，需要让它们既有足够的地址空间以供资源拓展，又不要安排得范围过大，以免和其他VPC或公司内部网络产生地址冲突，为后续的网间互联带来不必要的麻烦。
如果你在没有VPC的情况下直接创建虚拟机，公有云一般都会为你自动生成VPC。在生产环境中，我强烈地建议你**不要让系统自动建立VPC**，而是像我们上面的做法，先自行建立好VPC，配置好子网和网段等重要参数，然后再创建云虚拟机“入住”。**因为这样，你会事先让自己有一个明确的网络规划，对整个VPC的把控和理解也会更强。**
## 私有网络中的虚拟机
让我们回到虚拟机的视角。当一个虚拟网络已经存在时，我们就可以将新创建的虚拟机放置在这个虚拟网络中。
**那么，这个所谓的“放置”是怎么真正产生的呢？虚拟机和专有网络的连接点是哪里呢？**
答案就在于虚拟机的**网卡**，又称弹性网卡（Elastic Network Interface， 简称ENI）。虚拟机的网卡一方面是和虚拟机的本体进行绑定，另一方面则嵌入某个私有网络的子网，也会拥有至少一个私网IP。
云上的网卡，之所以被称为“弹性”网卡，是因为它具备以下特征：
1. 一个虚拟机可以绑定多块网卡，有主网卡和辅助网卡之分；
1. 一块网卡隶属于一个子网，可以配置同一子网内的多个私有IP；
1. 辅助网卡可以动态解绑，还能够绑定到另一台虚拟机上。
这再次体现了云计算的解耦特征，在某些场景下是非常有用的。比如，有一台服务线上流量的机器，而且线上流量导向的是它的辅助网卡，那么当这台机器因故无法正常工作时，你在排查问题的同时可以考虑这样一个应急的办法：将这台机器的辅助网卡迅速解绑，并重新绑定到待命的备用机上。这样就能够比较快地先恢复对外服务。
当你在创建虚拟机的时候，向导会询问你，这台虚拟机属于哪个VPC，以及VPC下的哪个子网？现在你就理解了，**这个选项的实质性结果，就是新虚拟机自动生成的主网卡，接入了所选VPC的所选子网。**
好了，网卡和私有IP的部分你应该已经比较清楚了。那么你可能会问，**公有IP呢？**这正是我想说的另一个比较关键的部分。
在绝大多数的云上，创建虚拟机时都会有一个选项，问你“是否同时为虚拟机分配一个公网IP地址”。如果你选择“是”，这样机器启动后，就会拥有一个自动分配的公网地址，便于你从自己的电脑连接到这个实例。这在很多时候都是最方便的选择。
<img src="https://static001.geekbang.org/resource/image/c3/06/c33e5833b3b355812748b56242809f06.jpg" alt="">
但对于生产环境，我的推荐是，**尽量不要使用和依赖这个自动生成的公有IP**。因为它本质上是一个从公有云的IP池中**临时租用**给你的IP。如果你的机器关闭或重启，下次获得的IP可能就完全不同了。
这时，我们真正应该用到的是**弹性IP**（Elastic IP），有些云称为eIP。弹性IP一旦生成，它所对应的IP是固定、不会变化的，而且完全属于你所有。这非常适合需要稳定IP的生产环境。
请不要被它的名字迷惑，它所谓的弹性，其实是指可以**非常自由地解绑和再次绑定到任意目标**。你本质上是买下了这个IP的所有权，将这个IP赋予谁，是你的权利，而且你还可以动态按需切换。
所以，当你有一个域名，需要让DNS服务解析到某个外部IP，你就应该建立一个弹性IP，绑定到相关资源后，让域名解析到这个弹性IP，而不应该使用虚拟机自动匹配的公有IP。因为后者是不稳定的。
好，让我们继续进入实验的部分。我们在刚才的VPC内来建立一台虚拟机，起名为vm1-in-vpc1，把它放置到位于可用区E的第二个交换机中，并且选择**不自动生成公有IP**。
<img src="https://static001.geekbang.org/resource/image/0d/31/0df182dd6112814c5b37ad0f72990431.jpg" alt="">
注意，**这时它只有私有IP，我们怎么连接它呢？**我们可以创建一个弹性IP，然后绑定到这台实例：
<img src="https://static001.geekbang.org/resource/image/1e/41/1eaba10ea37d7cfe051c928b7661b041.jpg" alt="">
<img src="https://static001.geekbang.org/resource/image/af/03/af47832030593a7eec58c206e28b8003.jpg" alt="">
绑定之后，就自然可以连上刚才的这台虚拟机了。**注意VM列表界面会有相应的显示：**
<img src="https://static001.geekbang.org/resource/image/23/63/23caf3f25c45fda580b90b7a437c6a63.jpg" alt="">
尝试SSH连接一下，一切正常：
```
client@clientVM:~$ ssh root@47.102.139.39
root@47.102.139.39's password:
Welcome to Ubuntu 18.04.3 LTS (GNU/Linux 4.15.0-72-generic x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Welcome to Alibaba Cloud Elastic Compute Service !
root@vm1-in-vpc1:~#
```
## 如何让私有网络对外“开口子”？
在阿里云上，如果一台云虚拟机没有被赋予公有IP，默认情况下它就失去了访问外网的能力，只能进行内网通信，这在很多时候，的确是我们想要的安全控制。但也有一些情况，**我们希望内网的机器和外界并不完全隔离，一些互联网流量需要有序地引进来，一些内网机器也需要访问外网。**
**这就是一个如何在VPC上“开口子”的问题了。**
当然，你可以使用前面提到的弹性IP，绑定到相关虚拟机上。不过，如果我们需要访问外网的虚拟机数量有很多，这种办法就需要很多弹性IP，管理上就太麻烦了，成本也不划算。还有一个问题是，弹性IP带来的是双向的开放，有时我们只想允许单向的连接。
这就是**网关**可以大显身手的场景了，它正是用来统一协调管理私有网络与外部通信的组件。随着各个公有云的发展，云上也延伸出了许多不同形式、解决不同目的的网关产品。
我们这里讨论一个常见的场景，即**如何允许多台没有公有IP的虚拟机访问外网**。这时需要使用到的网关叫做**NAT**（Network Address Translation）网关，是一种常见的用来给VPC开口的手段。
我们继续以阿里云为例，来看下**如何通过NAT网关让虚拟机访问外网**。
我们可以事先把弹性IP从刚才那台虚拟机解绑，这下它现在又无法访问外网了：
```
root@vm1-in-vpc1:~# curl myip.ipip.net
curl: (7) Failed to connect to myip.ipip.net port 80: Connection timed out
```
接着我们创建一个NAT网关实例，并选择它对应的VPC，然后把刚才解绑的弹性IP(47.102.139.39)绑定到NAT网关上：
<img src="https://static001.geekbang.org/resource/image/56/a1/5689212f374b81d6737e156dc50d9ca1.jpg" alt="">
这里的关键之处在于**接下来我们要添加的SNAT条目**。
SNAT是“源地址转换”的意思，它非常适合让私有网络的主机共享某个公网IP地址接入Internet。注意，**这是一种从内向外的、单向的连通形式**。
<img src="https://static001.geekbang.org/resource/image/7d/5f/7dd66c1b4495261b579f2c06a201a65f.jpg" alt="">
上面我们添加了一个SNAT条目，让整个交换机“test-vpc1-vsw2”下的网段都共享一个出口公网IP。你要注意，**我们的虚拟机是位于这个网段内的**。
接着再回到这台虚拟机内，我们通过curl命令，尝试对外访问：
```
root@vm1-in-vpc1:~# curl myip.ipip.net
当前 IP：47.102.139.39 来自于：中国 上海 上海 阿里云/电信/联通/移动/铁通/教育网
```
很棒，这回成功地连通了。而且外部网站也显示，我们正在使用的外网IP正是那个弹性IP(47.102.139.39)。这就是对于NAT网关的一个小小实验了。
还有一种网关被称为**VPN网关**，也可以帮助外界连接到VPC，它本质上是基于你所熟知的VPN技术。由于VPN能够基于互联网提供私有加密的通信，因此非常适合用来从任意其他私有设施安全地连接到VPC。这些私有设施可以小到一台个人电脑或手机终端，也可以大到是你本地的数据中心，还可以是另一个VPC。
## 多网连接有哪些方式？
前面我们主要是从单个VPC的角度来进行讨论的，那么最后，我们再来讨论一下多VPC的场景。**公有云上是允许你同时使用多个VPC的，这样你可以构建更加复杂的网络架构，实现模块隔离和跨区域扩展等高级需求。**
如果是云端VPC和VPC的互联，我首先推荐的就是**对等连接**（VPC Peering）的方式。它能够在不添加额外设备的情况下，让两个VPC无缝地互联起来，而且操作非常简单，对等连接甚至还能够支持跨区域的私有网络互联。当然，对等连接的实施前提，是这两个VPC的网段没有交集，不存在冲突。
**这里你需要注意对等连接的一个特点，就是它不具备传递性。**也就是说，如果A和B建立了对等连接，B和C建立了对等连接，那么A和C是不相通的。这是对等连接的一个局限。
如果你真的需要多个VPC间任意路径的互联互通，那么可以考虑使用比对等连接更为复杂和强大的**专用网络设施**，比如AWS的Transit Gateway，和阿里云的云企业网，它们能够帮助搭建更为复杂的多VPC网络拓扑结构，也允许进行更精细的路由设置。如有需要，建议你仔细阅读厂商的文档进行学习和研究。
公有云中的私有网络，还可以和企业本地数据中心进行互联，形成**混合云架构**。你可以先考虑使用VPN这种轻量的方式，通过公网线路为两边建立连接渠道。但如果应用场景要求保证延迟和带宽，一般就需要专线进行连接了。绝大多数的云厂商，都提供了云端区域和本地数据中心进行高速互联的服务和解决方案，比如AWS的Direct Connect、Azure的ExpressRoute和阿里云的“高速通道”（云下IDC专线接入）等等。一般专线还会和VPN一起组合使用，来保证通道的高可用性。
小提示：与较为易用的VPC互联相比，混合云的构建是一项较为复杂的工程，通常需要由本地机房、云厂商、电信运营商三方配合进行，也牵涉到本地数据中心端的网络规划和路由设备适配。这超出了我们开发者课程的范畴。如需实施，建议你仔细咨询云厂商工作人员。
## 课堂总结与思考
今天，我主要为你介绍了云上虚拟网络，包括它的具体组成、使用场景和连接性问题。我还给你推荐了一些在生产环境下的最佳实践。
从某种程度上来说，虚拟私有网络的“仿真度”非常高，在软件定义网络（SDN）技术的加持下，甚至比物理网络还要更加灵活高效，更易于扩展。所以，**通过合理的规划和设置，云端的网络基础设施能够让我们拥有一个健壮而强大的网络拓扑结构，对于流量的引导和控制，也完全能够做到因势利导、开合有度。**
需要特别说明的是，在主体理念保持一致的情况下，各个云厂商在具体实现上，其实是各显神通的，会有一些细节存在差异。这是正常的现象，请你在实践时注意。比如说，和阿里云不同，AWS的VPC中访问外网，需要经由专门的Internet Gateway来通行流量，路由表中也需要进行相应的设置。
**好了，今天我给你留下的思考题是：**
- 在虚拟私有网络的内部，两机互联的带宽有多大呢？可能受到哪些因素的影响？
- 在今天的实验中，我们通过NAT网关实现了流量“出网”的目的。那么，如果是反过来需要引导外界流量进入VPC，应该使用什么方式呢？
欢迎你在留言区和我互动，我会一起参与讨论。如果觉得有收获，也欢迎你把这篇文章分享给你的朋友。感谢阅读，我们下期再见。

189
极客时间专栏/深入浅出云计算/IaaS篇/07 | 云端架构最佳实践：与故障同舞，与伸缩共生.md Normal file
View File

@@ -0,0 +1,189 @@
<audio id="audio" title="07 | 云端架构最佳实践：与故障同舞，与伸缩共生" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/82/97/82898948918ea25538858fd93a22e297.mp3"></audio>
你好，我是何恺铎。这一讲，我们来谈谈云上架构的注意事项和最佳实践。
云上架构最需要注意什么呢？就像我在标题所描述的那样，云端架构一方面需要处理和应对可能出现的**故障**，保证架构和服务的可用性；另一方面则是需要充分利用好云端的**弹性**，要能够根据负载进行灵活的伸缩。
## 面对故障，提升冗余
故障，是IT业界的永恒话题。故障的原因多种多样，无论是由于硬件的自然寿命造成的，还是数据中心的极端天气捣鬼，或是人工运维操作上的失误，不论我们多么讨厌它，故障似乎总是不可避免。
你也许会问，**那么，云计算会有故障吗？比如说，云上创建的虚拟机，是否百分之百会工作正常呢？**
很遗憾，虽然公有云们为了避免故障，在许多层面上做了冗余和封装，但云也不是可以让你永远无忧无虑的伊甸园。我们需要牢记，云端的服务仍然是有可能出故障的，只是概率上的不同而已。这也是云供应商们为云服务引入**服务等级协议**（Service Level Agreement，简称SLA）的原因，它主要是用来对服务的可靠性作出一个预期和保证。
SLA的可用性等级可能是99.9%，也可能是99.99%，它能够表明某项云服务在一段时间内，正常工作的时间不低于这个比例，也代表了厂商对于某项服务的信心。不过你要知道，再好的服务，即便是SLA里有再多的9，也不可能达到理论上的100%。
小提示：当实际产生的故障，未达到SLA的要求时，云厂商一般会给予受到影响的客户以消费金额一定比例金额的赔付。不过很多时候，赔付的金额不足以覆盖业务上的经济损失，你不应该依赖它。
所以，从架构思维的角度上来说，我们需要假定故障就是可能会发生，对于它的影响事先就要做好准备，事先就进行推演并设置相关的冗余和预案。AWS有一个非常著名的架构原则，叫做**Design For Failure**，讲的也就是这个意思。
好在云上做高可用架构同样有自己的特点和优势，我们可以轻松地调用各个层面的云端基础设施来构建冗余，规避单点的风险。
**那么，云上可能出现哪些不同层面的故障？相应的故障范围和应对措施又会是怎样的呢？**我们不妨从小到大，依次来看我们可能遇到的问题和解决办法。
**第一种故障是在宿主机的级别，这也是从概率上来说最常见的一种故障。**当宿主机出现硬件故障等问题后，毫无疑问将影响位于同一宿主机上的多个虚拟机。为了避免产生这样的影响，当我们承载重要业务时，就需要创建多台虚拟机组成的集群，共同来进行支撑。这样，当一台虚拟机出现故障时，还有其他几台机器能够保证在线。
这里需要注意的是，**我们需要保证多个虚拟机不在同一台宿主机上，甚至不处于同一个机架上，以免这些虚拟机一起受到局部事故的影响。**那么，要怎么做到这一点呢？
虚拟机的排布看似是一个黑盒，但其实在公有云上是有办法来对虚拟机的物理分配施加干预，让它们实现分散分布，隔开一段距离的。这一特性，在AWS称为置放群组（Placement Group），Azure称为可用性集（Availability Set），阿里云对应的服务则是部署集。比如说，我们对阿里云同一个可用区内的虚拟机，在创建时选择同一个部署集，就可以保证相当程度的物理分散部署，从而最大限度地保证它们不同时出现故障了。
**第二种规模更大的故障，是在数据中心，也就是可用区的层面。**比如火灾、雷击等意外，就可能会导致数据中心级别的全部或者部分服务类型的停摆。有时一些施工导致的物理破坏，也会挖断光纤，影响可用区的骨干网络。
要应对这类故障，我们就需要**多可用区的实例部署**，这也是云抽象出可用区概念的意义所在。你的实例需要分散在多个可用区中，这样，可用区之间既可以互为主备，也可以同时对外服务，分担压力。另外，也不要忘记我在[上一讲](https://time.geekbang.org/column/article/211071)中所提到的，虚拟私有网络可以跨越可用区，这会大大方便我们多可用区架构的搭建。
**第三种更严重的故障，就是整个区域级别的事故了。**当然这种一般非常少见，只有地震等不可抗力因素，或者人为过失引发出的一系列连锁反应，才有可能造成这么大的影响。
区域级别的事故一般都难免会对业务造成影响了。这时能够进行补救的，主要看**多区域架构层面是否有相关的预案**。如果是互联网类的服务，这时最佳的做法，就是在DNS层面进行导流，把域名解析到另外的一个区域的备用服务上，底层的数据则需要我们日常进行着跨区域的实时同步。
再更进一步的万全之策，就需要考虑**多云**了，也就是同时选用多家云厂商的公有云，一起来服务业务。虽然集成多个异构的云会带来额外的成本，但这能够最大限度地降低服务风险，因为两家云厂商同时出问题的概率实在是太低了。更何况，多云还能带来避免厂商锁定的好处，现在其实也越来越多见了。
综上所述，不论是哪种级别的故障，我们应对的基本思想其实没有变化，都是化单点为多点，形成不同层面、不同粒度的冗余。当故障发生时，要能迅速地发现和切换，平滑地过渡到备用的服务和算力上。
当然，盲目地追求可用性也不可取。**根据业务需求，在成本投入与可用性之间获得一个最佳的平衡，才是你应该追求的目标。**试想一下，构建一个个人博客网站，和建立一个金融级系统，两者在可用性架构方面的要求显然天差地别，所以我们最后的架构选择也会大相径庭。
## 随机应变，弹性伸缩
弹性伸缩，这是云上架构的另一个原则，也是云端的重要优势。
由于云的本质是租用，而且它便捷的操作界面、丰富的SDK和自动控制选项，使得云上“租用”和“退租”的成本很低，可以是一个很高频的操作，这就为弹性伸缩在云上的出现和兴起提供了土壤。在妥善应用之下，弹性伸缩既可以提高工作负载洪峰来临时的吞吐和消化能力，提高业务稳定性，又能够在低谷期帮我们显著地节约成本。
在IaaS端，能够弹性伸缩的最实用的产品形态，莫过于**虚拟机编组**了，也就是功能相同的多个虚拟机的集合。把它们作为一个单位来创建、管理和伸缩，是一种普遍应用的最佳实践。AWS中相关的产品命名是 EC2自动伸缩（Auto Scaling），Azure中是虚拟机规模集（VM Scale Set），阿里云则叫做弹性伸缩。
我们把多个虚拟机以弹性伸缩组的方式进行统一管理，能够极大地提高效率，减轻负担。因为弹性伸缩服务，会帮我们动态地创建和销毁虚拟机实例，自动根据我们指定的数量和扩缩容规则，来协调虚拟机的生命周期。我们只需要从高层进行指挥就可以了。
弹性伸缩服务，在云端还有一个最佳拍档，就是**负载均衡器**。它特别适合将流量均匀地，或者按照一定权重或规则，分发到多台虚拟机上，正好可以和提供计算资源的弹性伸缩服务形成配合。当负载增大、虚拟机增加时，负载均衡也能够自动动态识别，将流量分发到新创建的虚拟机上。
**所以，你可以尝试使用弹性伸缩服务来实现云端弹性架构，用它来管理一组虚拟机，并与负载均衡一起配合。这特别适合处理无状态类的计算需求，因为它会为你代劳底层计算资源的管理。**
## 高可用的弹性架构实战
结合上面的介绍，让我们进入这一讲的实战环节。
**我们来模拟一个线上高可用服务的场景，来看下如何用阿里云进行服务的搭建。**我会在上一讲搭建的虚拟私有网络的基础上来提供服务，并做到一定程度的故障隔离和弹性扩展。
我们先用Node.js来搭建一个简单的Web服务，用来计算著名的“斐波那契数列”。相关的源码如下，供你参考：
```
const express = require('express');
const ip = require('ip');
const os = require('os');
const app = express();
//使用递归计算斐波那契数列
function fibo (n) {
return n &gt; 1 ? fibo(n-1) + fibo(n-2) : 1;
}
app.get('/', function(req,res) {res.write('I am healthy'); res.end();} );
app.get('/fibo/:n', function(req, res) {
var n = parseInt(req.params['n']);
var f = fibo(n);
res.write(`Fibo(${n}) = ${f} \n`);
res.write(`Computed by ${os.hostname()} with private ip ${ip.address()} \n`);
res.end();
});
app.listen(80);
```
我们在上一讲创建的虚拟机“vm1-in-vpc1”中安装好Node环境，将上述代码放入一个起名为“app.js”的文件中，用npm安装express等相关依赖后，就可以用命令“node app.js”直接运行了。然后，我们需要把这个服务设置为**开机自动启动**（你可以通过npm安装pm2组件来帮助实现开机自动启动），这样一个简单的Web服务就搭建好了。
为了让之后的外部流量能够进入到内部网络的多台虚拟机中，我们来建立对外的负载均衡实例。要注意，**负载均衡器本身也需要是高可用的**，我们这里主要选择华东2区域下的可用区D，让可用区E作为备可用区，和我们的VPC保持一致。
<img src="https://static001.geekbang.org/resource/image/52/c9/5274fe3666a25c941e4c5d76ec89dcc9.jpg" alt="">
然后，在负载均衡器上配置一个HTTP协议80端口的监听，后端服务器可以先指向我们的测试机vm1-in-vpc1，然后从外部测试负载均衡器的连通性。
<img src="https://static001.geekbang.org/resource/image/af/ac/afb92ee39cb4e3377de7ff0d1ecfaeac.jpg" alt="">
```
[client@clientVM ~]$ curl http://47.101.77.110/fibo/35
Fibo(35) = 14930352
Computed by vm1-in-vpc1 with private ip 192.168.1.80
```
可以看到，curl命令的响应中，成功地返回了斐波那契数列第35项的结果值，以及相关服务器的名称、IP等信息，说明负载均衡已经初步正常工作了。
接下来，我们要创建一个能够弹性伸缩的虚拟机集群，来大规模地对外输出这个计算服务。
作为准备工作，我们要先为vm1-in-vpc1创建一个镜像，作为新建虚拟机的“种子”：
<img src="https://static001.geekbang.org/resource/image/b6/74/b67955f2983617f2dd30a42cd99f9b74.jpg" alt=""><br>
<img src="https://static001.geekbang.org/resource/image/4f/3c/4f3a8f4bf1b93db474b84a03f8ab0f3c.jpg" alt="">
然后，我们就可以创建弹性伸缩实例了。我们来建立一个最小数量为2，最大数量为10的伸缩组。在这个过程中，你尤其需要注意，**要选取上一讲中建立的VPC作为目标网络，同时选择两个分属不同可用区的交换机，并设置为均匀分布策略**。如下图所示：
<img src="https://static001.geekbang.org/resource/image/be/0c/be7010dd8ab2eabe6c8ef239ebe65a0c.jpg" alt="">
同时在这里，我们还为伸缩组和刚才建立的负载均衡器建立了关联，这样弹性伸缩实例中的机器，会自动地进入到负载均衡后端服务器的列表中。
下一步是建立伸缩配置，这里主要是指定虚拟机模板，记得选取我们刚才创建好的自定义镜像：
<img src="https://static001.geekbang.org/resource/image/93/2c/93853f924884adbd5ea53c12a904062c.jpg" alt="">
启用伸缩配置后，很快就能看到弹性伸缩服务为我们建立了两台虚拟机了：
<img src="https://static001.geekbang.org/resource/image/8b/51/8bbd864dbff87b209bc032da79679b51.jpg" alt="">
在ECS控制台，你也可以清楚地看到，这两台机器被自动分配到了不同的可用区中，分属不同的交换机：
<img src="https://static001.geekbang.org/resource/image/25/10/25fee9d72ee318093a5bd4c8d5896010.jpg" alt="">
我们再设置一下非常重要的伸缩规则，**这会告诉伸缩组何时进行自动扩缩容**。这里我们选择监控平均CPU指标，我们希望理想状态下控制在50%左右。换句话说，如果平均CPU偏离50%太远，系统就会自动地为我们增加或减少机器。
<img src="https://static001.geekbang.org/resource/image/32/c0/32ff1e7782b5180845cc2b4e53d12dc0.jpg" alt="">
回到最佳拍档**负载均衡**的管理界面，我们也看到弹性伸缩组中的两台机器，已经位于后端服务器列表中了（这时可以将测试机vm1-in-vpc1从后端服务中删去）：
<img src="https://static001.geekbang.org/resource/image/e9/63/e976f949ed609fc6ed77014f7cfde063.jpg" alt="">
我们试着来反复地访问负载均衡端的同一个入口URL，会获得来自不同可用区中不同机器的响应，这说明负载均衡的**随机分发**起到作用了：
```
[client@clientVM ~]$ curl http://47.101.77.110/fibo/35
Fibo(35) = 14930352
Computed by iZuf68viqv1vrqntkpyihaZ with private ip 192.168.0.234
[client@clientVM ~]$ curl http://47.101.77.110/fibo/35
Fibo(35) = 14930352
Computed by iZuf67wyymbgnnd69wkf31Z with private ip 192.168.1.89
```
最后也是最精彩的部分，**我们来使用siege命令来持续冲击这个负载均衡，使集群的平均CPU升高，看看它是否会自动扩容。**
```
[client@clientVM ~]$ siege -c 15 -t 20m http://47.101.77.110/fibo/35
** SIEGE 4.0.2
** Preparing 15 concurrent users for battle.
The server is now under siege...
HTTP/1.1 200 0.14 secs: 88 bytes ==&gt; GET /fibo/35
HTTP/1.1 200 0.16 secs: 87 bytes ==&gt; GET /fibo/35
HTTP/1.1 200 0.28 secs: 88 bytes ==&gt; GET /fibo/35
HTTP/1.1 200 0.29 secs: 87 bytes ==&gt; GET /fibo/35
HTTP/1.1 200 0.41 secs: 88 bytes ==&gt; GET /fibo/35
...
```
果然，流量到来后，虚拟机的CPU飙升，伸缩组就自动地进行了新实例的创建，一直达到了我们设定的十台上限，以满足汹涌到达的计算请求。
<img src="https://static001.geekbang.org/resource/image/b3/82/b329026b1adfc5fc8e6294496012ee82.jpg" alt="">
<img src="https://static001.geekbang.org/resource/image/fd/f8/fd03d6cc2a9228decbca5fb962e372f8.jpg" alt="">
当siege命令停止后，平均CPU大幅降低，伸缩组还能自动地缩容，减少实例数量。上面的伸缩活动的截图也体现了这个过程。
至此，我们的跨可用区负载均衡的实验就大功告成了。
你也可以结合你实际的场景，来进一步地实验和拓展这个范例。比如在生产环境中，你通常需要为负载均衡的外部IP绑定正式的域名；或者你的Web服务很可能不是完全无状态的，需要依赖后端数据库；再比如，你可以尝试在别的区域再建立一个VPC，让两个VPC互相连接，新VPC可以作为冷备，或者承担日志数据分析的工作，这样能够形成一个类似“两地三中心”的强壮架构。
## 课堂总结与思考
今天涉及的点比较多，我们谈到了故障范围和故障处理，也谈到了云端的弹性优势。这次的实验也相对大一些，比较完整地构造了一个负载均衡加弹性伸缩的架构。不知道你掌握得怎样，有没有相关的问题，欢迎你在这里留言，和我一起探讨。
**今天我留给你的思考题是：**
- 大多数云上负载均衡产品都有一个重要特性，叫做“**会话保持**”，你知道它是用来做什么的吗？它的原理又是什么呢？
- 默认情况下，弹性伸缩服务会使用按量计费的虚拟机。那么成本上更有优势的包年包月虚拟机，或者竞价实例的虚拟机，能够融入弹性伸缩的体系吗？
好了，今天我们就到这里。如果你觉得有收获，欢迎把这篇文章分享给你的朋友。感谢阅读，我们下期再见。

193
极客时间专栏/深入浅出云计算/IaaS篇/08 | 云上运维：云端究竟需不需要运维？需要怎样的运维？.md Normal file
View File

@@ -0,0 +1,193 @@
<audio id="audio" title="08 | 云上运维：云端究竟需不需要运维？需要怎样的运维？" controls="" preload="none"><source id="mp3" src="https://static001.geekbang.org/resource/audio/78/f3/784d1a993daa7db2ffbf35a05e813bf3.mp3"></audio>
你好，我是何恺铎。
谢谢你的努力和坚持，我们已经学习了IaaS篇中的大多数内容。今天是IaaS部分的最后一讲，我们来谈谈云上的运维工作。
## 云端需要运维吗？
既然要谈运维，我们得先回答这个必要性的问题。许多人都觉得，因为云服务大多都具有了非常高的可靠性和自动化程度，所以在云时代，运维就不那么重要了，甚至是可以省略的事情了。
这种观点有意无意地散播，其实会造成一些负面的影响。**开发者会容易轻视运维工作的重要性，忽略架构设计中运维友好性问题；而从事运维方向的工程师们，可能更会有点儿焦虑，甚至于担心未来的职业生涯。**
但很显然，这是一种误解。云端当然需要运维，而且云上运维很重要。因为不管在什么样的运行环境下，运维的本质和需求都没有消失，一样要为业务保驾护航，要保证系统的正常运作、应对突发情况等等。
云时代的运维，正确的理解应该是这样的：**云不但没有消灭运维，反而是助推了运维的发展**。
这是因为，云的引入能够让我们在更高的层面去思考和解决问题。比如说，云端基础设施的存在，可以让运维从偏硬件服务器、偏物理机房的日常繁琐工作中解脱出来，更多地基于云在**软件的层面**，进行部署、监控、调整。而云上的高质量、高可用的服务，也能避免我们重复建设，不用自己造轮子，也大大减轻了运维负担。
注意：底层的机房运维、基础架构运维仍然会继续存在，但会向头部的云供应商大规模集中。这属于云厂商的运维视角，是另一个宏大的话题，我们这里不多做讨论。
**所以，云其实是提高了运维的效率，改变了运维的形态。**
与此同时，由于云上运维的**软件属性**显著增强了，它就自然地和研发会有更强的融合。近期DevOps理念和云原生热潮的兴起，就说明了这一点。许多工作，你慢慢地会分不清它究竟是属于运维还是研发，因为两者的界限正在模糊。
另外，由于云独有的一些特点，它也会带来一些新的运维工作。比如我们课程中一直在涉及的**成本控制**，这也是云时代新运维所应当关注和包含的重要事项。因为云的成本消耗是动态、时刻发生着的，这和传统运维中的各类实时监控的对象，在形态上非常接近。
所以，云端需要运维吗？答案已经不言而喻了。
## 云时代的运维利器
工欲善其事，必先利其器。为了做好扎实的云上运维，首先我给你的一个建议是，你需要掌握云的**命令行工具**。现在几乎每个云都推出了自己的命令行工具，比如AWS CLI、Azure CLI、阿里云CLI等等。
在前面各讲的例子中，为了便于你学习和理解，我都使用了公有云的网站门户来进行操作。但如果是在生产环境，你需要对很大规模的资源池逐个进行调整，或者同一件事情，你需要在不同时间反复地操作很多遍，那你就很可能需要将这些操作脚本化、程序化，这就需要用到云的命令行工具了。
虽然命令行工具有一定的学习曲线，但如果你熟悉了以后，其实是可以干脆利落地表达一个操作的。比如说，如果你要创建在[第6讲](https://time.geekbang.org/column/article/211071)的实验中，使用的虚拟机“vm1-in-vpc1”，你就可以使用下面的**aliyun ecs命令**来轻松表达：
```
[client@clientVM ~]$ aliyun ecs CreateInstance --ImageId ubuntu_18_04_x64_20G_alibase_20191225.vhd --InstanceType ecs.g6.large --ZoneId cn-shanghai-e --VSwitchId vsw-uf6ls7t8l8lpt35xxxxxx
{
&quot;InstanceId&quot;: &quot;i-uf6hn8z47kqve3xxxxxx&quot;,
&quot;RequestId&quot;: &quot;222DA83B-0269-44BF-A303-00CB98E4AB07&quot;
}
[client@clientVM ~]$ aliyun ecs StartInstance --InstanceId i-uf6hn8z47kqve3xxxxxx
{
&quot;RequestId&quot;: &quot;8E4C43CA-8F36-422C-AEF1-14ED5023856D&quot;
}
```
现在各个云的CLI基本上都进化到了第二代，相比第一代，CLI在易用性和表达能力上都有了很大的提升，你不妨学习尝试一下。而且这些CLI都能和Shell编程进行比较好的融合，你可以通过脚本组合多个关联的操作。
小提示：除了命令行工具，各云还都提供了开发者工具包（SDK）。如果你的资源调度逻辑相当复杂，或者需要与你自己的程序集成，那么你可以考虑使用相应语言的SDK，来进行云上的一些资源管理操作。
如果你要频繁地在云上部署一套包含众多资源项的复杂系统，你还有另外一个得力的帮手：**资源编排类云服务**。属于这个领域的服务包括有AWS CloudFormation、 Azure的ARM Template、阿里云资源编排服务（ROS）等等，它们都可以通过使用一个JSON格式的文本文件，来描述和定义一个系统中所有的组件，以及它们互相之间的关系。
这个JSON文件，就是一个可以自动部署、可复用的单元了。这其实就是“基础设施即代码”（Infrastructure as Code）理念在云端的实现。
下面我给出了一个Azure的ARM Template的配置文件局部示例，可以让你有一个直观的感受：
```
{
&quot;$schema&quot;: &quot;https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#&quot;,
&quot;contentVersion&quot;: &quot;1.0.0.0&quot;,
&quot;parameters&quot;: {
&quot;adminUsername&quot;: {
&quot;type&quot;: &quot;string&quot;,
&quot;metadata&quot;: { &quot;description&quot;: &quot;This is the username you wish to assign to your VMs admin account&quot; }
},
...
},
&quot;variables&quot;: {
&quot;nicName&quot;: &quot;VMNic&quot;,
&quot;addressPrefix&quot;: &quot;10.0.0.0/16&quot;,
&quot;imagePublisher&quot;: &quot;Canonical&quot;,
...
},
&quot;resources&quot;: [
{
&quot;apiVersion&quot;: &quot;2015-05-01-preview&quot;,
&quot;type&quot;: &quot;Microsoft.Network/publicIPAddresses&quot;,
&quot;name&quot;: &quot;[variables('publicIPAddressName')]&quot;,
&quot;location&quot;: &quot;[parameters('location')]&quot;,
&quot;properties&quot;: { &quot;publicIPAllocationMethod&quot;: &quot;[variables('publicIPAddressType')]&quot; }
},
{
&quot;apiVersion&quot;: &quot;2015-05-01-preview&quot;,
&quot;type&quot;: &quot;Microsoft.Network/virtualNetworks&quot;,
&quot;name&quot;: &quot;[variables('virtualNetworkName')]&quot;,
&quot;location&quot;: &quot;[parameters('location')]&quot;,
&quot;dependsOn&quot;: [
&quot;[resourceId('Microsoft.Network/networkSecurityGroups', variables('networkSecurityGroupName'))]&quot;
],
&quot;properties&quot;: { ... }
},
{
&quot;apiVersion&quot;: &quot;2017-03-30&quot;,
&quot;type&quot;: &quot;Microsoft.Compute/virtualMachines&quot;,
&quot;name&quot;: &quot;[variables('vmName')]&quot;,
&quot;location&quot;: &quot;[parameters('location')]&quot;,
&quot;dependsOn&quot;: [ &quot;[concat('Microsoft.Network/networkInterfaces/', variables('nicName'))]&quot; ],
&quot;properties&quot;: {
&quot;hardwareProfile&quot;: { &quot;vmSize&quot;: &quot;[parameters('vmSize')]&quot; },
&quot;networkProfile&quot;: {
&quot;networkInterfaces&quot;: [
{ &quot;id&quot;: &quot;[resourceId('Microsoft.Network/networkInterfaces',variables('nicName'))]&quot; }
]
},
...
}
},
...
]
}
```
注：这个文件是用于配置单机WordPress网站的模板，这里略去了许多内容，其全貌可以参见[这个链接](https://github.com/Azure/azure-quickstart-templates/blob/master/wordpress-single-vm-ubuntu/azuredeploy.json)。
这类资源编排服务，理论上能够**支持云上所有服务的组合，而且配置节点互相能够引用**，功能十分强大。它还具有一定的灵活性，一般都有**输入参数字段**，允许你在部署时动态决定一些选项和参数值，还可以**自定义结果输出字段**，方便部署完成后告诉你一些结果信息。
在这类资源编排部署系统的帮助下，我们云端部署类的工作可以得到极大的自动化。
## 云运维由哪些工作组成？
有了趁手的工具之后，我们下一个需要讨论的问题就是，**云时代的运维具体有哪些重要的工作呢？哪些是和传统运维一脉相承的事情，哪些又是在云环境下所特有的内容呢？**
现在，我就和你一起来简单梳理一下。
**首先，在云端，传统的运维工作仍然存在，其中包括你所熟知的监控、部署、升级、备份等等。**只是操作手段会有所不同，比如在云上，我们可以利用前面说到的命令行工具和资源模板来进行部署。
**监控**一直是运维最核心的工作之一。几乎所有的云端服务都自带有一定的监控功能，默认提供了不少内置的维度指标和可视化图表，这些开箱即用的图表你要充分利用好，它们能够很好地帮助你了解相关服务的状态。
那么，如果自带的监控不够用怎么办？其实这些默认的统计监控的背后，往往都是由云的一个**大型统一监控服务**来支撑的，如AWS的CloudWatch和Azure的Monitor等等。你可以好好研究一下这类统一监控服务，通过它可以满足你更深度的自定义监控需求。
另外，这些你精心选择和设置的监控项，还能够和云上的仪表盘服务，以及报警服务联动，轻松实现运营监控的“大屏”和问题的实时报警。
<img src="https://static001.geekbang.org/resource/image/cb/a6/cb3d812198998cd4cce5bfe6b72024a6.jpg" alt="">
这里我还想再多谈一谈**备份**。
备份是一个简单但又很容易被我们忽视的事项。即便是在云端，尽管云厂商已经做了许多如三副本之类的防护措施，但还是会存在出故障的可能，所以我们仍然需要做好备份，尤其是重要数据的备份。**总之，我们在云上需要创造多层次的冗余，而备份在创造冗余方面也承担着重要的角色，有的时候，它会是我们的最后保障。**
在IaaS的虚拟机层面做备份，你的得力助手会是**镜像**和**快照**。
镜像我们在[上一讲](https://time.geekbang.org/column/article/212714)中已经接触过了，它可以用来恢复虚拟机；快照则是云磁盘级别对应的备份概念，它可以帮助你将某块磁盘某一时刻的状态进行封存和恢复，你还可以定期定时为一些重要磁盘自动生成快照。
<img src="https://static001.geekbang.org/resource/image/c5/db/c57c8f11c1c1b3cda41c8b442f7621db.jpg" alt="">
注意：不要小看镜像和快照这样简单基础的操作，像在[第5讲](https://time.geekbang.org/column/article/210423)中提到过的创业公司严重事故，就完全可以通过简单的磁盘快照进行避免。因为快照的存储本身不依赖于云盘，这就是额外的冗余。
除了虚拟机和磁盘层面，文件层面的备份同样重要而有效。而且文件的备份最好还能以异地的方式来存储。云上的对象存储可以在这方面肩负重任，我在PaaS篇中会做专门讲解。
**其次，你的运维工作中很可能包含迁移。**
这是带有云端特色的运维任务，因为**只要不是在云上创建的全新业务，传统业务在逐步上云的过程中一定会面临迁移工作**。
迁移显然是非常大的一个话题，有些复杂的迁移项目，持续的时间可能长达几个月。这里我想告诉你两点**最核心**的建议：
- 第一，在生产业务切换过来之前，一定要对云上的新架构、新方案进行充分而深入的POC测试，不可操之过急。对于复杂场景，可能要通过不断地实践，才能够逐步进化出完善的云上解决方案。
- 第二，对于一些虚拟机、数据库等独立的软硬件单元，许多云厂商都提供了官方的迁移服务或工具，支持离线甚至在线迁移，妥善使用可以事半功倍。比如AWS的主机迁移服务SMS（Server Migration Service）、数据库迁移服务DMS（Database Migration Service）和阿里云的数据传输服务DTS（Data Transmission Service）等。
所以，当你遇到一些迁移场景时，不妨先查一查云厂商是否有官方的支持。由于迁移类服务能够直接为厂商导流获客，所以云厂商一般都会比较重视，往往能给你提供相当好的用户体验。
**再次，云上的运维会包含和云厂商进行对接的工作。**
毕竟我们的大厦是建立在云厂商所提供的基础设施之上的。云虽然已经高度成熟，但作为一个高度复杂的系统，也总难免会有不按你所期望进行工作的时候，或者极为偶尔也会出些小Bug，这时和云厂商的对接渠道就显得尤为重要了。
所以，我们的运维团队中需要有相应的角色对云的工单机制，以及技术支持侧的对接方式了然于胸，以备不时之需。你也要熟读文档，要吃透云计算的许多特性，这样才能更准确地与客服沟通，更快地寻求到对口的帮助，最后解决好问题。
**最后，云上运维会具有很强的管理属性。**
这里的管理，指的不仅仅是对云上资源的管理，更要深入到流程和制度的管理层面。比如对于云资源的命名、开通、清理等日常操作的规范，各类云上安全的控制和最佳实践，所有云资源的负责人、所属资源组和权限体系等等。这些都需要有效的管理手段，才能避免资源在云上的野蛮生长。
**所以，高明的云上运维，既要为应用开发赋能，要足够高效，也要有适当的管理和约束。我们团队的组织架构和分工，最好也能够配合和适应这个需要。**
好在云厂商也在不断推出和完善与云上管理相关的配套服务，比如说，Azure Policy能够限定只有某类型号的资源可以被创建，还可以扫描和检查各种最佳实践是否得到了应用；再比如，AWS CloudTrail能够对账户内的操作进行监控和审计。如果你的组织内用户（团队成员）较多，就值得好好探索研究一下这一类的云服务。
当然，管理层面还有一项重要事务，就是我们多次提到的**成本管理**。公司或团队中，应当有专人对成本进行监控和分析，以此提升每一位用户的成本意识。我自己曾使用的实践，是按月来组织资源的使用方进行成本消耗的回顾，分析资源使用的上升、下降趋势及其主要原因，同时还会检查月度账单明细，以杜绝成本浪费。
## 课堂总结与思考
今天这一讲，与其说是教程，不如说是和你一起探讨云上运维的相关要点。因为篇幅所限，今天我主要总结介绍了那些最重要的，和你最需要了解的内容，没有办法深入探究每一个与运维相关的细节。但你必须知道这些事务的存在，明白云上运维需要做哪些事情，这样在你需要的时候，才能有针对性地去查找资料，找到怎么做这些事情的方法。
当前业界的一个重要趋势是，运维和开发的边界正在模糊。所以我在前面提到的诸多运维工作，可能是由开发者来负责，也可能是运维人员来承担。这要根据你们公司和部门的具体情况来决定。但至少，这些工作很重要，无论由什么角色来完成，总是需要有人来扎实落地的。
所以从个人视角来看，作为开发者，你应该学习和掌握一些运维的知识和技巧，让自己变得更加全面和综合；如果作为运维人员，你也应该学习了解现代软件构建和系统架构方面的知识，尤其是学习云、掌握云，为云端架构的全面到来做好准备。
**今天留给你的思考题是：**
- 如果要执行一些云上的CLI命令，你当然可以在自己的机器上安装命令行工具包，但其实你还可以使用不少云都提供的非常方便的“Cloud Shell”。那你知道什么是Cloud Shell，以及要如何使用它吗？
- 前面讲到云上资源管理时，我提到了“资源组”的概念。你知道资源组是什么吗？它起到什么作用呢？
好，至此我们课程IaaS部分的8篇内容就全部结束了，希望你有所收获。下一讲，我们将进入精彩的PaaS世界。欢迎你留言与我交流，咱们下期再见。