La siguiente figura muestra una instalación estándar en la que el agente SnapCenter junto con el complemento de base de datos se instaló localmente en el servidor de origen y de base de datos de destino. En la configuración de laboratorio, instalamos el complemento SAP HANA. Además, el trabajador de LSC también se instaló en el servidor de destino. Para simplificar y reducir el número de servidores virtuales, instalamos el maestro LSC en el servidor SnapCenter. En la siguiente figura, se muestra la comunicación entre los diferentes componentes.

La siguiente figura muestra la configuración mediante un host de comunicación central. En esta configuración, el agente SnapCenter junto con el plugin de SAP HANA y el cliente de base de datos HANA se instalaron en un servidor dedicado. En esta configuración, utilizamos el servidor SnapCenter para instalar el host de comunicación central. Además, el trabajador de LSC se instaló de nuevo en el servidor de destino. Para simplificar y reducir el número de servidores virtuales, decidimos también instalar el maestro LSC en el servidor SnapCenter. La comunicación entre los diferentes componentes se ilustra en la siguiente figura.

En esta sección se describen los pasos de configuración necesarios cuando se utiliza una instalación estándar en la que se instalan el agente de SnapCenter y el plugin de base de datos necesario en los sistemas de origen y de destino. Al utilizar una instalación estándar, todas las tareas necesarias para montar el volumen de clonado y restaurar y recuperar el sistema de destino se llevan a cabo desde el agente SnapCenter que se ejecuta en el sistema de la base de datos de destino en el propio servidor. De este modo, es posible acceder a todos los detalles relacionados con clones que están disponibles a través de variables del entorno del agente SnapCenter. Por lo tanto, sólo necesita crear una tarea adicional en la fase de copia LSC. En esta tarea se lleva a cabo el proceso de copia de Snapshot en el sistema de la base de datos de origen y el proceso de clonado y restauración y recuperación en el sistema de la base de datos de destino. Todas las tareas relacionadas con SnapCenter se activan mediante un script de PowerShell que se introduce en la tarea LSC NTAP_SYSTEM_CLONE.

La siguiente imagen muestra la configuración de tareas LSC en la fase de copia.

La siguiente imagen resalta la configuración del NTAP_SYSTEM_CLONE proceso. Puesto que ejecuta un script de PowerShell, este script de Windows PowerShell se ejecuta en el sistema satélite. En este caso, se trata del servidor SnapCenter con el maestro LSC instalado que también actúa como un sistema satélite.

Dado que LSC debe estar al tanto de si la operación de copia Snapshot, clonado y recuperación se ha realizado correctamente, debe definir al menos dos tipos de código de retorno. Un código es para una ejecución correcta del script, y el otro código es para una ejecución fallida del script, como se muestra en la siguiente imagen.

La siguiente imagen muestra parte del script de PowerShell que se debe ejecutar para ejecutar un backup basado en Snapshot en el sistema de la base de datos de origen y un clon en el sistema de la base de datos de destino. La secuencia de comandos no está diseñada para ser completa. En su lugar, el script muestra cómo la integración entre LSC y SnapCenter puede verse y lo fácil que es configurarlo.

Dado que la secuencia de comandos se ejecuta en el maestro LSC (que también es un sistema satélite), el maestro LSC en el servidor SnapCenter debe ejecutarse como un usuario de Windows que tenga los permisos adecuados para ejecutar las operaciones de copia de seguridad y clonación en SnapCenter. Para verificar si el usuario tiene el permiso apropiado, el usuario debe poder ejecutar una copia Snapshot y un clon en la interfaz de usuario de SnapCenter.

No es necesario ejecutar el satélite LSC MASTER y el satélite LSC en el propio servidor SnapCenter. El satélite LSC Master y el satélite LSC pueden ejecutarse en cualquier máquina Windows. El requisito previo para ejecutar la secuencia de comandos de PowerShell en el satélite LSC es que se han instalado los cmdlets de PowerShell de SnapCenter en Windows Server.

Para la integración entre LSC y SnapCenter utilizando un host de comunicación central, los únicos ajustes que deben realizarse se realizan en la fase de copia. La copia Snapshot y el clon se crean mediante el agente SnapCenter en el host de comunicación central. Por lo tanto, todos los detalles sobre los volúmenes recién creados solo están disponibles en el host de comunicación central y no en el servidor de base de datos de destino. Sin embargo, estos detalles son necesarios en el servidor de la base de datos de destino para montar el volumen clonado y llevar a cabo la recuperación. Este es el motivo por el que se necesitan dos tareas adicionales en la fase de copia. Se ejecuta una tarea en el host de comunicación central y se ejecuta una tarea en el servidor de base de datos de destino. Estas dos tareas se muestran en la siguiente imagen.

La siguiente imagen resalta la configuración de la tarea NTAP_SYSTEM_CLONE_CP. Se trata del script de Windows PowerShell que se ejecuta en el sistema por satélite. En este caso, el sistema satélite es el servidor SnapCenter con el maestro LSC instalado.

Como LSC debe saber si la operación de copia Snapshot y clonación se ha realizado correctamente, debe definir al menos dos tipos de código de retorno: Un código de retorno para una ejecución correcta del script y el otro para una ejecución fallida del script, como se muestra en la imagen siguiente.

La siguiente imagen muestra parte del script de PowerShell que se debe ejecutar para ejecutar una copia Snapshot y un clon con el agente SnapCenter en el host de comunicación central. La secuencia de comandos no está pensada para estar completa. En su lugar, el script se utiliza para mostrar cómo la integración entre LSC y SnapCenter puede verse y lo fácil que es configurarlo.

Como se ha mencionado anteriormente, debe pasar el nombre del volumen clonado a la siguiente tarea NTAP_MNT_RECOVER_CP para montar el volumen clonado en el servidor de destino. El nombre del volumen clonado, también conocido como ruta de unión, se almacena en la variable $JunctionPath. La entrega a una tarea de LSC posterior se logra a través de una variable de LSC personalizada.

Dado que la secuencia de comandos se ejecuta en el maestro LSC (que también es un sistema satélite), el maestro LSC en el servidor SnapCenter debe ejecutarse como un usuario de Windows que tenga los permisos adecuados para ejecutar las operaciones de copia de seguridad y clonación en SnapCenter. Para verificar si tiene los permisos adecuados, el usuario debe poder ejecutar una copia de Snapshot y un clon en la interfaz gráfica de usuario de SnapCenter.

En la siguiente figura se destaca la configuración de la tarea NTAP_MNT_RECOVER_CP. Como queremos ejecutar una secuencia de comandos Shell de Linux, se trata de una secuencia de comandos ejecutada en el sistema de base de datos de destino.

Dado que el LSC debe estar consciente del montaje de los volúmenes clonados y si la restauración y recuperación de la base de datos de destino se realizó correctamente, debemos definir al menos dos tipos de código de retorno. Un código es para una ejecución correcta del script y uno es para una ejecución fallida del script, como se muestra en la siguiente figura.

En la siguiente figura, se muestra parte del script Linux Shell que se utilizó para detener la base de datos de destino, desmontar el volumen antiguo, montar el volumen clonado, y restaurar y recuperar la base de datos de destino. En la tarea anterior, la ruta de unión se escribió en una variable LSC. El siguiente comando lee esta variable LSC y almacena el valor en $JunctionPath Variable de la secuencia de comandos del shell de Linux.

El trabajador del LSC en el sistema de destino se ejecuta como <sidaadm>, pero los comandos de montaje deben ejecutarse como usuario root. Por eso debe crear el central_plugin_host_wrapper_script.sh. El script central_plugin_host_wrapper_script.sh se llama desde la tarea NTAP_MNT_RECOVERY_CP con el sudo comando. Con el sudo Comando, el script se ejecuta con UID 0 y podemos realizar todos los pasos posteriores, como desmontar los volúmenes antiguos, montar los volúmenes clonados y restaurar y recuperar la base de datos de destino. Para habilitar la ejecución de scripts mediante sudo, se debe agregar la siguiente línea en /etc/sudoers: