Implantação do DBMS de Máquinas de Virtuais do SQL Server Azure para NetWeaver do SAP
Este documento aborda várias áreas diferentes a serem consideradas ao implantar o SQL Server para carga de trabalho do SAP no IaaS do Azure. Como pré-condição para este documento, leia o documento Considerações sobre a implantação do DBMS de Máquinas Virtuais do Azure para de carga de trabalho SAP e outros guias na carga de trabalho SAS na documentação do Azure.
Importante
O escopo deste documento é a versão do Windows no SQL Server. SAP já não suporta a versão do Linux do SQL Server com qualquer um dos software SAP. O documento não está discutindo o Banco de Dados SQL do Microsoft Azure, que é uma oferta de Plataforma como Serviço da Plataforma Microsoft Azure. A discussão neste artigo trata da execução do produto SQL Server como ele é conhecido para implantações locais nas Máquinas Virtuais do Azure, aproveitando a funcionalidade de infraestrutura como serviço do Azure. As funcionalidades e recursos do banco de dados dessas duas ofertas têm muitas diferenças e não devem ser misturados ou confundidas. Para saber mais, confira Banco de Dados SQL do Azure.
Em geral, você deve considerar usar o SQL Server mais recente para executar a carga de trabalho SAP no IaaS do Azure. As versões mais recentes do SQL Server oferecem a melhor integração com alguns dos serviços do Azure e funcionalidade. Ou tem alterações que otimizam as operações em uma infraestrutura de IaaS do Azure.
A documentação geral sobre o SQL Server em execução na VM (Máquinas Virtuais) do Azure pode ser encontrada nestes artigos:
- SQL Server nas Máquinas Virtuais do Azure (Windows)
- Automatizar gerenciamento com a extensão do Agente de IaaS do Windows SQL Server
- Configurar a integração do Azure Key Vault para SQL Server em VMs do Azure (Resource Manager)
- Lista de verificação: melhores práticas do SQL Server nas VMs do Azure
- Armazenamento: melhores práticas de desempenho do SQL Server nas VMs do Azure
- Melhores práticas de configuração de HADR (SQL Server em VMs do Azure)
Nem todo o conteúdo e as instruções feitas no SQL Server geral na documentação da VM do Azure se aplicam à carga de trabalho SAP. Mas, a documentação dá uma boa ideia sobre os princípios. Um exemplo de funcionalidade sem suporte para a carga de trabalho do SAP é o uso do clustering de FCI.
Há algumas informações específicas do SQL Server na IaaS que você deve conhecer antes de continuar:
- Suporte à versão do SQL: mesmo com a Nota SAP #1928533 informando que a versão mínima do SQL Server com suporte é o SQL Server 2008 R2, a janela de versões do SQL Server com suporte no Azure também é determinada com o ciclo de vida do SQL Server. A manutenção estendida do SQL Server 2012 terminou em meados de 2022. Como resultado, a versão mínima atual para sistemas recém-implantados deve ser o SQL Server 2014. Quanto mais recente, melhor. As versões mais recentes do SQL Server oferecem a melhor integração com alguns dos serviços do Azure e funcionalidade. Ou tem alterações que otimizam as operações em uma infraestrutura de IaaS do Azure.
- Usando imagens do Azure Marketplace: A maneira mais rápida de implantar uma nova VM do Microsoft Azure é usar uma imagem do Azure Marketplace. Há imagens no Azure Marketplace que contêm o SQL Server mais recente. As imagens em que o SQL Server já está instalado não podem ser usadas imediatamente para aplicativos SAP NetWeaver. O motivo é que a ordenação padrão do SQL Server é instalada nessas imagens e não na ordenação necessária para sistemas SAP NetWeaver. Para usar essas imagens, verifique as etapas documentadas no capítulo Como usar uma imagem do SQL Server fora do Microsoft Azure Marketplace.
- Suporte do SQL Server de várias instâncias em uma única VM do Azure: esse método de implantação tem suporte. No entanto, esteja ciente das limitações de recursos, especialmente em relação à largura de banda de rede e de armazenamento do tipo de VM que você está usando. Informações detalhadas estão disponíveis no artigo Tamanhos de máquinas virtuais no Azure. Essas limitações de cota podem impedir que você implemente a mesma arquitetura de várias instâncias que você pode implementar no local. A partir da configuração e da interferência de compartilhamento dos recursos disponíveis em uma única VM, as mesmas considerações em relação ao local precisam ser levadas em consideração.
- Vários bancos de dados SAP em uma só instância do SQL Server em uma só VM: há suporte para configurações como essas. As considerações de vários bancos de dados SAP que compartilham os recursos compartilhados de uma única instância de SQL Server são as mesmas para implantações locais. Considere também outros limites, como o número de discos que podem ser anexados a um tipo específico de VM. Ou limites de cota de rede e armazenamento de tipos de VM específicos como Tamanhos para máquinas virtuais no Azure detalhados.
Novas VMs da série M e SQL Server
O Azure lançou algumas novas famílias de SKUs da série M sob a família Mv3. Alguns dos tipos de VM dessa família não devem ser usados para SQL Server, incluindo o SQL Server 2022, sem desabilitar o SMT (Hyperthreading) no sistema operacional Windows Server convidado. O motivo é que o número de nós NUMA apresentados ao sistema operacional Windows Server convidado, que é maior que 64 vCPUs, é muito grande para que o SQL Server consiga acomodar. Ao desabilitar o SMT no sistema operacional Windows Server convidado, o número de vCPUs é reduzido. Assim, o número de vCPUs é inferior a 64 em cada nó NUMA. A forma de desabilitar o SMT é descrita aqui. Os tipos de VM específicos são:
- M176(d)s_3_v3 – desabilite o SMT ou use M176bds_4_v3 ou M176bds_4_v3 como alternativa
- M176(d)s_4_v3 – desabilite o SMT ou use M176bds_4_v3 como alternativa
- M624(d)s_12_v3 – desabilite o SMT ou use M416ms_v2 como alternativa
- M832(d)s_12_v3 – desabilite o SMT ou use M416ms_v2 como alternativa
- M832i(d)s_16_v3 – desabilite o SMT ou use M416ms_v2 como alternativa
Observação
Com alguns dos novos tipos de VM M(b)v3, o uso de armazenamento SSD Premium v1 com cache de leitura pode resultar em taxas de IOPS de leitura e gravação e taxa de transferência mais baixas do que você obteria se não usasse o cache de leitura.
Recomendações sobre a estrutura de VM/VHD para implantações do SQL Server relacionadas ao SAP
De acordo com a descrição geral, o sistema operacional, os executáveis do SQL Server e os executáveis do SAP devem estar localizados ou instalados em discos separados do Azure. Normalmente, a maioria dos bancos de dados do sistema DO SQL Server não são utilizados em um alto nível com a carga de trabalho do SAP NetWeaver. No entanto, os bancos de dados do sistema do SQL Server devem ficar juntos com os outros diretórios do SQL Server em um disco separado do Azure. O SQL Server tempdb deve estar localizado na unidade D:\ não persistida ou em um disco separado.
- Com todos os tipos de VM certificados pelo SAP (consulte Nota SAP #1928533), os dados tempdb e os arquivos de log podem ser colocados na unidade D:\ não persistente.
- Com as versões do SQL Server, em que o SQL Server instala o tempdb apenas com um arquivo de dados, é recomendável usar vários arquivos de dados tempdb. Esteja ciente de que os volumes da unidade D:\ têm tamanhos e funcionalidades diferentes com base no tipo de VM. Para obter tamanhos exatos da unidade D:\ das VMs diferentes, verifique o artigo máquinas virtuais de tamanhos para Windows no Azure.
Essas configurações permitem que o tempdb consuma mais espaço e, mais importante ainda, mais IOPS (operações de E/S por segundo) e largura de banda de armazenamento do que a unidade do sistema é capaz de fornecer. A unidade D:\ não persistente também oferece latência de E/S e taxa de transferência melhores. Para determinar o tamanho adequado de tempdb, é possível verificar os tamanhos de tempdb nos sistemas existentes.
Observação
no caso de você coloca os arquivos de dados tempdb e o arquivo de log em uma pasta na unidade D:\ que você criou, você precisa certificar-se de que a pasta existe após uma reinicialização da VM. Como a unidade D:\ pode ser inicializada logo após uma reinicialização da VM, todas as estruturas de arquivos e diretórios podem ser apagadas. Uma possibilidade de recriar as eventuais estruturas de diretório na unidade D:\ antes do início do serviço do SQL Server está documentada neste artigo.
Uma configuração de VM que executa o SQL Server com um banco de dados SAP e em que os arquivos de log e os dados do tempdb estão na unidade D:\ e no armazenamento Premium do Azure v1 ou v2 teria a seguinte aparência:
O diagrama exibe um caso simples. Como referido no artigo considerações para implantação de DBMS de Máquinas Virtuais do Azure para a carga de trabalho SAP, o número, o tamanho e o tipo dos discos de armazenamento do Azure dependem de diferentes fatores. Mas, em geral, recomendamos:
- Para implantações de intervalos menores e médios, usando um volume grande, que contém os arquivos de dados do SQL Server. O motivo por trás dessa configuração é que é mais fácil lidar com cargas de trabalho de E/S diferentes quando os arquivos de dados do SQL Server não tenham o mesmo espaço livre. Enquanto em implantações grandes, principalmente nas implantações em que o cliente fez uma migração heterogênea de banco de dados para o SQL Server no Azure, usamos discos separados e depois distribuímos os arquivos de dados entre esses discos. Essa arquitetura só é bem-sucedida quando cada disco tem o mesmo número de arquivos de dados, todos os arquivos de dados têm o mesmo tamanho e têm aproximadamente o mesmo espaço livre.
- Use o D:\drive para tempdb, desde que o desempenho seja bom o suficiente. Se a carga de trabalho geral for limitada no desempenho do tempdb localizado na unidade D:\, você precisará mover o tempdb para o armazenamento premium do Azure v1 ou v2 ou disco Ultra, conforme recomendado neste artigo.
O mecanismo de preenchimento proporcional do SQL Server distribui leituras e gravações para todos os arquivos de dados de maneira uniforme, desde que todos os arquivos de dados do SQL Server tenham o mesmo tamanho e tenham o mesmo espaço livre. O SAP no SQL Server oferece o melhor desempenho quando leituras e gravações são distribuídas uniformemente em todos os arquivos de dados disponíveis. Se um banco de dados tiver poucos arquivos de dados ou os arquivos de dados existentes estiverem muito desbalanceados, o melhor método de correção será uma exportação e uma importação de R3load. Uma exportação e importação do R3load envolve tempo de inatividade e só deverá ser feita se houver um problema de desempenho óbvio que precisa ser resolvido. Se os arquivos de dados forem apenas tamanhos moderadamente diferentes, aumente todos os arquivos de dados para o mesmo tamanho e o SQL Server está rebalanceando dados ao longo do tempo. O SQL Server aumentará automaticamente os arquivos de dados uniformemente se o sinalizador de rastreamento 1117 estiver definido ou se o SQL Server 2016 ou superior for usado sem sinalizador de rastreamento.
Especial para VMs da série M
Para a VM da série M do Azure, a latência de gravação nos logs de transação pode ser reduzida, em comparação ao desempenho do armazenamento Premium do Azure v1, ao usar o Acelerador de Gravação do Azure. Se a latência fornecida pelo armazenamento premium v1 estiver limitando a escalabilidade da carga de trabalho SAP, o disco que armazena o arquivo de log de transações do SQL Server poderá ser habilitado para o Acelerador de Gravação. Detalhes podem ser lidos no documento Acelerador de Gravação. O Acelerador de Gravação do Azure não funciona com o armazenamento Premium do Azure v2 e o Disco Ultra. Nos dois casos, a latência é melhor do que a oferecida pelo armazenamento Premium do Azure v1. O Acelerador de Gravação não dá suporte ao SSD Premium v2.
Observação
Com alguns dos novos tipos de VM M(b)v3, o uso de armazenamento SSD Premium v1 com cache de leitura pode resultar em taxas de IOPS de leitura e gravação e taxa de transferência mais baixas do que você obteria se não usasse o cache de leitura.
Formatação dos discos
Para o SQL Server, o tamanho do bloco NTFS para discos contendo arquivos de log e de dados do SQL Server deve ser de 64 KB. Não é necessário formatar a unidade D:\. Essa unidade vem pré-formatada.
Para evitar que a restauração ou a criação de bancos de dados inicialize os arquivos de dados zerando o conteúdo dos arquivos, verifique se o contexto de usuário em que o serviço do SQL Server está em execução tem o direito do usuário Executar tarefas de manutenção de volume. Para obter mais informações, consulte Inicialização instantânea de arquivo do bancos de dados.
SQL Server 2014 e versões mais recentes do SQL Server – Armazenando arquivos de banco de dados diretamente no Armazenamento de Blobs do Azure
O SQL Server 2014 e versões mais recentes abrem a possibilidade para armazenar arquivos de banco de dados diretamente no Armazenamento de Blobs do Azure sem o ‘wrapper’ de um VHD em torno deles. Antes essa funcionalidade era usada para resolver as deficiências do armazenamento em bloco do Azure. No momento, não é recomendável usar esse método de implantação. Escolha o armazenamento Premium do Azure v1, o armazenamento Premium v2 ou o Disco Ultra. Dependendo dos requisitos.
Considerações sobre backup e recuperação para o SQL Server
Ao implantar o SQL Server no Azure, você precisa examinar sua arquitetura de backup. Mesmo que o sistema não seja um sistema de produção, o banco de dados SAP do SQL Server deve ser feito com backup periodicamente. Como o armazenamento do Azure mantém três imagens, um backup agora é menos importante no que diz respeito à compensação de uma falha de armazenamento. O motivo da prioridade para manter um plano de backup e recuperação adequado é importante para que a funcionalidade de recuperação pontual compense erros lógicos/manuais. A meta é usar os backups para restaurar o banco de dados em um determinado ponto no tempo. Ou para usar os backups no Azure para propagar outro sistema com a cópia do backup de banco de dados existente.
Há várias maneiras de fazer backup e restaurar bancos de dados do SQL Server no Azure. Para obter uma boa visão geral e detalhes, leia o documento Backup e restauração do SQL Server em VMs do Azure. O artigo aborda várias possibilidades diferentes.
Como usar imagens do SQL Server do Microsoft Azure Marketplace
A Microsoft oferece VMs no Azure Marketplace, que já contém versões do SQL Server. Para os clientes SAP que necessitam de licenças para o SQL Server e Windows, usar essas imagens pode ser uma oportunidade para cobrir a necessidade de licenças gerando VMs com o SQL Server já instalado. Para usar essas imagens para SAP, as considerações a seguir precisam ser feitas:
- As versões do SQL Server que não são de avaliação acarretam em custos mais elevados do que uma VM ‘Somente Windows’ implantada do Azure Marketplace. Para comparar preços, confira Preços de Máquinas Virtuais do Windows e Preços de Máquinas Virtuais do SQL Server Enterprise.
- Você só pode usar versões do SQL Server, que têm suporte do SAP para seu software.
- A ordenação da instância do SQL Server que é instalada nas VMs oferecidas no Azure Marketplace não é a ordenação que o SAP NetWeaver exige para a instância do SQL Server ser executada. No entanto, você pode alterar a ordenação com as instruções na seção a seguir.
Alterando a ordenação do SQL Server de uma VM Microsoft Windows/SQL Server
Como as imagens do SQL Server no Azure Marketplace não são configuradas para usar a ordenação, que é necessária para aplicativos SAP NetWeaver, ela precisa ser alterada imediatamente após a implantação. Para o SQL Server, esta mudança de ordenação pode ser feita com as etapas a seguir assim que a VM tiver sido implantada e um administrador for capaz de fazer logon nela:
- Abra uma janela Comando do Windows como administrador.
- Altere o diretório para C:\Arquivos de Programas\Microsoft SQL Server\110\Setup Bootstrap\SQLServer2012.
- Execute o comando: Setup.exe /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=MSSQLSERVER /SQLSYSADMINACCOUNTS=
<local_admin_account_name> /SQLCOLLATION=SQL_Latin1_General_Cp850_BIN2<local_admin_account_name> é a conta, definida como a conta de administrador ao implantar a VM pela primeira vez por meio da galeria.
O processo deve levar apenas alguns minutos. Para verificar se a etapa terminou com o resultado correto, execute as seguintes etapas:
- Abra o SQL Server Management Studio.
- Abra uma Janela de Consulta.
- Execute o comando sp_helpsort no banco de dados mestre do SQL Server.
O resultado desejado deve ter uma aparência semelhante a essa:
Latin1-General, binary code point comparison sort for Unicode Data, SQL Server Sort Order 40 on Code Page 850 for non-Unicode Data
Se o resultado for diferente, INTERROMPA a implantação e investigue por que o comando de instalação não funcionou conforme o esperado. A implantação de aplicativos SAP NetWeaver na instância do SQL Server com páginas de código do SQL Server diferentes da mencionada NÃO é compatível com implantações do NetWeaver.
Alta disponibilidade do SQL Server para SAP no Azure
Usando o SQL Server em implantações de IaaS do Azure para SAP, você tem várias possibilidades diferentes para adicionar para implantar a camada de banco de dados altamente disponível. O Azure fornece diferentes SLAs de tempo de vida para uma só VM usando diferentes armazenamentos em bloco do Azure, um par de VMs implantadas em um conjunto de disponibilidade do Azure ou um par de VMs implantadas nas Zonas de Disponibilidade do Azure. Para sistemas de produção, esperamos que você implante um par de VMs em um conjunto de dimensionamento de máquinas virtuais com orquestração flexível em duas zonas de disponibilidade. Confira Comparação de diferentes tipos de implantação para cargas de trabalho do SAP para obter mais informações. Uma VM executa a instância ativa do SQL Server. A outra VM executa a instância passiva
Clustering do SQL Server usando o Servidor de Arquivos de Escalabilidade Horizontal do Windows ou o Disco Compartilhado do Azure
Com o Windows Server 2016, a Microsoft introduziu Espaços de Armazenamento Diretos. Com base na implantação dos Espaços de Armazenamento Diretos, de maneira geral, há suporte para o clustering de FCI do SQL Server. O Azure também oferece os Discos Compartilhados do Azure, que podem ser usados para clustering do Windows. Para a carga de trabalho do SAP, não há suporte para essas opções de HA.
Envio de logs do SQL Server
Uma funcionalidade de alta disponibilidade é o envio de logs do SQL Server. Se as VMs que participam da configuração de HA tiverem uma resolução de nome funcionando, não haverá problemas. A configuração no Azure não é diferente de nenhuma configuração feita localmente em relação à configuração e aos princípios do envio de logs. Detalhes do envio de logs do SQL Server podem ser encontrados no artigo Sobre o envio de logs (SQL Server).
Funcionalidade de envio de log do SQL Server foi mal usada no Azure para alcançar alta disponibilidade dentro de uma região do Azure. No entanto nos seguintes cenários clientes SAP estavam usando o envio de logs com êxito com o Azure:
- Cenários de recuperação de desastre de uma região do Azure em outra região do Azure
- Configuração de uma Recuperação de Desastre local para uma região do Azure
- Cenários de migração local para o Azure. Nesses casos, o envio de logs é usado para sincronizar a nova implantação de banco de dados no Azure com o sistema de produção em andamento local. No momento do corte, a produção é desligada e garante que os últimos backups de log de transações sejam transferidos para a implantação do banco de dados do Azure. Em seguida, a implantação do banco de dados do Azure é aberta para produção.
SQL Server Always On
Como há suporte para Always On no SAP local (confira a Nota da SAP nº 1772688), ele é compatível em combinação com o SAP no Azure. Há algumas considerações especiais sobre a implementação do ouvinte do grupo de disponibilidade do SQL Server (não confundir com o conjunto de disponibilidade do Azure). Portanto, algumas etapas de instalação diferentes são necessárias.
Algumas considerações sobre o uso de um ouvinte de grupo de disponibilidade são:
- O uso de um ouvinte de grupo de disponibilidade é possível apenas com o Windows Server 2012 ou superior como o SO convidado da VM. No Windows Server 2012, verifique se a atualização para habilitar Ouvintes do Grupo de Disponibilidade de SQL Server em máquinas virtuais do Microsoft Azure baseadas no Windows Server 2008 R2 e Windows Server 2012 foi aplicada.
- Para o Windows Server 2008 R2, esse patch não existe. Nesse caso, o Always On precisaria ser usado da mesma forma que o espelhamento de banco de dados. Ao especificar um parceiro de failover na cadeia de conexões (feito por meio do parâmetro default.pfl do SAP dbs/mss/server – Confira a Nota da SAP nº 965908).
- Ao usar um ouvinte do grupo de disponibilidade, as VMs de banco de dados precisam ser conectadas a um balanceador de carga dedicado. Você precisa atribuir endereços IP estáticos aos adaptadores de rede dessas VMs na configuração do Always On (a definição de um endereço IP estático está descrita neste artigo). Endereços IP estáticos em comparação com o DHCP estão impedindo a atribuição de novos endereços IP nos casos em que as duas VMs podem ser interrompidas.
- Há etapas especiais necessárias ao criar a configuração de cluster de WSFC em que o cluster precisa de um endereço IP especial atribuído, pois o Azure com sua funcionalidade atual atribuiria ao nome do cluster o mesmo endereço IP que o nó em que o cluster foi criado. Esse comportamento indica que uma etapa manual deve ser executada para atribuir um endereço IP diferente ao cluster.
- O ouvinte do grupo de disponibilidade será criado no Azure com pontos de extremidade TCP/IP atribuídos às VMs executando as réplicas primária e secundária do grupo de disponibilidade.
- Pode haver a necessidade de proteger esses pontos de extremidade com ACLs.
Lista a documentação detalhada sobre como implantar Always On com o SQL Server em VMs do Azure, como:
- Introdução aos grupos de disponibilidade do AlwaysOn do SQL Server em máquinas virtuais do Azure.
- Configurar um Grupo de Disponibilidade Always On em máquinas virtuais do Azure em diferentes regiões.
- Configurar um balanceador de carga para um grupo de disponibilidade Always On no Azure.
- Melhores práticas de configuração de HADR (SQL Server em VMs do Azure)
Observação
Em Introdução aos grupos de disponibilidade Always On do SQL Server nas máquinas virtuais do Azure, você lerá mais sobre o ouvinte DNN (Nome da Rede Direta) do SQL Server. Essa nova funcionalidade foi introduzida com o SQL Server 2019 CU8. Essa nova funcionalidade torna obsoleto o uso de um balanceador de carga do Azure que está tratando o endereço IP virtual do Ouvinte do Grupo de Disponibilidade.
O SQL Server Always On é a funcionalidade de recuperação de desastre e alta disponibilidade usada mais comumente usada nas implantações de carga de trabalho do Azure para SAP. A maioria dos clientes usa o AlwaysOn para alta disponibilidade em uma única região do Azure. Se a implantação é restrita a apenas dois nós, você terá duas opções de conectividade:
- Usando o Ouvinte do Grupo de Disponibilidade. Com o ouvinte do grupo de disponibilidade, você deve implantar um balanceador de carga do Azure.
- Com o SQL Server 2016 SP3, SQL Server 2017 CU 25 ou SQL Server 2019 CU8 ou versões mais recentes do SQL Server no Windows Server 2016 ou posterior, você pode usar o ouvinte DNN (Direct Network Name) em vez de um Azure Load Balancer. A DNN está eliminando o requisito de uso de um balanceador de carga do Azure.
O uso de parâmetros de conectividade do espelhamento de banco de dados do SQL Server só deve ser considerado para a rodada de investigação de problemas com os outros dois métodos. Nesse caso, você precisará configurar a conectividade dos aplicativos SAP de uma forma em que ambos os nomes de nó sejam nomeados. Os detalhes exatos de tal configuração do lado do SAP estão documentadas na nota do SAP #965908. Ao usar essa opção, você não precisaria configurar um ouvinte do Grupo de Disponibilidade. E com isso, nenhum Azure Load Balancer pode investigar os problemas desses componentes. Mas lembre-se de que essa opção só funcionará se você restringir o grupo de disponibilidade para abranger as duas instâncias.
Muitos clientes estão usando a funcionalidade Always On do SQL Server para recuperação de desastre entre regiões do Azure. Vários clientes também usam a capacidade de executar backups de uma réplica secundária.
Transparent Data Encryption do SQL Server
Muitos clientes estão usando a TDE (Transparent Data Encryption) do SQL Server ao implantar os bancos de dados SAP do SQL Server no Azure. A funcionalidade de TDE do SQL Server é totalmente suportada pelo SAP (consulte a nota SAP #1380493).
Aplicação de TDE do SQL Server
Nos casos em que você executa uma migração heterogênea de outro banco de dados, em execução local, para o Windows/SQL Server em execução no Azure, você deve criar seu banco de dados de destino vazio no SQL Server com antecedência. Na próxima etapa, você aplicaria a funcionalidade de TDE do SQL Server a esse banco de dados vazio. Motivo para executar a essa sequência é que o processo de criptografia de banco de dados vazio pode levar bastante tempo. Os processos de importação do SAP seriam, em seguida, importar os dados para o banco de dados criptografado durante a fase de tempo de inatividade. A sobrecarga da importação para um banco de dados criptografado tem um impacto de tempo menor de forma que criptografar o banco de dados após a fase de exportação a busca fase de tempo. Experiências negativas foram realizadas ao tentar aplicar o TDE com a carga de trabalho do SAP em execução por cima do banco de dados. Portanto, a recomendação é tratar a implementação do TDE como uma atividade que precisa ser executada com uma carga de trabalho SAP pequena ou nula no banco de dados específico. Do SQL Server 2016 em diante, você pode parar e retomar a verificação de TDE que executa a criptografia inicial. O documento TDE (Transparent Data Encryption) descreve o comando e os detalhes.
Nos casos em que você migra bancos de dados SQL Server do SAP locais para o Azure, é recomendável testar qual a infraestrutura em que será possível aplicar a criptografia mais rapidamente. Para isso, tenha estes fatos em mente:
- Você não pode definir quantos threads são usados para aplicar a criptografia de dados no banco de dados. O número de threads é majoritariamente dependente do número de arquivos de log e dados do SQL Server são distribuídos ao longo de volumes de disco. Significa que quanto mais volumes distintos (letras de unidade), mais threads são envolvidos em paralelo para executar a criptografia. Essa configuração contradiz um pouco com sugestão de configuração de disco anterior sobre a criação de um ou um número menor de espaços de armazenamento para arquivos de banco de dados do SQL Server em VMs do Azure. Uma configuração com alguns volumes fará com que alguns threads executem a criptografia. Um único thread com a criptografia está lendo as extensões de 64 KB, criptografando-as e, em seguida, gravando um registro no arquivo de log de transações, informando que a extensão foi criptografada. Como resultado, a carga no log de transações é moderada.
- Nas versões mais antigas do SQL Server, a compactação de backup não obteve mais eficiência quando você criptografou o banco de dados do SQL Server. Esse comportamento poderia ocasionar um problema quando o plano era criptografar seu banco de dados SQL Server local e, em seguida, copiar um backup no Azure para restaurar o banco de dados no Azure. A compactação de backup do SQL Server pode atingir uma taxa de compactação de fator 4.
- No SQL Server 2016, foi introduzida uma nova funcionalidade que também permite a compactação de bancos de dados criptografados de modo eficiente. Confira este blog para mais detalhes.
Como usar o Azure Key Vault
O Azure oferece o serviço de uma Key Vault para armazenar chaves de criptografia. SQL Server no outro lado oferece um conector para usar o Azure Key Vault como repositório para os certificados TDE.
Lista de mais detalhes para usar o Azure Key Vault para a TDE do SQL Server, como:
- Configurar a integração do Azure Key Vault para o SQL Server em VMs do Azure (Resource Manager).
- Mais perguntas dos clientes sobre o SQL Server Transparent Data Encryption – TDE + Azure Key Vault.
Importante
Usando a TDE do SQL Server, principalmente com o Azure Key Vault, é recomendável aplicar os patches mais recentes dos SQL Servers 2014, 2016 e 2017. Razão é que com base nos comentários dos clientes, as otimizações e correções são aplicadas ao código. Por exemplo, verifique KBA #4058175.
Configurações mínimas de implantação
Nesta seção, sugerimos um conjunto mínimo de configurações para diferentes tamanhos de bancos de dados na carga de trabalho SAP. É muito difícil avaliar se esses tamanhos se encaixam na sua carga de trabalho específica. Em alguns casos, podemos ser generosos na memória em comparação com o tamanho do banco de dados. Por outro lado, o dimensionamento do disco pode ser muito baixo para algumas das cargas de trabalho. Portanto, essas configurações devem ser tratadas como realmente são. Elas são configurações iniciais. Configurações para ajustar a carga de trabalho específica e os requisitos de eficiência de custo.
Um exemplo de configuração para uma pequena instância do SQL Server com um tamanho de banco de dados entre 50 GB e 250 GB seria assim:
| Configuração | VM do banco de dados | Comentários |
|---|---|---|
| Tipo de VM | E4s_v3/v4/v5 (4 vCPU/32 GiB de RAM) | |
| Rede Acelerada | Habilitar | |
| Versão do SQL Server | SQL Server 2019 ou mais recente | |
| Número de arquivos de dados | 4 | |
| Número de arquivos de log | 1 | |
| Número de arquivos de dados temporários | 4 ou padrão desde o SQL Server 2016 | |
| Sistema operacional | Windows Server 2019 ou mais recente | |
| Agregação de disco | Espaços de Armazenamento se desejado | |
| Sistema de arquivos | NTFS | |
| Tamanho do bloco de formato | 64 KB | |
| nº e tipo de discos de dados | Armazenamento Premium v1: 2 x P10 (RAID0) Armazenamento Premium v2: 2 x 150 GiB (RAID0) – IOPS padrão e taxa de transferência ou SSD Premium equivalente v2 |
Cache = Somente leitura para armazenamento Premium v1 |
| nº e tipo de discos de log | Armazenamento Premium v1: 1 x P20 Armazenamento Premium v2: 1 x 128 GiB – IOPS padrão e taxa de transferência ou SSD Premium equivalente v2 |
Cache = NENHUM |
| Parâmetro de memória máxima do SQL Server | 90% da RAM física | Presumindo instância única |
Um exemplo de configuração ou de instância pequena do SQL Server com um tamanho de banco de dados entre 250 GB e 750 GB, como um sistema SAP Business Suite menor, seria assim:
| Configuração | VM do banco de dados | Comentários |
|---|---|---|
| Tipo de VM | E16s_v3/v4/v5 (16 vCPU/128 de GiB RAM) | |
| Rede Acelerada | Habilitar | |
| Versão do SQL Server | SQL Server 2019 ou mais recente | |
| Número de arquivos de dados | 8 | |
| Número de arquivos de log | 1 | |
| Número de arquivos de dados temporários | 8 ou padrão desde o SQL Server 2016 | |
| Sistema operacional | Windows Server 2019 ou mais recente | |
| Agregação de disco | Espaços de Armazenamento se desejado | |
| Sistema de arquivos | NTFS | |
| Tamanho do bloco de formato | 64 KB | |
| nº e tipo de discos de dados | Armazenamento Premium v1: 4 x P20 (RAID0) Armazenamento Premium v2: 4 x 100 GiB – RAID0 (200 GiB) – IOPS padrão e taxa de transferência extra de 25 MB/s por disco ou SSD Premium equivalente v2 |
Cache = Somente leitura para armazenamento Premium v1 |
| nº e tipo de discos de log | Armazenamento Premium v1: 1 x P20 Armazenamento Premium v2: 1 x 200 GiB – IOPS padrão e taxa de transferência ou SSD Premium equivalente v2 |
Cache = NENHUM |
| Parâmetro de memória máxima do SQL Server | 90% da RAM física | Presumindo instância única |
Um exemplo de configuração ou de instância média do SQL Server com um tamanho de banco de dados entre 750 GB e 2.000 GB, como um sistema SAP Business Suite médio, seria assim:
| Configuração | VM do banco de dados | Comentários |
|---|---|---|
| Tipo de VM | E64s_v3/v4/v5 (64 vCPU/432 GiB de RAM) | |
| Rede Acelerada | Habilitar | |
| Versão do SQL Server | SQL Server 2019 ou mais recente | |
| nº de dispositivos de dados | 16 | |
| nº de dispositivos de log | 1 | |
| Número de arquivos de dados temporários | 8 ou padrão desde o SQL Server 2016 | |
| Sistema operacional | Windows Server 2019 ou mais recente | |
| Agregação de disco | Espaços de Armazenamento se desejado | |
| Sistema de arquivos | NTFS | |
| Tamanho do bloco de formato | 64 KB | |
| nº e tipo de discos de dados | Armazenamento Premium v1: 4 x P30 (RAID0) Armazenamento Premium v2: 4 x 250 GiB – 500 GiB – mais 2.000 IOPS e taxa de transferência de 75 MB/s por disco ou SSD Premium equivalente v2 |
Cache = Somente leitura para armazenamento Premium v1 |
| nº e tipo de discos de log | Armazenamento Premium v1: 1 x P20 Armazenamento Premium v2: 1 x 400 GiB – IOPS padrão e taxa de transferência extra de 75MB/s ou SSD Premium equivalente v2 |
Cache = NENHUM |
| Parâmetro de memória máxima do SQL Server | 90% da RAM física | Presumindo instância única |
Um exemplo de configuração ou de instância maior do SQL Server com um tamanho de banco de dados entre 2.000 GB e 4.000 GB, como um sistema SAP Business Suite maior, seria assim:
| Configuração | VM do banco de dados | Comentários |
|---|---|---|
| Tipo de VM | E96(d)s_v5 (96 vCPUs/672 GiB de RAM) | |
| Rede Acelerada | Habilitar | |
| Versão do SQL Server | SQL Server 2019 ou mais recente | |
| nº de dispositivos de dados | 24 | |
| nº de dispositivos de log | 1 | |
| Número de arquivos de dados temporários | 8 ou padrão desde o SQL Server 2016 | |
| Sistema operacional | Windows Server 2019 ou mais recente | |
| Agregação de disco | Espaços de Armazenamento se desejado | |
| Sistema de arquivos | NTFS | |
| Tamanho do bloco de formato | 64 KB | |
| nº e tipo de discos de dados | Armazenamento Premium v1: 4 x P30 (RAID0) Armazenamento Premium v2: 4 x 500 GiB – 800 GiB – mais 2500 IOPS e taxa de transferência de 100 MB/s por disco ou SSD Premium equivalente v2 |
Cache = Somente leitura para armazenamento Premium v1 |
| nº e tipo de discos de log | Armazenamento Premium v1: 1 x P20 Armazenamento Premium v2: 1 x 400 GiB – mais 1.000 IOPS e taxa de transferência extra de 75MB/s ou SSD Premium equivalente v2 |
Cache = NENHUM |
| Parâmetro de memória máxima do SQL Server | 90% da RAM física | Presumindo instância única |
Um exemplo de configuração de uma instância grande do SQL Server com um tamanho de banco de dados de mais de 4 TB, como o sistema SAP Business Suite grande usado em escala global, seria assim:
| Configuração | VM do banco de dados | Comentários |
|---|---|---|
| Tipo de VM | Série -M (1.0 to 4.0 TB RAM) | |
| Rede Acelerada | Habilitar | |
| Versão do SQL Server | SQL Server 2019 ou mais recente | |
| nº de dispositivos de dados | 32 | |
| nº de dispositivos de log | 1 | |
| Número de arquivos de dados temporários | 8 ou padrão desde o SQL Server 2016 | |
| Sistema operacional | Windows Server 2019 ou mais recente | |
| Agregação de disco | Espaços de Armazenamento se desejado | |
| Sistema de arquivos | NTFS | |
| Tamanho do bloco de formato | 64 KB | |
| nº e tipo de discos de dados | Armazenamento Premium v1: mais de 4 x P40 (RAID0) Armazenamento Premium v2: 4+ x 1.000 GiB - 4.000 GiB - mais 4.500 IOPS e taxa de transferência de 125 MB/s por disco ou SSD Premium equivalente v2 |
Cache = Somente leitura para armazenamento Premium v1 |
| nº e tipo de discos de log | Armazenamento Premium v1: 1 x P30 Armazenamento Premium v2: 1 x 500 GiB – mais 2.000 IOPS e taxa de transferência de 125 MB/s ou SSD Premium equivalente v2 |
Cache = NENHUM |
| Parâmetro de memória máxima do SQL Server | 95% da RAM física | Presumindo instância única |
Por exemplo, essa configuração é a configuração de VM de banco de dados de um SAP Business Suite no SQL Server. Essa VM hospeda o banco de dados de 30 TB da única instância global do SAP Business Suite de uma empresa global com mais de USD 200 bilhões de receita anual e mais de 200 mil funcionários em tempo integral. O sistema executa todo o processamento financeiro, vendas e processamento de distribuição e muitos outros processos empresariais de diferentes áreas, incluindo a folha de pagamento norte-americana. O sistema está em execução no Azure desde o início de 2018 usando VMs da série M do Azure como VMs de banco de dados. Como alta disponibilidade, o sistema está usando Always On com uma réplica síncrona em outra Zona de Disponibilidade da mesma região do Azure. E outra réplica assíncrona em outra região do Azure. A camada de aplicativo NetWeaver é implantada nas famílias de VM D(a)/E(a) mais recentes.
| Configuração | VM do banco de dados | Comentários |
|---|---|---|
| Tipo de VM | M192dms_v2 (192 vCPU/4,196 GiB de RAM) | |
| Rede Acelerada | habilitado | |
| Versão do SQL Server | SQL Server 2019 | |
| Número de arquivos de dados | 32 | |
| Número de arquivos de log | 1 | |
| Número de arquivos de dados temporários | 8 | |
| Sistema operacional | Windows Server 2019 | |
| Agregação de disco | Espaços de Armazenamento | |
| Sistema de arquivos | NTFS | |
| Tamanho do bloco de formato | 64 KB | |
| nº e tipo de discos de dados | Armazenamento Premium v1: 16 x P40 ou SSD Premium equivalente v2 | Cache = Somente leitura |
| nº e tipo de discos de log | Armazenamento Premium v1: 1 x P60 ou SSD Premium equivalente v2 | Usando o Acelerador de Gravação |
| # e tipo de discos tempdb | Armazenamento Premium v1: 1 x P30 ou SSD Premium equivalente v2 | Sem cache |
| Parâmetro de memória máxima do SQL Server | 95% da RAM física |
Resumo geral sobre o SQL Server para SAP no Azure
Há muitas recomendações neste guia e recomendamos que você o leia mais de uma vez antes de planejar sua implantação do Azure. Em geral, porém, siga as principais recomendações do SQL Server em recomendações específicas do Azure:
- Use a versão mais recente do SQLServer, como o SQL Server 2022, que tem mais vantagens no Azure.
- Planeje cuidadosamente sua estrutura de sistema da SAP no Azure para balancear o layout do arquivo de dados e as restrições do Azure:
- Não tenha discos demais, mas tenha espaço suficiente para garantir que você possa atingir seu IOPS necessário.
- Somente divida entre discos se você precisar obter uma maior taxa de transferência.
- Não tenha discos demais, mas tenha espaço suficiente para garantir que você possa atingir seu IOPS necessário.
- Nunca instale o software ou coloque arquivos que exijam persistência na unidade D:\, pois ele não é persistente. Qualquer coisa nessa unidade pode ser perdida em uma reinicialização do Windows ou na reinicialização da VM.
- Use a solução Always On do SQL Server para replicar dados de banco de dados.
- Sempre use a resolução de nome, não confie em endereços IP.
- Usando a TDE do SQL Server, aplique os patches mais recentes do SQL Server.
- Tenha cuidado ao usar imagens do SQL Server do Azure Marketplace. Se você usar o SQL Server um, deverá alterar a ordenação de instância antes de instalar qualquer sistema SAP NetWeaver nele.
- Instale e configure o Monitoramento de Host do SAP para Azure, conforme descrito no Guia de Implantação.
Próximas etapas
Leia o artigo