Browse Prior Art Database

Proritize the cluster node activation in cloud environment

IP.com Disclosure Number: IPCOM000244689D
Publication Date: 2016-Jan-06
Document File: 6 page(s) / 74K

Publishing Venue

The IP.com Prior Art Database

Abstract

Prioritizing the activation of cluster node on the basis of Input/Output throughput and network parameters in cloud environment

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

Page 01 of 6

Proritize the cluster node activation in cloud environment

Acronyms Used:

SSP - Shared Storage Pool


VM - Virtual Machine
VIOS - Virtual Input/Output Server
SEA - Shared Ethernet Adapter
IO - Input/Output

Novelty:

From this article, we are designing a solution which is based on how we should make SSP node online after planned/unplanned outages so that customer can make his VM online and have his VM served to his clients without having delay.

Current Problem:

In any datacenter, planned and unplanned outages are quite common and quite natural. We need to have proper measures taken care when these outage happen. In particular, when datacenter is part of private or public cloud infrastructure, we need to ensure that planned and unplanned outages shouldn't cause any data integrity issues and also, we need to see all preventive measures are taken care so that after outage, we should have all the data intact.

In any cloud environment, Shared Storage Pool (SSP) is the most commonly used as SSP has lot of advantages over traditional vSCSI model of assigning disks to VMs.

With the current design of SSP, when systems are brought online, the cluster will be active on the node which came online first and then followed by all other nodes. With this current design of SSP, we are seeing following problems when SSP is spread across multiple cloud systems:

1. To customer, his VM is most priority and he knows which of his VM should be online with priority so that he can make his applications available for his clients as much as possible. With the current design of SSP, customer can't bring his priority VM online if the SSP node isn't online when cloud systems are brought up.

2. If we take any systems that are exist in datacenter, each systems will have dual VIOS to have redundancy. When SSP nodes are brought online, we need to ensure that atleast one node in each system should be brought up so that corresponding VMs which are mapped from SSP node can be activated. With the current design of SSP, we may see that 2 nodes of same system brought online and the VMs which are on other system can't be brought online as cluster isn't up other systems.

From this article, we are trying to the solve customer problem where he wants his VM back online as soon as possible and not on the basis of SSP nodes. End goal is to

1


Page 02 of 6

make sure customer should be able prioritize his VMs so that we can make his VM online after the planned/unplanned outages.

Solution:

Our solution is based on how we should make SSP node online after planned/unplanned outages so that customer can make his VM online and have his VM served to his clients without having delay.

This solution also take care of the 2 pain points which are described in #1 dynamically. We are using single method from which both of 2 pain points are taken care.

To better understand how our solution works, we are taking a typical 12-node SSP cluster with 4 VIOS configured in each POWER System.

Naming convention...