Patent Application
20190332413
Examples described herein relate generally to distributed computing systems. Examples of virtualized systems are described. container management tools are provided in some examples of distributed computing systems described herein to facilitate migration of services of infrastructure management virtual machines to a container.
A virtual machine (VM) generally refers to a software-based implementation of a machine in a virtualization environment, in which the hardware resources of a physical computer (e.g., CPU, memory, etc.) are virtualized or transformed into the underlying support for the fully functional virtual machine that can run its own operating system and applications on the underlying physical resources just like a real computer.
Virtualization generally works by inserting a thin layer of software directly on the computer hardware or on a host operating system. This layer of software contains a virtual machine monitor or “hypervisor” that allocates hardware resources dynamically and transparently. Multiple operating systems may run concurrently on a single physical computer and share hardware resources with each other. By encapsulating an entire machine, including CPU, memory, operating system, and network devices, a virtual machine may be completely compatible with most standard operating systems, applications, and device drivers. Most modern implementations allow several operating systems and applications to safely run at the same time on a single computer, with each having access to the resources it needs when it needs them.
One reason for the broad adoption of virtualization in modern business and computing environments is because of the resource utilization advantages provided by virtual machines. Without virtualization, if a physical machine is limited to a single dedicated operating system, then during periods of inactivity by the dedicated operating system the physical machine may not be utilized to perform useful work. This may be wasteful and inefficient if there are users on other physical machines which are currently waiting for computing resources. Virtualization allows multiple VMs to share the underlying physical resources so that during periods of inactivity by one VM, other VMs can take advantage of the resource availability to process workloads. This can produce great efficiencies for the utilization of physical devices, and can result in reduced redundancies and better resource cost management.
To easily identify the discussion of any particular element or act, the most significant digit or digits in a reference number refer to the figure number in which that element is first introduced.
This disclosure describes embodiments for migration of services/applications of infrastructure management virtual machines (IMVMs) to containers (e.g., a docker container, a Linux container, or any other construct that is capable of holding a set of processes that are isolated from the rest of the system, running from a distinct image that provides all files necessary to support the processes). Generally, a container may refer to a standalone/self-contained executable package of software that includes an entire runtime environment, including an application and dependencies, libraries, binaries, configurations files, etc. to run the application. Containers are tools that may allow many different applications to coexist on a single server without interfering or interacting with each other. The container acts as a boundary within a computer system that can control which computing resources, interfaces, other applications, etc. that are available and visible to the application. From the perspective of the application, the container may look like it is providing access to the entire computing system, even though it only actually aware of a portion of the computing system permitted to be visible and accessible by from the container. Moving services/applicants to containers, in some examples, may be a computing-resource-efficient alternative to a virtual machine due to decreased overhead processes and an ability to replicate a subset of services/applicants (e.g., as opposed to a VM that requires an entire set of services/applications to operate). Generally, IMVMs provide a central infrastructure resource to monitor and manage multiple clusters of nodes in a virtual computing environment. IMVMs can, in some examples, consume significant computing resources, and may effectively render a host computing node inoperable for other functions, especially in systems that include multiple IMVMs. Migrating the functionality (e.g., the services) of the IMVMs to containers may provide a more computing-resource-efficient and configurable alternative to the IMVMs.
Various embodiments of the present disclosure will be explained below in detail with reference to the accompanying drawings. The following detailed description refers to the accompanying drawings that show, by way of illustration, specific aspects and embodiments of the disclosure. The detailed description includes sufficient detail to enable those skilled in the art to practice the embodiments of the disclosure. Other embodiments may be utilized, and structural, logical and electrical changes may be made without departing from the scope of the present disclosure. The various embodiments disclosed herein are not necessary mutually exclusive, as some disclosed embodiments can be combined with one or more other disclosed embodiments to form new embodiments.
The storage 140 may include local storage 124, local storage 130, cloud storage 136, and networked storage 138. The local storage 124 may include, for example, one or more solid state drives (SSD 126) and one or more hard disk drives (HDD 128). Similarly, local storage 130 may include SSD 132 and HDD 134. Local storage 124 and local storage 130 may be directly coupled to, included in, and/or accessible by a respective computing node 102 and/or computing node 112 without communicating via the network 122. Cloud storage 136 may include one or more storage servers that may be stored remotely to the computing node 102 and/or computing node 112 and accessed via the network 122. Other nodes, however, may access the local storage 124 and/or the local storage 130 using the network 122. The cloud storage 136 may generally include any type of storage device, such as HDDs SSDs, or optical drives. Networked storage 138 may include one or more storage devices coupled to and accessed via the network 122. The networked storage 138 may generally include any type of storage device, such as HDDs SSDs, and/or NVM Express (NVMe). In various embodiments, the networked storage 138 may be a storage area network (SAN). The computing node 102 is a computing device for hosting virtual machines (VMs) in the distributed computing system of
The computing node 102 is configured to execute a hypervisor 110, a controller VM 108 and one or more user VMs, such as user VMs 104, 106. The user VMs including user VM 104 and user VM 106 are virtual machine instances executing on the computing node 102. The user VMs including user VM 104 and user VM 106 may share a virtualized pool of physical computing resources such as physical processors and storage (e.g., storage 140). The user VMs including user VM 104 and user VM 106 may each have their own operating system, such as Windows or Linux. While a certain number of user VMs are shown, generally any number may be implemented. User VMs may generally be provided to execute any number of applications and services desired by a user.
The hypervisor 110 may be any type of hypervisor. For example, the hypervisor 110 may be ESX, ESX(i), Hyper-V, KVM, or any other type of hypervisor. The hypervisor 110 manages the allocation of physical resources (such as storage 140 and physical processors) to VMs (e.g., user VM 104, user VM 106, and controller VM 108) and performs various VM related operations, such as creating new VMs and cloning existing VMs. Each type of hypervisor may have a hypervisor-specific API through which commands to perform various operations may be communicated to the particular type of hypervisor. The commands may be formatted in a manner specified by the hypervisor-specific API for that type of hypervisor. For example, commands may utilize a syntax and/or attributes specified by the hypervisor-specific API.
Controller VMs (CVMs) described herein, such as the controller VM 108 and/or controller VM 118, may provide services for the user VMs in the computing node. As an example of functionality that a controller VM may provide, the controller VM 108 may provide virtualization of the storage 140. Controller VMs may provide management of the distributed computing system shown in
The computing node 112 may include user VM 114, user VM 116, a controller VM 118, and a hypervisor 120. The user VM 114, user VM 116, the controller VM 118, and the hypervisor 120 may be implemented similarly to analogous components described above with respect to the computing node 102. For example, the user VM 114 and user VM 116 may be implemented as described above with respect to the user VM 104 and user VM 106. The controller VM 118 may be implemented as described above with respect to controller VM 108. The hypervisor 120 may be implemented as described above with respect to the hypervisor 110. In the embodiment of
The controller VM 108 and controller VM 118 may communicate with one another via the network 122. By linking the controller VM 108 and controller VM 118 together via the network 122, a distributed network of computing nodes including computing node 102 and computing node 112, can be created. In some examples, the hypervisor 110 may be of a same type as the hypervisor 120.
Controller VMs, such as controller VM 108 and controller VM 118, may each execute a variety of services and may coordinate, for example, through communication over network 122. Services running on controller VMs may utilize an amount of local memory to support their operations. For example, services running on controller VM 108 may utilize memory in local memory 142. Services running on controller VM 118 may utilize memory in local memory 144. The local memory 142 and local memory 144 may be shared by VMs on computing node 102 and computing node 112, respectively, and the use of local memory 142 and/or local memory 144 may be controlled by hypervisor 110 and hypervisor 120, respectively. Moreover, multiple instances of the same service may be running throughout the distributed system—e.g. a same services stack may be operating on each controller VM. For example, an instance of a service may be running on controller VM 108 and a second instance of the service may be running on controller VM 118.
Generally, controller VMs described herein, such as controller VM 108 and controller VM 118 may be employed to control and manage any type of storage device, including all those shown in storage 140 of
In some examples, the controller VMs may include an orchestration engine (e.g., the orchestration engine 150 and the orchestration engine 152) that facilitates migration of and hosting of services/applications from IMVMs in one or more containers. The orchestration engine may define one or more volume groups that include data for running the services/applications, which may allow a service running on a respective container to access the associated service data. In some examples, the client may include one or more of the user VMs 104, 106, 114, or 118. Controller VMs 108 and 118 may include one or more container management tools to facilitate the migration and operation of the services/applications included in the containers. Orchestration services described herein may utilize the container management tools to perform the data migration and operation associated with a services/applications.
Note that controller VMs are provided as virtual machines utilizing hypervisors described herein—for example, the controller VM 108 is provided behind hypervisor 110. Since the controller VMs run “above” the hypervisors examples described herein may be implemented within any virtual machine architecture, since the controller VMs may be used in conjunction with generally any hypervisor from any virtualization vendor.
Virtual disks (vDisks) may be structured from the storage devices in storage 140, as described herein. A vDisk generally refers to the storage abstraction that may be exposed by a controller VM to be used by a user VM. In some examples, the vDisk may be exposed via iSCSI (“internet small computer system interface”) or NFS (“network file system”) and may be mounted as a virtual disk on the user VM. For example, the controller VM 108 may expose one or more vDisks of the storage 140 the hypervisor 110 may attach the vDisks to one or more VMs, and the virtualized operating system and may mount a vDisk on one or more user VMs, such as user VM 104 and/or user VM 106.
During operation, user VMs (e.g., user VM 104 and/or user VM 106) may provide storage input/output (I/O) requests to controller VMs (e.g., controller VM 108 and/or hypervisor 110). Accordingly, a user VM may provide an I/O request over a virtual bus to a hypervisor as an iSCSI and/or NFS request. Internet Small Computer System Interface (iSCSI) generally refers to an IP-based storage networking standard for linking data storage facilities together. By carrying SCSI commands over IP networks, iSCSI can be used to facilitate data transfers over intranets and to manage storage over any suitable type of network or the Internet. The iSCSI protocol allows iSCSI initiators to send SCSI commands to iSCSI targets at remote locations over a network. In some examples, user VMs may send I/O requests to controller VMs in the form of NFS requests. Network File System (NFS) refers to an IP-based file access standard in which NFS clients send file-based requests to NFS servers via a proxy folder (directory) called “mount point”. Generally, then, examples of systems described herein may utilize an IP-based protocol (e.g., iSCSI and/or NFS) to communicate between hypervisors and controller VMs.
During operation, examples of user VMs described herein may provide storage requests using an IP based protocol, such as SMB. The storage requests may designate the IP address for a controller VM from which the user VM desires I/O services. The storage request may be provided from the user VM to a virtual switch within a hypervisor to be routed to the correct destination. For examples, the user VM 104 may provide a storage request to hypervisor 110. The storage request may request I/O services from controller VM 108 and/or controller VM 118. If the request is to be intended to be handled by a controller VM in a same service node as the user VM (e.g., controller VM 108 in the same computing node as user VM 104) then the storage request may be internally routed within computing node 102 to the controller VM 108. In some examples, the storage request may be directed to a controller VM on another computing node. Accordingly, the hypervisor (e.g., hypervisor 110) may provide the storage request to a physical switch to be sent over a network (e.g., network 122) to another computing node running the requested controller VM (e.g., computing node 112 running controller VM 118).
Accordingly, hypervisors described herein may manage I/O requests between user VMs in a system and a storage pool. Controller VMs may virtualize I/O access to hardware resources within a storage pool according to examples described herein. In this manner, a separate and dedicated controller (e.g., controller VM) may be provided for each and every computing node within a virtualized computing system (e.g., a cluster of computing nodes that run hypervisor virtualization software), since each computing node may include its own controller VM. Each new computing node in the system may include a controller VM to share in the overall workload of the system to handle storage tasks. Therefore, examples described herein may be advantageously scalable, and may provide advantages over approaches that have a limited number of controllers. Consequently, examples described herein may provide a massively-parallel storage architecture that scales as and when hypervisor computing nodes are added to the system.
In operation, the IMVMs 291(1)-(N) may monitor and manage one or more clusters of nodes (e.g., the nodes 102 and/or 112 of
Therefore, to move to a more computing resource efficient solution, an orchestration engine 250 operating on a CVM 218 may migrate the individual services of the sets of services 292(1)-(N) from the IMVMs 291(1)-(N) to respective containers 271-278. The migration may include extracting the individual services from the sets of services 292(1)-(N) from the IMVMs 291(1)-(N) and creating the containers 271-278 that include one or more of the extracted services. The migration may also include migration of the service data 281(1)-(N) to facilitate execution of the services. On started, the container management engine 232 may provide an interface for services running in the respective containers 271-278 to communicate within an overall computing system, including communication with the operating system 252 of the CVM 218. The CVM 218 may be implemented in one or more of the CVMs 108 and 118 of
The allocation of individual services among the containers 271-278 depicted in
In
The computing node 400 includes a communications fabric 402, which provides communications between one or more processor(s) 404, memory 406, local storage 408, communications unit 410, I/O interface(s) 412. The communications fabric 402 can be implemented with any architecture designed for passing data and/or control information between processors (such as microprocessors, communications and network processors, etc.), system memory, peripheral devices, and any other hardware components within a system. For example, the communications fabric 402 can be implemented with one or more buses.
The memory 406 and the local storage 408 are computer-readable storage media. In this embodiment, the memory 406 includes random access memory RAM 414 and cache 416. In general, the memory 406 can include any suitable volatile or non-volatile computer-readable storage media. The local storage 408 may be implemented as described above with respect to local storage 124 and/or local storage 130. In this embodiment, the local storage 408 includes an SSD 422 and an HDD 424, which may be implemented as described above with respect to SSD 126, SSD 132 and HDD 128, HDD 134 respectively.
Various computer instructions, programs, files, images, etc. may be stored in local storage 408 for execution by one or more of the respective processor(s) 404 via one or more memories of memory 406. In some examples, local storage 408 includes a magnetic HDD 424. Alternatively, or in addition to a magnetic hard disk drive, local storage 408 can include the SSD 422, a semiconductor storage device, a read-only memory (ROM), an erasable programmable read-only memory (EPROM), a flash memory, or any other computer-readable storage media that is capable of storing program instructions or digital information.
The media used by local storage 408 may also be removable. For example, a removable hard drive may be used for local storage 408. Other examples include optical and magnetic disks, thumb drives, and smart cards that are inserted into a drive for transfer onto another computer-readable storage medium that is also part of local storage 408.
Communications unit 410, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit 410 includes one or more network interface cards. Communications unit 410 may provide communications through the use of either or both physical and wireless communications links.
I/O interface(s) 412 allows for input and output of data with other devices that may be connected to computing node 400. For example, I/O interface(s) 412 may provide a connection to external device(s) 418 such as a keyboard, a keypad, a touch screen, and/or some other suitable input device. External device(s) 418 can also include portable computer-readable storage media such as, for example, thumb drives, portable optical or magnetic disks, and memory cards. Software and data used to practice embodiments of the present disclosure can be stored on such portable computer-readable storage media and can be loaded onto local storage 408 via I/O interface(s) 412. I/O interface(s) 412 also connect to a display 420.
Display 420 provides a mechanism to display data to a user and may be, for example, a computer monitor.
Although this disclosure has been disclosed in the context of certain preferred embodiments and examples, it will be understood by those skilled in the art that the disclosures extend beyond the specifically disclosed embodiments to other alternative embodiments and/or uses of the disclosures and obvious modifications and equivalents thereof. In addition, other modifications which are within the scope of this disclosure will be readily apparent to those of skill in the art based on this disclosure. It is also contemplated that various combination or sub-combination of the specific features and aspects of the embodiments may be made and still fall within the scope of the disclosures. It should be understood that various features and aspects of the disclosed embodiments can be combined with or substituted for one another in order to form varying mode of the disclosed disclosure. Thus, it is intended that the scope of at least some of the present disclosure herein disclosed should not be limited by the particular disclosed embodiments described above.
