Author Archive: JD Wells

June 30, 2016

HA, DR, GSLB, LB: The What’s What and Who’s Who of Uptime

As a SoftLayer sales engineer, I get the opportunity to talk to a wide range of customers on a daily basis about almost everything under the sun. This is one of my favorite parts of working at SoftLayer: every day is unique and the topics range from a standalone LAMP server to thousands of servers in a big data cluster—and everything in between. It can be challenging at times, due to the infinite number of solutions that SoftLayer can run, but it also gives me the chance to learn and teach others. In this blog post, I’ll discuss high availability (HA), disaster recovery (DR)global server load balancing (GSLB), and load balancing (LB), as I occasionally hear customers mix up the terms, and I think a little clarity on the topics could help.

Before we dive into the differences, let’s define each in alphabetical order (I did take a stab at stating this in my own words, but Wikipedia does such a good job that I paraphrased from its descriptions and added in a little more context).

  • High availability (HA): HA is a characteristic of a system, which aims to ensure an agreed level of operational performance for a higher than normal period. There are three principles of system design in high availability engineering: the elimination of single points of failure (SPOF), reliable failover, and failure detection.
  • Disaster recovery (DR): DR involves a set of policies and procedures to enable the recovery or continuation of systems following a natural or human-induced disaster. Disaster recovery focuses on keeping all essential aspects of a business functioning despite significant disruptive events.
  • Global server load balancing (GSLB): GSLB is a method of splitting traffic across multiple servers using DNS and geographical locations as the means to determine where request traffic will be sent.
  • Load balancing (LB): LB is a way to distribute processing and communications evenly across multiple servers within a data center so that a single device does not carry an entire load. LB is essential in situations where it is difficult to predict the number of requests issued to a server, and it can distribute requests that would have been made to a single server to ease the load and minimize latency and other issues.

Now that we've defined each of these topics, let’s quickly check off the main points of each topic:

HA

  • No single points of failure (SPOF)
  • Each component of a system has as at least one failover node

Hardware Recommendations

  • If a server is part of an HA pair, it is recommended to run the OS on at least a RAID 1 group and DATA partitions on a RAID 1, 5, 6,10, or higher group
  • If the system is part of a cluster, it is always recommended to run the OS on at least a RAID 1 and DATA partitions can be optimized for storage capacity 
  • Redundant power

Network Recommendations

  • Dual path networking/uplinks
  • Utilize portable IP addresses for HA/service configurations as primary IPs assigned directly to a server or VLAN is specific to that instance and can lead to IP conflicts or unintended disruption in service
  • Database systems are configured at the application for HA or clustering
  • Web/app systems are configured at the OS or app in a HA pair or are placed behind a load balancer

DR

  • Companies should analyze their infrastructure and personnel assignment to identify mission-critical system components and personnel
  • A plan should be developed to identify and recover from a disaster; this plan should also include recovery time objective (RTO) and recovery point objective (RPO) to reflect the business model
  • A secondary data center is recommended to mitigate risks of a major natural or human disaster
  • Mission-critical systems should be on standby or quickly deployable to meet or beat a company’s stated RTO
  • Backup data should be stored offsite and ideally at the secondary DR site to reduce recovery time
  • Once a plan is in place, mock fail-overs should be performed regularly to ensure the DR plan is fully executable and all parties understand their roles

GSLB

  • Complete, independent systems should be deployed into two or more DC locations
  • Each location is accessible via a unique IP address(es)
  • Data systems should be designed to operate regionally independent and possibly synchronized on-schedule or on-demand
  • Each location hosts at least one LB instance that supports GSLB
  • Based on availability of each site, the location of a user, or data sovereignty regulations, users are directed to an available site via DNS resolution
  • Once a user has been directed to a site, standard load balancing takes precedence until the time to live (TTL) of the DNS resolution expires

LB

  • Each server within a LB pool should reside in the same DC as the LB, or performance may degrade and health checks may fail
  • A minimum of two servers should be included in a LB pool
  • Load should be spread across servers based on the specification of each server; if all servers are equal in specs, the load should be shared equally
  • Each server in a LB pool will need a public IP address and active public interface to respond to Internet requests
  • When possible, it is recommended to leverage LB features such as SSL offload to minimize load on web servers

I hope this clarifies the terms and uses of HA, DR, GSLB, and LB. Without background, tech jargon can be a bit ambiguous. In this case, some of the terms even share some of the same acronyms, so it’s easy to mix them up. If you haven't had a chance to kick the tires of the SoftLayer LB offerings or if you’re looking to build a DR solution on SoftLayer, just let us know. We’ll be happy to dive in and help you out.

- JD

 

Categories: 
November 18, 2014

Your Direct Link into the SoftLayer Cloud

Remember the days when cellular companies charged additional fees for calls placed during peak hours or for text messages that exceeded your plan?

The good news is those days are pretty much over for cellular services thanks to unlimited text and data plans. The bad news is there are cloud and hosting providers who adhere to those same old billing practices of charging customers for every single communication their severs send or receive.

At SoftLayer we do things differently. All of our servers come with included terabytes of outbound bandwidth—5TB for virtual servers and 20TB for bare metal servers. Now you probably just noticed I specifically mentioned outbound bandwidth, and that's because we don't charge anything, nothing, zip, zilch for all traffic inbound to any of our servers, nor do we charge for any bandwidth usage across our Global Private Network.

Imagine the possibilities of what you could build on a Global Private Network that essentially comes free of charge just by being a SoftLayer customer.

  • How about building that true disaster recovery solution that you’re always talking about?
  • How about moving all of your backups offsite now that the necessary bandwidth requirements and costs aren’t standing in your way?
  • Or maybe it’s time to offer your app a little GSLB now that replicating data across remote sites, which hasn’t been feasible over the public Internet due to latency or security concerns, is now feasible?

We help put all these dreams within grasp thanks to Direct Link. Tap directly into our Global Private Network at connection speeds of 1Gbps or 10Gbps to establish a Direct Link into any of our 19 network PoPs (more PoPs are being added regularly). You’ll have the ability to seamlessly extend your private networks directly into SoftLayer. Not only does a Direct Link give you access to one of the world’s largest and fastest private networks, it gives you access to elastically scale your compute and storage on demand.

Many companies look to the cloud as a way to reduce capex and adjust spending on demand but hesitate to move workloads due to latency or security concerns. I'd like to say that latency isn’t even worth thinking twice about at SoftLayer. But don't take my word for it; take a peek at our Looking Glass, and see for yourself. In regards to security, a SoftLayer Direct Link enables you to build and deliver secure services on our private network without having to expose your servers to the public Internet.

For more information on Direct Link and connectivity check out KnowledgeLayer or this blog where the author digs into the technical details and explains how enterprise customers benefit from Direct Link with GRE Tunnels.

Thanks,
JD Wells

Categories: 
Subscribe to Author Archive: %