High Availability 클러스터 문제 해결

이 표에는 일반적인 클러스터 증상과 해결 방법이 나와 있습니다.
증상
해상도
Windows 워크스테이션과 Ubuntu 노드 간의 SSH 연결이 실패합니다.
워크스테이션이 각 노드에 연결할 수 있도록 SSH 자격 증명 또는 네트워크 구성을 수정하십시오.
클러스터와 배포된 프로젝트가 서로 다른 포트를 사용하기 때문에 웹 UI 액세스가 차단됩니다.
프로젝트 웹프레젠테이션엔진 포트를 클러스터에 구성된 웹 포트(HTTP의 경우 기본값 80, HTTPS의 경우 443)와 일치시킵니다.
데이터베이스가 쓰기 수락을 중지합니다.
이 문제는 세 개의 노드 중 두 개에 장애가 발생하고 데이터베이스가 쿼럼을 잃을 때 발생합니다.
장애가 발생한 노드를 하나 이상 복원하여 쿼럼을 설정하고 쓰기를 재개합니다.
클러스터를 제거한 후 영구 데이터가 누락됩니다.
클러스터를 제거하면 영구 저장소가 제거됩니다.
제거 전에 생성된 백업에서만 데이터를 복구합니다.
클러스터 대시보드에 오래되었거나 예기치 않은 것으로 보이는 상태가 표시됩니다.
대시보드를 새로 고침합니다.
상태가 여전히 잘못되어 보이면 진단 및 내보낸 로그를 확인하여 실제 포드 및 노드 상태를 확인합니다.
런타임의 메모리 제한을 초과하는 대규모 프로젝트를 배포하면 Studio에서 배포가 성공했다고 보고하지만, 로그에 기록되는 정보는 거의 없이 런타임이 즉시 종료됩니다.
  1. 현재 Helm 값 및 개정 기록을 백업하려면 다음을 실행합니다.
    helm get values ftoptix -n ftoptix > pre-change-values-backup.yaml && helm history ftoptix -n ftoptix
  2. 노드 RAM이 새 메모리 제한을 지원할 수 있는지 확인하려면 다음을 실행합니다.
    kubectl describe node <node-name> | grep -A2 "Capacity:"
  3. 재정의를 적용하려면 다음을 실행합니다.
    helm upgrade ftoptix <chart-path> -n ftoptix --reuse-values --set resources.runtime.requests.memory=<value> --set resources.runtime.limits.memory=<value>
  4. 포드가 새 제한을 적용받았고 정상 상태인지 확인하려면 다음을 실행합니다.
    kubectl rollout status statefulset/ftoptix-core-ha-runtime -n ftoptix
                      kubectl get pods -n ftoptix
                      kubectl describe pod ftoptix-core-ha-runtime-0 -n ftoptix | grep -A2 "Limits:"
  5. 변경 사항을 확인하려면 프로젝트를 다시 배포하고, 런타임이 실행 중 또는 활성 상태에 도달하는지 확인하고, 웹 UI에 연결할 수 있는지 확인합니다.
Kubernetes가 401 Unauthorized를 반환하거나, 런타임 ID 검색이 실패하거나, 런타임이 데모 모드로 전환되거나, 업데이트 서버 승인이 간헐적으로 실패하거나, 런타임 포드가 예상대로 복구되지 않습니다.
이러한 증상은 일반적으로 클러스터 노드 간의 클럭 오차로 인해 발생합니다.
승인된 동일한 NTP 소스를 사용하도록 모든 노드를 구성하고, 시간 동기화를 복원하고, 클럭 차이가 1초를 초과하지 않는지 확인하고, 실패한 작업을 다시 시도하십시오.
노드가 동기화되지 않았거나 5초 이상 차이가 나는 경우 프로비저닝을 계속하지 마십시오.
의견을 작성 부탁드립니다.
이 자료에 대한 문의사항이나 요청사항이 있습니까? 여기에 요청사항을 작성 부탁드립니다.
Normal