• Articles
• admin

Em 9 de julho de 2019, suporte para o SQL Server 2008 e 2008 R2 vai acabar. Isso significa o fim das atualizações de segurança regulares. No entanto, se você mover essas instâncias do SQL Server para Azure ou Azure Stack (eu simplesmente me referirei a ambos como Azure para o resto do guia), a Microsoft fornecerá três anos de atualizações de segurança estendidas sem custo adicional. Se você estiver executando o SQL Server 2008/2008 R2 e não conseguir atualizar para uma versão posterior do SQL Server antes do prazo de 9 de Julho, você desejará aproveitar esta oferta em vez de correr o risco de enfrentar uma futura vulnerabilidade de segurança. Uma instância não corrigida do SQL Server pode levar a perda de Dados, tempo de inatividade ou uma violação de dados devastadora.

um dos desafios que você enfrentará ao executar o SQL Server 2008/2008 R2 no Azure é garantir alta disponibilidade. No local, você pode estar executando uma instância do cluster de Failover do SQL Server (FCI) para alta disponibilidade ou, possivelmente, você está executando o SQL Server em uma máquina virtual e está confiando no VMware HA ou em um cluster do Hyper-V Para disponibilidade. Ao mudar para o Azure, nenhuma dessas opções está disponível. O tempo de inatividade no Azure é uma possibilidade muito real de que você deve tomar medidas para mitigar.

para mitigar a possibilidade de tempo de inatividade e se qualificar para os 99,95% ou 99 do Azure.99% SLA, você tem que alavancar SIOS DataKeeper. O DataKeeper supera a falta de armazenamento compartilhado do Azure e permite que você crie um SQL Server FCI no Azure que aproveita o armazenamento anexado localmente em cada instância. SIOS DataKeeper não só suporta o SQL Server 2008 R2 e Windows Server 2008 R2, conforme documentado neste manual, suporta qualquer versão do Windows Server 2008 R2 através do Windows Server 2019 e qualquer versão do SQL Server a partir do SQL Server 2008 através do SQL Server 2019.

este guia examinará o processo de criação de uma instância de Cluster de Failover do SQL Server 2008 R2 de dois nós (FCI) no Azure, em execução no Windows Server 2008 R2. Embora o SIOS DataKeeper também ofereça suporte a clusters que abrangem zonas ou regiões de disponibilidade, este guia assume que cada nó reside na mesma região do Azure, mas em domínios de falha diferentes. O SIOS DataKeeper será usado no lugar do armazenamento compartilhado normalmente necessário para criar um SQL Server 2008 R2 FCI.

pré-requisitos

Active Directory
este guia assume que você tem um domínio do Active Directory existente. Você pode gerenciar seus próprios controladores de domínio ou usar os Serviços de domínio do Azure Active Directory. Para este tutorial, nos conectaremos a um domínio chamado contoso.local. Claro que você se conectará ao seu próprio domínio ao seguir este tutorial.

portas de Firewall abertas
– SQL Server:1433 para instância padrão– 6102>– Load Balancer Health Probe: 59999
– DataKeeper: essas regras de firewall são adicionadas ao firewall baseado no host do Windows automaticamente durante a instalação. Para obter detalhes sobre quais portas são abertas, consulte a documentação do Sios.
– lembre-se de que, se você tiver alguma segurança baseada em rede que bloqueie portas entre os nós do cluster, também precisará contabilizar essas portas.

conta de Serviço DataKeeper
crie uma conta de domínio. Especificaremos essa conta quando instalarmos o DataKeeper. Essa conta precisará ser adicionada ao grupo Administradores Locais em cada nó do cluster.

Crie a primeira instância do SQL Server no Azure

este guia aproveitará a imagem do SQL Server 2008r2sp3 no Windows Server 2008R2 publicada no Azure Marketplace.

ao provisionar a primeira instância, você terá que criar um novo conjunto de disponibilidade. Durante este processo, certifique-se de aumentar o número de Domínios de falha para 3. Isso permite que os dois nós de cluster e a testemunha de compartilhamento de arquivos residam em seu próprio domínio de falha.

Se você não tiver uma rede virtual configurado, permitir que o assistente de criação para criar uma nova para você.

depois que a instância for criada, vá para as configurações de IP e torne o endereço IP privado estático. Isso é necessário para o SIOS DataKeeper e é a melhor prática para instâncias agrupadas.

certifique-se de que sua rede virtual esteja configurada para definir o servidor DNS como um controlador de anúncios local do Windows para garantir que você possa ingressar no domínio em uma etapa posterior.

depois que as máquinas virtuais forem provisionadas, adicione pelo menos dois discos adicionais a cada instância. Premium ou Ultra SSD são recomendados. Desative o Cache nos discos usados para os arquivos de log SQL. Habilite o Cache somente leitura no disco usado para os arquivos de dados SQL. Consulte as Diretrizes de desempenho do SQL Server em máquinas virtuais do Azure para obter informações adicionais sobre as melhores práticas de armazenamento.

Crie a 2ª instância do SQL Server no Azure

siga os mesmos passos acima, exceto certifique-se de colocar esta instância na mesma rede virtual e conjunto de disponibilidade que você criou com a 1ª instância.

crie uma instância de testemunha de compartilhamento de arquivos (FSW)

para que o cluster de Failover do Windows Server (WSFC) funcione de maneira ideal, é necessário criar outra instância do Windows Server e colocá-la no mesmo conjunto de disponibilidade que as instâncias do SQL Server. Ao colocá-lo no mesmo conjunto de disponibilidade, você garante que cada nó do cluster e o FSW residam em domínios de falha diferentes, garantindo que seu cluster permaneça on-line caso um domínio de falha inteiro fique off-line. Essas instâncias não requerem SQL Server, pode ser um servidor Windows simples, pois tudo o que precisa fazer é hospedar um compartilhamento de arquivo simples.

esta instância hospedará a testemunha de compartilhamento de arquivos exigida pelo WSFC. Esta instância não precisa ter o mesmo tamanho, nem requer que discos adicionais sejam anexados. Seu único objetivo é hospedar um simples compartilhamento de arquivos. Na verdade, pode ser usado para outros fins. No meu ambiente de laboratório, meu FSW também é meu controlador de domínio.

desinstalar o SQL Server 2008 R2

cada uma das duas instâncias do SQL Server provisionadas já tem o SQL Server 2008 R2 instalado nelas. No entanto, eles são instalados como instâncias autônomas do SQL Server, não instâncias agrupadas. O SQL Server deve ser desinstalado de cada uma dessas instâncias antes que possamos instalar a instância do cluster. A maneira mais fácil de fazer isso é executar a configuração SQL como mostrado abaixo.

quando você executa a configuração.exe / Action-RunDiscovery você verá tudo o que está pré-instalado

setup.exe /Action=RunDiscovery

executando a configuração.exe /Action=Desinstalar /CARACTERÍSTICAS=SQL,COMO,RS,É,Ferramentas /INSTANCENAME=MSSQLSERVER começa o processo de desinstalação

setup.exe /Action=Uninstall /FEATURES=SQL,AS,RS,IS,Tools /INSTANCENAME=MSSQLSERVER

Executando o programa de instalação.exe / Action-RunDiscovery confirma a desinstalação concluída

setup.exe /Action-RunDiscovery

execute este processo de desinstalação novamente na 2ª instância.

adicionar instâncias ao Domínio

todas essas três instâncias precisarão ser adicionadas a um domínio do Windows. Conforme mencionado na seção Pré-requisitos, você deve ter acesso para ingressar em um Windows Active Directory existente. No nosso caso, estamos aderindo a um domínio chamado contoso.local.

Adicionar o Windows Recurso de Cluster de Failover

O Recurso de Cluster de Failover precisa ser adicionado para as duas instâncias do SQL Server

Add-WindowsFeature Failover-Clustering

Instale Conveniência do Update Rollup para o Windows Server 2008 R2 SP1

Há uma atualização crítica ( kb2854082) que é necessário para configurar um Windows Server 2008 R2 instância no Azure. Essa atualização e muito mais estão incluídos na atualização Rollup conveniência para Windows Server 2008 R2 SP1. Instale esta atualização em cada uma das duas instâncias do SQL Server.

Formato de Armazenamento

discos adicionais que foram anexados, quando as duas instâncias do SQL Server foram provisionadas devem ser formatados. Faça o seguinte para cada volume em cada instância.

as práticas recomendadas da Microsoft, diz o seguinte…

“NTFS tamanho da unidade de alocação: Ao formatar o disco de dados, é recomendável que você use um tamanho de unidade de alocação de 64 KB para arquivos de dados e log, bem como TempDB.”

execute a validação do Cluster

execute a validação do cluster para garantir que tudo esteja pronto para ser agrupado.

Import-Module FailoverClustersTest-Cluster -Node "SQL1", "SQL2"

seu relatório conterá avisos sobre armazenamento e rede. Você pode ignorar esses avisos, pois sabemos que não há discos compartilhados e existe apenas uma única conexão de rede entre os servidores. Você também pode receber um aviso sobre a ordem de ligação à rede que também pode ser ignorada. Se você encontrar algum erro, você deve abordá-lo antes de continuar.

erro ao tentar executar a validação do Cluster?

encontrei este erro em algumas ocasiões e ainda estou tentando resolver em que Condições isso ocorre. Ocasionalmente, você descobrirá que o cluster de teste não é executado conforme descrito na postagem do fórum.

Test-ClusterUnable to Validate a Cluster Configuration. The operation has failed. The action validate a configuration did not completeThere is an error in XML document (5, 73). Attempt by methodMicrosoft.Xml.Serialzation.GeneratedAssembly.XmlSerialzationReaderClusterPrep.Config.Read4_As...Bolean) to access methodMS.Internal.ServerClusters.Validation.TestAssemblyCollection.Add(MS.Internal.ServerClusters.V....Failed

se isso acontecer com você, encontrei a seguinte correção recomendada na postagem do fórum funciona para mim.

Inside C:\Windows\System32\WindowsPowerShell\v1.0 make a copy of powershell_ise.exe.config file (make a copy inside C:\Windows\System32\WindowsPowerShell\v1.0)- rename it to powershell.exe.configOpen it with notepad- delete current config line and paste:<?xml version="1.0" encoding="utf-8" ?><configuration> <system.xml.serialization> <xmlSerializer useLegacySerializerGeneration="true"/> </system.xml.serialization></configuration>- save and run test-cluster

embora essa correção permita que você execute test-cluster do Powershell, descobri que executar Validate através da GUI ainda gera um erro, mesmo com essa correção. Eu tenho uma consulta na Microsoft para ver se eles têm uma solução, mas por enquanto, se você precisar executar a validação de cluster, talvez seja necessário usar Test-Cluster no Powershell.

as melhores práticas para criar um cluster no Azure seriam usar o Powershell para criar um cluster, especificando um endereço IP estático. O Powershell nos permite especificar um endereço IP estático, enquanto o método GUI não. Infelizmente, a implementação do DHCP pelo Azure não funciona bem com o WSFC, portanto, se você usar o método GUI, acabará com um endereço IP duplicado como o endereço IP do Cluster que precisará ser corrigido antes que o cluster seja utilizável.

no entanto, o que descobri é que o comando típico do powershell de novo Cluster com o comando-StaticAddress não funciona. Para evitar o problema do endereço IP duplicado, temos que recorrer ao cluster.utilitário exe e execute o seguinte comando.

cluster /cluster:cluster1 /create /nodes:"sql1 sql2" /ipaddress:10.0.0.100/255.255.255.0

Adicionar a Testemunha de Compartilhamento de arquivos

em seguida, precisamos adicionar a Testemunha de Compartilhamento de Arquivo. No terceiro servidor, provisionamos como FSW, crie uma pasta e compartilhe-a como mostrado abaixo. Você precisará conceder as permissões de leitura/gravação do objeto de nome do Cluster (CNO) nos níveis de compartilhamento e segurança, conforme mostrado abaixo.

depois que o compartilhamento for criado, execute o Assistente Configurar Quorum do Cluster em um dos nós do cluster e siga as etapas ilustradas abaixo.

Instalar DataKeeper

Instalar DataKeeper em cada um dos dois nós de cluster do SQL Server, como mostrado abaixo.

é aqui que especificaremos a conta de domínio que adicionamos a cada um do grupo Administradores de domínio local.

Configurar DataKeeper

uma Vez DataKeeper é instalado em cada um dos dois nós de cluster, você está pronto para configurar DataKeeper.

nota-o erro mais comum encontrado nas etapas a seguir está relacionado à segurança, na maioria das vezes por grupos de segurança pré-existentes do Azure que bloqueiam as portas necessárias. Consulte a documentação do SIOS para garantir que os servidores possam se comunicar pelas portas necessárias.

primeiro você deve se conectar a cada um dos dois nós.

se tudo estiver configurado corretamente, você deverá ver o seguinte no Relatório de Visão Geral do servidor.

em seguida, crie um Novo Emprego e siga as etapas ilustradas abaixo

Escolha Sim aqui para registrar o DataKeeper Volume de recursos Disponíveis para o Armazenamento de

Completar os passos acima para cada um dos volumes. Depois de terminar, você deve ver o seguinte na interface do usuário do WSFC.

agora você está pronto para instalar o SQL Server no cluster.

nota-neste ponto, o volume replicado só está acessível no nó que atualmente hospeda armazenamento disponível. Isso é esperado, então não se preocupe!

Instale o SQL Server no primeiro nó

se você deseja fazer o script da instalação, incluí o exemplo abaixo de uma instalação de cluster com script do SQL Server 2008 R2 no primeiro nó do cluster. O script para adicionar um nó ao cluster existente é encontrado mais abaixo no Guia.

claro ajustar para o seu ambiente.

c:\SQLServerFull\setup.exe /q /ACTION=InstallFailoverCluster /FEATURES=SQL /INSTANCENAME="MSSQLSERVER" /INSTANCEDIR="C:\Program Files\Microsoft SQL Server" /INSTALLSHAREDDIR="C:\Program Files\Microsoft SQL Server" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxxx" /SQLDOMAINGROUP="contoso\SQLAdmins" /AGTDOMAINGROUP="contoso\SQLAdmins" /SQLCOLLATION="SQL_Latin1_General_CP1_CI_AS" /FAILOVERCLUSTERGROUP="SQL Server 2008 R2 Group" /FAILOVERCLUSTERDISKS="DataKeeper Volume E" "DataKeeper Volume F" /FAILOVERCLUSTERIPADDRESSES="IPv4;10.0.0.101;Cluster Network 1;255.255.255.0" /FAILOVERCLUSTERNETWORKNAME="SQL2008Cluster" /SQLSYSADMINACCOUNTS="contoso\admin" /SQLUSERDBLOGDIR="E:\MSSQL10.MSSQLSERVER\MSSQL\Log" /SQLTEMPDBLOGDIR="F:\MSSQL10.MSSQLSERVER\MSSQL\Log" /INSTALLSQLDATADIR="F:\MSSQL10.MSSQLSERVER\MSSQLSERVER" /IAcceptSQLServerLicenseTerms

se você preferir usar a GUI, basta acompanhar as capturas de tela abaixo.

no primeiro nó, execute a configuração do SQL Server.

escolha nova instalação de Cluster de Failover do SQL Server e siga as etapas conforme ilustrado.

Escolha somente as opções que você precisa.

observe que este documento assume que você está usando a instância padrão do SQL Server. Se você usar uma instância nomeada, precisará bloquear a porta que ela escuta e usar essa porta mais tarde ao configurar o balanceador de carga. Você também precisará criar uma regra de balanceador de carga para o serviço de navegador do SQL Server (UDP 1434) para se conectar a uma instância nomeada. Nenhum desses dois requisitos é coberto neste guia, mas se você precisar de uma instância nomeada, ela funcionará se você fizer essas duas etapas adicionais.

Aqui você precisará especificar um endereço IP não utilizado

Ir para os Diretórios de Dados do guia e realocar os arquivos de dados e log. No final deste guia, falamos sobre a realocação do tempdb para um volume de DataKeeper não espelhado para um desempenho ideal. Por enquanto, mantenha-o em um dos discos agrupados.

Instale o SQL Server no segundo nó

Abaixo está um exemplo de comando que você pode executar para adicionar um adicional de SQL Server 2008 R2 nó em um cluster existente.

c:\SQLServerFull\setup.exe /q /ACTION=AddNode /INSTANCENAME="MSSQLSERVER" /SQLSVCACCOUNT="contoso\admin" /SQLSVCPASSWORD="xxxxxxxxx" /AGTSVCACCOUNT="contoso\admin" /AGTSVCPASSWORD="xxxxxxxx" /IAcceptSQLServerLicenseTerms

se você preferir usar a GUI, siga as seguintes capturas de tela.Execute a configuração do SQL Server novamente no segundo nó e escolha Adicionar Nó a um Cluster de Failover do SQL Server.

Congratulations, você está quase pronto! No entanto, devido à falta de Suporte do Azure para ARP gratuito, precisaremos configurar um balanceador de carga interno (ILB) para ajudar no redirecionamento do cliente, conforme mostrado nas etapas a seguir.

atualize o endereço IP do Cluster SQL

para que o ILB funcione corretamente, você deve executar o seguinte comando de um dos nós do cluster. Ele SQL Cluster IP permite que o endereço IP do Cluster SQL responda ao probe de integridade do ILB e, ao mesmo tempo, defina a máscara de sub-rede como 255.255.255.255 para evitar conflitos de endereço IP com o probe de integridade.

cluster res <IPResourceName> /priv enabledhcp=0 address=<ILBIP> probeport=59999 subnetmask=255.255.255.255

NOTA – não sei se é uma questão de sorte, mas na ocasião eu tiver de executar este comando, e parece que ele é executado, mas não concluir o trabalho e eu para executá-lo novamente. A maneira que posso dizer se funcionou é olhando para a máscara de sub-rede do recurso IP do SQL Server, se não for 255.255.255.255, então você sabe que não foi executado com sucesso. Pode ser simples um problema de atualização da GUI, então você também pode tentar reiniciar a GUI do cluster para verificar se a máscara de sub-rede foi atualizada.

depois de executado com sucesso, pegue o recurso offline e coloque-o de volta online para que as alterações entrem em vigor.

Crie o balanceador de carga

a etapa final é criar o balanceador de carga. Neste caso, estamos assumindo que você está executando a instância padrão do SQL Server, ouvindo na porta 1433.

o endereço IP privado que você define ao criar o balanceador de carga será exatamente o mesmo endereço que seu SQL Server FCI usa.

adicione apenas as duas instâncias do SQL Server ao pool de back-end. Não adicione o FSW ao pool de back-end.

neste regra de balanceamento de carga você deve habilitar o IP Flutuante

Validar o Cluster

Antes de continuar, execute a validação de cluster mais uma vez. O Relatório de Validação de Cluster deve retornar apenas os mesmos avisos de rede e armazenamento que fez na primeira vez que você o executou. Supondo que não haja novos erros ou avisos, seu cluster está configurado corretamente.

editar sqlserv.arquivo de configuração exe

no diretório C:\Program arquivos(x86) \ Microsoft SQL Server \ 100 \ Ferramentas \ Binn criamos um sqlps.exe.arquivo de configuração e sqlservr.exe.config com as seguintes linhas no arquivo de configuração:

<configuration> <startup> <supportedRuntime version="v2.0.50727"/> </startup></configuration>

esses arquivos, por padrão, não existirão e podem ser criados. Se este(S) arquivo (s) já existir para a sua instalação, a linha <supportedRuntime version=”v2.0.50727″/> simplesmente precisa ser colocada com a seção <startup>…</startup> da seção <configuration>…</configuration>. Isso deve ser feito em ambos os servidores.

teste o Cluster

o teste mais simples é abrir o SQL Server Management Studio no nó passivo e conectar-se ao cluster. Se você é capaz de se conectar, parabéns, você fez tudo correto! Se você não puder se conectar, não tenha medo, você não seria a primeira pessoa a cometer um erro. Eu escrevi um artigo de blog para ajudar a solucionar o problema. Gerenciar o cluster é exatamente o mesmo que gerenciar um cluster de armazenamento compartilhado tradicional. Tudo é controlado por meio do Gerenciador de Cluster de Failover.

opcional-Relocate Tempdb

para um desempenho ideal, seria aconselhável mover tempdb para o SSD local, não replicado. No entanto, o SQL Server 2008 R2 requer que o tempdb esteja em um disco em cluster. O sios tem uma solução chamada recurso de Volume Não espelhado que aborda esse problema. Seria aconselhável criar um recurso de volume não espelhado da unidade SSD local e mover o tempdb para lá. No entanto, a unidade SSD local não é persistente, portanto, você deve tomar cuidado para garantir que a pasta que contém tempdb e as permissões nessa pasta sejam recriadas sempre que o servidor for reinicializado.