云厂商质疑SDN 理论分析究竟是否该用

最近有一家知名云厂商对SDN这一概念提出质疑。他们认为该技术的发展程度还不足以使人受益。

那么他们的SDN理念是什么呢?客户保留着若干业务单位为on-demand运算和存储提供大量推动扩展需求。他们希望自己的网络不可视,从不影响应用环境。显然,他们的数据中心也不是用来试水的地方。

云厂商质疑SDN 理论分析究竟是否该用?

这一点不让人意外,对于同类企业而言难题都类似:

1. 部署新的硬件(如从1G到10G)和选择新供应商便产生了持续的再教育,管理和操作型架构变更需求。这些阻碍一般会导致一些顾客接受唯一供应商,端到端的方法。

2. OpEx高过CapEx,所以90%的成本是可操作的。物理设备的价格持续下跌,因为内存成本在下降而系统集成程度在提高。虽然有些人称这为迎接消费化,但是集资费用不再主导IT预算。

3. 保留一个内部灵活,更改成本高的拓扑结构。网络建设趋于稳定,这意味着它们更容易被改变。由于有了云计算,工作负载管理现状需要各种更为快速的网速,这样才能改变网络配置适应工作负载环境中的变化。

讽刺的是,大多数SDN支持者都会说“这就是SDN将提供的优势”。

如果你有开放的SDN:

1. 你可以从硬件中提取网络操作系统,然后从网络中提取应用。这是使用白盒服务器的普遍想法,而把这种层级的提取反映到网络技术中而是关键的一步。一旦你有了利用持续软件环境的自由,硬件更改就不会引发一系列的关联和操作问题。

2. 如果你的硬件被提取和消费品化,你就可以考虑通过常用创建模块扩展的新型拓扑结构,实现水平方向(服务器数量)和垂直方向的扩展,让大量服务器阵列聚合在 一起,使其在数据中心之外具备线速率或近线速率通道。用基架,行和满是CPU的数据中心搭建的云/运算资源确实是现在被普遍接受的平行方法。

3. 你可以在不改变物理拓扑结构的情况下对网络进行编程,而这样又有助于减少OpEx和意外的停工时间。编程是基于“黄金标准”策略,脚本是实现服务器管理自动化的常用方式。网络技术可以沿着外部编程的方向继续发展,而这也会有助于IT团队解决操作难题——成本和意外停工。

无论你是将这种理念称作是SDN还是开放型网络,都没有关系。所有拥有大型数据中心的公司都需要了解SDN可以如何协助他们解决问题,不要再等待。