보조 시스템을 배포할 지정된 리전에서 영역을 선택합니다.
이 필드는 기본 섹션에서 HA를 배포 모델로 지정한 경우에만 표시됩니다.
워크로드를 배포할 Virtual Private Cloud (VPC) 네트워크를 선택합니다.
워크로드를 배포할 지정된 VPC 네트워크의 서브넷을 선택합니다.
VM에 외부 인터넷 액세스를 제공하는 방법을 선택합니다. 자세한 내용은 요구사항을 참고하세요.
Cloud NAT: 지정된 네트워크에 대해 이미 만든 Cloud NAT 게이트웨이를 사용하여 외부 인터넷 액세스 권한을 제공하려는 경우
외부 IP 허용: 각 VM에서 고정 외부 IP 주소를 예약하여 외부 인터넷 액세스를 제공하려는 경우
새 DNS 영역 만들기를 선택합니다. 워크로드 관리자는 배포의 VM 간에 통신할 수 있도록 DNS를 자동으로 만듭니다.
계속을 클릭합니다.
Active Directory 탭에서 다음을 입력합니다.
Active Directory에 연결하기 위해 도메인 사용자 이름 입력란에 지정된 사용자 이름의 비밀번호에 해당하는 Secret Manager 이름을 선택합니다.
워크로드 관리자는 배포 및 설치 프로세스 전반에서 이 비밀번호를 사용합니다. 이 보안 비밀은 배포를 만드는 Google Cloud프로젝트에 있어야 합니다.
VM을 Active Directory 도메인에 조인하는 데 사용되는 Active Directory 사용자 계정의 이름을 지정합니다.
단독 테넌트
참고: Windows BYOL 라이선스에는 공유 테넌트 옵션을 사용할 수 없습니다.
데이터베이스 VM의 머신 계열을 선택합니다.
데이터베이스 VM의 머신 유형을 선택합니다.
VM의 블록 스토리지 유형을 선택합니다.
SMT off 옵션을 선택하여 하이퍼스레딩이라고도 하는 동시 멀티스레딩을 사용 설정하거나 사용 중지합니다.
로컬 SSD를 사용하여 TempDB를 저장하려면 로컬 SSD의 TempDB 옵션을 선택합니다.
배포 구성을 검토하려면 계속을 클릭합니다.
SQL Server 워크로드를 배포하려면 만들기를 클릭합니다.
배포 상태 검토
만들기를 클릭하면 배포 대시보드가 표시되며 여기에서 배포 상태를 모니터링할 수 있습니다. 상태 아이콘 위로 마우스를 가져가면 배포 상태를 모니터링할 수 있습니다.
워크로드 관리자가 배포 프로세스를 완료하면 Google Cloud 콘솔에 알림이 표시됩니다. 배포에 실패하면 실패 알림이 전송됩니다. 대시보드에서 배포 이름을 클릭하면 배포 세부정보 페이지에서 오류에 관한 추가 정보를 확인할 수 있습니다. 배포 오류 문제 해결을 참고하세요.
배포 오류 문제 해결
Terraform 파일 생성 중에 오류가 발생한 경우 다음 단계를 따르세요.
구성을 변경해야 하는 근본적인 문제가 있는 경우(예: 배포 이름 또는 VM 접두사가 고유하지 않은 경우) 다음을 실행합니다.
배포를 삭제합니다.
올바른 구성을 사용하여 새 배포를 만듭니다.
할당량 문제와 같이 기본 문제가 구성 변경을 필요로 하지 않는 경우 다음 단계를 따르세요.
문제를 해결합니다.
오류 메시지에서 다시 시도를 클릭하여 배포 프로세스를 재개합니다.
PowerShell Desired State Configuration (DSC) 파일을 만드는 중에 오류가 발생한 경우:
기본 문제로 인해 구성을 변경해야 하는 경우(예: 잘못된 소프트웨어 버킷이 선택됨) 다음 단계를 따르세요.
배포를 삭제합니다.
올바른 구성을 사용하여 새 배포를 만듭니다.
근본적인 문제로 인해 구성을 변경할 필요가 없는 경우(예: OS 패키지 다운로드 실패) 다음 단계를 따르세요.
해당하는 경우 근본적인 문제를 해결합니다.
Compute Engine 대시보드에서 VM_PREFIX-ansible-runner라는 Ansible Runner VM을 중지하고 시작합니다.
VM_PREFIX은 배포의 모든 VM에 지정한 접두사입니다.
이 프로세스를 통해 배포의 Ansible 생성이 다시 시작됩니다.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 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)."]]
