Cet article traite des questions fréquemment posées relatives à Azure Cloud Services (support étendu).
Général
Quel est le nom de la ressource pour Azure Cloud Services (classique) et Azure Cloud Services (support étendu) ?
- Azure Cloud Services (classique) :
microsoft.classiccompute/domainnames - Azure Cloud Services (support étendu) :
microsoft.compute/cloudservices
Quels sont les emplacements disponibles pour déployer Azure Cloud Services (support étendu) ?
Cloud Services (support étendu) est disponible dans toutes les régions du cloud public et du cloud souverain.
Comment mon quota change-t-il ?
Les clients doivent demander un quota à l’aide des mêmes processus que n’importe quel autre produit Azure Resource Manager. Le quota dans Azure Resource Manager est régional et une demande de quota distincte est nécessaire pour chaque région.
Pourquoi ne puis-je plus voir d’emplacement de production et de préproduction ?
Azure Cloud Services (support étendu) ne prend pas en charge le concept logique d’un service hébergé, qui comprenait deux emplacements (production et préproduction). Chaque déploiement est un déploiement indépendant d’Azure Cloud Services (support étendu). Pour tester et mettre en place une nouvelle version d’un service cloud, déployez un service cloud (support étendu) et marquez-le pour indiquer que son adresse IP virtuelle peut être échangée avec celle d’un autre service cloud (support étendu).
Pourquoi ne puis-je plus créer de service cloud vide ?
Le concept de noms de services hébergés n’existe plus. Vous ne pouvez donc pas créer d’instance vide de Cloud Services (support étendu).
Azure Cloud Services (support étendu) prend-il en charge Resource Health Check (RHC) ?
Non, Cloud Services (support étendu) ne prend pas en charge Resource Health Check (RHC).
En quoi les métriques d’instance de rôle changent-elles ?
Il n’y a aucune modification dans les métriques d’instance de rôle.
En quoi les rôles web et Worker changent-ils ?
Il n’y a pas de changement dans la conception, l’architecture ou les composants des rôles de travail et web.
La mise à l’échelle de l’instance de rôle continue d’échouer. Comment corriger ces échecs ?
Lorsque plusieurs appels de mise à l’échelle se produisent sur le même service cloud (pour des rôles différents) au même moment approximatif, en raison d’une condition de concurrence, les composants de plateforme Microsoft ne sont plus synchronisés, ce qui entraîne des échecs. Microsoft travaille activement à la résolution de ce problème. La solution de contournement provisoire suggérée ne consiste pas à mettre automatiquement à l’échelle tous les rôles simultanément.
En quoi les instances de rôle changent-elles ?
Il n’y a pas de changement dans la conception, l’architecture ou les composants des instances de rôle.
Les mises à jour du système d’exploitation invité changent-elles ?
Il n’y a aucune modification apportée à la méthode de lancement. Cloud Services (classique) et Cloud Services (support étendu) obtiennent les mêmes mises à jour.
Azure Cloud Services (support étendu) prend-il en charge les états Arrêté (alloué) et Arrêté (désalloué) ?
Le déploiement de Cloud Services (support étendu) prend uniquement en charge l’état Arrêté- Alloué qui apparaît comme « arrêté » sur le Portail Azure. L’état Arrêté- Désalloué n’est pas pris en charge.
Les déploiements d’Azure Cloud Services (support étendu) prennent-ils en charge la mise à l’échelle entre les clusters, les zones de disponibilité et les régions ?
Les déploiements de Cloud Services (support étendu) ne peuvent pas être mis à l’échelle sur plusieurs clusters, zones de disponibilité et régions.
Comment obtenir l’ID de déploiement pour mon service cloud (support étendu)
L’ID de déploiement, ou ID privé, est accessible à l’aide de l’API CloudServiceInstanceView. Il est également disponible sur le Portail Azure sous le panneau Rôle et instances de Cloud Services (support étendu)
Existe-t-il des différences de tarification entre Azure Cloud Services (classique) et Azure Cloud Services (support étendu) ?
Cloud Services (support étendu) utilise des IP publiques (Azure Resource Manager) Azure Key Vault et Essentiel. Les clients ayant besoin de certificats doivent utiliser Azure Key Vault pour la gestion des certificats (en savoir plus sur la tarification d’Azure Key Vault). Chaque IP publique pour Azure Cloud Services (support étendu) est facturée séparément (en savoir plus sur la tarification des IP publiques.)
Pourquoi le montant de facturation a-t-il changé après novembre 2022 pour les déploiements de Cloud Services (support étendu) ?
Un bogue dans la facturation de la bande passante a été résolu en novembre 2022, ce qui a permis aux clients de voir une facturation accrue en fonction de leur transfert de données sortant vers d’autres régions ou Internet. Pour plus d’informations, consultez la page de tarification de la bande passante Azure.
Qu’est-ce que le contrat de niveau de service (SLA) pour Cloud Services (support étendu) ?
Le contrat de niveau de service (SLA) pour Cloud Services (support étendu) est identique au contrat SLA pour Cloud Services (classique). Reportez-vous aux documents de licence.
Ressources
Quelles sont les ressources relatives à un déploiement d’Azure Cloud Services (support étendu) qui doivent se trouvent dans le même groupe de ressources ?
Les équilibreurs de charge, les groupes de sécurité réseau et les tables de routage doivent se trouvent dans la même région et le même groupe de ressources.
Quelles sont les ressources relatives à un déploiement d’Azure Cloud Services (support étendu) qui doivent se trouvent dans la même région ?
Key Vault, le réseau virtuel, les IP publiques, les groupes de sécurité réseau et les tables de routage doivent se trouver dans la même région.
Quelles sont les ressources relatives à un déploiement d’Azure Cloud Services (support étendu) qui doivent se trouvent dans le même réseau virtuel ?
Les IP publiques, les équilibreurs de charge, les groupes de sécurité réseau et les tables de routage doivent se trouvent dans le même réseau virtuel.
Fichiers de déploiement
Comment puis-je utiliser un modèle pour déployer ou gérer mon déploiement ?
Les fichiers de modèle et de paramètres peuvent être transmis comme paramètre en utilisant REST, PowerShell ou l’interface CLI. Ils peuvent également être chargés à l’aide du portail Azure.
Ai-je besoin de gérer quatre fichiers maintenant ? (modèle, paramètre, csdef, cscfg)
Les fichiers de modèle et de paramètres sont utilisés uniquement pour l’automatisation du déploiement. Comme pour Azure Cloud Services (classique), vous pouvez créer manuellement des ressources dépendantes, puis un déploiement d’Azure Cloud Services (support étendu) à l’aide de PowerShell, de commandes CLI ou via le portail avec le fichier .csdef existant, le fichier .cscfg.
Comment mon code d’application est-il modifié sur Azure Cloud Services (support étendu) ?
Aucune modification n’est requise pour votre code d’application empaqueté au format cspkg. Vos applications existantes continuent de fonctionner comme avant.
Cloud Services (support étendu) autorise-t-il le format de package CTP ?
Le format de package CTP n’est pas pris en charge dans Cloud Services (support étendu). Toutefois, il permet une limite de taille de package améliorée de 800 Mo
CSES nécessite que ses fichiers de package soient stockés dans un compte de stockage. Le compte de stockage peut-il être défini comme « activer l’accès à partir de réseaux virtuels sélectionnés »
CSES ne prend pas en charge le support d’identité managée. Par conséquent, le compte de stockage par conception n’autorise pas CSES à accéder aux fichiers de package lorsque le compte de stockage est activé uniquement sur le réseau virtuel sélectionné dans le paramètre.
Migration
Azure Cloud Services (support étendu) atténue-t-il les échecs dus aux échecs d’allocation ?
Non, les déploiements d’Azure Cloud Services (support étendu) sont liés à un cluster, tout comme Azure Cloud Services (classique). Par conséquent, les échecs d’allocation continuent d’exister si le cluster est plein.
Quand dois-je effectuer la migration ?
L’estimation du temps nécessaire et de la complexité de la migration dépend d’une série de variables. La planification est l’étape la plus efficace pour comprendre l’étendue du travail, les blocages et la complexité de la migration.
Mise en réseau
Pourquoi ne puis-je pas créer de déploiement sans réseau virtuel ?
Les réseaux virtuels sont une ressource obligatoire pour tout déploiement sur Azure Resource Manager. Le déploiement d’Azure Cloud Services (support étendu) doit se trouver dans un réseau virtuel.
Pourquoi vois-je maintenant autant de ressources de mise en réseau ?
Dans Azure Resource Manager, les composants de votre déploiement d’Azure Cloud Services (support étendu) sont exposés comme ressource pour une meilleure visibilité et un meilleur contrôle. Le même type de ressources était utilisé dans Cloud Services (classique), mais elles étaient masquées. Un exemple de ce type de ressource est l’équilibreur de charge public, qui est maintenant une ressource « en lecture seule » explicite créée automatiquement par la plateforme.
Quelles restrictions s’appliquent à un sous-réseau avec Azure Cloud Services (support étendu) ?
Un sous-réseau contenant des déploiements de Cloud Services (support étendu) ne peut pas être partagé avec des déploiements d’autres produits de calcul tels que des Machines Virtuelles, Virtual Machine Scale Sets, Service Fabric, etc.
Quelles sont les méthodes d’allocation d’adresses IP prises en charge sur Azure Cloud Services (support étendu) ?
Azure Cloud Services (support étendu) prend en charge les méthodes d’allocation d’adresses IP dynamiques et statiques. Les adresses IP statiques sont référencées en tant qu’adresses IP réservées dans le fichier cscfg.
Pourquoi les adresses IP me sont-elles facturées ?
Les clients sont facturés pour l’utilisation des adresses IP sur Azure Cloud Services (support étendu) tout comme les utilisateurs sont facturés pour les adresses IP associées aux machines virtuelles.
L’adresse IP réservée peut-elle être mise à jour après un déploiement réussi ?
Une adresse IP réservée ne peut pas être ajoutée, supprimée ou modifiée pendant la mise à jour ou la mise à niveau du déploiement. Si les adresses IP doivent être modifiées, utilisez un service cloud échangeable ou déployez deux instances Cloud Services avec un CName dans Azure DNS\Traffic Manager afin que l’adresse IP puisse être pointée vers l’un d’eux.
Puis-je utiliser un nom DNS avec Azure Cloud Services (support étendu) ?
Oui. Azure Cloud Services (support étendu) peut également recevoir un nom DNS. Avec Azure Resource Manager, l’étiquette DNS est une propriété facultative de l’IP publique qui est attribuée au service cloud. Le format du nom DNS pour les déploiements basés sur Azure Resource Manager est <userlabel>.<region>.cloudapp.azure.com.
Puis-je mettre à jour ou modifier la référence de réseau virtuel pour un service cloud existant (support étendu) ?
Non. La référence de réseau virtuel est obligatoire lors de la création d’un service cloud. Pour un service cloud existant, la référence de réseau virtuel ne peut pas être modifiée. L’espace d’adressage du réseau virtuel lui-même peut être modifié à l’aide des API de réseau virtuel.
Certificats et coffres de clés
Pourquoi dois-je gérer mes certificats sur Azure Cloud Services (support étendu) ?
Cloud Services (support étendu) a adopté le même processus que les autres offres de calcul où les certificats résident dans des coffres de clés gérés par le client. Ce processus permet aux clients d’avoir un contrôle total sur leurs secrets et leurs certificats.
Puis-je utiliser un coffre de clés pour tous mes déploiements dans toutes les régions ?
Non. Azure Key Vault est une ressource régionale et les clients ont besoin d’un coffre de clés dans chaque région. Toutefois, un coffre de clés peut être utilisé pour tous les déploiements dans une région donnée.
Lorsque vous spécifiez des secrets/certificats à installer sur un service cloud, la ressource de coffre de clés doit-elle se trouver dans le même abonnement Azure ?
Oui. Nous n'autorisons pas les références de coffre de clés entre abonnements dans Cloud Services afin d’empêcher les attaques par escalade de privilèges via CS-ES. L’abonnement n’est pas une limite que CS-ES croise pour les références aux secrets. La raison pour laquelle nous n’autorisons pas les références entre abonnements est la dernière étape importante pour empêcher des utilisateurs malveillants d’utiliser CS-ES comme mécanisme d’escalade de privilèges pour accéder aux secrets d’autres utilisateurs. L’abonnement n’est pas une limite de sécurité, mais la défense en profondeur est une exigence. Toutefois, vous pouvez utiliser l’extension Key Vault pour obtenir une prise en charge inter-abonnement et inter-région pour vos certificats. Consultez la documentation ici
Lorsque vous spécifiez des secrets/certificats à installer sur un service cloud, la ressource de coffre de clés doit-elle se trouver dans la même région ?
Oui. La raison pour laquelle nous appliquons des limites de région est d’empêcher les utilisateurs de créer des architectures qui ont des dépendances entre régions. L’isolation régionale est un principe de conception clé des applications basées sur le Cloud. Toutefois, vous pouvez utiliser l’extension Key Vault pour obtenir une prise en charge inter-abonnement et inter-région pour vos certificats. Consultez la documentation ici
Problèmes connus
La mise à l’échelle de l’instance de rôle continue d’échouer. Comment corriger ces échecs ?
Lorsque plusieurs appels de mise à l’échelle se produisent sur le même service cloud (pour des rôles différents) au même moment approximatif, en raison d’une condition de concurrence, les composants de plateforme Microsoft ne sont plus synchronisés, ce qui entraîne des échecs. Microsoft travaille activement à la résolution de ce problème. La solution de contournement provisoire suggérée ne consiste pas à mettre automatiquement à l’échelle tous les rôles simultanément.
Visual Studio/Tools ne prend pas en charge le déploiement de CS-ES lorsque le réseau virtuel se trouve dans un autre groupe de ressources. Comment effectuer le déploiement ?
Ce scénario n’est pas pris en charge via Visual Studio. Déployez via PowerShell ou le Portail.
Étapes suivantes
Pour commencer à utiliser Azure Cloud Services (support étendu), consultez Déployer un service cloud (support étendu) à l’aide de PowerShell.