190 likes | 315 Views
Consolidamento Database Oracle. Come eravamo…. LDAP Datastore Citrix Farm. Didattica on line. Gestione PTA Gestione DOC Timbrature Controllo accessi. Contabilità . Segreteria Studenti (ora replica di Esse3) Logistica. …e dove siamo arrivati. 100Mb/sec. 100Mb/sec. 100Mb/sec.
E N D
Consolidamento Database Oracle
Come eravamo… • LDAP • Datastore Citrix Farm • Didattica on line • Gestione PTA • Gestione DOC • Timbrature • Controllo accessi • Contabilità • Segreteria Studenti (ora replica di Esse3) • Logistica
…e dove siamo arrivati 100Mb/sec 100Mb/sec 100Mb/sec eth0 eth0 heartbeat eth2 eth2 CIOP CIP eth1 eth1 50Gb Database Cross 1000 Cross 1000 ORAFilerRETT ORAFilerDIT
Configurazione HW/SW Storage condiviso • Netapp F87 • 8x72GB HDD SCSI • Data ONTAP 6.5.1 R1 • Snapshot • SnapRestore • SnapMirror • NFS Nodi cluster • HP Proliant BL20p • 2x Intel Xeon 2.8 GHz • 2x36GB HDD UltraSCSI in RAID 1 • 2 GB RAM • Red Hat Enterprise 3 AS • Heartbeat 1.2.3 + mon • ORACLE 9.2.0.5
Struttura fisica database • Layout Oracle OFA (Optimal Flexible Architecture) per NetApp • Tutti i datafile, controlfile, redo log, archive log sono sul filer • Sul filesystem dei nodi questi file sono dei link simbolici ai filesystem nfs montati su filer • I binari di Oracle sono mantenuti sui dischi locali dei nodi • Le mount nfs seguono delle best practice Oracle/Netapp: rw, bg, tcp, hard, rsize=32768, wsize=32768 (http://www.netapp.com/tech_library/ftp/3369.pdf) /mnt/cluster/unitnprd/oracle • /oracle_prod • Datafile • Controlfile, copia 1 • Primo membro redo log group • Archive log destination 1 /mnt/cluster/unitnprd/oracle_1 • /oracle_prod_1 • Controlfile, copia 2 • Secondo membro redo log group /mnt/cluster/unitnprd/archive • /oracle_prod_archive • Archive log destination 2
Politiche di backup del database Oracle • Su nastro con programma di backup centralizzato (con doppia scrittura su pool libreria e pool conservato in cassaforte ignifuga) • Export di schemi selezionati due volte al giorno (ore 13 ed ore 23) • Full export una volta alla settimana • Hot backup su filer utilizzando gli snapshot, con script bash “crontabizzato” (ore 2,6,10,16,20) • Replica in sito di DR con SnapMirror …lo sappiamo, siamo un po’ paranoici!
Hot backup con gli snapshot alter tablespace SYSTEM begin backup; alter tablespace DATI1 begin backup; alter tablespace DATI2 begin backup; • Database in backup mode • Snapshot dei datafile • End backup del database • Switch log e backup dei controfile • Snapshot dei log e dei controlfile appena creati rsh orafilerdit snap create ${ORACLE_SID}.datafile.00 alter tablespace SYSTEM end backup; alter tablespace DATI1 end backup; alter tablespace DATI2 end backup; alter system archive log current; alter database backup controlfile to trace noresetlogs; alter database backup controlfile to '/mnt/orabackup/unitnprd/backup/hot/last/unitnprd_ctrlfile.ctl' reuse; alter database backup controlfile to trace as '/mnt/orabackup/unitnprd/backup/hot/last/unitnprd_ctrlfile.sql' reuse noresetlogs; create pfile=/mnt/orabackup/unitnprd/backup/hot/last/initunitnprd.ora' from spfile; rsh orafilerdit snap create ${ORACLE_SID}.ctrlarch.00
Hot backup con snapshot Un backup su filer sarà costituito da due snapshot: • ${ORACLE_SID}.datafile.xx • datafile • ${ORACLE_SID}.ctrlarch.xx • Redo log generati durante il backup • Backup controlfile (generato immediatamente prima dello snapshot), binario ed sql • Init file, generato a partire dal spfile • Lo spazio utilizzato da questo snapshot sarà particolarmente ridotto, riconducibile praticamente ai tre tipi di file sopraelencati
Hot backup con gli snapshot • Un backup viene creato in meno di un minuto • Lo snapshot viene creato in pochi secondi • Possibilità di fare backup più frequenti, anche durante le ore di punta • Maggiore velocità durante un restore • Lo spazio disco richiesto da un backup con gli snapshot è irrisorio: • 20 backup in linea • Spazio utilizzato dagli snapshot: poco più di 40 Gb
Scenario di restore/recovery… …nel caso di perdita di un datafile. Segue la normale procedura di restore/recovery di un database Oracle • Restore del file mancante • Recovery del tablespace
Restore con gli snapshot • Restore da nastro • Copia di un file dallo snapshot (con utility come cp) • Utilizzo di snaprestore (più veloce, possibilità di effettuare il revert di un intero volume in pochi secondi)
Restore con gli snapshot • Restore del datafile mancante snaprestore -t file –s unitnprd.datafile.xx /vol/vol0/oracle_prod/oradata/dati1.dbf
Scenario di restore/recovery • Recovery della tablespace alter tablespace dati offline temporary; <restore datafile> recover tablespace dati;
Scenario di restore/recovery • Fornire gli archive log necessari • Dalla posizione specificata nei parametri di Oracle “log_archive_dest” • Restore da nastro • Direttamente da snapshot /mnt/cluster/unitnprd/oracle/.snapshot/${ORACLE_SID}.ctrlarch.xx/oradata/archive • Riportare online la tablespace Alter tablespace dati online;
Disaster Recovery MAN 100 Mbps • Utilizza SnapMirror (asincrono) • Replica l’intero database su un altro filer in sede remota • Una replica ogni 15 minuti • Su linea a 100 Mbps: nessun problema di velocità (trasferimento dei soli incrementali, modello rsync). Possibilità di limitare la banda utilizzabile • Una replica anche ogni 24 ore (un problema verificatosi entro 15 minuti si propagherebbe anche sulla replica) • Snapmirror utilizzato anche per mantenere una copia sullo stesso filer. Utile per avere una copia aggiornata del db per test Documento tecnico NetApp di riferimento: http://www.netapp.com/tech_library/3057.html snapmirror orafilerdit Direzione Informatica orafilerrettRettorato
Disaster Recovery • Quiesce del filesystem di orafilerrett • Break della relazione tra i due filer: a questo punto il mirror di orafilerrett è writeable • Cambio dell’IP nei file hosts dei nodi del cluster • Mount del filesystem di orafilerrett • Recovery del database • Open database e …di nuovo al lavoro sfaticati! snapmirror orafilerdit Direzione Informatica orafilerrettRettorato
Disaster Recovery Modifiche apportate al sito secondario Al ripristino del sito primario è possibile risincronizzare il database: • Creando un nuovo mirror tra i due filer (copiando l’intero db, con snapmirror o backup+restore da nastro) • Reinizializzando il mirror a partire dall’ultimo snapshot in comune tra i due storage orafilerrettRettorato orafilerdit Direzione Informatica
To do • Consolidamento infrastruttura storage • Cluster di filer • Possibilità di utilizzo dei protocolli già in uso in Ateneo (FC SAN, iSCSI, CIFS, NFS) • Utilizzo di NDMP per backup su nastro • Migrazione a Data ONTAP 7G • FlexVolume: volumi dinamici • FlexClone: “snapshot” r/w vs copia db snapmirrorata. • Resource fencing sul cluster, tramite un meccanismo di STONITH, utilizzando HP iLO • Completamento del sito di DR (VMware ?)