Implantações com alta disponibilidade do SQL Server usando o Amazon FSx for NetApp ONTAP

Ao implantar uma carga de trabalho de missão crítica, é de suma importância garantir que todos os componentes estejam altamente disponíveis. Os clientes que optam por usar o SQL Server em suas cargas de trabalho de missão crítica podem obter alta disponibilidade implantando o SQL Server Always On. O SQL Server Always On pode ser implantado em duas configurações principais: Always On Failover Cluster Instances (FCI) e Always On Availability Groups (AGs).

Neste blog, vamos nos concentrar em como implantar Failover Cluster Instances do SQL Server Always On (Always On FCIs). Até agora, a maneira mais simples e econômica de implantar Always On FCIs na AWS era usar o Amazon FSx for Windows File Server para a camada de armazenamento compartilhado. Mas na AWS, estamos sempre procurando mais maneiras de atender às necessidades de nossos clientes. Para esse fim, lançamos recentemente o Amazon FSx for NetApp ONTAP (FSx for ONTAP) como uma solução de armazenamento de arquivos totalmente gerenciada, altamente confiável, escalável, de alto desempenho e rica em recursos, criada no popular sistema de arquivos ONTAP da NetApp. O FSx for ONTAP fornece acesso multiprotocolo aos dados usando NFS, SMB e iSCSI para sistemas Windows e Linux.

Um cluster Always On FCI permite que você execute uma instância do SQL Server em vários nós do Windows Server Failover Cluster (WSFC). A instância SQL está ativa em um único nó do cluster e, em caso de falha, a propriedade da instância SQL e de todos os recursos associados são transferidos para outro nó no WSFC. O armazenamento compartilhado é necessário para habilitar essa configuração. Um dos principais benefícios dessa configuração é que ela remove a necessidade de fazer upgrade do SQL Standard para o SQL Enterprise apenas para oferecer suporte a Always On AGs. Além disso, como o SQL Server FCI fornece proteção no nível da instância, todas as alterações administrativas (como criar e gerenciar logins e usuários) e de agendamento (jobs e agendamentos do SQL Agent) são automaticamente propagadas de instâncias ativas para passivas do FCI no WSFC por meio do armazenamento compartilhado.

SQL Server Always On FCIs suportam o uso de armazenamento compartilhado apresentado por meio de SMB e iSCSI. Para pequenas e médias empresas, os clientes da AWS têm se beneficiado desde 2018 com o uso do FSx para Windows File Server. Com o lançamento do FSx for ONTAP , os clientes também podem optar por usar SMB ou iSCSI no FSx for ONTAP . Neste blog post, explicaremos como configurar um SQL Server Always On FCI com FSx for ONTAP como armazenamento iSCSI compartilhado.

Visão geral da solução

Os sistemas de arquivos do FSx for ONTAP são altamente disponíveis e duráveis nas zonas de disponibilidade (AZs) da AWS e são projetados para fornecer disponibilidade contínua aos dados. Cada sistema de arquivos é alimentado por dois servidores de arquivos em AZs separadas, cada um com seu próprio armazenamento. O Amazon FSx replica automaticamente seus dados entre AZs para protegê-los contra falhas de componentes, monitora continuamente falhas de hardware e substitui automaticamente os componentes da infraestrutura em caso de falha.

O sistema de arquivos do FSx for ONTAP é configurado como Multi-AZ por padrão. Cada sistema de arquivos tem uma subnet preferencial (ativa) e uma subnet em standby (passiva). Em nosso cenário, a zona de disponibilidade A hospeda a subnet preferencial e a zona de disponibilidade B hospeda a subnet em standby. O sistema de arquivos do FSx for ONTAP  fornece endpoints específicos de gerenciamento e protocolo para cada AZ. Seus nós FCI do SQL Server acessam seu sistema de arquivos do FSx for ONTAP  por meio de elastic network interfaces (ENI). Essas interfaces de rede residem na Amazon VPC que você associa ao seu sistema de arquivos. Os clientes acessam o sistema de arquivos do FSx for ONTAP por meio dessas ENIs (Preferred & Standby).

Como boa prática, o nó FCI ativo do SQL Server deve estar na mesma subnet da subnet preferencial do sistema de arquivos do FSx for ONTAP afim de obter a melhor taxa de transferência e a menor latência e evitar tráfego desnecessário na rede Inter-AZ.

No passo a passo a seguir, configuramos um SQL Server FCI de dois nós com FSx for ONTAP, fornecendo armazenamento compartilhado aproveitando o protocolo iSCSI.

Recomendamos configurar os endpoints iSCSI preferenciais e os de standby no lado do cliente (nós FCI do SQL Server) como destinos iSCSI. O driver MPIO reconhece vários caminhos para o armazenamento. As operações de failover e failback são gerenciadas pela política de failover do MPIO e pelo asymmetric logical unit access (ALUA). A política de failover do MPIO deve ser definida como “round robin” para que somente caminhos ativos/otimizados do cliente iSCSI (nós FCI do SQL Server) até o destino iSCSI (sistema de arquivos FSx for ONTAP) sejam usados a qualquer momento.

Figura 1 — Configuração do SQL Server FCI com discos compartilhados iSCSI (FSx for ONTAP )

Considerações Importantes

Ao configurar cargas de trabalho SQL, é importante considerar como você pretende fazer backup de seus bancos de dados. O serviço FSx for ONTAP fornece funcionalidade de backup automatizado, incluindo backups e snapshot integrados. Para simplificar, neste cenário de exemplo, desabilitamos os backups e snapshots automatizados do FSx for ONTAP em favor das ferramentas nativas do SQL. Se você decidir aproveitar o FSx para a funcionalidade avançada de proteção de dados do ONTAP, deverá considerar os requisitos adicionais de armazenamento para backup e snapshot.

O acesso ao sistema de arquivos do FSx for ONTAP é feito pela rede, então você deve escolher uma instância do Amazon Elastic Compute Cloud (Amazon EC2) com desempenho de rede suficiente para suportar sua carga de trabalho. Neste passo a passo, usaremos instâncias r5n.4xlarge como nós FCI do SQL Server. Essa instância do EC2 fornece largura de banda de rede de até 25 Gbps. Ter um tipo e tamanho de instância adequados para sustentar a rede e o tráfego iSCSI é crucial para um desempenho ideal. Como sempre, teste suas cargas de trabalho antes de transferi-las para a produção. Se você tiver requisitos de taxa de transferência de disco especialmente altos (por exemplo, maiores que 1024 MB/s), considere habilitar Jumbo Frames em suas instâncias e configurar sessões iSCSI adicionais para cada destino iSCSI.

Consulte a documentação da NetApp para configurar seu armazenamento com base em seus requisitos de carga de trabalho e desempenho: Guia de melhores práticas para Microsoft SQL Server com ONTAP. Detalhamos as configurações do FSx for ONTAP  na etapa 7 do passo a passo abaixo, junto com os comandos necessários para configurá-las.

Pré-requisitos e configuração básica

Antes de iniciar o passo a passo, certifique-se de ter concluído ou preparado as seguintes etapas/requisitos:

• Microsoft Active Directory e uma conta de usuário do AD com acesso privilegiado para realizar a configuração de instâncias do Windows. Neste passo a passo, usamos o AWS Managed Microsoft AD.
• Os controladores de domínio do Active Directory (AD) devem ter todas as portas necessárias abertas para que os nós do SQL Server ingressem no domínio e se autentiquem no AD.
• Mídia de instalação do Microsoft SQL Server. Para este passo a passo, usamos a edição SQL Server 2019 Developer.
• Criar 2 instâncias do Amazon EC2 Windows Server 2019 em 2 subnets privadas em duas zonas de disponibilidade dentro de uma Virtual Private Cloud (VPC).
• Você pode usar o RDP para se conectar de um servidor jump/bastion às instâncias do nó do cluster ou usar o AWS Systems Manager Fleet Manager.
• Configurar 2 IPs secundários adicionais na mesma ENI para cada nó do cluster (3 IPs no total por instância do EC2).
• Executar o domain join dos nós ao domínio. Verifique se você está conectado usando credenciais de domínio antes de criar e configurar o cluster.
• Configurar as regras de entrada do Security Group e as exceções do Firewall do Windows para permitir que os nós se comuniquem em um ambiente restritivo.
• Determinar os requisitos de espaço de armazenamento (por exemplo, dados, logs, backup e espaço de armazenamento para NetApp ONTAP Snapshot).
• Configurar um sistema de arquivos do FSx for ONTAP. Para este passo a passo, configuramos o FSx for ONTAP  com 2 TB de capacidade de armazenamento SSD, capacidade de transferência de 512 MB/s e 20.000 IOPS provisionados. Consulte a página de desempenho do Amazon FSx for NetApp ONTAP.
• Para esse exemplo de carga de trabalho, configuramos backups usando a tecnologia nativa do SQL Server para separar o armazenamento. Por esse motivo, desativamos os backups automáticos do FSx for ONTAP, conforme discutimos na seção “Considerações Importantes”.

Tabela 1 — Endereços IP usados neste passo a passo

Passo a passo

Avalie os comandos neste passo a passo em um ambiente de teste antes de tentar usá-los em produção.

Configure o sistema de arquivos Amazon FSx for ONTAP e defina as configurações de iSCSI Target

Primeiro, siga as etapas na documentação do FSx for ONTAP para criar um sistema de arquivos. Neste passo a passo, usamos vários scripts e comandos referenciando a FSx for ONTAP storage virtual machine (svm) como sql-svm01. Se você quiser economizar algum tempo, use o mesmo nome para o seu svm. Ao criar o sistema de arquivos do FSx for ONTAP usando a opção de criação padrão, você pode deixar a criação do volume padrão em branco e não precisar fazer o domain join do svm ao AD. Criaremos os volumes ONTAP necessários posteriormente neste passo a passo. Usamos a Default VPC e a tabela de rotas padrão da VPC.

Em seguida, instalamos e configuramos os recursos do Windows necessários para concluir este passo a passo.

1. Conecte-se à sua instância do EC2 usando RDP com uma conta de usuário do AD que tenha permissões locais de administrador em ambos os nós.
2. Em cada instância, instale os recursos necessários (MultiPath-IO, Failover-Clustering, RSAT-AD-Tools, RSAT-DNS-Server) usando o Server Manager ou execute o seguinte comando do PowerShell (executar como administrador):

Install-WindowsFeature RSAT-AD-Tools, RSAT-DNS-Server, Multipath-IO, Failover-Clustering -IncludeManagementTools -Restart

3. Em cada instância, inicie o Microsoft iSCSI Initiator Service e defina o tipo de inicialização como ‘Automatic’ no Services snap-in, ou execute o seguinte comando do PowerShell (executar como administrador):

#Start iSCSI initiator
Start-Service MSiSCSI
Set-Service -Name msiscsi -StartupType Automatic

4. Em cada instância, acesse as propriedades do iSCSI Initiator, escolha a guia de configuração e anote o nome do Initiator ou execute o seguinte comando do PowerShell (executar como administrador):

#Get iSCSI initiator name of cluster nodes
(Get-InitiatorPort).NodeAddress

5. Anote o endereço IP do terminal de gerenciamento no console do FSx for ONTAP.

Figura 2 — Console do FSx for ONTAP — Endereços IP de endpoint do sistema de arquivos

6. Conecte-se ao seu sistema FSx for ONTAP usando SSH (por exemplo, ssh fsxadmin @x.x.x.x no PowerShell). Se você não conseguir acessar seu sistema de arquivos, siga as instruções aqui.
7. Em sua sessão ssh do FSx for ONTAP, use os seguintes comandos para criar um volume, um iGroup, 3 LUNs (Quorum, Dados e Logs) e mapeie esses LUNs para o iGroup. Personalize esses comandos com base em seus próprios requisitos e convenções de nomenclatura. Certifique-se de atualizar os nomes dos iSCSI Initiators abaixo com os que você registrou na etapa 4. O comando será bem-sucedido mesmo se você não atualizar os nomes dos Initiators, mas os nós FCI do SQL Server não conseguirão se conectar ao destino iSCSI.

volume create -vserver sql-svm01 -volume SQLCluster01 -aggregate aggr1 -size 500G -state online -tiering-policy snapshot-only -percent-snapshot-space 0 -autosize-mode grow -snapshot-policy none
volume modify -vserver sql-svm01 -volume SQLCluster01 -fractional-reserve 0
volume modify -vserver sql-svm01 -volume SQLCluster01 -space-mgmt-try-first snap_delete
volume snapshot autodelete modify -vserver sql-svm01 -volume SQLCluster01 -delete-order oldest_first -enabled true
igroup create -igroup SQLCluster01-IG -ostype windows -protocol iscsi -vserver sql-svm01 -initiator iqn.1991-05.com.microsoft:sqlnode1.corp.aws.example.com,iqn.1991-05.com.microsoft:sqlnode2.corp.aws.example.com
lun create -vserver sql-svm01 -volume SQLCluster01 -lun quorum -size 1G -ostype windows_2008
lun create -vserver sql-svm01 -volume SQLCluster01 -lun sqldata01 -size 200G -ostype windows_2008
lun create -vserver sql-svm01 -volume SQLCluster01 -lun sqllogs01 -size 100G -ostype windows_2008
lun map -vserver sql-svm01 -volume SQLCluster01 -lun quorum -igroup SQLCluster01-IG
lun map -vserver sql-svm01 -volume SQLCluster01 -lun sqldata01 -igroup SQLCluster01-IG
lun map -vserver sql-svm01 -volume SQLCluster01 -lun sqllogs01 -igroup SQLCluster01-IG

Esses comandos definem as seguintes configurações:

Tabela 2 — Configuração do ONTAP para a configuração do SQL Server FCI neste passo a passo

Configurar o armazenamento iSCSI e o WSFC no Amazon EC2 Windows

Agora, iniciaremos e configuraremos as instâncias EC2 Windows com conexões e discos iSCSI.

8. Em cada instância EC2, recupere todos os endereços IP (3 IPs por instância do EC2) e anote-os. Esses endereços IP são usados nas etapas subsequentes.
9. Obtenha os endereços IP do endpoint iSCSI (subnet preferencial e subnet de standby) do console FSx for ONTAP. Escolha seu svm (neste passo a passo sql-svm01) na página Storage Virtual Machines. Esses endereços IP são usados como destinos iSCSI na próxima etapa.

Figura 3 — Console FSx for ONTAP — Endereços IP do terminal ISCSI

10. Em cada instância, acesse as configurações do iSCSI Initiator e conecte-se aos seus destinos iSCSI (FSx para endpoints iSCSI ONTAP) ou execute o seguinte script do PowerShell (executar como administrador) — (Substitua os endereços IP pelos que você recuperou na etapa anterior):

#Retrieve iSCSI target endpoint IP Addresses from AWS FSx for ONTAP page.
#IP addresses for Preferred and Standby subnets
$TargetPortalAddresses = @("172.31.10.123","172.31.20.123")
#Primary IP address of EC2 instance recorded in step 1. 
#In our demo this is 172.31.10.100 (SQLnode1) and 172.31.20.100 (SQLnode2). Refer to the diagram above.
$LocaliSCSIAddress = "172.31.10.100"
#Connect to FSx for Netapp ONTAP file system
Foreach ($TargetPortalAddress in $TargetPortalAddresses){
New-IscsiTargetPortal -TargetPortalAddress $TargetPortalAddress -TargetPortalPortNumber 3260 -InitiatorPortalAddress $LocaliSCSIAddress
}
#Add MPIO support for iSCSI
New-MSDSMSupportedHW -VendorId MSFT2005 -ProductId iSCSIBusType_0x9
#Establish iSCSI connection
1..3 | %{Foreach($TargetPortalAddress in $TargetPortalAddresses){Get-IscsiTarget | Connect-IscsiTarget -IsMultipathEnabled $true -TargetPortalAddress $TargetPortalAddress -InitiatorPortalAddress $LocaliSCSIAddress -IsPersistent $true} }
#Set the MPIO Policy to Round Robin
Set-MSDSMGlobalDefaultLoadBalancePolicy -Policy RR

Figura 4 — Propriedades do dispositivo de disco, guia MPIO para LUN conectado via iSCSI

11. Na instância EC2 na Zona de Disponibilidade A, acesse a ferramenta de gerenciamento de disco do Windows e inicialize e formate cada novo disco iSCSI ou execute o seguinte script do PowerShell (executado como administrador):

#Retrieve a list of FSx for ONTAP disks 
$disklist=Get-Disk | Where-Object{$_.FriendlyName -eq 'NETAPP LUN C-MODE'} | Sort-Object -Property Size 
#Create a list of drive letters
$driveletters=@("Q","L","S")
#Initiate, create and format volumes from the list of available FSx for ONTAP disks

foreach($dk in $disklist)
{   
    if(($dk).IsOffline -eq $True){
       Set-Disk -Number ($dk).Number -IsOffline $False

    }
    if(($dk).PartitionStyle -eq 'RAW'){
        Initialize-Disk -Number ($dk).Number -PartitionStyle GPT -ErrorAction SilentlyContinue
    }
    if($dk.IsReadOnly -eq $True){ 
        Set-Disk -Number ($dk).Number -IsReadOnly $False
    }
} 

New-Partition -DiskNumber ($disklist[0]).Number -UseMaximumSize -DriveLetter $driveletters[0] | Format-Volume -FileSystem NTFS -Force -NewFileSystemLabel Quorum
New-Partition -DiskNumber ($disklist[1]).Number -UseMaximumSize -DriveLetter $driveletters[1] | Format-Volume -FileSystem NTFS -AllocationUnitSize 65536 -Force -NewFileSystemLabel SQL-Log
New-Partition -DiskNumber ($disklist[2]).Number -UseMaximumSize -DriveLetter $driveletters[2] | Format-Volume -FileSystem NTFS -AllocationUnitSize 65536 -Force -NewFileSystemLabel SQL-Data 

12. Na instância EC2 na zona de disponibilidade A, configure o WSFC usando o Failover Cluster Manager ou execute o seguinte script do PowerShell (executado como administrador):

Certifique-se de alterar as variáveis $WSFCClusterName e $ClusterNodes para que correspondam ao seu ambiente, além de alterar a variável $ClusterIPs para incluir o primeiro endereço IP secundário de cada nó (registrado na etapa 8). Em nosso passo a passo, o SQLNode1 tem um IP primário de 172.31.10.100 e endereços IP secundários de 172.31.10.101 e 172.31.10.102, portanto, usaremos 172.31.10.101. Usaremos o terceiro endereço IP durante a instalação do SQL Server FCI.

# Populate the cluster node names and set the cluster name for the WSFC
$WSFCClusterName = "WSFC1"
$ClusterNodes = ("SQLNode1", "SQLNode2")
$ClusterIPs = ("172.31.10.101", "172.31.20.101")

# Create a Cluster
New-Cluster -Name $WSFCClusterName -Node $ClusterNodes -AdministrativeAccessPoint ActiveDirectoryAndDNS -StaticAddress $ClusterIPs

# Rename Cluster Resources
$ClusterIPResources = Get-ClusterResource | Where-Object {$_.ResourceType -eq "IP Address"} | Select-Object -ExpandProperty Name
$ClusterIPResources.ForEach( { (Get-ClusterResource -Name "$_").Name = Get-ClusterResource -Name "$_" | Get-ClusterParameter -Name Address | Select-Object -ExpandProperty Value } )
(Get-ClusterGroup "Cluster Group").Name = $WSFCClusterName
(Get-ClusterResource | Where-Object {$_.ResourceType -eq "Network Name" -and $_.OwnerGroup -eq $WSFCClusterName}).Name = $WSFCClusterName

# Set possible owners for IP addresses - each node can only own its own IP
for($i = 0; $i -le 1; $i++){ Get-Cluster -Name $WSFCClusterName | Get-ClusterResource -Name $ClusterIPs[$i] | Set-ClusterOwnerNode -Owners $ClusterNodes[$i] }

# Set dependencies for the cluster name object to be either/or for the node IP addresses
Set-ClusterResourceDependency -Resource $WSFCClusterName -Dependency ("[$($ClusterIPs[0])] or [$($ClusterIPs[1])]")

# Test the cluster
Test-Cluster

Figura 5 — Discos mostrados no Failover Cluster Manager

Instalação do Failover Cluster do SQL Server

13. Execute o SQL Server Setup a partir da mídia de instalação e selecione New SQL Server Failover Cluster Installation. Conclua o assistente de instalação do cluster com os parâmetros de configuração de sua escolha nos dois nós FCI do SQL Server. Aqui, destacamos algumas etapas importantes do processo de instalação.
14. Em Cluster Network Configuration, selecione a linha de endereço IP que corresponde à subnet do nó SQL atual, desmarque a caixa de seleção DHCP e use o terceiro endereço IP dos nós do SQL Server (IP secundário 2 para cada nó da Tabela 1). Em nosso passo a passo, o SQLNode1 está configurado com 172.31.10.102 como o terceiro endereço IP.

Figura 6 — Assistente de instalação de cluster: Configuração de rede de cluster SQLNode1

15. Durante a instalação, você pode escolher a opção “Grant Perform Volume Maintenance Task” para ativar o recurso de inicialização instantânea de arquivos para o SQL Server.

Figura 7 — Assistente de instalação de cluster: Configuração do servidor

Depois de concluir a instalação do primeiro nó do seu cluster SQL FCI, você pode prosseguir e adicionar outros nós ao seu SQL Server FCI.

Limpar

É uma prática recomendada excluir recursos que você não está mais usando para não incorrer em cobranças não intencionais. Você pode limpar os seguintes recursos criados para este tutorial:

• Instâncias do Amazon EC2
• Volumes do Amazon EBS
• Amazon FSx for NetApp ONTAP

Conclusão

Há muitos anos, os clientes implantam Microsoft SQL Always On Failover Cluster Instances no armazenamento on-premises da NetApp com muito sucesso. Com o Amazon FSx for NetApp ONTAP, os clientes agora podem implantar e configurar SQL FCIs em armazenamento totalmente gerenciado criado no sistema de arquivos ONTAP da NetApp na nuvem AWS.

Nesta postagem do blog, explicamos como configurar um sistema de arquivos do FSx for ONTAP, provisionar e otimizar volumes ONTAP, configurar conexões iSCSI e, finalmente, implantar um SQL Server Always On FCI com armazenamento iSCSI compartilhado.

Este artigo foi traduzido do Blog da AWS em Inglês.

Sobre os autores

Andy Ward é Senior Specialist Solutions Architect na AWS, com foco em Workloads Microsoft. Andy trabalha com a tecnologia da Microsoft há mais de 20 anos e ajuda clientes e parceiros a executar, transformar e otimizar suas cargas de trabalho da Microsoft na AWS.

Baris Furtinalar é Senior Solutions Architect que faz parte da equipe de especialistas em arquiteturas Microsoft na AWS. Ele é apaixonado pela computação em nuvem e acredita que essa mudança para a nuvem ajuda as empresas a transformar seus negócios, ganhar agilidade e melhorar a capacidade de resposta operacional. Ele tem uma experiência diversificada, incluindo administração de banco de dados SQL, virtualização e segurança do sistema. Ele projetou, implementou e deu suporte a implantações de servidores Windows/SQL desde 2000.

Tradutores

Bruno Lopes é Senior Solutions Architect no time da AWS LATAM. Trabalha com soluções de TI há mais de 14 anos, tendo em seu portfólio inúmeras experiências em workloads Microsoft, ambientes híbridos e capacitação técnica de clientes como Technical Trainer e Evangelista. Agora atua como um Arquiteto de Soluções, unindo todas as capacidades para desburocratizar a adoção das melhores tecnologias afim de ajudar os clientes em seus desafios diários.

Luciano Bernardes trabalha atualmente como Sr Solutions Architect na AWS, especializado em workloads Microsoft. Com 15 anos de experiência no mercado, trabalhou a maior parte em consultoria técnica especializada em Microsoft, em clientes de várias verticais, com demandas voltadas para infraestrutura on-premises e em nuvem. Como SA, trabalha próximo a clientes e parceiros de consultoria em LATAM e US, para apoiá-los em tomadas de decisão e revisão de arquitetura de workoads Microsoft na nuvem AWS.