Distribuire BDC nel cluster privato del servizio Azure Kubernetes

2023-12-04

Importante

Il componente aggiuntivo Cluster Big Data di Microsoft SQL Server 2019 verrà ritirato. Il supporto per i cluster Big Data di SQL Server 2019 terminerà il 28 febbraio 2025. Tutti gli utenti esistenti di SQL Server 2019 con Software Assurance saranno completamente supportati nella piattaforma e il software continuerà a essere mantenuto tramite gli aggiornamenti cumulativi di SQL Server fino a quel momento. Per ulteriori informazioni, vedere il post di blog sull'annuncio e le opzioni di Big Data sulla piattaforma Microsoft SQL Server.

Questo articolo illustra come distribuire cluster Big Data di SQL Server nel cluster privato del servizio Azure Kubernetes. Questa configurazione supporta l'uso limitato di indirizzi IP pubblici nell'ambiente di rete aziendale.

Una distribuzione privata offre i vantaggi seguenti:

Uso limitato di indirizzi IP pubblici
Il traffico di rete tra server applicazioni e pool di nodi del cluster rimane solo nella rete privata
Configurazione personalizzata per il traffico in uscita obbligatorio per soddisfare requisiti specifici

Questo articolo illustra come usare un cluster privato del servizio Azure Kubernetes per limitare l'uso dell'indirizzo IP pubblico mentre sono state applicate le rispettive stringhe di sicurezza.

Distribuire un cluster Big Data privato con un cluster privato di AKS

Per iniziare, creare un cluster privato del servizio Azure Kubernetes per assicurarsi che il traffico di rete tra il server API e i pool di nodi rimanga solo nella rete privata. Piano di controllo o server API ha indirizzi IP interni in un cluster privato AKS.

Questa sezione illustra la distribuzione di un cluster Big Data nel cluster privato del servizio Azure Kubernetes con funzionalità di rete avanzate (CNI).

Creare un cluster AKS privato con rete avanzata


export REGION_NAME=<your Azure region >
export RESOURCE_GROUP=< your resource group name >
export SUBNET_NAME=aks-subnet
export VNET_NAME=bdc-vnet
export AKS_NAME=< your aks private cluster name >
 
az group create -n $RESOURCE_GROUP -l $REGION_NAME
 
az network vnet create \
    --resource-group $RESOURCE_GROUP \
    --location $REGION_NAME \
    --name $VNET_NAME \
    --address-prefixes 10.0.0.0/8 \
    --subnet-name $SUBNET_NAME \
    --subnet-prefix 10.1.0.0/16
 

SUBNET_ID=$(az network vnet subnet show \
    --resource-group $RESOURCE_GROUP \
    --vnet-name $VNET_NAME \
    --name $SUBNET_NAME \
    --query id -o tsv)
 
echo $SUBNET_ID
## will be displayed something similar as the following: 
/subscriptions/xxxx-xxxx-xxx-xxxx-xxxxxxxx/resourceGroups/your-bdc-rg/providers/Microsoft.Network/virtualNetworks/your-aks-vnet/subnets/your-aks-subnet

Creare un cluster privato AKS con rete avanzata (CNI)

Per poter passare al passaggio successivo, è necessario configurare un cluster AKS con Load Balancer Standard e la funzionalità di cluster privato abilitata. Il comando sarà simile al seguente:

az aks create \
    --resource-group $RESOURCE_GROUP \
    --name $AKS_NAME \
    --load-balancer-sku standard \
    --enable-private-cluster \
    --network-plugin azure \
    --vnet-subnet-id $SUBNET_ID \
    --docker-bridge-address 172.17.0.1/16 \
    --dns-service-ip 10.2.0.10 \
    --service-cidr 10.2.0.0/24 \
    --node-vm-size Standard_D13_v2 \
    --node-count 2 \
    --generate-ssh-keys

Dopo aver completato la distribuzione, è possibile passare al <MC_yourakscluster> gruppo di risorse e si troverà che kube-apiserver è un endpoint privato. Ad esempio, vedere la sezione seguente.

Connettersi a un cluster AKS

az aks get-credentials -n $AKS_NAME -g $RESOURCE_GROUP

Creare un profilo di distribuzione del cluster Big Data

Dopo la connessione a un cluster del servizio Azure Kubernetes, è possibile iniziare a distribuire BDC ed è possibile preparare la variabile di ambiente e avviare una distribuzione:

azdata bdc config init --source aks-dev-test --target private-bdc-aks --force

Generare e configurare il profilo di distribuzione personalizzato BDC:

azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.docker.imageTag=2019-CU6-ubuntu-16.04"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.storage.data.className=default"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.storage.logs.className=default"

azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/control.json -j "$.spec.endpoints[1].serviceType=NodePort"

azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.master.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.gateway.spec.endpoints[0].serviceType=NodePort"
azdata bdc config replace -c private-bdc-aks/bdc.json -j "$.spec.resources.appproxy.spec.endpoints[0].serviceType=NodePort"

Distribuire un cluster Big Data di SQL Server privato con disponibilità elevata

Se si distribuisce un cluster Big Data di SQL Server (SQL-BDC) con disponibilità elevata, si userà il profilo di distribuzione di distribuzione aks-dev-test-ha . Dopo aver completato la distribuzione, è possibile usare lo stesso kubectl get svc comando e verrà visualizzato un servizio aggiuntivo master-secondary-svc creato. È necessario configurare ServiceType come NodePort. Altri passaggi saranno simili a quanto indicato nella sezione precedente.

L'esempio seguente imposta ServiceType come NodePort.

azdata bdc config replace -c private-bdc-aks /bdc.json -j "$.spec.resources.master.spec.endpoints[1].serviceType=NodePort"

Distribuire il BDC in un cluster privato di AKS

export AZDATA_USERNAME=<your bdcadmin username>
export AZDATA_PASSWORD=< your bdcadmin password>

azdata bdc create --config-profile private-bdc-aks --accept-eula yes

Controllare lo stato della distribuzione

La distribuzione richiederà alcuni minuti ed è possibile usare il comando seguente per controllare lo stato della distribuzione:

kubectl get pods -n mssql-cluster -w

Controllare lo stato del servizio

Usare il comando seguente per controllare i servizi. Verificare che siano tutti integri senza indirizzi IP esterni:

kubectl get services -n mssql-cluster

Scopri come gestire il cluster Big Data nel cluster privato di AKS e quindi, nel passaggio successivo, connettersi a un cluster Big Data di SQL Server.

Vedere script di automazione per questo scenario nel repository di esempi di SQL Server in GitHub.

Condividi tramite