Red Hat OpenShift avec NetApp est conçu pour séparer logiquement le trafic réseau à des fins différentes en utilisant des réseaux locaux virtuels (VLAN). Cette configuration peut être mise à l’échelle pour répondre aux demandes des clients ou pour fournir une isolation supplémentaire pour des services réseau spécifiques. Le tableau suivant répertorie les VLAN requis pour implémenter la solution lors de la validation de la solution 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 minimal 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.

Étant donné que Red Hat OpenShift se déploie initialement avec trois nœuds maîtres, une configuration à deux nœuds peut entraîner l'occupation du même nœud par au moins deux maîtres, ce qui peut entraîner une éventuelle panne d'OpenShift si ce nœud spécifique devient indisponible. Par conséquent, il s’agit d’une bonne pratique de Red Hat de déployer au moins trois nœuds de calcul OSP afin que les maîtres OpenShift puissent être répartis uniformément et que la solution reçoive un degré supplémentaire de tolérance aux pannes.

La distribution des maîtres OpenShift sur plusieurs nœuds d'hyperviseur peut être réalisée en activant l'affinité VM/hôte.

L'affinité est un moyen de définir des règles pour un ensemble de machines virtuelles et/ou d'hôtes qui déterminent si les machines virtuelles s'exécutent ensemble sur le même hôte ou sur des hôtes du groupe ou sur des hôtes différents. Il est appliqué aux machines virtuelles en créant des groupes d'affinité constitués de machines virtuelles et/ou d'hôtes avec un ensemble de paramètres et de conditions identiques. Selon que les machines virtuelles d'un groupe d'affinité s'exécutent sur le même hôte ou sur les mêmes hôtes du groupe ou séparément sur des hôtes différents, les paramètres du groupe d'affinité peuvent définir une affinité positive ou une affinité négative. Dans la plateforme Red Hat OpenStack, les règles d'affinité et d'anti-affinité d'hôte peuvent être créées et appliquées en créant des groupes de serveurs et en configurant des filtres afin 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 dispose d'un maximum par défaut de 10 instances virtuelles dont il peut gérer le placement. Cela peut être modifié en mettant à jour les quotas par défaut pour Nova.

Pour configurer les groupes d'affinité, voir"Comment configurer Affinity et Anti-Affinity pour les instances OpenStack ?" .

IPI facilite le déploiement des clusters OpenShift grâce à l'assistant interactif décrit précédemment dans ce document. Cependant, il est possible que vous ayez besoin de modifier certaines valeurs par défaut dans le cadre d’un déploiement de cluster.

Dans ces cas, vous pouvez exécuter l'assistant sans déployer immédiatement un cluster ; à la place, il crée un fichier de configuration à partir duquel le cluster peut être déployé ultérieurement. Ceci est très utile si vous devez modifier des paramètres IPI par défaut ou si vous souhaitez déployer plusieurs clusters identiques dans votre environnement pour d'autres utilisations telles que le multi-hébergement. 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 personnalisations" .