Data Center

Introducing BlueLock CloudConnector, a vCloud Datacenter Service

Tuesday, August 31, 2010 by Alicia Gaba

This morning at VMworld in San Francisco, BlueLock officially released our newest cloud technology, the BlueLock CloudConnector, a hybrid cloud enabler. We are also announcing our selection as one of three North American vCloud Datacenter providers.

With BlueLock CloudConnector VMware customers can immediately realize the benefits of the next generation of cloud capabilities provided by VMware’s vCloud Director, the cloud delivery platform for vCloud Datacenter (also introduced this morning). vCloud Director adds new capabilities such as the ability to move workloads between VMware-compatible clouds (public and/or private) in a secure environment.

BlueLock CloudConnector for vCloud Director allows current VMware customers to view and manage their existing VMware environment (their private cloud) and BlueLock’s VMware-based public cloud resources in the vSphere Client control panel they already have, making the transition to a hybrid cloud even easier for existing VMware administrators.

vCloud Datacenter
As one of only three North American VMware vCloud Datacenter providers selected by VMware, BlueLock provides enterprise-class public cloud infrastructure with compatible management, security, application portability and business agility to businesses of all sizes. Use of the same VMware technology provides common management and security model enabling workloads to move between internal datacenters and the BlueLock Public Cloud.

vCloud Datacenter is an enterprise-class cloud built on VMware’s cloud infrastructure technology including VMware vSphere, vCloud Director, and vShield security. vCloud Datacenter delivers consistent and auditable security and performance through SAS-70-Type-II certifications as well as technical capabilities such as network isolation, role-based access control and directory services integration.

Read the full release.

Know Your Scaling Enemy

Thursday, August 26, 2010 by John Ellis

I've got scalability on the brain lately. Right now I've been thinking about caching strategies as a way to accelerate applications, reduce I/O and increase scalability.

A recent post on High Availability entitled "6 Ways to Kill Your Servers - Learning How to Scale the Hard Way" has been circulating the Internet's tubes lately and is an interesting read on how someone came to understand scalability for a web site. It was narrated from a timeline perspective, detailing what had to be incremenetally learned as they scaled a website to beyond one million users a month. Each iteration was a lesson on what you had to learn... or your site will die.

All the lessons had a common thread: under load, I/O will eventually kill your site. It may start with network bottlenecks, then progress to open file handles, then to filesystem I/O. Eventually reading/writing blocks to disk or the network will become the critical path for your application and make it crawl to its knees.

It may sound like a hack but the solution is always the same: cache data like mad. Put as much data in-memory as humanly possible so you don't need to read it from disk or *gasp* across the network. Cache data like there's no tomorrow.

There are tons of advanced solutions for data caching. There are centralized solutions such as memcached or distributed solutions from Terracotta, Tangosol Coherence, JBoss Cache and others, but sometimes the most simple implementations of caching are the best. Unless you actually need massive cache stores that can persist to disk you may get the best leverage from local caches that reside entirely in-memory on the same server as the process that consumes them. One example is having an individual, entirely in-memory and independent EhCache region within every running application. This implementation is very straight-foward and best of all requires no network I/O for retrieval. True, you may end up with a bunch of redundant data spread across each running application, but for me that's an acceptable trade-off for sub-millisecond access to the data I need. Even with aggressive cache invalidation the I/O savings can be huge. As Lesson #5 taught the author, caching can reduce I/O load by up to 80%. That's a pretty huge savings.

When you move into managed cloud hosting your strategies may need to change. Since you can dynamically size memory with a VMware cloud, it may make more sense to have a centralized memcached or EhCache store. Since you can shrink or expand VMs on demand you don't necessarily have to worry about a server's RAM going unused. And since a good cloud service provider (such as BlueLock) will have gigabit interconnects between VMs, network latency may be a diminishing issue. You could have twenty very lean VMs with 1 GB RAM each connecting to a central memcached server with 16 GB of RAM that has a ton of cached data. You can even pre-fill it with frequently accessed data: think calendar dates, city/state/zip combinations, customer account data, previous invoices... all the stuff that will likely not change and need to be invalidated. If a node happens to be re-deployed or upgraded you don't need to re-fetch that data either - your central cache server will still keep it faithfully in-memory.

Caching strategies in a physical datacenter world are very different than in the cloud computing world. That's a good thing - lines between servers become blurred with cloud computing infrastructure, making "cleaner" solutions like centralized caching strategies more practical. Picking the right caching strategy is a big win for everyone; you end up doing more with less, you reduce response times and make customers happier for it. Everyone wins!

Cloud Computing to Scale

Thursday, August 19, 2010 by John Ellis

There are very, very different ways of architecting cloud infrastructure so that it can scale. Prior to deciding on a cloud strategy you should ask one big question - why does your infrastructure need to scale?

About five or six years ago scalability migrated from an architectural property to a widely-discussed buzz word. I would occasionally be in a meeting where someone would ask if my application was "scalable." At times I was met with an incredulous stare when I asked to elaborate on what was meant by "scalable." It should just scale! Scales! Like... er... fish skin?

Scalability is a critical thing when designing your infrastructure and your applications, no doubt. What if I build an amazingly scalable Web application that can handle 10 million concurrent requests from users and could still double amount that in a blink of an eye... but my MySQL database quickly filled up with 1 billion user records? I may have amazing throughput and pass my JMeter load tests with flying colors, but if I don't prepare for the massive amounts of data my application might need to dig through in order to serve a query all the HTTP connections in the world will just serve to pour salt into the wound.

There are options for scaling your data layer and vastly reducing query time, as mentioned earlier in our discussions about non-relational databases in the Cloud. You can even expand to 10,000 node clusters like Google has done with Dremel. However, unless you are ready to build a league of data centers filling the Atlantic Ocean, you may want to consider what your upper limits of scaling really are. Don't automatically assume that a 10,000 node cluster of servers means more power, and definitely be careful of using technology that your application may have difficulty using properly. Non-relational databases won't fit well if your application already uses ORM tools for populating data, and sometimes you need to completely re-think how data is represented (as in Dremel) and move from simple rows of delimited data to nested columnar storage. It can make one's head explode. Mine already has twice this morning.

Cloud Computing infrastructure gives you a quintillion servers at your fingertips, but consider your diagonal scalability strategy first. Are we talking about syndicating or publishing content that is modified maybe 10-20 times a day but viewed thousands of times? Creating a series of read-only MySQL clones will work fabulously, even more so if your application caches data aggressively. Are you going to deal with a ton of transactions that need to be immediately written to your database? Architect your database layer using a sharding strategy that allows you to distribute the transactional load across multiple databases, even relational databases. Are you going to deal with massive amounts of data that will need immediate retrieval? Perhaps a non-relational database is a good idea, allowing you to distribute your data across multiple nodes and retrieve it by using a non-relational key. Need to perform full-text search? You may instead want to index your data in something like Lucene.

I can appreciate the need to standardize an organization's database tools, especially in an enterprise, but it is always good to be open to new solutions for unique problems. When it comes to scaling an application no single technology fits all situations... you need to predict why scaling might need to occur, then open up a path to remove potential bottlenecks before everything grinds to a halt.

Physical Education in a Virtual World

Thursday, August 12, 2010 by John Ellis

I will admit that "Cloud Computing" terminology is becoming confused. People are mixing together the concepts of commodity hardware datacenters, the benefits of virtualization and massively parallel systems into a blender and calling it a "cloud." The truth is that these three concepts are very disparate practices that often do not entirely co-exist. Most service providers will pick one or two of the three for their managed cloud hosting.

For example: Amazon AWS is largely a traditional infrastructure provider that leverages a massive number of commodity hardware (well, not quite, but bear with me) to offer low-cost server hosting. This allows you to spin up elebenty kabillion instances on the cheap, but the price/performance ratio many times just isn't there. A great article was recently published showing how moving a conventional Drupal installation away from AWS provided much better performance, lowered response times and was much more cost effective, even when accounting for disaster recovery. This demonstrates not how physical hardware is more cost-effective, but instead shows how performance matters when calculating cost.

When architecting an application's infrastructure it pays to remember that performance does not increase by adding more servers into the mix. Diagonal scaling is the best way to handle increasing load on a cost-effective basis, as demonstrated by Flickr and Wikimedia. Increase your hardware until you become constrained by concurrency (such as context switching, thread contention or mutex waits) or I/O then consider scaling out horizontally. Unless you are talking about massively parallel algorithms you don't need to spin up an enormous number of machines; even if you do start talking about massively parallel computation, you cease talking about infrastructure as a service and virtualization and instead move towards deploying Hadoop clusters across many physical nodes.

I would agree that vertical scaling isn't a great strategy. I would also argue that horizontal scaling on its own isn't a great strategy either. Get your money's worth for each instance you start, then keep deploying as demand increases.

SAS 70 Type II

Wednesday, August 11, 2010 by Jake Barna

SAS 70 (Statement on Auditing Standards No. 70) is a widely recognized auditing standard developed by the American Institute of Certified Public Accountants (AICPA). A SAS 70 audit represents that a service organization has been through an in-depth audit of their control objectives and control activities, which often include controls over information technology and related processes.

Service organizations, such as a data center, elect to go through either a Type I or Type II SAS 70 audit. Both audit types list controls that are in place at that point in time. A Type II audit goes one step further and evaluates the effectiveness of those controls within a defined period of review (typically six months).

A SAS 70 audit can provide several advantages for a service organization:

Establish credibility within the business community
Build trust with clients by having controls independently verified by a third party
Identify operational areas for improvement

To learn more about BlueLock and our SAS 70 Type II certified data center, visit our website!

Does Virtualization = Cloud Computing or Vice Versa?

Tuesday, August 10, 2010 by Bob Roudebush

There's some debate these days about whether or not you must be utilizing virtualization technology to be considered a true cloud computing solution. Some argue that cloud computing is merely a paradigm and not a prescribed set of technologies; that while the advantages of virtualization are great you don't need virtualization to enjoy the advantages of cloud computing. Just like I'm not convinced that one model fits all when it comes to cloud computing, I'm also not convinced that you have to be running a workload in a virtual machine for it to be considered to be "in the cloud". At the core of it, cloud computing is just a sophisticated form of outsourcing all or a part of your IT infrastructure. Instead of building your own datacenter or bying your own systems and software and managing it all yourself, you get along using someone else's datacenter. Or someone else's systems and software. Or someone else's people.

So while Cloud Computing <> Virtualization, VMs are the way that companies like BlueLock make infrastructure as a service and cloud computing a reality. You can do managed hosting without virtualization, but the economies of scale and the ability to decouple compute capacity from the underlying hardware that virtualization provides are what makes infrastrure "convenient", "on-demand" and "elastic" - thereby making elevating it from mere managed hosting to "cloud hosting". John Considine wrote a post on CloudSwitch's blog title, "Do VMs Still Matter in the Cloud". It's worth reading to understand one perspective of what virtualization and cloud computing do probably deserve to be joined at the hip.

Visibility and Managing Costs

Monday, July 26, 2010 by Bob Roudebush

The two biggest concerns that most clients have when moving to cloud hosting are “control” and “visibility”. Even though they are convinced of the benefits of cloud computing, they are concerned about giving up control of applications and data and they’re worried that they won’t have any visibility into their applications and data once they move them into the cloud.

Visibility is probably the single best tool that clients can have for managing costs. We provide a web-based portal (the BlueLock Vital Signs Portal) with granular reporting to show not only what clients are allocated in terms of compute and storage capacity within our cloud, but more importantly what they are consuming. Since in the IaaS world, the amount of capacity you have reserved is directly related to the overall cost of the hosting service, providing visibility into what is actually being consumed and allowing clients to adjust their reserved resources helps you maintain costs.

OpenStack the Deck

Tuesday, July 20, 2010 by John Ellis

Over the weekend the OpenStack project proudly announced its existence and its intended goal: to create an infrastructure cloud platform that can reach the scale of a million machines. NASA has evidently dedicated a team of employees to support these efforts likely to replace their existing Eucalyptus cloud fabric controller used within their Nebula infrastructure cloud.

NASA had already been working on Nova, a next-generation cloud fabric controller, for the better part of this year. Nova had even been released as open source project for public adoption. Meanwhile Rackspace, simultaneously prepping their "Ozone" cloud infrastructure software for public release, approached NASA to see if the two could meld their codebases together. As a result OpenStack was born and now Nova seems to have gone defunct... even Nova's old home at http://novacc.org/ redirects to the Nebula cloud computing platform page.

The announcement of OpenStack has generated quite a bit of buzz. Several out in the grand Interwebs are wondering what this collective brain weight will bring. The goals are quite lofty: allow an open, inter-operable fabric for deployment and provisioning of infrastructure as a service. And while there are many cloud projects ready to pledge support, I wonder if consumer adoption is just as rampant. Will service providers spring up, ready to host an OpenStack cloud? Bear in mind while the hypervisor management may be open source and (presumably) free for use, the capital expense of a data center is most decidedly not.

My biggest wonder is how these two (or three) separate projects, up to now independently architected, will be able to merge and work together as a cohesive whole. Nebula and Ozone appear to be comprised of C, Python and C++ - each of which are definitely complimentary languages to each other - but the codebases may leverage very disparate frameworks. Will code have to be largely re-designed and re-written? Will the separate pieces just end up sandwiched together? Or are the software engineering efforts so vast that it doesn't even matter?

One thing is becoming very apparent - everyone and their mom is racing to push their cloud solution out into public light. Even Oracle just released their Cloud Resource Model API - although it seems that is barely making a din above the OpenStack conversation. Everyone established infrastructure and/or software company seems to be throwing their hat in the ring and handing out orchestration solutions. One big problem exists however: are they going to start handing out blade chassis, too?

Yeah, I don't think so, either.

I could be rolling in free hypervisors but it always comes down to one thing: who is managing the SAN? Or figuring out the resulting layer 2 network craziness? Or keeping the cores stoked? Or keeping the backup generator filled with diesel?

Rights and Responsibilities in Cloud Computing (via Gartner)

Monday, July 19, 2010 by Alicia Gaba

Gartner recently released six "rights" and one "responsibility" for cloud service users/clients to help enable better business relationships between vendor and client. This list, although short, is actually quite exhaustive in terms of outlining some major topics a client should cover BEFORE entering a cloud hosting agreement.

Gartner's list of Cloud Computing Rights & Responsibilities:

The right to retain ownership, use and control one’s own data - Service consumers should retain ownership of, and the rights to use, their own data.

The right to service-level agreements that address liabilities, remediation and business outcomes - All computing services - including cloud services - suffer slowdowns and failures. However, cloud services providers seldom commit to recovery times, specify the forms of remediation or spell out the procedures they will follow.

The right to notification and choice about changes that affect the service consumers’ business processes - Every service provider will need to take down its systems, interrupt its services or make other changes in order to increase capacity and otherwise ensure that its infrastructure will serve consumers adequately in the long term. Protecting the consumer’s business processes entails providing advanced notification of major upgrades or system changes, and granting the consumer some control over when it makes the switch.

The right to understand the technical limitations or requirements of the service up front - Most service providers do not fully explain their own systems, technical requirements and limitations so that after consumers have committed to a cloud service, they run the risk of not being able to adjust to major changes, at least not without a big investment.

The right to understand the legal requirements of jurisdictions in which the provider operates - If the cloud provider stores or transports the consumer’s data in or through a foreign country, the service consumer becomes subject to laws and regulations it may not know anything about.

The right to know what security processes the provider follows - With cloud computing, security breaches can happen at multiple levels of technology and use. Service consumers must understand the processes a provider uses, so that security at one level (such as the server) does not subvert security at another level (such as the network).

The responsibility to understand and adhere to software license requirements - Providers and consumers must come to an understanding about how the proper use of software licenses will be assured.

This list brings light to what BlueLock is already doing right to better our relationships with our own clients. Based on the Gartner list provided, we are certainly in the right place.

1. Our clients do own and control their own data. We just provide and help manage the infrastructure platform.
2. BlueLock's Service Level Agreement (SLA) addresses liabilities, remediation and business outcomes the organization follows in the case of a service fall down.
3. BlueLock sends notifications and updates to our clients prior to, during and after any changes or updates to our environment that may or may not affect our client's environments. We even ask that our clients make us aware of any changes or updates on their end so that we can plan together to better alleviate any chance of disruption.
4. Technical limitations and service requirements are always discussed in the sales process.
5. We provide legal documentation upfront.
6. Our security procedures are very important to our clients, and therefore, our clients want and need to know what security processes we follow and adhere to.
7. Software license requirements are important - BlueLock must stay true to its software providers, and therefore, our clients must stay true to them as well.

To learn more about BlueLock's cloud hosting services, contact us or visit our website.

HPC - High(er) Performance Computing

Friday, July 16, 2010 by John Ellis

Recently the swell folks at The Register commented on AWS' latest cluster computing initiative centered around High Performance Computing. In a nutshell this differs from other EC2 instances by providing dedicated servers with two 2.93 GHz, quad-core Xeon X5570s and 23 GB of memory attached to a 10Gb switching layer. Previously you didn't have dedicated hardware... you floated in a pool of resources, hoping that today would be a good day. While the resulting performance gains from dedicated hardware may be significant over the floating-in-the-sea approach, in the end you are just getting a higher performance infrastructure and not a high performance infrastructure.

The annoncements and analysis made me chuckle a bit. For BlueLock to drop another slew of 144 GB blades into a chassis is standard operating procedure. Does that make us HPC as well? For us private clouds and dedicated hardware has always been the order of the day. I find it very telling that the decisions BlueLock made years ago are just now emerging as popular trends for Infrastructure as a Service today.

When evaluating managed IT hosting or cloud hosting providers, it's always good to look at performance not just in terms of "small," "medium" or "large." It's not even how much compute or memory you throw at the problem. Network and filesystem I/O (especially for cloud computing) is a huge factor in overall cluster performance, and one really needs to be at peace with your physical hardware to truly take advantage of your virtual solutions.

Cloud Computing Providers: Accountability and High Availability

Thursday, July 15, 2010 by Bob Roudebush

Potential cloud computing prospects make the assertion thata all cloud service providers promise availability that is “high.” Their contention often is that an internal IT department could potentially provide the same level of high availability. And to some extent, they're correct.

So what can an Infrastructure as a Service (IaaS) company like BlueLock promise relative to what a company would be able to achieve if it had invested in its own on-premises data center for a departmental application, for example? Accountability.

The entire premise underlying the value of cloud hosting is that by sharing a pool of physical resources, IaaS clouds can aggregate all of that compute capacity to deliver better scalability and availability than any one company could provide (even a large F500 company) on their own. In addition, BlueLock specializes in managed IaaS cloud offerings which add a layer of people on top of that compute capacity and are able to manage those hosted resources as well as (and many times better) than that company could on its own. Whether or not one takes stock in either of these assertions, the difference between hosting this in an outsourced data center versus one on-premise is the accountability aspect. With an outsourced solution, companies can have SLAs in place with guaranteed commitments and financial penalties if those commitments aren’t met. Typically an individual business unit wouldn’t have this “stick” to use with an internal IT department.

Transitioning from Traditional Computing Architectures to Cloud Architectures

Thursday, July 1, 2010 by Bob Roudebush

Typical data center architectures are based around not just the functions that servers perform, but the capabilities of the hardware in performing it. In a cloud computing scenario, supported by full-scale virtualization, the capabilities of the hardware change from constants to variables. Sometimes this makes it more difficult for architects to transition larger-scale deployments, even of specific functions like applications hosting, from physical data centers to the cloud.

To some extent, Infrastructure as a Service (IaaS) cloud computing (specifically virtualization as the enabling technology for cloud computing) does homogenize the capabilities of the underlying hardware being used. This is mostly a benefit because it provides economies of scale and allows IaaS providers to maintain higher availability for servers hosted in a cloud. It does make things like sizing or designing the deployment of applications a bit tougher because typically we deploy the different aspects of a multi-tier application on different types of platforms – i.e., small, scale-out environments for web servers and large, scale-up environments for back-end database servers.

One approach that can be taken is to build “clouds within clouds” each with different characteristics. A second approach would be to carve things like compute capacity or storage capacity up into “building blocks” so that when it’s time to deploy an application, an administrator can combine one or more of these “building blocks” to ensure that a specific part of the application is getting the performance it requires.

BlueLock takes both approaches. Within our IaaS cloud hosting offering, we have different tiers with different performance and availability characteristics – BlueLock vCloud Express, Virtual Cloud Professional and Virtual Cloud Enterprise. On the one end, BlueLock vCloud Express is great for things like dev and test. On the other end, Virtual Cloud Enterprise is a fully-managed IaaS cloud built for performance and availability and perfect for mission-critical or regulated applications. We try to work closely with prospects to understand their needs and then match those up with the appropriate service.

The OVF Envelope for Virtual Application Solutions

Thursday, July 1, 2010 by John Ellis

Last night's episode of This Week in Cloud Computing features BlueLock's CTO and Co-Founder Pat O'Day. In the episode the subject of application & virtual machine portability comes up several times and Pat discusses one aspect of VM deployment: allowing several virtual machines to be deployed together as a singular, orchestrated virtual application solution. In VMware parlance this kind of logical grouping is considered a vApp, or virtual application solution.

The distinction between vApps and VMs can get a bit foggy and unclear at times. Things become a bit clearer when you take a look at the Open Virtualization Format (OVF) specification, which outlines the metadata that describes a vApp. In a nutshell: vApps are ultimately not definied by the virtual machines that run within them, but instead is a way of telling your infrastructure how VMs can play nicely with each other. Should the exist within an isolated network? How should IP addresses be allocated? Do you start the database server before the application server? Where did that other sock go? The OVF format lets your cloud infrastructure know all the facts necessary during deployments, shutdowns and re-starts.

This can be especially handy for disaster recovery. Imagine a meteor strikes your primary cloud hosting facility. Even though your operations staff now has super-powers, your data center is toast. Luckily you had the presence of mind to keep your vApps in an off-site data center that automagically activates when the primary data center goes offline. Thanks to the vApp's metadata, the disaster recovery site knows how to start an entire n-tier web application in an orderly fashion so that dependent services don't start out-of-order.

This kind of virtual application meta-data is being continuously extended to include service levels and quality of service data so that vApps can be deployed or even migrate to the most ideal resource pool either based on cost, performance or a mix between the two. This specification is evolving, and so are the use cases and technology stack that supports it. As the cloud ecosystem matures we will continue to see innovative ways to focus on not just the virtual machine, but the entire virtual solution.

Software as a Service: Don’t Re-Invent the Wheel

Monday, June 28, 2010 by Brandon Jeffress

As the evolution of software continues to evolve towards the Software as a Service (SaaS) model, I regularly get asked questions during my conversations with software executives that further tells me that companies want and need help in this time of evolution.

Some examples of those regularly asked questions are:

How are people licensing the software in the SaaS model?
How are companies structuring their pricing in the SaaS world?
Should I charge for new enhancements or is that included in the service?
How do I ensure my client’s data is protected in a hosted environment?
How can I get better performance in the cloud?

While some companies have this figured out well (at least for today), others continue to struggle and constantly feel like they are reinventing the wheel. To this end, an organization and newsletter called SoftLetter started a quarterly conference called SaaS University.
SaaS University is a multi-day conference that focuses on helping top executives (C, E, and VP level) of software companies to be educated around an array of topics concerning SaaS.

The event focuses on topics such as:

What is SaaS?
What does Cloud mean & what options are best for me?
Pricing
Fund Raising
Development Methodologies
Hosting Options
Licensing Options
Trends, and more.

Various industry experts lead congruent sessions allowing attendees to focus on the subjects that mean the most to them. My experience is that SaaS University has found some of the most quality experts to lead the discussions and sessions. The feedback I received from other attendees supports those sentiments as well.

Thought leaders are asked to speak about industry subject matter and various offerings to support a SaaS company. They use this stage to speak consultatively on various industry trends and decision factors.

The goal of the event is that top executives can walk away knowing that there are real answers to their questions and that they do not have to re-invent the wheel to be a successful SaaS company. The networking of software executives and industry leaders jointly make the multi-day educational process a great way to learn fresh and new ideas, as well as the basics of being successful as a SaaS company.

The next SaaS University Event is July 20-22nd in Washington DC. Use the code BLUELOCK100 for $100 off. Register & learn more today.

BlueLock Selects Wright Line for Data Center Heat Containment

Monday, June 28, 2010 by Alicia Gaba

Cloud Computing Services Expert Chooses Advanced Heat Containment System from Airflow Management Authority

Worcester, MA June 28, 2010 -- Wright Line today announced that it has integrated its patented Heat Containment System (HCS) into BlueLock’s world-class, SAS 70 certified data center. BlueLock is an experienced provider of cloud hosting and managed IT services headquartered in Indianapolis.

“As a result of business growth and increased processing densities, excess heat was being produced in our data center,” said Mike Durham, BlueLock’s Director of Quality. “With Wright Line’s HCS, our ability to contain the hot air exhausted at the rack level, and then return it directly back into the CRAC, provides a predictable and efficient operating environment.”

Wright Line’s HCS was developed in direct response to customers growing concerns about the need to significantly reduce operating and capital costs while conserving energy and eliminating the waste most data centers currently experience.

The system captures, manages and directs the heat exhaust from IT equipment to the top rear of the rack enclosure were it is ducted to the data center’s precision air conditioning units through a ceiling plenum or hot air return.

The HCS can be seamlessly integrated into Wright Line’s own Paramount and Vantage Enclosure platforms, as well as most third-party server enclosures, including APC®, Rittal, Knurr and Chatsworth Products, Inc at the factory or in the field.

Disaster Recovery in the Cloud: We’re Not In Kansas Anymore

Thursday, June 24, 2010 by Jon Schackmuth

Every year during the months of June and July the Midwest gets hit with tremendous storms in the late afternoon to early evening. If you have never experienced this type of weather pattern, it is quite alarming. It can be sunny and ninety degrees while sitting at work or spending time at the pool with the kids when dark storm clouds roll in and strong winds blow across the hot blacktop. If there were tumbleweed lying around, many suburban neighborhoods would look like an old western shootout.

Within moments, raindrops and hail the size of marbles are pelting down on anything and everyone in sight. Lightning streams across the sky and the tornado horn sounds; Welcome to the Midwest. Whether you experience this type of weather or any other extreme storms, you need to ask yourself, what kind of back-up generator do I need to keep my data center up and running?

Just last week, I was talking with a new client who is in the process of moving part of his infrastructure into the cloud. He had recently experienced a four hour power outage at his office, leaving their on-site systems inoperable. When most businesses operate without a disaster recovery plan due to financial constrains, I always ask the question - what is your threshold for pain? It may sound a bit dramatic, or maybe it’s the ex-military in me, but in the end, the question is valid. Most companies can work though a few hours of power loss, but when the clock keeps ticking and trucks aren’t rolling or vendors can’t pay for days or weeks, the pain threshold is diminished and tensions rise.

Cloud hosting has become well accepted in every size business. What most CEO’s/Owners may not realize is that they don’t need to put all their proverbial chips in the pot, they can do a hybrid approach to maximize their existing infrastructure or simply utilize the cloud as a pure disaster recovery solution without spending large amounts of their budget on collocation equipment. I have never understood why companies buy equipment for disaster recovery and let their hard earned money depreciate, let a true cloud company flip the bill for the equipment and as the business owner or CEO, reinvest your CAPEX back into your business.

Next time you hear the tornado horn sound, think about a company like BlueLock that is rated for an F5 and ask yourself, "Are We Still In Kansas?"

For more information on BlueLock, an Indianapolis based company, visit our website or call me directly at 888-402-1980 ex. 127

Building out a New Data Center - Part II

Tuesday, June 22, 2010 by Jake Barna

As Mike Durham mentioned in Part I of Building out a New Data Center, equipment should failover & operate as normal when one power feed is shutdown.

What happens when a procedure doesn’t go as planned? How does a company prepare for a worst case scenario? These are just a few of the questions that should be addressed in a Change Management Plan.

The ITIL world defines Change Management as: Ensuring that standardized methods and procedures are used for efficient and prompt handling of all changes, in order to minimize the impact of Change-related incidents upon service quality, and consequently to improve the day-to-day operations of the organization.

In a data center environment, this translates into: risk assessment, mitigation, contingency procedures, scheduled maintenance, etc… BlueLock incorporated many of these into an internal Change Management Plan to successfully built out a new data center.

Check the Quality Corner next month as we continue to blog about the expansion of our BlueLock facility!

Building out a New Data Center

Friday, June 18, 2010 by Mike Durham

With all of the recent growth at BlueLock, the Facilities team was challenged with the assignment of building out a new data center. Building out a new data center is never a small task. The devil is in the details!

Looking to build out your own data center? Feel free to use our learning and framework for your own endeavors:

First, a firm should be selected to act as the general contractor (GC) for the project. Then, form a team consisting of both GC and company personnel. A traditional project plan will help create structure. It should include all components to ensure the proper funding, planning, communication, execution, and commisioning were done prior to final inspection and release. This foundational planning is of utmost importance.

An even more detailed plan should be created for the most critical components of the project, namely, installing new AC units with rooftop condensing units, and 2) installing new power feeds. Structural analysis should be done by a third party to ensure the roof top or other structures can support the additional weight and load of the condensing units.

Now on to installing the new power feeds. Most of BlueLock's data center equipment is dual corded which means that a loss of one power source doesn't affect the operation of the equipment as long as the second source of power is still available.  Equipment that isn't dual corded should be placed on an automated transfer switch that causes the equipment to act like a dual corded piece of equipment.

Power loads must be monitored to make sure that when the load on the equipment is transfered from one feed to the other, the breakers could handle the increased power load. Loads must be monitored at the circuit level to make that determination. Power will need to be shut down to the first side so the electricians can safely perform the installation work. The load from the side that is shut down will be transferred to the second side. All equipment should continue to operate as normal.

Stay tuned for more.

Does this application make my server look fat?

Thursday, June 17, 2010 by Bob Roudebush

In a previous post, I talked about the challenges of sizing a cloud computing infrastructure, specifically one for running Microsoft SQL Server. Because it's the back-end for many corporate IT systems and also serves as part of a lot of internet-facing applications, Microsoft SQL Server is certainly one of the more popular candidates for consideration when looking to leverage Infrastructure As A Service. It's not the only one, however, so understanding how to properly size a managed cloud hosting VM is important regardless of the application being considered. Luckily, it's easier than one might think.

The key is almost always completely understanding how the application is performing today and what hardware (physical -or- virtual) it's running on currently.

There are a ton of great tools out there to assist with these assessments. Commercial tools such as Lanamark VReady, Novell Platespin Recon and Vizioncore vFoglight are popular candidates and there are many more where those came from. VMware partners like BlueLock can even provide this information as a service offering using the VMware Capacity Planner tool which is an IT capacity planning tool that collects comprehensive resource utilization and compares it to industry standard reference data to provide analysis about what how much capacity is needed in a virtualized environment using Vmware Virtualization Technology.

One hidden gem that is often overlooked, though, is the VMware Guided Consolidation tool included as a feature of VMware vCenter. Now a module within vCenter Server, it walks you step by step through the consolidation process including automatic discovery of up to 500 servers, performance analysis, conversion and intelligent placement on the right host. Even if you aren't planning on building your own private cloud and, instead, are looking to Cloud Computing Companies to run your virtualized workloads, the VMware Guided Consolidation tool can at least help you assess your current environment if you are a small or mid-sized business. It has an easy to use interface and a more simplified approach than using hte full VMware Capacity Planner tool.

BlueLock vCloud Express Passes jclouds Certification

Wednesday, June 16, 2010 by John Ellis

Just got word that BlueLock passed the gauntlet of exhaustive automation tests for the jclouds API today!

jclouds is the Swiss Army knife of cloud APIs. Not only does it connect tons of Platform as a Service and Infrastructure as a Service offerings it also connects cloud storage services, manages deployments intelligently, bootstraps grids and makes some fantastic grilled cheese.

What gets me really excited about jclouds is the Chef integration their development team is working on. Chef turns the usually arduous process of deploying a server into a plug-and-play affair by automagically installing packages, managing configs, altering interfaces and doing tons of post-provisioning routines. By building a list of recipies from cookbooks, one can come up with a repeatable and auditable process for deploying an array of disparate servers into a datacenter, virtual or physical.

Imagine a world where asking for a new development environment, not just a single test server, is a point-and-click affair. No req's. No red tape. No SOx Docs. One just needs a Chef repository of cookbooks, a virtual datacenter and some fresh code to deploy. Such a time is is much closer than you might expect!