Best practices to vet hosting providers

Question

What are best practices for vetting a hosting provider? Other than simply requiring SAS-70 certification, what would you ask to ensure a hosting provider's plant, network and server infrastructure is stable and secure?

I'm not looking for a list of favorite hosting companies, but advice on asking meaningful questions of hosting candidates.

Answer 1

If you can, I recommend touring their facilities. Even if you have an unskilled eye, you can often get a good "feel" the place.

Does their cabling and facility appear neat and professional? (and are they steering you to specific "presentation" installations) Does the security, power systems and AC match up to their published specs? Does the person giving the tour seem to have a good working knowledge of the facility. (They may not be an expert, but they should generally at least know enough to know who's responsible for the gear and what not to touch.) Check the Emergency Power Off switches near the room entrances, are they covered, tamper resistant, and is there a security camera situated so that it can see the switch? (as one of the leading causes of datacenter failure, it really, really matters... I had techs that were employed for years push the button, because it turns out no one ever told them not to and they wanted to see what it did.)

I've had a hosting provider advertise "redundant" generators... when I toured their facility they pointed to one and said "that's for the Air Conditioners, and the big one over there is for the computers." (I wondered how long the datacenter would take to overheat if the Air Conditioning generator failed to start.)

As the previous poster said, ask a lot of questions about DR services, how often backups are tested and if/what their plan is for a total datacenter failure. (Fire, water damage, natural disaster. Many company spend a fortune making a single datacenter redundant, then are caught flatfooted when the facility is knocked offline)

Webhostingtalk.com can also be a good reference for reviews taken with a grain of salt. And as with any business relationship ask for and verify references.

Mark

Answer 2

Redundancy, backup, and security should be some of your major concerns.

1. What happens if a car crashes into, or there's a small fire in the side of the building where the primary ISP is cabled into? (ie, multiple providers/peers, physically separate incoming lines, separate routers, etc) Is the entire chain redundant (incoming routers, firewalls, internal routers, switches, DNS/DHCP/other internal infrastructure, machine cabling, power and power cabling) You may also ask, "At what machine, power input, cable rack, generator can I take an axe to which would cause your entire operation to stop?"
2. Backup for user machines (if requested), router configurations, cabling diagrams, etc. Where is everything stored that needs storing, and should the worst happen do you have enough information stored offsite to get everything back up in very little time somewhere else? What equipment do you keep online, near online, or offline for replacement, and what is the guaranteed maximum period of time from problem detection to replacement, configuration, and back online in the worst case equipment failure?
3. Who has acces? How is that access granted? Who observes the operation of the data center and its employees? What types of violations have you seen in the past, and how were they handled? What is your insurance liability - does it extend to the customers of your customers (ie, credit card details stolen due to someone taking a physical server out of your facility) or just to your direct customers?

-Adam

Answer 3

As well as asking about their redundancy and disaster recovery plans, make sure you ask how often they are tested and if you can see logs to prove they have been tested on that schedule.

Thus speaks someone who was caught up in major hassle recent because a DC's secondary internet access failed to take over when the primary failed, leaving us with a massive (almost two working days) outage...