Perguntas frequentes sobre os Serviços de Nuvem do Microsoft Azure (suporte estendido)

• Serviços de Nuvem (clássico): microsoft.classiccompute/domainnames
• Serviços de Nuvem (suporte estendido): microsoft.compute/cloudservices

Os Serviços de Nuvem (suporte estendido) estão disponíveis em todas as regiões de nuvem pública e soberana.

Os clientes precisam solicitar cota usando os mesmos processos que qualquer outro produto do Azure Resource Manager. A cota no Azure Resource Manager é regional e uma solicitação de cota separada é necessária para cada região.

Os Serviços de Nuvem do Microsoft Azure (suporte estendido) não dão suporte ao conceito lógico de um serviço hospedado, que incluiu dois locais (produção e preparo). Cada implantação é uma implantação independente de serviço de nuvem (suporte estendido). Para testar e preparar uma nova versão de um serviço de nuvem, implante um serviço de nuvem (suporte estendido) e marque-o como permutável VIP com outro serviço de nuvem (suporte estendido)

O conceito de nomes de serviços hospedados não existe mais, você não pode criar um serviço de nuvem vazio (suporte estendido).

Não, o Serviços de Nuvem do Microsoft Azure(suporte estendido) não dão suporte à verificação de Resource Health (RHC).

Não há alterações nas métricas da instância de função.

Não há alteração no design, na arquitetura nem nos componentes das funções de trabalho e Web.

Quando várias chamadas de escala acontecem no mesmo serviço de nuvem (para funções diferentes) aproximadamente ao mesmo tempo, devido a uma condição de corrida, os componentes da plataforma da Microsoft saem de sincronia, levando a falhas. A Microsoft está trabalhando ativamente para resolver esse problema. A solução alternativa sugerida até que isso aconteça é não dimensionar automaticamente todas as funções simultaneamente.

Não há nenhuma alteração no design, na arquitetura ou nos componentes das instâncias de função.

Não há nenhuma alteração no método de distribuição. Serviços de Nuvem do Microsoft Azure (clássicos) e serviços de nuvem (suporte estendido) recebem as mesmas atualizações.

A implantação de serviços de nuvem (suporte estendido) só dá suporte ao estado interrompido-alocado, que aparece como "interrompido" no portal do Azure. Não há suporte para o estado interrompido-desalocado.

Implantações de Serviços de Nuvem do Microsoft Azure (suporte estendido) não podem ser dimensionadas em vários clusters, zonas de disponibilidade e regiões.

A ID de implantação, também conhecida como ID privada, pode ser acessada usando a API CloudServiceInstanceView. Ela também está disponível na portal do Azure na folha Função e Instâncias do serviço de nuvem (suporte estendido)

Os serviços de nuvem (suporte estendido) usam Azure Key Vault e endereços IP públicos (Azure Resource Manager) básicos. Os clientes que exigem certificados precisam usar Azure Key Vault para o gerenciamento de certificados (saiba mais sobre preços de Azure Key Vault). Cada endereço IP público para serviços de nuvem (suporte estendido) é cobrado separadamente (saiba mais sobre preços de endereço IP público).

Um bug na cobrança de Largura de Banda foi corrigido em novembro de 2022, resultando em clientes possivelmente vendo um aumento na cobrança com base na transferência de dados de saída para outras regiões ou internet. Para obter mais referências, visite a Página de preços de largura de banda do Azure.

O SLA (Contrato de Nível de Serviço) para Serviços de Nuvem do Microsoft Azure( suporte estendido) é igual ao SLA para Serviços de Nuvem do Microsoft Azure (clássico). Consulte Documentos de Licenciamento.

Balanceadores de carga de grupos de segurança de rede, e tabelas de rotas precisam estar na mesma região e no mesmo grupo de recursos.

Key Vault, rede virtual, endereços IP públicos de grupos de segurança de rede, e tabelas de rotas precisam estar na mesma região.

Endereços IP públicos, balanceadores de carga de grupos de segurança de rede, e tabelas de rotas precisam estar na mesma rede virtual.

Os arquivos de modelo e parâmetro podem ser passados como um parâmetro usando REST do PowerShell, e CLI. Eles também podem ser carregados usando o portal do Azure.

Arquivos de modelo e parâmetro são usados somente para automação de implantação. Como os serviços de nuvem (clássicos), você pode criar manualmente os recursos dependentes primeiro e, em seguida, uma implantação de serviços de nuvem (suporte estendido) usando o PowerShell, comandos da CLI ou por meio do portal com o csdef, cscfg existente.

Não há nenhuma alteração necessária para o pacote de código do aplicativo no cspkg. Seus aplicativos existentes continuarão a funcionar como antes.

Não há suporte para o formato de pacote CTP em Serviços de Nuvem do Microsoft Azure (suporte estendido). No entanto, ele permite um limite de tamanho de pacote avançado de 800 MB

O CSES não dá suporte à identidade gerenciada. Portanto, a conta de armazenamento por design não permite que o CSES acesse os arquivos de pacote quando a conta de armazenamento estiver habilitada apenas na rede virtual selecionada na configuração.

Não, as implantações de serviço de nuvem (suporte estendido) são vinculadas a um cluster como serviços de nuvem (clássico). Portanto, as falhas de alocação continuarão a existir se o cluster estiver cheio.

Estimar o tempo necessário e a migração de complexidade depende de um intervalo de variáveis. O planejamento é a etapa mais eficaz para entender o escopo do trabalho, os bloqueadores, e a complexidade da migração.

As redes virtuais são um recurso necessário para qualquer implantação no Azure Resource Manager. A implantação de serviços de nuvem (suporte estendido) deve residir dentro de uma rede virtual.

No Azure Resource Manager, os componentes de sua implantação de serviços de nuvem (suporte estendido) são expostos como um recurso para melhor visibilidade e controle aprimorado. Os mesmos tipo de recursos foram usados nos Serviços de Nuvem do Microsoft Azure(clássicos), mas estavam ocultos. Um exemplo desse recurso é o Load Balancer público, que agora é um recurso "somente leitura" explícito criado automaticamente pela plataforma

Uma sub-rede contendo implantações de Serviços de Nuvem do Microsoft Azure (suporte estendido) não pode ser compartilhada com implantações de outros produtos de computação, como Máquinas Virtuais, conjuntos de dimensionamento de máquinas virtuais, Service Fabric, etc.

Os serviços de nuvem (suporte estendido) dão suporte a métodos de alocação de IP estáticos e dinâmicos. Endereços IP estáticos são chamados de IPs reservados no arquivo cscfg.

Os clientes são cobrados pelo uso do endereço IP nos serviços de nuvem (suporte estendido) assim como os usuários são cobrados por endereços IP associados a máquinas virtuais.

Um IP reservado não pode ser adicionado, removido ou alterado durante a atualização ou o upgrade da implantação. Se os endereços IP precisarem ser alterados, use um Serviço de Nuvem intercambiável ou implante dois Serviços de Nuvem com um CName no DNS do Azure\Gerenciador de Tráfego para que o IP possa ser apontado para qualquer um deles.

Sim. Os serviços de nuvem (suporte estendido) também podem receber um nome DNS. Com Azure Resource Manager, o rótulo DNS é uma propriedade opcional do endereço IP público que é atribuído ao serviço de nuvem. O formato do nome DNS para implantações baseadas em Azure Resource Manager é <userlabel>.<region>.cloudapp.azure.com

Não. A referência de rede virtual é obrigatória durante a criação de um serviço de nuvem. Para um serviço de nuvem existente, a referência de rede virtual não pode ser alterada. O próprio espaço de endereço de rede virtual pode ser modificado usando APIs da rede virtual.

Os Serviços de Nuvem do Microsoft Azure (suporte estendido) adotaram o mesmo processo que outras ofertas de computação em que os certificados residem em cofres de chaves gerenciadas pelo cliente. Esse processo permite que os clientes tenham controle total sobre seus segredos e certificados.

Não. Key Vault é um recurso regional e os clientes precisam de um Key Vault em cada região. No entanto, um Key Vault pode ser usado para todas as implantações em uma determinada região.

Sim. Não permitimos referências do cofre de chaves de assinatura cruzada nos Serviços de Nuvem para proteger contra o escalonamento de ataques de privilégio por meio de CS-ES. A assinatura não é um limite que o CS-ES cruza para referências a segredos. Não permitimos referências de assinatura cruzada porque é uma etapa final importante para impedir que usuários mal-intencionados usem o CS-ES como um mecanismo de escalonamento de privilégios para acessar os segredos de outros usuários. A assinatura não é um limite de segurança, mas a defesa profunda é um requisito. No entanto, você pode usar a extensão Key Vault para obter o suporte de assinatura cruzada e região cruzada para seus certificados. Consulte a documentação aqui

Sim. Aplicamos limites de região para impedir que os usuários criem arquiteturas com dependências entre regiões. O isolamento regional é um princípio básico de design de aplicativos baseados em nuvem. No entanto, você pode usar a extensão Key Vault para obter o suporte de assinatura cruzada e região cruzada para seus certificados. Consulte a documentação aqui

Quando várias chamadas de escala acontecem no mesmo serviço de nuvem (para funções diferentes) aproximadamente ao mesmo tempo, devido a uma condição de corrida, os componentes da plataforma da Microsoft saem de sincronia, levando a falhas. A Microsoft está trabalhando ativamente para resolver esse problema. A solução alternativa sugerida até que isso aconteça é não dimensionar automaticamente todas as funções simultaneamente.

Não há suporte para esse cenário no Visual Studio. Implantação via PowerShell ou pelo Portal.

Próximas etapas

Para começar a usar os serviços de nuvem (suporte estendido), consulte Implantar um serviço de nuvem (suporte estendido) usando o PowerShell