数据中心网络的自动部署新方案

By 罗枫@云启科技

摘要:本文立足数据中心的行业背景、特点,提出一套简单高效的自动部署方案-ATP(Auto Provisioning),该方案已经在业界一流数据中心机房里进行了大规模的实践。

引言

在数据中心领域,网络设备的上线和部署一直是备受关注的一大问题,规模越大,交付效率的影响越大。在规模较小或数据中心早期阶段,网络设备初建或故障整机替换环节主要依靠人工参与,效率低下。鉴于此,不少网络设备厂商提出Zero-ouch Provisioning解决方案,试图做到自动化上线和完成配置获取及加载。

但由于网络设备的行业封闭性,网络设备的上线和部署缺乏标准,难以有统一有效的方案。而且,目前业界的方案依然未能完全摆脱人工干预,只是相比传统方案,将原本在现场由人工完成的工作进行了一定程度的转嫁和转移。

名词解释

  • ATP:Auto Provisioning,自动部署技术,对标ZTP,Zero-touch Provisioning
  • LLDP:Link Layer Discovery Protocol,链路层发现协议,一个与厂商无关的二层协议,允许网络设备在本地子网中通告自己的设备标识和性能。
  • TOR:Top Of Rack,架顶交换机,也称接入交换机,用来直连服务器。
  • Core Switch:核心交换机,对于扁平化的二层架构中,核心交换机直连TOR。

应用场景

本文的技术方案适用于spine-leaf网络架构,致力于提供如下问题的解决方案:

  • 首次上线,空配置状态下自动获取和加载配置;
  • 整机替换,整机替换时自动获取和加载历史最新配置;
  • 容错性,健全的重试机制;

有了NZTP方案,传统网络上线时的按照指定机架位上线设备以及手动配置管理IP的工作全部可以节省掉。效率能得到极大提升。

当前现状

  • 手工部署

对于规模不大的数据中心网络而言,手工部署方式应该是最主要的方式。对于网络建设而言,从设备进机房的上架加电、现场配置网络到远程导入配置文件,都是需要人工参与的。这种方式的典型特点是效率低,严重依赖于参与现场实施的人员的专业技术熟练程度。

  • 自动部署

对于规模较大的数据中心网络,处于对交付效率的追求,会从手工部署往自动部署层面转换。根据对厂商依赖程度的不同,又分为两类,一类是客户主导型,主要依靠周期探测网络后推送配置;另一类是厂商主导型,主要依靠厂商制定的策略,做好相应的环境配置即可工作。两种方式都不够简洁高效。

设计理念

  • 充分利用现有网络资源和环境,不额外提升复杂度

    当前大规模数据中心场景下的网络架构主要采用的Spine-leaf两层结构,Spine交换机主要依靠商用厂家的大型Chassis方案。对于此类Chassis交换机,由于使用数量较少且属于核心基础网络设施,一般都采用手动部署和配置方式。在完成spine层交换机配置的过程中,相关网络配置环境会准备就绪。ATP会充分挖掘当前在对chassis做手工配置过程中的一些资源和条件,将ATP方案依赖的元素在不增加额外复杂性的前提下与传统Chassis交换机的建设流程进行融合。

  • 系统化工程化的观点看待问题,释放设备潜力

    网络设备的自动部署是一个系统工程问题,要从网络架构、设备OS和网络安装环境一起联合考虑,合理分散精力才能获得最大的收益。因此本文提供的ATP方案,是一个开放技术规范,需要从设备商到用户的良好配合才能发挥价值。

  • 开放与兼容性

    ATP方案在流程设计之初就考虑到要解决跨厂商设备替换的问题,通过对技术规范的指定和开放,实现数据中心网络统一的部署方案。

核心设计

对于网络自动部署而言,要解决的最核心问题是,如何标识设备的位置信息,因为设备实际在机房所处的位置就对应了在网络拓扑规划中什么样的配置。其次是如何设计一套获取到配置的合理高效的流程。

  • 策略重构:网络部署基本属性的传递

    在数据中心中,网络设备所处的位置决定了其对应的网络配置。只有清楚了自己的位置信息,才能映射到准确的网络配置。传统方式中比较经典的一种做法是,基于MAC地址来标识一台设备,通过建立MAC地址和配置文件之间的映射关系来达到自动下发配置的目的,但这种做法要求TOR交付时必须反馈MAC和机架位的对应关系。这是一种从设备层面看待问题的角度,对于做网络规划和建设的人员来讲,更愿意看到的是网络拓扑和机架位层面。从网络建设和运维的角度出发,网络层面是否有一些属性可以标识或携带位置信息呢?答案是肯定的,而且是过去一直在使用,那就是核心交换机的端口描述。核心交换机互连TOR的端口描述上会指明对端设备的一些信息,比如TO-NMG-NMG01A341-B-D2020-16.Int-AE1,从这个例子里,可以看到TOR的hostname和TOR互连的接口。与MAC地址一样,hostname也是可以唯一标识一台设备的,但是和MAC地址不同的是,hostname是没有和具体的设备绑定的,只有在设备上架后才和具体设备建立映射关系,因此,只要TOR能感知到该hostname,那么这台TOR的身份也就明确了。那么如何来传递这个信息呢?可以利用LLDP协议,TOR和CORE之间可以互相交换设备信息。发散一下,可以更通用,将设备IP、服务器IP地址通过LLDP协议从chassis往下进行传递。LLDP协议这个本身已经在网络中得到成熟广泛部署的协议,而且无需新增其他工作量就能将网络身份信息进行传递。

  • 流程优化:自动部署流程的优化

    基于上述策略,可以将设备和服务器的IP地址等都以端口描述的行为通过LLDP协议进行传递。

    设备上的ATP业务模块实现对设备IP地址、配置服务器IP地址、配置文件名以及堆叠成员号等信息的解析和获取。 有了上述基本信息后,ATP业务就可以实现对网络的自配置、获取配置文件并加载配置文件了。无须再依赖带option扩展的dhcp服务。

方案要点

生命周期

ATP流程只在设备以空配置启动后到设备获取配置文件并加载成功之后的时间段内运行。一旦设备上存在上电启动配置,ATP就不会再执行,若要再次触发其执行,需要手动将配置文件清除掉并重启设备。

这里对两种配置文件的概念做一下简单介绍:

  • 缺省配置:系统空配置时对应的配置,要么以运行时内存数据存在,要么以文件形式直接存在。
  • 启动配置:相比缺省配置,系统启动后所做的任何修改并保存到disk里的配置,以文件形式存在。

因此,对于出厂设备而言,ATP任务是缺省启动的,但是ATP是默默在后台工作,不影响用户首次登陆,也不会直接在串口上进行信息回显。

网络基本属性描述规范

对于网络自动部署和上线来讲,网络的基本属性包括如下几点:

  • 设备自身IP;
  • 配置服务器IP;
  • 待加载的配置文件的名字;
  • 是否有堆叠;

端口扩展描述规范

根据上一节的内容,ATP采用的是LLDP策略来进行网络属性信息的传递。在该策略下,一个端口的描述信息将被增加一段扩展描述。端口扩展描述规范如下:

  • 原有端口描述@设备IP@服务器IP第4个字节缩写
  • 原有端口描述@设备IP@服务器IP第4个字节缩写@堆叠成员ID 举例如下:
端口描述 含义
[email protected]@11 设备IP:192.168.70.100 服务器IP:192.168.70.11
[email protected]@11@1 设备IP:192.168.70.100 服务器IP:192.168.70.11 堆叠成员号:1

配置文件命名规范

配置文件命名规范如下:

设备IP_厂商.cfg举例如下:

配置文件 含义
192.168.1.70_yunqi.cfg 适用于云启设备且网络规划地址为192.168.1.70的设备配置文件
192.168.1.70_h3c.cfg 适用于云启设备且网络规划地址为192.168.1.70的设备配置文件

端口状态机模型

ATP定义了如下几种状态:

  • INIT,表示ATP流程启动并完成基本初始化,初始状态;
  • DESC_COLLECTING,表示通过LLDP获取对端端口描述;
  • DESC_RCVD, 表示获取到端口描述;
  • DESC_VALID,表示端口描述合法性检查通过;
  • NETWORK_VALID,表示网络连通性正常;
  • TFTP_FIN,表示TFTP请求配置文件成功;

各种状态之间的变迁图如下图所示: 该状态机是基于端口的,亦即每个端口维护自己独立的状态机。

堆叠支持

ATP除了能支持underlay网络的自动部署外,也可以支持overlay网络的配置加载。如果ATP能识别到正确合法的堆叠成员号,那这个编号会被ATP自动下发到设备,设备将被切换为堆叠工作模式进行运行。

实时的ATP状态

ATP流程中任何一个状态出错都要有明确的记录,并且该记录要在没有做手工配置syslog远程推送的条件下对外进行发送。这里就需要借用端口扩展描述中的第二个@部分的内容,将ATP流程产生的所有行为向指定的服务器进行推送。这样方便远程分析和诊断ATP的行为。

良好的容错性

ATP的容错性体现在两个层面:一是在ATP条件不具备时ATP会一直轮询指导能完成ATP状态机流程;二是在正常执行ATP状态机过程中,能对配置文件进行语法和语义层面的检查。如果检测到配置文件的语法或语义有任何错误的时候,ATP会备份并删除该文件,以缺省配置启动,然后继续NZTP的流程,直到配置文件里的错误被修正。有了这个容错性的保障后,ATP的自动部署就不用担心批量准备的配置文件有误而导致全部需要现场把设备恢复到出厂设置。

规范的日志记录

网络设备的syslog日志,在网络监控中占据非常重要的作用,ATP如果要成为一个规范,定义syslog日志规范的必要性尤为重要。

状态变迁syslog

状态变迁时的syslog格式为:

ATP on xxx,changed state from STATE1 to STATE2其中,xxx为携带ATP流程所需信息的端口。STATE1和STATE2为ATP状态机中的定义的状态。

例如,在TOR的te-1\/1\/33口上能够收到用于ATP相关信息,则至少应有如下的打印信息:

ATP on te-1/1/33,changed state from INIT to DESC_COLLECTING

ATP on te-1/1/33,changed state from DESC_COLLECTING to DESC_RCVD

ATP on te-1/1/33,changed state from DESC_RCVD to DESC_VALID

ATP on te-1/1/33,changed state from DESC_VALID to NETWORK_VALID

ATP on te-1/1/33,changed state from NETWORK_VALID to TFTP_FIN

异常处理syslog

在ATP流程中如果出现一些异常情况,仅依靠状态机的变迁日志无法进行准确的过程跟踪。因此对于出现的若干异常事件,需要进行特定的日志输出。常见的异常事件有如下几类:扩展信息不完备、扩展信息出现语法错误、网络异常。

部署规范

端口扩展描述添加规范

Chassis交换机和TOR交换机可能存在多条互连的链路,端口扩展描述只允许出现在互连的其中一条链路上。对于采用LAG链路互连的情况,只挑选LAG中的一个成员端口进行扩展位置信息配置即。

跨厂商混合部署机制

ATP在INIT初始化阶段,提取自身的vendor特性,然后根据DESC_VALID阶段中提取出来的设备IP,产生完整的配置文件名字。当设备跨厂商之间进行替换时,可以无缝进行切换。前提条件是事先将不同厂商的配置文件都准备好。

ATP使用checklist

按照ATP的设计理念,只要准备工作齐全,一定能正常工作,如果没有正常工作,一定是哪个环节出现了异常。日常使用中,可以参照如下checklist来进行排查:

1. 端口扩展描述里的信息是否准确;

2. 配置服务器上的配置文件和端口扩展描述里的信息是否匹配;

3. Core Switch上是否开启了LLDP。

延伸一:与SDN控制器的对接

网络的自动部署最糟糕的情况是设备没有被正常部署但网络又连不上,这样只能现场人工逐台排查和除错。在ATP方案里,syslog会自动将ATP的实时状态往服务器发送,这样SDN控制器可以搜集该日志进行统一的分析,增加自动化和智能化水平。

延伸二:业界支持和实现程度

ATP方案是目前数据中心领域里最简单最高效的自动上线部署方案。该方案的技术实现和理念都是完全对外开放的,已经有华为、锐捷、博科等品牌厂商率先实现了特定版本上的支持和发布。

延伸三:系统联动

由于线上网络有可能发生变更和调整,因此网络配置文件也需要周期性进行备份。周期性备份的配置文件可能以如下的格式进行存储:机房IP_192.168.x.x时间戳.cfg。而ATP在执行下载配置时,总是按照IP_vendor.cfg的固定格式获取。如何确保ATP在执行整机替换时总是能按照历史最新配置进行加载呢?这里需要联合配置管理方面的工作一起来看,比较简单的一个办法是:每备份一次配置文件时,将IP_vendor.cfg软链接到新的配置文件。

results matching ""

    No results matching ""