Alterando Database Mirroring para utilizar uma placa de rede dedicada

Para quem já trabalhou com Database Mirroring, provavelmente já ouviu falar que o ideal é ter uma conexão de rede dedicada entre o Principal e o Mirror para evitar que problemas de lentidão na rede ou em algum switch causem problemas.

Lembre que, se você tiver um Mirror SÍNCRONO, as alterações no banco só serão confirmadas para a aplicação quando os dados já estiverem sido escritos em AMBOS os servidores. Então se houver lentidão entre eles, a sua aplicação também ficará lenta.

Lembre que nem mesmo a compressão de log no Database Mirror existente no SQL Server 2008 te protege desse tipo de problema, ela pode até amenizá-lo, mas não há como evitá-lo.

Essa conexão entre os servidores normalmente é feita através de um Switch (preferencial) ou um Hub onde é configurada uma pequena rede entre os dois servidores, ou até mesmo através de um cabo cross (em último caso).

Algumas pessoas, baseadas no fato de que hoje as redes das empresas costumam ter uma boa estrutura, terminam deixando de lado essa boa prática, mas acreditem, ela deve ser seguida, pois ninguém quer problemas com a conexão de banco de dados enquanto alguém copia um arquivo grande pela rede, por exemplo.

Agora o ponto em questão é, e se eu já tenho meu Database Mirror configurado, sem uma conexão dedicada entre o Principal e o Mirror, e desejo realizar tal alteração sem tem de refazer todo o mirror ou causar uma parada no serviço?

Vamos ver então como realizar esse procedimento!

Antes de iniciar o procedimento, devemos configurar nossa rede dedicada entre os dois servidores do Mirror. Digamos que você adicionou uma nova placa de rede em cada um dos servidores e os conectou através de um cabo cross, só para falar do procedimento mais “simples”.

Considerando que os IPs configurados foram:

Principal: 192.168.1.1

Mirror: 192.168.1.2

Agora devemos tornar esses IPs “visíveis” para os dois servidores. Para isso temos duas formas:

1) Registrar o DNS das novas placas de rede (recomendável)

2) Adicionar o nome FQDN das duas placas nos arquivos Hosts de ambos os servidores.

Vou considerar aqui a segunda forma. Você deve abrir um NOTEPAD como administrador (botão direito sobre o NOTEPAD -> Executar como administrador), clicar no botão para abrir arquivos, navegar até a pasta “C:\Windows\System3\Drivers\etc”, na caixa de “tipo de arquivo” configurar para exibir “Todos os arquivos” e então selecionar o arquivo “hosts”.

Ao final do arquivo você deve adicionar os registros dos nomes/IPs da seguinte forma:

192.168.1.1 ALGUM_NOME_PARA_PRINCIPAL.DOMINIO.COM

192.168.1.2 ALGUM_NOME_PARA_MIRROR.DOMINIO.COM

Após isso é bom fazer um ping do PRINCIPAL para o MIRROR e vice-versa, utilizando esses IPs/nomes para testar e é sempre recomendável reiniciar os servidores após essa operação, sempre que possível.

Agora, com a rede dedicada configurada, vamos ao processo no SQL Server.

O primeiro passo é evitar os acessos da aplicação ao servidor de banco de dados. Sei que muitos vão falar “mas isso vai parar o serviço!”, mas considerando que essa alteração é rápida e você pode realizá-la em um horário de manutenção essa seria a forma mais rápida.

Caso você não possa parar o serviço, o procedimento será mais lento, pois você terá que refazer todo o mirror provavelmente, pois enquanto estiver realizando alterações em um dos servidores, o outro estará recebendo atualizações e ao tentar reativar o mirror a operação não será possível.

Com os acessos ao servidor já bloqueados de alguma forma, o segundo passo é parar os Endpoints nos dois servidores, utilizando o comando abaixo:

ALTER ENDPOINT NOME STATE = STOPPED

Lembre, esse comando deve ser executado tanto no PRINCIPAL como também no MIRROR!

O terceiro passo é alterar o IP dos Endpoints para os IPs de nossas placas de rede dedicadas.

Para isso devemos executar o seguinte comando, em ambos os servidores:

ALTER ENDPOINT NOME AS TCP(LISTENING_IP = (192.168.1.X))

Onde o valor de X vai variar dependendo se o comando está sendo executado no PRINCIPAL ou no MIRROR.

Aqui uma observação. No meu ambiente tive problemas ao limitar o IP do Endpoint durante a configuração e tive que liberar para aceitar qualquer IP (tanto no PRINCIPAL como no MIRROR):

ALTER ENDPOINT NOME AS TCP(LISTENING_IP = ALL)

mas pelo que pesquisei, depois de terminada a configuração do Mirror é só executar o comando anterior para voltar ao IP desejado (não pude alterar em meu ambiente).

O quarto passo é reativar os Endpoints com o comando abaixo (novamente em ambos os servidores):

ALTER ENDPOINT NOME STATE = STARTED

O quinto passo é reativar o mirror, definindo o partner no MIRROR:

ALTER DATABASE NOME SET PARTNER = ‘TCP://ALGUM_NOME_PARA_PRINCIPAL.DOMINIO.COM:PORTA’

e no PRINCIPAL:

ALTER DATABASE NOME SET PARTNER = ‘TCP://ALGUM_NOME_PARA_MIRROR.DOMINIO.COM:PORTA’

Com isso seu Database Mirror já deve estar ativo e com o tráfego do PRINCIPAL para o MIRROR ocorrendo através da rede dedicada.

Caso precise adicionar um WITNESS, basta executar o comando abaixo:

ALTER DATABASE BANCO SET WITNESS = ‘TCP://NOME_WITNESS.DOMINIO.COM:PORTA’

O sexto é último passo é a validação do ambiente. Para isso eu utilizo o velho NETSTAT para verificar as conexões entre os servidores, normalmente com o comando abaixo (em uma janela do DOS):

NETSTAT -NAO -P TCP

E então vejo se está havendo tráfego na porta configurada entre os dois servidores, através do IP da rede dedicada.

Outra forma de validar é utilizando a interface gráfica de configuração do Mirror no SSMS. Aqui vale um aviso. Se você configurou utilizando o arquivo HOSTS, quando estiver com o banco ativo no Servidor01, verá na GUI ele sendo referenciado pelo seu nome “original” e o outro servidor, Servidor02, através do nome do arquivo HOSTS (ALGUM_NOME_PARA_MIRROR.DOMINIO.COM:PORTA) e o contrário quando estiver com o banco ativo no Servidor02. Pelo menos foi isso que aconteceu no meu ambiente.

Penso eu que quando os nomes forem registrados no DNS isso não deve ocorrer, mas não tenho como testar atualmente (se alguém testar me diz depois o resultado!). De qualquer forma com o NETSTAT não restará nenhuma dúvida.

Agora é só testar seu ambiente, preferencialmente realizando failovers entre os dois servidores e testando as conexões com o mesmo, e confiar em um ambiente mais seguro.

Fontes utilizadas nesse artigo ou que podem ajudar na implementação:

Esse post foi publicado em Artigos, Virtual PASS BR. Bookmark o link permanente.

4 respostas para Alterando Database Mirroring para utilizar uma placa de rede dedicada

  1. Parabéns pelo artigo Vladimir, muito bom.

  2. ericksonricci disse:

    Gostei, Best Practice!😉

  3. Pingback: Implementando Espelhamento de Banco de Dados (Database Mirror) « Alex Souza

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s