Uber如何在生产环境中部署IPv6_语言 & 开发_JEAN HE

Python 还能承担下一个时代的发展重任吗？Mojo 语言的横空出世对 AI 研发生态有什么影响？了解详情 



 写点什么

自 2009 年 3 月上线至今，Uber 一直坚持自己的使命，致力于让每个人随时随地享受可靠的交通服务。时间已经到了 2017 年，但我们的使命依然未变。

2014 年初，Uber 已落地 100 个城市；2016 年初，Uber 已经遍及全球超过 400 个城市，不仅提供驾乘，还提供了其他类型的交通运输服务。与此同时，2015 年新年前夜，我们达成了 10 亿次行程的里程碑，并很快于 2016 年 6 月达成 20 亿次行程。随着我们将服务扩展至更多城市，这个数字还会继续飞速攀升，我们也会继续以可靠的交通服务服务于全球用户。然而为了继续提高 Uber 服务的覆盖面，我们需要确保工作能够顺利应对 IP 协议方面遇到的一些挑战。

(点击放大图像)

图1：Uber 已经落地全球六大洲数百个城市，地图上每个蓝点对应的城市都有我们的服务

Uber 目前的基础架构建于 Internet 协议版本 4 （IPv4）地址标准的基础之上，包含多个数据中心，使用了少量网络入网点（POP）和云服务。然而Uber 的成长速度远远超出了IPv4 的承载能力，为了更好地支持业务扩展，我们的基础架构需要跟上用户增速的步伐，必须使用下一代IP： Internet 协议版本 6 （IPv6）。

2016 年，Uber 开始推行 IPv6 数据中心架构，通过对现有基础架构进行调整来促进业务的扩展。本文中，我们将介绍为适应 Uber 工程任务的成长，我们在设计这一全新网络的过程中获得的最佳实践，以及通过对基础架构进行更新以支持 IPv6 过程中，我们学到的经验。

从 IPv4 到 IPv6 的奋力一跃

根据互联网协会（ISOC）的介绍，IPv4 总共43 亿个地址已于2011 年2 月全部耗尽。IPv4 地址总数超过40 亿个，远远比不上全球移动设备总数。再考虑到物联网（IoT）设备的飞速增长等因素，我们很快将发现自己开始面临IP 地址“饥荒”。

2011 年，全球五大区域性互联网管理机构（RIR）中的三家，包括亚太网络信息中心（APNIC）、 Réseaux IP Européens （RIPE），以及拉丁美洲和加勒比网络信息中心（LACNIC）已彻底分配完了自己所有可用IPv4 地址。 2015 年 9 月 24 日，美国互联网号码注册机构（ARIN）也宣布自己的全部IPv4 地址已耗尽。

早在1996 年就已制定的 Internet 协议版本 6 （IPv6）是目前最新版的 Internet Protocol（IP）地址标准，提供了大量可解决 IPv4 所面临诸多弊端的功能，如更大的地址空间、一种多播基础规范，以及无状态地址自动配置（SLAAC）。IPv6 可容纳超过340 涧（Undecillion，10 的36 次方）个地址，这一数量已经远远超过目前全球所有用户，当然也包括Uber 自己对IP 地址的需求。

(点击放大图像)

图2：上图展示了目前全球范围内各国的IPv6 部署情况（来自APNIC）

APNIC 制作的一个地图（见上图）显示了全球不同国家目前的IPv6 部署，很多国家目前的部署依然为零，而比利时已经超过了56%。互联网协会在2011 年进行的全球IPv6 使用情况调查发现，自从2012 年起，全球主要ISP 运营商，尤其是美国的运营商在部署IPv6 方面开始加快步伐。北美运营商目前的IPv6 部署范围从27.93%（ Cox Communications ）到 84.36%（ Verizon Wireless ）各异。

调查还发现，整个互联网上的 IPv6 流量正在稳步增加，然而依然远低于 IPv4 流量。更重要的是，2017 年 4 月， Google 称 Google 用户中使用 IPv6 的比例已达 16%，依然使用 IPv4 的比例为 84%；类似的，Web 信息公司 Alexa 称截止 2017 年 3 月 8 日，全球排名前 1000 位的网站中，只有不到 20% 的用户在使用 IPv6。

专为 2014 年美国计算机协会大会撰写的 Measuring IPv6 Adoption 一文预测说：“到 2019 年，已分配的 IPv6 前缀数量将约为 IPv4 的.25-.50，而届时 IPv6 与 IPv4 流量的比例约介于.03 到 5.0 之间。换句话说，IPv6 流量依然只在总流量中占据很小的零头。”这些结论建议，按照目前的增速，全球对 IPv6 的接受速度过慢，已无法适应整个世界对网络连接快速增长的需求。

Uber 的 IPv6 部署

目前 Uber 运维着数万台服务器，整个网络共承载了超过 800 万个 IPv4 地址。

2014 年之前，Uber 的数据中心托管在第三方。为满足我们对容量的需求并为用户提供更可靠的服务，我们在 2014 年建立了自己的首个北美数据中心。2015 年，Uber 对北美数据中心进行了扩展，在美国东西海岸建立了更多数据中心；2016 年，Uber 建立了几个网络 POP 点，并将其扩展至云中。随着 2017 年来用户数量持续激增，IPv6 部署已开始成为我们后续扩展过程中的关键一环。

对我们来说，为了维持大规模架构的可靠性，在整个网络中部署 IPv6 主要有三个原因：

更“慷慨”的 IP 分配：过去几年来，我们的网络规模增速飞快，数据中心内服务器机架数已达数千个。我们会从自己的 Request for Comment (RFC) 1918 IP 空间内为每个机架分配一个 /24 IP 子网，而目前机架中仅剩 48 台服务器。
资源局限：增长到目前这样的规模后，我们现有的 10.0.0.0/8 IPv4 子网中已经有超过 50% 的地址被用于内部用途。如果不过渡至 IPv6，我们的 RFC1918 （互联网工程任务组（IETF）有关私有 IP 地址分配方式的备忘录）地址空间很快就会耗尽。
IP 地址重叠：按照传统，Uber 的网络中为自己的资源定义了自己的 IP 地址。当 Uber 开始与其他公司合并时，不同机构的两个内部网络中会出现一些重叠的 IPv4 地址。

经过全面研究、测量以及其他分析后，我们意识到为了支持 IPv6 部署，我们的基础架构还有三大领域需要进行更新：

网络架构
软件支持
供应商支持

首先，我们将介绍 Uber 数据中心网络中上述三方面内容的构成，随后将介绍如何面向 IPv6 的部署做准备。

网络架构

Uber 的网络架构包含三个主要部分：

硬件

Uber 使用了统一且一致的硬件，这样可以更容易地实现模块化、可伸缩的数据中心设计。每个设备通常会使用相同型号的硬件，因此可以很容易地根据需求进行伸缩。我们的网络设备可支持通过 100G/50G/25G 以太网下行链路连接至服务器。

自动化

以 Uber 的系统规模来说，网络的构建、管理和运维必须使用自动化工具。我们的网络数据中心可使用零接触供应工具自动构建，日常网络管理工作中可通过内部开发的自动化工具管理网络配置和 IP 地址，此外如果哪里出现问题，智能监视工具可以向我们发出通知。

网络设计

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

(点击放大图像)

图3：Uber 网络拓扑的高层次视图，其中包含多个连接至同一边缘骨干网络的集群

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

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

(点击放大图像)

图 4：使用 1:1 无闭锁网络模型的 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\0”问题而无法存储 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 部署：2017 年和将来

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

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

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