Pensando en la migración y la tolerancia a desastres bajo la tendencia de nativos en la nube

Fuente | Cuenta oficial nativa de Alibaba Cloud

Autor | Sun Qi

Introducción: ¿El próximo campo de subversión nativa de la nube estará en el campo tradicional de recuperación ante desastres? Bajo la tendencia de la nube nativa, ¿cómo construir soluciones de migración de sistemas de aplicaciones y recuperación de desastres?

tendencia

1. Tendencia de desarrollo nativo en la nube

Cloud Native es un tema muy candente en los últimos años. El "Informe técnico sobre desarrollo nativo en la nube (2020)" publicado por la Academia de Tecnología de la Información y las Comunicaciones en julio de 2020 señaló claramente que ha llegado el punto de inflexión de la computación en la nube y que la tecnología nativa en la nube se ha convertido en el motor del negocio. Un importante motor de crecimiento. No es difícil encontrar que el nativo de la nube trae una reorganización de la industria de TI Desde el proceso de desarrollo de aplicaciones hasta las capacidades técnicas de los profesionales de TI, es una revolución disruptiva. Sobre esta base, apareció la definición del modelo de aplicación abierta basada en la plataforma nativa de la nube, que se resumió aún más sobre la base de la plataforma nativa de la nube, centrándose más en la aplicación que en la infraestructura. Al mismo tiempo, cada vez más nubes públicas están comenzando a admitir servicios sin servidor, lo que ilustra aún más la tendencia de desarrollo futuro: las aplicaciones son el núcleo y el papel de la capa de infraestructura ligera en el proceso de construcción del sistema. Pero no importa cuál sea el cambio, la dirección general del desarrollo de TI debe evolucionar en una dirección que sea más propicia para una iteración comercial rápida y para satisfacer las necesidades comerciales.

En septiembre de 2020, Snowflake creó la oferta pública inicial más grande de este año con una oferta pública inicial de US $ 120 por acción y la oferta pública inicial de software más grande de la historia. Snowflake reestructuró el almacén de datos utilizando un enfoque nativo de la nube y subvirtió con éxito el panorama de competencia de la industria. Este es el mejor reconocimiento del mercado de la tendencia de desarrollo nativa de la nube, entonces, ¿la próxima área de subversión nativa de la nube estará en el área tradicional de recuperación ante desastres?

2. ¿Por qué se necesita una nueva migración y tolerancia a desastres en la nube?

1) Limitaciones de las soluciones tradicionales

Bajo esta tendencia general, la migración tradicional y la recuperación ante desastres aún permanecen en el nivel de manejo de datos, mientras se ignoran las características orientadas a la nube y el replanteamiento y construcción del negocio de los usuarios. La visión de la computación en la nube es permitir que los recursos de la nube se utilicen bajo demanda, como agua y electricidad, por lo que la migración basada en la nube y la tolerancia a los desastres también deben ajustarse a esta tendencia histórica. Snowflake también logró romper el antiguo panorama competitivo a través de esta innovación de modelo de negocio.

¿Por qué los métodos tradicionales de recuperación ante desastres no pueden satisfacer las necesidades de la nube nativa? En pocas palabras, el núcleo de las dos preocupaciones es diferente. La recuperación de desastres tradicional a menudo toma el almacenamiento como núcleo y tiene un control supremo sobre el almacenamiento. Y en la era física, no existen métodos de programación efectivos para las capas de infraestructura, como computación, almacenamiento y redes, y no se puede lograr una orquestación altamente automatizada. El núcleo de las aplicaciones creadas en la nube se convierte en el propio servicio nativo de la nube. Cuando el sistema empresarial del usuario está completamente implementado en la nube, el usuario ya no tiene control absoluto sobre el almacenamiento subyacente, por lo que los métodos tradicionales de recuperación ante desastres se han ido.

Creo que al crear una solución de recuperación ante desastres nativa de la nube, es necesario pensar en el método de construcción con el negocio como núcleo y utilizar las capacidades de orquestación de los servicios nativos de la nube para lograr la continuidad del sistema empresarial.

2) seguridad de los datos

El CTO de AWS, Werner Vogels, dijo una vez: Todo falla, todo el tiempo. A través del modelo de responsabilidad compartida de AWS, no es difícil encontrar que los proveedores de la nube sean responsables de la infraestructura subyacente y que los usuarios sigan siendo responsables de su propia seguridad de datos y continuidad comercial.

Creo que bajo la tendencia nativa de la nube, el atractivo más directo de los usuarios proviene de la seguridad de los datos, es decir, la copia de seguridad. La migración, la recuperación y la alta confiabilidad se basan en la forma de negocio que muestra la copia de seguridad, y las capacidades de copia de seguridad pueden ser proporcionadas por las capacidades nativas de la nube. También puede ser proporcionado por capacidades de terceros, pero la realización final de la forma comercial la produce la orquestación.

El hecho de que los usuarios se pasen a la nube no significa estar sentados de un lado a otro, al contrario, los usuarios deben aprender la forma correcta de abrir la nube para garantizar la continuidad del negocio en la mayor medida posible. Aunque la nube es altamente confiable en el diseño subyacente, todavía no puede evitar la influencia causada por fuerzas externas, tales como: el área disponible de la plataforma en la nube no se puede usar debido al corte del cable óptico, la falla de energía y el error humano. Decidió la estabilidad de la computación en nube de China "ridículo". Creo que desde el momento en que un usuario decide migrar su negocio a la nube, la copia de seguridad, la migración, la recuperación y la alta confiabilidad son un proceso continuo. Cómo hacer un uso razonable de las características de los servicios nativos de la nube para lograr la continuidad del negocio, optimizando los costos y reduciendo la propiedad general Costo (TCO).

3) Evitar el bloqueo del proveedor

En cierto sentido, la dirección de la nube nativa es una nueva ronda de bloqueo de proveedores, al igual que la arquitectura IOE que prevaleció en ese entonces, excepto que ahora es reemplazada por proveedores de nube como base para llevar aplicaciones. En la era IOE, es difícil para los usuarios encontrar un sustituto perfecto, pero en la era de la nube, esta diferencia no es tan obvia. Por lo tanto, la mayoría de los clientes generalmente eligen la nube híbrida como una estrategia de construcción de la nube. Para permitir que las aplicaciones se muevan sin problemas entre diferentes nubes, la migración mediante tecnología de tolerancia a desastres debe existir como un requisito normalizado. Gartnar también considera la migración y la recuperación ante desastres como una capacidad separada en la definición de plataforma de administración de múltiples nubes. Ilustra completamente la tendencia de normalización de la migración y la recuperación ante desastres en un entorno de múltiples nubes.

La relación entre la migración a la nube y la recuperación ante desastres en la nube

1. La aparición de requisitos de migración a la nube

En el entorno tradicional, la necesidad de migración no es muy importante. A menos que se trate de una reubicación de una sala de computadoras o una actualización de hardware, se pensará en la migración. Sin embargo, la migración aquí es más como un movimiento de hierro, y la necesidad de herramientas y automatización de la migración no es obvia. Cuando apareció VMware, la demanda de migración del entorno físico a la virtualización se incrementó, pero debido a que era una plataforma de virtualización única, las herramientas propias de los proveedores de virtualización básicamente pudieron satisfacer las necesidades. En la plataforma de virtualización, todos descubrieron de repente que el entorno físico original que solo se podía operar manualmente se volvió más liviano. En pocas palabras, nuestro servidor tradicional ha cambiado de una pila de hierro a un archivo, y este archivo se puede mover y copiar de un lado a otro. . Más tarde, en la era de la nube, florecieron varias plataformas en la nube, y el mercado doméstico de la computación en la nube era aún más competitivo, y el paso a la nube se convirtió en una demanda rígida. Con el tiempo, debido al impacto de muchos factores, como el costo y la dependencia del proveedor, la migración mutua entre diferentes nubes se convertirá en una demanda normalizada.

2. La tecnología subyacente es consistente

La migración a la nube y la recuperación ante desastres mencionadas aquí no son servicios de migración proporcionados por Hei Ren, sino un medio altamente automatizado. El objetivo es garantizar la continuidad del negocio durante el proceso de migración, reducir el tiempo de inactividad o incluso el efecto ininterrumpido. Aquí, la tecnología de sincronización de nivel de almacenamiento tolerante a desastres se utiliza para realizar una "migración en caliente" en un entorno heterogéneo. Las soluciones existentes incluyen tanto software de migración de la era tradicional de reubicación de máquinas físicas como herramientas basadas en el desarrollo nativo de la nube. Pero no importa cuál sea la forma, ha resuelto las demandas básicas de los usuarios de ir a la nube en diversos grados. La mayor diferencia radica en la relación entre personas y eficiencia, que está directamente relacionada con sus intereses.

Desde otra perspectiva, no es difícil encontrar que la llamada migración es esencialmente un proceso intermedio de recuperación ante desastres antes del cambio oficial. Al mismo tiempo, una vez que el sistema empresarial se migra a la plataforma en la nube, la recuperación ante desastres es una acción continua, que incluye no solo el respaldo tradicional y la recuperación ante desastres, sino también el concepto de alta confiabilidad en la nube. De esta manera, el sistema empresarial del usuario puede deshacerse de la carga de la infraestructura tradicional, lograr una "operación y mantenimiento cero" y disfrutar verdaderamente de los dividendos que brinda la nube. Por lo tanto, creo que en el estado nativo de la nube, la migración a la nube, la recuperación de desastres en la nube y la copia de seguridad en la nube son esencialmente una forma comercial, y los medios técnicos subyacentes pueden ser completamente consistentes.

3. Dirección de desarrollo

Bajo los puntos débiles y las tendencias antes mencionados, inevitablemente aparecerá una plataforma nueva para ayudar a los clientes a resolver los problemas de seguridad de los datos y continuidad del negocio. Hoy, analizaremos desde esta perspectiva cómo construir sistemas de aplicaciones bajo la tendencia de los nativos de la nube. Plan de migración y recuperación ante desastres.

Tendencia de desarrollo de la migración a la nube

1. Método de migración a la nube

La migración es un negocio de consultoría pesado. Cada proveedor de nube y MSP en Internet tiene sus propias metodologías. De hecho, no parecen ser muy diferentes. Muchas personas están compartiendo temas relacionados antes, así que no los repetiré en este artículo. Aquí nos enfocamos en discutir qué herramienta usar en el proceso de aterrizaje real y qué método es el más eficiente. La llamada herramienta de migración a la nube consiste en migrar el extremo de origen al extremo de destino para garantizar que el extremo de origen se ejecute correctamente en el extremo de destino. Los métodos comunes incluyen: máquina física a virtualización, virtualización a virtualización, máquina física a plataforma de nube, virtualización a plataforma de nube, etc.

Esta es la teoría clásica de la migración 6R (ahora se ha actualizado a 7R, y VMware ha salido a estropear la situación). En esta imagen, la única migración real relacionada con Rehosting, Replatforming, Refactoring y Refactoring, pero en este 4R, Refactoring es obviamente uno El proceso iterativo a largo plazo requiere la participación de usuarios y desarrolladores de software. La recompra no es básicamente muy diferente de la reubicación manual. Por lo tanto, solo el Rehosting y Replatofrming deben ser completados por el usuario o MSP en un corto período de tiempo.

En comparación con la teoría de la migración clásica anterior, prefiero la siguiente imagen, que refleja mejor todo el proceso de una aplicación tradicional para el crecimiento nativo en la nube. De manera similar a las conclusiones anteriores, cuando realmente aceptamos la nube, básicamente seguimos los tres caminos anteriores:

• Lift & Shift es otro nombre para el método Rehost. Este método tiene la superficie de la carretera más ancha, lo que significa que esta carretera es la ruta más corta a la nube y la aplicación no necesita ninguna modificación para ir directamente a la nube.

• Tanto Evolve como Go Native son caminos estrechos, lo que significa que en comparación con el método Rehost, estos dos caminos toman más tiempo y son más difíciles.

• En el extremo derecho de la figura, las tres formas se pueden convertir entre sí y eventualmente evolucionar a una nube nativa completa, lo que significa que la migración no se logra de la noche a la mañana y debe completarse paso a paso.

2. Método de rehospedaje

Los métodos de realojamiento más utilizados son la migración en frío y la migración en caliente. La migración en frío a menudo implica pasos engorrosos, requiere una gran cantidad de mano de obra, es propensa a errores y tiene una baja eficiencia, tiene un mayor impacto en la continuidad del negocio y no es adecuada para la migración del sistema de producción. Las soluciones de migración en caliente son básicamente soluciones comerciales, que se dividen en nivel de bloque y nivel de archivo, y luego se subdividen en soluciones tradicionales y soluciones nativas de la nube.

1) Migración fría

Echemos un vistazo a la solución de migración en frío manual. Tome VMware a OpenStack como ejemplo. La forma más sencilla es convertir el archivo de máquina virtual de VMware (VMDK) a través de la herramienta qemu-img, convertirlo a formato QCOW2 o RAW y subirlo a OpenStack Eche un vistazo al servicio y luego reinicie en la plataforma en la nube. Por supuesto, se requiere la inyección del controlador virtio; de lo contrario, el host no puede iniciarse normalmente en la plataforma en la nube. El proceso que lleva más tiempo en este proceso debería ser el proceso de carga de archivos de máquina virtual al servicio OpenStack Glance En nuestra primera práctica, un host tardaba 24 horas completas en migrar desde el principio hasta el principio. Al mismo tiempo, los datos durante el período de migración se generan de forma incremental. A menos que cierre la fuente y espere a que se complete la migración, debe repetir los pasos anteriores. Por tanto, este método no es adecuado para migrar sistemas de producción con continuidad empresarial.

Entonces, ¿qué pasa si se trata de una solución de migración en frío para máquinas físicas? Después de nuestra mejor práctica, aquí está la antigua herramienta de copia de seguridad CloneZilla, que se llama Regenerative Dragon en chino. Es un software de copia de seguridad muy anticuado, que a menudo se utiliza para realizar copias de seguridad y recuperación de toda la máquina, y es muy similar a nuestro principio común Norton Ghost. CloneZilla se replica desde el nivel de bloque subyacente, puede realizar una copia de seguridad de todo el disco y admite varios destinos. Por ejemplo, guardamos el disco en un disco duro móvil. El formato real es RAW. Solo necesita repetir la solución anterior para completar la migración. Sin embargo, en el proceso de uso de CloneZilla, debe usar Live CD para arrancar y también enfrentará el problema de la interrupción del sistema comercial a largo plazo.Es por eso que la migración en frío mencionada anteriormente no es adecuada para la migración del entorno de producción.

2) Solución de migración térmica tradicional

El esquema tradicional de migración en caliente se divide básicamente en nivel de bloque y nivel de archivo. Las similitudes entre los dos se realizan mediante tecnología de sincronización diferencial, es decir, sincronización cruzada completa e incremental.

Las soluciones de migración en caliente a nivel de archivo suelen ser más limitadas y no pueden considerarse como un verdadero método de ReHost, porque el sistema operativo original debe prepararse en el extremo de origen y no se puede reubicar la máquina completa. Por la complejidad de la operación y la estabilidad de la migración No es demasiado alto. Rsync, que usamos comúnmente en Linux, en realidad puede usarse como una solución para la migración en vivo a nivel de archivo.

Realice el esquema de migración en caliente, pero también use la sincronización a nivel de bloque para reducir la dependencia del sistema operativo subyacente y darse cuenta del efecto de reubicación de toda la máquina. La solución tradicional de migración en caliente a nivel de bloque proviene básicamente de una variante de la solución tradicional de recuperación ante desastres, que se implementa mediante el sistema operativo de memoria WIN PE u otro Live CD. El principio básico y el proceso se muestran en la siguiente figura. A partir del proceso, no es difícil encontrar que, aunque este enfoque resuelve el objetivo de migración en cierta medida, todavía tiene las siguientes deficiencias como requisito de migración normalizado para la nube híbrida en el futuro:

• Dado que la solución de migración térmica tradicional se basa en el entorno físico, encontramos que hay muchas intervenciones humanas en todo el proceso, lo que requiere habilidades relativamente altas para los usuarios.

• Incapaz de satisfacer las necesidades de tenencia múltiple y autoservicio en la era nativa de la nube

• Instalar un agente es un eterno agravio en el corazón de los usuarios

• El método de sincronización uno a uno no es económico en términos de costo

• El mejor método de verificación de la migración es restaurar completamente el clúster del sistema empresarial en la nube, pero el método de verificación manual aumenta nuevamente el costo laboral de la migración.

3) Solución de migración en caliente nativa de la nube

Es precisamente debido a las deficiencias de la solución de migración tradicional que ha surgido una solución de migración en caliente nativa de la nube. El proveedor representativo a este respecto es el proveedor israelí de migración y recuperación de desastres nativo de la nube CloudEndure, que fue adquirido por AWS para vencer a Google Cloud por $ 250 millones en 2019. .

La solución de migración en caliente nativa de la nube se refiere al uso de tecnología de sincronización diferencial a nivel de bloque combinada con interfaces y recursos de API nativos de la nube para lograr un efecto de migración altamente automatizado, al tiempo que proporciona interfaces de API y de múltiples inquilinos para satisfacer las necesidades de autoservicio de los inquilinos de la nube híbrida. Primero analicemos desde una perspectiva de principio, por qué el enfoque nativo de la nube puede satisfacer la experiencia de usuario altamente automatizada y de autoservicio en comparación con las soluciones tradicionales. Al comparar las dos soluciones, no es difícil encontrar varias ventajas del enfoque nativo de la nube:

• Utilice la interfaz y los recursos de la API nativa de la nube, fácil de operar, reemplace por completo una gran cantidad de operaciones manuales engorrosas de las soluciones tradicionales, reduzca los requisitos técnicos para los usuarios y reduzca en gran medida la complejidad del aprendizaje

• Debido a la operación simple y la eficiencia de migración mejorada, mejora de manera efectiva la relación de eficiencia humana de la implementación de la migración

• El modo de sincronización uno a muchos reduce en gran medida el uso de recursos informáticos, que solo se utilizan durante la verificación y la conmutación final

• Capaz de cumplir con los requisitos de arrendamiento múltiple y autoservicio

• El extremo de origen también puede admitir el modo sin agente, disipar las dudas del usuario y es adecuado para la migración por lotes a gran escala

• Medios de verificación altamente automatizados, que se pueden verificar repetidamente antes de completar la migración y el cambio

Este es el diagrama de arquitectura de CloudEndure. Por supuesto, también puede utilizar CloudEndure para lograr la recuperación de desastres entre regiones.

Sin embargo, es una lástima que debido a la adquisición por parte de AWS, CloudEndure actualmente solo puede admitir la migración a AWS y no puede satisfacer las necesidades de varias migraciones a la nube nacionales. Así que aquí recomiendo una plataforma de migración puramente localizada: HyperMotion de Wanbo Zhiyun, que es muy similar en principio a CloudEndure. También admite la migración sin agentes de VMware y OpenStack y, lo que es más importante, cubre la propiedad pública general en China. Migración a la nube, la nube propietaria y la nube privada.

3. Método de reequipamiento

A medida que la nube nativa proporciona más y más servicios, se reduce la complejidad de la arquitectura de la aplicación, lo que permite a las empresas centrarse más en su propio desarrollo empresarial. Sin embargo, la carga de trabajo reducida en el lado de I + D significa que esta parte del costo se ha transferido a los enlaces de implementación, operación y mantenimiento, por lo que DevOps se ha convertido en una mitigación indispensable en las aplicaciones nativas de la nube y también permite a las empresas responder de manera más ágil a cambios complejos en el negocio.

Como se mencionó anteriormente, los usuarios pueden utilizar preferentemente algunos servicios nativos de la nube a través de una pequeña cantidad de transformación. Este método de migración se llama reconstrucción de plataforma (replanteamiento). Actualmente, la migración del modo de reconstrucción de plataforma se basa principalmente en servicios relacionados con los datos del usuario. . Los más comunes incluyen: servicio de base de datos RDS, servicio de almacenamiento de objetos, servicio de cola de mensajes, servicio de contenedor, etc. La introducción de estos servicios nativos de la nube ha reducido los costos de operación y mantenimiento del usuario. Sin embargo, debido a que el servicio nativo de la nube en sí está muy bien encapsulado y la capa de infraestructura subyacente es completamente invisible para los usuarios, la migración no se puede realizar utilizando el método Rehost mencionado anteriormente, y se deben usar otros medios auxiliares para completar la migración.

Tomando las bases de datos relacionales como ejemplo, casi todas las nubes proporcionan herramientas de migración, como AWS DMS, DTS de Alibaba Cloud y el servicio de transmisión de datos de Tencent Cloud DTS. Estas herramientas nativas de la nube pueden admitir MySQL, MariaDB, PostgreSQL, Redis, Migración de varias bases de datos relacionales como MongoDB y bases de datos NoSQL. Tome MySQL como ejemplo: estos servicios utilizan inteligentemente la replicación binlog para realizar la migración de bases de datos en línea.

Tomemos el almacenamiento de objetos como ejemplo. Casi todas las nubes proporcionan sus propias herramientas de migración. Por ejemplo, las herramientas ossimport de Alibaba Cloud y Tencent Cloud COS Migration pueden implementar la migración incremental del almacenamiento de objetos local a la nube. Sin embargo, en la migración real, también se debe considerar el costo. El objeto de nube pública es relativamente barato para almacenar datos, pero al leer los datos, se cobra en función del tráfico de la red y la cantidad de solicitudes, lo que nos obliga a diseñar el plan de migración. Cuándo, considere completamente el factor de costo. Si la cantidad de datos es demasiado grande, también puede considerar el uso de dispositivos sin conexión, como Snowball de AWS, Lightning Cube de Alibaba Cloud, etc. Esta parte no se presentará y se la presentaré por separado en el futuro.

Si elige el método de reconstrucción de la plataforma para ir a la nube, además de la transformación de la aplicación necesaria, también debe elegir una herramienta de migración que se adapte a sus necesidades para garantizar una migración de datos fluida a la nube. Combinado con la migración del modo Rehost anterior, se puede lograr el efecto de nube general del sistema empresarial. Dado que hay muchos servicios involucrados, aquí hay un formulario de herramienta de migración para su referencia.

Tendencia de desarrollo de recuperación ante desastres en entornos nativos de la nube

Hasta ahora, no ha habido un conjunto de plataformas que puedan cumplir por completo con los requisitos de recuperación de desastres unificada en el estado nativo de la nube. Analicemos cómo construir una plataforma de recuperación de desastres unificada para satisfacer las necesidades de los nativos de la nube a través de los siguientes escenarios.

1. Arquitectura tradicional

Tomemos como ejemplo un entorno simple de Wordpress + MySQL. El entorno de implementación tradicional generalmente está estructurado así:

Si diseña una solución de tolerancia a desastres para esta arquitectura de aplicación, puede utilizar los siguientes métodos:

1) Recuperación ante desastres del nodo de equilibrio de carga

El equilibrio de carga se divide en niveles de hardware y software. La alta fiabilidad y tolerancia a desastres del equilibrio de carga de hardware a menudo se logra a través de sus propias soluciones. Si se trata de un software de equilibrio de carga, a menudo es necesario instalarlo en el sistema operativo básico. La recuperación ante desastres en la misma ciudad se puede lograr mediante software de alta confiabilidad. La recuperación ante desastres en ubicaciones remotas a menudo se realiza estableciendo nodos del mismo nivel por adelantado o simplemente utilizando software de recuperación ante desastres. Se logra la recuperación ante desastres a nivel de archivo o bloque. Es una parte muy importante de la conmutación por error.

2) Recuperación ante desastres del servidor web

El entorno operativo de Wordpress no es más que Apache + PHP. Debido a que el sistema de archivos utilizado para almacenar las cargas de los usuarios está separado, el nodo es casi sin estado. Se puede lograr una alta confiabilidad expandiendo el nodo, y la recuperación remota de desastres es relativamente simple. Tradicional Tanto el nivel de bloque como el nivel de archivo pueden satisfacer las necesidades de recuperación ante desastres.

3) Recuperación ante desastres del sistema de archivos compartidos

La figura utiliza el sistema de archivos Gluster. Dado que la consistencia del sistema distribuido generalmente se mantiene internamente, es difícil asegurar la consistencia de los nodos usando solo el nivel de bloque, por lo que la recuperación de desastres a nivel de archivo es más precisa.

4) Tolerancia a desastres de la base de datos

Basarse únicamente en el nivel de almacenamiento no puede lograr fundamentalmente la pérdida de datos en la base de datos 0, por lo que generalmente se implementa a nivel de base de datos. Por supuesto, si para reducir los costos, la recuperación de desastres de la base de datos se puede lograr simplemente utilizando la base de datos de volcado de ciclo, por supuesto, si los requisitos de confiabilidad Alto, también puede usar CDP para lograrlo.

A partir del análisis de caso anterior, no es difícil ver que la recuperación ante desastres en la infraestructura tradicional a menudo toma el almacenamiento como el núcleo, ya sea la duplicación de almacenamiento de matrices de discos o el bloque de datos de E / S, la tecnología de captura a nivel de bytes, combinada con la red, la base de datos y La tecnología de nivel de aplicación del clúster completa la construcción de un sistema altamente confiable y tolerante a desastres. Los principales participantes en todo el proceso de recuperación de desastres son: host, almacenamiento, red y software de aplicación, que son relativamente únicos. Por lo tanto, en las soluciones tradicionales de recuperación ante desastres, cómo resolver correctamente la recuperación ante desastres del almacenamiento se ha convertido en la clave para resolver el problema.

2. Recuperación ante desastres en la nube híbrida

Esta debería ser la solución de nube híbrida más común en la actualidad, y también es un método recomendado por los principales proveedores de recuperación ante desastres. Aquí somos equivalentes a tratar la plataforma en la nube como un conjunto de plataformas de virtualización, y casi no usamos ninguna característica de la plataforma en la nube. En el proceso de recuperación, se requiere una gran cantidad de acceso humano para restaurar el sistema empresarial a un estado utilizable. Dicha arquitectura no se ajusta a las mejores prácticas en la nube, pero de hecho es un retrato real de muchos sistemas comerciales después de realizar una copia de seguridad o migrarlos a la nube.

De hecho, una arquitectura de este tipo puede resolver el problema de la tolerancia a los desastres, pero es muy costosa. Ahora cambiémosla. Usamos almacenamiento de objetos y base de datos para una optimización. Almacenamos el servicio de almacenamiento original en el almacenamiento de objetos y utilizamos el servicio de transferencia de datos para la replicación de la base de datos en tiempo real. El host en la nube todavía usa el nivel de bloque tradicional para la sincronización. Una vez que ocurre una falla, debe automatizar la capacidad de orquestación, restaurar la copia de seguridad nuevamente y restaurarla de acuerdo con nuestro plan preestablecido en el menor tiempo posible para completar la recuperación ante desastres.

3. Arquitectura de recuperación ante desastres en la nube en la misma ciudad

El método de copia de seguridad mencionado anteriormente es esencialmente una migración mediante la reconstrucción de la plataforma. Ahora que la migración se ha utilizado para la copia de seguridad, se pueden realizar las siguientes transformaciones en la arquitectura para formar una arquitectura de tolerancia a desastres en la misma ciudad. De acuerdo con las mejores prácticas de la plataforma en la nube, hemos realizado los siguientes ajustes a la arquitectura:

Esta arquitectura no solo logra una alta confiabilidad a nivel de aplicación, sino que también admite un cierto nivel de alta concurrencia.Los usuarios pueden lograr efectos duales activos en la misma ciudad con costos de transformación mínimos. Analicemos cuántos servicios nativos de la nube se utilizan en la nube:

• Servicio de resolución de nombres de dominio
• Servicio de VPC
• Servicio de equilibrio de carga
• Servicio de escalado automático
• Servicio de alojamiento en la nube
• Servicio de almacenamiento de objetos
• Servicio RDS de base de datos relacional

Además de los hosts en la nube, otros servicios admiten naturalmente una alta disponibilidad en todas las zonas de disponibilidad. Para los hosts en la nube, podemos crear métodos de duplicación, y el servicio de escalado automático es responsable del estado de la instancia. Dado que la zona de disponibilidad en la nube es el concepto de recuperación ante desastres dentro de la ciudad, aquí hemos implementado la recuperación ante desastres del sistema empresarial dentro de la ciudad.

La arquitectura ajustada cumple con los requisitos de continuidad del negocio hasta cierto punto, pero aún carece de garantía para la seguridad de los datos. En los últimos años, el ransomware ha sido rampante y un gran número de empresas han sufrido enormes pérdidas por ello, por lo que es necesario implementar una copia de seguridad de los datos después de pasar a la nube. Los propios servicios nativos de la nube brindan soluciones de respaldo, como instantáneas regulares de los hosts en la nube, pero a menudo los servicios están dispersos y no es fácil administrarlos de manera unificada. Al mismo tiempo, durante la restauración, solo se puede restaurar cada servicio. Si la escala del sistema empresarial es grande, también aumentará mucho los costos de restauración. Si bien los servicios nativos de la nube resuelven sus propios problemas de respaldo, la reorganización de los respaldos en aplicaciones requiere el uso de capacidades de orquestación automatizadas.

4. La misma arquitectura de recuperación ante desastres remota y en la nube

La mayoría de los servicios nativos de la nube se encuentran en la zona de disponibilidad y brindan capacidades de alta confiabilidad, pero para las copias de seguridad entre regiones, generalmente se brindan capacidades. Por ejemplo: el host en la nube se puede convertir en un espejo y el espejo se puede copiar a otras regiones; las bases de datos relacionales y el almacenamiento de objetos también tienen capacidades de respaldo entre dominios. Usando las capacidades de respaldo de estos componentes y las capacidades de orquestación de los recursos propios de la nube, podemos restaurar el sistema a un estado utilizable en el dominio disponible tolerante a desastres. ¿Cómo activar el interruptor?

Aquí personalizamos las alarmas en el monitoreo nativo de la nube en función de las características del sistema empresarial y utilizamos las capacidades de activación de la plataforma de alarmas para activar los cálculos de funciones para completar la conmutación entre dominios del sistema empresarial y formar el efecto de la recuperación remota de desastres.

5. Recuperación de desastres entre nubes

Sin embargo, la recuperación ante desastres entre nubes no es como la misma recuperación ante desastres en la nube. Al menos los servicios son coherentes entre las diferentes zonas de disponibilidad. En este momento, los métodos utilizados en la misma nube básicamente fallan y se requieren las capacidades de la plataforma de nube de destino o la neutralidad. Soluciones de terceros. Además de la copia de seguridad de datos, otro punto es la coincidencia de configuraciones de servicio. Para satisfacer plenamente las necesidades de recuperación y recuperación ante desastres entre nubes. Otro punto a considerar es el costo, tomando el almacenamiento de objetos como ejemplo, es típico de "fácil ir a la nube y difícil ir a la nube". Por lo tanto, cómo utilizar las características de los recursos nativos de la nube para diseñar de manera racional soluciones de recuperación ante desastres es una gran prueba de costos.

para resumir

La tolerancia a desastres nativa de la nube aún se encuentra en sus primeras etapas, y actualmente no existe una plataforma completa que pueda soportar los requisitos de tolerancia a desastres de los diversos escenarios anteriores, que es un tema digno de exploración continua. La recuperación ante desastres nativa de la nube toma la copia de seguridad como núcleo y toma la migración, la recuperación y la alta confiabilidad como escenarios comerciales para lograr el flujo libre entre múltiples nubes y, en última instancia, satisfacer las necesidades comerciales de los usuarios.

Por lo tanto, como plataforma de recuperación ante desastres nativa de la nube, se deben abordar tres capacidades:

• Con los datos como núcleo, permita que los datos fluyan entre varias nubes. Los datos son el valor central de los usuarios, por lo que no importa cómo cambie la infraestructura subyacente, la copia de seguridad de los datos debe ser la demanda de activación del usuario. Cómo resolver la copia de seguridad de datos para diferentes servicios nativos de la nube es una base necesaria para el flujo de datos.

• Utilice las capacidades de orquestación nativas de la nube para lograr un alto grado de automatización y crear escenarios comerciales basados ​​en datos. Utilice las capacidades de orquestación automatizada para implementar más aplicaciones basadas en datos y ayudar a los usuarios a completar más innovaciones comerciales.

• Uso flexible de las características de los recursos nativos de la nube para reducir el costo total de propiedad. Para resolver el problema de la enorme inversión en la recuperación de desastres tradicional, los usuarios realmente pueden pagar a pedido, como agua y electricidad.