@sambodhi
2016-11-16T09:12:20.000000Z
字数 7928
阅读 2405
作者:Franck Martin 译者:刘志勇
本文最初发布于Franck Martin的博客,经原作者授权由InfoQ中文站翻译并分享。
从2014年起,LinkedIn网站一直面向公众提供IPv6,他们的雇员已经用IPv6来冲浪很久了。在本系列的第一部分中,我们解释了为什么决定将公司内部网络升级到IPv6;在第二部分中,介绍了我们所面临的挑战,为了在一天的时间完全移除IPv4,我们在数据中心开始启用双栈。在最后一部分中,介绍了如何部署和管理纯IPv6网络上的服务器或者其他设备,以及从软件工程角度看待IPv6。我们还没有建好纯IPv6的数据中心,但这篇文章描述了纯IPv6数据中心的施工进展。
个人或者小团队可以手动安装、配置和管理有限数量的设备(如服务器、交换机,路由器等)。但是在任何大型网络中,由于涉及到成百上千个设备,变得更加复杂,您就会希望开始自动化执行这些功能。这是扩大基础设施的一个维度。随着团队的发展,越来越多的人在相同设备上做同样的工作,所以有必要确保知识传播、变化综述等的工具,这是另一维度的扩展。
在大规模部署时,有几个因素必须考虑,包括:
下面介绍了一些我们在IPv6环境中执行上述功能的能力缺陷。为了使讨论更加具体,这些主题,都是围绕我们体验过的软件,它们有已知的公开错误报告的参考文献。我们要感谢所有的合作伙伴和社区帮助解决这些差距。
当构建大型服务器网络时,其间通常会涉及多个不同的团队。数据中心技术人员敷设机架、电缆等设备,而网络和系统工程师配置并使它们在网络上运行。
您希望手动流程和接触点尽可能少:在理想情况下,您手动构建一个路由器和一个服务器,所有其他网络设备和服务器将从这两个设备自动安装和配置。这称为零接触配置(Zero Touch Provisioning,ZTP)。为了完全自动化,当设备上电时,它需要知道未被配置,在网络上查找其配置,然后安装自身。
在网络端,对于裸机交换机,有诸如开放网络安装环境(ONIE)的协议。在服务器端,有诸如Preboot eXecution Environment(PXE)之类的协议。这两种技术以类似的方式起作用。如果设备没有配置,它将获得一个IP地址(通常通过DHCP),然后通过DHCP选项使用TFTP下载一个小的内核映像文件(Image)或脚本,这个脚本用来通过复杂协议如HTTP以配置文件来执行检索更完善和更全的内核映像文件,然后可以进行设备安装和配置。此引导功能是硬件的一部分,位于主板和网卡的固件中。由于固件空间有限,TFTP客户端是优先的,因为它简单、微小。但是TFTP可能无法与今天的大型操作系统映像一道很好地工作,部分原因在于它使用UDP,与TCP不同,UDP不是为可靠性而设计。为此,首先加载小的内核映像文件,然后使用更完善但更复杂的协议,如HTTP,来下载较大的映像文件。
为了成功建立双栈环境,上面提到的IPv4进程需要在IPv6上执行同样的工作,甚至工作得更好。然而,向固件添加第二网络栈可能会超过固件的存储容量。要解决这个问题,传统的BIOS正在被UEFI(Unified Extensible Firmware Interface,统一的可扩展固件接口)取代,这是当下更好的框架。然而,UEFI相对较新,只有最近的版本才支持IPv6。在较旧或当前的设备刷入较新的固件是很复杂的事,会造成停机。事实上,它经常会使设备变砖。由于这个原因,理想的情况是,硬件已经内置支持UEFI和IPv6的新固件。因此,通过IPv6进行引导的功能,只能在内置了最新固件、开箱可用的新服务器上使用。
在纯IPv6网络中,UEFI网络引导只能使用autoconfig获取IPv6地址,而不能使用DHCPv6。如果你不控制服务器所使用的协议(在IPv4中,设备通过DHCP获取IP地址,基于集中式DHCP配置中设置的某些规则),可能需要更改配置架构。目前已发现一些TFTP客户端使用IPv6受到限制,仅能够访问本地或者IPv6内网(/64网络内)的文件,这意味着不能从不同的网络检索到映像文件,并且设备不能从全球的其他数据中心启动开机。
由于所有这些原因,在纯IPv6网络中,配置网络服务器(或网络设备)并非易事。用于选择正确的设备和网卡的选项是有限的。设备仍然可以通过IPv4进行配置,然后在纯IPv6环境中运行,但这涉及到运行多IP传输栈(Multiple IP Transport Stacks)。因此,当从双栈数据中心迁移到纯IPv6的数据中心时,确保设备在纯IPv6中可以配置非常重要。否则,IPv4网络必须保留以便可以重新安装设备。
我们目前正与供应商合作,在纯IPv6测试服务器配置。任何感兴趣的人,在一天内运行纯IPv6环境时,应与供应商一起检查,因为硬件生命周期至少为三年,并且可能希望在这段时间内迁移到纯IPv6环境中。
在超微(Supermicro)上使用新的网络固件,我们能够使用grub2通过IPv6进行UEFI网络启动。 这是我们的做法。
我们首先使用以下选项设置DHCPv6服务器:
option dhcp6.bootfile-url "tftp://[2001:DB8::245]/bootx64.efi";
我们在[2001:DB8 :: 245]上设置了TFTP和raddvd服务器。当通过IPv6引导时,UEFI网络引导接收DHCPv6选项并通过TFTP下载bootx64.efi并执行它。我们尝试通过IPv6在网络上加载Linux和initrd,使用带grub2.02-beta2的HTTP或TFTP;但是,下载无法执行。Grub需要在IPv6上进行更多的开发,以使其与在IPv4上具有相同的功能。
为了解决这个问题,所需的一切都被打包成一个memdisk,包含在bootx64.efi里;Grub2只需要链接这个映像文件(Linux + initrd)。
创建memdisk:
mkdir -p memdisk/boot/grub/x86_64-efi/
cp /usr/lib/grub/x86_64-efi/*.mod
memdisk/boot/grub/x86_64-efi/
cp /usr/lib/grub/x86_64-efi/*.o
memdisk/boot/grub/x86_64-efi/
cp /usr/lib/grub/x86_64-efi/*.lst
memdisk/boot/grub/x86_64-efi/
cp /usr/lib/grub/x86_64-efi/*.sh
memdisk/boot/grub/x86_64-efi/
cp /boot/vmlinuz memdisk/boot/
cp /boot/initrd.img memdisk/boot/
创建memdisk/boot/grub/grub.cfg:
set timeout=5
menuentry 'Linux diskless' --class os {
insmod all_video
set gfxpayload=keep
insmod net
insmod efinet
insmod tftp
insmod http
insmod gzio
insmod part_gpt
insmod efi_gop
insmod efi_uga
insmod ext2
# dhcp, tftp server in my network
set net_default_server=2001:DB8::245
# auto dhcp setup did not work for me, no idea why
# net_bootp
# ok let's assign a static address for now
net_ipv6_autoconf
echo 'Network status: '
net_ls_cards
net_ls_addr
net_ls_routes
echo 'Loading Linux ...'
linux /boot/vmlinuz rd_NO_LUKS rd_NO_LVM rd_NO_MD rd_NO_DM ramdisk_size=100000 rdblacklist=qla2xxx ksdevice=bootif lang= text ip=dhcp6 ks=http://[2001:DB8::245]/repo/cfg/KS1.cfg
echo 'Loading initial ramdisk ...'
initrd /boot/initrd.img
然后打包:
cd memdisk
tar cf memdisk.tar *
创建映像文件:
# grub2-mkimage --directory '/usr/lib/grub/x86_64-efi' --prefix '(memdisk)/boot/grub' --output 'bootx64.efi' --format 'x86_64-efi' --compression 'auto' --memdisk 'memdisk/memdisk.tar' 'memdisk' 'tar'
bootx86.efi映像文件相对较大,在我们的示例中大约为42M,主要是因为我们的initrd.img就这么大。毋庸置言,TFTP并非下载大文件的最佳工具,因为它依赖UDP而非TCP(TCP内置更多的纠错机制)。虽然根据UEFI规范应该是可能的,但是我们还没有成功地将HTTP用于UEFI通过IPv6的网络引导。到目前为止,这个工作正常——TFTP是一个可行的解决方案。
在此配置中,UEFI将下载映像,chainload到memdisk中的vmlinuz(无需使用Grub从网络中单独下载),并且此内核将与kickstart服务器联系并开始配置服务器。
虽然许多负载平衡器支持IPv6,但我们为了提高可扩展性,采用了与可用选项不同的方法。我们通过在本地接口上添加IP在服务器上配置VIPs,通过BGP会话使用bird和bird6向连接的交换机通告这些IP。因为这是内部网络,我们可以选择通告网络的聚合级别:对于IPv4为/24,对于IPv6为/128。但是,您需要非常小心,因为一些网络设备可能不能容纳超过/128前缀的128个路由,因此它可能是一个更好的策略,保留一个完整的/64甚至一个IPv6地址用作任播。通过消除服务器与负载均衡器在同一网段中的要求,就赋予我们更大的灵活性。
我们使用CFEngine配置虚拟IP任播,我们不得不修改一些RedHat的网络脚本,使配置在IPv4和IPv6上类似。这在CFEngine一节中有描述。
IPMI(Intelligent Platform Management Interface,智能平台管理接口)是非常重要的部分,它能够在出现显著影响之前检测硬件问题,或者在操作系统关闭时也能够查询机器状态。
IPMI是在不安装操作系统的情况下访问服务器的标准。它允许管理员在服务器启动时远程控制和查看屏幕,例如,当服务器启动时,监测各种硬件组件(如硬盘驱动器)的运行状况。该接入可以是“带外(out of band)”或“边带(side band)”。“带外”意味着为该管理保留一个接口,并且处于其所在的网络中。在“边带”设计中,相同的物理接口用于单独网络中的正常网络流量和管理。
由于管理可能在安装任何操作系统之前发生,因此IPMI必须能够在纯IPv6网络上自动配置。稍后,一旦安装了操作系统,服务器上的ipmitools将允许用户查询和设置硬件组件。
从2015年5月发行的版本1.8.14起,Linux上的Ipmitool支持IPv6。然而,它仍然需要找到一些Linux发行版。例如RedHat 7中还没有正确的版本,因此我们需要创建自己的版本。
此外,您需要一个具有适当固件的网卡来支持IPMI IPv6扩展。这样的网卡也可能能够通过IPv6进行UEFI和PXE。我们一直与供应商测试分布式管理任务组(Distributed Management Task Force)指定的Redfish兼容固件。
对于长期支持,管理员可能必须将当前运行的Linux版本更新为支持的完整IPv6支持版本; 这可能有下游影响,更不用说刷固件的困难。
管理服务器的另一方面是能够配置它们。有很多工具可用:Chef、Puppet、Foreman等。我们使用CFEngine。虽然CFEngine通过IPv6工作,但若尚未配置IPV6时,该软件内置了支持IPv4的功能。我们创建了一个CFEngine模块,它将从主机收集IPv6信息,并允许将其提供给我们想要的任何CFEngine序列。该模块为我们节省了大量的时间来配置IPv6服务器,设置网络接口,创建正确的iptables,使用IPv6支持更新软件配置文件等。
我们使用的自动化方法很大程度上依赖于Linux虚拟接口。这需要我们在Linux上修补网络脚本,使其可以由CFE管理。难点在于接口上的其他IP地址。对于IPv4,是通过配置的虚拟接口处理;而对于IPv6,这只是一个包含所有附加IP的变量。我们的补丁允许在IPv6中使用虚拟接口。我们对RedHat的修改进行了考虑。
CFE的IPv6支持的跟踪在这里,在支持问题中描述微小错误。CFE开发人员报告说,该软件在纯IPv6环境中工作。对我们来说,它在双栈环境下工作良好,我们看到IPv6流量,但我们还没有验证它确实在纯IPv6环境下工作。我们一直与CFE开发人员密切合作,提供对我们的经验反馈,他们非常热烈——其中一些反馈将很快应用到未来版本,所以如果我们发现任何问题,相信他们将及时处理。
其他配置系统对IPv6具有各种级别的支持。重要的是在现实环境中测试它们并提供反馈,使每个系统总是持续改进。
多年来,我们已经建立了自己的监控和警报服务,称为inGraphs和AutoAlerts,可以参考此处来了解。
此软件为各种收集器提供了从服务器、网络设备、应用程序或服务获取指标并将此信息以图形化呈现。如果数据不符合预期(硬盘驱动器已满、CPU使用率、接口上流量过多、对服务的请求过多等),此过程也可能生成警报。 我们监控每个设备的许多指标,以便我们在以每天和每周为周期来了解趋势,而且,当情况变槽之前及时通知我们。这些指标还可用于事后分析。
inGraphs和AutoAlerts只是一个框架,用于我们部署脚本,探测有助于衡量运营和服务之间的差异,无论是在IPv4或IPv6。任何组织都会这样做,并在自己的监视系统中构建新的图形化警报,以便在服务期间,根据协议栈不同表现进行通知。
当我们从纯IPv4转换到双栈环境,最终转向纯IPv6时,我们需要有指标标准,以便我们能够了解服务在IPv4和IPv6上是否正常运行。我们是否能够观察到延迟,每秒查询等方面的差异吗?虽然我们可能不会对产品本身进行更改,但这意味着具有收集检查IPv4和IPv6性能所需的数据的工具和工具。例如,我们发现一些网络设备可能提供IP、ICMP、TCP或UDP的流量故障,但它们不告诉我们IPv4和IPv6流量之间的分割。这是一个非常重要的度量标准,用于衡量进度及成功的指标,且当移除IPv4时至关重要。
像LinkedIn这样的大公司不进行测量许多指标,就不能迁移到IPv6,测量指标可以了解发现的问题是否是由于实施IPv4和IPv6之间的差异。有时变化并不显著,有时它们在百分比方面非常小,但仍然很重要,例如4亿成员的0.1%仍然是40万成员。
最终你需要停运机器。这需要从操作中删除它们,擦除数据,从网络中删除它们,最后解开它们。在纯IPv6环境中,软件需要能够在纯IPv6网络上执行这些操作。
早日规划如何停运,并同时仍然保证机器的供应,将在未来给您带来帮助。这是我们在IPv4上实施的,正在寻找如何在纯IPv6环境中执行的方案。
有许多软件需要支持IPv6。 在许多组织中大量部署的设备和软件可以与Hadoop网格的部署相关。我们将以Hadoop为例(因为这通常涉及在许多组织中大量部署设备),但是还要考虑其他软件和策略。
许多大公司必须存储和分析大数据。今天使用的常用系统之一是Hadoop。这通常需要大量的服务器来进行数据存储和计算。目前Hadoop不支持IPv6。社区已经创建了一个开发分支,以获得IPv6支持,一旦这个分支测试完毕,它将被合并回主分支。这是Hadoop社区在添加新功能时惯用的工作方式。它为功能和主要分支提供了一个安全的开发环境。
Facebook工程师一直在努力为Hadoop添加IPv6支持,我们正在研究如何参与这项工作。该项目进展顺利。这是所有参与Hadoop项目最棒的工作,但不用说,像所有开源项目一样,我们相信社区总是欢迎更多的帮助。
一旦Hadoop支持IPV6,我们就可以轻松地在许多组织中部署大型的纯IPv6机器,为每个组织节省数百万个IPv4地址。
我们期待能够测试支持IPv6的Hadoop,并报告和帮助修复我们发现的bug。
许多工具和软件需要修改以便处理IPv6及其数据结构。对于常规套接字连接,有几个策略要考虑。默认情况下,操作系统将返回主机名(IPv4或IPv6)的首选IP地址。当设备在其一个接口上具有全局IPv6地址时,此首选项通常为IPv6。但是,可以为了始终优先使用IPv4而更改此首选项。另一个策略是获取主机名的所有地址,并以不同于操作系统的方式在软件中处理它们。例如,Java有几个标志设置,以便您可以通过IPv6启用连接。更多的示例,您可以在这里找到一个关于Python和sockets的优秀教程。
这只是一个例子,说明还有一些软件还没有准备好应用于IPv6。在操作系统中禁用IPv6仍然是此软件中针对IPv6支持的任何问题的常见解决方案! 很可惜,因为这样无助于解决真正的问题。
在某些情况下,可以依赖外部第三方的任务,而不是固定所需的软件以使用IPv6,您可以在其周围提供包装器或代理。例如,Apache在代理模式或Nginx都已广泛用作IPv6前端到纯IPv4的后端。这是很多已经提供IPv6连接的网站。这也可以用于内部站点,使人们更熟悉IPv6并在内部增加IPv6流量,从而增加可见性,以便人们知道为IPv4编程不再是唯一选择。
ARIN(The American Registry for Internet Numbers,美国互联网号码注册管理机构)已经发布了如何确保开发人员制定网络无关代码的相关文档。
路漫漫其修远兮,我们正处在完全支持所有设备和软件的前沿。不再有不受IPv6影响的任何领域,也不再是只有少数人才认识到它的重要性。
迁移所有的软件通过IPv6连接,是我们接下来几个月的任务。我们还将在提供设备的方式上继续工作,一旦完成,就是开始处理IPv4的时间。
在这一部分中,我们要感谢一些提供帮助的外部人员。还有很多人我们需要感谢,如果我们遗漏或者忘记姓名,请接收我们的道歉:Fred Baker、John Brzozowski、Vint Cerf、Lorenzo Colitti、Jason Fesler、Lee Howard、Pradeep Kathail、Martin Levy、Christopher Morikang、Paul Saab、Mark Townsley、Eric Vyncke、Dan Wing、Jan Zorz。