{"id":92570,"date":"2020-08-28T19:42:21","date_gmt":"2020-08-28T17:42:21","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker"},"modified":"2020-08-28T19:42:21","modified_gmt":"2020-08-28T17:42:21","slug":"modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/modelirovanie-otkazoustojchivyh-klasterov-na-baze-postgresql-i-pacemaker","title":{"rendered":"Mod\u00e9lisation de clusters tol\u00e9rants aux pannes bas\u00e9s sur PostgreSQL et Pacemaker","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Introduction<\/h1>\n

<\/p>\n

Il y a quelque temps, on m'a confi\u00e9 la t\u00e2che de d\u00e9velopper un cluster tol\u00e9rant aux pannes pour PostgreSQL<\/a><\/noindex>, fonctionnant dans plusieurs centres de donn\u00e9es, interconnect\u00e9s par fibre optique dans une m\u00eame ville, et capable de r\u00e9sister \u00e0 la d\u00e9faillance (par exemple, une coupure de courant) d'un centre de donn\u00e9es. Pour le logiciel responsable de la tol\u00e9rance aux pannes, j'ai choisi Pacemaker<\/a><\/noindex>, car c'est la solution officielle de RedHat pour cr\u00e9er des clusters tol\u00e9rants aux pannes. Elle est appr\u00e9ci\u00e9e car RedHat en assure le support, et c'est une solution universelle (modulaire). Gr\u00e2ce \u00e0 elle, il sera possible d'assurer la tol\u00e9rance aux pannes non seulement pour PostgreSQL, mais aussi pour d'autres services, que ce soit en utilisant des modules standards ou en les cr\u00e9ant pour des besoins sp\u00e9cifiques.<\/p>\n

<\/p>\n

\u00c0 cette solution, une question l\u00e9gitime s'est pos\u00e9e : dans quelle mesure un cluster tol\u00e9rant aux pannes sera-t-il r\u00e9ellement tol\u00e9rant aux pannes ? Pour le d\u00e9couvrir, j'ai d\u00e9velopp\u00e9 un banc d'essai qui simule diverses pannes sur les n\u0153uds du cluster, attend la reprise du fonctionnement, restaure le n\u0153ud d\u00e9faillant et continue le test en boucle. Au d\u00e9part, ce projet s'appelait hapgsql, mais avec le temps, je me suis lass\u00e9 d'un nom comportant si peu de voyelles. J'ai donc commenc\u00e9 \u00e0 nommer les bases de donn\u00e9es tol\u00e9rantes aux pannes (et l'IP flottante qui les d\u00e9signe) krogan<\/strong> (un personnage d'un jeu vid\u00e9o qui a tous ses organes vitaux doubl\u00e9s), tandis que les n\u0153uds, les clusters et le projet lui-m\u00eame s'appellent tuchanka<\/strong> (la plan\u00e8te habit\u00e9e par les krogan).<\/p>\n

<\/p>\n

Actuellement, la direction a autoris\u00e9 \u00e0 ouvrir le projet \u00e0 la communaut\u00e9 open source sous licence MIT<\/a><\/noindex>. Le README sera bient\u00f4t traduit en anglais (car les principaux utilisateurs devraient \u00eatre les d\u00e9veloppeurs de Pacemaker et PostgreSQL), et j'ai d\u00e9cid\u00e9 de pr\u00e9senter la vieille version russe du README (en partie) sous la forme de cet article.<\/p>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/a><\/noindex><\/p>\n

Les clusters sont d\u00e9ploy\u00e9s sur des machines virtuelles VirtualBox<\/a><\/noindex>. Au total, 12 machines virtuelles seront d\u00e9ploy\u00e9es (pour un total de 36GiB), qui formeront 4 clusters tol\u00e9rants aux pannes (diff\u00e9rentes options). Les deux premiers clusters sont compos\u00e9s de deux serveurs PostgreSQL, situ\u00e9s dans diff\u00e9rents centres de donn\u00e9es, et d'un serveur g\u00e9n\u00e9ral witness<\/em> c quorum device<\/strong> (situ\u00e9 sur une machine virtuelle bon march\u00e9 dans un troisi\u00e8me centre de donn\u00e9es), qui r\u00e9sout l'incertitude 50%\/50%<\/strong>, en donnant sa voix \u00e0 l'une des parties. Le troisi\u00e8me cluster se compose de trois centres de donn\u00e9es : un ma\u00eetre, deux esclaves, sans quorum device<\/strong>. Le quatri\u00e8me cluster se compose de quatre serveurs PostgreSQL, deux par centre de donn\u00e9es : un ma\u00eetre et les autres en tant que r\u00e9pliques, et utilise aussi witness<\/em> c quorum device<\/strong>. Le quatri\u00e8me supporte la d\u00e9faillance de deux serveurs ou d'un centre de donn\u00e9es. Cette solution peut \u00eatre, si n\u00e9cessaire, \u00e9tendue \u00e0 un plus grand nombre de r\u00e9pliques.<\/p>\n

<\/p>\n

Service de temps pr\u00e9cis ntpd<\/a><\/noindex> est \u00e9galement reconfigur\u00e9 pour la r\u00e9silience, mais utilise la m\u00e9thode du ntpd<\/code> (mode orphelin<\/em>). Le serveur principal witness<\/em> sert de serveur NTP central, distribuant son temps \u00e0 tous les clusters, synchronisant ainsi tous les serveurs entre eux. Si witness<\/em> tombe en panne ou se retrouve isol\u00e9, l'un des serveurs du cluster commencera alors \u00e0 distribuer son temps (au sein du cluster). Un cache aux proxy HTTP<\/strong> a \u00e9galement \u00e9t\u00e9 configur\u00e9 sur witness<\/em>, permettant aux autres machines virtuelles d'acc\u00e9der aux d\u00e9p\u00f4ts Yum. En r\u00e9alit\u00e9, des services tels que le temps pr\u00e9cis et le proxy seront probablement h\u00e9berg\u00e9s sur des serveurs d\u00e9di\u00e9s, et dans cette configuration, ils sont plac\u00e9s sur witness<\/em> uniquement pour \u00e9conomiser sur le nombre de machines virtuelles et l'espace.<\/p>\n

<\/p>\n

Versions<\/h1>\n

<\/p>\n

v0. Fonctionne avec CentOS 7 et PostgreSQL 11 sur VirtualBox 6.1.<\/p>\n

<\/p>\n

Structure des clusters<\/h1>\n

<\/p>\n

Tous les clusters sont destin\u00e9s \u00e0 \u00eatre h\u00e9berg\u00e9s dans plusieurs centres de donn\u00e9es, regroup\u00e9s dans un r\u00e9seau plat et doivent r\u00e9sister \u00e0 la d\u00e9faillance ou \u00e0 l'isolement d'un centre de donn\u00e9es. Par cons\u00e9quent, est impossible<\/strong> utiliser pour se prot\u00e9ger contre le split-brain<\/strong> la technologie standard Pacemaker, appel\u00e9e STONITH<\/em> (Shoot The Other Node In The Head) ou fencing<\/em>. Son principe : si les n\u0153uds dans le cluster commencent \u00e0 soup\u00e7onner qu'un n\u0153ud est d\u00e9fectueux, qu'il ne r\u00e9pond pas ou se comporte de mani\u00e8re incorrecte, ils le d\u00e9connectent de force via des dispositifs \u00ab externes \u00bb, par exemple, une carte de gestion IPMI ou un UPS. Mais cela ne fonctionnera que dans les cas o\u00f9, en cas de d\u00e9faillance unique d'un serveur, l'IPMI ou l'UPS continuent de fonctionner. Ici, une protection contre une d\u00e9faillance beaucoup plus catastrophique est pr\u00e9vue, lorsque tout le centre de donn\u00e9es tombe en panne (par exemple, manque d'alimentation). Et dans un tel cas, tous les dispositifs stonith<\/em>(IPMI, UPS, etc.) ne fonctionneront \u00e9galement pas.<\/p>\n

<\/p>\n

Au lieu de cela, le syst\u00e8me repose sur l'id\u00e9e de quorum. Tous les n\u0153uds ont une voix, et seuls ceux qui voient plus de la moiti\u00e9 de tous les n\u0153uds peuvent fonctionner. Ce nombre, \u00ab moiti\u00e9+1 \u00bb, s'appelle quorum<\/strong>. Si le quorum n'est pas atteint, le n\u0153ud d\u00e9cide qu'il est en isolation r\u00e9seau et doit d\u00e9sactiver ses ressources, c'est-\u00e0-dire que c'est une sorte de protection contre le split-brain<\/strong>. Si le logiciel responsable de ce comportement ne fonctionne pas, un watchdog, par exemple bas\u00e9 sur IPMI, doit intervenir.<\/p>\n

<\/p>\n

Si le nombre de n\u0153uds est pair (cluster dans deux centres de donn\u00e9es), une incertitude appel\u00e9e peut survenir 50%\/50%<\/strong> (fifty-fifty<\/em>), lorsque l'isolation r\u00e9seau divise le cluster exactement en deux. C'est pourquoi, pour un nombre pair de n\u0153uds, on ajoute quorum device<\/strong> \u2014 un d\u00e9mon peu exigeant qui peut \u00eatre ex\u00e9cut\u00e9 sur la machine virtuelle la moins ch\u00e8re dans le troisi\u00e8me centre de donn\u00e9es. Il donne sa voix \u00e0 l'un des segments (qu'il voit), et ainsi r\u00e9sout l'incertitude 50%\/50%. Le serveur sur lequel sera ex\u00e9cut\u00e9 le dispositif de quorum, je l'ai appel\u00e9 witness<\/em> (terminologie de repmgr, que j'ai aim\u00e9e).<\/p>\n

<\/p>\n

Les ressources peuvent \u00eatre transf\u00e9r\u00e9es d'un endroit \u00e0 un autre, par exemple, des serveurs d\u00e9fectueux aux serveurs fonctionnels, ou sur ordre des administrateurs syst\u00e8me. Pour que les clients sachent o\u00f9 se trouvent les ressources dont ils ont besoin (o\u00f9 se connecter ?), on utilise IP flottants<\/em> (IP flottant<\/strong>). Ce sont des IP que Pacemaker peut d\u00e9placer d'un n\u0153ud \u00e0 l'autre (tout est dans un r\u00e9seau plat). Chacun d'eux symbolise une ressource (service) et sera l\u00e0 o\u00f9 il faut se connecter pour acc\u00e9der \u00e0 ce service (dans notre cas, la BD).<\/p>\n

<\/p>\n

Tuchanka1 (sch\u00e9ma avec compression)<\/h2>\n

<\/p>\n

Structure<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

L'id\u00e9e \u00e9tait d'avoir de nombreuses petites bases de donn\u00e9es avec une faible charge, pour lesquelles il n'est pas rentable de maintenir un serveur esclave d\u00e9di\u00e9 en mode hot standby pour des transactions en lecture seule (aucune n\u00e9cessit\u00e9 de gaspiller des ressources de cette mani\u00e8re).<\/p>\n

<\/p>\n

Dans chaque centre de donn\u00e9es, il y a un serveur. Sur chaque serveur, il y a deux instances PostgreSQL (dans la terminologie PostgreSQL, elles sont appel\u00e9es clusters, mais pour \u00e9viter toute confusion, je vais les nommer instances (par analogie avec d'autres bases de donn\u00e9es), et je n'appellerai clusters que les clusters Pacemaker). Une instance fonctionne en mode ma\u00eetre, et c'est la seule qui fournit des services (seule elle re\u00e7oit l'IP flottante). La deuxi\u00e8me instance fonctionne comme esclave pour le deuxi\u00e8me centre de donn\u00e9es, et elle ne fournira des services que si son ma\u00eetre tombe en panne. \u00c9tant donn\u00e9 que la plus grande partie du temps, seul un des deux instances (le ma\u00eetre) fournira des services (traitera les requ\u00eates), toutes les ressources serveur sont optimis\u00e9es pour le ma\u00eetre (de la m\u00e9moire est allou\u00e9e pour le cache shared_buffers, etc.), mais de mani\u00e8re \u00e0 ce que la deuxi\u00e8me instance dispose \u00e9galement de suffisamment de ressources (m\u00eame si c'est pour un fonctionnement sous-optimis\u00e9 via le cache du syst\u00e8me de fichiers) en cas de d\u00e9faillance de l'un des centres de donn\u00e9es. L'esclave ne fournit pas de services (ne traite pas les requ\u00eates read only) lors du fonctionnement normal du cluster, afin qu'il n'y ait pas de conflit de ressources avec le ma\u00eetre sur la m\u00eame machine.<\/p>\n

<\/p>\n

Dans le cas de deux n\u0153uds, la tol\u00e9rance aux pannes n'est possible que par r\u00e9plication asynchrone, car en r\u00e9plication synchrone, la d\u00e9faillance de l'esclave entra\u00eenera l'arr\u00eat du ma\u00eetre.<\/p>\n

<\/p>\n

D\u00e9faillance du t\u00e9moin<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

D\u00e9faillance du t\u00e9moin (quorum device<\/em>) je ne consid\u00e9rerai que le cluster Tuchanka1, pour tous les autres, ce sera la m\u00eame histoire. En cas de d\u00e9faillance du t\u00e9moin dans la structure du cluster, rien ne changera, tout continuera \u00e0 fonctionner comme avant. Mais le quorum sera \u00e9gal \u00e0 2 sur 3, et donc toute d\u00e9faillance ult\u00e9rieure sera fatale pour le cluster. Il faudra de toute fa\u00e7on r\u00e9parer rapidement.<\/p>\n

<\/p>\n

D\u00e9faillance de Tuchanka1<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

D\u00e9faillance de l'un des centres de donn\u00e9es pour Tuchanka1. Dans ce cas witness<\/em> elle donne sa voix au deuxi\u00e8me n\u0153ud dans le deuxi\u00e8me centre de donn\u00e9es. L\u00e0, l'ancien esclave devient ma\u00eetre, de sorte que deux ma\u00eetres fonctionnent sur un serveur et que leurs deux IP flottantes pointent vers eux.<\/p>\n

<\/p>\n

Tuchanka2 (classique)<\/h2>\n

<\/p>\n

Structure<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

Sch\u00e9ma classique de deux n\u0153uds. Sur l'un fonctionne le ma\u00eetre, sur l'autre l'esclave. Les deux peuvent traiter des requ\u00eates (l'esclave uniquement en lecture), donc les deux poss\u00e8dent une IP flottante : krogan2 \u2014 sur le ma\u00eetre, krogan2s1 \u2014 sur l'esclave. La tol\u00e9rance aux pannes sera pr\u00e9sente tant pour le ma\u00eetre que pour l'esclave.<\/p>\n

<\/p>\n

Dans le cas de deux n\u0153uds, la tol\u00e9rance aux pannes n'est possible que par r\u00e9plication asynchrone, car en r\u00e9plication synchrone, la d\u00e9faillance de l'esclave entra\u00eenera l'arr\u00eat du ma\u00eetre.<\/p>\n

<\/p>\n

D\u00e9faillance de Tuchanka2<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

En cas de d\u00e9faillance de l'un des centres de donn\u00e9es witness<\/em> vote pour le second. Sur le seul centre de donn\u00e9es fonctionnel, un master sera d\u00e9ploy\u00e9, qui recevra les deux IP flottants : celle du master et celle de l'esclave. Il va de soi que l'instance doit \u00eatre configur\u00e9e de mani\u00e8re \u00e0 disposer de ressources suffisantes (limites de connexion, etc.) pour accepter simultan\u00e9ment toutes les connexions et requ\u00eates provenant des deux IP flottantes, master et esclave. Cela signifie qu'en conditions normales, elle doit avoir une marge suffisante par rapport aux limites.<\/p>\n

<\/p>\n

Tuchanka4 (beaucoup d'esclaves)<\/h2>\n

<\/p>\n

Structure<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

C'est d\u00e9j\u00e0 un autre extr\u00eame. Il existe des bases de donn\u00e9es qui re\u00e7oivent un nombre consid\u00e9rable de requ\u00eates en lecture seule (c'est typiquement le cas des sites \u00e0 fort trafic). Tuchanka4 est une situation o\u00f9 le nombre d'esclaves peut \u00eatre de trois ou plus pour traiter ces requ\u00eates, mais sans \u00eatre trop nombreux. Avec un nombre tr\u00e8s \u00e9lev\u00e9 d'esclaves, il faudra inventer un syst\u00e8me de r\u00e9plication hi\u00e9rarchique. Dans le cas minimal (sur l'image), il y a deux serveurs dans chacun des deux centres de donn\u00e9es, chacun ayant une instance PostgreSQL.<\/p>\n

<\/p>\n

Une autre particularit\u00e9 de ce sch\u00e9ma est qu'il est d\u00e9j\u00e0 possible d'organiser une r\u00e9plication synchrone. Elle est configur\u00e9e pour r\u00e9pliquer, autant que possible, vers un autre centre de donn\u00e9es, et non vers une r\u00e9plique dans le m\u00eame centre de donn\u00e9es que le master. Tant le master que chaque esclave ont une IP flottante. Id\u00e9alement, il faudrait \u00e9quilibrer les requ\u00eates entre les esclaves d'une mani\u00e8re quelconque. sql proxy<\/em>, par exemple, du c\u00f4t\u00e9 client. Diff\u00e9rents types de clients peuvent n\u00e9cessiter diff\u00e9rents types sql proxy<\/em>, et seuls les d\u00e9veloppeurs clients savent qui a besoin de quoi. Cette fonctionnalit\u00e9 peut \u00eatre mise en \u0153uvre soit par un d\u00e9mon externe, soit par une biblioth\u00e8que cliente (pool de connexions), etc. Tout cela d\u00e9passe le cadre d'un cluster de bases de donn\u00e9es tol\u00e9rant aux pannes (la tol\u00e9rance aux pannes SQL proxy<\/em> peut \u00eatre r\u00e9alis\u00e9e ind\u00e9pendamment, en m\u00eame temps que la tol\u00e9rance aux pannes du client).<\/p>\n

<\/p>\n

Panne de Tuchanka4<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

En cas de panne d'un centre de donn\u00e9es (c'est-\u00e0-dire de deux serveurs), le t\u00e9moin vote pour le second. En cons\u00e9quence, dans le second centre de donn\u00e9es, deux serveurs fonctionnent : sur l'un se trouve le master, qui re\u00e7oit l'IP flottante du master (pour les requ\u00eates en lecture-\u00e9criture) ; et sur le second serveur, un esclave fonctionne avec une r\u00e9plication synchrone, sur lequel figure l'une des IP flottantes des esclaves (pour les requ\u00eates en lecture seule).<\/p>\n

<\/p>\n

La premi\u00e8re chose \u00e0 noter est que tous les IP flottants des esclaves ne seront pas op\u00e9rationnels, mais seulement un. Et pour travailler correctement avec celui-ci, il sera n\u00e9cessaire que sql proxy<\/em> tous les requ\u00eates \u00e9taient redirig\u00e9es vers le seul float IP restant ; sinon sql proxy<\/em> il est possible de lister tous les float IP des esclaves dans l'URL de connexion s\u00e9par\u00e9s par des virgules. Dans ce cas, la connexion se fera au premier IP de travail, comme c'est configur\u00e9 dans le syst\u00e8me de test automatis\u00e9. Il est possible qu'avec d'autres biblioth\u00e8ques, par exemple JDBC, cela ne fonctionne pas et que cela n\u00e9cessite libpq<\/em> La connexion sera \u00e9tablie au premier IP fonctionnel, ce qui est mis en place dans le syst\u00e8me de tests automatis\u00e9s. Il est possible que cela ne fonctionne pas avec d'autres biblioth\u00e8ques, comme JDBC, et qu\u2019un sql proxy<\/em>. Cela a \u00e9t\u00e9 r\u00e9alis\u00e9 car les float IP des esclaves ont l'interdiction de se lever simultan\u00e9ment sur un m\u00eame serveur, afin qu'ils soient uniform\u00e9ment r\u00e9partis sur les serveurs esclaves si plusieurs d'entre eux sont en fonctionnement.<\/p>\n

<\/p>\n

Deuxi\u00e8mement : m\u00eame en cas de d\u00e9faillance du centre de donn\u00e9es, la r\u00e9plication synchrone sera maintenue. Et m\u00eame si un second \u00e9chec se produit, c'est-\u00e0-dire que l'un des deux serveurs du centre de donn\u00e9es restant tombe en panne, le cluster, bien qu'il ne fournisse plus de services, conservera n\u00e9anmoins des informations sur toutes les transactions valid\u00e9es pour lesquelles il a donn\u00e9 une confirmation de commit (il n'y aura pas de perte d'informations en cas de second \u00e9chec).<\/p>\n

<\/p>\n

Tuchanka3 (3 centres de donn\u00e9es)<\/h2>\n

<\/p>\n

Structure<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

C'est un cluster pour une situation o\u00f9 il y a trois centres de donn\u00e9es fonctionnels, chacun avec un serveur de base de donn\u00e9es op\u00e9rationnel. Dans ce cas quorum device<\/em> n'est pas n\u00e9cessaire. Dans un centre de donn\u00e9es, fonctionne le ma\u00eetre, dans les deux autres - les esclaves. La r\u00e9plication est synchrone, de type ANY (esclave1, esclave2), c'est-\u00e0-dire que le client recevra une confirmation de commit lorsque l'un des esclaves r\u00e9pondra en premier qu'il a accept\u00e9 le commit. Un float IP est d\u00e9sign\u00e9 pour le ma\u00eetre et deux pour les esclaves. Contrairement \u00e0 Tuchanka4, tous les trois float IP sont tol\u00e9rants aux pannes. Pour \u00e9quilibrer les requ\u00eates SQL en lecture seule, on peut utiliser sql proxy<\/em> (avec une redondance externe), ou attribuer un float IP esclave \u00e0 la moiti\u00e9 des clients et l'autre \u00e0 l'autre moiti\u00e9.<\/p>\n

<\/p>\n

D\u00e9faillance de Tuchanka3<\/h3>\n

<\/p>\n

\"Mod\u00e9lisation<\/p>\n

<\/p>\n

En cas de d\u00e9faillance de l'un des centres de donn\u00e9es, deux restent. Dans l'un se trouve le ma\u00eetre et le float IP du ma\u00eetre, dans l'autre - un esclave et les deux float IP esclaves (l'instance doit avoir au moins deux fois la capacit\u00e9 des ressources pour accepter toutes les connexions des deux float IP esclaves). Entre le ma\u00eetre et l'esclave, il y a une r\u00e9plication synchrone. De plus, le cluster conservera des informations sur les transactions valid\u00e9es et confirm\u00e9es (il n'y aura pas de perte d'informations) en cas de destruction de deux centres de donn\u00e9es (s'ils sont d\u00e9truits non simultan\u00e9ment).<\/p>\n

<\/p>\n

Je n'ai pas inclus de description d\u00e9taill\u00e9e de la structure des fichiers et du d\u00e9ploiement. Si quelqu'un souhaite exp\u00e9rimenter, vous pouvez tout lire dans le README. Je ne fournis que la description du test automatique.<\/em><\/p>\n

<\/p>\n

Syst\u00e8me de test automatique<\/h1>\n

<\/p>\n

Pour tester la r\u00e9silience des clusters en simulant diverses pannes, un syst\u00e8me de test automatique a \u00e9t\u00e9 cr\u00e9\u00e9. Il est lanc\u00e9 par un script. test\/failure<\/code>. Le script peut accepter en param\u00e8tres les num\u00e9ros des clusters que vous souhaitez tester. Par exemple, cette commande :<\/p>\n

<\/p>\n

test\/failure 2 3<\/code><\/pre>\n
<\/p>\n
testera uniquement le deuxi\u00e8me et le troisi\u00e8me cluster. Si aucun param\u00e8tre n'est sp\u00e9cifi\u00e9, tous les clusters seront test\u00e9s. Tous les clusters sont test\u00e9s en parall\u00e8le, et le r\u00e9sultat est affich\u00e9 dans le panneau tmux. Tmux utilise un serveur tmux d\u00e9di\u00e9, il est donc possible de lancer le script \u00e0 partir du tmux par d\u00e9faut, ce qui donnera un tmux imbriqu\u00e9. Je recommande d'utiliser le terminal dans une grande fen\u00eatre avec une petite police. Avant de commencer les tests, toutes les machines virtuelles sont restaur\u00e9es \u00e0 un snapshot au moment de la fin du script. configuration<\/code>.<\/p>\n
<\/p>\n
\"Mod\u00e9lisation<\/p>\n
<\/p>\n
Le terminal est divis\u00e9 en colonnes correspondant au nombre de clusters test\u00e9s, qui est par d\u00e9faut (sur la capture d'\u00e9cran) quatre. Je d\u00e9taillerai le contenu des colonnes \u00e0 titre d'exemple pour Tuchanka2. Les panneaux sur la capture d'\u00e9cran sont num\u00e9rot\u00e9s :<\/p>\n
<\/p>\n
    \n
  1. Ici sont affich\u00e9es les statistiques des tests. Colonnes :\n