Posts Tagged ‘SoftLayer’

December 6, 2012

MongoDB: Architectural Best Practices

By in Development, Infrastructure, SoftLayer, Technology, Tips and Tricks

With the launch of our MongoDB solutions, developers can provision powerful, optimized, horizontally scaling NoSQL database clusters in real-time on bare metal infrastructure in SoftLayer data centers around the world. We worked tirelessly with our friends at 10gen — the creators of MongoDB — to build and tweak hardware and software configurations that enable peak MongoDB performance, and the resulting platform is pretty amazing. As Duke mentioned in his blog post, those efforts followed 10Gen’s MongoDB best practices, but what he didn’t mention was that we created some architectural best practices of our own for MongoDB in deployments on our platform.

The MongoDB engineered servers that you order from SoftLayer already implement several of the recommendations you’ll see below, and I’ll note which have been incorporated as we go through them. Given the scope of the topic, it’s probably easiest to break down this guide into a few sections to make it a little more digestible. Let’s take a look at the architectural best practices of running MongoDB through the phases of the roll-out process: Selecting a deployment strategy to prepare for your MongoDB installation, the installation itself, and the operational considerations of running it in production.

Deployment Strategy

When planning your MongoDB deployment, you should follow Sun Tzu’s (modified) advice: “If you know the [friend] and know yourself, you need not fear the result of a hundred battles.” “Friend” was substituted for the “enemy” in this advice because the other party is MongoDB. If you aren’t familiar with MongoDB, the top of your to-do list should be to read MongoDB’s official documentation. That information will give you the background you’ll need as you build and use your database. When you feel comfortable with what MongoDB is all about, it’s time to “know yourself.”

Your most important consideration will be the current and anticipated sizes of your data set. Understanding the volume of data you’ll need to accommodate will be the primary driver for your choice of individual physical nodes as well as your sharding plans. Once you’ve established an expected size of your data set, you need to consider the importance of your data and how tolerant you are of the possibility of lost or lagging data (especially in replicated scenarios). With this information in hand, you can plan and start testing your deployment strategy.

It sounds a little strange to hear that you should test a deployment strategy, but when it comes to big data, you want to make sure your databases start with a strong foundation. You should perform load testing scenarios on a potential deployment strategy to confirm that a given architecture will meet your needs, and there are a few specific areas that you should consider:

Memory Sizing
MongoDB (like many data-oriented applications) works best when the data set can reside in memory. Nothing performs better than a MongoDB instance that does not require disk I/O. Whenever possible, select a platform that has more available RAM than your working data set size. If your data set exceeds the available RAM for a single node, then consider using sharding to increase the amount of available RAM in a cluster to accommodate the larger data set. This will maximize the overall performance of your deployment. If you notice page faults when you put your database under production load, they may indicate that you are exceeding the available RAM in your deployment.

Disk Type
If speed is not your primary concern or if you have a data set that is far larger than any available in memory strategy can support, selecting the proper disk type for your deployment is important. IOPS will be key in selecting your disk type and obviously the higher the IOPS the better the performance of MongoDB. Local disks should be used whenever possible (as network storage can cause high latency and poor performance for your deployment). It’s also advised that you use RAID 10 when creating disk arrays.

To give you an idea of what kind of IOPS to expect from a given type of drive, these are the approximate ranges of IOPS per drive in SoftLayer MongoDB engineered servers:

SATA II – 100-200 IOPS
15K SAS – 300-400 IOPS
SSD – 7,000-8,000 IOPS (read) 19,000-20,000 IOPS (write)

CPU
Clock speed and the amount of available processors becomes a consideration if you anticipate using MapReduce. It has also been noted that when running a MongoDB instance with the majority of the data in memory, clock speed can have a major impact on overall performance. If you are planning to use MapReduce or you’re able to operate with a majority of your data in memory, consider a deployment strategy that includes a CPU with a high clock/bus speed to maximize your operations per second.

Replication
Replication provides high availability of your data if a node fails in your cluster. It should be standard to replicate with at least three nodes in any MongoDB deployment. The most common configuration for replication with three nodes is a 2×1 deployment — having two primary nodes in a single data center with a backup server in a secondary data center:

MongoDB Replication

Sharding
If you anticipate a large, active data set, you should deploy a sharded MongoDB deployment. Sharding allows you to partition a single data set across multiple nodes. You can allow MongoDB to automatically distribute the data across nodes in the cluster or you may elect to define a shard key and create range-based sharding for that key.

Sharding may also help write performance, so you can also elect to shard even if your data set is small but requires a high amount of updates or inserts. It’s important to note that when you deploy a sharded set, MongoDB will require three (and only three) config server instances which are specialized Mongo runtimes to track the current shard configuration. Loss of one of these nodes will cause the cluster to go into a read-only mode (for the configuration only) and will require that all nodes be brought back online before any configuration changes can be made.

Write Safety Mode
There are several write safety modes that govern how MongoDB will handle the persistence of the data to disk. It is important to consider which mode best fits your needs for both data integrity and performance. The following write safety modes are available:

None – This mode provides a deferred writing strategy that is non-blocking. This will allow for high performance, however there is a small opportunity in the case of a node failing that data can be lost. There is also the possibility that data written to one node in a cluster will not be immediately available on all nodes in that cluster for read consistency. The ‘None’ strategy will also not provide any sort of protection in the case of network failures. That lack of protection makes this mode highly unreliable and should only be used when performance is a priority and data integrity is not a concern.

Normal – This is the default for MongoDB if you do not select any other mode. It provides a deferred writing strategy that is non-blocking. This will allow for high performance, however there is a small opportunity in the case of a node failing that data can be lost. There is also the possibility that data written to one node in a cluster will not be immediately available on all nodes in that cluster for read consistency.

Safe – This mode will block until MongoDB has acknowledged that it has received the write request but will not block until the write is actually performed. This provides a better level of data integrity and will ensure that read consistency is achieved within a cluster.

Journal Safe – Journals provide a recovery option for MongoDB. Using this mode will ensure that the data has been acknowledged and a Journal update has been performed before returning.

Fsync – This mode provides the highest level of data integrity and blocks until a physical write of the data has occurred. This comes with a degradation in performance and should be used only if data integrity is the primary concern for your application.

Testing the Deployment
Once you’ve determined your deployment strategy, test it with a data set similar to your production data. 10gen has several tools to help you with load testing your deployment, and the console has a tool named ‘benchrun’ which can execute operations from within a JavaScript test harness. These tools will return operation information as well as latency numbers for each of those operations. If you require more detailed information about the MongoDB instance, consider using the mongostat command or MongoDB Monitoring Service (MMS) to monitor your deployment during the testing.

Installation

When performing the installation of MongoDB, a few considerations can help create both a stable and performance-oriented solution. 10gen recommends the use CentOS (64-bit) as the base operating system if at all possible. If you try installing MongoDB on a 32-bit operating system, you might run into file size limits that cause issues, and if you feel the urge to install it on Windows, you’ll see performance issues if virtual memory begins to be utilized by the OS to make up for a lack of RAM in your deployment. As a result, 32-bit operating systems and Windows operating systems should be avoided on MongoDB servers. SoftLayer provisions CentOS 6.X 64-bit operating systems by default on all of our MongoDB engineered server deployments.

When you’ve got CentOS 64-bit installed, you should also make the following changes to maximize your performance (all of which are included by default on all SoftLayer engineered servers):

Set SSD Read Ahead Defaults to 16 Blocks – SSD drives have excellent seek times allowing for shrinking the Read Ahead to 16 blocks. Spinning disks might require slight buffering so these have been set to 32 blocks.

noatime – Adding the noatime option eliminates the need for the system to make writes to the file system for files which are simply being read — or in other words: Faster file access and less disk wear.

Turn NUMA Off in BIOS – Linux, NUMA and MongoDB tend not to work well together. If you are running MongoDB on NUMA hardware, we recommend turning it off (running with an interleave memory policy). If you don’t, problems will manifest in strange ways like massive slow downs for periods of time or high system CPU time.

Set ulimit – We have set the ulimit to 64000 for open files and 32000 for user processes to prevent failures due to a loss of available file handles or user processes.

Use ext4 – We have selected ext4 over ext3. We found ext3 to be very slow in allocating files (or removing them). Additionally, access within large files is poor with ext3.

One last tip on installation: Make the Journal and Data volumes be distinct physical volumes. If the Journal and Data directories reside on a single physical volume, flushes to the Journal will interrupt the access of data and provide spikes of high latency within your MongoDB deployment.

Operations

Once a MongoDB deployment has been promoted to production, there are a few recommendations for monitoring and optimizing performance. You should always have the MMS agent running on all MongoDB instances to help monitor the health and performance of your deployment. Additionally, this tool is also very useful if you have 10gen MongoDB Cloud Subscriptions because it provides useful debugging data for the 10gen team during support interactions. In addition to MMS, you can use the mongostat command (mentioned in the deployment section) to see runtime information about the performance of a MongoDB node. If either of these tools flags performance issues, sharding or indexing are first-line options to resolve them:

Indexes – Indexes should be created for a MongoDB deployment if monitoring tools indicate that field based queries are performing poorly. Always use indexes when you are querying data based on distinct fields to help boost performance.

Sharding – Sharding can be leveraged when the overall performance of the node is suffering because of a large operating data set. Be sure to shard before you get in the red; the system only splits chunks for sharding on insert or update so if you wait too long to shard you may have some uneven distribution for a period of time or forever depending on your data set and sharding key strategy.

I know it seems like we’ve covered a lot over the course of this blog post, but this list of best practices is far from exhaustive. If you want to learn more, the MongoDB forums are a great resource to connect with the rest of the MongoDB community and learn from their experiences, and the documentation on MongoDB’s site is another phenomenal resource. The best people to talk to when it comes to questions about MongoDB are the folks at 10gen, so I also highly recommend taking advantage of MongoDB Cloud Subscriptions to get their direct support for your one-off questions and issues.

-Harold

December 4, 2012

Big Data at SoftLayer: MongoDB

By in Development, Executive Blog, Infrastructure, SoftLayer

In one day, Facebook’s databases ingest more than 500 terabytes of data, Twitter processes 500 million Tweets and Tumblr users publish more than 75 million posts. With such an unprecedented volume of information, developers face significant challenges when it comes to building an application’s architecture and choosing its infrastructure. As a result, demand has exploded for “big data” solutions — resources that make it possible to process, store, analyze, search and deliver data from large, complex data sets. In light of that demand, SoftLayer has been working in strategic partnership with 10gen — the creators of MongoDB — to develop a high-performance, on-demand, big data solution. Today, we’re excited to announce the launch of specialized MongoDB servers at SoftLayer.

If you’ve configured an infrastructure to accommodate big data, you know how much of a pain it can be: You choose your hardware, you configure it to run NoSQL, you install an open source NoSQL project that you think will meet your needs, and you keep tweaking your environment to optimize its performance. Assuming you have the resources (and patience) to get everything running efficiently, you’ll wind up with the horizontally scalable database infrastructure you need to handle the volume of content you and your users create and consume. SoftLayer and 10gen are making that process a whole lot easier.

Our new MongoDB solutions take the time and guesswork out of configuring a big data environment. We give you an easy-to-use system for designing and ordering everything you need. You can start with a single server or roll out multiple servers in a single replica set across multiple data centers, and in under two hours, an optimized MongoDB environment is provisioned and ready to be used. I stress that it’s an “optimized” environment because that’s been our key focus. We collaborated with 10gen engineers on hardware and software configurations that provide the most robust performance for MongoDB, and we incorporated many of their MongoDB best practices. The resulting “engineered servers” are big data powerhouses:

MongoDB Configs

From each engineered server base configuration, you can customize your MongoDB server to meet your application’s needs, and as you choose your upgrades from the base configuration, you’ll see the thresholds at which you should consider upgrading other components. As your data set’s size and the number of indexes in your database increase, you’ll need additional RAM, CPU, and storage resources, but you won’t need them in the same proportions — certain components become bottlenecks before others. Sure, you could upgrade all of the components in a given database server at the same rate, but if, say, you update everything when you only need to upgrade RAM, you’d be adding (and paying for) unnecessary CPU and storage capacity.

Using our new Solution Designer, it’s very easy to graphically design a complex multi-site replica set. Once you finalize your locations and server configurations, you’ll click “Order,” and our automated provisioning system will kick into high gear. It deploys your server hardware, installs CentOS (with OS optimizations to provide MongoDB performance enhancements), installs MongoDB, installs MMS (MongoDB Monitoring Service) and configures the network connection on each server to cluster it with the other servers in your environment. A process that may have taken days of work and months of tweaking is completed in less than four hours. And because everything is standardized and automated, you run much less risk of human error.

MongoDB Configs

One of the other massive benefits of working so closely with 10gen is that we’ve been able to integrate 10gen’s MongoDB Cloud Subscriptions into our offering. Customers who opt for a MongoDB Cloud Subscription get additional MongoDB features (like SSL and SNMP support) and support direct from the MongoDB authority. As an added bonus, since the 10gen team has an intimate understanding of the SoftLayer environment, they’ll be able to provide even better support to SoftLayer customers!

You shouldn’t have to sacrifice agility for performance, and you shouldn’t have to sacrifice performance for agility. Most of the “big data” offerings in the market today are built on virtual servers that can be provisioned quickly but offer meager performance levels relative to running the same database on bare metal infrastructure. To get the performance benefits of dedicated hardware, many users have chosen to build, roll out and tweak their own configurations. With our MongoDB offering, you get the on-demand availability and flexibility of a cloud infrastructure with the raw power and full control of dedicated hardware.

If you’ve been toying with the idea of rolling out your own big data infrastructure, life just got a lot better for you.

-Duke

November 27, 2012

Tips and Tricks – Building a jQuery Plugin (Part 1)

By in Development, Tips and Tricks

I’ve written several blogs detailing the use of different jQuery plugins (like Select2, LazyLoad and equalHeights), and in the process, I’ve noticed an increasing frustration among the development community when it comes to building jQuery plugins. The resources and documentation I’ve found online have not as clear and easy as they could be, so in my next few posts, I’ll break down the process to make jQuery plugin creation simple and straightforward. In this post, we’ll cover the basic structure of a plugin and where to insert your own functionality, and in Part 2, we’ll pick a simple task and add on to our already-made structure.

Before I go any further, it’s probably important to address a question you might be asking yourself: “Why would I want to make my own plugin?” The best reason that comes to my mind is portability. If you’ve ever created a large-scale project, take a look back into your source code and note how many of the hundreds of lines of jQuery code you could put into a plugin to reuse on a different project. You probably invested a lot of time and energy into that code, so it doesn’t make sense to reinvent the wheel if you ever need that functionality again. If that’s not enough of a reason for you, I can also tell you that if you develop your own jQuery plugin, you’ll level-up in cool points, and the jQuery community will love you.

For this post, let’s create a jQuery plugin that simply returns, “This is our awesome plugin!” Our first step involves putting together the basic skeleton used by every plugin:

(function($) {
    $.fn.slPlugin = function() {
 
            // Awesome plugin stuff goes here
    };
}) (jQuery);

This is your template — your starting point. Practice it. Remember it. Love it. The “slPlugin” piece is what I chose to name this plugin. It’s best to name your plugin something unique … I always run a quick Google search to ensure I don’t duplicate the name of a plugin I (or someone else) might need to use in a project alongside my plugin. In this case, we’re calling the example plugin slPlugin because SoftLayer is awesome, and I like naming my plugins after awesome things. I’ll save this code in a file called jquery.slPlugin.js.

Now that we have our plugin’s skeleton, let’s add some default values for variables:

(function($) {
    $.fn.slPlugin = function(options) {
            var defaults = {
                myVar: "default", // this will be the default value of this var
                anotherVar: 0,
                coolVar: "this is cool",                
            };
            var options = $.extend(defaults, options);
    };
}) (jQuery);

Let’s look at the changes we made between the first example and this one. You’ll notice that in our second line we added “options” to become $.fn.slPlugin = function(options) {. We do this because our function is now accepting arguments, and we need to let the function know that. The next difference you come across is the var defaults blurb. In this section, we’re providing default values for our variables. If you don’t define values for a given variable when you call the plugin, these default values will be used.

Now let’s have our plugin return the message we want to send:

(function($) {
    $.fn.slPlugin = function(options) {
            var defaults = {
                myVar: "This is", // this will be the default value of this var
                anotherVar: "our awesome",
                coolVar: "plugin!",
            };
            var options = $.extend(defaults, options);
            this.each(function() {
                ourString = myVar + " " + anotherVar + " " + coolVar;
            });
            return ourString;
    };
}) (jQuery);

We’ve defined our default values for our variables, concatenated our variables and we’ve added a return under our variable declaration. If our jQuery plugin is included in a project and no values are provided for our variables, slPlugin will return, “This is our awesome plugin!”

It seems rather rudimentary at this point, but we have to crawl before we walk. This introductory post is laying the groundwork of coding a jQuery plugin, and we’ll continue building on this example in the next installment of this series. As you’ve seen with the LazyLoad, equalHeights and Select2, there are much more complicated things we can do with our plugin, and we’ll get there. Sneak Preview: In the next installment, we’ll be creating and implementing a truncation function for our plugin … Get excited!

-Cassandra

November 21, 2012

Risk Management: The Importance of Redundant Backups

By in Business, Tips and Tricks

You (should) know the importance of having regular backups of your important data, but to what extent does data need to be backed up to be safe? With a crowbar and shove, thieves broke into my apartment and stole the backups I’ve used for hundreds of gigabytes of home videos, photo files and archives of past computers. A Dobro RAID enclosure and an external drive used by Apple Time Machine were both stolen, and if I didn’t have the originals on my laptop or a redundant offsite backup, I would have lost all of my data. My experience is not uncommon, and it’s a perfect example of an often understated principle that everyone should understand: You need redundant backups.

It’s pretty simple: You need to back up your data regularly. When you’ve set up that back up schedule, you should figure out a way to back up your data again. After you’ve got a couple current backups of your files, you should consider backing up your backups off-site. It seems silly to think of backing up backups, but if anything happens — failed drives, theft, fire, flood, etc. — those backups could be lost forever, and if you’ve ever lost a significant amount of data due to a hard drive failure or experience like mine, you know that backups are worth their weight in gold.

Admittedly, there is a point of diminishing return when it comes to how much redundancy is needed — it’s not worth the time/effort/cost to back up your backups ad infinitum — so here are the best practices I’ve come up with over the course of my career in the information technology industry:

  • Plan and schedule regular backups to keep your archives current. If your laptop’s hard drive dies, having backups from last June probably won’t help you as much as backups from last night.
  • Make sure your data exists on three different mediums. It might seem unnecessary, but if you’re already being intentional about backing up your information, take it one step further to replicate those backups at least one more time.
  • Something might happen to your easy onsite backups, so it’s important to consider off-site backups as well. There are plenty of companies offering secure online backups for home users, and those are generally easy to use (even if they can be a little slow).
  • Check your backups regularly. Having a backup is useless if it’s not configured to back up the correct data and running on the correct schedule.
  • RAID is not a backup solution. Yes, RAID can duplicate data across hard drives, but that doesn’t mean the data is “backed up” … If the RAID array fails, all of the hard drives (and all of the data) in the array fail with it.

It’s important to note here that “off-site” is a pretty relative term when it comes to backups. Many SoftLayer customers back up a primary drive on their server to a secondary drive on the same server (duplicating the data away from the original drive), and while that’s better than nothing, it’s also a little risky because it’s possible that the server could fail and corrupt both drives. Every backup product SoftLayer offers for customers is off-site relative to the server itself (though it might be in the same facility), so we also make it easy to have your backup in another city or on a different continent.

As I’ve mentioned already, once you set up your backups, you’re not done. You need to check your backups regularly for failures and test them to confirm that you can recover your data quickly in the event of a disaster. Don’t just view a file listing. Try extracting files or restore the whole backup archive. If you’re able to run a full restore without the pressure of an actual emergency, it’ll prove that you’re ready for the unexpected … Like a fire drill for your backups.

Setting up a backup plan doesn’t have to be scary or costly. If you don’t feel like you could recover quickly after losing your data, spend a little time evaluating ways to make a recovery like that easy. It’s crazy, but a big part of “risk management,” “disaster recovery” and “business continuity” is simply making sure your data is securely backed up regularly and available to you when you need it.

Plan, prepare, back up.

-Lyndell

November 19, 2012

How It’s Made (and Won): The Server Challenge II

By in Culture, Server Challenge, SoftLayer

Every year, we attend more than fifty trade shows and conferences around the world. We want to spread the word about SoftLayer and connect with each conference’s technical audience (also known as future SoftLayer customers). That goal is pretty straightforward on paper, but when it comes to executing on it, we’re faced with the same challenge as all of our fellow exhibitors: How do we get our target audience to the our booth?

Walk down any aisle of an expo hall, and you’ll see collateral and swag beckoning to attendees like a candy bar at the grocery store register. Some exhibitors rely on Twitter to monitor an event’s hashtag and swoop in at every opportunity to reach the show’s influential attendees. Other exhibitors might send out emails to their clients and prospects in the area to invite them to the show. We see value in each of those approaches, but what we found to be most effective was to bring a SoftLayer data center to our booth … or at least a piece of one.

The Server Challenge has come a long way over the years. Its meager beginnings involved installing RAM and hard drive cables in a tower server. Shortly thereafter, a rack-mount server replaced the tower server, but you were still tasked with “inside the server” challenges. As we started looking for ways to tell the bigger SoftLayer story with the Server Challenge, we moved to miniature server rack, and the competition really started to pick up steam. This year, we made it our goal to take the Server Challenge to the next level, and when Supermicro stepped in to sponsor the next iteration of the the competition, we started thinking BIG.

Why use a miniature version of a SoftLayer rack when we could use a full-size version? Why have a standalone screen when rack-mount monitors can make the display part of the unit? Why rely on speakers behind the booth to pump “Eye of the Tiger” while attendees are competing when we could easily build those into the next version of the challenge? What was initially intended to be a “tweak” of the first Server Challenge became a complete overhaul … Hence the new “Server Challenge II” moniker.

Harkening back to the 8-bit glory days of Pac Man and Space Invaders, the Server Challenge II uses a full-size 42U server rack with vintage arcade-style branding, a built-in timer and speakers that blast esoteric video game music. The bread and butter of the challenge is the actual server hardware, though … Supermicro provided two new 2U servers to replace the previous version’s five 1U servers, and we installed the same Cisco (public and private networks) and SMC (out-of-band management network) switches you see in SoftLayer’s pods.

Server Challenge II

We had two instances of the original Server Challenge (one in the US, one in Amsterdam), so in order for the Server Challenge II to be bigger and better, we had to increase that total to five — one instance in Europe, one in Asia and three in the United States. Things might get a little crazier logistically, but as a potential conference attendee, it means you’re even more likely to encounter the Server Challenge II if you attend any events with us.

The Server Challenge II’s Internal Debut

The first instance of the Server Challenge II made its debut at GDC Online in Austin, and we immediately knew we had a hit. By the time the rack got back to our office, we had to get it ready for its next destination (Cloud Expo West), but before we sent it on its way, we gave it an official internal debut … and raised some money for the American Heart Association in the process.

Server Challenge II at SoftLayer

SLayers at the SoftLayer HQ in Dallas could pay $3 for one attempt or $5 for two attempts to reach the top of the Server Challenge II leader board. Needless to say, it was competitive. If you click on the image above, you’ll notice that our fearless leader, Lance Crosby, stopped by and gave tips to (and/or heckled) a few participants. Unsurprisingly, one of our very talented Server Build Technicians — Ellijah Fleites — took home a MacBook Air and bragging rights as SoftLayer champion with a record time of 1:03.79 … But records are made to be broken.

In Two Places at Once

Immediately after the AHA fundraiser, we crated up the rack and sent it along to Cloud Expo West in Santa Clara. A few days later, we put the finishing touches on the second Server Challenge II rack, and because we got it done quickly, we were able to get it shipped to the other side of the country for ad:tech NYC. We would finally have the competition running in two places at the exact same time!

We weren’t disappointed.

On both coasts, the retro style of the Server Challenge II lured some fantastic competitors (excellent!), and started a lot of great conversations (even better!). Here are the final leader boards from the shows:

Server Challenge II
Server Challenge II

You probably notice that the times in the ad:tech leader board are a little higher than the times in the Cloud Expo leader board, and our team figured out why that was in the middle of the second day of the conference … The way we bound the network cables differed slightly between the two instances, and we were using different switches to time the competition (one that required only one hand to activate/deactivate, the other requiring both hands). In order to have an “apples-to-apples” comparison between all of our shows, we’re going to make sure everything is consistent with all of the instances, and we plan on keeping a running list of fastest overall challenge times … and maybe even a “World Championship” one day.

Given the early success of the Server Challenge II, you can bet that it’s not going anywhere any time soon. If we have multiple shows running the challenge at one time, we might even fire up a video chat where you can compete against an attendee at a completely different conference … so be prepared.

In the next year, we’ll have all five of the Server Challenge II instances in rotation across three continents, and with the popularity of the competition growing by leaps and bounds after every show, we hope by next holiday season, a home version of the Server Challenge II is at the top of every wish list on the planet. :-)

For now, though, I’ll just leave you with a glimpse at the action from Cloud Expo West (click for more pictures from the show):

Cloud Expo West

-Raleigh

November 16, 2012

Going Global: Domo Arigato, Japan

By in Business, Executive Blog, International

I’m SoftLayer’s director of international operations, so I have the unique pleasure of spending a lot of time on airplanes and in hotels as I travel between Dallas, Amsterdam, Singapore and wherever else our event schedule dictates. In the past six months, I’ve spent most of my time in Asia, and I’ve tried to take advantage of the opportunity relearn the culture to help shape SoftLayer Asia’s business.

To really get a sense the geographic distance between Dallas and Singapore, find a globe and put one index finger on Dallas and put your other index finger on Singapore. To travel from one location to the other, you fly to the other side of the planet. Given the space considerations, our network map uses a scaled-down representative topology to show our points of presence in a single view, and you get a sense of how much artistic license was used when you actually make the trip to Singapore.

Global Network

The longest currently scheduled commercial flight on the planet takes you from Singapore to Newark in a cool 19 hours, but I choose to maintain my sanity rather than set world records for amount of time spent in a metal tube. I usually hop from Dallas to Tokyo (a mere 14 hours away) where I spend a few days, and I get on another plane down to Singapore.

The break between the two legs of the trip serves a few different purposes … I get a much needed escape from the confines of an airplane, I’m able to spend time in an amazing city (where I lived 15 years ago), and I can use the opportunity to explore the market for SoftLayer. Proximity and headcount dictated that we spend most of our direct marketing and sales time focusing on the opportunities radiating from Singapore, so we haven’t been able to spend as much time as we’d like in Japan. Fortunately, we’ve been able organically grow our efforts in the country through community-based partnerships and sponsorships, and we owe a great deal of our success to our partners in the region and our new-found friends. I’ve observed from our experience in Japan that the culture breeds two contrasting business realities that create challenges and opportunities for companies like SoftLayer: Japan is insular and Japan is global.

When I say that Japan is insular, I mean that IT purchases are generally made in the realm of either Japanese firms or foreign firms that have spent decades building reputation in market. Becoming a trusted part of that market is a time-consuming (and expensive) endeavor, and it’s easy for a business to be dissuaded as an outsider. The contrasting reality that Japanese businesses also have a huge need for global reach is where SoftLayer can make an immediate impact.

Consider the Japanese electronics and the automobile industries. Both were built internally before making the leap to other geographies, and over the course of decades, they have established successful brands worldwide. Japanese gaming companies, social media companies and vibrant start-up communities follow a similar trend … only faster. The capital investment required to go global is negligible compared to their forebears because they don’t need to build factories or put elaborate logistics operations in place anymore. Today, a Japanese company with a SaaS solution, a game or a social media experience can successfully share it with the world in a matter minutes or hours at minimal cost, and that’s where SoftLayer is able to immediately serve the Japanese market.

The process of building the SoftLayer brand in Asia has been accelerated by the market’s needs, and we don’t take that for granted. We plan to continue investing in local communities and working with our partners to become a trusted and respected resource in the market, and we are grateful for the opportunities those relationships have opened for us … Or as Styx would say, “Domo Arigato, Mr. Roboto.”

-@quigleymar

November 8, 2012

Celebrating the First Anniversary of SoftLayer Going Global

By in Executive Blog, International, SoftLayer

In October, SoftLayer’s data center in Singapore (SNG01) celebrated its first birthday, and our data center in Amsterdam (AMS01) turned one year old this week as well. In twelve short months, SoftLayer has completely transformed into a truly global operation with data centers and staff around the world. Our customer base has always had an international flavor to it, and our physical extension into Europe and Asia was a no-brainer.

At the end of 2011, somewhere in the neighborhood of 40% of our revenue was generated by companies outside of North America. Since then, both facilities have been fully staffed, and we’ve ratcheted up support in local startup communities through the Catalyst program. We’ve also aggressively promoted SoftLayer’s global IaaS (Infrastructure-as-a-Service) platform on the trade show circuit, and the unanimous response has been that our decision to go global has been a boon to both our existing and new customers.

This blog is filled with posts about SoftLayer’s culture and our SLayers’ perspectives on what we’re doing as a company, and that kind of openness is one of the biggest reasons we’ve been successful. SoftLayer’s plans for global domination included driving that company culture deep into the heart of Europe and Asia, and we’re extremely proud of how both of our international locations show the same SLayer passion and spirit. In Amsterdam, our office is truly pan-European — staffed by employees who hail from the US, Croatia, Greece, France, the Netherlands, Poland, Spain, Sweden, Ireland and England. In Singapore, the SoftLayer melting pot is filled with employees from the US, Singapore, Malaysia, Indonesia and New Zealand. The SoftLayer culture has flourished in the midst of that diversity, and we’re a better company for it.

All of this is not to say the last year has not been without challenges … We’ve logged hundreds of thousands of air miles, spent far too many nights in hotels and juggled 13-hour and 6-hour time zone difference to make things work. Beyond these personal challenges, we’ve worked through professional challenges of how to make things happen outside of North America. It seems like everything is different — from dealing with local vendors to adjusting to the markedly different work cultures that put bounds around how and when we work (I wish I was Dutch and had as many vacation days…) — and while some adjustments have been more difficult than others, our team has pulled through and gotten stronger as a result.

As we celebrate our first anniversary of global operations, I reflect on a few of the funny “light bulb” moments I’ve experienced. From seeing switch balls get the same awed looks at trade shows on three different continents to realizing how to effectively complete simple tasks in the Asian business culture, I’m ecstatic about how far we’ve come … And how far we’re going to go.

To infinity and beyond?

-@quigleymar

November 5, 2012

O Canada! – Catalyst, Startups and “Coming Home”

By in Executive Blog, International, SoftLayer, Startup Series

I was born and raised in Brockville, Ontario, and I’ve always been a proud Canadian. In 2000, I decided to leave my homeland to pursue career options south of the 49th parallel, so I became an active participant in Canada’s so-called “brain drain.” It’s never easy starting over, but I felt that my options were limited in Canada and that I wouldn’t find many opportunities to make an impact on a global stage.

Fast-forward to 2012. Early in the year, we were introduced to GrowLab — a leading Vancouver based accelerator — by our friends at East Side Games Studio. They seemed to have a lot of incredible stuff going on, so I planned an exploratory mission of sorts … In June, I’d visit a few Canadian cities with an open mind to see what, if anything, had changed. With the Catalyst Program‘s amazing success in the US, I hoped we could hunt down one or two Canadian startups and accelerators to help out.

I was very pleasantly surprised at what I found: A vibrant, thriving Canadian community of entrepreneurs that seemed to match or exceed the startup activity I’ve seen in Silicon Valley, Boulder, Boston, New York, Amsterdam, Hong Kong, and Dubai. How times have changed! Investing in the Canadian startup scene was a no-brainer.

Canada Approved

The Catalyst team hit the ground running and immediately started working with GrowLab and several other incredible organizations like Communitech, Ryerson University Digital Media Zone (DMZ), Innovation Factory, Extreme Startups and the Ontario Network of Excellence (ONE).

We’ll enroll startups participating in those organizations into the Catalyst Program, and we’ll provide infrastructure credits (for servers, storage and networking), executive mentoring, engineering resources and limited financial support. SoftLayer wants to become the de facto Infrastructure as a Service (IaaS) provider for Canadian startups and startups worldwide, so this is a huge first step onto the international stage. More importantly — and on a personal level — I’m excited that we get to help new companies in Canada make a global impact with us.

As a Canadian expat, having the opportunity to give something back means a great deal to me. I see an incredible opportunity to nurture and help some of these Canadian startups take flight. SoftLayer is still an entrepreneurial company at heart, and we have a unique perspective on what it takes to build and scale the next killer app or game, so we feel especially suited to the task.

One of the Canadian entrepreneurs we’ve been working with sent us this great video produced by the Vancouver-based GROW Conference about entrepreneurship, and it immediately resonated with me, so I wanted to be sure to include it in this post:

We’ve already started working with dozens entrepreneurs in Vancouver, Toronto, Hamilton and Waterloo who embody that video and have kindred spirits to my own. SoftLayer has a few Canadian ex-pats on our team, and as Catalyst moves into Canada officially, we’re all extremely proud of our heritage and the opportunity we have to help.

Some have called our foray into the Canadian market an “international expansion” of sorts, I think of it more as a “coming home party.”

-@gkdog

Canada Approved

November 2, 2012

The Trouble with Open DNS Resolvers

By in SoftLayer, Technology, Tips and Tricks

In the last couple of days, there’s been a bit of buzz about “open DNS resolvers” and DNS amplification DDoS attacks, and SoftLayer’s name has been brought up a few times. In a blog post on October 30, CloudFlare explained DNS Amplification DDoS attacks and reported the geographic and network sources of open DNS resolvers that were contributing to a 20Gbps attack on their network. SoftLayer’s AS numbers (SOFTLAYER and the legacy THEPLANET-AS number) show up on the top ten “worst offenders” list, and Dan Goodin contacted us to get a comment for a follow-up piece on Ars Technica — Meet the network operators helping to fuel the spike in big DDoS attacks.

While the content of that article is less sensationalized than the title, there are still a few gaps to fill about when it comes to how SoftLayer is actually involved in the big picture (*SPOILER ALERT* We aren’t “helping to fuel the spike in big DDoS attacks”). The CloudFlare blog and the Ars Technica post presuppose that the presence of open recursive DNS resolvers is a sign of negligence on the part of the network provider at best and maliciousness at worst, and that’s not the case.

The majority of SoftLayer’s infrastructure is made up of self-managed dedicated and cloud servers. Customers who rent those servers on a monthly basis have unrestricted access to operate their servers in any way they’d like as long as that activity meets our acceptable use policy. Some of our largest customers are hosting resellers who provide that control to their customers who can then provide that control to their own customers. And if 23 million hostnames reside on the SoftLayer network, you can bet that we’ve got a lot of users hosting their DNS on SoftLayer infrastructure. Unfortunately, it’s easier for those customers and customers-of-customers and customers-of-customers-of-customers to use “defaults” instead of looking for, learning and implementing “best practices.”

It’s all too common to find those DNS resolvers open and ultimately vulnerable to DNS amplification attacks, and whenever our team is alerted to that vulnerability on our network, we make our customers aware of it. In turn, they may pass the word down the customer-of-customer chain to get to the DNS owner. It’s usually not a philosophical question about whether DNS resolvers should be open for the greater good of the Internet … It’s a question of whether the DNS owner has any idea that their “configuration” is vulnerable to be abused in this way.

SoftLayer’s network operations, abuse and support teams have tools that flag irregular and potentially abusive traffic coming from any server on our network, and we take immediate action when we find a problem or are alerted to one by someone who sends details to abuse@softlayer.com. The challenge we run into is that flagging obvious abusive behavior from an active DNS server is a bit of a cat-and-mouse game … Attackers cloak their activity in normal traffic. Instead of sending a huge amount of traffic from a single domain, they send a marginal amount of traffic from a large number of machines, and the “abusive” traffic is nearly impossible for even the DNS owner to differentiate from “regular” traffic.

CloudFlare effectively became a honeypot, and they caught a distributed DNS amplification DoS attack. The results they gathered are extremely valuable to teams like mine at SoftLayer, so if they go the next step to actively contact the abuse channel for each of the network providers in their list, I hope that each of the other providers will jump on that information as I know my team will.

If you have a DNS server on the SoftLayer network, and you’re not sure whether it’s configured to prevent it from being used for these types of attacks, our support team is happy to help you out. For those of you interested in doing a little DNS homework to learn more, Google’s Developer Network has an awesome overview of DNS security threats and mitigations which gives an overview of potential attacks and preventative measures you can take. If you’re just looking for an easy way to close an open recursor, scroll to the bottom of CloudFlare’s post, and follow their quick guide.

If, on the other hand, you have your own DNS server and you don’t want to worry about all of this configuration or administration, SoftLayer operates private DNS resolvers that are limited to our announced IP space. Feel free to use ours instead!

-Ryan

October 30, 2012

Startup Series: YouNoodle

By in Executive Blog, Startup Series

In the startup world, the resources you have are almost as important as your vision and your ability to execute. That simple idea fueled the creation of Catalyst, and it’s a big component of our incredible success. We’re taking the complexity (and cost) out of the hosting decision for the coolest startups we meet, and by doing so, those startups have the freedom to focus on their applications. But that’s only the beginning.

In addition to providing infrastructure, my team and I also try to introduce Catalyst participants to investors, incubators, accelerators and other startup founders. By building a strong network of experienced peers, entrepreneurs have a HUGE advantage as they’re building their businesses. The difficulty in making those introductions is that it’s such a labor-intensive process … Or I guess I should say that it *was* a labor-intensive process. Then we found YouNoodle.

YouNoodle is an online network for entrepreneurs that was founded in 2010 in San Francisco, California. The 18-person startup is built to connect entrepreneurs with people, startups, competitions and groups based on what’s relevant to each entrepreneur’s mission. What the Catalyst team has been doing in a labor-intensive fashion, YouNoodle has automated and streamlined! We had to meet these folks.

YouNoodle

We heard that YouNoodle was putting together a start-up crawl during one of their immersion programs — they bring international entrepreneurs to Silicon Valley to learn best practices and make connections in the US market — and we jumped at an opportunity to provide the beer and sandwiches at one of the stops. If you’ve ever worked at a startup before, you know that the way to an entrepreneur’s heart is through his/her stomach, so we hoped it would be “love at first bite.”

We chatted with the YouNoodle team, and they showed us the recently released 2.0 version of Podium, the SaaS platform they built to manage the selection process for entrepreneurial competitions and challenges from organizations like Start-Up Chile, The Next Web, Intel, NASA and seven out of the top ten universities around the world. Basically, Podium enables the most talented individuals and innovative startups to rise to the top and get the opportunities they deserve.

YouNoodle was an obvious fit for Catalyst, and Catalyst was an obvious fit for YouNoodle. Other Catalyst participants could join the thriving community of entrepreneurs that YouNoodle has built, and YouNoodle could take advantage of the power of SoftLayer’s hosting platform. And by helping support YouNoodle, Catalyst gets to indirectly help even more entrepreneurs and startups … Very “meta!”

Over the past two years, YouNoodle has managed over 400 competitions which have received entries from more than 28,000 entrepreneurs around the world. They’re a key player in the acceleration of global entrepreneurship, and they share our vision of breaking down the geographic barriers to innovation. And with the momentum they’ve got now, it’s clear that they’re just getting started.

If you have a second, head over to YouNoodle.com to check out the fresh, easy-to-use interface they launched to help users discover, get inspired by and connect with like-minded individuals on a global scale.

-@PaulFord