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 플랫폼의 빅 데이터 옵션을 참조하세요.

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

Important

관리되는 Kubernetes 서비스(AKS 또는 ARO) 중 하나를 사용하여 Azure에서 빅 데이터 클러스터를 배포하는 경우 애플리케이션 워크로드 요구 사항에 따라 수용해야 할 수 있는 제한 사항이 있다는 점에 유의하세요. 예를 들어 Azure 관리형 디스크를 사용하는 볼륨은 현재 영역 중복 리소스가 아닙니다. 볼륨은 영역 간에 연결할 수 없으며 대상 Pod를 호스트하는 지정된 노드와 동일한 영역에 공동 배치되어야 합니다. 이 특정한 경우에는 SQL Server 빅 데이터 클러스터와 사용할 수 있는 추가 고가용성 솔루션을 사용하는 것이 좋습니다. Azure Kubernetes Service 및 가용성 영역에 대한 자세한 내용은 여기를 참조하세요.

영구적 볼륨 구성

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

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

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

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

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

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

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

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

리소스 데이터에 대한 스토리지 유형 로그에 대한 스토리지 유형 주의
SQL Server 마스터 인스턴스 로컬(복제본>=3) 또는 원격 중복 스토리지(복제본=1) 로컬 저장소 Pod가 노드에 유지되는 상태 저장 세트 기반 구현은 다시 시작 및 일시적인 오류로 인해 데이터가 손상되지 않도록 보장합니다.
풀 컴퓨팅 로컬 저장소 로컬 저장소 저장된 사용자 데이터가 없습니다.
데이터 풀 로컬/원격 중복 스토리지 로컬 저장소 다른 데이터 원본에서 데이터 풀을 다시 작성할 수 없는 경우 원격 중복 스토리지를 사용합니다.
스토리지 풀(HDFS) 로컬/원격 중복 스토리지 로컬 저장소 HDFS 복제가 사용됩니다.
Spark 풀 로컬 저장소 로컬 저장소 저장된 사용자 데이터가 없습니다.
제어(controldb, metricsdb, logsdb) 원격 중복 스토리지 로컬 저장소 빅 데이터 클러스터 메타데이터에 스토리지 수준 중복성을 사용하는 것이 중요합니다.

Important

제어 관련 구성 요소가 원격 중복 스토리지 디바이스에 있는지 확인합니다. controldb-0 Pod는 클러스터 서비스 상태, 다양한 설정 및 기타 관련 정보와 관련된 모든 메타데이터를 저장하는 데이터베이스를 사용하여 SQL Server 인스턴스를 호스트합니다. 이 인스턴스를 사용할 수 없게 되는 경우 클러스터의 다른 종속 서비스에서 상태 문제가 발생합니다.

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

다른 사용자 지정에서와 같이, 배포 시 bdc.json 구성 파일의 각 풀과 control.json 파일의 컨트롤 서비스에 맞게 클러스터 구성 파일의 스토리지 설정을 지정할 수 있습니다. 풀 사양에 스토리지 구성 설정이 없는 경우 SQL Server 마스터(master 리소스), HDFS(storage-0 리소스), 데이터 풀을 비롯한 다른 모든 구성 요소에 컨트롤 스토리지 설정이 사용됩니다. 다음 코드 샘플은 사양에 포함할 수 있는 스토리지 구성 섹션을 나타냅니다.

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

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

Warning

테스트 환경에서는 영구 스토리지 없이 실행할 수 있지만 작동하지 않는 클러스터가 나타날 수 있습니다. Pod가 다시 시작되면 클러스터 메타데이터 및/또는 사용자 데이터가 영구적으로 손실됩니다. 이 구성에서 실행하는 것은 권장되지 않습니다.

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

AKS 스토리지 클래스

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

Warning

기본 제공 스토리지 클래스 default 및 managed-premium를 사용하여 만든 영구 볼륨에는 Delete의 회수 정책이 있습니다. 따라서 SQL Server 빅 데이터 클러스터를 삭제하면 영구 볼륨과 마찬가지로 영구 볼륨 클레임이 삭제됩니다. 스토리지 개념에 설명된 대로 Retain 유지 회수 정책으로 azure-disk 프로비저닝 프로그램을 사용하여 사용자 지정 스토리지 클래스를 만들 수 있습니다.

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

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

Important

kubeadm(kubeadm-dev-test 및 kubeadm-prod)에 대한 기본 제공 배포 구성 파일에는 데이터 및 로그 스토리지에 대해 지정된 스토리지 클래스 이름이 없습니다. 배포 전에 구성 파일을 사용자 지정하고 className의 값을 설정해야 합니다. 설정하지 않으면 배포 전 유효성 검사에 실패합니다. 또한 배포에는 스토리지 클래스가 있는지 검사하는 유효성 검사 단계가 있습니다. 필요한 영구 볼륨에 대한 단계는 없습니다. 클러스터의 규모에 따라 충분한 볼륨을 만들어야 합니다. 기본 최소 클러스터 크기(기본 규모, 고가용성 없음)의 경우 24개 이상의 영구 볼륨을 만들어야 합니다. 로컬 프로비저닝 프로그램을 사용하여 영구 볼륨을 만드는 방법의 예제는 Kubeadm을 사용하여 Kubernetes 클러스터 만들기를 참조하세요.

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

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

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

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

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

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

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

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

다음 단계