3.4 NFV的弹性和扩展性
VNF支持网络服务的按需部署和弹性增长。从基于硬件设备的物理架构向基于软件和多供应商的潜在开源架构转变的模型提供了诸多优势（如第3.1节所述），同时也带来了新的挑战。为确保与当前运营商级网络环境保持一致，并提供服务连续性和可预测性，我们需要将更好的软件工程与利用动态按需基础设施的架构完美结合起来。在某些情况下，它还需要与VNF相关的逻辑。正如我们将在本节中讨论的，网络云平台和特定 VNF都需要进行架构设计以实现高性能和可靠性。
弹性（Smith, 2011）是支持高服务可用性的 VNF资产。VNF是在运行 Linux的服务器和适当的虚拟机管理程序上实现的复杂软件功能。在最简单的实现形式中，VNF的可用性将低于或等于服务器可用性（我们将在第5章中对其进行详细讨论）。当服务器发生故障时，在该服务器上运行的所有软件任务都将失败并需要重新启动。服务器可能由于多种原因而发生故障。最常见的 原因是硬件故障、操作系统故障、虚拟机管理程序故障以及因维护和升级而导致服务器宕机事件。服务器故障是偶发事件，可以使用指数分布进行建模。服务提供商数据中心的服务器平均可用性范围为99.9%～99.99%（一年中有50～500min不可用）。这一变化范围是根据约为50000h的服务器平均故障间隔时间（MTBF，MeanTimeBetweenFailure）和故障情况下恢复时间的假设推断出来的 2。
通常情况下，服务提供商为大多数网络服务提供 99.99%～99.999%的可用性。主要挑战是提供在数据中心基础设施上运行的网络功能的高可用性，而数据中心基础设施的可用性非常低。
这意味着 VNF将需要在服务器发生故障时继续运行。理论上，可以通过在组织形式为高可用性集群的冗余服务器上运行 VF来实现连续操作。VMWare和 KVM都具有将一组服务器组织为高可用性集群的能力。
为了加深对弹性的理解，我们对照 3.1.3节对 VNF的分类方法，即把 VNF分为主机 VNF和中间盒 VNF 两类。
（1） 主机 VNF是数据分组流量的源点和汇聚点。承载最终用户会话的传输层连接将在主机
VNF上终止。DNS和 RADIUS是 IP网络中主机VNF的两大实例。
（2）中间盒 VNF类似于网络连接或数据流中的管道。进入中间盒 VNF的数据分组几乎总是退出以便将数据分组发送到最终目的地。通过中间盒VNF传输的数据分组可能会发生诸如报头转换等变化。通常，代理会对 HTTP报头字段进行修改以确保理想的效果，如使移动设备上的网页显示更具可读性。边缘路由器通过修改生存时间（TTL，TimeToLive）或添加 /删除封装头部字段是 VNF修改头部字段的另外一些实例。中间盒 VNF至少拥有两种接口：其中一个使用两种接口的实例是将可信网络（如专用网络）连接到不可信网络（如互联网）；另一个实例是将客户 网络连接到核心网络。中间盒 VNF始终位于可通过 VNF访问的两个（或多个）网络之间。因此， 通过中间盒 VNF来路由分组是此类 VNF的基本属性。有关中间盒 VNF的实例，请参见 3.1.3节。
主机 VNF的弹性设计非常简单。通常，设计人员可以依托单层网络云平台（服务器群集和云软件）通过在服务器发生故障时将 VNF重新定位到另一台服务器来提供高可用性。VMWare的分布式资源调度器和 KVM的实时迁移是主机 VNF用于实现高可用性的云平台功能实例。
中间盒 VNF的弹性设计是一种难度更高的问题。通常，中间盒VNF能够实现有状态功能。
VNF需要维护以下一种或多种功能所需的状态。
（1） 路由。
• 静态路由、默认路由、BGP路由和 OSPF路由。
• DHCP资源预留。
（2） 服务质量（QoS）。
• 流量整形器（如用于执行 SLA 的漏桶和峰值速率整形器）。
（3） 统计。
• 用于跟踪基于使用情况的计费或OAM功能的计数器。
（4） 连接状态。
• 防火墙或网络地址转换（NAT，NetworkAddressTranslation）的数据流状态[用户数据报协议（UDP，UserDatagramProtocol）或 TCP流 ]。
• IPSec会话（凭证、会话密钥）。
• 用于 WAN加速的压缩状态（块级压缩）。
3.4.1 多路径和分布式 VNF设计
中间盒 VNF必须支持在源端和目标端之间存在的多条网络路径上转发分组，我们将这种并行路径称为等成本路径。VNF需要对用于在多条等成本路径上路由分组的控制信息进行管理。
云通过支持在服务器集群中分配VF来实现弹性和可扩展性，以便单个 VF实例发生故障时不会中断为最终用户提供服务。管理某些组网状态需要对单个VNF进行实例化，因而可能不易支持在 VNF多个实例中拆分和分发 VNF功能。峰值速率整形是此类约束条件的一个很好的实例。我们考虑需要具备峰值速率整形功能的端到端数据流。数据流可分为两支或多支负载均衡子流， 这两支子流由两条不同路径上的两个 VNF实例进行处理（如图 3.12所示）。必须将速率计算逻辑
（如漏桶算法）和分组处理操作（缓存、转发、丢弃等）在两个或多个 VNF上进行实时分解，以便为累积流提供端到端速率控制。两个 VNF必须通信并协调速率控制统计和操作。与此类协调行为相关的时延将会导致累积速率控制不够准确。
、
图3.12 跨两个转发VNF实例的精确速率控制协调执⾏问题
存在与将VNF拆分为多个实例的难度相关的其他实例。如本节前面所述，网络流通常使用多条等成本路径，可能需要对流动路径上多个节点处的计数器和统计进行组合以满足 OAM需求。由于存在同步和不连续性问题，OAM所需的准确计算可能是非常困难的。例如，可以将两条路径的间隔统计时间加在一起，来计算在给定1 h内数据流传输的分组总数。多项计数任务之间的时间同步将是不准确的。另一个实例是TCP会话 [NAT、防火墙（FW，Firewall）和代理 ] 和点对点实体的管理状态。如果会话管理在多个 VNF上进行分割，则必须跨实例来复制状态信息。如果某个实例失败，则端到端会话将会失败。实际上，这可能导致弹性大大 降低。
尽管存在上述复杂性，操作多个并行实例仍是实现中间盒 VNF高可用性的唯一方法。在大多数情况下，将使用VNF的单转发实例在单条路径上维持单个数据流。中间盒 VNF将需要使用 VNF中的应用特定逻辑来解决与分发数据流（通常跨多个转发实例）相关的复杂性问题。VNF设计不能简单依赖基于云软件的集群管理来实现 VM移动。虚拟提供商边缘（vPE，virtualProviderEdge）路由器实例较好地说明了这一点。vPE是一种复杂中间盒 VNF。正如 3.1节所描述的，vPE可广泛用于为诸多不同服务提供 CUG功能，实现 VRF功能。企业 VPN服务、移动核心和 VoIP 服务所需的路由功能高度依赖 vPE。
