이 준비 단계는 Omnissa Access의 제어부 기반 배포를 시작하기 전에 모든 가상 시스템, 네트워킹, 인증서 및 인프라 사전 요구 사항이 준비되도록 보장합니다.
이 배포 모델에서 플랫폼 및 애플리케이션 서비스는 전용 가상 시스템에 배포되고 제어부 프레임워크를 통해 오케스트레이션됩니다. 배포 워크플로를 시작하기 전에 모든 필수 가상 시스템 및 지원 인프라를 프로비저닝하고 검증해야 합니다.
배포 토폴로지 요구 사항
배포 모델은 부트스트랩, 인프라/플랫폼 서비스 및 Omnissa Access 서비스에 전용 가상 시스템을 사용합니다.
표준 운영 배포는 다음 노드로 구성됩니다.
| 노드 유형 | 수량 | 용도 |
|---|---|---|
| 부트스트랩 노드 | 1 | 제어부 배포를 초기화하고 오케스트레이션합니다. |
| Omnissa Access 노드 | 2 또는 3 | 로드 밸런서 뒤에 있는 Omnissa Access 애플리케이션 서비스를 호스팅합니다. |
| 인프라/플랫폼 노드 | 3 | 플랫폼 및 공유 인프라 서비스를 호스팅합니다. |
필요한 총 노드 수: 소형 또는 중형 사용 시 6개, 대형 사용 시 7개입니다.
중요:
- 설치 워크플로를 시작하기 전에 모든 가상 시스템을 배포하고 액세스할 수 있어야 합니다.
- 모든 노드에 대해 정적 IP 주소, DNS 레코드 및 호스트 이름을 구성해야 합니다.
configuser암호는 모든 노드에서 일관되게 구성되어야 합니다.configuser의 기본 암호 만료 기간은 OVA 배포 날짜로부터 60일입니다. 모든 클러스터 노드에서 동일한 암호를 재설정해야 합니다.- 제어부 부트스트랩 및 클러스터 초기화가 완료된 후에는 노드 역할 또는 배포 토폴로지 변경이 지원되지 않습니다.
- 모든 노드는 필요한 네트워크 포트를 통해 서로 통신할 수 있어야 합니다.
- 배포하기 전에 Omnissa Access 노드 앞에 로드 밸런서가 구성되어 있어야 합니다.
고가용성을 위한 인프라 설정 지침
문제가 있어도 시스템이 계속 가동되어 실행되도록 하려면 인프라 및 플랫폼용 VM(가상 시스템)을 생성할 때 다음 규칙을 따르십시오.
서로 다른 물리적 시스템(ESX 호스트)에서 각 노드를 실행합니다. 예를 들어 인프라/플랫폼 노드 3개와 Omnissa Access 노드 2개가 필요한 경우 다음과 같이 배치합니다.
- 인프라/플랫폼 노드 1 → 물리적 호스트 1
- 인프라/플랫폼 노드 2 → 물리적 호스트 2
- 인프라/플랫폼 노드 3 → 물리적 호스트 3
- Omnissa Access 노드 1 → 물리적 호스트 1
- Omnissa Access 노드 2 → 물리적 호스트 2
이 방법을 사용하면 물리적 호스트 하나가 다운되더라도 나머지 두 개를 사용하여 서비스를 계속 실행할 수 있으므로 시스템 가용성과 안정성이 유지됩니다.
하드웨어 크기 조정 요구 사항
다음 크기 조정은 Omnissa Access의 제어부 기반 배포에만 적용됩니다.
환경의 사용자, 그룹 및 애플리케이션 수에 따라 배포 크기를 선택합니다.
다음 표에는 각 배포 크기에 필요한 최소 하드웨어 구성이 표시됩니다.
배포 크기별 최소 하드웨어 구성:
| 배포 크기 | 부트스트랩 노드 | Omnissa Access 노드 | 인프라/플랫폼 노드¹ | 지원되는 규모 |
|---|---|---|---|---|
| 소형 | 노드 1개 vCPU 8개 32GB RAM 200GB 디스크 | 로드 밸런싱된 노드 2개 vCPU 24개 48GB RAM 각각 200GB 디스크 | 노드 3개 vCPU 16개 48GB RAM 각각 200GB 디스크 | 최대: 사용자 300,000명 3,000개 그룹 애플리케이션 50개 |
| 중형 | 노드 1개 vCPU 8개 32GB RAM 200GB 디스크 | 로드 밸런싱된 노드 2개 vCPU 48개 64GB RAM 각각 200GB 디스크 | 노드 3개 vCPU 24개 96GB RAM 각각 300GB 디스크 | 최대: 사용자 1,000,000명 10,000개 그룹 애플리케이션 150개 |
| 대형 | 노드 1개 vCPU 8개 32GB RAM 200GB 디스크 | 로드 밸런싱된 노드 3개 vCPU 64개 96GB RAM 각각 200GB 디스크 | 노드 3개 vCPU 24개 96GB RAM 각각 400GB 디스크 | 최대: 사용자 1,000,000명 20,000개 그룹 애플리케이션 500개 |
¹ 인프라/플랫폼 노드는 데이터베이스, 메시징, 캐싱 및 검색(PostgreSQL, Redis, Kafka 및 OpenSearch)을 포함한 내부 플랫폼 서비스를 호스팅합니다.
*부트스트랩 노드에는 배포 크기에 관계없이 정확히 8개의 vCPU가 필요합니다.
중요:
- 리소스 크기 조정은 인증 로드, 사용된 서비스 및 통합 요구 사항에 따라 다를 수 있습니다.
- 로깅, 감사 보존 및 작업 요구 사항에 따라 추가 스토리지 할당이 필요할 수 있습니다.
모든 노드에 대한 요구 사항
Omnissa Customer Connect 페이지에서 Omnissa Access OVA를 다운로드하고 Omnissa Access를 선택합니다. 파일을 다운로드한 후 모든 가상 시스템을 배포합니다.
배포 전에 모든 노드에 대해 다음 요구 사항이 완료되었는지 확인합니다.
- 정적 IP 주소가 할당되었습니다.
- 호스트 이름이 올바르게 구성되었습니다.
cp-cluster.ini파일에서 호스트 이름을 사용하는 경우 DNS 확인이 구성되고 검증되었습니다.- SSH 액세스를 사용하도록 설정했습니다.
- 모든 노드가 네트워크를 통해 서로 연결할 수 있습니다.
- 로드 밸런서가 구성되고 연결할 수 있습니다.
configuser암호가 구성되거나 모든 노드에서 동일한 암호로 재설정됩니다.
목표는 운영 체제 및 기본 인프라가 완전히 준비되고 배포 중에 제어부 서비스를 방해하지 않도록 하는 것입니다.
인증서 요구 사항
배포 전에 필요한 TLS 인증서를 준비합니다.
Omnissa Access FQDN 인증서
Omnissa Access 배포 FQDN에는 TLS 인증서가 필요합니다.
인증서 요구 사항:
- PEM 형식
.pem입니다. - CN은 기본 테넌트 FQDN과 일치해야 합니다.
- 인증서에는 다음과 같은 SAN(주체 대체 이름)이 포함되어야 합니다.
tenant.example.comtenant-cert.example.comtenant-amsso.example.com
와일드카드 인증서는 필요한 SAN 항목을 충족하는 경우 지원됩니다.
예:
배포 도메인이 example.com인 경우 인증서 SAN 항목은 다음과 같을 수 있습니다.
- tenant.example.com
- tenant-cert.example.com
- tenant-amsso.example.com
인증서 및 개인 키 파일은 배포 구성 중에 필요합니다.
네트워크 구성 요구 사항
| 구성 요소 | 설명 |
|---|---|
| DNS 레코드 및 IP 주소 | IP 주소 및 DNS 레코드입니다. 호스트 이름, NiC 1(eth0) IPv4 주소, DNS 서버 주소, DNS 검색 도메인, NIC 1 IPv4 넷마스크, IPv4 기본 게이트웨이, Docker0 브리지 IPv4 CIDR 등 OVF 템플릿을 배포하는 데 필요한 정보를 수집합니다. |
| 방화벽 포트 | 인바운드 방화벽 포트가 네트워크 외부 사용자의 Omnissa Access 인스턴스 또는 로드 밸런서에 대해 열려 있는지 확인합니다. 다음 포트 요구 사항을 참조하십시오. |
| 역방향 프록시 | DMZ의 F5 액세스 정책 관리자 같은 역방향 프록시를 배포하여 사용자가 Omnissa Access 사용자 포털에 원격으로 안전하게 액세스하도록 할 수 있습니다. |
Unified Access Gateway 2.8 이상에서는 사용자가 원격으로 안전하게 Omnissa Access 통합 카탈로그에 액세스할 수 있도록 하기 위해 역방향 프록시 기능을 지원합니다. Unified Access Gateway는 Omnissa Access 장치 프런트 엔드에 있는 DMZ의 로드 밸런서 뒤에 배포할 수 있습니다.
포트 요구 사항
내부 및 외부 통신을 위한 포트 요구 사항은 다음과 같습니다.
| 서비스 | 공용 | 포트 | 프로토콜 | 방향 | 소스 노드 유형 | 대상 노드 유형 |
|---|---|---|---|---|---|---|
| Consul LAN Gossip | 아니요 | 8301 | TCP/UDP | 양방향 | 모두 | 모두 |
| Consul RPC | 아니요 | 8300 | TCP | 양방향 | 모두 | 모두 |
| Consul Mesh gRPC 포트 | 아니요 | 8302 | gRPC | 양방향 | 애플리케이션 워크로드/클러스터 | 애플리케이션 워크로드/클러스터 |
| Consul HTTP(s) | 아니요 | 8501 | HTTPS | 인바운드 | CLI | 관리 클러스터 |
| 동적 서비스 포트 | 아니요 | 20,000–32,000 | TCP/HTTPS | 양방향 | 애플리케이션 워크로드/클러스터 | 애플리케이션 워크로드/클러스터 |
| Nomad UI/API | 아니요 | 4646 | HTTPS | 인바운드 | CLI | 관리 클러스터 |
| Nomad UI/API | 아니요 | 4647 | TCP | 양방향 | 모두 | 모두 |
| Nomad LAN Gossip | 아니요 | 4648 | TCP/UDP | 양방향 | 모두 | 모두 |
| Vault | 아니요 | 8201 | TCP | 양방향 | 관리 클러스터 | 관리 클러스터 |
| Vault API | 아니요 | 8202 | HTTPS | 인바운드 | CLI | 관리 클러스터 |
| 아웃바운드 원격 분석 | 아니요 | 8125 | UDP | 아웃바운드 | 모두 | 관리 클러스터 |
| 아웃바운드 원격 분석 | 아니요 | 2878 | TCP | 인바운드 | 애플리케이션 워크로드/클러스터 | 애플리케이션 워크로드/클러스터 |
| 아웃바운드 원격 분석 | 아니요 | 9411 | TCP | 아웃바운드 | 모두 | 애플리케이션 워크로드/클러스터 |
| 아웃바운드 Syslog 로깅 | 아니요 | 5044 | TCP | 인바운드 | 애플리케이션 워크로드/클러스터 | 애플리케이션 워크로드/클러스터 |
| Redis 연결 | 아니요 | 6379 | TCP | 양방향 | 애플리케이션 워크로드/클러스터 | 애플리케이션 워크로드/클러스터 |
| Redis TLS 연결 | 아니요 | 16380 | TCP | 양방향 | 애플리케이션 워크로드/클러스터 | 애플리케이션 워크로드/클러스터 |
| Redis Sentinel 연결 | 아니요 | 26379 | TCP | 양방향 | 애플리케이션 워크로드/클러스터 | 애플리케이션 워크로드/클러스터 |
| Redis Sentinel TLS 연결 | 아니요 | 36379 | TCP | 양방향 | 애플리케이션 워크로드/클러스터 | 애플리케이션 워크로드/클러스터 |
| Postgres 연결 | 아니요 | 5432 | TCP | 인바운드 | 애플리케이션 워크로드/클러스터 | 핵심 서비스 |
| Postgres 연결 | 아니요 | 5432 | TCP | 양방향 | 핵심 서비스 | 핵심 서비스 |
| 클라이언트 연결 | 아니요 | 9092 | TCP | 인바운드 | 애플리케이션 워크로드/클러스터 | 핵심 서비스 |
| 클라이언트 연결 | 아니요 | 9096 | TCP | 인바운드 | 애플리케이션 워크로드/클러스터 | 핵심 서비스 |
| Kafka | 아니요 | 9094 | TCP | 인바운드 | 핵심 서비스 | 핵심 서비스 |
| Kafka | 아니요 | 9093 | TCP | 인바운드 | 핵심 서비스 | 핵심 서비스 |
| Kafka | 아니요 | 2181 | TCP | 인바운드 | 핵심 서비스 | 핵심 서비스 |
| Kafka | 아니요 | 2888 | TCP | 인바운드 | 핵심 서비스 | 핵심 서비스 |
| Kafka | 아니요 | 3888 | TCP | 인바운드 | 핵심 서비스 | 핵심 서비스 |
| 수신 게이트웨이 | 아니요 | 8080 | HTTPS | 인바운드 | 모두 | 애플리케이션 워크로드/클러스터 |
| Docker 이미지/패키지/바이너리 자산 | 아니요 | 443 | HTTPS | 인바운드 | 모두 | 자산 서버 |
| OpenSearch 클라이언트 연결 | 아니요 | 29200 | TCP | 양방향 | 애플리케이션 워크로드/클러스터 | 핵심 서비스 |
| OpenSearch 내부 통신 | 아니요 | 29300 | TCP | 양방향 | 애플리케이션 워크로드/클러스터 | 핵심 서비스 |
| Postgres | 아니요 | 28008 | HTTPS | 양방향 | 애플리케이션 워크로드/클러스터 | 핵심 서비스 |
| NGINX | 예 | 80 | HTTP | 인바운드 | 모두 | Omnissa Access 노드 |
| NGINX | 예 | 443 | HTTPS | 인바운드 | 모두 | Omnissa Access 노드 |
| NGINX-stream | 예 | 27443 | TCP | 인바운드 | 모두 | Omnissa Access 노드 |
| NGINX-stream | 예 | 25262 | TCP | 인바운드 | 모두 | Omnissa Access 노드 |
| CAS | 아니요 | 28443 | TCP | 인바운드 | 모두 | Omnissa Access 노드 |
| CERTPROXY | 아니요 | 25261 | TCP | 인바운드 | 모두 | Omnissa Access 노드 |
중요:
- 배포 전에 필요한 방화벽 규칙이 구성되어 있는지 확인합니다.
- 인프라와 Omnissa Access 노드 간에 내부 플랫폼 포트에 액세스할 수 있어야 합니다.
- 공용 포트는 로드 밸런서 또는 역방향 프록시를 통해서만 노출되어야 합니다.
- 포트 노출은 배포 아키텍처 및 보안 요구 사항에 따라 다를 수 있습니다.
이 페이지가 도움이 되었나요?