hologres支持计算节点弹性伸缩吗？可以根据计算压力，自动伸缩吗？
问题1:hologres支持计算节点弹性伸缩吗？ 可以根据计算压力，自动伸缩吗？ 问题2:目前看能实现吗？有计划实现吗？
运维编排系列场景--通过告警触发自动重启CPU使用率高的ECS实例
运维编排(OOS) 简介
什么是OOS
Operation Orchestration Service，简称OOS，是全面、免费的云上自动化运维平台，提供运维任务的管理和执行。典型使用场景包括：事件驱动运维，批量操作运维，定时运维任务，跨地域运维等，OOS为重要运维场景提供审批，通知等功能。OOS帮您实现标准化运维任务，从而实践运维即代码（Operations as Code）的先进理念。关于OOS更详细的介绍请查阅 运维编排服务。
场景介绍
当ECS实例因已知或未知的原因CPU使用率过高时，往往会影响实例上应用的运行状态，造成应用运行缓慢甚至卡死。这是如果通过重启实例能够将ECS实例的CPU使用率快速恢复到较低的水平，就能够避免对应用的影响。在这个场景中，可以使用OOS告警触发功能，将CPU使用率高的实例自动重启，从而达到无人值守自动恢复的效果。
操作步骤
登录
OOS控制台
。
单击
告警与事件运维
，单击
创建
。
设置
触发规则
。
产品类型选择
云服务器ECS
，在规则描述中选择触发条件；本文选择当
cpu_total
大于80%时，触发告警操作，即进行重启实例；
触发沉默周期
默认为5分钟，即5分钟内不会因为重复的告警而重启实例。
在需要
报警资源
中，选择要监控CPU使用率的实例。
选择模板，模板类型选择公共模板，并选择批量重启ECS实例模板
ACS-ECS-BulkyRebootInstances
。
设置模板参数。选择
从告警消息体选择参数
。
地域ID
、
目标实例
、
任务执行的并发比率
保留默认配置即可。
执行使用到的权限的来源
，需要为OOS服务创建RAM角色，参考《
为OOS服务设置RAM权限
》。执行此模板需要的权限策略。
{
"Version": "1",
"Statement": [
{
"Action": [
"ecs:RebootInstance",
"ecs:DescribeInstances"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
设置完成后，单击
创建
。
结果验证
针对本文中的场景，可以通过压测工具 stress-ng 模拟CPU使用率高的情况。
远程连接
登录到监控的ECS实例。
安装stress-ng
# AliyunLinux/CentOS/RHEL
yum install stress-ng -y
# Ubuntu/Debian
apt-get install stress-ng -y
运行stress-ng命令模拟CPU使用。
# stress-ng命令可以根据压测需求调整参数。
# 示例命令中，使用stress-ng压测2个CPU核，CPU负载设置为85%，运行5分钟后停止。
stress-ng --cpu 2 --cpu-load 85 --timeout 5m
压测1分钟左右，观察告警触发被执行，运行命令的ECS实例被重启成功，ECS实例的CPU使用率也下降。
快手 Flink 的稳定性和功能性扩展
摘要：本文整理自快手技术专家刘建刚，在 Flink Forward Asia 2022 生产实践专场的分享。本篇内容主要分为四个部分：
快手 Flink 平台
稳定性保障和智能运维
复杂场景下的功能扩展
批处理的定制优化
点击查看原文视频 & 演讲PPT
一、快手 Flink 平台
1.1 计算平台架构
如上图所示，Flink 主要运行在 Yarn 和 K8s 上，存储组件使用 HDFS 和快手自研的 kwaistore。在 Runtime 层，同时支持流处理和批处理。在用户结构层，主要包括 Data Stream 和 SQL。最上面一层是快手的作业管理平台，包括前端和后端。
基于 Flink 计算生态，周边组件囊括万千。既有 Kafka、RocketMQ等中间件，又有 Clickhouse、Druid 等 OLAP 分析，还有 Hudi、Hive 等存储层。最外层是应用场景，涵盖了音视频、商业化、数据工厂、湖仓一体等应用场景。
1.2 架构演进
架构演进
在 2018 年~2019 年，我们搭建了实时计算平台，在 Data Stream、SQL 计算、大状态存储等方面，为用户提供生产可用的功能。
在 2020 年~2021 年，我们对 SQL 进行了进一步的优化和推广，对 Flink Runtime 进行了深度改造。
在 2021 年~2022 年，我们开始探索流批一体。与此同时，在稳定性和功能性方面，进行了深度改造。
未来，我们会探索更加智能的流批融合，进一步丰富计算生态。
1.3 未来规划
上图是未来规划的大一统架构。从用户的角度来看，不再需要关心流和批，以及复杂的流批配置。对用户暴露的将是简单的资源延迟和吞吐配置，底层计算引擎会根据这些配置智能执行。
Flink 将作为统一的计算层，为用户暴露统一的 SQL 和 Data Stream API。统一的调度器，会解决用户的资源调度和算子调度。增量和全量计算对应用户的延迟要求。如果用户希望尽快得到结果，可以使用更短的增量触发。
在批处理方面，我们希望能在 Streaming 内核的基础上，达到业界领先。除此之外，Shuffle 对用户的吞吐至关重要。我们希望能够在 Pipeline 和 Blocking 之间智能切换，实现最大的吞吐。
在流批的智能切换和无缝融合方面，需要在性能和平滑过渡上多做一些工作，为用户屏蔽具体的细节。在存储层通过统一的管理，为用户展现一致的 Table 表。
二、稳定性保障和智能运维
2.1 自动迁移
稳定性保障和智能运维。由于我们经常会遇到机器下线、队列下线、集群下线的情况。此时，如果让用户自己迁移作业会非常麻烦，主要有三个方面。
机器下线是常态化的事情，会频繁干扰用户。
当涉及的用户作业数较多，手动操作非常繁琐。
沟通成本较大，会浪费大量的时间。
如上图所示，先来看一下单作业的自动迁移。对于用户来说，只需要配置 AutoMigrate 参数即可，该参数可以配置三个值。
Normal 值表示自动驱逐 Container 并恢复。
Exactly-Once 表示 stop-with-savepoint 并恢复。
Manual 表示通知用户 Dealine 前手动处理，否则自动处理。
当用户配置完参数，Flink 平台会在机器下线时，自动帮助用户操作。主要分成以下四步。
第一步，将下线的机器标记为不再调度。
第二步，找到对应的 Flink 作业。
第三步，按照用户的配置，进行自动化迁移。
第四步，当所有作业都迁移完后，机器就可以正式下线。
除了单作业的自动迁移，我们还具备集群迁移的经验。集群迁移的复杂性主要体现在以下三点。
Flink 及其上下游的数据一致性很难得到保证。
上千个作业，操作复杂，稳定性难以保障。
用户众多，沟通运维成本极高。
为此我们开发了一套自动化迁移程序。如上图所示，单个作业会在新集群，自动拷贝一个新作业。然后，通过 stop-with-savepoint 停止老作业，在新集群启动新作业。在启动时，我们会跨集群读取老作业的 Savepoint。除此之外，我们会通过各项指标检查作业的健康度。一旦出现问题，立刻回滚。
涉及集群操作时，我们会进行批量的灰度操作。如右图所示，我们通过批量的灰度，操作这些作业。一旦出现问题，会立刻回滚，并且告知用户尽快介入。
为了保证上下游 Kafka 数据的一致性，Flink 针对 Kafka 进行了深度改造和适配。在消费端，Kafka 会 Mirror 最近一段数据到新集群，确保 Offset 和数据都一样，Flink 自动切换到新集群消费。
在产出端，Kafka 也会自动 Mirror 数据到新集群，当 Flink 自动切换后，新数据会写到新集群，确保 Offset 和数据一致。
2.2 故障归因
故障归因主要讨论不确定性的硬件故障，主要有以下三点。
磁盘故障，比如磁盘坏道、内核故障等引起的读写卡顿问题。
内存故障，比如部分数据脏写、gc 频繁等。
网络故障，比如网卡异常导致无法连接等问题。
这些问题的共性是，导致作业卡顿或者表现异常，但又不是彻底的失败，定位非常困难，甚至无法查出问题所在。当规模比较大时，这种问题会频繁出现。
接下来，介绍一下应对方案。我们的应对方案主要包括以下四点。
自动拉黑。既包括在作业粒度，将机器拉黑。也包括在平台纬度，将一个机器彻底拉黑。
智能归因。我们会监控 Flink 算子的异常 Task，比如某个 Task 的延迟、吞吐、快照等有明显异常。我们会把它迅速拉黑。
人工快速识别。当我们怀疑一批机器有问题时，会快速计算共同的机器，并进行指标分析。一旦确定异常，立刻拉黑。
建立实施故障指标库。虽然离线计算能够容忍很多机器问题，但实时计算不能容忍。我们需要识别这些 Case，并且快速的处理，防止作业出现问题后处理。
故障归因。故障归因的目的是，将人工运维的经验，沉淀到自动化程序里，进一步解放开发人员、运维人员和使用人员。主要分为作业失败和作业性能两个诊断。
在作业失败方面，查询单个用户作业失败的原因时，首先去 ES 获取作业失败的原因。如果是用户的问题，直接返回给用户。如果是心跳超时，去 Yarn 查询 Host 和 Container 的存活性，然后再去 metric 系统查询是否 gc 等信息。
如果是其他问题，先看一下是否在系统诊断库里，如果是就可用直接返回。如果不是，直接给用户返回异常。与此同时，人工会排查原因，并把它加入诊断库。
作业性能问题的排查。首先，进行宽泛检查。比如资源是否打满，数据是否倾斜。然后，找到第一个有问题的 Task。如果这个作业有快照，我们就会找到第一个快照失败的 Task。
如果没有快照，我们会递归查询反压，并根据 Task 的 Input Queue 来判断它是不是第一个出现问题的 Task。
如果确定了第一个出现问题的 Task，会为用户返回资源、线程等相关信息，辅助用户确定根本原因。
2.3 分级保障
分级保障。分级保障是指给予不同优先级作业，不同的保障级别，其背景如下。
在资源紧张的情况下，我们会优先保障高优的作业。
我们会为高优的作业提供平台化的保障措施，比如热备、冷备等方案。
我们会根据优先级统筹规划，提高整个集群的利用率。
如上图所示，我们为作业划分了四个等级，其中 P0 为双 AZ 容灾（热备）、P1 为双 AZ 容灾（冷备）、P2 表示单集群常规作业、P3 表示不重要的作业资源，随时可能被抢占。
下面重点介绍一下冷备方案和抢占方案。Flink 的冷备方案既支持 Flink 冷备，也支持 Kafka AZ 容灾，主要指消费两个同名的 Topic 和写出两个同名的 Topic。同名 Topic 在不同的 AZ 下，两个同名的 Topic 共同组成一份完整的数据。
这时如果上游的一个 Kafka 集群挂掉，Flink 会自动容灾，并推动 watermark 的前进，整个作业不受影响。Flink 在常规情况下，通过轮转写的方式，将数据写到下游的两个 Topic。如果一个 Topic 挂掉，数据会全部导到另一个 Topic。
针对 Flink 作业，我们会定期将快照写到备集群。一旦作业管理平台监测到 Flink 所在的 AZ 挂掉，会自动在备集群拉起一个一样的 Flink 作业。
未来，我们将实现 HDFS、Kafka 的双 AZ 部署，到时它们会自动 AZ 容灾并为 Flink 呈现逻辑视图。
资源不足时的抢占方案。抢占策略主要有三点。
高优作业抢占低优作业资源。
优先抢占不健康的作业，比如 lag 严重的作业。
实时作业会优先抢占同一个作业的资源。
右图展示了我们的抢占效果。作业通过改造，在资源不足时，也能启动。
常见的保障措施，主要包括以下四点：
资源隔离。高优作业可以单独划定队列，实现物理隔离，同时不与离线作业混部。
资源抢占。在资源紧张情况下，高优作业可自动抢占低优作业的资源。
AZ 容灾。高优作业可实现 AZ 容灾，包括冷备和热备。
智能监控报警。高优作业配套的报警更加完善，一旦出现预期之外的问题可快速人工介入。
三、复杂场景下的功能扩展
3.1 弹性伸缩
在复杂场景下的功能性扩展。这里主要讲三个部分，即弹性伸缩、Remote Shuffle Service、云盘存储。接下来，来看下弹性伸缩的背景。
第一，Flink 作业当前的静态资源分配一般都是按照最高峰申请的，导致了其他时间段的资源，大量浪费。
第二，PerJob 模式调整并发度慢，需要停止作业、修改并发度、启动作业等繁琐流程。
第三，用户不知道该配置多少资源，有的延迟严重、有的资源浪费严重，带来了各种运维问题。
基于以上背景，我们开发了更轻量级的弹性伸缩方案，用户或者平台决定好并发度后，直接发给 Flink 作业，Flink 作业在不停止作业的情况下快速完成调整。
先来看一下整体的架构实现，用户可以直接触发扩缩容或者配置扩缩容的条件。比如当 CPU 或 IO 超过多少之后，进行调整。AutoController 作为自动控制的组件，会根据用户的配置，自动完成作业的弹性伸缩，比如根据 metric 自动触发调整。
在 Flink 内部，我们实现了快速 rescale 的接口。伸缩原理如下，如果是扩容，会提前申请资源，然后将并发度持久化到 ZK 里，来防止 Master Failover，然后重新生成执行图。在停止时，默认使用 stop-with-savepoint。
弹性伸缩的效果。扩缩容时间，常规聚合作业从分钟级别降低到 10s 左右，常规 ETL 作业 3s 内可完成调整。通过平台调整，作业资源占有量显著下降，可以有效整顿集群的资源利用率。将用户从作业资源调整的繁琐运维中解放出来，极大地减少了人工运维工作。
3.2 Remote Shuffle Service
Remote Shuffle Service。Flink 由 TaskManager 来管理 Shuffle 数据，计算和存储耦合，存在以下问题：
一旦 TaskManager 挂掉就会造成 Shuffle 数据丢失，存在重跑整个任务的风险。
空闲 TaskManager 因为 Shuffle 数据的存在而无法退出，导致资源浪费。
Shuffle 代价大，无论是网络连接、还是磁盘读取，开销都比较大。
快手内部自研的 Shuffle Service 主要采用 Master slave 架构。接下来，介绍一下 Flink 和 Shuffle Service。Flink 的 StreamShuffleMaster 负责跟 Shuffle Service 的 ShuffleManager 交互。
Task 的 Reader 和 Writer 通过心跳从 StreamShuffleMaster 处获取读写地址，将数据读写到 Shuffle Service。Shuffle 数据会持久化到 HDFS，防止数据丢失。
数据交互流程。针对上下游的交互，中间数据以 ReducePartition 的形式存在。Shuffle Service 负责将上游 Task 的数据聚合到一块，下游 Task 到时候只需要一对一的顺序读取即可。Shuffle Service 在网络和磁盘方面做了很多的优化，确保了整个 Stage 的快速数据传递。
我们的 Shuffle Service 支持多种传输模式，包括 AII to all、Point-wise、Broadcast。
其中，All to all，指的是上游每个 Task 将数据轮询发送到下游。Point-wise，指的是上下游按照倍数关系来映射，这样会减少连接的个数。Broadcast 指的是上游的一个 Task，将全量数据分别发送到每个下游的 Task。
3.3 云盘存储
云盘。快手自研的系统支持 Flink 的状态存储到远程的共享云盘。如上图所示，相关背景主要有三点。
存储和计算资源的不对等或者不匹配，决定了存算分离这一大趋势，二者可以独立开发和维护。
Flink 作业经常受磁盘故障的影响，单盘故障不可避免。
快手未来的机器会逐渐下掉本地盘，全部采用远程存储的方式。
云盘存储的实现，对于用户来使用很简单，只需要配置是否使用云盘即可。如果用户使用云盘，我们将 Flink 作业调度到支持云盘的机器上，Flink 会像使用本地盘一样使用云盘，操作非常简单。由于云盘的数据是持久化的，所以我们可以直接使用云盘的数据，不需要将快照写到 HDFS 等地方。
四、批处理的定制优化
4.1 准确性
快手批处理的定制优化，从准确性、稳定性、应用性三个方面解开展开介绍。在准确性方面，主要通过双跑来验证。首先，选取一批无外部访问、无随机性的线上 SQL。
然后，针对单个线上 Hive 作业，自动调度一个 Flink 镜像作业并读取数据源并写到测试表。最后，基于 Hash 算法验证数据的一致性。这种方法还会被用来跑回归测试，确保新增功能不影响数据的正确性。
4.2 稳定性
在稳定性方面，快手首先提出并解决了所有批处理都会遇到的三个关键性问题。
Remote Shuffle Service。我们通过存算分离，避免 Container 挂掉后，从头恢复的问题。
推测执行。主要通过通过镜像 Task 解决离线复杂环境下的长尾问题。
Adaptive scheduler。我们可以根据数据量自动决定算子的并发度，避免人工反复调整。
针对离线作业，前面专门开发了自动 Failover 机制。相关背景如上图所示，我们的离线环境非常的复杂，主要体现在以下三点。
高优作业抢占低优作业严重。
磁盘压力大，文件出现问题的概率也大。
网络吞吐大，网卡被打满的现象时有发生。
自动 Failover 机制会自动识别异常。如果是平台引起的，会帮助用户自动容灾。如果是用户的错误，会按照正常配置的 Failover 策略走。除此之外，我们的 Failover 机制是可插拔的，目前涵盖了抢占磁盘故障、网络故障等常见的平台问题，这些故障会自动帮助用户恢复作业。
Client 和 Job 的存活一致性。在应用场景里，客户端承载着更新作业进度、获取结果、检查作业存活等重要任务。所以我们必须确保客户端和 Flink 作业的存活一致性。
当 Job 挂掉时，Client 快速感知失败并退出。当 Client 挂掉时，Job 能快速退出，防止成为孤儿作业。
为此我们在 Client 和 job 之间建立了心跳机制，来确保二者的存活一致性，确保了任何极端情况下都能相互感知。这种机制可以应对各种极端 Case，比如 Kill -9。
4.3 易用性
易用性的改造。首先，支持远程文件加载。比如通过-C 加载远程的 classpath。其次，通过 SQL 加载远程的 Udf，使用方法是通过 Add jar remoteUdf 加载远程文件，极大的扩展了 Flink 的使用范围，为大一统的 Flink 计算，打下了坚实的基础。
接下来，介绍下 Web 智能路由和日志查看。虽然我们的离线环境非常多，但我们通过智能路由，帮助用户屏蔽了这些细节。用户可以直接由客户端，自动跳转到对应的集群和作业。
除此之外，日志查看对用户的 Debug 非常管用。用户通过平台，可以快速跳转查看各种各样的日志。最后，当日志结束作业，我们也支持一键跳转到 History Server。
点击查看原文视频 & 演讲PPT
更多内容
活动推荐
便宜云服务器基于 Apache Flink 构建的企业级产品-实时计算 Flink 版现开启活动：0 元试用 实时计算 Flink 版（5000CU*小时，3 个月内）了解活动详情：https://free.aliyun.com/?pipCode=sc
公有云——便宜云服务器ECS服务器入门精通（IaaS）（2）
一.ECS 实例规格族介绍第二部分我会给大家介绍一下 ECS 实例的规格族是怎么命名的，目前便宜云服务器提供几百种实例规格，所以在选择的过程中会眼花缭乱，其实 只要理解了 ECS 的实例规格族的命名方式，和它的信息布局，我们就能够很好的选型了。1.实例的架构类型、规格分类，详细信息在便宜云服务器控制台的购买页面上可以看到，实例规格族的选择上分成三大模块： 架构、分类、具体信息。最 上面就是我们的实例规格架构的类型，有三种架构类型，分别是通用的 X86 的架构、异构计算（像 GPU 或者是 FPGA、NPU 等）、便宜云服务器自研的神龙裸金属架 构。在每种架构下面会有实例规格的分类，从上图可以看到在 X86 的这种计算型态下，分成了 7 大类实例规格，不同实例规格代表了不同的硬件配置，选择任何一个实例规格的分 类之后，我们可以看到对应实例规格的详细信息，这些信息主要分为四部分：第一个就是实例规格族的详细信息，包括对应的规格族和实例规格的代称，这里可以通过点击小问号，能够看到实例规格族的一些详细的描述。第二部分是 CPU 和内存大小的信息，这里是大家在选型的过程中会比较关注的。第三部分是实例的网络能力信息，包括实例内网的带宽和收发包的能力。第四部分是 CPU 的处理型号的信息，包括处理器的主频和睿频这两部分信息。2.企业级实例 VS 入门级实例在控制台的购买页面上可以看到，ECS 的实例规格族特别多，单纯从 CPU 和内存是无法判断它们的区别，所以我们需要从宏观上来看。便宜云服务器 ECS 的实例规格整体是分成两 大类， 一类是企业级实例，一类是入门级实例。企业级实例是便宜云服务器在 2016 年 9 月份才推出的，其特点是 vCPU 是独享的，也就意味着我们创建一个企业级实例的时候，实例 vCPU 与我们 底层物理的 CPU 是绑定了的 ， 底层的物理 CPU 就不可能再分配给其他的实例了，所以企业级的实例不会出现资源的争 抢，因此能保证性能稳定，并且企业级实例提供了非常严格的 SLA 性能保证。 而入门级实例就是 vCPU 跟底层的物理的 CPU 是不绑定的，意味着可能每个 vCPU是随机分配到底层的空闲的一个物理 CPU 上，如果同一个物理的物理服务器上有多个共享入门级实例的话，不同的实例就会出现资源的争抢，导致CPU的性能不稳定。因为入门级实例存在性能不稳定的特性，所以便宜云服务器现在仅 仅提供一种入门级实例 ，就是在 X86 架构中的共享型实例， 而 X86 架构中的其他实例规格，以及 异构架构 和 神龙架构 中的所有 实例 ，都是属于 企业级实例 。由于企业级实例性能稳定，并且有严格的 SLA 的保证，所以它比较适合于对业务稳定性有比较高的要求的场景。入门级实例由于不能够保证性能稳定性，所以价格相对便宜，比 适合于一些对性能没有严格要求，或者在某些时段下才会有性能突发要求的场景，比如有 些轻负载的应用或者是微服务。3.共享型实例在介绍完 ECS 实例大的分类之后，我们来看一下共享型实例的具体信息。我们前面讲到了只有 X86 架构下的共享型实例才是入门级实例。这类实例比前面实例在四要素以外多出一个参数，即“平均基准的 CPU 计算性能”，基准性能即实例能够持续 提供的 CPU 性能。共享型实例也就是入门级实例，分成两大类，第一类是属于标准的共享型实例， CPU是不绑定的，只提供基准 CPU 性能，所以当出现资源的争抢，是否能超出基准性能是没有 保障。突发性能型的共享实例，如果应用实际用量低于了平均的基准性能，会获得对应的CPU 的积分，如果在某些场景下性能要求突然提升之后，比如实例对应的 CPU 的使用率 超过了 20%，会消耗之前累积的 CPU 的积分，去提升计算性能，让计算性能不会受到影 响，这个是突发性能的共享型实例独有的特性。4.两个特殊的实例规格除了共享型的入门级实例以外，便宜云服务器还有两个实例规格比较特殊，就是大数据型和本地 SSD。这两种实例规格会附带一个本地存储，大数据型实例的本地存储是 HDD 盘 ，本地SSD 新增的本地存储是具有非常高 I/O 吞吐，并且有低延迟的 本地 SSD 盘 ，具体的信息 大家可以在便宜云服务器控制台查看。5.企业级实例规格家谱企业级实例规格族分成三大块， 第一大块是 X86 计算 ，除了共享型以外，包括通用、计算、 内存、高主频、本地 SSD 和大数据型都属于我们的企业级实例，企业级实例每年都在不停 地迭代，所以会分成不同的代系，我们在后面会详细介绍不同的代际之间的区别。异构计算 里面所有的 GPU 和 FPGA 都是属于企业级的实例，裸金属和高性能计算也是一样的。绍 X86 的实例规格的命名方式，分成了 5 种第一种实例规格是 通用型 ，顾名思义就是什么场景都能够用，所以这种型号的代称是 g系列，它的 vCPU 和内存的一个配比是 1:4。第二种实例规格是计算型，顾名思义就是在某些场景下对 CPU 算力的要求会更高一点，所以它的 vCPU 和内存的配比是 1:2，然后简称为 c 系列。第三种类型是 内存型 ，提供更多的内存能力，所以它的 CPU 和内存的配比是 1:8，也简称为 r 系列，r 是 RAM 的简称。第四种和第五种分别是 大数据型 和 本地 SSD 型，这两种的 CPU 和内存的配比都是1:4，只是它们配的本地盘的类型是不一样的，导致它们的技能和适合的场景也是不一样的。 所以大数据型的简称是 d，本地 SSD 型简称是 i。6.实例规格的命名方式和规律通过下图能够看到便宜云服务器实例规格的命名方式和规律普通的 X86 实例规格名称是分成了三段：第一部分表示的是产品名称，ECS 是便宜云服务器 的产品。第二部分表示了实例的规格和代系，前面已经讲过 hfg 表示是在通用型的基础上增加了高主频的能力，然后 6 代表的是什么？其实它代表的是我们产品的代系，可以根据 产品的代系推算对应的产品的一个新旧，比如说 6 代表第 6 代，5 代表的是第 5 代，这个数字越大代表它是更新的一个代系，它底层的物理硬件也会越新，它的性价比相对而言也会越高。第三部分是实例的规格，表示的是实例的 vCPU 的核数，large 代表 2 个 vCPU，xlarge 代表 4 个 vCPU，2xlarge 代表的是 8 个 vCPU，以此类推。 了解了以上命名规律，就能通过实例规格族的名称推断出来当前这个实例的 CPU 是什么型号、它的是什么样的代系，以及它的 CPU 的数量是多少。GPU 命名规则也是类似的，只有一个不一样的点，GPU 名称的的中间这一部分会提供 CPU 和 GPU 的的配比关系，因为 GPU 是除了 CPU 以外还会提供一个额外的 GPU 的卡。所以我们也是直接可以通过它的规格族的格式，能够去推断出来它底层的物理的配置。
公有云——便宜云服务器ECS服务器（IaaS）
?前言本章将会学习便宜云服务器ECS服务器入门到精通，了解ECS概念选择ECS规格一.了解云服务器的基础概念1.云服务器的基础概念（云服务器选择）在云服务器的选择上面我们可以通过选择电脑的这种概念，进行考虑。选择一台电脑无非就是这几点。1.品牌2.硬件配置（计算性能CPU，存储（磁盘），网卡，显卡）3.系统选择（比如 Mac OS， windows 或 ubuntu 等）这是我在现实生活中去购买一台物理电脑的流程。在云上选择的话，比如说我们在选择一些物理硬件的参数的时候，选 CPU 和内存，对应在云上的话，就是选择 ECS 实例的 CPU 和内存大小以及 CPU 的型号。2.云上概念（存储）存储这一块，磁盘在云上对应的概念就是块存储，在云上块存储其实是包含两个概念，?一个概念是云盘，一个概念是本地盘。（1）两者区别是云上的块存储，我们在购买的过程中需要指定用作系统盘还是用作数据盘的。而现实生活中买了一个 电脑里面是有一块磁盘，然后我们自己会把磁盘分成系统盘还是数据盘，但在 云上的系统盘和数据盘是需要分开购买的 ，这是一点点区别。 3.云上概念（网络）在 网络 这一块其实也是类似的，云上提供弹性网卡，让用户通过访问云服务器就能够联通到网上。 ?4.云上概念（镜像，安全组，登录，快照）（1）镜像除了这些物理硬件以外，要让一个云服务器真正的跑起来，跟现实生活一样，我们也需要去安装一个操作系统，这个操作系统在云上的概念就是 镜像。 （2）安全组除此以外，云服务器还会有一些特殊的概念，比如安全组，本质上是通过一些规则来限定访问的流量，即被哪些应用可以访问。（3）登录 在云上买完一个云服务器之后，因为这个服务器是在云端或者说在远端，我们访问云服务器 的方式就跟我们平时打开一个电脑不太一样，我们需要通过便宜云服务器的控制台或者通过远程连接的工具来登录到我们的云服务器上去。 （4）快照云上有快照这样一个概念，它的意思是说对云盘的某一个时间点的数据拍一张照，本质上就是会把磁盘上所有的数据记录下来，如果出现了问 题，我们就可以通过快照，快速的回滚到某一个时间点的数据，这样能够保证在业务出现了 问题的情况下，快速做灾备的恢复。二.云服务器的存储和网络的概念1.云上的三种存储方式 （1）块存储块存储的模式，用户创建了一个块存储之后，可以把块存储挂 载到实例上，就跟自己使用笔记本电脑过程中，电脑自带的磁盘不够用了，去买移动硬盘来 插上来类似。块存储有三种类型，包括普通的高效云盘，还有 SSD 云盘，以及超高性能超 低延迟的 ESSD 云盘。（例如我这个就是高效云盘）（2）文件存储存储方式是文件存储，每一个块存储只能够挂载到一个云服务器上，而每个文件 存储可以被多台 ECS 使用。 （3）对象存储形态 OSS存储形态是对象存储形态 OSS，这个就类似于百度云盘，使用这种存储的方式， 更多的通过一个链接来做文件的读取。2.云上的网络 网络部分主要是两个概念，专有网络 VPC 和交换机。（1）专有网络 VPC专有网络 VPC，专有网络是在云上为用户划分一个私有网络，用户通过创建VPC 可以创建逻辑上彻底隔离的一个网络环境，每一个 VPC 都是由一个路由器以及一个 以上的交换机组成的。用户一旦创建了一个 VPC 专有网络，便宜云服务器会自动为用户创建一个 对应的路由器，来完成 VPC 下所有网络的转发。同一个 VPC 下的实例之间的内网是互通 的，即在同一个VPC下实例之间可以通过内网 IP 地址来互相访问。 （2）交换机前面已经介绍了，一个 VPC 至少有一个路由器。交换机是专有 网络的基础网络设备，用来连接不同的实例资源，我们可以通过交换机，在每一个可用区创 建多个交换机来划分子网，然后多个交换机之间是可以通过路由器来实现连接和转发。以上 是存储和网络的一些基础的概念。三.云服务器 ECS 的使用流程一个 ECS 的实例，我们可以把它理解成一台虚拟机，它包含 内存、磁盘、网络和操作系统 等软硬件。而一个 ECS 服务器实例是多大的规格，底层的物理硬件是什么样子的，是 由对应的实例规格和实例规格族来决定的。在确定了实例规格之后，我们还需要去选择对应的存储，因为只有 CPU 和内存的话，数据是没有办法存放的.所以就会有一个块存储。块存储有两种，一种是云盘，一种是本地 盘。云盘其实是云上的一种三副本的存储形态，能够给用户提供高可用的能力。云盘主要用 来做系统盘和数据盘，只需要像物理盘一样把它格式化就可以使用了，而本地盘可能更多的 主要是用来做数据盘。 选择完了计算存储，我们接下来就要看对应的操作系统，云上的操作系统指的是镜像，目前便宜云服务器提供是多种镜像的来源，包括官方提供的这种公共镜像、第三方市场提供的镜像、 用户自定义镜像，还允许不同的用户之间共享镜像。网络方面便宜云服务器会有一个网络带宽，用户可以直接指定。 我们把实例的计算、存储、网络以及操作系统等参数制定好之后，就可以创建一个跟我 们物理的笔记本电脑一样的云服务器。 创建完之后，我们通过便宜云服务器的控制台，或者是通过便宜云服务器的 APP，可以直接连接和访问已购买的云服务器。
在HBR混合云备份如果 我本地 ecs 完全摧毁了，不影响你哪里数据安全吧？
在HBR混合云备份如果 我本地 ecs 完全摧毁了，不影响你哪里数据安全吧？
在用HBR混合云备份ECS增加云备份服务，是否只需要订购资源包就行？
在用HBR混合云备份ECS增加云备份服务，是否只需要订购资源包就行？
香港ECS服务器批量采购，兄弟们有经验吗，618有优惠吗？
香港ECS服务器批量采购，兄弟们有经验吗，618有优惠吗？
HBR混合云备份跨地域备份可以用这个资源包吧？!
问题1：请问一下，HBR混合云备份跨地域备份可以用这个资源包吧？ 问题2：就是要备份ECS服务器上一个文件夹里面的所有文件，需要异地容灾备份，除了买上面的资源包，还需要其他费用么？问题3：资源包只是100g容量和软件的使用费？流量费另外算？那流量费具体怎么算呢？问题4：这个 文件数据源数量规格 1个是啥意思？问题5：流量费用怎么算呢？
在HBR混合云备份我有部分ECS没有注册HBR备份但却显示安装中，是怎么回事？还占了很大一部分内存。
在HBR混合云备份我有部分ECS没有注册HBR备份但却显示安装中，是怎么回事？还占了很大一部分内存。
