SDN数据中心可能是未来的大趋势，但这并不意味着它只是简单的转换。因此，如果您的组织希望在部署SDN数据中心方面取得进展，那么您需要为您的遗留遗留设备制定一个清晰的计划。本指南旨在帮助您确定在您的企业中实施SDN数据中心所需的后续步骤。定义了SDN数据中心后，下一步是什么？答案仍然取决于你问的是谁，许多关于软件定义网络的对话将非常明智地从一个问题开始：什么是SDN？根据我们自己的定义，“在软件定义网络中，网络管理员可以从一个集中考虑服务器或其他设备连接到什么特定设备。听起来很简单，对吧？但实际上并非如此。事实证明，至少在数据中心，仍然存在大量的复杂性。年中取得了长足的进步，但它的部署过程仍然很重要。在这篇详细介绍在数据中心部署SDN的指南中，我们的专家探讨了SDDC过渡的挑战以及如何预见和克服这些挑战。这些挑战。比如用SDN搭建私有云，并不是为了解决人员短缺的问题，虽然软件定义网络在这方面确实有优势。因此，当您的企业在评估软件定义的数据中心是否适合您的组织时，有一些关键问题需要考虑。如果您的企业决定部署SDN数据中心，那么您需要对您的传统设备有一个清晰的规划；从战略上协调新旧设备的见解。本文中的专家探索SDDC，他们不仅解释了SDN数据中心的性质，还帮助您确定从哪里开始。更轻松的数据中心SDN部署将推动私有云的发展因为软件定义网络可以将网络控制与数据包传输分开，它有可能改变所有数据网络。但大多数企业组织目前都关注SDN可以在数据中心为他们做什么。一方面，通过使用网络是完全可编程的，SDN承诺使网络像虚拟服务器和存储一样灵活、敏捷和自动化，这使得数据中心的功能更像云服务。另一方面，通过微分段，SDN为改善数据中心安全环境提供了一种更加灵活和可管理的技术。鉴于所有这些，以及SDN已经以这种或那种方式讨论了五年或更长时间的事实，仍然只有不到10%的企业组织在生产中部署了数据中心SDN。事实证明，尽管SDN技术已经足够成熟，具有足够的稳定性和可扩展性，可以为企业提供服务，但它仍然不容易部署，或者至少不容易广泛深入地部署。早期采用者表达了类似的烦恼。他们说，SDN的部署可能使他们希望的简化成为可能，但成功将需要大量的努力。艰苦的工作是彻底映射数据中心中的关系网络，以了解如何正确地对网络进行分段。在生产中，复杂性还涉及手动构建安全组和策略，以及集成各种工具要求以提供真正的类云行为。云管理，数据中心SDN作为内部云计算对于寻求构建真正私有云的企业来说，数据中心SDN只是一个更大问题的一个方面。任何致力于这一努力的企业都必须进行一些艰难的计算。组织必须决定使用虚拟化、SDN和云管理平台创建私有云的努力是否值得投资。为了使其适用于企业组织，他们必须购买或构建一个低级构建块层，其中包括各种虚拟服务器、虚拟存储服务和网络。他们还必须开发或获得中间件功能：一个内部平台或服务，提供数据库服务和应用程序服务，具有负载平衡和冗余。然后，他们必须将这些服务集中在一个门户和目录中，并提供适当的文档，以防止与他们的资源库相同的悲剧重演。然后，当然，他们还必须提供业务流程编排层，使其能够响应业务需求和工作负载的变化。即使有云管理平台，也需要很多层的努力，给系统集成带来巨大的负担。对于一些组织来说，毫无疑问，这种努力是值得的。但对于其他人来说，使用公共云作为应对策略并不是一种选择。对于上述企业，另一种选择是充分利用公共云产品或云服务。亚马逊、微软、谷歌、IBM、甲骨文和其他供应商已经完成了低级工作，并在不同程度上完成了一些中级工作，在幕后提供了许多必要的业务流程编排。例如，鉴于75%的企业组织已经在某种程度上使用IaaS，他们是否可以证明此时部署内部云的努力是合理的？鉴于已经有如此多的提供商提供云服务，是否值得他们重新设计一个可扩展的、弹性的数据库服务？仔细检查后，他们更有可能发现他们在数据中心坚持虚拟化而不是完全“云化”操作，同时扩大公共云的使用更有意义，至少在用云构建私有云变得更简单之前是这样经理和数据中心SDN以及所有其他人。如何评估SDN在您的网络中的优势在过去的几年里，软件定义网络已经从一项科学实验发展成为一种可部署的企业就绪技术，从BigSwitchNetworks和Pica8到Hewlett-PackardEnterprise和包括在内的VMware提供商已采用不同的用例来提供服务。尽管如此，NemertesResearch的2016年云和数据中心基准调查发现，只有超过9%的企业组织在生产中部署了SDN。说到SDN的好处，让我们看看该技术可以解决的三个最重要的问题，以及SDN可以帮助您解决的一些值得考虑的问题。更智能的访问：SDN技术的一个主要优势是它能够帮助您的企业从安全和性能管理的角度更智能地访问分支机构和园区网络边缘。例如，SDN可以同时为包括语音、协作和视频在内的统一通信会话提供网络访问控制和动态应用优化的平台。网络虚拟化：SDN的关键支柱和预期优势之一是能够虚拟化网络，或者换句话说，将一个或多个逻辑上分离的网络叠加在单个物理层之上。因此，在不受布线决定的网络架构中，网络功能可以在需要的时间和地点应用。虚拟网络为作为数据中心安全策略的微分段提供了基础。例如，它们还可以在插入时将视频电话识别为智能接入层的一部分，并将它们分配给特定的虚拟网络以进行性能管理。数据中心网络自动化：对于许多IT组织而言，数据中心网络仍然是快速部署新服务、产品和虚拟基础设施的关键。SDN的一个好处是通过使用产品或服务的API帮助使网络更直接地编写脚本。帮助您的企业确定SDN优势的问题那么，现在是仔细研究SDN的时候了吗？在您的企业进行决策过程时，请务必考虑以下问题。相关网络（包括边缘接入和数据中心）是否已为SDN做好准备？换句话说，您企业的网络设备是否足够新，足以成为基于OpenFlow的软件定义网络的一部分？如果没有，是时候更新这些设备是否正在更换？如果答案是肯定的，您的组织可以将SDN作为更换这些设备的关键标准。如果不是更换设备的时候，您的组织面临的问题是否严重到需要在常规更新周期之外进行更换？您的组织也可以考虑有选择地覆盖SDN基础设施，只有在最需要的时候。在需要的地方添加必要的设备并从那里扩展。您的供应商或供应商能否为您提供经过验证的架构或部署蓝图以满足您的特定业务需求？您的供应商能否为您提供您想做的事情的参考资料？或其他做过类似事情的企业的经验可以作为您企业的指南？您的企业能否以最少的设备和时间投资在试点部署中解决有意义的问题？问题？您的企业不应该在没有测试以确保它确实有效的情况下孤注一掷地过渡到新平台。您的企业是否有强大的变更管理流程？当您对技术进行根本性转变时，您需要一个。如果您的企业的目标是解决数据中心问题，尤其是支持微分段，您的系统是否具有强大的关系映射信息？也就是说，您是否完全了解您的企业希望应用于微细分关系的系统之间的关系？该领域的早期采用者反复告诉NemertesResearch的研究人员，当他们意识到自己对哪些系统真正需要相互通信的知识不完整时，他们的项目速度显着放缓。不难发现哪些系统相互通信。但是要知道哪些系统应该相互通信是很困难的。Nemertes多年来一直强调，所有网络收购最终都应考虑SDN部署。现在是开始确定该部署的第一步以及是否开始了解SDN可以为您的组织带来的好处的时候了。数据中心迁移策略：在SDDC过渡期间应考虑的事项似乎是一种令人沮丧的练习。您的企业应该如何处理现有设备和在其上运行的相关应用程序？答案是：与IT中的大多数事情一样，“视情况而定！”迁移数据中心时，有两种基本模型需要考虑：并行运行旧设备和新设备，或者在某种形式的过渡阶段将现有设备与较新的SDDC集成。第二。将现有设备集成到单个数据中心架构中，不是在一个地方，而是在两个地方：在pod级别集成，或在现有设备之上运行SDDC。并行运行新旧数据中心似乎更简单——甚至是理想的。但即使在理想情况下，也有相应的问题需要解决。工作负载能否在数据中心之间迁移？如果是这样，这些迁移将如何发生？当然，这些问题的大部分答案将取决于应用程序本身。在这个领域有几个重要的问题需要解决。新的数据中心架构能否满足每个特定应用的要求？重要的是要考虑常见的考虑因素，例如带宽利用率、延迟和抖动要求。但同样重要的是要考虑域名系统、大象流动态管理、安全区创建、覆盖网络等服务的存在和其他因素。虽然在设计阶段可以而且应该避免与架构提供的服务相关的许多问题，但总会有一些遗漏。至少，没有一个清单是完整的，因为很少有应用程序所有者能够知道他们的应用程序所依赖的所有服务，或者他们会在执行此类清单的过程中做出无效的假设。对于这些情况，从第一天开始迁移数据中心时就需要一个明确的行动计划。很容易假设每项服务都可以在新架构上交付，但将其用作规划基准通常会导致非常糟糕的结果。最好假设应用程序的所有者将需要修改或更新应用程序以修复其中的一些问题，而不是将整个问题交给网络工程团队。该应用程序将确定数据中心如何相互关联。当两种架构并行运行时，它们之间需要某种形式的连接，即：数据中心互连(DCI)。应用需求将决定此DCI的外观，例如是否需要顶层以太网连接，或更简单的IP支持或路由连接。这里的挑战与DCI在任何其他数据中心面临的挑战类似，具有SDDC系统支持和预期的额外限制。第二种解决方案是将SDDC与pod级别的现有设备集成，提出了一系列不同的挑战。这个想法在下面详述。如果不需要连接数据中心结构以实现弹性（这在大多数现代网络中不太可能），则此类解决方案可以消除上述一大挑战：DCI。另一个优点是，它允许您使用模拟来测试您的SDDC设计方法，以适应不同时间的各个应用程序。在这种情况下，它将涉及并行运行两个基础架构，将应用程序从传统基础迁移到SDDC，对其进行评估，如果它们能在新环境中正常运行，则将它们留在那里。这实际上是大多数超大规模或网络规模运营商向新基础设施过渡的方式。但是，它增加了一个需要考虑的新问题：SDDC控制平面将如何与现有控制平面交互？不知何故，流量必须从较新的SDDCpod流向较旧的硬件，然后再返回。如果流量工程、安全和其他策略要求很少，这可能就像在两个控制平面之间重新分配路由信息一样简单。如果迁移数据中心需要包括跨越两个域的安全区域或某种形式的动态流量整形，那么这里的问题可能会很复杂。最可能的情况是某种形式的重新分配与手动或自动调整两个操作区域之间的边缘相结合。这样的安排往往开始简单，但也往往结束复杂，并且会消耗比预期更多的资源。如果这是选择的迁移路径，最好将应用程序作为一个组从一个环境推送到另一个环境。这种方法减少了两个环境表面之间相互作用的深度和宽度。将SDDC作为覆盖运行本文前面提到的最后一个选项是将SDDC作为覆盖运行在现有设备之上。这可能是SDDC供应商出售的最常见策略，因为这允许SDDC将现有设备用于其控制和管理平面。这似乎也是一个简单的答案，但随着混合的进行，复杂性往往会很快增加。总体思路是利用SDDC的功能，随着时间的推移用新设备替换旧设备，将现有设备用作SDDC的物理层。这种情况应该与SDDC环境中的设备随时间推移经历的正常使用周期没有什么不同。为此，从第一天开始就应使用相同的工具和流程，直到SDDC替换的旧设备停止使用。但最初的设备组合与未来的任何设备采购以及SDDC的要求都不匹配，这可能会导致问题。在物理层，设备是否支持SDDC要求的南向接口？例如，如果SDDC需要特定级别（例如1.3）的OpenFlow支持才能正常运行，是否所有现有的旧设备都支持该级别的操作？如果供应商声称支持，是否经过测试？可以肯定的是，所有现有设备都必须重新验证才能在新环境中运行。在控制平面，SDDC覆盖如何与现有控制平面交互以将设备连接在一起并将流量从架构的一部分吸引到另一部分？现有控制平面（已经围绕它构建的工具和功能）的所有功能都可以集成到SDDC覆盖中吗？如果现有的控制平面旨在为网络提供某种结构性的API覆盖，而不是运行更传统的分布式协议（如IS-IS或边界网关）协议的设备集合，那么这将更加困难要解决的问题。管理方法的复杂性增加当从控制转向管理时，问题成倍增加。现有网络中的每台设备都设计为以特定方式进行管理。有些设备可能只有一个MIB接口；其他人可能只有命令行界面；其他人可能有一个使用一组YANG模型的RESTful接口；同样，其他设备可能最好通过gRPC接口进行管理。SDDC能否从所有设备上的各种接口中提取信息并推送配置？您的数据中心将获得什么遥测，又将失去什么？这是另一个需要广泛测试和验证的领域，特别是对于未来的要求。不要期望“硬件会在我们需要之前被替换”。仔细考虑您的应用程序在未来功能方面可能面临哪些限制，以及这对您的业务意味着什么。一个并行的问题是快速排除故障和解决问题的能力——修复网络的平均时间与整体可用性直接相关，并且是衡量网络支持业务有效性的关键指标。在这种情况下，遥测允许您查看网络状况，以便您可以在问题影响故障操作之前解决问题，并快速找到影响的根本原因。根据SDDC覆盖范围确定可能存在任何潜在问题的能力，检查当前用于快速恢复服务的流程非常重要。通过SDDC过渡管理的最困难的遗留设备也许是基于设备的防火墙。虽然广泛部署以在数据中心结构内创建安全区域并将结构内的区域与结构外的区域分开，但基于设备的防火墙可能是最难有效管理的设备。在现有设备之上叠加SDDC将通过隧道封装、动态策略和其他难以解决的问题挑战基于设备的防火墙。在覆盖模型中，需要重新考虑安全性，包括如何将安全区域从现有的基于设备的防火墙迁移到SDDC系统本身提供的其他技术。将数据中心移至SDDC可以使网络随着时间的推移变得更加清洁，并为构建和管理大型网络提供许多新选项以满足业务需求。但是，将现有设备过渡到SDDC环境所需的中间步骤可能很复杂。因此，网络运营商需要考虑这些挑战并仔细规划他们的应对措施。
