CN113704218A - 一种容器环境中运行时数据迁移方法及系统 - Google Patents

一种容器环境中运行时数据迁移方法及系统 Download PDF

Info

Publication number
CN113704218A
CN113704218A CN202110985351.2A CN202110985351A CN113704218A CN 113704218 A CN113704218 A CN 113704218A CN 202110985351 A CN202110985351 A CN 202110985351A CN 113704218 A CN113704218 A CN 113704218A
Authority
CN
China
Prior art keywords
data
node
container
migration
old
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.)
Granted
Application number
CN202110985351.2A
Other languages
English (en)
Other versions
CN113704218B (zh
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.)
Harbin Institute of Technology
Original Assignee
Harbin Institute of Technology
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 Harbin Institute of Technology filed Critical Harbin Institute of Technology
Priority to CN202110985351.2A priority Critical patent/CN113704218B/zh
Publication of CN113704218A publication Critical patent/CN113704218A/zh
Application granted granted Critical
Publication of CN113704218B publication Critical patent/CN113704218B/zh
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/11File system administration, e.g. details of archiving or snapshots
    • G06F16/119Details of migration of file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/182Distributed file systems
    • G06F16/184Distributed file systems implemented as replicated file system

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

一种容器环境中运行时数据迁移方法及系统,涉及容器数据迁移技术领域,用以解决现有迁移方法在迁移过程中传输的数据量过大而导致迁移效率低下的问题。本发明的技术要点包括:对于每个用户设备,数据迁移过程包括:用户端访问新节点,新节点根据用户端请求发送数据迁移指令至旧节点;旧节点接收到数据迁移指令后,使所有运行任务有序退出并通知新节点;新节点获取旧节点连接信息并与其建立连接;旧节点通过NFS方式共享数据到新节点;新节点将旧节点数据挂载并复制到本地用户容器中,完成数据从旧节点到新节点的迁移;其中,新节点以Overlay只读方式挂载数据。本发明通过Overlay+NFS的方式实现迁移,不会拖累系统性能,优化了迁移中传输的数据量和带来的传输延迟。

Description

一种容器环境中运行时数据迁移方法及系统
技术领域
本发明涉及容器数据迁移技术领域,具体涉及一种容器环境中运行时数据迁移方法及系统。
背景技术
每个接入蜂窝网络的设备都会被叫做UE(User Equipment,用户设备)。每个UE都需要一个在边缘计算中对应的实体,本发明中将其称为虚拟UE。这个虚拟UE通过(如分析、数据聚合、视频压缩、物体识别)和处理/存储能力来补充用户设备上的应用。虚拟UE可以通过容器或虚拟机来实现,但是容器实现方式相比虚拟机更为轻量。
高速响应的服务依赖于终端用户和边缘服务器之间相对较短的网络距离。然而,当终端用户远离其当前的边缘服务器时,移动性能的好处将被大大削弱。当用户设备从一个边缘计算服务节点离开进入另一个边缘计算服务节点时,为了保证服务质量,用户应该尽可能的请求离自己近的节点。而当新的节点要开始服务时,之前节点上用户的数据将会帮助新节点更好地服务用户。
在传统的C/S服务架构中,用户的数据都被保存在中心化的云数据中心中。任何服务都可以在授权后方便地获取、修改需要的数据,而因为数据都集中化地保存在同一个地方,或者考虑到异地分布式的存储结构,至少可以通过一个统一的接口或者地址获取到需要的数据。同时用户的移动性也不会和应用有太大关系,当用户的网络状况发生很大的变化时,对于应用而言,变化的只有网络连接。应用代码、数据、计算环境等都还在同一个数据中心。随着网络的扩展、国际化使用需求的增多,一些大型企业开始有了在全球各地建设数据中心协作的实践,但是主要目的是因为各地的数据相关法律和降低通过跨洋光纤传输的数据量。然而,这些实践很少需要将用户的数据从一个大洲迁移到另一个大洲的数据中心,同时这种方式最终只能将延迟控制到100ms左右的级别。
从上述的分析中可以看出,迁移本身是必要的。迁移可以将用户的数据、任务计算的中间结果等通过边之间的连接迁移到另一个节点,而省去了从云上重新获取数据的麻烦。同时当部分地区暂时失去了和云上的数据连接时,也能保持边缘有一定的服务能力。Docker (应用容器引擎)本身提供了save(保存)和load(下载)指令用来保存用户数据,这个机制常常被用在迁移中。分析Docker的源码和实验可知,save和load在保存的时候会将镜像每一层都导出到文件当中。然而,这种方法只是转移了位于容器根文件系统挂载点下的所有文件,这些文件实际上是所有容器镜像层的组合。这种方法忽略了底层的存储层,最终导致迁移效率低下。效率低下的原因如下:第一,Docker的save和load过程中会保存所有的层次信息,操作本身十分耗时;第二,将所有层次信息都保存到导出的文件中,得到的数据量会非常大;第三,执行save操作时容器不能运行,执行完save操作后写入的数据也不能同步到导出的数据中心。由此,通过上述这种方法进行迁移时原则上不应该有任务正在运行,而且因为导出、导入、传输所耗费的时间都很多,从而也就导致了在迁移过程中会出现长时间的中断。
Docker的底层组件之一containerd(主要职责是镜像管理、容器执行)也提供了snapshot机制,snapshot机制可以将某一层导出,避免上述导致迁移效率低下的第一和第二个问题。但是通过containerd导出每层时要求两层之间存在依赖关系,且上层导出的tar文件会显式地指定下层的SHA256(摘要信息),若SHA256不匹配则不能正常导入。因此在发生程序升级时,所有的Root数据会丢失,需要应用重新初始化或者提前同步到云端。
发明内容
鉴于以上问题,本发明提出一种容器环境中运行时数据迁移方法及系统,用以解决现有迁移方法在迁移过程中传输的数据量过大而导致迁移效率低下的问题。
根据本发明一方面,提出一种容器环境中运行时数据迁移方法,该方法在云计算架构中构建容器,并将数据和容器的运行环境分离,对于每个需要迁移的容器,数据迁移的过程包括:
步骤一、用户端访问新节点,新节点根据用户端请求发送数据迁移指令至旧节点;所述节点为边缘计算服务节点;
步骤二、旧节点接收到数据迁移指令后,使所有运行任务有序退出,并通知新节点;
步骤三、新节点获取旧节点连接信息并与其建立连接,所述连接信息包括网络连接地址;
步骤四、旧节点通过NFS方式共享数据到新节点;
步骤五、新节点将旧节点数据挂载并复制到本地容器中,完成数据从旧节点到新节点的迁移。
进一步地,所述数据包括Root数据和Data数据,所述Root数据是指从整个根目录下任意地方写入的数据,通过overlay的方式绑定在容器上;所述Data数据是指包含待交换数据和域套接字的数据目录,通过Bind的方式绑定在容器上。
进一步地,为每个容器设置一个包含锁信息的文件锁以保证数据传输的一致性,所述锁信息包括当前节点的名称和地址。
进一步地,步骤三中新节点与旧节点建立连接后,对锁信息进行修改,修改内容包括将文件锁的名称和地址修改为新节点的名称和地址。
进一步地,步骤五中以Overlay只读方式挂载数据,当在本地容器中找不到所需数据时,通过网络访问旧节点以获取数据。
进一步地,在步骤五数据复制完成后,将对应消息推送到旧节点,以使旧节点对不再需要的用户数据进行清理。
根据本发明另一方面,提出一种容器环境中运行时数据迁移系统,在云计算架构中构建容器,并将数据和容器的运行环境分离,在上述构建的容器环境中,所述系统包括:
迁移指令接收模块,用于当用户端访问新节点时,新节点根据用户端请求发送数据迁移指令至旧节点,所述节点为边缘计算服务节点;旧节点接收到数据迁移指令后,使所有运行任务有序退出,并通知新节点;
连接建立模块,用于新节点获取旧节点连接信息并与其建立连接,所述连接信息包括网络连接地址;
数据共享模块,用于旧节点通过NFS方式共享数据到新节点;
挂载复制模块,用于新节点将旧节点数据挂载并复制到本地容器中,完成数据从旧节点到新节点的迁移;
其中,系统中待迁移的数据包括Root数据和Data数据,所述Root数据是指从整个根目录下任意地方写入的数据,通过Overlay的方式绑定在容器上;所述Data数据是指包含待交换数据和域套接字的数据目录,通过Bind的方式绑定在容器上。
进一步地,所述系统中为每个容器设置一个包含锁信息的文件锁以保证数据传输的一致性,所述锁信息包括当前节点的名称和地址。
进一步地,所述连接建立模块中新节点与旧节点建立连接后,对锁信息进行修改,修改内容包括将文件锁的名称和地址修改为新节点的名称和地址。
进一步地,所述挂载复制模块中以Overlay只读方式挂载数据,当在本地容器中找不到所需数据时,通过网络访问旧节点以获取数据。
本发明的有益技术效果是:
本发明旨在在容器的环境中设计一种方式实现数据迁移,来帮助服务的连续性。通过 Overlay+NFS的方式实现迁移,优化了迁移中传输的数据量和带来的传输延迟;相比于现有的迁移方法,本发明不会拖累系统性能,迁移的数据量也不会过大。
附图说明
本发明可以通过参考下文中结合附图所给出的描述而得到更好的理解,所述附图连同下面的详细说明一起包含在本说明书中并且形成本说明书的一部分,而且用来进一步举例说明本发明的优选实施例和解释本发明的原理和优点。
图1是本发明实施例数据迁移的示意图;
图2是本发明实施例锁轮询逻辑示意图;
图3是本发明实施例容器运行中产生数据统计图;
图4是本发明实施例数据迁移系统的结构示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案,在下文中将结合附图对本发明的示范性实施方式或实施例进行描述。显然,所描述的实施方式或实施例仅仅是本发明一部分的实施方式或实施例,而不是全部的。基于本发明中的实施方式或实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施方式或实施例,都应当属于本发明保护的范围。
随着用户的移动,另一个边缘集群会成为更为合适的应用提供者。为了保证服务的持续性,同时一定程度降低响应时间,迁移用户上下文数据是有必要的。每个用户的上下文数据会保存用户实时数据,在某个时间点,应用状态被完全转移而源实例停止服务。本发明提供一种容器环境中运行时数据迁移方法,旨在在容器的环境中设计一种方式实现迁移,来帮助服务的连续性。通过Linux自身的分层存储机制管理用户数据,通过Overlay+NFS的方式实现迁移,优化了迁移中传输的数据量和带来的传输延迟;相比于现有的迁移方法,本发明方法不会拖累系统性能,迁移的数据量也不会太大。
该方法对于每个用户迁移的流程包括:S1.用户在新的节点上开始访问;S2.新节点根据用户端的请求或者根据云上的数据库,获取旧节点的连接信息;S3.新节点将旧节点的数据挂载到本地,并且后台开始复制数据到本地;S4.在数据复制完后,新节点上后续启动的任务开始使用本地的数据,同时将新修改的数据应用到本地的数据上;S5.在新节点上没有任何任务通过NFS方式依赖旧节点上的数据时,旧节点回收空间。考虑到函数式服务一般执行速度快,执行时间短,这个依赖时间不会太长。下面对本发明方法进行详细说明。
1.容器环境
容器环境中使用了如下技术:
(1)Gvisor:Gvisor是一个容器运行环境。相比标准的runc,Gvisor提供了沙箱机制,可以有效地实现容器内程序和容器外的宿主机系统的隔离。Gvisor内设置了一个组件Sentry,Sentry会对容器内进程的系统调用做捕获和重新实现,角色类似于虚拟机内的内核,而真实的任务程序则运行在用户空间中。Gvisor提供了类似于虚拟机的隔离,但是和完整的虚拟机相比,有着更低的系统占用。在捕获系统调用上有两种机制,本发明使用的是KVM方式。
(2)Crun:Runc是由Docker开源的容器运行环境,也是Docker目前默认的运行环境,和Docker一样由Go语言实现。因为原生的Runc受制于go语言设计时本身的一些限制(例如fork/exec的语义问题),Red Hat推出了类似于runc的功能的Crun,Crun表示一个基于cgroup实现的容器运行时。与Go语言不同,C语言默认不是多线程的,它是围绕fork/exec模型建立和设计的。它可以以更简洁的方式处理OCI运行时的这一部分。同样受益于C语言直接和内核交互,也不需要GMP模型等方式优化,crun本身带来的额外内存开销更小,更适合运行在低性能的环境。
每个节点之间通过etcd数据库来保持配置的一致性。etcd保证每个节点看到的数据都是一样的。同时选取一部分节点共同持有一个etcd数据库,通过节点间共同的etcd数据库来保证数据写入正确。
Flannel网络组件通过etcd来互相同步网络数据。在网络配置的时候,Flannel将自己的网络信息(连接地址、连接方式、MAC地址等)写入etcd中。其他Flannel节点同样将自己的网络信息也写到etcd中。每个物理节点上的Flannel监听着新加入etcd的所有节点,及时更新自己的网络信息。
同时,etcd数据库中保存了所有容器的位置信息。etcd数据库保存了每个用户和对应容器在数据平面的地址。每当有请求来访问时,网关将会转发请求到对应地址,由容器完成后续的步骤。对于不存在于etcd中的地址,说明本地没有用户数据,需要在共有的数据库里查找该用户数据所在的位置并且请求迁移。
同时,节点间共同的etcd数据库则是负责同步用户所在的任务节点。当用户从一个节点迁移到另一个节点时,之前的节点需要退出所有任务后,主动地将地址修改为新的物理节点。新的物理节点在监听到这一改变后,才可以开始任务的创建。
2.用户数据的定义
每个容器都会在运行的时候消费和生产数据,将这些数据分为Root和Data数据两个部分来进行管理。Root数据将会保留绝大多数的容器状态,例如通过软件包管理器安装的包和依赖库、计算产生的中间文件和模型H5文件等。同一任务可以访问到这些数据,而不同应用则不能访问到这些数据。因此Root中的数据不会用来跨应用数据的交互。而Data 目录被设计成是可以用来做数据交换的,Data目录中有可以用来交换的数据和域套接字,可以用来让各个任务之间通信和数据交换。每个任务可以写入到自己的数据目录中,同时读取经过授权的其他任务的数据目录。为了避免多个任务同时对文件读写引起数据故障,通过文件系统发生的数据传输需要是单向的。当需要双向的数据传输时,即对于复杂、可能同时存在多个读写的场景则需要通过域套接字的方式进行。
Root数据会通过Overlay的方式绑定在容器上,Data数据会通过Bind的方式绑定在容器上。因为容器依赖于Gvisor重新编写的网络栈,而Gvisor本身网络栈性能在大数据传输时开销较大,因此通过文件系统传输数据可以更好地提高容器间交互的性能。在节点间传输的时候,Root数据将传输到其他节点上,用来帮助容器启动加速,进一步提升对用户请求的响应速度。
Overlayfs是一种堆叠式的文件系统,文件系统本身依赖并建立在其它的文件系统之上 (例如ext4fs和xfs等等)。不同于其他的文件系统,Overlayfs并不直接参与磁盘空间结构的划分,仅仅通过将原来底层文件系统中不同的目录进行“合并”,然后返回到用户端供用户使用。因此在用户调用的时候来说,获得的Overlay文件系统根目录下的内容就来自挂载时挂载参数所指定的不同目录的叠加。
在每个任务容器启动的时候,需要将这个容器需要的数据指定到任务容器的环境中。在构建任务容器的启动目录时,以运行环境为底层,以用户Root数据目录为上层,构建容器的根文件系统。同时会绑定用户的Data目录下到该应用的目录到容器的Data目录中。绑定的方式会有相比Overlay机制更好的读写性能,因此bind方式更适合容器之间的数据传输。而Overlay的方式可以很大程度上降低容器迁移的负担,新修改的内容将会显示在upper目录中。任务程序将会以这个构造好的文件夹为根目录。
3.迁移的实现
在迁移的时候,一般迁移任务代码和数据。但是Serverless(无服务计算)本身任务是通过镜像库分发的,因此任务的代码并不需要迁移,只需要迁移数据部分。数据都通过NFS的方式传输。NFS机制本身支持从内核空间中使用,因此可以方便地集成到Overlay文件系统中。
每个容器的数据分为Root部分和Data部分,容器在启动的时候,往往不需要所有的数据。将所有文件都迁移到新的节点之后才可以启动容器的方法会拖慢任务的启动速度。因此在NFS加载以后,获得了整个的目录结构后就可以开始启动容器。当容器需要某个文件的时候,再通过网络连接方式完成这次IO。对于一些使用频率较高的数据,例如分析视频任务中刚刚捕获的视频片段,本发明中按照用户的粒度为每个NFS服务建立了缓存,这些热点文件将会缓存在本地,来降低读取的开销。
而对于写入数据的情况来说,NFS的写入往往需要通过网络写回到原服务器中。而在迁移的场景中,NFS系统只是用来在迁移过程中避免需要复制所有文件的一个过渡机制,并不需要写入原来的服务器中。因此为了避免写入性能的问题,新节点将会构建成一个Overlay 文件系统。以旧节点的NFS系统为底层,新节点的NFS系统为顶层。原先的数据仍然通过 NFS方式访问,新的数据则保存到本地,如图1所示。
NFS加载的请求需要ue-watchdog发送到宿主机实现。在宿主机上运行着nfs-handler 程序,nfs-handler程序同时可以访问控制平面和用户数据平面。当ue-watchdog程序提出了需要尝试获取用户数据时,将请求发送到nfs-handler,nfs-handler将会将数据只读挂载到宿主机中用户数据目录中,通过Bind机制在容器中也会看到这个文件。
在容器迁移时,按照层进行数据保存的话将会出现容器层上的依赖问题。每到一个节点后修改将会创造出新的一层,随着迁移次数的增多,层次结构将会变得十分复杂。在一些层会依赖NFS实现的时候,整体性能下降会非常严重。同时,随着NFS层次的增多,IO 性能会有明显的下降。后台需要将远端的数据复制到本地。在完成复制后,所有新运行的任务容器将会读取本地新的文件服务。并且所有依赖NFS的服务器都退出后,远端便可以安全地停止NFS服务并且回收存储空间。
4.任务之间的协调
使用NFS实现数据传输可以快速地帮助任务启动,快速地加载用户数据到新的目录。对于Root目录来说,因为是以Lower层的形式挂载到容器当中,因此不会发生修改。而对于Data层来说,则存在文件被修改的可能。在NFSv4中,为了保证文件一致性,修改文件需要通过RPC的方式获得文件锁。因为在迁移过程中数据没有写回旧节点的必要,这个过程会增加没有意义的延迟,因此本发明中通过Overlay的方式可以提升读写性能,避免不必要的传输。
同时,每个用户下的每个应用会共享同一份存储空间,如果在迁移过程中源节点上的任务没有退出的时候,新节点的任务就开始执行,则有可能导致文件系统出错。因此为了避免出现多个节点进行任务影响系统的一致性,系统中为每个容器设置了一个分布性锁来保证一致性。这个锁放置在节点之间的etcd数据库中,每个正在运行的节点持有这个锁,值设置为当前节点的名字和地址。
图2是锁轮询逻辑示意图。如图2所示,锁通过etcd数据库提供的Raft机制保证锁的正确性。通过持有锁的节点在释放锁时通知后驱节点释放锁,而后驱节点自旋等待这一通知。在多NUMA节点的实验环境中,因为跨NUMA节点的系统性能会有损失,相比于CLH 方式,这种方式跨节点访问次数更少,会有更好的表现。因此在类似情况下,对于需要远程通信的跨节点而言,这种方式会带来更好的性能提升。
每当迁移需要发生的时候,新的节点需要通知旧的节点停止所有任务,之后等待旧的节点发送通知。旧节点发送SIGSTOP到所有任务并且在任务结束后回收UE容器,之后将锁设置为新的节点并且通知新节点。新节点获得锁,可以开始写入用户数据文件。
综上,本发明方法一个具体实施例如下:
S1.在用户远离前一个基站的情况下(以接口形式提供出去),开始准备迁移数据。这个过程为从旧节点迁移到新节点。首先旧节点发送系统信号给所有的任务,让所有任务有序退出,并且在etcd数据库中设置锁L;同时通知新节点即将有迁移,新节点注册锁L释放的回调事件(在释放锁的时候就会通知新节点);
S2.当所有任务有序退出后,旧节点释放锁,数据库通知新节点;
S3.旧节点开始通过NFS的方式共享数据到新节点;
S4.新节点进行两个任务:
挂载旧节点数据到本地,以Overlay只读方式将数据挂载到容器中,容器启动的时候可以使用旧的数据;新写入的数据都保存到本地,当本地找不到对应数据时,通过网络访问旧节点获取数据;
复制旧节点的数据到本地;
S5.在复制任务完成后,将对应消息推送到旧的节点;旧节点可以在空闲时清理掉不再需要的用户数据。
新节点将会有两份数据,迁移来的旧节点数据和新写入的数据,这两份数据合并起来便是完整的用户数据。
本发明另一实施例提供一种容器环境中运行时数据迁移系统,在云计算架构中构建容器,并将数据和容器的运行环境分离,在上述构建的容器环境中,如图4所示,所述系统包括:
迁移指令接收模块10,用于当用户端访问新节点时,新节点根据用户端请求发送数据迁移指令至旧节点,所述节点为边缘计算服务节点;旧节点接收到数据迁移指令后,使所有运行任务有序退出,并通知新节点;
连接建立模块20,用于新节点获取旧节点连接信息并与其建立连接,连接信息包括网络连接地址;
数据共享模块30,用于旧节点通过NFS方式共享数据到新节点;
挂载复制模块40,用于新节点将旧节点数据挂载并复制到本地容器中,完成数据从旧节点到新节点的迁移;
其中,系统中待迁移的数据包括Root数据和Data数据,Root数据是指从整个根目录下任意地方写入的数据,通过Overlay的方式绑定在容器上;Data数据是指包含待交换数据和域套接字的数据目录,通过Bind的方式绑定在容器上。
系统中为每个容器设置一个包含锁信息的文件锁以保证数据传输的一致性,锁信息包括当前节点的名称和地址。连接建立模块20中新节点与旧节点建立连接后,对锁信息进行修改,修改内容包括将文件锁的名称和地址修改为新节点的名称和地址;挂载复制模块40 中以Overlay只读方式挂载数据,当在本地容器中找不到所需数据时,通过网络访问旧节点以获取数据。
最后,通过实验验证本发明的技术效果。
首先创建容器,容器大小如表1所示。
表1实验容器属性
Figure BDA0003230476450000091
实验关注的是本发明正常运行时与常见的export+SCP迁移方法产生的数据量对比。对于每个应用程序,均以每3秒一次的频率模拟一些请求。对于Resnet50程序,输入图片让其分类;对于Imagemagick程序,输入图片让其缩放;对于Minio程序,以4:1的概率进行读请求和写请求,其中写入的文件为100KB-120KB大小范围的图片,来模拟常见的图片存储请求;对于Nginx程序,进行简单的HTTP访问。运行10分钟后测试结果如图3所示。从图3中可以看到,本发明中的访问对于一些容器而言创造了大量的数据,但是对于另一些容器而言创造的数据量极少。
在每个容器中都制造了一些数据后开始进行迁移。对比的迁移方式是DockerExport 导出+SCP传输文件方式[1]。通过测试平台均是i5-8400处理器、8G内存、Ubuntu18.04且通过千兆路由器连接的两台机器,通过iperf3估测有线带宽估测为110MB/s左右。
表2是实验最终结果。从表2中可以看到,本发明方法显著地降低了开始响应的时间和迁移的时间。所有任务在0.5s内都开始响应运行,同时由于迁移数据量的减少,迁移整体用时减少。因此整体从迁移到运行需要的时间也大幅度减少。
表2迁移实验结果
Figure BDA0003230476450000101
尽管根据有限数量的实施例描述了本发明,但是受益于上面的描述,本技术领域内的技术人员明白,在由此描述的本发明的范围内,可以设想其它实施例。对于本发明的范围,对本发明所做的公开是说明性的,而非限制性的,本发明的范围由所附权利要求书限定。
本发明援引的文献如下:
[1]CAMPOLO C,IERA A,MOLINARO A,2019.MEC Support for 5G-V2X Use Casesthrough Docker Containers[J].IEEE Wireless Communications and NetworkingConference,WCNC, 2019-April:0–5.DOI:10.1109/WCNC.2019.8885515。

Claims (10)

1.一种容器环境中运行时数据迁移方法,其特征在于,在云计算架构中构建容器,并将数据和容器的运行环境分离,对于每个需要迁移的容器,数据迁移的过程包括:
步骤一、用户端访问新节点,新节点根据用户端请求发送数据迁移指令至旧节点;所述节点为边缘计算服务节点;
步骤二、旧节点接收到数据迁移指令后,使所有运行任务有序退出,并通知新节点;
步骤三、新节点获取旧节点连接信息并与其建立连接,所述连接信息包括网络连接地址;
步骤四、旧节点通过NFS方式共享数据到新节点;
步骤五、新节点将旧节点数据挂载并复制到本地容器中,完成数据从旧节点到新节点的迁移。
2.根据权利要求1所述的一种容器环境中运行时数据迁移方法,其特征在于,所述数据包括Root数据和Data数据,所述Root数据是指从整个根目录下任意地方写入的数据,通过overlay的方式绑定在容器上;所述Data数据是指包含待交换数据和域套接字的数据目录,通过Bind的方式绑定在容器上。
3.根据权利要求2所述的一种容器环境中运行时数据迁移方法,其特征在于,为每个容器设置一个包含锁信息的文件锁以保证数据传输的一致性,所述锁信息包括当前节点的名称和地址。
4.根据权利要求3所述的一种容器环境中运行时数据迁移方法,其特征在于,步骤三中新节点与旧节点建立连接后,对锁信息进行修改,修改内容包括将文件锁的名称和地址修改为新节点的名称和地址。
5.根据权利要求4所述的一种容器环境中运行时数据迁移方法,其特征在于,步骤五中以Overlay只读方式挂载数据,当在本地容器中找不到所需数据时,通过网络访问旧节点以获取数据。
6.根据权利要求5所述的一种容器环境中运行时数据迁移方法,其特征在于,在步骤五数据复制完成后,将对应消息推送到旧节点,以使旧节点对不再需要的用户数据进行清理。
7.一种容器环境中运行时数据迁移系统,其特征在于,在云计算架构中构建容器,并将数据和容器的运行环境分离,在上述构建的容器环境中,所述系统包括:
迁移指令接收模块,用于当用户端访问新节点时,新节点根据用户端请求发送数据迁移指令至旧节点,所述节点为边缘计算服务节点;旧节点接收到数据迁移指令后,使所有运行任务有序退出,并通知新节点;
连接建立模块,用于新节点获取旧节点连接信息并与其建立连接,所述连接信息包括网络连接地址;
数据共享模块,用于旧节点通过NFS方式共享数据到新节点;
挂载复制模块,用于新节点将旧节点数据挂载并复制到本地容器中,完成数据从旧节点到新节点的迁移;
其中,系统中待迁移的数据包括Root数据和Data数据,所述Root数据是指从整个根目录下任意地方写入的数据,通过Overlay的方式绑定在容器上;所述Data数据是指包含待交换数据和域套接字的数据目录,通过Bind的方式绑定在容器上。
8.根据权利要求7所述的一种容器环境中运行时数据迁移系统,其特征在于,所述系统中为每个容器设置一个包含锁信息的文件锁以保证数据传输的一致性,所述锁信息包括当前节点的名称和地址。
9.根据权利要求8所述的一种容器环境中运行时数据迁移系统,其特征在于,所述连接建立模块中新节点与旧节点建立连接后,对锁信息进行修改,修改内容包括将文件锁的名称和地址修改为新节点的名称和地址。
10.根据权利要求9所述的一种容器环境中运行时数据迁移系统,其特征在于,所述挂载复制模块中以Overlay只读方式挂载数据,当在本地容器中找不到所需数据时,通过网络访问旧节点以获取数据。
CN202110985351.2A 2021-08-26 2021-08-26 一种容器环境中运行时数据迁移方法及系统 Active CN113704218B (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202110985351.2A CN113704218B (zh) 2021-08-26 2021-08-26 一种容器环境中运行时数据迁移方法及系统

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202110985351.2A CN113704218B (zh) 2021-08-26 2021-08-26 一种容器环境中运行时数据迁移方法及系统

Publications (2)

Publication Number Publication Date
CN113704218A true CN113704218A (zh) 2021-11-26
CN113704218B CN113704218B (zh) 2024-04-05

Family

ID=78654894

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202110985351.2A Active CN113704218B (zh) 2021-08-26 2021-08-26 一种容器环境中运行时数据迁移方法及系统

Country Status (1)

Country Link
CN (1) CN113704218B (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117370310A (zh) * 2023-10-19 2024-01-09 中电云计算技术有限公司 一种分布式文件系统跨集群数据增量迁移的方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090210431A1 (en) * 2007-11-12 2009-08-20 Attune Systems, Inc. Load Sharing Cluster File Systems
CN107526626A (zh) * 2017-08-24 2017-12-29 武汉大学 一种基于CRIU的Docker容器热迁移方法及系统
CN111769984A (zh) * 2020-06-29 2020-10-13 北京天仪百康科贸有限公司 区块链网络中添加节点的方法及区块链系统

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090210431A1 (en) * 2007-11-12 2009-08-20 Attune Systems, Inc. Load Sharing Cluster File Systems
CN107526626A (zh) * 2017-08-24 2017-12-29 武汉大学 一种基于CRIU的Docker容器热迁移方法及系统
CN111769984A (zh) * 2020-06-29 2020-10-13 北京天仪百康科贸有限公司 区块链网络中添加节点的方法及区块链系统

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117370310A (zh) * 2023-10-19 2024-01-09 中电云计算技术有限公司 一种分布式文件系统跨集群数据增量迁移的方法
CN117370310B (zh) * 2023-10-19 2024-05-28 中电云计算技术有限公司 一种分布式文件系统跨集群数据增量迁移的方法

Also Published As

Publication number Publication date
CN113704218B (zh) 2024-04-05

Similar Documents

Publication Publication Date Title
Xiong et al. Extend cloud to edge with kubeedge
US11128706B2 (en) Omnichannel approach to application sharing across different devices
US8516159B2 (en) Asynchronous file operations in a scalable multi-node file system cache for a remote cluster file system
US9934242B2 (en) Replication of data between mirrored data sites
US8458239B2 (en) Directory traversal in a scalable multi-node file system cache for a remote cluster file system
US7877511B1 (en) Method and apparatus for adaptive services networking
US9298752B2 (en) Facilitating data migration between database clusters while the database continues operating
US20150350366A1 (en) Scalable caching of remote file data in a cluster file system
US20090063556A1 (en) Root node for carrying out file level virtualization and migration
KR101008554B1 (ko) 클라우드 방식의 파일 복사 및 광역 통신망을 통한 디스크 복제 시스템 및 그 방법
CN111708738B (zh) 实现hadoop文件系统hdfs与对象存储s3数据互访方法及系统
CN111694791B (zh) 一种分布式基础框架中的数据存取方法及装置
CN109933312B (zh) 一种有效降低容器化关系型数据库i/o消耗的方法
CN112000635A (zh) 一种数据请求方法、设备以及介质
CN113703867B (zh) 一种无服务计算中加速启动方法及系统
CN112882726B (zh) 基于Hadoop和Docker的环境系统的部署方法
CN113704218B (zh) 一种容器环境中运行时数据迁移方法及系统
Faisal et al. Network latency impact on performance of software deployed across multiple clouds.
US11916998B2 (en) Multi-cloud edge system
Chen et al. On developing and deploying large-file upload services of personal cloud storage
US11507512B2 (en) Fault tolerant cluster data handling
CN115525618A (zh) 存储集群、数据存储方法、系统及存储介质
US20170220660A1 (en) Intelligent content synchronization between content libraries
CN112346912A (zh) 基于网络文件系统的有状态服务主备高可用系统及方法
CN112019623A (zh) 基于ftp协议的分布式存储系统及其实现方法

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
GR01 Patent grant
GR01 Patent grant