다음을 통해 공유

빅 데이터 클러스터 리소스 및 서비스에 대한 배포 설정 구성

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

Azure Data CLI(azdata) 관리 도구에 기본 제공되는 미리 정의된 구성 프로필 집합부터 BDC 워크로드 요구 사항에 맞게 기본 설정을 쉽게 수정할 수 있습니다. 구성 파일의 구조를 사용하면 리소스의 각 서비스에 대한 설정을 세분화하여 업데이트할 수 있습니다.

비고

빅 데이터 클러스터 버전 CU9+에는 구성 관리 기능이 지원됩니다. 이 기능은 배포 후 구성을 사용하도록 설정하고 클러스터의 향상된 가시성과 구성 가능성을 제공합니다. CU8 이하 버전에는 이 기능이 없으며 구성은 배포 시에만 수행할 수 있습니다.

빅 데이터 클러스터 구성에 대한 개요는 이 13분 분량의 비디오를 시청하세요.

팁 (조언)

고가용성을 갖춘 서비스를 배포하는 방법에 대한 자세한 내용은 중요 업무용 구성 요소인 SQL Server 마스터 또는 HDFS 이름 노드에 대해 고가용성을 구성하는 방법을 설명한 문서를 참조하세요.

팁 (조언)

SQL Server 빅 데이터 클러스터 구성 속성 문서를 참조하여 구성할 수 있는 설정을 확인합니다. CU8 이하 버전의 경우 SQL Server 마스터 인스턴스 구성 속성 - SQL Server 마스터 인스턴스 에 사용할 수 있는 구성에 대한 사전 CU9 릴리스 및 Apache Spark 및 Hadoop 속성에 대한 APache Spark 및 HDFS(Apache Hadoop) 구성 속성을 참조하세요.

리소스 수준 구성을 설정하거나 리소스의 모든 서비스에 대한 구성을 업데이트할 수도 있습니다. 다음은 다음과 같은 구조에 대한 요약입니다 bdc.json.

{
    "apiVersion": "v1",
    "metadata": {
        "kind": "BigDataCluster",
        "name": "mssql-cluster"
    },
    "spec": {
        "resources": {
            "nmnode-0": {...
            },
            "sparkhead": {...
            },
            "zookeeper": {...
            },
            "gateway": {...
            },
            "appproxy": {...
            },
            "master": {...
            },
            "compute-0": {...
            },
            "data-0": {...
            },
            "storage-0": {...
        },
        "services": {
            "sql": {
                "resources": [
                    "master",
                    "compute-0",
                    "data-0",
                    "storage-0"
                ]
            },
            "hdfs": {
                "resources": [
                    "nmnode-0",
                    "zookeeper",
                    "storage-0",
                    "sparkhead"
                ],
                "settings": {...
            },
            "spark": {
                "resources": [
                    "sparkhead",
                    "storage-0"
                ],
                "settings": {...
            }
        }
    }
}

풀의 인스턴스와 같은 리소스 수준 구성을 업데이트하려면 리소스 사양을 업데이트합니다. 예를 들어 컴퓨팅 풀의 인스턴스 수를 업데이트하려면 구성 파일에서 bdc.json 이 섹션을 수정합니다.

"resources": {
    ...
    "compute-0": {
        "metadata": {
            "kind": "Pool",
            "name": "default"
        },
        "spec": {
            "type": "Compute",
            "replicas": 4
        }
    }
    ...
}

마찬가지로 특정 리소스 내에서 단일 서비스의 설정을 변경합니다. 예를 들어, 스토리지 풀의 Spark 구성 요소에 대해서만 Spark 메모리 설정을 변경하려면 storage-0 구성 파일의 settings 서비스 섹션에 spark 리소스를 업데이트하여 bdc.json 합니다.

"resources":{
    ...
     "storage-0": {
        "metadata": {
            "kind": "Pool",
            "name": "default"
        },
        "spec": {
            "type": "Storage",
            "replicas": 2,
            "settings": {
                "spark": {
                    "spark-defaults-conf.spark.driver.memory": "2g",
                    "spark-defaults-conf.spark.driver.cores": "1",
                    "spark-defaults-conf.spark.executor.instances": "3",
                    "spark-defaults-conf.spark.executor.memory": "1536m",
                    "spark-defaults-conf.spark.executor.cores": "1",
                    "yarn-site.yarn.nodemanager.resource.memory-mb": "18432",
                    "yarn-site.yarn.nodemanager.resource.cpu-vcores": "6",
                    "yarn-site.yarn.scheduler.maximum-allocation-mb": "18432",
                    "yarn-site.yarn.scheduler.maximum-allocation-vcores": "6",
                    "yarn-site.yarn.scheduler.capacity.maximum-am-resource-percent": "0.3"
                }
            }
        }
    }
    ...
}

여러 리소스와 연결된 서비스에 동일한 구성을 적용하려면 settings 섹션에서 해당 services을 업데이트하십시오. 예를 들어, 스토리지 풀과 Spark 풀이 모두 Spark를 위해 동일한 설정을 적용하려는 경우, settings 구성 파일 내의 spark 서비스 섹션에 있는 bdc.json 섹션을 업데이트합니다.

"services": {
    ...
    "spark": {
        "resources": [
            "sparkhead",
            "storage-0"
        ],
        "settings": {
            "spark-defaults-conf.spark.driver.memory": "2g",
            "spark-defaults-conf.spark.driver.cores": "1",
            "spark-defaults-conf.spark.executor.instances": "3",
            "spark-defaults-conf.spark.executor.memory": "1536m",
            "spark-defaults-conf.spark.executor.cores": "1",
            "yarn-site.yarn.nodemanager.resource.memory-mb": "18432",
            "yarn-site.yarn.nodemanager.resource.cpu-vcores": "6",
            "yarn-site.yarn.scheduler.maximum-allocation-mb": "18432",
            "yarn-site.yarn.scheduler.maximum-allocation-vcores": "6",
            "yarn-site.yarn.scheduler.capacity.maximum-am-resource-percent": "0.3"
        }
    }
    ...
}

클러스터 배포 구성 파일을 사용자 지정하려면 VSCode와 같은 JSON 형식 편집기를 사용할 수 있습니다. 자동화를 위해 이러한 편집 내용을 스크립팅하려면 이 명령을 사용합니다 azdata bdc config . 이 문서에서는 배포 구성 파일을 수정하여 빅 데이터 클러스터 배포를 구성하는 방법을 설명합니다. 다양한 시나리오에 대한 구성을 변경하는 방법에 대한 예제를 제공합니다. 배포에서 구성 파일을 사용하는 방법에 대한 자세한 내용은 배포 지침을 참조하세요.

필수 조건

  • azdata를 설치합니다.

  • 이 섹션의 각 예제에서는 표준 구성 중 하나의 복사본을 만들었다고 가정합니다. 자세한 내용은 사용자 지정 구성 만들기를 참조하세요. 예를 들어 다음 명령은 기본 custom-bdc 구성에 따라 두 개의 JSON 배포 구성 파일을 bdc.jsoncontrol.json 포함하는 디렉터 aks-dev-test 리를 만듭니다.

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

경고

매개 변수 imagePullPolicy 는 배포 프로필 control.json 파일에서와 같이 "Always" 설정해야 합니다.

기본 Docker 레지스트리, 리포지토리 및 이미지 태그 변경

특히 control.json 기본 제공 구성 파일에는 컨테이너 레지스트리, 리포지토리 및 이미지 태그가 미리 채워진 섹션이 포함되어 docker 있습니다. 기본적으로 빅 데이터 클러스터에 필요한 이미지는 리포지토리의 Microsoft Container Registry(mcr.microsoft.com)에 있습니다 mssql/bdc .

{
    "apiVersion": "v1",
    "metadata": {
        "kind": "Cluster",
        "name": "mssql-cluster"
    },
    "spec": {
        "docker": {
            "registry": "mcr.microsoft.com",
            "repository": "mssql/bdc",
            "imageTag": "2019-GDR1-ubuntu-16.04",
            "imagePullPolicy": "Always"
        },
        ...
    }
}

배포하기 전에 docker 설정을 control.json 구성 파일을 직접 편집하거나 azdata bdc config 명령을 사용하여 사용자 지정할 수 있습니다. 예를 들어, 다음 명령은 custom-bdc, <registry>, <repository>을 사용하여 control.json 구성 파일을 업데이트합니다.

azdata bdc config replace -c custom-bdc/control.json -j "$.spec.docker.registry=<registry>"
azdata bdc config replace -c custom-bdc/control.json -j "$.spec.docker.repository=<repository>"
azdata bdc config replace -c custom-bdc/control.json -j "$.spec.docker.imageTag=<image_tag>"

팁 (조언)

버전별 이미지 태그를 반드시 사용하고 latest 이미지 태그의 사용을 피해야 합니다. 그렇지 않으면 클러스터 상태 문제를 일으킬 수 있는 버전 불일치가 발생할 수 있습니다.

팁 (조언)

빅 데이터 클러스터 배포는 컨테이너 이미지를 끌어올 컨테이너 레지스트리 및 리포지토리에 대한 액세스 권한이 있어야 합니다. 사용자 환경에서 기본 Microsoft Container Registry에 액세스할 수 없는 경우 필요한 이미지가 먼저 프라이빗 Docker 리포지토리에 배치되는 오프라인 설치를 수행할 수 있습니다. 오프라인 설치에 대한 자세한 내용은 SQL Server 빅 데이터 클러스터의 오프라인 배포 수행을 참조하세요. 배포 워크플로가 이미지를 프라이빗 리포지토리에서 끌어올 수 있도록 DOCKER_USERNAME 및 DOCKER_PASSWORD환경 변수를 설정해야 한다는 점을 명심하십시오. 이러한 설정은 배포를 실행하기 전에 반드시 이루어져야 합니다.

클러스터 이름 변경

클러스터 이름은 배포에 생성될 빅 데이터 클러스터와 Kubernetes 네임스페이스의 이름입니다. 배포 구성 파일의 bdc.json 다음 부분에 지정됩니다.

"metadata": {
    "kind": "BigDataCluster",
    "name": "mssql-cluster"
},

다음 명령은 키-값 쌍을 매개 변수로 --json-values 보내 빅 데이터 클러스터 이름을 다음과 같이 변경합니다 test-cluster.

azdata bdc config replace --config-file custom-bdc/bdc.json --json-values "metadata.name=test-cluster"

중요합니다

빅 데이터 클러스터의 이름은 소문자 알파 숫자 문자만이어야 하며 공백은 없어야 합니다. 클러스터에 대한 모든 Kubernetes 아티팩트(컨테이너, Pod, 상태 저장 집합, 서비스)는 지정된 클러스터 이름과 동일한 이름의 네임스페이스에 만들어집니다.

엔드포인트 포트 업데이트

엔드포인트는 컨트롤러에 대해 control.json에서 정의되고, 게이트웨이 및 SQL Server 마스터 인스턴스에 대해서는 bdc.json의 해당 섹션에서 정의됩니다. 구성 파일의 control.json 다음 부분에서는 컨트롤러에 대한 엔드포인트 정의를 보여 줍니다.

{
  "endpoints": [
    {
      "name": "Controller",
      "serviceType": "LoadBalancer",
      "port": 30080
    },
    {
      "name": "ServiceProxy",
      "serviceType": "LoadBalancer",
      "port": 30777
    }
  ]
}

다음 예제에서는 인라인 JSON을 사용하여 엔드포인트의 포트를 controller 변경합니다.

azdata bdc config replace --config-file custom-bdc/control.json --json-values "$.spec.endpoints[?(@.name==""Controller"")].port=30000"

스케일 설정

스토리지 풀과 같은 각 리소스의 구성은 구성 파일에 정의됩니다 bdc.json . 예를 들어, bdc.json의 다음 부분은 storage-0 리소스 정의를 보여줍니다.

"storage-0": {
    "metadata": {
        "kind": "Pool",
        "name": "default"
    },
    "spec": {
        "type": "Storage",
        "replicas": 2,
        "settings": {
            "spark": {
                "spark-defaults-conf.spark.driver.memory": "2g",
                "spark-defaults-conf.spark.driver.cores": "1",
                "spark-defaults-conf.spark.executor.instances": "3",
                "spark-defaults-conf.spark.executor.memory": "1536m",
                "spark-defaults-conf.spark.executor.cores": "1",
                "yarn-site.yarn.nodemanager.resource.memory-mb": "18432",
                "yarn-site.yarn.nodemanager.resource.cpu-vcores": "6",
                "yarn-site.yarn.scheduler.maximum-allocation-mb": "18432",
                "yarn-site.yarn.scheduler.maximum-allocation-vcores": "6",
                "yarn-site.yarn.scheduler.capacity.maximum-am-resource-percent": "0.3"
            }
        }
    }
}

각 풀의 값을 수정하여 스토리지, 컴퓨팅 및/또는 데이터 풀의 replicas 인스턴스 수를 구성할 수 있습니다. 다음 예제에서는 인라인 JSON을 사용하여 스토리지, 컴퓨팅 및 데이터 풀에 대한 이러한 값을 각각으로 1044 변경합니다.

azdata bdc config replace --config-file custom-bdc/bdc.json --json-values "$.spec.resources.storage-0.spec.replicas=10"
azdata bdc config replace --config-file custom-bdc/bdc.json --json-values "$.spec.resources.compute-0.spec.replicas=4"
azdata bdc config replace --config-file custom-bdc/bdc.json --json-values "$.spec.resources.data-0.spec.replicas=4"

비고

컴퓨팅 및 데이터 풀에 대해 유효성을 검사하는 최대 인스턴스 수는 각각입니다 8 . 배포 시 이 제한은 적용되지 않지만 프로덕션 배포에서 더 높은 규모를 구성하는 것은 권장되지 않습니다.

스토리지 구성

각 풀에 사용되는 스토리지 클래스 및 특성을 변경할 수도 있습니다. 다음 예제에서는 스토리지 및 데이터 풀에 사용자 지정 스토리지 클래스를 할당하고 데이터를 저장하기 위한 영구 볼륨 클레임의 크기를 HDFS(스토리지 풀)의 경우 500Gb, 마스터 및 데이터 풀의 경우 100Gb로 업데이트합니다.

팁 (조언)

스토리지 구성에 대한 자세한 내용은 Kubernetes의 SQL Server 빅 데이터 클러스터를 사용한 데이터 지속성을 참조하세요.

먼저 스토리지 설정을 조정하는 patch.json 파일을 아래와 같이 만듭니다.

{
        "patch": [
                {
                        "op": "add",
                        "path": "spec.resources.storage-0.spec.storage",
                        "value": {
                                "data": {
                                        "size": "500Gi",
                                        "className": "default",
                                        "accessMode": "ReadWriteOnce"
                                },
                                "logs": {
                                        "size": "30Gi",
                                        "className": "default",
                                        "accessMode": "ReadWriteOnce"
                                }
                        }
                },
        {
                        "op": "add",
                        "path": "spec.resources.master.spec.storage",
                        "value": {
                                "data": {
                                        "size": "100Gi",
                                        "className": "default",
                                        "accessMode": "ReadWriteOnce"
                                },
                                "logs": {
                                        "size": "30Gi",
                                        "className": "default",
                                        "accessMode": "ReadWriteOnce"
                                }
                        }
                },
                {
                        "op": "add",
                        "path": "spec.resources.data-0.spec.storage",
                        "value": {
                                "data": {
                                        "size": "100Gi",
                                        "className": "default",
                                        "accessMode": "ReadWriteOnce"
                                },
                                "logs": {
                                        "size": "30Gi",
                                        "className": "default",
                                        "accessMode": "ReadWriteOnce"
                                }
                        }
                }
        ]
}

그런 다음 azdata bdc config patch 명령을 사용하여 bdc.json 구성 파일을 업데이트할 수 있습니다.

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

비고

기반 kubeadm-dev-test 구성 파일에는 각 풀에 대한 스토리지 정의가 없지만 필요한 경우 위의 프로세스를 사용하여 추가할 수 있습니다.

Spark 없이 스토리지 풀 구성

Spark 없이 실행되도록 스토리지 풀을 구성하고 별도의 Spark 풀을 만들 수도 있습니다. 이 구성을 사용하면 스토리지와 독립적으로 Spark 컴퓨팅 성능을 확장할 수 있습니다. Spark 풀을 구성하는 방법을 보려면 이 문서의 Spark 풀 만들기 섹션을 참조하세요.

비고

Spark 없이 빅 데이터 클러스터를 배포하는 것은 지원되지 않습니다. includeSpark를 true로 설정하거나, 인스턴스가 하나 이상 있는 별도의 Spark 풀을 만들어야 합니다. 또한 Spark가 스토리지 풀(includeSpark 즉 true)에서 실행되고 별도의 Spark 풀을 가질 수도 있습니다.

기본적으로 includeSpark 스토리지 풀 리소스에 대한 설정은 true로 되어 있으므로 변경하려면 includeSpark 필드를 스토리지 구성에 편집해야 합니다. 다음 명령은 인라인 json을 사용하여 이 값을 편집하는 방법을 보여줍니다.

azdata bdc config replace --config-file custom-bdc/bdc.json --json-values "$.spec.resources.storage-0.spec.settings.spark.includeSpark=false"

Spark 풀 생성

또한 Spark 풀을 만들거나 스토리지 풀에서 실행되는 Spark 인스턴스 대신 만들 수 있습니다. 다음 예제에서는 구성 파일을 패치하여 두 개의 인스턴스가 있는 Spark 풀을 bdc.json 만드는 방법을 보여 줍니다.

먼저 아래와 spark-pool-patch.json 같이 파일을 만듭니다.

{
    "patch": [
        {
            "op": "add",
            "path": "spec.resources.spark-0",
            "value": {
                "metadata": {
                    "kind": "Pool",
                    "name": "default"
                },
                "spec": {
                    "type": "Spark",
                    "replicas": 2
                }
            }
        },
        {
            "op": "add",
            "path": "spec.services.spark.resources/-",
            "value": "spark-0"
        },
        {
            "op": "add",
            "path": "spec.services.hdfs.resources/-",
            "value": "spark-0"
        }
    ]
}

그런 다음, 다음 명령을 실행합니다.azdata bdc config patch

azdata bdc config patch -c custom-bdc/bdc.json -p spark-pool-patch.json

Pod 배치를 Kubernetes 레이블로 구성하기

다양한 유형의 워크로드 요구 사항을 수용하기 위해 특정 리소스가 있는 Kubernetes 노드에서 Pod 배치를 제어할 수 있습니다. Kubernetes 레이블을 사용하여 빅 데이터 클러스터 리소스를 배포하는 데 사용할 Kubernetes 클러스터의 노드를 사용자 지정할 수 있을 뿐만 아니라 특정 리소스에 사용되는 노드도 제한할 수 있습니다. 예를 들어 스토리지 풀 리소스 Pod가 더 많은 스토리지가 있는 노드에 배치되는 반면 SQL Server 마스터 인스턴스는 CPU 및 메모리 리소스가 더 높은 노드에 배치되도록 할 수 있습니다. 이 경우 먼저 다양한 유형의 하드웨어를 사용하여 다른 유형의 Kubernetes 클러스터를 빌드한 다음 그에 따라 노드 레이블을 할당합니다 . 빅 데이터 클러스터를 배포할 때 클러스터 수준에서 동일한 레이블을 지정하여 clusterLabel 파일의 control.json 속성을 사용해 빅 데이터 클러스터에 사용되는 노드를 나타낼 수 있습니다. 그런 다음 풀 수준 배치에 다른 레이블이 사용됩니다. 이러한 레이블은 특성을 사용하여 nodeLabel 빅 데이터 클러스터 배포 구성 파일에서 지정할 수 있습니다. Kubernetes는 지정된 레이블과 일치하는 노드에 Pod를 할당합니다. kubernetes 클러스터의 노드에 추가해야 하는 특정 레이블 키는 mssql-cluster (빅 데이터 클러스터에 사용되는 노드를 나타내기 위한) 및 mssql-resource (다양한 리소스에 대해 Pod가 배치되는 특정 노드를 나타내기 위해) 있습니다. 이러한 레이블의 값은 선택한 모든 문자열일 수 있습니다.

비고

Pod가 노드 수준의 메트릭을 수집하는 특성으로 인해, 레이블 metricsdc이 있는 모든 노드에 Pod가 배포되며 mssql-cluster는 이러한 Pod에 적용되지 않습니다.

다음 예제에서는 전체 빅 데이터 클러스터에 대한 노드 레이블bdc, 특정 노드에 SQL Server 마스터 인스턴스 Pod를 배치하는 레이블, 스토리지 풀 리소스bdc-master, bdc-storage-pool 컴퓨팅 풀 및 데이터 풀 Pod bdc-compute-pool 및 나머지 리소스에 대한 레이블 bdc-shared 을 포함하도록 사용자 지정 구성 파일을 편집하는 방법을 보여 줍니다.

먼저 Kubernetes 노드에 레이블을 지정합니다.

kubectl label node <kubernetesNodeName1> mssql-cluster=bdc mssql-resource=bdc-shared --overwrite=true
kubectl label node <kubernetesNodeName2> mssql-cluster=bdc mssql-resource=bdc-master --overwrite=true
kubectl label node <kubernetesNodeName3> mssql-cluster=bdc mssql-resource=bdc-compute-pool --overwrite=true
kubectl label node <kubernetesNodeName4> mssql-cluster=bdc mssql-resource=bdc-compute-pool --overwrite=true
kubectl label node <kubernetesNodeName5> mssql-cluster=bdc mssql-resource=bdc-storage-pool --overwrite=true
kubectl label node <kubernetesNodeName6> mssql-cluster=bdc mssql-resource=bdc-storage-pool --overwrite=true
kubectl label node <kubernetesNodeName7> mssql-cluster=bdc mssql-resource=bdc-storage-pool --overwrite=true
kubectl label node <kubernetesNodeName8> mssql-cluster=bdc mssql-resource=bdc-storage-pool --overwrite=true

그런 다음, 레이블 값을 포함하도록 클러스터 배포 구성 파일을 업데이트합니다. 이 예제에서는 프로필에서 custom-bdc 구성 파일을 사용자 지정한다고 가정합니다. 기본적으로 기본 제공 구성에는 nodeLabel 및 clusterLabel 키가 없으므로 사용자 지정 구성 파일을 수동으로 편집하거나 azdata bdc config add 명령을 사용하여 필요한 편집을 수행해야 합니다.

azdata bdc config add -c custom-bdc/control.json -j "$.spec.clusterLabel=bdc"
azdata bdc config add -c custom-bdc/control.json -j "$.spec.nodeLabel=bdc-shared"

azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.master.spec.nodeLabel=bdc-master"
azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.compute-0.spec.nodeLabel=bdc-compute-pool"
azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.data-0.spec.nodeLabel=bdc-compute-pool"
azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.storage-0.spec.nodeLabel=bdc-storage-pool"

# below can be omitted in which case we will take the node label default from the control.json
azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.nmnode-0.spec.nodeLabel=bdc-shared"
azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.sparkhead.spec.nodeLabel=bdc-shared"
azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.zookeeper.spec.nodeLabel=bdc-shared"
azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.gateway.spec.nodeLabel=bdc-shared"
azdata bdc config add -c custom-bdc/bdc.json -j "$.spec.resources.appproxy.spec.nodeLabel=bdc-shared"

비고

모범 사례에서는 Kubernetes 마스터에게 위의 BDC 역할을 제공하지 않습니다. 이러한 역할을 Kubernetes 마스터 노드에 할당하려는 경우 해당 taint를 제거 master:NoSchedule 해야 합니다. 이렇게 하면 마스터 노드가 오버로드되고 대규모 클러스터에서 Kubernetes 관리 업무를 수행하는 기능이 억제될 수 있습니다. 모든 배포에서 마스터 노드에 예약된 일부 Pod를 보는 것은 일반적인 일입니다. 이 Pod들은 이미 master:NoSchedule 오염을 수용하여 클러스터 관리에 주로 사용됩니다.

JSON 패치 파일을 사용하는 기타 사용자 지정

JSON 패치 파일은 한 번에 여러 설정을 구성합니다. JSON 패치에 대한 자세한 내용은 Python의 JSON 패치 및 JSONPath Online 평가기를 참조하세요.

다음 patch.json 파일은 다음 변경 내용을 수행합니다.

  • control.json에서 단일 엔드포인트의 포트를 업데이트합니다.
{
  "patch": [
    {
      "op": "replace",
      "path": "$.spec.endpoints[?(@.name=='Controller')].port",
      "value": 30000
    }
  ]
}
  • port에서 모든 엔드포인트(serviceType 및 control.json)를 업데이트합니다.
{
  "patch": [
    {
      "op": "replace",
      "path": "spec.endpoints",
      "value": [
        {
          "serviceType": "LoadBalancer",
          "port": 30001,
          "name": "Controller"
        },
        {
          "serviceType": "LoadBalancer",
          "port": 30778,
          "name": "ServiceProxy"
        }
      ]
    }
  ]
}
  • 에서 컨트롤러 스토리지 설정을 업데이트합니다 control.json. 이러한 설정은 풀 수준에서 재정의되지 않는 한 모든 클러스터 구성 요소에 적용할 수 있습니다.
{
  "patch": [
    {
      "op": "replace",
      "path": "spec.storage",
      "value": {
        "data": {
          "className": "managed-premium",
          "accessMode": "ReadWriteOnce",
          "size": "100Gi"
        },
        "logs": {
          "className": "managed-premium",
          "accessMode": "ReadWriteOnce",
          "size": "32Gi"
        }
      }
    }
  ]
}
  • 에서 스토리지 클래스 이름을 업데이트합니다 control.json.
{
  "patch": [
    {
      "op": "replace",
      "path": "spec.storage.data.className",
      "value": "managed-premium"
    }
  ]
}
  • 스토리지 풀 bdc.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"
          }
        }
      }
    }
  ]
}
  • bdc.json에서 스토리지 풀에 대한 Spark 설정을 업데이트합니다.
{
  "patch": [
    {
      "op": "replace",
      "path": "spec.services.spark.settings",
      "value": {
            "spark-defaults-conf.spark.driver.memory": "2g",
            "spark-defaults-conf.spark.driver.cores": "1",
            "spark-defaults-conf.spark.executor.instances": "3",
            "spark-defaults-conf.spark.executor.memory": "1536m",
            "spark-defaults-conf.spark.executor.cores": "1",
            "yarn-site.yarn.nodemanager.resource.memory-mb": "18432",
            "yarn-site.yarn.nodemanager.resource.cpu-vcores": "6",
            "yarn-site.yarn.scheduler.maximum-allocation-mb": "18432",
            "yarn-site.yarn.scheduler.maximum-allocation-vcores": "6",
            "yarn-site.yarn.scheduler.capacity.maximum-am-resource-percent": "0.3"
      }
    }
  ]
}

팁 (조언)

배포 구성 파일을 변경하는 구조 및 옵션에 대한 자세한 내용은 빅 데이터 클러스터에 대한 배포 구성 파일 참조를 참조하세요.

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

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

권한 있는 모드에서 실행되도록 ElasticSearch 사용 안 함

기본적으로 ElasticSearch 컨테이너는 빅 데이터 클러스터의 권한 모드에서 실행됩니다. 이 설정을 사용하면 컨테이너 초기화 시 ElasticSearch가 더 많은 양의 로그를 처리할 때 필요한 호스트에 대한 설정을 업데이트할 수 있는 충분한 권한이 컨테이너에 있습니다. 이 항목에 대한 자세한 내용은 이 문서에서 확인할 수 있습니다.

권한 있는 모드에서 실행하는 ElasticSearch 컨테이너를 비활성화하려면 섹션 settings을 업데이트하고 control.json에서 vm.max_map_count의 값을 -1으로 지정해야 합니다. 다음은 이 섹션의 모양에 대한 샘플입니다.

{
    "apiVersion": "v1",
    "metadata": {...},
    "spec": {
        "docker": {...},
        "storage": {...},
        "endpoints": [...],
        "settings": {
            "ElasticSearch": {
                "vm.max_map_count": "-1"
            }
        }
    }
}

먼저 control.json 파일을 수동으로 편집하여 위의 섹션을 추가하거나, 아래처럼 패치 파일 spec을 만든 후 Azure Data CLI(elasticsearch-patch.json)를 사용하여 azdata 파일을 패치할 수 있습니다.

{
  "patch": [
    {
      "op": "add",
      "path": "spec.settings",
      "value": {
            "ElasticSearch": {
                "vm.max_map_count": "-1"
        }
      }
    }
  ]
}

이 명령을 실행하여 구성 파일을 패치합니다.

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

중요합니다

max_map_count 지침에 따라 Kubernetes 클러스터의 각 호스트에서 설정을 수동으로 업데이트하는 것이 좋습니다.

Pod 및 노드의 메트릭 수집 활성화/비활성화

SQL Server 2019 CU5는 Pod 및 노드 메트릭의 컬렉션을 제어하는 두 가지 기능 스위치를 사용하도록 설정했습니다. Kubernetes 인프라를 모니터링하기 위해 다른 솔루션을 사용하는 경우 control.json배포 구성 파일에서 allowNodeMetricsCollection 및 allowPodMetricsCollection을 false로 설정하여 Pod 및 호스트 노드에 대한 기본 제공 메트릭 컬렉션을 해제할 수 있습니다. OpenShift 환경의 경우 Pod 및 노드 메트릭을 수집하려면 권한 있는 기능이 필요하므로 기본 제공 배포 프로필에서 이러한 설정은 기본적으로 false 로 설정됩니다. 다음 명령을 실행하여 azdata CLI를 사용하여 사용자 지정 구성 파일에서 이러한 설정의 값을 업데이트합니다.

 azdata bdc config replace -c custom-bdc/control.json -j "$.security.allowNodeMetricsCollection=false"
 azdata bdc config replace -c custom-bdc/control.json -j "$.security.allowPodMetricsCollection=false"

다음 단계

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