Citrix - 2.4 IMA

IMA (Independent Management Architecture) est le framework historique qui a structuré les architectures XenApp pendant plus de dix ans. Sa raison d'être est de fournir un cadre de communication serveur à serveur permettant à tous les serveurs d'une ferme XenApp de coopérer : ils se reconnaissent, partagent leurs informations de session, d'application et de licence. IMA s'étend également via des sous-systèmes embarqués pour gérer la sécurité et la confidentialité au sein de la ferme.

Si un serveur XenApp accomplit une action, les autres serveurs en sont informés via IMA. La communication s'effectue par messages échangés sur le port TCP 2512. Ce schéma a longtemps suffi, mais il porte une contrainte forte : tous les serveurs d'une ferme sont à la fois workers (ils servent les sessions utilisateurs) et controllers (ils participent au pilotage de la ferme). L'un d'eux est élu collecteur de données et détient un peu plus d'informations que les autres.

Limites d'IMA

• Toute mise à niveau majeure (par exemple XenApp 5 vers 6) impose de migrer la structure entière, car tous les serveurs partagent le même framework
• Pas de séparation native entre rôles : difficile de dédier un serveur uniquement au contrôle sans accepter de sessions
• Coexistence laborieuse de plusieurs versions IMA dans une même ferme
• Scalabilité limitée sur les très grands déploiements

Ce sont ces limites qui ont conduit Citrix à abandonner IMA au profit de FMA (FlexCast Management Architecture) avec XenDesktop 7. FMA introduit une séparation claire entre les rôles (Delivery Controller, VDA) et une plus grande flexibilité pour l'évolution des infrastructures. La transition d'IMA vers FMA constitue le saut architectural majeur entre XenApp 6.5 et XenDesktop 7.x.