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