The following image depicts the logical relationship between Eucalyptus components
in a generalized deployment.
The cloud components, Cloud Controller (CLC) and Walrus, communicate with cluster
components,
the Cluster Controllers (CCs) and Storage Controllers (SCs). The CCs and SCs, in
turn,
communicate with the Node Controllers (NCs). The networks between machines hosting
these components must be able to allow TCP connections between them.
However, if the CCs are on separate network interfaces (one for the network on which
the cloud
components are hosted and another for the network that NCs use) the CCs will act
as software
routers between these networks in some networking configurations. So each cluster
can use an internal private network for its NCs
and the CCs will route traffic from that network to a network shared by the cloud
components.
Virtual machines (VMs) run on the machines that host NCs. You can use the CCs as software
routers for traffic between clients outside Eucalyptus and VMs. Or the VMs can use
the routing framework already in place without CC software routers. However, depending
on the layer-2 isolation characteristics of your existing network, you might not be
able to implement all of the security features supported by Eucalyptus.
Eucalyptus HA
If you configure Eucalyptus for high availability (HA), the you will have primary
and secondary cloud and
cluster components. In the
event of a failure, the secondary component becomes the primary component.
Eucalyptus HA uses a service called Arbitrator that monitors connectivity
between a user and a user-facing component (CLC, Walrus, and CC). An Arbitrator
approximates reachability to a user. Each Arbitrator uses ICMP messages
to periodically test reachability to an external entity (for example, a
network gateway or border router) or to an external site (for example,
google.com).
An Arbitrator is not required in HA. However, it is nice to have in order to test
connectivity with a user.
If all Arbitrators fail to reach its monitored
entity, Eucalyptus assumes there is a loss of connectivity between a user and the
component. At that point a failover occurs. To allow for normal outages and
maintenance, we recommend that you register more than one Arbitrator for
each user-facing component.
