Apigee 및 Apigee Hybrid 문서입니다.
이 주제에 해당하는 Apigee Edge 문서가 없습니다.
증상
Apigee Hybrid에서 Cassandra 복원을 수행하는 동안 복원 로그에 오류가 표시될 수 있습니다.
오류 메시지
로그에 다음 중 하나가 표시됩니다.
java.net.ConnectException: Connection timed out (Connection timed out)
/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1
/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists
가능한 원인
원인 | 설명 | 다음에 관한 문제 해결 안내 |
---|---|---|
연결 시간 초과 |
이 오류는 apigee-cassandra-restore 포드와 apigee-cassandra-default-* 포드 간의 연결 오류입니다.
|
Apigee Hybrid |
작업 시간을 초과했습니다. | 이 오류는 15분 후 복원이 타임아웃되면 발생합니다. | Apigee Hybrid |
이미 존재함 | 이 오류 메시지는 문제의 원인과 관련이 없으며 복원 작업 재시도 작업의 결과입니다. | Apigee Hybrid |
원인: 연결 타임아웃
다음 오류는 apigee-cassandra-restore
포드와 apigee-cassandra-default-*
포드 간의 연결 오류입니다.
java.net.ConnectException: Connection timed out (Connection timed out)
진단
-
포드 네트워크에서 호스트 네트워크에 연결할 수 없는 경우
백업에서 리전 복원에 나와 있는 것처럼
overrides.yaml
의cassandra
아래에서hostNetwork
가false
로 설정되어 있는지 확인합니다. -
연결을 테스트하려면
apigee-cassandra-restore
작업과 동일한 네트워크에 있는apigee-mart
또는apigee-runtime
포드에 로그인합니다. 포드 네트워크에서 다른 포드를 사용할 수도 있습니다.-
apigee-mart
포드의 이름을 가져옵니다.kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
-
mart 포드 내에서 bash 세션을 실행합니다.
kubectl exec -it MART_POD_NAME -n apigee -- bash
MART_POD_NAME을 MART 포드의 이름으로 바꿉니다. 예를 들면
apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl
입니다. - Cassandra 포트에 대해 연결 테스트를 실행합니다.
curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:9042
curl -v -m 5 telnet://apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local:7001
출력에
Connection timed out
오류가 표시되면 연결 문제가 있는 것입니다. 하지만Connected to
메시지가 표시되면 연결에 성공한 것입니다. Ctrl+C를 눌러 연결을 닫고 계속 진행해야 합니다. -
해결 방법
복원에 사용되는 overrides.yaml
파일에서 HostNetwork
설정이 false
로 설정되어 있는지 확인하고 복원 프로세스를 반복합니다. 설정이 이미 false
로 설정되어 있지만 연결 오류가 표시되면 다음 명령어를 사용하여 Cassandra 포드가 작동되어 실행되는지 확인합니다.
kubectl get pods -n apigee -l app=apigee-cassandra
다음 예시와 같은 출력이 표시됩니다.
NAME READY STATUS RESTARTS AGE apigee-cassandra-default-0 1/1 Running 0 14m apigee-cassandra-default-1 1/1 Running 0 13m apigee-cassandra-default-2 1/1 Running 0 11m exampleuser@example hybrid-files %
원인: 작업 타임아웃
15분 후 복원이 타임아웃되면 다음 오류가 발생합니다. 이 오류는 스토리지 및 네트워크가 압축되지 않은 백업 내용을 제시간에 전송할 수 없는 등의 I/O 문제를 나타냅니다.
/tmp/tmp/schema.cql:662:OperationTimedOut: errors={'10.0.0.1': 'Client request timeout. See Session.execute[_async](timeout)'}, last_host=10.0.0.1
진단
-
apigee-cassandra-default-0
로그에서 복원 시작의 타임스탬프를 확인합니다.kubectl logs apigee-cassandra-default-0 -n apigee | grep 'MigrationManager.java' | head -n 1
-
타임스탬프를 테이블 생성의 최신 로그와 비교합니다.
kubectl logs apigee-cassandra-default-0 -n apigee | grep 'Create new table' | tail -n 1
이 비교 결과는 Cassandra 포드가 제한 시간을 초과한 후에도 테이블을 만드는 중임을 보여줍니다.
-
다음 명령어를 사용하여 스토리지 대역폭을 테스트합니다.
kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'
kubectl -n apigee exec -it apigee-cassandra-default-1 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'
kubectl -n apigee exec -it apigee-cassandra-default-2 -- bash -c 'dd if=/dev/zero of=/opt/apigee/data/test.img bs=200M count=1 ; rm /opt/apigee/data/test.img'
쓰기 속도가 100M/s 미만이면 사용된 적절한 StorageClass(SSD)가 부족하다는 의미일 수 있습니다.
-
네트워킹 대역폭을 테스트합니다.
-
Cassandra 포드에서
netcat
을 실행하여 포트에서 리슨합니다.kubectl -n apigee exec -it apigee-cassandra-default-0 -- bash -c 'nc -l -p 3456 > /dev/null'
-
별도의 셸 세션에서
apigee-mart
포드 이름을 가져옵니다.kubectl -n apigee get po --selector=app=apigee-mart --no-headers -o custom-columns=":metadata.name"
-
apigee-mart
포드 내에서 bash 세션을 실행합니다. 포드 네트워크에서 다른 포드를 사용할 수도 있습니다.kubectl exec -it MART_POD_NAME -n apigee -- bash
MART_POD_NAME을 MART 포드의 이름으로 바꿉니다. 예를 들면
apigee-mart-myorg--9a8228a-191-t0xh1-qz5fl
입니다. -
아직
netcat
을 실행 중인 Cassandra 포드에 대해 네트워크 대역폭 테스트를 실행합니다.dd if=/dev/zero bs=50M count=1 | nc apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local 3456
다른 Cassandra 포드에 대해 이 프로세스를 반복할 수 있습니다. 결과 속도가 10M/s 미만이면 네트워크 대역폭이 문제 원인일 가능성이 가장 높습니다.
-
해결 방법
위 단계를 통해 느린 I/O 속도가 확인되면 클러스터가 최소 네트워크 및 스토리지 요구사항을 충족하는지 확인합니다. 나중에 대역폭을 다시 테스트합니다.
원인: 이미 존재함
진단
다음과 비슷한 오류가 표시됩니다.
/tmp/tmp/schema.cql:6409:AlreadyExists: Table 'kvm_myorg.kvm_map_keys_descriptor' already exists
해결 방법
이 오류 메시지는 문제의 원인과 관련이 없으며 복원 작업 재시도 작업의 결과입니다. 실제 오류 메시지는 실패한 첫 번째 포드의 로그에 표시됩니다.
문제를 진단하려면 초기 실패에서 로그를 가져옵니다.
문제가 계속되면 진단 정보를 수집해야 함으로 이동합니다.
진단 정보 수집 필요
위 안내를 따른 후에도 문제가 지속되면 다음 진단 정보를 수집한 후 Google Cloud Customer Care에 문의하세요.
-
요청 받은 일반적인 데이터 외에도 다음 명령어를 사용하여 모든 Cassandra Pod에서 진단 데이터를 수집합니다.
for p in $(kubectl -n apigee get pods -l app=apigee-cassandra --no-headers -o custom-columns=":metadata.name") ; do \ for com in info describecluster failuredetector version status ring info gossipinfo compactionstats tpstats netstats cfstats proxyhistograms gcstats ; do kubectl \ -n apigee exec ${p} -- bash -c 'nodetool -u $APIGEE_JMX_USER -pw $APIGEE_JMX_PASSWORD '"$com"' 2>&1 '\ | tee /tmp/k_cassandra_nodetool_${com}_${p}_$(date +%Y.%m.%d_%H.%M.%S).txt | head -n 40 ; echo '...' ; done; done
-
압축하고 지원 케이스에 제공합니다.
tar -cvzf /tmp/cassandra_data_$(date +%Y.%m.%d_%H.%M.%S).tar.gz /tmp/k_cassandra_nodetool*
- 복원 포드에서 로그를 수집하고 제공합니다. 로그는 단기 지속되므로 실패 직후에 수집해야 합니다.
- 위의 진단 단계를 수행한 경우 모든 콘솔 출력을 수집하여 파일로 복사하고 지원 케이스에 첨부합니다.