{"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\/it\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: ci soffoca il perfezionismo e\u2026 la pigrizia","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

D'estate tradizionalmente diminuisce sia l'attivit\u00e0 degli acquirenti che l'intensit\u00e0 dei cambiamenti infrastrutturali dei progetti web, ci dice Capitan Evidente. Semplicemente perch\u00e9 anche gli informatici, a volte, vanno in vacanza. E anche i CTO. Pi\u00f9 difficile per chi resta al lavoro, ma ora non \u00e8 di questo che vogliamo parlare: forse \u00e8 proprio per questo che l'estate \u00e8 il periodo migliore per riflettere con calma sul sistema di riservazione esistente e pianificare il suo miglioramento. E in questo ti sar\u00e0 utile l'esperienza di Egor Andreev di AdminDivision<\/a><\/noindex>, di cui ha parlato alla conferenza Uptime day<\/a><\/noindex>.<\/i><\/p>\n

Nella costruzione di aree di riserva, ci sono diverse trappole in cui \u00e8 facile cadere. E cadere in esse \u00e8 assolutamente da evitare. E ci\u00f2 che ci rovina in tutto questo, cos\u00ec come in molte altre cose, \u00e8 il perfezionismo e... la pigrizia. Cerchiamo di fare tutto, tutto, tutto in modo perfetto, ma non dobbiamo farlo in modo perfetto! Dobbiamo solo fare determinate cose, ma farle nel modo giusto, portarle a termine, affinch\u00e9 funzionino correttamente. <\/p>\n

Il failover non \u00e8 una cosa divertente o un gadget 'giusto per avere'; \u00e8 qualcosa che deve fare esattamente una cosa: ridurre il tempo di inattivit\u00e0, affinch\u00e9 il servizio, l'azienda, perda meno soldi. E in tutti i metodi di riservazione, propongo di pensare nel seguente contesto: dove ci sono i soldi?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nLa prima trappola<\/b>: quando costruiamo grandi sistemi affidabili e ci occupiamo di riservazione, riduciamo il numero di guasti. Questo \u00e8 un terribile malinteso. Quando ci occupiamo di riservazione, il numero di guasti, molto probabilmente, aumenta. E se facciamo tutto correttamente, complessivamente ridurremo il tempo di inattivit\u00e0. Ci saranno pi\u00f9 guasti, ma si verificheranno con minori conseguenze. Infatti, cos'\u00e8 la riservazione? \u2014 \u00e8 un complicamento del sistema. Qualsiasi complicazione \u00e8 negativa: abbiamo pi\u00f9 viti, pi\u00f9 ingranaggi, insomma, pi\u00f9 elementi \u2014 e, di conseguenza, maggior rischio di rottura. E si romperanno davvero. E si romperanno pi\u00f9 frequentemente. Un semplice esempio: supponiamo di avere un certo sito web, con PHP, MySQL. E deve essere urgentemente riservato. <\/p>\n

Dunque (c) Prendiamo un secondo ambiente, costruiamo un sistema identico... La complessit\u00e0 raddoppia: abbiamo due entit\u00e0. E in pi\u00f9 sovrapporremo una logica specifica per il trasferimento dei dati da un ambiente all'altro, ossia la replica dei dati, la copia della statica e cos\u00ec via. Ecco, la logica di replica \u00e8 solitamente molto complessa, e quindi la complessit\u00e0 complessiva del sistema pu\u00f2 essere non 2, ma 3, 5, 10 volte maggiore. <\/p>\n

Il secondo tranello<\/b>: quando costruiamo sistemi veramente grandi e complessi, fantastichiamo su cosa vogliamo ottenere alla fine. Voil\u00e0: vogliamo un sistema super affidabile, che funzioni senza alcun tempo di inattivit\u00e0, che faccia il switch in mezzo secondo (meglio ancora, immediatamente), e iniziamo a trasformare i sogni in realt\u00e0. Ma c'\u00e8 anche un aspetto da considerare: minore \u00e8 il tempo di switch desiderato, pi\u00f9 complessa diventa la logica del sistema. Pi\u00f9 sar\u00e0 complessa questa logica, pi\u00f9 frequentemente il sistema avr\u00e0 problemi. E si pu\u00f2 cadere in una situazione molto spiacevole: ci sforziamo di ridurre il tempo di inattivit\u00e0, ma in realt\u00e0 stiamo complicando tutto, cos\u00ec quando qualcosa va storto, il tempo di inattivit\u00e0 alla fine sar\u00e0 maggiore. Qui ti sorprendi a pensare: beh... sarebbe stato meglio non avere riserve. Sarebbe stato meglio che funzionasse uno solo con un tempo di inattivit\u00e0 chiaro. <\/p>\n

Come possiamo combattere tutto questo? Dobbiamo smettere di mentire a noi stessi, smettere di compiacere noi stessi dicendo che stiamo costruendo un razzo spaziale, ma comprendere realisticamente quanto tempo il progetto pu\u00f2 rimanere inattivo. E in base a questo tempo massimo sceglieremo quali metodi utilizzare per aumentare l'affidabilit\u00e0 del nostro sistema. <\/p>\n

\"Failover:
\n
\n\u00c8 il momento per \"storie dalla vita\"... dalla vita reale, naturalmente. <\/p>\n

Esempio numero uno<\/h4>\n

\nImmaginate un sito di presentazione della fabbrica di tubi n. 1 della citt\u00e0 di N. Su di esso \u00e8 scritto a caratteri giganti: FABBRICA DI TUBI N. 1. Poco pi\u00f9 in basso, lo slogan: \u00abI nostri tubi sono i tubi pi\u00f9 rotondi di N\u00bb. E in fondo, il numero di telefono del direttore generale e il suo nome. Comprendiamo che \u00e8 necessario prenotare\u2014\u00e8 una questione molto importante! Iniziamo a capire di cosa si tratta. Statico HTML\u2014cio\u00e8 una coppia di immagini, dove il direttore, in realt\u00e0, \u00e8 seduto al tavolo in sauna con il suo partner a discutere qualche affare imminente. Iniziamo a pensare al tempo di inattivit\u00e0. Viene in mente: \u00e8 necessario restare l\u00ec per cinque minuti, non di pi\u00f9. E qui la domanda: quante vendite sono state fatte tramite questo nostro sito? Quante? Cosa significa \u00abzero\u00bb? Questo significa: perch\u00e9 tutte e quattro le transazioni dello scorso anno il direttore le ha fatte allo stesso tavolo, con le stesse persone, con cui vanno in sauna a sedere al tavolo. E comprendiamo che anche se il sito rimane inattivo per un giorno, non succeder\u00e0 niente di grave. <\/p>\n

In base alle informazioni fornite, abbiamo un giorno per alzare questa situazione. Iniziamo a pensare a uno schema di prenotazione. E scegliamo lo schema di prenotazione pi\u00f9 ideale per questo esempio: non utilizziamo la prenotazione. Tutta questa cosa pu\u00f2 essere attivata da qualsiasi amministratore in mezz'ora con una pausa caff\u00e8. Installare un server web, caricare i file\u2014\u00e8 tutto. Funzioner\u00e0. Non \u00e8 necessario monitorare nulla, non c'\u00e8 nulla a cui prestare particolare attenzione. Quindi, la conclusione dall'esempio numero uno \u00e8 piuttosto ovvia: i servizi che non necessitano di prenotazione\u2014non necessitano di prenotazione.<\/p>\n

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

Esempio numero due<\/h4>\n

\nBlog dell'azienda: specializzati scrivono notizie al riguardo, ad esempio abbiamo partecipato a una certa fiera, oppure abbiamo lanciato un nuovo prodotto, e cos\u00ec via. Diciamo che si tratta di un PHP standard con WordPress, un piccolo database e un po' di statico. Naturalmente, torna subito in mente che non possiamo lasciarlo inattivo \u2014 \"non pi\u00f9 di cinque minuti!\", e tutto il resto. Ma riflettiamo oltre. Cosa fa questo blog? Riceve visitatori da Yandex, da Google attraverso certe ricerche, dal traffico organico. Ottimo. E le vendite sono in qualche modo collegate a questo? Rivelazione: non molto. Il traffico pubblicitario va al sito principale, che si trova su un'altra macchina. Iniziamo a pensare a uno schema di riserva per il blog. Idealmente, dovrebbe essere riavviato in poche ore, e sarebbe bene prepararsi a questo. Sarebbe saggio prendere una macchina in un altro data center, installare l\u00ec l'ambiente, cio\u00e8 il web server, PHP, WordPress, MySQL, e lasciarlo inattivo. Nel momento in cui ci rendiamo conto che tutto \u00e8 rotto, dobbiamo fare due cose: ripristinare un dump di MySQL di 50 megabyte, che arriver\u00e0 in un minuto, e ripristinare un certo numero di immagini dal backup. Questo richieder\u00e0 anch'esso poco tempo. In questo modo, in mezz'ora tutta questa cosa sar\u00e0 attiva. Niente replicazioni, o peggio, failover automatico. Conclusione: ci\u00f2 che possiamo ripristinare rapidamente dal backup non necessita di riserva. <\/p>\n

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

Esempio numero tre, un po' pi\u00f9 complesso<\/h4>\n

\nNegozio online. PhP con open heart leggermente modificato, MySQL con un database solido. Abbastanza statico (dopotutto, nei negozi online ci sono belle immagini HD e tutto il resto), Redis per le sessioni e Elasticsearch per la ricerca. Cominciamo a pensare al tempo di inattivit\u00e0. E qui, naturalmente, \u00e8 chiaro che un giorno senza problemi il negozio online non pu\u00f2 rimanere inattivo. Infatti, pi\u00f9 a lungo rimane inattivo, pi\u00f9 soldi perdiamo. \u00c8 tempo di accelerare. E di quanto? Credo che se rimaniamo inattivi per un'ora, nessuno impazzir\u00e0. S\u00ec, perderemo qualcosa, ma inizieremo a sforzarci \u2014 peggiorer\u00e0 solo. Determiniamo il piano di inattivit\u00e0 accettabile in un'ora.<\/p>\n

Come si pu\u00f2 prenotare tutto questo? L'auto \u00e8 necessaria in ogni caso: un'ora di tempo \u00e8 piuttosto poco. Mysql: qui \u00e8 necessaria una replica, una replica live, perch\u00e9 in un'ora 100 GB in un dump probabilmente non ci staranno. Statico, immagini: di nuovo, in un'ora 500 GB potrebbero non riuscire a entrare. Pertanto, \u00e8 meglio copiare subito le immagini. Redis: qui \u00e8 pi\u00f9 interessante. In Redis ci sono le sessioni \u2014 non possiamo semplicemente prenderlo e distruggerlo. Perch\u00e9 non sarebbe una cosa molto positiva: tutti gli utenti si troverebbero disconnessi, i carrelli svuotati e cos\u00ec via. Le persone sarebbero costrette a reinserire il proprio login e la propria password, e molte persone potrebbero allontanarsi e non completare l'acquisto. Inoltre, la conversione diminuirebbe. D'altra parte, Redis \u00e8 davvero aggiornato, con gli ultimi utenti collegati, probabilmente non \u00e8 nemmeno necessario. E un buon compromesso sarebbe prendere Redis e ripristinarlo da un backup, di ieri, oppure, se \u00e8 fatto ogni ora, di un'ora fa. Fortunatamente, ripristinarlo da un backup significa copiare un file. La storia pi\u00f9 interessante \u00e8 Elasticsearch. Chi ha mai attivato la replica di MySQL? Chi ha mai attivato la replica di Elasticsearch? E a chi ha mai funzionato bene dopo? A cosa mi riferisco: vediamo nella nostra sistema una certa entit\u00e0. Sembra utile, ma \u00e8 complessa.
\n\u00c8 complicato nel senso che i nostri colleghi ingegneri non hanno esperienza con esso. Oppure hanno avuto esperienze negative. O capiamo che \u00e8 una tecnologia ancora nuova con sfumature o problemi. Pensiamo... Accidenti, anche Elastic \u00e8 pesante, ci vuole molto tempo per ripristinarlo da un backup, cosa facciamo? Capisco che Elastic in questo nostro caso viene utilizzato per la ricerca. E come vende il nostro negozio online? Andiamo dai marketer, chiediamo da dove arriva la gente. Loro rispondono: \"Il 90% arriva direttamente dalle schede prodotto di Yandex Market.\" E o comprano, o no. Di conseguenza, la ricerca \u00e8 necessaria per il 10% degli utenti. E mantenere la replica di Elastic, specialmente tra diversi data center in diverse zone, presenta davvero molte complessit\u00e0. Qual \u00e8 la soluzione? Prendiamo Elastic su una piattaforma riservata e non facciamo nulla con esso. Se ci vorr\u00e0 tempo, potremmo eventualmente alzarlo, ma non \u00e8 sicuro. In sostanza, la conclusione \u00e8 pi\u00f9 o meno la stessa: i servizi che non influiscono sui soldi, di nuovo, non li riserviamo. Affinch\u00e9 lo schema rimanga pi\u00f9 semplice.<\/p>\n

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

Esempio numero quattro, ancora pi\u00f9 complicato<\/h4>\n

\nIntegratore: vendite di fiori, chiamate di taxi, vendite di prodotti, insomma, di tutto. Una cosa seria che funziona 24\/7 per un grande numero di utenti. Con un stack interessante e completo, dove ci sono database interessanti, soluzioni, carichi elevati, e la cosa pi\u00f9 importante \u00e8 che rimanere inattiva per pi\u00f9 di 5 minuti \u00e8 doloroso. Non solo perch\u00e9 la gente non comprer\u00e0, ma perch\u00e9 le persone vedranno che questa cosa non funziona, si sentiranno deluse e potrebbero non tornare mai pi\u00f9. <\/p>\n

Ok. Cinque minuti. Cosa faremo al riguardo? In questo caso, ci comportiamo in modo maturo, investiamo realmente in una vera piattaforma di riserva, con replica di tutto e di pi\u00f9, e forse anche automatizziamo il passaggio a questa piattaforma al massimo. E in aggiunta a questo, non dobbiamo dimenticare di fare una cosa importante: scrivere il regolamento per il passaggio. Il regolamento, anche se avete automatizzato tutto, pu\u00f2 essere molto semplice. Del tipo \"eseguire questo particolare scenario ansible\", \"cliccare quella casella in route 53\" e cos\u00ec via\u2014ma deve essere un elenco preciso di azioni. <\/p>\n

E sembra tutto chiaro. Passare la replicazione \u00e8 un compito triviale, oppure si switcha da solo. Riscrivere il nome di dominio nel DNS \u00e8 della stessa serie. Il problema \u00e8 che quando un progetto del genere fallisce, inizia il panico, e anche gli amministratori pi\u00f9 esperti e pi\u00f9 navigati possono esserne colpiti. Senza un'istruzione chiara \"apri il terminale, accedi qui, l'indirizzo del nostro server \u00e8 ancora questo\" \u00e8 difficile rispettare i 5 minuti concessi per la rianimazione. In aggiunta, quando utilizziamo questo regolamento, \u00e8 facile registrare eventuali modifiche nell'infrastruttura, ad esempio, e modificare il regolamento di conseguenza.
\nE se il sistema di backup \u00e8 molto complesso e in un certo momento abbiamo commesso un errore, potremmo compromettere anche il nostro sito di riserva, e in aggiunta i dati diventerebbero inutilizzabili su entrambi i siti \u2014 sarebbe davvero triste. <\/p>\n

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

Esempio numero cinque, hardcore completo<\/h4>\n

\nUn servizio internazionale con centinaia di milioni di utenti in tutto il mondo. Tutti i fusi orari, il massimo del highload, non ci si pu\u00f2 permettere di essere gi\u00f9. Un minuto \u2014 e sar\u00e0 triste. Cosa fare? Riservare, soprattutto, a regola d'arte. Abbiamo fatto tutto ci\u00f2 di cui ho parlato nell'esempio precedente, e anche qualcosina di pi\u00f9. Un mondo ideale, e la nostra infrastruttura \u00e8, per tutti i versi, DevOps IaaC. Cio\u00e8, tutto \u00e8 in git, e basta premere un pulsante. <\/p>\n

Cosa manca? Una cosa: esercitazioni. Senza di esse non \u00e8 possibile. Sembra che tutto sia perfetto, e che abbiamo tutto sotto controllo. Premi un pulsante, tutto si verifica. Anche se fosse cos\u00ec \u2014 e sappiamo che cos\u00ec non \u00e8 \u2014 il nostro sistema interagisce con altri sistemi. Per esempio, c'\u00e8 il DNS di Route 53, gli archivi S3, l'integrazione con alcune API. Non possiamo prevedere tutto in questo esperimento teorico. E finch\u00e9 non tireremo fisicamente la leva non sapremo se funzioner\u00e0 o meno. <\/p>\n

\"Failover:
\n
\nProbabilmente \u00e8 tutto. Non siate pigri e non esagerate. Che la disponibilit\u00e0 sia con voi!
\n
Fonte: 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: ci rovina il perfezionismo e... la pigrizia | ProHoster","description":"In estate, tradizionalmente diminuiscono sia l'attivit\u00e0 dei consumatori che l'intensit\u00e0 delle modifiche all'infrastruttura dei progetti web, ci dice il Capitano Ovvio. Semplicemente perch\u00e9 anche gli informatici, a volte, vanno in vacanza.","canonical_url":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"it_IT","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\/it\/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\/it\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/it\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}