You can establish and use various deployment topologies based on how you configure your NSX-T network and security and your load balancer components in the vRealize Automation blueprint.

Networking and Security

  • Routed networks

    If you attach an NSX-T routed network component to a vSphere machine component in the blueprint, the following topology is provisioned in NSX-T:

    • A Tier-1 router is created.

    • A logical switch is created.

    • The Tier-1 router is down-linked to the logical switch.

    • Specific routed routes are advertised on the Tier 1 router.

  • NAT networks (static IP)

    If you attach an NSX-T NAT network to a vSphere machine component in the blueprint, the following topology is provisioned in NSX-T:

    • A Tier-1 router is created.

    • A logical switch is created.

    • The Tier-1 router is connected to the edge cluster.

    • The Tier-1 router is up-linked to a Tier-0 router; the Tier-0 router is selected from the reservation.

    • The Tier-1 router is down-linked to the logical switch.

    • All NAT routes are advertised on the Tier 1 router.

    • One external IP is allocated for each NAT network from the external network profile that supports the on-demand NAT network profile. This IP is used for SNAT and DNAT rules.

  • NAT networks (DHCP)

    If you attach an NSX-T NAT network with DHCP to a vSphere machine component in the blueprint, the following topology is provisioned in NSX-T:

    • A Tier-1 router is created.

    • A logical switch is created.

    • The Tier-1 router is connected to the edge cluster.

    • The Tier-1 router is up-linked to a Tier-0 router; the Tier-0 router is selected from the reservation.

    • The Tier-1 router is down-linked to the logical switch.

    • A DHCP server with an IP pool is provisioned.

    • All NAT routes are advertised on the Tier 1 router.

  • App Isolation

    If app isolation is required for a blueprint with NSX-T components, the following topology is provisioned in NSX-T:

    Note:

    You configure app isolation for the blueprint on the Blueprint Properties page when you create or edit the blueprint.

    • An NS Group is created.

    • A firewall section, with firewall isolation rules, is created.

    • The machines in the blueprint are added to the app isolation NS Group by using tags.

    • The load balancer VIP and external IP for NAT networks at the IPset are added to the app isolation NS Group.

    To support app isolation NS Groups, you must connect the machines to opaque networks.

  • Existing NS Groups

    If you attach an existing NS Group component to a vSphere machine component in the blueprint, the following topology is provisioned in NSX-T:

    • The machines that are attached to the NS Group are added to the NS Group in NSX-T using tags as a membership criteria

    To support existing NS Groups, you must connect the machines to opaque networks.

Load Balancers

The following topologies are supported for load balancers in an NSX-T blueprint deployment:

  • One-arm on a NAT on-demand network.

  • One-arm on a routed on-demand network.

  • One-arm on external (existing) network.

  • Two-arm, one on NAT and one on external.

  • Two-arm, one on routed and one on external.

If an NSX-T load balancer is added to the blueprint, the following topology - in addition to the network topologies, is provisioned in the deployment:

  • For all topologies except where the load balancer is one-armed on an external network:

    • A single load balancer service is created, even if there are multiple load balancer components in the blueprint.

    • The load balancer service is attached to the Tier-1 router, for the deployment. The Tier-1 router is created on-demand.

  • For topologies where the load balancer is one-armed on an external network:

    • The external network that is specified in the reservation must be a VC-opaque network (NSX-T logical switch).

    • The Tier-1 router must exist and be attached to the external network (NSX-T logical switch).

    • If the Tier 1 router does not already exist, the load balancer server is created on-demand and attached to the Tier-1 router; otherwise, an already existing load balancer is used.

  • The VIP route is advertised, unless the VIP is on a private NAT network.

  • One or more virtual servers are created on the load balancer service.

    There are limitations on the number of virtual servers per load balancer service based on the size of the load balancer.

  • A virtual server application profile is created for each virtual server.

  • A virtual server persistence profile is created for each virtual server that has configured persistence options.

  • A membership pool is configured that contains the static IP of each machine in the membership pool.

  • A single load balancer service is created regardless of the number of load balancer components in the blueprint.

  • A health monitor is created and configured for each member pool.

For virtual servers with HTTPS support, and unlike load balancers in NSX for vSphere, there's no support for SSL passthrough in NSX-T load balancers. vRealize Automation configures the load balancer virtual server to terminate SSL at the load balancer and to use plain HTTP from the load balancer to the pool members. The certificate name and SSL client profile name, bot of which must exist in NSX-T, must be specified when configuring virtual server with HTTPS. You can import certificates into the NSX-T trust manager.

When more than one NSX-T component is present on the blueprint, the Tier-1 logical router is shared among all the components and is configured accordingly. The external Tier 1 logical router ID is displayed in the Details view for each component on the vRealize Automation Deployments page.