Polymorphism and type casting in storage volume connections

Aspects of the disclosure provide for polymorphism and type casting in storage volume connections. A method of the disclosure includes receiving an identifier of a persistent volume (PV) created on a storage device and list of polymorphic connection types supported by the PV, creating a PV record for the PV at the container manager, responsive to receiving a query of the PV record from a container host, performing, for a connection from the container host to the storage device, type casting to select a connection type from the list of polymorphic connection types, and returning the identifier of the PV and connection information to cause the container host to establish the connection to the storage device via the selected connection type.

TECHNICAL FIELD

The implementations of the disclosure relate generally to computing systems and, more specifically, to methods and systems for polymorphism and type casting in storage volume connections.

BACKGROUND

Container deployment faces multiple challenges in a hybrid cloud environment where baremetal and virtualized container hosts exist. This is especially true when connecting containers to backend storage systems. On virtualized container host, containers can run inside a virtual machine (VM). In this case block storage is presented to the VM and containers by a hypervisor that masks detailed storage connection information. On the other hand, when containers are running on remote baremetal container hosts, the containers have to connect to the same storage asset through a transport that the container host can initiate. In yet another case, the containers may run on a container host where the physical storage is collocated on the container host. In this case, the containers can use the local storage without having to initiate any remote access protocols to connect.

DETAILED DESCRIPTION

Aspects of the disclosure provide for systems and methods for polymorphism and type casting in storage volume connections. Container deployment systems face multiple challenges in a hybrid cloud environment where baremetal and virtualized container hosts exist. A container in a container deployment system may refer to an allocation, portioning, and assignment of host (compute) resources, such as central processing unit (CPU) shares, network input/output (I/O), bandwidth, block I/O, and memory, in a way that these protected resources are isolated (or “contained”) so that that specific running services (processes) and namespaces may solely utilize them without interfering with the rest of the system.

The challenges faced by container deployment systems in a hybrid cloud environment are especially apparent when connecting containers to backend storage systems (storage devices). On virtualized container hosts, containers can run inside a virtual machine (VM). In this case, block storage is presented to the VM and containers by a hypervisor that masks detailed storage connection information. On the other hand, when containers are running on remote baremetal container hosts, the containers have to connect to the same storage asset through a transport that the container host can initiate. In yet another case, the containers may run on a container host where the physical storage is collocated on the container host. In this case, the containers can use the local storage without having to initiate any remote access protocols to connect. These varied connection options corresponding to deployed containers can make connecting the containers to the backend storage system a complex process.

Implementations of the disclosure introduce polymorphism and type casting for storage volume connections. In contrast to conventional system's utilization of singleton and concrete types of storage connection configurations, a polymorphic connection type is provided so that access to the storage device can be determined on-the-fly (e.g., at runtime) by the container host. Examples of the polymorphic connection types may include, but are not limited to, hypervisor initiated type, remote protocol access type, and local storage access type. Polymorphism, in programming languages and type theory, is the provision of a single interface to entities of different types. In other words, subclasses of a class can define their own unique behaviors and yet share some of the same functionality of the parent class.

A type casting mechanism is attached to the polymorphic connection type. Type casting refers to the act or result of changing an entity of one data type into another. Each time a container host is to resolve the connection type to the storage device, the container host passes its node information to a container manager that determines the appropriate connection information from the polymorphic connection types and provides this connection information to the container host. The container host then utilizes this connection information to establish a connection to the storage device in order to access storage.

Utilization of the polymorphism and type casting for storage volume connections in container deployment systems can allow for automated implementation of varied connection protocols in a container deployment system, without limiting the storage connection configuration options of the container host. This results in an improved connection process to backend storage system, improved connection options available in the container deployment system, and faster and more efficient performance of the overall container deployment system.

FIG. 1is a block diagram of an example of a container deployment system100according to some implementations of the disclosure. “Container deployment system” as used herein may be and/or include one or more computing devices, where each computing device may comprise one or more processors, one or more memory devices, and one or more input/output (I/O) interfaces.

As illustrated inFIG. 1, container deployment system100may include one or more container hosts.110,120,130, a container manager140, and a storage device150. As illustrated inFIG. 1, container hosts110-130, container manager140, and storage device150may be interconnected via a network105. Network105can include a private network (e.g., a local area network (LAN)), a wide area network (WAN), intranet, etc.), a public network (e.g., the Internet), etc.

Each of container hosts110-130and container manager140may include processors (e.g., central processing units (CPUs)) communicatively coupled to memory devices. Local connections within container hosts110-130and container manager140, including connections between processors and memory devices, may be provided by one or more local buses (not shown) of a suitable architecture.

“Processor” or “processing device” as used herein may be and/or include a device capable of executing instructions encoding arithmetic, logical, or I/O operations. In one illustrative example, a processor may follow a Von Neumann architectural model and may comprise an arithmetic logic unit (ALU), a control unit, and a plurality of registers. In a further aspect, a processor may be a single core processor which is typically capable of executing one instruction at a time (or process a single pipeline of instructions), or a multi-core processor which may simultaneously execute multiple instructions. According to another aspect of the disclosure, a processor may be implemented as a single integrated circuit, two or more integrated circuits, or may be a component of a multi-chip module (e.g., in which individual microprocessor dies are included in a single integrated circuit package and hence share a single socket). A processor may also be a central processing unit (CPU) in some implementations.

“Memory device” herein may be and/or include a volatile or non-volatile memory device, such as RAM (random-access memory), ROM (read-only memory), EEPROM (electrically erasable programmable read-only memory), or any other device capable of storing data.

“I/O device” herein may be and/or include a device capable of providing an interface between a processor and an external device capable of inputting and/or outputting binary data.

“Network interface controller” (NIC) herein may be and/or include a computer hardware component that connects a computer to a computer network. An NIC may include electronic circuitry required to communicate with other networked devices using specific physical layer and data link layer standards.

As illustrated inFIG. 1, container hosts110-130may be implemented in a variety of different environments. Each of container hosts110-130is responsible for deploying containers115,125,135in container deployment system100. A container115,125,135is an allocation, portioning, and assignment of host (compute) resources, such as CPU shares, network I/O, bandwidth, block I/O, and memory (RAM), in a way that these protected resources are isolated (or “contained”) so that that specific running services (processes) and namespaces may solely utilize them without interfering with the rest of the system. The processes may be lightweight Linux hosts based on a Linux image, multiple web servers and application, a single subsystem like a database backend, to a single process such as ‘echo “hello”’ with little to no overhead. Containers115,125,135are sometimes referred to as “operating system-level virtualization” or “OS virtual environments” and they differ from hypervisor-level virtualization. The container model eliminates the hypervisor layer, redundant OS kernels, binaries, and libraries used to run workloads in a VM.

Containers115,125,135may be hosted in a variety of different environments, such as a hypervisor-based environment, a baremetal environment, or a hybrid-converged environment (having local storage access). These environments are represented, respectively, inFIG. 1as VM container host110, baremetal container host120, and hybrid-converged container host130.

VM container host110may deploy a container115within a VM112managed by a hypervisor114. Hypervisor114is a software layer150(above the hardware and below the VMs) of the container host110that executes the VM. In implementations of the disclosure, a “VM” may also be referred to as a “guest” and these terms may be used interchangeably herein. In certain implementations, hypervisor114may be a component of an operating system (OS) executed by the VM container host110. Alternatively, hypervisor114may be provided by an application running under the VM container host's110OS, or may run directly on the corresponding VM container host110without an OS beneath it. Hypervisor114may abstract the physical layer, including processors, memory, I/O devices, etc. and present this abstraction to VM112as virtual devices, including virtual processors, virtual memory, virtual I/O devices, etc. A hypervisor114may abstract the physical layer and present this abstraction to VM112to use, by providing interfaces between the underlying hardware and virtual devices of VM112.

Baremetal container host120may deploy a container125directly on the physical components (CPUs, memory, etc.) of the baremetal container host120without the use of a virtualization system. Hybrid-converged container host130may deploy a container135, either in a virtualized environment or directly on the hardware of the container host130, which is physically co-located with the storage device132it is to access.

Each of the container hosts110-130may execute a respective node manager118,128,138. The node manager118,128,138may support polymorphism and type casting in storage volume connections in accordance with one or more aspects of the disclosure, as described further below. In certain implementations, a node manager118,128,138may be implemented as a software component on the respective container host110-130. Alternatively, functions of node manager118,128,138may be performed by a hypervisor, such as hypervisor114. In certain implementations, a node manager118,128,138may be implemented as a software component of a guest OS invoked by a VM of the container host110-130. Alternatively, functions of node manager118,128,138may be performed by a VM. In some implementations, node manager118,128,138can implement one or more aspects of the disclosure as described in connection withFIGS. 2-9.

In container deployment system100, container hosts110-130may be provisioned portions of storage resources, such as storage device150or local storage132, to be consumed by the container hosts110-130. In one implementation, storage device150and/or local storage132may be a memory (e.g., random access memory), a cache, a drive (e.g., a hard drive), a flash drive, a database system, or another type of component or device capable of storing data. The storage device150and/or local storage132may also include multiple storage components (e.g., multiple drives or multiple databases) that may also span multiple computing devices (e.g., multiple server computers).

In one implementation, a container manager140, communicably coupled to container hosts110-130, is responsible for managing the container hosts110-130and the lifecycle of the containers115,125,135deployed on container host110-130. Container manager140may reside on a designated computer system. Container manager140may be responsible for provisioning new storage when added to the container deployment system100and binding the provisioned storage to compute resources, such as containers115,125,135, in the container deployment system100. In one implementation, container manger140supports polymorphism and type casting in storage volume connections, in accordance with one or more aspects of the disclosure. In some implementations, container manager140can implement one or more aspects of the disclosure as described in connection withFIGS. 2-9.

For ease of explanation, the following description discusses storage device150in terms of implementations of the disclosure. However, the description provided similarly applies to local storage device132as well.

Container manager140may include a storage manager142including a volume manager143and a type casting agent145. When a storage device150is added to container deployment system100, the storage manager142is responsible for configuring the storage device150for use by containers115,125,135in container deployment system100. The volume manager142of storage manger142may request to create persistent volumes (PVs)152on the storage device150. A PV152may refer to a portion of storage of the storage device150that has been provisioned by the storage manager142. The PV152may include a directory and data which is accessible to the containers115,125,135to which it is assigned. How the directory comes to be, the medium that backs it, and the contents of it are determined by the particular volume type (e.g., iSCSI, cephfs, nfs, glusterfs, rbd, cloud provider specific storage system such as awsElasticBlockStore, etc.) used. A PV152may have a lifecycle that is independent of the individual container(s)115,125,135that use it. Although implementations of the disclosure specifically discuss persistent volumes (PVs), other types of storage resources consumable by a container may be utilized in the polymorphism and type casting in storage volume connections described herein.

In implementations of the disclosure, when the storage device150creates the PV152, it provides an identifier of the PV152as well as a list of polymorphic connection types (polymorphic connection type data155) supported by the PV152. Examples of the polymorphic connection types may include, but are not limited to, hypervisor initiated type, remote protocol access type, and local storage access type. Polymorphism, in programming languages and type theory, is the provision of a single interface to entities of different types. In other words, subclasses of a class can define their own unique behaviors and yet share some of the same functionality of the parent class. For example, in the Java programming language, runtime polymorphism is also referred to as dynamic method dispatch and is a mechanism by which a call to an overridden method is resolved at runtime. When an overridden method is called by a reference, Java programming language determines which version of the method to execute based on the type of object it referred to. In implementations of the disclosure, each PV152is polymorphic in the sense that each PV152is associated with one or more different connection protocols represented by different classes.

The volume manager143creates PV records144for each created PV152provided by storage device150, where the PV records144specify the identifier of the PV, other configuration information of the PV152(e.g., storage capacity, etc.), and the supported polymorphic connection types of the PV152.

In implementations of the disclosure, the polymorphic connection type data155is provided so that access to the storage can be determined on the fly (e.g., at runtime) by the container host110,120130. The protocol utilized to establish a communication connection between a container host110-130and storage device150in order for the container115,125,135to consume the PV152varies depending on the type of environment of the container host (e.g., hypervisor-based, baremetal, hybrid-converged). For example, the protocol to establish a connection between a container115executing on a VM112in VM container host110is different from the protocol used to establish a connection between a container125executing on baremetal container host120, which is different from the protocol used to establish a connection between a container135executing in a local storage access environment of hybrid-converged container host130.

In one implementation, when a container host110-130seeks to consume (e.g., mount) a storage resource (such as PV152), the node manager118,128,138of the container host110-130sends a query for the PV record144including a PV identifier and node information of the container host110-130. The query is an attempt to resolve the connection type to use to connect to the storage device150. Node manager118,128,138may be aware of the PV identifier as a result of a claiming process performed by the storage manager142and node manager118,128,138. The claiming process includes binding created PVs152to requests for storage (referred to as persistent volume claims or “claims”) generated by node manager118,128,138for containers115,125,135. A claim may be a request for a specific size and access mode (e.g., read/write, read only, etc.) of storage. Storage manager143may match a node manager's118,128,138claim to provisioned PVs152and bind the PV and claim together. The node manager118,128,138is informed of the PVs152(e.g., a PV identifier is provided) that are bound to claims of the node manager118,128,138.

A type casting agent145of the storage manager142receives the PV record query from the node manager118,128,138and performs type casting to identify an appropriate connection type for the container host110-130. Type casting refers to the act or result of changing an entity of one data type into another. The type casting agent145may receive the PV identifier and node information from the query and use this information to determine the connection protocol for the container host110-130to use to connect to the storage device150. The node information may include, but is not limited to, an identity of the node (e.g., hostname, IP address, etc.), the cloud configuration (e.g., AWS, Azure, OpenStack, etc.), and machine configuration (OS distribution, kernel version, supported storage connection types, etc.).

The type casting agent145compares the node information to the list of polymorphic connection types of the PV record144corresponding to the PV identifier, and, based on this comparison, selects the connection protocol (i.e., selects one of the classes from the polymorphic connection types) that corresponds to the environment of the container host110-130as discerned from the provided node information. The type casting agent145then returns the PV152identifier and connection information for the chosen connection type to the node manager118,128,138.

In one example, the type casting agent145may determine, based on the node information, that connection protocol for the VM container host110is a hypervisor initiated protocol type. As such, the type casting agent145type casts the connection protocol for the hypervisor and returns this connection information to the node manager118. In one implementation, the connection information for the hypervisor-initiated protocol type includes a device ID of the storage device150. The hypervisor114at the VM container host110can then utilize the device ID to connect to the storage device150.

In another example, the type casting agent145may determine, based on the node information, that connection protocol for the baremetal container host120is a remote access protocol type. As such, the type casting agent145type casts the connection protocol for the baremetal device and returns this connection information to the node manager128. In one implementation, the connection information for the remote access protocol type includes a name of the protocol (e.g., iSCSI, NFS, etc.) to use to connect to the storage device150. The baremetal container host120can then determine whether it has the capability to connect to the storage device150using the identified protocol and, if so, utilize the protocol to connect to the storage device150.

In a further example, the type casting agent145may determine, based on the node information, that connection protocol for the hybrid-converged container host130is a local storage access protocol type. As such, the type casting agent145type casts the connection protocol for the hybrid-converged container host130and returns this connection information to the node manager138. In one implementation, the connection information for the local storage access protocol type includes a location (e.g., host name or IP address) of the storage device132. The hybrid-converged container host130can then utilize the location information to determine that the location information matches its own location information, and then use the device path in the connection information to connect to the storage device132.

Once the connection information is received, the node manager118,128,138can then cause a connection to the storage device150to be initiated using the connection protocol that is based on the received connection information. Once the connection is established, the storage device150responds to the container host110-130and provides access to the PV152.

In some implementations, the polymorphic connection type may be further extended and optimized to type cast additional types of connection protocols based on features beyond the environment of the container host110-130. For example, the polymorphic connection types may further include secure connection protocols, such as encrypted iSCSI, that can be used when the type casting conditions indicate that the container host110-130is sensitive to data security issues (e.g., demilitarized zones (DMZ) or trusted network). In another example, the polymorphic connection types may include high-performance connection protocols, such as iSER, that can be used when the type casting conditions indicate that the container host110-130is performance sensitive. In the implementations using the extended polymorphic connection types, the container manager140may examine, in addition to the environment of the container host1101-30, the particular type of compute job that is being requests (e.g., secure or high-performance). Additional extensions to the polymorphic connection types may be implemented beyond security and performance that recognize other factors that impact the container deployment system100.

FIG. 2illustrates a flow of operations200, using an example Kubernetes environment, for polymorphism and type casting for storage volume connections according to an implementation of the disclosure. In some implementations, process200may be performed by a container host201, a container manager202, and a storage device203. Container host may be any of VM container host110, baremetal container host120, or hybrid-converged container host130, as described with respect toFIG. 1. Container manger202may be the same as container manager140, as described with respect toFIG. 1. Storage device203may be the same as storage device150or local storage132, as described with respect toFIG. 1.

As shown inFIG. 2, process200begins at210where the container manager202requests to create a PV and sends this request to the storage device203. Then, at220, the storage device returns a PV and a list of polymorphic connection types to the container manager202. In one implementation, the polymorphic connection types may include, but are not limited to, hypervisor-initiated type, remote protocol access type, and local storage access type. In some implementations, the polymorphic connection types may be further extended to include secure and/or high-performance protocols as well.

At230, the container manager202creates one or more PC records in response to receiving the PV and the list of polymorphic connection types. At240, the compute node201queries the PV record of the container manager202using the PV name and node information of the container host201. At250, the container manager202, in response to the query from the container host201, performs connection type casting by examining the node information and choosing an appropriate connection type.

Subsequently, at260, the container manager202returns the PV and the connection information for the chosen connection type to the container host201. The, at270, the container host201initiates the connection to the storage device203based on the received connection information. Lastly, at280, the storage device203responds to the initiator (e.g., the container host201) of the connection and provides storage access.

FIG. 3depicts a block diagram of a computer system that is a container host300operating in accordance with one or more aspects of the disclosure. Container host300may be the same or similar to container host1110,120,130ofFIG. 1and may include one or more processing devices301and one or more memory devices350. In the example shown, container host300may include components and modules for polymorphism and type casting in storage volume connections.

The container host300may include a memory350that can store one or more a query355. The memory350may be and/or include a volatile or non-volatile memory device, such as RAM (random-access memory), ROM (read-only memory), EEPROM (electrically erasable programmable read-only memory), or any other device capable of storing data.

The container host300may include a processing device301that implements polymorphism and type cast for storage volume connections according to implementations of the disclosure. The container host300may be communicably coupled to a container manager360and a storage device370via a network or other connection.

The processing device301may include a query transmitter310, an information receiver320, and a connection initiator330. The query transmitter310may transmit, to a container manager360, a query355for a PV record maintained by the container manager360. The query355may include a name352of the PV and node information354of the container host300.

The information receiver may receive, from the container manager360, an identifier of the PV325and connection information327. The connection information327is specific to a connection type, where the connection type is type casted by the container manager360, using the node information354, from a plurality of polymorphic connection types supported by the PV. The connection initiator330may establish, using the connection information327, a connection to the storage device370via the connection type.

FIG. 4depicts a block diagram of a computer system400operating in accordance with one or more aspects of the disclosure. Computer system400may be the same or similar to container manager140ofFIG. 1and may include one or more processing devices401and one or more memory devices450. In the example shown, computer system400may include components and modules for polymorphism and type casting in storage volume connections.

The computer system400may include a memory450that can store one or more PV records455. The PV record455may correspond to PVs465created on a storage device460communicably coupled to the computer system400via a network405or other connection. The PV record455includes a PV identifier452and a list of polymorphic connection types454supported by the PV465corresponding to the PV record455. The memory450may be and/or include a volatile or non-volatile memory device, such as RAM (random-access memory), ROM (read-only memory), EEPROM (electrically erasable programmable read-only memory), or any other device capable of storing data.

The computer system400may include a processing device401that executes a container manager402. Container manager402may be the same as container manager140describes with respect toFIG. 1. The container manager402may implement polymorphism and type casting in storage volume connections. The container manager402may include a query receiver410, a type casting agent420, connection information430, and an information transmitter440.

The query receiver410may receive a query for one of the PV records455from a container host470communicably coupled to the computer system400via a network405or other connection. The type casting agent420may perform type casting associated with a connection from the container host470to the storage device460. Performing the type casting at the type casting agent420may include a connection type selector425of the type casting agent420selecting a connection type from the list of polymorphic connection types454in view of node information of the container host475comprised in the query.

The information transmitter440may transmit, to the container host470in response to the query, the identifier of the PV452and connection information430to cause the container host470to establish the connection to the storage device460via the selected connection type. The connection information430is different for each of the polymorphic connection types.

FIG. 5is a flow diagram illustrating a method500for polymorphism and type casting in storage volume connections as applied by a container manager, according to an implementation of the disclosure. Method500can be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), firmware, or a combination thereof. In one implementation, method500is performed by a processing device (e.g. a processing device1002ofFIG. 10) as described in connection withFIG. 1. In some implementations, method500can be performed by container manager140described with respect toFIG. 1.

Referring toFIG. 5, method500begins at block510where the processing device performs one or more operations to receive an identifier of a PV created on a storage device and list of polymorphic connection types supported by the PV. At block520, the processing device creates a PV record for the PV at the container manager. At block530, the processing device performs, responsive to receiving a query of the PV record from a container host, type casting associated with a connection from the container host to the storage device. In one implementation, performing the type casting comprises selecting a connection type from the list of polymorphic connection types in view of node information of the container host comprised in the query.

Lastly, at block540, the processing device returns, to the container host in response to the query, the identifier of the PV and connection information to cause the container host to establish the connection to the storage device via the selected connection type. In one implementation, the connection information is different for each of the polymorphic connection types.

FIG. 6is a flow diagram illustrating a method600for polymorphism and type casting in storage volume connections as applied by a container host, according to an implementation of the disclosure. Method600can be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), firmware, or a combination thereof. In one implementation, method600is performed by a processing device (e.g. a processing device1002ofFIG. 10) as described in connection withFIG. 1. In some implementations, method600can be performed by a source hypervisor running on the source computer system. In some implementations, method600can be performed by any of container hosts1101-30described with respect toFIG. 1.

Referring toFIG. 6, method600begins at block610where the processing device performs one or more operations to transmit, to a container manager, a query for a persistent volume (PV) record maintained by the container manager, the query comprising a name of the PV and node information of a container host including the processing device.

At block620, the processing device receives, from the container manager, an identifier of the PV and connection information. In one implementation, the connection information is specific to a connection type. In addition, the connection type is type casted by the container manager, using the node information, from a plurality of polymorphic connection types supported by the PV. Lastly, at block630, the processing device establishes, using the connection information, a connection to the storage device via the connection type.

FIG. 7is a flow diagram illustrating another method700for polymorphism and type casting in storage volume connections as applied by a container manager, according to an implementation of the disclosure. Method700can be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), firmware, or a combination thereof. In one implementation, method700is performed by a processing device (e.g. a processing device1002ofFIG. 10) as described in connection withFIG. 1. In some implementations, method700can be performed by container manager140described with respect toFIG. 1.

Method700can begin at block710where the processing device executes a container manager to manage one or more containers on one or more container hosts. At block720, the processing device performs, responsive to receiving a query for a PV record from a container host, perform type casting associated with a connection from the container host to the storage device. In one implementation, performing the type casting includes selecting a connection type from the list of polymorphic connection types in view of node information of the container host comprised in the query. Furthermore, the PV record may correspond to a PV created on a storage device, wherein the PV record comprises a PV identifier and a list of polymorphic connection types supported by the PV corresponding to the PV record.

Lastly, at block730, the processing device transmits, to the container host in response to the query, the identifier of the PV and connection information to cause the container host to establish the connection to the storage device via the selected connection type. In one implementation, the connection information is different for each of the polymorphic connection types.

FIG. 8is a flow diagram illustrating a method800for polymorphism and type casting in storage volume connections with an optimization as applied by a container manager, according to an implementation of the disclosure. Method800can be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), firmware, or a combination thereof. In one implementation, method800is performed by a processing device (e.g. a processing device1002ofFIG. 10) as described in connection withFIG. 1. In some implementations, method800can be performed by container manager140described with respect toFIG. 1.

Method800begins at block810where the processing device performs one or more operations to execute a container manager to manage one or more containers on one or more container hosts. Then, at block820, the processing device receives a query for a PV record from a container host. In one implementation, the query includes a PV name and node information of the container host, and a job type of the container host.

Subsequently, at block830, the processing device performs, responsive to receiving the query, type casting associated with a connection from the container host to the storage device. In one implementation, performing the type casting comprises selecting a connection type from a list of polymorphic connection types in the PV record in view of the node information of the container host and the job type.

Lastly, at block840, the processing device transmits, to the container host in response to the query, an identifier of the PV from the PV record and connection information to cause the container host to establish the connection to the storage device via the selected connection type. In one implementation, the connection information is different for each of the polymorphic connection types and job types.

FIG. 9is a flow diagram illustrating a method900for polymorphism and type casting in storage volume connections with an optimization as applied by a container host, according to an implementation of the disclosure. Method900can be performed by processing logic that may comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (such as instructions run on a processing device), firmware, or a combination thereof. In one implementation, method900is performed by a processing device (e.g. a processing device1002ofFIG. 10) as described in connection withFIG. 1. In some implementations, method900can be performed by any of container hosts110-130described with respect toFIG. 1.

Method900begins at block910where the processing device transmits, to a container manager, a query for a PV record maintained by the container manager. In one implementation, the query comprising a PV name and node information of the container host, and a job type of the container host.

At block920, the processing device receives, from the container manager, an identifier of the PV and connection information. In one implementation, the connection information is specific to a connection type and the job type. The connection type may be type casted by the container manager, using the node information and the job type, from a plurality of polymorphic connection types supported by the PV. Lastly, at block930, the processing device establishes, using the connection information, a connection to the storage device via the connection type.

The computer system1000includes a processing device1002(e.g., processor, CPU, etc.), a main memory1004(e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM) (such as synchronous DRAM (SDRAM) or DRAM (RDRAM), etc.), a static memory1006(e.g., flash memory, static random access memory (SRAM), etc.), and a data storage device1018, which communicate with each other via a bus1008.

The computer system1000may further include a network interface device1022communicably coupled to a network1064. The computer system1000also may include a video display unit1010(e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)), an alphanumeric input device1012(e.g., a keyboard), a cursor control device1014(e.g., a mouse), and a signal generation device1020(e.g., a speaker).

The data storage device1018may include a machine-accessible storage medium1024on which is stored software1026embodying any one or more of the methodologies or functions described herein. The software1026may also reside, completely or at least partially, within the main memory1004as instructions1026and/or within the processing device1002as processing logic1026during execution thereof by the computer system1000; the main memory1004and the processing device1002also constituting machine-accessible storage media.

The machine-readable storage medium1024may also be used to store instructions1026to implement a type casting agent1090and/or a software library containing methods that call the above applications. Type casting agent1090can implement polymorphism and type casting in storage volume connections by performing one or more operations described in connection withFIGS. 1-9above. While the machine-accessible storage medium1024is shown in an example implementation to be a single medium, the term “machine-accessible storage medium” should be taken to include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) that store the one or more sets of instructions. The term “machine-accessible storage medium” shall also be taken to include any medium that is capable of storing, encoding or carrying a set of instruction for execution by the machine and that cause the machine to perform any one or more of the methodologies of the disclosure. The term “machine-accessible storage medium” shall accordingly be taken to include, but not be limited to, solid-state memories, and optical and magnetic media.

Other computer system designs and configurations may also be suitable to implement the system and methods described herein. The following examples illustrate various implementations in accordance with one or more aspects of the disclosure.

The following examples pertain to further embodiments. Example 1 is a method for polymorphism and type casting in storage volume connections comprising receiving, by a processing device executing a container manager, an identifier of a persistent volume (PV) created on a storage device and list of polymorphic connection types supported by the PV, creating a PV record for the PV at the container manager, and responsive to receiving a query of the PV record from a container host, performing type casting associated with a connection from the container host to the storage device, wherein performing the type casting comprises selecting a connection type from the list of polymorphic connection types in view of node information of the container host comprised in the query. Further to Example 1, the method additionally comprises returning, to the container host in response to the query, the identifier of the PV and connection information to cause the container host to establish the connection to the storage device via the selected connection type, wherein the connection information is different for each of the polymorphic connection types.

In Example 2, the subject matter of Example 1 can optionally include wherein the PV record comprises at least one of the identifier of the PV, a storage capacity of the PV, the polymorphic connection types supported by the PV, or access mode of the PV. In Example 3, the subject matter of any one of Examples 1-2 can optionally include wherein the node information comprises at least one of a node identifier, cloud configuration information, and machine configuration information. In Example 4, the subject matter of any one of Examples 1-3 can optionally include wherein the connection types comprise at least one of a hypervisor type, a remote access protocol type, or a local volume type.

In Example 5, the subject matter of any one of Examples 1-4 can optionally include wherein the hypervisor type indicates a container of the container host is implemented on a virtual machine managed by a hypervisor of the container host. In Example 6, the subject matter of any one of Examples 1-5 can optionally include wherein the connection information comprises a device identifier (ID) of the storage device, the device ID used by the hypervisor to establish the connection to the storage device.

In Example 7, the subject matter of any one of Examples 1-6 can optionally include wherein the remote access protocol type indicates a container of the container host is implemented on baremetal components of the container host. In Example 8, the subject matter of any one of Examples 1-7 can optionally include wherein the connection information comprises an identification of a connection protocol for the container host to use to establish the connection to the storage device. In Example 9, the subject matter of any one of Examples 1-8 can optionally include wherein the local volume type indicates a container of the container host is co-located with the storage device on the container host.

In Example 10, the subject matter of any one of Examples 1-9 can optionally include wherein the connection information comprises a location of the storage device, the location used to identify a device path used by the compute to establish the connection to the storage device, wherein the location comprises at least one of a host name or an Internet Protocol (IP) address of the storage device.

Example 11 is a non-transitory computer-readable medium for implementing polymorphism and type casting in storage volume connections. In Example 11, the non-transitory machine-readable medium includes instructions that, when executed by a processing device, cause the processing device to transmit, by the processing device to a container manager, a query for a persistent volume (PV) record maintained by the container manager, the query comprising a name of the PV and node information of a container host comprising the processing device. In Example 11, the processing device is further to receive, by the processing device from the container manager, an identifier of the PV and connection information, wherein the connection information is specific to a connection type, and wherein the connection type is type casted by the container manager, using the node information, from a plurality of polymorphic connection types supported by the PV, and establish, by the processing device using the connection information, a connection to the storage device via the connection type.

In Example 12, the subject matter of Example 11 can optionally include wherein the PV record comprises at least one of the identifier of the PV, a storage capacity of the PV, the polymorphic connection types supported by the PV, or access mode of the PV. In Example 13, the subject matter of Examples 11-12 can optionally include wherein the node information comprises at least one of a node identifier, cloud configuration information, and machine configuration information.

In Example 14, the subject matter of Examples 11-13 can optionally include wherein the connection types comprise at least one of a hypervisor type, a remote access protocol type, or a local volume type. In Example 15, the subject matter of Examples 11-14 can optionally include wherein the hypervisor type indicates a container of the container host is implemented on a virtual machine managed by a hypervisor of the container host, and wherein the connection information comprises a device identifier (ID) of the storage device, the device ID used by the hypervisor to establish the connection to the storage device.

In Example 16, the subject matter of Examples 11-15 can optionally include wherein the remote access protocol type indicates a container of the container host is implemented on baremetal components of the container host, and wherein the connection information comprises an identification of a connection protocol for the container host to use to establish the connection to the storage device. In Example 17, the subject matter of Examples 11-16 can optionally include wherein the local volume type indicates a container of the container host is co-located with the storage device on the container host, and wherein the connection information comprises a location of the storage device, the location used to identify a device path used by the compute to establish the connection to the storage device, wherein the location comprises at least one of a host name or an Internet Protocol (IP) address of the storage device.

Example 18 is an apparatus for implementing polymorphism and type casting in storage volume connections. In Example 18, the apparatus includes a memory to store persistent volume (PV) records corresponding to PVs created on a storage device, wherein each PV record comprises a PV identifier and a list of polymorphic connection types supported by the PV corresponding to the PV record. In Example 18, the apparatus further includes a processing device communicably coupled to the memory. Further to Example 18, the processing device can execute a container manager to manage one or more containers on one or more container hosts and responsive to receiving a query for one of the PV records from a container host, perform type casting associated with a connection from the container host to the storage device, wherein performing the type casting comprises selecting a connection type from the list of polymorphic connection types in view of node information of the container host comprised in the query. In Example 18, the processing device can further transmit, to the container host in response to the query, the identifier of the PV and connection information to cause the container host to establish the connection to the storage device via the selected connection type, wherein the connection information is different for each of the polymorphic connection types.

In Example 19, the subject matter of Example 18 can optionally include wherein the PV record comprises at least one of the identifier of the PV, a storage capacity of the PV, the polymorphic connection types supported by the PV, or access mode of the PV. In Example 20, the subject matter of Examples 18-19 can optionally include wherein the node information comprises at least one of a node identifier, cloud configuration information, and machine configuration information. In Example 21, the subject matter of Examples 18-20 can optionally include wherein the connection types comprise at least one of a hypervisor type, a remote access protocol type, or a local volume type.

In Example 22, the subject matter of Examples 18-21 can optionally include wherein the hypervisor type indicates a container of the container host is implemented on a virtual machine managed by a hypervisor of the container host, and wherein the connection information comprises a device identifier (ID) of the storage device, the device ID used by the hypervisor to establish the connection to the storage device.

In Example 23, the subject matter of Examples 18-22 can optionally include wherein the remote access protocol type indicates a container of the container host is implemented on baremetal components of the container host, and wherein the connection information comprises an identification of a connection protocol for the container host to use to establish the connection to the storage device. In Example 24, the subject matter of Examples 18-23 can optionally include wherein the local volume type indicates a container of the container host is co-located with the storage device on the container host, and wherein the connection information comprises a location of the storage device, the location used to identify a device path used by the compute to establish the connection to the storage device, wherein the location comprises at least one of a host name or an Internet Protocol (IP) address of the storage device.

Example 25 is a system for implementing polymorphism and type casting in storage volume connections. In Example 20, the system includes a memory and a processing device coupled to the memory. Further to Example 20, the processing device can execute a container manager to manage one or more containers on one or more container hosts and receive a query for a persistent volume (PV) record from a container host, the query comprising a PV name and node information of the container host, and a job type of the container host. Further to Example 25, the processing device can responsive to receiving the query, perform type casting associated with a connection from the container host to the storage device, wherein performing the type casting comprises selecting a connection type from a list of polymorphic connection types in the PV record in view of the node information of the container host and the job type, and transmit, to the container host in response to the query, an identifier of the PV from the PV record and connection information to cause the container host to establish the connection to the storage device via the selected connection type, wherein the connection information is different for each of the polymorphic connection types and job types.

In Example 26, the subject matter of Example 25 can optionally include wherein the PV record comprises at least one of the identifier of the PV, a storage capacity of the PV, the polymorphic connection types supported by the PV, or access mode of the PV. In Example 27, the subject matter of any one of Examples 25-26 can optionally include wherein the node information comprises at least one of a node identifier, cloud configuration information, and machine configuration information.

In Example 28, the subject matter of any one of Examples 25-27 can optionally include wherein the connection types comprise at least one of a hypervisor type, a remote access protocol type, or a local volume type, and wherein the job types comprise at least one of security sensitive or performance sensitive. In Example 29, the subject matter of any one of Examples 25-28 can optionally include wherein the hypervisor type indicates a container of the container host is implemented on a virtual machine managed by a hypervisor of the container host, and wherein the connection information comprises a device identifier (ID) of the storage device, the device ID used by the hypervisor to establish the connection to the storage device.

In Example 30, the subject matter of any one of Examples 25-29 can optionally include wherein the remote access protocol type indicates a container of the container host is implemented on baremetal components of the container host, and wherein the connection information comprises an identification of a connection protocol for the container host to use to establish the connection to the storage device. In Example 31, the subject matter of any one of Examples 25-30 can optionally include wherein the local volume type indicates a container of the container host is co-located with the storage device on the container host, and wherein the connection information comprises a location of the storage device, the location used to identify a device path used by the compute to establish the connection to the storage device, wherein the location comprises at least one of a host name or an Internet Protocol (IP) address of the storage device.

Example 31 is another method for polymorphism and type casting in storage volume connections comprising transmitting, by a processing device executing a container host to a container manager, a query for a persistent volume (PV) record maintained by the container manager, the query comprising a PV name and node information of the container host, and a job type of the container host. Further to Example 1, the method additionally comprises receiving, by the processing device from the container manager, an identifier of the PV and connection information, wherein the connection information is specific to a connection type and the job type, and wherein the connection type is type casted by the container manager, using the node information and the job type, from a plurality of polymorphic connection types supported by the PV, and establishing, by the processing device using the connection information, a connection to the storage device via the connection type.

In Example 32, the subject matter of Example 31 can optionally include wherein the PV record comprises at least one of the identifier of the PV, a storage capacity of the PV, the polymorphic connection types supported by the PV, or access mode of the PV. In Example 33, the subject matter of any one of Examples 31-32 can optionally include wherein the node information comprises at least one of a node identifier, cloud configuration information, and machine configuration information.

In Example 34, the subject matter of any one of Examples 31-33 can optionally include wherein the connection types comprise at least one of a hypervisor type, a remote access protocol type, or a local volume type, and wherein the job type comprises at least one of security sensitive or performance sensitive. In Example 35, the subject matter of any one of Examples 31-34 can optionally include wherein the hypervisor type indicates a container of the container host is implemented on a virtual machine managed by a hypervisor of the container host, and wherein the connection information comprises a device identifier (ID) of the storage device, the device ID used by the hypervisor to establish the connection to the storage device.

In Example 36, the subject matter of any one of Examples 31-35 can optionally include wherein the remote access protocol type indicates a container of the container host is implemented on baremetal components of the container host, and wherein the connection information comprises an identification of a connection protocol for the container host to use to establish the connection to the storage device. In Example 37, the subject matter of any one of Examples 31-36 can optionally include wherein the local volume type indicates a container of the container host is co-located with the storage device on the container host, and wherein the connection information comprises a location of the storage device, the location used to identify a device path used by the compute to establish the connection to the storage device, wherein the location comprises at least one of a host name or an Internet Protocol (IP) address of the storage device.

Example 38 is an apparatus for implementing polymorphism and type casting in storage volume connections comprising means for receiving an identifier of a persistent volume (PV) created on a storage device and list of polymorphic connection types supported by the PV, means for creating a PV record for the PV at the container manager, means for performing, responsive to receiving a query of the PV record from a container host, type casting associated with a connection from the container host to the storage device, wherein performing the type casting comprises selecting a connection type from the list of polymorphic connection types in view of node information of the container host comprised in the query, and means for returning, to the container host in response to the query, the identifier of the PV and connection information to cause the container host to establish the connection to the storage device via the selected connection type, wherein the connection information is different for each of the polymorphic connection types. In Example 39, the subject matter of Example 38 can optionally include the apparatus further configured to perform the method of any one of the Examples 1 to 37.

In the foregoing description, numerous details are set forth. It will be apparent, however, that the disclosure may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the disclosure.

The terms “first,” “second,” “third,” “fourth,” etc. as used herein are meant as labels to distinguish among different elements and may not necessarily have an ordinal meaning according to their numerical designation.