{"id":38966,"date":"2019-10-31T22:27:03","date_gmt":"2019-10-31T19:27:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/admin-bez-ruk-giperkonvergentsiya\/"},"modified":"2019-10-31T22:27:03","modified_gmt":"2019-10-31T19:27:03","slug":"admin-bez-ruk-giperkonvergentsiya","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/admin-bez-ruk-giperkonvergentsiya","title":{"rendered":"Administrateur sans mains = hyper-convergence ?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Administrateur
\n\"Administrateur
\n
\nC'est un mythe assez r\u00e9pandu dans le domaine du mat\u00e9riel serveur. En pratique, les solutions hyperconverg\u00e9es (tout-en-un) sont n\u00e9cessaires pour de nombreuses raisons. Historiquement, les premi\u00e8res architectures ont \u00e9t\u00e9 d\u00e9velopp\u00e9es par Amazon et Google pour leurs services. L'id\u00e9e \u00e9tait de cr\u00e9er un parc informatique compos\u00e9 de n\u0153uds identiques, chacun ayant ses propres disques. Le tout \u00e9tait reli\u00e9 par un logiciel de syst\u00e8me (hyperviseur) et divis\u00e9 en machines virtuelles. L'objectif principal \u00e9tait de minimiser les efforts de maintenance d'un n\u0153ud et le minimum de probl\u00e8mes lors de l'\u00e9volutivit\u00e9 : il suffisait d'ajouter quelques milliers de serveurs de ce type et de les connecter c\u00f4te \u00e0 c\u00f4te. En pratique, ce sont des cas isol\u00e9s, et la plupart du temps, il s'agit de moins de n\u0153uds et d'une architecture l\u00e9g\u00e8rement diff\u00e9rente. <\/p>\n

Mais l'avantage reste le m\u00eame : une simplicit\u00e9 extraordinaire \u00e0 l'\u00e9chelle et \u00e0 la gestion. Le inconv\u00e9nient est que diff\u00e9rentes t\u00e2ches consomment les ressources de mani\u00e8re vari\u00e9e, donc il y aura beaucoup de disques locaux par endroits, et ailleurs peu de RAM, etc. Cela signifie qu'avec diff\u00e9rents types de t\u00e2ches, l'utilisation des ressources sera diminu\u00e9e. <\/p>\n

Il en r\u00e9sulte que vous payez 10 \u00e0 15 % de plus pour la facilit\u00e9 de configuration. Ceci a donn\u00e9 naissance au mythe mentionn\u00e9 dans le titre. Nous avons longtemps cherch\u00e9 o\u00f9 la technologie pouvait \u00eatre utilis\u00e9e de mani\u00e8re optimale et nous avons trouv\u00e9. En effet, Cisco n'avait pas ses propres syst\u00e8mes de stockage, mais ils voulaient conqu\u00e9rir le march\u00e9 des serveurs. Ils ont donc cr\u00e9\u00e9 Cisco Hyperflex \u2014 une solution avec des stockages locaux sur les n\u0153uds. <\/p>\n

Et cela a soudainement donn\u00e9 un tr\u00e8s bon r\u00e9sultat pour les centres de donn\u00e9es de secours (Disaster Recovery). Pourquoi et comment \u2014 je vais vous expliquer maintenant. Et je montrerai des tests de cluster. <\/a><\/noindex><\/p>\n

L\u00e0 o\u00f9 c'est n\u00e9cessaire<\/h3>\n

\nL'hyperconvergence, c'est : <\/p>\n

    \n
  1. Le transfert de disques dans les n\u0153uds de calcul.<\/li>\n
  2. Une int\u00e9gration compl\u00e8te du sous-syst\u00e8me de stockage avec le sous-syst\u00e8me de virtualisation.<\/li>\n
  3. Le transfert\/int\u00e9gration avec le sous-syst\u00e8me r\u00e9seau.<\/li>\n<\/ol>\n

    \nCette combinaison permet de r\u00e9aliser de nombreuses fonctionnalit\u00e9s du stockage au niveau de la virtualisation, le tout depuis une seule interface de gestion.<\/p>\n

    Notre entreprise a une forte demande pour des projets de conception de centres de donn\u00e9es de secours, et il est souvent choisi pr\u00e9cis\u00e9ment des solutions hyperconverg\u00e9es en raison de nombreux choix de r\u00e9plication (jusqu'au m\u00e9tro-cluster) disponibles d\u00e8s la sortie de la bo\u00eete. <\/p>\n

    Dans le cas des centres de donn\u00e9es secondaires, il s'agit g\u00e9n\u00e9ralement d'un site \u00e9loign\u00e9 situ\u00e9 \u00e0 l'autre bout de la ville ou m\u00eame dans une autre ville. Cela permet de restaurer les syst\u00e8mes critiques en cas de d\u00e9faillance partielle ou totale du centre de donn\u00e9es principal. Les donn\u00e9es du serveur sont constamment r\u00e9pliqu\u00e9es, et cette r\u00e9plication peut se faire au niveau de l'application ou au niveau de l'appareil de stockage (SAN).<\/p>\n

    Je vais donc vous parler de la structure du syst\u00e8me et des tests, puis de quelques sc\u00e9narios d'application r\u00e9elle avec des donn\u00e9es sur les \u00e9conomies r\u00e9alis\u00e9es. <\/p>\n

    Tests<\/h3>\n

    \nNotre configuration est compos\u00e9e de quatre serveurs, chacun \u00e9quip\u00e9 de 10 disques SSD de 960 Go. Il y a un disque d\u00e9di\u00e9 pour la mise en cache des op\u00e9rations d'\u00e9criture et pour le stockage d'une machine virtuelle de service. La solution elle-m\u00eame est la quatri\u00e8me version. La premi\u00e8re \u00e9tait franchement instable (d'apr\u00e8s les retours), la deuxi\u00e8me avait encore des d\u00e9fauts, la troisi\u00e8me \u00e9tait d\u00e9j\u00e0 assez stable, et celle-ci peut \u00eatre consid\u00e9r\u00e9e comme une version finale apr\u00e8s avoir termin\u00e9 les tests b\u00eata aupr\u00e8s du grand public. Pendant la phase de test, je n'ai rencontr\u00e9 aucun probl\u00e8me, tout fonctionne parfaitement.<\/p>\n

    Modifications dans v4<\/b>Un grand nombre de bogues ont \u00e9t\u00e9 corrig\u00e9s. <\/p>\n

    Au d\u00e9part, la plateforme ne pouvait fonctionner qu'avec l'hyperviseur VMware ESXi et ne supportait qu'un nombre limit\u00e9 de n\u0153uds. De plus, le processus de d\u00e9ploiement ne se terminait pas toujours avec succ\u00e8s, n\u00e9cessitant le red\u00e9marrage de certaines \u00e9tapes, il y avait des probl\u00e8mes de mise \u00e0 jour depuis d'anciennes versions, et les donn\u00e9es dans l'interface graphique n'\u00e9taient pas toujours affich\u00e9es correctement (bien que je ne sois pas encore ravi de l'affichage des graphiques de performance), et parfois des probl\u00e8mes survenaient au niveau de la virtualisation.<\/p>\n

    Maintenant, tous les probl\u00e8mes initiaux ont \u00e9t\u00e9 corrig\u00e9s, HyperFlex prend en charge \u00e0 la fois ESXi et Hyper-V, et en plus de cela, il est possible de :<\/p>\n

      \n
    1. Cr\u00e9er un cluster \u00e9tendu. <\/li>\n
    2. Cr\u00e9er un cluster pour des bureaux sans utiliser de Fabric Interconnect, de deux \u00e0 quatre n\u0153uds (nous achetons uniquement les serveurs).<\/li>\n
    3. Possibilit\u00e9 de travailler avec des SAN externes.<\/li>\n
    4. Support des conteneurs et de Kubernetes.<\/li>\n
    5. Cr\u00e9er des zones de disponibilit\u00e9.<\/li>\n
    6. Int\u00e9gration avec VMware SRM, si la fonctionnalit\u00e9 int\u00e9gr\u00e9e ne convient pas.<\/li>\n<\/ol>\n

      L'architecture ne diff\u00e8re pas beaucoup de celle des principaux concurrents, pas besoin de r\u00e9inventer la roue. Tout cela fonctionne sur une plateforme de virtualisation VMware ou Hyper-V. Au niveau mat\u00e9riel, cela s'implante sur des serveurs d\u00e9velopp\u00e9s en interne par Cisco UCS. Certaines personnes d\u00e9testent la plateforme en raison de la relative complexit\u00e9 de sa configuration initiale, de ses nombreux boutons, de son syst\u00e8me de mod\u00e8les et de d\u00e9pendances non trivial, mais d'autres ont compris l'essence de l'id\u00e9e et ne souhaitent plus travailler avec d'autres serveurs. <\/p>\n

      Nous allons examiner la solution pour VMware, car elle a \u00e9t\u00e9 initialement con\u00e7ue pour cela et offre plus de fonctionnalit\u00e9s, tandis que Hyper-V a \u00e9t\u00e9 am\u00e9lior\u00e9 au fil du temps pour ne pas \u00e9chapper \u00e0 la concurrence et r\u00e9pondre aux attentes du march\u00e9.<\/p>\n

      Il y a un cluster de serveurs \u00e9quip\u00e9s de disques. Il y a des disques pour le stockage des donn\u00e9es (SSD ou HDD selon vos besoins), ainsi qu'un SSD pour le caching. Lors de l'\u00e9criture des donn\u00e9es sur le datastore, celles-ci sont d'abord sauvegard\u00e9es sur la couche de cache (disque SSD d\u00e9di\u00e9 et RAM de la VM de service). Parall\u00e8lement, le bloc de donn\u00e9es est envoy\u00e9 sur les n\u0153uds du cluster (le nombre de n\u0153uds d\u00e9pend du facteur de r\u00e9plication du cluster). Apr\u00e8s confirmation de l'\u00e9criture r\u00e9ussie par tous les n\u0153uds, la confirmation est envoy\u00e9e \u00e0 l'hyperviseur, puis \u00e0 la VM. Les donn\u00e9es \u00e9crites sont ensuite d\u00e9dupliqu\u00e9es, compress\u00e9es et sauvegard\u00e9es sur les disques de stockage en arri\u00e8re-plan. De plus, des blocs importants sont toujours \u00e9crits s\u00e9quentiellement sur les disques de stockage, ce qui r\u00e9duit la charge sur ceux-ci.<\/p>\n

      La d\u00e9duplication et la compression sont activ\u00e9es en permanence et ne peuvent pas \u00eatre d\u00e9sactiv\u00e9es. La lecture des donn\u00e9es se fait directement \u00e0 partir des disques de stockage ou du cache RAM. Si une configuration hybride est utilis\u00e9e, la lecture est \u00e9galement mise en cache sur le disque SSD.<\/p>\n

      Les donn\u00e9es ne sont pas li\u00e9es \u00e0 l'emplacement actuel de la machine virtuelle et sont r\u00e9parties uniform\u00e9ment entre les n\u0153uds. Cette approche permet de charger de mani\u00e8re \u00e9gale tous les disques et interfaces r\u00e9seau. Il y a un inconv\u00e9nient \u00e9vident : nous ne pouvons pas minimiser au maximum la latence de lecture, car il n'y a aucune garantie que les donn\u00e9es sont localement disponibles. Mais je pense que c'est un sacrifice insignifiant compar\u00e9 aux avantages obtenus. De plus, les latences r\u00e9seau ont atteint de tels niveaux qu'elles n'affectent pratiquement plus le r\u00e9sultat global.<\/p>\n

      La logique de fonctionnement de la sous-syst\u00e8me de stockage est g\u00e9r\u00e9e par une machine virtuelle de service sp\u00e9ciale, le contr\u00f4leur Cisco HyperFlex Data Platform, qui est cr\u00e9\u00e9e sur chaque n\u0153ud de stockage. Dans notre configuration, cette VM de service dispose de huit vCPU et de 72 Go de RAM, ce qui n'est pas n\u00e9gligeable. Je rappelle que l'h\u00f4te poss\u00e8de 28 c\u0153urs physiques et 512 Go de RAM.<\/p>\n

      La VM de service a acc\u00e8s aux disques physiques directement via le passage du contr\u00f4leur SAS dans la VM. Les communications avec l'hyperviseur se font par le biais d'un module sp\u00e9cial IOVisor qui intercepte les op\u00e9rations d'entr\u00e9e\/sortie, ainsi qu'\u00e0 l'aide d'un agent qui permet de transmettre des commandes \u00e0 l'API de l'hyperviseur. L'agent s'occupe de la gestion des snapshots et des clones HyperFlex.<\/p>\n

      Dans l'hyperviseur, les ressources de stockage sont mont\u00e9es en tant que partages NFS ou SMB (selon le type d'hyperviseur, devinez o\u00f9 se trouve quoi). En coulisses, il s'agit d'un syst\u00e8me de fichiers distribu\u00e9 capable d'ajouter des fonctionnalit\u00e9s typiques des syst\u00e8mes de stockage avanc\u00e9s : allocation fine des volumes, compression et d\u00e9-duplication, snapshots par technologie Redirect-on-Write, r\u00e9plication synchrone\/asynchrone.<\/p>\n

      La VM de service fournit un acc\u00e8s \u00e0 l'interface web de gestion du sous-syst\u00e8me HyperFlex. Il existe une int\u00e9gration avec vCenter, et la plupart des t\u00e2ches quotidiennes peuvent \u00eatre effectu\u00e9es depuis celui-ci, mais il est plus pratique de d\u00e9couper les datastores \u00e0 partir d'une interface web s\u00e9par\u00e9e, si vous \u00eates d\u00e9j\u00e0 pass\u00e9 \u00e0 l'interface HTML5 rapide, ou d'utiliser un client Flash complet avec int\u00e9gration totale. Dans l'interface web de service, vous pouvez consulter les performances et le statut d\u00e9taill\u00e9 du syst\u00e8me.<\/p>\n

      \"Administrateur
      \n
      \nIl existe un autre type de n\u0153ud dans le cluster \u2014 les n\u0153uds de calcul. Ce peuvent \u00eatre des serveurs en rack ou des serveurs blade sans disques int\u00e9gr\u00e9s. Sur ces serveurs, vous pouvez faire fonctionner des VM dont les donn\u00e9es sont stock\u00e9es sur des serveurs avec disques. Du point de vue de l'acc\u00e8s aux donn\u00e9es, il n'y a pas de diff\u00e9rence entre les types de n\u0153uds, car l'architecture suppose une abstraction de la localisation physique des donn\u00e9es. Le ratio maximum de n\u0153uds de calcul \u00e0 n\u0153uds de stockage est de 2:1.<\/p>\n

      L'utilisation de n\u0153uds de calcul augmente la flexibilit\u00e9 lors de l'\u00e9volutivit\u00e9 des ressources du cluster : nous n'avons pas besoin d'acheter des n\u0153uds avec disques si nous avons uniquement besoin de CPU\/RAM. De plus, nous pouvons ajouter un ch\u00e2ssis blade et r\u00e9aliser des \u00e9conomies sur la mise en rack des serveurs.<\/p>\n

      En r\u00e9sum\u00e9, nous avons une plateforme hyper-convergente avec les fonctionnalit\u00e9s suivantes :<\/p>\n