CN111586141B - 作业处理方法、装置、***和电子设备 - Google Patents
作业处理方法、装置、***和电子设备 Download PDFInfo
- Publication number
- CN111586141B CN111586141B CN202010362976.9A CN202010362976A CN111586141B CN 111586141 B CN111586141 B CN 111586141B CN 202010362976 A CN202010362976 A CN 202010362976A CN 111586141 B CN111586141 B CN 111586141B
- Authority
- CN
- China
- Prior art keywords
- storage
- storage volume
- server
- job
- volumes
- 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.)
- Active
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
- H04L67/025—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP] for remote control or remote monitoring of applications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/10—File systems; File servers
- G06F16/18—File system types
- G06F16/182—Distributed file systems
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/06—Protocols specially adapted for file transfer, e.g. file transfer protocol [FTP]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/14—Session management
- H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/50—Network services
- H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (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
本公开提供了一种作业处理方法、装置、***和电子设备。该方法包括响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,其中,存储卷挂载请求包括存储卷标识,第一映射关系是存储卷标识和访问路径之间的映射关系;建立第一服务器端与第二服务器端之间的长连接,以使得第二服务器端可挂载与存储卷标识对应的存储卷,基于访问路径访问第一服务器端的特定存储空间,特定存储空间用于存储作业文件;以及响应于来自第二服务器端的第一操作指令,对特定存储空间的作业文件进行处理。
Description
技术领域
本公开涉及互联网技术领域,更具体地,涉及一种作业处理方法、装置、***和电子设备。
背景技术
在银行业务***中,随着业务数据量的增长,越来越多的业务集群已经开始了从主机到平台的迁移。原在主机***完成的批量作业,在下平台后多采用分布式批量***实现。应用间往往以文件的形式,采用点对点传输的方式进行文件交换。
在实现本公开构思的过程中,发明人发现相关的作业处理方法至少存在如下问题,随着业务量的增长,***之间,子***之间需要完成大量的文件交互,批量执行节点需要具有较大的磁盘容量,因此要在平台即服务(Platform as a Service,简称PaaS)***内预留特定的宿主机资源,不利于PaaS资源的统一管理,对磁盘资源也容易造成浪费。
发明内容
有鉴于此,本公开提供了一种可以有效降低资源浪费的作业处理方法、装置、***和电子设备。
本公开的一个方面提供了一种由服务器端执行的作业处理方法,包括:响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,其中,存储卷挂载请求包括存储卷标识,第一映射关系是存储卷标识和访问路径之间的映射关系;建立第一服务器端与第二服务器端之间的长连接,以使得第二服务器端可挂载与存储卷标识对应的存储卷,基于访问路径访问第一服务器端的特定存储空间,特定存储空间用于存储作业文件;以及响应于来自第二服务器端的第一操作指令,对特定存储空间的作业文件进行处理。
本公开实施例提供的作业处理方法,由于第二服务器端可以通过挂载存储卷的方式访问第一服务器端的特定存储空间以进行作业处理,其中,作业处理过程中在第二服务器端以本地文件的方式在第一服务器端对作业文件进行处理,无需预留大量的宿主机资源,降低对宿主机资源的消耗,且利于PaaS资源的统一管理。
本公开的一个方面提供了一种作业处理装置,包括:路径确定模块、连接建立模块和第一分布处理模块。其中,路径确定模块用于响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,其中,存储卷挂载请求包括存储卷标识,第一映射关系是存储卷标识和访问路径之间的映射关系;连接建立模块用于建立第一服务器端与第二服务器端之间的长连接,以使得第二服务器端可挂载与存储卷标识对应的存储卷,基于访问路径访问第一服务器端的特定存储空间,特定存储空间用于存储作业文件;第一分布处理模块用于响应于来自第二服务器端的第一操作指令,对特定存储空间的作业文件进行处理。
本公开的一个方面提供了一种作业处理***,包括:公共组件和数据存储模块。其中,公共组件用于响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,并且建立与第二服务器端之间的长连接,以实现存储卷挂载;以及数据存储模块用于提供存储空间,以存储作业文件、存储卷标识和访问路径之间的第一映射关系。
本公开的另一方面提供了一种电子设备,包括一个或多个处理器以及存储装置,其中,存储装置用于存储可执行指令,可执行指令在被处理器执行时,实现如上的所述方法。
本公开的另一方面提供了一种计算机可读存储介质,存储有计算机可执行指令,指令在被执行时用于实现如上所述的方法。
本公开的另一方面提供了一种计算机程序,计算机程序包括计算机可执行指令,指令在被执行时用于实现如上所述的方法。
附图说明
通过以下参照附图对本公开实施例的描述,本公开的上述以及其他目的、特征和优点将更为清楚,在附图中:
图1示意性示出了根据本公开实施例的作业处理方法、装置、***和电子设备的应用场景;
图2示意性示出了根据本公开实施例的可以应用作业处理方法、装置、***和电子设备的示例性***架构;
图3示意性示出了根据本公开实施例的作业处理方法的流程图;
图4示意性示出了根据本公开另一实施例的作业处理方法的流程图;
图5示意性示出了根据本公开实施例存储卷级联架构的结构示意;
图6示意性示出了根据本公开另一实施例存储卷级联架构的结构示意图;
图7示意性示出了根据本公开另一实施例的作业处理方法的流程图;
图8示意性示出了根据本公开另一实施例的作业处理方法的流程图;
图9示意性示出了根据本公开实施例的一组存储卷的结构示意图;
图10示意性示出了根据本公开实施例的降级窗口的示意图;
图11示意性示出了根据本公开实施例的降级处理的逻辑图;
图12示意性示出了根据本公开实施例的作业处理装置的框图;
图13示意性示出了根据本公开实施例的作业处理***的框图;
图14示意性示出了根据本公开另一实施例的作业处理***的框图;以及
图15示意性示出了根据本公开实施例的电子设备的方框图。
具体实施方式
以下,将参照附图来描述本公开的实施例。但是应该理解,这些描述只是示例性的,而并非要限制本公开的范围。在下面的详细描述中,为便于解释,阐述了许多具体的细节以提供对本公开实施例的全面理解。然而,明显地,一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外,在以下说明中,省略了对公知结构和技术的描述,以避免不必要地混淆本公开的概念。
在此使用的术语仅仅是为了描述具体实施例,而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在,但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义,除非另外定义。应注意,这里使用的术语应解释为具有与本说明书的上下文相一致的含义,而不应以理想化或过于刻板的方式来解释。
在使用类似于“A、B和C等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有A、B和C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有A、B或C中至少一个的***”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的***等)。术语“第一”、“第二”等仅用于描述目的,而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此,限定有“第一”、“第二”的特征可以明示或者隐含地包括一个或者更多个特征。
本公开的实施例提供了一种作业处理方法、装置、***和电子设备。该作业处理方法包括存储卷挂载过程和处理过程,其中,在存储卷挂载过程中,响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,然后,建立第一服务器端与第二服务器端之间的长连接,以使得第二服务器端可挂载与存储卷挂载请求对应的存储卷,这样就使得第二服务器端可以基于访问路径访问第一服务器端的特定存储空间。在完成存储卷挂载过程之后,进入处理过程,响应于来自第二服务器端的第一操作指令,对特定存储空间的作业文件进行处理。
图1示意性示出了根据本公开实施例的作业处理方法、装置、***和电子设备的应用场景。
相关技术中为支持大量文件在批量执行节点(如应用节点)内的处理,批量执行节点需要具有较大的磁盘容量,因此要在PaaS***内预留特定的宿主机资源,不利于PaaS资源的统一管理,对磁盘资源也容易造成浪费。本公开实施例中批量执行节点可以在本地挂载存储卷,以本地文件处理的形式(将本地文件夹映射至存储服务器端)对存储服务器中作业文件进行处理,文件读写操作不占用额外的磁盘空间。
另一方面,相关技术中可以基于(File Transfer Protocol,简称FTP)和安全外壳协议(Secure Shell,简称SSH)协议实现文件的上传、下载。相关技术中采用的点对点传输方式,对发送和接收服务器的可用性有强依赖,批量文件保存在单一服务器上容易造成单点隐患。本公开实施例中存储卷可以具有相对应的备份存储卷,存储卷和相对应的备份存储卷使用的存储空间可以是相互隔离的,有效解决单点隐患的问题。
另一方面,相关技术中,批量作业在从主机***迁移至分布式批量***之后,可以采用分布式存储***(如Hbase等)实现数据的拆分和整合。在批量作业处理过程中,需要在HBase上进行大量的数据存取访问,各应用节点之间往往采用点对点传输的方式实现文件交换,对***的稳定性、并发能力、网络带宽的抗压能力都有较高要求。例如,节点1、节点2和节点3中至少一个需要从第一服务器端获取作业文件,在自身完成对作业文件1的处理后,将处理后的作业文件1发送给节点其它相关节点进行后续处理。随着业务量的增长以及应用内的层级、集群划分越来越精细等原因,导致***之间,子***之间需要完成大量的文件交互,造成FTP并发压力。
为了解决至少部分上述问题,如图1所示,本公开的实施例中当一个或多个节点(如节点1、节点2和节点3)需要对一个或多个作业文件(如作业文件1)进行处理时,节点1、节点2和节点3可以通过挂载与作业文件1相对应的存储卷1,来实现对作业文件1的共享,无需占用额外的存储资源,也无需节点1、节点2和节点3之间进行作业文件传递,有效降低了对网络资源的消耗。图1中k、m、n是大于1的正整数,k、m和n的数值可以相等或不等。
图2示意性示出了根据本公开实施例的可以应用作业处理方法、装置、***和电子设备的示例性***架构。需要注意的是,图2所示仅为可以应用本公开实施例的***架构的示例,以帮助本领域技术人员理解本公开的技术内容,但并不意味着本公开实施例不可以用于其他设备、***、环境或场景。
如图2所示,根据该实施例的***架构200可以包括终端设备201、202、203,网络204和服务器205。网络204可以包括多个网关、路由器、集线器、网线等,用以在终端设备201、202、203和服务器205之间提供通信链路的介质。网络204可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
用户可以使用终端设备201、202、203通过网络204与其他终端设备和服务器205进行交互,以接收或发送信息等,如发送服务请求、发送信息请求、接收处理结果等。终端设备201、202、203可以安装有各种通讯客户端应用,例如银行类应用、业务开发类应用、监控类应用、网页浏览器应用、搜索类应用、办公类应用、即时通信工具、邮箱客户端、社交平台软件等应用(仅为示例)。
终端设备201、202、203包括但不限于智能手机、虚拟现实设备、增强现实设备、平板电脑、膝上型便携计算机等等。
服务器205可以接收请求,并对请求进行处理。例如,服务器205可以为后台管理服务器、服务器集群等。后台管理服务器可以对接收到的配置请求、信息请求、架构维护指令等进行分析处理,并将处理结果(如请求的信息、处理的结果等)反馈给终端设备。
需要说明的是,本公开实施例所提供的作业处理方法一般可以由服务器205执行。相应地,本公开实施例所提供的作业处理装置一般可以设置于服务器205中。本公开实施例所提供的作业处理方法也可以由不同于服务器205且能够与终端设备201、202、203和/或服务器205通信的服务器或服务器集群执行。
应该理解,终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
图3示意性示出了根据本公开实施例的作业处理方法的流程图。
如图3所示,该由服务器端执行的作业处理方法可以包括操作S301~操作S305。
在操作S301,响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,其中,存储卷挂载请求包括存储卷标识,第一映射关系包括存储卷标识和访问路径之间的映射关系。
在本实施例中,为了保证作业文件的持久性,可以使得作业文件存储在相对于第二服务器端的外部存储空间,然后通过第二服务器端端的容器(docker)对作业文件进行处理。为了实现作业文件的持久性存储,在宿主机(第二服务器端)和容器内做映射(映射至存储在第一服务器端的特定存储空间,该特定存储空间存储有作业文件),可以保证在容器的生命周期结束,作业文件依旧可以实现持久性存储。当第二服务器端需要对作业文件进行操作时,在创建的容器内挂载与上述特定存储空间对应的存储卷即可。其中,第二服务器端可以包括多个节点,不同的节点挂载同一个存储卷时,则可以实现不同的节点对与该存储卷对应的特定存储空间的作业文件的共享。
在操作S303,建立第一服务器端与第二服务器端之间的长连接,以使得第二服务器端可挂载与存储卷标识对应的存储卷,基于访问路径访问第一服务器端的特定存储空间,特定存储空间用于存储作业文件。
本实施例中长连接用于点对点的节点之间的通讯,以提升操作频繁的点对点通讯场景的作业文件处理速度。建立长连接后,在一次作业文件传输完成后,保持TCP连接不断开,等待在同域名下继续用该长连接进行作业文件传输。由于每次建立TCP连接都需要花费进行三步握手的时间以建立连接,而建立长连接可以有效减少每次建立TCP连接所花费的时间,有效提升作业文件传输效率。建立长连接以便于实现存储卷挂载,使得第二服务器端可以基于访问路径访问第一服务器端的特定存储空间,进而实现对该特定存储空间中的作业文件进行处理。
长连接的建立过程可以如下所示。节点A的应用程序与节点B的应用程序通过套接字(Socket)建立连接以实现通信,而建立Socket连接必须需要底层的传输控制协议/网际协议(Transmission Control Protocol/Internet Protocol,简称TCP/IP)协议来建立TCP连接。建立TCP连接需要底层的IP协议来寻址网络中的节点。因此,网络层使用IP协议根据IP地址来确定目标节点,然后,通过TCP或用户数据报协议(User Datagram Protocol,UPD)的地址(即端口号)来实现与指定的应用程序通信。这样就可以实现通过一个Socket实例唯一代表一个节点上的一个应用程序的通信链路。当第一服务器端接收到一个长连接请求时,第一服务器端可以为这个长连接请求创建一个新的套接字数据结构,该套接字数据结构的信息包含的地址和端口信息正是请求源地址和端口,在第一服务器端与第二服务器端的三次握手完成后,长连接创建成功。
在操作S305,响应于来自第二服务器端的第一操作指令,对特定存储空间的作业文件进行处理。
在本实施例中,可以在第二服务器端以处理本地作业文件(第二服务器端本地创建的容器中挂载存储卷,使得第二服务器端中存在与作业文件对应的文件夹和文件夹目录)的形式,对存储于第一服务器端的作业文件进行处理,如读操作、写操作、与其它节点共享文件等。例如,可以由第二服务器端将操作指令发送至第一服务器端,由第一服务器端基于该操作指令在本地对作业文件进行处理。又例如,可以由第二服务器端发送读取数据指令给第一服务器端以获取作业文件,由第二服务器端在本地对作业文件进行处理后,将处理结果发送给第一服务器端进行存储。
例如,在通用数据传输平台(General Data Transfer Platform,简称GTP,是面向分布式应用的数据传输平台,提供满足企业级应用需要的通用传输功能)服务器上挂载GlusterFS(Gluster File System,主要应用在集群***中,易于扩展和配置,通过各个模块的灵活搭配以得到针对性的解决方案)存储卷,配置为批量文件的接收、发送目录。在GTP服务器、应用内各层批量执行节点之间通过挂载相同的存储卷实现文件共享。
本公开实施例提供的作业处理方法,第二服务器端通过挂载存储卷的方式对第一服务器端存储的作业文件进行处理,不占用额外的磁盘空间,降低资源浪费。
图4示意性示出了根据本公开另一实施例的作业处理方法的流程图。
如图4所示,该方法还可以包括操作S401~操作S403。
在操作S401,响应于来自多个节点针对同一第一存储卷标识的存储卷挂载请求,基于第一映射关系确定多个第一访问路径,多个节点是第二服务器端的。
在本实施例中,第二服务器端可以包括一个或多个节点集群(如应用集群),每个节点集群可以包括一个或多个节点,以满足相关技术中对应用内的层级、集群划分越来越精细的需求。例如,第二服务器端包括GTP服务器和应用内多个批量执行节点。GTP服务器和应用内多个批量执行节点之间通过挂载相同的存储卷实现作业文件共享。
在操作S403,建立多个节点与第一服务器端之间的多个第一长连接,多个第一长连接使得多个节点可基于多个第一访问路径分别访问第一服务器端的与第一存储卷标识对应的特定存储空间,以使得多个节点可共同操作与第一存储卷标识对应的特定存储空间的作业文件。例如,第一访问路径可以包括端口号和文件目录,此外,第一访问路径也可以包括IP地址。
在另一个实施例中,在满足大量节点挂载存储卷的前提(如单个存储卷可被挂载的节点的数量上限为预设挂载数量阈值,该大量节点的数量超过该预设挂载数量阈值)下,为了避免出现存储卷连接池压力过大的问题,上述方法还可以包括如下操作。
首先,获得针对同一第一存储卷标识的存储卷的请求挂载数量。
然后,如果针对同一第一存储卷标识的存储卷的请求挂载数量达到或者超过第一可挂载数量,则根据请求挂载数量和存储卷级联架构确定接入策略,其中,存储卷级联架构包括至少两层存储卷,对于相邻的两层存储卷,与一个上层存储卷对应的作业文件被拆分为分别与多个下层存储卷对应的多个子作业文件,其中,至少两层存储卷中底层存储卷的允许挂载数量小于等于第一可挂载数量。这样可以将第一存储卷标识的存储卷拆分为多个子存储卷,每个子存储卷的可被挂载数量不超过预设挂载数量阈值,便于增加可处理与第一存储卷标识的存储卷对应的作业文件的节点的数量。其中,与一个上层存储卷对应的作业文件可以基于一致性哈希计算拆分为与多个下层存储卷对应的多个子作业文件,这样便于提升各节点处理的作业文件的一致性,提升各节点的作业处理效率。
接着,基于第一映射关系和接入策略确定与多个下层存储卷的存储卷标识对应的多个第二访问路径,以使得超过第一可挂载数量的节点可基于多个第二访问路径分别操作与多个下层存储卷对应的多个子作业文件,其中,第一映射关系还包括下层存储卷的存储卷标识和第二访问路径之间的映射关系。
由于批量执行节点(如应用节点)与GlusterFS之间需要建立长连接,为避免单一存储卷连接池压力过大(例如,默认要求一个GlusterFS存储卷最多只能被50个节点挂载),因此需要设计一个分组串并相联的级联结构实现层与层之间的存储共享。通过***(如采用Apollo,其是携程框架部门研发的开源配置管理中心,能够集中化管理应用不同环境、不同集群的配置,配置修改后能够实时推送到应用端,并具备规范的权限、流程治理等特性,支持4个维度管理键-值(Key-Value)格式的配置:应用、环境、集群和命名空间)配置默认接入模式,在满足现有分布式批量***需求的同时,减轻GlusterFS连接压力,并易于存储卷级联架构后续扩展。
例如,至少两层存储卷中各底层存储卷可被第二服务器端的多个节点同时挂载的数量是第一可挂载数量,第一可挂载数量(如15、20、25等)与预设挂载数量阈值(如50等)和备份倍数(如2倍、3倍等)相关,至少两层存储卷中各存储卷的存储卷标识与访问路径之间存在第一映射关系,使得第二服务器端的超过第一可挂载数量的节点(如30个、40个、50个或60个节点等)可基于至少两层存储卷中顶层存储卷标识和第一映射关系,对与顶层存储卷对应的作业文件进行操作。
这样就使得当至少两层存储卷中顶层存储卷被第二服务器端的超过第一可挂载数量的节点同时请求挂载时,超过第一可挂载数量的节点可分别基于多个第二访问路径访问第一服务器端的特定存储空间,以对特定存储空间中的作业文件以子作业文件的形式进行分布式批量处理,多个第二访问路径是通过与顶层存储卷对应的底层存储卷的存储卷标识和第一映射关系确定的。
此外,为了提升存储卷和作业文件的可靠性,提供备份存储卷。例如,存储卷包括多个,多个存储卷中至少一个存在对应的备份存储卷,一个存储卷和与一个存储卷对应的备份存储卷构成一组存储卷,一组存储卷中每个存储卷分别对应相互隔离的特定存储空间,相互隔离的特定存储空间的作业文件同步更新。
例如,备份倍数是两倍,至少两层存储卷中除底层存储卷之外的存储卷可被第二服务器端的多个节点同时挂载的数量是第二可挂载数量,第二可挂载数量小于等于第一可挂载数量的一半。例如,参考图4所示,备份倍数是两倍,存储卷pay-fss-0-1和存储卷pay-fss-0-2构成一组存储卷,存储卷pay-fss-0-2是存储卷pay-fss-0-1的备份存储卷。a-combt01~06的数量是6个,a-agrbt01~16的数量是16个,a-combt01~06的数量小于a-agrbt01~16的数量的一半。
具体地,至少两层存储卷包括第一层存储卷和第二层存储卷,第一层存储卷包括对应于同一作业文件的一对存储卷,第二层存储卷包括多对子存储卷,与多对子存储卷对应的子作业文件的并集与作业文件相同。
此外,为了便于对存储卷和作业文件进行运维(如检测、纠错、更新配置、操作作业文件等),至少两层存储卷中至少一个存储卷被指定节点挂载,以使指定节点检查至少两层存储卷中至少一个存储卷的使用状态和/或操作指定作业文件,指定作业文件对应于至少两层存储卷中至少一个存储卷。对于存在备份存储卷的情形,上述方法还可以包括如下操作,通过指定节点挂载多个存储卷和与多个存储卷对应的备份存储卷中的至少一个,以便于检测与多个存储卷和与多个存储卷对应的备份存储卷中的至少一个的作业文件。
图5示意性示出了根据本公开实施例存储卷级联架构的结构示意。
如图5所示,以至少两层存储卷为两层存储卷为例进行说明。多对子存储卷中同一个子存储卷分别被第一节点集群中小于或等于第一可挂载数量的第一节点挂载,一对存储卷中的同一个存储卷分别被第二节点集群中小于或等于第二可挂载数量的第二节点挂载。
其中,第一节点集群和第二节点集群是第二服务器端的,多对子存储卷的对数与第二节点的数量和第一可挂载数量相关。
以下以图5所示的存储卷级联架构为例,对作业处理过程进行说明。
GTP服务器(包括主、备)默认分别挂载GlusterFS(简称FSS)存储卷epay-fss-0-1和epay-fss-0-2做批量作业文件发送和接收。
普通(common)层批量节点(简称combt,包括a-combt01~06和b-combt01~06)默认挂载FSS存储卷epay-fss-0-1、epay-fss-0-2以及epay-fss-1-1~epay-fss-1-8。
其中,设置combt 01-06作为GTP服务器下面的第一层批量节点,从epay-fss-0-1、epay-fss-0-2获取上游批量文件,逐行按一致性哈希计算所属组,按1~16、……、49~64拆分成4批子文件B1~B4,保存到epay-fss-1-1、epay-fss-1-2,……,epay-fss-1-7、epay-fss-1-8这4组存储卷。第一层批量节点用于对作业文件进行拆分以分配给第二层批量节点,以及将来自第二层批量节点的子作业文件(或批量作业文件)进行汇总,以输出给第一层批量节点。
协定(agreement)层批量节点(简称agrbt,包括a-agrbt01~256和b-agrbt01~256)以16个节点为一组,分别从epay-fss-1-1、epay-fss-1-2,……,epay-fss-1-7、epay-fss-1-8这4组存储卷中获取拆分后的批量子作业文件B1~B4,按一致性哈希解析并过滤出本组节点所需子作业文件,进行批量业务逻辑处理。
汇总数据并向上游提交批量作业文件的流程与拆分作业文件的操作相反,在此不做赘述。
此外,为例提升***的稳定性,还可以设置存储卷epay-fss-1-9、epay-fss-1-10做冗余备份。对于允许***自动配置存储卷的情形,可根据保存的存储卷的使用状态(如存储在Redis中,Redis中存储卷的使用状态可以按需求进行更新,如按预设周期更新、手动更新等),对处于不可用状态的存储卷做动态替换。
以一组存储卷包括两个独立的存储卷为例,可以设置后缀为奇数的存储卷为主存储卷,后缀为偶数的存储卷为备份存储卷。
指定服务器(如ANY服务器)挂载一个或多个存储卷(如所有存储卷),用于运维检查。
以下给出第一可挂载数量的确定方式示例。epay-fss-0-1~2挂载数=GTP服务器*2+combt群组数(可以为6,参考图5所示)*2+ANY*1=15。epay-fss-1-1~epay-fss-1-8挂载数=combt群组数*2+agrbt群组数(可以为16,参考图5所示)*2+ANY*1=45。
为了便于实现第二服务器端对存储卷进行自动分配,提升自动化程度和智能程度,可以设置接入策略,该接入策略可以根据请求挂载的数量等自动基于存储卷级联架构进行存储卷分配,以下以两层存储卷为例对存储卷级联架构的确定方式进行说明。
按每个存储卷最多可被50个客户端(节点)挂载(即VolConn=50),每个批量组有主节点、备节点(2个节点),即SetExecNum=2计算,除去GTP和ANY服务器以外,下层批量群组数(subSetNum)的上限最多可连接23个批量群组,具体可以通过式(1)进行计算:
subSetNum = floor((VolConn-3)/SetExecNum) = 23 式(1)
其中,floor()函数表示向下取整。
对于一个存储卷,上层批量群组负责数据拆分和数据汇总,下层群组负责数据处理。上层群组的连接数量越多,并行拆分合汇总文件的效率越高。下层群组的连接数量越多,所需要的存储卷数量越少。
对于下层批量群组数(subSetNum1),为便于扩展,按2的n次幂向下缩放,具体可以采用如式(2)进行计算:
subSetNum1=scalePow2(floor((VolConn-3)/SetExecNum))=16 式(2)
其中,scalePow2()函数表示按2的n次幂向下缩放。
因此,每个存储卷上层批量群组最多可连接7个节点,下层批量群组数最多包括16个节点。
因此低于16个节点的***,只需要申请1组存储卷连接所有批量节点即可。
作业处理过程可以如下所示,GTP服务器接收到文件以后,最多可有7个(如果按2的n次幂向下缩放,则为4个)上层节点并行处理文件拆分,文件按一致性哈希算法,最多可拆分为16个子文件,分别交由16个下层节点做数据处理。向下游发送数据的过程相似,在此不再赘述。
如上所述,对于包括两层存储卷的存储卷级联架构,如果一个存储卷可被不超过50个节点挂载,并考虑便于扩展的因素,则该两级的存储卷级联架构能支持的批量节点数量的上限为4*16=64个,当有超过64个批量节点需要挂载存储卷时,则可以通过增加存储卷级联架构的层数以提升允许接入的批量节点数量。
以下以多于两层存储卷(n级模式,n为大于2的整数)为例对存储卷级联架构的确定方式进行说明。
除epay-fss-0-1和epay-fss-0-2以外,其他存储卷不连接GTP服务器,因此每个存储卷最多可连接批量群组数如式(3)所示:
floor((VolConn-1)/SetExecNum)=24 式(3)
考虑便于扩展的因素,则下层批量群组数(subSetNum2)最多可连接16个节点,如式(4)所示:
subSetNum2=scalePow2(floor((VolConn-1)/SetExecNum))=16
式(4)
每个存储卷上层批量群组最多可连接8个节点,如式(5)所示:
floor((VolConn-1)/SetExecNum)-subSetNum2=8 式(5)
相应地,存储卷级联架构的层数(getSup)可以如式(6)所示:
getSup=floor(16/8)=2 式(6)
对于n级模式的第n-1层存储卷,向下最多连接节点数为subSetNum2个,即可支持第n层2个存储卷关联的批量集群,因此后续n级每新增getSup*subSetNum2个集群,n-1级都需要新增1组存储卷,递归可计算各层存储卷需求量,并自动生成接入策略配置文件。
具体地,在具有三层存储卷的存储卷级联架构中,对于epay-fss-0-1~epay-fss-0-2,存储卷的允许挂载数=GTP服务器*2+combt群组数(如8个)*2+ANY*1=19。
对于epay-fss-0-3~epay-fss-0-4,存储卷的允许挂载数=combt群组数(如8个)*2+combt群组数(如16个)*2+ANY*1=49。
对于epay-fss-1-1~epay-fss-1-32,存储卷的允许挂载数=combt群组数(如8个)*2+agrbt群组数(如16个)*2+ANY*1=49。
图6示意性示出了根据本公开另一实施例存储卷级联架构的结构示意图。
如图6所示,以具有三层存储卷的存储卷级联架构为例进行说明。至少两层存储卷包括第一层存储卷(如epay-fss-0-1~epay-fss-0-2)、第二层存储卷(如epay-fss-0-3~epay-fss-0-4)和第三层存储卷(如epay-fss-1-1~epay-fss-1-32)。第一层存储卷包括对应于同一作业文件的一对存储卷。第二层存储卷包括多对第一子存储卷,与多对第一子存储卷对应的第一子作业文件的并集与作业文件相同。第三层存储卷包括多对第二子存储卷,对于与一对第一子存储卷对应的多对第二子存储卷,与多对第二子存储卷对应的第二子作业文件的并集与一对第一子存储卷对应的第一子作业文件相同。
一对存储卷中的同一个存储卷分别被第三节点集群中小于或等于第二可挂载数量的第三节点挂载,多对第一子存储卷中同一个子存储卷分别被第四节点集群中小于或等于第二可挂载数量的第四节点挂载,多对第二子存储卷中同一个第二子存储卷分别被第五节点集群中小于或等于第一可挂载数量的第五节点挂载。其中,第三节点集群、第四节点集群和第五节点集群是第二服务器端的,多对第二子存储卷的对数与第五节点的数量以及第一可挂载数量相关。
以下结合图6进行说明,当应用集群从64个节点扩容到256个节点时,为控制每个存储卷的长连接数,存储卷层数和批量节点层数需要从两层扩展到三层。
common层批量节点(combt)01~24从6个节点扩展到24个,其中,combt01-08作为GTP服务器下面的第一层批量节点,从epay-fss-0-1和epay-fss-0-2获取上游批量文件,逐行按一致性哈希计算所属节点,按1~128,129~256拆分成2批子文件A1、A2,保存到epay-fss-0-3和epay-fss-0-4存储卷。
combt09~16、combt17~24作为combt01~08(如属于第三节点集群)下面的第二层批量节点(如属于第四节点集群),从epay-fss-0-3和epay-fss-0-4获取A1或A2的批量文件,逐行按一致性哈希计算所属节点,按1~16、……、241~256拆分成16批子文件B1~B8,B9~B16,保存到epay-fss-1-1、epay-fss-1-2,……,epay-fss-1-31、epay-fss-1-32这16组存储卷。
agreement层批量节点(简称agrbt)从64个节点扩展到256个节点(包括a-agrbt01~256和b-agrbt01~256,如属于第五节点集群),以16个节点为一组,分别从epay-fss-1-1、epay-fss-1-2,……,epay-fss-1-31、epay-fss-1-32这16组存储卷中获取二次拆分后的批量子文件B1~B16,按一致性哈希解析并过滤出本节点所需数据,进行批量业务逻辑处理。
需要说明的是,汇总作业文件并向上游提交批量文件的流程与拆分作业文件的步骤相反,在此不做赘述。
此外,为了提升存储卷的可靠度,可以采用存储卷epay-fss-1-33~epay-fss-1-36做冗余备份,在允许***自动进行存储卷配置时,对于允许***自动配置存储卷的情形,可根据保存的存储卷的使用状态(如存储在Redis中,Redis中存储卷的使用状态可以按需求进行更新,如按预设周期更新、手动更新等),对处于不可用状态的存储卷做动态替换。
在另一个实施例中,为了提升作业处理***的稳定性和可靠性,可以通过在与作业文件对应的存储卷处于异常状态时,进行作业处理模式切换,实现通过其它模式对作业文件进行处理。
图7示意性示出了根据本公开另一实施例的作业处理方法的流程图。
如图7所示,除了包括操作S301~S305之外,上述方法还包括操作S701。
在操作S701,响应于处理模式切换指令,允许第二服务器端通过文件传输协议端口对作业文件进行处理。
其中,该处理模式切换指令是使得第二服务器端从挂载存储卷进行作业处理的模式,变更为通过FTP端口进行作业处理的模式。该处理模式切换指令可以是用户输入的,还可以是在存储卷异常时自动生成的,如根据接入配置自动生成的。
本公开的实施例中,为了提升作业处理效果的稳定性,响应于处理模式切换指令,通过其它模式对作业文件进行处理,以降低存储卷出现异常时无法进行作业处理的情形发生的概率。
图8示意性示出了根据本公开另一实施例的作业处理方法的流程图。在本实施例中,一个作业文件存在相对应的一组存储卷,当一组存储卷中至少一个存储卷处于可用状态时,第二服务器端可通过挂载一组存储卷中可用的一个存储卷对作业文件进行处理。
如图8所示,为了实现在存储卷处于异常状态时,通过切换处理模式使得可以对作业文件进行处理,该方法可以包括操作S801~操作S805。
在操作S801,响应于针对作业文件的作业处理请求,检测一组存储卷中各存储卷的第一使用状态。
具体地,检测一组存储卷中各存储卷的第一使用状态可以包括如下方式中的至少一种。
一种方式为接收来自第二服务器端的第一检测结果。其中,第一检测结果是由第二服务器端创建的第二后台线程和多个第一后台线程实现的,多个第一后台线程用于检测一组存储卷中多个存储卷的第一使用状态,第二后台线程用于检测文件传输协议端口的第二使用状态。
另一种方式为控制第一特定服务器挂载一组或多组存储卷中至少一个以检测一组存储卷中至少一个的第一使用状态,和/或,控制第二特定服务器检测文件传输协议端口的第二使用状态。其中,第一特定服务器和第二特定服务器可以相同或不同。
例如,可以通过如图5和图6中ANY服务器检测各存储卷的第一使用状态和FTP端口的第二使用状态。此外,还可以是由挂载存储卷的节点上报存储卷的第一使用状态。
在操作S803,如果确定一组存储卷中各存储卷的第一使用状态全部是异常状态,则检测文件传输协议端口的第二使用状态。
在操作S805,如果确定第二使用状态是可用状态,则允许第二服务器端通过文件传输协议端口对作业文件进行处理。例如,可以采用相关技术中基于FTP端口对作业文件进行处理的方法,在此不再详述。
为了提升存储卷的可用性,一个存储卷可以存在与其对应的一个或多个备用存储卷。当一个存储卷和与该一个存储卷对应的备份存储卷构成一组存储卷,一组存储卷中每个存储卷分别对应相互隔离的特定存储空间时,可以通过以下方式尽量保持不同时刻对作业文件存储、访问的一致性。例如,降低部分节点针对与上述一个存储卷对应的作业文件进行操作,而其它节点针对与上述一个存储卷的备份存储卷对应的作业文件进行操作,导致无法保持前后作业文件存储、访问的一致性的问题发生。
具体地,上述相互隔离的特定存储空间可以包括多个等级。相应地,响应于来自第二服务器端的第一操作指令,对特定存储空间的作业文件进行处理包括如下操作。
对于一组存储卷,响应于来自第二服务器端的第一操作指令,对上述相互隔离的特定存储空间中满足当前存储空间处理条件、并且等级最高的特定存储空间中作业文件进行处理。例如,当前存储空间处理条件可以为:当前可通过挂载存储卷的方式对作业文件进行处理。
然后,如果多个等级的特定存储空间都满足降级处理条件,则触发处理模式切换指令。这样即可通过处理模式切换的方式提升作业处理方法的可用性。
在一个实施例中,还可以分别为一组存储卷中各存储卷设置等级,以便于基于存储卷的等级进行存储卷分配。例如,一组存储卷包括至少两个等级的存储卷,不同等级的存储卷的处理优先级不同。相应地,检测一组存储卷中各存储卷的第一使用状态包括如下操作。按照等级从高到低的顺序逐个检测与一组存储卷中各存储卷的第一使用状态,直至确定一组存储卷中第一使用状态为可用状态、并且优先级最高的待挂载存储卷,或者直至确定一组存储卷中各存储卷的第一使用状态全部为异常状态。其中,存储空间的等级和存储卷的等级可以相同,上述等级是可以设定的,还可以是基于实验或运行过程中检测的参数确定的。例如,存储空间1的数据读写速度快于存储空间2的数据读写速度,则存储空间1的等级可以高于存储空间2的等级。又例如,存储空间1的数据读写准确率高于存储空间2的数据读写准确率,则存储空间1的等级可以高于存储空间2的等级。
图9示意性示出了根据本公开实施例的一组存储卷的结构示意图。
如图9所示,一个存储卷可以存在一个或多个备份存储卷,如图9中,存储卷1具有作为备份用的存储卷2和存储卷3,其中,与存储卷1对应的特定存储空间为存储空间1,与存储卷2对应的特定存储空间为存储空间2,与存储卷3对应的特定存储空间为存储空间3。存储空间1、存储空间2和存储空间3存储的作业文件都是作业文件1。当第二服务器端通过挂载存储卷1~存储卷3中任意一个对对应的存储空间中的作业文件1进行操作时,该操作的结果会同步至其余存储空间中的作业文件1。
为了保证操作对象的一致性,一组存储卷可以包括多个等级,如图9中存储卷1为等级1,存储卷2为等级2,存储卷3为等级3,各等级的优先级为:等级1大于等级2,等级2大于等级3。当第二服务器端请求对作业文件进行操作时,第一服务器端会按照与该作业文件对应的一组存储卷中各存储卷的第一使用状态和存储卷等级进行存储卷分配。例如,请求挂载存储卷1时,第一服务器端会确定该储卷1是否处于可用状态,如果是,则允许第二服务器端挂载存储卷1;如果否,则从存储卷1的备份存储卷(如存储卷2和存储卷3)中获得处于可用状态且等级最高的存储卷,如存储卷2和存储卷3都是可用状态,存储卷2的等级高于存储卷3的等级,则第一服务器端会为第二服务器端分配存储卷2。
在另一个实施例中,上述方法还可以包括如下操作。在确定一组存储卷中第一使用状态为可用状态、并且优先级为最高的待挂载存储卷之后,允许第二服务器端通过挂载待挂载存储卷以对作业文件进行处理。
此外,如果确定第一使用状态全部为异常状态,和/或,如果确定第二使用状态为异常状态,则进行异常提示。这样便于运维人员及时进行故障处理。
由于存储卷的第一使用状态可能随着网络异常、设备异常等被修复,使得之前处于异常状态的存储卷可能随着时间的延长,转变为处于可用状态的存储卷。因此,为了提升用户使用便捷度,如降低运维中手动操作的比例,可以自动检测之前处于异常状态的存储卷,便于在存储卷处于可用状态,或者等级高的存储卷处于可用状态时,优先使得第二服务器端采用挂载存储卷的方式进行作业处理,或者为第二服务器端分配等级高的存储卷。
在一个实施例中,上述方法还可包括如下操作。
在第二服务器端通过文件传输协议端口对作业文件进行处理的过程中,当满足第一升级检测条件时,检测一组存储卷中等级最低的存储卷的第一使用状态是否是可用状态。其中,第一升级检测条件可以是预先设置的条件,如第二服务器端通过文件传输协议端口对作业文件进行处理的时长超过特定时长阈值、接收到升级检测指令、接收到存储卷的第一使用状态更新指令等。
如果确定一组存储卷中等级最低的存储卷的第一使用状态是可用状态,则停用文件传输协议端口,并且允许第二服务器端挂载一组存储卷中等级最低、并且处于可用状态的存储卷。这样就可以实现:在上述一组存储卷中至少一个处于可用状态时,使得第二服务器端自动切换至采用存储卷挂载的方式进行作业处理。
此外,为了便于使得第二服务器端可以自动挂载等级最高的存储卷进行作业处理,上述方法还可以包括如下操作。
在使得第二服务器端挂载等级最低的存储卷之后,按照等级从低到高的顺序逐个挂载一组存储卷中处于可用状态的存储卷,直至一组存储卷中等级最高的存储卷被挂载。这样有助于使得第二服务器端对同一个作业文件进行处理时,尽量挂载相同的等级最高的存储卷,保证作业处理效率。
以下以一个通过降级的方式来提高作业处理方法的可用性的实施例进行说明。
图10示意性示出了根据本公开实施例的降级窗口的示意图。图11示意性示出了根据本公开实施例的降级处理的逻辑图。
如图10和图11所示,为了提升第二服务器端对一个作业文件(如一个批次的批量作业集合)进行处理的一致性,可以按照“前序作业->存储->后序作业”划分为多个子集(如进行作业划分时需要考虑各子集的执行时间的前后顺序),每个子集的后序作业按照前序作业对应的存储卷的检测结果(如对应的存储卷的第一使用状态是否为可用状态),选择存储空间进行文件读写。只要能保证该作业文件达到存储介质的一致性,即可保证作业正常执行。这样可以将每组存储卷作为一个可用性维护的最小单元,做到精细化的高可用管控。
以三层级联为例进行说明:作业1->存储空间A->作业2->存储空间B->作业3。
开口是作业1,对于存储空间A来说,作业1是前序作业,作业2是后序作业。作业1能检测存储空间A采用租户1、租户2或者FTP模式,并将检测结果存储在Redis上。
作业2接收存储空间A的作业文件时可以不检测存储空间A采用租户1、租户2或者FTP模式,直接使用作业1保存在Redis上的存储空间A的可用性标志。
但作业2执行完以后,输出文件要写入存储空间B,作业2使用租户1、租户2或者FTP模式,作业1是检测不了的,因为作业1所在的批量执行节点没有连接存储空间B,只能由作业2检测,此时对于存储空间B来说,作业2是前序作业,作业3是后序作业。
因此高可用的最小管理单元是“一组存储卷”,相应地,降级资源配置(如在开源工具Sentinel中进行配置时),也要按存储卷来设置。
以下以通过开源工具Sentinel实现双租户切换以提升作业处理方法的可用性为例进行说明。Sentinel是用以实现应用***的流量控制、熔断降级、负载保护的工具。
具体地,从保存批量作业文件的GlusterFS申请两个独立租户,每个租户位于一个独立的Gluster集群存储池。虽然GlusterFS本身具备很高的高可靠性,但是考虑到园区级故障带来的整体影响,因此可以申请物理隔离的两套租户进行主备设置,如两套Gluster集群部署在同城两个园区。然后,利用开源工具Sentinel的降级策略(DegradeRule),对GlusterFS进行可用性检测及三级降级处理。
在一种实施方式中,可以基于特定的异常计数降级策略(DEGRADE_GRADE_EXCEPTION_COUNT)构建公共检测模块,在Apollo分布式配置中心设置两层降级资源(如开源工具Sentinel中设置Res_FST1、Res_FST2、……),对GlusterFS存储卷和FTP端口进行异常检测。需要说明的是,除了异常计数降级策略之外,还可以基于异常比率降级策略(DEGRADE_GRADE_EXCEPTION_RATIO)、平均响应时间降级策略(DEGRADE_GRADE_RT)等,构建公共检测模块。
降级策略可以如下所示。
在挂载存储卷后,首个批量前序作业(开口作业)被执行时,默认按照与GlusterFS存储卷(以下简称为租户1)对应的第一指定存储空间进行文件读写测试。
当测试结果正常时,退出检测模块。后序作业处理使用租户1进行文件读写处理。
当测试结果异常时,如果异常次数小于第一异常阈值(如3次),对租户1重复进行检测,间隔时间可在Apollo配置,实时生效,默认5秒。
当租户1异常出现次数达到第一异常阈值(如3次)时,资源Res_FST1触发降级,在租户1读写测试对应的降级方法内,对租户2进行作业文件的读写测试。
当租户2测试结果正常时,退出检测模块。后序作业使用租户2进行作业文件的读写处理。
负载到该执行节点上的其他前序作业在租户1降级时间内(可以为第一设定时间阈值,如默认20分钟),不会再对租户1进行测试,直接调用租户2的检测逻辑。若租户2状态正常,则该前序作业的后序作业,使用租户2进行文件读写处理。
当租户2测试结果异常,且异常次数达到第二异常阈值(如3次)时,资源Res_FST2触发降级,在租户2读写测试对应的降级方法内,基于FTP端口进行读写测试。
当FTP测试结果正常时,退出测试模块,后序作业使用FTP进行文件读写处理。
负载到该执行节点上的其他前序作业在租户2降级时间内(可以为第二设定时间阈值,如默认10分钟),不会再对租户1、租户2进行测试,直接调用FTP的检测逻辑,若FTP状态正常,则该前序作业的后序作业,使用FTP进行文件读写处理。
当FTP检测结果异常时,会进行报警处理,如向监控中心发送监控报文。
当Res_FST2降级时间窗口到期后,会重新进行租户2的可用性检测,如果可用,则恢复到GlusterFS租户2做文件读写。
当Res_FST1降级时间窗口到期后,会重新进行租户1的可用性检测,如果可用,则恢复到GlusterFS租户1做文件读写。
因此从逻辑上Res_FST1的降级窗口要设置得比Res_FST2大一些。这样可以有效提升作业文件处理的一致性。
其中,可用性监控(GlusterFS存储卷和FTP的可用性监控)可分为批量执行器的存储可用性,以及存储介质的可用性监控两个维度。为了实现从上述两个维度进行监控,可以通过如下方式实现。
一方面,每个容器配置2组可用性模块编码,分别对应该容器使用的GlusterFS存储卷的可用性,以及FTP的可用性,容器启动后注册到监控中心。每个容器生成2个后台线程,对当前容器可用的GlusterFS存储卷、FTP进行文件读写、连接的检查,如果当前容器已降级到FTP模式,则监控中心只会接到FTP模式的心跳。否则该容器对当前可用的FS存储卷、以及FTP进行可用性监控和心跳报文发送。
另一方面,ANY服务器上执行一个后台脚本,对所有存储卷和FTP进行可用性检测和心跳报文发送
此外,对于一个作业文件,为了便于给后续请求挂载存储卷的节点分配相同的存储卷,上述方法还可以包括如下操作。
在检测一组存储卷中各存储卷的第一使用状态之后,存储第一使用状态,以便于响应于来自第二服务器端的存储卷挂载请求,基于第一使用状态为第二服务器端分配与存储卷挂载请求对应的一组存储卷中的一个。
具体地,可以标记处于异常状态的存储卷和文件传输协议端口,以禁止第二服务器端挂载处于异常状态的存储卷,以及禁止第二服务器端通过处于异常状态的文件传输协议端口处理作业文件。
例如,在Res_FST1和Res_FST2触发降级时,发送事件监控报文到监控中心,标记异常的存储卷名或FTP,以及降级后采用的存储卷或FTP。
采用如上所示的降级策略,可以具有如下所示的优势。
首先,将一个批次的批量作业集合按照“前序作业->存储->后序作业”划分为多个子集,每个子集的后序作业按照前序作业的检测结果,选择存储介质进行文件读写。只要该组作业内达到存储介质的一致性,即可保证作业正常执行。这样可以将每组存储卷作为一个可用性维护的最小单元,做到精细化的高可用管控。
其次,利用降级策略,可以做到同一容器内租户1、租户2、FTP的自动检测与切换,在降级时间窗口内,负载到相同容器内的前序作业,可以直接利用前序批量作业的检测结果,为后序批量作业配置可用的存储方式,降低了检测时间损耗。
此外,利用Sentinel对Apollo的支持,可以实现降级策略的灵活配置与实时更新。
本公开的另一方面提供了一种作业处理装置。
图12示意性示出了根据本公开实施例的作业处理装置的框图。
如图12所示,该作业处理装置1200可以包括路径确定模块1210、连接建立模块1220和第一分布处理模块1230。
其中,路径确定模块1210用于响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,其中,存储卷挂载请求包括存储卷标识,第一映射关系是存储卷标识和访问路径之间的映射关系。
连接建立模块1220用于建立第一服务器端与第二服务器端之间的长连接,以使得第二服务器端可挂载与存储卷标识对应的存储卷,基于访问路径访问第一服务器端的特定存储空间,特定存储空间用于存储作业文件。
第一分布处理模块1230用于响应于来自第二服务器端的第一操作指令,对特定存储空间的作业文件进行处理。
本公开的另一方面提供了一种存储卷级联架构,包括至少两层存储卷,对于相邻的两层存储卷,与一个上层存储卷对应的作业文件被拆分为分别与多个下层存储卷对应的多个子作业文件。
其中,至少两层存储卷中各底层存储卷可被第二服务器端的多个节点同时挂载的数量是第一可挂载数量,第一可挂载数量与预设挂载数量阈值和备份倍数相关,至少两层存储卷中各存储卷的存储卷标识与访问路径之间存在第一映射关系,使得第二服务器端的超过第一可挂载数量的节点可基于至少两层存储卷中顶层存储卷标识和第一映射关系,对与顶层存储卷对应的作业文件进行操作。
本公开的另一方面提供了一种作业处理装置。该作业处理装置包括第一状态检测模块、第二状态检测模块和第一作业处理模块。
其中,第一状态检测模块用于响应于针对作业文件的作业处理请求,检测一组存储卷中各存储卷的第一使用状态。
第二状态检测模块用于如果确定一组存储卷中各存储卷的第一使用状态全部是异常状态,则检测文件传输协议端口的第二使用状态。
第一作业处理模块用于如果确定第二使用状态是可用状态,则允许第二服务器端通过文件传输协议端口对作业文件进行处理。
本公开的另一方面提供了一种作业处理***。
图13示意性示出了根据本公开实施例的作业处理***的框图。
如图13所示,该作业处理***1300可以包括:公共组件1310和数据存储模块1320。
其中,公共组件1310用于响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,并且建立与第二服务器端之间的长连接,以实现存储卷挂载。
数据存储模块1320用于提供存储空间,以存储作业文件、存储卷标识和访问路径之间的第一映射关系。
图14示意性示出了根据本公开另一实施例的作业处理***的框图。
如图14所示,该作业处理***1400除了包括公共组件和数据存储模块之外,还可以包括以下至少一个模块:接入配置模块、可用性保证模块和运维辅助模块。
其中,接入配置模块用于基于存储卷的挂载请求的数量和存储卷级联架构确定接入策略,使得公共组件可基于接入策略进行存储卷动态分配,以便基于存储卷动态分配的结果确定访问路径。
可用性保证模块用于对存储卷和/或文件传输协议端口进行可用性检查,以便于在可用性检查的结果满足降级处理条件时,切换存储卷或者触发处理模式切换指令。例如,该可用性保证模块具体用于检测存储卷的第一使用状态,以便于在与作业文件对应的一组存储卷中各存储卷的第一使用状态全部是异常状态时,触发处理模式切换指令以通过文件传输协议端口进行数据传输。
运维辅助模块,用于实现以下至少一种操作:查询已挂载的存储卷信息;检查存储卷和/或文件传输端口的使用状态;检查与存储卷对应的作业文件。
以下以一个具体实施例对上述作业处理***进行说明。
关于数据存储模块。
在GlusterFS***内构建两套物理隔离的存储卷集合,一组为主,一组为备。
保存原有FTP读写逻辑,作为分布式存储***整体异常后的第三级存储方案。
Redis上保存各批量节点与存储卷的挂载关系以及可用性标志。
关于可用性保证模块。
在每个批量节点对当前节点挂载的GlusterFS存储卷定时进行读写检查,发送心跳包到监控中心
在每个批量节点对GTP传输服务器的FTP端口进行连通性检查,发送心跳包到监控中心
引入Sentinel对GlusterFS的主、备、FTP进行三级降级检查,一旦某一级存储***异常,自动降到下一级使用(Redis登记,保持前后作业存储访问的一致性)。
关于接入配置模块。
在分布式配置中心(Disconf)配置默认接入策略,配置一套批量群组和Gluster存储卷之间的挂载映射关系,以及模式开关(Gluster/FTP)。
提供研发辅助工具,输入节点数(SET数),自动生成Disconf上配置的接入策略。
需要说明的是,存储卷级联架构从两层存储卷变为三层存储卷时,只需要相应地修改Disconf的接入配置文件,追加新增节点的配置项即可。关于公共组件,可以包括如下模块。
数据存储预检查模块,用于对当前节点GlusterFS存储卷进行降级检查,将检查结果保存到Redis,以便后续依赖作业按照一致的存储卷进行批量数据处理。
存储挂载处理模块,用于在批量节点启动脚本内调用,从配置Disconf的接入策略中,获取GlusterFS总开关标志(fssEnable),自动分配开关标志(autoDispatcher)。
如果自动分配开关标志是失败(autoDispatcher=false),则按Disconf上的默认接入策略进行当前节点的存储卷挂载。
如果自动分配开关标志是真(autoDispatcher=true),则获取Disconf接入策略中所有默认已分配和备份的存储卷名,利用Redis的分布式锁做存储卷动态分配。
文件读写公共模块,用于提供公共方法屏蔽FTP模式和GlusterFS模式对文件读写的操作。
关于运维辅助模块。
提供运维小工具,一键查询各分布式批量节点或群组挂载的GlusterFS存储卷列表,并检测可用性。
预备专用的服务器挂载所有被申请挂载的存储卷,便于运维直接检查存储卷内保存的文件内容。
需要说明的是,装置、***部分实施例中各模块/单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似,在此不再一一赘述。
根据本公开的实施例的模块、单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、单元中的任意一个或多个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC),或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现,或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者,根据本公开实施例的模块、单元中的一个或多个可以至少被部分地实现为计算机程序模块,当该计算机程序模块被运行时,可以执行相应的功能。
例如,路径确定模块1210、连接建立模块1220和第一分布处理模块1230中的任意多个可以合并在一个模块中实现,或者其中的任意一个模块可以被拆分成多个模块。或者,这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合,并在一个模块中实现。根据本公开的实施例,路径确定模块1210、连接建立模块1220和第一分布处理模块1230中的至少一个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上***、基板上的***、封装上的***、专用集成电路(ASIC),或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现,或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者,路径确定模块1210、连接建立模块1220和第一分布处理模块1230中的至少一个可以至少被部分地实现为计算机程序模块,当该计算机程序模块被运行时,可以执行相应的功能。
图15示意性示出了根据本公开实施例的电子设备的方框图。图15示出的电子设备仅仅是一个示例,不应对本公开实施例的功能和使用范围带来任何限制。
如图15所示,根据本公开实施例的电子设备1500包括处理器1501,其可以根据存储在只读存储器(ROM)1502中的程序或者从存储部分1508加载到随机访问存储器(RAM)1503中的程序而执行各种适当的动作和处理。处理器1501例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如,专用集成电路(ASIC)),等等。处理器1501还可以包括用于缓存用途的板载存储器。处理器1501可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
在RAM 1503中,存储有电子设备1500操作所需的各种程序和数据。处理器1501、ROM 1502以及RAM 1503通过总线1504彼此通讯连接。处理器1501通过执行ROM 1502和/或RAM 1503中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意,程序也可以存储在除ROM 1502和RAM 1503以外的一个或多个存储器中。处理器1501也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
根据本公开的实施例,电子设备1500还可以包括输入/输出(I/O)接口1505,输入/输出(I/O)接口1505也连接至总线1504。电子设备1500还可以包括连接至I/O接口1505的以下部件中的一项或多项:包括键盘、鼠标等的输入部分1506;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分1507;包括硬盘等的存储部分1508;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分1509。通信部分1509经由诸如因特网的网络执行通信处理。驱动器1510也根据需要连接至I/O接口1505。可拆卸介质1511,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器1510上,以便于从其上读出的计算机程序根据需要被安装入存储部分1508。
根据本公开的实施例,根据本公开实施例的方法流程可以被实现为计算机软件程序。例如,本公开的实施例包括一种计算机程序产品,其包括承载在计算机可读存储介质上的计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中,该计算机程序可以通过通信部分1509从网络上被下载和安装,和/或从可拆卸介质1511被安装。在该计算机程序被处理器1501执行时,执行本公开实施例的***中限定的上述功能。根据本公开的实施例,上文描述的***、设备、装置、模块、单元等可以通过计算机程序模块来实现。
本公开还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中描述的设备/装置/***中所包含的;也可以是单独存在,而未装配入该设备/装置/***中。上述计算机可读存储介质承载有一个或者多个程序,当上述一个或者多个程序被执行时,实现根据本公开实施例的方法。
根据本公开的实施例,计算机可读存储介质可以是非易失性的计算机可读存储介质,例如可以包括但不限于:便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行***、装置或者器件使用或者与其结合使用。例如,根据本公开的实施例,计算机可读存储介质可以包括上文描述的ROM 1502和/或RAM 1503和/或ROM 1502和RAM 1503以外的一个或多个存储器。
本领域技术人员可以理解,本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合,即使这样的组合或结合没有明确记载于本公开中。这些实施例仅仅是为了说明的目的,而并非为了限制本公开的范围。尽管在以上分别描述了各实施例,但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围,本领域技术人员可以做出多种替代和修改,这些替代和修改都应落在本公开的范围之内。
Claims (9)
1.一种由第一服务器端执行的作业处理方法,包括:
响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,其中,所述存储卷挂载请求包括存储卷标识,所述第一映射关系包括存储卷标识和访问路径之间的映射关系;
建立所述第一服务器端与所述第二服务器端之间的长连接,以使得所述第二服务器端可挂载与所述存储卷标识对应的存储卷,基于所述访问路径访问所述第一服务器端的特定存储空间,所述特定存储空间用于存储作业文件;
响应于来自第二服务器端的第一操作指令,对所述特定存储空间的作业文件进行处理;
响应于来自多个节点针对同一第一存储卷标识的存储卷挂载请求,基于所述第一映射关系确定多个第一访问路径,所述多个节点是第二服务器端的;
建立所述多个节点与所述第一服务器端之间的多个第一长连接,所述多个第一长连接使得所述多个节点可基于所述多个第一访问路径分别访问所述第一服务器端的与所述第一存储卷标识对应的特定存储空间,以使得所述多个节点可共同操作与所述第一存储卷标识对应的特定存储空间的作业文件;
获得针对同一第一存储卷标识的存储卷的请求挂载数量;
如果针对同一第一存储卷标识的存储卷的请求挂载数量达到或者超过第一可挂载数量,则根据所述请求挂载数量和存储卷级联架构确定接入策略,其中,所述存储卷级联架构包括至少两层存储卷,对于相邻的两层存储卷,与一个上层存储卷对应的作业文件被拆分为分别与多个下层存储卷对应的多个子作业文件,其中,所述至少两层存储卷的底层存储卷的允许挂载数量小于等于所述第一可挂载数量;以及
基于所述第一映射关系和所述接入策略确定与所述多个下层存储卷的存储卷标识对应的多个第二访问路径,以使得超过所述第一可挂载数量的节点可基于所述多个第二访问路径分别操作与所述多个下层存储卷对应的多个子作业文件,其中,所述第一映射关系还包括下层存储卷的存储卷标识和第二访问路径之间的映射关系。
2.根据权利要求1所述的方法,还包括:
响应于处理模式切换指令,允许第二服务器端通过文件传输协议端口对所述作业文件进行处理。
3.根据权利要求1所述的方法,其中,所述存储卷包括多个,多个存储卷中至少一个存在对应的备份存储卷,一个存储卷和与所述一个存储卷对应的备份存储卷构成一组存储卷,一组存储卷中每个存储卷分别对应相互隔离的特定存储空间,所述相互隔离的特定存储空间的作业文件同步更新。
4.根据权利要求3所述的方法,其中,所述相互隔离的特定存储空间包括多个等级;
所述响应于来自第二服务器端的第一操作指令,对所述特定存储空间的作业文件进行处理包括:对于一组存储卷,
响应于来自第二服务器端的第一操作指令,对所述相互隔离的特定存储空间中满足当前存储空间处理条件、并且等级最高的特定存储空间中作业文件进行处理;以及
如果所述多个等级的特定存储空间都满足降级处理条件,则触发处理模式切换指令。
5.根据权利要求3所述的方法,还包括:
检测所述一组存储卷中各存储卷的第一使用状态;
存储所述第一使用状态,以便响应于来自第二服务器端的存储卷挂载请求,基于所述第一使用状态为所述第二服务器端分配与所述存储卷挂载请求对应的一组存储卷中的一个。
6.根据权利要求3所述的方法,还包括:
通过指定节点挂载所述多个存储卷和与所述多个存储卷对应的备份存储卷中的至少一个,以便于检测与所述多个存储卷和与所述多个存储卷对应的备份存储卷中的至少一个的作业文件。
7.一种作业处理装置,包括:
路径确定模块,用于响应于来自第二服务器端的存储卷挂载请求,基于第一映射关系确定访问路径,其中,所述存储卷挂载请求包括存储卷标识,所述第一映射关系包括存储卷标识和访问路径之间的映射关系;
连接建立模块,用于建立所述第一服务器端与所述第二服务器端之间的长连接,以使得所述第二服务器端可挂载与所述存储卷标识对应的存储卷,基于所述访问路径访问所述第一服务器端的特定存储空间,所述特定存储空间用于存储作业文件;以及
第一分布处理模块,用于响应于来自第二服务器端的第一操作指令,对所述特定存储空间的作业文件进行处理;
所述作业处理装置还用于:
响应于来自多个节点针对同一第一存储卷标识的存储卷挂载请求,基于所述第一映射关系确定多个第一访问路径,所述多个节点是第二服务器端的;
建立所述多个节点与所述第一服务器端之间的多个第一长连接,所述多个第一长连接使得所述多个节点可基于所述多个第一访问路径分别访问所述第一服务器端的与所述第一存储卷标识对应的特定存储空间,以使得所述多个节点可共同操作与所述第一存储卷标识对应的特定存储空间的作业文件;
获得针对同一第一存储卷标识的存储卷的请求挂载数量;
如果针对同一第一存储卷标识的存储卷的请求挂载数量达到或者超过第一可挂载数量,则根据所述请求挂载数量和存储卷级联架构确定接入策略,其中,所述存储卷级联架构包括至少两层存储卷,对于相邻的两层存储卷,与一个上层存储卷对应的作业文件被拆分为分别与多个下层存储卷对应的多个子作业文件,其中,所述至少两层存储卷的底层存储卷的允许挂载数量小于等于所述第一可挂载数量;以及
基于所述第一映射关系和所述接入策略确定与所述多个下层存储卷的存储卷标识对应的多个第二访问路径,以使得超过所述第一可挂载数量的节点可基于所述多个第二访问路径分别操作与所述多个下层存储卷对应的多个子作业文件,其中,所述第一映射关系还包括下层存储卷的存储卷标识和第二访问路径之间的映射关系。
8.一种电子设备,包括:
一个或多个处理器;
存储装置,用于存储可执行指令,所述可执行指令在被所述处理器执行时,实现根据权利要求1~6任一项所述的方法。
9.一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时实现根据权利要求1~6中任一项所述的方法。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010362976.9A CN111586141B (zh) | 2020-04-30 | 2020-04-30 | 作业处理方法、装置、***和电子设备 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010362976.9A CN111586141B (zh) | 2020-04-30 | 2020-04-30 | 作业处理方法、装置、***和电子设备 |
Publications (2)
Publication Number | Publication Date |
---|---|
CN111586141A CN111586141A (zh) | 2020-08-25 |
CN111586141B true CN111586141B (zh) | 2023-04-07 |
Family
ID=72125107
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010362976.9A Active CN111586141B (zh) | 2020-04-30 | 2020-04-30 | 作业处理方法、装置、***和电子设备 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111586141B (zh) |
Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9098525B1 (en) * | 2012-06-14 | 2015-08-04 | Emc Corporation | Concurrent access to data on shared storage through multiple access points |
CN107357524A (zh) * | 2017-06-30 | 2017-11-17 | 四川九洲电器集团有限责任公司 | 存储文件的方法、读取文件的方法、电子设备 |
CN108667904A (zh) * | 2018-04-10 | 2018-10-16 | 浙江大学 | 一种Docker容器远程内存卷管理方法和*** |
CN109213447A (zh) * | 2018-08-23 | 2019-01-15 | 郑州云海信息技术有限公司 | 一种san存储卷挂载、卸载方法及*** |
CN109327539A (zh) * | 2018-11-15 | 2019-02-12 | 上海天玑数据技术有限公司 | 一种分布式块存储***及其数据路由方法 |
CN109976669A (zh) * | 2019-03-15 | 2019-07-05 | 百度在线网络技术(北京)有限公司 | 一种边缘存储方法、装置和存储介质 |
CN110413441A (zh) * | 2019-06-18 | 2019-11-05 | 平安科技(深圳)有限公司 | 主备存储卷同步数据校验方法、装置、设备及存储介质 |
CN110554834A (zh) * | 2018-06-01 | 2019-12-10 | 阿里巴巴集团控股有限公司 | 文件***数据访问方法和文件*** |
-
2020
- 2020-04-30 CN CN202010362976.9A patent/CN111586141B/zh active Active
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US9098525B1 (en) * | 2012-06-14 | 2015-08-04 | Emc Corporation | Concurrent access to data on shared storage through multiple access points |
CN107357524A (zh) * | 2017-06-30 | 2017-11-17 | 四川九洲电器集团有限责任公司 | 存储文件的方法、读取文件的方法、电子设备 |
CN108667904A (zh) * | 2018-04-10 | 2018-10-16 | 浙江大学 | 一种Docker容器远程内存卷管理方法和*** |
CN110554834A (zh) * | 2018-06-01 | 2019-12-10 | 阿里巴巴集团控股有限公司 | 文件***数据访问方法和文件*** |
CN109213447A (zh) * | 2018-08-23 | 2019-01-15 | 郑州云海信息技术有限公司 | 一种san存储卷挂载、卸载方法及*** |
CN109327539A (zh) * | 2018-11-15 | 2019-02-12 | 上海天玑数据技术有限公司 | 一种分布式块存储***及其数据路由方法 |
CN109976669A (zh) * | 2019-03-15 | 2019-07-05 | 百度在线网络技术(北京)有限公司 | 一种边缘存储方法、装置和存储介质 |
CN110413441A (zh) * | 2019-06-18 | 2019-11-05 | 平安科技(深圳)有限公司 | 主备存储卷同步数据校验方法、装置、设备及存储介质 |
Also Published As
Publication number | Publication date |
---|---|
CN111586141A (zh) | 2020-08-25 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US20200358848A1 (en) | Methods, systems, and media for providing distributed database access during a network split | |
US9729666B2 (en) | Large scale storage system and method of operating thereof | |
US9450700B1 (en) | Efficient network fleet monitoring | |
US20160036924A1 (en) | Providing Higher Workload Resiliency in Clustered Systems Based on Health Heuristics | |
CN110096220B (zh) | 一种分布式存储***、数据处理方法和存储节点 | |
WO2012065426A1 (zh) | 一种分布式缓存***中负荷分配方法、装置及服务器 | |
US11784967B1 (en) | Monitoring internet protocol address utilization to apply unified network policy | |
CN111580753B (zh) | 存储卷级联***、批量作业处理***和电子设备 | |
US8977595B1 (en) | Message-recovery file log locating and monitoring | |
US11153173B1 (en) | Dynamically updating compute node location information in a distributed computing environment | |
CN111158949A (zh) | 容灾架构的配置方法、切换方法及装置、设备和存储介质 | |
CN115328662A (zh) | 一种进程线程资源管理控制方法及*** | |
CN114338670B (zh) | 一种边缘云平台和具有其的网联交通三级云控平台 | |
CN111586141B (zh) | 作业处理方法、装置、***和电子设备 | |
CN111586138B (zh) | 作业处理方法、装置、***和电子设备 | |
CN115378962B (zh) | 一种基于iSCSI协议的存储集群的高可用性连通方法和*** | |
CN114172917A (zh) | 一种分布式缓存***及其部署的方法 | |
US11190394B2 (en) | Soft-failure protection for multicast communications | |
US11909719B1 (en) | Managing the allocations and assignments of internet protocol (IP) addresses for computing resource networks | |
WO2018229153A1 (en) | Cross-cluster service provision | |
US11799826B1 (en) | Managing the usage of internet protocol (IP) addresses for computing resource networks | |
CN114945023B (zh) | 一种网络连接复用方法、装置、设备及介质 | |
US8799926B1 (en) | Active node detection in a failover computing environment | |
CN117714386A (zh) | 分布式***部署方法、配置方法、***、设备及介质 | |
CN117221167A (zh) | 一种降低网口绑定主备链路切换时丢包率的测试方法 |
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 |