3.4. 자동화 컨트롤러 API 서비스 스케일링 고려 사항

자동화 컨트롤러 API 서비스의 주요 성능 지표에는 다음이 포함됩니다.

자동화 컨트롤러 API 서비스는 Operator 기반 설치의 웹 Pod 및 VM 기반 설치 또는 컨테이너 기반 설치의 제어 또는 하이브리드 노드에 있습니다.

자동화 컨트롤러 API 서비스를 확장하려면 다음 전략을 고려하십시오.

OpenShift Container Platform에서 각 웹 복제본은 WSGI 웹 서비스 작업자 및 다양한 백그라운드 서비스에 대한 데이터베이스 연결을 사용하여 작업 통신 및 WebSocket을 지원합니다. VM 기반 설치 및 컨테이너 기반 설치의 WSGI 웹 서버에서 사용하는 데이터베이스 연결 수는 시스템의 CPU 수에 따라 확장됩니다. 또한 제어 및 하이브리드 노드는 Dispatcher(작업 시스템) 및 Callback Receiver(작업 이벤트 처리 작업자 풀)를 관리합니다. 이러한 작업자 풀은 CPU 가용성으로 확장되고 데이터베이스 연결이 필요합니다.

추가 제어 노드를 프로비저닝하려면 OpenShift Container Platform에서 웹 배포를 확장하는 것보다 더 많은 데이터베이스 연결이 필요합니다. 이 요구는 컨테이너화된 및 RPM 제어 노드 확장도 확장하므로 OpenShift Container Platform에서 별도의 배포로 작동하는 작업 시스템도 확장되기 때문에 발생합니다. OpenShift Container Platform 배포에서 이러한 서비스를 분리하면 관리자가 배포를 보다 세밀하게 튜닝하고 데이터베이스 연결과 같은 제한된 리소스를 절약할 수 있습니다.

100개 이상의 요청이 다시 로깅된 경우 uWSGI에 의해 이러한 요청이 삭제되므로 OpenShift Container Platform에서 서비스가 수평으로 확장되는 것이 특히 중요합니다. 이로 인해 클라이언트에서 삭제된 요청에 대한 시간 초과를 수신합니다. 다음 로그 텍스트는 이 이벤트에 대한 해당 오류를 제공합니다.

*** uWSGI listen queue of socket ":8000" (fd: 3) full !!! (101/100) ***

이 오류는 커널 매개변수 somaxconn 으로 백로그 길이를 연결하는 uWSGI의 제한으로 인해 발생합니다. OpenShift Container Platform에서 이 커널 매개변수를 늘릴 수 있지만 이렇게 하려면 "보안되지 않은 sysctl"이 필요합니다.