Udostępnij za pośrednictwem

Konfigurowanie ustawień wdrażania dla zasobów i usług klastra danych big data

  • Artykuł

Dotyczy: SQL Server 2019 (15.x)

Ważny

Dodatek Microsoft SQL Server 2019 Big Data Clusters zostanie wycofany. Obsługa klastrów danych big data programu SQL Server 2019 zakończy się 28 lutego 2025 r. Wszyscy istniejący użytkownicy programu SQL Server 2019 z pakietem Software Assurance będą w pełni obsługiwani na platformie, a oprogramowanie będzie nadal utrzymywane za pośrednictwem aktualizacji zbiorczych programu SQL Server do tego czasu. Aby uzyskać więcej informacji, zobacz post ogłoszeniowy na blogu i opcje big data na platformie Microsoft SQL Server.

Począwszy od wstępnie zdefiniowanego zestawu profilów konfiguracji wbudowanych w narzędzie do zarządzania interfejsem wiersza polecenia usługi Azure Data (azdata), można łatwo zmodyfikować ustawienia domyślne, aby lepiej dopasować je do wymagań dotyczących obciążenia usługi BDC. Struktura plików konfiguracji umożliwia szczegółowe aktualizowanie ustawień dla każdej usługi zasobu.

Notatka

Klastry danych big data w wersji CU9+ mają obsługę funkcji zarządzania konfiguracją. Ta funkcja umożliwia konfiguracje po wdrożeniu i zapewnia większą widoczność i możliwość konfigurowania klastra. Wersje CU8 i niższe nie mają tej funkcji, a konfiguracje można wykonywać tylko w czasie wdrażania.

Obejrzyj ten 13-minutowy film wideo, aby uzyskać omówienie konfiguracji klastra danych big data:

Napiwek

Zapoznaj się z artykułami dotyczącymi konfigurowania wysokiej dostępności dla składników o krytycznym znaczeniu, takich jak baza danych master w SQL Server lub name node HDFS , aby uzyskać szczegółowe informacje na temat wdrażania usług o wysokiej dostępności.

Napiwek

Zapoznaj się z artykułem Właściwości konfiguracji klastrów danych big data programu SQL Server, aby zobaczyć, jakie ustawienia można konfigurować. W przypadku wersji CU8 lub niższych zapoznaj się z Właściwości konfiguracji wystąpienia głównego programu SQL Server — wersji wstępnej CU9 dla konfiguracji dostępnych dla wystąpienia głównego programu SQL Server oraz Właściwości konfiguracji Apache Spark & Apache Hadoop (HDFS) dla właściwości Apache Spark i Apache Hadoop.

Można również ustawić konfiguracje na poziomie zasobów lub zaktualizować konfiguracje dla wszystkich usług w zasobie. Oto podsumowanie struktury 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": {...
            }
        }
    }
}

Aby zaktualizować konfiguracje na poziomie zasobów, takie jak wystąpienia w puli, zaktualizuj specyfikację zasobu. Aby na przykład zaktualizować liczbę wystąpień w puli obliczeniowej, zmodyfikujesz tę sekcję w pliku konfiguracji bdc.json:

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

Podobnie w przypadku zmiany ustawień pojedynczej usługi w ramach określonego zasobu. Jeśli na przykład chcesz zmienić ustawienia pamięci Sparka tylko dla składnika Spark w puli magazynowania, zaktualizuj zasób storage-0 za pomocą sekcji settings dla usługi spark w pliku konfiguracji 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"
                }
            }
        }
    }
    ...
}

Jeśli chcesz zastosować te same konfiguracje dla usługi skojarzonej z wieloma zasobami, zaktualizujesz odpowiednie settings w sekcji services. Jeśli na przykład chcesz ustawić te same ustawienia dla platformy Spark zarówno dla puli pamięci masowej, jak i pul Spark, zaktualizujesz sekcję settings w sekcji usługi spark w pliku konfiguracji 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"
        }
    }
    ...
}

Aby dostosować pliki konfiguracji wdrożenia klastra, możesz użyć dowolnego edytora formatu JSON, takiego jak VSCode. Przy tworzeniu skryptów do celów automatyzacji, użyj polecenia azdata bdc config. W tym artykule wyjaśniono, jak skonfigurować wdrożenia klastra danych big data przez zmodyfikowanie plików konfiguracji wdrożenia. Zawiera przykłady zmiany konfiguracji dla różnych scenariuszy. Aby uzyskać więcej informacji na temat sposobu użycia plików konfiguracji we wdrożeniach, zobacz wskazówki dotyczące wdrażania .

Warunki wstępne

  • Zainstaluj azdata.

  • W każdym z przykładów w tej sekcji założono, że utworzono kopię jednej ze standardowych konfiguracji. Aby uzyskać więcej informacji, zobacz Tworzenie konfiguracji niestandardowej. Na przykład następujące polecenie tworzy katalog o nazwie custom-bdc zawierający dwa pliki konfiguracji wdrożenia JSON, bdc.json i control.json, na podstawie domyślnej konfiguracji aks-dev-test:

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

Ostrzeżenie

Parametr imagePullPolicy musi być ustawiony jako "Always" w pliku control.json profilu wdrożenia.

Zmienianie domyślnego rejestru platformy Docker, repozytorium i tagu images

Wbudowane pliki konfiguracji, w szczególności control.json, zawierają sekcję docker, w której rejestr kontenerów, repozytorium i tagi obrazów są wstępnie wypełnione. Domyślnie obrazy wymagane dla klastrów danych big data znajdują się w usłudze Microsoft Container Registry (mcr.microsoft.com), w repozytorium 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"
        },
        ...
    }
}

Przed wdrożeniem można dostosować ustawienia docker, edytując bezpośrednio plik konfiguracji control.json lub używając poleceń azdata bdc config. Na przykład następujące polecenia aktualizują plik konfiguracji custom-bdc control.json przy użyciu innego <registry>, <repository> i <image_tag>:

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>"

Napiwek

Najlepszym rozwiązaniem jest użycie tagu obrazu specyficznego dla wersji i unikanie używania tagu obrazu latest, ponieważ może to spowodować niezgodność wersji, która spowoduje problemy z kondycją klastra.

Napiwek

Wdrożenie klastrów danych big data musi mieć dostęp do rejestru kontenerów i repozytorium, z którego mają zostać pobrane obrazy kontenerów. Jeśli środowisko nie ma dostępu do domyślnego rejestru microsoft Container Registry, możesz przeprowadzić instalację w trybie offline, w której wymagane obrazy są najpierw umieszczane w prywatnym repozytorium platformy Docker. Aby uzyskać więcej informacji na temat instalacji w trybie offline, zobacz Wykonywanie wdrożenia klastra danych big data programu SQL Server w trybie offline. Należy pamiętać, że należy ustawić zmienne środowiskowe DOCKER_USERNAME i DOCKER_PASSWORD przed wydaniem wdrożenia, aby upewnić się, że przepływ pracy wdrażania ma dostęp do repozytorium prywatnego w celu ściągnięcia obrazów.

Zmienianie nazwy klastra

Nazwa klastra to zarówno nazwa klastra danych big data, jak i przestrzeni nazw Kubernetes, która zostanie utworzona we wdrożeniu. Jest on określony w następującej części pliku konfiguracji wdrożenia bdc.json:

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

Następujące polecenie wysyła parę klucz-wartość do parametru --json-values, aby zmienić nazwę klastra danych big data na test-cluster:

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

Ważny

Nazwa klastra danych big data musi mieć tylko małe litery alfanumeryczne, bez spacji. Wszystkie artefakty Kubernetes (kontenery, zasobniki, zestawy z zachowaniem stanu, usługi) dla klastra zostaną utworzone w przestrzeni nazw o nazwie takiej samej jak określona nazwa klastra.

Aktualizowanie portów punktu końcowego

Punkty końcowe są definiowane dla kontrolera w control.json oraz dla bramy i wystąpienia głównego programu SQL Server w odpowiednich sekcjach w bdc.json. W poniższej części pliku konfiguracji control.json przedstawiono definicje punktów końcowych dla kontrolera:

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

W poniższym przykładzie użyto wbudowanego kodu JSON w celu zmiany portu dla punktu końcowego controller:

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

Konfigurowanie skalowania

Konfiguracje poszczególnych zasobów, takich jak pula magazynów, są zdefiniowane w pliku konfiguracji bdc.json. Na przykład następująca część bdc.json przedstawia definicję zasobu 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"
            }
        }
    }
}

Można skonfigurować liczbę wystąpień w puli przechowywania, obliczeniowej i/lub danych, modyfikując wartość replicas dla każdej z tych pul. W poniższym przykładzie użyto wbudowanego kodu JSON, aby zmienić te wartości dla magazynu, zasobów obliczeniowych i pul danych na odpowiednio 10, 4 i 4:

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"

Notatka

Maksymalna liczba wystąpień zweryfikowanych dla zasobów obliczeniowych i pul danych wynosi 8 każda. Nie ma wymuszania tego limitu w czasie wdrażania, ale nie zalecamy konfigurowania wyższej skali we wdrożeniach produkcyjnych.

Konfigurowanie magazynu

Możesz także zmienić klasę pamięci masowej oraz cechy przypisane każdej puli. W poniższym przykładzie przypisano niestandardową klasę magazynowania do puli przechowywania i puli danych oraz zaktualizowano rozmiar żądania trwałego woluminu do przechowywania danych na 500 Gb dla puli przechowywania HDFS i 100 Gb dla puli głównej oraz puli danych.

Napiwek

Aby uzyskać więcej informacji na temat konfiguracji magazynu, zobacz Trwałość danych w klastrze danych big data programu SQL Server na platformie Kubernetes.

Najpierw utwórz plik patch.json, tak jak poniżej, aby dostosować ustawienia magazynu 

{
        "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"
                                }
                        }
                }
        ]
}

Następnie możesz użyć polecenia azdata bdc config patch, aby zaktualizować plik konfiguracji bdc.json.

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

Notatka

Plik konfiguracji oparty na kubeadm-dev-test nie ma definicji magazynu dla każdej puli, ale w razie potrzeby można wykorzystać powyższy proces, aby to dodać.

Konfigurowanie puli pamięci masowej bez Spark

Zasobniki pamięci masowej można również skonfigurować do uruchamiania bez Spark i utworzyć oddzielną pulę Spark. Ta konfiguracja umożliwia skalowanie mocy obliczeniowej platformy Spark niezależnie od magazynu. Aby dowiedzieć się, jak skonfigurować pulę platformy Spark, zobacz sekcję Tworzenie puli platformy Spark w tym artykule.

Nota

Wdrażanie klastra danych big data bez platformy Spark nie jest obsługiwane. Musisz mieć includeSpark ustawioną na true lub utworzyć oddzielną pulę Spark z co najmniej jednym wystąpieniem. Możesz również uruchomić platformę Spark zarówno w puli magazynów (includeSpark jest true) i mieć oddzielną pulę Spark.

Domyślnie ustawienie includeSpark dla zasobu puli pamięci jest ustawione na wartość 'true', w związku z tym należy edytować pole includeSpark w konfiguracji pamięci, aby wprowadzić zmiany. Poniższe polecenie pokazuje, jak edytować tę wartość przy użyciu wbudowanego kodu json.

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

Tworzenie puli Spark

Ponadto można utworzyć pulę platformy Spark lub zamiast tego, wystąpienia Spark mogą działać w puli przechowywania. W poniższym przykładzie pokazano, jak utworzyć pulę spark z dwoma wystąpieniami, stosując poprawki do pliku konfiguracji bdc.json.

Najpierw utwórz plik spark-pool-patch.json, jak pokazano poniżej:

{
    "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"
        }
    ]
}

Następnie uruchom polecenie azdata bdc config patch:

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

Konfigurowanie umieszczania podów przy użyciu etykiet Kubernetes

Możesz kontrolować umieszczanie zasobników w węzłach Kubernetes, które mają określone zasoby, aby uwzględnić różne typy wymagań obciążenia. Za pomocą etykiet kubernetes można dostosować węzły w klastrze Kubernetes do wdrażania zasobów klastra danych big data, ale także ograniczyć, które węzły są używane dla określonych zasobów. Na przykład możesz upewnić się, że podyzasobów puli magazynowej są umieszczane na węzłach z większą ilością przestrzeni magazynowej, podczas gdy instancje nadrzędne SQL Server są umieszczane na węzłach, które mają wyższą moc obliczeniową CPU i większe zasoby pamięci. W takim przypadku najpierw utworzysz heterogeniczny klaster Kubernetes z różnymi typami sprzętu, a następnie odpowiednio przypisać etykiety węzłów. W momencie wdrażania klastra danych big data można określić te same etykiety na poziomie klastra, aby wskazać, które węzły są używane do klastra danych big data przy użyciu atrybutu clusterLabel w pliku control.json. Następnie do rozmieszczania na poziomie puli będą stosowane różne etykiety. Te etykiety można określić w plikach konfiguracji wdrożenia klastra danych big data przy użyciu atrybutu nodeLabel. Platforma Kubernetes przypisuje zasobniki w węzłach, które są zgodne z określonymi etykietami. Określone klucze etykiet, które należy dodać do węzłów w klastrze Kubernetes, to mssql-cluster (wskazujące, które węzły są używane do klastrów big data) i mssql-resource (aby wskazać, na których konkretnych węzłach rozmieszczane są pody dla różnych zasobów). Wartości tych etykiet mogą być dowolnym wybranym ciągiem.

Notatka

Ze względu na charakter podów, które realizują zbieranie metryk na poziomie węzła, pody metricsdc są wdrażane na wszystkich węzłach z etykietą mssql-cluster, a mssql-resource nie będą stosowane do tych podów.

"Poniższy przykład pokazuje, jak edytować niestandardowy plik konfiguracji, aby uwzględnić etykietę węzła bdc dla całego klastra big data, etykietę bdc-master do umieszczania zasobów instancji głównych programu SQL Server na określonym węźle, etykietę bdc-storage-pool dla zasobów puli pamięci masowej, etykietę bdc-compute-pool dla zasobów puli obliczeniowej i puli danych, oraz etykietę bdc-shared dla pozostałych zasobów."

Najpierw oznacz węzły 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

Następnie zaktualizuj pliki konfiguracji wdrożenia klastra, aby uwzględnić wartości etykiet. W tym przykładzie przyjęto założenie, że pliki konfiguracji są dostosowywane w profilu custom-bdc. Domyślnie w wbudowanych konfiguracjach nie ma nodeLabel i clusterLabel kluczy, dlatego konieczne będzie ręczne edytowanie niestandardowego pliku konfiguracji lub użycie poleceń azdata bdc config add w celu dokonania niezbędnych zmian.

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"

Notatka

Należy unikać przypisywania serwerowi Kubernetes którejkolwiek z powyższych ról BDC. Jeśli mimo to planujesz przypisanie tych ról do węzła głównego platformy Kubernetes, musisz usunąć jego master:NoSchedule defekt. Należy pamiętać, że może to spowodować przeciążenie węzła głównego i zahamowanie możliwości wykonywania obowiązków związanych z zarządzaniem platformą Kubernetes w większych klastrach. Normalne jest, że niektóre zasobniki są planowane do węzła głównego przy dowolnym wdrożeniu: one już tolerują skażenie master:NoSchedule i najczęściej są używane do zarządzania klastrem.

Inne dostosowania korzystające z plików poprawek JSON

Pliki poprawek JSON konfigurują wiele ustawień jednocześnie. Aby uzyskać więcej informacji na temat poprawek JSON, zobacz JSON Patches w języku Python i JSONPath Online Evaluator.

Następujące pliki patch.json wykonują następujące zmiany:

  • Zaktualizuj port pojedynczego punktu końcowego w control.json.
{
  "patch": [
    {
      "op": "replace",
      "path": "$.spec.endpoints[?(@.name=='Controller')].port",
      "value": 30000
    }
  ]
}
  • Zaktualizuj wszystkie punkty końcowe (port i serviceType) w control.json.
{
  "patch": [
    {
      "op": "replace",
      "path": "spec.endpoints",
      "value": [
        {
          "serviceType": "LoadBalancer",
          "port": 30001,
          "name": "Controller"
        },
        {
          "serviceType": "LoadBalancer",
          "port": 30778,
          "name": "ServiceProxy"
        }
      ]
    }
  ]
}
  • Zaktualizuj ustawienia pamięci kontrolera w control.json. Te ustawienia mają zastosowanie do wszystkich składników klastra, chyba że zostaną zastąpione na poziomie puli.
{
  "patch": [
    {
      "op": "replace",
      "path": "spec.storage",
      "value": {
        "data": {
          "className": "managed-premium",
          "accessMode": "ReadWriteOnce",
          "size": "100Gi"
        },
        "logs": {
          "className": "managed-premium",
          "accessMode": "ReadWriteOnce",
          "size": "32Gi"
        }
      }
    }
  ]
}
  • Zaktualizuj nazwę klasy pamięci w control.json.
{
  "patch": [
    {
      "op": "replace",
      "path": "spec.storage.data.className",
      "value": "managed-premium"
    }
  ]
}
  • Zaktualizuj ustawienia puli danych magazynowych dla puli magazynowej w 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"
          }
        }
      }
    }
  ]
}
  • Zaktualizuj ustawienia Spark dla puli magazynowej w bdc.json.
{
  "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"
      }
    }
  ]
}

Napiwek

Aby uzyskać więcej informacji na temat struktury i opcji zmiany pliku konfiguracji wdrożenia, zobacz Dokumentacja pliku konfiguracji wdrożenia dla klastrów danych big data.

Użyj poleceń azdata bdc config, aby zastosować zmiany w pliku poprawek JSON. Poniższy przykład stosuje plik patch.json do docelowego pliku konfiguracji wdrożenia custom-bdc/bdc.json.

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

Wyłącz ElasticSearch, aby działał w trybie uprzywilejowanym

Domyślnie kontener ElasticSearch działa w trybie uprawnień w klastrze danych big data. To ustawienie zapewnia, że w czasie inicjowania kontenera kontener ma wystarczające uprawnienia, aby zaktualizować ustawienie na hoście wymaganym, gdy usługa ElasticSearch przetwarza większą ilość dzienników. Więcej informacji na temat tego tematu można znaleźć w tym artykule.

Aby wyłączyć kontener uruchamiający ElasticSearch z trybu uprzywilejowanego, należy zaktualizować sekcję settings w control.json i ustawić wartość vm.max_map_count na -1. Poniżej przedstawiono przykładowy wygląd tej sekcji:

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

Możesz ręcznie edytować control.json i dodać powyższą sekcję do speclub utworzyć plik poprawki elasticsearch-patch.json, jak pokazano poniżej, i użyć interfejsu wiersza polecenia platformy Azure (azdata), aby zastosować poprawkę pliku control.json:

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

Uruchom to polecenie, aby zastosować poprawkę pliku konfiguracji:

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

Ważny

Zalecamy, jako najlepszą praktykę, ręczne aktualizowanie ustawienia max_map_count na każdym hoście w klastrze Kubernetes zgodnie z instrukcjami zawartymi w tym artykule.

Włączanie/wyłączanie zbierania metryk zasobników i węzłów

Program SQL Server 2019 CU5 włączył dwa przełączniki funkcji w celu kontrolowania zbierania metryk z podów i węzłów. Jeśli używasz różnych rozwiązań do monitorowania infrastruktury Kubernetes, możesz wyłączyć wbudowane zbieranie metryk dla podów i węzłów, ustawiając allowNodeMetricsCollection i allowPodMetricsCollection na false w pliku konfiguracji wdrożenia control.json. W przypadku środowisk OpenShift te ustawienia są domyślnie ustawione na false w wbudowanych profilach wdrażania, ponieważ zbieranie metryk podów i węzłów wymaga uprzywilejowanych uprawnień. Uruchom to polecenie, aby zaktualizować wartości tych ustawień w niestandardowym pliku konfiguracyjnym przy użyciu 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"

Następne kroki

Aby uzyskać więcej informacji na temat używania plików konfiguracji we wdrożeniach klastra danych big data, zobacz Jak wdrożyć klastry danych big data programu SQL Server na platformie Kubernetes.