Platform Architecture and Planning Overview

Page last updated:

This topic describes reference architectures and other plans for installing Ops Manager on any infrastructure to support the VMware Tanzu Application Service for VMs (TAS for VMs) and Tanzu Kubernetes Grid Integrated Edition (TKGI) runtime environments.

Overview

The reference architectures in this section describe a proven approach for deploying Ops Manager and runtimes, such as TAS for VMs or TKGI, on a specific IaaS, such as AWS, Azure, GCP, OpenStack, or vSphere. These reference architectures meet the following requirements:

  • Secure
  • Publicly accessible
  • Includes common Ops Manager-managed services such as VMware Tanzu SQL, VMware Tanzu RabbitMQ, and Spring Cloud Services for VMware Tanzu
  • Can host at least 100 app instances
  • Have been deployed and validated by VMware to support Ops Manager, TAS for VMs, and TKGI

You can use Ops Manager reference architectures to help plan the best configuration for your Ops Manager deployment on your IaaS.

Reference Architecture and Planning Topics

All Ops Manager reference architectures start with the base TAS for VMs architecture and base TKGI architecture.

These IaaS-specific topics build on these two common base architectures:

Control Plane Reference Architectures describes a broader architecture that automates the installation and updating of multiple Ops Manager foundations, or multiple instances of each architecture above.

These topics address aspects of platform architecture and planning that the Ops Manager reference architectures do not cover:

TAS for VMs Architecture

The diagram below illustrates a base architecture for TAS for VMs and how its network topology places and replicates TAS for VMs components across subnets and availability zones (AZs).

TAS for VMs Base Deployment Topology

View a larger version of this diagram

Internal Components

The table below describes the internal component placements shown in the diagram above:

Component Placement and Access Notes
Ops Manager VM Deployed on one of the three public subnets. Accessible by fully-qualified domain name (FQDN) or through an optional jumpbox.
BOSH Director Deployed on the infrastructure subnet.
Jumpbox Optional. Deployed on the infrastructure subnet for accessing TAS for VMs management components such as Ops Manager and the Cloud Foundry Command Line Interface (cf CLI).
Gorouters (HTTP routers in Ops Manager) Deployed on all three TAS for VMs subnets, one per AZ. Accessed through the HTTP, HTTPS, and SSL load balancers.
Diego Brain Deployed on all three TAS for VMs subnets, one per AZ. The Diego Brain component is required, but SSH container access support through the Diego Brain is optional, and enabled through the SSH load balancers.
TCP routers Optional. Deployed on all three TAS for VMs subnets, one per AZ, to support TCP routing.
Service tiles Service brokers and shared services instances are deployed to the Services subnet. Dedicated on-demand service instances are deployed to an on-demand services subnet.
Isolation segments Deployed on an isolation segment subnet. Includes Diego Cells and Gorouters for running and accessing apps hosted within isolation segments.

Networks

These sections describe TAS for VMs’s recommendations for defining your networks and load-balancing their incoming requests:

Required Subnets

TAS for VMs requires these statically-defined networks to host its main component systems:

  • Infrastructure subnet - /24 segment
    This subnet contains VMs that require access only for Platform Administrators, such as the Ops Manager VM, the BOSH Director VM, and an optional jumpbox.

  • TAS for VMs subnet - /24 segment
    This subnet contains TAS for VMs runtime VMs, such as Gorouters, Diego Cells, and Cloud Controllers.

  • Services subnet - /24 segment
    The services and on-demand services networks support Ops Manager tiles that you might add in addition to TAS for VMs. In other words, they are the networks for everything that is not TAS for VMs. Some services tiles can call for additional network capacity to grow into on-demand. If you use services with this capability, VMware recommends that you add an on-demand services network for each on-demand service.

  • On-demand services subnets - /24 segments
    This is for services that can allocate network capacity on-demand from BOSH for their worker VMs. VMware recommends allocating a dedicated subnet to each on-demand service. For example, you can configure the Redis for VMware Tanzu tile as follows:

    • Network: Enter the existing Services network, to host the service broker.
    • Services network: Deploy a new network OD-Services1, to host the Redis worker VMs.
      Another on-demand service tile can then also use Services for its broker and a new OD-Services2 network for its workers, and so on.
  • Isolation segment subnets - /24 segments
    You can add one or more isolation segment tiles to a TAS for VMs installation to compartmentalize hosting and routing resources. For each isolation segment you deploy, you should designate a /24 network for its range of address space.

Load Balancing

Any TAS for VMs installation needs a suitable load balancer to send incoming HTTP, HTTPS, SSH, and SSL traffic to its Gorouters and app containers. All installations approaching production-level use rely on external load balancing from hardware appliance vendors or other network-layer solutions.

The load balancer can also perform Layer 4 or Layer 7 load balancing functions. SSL can be terminated at the load balancer or used as a pass-through to the Gorouter.

Common deployments of load balancing in TAS for VMs are:

  • HTTP/HTTPS traffic to and from Gorouters
  • TCP traffic to and from TCP routers
  • Traffic from the Diego Brain, when developers access app containers through SSH

To load-balance across multiple TAS for VMs foundations, use an IaaS- or vendor-specific Global Traffic Manager or Global DNS load balancer.

For more information, see Global DNS Load Balancers for Multi-Foundation Environments.

High Availability

TAS for VMs is not considered high availability (HA) until it runs across at least two AZs. VMware recommends defining three AZs.

On an IaaS with its own HA capabilities, using the IaaS HA in conjunction with a TAS for VMs HA topology provides two benefits. Multiple AZs give TAS for VMs redundancy, so that losing an AZ is not catastrophic. The BOSH Resurrector can then replace lost VMs as needed to repair a foundation.

To back up and restore a foundation externally, use BOSH Backup and Restore (BBR). For more information, see the BOSH Backup and Restore documentation.

Storage

TAS for VMs requires disk storage for each component, for both persistent data and to allocate to ephemeral data. You size these disks in the Resource Config pane of the TAS for VMs tile. For more information about storage configuration and capacity planning, see the corresponding section in the reference architecture for your IaaS.

The platform also requires you to configure file storage for large shared objects. These blobstores can be external or internal. For details, see Configuring File Storage for TAS for VMs.

Security

For information about how TAS for VMs implements security, see:

Domain Names

TAS for VMs requires these domain names to be registered:

  • System domain, for TAS for VMs and other tiles: sys.domain.name
  • App domain, for your apps: app.domain.name

You must also define these wildcard domain names and include them when creating certificates that access TAS for VMs and its hosted apps:

  • *.SYSTEM-DOMAIN
  • *.APPS-DOMAIN
  • *.login.SYSTEM-DOMAIN
  • *.uaa.SYSTEM-DOMAIN

Component Scaling

For recommendations on scaling TAS for VMs for different deployment scenarios, see Scaling TAS for VMs .

Tanzu Kubernetes Grid Integrated Edition Architecture

The diagram below illustrates a base architecture for Tanzu Kubernetes Grid Integrated Edition (TKGI) and how its network topology places and replicates TKGI components across subnets and AZs:

TKGI Base Deployment Topology

View a larger version of this diagram

Internal Components

The table below describes the internal component placements shown in the diagram above:

Component Placement and Access Notes
Ops Manager VM Deployed on one of the subnets. Accessible by fully-qualified domain name (FQDN) or through an optional jumpbox.
BOSH Director Deployed on the infrastructure subnet.
Jumpbox Optional. Deployed on the infrastructure subnet for accessing TKGI management components such as Ops Manager and the kubectl command line interface.
TKGI API Deployed as a service broker VM on the TKGI services subnet. Handles TKGI API and service adapter requests, and manages TKGI clusters. For more information, see TKGI Architecture.
Harbor tile Optional container images registry, typically deployed to the services subnet.
TKGI Cluster Deployed to a dynamically-created, dedicated TKGI cluster subnet. Each cluster consists of worker nodes that run the workloads, or apps, and one or more master nodes.

Networks

These sections describe VMware’s recommendations for defining your networks and load-balancing their incoming requests.

Subnets Requirements

TKGI requires two defined networks to host the main elements that compose it:

  • Infrastructure subnet - /24
    This subnet contains VMs that require access only for Platform Administrators, such as the Ops Manager VM, the BOSH Director VM, and an optional jumpbox.

  • TKGI services subnet - /24
    This subnet hosts TKGI API VM and other optional service tiles such as VMware Harbor Registry.

  • TKGI cluster subnets - each one a /24 from a pool of pre-allocated IPs
    These subnets host TKGI clusters.

Load Balancing

Load balancers can be used to manage traffic across master nodes of a TKGI cluster or for deployed workloads. For more information on how to configure load balancers for TKGI, see the corresponding section in the reference architecture for your IaaS.

High Availability

TKGI has no inherent HA capabilities to design for. Make the best efforts to have HA design at the IaaS, storage, power, and access layers to support TKGI.

Storage

TKGI requires shared storage across all AZs for the deployed workloads to appropriately allocate their required storage.

Security

For information about how TKGI implements security, see Enterprise TKGI Security and Firewall Ports.

Domain Names

TKGI requires the *.pks.domain.name domain name to be registered when creating a wildcard certificate and TKGI tile configurations.

The wildcard certificate covers both the TKGI API domain, such as api.pks.domain.name, and the TKGI clusters domains, such as cluster.pks.domain.name.

Cluster Management

For information about managing TKGI clusters, see Managing Clusters.