Virtualizing shared computing resources

The present disclosure relates to systems, methods, and computer-readable media for virtualizing storage resources on non-volatile memory in a way that enables virtual machines on a computing device to efficiently access computing resources across multiple partitions of multiple non-volatile memory devices. For example, systems disclosed herein facilitate establishing a binding (e.g., a physical function, such as a single root input/output virtualization (SR-IOV) or a multi-physical function (MPF)) between the virtual machine(s) and solid state drive (SSD) devices. The systems disclosed herein further involve using a virtual volume manager on an operating system of the virtual machine(s) to implement features and functionality of the virtual machine(s) in accordance with configuration data unique to the virtual machine(s).

BACKGROUND

Recent years have seen a precipitous rise in the use of computing devices (e.g., mobile devices, personal computers, server devices, cloud computing systems) to receive, store, edit, transmit, or otherwise utilize digital data. For example, it is now common for individuals and businesses to store and/or process massive quantities of data on local computing devices and/or on remote cloud computing systems. As demand for increased storage and memory capacity on computing devices increases, innovations in technology associated with storing and processing data has similarly improved and become more capable.

As cloud computing continues to grow in popularity, managing increased demands on storage capacity and processing resources has become increasingly difficult. For example, in an effort to provide additional resources at affordable prices, many systems and devices enable sharing of resources between multiple customers. Indeed, many conventional systems host virtual machines associated with different customers that enable the virtual machines to share computing resources on individual computing devices. Enabling shared access to computing resources, however, suffers from a number of problems and drawbacks.

For example, sharing computing resources may often result in a noisy neighbor problem in which a more aggressive customer or tenant interferes with usage of the computing resources by other customers or virtual machines. In addition, while many conventional systems simply reserve specific computing capacity to specific customers or tenants, this can result in limited bandwidth and other computing resources allocated to specific virtual machines, and often causes inefficient utilization of computing resources. Moreover, and as will be discussed in further detail below, conventional solutions that implement virtualization using primarily central software management tools generally involve a robust development pipeline and significant computing overhead. Indeed, conventional virtual machine management tools often involve centrally maintaining numerous hardware configurations and processing a significant number of system calls to enable virtual machines of different types to share resources and operate on common devices, which can slow operation and add significant storage and computing costs.

These and other problems exist in connection with implementing different virtual machines that share computing resources.

DETAILED DESCRIPTION

The present disclosure is generally related to virtualizing storage resources on solid state drive (SSD) devices (and other non-volatile memory systems) in a way that enables the virtual machine(s) to efficiently access computing resources across multiple SSD devices using a variety of computing applications. In particular, based on configuration data for a virtual machine, a virtual machine may be associated (hardware-bound) to a plurality of SSD devices using physical functions that causes a portion of the SSD devices (e.g., namespaces) to be virtualized to the virtual machine(s) via physical functions. In addition to binding the virtual machines and SSD devices, a virtual volume manger may be implemented on the virtual machine(s) to access data on the SSD devices in accordance with the configuration data for the virtual machine. The systems described herein provide a flexible and secure configuration that enables the virtual machines to directly access partitioned portions of the SSD devices without interfering with usage by other virtual machines.

By way of example, and as will be discussed in further detail below, this disclosure describes a virtual volume manager implemented on a virtual machine on a computing device (e.g., a server node on a cloud computing system). The systems described herein may receive configuration data for the virtual machine including instructions associated with managing computing resources (e.g., processing and/or storage resources) on a plurality of non-volatile storage devices (e.g., peripheral component interconnect express (PCIe) devices, SSD devices). The systems described herein facilitate establishing bindings between the virtual machine and a number of non-volatile storage devices. The systems described herein further facilitate implementing, on an operating system of the virtual machine (e.g., a guest operating system), the virtual volume manager being configured to access the non-volatile storage devices in accordance with the received configuration data.

The present disclosure includes a number of practical applications that provide benefits and/or solve problems associated with virtualizing computing resources to virtual machines to enable the virtual machines to share computing resources without interfering with one another. Examples of these applications and benefits are discussed in further detail below.

For example, by virtualizing computing resources in accordance with one or more embodiments described herein, the systems described herein can provide consistent computing resources while avoiding the noisy neighbor problem caused by other tenants or customers that may be sharing the same computing resources. For instance, systems described herein may bind or otherwise associate partitioned namespaces of SSD devices to multiple virtual machines using a variety of virtualization techniques. By way of example, in one or more embodiments described herein, the systems may bind the virtual machines and partitioned resources by way of single-root input/output virtualization (SR-IOV) or multi-physical function (MPF) techniques.

In addition to reducing or otherwise eliminating cross-customer interference from aggressive tenants, the systems described herein provide enhanced flexibility in implementing a variety of configurations associated with different types of virtual machines. For example, by implementing a virtual volume manager locally on a virtual machine, a greater variety of virtual machines capable of implementing different configurations is possible. To illustrate, a first virtual machine may prioritize processing performance by implementing a configuration in which computing resources across different SSD devices are concurrently used to boost bandwidth or throughput for the particular virtual machine. Meanwhile, on the same computing device, a second virtual machine may prioritize redundancy or boost failover by duplicating a storage volume or otherwise maintaining redundant data on different SSD devices. In both cases, the virtual machines can provide a single storage volume view to a client while optimizing different types of performance based on locally implemented configuration data on a virtual volume manager of the virtual machine(s). Indeed, as will be discussed in further detail herein, locally implementing configurations on respective virtual volume managers greatly enhances flexibility for any number of virtual machines.

Moreover, the systems described herein provide the above benefits while significantly reducing processing overhead and latency in performing various computing and storage functions. For example, where a conventional host system may include a hypervisor and host operating system capable of enabling various performance and/or failover benefits using complex and often expensive software solutions, these existing systems typically involve a significant number of system calls between the virtual machines and the host operating system and/or hypervisor. These system calls, in addition to the expense of hosting a robust central software solution, can cut down on available computing resources. For instance, as more virtual machines associated with different customers are loaded onto a device, an increased number of system calls to accommodate each customer can result in slower access speeds, lower throughput generally, and other limitations on computing performance for the virtual machines.

In addition to improving performance by reducing a number of system calls to a host system, distributing management of the virtual machines to locally implemented virtual volume managers and guest operating systems also reduces processing overhead in other ways. For instance, by performing hardware virtualization in accordance with one or more embodiments, a greater number of virtual machine types may be deployed without locally managing specific hardware configurations on the host system. This reduces expense of supply chain management resources, allocation resources, idle resources, and other computing expenses that occur as a result of centrally maintaining hardware configurations for a variety of virtual machines.

As illustrated in the foregoing discussion, the present disclosure utilizes a variety of terms to describe features and advantages of the systems herein. Additional detail is now provided regarding the meaning of some example terms.

For example, as used herein, a “cloud computing system” refers to a network of connected computing devices that provide various services to customer devices (e.g., client devices, network devices). For instance, as mentioned above, a distributed computing system can include a collection of physical server devices (e.g., server nodes) organized in a hierarchical structure including clusters, computing zones, virtual local area networks (VLANs), racks, fault domains, etc. The cloud computing system may refer to a private or public cloud computing system. In one or more embodiments described herein, a computing device or host device refers to a server node or any network device on a cloud computing system.

As used herein, a “virtual machine” refers to an emulation of a computer system on a server node that provides functionality of one or more applications or services on the cloud computing system. Virtual machines can provide functionality needed to execute one or more operating systems. In addition, virtual machines can make use of hypervisors on processors of server devices that support virtual replication of hardware. It will be understood that while one or more specific examples and implementations described herein relate specifically to virtual machines, features and functionality described in connection with binding or otherwise virtualizing computing resources for virtual machines may similarly refer to other types of services or cloud-based resources implemented on server nodes or other computing devices.

As used herein, “configuration data,” a “machine configuration,” or “hardware configuration” may refer to specifications or characteristics associated with operation of a virtual machine on a computing device. For example, configuration data may refer to any information or instructions that the virtual machine may implement in performing various tasks in connection with data or other computing resources maintained on a computing device. In one or more embodiments, configuration data refers to instructions associated with prioritizing specific tasks or performance specifications. For instance, configuration data may include instructions for prioritizing redundancy or failover, thus causing a virtual volume manager to maintain redundancy across multiple namespaces on multiple SSD devices. In addition, or as an alternative, configuration data may include instructions for increasing computing speed or throughput (or other computing performance specification), thus causing a virtual volume manager to concurrently use computing resources (e.g., parallel resources) across multiple SSD devices. In one or more embodiments, the configuration data includes instructions associated with virtualizing hardware on the computing device to the respective virtual machine.

As will be discussed in further detail herein, a virtual machine may be associated with one or multiple SSD devices by way of a binding between the virtual machine and the SSD devices. As used herein, a “binding” may refer to any physical or virtual function or virtualization of hardware from the perspective of a virtual machine. In one or more embodiments, the binding may refer to a physical function, which may refer to a construct or function of a system that supports a virtualization interface between a virtual machine and the SSD device(s) (or other computing resource device(s)). For instance, in one or more implementations, a physical function may refer to a peripheral component interconnect express (PCIe) function that supports a virtualization interface between the virtual machine and SSD device(s).

In addition, as will be discussed in further detail below, the physical function may refer to a variety of different virtualization types. For instance, in one or more embodiments, the physical function refers to a single root input/output virtualization (SR-IOV) in which the SSD or PCIe resource is exposed via a single interface that exposes virtual functions of the SSD device. As another example, in one or more implementations, the physical function refers to a multi-physical function including multiple functions between the virtual machine and SSD devices (e.g., non-volatile memory express (NVMe) SSDs).

Additional detail will now be provided regarding examples of various systems in relation to illustrative figures portraying example implementations. For example,FIG.1illustrates an example environment100including a cloud computing system102. The cloud computing system102may include any number of devices. For example, as shown inFIG.1, the cloud computing system102may include one or more server device(s)104having a resource management system106thereon.

In one or more embodiments, the resource management system106includes features and functionality that enables deployment of virtual machines that operate in accordance with specific configurations. For instance, the resource management system106may provide specifications for different types of virtual machines to a host system on a computing node that facilitates allocating computing resources on one or more SSD devices of the computing node. In one or more embodiments, the resource management system106includes one or more control planes for managing resources across any number of nodes on the cloud computing system102. The resource management system106may refer to localized control planes and associated management systems for controlling resources at specific datacenters and/or node clusters. Alternatively, the resource management system106may refer to a centralized resource system responsible for management of computing resources across any number of nodes of the cloud computing system102.

As shown inFIG.1, in addition to the server device(s)104, the cloud computing system102may include any number of server nodes108a-n. While not shown inFIG.1, the server nodes108a-nmay be organized within node clusters or other grouping of devices or networks. For instance, the server nodes108a-nmay be grouped by geographic location (e.g., a region of a node cluster). In one or more embodiments, the server nodes108a-nare implemented across disparate geographic locations (e.g., on different datacenters or on different server racks including one or multiple node clusters).

The server nodes108a-nmay refer to a variety of computing devices or various network devices. For example, in one or more embodiments, the server nodes108a-nrefer to server devices having compute cores implemented thereon capable of hosting virtual machines and providing various services to customers of the cloud computing system102.

As shown inFIG.1, each of the server nodes108a-nmay include one or more virtual machines110a-n. For instance, a first server node108amay include a first set of virtual machine(s)110aimplemented thereon. The set of virtual machine(s)110amay include multiple virtual machines of similar types (e.g., that provide similar services or have similar virtual machine configurations). Alternatively, the virtual machine(s)110amay include virtual machines of different types and operating in accordance with different sets of configuration data. Each of the additional virtual machines110b-nmay have similar features and functionality as the first set of virtual machine(s)110aon the first server node108a. Additional detail in connection with virtual machines operating in conjunction with different configuration data will be discussed in further detail below.

Each of the virtual machines110a-nmay include virtual volume managers112a-nimplemented thereon. The virtual volume managers112a-nmay be implemented on guest operating systems of the virtual machines110a-nconfigured to facilitate various features and functionalities of the virtual machines110a-nin accordance with sets of configuration data. As mentioned above, the configuration data may include instructions for managing and otherwise utilizing computing resources on the respective server nodes108a-n. Additional detail in connection with the virtual volume managers112a-nwill be discussed below in connection withFIGS.2-3.

As further shown, each of the server nodes108a-ninclude memory systems114a-nhaving host systems116a-nimplemented thereon. Each of the host systems116a-nmay include similar features and functionality as one another. For example, as will be discussed in further detail below, a first host system116aon the first server node108amay include a hypervisor configured to create and host virtual machines on the server node108a. As will be discussed in further detail herein, the hypervisor may facilitate creating the virtual machines and handoff or otherwise distribute at least a portion of control of the virtual machine operation to a virtual volume manager having a guest operating system implemented thereon for facilitating operation of the virtual machine in accordance with a set of configuration data.

The host system116amay additionally include an operating system (e.g., a host operating system) that facilitates basic operations and other functions of the host system116a, such as scheduling tasks, executing applications, etc. In one or more embodiments, the operating system refers to a host operating system implemented on the host system116athat operates in conjunction with guest operating systems implemented on each of the respective virtual machine(s)110a.

As further shown inFIG.1, the memory systems114a-ninclude SSD devices118a-nimplemented thereon. The SSD devices118a-nmay include similar configurations of SSD devices118a-non each of the respective memory systems114a-n. For example, a first SSD device(s)118amay include any number of non-volatile storage devices capable of maintaining data and providing access to the data to any number of the virtual machines110aon the associated server node108a. As discussed in further detail below, the SSD device(s)118amay include partitioned storage that are selectively accessible to respective virtual machines110aby way of physical functions that have been established between the virtual machines110aand respective SSD device(s)118a.

While one or more embodiments described herein relate specifically to SSD devices implemented on server nodes, it will be appreciated that other configurations of storage devices and associated computing devices may be used in accordance with one or more embodiments of the present disclosure. For example, the server nodes may refer to any computing devices capable of hosting virtual machines thereon. This may include server devices on the cloud computing system102in accordance with one or more examples described herein or, alternatively, other types of computing devices on any type of network of devices. In addition, one or more embodiments may specifically describe features related to providing selective access to data via SSD devices, other types of non-volatile devices may similarly be used in accordance with one or more embodiments described herein. Accordingly, features and functionalities described in connection with virtual machines and SSD devices on server nodes may similarly apply to other types of computing devices and other types of non-volatile memory devices.

In addition to the cloud computing system102and associated components, the environment100may include a plurality of client devices120in communication with the cloud computing system via a network122. For example, the client devices120may communicate with the server nodes108a-nvia the network118. The client devices120may refer to various types of computing devices including, by way of example, mobile devices, desktop computers, server devices, or other types of computing devices. The network122may include one or multiple networks that use one or more communication platforms or technologies for transmitting data. For example, the network122may include the Internet or other data link that enables transport of electronic data between respective client devices120and devices of the cloud computing system102.

As mentioned above, the components illustrated inFIG.1may provide features and functionality related to establishing a physical function between a virtual machine and one or more SSD devices. This may be done in a way that offloads processing from the host systems116a-nto the virtual volume managers112a-non the respective virtual machines110a-n. Additional detail in connection with an example implementation will now be discussed in connection with an example server node having a virtual machine deployed thereon.

For example,FIG.2illustrates an example server node202including a virtual machine204and a host system206. The server node202may refer to a server node of a cloud computing system102as discussed above in connection withFIG.1. Alternatively, the server node202may refer to any computing device capable of hosting a virtual machine204thereon that operates in conjunction with a host system206in accordance with one or more embodiments described herein.

As shown inFIG.2the virtual machine204includes a virtual volume manager208and a set of configuration data210. As noted above, the virtual volume manager208refers to a module on the virtual machine204that is capable of managing features and functionality of the virtual machine204, some of which may traditionally be performed by the hypervisor on the host system206. For example, in one or more embodiments described herein, the virtual volume manager208may reside in an operating system of the virtual machine204to schedule tasks, execute functions, access data on non-volatile storage devices, and otherwise perform actions of the virtual machine204in accordance with the configuration data210(e.g., instructions of the configuration data210).

As shown inFIG.2, the host system206includes a number of components including a hypervisor212, a host operating system214, and root complex216. As discussed above, the hypervisor212and host operating system214may be configured to create and deploy virtual machines on the server node202in accordance with received configuration data210. For example, in one or more embodiments described herein, the hypervisor212can create one or more virtual machines and cause the virtual machines to be configured to perform tasks in accordance with respective configurations data210. In the illustrated example, the hypervisor212may create the virtual machine204having the virtual volume manager208thereon and provide permissions to the virtual volume manager208associated with accessing portions of SSD devices (e.g., establishing bindings).

In cooperation with the hypervisor212, the host operating system214can manage operation of the hardware on server node202including the SSD devices (discussed below). In one or more embodiments described herein, the host operating system214may be tasked with performing any features and functionality that fall outside of the permissions that have been set for the virtual volume manager208on the virtual machine204. In one or more embodiments, the host operating system214facilitates the initial bindings between the virtual machine204and various SSD devices.

As further shown inFIG.2, the host system206includes a root complex216. The root complex216may include features and functionality for enabling components of the host system206(and virtual machines204) to communicate with or otherwise interface with various endpoints. The root complex216may include a variety of switches, multiplexers, ports (e.g., root ports) and other hardware that enable the host system206(and virtual machine204) to communicate with SSD devices or other types of endpoints (e.g., PCIe endpoints). Further, while one or more embodiments described herein relate specifically to a root complex216in a PCIe framework including PCIe interfaces for communicating with SSD devices, the host system206may utilize other implementations of hardware the facilitate communication between devices of the server node202and a variety of computing endpoints or types of non-volatile storage devices.

As mentioned above, and as shown inFIG.2, the server node(s)202may include multiple SSD devices218a-b. The SSD devices218a-bmay be coupled to the root complex216via PCIe links220a-b. The SSD devices218a-bmay refer to independent storage devices that are intended to operate independent from one another. The SSD devices218a-bmay have similar specifications (e.g., storage volumes, access speeds) and identical functionalities. Alternatively, the SSD devices218a-bmay provide different types or quantities of computing resources capable of accommodating different types of virtual machines and/or different sets of instructions indicated by associated configuration data.

As shown inFIG.2, computing resources of the SSD devices218a-bmay be exposed to the virtual machine204by way of virtual bindings222a-b. For example, a first binding222amay be established between the virtual machine204and the first SSD device218a. In addition, a second binding222bmay be established between the virtual machine204and the second SSD device218b. In one or more embodiments, the bindings222a-bare established by the host operating system214in conjunction with creating the virtual machine204on the server node202. Moreover, as discussed below, the bindings222a-bmay be established in accordance with the configuration data210indicating specifications and instructions associated with managing computing resources on the SSD devices218a-b.

The bindings220a-bmay refer to a variety of links between the virtual machine204and SSD devices208a-b. For example, in one or more embodiments, the bindings220a-brefer to physical functions established between the virtual machine204and the SSD devices208a-bthat enables the virtual machine204to obtain access to a storage volume or portion of a storage volume on the respective SSD devices208a-b. In one or more embodiments, the bindings220a-binclude a PCIe physical function that enables the virtual machine204to detect or enumerate a corresponding PCIe endpoint, which may include SSD devices218a-bcoupled to the root complex216via a PCIe interface. These bindings220a-bmay act as a link between the virtual machine204and the SSD devices218a-bfrom the perspective of the virtual machine204similar to a communication link that the PCIe links220a-bprovide between the host system206and the SSD devices208a-b.

The virtual machine204may additionally utilize a variety of physical functions when establishing the bindings222a-b. For example, in one or more implementations, the bindings222a-binclude SR-IOVs between the virtual machine204and SSD devices218a-b. In particular, each binding may refer to a respective SR-IOV interface between the virtual machine204and partitioned portion of the respective SSD device(s). Alternatively, in one or more embodiments, the bindings222a-binclude MPFs between the virtual machine204and SSD devices218a-b. In particular, each binding may refer to a respective MPF between the virtual machine204and discrete portion of the respective SSD device(s).

As will be discussed in further detail below, the bindings222a-b(e.g., the physical functions) may act as a physical interface between the virtual machine204and the SSD devices218a-bthat expressly limit a domain of storage space that the virtual machine204may access. For instance, where the SSD devices218a-binclude partitioned portions of storage (e.g., namespaces), the bindings222a-bmay selectively provide access to only the portions of storage that have been identified when establishing the bindings222a-bbetween the virtual machine204and the corresponding partitioned portions of the SSD devices218a-b. Establishing the bindings222a-busing physical functions enables the hardware of the SSD devices218a-bto limit access to a specific partitioned portion of the storage space corresponding to the physical function(s).

In one or more embodiments, the virtual machine204provides a virtualization of one or more storage volumes from the SSD devices218a-bin accordance with the configuration data. For example, in one or more embodiments, the virtual machine204provides a single storage volume based on two or more discrete partitions of storage space from the two (or more) SSD devices208a-b. For instance, where the configuration data includes instructions to combine storage from the two different SSD devices218a-bwithin a single volume, file, or other storage construct, a customer of the virtual machine204may view a single storage volume that includes a combination of data maintained on the two SSD devices218a-b. In accordance with one or more embodiments discussed herein, this combination and virtualization of computing resources within a single volume or virtualization may be performed by the virtual volume manager208(e.g., a guest operating system on the virtual volume manager) as an alternative to a hypervisor212facilitating the virtualization in accordance with the configuration data for the virtual machine204.

As mentioned above, and as will be discussed by way of example below in connection withFIG.3, the configuration data may include sets of rules or instructions for prioritizing different types of performance. For instance, the virtual machine204may have a particular function or characteristic based on the configuration data that facilitates differences in utilization of the computing resources (e.g., the SSD devices218a-b). As shown inFIG.2, the configuration data may be included or otherwise maintained by the virtual machine204to enable the virtual volume manager208to locally execute tasks and actions in accordance with functionality defined or otherwise included within the configuration data.

As a first example, in one or more embodiments, the configuration data210includes instructions for prioritizing redundancy (e.g., failover) of one or more storage volumes. In particular, based on these instructions for prioritizing redundancy, the virtual volume manager208may cause data to be replicated across both the first SSD device218aand the second SSD device218b. In accordance with the configuration data210, therefore, the virtual volume manager208can ensure2xfailover capacity for the data stored or otherwise maintained on the SSD devices218a-b. In this way, where one of the SSD devices218a-bgoes down, the virtual volume manager208may nonetheless have uninterrupted access to data stored on one of the two SSD devices218a-b.

As a second example, in one or more embodiments, the configuration data210includes instructions for prioritizing bandwidth, throughput, or other metric of computing performance for the one or more storage volumes. In particular, based on the instructions for prioritizing computing performance, the virtual volume manager208may concurrently utilize both volumes on the respective SSD devices218a-b. While this may not prevent the virtual volume manager208from losing data in the event of one of the SSD devices218a-bgoing down, it may nonetheless ensure faster performance of tasks performed by the virtual machine204. In addition, where a particular task or functionality of the virtual machine204does not depend on redundancy, this configuration may represent a more efficient utilization of available computing resources.

As a third example, in one or more embodiments, the configuration data210includes instructions having a combination of different priorities for the virtual machine204. For example, the configuration data210may include instructions for prioritizing a combination of computing performance and redundancy. In this example, the virtual volume manager208may duplicate data across both the SSD devices218a-bas well as utilize a greater partition (e.g., multiple partitions or namespaces) of the SSD devices218a-bto ensure faster performance while also ensuring2xfailover capacity. In addition, where the server node202includes additional SSD devices, the virtual volume manager208can utilize additional bindings between the virtual machine204and additional SSD devices to further implement specific instructions of the configuration data210.

WhileFIG.2illustrates an example implementation showing a server node(s)202including a single virtual machine204having two bindings222a-bwith two available SSD devices218a-b, it will be understood that any number of configurations having different sets of instructions may be implemented on one or multiple server devices. For example, the configuration data210may include different instructions corresponding to specific types of virtual machines204. In addition, the configuration data210may prioritize different performance specifications based on information received from customers upon creation of or deployment of the virtual machines

For example, as mentioned above, a cloud computing system102may include a resource management system106having one or more control planes thereon that are configured to deploy or otherwise implement virtual machines on respective server nodes. In one or more embodiments, a control plane or central resource system may receive a selection of a particular virtual machine type or set of specifications for a virtual machine and initiate a deployment of the virtual machine on the server node(s). In addition, the control plane and/or central resource system can provide the configuration data to the server node(s)202for use in creating the virtual machine204and implementing the virtual volume manager208thereon.

FIG.3illustrates another example implementation in which a plurality of virtual machines are implemented on a server node in accordance with one or more embodiments described herein. In particular, as shown inFIG.3, a server node(s)302may include multiple virtual machines304a-bhaving virtual volume managers306a-bimplemented thereon. The virtual machines304a-band virtual volume managers306a-bmay include similar features and corresponding component discussed above in connection withFIGS.1and2.

As further shown, the server node(s)302may include a host system308having a root complex310implemented thereon. While not shown inFIG.3, the host system308may additionally include a hypervisor and host operating system as discussed in connection with other examples configured to perform acts related to creating the virtual machines304a-band establishing bindings with respective storage volumes on the host system308. For ease in explanation, a root complex310is shown showing links (e.g., PCIe links) between the host system308and a plurality of SSD devices on the server node302.

As shown inFIG.3, the server node(s)302includes a plurality of SSD devices312a-d. Each of the SSD devices312a-dmay include allocable computing resources for use by any number of virtual machines deployed on the server node(s)302. As mentioned above, while the SSD devices312a-dspecifically refer to storage devices capable of maintaining data using SSD technology, other types of non-volatile storage devices may similarly be used in connection with one or more embodiments described here. In addition, whileFIG.3shows an example in which four SSD devices312a-dare available for allocation of computing resources, other implementations may include fewer or additional SSD devices. Moreover, in one or more embodiments, the server node302may include a combination of different types of non-volatile storage devices (e.g., SSD devices, flash memory, NAND memory, etc.)

In one or more embodiments, storage spaces of the SSD devices312a-dmay be divided into any number of partitioned spaces or allocations. For example, in one or more implementations, the SSD devices312a-dmay be partitioned into a number of storage namespaces (or simply “namespaces”). The namespaces may refer to discrete partitions of the storage on the SSD devices. The namespaces for a given SSD device may include partitions of uniform (or non-uniform) sizes (e.g., preconfigured partitions of storage). In one or more embodiments, the namespaces may be defined by the virtual machines304a-band/or hypervisor/OS on the host system308.

In the example shown inFIG.3, the SSD devices312a-deach include four namespaces corresponding to partitions of data on the respective devices. For instance, as shown inFIG.3, the first SSD device312aincludes four namespaces denoted as namespaces N0-N3. Similarly, the second SSD device312bincludes four namespaces denoted as namespaces N0-N3, the third SSD device312cincludes four namespaces denoted as namespaces N0-N3, and the fourth SSD device312dincludes four namespaces denoted as namespaces N0-N3. Other implementations may include SSD devices having fewer or additional namespaces. The different SSD devices may have different numbers of namespaces from one another. Further, the namespaces may be associated with storage spaces of similar or different sizes.

As shown inFIG.3, the virtual machines304a-bmay be bound to one or more of the SSD devices312a-d. More specifically, the host system308can facilitate establishing a binding (e.g., a physical function) between the virtual machines304a-dand respective namespaces of the SSD devices312a-d. In the example illustrated inFIG.3, the first virtual machine304ais associated with a first namespace (N0) of the first SSD device312avia a first binding314a. The first virtual machine304ais also associated with a first namespace (N0) on the second SSD device312bvia a second binding314b, a first namespace (N0) on the third SSD device312cvia a third binding314c, and a first namespace (N0) on the fourth SSD device312dvia a fourth binding314d. Each of the bindings314a-dmay refer to one of a number of different physical functions.

As further shown in the example illustrated inFIG.3, the second virtual machine304bis similarly associated with multiple SSD devices via respective bindings. In particular, as shown inFIG.3, the second virtual machine304bis associated with a second namespace (N1) on the third SSD device312cvia a first binding316aand a second namespace (N1) on the fourth SSD device312dvia a second binding316b. The bindings316a-bof the second virtual machine304bmay be a similar or different type of physical function from the bindings314a-dof the first virtual machine304a.

As further shown, each of the SSD devices312a-dprovide connectivity to the host system308by way of PCIe links318a-dbetween the respective SSD devices312a-dand the root complex310. For example, the first SSD device312ais coupled to the root complex310via a first PCIe link318a, the second SSD device312bis coupled to the root complex310via a second PCIe link318b, the third SSD device312cis coupled to the root complex310via a third PCIe link318c, and the fourth SSD device312dis coupled to the root complex310via a fourth PCIe link318d.

It is noted that each of the virtual machines304a-bmay have a different number of bindings for a variety of reasons. For instance, in one or more embodiments, the first virtual machine304aand the second virtual machine304bmay refer to different virtual machine types or virtual machines from different virtual machine families and may be associated with different functions.

In addition, or as an alternative, the virtual machines304a-bmay have similar (or different) functions, but establish a different number of bindings in accordance with configuration data associated with the respective virtual machines304a-b. For example, where a first virtual machine304ais created based on configuration data that indicates a higher performance demand or a higher requirement for redundancy (e.g.,2xor4xfailover), the resulting set of bindings for the first virtual machine304amay include a higher number of physical functions than a number of bindings for the second virtual machine304b. This configuration may be implemented even where the second virtual machine304bis a similar type of virtual machine or from a similar virtual machine family as the first virtual machine304a.

In addition to determining or implementing a number of bindings in accordance with the configuration data, the configuration data may additionally influence the behavior of the virtual machine in connection with each of the SSD devices312a-dvia the respective bindings. As an example, where the configuration data for the first virtual machine304aindicates that computing performance should be prioritized, the first virtual machine304amay concurrently utilize each of the first namespaces of the SSD devices312a-din a way that maximizes throughput or processing speed. Alternatively, where the configuration data for the second virtual machine304bindicates that redundancy should be prioritized, the second virtual machine304bmay cause data on the second namespaces of the third and fourth SSD devices312c-dto maintain duplicative data to have 2× failover capacity.

As noted above, the configuration data may indicate a combination of different performance priorities. For example, the first virtual machine304amay maximize processing throughput (or other computing performance metric) by concurrently accessing data on each of first namespaces of the SSD devices312a-dor, alternatively, duplicate data across each of the first namespaces of the SSD devices312a-d. Conversely, in one or more embodiments, the virtual volume manager306aon the first virtual machine304amay perform a combination of optimizations in accordance with the configuration data. For example, in accordance with the configuration data, the virtual volume manager306amay cause data on the first namespace of both the first and second SSD devices312a-bto be duplicated across the first namespace of both the third and fourth SSD devices312c-d. Further in accordance with the configuration data, the virtual volume manager306acan concurrently access data on the pairings of SSD devices312a-d(e.g., a first pair of the first and second SSD devices312a-band a second pair of the third and fourth devices312c-d) to boost computing performance.

Of note, the virtual volume managers306a-bmay implement features of the specific virtual machine configurations based on configuration data maintained thereon. In particular, rather than (or in addition to) maintaining the configuration data on the host system308, the virtual volume managers306a-bmay maintain local control of the functionality and accessing the data on the SSD devices312a-d.

Thus, independent of whether the configuration data indicates a priority on computing performance or redundancy, the virtual machines can locally manage access to the specific namespaces without querying or transmitting system calls to the hypervisor responsive to each access request. Rather, in accordance with one or more embodiments described herein, the hypervisor on the host system308can delegate functions of the virtual machines related to accessing and otherwise managing data on a select set of namespaces corresponding to the bindings without specifically authorizing or processing specific data requests. In one or more embodiments, the delegation of data management and other functions of the virtual machines304a-bmay be limited to actions taken by the virtual machines304a-bin connection with the specific namespaces that have been virtualized to the virtual machines304a-bvia the corresponding physical functions (e.g., bindings).

Turning now toFIG.4, this figure illustrates example flowcharts including series of acts for binding virtual machines to storage spaces and implementing a virtual volume manager on the virtual machines in accordance with one or more embodiments described herein. WhileFIG.4illustrates acts according to one or more embodiments, alternative embodiments may omit, add to, reorder, and/or modify any of the acts shown inFIG.4. The acts ofFIG.4can be performed as part of a method. Alternatively, a non-transitory computer-readable medium can include instructions that, when executed by one or more processors, cause a computing device (e.g., a server device) to perform the acts ofFIG.4. In still further embodiments, a system can perform the acts ofFIG.4.

As indicated above,FIG.4illustrates a series of acts400for binding virtual machines to storage spaces and implementing a virtual volume manager on the virtual machine (e.g., operating system(s) of the virtual machines). As shown inFIG.4, the series of acts400includes an act410of receiving virtual machine configuration data including instructions for managing computing resources on server nodes. For example, in one or more implementations, the act410involves receiving configuration data for a virtual machine where the configuration data includes instructions associated with managing computing resources on a plurality of non-volatile storage devices on a computing device.

As further shown inFIG.4, the series of acts400includes an act420of establishing a first binding between the virtual machine and a first non-volatile storage device on the server node. For example, in one or more implementations, the act420includes establishing a first binding between the virtual machine and a first non-volatile storage device of the plurality of non-volatile storage devices. The series of acts400further includes an act430of establishing a second binding between the virtual machine and a second non-volatile storage device on the server node. For example, in one or more implementations, the act430of establishing a second binding between the virtual machine and a second non-volatile storage device of the plurality of non-volatile storage devices.

As further shown inFIG.4, the series of acts400includes an act440of implementing, on an operating system of the virtual machine, a virtual volume manager configured to access the non-volatile storage devices via the respective bindings in accordance with the received configuration data. For example, in one or more implementations, the act440involves implementing a virtual volume manager on an operating system of the virtual machine where the virtual volume manager is configured to access the first non-volatile storage device and the second non-volatile storage device via the first and second bindings and in accordance with the received configuration data.

In one or more implementations, establishing the first binding includes binding the virtual machine to a first namespace associated with a partitioned portion of a first solid state storage (SSD) device. Further, in one or more implementations, establishing the second binding includes binding the virtual machine to a second namespace associated with a partitioned portion of a second SSD device. In one or more embodiments, the virtual volume manager is configured to provide a customer view including a single storage volume representative of a combination of the first namespace and the second namespace.

In one or more embodiments, establishing the first binding includes virtualizing at least a portion of the first non-volatile storage device to the virtual machine via a first physical function. Further, in one or more implementations, establishing the second binding includes virtualizing at least a portion of the second non-volatile storage device to the virtual machine via a second physical function. In one or more embodiments, the first physical function and the second physical function include one or more of a single root input/output (TO) virtualization physical function or a multi-physical function (MPF).

In one or more embodiments, the virtual volume manager is implemented locally on a guest operating system of the virtual machine. Further, the virtual machine may be implemented on the computing device including a hypervisor and host operating system. In one or more embodiments, the plurality of non-volatile storage devices includes a plurality of peripheral component interconnect express (PCIe) endpoints. For example, the first non-volatile storage device may include a first PCIe endpoint coupled to a root complex and the second non-volatile storage device may include a second PCIe endpoint coupled to the root complex.

In one or more embodiments, implementing the virtual volume manager enables the virtual machine to access computing resources on the first non-volatile storage device and the second non-volatile storage device without requesting access from a host operating system of the computing device for each access command.

In one or more embodiments, the configuration data includes instructions for prioritizing redundancy across the first non-volatile storage device and the second non-volatile storage device. In this example, implementing the virtual volume manager on the virtual machine causes data on the first non-volatile storage device to have redundancy on the second non-volatile storage device in accordance with the configuration data.

In one or more embodiments, the configuration data includes instructions for utilizing computing resources on both the first non-volatile storage device and the second non-volatile storage device to boost computing performance for the virtual machine. In this example, implementing the virtual volume manager on the virtual machine enables the virtual machine to concurrently utilize computing resources on the first non-volatile storage device and the second non-volatile storage device in accordance with the configuration data.

In one or more embodiments, the series of acts400includes establishing a third binding between the virtual machine and a third non-volatile storage device of the plurality of non-volatile storage devices and establishing a fourth binding between the virtual machine and a fourth non-volatile storage device of the plurality of non-volatile storage devices. In this example, the configuration data may include first instructions associated with prioritizing redundancy across multiple non-volatile storage devices and second instructions for utilizing computing resources on multiple non-volatile storage devices to boost computing performance. Further, implementing the virtual volume manager on the virtual machine may cause data on the first non-volatile storage device to have redundancy on the second non-volatile storage device in accordance with the first instructions of the configuration data. Implementing the virtual volume manager on the virtual machine may further cause the virtual machine to concurrently utilize computing resources on the third non-volatile storage device and the fourth non-volatile storage device in accordance with the second instructions of the configuration data.

FIG.5illustrates certain components that may be included within a computer system500. One or more computer systems500may be used to implement the various devices, components, and systems described herein.

The computer system500includes a processor501. The processor501may be a general-purpose single- or multi-chip microprocessor (e.g., an Advanced RISC (Reduced Instruction Set Computer) Machine (ARM)), a special purpose microprocessor (e.g., a digital signal processor (DSP)), a microcontroller, a programmable gate array, etc. The processor501may be referred to as a central processing unit (CPU). Although just a single processor501is shown in the computer system500ofFIG.5, in an alternative configuration, a combination of processors (e.g., an ARM and DSP) could be used.

The computer system500also includes memory503in electronic communication with the processor501. The memory503may be any electronic component capable of storing electronic information. For example, the memory503may be embodied as random access memory (RAM), read-only memory (ROM), magnetic disk storage media, optical storage media, flash memory devices in RAM, on-board memory included with the processor, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM) memory, registers, and so forth, including combinations thereof.

Instructions505and data507may be stored in the memory503. The instructions505may be executable by the processor501to implement some or all of the functionality disclosed herein. Executing the instructions505may involve the use of the data507that is stored in the memory503. Any of the various examples of modules and components described herein may be implemented, partially or wholly, as instructions505stored in memory503and executed by the processor501. Any of the various examples of data described herein may be among the data507that is stored in memory503and used during execution of the instructions505by the processor501.

A computer system500may also include one or more communication interfaces509for communicating with other electronic devices. The communication interface(s)509may be based on wired communication technology, wireless communication technology, or both. Some examples of communication interfaces509include a Universal Serial Bus (USB), an Ethernet adapter, a wireless adapter that operates in accordance with an Institute of Electrical and Electronics Engineers (IEEE) 802.11 wireless communication protocol, a Bluetooth® wireless communication adapter, and an infrared (IR) communication port.

A computer system500may also include one or more input devices511and one or more output devices513. Some examples of input devices511include a keyboard, mouse, microphone, remote control device, button, joystick, trackball, touchpad, and lightpen. Some examples of output devices513include a speaker and a printer. One specific type of output device that is typically included in a computer system500is a display device515. Display devices515used with embodiments disclosed herein may utilize any suitable image projection technology, such as liquid crystal display (LCD), light-emitting diode (LED), gas plasma, electroluminescence, or the like. A display controller517may also be provided, for converting data507stored in the memory503into text, graphics, and/or moving images (as appropriate) shown on the display device515.

The various components of the computer system500may be coupled together by one or more buses, which may include a power bus, a control signal bus, a status signal bus, a data bus, etc. For the sake of clarity, the various buses are illustrated inFIG.5as a bus system519.