--- schema_version: "1" id: da1341453969f9d0e7aba56859804f85d6de3e356c07881fdbcc91a1c1a9796b title: 7부 - 유효성 검사, 도구 및 문제 해결 collection: tableau version: current locale: ko-kr portal_url: https://docs.salesforce.com/tableau/current/ko-kr/guides/enterprise-deployment/edg_part7.md canonical_url: https://help.tableau.com/current/guides/enterprise-deployment/ko-kr/edg_part7.htm source_site: help.tableau.com content_type: documentation content_hash: 619c6afb737ceb88cec5d1848b45eb639c7e214105914e49f774fc294520227a description: "Part 7: validate, troubleshoot, and recover the enterprise deployment, including failover." --- [주요 콘텐츠로 건너뛰기](#main-content) # 7부 - 유효성 검사, 도구 및 문제 해결 **참고**: Tableau는 더 이상 엔터프라이즈 배포 가이드를 업데이트하지 않습니다. AWS에서 Tableau Server를 배포하기 위한 유효한 모델로는 본 문서에 설명된 참조 아키텍처를 계속 권장하지만, 마지막 업데이트 이후 특정 구성 절차가 변경되었을 수 있습니다. 정확성을 보장하려면 항상 최신 [Tableau Server 도움말](https://help.tableau.com/current/server/ko-kr/get_started_server.htm) 설명서에 명시된 단계를 상호 참조하십시오. 이 항목에는 설치 후 검증 단계 및 문제 해결 지침이 수록되어 있습니다. ## 장애 조치 시스템 검증 배포를 구성한 후에는 간단한 장애 조치 테스트를 실행하여 시스템 이중화를 검증하는 것이 좋습니다. 다음 단계를 실행하여 장애 조치 기능을 검증하는 것이 좋습니다. 1. 독립 게이트웨이(TSIG1)의 첫 번째 인스턴스를 종료합니다. 모든 인바운드 트래픽은 독립 게이트웨이(TSIG2)의 두 번째 인스턴스를 통해 라우팅되어야 합니다. 2. TSIG1을 다시 시작한 다음 TSIG2를 종료합니다. 모든 인바운드 트래픽은 TSIG1을 통해 라우팅되어야 합니다. 3. TSIG2를 다시 시작합니다. 4. Tableau Server 노드 1을 종료합니다. 모든 Vizportal/응용 프로그램 서비스 트래픽이 노드 2로 장애 조치됩니다. **참고:** 2022년 9월부터 Tableau Server 2021.4 이상의 특정 버전에서는 노드 1 고가용성이 저하됩니다. 노드 1이 중단되면 클라이언트 연결이 실패합니다. 이 문제는 다음 유지 관리 버전에서 해결되었습니다. \- 2021.4.15 이상 \- 2022.1.11 이상 \- 2023.1.3 이상 ATR 활성화를 사용하는 Tableau Server 설치에 초기 노드 오류가 발생한 후 72시간의 유예 기간을 가지려면 이러한 버전 중 하나를 설치하거나 업그레이드하십시오. 자세한 내용은 Tableau 기술 자료에서 [ATR을 사용하는 Tableau Server HA에 초기 노드 오류 후 유예 기간이 없음](https://kb.tableau.com/articles/issue/tableau-server-ha-using-atr-does-not-have-a-grace-period-after-the-initial-node-failure?lang=ko-kr "고가용성 실패에 대한 Tableau KB 문서")을 참조하십시오. 5. 노드 1을 다시 시작하고 노드 2를 종료합니다. 모든 Vizportal/응용 프로그램 서비스 트래픽이 노드 1로 장애 조치됩니다. 6. 노드 2를 다시 시작합니다. 이 맥락에서 "종료" 또는 "다시 시작"은 응용 프로그램을 미리 정상적으로 종료하지 않고 운영 체제 또는 가상 컴퓨터를 끄는 방식으로 수행합니다. 이 작업의 목표는 하드웨어 또는 가상 컴퓨터 장애를 시뮬레이션하는 것입니다. 각 장애 조치 테스트의 최소 검증 단계는 사용자를 인증하고 기본적인 보기 작업을 수행하는 것입니다. 장애를 시뮬레이션한 후 로그인을 시도할 때 "잘못된 요청" 브라우저 오류가 발생할 수 있습니다. 브라우저에서 캐시를 지우는 경우에도 이 오류가 나타날 수 있습니다. 이 문제는 주로 브라우저가 이전 IdP 세션의 데이터를 캐싱할 때 발생합니다. 로컬 브라우저 캐시를 지워도 이 오류가 계속되면 다른 브라우저로 연결하여 Tableau 시나리오의 유효성을 검사하십시오. ## 초기 노드 자동 복구 Tableau Server 버전 2021.2.4 이상에는 스크립트 디렉터리(`/app/tableau_server/packages/scripts.`)에 자동화된 초기 노드 복구 스크립트인 `auto-node-recovery`가 포함되어 있습니다. 초기 노드에 문제가 있고 노드 2에 중복 프로세스가 있는 경우 Tableau Server가 계속 실행된다는 보장이 없습니다. Tableau Server는 초기 노드 장애 발생 후 최장 72시간 동안 계속 실행될 수 있으며, 그 이후에는 라이선스 서비스가 부족하여 다른 프로세스에 영향을 미칠 수 있습니다. 이러한 경우 사용자는 초기 노드에 장애가 발생한 후에도 계속 로그인하고 자신의 콘텐츠를 보고 사용할 수 있지만 관리 컨트롤러에 액세스할 수 없기 때문에 Tableau Server를 다시 구성할 수 없습니다. 중복 프로세스로 구성된 경우에도 초기 노드에 장애가 발생한 후 Tableau Server가 계속 작동하지 않을 수 있습니다. Tableau 초기 노드(노드 1) 오류를 복구하려면: 1. Tableau Server 노드 2에 로그인합니다. 2. 스크립트 디렉터리로 변경합니다. cd /app/tableau\_server/packages/scripts. 3. 다음 명령을 실행하여 스크립트를 시작합니다. sudo ./auto-node-recovery -p node1 -n node2 -k 여기서 ``는 배포의 쉼표로 구분된(공백 없음) 라이선스 키 목록입니다. 라이선스 키에 액세스할 수 없는 경우 [Tableau 고객 포털](http://customer.tableausoftware.com/?_fsi=v45oWMAM)을 방문하여 해당 키를 검색하십시오. 예를 들면 다음과 같습니다. sudo ./auto-node-recovery -p node1 -n node2 -k TSB4-8675-309F-TW50-9RUS,TSNM-559N-ULL6-22VE-SIEN auto-node-recovery 스크립트는 약 20단계를 실행하여 서비스를 노드 2로 복구합니다. 스크립트가 진행됨에 따라 각 단계가 터미널에 표시됩니다. 자세한 상태는 `/data/tableau_data/logs/app-controller-move.log`에 기록됩니다. 대부분의 환경에서 스크립트를 완료하는 데 35분에서 45분 정도 걸립니다. ### 초기 노드 복구 문제 해결 노드 복구가 실패하면 대화형으로 스크립트를 실행하여 유용한 프로세스에서 개별 단계를 허용하거나 허용하지 않을 수 있습니다. 예를 들어 스크립트가 프로세스 도중에 실패할 경우 로그 파일을 검토하고 구성을 변경한 다음 스크립트를 다시 실행할 수 있습니다. 대화형 모드로 실행하면 실패한 단계에 도달할 때까지 모든 단계를 건너뛸 수 있습니다. 대화형 모드로 실행하려면 script 인수에 `-i` 스위치를 추가합니다. ### 장애가 발생한 노드를 다시 구축 스크립트를 실행한 후에는 이전에 장애가 발생한 노드 1 호스트에 있었던 모든 서비스가 노드 2에서 실행됩니다. 4노드에서 추가하려면 부트스트랩 파일을 사용하여 새로운 Tableau Server 호스트를 배포하고 4부에 명시된 대로 원래 노드 2에 했던 것과 동일하게 구성합니다. 자세한 내용은 [노드 2 구성](https://help.tableau.com/current/guides/enterprise-deployment/ko-kr/edg_part4.htm#Configur2)을 참조하십시오. ## switchto switchto는 창 간 전환을 손쉽게 하는 Tim의 스크립트입니다. 1. 배스천 호스트의 홈 디렉터리에 있는 `switchto` 파일에 다음 코드를 복사합니다. #!/bin/bash #------------------------------------------------------------------- # switchto # # Helper function to simplify SSH into the various AWS hosts when # following the Tableau Server Enterprise Deployment Guide (EDG). # # Place this file on your bastion host and provide your AWS hosts' # internal ip addresses or machine names here. # Example: readonly NODE1="10.0.3.187" # readonly NODE1="" readonly NODE2="" readonly NODE3="" readonly NODE4="" readonly PGSQL="" readonly PROXY1="" readonly PROXY2="" usage() { echo "Usage: switchto.sh \[ node1 | node2 | node3 | node4 | pgsql | proxy1 | proxy2 \]" } ip="" case $1 in node1) ip="$NODE1" ;; node2) ip="$NODE2" ;; node3) ip="$NODE3" ;; node4) ip="$NODE4" ;; pgsql) ip="$PGSQL" ;; proxy1) ip="$PROXY1" ;; proxy2) ip="$PROXY2" ;; ?) usage exit 0 ;; \*) echo "Unkown option $1." usage exit 1 ;; esac if \[\[ -z $ip \]\]; then echo "You must first edit this file to provide the ip addresses of your AWS hosts." exit 1 fi ssh -A ec2-user@$ip 3. 스크립트의 IP 주소를 업데이트하여 EC2 인스턴스에 매핑한 후 파일을 저장합니다. 4. 스크립트 파일에 사용 권한을 적용합니다. sudo chmod +x switchto 사용법: 호스트를 전환하려면 다음 명령을 실행합니다. `./switchto ` 예를 들어 노드 1로 전환하려면 다음 명령을 실행합니다. `./switchto node1` ## Tableau Server 독립 게이트웨이 문제 해결 Tableau Server에서 독립 게이트웨이, Okta, Mellon 및 SAML을 구성하는 프로세스에서는 오류가 많이 발생할 수 있습니다. 실패의 가장 일반적인 근본 원인은 문자열 오류입니다. 예를 들어 구성 중에 지정된 Okta URL의 후행 슬래시(`/`)로 인해 SAML 어설션 관련 불일치 오류가 발생할 수 있습니다. 이 오류는 한 가지 예입니다. 구성 중에 어떤 응용 프로그램에서든 잘못된 문자열을 입력하게 될 가능성이 많습니다. ### tableau-tsig 서비스 다시 시작 항상 독립 게이트웨이 컴퓨터에서 tableau-tsig 서비스를 다시 시작하는 것으로 문제 해결 작업을 시작합니다. 이 서비스는 빠르게 다시 시작되며 다시 시작하면 Tableau Server에서 업데이트된 구성이 로드됩니다. 독립 게이트웨이 컴퓨터에서 다음 명령을 실행합니다. sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### 잘못된 문자열 찾기 문자열 오류(복사/붙여넣기 실수, 문자열 잘림 등)가 있는 경우 구성한 각 설정을 검토하십시오. - Okta 사전 인증 구성. 설정한 URL을 주의 깊게 검토합니다. 후행 슬래시가 있는지 확인합니다. HTTP와 HTTPS를 비교하여 확인합니다. - 노드 1의 SAML 구성에 대한 셸 기록. 실행한 `tsm authentication saml configure` 명령을 검토합니다. 모든 URL이 Okta에 구성된 것과 일치하는지 확인합니다. 노드 1에서 셸 기록을 검토하는 동안 Mellon 구성 파일 경로를 지정하는 `tsm configuration set` 명령이 독립 게이트웨이에서 파일을 복사한 파일 경로에 정확히 매핑되는지 확인합니다. - 독립 게이트웨이의 Mellon 구성. 셸 기록을 검토하여 Okta 및 Tableau SAML에서 구성한 것과 동일한 URL 문자열로 메타데이터를 만들었는지 확인합니다. `/etc/mellon/conf.d/global.conf`에 지정된 모든 경로가 올바르고 `MellonCookieDomain`이 Tableau 하위 도메인이 아닌 루트 도메인으로 설정되어 있는지 확인합니다. ### 관련 로그 검색 모든 문자열이 올바르게 설정된 것으로 보이면 로그에서 오류를 검사해야 합니다. Tableau Server는 수십 개의 서로 다른 로그 파일에 오류 및 이벤트를 기록합니다. 독립 게이트웨이는 로컬 파일 집합에도 로그를 기록합니다. 이러한 로그를 검사할 때는 다음 순서를 따르는 것이 좋습니다. #### 독립 게이트웨이 로그 파일 독립 게이트웨이 로그 파일의 기본 위치는 `/var/opt/tableau/tableau_tsig/logs`입니다. - `access.log`: 이 로그는 Tableau Server 노드의 연결을 보여주는 항목이 있는 경우 유용합니다. TSM을 시작하려고 할 때 게이트웨이 오류가 발생해 시작되지 않는 경우 `access.log` 파일에 항목이 없다면 코어 연결 문제가 있는 것입니다. 항상 AWS 보안 그룹 구성을 첫 번째 단계로 확인합니다. 다른 일반적인 문제로는 `tsig.json`의 입력 오류가 있습니다. tsig.json을 업데이트하는 경우 `tsm topology external-services gateway update -c tsig.json`을 실행하기 전에 `tsm stop`을 실행합니다. tsig.json이 업데이트되면 `tsm start`를 실행합니다. - `error.log`: 다른 항목 중에서 이 로그에는 SAML 및 Mellon 오류가 포함됩니다. #### Tableau Server tabadminagent 로그 파일 `tabadminagent`(`tabadmincontroller`가 아님) 파일 집합은 독립 게이트웨이 관련 오류를 해결하는 것과 관련된 로그 파일만 모아 놓은 것입니다. 독립 게이트웨이 오류가 `tabdminagent`에 기록된 위치를 찾아야 합니다. 이러한 오류는 아무 노드에서나 발생할 수 있지만 노드 1개에만 존재합니다. Tableau Server 클러스터의 각 노드에서 다음 단계를 수행하면서 "independent" 문자열을 찾습니다. 1. EDG 설정의 Tableau Server 노드 1~4에서 tabadminagent 로그 파일 위치를 찾습니다. cd /data/tableau\_data/data/tabsvc/logs/tabadminagent 2. 다음과 같은 이름의 최신 로그를 엽니다. less tabadminagent\_nodeN.log (N을 노드 번호로 바꾸기) 3. 다음 검색 문자열을 사용하여 "Independent" 및 "independent"가 나오는 모든 경우를 검색합니다. /ndependent 일치하는 항목이 없는 경우 다음 노드로 이동하고 1~3단계를 반복합니다. 4. 일치하는 항목이 발견되면 `Shift + G`를 눌러 맨 아래로 이동하고 마지막 오류 메시지를 확인합니다. ### httpd stub 파일 다시 로드 독립 게이트웨이는 Apache의 httpd 구성을 관리합니다. 일시적인 문제를 해결하는 일반적인 작업은 기초 Apache 구성을 채우는 httpd stub 파일을 다시 로드하는 것입니다. 독립 게이트웨이의 두 인스턴스 모두에서 다음 명령을 실행합니다. 1. stub 파일을 httpd.conf에 복사합니다. cp /var/opt/tableau/tableau\_tsig/config/httpd.conf.stub /var/opt/tableau/tableau\_tsig/config/httpd.conf 2. 독립 게이트웨이 서비스를 다시 시작합니다. sudo su - tableau-tsig systemctl --user restart tsig-httpd exit ### 로그 파일 삭제 또는 이동 독립 게이트웨이는 모든 액세스 이벤트를 기록합니다. 디스크 공간이 가득 차는 것을 방지하기 위해 로그 파일 저장소를 관리해야 합니다. 디스크가 가득 차면 독립 게이트웨이가 액세스 이벤트를 기록할 수 없으며 서비스가 실패합니다. 다음 메시지가 독립 게이트웨이의 error.log에 기록됩니다. (28)No space left on device: \[client 10.0.2.209:54332\] AH00646: Error writing to /var/opt/tableau/tableau\_tsig/logs/access.%Y\_%m\_%d\_%H\_%M\_%S.log 이 오류는 Tableau 노드 1에서 `tsm status -v`를 실행할 때 `external` 노드에 대해 `DEGRADED` 상태를 초래합니다. 상태 출력의 `external` 노드는 독립 게이트웨이를 참조합니다. 이 문제를 해결하려면 access.log 파일을 삭제하거나 디스크에서 옮기십시오. Access.log 파일은 `/var/opt/tableau/tableau_tsig/logs`에 저장됩니다. 디스크를 지운 후 tableau-tsig 서비스를 다시 시작하십시오. ### 브라우저 오류 **잘못된 요청**: 이 시나리오의 일반적인 오류는 Okta의 "잘못된 요청" 오류입니다. 이 문제는 주로 브라우저가 이전 Okta 세션의 데이터를 캐싱할 때 발생합니다. 예를 들어 Okta 관리자 자격으로 Okta 응용 프로그램을 관리하고 다른 Okta 지원 계정을 사용하여 Tableau에 액세스하려고 하면 관리자 데이터의 세션 데이터가 "잘못된 요청" 오류를 발생시킬 수 있습니다. 로컬 브라우저 캐시를 지워도 이 오류가 계속되면 다른 브라우저로 연결하여 Tableau 시나리오의 유효성을 확인해 보십시오. “Bad Request” 오류의 또 다른 원인은 Okta, Mellon 및 SAML 구성 프로세스 중에 입력한 많은 URL 중 하나의 입력 오류입니다. 이 모든 것을 오류 없이 입력했는지 확인합니다. 오류를 야기한 URL은 주로 독립 게이트웨이 서버의 `error.log` 파일에 명시됩니다. **찾을 수 없음 - 요청한 URL을 이 서버에서 찾지 못했습니다**: 이 오류는 많은 구성 오류 중 하나를 나타냅니다. 사용자가 Okta로 인증된 후 이 오류가 발생하면 SAML을 구성할 때 Okta 사전 인증 응용 프로그램을 Tableau Server에 업로드한 것일 수 있습니다. Okta 사전 인증 응용 프로그램 메타데이터가 아니라 Tableau Server에 Okta Tableau Server 응용 프로그램 메타데이터가 구성되어 있는지 확인합니다. 다른 문제 해결 단계: - Okta 사전 인증 응용 프로그램 설정을 검토합니다. HTTP와 HTTPS 프로토콜이 이 항목에서 지정한 대로 설정되어 있는지 확인하십시오. - 두 독립 게이트웨이 서버에서 Restart tsig-httpd를 다시 시작합니다. - 두 독립 게이트웨이 모두에서 `sudo apachectl configtest`가 "Syntax OK"를 반환하는지 확인합니다. - 테스트 사용자가 Okta의 두 응용 프로그램에 모두 할당되었는지 확인합니다. - 부하 분산 장치 및 연결된 대상 그룹에 연결 유지가 설정되어 있는지 확인합니다. ### Tableau Server에서 독립 게이트웨이로의 TLS 연결 확인 `wget` 명령을 사용하여 Tableau Server에서 독립 게이트웨이로의 연결 및 액세스를 확인합니다. 이 명령의 변형을 사용하면 인증서 문제가 연결 문제를 일으키는지 여부를 확인하는 데 도움이 될 수 있습니다. 예를 들어 다음 `wget` 명령을 사용하여 Tableau Server의 HK(하우스키핑) 프로토콜을 확인합니다. `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319` tsig.json 파일의 호스트 옵션에 포함한 것과 동일한 호스트 주소를 사용하여 URL을 구성합니다. `https` 프로토콜을 지정하고 URL에 HK 포트 `21319`를 추가합니다. 연결을 확인하고 인증서 확인을 무시하려면 `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --no-check-certificate` TSIG의 루트 CA가 유효한지 확인하려면 `wget https://ip-10-0-1-38.us-west-1.compute.internal:21319 --ca-certificate=tsigRootCA.pem` Tableau에서 통신할 수 있는 경우에는 콘텐츠 관련 오류가 계속해서 발생할 수 있지만 연결 관련 오류는 발생하지 않습니다. Tableau에서 전혀 연결할 수 없는 경우 방화벽/보안 그룹의 프로토콜 구성을 확인하는 것으로 시작합니다. 예를 들어 독립 게이트웨이가 상주하는 보안 그룹의 인바운드 규칙은 TCP 21319를 허용해야 합니다.