阿里云贾少天：大规模云服务器高效使用及管理实践

Posted 2022-02-14 阿里云云栖号

简介：本篇内容分享了大规模云服务器高效使用及管理最佳实践。

2021年10月22日，在云栖大会的《云上运维最佳实践》分论坛，阿里云高级技术专家贾少天发表了主题为“大规模云服务器高效使用及管理最佳实践”的演讲，本篇内容根据他的演讲整理成的文章，主要通过以下三个部分来介绍大规模云服务器高效使用及管理最佳实践。

1. 如何快速上云
2. 如何低成本的构建大规模资源场景
3. 如何高效的管理资源

01  如何快速上云 

我们把上云分为四个阶段：上云前整体评估、上云迁移的过程、上云迁移的验证、线上业务切换。我们今天带给大家的服务器迁移中心产品就是帮助大家优化迁移的过程和迁移的验证，让这一部分更快速高效的进行。

迁移现存三种方式：

◾ 第一种，重新部署迁移。就是把原来在线下的环境在云上重新一步一步再操作一遍，这种方式不管是易用性、速度、还原度方面都不是推荐的方式。

◾ 第二种，导出镜像方式。是在你自己本地的环境按照阿里云镜像规范导出一个镜像，然后上传到阿里云使用，系统还原度可以保证，但是容易度和速度还不是最优的办法。

◾ 第三种，使用阿里云的服务器迁移中心。你只需要下载一个客户端在本地运行，然后创建一个迁移任务，服务器迁移中心产品就会帮你自动执行整个迁移工作。

阿里云服务器迁移中心有哪些优势呢？

◾ 首先，它是高度成熟化的产品，支持行业里各种各样镜像。

◾ 第二，高度自动化。一行命令，整个过程无人值守。我们提供API和控制台，让你去观测整个过程和结果。

◾ 第三，高度智能化。从迁移开始，到执行过程中出现任何问题，都会自动进行相关的修复工作，让整个过程更加高效顺畅。

用户也可以根据自己的场景，迁移成多形态。我们也支持增量和全量迁移，达到线上和线下完全统一的效果；用户还可以根据自己的情况，选择多种复制模式。

服务器迁移中心是一个高度自动化的产品，支持批量多实例迁移，无论是什么规模的资源迁移都可以高效的支持，如果大家后续使用阿里云过程中遇到迁移问题，强烈建议大家使用这个产品。

02 如何低成本地构建大规模资源场景 

如何低成本的构建大规模服务器？这里有两个核心关键词：低成本、大规模。 我们看看到底怎么用最少的钱使用阿里云的ECS？

如果大规模使用ECS，第一个问题是如何高效？比如今天有一个业务高峰期，需要1000台机器，我们能不能在最短时间里快速交付这1000台机器？其次，能否以更低的成本使用这1000台机器？第三，这个机器能不能通过自动化的方式，减少人工参与，让管理和维护过程的成本更低？

先说高效部分，推荐大家使用ECS启动模板功能。不知道在座的各位来宾有哪位使用过ECS的启动模板这个功能，这是一个ECS配置数据的持久化工具。在阿里云上创建的任何ECS实例，都可以通过它去保存ECS实例的所有配置。后续任何时候，都可以通过这个配置快速创建实例，不再需要重新配置。而且每次的变化都可以通过版本的方式管理。即使之前没用过，想要用起来也很轻松，从任何一个已经存在的实例可以快速的生成一个启动模板，对应的配置就是这个实例的配置。

有了启动模板，除了快速创建实例，我们还有其他的使用方式。比如你当前需要创建一个高弹性的Web应用，像在线提供Web服务的场景，每天都有高峰期。高峰期使用更多资源，低峰期使用更少的资源。这样的话，可以用现有的启动模板，快速创建一个弹性伸缩组。

比如它有定时模式，当业务高峰期在早上8点，早上8点会定时去扩容。业务低峰期是晚上6点，在晚上6点定时会缩少机器；第二，可以是动态模式，当CPU超过50%时增加机器，当CPU低于40%时缩减机器；第三，手动模式，用户自己通过本地自建系统来触发伸缩活动。

除此之外，如果你想对整个过程有更全面的控制能力，  我们还提供生命周期挂钩的能力，比如伸缩组在帮你缩容资源的时候，你发现实例上还有一些日志文件需要备份，则可以通过生命周期挂钩拒绝当前的缩容行为，伸缩组可以帮助继续保留资源；还有通知能力，任何扩容缩容都可以通过钉钉、短信、邮件的方式通知给你。而且伸缩组还可以同时帮你打通实例与SLB和RDS的联通关系，帮忙用户通过这种方式快速构建高弹性的Web能力。

如果你不需要一个具备持续弹性能力的方案，只是需要批量的使用大规模的计算资源， 比如使用1000台机器。我们推荐使用弹性供应组。弹性供应组是为了满足批量大规模计算力交付的场景。比如当前需要10000个CPU，它可以根据使用弹性供应组的容量模式，去设定10000个CPU。系统会自动根据10000个CPU判断，当下需要创建多少实例。同时，你可以根据自己的成本考量，选择是否用按量或者Spot实例，进行配比承载自己的业务需求。

另外，我们还有多种交付类型。其中有成本优化模式，系统每次创建时都会以最低价格的实例进行创建，让你的成本降到最低；均衡模式可以帮你在多个可用区创建，提高系统的高可用能力等。为了满足更多的场景，弹性供应组提供了三种交付模式来满足不用需求，有持续交付的maintain模式，也就是一直帮你保持你需要的资源数量，也有一次性交付的request和instant模式，其中instant模式可以理解成RunInstances接口能力的升级版本，在原有runInstance只支持单个实例规格、单个可用区的基础上，增加了更全面的能力。

弹性供应组让交付过程更加顺畅，成功率越来越高。

如果大家使用以上的弹性能力来创建资源，可以轻松保障99.9%的弹性成功率，实现一分钟交付1000台ECS的效果。在这个基础上，你可以快速构建自己的弹性场景，任何快速高要求的极致弹性场景都可以通过这种方式快速构建起来。

刚才说到要降低成本，以低成本使用这些资源。先跟大家简单介绍一下Spot实例，它是后付费实例。它有两个特点，一个是低价，它的价格在按量实例一折和原价之间。另一个是容易被释放，你可以根据自己的可接受价格进行出价，如果当前出价低于市场价格，这个实例存在被系统释放的可能性。关键特点就是便宜但是有被释放的可能性。

如果当前业务场景基于全按量模式，或者部分按量构建。可以慢慢尝试通过部分Spot实例去替换现有的按量实例。随着Spot比例越来越高，成本也会无限趋近于最低，达到一折的效果。这个时候你肯定要问了，我如果用了这么多Spot实例，如果价格变化导致实例释放了怎么办，我的业务岂不是都会受到影响了？所以在这个基础上我们提供了更多能力来规避这个问题。

首先，Spot实例规格全部承载自己的业务场景，如果Spot实例价格过高了，所有业务全部被释放。所以我们推出了针对Spot场景的优化，当你使用Spot实例的时候，可以设置多个最低价格的实例规格进行创建，比如3种，如图中左边所示，通过多种实例规格打散的方式，可以避免单一实例的释放导致的问题。

同时，我们还叠加了第二种能力，Spot自动补偿机制。如果没有开启Spot补偿机制，所有的Spot释放之后有2分钟的断崖式异常，所有业务都会受损。如果开启了补偿机制，我们的系统会自动判断，提前5分钟进行一些替换实例的创建。在这些实例还没有释放之前，完成创建出来了，自动替换掉。所以中间不会再出现断崖式异常。通过这两种方式，你就可以更加轻松的使用spot实例来承载业务场景，同时达到降低整体资源成本的效果。

除了以上的基础能力，还有一些自动化的能力。这里简单举几个例子。首先，我们提供了弹性伸缩组的伸缩规则能力，有多种类型。

◾ 普通伸缩规则。它的定义方式是，当CPU大于20%时，扩容4台ECS。这种模式一般适用当前业务变化不频繁的场景，可以类比为手动空调。

◾ 步进伸缩规则。它是普通伸缩规则基础上的增强模式，可以设置多个区间，不同区间以不同的方式应对。这样，我们可以按照自己的经验积累，判断不同的负载情况，需要扩容多少，以便承载业务压力，灵活度更高一些，可以类比为半自动空调。

◾ 目标追踪伸缩模式。一种全自动的伸缩能力，使用这个策略你只需要知道当前负载保持在什么水位上。比如CPU保持在50%，系统会自动判断增加多少机器，或者缩减多少机器。这样的话，整个过程完全不需要人工干预，更加顺畅。

我们在这些基础上又增加了进一步的伸缩规则，即预测性伸缩规则。任何伸缩组如果开启了预测性伸缩规则，我们会用机器学习模型去学习过去1到14天整体资源的使用情况和负载变化。然后预测未来2天的负载变化情况，去生成根据预测结果，以小时为单位，自动为伸缩组生成定时任务，把资源提前准备出来。这种场景非常适合周期性的业务场景。比如你的网站每天的访问热点时间和规模都比较固定，就可以使用这个模式，开启了之后完全不需要再人工干预。

如果这个过程中出现了一些突发的流量，怎么预测呢？开启预测性模式的同时，可以通过叠加现有的目标追踪模式和其他各种模式。通过预测性去保证每天的周期性，通过目标追踪模式去应对突发性的情况。通过多种模式叠加，最终达到有效稳定的效果。

接下来，和大家分享一下滚动升级功能。滚动升级主要解决日常工作中经常遇到的发布问题。我们提供滚动升级，然后就会自动帮助你做。你只需要配置好今天分几批机器。更新前机器进入备用状态，这时候不对外提供服务。更新之后退出备用状态，对外提供服务。然后，再进入下一批。你也可以判断当前是否要重试，回滚，还是继续。通过整体的过程，最终达到发布的效果。通过这种方式可以降低整体发布成本，帮助大家更方便的完成日常应用发布的工作，而不需要自己构建一套发布体系。

刚才讲完了效率，低成本，还有自动化，我们来看两个客户的例子。首先是汇量科技，它把在线广告业务放在弹性收缩产品上。因为它的最终广告收益，是广告收入减去资源的成本，所以它的资源成本非常重要。同时，它也是使用大批量资源，所以它使用了弹性伸缩产品。然后通过设置按量和Spot的组合，同时开启Spot自动补偿机制，让整体成本控制在3-4折。

第二个客观例子是深势科技，一家做人工智能和分子模拟算法的公司。它的特点是全部以交互型任务为主。每次跑任务都需要大量资源和严格的成本控制。所以在这个场景下，选择了全Spot方式。把成本降到最低，同时每次也设置它的Spot最高值，来保证它不会超出整体的成本边界，最终满足它整体的业务场景。

03 如何高效的管理资源 

当你在阿里云上有了更多资源之后，下一步如何高效的管理？

因为管理资源有很多种场景，这里只列举三个场景：成本、效率、安全。

◾ 成本。当有很多团队参与资源使用且资源非常多时，如何知道哪些资源花了多少钱？如何知晓每个团队资源的费用情况？

◾ 效率。如何快速对接资源，高效进行一些日常运维的工作？

◾ 安全。当有越来越多子账号时，如何控制控制之间的调用权限，保证安全？

今天带来的是阿里云推荐的最佳实践方式，希望大家使用Tag来对资源进行分组。

比如你在阿里云已经购买了各种类型的资源，同时这些资源也分属于不同团队、不同环境，比如其中一个团队是北京区的信息部，这个团队团队的生产环境使用了一批资源，如果单从资源视角，是没法很清晰区分哪些是北京信息部的生产环境的，但是如果你把地区、部门、环境定义成标签，给实例打上标签，然后就可以切换到清晰的标签视角了，根据标签自动给你的资源进行了分组，即使是跨产品的情况下。可以一个标签的方式来分组，也可以多个标签的方式分组，可以以你的场景来自己定义，一个资源最多可以添加20个自定义标签。

一旦你给资源把标签打上之后，很多事情就变得容易了起来，通过标签的能力可以轻松进行分账、运维和安全控制。

分组之后就可以轻松达到分账，运维的效果。打完相关标签之后，就可以进入费用中心控制台，通过标签，查询对应标签下所有资源费用情况。它可以按月、按天、按小时的展现费用的详细情况，从而达到快速分账的效果。如果你需要查看多组标签交集下的资源情况，则可以通过新增财务单元的方式来开启费用分析，财务单元功能支持绑定多个标签来进行费用过滤，这里需要关注的一点是，标签出账是T+1的，如果你对资源添加标签后，是T+1之后才能看到账单数据。

打完标签之后，进入到运维编排的控制台，可以快速对资源进行运维相关的事情。我们在运维编排控台可以找到：发送命令、执行脚本，批量的重启和批量续费等相关操作。

同样，打完标签之后，可以进入访问控制的后台。通过进行一些策略，叠加到Tag相关的信息，对当前进行操作。API调用时必须包含某个Tag。如果没有，整个请求就会被拒绝。通过这样的方式，可以把各账号之间权限隔离起来。

原文链接

本文为阿里云原创内容，未经允许不得转载。