4.4. Estimation du temps de mise à jour des grappes
L'historique de la durée de mise à jour de clusters similaires vous fournit la meilleure estimation pour les futures mises à jour de clusters. Toutefois, si les données historiques ne sont pas disponibles, vous pouvez utiliser la convention suivante pour estimer la durée de mise à jour de votre grappe :
Cluster update time = CVO target update payload deployment time + (# node update iterations x MCO node update time)
Une itération de mise à jour de nœud consiste en un ou plusieurs nœuds mis à jour en parallèle. Les nœuds du plan de contrôle sont toujours mis à jour en parallèle avec les nœuds de calcul. En outre, un ou plusieurs nœuds de calcul peuvent être mis à jour en parallèle sur la base de la valeur maxUnavailable.
Par exemple, pour estimer le temps de mise à jour, considérons un cluster OpenShift Container Platform avec trois nœuds de plan de contrôle et six nœuds de calcul et chaque hôte prend environ 5 minutes pour redémarrer.
Le temps nécessaire au redémarrage d'un nœud donné varie considérablement. Dans les instances en nuage, le redémarrage peut prendre environ 1 à 2 minutes, alors que dans les hôtes physiques en métal nu, le redémarrage peut prendre plus de 15 minutes.
Scénario 1
Lorsque vous définissez maxUnavailable sur 1 pour le plan de contrôle et les nœuds de calcul Machine Config Pool (MCP), les six nœuds de calcul seront mis à jour l'un après l'autre à chaque itération :
Cluster update time = 60 + (6 x 5) = 90 minutes
Scénario 2
Lorsque vous définissez maxUnavailable sur 2 pour le nœud de calcul MCP, deux nœuds de calcul sont mis à jour en parallèle à chaque itération. Il faut donc trois itérations au total pour mettre à jour tous les nœuds.
Cluster update time = 60 + (3 x 5) = 75 minutes
Le paramètre par défaut pour maxUnavailable est 1 pour tous les MCP dans OpenShift Container Platform. Il est recommandé de ne pas modifier maxUnavailable dans le MCP du plan de contrôle.
