VoiceObjects provides session partitioning to enable native support for Service Level Agreements (SLAs), making it the ideal foundation for Managed Service Environments.

SLAs set the expectations between the service consumer and service provider. It helps define the relationship between the two parties. It is the cornerstone of how the service provider sets and maintains commitments to the service consumer.

A SLA typically addresses five key aspects:

·          What the service provider is promising.

·          How the service provider will deliver on those promises.

·          Who will measure the service delivery, and how.

·          What happens if the service provider fails to deliver as promised.

·          How SLAs will change over time.

The challenge for a new service and its associated SLA is that there is a direct relationship between the platform architecture and what the guaranteed and maximum levels of availability are. Thus, a SLA cannot be created in a vacuum. A SLA must be defined with the overall system infrastructure in mind.

Using Session Partitioning

In Managed Service Environments (MSEs), SLAs are a vital mechanism to ensure the smooth coexistence of applications deployed by multiple different sites. While it is desirable to use the same pool of sessions for different sites, certain availability guarantees must be met. In particular, each site typically has a certain number of phone lines assigned to it, which map to dialog sessions on the VoiceObjects platform. Thus it is necessary to partition the capacity of dialog sessions for each site that are available to it regardless of the overall traffic on the platform.

On the other hand, sites may only have purchased a defined session capacity. So it must also be possible to assign individual session limits to them.

The VoiceObjects platform provides all of these capabilities, and ensures that the partitioned session capacities are enforced at any time to deliver the promised SLA towards the service consumer.

Configuring Session Partitioning

Within VoiceObjects, session partitioning allows administrators to slice the total session capacity of the system into dedicated partitions. Each partition is specified by a session guarantee, limit and distribution. The individual partitions can be configured on three isolated levels: server, site, and service.

8     Caution: The session partitioning settings made on the different levels interact with each other and must be kept synchronized for the installation to work as expected. VoiceObjects provides assistance for this by indicating conflicts between partition definitions, and by visualizing the current session partitioning matrix. For details, refer to Monitoring Session Partitioning.

Session guarantees define the minimum number of concurrent dialog sessions that are available to a server, site, or service. Regardless of whether these sessions are actually in use, they are set aside and may not be used for other purposes. This also implies that sessions can only be guaranteed to a specific server, site, or service if they are still available.
Session guarantees should be used to ensure that sites receive the service level they have paid for, regardless of the current traffic situation in other sites. They are typically configured by Server Administrators.

Session limits define the maximum number of concurrent dialog sessions that may be active for a server, site, or service. If this limit is reached, any additional incoming dialog sessions will be rejected. The Reject response setting on the service enables intelligent handling of such situations (e.g. premium customers may be routed to a call center while standard customers are informed to call again later).
Session limits should be used to ensure that sites do not exceed the service level they have paid for, regardless of the number of incoming requests. They are typically configured by Server Administrators.

Session distributions define how dialog sessions are distributed between different services within a custom site and on a given server. They are only relevant for custom sites with a session limit and should be seen as an alternative to using explicit guarantees and limits for the services.
Session distributions should be used to ensure that priorities within a site are respected, and that one service cannot deprive another service of dialog sessions. They are typically configured by Site Administrators.

For details on how the session partitioning is applied at call time and how the various session partitions interact with each other, see Applying Session Partitioning.

Site

For each site, a session guarantee and a session limit can be defined.

The sum of the session guarantees for all sites must not exceed the total number of licensed sessions for the installation.

The session limit set on a site implicitly limits all servers and services that belong to this site.

Changes made to these settings are applied as soon as at least one service belonging to this site is redeployed (regardless on which server).

i8    Note: The system site has neither a session guarantee nor a session limit. This implies that services within the system site cannot have a session guarantee (but they can have session limits). Servers from the system site can have both.

For details on how to set session guarantee and session limit for a site, refer to Chapter 3 – User Management – Managing Sites in the Administration Guide.

Server

For each server, a session guarantee and a session limit can be defined.

The sum of the session guarantees for all servers must not exceed the total number of licensed sessions for the installation. If the server belongs to a custom site, it must also not exceed the session guarantee for this site.

The session limit set on a server implicitly limits all services that are deployed on this server. If a server belongs to a custom site, then the server itself is implicitly limited by the settings made on the site.

Changes made to the server settings are applied when the server is reset or completely restarted. The server claims any session guarantee assigned to it when it starts, and releases them when it is stopped or shut down.

For details on how to set session guarantee and session limit on a server, refer to Chapter 2 – Configuring Servers and Services.

Service

For each service, a session guarantee, a session limit, and a session distribution percentage can be defined.

The session guarantee for a service must not exceed the session guarantee for the site it belongs to, or for the server it is deployed on. The session guarantee for a service counts separately for each server this service is deployed on.

By default, session distribution is disabled. To enable it, all services within a custom site hosted on a given server must be assigned a percentage value. The sum of all percentage values must not exceed 100%. If it stays below 100%, available sessions may go unused. If it exceeds 100%, session distribution settings will be ignored for all services within the site. This is indicated by warning icons  in the service info boxes as well as on the Session Partitioning tab.

Changes made to these settings are applied when the service is redeployed. The service claims any session guarantee assigned to it when it is started (or redeployed in started state), and releases them when it is stopped. Note that the service holds on to its session guarantee when it is idled.

i8    Note: Services that belong to the system site cannot have a session guarantee, since the system site itself cannot have them.

For details on how to set session partitions with guarantees and limits for a service, refer to Chapter 2 – Configuring Servers and Services.

Applying Session Partitioning

When running multiple sites with their respective services on a single VoiceObjects platform, the various configured session partitions may interact in complex ways. Thus it is important for a Server Administrator or Controller to have a thorough understanding of the impact a certain session partition may have.

The following image shows the general installation topology:

Inside a site, which may either be the system site or a custom site, there can be multiple servers. Each of these servers runs a set of VoiceObjects services (VS). These services may in turn belong to various sites, as indicated by the dashed line groups.
A server in the system site may host services from the system site or from any custom site.
A server in a custom site may host services from this site, or from the system site.

Session guarantees

Session guarantees are set aside top-down.
In order for a server from a custom site to have any session guarantee, the site itself must have them. Servers within the system site may use a session guarantee up to the concurrent session limit defined in the license key for the installation.

The sum of the session guarantees for all servers within a site must not exceed the session guarantee for the site itself. If it does, session guarantees are granted on a first-come-first-served basis and some of the servers may only receive a fraction of their requested session guarantee.

In order for a service to have any session guarantee, both the site it belongs to and the server it runs on must have them. In particular, services from the system site cannot have a session guarantee since the system site itself cannot have them.

The sum of session guarantees for all services on a server must not exceed the session guarantee for the server itself. If it does, session guarantees are granted on a first-come-first-served basis and some of the services may only receive a fraction of their requested session guarantee.
Similarly, the sum of session guarantees for all services from a site must not exceed the session guarantee for the site itself. If it does, session guarantees are granted on a first-come-first-served basis and some of the services may only receive a fraction of their requested session guarantee.

Examples:

1          Assume that a server with a session guarantee of 10 belongs to a custom site with a session guarantee of 5. Then the server only receives a session guarantee of 5.

2          Assume that a custom site with a session guarantee of 10 contains two servers with a session guarantee of 7 each. Then the first server to start will receive a session guarantee of 7, while the second server to start will only receive a session guarantee of 3.

3          A server in the system site may use any session guarantee, up to the number of available concurrent sessions in the license key for the installation. If there are multiple servers in the system site, then the sum of their session guarantees must not exceed the number of available concurrent sessions for the installation.

4          Assume that a custom site with a session guarantee of 10 contains two services with session guarantee of 5 each. Both services are deployed on a server in the system site, which has a session guarantee of 8. Then (assuming there is no interference with other services on the server) the first service to start will receive a session guarantee of 5, while the second service to start will only receive a session guarantee of 3.

Session limits

Session limits are imposed top-down.
The outermost limit is the number of concurrent sessions available in the license key of the VoiceObjects installation.

The session limit for any server within a site must not exceed the session limit for the site itself. If it does, the site session limit is used instead.

The session limit for any service on a server must not exceed the session limit for the server itself. If it does, the server session limit is used instead.
Similarly, the session limit for any service from a site must not exceed the session limit for the site itself. If it does, the site session limit is used instead.

Examples:

1          Assume there is a server with a session limit of 10 that belongs to a custom site with a session limit of 7. Then the lower session limit of 7 is also applied to the server.

2          Assume there is a server in the system site with a session limit of 100 while the license key for the installation defines a session limit of 75. Then the lower session limit of 75 is also applied to the server.

3          Assume that a service with a session limit of 25 is hosted on a server with a session limit of 15. Then the lower session limit of 15 is also applied to the service.

4          Assume that a service with a session limit of 25 belongs to a custom site with a session limit of 10. Then the lower session limit of 10 is also applied to the service.

5          Assume that a server with a session limit of 10 hosts two services that each have a session limit of 8. Then each of the two services is limited to at most 8 concurrent dialog sessions, while the sum of concurrent dialog sessions for both services combined is limited to 10 concurrent sessions.

Session distributions

Session distributions provide a mechanism to prioritize among multiple services within a custom site. This setting is only relevant if a session limit is defined for the site. It is ignored for services from the system site (since the system site has no session limit).

Session distribution percentages should be used as an alternative to explicit guarantees and limits for the individual services within a site. When used in combination with them, the session distribution percentages will take precedence and the guarantees and limits will be adjusted accordingly.
The advantage of using session distributions lies in the fact that they automatically adjust to a modified session limit for the site, and that no session guarantee is required on the site level.

By default, session distribution is disabled. To enable it, all services within a site must be assigned a session distribution percentage. As long as at least one service within a site is set to Disabled, session distributions are not applied.

The percentages assigned to the services within a site and on a given server must sum up to no more than 100%. If they do, the settings are ignored. If they sum up to less than 100%, the site may not reach its session limit.

When session distribution percentages are assigned, each service is allowed at most the number of concurrent sessions that corresponds to its percentage of the total sessions available to the site.

Examples:

1          Assume that a site has three services, all of which have their session distribution set to the default of Disabled. Then dialog sessions within the site are distributed on a first-come-first-served basis.

2          Assume that in the same scenario as above, two of the services are assigned session distribution percentages while the third one is left at Disabled. Then the behavior is exactly the same as above, since session distributions are only activated if all services are assigned percentages.

3          Assume that a site has a session limit of 10 and contains two services with session distribution percentages of 20% and 80%, respectively. Then the first service can accept no more than 2 concurrent sessions, and the second service can accept no more than 8 concurrent sessions.

4          Assume that starting from the scenario above, an even distribution between the two services is desired. Then the session distribution percentages for both services need to be set to 50%, and both of the services need to be redeployed. Then both of them receive at most 5 concurrent sessions.
i8Note: Depending on the order in which the adjustment is done, the session distribution settings may be ignored temporarily while the sum of all session distribution exceeds 100%. They will take effect again once the sum is 100% or less.

Monitoring Session Partitioning

Once session partitioning has been configured for the various servers, sites, and services used in a VoiceObjects installation, the platform automatically enforces that these session partitions are honored at call time as described in Applying Session Partitioning.

Since the session partitions made on the different levels interact with each other and may have unintended impact when used without caution, VoiceObjects provides monitoring and management capabilities. This enables administrators to ensure that the session partitioning settings that are currently applied are consistent.

Session partitioning monitoring is available using the Control Center and the Web Services Interface.

Control Center

Session partitioning summary information is provided on the Session Partitioning tab within the Control Center.

 

This tab is only accessible to Server Administrators, Server Controllers, Site Administrators, and Site Controllers. The content of the Session Partitioning tab always provides an overview of the session partitioning settings for the entire repository (for Server Administrators/Controllers) or for the entire site (for Site Administrators/Controllers).

Information is displayed grouped by Sites, Servers, and Services. For all three sections, there is a set of columns displaying the granted session settings that are currently applied, and a set of columns displaying the requested session settings as they are provided in the respective object definition.

The Sites section displays the session partitioning settings for all sites that are active in the installation, including the system site. Custom sites are identified by their site ID as defined in the respective site settings.

The Sites section shows the following information:

·          Granted Sessions – Guarantee
The session guarantee that has been set aside for this site.
If this number is smaller than the requested session guarantee, a yellow triangle icon  is shown to the right of the site name.

·          Granted Sessions – Pool
The pool of floating sessions available to this site. This is the difference between Limit and Guarantee.

·          Granted Sessions – Limit
The maximum number of concurrent sessions available to this site.
If this number is smaller than the requested session limit, a yellow triangle icon  is shown to the right of the site name.

·          Requested Sessions – Guarantee
The session guarantee requested by this site within its site settings.

·          Requested Sessions – Limit
The maximum number of concurrent sessions defined for this site within its site settings.

·          Requested Sessions – Distribution
This column is not currently relevant for sites.

The Servers section displays the session partitioning settings for all servers that are active in the installation. Servers are identified by their reference ID. To indicate which site a specific server belongs to, the site ID is appended using the @ sign (e.g. VOServer@System indicates that the server with reference ID VOServer belongs to the system site).

The Servers section shows the following information:

·          Granted Sessions – Guarantee
The session guarantee that has been set aside for this server.
If this number is smaller than the requested session guarantee, a yellow triangle icon  is shown to the right of the server name.

·          Granted Sessions – Pool
The pool of floating sessions available to this server. This is the difference between Limit and Guarantee.

·          Granted Sessions – Limit
The maximum number of concurrent sessions available to this server.
If this number is smaller than the requested session limit, a yellow triangle icon  is shown to the right of the server name.

·          Requested Sessions – Guarantee
The session guarantee requested by this server within its object definition.

·          Requested Sessions – Limit
The maximum number of concurrent sessions defined for this server within its object definition.

·          Requested Sessions – Distribution
This column is not currently relevant for servers.

The Services section displays the session partitioning settings for all services that are active in the installation. Since the same service may be deployed on multiple servers, each service is shown along with the server it is deployed on.
Services are identified by their VoiceObjects Service Name (VSN). To indicate which site a specific service belongs to, the site ID is appended using the @ sign (e.g. PI@System indicates that the service with VSN PI belongs to the system site).

The Services section shows the following information:

·          Granted Sessions – Guarantee
The session guarantee that has been set aside for this service.
If this number is smaller than the requested session guarantee, a yellow triangle icon  is shown to the right of the service name.

·          Granted Sessions – Pool
The pool of floating sessions available to this service. This is the difference between Limit and Guarantee.

·          Granted Sessions – Limit
The maximum number of concurrent sessions available to this service.
If this number is smaller than the requested session limit, a yellow triangle icon  is shown to the right of the service name.

·          Requested Sessions – Guarantee
The session guarantee requested by this service within its object definition.

·          Requested Sessions – Limit
The maximum number of concurrent sessions defined for this service within its object definition.

·          Requested Sessions – Distribution
The session distribution percentage defined for this service.

Web Services Interface

Session partitioning information can be obtained through the Web Services Interface (WSI) using the getSessionPartitioning method. It returns an XML structure representing the same data that is displayed in the Control Center.

For more information on the Web Services Interface, refer to the Web Services Guide.

i8    Note: The Web Services Interface is licensed separately and can only be used if it is available in the license key.

Notifications

If notifications are enabled, notifications are sent whenever a session limit is exceeded. This applies to the service, server, and site level. For more information, refer to Chapter 8 – Notifications.

i8    Note: Notification is licensed separately and can only be used if it is available in the license key.

Infostore

If Infostore is active, session partitioning settings made on servers, services, and sites are written to the database. In addition, current session partitioning information is written out in regular intervals to enable subsequent analysis of actual load situations versus SLA limits. For more information, refer to the Infostore Guide.

i8    Note: Infostore is licensed separately and can only be used if it is available in the license key.