Se proporciona el idioma español mediante traducción automática para su comodidad. En caso de alguna inconsistencia, el inglés precede al español.

Actualización del sistema SAP HANA con SnapCenter

07/18/2024 Colaboradores

PDF

En la siguiente sección se proporciona una descripción paso a paso de las diferentes opciones de operación de actualización del sistema de una base de datos SAP HANA.

En función de la configuración de la base de datos SAP HANA, se ejecutan o deben prepararse pasos adicionales. La siguiente tabla muestra un resumen.

Sistema de origen	Configuración del sistema de origen	Operaciones de SnapCenter y SAP HANA
Inquilino único MDC + SID = nombre de inquilino	Configuración estándar	Operación de clonado de SnapCenter y ejecución de script de recuperación opcional.
	Cifrado persistente de SAP HANA	Inicialmente, o si se han cambiado las claves raíz en el sistema de origen, se deben importar copias de seguridad de clave raíz en el sistema de destino antes de poder ejecutar la recuperación.
	Origen de replicación del sistema SAP HANA	No se requieren pasos adicionales. Si el sistema de destino no tiene HSR configurado, seguirá siendo un sistema independiente.
	Varias particiones de SAP HANA	No se requieren pasos adicionales, pero los puntos de montaje para particiones de volúmenes SAP HANA deben estar disponibles en el sistema de destino con la misma convención de nomenclatura (solo el SID es diferente).
MDC varios inquilinos O inquilino único MDC + con SID <> nombre de inquilino	Configuración estándar	Operación de clonado de SnapCenter y ejecución de script de recuperación opcional. El script recupera todos los inquilinos. Si no existen inquilinos o nombres de inquilinos en los nombres del sistema de destino, los directorios necesarios se crearán automáticamente durante la operación de recuperación de SAP HANA. Los nombres de arrendatarios serán los mismos que los de origen y deberán cambiarse de nombre después de la recuperación, si es necesario.
	Cifrado persistente de SAP HANA	Si un DBID del sistema de origen no existe antes en el sistema de destino, la base de datos del sistema se debe recuperar primero, antes de poder importar la copia de seguridad de la clave raíz de este arrendatario.
	Origen de replicación del sistema HANA	No se requieren pasos adicionales. Si el sistema de destino no tiene HSR configurado, seguirá siendo un sistema independiente.
	Múltiples particiones de HANA	No se requieren pasos adicionales, pero los puntos de montaje para particiones de volúmenes SAP HANA deben estar disponibles en el sistema de destino con la misma convención de nomenclatura (solo el SID es diferente).

Sistema de origen

Configuración del sistema de origen

Operaciones de SnapCenter y SAP HANA

Inquilino único MDC + SID = nombre de inquilino

Configuración estándar

Operación de clonado de SnapCenter y ejecución de script de recuperación opcional.

Cifrado persistente de SAP HANA

Inicialmente, o si se han cambiado las claves raíz en el sistema de origen, se deben importar copias de seguridad de clave raíz en el sistema de destino antes de poder ejecutar la recuperación.

Origen de replicación del sistema SAP HANA

No se requieren pasos adicionales. Si el sistema de destino no tiene HSR configurado, seguirá siendo un sistema independiente.

Varias particiones de SAP HANA

No se requieren pasos adicionales, pero los puntos de montaje para particiones de volúmenes SAP HANA deben estar disponibles en el sistema de destino con la misma convención de nomenclatura (solo el SID es diferente).

MDC varios inquilinos

O inquilino único MDC + con SID <> nombre de inquilino

Configuración estándar

Operación de clonado de SnapCenter y ejecución de script de recuperación opcional. El script recupera todos los inquilinos. Si no existen inquilinos o nombres de inquilinos en los nombres del sistema de destino, los directorios necesarios se crearán automáticamente durante la operación de recuperación de SAP HANA. Los nombres de arrendatarios serán los mismos que los de origen y deberán cambiarse de nombre después de la recuperación, si es necesario.

Cifrado persistente de SAP HANA

Si un DBID del sistema de origen no existe antes en el sistema de destino, la base de datos del sistema se debe recuperar primero, antes de poder importar la copia de seguridad de la clave raíz de este arrendatario.

Origen de replicación del sistema HANA

No se requieren pasos adicionales. Si el sistema de destino no tiene HSR configurado, seguirá siendo un sistema independiente.

Múltiples particiones de HANA

En esta sección se tratan los siguientes escenarios.

Actualización del sistema SAP HANA sin una operación de división de clones.
Clonado de almacenamiento principal con un nombre de inquilino igual al SID
Clonado desde almacenamiento de backup externo
Clonado desde el almacenamiento primario con varios usuarios
Operación de eliminación de clones
Actualización del sistema SAP HANA con una operación de división de clones
Clonado de almacenamiento principal con un nombre de inquilino igual al SID
Operación de división de clones

Requisitos previos y limitaciones

Los flujos de trabajo descritos en las siguientes secciones tienen algunos requisitos previos y limitaciones relacionados con la arquitectura del sistema SAP HANA y la configuración de SnapCenter.

Los flujos de trabajo descritos solo son válidos para la versión SnapCenter 5,0 o posterior.
Los flujos de trabajo descritos son válidos para sistemas SAP HANA MDC de un solo host con uno o varios inquilinos. No se cubren varios sistemas host de SAP HANA.
El complemento SAP HANA de SnapCenter se debe poner en marcha en el host de destino para permitir la detección automática de SnapCenter y la ejecución de scripts de automatización.
Los flujos de trabajo son válidos para los sistemas SAP HANA que utilizan NFS o FCP en hosts físicos, o para hosts virtuales que utilizan montajes NFS en invitado.

Configuración de laboratorio

La siguiente figura muestra la configuración de laboratorio utilizada para las diferentes opciones de operación de actualización del sistema.

Clonado desde almacenamiento principal o almacenamiento de respaldo externo; el nombre del inquilino es igual al SID.
- Sistema SAP HANA de origen: SS1 con Tenant SS1
- Diríjase al sistema SAP HANA: QS1 con el inquilino QS1
Clonado desde el almacenamiento principal; varios inquilinos.
- Sistema SAP HANA de fuente: SM1 con Tenant1 y Tenant2
- Diríjase al sistema SAP HANA: QS1 con Tenant1 y Tenant2

Se utilizaron las siguientes versiones de software:

SnapCenter 5,0
Sistemas SAP HANA: HANA 2,0 SPS7 rev,73
SLES 15
ONTAP 9.14P1

Todos los sistemas SAP HANA deben configurarse en función de la guía de configuración "SAP HANA en sistemas AFF de NetApp con NFS". SnapCenter y los recursos de SAP HANA se configuraron en función de la guía de mejores prácticas "Backup y recuperación de datos de SAP HANA con SnapCenter".

Pasos iniciales de preparación única

Como paso inicial, el sistema SAP HANA de destino debe configurarse en SnapCenter.

Instalación del sistema de destino SAP HANA
Configuración del sistema SAP HANA en SnapCenter como se describe en "TR-4614: Backup y recuperación de datos de SAP HANA con SnapCenter"
1. Configuración del usuario de base de datos SAP HANA para operaciones de backup de SnapCenter Este usuario debe ser idéntico en el sistema de origen y el de destino.
2. Configuración de la clave hdbuserstore para <sid>adm con el usuario de copia de seguridad anterior. Si se utiliza el script de automatización para la recuperación, el nombre de clave debe ser <SID>KEY
3. Puesta en marcha del complemento SAP HANA de SnapCenter en el host de destino. El sistema SAP HANA es detectado automáticamente por SnapCenter.
4. Configuración de la protección de recursos SAP HANA (opcional)

El primer funcionamiento de actualización del sistema SAP después de la instalación inicial se prepara con los pasos siguientes:

Cierre el sistema SAP HANA de destino
Desmonte el volumen de datos de SAP HANA.

Debe agregar los scripts que deben ejecutarse en el sistema de destino al archivo de configuración de comandos permitidos de SnapCenter.

hana-7:/opt/NetApp/snapcenter/scc/etc # cat /opt/NetApp/snapcenter/scc/etc/allowed_commands.config
command: mount
command: umount
command: /mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh
hana-7:/opt/NetApp/snapcenter/scc/etc #

La clonación del almacenamiento primario con el nombre de inquilino es igual a SID

En esta sección se describe el flujo de trabajo de actualización del sistema SAP HANA en el que el nombre del inquilino en el sistema de origen y de destino es idéntico al SID. La clonación de almacenamiento se ejecuta en el almacenamiento primario y la recuperación se automatiza mediante el script sc-system-refresh.sh.

El flujo de trabajo consta de los siguientes pasos:

Si el cifrado de persistencia de SAP HANA está habilitado en el sistema de origen, las claves raíz de cifrado se deben importar una vez. También es necesaria una importación si las claves se han cambiado en el sistema de origen. Consulte el capítulo "«Consideraciones sobre las operaciones de actualización del sistema SAP HANA con los backups de snapshots de almacenamiento»"
Si el sistema SAP HANA de destino se protegió en SnapCenter, primero se debe quitar la protección.
Flujo de trabajo de creación de clones de SnapCenter.
1. Seleccione Snapshot backup desde el sistema SAP HANA de origen SS1.
2. Seleccione el host de destino y proporcione la interfaz de red de almacenamiento del host de destino.
3. Proporcionar SID del sistema de destino, en nuestro ejemplo QS1
4. De manera opcional, proporcione un script para la recuperación como una operación posterior a la clonado.
Operación de clonado de SnapCenter.
1. Crea volumen FlexClone basado en un backup Snapshot seleccionado del sistema SAP HANA de origen.
2. Exporta volumen FlexClone a la interfaz de red de almacenamiento del host o el igroup de destino.
3. Ejecuta la operación de montaje del volumen FlexClone en el host de destino.
4. Ejecuta el script de recuperación de operaciones posteriores a la clonación, si se configuró anteriormente. De lo contrario, la recuperación debe realizarse manualmente cuando finalice el flujo de trabajo de SnapCenter.
  - Recuperación de la base de datos del sistema.
  - Recuperación de la base de datos de arrendatarios con el nombre del arrendatario = QS1.
Opcionalmente, proteja el recurso SAP HANA de destino en SnapCenter.

Las siguientes capturas de pantalla muestran los pasos necesarios.

Seleccione un backup de Snapshot del sistema de origen SS1 y haga clic en Clone.

Seleccione el host en el que está instalado el sistema de destino QS1. Introduzca QS1 como SID de destino. La dirección IP de exportación de NFS debe ser la interfaz de red de almacenamiento del host de destino.

El SID de destino que se introduce controla el modo en que SnapCenter gestiona el recurso clonado. Si un recurso con el SID de destino ya está configurado en SnapCenter y coincide con el host del plugin, SnapCenter solo asigna el clon a este recurso. Si el SID no está configurado en el host de destino, SnapCenter crea un recurso nuevo.

Es fundamental que el recurso y el host del sistema de destino se hayan configurado en SnapCenter antes de iniciar el flujo de trabajo de clonado. De lo contrario, el nuevo recurso creado por SnapCenter no admitirá la detección automática y los flujos de trabajo descritos no funcionarán.

En una configuración de SAN Fibre Channel, no se requiere una dirección IP de exportación, pero debe proporcionar el protocolo utilizado en la siguiente pantalla.

Las capturas de pantalla muestran una configuración de laboratorio diferente mediante una conectividad FibreChannel.

Con Azure NetApp Files y un pool de capacidad de calidad de servicio manual, debe proporcionar el rendimiento máximo del volumen nuevo. Asegúrese de que el pool de capacidad tenga suficiente espacio adicional; de lo contrario, se producirá un error en el flujo de trabajo de clonado.

Las capturas de pantalla muestran una configuración de laboratorio diferente que se ejecuta en Microsoft Azure con Azure NetApp Files.

Introduzca los scripts posteriores a la clonado opcionales con las opciones de línea de comandos requeridas. Con nuestro ejemplo utilizamos un script posterior a la clonado para ejecutar la recuperación de la base de datos SAP HANA.

Como se explicó anteriormente, el uso del script de recuperación es opcional. La recuperación también puede realizarse manualmente después de que finaliza el flujo de trabajo de clonación de SnapCenter.

El script para la operación de recuperación recupera la base de datos SAP HANA al momento específico de Snapshot mediante la operación Clear logs y no ejecuta ninguna recuperación futura. Si se requiere una recuperación futura a un momento específico, la recuperación debe realizarse manualmente. La recuperación manual de reenvío también requiere que los backups de registros del sistema de origen estén disponibles en el host de destino.

La pantalla Detalles del trabajo en SnapCenter muestra el progreso de la operación. Los detalles de la tarea también muestran que el tiempo de ejecución general, incluida la recuperación de la base de datos, fue inferior a 3 minutos.

El archivo log del sc-system-refresh script muestra los diferentes pasos que se ejecutaron para la operación de recuperación. El script lee la lista de inquilinos de la base de datos del sistema y ejecuta una recuperación de todos los inquilinos existentes.

20240425112328###hana-7###sc-system-refresh.sh: Script version: 3.0
hana-7:/mnt/sapcc-share/SAP-System-Refresh # cat sap-system-refresh-QS1.log
20240425112328###hana-7###sc-system-refresh.sh: ******************* Starting script: recovery operation **************************
20240425112328###hana-7###sc-system-refresh.sh: Recover system database.
20240425112328###hana-7###sc-system-refresh.sh: /usr/sap/QS1/HDB11/exe/Python/bin/python /usr/sap/QS1/HDB11/exe/python_support/recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG"
20240425112346###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is started ....
20240425112347###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112357###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112407###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112417###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112428###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112438###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425112448###hana-7###sc-system-refresh.sh: Status: GREEN
20240425112448###hana-7###sc-system-refresh.sh: HANA system database started.
20240425112448###hana-7###sc-system-refresh.sh: Checking connection to system database.
20240425112448###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY 'select * from sys.m_databases;'
DATABASE_NAME,DESCRIPTION,ACTIVE_STATUS,ACTIVE_STATUS_DETAILS,OS_USER,OS_GROUP,RESTART_MODE,FALLBACK_SNAPSHOT_CREATE_TIME
"SYSTEMDB","SystemDB-QS1-11","YES","","","","DEFAULT",?
"QS1","QS1-11","NO","ACTIVE","","","DEFAULT",?
2 rows selected (overall time 16.225 msec; server time 860 usec)
20240425112448###hana-7###sc-system-refresh.sh: Succesfully connected to system database.
20240425112449###hana-7###sc-system-refresh.sh: Tenant databases to recover: QS1
20240425112449###hana-7###sc-system-refresh.sh: Found inactive tenants(QS1) and starting recovery
20240425112449###hana-7###sc-system-refresh.sh: Recover tenant database QS1.
20240425112449###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR QS1 USING SNAPSHOT CLEAR LOG
0 rows affected (overall time 22.138599 sec; server time 22.136268 sec)
20240425112511###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant QS1.
20240425112511###hana-7###sc-system-refresh.sh: Recovery of tenant database QS1 succesfully finished.
20240425112511###hana-7###sc-system-refresh.sh: Status: GREEN
20240425112511###hana-7###sc-system-refresh.sh: ******************* Finished script: recovery operation **************************
hana-7:/mnt/sapcc-share/SAP-System-Refresh

Cuando finalice el trabajo de SnapCenter, el clon se puede ver dentro de la vista de topología del sistema de origen.

La base de datos SAP HANA se está ejecutando.
Si desea proteger el sistema SAP HANA de destino, debe ejecutar la detección automática haciendo clic en el recurso del sistema de destino.

Cuando finaliza el proceso de detección automática, el nuevo volumen clonado aparece en la sección huella de almacenamiento.

Al volver a hacer clic en el recurso, la protección de datos se puede configurar para el sistema QS1 actualizado.

Clonado desde almacenamiento de backup externo

En esta sección se describe el flujo de trabajo de actualización del sistema SAP HANA para el que el nombre del inquilino en el sistema de origen y de destino es idéntico al SID. La clonación de almacenamiento se ejecuta en el almacenamiento de backup externo y se automatiza aún más mediante el script sc-system-refresh.sh.

La única diferencia en el flujo de trabajo de actualización del sistema SAP HANA entre el clonado del almacenamiento de backup primario y externo es la selección del backup Snapshot en SnapCenter. Para la clonado de almacenamiento de backup fuera de las instalaciones, se deben seleccionar primero los backups secundarios, seguidos por la selección del backup de Snapshot.

Si existen varias ubicaciones de almacenamiento secundario para el backup seleccionado, debe elegir el volumen de destino requerido.

Todos los pasos siguientes son idénticos al flujo de trabajo para clonar desde el almacenamiento primario.

Clonar un sistema SAP HANA con varios inquilinos

En esta sección se describe el flujo de trabajo de actualización del sistema SAP HANA con varios inquilinos. La clonación de almacenamiento se ejecuta en el almacenamiento primario y se automatiza aún más mediante el script sc-system-refresh.sh.

Los pasos requeridos en SnapCenter son idénticos a los descritos en la sección «Clonación desde almacenamiento principal con un nombre de inquilino igual a SID». La única diferencia está en la operación de recuperación de arrendatarios dentro del script sc-system-refresh.sh, donde se recuperan todos los arrendatarios.

20240430070214###hana-7###sc-system-refresh.sh: **********************************************************************************
20240430070214###hana-7###sc-system-refresh.sh: Script version: 3.0
20240430070214###hana-7###sc-system-refresh.sh: ******************* Starting script: recovery operation **************************
20240430070214###hana-7###sc-system-refresh.sh: Recover system database.
20240430070214###hana-7###sc-system-refresh.sh: /usr/sap/QS1/HDB11/exe/Python/bin/python /usr/sap/QS1/HDB11/exe/python_support/recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG"
[140310725887808, 0.008] >> starting recoverSys (at Tue Apr 30 07:02:15 2024)
[140310725887808, 0.008] args: ()
[140310725887808, 0.008] keys: \{'command': 'RECOVER DATA USING SNAPSHOT CLEAR LOG'}
using logfile /usr/sap/QS1/HDB11/hana-7/trace/backup.log
recoverSys started: ============2024-04-30 07:02:15 ============
testing master: hana-7
hana-7 is master
shutdown database, timeout is 120
stop system
stop system on: hana-7
stopping system: 2024-04-30 07:02:15
stopped system: 2024-04-30 07:02:15
creating file recoverInstance.sql
restart database
restart master nameserver: 2024-04-30 07:02:20
start system: hana-7
sapcontrol parameter: ['-function', 'Start']
sapcontrol returned successfully:
2024-04-30T07:02:32-04:00 P0023828 18f2eab9331 INFO RECOVERY RECOVER DATA finished successfully
recoverSys finished successfully: 2024-04-30 07:02:33
[140310725887808, 17.548] 0
[140310725887808, 17.548] << ending recoverSys, rc = 0 (RC_TEST_OK), after 17.540 secs
20240430070233###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is started ....
20240430070233###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070243###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070253###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070304###hana-7###sc-system-refresh.sh: Status: GRAY
20240430070314###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070314###hana-7###sc-system-refresh.sh: HANA system database started.
20240430070314###hana-7###sc-system-refresh.sh: Checking connection to system database.
20240430070314###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY 'select * from sys.m_databases;'
20240430070314###hana-7###sc-system-refresh.sh: Succesfully connected to system database.
20240430070314###hana-7###sc-system-refresh.sh: Tenant databases to recover: TENANT2
TENANT1
20240430070314###hana-7###sc-system-refresh.sh: Found inactive tenants(TENANT2
TENANT1) and starting recovery
20240430070314###hana-7###sc-system-refresh.sh: Recover tenant database TENANT2.
20240430070314###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR TENANT2 USING SNAPSHOT CLEAR LOG
20240430070335###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant TENANT2.
20240430070335###hana-7###sc-system-refresh.sh: Recovery of tenant database TENANT2 succesfully finished.
20240430070335###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070335###hana-7###sc-system-refresh.sh: Recover tenant database TENANT1.
20240430070335###hana-7###sc-system-refresh.sh: /usr/sap/QS1/SYS/exe/hdb/hdbsql -U QS1KEY RECOVER DATA FOR TENANT1 USING SNAPSHOT CLEAR LOG
20240430070349###hana-7###sc-system-refresh.sh: Checking availability of Indexserver for tenant TENANT1.
20240430070350###hana-7###sc-system-refresh.sh: Recovery of tenant database TENANT1 succesfully finished.
20240430070350###hana-7###sc-system-refresh.sh: Status: GREEN
20240430070350###hana-7###sc-system-refresh.sh: ******************* Finished script: recovery operation **************************

Operación de eliminación de clones

Se inicia una nueva operación de actualización del sistema SAP HANA mediante la limpieza del sistema de destino mediante la operación de eliminación de clones de SnapCenter.

Si el sistema SAP HANA de destino se protegió en SnapCenter, primero se debe quitar la protección. En la vista de topología del sistema de destino, haga clic en Remove Protection.

El flujo de trabajo de eliminación de clones ahora se ejecuta con los siguientes pasos.

Seleccione el clon dentro de la vista de topología del sistema de origen y haga clic en Eliminar.

Introduzca los scripts de clonado previo y desmontaje con las opciones de línea de comandos requeridas.

La pantalla de detalles del trabajo en SnapCenter muestra el progreso de la operación.

El archivo de registro sc-system-refresh del script muestra los pasos de las operaciones de apagado y desmontaje.

20240425111042###hana-7###sc-system-refresh.sh: **********************************************************************************
20240425111042###hana-7###sc-system-refresh.sh: Script version: 3.0
20240425111042###hana-7###sc-system-refresh.sh: ******************* Starting script: shutdown operation **************************
20240425111042###hana-7###sc-system-refresh.sh: Stopping HANA database.
20240425111042###hana-7###sc-system-refresh.sh: sapcontrol -nr 11 -function StopSystem HDB
25.04.2024 11:10:42
StopSystem
OK
20240425111042###hana-7###sc-system-refresh.sh: Wait until SAP HANA database is stopped ....
20240425111042###hana-7###sc-system-refresh.sh: Status: GREEN
20240425111052###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111103###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111113###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111123###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111133###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111144###hana-7###sc-system-refresh.sh: Status: YELLOW
20240425111154###hana-7###sc-system-refresh.sh: Status: GRAY
20240425111154###hana-7###sc-system-refresh.sh: SAP HANA database is stopped.
20240425111154###hana-7###sc-system-refresh.sh: ******************* Finished script: shutdown operation **************************

La operación de actualización de SAP HANA ahora puede iniciarse de nuevo mediante la operación de creación de clones de SnapCenter.

Actualización del sistema SAP HANA con operación de división de clones

Si el sistema de destino de la operación de actualización del sistema está planificado para utilizarlo durante un período de tiempo más largo, tiene sentido dividir el volumen de FlexClone como parte de la operación de actualización del sistema.

La operación de división de clones no bloquea el uso del volumen clonado y, por tanto, se puede ejecutar en cualquier momento mientras la base de datos SAP HANA está en uso.

Con Azure NetApp Files, la operación de división de clones no está disponible, ya que Azure NetApp Files siempre divide el clon una vez creado.

El flujo de trabajo de división de clones en SnapCenter se inicia en la vista de topología del sistema de origen seleccionando el clon y haciendo clic en la división de clones.

En la siguiente pantalla se muestra una vista previa que proporciona información sobre la capacidad necesaria para el volumen dividido.

El registro de trabajos de SnapCenter muestra el progreso de la operación de división de clones.

En la vista de recursos de SnapCenter, el sistema de destino QS1 ahora ya no está marcado como un recurso clonado. Al volver a la vista de topología del sistema de origen, el clon ya no queda visible. El volumen dividido ahora es independiente del backup de snapshot del sistema de origen.

El flujo de trabajo de actualización después de una operación de división de clones tiene un aspecto ligeramente diferente a la operación sin división de clones. Tras una operación de división de clones, no se requiere ninguna operación de eliminación de clones, ya que el volumen de datos de destino ya no es un volumen FlexClone.

El flujo de trabajo consta de los siguientes pasos:

Si el sistema SAP HANA de destino se protegió en SnapCenter, primero se debe quitar la protección.
Debe apagarse la base de datos SAP HANA, el volumen de datos debe desmontarse y se debe quitar la entrada fstab creada por SnapCenter. Estos pasos deben ejecutarse manualmente.
Ahora, el flujo de trabajo de creación del clon SnapCenter puede ejecutarse como se describe en las secciones anteriores.
Después de la operación de actualización, el volumen de datos de destino antiguo todavía existe y debe eliminarse manualmente con, por ejemplo, ONTAP System Manager.

Automatización del flujo de trabajo de SnapCenter con scripts de PowerShell

En las secciones anteriores, se ejecutaron los diferentes flujos de trabajo utilizando la interfaz de usuario de SnapCenter. Todos los flujos de trabajo también pueden ejecutarse con scripts de PowerShell o llamadas a la API DE REST, lo que permite una mayor automatización. Las siguientes secciones describen ejemplos básicos de scripts de PowerShell para los siguientes flujos de trabajo.

Crear clon
Eliminar clon

Los scripts de ejemplo se proporcionan tal cual y no son compatibles con NetApp.

Todos los scripts deben ejecutarse en una ventana de comandos de PowerShell. Para poder ejecutar los scripts, se debe establecer una conexión con el servidor SnapCenter mediante Open-SmConnection comando.

Crear clon

El sencillo script que se muestra a continuación muestra cómo puede ejecutarse una operación de creación de clones de SnapCenter con comandos de PowerShell. La SnapCenter New-SmClone el comando se ejecuta con la opción de línea de comandos necesaria para el entorno de laboratorio y la secuencia de comandos de automatización que se ha tratado anteriormente.

$BackupName='SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458'
$JobInfo=New-SmClone -AppPluginCode hana -BackupName $BackupName -Resources @\{"Host"="hana-1.sapcc.stl.netapp.com";"UID"="MDC\SS1"} -CloneToInstance hana-7.sapcc.stl.netapp.com -postclonecreatecommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh recover' -NFSExportIPs 192.168.175.75 -CloneUid 'MDC\QS1'
# Get JobID of clone create job
$Job=Get-SmJobSummaryReport | ?\{$_.JobType -eq "Clone" } | ?\{$_.JobName -Match $BackupName} | ?\{$_.Status -eq "Running"}
$JobId=$Job.SmJobId
Get-SmJobSummaryReport -JobId $JobId
# Wait until job is finished
do \{ $Job=Get-SmJobSummaryReport -JobId $JobId; write-host $Job.Status; sleep 20 } while ( $Job.Status -Match "Running" )
Write-Host " "
Get-SmJobSummaryReport -JobId $JobId
Write-Host "Clone create job has been finshed."

El resultado de la pantalla muestra la ejecución del script clone create PowerShell.

PS C:\Windows\system32> C:\NetApp\clone-create.ps1
SmJobId : 110382
JobCreatedDateTime :
JobStartDateTime : 6/26/2024 9:55:34 AM
JobEndDateTime :
JobDuration :
JobName : Clone from backup 'SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458'
JobDescription :
Status : Running
IsScheduled : False
JobError :
JobType : Clone
PolicyName :
JobResultData :
Running
Running
Running
Running
Running
Running
Running
Running
Running
Running
Completed
SmJobId : 110382
JobCreatedDateTime :
JobStartDateTime : 6/26/2024 9:55:34 AM
JobEndDateTime : 6/26/2024 9:58:50 AM
JobDuration : 00:03:16.6889170
JobName : Clone from backup 'SnapCenter_hana-1_LocalSnap_Hourly_06-25-2024_03.00.01.8458'
JobDescription :
Status : Completed
IsScheduled : False
JobError :
JobType : Clone
PolicyName :
JobResultData :
Clone create job has been finshed.

Eliminar clon

El sencillo script que se muestra a continuación muestra cómo puede ejecutarse una operación de eliminación de clones de SnapCenter con comandos de PowerShell. La SnapCenter Remove-SmClone el comando se ejecuta con la opción de línea de comandos necesaria para el entorno de laboratorio y la secuencia de comandos de automatización que se ha tratado anteriormente.

$CloneInfo=Get-SmClone |?\{$_.CloneName -Match "hana-1_sapcc_stl_netapp_com_hana_MDC_SS1" }
$JobInfo=Remove-SmClone -CloneName $CloneInfo.CloneName -PluginCode hana -PreCloneDeleteCommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh shutdown QS1' -UnmountCommands '/mnt/sapcc-share/SAP-System-Refresh/sc-system-refresh.sh umount QS1' -Confirm: $False
Get-SmJobSummaryReport -JobId $JobInfo.Id
# Wait until job is finished
do \{ $Job=Get-SmJobSummaryReport -JobId $JobInfo.Id; write-host $Job.Status; sleep 20 } while ( $Job.Status -Match "Running" )
Write-Host " "
Get-SmJobSummaryReport -JobId $JobInfo.Id
Write-Host "Clone delete job has been finshed."
PS C:\NetApp>

El resultado de la pantalla muestra la ejecución del script de PowerShell clone –delete.ps1.

PS C:\Windows\system32> C:\NetApp\clone-delete.ps1
SmJobId : 110386
JobCreatedDateTime :
JobStartDateTime : 6/26/2024 10:01:33 AM
JobEndDateTime :
JobDuration :
JobName : Deleting clone 'hana-1_sapcc_stl_netapp_com_hana_MDC_SS1__clone__110382_MDC_SS1_04-22-2024_09.54.34'
JobDescription :
Status : Running
IsScheduled : False
JobError :
JobType : DeleteClone
PolicyName :
JobResultData :
Running
Running
Running
Running
Completed
SmJobId : 110386
JobCreatedDateTime :
JobStartDateTime : 6/26/2024 10:01:33 AM
JobEndDateTime : 6/26/2024 10:02:38 AM
JobDuration : 00:01:05.5658860
JobName : Deleting clone 'hana-1_sapcc_stl_netapp_com_hana_MDC_SS1__clone__110382_MDC_SS1_04-22-2024_09.54.34'
JobDescription :
Status : Completed
IsScheduled : False
JobError :
JobType : DeleteClone
PolicyName :
JobResultData :
Clone delete job has been finshed.
PS C:\Windows\system32>