标签： 中立科普

关注星融元

业务可视云网络：Visibility-as-a-Service(VaaS)

VaaS（Visibility-as-a-Service，可视即服务）是星融Asterfusion为云网络设计开发的业务可视整体解决方案，能够轻松应对、完美满足云计算时代的运维所面临的各种挑战和需求。

构建VaaS方案的基石是NT（Network Telemetry，网络遥测）技术。

那么啥是NT技术呢？

NT技术为运维人员提供网络运行的实时参数和状态，并且能够将需要深度分析的网络数据复制出来，按照预先设置好的策略经过智能处理后，交给后端运营分析系统的子系统（运维、安全、审计、回溯、优化等）进行关联分析和呈现。

VaaS整体架构一览

VaaS方案主要由这4部分构成：

• INT（In-band Network Telemetry，带内网络遥测）
• VNT（Virtual Network Telemetry，虚拟网络遥测）
• ONT（Out-band Network Telemetry，带外网络遥测）
• AFC（Asteria Fabric Controller）

图2：Asterfusion业务可视云网络整体架构

• INT：基于可编程交换芯片的INT方案，在转发业务流量的同时，将网络的即时性能、状态、参数收集并记录下来，在网络的出口发送给运营分析系统，用来精准分析物理网络的健康状况。
• VNT：VNT方案是为运行在计算空间的虚拟网络开发的流量采集与分析方案，在不影响业务系统性能的前提下，虚拟网络流量会被VNT采集出来，然后通过隧道发送给ONT方案，用来分析虚拟网络的运行状况；对于那些单租户，VNT能够将所采集的虚拟网络流量直接发送给后端的运营分析系统。
• ONT：ONT方案将来自于物理网络和虚拟网络的采集流量进行租户和业务的关联对应，再按照预先设定的策略进行智能处理（例如汇聚、分流、负载均衡、隧道解封装、业务负载裁剪、元数据提取、特征标记等），最后将处理后的ONT数据发送到后端的运营分析系统进行分析。
• AFC：AFC（Asteria Fabric Controller）是VaaS的统一管理和调度平台，向南通过调用INT、VNT、ONT的REST API自动部署、按需调度、集中管理VaaS方案，同时向北为Cloud OS提供业务级的REST API，接受Cloud OS的统一调度和自动化管理。

VaaS整合了INT、VNT和ONT三个维度的技术与方案，即可以运行在星融Asterfusion的硬件平台之上，也可以运行在云计算的虚拟化环境中。

基于VaaS的业务可视云网络全面解决了云网络运维的各种挑战，完美满足云计算对云网络的运营提出的各种新需求。

接下来，让我们看看VaaS方案是怎么解决这些运营需求的。

虚拟网络与物理网络的综合运营

在星融元Asterfusion业务可视云网络中，不同的组件方案都能完成对虚拟网络和物理网络的运营分析，并且能够在同一张ONT网络上完成虚拟网络与物理网络分析结果的关联对应。

图3：虚拟网络与物理网络的综合运营

如图3所示：

• VNT方案采集虚拟网络中需要被分析的流量，并进行适当的处理以降低对云中东西向带宽的消耗（例如过滤掉不感兴趣的流量、将感兴趣流量的负载部分裁剪掉），然后通过隧道发送到ONT网络进行处理；
• ONT方案通过分光或者端口镜像的方式采集物理网络中需要被分析的流量，这些流量也被发送到ONT网络进行统一处理；
• ONT网络接收到采集完虚拟网络和物理网络的流量后，提取流量当中的特征，完成虚拟网络与物理网络的流量关联，然后将关联后的流量按照预先设置的策略进行智能处理，后发往运营分析系统；
• INT方案能够将交换机在转发业务流量的那一瞬间自身健康状况数据采集出来，并且在业务流量离开网络进入业务系统之前，将业务流量携带的交换机健康状况数据从中剥离出来，发送给运营分析系统；
• 运营分析系统根据接收到的ONT数据和INT数据，对云网络整体进行综合运营分析。

我们看到，当云网络发生故障时，

星融元Asterfusion业务可视云网络以虚拟和物理相结合的方式，帮助云的运营者快速、精准定位到是哪个租户的哪个业务出了问题，问题来自于虚拟网络还是物理网络，是业务流量超越SLA、还是物理网络自身性能瓶颈所致。

云级网络的整体运营

星融元Asterfusion业务可视云网络能够被部署在云中的任何位置~

图4：云级网络的整体运营

如图4所示：

• 当云中两个虚拟计算节点（两个蓝色的VM）通信时，在他们之间形成了一条虚拟网络路径（图中蓝色虚线），VNT方案能够将这条路径上的流量采集出来进行分析；
• 当这条虚拟网络路径上的流量通过物理网络传送时，在物理网络上存在两条路径在实际承载虚拟网络的流量，即图中的“物理网络路径-A（红色）”和“物理网络路径-B（金色）”，这两条路径协同工作，为两个虚拟计算节点提供高可靠、高带宽的通信通道；
• 在某一瞬间，虚拟网络流量使用哪一条物理网络路径，是由那一瞬间物理网络设备的负载状况、虚拟网络流量的自身特征、物理网络上同时承载的其他租户和业务流量的大小等因素共同决定的，并不能提前预知；
• 为了对图中的虚拟网络流量做全面的分析，ONT方案在物理网络的各个节点上都采集了流量，然后将这些流量智能处理后，发到后端的运营分析系统；
• 所以，运营分析系统就能够分别通过VNT和ONT获取全面的虚拟网络流量信息和全量的底层物理网络流量信息进行关联分析。

通过对物理网络的全量采集（任意位置、任意流量），再结合虚拟网络采集流量进行关联分析后，能够帮助运营者在网络层面构建云中业务的全景视图，因此，星融Asterfusion业务可视云网络能够为用户提供面向全网的整体运营能力。

面向云网络健康状况的精准运营

INT是最近几年出现的，能够对网络健康状况进行精准测量和分析的技术，目前已经被IETF所接纳，正处于被标准化的过程中。INT的整体架构如下图所示：

图5：INT的整体架构

与传统的用于观察网络健康状况的工具及能力（例如SNMP）相比，INT从根本上改变了观察网络健康状况的方法。

INT系统一般由运Controller软件系统和支持INT能力的网络设备构成，Controller软件系统一般包含两个模块：策略编排模块、分析呈现。而网络设备要能够接收Controller下发的策略，并且采集策略所要求的数据，最终输出到Controller进行分析与呈现。

一般来说，INT系统的工作流程大致如下：

1. Controller的策略编排模块根据管理员的需求生成对某种业务的测量策略，并通过管理通道将生成的策略下发到业务转发路径上支持INT能力的网络设备上；
2. 网络设备的控制平面接收来自Controller的策略，将策略编译后下发到转发芯片中；
3. 工作在转发平面的转发芯片根据来自于控制平面的指令在其所转发的业务流中采集相关的数据（出入接口、收发时间、队列长度、缓存状况等），并将这些数据按照指令的要求编码在业务流中向前传送；
4. 在业务流离开网络进入业务系统之前，网络设备将所有的采集数据从业务流中剥离出来发往Controller的分析呈现模块，并将复原的业务流继续发送到业务系统；
5. Controller的分析呈现模块对所接收到的采集数据进行分析、呈现，描绘业务路径上的网络设备在转发业务流那一时刻的健康状况。

从工作流程可以看出INT具备如下主要特点：

• 动态。按照业务与管理的需求对INT系统进行动态调整，能够随时对需要重点关注的业务进行观察。
• 推送。INT系统会在转发业务流量的同时，主动向管理与分析系统推送采集的测量数据，而不是响应管理侧周期性的查询。
• 数据平面采集。INT系统直接从网络设备的转发平面获取采集数据，这样就规避了传统模型中采集数据由控制平面生成、无法反应转发平面的真实状况或数据。
• 高精度。传统模型中网络健康数据只能够反应网络在查询时刻的状况，精度较低，而INT采集的各种健康数据描述的则是交换机在真正转发指定业务流量的那一时刻的状态，精准度非常高。
• 多租户网络。在承载着多租户、多业务的云上，INT系统能够仅仅对某一个租户的某一种业务进行转发过程的数据采集，帮助管理员针对租户/业务进行网络健康状况的精细分析。

星融元Asterfusion基于可编程交换芯片与全开放架构开发的CX系列和NX系列云交换机全面支持INT能力。

图6：面向云网络健康状况的精准运营

如图6所示：

在星融元Asterfusion业务可视云网络上，运营分析系统能够为不同租户的不同业务定义分析策略，然后动态下发到由星融Asterfusion云交换机（CX系列 & NX系列）构建的云网络上去；针对不同的业务流，云交换机在转发时刻将采集交换机的各种健康状况数据，然后将这些数据发送到运营分析系统，由运营分析系统从租户/业务维度完成对云网络健康状况的精准分析。

对于发现问题的业务流量，运营分析系统能够通过星融Asterfusion云网络的sFlow能力采样该业务流的部分报文，或通过ONT方案获取该业务流的全部报文，进一步的深入分析、定位问题。

不影响生产网络的高性能运营

星融元Asterfusion业务可视云网络的ONT方案能够帮助运营分析系统全量获取云中的业务流量，从而获得更智能、更全面的业务分析数据。

ONT方案全量获取业务流量却不会给生产网络带来任何性能的影响，并且在生产网络与运营分析系统之间建立起一条不受距离和规模限制的传送通道。

一般来说，运营分析系统从生产网络获取业务流量的主要方法是端口镜像。

如下图所示，当需要对流动在生产网络中的某一业务流量进行跟踪分析时，管理员通常会在该业务流量所流经的某一台生产网络交换机上，利用该交换机的端口镜像能力，将正常转发的业务流量复制一份、经过镜像端口发送给后端的运营分析系统。

图7：通过交换机端口镜像采集数据

对于小规模、业务流量较小、业务变化不频繁的场景，端口镜像的部署方案完全没有问题。

但是，在云计算的环境，端口镜像方案有着显而易见的缺点：

• 对生产网络的性能带来巨大影响。通常，交换机开启端口镜像后，会对其自身的转发性能产生很大的影响；在云中因为业务路径的不确定性，需要在业务可能路径的所有交换机上开启端口镜像，才能完成针对业务路径的全量分析；所以，在大规模的云中使用端口镜像，将会对生产网络的性能带来巨大的冲击。

• 交换机可支持镜像的端口十分有限。一般的，交换机支持镜像端口的总数量是有限的（个位数），对于大规模部署的云来说，仅交换机支持的镜像端口的数量就已经无法满足全量采集的需求了。

• 浪费生产网络的端口资源。对于云计算来说，云网络最宝贵的资源之一就是其端口资源，在同样的空间内，每多一个网络端口投入到生产系统，就意味着ROI（投资回报）的提升和TCO的降低，所以，将大量的生产网络端口资源当作镜像端口使用实在不是一个明智之举。

• 耗时耗力，为生产网络的安全运维引入风险。因为镜像对性能的影响，不可能随时对任何业务流量都开启镜像功能，但在云中，网络承载着数以十万计的租户和业务的流量，不同的租户和业务随时也都有可能产生运营分析的需求，这就意味着管理员要频繁地变更生产网络的配置，费时费力，而且为生产网络的安全运维引入了巨大的不可控风险。

• 要求后端运营分析系统服务器的数量线性增长。在镜像部署场景中，每开启一个镜像端口，就意味着后端的运营分析系统要保留一个专门的端口来接收发送过来的业务流量，无论这个端口中实际传送的流量是端口带宽的10%还是100%；从今天服务器的一般配置与处理能力来看，这种端口密度匹配要求，意味着后端运营分析系统的服务器数量的线性增长。

为了解决上述问题，星融元Asterfusion的ONT方案采用基于分光器的旁路部署、带外采集方案，在满足全量、全网采集的同时，对生产网络的性能、运维不带来任何影响。

图8：不影响生产网络的高性能运营

如图8所示：

在星融元Asterfusion ONT方案中，与生产网络并行地建设一张ONT网络，然后通过分光器将需要采集分析的生产网络的线路旁路接进ONT网络，所有通过这条线路传输的业务流量在正常传送的同时，都会被分光器全量地复制一份。通过分光线路发送给ONT网络，经过智能处理后进入运营分析系统。

相对于镜像方案的缺点，ONT方案的优点也是显而易见的：

• 因为分光的过程仅仅是对物理层光信号的复制与放大，因此对生产网络的性能没有任何影响。
• 数据采集的规模不受生产网络设备端口数量的限制，只需在需要分析的线路上部署分光器即可；
• 生产网络的端口可以全部用于生产，确保采集全量分析数据的同时，生产网络的ROI不会降低；
• 所有的变更、操作全部在独立的ONT网络上发生，不会对生产网络的运维带来任何风险；
• ONT网络的智能处理能力能够将从生产网络采集到的业务流量进行智能处理、高效收敛，大幅降低运营分析系统所需服务器的数量。

更为值得一提的是，构建ONT网络的星融元Asterfusion PX系列网络可视交换机采用可编程硬件平台，在单位空间内提供超高端口密度和超高处理性能的同时，还提供包括流量汇聚、负载均衡、流量裁剪、租户关联等各种智能处理能力，并且能够根据网络规模按需任意扩展，在生产网络和运营分析系统之间建立一个全线速的智能通道。

能够负担得起的低TCO运营

构建一个业务可视化分析系统对于运营好一张云来说的确是不可或缺的，一般来说，可视化分析系统的架构大致如下：

图9：业务可视化分析系统的一般架构

从逻辑上来说，业务可视化分析系统分为两层：

• 网络流量存储层
• 业务分析呈现层

❗网络流量存储层与业务系统的生产网络直接连接，接收从生产网络镜像或者分光过来的业务流量，完成针对网络流量的初级处理之后，将报文及处理产生的元数据存储在本地，供业务分析呈现层使用。

该层需要执行的动作主要包括：

1. 一对一全量接受网络流量
2. 流量过滤，匹配识别流量特征
3. 网络流量的编辑
4. 全量储存过滤后的网络流量
5. 解除封装、终结隧道、识别协议
6. 元数据的提取与分析
7. 元数据的存储

有一点需要强调的是，因为架构的关系，同属于一个业务的流量信息有可能存储在网络流量存储层的任何一台服务器上。所以，给业务分析呈现层带来了分析与处理层面的复杂度。

❗业务分析呈现层直接向运营者展示业务分析的结果，它首先从网络流量存储层获取各种流量报文及其对应的元数据，按照业务逻辑对这些流量报文和元数据完成重构与各种分析后，按照预定的规则及分析逻辑将结果呈现在直接面对运营者的控制面板上。该层需要执行的动作主要包括：

1. 获取全量元数据
2. 完成虚拟网络与物理网络的关联
3. 完成元数据的去重
4. 完成业务逻辑的一致性重构
5. 分析与呈现

显而易见的，上述架构最大的问题在于：

• 大量的服务器在重复地做着同样的事情；
• 服务器大量地存储了对于业务分析来说无用的数据；
• 大量的服务器在做不擅长的事情；
• 架构没能解决业务逻辑一致性的问题，浪费CPU的计算力来解决；

这些问题导致为云中业务构建一个可视化分析系统的TCO会非常高，除了镜像/分光的成本以外，还意味着大量的服务器和存储系统。

星融元Asterfusion VaaS的ONT方案成功的解决了上述问题，让针对云业务进行整体运营分析成为可以负担得起的方案。

显而易见的，上述架构最大的问题在于：

大量的服务器在重复地做着同样的事情；

服务器大量地存储了对于业务分析来说无用的数据；

大量的服务器在做不擅长的事情；

架构没能解决业务逻辑一致性的问题，浪费CPU的计算力来解决；

这些问题导致为云中业务构建一个可视化分析系统的TCO会非常高，除了镜像/分光的成本以外，还意味着大量的服务器和存储系统。

星融元Asterfusion VaaS的ONT方案成功的解决了上述问题，让针对云业务进行整体运营分析成为可以负担得起的方案。

图10：被ONT优化的业务可视化分析系统架构

星融元Asterfusion VaaS方案在业务系统的生产网络和可视化分析系统之间构建了一个独立的ONT网络，然后将网络流量存储层和业务分析呈现层原先需要服务器做的工作全部卸载到ONT网络上，由ONT网络一次性地、高效地、专业地完成，不再浪费服务器的计算力做这些不擅长的事情，而是专注在对业务的可视化分析与呈现上。

并且，星融元Asterfusion的ONT网络还具备如下特点，可以进一步优化业务可视分析系统：

• 网络流量裁剪。可选的报文截短功能将从生产网络接收到的全尺寸报文截短再到指定的长度，去除对于分析系统无意义的负载部分而只保留报文头部，在确保业务分析逻辑正确的前提下，有效降低后端存储服务器接收、处理负担，同时大幅降低报文存储的压力，提升单台服务器的使用效率；需要强调的是，星融元Asterfusion VNT也能够支持网络流量裁剪功能。
• 重复流量剔除。星融元Asterfusion ONT网络能够将从生产网络的不同分段，接收到的重复的网络流量剔除后，只保留一个拷贝、发送给后端的报文存储服务器，大幅节省后端报文存储服务器的处理时间，降低其存储压力，并且为分析与呈现服务器降低处理重复数据的负担，进一步提升其处理效率。
• 业务逻辑重构。ONT网络在转发从生产网络分光过来的流量时，除了完成原先在两层服务器上做的工作，同时，还从业务逻辑的层面还原、重构了同属于一个业务的流量（即同源同宿），确保同属于一个业务的所有数据全部输出到同一台网络流量存储层的服务器上，分析呈现层的服务器只需要从这一台服务器上就可以获得指定业务的所有信息，节省了从所有存储服务器读取数据的开销和自行完成业务逻辑重构的开销；
• 业务弹性分布。对于流量较大、单台服务器无法完成分析的业务，星融元Asterfuison ONT网络支持将业务按照逻辑分布到由多台服务器组成的存储、分析集群上去，由集群中的多台服务器并行地完成对业务的存储、分析和呈现，而这种情形，在ONT网络缺失的情况下，是根本不可能完成的。
• 不妥协性能的灵活性。构建星融Asterfuison ONT网络的Asterfusion PX系列产品是基于业界最领先的可编程交换芯片及技术开发的，能够按照业务需求将各种功能（协议识别、隧道终结、流量裁剪、业务重构、报文编辑、元数据提取等）在芯片内部的处理逻辑中通过软件编程的方式实现，在以超强的灵活性确保快速响应业务需求的同时，又不降低系统的性能。

通过以上架构与能力，星融Asterfusion为云计算交付的是真正能够负担得起的低TCO运营的方案：

• 15:1的流量收敛；
• 单位空间最高6.4T的处理性能；
• 8倍的端口使用效率提升；
• 3倍的服务器效率提升；

更值得一提的是，构建星融元Asterfusion ONT网络的PX系列网络可视交换机与构建云物理网络的CX系列和NX系列云交换机基于相同的硬件平台开发，对于运营来说，相同的硬件平台则意味着统一库存、备件管理和灵活的部署选择，将进一步降低运营的综合成本。

-未完待续-

关注星融元

云与云上业务的不确定性和无关性

云计算在过去的十年当中大行其道，IT架构及其所承载业务系统的交付模式几乎发生了天翻地覆的变化：

• 传统基础设施的竖井式部署架构被彻底抛弃，被资源池、虚拟化、按需部署、动态调度取而代之；
• 传统基础设施的封闭体系被完全打破，取而代之的是开放、开源、解耦、软件定义。

相应的，上层业务系统的开发、部署、交付、运营模式也与传统时代大相径庭：

1. DevOps（Development and Operations，开发运维）让业务系统对底层支撑系统的操控达到前所未有的程度；
2. CI/CD（Continuous Integration/Continuous Deployment，持续集成/持续部署）将业务系统的迭代速度大幅提升、发布周期大幅缩短；
3. SaaS（Software-as-a-Service，软件即服务）取代传统的固化、私有安装的发布模式 成为业务系统的主要交付模式……

自然而然地，云计算（或者运行在云计算平台之上的业务系统）的运营也必将与传统时代的IT运营不可同日而语，云计算自身的特征为运营带来了一系列的新挑战、新需求。

图1：云与云上业务的不确定性和无关性

如图1所示，从云计算的整体模型与运营关系上看，新挑战主要体现在两个方面：

业务对云的需求的不确定性

云平台的本质是将各种基础设施资源进行池化、虚拟化，然后按照租户的申请和业务的需求进行自动调度，即相对于所承载的租户与业务来说，云平台是一组“无差别”构建的基础设施资源的集合。而云平台之上承载的不同租户、以及同一租户的不同业务是千差万别的，租户规模有大有小、业务范畴有复杂有简单、运行时段有高峰有低谷，是一个在时间和空间上不停动态变化的过程。所以说，云平台首先面对的挑战是上层业务需求的不确定性。

云与业务的所有权的无关性

云平台的所有权属于云的运营者，而上层业务系统的所有权则属于租户；相应地，对上层业务系统运营的权利和义务也属于租户，对云平台自身运营的权利和义务则属于云的运营者。这就是云与业务的所有权的无关性。但是，云自身的特性（基础支撑平台，支撑其上的所有业务顺利运行）决定了云的运营者在实质上要对上层业务能否正常、高效运行来承担责任。

例如，云的运营者要给自己（和租户）提供一种工具，当租户的某种业务发生中断或者性能降级时，能够很快速、精准地定位到发生故障的位置（甚至原因）。

无论是出于对租户业务运行环境保障的目的，还是出于证明云平台对SLA（Service Level Agreement，服务等级协议）的合规遵从的目的，云的运营者都需要拥有相应的工具与方法，在这样一种以无关性为前提的关系下，为双方的运营提供更好的支撑。

也正是因为这样的不确定性和无关性的存在，使得云的运营者需要找到一个契合点，通过这个契合点能够同时对云和云上的业务进行全面的运营，同时又可以规避不确定性带来的影响、确保无关性的关系不被打破。

于是，作为三大支撑基础设施之一的云网络，作为连接云中所有资源的最重要载体，自然成为了这个契合点。

那么，随之而来的，相较于传统网络的运营，对于云网络的运营，云计算又提出了哪些新的需求呢？

云计算对云网络提出新的需求

1、运营需要同时面对物理网络和虚拟网络

因为网络在云计算的世界中与计算、存储资源被一起云化（虚拟化、资源池化），所以云网络运营与传统网络运营的最大区别在于对象不再是单一的、静态的一张物理网络，而是同时包含了运行在这张物理网络上的、动态变化的所有虚拟网络；

这就意味着，云网络的运营工具除了要面对高速交换的物理网络，而且还包括动态变化（创建、删除、迁移、变更等）的虚拟网络。并且，因为所有的虚拟网络其实都运行在同一张物理网络上，所以云网络的运营要有将物理网络与虚拟网络关联在一起进行运营分析的能力，以便在网络发生故障时快速定位到发生故障的点是在物理网络上还是虚拟网络上。

2、云业务流量在云网络上的传送路径无法预知

前述的不确定性与无关性在云网络方面的具体表现之一就是：直接承载云业务的虚拟网络在运行时刻具体通过物理网络的哪一条路径完成交换是不可定义和不可预知的。

物理网络一般会在众多计算节点之间提供多通道能力以确保高性能与高可靠性，虚拟网络的流量在交换时刻会被物理网络根据自身在那一时刻的各种状态参数动态地分布到最合理的路径上去，而承载着众多租户、众多业务和众多虚拟网络的物理网络的瞬时动态参数基本是不可预测的。再考虑到云中虚拟计算节点频繁的动态变化（按需创建或删除、动态迁移或调整等），我们基本可以认为，云业务的流量在云网络上的分布是“随机的”，

这样的“随机”设计给云网络运营带来最直接的挑战就是：云业务的流量有可能出现在网络中的任何一点，无法通过预先设置假设到某一点或某一条路径上去观察。

3、无法获知网络的精准健康数据

物理网络承载了云中所有的虚拟网络和租户业务，因此其健康状况直接影响到云及云中业务的运行状况。

传统的观察网络健康状况的工具，包括WebUI、SNMP、syslog等，都是属于静态的、Pull模式的工具，往往需要管理员预先定义好各种参数，然后以周期性查询的方式获取数据，这些静态的数据精度很低，只能反映查询瞬间的网络健康状况，而非网络在真正转发业务那一时刻的，而且，这些数据往往来自于网络设备的控制平面，并不能代表网络数据平面（或转发平面）最真实的健康状况。

尤为重要的是，传统的采集工具无法应对今天云中“虚拟网络运行在物理网络之上”的模型。因此，如果说传统网络的运营工具是X射线的话，今天的云网络则急需类似于CT这样具备更精准能力的工具完成深层次的网络运营。

4、运营不能对生产网造成性能影响

为了更好地对云中的生产网络（虚拟网络+物理网络）进行运营，必须从生产网络获取一定的数据供运营分析系统使用；但是，不可避免从生产网络获得运营支撑数据一定会对生产网络自身的性能带来影响。当然，运营分析系统希望获得“尽可能多的运营数据”以便能够提供更智能、更全面的分析信息，但是“尽可能多的运营数据”对生产网络而言则意味着更大的性能冲击，尤其在云计算的环境中，业务大规模集中部署，并且承载在统一的底层平台之上，对任何一个租户或业务运营数据需求的激增，都有可能影响到其他租户或业务。

很多情况下，运营分析系统的多个子系统（例如安全审计系统和性能分析系统）还需要各自得到一份数据的完整拷贝，会让这种数据获取对生产网络的冲击成倍放大。于是，数据获取不能影响生产网络（或者尽可能降低对生产网络的影响）成为了云网络运营的前提。

5、精细运营不能过度增加成本

一般来说，运营分析系统与生产网络在物理上是隔离开的，并且有一定距离，在跨数据中心、广域的场景中，这个距离很有可能是跨越城市的。因此，如何让“尽可能多的运营数据”从生产网络简捷、快速地到达后端的运营分析系统也是一个需要重点考虑的问题。

当这些“尽可能多的运营数据”抵达后，对后端运营分析系统随之而来的需求就是更大的数据存储容量与更高的数据处理性能。

例如，在一些针对网络交易质量的分析场景中，运营分析系统需要追踪、接收、存储、分析、复原每一笔交易的所有过程，精确记录过程中每一次交互的时间、状态、结果等信息，从而为决策者提供判断与决策依据；不难想象，一个这样的运营分析系统对数据存储和处理的性能要求之高。

所以，“尽可能多的运营数据”无论对于传送来说，还是对于后端的运营分析系统来说，都意味着“更高的成本”，而当这个成本高到一定程度后，也就意味着运营分析系统不再具备存在的可行性。

于是，如何有效降低整个运营分析系统的TCO（Total Cost of Ownership，总拥有成本），也成为云网络运营的刚需。

6、运营系统要将自身融合到云中

云计算的世界是软件定义的世界，从上层业务的部署到底层基础设施的调度，从虚拟计算、存储节点的创建、迁移到虚拟网络的连通、策略跟随，都是通过Cloud OS对各种业务、平台、基础设施提供的REST（REpresentation State Transfer，表述状态转移）风格API（Application Programming Interface，应用软件编程接口）的软件编程调用来完成的。

相应的，部署在云中的运营方案也需要支持同样的软件定义、统一编排能力，要能够被Cloud OS自动调度，即在需要的时候，运营人员只需要点击两下鼠标，即可完成规则定义、数据采集、数据传送、数据分析的全部过程，甚至运营系统要能够根据运营人员预先设置好的策略与触发阈值，在需要的时候自动化地完成上述过程，而不需要人工干预。

7、保护用户隐私不受侵犯

在公有云中，前述的“云与业务所有权的无关性”给云及云网络的运营带来了无法回避的合规需求。

公有云上运行着各种各样的业务，这些业务以及所产生的数据的所有权属于租户，而非公有云的运营者，而公有云的运营者在对云及云网络的运营过程中，不可避免地要获取各种业务的网络流量，此时，如何确保租户/用户的业务隐私和数据不被碰触就成了最关键的问题。

欧盟于2018年5月正式颁布执行的GDPR（General Data Protection Regulations，通用数据保护条例）就是应对这种风险的法律准备，那么，对于云的运营者来说，如何通过技术手段避免任何形式的接触用户数据，从而规避自身的法律风险，成为当务之急。

8、将运维能力作为一种服务提供给租户/用户

当租户将业务部署在云上，自然地，也就产生了对业务以及所拥有的虚拟网络的运维需求。

但是因为租户并不拥有云平台，而只拥有云上的虚拟化资源，因此，云的运营者需要将云上的运维工具作为一种增值服务提供给租户。

对于购买了这种增值服务的租户，完全可以自助部署针对特定业务系统的运维环境，实时监控业务系统的运行状况，及时发现可能的性能瓶颈与潜在的故障风险，以确保业务的连续性与高可靠性。

而对于公有云的运营者来说，这样的自助运维系统则意味着更高的用户粘性、更低的用户故障率和更多的潜在收入。

那么问题来了，云网络的运维所面临的重重困难，是如何解决的？

关注我们，下期更精彩！

-未完待续-