F5 vCMP : hôte, guests, états et ressources

vCMP organise des guests BIG-IP sur les plateformes compatibles. L’hôte attribue des ressources et présente des réseaux aux guests ; chaque guest possède sa propre configuration BIG-IP.

Ce guide traite le modèle vCMP documenté pour les appliances concernées. Il ne constitue pas une procédure pour les tenants F5OS de rSeries ou VELOS. Relevez le modèle et le système hôte avant d’utiliser un exemple d’un ancien support.

Configured conserve la définition du guest sans le faire traiter le trafic. Provisioned alloue les ressources prévues sans déployer le guest comme un service actif. Deployed permet son démarrage et son exploitation selon sa configuration.

Changer d’état peut modifier allocation et disponibilité. Le statut du guest côté host et le statut de ses pools à l’intérieur du guest sont des informations différentes.

Les paramètres de cœurs et, pour VIPRION, de slots doivent correspondre aux possibilités du matériel et de la version. La mémoire attribuée au guest est liée au mécanisme d’allocation vCMP ; elle ne se règle pas comme une mémoire indépendante dans tous les cas.

Ne déduisez pas un ratio CPU/RAM universel d’un exemple ancien. Relevez les ressources libres sur l’hôte et le besoin réel du guest, puis utilisez la procédure correspondant au modèle pour modifier l’allocation.

Un guest ne peut pas utiliser un réseau que l’hôte ne lui présente pas correctement. Vérifiez VLANs et interfaces côté host, association des VLANs au guest, puis self IP et routes à l’intérieur du guest.

La connectivité de management du guest possède également son mode propre. Une GUI accessible ne prouve pas que les VLANs applicatifs sont présents ou que les serveurs sont joignables.

Sur l’hôte vCMP, inspectez le guest nommé et les VLANs. À l’intérieur du guest, relevez version et provisioning BIG-IP. Les commandes ne doivent pas être saisies indifféremment dans les deux consoles.

Une mise à jour du guest et une mise à jour du host ne sont pas une seule opération. Vérifiez la matrice de compatibilité, les images et l’effet d’une intervention sur l’hôte qui porte plusieurs guests.

Pour une paire HA de guests, la capacité de reprise dépend aussi des hôtes. En laboratoire, relevez état du guest, version active et résultat applicatif après une transition prévue ; ne concluez pas au succès à partir du seul statut de l’image.

L’allocation se contrôle sur l’hôte vCMP, tandis que le provisioning des modules se contrôle dans le guest. Avant de changer des cœurs, relevez l’état du guest, les ressources déjà attribuées aux autres guests et les contraintes de slots pour VIPRION. Les limites et le rapport mémoire/cœurs sont propres à la plateforme.

Selon le changement documenté, une transition vers un état permettant la modification peut arrêter le guest. Pour une paire HA, commencez par vérifier que le pair peut porter les traffic groups et la charge, puis préparez bascule, arrêt et reprise du guest concerné. Un host update peut affecter plusieurs guests simultanément.

Après reprise, vérifiez allocation côté host, ressources et version côté guest, VLANs, état DSC et service applicatif. Notez les versions host/guest compatibles avant le changement : une image installable n’est pas à elle seule une preuve de compatibilité ou de support.