Deployment topology with Isolation Segments and Windows Runtime (WRT)

Products

• VMware Tanzu Application Service for VMs

Issue/Introduction

This knowledge base article covers the deployment topology that could be used to install Windows Runtime Tiles in different isolation segment networks. 

 

Environment

Cause

The use case is to deploy Windows Runtime tile/s in the DMZ network/s, and have a different set of routers to handle the traffic to the applications running on those windows Diego cells. Since WRT does not come with routers, we deploy WRT along with Isolation Segment tile, so there are dedicates routers to cater the applications deployed on those specific WRT Diego cells.

Why not use the default routers that come with PAS, for handling external application traffic?

• Security concerns, where the Internal routers will make outbound calls from Non-DMZ network to the applications running in the Diego Cells deployed in the DMZ network
• Have dedicated routers for external and internal applications provides better application scalability
• WRT tile does not come with routers. It has only Diego cells. 

 

Resolution

The following diagram illustrates a deployment where there are 5 networks:

• Infrastructure Network
• Deployment Network
• Services Network
• Dynamic Services Network
• Isolation Segment Network 1
• Isolation Segment Network 2

In this deployment, there are dedicated VIP’s to handle traffic for

• *.cfapps.ext1.env.company.com

• *.cfapps.ext2.env.company.com

• *.cfapps.int.env.company.com and *.sys.int.env.company.com  

1. Using the replicator CLI, clone the Isolation Segment tile to create 2 copies, call it IS1 and IS2. Next using the replicator CLI, clone the Windows Runtime Tile to create 2 copies, call it WRT1 and WRT2.
2. While installing the isolation segments, ensure you:
   1. Pin down the router IPs
   2. Specify the placement tag name
   3. Select Isolation Segments Only option from Isolation Segment tile, go to  Networking and to the Isolation Segments Only option. This option will enable the routers to handle the application traffic for only those apps, that are deployed on the Diego cells, that are tagged with the same name
3. Use the same placement tag name for the WRT tile. Ex: Use the same placement tag name (ext-is1) for IS1 and WRT1, and use the same placement tag name (ext-is2) for IS2 and WRT2.
4. Create Load Balancer VIPs to load balance traffic to list of the routers deployed with isolation segment tile. Ex: Create one VIP that round robins traffic to the static IP’s assigned to the routers deployed with IS1. Similarly, create another VIP that round robins traffic to the static IP’s assigned to the routers deployed with IS2.
5. Create A records in the DNS, and register the wildcard domains specific for each VIP. If you need SSL to be terminated at the routers, then import the wildcard certificates on the tile
6. Ensure the firewalls are opened between the DMZ and Non-DMZ networks. https://docs.pivotal.io/pivotalcf/2-1/adminguide/routing-is.html#config-firewall
7. Deploy.

Once the deployment is complete, the spaces need to be mapped to the isolation segments. To do this, using the CF CLI, define the isolation segments. Only administrators can perform the following operation.

cf create-isolation-segment ext-is1

cf create-isolation-segment ext-is2

Once the segments have been defined, they need to be mapped to the Orgs. To do this execute:

cf enable-org-isolation <ORG-NAME> ext-is1

cf enable-org-isolation <ORG-NAME> ext-is2

Next, bind the space to the isolation segment.

cf set-space-isolation-segment <SPACE-NAME> ext-is1

cf set-space-isolation-segment <SPACE-NAME> ext-is2

Next, define the new shared/private domains

cf create-shared-domain cfapps.ext1.env.company.com

cf create-shared-domain cfapps.ext2.env.company.com

At this point, the application developers can push their applications into their respective spaces. They should also specify the external domain for their application.

cf push <App-Name> -d <Shared/private domain> …..