{"id":547,"date":"2017-04-29T16:53:59","date_gmt":"2017-04-29T14:53:59","guid":{"rendered":"http:\/\/www.gatoux.com\/?page_id=547"},"modified":"2017-04-29T17:20:36","modified_gmt":"2017-04-29T15:20:36","slug":"principe-de-mutualisation","status":"publish","type":"page","link":"https:\/\/racine.gatoux.com\/lmdr\/index.php\/principe-de-mutualisation\/","title":{"rendered":"Principe de mutualisation"},"content":{"rendered":"

Je ne vous ferai pas l’affront de vous proposer une d\u00e9finition du \u00ab\u00a0partage\u00a0\u00bb ! Je sais que vos convictions chr\u00e9tiennes font de vous des experts dans le domaine. Ceci dit, aucun de vous n’a encore partag\u00e9 sa fortune avec moi ! Mais c’est vrai ! Il y a une diff\u00e9rence entre \u00ab\u00a0partage\u00a0\u00bb et \u00ab\u00a0obole\u00a0\u00bb !<\/em><\/p>\n

En mati\u00e8re de r\u00e9seaux de donn\u00e9es la notion de partage est simple : Il s’agit d’optimiser l’utilisation des ressources<\/strong> en les r\u00e9partissant entre diff\u00e9rents utilisateurs.<\/p>\n

L’optimisation \u00e9voqu\u00e9e ici s’entend sous au moins deux aspects : le crit\u00e8re technique<\/strong>, le crit\u00e8re \u00e9conomique<\/strong>. On parle alors de rendement<\/strong> (ou pertinence) technico-\u00e9conomique (quelle science j’ai, n’est ce pas ?<\/em>).<\/p>\n

Mais comment d\u00e9finir la limite entre un r\u00e9seau d\u00e9di\u00e9 et un r\u00e9seau partag\u00e9 ?<\/p>\n

Encore ici, comme dans le cours \u00ab\u00a0Mod\u00e8le OSI<\/strong>\u00ab\u00a0, je ferai appel \u00e0 la citation d’un de mes anciens coll\u00e8gues (aujourd’hui install\u00e9 dans le Sud ! Sale tra\u00eetre !<\/em>) :<\/p>\n

Tout d\u00e9pend de l’endroit o\u00f9 on se place et de l’id\u00e9e qu’on s’en fait !<\/span><\/h6>\n

La topologie \u00ab\u00a0Point \u00e0 point\u00a0\u00bb …<\/h2>\n

\"\"Sur le sch\u00e9ma ci-contre, un lien unique interconnecte deux routeurs. Ce lien permet de relier deux sites d’une m\u00eame entreprise. Sur le site A des ressources applicatives sont livr\u00e9es, par les serveurs, aux utilisateurs du site B.<\/p>\n

Les deux routeurs et le lien d’interconnexion v\u00e9hiculent donc des donn\u00e9es pour l’ensemble des utilisateurs du site B. Du point de vue des utilisateurs, ils se partagent ses ressources. Le lien est mutualis\u00e9. Par contre du point de vue du site A, ce lien et ses routeurs sont d\u00e9di\u00e9s \u00e0 l’acc\u00e8s au site B (et inversement pour le site B). Donc du point de vue des sites, le lien est d\u00e9di\u00e9. Du point de vue de l’entreprise \u00e9galement, ce lien est d\u00e9di\u00e9 \u00e0 l’interconnexion des deux sites.<\/p>\n

La seule pr\u00e9occupation ici est de veiller \u00e0 la charge du lien en regard de l’augmentation des besoins des utilisateurs du site B. Si la charge augmente, il suffit d’augmenter le d\u00e9bit de ce seul lien (et \u00e9ventuellement upgrader les routeurs \u00e9galement). Par contre dans cette logique, si 100 sites doivent acc\u00e9der au site A pour b\u00e9n\u00e9ficier des services applicatifs fournis par les serveurs, il faudra pr\u00e9voir 100 liaisons d\u00e9di\u00e9es et autant d’interfaces sur le routeur du site A, ou multiplier les routeurs (ce qui pose des probl\u00e8mes de routage ensuite !!<\/em>). \u00c9conomiquement et techniquement parlant, est-ce rentable (r\u00e9ponse dans le prochain chapitre !<\/em>) ?<\/p>\n

La topologie \u00ab\u00a0Hi\u00e9rarchique\u00a0\u00bb …<\/h2>\n

\"\"Sur le sch\u00e9ma ci-contre nous mettons en place un point de concentration entre les sites B et C et le site A par le site D. Il appara\u00eet clairement que les liens D-C et D-B sont toujours consid\u00e9r\u00e9s comme partag\u00e9s par les utilisateurs des sites B et C, mais vus comme d\u00e9di\u00e9s aux sites B et C du point de vue de l’entreprise.<\/p>\n

Par contre le lien A-D est vu par les utilisateurs, les sites et l’entreprise comme un lien mutualis\u00e9 pour les sites B et C. Ces deux sites se partagent la bande passante du lien pour acc\u00e9der aux ressources fournies par A. Mais ce lien reste d\u00e9di\u00e9 \u00e0 l’entreprise. On peut ici observer six points :<\/p>\n

    \n
  • Cette topologie pr\u00e9sente un point de fragilit\u00e9<\/strong> : si le routeur D ou le lien A-D sont HS, deux sites (B et C) sont hors services, contre un seul pr\u00e9c\u00e9demment !<\/li>\n
  • L’\u00e9volutivit\u00e9 est plus complexe \u00e0 g\u00e9rer<\/strong> : si les besoins du site B augmentent et pas ceux de C, il est n\u00e9cessaire de monter en d\u00e9bit sur le lien D-B, mais \u00e9galement sur le lien A-D ! C’est une double intervention.<\/li>\n
  • Si l’entreprise ferme le site B<\/strong>, le lien A-D ne sert plus qu’\u00e0 v\u00e9hiculer les donn\u00e9es de C vers A (plus \u00e9ventuellement celles de D vers A). La concentration par D est-elle encore \u00e9conomiquement rentable ? Un lien direct entre A et C serait peut-\u00eatre pr\u00e9f\u00e9rable.<\/li>\n
  • Le cas horrible o\u00f9 le site D d\u00e9m\u00e9nage ou ferme<\/strong> ! Il faut d\u00e9placer ou supprimer trois liaisons (A-D, D-B, D-C).<\/li>\n
  • Cette topologie permet d’optimiser l’utilisation du lien A-D<\/strong>, son d\u00e9bit n’est pas forc\u00e9ment \u00e9gal \u00e0 la somme des d\u00e9bits des liens D-B et D-C. On peut appliquer un principe d’utilisation statistique en supposant que les site B et C ne transmettent pas forc\u00e9ment toujours en m\u00eame temps !<\/li>\n
  • On peut raccourcir les distances<\/strong> et donc, souvent, le co\u00fbt des liaisons. Une LL (Liaison Lou\u00e9e) \u00e0 128K pour D-C et une autre \u00e0 64K pour D-B plus une liaison \u00e0 128K pour A-D peuvent suffirent et \u00eatre moins on\u00e9reuses que 2 LL \u00e0 128K directes B-A, C-A !<\/li>\n<\/ul>\n

    On en conclut ais\u00e9ment que la structure hi\u00e9rarchique peut pr\u00e9senter des avantages en termes financiers mais n’est pas forc\u00e9ment la panac\u00e9e en terme d’\u00e9volution et de garantie de disponibilit\u00e9 globale du r\u00e9seau !<\/p>\n

    La topologie \u00ab\u00a0Backbone\u00a0\u00bb …<\/h2>\n

    \"\"Sur le sch\u00e9ma ci-contre on mets en place un r\u00e9seau central maill\u00e9, sur lequel des sites viennent se connecter. Le \u00ab\u00a0backbone<\/strong>\u00a0\u00bb central peut disposer d’un point d’acc\u00e8s par r\u00e9gion qui va concentrer les sites de la r\u00e9gion. Le point d’acc\u00e8s est souvent appel\u00e9 PoP<\/strong> pour P<\/strong>oint O<\/strong>f P<\/strong>resence.<\/p>\n

    Dans le backbone constitu\u00e9 par l’interconnexion des routeurs R3 \u00e0 R6 on peut mettre en place une politique de routage dynamique intelligente qui serait capable :<\/p>\n

      \n
    • de prendre en compte tout nouveau site<\/strong> qui se connecterai \u00e0 un PoP<\/li>\n
    • d’assurer un re-routage<\/strong> en cas d’indisponibilit\u00e9 d’un des liens d’interconnexion<\/li>\n
    • d’activer un mode de partage de charge<\/strong> entre les diff\u00e9rentes routes possibles afin d’optimiser l’utilisation des liens (nous reviendrons sur le partage de charge dans un autre cours ! On peut pas tout voir ici !!).<\/li>\n<\/ul>\n

      Il est \u00e9vident ici que le backbone<\/strong> (liens et routeurs) est partag\u00e9 entre tous les sites connect\u00e9s aux diff\u00e9rents PoP<\/strong>. Les sites distants et leurs routeurs forment le \u00ab\u00a0r\u00e9seau capillaire<\/strong>\u00ab\u00a0. Le backbone est la topologie de r\u00e9seaux mutualis\u00e9 de r\u00e9f\u00e9rence !<\/p>\n

      Nous noterons qu’ici nous avons raccord\u00e9 le site A, consid\u00e9r\u00e9 comme site central, sur deux PoP avec donc deux liaisons et deux routeurs sur le site ! Ceci permet de garantir une meilleure disponibilit\u00e9 d’acc\u00e8s au site. En effet, si nous l’avions raccord\u00e9 uniquement \u00e0 R3, plus aucun site n’acc\u00e8derai aux ressources du site A en cas d’indisponibilit\u00e9 de R3, R1 ou du lien R1-R3. Par contre ceci suppose que le backbone est en mesure d’op\u00e9rer un re-routage<\/strong> vers le dernier acc\u00e8s valide !<\/p>\n

      Cette topologie peut para\u00eetre optimum, mais :<\/p>\n

        \n
      • les points d’acc\u00e8s sont des points de fragilit\u00e9 du r\u00e9seau<\/strong>, si l’un d’eux est HS (Hors Service), un nombre de sites plus ou moins important peut \u00eatre compl\u00e9tement isol\u00e9.<\/li>\n
      • le dimensionnement des liens et routeurs du backbone est une op\u00e9ration assez d\u00e9licate<\/strong> si l’on veut assurer un potentiel d’\u00e9volutivit\u00e9 \u00e0 ce r\u00e9seau sans devoir sans cesse reprendre le dimensionnement en fonction de l’ajo\u00fbt ou le retrait de sites. Il faut qu’il puisse accueillir de nouveaux sites mais il ne faut pas non plus qu’il soit surdimensionn\u00e9 car cela \u00e0 un co\u00fbt !<\/li>\n
      • la politique de routage au sein du backbone peut \u00eatre assez complexe<\/strong> \u00e0 mettre en \u0153uvre et \u00e0 maintenir.<\/li>\n<\/ul>\n

        Par contre les avantages sont importants :<\/p>\n