Valentin Hamburger

The Hitachi Enterprise Cloud - Multi tier application with NSX - Technical Part 2

Blog Post created by Valentin Hamburger on May 17, 2017

Allright, this is the technical part, describing how to built the blueprint and what to configure in NSX to make it work like described in the overview. Let's get started, shall we?

 

Getting started

First things first. I have to create a list of requirements in order to master all the challenges such a micro DMZ concept brings. Lets see what we need:

  • NSX installed and ready to be used
    • Integrated with HEC
    • Security groups for Web and DB
    • Virtual wire for DB
    • Edge configured and ready for external traffic
    • DLR (Distributed Logical Router) configured and ready (OSPF, etc...)
    • Security Tags for DB and WEB server
  • Hitachi Enterprise Cloud
    • Linux blueprint / image to use for WEB and DB server
    • Software components to install such as Apache, MySQL, PHP5, etc...
    • Network reservation for on-demand DMZ (routed-on-demand-network) and the DB network (static)

OK - that should be it. I will focus in this part on the NSX config in the blueprint and the designer. Assuming everything else is just fine and had been pre-configured installed by our fine consulting folks. Just like a customer, I am eager to use it - not to install it

Set up the NSX Tags and security policies

OK, I decided to start with the very important and yet super complex NSX integration...

Alright, you got me there, it is actually not that complex to integrate

 

First I created some NSX Security Tags. These can be used to identify VMs and run actions based on the found tags. Also it might be a smart way of dynamically add VMs to security groups in NSX. In order to use them in the HEC blueprint canvas, the Tags need to be pre-existant in NSX.

OK got it, but were do you create these Tags in the first place?

 

Well, this is done in the NSX management in vCenter. To create custom security tags, follow these steps:

  1. Got to the home screen in vCenter and click on Network and Security
  2. In the left hand side menu click on NSX Managers
  3. In the left hand side select your NSX Manager by clicking on it
  4. Click on the Manage tab
  5. Select the Security Tags button in the headline of the Manage tab
  6. 6. Click on the New Security Tag symbol on top left of the table to add a tag.

 

OK, I created the tags "HEC_DB" and "HEC_Web" and am ready for action. These tags are now useable on VMs for advanced processing.

Also, I created two security groups:

  • DbServer
  • WebServer

To create those, go to Networking and Security and click on Service Composer in the left hand side menu.
These security groups are later used to apply the firewall rules onto. The Tags will be used to assign the VMs to their respective security group (DB VM to DbServer, WEB VM to WebServer),  after the VM deployment.

 

Screen Shot 2017-04-04 at 15.55.20.png

This means you are now able to enforce firewall rules to VMs where you might not even know the IP address nor their subnet mask just by putting the VMs in NSX security groups.

Welcome, to the power of the Service Composer in NSX!

 

After the creation of Tags and Groups in NSX

After the security groups have been created we have to set up the rules of engagement, ahem I mean, the rules for communication between the WEB server and the DB server. Since the WEB server is exposed to the internet, we do not want to have him chatty chatting to the DB server as he whishes. Therefore the communication between these two servers (WEB to DB) has to be limited as much as possible in order to keep the security high! These sophisticated firewall rules are set in so called Security Policies.
We can create a new Security Policy by just clicking on the Security Policies tab and selecting the Create Security Policy icon.
Now you can specify rules for interaction between Security Groups on NSX or even from external sources (like the internet) to Security Groups.
In our case, we want the following rules to apply for a secure configuration:

  • WEB Server can access DB sever only to issue MySQL queries using specific MySQL ports
  • The Internet can access the Web Server only by HTTP or HTTPS
  • All other actions from DB to WEB server are blocked
  • All other actions from WEB to DB sever are blocked

Screen Shot 2017-04-04 at 16.07.15.png

 

Voilá: That should be it, now VMs in the DB security group will only allow VMs in the WEB security group access via the MySQL port. All other access is blocked. For the WEB servers, we are even stricter, from the perimeter firewall (aka: the internet), only HTTP and HTTPs will be let through to the WEB server. The only other server outside of the DMZ  the WEB server can reach is the DB server. The communication is only possible via the MySQL ports to initiate DB queries.

 

You might wonder how to enforce all of this without specifying a single subnet or IP address? Well that is solved by the Security Tags. As soon as the VMs are assigned to the right policies in the Service Composer, the rules will be enforced on them, automagically!

 

Create the blueprint

Assuming everything else is just fine and had been configured correctly, we can now start building the actual application. So lets get started with the design, given that I already have created some installable components, so called Application Blueprints, I can start drag and dropping my way to a versatile multi-tier web application.

 

Screen Shot 2017-04-04 at 15.12.59.png

 

I decided to have a DB sever and a WEB server (shocking - isn't it?). In the design canvas I dragged the DB components such as MySQL installation as well as the FST_Industries_DB component on the DB server.

To do this, simply drag and drop the packages onto the VMs. The FST_Industries_DB component is a customising the DB to set up a table space and does make some other minor edits to prepare the DB server for the use of the WEB Server.
After doing that, I dragged Apache, PHP and the FST_Industries_Web component onto the WEB server.

Besides installing all the software assets, the FST_Industries_Web is then creating an on-demand web site which is accessing the DB sever via its full qualified domain name (FQDN). HEC will now install these packages on the specified VMs, it is important to know that all this data is passed on as dynamic variables during the install (IP addresses, domain names, DB names, etc...) Otherwise it would be fairly complex to install anything on demand

 

After the actual service design is done, we need to ensure that the VMs are tagged to auto assign them into the respective security groups in NSX. Therefore you can drag the Tags directly into the canvas.

The Tags are shown in the picture right above each VM, a thin line represents their assignment to each of the VMs

Just drop it somewhere, for the sake of a clean graphic I put it on top of each of the VMs. By clicking on the dragged in security tag, the actual tag value can be assigned. You will see a list of possible NSX security tags, pick HEC_DB for one and WEB_DB for the other - done

 

If you just finished created the Security Tags in NSX, give HEC a moment to pick them up. If they are not showing up after 15 minutes, it might be necessary to re-run the network and security inventory data collection task. You can find it under "Infrastructure -> Compute Resources -> Mouse over vSphere resources -> Data Collection. The Network and Security inventory is the second last entry in the list. Select "Request Now" after creating the tags and wait for its completion. After this they will show up in the design canvas.

Now, the tags need to be formally assigned to each of the VMs. This is done by clicking on the VM in the canvas and selecting the Security tab. In there you will see both tags available, just tick the one which applies:

  • HEC_DB if you selected the DB Server
  • HEC_Web if you selected the WEB server
  • Done!

 

You might wonder why both tags are always displayed in this security settings for the VM. This is because a VM can have multiple security tags - all tags dragged in the canvas will be shown. In our case it is important to make sure to prevent a double select of a tag with a VM, this mite shake up our well thought through security concept (however, it is easy to spot and fix).

Last but not least both VMs need to be placed in a NSX network. For the DB VM, this network ("virtual wire" in NSX slang) needs to be set as an internal and protected network, since possibly other DB servers might run in there as well.

 

Defining the networks to use

For the WEB server, we want to create the DMZ on demand. That means this network is not pre-existent at the time of deployment.

To accomplish this, we need to define two different types of networks in HEC:

 

Do not get over excited by the term "External" in this case, that refers to all networks that are pre-existing before the time of deploying a service. The "Routed" network is different, this one is a pure logical construct which only comes to life at the time of deployment. This will be configured to form smaller networks to than place the newly created VMs into them.

Therefore its configuration might be a bit confusing in the first place. To configure the network profiles in HEC, go to Infrastructure -> Reservations -> Network Profiles and click on New to select either External or Routed.

The External one has to be pre-existing, which means it has to be defined in NSX before it can be added to HEC.

 

This means you have to create a new virtual wire in NSX prior to the selection in HEC.

The Routed one is more difficult, this is why I think it might be worth going over its options quickly. In the form you will see the following fields:

 

Provide a valid name: DMZ_OnDemand

Description: DMZ network, created on demand each time for every deployment

External Network profile: Transport*

Subnet mask: 255.255.192.0**

Range subnet mask: 255.255.255.240***

Base IP: 172.30.50.1

 

OK, here we are in the networking nirvana. What does all this mean. Just let me explain the "*" real quick:

*: The transport network for your DLR. This is configured during NSX setup for external network access. To describe how to do this would be to much detail for this blog post. In our case, it is named "Transport", but you can name it also Bob, Jon, or Fritzifratzi if that works better for your use case

 

 

**: This is the subnet mask, defining how much devices we want to put into the micro DMZs. In this case it is a /18 subnet mask, which gives us "only" 16,382 addresses. You could also go for a /16 which would give you 65,534 or a /14 for a whopping 262,142 addresses. But be careful, all these addresses are pre-calculated by HEC, which can be quite CPU intense if you chose big ranges.

 

***: The subnet mask for the different small network areas. Basically it creates the "micro" networks, based on the given subnet mask (255.255.255.192.0) and uses the /28 subnet mask (255.255.255.240) to create a net with 14 useable addresses.

This means HEC will now go ahead and create as many small subnets as possible using the provided big /18 (255.255.192.0) subnet mask. In my case it will create network chunks looking like this:

  • 172.30.50.1 - 172.30.50.14 (useable addresses)
  • 172.30.50.17 - 172.30.50.30
  • ...
  • 172.30.63.225 - 172.30.63.238
  • 172.30.63.241 - 172.30.63.254

 

Now you might wonder why there are small gaps between these address spaces. That is because only the useable 14 addresses are shown. For example, the first address is 172.30.50.1, the network address would be 172.30.50.0 and the broadcast address would be 172.30.50.15. So the entire network is actually 172.30.50.0 - 172.30.50.15. But given how networks work the network address and the broadcast address can't be used for servers, leaving a total of 14 addresses useable. It is important to understand that principle in order to make the networks chunks big enough for the amount of servers to be in them.

 

If all this network calculations, slicing and subletting is creating the father of all headaches don't give up! There are quite nice websites which do all the calculations mentioned here for you. One of these sites can be found here:

IP Calculator / IP Subnetting

 

What have we achieved so far

Good, after all this hard work of clicking and brain twisting network mask calculations the setup is finally done.

We configured security tags, automatically assigned them to the right VMs. Firewall rules will assure only allowed protocol communication from one security group to another.

The VMs and its software get installed by HEC, once the tags are assigned and the VMs are installed one is placed in a static and the other one is placed in a routed network. The routed network will be sliced by a subnet algorithm to only allow 14 devices, each WEB server will have its own DMZ.
After all that has been configured by HEC, the NSX security kicks in and our freshly deployed application will work like intended and only let MySQL queries reach the DB server. Also, HTTP / HTTPs queries from the internet can only reach our WEB server running in its very own "private" DMZ. All of this is created for each and every new application being deployed.

 

To Summarize

Wow, after all this clicking and configuring and calculating we do have a quite comprehensive blueprint, not only setting up a full service with a single mouse click, but also providing enterprise grade IT security for each and every deployment.

Not only through the firewall and security capabilities of NSX, but also through the flexible and purpose ready design of a micro DMZ per WEB server per service. This is an achievement which would be fairly difficult to reach without the capable technologies introduced by HEC.

 

If you want to see all this running, stay tuned for the next article in this series showing all of this working in our HEC Solution Centre environment which is located in the Netherlands in a wonderful small town called Zaltbommel...

Outcomes