SQL Server: Top Tips for SQL Server Clustering

Artigo
08/19/2016

SQL Server

Dicas ótimas para o agrupamento do SQL Server

Tom Moreau, PhD

Visão geral:

Executando o SQL Server em um cluster
Requisitos de hardware e software
Armazenando um nó em cluster
Opções econômicas

Um cluster de servidor permite conectar vários servidores físicos, ou nós, que atuam como parceiros de failover entre si. A redundância fornecida por um cluster resulta em mais tempo de atividade para operações

críticas. Implementei vários clusters durante os meus 13 anos de trabalho com o SQL Server™ e cada um tinha a sua própria série de problemas. Essa experiência permitiu a coleta de várias dicas que podem ajudar a facilitar e a favorecer o sucesso dos esforços de armazenamento em cluster.

Os clusters de servidores têm a vantagem dos recursos integrados de armazenamento em cluster das edições Enterprise da família do Windows Server®. De fato, para finalidades de armazenamento em cluster, o Windows Server 2003 é significativamente melhor que o Windows 2000 Advanced Server. Para maximizar os benefícios que serão obtidos com o armazenamento em cluster, você precisará do hardware certo e isso envolve certos gastos. Não basta juntar alguns servidores com um disco compartilhado e você não pode depender do fato de que componentes de hardware individuais possam estar no Windows® Catalog (anteriormente conhecido como Lista de compatibilidade de hardware). O sistema como um todo deve estar no Windows Catalog. Mas, não se preocupe, pois estão disponíveis algumas soluções de cluster econômicas aprovadas. A Figura 1 mostra uma configuração típica de cluster.

Figure 1 A typical cluster

Figure 1** A typical cluster **(Clique na imagem para aumentar a exibição)

É claro que o armazenamento em cluster envolve muito mais do que hardware. Você também precisa escolher a edição correta do SQL Server 2005. A Enterprise Edition habilita o armazenamento em cluster, bem como outros recursos úteis, como a capacidade de utilizar mais CPUs, modos de exibição distribuídas e atualizáveis, transporte integrado de logs e uso automático de modos de exibição indexados. Se uma licença do Enterprise Edition já estiver disponível, considere o armazenamento em cluster, independentemente de você ter os dois a oito servidores necessários para formar um cluster tradicional (conversaremos sobre clusters de um nó em alguns instantes). Se você tiver o SQL Server 2005 Standard Edition, poderá instalar um cluster de dois nós.

O Windows Server 2003 Enterprise Edition e o Windows Server 2003 Datacenter Edition acompanham um armazenamento em cluster integrado. Tudo o que precisa ser feito é executar o Administrador de Cluster para configurar o seu cluster. Você pode adicionar todos os nós de uma vez ou pode adicionar um por vez. De forma semelhante, ao instalar o SQL Server, você pode optar por instalar um servidor individual não armazenado em cluster ou pode instalar uma instância virtual em um cluster. Se você optar por instalar uma instância virtual, poderá instalar em todos os nós do cluster, em apenas alguns nós ou até mesmo em apenas um nó.

Por fim, para alcançar a verdadeira meta do armazenamento em cluster (a alta disponibilidade), você precisa de pessoas qualificadas e procedimentos bem pesquisados a serem seguidos no caso de problemas. Embora o armazenamento em cluster seja uma boa garantia contra falhas de hardware, ele não impede erros de usuários, como a eliminação de uma tabela crítica por um DBA mentalmente esgotado no meio da madrugada.

Clusters de um nó

Mesmo que você precise apenas de um servidor no momento, considere a criação de cluster de um nó. Isso lhe dá a opção de atualizar para um cluster mais tarde, o que evita uma operação de reconstrução. Apenas se certifique de que o hardware escolhido esteja na parte de cluster do Windows Catalog.

Não é exclusivamente por questões de alta disponibilidade que a opção de adicionar um nó posteriormente pode vir a ser desejável. Considere o que aconteceria se você descobrisse que o seu servidor simplesmente não possui a capacidade necessária. Isso significa a necessidade de migração, o que exige tempo e esforços. Se você tiver um cluster de um nó, a migração será mais fácil e o tempo de inatividade será muito menor. Basta adicionar o novo nó ao cluster, adicionar os binários e os service packs do SQL Server ao novo nó e fazer failover no novo nó. Em seguida, adicione as atualizações disponibilizadas após o lançamento do service pack e, por fim, remova o nó antigo. O tempo de inatividade corresponde apenas ao tempo necessário para fazer o failover e adicionar as atualizações (se houver).

Adicionando nós

Como todos os nós em um cluster devem ser iguais, convém agir o mais rápido possível, em vez de tarde demais, para obter esse nó extra. Se você esperar muito tempo, o nó poderá sair de produção. Em um projeto, tive que reconstruir um nó em um cluster SQL Server 2000. O administrador da rede/sistema operacional estava lidando com a criação básica da máquina, quando entrei em ação para adicioná-la de volta ao cluster e prepará-la para operação como um nó do SQL Server. Tudo estava indo bem, até o momento de fazer failover para o novo nó. Para meu espanto, ocorreu um processo direto de failback. Para encurtar a história, embora eu tivesse preparado um documento detalhado sobre a criação de um novo cluster, incluindo a adição das contas de serviço de cluster e de serviço do SQL Server a ambos os nós, o documento não foi seguido explicitamente. O administrador não havia adicionado essas contas de serviço ao nó recriado e, portanto, os privilégios que elas tinham antes da reconstrução deixaram de existir.

Demorou muito tempo para fazer esse rastreamento. Um certo dia, tive a idéia de observar uma associação de grupo local. Após a adição das duas contas, o failover ocorreu sem maiores problemas. Então, comecei a ponderar. A recriação de um nó é algo que não é feito freqüentemente e, se o for, é apenas em caso de emergência. Embora eu tivesse um documento apropriado, ele não foi usado. Poderíamos ter automatizado a parte de segurança simplesmente gravando um breve script para adicionar essas contas e fazer todas as outras personalizações necessárias. Apesar disso, os recursos do SQL Server 2005 foram aprimorados. O instalador exige a definição de grupos em nível de domínio para as contas de serviço do SQL Server.

É claro que isso me fez pensar ainda mais. Você pode criar scripts que chama CLUSTER.EXE para adicionar o nó ao cluster do MSCS (Microsoft® Cluster Server). Tudo o que precisa ser feito é inserir no script o nome do nó para que esse script possam manipular o restante do processo. Em caso de emergências, a automação é realmente muito benéfica.

Clusters N+1

Às vezes, o motivo para a adição de um nó em um cluster não é a substituição de um nó. Você pode estar adicionando mais instâncias do SQL Server ao cluster, e cada uma delas precisa de recursos de disco à parte. Embora várias instâncias possam ser executadas em um único nó, elas compartilhariam a CPU e a RAM, podendo resultar em fraco desempenho. Teoricamente, apenas uma instância deve ser executada em um único nó. Como garantir isso no momento do failover? Simples: a resposta é que um nó não possui serviços em execução, enquanto cada um dos outros executa uma instância do SQL Server. De fato, essa é a definição de um cluster N+1: N instâncias em execução em N+1 nós. O nó extra é o backup.

Atualizando o SQL Server

A atualização de uma instância em cluster do SQL Server não é uma tarefa simples: ela está armazenada em cluster por um motivo, que é a necessidade de tempo de atividade. Mas, o SQL Server 2005 oferece vários aprimoramentos que valem a pena aproveitar e, pois isso, se e quando a atualização for necessária, você poderá proceder sem muito tempo de inatividade.

Quais são as suas opções? Em primeiro lugar, examinaremos a solução mais cara: a criação de um cluster totalmente novo, significando novos servidores e talvez uma nova SAN (rede de armazenamento). É provavelmente possível manter os comutadores de rede existentes, mas isso é tudo. É óbvio que essa abordagem não é barata, mas tem as suas vantagens. Em geral, novos componentes de hardware apresentam um desempenho melhor que os antigos, com capacidade de disco e velocidade cada vez maiores em um ritmo sempre crescente. Portanto, você terá um grande aumento no desempenho simplesmente com novos componentes de hardware. É possível até mesmo alugar os seus equipamentos apenas para se manter em uma posição melhor.

Quando o hardware adequado estiver preparado, será possível criar um novo SQL Server virtual nessa configuração, copiar os bancos de dados de produção e então inserir o novo sistema no seu próprio ritmo, possibilitando tempo suficiente para eliminar os bugs antes do dia da transição. Apenas lembre-se de criptografar os logins a partir do servidor existente. (Consulte support.microsoft.com/kb/246133. Também é aconselhável atualizar o script de criação de login para o caso de uma falha catastrófica.)

Para minimizar o tempo de inatividade, será provavelmente necessário usar o transporte de logs, a menos que os bancos de dados sejam bem pequenos e você tenha um período de tempo durante o qual nenhum usuário esteja conectado. É possível fazer o transporte de logs logo antes da transição. Depois, desconecte os usuários, recorte e transporte o log final e então aponte o aplicativo para a nova instância. (Verifique a seção de espelhamento de banco de dados a seguir para conhecer uma alternativa interessante para o transporte de logs.) Se você usar aliases de DNS, provavelmente não precisará nem mesmo apontar os aplicativos para a nova instância. Basta atualizar o alias de DNS. Essa abordagem tem a vantagem de que, se você chegar à metade do caminho da migração e tiver que reverter para o original, terá pelo menos esse original.

É possível seguir uma rota mais econômica, mas isso requer um planejamento mais antecipado. Um cluster pode suportar mais de uma instância do SQL Server, mas cada uma deve ter os seus próprios recursos de disco. Portanto, se você subdividindo a sua SAN, reserve um LUN para uma atualização futura. Para fazer a atualização, instale os binários do SQL Server nesse recurso de disco. Você pode testar o sistema e, quando estiver pronto, desligar o SQL Server atual, mover os recursos de disco a partir do grupo antigo do SQL Server, atualizar as dependências e colocar online a nova instância do SQL Server. Conecte os bancos de dados a partir da instância antiga e você está pronto para colocar tudo em operação. (Você já fez o backup antecipado de todos os dados, certo?)

Essa é a abordagem mais econômica, mas apresenta alguns riscos. Se algo der errado, não será possível desconectar os bancos de dados da nova instância e recolocá-los em operação. Você apenas poderá fazer restaurações de backups, o que pode envolver um sério tempo de inatividade.

Uma alternativa é colocar duas instâncias do SQL Server na SAN, supondo que haja espaço suficiente. Restaure os backups de produção (e o transporte de logs) para a nova instância e proceda exatamente como descrito anteriormente. Entretanto, existe agora um fallback. Após a migração, você poderá liberar os recursos da SAN da instância antiga. Os custos desse processo são alguns discos extras.

Balanceamento de carga

Vamos começar derrubando um mito comum. O armazenamento em cluster do MSCS é usado para alta disponibilidade e não para balanceamento de carga. Além disso, o SQL Server não tem recursos integrados e automáticos de balanceamento de carga. É necessário fazer o balanceamento de carga por meio do design físico do seu aplicativo. O que isso significa?

Conforme o crescimento de uma tabela, haverá uma certa degradação do desempenho, especialmente quando verificações de tabela entrarem em jogo. Quando você alcançar milhões ou bilhões de linhas, a solução tradicional será o uso de modos de exibição particionados, que são compostos de tabelas com esquemas idênticos vinculados por meio de instruções UNION ALL. Além disso, restrições CHECK são efetivadas para diferenciar as tabelas-membro, o que evita a duplicação de dados na visualização particionada. Se a coluna usada na restrição CHECK também fizer parte da chave primária, o modo de exibição poderá ser atualizado.

Se as tabelas-membro estiverem em seus próprios grupos de arquivos, será possível melhorar o desempenho se os arquivos nesses grupos estiverem em unidades físicas separadas. As tabelas podem estar até mesmo em bancos de dados separados. Entretanto, no SQL Server 2005, desde que todos os dados estejam no mesmo banco de dados, você poderá usar o particionamento de tabelas, que é muito mais fácil de implementar.

Digamos que você tenha feito o melhor possível com o particionamento de tabelas ou com os modos de exibição particionados (locais), mas o desempenho ainda esteja lento. Se tiver o SQL Server 2000 ou o SQL Server 2005, será possível usar modos de exibição particionados distribuídos. A principal diferença é que as tabelas-membro podem residir em instâncias diferentes do SQL Server e essas instâncias podem ser instaladas em um cluster N+1. Por que é uma boa idéia? Se qualquer tabela-membro for colocada offline em um modo de exibição particionado, esse modo de exibição inteiro ficará offline. Por isso, tornar esses membros parte de um cluster proporciona a segurança necessária para favorecer o desempenho e fornecer balanceamento de carga.

Você precisa realmente de um cluster?

Talvez existam alguns servidores sobressalentes disponíveis, mas eles não estão no Windows Catalog para clusters. É uma pena ter que comprar novos servidores unicamente para dar suporte a um cluster quando já existem servidores disponíveis.

O espelhamento de bancos de dados pode ser uma alternativa atraente para o armazenamento em cluster. O espelhamento envolve três elementos: uma instância que hospeda o banco de dados espelhado é conhecida como principal, o servidor de backup é conhecido como o espelho e, se você quiser failover automático, um terceiro servidor, conhecido como testemunha, será necessário. Em resumo, uma transação em um banco de dados no principal é executada novamente no espelho. Se o principal falhar, o failover do banco de dados poderá ocorrer no espelho, automaticamente se você tiver uma testemunha. É necessário configurar o espelhamento para cada um dos bancos de dados de aplicativos, mas não é possível espelhar bancos de dados do sistema.

O espelho é uma instância à parte do SQL Server, ao contrário de um cluster, e pode estar localizado a milhares de quilômetros de distância. Seus caches são preenchidos pela atividade de atualização que ocorre como resultado das transações duplicadas a partir do principal. Suponha, é claro, que não haja atividade no espelho além do recebimento de transações espelhadas do principal. O failover será geralmente mais rápido do que em um cluster, pois o SQL Server já está em execução no espelho. Como os caches estão pelo menos parcialmente preparados, o desempenho inicial não é tão lento como seria em um cenário em cluster. E, observe que, quando ocorre o failover de um banco de dados espelhado, as funções do principal e do espelho são invertidas.

A desvantagem do espelhamento de bancos de dados é a necessidade de duplicar a capacidade total de disco em comparação a um cluster. Você também precisará de mais potência de CPU se preferir o modo de sincronização sem perda de dados. Como já disso, a alta disponibilidade não é barata.

Uma abordagem combinada

Como um espelho pode estar localizado remotamente do principal, ele é uma boa opção para planos de DR (recuperação após desastres). Seu cluster pode ser sua primeira linha de defesa, mas o que acontecerá se você usar técnicas de armazenamento em cluster e de espelhamento? Em um failover de cluster, se você tiver uma testemunha como parte da configuração de espelhamento, o espelho se tornará o principal enquanto o SQL Server estiver entrando online. Entretanto, observe que o failover a partir do novo principal de volta para o novo espelho (em cluster) não é automático. Consequentemente, convém não habilitar o failover automático para bancos de dados espelhados quando eles forem usados em conjunto com um cluster.

A DR não é o único motivo para se usar o espelhamento. Ela também é útil caso você precise aplicar um service pack ou um hotfix ao principal, em cujo caso é possível fazer o failover manualmente para o espelho. Ao aplicar o service pack ou o hotfix, o servidor principal antigo está temporariamente offline e as transações confirmadas que ocorrem no novo principal são colocadas em fila, aguardando para serem enviadas de volta ao novo espelho (principal antigo). Após a conclusão da instalação do service pack ou do hotfix, a sincronização ocorrerá e, com o tempo, os dois servidores estarão completamente em sincronia. Agora, você poderá alternar as funções do principal e do espelho. O tempo de inatividade correspondeu a alguns segundos para o failover e o failback. Essa abordagem pode ser usada para migrar o SQL Server para outra máquina. Apenas não faça o failback.

O servidor virtual adiciona flexibilidade

A virtualização permite executar um ou mais sistemas operacionais simultaneamente em um único servidor físico. O software de virtualização adiciona outra camada de recursos ao conceito de cluster, pois você pode armazenar o software em cluster. Conseqüentemente, se o servidor no qual o host está em execução falhar, ele e seus sistemas operacionais convidados farão failover em um nó de backup. Essa seria uma forma muito fácil de migrar um servidor convidado. Além disso, o sistema operacional convidado não precisa estar habilitado para cluster. Portanto, seria possível executar o SQL Server Workgroup Edition dentro de um Windows Server 2003 convidado, em execução no Microsoft Virtual Server 2005 em um cluster. Indiretamente, você armazenou em cluster basicamente o Workgroup Edition (consulte a Figura 2).

Figure 2 Using a virtual server

Figure 2** Using a virtual server **(Clique na imagem para aumentar a exibição)

No controle

Se você estiver encarregado de uma implementação do SQL Server, convém saber que o servidor sempre está disponível. O armazenamento em cluster do servidor ajuda a garantir que isso sempre acontecerá. Este artigo fornece algumas dicas merecidas para ajudá-lo a dar os primeiros passos e você encontrará mais informações úteis na barra lateral "Recursos de armazenamento em cluster".

Recursos de armazenamento em cluster

Para obter mais informações sobre os métodos usados aqui e os vários produtos necessários para configurar o cluster do SQL Server, consulte:

Tom Moreau, PhD, BSc, PhD, MCSE, MCDBA, é um consultor independente especializado em administração, design e implementação de bancos de dados SQL Server e que trabalha na região de Toronto. Tom usa o SQL Server desde 1993 e é MVP desde 2001. Ele escreveu mais de 100 artigos e participou como co-autor de um livro sobre o SQL Server. Agradecimentos ao MVP do SQL Server Geoff Hiten por essas úteis informações .

Recursos adicionais