Tu tires ou tu pousses ?

28 janvier 2007

Le Device Management est l’art de gérer les terminaux, qui peuvent être des PC, des téléphones, des décodeurs télé, en fait n’importe quel équipement connecté à un réseau. Gérer ça veut dire pouvoir faire à distance tout ce que l’on pourrait faire en étant sur place : mettre à jour les logiciels, corriger un mauvais paramétrage, rentrer un code pour accéder à un nouveau service, etc. Mais gérer c’est aussi gérer le nombre, à la manière d’un épicier qui ferait l’inventaire de son magasin : combien de boîtes de haricots, leur date limite, comment on y accède, etc. Pour une Livebox ce sera plutôt son numéro de série, la date de sa premère connexion, ou son IP.

Les applications sont nombreuses : permettre à un expert d’intervenir à distance et d’économiser le temps de déplacement, automatiser à grande échelle des actions répétitives, tout ça pour qu’au final l’utilisateur du terminal ait l’impression que ça marche « tout seul ».

On l’imagine, les facettes de ce domaine sont aussi nombreuses que passionnantes : éthiques, techniques, organisationnelles, ergonomiques. Aujourd’hui nous parlerons d’une question technique fondamentale : mode pull ou mode push ?

Avec la généralisation des protocoles en mode connecté comme HTTP, le terminal et le serveur échangent des informations au cours d’un dialogue entamé par l’un des deux. Lorsque c’est le terminal qui a appelé le serveur on parle de mode Pull (tirer) ; si c’est le serveur qui a réveillé le terminal c’est du Push (pousser).

Push et Pull sont souvent perçus par les décideurs informatiques comme deux antagonismes présentant chacun des avantages et des inconvénients finalement mal connus. Ce que j’ai observé, c’est que ceux qui font du Push lorgnent sur le Pull, et ceux qui font du Pull bavent sur le Push. Alors lequel choisir ?

Pull

En mode Pull le terminal est une amoureuse impatiente qui va tous les jours demander à la poste s’il y a du courrier pour elle : le terminal connaît l’adresse du serveur et va régulièrement lui demander s’il a quelquechose pour lui. Le cas échéant, le serveur lui renvoie un paramétrage à appliquer, un nouveau logiciel à installer, oui lui demande de lui décrire sa configuration.

classe.jpg

Avantages Inconvénients
  • ne nécessite pas de connaître le terminal au préalable : autoprovisioning
  • fonctionne même s’il y a plusieurs terminaux derrière la même IP (NAT)
  • peut être lié à des événements côté terminal pour moins perturber l’utilisateur : mise en veille, etc.
  • les reprises sur échec (coupure d’un téléchargement par exemple) sont automatiques
  • le lissage de charge se fait tout seul : si l’on dit aux terminaux de venir tous les 5 jours, on en traitera ~20% chaque jour
  • sécurité : le terminal appelant une adresse non modifiable, il est très difficile de prendre la place du serveur, ou d’intercepter les messages envoyés à un autre terminal
  • peu réactif : il faut attendre que le terminal vienne
  • peu scalable : pour obtenir une réactivité correcte il faut des requêtes très fréquentes, ce qui charge le serveur

C’est comme ça que fonctionne le système de mise à jour de tous vos logiciels habituels : Firefox, Windows Update, McAfee, etc. Le principal avantage est de pouvoir décrire les campagnes de déploiement avec des règles génériques (ceux qui sont en version A reçoivent la version B, etc.) et de laisser les choses se faire d’elles-mêmes.

Push

En mode Push le postier connaît l’adresse d’Aglaé et court lui porter les messages dès qu’ils arrivent : c’est même plutôt un coursier qui fera le voyage trois fois dans la journée s’il y a trois messages.

fedex.jpg

Avantages Inconvénients
  • très réactif : l’action à effectuer est transmise immédiatement
  • permet même une interactivité entre un expert et le terminal
  • scalable : s’il y a en moyenne pour chaque terminal une action toutes les 3 semaines, pas la peine d’être dimensionné pour traiter une requête toutes les 2 heures
  • on ne peut agir que sur les terminaux que l’on connaît déjà : provisioning nécessaire, souvent en mode Pull
  • un network mapping (association entre l’identifiant du terminal et son adresse réseau) fiable est nécessaire, avec une synchronisation à chaque changement d’IP par exemple ; il faut cependant être conscient qu’il ne sera jamais fiable à 100%
  • il faut que le terminal soit joignable, et gérer la reprise en cas d’échec
  • nécessite une participation de la passerelle s’il y a plusieurs terminaux derrière la même IP
  • sécurité : il faut une authentification forte du terminal pour éviter de lui envoyer les données confidentielles destinées à un autre, et du serveur pour éviter de prendre des ordres de n’importe qui

C’est comme ça que fonctionnent les systèmes en mode non connecté (SNMP), et surtout la plupart des progiciels de Device Management : IBM Tivoli, Microsoft SMS, etc. Le principal avantage est de permettre des actions en direct. L’inconvénient est que la gestion des campagnes massives nécessite beaucoup de ressources.

And the winner is…

Alors que choisir ? Je ne tournerai pas autour du pot : commencez par le Pull ! En effet le Pull n’est pas une option : c’est la seule solution réaliste pour établir le network mapping fiable nécessaire au Push. De plus lorsqu’en Push un terminal n’est pas joignable, il faut bien qu’il s’annonce lorsqu’il revient, et que l’on soit capable de traiter cette requête Pull. Si vous faites du Device Management, vous avez besoin du Pull.

La nécessité du Push va ensuite dépendre de ce que vous voulez faire.

S’il s’agit de gérer des campagnes massives d’audit, de mise à jour, de reconfiguration etc. où vous pouvez décrire votre campagne avec des règles génériques et vous permettre d’attendre une journée pour connaître le résultat (ne serait-ce que parce que les capacités de votre réseau ne vous permettraient pas, même en Push, de tout faire en moins de temps), alors restez en Pull : je me suis occupé d’une infrastructure où pour gérer les campagnes en Push sur 100.000 terminaux il fallait 30 personnes. J’ai aussi mis en place des campagnes en Pull sur 4 millions de terminaux, avec 3 personnes.

En revanche sur des actions unitaires le Push ouvre de nouvelles voies : activation de service immédiate, interactivité entre un expert et le terminal dans un processus de diagnostic/réparation, etc.

Il n’y a donc pas de dichotomie entre Push et Pull : les deux sont complémentaires, et la meilleure illustration en est le fonctionnement du TR-069. Il s’agit d’un protocole standard défini par le DSL Forum et en cours d’adoption par l’ensemble du monde des télécoms : dans ce protocole, le Push consiste simplement à demander au terminal de faire une requête Pull. Mais nous en reparlerons…

En lire plus sur : telcos