Red Hat OpenShift avec NetApp est conçu pour séparer logiquement le trafic réseau à différents fins à l'aide de réseaux locaux virtuels (VLAN). Cette configuration peut être adaptée aux besoins du client ou pour assurer une isolation supplémentaire pour des services réseau spécifiques. Le tableau suivant répertorie les VLAN nécessaires à la mise en œuvre de la solution lors de sa validation chez NetApp.

L'infrastructure suivante doit être en place avant le déploiement de la plateforme de conteneurs OpenShift :

L'architecture vérifiée décrite dans ce document présente le déploiement matériel minimum adapté aux opérations HA en déployant trois nœuds de contrôleur OSP et deux nœuds de calcul OSP. Cette architecture garantit une configuration tolérante aux pannes dans laquelle les deux nœuds de calcul peuvent lancer des instances virtuelles et les machines virtuelles déployées peuvent migrer entre les deux hyperviseurs.

Dans la mesure où Red Hat OpenShift se déploie initialement avec trois nœuds maîtres, une configuration à deux nœuds risque d'entraîner l'occupation d'au moins deux maîtres du même nœud, ce qui peut entraîner une interruption possible d'OpenShift si ce nœud spécifique devient indisponible. C'est pourquoi il s'agit d'une meilleure pratique Red Hat de déployer au moins trois nœuds de calcul OSP afin que les maîtres OpenShift puissent être distribués uniformément et que la solution reçoive un degré supplémentaire de tolérance aux pannes.

Distribution des maîtres OpenShift sur plusieurs nœuds d'hyperviseur peut être obtenue grâce à l'affinité VM/hôte.

L'affinité est un moyen de définir des règles pour un ensemble de VM et/ou d'hôtes qui déterminent si les VM s'exécutent sur le même hôte ou sur des hôtes du groupe ou sur des hôtes différents. Elle est appliquée aux VM par la création de groupes d'affinités comprenant des VM et/ou des hôtes avec un ensemble de paramètres et de conditions identiques. Selon que les VM d'un groupe d'affinité s'exécutent sur le même hôte ou sur les hôtes du groupe ou séparément sur des hôtes différents, les paramètres du groupe d'affinités peuvent définir une affinité positive ou négative. Dans Red Hat OpenStack Platform, il est possible de créer et d'appliquer des règles d'affinité des hôtes et d'anti-affinité en créant des groupes de serveurs et en configurant des filtres de sorte que les instances déployées par Nova dans un groupe de serveurs se déploient sur différents nœuds de calcul.

Un groupe de serveurs possède un maximum de 10 instances virtuelles par défaut pour lesquelles il peut gérer le placement. Ceci peut être modifié en mettant à jour les quotas par défaut pour Nova.

Pour configurer des groupes d'affinités, voir "Comment configurer l'affinité et la anti-affinité pour les instances OpenStack ?".

IPI facilite le déploiement des clusters OpenShift via l'assistant interactif présenté plus haut dans ce document. Cependant, il est possible que vous deviez modifier certaines valeurs par défaut dans le cadre d'un déploiement de cluster.

Dans ces cas, vous pouvez exécuter et effectuer la tâche sans déployer immédiatement un cluster ; il crée alors un fichier de configuration à partir duquel le cluster peut être déployé ultérieurement. Cette approche est très utile pour modifier les valeurs par défaut des IPI ou pour déployer plusieurs clusters identiques dans votre environnement pour d'autres utilisations telles que la colocation. Pour plus d'informations sur la création d'une configuration d'installation personnalisée pour OpenShift, consultez "Red Hat OpenShift installation d'un cluster sur OpenStack avec personnalisation".