Compartilhar via

Implantar Clusters de Big Data do SQL Server no OpenShift local e no Red Hat OpenShift no Azure

  • Artigo

Aplica-se a: SQL Server 2019 (15.x)

Importante

O complemento Clusters de Big Data do Microsoft SQL Server 2019 será desativado. O suporte para Clusters de Big Data do SQL Server 2019 será encerrado em 28 de fevereiro de 2025. Todos os usuários existentes do SQL Server 2019 com Software Assurance terão suporte total na plataforma e o software continuará a ser mantido por meio de atualizações cumulativas do SQL Server até esse momento. Para obter mais informações, confira a postagem no blog de anúncio e as opções de Big Data na plataforma do Microsoft SQL Server.

Este artigo explica como implantar um Cluster de Big Data do SQL Server em ambientes do OpenShift, no local ou no ARO (Red Hat OpenShift no Azure).

Dica

Para encontrar uma forma rápida de inicializar um ambiente de exemplo usando o ARO e o BDC implantado nessa plataforma, use o script Python disponível aqui.

Você pode implantar Clusters de Big Data no OpenShift local ou no ARO (Red Hat OpenShift no Azure). Valide a versão CRI-O do OpenShifts em relação a configurações testadas nas notas sobre a versão dos clusters de Big Data do SQL Server. Embora o fluxo de trabalho de implantação seja semelhante à implantação em outras plataformas baseadas no Kubernetes (kubeadm e AKS), há algumas diferenças. A diferença está principalmente na execução de aplicativos como o usuário não raiz e o contexto de segurança usado para namespace no qual o BDC é implantado.

Para implantar o cluster OpenShift no local, confira a documentação do Red Hat OpenShift. Para implantações do ARO, confira o Red Hat OpenShift no Azure.

Este artigo descreve as etapas de implantação específicas da plataforma OpenShift, destaca as opções existentes para acessar o ambiente de destino e o namespace que você está usando para implantar o cluster de Big Data.

Pré-requisitos

Importante

Os pré-requisitos abaixo precisam ser executados por um administrador de cluster OpenShift (função de cluster de administrador de cluster) que tenha permissões suficientes para criar esses objetos no nível de cluster. Para obter mais informações sobre as funções de cluster do OpenShift, confira Como usar o RBAC para definir e aplicar permissões.

  1. Verifique se a configuração de pidsLimit do OpenShift está atualizada para acomodar cargas de trabalho do SQL Server. O valor padrão no OpenShift é muito baixo para cargas de trabalho semelhantes a de produção. Comece com pelo menos 4096, mas o valor ideal depende da configuração de max worker threads no SQL Server e do número de processadores da CPU no nó do host do OpenShift.

    • Para descobrir como atualizar o pidsLimit para o cluster do OpenShift, use estas instruções. Observe que as versões do OpenShift anteriores a 4.3.5 apresentavam um defeito que fazia com que o valor atualizado não entrasse em vigor. Lembre-se de atualizar o OpenShift para a última versão.
    • Para ajudar você a calcular o valor ideal dependendo do ambiente e das cargas de trabalho planejadas do SQL Server, use a estimativa e os exemplos abaixo:
    Número de processadores Número máximo de threads de trabalho padrão Trabalhos padrão por processador Valor mínimo de pidsLimit
    64 512 16 512 + (64 *16) = 1.536
    128 512 32 512 + (128*32) = 4.608

    Observação

    Outros processos (por exemplo, backups, CLR, texto completo, SQLAgent) também adicionam uma sobrecarga; portanto, adicione um buffer ao valor estimado.

  2. Baixe a SCC (restrição de contexto de segurança) personalizada bdc-scc.yaml:

    curl https://raw.githubusercontent.com/microsoft/sql-server-samples/master/samples/features/sql-big-data-cluster/deployment/openshift/bdc-scc.yaml -o bdc-scc.yaml

  3. Aplique a SCC ao cluster.

    oc apply -f bdc-scc.yaml

    Observação

    A SCC personalizada para o BDC é baseada na SCC nonroot interno no OpenShift, com permissões adicionais. Para saber mais sobre as restrições de contexto de segurança do OpenShift, confira Como gerenciar restrições de contexto de segurança. Para obter informações detalhadas sobre quais permissões adicionais são necessárias para Clusters de Big Data na SCC nonroot, baixe o white paper aqui.

  4. Crie um namespace/um projeto:

    oc new-project <namespaceName>

  5. Associe a SCC personalizada às contas de serviços no namespace em que o BDC foi implantado:

    oc create clusterrole bdc-role --verb=use --resource=scc --resource-name=bdc-scc -n <namespaceName>
oc create rolebinding bdc-rbac --clusterrole=bdc-role --group=system:serviceaccounts:<namespaceName>

  6. Atribua a permissão apropriada ao usuário que está implantando o BDC. Execute uma delas.

    • Se o usuário que está implantando o BDC tiver a função de administrador de cluster, prossiga para Implantar cluster de Big Data.

    • Se o usuário que está implantando o BDC for um administrador de namespace, atribua a ele a função local de administrador de cluster no namespace criado. A opção preferencial é que o usuário que implanta e gerencia o cluster de Big Data tenha permissões de administrador no nível do namespace.

    oc create rolebinding bdc-user-rbac --clusterrole=cluster-admin --user=<userName> -n <namespaceName>

    O usuário que está implantando o cluster de Big Data precisará fazer logon no console do OpenShift:

    oc login -u <deployingUser> -p <password>

Implantar um cluster de Big Data

  1. Instale o azdata mais recente.

  2. Clone um dos arquivos de configuração internos do OpenShift, dependendo do ambiente de destino (OpenShift local ou ARO) e do cenário de implantação. Confira a seção Configurações específicas do OpenShift nos arquivos de configuração de implantação abaixo para obter as configurações específicas do OpenShift nos arquivos de configuração internos. Para obter mais detalhes sobre os arquivos de configuração disponíveis, confira as diretrizes de implantação.

    Liste todos os arquivos de configuração internos disponíveis.

    azdata bdc config list

    Para clonar um dos arquivos de configuração internos, execute o comando abaixo (opcionalmente, você pode substituir o perfil com base na plataforma/no cenário de destino):

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

    Para uma implantação no ARO, comece com um dos perfis aro-, que inclui valores padrão para serviceType e storageClass apropriados para esse ambiente. Por exemplo:

    azdata bdc config init --source aro-dev-test --target custom-openshift

  3. Personalize os arquivos de configuração control.json e bdc.json. Estes são alguns recursos adicionais que orientarão você nas personalizações de vários casos de uso:

    Observação

    Não há suporte para a integração ao Microsoft Entra ID no BDC e, portanto, você não pode usar esse método de autenticação para a implantação no ARO.

  4. Definir variáveis de ambiente

  5. Implantar um cluster de Big Data

    azdata bdc create --config custom-openshift --accept-eula yes

  6. Após a implantação bem-sucedida, você poderá fazer logon e listar os pontos de extremidade do cluster externo:

       azdata login -n mssql-cluster
   azdata bdc endpoint list

Configurações específicas do OpenShift nos arquivos de configuração de implantação

O SQL Server 2019 CU5 apresenta duas opções de recurso para controlar a coleta de métricas de pod e nó. Esses parâmetros são definidos como false por padrão nos perfis internos do OpenShift, já que os contêineres de monitoramento exigem um contexto de segurança com privilégios, o que flexibilizará algumas das restrições de segurança para o namespace no qual BDC foi implantado.

    "security": {
      "allowNodeMetricsCollection": false,
      "allowPodMetricsCollection": false
}

O nome da classe de armazenamento padrão do ARO é managed-premium (em oposição ao AKS, em que a classe de armazenamento padrão é chamada default). Você encontrará isso no control.json correspondente a aro-dev-test e aro-dev-test-ha:

    },
    "storage": {
      "data": {
        "className": "managed-premium",
        "accessMode": "ReadWriteOnce",
        "size": "15Gi"
      },
      "logs": {
        "className": "managed-premium",
        "accessMode": "ReadWriteOnce",
        "size": "10Gi"
      }

Arquivo bdc-scc.yaml

O arquivo SCC para essa implantação é:

allowHostDirVolumePlugin: false
allowHostIPC: false
allowHostNetwork: false
allowHostPID: false
allowHostPorts: false
allowPrivilegeEscalation: true
allowPrivilegedContainer: false
allowedCapabilities:
  - SETUID
  - SETGID
  - CHOWN
  - SYS_PTRACE
apiVersion: security.openshift.io/v1
defaultAddCapabilities: null
fsGroup:
  type: RunAsAny
kind: SecurityContextConstraints
metadata:
  annotations:
    kubernetes.io/description: SQL Server BDC custom scc is based on 'nonroot' scc plus additional capabilities required by BDC.
  generation: 2
  name: bdc-scc
readOnlyRootFilesystem: false
requiredDropCapabilities:
  - KILL
  - MKNOD
runAsUser:
  type: MustRunAsNonRoot
seLinuxContext:
  type: MustRunAs
supplementalGroups:
  type: RunAsAny
volumes:
  - configMap
  - downwardAPI
  - emptyDir
  - persistentVolumeClaim
  - projected
  - secret

Próximas etapas

Tutorial: Carregar dados de exemplo em um cluster de Big Data do SQL Server