SDN技术路线选择和SDN规划初期重点

SDN 技术路线选择和 SDN 规划初期重点SDN 技术路线选择和 SDN 规划初期重点计算、存储当前已经在做云化的落地，但是光有存储和计算的云化，不是一个完整的云解决方案。如果要做到云化、服务化，把 SDN 带进去会不会是一个比较好的选择？在 SDN 技术路线的选型上又应该如何选择？规划 SDN 网络应该注意哪些？ 1、企业为什么需要上 SDN，能给带来什么好处？近年来，随着数据中心云化的加速，云作为最新的基础设施形态开始被行业认同并接纳。但在云环境下，传统网络技术架构受到了挑战：一方面虚拟化思想的出现，颠覆了原有的数据中心网络模型，使得传统网络技术已不足以适配云环境下产生的新场景，如虚拟机的出现要求网络颗粒度从物理机细化到了虚拟机级别；另一方面面向互联网的创新业务的快速发展，也会对网络的性能、弹性等特性提出更高的要求。软件定义网络（SDN）技术通过分布式架构理念，将网络中数据平面与控制平面相分离，从而实现了网络流量的灵活控制，为核心网络及应用的创新提供了良好的平台，其与云网络发展趋势相契合，是实现云网络服务的有效支撑技术。2、SDN 架构与传统的架构相比有哪些优势，尤其是成本这一块？SDN 并不能降低网络设备采购成本。SDN 价值主要是使企业可以应对上云后所产生的灵活多变的网络需求，提升运维效率和网络的稳定性。如果不与云平台对接，上 SDN 也没有意义了。当然也存在一些对接风险问题，这就需要企业根据自身情况进行评估。3、如何根据不同的场景选择 SDN 的技术路线及厂商？SDN 发展多年，已较为成熟，各家厂商基本上都能够覆盖当前的企业场景需求。重要的还是后期支持能力，响应的敏捷度，以及价格。4、硬件 SDN 与软件 SDN 分别指什么？硬件与软件 SDN 的优劣势分别是什么？SDN 方案分为硬件和软件两大类。硬件 SDN 是采用专用的硬件交换设备与控制器来实现相关的网络功能，控制器对硬件设备进行策略以及流表的下发，来实现网络相关的功能。它的优点是性能强，比较稳定，缺点是不灵活且组网成本很高。而在软件 SDN 的解决方案中，网络的功能是通过软件层面的 Linu_ 协议栈以及相关的虚拟交换机技术实现的。它的优点可以避免对硬件网络设备的过度依赖，同时降低了组网的成本，但是软件方案的缺点也比较明显，主要表现在网络的稳定性、性能和可扩展性不如硬件方案。5、软件和硬件 SDN，在性能上会有多大的差异，对于后期运维管理而言，会有什么区别？之前对 ovs+v_lan 方案的性能进行过测试，在无任何加速手段的情况下，极限性能只能跑到 3g 多一点，瓶颈出在对 v_lan 报头的解封装上面，只能在服务器中进行软卸载，导致性能感人。但是有许多加速的手段，一是采用 dpdk 进行软件加速，单对 vm 极限速率可提升到近 5g，3 对即可打满；还有就是在服务器上配置具备 v_lan 解封装能力的网卡，也能够打满万兆网卡，提升能力比 dpdk更强，但这还是依赖了硬件能力。另外软件 SDN 性能与方案架构也有关系，比如分布式路由性能要强于集中路由。对后期管理而言，软件方案对物理网络设备没有太大影响，主要都是通过 openflow 流表实现；硬件方案网络设备上配置较复杂，在上面实现 v_lan 能力，服务器上依然通过流表实现 VLAN。如果自己长期维护，稳定性上硬件要强于软件，但是难度上也高于软件。6、软件 SDN 是否符合金融业对网络架构中隔离性的要求？随着 SDN 在各个测试环境的落地和实施，通过实践经验和压力测试过程，连接外部关联的防火墙，蜜罐，内部软防火墙等等设备后，SDN 已经符合目前要求的等保标准和生产标准。SDN 的软防火墙已经和硬防火墙有同等防御能力和共功能。而且目前新建数据中心网络多部署 SDN 网络结构。7、软件 SDN 使用普通服务器进行网络控制，这部分服务器由系统工程师还是网络工程师来进行规划和维护工作比较好？SDN 设备部署和基础环境管理是网络管理员责任，包括交换机，防火墙，蜜罐，放渗透设备等。软路由和防火墙策略关系等业务网络连接特性和访问关系，由运维人员负责处理。8、企业当前网络结构较复杂，如何能够快速切换到全 SDN 解决方案？从传统网络切换到 SDN 网络需要详细规划业务网络部署情况和互联情况。先规划出网络区域、网络物理层级、各个业务的互联情况、外联情况、数据过强和蜜罐位置。完成上面需求分析p 后，规划新的 SDN部署过程和 ip 网段等的分配方式和分类。9、规划 SDN 网络时，应该提前考虑和规划好什么内容？一般从大到小开始规划，首先 SDN 网络定位是新建数据中心内的 SDN，还是传统网络搬迁到同址的SDN，IP 地址规划和新老网互通方式。接着是定位 sdn 的整体容灾架构，是同城双中心二层打通的 SDN还是三层独立的 SDN 网络。接着是 fabric 的部署模式，一般取决于 az 域或者服务器规模和成本考虑。fabric 整体的收敛比，互联带宽大小，v_lan 互联方式，vpc 规划，分布式网关集中式网关。如果涉及传统业务搬迁，提前考虑搬迁计划和方案。underlay 的部署模式，SDN 控制器是通过带内管理还是带外管理。也要考虑模块距离长度的问题，防火墙的部署模式，负载均衡设备的部署模式，安全隔离方案南北向和东西向是否都需要隔离，东西向是否需要服务链引流到防火墙，服务链的匹配能力是否兼容现有网络尤其是负载均衡的 vs。从大的层面来看，与云平台采用什么模式对接、业务分布及网络规划如何、怎样与传统区域互通等等。从小层面来看，防火墙、负载均衡的接入方式，业务网、数据网、管理网及带外如何规划，每张网络上都跑什么样的数据，Qos 策略如何设计能够满足业务需求，ACL 安全控制规划等等。10、不同厂商的 SDN 是否可以实现对接，对接前需要准备什么内容？现在主流厂商 SDN 产品一般来说不建议跨厂商纳管，在早期 SDN 经常讲白牌交换机，和 openflow 统一管理，但其实现在主流方案都不是这样实现了。一般都是同厂商来实现比较合适，版本升级简单，功能更全面。不同厂商 SDN 一般之间三层隔离打通，物理和逻辑上是独立的 SDN，这样比较好一些。或者可以找一些相应的云管厂商在多个 SDN 控制器上封装一层面向客户，就是一个大的 SDN 控制器。11、银行传统数据中心升级改造，SDN 如何兼顾传统数据中心，消除掉不纳管不搭桥不监控现象，是否有较优的过渡解决方案？可以在同城双中心先搭建好跨中心端到端 v_lan 的两个 SDN fabric，在这两个 fabric 上增加 leaf，用border leaf 与传统网络各个区域的核心三层和二层打通，然后把 leaf 按照搬迁计划部署到相应服务器附近新布线，服务器 ip 和位置不动，只换接入线缆让其接入 SDN 网络，一般尽量相同网段一批搬迁，然后再迁移网关从传统核心到 SDN 分布式网关，这样逐步搬迁就可以完成，民生银行数据中心就是采用这种方案完成传统网络向 SDN 网络升级。12、双活数据中心的架构模式下，大二层的意义是什么？是做大二层的 IAAS 层面资灵活调配，还是做基于应用弹性部署的 3 层负载更加便于管理？哪一种更代表趋势？二层打通会增加虚拟机的漂移范围，做跨中心的大二层一般是有两个原因，一是两个中心 A 和 B 资利用率极不平衡，所以需要虚拟机的跨中心漂移来对中心资进行再平衡，降低其中一个中心的资负载；二是客户提出明确需求，云平台支持跨中心的虚拟机漂移，以满足特殊业务需求。跨中心大二层的打通不会带来管理上的便捷，只会增加管理复杂性，一旦出现故障，由于传输线路过长，将极难定位问题。另外跨中心大二层打通会使逻辑上的东西流量变为实质上的南北流量，会增加核心以及骨干的负担，增加专线资消耗。虽然目前不会出现广播风暴的问题，但在无硬需求场景的情况下，不建议做跨中心大二层。以上纯属个人看法，也请大家讨论。这个问题我的经验是这样的：一般多个数据中心之间是否打通二层最关键是取决于数据库的容灾切换方式。一般银行数据中心重要系统的数据库还是主备架构，主数据所在同机房使用操作系统 HA 或者数据库层的同步技术实现同机房容灾确保 rto 时间较小。在同城灾备机房的备库，使用存储同步技术保证备库数据一致性。在异地灾备机房的备库使用存储异步或者数据库层异步技术保证数据库一致性。当主库所在机房发生灾难需要切换到同城容灾机房的备库的时候，有两种方式实现容灾。1.在 app 使用ip 地址访问数据库的场景下，最快速的切换方式是把备库的 ip 地址改为主库相同的地址，避免更改大量 app 服务器的配置加快切换速度。2.在 app 使用 dns 域名访问数据库的场景下，只需要更改 dns 的a 记录解析即可完成切换。第一种切换方式是传统比较常用的方式，使用这种方式的前提的同城双中心需要二层打通部署相同网段，这样才支持跨数据中心修改成相同的 ip 地址。第二种切换方式不需要二层打通，主备库 ip 可以不同网段，当然 dns 改造和 GSLB 是必须的。所以一般是否需要打通大二层主要取决于数据库容灾切换的方式，sdn 同理，建议传统同城数据中心是大二层架构的可以直接搭建同样打通二层的 sdn，如果使用 dns 或者负载均衡挂在数据库并且已完成dns 改造和 gslb 方案的可以搭建三层隔离的 sdn 网络，当然从先进性和运维角度后者是未来的主流趋势。这个问题需要从以下两个方面来考虑：一、首先得搞清楚二层打通的目的是什么？一般来讲二层打通的目的主要有以下几个：2.跨数据中心数据库集群（HA 或者 AA）对于 1、3 来讲，其实 SDN 技术本身有一个优势，就是通过隧道技术解决二层跨地域问题，也就是说通过 SDN 的隧道技术完全可以实现以上所述的几个功能。但是，有一点是需要注意的，就是如果数据库集群采用的是跨中心的 RAC，那么双中心之间的 RAC 心跳是非常重要的（一致性缓存块儿的传递、锁信息的传递），从稳定性、延时、带宽等各个方面需要一个全面的评估。二、从技术成熟性和复杂度来讲，我觉得二层打通技术更复杂，要求更高；SDN 技术从成熟度上来讲缺乏足够的实战场景来发现其中的一些 BUG，或许使用过程当中会面临很多意想不到 BUG 的困扰。综上所述，这个问题首先是要看整体技术架构，然后通过技术架构的优化来实现取长补短（比如说，我可以用 SDN 实现应用的漂移以及负载的平衡，但是数据库我可以采用主备模式降低风险，提高硬件配置降低复制带来的 RPO 风险等）。这个问题要分开来看：一、从技术发展趋势上看1.SDN 技术从 2022 年被提出已经经历了 10 多年的发展，技术逐渐成熟，用户量也再逐年上升，尤其在运营商层面；2.其核心就是一种数据平面与控制分离、软件可编程的新型网络体系架构，消除了顶层基础架构的兼容性限制，其实可以理解成为网络虚拟化的一种；3.对于运维人员只需要关注控制即可，转发层甚至是傻瓜交换机都可以。所以从技术角度看的确增加了数据中心的灵活性和弹性。二、从实际困难出发1.国内掌握 SDN 神髓的个人或者服务商不多，存在较高的技术壁垒；2.整体运维成本高，对运维人员的开技术要求过高；3.初期投入成本不低，需要各种设备的联调测试；4.场景化应用有待普及。所以对于成熟的数据中心更倾向于稳定，试错尽量放在测试环境或者非核心的小环境。多活数据中心都上了 sdn 用 v_lan 了，实现了二层网络在三层扩展，那二层打通的意义也不大了吧，IAAS层的飘移也可以通过 V_LAN 实现了。这时您的数据中心应该也不会有传统的集中式数据库了吧，HA高可用什么的也不会有了，分布式应用和分布式数据库都基本以这些为主了，那更没必要再引入大二层了，增加管理的复杂性。多数据中心情况下，SDN 网络是否要上大二层，笔者认为主要取决于应用场景。对于部分电信应用场景来说，大二层非常有必要，因为有些电信应用场景需要保持 IP 和 MAC 地址不变，而且要支持跨数据中心的迁移，在这种情况下没有大二层根本行不通。对于绝大部分互联网应用场景和金融应用场景来说，大二层没有必要，互联网应用有很多技术可以实现跨数据中心的流量分发和集群多活（如负载均衡+域名智能解析），服务器实例不需要在跨数据中心进行迁移。这种情况下，其实没必要上大二层。在多数据中心上大二层技术的好处是支持的场景更多，对于部分用户的应用来说不需要改造，上云更简单方便。但是对于建设和运维来说，肯定会更复杂，由于涉及多数据中心，多数据中心之间的大二层网络如何打通，这在业界也是一个难题。如果采用点对点 mesh 的方式，即多数据中心之间的虚拟网络直接互联，那虚拟网络节点的规模会成倍增加，这样给查表的速度和网络规格容量都带来很大压力。如果采用 L2 GW 的方式实现互通，那 L2 GW 的性能又会成为瓶颈，总体而言这些技术的复杂度要比非大二层高很多。同时，在日常运维中，大二层网络链路较长涉及多个数据中心，一旦出问题影响比较大（如如何避免二层广播风暴），运维复杂度也会增加，对运维人员的要求更高。综上而言，是否要上大二层取决于应用场景，如果应用场景没有强烈的需要，还是不上为好。如果要上，需要考虑随之带来的技术复杂度和运维压力，同时必要的一些技术坑还是得踩一踩才更有底气。第 13 页 共 13 页