This is the multi-page printable view of this section. Click here to print.
This section describes the parameters you need to set in order to launch Eucalyptus for the first time.
The first launch of Eucalyptus is different than a restart of a previously running Eucalyptus deployment in that it sets up the security mechanisms that will be used by the installation to ensure system integrity.
Eucalyptus configuration is stored in a text file, /etc/eucalyptus/eucalyptus.conf, that contains key-value pairs specifying various configuration parameters.
We recommend enabling SELinux on host systems running Eucalyptus 4.4 services to improve their security on RHEL 7. Enabling SELinux, as described in this topic, can help contain break-ins. For more information, see RedHat SELinux documentation.
You need to set boolean values on Storage Controller (SC) and Management Console host machines. If your network mode is VPCMIDO, you also set a boolean value on the Cloud Controller (CLC) host machines. To configure SELinux on Eucalyptus 4.4 :
On each Storage Controller (SC) host machine, run the following command:
setsebool -P eucalyptus_storage_controller 1
This allows Eucalyptus to manage EBS volumes.
On each Management Console host machine, run the following command:
setsebool -P httpd_can_network_connect 1
This allows the Management Console’s HTTP proxy to access the back end.
If your cloud uses VPCMIDO networking mode, on the Cloud Controller (CLC), run the following command:
setsebool -P httpd_can_network_connect 1
This allows the CLC’s HTTP proxy to access the back end.
SELinux is now configured and ready to use with your Eucalyptus 4.4 cloud.
This section provides configuration instructions for Eucalyptus networking modes. Eucalyptus overlays a virtual network on top of your existing network. In order to do this, Eucalyptus supports these networking modes: EDGE (AWS EC2 Classic compatible) and VPCMIDO (AWS VPC compatible).
This topic provides configuration instructions for Eucalyptus EDGE network mode. Eucalyptus requires network connectivity between its clients (end-users) and the cloud components (e.g., CC, CLC, and Walrus).
To configure Eucalyptus for EDGE mode, most networking configuration is handled through settings in a global Cloud Controller (CLC) property file.
The /etc/eucalyptus/eucalyptus.conf file contains some network-related options in the “Networking Configuration” section. These options use the prefix VNET_. The most commonly used VNET options are described in the following table.
The most commonly used VNET options are described in the following table.
| Option | Description | Component |
|---|---|---|
| VNET_BRIDGE | This is the name of the bridge interface to which instances’ network interfaces should attach. A physical interface that can reach the CC must be attached to this bridge. Common setting for KVM is br0. | Node Controller |
| VNET_DHCPDAEMON | The ISC DHCP executable to use. This is set to a distro-dependent value by packaging. The internal default is /usr/sbin/dhcpd3. | Node Controller |
| VNET_MODE | The networking mode in which to run. The same mode must be specified on all CCs and NCs in your cloud. Valid values: EDGE | All CCs and NCs |
| VNET_PRIVINTERFACE | The name of the network interface that is on the same network as the NCs. Default: eth0 | Node Controller |
| VNET_PUBINTERFACE | This is the name of the network interface that is connected to the same network as the CC. Depending on the hypervisor’s configuration this may be a bridge or a physical interface that is attached to the bridge. Default: eth0 | Node Controller |
You must edit eucalyptus.conf on the Cluster Controller (CC) and Node Controller (NC) hosts. You must also create a network configuration file and upload it the Cloud Controller (CLC).
Log in to the CC and open the /etc/eucalyptus/eucalyptus.conf file. Go to the Network Configuration section, uncomment and set the following:
VNET_MODE="EDGE"
Save the file. Repeat on each CC in your cloud.
Log into an NC machine and open the /etc/eucalyptus/eucalyptus.conf file. Go to the Network Configuration section, uncomment and set the following parameters:
VNET_MODE
VNET_PRIVINTERFACE
VNET_PUBINTERFACE
VNET_BRIDGE
VNET_DHCPDAEMON
For example:
VNET_MODE="EDGE"
VNET_PRIVINTERFACE="br0"
VNET_PUBINTERFACE="br0"
VNET_BRIDGE="br0"
VNET_DHCPDAEMON="/usr/sbin/dhcpd"
Save the file. Repeat on each NC.
To configure the rest of the EDGE mode parameters, you must create a network.yaml configuration file. Later in the installation process you will Upload the Network Configuration to the CLC.
Create the network configuration file. Open a text editor. Create a file similar to the following structure.
# A list of servers that instances receive to resolve DNS names
InstanceDnsServers:
- ""
# List of public IP addresses or address ranges
PublicIps:
- ""
# A list of cluster objects that define each availability zone (AZ) in your cloud
Clusters:
-
# Name of the cluster as it was registered
Name: ""
# Subnet definition that this cluster will use for private addressing
Subnet:
# Arbitrary name for the subnet
Name: ""
# The subnet that will be used for private addressing
Subnet: ""
# Netmask for the subnet defined above
Netmask: ""
# Gateway that will route packets for the private subnet
Gateway: ""
# List of Private IP addresses or address ranges for instances
PrivateIps:
- ""
Save the network.json file. The following example is for a setup with one cluster (AZ), called PARTI00, with a flat network topology.
InstanceDnsServers:
- "10.1.1.254"
PublicIps:
- "10.111.101.84"
- "10.111.101.91-10.111.101.93"
Clusters:
- Name: PARTI00
Subnet:
Name: "10.111.0.0"
Subnet: "10.111.0.0"
Netmask: "255.255.0.0"
Gateway: "10.111.0.1"
PrivateIps:
- "10.111.101.94"
- "10.111.101.95"
For a multi-cluster deployment, add an additional cluster to your configuration for each cluster you have. The following example has an two clusters, PARTI00 and PARTI01.
InstanceDnsServers:
- "10.1.1.254"
PublicIps:
- "10.111.101.84"
- "10.111.101.91-10.111.101.93"
Clusters:
- Name: PARTI00
Subnet:
Name: "10.111.0.0"
Subnet: "10.111.0.0"
Netmask: "255.255.0.0"
Gateway: "10.111.0.1"
PrivateIps:
- "10.111.101.94"
- "10.111.101.95"
- Name: PARTI01
Subnet:
Name: "10.111.0.0"
Subnet: "10.111.0.0"
Netmask: "255.255.0.0"
Gateway: "10.111.0.1"
PrivateIps:
- "10.111.101.96"
- "10.111.101.97"
This topic provides configuration instructions for Eucalyptus VPCMIDO network mode. Eucalyptus requires network connectivity between its clients (end-users) and the cloud components (e.g., CC, CLC, and storage).
To configure VPCMIDO mode parameters, you must create a network.yaml configuration file. Later in the installation process you will Upload the Network Configuration to the CLC.
Create the network configuration file. Open a text editor. Create a file similar to the following structure. This example demonstrates two gateways and two BGP peers (sections relevant to VPCMIDO are shown here).
Mode: VPCMIDO
PublicIps:
- "10.116.150.10-10.116.150.254"
- "10.117.150.10-10.117.150.254"
Mido:
BgpAsn: "64512"
Gateways:
- Ip: "10.111.5.11"
ExternalDevice: "em1.116"
ExternalCidr: "10.116.128.0/17"
ExternalIp: "10.116.133.11"
BgpPeerIp: "10.116.133.173"
BgpPeerAsn: "65000"
BgpAdRoutes:
- "10.116.150.0/24"
- Ip: "10.111.5.22"
ExternalDevice: "em1.117"
ExternalCidr: "10.117.128.0/17"
ExternalIp: "10.117.133.22"
BgpPeerIp: "10.117.133.173"
BgpPeerAsn: "65001"
BgpAdRoutes:
- "10.117.150.0/24"
Save the network.yaml file. The following example demonstrates a gateway with static routing configuration.
Mode: VPCMIDO
PublicIps:
- "10.116.150.10-10.116.150.254"
Mido:
Gateways:
- Ip: "10.111.5.11"
ExternalDevice: "em1.116"
ExternalCidr: "10.116.128.0/17"
ExternalIp: "10.116.133.11"
ExternalRouterIp: "10.116.133.173"
This topic provides detailed configuration parameter information for Eucalyptus VPCMIDO network mode.
The following table provides a list of VPCMIDO parameters.
| Parameter | Description | Validation |
|---|---|---|
| BgpAsn | (Optional) Global BGP configuration *BGP Autonomous System Number assigned (to be decided by administrator/installer) for this VPCMIDO deployment. Private ASN range should be used:16-bit: 64512 - 6553432-bit: 131072 - 4199999999 (RFC6996) | Private use blocks recommended, but owners of public ASNs can use public ASNs or other blocks if they wish.Valid range is 1 - 4294967295. |
| Gateways | (The VPCMIDO gateway parameters are below.) | Per MidoNet/BGP limitation, a maximum of 6 MidoGateways can be used. |
| Ip | Internal IP address of Mido Gateway (not to be confused with the IP address of the gateway interface used in external communications). Note: Replaces 4.3 GatewayHost parameter. | Must be a valid IP address.Must be a live IP address configured on the machine. |
| ExternalDevice | Device name of Mido Gateway interface that is physically connected to the external network (i.e., has L2 connectivity to the infrastructure router or BGP peer). This interface is dedicated for MidoNet use (Mido Gateway Operating System should not have control of this device). Note: Replaces 4.3 GatewayInterface parameter. | Must be a valid network interface connected to the network where L2 communication with BgpPeerIp (or ExternalRouterIp) can be established. |
| ExternalCidr | CIDR block used in the external routing. Note: Replaces 4.3 PublicNetworkCidr parameter. | Must be a valid CIDR block. |
| ExternalIp | IP address to be configured on ExternalDevice by eucanetd. Its subnet is as specified in ExternalCidr (ExternalCidr must contain ExternalIp). Note: Replaces 4.3 GatewayIP parameter. | Must be a valid and unused IP address.Must be within ExternalCidr.Must not be a network or broadcast address. |
| ExternalRouterIp | IP address of an external router (for static configuration). This is the router IP address used in default routes for traffic originating from MidoNet. Note: Partially replaces 4.3 PublicGatewayIp parameter. | Must be a valid and unused IP address.Must be within ExternalCidr.Must not be a network or broadcast address.Either ExternalRouterIp or BgpPeerIp is required. |
| BgpPeerIp | (Optional) BGP configuration * IP address of a BGP peer. This is the IP address to where MidoNet router will attempt to establish a BGP session.Note: Partially replaces 4.3 PublicGatewayIp parameter. | Must be a valid and unused IP address.Must be within ExternalCidr.Must not be a network or broadcast address.Either ExternalRouterIp or BgpPeerIp is required. |
| BgpPeerAsn | (Optional) BGP configuration * BGP peer ASN for this MidoGateway. | Valid range is 1 - 4294967295. |
| BgpAdRoutes | (Optional) BGP configuration * A list of CIDR blocks delegated to this VPCMIDO deployment. VPCMIDO BGP will be configured to advertise these routes. public IPs must be within these CIDR blocks. The same list can be used for all MidoGateways. The advantage of having a separate list per MidoGateway is that it allows different MidoGateways to be responsible for different CIDR blocks. If the same list of CIDR blocks is used for all MidoGateways, MidoNet built-in load sharing/balancing mechanism is used. | Each entry must be a valid CIDR block. |
| PublicIps | The public IP address ranges associated with VPCMIDO. | With BGP: Each public IP must be within one of the CIDR blocks in the union of all BgpAdRoutes entries.Must be a valid IP address range.Must not contain network or broadcast address of the CIDR blocks in the union of all BgpAdRoutes.Without BGP: On-premise infrastructure must route all PublicIps to one of the MidoGateways. |
Gateways with BGP require BgpPeerAsn , BgpAdRoutes , and BgpAsn . If all gateways are static (no BGP), BgpAsn is optional. A gateway with BGP has BgpPeerAsn and BgpAdRoutes parameters; a static gateway does not.
This topic describes how to set up the Cluster Controller (CC) to choose which Node Controller (NC) to run each new instance.In the CC, open the /etc/eucalyptus/eucalyptus.conf file. In the SCHEDPOLICY= parameter, set the value to one of the following: GREEDY When the CC receives a new instance run request, it runs the instance on the first NC in an ordered list of NCs that has capacity to run the instance. At partial capacity with some amount of churn, this policy generally results in a steady state over time where some nodes are running many instances, and some nodes are running few or no instances. ROUNDROBIN (Default) When the CC receives a new instance run request, it runs the instance on the next NC in an ordered list of NCs that has capacity. The next NC is determined by the last NC to have received an instance. At partial capacity with some amount of churn, this policy generally results in a steady state over time where instances are more evenly distributed across the set of NCs. Save the file.