{"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\/da\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: perfektionisme og\u2026 dovenskab \u00f8del\u00e6gger os","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Om sommeren falder b\u00e5de k\u00f8bsaktivitet og intensiteten af \u00e6ndringer i infrastrukturen for webprojekter, fort\u00e6ller Captain Obvious os. Bare fordi selv it-folk, sker der, g\u00e5r p\u00e5 ferie. Og CTO'er ogs\u00e5. Det g\u00f8r det sv\u00e6rere for dem, der bliver p\u00e5 posten, men det handler ikke om det nu; muligvis er det derfor, at sommeren er den bedste tid til at tage sig tid til at overveje den eksisterende backup-ordning og lave en plan for at forbedre den. Og her kan du have gavn af erfaringen fra Yegor Andreev fra AdminDivision<\/a><\/noindex>, som han delte p\u00e5 konferencen Uptime dag<\/a><\/noindex>.<\/i><\/p>\n

N\u00e5r vi bygger backup-steder, er der flere f\u00e6lder, vi kan falde i. Og det er helt uacceptabelt at falde i dem. Det, der skader os i alt dette, som i meget andet, er perfektionisme og... dovenskab. Vi pr\u00f8ver at f\u00e5 alt gjort perfekt, men det er ikke n\u00f8dvendigt at g\u00f8re alt perfekt! Det er vigtigt kun at g\u00f8re bestemte ting, men g\u00f8re dem korrekt og fuldf\u00f8re dem, s\u00e5 de fungerer ordentligt. <\/p>\n

Failover er ikke noget sjovt og underholdende, der bare er for sjov; det er noget, der skal g\u00f8re pr\u00e6cis \u00e9n ting \u2014 reducere nedetid, s\u00e5 tjenesten, firmaet, taber f\u00e6rre penge. Og i alle metoder til backup foresl\u00e5r jeg at t\u00e6nke i f\u00f8lgende kontekst: hvor er pengene?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nDen f\u00f8rste f\u00e6lde<\/b>: n\u00e5r vi bygger store p\u00e5lidelige systemer og arbejder med backup \u2014 reducerer vi antallet af nedbrud. Det er en frygtelig misforst\u00e5else. N\u00e5r vi arbejder med backup, \u00f8ger vi sandsynligvis antallet af nedbrud. Og hvis vi g\u00f8r alt rigtigt, vil vi samlet set reducere nedetiden. Der vil v\u00e6re flere nedbrud, men de vil ske med f\u00e6rre omkostninger. Hvad er backup? \u2014 det er en komplikation af systemet. Enhver komplikation er en d\u00e5rlig ting: vi f\u00e5r flere sm\u00e5 dele, flere tandhjul, kort sagt, flere elementer \u2014 og dermed er der en h\u00f8jere chance for, at noget g\u00e5r i stykker. Og de vil faktisk g\u00e5 i stykker. Og de vil bryde oftere. Et enkelt eksempel: lad os sige, at vi har en hjemmeside, der bruger PHP og MySQL. Og den skal hurtigt sikres. <\/p>\n

S\u00e5, vi tager den anden platform, bygger et identisk system... Kompleksiteten fordobles - vi har to enheder. Og s\u00e5 opbygger vi en bestemt logik for overf\u00f8rsel af data fra den ene platform til den anden - alts\u00e5 datareplication, kopiering af statiske filer osv. Logikken for replication er som regel meget kompleks, og dermed kan den samlede kompleksitet af systemet v\u00e6re ikke 2, men 3, 5, 10 gange st\u00f8rre. <\/p>\n

Den anden f\u00e6lde<\/b>: n\u00e5r vi bygger virkelig store komplekse systemer, fantasere vi om, hvad vi \u00f8nsker at opn\u00e5 i sidste ende. Voil\u00e0: Vi \u00f8nsker at f\u00e5 et superp\u00e5lideligt system, der fungerer uden nedetid, skifter over p\u00e5 et halvt sekund (eller endnu bedre \u00f8jeblikkeligt), og vi begynder at g\u00f8re vores dr\u00f8mme til virkelighed. Men der er ogs\u00e5 en nuance her: jo mindre den \u00f8nskede skiftetid er, desto mere kompleks bliver logikken i systemet. Jo mere kompleks logikken bliver, desto oftere vil systemet g\u00e5 i stykker. Man kan havne i en meget ubehagelig situation: vi pr\u00f8ver med alle kr\u00e6fter at reducere nedetid, men i virkeligheden g\u00f8r vi alt mere kompliceret, og n\u00e5r noget g\u00e5r galt, vil nedetiden i sidste ende v\u00e6re st\u00f8rre. Her fanger man ofte sig selv i tanken: ah... det ville have v\u00e6ret bedre ikke at have reserveret. Det ville have v\u00e6ret bedre, hvis det bare fungerede med en forst\u00e5elig nedetid. <\/p>\n

Hvordan kan man bek\u00e6mpe dette? Vi m\u00e5 stoppe med at lyve for os selv, stoppe med at rose os selv, om at vi her nu vil bygge et rumskib, men realistisk forst\u00e5, hvor l\u00e6nge projektet egentlig kan tage. Og til denne maksimale tid vil vi v\u00e6lge, hvilke metoder vi vil bruge til at \u00f8ge p\u00e5lideligheden af vores system. <\/p>\n

\"Failover:
\n
\nDet er tid til nogle \"historier fra livet\"\u2026 fra livet, selvf\u00f8lgelig. <\/p>\n

Eksempel nummer et<\/h4>\n

\nForestil dig en visitkort website for r\u00f8rproduktionsfabrikken nr. 1 i by N. Der st\u00e5r med store bogstaver - R\u00d8RPRODUKTION FABRIK NR. 1. Lidt l\u00e6ngere nede - sloganet: \"Vore r\u00f8r er de mest runde r\u00f8r i N\". Og nederst telefonnummeret til direkt\u00f8ren og hans navn. Vi forst\u00e5r, at det er vigtigt at reservere - det er virkelig en vigtig ting! Vi begynder at finde ud af, hvad det best\u00e5r af. Html-statik - det vil sige et par billeder, hvor direkt\u00f8ren faktisk sidder ved bordet i saunaen med sin partner og diskuterer en eller anden aftale. Vi begynder at t\u00e6nke p\u00e5 nedetid. Det kommer til at t\u00e6nke, at man skal ligge der i fem minutter, ikke mere. Og s\u00e5 sp\u00f8rgsm\u00e5let: hvor mange salg har vi egentlig haft fra vores hjemmeside? Hvor mange? Hvad betyder \"nul\"? Eller faktisk: fordi alle fire handler fra det sidste \u00e5r gjorde direkt\u00f8ren ved det samme bord, med de samme mennesker, som de g\u00e5r i sauna med og sidder ved bordet. Og vi forst\u00e5r, at selv hvis dagen g\u00e5r, kommer der ikke til at ske noget skr\u00e6mmende. <\/p>\n

Ud fra de indledende oplysninger er der en dag til at f\u00e5 denne historie op at k\u00f8re. Vi begynder at t\u00e6nke p\u00e5 reservationsskemaet. Og vi v\u00e6lger det mest ideelle skema til reservation for dette eksempel: vi bruger ikke reservation. Hele denne ting kan enhver administrator s\u00e6tte op p\u00e5 en halv time med pauser. S\u00e6tte en webserver op, l\u00e6gge filer - det hele. Det vil k\u00f8re. Der er ikke noget, man skal holde \u00f8je med, intet der kr\u00e6ver s\u00e6rlig opm\u00e6rksomhed. S\u00e5 konklusionen fra eksempel nummer et er temmelig indlysende: tjenester, som ikke kr\u00e6ver reservation - skal ikke reserveres.<\/p>\n

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

Eksempel nummer to<\/h4>\n

\nVirksomhedsblog: specielt uddannede skriver nyheder der, vi deltager i en bestemt messe, og vi har netop lanceret et nyt produkt osv. Lad os antage, at dette er standard PHP med WordPress, en lille database og lidt statisk indhold. Det er klart, at vi ikke b\u00f8r falde hen \u2014 \"ikke l\u00e6ngere end fem minutter!\", alt det der. Men lad os t\u00e6nke lidt videre. Hvad laver denne blog? Bes\u00f8gende kommer fra Yandex og Google via forskellige s\u00f8gninger, organisk. Fantastisk. Men hvordan h\u00e6nger salget sammen med det? En \u00e5benbaring: ikke s\u00e6rlig meget. Annoncetransport g\u00e5r til hovedsiden, som er p\u00e5 en anden server. Vi begynder at overveje en backup-plan for bloggen. Ideelt set skal den kunne gendannes p\u00e5 et par timer, og det ville v\u00e6re godt at forberede sig p\u00e5 det. Det ville v\u00e6re fornuftigt at tage en maskine i et andet datacenter, installere milj\u00f8et, det vil sige webserver, PHP, WordPress, MySQL, og lade det ligge i dvale. I det \u00f8jeblik vi indser, at alt er brudt ned, skal vi g\u00f8re to ting \u2014 gendanne en MySQL dump p\u00e5 50 megabyte, som tager et minut, og gendanne et antal billeder fra backupen. Det er heller ikke s\u00e5 omfattende. P\u00e5 den m\u00e5de kan hele ops\u00e6tningen v\u00e6re oppe at k\u00f8re p\u00e5 en halv time. Ingen replikationer, eller Gud forbyde det, automatisk failover. Konklusion: det, vi hurtigt kan gendanne fra backup, beh\u00f8ver ikke at v\u00e6re reserveret. <\/p>\n

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

Eksempel nummer tre, lidt mere kompliceret<\/h4>\n

\nOnlinebutik. PHP med open heart er lidt modificeret, MySQL med en solid database. Ret meget statisk indhold (for der er flotte HD-billeder i en onlinebutik og alt det der), Redis til sessioner og Elasticsearch til s\u00f8gning. Vi begynder at t\u00e6nke p\u00e5 nedetid. Her er det klart, at en dag uden problemer kan internetbutikken ikke ligge stille. Jo l\u00e6ngere tid den ligger stille, jo flere penge mister vi. Det er tid til at skynde sig. Og hvor meget? Jeg t\u00e6nker, at hvis vi ligger stille i en time, s\u00e5 g\u00e5r ingen amok. Ja, vi vil miste noget, men hvis vi arbejder h\u00e5rdere, s\u00e5 bliver det kun v\u00e6rre. Vi definerer niveauet for acceptabel nedetid, i timer.<\/p>\n

Hvordan kan man reservere alt dette? Man har brug for en maskine uanset hvad: en time er ikke meget. Mysql: her kr\u00e6ves der allerede replikation, live replikation, fordi man sandsynligvis ikke vil kunne overf\u00f8re 100 GB data p\u00e5 \u00e9n time. Statiske filer, billeder: igen, 500 GB kan muligvis ikke overf\u00f8res p\u00e5 en time. Derfor er det bedre straks at kopiere billederne. Redis: her bliver det interessant. I Redis ligger sessioner \u2014 vi kan ikke bare slette den. For det ville ikke v\u00e6re godt: alle brugere vil blive logget ud, indk\u00f8bskurve ryddes osv. Folk vil v\u00e6re tvunget til at indtaste deres loginoplysninger igen, og mange kan v\u00e6lge at forlade og ikke gennemf\u00f8re k\u00f8bet. Igen, konverteringen vil falde. P\u00e5 den anden side er Redis pr\u00e6cis aktuelt med de senest loggede ind brugere, s\u00e5 det er m\u00e5ske heller ikke n\u00f8dvendigt. En god kompromis er at tage Redis og gendanne det fra en backup, fra i g\u00e5r, eller hvis der laves backup hver time \u2014 s\u00e5 fra en time tilbage. Heldigvis er gendannelse fra backup lige s\u00e5 simpelt som at kopiere \u00e9n fil. Den mest interessante historie er Elasticsearch. Hvem har nogensinde opsat MySQL replikation? Hvem har nogensinde opsat Elasticsearch replikation? Og hos hvem har den fungeret ordentligt bagefter? Jeg siger: vi ser en eller anden enhed i vores system. Den virker nyttig \u2014 men den er kompleks.
\nDet er komplekst i den forstand, at vores ingeni\u00f8rkolleger ikke har erfaring med det. Enten er der negative erfaringer, eller ogs\u00e5 forst\u00e5r vi, at det stadig er en relativt ny teknologi med sine nuancer eller mangler. Vi t\u00e6nker... \u00d8v, Elasticsearch er ogs\u00e5 stort, og det tager lang tid at gendanne fra backup \u2013 hvad g\u00f8r vi? Vi forst\u00e5r, at Elasticsearch i vores tilf\u00e6lde bruges til s\u00f8gning. Og hvordan s\u00e6lger vores onlinebutik? Vi g\u00e5r til marketingfolkene og sp\u00f8rger, hvor folk overhovedet kommer fra. De svarer: \"90% kommer direkte fra Yandex.Marked til produktkortet.\" Og s\u00e5 k\u00f8ber de, eller ogs\u00e5 g\u00f8r de ikke. F\u00f8lgelig har vi brug for s\u00f8gning for 10% af brugerne. At holde replikationen af Elasticsearch, is\u00e6r mellem forskellige datacentre i forskellige zoner, indeb\u00e6rer faktisk mange nuancer. Hvad er l\u00f8sningen? Vi tager Elasticsearch p\u00e5 en reserveret platform og g\u00f8r ikke noget med det. Hvis sagen tr\u00e6kker ud, s\u00e5 tager vi det m\u00e5ske op senere, men det er ikke sikkert. Egentlig er konklusionen stort set den samme: tjenester, der ikke p\u00e5virker pengene, reserverer vi alts\u00e5 ikke. S\u00e5 skemaet forbliver enklere.<\/p>\n

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

Eksempel nummer fire, endnu sv\u00e6rere.<\/h4>\n

\nIntegrator: blomstersalg, taxaopkald, salg af varer, kort sagt, hvad som helst. En seri\u00f8s ting, der arbejder 24\/7 for mange brugere. Med en komplet og interessant stak, hvor der er interessante databaser, l\u00f8sninger, h\u00f8j belastning, og vigtigst af alt, kan det ikke v\u00e6re nede i mere end 5 minutter. Ikke kun fordi folk ikke vil k\u00f8be, men fordi folk vil se, at denne ting ikke fungerer, bliver skuffede og m\u00e5ske slet ikke kommer tilbage. <\/p>\n

Okay. Fem minutter. Hvad skal vi g\u00f8re ved dette? I dette tilf\u00e6lde bygger vi, som voksne, en rigtig reserveret platform, med replikering af det hele og m\u00e5ske endda automatiserer overgangen til denne platform s\u00e5 meget som muligt. Og derudover m\u00e5 vi ikke glemme at g\u00f8re \u00e9n vigtig ting: faktisk at skrive en overgangsprocedure. Proceduren, selvom alt er automatiseret, kan v\u00e6re meget simpel. I stil med \"start dette ansible-scenarie\", \"klik p\u00e5 den bestemte boks i route 53\" osv. \u2014 men det skal v\u00e6re en pr\u00e6cis liste over handlinger. <\/p>\n

Og det virker til at v\u00e6re klart. At skifte replikationen er en triviel opgave, ellers skifter den automatisk. At omskrive dom\u00e6nenavnet i DNS er af samme slags. Problemet er, at n\u00e5r et s\u00e5dant projekt falder, opst\u00e5r der panik, og selv de st\u00e6rkeste og mest erfarne administratorer kan blive ramt af det. Uden en klar instruktion som \"\u00e5bn terminalen, g\u00e5 hertil, og vores servers adresse er stadig s\u00e5dan her\" er det sv\u00e6rt at overholde en tidsramme p\u00e5 5 minutter til genoplivning. Og n\u00e5r vi bruger denne retningslinje, er det let at registrere \u00e6ndringer i infrastrukturen, for eksempel, og \u00e6ndre retningslinjen tilsvarende.
\nMen hvis reserveringssystemet er meget komplekst, og vi p\u00e5 et tidspunkt laver en fejl, kan vi b\u00e5de nedl\u00e6gge vores backup-lokation og samtidig forvandle dataene til gr\u00f8d p\u00e5 begge lokationer - det vil v\u00e6re meget trist. <\/p>\n

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

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

\nEn international tjeneste med hundred millioner brugere over hele verden. Alle tidszoner, der findes, highload p\u00e5 max, m\u00e5 ikke g\u00e5 ned overhovedet. Et minut, og det bliver trist. Hvad skal man g\u00f8re? Reservering, igen, fuldt program. Vi gjorde alt, hvad jeg n\u00e6vnte i det forrige eksempel, og lidt mere. En ideel verden, og vores infrastruktur - den er efter alle definitioner DevOps IaaC. S\u00e5 alt ligger i git, og man skal bare trykke p\u00e5 knappen. <\/p>\n

Hvad mangler? En ting - tr\u00e6ning. Uden det kan vi ikke. Det virker som om, at alt er perfekt, og at vi har alles kontrol. Vi trykker p\u00e5 knappen, og alt sker. Selv hvis det er s\u00e5dan - og vi ved, at det ikke sker - interagerer vores system med nogle andre systemer. For eksempel DNS fra route 53, S3-lagring, integration med nogle API\u2019er. Vi kan ikke forudse alt i dette hypotetiske eksperiment. Og indtil vi faktisk tr\u00e6kker kontakten - finder vi ikke ud af, om det virker eller ej. <\/p>\n

\"Failover:
\n
\nDet var nok det hele. V\u00e6r ikke doven og overdriv ikke. Og m\u00e5 oppetiden v\u00e6re med dig!
\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: perfektionisme og\u2026 dovenskab \u00f8del\u00e6gger os | ProHoster","description":"Om sommeren falder b\u00e5de k\u00f8bsaktiviteten og intensiteten af \u00e6ndringer i webprojekters infrastruktur, fort\u00e6ller os Captain Obvious. Bare fordi selv IT-folk sommetider tager p\u00e5 ferie.","canonical_url":"https:\/\/prohoster.info\/da\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"da_DK","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\/da\/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\/da\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/da\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}