Technology Posts

SoftLayer recently released “Global IPs” to a good amount of internal fanfare, and I thought I’d share a little about it with the blog audience in case customers have questions about what Global IPs are and how they work. Simply put, Global IP addresses can be provisioned in any data center on the SoftLayer network and moved to another facility if necessary. You can point it to a server in Dallas, and if you need to perform maintenance on the server in Dallas, you can move the IP address to a server in Amsterdam to seamlessly (and almost immediately) transition your traffic. If you spin up and turn down workloads on cloud computing instances, you have the ability to maintain and a specific IP address when you completely turn down an environment, and you can quickly reprovision the IP on a new instance when you spin up the next workload.

How Do Global IPs Work?

The basics of how the Internet works are simple: Packets are sent between you and a server somewhere based on the location of the content you’ve requested. That location is pinpointed by an IP address that is assigned to a specific server or cloud. Often for various reasons, blocks of IP addresses are provisioned in one region or location, so Global IPs are a bit of a departure from the norm.

When you’re sending/receiving packets, you might thing the packets “know” the exact physical destination as soon as they’re directed to an IP address, but in practice, they don’t have to … The packets are forwarded along a path of devices with a general idea of where the exact location will be, but the primary concern of each device is to get the all packets to the next hop in the network path as quickly as possible by using default routes and routing tables. As an example, let’s follow a packet as it comes from an external webserver and detail how it gets back to your machine:

1. The external webserver sends the packet to a local switch.
2. The switch passes it to a router.
3. The packet traverses a number of network hops (other routers) and enters the Softlayer network at one of the backbone routers (BBR).
4. The BBR looks at the IP destination and compares it to a table shared and updated with the other routers on SoftLayer’s network, and it locates the subnet the IP belongs to.
5. The BBR determines behind which distribution aggregate router (DAR) the IP is located, then it to the closest BBR to that DAR.
6. The DAR gets the packet, looks at its own tables, and finds the front-end customer router (FCR) that the subnet lives on, and sends it there.
7. The FCR routes the packet to the front-end customer switch (FCS) that has that IP mapped to the proper MAC address.
8. The switch then delivers the packet through the proper switchport.
9. Your server gets the packet from the FCS, and the kernel goes, “Oh yes, that IP on the public port, I’ll accept this now.”

All of those steps happen in an instant, and for you to be reading this blog, the packets carrying this content would have followed a similar pattern to the browser on your computer.

The process is slightly different when it comes to Global IP addresses. When a packet is destined for a Global IP, as soon as it gets onto the SoftLayer network (step 4 above), the routing process changes.

We allocate subnets of IP addresses specifically to the Global IP address pool, and we tell all the BBRs that these IPs are special. When you order a global IP, we peel off one of those IPs and add a static route to your chosen server’s IP address, and then tell all the BBRs that route. Rather than the server’s IP being an endpoint, the network is expecting your server to act as a router, and do something with the packet when it is received. I know that could sound a little confusing since we aren’t really using the server as a router, so let’s follow a packet to your Global IP (following the first three steps from above):

4. The BBR notes that this IP belongs to one of the special Global IP address subnets, and matches the destination IP with the static route to the destination server you chose when you provisioned the Global IP.
5. The BBR forwards the packet to the DAR, which then finds the FCR, then hands it off to the switch.
6. The switch hands the packet to your server, and your server accepts it on the public interface like a regular secondary IP.
7. Your server then essentially “routes” the packet to an IP address on itself.

Because the Global IP address can be moved to different servers in different locations, whenever you change the destination IP, the static route is updated in our routing table quickly. Because the change is happening exclusively on SoftLayer’s infrastructure, you don’t have to wait on other providers propagate the change. Think of updating your site’s domain to a new IP address via DNS as an example: Even after you update your authoritative DNS servers, you have to wait for your users’ DNS servers to recognize and update the new IP address. With Global IPs, the IP address would remain the same, and all users will follow the new path as soon as the routers update.

This initial release of Global IP addresses is just the tip of the iceberg when it comes to functionality. The product management and network engineering teams are getting customer feedback and creating roadmaps for the future of the product, so we’d love to hear your feedback and questions. If you want a little more in-depth information about installation and provisioning, check out the Global IP Addresses page on KnowledgeLayer.

-Jason

This is a guest blog with Chad Morris from our partner Mandrill. Mandrill is an email delivery platform built on and managed by MailChimp. Created for developers to set up and manage with minimal coding effort, Mandrill offers advanced tracking, easy-to-understand reports and hundreds of template options. In this video interview, Chad goes into detail about the history of the company as well as the major differences between Mandrill and MailChimp. In the near future, you’ll see a separate guest blog from the Mandrill team with best practices for managing your email systems.

SoftLayer has over 1,750 Gbit/s of network capacity. In each of our data centers and points of presence, we have an extensive library of peering relationships and multiple 10 Gbit/s connections to independent Tier 1 carriers. We operate one of the fastest, most reliable networks on the planet, and our customers love it:

Wow these new Softlayer servers are amazingly fast! No more lag in EU!

— ChadTheDJ (@MCChadTheDJ) July 1, 2012

From a network operations standpoint, that means we have our work cut out for us to keep everything running smoothly while continuing to build the network to accommodate a steady increase in customer demand. It might be easier to rest on our laurels to simply maintain what we already have in place, but when you look at the trend of bandwidth usage over the past 18 months, you’ll see why we need to be proactive about expanding our network:

The purple line above plots the 95th percentile of weekly outbound bandwidth utilization on the SoftLayer network, and the red line shows the linear trend of that consumption over time. From week to week, the total usage appears relatively consistent, growing at a steady rate, but when you look a little deeper, you get a better picture of how dynamic our network actually is:

The animated gif above shows the 2-hour average of bandwidth usage on our entire network over a seven-week period (times in CDT). As you can see, on a day-to-day basis, consumption fluctuates pretty significantly. The NOC (Network Operations Center) needs to be able to accommodate every spike of usage at any time of day, and our network engineering and strategy teams have to stay ahead of the game when it comes to planning points of presence and increasing bandwidth capacity to accommodate our customers’ ever-expanding needs.

But wait. There’s more.

Let’s go one level deeper and look a graph of the 95th percentile bandwidth usage on 5-minute intervals from one week in a single data center:

The variations in usage are even more dramatic. Because we have thirteen data centers geographically dispersed around the world with an international customer base, the variations you see in total bandwidth utilization understate the complexity of our network’s bandwidth usage. Customers targeting the Asian market might host content in SNG01, and the peaks in bandwidth consumption from Singapore will counterbalance the valleys of consumption at the same time in the United States and Europe.

With that in mind, here’s a challenge for you: Looking at the graph above, if the times listed are in CDT, which data center do you think that data came from?

It would be interesting to look at weekly usage trends, how those trends are changing and what those trends tell us about our customer base, but that assessment would probably be “information overload” in this post, so I’ll save that for another day.

-Dani

P.S. If you came to this post expecting to see “a big truck” or “a series of tubes,” I’m sorry I let you down.

This guest blog features Cedexis, a featured member of the SoftLayer Technology Partners Marketplace. Cedexis a content and application delivery system that offers strategies and solutions for multi-platform content and application delivery to companies focused on maximizing web performance. In this video we talk to Cedexis Co-Founder Julien Coulon.

A Multi-Cloud Strategy – The Key to Expansion and Conversion

Web and mobile applications have collapsed geographic barriers to business, bringing brand and commerce experiences ever-closer to increasingly far-flung customers. While web-based business models are powerful enablers for global expansion, they also create new a new challenge in managing availability and performance across diverse and distributed markets: How do you ensure consistent web performance across all markets without investing in physical infrastructure in all of those markets?

Once a business gets its core business on a consistent and reliable provider like SoftLayer, we typically recommend that they consider a multi-cloud strategy that will spread availability and performance risk across a global infrastructure of public and private data centers, delivery networks and cloud providers. Regardless of how fantastic your core SoftLayer hosting is, the reality is that single-source dependency introduces significant business risk. Fortunately, much of that business risk can be mitigated by adding a layer of multi-cloud architecture to support the application.

Recent high-profile outages speak to the problem that multi-sourcing solves, but many web-based operations remain precariously dependent on individual hosting, CDN and cloud providers. It’s a lot like having server backups: If you never need a backup that you have, that backup probably isn’t worth much to you, but if you need a backup that you don’t have, you’d probably pay anything to have it.

Read the rest of Cedexis’s blog about adopting a multi-cloud strategy. »

Wouldn’t it be nice if you could keep the parts of a relationship that you like and “move on” from the parts you don’t? You’d never have to go through the awkward “getting to know each other” phase where you accidentally order food the other person is allergic to, and you’d never have to experience a break up. As it is, we’re faced with a bit of a paradox: Relationships are a lot of work, and “Breaking up is hard to do.”

I could tell you story after story about the break ups I experienced in my youth. From the Ghostbuster-jumpsuited boyfriend I had in kindergarten who stole my heart (and my barrettes) to until it was time to take my had-to-have “My Little Pony” thermos lunchbox to another table at lunch after a dramatic recess exchange to the middle school boyfriend who took me to see Titanic in the theater four times (yes, you read that correctly), my early “romantic” relationships didn’t pan out in the “happily ever after” way I’d hoped they would. Whether the result of an me unwelcome kiss under the monkey bars or a move to a different school (which might as well have been on Mars), I had to break up with each of the boys.

Why are you reading about my lost loves on the SoftLayer Blog? Simple: Relationships with IT environments — specifically applications and data — are not much different from romantic relationships. You might want to cut ties with a high maintenance piece of equipment that you’ve been with for years because its behavior is getting erratic, and it doesn’t look like it’ll survive forever. Maybe you’ve outgrown what your existing infrastructure can provide for you, and you need to move along. Perhaps you just want some space and need to take a break from a project for six months.

If you feel like telling your infrastructure, “It’s not you, it’s me,” what are your options? Undo all of your hard work, schedule maintenance and stay up in the dead of a weeknight to migrate, backup and restore all of your data locally?

When I talk to SoftLayer customers, I get to be a relationship therapist. Because we’ve come out with some pretty innovative tools, we can help our customers avoid ever having to break up with their data again. Two of the coolest “infrastructure relationship”-saving releases: Flex Images (currently in public beta) and portable storage volumes for cloud computing instances (CCIs).

With Flex Images, customers using RedHat, CentOS or Windows systems can create and move server images between physical and virtual environments to seamlessly transition from one platform to the other. With about three clicks, a customer-created image is quickly and uniformly delivered to a new dedicated or cloud server. The idea behind Flex Images is to blur the line between physical and virtual environments so that if you feel the need to break up with one of the two, the other is able to take you in.

Portable storage volumes (PSVs) are secondary CCI volumes that can be added onto any public or private CCI. Users can detach a PSV from any CCI and have it persist in the cloud, unattached to any compute resource, for as long as necessary. When that storage volume is needed again, it can be re-attached as secondary storage on any other CCI across all of SoftLayer’s facilities. The best relationship parallel would be “baggage,” but that’s got a negative connotation, so we’ll have to come up with something else to call it … “preparedness.”

We want to help you avoid break ups and provide you easy channels to make up with your old infrastructure if you have a change of heart. The result is an infrastructure that’s much easier to manage, more fluid and less dramatic.

Now if I can only figure out a way to make Flex Images and portable storage volumes available for real-life relationships …. I’d make millions!

-Arielle

This guest blog comes to us from Cloudability, a featured member of the SoftLayer Technology Partners Marketplace. Cloudability is a cloud budget management service that helps companies manage their cloud spending, prevent overages, reduce waste and save money. In this video we talk to Cloudability Founder and CEO Mat Ellis about how the company developed, and we hear examples of how Cloudability is supporting and businesses money.

5 Things You Need to Know to Control Variable Infrastructure Costs

If you have on premise equipment, then your costs are fixed — you paid your money and now you own a fixed amount of hardware and software. The cloud, on the other hand, has variable costs due to two important features — you only pay for the services you use and it’s scalable, providing the resources you need at any given time. By using a cloud infrastructure, you end up with what we call Variable Infrastructure Costs (VICs).

Most of SoftLayer’s services meet the criteria for a VIC. You need an extra cloud server for a few hours? No problem. More disk? Done.

With great power, comes great responsibility, and the biggest problem with VICs is that they are just like a faucet: Leave it running, and the water bill can add up fast … Not to mention all that waste! Unless you keep a close eye on VICs, you could find yourself in front of your CFO, pleading for your budget’s life.

Cloudability was created to keep those costs under control, and in the course of working with our customers, we’ve come up with a simple five-point checklist of best practices:

1. Collation

Make sure you have insight to all your costs, create a single contract database, and review it regularly. Don’t forget to include total cloud spending alongside your fixed contracts. Talk to your finance department, then drill your employees and tech teams to make sure you REALLY know the whole truth. There can be — and usually is — a disconnect in the organization about how much cloud is really being used.

2. Analysis

Get into the weeds to see why each project is spending what they are spending. Try to calculate some tangible metrics like cost per thousand web pages served or cost per new customer, and benchmark these against public data and common sense.

3. Organization and Rebalancing

Put each of your projects into one of four quadrants:

1. High Spend/Low Efficiency
2. High Spend/High Efficiency
3. Low Spend/Low Efficiency
4. Low Spend/High Efficiency.

Read the rest of Cloudability’s blog about best practices in variable cost management. »

If you read Nathan’s “A Cloud to Call Your Own” blog, and you wanted to learn a little more about private clouds in general or SoftLayer Private Clouds specifically, this post is for you. We’re going take a little time to dive deeper into the technology behind SoftLayer Private Clouds, and in the process, I’ll talk a little about why particular platforms/hardware/configurations were chosen.

The Platform: Citrix CloudPlatform

There are several cloud infrastructure frameworks to choose from these days. We have surveyed a number of them and actively work with several of them. We are active members of the happenings around OpenStack and we have working implementations of vSphere, Nimula, Eucalyptus and other stacks in our data centers. So why CloudPlatform by Citrix?

First off, it’s one of the most mature of these options. It’s been around for several years and now has the substantial backing of Citrix. That backing includes investment, support organizations and the multitude of other products managed by Citrix. There are also some futuristic ideas we have regarding how to leverage products like CloudBridge and Netscaler with Private Clouds. Second, CloudPlatform operates in accordance with how we believe a private cloud should work: It’s simple, it doesn’t have a huge management infrastructure and we can charge for it by the CPU per month, just like all of our other products. Finally, CloudPlatform has made good inroads with enterprise customers. We love the idea that an enterprise ops team could leverage CloudPlatform as the management platform for both their on-premise and their off-premise private cloud.

So, we selected CloudPlatform for a multitude of reasons; not just one.

Another huge key was our ability to integrate CloudPlatform into the SoftLayer portals/mobile apps/API. Because many SoftLayer customers manage their environments exclusively through the SoftLayer API, we knew that a seamless integration there was an absolute necessity. With the help of the SoftLayer dev team and the CloudStack folks, we’ve been able to automate private clouds the same way we did for public cloud instances and dedicated servers.

The Hardware

When it came to choosing what hardware the private clouds would use, the decision was pretty simple. Given our need for automation, SoftLayer Private Clouds would need to be indistinguishable from a standard dedicated server or CloudLayer environment. We use the latest and greatest server hardware available on the market, and every month, you can see thousands of new SuperMicro boxes being delivered to our data centers around the world. Because we know we have a reliable, powerful and consistent hardware foundation on which we can build the private clouds product, it makes the integration of the system even easier.

When it comes to the specs of the hardware provided for a private cloud environment, we provide as much transparency and flexibility as we can for a customer to build exactly what he or she needs. Let’s look into what that means…

The Hardware Configurations

A CloudPlatform environment can be broken down into these components:

• A single management server (that can manage multiple zones across layer 2 networks)
• One or more zones
• One or more clusters in a zone
• One or more hosts in a cluster
• Storage shared by a cluster (which can be a single server)

A simple diagram of a two-zone private cloud might look like this:

We’ve set a standard “management server” configuration that we know will be able to accommodate all of your needs when it comes to running CloudPlatform, and how you build and configure the rest of your private cloud infrastructure is up to you. Whether you want simple dual proc, quad core Nehalem box with a lot of local disk space for a dev cloud or an environment made up of quad proc 10-core Westmeres with SSDs, you have the freedom to choose exactly what you want.

Oh, and everything can be online in two to four hours, and it’s offered on a month-to-month contract.

The Network Configuration

When it comes to where the hardware is provisioned, you have the ability to deploy zones in multiple geographies and manage them all through a single CloudPlatform management node. Given the way the SoftLayer three-tier network is built, the management node and host nodes do not even need to be accessible by our public network. You can choose to make accessible only the IPs used by the VMs you create. If your initial private cloud infrastructure is in Dallas and you want a node online in Singapore, you can just click a few buttons, and the new node will be provisioned and configured securely by CloudPlatform in a couple of hours.

Imagine how long it would have taken you to build this kind of infrastructure in the past:

It doesn’t take days or weeks now. It takes hours.

As you can see, when we approached the challenge of bringing private clouds to the SoftLayer platform, we had to innovate. In Texas, that would be roughly translated as “Go big or go home.” Given the response we’ve seen from customers and partners since the announcement of SoftLayer Private Clouds, we know the industry has taken notice.

Will all of our customers need their own private cloud infrastructure? Probably not. But will the customers who’ve been looking for this kind of functionality be ecstatic with the CloudPlatform environment on SoftLayer’s network? Absolutely.

-Duke

Those of us who’ve been in this industry for years have seen computing evolve pretty significantly, especially recently. We started with dedicated servers running a single operating system, and we were floored by innovations that allowed dedicated servers to run a hypervisor with many operating systems. The next big leap brought virtual machine “cloud” instances into the spotlight … And the resulting marketing shenanigans have been a blessing and a curse. On the positive side, the approachable “cloud” term is a lot easier to talk about with a nontechnical audience, but on the negative side, we see uninformative TV commercials that leverage cloud as a marketing term, and we see products that further obfuscate what cloud technology actually means:

To make sure we’re all on the same page, as we continue to talk about “cloud,” our definition is pretty straightforward:

• It’s an operations model.
• It provides capacity on demand.
• It offers consumption-based pricing.
• It features self-service provisioning.
• It can be accessed and managed via an API.

Understanding those characteristics, when you hear about cloud in the hosting industry, you’re usually hearing about cloud computing instances in a public cloud environment. An instance in a public cloud is one of many instances operating on a shared cloud infrastructure alongside other similar instances that aren’t managed by you. Your data is still secure, and you can still get good performance in a public cloud environment, but you’re not managing the cloud infrastructure on which your instance resides … You’re using a piece of a cloud.

What we announced at Cloud Expo East is the next step in the evolution of technology in our industry … We’re providing a turnkey, on-demand way for our customers to provision their own Private Clouds with Citrix CloudPlatform, powered by Apache CloudStack.

You don’t get a piece of the cloud. You have your own cloud, provisioned in a matter of hours on a month-to-month contract.

For those who have looked into building a private cloud for their business in the past, it’s probably worth reiterating: With SoftLayer and CloudStack, you can have a geographically distributed, secure, private cloud environment provisioned in a matter of hours (not months). Given the complexity of a private cloud environment — involving a management server, private cloud zones, host servers and object storage — this is no small feat.

Those unbelievable provisioning times are only part of the story … When that cloud infrastructure is deployed quickly, it’s fully integrated into the SoftLayer platform, so it leverages our global private network alongside your existing bare metal, dedicated and virtual servers. Want to add public cloud instances to your private cloud as web heads? You’ll log into one portal or use a singular API to have that done in an instant.

Your own cloud infrastructure, fully integrated into SoftLayer’s global infrastructure. If you’re chomping at the bit to try it out for yourself, email us at privateclouds@softlayer.com, and we’ll get you on the “early access” list.

Before I sign off, I want to be sure to thank everyone at SoftLayer and Citrix who worked so hard to make SoftLayer Private Clouds such an amazing new addition to our platform.

-@nday91

June 6, 2012, marked a milestone in the further advancement of the Internet: World IPv6 Launch Day. It was by no means an Earth-shattering event or a “flag day” where everyone switched over to IPv6 completely … What actually happened was that content providers enabled AAAA DNS records for their websites and other applications, and ISPs committed to providing IPv6 connectivity to at least 1% of their customers by this date.

What’s all of this fuss about the IPv6 transition about? The simplest way to explain the situation is that the current Internet can stay working as it does, using IPv4 addresses, forever … if we’re okay with it not growing any more. If no more homes and businesses wanted to get on the Internet, and no more new phones or tablets were produced, and no more websites or applications were created. SoftLayer wouldn’t be able to keep selling new servers either. To prevent or lose that kind of organic growth would be terrible, so an alternative had to be created to break free from the limitations of IPv4.

The long-term goal is to migrate the entire Internet to the IPv6 standard in order to eliminate the stifling effect of impending and inevitable IP address shortages. It is estimated that there are roughly 2.5 billion current connections to the Internet today, so to say the transition has a lot of moving parts would be an understatement. That complexity doesn’t lessen the urgency of the need to make the change, though … In the very near future, end-users and servers will no longer be able to get IPv4 connections to the Internet, and will only connect via IPv6.

The primary transition plan is to “dual-stack” all current devices by adding IPv6 support to everything that currently has an IPv4 address. By adding native IPv6 functionality to devices using IPv4, all of that connectivity will be able to speak via IPv6 without transitional technologies like NAT (Network Address Translation). This work will take several years, and time is not a luxury we have with the dwindling IPv4 pool.

Like George mentioned in a previous post, I see World IPv6 Launch day as a call-to-action for a “game changer.” The IPv6 transition has gotten a ton of visibility from some of the most recognizable names on the Internet, but the importance and urgency of the transition can’t be overstated.

So, what does that mean for you?

To a certain extent, that depends on what your involvement is on the Internet. Here are a few steps everyone can take:

• Learn all you can about IPv6 to prepare for the work ahead. A few good books about IPv6 have been published, and resources like ARIN’s IPv6 Information Wiki are perfect places to get more information.
• If you own servers or network equipment, check them for IPv6 functionality. Upgrade or replace any software or devices to ensure that you can deliver native IPv6 connectivity end-to-end without any adverse impact to IPv6 users. If any piece of gear isn’t IPv6-capable, IPv6 traffic won’t be able to pass through your network.
• If you are a content provider, make your content available via IPv6. This starts with requesting IPv6 service from your ISP. At SoftLayer, that’s done via a zero-cost sales request to add IPv6 addresses to your VLANs. You should target 100% coverage for your services or applications — providing the same content via IPv6 as you do via IPv4. Take an inventory of all your DNS records, and after you’ve tested extensively, publish AAAA records for all hostnames to start attracting IPv6 traffic.
• If you are receiving Internet connectivity to your home or business desktops, demand IPv6 services from your upstream ISP. Also be sure to check your access routers, switches and desktops to ensure they are running the most recent code with stable IPv6 support.
• If you are running equipment such as firewalls, load balancers, IDS, etc., contact your vendors to learn about their IPv6 support and how to properly configure those devices. You want to make sure you aren’t limiting performance or exposing any vulnerabilities.

Starting now, there are no more excuses. It’s time to get IPv6 up and running if you want to play a part in tomorrow’s Internet.

-Dani

Innovation. Automation. Innovation. Automation. Innovation. Automation. That’s been our heartbeat since SoftLayer was born on May 5, 2005. The “Innovation” piece is usually the most visible component of that heartbeat while “Automation” usually hangs out behind the scenes (enabling the “Innovation”). When we launch a new product line like Object Storage, add new functionality to the SoftLayer API, announce a partnership with a service provider like RightScale, or simply receive and rack the latest and greatest server hardware from our vendors, our automated platform allows us to do it quickly and seamlessly. Because our platform is built to do exactly what it’s supposed to without any manual intervention, it’s easily overlooked.

But what if we wanted to show what automation actually looks like?

It seems like a silly question to ask. If our automated platform is powered by software built by the SoftLayer development team, there’s no easy way to show what that automation looks like … At least not directly. While the bits and bytes aren’t easily visible, the operational results of automation are exceptionally photogenic. Let’s take a look at a few examples of what automation enables to get an indirect view of what it actually looks like.

Example: A New Server Order

A customer orders a dedicated server. That customer wants a specific hardware configuration with a specific suite of software in a specific data center, and it needs to be delivered within four hours. What does that usually look like from an operations perspective?

If you want to watch those blinking lights for two or three hours, you’ll have effectively watched a new server get provisioned at SoftLayer. When an order comes in, the automated provisioning system will find a server matching the order’s hardware requirements in the requested data center facility, and the software will be installed before it is handed over to the the customer.

Example: Server Reboot or Operating System Reload

A customer needs to reboot a server or install a new operating system. Whether they want a soft reboot, a hard reboot with a full power cycle or a blank operating system install, the scene in the data center will look eerily familiar:

Gone are the days of server build technicians wheeling a terminal over to every server that needs work done. From thousands of miles away, a customer can remotely “unplug” his or her server via the rack’s power strip, initiate a soft reboot or reinstall an operating system. But what if they want even more accessibility?

Example: What’s on the Screen?

When remotely rebooting or power cycling a server isn’t enough, a customer might want someone in the data center to wheel over to their server in the rack to look at any of the messages that can only be read with a monitor attached. This would generally happen behind the server, but for the sake of this example, we’ll just watch the data center technician pass in front of the servers to get to the back:

Yeah, you probably could have seen that one coming.

Because KVM over IP is included on every server, physical carts carrying “keyboard, video and mouse” are few and far between. By automating customers’ access to their server and providing as much virtual access as we possibly can, we’re able to “get out of the way” of our technical users and only step in to help when that help is needed.

I could go on and on with examples of cloud computing upgrades and downgrades, provisioning a firewall or adding a load balancers, but I’ll practice a little restraint. If you want the full effect, you can scroll up and watch the blinking lights a little while longer.

Automation looks like what you don’t see. No humanoid robots or needlessly complex machines (that I know of) … Just a data center humming along with some beautiful flashing server lights.

-Duke

P.S. If you want to be able to remotely bask in the glow of some blinking server lights, bookmark the larger-sized SoftLayer Rack animated gif … You could even title the bookmark, “Check on the Servers.”