이 준비 단계는 Omnissa Access의 제어부 기반 배포를 시작하기 전에 모든 가상 시스템, 네트워킹, 인증서 및 인프라 사전 요구 사항이 준비되도록 보장합니다.
이 배포 모델에서 플랫폼 및 애플리케이션 서비스는 전용 가상 시스템에 배포되고 제어부 프레임워크를 통해 오케스트레이션됩니다. 배포 워크플로를 시작하기 전에 모든 필수 가상 시스템 및 지원 인프라를 프로비저닝하고 검증해야 합니다.
배포에 대해 DR(재해 복구) 사이트를 구성하려는 경우 NFS 스토리지가 필요합니다. 사전 요구 사항에 대해서는 Omnissa Access를 위한 재해 복구 구성을 참조하십시오.
배포 토폴로지 요구 사항
배포 모델은 부트스트랩, 인프라/플랫폼 서비스 및 Omnissa Access 서비스에 전용 가상 시스템을 사용합니다.
표준 운영 배포는 다음 노드로 구성됩니다.
| 노드 유형 | 수량 | 용도 |
|---|---|---|
| 부트스트랩 노드 | 1 | 제어부 배포를 초기화하고 오케스트레이션합니다. |
| Omnissa Access 노드 | 2 소형 및 중형 3 대형 | 로드 밸런서 뒤에 있는 Omnissa Access 애플리케이션 서비스를 호스팅합니다. |
| 인프라/플랫폼 노드 | 3개 | 플랫폼 및 공유 인프라 서비스를 호스팅합니다. |
중요:
- 설치 워크플로를 시작하기 전에 모든 가상 시스템을 배포하고 액세스할 수 있어야 합니다.
- 모든 노드에 대해 정적 IP 주소, DNS 레코드 및 호스트 이름을 구성해야 합니다.
configuser암호는 모든 노드에서 일관되게 구성되어야 합니다.configuser의 기본 암호 만료 기간은 OVA 배포 날짜로부터 60일입니다. 모든 클러스터 노드에서 동일한 암호를 재설정해야 합니다.- 제어부 부트스트랩 및 클러스터 초기화가 완료된 후에는 노드 역할 또는 배포 토폴로지 변경이 지원되지 않습니다.
- 모든 노드는 필요한 네트워크 포트를 통해 서로 통신할 수 있어야 합니다.
- 배포하기 전에 Omnissa Access 노드 앞에 로드 밸런서가 구성되어 있어야 합니다.
하드웨어 크기 조정 요구 사항
다음 크기 조정은 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가 필요합니다.
중요:
- 리소스 크기 조정은 인증 로드, 사용된 서비스 및 통합 요구 사항에 따라 다를 수 있습니다.
- 로깅, 감사 보존 및 작업 요구 사항에 따라 추가 스토리지 할당이 필요할 수 있습니다.
고가용성을 위한 인프라 설정 지침
문제가 있어도 시스템이 계속 가동되어 실행되도록 하려면 인프라 및 플랫폼용 VM(가상 시스템)을 생성할 때 다음 규칙을 따르십시오.
서로 다른 물리적 시스템(ESX 호스트)에서 각 노드를 실행합니다. 예를 들어 인프라/플랫폼 노드 3개와 Omnissa Access 노드 2개가 필요한 경우 다음과 같이 배치합니다.
- 부트스트랩 노드 → 물리적 호스트 1
- 인프라/플랫폼 노드 1 → 물리적 호스트 1
- 인프라/플랫폼 노드 2 → 물리적 호스트 2
- 인프라/플랫폼 노드 3 → 물리적 호스트 3
- Omnissa Access 노드 1 → 물리적 호스트 1
- Omnissa Access 노드 2 → 물리적 호스트 2
이 방법을 사용하면 물리적 호스트 하나가 다운되더라도 나머지 두 개를 사용하여 서비스를 계속 실행할 수 있으므로 시스템 가용성과 안정성이 유지됩니다.
모든 노드에 대한 요구 사항
Omnissa Customer Connect 페이지에서 Omnissa Access OVA를 다운로드하고 Omnissa Access를 선택합니다. 파일을 다운로드한 후 Omnissa Access용 가상 시스템 설치 배포에 설명된 대로 모든 가상 시스템을 배포합니다.
배포 전에 모든 노드에 대해 다음 요구 사항이 완료되었는지 확인합니다.
- 정적 IP 주소가 할당되었습니다.
- 호스트 이름이 올바르게 구성되었습니다.
- DNS 확인이 구성되었습니다.
- 모든 노드가 네트워크를 통해 서로 연결할 수 있습니다.
- 로드 밸런서가 구성되고 연결할 수 있습니다. 구성 요구 사항은 로드 밸런서 또는 역방향 프록시를 사용하여 Omnissa Access에 대한 외부 액세스 사용을 참조하십시오.
목표는 운영 체제 및 기본 인프라가 완전히 준비되고 배포 중에 플랫폼 서비스를 방해하지 않도록 하는 것입니다.
인증서 요구 사항
Omnissa Access 배포 FQDN에는 TLS 인증서가 필요합니다.
- PEM 형식
.pem입니다. - CN은 기본 테넌트 FQDN과 일치해야 합니다.
- 인증서에는 다음 SAN(주체 대체 이름)가 포함되어야 합니다. 여기서
example.com은 배포 도메인으로 대체됩니다.tenant.example.comtenant-cert.example.comtenant-amsso.example.com
와일드카드 인증서는 필요한 SAN 항목을 충족하는 경우 지원됩니다. 자체 서명 인증서도 지원됩니다.
인증서 및 개인 키 파일은 배포 구성 중에 필요합니다.
네트워크 구성 요구 사항
| 구성 요소 | 설명 |
|---|---|
| DNS 레코드 및 IP 주소 | IP 주소 및 DNS 레코드입니다. 호스트 이름, NiC 1(eth0) IPv4 주소, DNS 서버 주소, DNS 검색 도메인, NIC 1 IPv4 넷마스크, IPv4 기본 게이트웨이, Docker0 브리지 IPv4 CIDR 등 OVF 템플릿을 배포하는 데 필요한 정보를 수집합니다. |
| 방화벽 포트 | 인바운드 방화벽 포트가 네트워크 외부 사용자의 Omnissa Access 인스턴스 또는 로드 밸런서에 대해 열려 있는지 확인합니다. 다음 포트 요구 사항을 참조하십시오. |
| 역방향 프록시 | DMZ의 Unified Access Gateway 같은 역방향 프록시를 배포하여 사용자가 Omnissa Access 사용자 포털에 원격으로 안전하게 액세스하도록 할 수 있습니다. |
Unified Access Gateway에서는 사용자가 원격으로 안전하게 Omnissa Access 통합 카탈로그에 액세스할 수 있도록 하기 위해 역방향 프록시 기능을 지원합니다. Unified Access Gateway는 Omnissa Access 장치 프런트 엔드에 있는 DMZ의 로드 밸런서 뒤에 배포할 수 있습니다.
포트 요구 사항
이 Omnissa Access 릴리스에 필요한 포트를 확인하려면 버전 필터와 같은 필터를 사용하여 필요에 맞게 목록을 사용자 지정할 수 있는 Omnissa Access 포트 및 프로토콜 페이지를 참조하십시오.
중요:
- 배포 전에 필요한 방화벽 규칙이 구성되어 있는지 확인합니다.
- 인프라와 Omnissa Access 노드 간에 내부 플랫폼 포트에 액세스할 수 있어야 합니다.
- 공용 포트는 로드 밸런서 또는 역방향 프록시를 통해서만 노출되어야 합니다.
- 포트 노출은 배포 아키텍처 및 보안 요구 사항에 따라 다를 수 있습니다.
이 페이지가 도움이 되었나요?