Note: These procedures are intended for the VMware by Broadcom ESXi and Nutanix hypervisors.
This preparation phase ensures that all virtual machines, networking, certificates, and infrastructure prerequisites are prepared before you start a deployment of Omnissa Access.
In this deployment model, platform and application services are deployed across dedicated virtual machines and orchestrated through the Control Plane framework. All required virtual machines and supporting infrastructure must be provisioned and validated before beginning the deployment workflow.
NFS storage is required if you plan to configure a disaster recovery (DR) site for your deployment. See Configure Disaster Recovery for Omnissa Access for prerequisites.
Deployment Topology Requirements
The deployment model uses dedicated virtual machines for bootstrap, infrastructure/platform services, and Omnissa Access services.
A standard production deployment consists of the following nodes:
| Node Type | Quantity |
|---|---|
| Bootstrap Node Initializes and orchestrates the Control Plane deployment. | 1 |
| Omnissa Access Nodes Hosts Omnissa Access application services behind the load balancer. | 2 for extra small, small and medium3 for large |
| Infrastructure/Platform Nodes Hosts platform and shared infrastructure services. | 3 |
Important:
- All virtual machines must be deployed and accessible before starting the installation workflow.
- Static IP addresses, DNS records, and hostnames must be configured for all nodes.
- The
configuserpassword must be configured consistently across all nodes. - Default password expiry of
configuseris 60 days, from the date of the deployment. You must reset the same password across all cluster nodes. - After Control Plane bootstrap and cluster initialization are completed, changing node roles or deployment topology is not supported.
- All nodes must be able to communicate with each other over the required network ports.
- A load balancer must be configured in front of the Omnissa Access Nodes before deployment.
Hardware Sizing Requirements
The following sizing applies to Control Plane-based deployments of Omnissa Access only.
Choose a deployment size based on the number of users, groups, and applications in your environment.
The following table shows the minimum hardware configuration required for each deployment size.
Minimum Hardware Configuration by Deployment Size:
| Deployment Size | Bootstrap Node | Omnissa Access Nodes | Infrastructure/ Platform Nodes¹ |
|---|---|---|---|
| Extra Small 100,000 users 1,000 groups 50 applications | 1 node 8 vCPUs 32 GB RAM 200 GB disk | 2 load-balanced nodes 16 vCPUs 32 GB RAM 200 GB disk each | 3 nodes 16 vCPUs 32 GB RAM 200 GB disk each |
| Small 300,000 users 3,000 groups 50 applications | 1 node 8 vCPUs 32 GB RAM 200 GB disk | 2 load-balanced nodes 24 vCPUs 48 GB RAM 200 GB disk each | 3 nodes 16 vCPUs 48 GB RAM 200 GB disk each |
| Medium 1,000,000 users 10,000 groups 150 applications | 1 node 8 vCPUs 32 GB RAM 200 GB disk | 2 load-balanced nodes 48 vCPUs 64 GB RAM 200 GB disk each | 3 nodes 24 vCPUs 96 GB RAM 300 GB disk each |
| Large 1,000,000 users 20,000 groups 500 applications | 1 node 8 vCPUs 32 GB RAM 200 GB disk | 3 load-balanced nodes 64 vCPU 96 GB RAM 200 GB disk each | 3 nodes 24 vCPUs 96 GB RAM 400 GB disk each |
¹ Infrastructure/Platform Nodes host internal platform services including database, messaging, caching, and search (PostgreSQL, Redis, Kafka, and OpenSearch).
*The Bootstrap Node requires exactly 8 vCPUs, regardless of deployment size.
Important:
- Resource sizing may vary depending on authentication load, enabled services, and integration requirements.
- Additional storage allocation may be required based on logging, audit retention, and operational requirements.
Infrastructure Setup Guidelines for High Availability
To ensure the system stays up and running even if something goes wrong, follow these rules when creating virtual machines (VMs) for Infrastructure and platform.
Run nodes on different physical machines (hypervisor hosts). For example, if you need three Infrastructure/Platform nodes and two Omnissa Access nodes, place them as such:
- Bootstrap Node → Physical Host 1
- Infrastructure/Platform Node 1 → Physical Host 1
- Infrastructure/Platform Node 2 → Physical Host 2
- Infrastructure/Platform Node 3 → Physical Host 3
- Omnissa Access Node 1 → Physical Host 1
- Omnissa Access Node 2 → Physical Host 2
With this approach, if one physical host goes down, the service can still run using the other two, keeping your system available and stable.
Requirements for All Nodes
For vSphere, download the Omnissa Access OVA from Omnissa Customer Connect page and select Omnissa Access. After you download the file, deploy all the virtual machines as described in Deploy the Virtual Machines for Omnissa Access Installation
For Nutanix, deployment will be performed from customer-supplied Linux environment. Omnissa has verified Access with AlmaLinux 9.6.
Ensure that the following requirements are completed for all nodes before deployment:
- Static IP address assigned.
- Hostname configured correctly.
- DNS resolution configured.
- All nodes reachable from each other over the network.
- Load balancer configured and reachable. See Using a Load Balancer or Reverse Proxy to Enable External Access to Omnissa Access for configuration requirements.
The objective is to ensure that the operating system and base infrastructure are fully prepared and do not interfere with Platform services during deployment.
Certificate Requirements
A TLS certificate is required for the Omnissa Access deployment FQDN:
- PEM format
.pem. - CN must match the primary tenant FQDN.
- The certificate must include the following Subject Alternative Names (SANs), where
example.comis replaced with your deployment domain:tenant.example.comtenant-cert.example.comtenant-amsso.example.com
Wildcard certificates are supported if they satisfy the required SAN entries. Self-signed certificates are also supported.
The certificate and private key files are required during deployment configuration.
Network Configuration Requirements
| Component | Description |
|---|---|
| DNS record and IP address | IP address and DNS record. Gather the information required to deploy the OVF template, as such: hostname, NiC 1 (eth0) IPv4 address, DNS server addresses, DNS search domain, NIC 1 IPv4 netmask, IPv4 Default Gateway, Docker0 Bridge IPv4 CIDR. |
| Firewall port | Ensure that the inbound firewall ports are open for users outside the network to the Omnissa Access instance or the load balancer. See the Port Requirements that follow. |
| Reverse Proxy | Deploy a reverse proxy such as Unified Access Gateway in the DMZ to allow users to access the Omnissa Access user portal remotely and securely. |
Unified Access Gateway supports reverse proxy functionality to allow users to access the Omnissa Access unified catalog remotely and securely. Unified Access Gateway can be deployed in the DMZ behind the load balancers that is front-ending the Omnissa Access appliance.
Port Requirements
To determine which ports are needed for this Omnissa Access release, see the Omnissa Access Ports and Protocols page, where you can use the filters, such as the Version filter to customize the list to your needs.
Important:
- Ensure that required firewall rules are configured before deployment.
- Internal platform ports must be accessible between infrastructure and Omnissa Access Nodes.
- Public-facing ports should be exposed only through the load balancer or reverse proxy.
- Port exposure may vary depending on deployment architecture and security requirements.
Deploy Virtual Machines
Omnissa Access supports VMware by Broadcom ESXi and Nutanix hypervisors. For the next phase, deploy virtual machines based on your environment:
此页面对您有帮助吗?