Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
Este documento descreve como implantar uma carga de trabalho do SQL Server no Google Cloud
usando a ferramenta de automação de implantação guiada no Workload Manager.
Configurar a implantação do SQL Server
Para configurar e implantar uma carga de trabalho do SQL Server, execute as seguintes tarefas:
No Google Cloud console, acesse a página Gerenciador de carga de trabalho.
No painel de navegação do Workload Manager, clique em Deployments.
Selecione o projeto em que você quer criar a implantação.
Clique em Criar implantação e escolha SQL Server.
Na seção Noções básicas sobre implantação, insira as seguintes informações sobre seus requisitos de implantação e carga de trabalho.
O Gerenciador de carga de trabalho usa essas informações
básicas para determinar os dados a serem coletados nas guias subsequentes.
O Workload Manager também oferece recomendações para a
configuração de implantação com base nas configurações básicas:
Insira um nome para descrever a carga de trabalho que você está implantando.
Por exemplo, sqlserver-prod-1 Esse nome precisa ser exclusivo no projeto em que você está implantando a carga de trabalho.
É possível usar caracteres alfanuméricos e hifens em letras minúsculas para especificar o nome,
mas ele precisa começar com uma letra e não pode terminar com um hífen. Ele pode ter
no mínimo 3 e no máximo 22 caracteres.
No campo Descrição da implantação, adicione uma descrição para sua carga de trabalho,
que será mostrada mais tarde no painel que mostra suas implantações.
No campo Conta de serviço, selecione uma conta de serviço que você quer anexar à implantação. O Workload Manager usa
essa conta de serviço para chamar outras APIs e serviços para criar recursos
necessários para a implantação. É possível selecionar uma conta de serviço
atual ou criar uma nova.
Selecione se a carga de trabalho é destinada ao uso de produção ou não.
Observação: alguns valores padrão são usados na ferramenta com base na seleção de ambiente.
Selecione o sistema operacional. O Workload Manager oferece suporte à implantação do SQL Server apenas em VMs que executam o sistema operacional Windows.
Selecione o tipo de licenciamento do Windows entre as seguintes opções:
Licenças adquiridas pelo usuário (BYOL)
Pagamento por utilização (PAYG)
Selecione o tipo de licenciamento do SQL Server entre as seguintes opções:
Licenças adquiridas pelo usuário (BYOL)
Pagamento por utilização (PAYG)
Selecione a imagem do SO entre as opções públicas ou personalizadas.
Selecione a estratégia de implantação:
Nó único: cada instância do SQL Server é implantada na própria VM
Alta disponibilidade: o cluster do SQL Server com alta disponibilidade é implantado em várias zonas
Selecione o modo de disponibilidade:
Grupo de disponibilidade (AG)
Instância de cluster de failover (FCI)
No campo Prefixo do nome da VM, insira um prefixo que será aplicado aos nomes
de todas as VMs criadas durante a implantação.
São permitidos no máximo sete caracteres para o prefixo.
No campo Bucket de mídia de instalação de software, selecione o bucket do Cloud Storage que contém a mídia de instalação do SQL Server que você enviou. O bucket
precisa existir no projeto em que você está criando a implantação.
Na guia Local e rede, insira as seguintes informações.
Selecione o Google Cloud projeto em que você quer implantar a carga de trabalho.
Selecione a Google Cloud região em que você quer implantar a carga de trabalho.
Selecione uma zona na região especificada.
Selecione uma zona da região especificada para implantar o sistema secundário.
Esse campo só fica visível se você tiver especificado HA como
o modelo de implantação na seção "Noções básicas".
Selecione a rede de nuvem privada virtual (VPC) em que você está implantando
a carga de trabalho.
Selecione a sub-rede na rede VPC especificada em que você quer
implantar a carga de trabalho.
Selecione um método para fornecer acesso externo à Internet às VMs. Para
mais informações, consulte Pré-requisitos.
Cloud NAT: se você quiser fornecer acesso externo à Internet usando um gateway do Cloud NAT que já criou para a rede especificada.
Permitir IP externo: se você quiser fornecer acesso externo à Internet
reservando um endereço IP externo estático em cada VM.
Selecione Criar uma nova zona DNS. O Workload Manager cria automaticamente um DNS para
permitir a comunicação entre as VMs na implantação.
Clique em Continuar.
Na guia Active Directory, insira o seguinte.
Selecione o nome do Secret Manager que
corresponde à senha do nome de usuário especificado no campo Nome de usuário do domínio
para se conectar ao Active Directory.
O Workload Manager usa essa senha durante o processo de implantação e
instalação. Esse secret precisa existir no projeto Google Cloud
em que você cria a implantação.
Especifique o nome da conta de usuário do Active Directory usada para ingressar as VMs no domínio do
Active Directory.
Especifique o endereço IP do nó do Active Directory.
Especifique o nome DNS do domínio do Active Directory.
Clique em Continuar.
Na guia Database, insira as seguintes informações:
Selecione o modelo de tenancy entre as seguintes opções:
Compartilhado
Locatário único
Observação: a opção de locação compartilhada não está disponível para licenças BYOL do Windows.
Selecione uma família de máquinas para as VMs do banco de dados.
Selecione um tipo de máquina para as VMs do banco de dados.
Selecione o tipo de armazenamento em blocos para a VM.
Selecione a opção SMT off para ativar ou desativar a multissegmentação simultânea,
também chamada de Hyper-Threading.
Selecione a opção TempDB no SSD local para usar um SSD local para armazenar o TempDB.
Para revisar a configuração de implantação, clique em Continuar.
Para implantar a carga de trabalho do SQL Server, clique em Criar.
Analisar o status da implantação
Depois de clicar em Criar, o painel de implantação aparece, onde você pode monitorar o status dela. É possível monitorar o status
da implantação passando o cursor sobre o ícone Status.
Você vai receber uma notificação no console do Google Cloud quando o Workload Manager
concluir o processo de implantação. Se a implantação não for bem-sucedida, você
vai receber uma notificação de falha. Para conferir mais informações sobre o erro, clique no nome da implantação no painel. Consulte Resolver erros de implantação.
Resolver erros de implantação
Se o erro ocorreu durante a criação do arquivo do Terraform, siga estas etapas:
Se o problema exigir a alteração da
configuração, por exemplo, se o nome da implantação ou o prefixo da VM não forem exclusivos, faça o seguinte:
Exclua a implantação.
Faça uma nova implantação usando a configuração correta.
Se o problema não exigir a alteração da configuração, por exemplo, problemas de cota:
Corrija o problema.
Clique em Tentar novamente na mensagem de erro para retomar o processo de implantação.
Se o erro ocorreu durante a criação do arquivo de configuração do estado desejado (DSC, na sigla em inglês) do PowerShell:
Se o problema exigir a alteração da configuração, por exemplo,
o bucket de software errado foi escolhido:
Exclua a implantação.
Crie uma nova implantação usando a configuração correta.
Se o problema não exigir a mudança da configuração, por
exemplo, o pacote do SO não foi feito o download:
Resolva o problema subjacente, se aplicável.
Pare e inicie a VM do Ansible Runner chamada VM_PREFIX-ansible-runner
no painel do Compute Engine.
VM_PREFIX é o prefixo especificado para todas as VMs na implantação.
Esse processo reinicia a criação do Ansible para a implantação.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Difícil de entender","hardToUnderstand","thumb-down"],["Informações incorretas ou exemplo de código","incorrectInformationOrSampleCode","thumb-down"],["Não contém as informações/amostras de que eu preciso","missingTheInformationSamplesINeed","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 2025-09-04 UTC."],[],[],null,["# Deploy a SQL Server workload\n\nThis document describes how to deploy a SQL Server workload on Google Cloud\nby using the Guided Deployment Automation tool in Workload Manager.\n\nConfigure SQL Server deployment\n-------------------------------\n\nTo configure and deploy a SQL Server workload, perform the following tasks:\n\n1. In the Google Cloud console, go to the **Workload Manager** page.\n\n [Go to Workload Manager](https://console.cloud.google.com/workload-manager)\n2. In the **Workload Manager** navigation pane, click **Deployments**.\n\n3. Select the project in which you want to create the deployment.\n\n4. Click **Create Deployment** and choose **SQL Server**.\n\n5. In the **Deployment basics** section, enter the following information about your\n deployment and workload requirements.\n\n Workload Manager uses this basic\n information to determine the data to be collected in the subsequent tabs.\n Workload Manager also provides recommendations for your\n deployment configuration based on the basic settings:\n 1. Enter a name to describe the workload you are deploying.\n For example, `sqlserver-prod-1`. This name must be unique in the\n project where you're deploying the workload.\n\n You can use lowercase alphanumeric characters and hyphens to specify the name,\n but it must start with a letter and must not end with a hyphen. It can have\n minimum of 3 and maximum of 22 characters.\n 2. In the **Deployment description** field, add a description for your workload,\n which is later displayed on the dashboard that shows your deployments.\n\n 3. In the **Service account** field, select a service account that\n you want to attach to the deployment. Workload Manager uses\n this service account to call other APIs and services for creating resources\n required for the deployment. You can either select an existing service\n account or create a new service account.\n\n | **Note:** If the service account is missing any of the required roles for creating a deployment, Workload Manager prompts you to grant these roles. Click **Grant** to grant the missing roles to the attached service account.\n 4. Select whether the workload is intended for production use or non-production use.\n Note: Certain default values are used in the tool based on the environment selection.\n\n 5. Select the operating system. Workload Manager supports deploying\n SQL Server only on VMs that run Windows operating system.\n\n 6. Select the licensing type for Windows from the following options:\n\n - Bring your own license (BYOL)\n - Pay as you go (PAYG)\n 7. Select the licensing type for SQL Server from the following options:\n\n - Bring your own license (BYOL)\n - Pay as you go (PAYG)\n 8. Select the OS image from public or custom images.\n\n 9. Select the deployment strategy:\n\n - Single node: each SQL Server instance is deployed on its own VM\n - High availability: highly available SQL Server cluster is deployed across multiple zones\n 10. Select the availability mode:\n\n - Availability group (AG)\n - Failover cluster instance (FCI)\n6. In the **VM name prefix** field, enter a prefix that is applied to the names\n of all VMs created during the deployment.\n A maximum of seven characters are allowed for the prefix.\n\n7. In the **Software installation media bucket** field, select the Cloud Storage\n bucket that holds the SQL Server installation media you uploaded. The bucket\n must exist within the project in which you're creating the deployment.\n\n For more information, see [Prepare SQL Server installation files for deployment](/workload-manager/docs/deploy/sql-server/prerequisites-sql#install-files).\n8. Click **Continue** to proceed.\n\n9. In the **Location \\& networking** tab, enter the following.\n\n 1. Select the Google Cloud project in which you want to deploy the workload.\n 2. Select the Google Cloud region in which you want to deploy the workload.\n 3. Select a zone from the specified region.\n 4. Select a zone from the specified region for deploying the secondary system. This field is visible only if you have specified HA as the deployment model in the basics section.\n 5. Select the Virtual Private Cloud (VPC) network into which you're deploying the workload.\n 6. Select the subnet in the specified VPC network where you want to deploy the workload.\n 7. Select a method for providing external internet access to the VMs. For more information, see [Prerequisites](/workload-manager/docs/deploy/prerequisites#network%22%3EPrerequisites).\n - Cloud NAT: If you want to provide external internet access using a Cloud NAT gateway that you have already created for the specified network.\n - Allow External IP: If you want to provide external internet access by reserving a static external IP address on each VM.\n 8. Select **Create a new DNS zone**. Workload Manager automatically creates a DNS to allow communication between VMs in the deployment.\n10. Click **Continue**.\n\n11. In the **Active Directory** tab, enter the following.\n\n 1. Select the [Secret Manager name](/secret-manager) that corresponds to the password for the username specified in the **Domain username** field to connect to Active Directory. Workload Manager uses this password throughout the deployment and installation process. This secret must exist in the Google Cloud project in which you create the deployment.\n 2. Specify the name of the Active Directory user account used to join the VMs to the Active Directory domain.\n 3. Specify the IP address of the Active Directory node.\n 4. Specify the Active Directory domain DNS name.\n12. Click **Continue**.\n\n13. In the **Database** tab, enter the following information:\n\n 1. Select the [Secret Manager name](/secret-manager) that corresponds to the password used for the database.\n 2. Select the tenancy model from the following options:\n - Shared\n - Sole tenant Note: The shared tenancy option is not available for Windows BYOL licenses.\n 3. Select a machine family for the database VMs.\n 4. Select a machine type for the database VMs.\n 5. Select the type of block storage for the VM.\n 6. Select the **SMT off** option to turn on or turn off simultaneous multithreading, which is also called as hyper-threading.\n 7. Select the **TempDB on local SSD** option to use a local SSD to store TempDB.\n14. To review the deployment configuration, click **Continue**.\n\n15. To deploy the SQL Server workload, click **Create**.\n\nReview the deployment status\n----------------------------\n\nAfter you click **Create** , you see the Deployment dashboard, where you can\nmonitor the status of your deployment. You can monitor the status\nof the deployment by hovering over the **Status** icon.\n\nYou receive a notification in the Google Cloud console when Workload Manager\ncompletes the deployment process. If the deployment is not successful, you\nreceive a failure notification. You can view additional information about the\nerror on the Deployment Details page by clicking the deployment name on the\ndashboard. See [Troubleshoot deployment errors](#deployment-errors).\n| **Note:** The entire deployment process might take up to two or three hours to complete. The deployment process continues in the background. After you receive the notification, you can check the deployment dashboard.\n\nTroubleshoot deployment errors\n------------------------------\n\nIf the error occurred during the Terraform file creation, then follow these steps:\n\n- If the underlying issue requires changing the configuration, for example, if deployment name or VM prefix was not unique, then do the following:\n 1. Delete the deployment.\n 2. Make a new deployment using the correct configuration.\n- If the underlying issue does not require changing the configuration, for example, quota issues:\n 1. Fix the issue.\n 2. Click **Retry** on the error message to resume the deployment process.\n\nIf the error occurred during the PowerShell Desired State Configuration (DSC) file creation:\n\n- If the underlying issue requires changing the configuration, for example, the wrong software bucket was chosen:\n 1. Delete the deployment.\n 2. Create a new deployment using the correct configuration.\n- If the underlying issue does not require changing the configuration, for example, the OS package failed to download:\n 1. Resolve the underlying problem, if applicable.\n 2. Stop and start the Ansible Runner VM named \u003cvar translate=\"no\"\u003eVM_PREFIX\u003c/var\u003e-ansible-runner from the Compute Engine dashboard. \u003cvar translate=\"no\"\u003eVM_PREFIX\u003c/var\u003e is the prefix you specified for all VMs in your deployment. This process restarts the Ansible creation for the deployment.\n\nWhat's next\n-----------\n\n- [Perform the post-deployment tasks](/workload-manager/docs/deploy/post-deployment)."]]