Azure DSC部署SQL数据库遇F盘未就绪问题求助

这是个典型的Azure资源部署时序问题——你已经设置了DSC扩展依赖SQL VM，但Azure中VM"部署完成"的判定只意味着VM实例本身启动，附加的数据盘可能还在后台完成初始化、挂载操作，这就导致DSC脚本先跑起来，找不到F:\盘而失败。

能不能调整部署顺序？ #

当然可以！关键是让DSC扩展直接依赖于数据盘资源的完成，而不是仅仅依赖VM。ARM模板的dependsOn属性支持指向具体的子资源，你需要修改DSC扩展的依赖配置，确保它等待数据盘完全挂载就绪后再执行。

举个具体的配置示例：

• 如果你的数据盘是作为独立的托管磁盘资源创建，再附加到VM，那么DSC扩展的dependsOn要包含这个磁盘的资源ID：

  "dependsOn": [
    "[resourceId('Microsoft.Compute/virtualMachines', variables('vmName'))]",
    "[resourceId('Microsoft.Compute/disks', variables('dataDiskName'))]"
  ]
  

• 如果数据盘是直接在VM的storageProfile里定义的，你可以指向VM的磁盘子资源：

  "dependsOn": [
    "[concat(resourceId('Microsoft.Compute/virtualMachines', variables('vmName')), '/datadisks/', variables('dataDiskLun'))]"
  ]
  

这样配置后，Azure会确保数据盘完全配置完成，再启动DSC扩展的执行。

无法调整模板时的解决办法 #

如果因为某些原因不能修改ARM模板，那只能在DSC脚本内部强化等待和初始化逻辑：

1. 完善磁盘等待逻辑
   之前的Do While循环超时，大概率是只检查了磁盘是否存在，没考虑磁盘需要初始化、格式化的过程。你可以修改循环逻辑，检查F:\盘是否可用（比如是否有读写权限、卷状态正常）：

   $maxWaitMinutes = 30
   $waitIntervalSeconds = 30
   $endTime = (Get-Date).AddMinutes($maxWaitMinutes)
   
   while ((Get-Date) -lt $endTime) {
       if (Test-Path -Path "F:\") {
           # 额外检查磁盘是否可写
           try {
               $testFile = "F:\dsc_disk_test.tmp"
               New-Item -Path $testFile -ItemType File -ErrorAction Stop | Out-Null
               Remove-Item -Path $testFile -ErrorAction Stop
               Write-Verbose "F:\盘已就绪，退出等待"
               break
           }
           catch {
               Write-Verbose "F:\盘存在但不可写，继续等待"
           }
       }
       Start-Sleep -Seconds $waitIntervalSeconds
   }
   
   if ((Get-Date) -ge $endTime) {
       throw "等待F:\盘就绪超时"
   }
   

2. 自动初始化新数据盘
   如果数据盘是全新的，Azure不会自动帮你初始化、分区和格式化，你需要在DSC脚本里加入这部分逻辑：

   # 查找未初始化的磁盘（假设是LUN为1的数据盘）
   $dataDisk = Get-Disk | Where-Object { $_.Number -eq 1 -and $_.PartitionStyle -eq 'RAW' }
   if ($dataDisk) {
       Initialize-Disk -Number $dataDisk.Number -PartitionStyle GPT -PassThru |
       New-Partition -DriveLetter F -UseMaximumSize |
       Format-Volume -FileSystem NTFS -NewFileSystemLabel "SQLData" -Confirm:$false
   }
   

   这样即使磁盘还没初始化，DSC也能先完成这一步，再继续创建数据库。

3. 拆分扩展执行流程
   你可以先部署一个自定义脚本扩展，专门负责初始化和挂载数据盘，然后让DSC扩展依赖于这个自定义脚本扩展的完成。这样能把磁盘准备和DSC配置的时序彻底分开，避免冲突。

额外排查点 #

• 检查ARM模板中数据盘的createOption配置：如果是新磁盘，要设为Empty；如果是现有磁盘，设为Attach，确保磁盘能正确附加到VM。
• 查看DSC扩展日志：登录VM后，在C:\WindowsAzure\Logs\Plugins\Microsoft.Powershell.DSC路径下查看日志，能明确看到DSC执行时磁盘的状态，帮助定位问题。

内容的提问来源于stack exchange，提问作者Alex Moffitt