In our last blog post, I discussed the storage considerations for the Eucalyptus Walrus component. Toward the end of the post, I talked about pondering some additional implications of using a SAN to back Walrus if you are going to use a Eucalyptus supported SAN with the SAN adapter for the Storage Controller (SC). In this post, we will delve into the various ways you can deploy the Storage Controller (SC) component, building from non-HA to HA with the Eucalyptus SAN adapter. Keep in mind that using the SAN adapter is a requirement for deploying the SC in HA, so if you do not have a Eucalyptus supported SAN (at the time of this publication this includes EMC VNX, NetApp and Dell Equallogic) you can only deploy in non-HA mode.
How the Storage Controller FunctionsThe SC functions in one of two ways in a Eucalyptus cloud depending on whether you deploy in HA or non-HA mode. They are quite different, so carefully consider each approach when designing the SC component of your cloud.
|Eucalyptus SC Logical Diagram|
for non-HA and HA modes.
In HA mode, the SC can be thought of as a proxy that takes EBS requests and orchestrates the provisioning, exporting and mounting of iSCSI LUNs from a supported SAN via the SAN adapter. In this scenario, the SC is NOT in the data path. Node Controllers mount the iSCSI LUNs directly from the SAN, not the SC. Not only is this more performant, in the case of an SC failure, you do not lose data or connectivity. The second SC simply takes over and proxies all of the SC related requests to the SAN and NCs. With all that said, lets take a look at HA and non-HA mode storage considerations.
|Eucalyptus non-HA SC data path|
OverlayOverlay simply means that Eucalyptus will use the local filesystem and “overlay” storage of your EBS volumes onto that directory. By default, Eucalyptus uses the ‘/var/lib/eucalyptus/volumes’ directory for SC storage in Overlay mode.
Direct Attached Storage (DAS)When using DAS, you are able to specify a device to use for the SC’s storage space. This can either be a raw device (like /dev/sdb) or a LVM volume group.
The main reason for using DAS instead of Overlay is performance and control, especially if you are using network storage of some type, such as an iSCSI or Fibre Channel LUN. Overlay has the benefit of being much simpler to setup and configure (for small test clouds or POCs) and also allows you to use something like NFS to back the ‘/var/lib/eucalyptus/volumes’ directory instead of a block device. Both have their uses, but DAS is a step up in terms of performance and flexibility which was introduced in 3.2, and is highly recommended if you are able to dedicate a raw device for it’s usage.
|Eucalyptus HA SC data path|