SQL Server 빅 데이터 클러스터를 사용하는 Kubernetes의 데이터 지속성

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

영구 볼륨은 Kubernetes의 스토리지에 대한 플러그 인 모델을 제공합니다. 이 모델에서는 스토리지가 제공되는 방식이 소비되는 방식과 별개로 추상화됩니다. 따라서 고가용성 스토리지를 가져와서 SQL Server 빅 데이터 클러스터에 연결할 수 있습니다. Kubernetes는 Azure 디스크 및 파일, NFS(네트워크 파일 시스템) 및 로컬 스토리지를 비롯한 다양한 종류의 스토리지 솔루션을 지원하지만 빅 데이터 클러스터는 테스트된 구성에서만 지원됩니다. 지원되는 구성에 대한 자세한 내용은 SQL Server 2019 빅 데이터 클러스터 플랫폼 릴리스 정보를 참조하세요.

영구 볼륨 구성

SQL Server 빅 데이터 클러스터는 스토리지 클래스를 사용하여 이러한 영구 볼륨 을 사용합니다. 다양한 종류의 스토리지에 대해 다른 스토리지 클래스를 만들고 빅 데이터 클러스터 배포 시 지정할 수 있습니다. 풀 수준에서 특정 용도로 사용할 스토리지 클래스 및 영구 볼륨 클레임 크기를 구성할 수 있습니다. SQL Server 빅 데이터 클러스터는 영구적 볼륨이 필요한 각 구성 요소에 대해 지정된 스토리지 클래스 이름을 사용하여 영구 볼륨 클레임을 만듭니다. 그런 다음 해당 영구 볼륨(또는 볼륨)을 Pod에 탑재합니다.

빅 데이터 클러스터에 대한 스토리지 구성을 계획할 때 고려해야 할 몇 가지 중요한 측면은 다음과 같습니다.

• 빅 데이터 클러스터 배포에 성공하려면 필요한 수의 영구 볼륨을 사용할 수 있는지 확인합니다. AKS(Azure Kubernetes Service) 클러스터에 배포하고 기본 제공 스토리지 클래스(default 또는 managed-premium)를 사용하는 경우 이 클래스는 영구 볼륨에 대한 동적 프로비저닝을 지원합니다. 따라서 영구 볼륨을 미리 만들 필요는 없지만 AKS 클러스터에서 사용 가능한 작업자 노드가 배포에 필요한 영구 볼륨 수만큼 많은 디스크를 연결할 수 있는지 확인해야 합니다. 작업자 노드에 대해 지정된 VM 크기에 따라 각 노드는 특정 수의 디스크를 연결할 수 있습니다. 기본 크기 클러스터(고가용성 없음)의 경우 최소 24개의 디스크가 필요합니다. 고가용성을 사용하도록 설정하거나 풀을 확장하는 경우 스케일 업하는 리소스에 관계없이 각 추가 복제본당 최소 두 개의 지속형 볼륨이 있는지 확인합니다.

• 구성에서 제공하는 스토리지 클래스에 대한 스토리지 프로비저닝기가 동적 프로비저닝을 지원하지 않는 경우 지속형 볼륨을 미리 만들어야 합니다. 예를 들어 local-storage 프로비저닝 프로그램은 동적 프로비저닝을 사용하도록 설정하지 않습니다. 배포된 Kubernetes 클러스터에서 진행하는 방법에 대한 지침은 이 샘플 스크립트 를 참조하세요 kubeadm.

• 빅 데이터 클러스터를 배포할 때 클러스터의 모든 구성 요소에서 사용할 동일한 스토리지 클래스를 구성할 수 있습니다. 그러나 프로덕션 배포의 모범 사례로, 다양한 구성 요소에는 크기 또는 처리량 측면에서 다양한 워크로드를 수용하기 위해 다양한 스토리지 구성이 필요합니다. 각 SQL Server 마스터 인스턴스, 데이터 세트 및 스토리지 풀에 대해 컨트롤러에 지정된 기본 스토리지 구성을 덮어쓸 수 있습니다. 이 문서에서는 이 작업을 수행하는 방법에 대한 예제를 제공합니다.

• 스토리지 풀 크기 조정 요구 사항을 계산할 때 HDFS가 구성된 복제 요소를 고려해야 합니다. 복제 요소는 클러스터 배포 구성 파일에서 배포 시 구성할 수 있습니다. 개발 테스트 프로필(예: aks-dev-test 또는 kubeadm-dev-test)의 기본값은 2이며 프로덕션 배포에 권장되는 프로필(예 kubeadm-prod: 기본값)의 경우 기본값은 3입니다. 모범 사례로, HDFS에 대한 복제 요소가 3개 이상인 빅 데이터 클러스터의 프로덕션 배포를 구성하는 것이 좋습니다. 복제 요소의 값은 스토리지 풀의 인스턴스 수에 영향을 줍니다. 최소한 복제 요소 값만큼의 스토리지 풀 인스턴스를 배포해야 합니다. 또한 그에 따라 스토리지 크기를 조정하고 HDFS에서 복제되는 데이터를 복제 계수 값의 2배만큼 고려해야 합니다. HDFS에서 데이터 복제에 대한 자세한 내용은 여기를 참조 하세요.

• SQL Server 2019 CU1 릴리스를 기준으로 BDC는 배포 후 스토리지 구성 설정을 업데이트하는 환경을 사용하도록 설정하지 않습니다. 이 제약 조건을 사용하면 BDC 작업을 사용하여 각 인스턴스에 대한 영구 볼륨 클레임의 크기를 수정하거나 배포 후 풀의 크기를 조정할 수 없습니다. 따라서 빅 데이터 클러스터를 배포하기 전에 스토리지 레이아웃을 계획하는 것이 매우 중요합니다. 그러나 Kubernetes API를 사용하여 영구 볼륨 크기를 직접 확장할 수 있습니다. 이 경우 BDC 메타데이터는 업데이트되지 않으며 구성 클러스터 메타데이터의 볼륨 크기와 관련된 불일치가 표시됩니다.

• Kubernetes에서 컨테이너화된 애플리케이션으로 배포하고 상태 저장 집합 및 영구 스토리지와 같은 기능을 사용하여 Kubernetes는 상태 문제가 발생할 경우 Pod가 다시 시작되고 동일한 영구 스토리지에 연결되도록 합니다. 그러나 노드 오류가 있고 다른 노드에서 Pod를 다시 시작해야 하는 경우 스토리지가 실패한 노드에 로컬인 경우 사용할 수 없을 위험이 증가합니다. 이러한 위험을 줄이려면 추가 중복성을 구성하고 고가용성 기능을 사용하도록 설정하거나 원격 중복 스토리지를 사용해야 합니다. 다음은 빅 데이터 클러스터의 다양한 구성 요소에 대한 스토리지 옵션에 대한 개요입니다.

빅 데이터 클러스터 스토리지 설정 구성

다른 사용자 지정과 같이 배포 시 각 풀에 대한 스토리지 설정을 bdc.json 구성 파일에서 지정하고, 제어 서비스에 대한 설정은 control.json 파일에서 지정할 수 있습니다. 풀 사양에 스토리지 구성 설정이 없으면 SQL Server 마스터(리소스), HDFSmaster(storage-0리소스) 및 데이터 풀 구성 요소를 비롯한 다른 모든 구성 요소에 컨트롤 스토리지 설정이 사용됩니다. 다음 코드 샘플은 사양에 포함할 수 있는 스토리지 구성 섹션을 나타냅니다.

    "storage": 
    {
      "data": {
        "className": "default",
        "accessMode": "ReadWriteOnce",
        "size": "15Gi"
      },
      "logs": {
        "className": "default",
        "accessMode": "ReadWriteOnce",
        "size": "10Gi"
    }

빅 데이터 클러스터 배포는 영구 스토리지를 사용하여 다양한 구성 요소에 대한 데이터, 메타데이터 및 로그를 저장합니다. 배포의 일부로 만든 영구 볼륨 클레임의 크기를 사용자 지정할 수 있습니다. 보존 회수 정책을 사용하여 스토리지 클래스를 사용하는 것이 좋습니다.

스토리지 구성 섹션에서는 SQL Server 빅 데이터 클러스터 배포에 대한 스토리지 설정을 구성하는 방법에 대한 더 많은 예제를 제공합니다.

AKS 스토리지 클래스

AKS에는 두 개의 기본 제공 스토리지 클래스default와 managed-premium동적 프로비저닝기가 함께 제공됩니다. 이러한 중 하나를 지정하거나 고유한 스토리지 클래스를 만들어 영구 스토리지를 사용하도록 설정된 빅 데이터 클러스터를 배포할 수 있습니다. 기본적으로 AKS aks-dev-test에 대한 클러스터 구성 파일은 default 스토리지 클래스를 사용하기 위한 영구 스토리지 설정을 포함하고 있습니다.

클러스터에 대한 kubeadm 스토리지 클래스

사용하여 kubeadm 배포되는 Kubernetes 클러스터에는 기본 제공 스토리지 클래스가 없습니다. 로컬 스토리지 또는 기본 스토리지 프로비저닝자를 사용하여 고유한 스토리지 클래스 및 영구 볼륨을 만들어야 합니다. 이 경우 구성한 스토리지 클래스로 설정합니다 className .

각 풀에 대한 스토리지 구성 사용자 지정

모든 사용자 지정의 경우 먼저 사용하려는 기본 제공 구성 파일의 복사본을 만들어야 합니다. 예를 들어 다음 명령은 다음과 aks-dev-test같은 하위 디렉터리에 배포 구성 파일의 custom 복사본을 만듭니다.

azdata bdc config init --source aks-dev-test --target custom

이 프로세스에서는 두 개의 파일을 만들고 수동으로 bdc.jsoncontrol.json편집하거나 명령을 사용하여 azdata bdc config 사용자 지정할 수 있습니다. jsonpath 및 jsonpatch 라이브러리의 조합을 사용하여 구성 파일을 편집하는 방법을 제공할 수 있습니다.

스토리지 클래스 이름 및/또는 클레임 크기 구성

기본적으로 클러스터에 프로비전된 각 Pod에 대해 프로비전된 영구 볼륨 클레임의 크기는 10GB(기가바이트)입니다. 클러스터 배포 전에 사용자 지정 구성 파일에서 실행 중인 워크로드를 수용하도록 이 값을 업데이트할 수 있습니다.

다음 예제에서는 영구 볼륨 클레임의 크기가 32GB로 업데이트됩니다 control.json. 풀 수준에서 재정의되지 않으면 이 설정이 모든 풀에 적용됩니다.

azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.size=100Gi"

다음 예제에서는 파일에 대한 스토리지 클래스를 수정하는 방법을 보여 줍니다 control.json .

azdata bdc config replace --config-file custom/control.json --json-values "$.spec.storage.data.className=<yourStorageClassName>"

또한 다음 예제와 같이 사용자 지정 구성 파일을 수동으로 편집하거나 스토리지 풀에 대한 스토리지 클래스를 변경하는 .json 패치를 사용할 수도 있습니다.

{
  "patch": [
    {
      "op": "replace",
      "path": "$.spec.resources.storage-0.spec",
      "value": {
        "type":"Storage",
        "replicas":2,
        "storage":{
            "data":{
                    "size": "100Gi",
                    "className": "myStorageClass",
                    "accessMode":"ReadWriteOnce"
                    },
            "logs":{
                    "size":"32Gi",
                    "className":"myStorageClass",
                    "accessMode":"ReadWriteOnce"
                    }
                }
            }
        }
    ]
}

패치 파일을 적용합니다. azdata bdc config patch 명령을 사용하여 .json 패치 파일의 변경 내용을 적용합니다. 다음 예제에서는 patch.json 파일을 custom.json 대상 배포 구성 파일에 적용합니다.

azdata bdc config patch --config-file custom/bdc.json --patch-file ./patch.json

다음 단계

• Kubernetes의 볼륨에 대한 전체 설명서는 볼륨에 대한 Kubernetes 설명서를 참조하세요.

• SQL Server 빅 데이터 클러스터 배포에 대한 자세한 내용은 Kubernetes에 SQL Server 빅 데이터 클러스터를 배포하는 방법을 참조하세요.