Skip to main content
NetApp database solutions
La versione in lingua italiana fornita proviene da una traduzione automatica. Per eventuali incoerenze, fare riferimento alla versione in lingua inglese.

Ciclo di vita automatizzato di Oracle Clone su GCNV con ASM

Collaboratori kevin-hoke

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 Google su storage Google Cloud NetApp Volumes con configurazione ASM.

Scopo

Sfruttare i cloni rapidi del database Oracle di standby fisico nella configurazione di Oracle Data Guard per altri casi d'uso serve a molteplici scopi. Fornisce un database di reporting quasi in tempo reale e anche 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. Permette di risparmiare sui costi di archiviazione, in particolare quando è possibile effettuare una clonazione ridotta dei volumi di dati primari. 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 Google utilizzando l'archiviazione Google Cloud NetApp Volumes (GCNV) e la configurazione del database Oracle 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 di Google.

  • Un amministratore di storage che gestisce lo storage di Google NetApp Volumes.

  • 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" .

Nota 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
Nota 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
https://bitbucket.ngage.netapp.com/projects/NS-BB/repos/na_oracle_clone_gcnv/browse
Nota 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'accesso e la gestione dello storage Google Cloud NetApp Volumes avvengono tramite gcloud cli.

[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
[gcp]
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 GCNV user configuration variables     ######
###### Consolidate all variables from GCNV, linux and oracle    ######
######################################################################
############################################
### ONTAP/GCNV specific config variables ###
############################################
# GCNV credential
key_file: /home/admin/google-cloud-sdk/service_key.json
# Cloned DB volumes from standby DB
project_id: cvs-pm-host-1p
location: us-west4
protocol: nfsv3
data_vols:
  - "{{ groups.ora_stdby[0] }}-u02"
  - "{{ groups.ora_stdby[0] }}-u03"
  - "{{ groups.ora_stdby[0] }}-u04"
  - "{{ groups.ora_stdby[0] }}-u05"
  - "{{ groups.ora_stdby[0] }}-u06"
  - "{{ groups.ora_stdby[0] }}-u07"
  - "{{ groups.ora_stdby[0] }}-u08"
nfs_lifs:
  - 10.165.128.197
  - 10.165.128.196
  - 10.165.128.197
  - 10.165.128.197
  - 10.165.128.197
  - 10.165.128.197
  - 10.165.128.197
nfs_client: 0.0.0.0/0
###########################################
### 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.1198520783'
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"
# Data Guard mode - MaxAvailability or MaxPerformance
dg_mode: MaxAvailability
Nota Per una distribuzione dell'automazione più sicura, è possibile utilizzare Ansible Vault per crittografare informazioni sensibili quali password, token di accesso o chiavi, ecc. La soluzione non copre l'implementazione di Ansible Vault, ma è ampiamente documentata nella documentazione di Ansible. Si prega di fare riferimento a"Protezione dei dati sensibili con Ansible Vault" per i dettagli.

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'
Nota Assicurarsi che il parametro di configurazione asm_diskstring nell'host clone del database includa tutti i punti di montaggio NFS dei volumi clonati e i percorsi delle directory sui dispositivi disco.

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.

  1. Installare i prerequisiti del controller Ansible una sola volta.

    ansible-playbook -i hosts ansible_requirements.yml
  2. 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_gcnv.yml -u admin -e @vars/vars.yml
    0 */2 * * * /home/admin/na_oracle_clone_gcnv/oracle_clone_asm_gcnv.sh

Per clonare eventuali database aggiuntivi, creare un file oracle_clone_n_asm_gcnv.yml e un file oracle_clone_n_asm_gcnv.sh separati. Configurare di conseguenza gli host di destinazione Ansible, il file vars.yml globale e il file hostname.yml nella directory host_vars.

Nota 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 "