SDN创新局　Google强力背书

当企业汲汲营营踏进云端世界后，很容易就会体认到，光是实现服务器虚拟化、储存虚拟化，其实还不够，且两项技术的实践难度，也还在可受控制的范围内，剩下来最棘手的部分，无疑就是网络这一环。

只要一谈论云端运算，企业IT人员立即涌上脑海的头号技术要务，十之八九都是服务器虚拟化，而当此项技术推展到一定阶段后，紧接着就会透过相关管理工具的采用，逐步建立所谓的自动化机制。

接下来，有感于大量虚拟机器所挟带的庞大数据存取需求，难免凸显现有储存架构之不足，于是为了优化应用服务的执行性能，便会着手导入储存虚拟化；更有甚者，一些较晚启动云端建置的企业，在规划专案内容时，一出手便是同时实施运算、储存等两项虚拟化技术。

做到这里，够了吗？理论上是够的，但要不了多久，企业往往就会发现一个现象，随着部署新应用服务的频率提高，数据量也加大，此时即会被迫反覆重置网络设定，而且还不时因为传递大量数据而拖垮网络效能，尤其云端应用规模愈大的企业或服务供应商，此类情况尤其明显。

看到这里，或许有人备感纳闷，相较于运算、储存这两大环节，网络明明相对稳定成熟，按理说问题理应较少，无奈在于网络这一块，不仅可能出现上述令人苦恼的现象，且在面临多租户(Multi-Tenancy)环境时，还经常出现瓶颈，时时扮演冲击云端应用效能的杀手，真不知诸如此类的难题，应该如何化解？莫非得赶紧推动网络虚拟化？而当前有哪些主流技术，最有助于实现网络虚拟化愿景？

传统网络架构　罩门一一浮现
意欲探究解决之道，不妨先从传统网络架构的罩门开始说起。以目前举世所见，最大规模着手颠覆传统架构的Google为例，以往最感困扰之处，在于每回在新的应用服务上线之前，皆须大费周章针对旗下多不胜数的交换器或路由器，不厌其烦地进行CLI设定，而且为了担心IP、Routing或防火墙出现设定错误情事，就莫名其妙造成网络瘫痪，因此在搞定一切设定事宜后，亦需要进行详细的测试，如此耗时费工，难免延宕了新与服务的开通时程。

撇开Google这般网络巨擘不谈，即使是一般规模稍大的企业，也一样会在网络这一层吃足苦头。主因在于，传统VLAN的可配置上限，走到顶端就是4,096个ID，若在传统IT环境，这个极限值也还够用，但对于高度虚拟化的数据中心来说，「屈屈」4,096个ID，却是明显不足的。此时该如何是好？似乎别无他法，只能从VLAN Trunking下手寻求解决之道，但即使如此，用户还是难以真正打通「任督二脉」，而且容易制造新的问题，因为当所有交换机形成了一颗相互连接的树，彼此难免需要一番学习适应，很快就会把TCAM存储器空间用满，因而导致网络趋于不稳。

值此时刻，Google的革新之道，无疑将带给世人莫大启发；而该公司的做法，便是将数据中心网络基础架构全面转换到OpenFlow，也因此而造就迄今全球最大的「软件定义网络(Software-defined Networks；SDN)」。

Google临门一脚　无异为SDN强力背书
看到这里，相信对SDN的背景稍有认识的人士，难免认为Google实在大胆。此乃由于，OpenFlow这个至今仍未甩脱实验性质的技术，打从2006年经由史丹佛大学发表到现在，不过历经了不到7年的时间，尚无前人将之大举运用在商业环境，而Google竟决意挥别沿用数十年的传统网络技术，愿意朝向这个新生儿放手一搏，背后隐含的意义着实重大。

一来，大如Google的业者，都胆敢把吃饭家伙押注在OpenFlow及SDN之上，显见他们势必经过仔细盘算，反覆验证了此项技术确实可行，才会信心满满地做出决定，这也意谓着，SDN已非理论性、概念性的产物，而是真的可以付诸实践；其次，在这场「豪赌」的背后，似乎也充分吐露，在虚拟化、云端化的世界里，传统网络架构真的愈来愈寸步难行，不赶紧做一番「了断」，日后包袱势将愈来愈大。

究竟SDN为何物？顾名思义，即是扬弃过往的Routing Table，改以控制软件所设定的政策，来主宰一切的封包传递路径；说得更具体一些，就是藉由软件式控制器，一举取代掉传统网络设备的「大脑」－操作系统加功能单元，继而取得「导航」的主控权，它不再迁就于层层辗转的网络架构，也无须绕行过去曲曲折折的羊肠小径，而是比从前更具智能，懂得透过持续不断的模拟试算，在封包的来源地与目的地之间，演算出传输效率最佳的路径。至于OpenFlow，则是赖以实践SDN的交换技术。

反观传统网络设备，最主要的问题在于，随着厂牌与供应商的不同，一来会产生一个个独一无二的操作系统，二来也会根据各自的操作系统，繁衍出一个个独一无二的特殊应用IC(Application-specific IC；ASIC)，并由ASIC来执行Routing Table的演算任务。

单就上述的来龙去脉观之，不难让人理解，过去的网络设备充斥了封闭气息，各自都有各自的独门秘技，所以在看似大一统的业界标准协定外，尚埋藏了许多不尽兼容的阻碍，这些由来已久的路障，无疑正是拖累网络传输效能的关键所在，这些问题，过去或许尚在人们容忍的范围之内，但到了虚拟化、云端化时代，从前若隐若现的「拦路虎」，将更加清晰可见！

因为传统的阶层式架构、Spanning Tree协定，犹如盘根错节，实在塑造了太多的延迟(Latency)现象；试想，假如企业基于某些不得不然的因素，亟欲将驻留在某台实体服务器的20个虚拟机器，实时迁移到另一台主机，却坏在网络根本认不得Mac位址或VLAN编号，所以无法直接支持这般迁移动作，还需要劳烦网管人员以手动方式更改一切设定，其间所耗费的可观时间，便有可能导致大量金流的凭空消失，教企业主怎能忍受？唯有以SDN形塑出最扁平、最饶富弹性的新架构，把VLANs、ACL、QoS、PVLANs或Service Routing等繁琐协定通通抛开，才可望化解这一切的扞格。

而且坦白来说，一直以来，企业之所以为建设数据中心而付出庞大成本，某种程度上，也是被逼得替上述要价不菲的ASIC买单所致，再加上这些东西如影随形，不管Core、Aggregation或Access等不同阶层所在多有，加总起来的财务负担，难免让原本颇具利润或效益空间的网络应用服务，硬生生被挤压成为蝇头小利。如今有了软件控制器当做大脑，ASIC便无存在必要，可使交换器蜕变成仅须听候差遣的Dump Pipe，只管好单纯的Forwarding任务即可，一来一往之间，网络建置成本落差之大，也可望让企业主眉开眼笑。

综此，凭藉OpenFlow与SDN作为网络控制枢纽，随时计算最佳路径，任凭交换器暂时遭逢壅塞状况，也能随即接收到软件的指示，自动转向另一条畅通道路，继续执行Forwarding任务，致使封包传输速度显着提升；唯有如此，方能有助于企业加快云端应用服务递送的效率，即使肇因于大量移动设备、巨量数据，突然爆出事前难以预期的流量，抑或川流不息的服务请求，都可藉由SDN展现灵活身段，透过始终优异如常的交换品质，有效克服一切考验。