Exadata: Migrando uma VM para outro DBServer

Por Franky Weber Faust Oracle ACE
Publicado em Setembro 2018

Revisado por Victor Ambrsut




Objetivo: 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 nosso 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 objetivo é isolar o VM Domain exa-vm1 no DBServer exa-db1 no Exadata, para que este possa utilizar, quando necessário, todos os recursos disponíveis neste DBServer.



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


Inicialmente vamos 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"





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

Neste exemplo como queremos isolar a VM exa-vm1 no exa-db1, então precisamos migrar a VM exa-vm3 para outro DBServer, neste caso vamos migrá-la para o exa-db6.

Para acessar a VM exa-vm3 podemos 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 aqui estamos trabalhando no ambiente de contingência, para evitar indisponibilidades não necessárias para os Databases, vamos alterar a configuração do Standby para prepará-lo para a migração.

Efetuamos o acesso ao Broker:

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





Listamos a configuração atual:

DGMGRL> show configuration





Agora alteramos 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;





Também por precaução, mas não é necessário, podemos desabilitar a atualização do Standby (Redo Apply):

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





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

DGMGRL> show database orclgt





Agora vamos efetuar o shutdown no banco de dados Standby:

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





Desabilitamos o startup automático (também não é necessário, pois o Clusterware salva o último status do recurso, vamos fazer só por garantia):

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





E então a partir do DBServer exa-db1 efetuamos o shutdown da VM exa-vm3:

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





Vamos conferir a lista das VMs online agora no DBServer exa-db1:

[root@exa-db1 ~]# xm list





Para realizar a migração precisamos copiar os arquivos da VM exa-vm3 para o DBServer exa-db6:

[root@exa-db1 ~]# scp -rp /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br  
root@exa-db6:/EXAVMIMAGES/GuestImages/





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

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





Vamos listar os arquivos da VM exa-vm3 no DBServer exa-db1 para ver se não esquecemos de algum que possa ser necessário:

[root@exa-db1 ~]# ls -lh /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/





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

[root@exa-db1 ~]# ls -lh /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/





Observe que o uuid da VM é o mesmo do diretório onde estão os link simbólicos.
Vamos listar também os links simbólicos dos discos da VM exa-vm3:

[root@exa-db1 ~]# ls -lh /OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/





Agora já no DBServer exa-db6 vamos criar 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 passo apresentado acima, pois é citado de outra maneira na documentação e quando não foi feito este passo as interfaces InfiniBand não subiram na VM e consequentemente o Clusterware também não subiu devido a não conseguir acessar os discos dos Storage Cells.

Temos que criar também 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





Agora criamos os links simbólicos dos discos da VM:

[root@exa-db6 ~]# ln -s /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/<nome_do_disco>.img  
/OVS/Repositories/c61093b7207b43d2b5b63c07db32a965/VirtualDisks/<uuid_do_disco>.img





Vamos dar boot na VM exa-vm3 no DBServer exa-db6 utilizando o arquivo de configuração e já acessar a console através do parâmetro “-c" para acompanhar toda a inicialização da mesma:

[root@exa-db6 ~]# xm create /EXAVMIMAGES/GuestImages/exa-vm3.loredata.com.br/vm.cfg -c





Para sair do console da VM e voltar ao DBServer pressione "ctrl 5".
Listamos as VMs presentes no DBServer exa-db6:

[root@exa-db6 ~]# xm list





Podemos ver que a VM exa-vm3 está online no DBServer exa-db6 conforme nosso objetivo.
VM migrada e iniciada com sucesso no DBServer exa-db6.
Agora vamos habilitar o Standby Database novamente.

Habilitamos o startup do Database:

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





Efetuamos o startup:

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





Acessamos o Broker:

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





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

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





Conferimos a alteração e de quanto tempo é o Gap, caso exista:

DGMGRL> show database orclgt





Vamos voltar a configuração para Maximum Availability:

DGMGRL> edit Configuration set Protection Mode as MaxAvailability;





Confirmamos que está como desejado:

DGMGRL> show  configuration;





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.



Referências

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




Franky Weber Faust atua como administrador de banco de dados Oracle e MySQL no PagSeguro, tem 26 anos, é graduado em Tecnologia em Bancos de Dados e iniciou sua carreira trabalhando num projeto internacional da Volkswagen com os bancos de dados DB2 da IBM, SQL Server da Microsoft e tambémcom o Oracle e desde o início direcionou seus estudos para as tecnologias Oracle. É especialista em tecnologias de Alta Disponibilidade como RAC, Dataguard e GoldenGate e compartilha seus conhecimentos no blog loredata.com.br. Possui as certificações OCE SQL, OCA 11g, OCP 12c, OCS RAC 12c e OCS Linux 6.

Este artigo foi revisto pela equipe de produtos Oracle e está em conformidade com as normas e práticas para o uso de produtos Oracle