[0001] 本发明关于一种具备容错机制的主机系统。

[0002] 主机内的虚拟机通过不间断地将虚拟机的外设输入/输出的状态以及存储器的状态完全地备份至备份主机，使得备份主机内形成完全相同于虚拟机的备份虚拟机，藉此实现虚拟机的容错机制。当虚拟机欲传送数据封包至客户端装置时，为了使备份虚拟机的状态与外界状态保持一致，主机内的虚拟机监控层将欲传送的数据封包进行暂存，直到虚拟机的外设输入/输出的状态以及存储器的状态完全地备份至备份主机之后，虚拟机监控层才将欲传送的数据封包传送至客户端装置。当客户端装置接收到来自主机的数据封包后，客户端应用程序回传确认封包至主机。

[0003] 然而，当主机启动容错机制时，将使得数据封包的往返时间(round trip time)急遽增加，其中所增加的时间即是执行容错机制的运作状态(running state)、快照状态(snapshot state)、传送状态(transfer state)以及备份完成状态(flush output state)的所需时间的总合。依据目前传输控制协议(TCP)对于网络的壅塞控制，当数据封包的往返时间变长时，将使网络传输速率大幅降低。由此可知，主机启动容错机制后虽然能达到状态备份的目的，但反而造成网络传输速率下降的缺点。

[0004] 有鉴于此，目前的确有需要一种改良的容错系统，除了能达到状态备份的目的之外，也能改善网络传输速率下降的缺点。

[0020] 以下在实施方式中详细叙述本发明的详细特征以及优点，其内容足以使任何熟习相关技艺者了解本发明的技术内容并据以实施，且根据本说明书所公开的内容、权利要求书及附图，任何熟习相关技艺者可轻易地理解本发明相关的目的及优点。以下的实施例进一步详细说明本发明的观点，但非以任何观点限制本发明的范畴。

[0021] 图1是根据本发明容错系统的第一实施例所绘示的功能方块图。如图1所示，本发明的容错系统可适用于FTP、TFTP、WGET或SSH等环境，其中该容错系统包含第一主机100及第二主机200，该第一主机100通过局域网络(local network)与该第二主机200进行通信连接，第一主机100还通过因特网(internet)与客户端装置C进行通信连接，所述通信连接包含单向通信和/或双向通信。第一主机100以及第二主机200例如为两台具有相同硬件架构的云端服务器，至于客户端装置C例如为个人计算机、移动通信装置、笔记本电脑、平板计算机或服务器。

[0022] 第一主机100包含有电路板10、中央处理器11以及存储器12，该电路板10例如为主板，而该中央处理器11与该存储器12设于该电路板10且该中央处理器11与该存储器12彼此电性连接。该存储器12储存有虚拟机13(virtual machine)、虚拟机监控程序14(virtual machine monitor)以及传输控制协议代理15(TCP agent)等软件，该中央处理器11用于执行虚拟机13、虚拟机监控程序14以及传输控制协议代理15等软件。虚拟机13的状态包含虚拟机13的外设输入/输出的状态以及虚拟机13的存储器的状态，虚拟机监控程序14用于接收外部指令，当该外部指令的内容为启动虚拟机13的容错机制，则虚拟机监控程序14将驱使虚拟机13启动容错机制。当虚拟机13运行容错机制时，虚拟机13会执行状态转移(migration)。所谓状态转移意即虚拟机13的状态转移至第二主机200，使得第二主机200内产生备份虚拟机20，而备份虚拟机20的状态与虚拟机13的状态完全一致。在其他实施例中，虚拟机13以及传输控制协议代理15亦可分别位于不同的主机而通过局域网络进行通信。当客户端装置C欲传送数据流至第一主机100的虚拟机13(incoming path)时，传输控制协议代理15用于接收来自客户端装置C的数据流，当传输控制协议代理15确认完全地接收到来自客户端装置C的数据流后，传输控制协议代理15传送确认封包(acknowledge)至客户端装置C。相较于以往的容错系统由虚拟机发送确认封包给客户端装置，本发明的容错系统在回传确认封包的时间点明显较以往的容错系统提前许多。

[0023] 除此之外，第一主机100的传输控制协议代理15还用于判断虚拟机13是否启动容错机制以及判断虚拟机13的状态是否完全地备份至第二主机200。容错机制的一个周期内包含有运作状态(running state)、快照状态(snapshot state)、传送状态(transfer state)以及备份完成状态(flush output state)等四个时段。详言之，运作状态意即第一主机100的虚拟机13持续运作的时段，快照状态意即将虚拟机13的状态进行备份的时段，传送状态意即将虚拟机13的状态的备份转移至第二主机200的时段，而备份完成状态意即虚拟机13的状态完全地转移至第二主机的时段。在本实施例中，采用多线程(multithreading)的方式实现虚拟机13的容错机制，因此对于虚拟机13而言，运作状态以及快照状态持续地循环，至于传送状态以及备份完成状态则于后台执行。

[0024] 图2是根据本发明容错系统的控制方法的第一实施例所绘示的流程图。共同参阅图1与图2，在步骤S101中，以第一主机100的中央处理器11执行传输控制协议代理15，以接收来自客户端装置C的数据流，其中数据流包含多个不同时序的数据封包。在步骤S102中，以传输控制协议代理15对数据流加入辨识戳记，其中辨识戳记用于表示传输控制协议代理15接收数据流的接收时间点。在步骤S103中，当传输控制协议代理15完全地接收到来自客户端装置C的数据流之后，以传输控制协议代理15响应确认封包至客户端装置C，以供客户端装置C的客户端应用程序进行读取。在步骤S104中，以传输控制协议代理15判断虚拟机13是否启动容错机制(fault tolerance mechanism)，当传输控制协议代理15确认虚拟机13已启动容错机制，则接续步骤S105：以传输控制协议代理15判断虚拟机13是否处于运作状态。当传输控制协议代理15确认虚拟机13未启动容错机制(fault tolerance mechanism)，则接续步骤S106：以传输控制协议代理15传送数据流至虚拟机13。当虚拟机13完全地接收到来自传输控制协议代理15的数据流之后，虚拟机13传送确认封包至传输控制协议代理
15。

[0025] 当传输控制协议代理15确认虚拟机13未处于运作状态时，则接续步骤107：以传输控制协议代理15暂存数据流，且接续至步骤S105。当传输控制协议代理15确认虚拟机13处于运作状态时，则接续步骤108：以传输控制协议代理15传送数据流至虚拟机13。

[0026] 客户端装置C接收到来自传输控制协议代理15的确认封包的第一时间点减去客户端装置C开始传送数据流至第一主机100的第二时间点即为数据流的往返时间(round trip time)。处于传输控制协议(TCP)的壅塞控制机制的网络环境下，当往返时间越短，相对地网络传输速度也越快。

[0027] 图3为绘示图2的传输控制协议代理判断虚拟机是否启动容错机制的实施例的流程图。如图3所示，步骤S104包含子步骤S104-1至子步骤S104-3。在子步骤S104-1中，以传输控制协议代理15判断是否接收到来自虚拟机13的行程间通信封包(Inter-Process Communication Packet，IP Packet)。当传输控制协议代理15确认接收到来自虚拟机13的行程间通信封包，接续执行步骤S104-2：以传输控制协议代理15确认虚拟机13已启动容错机制，详言之，启动容错机制的虚拟机13会连续地传送不同时序的行程间通信封包至传输控制协议代理15，而每行程间通信封包记载有虚拟机的状态，而行程间通信封包内记载的虚拟机的状态为运作状态、快照状态、传送状态以及备份完成状态的其中一者。当传输控制协议代理15确认未接收到来自虚拟机13的行程间通信封包，执行步骤S104-3：以传输控制协议代理15确认虚拟机13未启动容错机制。

[0028] 图4是根据本发明容错系统的控制方法的第二实施例所绘示的流程图，而图4的实施例与图2的实施例的差异为图4还包括下列步骤S109至步骤S111。如图4所示，以传输控制协议代理15传送数据流至虚拟机13之后，在步骤S109中以传输控制协议代理15判断虚拟机13是否处于故障状态。当传输控制协议代理15确认虚拟机13处于故障状态时，则接续步骤S110。由于虚拟机13的故障很可能导致先前传送至虚拟机13的数据流遗失，因此，在步骤S110中，以传输控制协议代理15将先前已传送至虚拟机13的数据流再次传送至虚拟机13。
执行步骤S110之后，接续步骤S111：以传输控制协议代理15判断虚拟机13是否将虚拟机13的状态完全地备份至第二主机200(即容错机制的备份完成状态)。当传输控制协议代理15确认虚拟机13的状态完全地备份至第二主机200，则接续步骤S112：以传输控制协议代理15释出数据流。当传输控制协议代理15确认虚拟机13的状态并未完全地备份至第二主机200，则从步骤S111再次回到步骤S109。当传输控制协议代理15确认虚拟机13未处于故障状态时，接续执行步骤S111。

[0029] 由于传输控制协议代理15的数据处理排程是每隔一固定时间区一次处理多笔网络封包，若将行程间通信封包(IPC packet)也导入传输控制协议代理15的数据处理排程，传输控制协议代理15读取到的虚拟机状态即为最新的行程间通信封包内所记载的虚拟机状态。假设最新的行程间通信封包内所记载虚拟机13的状态为备份完成状态，若时间点位于最新的行程间通信封包之前的至少一个行程间通信封包所记载的虚拟机13的状态亦为备份完成状态，以虚拟机13传送数据流至客户端装置C的路径而言，传输控制协议代理15没有实时处理每一个行程间通信封包，将延迟传输控制协议代理15将先前暂存数据流传送至客户端装置C的时间点。因应上述可能发生的问题，设计传输控制协议代理15可实时处理每一个行程间通信封包。

[0030] 因此，本发明还提供容错系统的第二实施例。图5是根据本发明容错系统的第二实施例所绘示的功能方块图。图5与图1的差异在于存储器12内还储存有行程间通信封包监控程序16，而中央处理器11用于执行行程间通信封包监控程序16。图6是根据图5的容错系统执行行程间通信封包监控程序的实施例所绘示的流程图。本发明的容错系统的控制方法，除了前述数据流的容错机制控制之外，还包括以中央处理器11执行行程间通信封包监控程序16，且可设定传输控制协议代理15最优先处理行程间通信封包。如图6所示，在步骤S201中，以传输控制协议代理15于多个不同时间点接收来自虚拟机13的多个行程间通信封包。在步骤S202中，以传输控制协议代理15于所述时间点分别实时地读取所述行程间通信封包的内容，藉此实时地取得虚拟机13于所述时间点的状态。详言之，已启动容错机制的虚拟机
13会持续地传送行程间通信封包至传输控制协议代理15，因此传输控制协议代理15可实时处理每一笔行程间通信封包，藉此取得实时的虚拟机状态。反之未启动容错机制的虚拟机
13不会输出任何行程间通信封包。

[0031] 图7是根据本发明容错系统的控制方法的第三实施例所绘示的流程图。如图7所示，在步骤S301中，以第一主机100的中央处理器11执行传输控制协议代理15，以接收来自虚拟机13的数据流，其中该数据流包含多个不同时序的数据封包。在步骤S302中，以传输控制协议代理15对数据流加入辨识戳记，其中辨识戳记用于表示传输控制协议代理15接收数据流的接收时间点以及数据流于接收时间点的状态。在步骤S303中，当传输控制协议代理15完全地接收到来自虚拟机13的数据流之后，以传输控制协议代理15响应确认封包至虚拟机13。在步骤S304中，以传输控制协议代理15判断虚拟机13是否启动容错机制，当传输控制协议代理15确认虚拟机13已启动容错机制，则接续步骤S305：以传输控制协议代理15判断虚拟机13的状态是否完全地备份至第二主机200。当传输控制协议代理15确认虚拟机13未启动容错机制，则接续步骤S306：以传输控制协议代理15传送数据流至客户端装置C。当客户端装置C完全地接收到来自传输控制协议代理15的数据流之后，客户端装置C将回传确认封包给传输控制协议代理15。

[0032] 在步骤S305中，当传输控制协议代理15确认虚拟机13的状态并未完全地备份至第二主机200，则接续步骤307：以传输控制协议代理15暂存数据流。当传输控制协议代理15确认虚拟机13的状态完全地备份至第二主机200，则接续步骤308：以传输控制协议代理15传送数据流至客户端装置C。步骤S309接续于步骤S308之后，在步骤S309中，当客户端装置C完全地接收到来自传输控制协议代理15的数据流之后，客户端装置C响应确认封包给传输控制协议代理15，传输控制协议代理15读取来自客户端装置C的确认封包之后，以传输控制协议代理15释出数据流。

[0033] 由于传输控制协议代理15与虚拟机13之间的通信连接通常通过局域网络或者为同一主机内的信息传递，而传输控制协议代理15与客户端装置C之间的通信通常通过因特网，因此传输控制协议代理15与虚拟机13之间的第一数据传输速度通常远高于传输控制协议代理15与客户端装置C之间的第二数据传输速度。以虚拟机13传送数据至客户端装置C的路径而言，当过多的数据封包累积于传输控制协议代理15而未被处理，有可能发生存储器资源(resource)耗尽以及数据封包遗失的情况。为了解决上述问题，本发明还提供容错系统的第三实施例。图8是根据本发明容错系统的第三实施例所绘示的功能方块图。图8与图1的差异在于存储器12内还储存有传输速度监控程序17，而中央处理器11用于执行传输速度监控程序17。

[0034] 本发明的容错系统的控制方法，除了前述的数据封包的容错机制控制及行程间通信封包监控程序之外，还包括以中央处理器11执行数据传输速度监控程序。图9是依据图8的容错系统执行数据传输速度监控程序的实施例所绘示的流程图。如图9所示，在步骤S401中，以传输控制协议代理15判断传输控制协议代理15与虚拟机13之间的第一数据传输速度。在步骤S402中，以传输控制协议代理15判断传输控制协议代理15与客户端装置C之间的第二数据传输速度，其中第二传输速度小于第一数据传输速度。在其他实施例中，步骤S401及步骤S402的先后顺序可对调。在步骤S403中，以传输控制协议代理15依据第二数据传输速度以传输控制协议窗口算法(TCP Window Control)降低第一数据传输速度。详言之，第一主机100的底层硬件储存有虚拟机13的主机操作系统(host OS)以及传输控制协议代理15的主机操作系统，而虚拟机13的主机操作系统可相同或不同于传输控制协议代理15的主机操作系统。虚拟机13的主机操作系统可建立虚拟机13的多个属于传输控制协议的第一窗口，传输控制协议代理15的主机操作系统可建立传输控制协议代理15的多个属于传输控制协议的第二窗口。当虚拟机13传送数据封包至传输控制协议代理15时，传输控制协议代理
15的主机操作系统响应确认封包至虚拟机13的主机操作系统，藉此将目前未填入数据封包的第二窗口的个数的信息提供给虚拟机13的主机操作系统，而虚拟机13依据确认封包的内容以决定是否继续传送数据封包至传输控制协议代理15。当传输控制协议代理15的所有第二窗口都已填满数据封包时，虚拟机13将无法传送数据封包至传输控制协议代理15，直到传输控制协议代理15从所述第二窗口之中提出数据封包为止。

[0035] 通过传输控制协议窗口算法降低传输控制协议代理15与虚拟机13之间的第一传输速度可包含多个实施态样，在一实施态样中，当第一主机100的剩余存储器资源(resource)大于或等于预设百分比下限时，传输控制协议代理15不会从所述第二窗口中撷取任何数据封包，直到第一主机100的剩余存储器资源小于百分比下限时，传输控制协议代理15才从所述第二窗口之中撷取数据封包。在另一实施态样中，当传输控制协议代理15的所述第二窗口都填满数据封包时，传输控制协议代理15才从所述第二窗口之中撷取数据封包。

[0036] 当容错系统具有多个虚拟机且每虚拟机的容错机制周期没有完全相同，则必须进一步控制每虚拟机处理的数据量。每虚拟机的分配流量(位/秒)的公式为：(容错系统欲传输至客户端装置的总数据量)/虚拟机个数，每虚拟机于一个容错机制周期的处理数据量的公式为：分配流量*容错机制周期(epoch time)。在其他实施例中，可依据每虚拟机所处理的数据种类的重要程度决定每虚拟机的优先程度，而对于优先程度最高的虚拟机，将设定特定的数据传输量(Priority Scheduling Algorithm)。在其他实施例中，对于每虚拟机设定最低保证带宽(Guaranteed Minimum Transmission Algorithm)，假设虚拟机的最低保证带宽设定为X兆位/秒，则虚拟机的最低传送数据量的公式为 兆位/秒，其中n为经过时间，t为总传输数据量。

[0037] 综上所述，本发明的容错系统及其控制方法，由于将响应确认封包以及暂存数据封包的工作改由传输控制协议代理来处理。如此一来，无论是虚拟机或是客户端应用程序接收到确认封包的所需时间都可大幅缩短，相对地使得数据封包的往返时间也大幅缩短。反之当目前的虚拟机的容错机制开启后，必须等待运作状态、快照状态、传送状态以及备份完成状态都处理完毕后，虚拟机才能收到确认封包。上述四个状态的处理时间使得收到确认封包的所需时间急遽增长，相对地使得往返时间急遽增长。在相同的传输控制协议(TCP)进行网络壅塞控制的网络环境下，当往返时间越短，网络传输速度则越快，因此本发明的容错系统相较于以往的容错系统的确具有较佳的网络传输速度，当网络传输速度较快时，相对地降低数据传输时所需的时间。

[0038] 【符号说明】

[0039] 100 第一主机

[0040] 200 第二主机

[0041] 10 电路板

[0042] 11 中央处理器

[0043] 12 存储器

[0044] 13 虚拟机

[0045] 14 虚拟机监控程序

[0046] 15 传输控制协议代理

[0047] 16 行程间通信封包监控程序

[0048] 17 数据传输速度监控程序

[0049] 20 备份虚拟机

[0050] C 客户端装置