网络维护最佳实践

发布于:2020-12-19 18:39:15

0

78

0

网络 维护 定期检查

您可能已经注意到,NetCraftsmen会进行各种类型的评估(网络,安全性等)。在执行这些操作时,我注意到的一件事是客户的操作习惯差异很大。

该博客介绍了您应该定期执行的某些事情(流程),并在您重复执行这些操作时有所改进。它还涵盖了一些良好的操作规范。

这里有一个教训,它适用于许多领域:您可以以可控的方式提前安排时间,每次执行任务时都可以逐步改进流程,或者可以做得差一些。匆忙的消防演习,一遍又一遍。

对于那些说“但我没有时间”的人,我听到了。但是,这是“现在付钱或以后付钱”的事情。花些时间让您的生活变得更好。

为了控制此博客的大小,我们将重点放在与网络相关的任务上。每个技术领域都有其自己的领域。对于服务器和虚拟机,要想到具有可靠过程的良好备份或克隆,以及良好的备份验证过程。您不想发现急需的备份已失败并且没有人注意到,或者您不想因为没有考虑到某些原因而损坏了每个备份。当cryptolocker命中并且备份似乎全部损坏时,您就不想成为 那个人

管理定期维护

以下是定期维护任务。如果您不对它们进行管理,它们将无法完成,或者不会相当定期地完成,特别是如果您像大多数网络工作人员那样忙碌时。

对我有用的是(a)建立一个跟踪电子表格,其中包含任务以及上次执行的时间,以及(b)将它们放入日历中,也许是一年中的几周列表,哪些是维护周,哪些是变更-窗口周等

网络HA测试

我已经看到在三个大型站点完成并在其他地方推荐的一项是对高可用性(HA)的定期验证。该操作可能每年执行一次,或者每两年执行一次,具体取决于因故障切换失败而被烧死的频率。

这项工作的重点是计划是人为的并且容易出错,并且设备上的配置会随着时间的推移而变化。假设您可能不想找出破坏高可用性配置的困难方式(停机时间)。如果足够重要,则可以选择承担测试的人员和其他费用。

要实现这一点,需要遍历网络图,确定发生故障转移的点,检查配置以查看功能是否配置正确。最佳实践是实际上触发故障转移并进行故障回复以确保它确实有效。通常,这是分批进行的,并在每个可用更改窗口中进行了一些测试。这通常是低风险的,但可能会在测试时中断服务。此处的关键点是根据您的时间表而不是墨菲先生的身份(如“墨菲定律”)确定故障转移失败 。

您可能要测试的场所和HA功能包括HSRP,到HSRP或防火墙VRRP VIP的静态路由(包括确保目标是VIP不是“真实”设备IP),交换机堆栈成员故障,两个WAN路由器和链路之间的路由故障转移,等等

如果您是视频爱好者,我们中的一些人会与Network Collective进行有关HA和弹性的聊天 。

配置备份/更改控制

对我来说,自动存档配置是一种很好的做法。多种工具通常会在退出配置模式时触发Cisco syslog消息,从而触发此操作。SolarWinds NCM,Cisco Prime基础设施/ APIC-EM,NetMRI等。

这可以在发生故障时进行配置比较,例如“发生了什么变化?” –故障排除中经常会问的第一个问题。它还启用回滚。

我也喜欢出于教育/流程改进目的的审核跟踪(谁进行了更改)。

我个人更喜欢在笔记本电脑上也有当前配置的加密ZIP,以解决无法访问存档的情况。当远程访问或文件共享的路径不起作用时,这很方便。

网络设备清单

我真的很想拥有强大的网络设备清单,至少包括设备名称,IP地址,硬件模块,序列号,当前的IOS / OS版本以及SmartNet或其他支持合同信息。您可能想知道的所有内容。

这是关键的一个原因:将配置管理设备清单和其他网络管理工具中的清单同步到“主”清单。如果您有自动发现开启,那么工具可以捕获你忘记添加到您的库存设备。上面命名的工具可以提供清单信息。

顺便说一句,您是否使用网络自动发现?当我们不得不担心SNMP导致设备重新启动或“大量”网络流量时,我们已经走过了黑暗时代,不是吗?是的,  SolarWinds 或其他产品的许可强制对设备进行手动管理。效率低下。

我在很多网站上看到了带有不同设备列表的工具。这就是为什么我认为需要定期(每年一次)同步库存的原因-这样您就不会在故障排除过程中发现差距。

对于那些谁认识我,我强烈相信你应该管理的每个设备和每个接口。盲点是浪费时间。如果许可费用太高,那么您使用的工具不正确。

我还喜欢自动设置阈值(错误,丢弃,利用率百分比,进出)和警报的工具,因此您可以意识到问题。不应容忍高于0.001%(或什至更低的水平)的错误和丢弃百分比-固定电缆(通常是电缆,但并非总是如此-光学器件也很脏)。

是的,您确实确实需要管理用户和服务器端口。您可能有一些用户认为网络速度很慢,因为他们多年来一直遇到双工不匹配或电缆故障,而您却一无所知。

教INFORMATION信息

我非常喜欢缓存的信息。原因如下:当发生网络危机时,我经常看到人们花大量时间来挖掘信息。手动跟踪路线,从A到B,从B到A,记下跃点,绘制示意图。然后找出涉及的接口并查看其配置。等等,这既费时又容易出错,请不要去那里。

在这里,好的网络管理工具可以并且确实集成了所有这些信息,以节省您的时间。 NetBrain 和SolarWinds具有一定程度的路径功能。太多的工具在将信息埋藏在其中的某种意义上提供了“可见性”,但是您仍然最终不得不在太多的不同地方进行过多的挖掘,以汇总所需的知识。

好的意味着在您需要时它就在那里。不好的是,当它们都放在某个地方时,但是需要花费两个小时的寻宝游戏才能将其全部拉出并放入基于纸张的桌子中。

缓存的信息包括(a)良好的图表,以及(b)在DNS中包含您的路由器名称。并且请遵循结构化命名约定使用简短的设备名称。不要在名称中包含设备类型,它会使名称变得很长,很难记住,并且稍后会咬住您(设备类型是好的库存为您提供的功能)。

图必须是可持续的(结构化,模块化的),否则会浪费时间。千篇一律的站点和园区设计可能意味着您可以用通用图和按站点信息的XLS替换图。使用常识。图表因浪费时间而声名狼藉,因为人们过度使用图表,包含过多信息或以难以改变的方式进行绘制(例如海报大小的图表)。

对于那些说他们没有时间来生成好的功能图的人,我说:“嘿,每次执行traceroute / sketch东西时,您都会浪费一个小时,而且还要冒错误的风险。您最终会反复这样做。正确地做,并在重要时节省时间!”

自动配置合规性检查

熵发生了-这就是定律(热力学)。您需要施加能量来反转熵。

适用于配置合规性:配置会随时间推移而漂移-人们可能会前后矛盾或混乱。

符合性检查工具可以帮助您解决此问题,但价格昂贵(许可加添加规则)。自行开发的工具必须应对各种语法和默认值(在所有Cisco平台上)造成的复杂性(“全部显示运行”并不能始终如一地显示默认值)。

定期设备代码升级和跟踪

新的IOS代码有风险,但是当我看到设备已经7年没有重启时,我的反应是“那是相当健壮的,做得很好的Cisco(或其他供应商)”,然后是“哦,但是安全补丁还没有”被应用”。

NetCraftsmen和Cisco通常建议使用“ N-1”方法,就像在最新的代码版本中一样-其他站点已经为您测试过,发现了严重的/常见的错误,并进行了多次补丁更新。

我们还建议定期将代码刷新到N-1,也许一年一次或两次。许多网站都不记得要这样做。

容量规划数据捕获和预测跟踪

大多数网络管理工具都会汇总历史测量数据,以消除流量峰值。

对于容量规划,你可以选择一些数字,如95 百分位,或80 百分点,和捕获的流量测量(入站,出站)到Excel的关键接口。假设您每月这样做。然后,您可以绘制数据点图,应用趋势线,插入年度或季度容量目标。通过这样做,您可以了解自己的看法和实际数据,从而可以学习和改进。

感谢我们的特里斯莱特里,我喜欢他的约百分数据关键点:95百分位的手段,你测量的5%,分别为糟,甚至更糟。这样,每分钟的数据,72分钟的平均值分别为坏或大于95更糟 百分位(51440分钟%)。详细介绍这是一个 单独的博客主题。

变更准备

更改期间的时间Windows运行很快。提前彻底准备;拥有configlet,回滚configlet,电话号码/联系信息以及手边所有必要的信息是提高效率的关键。几个大型站点使用一个XLS中的标签将它们捆绑在一个地方。

制定可靠的测试计划也是关键。不要从那里走过(取决于关键性)。这更多是一个过程项目,不一定是周期性的,但可以改善您进行变更的方式。

经验表明,草率的准备常常与转换延迟和障碍有关。未能计划测试可能意味着差距,然后在星期一早上咬住您。

人们尤其会忘记做某事,例如,他们将VLAN添加到下行链路,而不是添加到VPC或核心交换机之间的其他中继。然后可能要花一些时间才能解决该问题-这是您没有的时间。

预先对变更进行VIRL建模可以有所帮助-尽管L2在那里有些问题。VIRL至少可以捕获语法和路由问题。

第二个相关实践是在更改的早期验证1-3层。连接性问题可能会伪装成路由或更高级别的问题,从而浪费宝贵的转换时间。这也是CCIE实验室的建议:在花费时间处理复杂的症状之前,请检查您的基础知识(链接,寻址,路由邻接关系并保持稳定)。

真正的灾难恢复/作战计划和测试

对于单独的博客,这是一个足够大的主题。我的印象是组织倾向于做出各种方便的假设,为灾难恢复失败做好准备。所有车队都必须做好准备。

我将在这里强调的是具有详细的DR网络计划,包括configlet,尤其是在需要即时重新配置的情况下。并测试它们。在DR网络启动之前,所有操作都将无效,所以所有的目光都将注视着您!

应用程序故障转移计划和测试

网络和应用程序团队确实需要讨论应用程序的DR故障转移是如何工作的。这有助于进行适当的设计,自动故障转移并减少发生灾难恢复时的指责。定期测试有帮助。