{"id":36393,"date":"2019-10-31T22:11:24","date_gmt":"2019-10-31T19:11:24","guid":{"rendered":"https:\/\/prohoster.info\/blog\/failover-nas-gubit-perfektsionizm-i-len\/"},"modified":"2019-10-31T22:11:24","modified_gmt":"2019-10-31T19:11:24","slug":"failover-nas-gubit-perfektsionizm-i-len","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover : notre p\u00e9ril est le perfectionnisme et\u2026 la paresse","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

L'\u00e9t\u00e9, la r\u00e9duction de l'activit\u00e9 des acheteurs et de l'intensit\u00e9 des changements d'infrastructure des projets web est quelque chose de traditionnel, nous dit le Capitaine \u00c9vidence. Simplement parce que m\u00eame les informaticiens, parfois, partent en vacances. Et les CTO aussi. C'est donc plus difficile pour ceux qui restent \u00e0 leur poste, mais ce n'est pas le sujet du jour : peut-\u00eatre que c'est justement pour cela que l'\u00e9t\u00e9 est la meilleure p\u00e9riode pour r\u00e9fl\u00e9chir calmement au sch\u00e9ma de sauvegarde existant et dresser un plan pour l'am\u00e9liorer. Et l'exp\u00e9rience d'Egor Andreyev de [AdminDivision] vous sera utile \u00e0 cet \u00e9gard. AdminDivision<\/a><\/noindex>, dont il a parl\u00e9 lors de la conf\u00e9rence Uptime day<\/a><\/noindex>.<\/i><\/p>\n

Lors de la construction de sites de secours, il existe plusieurs pi\u00e8ges dans lesquels on peut tomber. Et il est absolument inacceptable d'y tomber. Ce qui nous nuit dans tout cela, comme dans bien d'autres domaines, c'est le perfectionnisme et\u2026 la paresse. Nous essayons de tout faire parfaitement, alors qu'il n'est pas n\u00e9cessaire de tout rendre parfait ! Il faut juste faire certaines choses, mais bien les faire, jusqu'au bout, pour qu'elles fonctionnent correctement. <\/p>\n

Le basculement n'est pas un gadget amusant \u00ab juste pour le plaisir \u00bb ; c'est un outil qui doit faire une seule chose : r\u00e9duire le temps d'arr\u00eat, afin que le service et l'entreprise perdent moins d'argent. Dans toutes les m\u00e9thodes de sauvegarde, je propose de se demander dans quel contexte se trouvent l'argent.<\/p>\n

\"Failover
\n<\/a><\/noindex>
\nLe premier pi\u00e8ge<\/b>: lorsque nous construisons de grands syst\u00e8mes fiables et que nous nous occupons de la sauvegarde, nous r\u00e9duisons le nombre de pannes. C'est une terrible illusion. En fait, lorsque nous nous occupons de la sauvegarde, le nombre de pannes augmente probablement. Et si nous faisons tout correctement, nous r\u00e9duirons le temps d'arr\u00eat au total. Il y aura plus de pannes, mais elles se produiront avec moins de co\u00fbts. Qu'est-ce que la sauvegarde ? \u2014 c'est une complication du syst\u00e8me. Toute complication est n\u00e9gative : elle nous donne plus de petites pi\u00e8ces, plus de roues dent\u00e9es, en un mot, plus d'\u00e9l\u00e9ments \u2014 et donc, un risque de rupture plus grand. Et elles vont effectivement se casser. Et cela arrivera plus souvent. Un exemple simple : disons que nous avons un site utilisant PHP et MySQL, et qu'il doit \u00eatre rapidement sauvegard\u00e9. <\/p>\n

D'accord (c) Nous prenons la deuxi\u00e8me plateforme, construisons un syst\u00e8me identique... La complexit\u00e9 devient deux fois plus grande \u2014 nous avons deux entit\u00e9s. De plus, nous ajoutons une certaine logique de transfert de donn\u00e9es d'une plateforme \u00e0 l'autre \u2014 c'est-\u00e0-dire la r\u00e9plication des donn\u00e9es, la copie de la statique, et ainsi de suite. Ainsi, la logique de r\u00e9plication \u2014 elle est g\u00e9n\u00e9ralement tr\u00e8s complexe, et donc, la complexit\u00e9 globale du syst\u00e8me peut \u00eatre non pas 2, mais 3, 5, ou m\u00eame 10 fois plus grande. <\/p>\n

Le deuxi\u00e8me pi\u00e8ge<\/b>: lorsque nous construisons de v\u00e9ritables syst\u00e8mes complexes, nous imaginons ce que nous voulons obtenir \u00e0 la fin. Voil\u00e0 : nous voulons obtenir un syst\u00e8me super fiable qui fonctionne sans aucun temps d'arr\u00eat, qui bascule en une demi-seconde (ou mieux encore, instantan\u00e9ment), et nous commen\u00e7ons \u00e0 concr\u00e9tiser nos r\u00eaves. Mais ici aussi, il y a un d\u00e9tail : plus le temps de basculement souhait\u00e9 est court, plus la logique du syst\u00e8me devient complexe. Plus nous devrons rendre cette logique complexe, plus le syst\u00e8me aura tendance \u00e0 tomber en panne. Et on peut se retrouver dans une situation tr\u00e8s d\u00e9sagr\u00e9able : nous essayons de toutes nos forces de r\u00e9duire le temps d'arr\u00eat, alors qu'en r\u00e9alit\u00e9, nous compliquons les choses, et lorsque quelque chose ne va pas, le temps d'arr\u00eat sera finalement plus long. On se surprend souvent \u00e0 penser : eh bien... il valait mieux ne pas avoir de redondance. Il valait mieux que tout fonctionne seul avec un temps d'arr\u00eat compr\u00e9hensible. <\/p>\n

Comment peut-on lutter contre cela ? Il faut arr\u00eater de se mentir, arr\u00eater de se flatter en pensant que nous allons construire une fus\u00e9e spatiale, mais comprendre de mani\u00e8re ad\u00e9quate combien de temps le projet peut effectivement \u00eatre en attente. Et en fonction de ce temps maximum, nous choisirons en fait les m\u00e9thodes dont nous disposerons pour augmenter la fiabilit\u00e9 de notre syst\u00e8me. <\/p>\n

\"Failover
\n
\nIl est temps de raconter des \u00ab histoires de la vraie vie \u00bb\u2026 de la vie, bien s\u00fbr. <\/p>\n

Exemple num\u00e9ro un<\/h4>\n

\nImaginez un site vitrine pour l'usine de tuyauterie num\u00e9ro 1 de la ville de N. Il est \u00e9crit en lettres g\u00e9antes \u2014 USINE DE TUYAUTERIE N\u00b0 1. Juste en dessous \u2014 le slogan : \u00ab Nos tuyaux sont les tuyaux les plus ronds de N \u00bb. Et en bas, le num\u00e9ro de t\u00e9l\u00e9phone du directeur g\u00e9n\u00e9ral et son nom. Nous comprenons qu'il est n\u00e9cessaire de r\u00e9server \u2014 c'est tr\u00e8s important ! Commen\u00e7ons \u00e0 analyser de quoi cela se compose. C'est de l'HTML statique \u2014 c'est-\u00e0-dire quelques images o\u00f9 le directeur est, en fait, assis \u00e0 une table dans un sauna avec son partenaire, discutant d'une nouvelle affaire. Nous commen\u00e7ons \u00e0 penser au temps d'arr\u00eat. Une pens\u00e9e nous traverse : il faut rester l\u00e0 cinq minutes, pas plus. Et voici la question : combien de ventes ont \u00e9t\u00e9 r\u00e9alis\u00e9es sur notre site ? Combien, combien ? Que signifie \u00ab z\u00e9ro \u00bb ? En effet, cela veut dire que les quatre affaires de l'ann\u00e9e derni\u00e8re ont \u00e9t\u00e9 conclues \u00e0 la m\u00eame table, avec les m\u00eames personnes, avec qui ils vont au sauna et s'assoient \u00e0 la table. Nous comprenons qu'il ne se passera rien de terrible m\u00eame si le site reste inactif pendant un jour. <\/p>\n

En se basant sur ces \u00e9l\u00e9ments, nous avons un jour pour mettre cette histoire en place. Nous commen\u00e7ons \u00e0 r\u00e9fl\u00e9chir au sch\u00e9ma de r\u00e9servation. Et nous choisissons le sch\u00e9ma de r\u00e9servation le plus id\u00e9al pour cet exemple : nous ne faisons pas de r\u00e9servation. Tout cela peut \u00eatre mis en place par n'importe quel administrateur en trente minutes, pauses comprises. Installer le serveur web, d\u00e9poser les fichiers \u2014 tout simplement. Cela fonctionnera. Il n'est pas n\u00e9cessaire de surveiller quoi que ce soit, rien ne n\u00e9cessite une attention particuli\u00e8re. Ainsi, la conclusion du premier exemple est assez claire : les services pour lesquels aucune r\u00e9servation n'est n\u00e9cessaire \u2014 cela ne n\u00e9cessite pas de r\u00e9servation.<\/p>\n

\"Failover
\n<\/p>\n

Exemple num\u00e9ro deux<\/h4>\n

\nBlog de l'entreprise : des \u00e9crivains sp\u00e9cialement form\u00e9s y publient des nouvelles, par exemple, nous avons particip\u00e9 \u00e0 telle exposition, ou nous avons lanc\u00e9 un nouveau produit, et ainsi de suite. Supposons qu'il s'agit d'un PHP standard avec WordPress, une petite base de donn\u00e9es et un peu de contenu statique. Bien s\u00fbr, on pense \u00e0 nouveau qu'il ne faut surtout pas le laisser inactif \u2014 \u00ab pas plus de cinq minutes ! \u00bb, tout \u00e7a. Mais r\u00e9fl\u00e9chissons un peu plus. Quel est le but de ce blog ? Il attire des visiteurs depuis Yandex et Google par certaines requ\u00eates, par le biais du r\u00e9f\u00e9rencement. Super. Et les ventes, sont-elles li\u00e9es d'une mani\u00e8re ou d'une autre ? R\u00e9v\u00e9lation : pas vraiment. Le trafic publicitaire est dirig\u00e9 vers le site principal, qui est sur une autre machine. Nous commen\u00e7ons \u00e0 r\u00e9fl\u00e9chir \u00e0 un sch\u00e9ma de sauvegarde du blog. Id\u00e9alement, il faudrait pouvoir le relancer en quelques heures, et il serait bon de s'y pr\u00e9parer. Il serait judicieux de prendre une machine dans un autre data center, d'y installer un environnement, c'est-\u00e0-dire un serveur web, PHP, WordPress, MySQL, et de le laisser en veille. Au moment o\u00f9 nous r\u00e9alisons que tout est cass\u00e9, il faut faire deux choses - restaurer un dump MySQL de 50 Mo, ce qui prendra une minute, et r\u00e9cup\u00e9rer un certain nombre d'images depuis la sauvegarde. Cela ne prend pas non plus beaucoup de temps. Ainsi, en une demi-heure, tout cela peut \u00eatre remis en marche. Pas de r\u00e9plications, ou pire encore, de basculement automatique. Conclusion : ce que nous pouvons rapidement restaurer d'une sauvegarde ne n\u00e9cessite pas de sauvegarde s\u00e9par\u00e9e. <\/p>\n

\"Failover
\n<\/p>\n

Exemple num\u00e9ro trois, un peu plus complexe<\/h4>\n

\nBoutique en ligne. PHP avec open heart l\u00e9g\u00e8rement modifi\u00e9, MySQL avec une base solide. Pas mal de statique (apr\u00e8s tout, une boutique en ligne a de jolies images HD et tout le reste), Redis pour les sessions et Elasticsearch pour la recherche. Nous commen\u00e7ons \u00e0 penser au temps d'arr\u00eat. Et ici, il est \u00e9videmment clair qu'il est impossible que la boutique en ligne soit inactive pendant un jour sans douleur. Plus elle est inactive, plus nous perdons d'argent. Il est temps d'acc\u00e9l\u00e9rer. Et \u00e0 quel point ? Je suppose que si nous restons inactifs pendant une heure, personne ne perdra la t\u00eate. Oui, nous perdrons quelque chose, mais si nous nous acharnons, cela ne fera qu'empirer. Nous d\u00e9terminons le sch\u00e9ma de temps d'arr\u00eat acceptable par heure.<\/p>\n

Comment peut-on tout cela r\u00e9server ? Une machine est n\u00e9cessaire dans tous les cas : une heure, c'est plut\u00f4t peu. Mysql : ici, une r\u00e9plication est requise, une r\u00e9plication active, car en une heure, 100 Go de dump ne passeront probablement pas. Statique, images : encore une fois, en une heure, 500 Go pourraient ne pas \u00eatre transf\u00e9r\u00e9s \u00e0 temps. Il serait donc pr\u00e9f\u00e9rable de copier imm\u00e9diatement les images. Redis : c'est ici que la situation devient plus int\u00e9ressante. Les sessions se trouvent dans Redis \u2014 nous ne pouvons tout simplement pas le supprimer. Car ce ne serait pas id\u00e9al : tous les utilisateurs se retrouveraient d\u00e9connect\u00e9s, leurs paniers seraient vid\u00e9s, etc. Les gens seraient contraints de ressaisir leur identifiant et leur mot de passe, et beaucoup risquent d'abandonner leurs achats. Encore une fois, cela fera chute du taux de conversion. D'un autre c\u00f4t\u00e9, Redis, tel qu'il est, avec les derniers utilisateurs connect\u00e9s, n'est probablement pas n\u00e9cessaire non plus. Et un bon compromis serait de prendre Redis et de le restaurer \u00e0 partir d'une sauvegarde, d'hier, ou, s'il est sauvegard\u00e9 chaque heure, d'une heure auparavant. Heureusement, sa restauration \u00e0 partir d'une sauvegarde ne n\u00e9cessite que la copie d'un fichier. Et l'histoire la plus fascinante concerne Elasticsearch. Qui a d\u00e9j\u00e0 mis en place la r\u00e9plication MySQL ? Qui a d\u00e9j\u00e0 mis en place la r\u00e9plication Elasticsearch ? Et chez qui cela a-t-il bien fonctionn\u00e9 par la suite ? Ce que je veux dire, c'est que nous voyons dans notre syst\u00e8me une sorte d'entit\u00e9. Elle semble utile \u2014 mais elle est complexe.
\nC'est compliqu\u00e9 dans le sens o\u00f9 nos coll\u00e8gues ing\u00e9nieurs n'ont pas d'exp\u00e9rience avec cela. Soit ils ont une exp\u00e9rience n\u00e9gative, soit nous comprenons que c'est une technologie encore relativement nouvelle avec ses nuances et ses imperfections. Nous pensons... Mince, elastic est aussi lourd, il prend beaucoup de temps \u00e0 se restaurer depuis une sauvegarde, que faire ? Nous comprenons qu'elastic est utilis\u00e9 pour la recherche dans notre cas. Et comment notre boutique en ligne vend-elle ? Nous allons chez les sp\u00e9cialistes du marketing et leur demandons d'o\u00f9 viennent les gens. Ils r\u00e9pondent : \u00ab 90 % viennent directement de Yandex.Market sur la fiche produit \u00bb. Et soit ils ach\u00e8tent, soit ils n'ach\u00e8tent pas. Par cons\u00e9quent, la recherche est n\u00e9cessaire pour 10 % des utilisateurs. Et maintenir la r\u00e9plication d'elastic, surtout entre diff\u00e9rents centres de donn\u00e9es dans diff\u00e9rentes zones, comporte en effet beaucoup de nuances. Quelle est la solution ? Nous prenons elastic sur un site de sauvegarde et nous ne faisons rien avec. Si cela prend du temps, peut-\u00eatre que nous le mettrons en ligne un jour, mais ce n'est pas s\u00fbr. En r\u00e9alit\u00e9, la conclusion reste globalement la m\u00eame : nous ne sauvegardons pas les services qui n'affectent pas les revenus.<\/p>\n

\"Failover
\n<\/p>\n

Exemple num\u00e9ro quatre, encore plus compliqu\u00e9<\/h4>\n

\nIntegrateur : vente de fleurs, appel de taxi, vente de produits, en gros, tout ce que vous voulez. Une chose s\u00e9rieuse qui fonctionne 24\/7 pour un grand nombre d'utilisateurs. Avec une pile int\u00e9ressante et compl\u00e8te, o\u00f9 il y a des bases int\u00e9ressantes, des solutions, une forte charge, et surtout, il est douloureux qu'elle soit en panne pendant plus de 5 minutes. Non seulement parce que les gens n\u2019ach\u00e8teront pas, mais parce qu\u2019ils verront que \u00e7a ne fonctionne pas, seront d\u00e9\u00e7us et pourraient ne jamais revenir. <\/p>\n

D'accord. Cinq minutes. Que faisons-nous avec \u00e7a ? Dans ce cas, nous b\u00e2tissons s\u00e9rieusement, avec tous les moyens, une v\u00e9ritable plateforme de secours, avec r\u00e9plication de tout et n'importe quoi, et \u00e9ventuellement, nous automatisons au maximum le basculement vers cette plateforme. Et en plus de cela, il ne faut pas oublier de faire une chose importante : en fait, r\u00e9diger un r\u00e8glement de basculement. Le r\u00e8glement, m\u00eame si vous avez tout automatis\u00e9, peut \u00eatre tr\u00e8s simple. Genre \u00ab lancer ce sc\u00e9nario ansible \u00bb, \u00ab cocher cette case dans route 53 \u00bb et ainsi de suite - mais cela doit \u00eatre une liste pr\u00e9cise d'actions. <\/p>\n

Tout semble clair. Passer la r\u00e9plication \u2014 c'est une t\u00e2che triviale, ou elle peut se faire toute seule. R\u00e9\u00e9crire le nom de domaine dans le DNS \u2014 c'est dans la m\u00eame veine. Le probl\u00e8me, c'est que lorsque ce type de projet \u00e9choue, la panique s'installe, et m\u00eame les meilleurs administrateurs peuvent en \u00eatre affect\u00e9s. Sans une instruction claire \u00ab ouvrez le terminal, allez ici, l'adresse de notre serveur est toujours celle-ci \u00bb, il est difficile de respecter un d\u00e9lai de 5 minutes pour la r\u00e9animation. De plus, lorsque nous utilisons cette proc\u00e9dure, il est facile d'enregistrer des modifications dans l'infrastructure, par exemple, et d'ajuster la proc\u00e9dure en cons\u00e9quence.
\nCependant, si le syst\u00e8me de sauvegarde est tr\u00e8s complexe et qu'\u00e0 un moment donn\u00e9 nous avons commis une erreur, nous pourrions \u00e9galement compromettre notre site de secours et, de plus, transformer les donn\u00e9es en citrouille sur les deux sites \u2014 ce serait vraiment triste. <\/p>\n

\"Failover
\n<\/p>\n

Exemple num\u00e9ro cinq, pure hardcore.<\/h4>\n

\nUn service international avec des centaines de millions d'utilisateurs \u00e0 travers le monde. Tous les fuseaux horaires possibles, haute charge au maximum, ne pas tomber est imp\u00e9ratif. Une minute \u2014 et ce sera triste. Que faire ? Sauvegarder, encore une fois, de mani\u00e8re exhaustive. Nous avons fait tout ce qui a \u00e9t\u00e9 dit dans le pr\u00e9c\u00e9dent exemple, et un peu plus. C'est un monde id\u00e9al, et notre infrastructure \u2014 elle correspond \u00e0 tous les crit\u00e8res du DevOps IaaC. Tout est dans Git, il suffit d'appuyer sur un bouton. <\/p>\n

Que manque-t-il ? Juste une chose \u2014 des exercices. Sans eux, c'est impossible. On pourrait penser que tout va parfaitement, que tout est sous contr\u00f4le. Nous appuyons sur le bouton, tout se passe. M\u00eame si cela est vrai \u2014 et nous savons que ce n'est pas le cas \u2014 notre syst\u00e8me interagit avec d'autres syst\u00e8mes. Par exemple, il y a le DNS de Route 53, le stockage S3, l'int\u00e9gration avec diverses API. Rien ne peut \u00eatre pr\u00e9vu dans cette exp\u00e9rience th\u00e9orique. Et tant que nous n'avons pas vraiment tir\u00e9 le levier \u2014 nous ne saurons pas si cela fonctionne ou non. <\/p>\n

\"Failover
\n
\nC'est probablement tout. Ne soyez pas paresseux et ne poussez pas trop loin. Et que l'uptime soit avec vous !
\n
Source : habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a. \u0418 C\u0422\u041e \u0442\u043e\u0436\u0435. \u0422\u0435\u043c \u0442\u044f\u0436\u0435\u043b\u0435\u0435 \u0442\u0435\u043c, \u043a\u0442\u043e \u043e\u0441\u0442\u0430\u0451\u0442\u0441\u044f \u043d\u0430 \u043f\u043e\u0441\u0442\u0443, \u043d\u043e \u0441\u0435\u0439\u0447\u0430\u0441 \u043d\u0435 \u043e\u0431 \u044d\u0442\u043e\u043c: \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043b\u0435\u0442\u043e \u2014 \u043b\u0443\u0447\u0448\u0438\u0439 \u043f\u0435\u0440\u0438\u043e\u0434 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0442\u043e\u0440\u043e\u043f\u044f\u0441\u044c \u043e\u0431\u0434\u0443\u043c\u0430\u0442\u044c \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0443\u044e \u0441\u0445\u0435\u043c\u0443 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36393","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Failover : le perfectionnisme et\u2026 la paresse nous perdent | ProHoster","description":"En \u00e9t\u00e9, l'activit\u00e9 d'achat et l'intensit\u00e9 des changements d'infrastructure des projets web diminuent traditionnellement, nous dit le Capitaine \u00c9vidence. Tout simplement parce que m\u00eame les informaticiens prennent parfois des vacances.","canonical_url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"fr_FR","og:site_name":"ProHoster | \u041a\u0443\u043f\u0438\u0442\u044c \u043d\u0430\u0434\u0435\u0436\u043d\u044b\u0439 \u0445\u043e\u0441\u0442\u0438\u043d\u0433 \u0434\u043b\u044f \u0441\u0430\u0439\u0442\u043e\u0432 \u0441 \u0437\u0430\u0449\u0438\u0442\u043e\u0439 \u043e\u0442 DDoS, VPS VDS \u0441\u0435\u0440\u0432\u0435\u0440\u044b","og:type":"article","og:title":"\ud83e\udd47Failover: \u043d\u0430\u0441 \u0433\u0443\u0431\u0438\u0442 \u043f\u0435\u0440\u0444\u0435\u043a\u0446\u0438\u043e\u043d\u0438\u0437\u043c \u0438\u2026 \u043b\u0435\u043d\u044c | ProHoster","og:description":"\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a.","og:url":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","og:image":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:secure_url":"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg","og:image:width":350,"og:image:height":350,"article:published_time":"2019-10-31T19:11:24+00:00","article:modified_time":"2019-10-31T19:11:24+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"36393","title":null,"description":null,"keywords":null,"keyphrases":null,"primary_term":null,"canonical_url":null,"og_title":null,"og_description":null,"og_object_type":"default","og_image_type":"default","og_image_url":null,"og_image_width":null,"og_image_height":null,"og_image_custom_url":null,"og_image_custom_fields":null,"og_video":null,"og_custom_url":null,"og_article_section":null,"og_article_tags":null,"twitter_use_og":false,"twitter_card":"default","twitter_image_type":"default","twitter_image_url":null,"twitter_image_custom_url":null,"twitter_image_custom_fields":null,"twitter_title":null,"twitter_description":null,"schema":{"blockGraphs":[],"customGraphs":[],"default":{"data":{"Article":[],"Course":[],"Dataset":[],"FAQPage":[],"Movie":[],"Person":[],"Product":[],"ProductReview":[],"Car":[],"Recipe":[],"Service":[],"SoftwareApplication":[],"WebPage":[]},"graphName":"","isEnabled":true},"graphs":[]},"schema_type":null,"schema_type_options":null,"pillar_content":false,"robots_default":true,"robots_noindex":false,"robots_noarchive":false,"robots_nosnippet":false,"robots_nofollow":false,"robots_noimageindex":false,"robots_noodp":false,"robots_notranslate":false,"robots_max_snippet":null,"robots_max_videopreview":null,"robots_max_imagepreview":"large","priority":null,"frequency":null,"local_seo":null,"seo_analyzer_scan_date":"2026-01-22 03:07:19","breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 01:45:36","updated":"2026-01-22 03:07:19","focus_keyword":null,"additional_keywords":null,"truseo_locale":null},"gt_translate_keys":[{"key":"link","format":"url"}],"_links":{"self":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/fr\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}