spacer
Sales: 1.866.579.9690       Chat Now       Email Us      


Monthly Archive for April, 2011

6 Steps to Successful Disaster Response and Recovery

Tuesday, April 26th, 2011  |  by Serra Boten  |   2 Comments

Even the most complex hosting configurations today are vulnerable to the physical realities of our world – hard drives can fail, fiber optic cables can be cut, and natural disasters don’t heed even the most inclusive security policies. So what can today’s online businesses do to prepare for the worst? Here are 6 steps to help you maintain business continuity through unexpected events or disasters.

1. Create a disaster recovery plan.
Creating a disaster recovery plan can be an incredibly intimidating task to approach, with an unlimited number of unknown scenarios that could possibly surface. A good place to start is with the essentials, by identifying what services are mission critical to your business. Web presence, email and application database access are likely, but these will vary between organizations. Once key services have been identified, consider a course of action to be taken if these services were rendered unavailable for whatever reason.

Another factor to consider is the desired Recovery Time Objective (TRO). This is the amount of time that is acceptable between a disaster occurring and the business being back up and running.

2. Implement and test your plan. Then test it again.
A good disaster recovery plan is only useful if it is deployed properly and tested regularly. Businesses choosing to take a set it and forget it approach to disaster recovery may end up paying the price five years down the road when an unexpected catastrophe occurs, and your key systems have changed but the policy has not been updated to reflect the changes. System updates, lost passwords, staffing changes, office relocation, infrastructure upgrades and disorganized backup tapes are just a few examples of everyday changes that can render even the best disaster response plan out of date.

Testing of the disaster recovery plan should be carried out at regular, ongoing intervals. Catastrophic events can be simulated during off-peak hours, giving your IT staff a chance to test failover systems without the added pressure of an actual emergency. This provides an opportunity to correct oversight in the policy before a critical incident has a chance to significantly disrupt your business.

3. Use offsite data backups.
Local data backups are better than no backups, but essentially useless in the event of a natural disaster that devastates your localized infrastructure. Many organizations utilize tape backup libraries, but to efficiently protect your data these tapes must be tested regularly, managed properly and stored in a secure, offsite location. Restoring data from these tapes can often be very time consuming and confusing if the backup rotation isn’t well-managed.

In recent years, many businesses have turned to highly redundant Storage Area Networks (SAN) or simple-to-use cloud storage. A product like IBM Tivoli backup service simplifies and speeds up the restoration process significantly, by allowing you to easily back up and replicate your data between multiple datacenters.

Regardless of the backup strategy you chose, one of the most integral parts of having a functional disaster recovery plan is to regularly restore data from your backups to ensure they are functioning properly, and that your support staff prepared to restore data when disaster strikes.

4. Take advantage of redundancy.
Mission critical services should always have redundant failovers, preferably in geographically diverse locations. The goal of redundancy is to eliminate any single point of failure within your organization. For example, imagine you have two servers – an email server and a web server. Both are hosted in the same location, and one day an event occurs which renders both of these servers unavailable. The data on these servers is backed up daily, but you realize that the information needed to restore this data is stored on the now inaccessible web server, and you can’t communicate to others within your organization because your email is down. In this example, these servers are your single point of failure, so steps should be taken to ensure the services provided by these servers is redundantly available in case of disaster.

5. Be transparent, communicate often.
In the event of a disaster, there is a possibility that regular lines of communication can become unavailable, so it is important to define alternative methods of communication before a disaster happens. Contact information for key staff members should always be kept up-to-date and made redundantly available. Depending on the structure within your organization, a disaster response person or team should be appointed, and a process defined for both internal and external communication. Your staff and your customer base need to be kept in the loop during a crisis, so how will you get information to them? In recent years, savvy businesses have turned to forums or third-party social media sites like Twitter as a means for communicating up-to-the-minute status information.

6. Outsource to a professional managed hosting provider.
Maintaining your IT infrastructure is a lot of work, and a comprehensive disaster recovery plan is just one part of the picture. Choosing to use a managed hosting provider is a great option for businesses who prefer to focus on running their business rather than stressing about IT infrastructure. A typical managed hosting provider delivers redundant power and cooling systems, has a strong technical support staff available round-the-clock, multiple datacenters, and a reliable network backbone.


Current IPv6 Network Techniques and Transition Strategies

Wednesday, April 20th, 2011  |  by Jag Bains  |   No Comments

This is the second of two posts on IPv6 written by Jag Bains, Director of Network Operations at PEER 1 Hosting. You can read his first post entitled Fear and Loathing in IPv6 Land.

Despite the race condition to procure the last of the IPv4 space from the RIR’s, there are still a large percentage of Network Operators who do not have an IPv6 game plan at this time.

With IPv6 fundamentally being a separate network (an IPv4 address cannot route to an IPv6 address), the adoption of an IPv6 strategy is as much a business decision as it is a technical one, and with an uncertain landscape on how global IPv6 deployment and adoption rates are to be, these organizations are taking a ‘wait and see’ approach for the time being. The ones who are taking a more proactive approach are primarily adopting one or all of the following approaches.

Tunnelling
In the absence of an IPv6 capable network between two IPv6 hosts, tunnelling is used to provide connectivity between them. This is done by encapsulating IPv6 packets within IPv4, in effect using IPv4 as a link layer for IPv6.

Native/Dual Stack
With the presumption that the network between hosts is capable of routing both IPv6 and IPv4, hosts are dual stacking IP addresses in their operating systems so they can route to either network. While this allows developers to create code that can work on both networks, there is still a fundamental divide in that IPv4 hosts cannot route to IPv6 hosts, and vice versa.

Carrier Grade NAT (CGN)
This differs from the previous two, which were focused on just routing IPv6 hosts to each other. A CGN, also known as a Large Scale NAT (LSN), is intended to bridge IPv6 and IPv4 hosts, so that they communicate with each other. An example of a real world scenario would be having an IPv6 mobile phone using a CGN to access content on a IPv4 host. At it’s core, a CGN is a simply middlebox that translates multiple hosts with IPv6 addresses to a small set of IPv4 addresses, so that communication can be realized with the global IPv4 network at large.

Regardless of the approach used, all methodologies come with caveats and limitations due to the distinct boundaries between IPv4 and IPv6, and the debate rages on in the network world on what the prescribed methodology should be during the ‘transitional’ years as we migrate to eventual native ipv6 support.

PEER 1 Hosting and IPv6
Out network team has been looking at IPv6 for sometime, understanding that IPv4 exhaustion poses a significant business risk. Fortunately, our IPv4 allocations are in very good shape, allowing us to investigate multiple tactics and strategies to introduce IPv6 over time. Here are some of the highlights of what has been achieved on the IPv6 front to date:

IPv6 Architecture and Design
PEER 1 Hosting procured its first IPv6 allocation, 2001:1978::/32, from ARIN in 2004. Since then, we’ve obtained 2606:be00::/32 in anticipation of our Serverbeach implementations, as well as 2a03:8a00::/32 from RIPE for our European operations. Along with acquiring these blocks, we have invested considerable time in designing a  highly redundant  network architecture that will allow us to support deployment of these addresses to clients across our network. Presently, a tentative IPv6 customer provisioning model looks like this so far:

  • Each PEER 1 Hosting city will be provisioned a /40 (309,485,009,821,345,068,724,781,056 ip’s)
  • Each Customer VLAN will be provisioned a /64 (18,446,744,073,709,551,616 ip’s)
  • Each BGP Customer will be provisioned a /64

Network Upgrades
Over the last 4 years, PEER 1 Hosting has made significant investment into our network infrastructure to prepare for IPv6. The upgrades that have been implemented to date have significantly increased our overall bandwidth capacity, as well as given us the ability to provide native, dual stack IPv6 support on our backbone and Colocation operations. This makes PEER 1 Hosting one of the first Canadian companies to provide IPv6 transit in Canada. Support for IPv6 will extend into our Serverbeach and Managed Hosting networks once we have completed upgrading those environments over the next few months.

Presently we are also in the midst of evaluating IPv6 capable DNS servers, which we will be installing throughout our anycast DNS network. In conjunction with this we are also installing tunnelling servers throughout our backbone to further assist in reachability to the PEER 1 Hosting network, for those remote networks that cannot route natively.

Compatibility and Readiness Testing
Within a complex hosting environment such as ours, there are many pieces which need to be tested for IPv6 support and compatibility. Some highlights of what is currently underway include:

  • Our Network Engineering team is presently working with our various hardware and software vendors such as Brocade and Radware to evaluate CGN strategies for Service Providers and Hosting Environments specifically, in addition to coordinating ongoing network infrastructure upgrades, which aim to be completed by the end of 2011.
  • Support  teams are working to ensure IPv6 readiness for various extended services we provide, such as load balancers and firewalls, as well as working with identified customers to test one-off IPv6 deployments and engaging them on evolving our strategy as it continues to develop in the network world at large.
  • The Network Operations Center has been busy testing and developing new tools for tasks such as IPv6 monitoring and provisioning, so as to adapt new policies and procedures to be able to meet the support needs as IPv6 gains traction.

How I Learned to Stop Worrying and Love the Hex
To date, the only thing that the network community have agreed upon is that IPv6 needs to be realized globally sooner than later; there has been no consensus achieved on how that will be done.  Heated discussions are taking place in various blog spheres and mailing lists, leading to confusion and apprehension, and sometimes fear mongering. CIO’s and CTO’s are now constantly being barraged by vendors who can offer an IPv6 solution in a box. Discussions surrounding a  ‘black market’ for IPv4 space are taking place, given credence by Microsoft’s latest $7.5 million purchase of Nortel IP space. This has led some folks to believe that future mergers and acquisitions will heavily factor in the availability of IP space within target organizations.

At a personal level, I’m still trying to get a comprehensive understanding on what the cable/dsl/access providers are doing and what rates to bring IPv6 capability to their subscribers, as I ultimately feel that the number of subscribers in IPv6 space will drive the development of IPv6 throughout the industry, but it’s hard to tell what is going on in this space.

Whatever the case may be, IPv6 needs to be addressed by everyone with an online presence, and it’s a strategy that will need to be developed within the network departments of each organization. With PEER 1 Hosting’s great history in running a global network, we are well positioned to continue developing our IPv6 strategy to ensure the business continuity of our customers.


Infographic Looks Behind Today’s Top Website Datacenters

Wednesday, April 6th, 2011  |  by Serra Boten  |   1 Comment

Over the years, we’ve come to expect our favorite websites to auto-magically appear when we type a web address or click on a Google result, but the truth is that the technology behind today’s top sites is pretty amazing. So how do these websites go about supporting millions of users while making efficient energy decisions? Let’s find out.


Created by PEER 1 Dedicated Hosting

EMBED THIS IMAGE ON YOUR SITE

 


Folding@PEER1

Monday, April 4th, 2011  |  by Fred Taylor-Young  |   No Comments

nVidia GPU servers in actionA colleague of mine started running Folding@Home on a few PCs in his office last summer. When a load of powerful servers were freed up at the end of last year, I figured that since we now had a lot of spares in the data center, why not see what kind of PPD we could squeeze out of them?

For those who have never heard of it, Folding@home is a distributed computing project.  People from around the world download and run a piece of software, all of which combine together to make one of the largest supercomputers in the world, which is used by scientists to simulate and study protien folding. You can read more about the project here.

Originally we started out with a little over sixty dual-5420/5520 Xeon servers (8-12GB RAM each) running one instance of the regular CPU client for each CPU core. This gave a big boost to our rankings, going from a very low number to the mid-2000s pretty quickly.

As the 5420/5520 servers were used up by new orders (and as we bought more powerful servers), I started running the SMP client (with the -bigadv option to increase the PPD) on a few Dell PowerEdge R810 servers (each with four quad-core HT-capable Xeons – a staggering 32 logical cores per server), which resulted in an enormous PPD increase.

We later had a bunch of GPU Cloud servers sent over from another datacentre, each with two 5620 Xeons, between 12 and 48GB RAM and two nVidia Fermi GPUs (pictured). With sixteen of these servers running two GPU Folding clients and the CPU SMP client (again with the -bigadv option), we shot up the team rankings, going from the low 1000s in early January to our current position of 232nd worldwide! And we’re still climbing… :D

Some stats, graphs and point/ranking predictions can be seen on the official Folding@Home stats page, the Extreme Overclocking stats tool or the Kakao Stats tool.

The power usage of these servers is also pretty phenomenal; each GPU servers uses a little over 2amps (at ~240VAC) when running at 100% CPU/GPU load, which equates to just under 40 amps for all sixteen. Each R810 uses about 4amps at full load (2amps per PSU) while the dual-5420/5520 servers only use approximately 1amp each.

And of course, with big power usage comes big heat output: each GPU server throws out an epic amount of hot air at over 50°C (122°F). You could heat a pretty big room with a single one of these GPU servers, as long as the occupants didn’t mind the horrendous noise the fans make at full speed.

Fred Taylor-Young works as a Data Center Operations Technician in our UK data center. This post was originally posted on his site, fr3d.org. P9D9WTFA4BMR