Uber是如何在生产环境中部署IPv6的？

我们数据中心的设计符合IETF RFC 7938所定义的Clos设计,“在大规模数据中心内部使用BGP进行路由”,该设计方式决定了我们需要使用边界网关协议(BGP)作为动态路由协议.按照网络架构,我们使用了对分(Bisectional)带宽,可快速收敛(Convergence)并且故障域很少.此外我们还通过构建网络过程中使用的功能集实现了不同供应商产品的互操作性,如下所示：

在Clos设计的基础上,我们将整个数据中心划分为模块化的Pod和集群.每个Pod包含相同数量的服务器机架,每个集群包含多个服务器Pod.因此整个网络可拆分为多个小规模但完全一致的单元,所有Pod之间统一使用高性能网络进行互联.Uber的数据中心包含多个集群,所有集群连接至我们的边缘骨干网络,进而连接至互联网.

为了向Uber的网络提供足够的带宽,包括向Hadoop等主要的内部“东西”流量提供支持,我们的集群架构使用了一种1:1无闭锁(Unblocking)网络模型,例如下图展示了我们设施内部的IPv4网络架构：

为了在维持冗余的同时尽可能让每个网络层实现最大化的带宽共享,随后我们还在网络设计中引入了一种Fabric plane的概念.另外,1:1的无闭锁超额开通(Oversubscription)率意味着任何服务器主机均可在维持自己端到端上行带宽的同时与这个IP设施网络内的其他任何主机通信.

为了在这种网络架构中部署IPv6,我们为每个服务器机架和集群指定了要分配的IPv6地址,其中服务器机架会被分配一个/64 IPv6子网,集群会分配并汇聚至子网/n,其中n<64.这些子网会通过一个/32全局唯一IPv6地址块获得地址,这个地址块是由区域性互联网管理机构(RIR)分配给我们的,仅限内部网络使用.IPv6的分配和管理工作使用了上文提到的自动化过程.

由于我们的数据中心网络是模块化的,使用了模板化的配置,并且我们的Clos设计自上至下只使用了一种协议：外部边界网关协议(eBGP),相比在从IPv4迁移至IPv6过程中需要重新配置协议的网络设计,我们可以快速简单地为所有机架分配原生IPv6地址.我们数据中心集群的每个组件,例如机架子网、Pod子网、环回、带外(Out-of-band)子网,以及点对点子网均使用了相同的IPv6分配过程.这些自动化的IPv6地址生成工具使用了与我们的IPv4地址分配架构类似的逻辑.

最后,我们的骨干网络所用的诸如BGP和IS-IS等路由协议可以很轻松地通过更新支持IPv6,在运维方面不会产生太多额外的工作量.

软件支持

为了顺利部署IPv6,还需要对整个网络对软件的支持情况进行更新,尤其是可提升IPv6流量的软件更是需要重点处理.为软件实现IPv6的支持需要不同团队通力协作,涉及到Uber的多个团队,包括安全工程团队和站点可靠性工程团队.

一些工程师所接受的培训只介绍过如何编写仅支持IPv4的代码,因此他们针对IPv6兼容性开发的应用程序和工具也能支持IPv4.IPv4和IPv6地址无论地址长度、前缀,以及表现形式等方面都有很大差异,例如在从纯IPv4代码迁移至可支持IPv6代码的过程中,我们遇到了一些常见的应用程序问题,包括：

• 代码将前缀长度设置为常见的IPv4前缀,例如/24,无法适应IPv6前缀的长度.
• 会将“a.b.c.d”拆分为”(“a”、“b”、“c”、“d”)元组(Tuple)的代码将无法识别IPv6地址,因为拆分是以分号“:”而非句号“.”为依据的.
• 需要将“主机：端口号”,例如“a.b.c.d:8080”拆分为“a.b.c.d”,“80”的代码遇到“[2002:a:b:c::ff]:8080”之后会出错.同理,需要将“a.b.c.d”,“80”组合为“a.b.c.d:8080”的代码遇到“2002:a:b:c::ff:8080”会创建出无效的IPv6地址.
• 使用regex匹配IPv4地址的代码在收到IPv6地址后会给出无效的结果.
• 通过硬编码方式指定尺寸的列将IPv4地址存储为“varchar(16)”的数据库,会由于“a.b.c.d”问题而无法存储IPv6地址.

（编辑：网站开发网_盐城站长网 ）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!