Getting Started With Oracle Cloud VMware Solution (OCVS) – Connecting To Oracle Cloud Infrastructure Services

In my recent ‘Getting started with Oracle Cloud VMware Solution (OVCS)’ post; Getting Started With Oracle Cloud VMware Solution (OCVS) – Networking Configuration we familiarized ourselves with the OCVS networking configuration, including NSX-T. Now that we have a better understanding of how the networking is configured within the environment, we can start to look at connecting our workloads running within our OCVS SDDC to other Oracle Cloud Infrastructure (OCI) Services.

Posts in this series:

• Deploying A Bastion Host
• Deploying The SDDC With HCX
• Deployment Overview
• Networking Configuration
• Connecting To Oracle Cloud Infrastructure Services
• Connecting To An On-Premises Environment
• Migrating Workloads Using VMware HCX

In this blog post were are going to deploy a Windows Server into our SDDC and connect it to an OCI File System that will be used to store files and folders for our users. This is a very simple example chosen to illustrate how easy it is to connect OVCS workloads to OCI services. This is a high-level diagram of what we are going to be configuring.

Deploying an OVCS Workload

The first thing we need to do is create our workload in our SDDC. The process of creating virtual machines within the OCVS SDDC is the same as it is in your on-premises environment, so I am not going to document the process here. I simply created a virtual machine, uploaded an ISO onto the vSAN datastore, and booted the virtual machine from the ISO to install Window Server.

The Windows Server virtual machine is connected to the ‘workload’ network. This is an NSX overlay network we created during the deployment of the SDDC using the 192.168.1.0/24 CIDR.

Create A Private Subnet

Next, we need to create a private subnet that will be used by the OCI File System service. In theory, we could connect it to the public subnet, however, keeping security in mind, I’d recommend using a private subnet for any workloads that do not require access from the outside world.

1. Login to the OCVS console
2. Select the correct Region. (This should be the same region that the SDDC and the Bastion host were deployed)
3. Click on the burger icon at the top left of the screen to display the menu
4. Select Networking > Virtual Cloud Networks
   • Click your VCN (tshirts-vcn)
   • Click Create Subnet

1. • Name the new subnet (I called mine tshirts-private-subnet)
   • Select Regional (Recommended) for the Subnet Type
   • Enter a CIDR Block to be used for the new subnet (I used 10.100.8.0/24 as this was the next available subnet in my 10.100.0.0/16)
   • Select Private Subnet for the Subnet Access
   • Click Create Subnet

We now have three Subnets. Our Public subnet which is where our Bastion host lives, our newly created private subnet, and our SDDC subnet which is automatically created during the SDDC deployment. The SDDC subnet is where the ESXi Host Management vNICs (vmk0) live.

Create A Route Table

Next, our private subnet needs a Route table so the subnet knows how to get to the Windows Server on the workload (overlay) network.

The Windows Server is on a network that is not part of our VCN, as such, we need to create a route so that traffic that needs to go from the private subnet (10.100.8.0/24) to the Windows Server (192.168.1.3) knows that to get to the server, it needs to send the traffic to the NSX Edge vIP. Once the traffic reaches the NSX Tier-0 router via the Edge vIP, it is routed to the Windows server through the Tier-1 router.

If you wanted to, you could use an existing Route Table (I.e Default Route Table for <vcn name>) for this, however, I prefer to be more granular and give this subnet its own unique Route Table.

During the creating of the Route Table Rules, we are going to need a couple of pieces of information. First, we need the workload (overlay) network CIDR block (I used 192.168.1.0/24). Second, we need the NSX Edge virtual IP Address. The quickest way to find the Edge vIP is the following:

1. Click on the burger icon at the top left of the screen to display the menu
2. Select Networking > Virtual Cloud Networks
   • Click your VCN (tshirts-vcn)
   • Select VLANs
   • Select VLAN-<SDDC name>-NSX Edge Uplink 1
   • Make a note of the Private IP Address of the nsx-edge-up1-vip

Now we have all of the information we need to create our Route Table and Rules.

3. Click on the burger icon at the top left of the screen to display the menu
4. Select Networking > Virtual Cloud Networks
   • Click your VCN (tshirts-vcn)
   • Click Route Tables
   • Click Create Route Table
     • Name the Route Table (I used ‘Route Table for tshirt-private-subnet’)
     • Click Create Route Table

The Route Table will be created and is ready for editing.

5. Click on your newly created Route Table
   • Click Add Route Rules
   • Select Private IP as the Target Type
   • Enter the CIDR Block for the workload (overlay) network
   • Enter the NSX Edge vIP Address in Target Selection
   • Click Add Route Rules

Your Route Rule should look something like this, except of course with your own NSX Edge vIP address and workload network CIDR Block. This rule directs any traffic that wants to go to your workload network to the NSX Edge vIP address.

Next, we need to assign the Route Table to our private subnet.

6. Click on the burger icon at the top left of the screen to display the menu
7. Select Networking > Virtual Cloud Networks
   • Click your VCN (tshirts-vcn)
   • Click your private subnet
   • Click Edit (It’s at the top, underneath the private subnet name)
     • Select your newly created Route Table in the Route Table Compartment dropdown
     • Click Save Changes

Create A Network Security Group

Next, we need to create a Network Security Group (NSG) which we will apply to our File System Mount Target. The NSG will allow traffic we specify to flow from the NSX Edge Uplink 1 VLAN to the File System we will create shortly. Security Lists can also be used to allow traffic to flow.

Why use Network Security Groups instead of Security Lists?

Security lists are associated with subnets. If you use security lists to set up your security rules, those rules will apply to all VNICs in the subnet. Unlike security list rules, NSGs apply only to resource VNICs you add to the NSG. So the NSG’s allow more granularity by applying the rules directly at the VNIC level.

1. Click on the burger icon at the top left of the screen to display the menu
2. Select Networking > Virtual Cloud Networks
   • Click your VCN (tshirts-vcn)
   • Select Network Security Groups
   • Click Create Network Security Groups
     • Name the NSG (I used ‘NSG for File System (NFS)’)
     • Click Next

I needed to add the following Security Rules for File Storage to enable NFS communication. If you are using a different OCI service, your ports will differ.

NOTE: The Source CIDR I specified is the CIDR for my workload (overlay) network. Your workload CIDR Block maybe different.

Direction	Source or Destination	Protocol	Ports
Ingress	Source Type: CIDR Source: 192.168.1.0/24	TCP	Source Port Range: ALL Destination Port Range: 111,2048-2050
Ingress	Source Type: CIDR Source: 192.168.1.0/24	UDP	Source Port Range: ALL Destination Port Range: 111,2048

 

• Click Create

 

Create A File System 

Next, we need to create a File System that will be mounted into our Windows Server virtual machine and used to store users’ files and folders.

1. Click on the burger icon at the top left of the screen to display the menu
2. Select File Storage > File Systems
   • Click Create File System

• • • Click Edit Details in the File System Information section
    • Name your File System (I used: tshirts-userdata)
    • Click Edit Details in the Mount Target Information section
    • Select Create New Mount
    • Name the New Mount Target (I used: userdata)
    • Select your private Subnet in the Subnet dropdown
    • Check Use network security groups to control traffic
    • Select the Network Security Group you created earlier
    • Click Create

 

Mount the File System

With our new File System created and our Network Security Group applied to our Target Mount, we can now mount our File System on our Windows Server virtual machine. As this is a Windows task, I am not going to document the steps in this post. You can follow the steps posted here.

There are two pieces of information you will need to mount your File System; your Mount Target IP Address and Export Path.

1. Click on the burger icon at the top left of the screen to display the menu
2. Select File Storage > File Systems
   • Click your File System Name
   • Click your Mount Target (Mine is called: userdata)
     • Note the IP Address (yours might be different from mine)
     • Note the Export Path (yours might be different from mine)

With this information, you can mount your File System into your Windows Server.

Summary

Even though this a fairly simple example, I think it nicely illustrates the simplicity of how OCVS workloads can interact with native Oracle Cloud services.

Referring back to our high-level diagram, we can see all of the components we have deployed for our Windows server within our SDDC to communicate with our File System within OCI. We can now follow the traffic flow between the servers which might help make things a little clearer.

From bottom to top; The traffic from the Windows server flows through our Tier-1 router, and out through the Tier-0 router as the File System lives outside of the SDDC. The traffic exits the NSX-T Edges onto the Uplink 1 VLAN and out via the VLAN default gateway. The traffics arrives into the private subnet and is then checked against our Network Security Group before reaching the Mount Target of our File System.

Hybrid Connectivity

In the next post in this ‘Getting Started with Oracle Cloud VMware Solution (OCVS)’ series, we’ll be looking at external connectivity. Connecting our on-premises vSphere environment to our OCVS SDDC and workloads.