时常在文章里看到“网元”这个词，一看到就害怕，因为完全不知道是什么东西。

一番谷歌就理解了，如果你知道它的英文可能瞬间就理解了——Network Element。

网元就是网络中的元素，网络中的设备。

在GSM网络系统中, 一个基站就是一个网元。

交换机 路由器等也是一个网元。

http://www.jiancenj.com/2209.aspx

在BGP学习中，我们了解到，BGP有个keepalive time，默认是60秒，还有hold time，是keepalive time的3倍关系，也就是180秒。同时我们也了解到，hold time的值是协商值，那这个值是怎么协商的呢？我们来看一下：

拓扑如上：两台设备之间建立IBGP连接。

我们可以通过display bgp peeripv4 verbose 命令查看keepalive time和hold time，如下图：

我们可以看到，在没有修改的情况下，keepalive和hold时间都是默认值。

在路由器2上的BGP进程中，修改keepalive和hold值。用timer keepalive +时间 hold +时间修改。注意：修改时间值时，holdtime ≥ 3*keepalive time。

首先我们先修改hold time =3*keepalive time：

然后去路由器1上查看协商的hold值。注意：查看之前要重新启用bgp进程，使用reset bgp 100 ipv4命令。因为协商参数的传递由open报文负责，而在BGP邻居状态使能的情况下，只有keepalive和update报文交互。reset之后，再去查看。我们可以看到：

路由器1上协商的hold time,为60秒，keepalive time为20秒。

接下来我们再路由器2上继续修改，hold time > 3*keepalive time。

再次到路由器1上查看：

这时候我们发现，协商的hold time为100秒，keepalive time是33秒。这时候的keepalive time并不是我们设置的20秒。这是因为在open报文中只携带hold time值，不携带keepalive值，keepalive是根据与hold 值的三倍关系计算出来的。

那我们继续做一个修改：在路由器1 上设置keepalive time为30秒，hold time为90秒，路由器2上keepalive time 为20秒 hold time 为100秒保持不变。

这时候我们发现：

路由器1上：

路由器2上：

我们发现，路由器1和路由器2上hold 值是一致的，为90秒。但是keepalive 值，路由器1上是30秒，路由器2上是20秒。这是因为，当路由器接收到对方传来的hold值时，首先与自己的做比较，如果接收到的hold值小，则hold值修改为接收到的值，在比较keepalive值，若自己的keepalive值小于接收到的(hold值/3)，则用自己的keepalive值，若自己的keepalive值大于接收到的(hold值/3)，则使用接收到的(hold值/3)；当路由器接收到的hold值比自己的hold值大时，则不做任何修改。

参考

• CCNP—BGP笔记之二
• BGP timer协商实验
• BGP ALL IN ONE 详解
• BGP Route Reflection and Multiple Cluster IDs
• BGP邻居建立过程及报文详解
• 一个小白网工的项目实战之旅
• 由于IGP与BGP互引导致路由出现环路震荡

cpufreq

cpufreq是一个动态调整cpu频率的模块，系统启动时生成一个文件夹/sys/devices/system/cpu/cpu0/cpufreq/，里面有几个文件，其中scaling_min_freq代表最低频率，scaling_max_freq代表最高频率，scalin_governor代表cpu频率调整模式，用它来控制CPU频率。

1. performance: 顾名思义只注重效率，将CPU频率固定工作在其支持的最高运行频率上，而不动态调节。
2. Userspace:最早的cpufreq子系统通过userspace governor为用户提供了这种灵活性。系统将变频策略的决策权交给了用户态应用程序，并提供了相应的接口供用户态应用程序调节CPU 运行频率使用。也就是长期以来都在用的那个模式。可以通过手动编辑配置文件进行配置
3. powersave: 将CPU频率设置为最低的所谓“省电”模式，CPU会固定工作在其支持的最低运行频率上。因此这两种governors 都属于静态governor，即在使用它们时CPU 的运行频率不会根据系统运行时负载的变化动态作出调整。这两种governors 对应的是两种极端的应用场景，使用performance governor 是对系统高性能的最大追求，而使用powersave governor 则是对系统低功耗的最大追求。
4. ondemand: 按需快速动态调整CPU频率， 一有cpu计算量的任务，就会立即达到最大频率运行，等执行完毕就立即回到最低频率；ondemand：userspace是内核态的检测，用户态调整，效率低。而ondemand正是人们长期以来希望看到的一个完全在内核态下工作并且能够以更加细粒度的时间间隔对系统负载情况进行采样分析的governor。 在 ondemand governor 监测到系统负载超过 up_threshold 所设定的百分比时，说明用户当前需要 CPU 提供更强大的处理能力，因此 ondemand governor 会将CPU设置在最高频率上运行。但是当 ondemand governor 监测到系统负载下降，可以降低 CPU 的运行频率时，到底应该降低到哪个频率呢？ ondemand governor 的最初实现是在可选的频率范围内调低至下一个可用频率，例如 CPU 支持三个可选频率，分别为 1.67GHz、1.33GHz 和 1GHz ，如果 CPU 运行在 1.67GHz 时 ondemand governor 发现可以降低运行频率，那么 1.33GHz 将被选作降频的目标频率。
5. conservative: 与ondemand不同，平滑地调整CPU频率，频率的升降是渐变式的,会自动在频率上下限调整，和ondemand的区别在于它会按需分配频率，而不是一味追求最高频率；

cpupower

# CentOS 安装 kernel-tools
yum install kernel-tools

# Ubuntu 安装 CPU 模式无图形化切换器
apt install cpufrequtils

# cpupower设置performance
cpupower frequency-set -g performance

# 查看当前的调节器
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

参考资料

• CPU优化建议使用cpupower设置CPU Performance模式
• https://wiki.archlinux.org/index.php/CPU_frequency_scaling

手机上的chrome显示了这样的错误，不能同步收藏夹还是挺痛苦的：

可以通过如下步骤打开同步：

设置-用户和账户-右上角竖着的三个点-勾选自动同步。

一共四道题，在此记录一下。原广告链接：https://tianchi.aliyun.com/specials/promotion/cloudnative

【赛道1】实现一个分布式统计和过滤的链路追踪

用户需要两个程序，一个是数量流（橙色标记）的处理程序，该机器可以获取数据源的http地址，拉取数据后进行处理，并与后端引擎（蓝色标记）通信， 最终数据结果在后端引擎机器上落盘。

【赛道2】实现规模化容器静态布局和动态迁移

赛题背景

阿里每年双11不断的创造奇迹的背后，是巨大的资源成本投入，用以支撑峰值流量。每年各种大促、基础设施的升级都有可能会涉及到单元、中心机房站点变化，而这些站点的迁移、变化，我们可能会短时间借助离线资源、云上资源等，也可能会评估采购物理机，无论是采用哪种方式，我们都期望控制成本用尽可能少的资源成本满足当下站点需求。

日常态，我们使用较少的资源满足业务流量需求，但备战各种大促态尤其是双11，容器平台会承担数十万容器扩容诉求，支撑0点峰值流量，满足用户买买买的需求，同时也使得机器资源成本大幅度提升。

在大促规模化场景下，我们希望通过合理容器静态布局及动态迁移能力，在保证业务稳定性前提下，用尽可能少的机器资源来满足大促资源成本的节省，因而集群规模化容器布局成为了我们的关注点。

静态布局

容器平台规模化建站

• 每年双11大促，阿里容器平台会提前规划多个机房单元流量、容量分布。此阶段各机房单元站点，可能经历从0到1的新建，也可能经历从1到N规模化的容器布局。使得交易流量从日常态倾于大促态。然后经受第一轮全链路建站压测。

动态迁移

集群变化后容器平台按诉求规模化容器迁移。

• 大促建站后，通过良好的资源运营方式，集群符合90%的大促态，但业务团队会通过全链路压测、特殊的业务大促活动补容/缩容诉求等，使得各个集群资源状态发生变化。
• 大促结束后，交易流量会从大促态倾于日常态，在此过程中，集群容器会缩容至日常态，同时集团的机器资源会退水并分时复用于其他团队。

赛题准备

根据下面的单元化集群描述，我们会抽取机房单元中容器、宿主机信息并结合站点集群的变化来准备赛题。

1. 多单元机房规模化容器布局
2. 单元机房集群站点变化

• 初始态: 基础设置环境准备，涉及内核、网络、中间件、存储、集群管理等等验证准备阶段，此时没有任何交易业务容器，涉及到跨bu多团队的协作。
• 站点火种: 较少的机器、业务容器，用于支撑极少交易流量(如每秒1k笔 / 全局1%%流量)，用于验证交易全链路的正确性，并为未来快速规模化扩容埋下火种。
• 中间态: 较多的机器、业务容器，用于支撑一定规模交易流量(如每秒万笔流量)，成为一个长期、平稳日常态单元集群，抑或通过建站使得集群规模化补容到濒临大促态。
• 大促态: 集团大面积封网、全链路压测稳定，迎接大促。
• 一个不够形象的串联解释: 当我们想要搬家时，购买了很多储物箱(初始态)，但还没到搬家的日期，空闲时先收拾了一部分衣物在部分储物柜中(站点火种)，当真正要搬家之前，此阶段可能还要补充储物柜、清理旧物品等，然后陆陆续续的整理好了一个个的储物柜(中间态)，，直到真正搬家时候(大促态)。

赛题内容

1. 规模化容器静态布局场景。我们准备了确定数量多规格机器资源，使得在满足调度约束条件下，确定数量、多种类的应用容器能在这些机器资源上满足扩容诉求，保证建站的确定性(赛题中我们会给出充足的机器，但真正建站场景我们会先通过计算预估机器)。
2. 规模化容器动态迁移场景。我们会准备一个集群容器静态布局数据，此时集群是一种碎片态。然后通过容器的迁移，按照规则要求尽可能腾空机器资源，过滤空机器，使得碎片态集群现状重新成为饱满态。

赛题挑战

一个单元集群，数万容器、数千主机、核心业务调度约束，综合起来资源碎片问题会更加放大，而这些单元机房可能根本不会有容器的新增，集群会成为我想象中的”饱和态”

静态布局

业界多数调度器均通过不同的策略打分通过queue以one-by-one的方式调度容器，设计上并不感知后续容器信息，串行扩容顺序会左右调度结果，进而极大地可能会导致资源的浪费。下面通过三个容器实例、三台宿主机举例:

动态迁移

赛题数据

应用描述

1. 集团中的应用信息实际以 “应用名

   应用分组” 两个维度的形式呈现，同一个应用名下会有多个应用分组，不会出现一个应用分组对应多个应用名。对应关系是一对多的关系(appName:group=1:N)。

2. 集团内部应用与应用、分组与分组之间有各种调度规则约束，如应用分时错峰、CPU/内存密集型应用交错布局，但本赛题简化问题描述，不增加这些复杂约束。
3. 集团应用根据不同画像特性，cpu-model定义了cpu-share、cpu-set 两种类型，内存超卖技术还未规模化铺开，此处我们考量的是保证交易的稳定性的双11大促单元集群中的cpu-set模式、固定内存的核心应用。

【赛道3】服务网格控制面分治体系构建

问题背景

阿里拥有百万级别的服务实例。虽然通过 Nacos 可以解决超大规模服务发现问题，但服务网格的先行者 Istio 却一直是单体全量数据，不能横向扩容。因此我们找个办法，通过让不同的 Pilot 实例负责不同的 Sidecar 即分治方式来支撑超大规模的系统。然而这里的一个挑战是：如何分配 Sidecar 才能让 Pilot 集群整体负载均衡 ？

为了更好地说明问题，我们先将问题简化成以下模型：

这里说明如下：

• 三个部分，从上至下分别是：注册中心、Pilot 集群以及应用；
• 每个应用中 Sidecar 依赖的服务都是一样的，不同应用依赖的服务可能有重叠；
• 应用可能随时增减、应用的 Sidecar 也可能随时增减；
• 每个 Pilot 依据连接上来的 Sidecar 实例需要的全部服务，向注册中心发起服务订阅，将结果存于内存中并推送给他们。

由此可见，Pilot 单个实例承压为：Sidecar 连接量 + 服务数据。服务数据越大，意味着推送前处理的数据越多；连接数越多，意味着需要推送的数据越多。因此，这里的性能优化便成了设法降低这两个值，这体现在 Pilot 集群里便是让 Sidecar 连接更均匀，以及减少 Pilot 服务加载的重复度。但这并不简单，因为我们尝试优化一个时，另一个就会变差。例如，如果我们采取随机连接的方式，那么 Sidecar 连接将会比较平均，单个实例的连接数便较小，但每个 Pilot 加载的服务量增加，因为加载的是 Sidecar 依赖的并集；

图1

如果我们采用散列函数按服务依赖映射至 Pilot，单个实例加载的服务会减少，但是多个应用可能会映射到同一 Pilot，连接数又会增加，造成不均匀问题（如图2所示）。

图2

所以，我们需要寻找一个最优解。

问题描述

首先我们简化问题，只在应用维度进行 Sidecar 分配，同时为了更好的地理解问题，我们进行以下抽象：

• 已知：
  • 提供一个应用列表 A，以及每个应用对应的 Sidecar 数量 n；
  • 对于每个应用 a，提供一个服务依赖列表 D；
  • 已知一个 Pilot 集群，并有 m 个实例。
• 条件：
  • 为了保障 Sidecar 由访问的顺畅，防止惊群，在整个过程中 Pilot 的加载的服务只增不减（即使应用迁移到其它 Pilot 上，加载的数据依然存在），请谨慎调整应用连接的 Pilot；
  • 需要支持应用增减，Sidecar 扩容、缩容，变化后每个 Sidecar 需要的服务需要在对应的 Pilot 上找到，不得缺失。
• 求：
  • 每个 Pilot 实例需要挂载的应用列表 P(L)（i ∈ [0, m-1]）。

【复赛预览】实现一个 Serverless 计算服务调度系统

赛题背景

Serverless 计算服务（如函数计算）根据实际代码执行时间和资源规格收费，让使用者无需为闲置资源付费，背后是服务方采用各种手段优化服务端资源利用率。在优化的过程中，一个关键的问题是平衡请求响应时间和资源利用率，即如何在响应延迟可接受范围内使用尽可能少的资源。Serverless计算服务支撑场景的多样性以及不同应用对于响应延迟的不同要求，也给优化带来了一些额外的空间。本题目是关于如何设计和实现一个 Serverless 计算服务的调度系统。

赛题设置

• 系统分为APIServer，Scheduler和ResourceManager 3个组件，其中APIServer和ResourceManager由平台提供，Scheduler由选手实现。
• APIServer提供了Invoke API，该API接受函数名称和event，返回执行结果。
• ResourceManager提供了ReserveNode API获得Node和ReleaseNode API释放Node，该Node上有容器管理服务，选手可以调用管理服务在Node上为函数创建和销毁容器。其中函数实现已提供，选手无需关注。
• 当APIServer接收到Invoke请求后会调用Scheduler的AquireContainer API获得执行函数需要的容器，在该容器上执行函数，执行成功后调用ReturnContainer API归还容器。

指标定义

• 资源使用时间：获得Node成功后开始计时，同一Node释放成功后结束计时，其差值为资源使用时间。
• 调度延迟：调用AquireContainer所需时间。

赛题描述

评测程序会以不同QPS调用多个函数，计算调度延迟和资源使用时间，按照一定规则对结果评测。