Application Affinity Analysis
Original Publication Date: 2004-Jul-16
Included in the Prior Art Database: 2004-Jul-16
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.
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
Transforming dependencies into constraints A set of rules have been defined to assist the translation of dependencies into constraints: