SnapMirror
SnapMirror es una solución de replicación avanzada a nivel de storage de Netapp, que no solo puede ser utilizado como mecanismo de recuperación ante desastres, ya en combinación con FlexClone permite crear copias con uso eficiente del espacio, que pueden ser utilizadas para testing, Business Inteligence y ambientes de desarrollo.
SnapMirror utiliza la tecnologia de SnapShot de Netapp para su operación.
Oracle soporta oficialmente el uso de tecnologías de terceros de SnapShot (MOS 604683.1) para crear imágenes del tipo Crash Consistent, sin la necesidad de poner la base de datos en modo BEGIN BACKUGP
que pueden ser usadas como opciones de Respaldo, restauración y recuperación.
Ventajas de SnapMirror
- No requiere de espacio adicional en el servidor de destino.
- Se realiza a nivel de Storage
- No requiere poner la base de datos en modo Begin Backup (Crash Consistency images)
- La replicación puede ser bidireccional, como Oracle DataGuard luego de un switchover
A continuación les muestro un ejemplo de recuperación de una base de datos Oracle utilizando SnapMirror como mecanismo de recuperación ante desastres (FailOver).
Configuración del laboratorio:
- 2 Oracle Database 11.2 Single Instance
- Oracle ASM
- 2 Data Ontap 8.0 simulator (filer)
- iSCSI Protocol
- Oracle Enterprise Linux 5.7 x86_64
- Vmware Player
Habilitación SnapMirror en el storage de origen y destino
filer01> options snapmirror.enable
snapmirror.enable on
filer01>
filer02> options snapmirror.enable
snapmirror.enable on
filer02>
Acceso para SnapMirror
Es necesario que el filer de destino tenga acceso al filer de origen, para ello debemos agregar el nombre y ip en el archivo /etc/snapmirror.allow del filer de origen, podemos utilizar el comando wrfile y rdfile
filer01> rdfile /etc/snapmirror.allow
192.168.161.139
filer02
filer01>
Inicializacion de SnapMirror relation
Primero debemos crear los volumenes necesarios en el filer de destino, estos deben ser del mismo tamaño o mayor que los volumenes de origen.
Volumenes de origen
filer01> df -h
Filesystem total used avail capacity Mounted on
/vol/vol0/ 647MB 132MB 515MB 20% /vol/vol0/
/vol/vol0/.snapshot 161MB 28MB 133MB 17% /vol/vol0/.snapshot
/vol/voldb/ 4096MB 4096MB 0MB 100% /vol/voldb/
/vol/voldb/.snapshot 1024MB 103MB 920MB 10% /vol/voldb/.snapshot
/vol/vol_archive/ 2457MB 2192MB 265MB 89% /vol/vol_archive/
/vol/vol_archive/.snapshot 614MB 452KB 613MB 0% /vol/vol_archive/.snapshot
filer01>
Volumenes de destino
filer02> vol create voldb aggr0 5g
Creation of volume 'voldb' with size 5g on containing aggregate
'aggr0' has completed.
filer02> vol create vol_archive aggr0 3g
Creation of volume 'vol_archive' with size 3g on containing aggregate
'aggr0' has completed.
filer02> df -Ah
Aggregate total used avail capacity
aggr0 11GB 9052MB 2917MB 76%
aggr0/.snapshot 630MB 304MB 325MB 48%
filer02> df -h
Filesystem total used avail capacity Mounted on
/vol/vol0/ 647MB 127MB 520MB 20% /vol/vol0/
/vol/vol0/.snapshot 161MB 5288KB 156MB 3% /vol/vol0/.snapshot
/vol/voldb/ 4096MB 108KB 4095MB 0% /vol/voldb/
/vol/voldb/.snapshot 1024MB 0TB 1024MB 0% /vol/voldb/.snapshot
/vol/vol_archive/ 2457MB 108KB 2457MB 0% /vol/vol_archive/
/vol/vol_archive/.snapshot 614MB 0TB 614MB 0% /vol/vol_archive/.snapshot
filer02>
Segundo, debemos poner en modo restringido los volumenes en el filer de destino.
filer02> vol restrict voldb
Volume 'voldb' is now restricted.
filer02> vol restrict vol_archive
Volume 'vol_archive' is now restricted.
filer02>
Tercero, debemos inicializar el SnapMirror, para ello utilizamos el siguiente comando.
filer02> snapmirror initialize -S filer01:voldb filer02:voldb
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.
filer02> snapmirror initialize -S filer01:vol_archive filer02:vol_archive
Transfer started.
Monitor progress with 'snapmirror status' or the snapmirror log.
filer02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
filer01:vol_archive filer02:vol_archive Uninitialized - Transferring
filer01:voldb filer02:voldb Uninitialized - Transferring (73 MB done)
filer02>
Podemos monitorear el estado de la transferencia con el comando “snapmirror status”, hasta que el estado sea “idle”.
filer02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
filer01:vol_archive filer02:vol_archive Uninitialized - Transferring
filer01:voldb filer02:voldb Uninitialized - Transferring (250 MB done)
filer02>
filer02> snapmirror status
Snapmirror is on.
Source Destination State Lag Status
filer01:vol_archive filer02:vol_archive Snapmirrored 00:57:39 Idle
filer01:voldb filer02:voldb Snapmirrored 00:58:03 Idle
filer02>
Configuración iSCSI
Ahora debemos configurar la conexión iSCSI en el filer de destino, y la maquina donde recuperaremos la base de datos.
Debemos obtener el IQN del nodo02, esto corresponde al contenido del archivo /etc/iscsi/initiator.name
[root@nodo02 ~]# more /etc/iscsi/initiatorname.iscsi
InitiatorName=iqn.1994-05.com.redhat:5249af2f9f59
[root@nodo02 ~]#
En el filer de destino debemos crear un igroup de tipo iSCSI, al cual le asignaremos las Luns replicadas con snapmirror, y le daremos acceso al nodo02.
filer02>igroup create -i -t linux simdb iqn.1994-05.com.redhat:5249af2f9f59
filer02> lun show
/vol/vol_archive/volarc01 2g (2147483648) (r/o, online)
/vol/voldb/volasm01 3g (3221225472) (r/o, online)
filer02> lun map /vol/vol_archive/volarc01 simdb
Tue Dec 27 18:29:08 GMT [lun.map:info]: LUN /vol/vol_archive/volarc01 was mapped to initiator group simdb=0
filer02> lun map /vol/voldb/volasm01 simdb
Tue Dec 27 18:29:19 GMT [lun.map:info]: LUN /vol/voldb/volasm01 was mapped to initiator group simdb=1
filer02>
Ahora debemos terminar la relación del SnapMirror en el servidor de destino, de lo contrario no podremos utilizar los volumenes replicados.
filer02> snapmirror break -f voldb
snapmirror break: Destination voldb is now writable.
Volume size is being retained for potential snapmirror resync. If you would like to grow the volume and do not expect to resync, set vol option fs_size_fixed to off.
filer02> snapmirror break -f vol_archive
snapmirror break: Destination vol_archive is now writable.
Volume size is being retained for potential snapmirror resync. If you would like to grow the volume and do not expect to resync, set vol option fs_size_fixed to off.
filer02>
En el servidor de base de datos debemos reconfigurar iSCSI para que reconozca los 2 nuevos discos, para ello debemos ejecutar lo siguiente
[root@nodo02 ~]# service iscsi restart
Logging out of session [sid: 1, target: iqn.1992-08.com.netapp:sn.80335005, portal: 192.168.161.139,3260]
Logout of [sid: 1, target: iqn.1992-08.com.netapp:sn.80335005, portal: 192.168.161.139,3260]: successful
Stopping iSCSI daemon:
iscsid dead but pid file exists [ OK ]
Starting iSCSI daemon: [ OK ]
[ OK ]
Setting up iSCSI targets: Logging in to [iface: default, target: iqn.1992-08.com.netapp:sn.80335005, portal: 192.168.161.139,3260]
Login to [iface: default, target: iqn.1992-08.com.netapp:sn.80335005, portal: 192.168.161.139,3260]: successful
[ OK ]
[root@nodo02 ~]#
Luego de esto aparecerán las 2 nuevas luns, para que ASM identifique las LUN clonadas, podemos ejecutar el comando “scandisk” de ASM o reiniciar el servidor.
[root@nodo02 ~]# /etc/init.d/oracleasm listdisks
VOL01
VOL02
[root@nodo02 ~]# /etc/init.d/oracleasm scandisks
Scanning the system for Oracle ASMLib disks: [ OK ]
[root@nodo02 ~]# /etc/init.d/oracleasm listdisks
VOL01
VOL02
VOL_NETASM01
VOL_NETFRA01
[root@nodo02 ~]#
Montar DiskGroup en ASM
Luego de reconocidas las Luns clonadas debemos montarlas en ASM, para ello debemos ejecutar lo siguiente
[oracle@nodo02 grid]$ sqlplus
SQL*Plus: Release 11.2.0.2.0 Production on Tue Dec 27 11:58:55 2011
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Enter user-name: / as sysasm (SYSASM no SYSDBA)
Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - 64bit Production
With the Automatic Storage Management option
SQL> alter diskgroup dg_netapp_data mount;
Diskgroup altered.
SQL> alter diskgroup dg_netapp_fra mount;
Diskgroup altered.
SQL>
Montar la base de destino
La siguiente etapa consiste en montar la base de datos en los volumenes replicados, y luego realizar un recuperación del tipo Point in Time.
SQL> startup mount
ORACLE instance started.
Total System Global Area 463478784 bytes
Fixed Size 2227512 bytes
Variable Size 176161480 bytes
Database Buffers 281018368 bytes
Redo Buffers 4071424 bytes
Database mounted.
Obtener el SCN minimo
Ahora debemos ejecutar el archivo “scandatafiles.sql” para obtener el minimo SCN consistente, que es requerido para recuperar la base de datos a un punto del tiempo consistente. Este paso puede demorar un tiempo en completarse.
SQL> start scandatafiles
File 1 absolute fuzzy scn = 1241419
File 2 absolute fuzzy scn = 1241417
File 3 absolute fuzzy scn = 1241419
File 4 absolute fuzzy scn = 0
File 5 absolute fuzzy scn = 1238741
File 6 absolute fuzzy scn = 1238651
Minimum PITR SCN = 1241419
PL/SQL procedure successfully completed.
SQL> recover database until change 1241419;
Media recovery complete.
SQL> alter database open resetlogs;
Archivo SQL scandatafiles
# scans all files and update file headers with meta information
# depending on number and sizes of files, the scandatafile procedure can be a
# time consuming operation.
# create a script, “scandatafile”, with the following content
spool scandatafile.sql
set serveroutput on
declare
scn number(12) := 0;
scnmax number(12) := 0;
begin
for f in (select * from v$datafile) loop
scn := dbms_backup_restore.scandatafile(f.file#);
dbms_output.put_line('File ' || f.file# ||' absolute fuzzy scn = ' || scn);
if scn > scnmax then scnmax := scn; end if;
end loop;
dbms_output.put_line('Minimum PITR SCN = ' || scnmax);
end;
/
Mas información en Using Crash-Consistent Snapshot Copies as Valid Oracle Backups