criando vm falha se o tipo de vm for diferente de outras VMs na rede virtual

Question

Minha configuração do Azure:

Rede virtual: VN

O VN supõe conter 3 máquinas virtuais

1. 2 do tipo DS2
2. 1 do tipo A3

Depois de criar os primeiros 2 com êxito (ambos sob o mesmo virtual network e com o mesmo resource-group ), não consigo criar a 3ª vm.

O erro que estou recebendo:

Unable to upgrade the deployment. The requested VM size 'Large' may not be 
available in the resources supporting the existing deployment. 
Please try again later, try with a different VM size or smaller number of
role instances, or create a deployment under an empty hosted service with a
new affinity group or no affinity group binding

Ao criar o vm, estou usando diferentes Storage account - Standard-GRS Ao contrário do que estou usando nas duas primeiras VMs: Premium-LRS

--- EDIT ---

Todos os Vms devem ser executados no mesmo Serviço em Nuvem. Os dois primeiros são dos tipos DS2 , o terceiro que estou tentando criar é do tipo A3

    

Answer 1

Então ... um serviço de nuvem é alocado para um cluster de computação específico, e esse cluster específico pode suportar apenas um subconjunto de tipos de máquinas virtuais disponíveis.

É perfeitamente possível que, com base no tamanho original da VM para a primeira VM criada, o serviço de nuvem tenha sido concluído em um cluster que não tenha suporte para a série A. Isso é bastante fácil de verificar através do portal (e eu acho um pouco mais fácil fazer check-in no portal "clássico", pois você tem um menu suspenso simples com tamanhos de máquina, ao adicionar uma nova VM a um serviço de nuvem existente - e o portal clássico não está disponível para uso com implantações baseadas em ARM, portanto, meu comentário à sua pergunta).

Supondo que não haja tamanhos de VMs da série A nesse cluster, você ainda poderá criar um novo serviço de nuvem, na mesma rede virtual que seu serviço de nuvem original, para manter suas VMs de série A. Você ainda teria a capacidade de suas VMs se comunicarem umas com as outras diretamente (já que elas estariam no mesmo vnet).

Para mais informações: um colega meu escreveu um artigo que inclui detalhes sobre clusters e tipos de VMs.