Avoiding Single Points of Failure: “Careful with that Backhoe, Eugene!”

Avoiding single points of failure has been part of our philosophy—and design—since the origins of our company. The philosophy includes avoiding single points of backhoes and diggers as well. Avoiding backhoes is no laughing matter, as the actions of heavy equipment operators, whether in front of your building or miles away, are beyond your control.

This is why SingleHop has multiple network providers for each of its data centers, and why we require each network provider to enter their cables from a different side of the building. That way a careless move with a backhoe can only take out one provider’s fiber. Backhoes and fiber optic cables have what we might call a complicated relationship. The two are wonderful together early on, as in: Backhoe digs channel for cable runs. But things rarely go well should the two unexpectedly meet later in life.

SingleHop was Built with Redundancy in Mind

Starting at the beginning of the process, we use multiple power providers resourced from separate areas of the power grid, so that an outage in one geographic area doesn’t take down all of our sources. The power feeds are run into multiple PDUs which are run back to multiple diesel-powered generators, so the chance of ever losing power is miniscule. And, as noted above, we use multiple network providers, each entering the facility from a different part of the building.

Backhoes and fiber optic cables have what we might call a complicated relationship.
Backhoes and fiber optic cables have what we might call a complicated relationship.

In the server rooms, each top-of-rack switch is connected into two Cisco enterprise series routers.  Each router has multiple upstream providers on them, which means we can lose an entire router, and its load will just failover to the second router. Traffic may slow until the router is replaced, but everything keeps running. Our redundancy applies to load balancers. Whenever we deploy one load balancer—spreading work across Web servers, for example—we deploy a second in case the first should ever fail. In short, we’ve created our infrastructure with redundancy in mind to avoid any chance of their being a single point of failure.

We Do the Same for Your Application Deployments

The search for—and elimination of—single points of failure should continue when it comes time to deploy solutions. We take pride in our sales engineers who work with customers to design and deploy robust solutions that are free of single points of failure. If you’ve got a complex solution to deploy, our highly trained staff will go over your plans—whether over the phone, via e-mail, or in person—searching for weak points that can be toughened through adding redundant pathways. This may include mirroring database servers, creating active/passive clusters for DNS servers, or providing backup load balancing for Web servers, or a range of other proactive measures.

We essentially break out all of the different physical components and make them all redundant. We also help you determine your backup strategies for the different elements of your solution. (While you may want transaction-based protection for databases, static content on Web servers can have a less stringent schedule. Going through the process of planning a robust application deployment, also provides a foundation for developing the disaster recovery plan that every organization should have to speed recovery should something catastrophic ever occur.

Looking Ahead

I'm really excited about our VMware-powered Enterprise Public Cloud launch that is coming up soon. Our built-in redundancy makes it an enterprise-level public cloud, making it easier than ever for engineers or system administrators to use the cloud to design their own fault tolerance solution for whatever application they want to deploy.