Boot path and production path accessible storage system

The concepts described herein include a storage access system including two access paths using different path configurations resulting in the ability to do a two part boot from the same boot memory. The two storage access paths address the boot memory using a globally unique identifier. The first storage path is a slower path that transfers instructions from the boot memory to configure the second storage path used to transfer the operating system from the boot memory.

TECHNICAL FIELD

Aspects of the present disclosure relate to computing devices and, in particular, to a storage access system using an internet small computer systems interface (iSCSI) target over a high speed network topology and method of operating the same.

BACKGROUND

Production data communication interfaces sometimes lack sufficient on-board programmable read-only memory for machines to boot using the internet small computer system interface. As a result, typical systems use a multi-stage boot process. In the first stage a small boot kernel, capable of configuring a production data communication interface and internet small computer system interface, loads from a local device. In the second stage the full operating system is loaded using the internet small computer system interface over the production data communication path from another storage device. This multi-stage process requires systems to maintain multiple storage devices for the sole purpose of booting the machine.

BRIEF SUMMARY

In one embodiment presently described is a storage access system comprising one or more data processors and a boot memory which itself comprises a boot kernel comprising first instructions and an operating system comprising second instructions. The storage access system further comprises a non-transitory computer readable storage medium containing instructions that when executed on the one or more data processors, cause the one or more data processors to perform actions including: receiving a request to create a virtual machine; creating an instance of the virtual machine, wherein the virtual machine comprises initial instructions, and wherein the initial instructions facilitate initiating and enabling a boot path from the virtual machine to the boot memory; executing the initial instructions to initiate the boot path, configure the boot path, and enable the boot path; transferring, using the boot path, the boot kernel to the virtual machine from the boot memory; loading the boot kernel on the virtual machine; executing the first instructions of the boot kernel, wherein executing the first instructions causes configuring a production path between the virtual machine and the boot memory and enabling the production path; transferring, using the production path, the operating system to the virtual machine from the boot memory; loading the operating system on the virtual machine; executing the second instructions on the virtual machine; detecting that the production path has been successfully configured; and in response to the detecting, disabling the boot path. Another embodiment of the storage access system further comprises an action of detecting a production path failure or the virtual machine executing the initial instructions, and in response to the detecting, enables the boot path. A further embodiment of the storage access system further comprises a load balancer comprising a multiplex input/output (MPxIO) device that enables the virtual machine to be accessed through multiple storage access paths from a single operating system instance. An additional embodiment of the storage access system further comprises actions that connect the boot path to the boot memory using a single global user interface id and/or connect the production path to the boot memory using a single global user interface id. And yet a different embodiment of storage access system is wherein the boot path and the production path conform to an internet small computer system interface, wherein the boot path conforms to a Gb Ethernet protocol, or wherein the production path conforms to an Infiniband protocol.

Yet another embodiment presently described is a storage access method, the method comprising: executing, using one or more data processors, from a non-transitory computer readable storage medium, instructions that when executed on the one or more data processors, cause the one or more data processors to perform actions including: receiving a request to create a virtual machine; creating an instance of the virtual machine, wherein the virtual machine comprises initial instructions, and wherein the initial instructions facilitate initiating and enabling a boot path from the virtual machine to a boot memory. The boot memory comprises: a boot kernel comprising first instructions and an operating system comprising second instructions. Further performed actions include: executing the initial instructions to initiate the boot path, configure the boot path, and enable the boot path; transferring, using the boot path, the boot kernel to the virtual machine from the boot memory; loading the boot kernel on the virtual machine; and executing the first instructions of the boot kernel. Executing the first instructions causes: configuring a production path between the virtual machine and the boot memory; and enabling the production path. Further actions include: transferring, using the production path, the operating system to the virtual machine from the boot memory; loading the operating system on the virtual machine; executing the second instructions on the virtual machine; detecting that the production path has been successfully configured; and in response to the detecting, disabling the boot path. Another embodiment of the storage access method further comprises an action of detecting a production path failure or the virtual machine executing the initial instructions, and in response to the detecting, enables the boot path. A different embodiment of the storage access method further comprises a load balancer comprising a multiplex input/output (MPxIO) device that enables the virtual machine to be accessed through multiple storage access paths from a single operating system instance. An additional embodiment of the storage access method further comprises actions that connect the boot path to the boot memory using a single global user interface id and/or connect the production path to the boot memory using a single global user interface id. And yet a different embodiment of storage access method is wherein the boot path and the production path conform to an internet small computer system interface, wherein the boot path conforms to a Gb Ethernet protocol, or wherein the production path conforms to an Infiniband protocol.

A further embodiment presently described is a non-transitory computer-readable medium having sets of instructions stored thereon for storage access, comprising: executing, using one or more data processors, from a non-transitory computer readable storage medium, instructions that when executed on the one or more data processors, cause the one or more data processors to perform actions including: receiving a request to create a virtual machine; creating an instance of the virtual machine, wherein the virtual machine comprises initial instructions, and wherein the initial instructions facilitate initiating and enabling a boot path from the virtual machine to a boot memory. The boot memory comprises: a boot kernel comprising first instructions and an operating system comprising second instructions. Further performed actions include: executing the initial instructions to initiate the boot path, configure the boot path, and enable the boot path; transferring, using the boot path, the boot kernel to the virtual machine from the boot memory; loading the boot kernel on the virtual machine; and executing the first instructions of the boot kernel. Executing the first instructions causes: configuring a production path between the virtual machine and the boot memory; and enabling the production path. Further actions include: transferring, using the production path, the operating system to the virtual machine from the boot memory; loading the operating system on the virtual machine; executing the second instructions on the virtual machine; detecting that the production path has been successfully configured; and in response to the detecting, disabling the boot path. Another embodiment of the storage access method further comprises an action of detecting a production path failure or the virtual machine executing the initial instructions, and in response to the detecting, enables the boot path. A different embodiment of the non-transitory computer-readable medium having sets of instructions stored thereon for storage access further comprises a load balancer comprising a multiplex input/output (MPxIO) device that enables the virtual machine to be accessed through multiple storage access paths from a single operating system instance. An additional embodiment of the non-transitory computer-readable medium having sets of instructions stored thereon for storage access further comprises actions that connect the boot path to the boot memory using a single global user interface id and/or connect the production path to the boot memory using a single global user interface id. And yet a different embodiment of the non-transitory computer-readable medium having sets of instructions stored thereon for storage access is wherein the boot path and the production path conform to an internet small computer system interface, wherein the boot path conforms to a Gb Ethernet protocol, or wherein the production path conforms to an Infiniband protocol.

DETAILED DESCRIPTION

Certain aspects and embodiments of this disclosure are provided below. Some of these aspects and embodiments may be applied independently and some of them may be applied in combination as would be apparent to those of skill in the art. In the following description, for the purposes of explanation, specific details are set forth in order to provide a thorough understanding of embodiments described. However, it will be apparent that various embodiments may be practiced without these specific details. The figures and description are not intended to be restrictive.

Furthermore, embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description languages, or any combination thereof. When implemented in software, firmware, middleware or microcode, the program code or code segments to perform the necessary tasks (e.g., a computer-program product) may be stored in a computer-readable or machine-readable medium. A processor(s) may perform the necessary tasks.

Embodiments of the present disclosure provide a storage access system for managing a boot path and a production path to provide boot access capabilities to a virtual machine configured in a virtual computing environment.

The proliferation of virtualization techniques has been expanded into computer cluster designs due at least in part to the ability of multiple virtual resources to be created and deleted on demand, and to share workload with one another such that enhanced economies of scale may be achieved. One particular virtualization technique involves logical partitioning of one or more hardware resources of a physical computing device, such as that provided by single root input/output virtualization (SR-IOV). SR-IOV allows different virtual machines (VMs) to share hardware resources, such as a PCI Express interface often found on currently available physical (e.g., bare metal) computing devices.

Nevertheless, it has been projected that introducing SR-IOV into computing cluster designs may precipitate a proliferation of virtualized storage devices by numerous users. For example, current trends in the computing industry have evolved to provide computing environments in which computing resources are leased, rather than purchased by users (e.g., tenants). SR-IOV provides the tenant with additional management tools that could expand the usability of virtualized storage devices to the point where they become an integral component of many new implementations.

Leased data storage is often provided by logical domains (LDoms) in which each LDom comprises a fully functioning virtual machine (VM). These LDoms typically include an operating system (operating system) that can be started, stopped, configured, and rebooted independently of other LDoms, such as by a tenant who desires to manage the operation of the LDom independently of an administrator of the computing cluster. In some cases, a running LDom can be dynamically reconfigured to add or remove CPUs, RAM, or I/O devices without requiring a reboot operation. In some embodiments the LDom or virtual machine include a load balancer that controls and balanced the data traffic to and from the LDom.

The implementation of LDoms have provided an efficient, customizable solution to virtualized data storage. Nevertheless, the implementation of such a virtualized architecture may present several problems. High throughput or “production” network technologies, such as Infiniband (TB), IEEE 1394, and the like, often do not have interfaces with sufficient programmable read only memory to enable booting of the operating system associated with an LDom. Most conventional solutions have involved a multi-stage boot process where a boot kernel is initially loaded from a local/accessible device, which is then used to configure a high speed data channel interface to load the operating system from a second device. The boot kernel is a mini operating system for the virtual machine and it initiates and enable input/output and other functionality of the VM. This multi-stage boot process conventionally requires the operating system utilities to maintain multiple storage devices: one for the boot kernel and another for the full operating system. This problem is minimized in the present application by using a first communication channel to partially boot the virtual machine with a boot kernel with executable instructions that initiates and enables a high bandwidth communication channel used to finish loading the full operating system from the same storage device as the boot kernel. The high bandwidth or high threshold channel thus becomes the “production” channel used for data transfer during normal operations.

FIGS. 1A, 1B and 1Cillustrate an example storage access system100according to the teachings of the present disclosure. The storage access system100addresses problems with conventional storage access systems among other benefits and solutions. The storage access system100comprises a computing device125as well as a storage array130with two communications paths between them. The first communication path is a boot path110such as a Gb Ethernet channel or the like as the concept described is not so limited and includes any boot capable communication protocol. The second communication path is a production path112such as an Infiniband channel or the like as the concepts described are not so limited and include any high speed, or high throughput communication protocol.

Referring now toFIG. 1Ashowing only the boot path110configured. Boot path110may be used for loading a boot kernel on the virtual machine120from boot memory140, a mini operating system that, among other functions, will initiate and enable the production path112. Once the virtual machine120is completely booted, continuous access to boot memory140over the boot path110could possibly create network bandwidth saturation issues resulting in a denial of access for managing resources in the virtual computing environment when numerous virtual machines120are deployed. That is, the boot path110may not have the capability of providing sufficient bandwidth when there are multiple virtual machines120deployed. Therefore, any traffic over the boot path110should be temporary and limited to those operations that may not be easily performed by the production path112. The production path is shown in dashed lines inFIG. 1A. That is because until the boot kernel is installed and running on the virtual machine120, the production path112is not enabled to be operational and is not recognized by the boot environment of the virtual machine.

While the boot path110enables the virtual machine120to boot from a boot kernel, it may not provide sufficient throughput to load the full operating system. Thus, as shown inFIG. 1B, the production path112is enabled by the boot kernel in the virtual machine120to provide the production path112to load the full operating system from boot memory140to complete the full boot of the virtual machine120. During this time, both the boot path110and the production path112are enabled as shown inFIG. 1B.

Referring now toFIG. 1C, showing the production mode of the storage access system100. Here the boot path110is shown as a dotted line indicating that it is disabled during normal production mode to prevent network bandwidth saturation issues resulting in a denial of access for managing resources in the virtual computing environment. The production path112is fully enabled and operational. However, should the virtual machine120need to reboot or enter boot mode for any reason, production path112will no longer be enabled or operational until the boot kernel has initiated and enabled it again.

The storage controller135may control the operation of the production path112and boot path110. The load balancer115may also control the operation of the production path112and the boot path110. In general, the load balancer115distributes workloads across multiple storage access paths, such as the production path112and boot path110, and may be used to optimize resource usage, maximize throughput, minimize response time, and avoid overload of any single storage access path. The load balancer115can operate to effectively disable either path. Additionally, the use of multiple storage access paths instead of a single storage access path may increase reliability and availability through redundancy.

In one embodiment, the load balancer115comprises a multiplex input/output (MPxIO) device or software module that enables a storage device to be accessed through multiple host controller interfaces from a single operating system instance. The MPxIO architecture helps protect against outages due to I/O controller failures. Thus, should one storage controller fail, the MPxIO device automatically switches to an alternate controller so that service is maintained.

The MPxIO load balancer does not need to use the same transport medium (e.g. Ethernet, IB, etc.). That is, the MPxIO load balancer provides for mixing of storage access paths that conform to different protocols. Additionally, the MPxIO load balancer presents as a single globally unique identifier (GUID). In this manner, the MPxIO may balance the traffic between the boot path110and the production path112and/or alternatively select one of storage access paths for handling all of the traffic on each.

The computing components of a virtual computing environment solution may include one or more servers, data storage components, networking equipment, and software for managing the integrated components. To assist in the scalability, management and sharing of resources, particularly in large computing system environments, virtual computing environments may involve a pool of server, storage and networking capacities, typically virtualized, that can shared by multiple applications. One particular example of a virtualized computing environment includes an Oracle™ Supercluster line of Engineered Systems from Oracle Corporation, which is headquartered in Redwood City, Calif.

Example hardware resources of a virtual computing environment may include any type of hardware that provides physical resources for the virtual computing environment while the virtual resources include logical entities. such as virtual machines120. Virtual resources may also include logical configuration constructs, such as storage partitions (e.g., tenant partitions), port groups, virtual private clouds, virtual local area networks (LANs), private virtual data centers (PVDCs), that may be individually allocated to one or more users commonly referred to as tenants.

In one embodiment, the virtual machine may comprise guest logical domains (LDoms) as specified by Oracle virtual machine Server for SPARC™ server virtualization and partitioning system from Oracle Corporation, which is headquartered in Redwood City, Calif. In general, each LDom is essentially a full virtual machine that is configurable with one or more characteristics, redundancy level (e.g., redundant array of inexpensive disks (RAID) settings, etc.), latency time, failover procedures, and the like. LDoms can be securely live migrated between servers while running. Operating systems (operating system s) running inside LDoms can be started, stopped, and rebooted independently of other LDoms. Additionally, a running LDom can be dynamically reconfigured to add or remove CPUs, RAM, or I/O devices without requiring a reboot.

Each guest LDom may be configured as an I/O domain with at least one local Infiniband (IB) channel adapter for providing the production path112and at least one Ethernet adapter for providing the boot path110. Additionally, management network access arrives either via the local Ethernet adapter or one or more virtual networks provided from a service LDom of the Oracle virtual machine Server for SPARC™ server virtualization and partitioning system. Additionally, each guest LDom may have storage area network (SAN) access to storage on the file system (e.g., ZFS file system) via iSCSI over both the boot path110(e.g., Gb Ethernet interface) as well as the production path112(e.g., IB interface (IPoIB or iSER)). Thus, the boot path110provides for installation of boot kernels in guest LDoms, while iSCSI over IB provides for operating system downloading and access to virtual storage elements and additional storage as may be implemented in each LDom.

Some storage paths using the iSCSI protocol typically have throughput rates of approximately 1 Gigabit per second, while other high speed, high threshold (production) paths, such as those using the Infiniband (IB) protocol often have throughput rates of over 25 Gigabits per second. Thus, the production path112may be provided to take over communication with the virtual machine120once the boot path110has successfully pre-booted the virtual machine120.

Any suitable communication protocol for the production path112may be used. Examples of suitable communication protocols include an Infiniband protocol and an Institute of Electrical and Electronics Engineers (IEEE) 1394 protocol. In one embodiment, the production path112conforms to the IB protocol. The IB protocol features high throughput while maintaining relatively low latency using a mesh type circuit topology. Also, the IB protocol may be utilized as either a direct, or switched interconnect between servers and storage systems, as well as an interconnect between storage systems.

Referring now in more detail toFIG. 2, a block diagram200of the computing device125according to one aspect of the present disclosure. Although blocks are shown drawn insidge the confines of the computing device125—any number of all blocks encompassed may be standalone device interconnected with the other blocks in computing device125. According to one aspect, the computing device125also includes a graphical user interface (GUI)206displayed on a display208, such as a computer monitor for displaying data. The computing device125may also include an input device210, such as a keyboard or a pointing device (e.g., a mouse, trackball, pen, or touch screen) to enter data into or interact with the GUI206. According to one aspect, the storage controller135includes executable instructions or modules.

The storage array130includes volatile media, nonvolatile media, removable media, non-removable media, and/or another available medium. By way of example and not limitation, non-transitory storage array130comprises computer storage media, such as non-transient storage memory, volatile media, nonvolatile media, removable media, and/or non-removable media implemented in a method or technology for storage of information, such as computer readable instructions, data structures, program modules, or other data. The storage array130can be standalone device in a typical system.

A user interface module212displays information associated with operation of the virtual computing environment116and the load balancer115, which is used to generate the boot path110and production storage access path112. For example, the user interface module212may display some, most, or all resources that are available on the computing device125, and may receive user input for managing those resources. Additionally, the user interface module212may receive user input for managing the operation of the load balancer115and displaying information associated with the operational status of the load balancer115and any boot capable storage access paths110or production paths112generated by the load balancer115. For example, the user interface module212may display detailed information about boot memory140and any error conditions that may be associated with boot memory140.

A load balancer management module216manages the operation of the load balancer115. For example, the load balancer management module216may issue instructions to the load balancer115configure a production path112to a newly instantiated virtual machine120, and disable the boot path110once the production path112has been successfully configured. Additionally, the load balancer management module216may communicate with the load balancer115to receive notifications regarding the operational status of the storage paths. For example, in the event that the production path112is unable to be properly configured on a newly instantiated virtual machine120, the load balancer115may transmit a notification message indicating this failure condition so that the load balancer management module216may take appropriate remedial actions.

In one embodiment, the load balancer management module216may communicate with the load balancer115to load an operating system on the LDom and disable the boot path110once the operating system has been loaded and started on the LDom. Control over how the boot path110is disabled may be accomplished in any suitable manner. For example, the load balancer management module216may issue a request to the load balancer115to boot the virtual machine120using the boot path110, and upon a response from the load balancer115indicating that the virtual machine120has been successfully booted and both the boot path110and production path112successfully started, issue a second request instructing that the load balancer115disable the boot path110. As another example, the load balancer management module216may issue a request to the load balancer115to boot the virtual machine120using the boot path110, and after a specified period of elapsed time, issue a second request instructing that the load balancer115disable the boot path110. In this case, the load balancer115may be configured to automatically reject the second request in the event that the virtual machine120has not been successfully booted or that both the boot path110and production path112have not been successfully started. As such, the load balancer115may issue a response indicating that the boot path110was not able to be disabled so that the load balancer management module216may take further remedial action. A boot path adapter222is configurable to provide an interface to the virtual machine120for the boot path110. Either the load balancer115or the load balance manager216can disable the interface to or the boot path adapter222—essentially turning off communication over the boot path110. A production path adapter220is configurable to provide an interface to the virtual machine120for the production path112. Either the load balancer115or the load balance manager216can disable the interface to the production path adapter220—essentially turning off communication over the production path112.

It should be appreciated that the modules described herein are provided only as examples, and that the computing device125may have different modules, additional modules, or fewer modules than those described herein. For example, one or more modules as described inFIG. 2may be combined into a single module.

FIG. 3illustrates an example process that may be performed by the storage access system100to generate and manage virtual machine120to provide storage access to a client of the virtual machine120according to one embodiment of the present disclosure.

Initially at block302, the computing device125receives a request to instantiate a new virtual machine120. At block304the computing device125creates a new instance of the virtual machine120in response to that request. The new instance is a software object defining the virtual machine120and its functionality, including initial instructions. The virtual machine120functionality includes the ability to start the process to boot the virtual machine up by executing the initial instructions. This includes configuring and enabling the boot path110to communicate between the virtual machine and the boot memory140.

At block306, once the boot path110has been enabled the virtual machine120will execute initial instructions to initiate transferring a boot kernel from the boot memory140to the virtual machine. The boot kernel is software object containing executable instructions, that when executed, will further configure the virtual machine and additional functionality.

At block308, the virtual machine120executes the instructions in the boot kernel to configure and enable the production path112(e.g., an Infiniband path) and enable other functionality of the virtual machine120. In one particular embodiment the iSCSI is initiated to provide access to the underlying virtual machine120via the production path112.

At block310, if the production path112configuration is successful, processing continues at block311; otherwise processing continues at block314in which one or more remedial actions may be taken to correct the error condition such as described herein above. At block311the virtual machine120requests the full operating system from the boot memory140using the production path112. The full operating system comprises instructions that enable the full functionality of the virtual machine120. Once the virtual machine120receives the full operating system it installs it and begins executing those instructions so that it is fully capable of performing all of its functions. At this point the load balancer115and load balancer manager216are fully enabled on the virtual machine120.

At block312, in one embodiment, virtual machine120instructs the load balancer115to configure both the boot path110and the production path112to connect with the boot memory140with a single GUID. Without the single GUID, the configuration of the boot path110and the production path112may be more complex, and hence error prone, because should a boot operation be attempted through a private IP address configured on a first of multiple redundant controllers that has failed, a second controller may not have easy access to the virtual machine120. Thus, the single GUID configured by the load balancer115eliminates the need for multiple attempts using different IP addresses as would otherwise be required without it.

At block316, load balance manager216or the load balancer115disable the boot path110such that all further access to the boot memory140is through the production path112. The load balancer manager216or the load balancer115can disable the boot path in numerous ways including disabling the virtual boot path virtual interface or the boot path adapter222. In the event that the production path112fails for any reason, the load balancer115, load balance manager216or the virtual machine will re-enable the boot path110. At block318the boot path110is re-enabled by the load balancer115, the load balance manager216, or the virtual machine120so that boot processing can continue at block306.

During operation of the virtual machine120, a request may be received to re-boot the virtual machine120at block318or the virtual machine120may start executing the initial instructions—indicating it is in boot mode. If so, processing continues at block322; otherwise, processing continues at block316in which access to the virtual machine120is continually provided through the production storage access path112.

The previous blocks may be repeatedly performed for instantiation of booting of additional virtual machine120. Nevertheless, when use of the storage access system100is no longer needed or desired, the process ends.

AlthoughFIG. 3describes one example of a process that may be performed by the storage access system100, the features of the disclosed process may be embodied in other specific forms without deviating from the spirit and scope of the present disclosure. For example, the storage access system100may perform additional, fewer, or different operations than those operations as described in the present example.

The description above includes example systems, methods, techniques, instruction sequences, and/or computer program products that embody techniques of the present disclosure. However, it is understood that the described disclosure may be practiced without these specific details.

In the present disclosure, the methods disclosed may be implemented as sets of instructions or software readable by a device. Further, it is understood that the specific order or hierarchy of blocks in the methods disclosed are instances of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the method can be rearranged while remaining within the disclosed subject matter. The accompanying method claims present elements of the various blocks in a sample order, and are not necessarily meant to be limited to the specific order or hierarchy presented.

For example,FIG. 4is a block diagram illustrating an example of a host or computer system400which may be used in implementing the embodiments of the present disclosure. The computer system (system) includes one or more processors402-406. Processors402-406may include one or more internal levels of cache (not shown) and a bus controller or bus interface unit to direct interaction with the processor bus412. Processor bus412, also known as the host bus or the front side bus, may be used to couple the processors402-406with the system interface414. System interface414may be connected to the processor bus412to interface other components of the system400with the processor bus412. For example, system interface414may include a memory controller418for interfacing a main memory416with the processor bus412. The main memory416typically includes one or more memory cards and a control circuit (not shown). System interface414may also include an input/output (I/O) interface420to interface one or more I/O bridges or I/O devices with the processor bus412. One or more I/O controllers and/or I/O devices may be connected with the I/O bus426, such as I/O controller428and I/O device460, as illustrated.

I/O device460may also include an input device (not shown), such as an alphanumeric input device, including alphanumeric and other keys for communicating information and/or command selections to the processors402-406. Another type of user input device includes cursor control, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to the processors402-406and for controlling cursor movement on the display device.

System400may include a dynamic storage device, referred to as main memory416, or a random access memory (RAM) or other computer-readable devices coupled to the processor bus412for storing information and instructions to be executed by the processors402-406. Main memory416also may be used for storing temporary variables or other intermediate information during execution of instructions by the processors402-406. System400may include a read only memory (ROM) and/or other static storage device coupled to the processor bus412for storing static information and instructions for the processors402-406. The system set forth inFIG. 4is but one possible example of a computer system that may employ or be configured in accordance with aspects of the present disclosure.

According to one embodiment, the above techniques may be performed by computer system400in response to processor402-406executing one or more sequences of one or more instructions contained in main memory416. These instructions may be read into main memory416from another machine-readable medium, such as a storage device. Execution of the sequences of instructions contained in main memory416may cause processors402-406to perform the process blocks described herein. In alternative embodiments, circuitry may be used in place of or in combination with the software instructions. Thus, embodiments of the present disclosure may include both hardware and software components.

As noted, the computer-readable medium may include transient media, such as a wireless broadcast or wired network transmission, or storage media (that is, non-transitory storage media), such as a hard disk, flash drive, compact disc, digital video disc, Blu-ray disc, or other computer-readable media. The computer-readable medium may be understood to include one or more computer-readable media of various forms, in various examples.

Where components are described as performing or being “configured to” perform certain operations, such configuration can be accomplished, for example, by designing electronic circuits or other hardware to perform the operation, by programming programmable electronic circuits (e.g., microprocessors, or other suitable electronic circuits) to perform the operation, or any combination thereof.