Container data sharing via external memory device

Abstract

Container data sharing is provided. And in response to the detected fault of the first container for processing the service request, starting a second container in the container cluster to process the service request. Service requests and data stored on the physical external memory device generated by the failed first container are accessed. Service requests and data generated by the failed first container are loaded on the second container from the physical external memory device via a dedicated hardware link for container failure recovery.

Description

Background Art 1. Technical field:

[0001] The present disclosure relates generally to containers, and more particularly to enabling containers running on an operating system with container extensions to utilize physical external memory devices via dedicated hardware links for container data sharing and high-speed container failure recovery.

[0002] 2. Description of related technology:

[0003] A container is the lowest layer of a service (e.g., a microservice) that holds running applications, libraries, and their dependencies. Containers can be exposed using external IP addresses. Containers are commonly used in various cloud environments and bare metal data centers. Currently, when a service request is being processed by a specific container in a container cluster and the specific container encounters a problem that causes the container to crash or fail, the service request is interrupted and the client device requesting the service receives a timeout response after a defined time period. Therefore, after receiving the timeout response, the client device must resend the service request via a standard network so that another container in the cluster processes the service request, resulting in further delays and increased network traffic. However, there is currently no solution that enables containers to utilize physical external memory devices via dedicated hardware links to implement data sharing between containers for high-speed container failure recovery. Summary of the invention

[0004] According to one illustrative embodiment, a computer-implemented method for container data sharing is provided. In response to detecting a failure of a first container processing a service request, a second container in a container cluster is started to process the service request. The service request and data generated by the failed first container stored on a physical external memory device are accessed. The service request and the data generated by the failed first container are loaded from the physical external memory device to the second container via a dedicated hardware link for high-speed container failure recovery. According to other illustrative embodiments, a computer system and a computer program product for container data sharing are provided. As a result, compared to traditional distributed solutions that communicate via standard networks, illustrative embodiments enable containers to utilize physical external memory devices that communicate via dedicated hardware links to achieve high data availability for high-speed container failure recovery. BRIEF DESCRIPTION OF THE DRAWINGS

[0005] Figure 1 is a pictorial representation of a computing environment in which the illustrative embodiments may be implemented;

[0006] Figure 2 is a diagram illustrating an example of a container data sharing architecture according to an illustrative embodiment;

[0007] Figure 3is a diagram showing an example of a container file according to an illustrative embodiment;

[0008] Figure 4 is a diagram showing an example of a memory data sharing process according to an illustrative embodiment;

[0009] Figure 5 is a diagram showing an example of a memory structure according to an illustrative embodiment;

[0010] Figure 6 is a diagram showing an example of a workflow according to an illustrative embodiment;

[0011] Figure 7 is a diagram illustrating an example of a shared queue data sharing process according to an illustrative embodiment;

[0012] Figure 8 is a flow chart illustrating a process for enabling container data sharing according to an illustrative embodiment; and

[0013] Fig. 9 is a flow chart illustrating a process for high-speed container failover using physical external memory devices in accordance with an illustrative embodiment. DETAILED DESCRIPTION

[0014] Various aspects of the present disclosure are described by narrative text, flow charts, block diagrams of computer systems, and / or block diagrams of machine logic included in computer program product (CPP) embodiments. With respect to any flow chart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flow chart. For example, again depending on the technology involved, two operations shown in consecutive flow chart blocks may be performed in reverse order, as a single integrated step, simultaneously, or in a manner that at least partially overlaps in time.

[0015] Computer program product embodiments ("CPP embodiments" or "CPP") are terms used in this disclosure to describe any collection of one or more storage media (also referred to as "media") collectively included in a collection of one or more storage devices that collectively include machine-readable code corresponding to instructions and / or data for performing the computer operations specified in a given CPP claim. A "storage device" is any tangible device that can hold and store instructions for use by a computer processor. Without limitation, a computer-readable storage medium may be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include these media include: magnetic disks, hard disks, random access memories (RAM), read-only memories (ROM), erasable programmable read-only memories (EPROM or flash memory), static random access memories (SRAM), compact disk read-only memories (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks, mechanical encoding devices (such as punch cards or pits / land formed in a major surface of a disk), or any suitable combination of the foregoing. Computer-readable storage media, as the term is used in this disclosure, should not be construed as storing in the form of transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides, light pulses transmitted through fiber optic cables, electrical signals transmitted through wires and / or other transmission media. As will be appreciated by those skilled in the art, data is typically moved at certain occasional points in time during normal operation of the storage device, such as during access, defragmentation, or garbage collection, but this does not make the storage device transient because the data is not transient while it is stored.

[0016] Referring now to the drawings, and in particular to the Figure 1-2 , provides a diagram of a data processing environment in which an illustrative embodiment may be implemented. It should be understood that Figure 1-2 This is meant to be an example only and is not intended to assert or imply any limitation with regard to the environments in which different embodiments may be implemented.Many modifications to the described environments may be made.

[0017] Figure 1A graphical representation of a computing environment in which an illustrative embodiment may be implemented is shown. Computing environment 100 includes an example of an environment for executing at least some of the computer code involved in performing the method of the present invention, such as container data sharing code 200. Container data sharing code 200 enables containers running on an operating system with container extensions to share container data using physical external memory devices via dedicated hardware links to achieve high-speed container failure recovery. In addition to container data sharing code block 200, computing environment 100 includes, for example, computer 101, wide area network (WAN) 102, end user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, the computer 101 includes a processor set 110 (including a processing circuit 120 and a cache 121), a communication structure 111, a volatile memory 112, a permanent storage device 113 (including an operating system 122 and a container data sharing code block 200, as described above), a peripheral device set 114 (including a user interface (UI) device set 123, a storage device 124, and an Internet of Things (IoT) sensor set 125), and a network module 115. The remote server 104 includes a remote database 130. The public cloud 105 includes a gateway 140, a cloud coordination module 141, a host physical machine set 142, a virtual machine set 143, and a container set 144.

[0018] Computer 101 may take the form of a desktop computer, laptop computer, tablet computer, smart phone, smart watch or other wearable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or developed in the future that is capable of running programs, accessing a network, or querying a database such as remote database 130. As is well known in the art of computer technology, and depending on the technology, the performance of computer-implemented methods may be distributed among multiple computers and / or among multiple locations. On the other hand, in this presentation of computing environment 100, the detailed discussion focuses on a single computer, particularly computer 101, to keep the presentation as simple as possible. Computer 101 may be located in the cloud, even though it is not yet fully understood. Figure 1 1 is not shown in the cloud, on the other hand, computer 101 need not be in the cloud except to any extent that can be positively indicated.

[0019] Processor set 110 includes one or more computer processors of any type known now or to be developed in the future. Processing circuit 120 may be distributed over multiple packages, such as multiple cooperating integrated circuit chips. Processing circuit 120 may implement multiple processor threads and / or multiple processor cores. Cache 121 is a memory located in the processor chip package and is typically used for data or code that should be quickly accessed by threads or cores running on processor set 110. Cache memory is typically organized into multiple levels based on relative proximity to the processing circuit. Alternatively, some or all of the caches of the processor set may be located "off chip". In some computing environments, processor set 110 may be designed to work with qubits and perform quantum computing.

[0020] Computer-readable program instructions are typically loaded onto the computer 101 to cause the processor set 110 of the computer 101 to perform a series of operating steps to implement a computer-implemented method, so that the instructions so executed will instantiate the method specified in the flowchart and / or narrative description of the computer-implemented method included in this document (collectively referred to as the "method of the present invention"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache 121 and other storage media discussed below. The program instructions and related data are accessed by the processor set 110 to control and direct the execution of the computer-implemented method. In the computing environment 100, at least some of the instructions for performing the method of the present invention may be stored in a block 200 in a persistent storage device 113.

[0021] The communication fabric 111 is the signal conduction paths that allow the various components of the computer 101 to communicate with each other. Typically, the fabric is made up of switches and conductive paths, such as those that make up a bus, a bridge, physical input / output ports, etc. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths.

[0022] The volatile memory 112 is any type of volatile memory now known or developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, the volatile memory 112 is characterized by random access, but this is not required unless affirmatively indicated. In the computer 101, the volatile memory 112 is located in a single package and is internal to the computer 101, but, alternatively or additionally, the volatile memory can be distributed in multiple packages and / or located externally relative to the computer 101.

[0023] Permanent storage 113 is any form of non-volatile storage for computers known now or developed in the future. The non-volatility of the memory means that the stored data is maintained regardless of whether power is supplied to the computer 101 and / or directly to the permanent storage 113. Permanent storage 113 can be a read-only memory (ROM), but usually at least a portion of the permanent storage allows the writing of data, the deletion of data, and the re-writing of data. Some common forms of persistent storage include disks and solid-state storage devices. Operating system 122 can take several forms, such as various known proprietary operating systems or operating systems of the open source portable operating system interface type using a kernel. The code included in block 200 generally includes at least some computer codes involved in executing the method of the present invention.

[0024] The peripheral device set 114 includes a set of peripheral devices of the computer 101. The data communication connection between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as a Bluetooth connection, a near field communication (NFC) connection, a connection made by a cable (such as a universal serial bus (USB) type cable), a plug-in type connection (e.g., a secure digital (SD) card), a connection made through a local area communication network, and even a connection made through a wide area network such as the Internet. In various embodiments, the UI device set 123 may include components such as display screens, speakers, microphones, wearable devices (such as goggles and smart watches), keyboards, mice, printers, touchpads, game controllers, and tactile devices. The storage device 124 is an external storage device, such as an external hard drive, or a pluggable storage device, such as an SD card. The storage device 124 can be permanent and / or volatile. In some embodiments, the storage device 124 can take the form of a quantum computing storage device for storing data in the form of quantum bits. In embodiments where the computer 101 needs to have a large amount of storage (e.g., where the computer 101 locally stores and manages a large database), the storage may be provided by a peripheral storage device designed to store very large amounts of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor set 125 consists of sensors that can be used in IoT applications. For example, one sensor may be a thermometer, while another sensor may be a motion detector.

[0025] The network module 115 is a collection of computer software, hardware, and firmware that allows the computer 101 to communicate with other computers via the WAN 102. The network module 115 may include hardware such as a modem or a Wi-Fi signal transceiver, software for packetizing and / or depacketizing data transmitted over a communication network, and / or web browser software for transmitting data over the Internet. In some embodiments, the network control function and the network forwarding function of the network module 115 are performed on the same physical hardware device. In other embodiments (e.g., embodiments utilizing software defined networks (SDN)), the control function and the forwarding function of the network module 115 are performed on physically separated devices, so that the control function manages several different network hardware devices. Computer-readable program instructions for executing a computer-implemented method can typically be downloaded to the computer 101 from an external computer or an external storage device via a network adapter card or a network interface included in the network module 115.

[0026] WAN 102 is any wide area network (e.g., the Internet) capable of transmitting computer data over non-local distances by any technology now known or developed in the future for transmitting computer data. In some embodiments, WAN 102 may be replaced and / or supplemented by a local area network (LAN) designed to transmit data between devices located in a local area (e.g., a Wi-Fi network). WANs and / or LANs typically include computer hardware such as copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and edge servers.

[0027] End-user device (EUD) 103 is any computer system used and controlled by an end-user (e.g., a customer of an enterprise operating computer 101), and may take any of the forms discussed above in connection with computer 101. EUD 103 typically receives useful and usable data from the operation of computer 101. For example, in the hypothetical case where computer 101 is designed to provide recommendations to an end-user, the recommendations would typically be transmitted from network module 115 of computer 101 to EUD 103 via WAN 102. In this manner, EUD 103 may display or otherwise present the recommendations to the end-user. In some embodiments, EUD 103 may be a client device, such as a thin client, a heavy client, a mainframe computer, a desktop computer, etc.

[0028] Remote server 104 is any computer system that provides at least some data and / or functionality to computer 101. Remote server 104 may be controlled and used by the same entity that operates computer 101. Remote server 104 represents a machine that collects and stores useful and usable data for use by other computers, such as computer 101. For example, in the hypothetical case where computer 101 is designed and programmed to provide recommendations based on historical data, the historical data may be provided to computer 101 from remote database 130 of remote server 104.

[0029] The public cloud 105 is any computer system available for use by multiple entities that provides on-demand availability of computer system resources and / or other computer capabilities, particularly data storage (cloud storage) and computing capabilities, without direct active management by users. Cloud computing typically utilizes the sharing of resources to achieve consistency and economy of scale. The direct and active management of the computing resources of the public cloud 105 is performed by computer hardware and / or software of the cloud coordination module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that constitute the host physical machine set 142, which is the universe of physical computers in and / or available for the public cloud 105. Virtual computing environments (VCEs) typically take the form of virtual machines from a virtual machine set 143 and / or containers from a container set 144. It should be understood that these VCEs can be stored as images and can be transferred between various physical machine hosts as images or after instantiation of the VCEs. Cloud orchestration module 141 manages the transfer and storage of images, deploys new instantiations of VCEs, and manages active instantiations of VCE deployments. Gateway 140 is a collection of computer software, hardware, and firmware that allows public cloud 105 to communicate over WAN 102 .

[0030] Some further explanation of a virtualized computing environment (VCE) will now be provided. A VCE can be stored as an "image". A new active instance of the VCE can be instantiated from the image. Two common types of VCEs are virtual machines and containers. Containers are VCEs that use operating system-level virtualization. This refers to an operating system feature in which the kernel allows the existence of multiple isolated user space instances, called containers. From the perspective of the programs running in them, these isolated user space instances typically behave like actual computers. Computer programs running on a normal operating system can utilize all of the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, programs running within a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization.

[0031] The private cloud 106 is similar to the public cloud 105, except that the computing resources are only available to a single enterprise. Although the private cloud 106 is depicted as communicating with the WAN 102, in other embodiments, the private cloud can be completely disconnected from the Internet and can only be accessed through a local / private network. A hybrid cloud is a combination of multiple clouds of different types (e.g., private, community, or public cloud types), typically implemented by different vendors. Each of the multiple clouds remains an independent and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable coordination, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, the public cloud 105 and the private cloud 106 are both part of a larger hybrid cloud.

[0032] As used herein, when used with reference to a project, a "set" means one or more projects. For example, a cloud set is one or more cloud environments of different types. Similarly, "plurality" when used with reference to a project means one or more projects.

[0033] In addition, the term "at least one" when used with a list of items means that different combinations of one or more of the listed items can be used, and only one of each item in the list may be required. In other words, "at least one" refers to any combination of items, and a number of items from the list can be used, but not all items in the list are required. The item can be a specific object, thing, or category.

[0034] For example, but not limited to, "at least one of item A, item B, or item C" may include item A, item A and item B, or item B, and this example may also include item A, item B and item C, or item B and item C. Of course, any combination of these items may exist. In some illustrative examples, "at least one" may be, for example, but not limited to, two items A; one item B; and ten items C; four items B and seven items C; or other suitable combinations.

[0035] The container may run on an operating system that may utilize physical external memory devices such as, for example, a coupling facility. A coupling facility is a host processor that runs in its own logical partition (LPAR) that is defined via a hardware management console that includes a dedicated physical central processor, memory, a dedicated hardware communication channel (e.g., a physical coupling facility link) dedicated to data transfer between shared data queues of the container, and a dedicated operating system (e.g., a coupling facility control code). Aside from the physical coupling facility link, the coupling facility has no I / O devices. The data contained in the coupling facility resides entirely in storage (e.g., memory) because the coupling facility control code is not a virtual memory operating system. Typically, the coupling facility has large storage (e.g., on the order of tens of gigabytes). Furthermore, the coupling facility does not run application software.

[0036] Currently, on some operating systems (e.g. ) can utilize physical external storage devices for data sharing and high availability. z / OS is a registered trademark of International Business Machines Corporation located in Armonk, New York, USA. Entities such as enterprises, businesses, companies, organizations, institutions, agencies, etc. are increasingly embracing the use of mixed workloads. As a result, these operating systems include container extensions to enable containers to run on these operating systems and enable cloud native workloads to run. However, there is currently no solution that enables these containers to utilize physical external storage devices for data sharing and high availability.

[0037] The illustrative embodiments enable containers running on these operating systems with container extensions to utilize physical external memory devices via dedicated hardware links for container data sharing and high-speed container failure recovery. For example, the illustrative embodiments provide a plug-in container external memory application programming interface (API) to enable the container to call the container external memory API to perform operations on the physical external memory device, such as create, delete, clear, lock, unlock, etc., according to the service request being processed by the container. An illustrative example of the plug-in container external memory API is as follows:

[0038] func newExMemoryDriver()(root,EMAddress,EMBase string,servers[]string)exmemoryDriver{}

[0039] func(d exmemoryDriver)Create(r memory.Request)memory.Response{}

[0040] func(d exmemoryDriver)Delete(r memory.Request)memory.Response{}

[0041] func(d exmemoryDriver)Clean(r volume.Request)memory.Response{}

[0042] func(d exmemoryDriver)Lock(r volume.Request)memory.Response{}

[0043] func(d exmemoryDriver)Unlock(r volume.Request)memory.Response{}

[0044] ….

[0045] The illustrative embodiments may generate a new external memory driver function for each corresponding service request received to perform a corresponding operation on that particular physical external memory device.

[0046] In addition, the illustrative embodiment adds an external memory manager to the kernel of the operating system. The external memory manager enables the operating system kernel to generate a dedicated field (e.g., an external memory data field) in the virtual memory and copy the data contained in the external memory data field to the virtual external memory. In addition, the illustrative embodiment adds an external memory utilizer under the container extension virtualization layer. The container extension virtualization layer is, for example, a partition manager, such as a hypervisor. The container extension virtualization layer virtualizes the resources of the container data sharing architecture into multiple LPARs. For example, each corresponding container corresponds to a specific LPAR among the multiple LPARs in the container data sharing architecture. Each LPAR shares physical resources, such as processing power, memory, storage devices, network devices, etc.

[0047] The illustrative embodiment utilizes an external memory utilizer to connect to a cross-system extension service component of an operating system to transfer data from a virtual external memory of a container extension virtualization layer to a physical external memory device. The cross-system extension service component of the operating system includes a section for an external device driver program. The cross-system extension service component utilizes the external device driver program to operate the physical external memory device. The container extension virtualization layer virtualizes the shared container data stored on the physical external memory device to the virtual external memory as directed by the external memory manager.

[0048] The illustrative embodiments utilize an external memory manager to register data changes (e.g., write changes) generated in a container (e.g., a writable container) and send them to a physical external memory device. The external memory manager registers a data structure (i.e., a data storage unit, a memory segment, etc.) in the physical external memory device to store data to be shared between containers in response to the start of a container cluster. In addition, in response to a new service request entering the container cluster, the external memory manager stores the new service request in the external memory device. While the containers in the cluster process the new service request, the external memory manager retrieves each corresponding data change generated by the container and stores each of these data changes in real time in the registered data structure of the physical external memory device.

[0049] In addition, in response to a container that is processing a new service request encountering a problem that causes the container to crash or fail, the external memory manager selects another container in the cluster to take over the processing of the service request. For example, the external memory manager recovers the processing point of the crashed container in other containers by retrieving service requests, the service requests being processed by the crashed container, and the corresponding data changes generated by the crashed container are stored in a registered data structure of the external memory device. The external memory manager then uses a dedicated hardware external memory device link or communication channel to send the retrieved service requests and corresponding data changes to another container in the cluster for high-speed container failure recovery. In addition, the external memory manager synchronizes the service requests and corresponding data changes stored in the external memory device with other containers that took over the processing of the crashed container.

[0050] As a result, by enabling containers managed by an operating system with container extensions to utilize physical external memory devices that communicate via dedicated hardware links, the illustrative embodiments allow these containers to achieve high data availability for high-speed container failure recovery compared to traditional distributed solutions that communicate via standard networks. Therefore, the illustrative embodiments provide one or more technical solutions to overcome technical problems, which have the advantages of enabling containers to share data via physical external memory devices to obtain high data availability, thereby achieving high-speed container failure recovery. Therefore, these one or more technical solutions provide technical effects and practical applications in the field of containers.

[0051] Reference now Figure 2 , a diagram illustrating an example of a container data sharing architecture is depicted in accordance with an illustrative embodiment. The container data sharing architecture 201 may be used in a container such as Figure 1 The container data sharing architecture 201 is a system of hardware and software components for enabling containers to share data via physical external memory devices to obtain high data availability, thereby achieving high-speed container failure recovery.

[0052] In this example, container data sharing architecture 201 includes a conventional operating system (OS) address space 202 of an operating system (e.g., z / OS) and a container extension (CX) virtual container server address space 204. Conventional operating system address space 202 and container extension virtual container server address space 204 represent areas of virtual addresses that can be used to execute instructions and store data.

[0053] The container-extended virtual container server address space 204 includes an operating system kernel 206 including an external memory manager (EMM) 208 and an operating system container engine 210. The operating system container engine 210 includes a standard container API 212 and a plug-in container external memory API 214. Containers 216, 218, 220, and 222 call the plug-in container external memory API 214 to guide the external memory manager 208 to generate virtual external memory 224. It should be noted that containers 216, 218, 220, and 222 are only examples and not limitations of the illustrative embodiments. In other words, the container-extended virtual container server address space 204 can include any number of containers, and the containers can be included in a container cluster. In addition, the containers can handle any type and number of service requests.

[0054] In response to receiving an instruction from one of the plug-in container external memory APIs 214, the external memory manager 208 of the operating system kernel 206 generates a virtual external memory 224. In addition, the external memory manager 208 copies the data generated by the container when processing the service request in the external memory data (EMDATA) field 226 of the virtual memory 228 to the virtual external memory 224. In addition, the external memory manager 208 continuously monitors the data changes in the external memory data field 226 and updates the virtual external memory 224 with those data changes in the external memory data field 226.

[0055] The container extension virtual container server address space 204 also includes an external memory (EM) utilizer 230. The external memory utilizer 230 uses a dedicated hardware link 236 to connect to a physical external memory device 232 via an external memory driver 234 to store data changes from the virtual external memory 224 in the physical external memory device 232 for container data sharing to achieve high-speed container failure recovery in the event of a container failure while processing a service request. The external memory driver 234 controls operations performed on the physical external memory device 232.

[0056] The external memory utilizer 230 generates a cross-system extension service 238 in the conventional operating system address space 202 so as to connect to the physical external memory device 232 through the operating system. It should be noted that the cross-system extension service 238 includes an external memory driver 234. When connected to a specific physical external memory device, the external memory driver 234 selects a corresponding code segment for the type (e.g., coupling facility) of the specific external memory device and connects to the specific external memory device to obtain the shared data resources contained on the specific external memory device. The container extension (CX) virtualization layer 240 virtualizes the shared data resources stored in the specific external memory device to the virtual external memory 224 for container data sharing.

[0057] Furthermore, it should be noted that physical memory 242 represents physical memory corresponding to container extension virtual container server address space 204. Furthermore, certain address spaces of physical memory 242 correspond to specific address spaces in virtual memory 228, particularly address spaces associated with external memory data field 226. This represents data to be shared between containers such as container 216 and container 218 via physical external memory device 232 in the event that container 216 fails while processing a service request.

[0058] Reference now Figure 3 , which is a diagram showing an example of a container file depicted according to an illustrative embodiment. The container file 300 can be implemented in a plug-in container external storage API, such as Figure 2 In one embodiment, the container file 300 is a plug-in container external storage API 214 in the example, and in this example, the container file 300 is a YAML file. YAML is a file of a human-readable data serialization language for storing or transmitting data. However, it should be noted that the container file 300 is intended only as an example and not a limitation of the illustrative embodiment.

[0059] The container file 300 includes an external memory portion 302 in a request section 304. The external memory portion 302 specifies, for example, the type, location, and size of a physical external memory device. The physical external memory device may be, for example, Figure 2 In addition, the container file 300 also includes an external storage location portion 306 in the volume segment 308. The external storage location portion 306 specifies, for example, an external storage location name and a corresponding type, name, and data structure of the external storage device storing the shared container data.

[0060] Reference now Figure 4 , a diagram depicting an example of a memory data sharing process according to an illustrative embodiment. The memory data sharing process 400 may be implemented in a container data sharing architecture, such as Figure 2 Container data sharing architecture 201 in.

[0061] The memory data sharing process 400 includes a physical memory 402, a virtual memory 404, a virtual external memory 406, and an external memory device 408. The physical memory 402, the virtual memory 404, the virtual external memory 406, and the external memory device 408 may be, for example, Figure 2 The physical memory 242, virtual memory 228, virtual external memory 224 and physical external memory device 232 in.

[0062] The memory data sharing process 400 shows the correspondence between the physical memory 402 and the virtual memory 404. The virtual memory 404 includes an external memory data (EMDATA) field 410 (e.g. Figure 2 The external memory manager 412 (e.g. Figure 2 The external memory manager 208 in the virtual memory 404 adds the external memory data field 410 to the virtual memory 404. The external memory manager 412 storage service application wants to store data in the container (i.e., corresponding to the partition of the container, such as, for example Figure 2 In addition, the external memory manager 412 monitors the external memory data field 410 for data changes generated by the container and synchronizes the data changes in the external memory data field 410 to the virtual external memory 406. The external memory utilizer 414 (e.g. Figure 2 The external memory utilization device 230 in the embodiment uses the external memory driver program (e.g. Figure 2 The external memory driver 234 in the container stores the data shared between containers in the external memory device 408 and caches it in the virtual external memory 406.

[0063] Reference now Figure 5 , a diagram illustrating an example of a memory structure is depicted in accordance with an illustrative embodiment. The memory structure 500 includes a virtual memory area structure (VM_AREA_STRUC) 502, a virtual external memory area structure (EXMEM_AREA_STRUC) 504, and an external memory device data structure 506. The virtual memory area structure 502, the virtual external memory area structure 504, and the external memory device data structure 506 are implemented in a virtual memory 508, a virtual external memory 510, and an external memory device 512, respectively. The virtual memory 508, the virtual external memory 510, and the external memory device 512 may be, for example, Figure 4 The virtual memory 404, the virtual external memory 406 and the external memory device 408.

[0064] The operating system kernel 514 generates a virtual memory region structure 502 for the virtual memory 508. It should be noted that in this example, the VM_EXMEM_FLAG 518 is set to yes. Because the VM_EXMEM_FLAG 518 is set to yes, the external memory manager 516 generates a virtual external memory region structure 504 for the virtual external memory 510. The virtual external memory region structure 504 includes information about the location of the external memory device data structure 506 in the external memory device 512 for storing data to be shared between containers.

[0065] Reference now Figure 6 , depicts a diagram showing an example of a workflow according to an illustrative embodiment. Workflow 600 may be implemented in a container data sharing architecture such as, for example, Figure 2 The workflow 600 includes a container file 602, a container 604, an external memory manager 606, an operating system kernel 608, a virtual memory 610, an external memory data field 612, a virtual external memory 614, an external memory utilizer 616, a container extension virtualization layer 618, a cross-system extension service 620, and a physical external memory device 622.

[0066] The container file 602 may be, for example, Figure 3 602 specifies, for example, an external memory device type and a memory space size. The container 604 uses the container file 602 to call the plug-in container external memory API to trigger the external memory manager 606 to perform a set of actions. The set of actions may include, for example, the external memory manager 606 sets the virtual memory flag to yes, generates an external memory data field 612 generated by the operating system kernel 608 in the virtual memory 610, and notifies the container extension virtualization layer 618 of the data to be shared, which is stored in the data structure of the physical external memory device 622. The container extension virtualization layer 618 virtualizes the data to be shared stored in the data structure of the physical external memory device 622 to the virtual external memory 614 for container data sharing as requested by the upper layer service application. The set of actions may also include the external memory manager 606 instructing the external memory utilizer 616 to generate a new external memory driver corresponding to the service request being processed by the container 604 in the cross-system extension service 620.

[0067] External memory utilizer 616 uses an external memory driver (eg Figure 2The external memory driver 234 in the cross-system extension service 620 is connected to the physical external memory device 622 via the cross-system extension service 620. When connected to the physical external memory device 622, the external memory driver of the cross-system extension service 620 selects a corresponding code segment in the library of the external memory driver according to the type of the physical external memory device 622 (e.g., coupling facility), and connects to the physical external memory device 622 to obtain data to be shared, which is stored in a data structure of the physical external memory device 622.

[0068] Reference now Figure 7 , a diagram depicting an example of a shared queue data sharing process according to an illustrative embodiment. The shared queue data sharing process 700 may be implemented in a container data sharing architecture (e.g. Figure 2 The container data sharing architecture 201 is implemented in the container data sharing architecture 201).

[0069] In this example, the shared queue data sharing process 700 includes operating system LPAR 1 702 and operating system LPAR 2 704. However, it should be noted that the shared queue data sharing process 700 is intended only as an example and not as a limitation of the illustrative embodiments. In other words, the shared queue data sharing process 700 may include any number of operating system LPARs.

[0070] Operating system LPAR 1 702 includes container extension LPAR 1 706. Container extension LPAR 1 706 is included in the container extension virtual container server address space, e.g. Figure 2 Container extension virtual container server address space 204. In addition, container extension LPAR 1 706 corresponds to a container (e.g. Figure 2 The external memory manager 708 stores the data generated by the container when processing the service request in the shared data queue 710 of the external memory data field 712. In addition, the external memory manager 708 copies the data contained in the shared data queue 710 of the external memory data field 712 to the shared data queue 714 of the virtual external memory 716. In addition, the external memory manager 708 directs the external memory utilizer 718 to send the data generated by the container when processing the service request contained in the shared data queue 714 of the virtual external memory 716 to the shared queue 720 of the physical external memory device 722 via the dedicated hardware link 724 for container data sharing.

[0071] Operating system LPAR 2 704 includes container extension LPAR 2 726. Container extension LPAR 2 726 is also included in the container extension virtual container server address space and corresponds to another container, such as Figure 2 218 in the container 218. In the event of a failure of the container corresponding to the container extension LPAR 1 706, the external memory manager 728 directs the external memory exploiter 730 to retrieve data from the shared queue 720 of the physical external memory device 722 generated by the failed container when processing the service request to continue processing the service request of the failed container for high-speed container failure recovery. The external memory exploiter 730 retrieves the data via a dedicated hardware link 732 and places the data retrieved from the shared queue 720 of the physical external memory device 722 in the shared data queue 734 of the virtual external memory 736 so that the service request can be processed by the container that takes over the failed container.

[0072] Reference now Figure 8 , a flowchart of a process for implementing container data sharing is shown according to an illustrative embodiment. Figure 8 The process shown can be performed on a computer such as Figure 1 101), for example, Figure 8 The process shown can be found in Figure 1 The container data sharing code 200 is implemented in the container data sharing code 200.

[0073] The process begins with the computer adding a container external memory API to an operating system container engine, so that a container of a container cluster running on the computer can call the container external memory API to perform a set of operations on data stored on a data structure of a physical external memory device according to a service request being processed by the container (step 802). In addition, the computer adds an external memory manager to a kernel of an operating system of the computer, so that the external memory manager can generate a dedicated external memory data field in a virtual memory of the computer, and copy the data contained in the dedicated external memory data field to the virtual external memory of the computer (step 804).

[0074] In addition, the computer adds an external memory utilization device under the container extension virtualization layer of the computer, so that the external memory utilization device can be connected to the cross-system extension service of the operating system to transfer data from the virtual external memory to the physical external memory device via a dedicated hardware link (step 806). The cross-system extension service includes an external memory device driver to operate the physical external memory device. The container extension virtualization layer virtualizes the shared container data stored on the physical external memory device to the virtual external memory as directed by the external memory manager. In addition, the computer uses the external memory utilization device to enable the container to use the physical external memory device to realize data sharing and high availability between containers in the container cluster (step 808). Thereafter, the process terminates.

[0075] Reference now Fig. 9 , a flow chart of a process for high-speed container failure recovery using physical external memory devices is shown according to an illustrative embodiment. Fig. 9 The process shown can be performed on a computer such as Figure 1 For example, Fig. 9 The process shown in Figure 1 The container data sharing code 200 is implemented in the container data sharing code 200.

[0076] The process begins with the computer receiving a service request from a client device via a network to perform a service corresponding to a service application (step 902). In response to receiving the service request, the computer starts a container in a container cluster on the computer to process the service request (step 904). In addition, the computer registers a data structure in a physical external memory device to store data generated by the container corresponding to the service request (step 906). In addition, the computer uses an external memory manager of an operating system on the computer to store the service request on the physical external memory device (step 908).

[0077] When the container processes the service request, the computer uses the external memory manager to retrieve the data generated by the container corresponding to the service request (step 910). When the container processes the service request, the computer uses the external memory utilizer on the computer to store the data generated by the container corresponding to the service request in the data structure of the physical external memory device via a dedicated hardware link (step 912).

[0078] The computer uses the external memory manager to detect a failure of the container that processes the service request (step 914). In response to detecting the failure of the container, the computer uses the external memory manager to start another container in the container cluster to process the service request (step 916). It should be noted that the other container can be located on a different computer than the failed container or on the same computer.

[0079] In addition, the other containers access the service requests and data generated by the failed container stored on the data structure of the physical external memory device (step 918). The other containers load the service requests and data generated by the failed container from the data structure of the physical external memory device via a dedicated hardware link for high-speed container failure recovery (step 920). Thereafter, the process terminates.

[0080] Therefore, the illustrative embodiments of the present invention provide a computer-implemented method, computer system, and computer program product for enabling containers running on an operating system with container extensions to utilize physical external memory devices via dedicated hardware links for container data sharing and high-speed container fault recovery. A description of various embodiments of the present invention has been given for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein are selected to best explain the principles of the embodiments, practical applications, or technical improvements existing on the market, or to enable other persons of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A computer-implemented method for container data sharing, the computer-implemented method comprising: In response to detecting a failure of a first container processing a service request, starting a second container in a container process to process the service request; accessing the service request and data generated by the failed first container stored on a physical external memory device; as well as The service request and the data generated by the failed first container are loaded from the physical external memory device onto the second container via a dedicated hardware link for high-speed container failure recovery.

2. The computer-implemented method of claim 1 , further comprising: receiving the service request from the client device via the network to execute the service corresponding to the service application; Starting the first container of the container cluster to process the service request; as well as A data structure is registered in the physical external memory device to store data generated by the first container.

3. The computer-implemented method according to any one of the preceding claims, further comprising: storing the service request on the physical external memory device; as well as When the first container processes the service request, data generated by the first container and corresponding to the service request is retrieved.

4. The computer-implemented method according to any one of the preceding claims, further comprising: When the first container processes the service request, data generated by the first container is stored in the physical external memory device via the dedicated hardware link.

5. The computer-implemented method of any preceding claim, further comprising: Adding a container external memory application programming interface API to an operating system container engine, so that the first container of the container cluster can call the container external memory API to perform a set of operations on the data stored on the physical external memory device according to the service request processed by the first container; adding an external memory manager to the kernel of the operating system so that the external memory manager can generate a dedicated external memory data field in the virtual memory and copy data contained in the dedicated external memory data field to the virtual external memory; as well as An external memory utilizer is added under the container extension virtualization layer, so that the external memory utilizer can be connected with the cross-system extension service of the operating system to transfer the data from the virtual external memory to the physical external memory device via the dedicated hardware link.

6. The computer-implemented method of claim 5, wherein: The cross-system extension service includes an external memory device driver to operate the physical external memory device.

7. The computer-implemented method of claim 5, wherein: The container extension virtualization layer virtualizes the data stored in the physical external memory device to the virtual external memory according to the instruction of the external memory manager.

8. The computer-implemented method of claim 5, further comprising: Using the external memory utilizer, the first container is enabled to use the physical external memory device to achieve data sharing with the second container in the container cluster.

9. A computer system for container data sharing, the computer system comprising: Communication structure; a storage device coupled to the communications structure, wherein the storage device stores program instructions; and a set of processors coupled to the communication structure, wherein the set of processors execute the program instructions to: In response to detecting a failure of a first container processing a service request, starting a second container in a container cluster to process the service request; accessing the service request and data generated by the failed first container stored on a physical external memory device; and The service request and the data generated by the failed first container are loaded from the physical external memory device onto the second container via a dedicated hardware link for high-speed container failure recovery.

10. The computer system according to claim 9, wherein: The set of processors further executes the program instructions to: receiving the service request from the client device via the network to execute the service corresponding to the service application; Starting the first container of the container cluster to process the service request; as well as A data structure is registered in the physical external memory device to store data generated by the first container.

11. A computer system according to any one of the preceding claims 9 to 10, wherein: The set of processors further executes the program instructions to: storing the service request on the physical external memory device; and When the first container processes the service request, data generated by the first container and corresponding to the service request is retrieved.

12. A computer system according to any one of the preceding claims 9 to 11, wherein: The set of processors further executes the program instructions to: When the first container processes the service request, data generated by the first container is stored in the physical external memory device via the dedicated hardware link.

13. A computer system according to any one of the preceding claims 9 to 12, wherein: The set of processors further executes the program instructions to: Adding a container external memory application programming interface API to an operating system container engine, so that the first container of the container cluster can call the container external memory API to perform a set of operations on the data stored on the physical external memory device according to the service request processed by the first container; adding an external memory manager to the kernel of the operating system so that the external memory manager can generate a dedicated external memory data field in the virtual memory and copy data contained in the dedicated external memory data field to the virtual external memory; as well as An external memory utilizer is added under the container extension virtualization layer, so that the external memory utilizer can be connected with the cross-system extension service of the operating system to transfer the data from the virtual external memory to the physical external memory device via the dedicated hardware link.

14. A computer program product for container data sharing, the computer program product comprising a computer readable storage medium having program instructions embodied therewith, the program instructions being executable by a group of processors to cause the group of processors to perform the following method: In response to detecting a failure of a first container processing a service request, starting a second container in a container cluster to process the service request; accessing the service request and data generated by the failed first container stored on a physical external memory device; as well as The service request and the data generated by the failed first container are loaded from the physical external memory device onto the second container via a dedicated hardware link for high-speed container failure recovery.

15. The computer program product of claim 14, further comprising: receiving the service request from the client device via the network to execute the service corresponding to the service application; Starting the first container of the container cluster to process the service request; as well as A data structure is registered in the physical external memory device to store data generated by the first container.

16. The computer program product according to any one of claims 14 to 15, further comprising: storing the service request on the physical external memory device; as well as When the first container processes the service request, data generated by the first container and corresponding to the service request is retrieved.

17. The computer program product according to any one of claims 14 to 16, further comprising: When the first container processes the service request, data generated by the first container is stored in the physical external memory device via the dedicated hardware link.

18. The computer program product according to any one of claims 14 to 17, further comprising: Adding a container external memory application programming interface API to an operating system container engine, so that the first container of the container cluster can call the container external memory API to perform a set of operations on the data stored on the physical external memory device according to the service request processed by the first container; adding an external memory manager to the kernel of the operating system so that the external memory manager can generate a dedicated external memory data field in the virtual memory and copy data contained in the dedicated external memory data field to the virtual external memory; as well as An external memory utilizer is added under the container extension virtualization layer, so that the external memory utilizer can be connected with the cross-system extension service of the operating system to transfer the data from the virtual external memory to the physical external memory device via the dedicated hardware link.

19. The computer program product of claim 18, wherein: The cross-system extension service includes an external memory device driver to operate the physical external memory device.

20. The computer program product of claim 18, wherein: The container extension virtualization layer virtualizes the data stored in the physical external memory device to the virtual external memory as directed by the external memory manager.

Images