本博客是以下文章的续篇：“什么样的控制平面适合运维大量Kubernetes集群”。上一篇博客介绍了Volterra独特的Fleet Operations方法，用于管理由基础设施站点和应用组成的资源群。本博客将具体介绍运维团队在大量集群或站点中更改配置时面临的一项关键挑战：配置漂移。我将这一挑战称为“生效时间”。
什么是生效时间？
简单来说，它是指一项操作的意图需要多长时间才能生效。例如：
- 我的安全策略配置需要多长时间才能在所有站点上生效？
- 我的应用程序最新版本需要多长时间才能传播到所有站点？
- 升级全球所有分布式站点的操作系统或基础设施软件需要多长时间？
为什么这很重要？
以下几个真实的客户案例可以回答这个问题：
- Meltdown和Spectre：Meltdown/Spectre事件曝光后，每位CISO最关心的是如何快速为所有基础设施的操作系统打补丁。运营团队的考核以小时为单位，衡量其意图（即升级操作系统版本）需要多长时间才能生效。
- 您可能听说过一批自动售货机对某所大学发起拒绝服务攻击的事件。若您没有关注此次攻击，简要情况如下：黑客利用零日漏洞安装了恶意软件，使这些自动售货机相互连接，形成自动售货机僵尸网络。该僵尸网络随后发送海量流量，对这所大学发起拒绝服务攻击。检测到攻击后，校方不得不逐台为自动售货机配置网络策略规则，以阻止其访问命令与控制服务器。对校方而言，必须立即在所有自动售货机上落实其意图（即阻止访问特定网站），以遏制损失。
生效时间对于基础设施软件、应用软件、网络策略和安全策略等多个类别都很重要。
面临哪些挑战？
当运维团队必须进行管理时，这一挑战尤为严峻
- 大量站点
- 分布在全球各地的站点
- 异构环境，例如位于私有云、公有云、电信云中的站点以及边缘设备
- 站点连接不稳定
汽车OEM的运维团队就是一个典型示例。该团队负责更新汽车软件并管理汽车的连接（下文将这些汽车称为客户站点）。典型部署包括一个私有数据中心，运维团队通过该数据中心在全球范围内（或根据组织架构在区域范围内）管理汽车。
要了解这一挑战，我们先来看看运维团队可采用的解决方案。大多数解决方案都提供托管在客户私有数据中心的管理软件，用于集中管理大规模分布式站点。当汽车OEM配置一项需要应用于所有车辆的策略时，中央管理软件实际上会逐一向每辆车下载配置脚本。该配置脚本可以是Ansible Playbook或Helm Chart，用于在每个站点执行一系列配置命令。具体过程如下图所示。
问题在于，生效时间与站点数量成正比。集中式管理软件供应商会认为，只要所有操作都能以远程自动化方式执行，这就是所能达到的理想效果。
Volterra对此持不同看法，本博客将对此加以证明。我们采用分层横向扩展架构构建了分布式控制平面，旨在尽可能缩短生效时间。
实现最短生效时间的Volterra架构
实现最短见效时间的基本构建模块包括：
- 分层树状架构
- 专门构建的分布式控制平面
下面是总体架构概览。
Volterra的分层架构通过创建树状节点来分发配置。每个节点都会存储并转发配置，即先将配置存储在本地，再转发给其子节点。以下示例可以更清楚地说明这一过程。当用户在Volterra Console上配置网络策略等对象时，控制和管理平面会将配置分发给直接子节点，即区域边缘（RE）。每个RE都会将配置存储在本地，并转发给其子节点。RE的子节点是连接到该RE的客户站点。
分层树状架构可确保将生效时间降至较低水平。生效时间受树的层级数和每个节点的子节点数限制。树最多包含3个层级（控制器→RE→客户站点）。每个节点的子节点数与连接到RE的站点数成正比。RE上会创建一个服务实例，用于处理一组站点的配置。如果连接到RE的站点数增加，Volterra的横向扩展控制平面会按需创建新的服务实例。
测试设置
生效时间测量在大规模客户站点上进行，这些站点连接到位于纽约（NY8-NYC）和巴黎（PA4-PAR）的两个区域边缘节点。客户站点分布在全球各地，包括圣克拉拉（加利福尼亚州）、休斯敦（得克萨斯州）、马德里（西班牙）、布拉格（捷克共和国）和伦敦（英国）等。此外，客户站点还涵盖多种异构环境，例如AWS、虚拟机（ESXi），以及包括Intel NUC和Fitlet2在内的边缘网关。
Volterra的客户门户和全局控制平面运行在Azure（Washington-IAD）中。客户站点分布在多个命名空间和租户中，以模拟真实的运营环境。
通过终止RE上的服务实例，并在RE与客户站点之间使用质量较差的连接链路来模拟故障条件。图3显示了单个命名空间中整个设备群某一部分在特定时间点的快照视图。
测试方法
每当在Volterra控制台上配置对象，并将配置应用于各客户站点时，Volterra系统都会记录带时间戳的审计日志。传播时间按从在门户中完成配置到该配置应用于客户站点之间的时间差计算。下面将详细介绍具体步骤。
- 在客户门户中配置对象。
- 将客户门户（本文称为Volterra Global Controller）上的对象创建时间作为测量开始时间。示例见图4。
- 将客户站点上的对象创建时间作为结束时间进行测量。示例见图 5。
请注意，所示屏幕截图为抽样截图，并非来自同一次测量迭代。
配置开始时间
配置结束时间
测试结果
传播时间的测试结果如图6和图7所示。图6中的图表表明，大多数测量样本的传播时间为0–400 ms。这意味着所有客户站点都会在0–400 ms内更新为新配置。如前所述，测试通过重启RE上的服务，并在客户站点引入连接故障或延迟来模拟故障情况。在这些特定测试中，故障情况下的配置传播时间更长，具体取决于故障类型，范围为600 ms至9秒。例如，RE与客户站点之间的连接故障会延长配置到达客户站点的时间。不过，Volterra分布式控制平面的优势在于采用配置最终一致性模式，即持续重试，以确保所有客户站点上的配置与客户定义的意图保持一致。
图7中的图表显示，在85%的情况下，所有 客户站点都会在322毫秒内更新为新配置。引入故障条件后，少数客户站点的配置传播时间可能约为3至9秒。
免责声明：这些测量结果与所模拟的拓扑、规模、部署环境和故障情形密切相关。我们并未测量所有可能的故障情形或其他环境，因此无法对未经测试的其他情形或环境中的传播延迟作出判断。例如，如果Kubernetes集群发生故障，系统必须等待故障检测、重启并重试配置，因而会产生更高的传播延迟。
相关博客
关于作者
相关博客文章
Thingbot正转变为攻击平台
Lori MacVittie重点介绍了F5 Labs对2018年1月至6月全球物联网设备攻击的研究，并指出了其中令人警醒的影响。物联网设备不仅持续遭到利用，还被转变为攻击平台，这意味着攻击者可以更充分地利用这个必然增长的市场。
借助F5全新Quick Start，在AWS上快速开展业务
在AWS re:Invent开幕前，我们很高兴与大家分享F5与AWS之间全新的Quick Start集成。F5的Tom Atkins将介绍该服务如何启动、配置和运行在AWS上部署工作负载所需的计算、网络、存储及其他AWS服务。