{"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\/no\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: perfeksjonisme og\u2026 latskap \u00f8delegger oss","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Om sommeren synker tradisjonelt b\u00e5de kj\u00f8psaktiviteten og intensiteten av endringer i infrastrukturen for webprosjekter, forteller oss Kaptein \u00c5penbaring. Bare fordi selv IT-folk, som det hender, g\u00e5r p\u00e5 ferie. Og CTO-er ogs\u00e5. Det er tyngre for dem som blir igjen p\u00e5 posten, men det er ikke det vi snakker om n\u00e5: kanskje er det derfor sommeren er den beste perioden for \u00e5 i ro og mak overveie den eksisterende reservel\u00f8sningen og lage en plan for \u00e5 forbedre den. Og erfaringen til Egor Andreev fra AdminDivision<\/a><\/noindex>, som han delte p\u00e5 konferansen Uptime day<\/a><\/noindex>.<\/i><\/p>\n

N\u00e5r vi bygger reservedatasteder, er det flere feller som man kan falle i. Og det er helt uakseptabelt \u00e5 gj\u00f8re det. Det som \u00f8delegger oss i dette, som i mye annet, er perfeksjonisme og\u2026 latskap. Vi pr\u00f8ver \u00e5 gj\u00f8re alt helt perfekt, men det er ikke n\u00f8dvendig \u00e5 gj\u00f8re alt perfekt! Det er bare n\u00f8dvendig \u00e5 gj\u00f8re visse ting, men gj\u00f8re dem riktig, fullf\u00f8re dem slik at de fungerer som de skal. <\/p>\n

Failover er ikke bare en morsom ting \u00abbare for moro skyld\u00bb; det er noe som skal gj\u00f8re \u00e9n ting \u2014 redusere nedetid, slik at tjenesten og selskapet taper mindre penger. Og i alle metoder for reservasjoner foresl\u00e5r jeg \u00e5 tenke i f\u00f8lgende kontekst: hvor er pengene?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nDen f\u00f8rste fellen<\/b>: N\u00e5r vi bygger store, p\u00e5litelige systemer og jobber med reservasjon \u2014 reduserer vi antallet uhell. Dette er en skremmende misforst\u00e5else. N\u00e5r vi jobber med reservasjoner, \u00f8ker vi sannsynligvis antallet uhell. Og hvis vi gj\u00f8r alt riktig, vil vi totalt redusere nedetiden. Det vil bli flere uhell, men de vil skje med mindre kostnader. For hva er reservasjon? \u2014 det er en komplisering av systemet. Enhver komplisering er d\u00e5rlig: vi f\u00e5r flere skruer, flere tannhjul, med andre ord, flere elementer \u2014 og dermed h\u00f8yere sjanse for feil. Og de vil faktisk g\u00e5 i stykker. Og de vil g\u00e5 i stykker oftere. Et enkelt eksempel: si at vi har et nettsted, med PHP, MySQL. Og det m\u00e5 haste reserveres. <\/p>\n

Vel, vi tar den andre plattformen og bygger et identisk system... Kompleksiteten dobles \u2014 vi har to enheter. Og i tillegg implementerer vi en viss logikk for dataoverf\u00f8ring fra den ene plattformen til den andre \u2014 det vil si databasering, kopiering av statiske ressurser, og s\u00e5 videre. S\u00e5, logikken for replikering \u2014 den er vanligvis veldig kompleks, og dermed kan den samlede kompleksiteten i systemet v\u00e6re ikke bare 2, men 3, 5, 10 ganger mer. <\/p>\n

Den andre fella<\/b>: n\u00e5r vi bygger virkelig store, komplekse systemer, liker vi \u00e5 fantasere om hva vi \u00f8nsker \u00e5 oppn\u00e5 til slutt. Voil\u00e0: vi \u00f8nsker \u00e5 skape et superp\u00e5litelig system som fungerer uten nedetid, som kan veksle over p\u00e5 et halvt sekund (eller enda bedre, helt umiddelbart), og vi begynner \u00e5 realisere dr\u00f8mmer. Men her er det ogs\u00e5 en nyanse: jo kortere \u00f8nsket vekselverdi er, desto mer kompleks blir logikken i systemet. Jo mer komplisert logikken m\u00e5 v\u00e6re, jo oftere vil systemet bryte sammen. Og man kan havne i en veldig uheldig situasjon: vi pr\u00f8ver med alle midler \u00e5 redusere nedetiden, men vi gj\u00f8r det bare mer komplisert, og n\u00e5r noe g\u00e5r galt, blir nedetiden i stedet lengre. Her fanger man seg selv med tanken: det ville v\u00e6rt bedre om vi ikke hadde reservert. Det ville v\u00e6rt bedre om det leverte \u00e9n gang og med forst\u00e5elig nedetid. <\/p>\n

Hvordan kan vi kjempe mot dette? Vi m\u00e5 slutte \u00e5 lyve for oss selv, slutte \u00e5 skryte av at vi n\u00e5 skal bygge romskip, men i stedet realistisk forst\u00e5 hvor lenge prosjektet kan vare. Og i henhold til denne maksimale tiden, vil vi velge hvilke metoder vi vil bruke for \u00e5 \u00f8ke p\u00e5liteligheten til systemet v\u00e5rt. <\/p>\n

\"Failover:
\n
\nDet er p\u00e5 h\u00f8y tid for 'historier fra livet'... fra virkeligheten, selvsagt. <\/p>\n

Eksempel nummer \u00e9n<\/h4>\n

\nTenk p\u00e5 et digitalt visittkort for r\u00f8rfabrikk nr. 1 i byen N. Det st\u00e5r med store bokstaver \u2014 R\u00d8RFABRIKK NR. 1. Litt lenger ned er slagordet: \u00abR\u00f8rene v\u00e5re er de mest runde r\u00f8rene i N\u00bb. Og nederst st\u00e5r telefonnummeret til direkt\u00f8ren og navnet hans. Vi forst\u00e5r at det er viktig \u00e5 reservere \u2014 det er jo en veldig viktig ting! La oss begynne \u00e5 finne ut av hva det best\u00e5r av. Html-statiske filer \u2014 det vil si et par bilder der direkt\u00f8ren sitter ved bordet i badstuen med sin partner og diskuterer en ny avtale. Vi begynner \u00e5 tenke p\u00e5 nedetid. Det kommer til hodet v\u00e5rt: vi m\u00e5 v\u00e6re der i fem minutter, ikke mer. Og s\u00e5 sp\u00f8rsm\u00e5let: hvor mange salg har vi gjort fra denne nettsiden? Hvor mange? Hva mener du med \u00abnull\u00bb? Vel, det betyr at alle fire avtalene fra i fjor ble gjort ved samme bord med de samme folkene som de g\u00e5r i badstuen med. Vi forst\u00e5r at selv om nettsiden ligger nede en dag, vil det ikke v\u00e6re s\u00e5 farlig. <\/p>\n

Basert p\u00e5 informasjonen, har vi en dag til \u00e5 f\u00e5 dette p\u00e5 plass. Vi begynner \u00e5 tenke p\u00e5 reservasjonsordningen. Og vi velger den ideelle reservasjonsl\u00f8sningen for dette eksempelet: vi bruker ikke reservasjon. Hele denne greia kan settes opp av hvilken som helst administrator p\u00e5 en halvtime, med pauser. Installere webserveren, legge inn filene \u2014 ferdig. Det vil fungere. Ingenting m\u00e5 overv\u00e5kes, ingenting trenger spesiell oppmerksomhet. Alts\u00e5 er konklusjonen fra eksempel nummer \u00e9n ganske \u00e5penbar: tjenester som ikke trenger \u00e5 reserveres \u2014 trenger ikke \u00e5 reserveres.<\/p>\n

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

Eksempel nummer to<\/h4>\n

\nSelskapet sin blogg: spesialutdannede skriver nyheter der, for eksempel deltok vi p\u00e5 en utstilling eller lanserte et nytt produkt, og s\u00e5 videre. La oss si at dette er standard PHP med WordPress, en liten database og litt statisk innhold. Man tenker selvf\u00f8lgelig igjen at man ikke m\u00e5 ligge stille \u2014 \u00abikke mer enn fem minutter!\u00bb, alt det der. Men la oss tenke videre. Hva gj\u00f8r egentlig denne bloggen? Det kommer folk fra Yandex og Google via forskjellige s\u00f8k, organisk trafikk. Bra. Men er salg p\u00e5 noen m\u00e5te knyttet til den? \u00c5penbaring: ikke egentlig. Annonsetrafikken g\u00e5r til hovedsiden, som ligger p\u00e5 en annen maskin. Vi begynner \u00e5 tenke p\u00e5 reserverytmetoden for bloggen. I utgangspunktet m\u00e5 den heves p\u00e5 et par timer, og det ville v\u00e6rt nyttig \u00e5 forberede seg til dette. Det ville v\u00e6re fornuftig \u00e5 ta en maskin i et annet datasenter, sette opp et milj\u00f8, det vil si webserver, PHP, WordPress, MySQL, og la det st\u00e5 der, skrudd av. I det \u00f8yeblikket vi innser at alt har krasjet, m\u00e5 vi gj\u00f8re to ting \u2014 gjenopprette en mysql-dump p\u00e5 50 megabyte, som g\u00e5r p\u00e5 under et minutt, og gjenopprette et antall bilder fra backupen. Det er heller ikke s\u00e5 mye. Dermed kan hele systemet heves p\u00e5 en halv time. Ingen replikering, eller beklager, automatisk failover. Konklusjon: det vi raskt kan gjenopprette fra backup, trenger ikke \u00e5 v\u00e6re reservert. <\/p>\n

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

Eksempel nummer tre, litt mer komplisert<\/h4>\n

\nNettbutikk. PHP med litt modifisert open heart, MySQL med en solid database. Ganske mye statisk innhold (for en nettbutikk har vi jo fine HD-bilder og alt det der), Redis for sesjoner og Elasticsearch for s\u00f8k. Vi begynner \u00e5 tenke p\u00e5 nedetid. Og her er det \u00e5penbart at nettbutikken ikke kan v\u00e6re ute av drift en hel dag uten alvorlige konsekvenser. Jo lenger den er nede, desto mer penger taper vi. Det er p\u00e5 tide \u00e5 handle. Men hvor mye? Jeg tror at hvis vi er nede i en time, vil ingen g\u00e5 fra forstanden. Ja, vi mister noe, men hvis vi begynner \u00e5 stresse \u2014 vil det bare bli verre. Vi definerer tolerant nedetid, tillatt pr. time.<\/p>\n

Hvordan kan alt dette reserveres? En maskin er n\u00f8dvendig uansett: en time er ganske lite. Mysql: her trenger vi replikasjon, levende replikasjon, fordi 100 GB i dump mest sannsynlig ikke vil v\u00e6re mulig \u00e5 overf\u00f8re p\u00e5 en time. Statikk, bilder: igjen, p\u00e5 en time kan 500 GB ikke rekke \u00e5 lastes opp. Derfor er det best \u00e5 begynne \u00e5 kopiere bildene med en gang. Redis: her blir det mer interessant. I Redis ligger sesjoner \u2014 vi kan ikke bare ta det og begrave det. For det vil ikke v\u00e6re bra: alle brukere vil bli logget ut, handlekurvene vil bli t\u00f8mt, og s\u00e5 videre. Folk m\u00e5 tvinges til \u00e5 skrive inn brukernavn og passord p\u00e5 nytt, og mange kan bli borte og ikke fullf\u00f8re kj\u00f8pet. Igjen, konverteringen vil falle. P\u00e5 den annen side, Redis er helt aktuell, med de sist p\u00e5loggede brukerne, kanskje det heller ikke er n\u00f8dvendig. En god kompromiss er \u00e5 ta Redis og gjenopprette det fra en backup, fra i g\u00e5r, eller, hvis det blir gjort hver time, fra en time siden. Heldigvis er gjenopprettingen fra backup ganske enkelt en kopiering av \u00e9n fil. Den mest interessante historien er Elasticsearch. Hvem har noen gang satt opp MySQL-replikasjon? Hvem har noen gang satt opp Elasticsearch-replikasjon? Og hvem har hatt den til \u00e5 fungere ordentlig etterp\u00e5? Jeg mener: vi ser en viss enhet i systemet v\u00e5rt. Den virker nyttig \u2014 men den er komplisert.
\nVanskelig i den forstand at v\u00e5re ingeni\u00f8rkolleger ikke har erfaring med det. Enten har de hatt negative erfaringer, eller s\u00e5 forst\u00e5r vi at dette fortsatt er en ganske ny teknologi med nyanser eller ufullkommenheter. Vi tenker... Herregud, Elastic er ogs\u00e5 stort, det tar lang tid \u00e5 gjenopprette fra backup, hva gj\u00f8r vi? Vi forst\u00e5r at Elastic i v\u00e5rt tilfelle brukes til s\u00f8k. Hvordan selger nettbutikken v\u00e5r? Vi g\u00e5r til markedsf\u00f8rerne og sp\u00f8r hvor folk kommer fra. De svarer: \"90% kommer fra Yandex-markedet direkte til produktsiden.\" Og enten kj\u00f8per de, eller s\u00e5 gj\u00f8r de ikke. Dermed er s\u00f8k n\u00f8dvendig for 10% av brukerne. Og \u00e5 opprettholde replikeringen av Elastic, spesielt mellom forskjellige datasentre i ulike soner, inneb\u00e6rer faktisk mange nyanser. Hva er l\u00f8sningen? Vi tar Elastic p\u00e5 en reservert plattform og gj\u00f8r ingenting med det. Hvis det drar ut, vil vi kanskje heve det senere, men det er ikke sikkert. Egentlig er konklusjonen stort sett den samme: tjenester som ikke p\u00e5virker inntektene, reservert vi ikke. For \u00e5 holde ordningen enklere.<\/p>\n

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

Eksempel nummer fire, enda vanskeligere.<\/h4>\n

\nIntegrator: salg av blomster, bestilling av taxi, salg av varer, kort sagt, hva som helst. En seri\u00f8s greie som fungerer 24\/7 for et stort antall brukere. Med en fullverdig interessant teknologistack, hvor det er spennende databaser, l\u00f8sninger, h\u00f8y belastning, og viktigst av alt, den b\u00f8r ikke v\u00e6re nede i mer enn 5 minutter. Ikke bare fordi folk ikke kj\u00f8per, men fordi de vil se at denne tingen ikke fungerer, bli frustrert og kanskje ikke komme tilbake igjen. <\/p>\n

Greit. Fem minutter. Hva skal vi gj\u00f8re med dette? I dette tilfellet bygger vi seri\u00f8st, for alle penger, en ekte reserveplass, med replikasjon av alt og alle, og muligens automatiserer vi ogs\u00e5 overgangen til denne plassen. Og i tillegg til dette er det viktig \u00e5 huske p\u00e5 \u00e9n ting: \u00e5 faktisk skrive en bytteprosess. Prosedyren, selv om alt er automatisert, kan v\u00e6re veldig enkel. Av typen \"kj\u00f8r dette ansible-scenarioet\", \"trykk p\u00e5 den aktuelle avmerkingsboksen i route 53\", osv.\u2014 men det m\u00e5 v\u00e6re en presis liste over handlingene. <\/p>\n

Og det virker som om alt er klart. \u00c5 bytte replikasjon er en triviel oppgave, eller s\u00e5 kan den bytte seg selv. \u00c5 skrive domene navnet inn i DNS er av samme sjanger. Problemet er at n\u00e5r et slikt prosjekt faller, begynner panikken, og selv de sterkeste, erfarne administratorene kan bli rammet av den. Uten en klar instruksjon \"\u00e5pne terminalen, g\u00e5r hit, adressen til serveren v\u00e5r er fortsatt slik\" er det vanskelig \u00e5 holde tidsrammen p\u00e5 5 minutter for gjenoppretting. Og i tillegg, n\u00e5r vi bruker denne reguleringen, er det lett \u00e5 fikse endringer i infrastrukturen, for eksempel, og endre reguleringen deretter.
\nMen, hvis reservasjons-systemet er veldig komplisert og vi p\u00e5 et tidspunkt gjorde en feil, kan vi ogs\u00e5 legge ned v\u00e5rt backup-sted, og i tillegg kan dataene bli til gresskar p\u00e5 begge steder \u2014 det ville v\u00e6rt ganske trist. <\/p>\n

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

Eksempel nummer fem, hardcore.<\/h4>\n

\nInternasjonal tjeneste med hundre millioner brukere over hele verden. Alle tidssoner, som finnes, highload p\u00e5 maks, kan ikke v\u00e6re nede i det hele tatt. Ett minutt \u2014 og det blir trist. Hva gj\u00f8r vi? Vi reserverer, igjen, fullt ut. Vi gjorde alt jeg snakket om i forrige eksempel, og litt mer. Den ideelle verden, og v\u00e5r infrastruktur \u2014 den er i henhold til alle definisjoner av devops IaaC. Det vil si at alt er i git, og du m\u00e5 bare trykke p\u00e5 knappen. <\/p>\n

Hva mangler? En ting \u2014 \u00f8velser. Uten dem kan vi ikke. Det ser ut til at alt er perfekt, vi har alt under kontroll. Vi trykker p\u00e5 knappen, alt skjer. Selv om det er slik \u2014 og vi forst\u00e5r at det ikke alltid er slik \u2014 v\u00e5rt system interagerer med andre systemer. For eksempel, dette er DNS fra route 53, s3-lagring, integrasjon med noen API-er. Vi kan ikke forutse alt i dette hypotetiske eksperimentet. Og f\u00f8r vi faktisk drar i str\u00f8mbryteren \u2014 vil vi ikke vite om det fungerer eller ikke. <\/p>\n

\"Failover:
\n
\nDet er vel alt. Ikke v\u00e6r lat, og ikke overdriv. Og m\u00e5tte uptime v\u00e6re med dere!
\n
Kilde: 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\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: Perfeksjonisme og... latskap vil \u00f8delegge oss | ProHoster","description":"Om sommeren reduseres b\u00e5de kj\u00f8psaktiviteten og intensiteten av endringene i infrastrukturen til webprosjekter, sier Kaptein \u00c5penbaring. Bare fordi selv IT-folk av og til g\u00e5r p\u00e5 ferie.","canonical_url":"https:\/\/prohoster.info\/no\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"nn_NO","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\/no\/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\/no\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/no\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}