Clon del sistema SAP con SnapCenter
Colaboradores
Esta sección proporciona una descripción paso a paso de la operación de clonado del sistema SAP, que puede utilizarse para configurar un sistema de reparación para solucionar daños lógicos.
|
La configuración y validación del laboratorio no incluye servicios de aplicaciones SAP. No obstante, los pasos necesarios para los servicios de aplicaciones SAP se resaltan en la documentación. |
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 HANA y la configuración de SnapCenter.
-
El flujo de trabajo descrito es válido para sistemas SAP HANA MDC de un solo host con un solo inquilino.
-
El complemento SnapCenter HANA se debe poner en marcha en el host de destino para permitir la ejecución de scripts de automatización. No es necesario instalar el plugin de HANA en el host del sistema de origen HANA.
-
El flujo de trabajo se ha validado para NFS. El script de automatización
sc-mount-volume.sh
, Que se utiliza para montar el volumen compartido de HANA, no admite FCP. Este paso debe realizarse manualmente o mediante la ampliación del script. -
El flujo de trabajo descrito solo es válido para la versión P1 de SnapCenter 4.6 o posterior. Las versiones anteriores tienen flujos de trabajo ligeramente diferentes.
Configuración de laboratorio
La siguiente figura muestra la configuración de laboratorio utilizada para una operación de clonación del sistema.
Se utilizaron las siguientes versiones de software:
-
SnapCenter 4. 6 P1
-
SISTEMAS HANA: HANA 2.0 SPS6 rev.61
-
VMware 6.7.0
-
SLES 15 SP2
-
ONTAP 9.7P7todos los sistemas HANA se configuraron de acuerdo con la guía de configuración "SAP HANA en sistemas AFF de NetApp con NFS". SnapCenter y los recursos de HANA se configuraron de acuerdo con la guía de prácticas recomendadas "Backup y recuperación de datos de SAP HANA con SnapCenter".
Preparación de host de destino
En esta sección se describen los pasos de preparación necesarios en un servidor que se usa como destino de clon del sistema.
Durante el funcionamiento normal, el host objetivo puede utilizarse para otros fines, por ejemplo, como un sistema de garantía de calidad o prueba de HANA. Por lo tanto, la mayoría de los pasos descritos deben ejecutarse cuando se solicita la operación de clonado del sistema. Por otro lado, los archivos de configuración pertinentes, como /etc/fstab
y.. /usr/sap/sapservices
, se puede preparar y poner en producción simplemente copiando el archivo de configuración.
La preparación del host de destino también incluye apagar el sistema de prueba o garantía de calidad de HANA.
El nombre de host y la dirección IP del servidor de destino
El nombre de host del servidor de destino debe ser idéntico al nombre de host del sistema de origen. La dirección IP puede ser diferente.
|
Se debe establecer una correcta delimitación del servidor de destino para que no pueda comunicarse con otros sistemas. Si no se dispone de una cercado adecuada, el sistema de producción clonado puede intercambiar datos con otros sistemas de producción. |
|
En nuestra configuración de laboratorio, hemos cambiado el nombre de host del sistema de destino sólo internamente desde la perspectiva del sistema de destino. Externamente, se pudo acceder al host con el nombre de host hana-7. Cuando se inicia sesión en el host, el propio host es hana-1. |
Instale el software necesario
El software del agente de host SAP debe instalarse en el servidor de destino. Para obtener toda la información, consulte "Agente host SAP" En el portal de ayuda de SAP.
El plugin de SnapCenter HANA se debe poner en marcha en el host de destino mediante la operación de añadir host dentro de SnapCenter.
Configurar usuarios, puertos y servicios SAP
Los usuarios y los grupos requeridos para la base de datos SAP HANA deben estar disponibles en el servidor de destino. Normalmente, se utiliza la gestión central de usuarios; por lo tanto, no es necesario realizar ningún paso de configuración en el servidor de destino. Los puertos necesarios para la base de datos HANA deben configurarse en los hosts objetivo. La configuración se puede copiar desde el sistema de origen copiando el /etc/services
archivo al servidor de destino.
Las entradas de servicios SAP necesarias deben estar disponibles en el host de destino. La configuración se puede copiar desde el sistema de origen copiando el /usr/sap/sapservices
archivo al servidor de destino. El siguiente resultado muestra las entradas necesarias para la base de datos SAP HANA que se utilizan en la configuración de laboratorio.
#!/bin/sh LD_LIBRARY_PATH=/usr/sap/SS1/HDB00/exe:$LD_LIBRARY_PATH;export LD_LIBRARY_PATH;/usr/sap/SS1/HDB00/exe/sapstartsrv pf=/usr/sap/SS1/SYS/profile/SS1_HDB00_hana-1 -D -u ss1adm limit.descriptors=1048576
Preparar el volumen de backup de registros y registros
Debido a que no es necesario clonar el volumen de registro del sistema de origen y se realiza cualquier recuperación con la opción Clear log, se debe preparar un volumen de registro vacío en el host objetivo.
Dado que el sistema de origen se configuró con un volumen de backup de registros independiente, se debe preparar y montar un volumen de backup de registros vacío en el mismo punto de montaje que en el sistema de origen.
hana- 1:/# cat /etc/fstab 192.168.175.117:/SS1_repair_log_mnt00001 /hana/log/SS1/mnt00001 nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0 192.168.175.117:/SS1_repair_log_backup /mnt/log-backup nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0
Dentro del volumen de registro hdb*, debe crear subdirectorios de la misma forma que en el sistema de origen.
hana- 1:/ # ls -al /hana/log/SS1/mnt00001/ total 16 drwxrwxrwx 5 root root 4096 Dec 1 06:15 . drwxrwxrwx 1 root root 16 Nov 30 08:56 .. drwxr-xr-- 2 ss1adm sapsys 4096 Dec 1 06:14 hdb00001 drwxr-xr-- 2 ss1adm sapsys 4096 Dec 1 06:15 hdb00002.00003 drwxr-xr-- 2 ss1adm sapsys 4096 Dec 1 06:15 hdb00003.00003
En el volumen de copia de seguridad de registro, se deben crear subdirectorios para el sistema y la base de datos de tenant.
hana- 1:/ # ls -al /mnt/log-backup/ total 12 drwxr-xr-x 4 root root 4096 Dec 1 04:48 . drwxr-xr-x 1 root root 48 Dec 1 03:42 .. drwxrwxrwx 2 root root 4096 Dec 1 06:15 DB_SS1 drwxrwxrwx 2 root root 4096 Dec 1 06:14 SYSTEMDB
Preparar los montajes del sistema de archivos
Debe preparar puntos de montaje para los datos y el volumen compartido.
Con nuestro ejemplo, los directorios /hana/data/SS1/mnt00001
, /hana/shared
y.. usr/sap/SS1
debe crearse.
Preparar el archivo de configuración específico de SID para el script de SnapCenter
Debe crear el archivo de configuración para el script de automatización de SnapCenter sc-system-refresh.sh
.
hana- 1:/mnt/sapcc-share/SAP-System-Refresh # cat sc-system-refresh-SS1.cfg # --------------------------------------------- # Target database specific parameters # --------------------------------------------- # hdbuserstore key, which should be used to connect to the target database KEY="SS1KEY" # Used storage protocol, NFS or FCP PROTOCOL
Clonado del volumen compartido de HANA
-
Seleccione un backup de Snapshot en el volumen compartido SS1 del sistema de origen y haga clic en Clone from Backup.
-
Seleccione el host donde se ha preparado el sistema de reparación de destino. La dirección IP de exportación de NFS debe ser la interfaz de red de almacenamiento del host de destino. Como SID de destino, mantenga el mismo SID que el sistema de origen; en nuestro ejemplo, esto es SS1.
-
Escriba el script de montaje con las opciones de línea de comandos requeridas.
El sistema HANA utiliza un único volumen para /hana/shared `as well as for `/usr/sap/SS1
, separado en subdirectorios como se recomienda en la guía de configuración "SAP HANA en sistemas AFF de NetApp con NFS". El scriptsc-mount-volume.sh
admite esta configuración mediante una opción de línea de comandos especial para la ruta de montaje. Si la opción de línea de comandos de ruta de montaje es igual a.usr-sap-and-shared
, la secuencia de comandos monta los subdirectoriosshared
y..usr-sap
en el volumen correspondiente. -
La pantalla de detalles del trabajo en SnapCenter muestra el progreso de la operación.
-
El archivo de registro de
sc- mount-volume.sh
la secuencia de comandos muestra los diferentes pasos ejecutados para la operación de montaje.20201201041441###hana-1###sc-mount-volume.sh: Adding entry in /etc/fstab. 20201201041441###hana-1###sc-mount-volume.sh: 192.168.175.117://SS1_shared_Clone_05132205140448713/usr-sap /usr/sap/SS1 nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0 20201201041441###hana-1###sc-mount-volume.sh: Mounting volume: mount /usr/sap/SS1. 20201201041441###hana-1###sc-mount-volume.sh: 192.168.175.117: /SS1_shared_Clone_05132205140448713/shared /hana/shared nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0 20201201041441###hana-1###sc-mount-volume.sh: Mounting volume: mount /hana/shared. 20201201041441###hana-1###sc-mount-volume.sh: usr-sap-and-shared mounted successfully. 20201201041441###hana-1###sc-mount-volume.sh: Change ownership to ss1adm.
-
Cuando finalice el flujo de trabajo de SnapCenter, el
usr/sap/SS1
y la/hana/shared
los sistemas de archivos se montan en el host de destino.hana-1:~ # df Filesystem 1K-blocks Used Available Use% Mounted on 192.168.175.117:/SS1_repair_log_mnt00001 262144000 320 262143680 1% /hana/log/SS1/mnt00001 192.168.175.100:/sapcc_share 1020055552 53485568 966569984 6% /mnt/sapcc-share 192.168.175.117:/SS1_repair_log_backup 104857600 256 104857344 1% /mnt/log-backup 192.168.175.117: /SS1_shared_Clone_05132205140448713/usr-sap 262144064 10084608 252059456 4% /usr/sap/SS1 192.168.175.117: /SS1_shared_Clone_05132205140448713/shared 262144064 10084608 252059456 4% /hana/shared
-
En SnapCenter, se puede ver un nuevo recurso para el volumen clonado.
-
Ahora que la
/hana/shared
El volumen está disponible, se pueden iniciar los servicios SAP HANA.hana-1:/mnt/sapcc-share/SAP-System-Refresh # systemctl start sapinit
-
Los procesos SAP Host Agent y sapstartsrv se inician ahora.
hana-1:/mnt/sapcc-share/SAP-System-Refresh # ps -ef |grep sap root 12377 1 0 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile sapadm 12403 1 0 04:34 ? 00:00:00 /usr/lib/systemd/systemd --user sapadm 12404 12403 0 04:34 ? 00:00:00 (sd-pam) sapadm 12434 1 1 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/sapstartsrv pf=/usr/sap/hostctrl/exe/host_profile -D root 12485 12377 0 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/saphostexec pf=/usr/sap/hostctrl/exe/host_profile root 12486 12485 0 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile ss1adm 12504 1 0 04:34 ? 00:00:00 /usr/sap/SS1/HDB00/exe/sapstartsrv pf=/usr/sap/SS1/SYS/profile/SS1_HDB00_hana-1 -D -u ss1adm root 12582 12486 0 04:34 ? 00:00:00 /usr/sap/hostctrl/exe/saposcol -l -w60 pf=/usr/sap/hostctrl/exe/host_profile root 12585 7613 0 04:34 pts/0 00:00:00 grep --color=auto sap hana-1:/mnt/sapcc-share/SAP-System-Refresh #
Clonado de servicios de aplicaciones SAP adicionales
Los servicios adicionales de aplicaciones SAP se clonan del mismo modo que el volumen compartido SAP HANA, tal y como se describe en la sección “Clonado del volumen compartido de HANA.” Por supuesto, los volúmenes de almacenamiento necesarios de los servidores de aplicaciones SAP también deben protegerse con SnapCenter.
Debe agregar las entradas de servicios requeridos a. /usr/sap/sapservices`y los puertos, usuarios y puntos de montaje del sistema de archivos (por ejemplo, `/usr/sap/SID
) debe estar preparado.
Clonar el volumen de datos y recuperar la base de datos de HANA
-
Seleccione un backup de HANA Snapshot del sistema de origen SS1.
-
Seleccione el host donde se ha preparado el sistema de reparación de destino. La dirección IP de exportación de NFS debe ser la interfaz de red de almacenamiento del host de destino. Un SID de destino mantiene el mismo SID que el sistema de origen; en nuestro ejemplo, es SS1.
-
Escriba los scripts de montaje y posteriores a la clonado con las opciones de línea de comandos requeridas.
El script para la operación de recuperación recupera la base de datos de HANA hasta el momento específico de la operación de Snapshot y no ejecuta ninguna recuperación de reenvío. 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 de detalles del trabajo en SnapCenter muestra el progreso de la operación.
El archivo de registro de sc-system-refresh.sh
el script muestra los diferentes pasos que se ejecutan para la operación de montaje y recuperación.
20201201052114###hana-1###sc-system-refresh.sh: Adding entry in /etc/fstab. 20201201052114###hana-1###sc-system-refresh.sh: 192.168.175.117:/SS1_data_mnt00001_Clone_0421220520054605 /hana/data/SS1/mnt00001 nfs rw,vers=3,hard,timeo=600,rsize=1048576,wsize=1048576,intr,noatime,nolock 0 0 20201201052114###hana-1###sc-system-refresh.sh: Mounting data volume: mount /hana/data/SS1/mnt00001. 20201201052114###hana-1###sc-system-refresh.sh: Data volume mounted successfully. 20201201052114###hana-1###sc-system-refresh.sh: Change ownership to ss1adm. 20201201052124###hana-1###sc-system-refresh.sh: Recover system database. 20201201052124###hana-1###sc-system-refresh.sh: /usr/sap/SS1/HDB00/exe/Python/bin/python /usr/sap/SS1/HDB00/exe/python_support/recoverSys.py --command "RECOVER DATA USING SNAPSHOT CLEAR LOG" 20201201052156###hana-1###sc-system-refresh.sh: Wait until SAP HANA database is started .... 20201201052156###hana-1###sc-system-refresh.sh: Status: GRAY 20201201052206###hana-1###sc-system-refresh.sh: Status: GREEN 20201201052206###hana-1###sc-system-refresh.sh: SAP HANA database is started. 20201201052206###hana-1###sc-system-refresh.sh: Source system has a single tenant and tenant name is identical to source SID: SS1 20201201052206###hana-1###sc-system-refresh.sh: Target tenant will have the same name as target SID: SS1. 20201201052206###hana-1###sc-system-refresh.sh: Recover tenant database SS1. 20201201052206###hana-1###sc-system-refresh.sh: /usr/sap/SS1/SYS/exe/hdb/hdbsql -U SS1KEY RECOVER DATA FOR SS1 USING SNAPSHOT CLEAR LOG 0 rows affected (overall time 34.773885 sec; server time 34.772398 sec) 20201201052241###hana-1###sc-system-refresh.sh: Checking availability of Indexserver for tenant SS1. 20201201052241###hana-1###sc-system-refresh.sh: Recovery of tenant database SS1 succesfully finished. 20201201052241###hana-1###sc-system-refresh.sh: Status: GREEN
Después de la operación de montaje y recuperación, el volumen de datos del HANA se monta en el host de destino.
hana-1:/mnt/log-backup # df Filesystem 1K-blocks Used Available Use% Mounted on 192.168.175.117:/SS1_repair_log_mnt00001 262144000 760320 261383680 1% /hana/log/SS1/mnt00001 192.168.175.100:/sapcc_share 1020055552 53486592 966568960 6% /mnt/sapcc-share 192.168.175.117:/SS1_repair_log_backup 104857600 512 104857088 1% /mnt/log-backup 192.168.175.117: /SS1_shared_Clone_05132205140448713/usr-sap 262144064 10090496 252053568 4% /usr/sap/SS1 192.168.175.117: /SS1_shared_Clone_05132205140448713/shared 262144064 10090496 252053568 4% /hana/shared 192.168.175.117:/SS1_data_mnt00001_Clone_0421220520054605 262144064 3732864 258411200 2% /hana/data/SS1/mnt00001
El sistema HANA ahora está disponible y se puede utilizar, por ejemplo, como un sistema de reparación.