{"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\/pt\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: o perfeccionismo e\u2026 a pregui\u00e7a nos consomem","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

No ver\u00e3o, a atividade do consumidor e a intensidade das mudan\u00e7as na infraestrutura dos projetos da web tradicionalmente diminuem, diz o Capit\u00e3o \u00d3bvio. Apenas porque at\u00e9 os profissionais de TI, \u00e0s vezes, tiram f\u00e9rias. E os CTOs tamb\u00e9m. O que torna mais dif\u00edcil para aqueles que permanecem no cargo, mas n\u00e3o \u00e9 sobre isso que estamos falando agora: talvez seja precisamente por isso que o ver\u00e3o seja o melhor per\u00edodo para refletir calmamente sobre o esquema de backup existente e elaborar um plano para sua melhoria. E a experi\u00eancia de E ogar Andreev ser\u00e1 \u00fatil nesse sentido. AdminDivision<\/a><\/noindex>, sobre a qual ele falou na confer\u00eancia Uptime day<\/a><\/noindex>.<\/i><\/p>\n

Ao construir sites de backup, existem v\u00e1rias armadilhas nas quais podemos cair. E cair nelas \u00e9 completamente inaceit\u00e1vel. O que nos causa problemas, assim como em muitas outras quest\u00f5es, \u00e9 o perfeccionismo e... a pregui\u00e7a. Tentamos fazer tudo absolutamente perfeito, mas n\u00e3o precisamos fazer tudo de forma perfeita! Devemos nos concentrar apenas em certas coisas, mas faz\u00ea-las corretamente, finaliz\u00e1-las para que funcionem adequadamente. <\/p>\n

Failover n\u00e3o \u00e9 algo divertido ou desnecess\u00e1rio; \u00e9 uma coisa que deve fazer uma \u00fanica coisa - reduzir o tempo de inatividade para que o servi\u00e7o ou a empresa perca menos dinheiro. E em todos os m\u00e9todos de backup, sugiro pensar no seguinte contexto: onde est\u00e3o os recursos financeiros?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nA primeira armadilha<\/b>: quando constru\u00edmos sistemas grandes e confi\u00e1veis e trabalhamos em backup - diminu\u00edmos o n\u00famero de falhas. Isso \u00e9 uma ilus\u00e3o terr\u00edvel. Quando trabalhamos em backups, provavelmente aumentamos o n\u00famero de falhas. E se fizermos tudo corretamente, ent\u00e3o, no total, reduziremos o tempo de inatividade. Haver\u00e1 mais falhas, mas elas ocorrer\u00e3o com menores custos. Afinal, o que \u00e9 backup? \u2014 \u00e9 a complexifica\u00e7\u00e3o do sistema. Qualquer complexidade \u00e9 prejudicial: temos mais parafusos, mais engrenagens, em suma, mais elementos \u2014 e, portanto, uma chance maior de falhas. E eles realmente quebrar\u00e3o. E ocorrer\u00e3o com mais frequ\u00eancia. Um exemplo simples: digamos que temos um site, com PHP, MySQL. E ele precisa ser urgentemente reservado. <\/p>\n

Ent\u00e3o (c) Vamos pegar a segunda plataforma, construir um sistema id\u00eantico... A complexidade dobra \u2014 temos duas entidades. E ainda por cima, adicionamos uma l\u00f3gica espec\u00edfica de transfer\u00eancia de dados de uma plataforma para outra \u2014 ou seja, replica\u00e7\u00e3o de dados, c\u00f3pia de est\u00e1ticos e assim por diante. Pois bem, a l\u00f3gica de replica\u00e7\u00e3o \u2014 geralmente, \u00e9 muito complexa, e, portanto, a complexidade total do sistema pode ser n\u00e3o 2, mas 3, 5, 10 vezes maior. <\/p>\n

A segunda armadilha<\/b>: quando constru\u00edmos sistemas realmente grandes e complexos, fantasizamos sobre o que queremos obter no final. Voil\u00e0: queremos um sistema super confi\u00e1vel, que funciona sem downtime, que muda em meio segundo (ou melhor, instantaneamente), e come\u00e7amos a tornar nossos sonhos realidade. Mas aqui tamb\u00e9m h\u00e1 um detalhe: quanto menor o tempo desejado de mudan\u00e7a, mais complexa se torna a l\u00f3gica do sistema. Quanto mais complexa for essa l\u00f3gica, mais vezes o sistema falhar\u00e1. E pode-se entrar em uma situa\u00e7\u00e3o muito desagrad\u00e1vel: estamos tentando a todo custo reduzir o tempo de inatividade, mas, na verdade, estamos complicando tudo e, quando algo d\u00e1 errado, o tempo de inatividade acaba sendo maior. Muitas vezes, nos pegamos pensando: ah... seria melhor n\u00e3o termos feito a reserva. Seria melhor se apenas um funcionasse com um tempo de inatividade compreens\u00edvel. <\/p>\n

Como podemos lidar com isso? Precisamos parar de mentir para n\u00f3s mesmos, parar de nos iludir achando que vamos construir uma espa\u00e7onave, mas entender adequadamente quanto tempo o projeto pode realmente levar. E, para esse tempo m\u00e1ximo, escolheremos quais m\u00e9todos realmente usaremos para aumentar a confiabilidade do nosso sistema. <\/p>\n

\"Failover:
\n
\n\u00c9 hora de 'hist\u00f3rias da vida'... da vida, \u00e9 claro. <\/p>\n

Exemplo n\u00famero um<\/h4>\n

\nImagine um site de apresenta\u00e7\u00e3o da f\u00e1brica de tubos n\u00ba 1 da cidade de N. Est\u00e1 escrito em letras enormes \u2014 F\u00c1BRICA DE TUBOS N\u00ba 1. Um pouco abaixo, o slogan: \"Nossos tubos s\u00e3o os tubos mais redondos de N\". E embaixo, o n\u00famero de telefone do diretor-geral e seu nome. Entendemos que \u00e9 necess\u00e1rio reservar \u2014 isso \u00e9 algo muito importante! Come\u00e7amos a investigar do que se trata. \u00c9 uma p\u00e1gina HTML est\u00e1tica \u2014 ou seja, algumas imagens do diretor, na verdade, \u00e0 mesa em uma sauna com seu parceiro discutindo algum neg\u00f3cio. Come\u00e7amos a pensar sobre o tempo de inatividade. Vem \u00e0 mente a ideia: \u00e9 preciso ficar l\u00e1 por cinco minutos, no m\u00e1ximo. E aqui surge a pergunta: quantas vendas foram feitas atrav\u00e9s desse nosso site? Quantas, quantas? O que significa \"zero\"? Ou seja: porque todas as quatro vendas do ano passado o diretor fez na mesma mesa, com as mesmas pessoas com quem ele vai \u00e0 sauna. E entendemos que mesmo se o site ficar fora do ar por um dia \u2014 n\u00e3o ser\u00e1 nada aterrorizante. <\/p>\n

Com base nas informa\u00e7\u00f5es fornecidas, temos um dia para levantar essa quest\u00e3o. Come\u00e7amos a pensar sobre o esquema de reserva. E escolhemos o esquema de reserva mais ideal para este exemplo: n\u00e3o usamos reserva. Todo esse processo pode ser realizado por qualquer administrador em meia hora, com intervalos. Colocar um servidor web, colocar os arquivos \u2014 tudo. Ele funcionar\u00e1. N\u00e3o \u00e9 necess\u00e1rio monitorar nada, nem prestar aten\u00e7\u00e3o especial a nada. Portanto, a conclus\u00e3o do primeiro exemplo \u00e9 bastante \u00f3bvia: servi\u00e7os que n\u00e3o precisam de reserva \u2014 n\u00e3o precisam ser reservados.<\/p>\n

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

Exemplo n\u00famero dois<\/h4>\n

\nBlog da empresa: profissionais qualificados escrevem not\u00edcias l\u00e1, participamos de uma determinada exposi\u00e7\u00e3o e lan\u00e7amos mais um novo produto, e assim por diante. Suponha que isso seja um PHP padr\u00e3o com WordPress, um pequeno banco de dados e um pouco de est\u00e1tico. Claro, vem \u00e0 mente que n\u00e3o devemos deixar parado, 'n\u00e3o mais que cinco minutos!', tudo isso. Mas vamos pensar mais a fundo. O que esse blog faz? Ele recebe visitantes do Yandex, do Google atrav\u00e9s de algumas buscas org\u00e2nicas. \u00d3timo. E as vendas est\u00e3o, de alguma forma, relacionadas a isso? A revela\u00e7\u00e3o: n\u00e3o muito. O tr\u00e1fego pago vai para o site principal, que est\u00e1 em outra m\u00e1quina. Come\u00e7amos a pensar sobre o esquema de reserva do blog. Idealmente, ele precisa ser levantado em algumas horas, e seria bom se prepararmos para isso. O sensato seria alugar uma m\u00e1quina em outro data center, configurar o ambiente, ou seja, servidor web, PHP, WordPress, MySQL, e deix\u00e1-la em modo de espera. No momento em que percebemos que tudo deu errado, precisamos fazer duas coisas: restaurar o dump do MySQL que tem 50 megabytes, o que levar\u00e1 apenas um minuto, e restaurar algumas imagens do backup. Isso tamb\u00e9m n\u00e3o \u00e9 uma tarefa complexa. Assim, em meia hora, todo esse sistema est\u00e1 funcionando novamente. Sem replica\u00e7\u00f5es, ou, Deus nos livre, failover autom\u00e1tico. Conclus\u00e3o: o que podemos rapidamente restaurar do backup n\u00e3o precisa de reserva. <\/p>\n

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

Exemplo n\u00famero tr\u00eas, um pouco mais complicado<\/h4>\n

\nLoja virtual. PHP com open heart um pouco modificado, MySQL com uma base s\u00f3lida. Bastante est\u00e1tica (afinal, em uma loja virtual h\u00e1 lindas fotos em HD e tudo mais), Redis para sess\u00f5es e Elasticsearch para busca. Come\u00e7amos a pensar sobre o tempo de inatividade. E aqui \u00e9 claro que n\u00e3o podemos deixar a loja virtual fora do ar por um dia sem problemas. Quanto mais tempo ela ficar fora, mais dinheiro perdemos. \u00c9 hora de acelerar. E quanto? Acredito que se ficarmos uma hora fora, ningu\u00e9m ficar\u00e1 louco. Sim, perderemos algo, mas se come\u00e7armos a nos esfor\u00e7ar \u2014 ser\u00e1 ainda pior. Definimos o esquema de inatividade aceit\u00e1vel por hora.<\/p>\n

Como podemos reservar tudo isso? A m\u00e1quina \u00e9 necess\u00e1ria, de qualquer forma: uma hora \u00e9 bastante pouco. Mysql: aqui j\u00e1 precisamos de replica\u00e7\u00e3o, replica\u00e7\u00e3o ativa, porque em uma hora 100 GB em um dump, provavelmente, n\u00e3o caber\u00e1. Est\u00e1tica, imagens: novamente, em uma hora 500 GB pode n\u00e3o conseguir ser transferido. Sendo assim, \u00e9 melhor copiar as imagens de imediato. Redis: aqui a situa\u00e7\u00e3o \u00e9 mais interessante. As sess\u00f5es est\u00e3o no Redis - simplesmente n\u00e3o podemos apag\u00e1-lo. Porque isso n\u00e3o seria muito bom: todos os usu\u00e1rios ficariam desconectados, os carrinhos de compras limpos e assim por diante. As pessoas seriam obrigadas a digitar novamente seu login e senha, e muitos poderiam desistir e n\u00e3o finalizar a compra. Novamente, a convers\u00e3o cairia. Por outro lado, o Redis \u00e9 exatamente o que precisamos, com os \u00faltimos usu\u00e1rios logados, talvez tamb\u00e9m n\u00e3o seja necess\u00e1rio. E um bom compromisso seria pegar o Redis e restaur\u00e1-lo a partir de um backup, do dia anterior, ou, se voc\u00ea o fizer a cada hora, do \u00faltimo backup. Felizmente, restaur\u00e1-lo a partir de um backup \u00e9 a c\u00f3pia de um \u00fanico arquivo. E a hist\u00f3ria mais interessante \u00e9 o Elasticsearch. Quem j\u00e1 implantou a replica\u00e7\u00e3o do MySQL? Quem j\u00e1 implantou a replica\u00e7\u00e3o do Elasticsearch? E quem teve seu funcionamento normal depois? Eu quero dizer: vemos em nosso sistema uma certa entidade. Ela parece ser \u00fatil - mas \u00e9 complexa.
\n\u00c9 complicado no sentido de que nossos colegas engenheiros n\u00e3o t\u00eam experi\u00eancia com isso. Ou t\u00eam uma experi\u00eancia negativa. Ou entendemos que, por enquanto, \u00e9 uma tecnologia bastante nova com nuances ou imaturidade. Pensamos... Caramba, elastic tamb\u00e9m \u00e9 robusto, e restaur\u00e1-lo a partir do backup tamb\u00e9m leva tempo, o que fazer? Entendemos que o elastic, neste caso, \u00e9 usado para busca. E como nosso e-commerce vende? Vamos at\u00e9 os profissionais de marketing, perguntamos de onde as pessoas v\u00eam. Eles respondem: \"90% v\u00eam do Yandex Market diretamente para a p\u00e1gina do produto\". E ou compram ou n\u00e3o. Portanto, a busca \u00e9 necess\u00e1ria para 10% dos usu\u00e1rios. E manter a replica\u00e7\u00e3o do elastic, especialmente entre diferentes data centers em diferentes zonas, realmente tem muitos detalhes. Qual \u00e9 a sa\u00edda? Pegamos o elastic em uma plataforma reservada e n\u00e3o fazemos nada com ele. Se o processo demorar, talvez o levantemos mais tarde, mas isso n\u00e3o \u00e9 certo. Na verdade, a conclus\u00e3o \u00e9 mais ou menos a mesma: servi\u00e7os que n\u00e3o afetam o dinheiro, novamente, n\u00e3o reservamos. Para que o esquema permane\u00e7a mais simples.<\/p>\n

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

Exemplo n\u00famero quatro, ainda mais complicado.<\/h4>\n

\nIntegrador: venda de flores, chamada de t\u00e1xi, vendas de produtos, enfim, o que for. Um neg\u00f3cio s\u00e9rio, que funciona 24\/7 para um grande n\u00famero de usu\u00e1rios. Com um stack interessante, onde h\u00e1 bases interessantes, solu\u00e7\u00f5es, alta carga e, o mais importante, se ele estiver fora do ar por mais de 5 minutos, isso \u00e9 doloroso. N\u00e3o s\u00f3 porque as pessoas n\u00e3o comprar\u00e3o, mas porque ver\u00e3o que essa coisa n\u00e3o est\u00e1 funcionando, ficar\u00e3o desapontadas e podem n\u00e3o voltar nunca mais. <\/p>\n

Ok. Cinco minutos. O que vamos fazer com isso? Nesse caso, de forma profissional, com todo o investimento, constru\u00edmos uma verdadeira infraestrutura de backup, com replica\u00e7\u00e3o de tudo e todos, e talvez at\u00e9 automatizemos ao m\u00e1ximo a troca para essa infraestrutura. E, al\u00e9m disso, n\u00e3o podemos esquecer de fazer uma coisa importante: efetivamente, escrever um regulamento de troca. O regulamento, mesmo que voc\u00ea tenha tudo automatizado, pode ser bastante simples. Algo do tipo \"executar este determinado script ansible\", \"marcar esta op\u00e7\u00e3o no Route 53\" e assim por diante \u2014 mas deve haver uma lista precisa de a\u00e7\u00f5es. <\/p>\n

E parece que tudo est\u00e1 claro. Mudar a replica\u00e7\u00e3o \u00e9 uma tarefa trivial, ou ela se ajustar\u00e1 sozinha. Alterar o nome de dom\u00ednio no DNS \u00e9 da mesma linha. O problema \u00e9 que, quando um projeto assim cai, come\u00e7a o p\u00e2nico, e at\u00e9 os administradores mais experientes podem se deixar levar por isso. Sem uma instru\u00e7\u00e3o clara \"abra o terminal, v\u00e1 para aqui, o endere\u00e7o do nosso servidor ainda \u00e9 este\", \u00e9 dif\u00edcil manter o prazo de 5 minutos destinado \u00e0 recupera\u00e7\u00e3o. E al\u00e9m disso, quando usamos esse regulamento, \u00e9 f\u00e1cil registrar algumas mudan\u00e7as na infraestrutura, por exemplo, e alterar o regulamento de acordo.
\nMas, e se o sistema de reserva for muito complexo e, em algum momento, cometemos um erro, podemos acabar com nosso ambiente de backup e ainda transformar os dados em ab\u00f3bora em ambos os ambientes \u2013 isso ser\u00e1 realmente triste. <\/p>\n

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

Exemplo n\u00famero cinco, hardcore completo<\/h4>\n

\nUm servi\u00e7o internacional com centenas de milh\u00f5es de usu\u00e1rios em todo o mundo. Todos os fusos hor\u00e1rios, o m\u00e1ximo de highload, n\u00e3o pode haver quedas de forma alguma. Um minuto \u2014 e a situa\u00e7\u00e3o fica complicada. O que fazer? Reservar, novamente, da maneira mais completa. Fizemos tudo o que foi mencionado no exemplo anterior, e um pouco mais. Um mundo ideal, e nossa infraestrutura \u2014 ela se encaixa em todos os conceitos de DevOps IaaC. Ou seja, tudo est\u00e1 no git, e \u00e9 s\u00f3 clicar no bot\u00e3o. <\/p>\n

O que falta? Uma coisa \u2014 treinamentos. Sem eles, n\u00e3o d\u00e1. Parece que est\u00e1 tudo perfeito, temos tudo sob controle. Apertamos o bot\u00e3o, tudo acontece. Mesmo que assim seja \u2014 e sabemos que n\u00e3o \u00e9 bem assim \u2014 nosso sistema interage com outros sistemas. Por exemplo, o DNS do Route 53, armazenamento S3, integra\u00e7\u00e3o com alguma API. N\u00e3o poderemos prever tudo neste experimento te\u00f3rico. E at\u00e9 que realmente acionemos o interruptor \u2014 n\u00e3o saberemos se vai funcionar ou n\u00e3o. <\/p>\n

\"Failover:
\n
\nPor aqui, acho que \u00e9 isso. N\u00e3o sejam pregui\u00e7osos e n\u00e3o exagerem. E que a uptime esteja com voc\u00eas!
\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\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: o perfeccionismo e\u2026 a pregui\u00e7a nos levam \u00e0 ru\u00edna | ProHoster","description":"No ver\u00e3o, tradicionalmente, tanto a atividade de compra quanto a intensidade de mudan\u00e7a na infraestrutura de projetos web diminuem, nos diz o Capit\u00e3o \u00d3bvio. Simplesmente porque at\u00e9 os profissionais de TI, ocasionalmente, v\u00e3o de f\u00e9rias.","canonical_url":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"pt_PT","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\/pt\/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\/pt\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/pt\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}