CN106059936B - 云系统组播文件的方法及装置 - Google Patents

Abstract

本发明提供的云系统组播文件的方法及装置，有效解决了云系统中传输大文件到海量的实例系统时高带宽占用率以及整体完成时间过长的问题，通过组播方式传输文件，大大降低了带宽占用。组播的数据包中包括了文件偏移量，传输的文件不受数据包乱序的影响。此外，如果组播大范围失败，可以在局部系统中选择一个实例系统代表从控制节点获取需要传输的文件，由实例系统代表在局部系统内部传输，不影响局部系统之外的其他实例系统。

Description

云系统组播文件的方法及装置

技术领域

本发明涉及云系统组播文件的方法及装置。

背景技术

某种操作系统(例如安卓操作系统)加上运行该操作系统所需的必要硬件(例如处理器、存储器等)，可以视为一个实例系统，实例系统中可以运行各种应用(应用指能够在实例系统的操作系统中运行的软件或程序)。将若干个实例系统按照一定的架构方式(例如分布式)集中管理，可以形成云系统。通常云系统由运营商负责日常运营，为用户提供服务。

很多情况下，运营商需要把某个应用安装到大量的实例系统上，或者对所有实例系统的操作系统进行升级(例如该操作系统发布了重大安全补丁)。目前常见的做法，云系统的控制节点(例如具有X86架构的控制服务器，用于控制和管理云系统中的实例系统)通过TCP协议(Transmission Control Protocol，传输控制协议)多线程并行对所有的实例系统推送应用安装包或者操作系统升级包。基于TCP方式的稳定性，运营商不需要考虑数据包丢包或者包乱序的问题。但这种做法的缺点也非常明显，如果需要推送的文件较大，一台高性能服务器同时推送到几十个实例系统就已经达到上限。即使控制节点的性能非常强大，并发推送同一个大文件到成千上万个实例系统，也避免不了大量实例系统排队等待的情况。为了实现快速推送，可以在云系统中大量配备高性能服务器，但这非常不经济。此外，并发推送大文件会产生高带宽占用，可能影响云系统中其他服务(例如推送音视频流服务)的流畅运行。

在说明书“背景技术”部分公开的内容，有助于本领域技术人员理解本发明的技术方案，但不应据此认为这些内容一定属于现有技术或公知常识。

发明内容

为了克服“背景技术”部分所反映的缺陷，本发明提供云系统组播文件的方法及装置。

云系统组播文件的方法，包括：

1)控制节点分配组播IP与端口号，通知所有相关的实例系统加入组播组。

2)控制节点通知存储模块加入组播组，以数据包形式组播需要传输的文件。

3)实例系统根据通知创建文件，循环接收存储模块组播的数据包。

进一步的，1)中，通知包括需要传输的文件的文件名、文件验证值、文件大小以及组播组名、端口号。

进一步的，2)中，需要传输的文件被分割为多个数据块，组播的数据包包括数据块和文件偏移量。

进一步的，3)中，实例系统将接收的数据包中的数据块按照文件偏移量写入创建的文件。

进一步的，3)中，实例系统每接收一个数据包则实时合并所有已接收的数据块在创建的文件中的范围。

更进一步的，3)中，如果实例系统接收数据包尚未结束，实时合并的结果存在至少一处间断，则实例系统针对每处间断设定继续接收数据包的阈值；如果任何一处间断在实例系统继续接收设定阈值的数据包后仍未被填补，则实例系统退出组播组。

云系统组播文件的装置，包括存储模块，存储模块用于将需要传输的文件分割为多个数据块，生成包括数据块和文件偏移量的数据包并组播数据包。

云系统组播文件的装置，包括实例系统，实例系统用于将接收的数据包中的数据块按照文件偏移量写入创建的文件，还用于每接收一个数据包则实时合并所有已接收的数据块在创建的文件中的范围。

由于云系统组播文件的装置，与之前所述的云系统组播文件的方法具有明确的关联性，为了避免不必要的重复，云系统组播文件的装置中的一些描述进行了省略。本领域技术人员通过对照，能够对云系统组播文件的装置有清晰、完整的认识。

云系统组播文件的方法，包括：

在包括内部交换机和多个实例系统的局部系统中选择一个实例系统代表，实例系统代表从控制节点获取需要传输的文件，在局部系统内部传输。

进一步的，内部传输包括实例系统代表在局部系统中使用控制节点单独分配的组播组内部组播。

本发明技术方案中，“包括”、“用于”等词语应按照开放式表达方式理解。本领域技术人员通过阅读本说明书并结合现有技术或公知常识能够获知的内容，本说明书中不再赘述。

本发明提供的云系统组播文件的方法及装置，有效解决了云系统中传输大文件到海量的实例系统时高带宽占用率以及整体完成时间过长的问题，通过组播方式传输文件，大大降低了带宽占用。组播的数据包中包括了文件偏移量，传输的文件不受数据包乱序的影响。此外，如果组播大范围失败，可以在局部系统中选择一个实例系统代表从控制节点获取需要传输的文件，由实例系统代表在局部系统内部传输，不影响局部系统之外的其他实例系统。

附图说明

图1为具体实施方式中云系统组播文件的方法的流程图。

图2为具体实施方式中云系统的控制节点、实例系统和存储模块的关系示意图。

具体实施方式

下面对本发明的实施方式进行进一步的具体说明。但应注意，本发明的范围并不局限于所描述的具体技术方案。任何对所描述的具体技术方案中的技术要素进行相同或等同替换获得的技术方案或本领域技术人员在所描述的具体技术方案的基础上不经过创造性劳动就可以获得的技术方案，都应当视为落入本发明的保护范围。

某种操作系统加上运行该操作系统所需的必要硬件(例如处理器、存储器等)，可以构成一个实例系统。将若干个实例系统按照一定的架构方式集中管理，可以形成云系统。

云系统组播文件的方法，采用组播(组播是IP网络数据传输的三种方式之一，在发送者和每一接收者之间实现点对多点网络连接)方式来传输文件。这样云系统的控制节点(控制节点用于控制和管理云系统中的全部或部分实例系统，作为一种实施方式，由具有X86架构的控制服务器实现)进行一次文件传输，所有加入了组播组的实例系统都能接收该文件，大大提高了并行性，同时降低了网络带宽占用。目前组播只能通过UDP协议(UserDatagram Protocol，用户数据报协议)实现，如果网络传输质量较差，UDP协议数据包丢包会比较严重。由于云系统传输文件使用的是内部建立的局域网，网络传输质量很高，不容易丢包，UDP协议很适合这种场景。当然，为了最大可能避免丢包，数据包发送方需要进行限速，以便和数据包接收方的处理速度匹配，同时数据包接收方要设置足够大的socket(当网络上两个程序通过一个双向的通信连接实现数据交换时，这个连接的一端称为一个socket)接收缓存。

云系统组播文件的方法，如图1所示，包括如下步骤：

S101：控制节点分配组播IP与端口号，通知所有相关的实例系统加入组播组。

具体的，本步骤中，当云系统的控制节点收到传输文件(特别是传输大文件)到很多个实例系统的请求时，先分配一个组播IP(组播IP应当和云系统中已经使用的IP不冲突)与端口号，TCP多线程并行通知所有相关的实例系统加入设置好的组播组，准备接收数据。该TCP通知包括需要传输的文件的文件名、文件验证值、文件大小(也可以称为文件长度或文件总长度)以及组播组名、端口号等信息，其中文件验证值常选用MD5(消息摘要算法第五版，为广泛使用的一种散列函数，用以提供消息的完整性保护)。实际中往往会有控制节点认为某个实例系统需要接收某个文件而该实例系统中已经存在该文件的情况，因此实例系统收到TCP通知后，可以将其中的信息与实例系统的存储器上已有的文件进行比对，如果存储器上的某个文件与TCP通知中需要传输的文件的文件名、MD5、文件大小三者都相同，则该实例系统直接退出组播组并报告控制节点接收成功，这样可以避免无意义的文件传输，节约云系统的资源。

S102：控制节点通知存储模块加入组播组，以数据包形式组播需要传输的文件。

具体的，本步骤中，控制节点通知存储模块加入组播组。通常，存储模块位于云系统中独立的高性能存储服务器(存储服务器一般具有较高的配置，例如8核处理器、64G大内存等)上，存储了需要传输给很多个实例系统的文件(特别是大文件)。存储模块将需要传输的文件分割为多个数据块，生成数据包(UDP包)。每个数据包都包括数据块和文件偏移量(从指定位置向前或向后移动的字节数)，为了尽可能方便的实现本发明技术方案，数据包中往往还包括数据块大小(也可以称为数据块长度)。存储模块组播需要传输的文件，实质上是组播UDP包。如果所有的UDP包发送完成，则存储模块退出组播组，并报告控制节点发送成功。反之，如果因磁盘IO异常等情况导致UDP包发送失败，则存储模块退出组播组，并报告控制节点发送失败。

S103：实例系统根据通知创建文件，循环接收存储模块组播的数据包。

具体的，本步骤中，实例系统根据之前收到的TCP通知，在实例系统的存储器上选择合适的位置，按照文件名和文件大小创建一个新文件。实例系统不断重复接收数据包的操作，循环接收组播的数据包(UDP包)。为了避免循环接收导致无限等待UDP包，实例系统可以设置socket接收时限，如果超过时限仍未收到UDP包则认为UDP包的发送已经终止或失败，接收UDP包的过程结束。

对于接收的UDP包，实例系统将UDP包中的数据块直接按照文件偏移量写入创建的文件。由于UDP包中附带了文件偏移量，数据块能够写入正确的位置，UDP包出现乱序对实例系统接收文件没有影响。同时，实例系统每接收一个数据包，则实时合并所有已接收的数据块在创建的文件中的范围。正常情况下，UDP包是按照数据块在需要传输的文件中的先后顺序依次发送的，实时合并的结果就是从文件起始位置到当前偏移(中间没有间断)。如果合并的结果是从文件起始位置到文件结尾位置(由于文件大小已知，每个数据块的文件偏移量和数据块大小也已知，很容易计算出是否已经达到文件结尾位置)，中间没有间断，则意味着所有的UDP包都已接收，接收UDP包的过程结束。

考虑到UDP包可能存在乱序或丢包情况，为了避免文件传输错误，设置这样一个判断规则：如果实例系统接收UDP包的过程尚未结束，实时合并的结果存在至少一处间断，则实例系统针对每处间断设定继续接收UDP包的阈值；如果任何一处间断在实例系统继续接收设定阈值的UDP包后仍未被填补，则实例系统退出组播组并报告控制节点接收失败。设置这个判断规则基于如下考虑：由于UDP包在组播过程中可能乱序，实时合并的结果如果存在间断，间断可能会被后来接收的迟到UDP包填补。但如果实例系统继续接收一定数量的UDP包后间断仍未被填补，则意味着可能UDP包的发送速度远大于实例系统的接收速度，或者实例系统的处理器被别的进程大量占用，UDP包已经丢包，间断后续再被填补的可能性不大。继续接收UDP包的阈值，可根据存储模块分割形成的UDP包的数量、网络情况等因素综合考虑设定。如果实时合并的结果存在多于一处的间断，可以为不同间断设定不同的继续接收UDP包的阈值，当然通常情况下对不同间断设定相同的阈值是简单而有效的。

注意，设置socket接收时限和设定继续接收UDP包的阈值这两个条件要同时使用。例如，实时合并的结果是从文件起始位置到文件结尾位置，但存在至少一处间断，超过设置的socket接收时限仍未接收到UDP包，则最可能的原因是UDP包的发送已经结束，确实存在丢包，文件传输失败。

实时合并的结果是从文件起始位置到文件结尾位置，也不存在间断，并不意味着文件传输就一定成功了，实例系统还要检查创建的文件的文件大小和MD5是否和TCP通知中需要传输的文件的文件大小和MD5一致，两者都一致，文件才算真正的传输成功，否则仍视为传输失败。无论最终的结果是文件传输成功还是失败，实例系统都将相应的结果通知控制节点。

下面通过一个理想化的简单示例进一步展示S102和S103的工作过程。实例系统收到的TCP通知显示需要传输一个名称为ust、大小5KB的文件，则实例系统在存储器上选择合适的位置，创建一个名称为ust、大小5KB的新文件。实例系统设置socket接收时限为2秒。

存储模块将需要传输的ust文件分割为5个数据块，每个数据块1KB，生成5个UDP包，每个UDP包中包括1KB的数据块和文件偏移量(从ust的起始位置计算，分别为0K、1K、2K、3K、4K)。

情形1：正常情况，存储模块按照文件偏移量0K、1K、2K、3K、4K的顺序发送UDP包，实例系统也按照文件偏移量0K、1K、2K、3K、4K的顺序接收UDP包。

实例系统接收文件偏移量0K的UDP包，按照文件偏移量从创建的ust文件的起始位置写入数据块，并实时合并所有已接收的数据块在创建的文件中的范围，实时合并的结果是创建的ust文件0K到1K的范围被写入数据；实例系统接收文件偏移量1K的UDP包，按照文件偏移量从距离创建的ust文件起始位置1K的位置写入数据块，并实时合并所有已接收的数据块在创建的文件中的范围，实时合并的结果是创建的ust文件0K到2K的范围被写入数据，中间无间断。依次类推，当实例系统接收5个UDP包后，创建的ust文件0K到5K的范围都被写入数据，中间无间断，这意味着所有的UDP包都已接收，接收UDP包的过程结束。实例系统还要检查创建的ust文件的大小和MD5是否和TCP通知中ust文件的大小和MD5一致，两者都一致，文件传输成功。

情形2：UDP包乱序，存储模块按照文件偏移量0K、1K、2K、3K、4K的顺序发送UDP包，实例系统却按照文件偏移量0K、1K、3K、4K、2K的顺序接收UDP包。

实例系统接收文件偏移量3K的UDP包后，实时合并的结果发现创建的ust文件0K到4K的范围被写入数据，但中间存在2K到3K这个间断。实例系统设定继续接收UDP包的阈值为2个UDP包。在文件偏移量3K的UDP包后，实例系统后续又接收了文件偏移量4K、2K的UDP包，由于在设定的阈值范围内收到了文件偏移量2K的UDP包，2K到3K的间断能够被填补上。

情形3：UDP包丢包，存储模块按照文件偏移量0K、1K、2K、3K、4K的顺序发送UDP包，实例系统却只收到按照文件偏移量0K、1K、3K、4K的UDP包，文件偏移量2K的UDP包丢包。

实例系统接收文件偏移量3K的UDP包后，实时合并的结果发现创建的ust文件0K到4K的范围被写入数据，但中间存在2K到3K这个间断。实例系统同样设定继续接收UDP包的阈值为2个UDP包，但后续实例系统只接收了文件偏移量4K的UDP包，超过设置的socket接收时限2秒后仍然没有收到文件偏移量2K的UDP包，2K到3K的间断没有被填补上。这时实例系统没有必要继续等待UDP包，可以认为文件传输已经失败，立即向控制节点报告。

利用云系统组播文件的装置，可以实现以上所述的云系统组播文件的方法。云系统组播文件的装置，包括云系统中的控制节点、实例系统和存储模块(一般位于云系统中独立的存储服务器上)三个部件。存储模块与实例系统彼此独立，都由控制节点控制和管理，其关系如图2所示(图2中的实线双向箭头表示控制和管理关系，虚线箭头表示组播中的数据流向)。存储模块比较重要的功能，是将需要传输的文件分割为多个数据块，生成包括数据块和文件偏移量的数据包，并组播数据包。实例系统比较重要的功能，一是将接收的数据包中的数据块按照文件偏移量写入创建的文件，二是每接收一个数据包则实时合并所有已接收的数据块在创建的文件中的范围。上述功能都可以通过编写专用程序实现。

正常情况下，一次组播所有相关的实例系统都可以成功接收需要传输的文件，如果有个别实例系统由于自身原因(例如组播时恰好负荷过重)导致接收文件失败，控制节点可以对这些实例系统单独采用TCP方式重新传输文件，接收文件失败的实例系统数量很少时，TCP重新传输不会对云系统的整体性能有较大影响。但在一些极端情况下，组播大范围失败，这时就需要采用特殊的云系统组播文件的方法。

在整体的云系统中，还可以设置一些局部系统，局部系统中包括内部交换机和多个实例系统(例如1个内部交换机和24个小型实例系统可以组成一台刀片服务器，这台刀片服务器就可以视为一个局部系统)，局部系统中的内部交换机进行网络传输时数据不会外溢到局部系统之外的其他实例系统。局部系统可以选择其中的一个实例系统作为代表，从控制节点以TCP方式获取需要传输的文件，然后在局部系统内部传输。具体的内部传输方法有两种，一种是控制节点为这个局部系统单独分配一个组播组，实例系统代表在局部系统中利用单独分配的组播组进行内部组播(组播不面向局部系统之外的实例系统)；另一种是实例系统代表将要传输的文件以TCP方式发送给另一个实例系统，这两个实例系统同时再把要传输的文件以TCP方式发送给另外两个实例系统，以这种“一变二、二变四、四变八……”的模式指数级的在局部系统内传输文件。当局部系统中的实例系统较多时，第一种方法较为适宜；当局部系统中的实例系统较少时，第二种方法较为适宜。

本发明技术方案，将要传输的文件分解为UDP包，组播UDP包，大大降低了带宽占用。但对于一些关键性且数据量很少的参数(例如需要传输的文件的文件名、文件验证值、文件大小以及组播组名、端口号)，仍然采用TCP传输，确保这些参数传输的准确性。UDP包中包括了数据块和文件偏移量，还可以包括数据块大小，组播UDP包不受UDP包乱序的影响。通过实时合并所有已经接收的数据块在创建的文件中的范围，可以及时发现UDP包较为严重的丢包问题。此外，如果组播大范围失败，则充分利用云系统中的局部系统性能自治的优势，在局部系统内部完成文件的传输。

如果利用“背景技术”部分所述的常见做法将一个大文件传输到几千个实例系统，估算的时间需要几个小时，而利用本发明技术方案则只需要几分钟。本发明技术方案的时间复杂度由线性降低为常数，这意味着并不需要随着实例系统数量的增加而增加控制节点，同时网络带宽的占用率也大大降低。

本领域技术人员在以上所描述的具体技术方案的基础上，完全可以构造出其他方案，在此不一一列举。

Claims (7)

1.云系统组播文件的方法，其特征在于，所述的方法包括：

1)控制节点分配组播IP与端口号，通知所有相关的实例系统加入组播组；

2)控制节点通知存储模块加入组播组，以数据包形式组播需要传输的文件；

3)实例系统根据通知创建文件，循环接收存储模块组播的数据包；

当组播大范围失败时，在包括内部交换机和多个实例系统的局部系统中选择一个实例系统代表，实例系统代表从控制节点获取需要传输的文件，在局部系统内部传输。

2.根据权利要求1所述的方法，其特征在于，1)中所述的通知包括需要传输的文件的文件名、文件验证值、文件大小以及组播组名、端口号。

3.根据权利要求1所述的方法，其特征在于，2)中所述的需要传输的文件被分割为多个数据块，组播的数据包包括数据块和文件偏移量。

4.根据权利要求1所述的方法，其特征在于，3)中所述的实例系统将接收的数据包中的数据块按照文件偏移量写入创建的文件。

5.根据权利要求1所述的方法，其特征在于，3)中所述的实例系统每接收一个数据包则实时合并所有已接收的数据块在创建的文件中的范围。

6.根据权利要求3所述的方法，其特征在于，3)中如果所述的实例系统接收数据包尚未结束，实时合并的结果存在至少一处间断，则所述的实例系统针对每处间断设定继续接收数据包的阈值；如果任何一处间断在所述的实例系统继续接收设定阈值的数据包后仍未被填补，则所述的实例系统退出组播组。

7.根据权利要求1所述的方法，其特征在于，所述的内部传输包括实例系统代表在局部系统中使用控制节点单独分配的组播组内部组播。