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 devront demander un quota à l’aide des mêmes processus que tout autre produit Azure Resource Manager. Le quota dans Azure Resource Manager est régional et une demande de quota distincte sera nécessaire pour chaque région.
Pourquoi ne puis-je plus voir d’emplacement de production et de préproduction ?
Services cloud (support étendu) ne prend pas en charge le concept logique d’un service hébergé, qui inclut 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 service hébergé n’existe plus, vous ne pouvez plus créer de service cloud vide (support étendu).
Azure Cloud Services (support étendu) prend-il en charge Resource Health Check (RHC) ?
Non, Services cloud (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 Worker et web changent-ils ?
Il n’y a pas de changement dans la conception, l’architecture ou les composants des rôles Worker et web.
La mise à l’échelle de l’instance de rôle continue d’échouer. Comment corriger ce problème ?
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.
En quoi les mises à jour du système d’exploitation invité seront différentes ?
Il n’y a aucune modification apportée à la méthode de lancement. Azure Cloud Services (classique) et Azure 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 d’Azure Cloud Services (support étendu) prend uniquement en charge l’état Arrêté (alloué) qui apparaît comme « arrêté » dans le portail Azure. Arrêté : l’état 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 Services cloud (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 de mon service cloud (support étendu)
L’ID de déploiement, également appelé 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 du service cloud (support étendu)
Existe-t-il des différences de tarification entre Azure Cloud Services (classique) et Azure Cloud Services (support étendu) ?
Azure Cloud Services (support étendu) utilise Azure Key Vault et des IP publiques du niveau De base (ARM). 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 puis-je voir une modification du montant de facturation après novembre 2022 pour les déploiements Services cloud (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 vers d’autres régions ou Internet. Pour obtenir des informations de référence supplémentaires, consultez la page de tarification de la bande passante Azure.
Qu’est-ce que le contrat de niveau de service (SLA) pour Services cloud (support étendu) ?
Le contrat de niveau de service (SLA) pour Services cloud (prise en charge étendue) est identique au contrat SLA pour Services cloud (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 ? (template, parameter, 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 change-t-il sur Services cloud (support étendu)
Aucune modification n’est requise pour votre code d’application empaqueté au format cspkg. Vos applications existantes continueront à fonctionner comme avant.
Cloud Services (support étendu) autorise-t-il le format de package CTP ?
Le format du package CTP n’est pas pris en charge dans Services cloud (prise en charge étendue). 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 managed Identity Support. Par conséquent, Stockage compte 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 Azure Cloud Services (classique), mais elles étaient simplement 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 Services cloud (support étendu) ne peut pas être partagé avec des déploiements à partir d’autres produits de calcul tels que Machines Virtuelles, Machines Virtuelles groupes identiques, 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 permutable ou déployez deux Services cloud avec un CName dans Azure DNS\Traffic Manager afin que l’adresse IP puisse être pointée vers l’une ou l’autre d’entre elles.
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 VNet.
Certificats et coffres de clés
Pourquoi dois-je gérer mes certificats sur Azure Cloud Services (support étendu) ?
Azure 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. Cela 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’autorisez pas les références entre les coffres de clés d’abonnement dans Services cloud à protéger contre l’escalade des attaques par privilèges via CS-ES. L’abonnement n’est pas une limite que CS-ES traversera pour les références aux secrets. La raison pour laquelle nous n’autorisons pas les références inter-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. Reportez-vous à 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. Reportez-vous à la documentation ici
Problèmes connus
La mise à l’échelle de l’instance de rôle continue d’échouer. Comment corriger ce problème ?
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 déployer ?
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.