Casos de uso de actualización y clonado del sistema
Sugerir cambios
PDF
Las soluciones de NetApp para optimizar la gestión del ciclo de vida de SAP están integradas en las herramientas de gestión del ciclo de vida y bases de datos de SAP HANA, combinando una protección eficiente de datos integrada en las aplicaciones con el aprovisionamiento flexible de sistemas de prueba de SAP.
Actualización de datos de sistemas de control de calidad, pruebas, filtrado o formación
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.
Los flujos de trabajo de clonado de SnapCenter se pueden usar para acelerar y automatizar las tareas necesarias en las capas de la infraestructura y de bases 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 SAP HANA iniciada pueden llevarse a cabo en minutos en lugar de horas. 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. El tiempo de inicio solo depende del tamaño de la base de datos y de la conectividad entre el servidor de la base de datos y el sistema de almacenamiento.
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 agilidad son cruciales. Cuando se utilizan backups de SnapVault basados en almacenamiento de NetApp, hay disponibles varias imágenes de base de datos consistentes para crear un clon del sistema de producción mediante la tecnología FlexClone de NetApp. 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
Una estrategia de recuperación ante desastres eficaz necesita probar el flujo de trabajo requerido. Las pruebas demuestran si la estrategia funciona y si la documentación interna es suficiente. También permite a los administradores formar los procedimientos necesarios.
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.
Puede encontrar una descripción detallada paso a paso en los informes técnicos