Cloud Computing Mechanisms Overview
Cloud Computing Mechanisms Overview
UNIT-3
Cloud Mechanisms Overview
Technology mechanisms represent well-defined IT artifacts that are established within an IT industry
and commonly distinct to a certain computing model or platform. The technology-centric nature of cloud
computing requires the establishment of a formal level of mechanisms to be able to explore how a given
pattern can be applied differently via alternative combinations of mechanism implementations. This not
only standardizes proven practices and solutions in a design pattern format, it further adds
standardization to pattern application options. It is for this reason that the mechanisms listed on this site
have been defined for the cloud computing design patterns catalog.
The following mechanisms are defined:
The automated scaling listener mechanism is a service agent that monitors and tracks
communications between cloud service consumers and cloud services for dynamic scaling
purposes. Automated scaling listeners are deployed within the cloud, typically near the
firewall, from where they automatically track workload status information.
Workloads can be determined by the volume of cloud consumer-generated requests or via
back-end processing demands triggered by certain types of requests. For example, a small amount of
incoming data can result in a large amount of processing.
Automated scaling listeners can provide different types of responses to workload fluctuation
conditions, such as:
Automatically scaling IT resources out or in based on parameters previously defined by the cloud
consumer (commonly referred to as auto-scaling).
Automatic notification of the cloud consumer when workloads exceed current thresholds or fall
below allocated resources. This way, the cloud consumer can choose to adjust its current IT
resource allocation.
Different cloud provider vendors have different names for service agents that act as automated scaling
listeners.
Three cloud service consumers attempt to access one cloud service simultaneously (1). The automated
scaling listener scales out and initiates the creation of three redundant instances of the service (2). A
fourth cloud service consumer attempts to use the cloud service (3). Programmed to allow up to only
three instances of the cloud service, the automated scaling listener rejects the fourth attempt and
notifies the cloud consumer that the requested workload limit has been exceeded (4). The cloud
consumer’s cloud resource administrator accesses the remote administration environment to adjust
the provisioning setup and increase the redundant instance limit (5).
Load Balancer
The load balancer mechanism is a runtime agent with logic fundamentally based on the
premise of employing horizontal scaling to balance a workload across two or more IT
resources to increase performance and capacity beyond what a single IT resource can provide.
Beyond simple division of labor algorithms (Figure 1), load balancers can perform a range of
specialized runtime workload distribution functions that include:
Asymmetric Distribution – larger workloads are issued to IT resources with higher processing
capacities
Workload Prioritization – workloads are scheduled, queued, discarded, and distributed workloads
according to their priority levels
Content-Aware Distribution – requests are distributed to different IT resources as dictated by the
request content
SLA Monitor
Figure 1 – A cloud service consumer interacts with a cloud service (1). An SLA monitor intercepts the
exchanged messages, evaluates the interaction, and collects relevant runtime data in relation to
quality-of-service guarantees defined in the cloud service’s SLA (2A). The data collected is stored in a
repository (2B) that is part of the SLA management system (3). Queries can be issued and reports can
be generated for an external cloud resource administrator via a usage and administration portal (4)
or for an internal cloud resource administrator via the SLA management system’s native user-
interface (5).
Pay-Per-Use Monitor
Figure 1 – A cloud consumer requests the creation of a new instance of a cloud service (1). The IT
resource is instantiated and they pay-per-use monitor mechanism receives a “start” event notification
from the resource software (2). The pay-per-use monitor stores the value timestamp in the log
database (3). The cloud consumer later requests that the cloud service instance be stopped (4). The
pay-per-use monitor receives a “stop” event notification from the resource software (5) and stores the
value timestamp in the log database (6).
Figure 1 illustrates the pay-per-use monitor designed as a monitoring agent that transparently
intercepts and analyzes runtime communication with a cloud service.
Figure 2 – A cloud service consumer sends a request message to the cloud service (1). The pay-per-
use monitor intercepts the message (2), forwards it to the cloud service (3a), and stores the usage
information in accordance with its monitoring metrics (3b). The cloud service forwards the response
messages back to the cloud service consumer to provide the requested service (4).
Audit Monitor
The audit monitor mechanism is used to collect audit tracking data for networks and IT
resources in support of, or dictated by, regulatory and contractual obligations. The figure
depicts an audit monitor implemented as a monitoring agent that intercepts “login” requests
and stores the requestor’s security credentials, as well as both failed and successful login
attempts, in a log database for future audit reporting purposes.
A cloud service consumer requests access to a cloud service by sending a login request message with
security credentials (1). The audit monitor intercepts the message (2) and forwards it to the
authentication service (3). The authentication service processes the security credentials. A response
message is generated for the cloud service consumer, in addition to the results from the login attempt
(4). The audit monitor intercepts the response message and stores the entire collected login event
details in the log database, as per the organization’s audit policy requirements (5). Access has been
granted, and a response is sent back to the cloud service consumer (6).
Failover System
The failover system mechanism is used to increase the reliability and availability of IT
resources by using established clustering technology to provide redundant
implementations. A failover system is configured to automatically switch over to a
redundant or standby IT resource instance whenever the currently active IT resource becomes
unavailable.
Failover systems are commonly used for mission-critical programs or for reusable services that can
introduce a single point of failure for multiple applications. A failover system can span more than one
geographical region so that each location hosts one or more redundant implementations of the same IT
resource.
This mechanism may rely on the resource replication mechanism to supply the redundant IT resource
instances, which are actively monitored for the detection of errors and unavailability conditions.
Failover systems come in two basic configurations:
Active-Active
In an active-active configuration, redundant implementations of the IT resource actively serve the
workload synchronously (Figure 1). Load balancing among active instances is required. When a
failure is detected, the failed instance is removed from the load balancing scheduler (Figure 2).
Whichever IT resource remains operational when a failure is detected takes over the processing
(Figure 3).
Figure 1 – The failover system monitors the operational status of Cloud Service A.
Figure 2 – When a failure is detected in one Cloud Service A implementation, the failover system
commands the load balancer to switch over the workload to the redundant Cloud Service A
implementation.
Figure 3 – The failed Cloud Service A implementation is recovered or replicated into an operational
cloud service. The failover system now commands the load balancer to distribute the workload again.
Active-Passive
In an active-passive configuration, a standby or inactive implementation is activated to take over the
processing from the IT resource that becomes unavailable, and the corresponding workload is
redirected to the instance taking over the operation (Figures 4 to 5).
Some failover systems are designed to redirect workloads to active IT resources that rely on
specialized load balancers that detect failure conditions and exclude failed IT resource instances from
the workload distribution. This type of failover system is suitable for IT resources that do not require
execution state management and provide stateless processing capabilities. In technology architectures
that are typically based on clustering and virtualization technologies, the redundant or standby IT
resource implementations are also required to share their state and execution context. A complex task
that was executed on a failed IT resource can remain operational in one if its redundant
implementations.
Figure 4 – The failover system monitors the operational status of Cloud Service A. The Cloud Service
A implementation acting as the active instance is receiving cloud service consumer requests.
Figure 5 – The Cloud Service A implementation acting as the active instance encounters a failure that
is detected by the failover system, which subsequently activates the inactive Cloud Service A
implementation and redirects the workload toward it. The newly invoked Cloud Service A
implementation now assumes the role of active instance.
Figure 6 – The failed Cloud Service A implementation is recovered or replicated into an operational
cloud service, and is now positioned as the standby instance, while the previously invoked Cloud
Service A continues to serve as the active instance.
Hypervisor
limited to one physical server and can therefore only create virtual images of that server (Figure 1).
Similarly, a hypervisor can only assign the virtual servers it generates to resource pools that reside on
the same underlying physical server. A hypervisor has limited virtual server management features,
such as increasing the virtual server’s capacity or shutting it down. The VIM provides a range of
features for administering multiple hypervisors across physical servers.
Figure 1 – Virtual servers are created via individual hypervisors on individual physical servers. All
three hypervisors are jointly controlled by the same VIM.
Hypervisor software can be installed directly in bare-metal servers and provides features for
controlling, sharing and scheduling the usage of hardware resources, such as processor power,
memory, and I/O. These can appear to each virtual server’s operating system as dedicated resources.
Resource Cluster
system and can be used to increase scalability by live-migrating a virtual server that is running at an
overloaded physical server to another physical server that has suitable capacity.
Database Cluster – Designed to improve data availability, this high-availability resource cluster
has a synchronization feature that maintains the consistency of data being stored at different storage
devices used in the cluster. The redundant capacity is usually based on an active-active or active-
passive failover system committed to maintaining the synchronization conditions.
Large Dataset Cluster – Data partitioning and distribution is implemented so that the target
datasets can be efficiently partitioned without compromising data integrity or computing accuracy.
Each cluster node processes workloads without communicating with other nodes as much as in
other cluster types.
Many resource clusters require cluster nodes to have almost identical computing capacity and
characteristics in order to simplify the design of and maintain consistency within the resource cluster
architecture. The cluster nodes in high-availability cluster architectures need to access and share
common storage IT resources. This can require two layers of communication between the nodes—one
for accessing the storage device and another to execute IT resource orchestration (Figure 1). Some
resource clusters are designed with more loosely coupled IT resources that only require the network
layer (Figure 2).
Figure 1 – Load balancing and resource replication are implemented through a cluster enabled
hypervisor. A dedicated storage area network is used to connect the clustered storage and the
clustered servers, which are able to share common cloud storage devices. This simplifies the storage
replication process, which is independently carried out at the storage cluster.
Figure 2 – A loosely coupled server cluster that incorporates a load balancer. There is no shared
storage. Resource replication is used to replicate cloud storage devices through the network by the
cluster software.
There are two basic types of resource clusters:
Load Balanced Cluster – This resource cluster specializes in distributing workloads among cluster
nodes to increase IT resource capacity while preserving the centralization of IT resource
management. It usually implements a load balancer mechanism that is either embedded within the
cluster management platform or set up as a separate IT resource.
High-Availability (HA) Cluster – A high-availability cluster maintains system availability in the
event of multiple node failures, and has redundant implementations of most of all of the clustered
IT resources. It implements a failover system mechanism that monitors failure conditions and
automatically redirects the workload away from any failed nodes.
The provisioning of clustered IT resources can be considerably more expensive than the provisioning
of individual IT resources that have an equivalent computing capacity.
Multi-Device Broker
An individual cloud service may need to be accessed by different types of cloud service
consumers, some of which may be incompatible with the cloud service’s published service
contract. Disparate cloud service consumers may be differentiated by their hosting hardware
devices and/or may have different types of communication requirements. To overcome
incompatibilities between a cloud service and a disparate cloud service consumer, mapping logic
needs to be created to transform (or convert) information that is exchanged at runtime.
The multi-device broker mechanism is used to facilitate runtime data transformation so as to make a
cloud service accessible by a wider range of cloud service consumer programs and devices (Figure 1).
Multi-device brokers commonly exist as or incorporate gateway components, such as:
XML Gateway – transmits and validates XML data
Cloud Storage Gateway – transforms cloud storage protocols and encodes storage devices to
facilitate data transfer and storage
Mobile Device Gateway – transforms the communication protocols used by mobile devices
Figure 1 – A multi-device broker contains the mapping logic necessary to transform data exchanges
between a cloud service and different types of cloud service consumer devices.
A state management database is a storage device that is used to temporarily persist state
data for software programs. As an alternative to caching state data in memory, software
programs can offload state data to the database in order to reduce the amount of run-
time memory they consume (Figures 1 and 2). By doing so, the software programs and
the surrounding infrastructure are more scalable. State management databases are commonly used by
cloud services, especially those involved in long-running runtime activities.
Figure 1 – During the lifespan of a cloud service instance, it may be required to remain stateful and
keep state data cached in memory, even when idle.
Figure 2 – By deferring state data to a state repository, the cloud service is able to transition to a
stateless condition (or a partially stateless condition), thereby temporarily freeing system resources.
Figure 1 – The remote administration system abstracts underlying management systems to expose and
centralize administration controls to external cloud resource administrators. The system provides a
customizable user console, while programmatically interfacing with underlying management systems
via their APIs.
The tools and APIs provided by a remote administration system are generally used by the cloud
provider to develop and customize online portals that provide cloud consumers with a variety of
administrative controls.
The following are the two primary types of portals that are created with the remote administration
system:
Usage and Administration Portal – A general purpose portal that centralized management controls
to different cloud-based IT resources and can further provide IT resource usage reports.
Self-Service Portal – This is essentially a shopping portal that allows cloud consumers to search an
up-to-date list of cloud services and IT resources that are available from a cloud provider (usually
for lease). The cloud consumer submits its chosen items to the cloud provider for provisioning.
Figure 2 illustrates a scenario involving a remote administration system and both usage and
administration and self-service portals.
Figure 2 – A cloud resource administrator uses the usage and administration portal to configure an
already leased virtual server (not shown) to prepare it for hosting (1). The cloud resource
administrator then uses the self-service portal to select and request the provisioning of a new cloud
service (2). The cloud resource administrator then accesses the usage and administration portal again
to configure the newly provisioned cloud service that is hosted on the virtual server (3). Throughout
DR. [Link], PROFESOR, C&IT, REVA UNIVERSITY 16
Cloud Computing
these steps, the remote administration system interacts with the necessary management systems to
perform the requested actions (4).
Depending on:
the type of cloud product or cloud delivery model the cloud consumer is leasing or using from the
cloud provider,
the level of access control granted by the cloud provider to the cloud consumer, and
further depending on which underlying management systems the remote administration system
interfaces with,
…tasks that can commonly be performed by cloud consumers via a remote administration console
include:
configuring and setting up cloud services
provisioning and releasing IT resource for on-demand cloud services
monitoring cloud service status, usage, and performance
monitoring QoS and SLA fulfilment
managing leasing costs and usage fees
managing user accounts, security credentials, authorization, and access control
tracking internal and external access to leased services
planning and assessing IT resource provisioning
capacity planning
Figure 3 – Standardized APIs published by remote administration systems from different clouds enable
a cloud consumer to develop a custom portal that centralizes a single IT resource management portal
for both cloud-based and on-premise IT resources.
While the user-interface provided by the remote administration system will tend to be proprietary to the
cloud provider, there is a preference among cloud consumers to work with remote administration
systems that offer standardized APIs. This allows a cloud consumer to invest in the creation of its own
front-end with the foreknowledge that it can reuse this console if it decides to move to another cloud
provider that supports the same standardized API. Additionally, the cloud consumer would be able to
further leverage standardized APIs if it is interested in leasing and centrally administering IT resources
from multiple cloud providers and/or IT resources residing in cloud and on-premise environments.
Figure 1 – The cloud consumer’s cloud resource administrator accesses a usage and administration
portal externally to administer a leased IT resource (1). The cloud provider’s cloud resource
administrator uses the native user-interface provided by the VIM to perform internal resource
management tasks (2).
Figure 1 – The SLA monitor polls the cloud service by sending over polling request messages
(MREQ1 to MREQN). The monitor receives polling response messages (M to M ) that report that the
service was “up” at each polling cycle (1a). The SLA monitor stores the “up” time—time period of all
polling cycles 1 to N—in the log database (1b). The SLA monitor polls the cloud service that sends
polling request messages (M to M ). Polling response messages are not received (2a). The response
messages continue to time out, so the SLA monitor stores the “down” time—time period of all polling
cycles N+1 to N+M—in the log database (2b). The SLA monitor sends a polling request message (M )
and receives the polling response message (M ) (3a). The SLA monitor stores the “up” time in the log
database (3b).
Figure 1 – A cloud service consumer exchanges messages with a cloud service (1). A pay-per-use
monitor keeps track of the usage and collects data relevant to billing (2A), which is forwarded to a
repository that is part of the billing management system (2B). The system periodically calculates the
consolidated cloud service usage fees and generates an invoice for the cloud consumer (3). The
invoice may be provided to the cloud consumer through the usage and administration portal (4).