Welcome to Part 3 of the blog series on NSX Application Platform Automation Appliance (NAPP-AA). In this article, we will deploy a second NAPP instance for the additional compute workload domain using the NAPP automation appliance. If you were not following along, please check out the previous articles of the blog series below:
Part 1 : Topology and Appliance Deployment – https://vxplanet.com/2024/04/16/nsx-application-platform-automation-appliance-napp-aa-part-1-topology-and-appliance-deployment/
Part 2 : NAPP Instance Deployment –
https://vxplanet.com/2024/04/18/nsx-application-platform-automation-appliance-napp-aa-part-2-napp-instance-deployment/
Let’s get started:
Deploying multiple NAPP instances using the NAPP automation appliance
For additional NAPP instances, the NAPP automation appliance provisions a new TKGS guest cluster under a new supervisor namespace within the existing supervisor cluster on the management workload domain. Each NAPP instance is mapped to a dedicated TKGS cluster and multiple NAPP instances require multiple TKGS guest clusters. In the current version of the automation appliance (version 4.1.2), only two NAPP instances are supported. For the VCF use case, multiple NAPP instances corresponds to multiple compute workload domains.
The below sketch shows the mapping between NAPP instances to their NSX instances (in compute workload domains) and TKGS guest clusters (on the management workload domain).
Let’s start the deployment of our second NAPP instance. As I have run out of resources on the management cluster, I have scaled out the cluster to three additional ESXi hosts. Below is the current state of the management workload domain.
The management cluster VxDC01-C01-MGMT has workload management enabled. The supervisor name space “napp-ns-vxdc01-cwld01” and the TKGS cluster “napp-cluster-vxdc01-cwld01” is for the first NAPP instance which we deployed in Part 2. We now have a new NSX manager instance VxDC02-NSXMGR01 that corresponds to a new compute workload domain, and will configure a new NAPP instance for this NSX.
As previously, let’s login to the NAPP automation appliance UI and start the deployment workflow.
We need to jump to step 6 where we can add the new NAPP instance definition.
As previously, the NAPP instance name must be unique, and this will be used for supervisor namespaces and TKGS guest clusters. Instance name once set, cannot be changed.
The NSX manager details corresponds to the new compute workload domain. Like the first NAPP instance, let’s deploy the TKGS cluster with a minimum footprint of 3 control plane nodes and 3 worker nodes.
We will again create two DNS records for the NAPP HTTPS and messaging endpoints. The IP addresses for the DNS entries will be suggested by the workflow (taken from the VIP pool). The VIP for these endpoints will be created on the HAProxy load balancer.
- NAPP HTTPS endpoint : vxdc02-cwld01-napp.vxplanet.int
- NAPP Kafka messaging endpoint : vxdc02-cwld01-napp-stream.vxplanet.int
As stated earlier, two is the maximum number of NAPP instances currently supported by the NAPP automation appliance. Once the definition is created, we can proceed to pre-checks and make sure it succeeds.
As previously, the deployment phase happens in two stages:
- Stage 1 – Deploy a new TKGS guest cluster on the management workload domain
- Stage 2 – Enable NAPP for the new NSX instance in the compute workload domain
Stage 1 – Deploy a new TKGS guest cluster on the management workload domain
Clicking “Update and Redeploy” will start the deployment of a new TKGS guest cluster under a new supervisor namespace in the supervisor cluster.
Let’s connect to the management workload domain and verify that the TKGS cluster is deployed:
Stage 2 – Enable NAPP for the new NSX instance in the compute workload domain
Clicking “Update and Redeploy” will enable NAPP for the NSX instance in the compute workload domain on the newly deployed TKGS cluster.
This will take a while to complete, and once done let’s connect to the TKGS cluster and verify that the NAPP components are up and running. Please check back the previous article to see the different namespaces and NAPP components that are deployed on the TKGS guest cluster.
Finally, lets connect to the NSX instance on the compute workload domain and confirm that we don’t have any open alarms.
We could also perform NAPP diagnostics on the new NAPP instance to detect any issues with the NAPP deployment.
Let’s break for now and will meet shortly in Part 4 where we discuss about NAPP scale-out using the NAPP automation appliance.
Stay tuned!!!
I hope this article was informative. Thanks for reading.
Continue reading? Here are the other parts of this series:
Part 1 – Topology and Appliance Deployment :
https://vxplanet.com/2024/04/16/nsx-application-platform-automation-appliance-napp-aa-part-1-topology-and-appliance-deployment/
Part 2 – NAPP Instance Deployment :
https://vxplanet.com/2024/04/18/nsx-application-platform-automation-appliance-napp-aa-part-2-napp-instance-deployment/
Part 4 – NAPP Scale-Out :
https://vxplanet.com/2024/04/20/nsx-application-platform-automation-appliance-napp-aa-part-4-napp-scale-out/
