Executar SAP HANA no Azure (instâncias grandes)

Essa arquitetura de referência mostra um conjunto de práticas comprovadas para executar o SAP HANA no Azure (Instâncias Grandes) com HA (alta disponibilidade) e DR (recuperação de desastre). Chamada de HLI (Instâncias Grandes do HANA), essa oferta é implantada em servidores físicos em regiões do Azure. Essa solução ilustra um cenário de escala vertical simples para demonstrar conceitos fundamentais na implantação e na operação de um sistema SAP HANA no Azure. Para obter opções, confira outros cenários de instalação para Instâncias Grandes do HANA.

Arquitetura

Baixe um Arquivo Visio dessa arquitetura.

Workflow

Essa arquitetura consiste nos componentes de infraestrutura a seguir.

• Rede virtual. O serviço da Rede Virtual do Azureconecta os recursos do Azure entre si de modo seguro e é subdividido em sub-redes separadas para cada camada. As camadas de aplicativos SAP são implantadas em VMs (máquinas virtuais) do Azure para se conectarem à camada de banco de dados do HANA que reside em instâncias grandes.

• Rede HLI Revision 4.5. A revisão atualizada do HLI Rev 4 foi disponibilizada em julho de 2021. Essa implementação atualizada [rev4.5] inclui muitos aprimoramentos na infraestrutura, como a rede de 100 Gb/s para o armazenamento NFS e melhor redundância de rede do servidor de banco de dados. Nesse design, os servidores HLI são implantados em datacenters do Azure em estreita proximidade física com as VMs do Azure onde os servidores de aplicativos SAP estão sendo executados. Quando usado em conjunto com uma configuração [ExpressRoute FastPath][fastpath], o Rev 4.5 eleva o desempenho do aplicativo. Esses recursos de rede também dão suporte às implantações do Rev 3 e do Rev 4.

• Máquinas Virtuais (VMs) . As VMs são usadas na camada de aplicativo e na camada de serviços compartilhados do SAP. A última inclui uma caixa de atalho usada por administradores para configurar Instâncias Grandes do HANA e fornecer acesso a outras VMs. Para colocar os servidores de aplicativos SAP no mesmo datacenter com as unidades de Instância Grande do HANA, use grupos de posicionamento por proximidade.

• Instância Grande do HANA. Este servidor físico é certificado para atender aos padrões de TDI (Integração de Datacenter Personalizado) do SAP HANA que executa o SAP HANA. Essa arquitetura usa duas Instâncias Grandes do HANA: uma unidade de computação principal e uma secundária. A alta disponibilidade da camada de dados é fornecida por meio da HSR (Replicação de Sistema do HANA).

• Par de alta disponibilidade. Um grupo de folhas das Instâncias Grandes do HANA são gerenciadas em conjunto para fornecer redundância e confiabilidade de banco de dados.

• Microsoft Enterprise Edge (MSEE). O MSEE é um ponto de conexão de um provedor de conectividade ou de seu limite de rede por meio de um circuito ExpressRoute.

• NICs (Placas de interface de rede). Para habilitar a comunicação, o servidor de Instância Grande do HANA fornece quatro NICs virtuais por padrão. Essa arquitetura requer um NIC para comunicação de cliente, um segundo NIC para a conectividade de nó para nó necessário pela HSR, um terceiro NIC para armazenamento de Instância Grande do HANA e um quarto para iSCSI usado no cluster de alta disponibilidade.

• Armazenamento do NFS (Network File System). O servidor de NFS oferece suporte ao compartilhamento de arquivos da rede que fornece a persistência de dados seguros para a Instância Grande do HANA.

• ExpressRoute. O ExpressRoute é o serviço de rede do Azure recomendado para criar conexões privadas entre uma rede local e redes virtuais do Azure que não passam pela Internet pública. As máquinas virtuais do Azure se conectam às Instâncias Grandes do HANA usando outra conexão de ExpressRoute. A conexão de ExpressRoute entre a rede virtual do Azure e as Instâncias Grandes do HANA é configurada como parte da oferta da Microsoft.

• Gateway. O Gateway do ExpressRoute é usado para conectar a rede virtual do Azure usada para a camada de aplicativo do SAP para a rede de Instância Grande do HANA. Use a SKU Alto desempenho ou Ultradesempenho.

• DR (recuperação de desastre). As opções para DR incluem HSR (Replicação de Sistema) do HANA, backup e restauração de arquivos do HANA ou replicação de armazenamento. Após a solicitação, a equipe de Gerenciamento de Serviços da Microsoft pode configurar os servidores de armazenamento e volumes. Você é responsável por agendar o instantâneo de armazenamento, testar o sistema e se familiarizar com o processo de recuperação. Outras considerações se aplicam à camada de aplicativo para SAP NetWeaver e SAP S/4HANA no Azure.

Recomendações

Os requisitos podem variar, portanto, use essas recomendações como ponto de partida.

Computação das Instâncias Grandes do HANA

Instâncias Grandes do HANA são servidores físicos baseados na arquitetura de CPU Intel Broadwell e Cascade Lake e configurados em uma instância grande - isto é, um conjunto específico de servidores ou folhas. Uma unidade de computação é igual a um servidor ou uma folha, e um selo é composto por vários servidores ou folhas. Dentro de um selo de instância grande, os servidores não são compartilhados e são dedicados à execução de uma implantação do SAP HANA do cliente.

Há diversas SKUs disponíveis para Instâncias Grandes do HANA, que oferecem suporte a uma instância única de até 24 TB (expansão para 120 TB) de memória para S/4HANA ou outras cargas de trabalho do SAP HANA.

Escolha uma SKU que atenda aos requisitos de dimensionamento determinados por você nas sessões de arquitetura e design. Verifique sempre se o tamanho se aplica à SKU correta. Os requisitos de recursos e implantação variam por tipo, e a disponibilidade varia de acordo com a região. Também é possível fazer o upgrade de uma SKU para uma maior.

A Microsoft ajuda a estabelecer a configuração de instância grande, mas é sua responsabilidade verificar as definições de configuração do sistema operacional. Verifique se você analisou as Notas SAP mais atuais em relação à sua versão exata do Linux.

Armazenamento

O layout de armazenamento é implementado de acordo com a recomendação da TDI do SAP HANA. As Instâncias Grandes do HANA vêm com uma configuração de armazenamento específica para as especificações de TDI padrão. Contudo, é possível adquirir armazenamento adicional em incrementos de 1 TB.

Para dar suporte aos requisitos de ambientes de missão crítica, incluindo a recuperação rápida, é usado o NFS e não um armazenamento anexado diretamente. O servidor de armazenamento NFS para Instâncias Grandes do HANA é hospedado em um ambiente multilocatário, em que os locatários são segregados e protegidos usando isolamento de computação, rede e armazenamento.

Para dar suporte à alta disponibilidade no site principal, use diferentes layouts de armazenamento. Por exemplo, em uma expansão de vários hosts, o armazenamento é compartilhado. Outra opção de alta disponibilidade é a replicação baseada em aplicativo, como uma HSR. Para a DR, porém, é usada uma replicação de armazenamento baseada em instantâneos.

Rede

Essa arquitetura usa redes físicas e virtuais. A rede virtual faz parte da IaaS (Infraestrutura como serviço) do Azure e conecta-se a uma rede física discreta de Instâncias Grandes do HANA por meio de circuitos do ExpressRoute. Um gateway entre locais conecta suas cargas de trabalho na rede virtual do Azure aos seus sites locais.

Todas as implantações do HANA em Instâncias Grandes desde julho de 2019 usam selos Rev 4, que são implantados próximos aos hosts de VM do Azure usados para os servidores de aplicativos SAP. Como resultado, a implantação do Rev 4 minimiza a latência de rede entre o aplicativo e as camadas de banco de dados.

As redes de Instâncias Grandes do HANA ficam isoladas umas das outras para fins de segurança. As instâncias que residem em diferentes regiões não se comunicam entre si, exceto para a replicação de armazenamento dedicada. Contudo, para usar a HSR, as comunicações entre regiões são necessárias. [Alcance Global do Azure][globalreach], tabelas de roteamento de IP, ou proxies podem ser usados para habilitar a HSR entre regiões.

Todas as redes virtuais do Azure que se conectam às Instâncias Grandes do HANA em uma região podem ser conectadas entre si por meio do ExpressRoute para Instâncias Grandes do HANA em uma região secundária.

O circuito do ExpressRoute para Instâncias Grandes do HANA é incluído por padrão durante o provisionamento. Para a instalação, é necessário um layout de rede específico, incluindo intervalos de endereços de CIDR (Roteamento entre Domínios sem Classificação) necessários e o domínio de roteamento. Para obter mais informações, confira Infraestrutura e conectividade do SAP HANA (Instâncias Grandes) no Azure.

Para reduzir a latência de rede e melhorar o desempenho, considere habilitar o FastPath (também conhecido como MSEE v2). Essa configuração de rede permite que o tráfego do local para a VNet do Azure e da VNet para o HANA em Instâncias Grandes ignore o gateway do Azure.

Considerações

Escalabilidade

Para escalar ou reduzir verticalmente, é possível escolher entre vários tamanhos de servidores que estão disponíveis para Instâncias Grandes do HANA. Eles são categorizados como Tipo I e Tipo II e são adaptados para diferentes cargas de trabalho. Escolha um tamanho que possa crescer junto com a sua carga de trabalho nos próximos três anos. Os compromissos de um ano também estão disponíveis.

Uma implantação escalável de vários hosts geralmente é usada para implantações de BW/4HANA como um tipo de estratégia de particionamento do banco de dados. A partir desta gravação, o BW/4HANA em Instâncias Grandes do HANA pode ser expandido para 120 TB. Para escalar horizontalmente, planeje o posicionamento das tabelas do HANA antes da instalação. Do ponto de vista de infraestrutura, vários hosts estão conectados a um volume de armazenamento compartilhado, permitindo o controle rápido por hosts em espera no caso de um dos nós de trabalho de computação no sistema HANA falhar.

S/4HANA e SAP Business Suite no HANA em uma única folha podem ser escalados verticalmente para até 24 TB, com um único nó de instância. As Instâncias Grandes do HANA e a infraestrutura de armazenamento do Azure também dão suporte a implantações de expansão S/4HANA e BW/4HANA. Para SKUs específicas que são certificadas para expansão, confira o [diretório de hardware certificado pelo SAP][diretório].

Os requisitos de memória para o HANA aumentam conforme o volume de dados aumenta. Use o consumo de memória atual do seu sistema como base para prever o consumo futuro, depois mapeie a demanda de entrada de um dos tamanhos de Instâncias Grandes do HANA.

Caso já tenha as implantações do SAP, ele fornece relatórios que podem ser usados para verificar os dados usados por sistemas existentes e calcular os requisitos de memória para uma instância do HANA. Por exemplo, confira as seguintes Notas do SAP (o acesso requer uma conta do SAP Service Marketplace):

• Nota SAP 1793345 – Dimensionamento do SAP Suite no HANA
• Nota SAP 1872170 – Relatório de dimensionamento do Suite no HANA e S/4 HANA
• Nota SAP 2121330– Perguntas frequentes: relatório de dimensionamento do SAP BW no HANA
• Nota SAP 1736976 – Relatório de dimensionamento do BW no HANA
• Nota SAP 2296290 – Novo relatório de dimensionamento do BW no HANA

Disponibilidade

A redundância de recursos é o tema geral em soluções de infraestrutura altamente disponíveis. Trabalhe junto com o SAP, seu integrador de sistemas ou com a Microsoft para arquitetar e implementar adequadamente uma estratégia de alta disponibilidade e recuperação de desastre. Essa arquitetura segue o (SLA) contrato de nível de serviço do Azure para HANA no Azure (Instâncias Grandes). Para avaliar seus requisitos de disponibilidade, considere todos os pontos únicos de falha, o nível desejado de tempo de atividade para serviços e estas métricas comuns:

• O Objetivo de Tempo de Recuperação (RTO) é a duração de tempo em que o servidor de Instâncias Grandes do HANA está disponível.

• O Objetivo de Ponto de Recuperação (RPO) é o período máximo tolerável em que dados do cliente podem ser perdidos devido a uma falha.

Para obter a alta disponibilidade, implante mais de uma instância em um par de alta disponibilidade e use uma HSR em um modo síncrono para minimizar a perda de dados e o tempo de inatividade. Além de uma configuração de alta disponibilidade local de dois nós, a HSR oferece suporte à replicação de várias camadas, em que um terceiro nó em uma região separada do Azure é registrada na réplica secundária do par da HSR com cluster como seu destino de replicação. Isso forma uma corrente encadeada de replicação.

O failover para o nó de recuperação de desastre é um processo manual sem clustering do Linux. Para detecção automática de falhas e failover, você pode configurar o Pacemaker para reduzir ainda mais o tempo de inatividade causado por falha de software ou hardware. A partir do HANA 2.0 Microsoft SharePoint Server 04, o HSR também dá suporte à replicação de vários destinos. Em vez de uma cadeia de margaridas, essa forma de replicação tem um assinante primário e vários secundários.

Ao configurar a HSR das Instâncias Grandes do HANA com failover automático, é possível solicitar que a equipe de Gerenciamento de Serviços da Microsoft configure um dispositivo STONITH para seus servidores de Instâncias Grandes do HANA existentes.

Recuperação de desastre

Essa arquitetura oferece suporte à recuperação de desastreentre Instâncias Grandes do HANA em diferentes regiões do Azure. Há duas maneiras de oferecer suporte a DRs com Instâncias Grandes do HANA:

• Replicação de armazenamento. O conteúdo de armazenamento primário é replicado constantemente para os sistemas de armazenamento de DR remota disponíveis no servidor designado para DR de Instâncias Grandes do HANA. Na replicação de armazenamento, o banco de dados do HANA não é carregado na memória. Essa opção de DR é mais simples sob uma perspectiva administrativa. Para determinar se essa é uma estratégia adequada, considere o tempo de carregamento do banco de dados em relação ao SLA de disponibilidade. A replicação de armazenamento também permite a execução da recuperação pontual. Caso seja configurada uma DR com vários fins (otimização de custo), você deve adquirir armazenamento adicional do mesmo tamanho no local de DR. A Microsoft fornece instantâneo de armazenamento e scripts de failover para failover do HANA como parte da oferta das Instâncias Grandes do HANA.

• A HSR de várias camadas ou vários destinos com uma terceira réplica na região da DR (onde o banco de dados do HANA é carregado na memória). Essa opção oferece suporte a um tempo de recuperação mais rápido, mas não à recuperação pontual. A HSR requer um sistema secundário. O tráfego de replicação do sistema HANA destinado ao site de recuperação de desastre pode ser roteado através de proxies, como nginx ou tabelas IP. Como alternativa, o Alcance Global pode ser usado para vincular os circuitos do ExpressRoute juntos, permitindo que os usuários autorizados se conectem diretamente à unidade de Instâncias Grandes do HANA.

Otimização de custo

Use a Calculadora de Preços do Azure para estimar os custos.

Para obter mais informações, confira a seção de custo em Estrutura Bem Projetada do Microsoft Azure.

SKUs podem afetar o modelo de cobrança. Estas são algumas considerações sobre custo.

Máquinas virtuais

Nessa arquitetura de referência, as máquinas virtuais são usadas para hospedar aplicativos SAP, serviços SAP e serviços compartilhados, como caixas de atalho de gerenciamento. Há certos SKUs certificados de Instâncias Grandes do HANA. As configurações dependem da carga de trabalho, dos recursos da CPU, da memória desejada e do orçamento.

SKUs de Instâncias Grandes do HANA estão disponíveis como instâncias de VM reservadas. As Reservas do Azure podem reduzir seu custo se você puder se comprometer com um período de um ou três anos. As reservas de VM podem reduzir os custos em até 72% quando comparadas com os preços de pagamento conforme o uso. Você obtém uma infraestrutura SAP HANA criada com finalidade com computação, armazenamento e rede. As Instâncias Grandes do HANA são acopladas ao armazenamento e à rede NFS e fornecem suporte interno para backups por meio de instantâneos de armazenamento, alta disponibilidade e recuperação de desastre e configurações de expansão. Se sua carga de trabalho não tiver um tempo previsível de conclusão ou consumo de recursos, considere a opção pagamento conforme o uso.

Use a visão geral do plano de economia do Azure e combine com as Reservas do Azure. O plano de economia do Azure é um plano flexível de economia de custos que gera economia significativa em relação aos preços pré-pagos. Você concorda com um contrato de um ou três anos e recebe descontos em serviços de computação qualificados. A economia se aplica a esses serviços de computação, independentemente da região, do tamanho da instância ou do sistema operacional. Para obter mais informações, consulte a documentação do plano de economia do Azure.

Use VMs spot do Azure para executar cargas de trabalho que podem ser interrompidas e não exigem conclusão em um período predeterminado ou em um SLA.

Para obter mais informações, confira a seção "SAP HANA em Instâncias Grandes do Azure" no Preços de HLI para Máquinas Virtuais SAP HANA.

Azure ExpressRoute

Para essa arquitetura, o Azure ExpressRoute é usado como serviço de rede usado para criar conexões privadas entre uma rede local e redes virtuais do Azure. As máquinas virtuais do Azure se conectam às Instâncias Grandes do HANA usando outra conexão de ExpressRoute e outro Gateway do ExpressRoute. Alto desempenho ou Ultradesempenhoé o SKU recomendado.

Toda a transferência de dados de entrada é gratuita. Toda a transferência de dados de saída é cobrada com base em uma taxa pré-determinada. Para obter mais informações, confira os Preços do Azure ExpressRoute.

Backup

Com base em seus requisitos de negócios, escolha entre várias opções disponíveis.

Para obter detalhes sobre uma abordagem do tipo "faça você mesmo" para backup e mais opções fornecidas com o SAP HANA em Instâncias Grandes, consulte o artigo Backup e restauração .

Capacidade de gerenciamento

Monitore os recursos das Instâncias Grandes do HANA— como CPU, memória, largura de banda de rede e espaço de armazenamento usando o SAP HANA Studio, SAP HANA Cockpit, SAP Solution Manager e outras ferramentas nativas do Linux. As SKUs do Tipo I de Instâncias Grandes do HANA não vêm com ferramentas de monitoramento internas. SKUs do tipo II oferecem ferramentas de diagnóstico predefinidas para registro em log de atividades do sistema e solução de problemas.

A Microsoft oferece ferramentas e recursos básicos para ajudá-lo a monitorar instâncias grandes do HANA no Azure. A equipe de suporte da Microsoft também pode ajudá-lo na solução de problemas técnicos.

Segurança

• Desde o final de 2018, o armazenamento de Instâncias Grandes do HANA é criptografado por padrão.

• Os dados em trânsito entre as Instâncias Grandes do HANA e as máquinas virtuais não são criptografados. Para criptografar a transferência de dados, habilite a criptografia específica do aplicativo. Confira a Nota SAP 2159014 – Perguntas frequentes: Segurança do SAP HANA.

• O isolamento fornece segurança entre os locatários no ambiente multilocatário do SAP HANA em Instâncias Grandes. Os locatários são isolados usando suas próprias VLANs.

• As práticas recomendadas de segurança de rede do Azure fornecem orientações úteis.

• Assim como em qualquer implantação, é recomendável proteger o sistema operacional, incluindo a proteção da imagem do SUSE Linux para SAP no Azure.

• Para a segurança física, o acesso aos datacenters do Azure é limitado apenas a pessoal autorizado. Nenhum cliente pode acessar os servidores físicos.

Para saber mais, confira Segurança do SAP HANA — Uma visão geral. (Uma conta do SAP Service Marketplace é necessária para o acesso.)

Comunidades

As comunidades podem responder a perguntas e ajudar você a configurar uma implantação bem-sucedida. Considere o seguinte:

• Como executar aplicativos SAP no blog Microsoft Platform
• Stack Overflow SAP

Colaboradores

Esse artigo é mantido pela Microsoft. Ele foi originalmente escrito pelos colaboradores a seguir.

Autor principal:

• Ben Trinh | Arquiteto Principal

Para ver perfis não públicos do LinkedIn, entre no LinkedIn.

Recursos relacionados

Talvez seja melhor examinar o seguinte cenário de exemplo do Azure, que demonstram soluções específicas usando algumas das mesmas tecnologias:

• Executando cargas de trabalho de produção do SAP usando um Oracle Database no Azure