Ciclo di vita automatizzato di Oracle Clone su ANF con ASM
Suggerisci modifiche
PDF
Allen Cao, Niyaz Mohamed, NetApp
La soluzione fornisce un toolkit di automazione basato su Ansible per la configurazione, la clonazione e l'aggiornamento dei database clone Oracle dal database standby fisico di Oracle Data Guard ospitato nel cloud Azure su storage Azure NetApp Files con configurazione ASM.
Scopo
L'utilizzo dei cloni del database Oracle di standby fisico nella configurazione di Oracle Data Guard per altri casi d'uso ha molteplici scopi. Fornisce una copia scrivibile del database di produzione per scopi di sviluppo o UAT. In questo modo è possibile eliminare i costosi costi di licenza di Active Data Guard se è accettabile un breve ritardo (10-15 minuti) nella segnalazione. Si risparmia sui costi di archiviazione, soprattutto quando è disponibile un clone sottile. Questo toolkit di automazione basato su Ansible consente agli utenti di configurare, clonare e aggiornare i database Oracle clonati in base alle proprie pianificazioni, per una gestione semplificata del ciclo di vita. Il toolkit si applica ai database Oracle distribuiti sul cloud pubblico di Azure utilizzando l'archiviazione Azure NetApp Files e il database Oracle configurato in una configurazione Data Guard.
Questa soluzione affronta i seguenti casi d'uso:
-
Imposta i file di configurazione del clone del database standby Oracle per l'automazione Ansible.
-
Crea o aggiorna il database Oracle clone dallo standby di Data Guard utilizzando il playbook Ansible in base alla pianificazione definita dall'utente.
Pubblico
Questa soluzione è destinata alle seguenti persone:
-
Un DBA che gestisce i database Oracle nel cloud Azure.
-
Un amministratore di archiviazione che gestisce l'archiviazione Azure NetApp Files .
-
Un proprietario di applicazioni che desidera clonare i database Oracle dallo standby di Data Guard per altri casi d'uso.
Licenza
Accedendo, scaricando, installando o utilizzando il contenuto di questo repository GitHub, accetti i termini della licenza stabiliti in"File di licenza" .
|
Esistono alcune restrizioni relative alla produzione e/o alla condivisione di lavori derivati dai contenuti di questo repository GitHub. Prima di utilizzare il contenuto, assicurati di leggere i termini della licenza. Se non accetti tutti i termini, non accedere, scaricare o utilizzare i contenuti di questo repository. |
Distribuzione della soluzione
Prerequisiti per la distribuzione
Details
Per la distribuzione sono richiesti i seguenti prerequisiti.
Ansible controller:
Ansible v.2.10 and higher
ONTAP collection 21.19.1
Python 3
Python libraries:
netapp-lib
xmltodict
jmespath
Oracle servers: Physical standby Oracle servers in Data Guard configuration Clone target Oracle servers with ASM configuration
|
|
Per semplificare, il server Oracle di destinazione del clone dovrebbe essere configurato in modo identico al server Oracle di standby, come lo stack software Oracle, nonché il layout delle directory per Oracle Home, ecc. |
Scarica il toolkit
Details
git clone https://bitbucket.ngage.netapp.com/scm/ns-bb/na_oracle_clone_anf.git|
|
Al momento, l'accesso al toolkit è consentito solo agli utenti interni NetApp con accesso Bitbucket. Gli utenti esterni interessati possono richiedere l'accesso al proprio account team o contattare il team NetApp Solutions Engineering. |
Configurazione dei file host di origine e destinazione di Ansible
Details
Il toolkit include un file hosts che definisce gli host Oracle di origine e di destinazione su cui viene eseguito il playbook Ansible. Solitamente include l'host DB di standby nella configurazione di Data Guard e l'host clone Oracle di destinazione. Di seguito è riportato un file di esempio. Una voce host include l'indirizzo IP dell'host di destinazione e la chiave ssh per l'accesso dell'utente all'host per eseguire il comando clone o refresh. L'archiviazione Azure NetApp Files viene configurata tramite API. Pertanto, la connessione ANF avviene tramite host locale tramite protocollo HTTP.
[ora_stdby] oras ansible_host=172.179.119.75 ansible_ssh_private_key_file=oras.pem
[ora_clone] orac ansible_host=52.148.142.212 ansible_ssh_private_key_file=orac.pem
[azure] localhost ansible_connection=local
Configurazione delle variabili globali
Details
Di seguito è riportato un esempio di un tipico file di variabili globali vars.yml che include variabili applicabili a livello globale.
###################################################################### ###### Oracle DB clone on ANF user configuration variables ###### ###### Consolidate all variables from ANF, linux and oracle ###### ######################################################################
########################################### ### ONTAP/ANF specific config variables ### ###########################################
# ANF credential subscription: "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" client: "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" secret: "xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" tenant: "xxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx"
# Cloned DB volumes from standby DB
resource_group: ANFAVSRG
storage_account: ANFOraWest
anf_pool: database2
data_vols:
- "{{ groups.ora_stdby[0] }}-u02"
- "{{ groups.ora_stdby[0] }}-u04"
- "{{ groups.ora_stdby[0] }}-u05"
- "{{ groups.ora_stdby[0] }}-u06"
- "{{ groups.ora_stdby[0] }}-u03"
nfs_lifs: - 10.0.3.36 - 10.0.3.36 - 10.0.3.36 - 10.0.3.36 - 10.0.3.36
########################################### ### Linux env specific config variables ### ###########################################
#################################################### ### DB env specific install and config variables ### ####################################################
# Standby DB configuration
oracle_user: oracle
oracle_base: /u01/app/oracle
oracle_sid: NTAP
db_unique_name: NTAP_LA
oracle_home: '{{ oracle_base }}/product/19.0.0/{{ oracle_sid }}'
spfile: '+DATA/{{ db_unique_name }}/PARAMETERFILE/spfile.289.1190302433'
adump: '{{ oracle_base }}/admin/{{ db_unique_name }}/adump'
grid_home: /u01/app/oracle/product/19.0.0/grid
asm_disk_groups:
- DATA
- LOGS
# Clond DB configuration clone_sid: NTAPDEV sys_pwd: "xxxxxxxx"
Configurazione delle variabili host
Details
Le variabili host sono definite nella directory host_vars denominata {{ host_name }}.yml e si applicano solo all'host specifico. Per questa soluzione, viene configurato solo il file dei parametri host del database clone di destinazione. I parametri del database standby di Oracle sono configurati nel file global vars. Di seguito è riportato un esempio di file di variabili host del database clone Oracle di destinazione orac.yml che mostra una configurazione tipica.
# User configurable Oracle clone host specific parameters
# Database SID - clone DB SID
oracle_base: /u01/app/oracle
oracle_user: oracle
clone_sid: NTAPDEV
oracle_home: '{{ oracle_base }}/product/19.0.0/{{ oracle_sid }}'
clone_adump: '{{ oracle_base }}/admin/{{ clone_sid }}/adump'
grid_user: oracle
grid_home: '{{ oracle_base }}/product/19.0.0/grid'
asm_sid: +ASM
Configurazione aggiuntiva del server Oracle di destinazione del clone
Details
Il server Oracle di destinazione clone deve avere lo stesso stack software Oracle del server Oracle di origine installato e patchato. L'utente Oracle .bash_profile ha $ORACLE_BASE e $ORACLE_HOME configurati. Inoltre, la variabile $ORACLE_HOME deve corrispondere all'impostazione del server Oracle di origine. Se l'impostazione di destinazione ORACLE_HOME è diversa dalla configurazione del server Oracle di standby, creare un collegamento simbolico per aggirare le differenze. Di seguito un esempio.
# .bash_profile
# Get the aliases and functions
if [ -f ~/.bashrc ]; then
. ~/.bashrc
fi
# User specific environment and startup programs
export ORACLE_BASE=/u01/app/oracle export GRID_HOME=/u01/app/oracle/product/19.0.0/grid export ORACLE_HOME=/u01/app/oracle/product/19.0.0/NTAP alias asm='export ORACLE_HOME=$GRID_HOME;export PATH=$PATH:$GRID_HOME/bin;export ORACLE_SID=+ASM'
Esecuzione del playbook
Details
Sono disponibili in totale due playbook per eseguire il ciclo di vita del clone del database Oracle. La clonazione o l'aggiornamento del DB possono essere eseguiti su richiesta o pianificati come un'attività crontab.
-
Installare i prerequisiti del controller Ansible una sola volta.
ansible-playbook -i hosts ansible_requirements.yml -
Crea e aggiorna il database clone su richiesta o regolarmente da crontab con uno script shell per chiamare il playbook clone o refresh.
ansible-playbook -i oracle_clone_asm_anf.yml -u azureuser -e @vars/vars.yml0 */2 * * * /home/admin/na_oracle_clone_anf/oracle_clone_asm_anf.sh
Per clonare eventuali database aggiuntivi, creare un file oracle_clone_n_asm_anf.yml e un file oracle_clone_n_asm_anf.sh separati. Configurare di conseguenza gli host di destinazione Ansible, il file vars.yml globale e il file hostname.yml nella directory host_vars.
|
|
L'esecuzione del toolkit in varie fasi prevede delle pause per consentire il completamento di un'attività specifica. Ad esempio, si interrompe per due minuti per consentire il completamento della clonazione dei volumi DB. In generale, l'impostazione predefinita dovrebbe essere sufficiente, ma potrebbe essere necessario adattare i tempi in base a situazioni o implementazioni specifiche. |
Dove trovare ulteriori informazioni
Per saperne di più sull'automazione della soluzione NetApp , consultare il seguente sito Web"Automazione delle soluzioni NetApp "