ABLESTACK VM 클라우드센터 연결실패

kynd

CCVM 배포 후, 클라우드 센터 구성하기를 3개 호스트에서 동시 실행하고 난 뒤, 클라우드 센터 연결이 되지 않는 상황발생

TechFlow-Assistant

현재 자료만으로는 3개 호스트의 동시 실행이 연결 실패를 일으켰다고 확정할 수 없습니다. 우선 추가 동시 실행을 중단하고, 실패한 화면의 정확한 단계와 API 응답을 확인해야 합니다. 제공된 Source의 createConsoleEndpoint, CheckConsoleProxyLoadCommand, LibvirtConsoleProxyLoadCommandWrapper는 VM 콘솔 연결 기능에 관한 코드입니다. 사용자가 실행한 ‘클라우드 센터 구성하기’ 작업과 같은 요청이라는 근거는 없습니다. 따라서 CCVM 관리 연결 장애와 VM 콘솔 장애를 먼저 구분해야 합니다.

먼저 다음 해결 방법을 적용해 보세요.

세 호스트에서 ‘클라우드 센터 구성하기’를 다시 동시에 실행하지 마십시오. 기존 작업 결과를 보존하고, 이후 확인은 한 호스트에서만 진행하십시오.
브라우저 개발자 도구의 Network에서 실패한 요청의 API 명령 이름, HTTP 상태 코드, 응답 본문을 확인하십시오. 설정 작업을 다시 실행하지 말고 현재 연결 시도에서 발생하는 요청을 확인하는 것이 안전합니다.
실패 요청이 createConsoleEndpoint라면 이는 클라우드 센터 구성 작업이 아니라 VM 콘솔 연결 정보 생성 경로입니다. 이 API는 연결 정보를 만들지 못하면 INTERNAL_ERROR와 Unable to generate console endpoint for vm ... 오류를 반환합니다.
VM 콘솔만 열리지 않는 경우에는 관리자 화면에서 콘솔 연결을 중계하는 시스템 가상머신 상태를 확인하십시오. 콘솔 연결을 중계하는 시스템 가상머신은 하이퍼바이저의 VNC 데이터를 중계하며, 호스트 측 상태 점검은 관리 IP와 명령 포트의 /cmd/getstatus 응답을 읽습니다. 이 응답을 열거나 읽지 못하면 점검 결과가 실패로 처리됩니다.
실패 요청이 createConsoleEndpoint가 아니라면 Console Proxy 조치를 적용하지 마십시오. 해당 API 이름과 응답 본문을 기준으로 CCVM 구성 단계의 실패 분기를 다시 판단해야 합니다.

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

실패 요청이 createConsoleEndpoint인 경우, 콘솔 연결 정보 생성 결과가 없어서 내부 오류가 발생했을 가능성
VM 콘솔 장애인 경우, 호스트가 콘솔 연결을 중계하는 시스템 가상머신의 관리 IP와 명령 포트에 있는 /cmd/getstatus를 열거나 읽지 못했을 가능성

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

‘연결 실패’가 Mold 웹 화면 자체의 접속 실패인지, CCVM 구성 마법사의 연결 시험 실패인지, 특정 VM 콘솔 연결 실패인지 확인되지 않았습니다.
‘클라우드 센터 구성하기’에서 실패한 정확한 단계와 화면 오류 문구가 제공되지 않았습니다.
실패한 API 명령 이름, HTTP 상태 코드, 응답 본문이 제공되지 않았습니다.
3개 호스트의 동시 실행이 구성 상태 경합을 일으켰는지는 현재 Source와 실행 증거로 확인되지 않습니다.

kynd

TechFlow-Assistant
클라우드센터 연결

클라우드센터에 정상적으로 연결되지 않습니다.
클라우드센터 서비스 상태를 확인하거나, 잠시 후에 다시 시도해주십시오.

ablestackJson.py : {"code": 200, "val": {"ccvm": "true"}, "name": "jsonStatus", "type": "dict"}

VM85:686 ccvmStatus.ccvm = true

VM85:694 ccvm true in

VM83:236 ok(checkPCSOK): {

"code": 200,

"val": {

    "clustered_host": [

        "10.10.12.1",

        "10.10.12.2",

        "10.10.12.3"

    ],

    "nodes": [

        {

            "host": "10.10.12.1",

            "online": "true",

            "resources_running": "7",

            "standby": "false",

            "standby_onfail": "false",

            "maintenance": "false",

            "pending": "false",

            "unclean": "false",

            "shutdown": "false",

            "expected_up": "true",

            "is_dc": "false",

            "type": "member"

        },

        {

            "host": "10.10.12.2",

            "online": "true",

            "resources_running": "5",

            "standby": "false",

            "standby_onfail": "false",

            "maintenance": "false",

            "pending": "false",

            "unclean": "false",

            "shutdown": "false",

            "expected_up": "true",

            "is_dc": "true",

            "type": "member"

        },

        {

            "host": "10.10.12.3",

            "online": "true",

            "resources_running": "4",

            "standby": "false",

            "standby_onfail": "false",

            "maintenance": "false",

            "pending": "false",

            "unclean": "false",

            "shutdown": "false",

            "expected_up": "true",

            "is_dc": "false",

            "type": "member"

        }

    ],

    "started": "10.10.12.1",

    "role": "Started",

    "active": "true",

    "blocked": "false",

    "failed": "false"

},

"name": "statusResource",

"type": "dict"

}

VM85:704 ablestackJson.py : {"code": 200, "val": {"wall": "false"}, "name": "jsonStatus", "type": "dict"}

VM85:707 wallStatus.wall = false

VM85:710 wall false in

VM84:1720 step0 :: active, step1 :: true, step5 :: HEALTH_OK, step6 :: RUNNING, step7 :: true, step8 :: false, step11 :: true

VM85:957 license check update success

VM84:2020 keyscan ok

TechFlow-Assistant

올려주신 statusResource 결과의 active=true는 클라우드센터 리소스가 실행 중임을 보여 줍니다. 이는 CCVM의 Mold 웹 서비스가 8080 포트에서 응답한다는 검사 결과는 아닙니다. ccvm=true는 배포 상태값이며 HTTP 연결 성공을 뜻하지 않습니다. step8=false는 Wall 모니터링 구성 상태이므로 연결 실패의 직접 원인으로 단정하지 않겠습니다. Cube의 “클라우드센터 연결”은 각 Cube 호스트에서 ccvm-mngt를 주소로 해석하고 CCVM 관리 주소의 8080 포트에 HTTP GET을 보냅니다. 게시하신 “클라우드센터에 정상적으로 연결되지 않습니다” 문구는 이 요청에서 예외가 발생할 때 표시됩니다. 따라서 세 호스트의 동시 구성 자체보다 현재 Cube 호스트→CCVM 8080 연결 경로와 CCVM 안의 Mold 웹 서비스 응답을 먼저 확인해야 합니다.

먼저 다음 해결 방법을 적용해 보세요.

세 Cube 호스트에서 각각 관리자 계정으로 ssh -p <SSH_PORT> <ADMIN>@<CUBE_HOST_IP>에 접속하십시오. 다음 명령을 실행해 해석된 주소를 비교하고, 다음 명령을 실행하십시오. 정상 기준은 세 호스트가 의도한 같은 CCVM 관리 주소를 가리키고 HTTP 응답을 받는 것입니다. 연결 오류·시간 초과·주소 차이를 구분해 주세요. 브라우저의 화면 접속 결과만으로 Cube 호스트의 요청 성공을 판정하지 마십시오.

getent hosts ccvm-mngt
curl -sS -o /dev/null -w "%{http_code}\n" --connect-timeout 5 --max-time 10 http://ccvm-mngt:8080/

CCVM 관리 서버에는 ssh -p <SSH_PORT> <ADMIN>@<CCVM_MANAGEMENT_IP>로 접속하거나 Cube의 CCVM 콘솔을 사용하십시오. 관리자 권한에서 아래 명령의 8080 LISTEN 여부를 확인하십시오. 정상 기준은 Mold 서비스가 active (running)이고 CCVM 관리 주소의 8080 포트가 LISTEN인 것입니다. 서비스명이나 포트가 이 설치 버전에서 다르면 실제 설치된 Unit과 LISTEN 출력을 알려주세요.

sudo systemctl status mold.service --no-pager -l
sudo ss -ltnp

CCVM 관리 서버에서 같은 관리자 권한으로 실패 시각 전후의 다음 명령을 확인하십시오. 더 이전에 발생한 장애라면 두 시각을 실제 실패 시각 전후로 바꿔 조회하십시오. 세 Cube 호스트가 모두 실패하면 CCVM 서비스·관리망 경로를, 특정 호스트만 실패하면 그 호스트의 주소 해석·라우팅·방화벽 차이를 우선 비교하십시오. 정상 기준은 같은 시간대에 Mold 서비스 오류가 없고 세 호스트의 HTTP 요청이 응답하는 것입니다. 공유할 때 암호·토큰·쿠키와 내부 IP는 일관된 별칭으로 마스킹해 주세요.

sudo journalctl -u mold.service --since "-2 hours" --until "now" --no-pager

이 방법을 먼저 권장하는 이유는 다음과 같습니다.

제품 소스의 create_address.py cloudCenter 분기는 ccvm-mngt 주소에 HTTP GET을 보내며 연결 예외를 위 안내 문구로 표시합니다. statusResource의 code=200은 리소스 조회 성공이고 Mold HTTP 응답 코드가 아닙니다.

위 조치로 해결되지 않으면 아래 결과를 알려주세요. 이미 제공한 내용은 다시 보내지 않으셔도 됩니다.

이미 제공한 리소스 상태는 다시 보내지 않으셔도 됩니다. 세 Cube 호스트별 주소 해석 결과와 HTTP 상태 또는 연결 오류, CCVM의 Mold 서비스·8080 LISTEN 상태 및 실패 시각 전후 로그에서 첫 오류만 알려주시면 실패 지점을 좁힐 수 있습니다.

TechFlow-Assistant

증상

화면에 “클라우드센터에 정상적으로 연결되지 않습니다. 클라우드센터 서비스 상태를 확인하거나, 잠시 후에 다시 시도해주십시오.”라는 메시지가 표시되었습니다.
상태 출력에는 code: 200, ccvm: true와 클러스터 호스트 목록이 표시되었습니다.

원인

현재 근거에서 확인된 원인은 없습니다.

추가로 필요한 정보

getent, curl, 서비스 상태, 8080 LISTEN 상태 및 로그 결과가 대화에 없어 실제 장애 지점과 최종 복구 조치는 확인할 수 없습니다.

해결 방법

추가 동시 실행을 중단하고 한 호스트씩 확인합니다.

각 Cube 호스트에 관리자 계정으로 접속하여 주소 해석 결과와 HTTP 응답을 확인합니다. 세 호스트가 같은 CCVM 관리 주소를 가리키고 HTTP 상태 코드를 반환하면 정상입니다.

ssh -p <SSH_PORT> <ADMIN>@<CUBE_HOST_IP>

getent hosts ccvm-mngt
curl -sS -o /dev/null -w "%{http_code}\n" --connect-timeout 5 --max-time 10 http://ccvm-mngt:8080/

CCVM에 관리자 계정으로 접속하거나 Cube의 CCVM 콘솔을 사용하여 Mold 서비스와 8080 포트의 수신 상태를 확인합니다. 선택된 해결 환경에서는 mold.service를 사용했습니다. 해당 단위가 없다면 임의로 재시작하지 말고 실제 설치된 관리 서비스 이름을 확인합니다. 제품 문서에는 관리 서비스 식별자가 cloudstack-management로 안내되어 있습니다.

ssh -p <SSH_PORT> <ADMIN>@<CCVM_MANAGEMENT_IP>

sudo systemctl status mold.service --no-pager -l
sudo ss -ltnp

연결 실패 시각 전후의 서비스 로그를 확인합니다. 정상 기준은 같은 시간대에 Mold 서비스 오류가 없고 Cube 호스트의 HTTP 요청이 응답하는 것입니다. 공유할 때 암호, 토큰, 쿠키, 내부 IP, 호스트 이름은 일관된 별칭으로 마스킹합니다.

sudo journalctl -u mold.service --since "-2 hours" --until "now" --no-pager

추가 고려사항

별도의 추가 고려사항은 확인되지 않았습니다.

적용 버전

ABLESTACK Diplo

이 문서는 질문자가 해결 답변으로 선택한 내용을 중심으로 TechFlow가 대화를 정리한 Knowledge Base입니다.