CN107919994B - 实现网络服务双机热备的方法及服务器 - Google Patents

Abstract

本发明公开一种实现网络服务双机热备的方法及服务器，首先通过快/慢结合的心跳和握手机制，完成主备协商和服务器模式的切换；然后在网络层面，利用虚拟IP技术，实现双机利用同一IP地址对外提供网络服务的热备方案。双机热备插件的物理形态为一软件插件的形式，可安装于Windows、Linux类操作系统。该方法通过在服务器上安装热备插件，无需修改原服务器上的服务程序，非常有利于原来单服务器工作的系统，实现双机热备的升级；采用虚拟IP技术，并通过快/慢结合的心跳和握手机制，以自动完成双机热备状态的协商和服务器模式的切换，无需客户端轮询查找服务器，有效避免了客户端和用户的负担的增加。

Description

实现网络服务双机热备的方法及服务器

技术领域

本发明属于网络通信中的提高网络可靠性、服务器可维护性的技术领域，具体涉及一种用软件的方法解决基于网络服务的双机热备问题的技术方案。

背景技术

随着信息化和网络技术的飞速发展，用户对网络服务可靠性的要求越高，如何避免和解决由服务宕机、网络中断等造成的服务质量不佳、用户体验下降等问题，变得尤为重要。

现行较通行的做法是，在局域网内或分布式的架设多台服务器对外提供服务，一台服务器宕机或网络不通，其他服务器亦能保持正常工作，但是这些做法亦存在各自的弊端和问题。例如，Windows系统的网络对时服务，当某网络对时服务器不通时，需要用户手动的选择另一服务器做对时；另有一些在客户端上做了一些改进，可配置多路服务器的地址，然后帮助用户自动的探测和轮询多服务器来请求服务。这两种方式，或多或少都增加了用户负担或对客户端有一定的要求。

虚拟IP技术是依赖ARP机制实现的。ARP，即地址解析协议，是TCP/IP协议栈的内容。ARP的核心思想是，在局域网内，与对方设备通信前，先在网内查询对方IP对应的MAC地址(物理地址)，然后通过MAC地址完成局域网内通信。通过在一个MAC地址上绑定多个IP地址，即可实现一个网卡两个IP，即虚拟IP技术。

发明内容

为解决上述问题，本发明中提出一种实现网络服务双机热备的方法及服务器，双服务器仅暴露一个虚拟IP地址(简称VIP)为客户端提供服务，虚拟IP地址加载在主服务器上，利用ARP机制发往虚拟IP地址的请求，即被定位到主服务器上，主服务器发生异常后，通过探测和主备协商机制重新商定主备关系，以实现对客户端的双机热备服务。本发明的技术方案如下：

一种实现网络服务双机热备的方法，服务器运行双机热备插件，并进入探测状态、独立运行状态或同步运行状态，具体如下：

探测状态下，服务器发送快心跳，在第一预设应答时间内未收到其他服务器的握手应答，自动获取并加载虚拟IP地址，并进入独立运行状态；在第一预设应答时间内收到另一方服务器的握手应答后建立主备连接，通过主备协商机制完成主备协商，协商为主服务器的一方(即主服务器)自动获取并加载虚拟IP地址，随后进入同步运行状态；

同步运行状态下，主服务器通过虚拟IP地址为客户端提供服务；协商为备服务器的一方(即备服务器)进入服务静默状态；主、备服务器周期性的点对点的发送慢心跳，并等待对方回复，在第二预设应答时间内接收到对方心跳时予以握手应答以进行主备同步维护，若在第二预设应答时间内接收不到对方心跳时进入探测状态；

独立运行状态下，服务器通过虚拟IP地址为客户端提供服务。

作为一种优选方案，独立运行状态下，不发送心跳。

作为一种优选方案，所述快心跳采用UDP广播方式发送，所述慢心跳采用UDP单播方式发送。

作为一种优选方案，所述主备协商机制是指通过心跳报文和心跳握手应答报文中携带的信息商定主备关系，或者通过预先设定的主备判定方式来确定主备关系。

作为一种优选方案，还包括设置心跳应答定时器，用于对应答时间进行计时；在探测状态下，服务器发送快心跳，并通过心跳应答定时器对对方的应答时间进行计时；在同步运行状态下，主、备服务器周期性的点对点的发送慢心跳，并通过心跳应答定时器对对方的应答时间进行计时。

作为一种优选方案，还包括设置心跳计数器，用于对快心跳进行计数；在探测状态下，服务器发送至少两次快心跳，并启动心跳计数器：若在第一预设应答时间内收到另一方服务器的握手应答，心跳计数器清0，并进入同步运行状态；若在第一预设应答时间内未收到其他服务器的握手应答，心跳计数器加1，直到心跳计数器溢出，则认定对端不存在，并进入独立运行状态。

作为一种优选方案，在同步运行状态下，备服务器在第二预设应答时间内接收不到主服务器心跳或握手应答时进入探测状态，在探测状态下仍探测不到对方后自动加载虚拟IP地址，并进入独立运行状态，为客户端提供服务。

作为一种优选方案，备服务器在探测状态下探测到对方出现异常后；根据主备协商机制切换重新确定主、备服务器，协商为主服务器的一方自动加载虚拟IP地址，为客户端提供服务。

作为一种优选方案，探测到对方出现异常是指与主备协商机制相关的状态或参数发生变化。例如，包括在心跳报文和心跳握手应答报文中携带的热备插件的版本号发生变化，对方服务器的IP地址发生变化等。

本发明还公开一种服务器，其装有开机时自动启动运行的双机热备插件，所述双机热备插件在运行时执行以上所述的方法。

有益效果：

(1)通过在服务器上安装热备插件，设置热备插件为开机自启动方式，即通过软件化的方式实现双机利用同一IP地址对外提供网络服务的热备方案，无需修改原服务器上的服务程序，非常有利于原来单服务器工作的系统，实现双机热备的升级。

(2)本发明采用虚拟IP技术，双机共用同一个IP对外提供服务，并通过快/慢结合的心跳和握手机制，以自动完成双机热备状态的协商和服务器模式的切换，无需客户端轮询查找服务器，有效避免了客户端和用户的负担的增加。

(3)本发明采用快/慢心跳机制，且快心跳采用广播，慢心跳采用单播，提高服务效率的同时还有效地减少了网络资源的占有。

(4)本发明所采用双服务器服务模式可适用于云计算中虚拟机场景的应用，亦可使用于普通场景下，两台宿主机的双机热备，具有很强的通用性。

附图说明

图1单服务器升级为本发明双机热备模型的示意图；

图2双机热备的状态机；

图3快/慢心跳与主备协商机制；

图4实现双机热备的网络模型；

图5 Windows和Linux系统下虚拟IP的加载；

图6本发明具体实施步骤图。

具体实施方式

本发明首先通过快/慢结合的心跳和握手机制，完成双机热备状态的协商和服务器模式的切换；然后在网络层面，利用虚拟IP技术，实现双机利用同一IP地址对外提供网络服务的热备方案，以确保对客户端的服务不中断。本发明的物理形态为一软件插件的形式，可安装于Windows、Linux类操作系统，即后文所称的双机热备插件(或热备插件)。

服务器上一个网卡有两个IP，即实际IP地址和虚拟IP地址，在以太网内实现服务和通信，原理上主要是利用TCP/IP协议栈中的ARP功能，操作系统会自动维护更新ARP缓存。虚拟IP地址是一个不与特定计算机或一个计算机中的网络接口卡相连的IP地址，VIP地址上数据包的收发，与实际IP地址的用法没有区别，VIP上所有收发的数据也是经过真实的物理网卡的。

下面结合附图和具体实施示例，对本发明进行详细说明，

如图1所示，图1中的(a)为原单服务器网络服务模式，通过增加一台相同的服务器，并在两台服务器上安装开机自启动的热备插件，如图1中的(b)所示，即可升级为双机热备网络服务，此种方法对原服务器的软硬件无特定要求，具有通用性。

如图2所示，本发明中，双机热备的运行状态有三种，即探测状态、独立运行和同步运行，同时，将热备服务器机定义为三种模式，即主服务器、备服务器、独立服务器。具体如下：

探测状态：表示尝试与对方(即其他服务器)握手，即正在建立主备连接的中间状态，此状态发送快心跳探测对方。通常有两种情形进入此状态：1)开机启动时；2)双机同步运行情况下，另一方疑似丢失(不发送心跳或不应答本方心跳)，进入探测状态。

同步运行：表示本服务器与对方建立备份连接，进入一主一备的双机同步运行状态。通常有三种情形进入此状态：1)本机在同步运行态，收到对方的心跳或本方发送心跳对方有握手应答，维持同步运行状态；2)本机启动，本方发起快心跳探测，收到对方心跳握手应答，双方进入同步运行状态；3)本机在独立运行态，收到对方心跳，予以握手应答，双方进入同步运行状态。此状态下，对外提供服务的称为主服务器，服务静默的称为备服务器。

独立运行：表示本服务器未能与其他服务器建立备份连接，从而进入独立运行状态，此状态不发送心跳。进入此状态的情形主要是指，探测状态下，快心跳探测次数超过阈值都没有收到心跳握手应答，即认为对方不存在。此状态的服务器称为独立服务器。

如图3所示，本发明建立了热备切换机制及相应的触发事件，具体如下：

本发明中，双机完成心跳和握手应答后，即可通过预设的主备协商机制完成双机主、备的协商。主备协商机制，可通过心跳报文和心跳握手应答报文中携带的信息商定，亦可通过一些预先设定的简单方式来确定主备关系，如在心跳和应答报文中携带的插件的版本号大小，版本新的为主，亦如IP地址较小的一方为主机，大的一方为备机。

心跳机制通常是指定期发送心跳，等待对方应答，用于探测对方是否存活；另收到对方的心跳，回复心跳握手应答，表示本方存活。本发明提出了一种快/慢结合的心跳机制，即根据发送周期上将心跳分为快心跳和慢心跳(或称常规心跳)，两种心跳报文在内容上是一样的，但发送周期不同、发送方式不同，亦起到不一样的作用。其中，快心跳用于开机或极端情况下(探测状态)，采用UDP广播方式发送，快速探知对方是否存在；慢心跳用于常规情况下双方的同步维护，采用UDP单播方式发送。

快心跳探测：快心跳1秒一次，用于快速探测对方是否存在，且采用UDP广播方式发送，非常有利于对方IP地址未知(如刚启动开机或对方IP地址有变更)情况下与对方握手探测。一般两种情形下会发送快心跳：1)开机时，对方IP地址未知，发送广播式的快心跳做探测；2)同步运行中，本方发送的心跳对方无应答，且在一定时间(例如20秒)内都未收到对方心跳报文，对方疑似丢失，本方变慢心跳为快心跳，即刻探测对方存活性。快心跳发出后，若收到对方应答握手，快心跳即停止，表明对方存在；若无应答，继续1秒周期性发送快心跳，直到快心跳计数器溢出。如图3中的(a)所示为一次快心跳的过程，服务器A发起后设置200ms定时器，做有效应答的定时等待，发送方式为UDP广播，服务器B收到后，回复握手应答给服务器A。

慢心跳维护：在双方建立主备连接，进入同步运行状态后，15秒周期性的点对点的发送常规(慢)心跳，可节省链路资源。慢心跳采用UDP单播(即点对点)方式发送，定向发送给另一服务器(即通过快心跳建立连接的服务器)，发送后设置心跳应答定时器，等待对端回复，若对方超时无回复，进入快心跳探测，判断对方是否有丢失。如图3中的(b)所示为服务器A发起的常规/跳心跳，设置200ms定时器，做有效应答的定时等待，发送方式为点对点发送，服务器B收到后，回复握手应答给服务器A。

由上可知，本发明中快/慢心跳切换通常包括两种情况：1)开机时，探测状态发送快心跳，收到对方握手应答，切换为慢心跳；2)同步运行时发送慢心跳，在预设应答时间内仍未收到对方握手应答，切换为快心跳做探测。

其中，“预设应答时间”可通过心跳应答定时器与超时来实现，发出心跳(实施例中为快、慢心跳设置相等的预设应答时间)后，等待对方有效的握手应答的定时器，即为心跳应答定时器，一般设置为200毫秒，超时无应答或超过预设应答时间的应答都认为是无应答或无效应答。实施例中，快、慢心跳发送后，都有设有心跳应答定时器进行定时。

探测状态下发送快心跳，另同步运行时发送的慢心跳，在预设应答时间内仍未收到对方握手应答，亦切换为快心跳做探测，通常可设定探测多次，若探测多次仍未收到对方握手应答，即停止快心跳，进入独立服务模式。具体可通过快心跳计数器与溢出来实现，具体为：为快心跳探测设置一个计数器，并设置相应的阈值，如一般地阈值为5次。在探测时，快心跳会周期性持续发送，并通过计数器同时计数，若快心跳收到有效应答，计数器清0，停止快心跳过程并切换为慢心跳，表明对方存在；若未收到有效应答，计数器加1，直到计数器超出阈值(即溢出)，停止快心跳过程，并认定对端不存在，并进入独立运行状态。需要注意的是，等待心跳应答定时器200ms，快心跳发送周期为1s。发送一个快心跳，等200ms，看是否有应答，有应答则检测到对方存在，结束快心跳；无应答，到下一秒钟，再发一次快心跳，再等200ms，看是否有应答，如此进行五次(即计数器设定的阈值)，若连续五次都等不到有效应答，认为对方不存在，即结束快心跳进入独立运行状态，而不会无限制的进行快心跳。

本发明利用虚拟IP地址(即VIP地址)技术来实现双机热备的网络服务，即使用VIP技术使热备的双服务器共用IP地址上对外提供网络服务。

如图4所示，在本发明的网络模型中，两台热备的服务器，各自有一个自身的IP地址，即实际IP地址(或称实IP地址)，对客户端是不可见，仅可用于双机热备的心跳握手和主备协商。另外，系统还具有一个虚拟IP地址，是双机共用，并根据情况动态加载的，此IP地址暴露给用户，作为对外提供服务的IP地址。

双服务器通过心跳握手机制完成主备协商后，热备插件会自动将VIP地址分配给主服务器，使主服务器同一网卡对应两个IP地址，其中，虚拟IP与客户端通信，完成客户端请求的服务，实IP与备服务器之间维护心跳和主备切换；而备服务器即进入服务静默状态(客户端的服务请求被自动定向到主服务器，备服务器收不到客户端请求，即处于静默状)，仅监测主服务的状态，当探测确认主服务器不存在或出现异常后，获取到VIP地址，并对外提供工作。

值得注意的是，此时备服务器是进入独立运行状态还是切换为主服务器对为提供服务，需通过主备协商机制和探测过程来确定。例如，主服务器宕机了，探测不到，备服务器进入独立运行状态；在采用地址较小的一方为主机，大的一方为备机的协商机制时，主服务器换了个IP地址且IP地址变更大，探测后主备切换，即原来的主变成备，备变成主。热备插件通过软件化的方式给某服务器即网卡增加或删除(即加载和卸载)虚拟IP地址，根据操作系统的差异，有各自不同的实现方式。例如，Windows各类操作系统，可通过C++或C#编程的方式，利用MFC(微软基础类库)提供的接口和函数来实现。服务器常用Linux类操作系统，可通过调用system()函数，执行Shell命令的方式来实现VIP地址的加载和卸载，如system(“ifconfig eth2:0 192.168.8.100netmask 255.255.255.0up”)、system(“ifconfigeth2:0down”)。

在以太网中，MAC地址才是真正用来进行数据传输的物理地址，每台主机中都有一个ARP高速缓存，存储同一个网络内的IP地址与MAC地址的对应关系，以太网中的主机发送数据时会先从这个缓存中查询目标IP对应的MAC地址，随后会向这个MAC地址发送数据，即ARP查询。并且，操作系统会自动维护更新ARP缓存。

图5展示了两类操作系统下，安装本发明热备插件后，完成双机协商，主服务器加载了虚拟IP地址后，网卡上双IP地址与MAC地址对应的情况。

实施例中，主服务器上加载VIP地址后，ARP缓存的内容为：(使用ARP命令查看)：

结合图4所示，Server A和Server B的实IP地址分别是192.168.8.136和192.168.8.144，Server A为主服务器，192.168.8.100为双方共用的虚拟IP地址，192.168.8.100和192.168.8.136共享相同的MAC地址，即表明Server A作为主服务器，Server B作为备服务器存在。

如若Server A宕机后，Server B检测不到Server A的存在，双机热备插件会自动加载虚拟IP地址到Server B上。随即系统的ARP缓存将刷新为下表内容：

客户端再次发起服务请求，发往虚拟IP地址的报文，会重定向到Mac地址00:21:5a:db:7f:c2上了，即Server B上，Server B即取代Server A对外提供服务，即完成了双机热备的切换。

结合图6所示，实现网络服务双机热备的方法主要包括以下步骤：

步骤100：服务器开机启动，双机热备插件自动运行。

步骤101：热备插件开启时，双机热备状态默认为探测状态。

步骤102：探测状态下，发起快心跳探测，即对外广播发送快心跳，快心跳计数器+1。此时，若双方同时开机，故都处于探测状态，均会发起快心跳探测，并且都会应答对方，以完成主备协商；若双方不同时开机，后启动者处于探测状态，会发送快心跳探测，待收到回复，即互相知道对方存在，从而完成主备协商。

步骤103：启动心跳应答定时器等待应答，根据应答时效内的应答情况，分别进入104或105步骤，见下文。

步骤104：若收到对方服务器的心跳握手应答，停止心跳应答定时器，快心跳计数器清0，跳转到同步运行状态，并根据预设在热备插件中的双方握手协商的机制分配主、备服务器，具体如下：

本服务器若协商为主服务器，则进入1041～1045步骤运行，如图6中同步运行中的实线流程；

步骤1041：进入同步运行状态，且为协商为主服务器，将VIP地址加载给主服务器；这里的VIP地址预设在热备插件的配置文件中，即两台服务器以此为共用的IP地址对外服务，并将此IP地址暴露给客户端，客户端到此IP地址上请求服务。

步骤1042：主服务器通过VIP地址，对客户端提供服务，同时若收到对方心跳，予以握手应答；

步骤1043：主服务器周期性的发起慢心跳，做主备维护，并启动心跳应答定时器；

步骤1044：若心跳应答握手成功，停止心跳应答定时器，双机热备状态无变化，等待下一次心跳维护；

步骤1045：若心跳应答定时器超时无应答，卸载VIP地址，跳转到探测状态，进入101步骤，探测备服务器的存在性。

若协商为备服务器，则进入1046～1048步骤运行，如图6中同步运行中的虚线流程；

步骤1046：进入同步运行状态，且为协商为备服务器，进入服务静默状态，若收到对方心跳，予以握手应答；

步骤1047：备服务器周期性的发起慢心跳，做主备维护，并启动心跳应答定时器；

步骤1048：若心跳应答握手成功，停止心跳应答定时器，双机热备状态无变化，等待下一次心跳维护；若心跳应答定时器超时无应答，跳转到探测状态，进入101步骤，探测主服务器的存在性。

步骤105：若心跳应答定时器超时仍未收到对方应答，比较快心跳计数器和阈值，若快心跳计数器<＝阈值，回到101步骤，继续探测；若快心跳计数器>阈值，跳转到106步骤。例如，1.0s时刻发送快心跳，1.2s时未收到应答，定时器即超时，在下一个周期，即2.0s时刻，再次发送快心跳，直到5.0s发送，5.2s再超时，判断超出阈值，认为探测不到对方，跳到106步骤。

步骤106：快心跳探测认为对方不存在，快心跳计数器清0，服务器进入到独立运行状态，具体见步骤1061～1065：

步骤1061：探测后进入独立运行状态，将VIP地址加载给本服务器；

步骤1062：本服务器即为独立服务器，通过VIP地址，对客户端提供服务，本状态不发送任何心跳；

步骤1063：若独立服务器收到其他服务器发来的心跳报文，予以握手应答；

步骤1064：若双方的心跳的握手协商表明本方应为备服务器，本方即卸载VIP地址，热备状态跳转到同步运行状态，服务器进入备服务器模式，即1046步骤；

步骤1065：若双方的心跳的握手协商表明本方应为主服务器，热备状态跳转到同步运行状态，服务器进入主服务器模式，即1042步骤。

综上可见，通过本发明的方法，无需客户端轮询查找主/备服务器，仅需对固定的一个IP地址(即主/备服务器共用的虚拟IP地址)做服务请求，即可完成双服务器服务模式，有效避免了客户端和用户负担的增加。该方法无需修改原服务器上的服务程序，仅需在服务器上通过安装热备插件，并将插件配置为开机自启动的方式，即可软件化的实现双机热备。这种方法很容易用于双服务器的部署，也非常有利于原来单服务器工作的系统，实现双机热备的升级。

尽管以上结合附图对本发明的实施方案进行了描述，但本发明并不局限于上述的具体实施方案和应用领域，上述的具体实施方案仅仅是示意性的、指导性的，而不是限制性的。本领域的普通技术人员在本说明书的启示下，在不脱离本发明权利要求所保护的范围的情况下，还可以做出很多种的形式，这些均属于本发明保护之列。

Claims (9)

1.一种实现网络服务双机热备的方法，其特征在于，服务器运行双机热备插件，并进入探测状态、独立运行状态或同步运行状态，具体如下：

探测状态下，服务器发送快心跳，在第一预设应答时间内未收到其他服务器的握手应答，自动获取并加载虚拟IP地址，并进入独立运行状态；在第一预设应答时间内收到另一方服务器的握手应答后建立主备连接，通过主备协商机制完成主备协商，协商为主服务器的一方自动获取并加载虚拟IP地址，随后进入同步运行状态；

同步运行状态下，主服务器通过虚拟IP地址为客户端提供服务；协商为备服务器的一方进入服务静默状态；主、备服务器周期性的点对点的发送慢心跳，并等待对方回复，在第二预设应答时间内接收到对方心跳时予以握手应答以进行主备同步维护，若在第二预设应答时间内接收不到对方心跳时进入探测状态；

独立运行状态下，服务器通过虚拟IP地址为客户端提供服务；

所述快心跳采用UDP广播方式发送，所述慢心跳采用UDP单播方式发送。

2.如权利要求1所述的方法，其特征在于，独立运行状态下，不发送心跳。

3.如权利要求1所述的方法，其特征在于，所述主备协商机制是指通过心跳报文和心跳握手应答报文中携带的信息商定主备关系，或者通过预先设定的主备判定方式来确定主备关系。

4.如权利要求1所述的方法，其特征在于，还包括设置心跳应答定时器，用于对应答时间进行计时；在探测状态下，服务器发送快心跳，并通过心跳应答定时器对对方的应答时间进行计时；在同步运行状态下，主、备服务器周期性的点对点的发送慢心跳，并通过心跳应答定时器对对方的应答时间进行计时。

5.如权利要求1所述的方法，其特征在于，还包括设置心跳计数器，用于对快心跳进行计数；在探测状态下，服务器发送至少两次快心跳，并启动心跳计数器：若在第一预设应答时间内收到另一方服务器的握手应答，心跳计数器清0，并进入同步运行状态；若在第一预设应答时间内未收到其他服务器的握手应答，心跳计数器加1，直到心跳计数器溢出，则认定对端不存在，并进入独立运行状态。

6.如权利要求1所述的方法，其特征在于，在同步运行状态下，备服务器在第二预设应答时间内接收不到主服务器心跳或握手应答时进入探测状态，在探测状态下仍探测不到对方后自动加载虚拟IP地址，并进入独立运行状态，为客户端提供服务。

7.如权利要求6所述的方法，其特征在于，备服务器在探测状态下探测到对方出现异常后；根据主备协商机制切换重新确定主、备服务器，协商为主服务器的一方自动加载虚拟IP地址，为客户端提供服务。

8.如权利要求7所述的方法，其特征在于，探测到对方出现异常是指与主备协商机制相关的状态或参数发生变化。

9.一种服务器，其特征在于，所述服务器包括网卡，所述服务器装有开机时自动启动运行的双机热备插件，所述双机热备插件在运行时执行如权利要求1至8任意一项所述的方法。

Images