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地址.

Uber的基础架构使用haproxy在不同地区进行路由.我们广泛使用诸如haproxy.cfg yaml等配置(config)文件将不同IPv4地址与对应的主机名存储在一起.所有服务的配置文件也需要仔细检查,并根据不同用途进行更新,以便在为所有主机启用IPv6后支持IPv6地址.

我们并未使用硬编码的方式指定IPv4地址,而是在代码中使用主机名,随后通过DNS解决过渡期遇到的问题.目前我们正在对开发者进行培训,告诉他们如何使用诸如getaddrinfo(3)等IPv6相关支持工具促进整个过渡进程.

供应商支持

大型网络设备和服务器硬件供应商多年来一直在积极地为IPv6提供着支持,并且已经顺利实现了大量IPv6特性.然而考虑到生产环境中使用IPv6的历史并不长,并且大家普遍缺乏相关运维经验,随着越来越多的组织开始在生产环境中部署IPv6,大家陆续发现了很多bug.IPv6的质量保证(QA)需要努力与IPv4看齐.

随着越来越多的组织将服务部署在云端,Amazon AWS、Google GCP,以及Microsoft Azure等云供应商也加快了对IPv6的支持步伐.

Uber的IPv6部署：现在和未来

Uber目前正在以设计文档,包括IPv6寻址机制和特性RFC为指导,对IPv6部署进行实验室测试.在全面将IPv6部署到生产环境之前,为了发现任何可能存在的问题,还需要在准备环境中进行深入的负载测试.

我们预计可以通过全面部署IPv6立刻获得下列收益(包括但不限于)：

• 前端：前端将可以直接为原生IPv6流量提供服务.
• 组织合并：面对相互重叠的IPv4地址,IPv6为我们提供了更具伸缩性的解决方案.
• 车辆上下客：目前,Uber为自有车辆提供的车载设备底座会被解析至一个/24 IPv4子网.当前的这种设计是为了预留IPv4资源同时确保不同工程项目一致的配置.然而IPv6可以通过设备底座为车辆上下客网络架构提供一种更具伸缩性的解决方案.然而需要注意,仅在用户的iOS或Android软件能够支持的情况下才可以在上下客网络中使用IPv6.行动呼吁：迎接IPv6

（编辑：核心网）

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