Best Practice
Aggiornamento del sistema SAP HANA con SnapCenter
Suggerisci modifiche
PDF
La sezione seguente fornisce una descrizione dettagliata delle diverse opzioni di aggiornamento del sistema di un database SAP HANA.
A seconda della configurazione del database di SAP HANA, vengono eseguiti o devono essere preparati altri passaggi. La tabella riportata di seguito fornisce un riepilogo.
| Sistema di origine | Configurazione del sistema di origine | Operazioni SnapCenter e SAP HANA |
|---|---|---|
MDC single tenant + SID = nome del tenant |
Configurazione standard |
Operazione di cloning SnapCenter ed esecuzione opzionale dello script di recovery. |
Crittografia di persistenza di SAP HANA |
Inizialmente, o se le chiavi principali sono state modificate nel sistema di origine, i backup delle chiavi principali devono essere importati nel sistema di destinazione prima di poter eseguire il ripristino. |
|
Origine replica sistema SAP HANA |
Non sono necessari passaggi aggiuntivi. Se il sistema di destinazione non ha HSR configurato, rimarrà un sistema autonomo. |
|
Partizioni multiple SAP HANA |
Non è necessario alcun passaggio aggiuntivo, ma i punti di montaggio per le partizioni di volume SAP HANA devono essere disponibili nel sistema di destinazione con la stessa convenzione di denominazione (solo SID è diverso). |
|
Tenant multipli MDC O MDC single tenant + con SID <> nome tenant |
Configurazione standard |
Operazione di cloning SnapCenter ed esecuzione opzionale dello script di recovery. Script recupera tutti i tenant. Se i nomi dei tenant o dei tenant non esistono nei nomi del sistema di destinazione, le directory richieste verranno create automaticamente durante l'operazione di recovery di SAP HANA. I nomi dei tenant saranno gli stessi dell'origine e, se necessario, dovranno essere rinominati dopo il ripristino. |
Crittografia di persistenza di SAP HANA |
Se un DBID del sistema di origine non esiste in precedenza nel sistema di destinazione, è necessario prima ripristinare il database di sistema, prima di poter importare il backup della chiave root di questo tenant. |
|
Origine replica sistema HANA |
Non sono necessari passaggi aggiuntivi. Se il sistema di destinazione non ha HSR configurato, rimarrà un sistema autonomo. |
|
Partizioni multiple HANA |
Non è necessario alcun passaggio aggiuntivo, ma i punti di montaggio per le partizioni di volume SAP HANA devono essere disponibili nel sistema di destinazione con la stessa convenzione di denominazione (solo SID è diverso). |
In questa sezione vengono descritti i seguenti scenari.
-
Aggiornamento del sistema SAP HANA senza un'operazione di suddivisione dei cloni.
-
Clonazione dallo storage primario con nome tenant uguale al SID
-
Clonazione dallo storage per il backup off-site
-
Cloning da storage primario con tenant multipli
-
Operazione di eliminazione dei cloni
-
Aggiornamento del sistema SAP HANA con un'operazione di suddivisione dei cloni
-
Clonazione dallo storage primario con nome tenant uguale al SID
-
Operazione di suddivisione dei cloni
Prerequisiti e limitazioni
I flussi di lavoro descritti nelle sezioni seguenti presentano alcuni prerequisiti e limitazioni relativi all'architettura di sistema SAP HANA e alla configurazione SnapCenter.
-
I flussi di lavoro descritti sono validi solo per SnapCenter versione 5,0 o superiore.
-
I flussi di lavoro descritti sono validi per sistemi SAP HANA MDC a host singolo con tenant singoli o multipli. I sistemi host multipli SAP HANA non sono coperti.
-
Il plug-in SAP HANA di SnapCenter deve essere implementato sull'host di destinazione per consentire il rilevamento automatico di SnapCenter e l'esecuzione degli script di automazione.
-
I flussi di lavoro sono validi per i sistemi SAP HANA che utilizzano NFS o FCP su host fisici o per host virtuali utilizzando i mount NFS in-guest.
Setup di laboratorio
La figura riportata di seguito mostra la configurazione di laboratorio utilizzata per le diverse opzioni di aggiornamento del sistema.
-
Clonazione da storage primario o storage di backup off-site; il nome del tenant è uguale al SID.
-
Sistema SAP HANA di origine: SS1 con tenant SS1
-
Sistema SAP HANA di destinazione: QS1 con tenant QS1
-
-
Cloning da storage primario; tenant multipli.
-
Sistema SAP HANA di origine: SM1 con Tenant1 e Tenant2
-
Sistema SAP HANA di destinazione: QS1 con Tenant1 e Tenant2
-
Sono state utilizzate le seguenti versioni software:
-
SnapCenter 5,0
-
Sistemi SAP HANA: HANA 2,0 SPS7 rev,73
-
SLES 15
-
ONTAP 9.14P1
Tutti i sistemi SAP HANA devono essere configurati in base alla guida alla configurazione "SAP HANA su sistemi NetApp AFF con NFS". SnapCenter e le risorse SAP HANA sono state configurate in base alla guida alle Best practice "Backup e ripristino SAP HANA con SnapCenter".
Fasi iniziali di preparazione una tantum
Come passaggio iniziale, è necessario configurare il sistema SAP HANA di destinazione all'interno di SnapCenter.
-
Installazione del sistema di destinazione SAP HANA
-
Configurazione del sistema SAP HANA in SnapCenter, come descritto in "TR-4614: Backup e ripristino SAP HANA con SnapCenter"
-
Configurazione dell'utente del database SAP HANA per le operazioni di backup SnapCenter questo utente deve essere identico sul sistema di origine e di destinazione.
-
Configurazione della chiave hdbuserstore per il server di base <sid> con l'utente di backup sopra indicato. Se lo script di automazione viene utilizzato per il ripristino, il nome della chiave deve essere <SID> 10
-
Implementazione del plug-in SAP HANA SnapCenter sull'host di destinazione. Il sistema SAP HANA è scoperto automaticamente da SnapCenter.
-
Configurazione della protezione delle risorse di SAP HANA (opzionale)
-
La prima operazione di refresh del sistema SAP dopo l'installazione iniziale viene preparata con i seguenti passaggi:
-
Chiudi il sistema SAP HANA di destinazione
-
Disinstalla volume di dati SAP HANA.
È necessario aggiungere gli script che devono essere eseguiti sul sistema di destinazione al file di configurazione dei comandi consentiti da 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 #
Clonazione dallo storage primario con nome tenant uguale a SID
Questa sezione descrive il workflow di refresh del sistema SAP HANA, in cui il nome del tenant sul sistema di origine e di destinazione è identico al SID. La clonazione dello storage viene eseguita nello storage primario e il ripristino viene automatizzato con lo script sc-system-refresh.sh.
Il flusso di lavoro è costituito dai seguenti passaggi:
-
Se la crittografia di persistenza SAP HANA è abilitata sul sistema di origine, le chiavi root di crittografia devono essere importate una volta. Un'importazione è necessaria anche se le chiavi sono state modificate nel sistema di origine. Vedere il capitolo ""Considerazioni per le operazioni di refresh del sistema SAP HANA utilizzando i backup delle snapshot di storage""
-
Se il sistema SAP HANA di destinazione è stato protetto in SnapCenter, occorre rimuovere per primo la protezione.
-
Workflow di creazione dei cloni SnapCenter.
-
Seleziona il backup Snapshot dal sistema SAP HANA di origine SS1.
-
Seleziona l'host di destinazione e fornisci un'interfaccia di storage network dell'host di destinazione.
-
Fornire il SID del sistema di destinazione, nell'esempio QS1
-
In alternativa, fornire script per il recovery come operazione post-clone.
-
-
Operazione di cloning SnapCenter.
-
Crea un volume FlexClone in base al backup Snapshot selezionato del sistema SAP HANA di origine.
-
Esporta il volume FlexClone nell'interfaccia o igroup della rete di storage host di destinazione.
-
Esegue l'operazione di montaggio del volume FlexClone di Monts sull'host di destinazione.
-
Esegue lo script di ripristino dell'operazione post-clone, se configurato in precedenza. In caso contrario, il ripristino deve essere eseguito manualmente al termine del flusso di lavoro SnapCenter.
-
Ripristino del database di sistema.
-
Ripristino del database tenant con nome tenant = QS1.
-
-
-
In alternativa, proteggi la risorsa SAP HANA di destinazione in SnapCenter.
Le seguenti schermate mostrano i passaggi necessari.
-
Selezionare un backup Snapshot dal sistema di origine SS1 e fare clic su Clone (Clona).
-
Selezionare l'host in cui è installato il sistema di destinazione QS1. Inserire QS1 come SID di destinazione. L'indirizzo IP di esportazione NFS deve essere l'interfaccia di rete dello storage dell'host di destinazione.
Il SID di destinazione immesso controlla il modo in cui SnapCenter gestisce la risorsa clonata. Se una risorsa con il SID di destinazione è già configurata in SnapCenter e corrisponde all'host del plug-in, SnapCenter assegna semplicemente il clone a questa risorsa. Se il SID non è configurato sull'host di destinazione, SnapCenter crea una nuova risorsa.
Prima di avviare il workflow di cloning, è fondamentale che la risorsa e l'host del sistema di destinazione siano stati configurati in SnapCenter. In caso contrario, la nuova risorsa creata da SnapCenter non supporterà il rilevamento automatico e i flussi di lavoro descritti non funzioneranno.
In una configurazione Fibre Channel SAN non è richiesto alcun indirizzo IP per l'esportazione, ma è necessario fornire il protocollo utilizzato nella schermata successiva.
|
|
Le schermate mostrano una diversa configurazione di laboratorio utilizzando una connettività FibreChannel. |
Grazie a Azure NetApp Files e a un pool di capacità QoS manuale, devi offrire il throughput massimo per il nuovo volume. Assicurati che il pool di capacità abbia spazio sufficiente, altrimenti il workflow di cloning fallirà.
|
|
Le schermate mostrano una diversa configurazione di laboratorio eseguita in Microsoft Azure con Azure NetApp Files. |
-
Immettere gli script post-clone opzionali con le opzioni della riga di comando richieste. Con il nostro esempio utilizziamo uno script post-clone per eseguire il recovery del database SAP HANA.
|
|
Come discusso in precedenza, l'utilizzo dello script di ripristino è facoltativo. Il recovery può essere eseguito anche manualmente al termine del workflow di cloning di SnapCenter. |
|
|
Lo script per l'operazione di recovery recupera il database SAP HANA fino al point-in-time della Snapshot utilizzando l'operazione di clear logs e non esegue alcun recovery in avanti. Se è necessario un ripristino in avanti a un determinato momento, il ripristino deve essere eseguito manualmente. Un forward recovery manuale richiede inoltre che i backup del log dal sistema di origine siano disponibili sull'host di destinazione. |
-
La schermata Dettagli lavoro in SnapCenter mostra lo stato di avanzamento dell'operazione. I dettagli del processo mostrano inoltre che il runtime complessivo, incluso il ripristino del database, è stato inferiore a 3 minuti.
-
Il file di log dello
sc-system-refreshscript mostra le diverse istruzioni eseguite per l'operazione di ripristino. Lo script legge l'elenco dei tenant dal database di sistema ed esegue un ripristino di tutti i tenant esistenti.
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
-
Al termine del lavoro SnapCenter, il clone è visibile nella vista topologia del sistema di origine.
-
Il database SAP HANA è ora in esecuzione.
-
Per proteggere il sistema SAP HANA di destinazione, è necessario eseguire il rilevamento automatico facendo clic sulla risorsa di sistema di destinazione.
Al termine del processo di auto-Discovery, il nuovo volume clonato è elencato nella sezione relativa all'ingombro dello storage.
Facendo nuovamente clic sulla risorsa, è possibile configurare la protezione dei dati per il sistema QS1 aggiornato.
Clonazione dallo storage per il backup off-site
Questa sezione descrive il workflow di refresh del sistema SAP HANA per il quale il nome del tenant sul sistema di origine e di destinazione è identico al SID. La clonazione dello storage viene eseguita nello storage di backup off-site e ulteriormente automatizzata utilizzando lo script sc-system-refresh.sh.
L'unica differenza nel workflow di refresh del sistema SAP HANA tra il cloning dello storage di backup primario e off-site è la selezione del backup Snapshot in SnapCenter. Per il cloning dello storage di backup off-site, occorre selezionare prima i backup secondari, quindi selezionare il backup Snapshot.
Se sono presenti più posizioni di storage secondario per il backup selezionato, è necessario scegliere il volume di destinazione richiesto.
Tutti i passaggi successivi sono identici al flusso di lavoro per il cloning dallo storage primario.
Cloning di un sistema SAP HANA con tenant multipli
Questa sezione descrive il workflow di refresh del sistema SAP HANA con tenant multipli. La clonazione dello storage viene eseguita nello storage primario e ulteriormente automatizzata utilizzando lo script sc-system-refresh.sh.
La procedura necessaria in SnapCenter è identica a quella descritta nella sezione "clonazione dello storage primario con nome tenant uguale a SID". L'unica differenza è nell'operazione di recupero del tenant all'interno dello script sc-system-refresh.sh, dove tutti i tenant vengono recuperati.
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 **************************
Operazione di eliminazione dei cloni
Una nuova operazione di refresh del sistema SAP HANA viene avviata mediante la pulizia del sistema di destinazione mediante l'operazione di eliminazione del clone SnapCenter.
Se il sistema SAP HANA di destinazione è stato protetto in SnapCenter, occorre rimuovere per primo la protezione. Nella vista della topologia del sistema di destinazione, fare clic su Remove Protection (Rimuovi protezione).
Il flusso di lavoro di eliminazione dei cloni viene eseguito mediante la seguente procedura.
-
Selezionare il clone all'interno della vista topologica del sistema di origine e fare clic su Elimina.
-
Immettere gli script pre-clone e dismount con le opzioni della riga di comando richieste.
-
La schermata dei dettagli del lavoro in SnapCenter mostra lo stato di avanzamento dell'operazione.
-
Il file di registro dello
sc-system-refreshscript mostra le istruzioni per l'operazione di arresto e smontaggio.
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 **************************
-
L'operazione di refresh SAP HANA può ora essere riavviata utilizzando l'operazione di creazione del clone SnapCenter.
Aggiornamento del sistema SAP HANA con operazione di suddivisione dei cloni
Se si prevede di utilizzare il sistema di destinazione dell'operazione di refresh del sistema per un periodo di tempo più lungo, conviene suddividere il volume FlexClone nell'ambito dell'operazione di refresh del sistema.
|
|
L'operazione clone split non blocca l'utilizzo del volume clonato e può quindi essere eseguita in qualsiasi momento mentre il database SAP HANA è in uso. |
|
|
Con Azure NetApp Files, l'operazione di clone split non è disponibile, poiché Azure NetApp Files suddivide sempre il clone dopo la creazione. |
Il flusso di lavoro di divisione dei cloni in SnapCenter viene avviato nella vista topologia del sistema di origine selezionando il clone e facendo clic su divisione dei cloni.
Nella schermata successiva viene visualizzata un'anteprima che fornisce informazioni sulla capacità richiesta per il volume suddiviso.
Il log dei lavori di SnapCenter mostra lo stato di avanzamento dell'operazione di suddivisione dei cloni.
Nella vista delle risorse in SnapCenter il sistema target QS1 non è ora più contrassegnato come una risorsa clonata. Quando si torna alla vista della topologia del sistema di origine, il clone non è più visibile. Il volume suddiviso è ora indipendente dal backup Snapshot del sistema di origine.
Il flusso di lavoro di refresh dopo un'operazione di suddivisione dei cloni appare leggermente diverso rispetto all'operazione senza suddivisione dei cloni. Dopo un'operazione di cloning split, non è più necessaria alcuna operazione di eliminazione dei cloni, poiché il volume dei dati di destinazione non è più un volume FlexClone.
Il flusso di lavoro è costituito dai seguenti passaggi:
-
Se il sistema SAP HANA di destinazione è stato protetto in SnapCenter, occorre rimuovere per primo la protezione.
-
Il database SAP HANA deve essere arrestato, il volume di dati deve essere smontato e la voce fstab creata da SnapCenter deve essere rimossa. Questi passaggi devono essere eseguiti manualmente.
-
Ora il workflow di creazione dei cloni di SnapCenter può essere eseguito come descritto in precedenza nelle sezioni.
-
Dopo l'operazione di refresh, il vecchio volume di dati di destinazione esiste ancora e deve essere eliminato manualmente con, ad esempio, Gestore di sistema di ONTAP.
Automazione del workflow SnapCenter con script PowerShell
Nelle sezioni precedenti, i diversi flussi di lavoro sono stati eseguiti utilizzando l'interfaccia utente di SnapCenter. Tutti i flussi di lavoro possono essere eseguiti anche con script PowerShell o chiamate API REST, consentendo un'ulteriore automazione. Le sezioni seguenti descrivono esempi di script PowerShell di base per i seguenti flussi di lavoro.
-
Creare un clone
-
Elimina clone
Gli script di esempio vengono forniti così come sono e non sono supportati da NetApp.
Tutti gli script devono essere eseguiti in una finestra di comando PowerShell. Prima di poter eseguire gli script, è necessario stabilire una connessione al server SnapCenter utilizzando Open-SmConnection comando.
Creare un clone
Il semplice script riportato di seguito mostra come è possibile eseguire un'operazione di creazione di un clone SnapCenter utilizzando i comandi PowerShell. SnapCenter New-SmClone il comando viene eseguito con l'opzione della riga di comando richiesta per l'ambiente di laboratorio e lo script di automazione discusso in precedenza.
$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."
L'output della schermata mostra l'esecuzione dello script di creazione del clone 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.
Elimina clone
Il semplice script riportato di seguito mostra come è possibile eseguire un'operazione di eliminazione dei cloni di SnapCenter utilizzando i comandi PowerShell. SnapCenter Remove-SmClone il comando viene eseguito con l'opzione della riga di comando richiesta per l'ambiente di laboratorio e lo script di automazione discusso in precedenza.
$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>
L'output della schermata mostra l'esecuzione dello script 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>