NFV解决之道：致我们无处安放的盒子

NFV到底是什么？其全称为Network Function Virtualization，即网络功能虚拟化。通过使用x86等通用性硬件以及虚拟化技术，来承载很多功能的软件处理。从而降低网络昂贵的设备成本。可以通过软硬件解耦及功能抽象，使网络设备功能不再依赖于专用硬件，资源可以充分灵活共享，实现新业务的快速开发和部署，并基于实际业务需求进行自动部署、弹性伸缩、故障隔离和自愈等。

高档盒子 VS NFVNFV对运营商来说居于前三的驱动力是业务弹性伸缩、新业务快速上线以及使用通用硬件。可不要小瞧这三个在IT领域再平常不过的要求，对于传统电信供应商来说是天翻地覆般的巨变。为什么会有这么大的差距，我们得从传统电信领域的盒子设备说起。

为了达成电信级高可靠/高性能要求，各种网元被专用硬件的金属外壳包裹着送到运营商的机房。运营商对这些铁盒子是又爱又恨，刚买那会的确省心，性能/可靠性没话说，毕竟是用大把美金买回来的高档货。但用了两三年后，新功能缺失和容量限制使得这些盒子成了鸡肋，想要扩容或者升级不得不受制于供应商的节奏，大动干戈不说，耗时数月实在伤不起。反观IT厂商如Google，Facebook，亚马逊都实现了基于通用硬件的云计算能力，不仅成本低廉，而且升级/扩容都是小case。

数据库——NFV的大脑要实现NFV，电信软件要从厚实的金属盒子中剥离出来，在通用硬件或虚拟机上同样需要达成电信级高性能和高可靠。众所周知，专用设备在硬件可靠性上有天然的优势，失去这一靠山软件只能从架构上找出路。反观互联网解决方案，不难发现业务与状态分离是实现业务系统高可靠的不二法门。

由于业务不保存状态信息，任一业务节点故障可以由其他节点接替，因此上层用户无感知。业务扩展也不再受制于节点间的状态同步，可以做到弹性伸缩。在IT架构中状态的存储与管理是由独立于业务的数据库来实现，数据库通过复制/持久化等技术保障状态数据的安全。

电信业务对可靠性的要求高于IT应用，这部分指标的达成依赖于管理业务状态的数据库。如何实现业务数据的可靠存储不再是简单的主从备份或持久化就能搞定的，因为云化环境中故障场景较传统盒子设备更复杂。DB需要从进程/虚拟机/物理主机/数据中心等不同层次考虑数据的冗余备份，才能达成电信级的高可用。由于业务支持弹性伸缩，意味着状态数据也会随之变化，数据库不能成为系统扩展的瓶颈。因此数据库本身也应该是分布式、可扩展的。

挑战——统一数据库由于不同网元中的数据各有特点，因此对于数据库的诉求也是不一而足的。通过对网元的梳理，总结下来主要包括下列三类数据：会话数据，用户数据及配置数据。如下表所示：

于是乎不同的网元使用不同数据库也是一种顺其自然的选择，但运营商更多考虑的是系统运维的复杂性和自动化程度。对于华为，欧洲大T提出了能否统一NFV数据库的殷切希望。因此我们总结对DB的另一个诉求：管理不同类型数据。

高性能是产品的竞争力，云化后各网元性能指标有了更加精细的度量。虚拟机或Docker作为计算资源的容器是可以被外部感知的，因此软件的性能不再能躲藏在电信硬件之后。另一方面传统设备中数据库多采用嵌入式部署，而云化后数据被拉远由独立数据库进行管理。但业务流程整体的时延指标不能下降，这就意味着数据库需要提供极低的时延来满足业务的E2E要求。

完美演进的关键NFV对电信行业的变更是针对软件架构的颠覆，其中达成的核心在于数据库，只有满足分布式架构，提供跨DC容灾能力，支持不同数据模型，高性能低时延数据库才能成就NFV的完美演进。可能有人会质疑这么牛的数据库真的存在么？我可以自豪地回答：GMDB就是我司自研的面向NFV/SDN的数据库。

本文转载自：http://developer.huawei.com/ict/forum/forum.php?mod=viewthread&tid=772&extra=page%3D1