Wednesday, March 6, 2013

EucaStart 2.0 Stage 2 - Cloud Architecture: Compute and Misc. Considerations

In the first three posts in this series we took a look at networking, application stack, and storage considerations when designing Eucalyptus clouds. In this blog post, we will take a look at compute infrastructure considerations, as well as some misc. gotchas and common mistakes to avoid when designing a Eucalyptus cloud.

Compute Infrastructure Considerations

The compute infrastructure, though the heart of any cloud platform, is the last to get consideration since many other factors affect the final design. For the front-end servers, we should by now have an excellent idea of expected load and can size accordingly for disk to network bandwidth. For the Node Controllers, we can now safely determine what the needs are in terms of compute power and size them accordingly Following are some considerations for your design.

Sizing Node Controllers

One common question/consideration revolves around the number of node controllers based on your application resource needs.  While total resource needs should be pretty straightforward (take everything you've gathered up to this point and add up CPU, RAM, network, and storage needs) how you divide up those resources is still a question. Options include:

* Fewest and biggest boxes (density). Tradeoff = more chances for single point of failure (SPOF). N+1 design.

* Lots of smaller boxes and spread the load (failure recovery, but what about big apps?)

* Try to do both in a multi-cluster deployment? (Use IAM to restrict resource access?)

* Middle-of-the-road approach with medium-sized boxes across the cloud.

While each solution has its pros and cons, our internal bias is to always go with middle of the road box. Small boxes = tons of money for network connections, ports, and management. Big boxes = lots of cost for failure recovery. Middle of road = medium pain on both sides.

Utilization Rate Planning

Another consideration is utilization. Again, our internal bias is to always size CPU, RAM and storage infrastructure at 80% utilization. We do not size at 100%, as you can easily and unexpectedly kill your cloud performance when the inevitable spike hits. When planning for networking bandwidth, we suggest planning for 50% utilization to handle spikes, as well as reserve capacity to deal with host failures, etc.

Additional Considerations

Lastly, though not a part of the Eucalyptus design itself, we try to make sure that there are no unmentioned pain points that could pop up post-installation, such as unanticipated bandwidth usage for communication to a back-end database farm which perhaps was on the same switch or same virtual machine farm the applications were initially sitting on. (This happens more frequently than most people imagine.)

Another common pitfall to avoid is the use of DNS lookups by the applications themselves by methods specific to the hosts they reside on. In two of the four networking modes, the instances do not know their public IP or DNS information, thus a query of the instance by an application will give erroneous information.

Also, understanding if the customer will need full DNS integration from Eucalyptus to their authoritative DNS infrastructure is important. Eucalyptus does not use BIND (contrary to popular belief), so any integration will be at the behest of the java dns tool we use.

There are many other small 'gotchas' that could pop up which are impossible to capture in the scope of this blog series, but the general idea is to become as familiar with a customer's infrastructure as they are and design the Eucalyptus cloud to integrate as seamlessly as possible into the existing data center infrastructure.

Let us know what you think. Do you agree or disagree with our recommendations and rules of thumb? Have we missed anything important in overall cloud design? What do *you* recommend to your customers or your employer when looking at building out a new cloud or adding capacity to an existing one? I'd love to hear from you. I can be reached via email at, or you should feel free to reply in the comments. Thanks!

No comments:

Post a Comment