CN109150589A - 基于Open Stack虚拟网络阻塞异常的处理方法及*** - Google Patents

基于Open Stack虚拟网络阻塞异常的处理方法及*** Download PDF

Info

Publication number
CN109150589A
CN109150589A CN201810828585.4A CN201810828585A CN109150589A CN 109150589 A CN109150589 A CN 109150589A CN 201810828585 A CN201810828585 A CN 201810828585A CN 109150589 A CN109150589 A CN 109150589A
Authority
CN
China
Prior art keywords
network
sflow
node
calculate node
open stack
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
CN201810828585.4A
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.)
CERNET Corp
Original Assignee
CERNET Corp
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 CERNET Corp filed Critical CERNET Corp
Priority to CN201810828585.4A priority Critical patent/CN109150589A/zh
Publication of CN109150589A publication Critical patent/CN109150589A/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/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/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H04L43/0829—Packet loss
    • 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/0876—Network utilisation, e.g. volume of load or congestion level

Landscapes

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

Abstract

本发明提供了一种基于Open Stack虚拟网络阻塞异常的处理方法及***。所述方法包括：S1,在Open Stack云平台中的控制节点和至少两个计算节点上部署sFlow‑RT，所述sFlow‑RT用于对所述至少两个计算节点进行网络流量监测，得到流量监测数据；S2,根据所述流量监测数据，获取在预设时间内每个所述计算节点的网络丢包率；S3,根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起；若是，调用所述Open Stack云平台管理工具puppet对网络阻塞的所述计算节点服务进行重启。

Description

基于Open Stack虚拟网络阻塞异常的处理方法及***
技术领域
本发明涉及一种基于Open Stack虚拟网络阻塞异常的处理方法及***。
背景技术
随着信息技术的快速发展，云计算也得到了极大的发展，多种云计算平台应运而生。OpenStack作为一种云计算平台，为云计算基础设施服务提供解决方案，OpenStack以其全开源、易拓展的特点，赢得业界越来越多的关注。目前，许多企业为了解决资源利用率、计算能力和成本等问题，不断的把企业的应用移植到了云平台上。
图1所示为云平台的基本框架示例，其包括控制网络节点，计算节点，核心交换机，和公开网络等。其中控制网络节点包括：Keystone认证模块：用于管理用户及其权限，Authentication(认证)和Authorization(鉴权)。Neutron网络管理模块：用于提供云计算的网络虚拟化技术，为Open-stack其他服务，提供网络连接服务，为用户提供接口。OpenvSwitch虚拟交换机模块，用于通过可编程扩展，可以实现大规模网络的自动化(配置、管理、维护)。计算节点包括计算控制模块Nova compute：用于为单个用户或使用群组管理虚拟机实例的整个生命周期，根据用户需求来提供虚拟服务。
随着在云上的应用日益增多，租户的网络、虚拟机***、企业应用等由于网络阻塞导致消息队列处理超时出现虚拟机的网络故障，Openvswitch会出现假死，容易造成服务的中断，无法提供正常的服务的情况。
发明内容
(一)要解决的技术问题
随着在云上的应用日益增多，租户的网络、虚拟机***、企业应用等由于网络阻塞导致消息队列处理超时出现虚拟机的网络故障，Openvswitch会出现假死，容易造成服务的中断，无法提供正常的服务的情况。
(二)技术方案
第一方面，本发明提供了一种基于Open Stack虚拟网络阻塞异常的处理方法，包括：S1,在Open Stack云平台中的控制节点和至少两个计算节点上部署sFlow-RT，所述sFlow-RT用于对所述至少两个计算节点进行网络流量监测，得到流量监测数据；S2,根据所述流量监测数据，获取在预设时间内每个所述计算节点的网络丢包率；S3,根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起；若是，调用所述Open Stack云平台管理工具puppet对网络阻塞的所述计算节点服务进行重启。
可选地，所述步骤S1中，在Open Stack云平台中的控制节点和至少两个计算节点上部署sFlow-RT，包括：在所述控制节点中添加sFlow-RT作为sFlow控制器,在所述至少两个计算节点的第一虚拟交换机上部署sFlow收集代理,所述sFlow收集代理获取所述第一虚拟交换机上网络端口的流量数据，将所述流量监测数据以sFlow报文的形式发送给所述sFlow控制器。
可选地，所述在所述控制节点中添加sFlow-RT，包括：在所述控制节点中添加Docker容器，在所述Docker容器中添加sFlow-RT。
可选地，所述sFlow收集代理将所述流量数据发送给所述sFlow控制器包括：将所述控制节点的第二虚拟交换机与所述计算节点的第一虚拟交换机通过Vxlan隧道以及路由连通，所述sFlow收集代理通过第一虚拟交换机与第二虚拟交换机将所述流量数据发送给所述sFlow控制器。
可选地，所述步骤S2中，所述流量监测数据为所述sFlow控制器获取的sFlow报文，所述预设时间为60秒，所述计算节点的网络丢包率的公式为：网络丢包率＝(60秒内网络正常时获取的sFlow报文数量-60秒内实际获取的sFlow报文数量)/60秒内网络正常时获取的sFlow报文数量×100％。
可选地，所述步骤S3中，根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起,包括：判断每个所述计算节点的网络丢包率是否都为100％，若否，判断所述控制节点与网络丢包率为100％的所述计算节点之间的物理链路是否连通，若是，则所述Open Stack云平台虚拟网络异常由所述计算节点网络阻塞引起。
可选地，还可继续通过查看控制节点上的日志进一步所述Open Stack云平台虚拟网络异常由所述计算节点网络阻塞引起。
可选地，所述判断所述物理链路是否连通，包括：利用ping判断所述物理链路是否连通，若连续三次ping不连通，则所述物理链路不连通。
第二方面，本发明提供了一种基于Open Stack虚拟网络阻塞异常的处理的电子设备，包括：
通信器，用于与服务器通信；处理器；存储器，其存储有计算机可执行程序，该程序在被所述处理器执行时，使得所述处理器执行如上文所述基于Open Stack虚拟网络阻塞异常的处理的方法。
第三方面，本发明提供了一种基于Open Stack虚拟网络阻塞异常的处理的***，其特征在于，所述***包括：网络流量监测模块，用于在OpenStack云平台中的控制节点和至少两个计算节点上部署sFlow-RT，所述sFlow-RT用于对所述至少两个计算节点进行网络流量监测，得到流量监测数据；网络丢包率获取模块,用于根据所述流量监测数据，获取在预设时间内每个所述计算节点的网络丢包率；网络阻塞异常处理，用于根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起；若是，调用所述Open Stack云平台管理工具puppet对网络阻塞的所述计算节点服务进行重启。
第四方面，本发明提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上文所述基于Open Stack虚拟网络阻塞异常的处理的方法。
(三)有益效果
本发明通过sFlow-RT对计算节点的网络流量进行监测，将监测得到的流量监测数据进行分析，获取预设时间内的计算节点的网络丢包率。通过网络丢包率以及物理链路的连通性判断Open Stack云平台中虚拟网络的异常是否是由于计算节点的网络阻塞引起，若是，则对计算节点重启。本发明的方法能及时发现和确认由于计算节点的网络阻塞引起的网络异常问题，解决Openvswitch出现假死的问题，减少用户虚拟机网络的停用时间。
附图说明
图1是现有技术的云平台的基本框架示例；
图2是本发明实施例云平台中控制节点与其中一个计算节点的网络连接拓扑图。
具体实施方式
为使本发明的目的、技术方案和优点更加清楚明白，以下结合具体实施例，并参照附图，对本发明进一步详细说明。但是应该理解，这些描述只是示例性的，而并非要限制本发明的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本发明实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本发明的概念。
在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本发明。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。
第一方面，本发明提供了一种基于Open Stack虚拟网络阻塞异常的处理方法，包括：S1,在Open Stack M版云平台中的控制节点和至少两个计算节点上部署sFlow-RT，所述sFlow-RT用于对所述至少两个计算节点进行网络流量监测，得到流量监测数据；S2,根据所述流量监测数据，获取在预设时间内每个所述计算节点的网络丢包率；S3,根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起；若是，调用所述Open Stack云平台管理工具puppet对网络阻塞的所述计算节点服务进行重启。即调用自动化运维管理工具puppet对该故障计算节点的Openvswitch服务进行处理，自动重启Neutron-Openvswitch-Agent服务。解决由于网络阻塞导致消息队列处理超时出现虚拟机的网络故障，Openvswitch会出现假死的问题。
本领域技术人员可以理解的是，sFlow技术是一种以设备端口为基本单元的数据流采样的流量监控技术。所述sFlow-RT的部署可以通过多种方式实现，例如还可以部署于虚拟机中。本发明实施例中以在所述控制节点中添加sFlow-RT为例进行说明，其包括：在所述控制节点中添加Docker容器，在所述Docker容器中添加sFlow-RT。并且，上文步骤S1中，在Open Stack云平台中的控制节点和至少两个计算节点上部署sFlow-RT，包括：在所述控制节点中添加sFlow-RT作为sFlow控制器,在所述至少两个计算节点的第一虚拟交换机上部署sFlow收集代理,所述sFlow收集代理获取所述第一虚拟交换机上网络端口的流量数据，将所述流量监测数据以sFlow报文的形式发送给所述sFlow控制器。
可选地，所述sFlow收集代理将所述流量数据发送给所述sFlow控制器包括：将所述控制节点的第二虚拟交换机与所述计算节点的第一虚拟交换机通过Vxlan隧道以及路由连通，所述sFlow收集代理通过第一虚拟交换机与第二虚拟交换机将所述流量数据发送给所述sFlow控制器。
本发明实施例以Open Stack云平台中包含1个控制节点和3个计算节点为例进行说明：
如图2所示，其为控制节点与其中一个计算节点的网络连接拓扑图，将sFlow-RT部署并安装于Docker容器中，将Docker容器与控制节点中的第二虚拟交换机(Openvswitch)连通，通过Vxlan隧道技术将第二虚拟交换机与计算节点中的第一虚拟交换机连通。其余计算节点与该控制节点的连接方式与图2一致，本发明实施例中Linux服务器的操作***为Centos7.4，所有节点的etho接口均接入公开网络。
具体地，在1个控制节点和3个计算节点中均安装Docker社区版，Docke社区版安装后默认的网段为172.17.0.0/24,对1个控制节点和3个计算节点分别定义与上述默认网段不同的私有网络IP地址段，可以实现所有节点Docker的私有网络能够相互连通。例如，定义该1个控制节点和3个计算节点的私有网络IP地址段分别为：
控制和网络节点：
#cat/etc/docker/daemon.json
{
"bip":"172.17.78.1/24",
"ipv6":true,
"fixed-cidr-v6":"2001:da8:243:2478::/64"
}
计算节点一：
#cat/etc/docker/daemon.json
{
"bip":"172.17.79.1/24",
"ipv6":true,
"fixed-cidr-v6":"2001:da8:243:2479::/64"
}
计算节点二：
#cat/etc/docker/daemon.json
{
"bip":"172.17.80.1/24",
"ipv6":true,
"fixed-cidr-v6":"2001:da8:243:2480::/64"
}
计算节点三：
#cat/etc/docker/daemon.json
{
"bip":"172.17.81.1/24",
"ipv6":true,
"fixed-cidr-v6":"2001:da8:243:2481::/64"
}
将控制节点与计算节点之间的虚拟交换机Openvswtich vxlan隧道建立后，还需要通过路由的添加，实现Openstack云平台环境下docker私有网络之间的互联互通，实现数据的通信。上文所述几个网段的路由都需经过本机的docker0网桥路由(docker0为docker创建的本地网桥)，其中每个“/24”网段都是通过Openvswitch的VxLAN隧道到达对端的，因此需要在每个节点上添加通过docker0网桥转发172.17.0.0/16段的路由规则：ip routeadd 172.17.0.0/16dev docker0；对于IPV6网络而言，为了使所有节点的docker自定义的IPv6地址段实现在所有节点互相访问并能访问Internet，需要在Openstack云平台接入的三层交换机上添加Docker IPv6网段的回程路由：
ipv6route-static 2001:da8:243:2478::64 2001:da8:243:2400::78
ipv6route-static 2001:da8:243:2479::64 2001:da8:243:2400::79
ipv6route-static 2001:da8:243:2480::64 2001:da8:243:2400::80
ipv6route-static 2001:da8:243:2481::64 2001:da8:243:2400::81
此时将sFlow-RT安装并启动，下载sFlow-RT镜像，启动sFlow-RT镜像容器。其中，8008为web访问端口，6343为reset api数据报文接收端口，21aea3d8dda6为sFlow-RT的ID号，在Docker环境中ID号唯一。sFlow-RT的IPv4地址查询：
docker inspect--format'{{.NetworkSettings.IPAddress}}'21aea3d8dda6
172.17.78.2
sFlow-RT的IPv6地址查询：
docker inspect--format＝"{{.NetworkSettings.GlobalIPv6Address}}"21aea3d8dda6
2001:da8:243:2400:0:242:ac11:2
sFlow-RT的IPv4流量监控页面为：http://10.25.87.78:8008
sFlow-RT的IPv6流量监控页面为：http://[2001:da8:243:2400::78]:8008
可选地，所述步骤S2中，所述流量监测数据为所述sFlow控制器获取的sFlow报文，所述预设时间为60秒，所述计算节点的网络丢包率的公式为：网络丢包率＝(60秒内网络正常时获取的sFlow报文数量-60秒内实际获取的sFlow报文数量)/60秒内网络正常时获取的sFlow报文数量×100％。
可选地，所述步骤S3中，根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起,包括：判断每个所述计算节点的网络丢包率是否都为100％，若否，判断所述控制节点与网络丢包率为100％的所述计算节点之间的物理链路是否连通，若是，则所述Open Stack云平台虚拟网络异常由所述计算节点网络阻塞引起。
首先判断每个所述计算节点的网络丢包率是否都为100％，若每个计算节点的网络丢包率都为100％，则需要考虑是由上联交换机故障导致的，该判断步骤用于排除由上联交换机故障导致的所有计算节点的网络丢包率都为100％的情况。当判断出不是由于上联交换机故障引起之后，还需判断是否由于物理链路不连通造成，若所述控制节点与网络丢包率为100％的所述计算节点之间的物理链路为连通状态，则可确定Open Stack云平台虚拟网络异常由网络丢包率为100％的计算节点网络阻塞引起。另外，可选地，还可通过查看控制节点上的日志进一步确定其是否由网络阻塞引起，例如查看/var/log/neutron/l3-agent.log信息，当出现例如下列的信息：ERROR oslo.messaging._drivers.impl_rabbit[-]AMQP server on10.25.87.79:5673is unreachable:[Errno 111]ECONNREFUSED.Trying again in 1seconds；说明消息列队服务器连接不到出现问题的计算节点，不能正常处理消息列队，进一步地确定了Open Stack云平台虚拟网络异常由网络丢包率为100％的计算节点网络阻塞引起。
其中，所述判断所述物理链路是否连通，包括：利用ping判断所述物理链路是否连通，若连续三次ping不连通，则所述物理链路不连通。
第二方面，本发明提供了一种基于Open Stack虚拟网络阻塞异常的处理的电子设备，包括：
通信器，用于与服务器通信；处理器；存储器，其存储有计算机可执行程序，该程序在被所述处理器执行时，使得所述处理器执行如上文所述基于Open Stack虚拟网络阻塞异常的处理的方法。
第三方面，本发明提供了一种基于Open Stack虚拟网络阻塞异常的处理的***，其特征在于，所述***包括：网络流量监测模块，用于在OpenStack云平台中的控制节点和至少两个计算节点上部署sFlow-RT，所述sFlow-RT用于对所述至少两个计算节点进行网络流量监测，得到流量监测数据；网络丢包率获取模块,用于根据所述流量监测数据，获取在预设时间内每个所述计算节点的网络丢包率；网络阻塞异常处理，用于根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起；若是，调用所述Open Stack云平台管理工具puppet对网络阻塞的所述计算节点服务进行重启。即调用自动化运维管理工具puppet对该故障计算节点的Openvswitch服务进行处理，自动重启Neutron-Openvswitch-Agent服务。
第四方面，本发明提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如上文所述基于Open Stack虚拟网络阻塞异常的处理的方法。
以上所述的具体实施例，对本发明的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本发明的具体实施例而已，并不用于限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (10)

1.一种基于Open Stack虚拟网络阻塞异常的处理方法，包括：
S1,在Open Stack云平台中的控制节点和至少两个计算节点上部署sFlow-RT，所述sFlow-RT用于对所述至少两个计算节点进行网络流量监测，得到流量监测数据；
S2,根据所述流量监测数据，获取在预设时间内每个所述计算节点的网络丢包率；
S3,根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起；若是，调用所述Open Stack云平台管理工具puppet对网络阻塞的所述计算节点服务进行重启。
2.根据权利要求1所述的方法，所述步骤S1中，在Open Stack云平台中的控制节点和至少两个计算节点上部署sFlow-RT，包括：
在所述控制节点中添加sFlow-RT作为sFlow控制器,在所述至少两个计算节点的第一虚拟交换机上部署sFlow收集代理,所述sFlow收集代理获取所述第一虚拟交换机上网络端口的流量数据，将所述流量监测数据以sFlow报文的形式发送给所述sFlow控制器。
3.根据权利要求2所述的方法，所述在所述控制节点中添加sFlow-RT，包括：在所述控制节点中添加Docker容器，在所述Docker容器中添加sFlow-RT。
4.根据权利要求2所述的方法，所述sFlow收集代理将所述流量数据发送给所述sFlow控制器包括：将所述控制节点的第二虚拟交换机与所述计算节点的第一虚拟交换机通过Vxlan隧道以及路由连通，所述sFlow收集代理通过第一虚拟交换机与第二虚拟交换机将所述流量数据发送给所述sFlow控制器。
5.根据权利要求2所述的方法，所述步骤S2中，所述流量监测数据为所述sFlow控制器获取的sFlow报文，所述预设时间为60秒，所述计算节点的网络丢包率的公式为：
网络丢包率＝(60秒内网络正常时获取的sFlow报文数量-60秒内实际获取的sFlow报文数量)/60秒内网络正常时获取的sFlow报文数量×100％。
6.根据权利要求5所述的方法，所述步骤S3中，根据所述网络丢包率以及物理链路是否连通，判断所述Open Stack云平台虚拟网络异常是否由所述计算节点网络阻塞引起,包括：
判断每个所述计算节点的网络丢包率是否都为100％，若否，判断所述控制节点与网络丢包率为100％的所述计算节点之间的物理链路是否连通，若是，则所述Open Stack云平台虚拟网络异常由所述计算节点网络阻塞引起。
7.根据权利要求6所述的方法，所述判断所述物理链路是否连通，包括：
利用ping判断所述物理链路是否连通，若连续三次ping不连通，则所述物理链路不连通。
8.一种基于Open Stack虚拟网络阻塞异常的处理的电子设备，包括：
通信器，用于与服务器通信；
处理器；
存储器，其存储有计算机可执行程序，该程序在被所述处理器执行时，使得所述处理器执行如权利要求1-7中基于Open Stack虚拟网络阻塞异常的处理的方法。
9.一种基于Open Stack虚拟网络阻塞异常的处理的***，其特征在于，所述***包括：
网络流量监测模块，用于在Open Stack云平台中的控制节点和至少两个计算节点上部署sFlow-RT，所述sFlow-RT用于对所述至少两个计算节点进行网络流量监测，得到流量监测数据；
网络丢包率获取模块,用于根据所述流量监测数据，获取在预设时间内每个所述计算节点的网络丢包率；
网络阻塞异常处理，用于根据所述网络丢包率以及物理链路是否连通，判断所述OpenStack云平台虚拟网络异常是否由所述计算节点网络阻塞引起；若是，调用所述Open Stack云平台管理工具puppet对网络阻塞的所述计算节点服务进行重启。
10.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如权利要求1-7中基于Open Stack虚拟网络阻塞异常的处理的方法。
CN201810828585.4A 2018-07-25 2018-07-25 基于Open Stack虚拟网络阻塞异常的处理方法及*** Pending CN109150589A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201810828585.4A CN109150589A (zh) 2018-07-25 2018-07-25 基于Open Stack虚拟网络阻塞异常的处理方法及***

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201810828585.4A CN109150589A (zh) 2018-07-25 2018-07-25 基于Open Stack虚拟网络阻塞异常的处理方法及***

Publications (1)

Publication Number Publication Date
CN109150589A true CN109150589A (zh) 2019-01-04

Family

ID=64798272

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201810828585.4A Pending CN109150589A (zh) 2018-07-25 2018-07-25 基于Open Stack虚拟网络阻塞异常的处理方法及***

Country Status (1)

Country Link
CN (1) CN109150589A (zh)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111901236A (zh) * 2020-08-05 2020-11-06 烽火通信科技股份有限公司 一种利用动态路由优化openstack云网络的方法及***
CN114301868A (zh) * 2021-12-30 2022-04-08 上海观安信息技术股份有限公司 快速生成虚拟容器浮动ip的方法及网络直通的方法和装置
CN114356440A (zh) * 2021-12-21 2022-04-15 西安四叶草信息技术有限公司 ***优化方法及装置

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103825832A (zh) * 2014-03-03 2014-05-28 中国人民解放军理工大学 丢包感知的区分型拥塞控制方法
CN104378264A (zh) * 2014-12-12 2015-02-25 武汉噢易云计算有限公司 一种基于sFlow的虚拟机进程流量监控方法
CN105872110A (zh) * 2016-06-17 2016-08-17 深圳纽博时代科技有限公司 一种云平台服务管理方法及装置
CN107623611A (zh) * 2017-09-22 2018-01-23 国云科技股份有限公司 一种云平台虚拟机的流量监控***
CN108183871A (zh) * 2017-11-23 2018-06-19 北京三快在线科技有限公司 一种虚拟交换机、虚拟交换机启动方法，电子设备
WO2018113393A1 (zh) * 2016-12-21 2018-06-28 华为技术有限公司 报文传输方法及混合接入网关

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103825832A (zh) * 2014-03-03 2014-05-28 中国人民解放军理工大学 丢包感知的区分型拥塞控制方法
CN104378264A (zh) * 2014-12-12 2015-02-25 武汉噢易云计算有限公司 一种基于sFlow的虚拟机进程流量监控方法
CN105872110A (zh) * 2016-06-17 2016-08-17 深圳纽博时代科技有限公司 一种云平台服务管理方法及装置
WO2018113393A1 (zh) * 2016-12-21 2018-06-28 华为技术有限公司 报文传输方法及混合接入网关
CN107623611A (zh) * 2017-09-22 2018-01-23 国云科技股份有限公司 一种云平台虚拟机的流量监控***
CN108183871A (zh) * 2017-11-23 2018-06-19 北京三快在线科技有限公司 一种虚拟交换机、虚拟交换机启动方法，电子设备

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111901236A (zh) * 2020-08-05 2020-11-06 烽火通信科技股份有限公司 一种利用动态路由优化openstack云网络的方法及***
CN114356440A (zh) * 2021-12-21 2022-04-15 西安四叶草信息技术有限公司 ***优化方法及装置
CN114356440B (zh) * 2021-12-21 2023-11-10 西安四叶草信息技术有限公司 ***优化方法及装置
CN114301868A (zh) * 2021-12-30 2022-04-08 上海观安信息技术股份有限公司 快速生成虚拟容器浮动ip的方法及网络直通的方法和装置
CN114301868B (zh) * 2021-12-30 2023-07-11 上海观安信息技术股份有限公司 快速生成虚拟容器浮动ip的方法及网络直通的方法和装置

Similar Documents

Publication Publication Date Title
US11558426B2 (en) Connection tracking for container cluster
US10432533B2 (en) Automatic detection and prevention of network overload conditions using SDN
US9311160B2 (en) Elastic cloud networking
EP3278506B1 (en) Methods and devices for monitoring of network performance for container virtualization
US11196628B1 (en) Monitoring container clusters
US8355316B1 (en) End-to-end network monitoring
US20150188772A1 (en) Hybrid sdn controller
US20120127850A1 (en) Best-path evaluation based on reliability of network interface layers
US20100077395A1 (en) Virtual machine liveness check
US11003516B2 (en) Geographical redundancy and dynamic scaling for virtual network functions
CN103368768A (zh) 混合云环境中具有启发式监视的自动缩放网络覆盖
JP7313480B2 (ja) スライスベースネットワークにおける輻輳回避
CN109150589A (zh) 基于Open Stack虚拟网络阻塞异常的处理方法及***
CN112202940B (zh) 一种kubernetes对外暴露Pod服务方式
EP3624401A1 (en) Systems and methods for non-intrusive network performance monitoring
EP4142243A1 (en) Adaptive flow monitoring
Zhu et al. Zoonet: a proactive telemetry system for large-scale cloud networks
US10402765B1 (en) Analysis for network management using customer provided information
CN101635656B (zh) 层次化有序地址分组网络中故障检测的方法、***及设备
Toy Future Directions in Cable Networks, Services and Management
CN106789380A (zh) 一种虚拟机网络一体化监管***
Jerzak et al. Fail-aware publish/subscribe
JP5653947B2 (ja) ネットワーク管理システム、ネットワーク管理装置、ネットワーク管理方法及びネットワーク管理プログラム
US11546244B1 (en) Namespace-aware test agents for network performance measurement
CN107104837A (zh) 路径检测的方法和控制设备

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: 20190104