Partilhar via

Configurações e operações de infraestrutura do SAP HANA no Azure

  • Artigo

Este documento fornece orientação para configurar a infraestrutura do Azure e operar sistemas SAP HANA implantados em máquinas virtuais (VMs) nativas do Azure. O documento também inclui informações de configuração para expansão do SAP HANA para o M128s VM SKU. Este documento não se destina a substituir a documentação padrão do SAP, que inclui o seguinte conteúdo:

Pré-requisitos

Para usar este guia, você precisa de conhecimento básico dos seguintes componentes do Azure:

Para saber mais sobre o SAP NetWeaver e outros componentes SAP no Azure, consulte a seção SAP no Azure da documentação do Azure.

Considerações básicas de configuração

As seções a seguir descrevem considerações básicas de configuração para implantar sistemas SAP HANA em VMs do Azure.

Conectar-se a máquinas virtuais do Azure

Conforme documentado no guia de planejamento de máquinas virtuais do Azure, há dois métodos básicos para se conectar às VMs do Azure:

  • Conecte-se através da Internet e de pontos de extremidade públicos em uma VM Jump ou na VM que está executando o SAP HANA.
  • Conecte-se por meio de uma VPN ou Azure ExpressRoute.

A conectividade site a site via VPN ou ExpressRoute é necessária para cenários de produção. Esse tipo de conexão também é necessário para cenários de não produção que alimentam cenários de produção em que o software SAP está sendo usado. A imagem a seguir mostra um exemplo de conectividade entre sites:

Conectividade entre sites

Escolher tipos de VM do Azure

O SAP lista quais tipos de VM do Azure que você pode usar para cenários de produção. Para cenários de não produção, uma variedade maior de tipos de VM nativa do Azure está disponível.

Nota

Para cenários de não produção, use os tipos de VM listados na nota SAP #1928533. Para o uso de VMs do Azure para cenários de produção, verifique se há VMs certificadas pelo SAP HANA na lista Plataformas IaaS certificadas publicadas pela SAP.

Implante as VMs no Azure usando:

  • Portal do Azure.
  • Cmdlets do Azure PowerShell.
  • CLI do Azure.

Importante

Para usar M208xx_v2 VMs, você precisa ter cuidado ao selecionar sua imagem do Linux. Para obter mais informações, consulte Tamanhos de máquina virtual otimizados para memória.

Configuração de armazenamento para SAP HANA

Para configurações de armazenamento e tipos de armazenamento a serem usados com o SAP HANA no Azure, leia o documento Configurações de armazenamento da máquina virtual SAP HANA Azure

Configurar redes virtuais do Azure

Quando você tem conectividade site a site no Azure via VPN ou ExpressRoute, você deve ter pelo menos uma rede virtual do Azure conectada por meio de um Gateway Virtual ao circuito VPN ou ExpressRoute. Em implantações simples, o Gateway Virtual pode ser implantado em uma sub-rede da rede virtual do Azure (VNet) que também hospeda as instâncias do SAP HANA. Para instalar o SAP HANA, crie mais duas sub-redes na rede virtual do Azure. Uma sub-rede hospeda as VMs para executar as instâncias do SAP HANA. A outra sub-rede executa o Jumpbox ou VMs de gerenciamento para hospedar o SAP HANA Studio, outro software de gerenciamento ou seu software de aplicativo.

Importante

Fora de funcionalidade, mas mais importante por razões de desempenho, não há suporte para configurar os Dispositivos Virtuais de Rede do Azure no caminho de comunicação entre o aplicativo SAP e a camada DBMS de um sistema SAP baseado em SAP NetWeaver, Hybris ou S/4HANA. A comunicação entre a camada de aplicação SAP e a camada DBMS precisa ser direta. A restrição não inclui regras ASG e NSG do Azure, desde que essas regras ASG e NSG permitam uma comunicação direta. Outros cenários em que NVAs não são suportados estão em caminhos de comunicação entre VMs do Azure que representam nós de cluster Linux Pacemaker e dispositivos SBD, conforme descrito em Alta disponibilidade para SAP NetWeaver em VMs do Azure no SUSE Linux Enterprise Server para aplicativos SAP. Ou em caminhos de comunicação entre VMs do Azure e SOFS do Windows Server configurados conforme descrito em Agrupar uma instância SAP ASCS/SCS em um cluster de failover do Windows usando um compartilhamento de arquivos no Azure. NVAs em caminhos de comunicação podem facilmente dobrar a latência de rede entre dois parceiros de comunicação, podem restringir a taxa de transferência em caminhos críticos entre a camada de aplicativos SAP e a camada DBMS. Em alguns cenários observados com os clientes, os NVAs podem fazer com que os clusters Linux do Pacemaker falhem nos casos em que as comunicações entre os nós do cluster Linux Pacemaker precisam se comunicar com seu dispositivo SBD por meio de um NVA.

Importante

Outro design que NÃO é suportado é a segregação da camada de aplicativo SAP e da camada DBMS em diferentes redes virtuais do Azure que não são emparelhadas entre si. É recomendável segregar a camada de aplicativo SAP e a camada DBMS usando sub-redes em uma rede virtual do Azure em vez de usar diferentes redes virtuais do Azure. Se você decidir não seguir a recomendação e, em vez disso, segregar as duas camadas em redes virtuais diferentes, as duas redes virtuais precisam ser emparelhadas. Lembre-se de que o tráfego de rede entre duas redes virtuais do Azure emparelhadas está sujeito a custos de transferência. Com o enorme volume de dados em muitos Terabytes trocados entre a camada de aplicativos SAP e a camada DBMS, custos substanciais podem ser acumulados se a camada de aplicativos SAP e a camada DBMS forem segregadas entre duas redes virtuais do Azure emparelhadas.

Se você implantou o Jumpbox ou VMs de gerenciamento em uma sub-rede separada, poderá definir várias placas de interface de rede virtual (vNICs) para a VM HANA, com cada vNIC atribuída a sub-rede diferente. Com a capacidade de ter vários vNICs, você pode configurar a separação de tráfego de rede, se necessário. Por exemplo, o tráfego do cliente pode ser roteado através da vNIC principal e o tráfego administrativo é roteado através de uma segunda vNIC.
Você também atribui endereços IP privados estáticos que são implantados para ambas as NICs virtuais.

Nota

Você deve atribuir endereços IP estáticos por meio do Azure a vNICs individuais. Você não deve atribuir endereços IP estáticos dentro do SO convidado a uma vNIC. Alguns serviços do Azure, como o Serviço de Backup do Azure, dependem do fato de que pelo menos a vNIC primária está definida como DHCP e não para endereços IP estáticos. Consulte também o documento Solucionar problemas de backup de máquina virtual do Azure. Se você precisar atribuir vários endereços IP estáticos a uma VM, precisará atribuir várias vNICs a uma VM.

No entanto, para implantações duradouras, você precisa criar uma arquitetura de rede de datacenter virtual no Azure. Essa arquitetura recomenda a separação do Gateway de Rede Virtual do Azure que se conecta ao local em uma VNet do Azure separada. Essa VNet separada deve hospedar todo o tráfego que sai para o local ou para a Internet. Essa abordagem permite implantar software para auditoria e registro em log do tráfego que entra no datacenter virtual no Azure nesta VNet de hub separada. Portanto, você tem uma VNet que hospeda todos os softwares e configurações relacionados ao tráfego de entrada e saída para sua implantação do Azure.

Os artigos Azure Virtual Datacenter: A Network Perspetive e Azure Virtual Datacenter and the Enterprise Control Plane fornecem mais informações sobre a abordagem de datacenter virtual e o design de VNet do Azure relacionado.

Nota

O tráfego que flui entre uma VNet de hub e uma VNet spoke usando o emparelhamento de VNet do Azure está sujeito a custos adicionais. Com base nesses custos, talvez seja necessário considerar fazer concessões entre a execução de um design de rede de hub e spoke estrito e a execução de vários Gateways de Rota Expressa do Azure aos quais você se conecta a 'spokes' para ignorar o emparelhamento de VNet. No entanto, os Gateways de Rota Expressa do Azure também apresentam custos adicionais. Você também pode encontrar custos adicionais para software de terceiros que você usa para registro, auditoria e monitoramento de tráfego de rede. Dependendo dos custos de troca de dados por meio do emparelhamento de VNet por um lado e dos custos criados por Gateways de Rota Expressa do Azure adicionais e licenças de software adicionais, você pode decidir por microssegmentação dentro de uma VNet usando sub-redes como unidade de isolamento em vez de VNets.

Para obter uma visão geral dos diferentes métodos de atribuição de endereços IP, consulte Tipos de endereços IP e métodos de alocação no Azure.

Para VMs que executam o SAP HANA, você deve trabalhar com endereços IP estáticos atribuídos. O motivo é que alguns atributos de configuração para HANA fazem referência a endereços IP.

Os NSGs (Grupos de Segurança de Rede) do Azure são usados para direcionar o tráfego roteado para a instância do SAP HANA ou para a jumpbox. Os NSGs e, eventualmente, os Application Security Groups estão associados à sub-rede SAP HANA e à sub-rede Management.

Para implantar o SAP HANA no Azure sem uma conexão site a site, você ainda deseja proteger a instância do SAP HANA da Internet pública e ocultá-la atrás de um proxy de encaminhamento. Neste cenário básico, a implantação depende de serviços DNS internos do Azure para resolver nomes de host. Em uma implantação mais complexa, onde endereços IP voltados para o público são usados, os serviços DNS internos do Azure são especialmente importantes. Use os NSGs do Azure e os NVAs do Azure para controlar e monitorar o roteamento da Internet para sua arquitetura de rede virtual do Azure no Azure. A imagem a seguir mostra um esquema aproximado para implantar o SAP HANA sem uma conexão site a site em uma arquitetura VNet hub e spoke:

Esquema de implementação aproximado para SAP HANA sem uma conexão site a site

Outra descrição sobre como usar NVAs do Azure para controlar e monitorar o acesso da Internet sem a arquitetura de VNet hub e spoke pode ser encontrada no artigo Implantar dispositivos virtuais de rede altamente disponíveis.

Opções de origem de relógio em VMs do Azure

O SAP HANA requer informações de temporização confiáveis e precisas para um desempenho ideal. Tradicionalmente, as VMs do Azure em execução no hipervisor do Azure usavam apenas a página TSC do Hyper-V como uma fonte de relógio padrão. Os avanços tecnológicos em hardware, sistema operacional host e kernels de SO convidado Linux tornaram possível fornecer "TSC invariante" como uma opção de fonte de relógio em algumas SKUs de VM do Azure.

A página TSC do Hyper-V (hyperv_clocksource_tsc_page) tem suporte em todas as VMs do Azure como uma fonte de relógio. Se o hardware subjacente, o hipervisor e o kernel linux do SO convidado suportarem o TSC Invariante, tsc serão oferecidos como fonte de relógio disponível e suportada no SO convidado em VMs do Azure.

Configurando a infraestrutura do Azure para expansão do SAP HANA

Para descobrir os tipos de VM do Azure certificados para expansão OLAP ou expansão S/4HANA, verifique o diretório de hardware do SAP HANA. Uma marca de verificação na coluna 'Clustering' indica o suporte de expansão. O tipo de aplicativo indica se há suporte para expansão OLAP ou expansão S/4HANA. Para obter detalhes sobre nós certificados em expansão, revise a entrada para uma SKU de VM específica listada no diretório de hardware do SAP HANA.

As versões mínimas do sistema operacional para implantar configurações de expansão em VMs do Azure, verifique os detalhes das entradas na SKU de VM específica listada no diretório de hardware do SAP HANA. De uma configuração de expansão OLAP de n-node, um nó funciona como o nó principal. Os outros nós até o limite da certificação atuam como nó de trabalho. Mais nós em espera não contam para o número de nós certificados

Nota

As implantações em expansão da VM do Azure do SAP HANA com nó de espera só são possíveis usando o armazenamento de Arquivos NetApp do Azure. Nenhum outro armazenamento do Azure certificado pelo SAP HANA permite a configuração de nós em espera do SAP HANA

Para /hana/shared, recomendamos o uso de Arquivos NetApp do Azure ou Arquivos do Azure.

Um design básico típico para um único nó em uma configuração de expansão, com /hana/shared implantado nos Arquivos NetApp do Azure, tem a seguinte aparência:

Diagrama que mostra um design básico típico para um único nó em uma configuração de expansão.

A configuração básica de um nó de VM para expansão do SAP HANA tem a seguinte aparência:

  • Para /hana/shared, você usa o serviço NFS nativo fornecido por meio dos Arquivos NetApp do Azure ou Arquivos do Azure.
  • Todos os outros volumes de disco não são compartilhados entre os diferentes nós e não são baseados em NFS. As configurações de instalação e as etapas para instalações HANA de expansão com /hana/data e /hana/log não compartilhadas são fornecidas mais adiante neste documento. Para obter o armazenamento certificado HANA que pode ser usado, consulte o artigo Configurações de armazenamento de máquina virtual do SAP HANA Azure.

Dimensionando os volumes ou discos, você precisa verificar o documento SAP HANA TDI Storage Requirements, para o tamanho necessário dependendo do número de nós de trabalho. O documento libera uma fórmula que você precisa aplicar para obter a capacidade necessária do volume

O outro critério de design exibido nos gráficos da configuração de nó único para uma VM SAP HANA de expansão é a VNet, ou melhor, a configuração de sub-rede. A SAP recomenda vivamente uma separação entre o cliente/aplicação e as comunicações entre os nós HANA. Como mostrado nos gráficos, esse objetivo é alcançado por ter duas vNICs diferentes conectadas à VM. Ambos os vNICs estão em sub-redes diferentes, têm dois endereços IP diferentes. Em seguida, você controla o fluxo de tráfego com regras de roteamento usando NSGs ou rotas definidas pelo usuário.

Particularmente no Azure, não há meios e métodos para impor a qualidade do serviço e as cotas em vNICs específicos. Como resultado, a separação da comunicação cliente/aplicativo e intra-nó não abre nenhuma oportunidade de priorizar um fluxo de tráfego sobre o outro. Em vez disso, a separação continua a ser uma medida de segurança na proteção das comunicações intra-nó das configurações de expansão.

Nota

A SAP recomenda separar o tráfego de rede para o lado do cliente/aplicativo e o tráfego intra-nó, conforme descrito neste documento. Portanto, recomenda-se colocar uma arquitetura no lugar como mostrado nos últimos gráficos. Consulte também a sua equipa de segurança e conformidade para conhecer os requisitos que se desviam da recomendação

Do ponto de vista da rede, a arquitetura de rede mínima necessária seria semelhante a:

Noções básicas de expansão de um único nó

Instalando o SAP HANA scale-out no Azure

Instalando uma configuração SAP de expansão, você precisa executar etapas aproximadas de:

  • Implantando uma nova infraestrutura de rede virtual do Azure ou adaptando uma existente
  • Implantando as novas VMs usando o Armazenamento Premium Gerenciado do Azure, volumes de disco Ultra e/ou volumes NFS com base em ANF
    • Adapte o roteamento de rede para garantir que, por exemplo, a comunicação intra-nó entre VMs não seja roteada por meio de um NVA.
  • Instale o nó principal do SAP HANA.
  • Adaptar os parâmetros de configuração do nó principal do SAP HANA
  • Continue com a instalação dos nós de trabalho do SAP HANA

Instalação do SAP HANA em configuração scale-out

À medida que sua infraestrutura de VM do Azure é implantada e todos os outros preparativos são concluídos, você precisa instalar as configurações de expansão do SAP HANA nestas etapas:

  • Instale o nó principal do SAP HANA de acordo com a documentação do SAP
  • Ao usar o global.ini Armazenamento Premium do Azure ou o armazenamento em disco Ultra com discos não compartilhados de /hana/data e /hana/log, adicione o parâmetro basepath_shared = no ao arquivo. Esse parâmetro permite que o SAP HANA seja executado em scale-out sem compartilhamento /hana/data e /hana/log volumes entre os nós. Os detalhes estão documentados na Nota SAP #2080991. Se você estiver usando volumes NFS baseados em ANF para /hana/data e /hana/log, não será necessário fazer essa alteração
  • Após a eventual alteração no parâmetro global.ini, reinicie a instância do SAP HANA
  • Adicione mais nós de trabalho. Para obter mais informações, consulte Adicionar hosts usando a interface de linha de comando. Especifique a rede interna para comunicação entre nós do SAP HANA durante a instalação ou depois usando, por exemplo, o hdblcm local. Para obter documentação mais detalhada, consulte SAP Note #2183363.

Para configurar um sistema de expansão SAP HANA com um nó em espera, consulte as instruções de implantação do SUSE Linux ou as instruções de implantação da Red Hat.

SAP HANA Dynamic Tiering 2.0 para máquinas virtuais do Azure

Além das certificações SAP HANA em VMs da série M do Azure, o SAP HANA Dynamic Tiering 2.0 também é suportado no Microsoft Azure. Para obter mais informações, consulte Links para a documentação do DT 2.0. Não há diferença na instalação ou operação do produto. Por exemplo, você pode instalar o SAP HANA Cockpit dentro de uma VM do Azure. No entanto, há alguns requisitos obrigatórios, conforme descrito na seção a seguir, para suporte oficial no Azure. Ao longo do artigo, a abreviatura "DT 2.0" será usada em vez do nome completo Dynamic Tiering 2.0.

O SAP HANA Dynamic Tiering 2.0 não é suportado pelo SAP BW ou S4HANA. Os principais casos de uso no momento são aplicativos HANA nativos.

Descrição geral

A imagem abaixo fornece uma visão geral sobre o suporte ao DT 2.0 no Microsoft Azure. Existe um conjunto de requisitos obrigatórios, que têm de ser seguidos para cumprir com a certificação oficial:

  • O DT 2.0 deve ser instalado em uma VM dedicada do Azure. Ele não pode ser executado na mesma VM em que o SAP HANA é executado
  • As VMs SAP HANA e DT 2.0 devem ser implantadas na mesma Vnet do Azure
  • As VMs SAP HANA e DT 2.0 devem ser implantadas com a rede acelerada do Azure habilitada
  • O tipo de armazenamento para as VMs DT 2.0 deve ser o Armazenamento Premium do Azure
  • Vários discos do Azure devem ser anexados à VM DT 2.0
  • É necessário criar um raid de software / volume distribuído (via lvm ou mdadm) usando striping nos discos do Azure

Mais detalhes serão explicados nas seções a seguir.

Visão geral da arquitetura do SAP HANA DT 2.0

VM do Azure dedicada para SAP HANA DT 2.0

Na IaaS do Azure, o DT 2.0 só é suportado em uma VM dedicada. Não é permitido executar o DT 2.0 na mesma VM do Azure em que a instância HANA está sendo executada. Inicialmente, dois tipos de VM podem ser usados para executar o SAP HANA DT 2.0:

  • M64-32ms
  • E32sv3

Para obter mais informações sobre a descrição do tipo de VM, consulte Tamanhos de VM do Azure - Memória

Dada a ideia básica do DT 2.0, que consiste em descarregar dados "quentes" para economizar custos, faz sentido usar tamanhos de VM correspondentes. No entanto, não há uma regra rígida em relação às combinações possíveis. Depende da carga de trabalho específica do cliente.

As configurações recomendadas seriam:

Tipo SAP HANA VM Tipo de VM DT 2.0
M128ms M64-32ms
M128s M64-32ms
M64ms E32sv3
M64s E32sv3

Todas as combinações de VMs da série M certificadas pelo SAP HANA com VMs DT 2.0 suportadas (M64-32ms e E32sv3) são possíveis.

Rede do Azure e SAP HANA DT 2.0

A instalação do DT 2.0 em uma VM dedicada requer uma taxa de transferência de rede entre a VM DT 2.0 e a VM SAP HANA de no mínimo 10 Gb. Portanto, é obrigatório colocar todas as VMs na mesma Vnet do Azure e habilitar a rede acelerada do Azure.

Veja informações adicionais sobre a rede acelerada do Azure Criar uma VM do Azure com Rede Acelerada usando a CLI do Azure

Armazenamento de VM para SAP HANA DT 2.0

De acordo com as diretrizes de práticas recomendadas do DT 2.0, a taxa de transferência de E/S do disco deve ser de no mínimo 50 MB/s por núcleo físico.

De acordo com as especificações para os dois tipos de VM do Azure, que são suportados para DT 2.0, o limite máximo de taxa de transferência de E/S de disco para a VM tem a seguinte aparência:

  • E32sv3: 768 MB/seg (sem cache), o que significa uma proporção de 48 MB/seg por núcleo físico
  • M64-32ms: 1000 MB/seg (sem cache), o que significa uma proporção de 62,5 MB/seg por núcleo físico

É necessário anexar vários discos do Azure à VM DT 2.0 e criar um raid de software (striping) no nível do SO para atingir o limite máximo de taxa de transferência de disco por VM. Um único disco do Azure não pode fornecer a taxa de transferência para atingir o limite máximo de VM nesse sentido. O armazenamento Premium do Azure é obrigatório para executar o DT 2.0.

Dependendo dos requisitos de tamanho, há diferentes opções para atingir a taxa de transferência máxima de uma VM. Aqui estão possíveis configurações de disco de volume de dados para cada tipo de VM DT 2.0 para atingir o limite superior de taxa de transferência da VM. A VM E32sv3 deve ser considerada como um nível de entrada para cargas de trabalho menores. Caso não seja rápido o suficiente, pode ser necessário redimensionar a VM para M64-32ms. Como a VM M64-32ms tem muita memória, a carga de E/S pode não atingir o limite, especialmente para cargas de trabalho de leitura intensiva. Portanto, menos discos no conjunto de distribuição podem ser suficientes, dependendo da carga de trabalho específica do cliente. Mas para estar no lado seguro, as configurações de disco abaixo foram escolhidas para garantir a taxa de transferência máxima:

SKU da VM Configuração de disco 1 Configuração de disco 2 Configuração de disco 3 Configuração de disco 4 Configuração de disco 5
M64-32ms 4 x P50 -> 16 TB 4 x P40 -> 8 TB 5 x P30 -> 5 TB 7 x P20 -> 3,5 TB 8 x P15 -> 2 TB
E32sv3 3 x P50 -> 12 TB 3 x P40 -> 6 TB 4 x P30 -> 4 TB 5 x P20 -> 2,5 TB 6 x P15 -> 1,5 TB

Especialmente no caso de a carga de trabalho ser intensa em leitura, isso pode aumentar o desempenho de E/S para ativar o cache de host do Azure "somente leitura", conforme recomendado para os volumes de dados do software de banco de dados. Considerando que, para o log de transações, o cache de disco do host do Azure deve ser "nenhum".

Em relação ao tamanho do volume de log, um ponto de partida recomendado é uma heurística de 15% do tamanho dos dados. A criação do volume de log pode ser realizada usando diferentes tipos de disco do Azure, dependendo dos requisitos de custo e taxa de transferência. Para o volume de log, é necessária uma alta taxa de transferência de E/S.

Ao usar o tipo de VM M64-32ms, é obrigatório habilitar o Acelerador de Gravação. O Azure Write Accelerator fornece latência de gravação de disco ideal para o log de transações (disponível apenas para a série M). Há alguns itens a serem considerados, como o número máximo de discos por tipo de VM. Detalhes sobre o Acelerador de Escrita podem ser encontrados na página do Acelerador de Escrita do Azure

Aqui estão alguns exemplos sobre como dimensionar o volume de log:

Tamanho do volume de dados e tipo de disco volume de log e configuração do tipo de disco 1 volume de log e configuração do tipo de disco 2
4 x P50 -> 16 TB 5 x P20 -> 2,5 TB 3 x P30 -> 3 TB
6 x P15 -> 1,5 TB 4 x P6 -> 256 GB 1 x P15 -> 256 GB

Como para o SAP HANA scale-out, o diretório /hana/shared deve ser compartilhado entre a VM SAP HANA e a VM DT 2.0. Recomenda-se a mesma arquitetura do SAP HANA scale-out usando VMs dedicadas, que atuam como um servidor NFS altamente disponível. Para fornecer um volume de backup compartilhado, o design idêntico pode ser usado. Mas cabe ao cliente se o HA seria necessário ou se é suficiente apenas usar uma VM dedicada com capacidade de armazenamento suficiente para atuar como um servidor de backup.

Operações para implantar o SAP HANA em VMs do Azure

As seções a seguir descrevem algumas das operações relacionadas à implantação de sistemas SAP HANA em VMs do Azure.

Fazer backup e restaurar operações em VMs do Azure

Os documentos a seguir descrevem como fazer backup e restaurar sua implantação do SAP HANA:

Iniciar e reiniciar VMs que contenham SAP HANA

Um recurso proeminente da nuvem pública do Azure é que você é cobrado apenas pelos minutos de computação. Por exemplo, quando você desliga uma VM que está executando o SAP HANA, é cobrado apenas pelos custos de armazenamento durante esse período. Outro recurso está disponível quando você especifica endereços IP estáticos para suas VMs em sua implantação inicial. Quando você reinicia uma VM que tem o SAP HANA, a VM é reiniciada com seus endereços IP anteriores.

Use o SAProuter para suporte remoto SAP

Se você tiver uma conexão site a site entre seus locais locais e o Azure e estiver executando componentes SAP, provavelmente já está executando o SAProuter. Nesse caso, preencha os seguintes itens para suporte remoto:

  • Mantenha o endereço IP privado e estático da VM que hospeda o SAP HANA na configuração do SAProuter.
  • Configure o NSG da sub-rede que hospeda a VM HANA para permitir o tráfego através da porta TCP/IP 3299.

Se você estiver se conectando ao Azure pela Internet e não tiver um roteador SAP para a VM com SAP HANA, precisará instalar o componente. Instale o SAProuter em uma VM separada na sub-rede Gerenciamento. A imagem a seguir mostra um esquema aproximado para implantar o SAP HANA sem uma conexão site a site e com o SAProuter:

Esquema de implementação aproximado para SAP HANA sem uma conexão site a site e SAProuter

Certifique-se de instalar o SAProuter em uma VM separada e não na sua VM Jumpbox. A VM separada deve ter um endereço IP estático. Para conectar seu SAProuter ao SAProuter hospedado pelo SAP, entre em contato com o SAP para obter um endereço IP. (O SAProuter hospedado pelo SAP é a contrapartida da instância do SAProuter que você instala em sua VM.) Use o endereço IP do SAP para configurar sua instância do SAProuter. Nas definições de configuração, a única porta necessária é a porta TCP 3299.

Para obter mais informações sobre como configurar e manter conexões de suporte remoto por meio do SAProuter, consulte a documentação do SAP.

Alta disponibilidade com SAP HANA em VMs nativas do Azure

Se você estiver executando o SUSE Linux Enterprise Server ou o Red Hat, poderá estabelecer um cluster Pacemaker com dispositivos de esgrima. Você pode usar os dispositivos para configurar uma configuração do SAP HANA que usa replicação síncrona com a replicação do sistema HANA e failover automático. Para mais informações, consulte a secção «Próximas etapas».

Passos Seguintes

Familiarize-se com os artigos listados