Use these instructions to install the Isolation Segment tile, which allows you to isolate deployment workloads into dedicated resource pools called isolation segments.
Installing the tile installs a single isolation segment. However, you can install multiple isolation segments using the Replicator tool shown in Step 4.
After installing the tile, you must follow the procedure in Register an Isolation Segment in Managing Isolation Segments to create the isolation segment in the Cloud Controller database (CCDB). The topic also includes information about managing an isolation segment.
For more information about how isolation segments work, see Isolation Segments in TAS for VMs Security.
By default, the VMware Tanzu Application Service for VMs (TAS for VMs) Gorouter handles traffic for your isolation segment. However, you can deploy a dedicated Gorouter for your isolation segment instead. For information about configuring and managing routing for isolation segments, see Routing for Isolation Segments.
To deploy a dedicated Gorouter:
Add a load balancer in front of the TAS for VMs Gorouter. The steps to do this depend on your IaaS, but the setup of the load balancer must mirror the setup of the load balancer for the TAS for VMs Gorouter that you configured in the TAS for VMs tile.
Create a wildcard DNS entry for traffic routed to any app in the isolation segment. For example,
Attach the wildcard DNS entry to the load balancer you created.
To install the Isolation Segment tile:
Download the product file from the Isolation Segment page of VMware Tanzu Network.
Go to your Tanzu Operations Manager URL in a browser to log in to the Tanzu Operations Manager Installation Dashboard.
Click Import a Product and select the downloaded product file.
Under Isolation Segment in the left column, click the + icon.
Click the orange Isolation Segment tile to start the configuration process.
In the Assign AZ and Networks pane, you assign jobs to your Availability Zones (AZs) and networks.
To configure the Assign AZ and Networks pane:
Select Assign AZs and Networks.
Select an AZ for your singleton jobs, and one or more AZs to balance other jobs in.
Select a network. This network does not need to be the same network where you deployed TAS for VMs. For most deployments, operators can create unique networks in which to deploy the Isolation Segment tile. These networks can maintain network reach with the Diego components because the Diego Cells can reach the Diego Brain and Diego Database VMs.
In the Networking pane, you configure security and routing services for your IaaS.
To configure the Networking pane:
Note: Entering the static IP addresses is not necessary for deployments running on a public IaaS such as AWS, GCP, or Azure because users specify the IaaS load balancer in the Resource Config pane of the Isolation Segment tile.
Under Certificates and private keys for the Gorouter, you must provide at least one certificate and private key pair for the Gorouter. The Gorouter is configured to receive TLS communication by default. You can configure multiple certificates for the Gorouter.
Note: When providing custom certificates, enter them in this order:
CA. For more information, see the DigiCert documentation.
Note: If you configured your Tanzu Operations Manager front end without a certificate, you can use this new certificate to finish configuring Tanzu Operations Manager. To configure your Tanzu Operations Manager front end certificate, see the Ops Manager documentation.
Note: Ensure that you add any certificates that you generate in this pane to your infrastructure load balancer.
x-forwarded-client-cert(XFCC) HTTP headers based on where TLS is terminated for the first time in your deployment. The table below indicates which option to choose based on your deployment configuration:
|Deployment Configuration||TLS Option||Additional Notes|
||Infrastructure load balancer||The Gorouter forwards the XFCC header when included in the request.|
||Gorouter||The Gorouter strips the XFCC header if it is included in the request and forwards the client certificate received in the TLS handshake in a new XFCC header.
Breaking Change: If you select the The Gorouter does not request client certificates option in the Gorouter behavior for client certificate validation field, the XFCC header cannot be delivered to apps.
Requests to the platform fail upon upgrade if your load balancer is configured with client certificates and the Gorouter is not configured with the appropriate CA. To mitigate this issue, select The Gorouter does not request client certificates.
Important Specify cipher suites that are supported by the versions configured under Select the range of TLS versions supported by the Gorouter. For example, TLS v1.3 does not support configuring cipher suites. If you select TLSv1.3 only, you cannot configure cipher suites for the Gorouter.AWS Classic Load Balancers do not support the TAS for VMs default cipher suites. For more information about configuring your AWS load balancers and Gorouter, see TLS Cipher suite support by AWS load balancers in Securing traffic into TAS for VMs.
0or no value. The default value is
httpStartStopevent metrics emitted for each app request. If your deployment uses App Metrics, you can also find this information in your App Metrics deployment. For more information, see the App Metrics documentation.
900. To accommodate larger uploads over connections with high latency, increase the value.
JSESSIONID. Some apps require a different cookie name. For example, Spring WebFlux requires
SESSIONfor the cookie name. Gorouter uses these cookies to support session affinity, or sticky sessions. For more information, see Session Affinity in HTTP Routing.
In the App Containers pane, you enable microservice frameworks, private Docker registries, and other services that support your apps at the container level.
To configure the App Containers pane:
Select App Containers.
(Optional) To give apps that generally stay within their CPU entitlements priority access to extra CPU during CPU bursts, activate the Allow CPU burst optimization check box. This check box is activated by default. When this check box is activated, apps that generally stay within their CPU entitlements have higher-priority access to extra CPU than apps that generally exceed their CPU entitlements. When this check box is deactivated, all apps have equal access to extra CPU during CPU bursts. Whether you activate or deactivate this check box, all apps are always guaranteed the amount of CPU that is within their CPU entitlements.
Choose how the Gorouter verifies app identity to activate encryption and prevent misrouting under Gorouter app identity verification:
For more information, see Preventing Misrouting in HTTP Routing.
(Optional) You can configure TAS for VMs to run app instances in Docker containers by provided a comma-separated list of their IP address ranges in the Docker registry allow list field. For more information, see Using Docker Registries.
Select your preference for disk cleanup scheduling. If you choose Clean up disk space once usage fills disk, enter a value in MB for Reserved disk space for other jobs. This is the amount of space the garbage collection algorithm must keep free for other jobs. For more information about the configuration options and how to configure a reserved amount, see Configuring Diego Cell Disk Cleanup Scheduling.
The Allow containerd delegation check box governs whether or not Garden delegates containers create and destroy operations to the containerd tool. By default, this option is activated and Garden uses containerd. Deactivate this option by deselecting the check box. For more information about the containerd tool, see containerd.
Under NFSv3 volume services, select Allow or Do not allow. NFS volume services allow app developers to bind existing NFS volumes to their apps for shared file access. For more information, see Enabling Volume Services.
Note In a fresh installation, NFSv3 volume services are enabled by default. In an upgrade, NFSv3 volume services is set to the same setting as it was in the previous deployment.
(Optional) To configure LDAP for NFSv3 volume services:
cloud.example.comtypically uses the following LDAP user search base:
Important UAA can only parse one certificate entered into this field. If you enter multiple certificates, UAA only uses the first one you entered and ignores the rest. You only need to include one root certificate or self-signed certificate.
In the System Logging pane, you can configure system logging in TAS for VMs to forward log messages from TAS for VMs component VMs to an external service. VMware recommends forwarding logs to an external service for use in troubleshooting. If you do not fill these fields, platform logs are not forwarded but remain available on the component VMs and for download through Tanzu Operations Manager.
To configure the System Logging pane:
Select System Logging.
Select an option under Configure syslog for system components?. Do not use is selected by default. This setting only affects Diego Cell and Gorouter components within the isolation segment. This setting does not affect shared TAS for VMs system components.
To use syslog, select Use.
Enter the address of your external syslog aggregation service in the Syslog server address field. The address can be a hostname or IP address.
Enter a port number in the Syslog server port field.
Select a protocol from the Transport protocol menu. This is the protocol the system uses to transmit logs to syslog.
(Optional) To transmit logs over TLS, select the Enable TLS check box.
Enter a Permitted peer. This is the SHA1 fingerprint of the remote peer.
Paste the certificate for your TLS certificate authority (CA) in the TLS CA certificate field.
(Optional) Enable the Use TCP for file forwarding local transport check box to transmit logs over TCP. This prevents log truncation, but might cause performance issues.
(Optional) The Do not forward debug logs check box is activated by default. To forward
DEBUG syslog messages to an external service, deactivate the check box.
Important Some Isolation Segment components generate a high volume of
DEBUG syslog messages. Enabling the Do not forward debug logs check box prevents TAS for VMs components from forwarding the
DEBUG syslog messages to external services. However, Isolation Segment still writes the messages to the local disk.
(Optional) To specify a custom syslog rule, enter it in the Custom rsyslog configuration field in RainerScript syntax. For more information about customizing syslog rules, see Customizing Syslog Rules. For more information about RainerScript, see the RainerScript documentation.
The Advanced Features pane includes new capabilities that might have certain constraints. Although these features are fully supported, VMware recommends caution when using them in production environments.
If your apps do not use the full allocation of disk space and memory set in the Resource Config tab, you might want use this feature. These fields control the amount to overcommit disk and memory resources to each Diego Cell VM.
For example, you might want to use the overcommit if your apps use a small amount of disk and memory capacity compared to the amounts set in the Resource Config settings for Diego Cell.
Due to the risk of app failure and the deployment-specific nature of disk and memory use, VMware has no recommendation for how much, if any, memory or disk space to overcommit.
To use overcommit:
Select Advanced Features.
In the Diego Cell memory capacity field, enter in MB the total desired amount of Diego Cell memory. See the Diego Cell row in the Resource Config tab for the current Diego Cell memory capacity settings that this field overrides.
In the Diego Cell disk capacity field, enter in MB the total desired amount of Diego Cell disk capacity. See the Diego Cell row in the Resource Config tab for the current Diego Cell disk capacity settings that this field overrides.
Entries made to each of these two fields set the total amount of resources allocated, not the overage.
If your apps require a longer period of time to finish in-flight jobs and gracefully shut down, you can increase the graceful shutdown period. By default, this graceful shutdown period is set to 10 seconds.
When TAS for VMs requests a shutdown of an app, the processes in the container have a period of time to gracefully shut down before the processes are forcefully terminated. For more information, see Shutdown in App Container Lifecycle.
If you significantly increase the value of the graceful shutdown period, platform upgrades and updates might become slower. This is because each Diego Cell uses the graceful shutdown period when it is cleaning up evacuated app instances and waits for each app to gracefully shut down.
VMware recommends using isolation segments to separate apps that have different shutdown requirements to ensure Diego Cell update times are reliable.
To avoid unexpected behavior, you must ensure that App graceful shutdown period has the same value in all environments that have deployed apps.
To increase the app graceful shutdown period:
Select Advanced Features.
In the App graceful shutdown period field, enter the number of seconds that you want the platform to wait for an app instance to exit after it is signaled to gracefully shut down. The default and minimum value is
Configuring TAS for VMs to deploy SMB volume services allows developers to bind existing SMB shares to their apps for shared file access.
To configure TAS for VMs to deploy SMB volume services:
Select Advanced Features.
Select the Enable SMB volume services check box.
Set the SMB Broker Errand to On.
For more information about SMB volume services, see Enabling volume services.
In the Compute and Networking Isolation pane, you can activate or deactivate compute isolation and configure Gorouter sharding for isolation segments.
Compute isolation is when an app runs on compute resources, such as clusters, resource pools, and servers, that are isolated from other resources by a network partition or firewall.
Networking isolation, or Gorouter sharding, is when traffic to an app instance uses a dedicated route that is isolated from routes used by other app instances by a network partition or firewall rule.
In the Isolation Segment tile, you cannot deactivate compute isolation and enable networking isolation at the same time. This is because networking isolation configures the route by which traffic goes to the Isolation Segment tile. Both compute and networking isolation are enabled by default.
The table below describes the ways VMware recommends configuring the Compute and Networking Isolation pane and the Requests to isolation segments property in the Networking pane of the TAS for VMs tile:
|Use case||Compute isolation||Gorouter sharding mode||Requests to isolation segments||Other requirements||Scaling recommendations|
|Use compute isolation and network isolation||Enabled||Isolation segment only||Reject requests for all isolation segments||Isolation Segment has its own load balancer and uses a different domain from TAS for VMs||Apps in the isolation segment can have their own Diego Cells and Gorouters.|
|Use compute isolation and extra Isolation Segment Gorouters||Enabled||Isolation segment only||Accept requests for all isolation segments||Isolation Segment has its own load balancer and uses the same domain as TAS for VMs||Apps in the isolation segment can have their own Diego Cells and Gorouters.|
|Use compute isolation only||Enabled||No isolation segment||Accept requests for all isolation segments||Isolation Segment uses TAS for VMs load balancer and domain||Scale Isolation Segment Gorouters to 0.|
|Use network isolation in some cases||See other rows for guidance||See other rows for guidance||Accept requests for some isolation segments||See other rows for guidance||See other rows for guidance|
The use cases from the previous table are described here:
Use compute isolation and network isolation for all isolation segments: This is the most common case. For this use case, select Reject requests for all isolation segments for the Requests to isolation segments radio button in the Networking pane of the TAS for VMs tile. This configuration routes traffic between an isolation segment and a block of compute resources that is dedicated solely to that isolation segment. It also ensures that no traffic is routed through the TAS for VMs Gorouters.
Use compute isolation and extra Isolation Segment Gorouters: To configure traffic for your isolated apps to pass through the Gorouters for both Isolation Segment and TAS for VMs, activate compute isolation and networking isolation, and select Accept requests for all isolation segments for the Requests to isolation segments radio button in the Networking pane of the TAS for VMs tile. You can also use either the same apps domain you configured in the Domains pane of the TAS for VMs tile, or a different domain that you configure with the DNS for the load balancer for the Isolation Segment Gorouters. This configuration is useful if you want to configure isolated compute resources for your apps but do not have additional networking restrictions.
Use compute isolation only: To configure the TAS for VMs load balancer and apps domain route requests from your isolated apps, you can activate compute isolation, deactivate networking isolation, and select Accept requests for all isolation segments for Requests to isolation segments in the Networking pane of the TAS for VMs tile. This configuration enables you to move Diego Cells out of TAS for VMs and into isolation segments, so you can upgrade TAS for VMs first and your Isolation Segment tiles as time permits. This allows you to upgrade a large foundation in pieces, making it easier to upgrade within scheduled maintenance windows. This configuration is useful if your foundation has additional compute resource blocks, but no additional Gorouters for Isolation Segment configured in the Resource Config pane.
Use network isolation in some cases: For this use case, in Requests to isolation segments (Networking pane), select Accept requests for some isolation segments TAS for VMs tile. Then provide a comma-separated list of Isolation Segment names that Gorouters accept traffic to. See other cases for guidance on how to configure each Isolation Segment.
Caution: If you configure the Compute and Networking Isolation pane and Requests to isolation segments setting in the TAS for VMs tile in a manner other than the use cases described, the smoke tests fail. To deploy the tile anyway, you must deactivate the Smoke Test errand in the Errands pane of the TAS for VMs tile. VMware does not recommend deactivating smoke tests. To configure the Smoke Test errand, see Configure Errands.
To configure the Compute and Networking Isolation pane:
Select Compute and Networking Isolation.
Under Compute isolation, activate or deactivate compute isolation:
Note: If you deactivate compute isolation, you must set Gorouter sharding mode to No isolation segment. Otherwise, the Isolation Segment tile fails to schedule the apps in your isolation segment.
Under Networking isolation, activate or deactivate networking isolation by selecting a sharding mode. For more information, see Sharding Gorouters for Isolation Segments in Routing for Isolation Segments.
Isolation segment only: The Gorouters for the TAS for VMs tile acknowledge requests only for apps deployed within the Diego Cells of the tile. All other requests fail.
In the Smoke Tests pane, you specify the org and space where smoke tests are run. In the org and space that you specify, the Smoke Test errand pushes the app to a Operations Manager org. The app runs basic functionality tests against both the TAS for VMs and Isolation Segment tiles after an installation or update.
The Smoke Test errand verifies that your deployment can:
Push, scale, and delete apps
Create and delete orgs and spaces
The Smoke Test errand is on by default. You can turn off the Smoke Test errand in the Errands pane. For more information, see Configure Errands.
To configure the Smoke Tests pane:
Select Smoke Tests.
(Optional) In Domain, enter the name of the apps domain that Isolation Segment uses when pushing an app to run smoke tests.
If you have a shared apps domain, select A temporary space within the system org, which creates a temporary space within the system org for running smoke tests and deletes the space afterwards. Otherwise, select A specified org and space and complete these fields to configure where Isolation Segment pushes an app to run smoke tests:
Note: If you configure the Compute and Networking Isolation pane and the Requests to isolation segments property in the TAS for VMs tile in a manner other than the use cases described in Options for Configuring Compute and Networking Isolation, the smoke tests fail.
Errands are scripts that Tanzu Operations Manager runs automatically when it installs or uninstalls a product, such as a new version of TAS for VMs. There are two types of errands: post-deploy errands run after the product is installed, and pre-delete errands run before the product in uninstalled.
By default, Tanzu Operations Manager always runs all errands.
In the Errands pane, you can select On to always run an errand or Off to never run it.
For more information about how Tanzu Operations Manager manages errands, see Managing Errands in Tanzu Operations Manager.
In the Resource Config pane, you must associate load balancers with the VMs in your deployment to enable traffic.
To configure the Resource Config pane:
Select Resource Config.
If you are using a dedicated Gorouter for your isolation segment:
NoteThe configuration settings available in Resource Config vary depending on your IaaS.
After you configure the Isolation Segment tile:
Register the isolation segment in the CCDB by following the procedure in Register an Isolation Segment in Managing Isolation Segments.
If you run smoke tests as a post-deploy errand in the Isolation Segment tile, the smoke tests check if your isolation segment in registered in the Cloud Controller database (CCDB). If not, the smoke tests register it in the CCDB. This eliminates the need to manually register the isolation segment with the
cf create-isolation-segment command. For more information about running smoke tests, see Configure Smoke Tests.
Return to the Tanzu Operations Manager Installation Dashboard.
Click Review Pending Changes, then Apply Changes to deploy the tile.
After the tile finishes deploying, see Managing Isolation Segments for more information about managing an isolation segment.
To create multiple isolation segments, you can copy the Isolation Segment tile with the Replicator tool.
To create multiple isolation segments:
Download the Replicator tool from the Isolation Segment page of VMware Tanzu Network.
Go to the directory where you downloaded the Replicator tool.
Replicate the tile by running:
./replicator \ --name "TILE-NAME" \ --path /PATH/TO/ORIGINAL.pivotal \ --output /PATH/TO/COPY.pivotal
TILE-NAMEis a unique name you provide for the new Isolation Segment tile. The name must be ten characters or less and only contain alphanumeric characters, dashes, underscores, and spaces.
/PATH/TO/ORIGINAL.pivotalis the absolute path to the original Isolation Segment tile you downloaded from VMware Tanzu Network.
/PATH/TO/COPY.pivotalis the absolute path for the copy that the Replicator tool produces.
Follow the procedures in this topic using the new
.pivotal file, starting with Step 1.
For information about upgrading replicated Isolation Segment tiles, see Upgrading Replicated Tiles in Upgrading TAS for VMs and Other Operations Manager Products.