Mejores prácticas
Casos de uso de actualización y clonado del sistema
Sugerir cambios
PDF
Hay varios escenarios en los que los datos de un sistema de origen deben estar disponibles para un sistema de destino con fines de pruebas o entrenamiento. Estos sistemas de pruebas y formación deben actualizarse periódicamente con los datos del sistema de origen para asegurarse de que se realizan las pruebas y la formación con el conjunto de datos actual.
Estas operaciones de actualización del sistema constan de varias tareas en las capas de infraestructura, base de datos y aplicación. Pueden tardar varios días en función del nivel de automatización.
En la siguiente figura se describen las operaciones de actualización, copia y clonación de los sistemas SAP.
Los flujos de trabajo de clonación de SnapCenter se pueden usar para acelerar y automatizar las tareas necesarias en las capas de infraestructura y base de datos. En lugar de restaurar un backup del sistema de origen al sistema de destino, SnapCenter utiliza la copia Snapshot de NetApp y la tecnología FlexClone de NetApp, de modo que las tareas necesarias hasta una base de datos HANA que se ha iniciado se pueden llevar a cabo en minutos en lugar de horas, como se muestra en la siguiente figura. El tiempo necesario para el proceso de clonación es independiente del tamaño de la base de datos, por lo que es posible crear sistemas de gran tamaño en un par de minutos.
En la siguiente figura, se muestra la actualización de datos de sistemas de control de calidad, pruebas, filtrado o formación.
El flujo de trabajo de las operaciones de actualización del sistema se describe en la sección "“Actualización del sistema SAP HANA con SnapCenter”."
Daños lógicos de dirección
La corrupción lógica puede deberse a errores de software, errores humanos o sabotaje. Desgraciadamente, la corrupción lógica no se puede hacer frente a menudo con soluciones estándares de alta disponibilidad y de recuperación ante desastres. Como resultado, dependiendo de la capa, la aplicación, el sistema de archivos o el almacenamiento donde se produjo el daño lógico, a veces no se pueden satisfacer los requisitos mínimos de tiempo de inactividad y pérdida máxima de datos.
En el peor de los casos, se puede ver un daño lógico en una aplicación SAP. Las aplicaciones SAP suelen funcionar en un entorno en el que diferentes aplicaciones se comunican entre sí y intercambian datos. Por lo tanto, el enfoque recomendado no es restaurar ni recuperar un sistema SAP en el que se ha producido un daño lógico. Cuando se restaura el sistema a un momento específico antes de que se dañara, se perderán los datos. Además, el entorno SAP ya no estaría sincronizado y necesitaría un postprocesamiento adicional.
En lugar de restaurar el sistema SAP, el mejor método es intentar solucionar el error lógico dentro del sistema analizando el problema en un sistema de reparación independiente. El análisis de la causa raíz requiere la participación del proceso empresarial y el propietario de la aplicación. En esta situación, puede crear un sistema de reparación (un clon del sistema de producción) basado en los datos almacenados antes de que se produjera el daño lógico. Dentro del sistema de reparación, los datos necesarios se pueden exportar e importar al sistema de producción. Con este método, no es necesario detener el sistema de producción y, en el mejor de los casos, no se pierden datos ni solo una pequeña fracción de estos.
Al configurar el sistema de reparación, la flexibilidad y la velocidad son cruciales. Con los backups Snapshot basados en almacenamiento de NetApp, hay disponibles varias imágenes de bases de datos consistentes para crear un clon del sistema de producción con la tecnología FlexClone de NetApp, como se muestra en la siguiente figura. Los volúmenes FlexClone se pueden crear en cuestión de segundos en lugar de varias horas si se realiza una restauración redirigida a partir de un backup basado en archivos para configurar el sistema de reparación.
El flujo de trabajo de creación del sistema de reparación se describe en la sección "“Clonado del sistema SAP con SnapCenter”."
Pruebas de recuperación ante desastres
Para que una estrategia de recuperación ante desastres sea eficaz, es necesario probar el flujo de trabajo necesario. Las pruebas demuestran si la estrategia funciona y si la documentación interna es suficiente. Además, permite a los administradores entrenar en los procedimientos requeridos.
La replicación de almacenamiento con SnapMirror permite ejecutar pruebas de recuperación ante desastres sin poner en riesgo el objetivo de tiempo de recuperación ni el objetivo de punto de recuperación. Las pruebas de recuperación ante desastres pueden realizarse sin interrumpir la replicación de datos.
Las pruebas de recuperación ante desastres para SnapMirror asíncrono y síncrono utilizan backups de Snapshot y volúmenes FlexClone en el destino de recuperación ante desastres.
La figura siguiente muestra las pruebas de recuperación tras desastres.
En el informe técnico se puede encontrar una descripción detallada paso a paso "Recuperación ante desastres de SAP HANA con replicación de almacenamiento".