|
Executive Summary
|
|
|
Deconstructing the Service Level Agreement.
A technical evaluation of host management quality of service guarantees
Executive Overview
Possibly the most vital factor relevant to your selection of a host management provider is the Service Level Agreement (SLA) offered by the provider. An SLA defines the level of service you should expect to receive from your provider – and defines your remedy when they fail to deliver guaranteed levels of service. In the new economy, the success of your e-business relies on a web of outsourced Internet hosting infrastructures. The provider hosting your vital business systems must be prepared to deliver the level of service you and your users expect. The SLA is a written agreement between you and your provider clearly defining these expectations. But the agreement is only the foundation of a solution – can your service provider actually deliver? Use proper due diligence when evaluating your hosting provider’s SLA. Let’s face it. A written agreement is worthless if the commitments it makes aren’t backed up with solid engineering principals and careful execution. While most SLA’s offer predefined remedy in the event of failure – no remedy is sufficient cure for broken commitments. Be diligent in your technical evaluation of the service provider’s infrastructure. Demand specific and detailed information. Don’t stop until you are satisfied.
What should you expect from an SLA?
The infrastructure of e-Business is complex. It is built upon multiple layers of hardware, software, public utilities, multiple network providers and managed by the hands of human engineers. This complexity practically guarantees failure. But accepting failure as imminent is the first step to writing a successful SLA. Follow a process of defining your level of fault tolerance and expect an SLA with an engineered infrastructure to match.
Areas of possible service failures include:
Power – All electronic systems need power. While this seems basic and fundamental, many providers fail to effectively plan for power requirements as they grow. There are three primary concerns to address in your SLA:
1. Immunity to power failure – A service provider should have adequate UPS and/or backup generators to keep power online for several days. More sophisticated providers will purchase multiple power grid connectivity and diesel powered generators for complete public utility independence.
2. Power conditioning – Online power conditioning systems will guard against the common inconsistencies in
public utility or generator provided power. Computer and network gear is sensitive to power fluctuations.
Consistent power levels ensure longer equipment life.
3. Provisioning – Just like network bandwidth, power is not unlimited. But unlike network bandwidth, power may not be oversold. Over selling will cause inconsistencies and ultimately complete failure. As your service provider grows, power availability must be provisioned properly and guaranteed at the level you purchase. Your exact power requirements should be documented in Amps and included in the SLA.
Attention to details can make the difference. When visiting the provider’s facility, look for cable management systems and attention to neatness. All power receptacles should use lockable outlets, such as Hubbell’s twist lock. Providers run new cable daily – this basic detail demonstrates a sophisticated knowledge of computer room operations.
Environmental controls – When electronic systems consume power, heat is generated. For this reason, most electronic equipment, including servers and network gear, is rated in BTU’s. Likewise, when air conditioning equipment is installed in a computer room, the room is rated in cooling BTU’s. The SLA should document and guarantee adequate cooling requirements will be provided to your specific equipment.
Internet bandwidth Quality – Unfortunately, Internet outages are common. If your application is connected to the Internet, your SLA should contain Internet connectivity guarantees. The SLA should cover the following bandwidth quality issues:
1. Failure resiliency. Avoid dependence on any single Internet connectivity provider. The SLA should document how a service provider will ensure resiliency in the event of failure on any single Internet provider. This is commonly achieved with BGP4 routing and Autonomous network configuration. With proper engineering and management, Internet connectivity guarantees are possible. Research the provider’s techniques for achieving high availability.
2. Latency. Sometimes routing or capacity troubles on an Internet provider’s backbone will cause unnecessary latency. This will ultimately equal poor and unacceptable performance for your user. Latency is much more difficult to guarantee than complete failure. But performance is really what you care about. The SLA should contain a guaranteed maximum acceptable latency rating measured in ping times between generally accepted network points originating from the hosting center. Be satisfied the provider is recording latency ratings, actively using techniques for guaranteed availability and reporting loss of quality.
3. Bandwidth guarantee. It is a common practice for hosting providers to over sell their available bandwidth. This practice is perfectly acceptable, as long as sufficient expansion guarantees are included in the SLA. With this policy, it is important to evaluate the provider’s measurement and reporting policies. Your specific requirements are likely very dynamic and difficult to predict. For this reason, you should only select providers with ample ‘burstable’ bandwidth. However, it is your responsibility to notify your provider for your expectations. No provider can guarantee infinite bandwidth. For this reason, most SLA’s include a provision for a guaranteed Committed Information Rates (CIR). Your hosting provider should guarantee the CIR is available at a minimum level of time, with provision to burst above the CIR. Lastly, it is vital to evaluate the provider’s measurement and reporting policies.
Networking hardware and backbone infrastructure – A network is only as strong as its weakest single point of failure. Unfortunately, many providers rely heavily on networks with multiple single points of failure. If an SLA is to include guaranteed connectivity, it must define to what point in the network infrastructure connectivity is guaranteed. Some will only guarantee ‘gateway’ availability. Others will guarantee connectivity up to the local switch located in your private network cabinet or cage. Important factors to consider when writing an SLA is what level of redundancy you will require on the provider’s network hardware and backbone gear. Reliability of this equipment is generally considered very high. But the fact is, most equipment will eventually fail. Some considerations for high availability infrastructure techniques:
1. HSRP. Hot Standby Router Protocol is a technique, which ensures that failing gateway routers are automatically detected and recovered without notice. The most sophisticated providers will, at a minimum, duplicate and cluster their router gear using HSRP.
2. EIBGP. Enhanced Interior Border Gateway Protocol is a routing technique utilized on all routers within a provider’s network to ensure backup paths exist between routers. EIBGP provides resiliency from hardware failures and traffic congestion.
3. SSRP and PNNI. Simple Server Redundancy Protocol and Private Network-to-Network Interface protocols
enable multiple, redundant ATM links to be configured between backbone network switches. The protocol detects network loops and ensures that only one path is used per ATM connection. PNNI and SSRP ensure all equipment between the gateway router and your servers are resilient to any single points of failure. Facility security – The physical data center security policies used by the service provider should be written in the SLA. Critical factors include the types of security equipment used, standard response times and guaranteed audit trails. Sophisticated providers will require biometric security entry devices and employ audit logging of facility access in customer accessible databases.
Customer support – Your methods of accessing a provider’s customer support department should be written in the SLA. If your e-business is a 24 by 7 by 365 operation, you should select a provider to match. Outline the specifics of guaranteed response times, telephone and email staff availability as well as engineering escalation procedures. More sophisticated providers will employ automated monitoring systems to detect failures and automatically notify customers, as well as its own customer support departments. Any expectations for automated monitoring should be written into the SLA. Application performance – Few hosting providers will guarantee availability and performance of customer installed or managed applications. Too many variables exist. However, if your expectation of the hosting provider is guaranteed levels of application level performance, these should be clearly defined in the SLA. The most sophisticated hosting providers will write application performance guarantees if they maintain control of application hardware. Be prepared to give up control and purchase equipment specified and certified by the provider. Your access to the equipment will be limited in most cases and require considerable oversight.
Depending on the solution, any of the following factors may be considered for the SLA:
1. SQL Server or Oracle Database query response times. Providers offering guaranteed query response times should be required to employ certified database administrators in the platform of your choice. Be prepared to give up administrator’s control of your databases, as well as restricted access to performing maintenance.
2. RAID level or SAN storage availability. Providers taking control of storage networks will likely store all but the essential information in online storage area networks. Be sure to write SAN or external RAID guarantees into the SLA. The additional complexities introduced with these solutions require high availability engineering. SANs offer incredible reliability and real-time data backup.
3. Application performance. Very sophisticated providers may have developed engineering expertise with specific applications. If you expect the provider to take responsibility for a specific application’s performance, write performance metric expectations in the SLA. Be sure the provider has engineering experience with the specific application, utilizes quality assurance monitoring systems and specifies a response procedure for scaling performance when limits are surpassed. In any case, be prepared to give up control of your systems. If a provider takes responsibility of application level performance, they will likely require hardware and software to be certified by their engineers. The cost for these solutions are considerably higher, so be prepared to pay for the engineering expertise required to ensure expectations are achieved.
1223 Turner Street Suite A Lansing, Michigan 48917
tel: 517/346-5041 fax: 517/346-5042 email:info@crt.net
© 2008 Control Room Technologies, LLC International rights reserved.
CoreComponents™ is a registered trademark of Control Room Technologies, LLC |
|
|
 |
|
|
