3.2. Operator 엔터프라이즈 토폴로지

다음 다이어그램에서는 고객이 Ansible Automation Platform을 직접 관리할 때 사용할 수 있는 이 배포 모델을 사용하여 Red Hat에서 테스트한 인프라 토폴로지를 간략하게 설명합니다.

그림 3.2. 인프라 토폴로지 다이어그램

View larger image

다음 인프라 토폴로지는 3개의 기본 노드와 2개의 작업자 노드가 있는 OpenShift 클러스터를 설명합니다.

각 OpenShift Worker 노드는 16GB RAM, 4개의 CPU, 128GB 로컬 디스크 및 3000 IOPS와 같은 구성 요소 요구 사항을 사용하여 테스트되었습니다.

Red Hat은 Red Hat Ansible Automation Platform을 설치하고 실행하기 위해 다음 구성을 테스트했습니다.

예를 들어 이 토폴로지의 CR 파일은 test-topologies GitHub 리포지토리의 ocp-b.env-a 디렉터리를 참조하십시오.

Ansible Automation Platform의 성능 특성 및 용량은 리소스 할당 및 구성의 영향을 받습니다. OpenShift를 사용하면 각 Ansible Automation Platform 구성 요소가 Pod로 배포됩니다. 각 Pod에 대한 리소스 요청 및 제한을 지정할 수 있습니다.

Ansible Automation Platform 사용자 지정 리소스를 사용하여 OpenShift 설치에 대한 리소스 할당을 구성합니다. 구성 가능한 각 항목에는 기본 설정이 있습니다. 이러한 설정은 이 참조 배포 아키텍처의 컨텍스트에서 사용되는 정확한 구성이며 환경을 프로덕션 목적으로 Enterprise IT 조직에서 배포 및 관리하는 것으로 가정합니다.

기본적으로 각 구성 요소의 배포는 최소 리소스 요청에 대해 설정되지만 리소스 제한은 없습니다. OpenShift는 사용 가능한 리소스 요청으로만 Pod를 예약하지만, OpenShift 작업자 노드 자체가 노드 부족 상태에 있지 않은 경우 Pod는 무제한 RAM 또는 CPU를 사용할 수 있습니다.

Operator 엔터프라이즈 토폴로지에서 Ansible Automation Platform은 단일 AWS 리전 내의 2개의 AZ에 분배되는 2개의 t3.xlarge 작업자 노드가 있는 AWS(ROSA) 호스트 컨트롤 플레인(HCP) 클러스터의 Red Hat OpenShift에 배포됩니다. 이는 공유 환경이 아니므로 Ansible Automation Platform Pod는 ROSA HCP 클러스터의 모든 컴퓨팅 리소스에 대한 전체 액세스 권한을 갖습니다. 이 시나리오에서는 자동화 컨트롤러 작업 Pod에 대한 용량 계산은 Pod를 실행하는 기본 HCP 작업자 노드에서 파생됩니다. 전체 노드의 CPU 또는 메모리 리소스에 액세스할 수 없습니다. 이 용량 계산은 동시 작업 자동화 컨트롤러 수에 영향을 미칩니다.

OpenShift는 VM과 별도로 스토리지를 관리합니다. 이는 자동화 허브가 아티팩트를 저장하는 방법에 영향을 미칩니다. Operator 엔터프라이즈 토폴로지에서는 자동화 허브에 OpenShift의 기본 스토리지 유형이 아닌 ReadWriteMany 유형 스토리지가 필요하기 때문에 S3 스토리지를 사용합니다. 외부에서 제공된 자동화 허브를 위한 Redis, PostgreSQL 및 오브젝트 스토리지가 지정됩니다. 이를 통해 Ansible Automation Platform 배포에는 특수 백업, 복원 및 복제 서비스 및 확장 가능한 스토리지를 포함한 추가 확장성 및 안정성 기능이 제공됩니다.

Red Hat Ansible Automation Platform은 여러 포트를 사용하여 서비스와 통신합니다. 이러한 포트가 열려 있어야 하며 Red Hat Ansible Automation Platform 서버에 대한 수신 연결에 사용할 수 있어야 합니다. 이러한 포트를 사용할 수 있고 서버 방화벽에 의해 차단되지 않았는지 확인합니다.