Browse Prior Art Database

Application Affinity Analysis Disclosure Number: IPCOM000029899D
Original Publication Date: 2004-Jul-16
Included in the Prior Art Database: 2004-Jul-16
Document File: 6 page(s) / 102K

Publishing Venue



In today's modern distributed computing environments, affinity impacts the ability to schedule changes to applications because of asssociations with other systems. This invention defines the method to identify the scheduling order where a community of applications and hosts have some affinity with each other.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 33% of the total text.

Page 1 of 6

Application Affinity Analysis

Application/Host Affinity constrains the ability to schedule change activities on hosts . The effects of affinity require that scheduling consider the following issues: the order in which all hosts must be refreshed within the schedule the order in which hosts must be refreshed within an Application inter-application host migration dependencies
inter-hosts outage constraints Note: a community of applications may evolve in such a way that Affinity issues may prevent hosts from being scheduled.

Evaluating these issues is a complex activity. analyse per Application information to identify dependencies

analyse dependency records to generate scheduling constraints

use constraints to order host change schedule




Capturing Affinity dependencies Host/Application combinations have dependencies on other Host/Application combinations.

These are represented by the following attributes: dependency type - this indicates the relationship that either the host or the application has to the other host or application. The dependencies may be denoted as follows:
sa = host shares application with other-host ss = host shares storage with other-host sd = host sends data to other-host rd = host receives data from other-host
sh = application shares host
ns = no sharing at all
bc = host is a backup client
bs = host is a backup server
dependency scope - this indicates the scope of the relationship, and is: i = internal - the relationship does not extend beyond this application. e = external - the relationship extends beyond this application, to other applications.
host association - this indicates how specifically (or generally) an application uses itʼs supporting hosts and may be denoted as: dedicated = the application function is dedicated to this host, no other host in the application cluster can perform this function and the application will fail if the host is offline. distributed = the application function is distributed across hosts, the application will continue to function if this host is offline.

Capturing Scheduling constraints Host/App scheduling constraints have the following attributes: ordering attributes - this indicates the relative rank between two hosts.

  H-OH = host must be refreshed before the other-host OH-H = other-host must be refreshed before the host H&OH = host and the other-host must be refeshed together HorOH = host can not be refreshed at the same time as the other-host dontcare = donʼt care about interaction unschedulable = host has an dependency issue impacting the ability to order it outage attributes - this indicates the relative impact of a host outage on another-host that is related by some dependency. full = outage on host causes full outage on the other-host partial outage on host does not cause a full outage on the other-host


Page 2 of 6

Transforming dependencies into constraints A set of rules have been defined to assist the translation of dependencies into constraints:

Rule Descripton