Exportar (0) Imprimir
Expandir todo

Orientación técnica de la continuidad del negocio de Azure

Actualizado: junio de 2014

Última actualización: Mayo 2014

Publicación original: Marzo 2012

Autores: Patrick Wickline, Jason Roth

Colaboradores y revisores: Luis Carlos Vargas Herring, Drew McDaniel, David Magar, Ganesh Srinivasan, Milan Gada, Nir Mashkowski ,Harsh Mittal, Sasha Nosov, Selcin Turkarslan, Cephas Lin, Cheryl McGuire, Bill Mathers, Mandi Ohlinger, Sidney Higa, Michael Green, Heidi Steen, Matt Winkler, Shayne Burgess, Larry Franks, Brad Severtson, Yavor Georgiev, Glenn Gailey, Tim Ammann, Ruppert Koch, Seth Manheim, Abhinav Gupta, Steve Danielson, Corey Sanders, John Deutscher

Para satisfacer los requisitos de alta disponibilidad y recuperación ante desastres, se requieren dos tipos de conocimientos: 1) la comprensión técnica detallada de las capacidades de una plataforma en la nube y 2) saber cómo diseñar correctamente un servicio distribuido. Este documento abarca el primero: las funciones y las limitaciones de la plataforma de Azure con respecto a la continuidad empresarial. Aunque también aborda la arquitectura y los patrones de diseño que no son primordiales. El lector debe consultar el material de la sección de recursos adicionales para orientarse sobre el diseño.

La información se organiza en las secciones siguientes:

  • 1. Recuperación de errores locales : puede que todo el hardware físico (como las unidades, los servidores y los dispositivos de red) genere errores y los recursos se agoten en los picos de carga. Esta sección describe las capacidades que Azure proporciona para mantener una alta disponibilidad en estas condiciones.

  • 2. Recuperación de la pérdida de una región de Azure: los errores generalizados son poco frecuentes pero posibles. Regiones enteras pueden quedar aisladas por culpa de errores de red o dañarse físicamente debido a desastres naturales. En esta sección se explica cómo utilizar las funciones de Azure para crear aplicaciones que abarcan varias regiones geográficas.

  • 3. Recuperación en local a Azure: la nube altera significativamente la economía de la recuperación ante desastres, ya que hace posible que las organizaciones usen Azure para establecer un segundo sitio para la recuperación. Esto se puede hacer por una fracción del costo de la compilación y el mantenimiento de un centro de datos secundario. En esta sección se describen las funciones que Azure proporciona para extender un centro de datos local a la nube.

  • 4. Recuperación de los daños en los datos o de una eliminación accidental: las aplicaciones pueden contener errores que dañen los datos y los operadores pueden eliminar datos importantes. Esta sección explica lo que ofrece Azure para realizar la copia de seguridad de los datos y restaurarlos a un momento anterior

  • 5. Recursos adicionales: otros recursos importantes que cubren la disponibilidad y la recuperación ante desastres en Azure.

Hay dos amenazas principales para la disponibilidad de la aplicación: el error de los dispositivos, como la unidad y los servidores, y el agotamiento de los recursos críticos, como el proceso en condiciones de carga máxima. Azure ofrece una combinación de administración de recursos, flexibilidad, equilibrio de carga y particiones para habilitar una alta disponibilidad en estas circunstancias. Algunas de estas características se realizan automáticamente para todos los servicios en la nube; sin embargo, en algunos casos el desarrollador de aplicaciones debe realizar algún trabajo adicional para beneficiarse de ellas.

Todos los servicios en la nube hospedados por Azure son colecciones de uno o varios roles de trabajo o web. Una o varias instancias de un rol dado pueden ejecutarse simultáneamente. La configuración determina el número de instancias. El rol de las instancias se supervisa y administra con un componente denominado controlador de tejido (FC). El controlador de tejido detecta y responde tanto al error de hardware como al de software automáticamente.

  • Cada instancia de rol se ejecuta en su propia máquina virtual (VM) y se comunica con su controlador de tejido a través de un agente invitado (GA). El agente invitado recopila estadísticas de los recursos y de los nodos, incluido el uso de la máquina virtual, el estado, los registros, el uso de recursos, las excepciones y las condiciones de error. El controlador de tejido consulta al agente invitado a intervalos configurables y reinicia la máquina virtual si este no puede responder.

  • En caso de que se produzca un error de hardware, el controlador de tejido asociado mueve todas las instancias del rol afectado a un nuevo nodo de hardware y reconfigura la red para enrutar allí el tráfico aéreo.

Para beneficiarse de estas características, los desarrolladores deben asegurarse de que todos los roles de servicio impiden almacenar el estado en las instancias de rol. En su lugar, se debe tener acceso a todos los datos persistentes desde el almacenamiento perdurable, como servicios de almacenamiento de Azure o Base de datos SQL de Azure. Esto permite que las solicitudes sean administradas por cualquier rol. También significa que las instancias de rol pueden desplazarse hacia abajo en cualquier momento sin crear incoherencias en el estado transitorio o persistente del servicio.

El requisito de almacenamiento externo del estado en los roles tiene algunas implicaciones. Implica, por ejemplo, que todos los cambios relacionados con una tabla de almacenamiento de Azure se deben cambiar en una única transacción de grupo de entidades, si es posible. Por supuesto, no siempre se puede realizar todos los cambios en una sola transacción. Se debe prestar atención especial para asegurarse de que los errores de las instancias de rol no ocasionan problemas cuando interrumpen las operaciones de ejecución prolongada que abarcan dos o más actualizaciones del estado persistente del servicio. Si otro rol intenta volver a realizar esta operación, debe prever y controlar el caso en el que el trabajo se completara parcialmente.

Por ejemplo, en un servicio que divida los datos entre varios almacenes, si un rol de trabajo desciende mientras se reubica la partición (shard), la reubicación del shard puede no completarse o puede repetirse desde el inicio en un rol de trabajo diferente, y puede producir daños en los datos o que se queden datos huérfanos. Para evitar problemas, las operaciones de ejecución prolongada deben ser idempotentes (es decir, repetibles sin efectos secundarios) o reiniciables incrementalmente (es decir, podrán continuar desde el punto de error más reciente).

  • Para ser idempotente, una operación de ejecución prolongada debe tener el mismo efecto independientemente de las veces que se ejecute, incluso si se interrumpe durante la ejecución.

  • Para ser incrementalmente reiniciable, una operación de ejecución prolongada debería estar formada por una secuencia de operaciones atómicas menores y registrar su progreso en un almacenamiento perdurable, de manera que cada llamada subsiguiente se reanude donde se detuvo su predecesora.

Finalmente, todas las operaciones de ejecución prolongada deben invocarse varias veces hasta que tengan éxito. Por ejemplo, se puede colocar una operación de aprovisionamiento en una cola de Azure y que un rol de trabajo la quite cuando se ejecute correctamente. La recolección de elementos no utilizados podría tener que limpiar los datos creados por las operaciones interrumpidas.

El número inicial de instancias que se ejecutan en cada rol se determina en la configuración de cada rol. Los administradores deben configurar inicialmente cada uno de los roles para ejecutarse con dos o más instancias según la carga esperada. Pero las instancias de rol se pueden escalar arriba o abajo fácilmente a media que cambian los patrones de uso. Esto se puede hacer con el portal de Azure, Windows PowerShell, la API de Administración de servicio o herramientas de terceros. El controlador de tejido aprovisiona automáticamente las nuevas instancias y las inserta en el equilibrador de carga para ese rol.

Con la Escala automática de Azure (vista previa), puede habilitar Azure para que escale automáticamente los roles en función de la carga. La escala automática también puede realizarse mediante programación integrada y configurarse para un servicio en la nube con un marco como Bloque de aplicación de autoescala automática (WASABi).

El controlador de tejido usa dos tipos de particiones: los dominios de actualización y los dominios de error.

  • Un dominio de actualización se utiliza para actualizar las instancias de rol de un servicio en los grupos. Azure implementa las instancias de servicio en varios dominios de actualización. En el caso de una actualización en contexto, el controlador de tejido desactiva todas las instancias en un dominio de la actualización, las actualiza y, a continuación, las reinicia antes de pasarlas al siguiente dominio de actualización. Este método impide que todo el servicio no esté disponible durante el proceso de actualización.

  • Un dominio de error define los puntos en los que puede haber un error de hardware o de red. Para cualquier rol con más de una instancia, el controlador de tejido garantiza que las instancias están distribuidas a través de varios dominios de error, para evitar que errores de hardware aislados interrumpan el servicio. Toda la exposición ante el error del clúster y del servidor de Azure se rige por los dominios de error.

En el contrato de nivel de servicio de Azure, Microsoft garantiza que, cuando implemente dos o más instancias de rol en diferentes dominios de error y actualización, tendrán una conectividad externa al menos durante el 99,95 % del tiempo. A diferencia de los dominios actualizados, no hay forma de controlar el número de dominios con error. Azure asigna automáticamente los dominios de error y distribuye las instancias de rol a través de ellos. Al menos las dos primeras instancias de cada rol se colocan en dominios de actualización y error diferentes para asegurarse de que cualquier rol con al menos dos instancias cumplirá el contrato de nivel de servicio. Esto se representa en el diagrama siguiente.

Todo el tráfico no enlazado a un rol web pasa a través de un equilibrador de carga sin estado que distribuye las solicitudes de cliente entre las instancias de rol. Las instancias de rol individuales no tienen direcciones IP públicas y no son directamente direccionables desde Internet. Los roles no tienen estado, de modo que cualquier solicitud de cliente puede enrutarse a cualquier instancia de rol. Un evento StatusCheck se desencadena cada 15 segundos. Se puede utilizar para indicar si el rol está listo para recibir el tráfico o está ocupado y debe sacarse de la rotación del equilibrador de carga.

Las máquinas virtuales de Azure difieren de los roles de proceso de PaaS en varios aspectos relacionados con la alta disponibilidad. A veces, debe realizar un trabajo adicional para asegurar una alta disponibilidad.

A diferencia de las instancias de rol PaaS, los datos almacenados en unidades de máquina virtual son persistentes incluso cuando la máquina virtual se reubica. Las máquinas virtuales de Azure utilizan los discos de máquina virtual existentes como blobs en el almacenamiento de Azure. Debido a las características de disponibilidad del almacenamiento de Azure, los datos almacenados en las unidades de una máquina virtual también tienen una elevada disponibilidad. Tenga en cuenta que la unidad D: es la excepción a esta regla. La unidad D: es realmente el almacenamiento físico en el servidor en bastidor que hospeda la máquina virtual y sus datos se perderán si esta se recicla. La unidad D: se ha diseñado solo para el almacenamiento temporal.

Azure entiende los niveles de una aplicación PaaS (rol web y rol de trabajo) y, por tanto, puede distribuirlos correctamente a través de dominios de error y actualización. Por el contrario, los niveles de las aplicaciones IaaS se deben definir manualmente mediante conjuntos de disponibilidad. Los conjuntos de disponibilidad se requieren para un contrato de nivel de servicio bajo IaaS.

En el diagrama superior, el nivel IIS y el nivel SQL se asignan a diferentes conjuntos de disponibilidad. Esto garantiza que todas las instancias de cada nivel tienen redundancia de hardware al distribuirlas a través de dominios de error y no se retiran durante una actualización. Para obtener más información sobre cómo configurar conjuntos de disponibilidad, vea Administrar la disponibilidad de las máquinas virtuales.

Si las máquinas virtuales hacen que el tráfico se distribuya a través de ellas, debe agruparlas en un servicio en la nube y equilibrio de carga a través de un extremo específico TCP o UDP. Para obtener más información, vea Máquinas virtuales de equilibrio de carga. Si las máquinas virtuales reciben el tráfico de otro origen (por ejemplo, un mecanismo de cola), un equilibrador de carga no es necesario. El equilibrador de carga utiliza una comprobación básica del estado para determinar si el tráfico se debe enviar al nodo. También es posible crear sus propios sondeos para implementar métricas específicas del estado que determinen si la máquina virtual debe recibir el tráfico.

El almacenamiento de Azure es el servicio de datos perdurable de referencia para Azure y proporciona almacenamiento en disco de máquina virtual, colas, tablas y blob. Utiliza una combinación de replicación y administración de recursos para proporcionar una alta disponibilidad dentro de un solo centro de datos. El contrato de nivel de servicio de disponibilidad del almacenamiento de Azure garantiza que, al menos un 99,9 % del tiempo, las solicitudes con formato correcto para agregar, actualizar, leer y eliminar datos se realizarán y se procesarán correctamente y que, además, las cuentas de almacenamiento tendrán conectividad con la puerta de enlace de Internet.

La durabilidad de los datos para el almacenamiento de Azure se logra manteniendo varias copias de todos los datos en diferentes unidades ubicadas en subsistemas de almacenamiento físico totalmente independientes dentro de la región. Los datos se replican de forma sincrónica y todas las copias se confirman antes de confirmar la escritura. El almacenamiento de Azure es muy coherente, lo que significa que se garantiza que las lecturas reflejen las escrituras más recientes. Además, las copias de los datos se examinan continuamente para detectar y reparar la degradación de bits, una amenaza a menudo soslayada para la integridad de los datos almacenados. Los servicios se benefician de la replicación solamente con el almacenamiento de Azure. No se requiere ningún trabajo adicional por parte del desarrollador del servicio para la recuperación de un error local.

Las cuentas de almacenamiento creadas después del 7 de junio de 2012 pueden crecer hasta 200 TB (el máximo anterior era de 100 TB). Si se necesita espacio adicional, las aplicaciones deben diseñarse para aprovechar varias cuentas de almacenamiento.

Un disco de máquina virtual se almacena como un blob de página en el almacenamiento de Azure lo que le confiere las mismas propiedades de durabilidad y escalabilidad que el almacenamiento de blobs. Este diseño hace que los datos del disco de una máquina virtual persistan incluso si el servidor que ejecuta la máquina virtual da error y esta debe reiniciarse en otro servidor.

Base de datos SQL de Microsoft Azure proporciona una base de datos como servicio, lo que permite que las aplicaciones aprovisionen los datos, los inserten en bases de datos relacionales y las consulten rápidamente. Ofrece muchas de las características y la funcionalidad conocidas de SQL Server, a la vez que resume la carga de hardware, configuración, incorporación de revisiones y resistencia.

noteNota
Base de datos SQL de Azure no proporciona una paridad 1:1 de características con SQL Server y está pensada para satisfacer un conjunto diferente de requisitos adecuados exclusivamente para las aplicaciones en la nube (escala elástica, base de datos como servicio para reducir los costos de mantenimiento, etc.). Para obtener más información, vea Series de datos: SQL Server en una máquina virtual de Azure frente a una base de datos SQL.

Base de datos SQL de Azure proporciona resistencia integrada a los errores de nivel de nodo. Todas las operaciones de escritura en una base de datos se replican automáticamente en dos o más nodos en segundo plano mediante una técnica de confirmación de quórum (el servidor principal y al menos uno secundario deben confirmar que la actividad se escribió en el registro de transacciones para que la transacción se considere correcta y vuelva). En el caso de error de nodo, la base de datos automáticamente conmuta por error a una de las réplicas secundarias. Esto produce una interrupción transitoria en la conexión para las aplicaciones cliente. Por esta razón, todos los clientes de Base de datos SQL de Microsoft Azure deben implementar algún medio para controlar las conexiones transitorias. Para obtener más información, vea Usar el Bloque de aplicaciones de administración de errores transitorios con SQL Azure.

Cada base de datos, cuando se crea, se configura con un límite superior de tamaño. El tamaño máximo actualmente disponible es de 150 GB. Cuando una base de datos llega al límite superior de tamaño rechaza comandos adicionales INSERT o UPDATE (la consulta y eliminación de datos siguen siendo posibles).

En una base de datos, Base de datos SQL de Microsoft Azure utiliza un tejido para administrar los recursos. Sin embargo, en lugar de un controlador de tejido, usa una topología en anillo para detectar errores. Cada réplica en un clúster tiene dos vecinos y es responsable de detectar cuándo se bloquean. Cuando una réplica se bloquea, sus vecinos activan un agente de reconfiguración (RA) para volver a crearla en otro equipo. La limitación del motor se proporciona para asegurarse de que un servidor lógico no utiliza demasiados recursos en un equipo ni supera los límites físicos del equipo.

Si la aplicación requiere más memoria del límite de la base de datos de 150 GB, debe implementar una solución escalada. La escala con Base de datos SQL de Microsoft Azure se hace manualmente mediante la partición, también conocida como sharding, de los datos a través de varios Base de datos SQL de Azure. Este enfoque escalado proporciona la oportunidad de lograr aproximadamente un crecimiento de costo lineal con la escala. El crecimiento elástico o la capacidad a petición pueden aumentar los costos incrementales según sea necesario porque las bases de datos se facturan según el tamaño real promedio que se usa cada día, no según el tamaño máximo posible.

Al instalar SQL Server 2012 en máquinas virtuales de Azure (IaaS), puede aprovechar las características de disponibilidad tradicionales de SQL Server, como los grupos de disponibilidad AlwaysOn o la creación de reflejo de la base de datos. Tenga en cuenta que la máquina virtual de Azure, el almacenamiento y la conexión de red tienen características operativas diferentes de las de una infraestructura TI local y no virtualizada. Una implementación correcta de una solución de SQL Server HADR en Azure requiere saber estas diferencias y diseñar la solución para tenerlas en cuenta.

Al implementar una solución de alta disponibilidad en Azure, el conjunto de disponibilidad establecido en Azure permite colocar los nodos de alta disponibilidad en dominios de error diferentes y en dominios de actualización. Como aclaración, el conjunto de disponibilidad es un concepto de Azure. Para obtener más información, vea Administrar la disponibilidad de las máquinas virtuales. Se recomienda asegurarse de que las bases de datos son en realidad de alta disponibilidad, tanto si usa grupos de disponibilidad AlwaysOn, la creación de reflejo de la base de datos u otros. Si no sigue esta recomendación, es posible que suponga falsamente que el sistema tiene una alta disponibilidad pero en realidad los nodos pueden dar error todos simultáneamente porque resulte que estén colocados en el mismo dominio de error en el centro de datos de Azure. Esta recomendación no es tan aplicable al trasvase de registros ya que, como característica de recuperación de desastres, debe asegurarse de que los servidores se ejecutan en ubicaciones independientes del centro de datos de Azure (regiones). Por definición, estas ubicaciones del centro de datos son dominios de error independientes.

Para que las VM de Azure se coloquen en el mismo conjunto de disponibilidad, debe implementarlas en el mismo servicio en la nube. Solo los nodos del mismo servicio en la nube pueden participar en el mismo conjunto de disponibilidad. Además, las máquinas virtuales deben estar en la misma VNet para asegurarse de que conservan sus direcciones IP incluso después de la recuperación del servicio, lo que evita los tiempos de actualización DNS.

Puede tener una solución de alta disponibilidad para sus bases de datos de SQL Server en Azure con grupos de disponibilidad AlwaysOn o creación de reflejo de la base de datos.

El diagrama siguiente muestra la arquitectura de los grupos de disponibilidad AlwaysOn que se ejecutan en máquinas virtuales de Azure. Este diagrama se tomó del completo artículo sobre este asunto, Alta disponibilidad y recuperación de desastres para SQL Server en máquinas virtuales de Azure.

El siguiente diagrama muestra el uso de la creación de reflejo de la base de datos en máquinas virtuales de Azure. También se tomó del completo tema Alta disponibilidad y recuperación de desastres para SQL Server en máquinas virtuales de Azure.

noteNota
Observe que en ambas arquitecturas se requiere un controlador de dominio. Sin embargo, con la creación de reflejo de la base de datos es posible utilizar certificados de servidor para eliminar la necesidad de un controlador de dominio.

Los servicios en la nube de Azure se basan en Azure, de modo que se benefician de las capacidades de la plataforma descritas para recuperarse de los errores locales. En algunos casos, hay medidas específicas que debe seguir para aumentar la disponibilidad en su situación concreta.

Access Control Service (ACS) 2.0 realiza copias de seguridad de todos los espacios de nombres una vez al día y las almacena en una ubicación segura fuera del sitio. Cuando el personal de operaciones de ACS determina que se ha producido una pérdida de datos irrecuperable en uno de los centros de datos de ACS regionales, ACS intentará recuperar las suscripciones de los clientes restaurando la copia de seguridad más reciente. Debido a la frecuencia con que se realizan las copias de seguridad, la pérdida de datos puede ser de hasta 24 horas. Para obtener más información, vea Access Control Service (recuperación de desastres).

Para mitigar la posible interrupción temporal del sistema de Service Bus de Azure, considere crear una cola en el cliente perdurable. Esto utiliza temporalmente un mecanismo de almacenamiento local alternativo para almacenar los mensajes que no se pueden agregar a la cola de Service Bus. La aplicación puede decidir cómo controlar los mensajes almacenados temporalmente después de restaurar el servicio. Para obtener más información, vea Aislar aplicaciones de Service Bus frente a sus caídas del sistema y desastres. Para obtener más información, vea Service Bus (recuperación de desastres).

Hay dos consideraciones sobre disponibilidad para los servicios móviles de Azure. Primero, cree periódicamente el Base de datos SQL de Azure asociado al servicio móvil. También haga una copia de seguridad de los scripts del servicio móvil. Para obtener más información, vea Recuperar el servicio móvil en caso de un desastre. Si los servicios móviles experimentan una falta de respuesta del sistema temporal, puede que tenga que usar temporalmente un centro de datos alternativo de Azure. Para obtener más información, vea Servicios móviles (recuperación de desastres).

Los datos asociados a HDInsight se almacenan de forma predeterminada en el almacenamiento de blob de Azure, que tiene las propiedades de alta disponibilidad y durabilidad especificadas por el almacenamiento de Azure. El procesamiento de varios nodos asociado a los trabajos de Hadoop MapReduce se efectúan en un sistema de archivos distribuido transitorio (HDFS) de Hadoop que se aprovisiona cuando lo requiere HDInsight. Los resultados de un trabajo MapReduce también se almacenan de forma predeterminada en el almacenamiento de blob de Azure, de modo que los datos procesados son perdurables y permanecen altamente disponibles cuando el clúster Hadoop se desaprovisiona. Para obtener más información, vea HDInsight (recuperación de desastres).

 

Servicio/área Lista de comprobación

Proceso (PaaS)

  • Configure al menos dos instancias para cada rol.

  • Persista el estado en el almacenamiento perdurable, no en las instancias de rol.

  • Administre correctamente el evento StatusCheck.

  • Ajuste los cambios relacionados en las transacciones cuando sea posible.

  • Compruebe que las tareas del rol de trabajo son idempotentes y reiniciables.

  • Continúe invocando operaciones hasta que se realicen correctamente.

  • Considere las estrategias de autoescalado.

Máquinas virtuales (IaaS)

  • No use la unidad D: para el almacenamiento persistente.

  • Agrupe los equipos de un nivel de servicio dentro de un conjunto de disponibilidad.

  • Configure el equilibrio de carga y sondeos opcionales.

Almacenamiento

  • Utilice varias cuentas de almacenamiento cuando los datos o el ancho de banda superen las cuotas.

Base de datos SQL

  • Implemente una directiva de reintentos para controlar los errores transitorios.

  • Utilice las particiones o sharding como estrategia de escala.

SQL Server 2012 en máquinas virtuales (IaaS)

  • Siga las recomendaciones anteriores para las máquinas virtuales.

  • Utilice las características de alta disponibilidad de SQL Server, como AlwaysOn.

Access Control Service (disponibilidad)

  • No se requieren pasos adicionales para la disponibilidad si hay errores locales.

Service Bus (disponibilidad)

  • Considere crear una cola en el cliente perdurable como copia de seguridad.

Servicios móviles (disponibilidad)

  • Cree periódicamente el Base de datos SQL de Azure asociado a los servicios móviles.

  • Haga una copia de seguridad de los scripts de servicios móviles.

HDInsight (disponibilidad)

  • No se requieren pasos adicionales para la disponibilidad si hay errores locales.

Azure se divide física y lógicamente en unidades denominadas regiones. Una región consta de uno o más centros de datos cercanos. En el momento de redactar este documento, Azure tiene ocho regiones (cuatro en Norteamérica, dos en Asia y dos en Europa).

En raras circunstancias, las instalaciones de toda una región pueden llegar a ser inaccesibles, por ejemplo debido a errores de red, o perderse completamente, por ejemplo por culpa de desastres naturales. Esta sección explica las capacidades de Azure para crear aplicaciones que se distribuyen entre las regiones. Las regiones están diseñadas para minimizar la posibilidad de que un error en una región puede afectar a otras.

La distribución las instancias de proceso a través de las regiones se consigue creando un servicio independiente en la nube en cada región de destino y publicando el paquete de implementación en cada servicio en la nube. Sin embargo, tenga en cuenta que el desarrollador de la aplicación es quien debe implementar la distribución del tráfico a través de los servicios en la nube en diferentes regiones o bien a través de un servicio de administración de tráfico.

Determinar el número de instancias de rol de repuesto que implementar de antemano para la recuperación de desastres es un aspecto importante del planeamiento de la capacidad. Disponer de una implementación secundaria a escala completa garantiza que la capacidad ya esté disponible cuando se necesite; sin embargo, esto duplica en efecto el costo. Un modelo común es tener una pequeña implementación secundaria lo suficientemente grande como para ejecutar los servicios esenciales. Se recomienda crear al menos una pequeña implementación secundaria, tanto para reservar capacidad como para probar la configuración del entorno secundario.

noteNota
La cuota de suscripción no es una garantía de la capacidad. La cuota es simplemente un límite de crédito. Para garantizar la capacidad, el número requerido de roles debe definirse en el modelo de servicio y los roles deben implementarse.

El tráfico de equilibrio de carga a través de las regiones requiere el uso de una solución de administración del tráfico. Azure proporciona Traffic Manager de Azure (ahora en CTP). También puede aprovechar los servicios de terceros que proporcionan funciones similares de administración del tráfico.

Hay muchas estrategias alternativas disponibles para implementar el proceso distribuido a través de las regiones. Se deben personalizar para adaptarse a los requisitos empresariales y las circunstancias específicos de la aplicación. En general, los métodos pueden dividirse en tres categorías:

  • Volver a realizar la implementación en caso de desastre: En este enfoque, la aplicación se implementa de nuevo desde el principio si se produce un desastre. Esto es adecuado para las aplicaciones no esenciales que no requieren un tiempo de recuperación garantizado.

  • Espera activa (activa/pasiva): Se crea un servicio hospedado secundario en una región alternativa y los roles se implementan para garantizar la capacidad mínima; sin embargo, los roles no reciben el tráfico de producción. Este enfoque es útil para las aplicaciones que no se han diseñado para distribuir el tráfico a través de las regiones.

  • Espera activa (activa/activa): La aplicación está diseñada para recibir la carga de producción en varias regiones. Los servicios en la nube de cada región pueden configurarse para una capacidad mayor de la necesaria para la recuperación de desastres. O bien, los servicios en la nube pueden escalarse según corresponda en el momento en que se produzca un desastre y la conmutación por error. Este enfoque requiere una inversión sustancial en el diseño de las aplicaciones pero tiene ventajas importantes como son un tiempo de recuperación garantizado y bajo, la prueba continua de todas las ubicaciones de recuperación y un uso eficaz de la capacidad.

Una explicación completa de los diseños distribuidos queda fuera del ámbito de este documento. Los documentos siguientes proporcionan una orientación detallada sobre estos escenarios.

La recuperación de las máquinas virtuales IaaS es similar a la recuperación del proceso de PaaS en muchos aspectos, sin embargo, hay diferencias importantes debidas a que una máquina virtual IaaS consta de la máquina y del disco de máquina virtual.

  • Utilice la API de copia de blobs para duplicar los discos de máquina virtual: Para crear máquinas virtuales en varias regiones, el disco de máquina virtual debe copiarse en la región alternativa. Dado que los discos de máquina virtual son simplemente blobs, esto se puede lograr utilizando la API de copia de blobs estándar.

  • Separe el disco de datos del disco del sistema operativo: Una consideración importante para las máquinas virtuales IaaS es que no se puede cambiar el disco del sistema operativo sin volver a crear la máquina virtual. Esto no es un problema si la estrategia de recuperación es volver a implementar después de un desastre. Sin embargo, podría ser un problema si utiliza el método de espera activa para reservar la capacidad. Para implementar esto correctamente, debe tener el disco apropiado del sistema operativo implementado tanto en la ubicación principal como en la secundaria y los datos de las aplicaciones deben estar almacenados en una unidad independiente. Si es posible, use una configuración estándar del sistema operativo que pueda proporcionarse en las dos ubicaciones. Después de una conmutación por error, debe adjuntar la unidad de datos a las máquinas virtuales IaaS existentes en el controlador de dominio secundario. Utilice la API CopyBlob para copiar instantáneas de los discos de datos a un sitio remoto.

  • Posibles problemas de coherencia después de una conmutación geográfica por error de varios discos de máquina virtual: Los discos de máquina virtual se implementan como blobs del almacenamiento de Azure y tienen la misma característica de replicación geográfica (vea a continuación). Se garantiza que los discos de máquina virtual están en un estado coherente de bloqueo después de una conmutación geográfica por error, aunque no existen garantías de que haya coherencia en varios discos, dado que la replicación geográfica es asincrónica y se replica de forma independiente. Esto puede causar problemas en algunos casos (por ejemplo, en la creación de bandas en disco). Puede requerirse trabajo adicional para restaurar la coherencia después de una conmutación geográfica por error en estos casos. Para garantizar la corrección de las copias de seguridad, se debe usar un producto de copia de seguridad como el Administrador de protección de datos para hacer la copia de seguridad y la restauración de los datos de la aplicación.

En Azure, los blobs, las tablas, las colas y los discos de máquina virtual se georreplican de forma predeterminada. Se denomina almacenamiento con redundancia geográfica (GRS). El GRS replica los datos de almacenamiento en un centro de datos emparejado alejado varios kilómetros dentro de una región geográfica específica. El GRS se ha diseñado para proporcionar durabilidad adicional en caso de que se produzca un desastre grave en un centro de datos. Microsoft toma el control en caso de conmutación por error y esta quedará limitada a los casos de desastres importantes donde la ubicación principal original se considera irrecuperable en un intervalo de tiempo razonable. En algunos casos puede ser varios días. Los datos se replican normalmente en unos minutos, pese a que el intervalo de sincronización aún no lo cubre ningún SLA.

En caso de la conmutación geográfica por error, no habrá ningún cambio en el modo en que se tiene acceso a la cuenta (la dirección URL y la clave de cuenta no cambiarán), sin embargo, la cuenta de almacenamiento estará en una región distinta después de la conmutación por error, lo que podría afectar a las aplicaciones que requieren afinidad regional con su cuenta de almacenamiento. Incluso para los servicios y las aplicaciones que no requieren una cuenta de almacenamiento en el mismo centro de datos, los gastos asociados a la latencia a través de los centros de datos y al ancho de banda pueden ser una razón de peso para pasar el tráfico a la región de conmutación por error temporalmente. Esto podría incluirse en una estrategia global de recuperación de desastres.

Además de la conmutación por error proporcionada por GRS, Azure ha introducido un servicio que ofrece acceso de lectura a la copia de los datos en la segunda ubicación de almacenamiento. Se denomina almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS).

Para obtener más información sobre la vista previa de GRS y RA-GRS, vea Windows Azure Storage Redundancy Options and Read Access Geo Redundant Storage.

Es importante saber dónde se georreplican los datos para saber dónde implementar las otras instancias de los datos que requieren afinidad regional con el almacenamiento. La tabla siguiente se muestran los emparejamientos de las ubicaciones principal y secundaria:

 

Principal Secundaria

EE. UU. Central Norte

EE. UU. Central Sur

EE. UU. Central Sur

EE. UU. Central Norte

Este de EE. UU.

Oeste de EE. UU.

Oeste de EE. UU.

Este de EE. UU.

Europa del Norte

Europa Occidental

Europa Occidental

Europa del Norte

Sudeste de Asia

Asia Oriental

Asia Oriental

Sudeste de Asia

Este de China

Norte de China

Norte de China

Este de China

Sur de Brasil

EE. UU. Central Sur

La replicación geográfica se incluye en el precio actual del almacenamiento de Azure. Esto se denomina almacenamiento con redundancia geográfica. Si no desea que los datos se georrepliquen, puede deshabilitar la replicación geográfica para la cuenta. Esto se denomina almacenamiento localmente redundante y se cobra a un precio con descuento con respecto al almacenamiento con replicación geográfica. Vea aquí más detalles sobre el almacenamiento localmente redundante (LRS).

Si se produce una conmutación geográfica por error, se enviará al Panel de estado del servicio de Azure, sin embargo, las aplicaciones pueden implementar métodos automatizados para detectar esto supervisando la región geográfica para su cuenta de almacenamiento. Esto se puede utilizar para activar otras operaciones de recuperación como la activación de los recursos de proceso en la región geográfica donde su almacenamiento se movió. Esto se puede consultar desde la API de administración del servicio utilizando Obtener las propiedades de las cuentas de almacenamiento. Las propiedades relevantes son:

<GeoPrimaryRegion>primary-region</GeoPrimaryRegion>
<StatusOfPrimary>[Available|Unavailable]</StatusOfPrimary>
<LastGeoFailoverTime>DateTime</LastGeoFailoverTime
<GeoSecondaryRegion>secondary-region</GeoSecondaryRegion
<StatusOfSecondary>[Available|Unavailable]</StatusOfSecondary>

  • Según se explicó en la sección sobre los discos de máquina virtual, no hay ninguna garantía de que exista coherencia en los datos de varios discos de máquina virtual después de una conmutación por error. Para garantizar la corrección de las copias de seguridad, se debe usar un producto de copia de seguridad como el Administrador de protección de datos para hacer la copia de seguridad y la restauración de los datos de la aplicación.

La recuperación de Base de datos SQL de Azure de Azure se puede realizar mediante la exportación de un blob de almacenamiento de Azure con el servicio de importación y exportación de Base de datos SQL de Azure de Azure. Esto se puede implementar de tres maneras:

  • Exportar a un blob con una cuenta de almacenamiento de un centro de datos diferente

  • Exportar a un blob usando la cuenta de almacenamiento en el mismo centro de datos (y basarse en la replicación geográfica de Almacenamiento de Azure en el centro de datos independiente).

  • Importar al SQL Server local.

Para obtener detalles sobre la implementación, vea el artículo de MSDN Continuidad de negocio en Base de datos SQL de Azure.

Existen dos opciones para recuperar una base de datos de SQL Server que se ejecuta en IaaS en un centro de datos de Azure alternativo: creación de reflejo o copia de seguridad de la base de datos y restauración con blobs de almacenamiento. Tenga en cuenta que en este momento los grupos de disponibilidad de SQL Server 2012 no se admiten a través de centros de datos de Azure porque tampoco se admiten las redes virtuales a través de centros de datos y un dominio de Active Directory no puede abarcar varios centros de datos de Azure.

Al utilizar la creación de reflejo de la base de datos para la recuperación de desastres, debe tener la entidad de los servidores principal y reflejado ejecutándose en diferentes centros de datos de Azure. Esto significa que debe implementar con certificados de servidor, porque un dominio de Active Directory no puede abarcar varios centros de Azure sin enrutar el tráfico a través de una red local. El diagrama siguiente muestra esta configuración.

Otra opción es usar copias de seguridad y restauración estándar con los blobs de almacenamiento de Azure.

Para obtener más información, vea Alta disponibilidad y recuperación ante desastres para SQL Server en máquinas virtuales de Azure.

Al intentar ejecutar el servicio en la nube en varias regiones de Azure, debe tener en cuenta las implicaciones de cada una de sus dependencias. En las secciones siguientes, la orientación específica del servicio supone que debe utilizar el mismo servicio de Azure en un centro de datos alternativo de Azure. Esto incluye tanto tareas de configuración como de replicación de datos.

Tenga en cuenta que, en algunos casos, estos pasos pueden ayudar a mitigar una interrupción específica del servicio en lugar de un evento de todo el centro de datos. Desde la perspectiva de la aplicación, la interrupción específica del servicio podría ser igual de restrictiva y requerir la migración temporal del servicio a una región alternativa de Azure.

Access Control Service (ACS) usa un espacio de nombres único que no abarca varias regiones de Azure. ACS 2.0 realiza copias de seguridad de todos los espacios de nombres una vez al día y las almacena en una ubicación segura fuera del sitio. En el caso de un desastre, el personal de operaciones de ACS puede intentar recuperar las suscripciones de los clientes de una región remota de Azure con la copia de seguridad más reciente. Debido a la frecuencia con que se realizan las copias de seguridad, la pérdida de datos puede ser de hasta 24 horas. No hay ningún contrato de nivel de servicio para la conmutación por error regional y el tiempo de recuperación puede ser de varios días según el escenario.

Para utilizar ACS en una región alternativa, los clientes deben configurar un espacio de nombres ACS en dicha región. Se recomienda a los clientes de ACS 2.0 a los que les preocupe la posible de pérdida de datos que revisen el servicio de administración de ACS 2.0. Esta interfaz permite a los administradores administrar sus espacios de nombres e importar y extraer todos los datos relevantes. Mediante el uso de esta interfaz, los clientes de ACS disfrutan de la capacidad de desarrollar soluciones personalizadas de copias de seguridad y de restauración para alcanzar un nivel mayor en la coherencia de datos del que ACS proporciona actualmente. Para conocer otras consideraciones sobre la disponibilidad, vea Access Control Service (disponibilidad).

Al igual que ACS, Service Bus usa un espacio de nombres único que no abarca varias regiones de Azure. Por eso, el primer requisito es configurar los espacios de nombres necesarios de Service Bus en la región alternativa. Sin embargo, también hay consideraciones para la durabilidad de los mensajes en cola. Hay varias estrategias para replicar mensajes a través de las regiones de Azure. Para obtener información detallada acerca de estas estrategias de replicación y otras estrategias de recuperación de desastres, vea Aislar aplicaciones de Service Bus frente a sus caídas del sistema y desastres. Para conocer otras consideraciones sobre la disponibilidad, vea Service Bus (disponibilidad).

Para migrar un sitio web de Azure a una región secundaria de Azure, debe tener una copia de seguridad del sitio web disponible para la publicación. Si la interrupción no implica a todo el centro de datos de Azure, podría ser posible utilizar FTP para descargar una copia de seguridad reciente del contenido del sitio. Luego, cree un sitio web en la región alternativa, a menos que ya lo haya hecho previamente para reservar capacidad. Publique el sitio en la nueva región y realice los cambios de configuración necesarios. Estos cambios podrían incluir cadenas de conexión a bases de datos u otras opciones específicas de la región. Si fuera necesario, agregue el certificado SSL del sitio y cambie el registro CNAME DNS de modo que el nombre de dominio personalizado señale a la dirección URL del sitio web de Azure implementada de nuevo.

En la región secundaria de Azure, cree un servicio móvil de copia de seguridad para la aplicación. Restaure el Base de datos SQL de Azure en la región alternativa también. A continuación utilice las herramientas de línea de comandos de Azure para pasar el servicio móvil a la región alternativa. Después, configure el servicio móvil para usar la base de datos restaurada. Para obtener más información sobre este proceso, vea Recuperar el servicio móvil en caso de un desastre. Para conocer otras consideraciones sobre la disponibilidad, vea Servicios móviles (disponibilidad)

Los datos asociados a HDInsight se almacenan de forma predeterminada en el almacenamiento de blobs de Azure. HDInsight requiere colocar un clúster Hadoop que procese los trabajos MapReduce en la misma región que la cuenta de almacenamiento con los datos analizados. Siempre que use la característica de replicación geográfica disponible para el almacenamiento de Azure, puede tener acceso a los datos de la región secundaria donde se replicarán si por algún motivo la región principal deja de estar disponible. Puede crear un nuevo clúster de Hadoop en la región en la que se hayan replicado los datos y continuar procesándolos. Para conocer otras consideraciones sobre la disponibilidad, vea HDInsight (disponibilidad).

En este momento, para la recuperación de la pérdida de una región de Azure son necesarias varias instancias de SQL Reporting en diferentes regiones de Azure. Estas instancias de SQL Reporting deben tener acceso a los mismos datos y esos datos deben tener su propio plan de recuperación en caso de desastre. También puede conservar las copias de seguridad externas del archivo RDL para cada informe.

Servicios multimedia de Azure tiene un enfoque de recuperación diferente para la codificación y la transmisión en secuencias. Normalmente, la transmisión en secuencias es más importante durante una interrupción regional del sistema. Para prepararse para esto, debe tener una cuenta de Servicios multimedia en dos regiones de Azure. El contenido codificado se debe encontrar en ambas regiones. Durante un error, puede redirigir el tráfico de transmisión en secuencias a la región alternativa. La codificación se puede realizar en cualquier región de Azure. Si el código es dependiente del tiempo, por ejemplo, durante el procesamiento de eventos en vivo, debe estar preparado para enviar los trabajos a un centro de datos alternativo si se producen errores.

Los archivos de configuración proporcionan la forma más rápida de configurar una red virtual en una región alternativa de Azure. Después de configurar la red virtual en la región principal de Azure, exporte la configuración de la red virtual para la red actual a un archivo de configuración de red. Si se produce la interrupción del sistema en la región principal, restaure la red virtual del archivo de configuración almacenado. Configure otros servicios en la nube, máquinas virtuales o valores en local para trabajar con la nueva red virtual.

 

Servicio/área Lista de comprobación

Proceso (PaaS)

  • Cree una estrategia de recuperación de desastres a través de regiones.

  • Conozca los inconvenientes que supone reservar capacidad en las regiones alternativas.

  • Utilice las herramientas de enrutamiento de tráfico, como Traffic Manager de Azure (CTP).

Máquinas virtuales (IaaS)

  • Copie los recursos de disco de máquina virtual de blobs a un centro de datos alternativo.

  • Realice copias de seguridad periódicas del contenido del disco o del disco de máquina virtual.

Almacenamiento

  • No deshabilite la replicación geográfica de los recursos de almacenamiento.

  • Conozca la región alternativa para la replicación geográfica en caso de una conmutación por error.

  • Cree estrategias de copia de seguridad personalizadas como estrategias de conmutación por error controladas por el usuario.

Base de datos SQL (recuperación de desastres)

  • Exporte Base de datos SQL de Azure a un almacenamiento de blobs.

  • Cree un plan de recuperación de desastres basado en las consideraciones anteriores del almacenamiento.

SQL Server en máquinas virtuales (recuperación de desastres)

  • Utilice la creación de reflejo de la base de datos a través de las regiones.

  • Como alternativa, utilice la copia de seguridad y la restauración para el almacenamiento de blobs.

Access Control Service (recuperación de desastres)

  • Configure un espacio de nombres ACS en una región alternativa.

  • Utilice el servicio de administración de ACS 2.0 para crear soluciones de copia de seguridad personalizadas.

Service Bus (recuperación de desastres)

  • Configure un espacio de nombres de Service Bus en una región alternativa.

  • Considere las estrategias personalizadas de replicación para los mensajes a través de las regiones.

Sitios web (recuperación de desastres)

  • Conserve las copias de seguridad del sitio web fuera de la región principal.

  • Si la interrupción del sistema es parcial, intente recuperar el sitio actual con FTP.

  • Planee la implementación del sitio web en un sitio web nuevo o en otro de una región alternativa.

  • Planee los cambios de configuración para la aplicación y para los registros CNAME DNS.

Servicios móviles (recuperación de desastres)

  • Cree un servicio móvil de copia de seguridad en una región alternativa.

  • Administre las copias de seguridad del Base de datos SQL de Azure asociado para restaurar durante la conmutación por error.

  • Utilice las herramientas de línea de comandos de Azure para pasar al servicio móvil.

HDInsight (recuperación de desastres)

  • Cree un nuevo clúster de Hadoop en la región con los datos replicados.

SQL Reporting (recuperación de desastres)

  • Conserve una instancia de SQL Reporting en una región diferente.

  • Conserve un plan independiente para replicar el destino en dicha región.

Servicios multimedia (recuperación de desastres)

  • Cree una cuenta de Servicios multimedia en una región alternativa.

  • Codifique el mismo contenido en ambas regiones para admitir la conmutación por error de las secuencias.

  • Envíe los trabajos de codificación a una región alternativa si se produce la interrupción del sistema.

Red virtual (recuperación de desastres)

  • Utilice la configuración exportada de la red virtual para volver a crearla en otra región.

Azure proporciona un conjunto completo de servicios para habilitar la extensión de un centro de datos local en Azure para lograr una alta disponibilidad y permitir la recuperación ante desastres:

  • Redes: Con la red privada virtual, puede ampliar de forma segura la red local a la nube.

  • Proceso: Los clientes que usan Hyper-V local pueden “elevar y cambiar” las máquinas virtuales existentes a Azure.

  • Almacenamiento: StorSimple amplía el sistema de archivos al almacenamiento de Azure. El servicio de copia de seguridad de Azure permite la copia de seguridad de los archivos y Base de datos SQL de Azure del almacenamiento de Azure

  • Replicación de bases de datos: Con los grupos de disponibilidad de SQL 2012, puede implementar una alta disponibilidad y permitir la recuperación ante desastres para los datos locales.

La red virtual de Azure permite crear una sección aislada lógicamente en Azure y conectarla con seguridad al centro de datos local o a un único equipo cliente utilizando una conexión IPsec. La red virtual facilita el aprovechamiento de la infraestructura escalable y a petición de Azure al tiempo que proporciona conectividad con los datos y aplicaciones locales, incluidos los sistemas que se ejecutan en Windows Server, grandes sistemas y UNIX. Vea aquí para obtener más información.

Los clientes que utilizan Hyper-V en local pueden “elevar y cambiar” las máquinas virtuales existentes a Azure y a los proveedores de servicios que ejecutan Windows Server 2012, sin realizar cambios en la máquina virtual ni convertir sus formatos. Para obtener más información, vea Administrar discos e imágenes.

Existen varias opciones para utilizar Azure como sitio de copias de seguridad para los datos locales.

StorSimple integra de forma segura y transparente el almacenamiento en la nube para las aplicaciones y ofertas locales en un único dispositivo que ofrece un almacenamiento en la nube y local en capas y de alto rendimiento, archivado activo, protección de datos basado en la nube y recuperación de desastres. Para obtener más información, vea StorSimple -- Almacenamiento integrado en la nube -- Qué y por qué.

Los servicios de copia de seguridad (Backup) de Azure permiten efectuar copias de seguridad en la nube con herramientas de copia de seguridad conocidas de Windows Server 2012, Windows Server 2012 Essentials o System Center 2012 Data Protection Manager. Estas herramientas proporcionan un flujo de trabajo para la administración de copia de seguridad que es independiente de la ubicación del almacenamiento de las copias de seguridad, ya sea en un disco local o en almacenamiento de Azure. Una vez que se ha realizado la copia de seguridad de los datos en la nube, los usuarios autorizados pueden recuperar fácilmente las copias de seguridad en cualquier servidor.

Con las copias de seguridad incrementales, solo se transfieren a la nube los cambios en los archivos. Esto ayuda a usar el espacio de almacenamiento de forma eficaz, reducir el uso del ancho de banda y ofrecer la posibilidad de recuperar de forma puntual varias versiones de los datos. También puede usar características adicionales, como directivas de retención de datos, compresión de datos y limitación de la transferencia de datos. Usar Azure como ubicación de copia de seguridad tiene la ventaja obvia de que las copias de seguridad están automáticamente “fuera de las instalaciones”. Esto evita la necesidad adicional de proteger los medios de copia de seguridad dentro del sitio. Para obtener más información, vea Información general de la copia de seguridad de Azure y Usar DPM con la copia de seguridad de Azure.

Puede tener una solución de recuperación de desastres para las bases de datos de SQL Server en un entorno TI híbrido con grupos de disponibilidad AlwaysOn, creación de reflejo de la base de datos, trasvase de registros y copias de seguridad y restauración con almacenamiento de blobs de Azure. Todas estas soluciones utilizan SQL Server que se ejecuta en las máquinas virtuales de Azure.

Los Grupos de disponibilidad AlwaysOn se pueden usar en un entorno de TI híbrido en el que existen réplicas de la base de datos tanto en local como en la nube. Esto se muestra en el siguiente diagrama, tomado del completo artículo sobre este asunto Alta disponibilidad y recuperación de desastres para SQL Server en máquinas virtuales de Azure.

La creación de reflejo de la base de datos también puede abarcar varios servidores locales y la nube en una instalación basada en el certificado. El diagrama siguiente muestra este concepto.

El trasvase de registros se puede usar para sincronizar una base de datos local con una base de datos de SQL Server en una máquina virtual de Azure.

Finalmente, puede hacer la copia de seguridad de una base de datos local directamente en el almacenamiento de blobs de Azure.

Para obtener más información, vea Alta disponibilidad y recuperación de desastres para SQL Server en máquinas virtuales de Azure y Copias de seguridad y restauración para SQL Server en máquinas virtuales de Azure.

 

Servicio/área Lista de comprobación

Redes

  • Use la red virtual de datos para conectarse localmente con seguridad a la nube.

Proceso

  • Reubique las máquinas virtuales entre Hyper-V y Azure.

Almacenamiento

  • Aprovéchese de los servicios de StorSimple para utilizar el almacenamiento en la nube.

  • Use los servicios de copia de seguridad de Azure.

Base de datos

  • Considere usar SQL Server en las máquinas virtuales de Azure como copia de seguridad.

  • Configure Grupos de disponibilidad AlwaysOn.

  • Configure la creación de reflejo de la base de datos basada en certificados.

  • Use el trasvase de registros.

  • Realice la copia de seguridad de la base de datos local en el almacenamiento de blobs de Azure.

Este escenario trata sobre la recuperación cuando se han dañado los datos o se han eliminado accidentalmente debido a errores en la aplicación o de los operadores.

Tenga en cuenta que mientras el Almacenamiento de Azure proporciona resistencia de los datos a través de las réplicas automatizadas, esto no impide que el código de aplicación (o los programadores y usuarios) dañe los datos por una eliminación accidental, una actualización, etc. Mantener la fidelidad de los datos en caso de un error de la aplicación o del usuario requiere técnicas más avanzadas, como copiar los datos en una ubicación de almacenamiento secundaria con un registro de auditoría. Los desarrolladores pueden beneficiarse de la capacidad de realización de instantáneas de los blobs, que pueden crear instantáneas de solo lectura en un momento dado de su contenido. Esto se puede utilizar como base de una solución que conserve fielmente los datos en los blobs.

Aunque los blobs y tablas son muy duraderos, siempre representan el estado actual de los datos. Es posible que la recuperación de una modificación o eliminación equivocadas requiera la restauración de los datos a un estado anterior. Esto se puede lograr con las capacidades que ofrece Azure para almacenar y conservar las copias en un momento dado.

Para los blobs de Azure, puede realizar copias de seguridad en un momento determinado con la característica instantánea de blobs. Para cada instantánea, solo se le carga en concepto del almacenamiento necesario para almacenar las diferencias en el blob desde el último estado de la instantánea. Las instantáneas dependen de que exista el blob original en el que se basan, de modo que se recomienda realizar una operación de copia a otro blob o incluso disponer de otra cuenta de almacenamiento para asegurarse de que los datos de copia están debidamente protegidos frente a una eliminación accidental. Para el servicio Tabla de Azure, puede realizar copias en un momento dado en otra tabla o en el servicio Blob de Azure. Se pueden encontrar más abajo instrucciones detalladas y ejemplos sobre cómo realizar copias de seguridad en la aplicación de tablas y blobs:

Hay varias opciones de continuidad empresarial (copia de seguridad, restauración) disponibles para Base de datos SQL de Azure. Las bases de datos se pueden copiar mediante la funcionalidad de copia de base de datos o el servicio para importar y exportar una DAC. Una copia de base de datos proporciona resultados transaccionales coherentes, mientras que un bacpac (a través del servicio para importar y exportar) no los proporciona. Ambas opciones se ejecutan como servicios basados en cola en el centro de datos y no proporcionan actualmente un contrato de nivel de servicio hasta su finalización.

noteNota
Observe que el servicio de copia de base de datos y de importación y exportación suponen un grado de carga significativo en la base de datos de origen, y pueden la desencadenar contención de los recursos o eventos de limitación (descritos en la sección siguiente sobre los recursos compartidos y la limitación).

Las copias de seguridad en un momento dado para Base de datos SQL de Microsoft Azure se realizan con el comando Copiar bases de datos en Base de datos SQL de Azure. Puede utilizar este comando para crear una copia transaccionalmente coherente de una base de datos en el mismo servidor de bases de datos lógico o en un servidor diferente. En cualquier caso, la copia de la base de datos es totalmente funcional y completamente independiente de la base de datos de origen. Cada copia que cree representa una opción de recuperación en un momento dado. Para recuperar el estado de la base de datos completamente, cambie el nombre de la nueva base de datos por el nombre de la base de datos de origen. O bien, también puede recuperar un subconjunto concreto de datos de la nueva base de datos mediante consultas de Transact-SQL. Para obtener detalles adicionales sobre la base de datos SQL, vea Continuidad de negocio en Base de datos SQL de Azure.

Para SQL Server en IaaS hay dos opciones: las copias de seguridad tradicionales y el trasvase de registros. El uso de las copias de seguridad tradicionales le permite restaurar a un momento dado, pero el proceso de recuperación es lento. Restaurar las copias de seguridad tradicionales requiere empezar con una copia de seguridad completa inicial y, después, aplicar las copias de seguridad realizadas a continuación. La segunda opción es configurar una sesión de trasvase de registros para retrasar la restauración de las copias de seguridad de registros (por ejemplo, en dos horas). Esto proporciona una ventana para recuperarse de los errores del servidor principal.

Ciertos servicios de la plataforma de Azure almacenan la información en una cuenta de almacenamiento controlada por el usuario o Base de datos SQL de Azure. Si se elimina o se daña el recurso de almacenamiento o la cuenta, podrían provocarse errores graves en el servicio. En estos casos, es importante mantener copias de seguridad que le permitirían volver a crear estos recursos si se eliminaran o se dañaran.

Con los sitios web y los servicios móviles de Azure, debe hacer la copia de seguridad y mantener las bases de datos asociadas. Para Servicios multimedia y las máquinas virtuales de Azure, debe mantener la cuenta asociada de almacenamiento de Azure y todos los recursos de esta cuenta. Por ejemplo, con las máquinas virtuales, debe hacer la copia de seguridad y administrar los discos de máquina virtual en el almacenamiento de blobs de Azure.

 

Servicio/área Lista de comprobación

Almacenamiento

  • Realice periódicamente una copia de seguridad de los recursos esenciales de almacenamiento.

  • Considere usar la característica de instantánea para los blobs.

Base de datos

  • Cree copias de seguridad hasta un momento dado con el comando de copia de la base de datos.

SQL Server en la copia de seguridad de las máquinas virtuales (IaaS)

  • Utilice técnicas tradicionales de copia de seguridad y restauración.

  • Cree una sesión diferida de trasvase de registros

Sitios web

  • Haga una copia de seguridad y mantenga la base de datos asociada, si existe.

Servicios para móviles

  • Haga una copia de seguridad y mantenga la base de datos asociada.

Media Services

  • Haga una copia de seguridad y mantenga los recursos de almacenamiento asociados.

Máquinas virtuales

  • Haga una copia de seguridad y mantenga los discos de máquina virtual en el almacenamiento de blobs.

Failsafe: Instrucciones para crear arquitecturas de nube resistentes: Orientación para la creación de arquitecturas en la nube resistentes, orientación para implementar dichas arquitecturas en tecnologías de Microsoft y recetas para implementar estas arquitecturas en escenarios concretos.

Consideraciones sobre la alta disponibilidad y la recuperación ante desastres para las aplicaciones de Azure: información general detallada de la disponibilidad y la recuperación de desastres. Trata sobre el desafío de la replicación manual para los datos transaccionales y de referencia. Las secciones finales proporcionan resúmenes de distintos tipos de topologías de recuperación de desastres que abarcan los centros de datos de Azure para el máximo nivel de disponibilidad.

Continuidad de negocio en Base de datos SQL de Azure: se centra exclusivamente en las técnicas de Base de datos SQL de Azure de Azure relativas a la disponibilidad, que se basan sobre todo en estrategias de copia de seguridad y restauración. Si utiliza Base de datos SQL de Azure en el servicio en la nube, debe leer este documento y sus recursos relacionados.

Alta disponibilidad y recuperación ante desastres para SQL Server en máquinas virtuales de Azure: describe la disponibilidad de las opciones de que dispone si usa la Infraestructura como servicio (IaaS) para hospedar los servicios de bases de datos. Describe los Grupos de disponibilidad AlwaysOn, la creación de reflejo de la base de datos, el trasvase de registros y la copia de seguridad o restauración. Observe que también hay varios tutoriales en la misma sección que muestran cómo utilizar estas técnicas.

Prácticas recomendadas para el diseño de servicios a gran escala en los Servicios en la nube de Azure: se centra en desarrollar arquitecturas muy escalables en la nube. Muchas de las técnicas que se emplean para mejorar la escalabilidad también mejoran la disponibilidad. Además, si la aplicación no puede escalar con una carga mayor, la escalabilidad se convierte en un problema de disponibilidad.

Copias de seguridad y restauración para SQL Server en máquinas virtuales de Azure

Mostrar:
© 2014 Microsoft