ELL 887 - CLOUD COMPUTING

Fundamental Cloud Architecture

 2

Outline
 The following are the more common foundational cloud architecture
models, each exemplifying a common usage and characteristics of
contemporary cloud based environments:
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 3

Outline
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 4

Workload Distribution Architecture

• IT resources can be horizontally scaled via the addition of one or more IT
resources and a load balancer that provides runtime logic capable of evenly
distributing the workload among the available IT resources.
• The resulting workload distribution architecture reduces both IT resource
over-utilization and under-utilization to an extent dependent upon the
sophistication of the load balancing algorithm.
• This foundational architectural model can be applied to any IT resource, with
workload distribution commonly carried out in support of distributed virtual
servers, cloud storage devices and cloud services.
• Load balancing systems applied to specific IT resources provide specialized
variations of this architecture that incorporate aspects of load balancing.
 5

Workload Distribution Architecture

• A redundant copy of Cloud Service A is implemented on Virtual Server

B.
• The Load Balancer intercepts cloud services consumer requests and
directs them to both Virtual servers A and B to ensure even workload
distribution.
 6

Workload Distribution Architecture

 In addition to base load balancer mechanisms, and the virtual server and
cloud storage device mechanisms to which load balancing can be applied,
the following mechanisms can also be part of this architecture:
• Audit Monitor: When distributing runtime workloads, the type and geographical
location of the IT resources that process the data can determine whether monitoring
is necessary to fulfil legal and regulatory requirements.
• Cloud Usage Monitor: Various monitors can be involved to carry out runtime
workload tracking and data processing.
• Hypervisor: Workloads between hypervisors and the virtual servers that they host
may require distribution.
• Logical Network Perimeter: The Logical Network Perimeter isolates cloud consumer
network boundaries in relation to how and where workloads are distributed.
• Resource Cluster: Clustered IT resources in active/active mode are commonly used
to support workload balancing between different cluster nodes.
• Resource Replication: This mechanism can generate new instances of virtualized IT
resources in response to runtime workload distribution demand.
 7

Outline
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 8

Resource Pooling Architecture

 A resource pool architecture is based on the use of one or more resource pools in
which identical IT resources are grouped and maintained by a system that
automatically ensures that they remain synchronized.
 Examples of Resource Pools
• Physical Server pools: Composed of networked servers that have been installed with OS
and other necessary programs and/or applications and are ready for immediate use.
• Virtual Server pools: Usually configured using one of several available templates chosen
by the cloud consumer during provisioning.
• Storage or Cloud Storage device pools: Consist of file-based or block-based storage
structures that contain empty and/or filled storage devices.
• Network pools: Composed of different pre-configured network connectivity devices.
• CPU pools: Ready to be allocated to virtual servers and are typically broken down to
individual processing cores
• Memory pools: Pools of physical RAM can be used in newly provisioned physical servers
or to vertically scale physical servers,
 9

Resource Pooling Architecture

 Dedicated pools can be created for each type of IT resources and individual pools
can be grouped into a larger pool in which case each individual pools becomes a
sub-pool.
 Resource pools can become highly complex with multiple pools created for
specific cloud consumers or applications.
 A hierarchical structure can be established to form parent, sibling and nested
pools in order to facilitate the organization of diverse resource pooling
requirements.
 Sibling pools are usually drawn from physically grouped IT resources, as opposed
to IT resources that are spread over different data centers.
 Sibling pools are isolated from one another so that each cloud consumer is only
provided access to its resource pools.
 In the nested pool model larger pools are divided into smaller pools that
individually group the same type of IT resources together.
 After resource 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.
 10

Resource Pooling Architecture

A sample resource pool comprised of 4 sub pools

Pools B and C are sibling pools taken from the larger Pool A which has been allocated to a cloud consumer.
Alternative to taking the IT resources for Pool B and C from a general reserve of IT resources that is shared
throughout the cloud
 11

Resource Pooling Architecture

Nested pools A.1 and A.2 are comprised on the same IT resources as Pool A but in different qualities.
Nested pools are generally used to provision cloud services that need to be rapidly instantiated using the same
type of IT resources with the same configuration settings.
 12

Resource Pooling Architecture

 In addition to cloud storage devices and virtual servers which are commonly
pooled mechanisms, the following mechanisms can also be part of this cloud
architecture:
• Audit Monitor: This mechanism monitors resource pool usage to ensure compliance with
privacy and regulation requirements, especially when pools contain cloud storage
devices or data loaded into memory.
• Cloud Usage Monitor: Various cloud usage monitors are involved in the runtime tracking
and synchronization that are required by the pooled IT resources and any underlying
management systems.
• Hypervisor: The hypervisor mechanism is responsible for providing virtual servers with
access to resource pools, in addition to hosting the virtual servers and sometimes the
resource pools themselves.
• Logical Network Perimeter: The logical network perimeter is used to logically organize
and isolate resource pools.
• Pay-per-use Monitor: Collects usage and billing info on how individual cloud consumers
are allocated and use IT resources from various pools.
• Remote Admin System: Commonly used to interface with backend systems and
programs in order to provide resource pool admin features via a front-end portal.
• Resource Mgmt System: Supports Cloud consumers with the tools and permission
mgmt. options for administering resource pools.
• Resource Replication: Used to generate new instances of IT resources for resource
pools.
 13

Outline
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 14

Dynamic Scalability Architecture

• An architectural model based on a system of pre-defined scaling conditions that
trigger the dynamic allocation of IT resources from resource pools.
• Dynamic allocation enables variable utilization as dictated by usage demand
fluctuations, since unnecessary IT resources are efficiently reclaimed without
requiring manual intervention.
• The automated scaling listener is configured with workload thresholds that
dictate when new IT resources need to be added to the workload processing.
• This mechanism can be provided with logic that determines how many additional
IT resources can be dynamically provided based on the terms of a given cloud
consumer’s provisioning contract.
 15

Types of Dynamic Scaling

 Dynamic Horizontal Scaling
• IT resource instances are scaled out and in to handle fluctuating workloads.
• The automatic scaling listener monitors requests and signals resource replication to
initiate IT resource duplication, as per requirements and permissions.
 Dynamic Vertical Scaling
• IT resource instances are scaled up and down when there is a need to adjust the
processing capacity of a single IT resource.
 Dynamic Relocation
• The IT resource is relocated to a host with more capacity
 16

Dynamic Horizontal Scaling

1. Cloud service consumers are sending requests to a cloud service

2. The automated scaling listener monitors the cloud service to determine if predefined capacity
thresholds are being exceeded
 17

Dynamic Horizontal Scaling

3. The number of requests coming from cloud service consumers increases

4. The workload exceeds the performance thresholds. The automated scaling listener determines the
next course of action based on a predefined scaling policy
5. If the cloud service implementation is deemed eligible for additional scaling the automated scaling
listener initiates the scaling process.
 18

Dynamic Horizontal Scaling

6. The automated scaling listener sends a request to the resource replication mechanism.
7. The resource replication mechanism creates more instances of the cloud service
8. Now that the increased workload has been accommodated the automated scaling listener
resumes monitoring and adding/subtracting IT resources as required.
 19

Dynamic Scalability Architecture

 The dynamic scalability architecture can be applied to a range of IT
resources.
 Besides the core automated scaling listener and resource replication
mechanisms, the following mechanisms can also be used in this form of cloud
architecture:
• Cloud Usage Monitor: Specialized cloud usage monitors can track runtime usage in
response to dynamic fluctuations caused by this architecture.
• Hypervisor: The hypervisor is invoked by a dynamic scalability system to create or
remove virtual server instances, or to be scaled itself.
• Pay-per-use Monitor: Engaged to collect usage cost information in response to
scaling of IT resources.
 20

Outline
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 21

Elastic Resource Capacity Architecture

• The elastic resource capacity architecture is primarily related to the dynamic
provisioning of virtual servers using a system that allocates and reclaims CPUs
and RAM in immediate response to the fluctuating processing requirements of
hosted IT resources.
• Resource pools are used by scaling technology that interacts with the hypervisor
and/or VIM to retrieve and return CPU and RAM resources at runtime.
• The runtime processing of the virtual server is monitored so that additional
processing power can be leveraged from the resource pool via dynamic allocation
before capacity thresholds are met.
• The virtual server and its hosted applications and IT resources are vertically scaled
in response.
• This type of cloud architecture can be assigned so that the intelligent automation
engine script sends its scaling request via the VIM instead of the hypervisor
directly.
• The intelligent automation engine automates admin tasks by executing scripts that
contain workflow logic.
• Virtual servers that participate in elastic resource allocation systems may also
require rebooting in order for the dynamic resource allocation to take effect.
 22

Elastic Resource Capacity Architecture

1. Cloud service consumers are actively sending requests to a cloud service

2. This is monitored by an automated scaling listener
3. An intelligent automation engine script is deployed with workflow logic
4. It is capable of notifying the resource pool using allocation requests
 23

Elastic Resource Capacity Architecture

5. Cloud service consumer request increases

6. Automated scaling listener signals the intelligent automation engine to execute the script
7. The script runs the workflow logic that signals the hypervisor to allocate more IT resources from
the resource pool
8. The hypervisor allocates additional CPU and RAM to the virtual server, enabling increased
workload to be handled
 24

Elastic Resource Capacity Architecture

 Some additional mechanisms that can be included in this cloud architecture
are the following:
• Cloud Usage Monitor: Specialized cloud usage monitors collect resource usage
information on IT resources before during and after scaling, to help define the future
processing capacity thresholds of the virtual servers
• Pay-per-use Monitor: The Pay-per-use monitor is responsible for collecting resource
usage cost information as it fluctuates with elastic provisioning
• Resource Replication: Resource replication is used by this architectural model to
generate new instances of the scaled IT resources.
 25

Outline
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 26

Service Load Balancing Architecture

 The service load balancing architecture can be considered a specialized variation of
the workload distribution architecture that is geared specifically for cloud service
implementations.
 Redundant deployments of cloud services are created with a load balancing system
added to dynamically distribute workloads.
 The duplicate cloud service implementations are organized into a resource pool,
while the load balancer is positioned as either an external or built-in component to
allow the host servers to balance the workloads themselves.
 Depending on the anticipated workload and processing capacity of host server
environments multiple instances of each cloud server implementation can be
generated as part of the resource pool that responds to fluctuating request volumes
more efficiently.
 There are two options for the load balancer:
• Can be positioned independent of the cloud services and their host servers
• Built as part of the application or server’s environment where a primary server with the load
balancing logic can communicate with neighboring servers to balance the workload.
 27

Load Balancer – Option 1

1. The load balancer intercepts messages sent by cloud consumers

2. Forwards them to the virtual servers so that the workload processing is horizontally scaled
 28

Load Balancer – Option 2

1. Cloud service consumer requests are sent to Cloud Service A on Virtual Server A.
2. The cloud service implementation includes in-built load balancing logic that is capable of
distributing requests to neighboring Cloud Service A implementations on Virtual Servers
B and C.
 29

Service Load Balancing Architecture

 Some additional mechanisms that can be included in this cloud
architecture are the following:
• Cloud Usage Monitor: Specialized cloud usage monitors collect resource
usage information on IT resources before, during and after scaling to help
define the future processing capacity thresholds of the virtual servers.
• Pay-per-use Monitor: Responsible for collecting resource usage cost info
as it fluctuates with the elastic provisioning.
• Resource Replication: Resource Replication is sued by the architecture
model to generate new instances of the scaled IT resources.
 30

Outline
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 31

Cloud Bursting Architecture

 The Cloud Bursting Architecture establishes a form of dynamic scaling that scales
or bursts out on-premise IT resources into a cloud whenever predefined capacity
thresholds have been reached.
 The corresponding cloud-based IT resources are redundantly pre-deployed but
remain inactive until cloud bursting occurs.
 After they are no longer required the cloud based IT resources are released and
the architecture bursts in back to the on-premise environment.
 Cloud bursting is a flexible scaling architecture that provides cloud consumers
with the option of using cloud-based IT resources only to meet higher usage
demands.
 The foundation of this architectural model is based on the following:
• The automated scaling listener determines when to redirect requests to cloud-based IT
resources
• Resource replication mechanism is used to maintain synchronicity between on-premise
and cloud-based IT resources in relation to state info.
• Numerous other mechanisms can be used to automate burst in and burst our dynamics
depending primarily on the type of IT resource being scaled.
 32

Cloud Bursting Architecture

1. The automated scaling listener monitors the usage of on-premise Service A and redirects
Service Consumer C’s request to Service A’s redundant implementation in the cloud (Cloud
Service A) one Service A’s usage threshold has been exceeded.
2. A resource replication system is used to keep state management database synchronized.
 33

Outline
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 34

Elastic Disk Provisioning Architecture

• Cloud consumers are commonly charged for cloud-based storage space based on fixed
disk storage allocation, meaning the charges are pre-determined by dish capacity and not
aligned with actual data storage consumption.
1. The cloud consumer requests a virtual
server with 3 150 GB hard drives.
2. The virtual server is provisioned with a
total of 450 GB of disk space.
3. The 450 GB is allocated to the virtual
server by the cloud provider
4. The cloud consumer has not installed
any S/W yet meaning that the actual
used space is currently 0GB.
5. Because the 450GB are already
allocated and reserved for the cloud
consumer, it will be charged for 450 GB
of disk usage as of the point of
allocation.
 35

Elastic Disk Provisioning Architecture

• The Elastic Disk Provisioning architecture establishes a dynamic storage provisioning
system that ensures that the cloud consumer is granularly billed for the exact amount of
storage that it actually uses.
• The system uses thin provisioning technology for the dynamic allocation of storage space
and is further supported by runtime usage monitoring to collect accurate usage data for
billing purposes.
1. The cloud consumer requests a virtual
server with 3 150 GB hard drives.
2. The virtual server is provisioned by this
architecture with a total of 450 GB of
disk space.
3. The 450 GB are set as the maximum
disk usage that is allowed for this virtual
server, although no physical disk space
has been allocated yet.
4. Because the allocated disk space is
equal to the actual usad space
(currently 0) the cloud consumer is not
charged for any disk space usage
 36

Elastic Disk Provisioning Architecture

• Thin provisioning software is installed on virtual servers that process dynamic storage
allocation via the hypervisor
• Pay-per-use Monitor tracks and reports granular billing related disk usage data

1. A request is received from a cloud

consumer and the provisioning of a
new virtual server instance begins
2. As part of the provisioning process the
hard disks are chosen as dynamic or
thin provisioned disks
3. The hypervisor calls a dynamic disk
allocation component to create thin
disks for the virtual server.
4. Virtual server disks are created via thin
provisioning program and saved in a
folder of near zero size. The size grows
as applications are installed and
additional files are copied onto the
virtual server.
5. The pay-per-use monitor tracks the
actual dynamically allocated storage for
billing purposes.
 37

Elastic Disk Provisioning Architecture

 The following mechanisms can be included in this architecture in addition to
the cloud storage device, virtual server, hypervisor and pay-per-use monitor:
• Cloud Usage Monitor: Specialized cloud usage monitors can be used to track and
log storage usage fluctuations.’
• Resource Replication: Part of the elastic disk provisioning system when conversion
of dynamic thin-disk storage into static thick-disk storage is reqd.
 38

Outline
• Workload Distribution Architecture
• Resource Pooling Architecture
• Dynamic Scalability Architecture
• Elastic Resource Capacity Architecture
• Service Load Balancing Architecture
• Cloud Bursting Architecture
• Elastic Disk Provisioning Architecture
• Redundant Storage Architecture
 39

Redundant Storage Architecture

• Cloud Storage devices are occasionally subject to failure and disruptions that
are caused by network connectivity issues, general hardware failures or security
breaches.
• A compromised cloud storage device reliability can have a ripple effect and
cause impact failure across all of the services, application and infra components
that are reliant on its availability.
• The redundant storage architecture introduces a secondary duplicate cloud
storage device as part of a failover system that synchronizes its data with the
data in the primary cloud storage devices.
• A storage service gateway diverts cloud consumer requests to the secondary
device whenever the primary device fails.
• The storage service gateway is a component that acts as the external interface
to the cloud storage services and is capable of automatically redirecting the
cloud consumer requests whenever the location of the request data has
changed.
 40

Redundant Storage Architecture

1. The primary cloud storage device is routinely replicated to the secondary cloud storage
device.
2. The primary storage becomes unavailable and the storage service gateway forwards the
cloud consumer requests to the secondary storage device.
3. The secondary storage device forwards the requests to LUNs, allowing the cloud consumer
to continue using their data.
Logical Unit Number (LUN) is a logical drive that represents a partition of physical drive.
 41

Redundant Storage Architecture

 The cloud architecture relies on a storage replication system that keeps the private cloud
storage device synchronized with the secondary cloud storage devices.
• Storage replication is a variation of resource replication used to synchronously or asynchronously
replicate data from a primary to a secondary storage device.
• It can be used to replicate partial and entire LUNs

Storage replication is used to keep the redundant storage device

synchronized with the primary storage device.
 42

Redundant Storage Architecture

• Cloud providers may also locate secondary cloud storage devices in a different
geographical region than the primary cloud storage device, usually for economic
reasons.
• However this can introduce legal concerns for some types of data
• The location of the secondary cloud storage device can dictate the protocol and
method used for synchronization, as some replication transport protocols have distance
restrictions.
• Some cloud providers use storage devices with dual array and storage controllers to
improve device redundancy and place secondary storage devices in a different physical
location for cloud balancing and disaster recovery purposes.
• In this case cloud providers may need to lease a network connection via a 3rd party
cloud provider in order to establish replication between the devices.
 43

Readings
• Cloud Computing: Concepts, Technology & Architecture. Chapter 11