fbpx
Saltear al contenido principal

recuperación de datos en caso de desastreSi echa un vistazo a los canales de noticias verá que los desastres pueden producirse en cualquier momento. Fenómenos climáticos extremos, terremotos, incendios, fallas eléctricas a gran escala: estos y otros escenarios amenazadores pueden provocar interrupciones en su TI y sus negocios. El campo de Recuperación de datos en caso de desastre (DR) ha evolucionado para abordar el desafío de garantizar una recuperación rápida y operaciones continuas en caso de desastre. Ahora, la nube ha cambiado la naturaleza y el potencial de la DR. Los nuevos avances en la recuperación de datos en caso de desastre en la nube requieren nuevas prácticas. Además, los enfoques totalmente nuevos, como las zonas de disponibilidad, pueden cambiar drásticamente todo el proceso de razonamiento sobre cómo proteger mejor una empresa ante un desastre.

La evolución de la recuperación de datos en caso de desastre en la era de la nube

La concepción de la seguridad de la información tradicional (InfoSec) sobre la recuperación de datos en caso de desastre estaba compuesta por tres (o cuatro) enfoques estándar cuyo objetivo era mantener el funcionamiento de la TI en caso de que se produjera una interrupción. Desde una perspectiva InfoSec, la interrupción podría estar causada por cualquier factor. Lo que importaba era la capacidad de volver a introducir las aplicaciones y los datos en línea en un plazo de tiempo acorde con las expectativas de la organización.

Los tres enfoques básicos eran el «sitio frío», el «sitio cálido» y el «sitio caliente». Un sitio frío era simplemente un lugar, separado de la ubicación de la empresa, donde se encontrarían almacenados el hardware informático y el software. Si se producía un desastre, se podía ir al sitio frío, instalar el equipo, instalar el software, cargar los datos con copia de seguridad de las cintas y hacer que los servicios de TI estuvieran disponibles para los usuarios. Por el contrario, el sitio cálido contaba con el equipo y el software listos para funcionar, pero no en funcionamiento. El sitio caliente lo tenía todo en funcionamiento como una réplica exacta de los sistemas en vivo, por lo que habría un tiempo de inactividad mínimo para realizar la restauración.

De estos tres, el sitio caliente ofreció el Objetivo de tiempo de recuperación (RTO, por sus siglas en inglés) más rápido. Una cuarta opción era el «sitio espejo», que funcionaba en paralelo con la instancia principal del software y los datos que protegía. Podía tener un retraso de una fracción de segundo, pero era esencialmente un gemelo idéntico de la infraestructura de TI. Podía realizar una conmutación por error a un sitio espejo en segundos, lo que garantizaba un servicio casi ininterrumpido. El sitio espejo, por supuesto, era la opción más costosa, seguida del sitio caliente, cálido y frío en orden descendente de gastos. Las cargas de trabajo de TI más urgentes se asignaban a sitios espejo o calientes.

La nube ha transformado completamente el paradigma tradicional de DR InfoSec en sitios frío/cálido/caliente/espejo. Gracias a su almacenamiento y sus procesos esencialmente ilimitados y de configuración rápida, un proveedor de nube pública puede reducir mucho el coste del sitio espejo, que anteriormente era costoso. Es mucho más fácil y menos costoso ejecutar versiones gemelas de aplicaciones principales en múltiples ubicaciones (en paralelo).

Incluso para tareas de DR menos complejas, la nube supone un gran cambio. La copia de seguridad y la réplica de datos, por ejemplo, son mucho más sencillas y menos costosas en la nube que en las arquitecturas de DR locales tradicionales. Estos avances, sin embargo, no cambian los fundamentos de la DR. En todo caso, las opciones de DR de la nube más rápidas y baratas han ejercido más presión sobre los administradores de DR para determinar qué cargas de trabajo merecen nuevos niveles de protección más altos y cuáles no.

Estrategia de recuperación de datos en caso de desastre en la nube

La estrategia de recuperación de datos en caso de desastre no cambia drásticamente con la incorporación de la nube, pero hay nuevos factores que deben tenerse en cuenta. Su estrategia de recuperación de datos en caso de desastre en la nube todavía debe orientarse hacia el negocio y reflejar las prioridades de la empresa y su modelo operativo. Por ejemplo, si SAP ERP requiere el RTO más rápido, el objetivo de la estrategia de DR permanecerá sin cambios, incluso si la DR se lleva a cabo en la nube.

La estrategia de DR en la nube debe, al igual que sus encarnaciones anteriores, alinearse con el plan de continuidad de negocios más amplio. Después de todo, la TI es solo un elemento más de un negocio. Cuando se produce un desastre, una empresa debe poder funcionar en todos los niveles, no solo en términos de TI. Esto incluye a las personas, las instalaciones, el mantenimiento de registros, la cadena de suministro, la logística, etc. El plan de continuidad empresarial tendrá en cuenta todos estos elementos.

El nuevo universo de amenazas cibernéticas también ha cambiado la ecuación de DR. El ciberespacio presenta un nuevo tipo de desastre, uno que posiblemente es más complejo que cualquier fenómeno natural. Aunque un huracán pueda destruir un centro de datos, los vientos fuertes no dañarían sus datos ni los retendrían para obtener un rescate. La estrategia de recuperación de datos en caso de desastre en la nube debe incluir contramedidas de seguridad que mantengan los sistemas de copia de seguridad y los datos libres de malware, y protegidos frente a las amenazas informáticas.

Zonas de disponibilidad en la nube

La nube ha creado una nueva opción para la DR conocida como la zona de disponibilidad en la nube. Si se le echa un vistazo, se pueden ver algunos componentes familiares de la DR tradicional. Sin embargo, también es bastante novedosa e innovadora.

¿Qué es una zona de disponibilidad?

Una zona de disponibilidad es una agrupación lógica de recursos que mantienen una separación física dentro de un centro de datos, o en el caso de AWS, en 2 o más centros de datos dentro de la misma área regional. En la nube pública, colocar un conjunto de recursos, normalmente instancias, en una zona de disponibilidad significa que obtendrán un mayor nivel de disponibilidad, lo que se traduce en que se garantiza un nivel de servicio más alto. Si se produce un corte de luz en un conjunto de recursos, es probable que el resto de recursos de la zona de disponibilidad no se vean afectados, lo que representa el objetivo principal de la zona de disponibilidad.

Si distribuye sus instancias en múltiples zonas de disponibilidad y se produce un fallo en una instancia, puede diseñar su aplicación para que una instancia de otra zona de disponibilidad pueda gestionar las solicitudes. Es importante tener en cuenta que las instancias secundarias no son clones de las instancias primarias. Depende de la aplicación reanudar el funcionamiento en las instancias secundarias y que la conectividad a la aplicación esté correctamente diseñada para que los procesos y los usuarios puedan acceder a ella.

Tener los SLA y los costes en mente

Configurar una zona de disponibilidad de DR a través de un proveedor en la nube no es tan simple como parece. Al trabajar con compañías que están creando zonas de disponibilidad para sus entornos SAP, hemos encontrado que es esencial prestar atención a los SLA con detenimiento. Aunque la mayoría de las plataformas en la nube proporcionan un buen rendimiento, los efectos del espacio geográfico y otros factores, como la calidad de los recursos informáticos y las redes, pueden afectar negativamente a los SLA. Las pruebas son fundamentales para garantizar su mantenimiento dentro de sus SLA en una zona de disponibilidad.

El coste es un problema. Los recursos de la nube son generalmente muy económicos, pero la intensidad de procesos y almacenamiento que necesita para duplicar un entorno SAP puede generar una factura de la nube más alta de lo que esperaba. También deberá organizar la obtención de licencias de software en la zona de disponibilidad.

La nube híbrida también complica las cosas. Nadie ofrece SAP al 100 % en la nube todavía. La mayoría de las organizaciones que ejecutan SAP en la nube lo están haciendo de forma híbrida, mezclando instancias locales con la nube. Para hacer que las zonas de disponibilidad de la nube sean efectivas, deberá replicar las instancias locales en una implementación de la nube por separado. Se necesita mucho trabajo y pruebas de DR para hacerlo bien.

Selección de un socio de DR para SAP

Contamos con una amplia experiencia en la implementación de programas de recuperación de datos en caso de desastre en la nube en empresas. Entendemos los matices de las zonas de disponibilidad y las recomendamos cuando se ajustan mejor a su estrategia de DR y su empresa en general.

Nick Suter, Senior SAP Basis Consultant

Nick is a Senior SAP Basis Consultant on Symmetry's consulting team, delivering expert technical day-to-day system monitoring support directly to Symmetry’s valued SAP customers. He pairs his sound technical knowledge with outstanding customer service to ensure Symmetry’s clients receive highly disciplined support and industry best practices to keep their SAP systems continuously running smoothly.