UEL-CN-7026 Cloud Computing

Week 8 – Reading Material

Advanced Cloud Architecture

1
TABLE OF CONTENTS

INTRODUCTION .....................................................................................................................................................3

LEARNING OBJECTIVES ..................................................................................................................................4

ADVANCED CLOUD ARCHITECTURES ............................................................................................................5

HYPERVISOR CLUSTERING ARCHITECTURE .............................................................................................5

LOAD BALANCED VIRTUAL SERVER INSTANCES ARCHITECTURE ....................................................6

NON-DISRUPTIVE SERVICE RELOCATION ARCHITECTURE ..................................................................7

ZERO DOWNTIME ARCHITECTURE ..............................................................................................................9

CLOUD BALANCING ARCHITECTURE ....................................................................................................... 10

RESOURCE RESERVATION ARCHITECTURE ............................................................................................ 11

DYNAMIC FAILURE DETECTION AND RECOVERY ARCHITECTURE ................................................. 13

BARE-METAL PROVISIONING ARCHITECTURE ....................................................................................... 14

RAPID PROVISIONING ARCHITECTURE .................................................................................................... 15

STORAGE WORKLOAD MANAGEMENT ARCHITECTURE ..................................................................... 16

CLOUD FEDERATION AND BROKERAGE ...................................................................................................... 17

CLOUD FEDERATION ..................................................................................................................................... 17

WORKLOAD PLACEMENT IN FEDERATED CLOUDS .............................................................................. 18

CLOUD BROKERAGE ...................................................................................................................................... 19

GLOSSARY ............................................................................................................................................................ 20

REFERENCES ........................................................................................................................................................ 21

2
INTRODUCTION
This chapter presents the diverse and advanced architectural layers of cloud technology architecture,

many of which can be constructed upon the more basic settings produced by the architectural models

explored in the preceding chapter. The chapter also investigates into specialized solution architectures

including cloud balancing and cloud provisioning, as well as elastic, resilient, multitenant, and

containerized technology architectures. Cloud Federation and Brokerage explain the IT role and

business model, as well as the practice of linking cloud computing environments to load balance traffic

and accommodate demand surges.

3
LEARNING OBJECTIVES
At the end of this week, students will be able to:

1. Describe the advanced cloud architectural mechanisms, industry technologies and design

patterns, both core and extended components.

2. Classify and organizes content so that architectural layers are explored sequentially and,

where appropriate, in relation to each other.

3. Understand the cloud federation and brokerage that explain geographic footprints and

describe custom solutions that enable to better manage, track billing and payments.

4. Develop Hadoop application to count no of characters, no of words and each character

frequency.

4
ADVANCED CLOUD ARCHITECTURES
In this section, we'll look at cloud architecture ideas that speak to specific and sophisticated

engineering layers. Every organization, from small too big, medium to giant, employs cloud

computing services to store information and access it from anywhere and at any time using only

with the assistance of the internet.

HYPERVISOR CLUSTERING ARCHITECTURE

Hypervisors are in charge of building and hosting a number of virtual servers. Because of this

dependency, any failures that affect a hypervisor can have a cascading effect on its virtual servers.

The hypervisor clustering architecture creates a high-availability hypervisor cluster that spans

many physical servers. To sustain runtime operations, the hosted virtual servers can be relocated

to another physical server or hypervisor if a specific hypervisor or its underlying physical server

becomes unavailable (Erl. T, 2013).

FIGURE 8.1 Hypervisor Clustering Architecture (Erl. T, 2013)

5
The hypervisor cluster is managed by a central Virtualized Infrastructure Manager (VIM), which

sends regular heartbeat messages to the hypervisors to ensure they are operational.

Unacknowledged heartbeat messages force the VIM to launch the live VM migration program,

which moves the afflicted virtual servers to a new host dynamically.

LOAD BALANCED VIRTUAL SERVER INSTANCES ARCHITECTURE

The most difficult component of a cloud is keeping cross-server workloads evenly balanced

between physical servers whose operation and management are isolated. A physical server can

easily host more virtual servers or receive greater workloads than its neighbors. Over- and under-

utilization of physical servers can both increase rapidly over time, resulting in continual

performance issues (for over-utilized servers) and constant waste (for the lost processing potential

of under-utilized servers) (Erl. T, 2013).

The load balanced virtual server instances design creates a capacity watchdog system that

calculates virtual server instances and associated workloads dynamically before distributing them

across available physical server hosts. A capacity watchdog cloud usage monitor, live Virtual

Machine (VM) migration software, and a capacity planner make up the capacity watchdog system.

The capacity watchdog monitor keeps track of physical and virtual server usage and alerts the

capacity planner if there are any noteworthy changes. The capacity planner is in charge of

dynamically matching physical server compute capacities to virtual server capacity requirements.

The live VM migration application is triggered to relocate the virtual server if the capacity planner

decides to move it to another host to divide the burden (Buyya et al., 2013).

6
 FIGURE 8.2 Loads Balanced Virtual Server Instances Architecture (Buyya et al., 2013)

NON-DISRUPTIVE SERVICE RELOCATION ARCHITECTURE

A cloud service may become unavailable for a variety of reasons, including:

1. Runtime use demands that exceed the processing capability of the cloud service.

2. A maintenance update that necessitates a brief downtime.

3. A long-term move to a new physical server host.

When a cloud service goes unavailable, consumer requests are typically refused, which can result

in exception conditions.

The non-disruptive service relocation architecture creates a system in which a predetermined

event initiates the duplication or movement of a cloud service implementation at runtime, avoiding

any downtime. Cloud service activity can be temporarily shifted to another hosting environment

at runtime by installing a duplicate implementation onto a new host, rather than scaling cloud
7
services in or out with redundant implementations.

When the original implementation is down for maintenance, cloud service consumer queries might

be temporarily diverted to a duplicate version. To accommodate cloud service migrations to new

physical server hosts, the cloud service implementation and any cloud service activity can be

relocated permanently. The new cloud service implementation is assured to be successfully

accepting and responding to cloud service consumer requests before the original cloud service

implementation is deactivated or destroyed, which is a critical component of the underlying

architecture (Buyya et al., 2013).

FIGURE 8.3 (a) Before Failure (b) After Failure (Buyya et al., 2013)

The use of live VM migration to relocate the complete virtual server instance that hosts the cloud

service is a typical strategy. In response to scaling and workload distribution requirements, the

automated scaling listener and/or load balancer techniques can be utilized to trigger a temporary
8
redirection of cloud service consumer requests. To start the live VM migration process, either

mechanism can contact the VIM. Depending on the location of the virtual server's disks and

settings, virtual server migration can take one of two forms:

• If the virtual server disks are stored on a local storage device or non-shared remote storage

devices associated to the source host, a copy of the virtual server disks is made on the

destination host. Both virtual server instances are synced when the copy is produced, and

virtual server files are removed from the origin host.

• If the virtual server's data are stored on a remote storage device shared by the origin and

destination hosts, copying the virtual server disks is unnecessary. The virtual server's

ownership is simply moved from the origin to the destination physical server host, and the

status of the virtual server is synced automatically (Buyya et al., 2013).

ZERO DOWNTIME ARCHITECTURE

For the virtual servers it hosts, a physical server is inherently a single point of failure. As a result,

if the real server fails or is attacked, any (or all) hosted virtual servers may suffer. This makes it

difficult for cloud providers to deliver zero-downtime promises to cloud customers.

FIGURE 8.4 Zero Downtime Architecture (Hwang, K., 2013)

9
In the event that their original physical server host fails, the zero downtime architecture develops

a sophisticated failover system that allows virtual servers to be dynamically transferred to new

physical server hosts (Hwang, K., 2013).

CLOUD BALANCING ARCHITECTURE

This architecture creates a customized architectural paradigm for load-balancing cloud resources

across different clouds. Consumer requests for cloud services can be balanced between clouds,

which can help:

1. Improve resource performance and scalability.

2. Enhance resource availability and dependability.

3. Optimize load balancing and resource allocation.

Its primary functionality is based on a combination of automated scaling and failover system

techniques. A complete architecture can have many more components and mechanisms. The two

mechanisms are used in the following order as a starting point:

• Based on current scaling and performance needs, the automated scaling listener routes

cloud service consumer requests to one of many redundant IT resource implementations.

• In the case of a failure within an IT resource or its underlying hosting environment, the

failover system ensures that redundant IT resources are capable of cross-cloud failover. IT

resource failures are reported so that the automated scaling listener can avoid routing cloud

service customer requests to unavailable or unstable IT resources by accident (Hwang, K.,

2013).

The automated scaling listener must be aware of all redundant IT resource implementations within

10
the scope of the cloud balanced architecture for a cloud balancing architecture to function

effectively. Additionally, if human synchronization of cross-cloud IT resource implementations is

not practicable, a resource replication mechanism may be required to automate the

synchronization.

FIGURE 8.5 Cloud Balancing Architecture (Hwang, K., 2013)

RESOURCE RESERVATION ARCHITECTURE

The resource reservation architecture creates a system in which one of the following resources is

reserved exclusively for a single cloud customer.

1. A single source of information

2. A component of a resource

11
 3. A variety of resources

The resource management system mechanism, which is used to establish the consumption

thresholds for individual resources and resource pools, may be required for the creation of a

resource reservation system. Reservations secure the amount of resources that each pool requires,

leaving the rest of the pool's resources open for sharing and borrowing. The remote administration

system approach is also utilized to offer front-end customization, allowing cloud customers to

manage their reserved resource allocations through administrative controls (Rosenberg, J. 2010,

Buyya et al., 2013).

FIGURE 8.6 Resource Reservation Architecture (Rosenberg, J. 2010, Buyya et al., 2013)

Cloud storage devices and virtual servers are two sorts of techniques that are frequently reserved

inside this architecture. Other mechanisms that could be included in the architecture are:
12
 • Audit Monitor

• Cloud Usage Monitor

• Hypervisor

• Logical Network Perimeter

• Resource Replication

DYNAMIC FAILURE DETECTION AND RECOVERY ARCHITECTURE

This architecture creates a robust watchdog system that can monitor and respond to a variety of

failure scenarios. This system alerts and escalates failure scenarios that it cannot resolve

autonomously. It uses the intelligent watchdog monitor, a customized cloud usage monitor, to

actively track resources and conduct pre-defined actions in response to pre-defined events. The

five fundamental functions of the robust watchdog system are as follows:

1. Watching

2. Deciding upon an event

3. Acting upon an event

4. Reporting

5. Escalating

For each resource, sequential recovery policies can be established to determine the actions that the

intelligent watchdog monitor should perform in the event of a failure state. A recovery policy

might indicate, for example, that one recovery attempt must be made automatically before

providing a notification (Buyya et al., 2013).

13
 FIGURE 8.7 Dynamic Failure Detection and Recovery Architecture (Buyya et al., 2013)

BARE-METAL PROVISIONING ARCHITECTURE

This architecture creates a system that makes use of this feature by deploying specialized service

agents that can identify and provision whole operating systems remotely. When the server boots

up, the remote administration software that is built into the ROM becomes available. To connect

to the physical server's native remote management interface, a Web-based or proprietary user

interface, such as the portal supplied by the remote administration system, is commonly utilized.

IP addresses in IaaS platforms can be passed directly to cloud users, allowing them to deploy bare-

metal operating systems on their own.

14
The auto-deployment functionality of the bare-metal provisioning system allows cloud customers

to connect to the deployment software and provide several servers or operating systems at the same

time. The central deployment system connects to the servers via their management interfaces, and

uploads and runs as an agent in the physical server's RAM using the same protocol. The raw client

becomes a bare-metal server with a management agent installed, and the deployment software

uploads the appropriate setup files to deploy the operating system (Erl. T, 2013).

FIGURE 8.8 Bare-Metal Provisioning Architecture (Erl. T, 2013)

RAPID PROVISIONING ARCHITECTURE

The rapid provisioning architecture creates a system that automates the providing of a variety of

resources, either individually or collectively. The underlying technical architecture for quick

resource provisioning is complicated and complex and it relies on a system that includes an

automated provisioning program, a rapid provisioning engine, and on-demand provisioning scripts

and templates (Erl. T, 2013).

15
 FIGURE 8.9 Rapid Provisioning Architecture (Erl. T, 2013)

1. A cloud resource administrator uses the self-service portal to request a new cloud service.

2. The self-service portal sends the request to the virtual server's automatic service

provisioning application.

3. This instructs the quick provisioning engine to do the required activities.

4. When the new cloud service is ready, the quick provisioning engine notifies you.

5. The automated service provisioning program completes and publishes the cloud service for

cloud consumer access on the usage and administrative site.

STORAGE WORKLOAD MANAGEMENT ARCHITECTURE

This design allows Logical Unit Numbers (LUNs) to be spread uniformly across available cloud

storage devices, while a storage capacity system ensures that runtime workloads are distributed

fairly across the LUNs.

16
 FIGURE 8.10 Storage Workload Management Architecture (Hwang, K., 2013)

LUN data is evenly dispersed throughout available storage hosts when cloud storage devices are

combined into a group. To monitor and equalize runtime workloads among the grouped cloud

storage devices, a storage management system is configured and an autonomous scaling listener is

positioned (Hwang, K., 2013).

CLOUD FEDERATION AND BROKERAGE

Cloud Federation is the aggregation of software, infrastructure, and platform services from several

networks that may be accessed via the internet by a client. Cloud services brokerage (CSB) is an

IT position and business model in which a corporation or other organization provides value to one

or more (public or private) cloud services on behalf of one or more customers by performing three

main functions: aggregation, integration, and customization brokerage (Comer, D.E., 2021).

CLOUD FEDERATION
• Virtual Machines (VMs) - This is the interconnection of two or more Cloud computing

17
 infrastructures for load balancing.

• One of the service providers purchases the services from the other.

• The federation agreement could be temporary or long-term.

• It generates cash for the seller while allowing the buyer to expand their resource capacity

without having to set up or acquire additional hardware.

• The VMs and data can be moved between cloud providers.

• The buyer's cloud federation process is transparent to the buyer's customers.

• Federation can be done horizontally or vertically by extending the federation buyer's SaaS,

PaaS, and IaaS.

• The SLA of the buyer's customers is also followed over the seller's infrastructure (Comer,

D.E., 2021).

WORKLOAD PLACEMENT IN FEDERATED CLOUDS

• Due to the limited number of physical resources available, a single cloud can only fulfill a

fixed number of consumer requests in a given amount of time.

• A Cloud infrastructure is experiencing resource constraint or congestion if it is unable to

meet the requests' deadlines.

• At this time, the likelihood of a SLA violation increases significantly.

• If the scenario continues, the cloud provider may face SLA fines.

• The cloud provider must decide whether to handle client requests that exceed current

capacity based on the following factors:

o Revenue to be received from processing the extra requests.

18
 o The amount to be paid to another service or providers.

o The request deadline vs. the remote provider's latency.

o To reduce network latency, a cloud federation can be built to fulfill the requests of

a remote consumer through the nearest provider in that region.

o As a result, cloud federation provides a superior solution to resource constraints

and latency difficulties in cloud computing.

o Horizontal federation is possible. The cloud services (IaaS, PaaS, and SaaS) are

expanded horizontally in this way.

o In vertical federation, a Cloud provider A (for example) may host a SaaS/PaaS

instance of another provider B on its own IaaS to meet provider A's needs.

o A hybrid federation is also possible (Comer, D.E., 2021).

CLOUD BROKERAGE
• It's a third-party procedure for locating the best cloud provider, and it's based on the

consumers' needs and/or instructions.

• Brokerage is a service provided by a person or organization. Assisting in the transfer of

data between cloud service users and providers.

• Saves the customer time and effort in looking for a Cloud provider.

• Collaborates closely with customers to understand their business processes, provisioning

needs, budget, and other demands.

• After that, the broker looks for the finest cloud provider options for the client.

• Based on the consumer's needs and budget, a list of suppliers is subsequently offered.

19
 • The broker may also be given the authority to negotiate with providers on the consumer's

behalf. Even better, the broker can negotiate a contract with the best provider.

• A broker may also supply the following to the consumer:

o Application Programming Interface (API) and Graphical User Interface (GUI) for

managing Cloud resources.

o Data encryption, transport, and management support

o A consumer advisory service to help them get the most out of the cloud (Comer,

D.E., 2021).

GLOSSARY
Intelligent Automation Engine: By executing scripts that incorporate process logic, the

intelligent automation engine automates administration activities.

LUN: A logical unit number (LUN) is a logical drive that corresponds to a physical disk partition.

Storage Service Gateway: The storage service gateway is an external interface to cloud storage

services that can automatically redirect cloud consumer requests when the location of the requested

data changes.

Storage Replication: Storage replication is a type of resource replication that replicates data from

a primary storage device to a secondary storage device in a synchronous or asynchronous manner.

It can reproduce both partial and whole LUNs.

Heartbeats: Hypervisors, hypervisors and virtual servers, and hypervisors and VIMs all exchange

heartbeats, which are system-level communications.

Live VM migration: A system capable of transferring virtual servers or virtual server instances
20
in real time is known as live VM migration.

LUN migration: LUN migration is a specialized storage tool that allows you to relocate LUNs

from one storage device to another without causing any disruption to cloud users.

REFERENCES
1. Buyya, R. et al., (2013). Mastering cloud computing: foundations and applications

programming. Newnes.

2. Comer, D.E., (2021). The Cloud Computing Book: The Future of Computing Explained.

Chapman and Hall/CRC.

3. Erl, T. et al., (2013). Cloud computing: concepts, technology, & architecture. Pearson

Education.

4. Hwang, K. et al., (2013). Distributed and cloud computing: from parallel processing to the

internet of things. Morgan Kaufmann.

5. Rosenberg, J. and Mateos, A., (2010). The cloud at your service. Manning Publications Co.

21