IBM Cloud Pak® for Data 배치에 대한 IBM Watson® Discovery 카트리지 문제점 해결

제품을 사용하는 동안 발생할 수 있는 문제를 해결하는 방법을 학습합니다.

IBM Cloud Pak for Data

이 정보는 IBM Cloud Pak® for Data에 설치된 IBM Watson® Discovery 의 인스턴스에만 적용됩니다. 설치 및 관리 배치 모두에 데이터를 추가하는 데 대한 문제점 해결 팁은 수집 문제점 해결 을 참조하십시오.

이 주제의 정보는 발생할 수 있는 문제를 조사하기 위해 수행할 수 있는 단계를 제안합니다. 알려진 문제점 및 버전당 임시 해결책에 대한 정보는 알려진 문제점 을 참조하십시오.

Minio팟 (Pod) 은 설치 또는 업그레이드 중에 다시 부팅 루프를 시작합니다.

오류: Discovery의 설치 또는 업그레이드 중에 Cannot find volume "export" to mount into container "ibm-minio" 가 표시됩니다. When you check the status of the Minio pods by using the command, oc get pods -l release=wd-minio -o wide, and then check the Minio operator logs by using the commands, oc get pods -A | grep ibm-minio-operator, and then oc logs -n <namespace> ibm-minio-operator-XXXXX, you see an error similar to the following one in the logs:
```
ibm-minio/templates/minio-create-bucket-job.yaml failed: jobs.batch "wd-minio-discovery-create-bucket" already exists) and failed rollback: failed to replace object"
```
원인: Minio의 스토리지 버킷을 작성한 후 완료된 후 삭제되는 작업이 제대로 삭제되지 않습니다.
솔루션: 다음 단계를 완료하여 Minio에 대해 불완전한 create-bucket 작업이 있는지 확인하십시오. 그런 경우, 작업을 다시 작성하고 성공적으로 실행할 수 있도록 완료되지 않은 작업을 삭제하십시오.
1. 다음 명령을 사용하여 Minio 작업을 확인하십시오.
```
oc get jobs | grep 'wd-minio-discovery-create-bucket'
```
2. 응답에 기존 작업이 나열된 경우 다음 명령을 사용하여 작업을 삭제하십시오.
```
oc delete job $(oc get jobs -oname | grep 'wd-minio-discovery-create-bucket')
```
3. 다음 명령을 사용하여 모든 Minio팟 (Pod) 이 성공적으로 시작되는지 확인하십시오.
```
oc get pods -l release=wd-minio -o wide
```

`No space left on device` 메시지가 로그에 표시됩니다.

wd-ibm-elasticsearch-es-server-client 팟 (Pod) 이 반복적으로 다시 시작되고 팟 (Pod) 에 대한 로그에 기록된 No space left on device 메시지와 함께 Crashloopbackoff 상태를 보고하는 경우 팟 (Pod) 의 메모리가 부족할 수 있습니다. 단계에 따라 메모리 부족 문제 해결 을 수행하거나 IBM 지원 센터에 문의하십시오.

`java.lang.OutOfMemoryError: Java heap space` 메시지가 로그에 표시됩니다.

여러 인리치먼트가 적용된 대형 문서 세트를 인덱싱할 때 작업자 노드에 공간이 부족할 수 있습니다. 문제를 해결하려면 먼저 다음 단계를 완료하여 메모리가 부족한 팟 (Pod) 을 판별하십시오.

문서 상태를 Processing 로 승격할 수 없는 경우 inlet, outlet 및 converter 팟 (Pod) 의 상태를 확인하십시오.

다음 명령을 실행하십시오.

oc get pod -l 'tenant=wd,run in (inlet,outlet,converter)'

Running 상태를 표시하지 않는 팟 (Pod) 이 있는 경우 다음 명령을 사용하여 실패한 팟 (Pod) 을 다시 시작하십시오.
```
oc delete pod <pod_name>
```
그렇지 않으면 콜렉션 관리>{collection name}>활동 페이지를 여십시오. 경고 및 오류 개요 섹션에서 OutOfMemory happened during conversion. Please reconsider size of documents. 메시지가 표시되면 다음 명령을 사용하여 변환기의 메모리 크기를 늘리십시오.
```
oc patch wd wd --type=merge \
--patch='{"spec":{"ingestion":{"converter":b{"maxHeapMemory":"10240m","resources":{"limits":{"memory":"10Gi"}}}}}}'
```
클러스터 리소스에 따라 maxHeapMemory 및 컨테이너 메모리의 값을 조정하십시오.
converter 팟 (Pod) 이 다시 시작되면 활동 탭에서 재처리 를 클릭하십시오.

문서가 Processing 상태에 머물러 있고 콜렉션에 대해 Available 상태로 승격될 수 없는 경우 다음 단계를 완료하십시오.

Hadoop 의 상태를 확인하려면 다음 명령을 사용하십시오
```
oc get pod -l 'tenant=wd,run in (hdp-rm,hdp-worker)'
```
여기서 l 는 목록의 경우 소문자 L입니다.
Running 상태를 표시하지 않는 팟 (Pod) 이 있는 경우 다음 명령을 사용하여 실패한 팟 (Pod) 을 다시 시작하십시오.
```
oc delete pod <pod_name>
```
다음 명령을 사용하여 OOM when allocating 메시지를 찾아 Hadoop 작업자 노드에 메모리가 충분하지 않은지 확인하십시오.
```
oc logs -l tenant=wd,run=hdp-worker -c logger --tail=-1 \
| grep "OOM when allocating"
```
일치가 발견되면 다음 명령을 사용하여 자원을 패치하십시오.
```
oc patch wd wd --type=merge \
--patch='{"spec":{"orchestrator":{"docproc":{"pythonAnalyzerMaxMemory":"8g"}}}}'
```
pythonAnalyzerMaxMemory 에 허용되는 최대값은 12g 입니다. 기본값은 6g입니다. 값을 점진적으로 늘리십시오 (예: 클러스터 리소스에 따라 한 번에 2g 씩 증가).
다음 명령을 사용하여 OutOfMemoryError 메시지를 찾아 Hadoop 작업자 노드에 메모리가 충분하지 않은지 확인하십시오.
```
oc logs -l tenant=wd,run=hdp-worker -c logger --tail=-1 \
| grep "OutOfMemoryError"
```
일치하는 항목이 발견되면 다음 명령을 사용하여 현재 환경 변수 값 및 Hadoop 작업자 노드 메모리 리소스를 확인하십시오.
- 오케스트레이터 컨테이너에서 "DOCPROC_MAX_MEMORY" 변수를 확인하려면 다음을 수행하십시오.
```
oc exec `oc get po -l run=orchestrator -o 'jsonpath={.items[0].metadata.name}'` env \
| grep DOCPROC_MAX_MEMORY
```
- Hadoop 작업자 노드 컨테이너에서 "YARN_NODEMANAGER_RESOURCE_MEMORY_MB" 변수를 확인하려면 다음을 수행하십시오.
```
oc exec `oc get po -lrun=hdp-worker -o 'jsonpath={.items[0].metadata.name}'` \
-c hdp-worker -- env | grep YARN_NODEMANAGER_RESOURCE_MEMORY_MB
```
- hdp-worker 컨테이너의 메모리 자원을 확인하려면 다음을 수행하십시오.
```
oc get po -l run=hdp-worker -o 'jsonpath=requests are \
{.items[*].spec.containers[?(.name=="hdp-worker")].resources.requests.memory}, \
limits are {.items[*].spec.containers[?(.name=="hdp-worker")].resources.limits.memory}'
```
다음 명령을 사용하여 환경 변수 자원을 점진적으로 패치하십시오.
```
oc patch wd `oc get wd -o 'jsonpath={.items[0].metadata.name}'` \
--type=merge --patch='{"spec":{"orchestrator":{"docproc":{"maxMemory":"4g"}}, \
"hdp":{"worker":{"nm":{"memoryMB":12000}, "resources":{"limits":{"memory":"20Gi"}, \
"requests":{"memory":"20Gi"}}}}}}'
```
자원의 기본값은 다음과 같습니다.
- docproc.maxMemory: 2g
  
  한 번에 2g 씩 증가시킵니다.
- nm.memoryMB: 10 ,240
  
  12 ,000에서 시작하여 한 번에 2,000씩 증가합니다.
- memory requests/limits: 13Gi/18Gi
  
  한 번에 2Gi 씩 증가합니다.
다음 명령을 사용하여 Hadoop 팟 (Pod) 이 정상적으로 다시 시작되는지 확인하십시오.
```
oc get pods -l 'tenant=wd,run in (orchestrator,hdp-worker)'
```
클러스터를 패치한 후 새 구성이 적용되었는지 확인하십시오.
팟 (Pod) 이 다시 시작되지 않으면 다음 명령을 사용하여 리소스가 업데이트되었는지 확인하십시오.
```
oc get wd wd -o yaml
```
클라이언트 및 데이터 노드를 별도로 확인하여 Elasticsearch 의 상태를 확인하십시오.
클라이언트 노드에서 다음 명령을 실행하여 메모리 부족 예외가 발생했는지 확인하십시오.
```
oc logs -l tenant=wd,ibm-es-data=False,ibm-es-master=False \
-c elasticsearch --tail=-1 | grep "OutOfMemoryError"
```

INFO 메시지를 제외한 오류 메시지가 발견되면 다음 명령을 사용하여 메모리 자원을 늘리십시오.

oc patch wd wd --type=merge \
--patch='{"spec":{"elasticsearch":{"clientNode":{"maxHeap":"896m","resources":{"limits":{"memory":"1792Mi"}}}}}}'

이 명령을 실행하면 약 20분 후에 Elasticsearch 클라이언트 팟 (Pod) 이 다시 시작됩니다. 다음 명령을 사용하여 팟 (Pod) 의 "AGE" 를 모니터하십시오.
```
oc get pod -l tenant=wd,ibm-es-data=False,ibm-es-master=False
```
팟 (Pod) 이 성공적으로 다시 시작된 후 다음 명령을 사용하여 ES_JAVA_OPTS 의 새 값 및 컨테이너 메모리 한계를 확인하십시오.
```
oc describe $(oc get po -l tenant=wd,ibm-es-data=False,ibm-es-master=False -o name)
```

데이터 노드에서 다음 명령을 실행하여 메모리 부족 예외가 발생했는지 확인하십시오.

oc logs -l tenant=wd,ibm-es-data=True,ibm-es-master=False \
-c elasticsearch --tail=-1 | grep "OutOfMemoryError"

INFO 메시지를 제외한 오류 메시지가 발견되면 다음 명령을 사용하여 메모리 자원을 늘리십시오.

oc patch wd wd --type=merge \
--patch='{"spec":{"elasticsearch":{"dataNode":{"maxHeap":"6g","resources":{"limits":{"memory":"10Gi"},"requests":{"memory":"8Gi"}}}}}}'

이 명령을 실행하면 약 20분 후에 Elasticsearch 클라이언트 팟 (Pod) 이 다시 시작됩니다. 다음 명령을 사용하여 팟 (Pod) 의 "AGE" 를 모니터하십시오.
```
oc get pod -l tenant=wd,ibm-es-data=True,ibm-es-master=False
```
팟 (Pod) 이 다시 시작되면 다음 명령을 사용하여 ES_JAVA_OPTS 의 새 값 및 컨테이너 메모리 요청/한계를 확인하십시오.
```
oc describe $(oc get po -l tenant=wd,ibm-es-data=True,ibm-es-master=False -o name)
```
두 노드 (클라이언트 및 데이터) 모두에 대해 resources.limits.memory 를 2 * maxHeap 와 동일하게 설정하십시오.

oc patch 명령을 적용하여 30분 후에 팟 (Pod) 을 다시 시작할 수 없는 경우 다음 명령을 사용하여 IBM 지원 센터와 공유할 로그를 수집하십시오.
```
oc logs -l control-plane=ibm-es-controller-manager --tail=-1
```

문서 상태가 Processing 로 승격될 수 없고 문서가 Processing 상태에 머물러 있는 두 문제 모두에 대해 Portworx 스토리지를 사용 중인 경우 Elasticsearch 디스크가 가득 찼는지 여부를 확인할 수 있습니다.

Elasticsearch 디스크가 꽉 찼는지 확인하려면 다음 명령을 실행하십시오

oc logs -l tenant=wd,run=elastic,ibm-es-master=True \
-c elasticsearch --tail=100000|grep 'disk watermark'

로그에 watermark exceeded on x-data-1 와 같은 메시지가 표시되면 지정된 노드의 디스크가 가득 찼음을 의미하며 다음 명령을 사용하여 디스크 크기를 늘려야 합니다.
```
oc patch pvc $(oc get pvc -l tenant=wd,run=elastic,ibm-es-data=True,ibm-es-master=False \
-o jsonpath='{.items[N].metadata.name}') \
-p '{"spec": {"resources": {"requests":{"storage": "60Gi"}}}}'
```
여기서 N 는 로그에서 보고된 데이터 노드 번호를 나타냅니다.

예를 들어, 로그가 노드 이름에서 data-1 를 언급하는 경우 사용할 명령은 다음과 같습니다.
```
oc patch pvc $(oc get pvc -l tenant=wd,run=elastic,ibm-es-data=True,ibm-es-master=False \
-o jsonpath='{.items[1].metadata.name}') -p '{"spec": {"resources": {"requests":{"storage": "60Gi"}}}}'
```

Discovery for Cloud Pak for Data의 샤드 한계 설정

Discovery 의 버전 4.0 에서는 클러스터에 열려 있을 수 있는 샤드의 수에 제한이 있습니다. 개발 인스턴스에서 한계는 1,000개의 열린 샤드이고 프로덕션 인스턴스에서 한계는 두 개의 데이터 노드입니다. 이는 2,000개의 열린 샤드 또는 데이터 노드당 1,000개의 열린 샤드와 동일합니다. 한계에 도달하면 더 이상 클러스터에서 더 많은 프로젝트 및 콜렉션을 작성할 수 없으며, 새 프로젝트 및 콜렉션을 작성할 경우 오류 메시지를 수신합니다.

이 제한은 Discovery 버전 4.0 를 설치할 때 Elasticsearch 버전 7.10.2 가 클러스터에서 자동으로 실행되기 때문입니다. 이 버전의 Elasticsearch가 클러스터에서 실행되므로, Elasticsearch 데이터 노드당 열린 샤드 수의 한계가 1,000개인 새 클러스터 안정성 구성을 사용할 수 있습니다.

새 프로젝트 및 콜렉션을 작성할 수 없고 오류를 수신하면 먼저 Elasticsearch 클러스터의 상태와 해당 클러스터의 샤드 수를 확인하십시오. 더 많은 샤드를 지원하기 위해 클러스터의 데이터 노드 수를 늘릴 것을 고려하십시오. 이 방법은 성능을 최적화하는 데 최적입니다. 그러나 노드 수가 늘어나면 더 많은 메모리를 사용합니다. 샤드 수가 한계에 도달하는 경우 데이터 노드의 한계를 늘릴 수도 있습니다. 노드의 샤드 한계 늘리기에 대한 자세한 정보는 샤드 한계 늘리기를 참조하십시오.

이 1,000개의 샤드 한계는 4.0 이상인 Discovery 버전에 적용됩니다.

샤드 한계 늘리기

Discovery 클러스터에 로그인하십시오.
데이터 노드에 액세스하십시오.

다음 명령을 입력하십시오.

oc exec -it $(oc get pod \
-l app=elastic,ibm-es-data=True -o jsonpath='{.items[0].metadata.name}') -- bash

<> 를 포트 번호로 바꾸고 그 안에 있는 내용을 입력하십시오
```
curl -X POST http://localhost:<port_number>/_cluster/health?pretty
```
포트 번호를 모르면 다음 명령을 입력하여 찾으십시오.
```
oc get pod -l app=elastic,ibm-es-data=True -o json \
| jq .items[].spec.containers[].ports[0].containerPort | head -n 1`
```
curl POST 명령은 active_primary_shards의 값을 리턴합니다. 값이 1,000보다 큰 하나의 데이터 노드가 있거나 값이 2,000보다 더 큰 두 개의 데이터 노드가 있는 경우 클러스터에서 새 프로젝트 및 콜렉션을 작성하도록 샤드 한계를 늘려야 합니다.

이 한계를 늘리면 늘어난 샤드 수가 포함되므로 클러스터의 안정성이 감소합니다.
다음 명령을 입력하여 샤드 수를 늘리십시오. 여기서 <port_number> 는 포트 번호로, <total_shards_per_node> 와 <max_shards_per_node> 는 노드에 할당할 새로운 샤드 제한으로 대체하십시오
```
curl -X POST http://localhost:<port_number>/_cluster/settings \
-d '{"persistent": {"cluster.routing.allocation.total_shards_per_node":<total_shards_per_node>, \
"cluster.max_shards_per_node":<max_shards_per_node>} }' \
-XPUT -H 'Content-Type:application/json'
```
샤드 한계를 늘린 후에는 클러스터에서 더 많은 프로젝트 및 콜렉션을 작성할 수 있습니다.

잠금 상태 해제

IBM Cloud Pak for Data 설치된 경우에만: gateway 포드가 다시 시작되면, 변경 사항을 확인하고 공유 데이터베이스에 최신 변경 세트를 적용하는 데이터베이스 검증 플러그인을 실행합니다. 이 검사가 진행되는 동안 포드가 다시 시작되면 플러그인이 잠금 상태에 머물러 서비스 시작이 불가능할 수 있습니다. 잠금을 해제하려면 수동으로 데이터베이스에 개입해야 할 수도 있습니다.

Discovery API가 온라인 상태가 되지 않거나, gateway-0 포드가 계속 충돌하는 것처럼 보인다면, 여기에서 API 서비스에 대한 Liberty 서버 로그를 확인해 볼 수 있습니다. /opt/ibm/wlp/output/wdapi/logs/messages.log

로그를 통해 Liquibase가 실패하고 실행할 수 없는지 여부를 알 수 있습니다. 시스템이 잠겨 있는 경우, 다음과 유사한 메시지가 표시될 수 있습니다

[11/7/19 5:07:51:491 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:07:51:593 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:01:601 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:02:091 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:12:097 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT LOCKED FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:12:197 UTC] 0000002f liquibase.lockservice.StandardLockService I Waiting for changelog lock....
[11/7/19 5:08:22:203 UTC] 0000002f liquibase.executor.jvm.JdbcExecutor I SELECT ID,LOCKED,LOCKGRANTED,LOCKEDBY FROM public.databasechangeloglock WHERE ID=1
[11/7/19 5:08:22:613 UTC] 0000002f com.ibm.ws.logging.internal.impl.IncidentImpl I FFDC1015I: An FFDC Incident has been created: "org.jboss.weld.exceptions.DeploymentException: WELD-000049: Unable to invoke public void liquibase.integration.cdi.CDILiquibase.onStartup() on liquibase.integration.cdi.CDILiquibase@7f02a07 com.ibm.ws.container.service.state.internal.ApplicationStateManager 31" at ffdc\_19.11.07\_05.08.22.0.log

플러그인을 수동으로 잠금 해제할 수 있습니다. Discovery 2.1.4 이하가 있는 경우, gateway-0 팟 (Pod) 이 보고 있는 postgres 데이터베이스에서 다음 명령을 입력하십시오.

psql dadmin
UPDATE DATABASECHANGELOGLOCK SET LOCKED=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1;

Discovery 2.2.0 이상이 있는 경우, gateway-0 팟 (Pod) 이 보고 있는 postgres 데이터베이스에서 다음 명령을 입력하십시오.

oc exec -it wd-discovery-postgres-0 -- bash -c 'env PGPASSWORD="$PG_PASSWORD" psql "postgresql://$PG_USER@$STKEEPER_CLUSTER_NAME-proxy-service:$STKEEPER_PG_PORT/dadmin" -c "UPDATE DATABASECHANGELOGLOCK SET LOCKE
D=FALSE, LOCKGRANTED=null, LOCKEDBY=null where ID=1"'

gateway 를 다시 시작할 수 있다면 모든 것이 정상적으로 재개될 것입니다.

SDU(Smart Document Understanding)에 대한 환경 변수 설정

IBM Watson® Discovery 버전 2.1.0 에서 스마트 문서 이해를 위해 조정해야 하는 환경 변수가 두 가지 있습니다. 이는 2.1.1 버전에서 해결되었습니다. 2020년 1월 24일 2.1.1 릴리스를 참조하십시오.

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS
SDU_YOLO_TIMEOUT_SEC

이 두 가지 모두 각각의 hour 값으로 설정해야 합니다. 이 값들은 <release-name>-watson-discovery-hdp ConfigMap 에서 설정해야 합니다.

값은 다음과 같아야 합니다.

SDU_PYTHON_REST_RESPONSE_TIMEOUT_MS 설정값 3600000

SDU_YOLO_TIMEOUT_SEC 설정값 3600

이러한 값은 소프트웨어를 설치하거나 다시 설치할 때 설정해야 합니다.

오류 메시지 문제점 해결

강화를 위한 제한시간 및 충분하지 않은 메모리와 관련된 오류 메시지를 수신하는 경우 다음 명령을 입력하여 제한시간 및 메모리 설정을 변경함으로써 잠재적으로 이 오류 메시지를 해결할 수 있습니다.

알림 메시지: <enrichment_name>: Document enrichment timed out

제안되는 조치: 문서 처리 제한시간을 늘리십시오. 다음 명령을 입력하여 기본 제한시간을 10분에서 20분으로 늘리십시오.
```
oc patch wd wd --type=merge \
--patch='{"spec": {"orchestrator": {"docproc": {"defaultTimeoutSeconds": 1200 } } } }'
```
알림 메시지: <enrichment_name>: Document enrichment failed due to lack of memory

제안되는 조치: 오케스트레이터 컨테이너 메모리 한계를 늘리십시오. 다음 명령을 입력하여 메모리 한계를 4Gi에서 6Gi로 늘리십시오.
```
oc patch wd wd --type=merge \
--patch='{"spec": {"orchestrator": {"resources": {"limits": {"memory": "6Gi"} } } } }'
```
알림 메시지: Indexing request timed out

제안되는 조치: Elasticsearch에 대한 문서를 푸시하도록 제한시간을 늘리십시오. 다음 명령을 입력하여 기본 제한시간을 10분에서 20분으로 늘리십시오.
```
oc patch wd wd --type=merge \
--patch='{"spec": {"shared": {"elastic": {"publishTimeoutSeconds": 1200 } } } }'
```

IBM Cloud Pak® for Data 배치에 대한 IBM Watson® Discovery 카트리지 문제점 해결

IBM Cloud Pak® for Data 배치에 대한 IBM Watson® Discovery 카트리지 문제점 해결

Minio팟 (Pod) 은 설치 또는 업그레이드 중에 다시 부팅 루프를 시작합니다.

No space left on device 메시지가 로그에 표시됩니다.

java.lang.OutOfMemoryError: Java heap space 메시지가 로그에 표시됩니다.

Discovery for Cloud Pak for Data의 샤드 한계 설정

샤드 한계 늘리기

잠금 상태 해제

SDU(Smart Document Understanding)에 대한 환경 변수 설정

오류 메시지 문제점 해결

`No space left on device` 메시지가 로그에 표시됩니다.

`java.lang.OutOfMemoryError: Java heap space` 메시지가 로그에 표시됩니다.