数据中心网络运维非常复杂，本文根据业界最佳实践，介绍了一个数据中心网络运维的实际框架及相关内容，供读者参考。读者可以根据自己的实际情况进行补充、修改和裁减。
网络运维的主要内容如下图所示：
网络运维的内容架构图
在数据中心环境下，对网络的基础监控和自动化操作是网络运营的基础，相关于管理员的“眼”和“手”。
1、面向日常运维支持工作的主要内容包括：
故障处理–处理故障，快速恢复业务
性能管理–监控和管理网络的性能
配置管理–维护网络配置合规有效
拓扑管理–维护准确有效的网络拓扑
2、面向宏观运营层面的管理，包括：
可用性管理–管理网络的可用性，满足用户的SLA
容量管理–分析容量状态和业务的变化趋势，确保网络容量能支持业务发展
3、面向用户的服务管理，管理网络与上层业务的服务接口，服务质量协议。
二、基础监控与自动化操作层面
1、网络的基础监控
基础监控通过各类接口和协议，主动地或被动地收集网络的运行信息，以便及时、准确地了解网络中实际的运行状态。
（1）监控的接口
数据中心网络能提供的管理接口和管理内容，必须在设计和选型时进行仔细地考虑。如果在运维阶段发现有很多重要的参数无法监控，将是十分被动的。
通常设备提供以下的管理接口：
ICMP –通过Ping进行最基本的连通性探测
SNMP –通过SNMP轮询，读取设备MIB所支持的管理信息
SNMP Trap/Notification –设备主动把告警发到监控平台
Syslog –一些厂商的设备通过Syslog提供比较丰富的信息，对深度排错有帮助
流信息–如思科Netflow或H3C的sFlow，提供了IP层和协议层详细的数据流信
CLI –通过模拟管理员登录，在设备管理终端上显示相关参数
（2）监控的内容
设备具备一定的管理接口，并不代表它能支持相应的监控内容，具体要看设备通过SNMP、XML、CLI等接口能提供哪些信息。这在设备的选择阶段十分重要。运营团队一定要在设备选型时，或者纳入生产管理之前，提出自己的监控要求。
典型的内容包括：
控制平面：路由状态的变化，路由拓扑信息
数据平面：端口利用率，丢包，误码，Netflow
管理平面：设备的负载，环境参数如温度、电源、电压、风扇
对于主动监控，要注意监控的方式：通过什么接口采集数据，多长时间采集一次，采集后的处理规则；对于被动收集的方式，要注意收集后的处理规则。
（3）监控结果的处理
应该着重强调的是，对网络的监控并不仅仅是为故障发现服务的。实际上，有很多上层的管理都需要通过监控层来收集基础的数据。监控层也同样需要为上层这些管理功能服务。
一种典型的错误做法，是把几乎所有的监控结果都发到告警平台上去。这会给告警系统造成很大的压力要么告警系统收到后将这些信息丢掉，要么转给负责故障处理的一线值班人员，由一线值班人员手工删除。无论哪一种，都是浪费。
正确的做法是，在开始进行监控时，一定要搞清楚监控的参数是为哪些管理功能服务的，然后把监控结果发给相应的管理系统处理。
举例来说，有些网络管理员会比较在意网络带宽的使用情况，于是监控带宽利用率，并设置阀值，一旦利用率超出阀值就进行告警。实际上，这种做法只有负面的意义，因为网络流量的突发性和波动性，阀值很有可能在瞬间被突破，但这并不意味着对业务会有影响，可能很快流量就会降到阀值以下，管理员收到这类告警并没有适合的处理手段。最终这种告警成为一种骚扰。
正确的做法是，把采集到的网络流量信息纳入容量管理的流量，定期进行宏观统计和趋势分析。
再比如Syslog的处理。网络设备上通常能报出很多Syslog信息。但很多信息发到告警系统后等被直接丢弃了。实际上，对于给定的设备类型和应用场景，除了几种明确的Syslog之外，多数Syslog不需要直接转入告警平台。比较好的做法是把Syslog尽量全地发到固定的Syslog服务器上，用问题管理的规则，定期进行统计分析，并方便排错时的查找。
2、网络的自动化操作
在架构统一，配置规范的前提下，自动化的优势才能显现出来。管理及规范的精细度决定了自动化程度。对于大集群的运维建设，使用自动化操作可以大大提供运维效率。网络的自动化需要和上下游打通（基础IDC、业务这些直接关联配置架构，需要推动它们与网络架构相匹配的规范化），否则在具体实施时就可能存在诸多问题。现有的自动化操作有：配置自动生成下发，监控自动添加，业务自动分配等。
（1）IP地址管理。IP地址的管理与设备管理是类似的，是其它自动化系统依赖的基础的信息源，在自动化过程中遇到的任何变量数据必须创建一个基础数据（库？）进行管理，IP地址也一样。IP段的属性可能有：机房、业务、类型、VLAN、网关等。可以根据具体的需求定制，尽可能用少量的属性完成自动化，因为任何手工维护的数据库都需要成本。
（2）自动化配置。当涉及配置的变量都已经有源数据库后，配置生成就非常简单，根据架构模板加上具体业务属性，通过系统即可生成某个具体的网络设备所有配置。配置生成完，可以通过工具自动下发到设备并生效。常用的配置下发方式有：交互式的CLI，TR-069，XML，SNMP；要依赖于现有网络设备支持的情况，建议是统一，可控。XML会是一种未来通用的方式。
（3）配置操作授权及审计。网络架构的设计决定是否会涉及到日常变更，当网络都以模块化交付、迁移、变更的前提下，针对单台设备的日常变更将会越来越少。随着工具监控系统不断介入网络设备的管理操作，操作授权和审计必须做到精细化，严格控制每个系统使用的账号权限。可以使用市场上常见的产品来完成AAA，当然也可以尝试tac_plus这样的开源产品。
三、日常支持层面
1、网络故障处理
（1）故障的分级。故障的分级是故障管理的基础。数据中心的网络故障可以有两种分类方式：
根据故障的业务影响分级
根据故障相关设备的业务影响分级
由于数据中心网络的复用性，网络故障的级别多取决于网络设备在数据中心的位置。位于核心的设备影响大，同类故障级别要高一些；而接入设备影响小，同类故障级别要低一些。
（2）故障处理。在传统的观念里，网络等基础架构故障是一种异常状态，出了故障必须及时恢复，故障解决的所有压力都在基础架构侧；而在互联网等新的行业里，会在业务架构时，把基础设施的故障看作是一种常态，故障一旦发生，业务侧是有能力进行切换或规避的。
从数据中心管理的角度，建议把网络强壮化和业务强壮化并行，因为任何一个短板都决定了业务恢复速度。
如果业务和基础架构独立运维，则发生故障时需要依据故障的优化级去解决；而如果业务和基础架构一体化运维，可以通过业务系统切换来避免网络故障对业务的影响，积极调动业务方资源，确保第一时间业务恢复。
2、网络性能管理
对于最终用户来说，响应时间是判断网络性能质量高低的一个基本手段，而对于网络管理员来说，还要关注网络资源的利用率。常见性能指标：连通性、吞吐、带宽、丢包率、时延、抖动。
（1）面向互联网的质量覆盖。针对互联网用户来说，ISP的网络质量直接关系到终端用户的访问质量，通过合理部署监控系统，来定位某个ISP是否有异常，并及时做出系统层面的响应。如通过DNS切换请求路径，来保障ISP用户的访问质量。监控的颗粒度及精细化程度，决定了是否能第一时间知晓互联网用户的网络状态。常用的方法有：全网的基调，采集全网日志。后者需要强大的存储和计算资源支持。
（2）内网性能管理。内网性能相对可控，在网络架构落地之前，需要做详细测试，方案验证。依赖于测试的结果合理部署。内网的高可靠性保障了业务的冗余，但对延迟、丢包、RTT更为敏感，对网络架构和设备硬件的熟悉度，决定了内网性能管理的精细度。
同时，要测试性能管理与业务相结合，不同的业务对性能参数的要求是不同的。比如，有些交易数据对时延特别敏感，而实时语音或视频数据对抖动有严格的要求，海量离线分析则要求网络的高吐吞能力，对丢包特别敏感。
3、网络配置管理
（1）配置模板标准化。在网络中运行着很多网络协议，包括路由协议和各种为上层应用服务的广域网、局域网协议等。路由器上也存在着很多服务，有些服务是网络运行所必需的，必须打开它；而有些服务是对网络运行无关紧要或无用的，可以关闭。在架构设计中，必须明确每个配置的具体作用，打开必须的功能特性，关闭不必要的特性，将配置尽可能精简化，规范化。
这里的标准化必须是和架构一体的，适应架构的规范。意味着当某个架构确定的情况下，所有设备的所有配置都能固化，只是部署的软调资源会随着IDC的物理位置发生变动。强调一下，在架构确定的情况下，配置必须相应地确定，这样IDC的建设才能模块化。
（2）配置规范及审计。配置的规范还是要依赖架构的设计，规范是先行，而审计是后补，二者相辅相成，共同确保网络状态是否正常。审计的内容主要是针对网络设备的配置，哪些必须有，哪些不能有，虽然配置标准化及规范保证网络建设过程中不出现异常，但是审计是保证变更过程或日常校验过程中能及时发现异常。审计依赖于配置规范，通常的做法是将设备配置全局本地保存，通过相应规则匹配查看设备是否异常，需要定期开启审计功能。
4、网络拓扑管理
网络拓图是运营中重要的信息资源。不仅仅是一线网络运营人员需要网络拓扑，实际上，网络优化团队、网络架构团队、容量管理团队、业务运维团队，都在各自的角度上具有网络拓扑的需求。
尤其是业务与网络混合运维的前提下，对拓扑的概念有了新的定义拓扑是基础平台。拓扑把静态基础数据动态地关联在一起。
从网络角度有网络拓扑，从现场IDC角度有机房环境拓扑，从业务角度有流拓扑，在标准的架构下网络拓扑层级简单明了，如果可以，要关联业务、监控、运维属性，使得管理可视化，简洁明了。
（1）拓扑的层级。面向不同的使用者，有不同的拓扑层级。比如网络容量管理员更关心广域网的拓扑和上面的负载变化，而不会关心数据中心网络的VLAN/IP地址等细节。网络规划人员可能需要在拓扑上显示路由域等信息，而工程实施人员往往需要某个局部的尽量全面详细的信息。
网络层拓扑的确定跟自身网络架构息息相关。DC内分接入，汇聚，核心；东西向DC间核心层；南北向对外提供服务核心层。建议是严格区分，根据每个设备的功能定义一个角色，统一规范，为后续自动化及监控提供集群分类。
（2）拓扑的自动化发现与维护。拓扑作为基础运维的一个平台，必须保证拓扑数据的准确性和完整性。通过网络设备支持的邻居发现协议，推广到服务器侧，运用监控平台自动采集到这些关联关系来完成拓扑生成的自动化。协议采集是动态的，无需人为维护，提供了必要的准确性和完整性支持。有了这个基础平台，才能在满足网络规模不断壮大的前提下，减少人力运维的成本。
当然，这需要诸如LLD等底层协议的支持，也对网络规划与设计提出了要求，需要在设计时就考虑网络能够被拓扑发现。
同时，也只有很好地支持自动发现，网络拓扑才有较强的可维护性。否则在反复的日常变化中，历史收集的拓扑信息很难及时维护，可能会最终失去参考价值。
四、宏观运维层面
1、网络可用性管理
可用性是衡量网络服务的一个重要指标，也是衡量整个基础架构服务的重要指标。
（1）建立网络可用性的度量模型。建立网络可用性度量模型的目的，是让网络运营团队和用户之间有一个共同认可的度量标准，以便网络服务的可用性能量化地度量。
业界常见的做法，是把为各个用户正常提供服务时间之和，除以各个用户应受到正常服务的时间之和。但实际工作中，我们很难直接统计到面向用户的服务状态，而是以用户接入交换机的可用状态，来近似计算用户服务的可用性状态。
考虑到不同业务的性质不同，在可用性建模的过程中还需要对业务影响进行加权处理。
（2）网络可用性的测量方法。有多种方法可以测量网络的可用性，它们各有优缺点。
故障单法。对于每个报告的故障，可计算“不可用的”用户时间分钟数。然后，将该时段的总用户时间（分钟）数，减去该时段不可用的用户时间（分钟）总数，即得到可用的用户时间分钟数。将可用的用户时间（分钟）数，除以用户时间（分钟）总数，得到可用性百分比。
此方法有两个主要的缺点：
极其费力，几乎需要对每个故障报告进行手动审核与检查；
此类人工“梳理”活动极易出现人为错误，对报告的有效性非常敏感。
设备报告。计算可用性的另一个方法是，测量ITIL配置项的可用性，如网元（路由器、交换机、防火墙）、WAN或LAN链路，或者其它IT基础架构项目，如服务器、数据库等。由于这些项目中许多都能够自我报告，因此这种方法往往比基于故障的可用性计算方法更可靠、更容易。
在基于设备的报告中，SNMPTrap或Syslog消息（如连接通断）被发送到服务器，后者汇总停机时间总长数据，然后将正常运行（可用）时间的分钟数总和，除以报告期的分钟数总和，计算报告期的可用性。这通常是自动完成的。
但是，设备报告经常不能充分体现设备中断故障对业务的影响。一个造成五位用户服务中断的边缘路由器故障，与中断一个数据中心并使整个企业都无法使用关键业务应用的路由器故障，它们对可用性的影响“似乎”相同。设备可用性也没有考虑冗余性。另外，在突发灾难性故障的情况下，可能不发出Syslog/SNMP告警。这种方法还依赖于变更管理，以考虑网络中设备的变化。
模拟探测。这种方法还有一种更复杂的版本，即在较大、较重要的用户节点安装探针，对重要应用进行模拟，然后跟踪模拟交易数据并向服务器汇报。最后，由网管服务器计算可用性并统计其它数据。这种方法有一个显著优势，即使某个设备表面上看似完全正常，智能探针也能发现“软故障”并报告给服务器。这样，就可以即时发现软故障和流量黑洞。如果不用这种方法，经常无法发现软故障，直到用户服务受到严重影响。
2、网络容量管理
网络容量管理是一个面向管理层的主动管理，它有以下特点，在实际工作中需要注意：
容量管理是瓶颈的管理：需要及时发现系统架构中的瓶颈，针对瓶颈进行扩容；
容量管理是趋势的管理：数据中心基础架构的扩容往往需要较长的时间，当容量出现问题的那一刻再进行扩容必然是来不及的，我们需要提前分析未来的发展趋势，及时判断，为扩容留出足够的时间；
容量管理是依赖关系的管理：数据中心是一个完整的架构，一个点的扩容往往可能会引起相关的基础系统一起扩容。比如要增加某个区域的容量，除了考虑增加接入端口、布线之外，还要考虑IP地址空间是不是满足，底层的电力、空调够不够；
容量管理是组份的管理：数据中心是一个复用的基础平台，我们需要了解是哪些业务组份占用了主要的容量，不同业务对资源使用的趋势如何，这样才能抓住主要矛盾，有针对性地进行容量管理，使我们的工作事半功倍。
网络容量的规划。网络的规模和数据中心规模息息相关，如何规划数据中心的容量，一直是困扰数据中心管理者和从业者的一个重大问题。当数据中心的建设意向提出之后，数据中心的建设容量到底是多大？到底该按照哪些因素去规划数据中心的容量？立项的数据中心到底该按照哪种方式去建设？如何使将要建设的数据中心能够面临以后10年的业务成长？如何使数据中心保持可靠性，经济性和节能环保的有机统一？不一而足。
目前通行的做法是：首先根据业务的发展，定出在数据中心生命周期内业务发展的路线图，然后就可根据该路线图核定出对各阶段业务支持的IT设备，继而也就可以定出各阶段支持系统的容量与规模。在获取各系统在各阶段的容量与规模之后，就可以进行细化设计了。
基础设施容量管理。数据中心规模越来越大，对数据中心从选址、区域划分、土建、承重、装饰装修、供电、制冷、强电、弱电、综合布线、照明、防雷接地、消防、监控与门禁等各个不同的维度，提出了新的建设要求。但总的来说，数据中心最重要的三个制约条件是：供电，制冷，占地面积（空间制约）。这里就不详细阐述。
网络设备容量管理。随着技术进步，数据中心的网络不断得到优化和调整，服务器的整合趋势，使得数据中心数量的增长速度低于服务器保有量的增长速度，并更倾向于高密度的服务器设备。同时云计算的不断发展，要求网络设备具备更高端口密度和延时。网络设备的容量依赖于业务需求，同时要满足公司业务快速发展，变化的需要。常用的几个参考：业务规模，网络架构，基础环境。
带宽容量管理。传统的网络模型是为了解决DC内部之间以及对外信息传递而建立的，遵循2/8规则。随着云计算的出现，流量的定向越来越弱化，不定向的突发流量会成为一种典型的特征，导致原有网络模型发生变化，对DC间的流量要求会越来越高。DC内带宽管理依赖于现有的网络模型，当收敛比达到DC内部1:1时，DC内部的瓶颈就是“多打一”的情况。而DC间的带宽现有情况下往往达不到1:1，需要合理部署QoS来保障重要业务，依赖监控系统及时发现瓶颈并扩容。
五、网络服务管理
1、网络层提供的服务
作为数据中心的通讯和互联基础，网络层提供的服务包括：
（1）具有一定质量保障的连通性，比如：
达到高可用性（99.999%）或近似达到高可用性；
一定范围之内的时延，比如北京、广州两数据中心之间的时延 50ms；
丢包率低于一定的阀值，如小于0.05%；
抖动在一定的范围内。
（2）为互联网连接提供有效的地址空间，比如：
为需要面向互联网提供服务的服务器提供有效的公网地址，或地址翻译；
为应用提供全球的负载均衡和流量调度服务；
为以上服务提供面向用户的支持与保障。
2、明确服务接口与服务指标
网络运营团队要与相关的团队制定明确的服务接口，并制订详细的服务指标。另外，如果可以，建议网络团队把服务内容和服务指标加入整个基础架构的服务目录中。
3、网络服务的度量
网络服务中可用性的度量，见以上关于网络可用性度量的论述，此处不再赘述。其它指标的度量方法，应在指标设计或服务质量协议拆解时明确下来，以便有效地进行度量。
（本文节选自《数据中心运维管理技术白皮书》如需购买或转载请留下您的联系电话及邮箱发送留言至本，将有工作人员与您联系）
ID：chinadcc=td】
