Datacenter – Database Hosting SLA

– Is this service for standing up a Microsoft SQL Server 20xx instance on a VM or is the service the provisioning of a database on in an existing SQL Server cluster/environment maintained by UNM IT?
– If this service is for using an existing SQL Server cluster/environment, should the SLA define how the database can be remotely accessed or managed?
– If this service is for the provisioning of a VM with a DBMS, will the user have remote access to the server?
– Can database backups be set for more granular levels of recovery should the application owners request it?
– It seems as if this SLA is blending SLAs for database hosting and the application that uses the database that UNM IT may not have any control over or may live on a different server? Is it assumed that the application and database live on the same VM?
– Should service catalog specify the versions of Oracle and SQL Server?
– Does there need to be a statement that this SLA excludes MySQL databases used by departmental web sites?
– Is there a time-to-restore that can be included in the SLA?
– The colocation SLA had a clause requiring users to disclose storage of certain types of data to UNM IT. Should that apply in this case? Should the Data Owner and/or Custodian also be notified if this hosted database will be used to store sensitive information?

Thank you for taking the time to carefully review the Database Hosting SLA. Your feedback will help us as we work to rollout this service to more UNM departments. Here are initial responses to your questions I have duplicated the questions, just to make sure it is clear which question we are answering.

Q – Can database backups be set for more granular levels of recovery should the application owners request it?
A – Yes, additional storage may be purchased to increase the frequency and retention periods for database backups.

Q – It seems as if this SLA is blending SLAs for database hosting and the application that uses the database that UNM IT may not have any control over or may live on a different server? Is it assumed that the application and database live on the same VM?
A – This service requires the database and application to reside on separate servers. This follows recommended database and security best practices.

Q – Should service catalog specify the versions of Oracle and SQL Server?
A – Section 2.1.2 in the SLA specifies “UNM IT will only install supported database software” and refers people to the Service Catalog, so I agree with you. We will not specify specific versions, since those are subject to change. We will clarify in the Catalog that we provide database support for database versions that are currently covered by vendor support commitments (Oracle and Microsoft).

Q – Does there need to be a statement that this SLA excludes MySQL databases used by departmental web sites
A – The preference is to avoid listing all database exclusions. The SLA states this service is for Oracle and/or SQL Server databases.

Q – Is there a time-to-restore that can be included in the SLA?
A – Not at this time. Recovery time varies greatly based on the nature of the failure and the size of the database. In the case of incidents, we will strive to meet the standard resolution timeframes identified in Section 6.2.

Q – The colocation SLA had a clause requiring users to disclose storage of certain types of data to UNM IT. Should that apply in this case? Should the Data Owner and/or Custodian also be notified if this hosted database will be used to store sensitive information?
A – We will comply with UNM IT Security policies and procedures. Those are separate from this SLA. Because the hosted database will reside on a hosted server/Virtual Machine, there is a standard security questionnaire that will be completed to document the nature of the data in the database. That provides the opportunity to know which policies and procedures apply.

Although at this point Law has no plans to use this service, we reserve the right to create a customized SLA specific to our needs with mutually-agreed upon consequences for both Law and UNM IT.
Cyndi Johnson

 This is the SLA for the database hosting service that IT offers today.  We are open to discussing customized agreements that are mutually agreed upon. 

I had a couple questions about this SLA. Seems like at one point there were discussions about offering up VMs through LoboCloud with standard configurations. For Example, Server 2012 R2 VM with SQL Server preinstalled and appropriate firewall rules in place. Is that still the direction UNM IT is looking at going? Would that fall under the LoboCloud SLA or the Database Hosting SLA? As Rooney mentioned if this is going to be a hosted VM then it sounds like some sort of tie in with the LoboCloud/Virtual Hosting SLA is needed.

I disagree that supported versions of the DBMS’s should not be in the Service Catalog, when reviewing vendor solutions departments need to be able to see what versions of DBMS’s are supported in UNM’s infrastructure. This should be tracked in the Service Catalog and even potentially this SLA. UNM as a customer of these services needs to agree that the versions of DBMS’s UNM IT is supporting meet the business requirements of the University.

2.1.1 Assuming this is talking about the supported DBMS’s, shouldn’t UNM IT Security already know about security gaps identified by the vendor? Or is this talking about the actual application that the Database is supporting?

5.2 Exceptions to service request response times should be explicitly defined. “Week before Fall semester starts” etc. Different UNM Departments may have different business needs.

I see a few asterisks at the end of sentences that suggest there is a footnote or disclaimer, but I can’t find what they are referencing.

Under 2.1, would it make sense to include storage and tablespace monitoring? What about performance monitoring?

2.1.2 – is migration of data from production to integration or some other from of data refresh on integration systems part of “Data recovery” portion of the service, or should that be spelled out separately?

Is application of special configuration changes for the database(s) limited to vendor-recommended changes, or are other departmentally determined specialized configurations covered? e.g. a peer or industry recommendation not specifically endorsed by the vendor?

I’m assuming more tuning is possible as a paid consultation?

2.2.2 – When recommending the amount of CPU, RAM, storage etc. needed to right size a database, is there a process for resolving that or evidence collection practices that would help departments analyze the need?

3.1 – add bullet “Plan database upgrades with the contracting department” ?

Would it be good to add in there somewhere that database availability and hosting can be purchased to comply with any of the data center tiers defined in the Data Center standard?

Q – I had a couple questions about this SLA. Seems like at one point there were discussions about offering up VMs through LoboCloud with standard configurations. For Example, Server 2012 R2 VM with SQL Server preinstalled and appropriate firewall rules in place. Is that still the direction UNM IT is looking at going? Would that fall under the LoboCloud SLA or the Database Hosting SLA? As Rooney mentioned if this is going to be a hosted VM then it sounds like some sort of tie in with the LoboCloud/Virtual Hosting SLA is needed.
A – Yes, that is the direction UNM IT will be pursuing. We do not currently offer a VM with a standard database installed through LoboCloud but plan to do so in the future. At this time, when we deliver a hosted database solution on a hosted VM, both SLAs apply.
Q – I disagree that supported versions of the DBMS’s should not be in the Service Catalog, when reviewing vendor solutions departments need to be able to see what versions of DBMS’s are supported in UNM’s infrastructure. This should be tracked in the Service Catalog and even potentially this SLA. UNM as a customer of these services needs to agree that the versions of DBMS’s UNM IT is supporting meet the business requirements of the University.
A – We are currently committed to support those database versions that are actively supported by the vendor. I agree that it will be helpful for departments to be able to easily find that information. We will update the Service Catalog and include a link to the vendor support list – that will be the most accurate place for departments to check.
A – 2.1.1 Assuming this is talking about the supported DBMS’s, shouldn’t UNM IT Security already know about security gaps identified by the vendor? Or is this talking about the actual application that the Database is supporting?
A – You are correct – this specifically refers to security gaps or risks for the application(s) using the database.
Q – 5.2 Exceptions to service request response times should be explicitly defined. “Week before Fall semester starts” etc. Different UNM Departments may have different business needs.
A – I will follow up on this question.

Thank you for the questions and the feedback

• This reply was modified 8 years, 1 month ago by loritaf.

Q – I see a few asterisks at the end of sentences that suggest there is a footnote or disclaimer, but I can’t find what they are referencing.
A – The * “answer” is at the bottom of section 2.1.2. I see where the confusion is, especially for the asterisks outside that section. I will modify.
Q – Under 2.1, would it make sense to include storage and tablespace monitoring? What about performance monitoring?
A – Storage monitoring is covered in 2.1 as “capacity monitoring”. On the Oracle enterprise databases supported by UNM IT, tablespace monitoring is done currently. It is not done on departmental/non-enterprise databases at this time. Performance monitoring for this service is currently covered under “capacity monitoring” and is limited to Database availability, CPU, RAM and Storage utilization. I think clarification on the definition of “capacity monitoring” is appropriate. I will do that.
Q – 2.1.2 – is migration of data from production to integration or some other from of data refresh on integration systems part of “Data recovery” portion of the service, or should that be spelled out separately?
A – Data recoveries are in response to an incident. Data refreshes are mentioned separately in Section 2.1 – “And consulting services for database tuning, major upgrade planning and execution, data refreshes, assisting with application triage, and special service monitoring needs.”
Q – Is application of special configuration changes for the database(s) limited to vendor-recommended changes, or are other departmentally determined specialized configurations covered? e.g. a peer or industry recommendation not specifically endorsed by the vendor?
A – We are happy to apply special configuration changes requested by a department. The language in the SLA is to encourage departments to get configuration recommendations and those often start with the application software vendors. I will add the clarification to 2.1.2
Q – I’m assuming more tuning is possible as a paid consultation?
A – Correct
Q – 2.2.2 – When recommending the amount of CPU, RAM, storage etc. needed to right size a database, is there a process for resolving that or evidence collection practices that would help departments analyze the need?
A – Our standard recommendation when we work with departments is to encourage them to contact the application vendor(s) directly for sizing recommendations. Many vendors provide explicit resource minimums with their installation guides. Part of the IT Database Hosting service is to configure the database, including initial tuning.
Q – 3.1 – add bullet “Plan database upgrades with the contracting department” ?
A – Yes, I will add that
Q – Would it be good to add in there somewhere that database availability and hosting can be purchased to comply with any of the data center tiers defined in the Data Center standard?
A – Not at this time. We do not currently provide Database hosting in every data center tier.