{"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\/es\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","title":{"rendered":"Failover: nos mata el perfeccionismo y\u2026 la pereza","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

En verano, tradicionalmente, disminuyen tanto la actividad de compra como la intensidad del cambio en la infraestructura de los proyectos web, nos dice el Capit\u00e1n Obviedad. Simplemente porque, incluso los inform\u00e1ticos, a veces se van de vacaciones. Y el CTO tambi\u00e9n. M\u00e1s dif\u00edcil es para aquellos que permanecen en sus puestos, pero ahora no es de eso de lo que se trata: tal vez, por eso, el verano sea el mejor momento para pensar tranquilamente en el esquema de backup existente y elaborar un plan para mejorarlo. Y en esto te ser\u00e1 \u00fatil la experiencia de Egor Andreyev de AdminDivision<\/a><\/noindex>, que comparti\u00f3 en la conferencia D\u00eda de Uptime<\/a><\/noindex>.<\/i><\/p>\n

Al construir sitios de respaldo, al realizar reservas, hay varias trampas en las que se puede caer. Y caer en ellas no es aceptable. Lo que nos destruye en todo esto, como en muchas otras cosas, es el perfeccionismo y... la pereza. Intentamos hacer todo, todo, todo de manera perfecta, \u00a1y no es necesario hacerlo a la perfecci\u00f3n! Solo necesitamos hacer ciertas cosas, pero hacerlas correctamente, llevarlas hasta el final para que funcionen bien. <\/p>\n

El failover no es algo divertido que existe 'por existir'; es algo que debe hacer una sola cosa: reducir el tiempo de inactividad, para que el servicio, la empresa, pierda menos dinero. Y en todos los m\u00e9todos de reserva, propongo pensar en el siguiente contexto: \u00bfd\u00f3nde est\u00e1 el dinero?<\/p>\n

\"Failover:
\n<\/a><\/noindex>
\nLa primera trampa<\/b>: cuando construimos sistemas grandes y confiables y nos encargamos de la reserva, estamos reduciendo el n\u00famero de fallas. Este es un terrible enga\u00f1o. Cuando nos estamos ocupando de la reserva, es probable que aumentemos el n\u00famero de fallas. Y si hacemos todo bien, en conjunto, reduciremos el tiempo de inactividad. Habr\u00e1 m\u00e1s fallas, pero ocurrir\u00e1n con menores costos. \u00bfQu\u00e9 es la reserva? \u2014 es una complicaci\u00f3n del sistema. Cualquier complicaci\u00f3n es mala: tenemos m\u00e1s tornillos, m\u00e1s engranajes, en resumen, m\u00e1s elementos \u2014 y, por lo tanto, mayor probabilidad de fallo. Y realmente se romper\u00e1n. Y se romper\u00e1n m\u00e1s a menudo. Un ejemplo simple: digamos que tenemos un sitio web, con PHP, MySQL. Y es urgentemente necesario hacer una reserva. <\/p>\n

Bueno, tomamos el segundo sitio, construimos un sistema id\u00e9ntico... La complejidad se duplica: tenemos dos entidades. Adem\u00e1s, aplicamos cierta l\u00f3gica para transferir datos de un sitio a otro, es decir, replicaci\u00f3n de datos, copia de est\u00e1tica, y as\u00ed sucesivamente. La l\u00f3gica de replicaci\u00f3n, como suele ser, es generalmente muy compleja, y, por lo tanto, la complejidad total del sistema puede ser no el doble, sino 3, 5, 10 veces mayor. <\/p>\n

La segunda trampa<\/b>: cuando construimos realmente grandes sistemas complejos, fantaseamos sobre lo que queremos lograr al final. Voil\u00e0: queremos crear un sistema hiperconfiable que funcione sin tiempo de inactividad, que se cambie en medio segundo (o mejor a\u00fan, instant\u00e1neamente), y empezamos a hacer realidad nuestros sue\u00f1os. Pero aqu\u00ed tambi\u00e9n hay un matiz: cuanto menor sea el tiempo de conmutaci\u00f3n deseado, m\u00e1s compleja se convierte la l\u00f3gica del sistema. Cuanto m\u00e1s compleja debamos hacer esta l\u00f3gica, m\u00e1s a menudo fallar\u00e1 el sistema. Y podemos caer en una situaci\u00f3n muy desagradable: nos esforzamos en reducir el tiempo de inactividad, pero en realidad estamos complicando todo, y cuando algo sale mal, el tiempo de inactividad al final ser\u00e1 mayor. A menudo te encuentras pensando: bueno... hubiera sido mejor no tener una reserva. Mejor que funcionara uno solo con un tiempo de inactividad claro. <\/p>\n

\u00bfC\u00f3mo se puede combatir esto? Hay que dejar de enga\u00f1arse a s\u00ed mismo, dejar de halagarse diciendo que ahora vamos a construir una nave espacial, y comprender adecuadamente cu\u00e1nto tiempo puede estar el proyecto en espera. Con base en este tiempo m\u00e1ximo, elegiremos qu\u00e9 m\u00e9todos utilizaremos para aumentar la confiabilidad de nuestro sistema. <\/p>\n

\"Failover:
\n
\nEs hora de \"historias de la vida\"... de la vida, por supuesto. <\/p>\n

Ejemplo n\u00famero uno<\/h4>\n

\nImagina una p\u00e1gina web de presentaci\u00f3n de la f\u00e1brica de tubos n\u00famero 1 de la ciudad de N. En ella, en letras enormes, est\u00e1 escrito \u2013 FABRICA DE TUBOS N\u00b0 1. Un poco m\u00e1s abajo, el eslogan: \u00abNuestros tubos son los m\u00e1s redondos de N\u00bb. Y al final, el n\u00famero de tel\u00e9fono del director general y su nombre. Entendemos que es necesario reservar \u2014 \u00a1es una cosa muy importante! Comenzamos a explorar de qu\u00e9 est\u00e1 compuesto. Html est\u00e1tico \u2014 es decir, un par de im\u00e1genes donde el director, en realidad, est\u00e1 en la sauna con su socio discutiendo alg\u00fan trato. Comenzamos a pensar en el tiempo de inactividad. Se nos ocurre: debe estar ah\u00ed cinco minutos, no m\u00e1s. Y aqu\u00ed viene la pregunta: \u00bfcu\u00e1ntas ventas se hicieron a trav\u00e9s de nuestro sitio? \u00bfCu\u00e1ntas? \u00bfQu\u00e9 significa \u00abcero\u00bb? O, incluso, significa: porque todas las cuatro transacciones del a\u00f1o pasado las hizo en la misma mesa, con las mismas personas, con las que van a la sauna y se sientan a la mesa. Y entendemos que incluso si el sitio permanece inactivo un d\u00eda, no pasar\u00e1 nada terrible. <\/p>\n

Con base en los datos, hay un d\u00eda para elevar esta historia. Comenzamos a pensar en el esquema de reserva. Y elegimos el esquema m\u00e1s ideal para la reserva en este caso: no usamos la reserva. Todo esto puede ser levantado por cualquier administrador en media hora, con pausas. Instalar un servidor web, colocar archivos \u2014 eso es todo. Funcionar\u00e1. No hay nada de qu\u00e9 preocuparse, nada a lo que prestar especial atenci\u00f3n. Es decir, la conclusi\u00f3n del primer ejemplo es bastante obvia: los servicios que no necesitan ser reservados \u2014 no necesitan ser reservados.<\/p>\n

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

Ejemplo n\u00famero dos<\/h4>\n

\nBlog de la empresa: escritores especializados publican noticias all\u00ed, como nuestra participaci\u00f3n en una determinada exposici\u00f3n, o que hemos lanzado un nuevo producto, etc. Supongamos que es un PHP est\u00e1ndar con WordPress, una peque\u00f1a base de datos y algo de est\u00e1tica. Por supuesto, viene a la mente que no hay que estar inactivos \u2014 \"\u00a1no m\u00e1s de cinco minutos!\", todo eso. Pero pensemos un poco m\u00e1s. \u00bfQu\u00e9 hace este blog? Recibe visitas desde Yandex, desde Google por ciertas b\u00fasquedas, de forma org\u00e1nica. Genial. \u00bfY las ventas tienen alguna relaci\u00f3n con ello? Revelaci\u00f3n: no realmente. El tr\u00e1fico publicitario va al sitio principal, que est\u00e1 en otra m\u00e1quina. Empezamos a pensar en el esquema de respaldo del blog. Idealmente, deber\u00eda levantarse en un par de horas, y ser\u00eda bueno estar preparados para ello. Ser\u00eda sensato adquirir una m\u00e1quina en otro centro de datos, instalar el entorno, es decir, servidor web, PHP, WordPress, MySQL, y dejarlo en estado de reposo. En el momento en que nos damos cuenta de que todo ha fallado, debemos hacer dos cosas: restaurar un volcado de MySQL de 50 megas, que se completar\u00e1 en un minuto, y restaurar una cierta cantidad de im\u00e1genes desde la copia de seguridad. Esto tampoco deber\u00eda llevar mucho tiempo. As\u00ed, en media hora, se levanta todo. No hay r\u00e9plicas, ni, por Dios, failover autom\u00e1tico. Conclusi\u00f3n: lo que podemos restaurar r\u00e1pidamente desde la copia de seguridad no necesita ser respaldado. <\/p>\n

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

Ejemplo n\u00famero tres, un poco m\u00e1s complicado.<\/h4>\n

\nTienda en l\u00ednea. PHP con open heart ligeramente modificado, MySQL con una base s\u00f3lida. Bastante est\u00e1tica (ya que en una tienda en l\u00ednea hay bonitas im\u00e1genes en HD y todo eso), Redis para sesiones y Elasticsearch para b\u00fasqueda. Empezamos a pensar sobre el tiempo de inactividad. Y aqu\u00ed, por supuesto, es obvio que un d\u00eda sin problema la tienda en l\u00ednea no puede estar ca\u00edda. Cuanto m\u00e1s tiempo est\u00e9 inactiva, m\u00e1s dinero perdemos. Es necesario acelerar el proceso. \u00bfY en qu\u00e9 medida? Supongo que si estamos ca\u00eddos una hora, nadie se volver\u00e1 loco. S\u00ed, perderemos algo, pero si comenzamos a apurarnos, solo empeorar\u00e1. Determinamos el esquema de inactividad aceptable en una hora.<\/p>\n

\u00bfC\u00f3mo se puede reservar todo esto? En cualquier caso, se necesita una m\u00e1quina: una hora es bastante poco tiempo. Mysql: aqu\u00ed ya se necesita replicaci\u00f3n, replicaci\u00f3n en vivo, porque en una hora 100 GB de volcado probablemente no se puedan procesar. Est\u00e1tica, im\u00e1genes: de nuevo, en una hora 500 GB pueden no dar tiempo a transferirse. Por lo tanto, es mejor copiar las im\u00e1genes de inmediato. Redis: aqu\u00ed es m\u00e1s interesante. En Redis se almacenan las sesiones; simplemente no podemos desecharlo. Porque eso no ser\u00eda muy bueno: todos los usuarios quedar\u00edan desconectados, los carritos vac\u00edos, etc. La gente tendr\u00eda que ingresar de nuevo su identificaci\u00f3n y contrase\u00f1a, y muchas personas podr\u00edan desinteresarse y no completar la compra. Nuevamente, la conversi\u00f3n disminuir\u00eda. Por otro lado, Redis tal como est\u00e1, con los \u00faltimos usuarios autenticados, tampoco ser\u00eda necesario. Y un buen compromiso ser\u00eda tomar Redis y restaurarlo desde una copia de seguridad, de ayer, o, si se hace cada hora, de hace una hora. afortunadamente, restaurarlo desde una copia de seguridad es solo copiar un archivo. Y la historia m\u00e1s interesante es Elasticsearch. \u00bfQui\u00e9n ha levantado alguna vez la replicaci\u00f3n de MySQL? \u00bfQui\u00e9n ha levantado alguna vez la replicaci\u00f3n de Elasticsearch? \u00bfY a qui\u00e9n le ha funcionado bien despu\u00e9s? A lo que me refiero: vemos en nuestro sistema alguna entidad. Parece \u00fatil, pero es complicada.
\nEs complicado en el sentido de que nuestros ingenieros no tienen experiencia trabajando con esto. O tienen experiencias negativas. O entendemos que, por ahora, es una tecnolog\u00eda bastante nueva con matices o inestabilidad. Pensamos... Vaya, elastic tambi\u00e9n es pesado, restaurarlo desde la copia de seguridad tambi\u00e9n lleva su tiempo, \u00bfqu\u00e9 hacemos? Entendemos que elastic, en nuestro caso, se utiliza para la b\u00fasqueda. \u00bfY c\u00f3mo vende nuestra tienda en l\u00ednea? Vamos a los mercad\u00f3logos y preguntamos de d\u00f3nde vienen las personas. Ellos responden: 'El 90% proviene de Yandex Market directamente a la p\u00e1gina del producto'. Y o compran, o no. Por lo tanto, la b\u00fasqueda es necesaria solo para el 10% de los usuarios. Y mantener la replicaci\u00f3n de elastic, especialmente entre diferentes centros de datos en diferentes zonas, realmente tiene muchos matices. \u00bfCu\u00e1l es la salida? Tomamos elastic en una plataforma reservada y no hacemos nada con \u00e9l. Si la cosa se alarga, puede que en alg\u00fan momento lo levantemos, pero no es seguro. En realidad, la conclusi\u00f3n es m\u00e1s o menos la misma: los servicios que no impactan en el dinero no los reservamos. Para que el esquema siga siendo m\u00e1s simple.<\/p>\n

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

Ejemplo n\u00famero cuatro, a\u00fan m\u00e1s complicado.<\/h4>\n

\nIntegrador: ventas de flores, llamada de taxis, venta de productos, en general, cualquier cosa. Una cosa seria, que trabaja 24\/7 para un gran n\u00famero de usuarios. Con un stack interesante, donde hay bases interesantes, soluciones, alta carga, y lo m\u00e1s importante, no puede estar inactivo m\u00e1s de 5 minutos. No solo porque la gente no comprar\u00e1, sino porque la gente ver\u00e1 que esto no funciona, se decepcionar\u00e1 y puede que no regresen en el futuro. <\/p>\n

Est\u00e1 bien. Cinco minutos. \u00bfQu\u00e9 vamos a hacer con esto? En este caso, de manera profesional, construimos una verdadera plataforma de respaldo con replicaci\u00f3n de todo y quiz\u00e1s incluso automatizamos al m\u00e1ximo la conmutaci\u00f3n a esta plataforma. Y adem\u00e1s de eso, no hay que olvidar hacer una cosa importante: redactar un protocolo de conmutaci\u00f3n. El protocolo, incluso si todo est\u00e1 automatizado, puede ser muy sencillo. Algo as\u00ed como \"ejecutar este escenario de ansible\", \"en route 53 marcar esta casilla\" y as\u00ed sucesivamente: pero debe ser una lista clara de acciones. <\/p>\n

Y parece que todo est\u00e1 claro. Cambiar la replicaci\u00f3n es una tarea trivial, o se cambiar\u00e1 autom\u00e1ticamente. Reescribir el nombre de dominio en DNS es de la misma serie. El problema es que cuando un proyecto como este falla, comienza la p\u00e1nico, y incluso los administradores m\u00e1s experimentados pueden verse afectados. Sin una instrucci\u00f3n clara \"abre la terminal, entra aqu\u00ed, la direcci\u00f3n de nuestro servidor sigue siendo esta\", es dif\u00edcil cumplir con el plazo de 5 minutos asignado para la reanimaci\u00f3n. Adem\u00e1s, cuando usamos este reglamento, es f\u00e1cil fijar alg\u00fan cambio en la infraestructura, por ejemplo, \u2014 y modificar el reglamento en consecuencia.
\nPero si el sistema de reserva es muy complicado y en alg\u00fan momento cometimos un error, podemos comprometer nuestra plataforma de respaldo y, adem\u00e1s, convertir los datos en calabaza en ambas plataformas \u2014 eso ser\u00eda muy triste. <\/p>\n

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

Ejemplo n\u00famero cinco, pura adrenalina.<\/h4>\n

\nUn servicio internacional con cientos de millones de usuarios en todo el mundo. Todas las zonas horarias que existen, alta carga al m\u00e1ximo, no puede haber ca\u00eddas de ninguna manera. Un minuto y ser\u00e1 triste. \u00bfQu\u00e9 hacer? Reservar, nuevamente, a lo grande. Hicimos todo lo que se mencion\u00f3 en el ejemplo anterior, y un poco m\u00e1s. En un mundo ideal, nuestra infraestructura \u2014 es por todos los conceptos DevOps IaaC. Es decir, todo est\u00e1 en git, y solo tienes que presionar un bot\u00f3n. <\/p>\n

\u00bfQu\u00e9 falta? Una cosa \u2014 ejercicios. Sin ellos no se puede. Parece que todo est\u00e1 perfecto, tenemos todo bajo control. Presionamos el bot\u00f3n, todo sucede. Incluso si as\u00ed fuera \u2014 y entendemos que no es as\u00ed \u2014 nuestro sistema interact\u00faa con otros sistemas. Por ejemplo, con DNS de Route 53, almacenamiento S3, integraci\u00f3n con algunas API. No podremos prever todo en este experimento te\u00f3rico. Y mientras no accionemos realmente el interruptor \u2014 no sabremos si funcionar\u00e1 o no. <\/p>\n

\"Failover:
\n
\nEso es todo, probablemente. No te dejes llevar y no te excedas. \u00a1Y que el uptime est\u00e9 contigo!
\n
Fuente: habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"

\u041b\u0435\u0442\u043e\u043c \u0442\u0440\u0430\u0434\u0438\u0446\u0438\u043e\u043d\u043d\u043e \u0441\u043d\u0438\u0436\u0430\u0435\u0442\u0441\u044f \u0438 \u043f\u043e\u043a\u0443\u043f\u0430\u0442\u0435\u043b\u044c\u0441\u043a\u0430\u044f \u0430\u043a\u0442\u0438\u0432\u043d\u043e\u0441\u0442\u044c, \u0438 \u0438\u043d\u0442\u0435\u043d\u0441\u0438\u0432\u043d\u043e\u0441\u0442\u044c \u0438\u0437\u043c\u0435\u043d\u0435\u043d\u0438\u044f \u0438\u043d\u0444\u0440\u0430\u0441\u0442\u0440\u0443\u043a\u0442\u0443\u0440\u044b \u0432\u0435\u0431-\u043f\u0440\u043e\u0435\u043a\u0442\u043e\u0432, \u0433\u043e\u0432\u043e\u0440\u0438\u0442 \u043d\u0430\u043c \u041a\u0430\u043f\u0438\u0442\u0430\u043d \u041e\u0447\u0435\u0432\u0438\u0434\u043d\u043e\u0441\u0442\u044c. \u041f\u0440\u043e\u0441\u0442\u043e \u043f\u043e\u0442\u043e\u043c\u0443 \u0447\u0442\u043e \u0434\u0430\u0436\u0435 \u0430\u0439\u0442\u0438\u0448\u043d\u0438\u043a\u0438, \u0441\u043b\u0443\u0447\u0430\u0435\u0442\u0441\u044f, \u0445\u043e\u0434\u044f\u0442 \u0432 \u043e\u0442\u043f\u0443\u0441\u043a. \u0418 C\u0422\u041e \u0442\u043e\u0436\u0435. \u0422\u0435\u043c \u0442\u044f\u0436\u0435\u043b\u0435\u0435 \u0442\u0435\u043c, \u043a\u0442\u043e \u043e\u0441\u0442\u0430\u0451\u0442\u0441\u044f \u043d\u0430 \u043f\u043e\u0441\u0442\u0443, \u043d\u043e \u0441\u0435\u0439\u0447\u0430\u0441 \u043d\u0435 \u043e\u0431 \u044d\u0442\u043e\u043c: \u0432\u043e\u0437\u043c\u043e\u0436\u043d\u043e, \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u043e\u044d\u0442\u043e\u043c\u0443 \u043b\u0435\u0442\u043e \u2014 \u043b\u0443\u0447\u0448\u0438\u0439 \u043f\u0435\u0440\u0438\u043e\u0434 \u0434\u043b\u044f \u0442\u043e\u0433\u043e, \u0447\u0442\u043e\u0431\u044b \u043d\u0435 \u0442\u043e\u0440\u043e\u043f\u044f\u0441\u044c \u043e\u0431\u0434\u0443\u043c\u0430\u0442\u044c \u0441\u0443\u0449\u0435\u0441\u0442\u0432\u0443\u044e\u0449\u0443\u044e \u0441\u0445\u0435\u043c\u0443 \u0440\u0435\u0437\u0435\u0440\u0432\u0438\u0440\u043e\u0432\u0430\u043d\u0438\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27235,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36393","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\n","aioseo_head_json":{"title":"\ud83e\udd47Failover: nos destruye el perfeccionismo y... la pereza | ProHoster","description":"En verano, tradicionalmente disminuye tanto la actividad de compra como la intensidad de los cambios en la infraestructura de proyectos web, nos dice el Capit\u00e1n Obvio. Simplemente porque incluso los inform\u00e1ticos, a veces, se van de vacaciones.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/administrirovanie\/failover-nas-gubit-perfektsionizm-i-len","robots":"max-image-preview:large","keywords":"","webmasterTools":{"miscellaneous":""},"schema":null,"og:locale":"es_ES","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\/es\/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\/es\/wp-json\/wp\/v2\/posts\/36393","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/comments?post=36393"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/36393\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/27235"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=36393"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=36393"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=36393"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}