Resource Pooling (Erl, Naserpour)
How can IT resources be organized to support dynamic sharing?
ProblemWhen sharing identical IT resources for scalability purposes, it can be error-prone and burdensome to keep them fully synchronized on an on-going basis.
SolutionAn automated synchronization system is provided to group identical IT resources into pools and to maintain their synchronicity.
ApplicationResource pools can be created at different sizes and further organized into hierarchies to provide parent and child pools.
MechanismsAudit Monitor, Cloud Storage Device, Cloud Usage Monitor, Hypervisor, Logical Network Perimeter, Pay-Per-Use Monitor, Remote Administration System, Resource Management System, Resource Replication, Virtual Server
Compound PatternsBurst In, Burst Out to Private Cloud, Burst Out to Public Cloud, Elastic Environment, Infrastructure-as-a-Service (IaaS), Multitenant Environment, Platform-as-a-Service (PaaS), Private Cloud, Public Cloud, Resilient Environment, Software-as-a-Service (SaaS)
When assembling identical IT resources for sharing and scalability purposes (such as when applying the Shared Resources and Dynamic Scalability patterns), the IT resources need to carefully be kept synchronized so that no one IT resource differs from another.
Manually establishing and maintaining the level of required synchronicity across collections of shared IT resources is challenging, effort-intensive and, most importantly, error-prone. Variances or disparity between shared IT resources can lead to inconsistent runtime behavior and cause numerous types of runtime exceptions.
Identical IT resources are grouped into resource pools and maintained by a system that automatically ensures they remain synchronized. The following items are commonly pooled:
- physical servers
- virtual servers
- cloud storage devices
- internetwork and networking devices
- memory (RAM)
Dedicated pools can be created for each of these items, or respective pools can be further grouped into a larger pool (in which case each individual pool becomes a sub-pool).
Figure 1 - A sample resource pool comprised of four sub-pools of CPUs, memory, cloud storage devices, and virtual network devices.
As stated previously, this pattern is primarily applied in support of the Shared Resources and Dynamic Scalability patterns in order to establish a reliable system of shared IT resource synchronization. The Resource Pool pattern itself can be further supported by the application of the Resource Reservation pattern.
Provided here are common examples of resource pools:
Physical server pools composed of ready-to-go, networked servers installed with operating systems and any other necessary programs or applications.
Virtual server pools are usually configured using templates that cloud consumers can choose from. For example, a pool of mid-tier Windows servers with 4 GB of RAM or a pool of low-tier Ubuntu servers with 2 GB of RAM.
Storage pools (or cloud storage device pools) that consist of file-based or block-based storage structures. Storage pools can contain empty or filled cloud storage devices. Often storage resource pools will take advantage of LUNs.
Internetwork pools composed of different, preconfigured network connectivity devices. For example, a pool of virtual firewall devices or physical network switches can be created for redundant connectivity, load balancing, or link aggregation.
CPU pool ready to be allocated to virtual servers. These are often broken down into individual processing cores (as opposed to pooling entire CPUs).
Pools of physical RAM that be can used in newly provisioned physical servers or to vertically scale physical servers.
Resource pools can grow to become complex, with multiple pools created for specific cloud consumers or applications. To help with the organization of diverse resource pools, a hierarchical structure can be established to create parent, sibling, and nested pools.
Sibling resource pools are normally drawn from the same collection of physical IT resources (as opposed to IT resources spread out over different data centers) and are isolated from one another so that each cloud consumer is only provided access to its respective pool.
Figure 2 - Pools B and C are sibling pools taken from the larger Pool A that has been allocated to a cloud consumer. This is an alternative to taking the IT resources for Pool B and Pool C from a general reserve of IT resources that is shared throughout the cloud.
In the nested pool model, larger pools are divided into smaller pools of the same kind. Nested pools can be used to assign resource pools to different departments or groups within the same cloud consumer organization.
Figure 3 - Nested Pools A.1 and Pool A.2 are comprised of the same IT resources as Pool A, but in different quantities. Nested pools are generally used to provision cloud services that are rapidly instantiated using the same kind of IT resources with the same configuration settings.
After resources pools have been defined, multiple instances of IT resources from each pool can be created to provide an in-memory pool of "live" IT resources.
NIST Reference Architecture Mapping
This pattern relates to the highlighted parts of the NIST reference architecture, as follows: