Lorsque vous prévoyez d'exécuter des charges de travail de VM sur des nœuds à locataire unique, vous devez d'abord décider comment déployer ces nœuds. En particulier, vous devez décider du nombre de groupes de nœuds dont vous avez besoin, et de la stratégie de maintenance que les groupes de nœuds doivent utiliser:
Groupes de nœuds:pour choisir le nombre approprié de groupes de nœuds, vous devez prendre en compte la disponibilité et l'utilisation des ressources. Bien qu'un petit nombre de groupes de nœuds vous permette d'optimiser l'utilisation des ressources et les coûts, il vous limite à une seule zone. Le déploiement de groupes de nœuds sur plusieurs zones vous permet d'améliorer la disponibilité, mais peut réduire l'utilisation des ressources.
Stratégies d'autoscaling et de maintenance : en fonction des exigences de licence des systèmes d'exploitation et des logiciels que vous prévoyez d'exécuter, l'autoscaling des nœuds et votre choix d'une stratégie de maintenance peuvent avoir un impact sur le coût de votre licence et votre disponibilité.
Pour prendre la bonne décision concernant l'utilisation des nœuds à locataire unique, vous devez soigneusement étudier vos exigences.
Évaluer les exigences
La section suivante liste plusieurs exigences que vous devez prendre en compte avant de déterminer le nombre de groupes de nœuds dont vous avez besoin, ainsi que la stratégie de maintenance que les groupes de nœuds doivent adopter.
Licences BYOL et par cœur
Si vous envisagez l'option Bring Your Own License (BYOL) avec Compute Engine, les nœuds à locataire unique peuvent vous permettre de répondre aux exigences ou aux contraintes matérielles imposées par ces licences.
Certains logiciels et systèmes d'exploitation tels que Windows Server peuvent être licenciés par cœur de processeur physique et définir des limites de la fréquence à laquelle vous êtes autorisé à modifier le matériel qui constitue vos machines virtuelles. L'autoscaling des nœuds et les stratégies de maintenance par défaut peuvent entraîner des modifications plus fréquentes du matériel que vos conditions de licence ne le permettent, ce qui peut entraîner des frais de licence supplémentaires.
Pour optimiser l'utilisation de BYOL par cœur, observez les bonnes pratiques suivantes :
Recherchez un équilibre entre l'optimisation du coût de l'infrastructure et le coût des licences : pour calculer le coût global d'exécution des charges de travail BYOL sur Compute Engine, vous devez prendre en compte à la fois le coût de l'infrastructure et le coût des licences. Dans certains cas, la réduction du coût d'infrastructure peut augmenter les frais de licence, ou inversement. Par exemple, l'utilisation d'un type de nœud comportant un grand nombre de cœurs peut être préférable en termes de coût/performances pour certaines charges de travail, mais peut entraîner des coûts de licence supplémentaires si les licences sont facturées par cœur.
Utilisez des groupes de nœuds distincts pour les charges de travail BYOL et non BYOL : pour limiter le nombre de cœurs dont vous avez besoin pour les licences, évitez de mélanger les charges de travail BYOL et non BYOL dans un seul groupe de nœuds. Utilisez plutôt des groupes de nœuds distincts.
Si vous utilisez plusieurs modèles de licence BYOL (par exemple, Windows Server Datacenter et Standard), la répartition des groupes de nœuds par modèle de licence peut simplifier le suivi des licences et réduire leur coût.
Utilisez la sursollicitation des processeurs et les types de nœuds avec un ratio cœur/mémoire élevé:les types de nœuds diffèrent dans leur ratio entre les sockets, les cœurs et la mémoire. L'utilisation d'un type de nœud doté d'un ratio cœur/mémoire plus élevé et l'activation de la sursollicitation des processeurs peuvent contribuer à réduire le nombre de cœurs dont vous avez besoin pour la licence.
Éviter l'autoscaling vertical:l'autoscaling de groupes de nœuds vous permet d'augmenter ou de réduire automatiquement un groupe de nœuds en fonction de la demande actuelle. La croissance et la réduction fréquentes d'un groupe de nœuds implique une modification fréquente du matériel sur lequel s'exécutent vos VM.
Si vous changez de matériel plus fréquemment que vous n'êtes autorisé à déplacer les licences entre les machines physiques, ces changements de matériel peuvent conduire à une situation où vous devez obtenir une licence pour plus de cœurs que vous n'en utilisez réellement.
Si la fréquence de déplacement entre les machines physiques est limitée, vous pouvez éviter des coûts de licence excessifs en désactivant l'autoscaling ou en configurant l'autoscaling pour un scaling horizontal uniquement.
N'utilisez pas la stratégie de maintenance par défaut : la stratégie de maintenance par défaut vous permet d'optimiser la disponibilité des VM, mais peut entraîner des modifications matérielles fréquentes. Pour limiter les modifications matérielles et optimiser les coûts de licence, utilisez plutôt la stratégie de migration au cours de la maintenance du groupe de nœuds ou de redémarrage sur place.
Pour les charges de travail ne nécessitant pas de licence par cœur, appliquez plutôt les bonnes pratiques suivantes :
- Utilisez la stratégie de maintenance par défaut : avec la migration à chaud, la stratégie de maintenance par défaut offre une meilleure disponibilité que le redémarrage sur place et évite les coûts d'infrastructure supplémentaires de migration au cours de la maintenance du groupe de nœuds.
Gestion
Lorsque vous avez plusieurs charges de travail, ou lorsque vous avez des charges de travail de développement et de production à exécuter sur des nœuds à locataire unique, tenez compte des bonnes pratiques suivantes :
Utilisez des groupes de nœuds distincts pour les environnements de développement et de production : l'utilisation de groupes de nœuds distincts vous aide à isoler les environnements des autres et à éviter des situations telles que les suivantes :
- Une VM de développement peut affecter les performances des VM de production en consommant trop de ressources de processeur, de disque ou de réseau ("voisin bruyant").
- Une charge de travail de développement peut épuiser la capacité d'un groupe de nœuds, ce qui empêche la création de nouvelles VM de production.
Limitez le nombre de groupes de nœuds dans chaque environnement : si vous exécutez plusieurs groupes de nœuds, il peut s'avérer difficile d'utiliser pleinement chaque groupe de nœuds. Pour en optimiser l'utilisation, combinez les charges de travail de chaque environnement et planifiez-les sur un petit nombre de groupes de nœuds.
Utilisez des projets dédiés pour gérer les groupes de nœuds : pour chaque environnement, créez un projet dédié à la gestion des groupes de nœuds. Ensuite, partagez les groupes de nœuds avec les projets contenant des charges de travail.
Cette approche vous permet de simplifier le contrôle des accès en utilisant un projet distinct pour chaque charge de travail, tout en optimisant l'utilisation des ressources en partageant les groupes de nœuds entre les charges de travail.
Partagez des groupes de nœuds avec des projets individuels : au lieu de partager un groupe de nœuds avec l'ensemble d'une organisation, ne le partagez qu'avec des projets individuels. Sélectionner des projets individuellement vous permet de maintenir une séparation entre les environnements et d'éviter de divulguer des informations sur les groupes de nœuds à d'autres projets.
Établissez un processus d'attribution des coûts internes : le coût d'exécution d'un groupe de nœuds est comptabilisé dans le projet qui contient le groupe de nœuds. Si vous devez attribuer ce coût à des projets ou charges de travail individuels, envisagez de suivre l'utilisation de vos VM à locataire unique et d'utiliser ces données pour effectuer une attribution de coûts interne.
Disponibilité
Vos charges de travail peuvent différer selon leurs exigences de disponibilité, et déterminer si la haute disponibilité peut être atteinte sur la couche d'application ou si elle doit être mise en œuvre sur la couche d'infrastructure :
Applications en cluster : certaines de vos charges de travail peuvent mettre en œuvre la haute disponibilité dans l'application à l'aide de techniques de clustering telles que la réplication et l'équilibrage de charge.
Les contrôleurs de domaine Active Directory, les instances de cluster de basculement SQL Server et les groupes de disponibilité, ou les applications en équilibrage de charge en cluster exécutées dans IIS, sont des exemples de telles charges de travail.
Les applications en cluster peuvent généralement gérer des pannes individuelles de VM tant que la majorité des VM restent disponibles.
Applications hors cluster : certaines de vos charges de travail peuvent ne pas mettre en œuvre de fonctionnalités de clustering et nécessiter plutôt que la VM soit maintenue disponible.
Les serveurs de bases de données non répliqués ou les serveurs d'applications avec état en sont des exemples.
Pour optimiser la disponibilité des VM individuelles, vous devez vous assurer que la VM peut être migrée à chaud en cas de maintenance des nœuds à venir.
La migration à chaud est compatible avec la stratégie de maintenance par défaut et la stratégie de maintenance de la migration dans un groupe de nœuds, sauf si vous utilisez la stratégie de maintenance de redémarrage sur place.
Applications non critiques : les charges de travail par lot, les charges de travail de développement et de test, et les autres charges de travail de priorité inférieure peuvent ne pas avoir d'exigences de disponibilité particulières. Pour ces charges de travail, ceci est acceptable si des VM individuelles ne sont pas disponibles lors de la maintenance du nœud.
Pour répondre aux exigences de disponibilité de vos charges de travail, tenez compte des bonnes pratiques suivantes :
Déployez des charges de travail en cluster à l'aide de groupes de nœuds dans différentes zones ou régions:les nœuds à locataire unique et les groupes de nœuds sont une ressource zonale. Pour vous protéger contre les pannes zonales, déployez plusieurs groupes de nœuds dans différentes zones ou régions. Utilisez l'affinité de nœuds pour planifier des VM afin que chaque instance de votre application en cluster s'exécute sur un nœud différent dans une zone ou une région différente.
Si deux ou plusieurs de vos groupes de nœuds appliquent la stratégie de maintenance par défaut ou de redémarrage en place, configurez les intervalles de maintenance de manière à ce qu'ils ne se chevauchent pas.
Si plusieurs instances de vos applications en cluster doivent s'exécuter dans une même zone, utilisez l'anti-affinité pour vous assurer que les instances de VM sont planifiées sur différents nœuds ou groupes de nœuds.
Éviter les stratégies de maintenance "Redémarrer sur place" pour les charges de travail hors cluster nécessitant une haute disponibilité : étant donné que la stratégie de maintenance Redémarrer sur place arrête les VM lorsque le nœud sous-jacent nécessite une maintenance. Il est préférable d'appliquer une stratégie de maintenance différente pour les groupes de nœuds qui exécutent des charges de travail hors cluster nécessitant une haute disponibilité.
Utilisez les groupes d'instances gérés pour augmenter la résilience et la disponibilité des charges de travail : vous pouvez renforcer la résilience et la disponibilité de votre déploiement en utilisant des groupes d'instances gérés pour surveiller l'état de vos charges de travail et recréer automatiquement des instances de VM si nécessaire. Vous pouvez utiliser des groupes d'instances gérés pour les charges de travail sans état et avec état.
Performances
La sensibilité de vos charges de travail aux différences de performances peut différer. Pour certaines applications internes ou charges de travail de test, il peut s'avérer plus important d'optimiser les coûts que de garantir des performances constantes tout au long de la journée. Pour d'autres charges de travail telles que les applications externes, les performances peuvent être essentielles et plus importantes que l'utilisation des ressources.
Pour optimiser l'utilisation de vos nœuds à locataire unique, tenez compte des bonnes pratiques suivantes :
Utilisez des groupes de nœuds dédiés et la sursollicitation des processeurs pour les charges de travail non sensibles à la performance : la sursollicitation des processeurs vous permet d'augmenter la densité des VM sur les nœuds à locataire unique et de réduire le nombre de nœuds à locataire unique requis.
Pour utiliser la sursollicitation des processeurs, vous devez utiliser un type de nœud compatible avec la sursollicitation des processeurs. L'activation de la sursollicitation des processeurs pour un groupe de nœuds entraîne des frais supplémentaires par nœud à locataire unique.
La sursollicitation des processeurs peut s'avérer plus rentable si vous utilisez un groupe de nœuds dédié pour les charges de travail adaptées à la sursollicitation des processeurs et activez la sursollicitation des processeurs pour ce groupe de nœuds uniquement. Laissez la sursollicitation des processeurs désactivée pour tous les groupes de nœuds qui doivent exécuter des charges de travail sensibles aux performances.
Utilisez un type de nœud avec un ratio cœur/mémoire élevé pour la sursollicitation des processeurs : bien que la sursollicitation des processeurs vous permette de partager des cœurs entre plusieurs VM, elle ne vous permet pas de partager de la mémoire entre VM. L'utilisation d'un type de nœud disposant d'une quantité de mémoire relativement élevée par cœur de processeur vous permet de garantir que la mémoire ne devient pas un facteur limitant.
Utilisez l'autoscaling de nœuds pour les charges de travail sensibles aux performances : pour répondre aux besoins variables en ressources des charges de travail sensibles aux performances, configurez votre groupe de nœuds pour utiliser l'autoscaling.
Modèles de déploiement
La meilleure façon d'utiliser des nœuds à locataire unique dépend de vos exigences individuelles. La section suivante décrit une sélection de modèles que vous pouvez utiliser comme point de départ pour dériver une architecture adaptée à vos besoins individuels.
Plusieurs groupes de nœuds pour des exigences de performances mixtes
Si vous disposez d'une combinaison de charges de travail sensibles aux performances (par exemple, les applications destinées au client) et non sensibles aux performances (par exemple, les applications internes), vous pouvez utiliser plusieurs groupes de nœuds utilisant des types de nœuds différents :
- Un groupe de nœuds utilise la sursollicitation des processeurs et un type de nœud avec un ratio processeur virtuel/mémoire de 1:8. Ce groupe de nœuds est utilisé pour les charges de travail insensibles aux performances.
- Un deuxième groupe de nœuds utilise un type de nœud optimisé pour le calcul avec un ratio processeur virtuel/mémoire de 1:4 sans sursollicitation des processeurs. Ce groupe de nœuds est utilisé pour les charges de travail critiques en termes de performances. Il est configuré pour évoluer à la demande.
Haute disponibilité multizone pour les charges de travail sous licence en cluster et par cœur
Si vous exécutez des charges de travail en cluster utilisant des licences par cœur et devez minimiser les modifications matérielles, vous pouvez trouver un équilibre entre la disponibilité et la gestion des licences en utilisant plusieurs groupes de nœuds avec des intervalles de maintenance sans chevauchement :
- Plusieurs groupes de nœuds sont déployés dans différentes zones ou régions.
- Tous les groupes de nœuds utilisent la stratégie de maintenance de redémarrage. Les groupes de nœuds utilisent des fenêtres de maintenance qui ne se chevauchent pas, de sorte que seul un groupe de nœuds à la fois peut subir des interruptions liées à la maintenance.
- Les instances de VM qui exécutent des charges de travail en cluster utilisent des libellés d'affinité, de sorte que chaque nœud de cluster est planifié sur un groupe de nœuds d'une zone différente.
Haute disponibilité multizone pour les charges de travail sous licence mixtes et par cœur
Si vous utilisez des licences par cœur, mais que toutes vos charges de travail ne sont pas mises en cluster, vous pouvez étendre le modèle précédent en utilisant des stratégies de maintenance hétérogènes :
- Le groupe de nœuds principal est déployé dans la zone
aet exécute des charges de travail en cluster et hors cluster. Pour minimiser les pannes causées par la maintenance matérielle, le groupe de nœuds utilise la stratégie de maintenance migrer dans un groupe de nœuds. - Un ou plusieurs groupes de nœuds secondaires sont déployés dans des zones ou des régions supplémentaires. Ces groupes de nœuds utilisent la règle de maintenance redémarrer, mais utilisent des intervalles de maintenance qui ne se chevauchent pas.
- Les instances de VM qui exécutent des charges de travail en cluster utilisent des libellés d'affinité, de sorte que chaque nœud de cluster est planifié sur un groupe de nœuds d'une zone différente.
- Les instances de VM qui exécutent des charges de travail hors cluster utilisent des libellés d'affinité afin qu'elles se déploient sur le groupe de nœuds principal.
En programmant uniquement les charges de travail en cluster sur les groupes de nœuds secondaires, vous pouvez vous assurer que les interruptions temporaires causées par la stratégie de maintenance de redémarrage ont un impact minimal sur la disponibilité globale. Dans le même temps, vous limitez les frais de licence et d'infrastructure en n'utilisant la stratégie de maintenance migrer dans un groupe de nœuds que pour le groupe de nœuds principal.
Étape suivante
Obtenez plus d'informations sur les nœuds à locataire unique.
Découvrez comment sursolliciter des processeurs sur les VM à locataire unique.
Découvrez comment apporter vos propres licences.