Migrando uma VM para outro DBServer no Exadata

Olá pessoal, o objetivo aqui é apresentar como migrar uma VM para outro Database Server (DBServer) do Exadata.

Atualmente trabalho com um Exadata X5-2 com Oracle VM e vez ou outra precisamos realizar uma manutenção específica para este ambiente, o qual é diferente de outras implementações de Exadata que vemos comumente por aí.

Num Exadata com Oracle VM temos nos Database Servers um hypervisor que gerencia os Domains (VMs), sendo assim em cada DBServer podemos ter várias VMs para diferentes Databases. Esta é uma outra maneira de separar o workload dos Databases no Exadata.

Exadata

Oracle Virtual Machine on Exadata

O meu objetivo é isolar o VM Domain exa-vm1 no DBServer exa-db1 no Exadata, para que este possa utilizar, quando necessário, todos os recursos dispoíveis neste DBServer.

Processo de migração de VM no Exadata X5-2

Inicialmente vou executar o utilitário “dcli” para poder acessar todos os DBServers do Exadata e listar as VMs:

[root@exa-db1 ~]# dcli -g all_dbnodes -l root "xm list"
Unable to connect to cells: ['exa-db7', 'exa-db8']
exa-db1: Name 						ID 	Mem 	VCPUs 	State 	Time(s)
exa-db1: Domain-0 					0 	8192	4 		r----- 	15142926.6
exa-db1: exa-vm1.loredata.com.br 	9 	180224 	48 		-b---- 	37594.0
exa-db1: exa-vm3.loredata.com.br 	1 	49152 	8 		r----- 	18131446.8
exa-db2: Name 						ID 	Mem 	VCPUs 	State 	Time(s)
exa-db2: Domain-0 					0 	8192 	4 		r----- 	15011160.7
exa-db2: exa-vm4.loredata.com.br 	1 	65536 	12 		r----- 	50986893.1
exa-db2: exa-vm2.loredata.com.br 	4	180224 	48 		-b---- 	62669.4
exa-db3: Name 						ID 	Mem 	VCPUs 	State 	Time(s)
exa-db3: Domain-0 					0 	8192 	4 		r----- 	8553671.7
exa-db3: exa-vm5.loredata.com.br 	10 	65536 	12 		-b---- 	384928.0
exa-db3: exa-vm7.loredata.com.br 	9 	49152 	8 		r----- 	5716802.4
exa-db3: exa-vm8.loredata.com.br 	1 	65536 	12 		-b---- 	5846901.3
exa-db4: Name 						ID	Mem 	VCPUs 	State 	Time(s)
exa-db4: Domain-0 					0 	8192 	4 		r----- 	4206662.7
exa-db4: exa-vm9.loredata.com.br 	5 	49152 	8 		r----- 	249203.3
exa-db4: exa-vm6.loredata.com.br 	4 	65536 	12 		r----- 	254795.8
exa-db4: exa-vm10.loredata.com.br 	6 	65536 	12 		-b---- 	416904.8
exa-db5: Name 						ID 	Mem 	VCPUs 	State 	Time(s)
exa-db5: Domain-0 					0 	8192 	4 		r----- 	6879432.2
exa-db5: exa-vm11.loredata.com.br 	3 	49152 	8 		-b---- 	4330469.7
exa-db5: exa-vm12.loredata.com.br 	2 	81920 	16 		-b---- 	6914358.4
exa-db5: exa-vm13.loredata.com.br 	1 	57344 	8 		r----- 	19232170.0
exa-db6: Name 						ID 	Mem 	VCPUs 	State 	Time(s)
exa-db6: Domain-0 					0 	8192 	4 		r----- 	5799919.6
exa-db6: exa-vm14.loredata.com.br 	11 	49152 	8 		-b---- 	318180.9
exa-db6: exa-vm15.loredata.com.br 	12 	65536 	8 		r----- 	458791.7
exa-db6: exa-vm16.loredata.com.br 	2 	81920 	16 		r----- 	8895233.3

O erro apresentado para conectar aos DBNodes exa-db7 e exa-db8 é devido ao isolamento da rede através de ACLs.

Neste exemplo como quero isolar a VM exa-vm1 no exa-db1, então preciso migrar a VM exa-vm3 para outro DBServer, no meu caso vou migrá-la para o exa-db6.

Para acessar a VM exa-vm3 posso utilizar o comando “xm console exa-vm3.loredata.com.br” a partir do DBServer no qual ela está (exa-db1) ou diretamente via “ssh”.

Como estou trabalhando no ambiente de contingência, para evitar indisponibilidades não necessárias para os Databases, vou alterar a configuração do Standby para prepará-lo para a migração.

Efetuo acesso ao Broker:

[orclgt.oracle@exa-vm3 ~]$ dgmgrl sys/oracle@ORCLGT_DGMGRL
DGMGRL for Linux: Version 12.1.0.2.0 - 64bit Production

Copyright (c) 2000, 2013, Oracle. All rights reserved.

Welcome to DGMGRL, type "help" for information.
Connected as SYSDBA.

Listo a configuração atual:

DGMGRL> show configuration

Configuration - orcl_dr

Protection Mode: MaxAvailability
Members:
orcltb - Primary database
orclgt - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS (status updated 31 seconds ago)

Altero o modo de proteção para Maximum Performance (Cuidado ao alterar isto no seu ambiente. Para saber mais leia este artigo):

DGMGRL> edit configuration set protection mode as maxperformance;
Succeeded.

Também por precaução desabilito a atualização do Standby (Redo Apply):

DGMGRL> edit database orclgt set state=apply-off;
Succeeded.

Confirmo que a alteração surtiu o efeito desejado:

DGMGRL> show database orclgt

Database - orclgt

Role: PHYSICAL STANDBY
Intended State: APPLY-OFF
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 15 seconds (computed 0 seconds ago)
Average Apply Rate: (unknown)
Real Time Query: OFF
Instance(s):
orclgt

Database Status:
SUCCESS

Efetuo shutdown no banco de dados Standby:

[orclgt.oracle@exa-vm3 ~]$ srvctl stop database -d orclgt

Desabilito o startup automático (não é necessário, pois o Clusterware salva o último status do recurso, estou fazendo só por garantia):

[orclgt.oracle@exa-vm3 ~]$ srvctl disable database -d orclgt

E então a partir do DBServer exa-db1 efetuo o shutdonw da VM exa-vm3:

[root@exa-db1 ~]# xm shutdown exa-vm3.loredata.com.br -w
Domain exa-vm3.loredata.com.br terminated
All domains terminated

Confiro a lista das VMs online:

[root@exa-db1 ~]# xm list
Name 						ID 	Mem 	VCPUs 	State 	Time(s)
Domain-0 					0 	8192 	4 		r----- 	15151377.7
exa-vm1.loredata.com.br 	9 	180224 	48 		-b---- 	56110.0

Copio os arquivos da VM exa-vm3 para o DBServer exa-db6

### -l 2000000 limita em 100 MB/s
###[root@exa-db1 ~]# scp -l 2000000 -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br root@exa-db6:/EXAVMIMAGES/GuestImages/

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/exa-vm3.loredata.com.br.cell.c61093b7207b43d2b5b63c07db32a965.conf root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
exa-vm3.loredata.com.br.cell.c61093b7207b43d2b5b63c07db32a965.conf 100% 3013 2.9KB/s 00:00

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/exa-vm3.loredata.com.br.virtualmachine.c61093b7207b43d2b5b63c07db32a965.conf root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
exa-vm3.loredata.com.br.virtualmachine.c61093b7207b43d2b5b63c07db32a965.conf 100% 4752 4.6KB/s 00:00

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/db12.1.0.2.160719-3.img root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
db12.1.0.2.160719-3.img 100% 50GB 108.3MB/s 07:53

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/grid12.1.0.2.160719.img root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
grid12.1.0.2.160719.img 100% 50GB 103.6MB/s 08:14

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/pv1_vgexadb.img root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
pv1_vgexadb.img 100% 62GB 100.0MB/s 10:35

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/System.img root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
System.img 100% 25GB 87.4MB/s 04:53

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/DISK01.img root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
DISK01.img 100% 20GB 110.1MB/s 03:06

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/DISK02.img root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
DISK02.img 100% 100GB 110.2MB/s 15:29

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg root@exa-db6:/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
vm.cfg 100% 3322 2.7KB/s 00:00

Ainda no DBServer exa-db1 consulto o uuid da VM exa-vm3:

[root@exa-db1 ~]# grep ^uuid /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg
uuid = 'c61093b7207b43d2b5b63c07db32a965'

Listo os arquivos da VM exa-vm3 para ver se não esqueci nenhum necessário:

[root@exa-db1 ~]# ls -lh /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/
total 87G
-rw-r----- 1 root root 3.0K Oct 24 2016  exa-vm3.loredata.com.br.cell.c61093b7207b43d2b5b63c07db32a965.conf
-rw-r----- 1 root root 4.7K Oct 24 2016  exa-vm3.loredata.com.br.virtualmachine.c61093b7207b43d2b5b63c07db32a965.conf
-rw-r----- 1 root root 50G 	Oct  2 06:30 db12.1.0.2.160719-3.img
-rw-r----- 1 root root 50G 	Oct  2 14:30 grid12.1.0.2.160719.img
-rw-r----- 1 root root 62G 	Sep 13 11:52 pv1_vgexadb.img
-rw-r----- 1 root root 25G 	Oct  1 19:21 System.img
-rw-r--r-- 1 root root 100G Sep 25 03:06 DISK01.img
-rw-r--r-- 1 root root 100G Sep 18 17:51 DISK02.img
-rw-r----- 1 root root 2.6K Sep 27 11:01 vm.cfg
-rw-r----- 1 root root 2.5K Jun 13 00:17 vm.cfg_13062017_C557767
-rw-r----- 1 root root 2.3K Oct 27 2016  vm.cfg.27102016

Listo o link simbólico para o arquivo de configuração da VM exa-vm3:

[root@exa-db1 ~]# ls -lh /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/
total 8.0K
drwxr----- 2 root root 4.0K Jun 13 00:36 VirtualDisks
lrwxrwxrwx 1 root root 60 Oct 24 2016 vm.cfg -> /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg

Observe que o uuid da VM é o mesmo do diretório onde estão os link simbólicos.

Listo também os links simbólicos dos discos da VM exa-vm3:

[root@exa-db1 ~]# ls -lh /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/
total 24K
lrwxrwxrwx 1 root root 69 Oct 24 2016 17646fbfbddf4752b30dba533a919c8b.img -> /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/pv1_vgexadb.img
lrwxrwxrwx 1 root root 77 Oct 24 2016 2544d24d9220486dba5c96062d572265.img -> /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/grid12.1.0.2.160719.img
lrwxrwxrwx 1 root root 64 Oct 24 2016 2adfc6446c4f45f2a11941b49a040ac0.img -> /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/System.img
lrwxrwxrwx 1 root root 77 Oct 24 2016 33721ddda9b04af28dc34a0e178e0f9e.img -> /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/db12.1.0.2.160719-3.img
lrwxrwxrwx 1 root root 67 Jun 13 00:36 581541eb44c349e9ba0d4c70326c4b63.img -> /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/DISK02.img
lrwxrwxrwx 1 root root 67 Oct 27 2016 661bbf817cd2440996b5921d5ad2d0d6.img -> /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/DISK01.img

Agora já no DBServer exa-db6 crio o diretório dos links simbólicos dos discos e do arquivo de configuração da VM:

[root@exa-db6 ~]# mkdir -p /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks

Atenção a este ponto, pois é citado de outra maneira na documentação e quando não fiz este passo as interfaces do Infiniband não subiram na VM e consequentemente o Clusterware também não subiu devido a não conseguir acessar os discos do Exadata Storage Cell.

Crio o link simbólico do arquivo de configuração:

[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/vm.cfg

Crio os links simbólicos dos discos da VM:

[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/pv1_vgexadb.img /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/17646fbfbddf4752b30dba533a919c8b.img
[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/grid12.1.0.2.160719.img /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/2544d24d9220486dba5c96062d572265.img
[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/System.img /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/2adfc6446c4f45f2a11941b49a040ac0.img
[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/db12.1.0.2.160719-3.img /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/33721ddda9b04af28dc34a0e178e0f9e.img
[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/DISK02.img /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/581541eb44c349e9ba0d4c70326c4b63.img
[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/DISK01.img /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/661bbf817cd2440996b5921d5ad2d0d6.img

Dou boot na VM exa-vm3 no DBServer exa-db6 utilizando o arquivo de configuração e já acessando o console da mesma através do parâmetro “-c”:

[root@exa-db6 ~]# xm create /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg -c
Using config file "/EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg".
Started domain exa-vm3.loredata.com.br (id=13)
Press any key to continue.
.......
GNU GRUB version 0.97 (632K lower / 3931136K upper memory)

+-------------------------------------------------------------------------+
| Exadata_DBM_0: LINUX_BOOT_0_DOMU 										  |
| 																		  |
| 																		  |
| 																		  |
| 																		  |
| 																		  |
| 																		  |
| 																		  |
| 																		  |
| 																		  |
| 																		  |
| 																		  |
+-------------------------------------------------------------------------+
Use the ^ and v keys to select which entry is highlighted.
Press enter to boot the selected OS, 'e' to edit the
commands before booting, 'a' to modify the kernel arguments
before booting, or 'c' for a command-line.

The highlighted entry will be booted automatically in 1 seconds.
Initializing cgroup subsys cpuset
Initializing cgroup subsys cpu
Linux version 2.6.39-400.277.1.el6uek.x86_64 (mockbuild@x86-ol6-builder-06) (gcc version 4.4.6 20110731 (Red Hat 4.4.6-3) (GCC) ) #1 SMP Wed Feb 24 16:13:42 PST 2016
Command line: root=LABEL=DBSYS bootarea=dbsys bootfrom=BOOT ro loglevel=7 panic=60 debug pci=noaer log_buf_len=1m nmi_watchdog=0 nomce transparent_hugepage=never rd_NO_PLYMOUTH audit=1 console=tty1 console=ttyS0,115200n8 processor.max_cstate=1 clocksource=pit nohpet nopmtimer hda=noprobe hdb=noprobe ide0=noprobe pci=nocrs
BIOS-provided physical RAM map:
.........[SAÍDA REMOVIDA PARA EVITAR CANSAÇO NO SCROLL-DOWN 🙂 HAHAHA. CASO QUEIRA VER O BOOT COMPLETO ACESSE ESSE LINK: <a href="https://drive.google.com/open?id=0B_N3mqs0olHhOEFYU1RPU3FnWEk" rel="noopener" target="_blank">Boot VM</a>]..........

exa-vm3.loredata.com.br login: ................................................................ started.
.......... started.

Para sair do console da VM e voltar ao DBServer pressione “ctrl 5”.

Listo as VMs presentes no DBServer exa-db6:

[root@exa-db6 ~]# xm list
Name 						ID 	Mem 	VCPUs State 	Time(s)
Domain-0 					0 	8192 	4 	  r----- 	5867279.7
exa-vm14.loredata.com.br 	11 	49152 	8 	  r----- 	425449.7
exa-vm15.loredata.com.br 	12 	65536 	8 	  r----- 	611987.4
exa-vm16.loredata.com.br 	2 	81920 	16 	  r----- 	8989361.6
exa-vm3.loredata.com.br 	13 	49152 	8 	  r----- 	221.6

Vejam que a VM exa-vm3 está online no DBServer exa-db6 conforme meu objetivo.

VM migrada e iniciada com sucesso no DBServer exa-db6.

Agora vou habilitar o Standby novamente.

Habilito o startup do Database:

[orclgt.oracle@exa-vm3 ~]$ srvctl enable database -d orclgt

Efetuo o startup:

[orclgt.oracle@exa-vm3 ~]$ srvctl start database -d orclgt

Acesso o Broker:

[orclgt.oracle@exa-vm3 ~]$ dgmgrl sys/oracle@ORCLGT_DGMGRL

Inicio a atualização (Redo Apply) do Standby:

DGMGRL> edit database orclgt set state=apply-on;
Succeeded.

Confiro a alteração e de quanto tempo é o Gap:

DGMGRL> show database orclgt

Database - orclgt

Role: PHYSICAL STANDBY
Intended State: APPLY-ON
Transport Lag: 0 seconds (computed 0 seconds ago)
Apply Lag: 0 seconds (computed 0 seconds ago)
Average Apply Rate: 28.82 MByte/s
Real Time Query: OFF
Instance(s):
orclgt

Database Status:
SUCCESS

Volto a configuração para Maximum Availability:

DGMGRL> edit Configuration set Protection Mode as MaxAvailability;
Succeeded.

Confirmo que está como desejado:


DGMGRL> show configuration;

Configuration - orcl_dr

Protection Mode: MaxAvailability
Members:
orcltb - Primary database
orclgt - Physical standby database

Fast-Start Failover: DISABLED

Configuration Status:
SUCCESS (status updated 52 seconds ago)

Lembre-se de desabilitar qualquer rotina que remova os Archivelogs do Primary ao efetuar esse procedimento para evitar trabalho desnecessário de resolução de Redo Gap.

Aos poucos vou trazer alguns artigos referente ao Oracle Exadata.

Por hoje é só pessoal. Se gostarem compartilhem e inscrevam-se no blog. 🙂

Abraços e até o próximo post.

Referências

http://docs.oracle.com/cd/E80920_01/DBMMN/maintaining-exadata-database-servers.htm#DBMMN22235