《Cloud Native Data Center Networking》（云原生数据中心网络设计）读书笔记 -- 08网络自动化

云原生数据中心和老一代数据中心不同之处在于其核心概念是聚焦于高效运营。网络自动化就是达到此目标的关键因素。

要达到此目的，本章要解决诸如下述的一些问题：

什么是网络自动化以及为什么我们在乎它?
为了学习网络自动化，我需要学习编程吗?
网络自动化为什么很难?
如何逐步探索自动化的好处?
哪些网络自动化工具适合我?
如何确保自动化程序能正常工作?

什么是网络自动化？

在网络管理语境下，自动化指的是允许程序执行运营人员所期望的任务的过程，如果这些任务不能由程序自动执行，则需要由运营人员手动将这些程序在每个网络设备上逐一运行。

为什么网络自动化很难？

作者以一个两级Clos网络中的BGP配置为例。

Sample BGP configuration for spines

sh 复制代码

! Configuration for spine01
!
interface lo
 ip address 10.0.0.21/32
!
interface swp1
  ip address 10.127.0.0/31
!
interface swp2
  ip address 10.127.0.2/31
!
interface swp3
  ip address 10.127.0.4/31
!
interface swp4
  ip address 10.127.0.6/31
!
router bgp 65000
  bgp router-id 10.0.0.21
  neighbor 10.127.0.1 remote-as 65001
  neighbor 10.127.0.3 remote-as 65002
  neighbor 10.127.0.5 remote-as 65003
  neighbor 10.127.0.7 remote-as 65004
  network 10.0.0.21/32

sh 复制代码

! Configuration for spine02
!
interface lo
 ip address 10.0.1.22/32
!
interface swp1
  ip address 10.127.1.0/31
!
interface swp2
  ip address 10.127.1.2/31
!
interface swp3
  ip address 10.127.1.4/31
!
interface swp4
  ip address 10.127.1.6/31
!
router bgp 65000
  bgp router-id 10.0.0.22
  neighbor 10.127.1.1 remote-as 65001
  neighbor 10.127.1.3 remote-as 65002
  neighbor 10.127.1.5 remote-as 65003
  neighbor 10.127.1.7 remote-as 65004
  network 10.0.0.22/32

Sample BGP configuration for leaves

sh 复制代码

! Configuration for leaf01
!
interface lo
 ip address 10.0.0.11/32
!
interface swp1
  ip address 10.127.0.1/31
!
interface swp2
  ip address 10.127.1.1/31
!
interface vlan10
  ip address 172.16.0.1/24
!
router bgp 65001
  bgp router-id 10.0.0.11
  neighbor 10.127.0.0 remote-as 65000
  neighbor 10.127.1.0 remote-as 65000
  network 10.0.0.11/32
  network 172.16.0.0/24

sh 复制代码

 Configuration for leaf02
!
interface lo
 ip address 10.0.1.12/32
!
interface swp1
  ip address 10.127.0.3/31
!
interface swp2
  ip address 10.127.1.3/31
!
interface vlan10
  ip address 172.16.1.1/24
!
router bgp 65002
  bgp router-id 10.0.0.12
  neighbor 10.127.0.2 remote-as 65000
  neighbor 10.127.1.2 remote-as 65000
  network 10.0.0.12/32
  network 172.16.1.0/24

IP地址与接口的问题

在IP网络中，网络接口都有IP地址。每个接口必须拥有一个IP地址来参与路由。转发是基于IP地址的。

路由协议是如何与对端设备进行通信呢？

最常见的答案是让链路两端的设备处于同一子网内。

典型的例子如 a/31 或 a/30。如果两端的设备都处于同一子网内，那么这就可以让一端的设备和另一端的设备利用桥接方式进行通信。比如，在图 10-1 中，某条链路在 spine 交换机的那一侧的IP地址和在 leaf 交换机那一侧的IP地址都处于同一子网内。即 spine01 上带有 IP 地址 10.127.0.0/31 的接口与 leaf01 上带有 IP 地址 10.127.0.1/31 的接口相连。这两个地址同属 /31 子网。

即便是 IPv6 中，每个接口会自动获取到一个本地链路地址，一种协议也被发明出来用来确保链路一端可以获取另一端设备的本地链路 IPV6 地址。（RA，路由器通告）。获取到另一端的 IP 地址 (本地链接或其他地址)之后 ARP (或 ARP 的IPV6 等价协议NDP) 可以用来确定对端设备的 MAC 地址。正如在第 5 章里描述的那样，获取下一跳的 MAC 地址是路由的基础。

规模

网络协议配置的复杂性

缺乏编程入口

传统网络操作系统的限制

网络自动化工具

系统管理员工具集

Ansible、Salt、Puppet、Chef 等工具被开发出来，最初是用于在单个系统上配置操作系统和应用程序，但是后来发现也可以用于网络配置。

网络管理员工具集

这里可选的工具包括NETCONF，YANG (Yet Another Next Generation) ，可能还有 Restconf。NETCONF 是传输工具，可以与文本文件配置或者 YANG数据模型一起使用。

Juniper和 Cisco产品通常使用NETCONF，而其他所有数据中心设备都使用 SSH或HTTP (用于 REST) 作为传输方式。

Ansible

Ansible 是一种自动化工具，它通过提供一种基于推送的模型，自动部署网络和计算节点的配置。

Ansible 是运行在 Linux (或 Mac) 服务器上的应用程序。它的主要输入是：

inventory 文件，它是一个待推送配置的设备的列表
Playbooks，一组指令集，用于指示所要执行的任务，任务可以生成配置或者运行命令。

Inventory

Ansible 如何知道要连接到哪一个节点，以及如何连接到这个节点？对于静态的网络实体，例如网络交换机或物理服务器，Ansible 使用一种称为 inventory 的文件。典型情况下，inventory 文件放在定义好的位置: /etc/ansible/hosts。但是你可以改变这个位置通过使用-i选项指定存放路径，或者借助 ansible.cfg 配置文件。

vx ansible_host=192.168.121.154                   
eos ansible_host=192.168.121.109                  
server01 ansible_host=192.168.121.86              
server02 ansible_host=192.168.121.82              

[servers]                                         
server01
server02

[cumulus]                                         
vx

[arista]                                          
eos

[linux:children]                                  
cumulus
linux

[routers:children]                                
vx
eos

[all:vars]                                        
ansible_port=22
ansible_user="vagrant"
ansible_ssh_private_key_file="/vagrant/machines/private_key"

[arista:vars]
ansible_network_os: "eos"

1）这个文件表明有四个设备: vx、eos、server01和 server02。每个条目占用一行显示了如何连接此设备的相关信息。

2）此inventory 文件还包含了与这四个设备相关联的不同分组。比如，servers 分组包含 server01 和 server02。有一个预定义的分组"all"包含了所有的节点。

3）分组还可以包含其他分组，避免主机被用于多个分组时，一遍遍的重复输入主机名。比如，linux分组包含了 cumulus 路由器和 servers。inventory 文件也允许你指定用于每个分组的变量。

4）虽然最好将变量放在其他文件里，但是你也可以在 inventory 文件里定义一些与分组或者主机相关的变量。比如，a11 分组包含了所有列出的节点，该分组在[all:vars]下定义了一组变量。这组变量显示了用于登录所有节点的用户名是vagrant

Playbooks

Ansible 的第二个主要部分是通过执行明确定义的工作流来执行明确定义的任务。这就涉及编写 playbooks。Ansible 包括一些顺序执行的任务或play。

下面是一个名为show-version.yml的 playbook 的例子，演示了如何获取节点的版本。

sh 复制代码

- name: get version for non-linux devices  #代表一个play，用于与一个play相关联的所有任务进行分组
  hosts: eos      # 与此play相关的一系列主机列表                                       
  gather_facts: no
  connection: network_cli
  tasks:      # 与此play关联的任务                                 
    - name: show version   # 与每一个任务关联的名字                       
      cli_command:
        commands: show version
      register: showver

    - debug: var=showver['stdout_lines']

- name: get version for linux devices             
  hosts: linux                                    
  gather_facts: no
  tasks:                                          
    - name: show version                          
      command: hostnamectl
      register: showver

    - debug: var=showver['stdout_lines']

与 Linux 设备相比，Ansible 有不同的网络设备模型，因为传统的网络设备经常不提供对 Python 的支持。在 Linux 主机上，Ansible 将某个任务对应的 Python 模板推送到远端设备上，并在此设备上执行此脚本文件。比如，模板在每一个远端设备上独立地进行渲染，并且这种渲染可以并行执行。在传统网络设备上，Ansible 假设Python 代码无法在远端节点上执行，所以 Ansible 先在本地执行那些为它正在操作的每个远端节点准备的 Python 代码，接下来再将生成的配置输出推送到远端设备上。Cumulus Linux 和 SoNIC 之类的网络操作系统可以视为 Linux 服务器，但是大多数其他网络设备 (包括 Arista 和 Cisco) 则不能。这些差异会对性能产生影响。

临时命令

略

使Playbooks结构化

推荐的Ansible目录结构

sh 复制代码

ansible.cfg                                       # 1
group_vars/                                       # 2
   routers.yml
   eos.yml
   server.yml
host_vars/                                        # 3
   vx.yml
   eos.yml
   ..
   server02.yml
inventory
roles/                                            # 4
   common/
         tasks/
        main.yml
   handlers/
   vars/
   files/
   templates/
   routers/
         tasks/
        main.yml
   handlers/
   vars/
   files/
   templates/
   servers/
        ...
site.yml

根据 Ansible 的文档，"roles 是基于已知文件系统结构自动加载特定变量文件、任务以及句柄的方法。按照roles 对文件内容进行分组还会使得与其他用户共享 roles变容易。" 在前述的示例结构中，我们会看到以下信息:

1）ansible.cfg 列出了与此目录下的文件相关的 Ansible 配置。比如，我通常在ansible.cfg 进行设置包含正在运行的 Vagrant 虚拟机所用的 inventory 文件。

2）此目录包含了与每个分组相关的变量。我们已经在 inventory 文件里定义了linux，routers，arista 等分组。

3）此目录包含了与每个主机相关的变量。所以，你能够设置与分组相关的变量也能设置与主机相关的变量。如果在分组相关的变量文件中和主机相关的变量文件中定义了同样的变量，那么主机相关的变量具有优先权，会覆盖分组相关的变量。

4）在 Ansible 中，roles 提供与函数一样的功能。正如函数包含自己的变量，role 包含特定于该 role 所执行的功能相关的信息。比如，如果你有一个 role 用来设置所有节点的 BGP 配置，你可以在 role 的 template 目录下将此配置文件定义为一个模板文件。template 目录下的文件和 files 目录下的文件的区别在于，template目录下的文件输出是通过 Jinja2 传递，而 files 目录下的文件输出是会照原样复制。对于 files 目录的文件的例子就是 FRR的 daemons 文件，FRR需要使用此文件列出需要启动的路由后台程序，例如 bgpd。你可以将此文件一直放在与配置 BGP 相关联的 files 目录下。

代码和数据分离。使用 host vars 和 group vars 是合理的，并且随着经验逐渐丰富，你也要做好准备逐渐脱离较简单的模型。
使用 Ansible 的 include 选项将 playbook 分解成简单的可重用的功能单元。当你使用 Ansible 更熟练时，可以逐步将 include 文件转换成 roles。