{"id":40138,"date":"2020-01-31T20:49:06","date_gmt":"2020-01-31T17:49:06","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/katastrofoustojchivoe-oblako-kak-eto-rabotaet"},"modified":"2020-01-31T20:49:06","modified_gmt":"2020-01-31T17:49:06","slug":"katastrofoustojchivoe-oblako-kak-eto-rabotaet","status":"publish","type":"post","link":"https:\/\/prohoster.info\/es\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet","title":{"rendered":"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"<p>\u00a1Hola, Habr! <\/p>\n<p>Despu\u00e9s de las festividades de A\u00f1o Nuevo, relanzamos la nube de recuperaci\u00f3n ante desastres con base en dos sitios. Hoy hablaremos de c\u00f3mo est\u00e1 organizada y mostraremos qu\u00e9 ocurre con las m\u00e1quinas virtuales de los clientes en caso de fallas de elementos individuales del cl\u00faster y ca\u00edda de un sitio completo (spoiler: todo sigue funcionando bien). <\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/58b56261b55785a76bce3e754c86f6a9.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Almacenamiento en la nube de recuperaci\u00f3n ante desastres en el sitio OST.<\/i><noindex><a rel=\"nofollow\" name=\"habracut\"><\/a><\/noindex><\/p>\n<h3>Qu\u00e9 hay dentro<\/h3>\n<p>\nEn el n\u00facleo del cl\u00faster hay servidores Cisco UCS con el hipervisor VMware ESXi, dos sistemas de almacenamiento INFINIDAT InfiniBox F2240, equipos de red Cisco Nexus, as\u00ed como switches SAN Brocade. El cl\u00faster est\u00e1 distribuido en dos sitios: OST y NORD, es decir, en cada centro de datos hay un conjunto id\u00e9ntico de hardware. Esto es lo que lo hace resistente a desastres. <\/p>\n<p>Dentro de un sitio, los elementos principales tambi\u00e9n est\u00e1n duplicados (hosts, switches SAN, red).<br \/>\nLos dos sitios est\u00e1n conectados por tramos de fibra \u00f3ptica dedicados, tambi\u00e9n redundantes.<\/p>\n<p>Unas palabras sobre el almacenamiento. La primera versi\u00f3n de la nube de recuperaci\u00f3n ante desastres la construimos sobre NetApp. Aqu\u00ed elegimos INFINIDAT, y aqu\u00ed est\u00e1 el porqu\u00e9:<\/p>\n<ul>\n<li>Opci\u00f3n de replicaci\u00f3n activa-activa. Permite que la m\u00e1quina virtual se mantenga en funcionamiento incluso ante la falla completa de uno de los sistemas de almacenamiento. Hablar\u00e9 sobre la replicaci\u00f3n m\u00e1s adelante.<\/li>\n<li>Tres controladores de disco para mejorar la disponibilidad del sistema. Normalmente hay dos.<\/li>\n<li>Soluci\u00f3n lista. Recibimos un rack ya ensamblado, que solo necesita ser conectado a la red y configurado.<\/li>\n<li>Soporte t\u00e9cnico atento. Los ingenieros de INFINIDAT analizan constantemente los registros y eventos del sistema de almacenamiento, instalan nuevas versiones de firmware, y ayudan con la configuraci\u00f3n.<\/li>\n<\/ul>\n<p>\nAqu\u00ed van algunas fotos del unpacking:<\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/b953a56bba9f0308f5fe1b27b356683b.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/94b5ceb8565ebe1ef2aacff943e1a9d0.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<\/p>\n<h3>C\u00f3mo funciona<\/h3>\n<p>\nLa nube ya es resistente por s\u00ed misma. Protege al cliente contra fallas de hardware y software individuales. Mientras que la recuperaci\u00f3n ante desastres ayuda a protegerse contra fallas masivas dentro de un solo sitio: por ejemplo, falla de un almacenamiento (o cluster SDS, lo que ocurre con frecuencia \ud83d\ude42), errores masivos en la red de almacenamiento, entre otros. Y lo m\u00e1s importante: tal nube ayuda cuando un sitio completo se vuelve inaccesible debido a un incendio, un apag\u00f3n, una toma hostil, o un aterrizaje extraterrestre. <\/p>\n<p>En todos estos casos, las m\u00e1quinas virtuales de los clientes contin\u00faan funcionando, y aqu\u00ed est\u00e1 el porqu\u00e9. <\/p>\n<p>El esquema del cl\u00faster est\u00e1 dise\u00f1ado de tal manera que cualquier host ESXi con m\u00e1quinas virtuales de cliente puede acceder a cualquiera de los dos centros de almacenamiento (SAN). Si el SAN en el sitio de OST falla, las m\u00e1quinas virtuales continuar\u00e1n funcionando: los hosts en los que operan acceder\u00e1n a los datos del SAN en NORD. <\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/996193debdab5b3564c97b05b1e5ba27.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>As\u00ed es como se ve el esquema de conexi\u00f3n en el cl\u00faster. <\/i><\/p>\n<p>Esto es posible gracias a que se ha configurado Inter-Switch Link entre las f\u00e1bricas SAN de los dos sitios: el switch SAN de la F\u00e1brica A OST est\u00e1 conectado al switch SAN de la F\u00e1brica A NORD, de manera similar para los switches SAN de la F\u00e1brica B. <\/p>\n<p>Y para que todas estas complejidades de las f\u00e1bricas SAN tengan sentido, se ha configurado una replicaci\u00f3n activa-activa entre los dos SAN: la informaci\u00f3n se registra pr\u00e1cticamente al mismo tiempo en el SAN local y en el remoto, RPO=0. As\u00ed que, un SAN almacena el original de los datos, mientras que el otro tiene su r\u00e9plica. Los datos se replican a nivel de vol\u00famenes de SAN, y sobre ellos se almacenan los datos de las VM (sus discos, archivos de configuraci\u00f3n, archivos de intercambio, etc.). <\/p>\n<p>El host ESXi ve el volumen principal y su r\u00e9plica como un solo dispositivo de almacenamiento (Storage Device). Desde el host ESXi hacia cada dispositivo de almacenamiento hay 24 caminos:<\/p>\n<p>12 caminos lo conectan con el SAN local (caminos \u00f3ptimos), y los otros 12 - con el remoto (caminos no \u00f3ptimos). En una situaci\u00f3n normal, el ESXi accede a los datos en el SAN local utilizando los caminos '\u00f3ptimos'. Cuando este SAN falla, el ESXi pierde los caminos \u00f3ptimos y se cambia a los 'no \u00f3ptimos'. As\u00ed es como se ve en el esquema.<\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/e2b61eb8b9db4b882a6d20c0abf9fc4e.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<i>Esquema de cl\u00faster de resistencia a desastres.<\/i><\/p>\n<p>Todas las redes de clientes est\u00e1n conectadas a ambos sitios a trav\u00e9s de una infraestructura de red com\u00fan. En cada sitio funciona un Provider Edge (PE), donde se terminan las redes del cliente. Los PE est\u00e1n unidos en un cl\u00faster com\u00fan. Si un PE falla en un sitio, todo el tr\u00e1fico se redirige al segundo sitio. Gracias a esto, las m\u00e1quinas virtuales del sitio que se queda sin PE siguen estando accesibles a trav\u00e9s de la red para el cliente. <\/p>\n<p>Ahora veamos qu\u00e9 suceder\u00e1 con las m\u00e1quinas virtuales del cliente en diversas fallas. Comencemos con las opciones m\u00e1s leves y terminemos con la m\u00e1s seria: la falla de todo el sitio. En los ejemplos, el sitio principal ser\u00e1 OST, y el de respaldo, con r\u00e9plicas de datos, ser\u00e1 NORD.<\/p>\n<h3>\u00bfQu\u00e9 sucede con la m\u00e1quina virtual del cliente si\u2026 <\/h3>\n<p>\n<b>Falla el Replication Link.<\/b> La replicaci\u00f3n entre los SAN de los dos sitios se detiene.<br \/>\nESXi solo funcionar\u00e1 con dispositivos de almacenamiento locales (a trav\u00e9s de rutas \u00f3ptimas). <br \/>\nLas m\u00e1quinas virtuales siguen funcionando.<\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/c15c34e54cb456011f3155b30cbe1063.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Est\u00e1 ocurriendo una ruptura de ISL (Inter-Switch Link).<\/b> Es un caso poco probable. A menos que alg\u00fan excavador loco corte varias l\u00edneas \u00f3pticas que pasan por rutas independientes y est\u00e9n conectadas a los sitios a trav\u00e9s de diferentes entradas. Pero a\u00fan as\u00ed. En este caso, los hosts ESXi perder\u00edan la mitad de las rutas y solo podr\u00edan acceder a sus propias SAN locales. Las r\u00e9plicas se recopilan, pero los hosts no podr\u00e1n acceder a ellas. <\/p>\n<p>Las m\u00e1quinas virtuales funcionan normalmente.<\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/c6c1b8b4972cd90cdb639fffe623bc1d.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Falla un switch SAN en uno de los sitios.<\/b> Los hosts ESXi pierden parte de las rutas a la SAN. En este caso, los hosts en el sitio donde fall\u00f3 el switch funcionar\u00e1n solo a trav\u00e9s de su HBA \u00fanico. <\/p>\n<p>Las m\u00e1quinas virtuales siguen funcionando normalmente.<\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/3325765d426751e8717af20f7f122b90.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Fallen todos los switches SAN en uno de los sitios.<\/b> Supongamos que esto sucede en el sitio OST. En este caso, los hosts ESXi en ese sitio perder\u00e1n todas las rutas a sus dispositivos de almacenamiento. Act\u00faa el mecanismo est\u00e1ndar de VMware vSphere HA: reiniciar\u00e1 todas las m\u00e1quinas virtuales del sitio OST en NORD en un m\u00e1ximo de 140 segundos. <\/p>\n<p>Las m\u00e1quinas virtuales que funcionan en los hosts del sitio NORD operan normalmente.<\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/c7a129691cd4d6c161e165fd55607206.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Falla un host ESXi en uno de los sitios. <\/b>Aqu\u00ed el mecanismo vSphere HA vuelve a activarse: las m\u00e1quinas virtuales del host defectuoso se reinician en otros hosts, ya sea en el mismo sitio o en un sitio remoto. El tiempo de reinicio de la m\u00e1quina virtual es de hasta 1 minuto. <\/p>\n<p>Si fallan todos los hosts ESXi del sitio OST, no hay opci\u00f3n: las VMs se reinician en otro. El tiempo de reinicio es el mismo. <\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/c00fb5078e0c4df1461187d8896670a4.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Falla la SAN en uno de los sitios.<\/b> Supongamos que la SAN fall\u00f3 en el sitio OST. Entonces, los hosts ESXi del sitio OST cambiar\u00e1n a trabajar con las r\u00e9plicas de la SAN en NORD. Despu\u00e9s de que la SAN defectuosa vuelva a estar operativa, se llevar\u00e1 a cabo una replicaci\u00f3n forzada y los hosts ESXi OST volver\u00e1n a acceder a su SAN local. <\/p>\n<p>Las m\u00e1quinas virtuales siguen funcionando normalmente durante todo este tiempo.<\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/87f7e1d012886d963f020768864154a7.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\n<b>Falla uno de los sitios.<\/b> En este caso, todas las m\u00e1quinas virtuales se reiniciar\u00e1n en el sitio de respaldo a trav\u00e9s del mecanismo vSphere HA. El tiempo de reinicio de las VMs es de 140 segundos. Durante esto, todas las configuraciones de red de la m\u00e1quina virtual se mantendr\u00e1n, y seguir\u00e1 siendo accesible para el cliente a trav\u00e9s de la red.<\/p>\n<p>Para que el reinicio de las m\u00e1quinas en la ubicaci\u00f3n de respaldo transcurra sin problemas, cada lugar est\u00e1 ocupado solo a la mitad. La segunda mitad se reserva en caso de trasladar todas las m\u00e1quinas virtuales desde la segunda ubicaci\u00f3n afectada.<\/p>\n<p><img decoding=\"async\" alt=\"Nube de recuperaci\u00f3n ante desastres: c\u00f3mo funciona\" src=\"\/wp-content\/uploads\/2020\/01\/62cad7aaf5043f6879dc4a6cbb7b35bb.jpeg\" style=\"display:block;margin: 0 auto;\" \/><br \/>\n<br \/>\nEste tipo de fallos es lo que protege una nube de alta disponibilidad basada en dos centros de datos. <\/p>\n<p>Este placer no es barato, ya que, adem\u00e1s de los recursos b\u00e1sicos, se necesita una reserva en la segunda ubicaci\u00f3n. Por eso, se alojan en esta nube los servicios cr\u00edticos para el negocio, cuyo largo tiempo de inactividad podr\u00eda generar grandes p\u00e9rdidas financieras y de reputaci\u00f3n, o si hay requisitos de alta disponibilidad requeridos por reguladores o normas internas de la empresa.<\/p>\n<p><b>Fuentes:<\/b><\/p>\n<ol>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/www.infinidat.com\/sites\/default\/files\/resource-pdfs\/DS-INFBOX-190331-US_0.pdf\">www.infinidat.com\/sites\/default\/files\/resource-pdfs\/DS-INFBOX-190331-US_0.pdf<\/a><\/noindex><\/li>\n<li><noindex><a rel=\"nofollow\" href=\"https:\/\/support.infinidat.com\/hc\/en-us\/articles\/207057109-InfiniBox-best-practices-guides\">support.infinidat.com\/hc\/es\/articles\/207057109-pr\u00e1cticas-recomendadas-de-InfiniBox<\/a><\/noindex><\/li>\n<\/ol>\n<p>Fuente: <a content=\"nofollow\" rel=\"nofollow\" href=\"https:\/\/habr.com\/ru\/company\/dataline\/blog\/486186\/\">habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"<p>\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u043e\u0441\u043b\u0435 \u043d\u043e\u0432\u043e\u0433\u043e\u0434\u043d\u0438\u0445 \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u043e\u0432 \u043c\u044b \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043d\u0430 \u0431\u0430\u0437\u0435 \u0434\u0432\u0443\u0445 \u043f\u043b\u043e\u0449\u0430\u0434\u043e\u043a. \u0421\u0435\u0433\u043e\u0434\u043d\u044f \u0440\u0430\u0441\u0441\u043a\u0430\u0436\u0435\u043c, \u043a\u0430\u043a \u044d\u0442\u043e \u0443\u0441\u0442\u0440\u043e\u0435\u043d\u043e, \u0438 \u043f\u043e\u043a\u0430\u0436\u0435\u043c, \u0447\u0442\u043e \u043f\u0440\u043e\u0438\u0441\u0445\u043e\u0434\u0438\u0442 \u0441 \u043a\u043b\u0438\u0435\u043d\u0442\u0441\u043a\u0438\u043c\u0438 \u0432\u0438\u0440\u0442\u0443\u0430\u043b\u044c\u043d\u044b\u043c\u0438 \u043c\u0430\u0448\u0438\u043d\u0430\u043c\u0438 \u043f\u0440\u0438 \u043e\u0442\u043a\u0430\u0437\u0435 \u043e\u0442\u0434\u0435\u043b\u044c\u043d\u044b\u0445 \u044d\u043b\u0435\u043c\u0435\u043d\u0442\u043e\u0432 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0438 \u043f\u0430\u0434\u0435\u043d\u0438\u0438 \u0446\u0435\u043b\u043e\u0439 \u043f\u043b\u043e\u0449\u0430\u0434\u043a\u0438 (\u0441\u043f\u043e\u0439\u043b\u0435\u0440 \u2013 \u0441 \u043d\u0438\u043c\u0438 \u0432\u0441\u0435 \u0445\u043e\u0440\u043e\u0448\u043e). \u0421\u0425\u0414 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0433\u043e \u043e\u0431\u043b\u0430\u043a\u0430 \u043d\u0430 \u043f\u043b\u043e\u0449\u0430\u0434\u043a\u0435 OST. \u0427\u0442\u043e \u0432\u043d\u0443\u0442\u0440\u0438 \u041f\u043e\u0434 \u043a\u0430\u043f\u043e\u0442\u043e\u043c \u0443 \u043a\u043b\u0430\u0441\u0442\u0435\u0440\u0430 \u0441\u0435\u0440\u0432\u0435\u0440\u044b Cisco [&hellip;]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":40139,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[],"tags":[],"class_list":["post-40138","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry"],"aioseo_notices":[],"aioseo_head":"\n\t\t<!-- All in One SEO 5.0.2 - aioseo.com -->\n\t<meta name=\"description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u043e\u0441\u043b\u0435 \u043d\u043e\u0432\u043e\u0433\u043e\u0434\u043d\u0438\u0445 \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u043e\u0432 \u043c\u044b \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043d\u0430 \u0431\u0430\u0437\u0435 \u0434\u0432\u0443\u0445 \u043f\u043b\u043e\u0449\u0430\u0434\u043e\u043a.\" \/>\n\t<meta name=\"robots\" content=\"max-image-preview:large\" \/>\n\t<meta name=\"author\" content=\"Yuri Gagarin\"\/>\n\t<link rel=\"canonical\" href=\"https:\/\/prohoster.info\/es\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet\" \/>\n\t<meta name=\"generator\" content=\"All in One SEO (AIOSEO) 5.0.2\" \/>\n\t\t<meta property=\"og:locale\" content=\"es_ES\" \/>\n\t\t<meta property=\"og:site_name\" content=\"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\" \/>\n\t\t<meta property=\"og:type\" content=\"article\" \/>\n\t\t<meta property=\"og:title\" content=\"\ud83e\udd47\u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e: \u043a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 | ProHoster\" \/>\n\t\t<meta property=\"og:description\" content=\"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u043e\u0441\u043b\u0435 \u043d\u043e\u0432\u043e\u0433\u043e\u0434\u043d\u0438\u0445 \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u043e\u0432 \u043c\u044b \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043d\u0430 \u0431\u0430\u0437\u0435 \u0434\u0432\u0443\u0445 \u043f\u043b\u043e\u0449\u0430\u0434\u043e\u043a.\" \/>\n\t\t<meta property=\"og:url\" content=\"https:\/\/prohoster.info\/es\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet\" \/>\n\t\t<meta property=\"og:image\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:secure_url\" content=\"https:\/\/prohoster.info\/wp-content\/uploads\/2021\/11\/logo-350.jpg\" \/>\n\t\t<meta property=\"og:image:width\" content=\"350\" \/>\n\t\t<meta property=\"og:image:height\" content=\"350\" \/>\n\t\t<meta property=\"article:published_time\" content=\"2020-01-31T17:49:06+00:00\" \/>\n\t\t<meta property=\"article:modified_time\" content=\"2020-01-31T17:49:06+00:00\" \/>\n\t\t<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/prohoster\" \/>\n\t\t<!-- All in One SEO -->\n\n","aioseo_head_json":{"title":"\ud83e\udd47Nube de alta disponibilidad: c\u00f3mo funciona | ProHoster","description":"\u00a1Hola, Habr! Despu\u00e9s de las festividades de A\u00f1o Nuevo, relanzamos la nube de alta disponibilidad basada en dos ubicaciones.","canonical_url":"https:\/\/prohoster.info\/es\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet","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\udd47\u041a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e: \u043a\u0430\u043a \u044d\u0442\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442 | ProHoster","og:description":"\u041f\u0440\u0438\u0432\u0435\u0442, \u0425\u0430\u0431\u0440! \u041f\u043e\u0441\u043b\u0435 \u043d\u043e\u0432\u043e\u0433\u043e\u0434\u043d\u0438\u0445 \u043f\u0440\u0430\u0437\u0434\u043d\u0438\u043a\u043e\u0432 \u043c\u044b \u043f\u0435\u0440\u0435\u0437\u0430\u043f\u0443\u0441\u0442\u0438\u043b\u0438 \u043a\u0430\u0442\u0430\u0441\u0442\u0440\u043e\u0444\u043e\u0443\u0441\u0442\u043e\u0439\u0447\u0438\u0432\u043e\u0435 \u043e\u0431\u043b\u0430\u043a\u043e \u043d\u0430 \u0431\u0430\u0437\u0435 \u0434\u0432\u0443\u0445 \u043f\u043b\u043e\u0449\u0430\u0434\u043e\u043a.","og:url":"https:\/\/prohoster.info\/es\/blog\/katastrofoustojchivoe-oblako-kak-eto-rabotaet","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":"2020-01-31T17:49:06+00:00","article:modified_time":"2020-01-31T17:49:06+00:00","article:publisher":"https:\/\/www.facebook.com\/prohoster","article:author":"https:\/\/www.facebook.com\/prohoster"},"aioseo_meta_data":{"post_id":"40138","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":null,"breadcrumb_settings":null,"limit_modified_date":false,"reviewed_by":null,"ai":null,"created":"2021-03-01 00:44:38","updated":"2022-09-28 05:19:32","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\/40138","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=40138"}],"version-history":[{"count":0,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/posts\/40138\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media\/40139"}],"wp:attachment":[{"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/media?parent=40138"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/categories?post=40138"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/prohoster.info\/es\/wp-json\/wp\/v2\/tags?post=40138"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}