OpenStack on Amazon Web Servers

Deploying OpenStack on Amazon Web Servers

 

OpenStack is a free, open-source cloud computing platform. OpenStack is a cloud Operating System used to control the deep pools of computing, networking, and storage resources within a data center. OpenStack is primarily used and implemented as an Infrastructure as a Service (IaaS) for cloud computing. OpenStack is an open-source platform that offers many options to deploy and install it through different software distributions. OpenStack provides various deployment models for their customers. OpenStack also provides pre-installed ISO images of its platform for its customers.

 

Deploy OpenStack on AWS 1

 

 

This tutorial will discuss the steps to install OpenStack on top of AWS Elastic Compute Cloud (AWS EC2). Installing OpenStack on a nested hypervisor environment is not a big deal when using the QEMU (short for Quick EMUlator) emulator to launch virtual machines inside a virtual machine. However, unlike a common nested hypervisor setup, Installing OpenStack on AWS EC2 instances has a few limitations on the networking part for the OpenStack setup to work correctly. This tutorial outlines those limitations and solutions to run OpenStack on top of an AWS EC2 virtual machine.

 

 

Limitations 

The Amazon Web Service environment will allow packets to flow in their network only when the MAC address is registered/known in the AWS network environment. Also, the IP address and the Media Access Control Address (MAC) address are tightly mapped, so the Amazon Web Service environment will not allow packet flow if the MAC address registered for the provided IP address is different.

Suppose the users wonder whether the above restrictions will impact the OpenStack setup on AWS Elastic Compute Cloud. Then, the answer is yes. Yes, it will!

While configuring the networking component (Neutron), users should create a virtual bridge (say, br-example ) for the provider network where all the Virtual Machines traffic will reach the Internet via the external bridge, followed by the actual physical network interface controller (NIC), such as eth1. In such scenarios, users should configure the external interface (NIC) with a particular type of configuration, as follows:

Users should configure the second interface as the provider interface. This provider interface uses a unique configuration without an IP address assigned to it.

Edit and add the following lines in the /etc/network/interfaces file. In the below content, replace INTERFACE_NAME with the actual interface name. For example, ens224 or eth1.

 

# The provider network interface
auto INTERFACE_NAME
iface INTERFACE_NAME inet manual
up ip link set dev $IFACE up
down ip link set dev $IFACE down

 

Due to this particular type of interface configuration, the restriction in AWS will hit OpenStack’s networking. In a mainstream OpenStack setup, the above-mentioned provider interface would be configured with a particular NIC configuration with no IP for that interface. It would allow all packets via that specially configured network interface controller (NIC).

Moreover, the virtual machine packets reaching the Internet via this specially configured NIC would have the IP of the OpenStack tenant router’s gateway IP address as the source IP address in each package. Also, the IP address must match the Media Access Control Address (MAC) address. As mentioned in the limitations above, Amazon Web Service will only allow the packet flow when the MAC address is registered/known in their environment.

In this tutorial, the packet from the above-mentioned OpenStack tenant router will have the IP address of the router’s gateway in every single packet, and the packet source MAC address will be the MAC address of the router’s interface.

 

>> Note: Users could view these details using “ip netns show” followed by the “ip netns exec qr- ifconfig” command in the OpenStack controller’s terminal.

 

Since the MAC address is not/unknown registered in the AWS environment, the packets will be dropped when it reaches the Amazon Web Service switch. To allow the virtual machine packets to get the Internet via AWS switch, we need to do some hacks/tricks in the OpenStack setup.

 

Making use of what we have: 

The possible ways are:

  • The first method is to register the router’s MAC address and its IP address with the AWS environment. However, this option is not feasible. Amazon Web Service currently does not have the features available to register any random IP address and MAC address inside the Virtual Private Cloud (VPC). Moreover, allowing this type of functionality would be a severe security threat to the environment.
  •  Another method is to make use of what we have. Since we have used a particular type of interface configuration for the provider NIC, users could note that the IP address assigned to the provider network interface controller (NIC), such as eth1, is left unused. We could use this unused/available IP address for the OpenStack router’s gateway.

 

To use the above mentioned alternative method, execute the below command:

 

neutron router-gateway-set router provider --fixed-ip ip_address=<Registered_IP_address*>

 

MAC Address and IP Address Mismatch 

After configuring the router gateway with the AWS-registered IP address, each packet from the router’s gateway will have the AWS-registered IP address as the source IP address. But with the OVS-generated, users should unregister the MAC address.

As mentioned in the AWS limitation session above, the IP address must match the MAC address registered; else, all the packets with mismatched IP and MAC addresses will be dropped by the AWS switch.

To make the registered MAC address match the IP address, users need to change the MAC address of the router’s interface. To change the MAC address of the router’s interface, follow the below steps:

 

  • First, install macchanger.
  • Ensure to note down the original or actual MAC address of the provider NIC, such as eth1.
  • After that, change the MAC address of the provider NIC (eth1).
  • Next, change the MAC address of the router’s gateway interface to the original MAC address of the provider NIC (eth1).
  • Finally, ping 8.8.8.8 from the router namespace.

 

If the user gets a successful ping response, then we are done with OpenStack on AWS setup.

 

Key Points 

  • First, change the MAC address of the router’s gateway interface to the original MAC address of the provider NIC (eth1).
  • Disable floating IP address
  • Execute the following NAT command to access the OpenStack VM using the AWS EC2 instance’s Elastic IP:

 

$ ip netns exec qrouter-f85bxxxx-61b2-xxxx-xxxx-xxxxba0xxxx iptables -t nat -A PREROUTING -p tcp -d 172.16.20.101 --dport 522 -j DNAT --to-destination 192.168.20.5:22

 

>> Note: By executing the above command, all the packets reaching 172.16.20.101 with Port number 522 will get forwarded to 192.168.20.5:22.

 

  • Elastic IP address: Users required at least two NICs for the AWS EC2 instance for customized OpenStack installation. One for accessing the virtual machine terminal for the installation and the dashboard. In short, it acts as an API network, VM tunnel network, and Management network. The second NIC is for an external network with a unique interface configuration and mapped with the provider network bridge, such as br-example with eth1. Amazon Web Service will not allow any packets to travel out of the Virtual Private Cloud unless the Elastic IP is attached with the IP address of the packet. To overcome the above problem, users must attach the Elastic IP for this NIC. 

 

Conclusion 

This tutorial presents the steps to deploy OpenStack on AWS. Hope this tutorial was helpful, and do reach out to us if you have any query or suggestions.

Comments

Post a Comment

Popular posts from this blog

Different Types of Reports in Scrum - Agile

Image
  Introduction to Agile Reporting I’m not going to elaborate on the Agile Framework itself here.  1. Sprint Burndown At a Sprint-level, the burndown presents the  easiest way to track and report status  (the proverbial  Red / Amber / Green ), i.e., whether your Sprint is on or off-track, and what are the chances of meeting the Sprint goals. The burndown chart – when used right – can provide  near-real time updates  on Sprint progress. “If your team do it right, then they would take in just the right amount of work into a sprint.” At the beginning of a Sprint, the Scrum team perform Sprint Planning and agree to take on development work worth a certain number of Story points. This forms the basis for the Sprint Burndown chart. The total story points agreed at the beginning of the sprint make up the y-axis, and the individual dates in the Sprint make up x-axis. If your team do it right, then they would take in just the right amount of work into ...
Read more

Terraform

Image
  Terraform is an infrastructure as code tool that lets you build, change, and version cloud and on-prem resources safely and efficiently. HashiCorp Terraform is an infrastructure as code tool that lets you define both cloud and on-prem resources in human-readable configuration files that you can version, reuse, and share. You can then use a consistent workflow to provision and manage all of your infrastructure throughout its lifecycle. Terraform can manage low-level components like compute, storage, and networking resources, as well as high-level components like DNS entries and SaaS features. How does Terraform work? Terraform creates and manages resources on cloud platforms and other services through their application programming interfaces (APIs). Providers enable Terraform to work with virtually any platform or service with an accessible API. HashiCorp and the Terraform community have already written  thousands of providers  to manage many different types of resources...
Read more

Scrum Master Interview help - Bootcamp

Understanding the MoSCoW prioritization | How to implement it into your project Projects, irrespective of their size or complexity, often juggle numerous tasks and requirements. In such a scenario,  MoSCoW prioritization  becomes essential to ensure the successful completion of the project.  Besides, it is also a very effective way to manage project priorities. With a straightforward and adaptable approach, the MoSCoW method helps manage stakeholder expectations and improve project outcomes. What is the MoSCoW prioritization technique?  The MoSCoW method is a prioritization matrix widely used in project management and software development. The term MoSCoW is an acronym that stands for  Must have ,  Should have ,  Could have , and  Won’t have , each denoting a level of priority. Here is the breakdown of the MoSCoW method:  Must have:  These are critical requirements that the project cannot be completed withou...
Read more