Esempio di implementazione
Suggerisci modifiche
PDF
A causa dell'elevato numero di opzioni disponibili per le configurazioni di sistema e storage, l'implementazione di esempio deve essere utilizzata come modello per i requisiti di configurazione e configurazione del sistema.
|
Gli script di esempio vengono forniti così come sono e non sono supportati da NetApp. Puoi richiedere la versione corrente degli script via email a ng-sapcc@netapp.com. |
Configurazioni e limitazioni validate
I seguenti principi sono stati applicati all'implementazione di esempio e potrebbero dover essere adattati per soddisfare le esigenze dei clienti:
-
I sistemi SAP gestiti utilizzavano NFS per accedere ai volumi di storage NetApp e sono stati configurati in base al principio di progettazione adattiva.
-
È possibile utilizzare tutte le release di ONTAP supportate dai moduli Ansible di NetApp (ZAPI e REST API).
-
Le credenziali per un singolo cluster NetApp e SVM erano codificate come variabili nello script del provider.
-
La clonazione dello storage è stata eseguita sullo stesso sistema storage utilizzato dal sistema SAP di origine.
-
I volumi di storage per il sistema SAP di destinazione avevano gli stessi nomi dell'origine con un'appendice.
-
Non è stato implementato alcun cloning nello storage secondario (SV/SM).
-
Lo split FlexClone non è stato implementato.
-
I numeri delle istanze erano identici per i sistemi SAP di origine e di destinazione.
Setup di laboratorio
La figura seguente mostra la configurazione di laboratorio utilizzata. Il sistema SAP di origine HN9 utilizzato per l'operazione di clone del sistema era costituito dal database H09, dal SAP CS e dal SAP AS Services in esecuzione sullo stesso host (sap-lnx32) con installato "design adattivo" attivato. Un nodo di controllo Ansible è stato preparato secondo la "Playbook Ansible per NetApp ONTAP" documentazione.
Anche l'agente host SAP è stato installato su questo host. Lo script del provider NetApp e i playbook Ansible sono stati configurati sul nodo di controllo Ansible come descritti nella ""Appendice: Configurazione script provider.""
L'host sap-lnx49 È stato utilizzato come destinazione per le operazioni di cloning di SAP lama ed è stata configurata la funzionalità di isolamento-ready.
Sono stati utilizzati diversi sistemi SAP (HNA come origine e HN2 come destinazione) per le operazioni di copia e refresh del sistema, perché è stata abilitata l'automazione post-copia (PCA).
Nella configurazione di laboratorio sono state utilizzate le seguenti versioni software:
-
SAP lama Enterprise Edition 3.00 SP23_2
-
SAP HANA 2.00.052.00.1599235305
-
SAP 7.77 PATCH 27 (S/4 HANA 1909)
-
SAP host Agent 7.22 Patch 56
-
SAPACEXT 7.22 Patch 69
-
Linux SLES 15 SP2
-
Ansible 2. 13.7
-
NetApp ONTAP 9.8P8
Configurazione di SAP lama
Definizione del provider SAP lama
La definizione del provider viene eseguita in Automation Studio di SAP lama, come mostrato nella seguente schermata. L'implementazione di esempio utilizza una singola definizione di provider utilizzata per diverse fasi di provisioning personalizzate e per le operazioni hook, come spiegato in precedenza.
Il provider netapp_clone viene definito come script netapp_clone.sh Registrato presso l'agente host SAP. L'agente host SAP viene eseguito sull'host centrale sap-jump, Che funge anche da nodo di controllo Ansible.
La scheda utilizzato in mostra le operazioni personalizzate per cui viene utilizzato il provider. La configurazione per il provisioning personalizzato NetAppClone e gli hook personalizzati Delete NetAppClone e Delete NetAppClone Refresh sono illustrati nei capitoli successivi.
I parametri ClonePostFix e SnapPostFix vengono richiesti durante l'esecuzione del flusso di lavoro di provisioning e utilizzati per i nomi dei volumi Snapshot e FlexClone.
Provisioning personalizzato SAP lama
Nella configurazione di provisioning personalizzata di SAP lama, il provider del cliente descritto in precedenza viene utilizzato per sostituire le fasi del workflow di provisioning Clone Volumes e PostCloneVolumes.
Gancio personalizzato SAP lama
Se un sistema viene cancellato con il flusso di lavoro System Destroy, viene utilizzato Hook Delete NetAppClone per chiamare la definizione del provider netapp_clone. L'hook Delete NetApp Clone Refresh viene utilizzato durante il flusso di lavoro di refresh del sistema perché l'istanza viene conservata durante l'esecuzione.
È importante configurare Usa Mount Data XML per il gancio personalizzato, in modo che SAP lama fornisca al provider le informazioni sulla configurazione del punto di montaggio.
Per garantire che il gancio personalizzato venga utilizzato ed eseguito solo quando il sistema è stato creato con un workflow di provisioning personalizzato, viene aggiunto il seguente vincolo.
Ulteriori informazioni sull'utilizzo di ganci personalizzati sono disponibili nella "Documentazione SAP lama".
Abilitare un workflow di provisioning personalizzato per il sistema di origine SAP
Per abilitare il workflow di provisioning personalizzato per il sistema di origine, è necessario adattarlo nella configurazione. Selezionare la casella di controllo Usa processo di provisioning personalizzato con la definizione di provisioning personalizzato corrispondente.
