SNAPSHOT BASED POOL OF VIRTUAL RESOURCES FOR EFFICIENT DEVELOPMENT AND TEST OF HYPER-CONVERGED INFRASTRUCTURE ENVIRONMENTS

A disclosed method for developing and testing a hyper-converged infrastructure (HCI) platform creates a snapshot pool with one or more virtual resource snapshots that include one or more virtual node snapshots, one or more virtual cluster snapshots, or both. The snapshot pool may be maintained with a desired quantity of the virtual resource snapshots by adjusting the composition of the snapshot pool in response to snapshot events, including an event that alters either a composition of the snapshot pool or a configuration of the HCI platform. The desired quantity of virtual resource snapshots may be determined in accordance with one or more snapshot thresholds. The snapshot thresholds may include a snapshot pertaining to a quantity of virtual node snapshots in the snapshot pool and/or a snapshot pertaining to a quantity of virtual cluster snapshots. Specifically, the threshold may include a cluster maximum and minimum and a node maximum and minimum.

TECHNICAL FIELD

The present disclosure relates to information handlings systems and, more specifically, developing and testing various information handling system configurations.

BACKGROUND

Information handling systems may be configured with a hyper-converged infrastructure (HCI), often using standard hardware including, as a non-limiting example, x86-based servers. In the context of a data center, as an example, HCI may be broadly defined as an information technology (IT) implementation that natively integrates all data center functions, including compute, storage, and networking, in a virtualized platform operated and monitored through a unified management console.

Developing and testing of HCI environments is inefficient at least in part because the process of building a multi-node HCI cluster is slow, even on a simulated virtual platform.

SUMMARY

In accordance with teachings disclosed herein, common problems associated with developing and testing a distributed and virtualized information handling system, such as a hyper-converged infrastructure (HCI) platform, may include creating a snapshot pool comprising one or more virtual resource snapshots, wherein the virtual resource snapshots include one or more virtual node snapshots, one or more virtual cluster snapshots, or both and maintaining the snapshot pool with a desired quantity of the virtual resource snapshots. Maintaining the desired quantity may include adjusting the composition of the snapshot pool in response to a snapshot event. For purposes of this disclosure, a snapshot may be defined as a copy of a state of a system, e.g., a virtual machine, including files and data, at a specific point in time. A snapshot event may refer to an event that alters either a composition of the snapshot pool (e.g., changes the number of available snapshots) or a configuration of the HCI platform (e.g., a change in the number of virtual resources associated with the HCI platform). The desired quantity of virtual resource snapshots may be determined in accordance with one or more snapshot thresholds. The snapshot thresholds may include a snapshot pertaining to a quantity of virtual node snapshots in the snapshot pool and/or a snapshot pertaining to a quantity of virtual cluster snapshots.

Creating the snapshot pool may include building a plurality of virtual node resources from a stable image of a single node, generating a node snapshot for each of the virtual node resources, creating a virtual cluster resource from two or more of the virtual node resources, generating a cluster snapshot of the virtual cluster resource and adding at least one snapshot, selected from the single node snapshots and the cluster snapshot, to the resource pool. Maintaining the snapshot pool may include automatically adding one or more cluster snapshots to the resource pool responsive to determining either that the number of node snapshots is less than a minimum node threshold or the number of cluster snapshots is less than a minimum cluster threshold. Adding one or more clusters may include adding a quantity of cluster snapshots, wherein the quantity is determined based on an amount by which (a) the minimum node threshold exceeds a node snapshot count and (b) the minimum cluster threshold exceeds a cluster snapshot count.

The one or more snapshot thresholds may include thresholds for a minimum quantity of cluster snapshots (cluster minimum), a maximum quantity of cluster snapshots (cluster maximum), a minimum quantity of node snapshots (node minimum), and/or a maximum number of node snapshots (node maximum). The snapshot event may be an apply snapshot event, in which a node or cluster snapshot is used to instantiate a node or cluster resource, wherein a quantity of snapshots in the snapshot pool decreases, or a release resource event, wherein a quantity of virtual resources associated with the virtual platform decreases.

When a virtual cluster resource is released, the manner in which the snapshot pool is maintained may depend upon the number of node and cluster snapshots in the snapshot pool. If the number of node snapshots and cluster snapshots is greater than the minimum and less than the maximum, maintaining the snapshot pool may include reverting the virtual cluster resource to a cluster snapshot in the snapshot pool. Prior to reverting the virtual cluster resource, a service status of the virtual cluster may be checked and, if the virtual cluster fails, the service status check, the virtual resource may be terminated. If the number of node snapshots in the snapshot pool when the cluster resource is released is below the node minimum and the number of cluster snapshots is greater than the cluster maximum, maintaining the snapshot pool may include reverting the virtual cluster resource to one or more node snapshots. If the number of cluster and node snapshots in the snapshot pool both exceed their respective maximum thresholds, maintaining the snapshot pool may include terminating the virtual cluster.

DETAILED DESCRIPTION

Exemplary embodiments and their advantages are best understood by reference toFIGS.1-7, wherein like numbers are used to indicate like and corresponding parts unless expressly indicated otherwise.

Additionally, an information handling system may include firmware for controlling and/or communicating with, for example, hard drives, network circuitry, memory devices, I/O devices, and other peripheral devices. For example, the hypervisor and/or other components may comprise firmware. As used in this disclosure, firmware includes software embedded in an information handling system component used to perform predefined tasks. Firmware is commonly stored in non-volatile memory, or memory that does not lose stored data upon the loss of power. In certain embodiments, firmware associated with an information handling system component is stored in non-volatile memory that is accessible to one or more information handling system components. In the same or alternative embodiments, firmware associated with an information handling system component is stored in non-volatile memory that is dedicated to and comprises part of that component.

Throughout this disclosure, a hyphenated form of a reference numeral refers to a specific instance of an element and the un-hyphenated form of the reference numeral refers to the element generically. Thus, for example, “device12-1” refers to an instance of a device class, which may be referred to collectively as “devices12” and any one of which may be referred to generically as “a device12”.

As used herein, when two or more elements are referred to as “coupled” to one another, such term indicates that such two or more elements are in electronic communication, mechanical communication, including thermal and fluidic communication, thermal, communication or mechanical communication, as applicable, whether connected indirectly or directly, with or without intervening elements.

Before describing disclosed features for monitoring and managing event messages in a distributed computing environment, an exemplary HCI platform suitable for implementing these features is provided. Referring now to the drawings,FIG.1andFIG.2illustrate an exemplary information handling system100. The information handling system100illustrated inFIG.1andFIG.2includes a platform101communicatively coupled to a platform administrator102. The platform101illustrated inFIG.1is an HCI platform in which compute, storage, and networking resources are virtualized to provide a software defined information technology (IT) infrastructure. Administrator102may be any computing system with functionality for overseeing operations and maintenance pertinent to the hardware, software, and/or firmware elements of HCI platform101. Platform administrator102may interact with HCI platform101via requests to and responses from an application programming interface (API) (not explicitly depicted). In such embodiments, the requests may pertain to event messaging monitoring and event messaging state management described below. The HCI platform101illustrated inFIG.1may be implemented as or within a data center and/or a cloud computing resource featuring software-defined integration and virtualization of various information handling resources including, without limitation, servers, storage, networking resources, management resources, etc.

The HCI platform101illustrated inFIG.1includes one or more HCI clusters106-1through106-N communicatively coupled to one another and to a platform resource monitor (PRM)114. Each HCI cluster106illustrated inFIG.1encompasses a group of HCI nodes110-1through110-M configured to share information handling resources. In some embodiments, resource sharing may entail virtualizing a resource in each HCI node110to create a logical pool of that resource, which, subsequently, may be provisioned, as needed, across all HCI nodes110in HCI cluster106. For example, when considering storage resources, the physical device(s) (e.g., hard disk drives (HDDs), solid state drives (SSDs), etc.) representative of the local storage resources on each HCI node110may be virtualized to form a cluster distributed file system (DFS)112. In at least some such embodiments, cluster DFS112corresponds to a logical pool of storage capacity formed from some or all storage within an HCI cluster106.

An HCI cluster106, and the one or more HCI nodes110within the cluster, may represent or correspond to an entire application or to one or more of a plurality of micro services that implement the application. As an example, an HCI cluster106may be dedicated to a specific micro service in which multiple HCI nodes110provide redundancy and support high availability. In another example, the HCI nodes110within HCI cluster106include one or more nodes corresponding to each micro service associated with a particular application.

The HCI cluster106-1illustrated inFIG.1further includes a cluster network device (CND)108, which facilitates communications and/or information exchange between the HCI nodes110of HCI cluster106-1and other clusters106, PRM114, and/or one or more external entities including, as an example, platform the administrator102. In at least some embodiments, CND108is implemented as a physical device, examples of which include, but are not limited to, a network switch, a network router, a network gateway, a network bridge, or any combination thereof.

PRM114may be implemented with one or more servers, each of which may correspond to a physical server in a data center, a cloud-based virtual server, or a combination thereof. PRM114may be communicatively coupled to all HCI nodes110across all HCI clusters106in HCI platform101and to platform administrator102. PRM114may include a resource utilization monitoring (RUM) service or feature with functionality to monitor resource utilization parameters (RUPs) associated with HCI platform101.

FIG.2illustrates an exemplary HCI node110in accordance with disclosed subject matter. HCI node110, which may be implemented with a physical appliance, e.g., a server (not shown), implements hyper-convergent architecture, offering the integration of virtualization, compute, storage, and networking resources into a single solution. HCI node110may include a resource utilization agent (RUA)202communicatively coupled to network resources204, compute resources206, and a node controller216. The node controller216illustrated inFIG.2is coupled to a hypervisor208that supports one or more virtual machines (VMs)210-1through210-L), each of which is illustrated with an operating system (OS)214and one or more application program(s)212. The illustrated node controller216is further coupled to storage components including zero or more optional storage controllers220, for example, a small computer system interface (SCSI) controller, and storage components222.

In some embodiments, RUA202is tasked with monitoring the utilization of virtualization, compute, storage, and/or network resources on HCI node110. Thus, the node RUA202may include functionality to: monitor the utilization of: network resources204to obtain network resource utilization parameters (RUPs), compute resources206to obtain compute RUPs, virtual machines210to obtain virtualization RUPs, storage resources222to obtain storage RUPs. RUA202may provide some or all RUPs to environment resource monitor (ERM)226periodically through pull and/or push mechanisms.

Referring now toFIG.3, one or more of the HCI components illustrated inFIG.1andFIG.2may be instantiated as or within a physical resource exemplified by the information handling system300illustrated inFIG.3. The illustrated information handling system includes one or more general purpose processors or central processing units (CPUs)301communicatively coupled to a memory resource310and to an input/output hub320to which various I/O resources and/or components are communicatively coupled. The I/O resources explicitly depicted inFIG.3include a network interface340, commonly referred to as a NIC (network interface card), storage resources330, and additional I/O devices, components, or resources including as non-limiting examples, keyboards, mice, displays, printers, speakers, microphones, etc. The illustrated information handling system300includes a baseboard management controller (BMC)360providing, among other features and services, an out-of-band management resource which may be coupled to a management server (not depicted). In at least some embodiments, BMC360may manage information handling system300even when information handling system300is powered off or powered to a standby state. BMC360may include a processor, memory, an out-of-band network interface separate from and physically isolated from an in-band network interface of information handling system300, and/or other embedded information handling resources. In certain embodiments, BMC360may include or may be an integral part of a remote access controller (e.g., a Dell Remote Access Controller or Integrated Dell Remote Access Controller) or a chassis management controller.

Turning now toFIG.4, a flow diagram illustrates a disclosed method400suitable for use in simulating, developing, and/or testing an HCI platform. Method400may be performed by any suitable management resource including any management-capable resource illustrated inFIG.1and/orFIG.2. The disclosed method includes creating (operation402) a snapshot pool comprising one or more virtual resource snapshots. The virtual resource snapshots may include one or more virtual node snapshots, one or more virtual cluster snapshots, or a combination of both. The disclosed method further includes maintaining (operation404) the snapshot pool with a desired quantity of virtual resource snapshots by adjusting the composition of the snapshot pool, i.e., the quantity of virtual resource snapshots, in response to a snapshot event. Snapshot events include events such as an apply snapshot event that result in a reduction of the number of snapshots in the snapshot pool and an increase in the number of virtual resources in the HCI platform. Snapshot events also include events, such as release resource events, that result in a reduction of the quantity of virtual resources and, in at least some instances, an increase in the quantity of snapshots. The desired levels of snapshots may be indicated by maximum and minimum thresholds for node snapshots and cluster snapshots.

Turning now toFIG.5, a method500for creating a snapshot pool is illustrated. The illustrated method500includes an initial build502of one or more virtual HCI nodes504. The build502is or may be generated from a known stable image501of an HCI hardware node. The example illustrated inFIG.5includes and creates three distinct virtual node resources504, but it will appreciated by those of ordinary skill in the field that other implementations may build more or fewer virtual node resources. As further illustrated inFIG.5, one or more node snapshots510, also sometimes referred to herein as a first snapshots, are taken of the one or more virtual HCI nodes501. After the node snapshots510have been taken, a cluster520of two or more nodes504is created (operation512) and a cluster snapshot522is taken and stored.

FIG.6is a graphical representation of a snapshot pool600in accordance with disclosed teachings. The snapshot pool600illustrated inFIG.6includes one or more node snapshots510and/or one or more cluster snapshots522. Counts of each type of snapshot stored in snapshot pool600may be tracked and, in at least some embodiments, a management resource may maintain the number of snapshots stored in snapshot pool600in accordance with predetermined or user-defined minimum and maximum threshold values.FIG.6illustrates node parameters including a node snapshot maximum601, a node snapshot count602, and a node snapshot minimum603and cluster parameters including a cluster snapshot maximum611, a cluster snapshot count612, and a cluster snapshot minimum613.

In at least some embodiments, the number of each type of snapshot stored in snapshot pool600may be controlled to maintain the number within the range between the minimum snapshot and the maximum snapshot parameters illustrated inFIG.6. The number of snapshots stored in snapshot pool600may be increased or decreased in response to one or more snapshot events. Snapshot events may refer to any operation or command that results in a change in the number of node snapshots510or cluster snapshots522. An exemplary implementation of managing snapshot pool600is illustrated and described below with respect toFIG.7.

FIG.7illustrates an exemplary snapshot pool management method700in accordance with an embodiment of disclosed subject matter. The illustrated example of method700automatically or manually initiates a virtual node creation and virtual cluster creation sequence701, analogous to the method500illustrated and described with respect toFIG.5, to create a cluster snapshot522. The illustrated sequence701may be triggered automatically based on the number of snapshots stored in the snapshot pool and the applicable minimum and maximum snapshots counts. As a non-limiting example, sequence701may be automatically triggered when the node snapshot count and the cluster snapshot count are below the respective minimum snapshot values.

The cluster snapshot522, according to the illustrated method700, is joined or added (operation712) to the snapshot pool as an available virtual HCI cluster. If a user applies (operation716) one of the cluster snapshots to create a virtual cluster on the HCI platform, the cluster snapshot count in the snapshot pool is reduced. When the user subsequently releases (operation722) the resource from the HCA platform, snapshot pool adjustment logic724determines how the release of the resource is handled with respect to the snapshot pool. If the cluster count and node counts are between the minimum and maximum thresholds specified by the parameters illustrated inFIG.6, the released resource may cause the pool resource adjustment logic to revert (operation714) the cluster snapshot corresponding to the release cluster to the snapshot pool. If, however, the node snapshot count is below the minimum node count and the cluster snapshot count exceeds the cluster maximum snapshot, the release of the cluster resource in operation724may result in node snapshots, rather than the cluster snapshot, being reverted to the snapshot pool. A similar reversion to node snapshots may occur (operation713) following the join (operation712) of a new node cluster if the same conditions apply, i.e., if the node snapshot count is below the minimum and the cluster snapshot count exceeds the maximum cluster count. In addition, if the node snapshot count and the cluster snapshot count both exceed their respective maximum values, the release of the resource may result in the termination (operation730) of the cluster resource without altering the snapshot pool.

After a snapshot is reverted to the snapshot pool, the snapshot may undergo a resource check in operation718and, if the resource check passes, the snapshot may be permitted to rejoin (operation720) the snapshot pool. If the resource check fails, the cluster may be terminated in operation730.