Browse Prior Art Database

Cloud computing component-workload-client mapping in a multi-tenant (public instances) environment Disclosure Number: IPCOM000239304D
Publication Date: 2014-Oct-28
Document File: 2 page(s) / 72K

Publishing Venue

The Prior Art Database


In a cloud multi-tenancy environment where public instances share the underlying hypervisor, compute, network, storage etc., it is difficult to map the physical hardware system components to the various workloads across the customers’ environment which are hosted in the cloud computing public instances environment. In addition to that, there is no easy solution which points out to the common physical server hardware resources being used across clients’ workloads on a same physical server.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 66% of the total text.

Page 01 of 2

Cloud computing component-workload-client mapping in a multi-tenant (public instances) environment

For example, if client A, client B and client C have public instances hosted/running on a server A, all the three clients are sharing the physical CPU, memory, physical ports, network cards etc.

For a robust change management process, problem & incident management process , it is imperative to carry out an impact analysis before we perform a change or resolve a problem.

It introduces a significant business risks, unless we analyse which clients and workloads may get impacted in a multi-tenancy cloud environment in the given scenarios:

Scenario1. executing a change on the component level e.g CPU/mem upgrade
Scenario2: failure of a component e.g. CPU/mem
Scenario3: executing a change for any shared hardware component Scenario4: failure of any shared hardware component

Hence, it is vital to map CCI-workload down to the hardware component level in a multi-tenant cloud environment.

The proposed component engine working algorithm is as stated below:

• Login to public CCIs

2. Determines workloads on all public CCIs on a physical server e.g. CCI1 - workload1,

CCI2 - workload2 and so on by running process grep or workload identifier call.

3. Login to hypervisor.

4. Determines sys config information for all hardware components on the same physical server (say server0) by calling system level routines e.g. prtdiag, sysconf etc.

e.g. CPU1,CPU2,DIMM1, DIMM2, NIC1, NIC2, HBA1, H...