Bonnes pratiques de calcul

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é avec les régions de 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. Assurez-vous de tenir compte de ces des différences régionales lors de la planification du 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 de zone

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 la résilience de zone et la haute disponibilité de 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 qui est gérée par vCenter Server.

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 inadéquates
  • Pour la gestion des licences et des logiciels
  • Pour plus de transparence et de simplicité des coûts
  • Pour la surveillance
  • Pour la conformité avec 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 des points de terminaison de gestion, utilisez uniquement le 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 logiciel.

Il n'est pas recommandé de réduire le nombre de cœurs du premier cluster, car cela qui héberge des composants clés, tels que vCenter et NSX Manager.

La réduction du nombre de cœurs efficaces dans un cluster ne modifie pas le coût l'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 Limites du nombre de cœurs personnalisé.

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

Les clusters VMware Engine doivent être dimensionnés pour comporter au moins un cluster de secours pour la résilience. Ce nœud de secours est disponible pour le cluster et peut fournissent de la capacité et des ressources supplémentaires lors des pics de charge ou les conflits. Ces nœuds de réserve sont facturés dans le cadre du cloud privé existant.

Si vous avez besoin d'une fiabilité plus élevée, envisagez d'ajouter plus de nœuds de rechange au cluster d'être disponible pendant les intervalles 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" (FTT) 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é nécessaires est important.

Étape suivante