我正在尝试使用Azure PowerShell CLI和带有参数的自定义ARM模板将3层体系结构部署到Azure。我对powershell脚本或模板的有效性没有任何疑问。
在模板中，除其他外，还有两个虚拟机规模集，一个用于前端，一个用于后端。前端是Windows，后端是红色的帽子。前端在应用程序网关后面，而后端在负载均衡器后面。奇怪的是，前端VMSS部署没有问题，一切都很好。后端VMSS每次尝试部署时都会失败，并带有模糊的“未知网络分配错误”消息，我不知道如何调试（因为到目前为止，它没有提供与我所有其他错误消息相同的细节）。 / p>
我将ARM模板基于来自另一个资源组中该体系结构的工作模型的导出模板，并修改了参数，并花了一些时间清理Azure导出模板的问题和错误。我尝试删除并从头开始，但似乎无法解决此问题。我以为有可能达到免费订阅处理器的极限，所以我尝试使前端VMSS依赖于后端VMSS，以便首先创建后端VMSS，但是仍然发生了同样的问题。 >
这是模板的后端VMSS部分：
{
"type": "Microsoft.Compute/virtualMachineScaleSets",
"apiVersion": "2018-10-01",
"name": "[parameters('virtualMachineScaleSets_JakeAppBESS_name')]",
"location": "westus2",
"dependsOn": [
"[parameters('loadBalancers_JakeAppBESSlb_name')]"
],
"sku": {
"name": "Standard_B1ls",
"tier": "Standard",
"capacity": 1
},
"properties": {
"singlePlacementGroup": true,
"upgradePolicy": {
"mode": "Manual"
},
"virtualMachineProfile": {
"osProfile": {
"computerNamePrefix": "jakeappbe",
"adminUsername": "Jake",
"adminPassword": "[parameters('JakeApp_Password')]",
"linuxConfiguration": {
"disablePasswordAuthentication": false,
"provisionVMAgent": true
},
"secrets": []
},
"storageProfile": {
"osDisk": {
"createOption": "FromImage",
"caching": "ReadWrite",
"managedDisk": {
"storageAccountType": "Premium_LRS"
}
},
"imageReference": {
"publisher": "RedHat",
"offer": "RHEL",
"sku": "7.4",
"version": "latest"
}
},
"networkProfile": {
"networkInterfaceConfigurations": [
{
"name": "[concat(parameters('virtualMachineScaleSets_JakeAppBESS_name'), 'Nic')]",
"properties": {
"primary": true,
"enableAcceleratedNetworking": false,
"dnsSettings": {
"dnsServers": []
},
"enableIPForwarding": false,
"ipConfigurations": [
{
"name": "[concat(parameters('virtualMachineScaleSets_JakeAppBESS_name'), 'IpConfig')]",
"properties": {
"subnet": {
"id": "[concat('/subscriptions/', parameters('subscription_id'), '/resourceGroups/', parameters('resource_Group'), '/providers/Microsoft.Network/virtualNetworks/', parameters('virtualNetworks_JakeAppVnet_name'), '/subnets/BEsubnet')]"
},
"privateIPAddressVersion": "IPv4",
"loadBalancerBackendAddressPools": [
{
"id": "[concat('/subscriptions/', parameters('subscription_id'), '/resourceGroups/', parameters('resource_Group'), '/providers/Microsoft.Network/loadBalancers/', parameters('loadBalancers_JakeAppBESSlb_name'), '/backendAddressPools/bepool')]"
}
],
"loadBalancerInboundNatPools": [
{
"id": "[concat('/subscriptions/', parameters('subscription_id'), '/resourceGroups/', parameters('resource_Group'), '/providers/Microsoft.Network/loadBalancers/', parameters('loadBalancers_JakeAppBESSlb_name'), '/inboundNatPools/natpool')]"
}
]
}
}
]
}
}
]
},
"priority": "Regular"
},
"overprovision": true
}
},
For reference, here's the front-end VMSS's part of the template so you can compare and see that there aren't many differences:
` {
"type": "Microsoft.Compute/virtualMachineScaleSets",
"apiVersion": "2018-10-01",
"name": "[parameters('virtualMachineScaleSets_JakeAppFESS_name')]",
"location": "westus2",
"dependsOn": [
"[parameters('applicationGateways_JakeAppFE_AG_name')]",
],
"sku": {
"name": "Standard_B1ls",
"tier": "Standard",
"capacity": 1
},
"properties": {
"singlePlacementGroup": true,
"upgradePolicy": {
"mode": "Manual"
},
"virtualMachineProfile": {
"osProfile": {
"computerNamePrefix": "jakeappfe",
"adminUsername": "Jake",
"adminPassword": "[parameters('JakeApp_Password')]",
"windowsConfiguration": {
"provisionVMAgent": true,
"enableAutomaticUpdates": true
},
"secrets": []
},
"storageProfile": {
"osDisk": {
"createOption": "FromImage",
"caching": "ReadWrite",
"managedDisk": {
"storageAccountType": "Premium_LRS"
}
},
"imageReference": {
"publisher": "MicrosoftWindowsServer",
"offer": "WindowsServer",
"sku": "2016-Datacenter",
"version": "latest"
}
},
"networkProfile": {
"networkInterfaceConfigurations": [
{
"name": "[concat(parameters('virtualMachineScaleSets_JakeAppFESS_name'), 'Nic')]",
"properties": {
"primary": true,
"enableAcceleratedNetworking": false,
"dnsSettings": {
"dnsServers": []
},
"enableIPForwarding": false,
"ipConfigurations": [
{
"name": "[concat(parameters('virtualMachineScaleSets_JakeAppFESS_name'), 'IpConfig')]",
"properties": {
"subnet": {
"id": "[concat('/subscriptions/', parameters('subscription_id'), '/resourceGroups/', parameters('resource_Group'), '/providers/Microsoft.Network/virtualNetworks/', parameters('virtualNetworks_JakeAppVnet_name'), '/subnets/FEsubnet')]"
},
"privateIPAddressVersion": "IPv4",
"applicationGatewayBackendAddressPools": [
{
"id": "[concat('/subscriptions/', parameters('subscription_id'), '/resourceGroups/', parameters('resource_Group'), '/providers/Microsoft.Network/applicationGateways/', parameters('applicationGateways_JakeAppFE_AG_name'), '/backendAddressPools/appGatewayBackendPool')]"
}
]
}
}
]
}
}
]
},
"priority": "Regular"
},
"overprovision": true
}
},
我希望他们的行为相似。当然，后端是RH linux，而前端是Windows，前端在应用程序网关后面，而后端在负载均衡器后面，但是此设置在我的其他资源组中工作得很好通过门户而不是通过ARM部署。但是每次我尝试部署它时，都会出现此错误：
New-AzureRmResourceGroupDeployment : 1:30:56 AM - Resource Microsoft.Compute/virtualMachineScaleSets 'ProdBESS' failed with message '{
"status": "Failed",
"error": {
"code": "ResourceDeploymentFailure",
"message": "The resource operation completed with terminal provisioning state 'Failed'.",
"details": [
{
"code": "NetworkingInternalOperationError",
"message": "Unknown network allocation error."
}
]
}
}'
答案 0 :(得分：0)
好吧，我终于弄清楚了问题所在，因此，如果将来有人搜索发现此线程时出现相同的错误：
显然，处理VMSS负载平衡器的模板部分（从天蓝色门户网站导出）具有两个相互冲突的入站nat池（重叠的端口范围）。一旦我删除了模板中创建冲突的额外nat池的部分，我的VMSS就可以正确部署而不会出现问题。
完全不知道为什么azure门户向我导出了一个模板，该模板带有一个从未存在过的额外的nat池（我从中导出模板的原始LB只有1个）。