在向SDDC转移的时候，要把你的传统设备搬上大台，需要花费大量的时间和仔细的研究。在移动数据中心时，要记住哪些策略呢?

SDDC: 是对数据中心所有的物理、硬件的资源进行虚拟化、软件化的一种技术。SDDC依赖于虚拟化和云计算技术， SDDC的目标是虚拟化数据中心的一切物理资源，通过虚拟化的技术，构建一个由虚拟资源组成的资源池，不仅是对服务器进行虚拟化，还包括存储虚拟化和网络虚拟化等。不仅可以简化服务器更改、存储更改、网络配置的难度，更使得对服务器、存储、网络的管理和配置操作具备可重复性和持续性。

SDDC使硬件资源可以通过软件进行配置和调度，提高了灵活性和敏捷性，带来的一个显著优势就是大大降低了数据中心的成本。通过SDDC提供的集中式的软件管理层，管理变得更简单。同时SDDC让软件来管理网络，让网络成为数据中心的一部分，专有的网络可以大幅提高硬件的效率，由此可见软件的重要性不可小视。软件定义的数据中心，将成为数据中心演进的一个新的方向和趋势。

因此，当你已经决定着手构建或向SDDC(软件定义的数据中心)过度的时候，你需要考虑一些问题。例如，当你此刻走在数据中心的热通道上，也许会让你感到沮丧。你应该如何处理数据中心内现有的设备以及运行在它们上面的应用程序呢?唯一的回答就是：就像信息技术中的大多数东西一样——是“这要看当时的情况”。

对于移动数据中心，要考虑两个基本的模型:第一,在某种形式的转换阶段中,并行地运行旧的和新的，或者将您现有设备与新的SDDC集成在一起。第二，将现有网络设备集成到独立数据中心内，错了，不是集中到一个，是两个，要么集成在pod层，要么集成在现有设备内运行SDDC的顶层。

第一模型，是并行地运行旧的和新的数据中心，这个看起来可能更简单，甚至是这样理想的情况。但即使是在理想情况下，也有一些问题需要解决。工作负载是否会在数据中心之间进行转换?如果是这样，这将如何发生?当然，这个问题的答案很大程度上取决于应用本身。在这个领域有还几个重要的问题要问。

新的数据中心架构如何满足每个特定应用程序的要求? 考虑通常考虑的问题是重要的，例如带宽利用率、延迟、抖动(Jitter是由确定性内容和高斯(随机)内容组成的。所谓jitter就是一种抖动。具体如何解释呢?其定义延迟从来源地址将要发送到目标地址，会发生不一样的延迟，这样的延迟变动是jitter。)等需求。 但考虑到域名系统，大象流量的动态管理，安全域的创建，覆盖网络等因素的存在也是很重要的。

备注：大象流量 (elephant flows)：在计算机网络中，大象流量是通过在网络链路上测量的TCP(或其他协议)流量建立的非常大的(总字节数)连续流量。大象流量虽然不是很多，但在一段时间内可占据总带宽的不成比例的份额。目前还不清楚是谁创造了“大象流”，但是这个词在2001年发表的互联网网络研究中开始发生，当时观察到，少量流量承载大部分互联网流量，剩余流量包含大量流量这些网络流量很小(鼠标流量)。例如，研究人员Mori et al，研究了几个日本大学和研究网络的交通流量。在WIDE网络中，他们发现大象流量仅占所有流量的4.7%，但在这段时间内占据了所有数据传输量的41.3%。

大象流量对互联网流量的实际影响仍然是一个研究和争论的领域。一些研究表明，大象流量可能与交通高峰和其他大象流量高度相关。大象流量在研究人员中有不同的定义，包括流量在一段时间内占据总流量的1%以上，测量流量的持续时间，并观察流量的大小大于平均值加上在此期间交通的标准偏差。大象流研究的主要目标之一是开发更高效的带宽管理工具和互联网的预测模型。例如，研究人员专注于通过对大象流量进行优先排序来为小尺寸(小流量)的流量提供更好的服务质量。

即使在最初的设计阶段，最好能够避免一些与数据中心提供后期服务相关的技术层面的问题，事实上，在这个过程中，总还是会有一些遗漏的问题。

由于有很少应用程序开发人员知道应用程序都在依赖哪些服务，或者在执行此类清单过程中做出无效假设，因此，起码，他们都不会有完整的库存。因此，当你第1天开始着手规划移动数据中心时，就需要制定明确的行动计划。

假设在新数据中心里，能提供各种所需服务，但如果将这项标准作为制定计划的基准，则很容易导致非常糟糕的结果。 假设应用程序开发人员需要修改或更新应用程序来解决其中的一些问题的时候，而不能将问题的全部重点放在网络工程团队上，而是需要放在解决应用程序本身的问题上。

应用程序将决定数据中心连接方式

在两种架构并行运行的时候，需要在它们之间建立某种形式的连接 - 数据中心互连(DCI)。 应用需求将决定一些DCI的方式，比如是否需要进行以太网上连接，或者更简单的支持IP或路由连接。

DCI (data center interconnect)互联方式：分为三层互联，也称为数据中心前端网络互联，所谓“前端网络”是指数据中心面向企业园区网或企业广域网的出口。不同数据中心(主中心、灾备中心)的前端网络通过IP技术实现互联，园区或分支的客户端通过前端网络访问各数据中心。当主数据中心发生灾难时，前端网络将实现快速收敛，客户端通过访问灾备中心以保障业务连续性;网络二层互联。也称为数据中心服务器网络互联。在不同的数据中心服务器网络接入层，构建一个跨数据中心的大二层网络(VLAN)，以满足服务器集群或虚拟机动态迁移等场景对二层网络接入的需求; SAN互联。也称为后端存储网络互联。借助传输技术(DWDM、SDH等)实现主中心和灾备中心间磁盘阵列的数据复制。

这里面临的挑战与其他任何数据中心面临的DCI挑战是相似的，SDDC系统将能支持之前更多的限制与期望。

第二种解决方案是将SDDC和现有设备集成在POD层，这是一项不同的挑战。 这个想法如下所示。

　　将SDDC设备集成在原有设备

如果不需要为了提高系统的恢复能力，连接数据中心，(事实上，在大多数现代网络中不可能)，这种类型的解决方案可以从上面的列表中删除一个挑战：DCI。

另一个优点是它允许您使用canaries探测 - 即模拟 - 随着时间的推移测试针对单个应用程序的SDDC设计方法。 在这种情况下，探测技术将涉及并行运行两个基础设施，将应用程序从遗留基础转移到SDDC来评估它们，如果它们在新环境中正常运行则将其留在那里。

备注：Canaries，要监测对函数栈的破坏，需要修改函数栈的组织，在缓冲区和控制信息(如EBP等)间插入一个canaryword。这样，当缓冲区被溢出时，组返回地址被覆盖之前canaryword会首先被覆盖。通过检查canary word的值是否被修改，就可以判断是否发生了溢出攻击。

这实际上是大多数超级、或网络规模的运营商向新基础设施过渡的方式。

然而，它增加了复杂性的一个新的要素：SDDC如何控制系统与对现有的控制如何相互影响? 事实上，流量必须从较新的SDDC POD中抽取到旧式硬件设备中，然后再返回。

如果没有什么流量工程、安全和其他政策需求，这可能就像在两个控制层之间重新分配路由信息一样简单。如果移动数据中心需要包含跨越两个域的安全区域，或者某种形式的动态流量塑造，那么这里的问题可能非常复杂。

备注：流量工程是指根据各种数据业务流量的特性选取传输路径的处理过程。流量工程用于平衡网络中的不同交换机、路由器以及链路之间的负载。流量工程在复杂的网络环境中，控制不同的业务流走不同的路径，关键的业务走可靠的路径并保证服务质量，并且在某段网络拥塞的情况下，动态调整路由，整个网络如同一个“可控的城市交通系统”。流量工程理念在上世纪90年代末提出，最初起源于互联网。其原理是在MPLS环境中，充分利用标签交换系统来为不同的业务流着色，通过LDP来传递LSP中间链路网络状态，不同颜色的业务流，根据不同的网络中间状态，动态地在网络中间传递，并且LSP能够传递RSVP网络控制信令，因此可以实现端到端的QoS或Diff-Service服务。流量工程用于平衡网络中的不同交换机、路由器以及链路之间的负载。ISP通过流量工程可以在保证网络运行高效、可靠的同时，对网络资源的利用率与流量特性加以优化，从而便于对网络实施有效的监测管理措施。应该说，流量工程早就该进入主流应用阶段了。但可惜的是，国内电信部门互联网采用流量工程的寥寥无几，行业和企业网中应用更是一片空白。究其原因，实际网络环境达不到其要求的理想环境，实施复杂。

最可能的情况是某种形式的再分配，以及在两个操作区域之间沿边缘的手动或自动调整。

这样的安排往往是简单的开始，但也往往会结束复杂的，比预期耗费更多的资源。 如果这是选择的迁移路径，最好是将应用程序从一个环境推送到另一个环境。 这种方法降低了两个环境之间交互表面的深度与广度。

将SDDC作为覆盖网络运行

本文开头提到的最后一个选项是将SDDC集成到现有设备之上运行。这可能是由SDDC供应商销售的最常见的策略，因为它允许SDDC将现有设备用于其控制和管理平面。 这也可以看起来是一个简单的答案，但是复杂性往往可以很快地发挥出来。

　　SDDC作为叠加

一般的想法是使用SDDC的强大功能来替换旧设备，随着时间的推移，使用现有设备作为SDDC的物理层的功能。

这种情况应该与SDDC环境中随着时间的推移正常的设备生命周期没有什么不同。 为此，相同的工具和流程应该从第1天开始适用，直到SDDC正在替换的传统设备从服务中移除。 但是最初的设备组合不能像SDDC的要求那样匹配任何未来的采购，可能导致几个问题。

在物理层，设备是否支持SDDC所需的南向接口? 例如，如果SDDC要求某个级别的OpenFlowsupport(如1.3)正常运行，那么所有现有的传统设备是否都支持此级别的操作? 如果供应商声称支持，它是否已经过测试? 要知道，现有的所有设备必须在新的环境下重新验证。

在控制层上，SDDC覆盖将如何与现有的控制平面相互作用，将现有的设备连接在一起，并将流量从一个部分传输到另一个部分? 现有控制层的所有功能(包括哪些工具和功能已建成)都可以集成到SDDC叠加层中?

如果现有的控制层是某种旨在向网络提供API的结构覆盖而不是运行更传统的分布式协议的设备(例如IS-IS或边界网关协议。)

管理方法增加复杂性

系统从控制到管理方面，问题都不少。 现有网络中的每个设备都被设计为以特定方式进行管理。 有的可能只有管理信息库接口; 其他人可能只有命令行界面; 其他人可能使用一组YANG模型的RESTful接口; 而且，其他人可能通过GRPC界面进行最好的管理。

SDDC能否从所有设备中获取信息，并将配置推到这个范围广泛的接口中?你会得到什么数据，你会失去什么?这是另一个需要广泛测试和验证的领域，特别是针对未来的需求。永远不要指望“在我们需要这个功能之前，硬件将会被取代”。考虑一下你的应用程序在未来可能遇到的有限功能的障碍，以及这对你的业务意味着什么。

一个并行的问题是能够快速故障排除和解决问题的能力——修复网络的平均时间与总体可用性直接相关，这是网络在支持业务方面的有效性的关键度量。

在这种情况下，允许您查看网络状况，以便在问题影响操作之前解决问题，并快速发现影响操作的问题。 检查当前用于快速恢复服务的流程与SDDC叠加的功能是非常重要的，以确定哪里可能存在差距。

也许通过SDDC转换最难管理的传统设备之一是基于设备的防火墙。 虽然广泛部署以在架构内创建安全区域，并将架构内的区域与无区域隔离，但基于设备的防火墙很可能是有效管理的最困难的设备。

在现有设备之上叠加SDDC将挑战基于设备的防火墙，其中包括隧道封装，动态策略和其他难以解决的问题。 在覆盖模型中，安全需要完全重新考虑，包括将安全区从现有的基于设备的防火墙迁移到由SDDC系统本身提供的其他技术。

将数据中心移动到一个SDDC可以随着时间的推移建立一个更清洁的网络，并有许多新的选择来构建和管理一个满足业务需要的网络。然而，将现有设备转换为SDDC环境所需要的中间步骤可能是复杂的。在移动数据中心时，网络运营商需要考虑这些挑战，并仔细规划它们