Installieren von Omnissa Access

Befolgen Sie die Anweisungen in diesem Handbuch, um Omnissa® Access™ auf der Steuerungsebene bereitzustellen.

Der Abschnitt „Installieren von Omnissa Access“ im Handbuch Installieren und Konfigurieren von Omnissa Access führt Sie durch den gesamten Prozess der Bereitstellung von Omnissa Access in Ihrer Umgebung. Er enthält eine Übersicht über die Bereitstellung, eine Beschreibung der Plattformkomponenten, aus denen ein Omnissa Access-Cluster besteht, die unterstützte Bereitstellungsarchitektur sowie eine schrittweise Installationsanleitung, die Sie von der ersten Vorbereitung der virtuellen Maschine bis zur Erstellung eines Mandanten begleitet – entweder mithilfe des Access Wizard oder, falls Sie die direkte Kontrolle über jeden einzelnen Schritt bevorzugen, manuell.

NFS-Speicher ist erforderlich, wenn Sie eine Notfallwiederherstellungs-Site (Disaster Recovery, DR) für Ihre Bereitstellung konfigurieren möchten. Weitere Informationen zu den Voraussetzungen finden Sie unter Konfigurieren der Notfallwiederherstellung für Omnissa Access.

Nach Abschluss der Installation behandelt das Handbuch Themen zur Konfiguration und Verwaltung, die Ihnen bei der Vorbereitung und dem Betrieb Ihrer Bereitstellung helfen.

Nach Abschluss der Konfiguration können Sie die Omnissa Access-Konsole verwenden, um Benutzer und Gruppen zu verwalten, Authentifizierungs- und Zugriffsrichtlinien einzurichten und zu verwalten sowie Ressourcen zum Katalog hinzuzufügen und die Berechtigungen für diese Ressourcen zu verwalten. Sie können auch die Workspace ONE UEM-Integration konfigurieren und Hub Services starten.

Übersicht über die Architektur

Omnissa Access wird als Satz von containerisierten Microservices ausgeführt, die von der Steuerungsebene verwaltet werden. Die Dienste, aus denen Omnissa Access besteht, sind auf einen Cluster aus dedizierten virtuellen Maschinen verteilt, die alle unter AlmaLinux 9.6 laufen, und werden als unabhängige Arbeitslasten bereitgestellt und betrieben. Da jeder Dienst eigenständig ausgeführt wird, können die Dienste einzeln aktualisiert, neu gestartet, skaliert und wiederhergestellt werden.

Die Steuerungsebene

Die Steuerungsebene ist die Plattform, die die Dienste, aus denen eine Omnissa Access-Bereitstellung besteht, installiert, ausführt, skaliert und überwacht. Sie koordiniert jeden Dienst im Cluster mithilfe von drei Plattformdiensten:

Nomad plant und orchestriert die Dienstarbeitslasten.
Consul sorgt für die Dienstermittlung und die sichere interne Kommunikation zwischen den Diensten.
Vault speichert und verwaltet geheime Schlüssel, Zertifikate und Token.

Dienstkategorien

Eine Omnissa Access-Bereitstellung besteht aus drei Dienstkategorien:

Komponente	Zweck	Kategorie
Nomad	Arbeitslast-Orchestrierung (führt alle Dienste aus)	Plattformdienst
Consul	Diensterkennung und interne Kommunikation	Plattformdienst
Vault	Geheime Schlüssel, Zertifikate, Token	Plattformdienst
PostgreSQL	Datenbank	Infrastrukturdienste
Redis	Cache und Warteschlangen	Infrastrukturdienste
Kafka	Event-Streaming	Infrastrukturdienste
OpenSearch	Analyse	Infrastrukturdienste
Access-Dienste	Omnissa Access-Anwendungsdienste	Access-Dienste

Knotentypen

Ein Omnissa Access-Cluster besteht aus drei Typen von virtuellen Maschinen sowie einem Lastausgleichsdienst:

Bootstrap-Knoten — der Bereitstellungskontroller. Sie führen die WSO-CLI von diesem Knoten aus, um den Cluster bereitzustellen und zu betreiben.
Infrastruktur-/Plattformknoten – hosten die Plattformdienste und die Infrastrukturdienste.
Omnissa Access-Knoten – hosten die Omnissa Access-Dienste. Plattformdienste werden auch auf diesen Knoten ausgeführt.
Lastausgleichsdienst – verteilt den Datenverkehr über die Omnissa Access-Knoten und bietet Hochverfügbarkeit für die Access-Dienste.

Plattformdienste werden sowohl auf den Infrastruktur-/Plattformknoten als auch auf den Omnissa Access-Knoten ausgeführt, sodass Orchestrierung, Dienstermittlung und die Verwaltung geheimer Schlüssel weiterhin clusterweit funktionieren und nicht von einem einzelnen Knoten abhängig sind.

Die WSO-CLI

Die WSO-CLI (Workspace ONE Command-Line Interface) ist die primäre Schnittstelle für die Bereitstellung und den Betrieb von Omnissa Access. Sie führen WSO-CLI-Befehle über den Bootstrap-Knoten aus.

Bereitstellungsübersicht

Omnissa Access wird auf der Steuerungsebenenplattform in mehreren Phasen bereitgestellt. Jede Phase hängt vom erfolgreichen Abschluss der vorherigen Phase ab.

Bereitstellungsphasen

Virtuelle Maschinen vorbereiten.
Stellen Sie die virtuellen Maschinen bereit.
Omnissa Access bereitstellen – wählen Sie eine der folgenden Optionen:
- Option 1: Verwenden des Access Wizard.
- Option 2: Manuell, Schritt für Schritt.

Bereitstellungsarchitektur

Stellen Sie sicher, dass die folgenden architekturbezogenen Anforderungen erfüllt sind. Diese sind für Omnissa Access erforderlich:

Erforderliche virtuelle Maschinen

Knotentyp	Anzahl	Zweck
Infrastruktur-/Plattformknoten	3	Infrastrukturdienste
Omnissa Access-Knoten	2 für kleine und mittlere 3 für große	Access-Anwendungsdienste
Bootstrap-Knoten	1	Bereitstellungscontroller
Lastausgleichsdienst	0	Für HA der Access-Dienste

Hinweis: Plattformdienste werden sowohl auf den Infrastruktur-/Plattformknoten als auch auf den Omnissa Access-Knoten ausgeführt.

Dienstplatzierung

Knoten	Dienste
Infrastruktur-/Plattformknoten	Nomad, Consul, Vault, Postgres, Redis, Kafka, OpenSearch
Omnissa Access-Knoten	Nomad, Consul, Vault, Access-Dienste
Bootstrap-Knoten	Bereitstellungs-/Verwaltungsvorgänge

Stellen Sie sicher, dass alle Knoten die folgenden Anforderungen erfüllen:

AlmaLinux 9.6 wird ausgeführt
Sie verfügen über statische IP-Adressen
Sie verfügen über eindeutige Hostnamen
Sie verfügen über SSH-Zugriff vom Bootstrap-Knoten aus

Lastausgleichskonfiguration

Konfigurieren Sie Ihren Lastausgleichsdienst und fügen Sie Ihre Access-Dienstknoten vorgelagert hinzu, sodass der Lastausgleichsdienst den Datenverkehr auf einen beliebigen der Knoten umleiten kann. Informationen zu den Konfigurationsanforderungen finden Sie unter Verwenden eines Lastausgleichsdiensts oder eines Reverseproxy für den externen Zugriff auf Omnissa Access.
DNS-Auflösung
- DNS-Eintrag: Stellen Sie sicher, dass ein DNS-Eintrag in FQDN-IP (Lastausgleichsdienst-IP) aufgelöst wird.
  
  tenant.example.com
Zertifikatanforderungen
- Allgemeiner Name (Common Name, CN): Hostname des Lastausgleichsdiensts (tenant.example.com).
- Alternative Antragstellernamen (Subject Alternate Name, SAN)
  - Beispiele:
    - tenant.example.com
    - tenant-cert.example.com
    - tenant-amsso.example.com
  Stellen Sie sicher, dass der Domänenanteil aller SAN-Einträge mit der Domäne übereinstimmt, die vom Lastausgleichsdienst und den Clusterknoten verwendet wird.
  
  Hinweise:
  - Sie können ein Platzhalterzertifikat wie beispielsweise *.tenant.example.com verwenden, um alle SANs abzudecken.
  - Wenn Sie keine zertifikatbasierte Authentifizierung verwenden ist, tenant.example.com das einzige erforderliche SAN. Sie können tenant-cert.example.com und tenant-amsso.example.com weglassen.
CSR-Referenz

Verwenden Sie je nach Zertifikattyp eine der folgenden Konfigurationen.

Platzhalterzertifikat
```
[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
CN = *.tenant.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = *.tenant.example.com
```
Nicht-Platzhalterzertifikat (alle SANs erforderlich)

Wenn Sie kein Platzhalterzertifikat verwenden, listen Sie jeden alternativen Antragstellernamen explizit auf.
```
[ req ]
default_bits       = 2048
prompt             = no
default_md         = sha256
distinguished_name = dn
req_extensions     = req_ext

[ dn ]
CN = tenant.example.com

[ req_ext ]
subjectAltName = @alt_names

[ alt_names ]
DNS.1 = tenant.example.com
DNS.2 = tenant-cert.example.com
DNS.3 = tenant-amsso.example.com
```

War diese Seite hilfreich?