IT设备的救命稻草-如何正确构建OOB带外网络
现实生活中,无论是传统的大型园区网络,运营商。或是现今流行的数据中心、虚拟化等技术,往往归根结底都是大量的网络设备以及服务器堆叠而成。自然而然,当网络或者服务器因为软件故障或者人为操作失误的原因导致系统宕机后,如何第一时间登陆到故障设备,并快速恢复业务已经成为考验运维人员的一大难题。
其实,试想如果网络中存在一个完善的OOB带外网络,在故障发生时,网络控制中心可通过此网络登录网络设备或者服务器的带外管理接口或者Console接口。从而第一时间获取故障信息并予以修正,或者收集log文件上报厂家。岂不美哉?
OOB网络定义及现网问题分析
在详细介绍解决方案之前,先明确什么是OOB带外网络。
OOB全称Out Of Band,而OOB带外网络是指:通过一套与任何业务数据网络没有关联的独立网络,网络控制中心可以连接到各个服务器或者网络设备的管理接口或者console。此管理流量不会因业务数据网络重大故障而受其影响,故称之为带外网络。与之相对于的则是带内网络。
为什么需要OOB网络?
对很多企业或者运营商来说,当进行计划性的远端网络或系统维护时,往往会提前安排远端值班人员或者临时驻场工程师随时待命。若因为软件Bug等情况导致系统无法启动时,驻场工程师到达现场并连接带外接口或者console,协助远端操作工程师进行故障排查及业务恢复。
此方法存在的两个弊端:
一方面驻场工程师经验资质可能低于远端执行计划事务的工程师,从而导致故障排查进度缓慢,故障时间延长。最总影响网络KPI以及非常糟糕的客户使用体验。
另一方面,无论是值班人员或者驻场工程师都存在项目成本问题,长期来说,每一次计划性的维护都需要一个驻场人员待命。但其实多数维护工作并不一定就会产生严重的故障,可是为了“万一”两字,也需要驻场工程师支持。
对于网络规模较大,业务节点分布全国的大型企业甚至运营商来说,这些问题会被不断放大。试想某企业的北京总部为了管理公司全国的网络节点,没有OOB网络而通过大量的驻场工程师协助维护将是一件费时费力的事情。
解决方案
如果此时引入OOB网络,无论是执行计划维护的工程师还是日常运维工程师,OOB就如一颗定心丸。一旦出现任何意外事故,工程师可以立即通过OOB网络登录远端故障设备立即排查故障,并及时恢复业务。所以OOB网络从某种程度上可算的上是IT设备的救命稻草。
真OOB?假OOB?
也许有朋友会问到,我司的设备所有带外接口和console接口也都通过网络设备互联起来了,我们可以随时随地通过带外接口或者console接口登录设备。
但是,依我多年经验发现,很多企业为了节省管理成本。仅仅是简简单单把带外接口以及console-以太网转换设备直连到业务交换机或者路由器上。
当企业网络工作正常时,一切相安无事。试想如出现任何网络故障时,则极有可能波及此“带外管理”和console接口设备,从而导致这些“带外设备”形同虚设。
此为假OOB网络!
如何正确构建OOB网络
为正确构建OOB网络,我们需要遵循如下要求:
1). 此OOB网络需要与业务网络完全独立。
如何实现与业务网络完全独立?
对企业来说,如果购买了运营商A的业务网络。则可以通过购买运营商B的广域网接入服务接入全国重要网络节点的OOB网络,以及连接到公司总部OOB核心节点。
对于运营商来说,可以重新铺设独立的OOB光纤网络。或者租用其他运营商的广域网构建其独立的OOB网络。
2). 网络需要覆盖企业或者运营商所有的重要网络节点,无论国内还是国际节点。
所谓的重要网络节点是指那些如果出现故障会引起区域范围的严重服务中断,例如企业的某远程节点机房核心交换机或路由器。而对运营商来说,可能是某PE路由器,P路由器或者BNG等。
那什么是国际节点?随着越来越多的中国公司走出国门。在海外设置分支机构的公司屡见不鲜。所以对于国内总部来说,远端OOB网络管理海外节点尤其重要。同样对于运营商上来说,也存在很多海外PE路由器等。这些都是需要被OOB网络保护的对象。
与境内OOB节点不同的是,我们很难找到一个独立的运营商帮助构建一个涵盖国内和国际节点的OOB网络。这个时候就需要借助Internet来连接海外OOB节点。总部OOB网络站点可以连接本地运营商的Internet。而海外OOB站点可以通过连接当地运营商从而获得Internet接入。
3). 当连接国际节点时,需要有安全的通信机制来保障OOB网络的私密性。
上面提到需要用Internet来保证国际节点的通信。而Internet本身是不被信任的,同时日常工作中,网管数据大部分均为明文数据,为了解决此问题我们需要有一套安全机制来保证国内总部OOB网络与国外分支OOB设备的通信是安全可靠的。
4).7x24的高可用性。
5.) 通过OOB网络能够连接到网络设备的带外接口、系统设备的iLO口,以及最重要的console 口等管理接口。
6). 具备监控节点环境的功能,例如但不限于:机柜前后门的开关监控,机柜温度监控等。
监控节点环境和监控设备软件方面的健康同样重要。只有保证设备的物理安全才存在软件方面的设备监控。例如我们需要监控机柜门是否在未授权的情况下开启或者关闭,如果此情况发生,总部管理员会收到相关的告警提示等。
OOB网络设备选型
与业务网络设备类似,OOB网络也需要对于的网络设备来支撑。但相比业务网络,OOB网络存在如下特性:
· 低带宽,ssh/telnet/SNMP等管理流量占用带宽很低。偶尔会存在带外FTP或者SCP传输升级文件等情况,但是总的来说对吞吐量要求不高。
· 有一定的安全性要求,支持防火墙功能,支持IPsec***等。
而console转以太网设备,正如上文OOB要求中提到,除基本的以太网转console功能以外,还需要环境温度检测,以及通过DIO接口配合小型触发开关来检测机柜门的开关动作。
#选型示例#
通过分析,选型如下(以Juniper为例):
OOB网络路由器:
总部:SRX300 x2 组成Cluster模式,支持1Gbps光纤。
Juniper最新款企业级低端防火墙,支持所有路由器协议(例如:RIP, OSPF, BGP等),交换功能,以及作为防火墙本身细颗粒度的安全策略等。全1Gbps 以太网口以及1Gbps 光口。
分支机构:SRX110 100Mbps 以太网上联或者ADSL、VDSL上联。
与SRX300类似,支持所有路由协议,支持交换以及防火墙功能。同时由于有RJ11接口,支持xDSL服务。以太网口为100Mbps。
OOB Console转换器:(以Opengear为例)
分支机构:Opengear 远端网关,根据console口数量不同,型号也不同。支持温度传感器以及DIO编程接口。
(注:下图的Opengear 甚至支持3G/4G,在某些不具备有线OOB网络连接的地方,例如某些户外站点可以使用3G/4G版本的Opengear做到远程OOB网络管理。)
以上仅是选型示例。当然,你可以根据自身需求以及当地市场情况采用类似的产品来实现一样的效果。
网络设计
设备选型完成以后,接下来就是网络设计阶段,根据OOB网络需求分析,得出如下网络框架,如下图:
技术细节
OOB设备数量
OOB设备数量包含SRX110设备数量以及Opengear 数量,两者的区别在于,SRX110除了预留一个接口连接Opengear的以太网接口以外,剩余的以太网接口将用于连接业务设备的带外管理接口,例如Juniper设备的FXP0接口。
基于此,工程师需要统计每一个远程OOB站点需要接入多少业务设备,每一个设备存在多少个带外管理接口或iLo接口,此决定了所需SRX110接口数量,若业务设备带外管理口数量超过SRX110的以太网接口数,我们可以通过下挂二层交换机的方法解决接口短缺。
同时,工程师也需要统计每个站点需要接入OOB网络的业务设备console数量。并根据此数量购买相应的Opengear设备。
子网划分
在OOB网络中,有如下几个地方需要IP地址:
1. 每一个远端OOB站点(国内和国际)需要一个独立的子网用于SRX110下挂子网网关,Opengear以太网接口需要一个IP地址作为console登陆地址,以及业务设备带外接口IP。
2. 国内远端OOB站点SRX110与OOB中心路由器SRX300之间,需要点对点的IP地址来做到互联互通。
3. 在网管中心与OOB中心节点SRX300之间需要建立点对点互联。此处也需要IP地址。
4. 最后就是互联网Internet IP地址。SRX300 需要向本地运营商申请互联网Internet点对点IP地址。而海外OOB节点也同样需要从当地的运营商申请Internet IP地址。
互联互通
三层路由互联方面,国内OOB网络和国际OOB网络实现细节不尽相同。
先从国内OOB网络说起:
由于使用了运营商B的广域网来连接各个OOB节点。根据运营商B提供的网络服务不同,可以采用不同的路由协议。
存在下面两种情况:
1. 若运营商B根据每一个OOB站点分配一个VLAN ID,此VLAN ID最终二层透传到总部OOB网络SRX300(在运营商此为L2***技术)。此种情况下,SRX300配置为点到多点P2MP型接口来连接所有国内远程站点。并在点到多点P2MP上运行OSPF协议,从而让总部能够学习到所有OOB站点的网段。另外,总部SRX300通过OSPF发布默认路由到每一个分支OOB网络站点。
2. 若运营商B在其内部为此OOB网路构建了一个三层VRF。所有国内远程OOB节点均通过PPPoE协议学习到运营商B的默认网关,而在OOB网络中心节点来说,由于是光纤专线,OOB网络SRX300可以与运营商B的PE运行BGP协议从而学习到所有国内远程OOB站点的网段信息。
对国际OOB站点而言
由于是通过Internet传输数据,所以保证海外OOB站点与中心OOB站点的数据通信安全可靠非常重要。自然而然IPsec *** Site to Site是最好的选择。通过在海外站点与中心站点之间建立IPsec 隧道。所有网管数据例如SNMP,FTP,telnet等明文数据均被很好的保护起来。
而为了实现中心OOB网络站点与海外站点的互联互通,取决于海外OOB站点的数量多少,我们可以采用点对点OSPF动态学习的方式,站点较少的情况下也可以手工指定静态路由来实现路由的互通。
总结
本文概述了OOB带外网络的定义,以及业务网和带外网分离的重要性。同时也介绍了如何构架一个安全完整的OOB网络。
在完成OOB网络构建以后,一方面减少了公司项目资源不必要的浪费,同时也大大减小了运维工程师的压力,毕竟出现软件bug等故障时,我们还有那么一根救命稻草。
谢谢大家的关注!

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
MariaDB ColumnStore一些限制和BUG总结
字段属性限制1、不支持CHARACTER SET语法MariaDB [test]> create table t1(id int,name varchar(10) CHARACTER SET utf8)-> engine=Columnstore;ERROR 1178 (42000): The storage engine for the table doesn’t support The syntax or the data type(s) is not supported by Columnstore. Please check the Columnstore syntax guide for supported syntax or data types. 2、不支持COLLATE语法MariaDB [test]> create table t1(id int)-> engine=Columnstore COLLATE=utf8_bin;ERROR 1178 (42000): The storage engine for the table doesn’t s...
- 下一篇
Kubernetes(K8S)集群管理Docker容器(部署篇)
今天这篇文章教给大家如何快速部署一套Kubernetes集群。K8S集群部署有几种方式:kubeadm、minikube和二进制包。前两者属于自动部署,简化部署操作,并且minikube只是单机测试,而kubeadm还是beta版,强烈推荐初学者使用二进制包部署,因为自动部署屏蔽了很多细节,使得对各个模块感知很少,非常不利用学习。 所以,这篇文章也是使用二进制包部署Kubernetes集群。 本章目录 一、架构拓扑图 二、环境规划 角色 IP 组件 master 192.168.0.211 etcdkube-apiserverkube-controller-managerkube-scheduler node01 192.168.0.212 kubeletkube-proxydocker node02 192.168.0.213 kubeletkube-proxydocker 环境说明: 操作系统:Ubuntu16.04 or CentOS7 Kubernetes版本:v1.8.3 Docker版本:v17.09-ce 均采用当前最新稳定版本。 关闭selinux。 三、部署集群 3....
相关文章
文章评论
共有0条评论来说两句吧...