Bonnes pratiques concernant Compute

Cette page présente les bonnes pratiques de calcul pour Google Cloud VMware Engine.

Sélectionnez la région la plus adaptée à votre application

Pour choisir la meilleure région pour vos applications, tenez compte des facteurs suivants:

  • Pour réduire la latence réseau et améliorer l'expérience client, sélectionnez un emplacement le plus proche de vos utilisateurs. La console Google Cloud fournit un tableau de bord des performances en temps réel qui peut vous aider à visualiser la latence entre les régions, ainsi qu'entre les utilisateurs Internet et une région Google Cloud.
  • Pour maintenir les performances de l'application, optimisez la connectivité aux installations sur site en sélectionnant la région Google Cloud la plus proche. Pour les déploiements multicloud, tenez compte de la proximité des régions d'autres fournisseurs cloud.
  • Pour vous assurer que vos applications respectent les réglementations, telles que les Règles de conformité de l'industrie des cartes de paiement (PCI) ou le Règlement général sur la protection des données (RGPD) européen, sélectionnez une région qui accepte ces exigences.
  • Les coûts et les tarifs varient selon les régions. Veillez à tenir compte de ces différences régionales lorsque vous planifiez votre déploiement.
  • Lorsque vous sélectionnez une zone géographique, certains codes SKU peuvent ne pas être disponibles dans certaines régions.

Décider quand choisir une conception multirégionale

Dans les situations suivantes, vous pouvez souhaiter déployer dans plusieurs clouds privés VMware Engine dans différentes régions pour la même charge de travail ou la même portée de projet:

  • Implémentations de reprise après sinistre qui utilisent Site Recovery Manager (SRM) ou Zerto
  • Applications qui nécessitent une disponibilité mondiale ou une faible latence pour leur base d'utilisateurs.
  • Exigences de planification de la capacité spécifiques à une région

Concevoir pour la résilience des zones

VMware Engine fournit une redondance de zone dans des régions spécifiques. Dans ces régions, pour une meilleure tolérance aux pannes, vous pouvez également déployer des clouds privés en tant que cluster étendu. Pour en savoir plus sur ces régions, consultez les notes de version de VMware Engine.

Lorsqu'il est déployé en tant que cluster étendu, votre cloud privé comporte des nœuds dans deux zones indépendantes. Vous devez disposer d'un nombre égal de nœuds dans chaque zone pour prendre en charge cette conception. Une telle conception garantit la disponibilité des applications grâce à la résilience de zone et à la haute disponibilité VMware vSphere.

Lors du provisionnement d'un cloud privé étendu, les VM peuvent s'exécuter des deux côtés d'un cloud privé étendu. Utilisez des règles d'affinité pour contrôler l'emplacement des VM de charge de travail sur les hôtes d'un cluster en les regroupant et en les épinglant à un site. Une telle conception assure la résilience des zones grâce à la haute disponibilité (HA) des applications.

Séparer les environnements sur plusieurs clouds privés

Un cloud privé est une pile VMware Cloud Foundation indépendante gérée par un serveur vCenter.

Vous pouvez segmenter votre empreinte VMware Engine sur plusieurs clouds privés. Par exemple, utilisez un vCenter Server dédié dans les cas suivants:

  • Pour un type de charge de travail spécifique, tel que l'infrastructure de bureau virtuel (VDI)
  • Lorsque les limites d'un cloud privé sont insuffisantes
  • Pour la gestion des licences et des logiciels
  • Pour plus de transparence et de simplicité
  • Pour la surveillance
  • Pour respecter les exigences réglementaires
  • Pour la multi-instance à tous les niveaux, y compris les composants de gestion et l'infrastructure

Pour éviter la prolifération inutile de points de terminaison de gestion, n'utilisez que le nombre requis de clouds privés.

Optimiser le nombre de cœurs

VMware Engine vous permet de réduire le nombre de cœurs de processeur effectifs exposés à l'hyperviseur ESXi. Cela peut être souhaitable ou obligatoire en vertu de certains contrats de licence de logiciels.

Nous vous déconseillons de réduire le nombre de cœurs du premier cluster, car il héberge des composants clés tels que vCenter et NSX Manager.

La réduction du nombre de cœurs effectifs dans un cluster n'a pas d'incidence sur le coût d'exécution du cluster, en particulier pour les charges de travail Oracle. Pour en savoir plus, consultez les conseils sur l'assistance et la licence.

Pour en savoir plus, consultez la section Limites du nombre de cœurs personnalisé.

Ajouter des nœuds de secours pour la résilience

Les clusters VMware Engine doivent être dimensionnés de manière à disposer d'au moins un nœud de secours pour la résilience. Ce nœud de réserve est disponible pour le cluster et peut fournir une capacité et des ressources supplémentaires en cas de charge ou de contention élevées. Ces nœuds de réserve sont facturés dans le cadre du cloud privé existant.

Si une fiabilité plus élevée est requise, envisagez d'ajouter des nœuds de réserve au cluster pour qu'ils soient disponibles pendant les périodes de maintenance. Planifier l'exécution des charges de travail sur ces nœuds de réserve permet d'optimiser l'utilisation des clusters dans les clouds privés.

Définir le nombre d'échecs à tolérer

Pour VMware vSAN, utilisez l'attribut "Échecs à tolérer" dans les règles de stockage vSAN pour définir le nombre d'échecs qu'un cluster peut tolérer sans affecter son intégrité des données ni la disponibilité des VM.

Plus la valeur FTT est élevée, plus le nombre d'hôtes de capacité requis est important.

Étape suivante