SQL Server 빅 데이터 클러스터 Kubernetes 문제 해결

  • 아티클

적용 대상: SQL Server 2019(15.x)

중요

Microsoft SQL Server 2019 빅 데이터 클러스터 추가 기능이 사용 중지됩니다. SQL Server 2019 빅 데이터 클러스터에 대한 지원은 2025년 2월 28일에 종료됩니다. Software Assurance를 사용하는 SQL Server 2019의 모든 기존 사용자는 플랫폼에서 완전히 지원되며, 소프트웨어는 지원 종료 시점까지 SQL Server 누적 업데이트를 통해 계속 유지 관리됩니다. 자세한 내용은 공지 블로그 게시물 및 Microsoft SQL Server 플랫폼의 빅 데이터 옵션을 참조하세요.

이 문서에서는 SQL Server 2019 빅 데이터 클러스터를 모니터링하고 문제를 해결하는 데 사용할 수 있는 몇 가지 유용한 Kubernetes 명령을 설명합니다. 빅 데이터 클러스터에 있는 Pod 또는 다른 Kubernetes 아티팩트에 대한 자세한 정보를 보는 방법을 보여 줍니다. 이 문서에서는 SQL Server 빅 데이터 클러스터 서비스 중 하나를 실행하는 컨테이너에 파일을 복사하는 작업 등의 일반적인 작업도 다룹니다.

팁

빅 데이터 클러스터 구성 요소의 상태를 모니터링하기 위해 azdata bdc status 명령 또는 Azure Data Studio에서 제공되는 기본 제공 문제 해결 Notebook을 사용할 수 있습니다.

팁

Windows(cmd 또는 PS) 또는 Linux(bash) 클라이언트 컴퓨터에서 다음 kubectl 명령을 실행합니다. 클러스터의 이전 인증과 실행 대상이 될 클러스터 컨텍스트가 필요합니다. 예를 들어 이전에 만든 AKS 클러스터의 경우 az aks get-credentials --name <aks_cluster_name> --resource-group <azure_resource_group_name>를 실행하여 Kubernetes 클러스터 구성 파일을 다운로드하고 클러스터 컨텍스트를 설정할 수 있습니다.

Pod 상태 가져오기

kubectl get pods 명령을 사용하여 모든 네임스페이스 또는 빅 데이터 클러스터 네임스페이스에 대한 클러스터의 Pod 상태를 가져올 수 있습니다. 다음 섹션에서는 두 가지 모두에 대한 몇 가지 예를 보여줍니다.

Kubernetes 클러스터에 있는 모든 Pod의 상태 표시

다음 명령을 실행하여 모든 Pod 및 해당 상태를 가져옵니다. 여기에는 SQL Server 빅 데이터 클러스터 Pod가 만들어지는 네임스페이스의 일부인 Pod가 포함됩니다.

kubectl get pods --all-namespaces

SQL Server 빅 데이터 클러스터에 있는 모든 Pod의 상태 표시

-n 매개 변수를 사용하여 특정 네임스페이스를 지정합니다. SQL Server 빅 데이터 클러스터 Pod는 배포 구성 파일에 지정된 클러스터 이름을 기반으로 클러스터 부트스트랩 시간에 만들어진 새 네임스페이스에 만들어집니다. 기본 이름인 mssql-cluster이 여기에 사용됩니다.

kubectl get pods -n mssql-cluster

실행 중인 빅 데이터 클러스터에 대한 다음 목록과 유사한 출력이 표시됩니다.

PS C:\> kubectl get pods -n mssql-cluster
NAME              READY   STATUS    RESTARTS   AGE
appproxy-f2qqt    2/2     Running   0          110m
compute-0-0       3/3     Running   0          110m
control-zlncl     4/4     Running   0          118m
data-0-0          3/3     Running   0          110m
data-0-1          3/3     Running   0          110m
gateway-0         2/2     Running   0          109m
logsdb-0          1/1     Running   0          112m
logsui-jtdnv      1/1     Running   0          112m
master-0          7/7     Running   0          110m
metricsdb-0       1/1     Running   0          112m
metricsdc-shv2f   1/1     Running   0          112m
metricsui-9bcj7   1/1     Running   0          112m
mgmtproxy-x6gcs   2/2     Running   0          112m
nmnode-0-0        1/1     Running   0          110m
storage-0-0       7/7     Running   0          110m
storage-0-1       7/7     Running   0          110m

참고 항목

배포 중에는 STATUS가 ContainerCreating인 Pod도 표시됩니다. 어떤 이유로든 배포가 중단되면 문제가 발생할 수 있는 위치를 파악할 수 있습니다. READY 열도 확인합니다. 그러면 Pod에서 시작된 컨테이너 수를 알 수 있습니다. 배포는 구성 및 네트워크에 따라 30분 이상 걸릴 수 있습니다. 이 시간의 대부분은 여러 구성 요소에 대한 컨테이너 이미지를 다운로드하는 데 소요됩니다.

Pod 세부 정보 가져오기

다음 명령을 실행하여 JSON 형식 출력의 특정 Pod에 대한 자세한 설명을 가져옵니다. 여기에는 Pod가 있는 현재 Kubernetes 노드, Pod 내에서 실행되는 컨테이너, 컨테이너를 부트스트랩하는 데 사용되는 이미지 등의 세부 정보가 포함됩니다. 또한 Pod와 연결된 레이블, 상태, 지속형 볼륨 클레임과 같은 다른 세부 정보도 나와 있습니다.

kubectl describe pod  <pod_name> -n <namespace_name>

다음 예제에서는 mssql-cluster로 명명된 빅 데이터 클러스터의 master-0 Pod에 대한 세부 정보를 보여줍니다.

kubectl describe pod  master-0 -n mssql-cluster

오류가 발생하면 Pod에 대한 최근 이벤트에서 오류를 확인할 수 있는 경우도 있습니다.

Pod 로그 가져오기

Pod에서 실행되는 컨테이너에 대한 로그를 검색할 수 있습니다. 다음 명령은 master-0로 명명된 Pod에서 실행되는 모든 컨테이너에 대한 로그를 검색하여 master-0-pod-logs.txt이라는 파일 이름으로 출력합니다.

kubectl logs master-0 --all-containers=true -n mssql-cluster > master-0-pod-logs.txt

앱 서비스 상태 가져오기

다음 명령을 실행하여 빅 데이터 클러스터 서비스의 세부 정보를 가져옵니다. 이러한 세부 정보에는 해당하는 형식과 각각의 서비스 및 포트와 연결된 IP가 포함됩니다. SQL Server 빅 데이터 클러스터 서비스는 배포 구성 파일에 지정된 클러스터 이름을 기반으로 클러스터 부트스트랩 시간에 만들어진 새 네임스페이스에서 만들어집니다.

kubectl get svc -n <namespace_name>

다음 예제에서는 mssql-cluster로 명명된 빅 데이터 클러스터의 서비스에 대한 상태를 보여줍니다.

kubectl get svc -n mssql-cluster

다음 서비스는 빅 데이터 클러스터에 대한 외부 연결을 지원합니다.

서비스 설명
master-svc-external 마스터 인스턴스에 대한 액세스를 제공합니다.
(EXTERNAL-IP,31433 및 SA 사용자)
controller-svc-external 클러스터를 관리하는 도구 및 클라이언트를 지원합니다.
gateway-svc-external HDFS/Spark 게이트웨이에 대한 액세스를 제공합니다.
(EXTERNAL-IP 및 <AZDATA_USERNAME> 사용자)1
appproxy-svc-external 애플리케이션 배포 시나리오를 지원합니다.

1 SQL Server 2019(15.x) CU 5부터 기본 인증을 사용하여 새 클러스터를 배포하는 경우 게이트웨이를 비롯한 모든 엔드포인트는 AZDATA_USERNAME 및 AZDATA_PASSWORD를 사용합니다. CU 5로 업그레이드된 클러스터의 엔드포인트는 게이트웨이 엔드포인트에 연결하기 위해 사용자 이름으로 root를 계속 사용합니다. Active Directory 인증을 사용하는 배포에는 이 변경 내용이 적용되지 않습니다. 릴리스 정보에서 게이트웨이 엔드포인트를 통해 서비스에 액세스하기 위한 자격 증명을 참조하세요.

팁

이는 kubectl을 사용하여 서비스를 보는 한 가지 방법이지만 azdata bdc endpoint list 명령을 사용하여 이러한 엔드포인트를 볼 수도 있습니다. 자세한 내용은 빅 데이터 클러스터 엔드포인트 가져오기를 참조하세요.

서비스 세부 정보 가져오기

이 명령을 실행하여 JSON 형식 출력으로 서비스에 대한 자세한 설명을 가져옵니다. 여기에는 레이블, 선택기, IP, 외부 IP(서비스가 LoadBalancer 유형인 경우), 포트 등의 세부 정보가 포함됩니다.

kubectl describe service <service_name> -n <namespace_name>

다음 예제에서는 master-svc-external 서비스에 대한 세부 정보를 검색합니다.

kubectl describe service master-svc-external -n mssql-cluster

파일 복사

컨테이너에서 로컬 컴퓨터로 파일을 복사해야 하는 경우 다음 구문과 함께 kubectl cp 명령을 사용합니다.

kubectl cp <pod_name>:<source_file_path> -c <container_name> -n <namespace_name> <target_local_file_path>

마찬가지로 kubectl cp를 사용하여 로컬 컴퓨터에서 특정 컨테이너로 파일을 복사할 수 있습니다.

kubectl cp <source_local_file_path> <pod_name>:<target_container_path> -c <container_name>  -n <namespace_name>

컨테이너에서 파일 복사

다음 예제에서는 컨테이너의 SQL Server 로그 파일을 로컬 컴퓨터의 ~/temp/sqlserverlogs 경로로 복사합니다(이 예제에서는 로컬 컴퓨터가 Linux 클라이언트).

kubectl cp master-0:/var/opt/mssql/log -c mssql-server -n mssql-cluster ~/tmp/sqlserverlogs

컨테이너에 파일 복사

다음 예제에서는 로컬 컴퓨터에서 AdventureWorks2022 Pod의 SQL Server 마스터 인스턴스 컨테이너(mssql-server)로 master-0 파일을 복사합니다. 파일이 컨테이너의 /tmp 디렉터리에 복사됩니다.

kubectl cp ~/Downloads/AdventureWorks2022.bak master-0:/tmp -c mssql-server -n mssql-cluster

Pod 강제 삭제

Pod는 강제로 삭제하지 않는 것이 좋습니다. 그러나 가용성, 복원력 또는 데이터 지속성을 테스트하기 위해 Pod를 삭제하여 kubectl delete pods 명령으로 Pod 오류를 시뮬레이션할 수 있습니다.

kubectl delete pods <pod_name> -n <namespace_name> --grace-period=0 --force

다음 예제에서는 스토리지 풀 Pod storage-0-0을 삭제합니다.

kubectl delete pods storage-0-0 -n mssql-cluster --grace-period=0 --force

Pod IP 가져오기

문제 해결을 위해 Pod가 현재 실행 중인 노드의 IP를 가져와야 할 수 있습니다. IP 주소를 가져오려면 다음 구문으로 kubectl get pods 명령을 사용합니다.

kubectl get pods <pod_name> -o yaml -n <namespace_name> | grep hostIP

다음 예제에서는 master-0 Pod가 실행 중인 노드의 IP 주소를 가져옵니다.

kubectl get pods master-0 -o yaml -n mssql-cluster | grep hostIP

Kubernetes 대시보드

Kubernetes 대시보드를 시작하여 클러스터에 대한 추가 정보를 확인할 수 있습니다. 다음 섹션에서는 AKS의 Kubernetes용 대시보드 및 kubeadm을 사용하여 부트스트랩된 Kubernetes용 대시보드를 시작하는 방법을 설명합니다.

클러스터가 AKS에서 실행 중일 때 대시보드 시작

Kubernetes 대시보드를 시작하려면 다음 명령을 실행합니다.

az aks browse --resource-group <azure_resource_group> --name <aks_cluster_name>

참고 항목

다음 오류가 표시되는 경우: 포트 8001에서 수신 대기할 수 없습니다: 다음 오류가 발생하여 모든 수신기를 만들지 못했습니다: 수신기를 만들 수 없습니다: tcp4 127.0.0.1:8001 수신 대기 오류: >bind: 각 소켓 주소(프로토콜/네트워크 주소/포트)는 한 가지 사용만 허용됩니다. 수신기를 만들 수 없습니다: tcp6 수신 대기 오류: 주소 [[::1]]:8001: >주소에 포트 누락 오류: 요청된 포트에서 수신 대기할 수 없습니다: [{8001 9090}], 다른 창에서 해당 대시보드를 이미 시작하지 않았는지 확인합니다.

브라우저에서 대시보드를 시작하면 AKS 클러스터에서 RBAC가 기본적으로 사용하도록 설정되고 대시보드에서 사용되는 서비스 계정에 모든 리소스에 액세스할 수 있는 권한이 없기 때문에 사용 권한 경고가 표시될 수 있습니다. 예를 들어 Pod를 사용할 수 없습니다: 사용자 "system:serviceaccount:kube-system:kubernetes-dashboard"는 "default" 네임스페이스에 Pod를 나열할 수 없습니다). 다음 명령을 실행하여 kubernetes-dashboard에 필요한 사용 권한을 부여하고 대시보드를 다시 시작합니다.

kubectl create clusterrolebinding kubernetes-dashboard -n kube-system --clusterrole=cluster-admin --serviceaccount=kube-system:kubernetes-dashboard

Kubernetes 클러스터가 kubeadm을 사용하여 부트스트랩된 경우 대시보드 시작

Kubernetes 클러스터에서 대시보드를 배포하고 구성하는 방법에 대한 자세한 지침은 Kubernetes 설명서를 참조하세요. Kubernetes 대시보드를 시작하려면 다음 명령을 실행합니다.

kubectl proxy

다음 단계

빅 데이터 클러스터에 대한 자세한 내용은 SQL Server 빅 데이터 클러스터란?을 참조하세요.