CN109005051A - 基于OpenStack的路由高可用方法和系统 - Google Patents

基于OpenStack的路由高可用方法和系统 Download PDF

Info

Publication number
CN109005051A
CN109005051A CN201810682549.1A CN201810682549A CN109005051A CN 109005051 A CN109005051 A CN 109005051A CN 201810682549 A CN201810682549 A CN 201810682549A CN 109005051 A CN109005051 A CN 109005051A
Authority
CN
China
Prior art keywords
harouter
agent
virtual router
openstack
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201810682549.1A
Other languages
English (en)
Inventor
卢永忠
施卫忠
高明星
孙远运
颜昌盛
刘洋
胡小宁
饶伟
王敏红
杜雅红
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
SINORAIL HONGYUAN (BEIJING) SOFTWARE TECHNOLOGY Co Ltd
China Railway Information Technology Co Ltd
Original Assignee
SINORAIL HONGYUAN (BEIJING) SOFTWARE TECHNOLOGY Co Ltd
China Railway Information Technology Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by SINORAIL HONGYUAN (BEIJING) SOFTWARE TECHNOLOGY Co Ltd, China Railway Information Technology Co Ltd filed Critical SINORAIL HONGYUAN (BEIJING) SOFTWARE TECHNOLOGY Co Ltd
Priority to CN201810682549.1A priority Critical patent/CN109005051A/zh
Publication of CN109005051A publication Critical patent/CN109005051A/zh
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0654—Management of faults, events, alarms or notifications using network fault recovery
    • H04L41/0663—Performing the actions predefined by failover planning, e.g. switching to standby network elements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/10—Active monitoring, e.g. heartbeat, ping or trace-route
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/56—Provisioning of proxy services

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Environmental & Geological Engineering (AREA)
  • Health & Medical Sciences (AREA)
  • Cardiology (AREA)
  • General Health & Medical Sciences (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

发明涉及基于OpenStack的路由高可用方法和系统。该方法包括：每隔预设的时间间隔，接收每个Harouter‑agent发送来的网络状态信息，根据网络状态信息，判断是否存在网卡故障，响应于已判断出存在网卡故障，则向Harouter‑agent发送隔离请求，调用Neutorn模块的应用程序接口删除原有虚拟路由器并在其他可用网络节点上重新创建虚拟路由器。本发明通过按照预设的时间间隔，定时查询虚拟路由器所在物理机的网卡状态，当物理网卡故障或者物理网络故障时，将虚拟路由器迁移到其他可用网络节点，保证云主机的正常运行。

Description

基于OpenStack的路由高可用方法和系统
技术领域
本发明涉及通信技术领域，具体而言，本发明涉及基于OpenStack的路由高可用方法和系统。
背景技术
路由器(Router)又称网关设备(Gateway)，用于连接多个逻辑上分开的网络，是整个网络的核心。所谓逻辑网络代表一个单独的网络或者一个子网。当数据从一个子网传输到另一个子网时，可通过路由器的路由功能来完成。因此，路由器具有判断网络地址和选择IP路径的功能，路由器能够在多网络互联环境中，建立灵活的连接，可通过完全不同的数据分组和介质访问方法连接各种子网。路由器可以接受源站或其他路由器的信息，属网络层的一种互联设备。
在使用单路由器的情况下，如果路由器发生致命性的故障，将导致本地网络的瘫痪，如果是骨干路由器发生严重故障，影响的范围将更大，所造成的损失也是难以估计的。因此，实现路由器高可用是提高网络可靠性的必然选择。“高可用性”(High Availability)通常来描述一个系统经过专门的设计，从而减少停工时间，而保持其服务的高度可用性。
当物理机上的业务网卡出现问题时，虚拟路由器会出现故障，所有连接此虚拟路由器的云主机将断掉与外部网络的通信，从而影响业务。因此，如何在物理网卡故障或者物理网络故障时，通过有效地技术手段，保证云主机的业务不会受到影响，已成为当前网络安全和通信领域亟待解决的技术问题。
发明内容
本发明针对现有技术中存在的缺陷和问题，提出一种基于OpenStack的路由高可用方法和系统。本发明通过按照预设的时间间隔，定时查询虚拟路由器所在物理机的网卡状态，当物理网卡故障或者物理网络故障时，将虚拟路由器迁移到其他可用网络节点，保证云主机的正常运行。
本发明技术方案：
本发明实施例提供一种基于OpenStack的路由高可用方法，包括以下步骤：
每隔预设的时间间隔，接收每个Harouter-agent发送来的网络状态信息；
根据所述网络状态信息，判断是否存在网卡故障；
响应于已判断出存在网卡故障，则向所述Harouter-agent发送隔离请求，调用Neutorn模块的应用程序接口删除原有虚拟路由器并在其他可用网络节点上重新创建虚拟路由器。
优选地，该方法还包括，在向所述Harouter-agent发送隔离请求之后，通知Harouter-agent删除虚拟路由器。
优选地，该方法还包括：
根据所述网络状态信息，若判断出不存在网卡故障，则测试与Harouter-agent节点的连通性；
当节点连通性正常时，不做任何处理；
当节点连通性异常时，则调用Neutron模块的应用程序接口，使得删除原有虚拟路由器并在其他可用网络节点上重新创建虚拟路由器。
进一步地，所述网络状态信息，包括可表征虚拟路由器运行状态的心跳信息；以及，
所述根据所述网络状态信息，判断是否存在网卡故障，具体包括：根据通过消息队列依次传来的多个心跳信息，判断是否连续接收到三个表征网卡故障的心跳信息；
若判断结果为是，则认为存在网卡故障。
具体地，所述Harouter-agent部署在网络节点上。
具体地，所述每隔预设的时间间隔，具体包括：每隔10秒钟间隔。
基于同一发明构思，本发明实施例还提供一种基于OpenStack的路由高可用系统，其特征在于，该系统包括：
高可用路由监控器Harouter-monitor和高可用代理节点Harouter-agent，
所述高可用路由监控器Harouter-monitor，在每隔预设的时间间隔，接收每个Harouter-agent发送来的网络状态信息，根据所述网络状态信息，判断是否存在网卡故障；
高可用代理节点Harouter-agent，接收所述高可用路由监控器Harouter-monitor做出的判断出存在网卡故障的响应信息，接收所述高可用路由监控器Harouter-monitor发来的隔离请求，根据所述响应信息，调用Neutorn模块的应用程序接口删除原有虚拟路由器。
优选地，该系统还包括可在其他可用网络节点上重新创建虚拟路由器的Neutorn模块。
优选地，所述高可用路由监控器Harouter-monitor，在向所述Harouter-agent发送隔离请求之后，通知Harouter-agent删除原有虚拟路由器。
本发明技术效果：
1.本发明实施例通过按照预设的时间间隔，定时查询虚拟路由器所在物理机的网卡状态，当出现网卡故障或者网络不通时，隔离本物理机的所有网络并在其他可用网络节点上重建虚拟路由器，成功保障了云主机的业务不受到影响，获得提高网络可用性的良好技术效果。
2.本发明实施例在一个可用网络节点故障但是虚拟路由器尚可提供服务的情况下，在其他可用网络节点上重建虚拟路由器，排除了因为不相关故障而造成网络终端的隐患。
3.本发明实施例基于OpenStack，无需额外的硬件或者软件来支持，减少了维护新硬件或者软件的成本。
附图说明
本发明上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中：
图1是本发明实施例基于OpenStack的路由高可用方法的流程示意图。
图2是本发明实施例基于OpenStack的路由高可用系统的逻辑结构示意图。
图3是本发明实施例基于OpenStack的路由高可用系统的一个实例的示意图。
具体实施方式
下面详细描述本发明的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本发明，而不能解释为对本发明的限制。
下面先对本申请涉及到的技术名词做一介绍。
OpenStack是一个开源的云计算管理平台项目，由几个主要的组件组合起来完成具体工作。OpenStack支持几乎所有类型的云环境，项目目标是提供实施简单、可大规模扩展、丰富、标准统一的云计算管理平台。OpenStack通过各种互补的服务提供了基础设施即服务(IaaS)的解决方案，每个服务提供API(应用程序接口)以进行集成。本发明正是基于该OpenStack平台所研发的创新成果。
neutron是OpenStack的一个重要模块，Neutron可以实施网络和地址管理，Neutron也是OpenStack核心项目之一，可以提供云计算环境下的虚拟网络功能。
neutron可以用来创建虚拟网络。所谓虚拟网络，就是虚拟机启动的时候会有一个虚拟网卡，虚拟网卡会连接到虚拟的switch(转换模块)上，虚拟的switch(转换模块)连接到虚拟的route(路由器)上，虚拟的router(路由器)最终和物理网卡联通，从而虚拟网络和物理网络联通起来。
Neutron能够管理OpenStack环境中的虚拟网络，是OpenStack的一个基础性关键服务，高可用(HA)和扩展性是它的基本需求之一。如果两个不同网段的虚拟机需要互相访问或者内网网段的虚拟机需要访问外网，就需要创建虚拟路由器。Neutron的L3Agent节点服务提供了虚拟路由器的功能。
agent指能自主活动的软件或者硬件实体。
本发明实施例包括两种服务，harouter-monitor和harouter-agent。其中harouter-monitor部署在控制节点，负责监控各个agent的状态，并在agent状态出现异常时进行虚拟路由器的切换。Harouter-agent服务运行在各个网络节点，负责监控各个网卡的状态并实时上报。
图1是本发明实施例基于OpenStack的路由高可用方法的流程示意图。结合图1可知，本发明实施例提供一种基于OpenStack的路由高可用方法，该方法包括以下步骤：
步骤S101，每隔预设的时间间隔，接收每个Harouter-agent发送来的网络状态信息。
优选地，网络状态信息，包括可表征虚拟路由器运行状态的心跳信息。
优选地，每隔预设的时间间隔，包括，每隔10秒钟间隔。
步骤S102，根据网络状态信息，判断是否存在网卡故障。
优选地，根据通过消息队列依次传来的多个心跳信息，判断是否连续接收到三个表征网卡故障的心跳信息。
若判断结果为是，则认为存在网卡故障。
步骤S103，响应于已判断出存在网卡故障，则向Harouter-agent发送隔离请求，调用Neutorn模块的应用程序接口删除原有虚拟路由器并在其他可用网络节点上重新创建虚拟路由器。
优选地，步骤S103中，还包括在向Harouter-agent发送隔离请求之后，通知Harouter-agent删除虚拟路由器。
优选地，还包括：根据所述网络状态信息，若判断出不存在网卡故障，则测试与Harouter-agent节点的连通性。
当节点连通性正常时，不做任何处理；当节点连通性异常时，则调用Neutron模块的应用程序接口，使得删除原有虚拟路由器并在其他可用网络节点上重新创建虚拟路由器。
有选地，Harouter-agent部署在网络节点上。
基于同一发明构思，本申请实施例还提供一种基于OpenStack的路由高可用系统，图2是本发明实施例基于OpenStack的路由高可用系统的逻辑结构示意图。该系统20包括高可用路由监控器Harouter-monitor201和高可用代理节点Harouter-agent202。其中，
高可用路由监控器Harouter-monitor201，在每隔预设的时间间隔，接收每个Harouter-agent发送来的网络状态信息，根据网络状态信息，判断是否存在网卡故障。
具体地，每隔10秒钟，通过消息队列，接收每个harouter agent上报上来的心跳信息。如果harouter agent上报的心跳信息里连续三次有网卡故障，则发送隔离请求给harouter agent，让harouter agent删除虚拟路由器，并停掉物理机上的出现故障的网络节点L3Agent，同时调用Neutorn模块的应用程序接口删除原有虚拟路由器并在其他可用的网络节点L3Agent上重新创建虚拟路由器。
如果连续三次没有收到harouter agent上报的心跳，则测试与harouter agent节点的连通性(例如，连通性使用fping来实现)，如果连通性没有问题，则判断是harouteragent本身出问题，不做任何处理。如果不能与harouter agent连通，则调用Neutron模块的应用程序接口删除原有虚拟路由器并在其他可用的L3Agent节点上重新创建虚拟路由器。
高可用代理节点Harouter-agent202，接收高可用路由监控器Harouter-monitor201做出的判断出存在网卡故障的响应信息，接收高可用路由监控器Harouter-monitor201发来的隔离请求，根据响应信息，调用Neutorn模块的应用程序接口删除原有虚拟路由器。
可选地，该系统还包括可在其他可用网络节点上重新创建虚拟路由器的Neutorn模块。
可选地，高可用路由监控器Harouter-monitor，在向Harouter-agent发送隔离请求之后，通知Harouter-agent删除原有虚拟路由器。
具体地，每隔10秒钟，Harouter-agent检测所有网卡的状态，并上报给Harouter-monitor。
若收到harouter monitor发送来的隔离请求，则删除物理机上所有的namespace(namespace代表承载虚拟路由器的技术)，并停用物理机上的出现故障的L3Agent节点。
Harouter-agent每次上报心跳都会收到harouter monitor的返回信息，如果三次上报心跳失败，则测试与harouter monitor节点的连通性(连通性测试使用fping来实现)。若连通性没有问题，则判断是harouter monitor本身出现问题，不做任何操作。如果不能与harouter monitor连通，则删除物理机上所有的namespace(承载虚拟路由器的技术)，并停用物理机上的出故障的L3Agent节点。
图3是本发明实施例基于OpenStack的路由高可用系统的一个实例的示意图。
harouter-monitor部署在控制节点，负责监控各个agent的状态，并在agent状态出现异常时进行虚拟路由器的切换。Harouter-agent服务运行在各个网络节点，负责监控各个网卡的状态并实时上报。
控制节点与管理网通信连接，多个计算节点(例如图3中的计算节点1和计算节点2)与业务网通信连接。
控制节点对应有多个应用，计算节点对应多个agent。
本发明实施例通过按照预设的时间间隔，定时查询虚拟路由器所在物理机的网卡状态，当出现网卡故障或者网络不通时，隔离本物理机的所有网络并在其他可用网络节点上重建虚拟路由器，成功保障了云主机的业务不受到影响，获得提高网络可用性的良好技术效果。
本技术领域技术人员可以理解，除非特意声明，这里使用的单数形式“一”、“一个”、“所述”和“该”也可包括复数形式。应该进一步理解的是，本发明的说明书中使用的措辞“包括”是指存在所述特征、整数、步骤、操作、元件和/或组件，但是并不排除存在或添加一个或多个其他特征、整数、步骤、操作、元件、组件和/或它们的组。应该理解，当我们称元件被“连接”或“耦接”到另一元件时，它可以直接连接或耦接到其他元件，或者也可以存在中间元件。此外，这里使用的“连接”或“耦接”可以包括无线连接或无线耦接。这里使用的措辞“和/或”包括一个或更多个相关联的列出项的全部或任一单元和全部组合。
本技术领域技术人员可以理解，除非另外定义，这里使用的所有术语(包括技术术语和科学术语)，具有与本发明所属领域中的普通技术人员的一般理解相同的意义。还应该理解的是，诸如通用字典中定义的那些术语，应该被理解为具有与现有技术的上下文中的意义一致的意义，并且除非像这里一样被特定定义，否则不会用理想化或过于正式的含义来解释。
本技术领域技术人员可以理解，可以用计算机程序指令来实现这些结构图和/或框图和/或流图中的每个框以及这些结构图和/或框图和/或流图中的框的组合。本技术领域技术人员可以理解，可以将这些计算机程序指令提供给通用计算机、专业计算机或其他可编程数据处理方法的处理器来实现，从而通过计算机或其他可编程数据处理方法的处理器来执行本发明公开的结构图和/或框图和/或流图的框或多个框中指定的方案。
本技术领域技术人员可以理解，本发明中已经讨论过的各种操作、方法、流程中的步骤、措施、方案可以被交替、更改、组合或删除。进一步地，具有本发明中已经讨论过的各种操作、方法、流程中的其他步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。进一步地，现有技术中的具有与本发明中公开的各种操作、方法、流程中的步骤、措施、方案也可以被交替、更改、重排、分解、组合或删除。
以上所述仅是本发明的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (9)

1.一种基于OpenStack的路由高可用方法，其特征在于，包括以下步骤：
每隔预设的时间间隔，接收每个Harouter-agent发送来的网络状态信息；
根据所述网络状态信息，判断是否存在网卡故障；
响应于已判断出存在网卡故障，则向所述Harouter-agent发送隔离请求，调用Neutorn模块的应用程序接口删除原有虚拟路由器并在其他可用网络节点上重新创建虚拟路由器。
2.根据权利要求1所述的基于OpenStack的路由高可用方法，其特征在于，还包括，在向所述Harouter-agent发送隔离请求之后，通知Harouter-agent删除虚拟路由器。
3.根据权利要求1所述的基于OpenStack的路由高可用方法，其特征在于，还包括：
根据所述网络状态信息，若判断出不存在网卡故障，则测试与Harouter-agent节点的连通性；
当节点连通性正常时，不做任何处理；
当节点连通性异常时，则调用Neutron模块的应用程序接口，使得删除原有虚拟路由器并在其他可用网络节点上重新创建虚拟路由器。
4.根据权利要求1所述的基于OpenStack的路由高可用方法，其特征在于，所述网络状态信息，包括可表征虚拟路由器运行状态的心跳信息；以及，
所述根据所述网络状态信息，判断是否存在网卡故障，具体包括：根据通过消息队列依次传来的多个心跳信息，判断是否连续接收到三个表征网卡故障的心跳信息；
若判断结果为是，则认为存在网卡故障。
5.根据权利要求1所述的基于OpenStack的路由高可用方法，其特征在于，所述Harouter-agent部署在网络节点上。
6.根据权利要求1所述的基于OpenStack的路由高可用方法，其特征在于，所述每隔预设的时间间隔，具体包括：每隔10秒钟间隔。
7.一种基于OpenStack的路由高可用系统，其特征在于，该系统包括：
高可用路由监控器Harouter-monitor和高可用代理节点Harouter-agent，
所述高可用路由监控器Harouter-monitor，在每隔预设的时间间隔，接收每个Harouter-agent发送来的网络状态信息，根据所述网络状态信息，判断是否存在网卡故障；
高可用代理节点Harouter-agent，接收所述高可用路由监控器Harouter-monitor做出的判断出存在网卡故障的响应信息，接收所述高可用路由监控器Harouter-monitor发来的隔离请求，根据所述响应信息，调用Neutorn模块的应用程序接口删除原有虚拟路由器。
8.根据权利要求7所述的基于OpenStack的路由高可用系统，其特征在于，还包括可在其他可用网络节点上重新创建虚拟路由器的Neutorn模块。
9.根据权利要求7所述的基于OpenStack的路由高可用系统，其特征在于，所述高可用路由监控器Harouter-monitor，在向所述Harouter-agent发送隔离请求之后，通知Harouter-agent删除原有虚拟路由器。
CN201810682549.1A 2018-06-27 2018-06-27 基于OpenStack的路由高可用方法和系统 Pending CN109005051A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810682549.1A CN109005051A (zh) 2018-06-27 2018-06-27 基于OpenStack的路由高可用方法和系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810682549.1A CN109005051A (zh) 2018-06-27 2018-06-27 基于OpenStack的路由高可用方法和系统

Publications (1)

Publication Number Publication Date
CN109005051A true CN109005051A (zh) 2018-12-14

Family

ID=64601885

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810682549.1A Pending CN109005051A (zh) 2018-06-27 2018-06-27 基于OpenStack的路由高可用方法和系统

Country Status (1)

Country Link
CN (1) CN109005051A (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110392111A (zh) * 2019-07-24 2019-10-29 华云超融合科技有限公司 一种基于数据中心的智能虚拟分布式路由器集群系统及其实现方法
CN111399978A (zh) * 2020-03-02 2020-07-10 中铁信弘远(北京)软件科技有限责任公司 一种基于OpenStack的故障迁移系统及迁移方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103607296A (zh) * 2013-11-01 2014-02-26 杭州华三通信技术有限公司 一种虚拟机故障处理方法和设备
WO2016011953A1 (en) * 2014-07-25 2016-01-28 Hangzhou H3C Technologies Co., Ltd. Scheduling of service resource
CN105915400A (zh) * 2016-06-28 2016-08-31 北京神州绿盟信息安全科技股份有限公司 一种数据流切换方法及系统
CN107770062A (zh) * 2016-08-16 2018-03-06 北京金山云网络技术有限公司 一种数据包发送方法、装置及网络架构

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103607296A (zh) * 2013-11-01 2014-02-26 杭州华三通信技术有限公司 一种虚拟机故障处理方法和设备
WO2016011953A1 (en) * 2014-07-25 2016-01-28 Hangzhou H3C Technologies Co., Ltd. Scheduling of service resource
CN105915400A (zh) * 2016-06-28 2016-08-31 北京神州绿盟信息安全科技股份有限公司 一种数据流切换方法及系统
CN107770062A (zh) * 2016-08-16 2018-03-06 北京金山云网络技术有限公司 一种数据包发送方法、装置及网络架构

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
董丽昕: "OpenStack集群高可用方案设计与实现", 《中国优秀硕士学位论文全文数据库 信息科技辑》 *

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN110392111A (zh) * 2019-07-24 2019-10-29 华云超融合科技有限公司 一种基于数据中心的智能虚拟分布式路由器集群系统及其实现方法
CN110392111B (zh) * 2019-07-24 2022-03-15 江苏安超云软件有限公司 一种基于数据中心的智能虚拟分布式路由器集群系统及其实现方法
CN111399978A (zh) * 2020-03-02 2020-07-10 中铁信弘远(北京)软件科技有限责任公司 一种基于OpenStack的故障迁移系统及迁移方法

Similar Documents

Publication Publication Date Title
US6674724B1 (en) Integrated telecommunications test system
EP2458797A1 (en) Method, device and system for updating ring network topology information
JPH05502347A (ja) パケット網における自動的な障害回復
CN104243205A (zh) 一种虚拟交换机故障时的报文处理方法和设备
EP1585299B1 (en) Providing applets to remote devices in a communications network
US20030069959A1 (en) Alarm lists synchronization in an alarm management system
CN101834687A (zh) 光接入网络的主备倒换方法、系统和设备
CN109656753A (zh) 一种应用于轨道交通综合监控系统的冗余热备系统
CN101227333B (zh) 一种容灾网管系统及其网管客户端的登陆方法
CN109005051A (zh) 基于OpenStack的路由高可用方法和系统
JP2001127761A (ja) Ｍｐｌｓ通信方式における通信データ確認試験方法及びその方法を利用するルータ，交換機，通信システム
CN101145972B (zh) 一种容灾网管系统及其网管客户端的登陆方法
KR20150002474A (ko) 통신 네트워크에서 장애 복구 방법
EP2485438B1 (en) Protection method for subscriber access network and equipment thereof
US9258194B2 (en) Method and apparatus to display a transport service between point A and point Z
KR101563133B1 (ko) 동적 멀티 도메인 환경에서 가상 회선 보호를 위한 시스템 및 방법
US8560668B2 (en) Alarm correlation system
CN103299584A (zh) 用于在暂时性失去连接之后优化网络性能的方法
CN102487332A (zh) 故障处理方法、装置和系统
US20100304736A1 (en) Method and apparatus to enable high availability UMTS radio access networks by dynamically moving Node B links among RNCs
CN111666170B (zh) 基于分布式框架的故障节点处理方法及装置
US7958386B2 (en) Method and apparatus for providing a reliable fault management for a network
KR0173380B1 (ko) 분산형 액세스 노드 시스템에서의 성능관리 방법
CN105978803A (zh) 一种网络数据路由备份方法
Cohen et al. Unified network management from AT&T

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20181214