CN103731289A - 一种网络服务器自动扩展的方法 - Google Patents
一种网络服务器自动扩展的方法 Download PDFInfo
- Publication number
- CN103731289A CN103731289A CN201210392517.0A CN201210392517A CN103731289A CN 103731289 A CN103731289 A CN 103731289A CN 201210392517 A CN201210392517 A CN 201210392517A CN 103731289 A CN103731289 A CN 103731289A
- Authority
- CN
- China
- Prior art keywords
- server
- pond
- pools
- message
- service
- 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
Links
Images
Abstract
本发明提供一种服务器扩展的方法,其包括首先建立服务器池,当服务器池处理量不够,需要增加服务器进入服务器池的时候,新服务器通过登记机制可以立刻将自己加入到服务器池之中,并通过池化器的解析服务功能,可将新增的服务器IP通过用户的池名解析分配给用户,从而分担用户的访问量和提高服务器池的整体处理量。服务器池中池化器与服务器之间是通过网络连接,池化器充当管理者的身份,服务器池系统中各成员是互通的即可。这样,服务器可以是任意位置,不必处于相同网段之中,因此服务器的位置在服务器池系统中没有任何限制。
Description
【技术领域】
本发明是关于计算机网络服务器领域,特别是关于网络服务器池系统的扩展的技术领域。
【背景技术】
典型的服务器集群模式下,通常在需要拥有一组冗余服务器,(冗余服务器即为:多台能提供相同服务功能的服务器),并在冗余服务器的前端部署一个负载均衡设备,该种设备通常被称之为负载均衡器,负载均衡器通常有内外网口之分,外网口面向用户,是用户可以访问的到的一端,而内网口面向后端的冗余服务器,内网口与后端冗余服务器也处于相同的网段,用户通常是不能直接访问到该网段的。
该种集群系统的工作模式如下:
用户访问负载均衡器的外网口IP地址,负载均衡器将用户请求通过相应的策略均匀地分配到处于后端的不同的实际服务器上,实际服务器处理完成用户请求后将处理结果返回给负载均衡器,负载均衡器再转发给用户,这样用户的访问量就由多台服务器同时处理,因此集群系统能显著提高多台服务器的协同工作,提高系统整体的处理能力,突破单台服务器的性能瓶颈。
然而在部署该类集群的时候,需要在前端的负载均衡设备中事先配置好后端的服务器IP,如果需要更大的处理能力,就需要在后端部署更多的服务器,这样就需要在前端负载均衡设备里人工修改配置,并使其生效,否则,负载均衡器将无法为新增的服务器分配用户流量。
也就是说,当我们部署和运行集群系统的时候,系统的扩展是需要人工干预的,同时负载均衡器的内网口与后端多台服务器处于相同网段,这样就要求后端多台服务器处于同一个内网,因此传统的集群系统有较大的局限性。
【发明内容】
本发明的目的在于本发明针对传统的服务器集群的不足之处,提出采用服务器池方案,可实现任意的系统扩展,并消除系统对服务器位置的限制。
为达成前述目的,本发明一种网络服务器自动扩展的方法,其包括如下步骤:
构建一个服务器池系统,并为提供相同服务的服务器组成的服务器池命名,其中所述服务器池系统包括:
服务器池:服务器池是由一组具有相同功能的,并被统一管理起来的服务器组成,每个服务器池均使用唯一的池名作为标识;
池化器:是服务器池的管理设备,负责将多台服务器组成一个虚拟的服务器池,并对各台服务器的运行状态进行实时监控和采集;同时提供池名解析功能,以便能让用户方便地访问服务器;
客户端:访问服务器池的客户机;
服务器启动时,服务器需在池化器处进行登记,登记时要提供相关的系统信息,包括:池名、唯一的服务识别号、服务器IP地址、服务端口、服务协议、服务检测、均衡策略;
池化器收到登记消息后,将对其按照池名进行归类,保存在其内部的服务器列表之中,同时发布服务器更新消息给其他池化器,将该服务登记信息同步到其他服务器里,从而保证所有池化器中的服务器列表都是一致的;
池化器每隔一个时间段会对其主管服务器进行监控检查,一旦发现有服务器发生故障,立刻从其保持的服务器列表中删除该服务器,同时发送服务器更新消息给其他池化器,其他池化器接到该消息后,也同时从自己的服务器列表中删除该服务器;
用户访问服务器池之前,必须向池化器发送池名解析请求,池化器根据自身保持的服务器列表,并按照服务器池的均衡策略为用户选择一台被认为最佳的服务器IP,将结果返回给用户;
根据池名解析的结果,用户直接与服务器建立连接,按照均衡策略,不同的用户通过池名解析,会获得不同的服务器IP,这样用户的访问量就被分配到不同的服务器上
当扩展服务器时,新的服务器在池化器处进行登记,重复前述服务器启动之后的步骤,实现服务器的扩展。
根据本发明的一个实施例,所述池名是由若干个从a到z的26个拉丁字母及0到9的10个阿拉伯数字及“-”以及“.”符号构成的并按一定的层次和逻辑排列,池名不能重复,具有相同服务的多台服务器拥有同一个池名。
根据本发明的一个实施例,服务登记的过程是通过服务器向池化器发送登记消息,到服务器收到池化器发回来的登记回应消息而完成,登记消息中包含了前述系统信息。
根据本发明的一个实施例,前述服务器状态监控的步骤中服务器健康检查采用以下方式进行:如果池化器发出的持续活动消息,在设定时间内没有收到持续活动确认消息,则迅速连续发送几个持续活动消息,如果仍然没有收到持续活动确认消息,则可以判定服务器发生故障,如果池化器收到持续活动确认消息则表明服务器正常。
根据本发明的一个实施例,在持续活动确认消息中服务器附带了服务器自身的CPU使用率、网络使用率、内存使用率、硬盘使用率信息。
根据本发明的一个实施例,前述服务器状态监控的步骤中服务器健康检查采用以下方式进行:池化器主动探测服务器IP及端口,主动创建服务器TCP连接,连接成功则表明服务器正常,否则表明服务器故障。
根据本发明的一个实施例,前述服务器状态监控的步骤中服务器健康检查采用以下方式进行:池化器向服务器依照用户所使用的服务协议发送特定的协议,然后根据服务器的回答来判断服务器的状况,池化器如果收到的服务器状态码为正常,则表明服务器的服务是正常的,反之可以判断出服务器的服务异常,即服务器发生故障。
本发明的方法,服务器池系统可以根据需求任意自动扩展,当服务器池处理量不够,需要增加服务器进入服务器池的时候,新服务器通过登记机制可以立刻将自己加入到服务器池之中,并通过池化器的解析服务功能,可将新增的服务器IP通过用户的池名解析分配给用户,从而分担用户的访问量和提高服务器池的整体处理量。如果因为各种理由需要降低服务器池的处理能力时,只要将需退出的服务器在池化器处进行注销,池化器就立刻删除该服务器节点,这样,用户进行池名解析时,池化器就不会再将该服务器IP分配给用户。
服务器池中池化器与服务器之间是通过网络连接,池化器充当管理者的身份,服务器池系统中各成员是互通的即可。这样,服务器可以是任意位置,不必处于相同网段之中,因此服务器的位置在服务器池系统中没有任何限制。
【附图说明】
图1是本发明的服务器池系统的结构示意图。
图2为本发明的服务器池系统的工作流程图。
图3为本发明的登记消息格式示意图。
图4为本发明的登记消息格式中池名参数格式示意图。
图5为本发明的登记消息格式中服务器参数格式示意图。
图6为本发明的登记回应消息格式示意图。
图7为本发明的持续活动消息格式示意图。
图8为本发明的持续活动消息格式中系统参数的格式示意图。
图9为本发明的持续活动确认消息格式示意图。
图10为本发明的服务器更新消息格式示意图。
【具体实施方式】
此处所称的“一个实施例”或“实施例”是指可包含于本发明至少一个实现方式中的特定特征、结构或特性。在本说明书中不同地方出现的“在一个实施例中”并非均指同一个实施例,也不是单独的或选择性的与其他实施例互相排斥的实施例。
现有的网络服务器群在部署该类集群的时候,需要在前端的负载均衡设备中事先配置好后端的服务器IP,如果需要更大的处理能力,就需要在后端部署更多的服务器,这样就需要在前端负载均衡设备里人工修改配置,并使其生效,否则,负载均衡器将无法为新增的服务器分配用户流量。
本发明针对现有技术的缺陷,提出一种新的自动扩展服务器的方法,本发明的自动扩展服务器的方法须建立在服务器池框架下方能发挥其功能。服务器池的核心思想是让某项服务由多个冗余服务器同时来提供,所有这些服务器的集合被称为一个服务器池。也就是说:一项服务是由一个服务器池的整体来提供的,服务器是分布式的,均拥有各自的IP地址。当其中一个服务器因故障而不能继续提供服务的时候,可以由存在于服务器池中另一个正常运行的服务器继续提供。其系统示意图图1所示,本发明的服务器池系统由以下三个部分组成:
服务器池:服务器池是由一组具有相同功能的,并被统一管理起来的服务器组成,每个服务器池均使用唯一的池名作为标识;
池化器:是服务器池的管理设备,负责将多台服务器组成一个虚拟的服务器池,并对各台服务器的运行状态进行实时监控和采集;同时提供池名解析功能,以便能让用户方便地访问服务器;
客户端:访问服务器池的客户机。
下面对本发明的服务器池系统的工作流程做详细说明,请参阅图2所示,本发明的服务器池系统的构建步骤如下:
步骤S1:首先建立服务器池,并为提供相同服务的服务器组成的服务器池命名,即池名,池名是服务器池唯一的标识名,是由若干个从a到z的26个拉丁字母及0到9的10个阿拉伯数字及“-”以及“.”符号构成的并按一定的层次和逻辑排列,命名方法与域名(Domain Name)是一致的。池名不能重复,具有相同服务的多台服务器拥有同一个池名。
步骤S2:在服务启动时,服务器需在池化器处进行登记,登记时要提供相关的系统信息,包括:池名,唯一的服务识别号、服务器IP地址、服务端口、服务协议、服务检测、均衡策略等。服务登记的过程是通过向池化器发送登记(registration)消息,到服务器收到池化器发回来的registration_response消息而完成,registration消息中包含了服务相关的池名信息和服务信息请参阅图3至图5所示,其分别显示了本发明的登记消息格式示意图、本发明的登记消息格式中池名参数格式示意图、本发明的登记消息格式中服务器参数格式示意图。以及请参阅图6所示,其显示了本发明的登记回应消息格式示意图。
步骤S3:池化器收到登记消息后,将对其按照池名进行归类,保存在其内部的服务器列表(Server List)之中,同时发布服务器更新消息(Server_Update)给其他池化器,将该服务登记信息同步到其他服务器里,从而保证所有池化器中的Server List都是一致的。
步骤S4:池化器每隔一个时间段会对其主管服务器进行监控检查,一旦发现有服务器发生故障,立刻从其保持的服务器列表(Server List)中删除该服务器,同时发送服务器更新消息给其他池化器,其他池化器接到该消息后,也同时从自己的服务器列表中删除该服务器。
步骤S5:池名解析:用户访问服务器池之前,必须向池化器发送池名解析请求,池化器根据自身保持的服务器列表,并按照服务器池的均衡策略为用户选择一台被认为最佳的服务器IP,将结果返回给用户;
步骤S6:用户访问服务器:根据池名解析的结果,用户直接与服务器建立连接,按照均衡策略,不同的用户通过池名解析,会获得不同的服务器IP,这样用户的访问量就被分配到不同的服务器上。
其中前述服务器状态监控的步骤中服务器健康检查采用以下方式进行:
方法一:向服务器发送持续活动消息(Keep_Alive),如果收到持续活动确认消息(Keep_Alive_Ack)则表明服务器正常;
方法二:池化器主动探测服务器IP及端口,主动创建服务器TCP连接,连接成功则表明服务器正常;
方法三:主动探测服务协议,池化器向服务器依照用户所使用的服务协议发送特定的协议,然后根据服务器的回答来判断服务器的状况。
其中方法一的具体的过程为:池化器每隔一个固定的时间间隔向该服务器发送持续活动消息Keep_Alive。请参阅图7和图8所示,其分别显示本发明的一个实施例中保持活动消息的格式和保持活动消息中系统参数描述的格式。
服务器接到持续活动消息Keep_Alive后,立刻以持续活动确认消息Keep_Alive_Ack回复给池化器。请参阅图9所示,其显示本发明的持续活动确认消息的格式。在持续活动确认消息Keep_Alive_Ack中服务器附带了自身的相关状态信息(比如:CPU使用率、网络使用率、内存使用率、硬盘使用率等)。这样池化器可以知晓服务器的实时系统状况,并可以参照作为依据判断服务器的状况。在一些情况下,虽然服务器运行都正常,但由于资源近乎消耗殆尽,例如CPU使用率、网络使用率、内存使用率、硬盘使用率等超过预定值,继续运行可能导致更大的问题,这种情况,池化器可提前预知,可将该服务器设置为故障服务器。
如果池化器发出的持续活动消息Keep_Alive,在设定时间(timeout)内没有收到持续活动确认消息Keep_Alive_Ack,则迅速连续发送几个持续活动消息Keep_Alive,如果仍然没有收到持续活动确认消息Keep_Alive_Ack,则可以判定服务器发生故障,这种故障可能有多种可能:服务器宕机、软件故障、网络故障等,总之在这种情况下,用户肯定是无法使用该服务器的服务。
其中方法三的具体过程为:由于服务器在登记时,提供其自身服务的相关信息,比如:服务协议、IP地址、端口号、以及是否进行服务检测等信息,如果服务器需要进行服务检测(见图7中服务器参数Server Parameter,服务检测0x1为开,0x0为关),池化器根据这些信息,对该服务器进行周期性的服务可用性探测,方法是向指定的IP和端口按照其服务协议发送探测消息,然后通过服务器的回应判断其服务正常与否。
这里通过一个实例说明池化器如何通过服务器参数进行服务可用性探测:假设服务器A在登记时提供的信息为:
服务协议 | http |
IP地址 | 192.168.100.9 |
服务端口 | 8080 |
池名 | www.test.com |
服务检测 | 0x1 |
池化器根据这些信息,可模拟一次通常的用户使用浏览器的访问操作,然后根据其回应,探测其服务是否正常。池化器主动向192.168.100.9:8080发起建立一个tcp连接,并发送一条HTTP消息,内容如下:
GET/HTTP/1.1
Host:www.test.com
User-Agent:Mozilla/5.0
Accept:*/*
如果服务器A的服务是正常的,池化器得到以下HTTP回复消息。
HTTP/1.1 200 OK
Date:Thu,27 Sep 2012 16:06:28 GMT
Server:BWS/1.0
Content-Length:9783
Content-Type:text/html;charset=gbk
Cache-Control:private
其中第一行“HTTP/1.1200OK”中的200就是HTTP状态码,根据这个HTTP状态码就可以判断其服务器状况。
HTTP状态码说明如下(仅列举部分):
HTTP状态码 | 说明 |
200 | 正常 |
403 | 资源不可用 |
404 | 无法找到指定位置的资源 |
503 | 服务不可用 |
… | … |
按照以上的例子,池化器如果收到的HTTP状态码为200,则表明服务器A的服务是正常的,反之可以判断出服务器A的服务异常,即服务器A发生故障,随后可以做进一步的故障处理。
无论在哪个检测环节(Keep_Alive和服务检测)中池化器判断出某个服务器发生故障,都将立刻向其他池化器发送服务器更新消息要求池化器将该服务器从服务器列表中删除掉,也即前述的服务器信息同步步骤。请参阅图10所示,其显示本发明的一个实施例中服务器更新消息的格式,其中在该服务器更新消息中其中更新动作(Update Action)定义如下:
Update Action=0x1增加服务;
Update Action=0x2删除服务。
该发明所述的服务器池系统的核心思想是让某项服务由多个冗余服务器同时来提供,所有这些服务器的集合被称为一个服务器池。也就是说:一项服务是由一个服务器池的整体来提供的,服务器是分布式的,均拥有各自的IP地址。当其中一个服务器因故障而不能继续提供服务的时候,可以由存在于服务器池中另一个正常运行的服务器继续提供。
基于服务器池相应的运行机制,每当服务器启动时,主动在池化器处进行登记,向池化器提供自身的相关信息(包括:服务器IP、服务器端口、服务协议、池名等),池化器维护着一份服务器列表,根据服务器的登记信息,实时更新着这份服务器列表;服务器关闭前需在池化器处做注销,池化器根据注销信息将该服务器从该服务器列表中删除;同时服务器池系统的故障检测机制,对服务器列表中的服务器实时健康检查,一旦发现服务器故障,也会主动将该服务器从服务器列表中删除掉,从而保证了服务器池中服务器都是正常的服务器。
这种机制使得服务器池系统可以根据需求任意扩展,当服务器池处理量不够,需要增加服务器进入服务器池的时候,新服务器通过登记机制可以立刻将自己加入到服务器池之中,并通过池化器的解析服务功能,可将新增的服务器IP通过用户的池名解析分配给用户,从而分担用户的访问量和提高服务器池的整体处理量。如果因为各种理由需要降低服务器池的处理能力时,只要将需退出的服务器在池化器处进行注销,池化器就立刻删除该服务器节点,这样,用户进行池名解析时,池化器就不会再将该服务器IP分配给用户。
服务器池中池化器与服务器之间是通过网络连接,池化器充当管理者的身份,服务器池系统中各成员是互通的即可。这样,服务器可以是任意位置,不必处于相同网段之中,因此服务器的位置在服务器池系统中没有任何限制。
上述说明已经充分揭露了本发明的具体实施方式。需要指出的是,熟悉该领域的技术人员对本发明的具体实施方式所做的任何改动均不脱离本发明的权利要求书的范围。相应地,本发明的权利要求的范围也并不仅仅局限于前述具体实施方式。
Claims (7)
1.一种网络服务器自动扩展的方法,其包括如下步骤:
构建一个服务器池系统,并为提供相同服务的服务器组成的服务器池命名,其中所述服务器池系统包括:
服务器池:服务器池是由一组具有相同功能的,并被统一管理起来的服务器组成,每个服务器池均使用唯一的池名作为标识;
池化器:是服务器池的管理设备,负责将多台服务器组成一个虚拟的服务器池,并对各台服务器的运行状态进行实时监控和采集;同时提供池名解析功能,以便能让用户方便地访问服务器;
客户端:访问服务器池的客户机;
服务器启动时,服务器需在池化器处进行登记,登记时要提供相关的系统信息,包括:池名、唯一的服务识别号、服务器IP地址、服务端口、服务协议、服务检测、均衡策略;
池化器收到登记消息后,将对其按照池名进行归类,保存在其内部的服务器列表之中,同时发布服务器更新消息给其他池化器,将该服务登记信息同步到其他服务器里,从而保证所有池化器中的服务器列表都是一致的;
池化器每隔一个时间段会对其主管服务器进行监控检查,一旦发现有服务器发生故障,立刻从其保持的服务器列表中删除该服务器,同时发送服务器更新消息给其他池化器,其他池化器接到该消息后,也同时从自己的服务器列表中删除该服务器;
用户访问服务器池之前,必须向池化器发送池名解析请求,池化器根据自身保持的服务器列表,并按照服务器池的均衡策略为用户选择一台被认为最佳的服务器IP,将结果返回给用户;
根据池名解析的结果,用户直接与服务器建立连接,按照均衡策略,不同的用户通过池名解析,会获得不同的服务器IP,这样用户的访问量就被分配到不同的服务器上
当扩展服务器时,新的服务器在池化器处进行登记,重复前述服务器启动之后的步骤,实现服务器的扩展。
2.如权利要求1所述的方法,其特征在于:所述池名是由若干个从a到z的26个拉丁字母及0到9的10个阿拉伯数字及“-”以及“.”符号构成的并按一定的层次和逻辑排列,池名不能重复,具有相同服务的多台服务器拥有同一个池名。
3.如权利要求1所述的方法,其特征在于:服务登记的过程是通过服务器向池化器发送登记消息,到服务器收到池化器发回来的登记回应消息而完成,登记消息中包含了前述系统信息。
4.如权利要求1所述的方法,其特征在于:前述服务器状态监控的步骤中服务器健康检查采用以下方式进行:如果池化器发出的持续活动消息,在设定时间内没有收到持续活动确认消息,则迅速连续发送几个持续活动消息,如果仍然没有收到持续活动确认消息,则可以判定服务器发生故障,如果池化器收到持续活动确认消息则表明服务器正常。
5.如权利要求4所述的方法,其特征在于:在持续活动确认消息中服务器附带了服务器自身的CPU使用率、网络使用率、内存使用率、硬盘使用率信息。
6.如权利要求1所述的方法,其特征在于:前述服务器状态监控的步骤中服务器健康检查采用以下方式进行:池化器主动探测服务器IP及端口,主动创建服务器TCP连接,连接成功则表明服务器正常,否则表明服务器故障。
7.如权利要求1所述的方法,其特征在于:前述服务器状态监控的步骤中服务器健康检查采用以下方式进行:池化器向服务器依照用户所使用的服务协议发送特定的协议,然后根据服务器的回答来判断服务器的状况,池化器如果收到的服务器状态码为正常,则表明服务器的服务是正常的,反之可以判断出服务器的服务异常,即服务器发生故障。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210392517.0A CN103731289A (zh) | 2012-10-16 | 2012-10-16 | 一种网络服务器自动扩展的方法 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN201210392517.0A CN103731289A (zh) | 2012-10-16 | 2012-10-16 | 一种网络服务器自动扩展的方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN103731289A true CN103731289A (zh) | 2014-04-16 |
Family
ID=50455224
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210392517.0A Pending CN103731289A (zh) | 2012-10-16 | 2012-10-16 | 一种网络服务器自动扩展的方法 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN103731289A (zh) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103944784A (zh) * | 2014-04-23 | 2014-07-23 | 南京邮电大学 | 一种面向大规模云数据中心的服务器协同监控方法 |
CN104298750A (zh) * | 2014-10-14 | 2015-01-21 | 北京国双科技有限公司 | 用于实时系统通信的更新处理方法及装置 |
CN104702667A (zh) * | 2015-01-30 | 2015-06-10 | 武汉大学 | 一种应用服务系统扩展的方法及装置 |
CN107567696A (zh) * | 2015-05-01 | 2018-01-09 | 亚马逊科技公司 | 计算集群内的资源实例群组的自动扩展 |
CN108965401A (zh) * | 2018-06-25 | 2018-12-07 | 千寻位置网络有限公司 | 支持水平扩展的地理围栏系统及工作方法 |
CN109766192A (zh) * | 2019-01-25 | 2019-05-17 | 郑州云海信息技术有限公司 | 一种虚拟化服务器的调度方法及调度系统 |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090157419A1 (en) * | 2007-09-28 | 2009-06-18 | Great-Circle Technologies, Inc. | Contextual execution of automated workflows |
CN102347876A (zh) * | 2011-09-30 | 2012-02-08 | 鞠洪尧 | 一种云计算网络多链路聚合控制装置 |
CN102437933A (zh) * | 2012-01-04 | 2012-05-02 | 无锡云捷科技有限公司 | 一种服务器故障容错系统及方法 |
CN102638396A (zh) * | 2012-03-21 | 2012-08-15 | 华为技术有限公司 | 负载均衡方法和设备 |
CN102685782A (zh) * | 2011-03-14 | 2012-09-19 | 中国移动通信集团公司 | 分布式基站系统及其负载均衡方法 |
-
2012
- 2012-10-16 CN CN201210392517.0A patent/CN103731289A/zh active Pending
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20090157419A1 (en) * | 2007-09-28 | 2009-06-18 | Great-Circle Technologies, Inc. | Contextual execution of automated workflows |
CN102685782A (zh) * | 2011-03-14 | 2012-09-19 | 中国移动通信集团公司 | 分布式基站系统及其负载均衡方法 |
CN102347876A (zh) * | 2011-09-30 | 2012-02-08 | 鞠洪尧 | 一种云计算网络多链路聚合控制装置 |
CN102437933A (zh) * | 2012-01-04 | 2012-05-02 | 无锡云捷科技有限公司 | 一种服务器故障容错系统及方法 |
CN102638396A (zh) * | 2012-03-21 | 2012-08-15 | 华为技术有限公司 | 负载均衡方法和设备 |
Cited By (10)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN103944784A (zh) * | 2014-04-23 | 2014-07-23 | 南京邮电大学 | 一种面向大规模云数据中心的服务器协同监控方法 |
CN103944784B (zh) * | 2014-04-23 | 2019-03-05 | 南京邮电大学 | 一种面向大规模云数据中心的服务器协同监控方法 |
CN104298750A (zh) * | 2014-10-14 | 2015-01-21 | 北京国双科技有限公司 | 用于实时系统通信的更新处理方法及装置 |
CN104298750B (zh) * | 2014-10-14 | 2018-02-23 | 北京国双科技有限公司 | 用于实时系统通信的更新处理方法及装置 |
CN104702667A (zh) * | 2015-01-30 | 2015-06-10 | 武汉大学 | 一种应用服务系统扩展的方法及装置 |
CN107567696A (zh) * | 2015-05-01 | 2018-01-09 | 亚马逊科技公司 | 计算集群内的资源实例群组的自动扩展 |
CN107567696B (zh) * | 2015-05-01 | 2021-01-12 | 亚马逊科技公司 | 计算集群内的资源实例群组的自动扩展 |
US11044310B2 (en) | 2015-05-01 | 2021-06-22 | Amazon Technologies, Inc. | Automatic scaling of resource instance groups within compute clusters |
CN108965401A (zh) * | 2018-06-25 | 2018-12-07 | 千寻位置网络有限公司 | 支持水平扩展的地理围栏系统及工作方法 |
CN109766192A (zh) * | 2019-01-25 | 2019-05-17 | 郑州云海信息技术有限公司 | 一种虚拟化服务器的调度方法及调度系统 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
WO2020253786A1 (zh) | 一种去中心化处理的方法、通信代理、主机以及存储介质 | |
CN103581276B (zh) | 集群管理装置、系统、业务客户端及相应方法 | |
CN108039964B (zh) | 基于网络功能虚拟化的故障处理方法及装置、系统 | |
CN105051698B (zh) | 用于基础设施即服务云中故障管理的方法和布置 | |
CN103853627B (zh) | 由与物理机器相关地分析虚拟机器性能问题原因的方法和系统 | |
CN103731289A (zh) | 一种网络服务器自动扩展的方法 | |
CN104935672B (zh) | 负载均衡服务高可用实现方法和设备 | |
CN104168333B (zh) | Proxzone服务平台的工作方法 | |
KR101408037B1 (ko) | 클라우드 시스템에서의 가상 머신 통합 모니터링 장치 및 방법 | |
JP2018522471A (ja) | ソフトウェアディファインドデータセンタ及びそこにおけるサービスクラスタの配置方法 | |
US20130007253A1 (en) | Method, system and corresponding device for load balancing | |
CN105897827A (zh) | 服务器节点、局域网服务器集群及其实现方法 | |
CN112015544A (zh) | 一种k8s集群的负载均衡方法、装置、设备及存储介质 | |
CN108243055B (zh) | 一种容器云自动发现与注册系统及方法 | |
CN106302596A (zh) | 一种服务发现的方法和装置 | |
JP6354901B2 (ja) | 仮想マシンの故障検知および回復用管理システム | |
CN103731287A (zh) | 一种故障接管服务器选择方法 | |
CN113489691B (zh) | 网络访问方法、装置、计算机可读介质及电子设备 | |
CN100461719C (zh) | 服务健康度检测系统及方法 | |
CN103731290A (zh) | 一种服务器故障切换方法 | |
CN107566466A (zh) | 负载均衡方法及装置 | |
CN103166980A (zh) | 互联网数据拉取方法和系统 | |
CN107992491A (zh) | 一种分布式文件系统、数据访问和数据存储的方法及装置 | |
CN110661641A (zh) | 一种虚拟网络功能vnf部署方法及装置 | |
CN108200132A (zh) | 资源获取方法、装置、设备及计算机可读存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
C10 | Entry into substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20140416 |
|
WD01 | Invention patent application deemed withdrawn after publication |