Wednesday, March 6, 2013

Blade Servers, Regular Servers and Eucalyptus


When planing what types of servers to use for your Eucalyptus deployment, there are several things to take into consideration. The first thing to consider is what type of network you are deploying to (e.g. one that you completely control or a colocation facility). The second thing to consider is what type of storage you plan to use with the Walrus (e.g. local disk, iSCSI LUN, Fibre Channel backed LUN, etc.). Figuring out these things ahead of time will help you to pick the best server options for your Eucalyptus Cloud. In this article, I will discuss the two most popular types of server formats used: blades and standard rack mount (RU) servers. 

Blade servers, such as Cisco UCS, Dell M-series Bladecenter and IBM Bladecenter consist of a blade chassis, which mounts to a rack, and small individual servers which sit in the chassis called blades. The main purpose to blade servers is higher rack density. A typical blade chassis can fit twice the number of servers or more per rack unit (RU) than traditional servers. One thing to note is that for a server to be a true blade server, it must mount within a chassis to be used. There is a common misconception out there that a standard rack mount server can also be a blade server. I have seen people refer to standard 1U or 2U rack mount servers as 'blades' and this is absolutely not the case. I'm not sure if this is a result of manufacturers 'blade washing' their limited offerings or of chain partners (such as VARs) trying to bundle a technology stack and calling the servers blades to jump on a buzzword and sell more. Either way, if a server can power on and operate without mounting inside of a blade chassis, it is not a blade server. This distinction is important because it also entails the utilization of the blade chassis modules for power, networking, storage, etc. 

Networking is more complicated with a blade chassis because there is a virtual network that is internal to the blade chassis, which runs across the backplane, but does not extend beyond the chassis. If network traffic needs to leave the chassis, it must be routed to a network module on the blade chassis which then passes the traffic out and onto the regular network. In a co-located environment, you typically do not have complete control of the entire network, so having the ability to control all VLANs, even across the core switches, is probably not an option. This could potentially impact your network mode choice, moving you to Managed-NoVLAN instead of Managed mode. if you do control the entire network and can fully segregate the Eucalyptus 'back-end' network from the rest of your network, then you can use Managed mode and gain layer 2 isolation for your Cloud.

Let's look at the Walrus storage. Walrus was originally designed to be backed by local disk and has a requirement for DRBD if you are planning to deploy in HA mode. Since most production deployments will be in HA, you must take the DRBD requirement into account. DRBD is a block-level replication technology, built into the kernel, that keeps two or more volumes in sync. The Walrus uses DRBD to keep the volumes backing the '/bukkits' directory in sync between both Walrus servers. The volume syncing takes place over a standard network interface (e.g. eth0) and constantly consumes bandwidth as it is doing this. If you are planning to use local disk for your Walrus storage, you should avoid blade type servers. These often have two or fewer disks and will limit the total size of your Walrus object store. Using standard rack mount servers for the Walrus is your best option if you are going to use local disk to back the object store. With offerings that can fit up to 16 disks in a 2U form factor, standard servers can pack a serious amount of storage space for your Walrus servers.

If you are using blade servers in order to achieve higher rack density, hope is not all lost. You can still use Fibre Channel or iSCSI LUNs to back the Walrus object store. In this case you will need to create two identical LUNs and export them, one to each Walrus. You should also 'mask' or isolate which host can see which LUN. Using LVM on top of these iSCSI LUNs and then layering DRBD on top of LVM is the way to go. It allows you to easily grow your Walrus LUNs down the road. This also allows you to scale the Walrus larger than local disks would normally allow as there is a finite amount of disks that will fit in a single server. A SAN can scale far larger, or until your SAN vendor artificially stops scalability to push you to a higher tier SAN. 

Networking and storage are just two areas to keep in mind when considering the use of blade servers, but they are vitally important areas for a Eucalyptus Cloud. Understanding the benefits and drawbacks of regular servers and blade servers will help you make a better choice in terms of hardware. 

1 comment:

  1. +1 for blades if cloud can fit to enclosure/chassis servers < 16
    If cloud is bigger it is simpler to user rack servers and also enjoy bigger disk capasity.

    ReplyDelete