{"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\/de\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: Perfektionismus und\u2026 Faulheit bringen uns um","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Im Sommer sinken traditionell sowohl die K\u00e4uferaktivit\u00e4t als auch die Intensit\u00e4t der \u00c4nderungen an der Infrastruktur von Webprojekten, sagt uns Captain Offensichtlich. Einfach weil selbst ITler manchmal in den Urlaub fahren. Und auch CTOs. Umso schwieriger ist es f\u00fcr die, die am Posten bleiben, aber darum geht es jetzt nicht: vielleicht ist genau deshalb der Sommer die beste Zeit, um ungest\u00f6rt \u00fcber das bestehende Reservierungsschema nachzudenken und einen Plan zu seiner Verbesserung zu erstellen. Und dabei wird euch die Erfahrung von Egor Andreev aus AdminDivision<\/a><\/noindex>, die er auf der Konferenz Uptime day<\/a><\/noindex>.<\/i><\/p>\n

Beim Aufbau von Backup-Plattformen und bei der Reservierung gibt es mehrere Fallen, in die man tappen kann. Und in diese darf man auf keinen Fall tappen. Und es sind uns dabei, wie in vielen anderen Dingen, Perfektionismus und\u2026 Faulheit im Weg. Wir versuchen, alles perfekt zu machen, und das muss nicht sein! Wir m\u00fcssen nur bestimmte Dinge tun, aber sie richtig machen und bis zum Ende bringen, damit sie gut funktionieren. <\/p>\n

Failover ist kein lustiges Gadget, \u201enur damit es vorhanden ist\u201c; es ist etwas, das genau eines tun sollte \u2013 die Ausfallzeiten zu minimieren, damit der Dienst, das Unternehmen, weniger Geld verliert. Und bei allen Methoden der Reservierung schlage ich vor, im folgenden Kontext zu denken: Wo ist das Geld?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nDie erste Falle<\/b>: Wenn wir gro\u00dfe, zuverl\u00e4ssige Systeme aufbauen und uns mit der Reservierung besch\u00e4ftigen \u2013 verringern wir die Anzahl von Ausf\u00e4llen. Das ist ein schrecklicher Irrtum. Wenn wir uns mit der Reservierung besch\u00e4ftigen, erh\u00f6hen wir wahrscheinlich die Anzahl der Ausf\u00e4lle. Und wenn wir alles richtig machen, verringern wir insgesamt die Ausfallzeit. Es wird mehr Ausf\u00e4lle geben, aber sie werden mit geringeren Kosten eintreten. Denn was ist Reservierung? \u2013 Es ist eine Komplikation des Systems. Jede Komplikation ist schlecht: Wir haben mehr Schrauben, mehr Zahnr\u00e4der, kurz gesagt, mehr Elemente \u2013 und damit eine h\u00f6here Wahrscheinlichkeit f\u00fcr Fehlfunktionen. Und sie werden wirklich kaputtgehen. Und sie werden h\u00e4ufiger kaputtgehen. Ein einfaches Beispiel: Angenommen, wir haben eine Website mit PHP, MySQL. Und diese muss dringend reserviert werden. <\/p>\n

Nun, wir nehmen die zweite Plattform und bauen ein identisches System\u2026 Die Komplexit\u00e4t verdoppelt sich \u2014 wir haben zwei Entit\u00e4ten. Dar\u00fcber hinaus f\u00fcgen wir eine bestimmte Logik f\u00fcr den Daten\u00fcbertrag von einer Plattform zur anderen hinzu \u2014 also Datenreplikation, das Kopieren von Statischer und so weiter. Die Logik der Replikation ist in der Regel sehr komplex, deshalb kann die gesamte Systemkomplexit\u00e4t nicht nur um das 2-fache, sondern um das 3-, 5- oder 10-fache h\u00f6her sein. <\/p>\n

Die zweite Falle<\/b>: Wenn wir wirklich gro\u00dfe und komplexe Systeme erstellen, tr\u00e4umen wir davon, was wir letztendlich erreichen wollen. Voil\u00e0: Wir wollen ein superzuverl\u00e4ssiges System, das \u00fcberhaupt keine Ausfallzeiten hat, in einer halben Sekunde (oder besser noch sofort) umschaltet, und beginnen, unsere Tr\u00e4ume in die Realit\u00e4t umzusetzen. Aber auch hier gibt es einen Unterschied: Je geringer die gew\u00fcnschte Umschaltzeit, desto komplizierter wird die Systemlogik. Je komplizierter wir diese Logik gestalten, desto h\u00e4ufiger wird das System ausfallen. Und man kann in eine sehr unangenehme Situation geraten: Wir versuchen mit aller Kraft, die Ausfallzeit zu verringern, aber in Wirklichkeit komplizieren wir alles und wenn etwas schiefgeht, wird die Ausfallzeit am Ende l\u00e4nger sein. Oft denkt man sich: H\u00e4tte ich doch besser nicht reserviert. Es w\u00e4re besser gewesen, wenn es nur eins gegeben h\u00e4tte, das mit einer klaren Ausfallzeit arbeitet. <\/p>\n

Wie kann man dem begegnen? Man muss aufh\u00f6ren, sich selbst zu bel\u00fcgen, aufh\u00f6ren, sich einzureden, dass wir hier jetzt ein Raumschiff bauen werden, und realistisch verstehen, wie lange das Projekt dauern kann. Und nach dieser maximalen Zeit werden wir entscheiden, mit welchen Methoden wir die Zuverl\u00e4ssigkeit unseres Systems erh\u00f6hen werden. <\/p>\n

\"Failover:
\n
\nEs ist Zeit f\u00fcr \"Geschichten aus dem Leben\"\u2026 aus dem echten Leben, nat\u00fcrlich. <\/p>\n

Beispiel Nummer eins<\/h4>\n

\nStellen Sie sich die Website einer Rohrleitungsfabrik Nr. 1 in der Stadt N vor. In gro\u00dfen Buchstaben steht dort \u2013 ROHRLEITUNGSFABRIK Nr. 1. Etwas weiter unten steht der Slogan: \u201eUnsere Rohre sind die rundesten Rohre in N\u201c. Und ganz unten die Telefonnummer des Gesch\u00e4ftsf\u00fchrers und sein Name. Wir verstehen, dass wir reservieren m\u00fcssen \u2013 das ist eine sehr wichtige Angelegenheit! Wir beginnen zu untersuchen, woraus das besteht. HTML-Statik \u2013 das hei\u00dft, ein paar Bilder, auf denen der Gesch\u00e4ftsf\u00fchrer, wie es scheint, am Tisch in der Sauna mit seinem Partner \u00fcber einen weiteren Deal diskutiert. Wir beginnen \u00fcber die Leerzeit nachzudenken. Uns kommt in den Sinn: Man muss da f\u00fcnf Minuten liegen, nicht mehr. Und dann die Frage: Wie viele Verk\u00e4ufe gab es von dieser Website \u00fcberhaupt? Wie viele? Was bedeutet \u201enull\u201c? Es bedeutet: Denn alle vier Gesch\u00e4fte des letzten Jahres hat der Gesch\u00e4ftsf\u00fchrer am selben Tisch mit denselben Personen gemacht, mit denen sie in die Sauna gehen. Und wir verstehen, dass es nichts Schlimmes sein wird, wenn die Website einen Tag lang liegt. <\/p>\n

Aus den Eingaben ergibt sich, dass es einen Tag f\u00fcr die Einf\u00fchrung dieser Geschichte gibt. Wir beginnen, \u00fcber das Reservierungsschema nachzudenken. Und w\u00e4hlen das idealste Schema f\u00fcr die Reservierung in diesem Beispiel: Wir verwenden keine Reservierung. Das ganze Ding kann von jedem Administrator in einer halben Stunde mit Pausen hochgefahren werden. Einen Webserver aufsetzen, die Dateien hochladen \u2013 das war's. Es funktioniert. Man muss nichts \u00fcberwachen, nichts besonders beachten. Das hei\u00dft, die Schlussfolgerung aus Beispiel eins ist ziemlich offensichtlich: Dienste, die nicht reserviert werden m\u00fcssen \u2013 m\u00fcssen nicht reserviert werden.<\/p>\n

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

Beispiel Nummer zwei<\/h4>\n

\nBlog des Unternehmens: speziell ausgebildete Mitarbeiter schreiben dort Nachrichten, zum Beispiel, dass wir an dieser oder jener Ausstellung teilgenommen haben, oder dass wir ein neues Produkt herausgebracht haben, und so weiter. Angenommen, es handelt sich um ein Standard-PHP mit WordPress, einer kleinen Datenbank und ein wenig Statik. Nat\u00fcrlich kommt einem wieder der Gedanke, dass man in keinem Fall einfach abwarten sollte \u2013 \"nicht l\u00e4nger als f\u00fcnf Minuten!\", all das. Aber lassen Sie uns weiterdenken. Was macht dieser Blog? Er erh\u00e4lt Besucher \u00fcber Yandex, Google, aufgrund bestimmter Anfragen, \u00fcber organische Suche. Toll. Und wie stehen die Verk\u00e4ufe dazu? Die Erkenntnis: nicht wirklich. Der Werbe-Traffic geht auf die Hauptwebsite, die auf einem anderen Server l\u00e4uft. Wir fangen an, \u00fcber ein Backup-System f\u00fcr den Blog nachzudenken. Im besten Fall sollte es innerhalb von ein paar Stunden wiederhergestellt werden, und es w\u00e4re gut, darauf vorbereitet zu sein. Es w\u00e4re klug, einen anderen Server in einem anderen Rechenzentrum zu mieten, das Umfeld, also den Webserver, PHP, WordPress, MySQL, darauf zu installieren und diesen dann inaktiv zu belassen. In dem Moment, wenn wir merken, dass etwas kaputt gegangen ist, m\u00fcssen wir zwei Dinge tun \u2013 das MySQL-Dump von 50 MB einspielen, das dauert dort eine Minute, und eine bestimmte Anzahl an Bildern aus dem Backup zur\u00fcckspielen. Das dauert auch nicht lange. So wird in einer halben Stunde alles wieder hochgefahren. Es sind keine Replikationen oder, Gott bewahre, automatischen Failover notwendig. Fazit: Was wir schnell aus dem Backup wiederherstellen k\u00f6nnen, braucht keine Sicherung. <\/p>\n

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

Beispiel Nummer drei, etwas komplizierter.<\/h4>\n

\nOnlineshop. PHP mit Open Heart, etwas angepasst, MySQL mit einer soliden Datenbasis. Ziemlich viel Statische (denn in einem Onlineshop gibt es sch\u00f6ne HD-Bilder und all das), Redis f\u00fcr die Sitzung und Elasticsearch f\u00fcr die Suche. Wir beginnen, \u00fcber Ausfallzeiten nachzudenken. Und hier ist es nat\u00fcrlich offensichtlich, dass ein Tag, an dem der Onlineshop keine Einnahmen hat, nicht unproblematisch sein kann. Je l\u00e4nger er liegt, desto mehr Geld verlieren wir. Es wird Zeit, sich zu beeilen. Aber wie viel? Ich denke, wenn wir eine Stunde aussetzen, wird niemand verr\u00fcckt spielen. Ja, wir werden etwas verlieren, aber wir fangen an, intensiv zu arbeiten \u2013 das wird nur schlimmer. Wir definieren das auszuhaltende Ma\u00df an Ausfallzeit pro Stunde.<\/p>\n

Wie kann man das alles reservieren? Ein Auto wird in jedem Fall ben\u00f6tigt: eine Stunde Zeit ist ziemlich wenig. Mysql: hier ist bereits eine Replikation notwendig, eine echte Replikation, denn in einer Stunde wird wahrscheinlich kein Dump von 100 GB in die Datenbank geladen. Statische Inhalte, Bilder: auch hier k\u00f6nnten in einer Stunde m\u00f6glicherweise keine 500 GB \u00fcbertragen werden. Daher ist es besser, die Bilder sofort zu kopieren. Redis: hier wird es interessanter. In Redis liegen die Sessions \u2014 wir k\u00f6nnen sie einfach nicht ablegen. Denn das w\u00e4re nicht gut: alle Benutzer w\u00fcrden ausgeloggt werden, die Warenk\u00f6rbe w\u00e4ren leer usw. Die Leute m\u00fcssten ihren Benutzernamen und ihr Passwort erneut eingeben, und viele k\u00f6nnten abspringen und den Kauf nicht abschlie\u00dfen. Wiederum w\u00fcrde die Conversion sinken. Auf der anderen Seite ist Redis direkt aktuell, mit den zuletzt angemeldeten Benutzern, wahrscheinlich auch nicht notwendig. Ein guter Kompromiss w\u00e4re, Redis zu \u00fcbernehmen und ihn aus einem Backup wiederherzustellen, von gestern oder, falls es jede Stunde gemacht wird, von vor einer Stunde. Gl\u00fccklicherweise besteht die Wiederherstellung aus einem einzigen Datei. Und die interessanteste Geschichte ist Elasticsearch. Wer hat jemals die MySQL-Replikation hochgefahren? Wer hat jemals die Elasticsearch-Replikation hochgefahren? Und bei wem hat sie danach normal funktioniert? Ich meine damit: wir sehen in unserem System eine Art Entit\u00e4t. Sie scheint n\u00fctzlich zu sein \u2014 aber sie ist komplex.
\nKompliziert in dem Sinne, dass unsere Ingenieure keine Erfahrung damit haben. Entweder gibt es negative Erfahrungen oder wir verstehen, dass dies eine recht neue Technologie mit ihren Eigenheiten oder Unzul\u00e4nglichkeiten ist. Wir denken nach... Verdammt, Elastic ist auch gro\u00df, und es dauert lange, ihn aus dem Backup wiederherzustellen. Was tun? Wir verstehen, dass Elastic in unserem Fall f\u00fcr die Suche verwendet wird. Und wie verkauft unser Online-Shop? Wir gehen zu den Marketingspezialisten und fragen, woher die Leute \u00fcberhaupt kommen. Sie antworten: \"90 % kommen direkt von Yandex-Markt zur Produktkarte.\" Und entweder kaufen sie oder nicht. Folglich brauchen nur 10 % der Benutzer die Suche. Und die Replikation von Elastic zu halten, insbesondere zwischen verschiedenen Rechenzentren in verschiedenen Zonen, hat tats\u00e4chlich viele Nuancen. Was ist die L\u00f6sung? Wir nehmen Elastic auf einer reservierten Fl\u00e4che und machen zun\u00e4chst nichts damit. Wenn es l\u00e4nger dauert, heben wir es vielleicht irgendwann sp\u00e4ter, aber das ist ungewiss. Eigentlich bleibt die Schlussfolgerung mehr oder weniger die gleiche: Dienstleistungen, die sich nicht auf das Geld auswirken, reservieren wir, wieder einmal, nicht. Damit das Schema einfacher bleibt.<\/p>\n

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

Beispiel Nummer vier, noch schwieriger.<\/h4>\n

\nIntegrator: Verkauf von Blumen, Taxiruf, Warenverkauf, kurz gesagt, alles M\u00f6gliche. Eine ernsthafte Sache, die rund um die Uhr f\u00fcr eine gro\u00dfe Anzahl von Nutzern arbeitet. Mit einem vollst\u00e4ndigen und interessanten Stack, wo interessante Datenbanken, L\u00f6sungen, hohe Lasten vorhanden sind, und das wichtigste, l\u00e4nger als 5 Minuten auszufallen, tut wirklich weh. Nicht nur, weil die Leute nicht kaufen, sondern weil die Leute sehen, dass dieses Ding nicht funktioniert, entt\u00e4uscht sind und beim n\u00e4chsten Mal vielleicht \u00fcberhaupt nicht zur\u00fcckkommen. <\/p>\n

Okay. F\u00fcnf Minuten. Was machen wir damit? In diesem Fall bauen wir ernsthaft, mit vollem Budget, eine echte Backup-Plattform auf, mit Replikationen von allem und jedem, und m\u00f6glicherweise automatisieren wir auch das Umschalten auf diese Plattform so weit wie m\u00f6glich. Und zus\u00e4tzlich dazu sollte man nicht vergessen, eine wichtige Sache zu tun: n\u00e4mlich ein Umschaltprotokoll zu schreiben. Das Protokoll kann, selbst wenn bei Ihnen alles automatisiert ist, sehr einfach sein. Aus der Reihe \u201eDieses Ansible-Szenario starten\u201c, \u201eIn Route 53 diese Option aktivieren\u201c und so weiter \u2013 es sollte aber eine genaue Liste von Schritten sein. <\/p>\n

Und irgendwie ist alles klar. Die Replikation umzuschalten ist eine triviale Aufgabe, oder sie schaltet sich von selbst um. Den Domainnamen im DNS umzuschreiben geh\u00f6rt ebenfalls dazu. Das Problem ist, dass bei einem derartigen Projektversagen Panik ausbricht, und selbst die st\u00e4rksten, erfahrensten Administratoren k\u00f6nnen davon betroffen sein. Ohne eine klare Anleitung \u201e\u00d6ffnen Sie das Terminal, gehen Sie hierhin, die Adresse unseres Servers bleibt die gleiche\u201c ist es schwierig, die 5 Minuten, die f\u00fcr die Wiederherstellung vorgesehen sind, einzuhalten. Und dazu kommt, dass es einfach ist, einige \u00c4nderungen in der Infrastruktur zu fixieren, w\u00e4hrend wir diese Vorschrift verwenden, beispielsweise \u2014 und die Vorschrift entsprechend zu \u00e4ndern.
\nNa ja, und wenn das Reservierungssystem sehr komplex ist und wir an einem bestimmten Punkt einen Fehler gemacht haben, k\u00f6nnen wir auch unser Backup-System au\u00dfer Gefecht setzen und dar\u00fcber hinaus die Daten auf beiden Plattformen verderben \u2013 das w\u00e4re wirklich traurig. <\/p>\n

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

Beispiel Nummer f\u00fcnf, v\u00f6lliger Hardcore.<\/h4>\n

\nEin internationaler Service mit Hunderten Millionen Nutzern weltweit. Alle Zeitzonen, die es gibt, Highload auf maximalem Niveau, darf absolut nicht ausfallen. Eine Minute \u2013 und es wird traurig. Was tun? Wieder vollst\u00e4ndig reservieren. Wir haben alles getan, was im vorherigen Beispiel erw\u00e4hnt wurde, und noch ein bisschen mehr. Eine ideale Welt, und unsere Infrastruktur \u2013 sie ist in jeder Hinsicht DevOps IaaC. Das hei\u00dft, alles ist in git, und man muss nur einen Knopf dr\u00fccken. <\/p>\n

Was fehlt? Einzig unser Training. Ohne das geht es nicht. Es scheint, als w\u00e4re bei uns alles perfekt, wir haben wirklich alles unter Kontrolle. Wir dr\u00fccken den Knopf, alles passiert. Selbst wenn es so ist \u2013 und wir wissen, dass es so nicht sein kann \u2013 interagiert unser System mit anderen Systemen. Zum Beispiel mit DNS von Route 53, S3-Speichersystemen oder der Integration mit bestimmten APIs. Alles in diesem gedanklichen Experiment vorherzusehen, ist uns nicht m\u00f6glich. Und solange wir nicht wirklich den Hebel umlegen \u2013 werden wir nicht wissen, ob es funktioniert oder nicht. <\/p>\n

\"Failover:
\n
\nDas w\u00e4re wohl alles. Seien Sie flei\u00dfig und \u00fcbertreiben Sie es nicht. M\u00f6ge der Uptime mit Ihnen sein!
\n
Quelle: 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: Perfektionismus und\u2026 Faulheit bringen uns um | ProHoster","description":"Im Sommer nimmt traditionell sowohl die K\u00e4uferaktivit\u00e4t als auch die Intensit\u00e4t der \u00c4nderungen in der Infrastruktur von Webprojekten ab, sagt uns Captain Obvious. Ganz einfach, weil selbst ITler manchmal in den Urlaub fahren.","canonical_url":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"de_DE","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\/de\/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\/de\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/de\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}