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 uma pré-condição para este documento, você deve ler o documento Considerações para implantação de DBMS de Máquinas Virtuais do Azure para carga de trabalho do SAP, e outros guias de carga de trabalho do SAP 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 em VMs 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 de carga de trabalho 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 nº 1928533 informando que a versão mínima com suporte do SQL Server é o SQL Server 2008 R2, a janela de versões do SQL Server com suporte no Azure também é ditada pelo 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 do SQL Server padrão é instalada dentro dessas imagens e não a ordenação exigida pelos 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.
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 é utilizada em um alto nível pela 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 certificadas pela SAP (confira a Nota da SAP nº 1928533), dados do tempdb e arquivos de log podem ser colocados na unidade D:\ não persistente.
- Com as versões do SQL Server, nas quais, por padrão, o SQL Server instala o tempdb com um arquivo de dados, recomendamos 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 é limitada em desempenho pelo tempdb localizado na unidade D:\, migre o tempdb para o armazenamento Premium do Azure v1 ou v2 ou para Disco Ultra, conforme a recomendação 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 entregará o melhor desempenho quando leituras e gravações forem 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 tiverem tamanhos só um pouco diferentes, aumente todos os arquivos de dados para o mesmo tamanho e, assim, o SQL Server rebalanceará os dados ao longo do tempo. O SQL Server aumentará os arquivos de dados automaticamente para o mesmo tamanho se o sinalizador de rastreamento 1117 estiver definido ou se o SQL Server 2016 ou superior for usado.
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.
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 mais recente – armazenando arquivos do banco de dados arquivos 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.
Extensão do pool de buffers do SQL Server 2014
O SQL Server 2014 introduziu um novo recurso, chamado Extensão do Pool de Buffers. Essa funcionalidade, embora testada na carga de trabalho SAP no Azure, não ofereceu aprimoramentos na carga de trabalho de hospedagem. Portanto, ele não deve ser considerado
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 hospedado pelo SQL Server precisa ser copiado em 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. A razão de prioridade para manter um plano de backup e recuperação adequado é mais que você pode compensar erros lógicos/manuais fornecendo funcionalidades de recuperação pontual. A meta é usar os backups para restaurar o banco de dados em um determinado ponto no tempo. Ou usar os backups no Azure para propagar outro sistema copiando o 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ê pode usar apenas versões do SQL Server que têm suporte da SAP.
- 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 estão configuradas para usar a ordenação, que é exigida pelos aplicativos SAP NetWeaver, elas precisam ser alteradas 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= /SQLCOLLATION=
<local_admin_account_name> 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 DBMS 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áquina virtual com orquestração flexível em duas zonas de disponibilidade. Consulte a comparação de diferentes tipos de implantação para carga de trabalho SAP para obter mais informações. Uma máquina virtual executará a instância do SQL Server Active Directory. A outra VM executará 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 DBMS no Azure com a produção contínua do sistema local. No momento da substituição, a produção é encerrada e é garantido que os últimos e mais recentes backups de log de transações foram transferidos para a implantação do DBMS do Azure. Em seguida, a implantação de DBMS do Azure é aberta para a 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 DBMS, em execução local, para o Windows/SQL Server em execução no Azure, você deve criar o banco de dados de destino vazio no SQL Server antecipadamente. 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 serão envolvidas 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 DBMS | 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 e taxa de transferência padrão |
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 e taxa de transferência padrão |
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 DBMS | 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 – 200 GiB (RAID0) – IOPS padrão e taxa de transferência extra de 25 MB/s por disco |
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 e taxa de transferência padrão |
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 DBMS | 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 mil IOPS e taxa de transferência de 75 MB/s por disco |
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 de 75 MB/s |
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 DBMS | 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 |
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 mil IOPS e taxa de transferência extra de 75 MB/s |
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 DBMS | 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: 4+ x P40 (RAID0) Armazenamento Premium v2: mais de 4 x 1,000 GiB – 4,000 GiB – Mais 4.500 IOPS e taxa de transferência de 125 MB/s por disco |
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 mil IOPS e taxa de transferência de 125 MB/s por disco |
Cache = NENHUM |
| Parâmetro de memória máxima do SQL Server | 95% da RAM física | Presumindo instância única |
Por exemplo, essa é a configuração de VM do DBMS 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, o processamento de vendas e distribuição e muito mais processos empresariais de diferentes áreas, incluindo a folha de pagamento da América do Norte. O sistema está em execução no Azure desde o início de 2018 usando VMs da série M do Azure como VMs do DBMS. 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 do NetWeaver é implantada em VMs Ev4.
| Configuração | VM do DBMS | 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 | Cache = Somente leitura |
| nº e tipo de discos de log | Armazenamento Premium v1: 1 x P60 | Usando o Acelerador de Gravação |
| # e tipo de discos tempdb | Armazenamento Premium v1: 1 x P30 | 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, no entanto, não se esqueça de seguir os dez principais pontos específicos recomendados do DBMS no Azure gerais:
- Use a versão mais recente do DBMS, como SQL Server 2019, que conta com o máximo de vantagens no Azure.
- Planeje cuidadosamente seu cenário de sistema SAP no Azure para equilibrar 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 nenhum software nem coloque arquivos que exijam persistência na unidade D:\, pois ela não é permanente e tudo nela é perdido em uma reinicialização do Windows ou da VM.
- Use a solução de HA/DR do seu fornecedor do DBMS para replicar dados do 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