Amazon OpenSearch Service 도메인이 ‘처리 중’ 상태에서 멈춘 이유는 무엇입니까?

최종 업데이트 날짜: 2023년 1월 11일

구성 변경 중에는 OpenSearch Service 클러스터가 처리 중 상태로 전환됩니다. 다음 상황 중 하나가 발생하는 경우 클러스터가 ‘처리 중’ 상태에서 멈출 수 있습니다.

• 새 데이터 노드 세트를 시작하지 못했습니다.
• 새 데이터 노드 세트로의 샤드 마이그레이션이 실패했습니다.
• 오류가 발생하여 검증 검사에 실패했습니다.

구성 변경을 시작하면 OpenSearch Service가 새 환경을 생성하는 동안 도메인 상태가 처리 중으로 변경됩니다. 새 환경에서 OpenSearch Service는 새로운 해당하는 노드(예: 데이터, 마스터 또는 UltraWarm) 세트를 시작합니다. 마이그레이션이 완료되면 이전 노드가 종료됩니다.

참고: OpenSearch Service 도메인을 ‘처리 중’ 상태에서 삭제하려고 시도한 후 삭제 중 상태에서 멈춘 경우 AWS Support에 문의하세요.

첫 번째 변경이 완료되기 전에 클러스터에 대한 구성을 동시에 변경하면 클러스터가 멈출 수 있습니다. 클러스터에 진행 중인 블루/그린 배포가 있는지 확인하세요. 진행 중인 블루/그린 배포가 있는지 확인하려면 Amazon CloudWatch에서 총 노드 수를 확인하면 됩니다. 노드 수가 예상보다 많은 경우 블루 또는 그린 배포가 진행 중일 가능성이 높습니다.

다음 API 호출을 사용하여 추가 노드 및 샤드 마이그레이션 프로세스에 대한 자세한 정보를 검색합니다.

Amazon Virtual Private Cloud(VPC) 도메인을 사용 중인 경우 서브넷에 여유 IP 주소가 충분한지 확인합니다. 서브넷에 지정된 IP 주소가 부족하면 새 노드를 시작할 수 없습니다. 결과적으로 클러스터가 처리 중 상태에서 중단됩니다. 자세한 내용은 VPC 서브넷에서 IP 주소 예약을 참조하세요.

OpenSearch Service 도메인을 암호화한 경우 구성을 변경하기 전에 AWS 계정에 AWS KMS 키가 있는지 확인하세요. 실수로 AWS KMS 키를 삭제하면 클러스터가 처리 중 상태에서 멈출 수 있습니다.

클러스터는 다음과 같은 이유로 인해 중단될 수도 있습니다.

• 대기 중인 작업이 너무 많거나 CPU 및 JVM 메모리 압력 수준이 높아 프라이머리 노드가 오버로드되었습니다. cat pending tasks API를 사용하여 대기 중인 작업이 있는지 확인합니다. Amazon CloudWatch에서 MasterCPUUtilization 및 MasterJVMMemoryPressure 지표를 확인할 수도 있습니다.
• OpenSearch 대시보드에 대한 Amazon Cognito 인증 선행 조건이 충족되지 않았습니다. OpenSearch 대시보드 인증을 위해 Amazon Cognito를 구성한 경우 인증 사전 조건이 충족되었는지 확인합니다. 예를 들어 OpenSearch Service에는 올바른 권한을 가진 사용자 풀, Amazon Cognito 자격 증명 풀 및 AWS Identity Access Management(IAM) 역할 세트가 있어야 합니다. 이 역할의 기본 이름은 CognitoAccessForAmazonOpenSearch(AmazonESCognitoAccess 정책이 연결됨)입니다.
  참고: 사용자 지정 IAM 역할을 생성한 경우 역할에 CognitoAccessForAmazonOpenSearch와 동일한 권한이 있는지 확인하세요.

샤드 마이그레이션(이전 데이터 노드 세트에서 새 데이터 노드 세트로)은 다음과 같은 이유로 실패할 수 있습니다.

• 현재 OpenSearch Service 클러스터의 상태가 빨간색입니다. 클러스터 상태가 빨간색인 경우 클러스터가 정상 상태가 되도록 빨간색 클러스터 상태 문제를 해결합니다.
  참고: 클러스터가 정상 상태일 때 클러스터를 구성하는 것이 가장 좋습니다.
• 높은 JVM 메모리 압력과 CPU 사용량으로 인해 처리 로드가 증가하면 노드 서비스가 중단됩니다. 이 문제를 해결하려면 클러스터에 대한 네트워크 트래픽을 줄이거나 네트워크 트래픽을 완전히 중지하여 클러스터를 정상 상태로 되돌립니다. 그렇지 않으면 블루 또는 그린 배포 프로세스 제한 시간이 초과되어 수동 개입이 필요할 수 있습니다.
• 내부 하드웨어 오류로 인해 이전 데이터 노드의 샤드가 마이그레이션 중에 중단될 수 있습니다.
  참고: 하드웨어 문제에 따라 클러스터가 자동으로 복구되지 않을 수도 있습니다. 클러스터가 자동으로 복구되지 않으면 OpenSearch Service는 자가 복구 스크립트를 실행하여 노드를 정상 상태로 되돌립니다. 노드의 루트 볼륨이 손실되면 OpenSearch Service가 응답하지 않을 수도 있으며 오토 스케일링이 장애 노드를 자동으로 교체합니다. 노드에 연결된 EBS 볼륨이 중단된 경우 EBS 볼륨을 교체하려면 수동으로 개입해야 합니다. 이전 노드 세트에서 계속 작동하는 샤드를 식별하려면 cat allocation API, cat nodes API 또는 cat shards API 명령을 사용합니다.
• 새 노드 세트에서 사용 가능한 스토리지가 부족하여 중단된 샤드 재배치가 있습니다. 블루 또는 그린 배포 프로세스 중에 클러스터에 새 데이터가 들어오는 경우 이 문제가 발생합니다.
  참고: OpenSearch Service가 성공적인 데이터 마이그레이션에 필요한 공간보다 적은 공간을 감지하면 블루 또는 그린 배포가 트리거되지 않습니다.
• 이전 노드 세트에 고정된 샤드로 인해 샤드 재배치가 중단되었습니다. 구성을 변경하기 전에 샤드가 노드에 고정되지 않도록 하려면 인덱스 설정을 확인합니다. 또는 높은 JVM 메모리 압력 또는 낮은 디스크 공간으로 인해 발생하는 쓰기 블록이 클러스터에 있는지 확인합니다.

중단된 인덱스 샤드와 해당 인덱스 설정을 확인하려면 다음 명령을 사용합니다.

인덱스 설정에서 다음 설정이 있는지 확인합니다.

인덱스 설정에서 "index.routing.allocation.require._name": "NODE_NAME"이 보이면 다음 설정을 제거합니다.

자세한 내용은 Elastic 웹 사이트에서 인덱스 레벨 샤드 할당 필터링을 참조하세요.

인덱스 설정에서 "index.blocks.write": true가 보이면 클러스터에 쓰기 블록이 있는 것입니다. 쓰기 블록은 높은 JVM 메모리 압력 또는 낮은 디스크 공간 때문에 발생할 수 있습니다. 다른 문제 해결 팁을 구현하기 전에 이 문제를 먼저 해결하세요. 이 예외 문제 해결에 대한 자세한 내용은 ClusterBlockException을 참조하세요.

참고: 클러스터가 24시간 이상 “처리 중(Processing)” 상태로 유지되면 클러스터에 수동 개입이 필요합니다. 또한 구성을 변경하지 않았지만 노드 수가 예상보다 많으면 소프트웨어 패치가 진행 중인 것일 수 있습니다.

서비스 소프트웨어 업데이트 또는 버전 업그레이드 검증 검사가 오류로 인해 실패하면 도메인이 처리 중 상태로 멈출 수 있습니다. 이 문제를 해결하려면 검증 오류 문제 해결을 참조하세요.