3.9. 추가 소프트웨어
일반적인 OpenStack 배포에는 OpenStack별 구성 요소 및 1.6.1절. “타사 구성 요소” 가 포함됩니다. 추가 소프트웨어에는 클러스터링, 로깅, 모니터링 및 경고용 소프트웨어가 포함될 수 있습니다. 따라서 배포 설계에서는 CPU, RAM, 스토리지 및 네트워크 대역폭과 같은 추가 리소스 사용을 고려해야 합니다.
클라우드를 설계할 때 다음과 같은 요소를 고려하십시오.
- 데이터베이스 및 메시징
기본 메시지 큐 공급자는 필요한 수의 컨트롤러 서비스와 복원력이 높은 데이터베이스 기능을 제공하는 기술에 영향을 미칠 수 있습니다. 예를 들어 Galera와 함께 MariaDB를 사용하는 경우 서비스 복제는 쿼럼에 의존합니다. 따라서 기본 데이터베이스는 실패한 Galera 노드 복구를 위해 3개 이상의 노드로 구성되어야 합니다.
소프트웨어 기능을 지원하는 노드 수를 늘리면 랙 공간 및 스위치 포트 밀도를 둘 다 고려하십시오.
- 외부 캐싱
Memcached는 분산 메모리 오브젝트 캐싱 시스템이며 Redis는 키-값 저장소입니다. 두 시스템 모두 클라우드에 배포하여 ID 서비스의 부하를 줄일 수 있습니다. 예를 들어 memcached 서비스는 토큰을 캐시하고 분산 캐싱 시스템을 사용하여 기본 인증 시스템에서 일부 병목 현상을 줄이는 데 도움이 됩니다.
이러한 서비스는 일반적으로 OpenStack 서비스를 제공하는 인프라 노드에 배포되므로 memcached 또는 Redis를 사용하면 아키텍처의 전체 설계에 영향을 미치지 않습니다.
- 로드 밸런싱
많은 일반 용도의 배포가 하드웨어 로드 밸런서를 사용하여 고가용성 API 액세스 및 SSL 종료를 제공하지만 HAProxy와 같은 소프트웨어 솔루션도 고려할 수 있습니다. 소프트웨어 정의 로드 밸런싱 구현도 고가용성인지 확인해야 합니다.
Corosync를 사용하여 Keepalived 또는 Pacemaker와 같은 솔루션을 사용하여 소프트웨어 정의 고가용성을 구성할 수 있습니다. Pacemaker 및 Corosync는 OpenStack 환경의 특정 서비스에 따라 active-active 또는 active-passive 고가용성 구성을 제공할 수 있습니다.
이러한 애플리케이션은 컨트롤러 노드 중 하나가 대기 모드에서 서비스를 실행할 수 있는 두 개 이상의 노드가 있는 배포가 필요하기 때문에 설계에 영향을 미칠 수 있습니다.
- 로깅 및 모니터링
로그를 중앙 집중식 위치에 저장해야 분석을 더 쉽게 수행할 수 있습니다. 또한 로그 데이터 분석 엔진은 일반적인 문제를 경고하고 해결하기 위한 메커니즘에 자동화 및 알림을 제공할 수 있습니다.
아키텍처 설계의 기존 소프트웨어 및 하드웨어를 지원하는 경우 기본 OpenStack 로그 외에 외부 로깅 또는 모니터링 소프트웨어를 사용할 수 있습니다. Red Hat OpenStack Platform용 Operational Tools 리포지토리에는 다음과 같은 툴이 포함되어 있습니다.