{"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\/hr\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: uni\u0161tava nas perfekcionizam i\u2026 lijenost","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Tijekom ljeta tradicionalno opada i kupovna aktivnost i intenzitet promjena infrastrukture web projekata, govori nam Kapetan O\u010diglednost. Jednostavno zato \u0161to \u010dak i IT stru\u010dnjaci, dogodi se, idu na godi\u0161nji odmor. I CTO tako\u0111er. Te\u017ee je onima koji ostaju na svom mjestu, no sada nije o tome: mo\u017eda je iz tog razloga ljeto najbolje doba za polako razmi\u0161ljanje o postoje\u0107em sustavu rezerviranja i izradu plana za njegovo pobolj\u0161anje. A u tome \u0107e vam pomo\u0107i iskustvo Egora Andrejeva iz AdminDivision<\/a><\/noindex>, o kojem je govorio na konferenciji Uptime dan<\/a><\/noindex>.<\/i><\/p>\n

Prilikom izgradnje rezervnih mjesta, prilikom rezerviranja postoje nekoliko zamki u koje se mo\u017ee upasti. A u njih se nikako ne smije upasti. I u svemu ovome, kao i u mnogo \u010demu drugome, uni\u0161tava nas perfekcionizam i\u2026 lijenost. Poku\u0161avamo u\u010diniti sve savr\u0161eno, a savr\u0161eno ne trebamo \u010diniti! Trebamo napraviti samo odre\u0111ene stvari, ali ih trebamo napraviti ispravno, zavr\u0161iti ih, kako bi normalno radile. <\/p>\n

Failover nije neka zabavna stvar \u2018za svaki slu\u010daj\u2019; to je stvar koja treba u\u010diniti samo jedno \u2014 smanjiti vrijeme mirovanja, kako bi se servis, tvrtka, manje gubila novac. I u svim metodama rezerviranja predla\u017eem razmi\u0161ljati u sljede\u0107em kontekstu: gdje su novci?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nPrva zamka<\/b>: kada gradimo velike pouzdane sustave i bavimo se rezerviranjem \u2014 smanjujemo broj kvarova. To je stra\u0161na zabluda. Kada se bavimo rezerviranjem, vjerojatno pove\u0107avamo broj kvarova. I ako sve napravimo ispravno, tada \u0107emo ukupno smanjiti vrijeme mirovanja. Kvarova \u0107e biti vi\u0161e, ali \u0107e se doga\u0111ati uz manje tro\u0161kove. \u0160to je zapravo rezerviranje? \u2014 to je kompliciranje sustava. Svako kompliciranje je lo\u0161e: imamo vi\u0161e sitnica, vi\u0161e zup\u010danika, rije\u010dju, vi\u0161e elemenata \u2014 i, stoga, ve\u0107a je \u0161ansa za kvar. I oni \u0107e se zaista slomiti. I stvarat \u0107e kvarove \u010de\u0161\u0107e. Jednostavan primjer: recimo da imamo neku web stranicu, s PHP-om, MySQL-om. I hitno je potrebno napraviti rezervaciju. <\/p>\n

\u0160to se ti\u010de (c) Uzimamo drugu platformu, gradimo identi\u010dan sustav... Slo\u017eenost postaje dvostruko ve\u0107a \u2014 imamo dvije entitete. A na to nanosimo odre\u0111enu logiku prijenosa podataka s jedne platforme na drugu \u2014 dakle, replikacija podataka, kopiranje statike i tako dalje. Tako, replikacijska logika \u2014 obi\u010dno je vrlo slo\u017eena, i stoga ukupna slo\u017eenost sustava mo\u017ee biti ne 2, ve\u0107 3, 5, 10 puta ve\u0107a. <\/p>\n

Druga zamka<\/b>: kada gradimo stvarno velike slo\u017eene sustave, ma\u0161tamo o tome \u0161to \u017eelimo posti\u0107i na kraju. Voil\u00e0: \u017eelimo imati superpouzan sustav koji radi bez ikakvog zastoja, prebacuje se za pola sekunde (a jo\u0161 bolje, odmah), i po\u010dinjemo ostvarivati snove u stvarnost. No ovdje tako\u0111er postoji nijansa: \u0161to je kra\u0107e \u017eeljeno vrijeme prebacivanja, to je slo\u017eenija logika sustava. \u0160to \u0107emo te\u017ee napraviti tu logiku, to \u0107e se sustav \u010de\u0161\u0107e ru\u0161iti. I mo\u017eemo se na\u0107i u vrlo neugodnoj situaciji: svim snagama poku\u0161avamo smanjiti vrijeme zastoja, a zapravo sve kompliciramo, i kada ne\u0161to ne ide po planu, vrijeme zastoja \u0107e na kraju biti du\u017ee. \u010cesto se uhvati\u0161 u misli: bolje da nismo imali rezervu. Bolje da je jedno radilo s jasnim vremenom zastoja. <\/p>\n

Kako se s tim boriti? Moramo prestati lagati sami sebi, prestati se udvarati, da \u0107emo graditi svemirski brod, i realno razumjeti koliko dugo projekt mo\u017ee trajati. Prema tom maksimalnom vremenu, birat \u0107emo kojim \u0107emo metodama zapravo pove\u0107ati pouzdanost na\u0161eg sustava. <\/p>\n

\"Failover:
\n
\nSavr\u0161eno vrijeme za \u00abpri\u010de iz \u017e\u00bb\u2026 iz \u017eivota, naravno. <\/p>\n

Primjer broj jedan<\/h4>\n

\nZamislite informacijsku stranicu tvornice cjevovoda broj 1 u gradu N. Na njoj su ispisana velika slova \u2014 TVORNICA CJEVOVODA BROJ 1. Malo ni\u017ee nalazi se slogan: \u201eNa\u0161e cijevi su najokruglije cijevi u N\u201c. I na dnu je broj telefona glavnog direktora i njegovo ime. Shva\u0107amo da treba rezervirati \u2014 to je veoma va\u017ena stvar! Po\u010dinjemo istra\u017eivati od \u010dega se sastoji. Html statika \u2014 dakle, nekoliko slika, gdje glavni direktor, zapravo, sjedi za stolom u sauni sa svojim partnerom i razgovaraju o nekoj novoj transakciji. Po\u010dinjemo razmi\u0161ljati o vremenu neaktivnosti. Pada nam na pamet: treba le\u017eati pet minuta, ne vi\u0161e. A tu je pitanje: koliko je od na\u0161e web stranice bilo prodaja uop\u0107e? Koliko, koliko? \u0160to zna\u010di \u201enula\u201c? A to i zna\u010di: zato \u0161to je svih \u010detiri transakcije pro\u0161le godine glavni direktor napravio za istim stolom, s istim ljudima s kojima idu u saunu sjede za stolom. I shva\u0107amo da \u010dak i ako stranica le\u017ei jedan dan \u2014 ne\u0107e biti ni\u0161ta stra\u0161no. <\/p>\n

Na temelju uvodnih informacija, imamo jedan dan za pokretanje ove pri\u010de. Po\u010dinjemo razmi\u0161ljati o rezervacijskoj shemi. I biramo najidealniju shemu za rezervaciju za ovaj primjer: ne koristimo rezervaciju. Ova cijela stvar se podi\u017ee bilo kojim administratorom za pola sata s pauzama. Postaviti web server, staviti datoteke \u2014 to je to. Funkcionirat \u0107e. Ni\u0161ta ne treba pratiti, ni\u0161ta ne treba posebno pa\u017enju. Dakle, zaklju\u010dak iz prvog primjera je prili\u010dno o\u010digledan: usluge koje ne treba rezervirati \u2014 ne treba rezervirati.<\/p>\n

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

Primjer broj dva<\/h4>\n

\nBlog tvrtke: posebno obu\u010deni pi\u0161u tamo vijesti, sudjelovali smo na odre\u0111enoj izlo\u017ebi, a ovdje smo predstavili jo\u0161 jedan novi proizvod i tako dalje. Pretpostavimo da je to standardni PHP s WordPressom, mala baza podataka i malo stati\u010dkog sadr\u017eaja. Naravno, ponovno dolazi na pamet da se ne mo\u017ee le\u017eati - 'ne vi\u0161e od pet minuta!', sve to. No, razmislimo dalje. \u0160to taj blog radi? Dolaze posjetitelji s Yandexa, s Googlea po nekim upitima, organski. Odli\u010dno. A kako su prodaje uop\u0107e povezane s njim? Osvje\u017eenje: ne previ\u0161e. Reklamni promet ide na glavni sajt, koji je na drugom poslu\u017eitelju. Po\u010dinjemo razmi\u0161ljati o shemi rezerviranja bloga. Po\u0161teno, trebalo bi ga podi\u0107i u roku od nekoliko sati, i bilo bi dobro pripremiti se za to. Razumno bi bilo nabaviti stroj u drugom data centru, instalirati na njega okru\u017eenje, to jest web server, PHP, WordPress, MySQL, i ostaviti to u mirovanju. U trenutku kada shvatimo da je sve propalo, trebamo u\u010diniti dvije stvari - izvr\u0161iti dump MySQL-a od 50 megabajta, to \u0107e tu pro\u0107i za minutu, i pokrenuti odre\u0111eni broj slika iz backup-a. To tako\u0111er nije puno. Tako, za pola sata cijela ta stvar se pokre\u0107e. Nema replikacija, ili, ne daj Bo\u017ee, automatskog failovera. Zaklju\u010dak: ono \u0161to mo\u017eemo brzo pokrenuti iz backup-a - ne treba rezervirati. <\/p>\n

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

Primjer broj tri, malo slo\u017eeniji<\/h4>\n

\nInternetska trgovina. PhP s malo dorade, mysql sa solidnom bazom. Dosta stati\u010dkog sadr\u017eaja (jer u internetskoj trgovini ima lijepih HD slika i sve to), Redis za sesije i Elasticsearch za pretra\u017eivanje. Po\u010dinjemo razmi\u0161ljati o vremenu zastoja. I tu, naravno, nije tajna da dan bez boli ne mo\u017ee pro\u0107i za internetsku trgovinu. \u0160to du\u017ee le\u017ei, to vi\u0161e novca gubimo. Moramo ubrzati. A koliko? Smatram da ako budemo le\u017eali sat, nitko ne\u0107e poludjeti. Da, ne\u0161to \u0107emo izgubiti, ali ako se po\u010dnemo truditi \u2013 samo \u0107e biti gore. Odre\u0111ujemo shemu zastoja, koja je prihvatljiva u satu.<\/p>\n

Kako to sve mogu rezervirati? Automobil je potreban u svakom slu\u010daju: sat vremena je prili\u010dno malo. Mysql: ovdje ve\u0107 potrebna replikacija, \u017eiva replikacija, jer za sat vremena 100 GB u dump vjerojatno ne\u0107e stati. Statika, slike: opet, za sat vremena 500 GB mo\u017eda ne\u0107e mo\u0107i stati. Stoga, bolje je odmah kopirati slike. Redis: ovdje je zanimljivije. U Redis-u se nalaze sesije \u2014 jednostavno uzeti i uni\u0161titi ga ne mo\u017eemo. Jer to ne\u0107e biti dobro: svi korisnici \u0107e se izlogirati, a ko\u0161arice \u0107e biti prazne i sli\u010dno. Ljudi \u0107e biti prisiljeni ponovno unositi svoje korisni\u010dko ime i lozinku, a mnogi \u0107e se mo\u017eda poslije povu\u0107i i ne zavr\u0161iti kupnju. Opet, konverzija \u0107e pasti. S druge strane, Redis je sasvim aktualan, s posljednjim prijavljenim korisnicima, vjerojatno tako\u0111er nije potreban. I dobar kompromis je uzeti Redis i obnoviti ga iz backup-a, ju\u010dera\u0161njeg, ili, ako ga imate svakih sat vremena, \u2014 starog satnog. Na sre\u0107u, obnova iz backup-a je kopiranje jedne datoteke. A najzanimljivija pri\u010da je Elasticsearch. Tko je ikada podizao replikaciju MySQL-a? Tko je ikada podizao replikaciju Elasticsearch-a? I tko je imao da nakon toga normalno radi? Na \u0161to mislim: vidimo u na\u0161em sustavu neku entitet. Izgleda korisno \u2014 ali je slo\u017eeno.
\nSlo\u017een je u smislu da na\u0161i in\u017eenjeri nemaju iskustva u radu s njim. Ili imaju negativno iskustvo. Ili shva\u0107amo da je to jo\u0161 uvijek prili\u010dno nova tehnologija s odre\u0111enim nijansama ili neodre\u0111enostima. Razmi\u0161ljamo... U redu, elastic je tako\u0111er velik, njegovo vra\u0107anje iz backup-a traje dugo, \u0161to u\u010diniti? Shva\u0107amo da se elastic u na\u0161em slu\u010daju koristi za pretra\u017eivanje. A kako prodaje na\u0161 online trgovina? Idemo do marketin\u0161kog tima, pitamo odakle ljudi dolaze. Oni odgovaraju: \"90% dolazi iz Yandex-marketa direktno na stranicu proizvoda\". I ili kupuju, ili ne. Shodno tome, pretra\u017eivanje treba 10% korisnika. A odr\u017eavanje replikacije elastic-a, posebno izme\u0111u razli\u010ditih data centara u razli\u010ditim zonama, zaista ima mnogo nijansi. Kakvo je rje\u0161enje? Uzimamo elastic na rezerviranoj platformi i ni\u0161ta s njim ne radimo. Ako se zadr\u017ei du\u017ee, mo\u017eda \u0107emo ga nekad podi\u0107i, ali to nije sigurno. Zapravo, zaklju\u010dak je manje-vi\u0161e isti: usluge koje ne utje\u010du na nov\u010dane tokove ne rezerviramo. Da bi shema ostala jednostavnija.<\/p>\n

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

Primjer broj \u010detiri, jo\u0161 slo\u017eenije<\/h4>\n

\nIntegrator: prodaja cvije\u0107a, pozivanje taksija, prodaja roba, u su\u0161tini, bilo \u0161to. Ozbiljna stvar koja radi 24\/7 za veliki broj korisnika. S potpuno zanimljivim okvirom, gdje postoje zanimljive baze, rje\u0161enja, visoka optere\u0107enja, i \u0161to je najva\u017enije, ne mo\u017ee le\u017eati vi\u0161e od 5 minuta. Ne samo zato \u0161to ljudi ne\u0107e kupiti, ve\u0107 zato \u0161to \u0107e ljudi vidjeti da ta stvar ne funkcionira, razo\u010darati se i mo\u017eda se uop\u0107e ne vratiti drugi put. <\/p>\n

U redu. Pet minuta. \u0160to \u0107emo s tim u\u010diniti? U ovom slu\u010daju, ozbiljno, ula\u017eemo sve novce u izgradnju stvarne rezervne platforme, s replikacijom svega i sva\u010dega, i mo\u017eda \u010dak maksimalno automatiziramo prebacivanje na ovu platformu. A osim toga, ne smijemo zaboraviti u\u010diniti jednu va\u017enu stvar: zapravo, napisati regulativu za prebacivanje. Regulativa, \u010dak i ako je sve automatizirano, mo\u017ee biti vrlo jednostavna. U stilu \"pokrenuti ovakav scenarij ansible\", \"u route 53 ozna\u010diti ovu opciju\" i tako dalje \u2014 ali to mora biti neki to\u010dan popis radnji. <\/p>\n

Sve izgleda jasno. Prebaciti replikaciju \u2014 trivijalni zadatak, ili \u0107e se sama prebaciti. Promijeniti naziv domene u dns-u \u2014 iz iste serije. Problem je \u0161to kada ovakav projekt propadne, po\u010dinje panika, i \u010dak i najiskusniji administratori mogu biti podlo\u017eni tome. Bez jasne upute 'otvorite terminal, idite ovdje, adresa na\u0161eg servera je jo\u0161 uvijek ovakva', te\u0161ko je odr\u017eati vremensko ograni\u010denje od 5 minuta za reanimaciju. Tako\u0111er, kada koristimo ovaj regulativ, lako je zapisati neka promjene u infrastrukturi, na primjer, \u2014 i odgovaraju\u0107e promijeniti regulativ.
\nAli, ako je sustav rezerviranja jako slo\u017een i u nekom trenutku napravimo gre\u0161ku, mo\u017eemo sru\u0161iti i na\u0161u rezervnu lokaciju, a uz to i podatke pretvoriti u bundeve na obje lokacije \u2014 to \u0107e biti jako tu\u017eno. <\/p>\n

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

Primjer broj pet, potpuni hardcore<\/h4>\n

\nMe\u0111unarodna usluga s stotinama milijuna korisnika \u0161irom svijeta. Sve vremenske zone koje postoje, visoka optere\u0107enja na maksimumu, ne smije biti nikakvih zastoja. Minuta \u2014 i bit \u0107e tu\u017eno. \u0160to u\u010diniti? Rezervirati, opet, po punom programu. U\u010dinili smo sve \u0161to je spomenuto u prethodnom primjeru, i jo\u0161 malo vi\u0161e. Idealan svijet, a na\u0161a infrastruktura \u2014 ona je po svim definicijama devops IaaC. Zna\u010di sve je u git-u, samo pritisnite dugme. <\/p>\n

\u0160to nedostaje? Jedno \u2014 obuka. Bez toga se ne mo\u017ee. \u010cini se da je sve savr\u0161eno, da je sve pod kontrolom. Pritiskuje se dugme, sve se de\u0161ava. \u010cak i ako je to tako \u2014 a mi znamo da to nije mogu\u0107e \u2014 na\u0161 sustav sura\u0111uje s nekim drugim sustavima. Na primjer, to je dns od route 53, s3 pohrana, integracija s nekim api-jem. Sve predvidjeti u ovom teoretskom eksperimentu ne mo\u017eemo. I dok stvarno ne povu\u010demo prekida\u010d \u2014 ne\u0107emo znati ho\u0107e li raditi ili ne. <\/p>\n

\"Failover:
\n
\nNa tome, vjerovatno, sve. Ne budite lijeni i ne pretjerujte. I neka s vama bude uptime!
\n
Izvor: 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: uni\u0161tava nas perfekcionizam i\u2026 lijenost | ProHoster","description":"Ljeti se tradicionalno smanjuje i kupovna aktivnost, kao i intenzitet promjena infrastrukture web projekata, ka\u017ee nam Kapetan O\u010diglednost. Jednostavno zato \u0161to \u010dak i IT stru\u010dnjaci, kad-tad, idu na godi\u0161nji odmor.","canonical_url":"https:\/\/prohoster.info\/hr\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"hr_HR","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\/hr\/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\/hr\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/hr\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}