Exadata: Migrando uma VM para outro DBServer

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:

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:

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

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

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

Agora vamos efetuar o shutdown no banco de dados Standby:

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):

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

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

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:

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:

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

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:

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:

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:

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:

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

Listamos as VMs presentes no DBServer exa-db6:

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:

Efetuamos o startup:

Acessamos o Broker:

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

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

Vamos voltar a configuração para Maximum Availability:

Confirmamos que está como desejado:

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