Hola! Yo Soy Dora! I hope you are having a great week and for those in the US, I hope your 4th of July holiday was fun and relaxing.
Here’s another “how to” for those not real familiar with Linux when standing up a vCloud Director infrastructure. If you’re following the documentation, you’ll notice on page 13 of the vCloud Director Installation and Configuration Guide that two NICs or an IP alias are required to support two separate SSL connections on each vCloud Director cell server. One IP is used for the vCloud Director HTTP service and the other is used for the console proxy service. I’ve deployed both methods, multiple NICs and IP aliasing, for the VCD cell server. Neither method has a distinct advantage over the other in terms of performance or other important metrics. Where both the http and console proxy addresses are on the same subnet, I prefer to use the IP Alias method to keep things a little cleaner but using two NICs is better at full disclosure in terms of how the VCD Cell Server is built and configured from a network standpoint.
To wrap some visualization around the two options, if you’re not familiar with Linux IP Aliasing, you’d probably deploy each VCD cell server in a multihomed configured with a minimum of two NICs and two IP addresses required for VCD, one IP established for each of the required SSL connections.
The IP Alias method involves just a single NIC with two IP addresses on the same subnet sharing a common mask and default gateway for the two required SSL connections. Don’t forget that with either method, without routed NFS on the network, each VCD cell server would likely have one additional NIC dedicated to an NFS network for vCloud Director Transfer Storage assuming the clustered cell configuration recommended for production and highly available cloud infrastructures.
I think everyone knows how to install and configure a multihomed server, so this writing will focus on adding an IP alias to a NIC in RHEL 5 Update 7, or at least it will focus on how I learned to do it via the command line. I’ll also show a second method to accomplish adding an IP alias through the GUI (X is enabled by default in RHEL 5.7).
Assuming RHEL 5 Update 7 is already installed with a NIC having an IP address 192.168.0.10, adding an additional IP address via an alias takes just a few steps via CLI.
- Use nano -w /etc/sysconfig/network-scripts/ifcfg-eth0 to edit the network configuration for eth0. If it exists, remove the line GATEWAY=192.168.0.1 or comment it out by placing a hash (#) character at the beginning of the line like so: # GATEWAY=192.168.0.1 Save and exit nano with CTRL+X.
- Make a copy of ifcfg-eth0 to use for the IP alias. Do this with the command cp /etc/sysconfig/network-scripts/ifcfg-eth0/etc/sysconfig/network-scripts/ifcfg-eth0:0
- Use nano -w /etc/sysconfig/network-scripts/ifcfg-eth0:0 to edit the network configuration for eth0:0. Change DEVICE=eth0 to read DEVICE=eth0:0. Change IPADDR=192.168.0.10 to read IPADDR=192.168.0.11 Change ONBOOT=yes to read ONPARENT=yes Save and exit nano with CTRL+X.
- Use nano -w /etc/sysconfig/network to add a commonly shared default gateway for eth0 and eth0:0. Add the line GATEWAY=192.168.0.1 Save and exit nano with CTRL+X.
- Restart networking with service network restart
At this point, the Linux platform has a single NIC with two IP addresses and the installation of vCloud Director on this cell can begin.
A second method to accomplish the above would be through the GUI by running the Networking application in RHEL 5 Update 7.
Seen here, eth0 is already configured. Click the New button to add an IP alias:
Select Ethernet connection, choose the existing NIC for eth0, assign the IP address, Subnet Mask, and Default Gateway for the alias, and then lastly click on the Activate button with eth0:1 highlighted.
Once again, at this point, the Linux platform has a single NIC with two IP addresses and the installation of vCloud Director on this cell can begin. Highlighted in yellow below is the IP alias or second IP address bound to eth0:
I’ve found that the GUI approach obsoletes steps 1 and 4 from the CLI approach above. Basically it strips out the steps where the Default Gateway configuration is moved from the individual ifcfg-eth0 network startup scripts to the centralized /etc/sysconfig/network location. It further affirms the GATEWAY= entry may remain in each of the individual ifcfg-eth0 network startup scripts. In the end, both methods work for a vCloud Director cell server however I imagine adding an additional NIC hard wired to an access port not on the 192.168.0.0 subnet will have issues with a GATEWAY=192.168.0.1 in /etc/sysconfig/network.