Geekly articles weekly

自动化程度最小。 零部分。 规划中

SDSM已经结束，但无法控制的写入愿望仍然存在。



多年以来，我们的兄弟经常进行例行工作，在交战前用手指交叉，并且由于夜间回滚而缺乏睡眠。
但是，黑暗时代即将结束。

在本文中，我将开始有关自动化的系列文章。
在此过程中，我们将使用RestAPI，NETCONF，YANG，YDK处理自动化，存储变量，形式化设计的各个阶段，我们将进行大量编程。
对我来说 ， 这意味着a）这不是客观事实，b）不是无条件的最佳方法c）即使在从第一篇到最后一篇的过程中，我的看法也可能会发生变化-老实说，从草稿阶段到出版物，我彻底重写了所有内容两次。


目录内容


  1. 目标
    1. 网络就像一个有机体
    2. 配置测试
    3. 版本控制
    4. 监测和自我修复服务

  2. 均值
    1. 库存系统
    2. IP空间管理系统
    3. 网络服务描述系统
    4. 设备初始化机制
    5. 供应商不可知配置模型
    6. 供应商特定的驱动程序
    7. 向设备下发配置的机制
    8. CI / CD
    9. 备份和偏离机制
    10. 监控系统

  3. 结论



我将尝试使ADSM的格式与SDSM略有不同。 编号较大的详细文章将继续出现，在它们之间，我将发布日常经验中的一些小笔记。 我将在这里尝试与完美主义作斗争，而不是舔它们中的每一个。

第二次您必须以同样的方式做这件事真有趣。

首先，由于它们不在RuNet中，因此我不得不写有关网络本身的文章。

现在，我找不到能将自动化方法系统化并使用简单的实际示例来分析上述技术的全面文档。

因此，也许我弄错了，因此抛出了指向合适资源的链接。 但是，这不会改变我写作的决心，因为主要目标仍然是我自己学习一些东西，并使我的邻居生活更轻松，这是一个令人愉悦的好处，它爱抚着传播经验的基因。


我们将尝试建立一个中型的LAN DC数据中心，并制定出整个自动化方案。
我几乎会第一次和您一起做一些事情。

在这里描述的思想和工具中，我不会是原创的。 德米特里·菲戈（Dmitry Figol）拥有一个出色的频道，提供有关此主题的信息流 。
许多方面的文章将与它们重叠。


LAN DC具有4个DC，约250个交换机，六个路由器和几个防火墙。
不是facebook，而是足以深入思考自动化。
但是，有一种观点认为，如果您拥有多于一台的设备，则您已经需要自动化。
实际上，很难想象有人现在至少可以没有一堆膝盖高的剧本。
尽管我听说在这样的办公室中IP地址保存在Excel中，并且数千个网络设备中的每一个都是手动配置的，并且具有自己的独特配置。 当然，这可以作为当代艺术来使用，但是工程师的感受肯定会受到冒犯。

目标


现在我们将设定最抽象的目标：
  • 网络就像一个有机体
  • 配置测试
  • 网络状态版本控制
  • 监测和自我修复服务

在本文的后面，我们将分析将使用的手段，以及下面的目标和手段。

网络就像一个有机体


循环的定义短语虽然乍一看似乎并不那么重要： 我们将配置网络，而不是单个设备 。
在过去的几年中，我们看到了对如何将网络视为一个整体的关注的转变，因此， 软件定义的网络 ， 意图驱动的网络和自治网络开始出现。
毕竟，网络上的应用程序在全球范围内需要什么：A点和B点之间的连通性（有时是+ B-Z点）以及与其他应用程序和用户的隔离。



因此，本系列的任务是构建一个支持整个网络的当前配置的系统 ，该系统已根据其角色和位置分解为每个设备上的当前配置。
网络管理系统意味着要进行更改，我们求助于它，然后依次为每个设备计算所需的状态并对其进行配置。
因此，我们将手中的CLI使用率降至最低，几乎为零-设备设置或网络设计的任何更改均应正式化并记录在案-然后再推广到必要的网络元素。
也就是说，例如，如果我们决定从现在开始，喀山的机架式交换机应该宣布两个网络，而不是一个，那么我们
  1. 首先，我们记录系统中的更改
  2. 我们生成所有网络设备的目标配置
  3. 我们启动网络配置更新程序，该程序计算需要在每个节点上删除的内容，添加的内容并将节点置于所需的状态。

同时，我们只在第一步就进行更改。


配置测试


众所周知 ，有80％的问题是在配置更改期间发生的-间接证明是，在新年假期期间，一切通常都很平静。
我亲眼目睹了数十次由于人为错误而导致的全球停机：错误的命令，在错误的分支中执行了配置，社区忘记了，在路由器上全局拆除了MPLS，配置了五块铁，并且没有注意到第六个错误，犯了另一个人所做的旧更改。 场景是黑暗的。

自动化将使我们犯下的错误更少，但规模更大。 因此，您可以一次性建立一个设备，而不是整个网络。

自远古时代起，我们的祖父就用锐利的眼神，钢蛋和在推出后的网络效率检查了更改的正确性。
这些祖父的工作导致了停机时间和灾难性损失，他们留下的后代减少了，应该随着时间的流逝而消亡，但是进化是一个缓慢的过程，因此并不是每个人都在实验室里检查过变化。
但是，在那些自动化测试配置过程并将其进一步应用到网络的人中，他们走在了最前沿。 换句话说，我从开发人员那里借来了CI / CD（ 持续集成，持续部署 ）过程。
在一部分中，我们将研究如何使用版本控制系统（可能是github）来实现这一点。

一旦您习惯了网络CI / CD的概念，一夜之间，通过将其应用到工作网络中来检查配置的方法在您看来似乎是早期的中世纪愚昧。 关于如何用锤子敲击弹头。


有关网络管理系统和CI / CD的想法的有机延续是配置的完整版本。

版本控制


我们将假定，即使进行任何更改，即使是最次要的更改，即使是在一台不起眼的设备上进行的更改，整个网络也会从一种状态变为另一种状态。
而且我们始终不在设备上执行命令，而是更改网络状态。
现在让我们获取这些状态并将其称为版本吗？

假设当前版本为1.0.0。
环回接口的IP地址在ToR之一上是否已更改？ 这是次要版本-获取数字1.0.1。
审查了BGP中的路由导入策略-更为严重-已经1.1.0
我们决定摆脱IGP并仅切换到BGP-这是一项重大的设计更改-2.0.0。

同时，不同的DC可能具有不同的版本-网络正在开发，正在安装新设备，在某个地方添加了新的主干级别，某个地方-否，等等。

我们将在另一篇文章中讨论语义版本控制 。

我重复一遍-任何更改（调试命令除外）都是该版本的更新。 如果与当前版本有任何偏差，应通知管理员。

回滚更改也是如此-这不是废除最后一个命令，也不是设备操作系统回滚-这会将整个网络带到新的（旧的）版本。

监测和自我修复服务


现代网络中的这一不言而喻的任务进入了一个新的高度。
大型服务提供商通常会采用这样一种方法，即必须迅速结束掉落的服务并提出新的服务，而不是弄清楚发生了什么。
“非常”表示必须从各个方面对监控进行大量涂抹，这将在几秒钟内检测到与规范之间的最小偏差。
而且这里还没有足够熟悉的指标，例如加载接口或节点的可访问性。 没有足够的人工跟踪值班人员。
在许多事情上，通常应该有自我修复功能 -控件会亮起红色并脱离车前草，这会很痛。

在这里，我们不仅监视单个设备，而且监视整个网络的运行状况，包括相对清晰的白盒和已经较复杂的黑盒。


我们需要执行什么雄心勃勃的计划？
  • 列出网络上所有设备的列表，它们的位置，角色，型号，软件版本。
    kazan-leaf-1.lmu.net，Kazan，叶子，Juniper QFX 5120，R18.3。
  • 有一个描述网络服务的系统。
    IGP，BGP，L2 / 3VPN，策略，ACL，NTP，SSH
  • 能够初始化设备。
    主机名，管理IP，管理路由，用户，RSA密钥，LLDP，NETCONF
  • 配置设备，并使配置达到所需的版本（包括旧版本）。
  • 测试配置
  • 定期检查所有设备的状态是否与当前设备存在偏差，并告诉谁应该。
    晚上，有人悄悄地向ACL添加了一条规则 。
  • 监视性能。



均值


听起来很复杂，无法开始将项目分解为组件。

其中将有十个：
  1. 库存系统
  2. IP空间管理系统
  3. 网络服务描述系统
  4. 设备初始化机制
  5. 供应商不可知配置模型
  6. 供应商特定的驱动程序
  7. 向设备下发配置的机制
  8. CI / CD
  9. 备份和偏离机制
  10. 监控系统


顺便说一下，这是一个关于周期目标的看法如何发生变化的示例-组成部分草案中有4个组成部分。




在图示中，我描绘了所有组件和设备本身。
相交的组件彼此交互。
块越大，您就越需要关注此组件。


组成部分1.库存系统


显然，我们想知道什么设备，它位于什么位置，连接到什么设备。
库存系统是任何企业不可或缺的一部分。
通常，对于网络设备，企业拥有单独的清单系统，可以解决更具体的任务。
作为一系列文章的一部分，我们将其称为DCIM-数据中心基础架构管理。 尽管严格说来，DCIM术语本身包含更多内容。

对于我们的任务，我们将在其中存储有关设备的以下信息：
  • 库存编号
  • 标题/说明
  • 型号（ 华为CE12800，瞻博QFX5120等 ）
  • 典型参数（ 板，接口等 ）
  • 角色（ 叶子，脊椎，边界路由器等 ）
  • 位置（ 区域，城市，数据中心，机架，单位 ）
  • 设备之间的互连
  • 网络拓扑




显然，我们自己想知道所有这一切。
但这对自动化有帮助吗？
当然可以
例如，我们知道在这个叶子交换机上的数据中心中，如果是华为，则应在VLAN上应用用于过滤某些流量的ACL；如果是Juniper，则应在物理接口的单元0上应用。
或者，您需要向该地区的所有寄宿者推出新的Syslog服务器。

在其中，我们将存储虚拟网络设备，例如虚拟路由器或根反射器。 我们可以添加DNS服务器，NTP，Syslog，以及通常与网络相关的所有内容。

组件2. IP空间管理系统


是的，在我们这个时代，有很多人跟踪Excel文件中的前缀和IP地址。 但是现代方法仍然是一个数据库，具有nginx / apache的前端，API和广泛的功能，这些功能考虑了IP地址和网络（分离为VRF）。
IPAM-IP地址管理。

对于我们的任务，我们将在其中存储以下信息：
  • 虚拟局域网
  • VRF
  • 网络/子网
  • IP地址
  • 将地址绑定到设备，网络绑定到位置和VLAN号




同样，很显然，我们希望确保通过为ToR环回分配新的IP地址，我们不会迷惑已将其分配给某人的事实。 或者我们在网络的不同末端两次使用相同的前缀。
但这对自动化有何帮助？
很简单
我们在系统中请求具有Loopbacks角色的前缀，其中有可分配的IP地址-如果有，请选择该地址，否则请选择创建新的前缀。
或者，在创建设备配置时，我们可以从同一系统中找出接口应位于哪个VRF中。
当您启动新服务器时，脚本会进入系统，找出交换机在哪台服务器中，在接口中分配了哪个端口和哪个子网-它将从中选择服务器地址。


迫切希望DCIM和IPAM合并为一个系统，以免重复功能且不为两个相似的实体提供服务。
所以我们会做。

组件3.网络服务描述系统


如果前两个系统存储仍需要以某种方式使用的变量，则第三个系统针对每个设备角色描述应如何配置它。
值得强调两种不同类型的网络服务：
  • 基础设施
  • 委托人


前者旨在提供基本的连接性和设备管理。 这些包括VTY，SNMP，NTP，Syslog，AAA，路由协议，CoPP等。
第二个为客户端组织服务：MPLS L2 / L3VPN，GRE，VXLAN，VLAN，L2TP等。
当然，也有极端情况-在哪里包括MPLS LDP，BGP？ 是的，路由协议可以用于客户端。 但这并不重要。

两种服务都分解为配置原语：
  • 物理和逻辑接口（标签/ anteg，mtu）
  • IP地址和VRF（IP，IPv6，VRF）
  • ACL和流量处理策略
  • 协议（IGP，BGP，MPLS）
  • 路由策略（前缀列表，社区，ASN过滤器）。
  • 服务服务（SSH，NTP，LLDP，Syslog ...）
  • 等等

我们将如何做到这一点，我不会全神贯注。 我们将在另一篇文章中介绍。



如果离生活更近一点，那么我们可以形容为
叶子交换机必须与所有连接的Spine交换机建立BGP会话，将连接的网络导入到进程中，并且仅接受来自Spine交换机的特定前缀的网络。 将CoPP IPv6 ND限制为10 pps等
反过来，自旋会与所有连接的身体（充当根反射器）举行会议，并从中仅接收一定长度和特定社区的路线。

组件4.设备初始化机制


在此标题下，我结合了必须执行的许多操作才能使设备出现在雷达上并可以远程访问。
  1. 在清单系统中启动设备。
  2. 高亮显示管理IP地址。
  3. 配置对其的基本访问权限：
    主机名，管理IP地址，到管理网络的路由，用户，SSH密钥，协议-telnet / SSH / NETCONF


有三种方法：
  • 一切都是完全手动的。 该设备将被带到一个站台，在那里普通的有机人将带领他进入系统，连接到控制台并进行配置。 可以在小型静态网络上工作。
  • ZTP-零接触配置。 Iron来了，站了起来，通过DHCP收到了一个地址，去了一个特殊的服务器，并进行了配置。
  • 控制台服务器的基础结构，其中初始配置是通过控制台端口以自动方式进行的。


我们将在另一篇文章中讨论这三个方面。




组件5.与供应商无关的配置模型


到现在为止，所有系统都散布着碎片，给出了变量以及对我们希望在网络上看到的内容的声明性描述。 但是迟早，您必须处理一些细节。
在此阶段，对于每个特定设备，仅以与供应商无关的方式，将原语，服务和变量组合到一个配置模型中，该配置模型实际上描述了特定设备的完整配置。
是什么赋予了这一步？ 为什么不立即配置设备，您只需填写一下呢？
实际上，这使我们能够解决三个问题：
  1. 不适应用于与设备交互的特定接口。 无论是CLI，NETCONF，RESTCONF，SNMP-模型都是相同的。
  2. 请勿按网络上供应商的数量来保留模板/脚本的数量，并且在进行设计更改的情况下，请在多个位置进行更改。
  3. 从设备下载配置（备份），以完全相同的模型进行布局，然后直接比较目标配置和可用于计算增量和准备配置补丁的配置，这将仅更改那些必需的部分或检测偏差。




作为此阶段的结果，我们获得了与供应商无关的配置。

组件6。特定于供应商接口的驱动程序


不要希望自己一旦配置了tsiska后就可以安慰自己，就可以像跳线一样发送相同的呼叫。 尽管白盒越来越受欢迎，并且出现了对NETCONF，RESTCONF，OpenConfig的支持，但是这些协议提供的具体内容因供应商而异，这是它们根本不会放弃的竞争差异之一。
这与将RestAPI作为其NorthBound接口的OpenContrail和OpenStack期望的调用完全不同。

因此，在第五步，独立于供应商的模型应采用将要采用的形式。
在这里，所有手段都是好的（否）：CLI，NETCONF，RESTCONF和SNMP只是一个简单的秋天。

, : CLI , XML.




7.


- , — , , .
- , , ? :
  • CLI (telnet, ssh)
  • SNMP
  • NETCONF
  • RESTCONF
  • REST API
  • OpenFlow ( , FIB, )


. CLI — . SNMP… -.
RESTCONF — , REST API . NETCONF.

, , — , .

- , ?
:
  • . ncclient asyncIO . , ?
  • Ansible .
  • Salt Napalm.
  • Napalm, , .
  • Nornir — , .


— .

? .
. .
, commit , .
NETCONF — . RFP . , 32*100GE . ?



8. CI/CD


.
« », . , . , .

, , , -, .
Pipeline CI/CD.
CI/CD Continuous Integration, Continuous Deployment. , , , (Deployment) , , (Integration).


, , , , , , — .

, CI/CD Pipeline — .




9.


.
.

— - . - , , -, , .
, - , , . — , - , , , , .

, . . , .
, IP, — .





10.


— , . , . .

— CI/CD. , , .
, — , , BGP-, OSPF-, End-to-End .
, SFlow-, , - ?

.







结论


— L3 Clos Fabric BGP .
Juniper, JunOs — .

Open Source — .

:
. , , , .
: , , .
.
, , .
.

, . :)

有用的链接




. .
. .

Source: https://habr.com/ru/post/zh-CN453516/

More articles:


All Articles