Hosting Partners  |  About Us  |  Blog  |  Legal  |  Portal Login

The Planet Blog

 

Kevin HazardAt the 2009 Cloud Computing Conference in Santa Clara, Calif., The Planet Director of Product Management Rob Walters was one of five experts invited to participate in a panel discussion about enterprise-level cloud computing – whether it’s a far-off dream or a present-day reality. Conference Chair Jeremy Geelan covered everything from whether the term “cloud” was too broad to be useful to whether private clouds and public clouds can coexist.

I caught up with Rob in the expo hall to have him weigh in on each of the questions for our loyal blog readers (you!):

I love the analogy he uses to explain why “the cloud” is such a difficult concept to explain. It seems to be a paradigm shift unlike any we’ve seen in recent memory, so the transition from hype and confusion to understanding and adoption should prove to be an interesting adventure over the next few years.

One of the most interesting questions asked of the panel was whether or not we’d be talking about cloud computing in 10 years. The unanimous answer: No. Why? The resounding sentiment is that shift toward “the cloud” will be so pervasive that a given platform’s “cloudiness” will be implied. This opinion is shared by a group of experts at a “cloud computing conference,” so there may be a little bias here … What do you think? Will the cloud take over and become the de facto standard or will demand for traditional IT remain in the midst of the cloud’s surge?

-Kevin

Kevin HazardSince Halloween falls on a Saturday this year, The Planet’s annual Boo Bash is happening today. As you can see from our archives, there are a lot of creative people around here, and when a costume contest challenge is issued, you’re bound to get some interesting results. I’ve already seen a fully costumed Ghostbuster, a bumble bee, and about 45 people – including our CEO and CFO – dressed as Todd Mitchell. They say imitation is the sincerest form of flattery, so Todd must feel VERY flattered.

We will post our costumed competitors on The Planet Flickr for all to see, and you can post a comment here to vote for your favorites. Click the picture of “Todd” below to go directly to the Boo Bash 2009 album.

Todd Mitchell

To let you share in today’s costuming, we’ve got a present for you. As a part of our fundraising efforts to support the American Heart Association, we printed shirts for employees who donate. The shirt design has been so popular internally that I made it into a few wallpapers that you can use:

You Got Served

Versions Available:
Dual-Monitor Setup (2560 x 1024)
Single Monitor – Server Only (1280 x 1024)
Single Monitor – “You Got Served” Only (1280 x 1024)

After you get your desktop suited up in its new costume, remember to vote for your favorite Boo Bash 2009 entrant in the comment section below.

Trick or Treat!

-Kevin

Ben KeenerIn Know Thy Backups – Part I, we started discussing the most common strategies of backing up your data, and before we continue that discussion, I should clarify that we’re not talking about hardware configurations like RAID or backup products like Evault and Data Protection Servers. These backup schemes can be executed without spending a dime on additional equipment or resources. While there are best practices and recommendations for making backups and keeping them safe, if your budget is limited, you can protect and preserve your data using one of these schemes on your local workstation or on a secondary drive in your server.

When we looked at the full server and simple incremental backups in our previous post, we noticed a significant limitation: losing a single backup can be catastrophic to restoring data. In the next two schemes, we’ll evaluate solutions that protect us from this vulnerability.

Differential Incremental Backups

A differential scheme requires a full backup reference point and then makes a backup of all changes to the server from that reference point on each subsequent backup. This method requires more storage space than incremental backups but generally doesn’t need as much space as a full backup.

Based on the volume of changes made between the first backup, the reference point and the current backup, differential incremental backups may require additional server resources than an incremental backup. Simple and multi-level incremental backups constantly update the reference point with minimal load, while differential backups update the reference point with a new full backup.

Example: Differential Incremental Backups

As in the previous example, I am using a schedule of backups that starts with a full backup on Sunday, with additional backups on the following days. This time, I’m using differentials. Let’s say that on Thursday I find some inconsistencies in the database when compared to the paper files I received from a vendor. After investigating, I find that my database is corrupted. I determine that I will not be able to recover the database as it is, so I review my backups.

Somehow, I cracked the DVD that my Tuesday backup was stored on, but all of the other discs are here. I start by restoring the Sunday backup and then the Wednesday backup, hoping the corruption occurred after the backup was made. Thankfully, the restoration works, and we are up and running again after losing minimal data. If I had been using simple incremental backups, I would have been able to restore only up to Monday because Tuesday’s backup disc was broken.

Multi-level Incremental Backups

There’s a more granular and robust backup scheme that is less vulnerable than simple incremental backups and less server-intensive than differential backups: The multi-level incremental backup. Multi-level increments assign a level to each backup and then make a comparison against the last lower-level backup made. Only the changes between the reference point and the current data are saved.

This arrangement allows you to design a backup scheme around your needs and the capabilities of your server, and you can decide how many backups you will need for a full restoration to the latest restore point. You will control the number of backups required for a given restore by determining the number of levels in the system. In the event of a disaster, you need a single backup of each level, and each higher level backup must use the lower level as its reference point.

Example: Multi-Level Incremental Backups

This time I am in charge of a Sendmail server that is always under heavy stress. Because this server is extremely important to my business, I need to ensure both its availability and responsiveness at all times. I also need to maintain archives of the e-mail on the server. To do this, I decide to implement a multi-level incremental backup scheme since I need more granular backup configuration that does not generate a great deal of load on the server. This scheme meets that need. It still retains the weakness of incremental backups, but I partially mitigate those weaknesses with scheduling.

At the first of every month, a full backup is scheduled. This is my Level 0 backup, and it is named level0.name of the month. The following day I run a Level 1 backup. This backup holds only the changes since the most recent Level 0 copy called level1.first.name of the month. The subsequent days of that week, I create a Level 2 backup called level2.first.day of the week.name of the month. This process continues until the Sunday after the first Level 2 backup.

On the next Sunday, I make another Level 1 backup called level1.second.name of the month. The subsequent days of that week, I make Level 2 backups called level2.second.day of the week.name of the month. I continue in this vein with every Sunday being a Level 1 backup and the rest of the week being Level 2 backups until the end of the month. On the first day of the next month, I start all over with another Level 0 copy.

I make certain to save multiple copies of the files after I test the archive. I also check to be certain it’s not corrupted, to minimize the risk of data loss through a faulty archive. This scheme allows me to restore to any point within the month in just three steps, as long as all of the archived backups work.

If I need to restore the data from April 17, 2009, I would need the archives for level0.april, level1.third.april, and level2.friday.third.april. I would restore them in sequence from Level 0 to Level 1 to Level 2.

Choosing Your Backup Scheme

As I said in the beginning of this post, these backup schemes are available to you without the use of an additional server or any expensive backup management software. All of the above are viable options for making your backups; however, not every scheme is perfect for every situation. You should review your requirements and the available resources to determine which scheme best fits your needs.

-Ben

Ben KeenerMore often than not, server backups are misunderstood. With dozens of hardware options and hundreds of software options, finding the right backup can be intimidating. To assuage some of those fears and clear up a bit of that confusion, let’s go over a few of the most common backup schemes. This list isn’t all-inclusive, and the options presented shouldn’t be mistaken for backup plans. A backup scheme is simply a method of creating backups. A backup plan (or disaster recovery plan) is a scheduled implementation of a backup scheme. As we evaluate each scheme, we’ll look at the requirements, costs and benefits, and by the end of our tour, you can decide which best fits your business.

Before we get too far into the specifics of the different schemes, we should define some fundamental terms that we’ll use throughout the comparison:

  • An archive is a set of data that is being preserved
  • A reference point is a single archive against which comparisons are made
  • A restore point is the most recent working backup

The key question a backup scheme answers is this: “If a server suffers a catastrophic failure, what is needed to resume operations with minimal downtime and data loss?” Again, the backup scheme is not a complete disaster recovery plan — its focus is the restoration of data.

The four basic backup schemes we’ll compare are full-server backups, simple incremental backups, multi-level incremental backups and differential incremental backups. The primary considerations about the method that should be used are the server load generated by the backup process, the backup file size, and the speed with which a backup can be restored.

Full Server Backups

A full server backup is one of the simplest methods for a backup scheme. It takes only a single backup archive to create a restore point, which makes data restoration simple and fast. The drawbacks are the amount of time it takes to make the backup, the load it generates, and the total size of the backup. Each backup scheme we’re comparing uses a full backup of the server.

As we evaluate the other schemes, you’ll note they all start with a full backup as a reference point, and create their own restore points as they move forward.

Simple Incremental Backups

A simple incremental backup attempts to resolve some of the issues with full backups, and it does a good job. With an incremental backup, a single full backup is made that serves as both a restore point and the initial reference point. On subsequent backups, it becomes a little more complex. Instead of making a new full backup when it is updated, this scheme compares the current state of the server against the state of the server as it was in the reference point (the first full backup). If it locates any changes, it backs up those changes and generates a new snapshot of the drive as another reference point. This new reference point is then used for the next incremental backup.

This backup structure means the restore point on a server with this backup will consist of the initial reference point and all subsequent incremental backups that use this reference point. This dependency is the primary weakness in simple incremental backups: All of the backups — from the original reference point to the incremental additions recording changes from the reference point — must be uncorrupted and complete for the backup to fully restore the data. If any backup is missing, corrupt or incomplete, the restoration can’t be completed.

The server load created and storage space required for this type of backup is generally less than what you’ll see in a full backup scheme, especially when there aren’t many differences between the backup point and the reference point. On the other side of the spectrum, if the entire data set changes between backups, the storage requirements and server load will be the same as they were when full backups were being performed.

Example: Simple Incremental Backups

I am implementing incremental backups for a database that houses all of my users’ data. I decide I am going to start with a full backup each Sunday — the slowest day of the week for the database — and do an incremental backup on each subsequent day. This process starts over again every Sunday. On Friday, my server suffers a catastrophic hard drive failure. I am told by the technician who replaced the drive that the controller failed, and the heads were idly tapping the side of the drive cage. Everything on the drive is lost.

I gather my backups and begin to restore them on the new replacement drive. The backups from Sunday, Monday and Tuesday restore without a hitch, but Wednesday’s backup is corrupted and will not complete. This means I have lost all of the data from Wednesday and Thursday. Without Wednesday’s backup, the rest of my incremental backups are useless.

There are two incremental backup schemes that attempt to address this issue: the differential and the multi-level incremental backup schemes. In Part II of “Know Thy Backups,” we’ll explain the pros and cons of these methods, and you’ll be ready to plan your backup strategy.

-Ben

Todd MitchellIf you weren’t able to attend the cPanel Conference 2009 last week in Houston, you missed out on a great show. With all the networking events, educational sessions and vendor booths to visit, it was pretty tough to keep up as a participant, so the cPanel team deserves a high-five or two —physical or virtual — for having everything so well prepared.

As you may have heard, I led a session about “Disruptive Technologies: The Road from Disruptive to Sustaining.” Instead of copying the bullet points from my presentation into this blog post, we recorded the whole session on a Flip MinoHD. If you’ve got a little time and you’re interested to hear my take on the effects of the Cloud and Virtualization on hosting, go grab a bag of popcorn, turn up your computer speakers, sit back and enjoy:

Get the Flash Player to see the wordTube Media Player.

I opened the floor for Q&A in the session and for additional follow-up after the session after we ran out of time, so I want to do the same for you: When you watch the video, if you’ve got any questions, please post them in a comment below and I’ll be happy to respond.

-Todd

Kevin HazardAs an avid reader of The Planet Blog, you’ve probably noticed some consistency in the 164 articles published here since Doug’s inaugural “Welcome to The Planet’s blog… I think?” post on May 14, 2007. We focus on our company culture, support, data centers and network to help you step through the looking glass and get an inside perspective on our business. With a continuous stream of changes and improvements, it’s tough to feature even a fraction of the work our team is doing to improve our service, so we keep an eye out for opportunities to “show” what we’ve “told” you about in the past. This is one of those opportunities.

On September 2, 2008, we announced the results of our lights-out energy efficiency initiative. A few days ago, I was sorting through a batch of data center pictures, and I came across a few great examples of what this news looks like in practice:

The Planet Lights Out Program

This is Phase Two of our H1 data center. With all the posts you see from H2 and D6, you might be curious about what our other data centers look like, so hopefully the picture above doesn’t surprise you. We have extremely high standards for our data centers, and you should expect the same enterprise-level quality across the board.

If you took a guided tour through H1, you’d see it all lit up as it is above. If you walked in during a normal DC shift, you’d probably find it a little different:

The Planet Lights Out Program

When the data center is unoccupied, the lights are switched off to save energy. How much energy? Well, across the board, we estimate the program saves more than 1.4 million kilowatt hours in a given year – or about $140,000 in power bills. It’s no small change.

As you’ve seen in our other posts about data center innovation and operational efficiency, we take a common-sense approach to energy conservation. It’s incredible to see the significant impact such simple changes can make.

It’s also pretty cool to see servers glowing in the dark:

The Planet Lights Out Program

-Kevin

Jon LoweIf you’ve ever been on a tour of The Planet’s data centers, you’ve probably noticed a server segregation of sorts. In one aisle, you see big breadracks of tower servers that resemble desktop computers, and in the next, you find rack-mount servers stacked on top of each other in cabinets. Both form factors can connect to the same Internet with the same speed and performance … and they can even share identical hardware specifications. It may be confusing to see both up and running right next to each other. In fact, as a DC manager, I’m often asked about why we elect to use one over the other. Because the explanation is pretty straightforward, I thought it would be a great topic to cover in my blog debut.

Tower Servers and Rack Servers

Quite a bit has changed in the way we’ve built data centers over the last four years. When we opened our H2 data center, we only deployed racks of tower servers, and in our newest data center phase, D6 Phase 3, we only provision rack-mount servers. You might assume this shift to imply the complete dominance of rack-mount servers over its tower-chassis relative. Let me suggest that you’d be making an incorrect assumption.

To understand when one form factor may be better than the other, let’s look at the hardware, flexibility, space requirements and costs for each. There are no umbrella claims about rack-mounted and tower servers because each comes in different sizes/variations. Tower servers will generally share the same width, but their heights and depths can vary. Concurrently, rack-mount servers are measured by their heights in “rack units.” The rack-mount server we’ll compare is a 1U – a server that takes up one rack unit of height.

Tower Servers

Tower Servers and Rack Servers
Hardware/Flexibility: Given the tower server size and layout, it can accommodate a greater number of large components like hard drives, RAID and network cards.
Space Requirements: The benefits of having more space for drives and components come at the cost of taking up more data center space. A breadrack of towers can hold 20 servers, while 30 1U rack-mount servers fill a cabinet less than half the width of the tower racks. There are fewer tower servers in a given square-foot area, so we say that the data center space is less dense. When a data center is dense, it requires more power and more cooling, so a data center with only tower servers will generally require less power and cooling.
Cost: In the early 2000’s, rack-mount servers were nearly twice the price of tower servers, so the use of towers could have been a purely economical decision. Now that the rack-mount equivalent of a tower is available only a few hundred dollars more, a data center’s use of the tower form factor will likely be based on one of the other differentiators.

Rack-Mount Servers

Tower Servers and Rack Servers
Space Requirements: As we noted, rack-mount servers can be installed more densely in a data center than their tower counterparts. To fit more servers in the same amount of space, the rack-mount servers offer less available interior real estate. Because the server uses less space, it tends to run hotter – the heat emitted from the processor and components is contained in a smaller area – so cooling and air-flow are critically important.
Hardware/Flexibility: A 1U rack-mount server’s decreased real estate often limits the types of components that fit in a given layout and the number of drives that can be installed … it’s not likely that the server above will be employed as a huge network storage repository.
Cost: While the difference in cost between form factors isn’t egregious, the cost of running a data center filled with one or the other is significant. That’s one of the main reasons why you see the focus on efficiency in D6 Phase 3. With more rack-mount servers in a given space, inefficient use of power and cooling means thousands of additional dollars in utility bills.

When it’s all said and done, the form factor of the server you have with The Planet shouldn’t matter to you. You’re connected to the same network, in the same enterprise-class data centers, and you’re getting the same level of service and support regardless of what your server looks like. If you are interested in more the nitty-gritty details from the data center operations side of our business, leave a comment and let me know what you want to see or learn more about, and I’ll do my best to cover it.

-Jon

 
 
 
 

Dedicated Servers

Managed Hosting

Colocation

Business Solutions

Why The Planet?

Contact Us