Décider du nombre de grappes à créer

Vos utilisateurs risquent moins de rencontrer des indisponibilités lorsque vous répartissez votre configuration entre plusieurs noeuds worker, zones et clusters. Les fonctions intégrées, telles que l'équilibrage de charge et l'isolement, augmentent la résilience en cas de pannes d'hôtes, de réseaux ou d'applications.

Le nombre de grappes que vous créez dépend de votre charge de travail, des politiques et réglementations de l'entreprise, des exigences commerciales, des accords de niveau de service que vous avez conclus avec vos clients, des ressources que vous souhaitez dépenser et de ce que vous voulez faire avec les ressources informatiques.

• Clusters multiples: les clusters multiples sont généralement plus complexes à gérer, mais peuvent vous aider à atteindre des objectifs importants tels que ceux décrits ci-dessous.

  • Respecter les politiques de sécurité qui exigent d'isoler des charges de travail.
  • Tester le fonctionnement de votre application dans différentes versions d'Red Hat OpenShift ou d'autres logiciels de cluster, tels que Calico.
  • Obtenir de meilleures performances pour les utilisateurs situés dans des zones géographiques différentes.
  • Simplifiez l'accès des utilisateurs pour contrôler l'accès au sein d'un cluster en configurant l'accès au niveau de l'instance de cluster au lieu de personnaliser et de gérer plusieurs politiques RBAC au niveau de l'espace de noms.
  • Réduire le nombre de nœuds de travail. La bande passante du réseau sur les machines virtuelles évolutives est d'environ 1000 Mbps. Si vous avez besoin de centaines de nœuds de travail dans un cluster, vous pouvez diviser la configuration en plusieurs clusters comportant moins de nœuds, ou commander des nœuds bare metal.
  • Permettre un plus grand nombre d'intégrations de services, par exemple plus de 5 000 services.
  • Fournir une plus grande disponibilité à une application. Tout comme lorsque vous utilisez 3 zones dans des clusters multizones, vous pouvez améliorer la disponibilité de votre application en configurant trois clusters répartis sur différentes zones.
  • Réduisez vos coûts en achetant des machines moins puissantes pour gérer votre charge de travail.

• Un cluster avec plus de nœuds de travail: Un nombre réduit de clusters peut vous aider à réduire l'effort opérationnel et les coûts par cluster pour les ressources fixes. Au lieu de créer d'autres clusters, vous pouvez ajouter des pools de travailleurs à un cluster pour obtenir différents types de ressources informatiques disponibles pour vos applications et composants de service. Lorsque vous développez l'application, les ressources qu'elle utilise sont dans la même zone ou étroitement connectées dans une zone multiple, par conséquent, vous pouvez émettre des hypothèses sur les temps d'attente, la bande passante ou les incidents en rapport avec ces éléments. Cependant, il est d'autant plus important pour vous d'organiser votre cluster à l'aide d'espaces de noms, de quotas de ressources et d'étiquettes lorsque vous ne disposez que d'un seul cluster.

Déterminer le nombre de sites nécessaires

Un cluster peut distribuer des répliques sur des nœuds de travail en un seul lieu ou sur plusieurs lieux. Ce choix peut avoir un impact sur les types de grappes disponibles dans la section suivante.

La répartition de vos charges de travail sur trois zones permet d'assurer la haute disponibilité de votre application en cas d'indisponibilité d'une zone. Vos noeuds worker doivent être répartis de manière égale dans les trois zones de disponibilité afin d'être conformes à l'accord sur les niveaux de service IBM Cloud pour la configuration de la haute disponibilité.

Une défaillance de zone affecte tous les hôtes de calcul physiques et le stockage NFS. Ces défaillances peuvent être des pannes de courant, de ventilation, de réseau ou de stockage ou être dues à des catastrophes naturelles, telles que des inondations, des tremblements de terre ou des ouragans. Pour se prémunir contre une défaillance de zone, il faut disposer de clusters dans deux zones différentes dont la charge est équilibrée par un équilibreur de charge externe, créer un cluster dans un emplacement multizone, qui répartit le maître entre les zones, ou envisager de mettre en place un second cluster dans une autre zone.

Sélectionner un type de cluster

Les versions et les niveaux d'isolement de noeud worker disponibles dépendent de votre plateforme de conteneur, du type de cluster, du fournisseur d'infrastructure que vous souhaitez utiliser et de l'emplacement de Red Hat OpenShift on IBM Cloud dans lequel vous souhaitez créer votre cluster. Vous pouvez choisir entre Classic, VPC ou Satellite clusters. Le type de cluster dont vous avez besoin dépend des choix que vous avez faits concernant le nombre de clusters et leur emplacement.

Clusters VPC (recommandés)

Les nœuds de travail sont déployés sous forme d'instances de serveurs virtuels sur l'infrastructure VPC. Le VPC est le type d'infrastructure recommandé pour les nouveaux clusters. Il assure par défaut l'isolation du réseau et prend en charge les dernières fonctionnalités d' Red Hat OpenShift on IBM Cloud, notamment les hôtes dédiés et le mode « sécurisé par défaut ».

Clusters Satellite

Les nœuds de travail sont déployés sur votre propre infrastructure, qu'il s'agisse de matériel sur site ou de machines virtuelles hébergées chez d'autres fournisseurs de services cloud tels que AWS, Azure et GCP. Utilisez Satellite lorsque vous devez exécuter des clusters gérés par IBM Cloud en dehors des centres de données IBM Cloud.

Clusters classiques

Les nœuds de travail sont déployés sur des machines virtuelles ou physiques au sein de l'infrastructure classique d' IBM Cloud. Optez pour Classic si vous avez besoin de nœuds de travail « bare metal », de configurations de stockage défini par logiciel (SDS) ou de connexions à des ressources d'infrastructure classique existantes.

Sélectionner un système d'exploitation pour le cluster

Les systèmes d'exploitation disponibles dépendent du type de cluster choisi.

Red Hat Enterprise Linux CoreOS (RHCOS)

[Satellite] VPC

Disponible pour les clusters créés à partir de la version 4.15 Red Hat Enterprise Linux CoreOS (RHCOS) est spécialement conçu pour le site Red Hat OpenShift Container Platform (OCP). Tout en tirant parti de la stabilité et de la sécurité de Red Hat Enterprise Linux (RHEL), RHCOS est léger et minimal, et se concentre sur l'exécution efficace et à grande échelle des charges de travail conteneurisées. Comme il s'agit de composants RHEL, vous bénéficiez du même niveau de sécurité que RHEL, avec en prime une empreinte plus minimale centrée sur les conteneurs, un système de fichiers en lecture seule, des déploiements basés sur des images, et bien d'autres choses encore. Pour une vue d'ensemble du RHCOS, voir Red Hat Enterprise Linux CoreOS(RHCOS). Les nœuds de travail RHCOS pour les clusters VPC ne sont disponibles que pour les clusters qui ont été créés avec une version prenant en charge RHCOS. Les clusters qui sont mis à niveau d'une version qui ne supporte pas RHCOS vers une version qui le supporte ne peuvent pas utiliser les travailleurs RHCOS.

À partir de la version 4.18, les nœuds de travail RHEL sont obsolètes pour les clusters VPC. La version 4.22 est la dernière version à prendre en charge les nœuds de travail RHEL sur VPC. Les prochaines versions nécessiteront des nœuds de travail RHCOS. Pour plus d'informations, voir RHEL deprecation for VPC clusters (en anglais).

Red Hat Enterprise Linux (RHEL) version 9

VPC classique

Disponible pour les clusters créés à partir de la version 4.16. Red Hat Enterprise Linux on IBM Cloud offre aux entreprises un environnement robuste et évolutif, conçu dans un souci de sécurité et adapté aux charges de travail critiques. En associant la plate-forme Red Hat Enterprise Linux à l'infrastructure de IBM Cloud, les entreprises bénéficient d'une haute disponibilité, d'une reprise après sinistre et de capacités de gestion rationalisées. Pour une présentation de RHEL 9, voir Pourquoi exécuter Linux sur IBM Cloud?

Red Hat Enterprise Linux (RHEL) version 8

VPC classique

Disponible pour les clusters créés à partir de la version 4.15. RHEL 8 a atteint sa fin de vie le 31 mai 2024. Pour plus d'informations, voir Red Hat Enterprise Linux 8 Life Cycle.

Définir une stratégie de dénomination des clusters

Veillez à attribuer des noms uniques aux clusters dans les groupes de ressources et les régions de votre compte pour éviter les conflits de noms. Vous ne pouvez pas renommer un cluster après sa création.

Déterminer le nombre de nœuds de travail pour chaque cluster

Le niveau de disponibilité que vous avez configuré pour votre cluster a une incidence sur la couverture que vous recevez dans le cadre de l'accord sur les niveaux de service IBM Cloud. Par exemple, pour recevoir une couverture haute disponibilité selon les termes du contrat de service, vous devez configurer un cluster multizone avec un total d'au moins 6 nœuds de travail, deux nœuds de travail par zone qui sont répartis également sur trois zones.

Le nombre total de noeuds worker que contient un cluster détermine la capacité de calcul disponible pour vos applications dans ce cluster. Vous pouvez protéger votre configuration en cas de défaillance d’un nœud de travail en configurant plusieurs nœuds de travail dans votre cluster. Les défaillances des nœuds de travail peuvent inclure des pannes matérielles, telles que des problèmes d’alimentation, de refroidissement ou de réseau, ainsi que des problèmes au niveau de l’ VM e lui-même.

• Clusters multizones Classic VPC: prévoyez au moins deux nœuds de travail par zone, soit six nœuds au total répartis sur trois zones. En outre, planifiez la capacité totale du cluster à au moins 150 % de votre capacité requise totale de charge de travail, de sorte que si une zone tombe en panne, vous disposiez de ressources disponibles pour la gestion de la charge de travail.

• Clusters à zone unique : prévoyez d’avoir au moins trois nœuds de travail dans votre cluster. De plus, vous souhaitez un noeud supplémentaire de capacité d'unité centrale et de mémoire disponible dans le cluster. Si vos applications nécessitent moins de ressources que celles disponibles sur le nœud de travail, vous pouvez éventuellement limiter le nombre de pods que vous déployez sur un nœud de travail.

Remarque :

• Vous pouvez essayer le cluster autoscaler pour être sûr d'avoir toujours assez de nœuds de travail pour couvrir votre charge de travail.
• Kubernetes limite le nombre maximal de noeuds worker dont vous pouvez disposer dans un cluster. Consultez les quotas des nœuds de travail et des pods pour plus d'informations.

Sélectionner les saveurs des nœuds de travail

Un nœud de travail est une instance VM qui s'exécute sur du matériel physique. Une version de noeud A worker décrit les ressources de calcul, telles que l'unité centrale, la mémoire et la capacité de disque que vous pouvez obtenir lorsque vous mettez à disposition votre noeuds worker. Les noeuds worker de la même version sont regroupés dans des pools de noeuds worker.

Lorsque vous avez choisi un type de cluster, vous avez déjà réfléchi à l'impact de l'emplacement de la saveur des nœuds de travail et du type de machine sur votre décision. Au moment de choisir entre les différents types de nœuds de travail, tenez compte des éléments suivants.

• Tenancy: En fonction du niveau d'isolation matérielle dont vous avez besoin, les nœuds de travailleur virtuel peuvent être partagés par plusieurs clients (multitenancy) ou vous être dédiés (single tenancy). Les machines "bare metal" sont toujours configurées comme des machines dédiées. Lorsque vous devez choisir entre des nœuds partagés et des nœuds dédiés, il peut être utile de consulter votre service juridique afin de discuter du niveau d'isolation de l'infrastructure et de conformité requis par l'environnement de votre application.

  • Partagé: les ressources physiques, telles que le processeur et la mémoire, sont partagées entre toutes les machines virtuelles déployées sur le même matériel physique. Pour permettre à chaque machine virtuelle d'opérer indépendamment, un moniteur de machine virtuelle, également dénommé hyperviseur, segmente les ressources physiques en entités isolées et les alloue à une machine virtuelle en tant que ressources dédiées (isolement par hyperviseur). Les noeuds partagés sont généralement moins coûteux que les noeuds dédiés, car les coûts du matériel sous-jacent sont partagés entre plusieurs clients.
  • Dédié: Toutes les ressources physiques vous sont réservées. Vous pouvez déployer plusieurs noeuds worker en tant que machines virtuelles sur le même hôte physique. A l'instar de la configuration à service partagé, l'hyperviseur veille à ce que chaque noeud worker ait sa part des ressources physiques disponibles.

• Type de machine: Vous avez le choix entre plusieurs types de machines.

  • Machines virtuelles: Pour une plus grande flexibilité, des temps de provisionnement plus rapides, des fonctions d'évolutivité plus automatiques et un prix plus rentable, utilisez des machines virtuelles. Vous pouvez utiliser des machines virtuelles pour la plupart des cas d'utilisation généraux, par exemple les environnements de test et de développement, les environnements de préproduction et de production, les microservices et les applications métier. Il y a toutefois un compromis en termes de performances.

  • Machines bare metal (physiques): si vous avez besoin de calcul haute performance pour des charges de travail gourmandes en données ou en mémoire vive, envisagez de créer des clusters avec des nœuds de travail bare metal. Etant donné que vous disposez d'un contrôle total sur l'isolement et la consommation de ressources pour vos charges de travail, vous pouvez utiliser des machines bare metal pour respecter les normes HIPAA et PCI pour votre environnement. Le type bare metal vous permet d'accéder directement aux ressources physiques sur la machine, par exemple à la mémoire ou à l'UC. Cette configuration élimine l'hyperviseur de machine virtuelle qui alloue des ressources physiques aux machines virtuelles qui s'exécutent sur l'hôte. Au lieu de cela, toutes les ressources d'une machine bare metal sont exclusivement réservées au travailleur, de sorte que vous n'avez pas à vous inquiéter des « voisins bruyantes » partageant des ressources ou ralentissant les performances. Les versions physiques ont davantage de capacité de stockage local que les machines virtuelles et certaines disposent de disques RAID pour augmenter la disponibilité des données. Le stockage local sur le nœud de travail est réservé au traitement à court terme, et les disques principal et auxiliaire sont effacés lorsque vous mettez à jour ou rechargez le nœud de travail. Des techniciens spécialisés dans le « bare metal » sont disponibles pour les clusters classiques et pour les configurations « bare metal » VPC.

    La facturation des nœuds de travail « bare metal » varie selon le type d'infrastructure. Les serveurs bare metal classiques sont facturés mensuellement. Si vous résiliez un serveur bare metal classique avant la fin du mois, vous serez facturé jusqu'à la fin de ce mois. Une fois que vous avez commandé ou annulé un serveur « bare metal » classique, la procédure est traitée manuellement dans votre compte d'infrastructure IBM Cloud; son exécution peut donc prendre plus d'un jour ouvré. Les serveurs « bare metal » VPC sont facturés à l'heure, sans durée minimale d'engagement.

  • Machines SDS: Les saveurs de stockage défini par logiciel (SDS) ont des disques bruts supplémentaires pour le stockage local physique. Contrairement aux disques locaux principaux et auxiliaires, ces disques bruts ne sont pas effacés lors d'une mise à jour ou d'un rechargement d'un nœud de travail. Comme les données sont colocalisées avec le noeud de traitement, les machines SSD conviennent particulièrement aux charges de travail hautes performances. Les versions de stockage définies par le logiciel ne sont disponibles que pour les clusters classiques et ne sont pas prises en charge dans les clusters VPC.

    Etant donné que vous disposez d'un contrôle total sur l'isolement et la consommation de ressources pour vos charges de travail, vous pouvez utiliser des machines SDS pour respecter les normes HIPAA et PCI pour votre environnement.

    En général, vous utilisez les machines SDS dans les cas suivants : * Si vous utilisez un module complémentaire SDS tel qu' Portworx s, utilisez une machine SDS. * Si votre application est une application de type StatefulSet nécessitant un stockage local, vous pouvez utiliser des machines SDS et provisionner des volumes persistants locaux via Kubernetes. * Si vous disposez d'applications personnalisées qui nécessitent du stockage local brut supplémentaire.

• Coût: en général, vos charges de travail intensives sont mieux adaptées à l'exécution sur des machines physiques bare metal, tandis que pour les travaux de test et de développement à moindre coût, vous pouvez opter pour des machines virtuelles sur du matériel partagé ou dédié.

• Localisation: Déterminez les lieux où vous souhaitez installer un cluster. L'endroit où vous le souhaitez peut également déterminer le nombre ou le type de grappes dont vous avez besoin. Par exemple, si vous savez que vous avez besoin d'un lieu à Montréal, cela vous aidera à réduire vos choix. Consultez les lieux disponibles.

• Taille: les nœuds de plus grande taille peuvent s'avérer plus rentables que les nœuds plus petits, en particulier pour les charges de travail conçues pour gagner en efficacité lorsqu'elles sont traitées sur une machine haute performance. Toutefois, si un nœud de travail de grande taille tombe en panne, vous devez vous assurer que votre cluster dispose d’une capacité suffisante pour réaffecter en toute sécurité tous les pods de charge de travail à d’autres nœuds de travail du cluster. Des nœuds de travail plus petits peuvent vous aider à évoluer en toute sécurité. En savoir plus sur la capacité.

• GPU: Vous pouvez utiliser une machine GPU pour accélérer le temps de traitement requis pour les charges de travail à forte intensité de calcul telles que l'IA, l'apprentissage automatique, l'inférence, etc.

• Stockage: chaque VM est associé à un disque permettant de stocker les informations nécessaires au fonctionnement de l' VM, telles que le système de fichiers du système d'exploitation, le runtime du conteneur et le kubelet. Le stockage local sur le noeud worker est conçu pour un traitement à court terme uniquement et les disques de stockage sont effacés lorsque vous supprimez, rechargez, remplacez ou mettez à jour le noeud worker. De plus, l'infrastructure classique et l'infrastructure VPC diffèrent en matière de configuration de disque.

  • Machines virtuelles classiques : Les machines virtuelles classiques ont deux disques connectés. Le disque de stockage principal dispose de 25 Go pour le système de fichiers du système d'exploitation, et le disque de stockage auxiliaire dispose de 100 Go pour les données telles que le runtime du conteneur et le kubelet. Pour des raisons de fiabilité, les volumes de stockage principal et auxiliaire sont des disques locaux plutôt que des réseaux de stockage (SAN). Un réseau SAN procure, entre autres, une capacité de traitement plus élevée lors de la sérialisation des octets sur le disque local et réduit les risques de dégradation du système de fichiers en cas de défaillance du réseau. Le disque auxiliaire est chiffré par défaut.
  • Machines virtuelles de calcul VPC : les machines virtuelles VPC comportent un disque principal qui correspond à un volume de stockage par blocs connecté via le réseau. La couche de stockage n'est pas séparée des autres couches réseau, et le trafic réseau et le trafic de stockage sont routés sur le même réseau. Le disque de stockage principal est utilisé pour stocker des données, telles que le système de fichiers de système d'exploitation, l'environnement d'exécution de conteneur et kubelet, et est chiffré par défaut. Pour les clusters VPC, vous pouvez également fournir un disque secondaire sur vos nœuds de travail. Ce disque optionnel est mis à disposition dans votre compte et vous pouvez le consulter dans la console VPC. Les frais relatifs à ces disques sont distincts du coût de chaque travailleur et figurent sur une ligne différente de votre facture. Ces volumes secondaires sont également pris en compte dans le calcul de l'utilisation du quota de votre compte. Pour éviter les expulsions par défaut des pods, 10 % du disque de données de l' Kubernetes (disque auxiliaire dans Classic, disque de démarrage principal dans VPC) est réservé aux composants système.

  Dans une application avec état, les données jouent un rôle important pour maintenir votre application opérationnelle. Assurez-vous de la haute disponibilité de vos données pour pouvoir les récupérer suite à une défaillance éventuelle. Dans Red Hat OpenShift on IBM Cloud, vous pouvez choisir parmi plusieurs options pour conserver vos données. Par exemple, vous pouvez mettre à disposition du stockage NFS en utilisant des volumes persistants Kubernetes natifs, ou stocker vos données en utilisant un service de base de données IBM Cloud. Pour plus d'informations, consultez la section Planification de données hautement disponibles.

  Choisissez une instance, ou un type de machine, dotée de la configuration de stockage adaptée à votre charge de travail. Certaines versions comportent un mélange de configurations de stockage et de disques suivant. Par exemple, certaines versions peuvent comporter un disque principal SATA avec un disque secondaire SSD RAW.

Pour une liste des saveurs disponibles, voir Saveurs VPC ou Saveurs classiques.

Déterminer la capacité des nœuds de travail pour les ressources

Pour tirer le meilleur parti des performances de votre nœud de travail, tenez compte des éléments suivants lors de la configuration de vos ressources :

• Considérez ce que fait votre application: Commencez par aligner la taille de l'application sur la capacité de l'un des nœuds de travail disponibles. Pensez également à vérifier si votre application récupère des images volumineuses ou en grand nombre, car celles-ci peuvent occuper de l'espace de stockage local sur le nœud de travail.

• Maintenir la puissance de vos coeurs : chaque machine comporte un certain nombre de coeurs. En fonction de la charge de travail de votre application, définissez une limite pour le nombre de pods par coeur, par exemple, 10.

• Évitez la surcharge des nœuds: maintenez votre nœud de travail à environ 75 % de sa capacité afin de laisser de la place pour d'autres pods qui pourraient devoir être planifiés. Si vos applications requièrent un nombre de ressources supérieur au nombre de ressources disponibles sur votre noeud worker, utilisez une autre version de noeud worker susceptible de répondre à ces exigences. En fonction de la charge de travail de votre application, définissez une limite pour le nombre de pods par noeud, par exemple, 40.

• Choisir les services: Combien d'intégrations de services avez-vous décidé d'inclure lorsque vous avez réfléchi au nombre de clusters à créer ? Ces services intégrés et modules complémentaires peuvent créer des pods qui consomment les ressources du cluster et ont un impact sur celles-ci.

• Répliques de votre application : pour déterminer le nombre de noeuds worker dont vous avez besoin, vous pouvez également prendre en compte le nombre de répliques de votre application que vous souhaitez exécuter. Par exemple, si vous savez que votre charge de travail requiert 32 coeurs d'unité centrale et que vous planifiez d'exécuter 16 répliques de votre application, chaque pod de réplique a besoin de 2 coeurs d'unité centrale. Si vous souhaitez n'exécuter qu'un seul pod par d'application par noeud worker, vous pouvez commander un nombre approprié de noeuds worker pour votre type de cluster afin de prendre en charge cette configuration.

• Laissez de la place pour les exigences d'exécution: Les nœuds de travail doivent réserver certaines quantités de ressources CPU et mémoire pour exécuter les composants requis, tels que le système d'exploitation ou le runtime du conteneur.

  La capacité réservée et les instances réservées ne sont pas prises en charge.

Choisir le nombre d'espaces de noms à créer au sein du cluster

Configurez plusieurs espaces de noms lorsque plusieurs équipes et projets se partagent le cluster. Les espaces de nommage sont un moyen de diviser les ressources d'un cluster en utilisant des quotas de ressources et des limites par défaut. Lorsque vous créez de nouveaux espaces de noms, prenez soin de configurer les règles RBAC appropriées pour contrôler les accès. Pour plus d’informations, consultez la section Partager un cluster avec des espaces de noms dans la documentation d’ Kubernetes.

Si vous disposez d'un cluster de petite taille, de deux douzaines d'utilisateurs et de ressources qui sont similaires (par exemple, différentes versions d'un même logiciel), vous n'aurez probablement pas besoin de plusieurs espaces de noms. Vous pourrez utiliser des libellés à la place.

Examinez les informations de sécurité relatives à cette décision dans Isolation et sécurité des conteneurs.

Établir les demandes et les limites de ressources pour les espaces nominatifs

Pour vous assurer que chaque équipe dispose des ressources nécessaires pour déployer des services et exécuter des applications dans le cluster, vous devez définir des quotas de ressources pour chaque espace de noms. Les quotas de ressources déterminent les contraintes de déploiement, telles que le nombre de ressources Kubernetes que vous pouvez déployer, ainsi que la quantité de CPU et de mémoire pouvant être consommée par ces ressources. Après avoir défini un quota, les utilisateurs doivent inclure des limites et des demandes de ressources dans leurs déploiements.

Lorsque vous créez un déploiement, limitez-le également de manière à ce que le pod de votre application ne soit déployé que sur les machines offrant la meilleure combinaison de ressources. Par exemple, vous souhaiterez peut-être limiter une application de base de données à une machine bare metal avec une quantité significative de stockage sur disque local, par exemple, md1c.28x512.4x4tb.

Faites en sorte que vos applications soient également hautement disponibles

De par leur conception, les conteneurs ont une durée de vie brève et ne sont pas à l'abri de défaillances inattendues. Par exemple, un conteneur ou un pod peuvent tomber en panne si une erreur est survenue dans votre application. Pour garantir la haute disponibilité de votre application, vous devez vous assurer de disposer d'un nombre d'instances suffisant pour gérer la charge de travail, ainsi que d'instances supplémentaires en cas de panne. Vous pouvez vous assurer qu'il y a suffisamment d'instances en configurant la mise à l'échelle automatique.

Bonnes pratiques en vigueur

Une fois votre cluster opérationnel, suivez ces bonnes pratiques pour en garantir la sécurité et le bon fonctionnement.

Etapes suivantes

Pour poursuivre le processus de planification, choisissez entre Mise en réseau de clusters VPC et Mise en réseau de clusters classiques. Si vous êtes prêt à créer un cluster, commencez par Préparer votre compte pour créer des clusters.