Appendum
Service Level Agreement
For
Accommodation Services Kx Application Hosting Service
Document Version: 1.0 draft
Date: 14/05/2009
Table of Contents
1 Document Management 3
1.1 Contributors 3
1.2 Version Control 3
2 Dates, Parties and Signatories 4
2.1 Signatories 4
3 Service Description 4
4 Service Hours & Availability 4
5 Service Support 4
5.1 Routine Support 4
5.2 Out of Hours Support 5
5.3 Backup Regime 5
6 Functionality 5
7 IT Service Continuity (Contingency) 6
8 Security 6
8.1 Server Update Regime 6
8.2 Application Update Regime 7
8.3 Server Access 8
9 User Training 8
10 Charging 8
10.1 Annual Charges 8
10.2 Charges for Additional Storage 8
10.3 Charging Procedures 8
11 Changes To This SLA 8
12 Re-Negotiating This SLA 9
13 Service Reviews 9
Appendix 1: Roles and Responsibilities 10
1 Document Management
1.1 Contributors
Role / Department / NameOwner / Service Management / Jay Coleman
Contributor / IS Applications Division / David Watters
1.2 Version Control
Date / Version / Author / Section / Amendment14/05/09 / 1.0 / Various / All / First version.
2 Dates, Parties and Signatories
See main support Service Level Agreement document section 2.
2.1 Signatories
See main support Service Level Agreement document section 2.1.
3 Service Description
Accommodation Services Kx application Hosting Service is an infrastructure platform provided by the University of Edinburgh IS to Accommodation Services in order that the Kx software can be delivered for use by Accommodation Services.
The service comprises:
· 2 Application layer servers (Windows Server 2003 with IIS 6)
· 2 Database servers (SQL Server 2005)
· 1.25 TB of SAN storage providing the database server filesystem as well as file storage for artefacts held outside the database.
This SLA does cover the loss of any single KX site or a fault in failover caused by loss of network routes, extended loss of electrical power or other infrastructure failures (excluding a failure of the University SAN).
This SLA does not cover any service unavailability caused by major loss of network routes (for example the main network link to Pollock Halls), extended loss of electrical power or other infrastructure failures not related to that above. Routing all faults through the IS Support Team for Accommodation Services will ensure that faults are directed as appropriate.
4 Service Hours & Availability
See main support Service Level Agreement document section 4.
5 Service Support
5.1 Routine Support
See main support Service Level Agreement document section 5.1.
5.2 Out of Hours Support
See main support Service Level Agreement document section 5.2.
5.3 Backup Regime
The SAN storage area will be backed up nightly, ensuring that both the SQL Server database file and any associated files on the file system are backed up. SAN storage backups will run on a 4 weekly cycle, with daily incremental backups and a full backup taken once a week.
In addition, backup maintenance plans are setup in SQL Server so that backups are scheduled to run as follows:
· A full backup of all the databases taken once every week i.e. system and user databases.
· The transaction log for the user database will be backed up hourly.
· A cleanup maintenance task will be setup to delete all backup files older than 4 days. The number of days will be determined by the amount of disk space available and will be revised periodically to ensure sufficient disk space remains.
This means that:
· in the event of any catastrophic event, there will be a maximum of 1 hours data loss.
· where an older version of a file is required it will only be possible to roll back to an earlier version within the last 4 weeks.
It is the responsibility of IS to ensure that backup routines are working properly. IS Applications division will liaise with colleagues in IS Infrastructure to resolve any issues.
For full details of backup scheduling and locations please refer to the Technical Architecture Document.
Note: there is no prevision of stored data states older than 4 weeks.
6 Functionality
See main support Service Level Agreement document section 5.1 for priority classifications for the service.
7 IT Service Continuity (Contingency)
This has been classified as a Disaster Recovery Priority 1 Service.
The clustered service runs in an active / passive configuration with bi-directional failover capabilities. The active node for both the cluster and SQL Server resource groups is located at Kings Buildings; the passive node at Appleton Tower. Both server nodes are of identical specification. Clustering is currently only present on the Database servers. There is one Web application server located at Appleton Tower and a further server located at King’s Buildings which monitors the cluster and initiates failover when necessary.
Failover of a resource group to the passive node is automatic. Manual intervention to move a resource group from one node to the other is only required for fail-back or to investigate any issues that may have arisen with a node.
The only instance where a switchover to the passive server is required is when there is a failure on the primary server, for test purposes, or for maintenance.
Wider failure on the Kx portion of the SAN or on the University network would not be resolved by a failover to the passive server. This would be dealt with as a critical incident under this SLA.
Failures on the SAN or the University network would affect a larger number of systems than the Kx Software service and are covered by separate University disaster recovery procedures.
Where a server fails, IS are responsible for restoration and/or recovery of the server with the appropriate versions and ensuring all relevant patches are applied.
Accommodation Services are responsible for Business Continuity in their environment around access to their infrastructure e.g. in the case of any loss of sites.
Elements of business continuity planning around the Kx service should be discussed with IS Applications in order to ensure that appropriate stakeholders are consulted and actions taken as required.
8 Security
8.1 Server Update Regime
As part of the Facilities Management of the server infrastructure we use an automated update regime that ensures services are not unnecessarily exposed to risk. Updates are usually released by Microsoft on the 2nd Tuesday of each month and will be applied via this regime for both the Microsoft Windows Server OS and the SQL Server application.
Patches / Updates are split into two types:
Critical Patches: All critical patches will be automatically installed once they have been checked and released by IS ITI Architecture (within 72 hours of release from Microsoft). A period of 24 hours is left before applying the patches to the second server.
By default the following patching procedure is followed:
ACCMH1 Thursdays 12:00 pm
ACCMH2 Thursdays 08:00 am
ACCMPR Thursdays 08:00 am
ACCMDR Fridays 08:00 am
Non-Critical Patches: All non-critical patches will be available for automated installation as soon as they have been picked up from Microsoft but will only be installed by mutual agreement with the customer.
For non-critical patches, such as service packs, IS ITI Architecture will provide details of all patches available, via a CMS call, to IS Applications Division. Details of these patches, and the Microsoft ref number and link, will be passed to the Kx Business Owner, or representative, to be forwarded on to Kinetics. It is the responsibility of Kinetics to ensure that any non-critical patches being installed will not have an adverse impact on the service. Any outstanding non-critical patches will be highlighted and discussed at the quarterly service meetings, with a view to mutually agreeing a date for installation. In order to stay fully supported, all non-critical patches should be scheduled for installation at a mutually agreed slot. Scheduling of non-critical patches should be communicated via a CMS Call to the IS-Apps Applications Management CMS queue.
In the unlikely event that a critical patch adversely affects the Kinetics service, the Business Owner, or IT Support Team for Accommodation Services, should alert IS Applications who will treat this as a Critical event and work with Kinetics to assess impact and recover the service, without unduly impacting other University services.
Where possible server and service updates will be applied without loss of service by switching which node is active in the cluster.
8.2 Application Update Regime
Patches to the application should be discussed at the Service Meetings and scheduled through the Business Diary
Emergency patch requests should be submitted through the Call Management System to the IS-Apps Application Managemnt team marked as high priority (we would recommend this is followed by a telephone call). These will then be discussed with the Business Coordinator and scheduled appropriately.
8.3 Server Access
Access to the Kx service for the purposes of maintenance by Kinetic Solutions if and when required will be available using Microsoft Enterprise Manager tools over a VPN connection.
Visitor accounts with VPN access will be setup in the Visitor Registration System by Accommodation Services. The currency of the visitor accounts will be controlled by the Business Owner, or representative.
Any further access e.g. Remote Desktop will be handled on a request by request basis as needed. In this instance, Kinetic Solutions should alert the Business Owner to the requirement for this access who in turn should place a request with IS Applications.
Any changes Kinetic Solutions or IS make to the server configuration should be documented and logged within the IS Change Control System.
9 User Training
Not applicable.
10 Charging
10.1 Annual Charges
See main support Service Level Agreement document section 6.1.
10.2 Charges for Additional Storage
Additional Storage and Backup costs can be calculated at;
http://www.ucs.ed.ac.uk/fmd/unix/storage/Infrastructure_SANcalc.html
Planned downtime is required for the provision of additional SAN storage. A period of 4 weeks notice should be allowed to mange the request, with planned downtime being scheduled a minimum of 10 working days prior to the downtime.
10.3 Charging Procedures
See main support Service Level Agreement document section 6.2.
11 Changes To This SLA
See main support Service Level Agreement document section 7.
12 Re-Negotiating This SLA
See main support Service Level Agreement document section 8.
13 Service Reviews
See main support Service Level Agreement document section 5.5.
Appendix 1: Roles and Responsibilities
The following is a summary of the roles and responsibilities of all parties involved in the support of the Kx Software service.
KX Software Business Owner (Service Manager / Business Support Contact)
The Business Owner is responsible for;
· Management and authorisation, including required communications, for any updates to either the infrastructure or the Kx Software application.
· Payment of service contracts
· Authorising scheduled downtime
· Reviewing service reports and attendance at service meetings
· Setup of VRS account to allow Kinetic Solutions remote support
The Kx Application Business Owner may decide to delegate some or all of these activities to a nominated representative(s).
Kx Application End User
The Kx Application End User is any user type of the Kx application. The Active Directory group ‘Kinetic’ permits user access to the file store.
IS (ITI, Applications Service Management, Project Services and Production Management
IS Applications will be responsible for the hosting of the Kx database and related file stores. Server facilities management functions are delivered by IS IT Infrastructure Division on our behalf. This involves;
· Managing the Server Environment (IS ITI Architecture)
· Cluster, Servers, HDD and Operating System (IS ITI Architecture)
· SAN Storage (IS ITI Unix Systems)
· Sql Server (IS Applications)
· Security Services (i.e. Firewalls) (IS Applications)
· Recovery (IS Applications, IS ITI Unix Systems and IS ITI Architecture)
· Backup (IS Applications and IS ITI Unix Systems)
· Storage Capacity Management (IS Applications and IS ITI Architecture)
· Hardware Fault Rectification, redundant server switch-over when required and Disaster Recovery (IS ITI Architecture)
· Database Server patches (IS Applications)
· Escalation and Relationship Management (IS Applications)
· Production of service reports (IS Applications)
· Identification/notification of required updates to infrastructure (IS Applications and IS ITI Architecture)
· Where required IS Applications will establish a Remote Desktop Connection, via VPN, to the server for fault resolution and for installation of patches.
Kinetic Solutions
Kinetic Solutions will be responsible for installation and configuration of the KX database and will advise on access permissions and security to relevant parts of the file store. This involves;
· Change Management of the data supported by the MSSQL database service
· The Kx Application, database structure and content
· Patches to the Kx Application
· Support the Dtsearch application – should an error occur.
· Identification/notification of required updates to the Kx application
IS Support Team for Accommodation Services
The IS Support Team for Accommodation Services will be the first line support for the Kx Application End User and will be, among other things, responsible for;
· resolving incidents and faults as appropriate
· logging reported incidents and faults via the Call Management System and, if required, directing the call to IS Applications, Kinetic Solutions, or other authorities/departments as appropriate
· establishing and maintaining the Active Directory security group (including access for the Kinetic Solutions remote support VRS id).
Accommodation Services IT Technical Representative (is this role needed?)
The Accommodation Services IT Technical Representative will be responsible for advising the Kx Application Business Owner (or representative) on technical matters that may arise during the length of this contract, specifically they will;
· Interpret IT matters
· Attend Service Meetings
DSP
DSP have no active role in delivering or maintaining the Application or Hardware. Due to the nature of DSP’s involvement in the development of this environment it may be necessary to approach DSP for further consultancy work should the need arise. IS Applications Division – Production Management will be responsible for maintaining the relationship with DSP on these occasions.
Service Level Agreement for Accommodation Services Kx application Hosting Service Page 1 of 11