Guia de planejamento do SAP HANA

Neste guia, você verá uma visão geral do que é necessário para executar o SAP HANA no Google Cloud, além de detalhes que podem ser usados ao planejar a implementação de um novo sistema SAP HANA.

Para detalhes sobre como implantar o SAP HANA no GCP, consulte o Guia de implantação do SAP HANA.

Sobre o SAP HANA no Google Cloud

O SAP HANA é um banco de dados relacional em memória, orientado por colunas, que oferece análise de alto desempenho e processamento de dados em tempo real. No centro dessa plataforma de dados em tempo real está o banco de dados SAP HANA. Os clientes podem aproveitar a facilidade dos recursos altamente escalonáveis, redundantes e de provisionamento da infraestrutura do GCP para executar cargas de trabalho essenciais aos negócios. O GCP oferece um conjunto de ativos físicos, como computadores e unidades de disco rígido, além de recursos virtuais, como máquinas virtuais (VMs, na sigla em inglês) do Compute Engine, localizados em data centers do Google ao redor do mundo.

Ao implantar o SAP HANA no GCP, você implanta em máquinas virtuais em execução no Compute Engine. As VMs do Compute Engine fornecem discos permanentes, que funcionam de maneira semelhante aos discos físicos em um computador ou servidor, mas são gerenciados automaticamente pelo Compute Engine para garantir a redundância de dados e o desempenho otimizado.

Princípios básicos do Google Cloud

O Google Cloud consiste em muitos serviços e produtos baseados em nuvem. Ao executar produtos SAP no Google Cloud, você usa principalmente os serviços baseados em IaaS oferecidos pelo Compute Engine e pelo Cloud Storage, bem como alguns recursos de toda a plataforma, como as ferramentas.

Consulte a visão geral do Google Cloud Platform para ver conceitos e termos importantes. Por conveniência e para contextualização, há algumas informações repetidas da visão geral neste guia.

Para uma visão geral das considerações que as organizações de escala empresarial devem considerar para execuções no Google Cloud, consulte as práticas recomendadas para organizações empresariais.

Como interagir com o Google Cloud

O Google Cloud oferece três maneiras principais de interagir com a plataforma e seus recursos na nuvem:

  • O Console do Google Cloud (que é uma interface do usuário na Web);
  • A ferramenta de linha de comando gcloud, que fornece um superconjunto das funcionalidades que o Console do Cloud oferece.
  • As bibliotecas de cliente, que fornecem APIs para acessar serviços e gerenciamento de recursos, além de serem úteis para você criar suas próprias ferramentas)

Serviços do GCP

As implantações da SAP normalmente utilizam alguns ou todos os seguintes serviços do Google Cloud:

Serviço Descrição
Rede VPC Conecta as instâncias de VM entre si e à Internet. Cada instância é membro de uma rede legada com um intervalo de IPs global ou de uma rede de sub-redes recomendada, em que a instância é membro de uma sub-rede que faz parte de uma rede maior. Não é possível que uma rede se estenda a projetos do Google Cloud, mas é possível que um projeto do Google Cloud tenha várias redes.
Compute Engine Cria e gerencia VMs com sua opção de sistema operacional e pilha de software.
Discos permanentes Estão disponíveis como unidades de disco rígido (HDD, na sigla em inglês) padrão ou unidades de estado sólido (SSD, na sigla em inglês).
Console do Google Cloud Ferramenta baseada em navegador para gerenciar recursos do Compute Engine. Use um modelo para descrever todos os recursos e instâncias necessários do Compute Engine. Não é preciso criar e configurar individualmente os recursos nem descobrir dependências, porque o Console do Cloud faz isso para você.
Cloud Storage Armazene no Cloud Storage os backups de bancos de dados SAP para maior durabilidade e confiabilidade, com replicação.
Cloud Monitoring Fornece visibilidade sobre a implantação, o desempenho, o tempo de atividade, bem como sobre a integridade do Compute Engine, da rede e dos discos permanentes.

O Monitoring coleta métricas, eventos e metadados do Google Cloud para oferecer insights com painéis, gráficos e alertas. É possível monitorar as métricas de computação sem custos por meio do Monitoring.
IAM Fornece controle unificado sobre permissões para recursos do Google Cloud. Controle quem tem capacidade para realizar operações de plano de controle nas VMs, que incluem criação, modificação e exclusão de VMs e discos persistentes, bem como criação e redes.

Preços e cotas

Use a calculadora de preços para estimar os custos de uso. Para mais informações sobre preços, consulte Preços do Compute Engine, Preços do Cloud Storage e Preços do pacote de operações do Google Cloud.

Os recursos do Google Cloud estão sujeitos a cotas. Se você planeja usar máquinas com alto uso da CPU ou da memória, talvez seja necessário solicitar cotas extras. Para mais informações, consulte Cotas de recursos do Compute Engine.

Recursos necessários

Tipos de máquinas certificadas para SAP HANA

A tabela a seguir mostra os tipos de máquina do Google Cloud certificadas pela SAP para uso de produção. Os tipos de máquina incluem máquinas virtuais (VMs, na sigla em inglês) do Compute Engine e máquinas bare-metal do Bare Metal Solution.

Exceto onde indicado na tabela, a SAP é compatível com os tipos de máquina em instalações de host único (escalonamento vertical) e de vários hosts (escalonamento horizontal). As instalações de escalonamento horizontal podem incluir até 15 hosts de worker, para um total de 16 hosts.

As configurações personalizadas dos tipos de VM de uso geral n1- e n2-highmem também são certificadas pela SAP. Para mais informações, consulte Tipos de VM personalizados certificados para SAP HANA.

Para os sistemas operacionais certificados para uso com HANA em cada tipo de máquina, consulte Sistemas operacionais certificados para SAP HANA.

Para saber mais sobre diferentes tipos de VM do Compute Engine e os respectivos casos de uso, consulte Tipos de máquina.

Alguns tipos de máquinas não estão disponíveis em todas as regiões do Google Cloud. Para verificar a disponibilidade regional de uma máquina virtual do Compute Engine, consulte Regiões e zonas disponíveis. Para máquinas do Bare Metal Solution certificadas para SAP HANA, consulte Disponibilidade regional de máquinas do Bare Metal Solution para SAP HANA.

A SAP lista os tipos de máquina certificadas para SAP HANA no diretório de hardware do SAP HANA (em inglês).

Os números do SAPS para cada tipo de máquina podem ser encontrados na página Certificações para SAP.

Tipos de máquina vCPU Memória (GB) Sistema operacional Plataforma de CPU Observações
Tipos de VM de uso geral com alta memória N1
n1-highmem-32 32 208 RHEL, SUSE
Intel Broadwell Certificação NetApp CVS-Performance para escalonamento vertical.
n1-highmem-64 64 416 RHEL, SUSE Intel Broadwell Certificação NetApp CVS-Performance para escalonamento vertical.
n1-highmem-96 96 624 RHEL, SUSE Intel Skylake Certificação NetApp CVS-Performance para escalonamento vertical.
Tipos de VM de uso geral com alta memória N2
n2-highmem-32 32 Até 256 RHEL, SUSE Intel Cascade Lake Somente escalonamento vertical.
Certificação NetApp CVS-Performance para escalonamento vertical.
n2-highmem-48 48 Até 384 RHEL, SUSE Intel Cascade Lake Somente escalonamento vertical.
Certificação NetApp CVS-Performance para escalonamento vertical.
n2-highmem-64 64 Até 512 RHEL, SUSE Intel Cascade Lake Somente escalonamento vertical.
Certificação NetApp CVS-Performance para escalonamento vertical.
n2-highmem-80 80 Até 640 RHEL, SUSE Intel Cascade Lake Somente escalonamento vertical.
Certificação NetApp CVS-Performance para escalonamento vertical.
Tipos de VM com otimização de memória M1
m1-megamem-96 96 1.433 RHEL, SUSE Intel Skylake Certificação NetApp CVS-Performance para escalonamento vertical.
m1-ultramem-40 40 Até 961 RHEL, SUSE Intel Broadwell Somente escalonamento vertical,
somente cargas de trabalho OLTP,
Certificação NetApp CVS-Performance para escalonamento vertical.
m1-ultramem-80 80 Até 1.922 RHEL, SUSE Intel Broadwell Somente escalonamento vertical,
somente cargas de trabalho OLTP,
Certificação NetApp CVS-Performance para escalonamento vertical.
m1-ultramem-160 160 Até 3.844 RHEL, SUSE Intel Broadwell Cargas de trabalho OLAP certificadas para escalonamento vertical e horizontal de até 16 nós.
As cargas de trabalho de OLTP certificadas somente para escalonamento vertical.
Certificado NetApp CVS-Performance apenas para escalonamento vertical.
Tipos de VM com otimização de memória M2
m2-megamem-416 416 Até 5.888 RHEL, SUSE Intel Cascade Lake Cargas de trabalho OLAP certificadas para escalonamento vertical e horizontal de até 16 nós.
As cargas de trabalho de OLTP certificadas somente para escalonamento vertical.
Certificado NetApp CVS-Performance apenas para escalonamento vertical.
m2-ultramem-208 208 Até 5.888 RHEL, SUSE Intel Cascade Lake Somente para escalonamento vertical.
apenas cargas de trabalho OLTP.
Certificado NetApp CVS-Performance para escalonamento vertical.
m2-ultramem-416 416 Até 11.776 RHEL, SUSE Intel Cascade Lake-SP As cargas de trabalho OLAP são certificadas para escalonamento vertical com dimensionamento baseado em carga de trabalho.
As cargas de trabalho de OLTP são certificadas para escalonamento vertical ou horizontal de até quatro nós.
A certificação de escalonamento horizontal de OLTP inclui o SAP S/4HANA.
O NetApp CVS-Performance é compatível com escalonamento vertical ou horizontal.
Para escalonar horizontalmente com o S/4HANA, consulte a Nota SAP 2408419.
Tipos de máquina do Bare Metal Solution com otimização de memória O2
o2-ultramem-672-metal 672 Até 18 TB RHEL, SUSE Intel Cascade Lake 12 soquetes.
Escalona verticalmente somente em uma arquitetura de três camadas.
Somente cargas de trabalho OLTP,
dimensionamento padrão.
o2-ultramem-896-metal 896 Até 24 TB RHEL, SUSE Intel Cascade Lake 16 soquetes.
Escalona verticalmente somente em uma arquitetura de três camadas.
Somente cargas de trabalho OLTP,
dimensionamento padrão.

Tipos de VM personalizados certificados para SAP HANA

A tabela a seguir mostra os tipos de máquina virtual (VM) personalizáveis do Compute Engine, certificados pela SAP para uso de produção do SAP HANA no Google Cloud.

A SAP certifica apenas um subconjunto das configurações de tipo de VM personalizada compatível com o Compute Engine.

As configurações de VM personalizadas estão sujeitas a regras de personalização definidas pelo Compute Engine. As regras variam de acordo com o tipo de máquina que você está personalizando. Para ver as regras de personalização completas, consulte Como criar uma instância de VM com um tipo de máquina personalizado.

Tipo de instância base do Google Cloud vCPU Memória (GB) Sistema operacional Plataforma de CPU
N1-highmem Um número de vCPUs de 32 a 64 que é igualmente divisível por 2. 6,5 GB por vCPU RHEL, SUSE Intel Broadwell
N2-highmem (somente escalonamento vertical) Um número de vCPUs de 32 a 64 que é igualmente divisível por 4. 8 GB por vCPU RHEL, SUSE Intel Cascade Lake

Disponibilidade regional de máquinas do Bare Metal Solution para SAP HANA

A tabela a seguir mostra as regiões atuais do Google Cloud compatíveis com o SAP HANA na Solução Bare Metal.

Região Local
europe-west3 Frankfurt, Alemanha, Europa
europe-west4 Eemshaven, Holanda, Europa
us-east4 Ashburn, Virgínia, EUA, América do Norte
us-west2 Los Angeles, Califórnia, EUA, América do Norte

Se você não vir a região de que precisa na tabela anterior, entre em contato com a Equipe de vendas do Google Cloud.

Configuração de memória

Suas opções de configuração de memória são determinadas pelo tipo de instância de VM do Compute Engine escolhida. Para mais informações, consulte a tabela tipos de VM compatíveis.

Configuração de memória da reinicialização rápida do SAP HANA

O Google Cloud recomenda a opção de Reinicialização rápida do SAP HANA.

Se você implementar a opção de reinicialização rápida, precisará mapear e entender a topologia de acesso não uniforme à memória (NUMA, na sigla em inglês) do ambiente host. O SAP HANA otimiza automaticamente o acesso à memória e a alocação de processos com base na topologia NUMA de um sistema.

Para mais informações do SAP, consulte Opção de reinicialização rápida do SAP HANA.

Sistemas operacionais certificados para SAP HANA

A tabela a seguir mostra os sistemas operacionais Red Hat Enterprise Linux (RHEL) e SUSE Linux Enterprise Server (SLES) certificados pela SAP para uso de produção com o SAP HANA no Google Cloud.

Exceto quando indicado na tabela, cada sistema operacional é compatível com o SAP HANA em todos os tipos de VM certificados do Compute Engine.

Para informações sobre o status de suporte atual de cada sistema operacional e quais sistemas operacionais estão disponíveis no Google Cloud, consulte Suporte do sistema operacional para SAP HANA no GCP.

Para informações da SAP sobre quais sistemas operacionais são compatíveis com o SAP HANA no Google Cloud, consulte o Diretório de hardware do SAP HANA.

A tabela a seguir não inclui:

  • versões certificadas do sistema operacional que não são mais compatíveis;
  • versões do sistema operacional que não são específicas do SAP.
Sistema operacional Versão Tipos de máquina não compatíveis
RHEL para SAP 7.3 personalizado
m1-ultramem
m2-megamem
m2-ultramem
n2-highmem
o2-ultramem
7.4 m2-ultramem
o2-ultramem
7.6
7.7
8.1
SLES para SAP 12 SP3 m1-megamem
n1-highmem
o2-ultramem
12 SP4
12 SP5
15
15 SP1
15 SP2 o2-ultramem

Imagens personalizadas de sistemas operacionais

É possível usar uma imagem do Linux que o GCP fornece e mantém (uma imagem pública) ou fornecer e manter sua própria imagem do Linux (uma imagem personalizada).

Use uma imagem personalizada se a versão do sistema operacional certificado pela SAP exigida não estiver disponível no GCP como imagem pública. Nas etapas a seguir, descritas em detalhes em Como importar imagens de disco de inicialização para o Compute Engine, resumimos o procedimento para usar uma imagem personalizada:

  1. Prepare seu disco de inicialização para que ele seja executado no ambiente do Compute Engine do GCP e para que possa ser acessado após a inicialização.
  2. Crie e compacte a imagem do disco de inicialização.
  3. Faça upload do arquivo de imagem para o Cloud Storage e importe a imagem para o Compute Engine como uma nova imagem personalizada.
  4. Use a imagem importada para criar uma instância de máquina virtual e garantir que ela seja inicializada corretamente.
  5. Otimize a imagem e instale o ambiente convidado do Linux para que a imagem do sistema operacional importada comunique-se com o servidor de metadados e use outros recursos do Compute Engine.

Depois que a imagem personalizada estiver pronta, será possível usá-la durante a criação de VMs para o sistema SAP HANA.

Se você estiver migrando um sistema operacional RHEL de uma instalação local para o GCP, será necessário adicionar o Red Hat Cloud Access à sua assinatura do Red Hat. Para mais informações, consulte Red Hat Cloud Access (em inglês).

Para mais informações sobre as imagens do sistema operacional fornecidas pelo GCP, consulte Imagens.

Para mais informações sobre como importar um sistema operacional para o GCP como uma imagem personalizada, consulte Como importar imagens de discos de inicialização para o Compute Engine.

Para mais informações sobre os sistemas operacionais que o SAP HANA suporta, consulte os links a seguir:

Origem do relógio no SO em VMs do Compute Engine

A origem do relógio padrão do SO é o kvm-clock para SLES e TSC para imagens do RHEL.

Não é necessário alterar a origem do relógio do SO quando o SAP HANA está em execução em uma VM do Compute Engine. Não há diferença no desempenho ao usar o kvm-clock ou o TSC como origem de relógio para VMs do Compute Engine com o SAP HANA.

Se você precisar alterar a origem do relógio do SO para o TSC, use SSH na sua VM e emita os seguintes comandos:

echo "tsc" | sudo tee /sys/devices/system/clocksource/*/current_clocksource
sudo cp /etc/default/grub /etc/default/grub.backup
sudo sed -i '/GRUB_CMDLINE_LINUX/ s|"| clocksource=tsc"|2' /etc/default/grub
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Armazenamento em disco permanente

Para armazenamento em blocos permanente, é possível anexar discos permanentes do Compute Engine ao criar suas VMs ou adicioná-las a elas posteriormente.

O Compute Engine oferece diferentes tipos de discos permanentes com base na tecnologia de unidade de estado sólido (SSD, na sigla em inglês) ou na tecnologia de unidade de disco rígido padrão. Cada tipo tem diferentes características de desempenho. O Google Cloud gerencia o hardware subjacente de discos permanentes para garantir a redundância de dados e otimizar o desempenho.

Por motivos de desempenho, os volumes /hana/data e /hana/log do SAP HANA exigem discos permanentes baseados em SSD. Os discos permanentes baseados em SSD incluem os tipos de disco permanente SSD (pd-ssd) e balanceados (pd-balanced).

Para o disco de inicialização e outros volumes do SAP HANA que não precisam do mesmo alto desempenho que os volumes /hana/data e /hana/log precisam, é possível usar os seguintes tipos de disco em uma instância de produção do SAP HANA:

  • O volume /shared pode ser mapeado para o mesmo disco permanente baseado em SSD que os volumes /hana/data e /hana/log. Se você mapeá-lo para o próprio disco dele, é possível usar um disco permanente pd-balanced;
  • Se você salvar os backups em um disco permanente, use um disco permanente padrão (pd-standard) com o volume /hanabackup.
  • Ao criar a VM do host, use um disco permanente pd-balanced para o disco de inicialização.
A figura a seguir mostra números de desempenho aproximados para diferentes discos permanentes em arquiteturas sugeridas para SAP HANA no Google Cloud. Os números reais que é possível encontrar em uma configuração semelhante podem ser diferentes por vários motivos, incluindo melhorias feitas pelo Compute Engine ao longo do tempo.

Dois sistemas SAP HANA são mostrados: o da esquerda tem "/hana/shared" no seu disco permanente equilibrado
e "/hana/data" e "/hana/log" juntos em um disco permanente
SSD. O outro sistema tem "/hana/data", "/hana/log" e
"/hana/shared" em um único disco permanente SSD, que é a
arquitetura recomendada.

Na configuração à esquerda na figura anterior, os volumes /hana/data e /hana/log estão em um disco permanente SSD e o volume /hana/shared, que não exige um desempenho alto, está em um disco permanente equilibrado, que custa menos do que um disco permanente SSD.

Na configuração à direita, os volumes /hana/data, /hana/log e /hana/shared estão todos em um único disco SSD. Isso proporciona um desempenho um pouco melhor com um disco a menos para ser gerenciado do que o modelo dividido, em que o volume /hana/shared está sozinho em um disco permanente equilibrado. A localização dos discos permanentes independe das VMs, portanto, é possível retirar ou mover os discos para manter os dados, mesmo depois de excluir as VMs.

No Console do Cloud, é possível ver os discos permanentes anexados às suas instâncias de VM em Discos adicionais na página Detalhes da instância de VM para cada instância de VM.

Para mais informações sobre os diferentes tipos de discos permanentes do Compute Engine, as características de desempenho deles e como trabalhar com eles, consulte a documentação do Compute Engine:

Tamanhos mínimos para discos permanentes baseados em SSD

Dentro dos limites descritos em Desempenho do armazenamento em blocos, o desempenho dos discos permanentes SSD e equilibrados aumenta à medida que o tamanho do disco e o número de vCPUs aumentam.

Veja na tabela a seguir os tamanhos recomendados de discos permanentes em SSD em disco permanente equilibrado em um ambiente de produção para cada tipo certificado de VM do Compute Engine. Os tamanhos presumem que os volumes /hana/data, /hana/log e /hana/shared são mapeados para o disco. Se o sistema for particularmente sensível com relação ao desempenho, o uso do pd-ssd é recomendado para o melhor desempenho.

No mínimo, o SAP HANA exige uma capacidade sustentada de 400 MB por segundo para leituras e gravações, o que é fornecido por um pd-ssd de 834 GB ou um pd-balanced de 1429 GB. Os tamanhos listados na tabela são os tamanhos dos discos permanentes para cada tipo de VM que fornecem o desempenho do SAP HANA necessário para a certificação desse tipo de VM.

À medida que os tamanhos dos discos permanentes na tabela aumentam para acomodar mais memória da máquina e tamanhos de dados, a capacidade também aumenta até os limites de arquitetura descritos em Desempenho do armazenamento em blocos.

Tipo de VM do Compute Engine pd-ssd pd-balanced
n1-highmem-32 834 1.429
n1-highmem-64 1,155 1.980
n1-highmem-96 1.716 2.942
n2-highmem-32 834 1.429
n2-highmem-48 1.068 1.831
n2-highmem-64 1.414 2.424
n2-highmem-80 1.760 3.017
m1-megamem-96 3.287 4.286
m1-ultramem-40 2.626 4.286
m1-ultramem-80 3.874 4.286
m1-ultramem-160 6.180 6.180
m2-megamem-416 8.667 8.667
m2-ultramem-208 8.667 8.667
m2-ultramem-416 15.766 15.766

Como determinar o tamanho do disco permanente

Para sistemas de escalonamento vertical do SAP HANA, calcule a quantidade de armazenamento em disco permanente necessário para os volumes do SAP HANA com base na quantidade de memória que o tipo de VM do Compute Engine selecionado contém. Use as seguintes fórmulas para cada volume:

  • /hana/data: 1,2 x memória
  • /hana/log: 0,5 x de memória (ajustada como um múltiplo de 64, se necessário) ou 512 GB, o que for menor
  • /hana/shared: 1 x memória ou 1.024 GB, o que for menor
  • /usr/sap: 32 GB
  • /hanabackup: 2 x memória

Selecione um tamanho de disco permanente que não seja menor do que o tamanho mínimo listado para seu tipo de disco permanente em Tamanhos mínimos para discos SSD e discos permanentes balanceados.

Por exemplo, se você estiver executando o SAP HANA em uma instância de VM n2-highmem-32, que tenha 256 GB de memória, o requisito de armazenamento total para os volumes do SAP HANA será 723 GB. No entanto, se você usar um disco permanente SSD, o tamanho mínimo necessário será 834 GB. Portanto, é preciso dimensionar o disco permanente em 834 GB ou mais.

Aplique qualquer armazenamento em disco permanente em excesso ao volume /hana/data.

Para informações da SAP sobre o dimensionamento do SAP HANA, consulte Como dimensionar o SAP HANA.

Discos permanentes implantados pelos modelos do Deployment Manager

Quando você implanta um sistema SAP HANA usando os scripts do Cloud Deployment Manager fornecidos pelo Google Cloud, o Cloud Deployment Manager aloca dois discos permanentes para o SAP HANA:

  • Um único disco permanente SSD para os diretórios /hana/data, /hana/log, /usr/sap e /hana/shared
  • Um disco permanente HDD padrão para o diretório /hanabackup

O Cloud Deployment Manager mapeia os diretórios /hana/data, /hana/log, /usr/sap e /hana/shared do SAP HANA para seu próprio volume lógico para facilitar o redimensionamento e os mapeia para a SSD permanente. disco em um único grupo de volumes.

O Deployment Manager mapeia o diretório /hanabackup para um volume lógico em um grupo de volumes separado, que ele mapeia para um disco permanente HDD padrão.

O exemplo a seguir mostra como o Deployment Manager mapeia os volumes para o SAP HANA em uma VM do Compute Engine n2-highmem-32, que tem 256 GB de memória.

No exemplo, o grupo de volumes vg_hana é mapeado para um único disco permanente SSD de 834 GB, que é o tamanho mínimo necessário. Com 256 GB de memória, os volumes do SAP HANA exigem apenas cerca de 723 GB de armazenamento no total. Para usar todo o armazenamento no disco permanente, o Deployment Manager alocou o espaço em disco em excesso para o volume de dados. O Deployment Manager dimensionou o volume de backup em 512 GB, dobrou a memória e a mapeou para um disco permanente padrão do mesmo tamanho.

hana-ssd-example:~ # lvs
  LV     VG            Attr       LSize   Pool Origin Data%  Meta%  Move Log Cpy%Sync Convert
  data   vg_hana       -wi-ao---- 426.00g
  log    vg_hana       -wi-ao---- 125.00g
  sap    vg_hana       -wi-ao----  32.00g
  shared vg_hana       -wi-ao---- 251.00g
  backup vg_hanabackup -wi-ao---- 512.00g

Os tamanhos dos volumes para o mesmo tipo de VM podem ser um pouco diferentes dos mostrados no exemplo.

Armazenamento para backups

O armazenamento para backup do SAP HANA é configurado com discos permanentes HDD padrão. Os discos permanentes HDD padrão são eficientes e econômicos para lidar com operações sequenciais de leitura/gravação, mas não são otimizados para lidar com altas taxas de operações de entrada/saída por segundo (IOPS, na sigla em inglês) aleatórias. O SAP HANA usa E/S sequencial com grandes blocos para fazer backup do banco de dados. Os discos permanentes HDD padrão fornecem uma opção de baixo custo e alto desempenho para esse cenário.

O tamanho do volume de backup do SAP HANA foi projetado para fornecer valor de referência e capacidade de burst ideais, bem como a habilidade de manter vários conjuntos de backup. Manter vários conjuntos de backups no volume de backup facilita a recuperação do banco de dados, se necessário.

Se você usar o SAP HANA em nível dinâmico, o armazenamento de backup precisará ser grande o suficiente para conter os dados em memória e os dados gerenciados em disco pelo servidor de nível dinâmico.

Se você usar o agente do Backint do Cloud Storage para SAP HANA, poderá fazer backup do SAP HANA diretamente para um bucket do Cloud Storage, o que torna opcional o uso de um disco permanente para armazenar backups.

Nível dinâmico do SAP HANA

O nível dinâmico do SAP HANA é certificado pela SAP para uso em ambientes de produção no GCP. O nível dinâmico do SAP HANA amplia seu próprio armazenamento de dados ao armazenar dados que raramente são acessados no disco em vez de na memória.

Para mais informações, consulte Nível dinâmico do SAP HANA no Google Cloud.

Opção de reinicialização rápida do SAP HANA

Para o SAP HANA 2.0 SP04 e versões posteriores, o Google Cloud recomenda a opção de Reinicialização rápida do SAP HANA.

Para implementar a opção de reinicialização rápida, consulte Opção de reinicialização rápida do SAP HANA na documentação do SAP HANA.

Se você implantar um sistema SAP HANA usando o modelo do Cloud Deployment Manager fornecido pelo Google Cloud, será preciso criar e ativar o sistema de arquivos TMPFS após a implantação da VM do host e do sistema SAP HANA de base.

Para mais informações sobre a alocação de memória para a Reinicialização rápida do SAP HANA, consulte Configuração de memória da Reinicialização rápida do SAP HANA.

Opções de servidor de arquivos

As opções de servidor de arquivos para o SAP HANA no Google Cloud incluem o Filestore e o NetApp Cloud Volumes Service para Google Cloud.

Para mais informações sobre todas as opções de servidores de arquivos para o SAP no Google Cloud, consulte Soluções de compartilhamento de arquivos para o SAP no Google Cloud.

Filestore

Somente para o volume /hana/shared, use o Filestore. No entanto, com os níveis de serviço básicos do Filestore, todos os hosts do SAP HANA que compartilham o armazenamento precisam estar na mesma zona do Google Cloud porque uma instância do Filestore é um recurso zonal. Isso é particularmente relevante para volumes compartilhados em uma configuração de escalonamento horizontal, em que os nós de computação para o sistema de escalonamento horizontal precisam residir na mesma zona para otimizar a latência. Para mais informações, consulte Componentes em um sistema de escalonamento horizontal do SAP HANA no Google Cloud.

Cloud Volumes Service da NetApp para Google Cloud

O NetApp Cloud Volumes Service para o Google Cloud é uma plataforma de serviços de dados nativa da nuvem totalmente gerenciada que pode ser usada para criar um sistema de arquivos NFS para sistemas de escalonamento vertical do SAP HANA em todos os tipos de instância do Compute Engine certificados para o SAP HANA.

O NetApp Cloud Volumes Service oferece dois tipos de serviço: CVS e CVS-Performance. O tipo de serviço CVS-Performance oferece níveis de serviço diferentes. É preciso usar o tipo de serviço NetApp Cloud Volumes Service CVS-Performance (NetApp CVS-Performance) e o nível de serviço Extremo com o SAP HANA.

A compatibilidade com o NetApp CVS-Performance em implantações de escalonamento horizontal é limitada a tipos de instância específicos do Compute Engine, conforme indicado em Tipos de VM certificados para SAP HANA na tabela.

Com o NetApp CVS-Performance, você pode colocar todos os diretórios do SAP HANA, incluindo /hana/data e /hana/logs, no armazenamento compartilhado, em vez de usar discos permanentes do Compute Engine. Com a maioria dos outros sistemas de armazenamento compartilhado, é possível incluir apenas o diretório /hana/shared no armazenamento compartilhado.

A compatibilidade do SAP com o NetApp CVS-Performance no Google Cloud está listada no Diretório de hardware do SAP HANA.

Disponibilidade regional do desempenho CSV do NetApp para o SAP HANA

Os volumes do NetApp CVS-Performance precisam estar na mesma região das instâncias de VM do host.

A compatibilidade do SAP HANA com o NetApp CVS-Performance não está disponível em todas as regiões em que o NetApp CVS-Performance se encontra.

É possível usar o NetApp CVS-Performance com o SAP HANA nas seguintes regiões do Google Cloud:

Região Local
europe-west4 Eemshaven, Países Baixos, Europa
us-east4 Ashburn, Virgínia do Norte, EUA
us-west2 Los Angeles, Califórnia, EUA

Se você tiver interesse em executar o SAP HANA com o NetApp CVS-Performance em uma região do Google Cloud que não está listada acima, entre em contato com a equipe de vendas.

Compatibilidade com o protocolo NFS

O NetApp CVS-Performance é compatível com os protocolos NFSv3 e NFSv4.1 com o SAP HANA no Google Cloud.

O NFSv3 é recomendado para volumes configurados para permitir várias conexões TCP. O NFSv4.1 ainda não é compatível com várias conexões TCP.

Requisitos de volume para o NetApp Cloud Volumes Service com SAP HANA

Os volumes do NetApp CVS-Performance precisam estar na mesma região das instâncias de VM do host.

Para os volumes /hana/data e /hana/log, é necessário o nível de serviço Extremo do NetApp CVS-Performance. É possível usar o nível de serviço Premium para o diretório /hana/shared se ele estiver em um volume separado dos diretórios /hana/data e /hana/log.

Para ter o melhor desempenho com sistemas SAP HANA maiores que 1 TB, crie volumes separados para /hana/data, /hana/log e /hana/shared.

Para atender aos requisitos de desempenho do SAP HANA, os seguintes tamanhos mínimos de volume são necessários ao executar o SAP HANA com o NetApp CVS-Performance:

Diretório Tamanho mínimo
/hana/shared 1 TB
/hana/log 2,5 TB
/hana/data 4 TB

Ajuste o tamanho dos volumes para atender aos requisitos de capacidade. A taxa de capacidade mínima para o nível de serviço "Extremo" é de 128 MB por segundo para cada 1 TB. Portanto, a capacidade para 4 TB de espaço em disco é de 512 MB por segundo. O provisionamento de mais espaço em disco para o volume /hana/data pode reduzir os tempos de inicialização. Para o volume /hana/data, recomendamos 1,5 vez o tamanho da memória ou 4 TB, o que for maior.

O tamanho mínimo do volume /hanabackup é determinado pela estratégia de backup. Também é possível usar o agente do Backint do Cloud Storage para SAP HANA para fazer backup do banco de dados diretamente no Cloud Storage.

Como implantar um sistema SAP HANA com o NetApp CVS-Performance

Para implantar o NetApp CVS-Performance com SAP HANA no Google Cloud, primeiro é preciso implantar as VMs e instalar o SAP HANA. É possível usar os modelos do Deployment Manager fornecidos pelo Google Cloud para implantar as VMs e o SAP HANA ou criar as instâncias de VM e instalar o SAP HANA manualmente.

Se você usar os modelos do Deployment Manager, as VMs serão implantadas com os volumes /hana/data e /hana/log mapeados para discos permanentes. Depois de ativar os volumes do NetApp CVS-Performance para as VMs, é preciso copiar o conteúdo dos discos permanentes, conforme descrito nas etapas a seguir.

Para implantar o SAP HANA com o NetApp CVS-Performance usando os modelos do Deployment Manager fornecidos pelo Google Cloud:

  1. Implante o SAP HANA com discos permanentes usando os modelos do Cloud Deployment Manager fornecidos pelo Google Cloud seguindo as instruções no Guia de implantação do SAP HANA.
  2. Crie seus volumes do NetApp CVS-Performance. Para ver instruções completas da NetApp, consulte a Documentação do NetApp Cloud Volumes Service para Google Cloud.

  3. Ative o NetApp CVS-Performance em um ponto de montagem temporário usando o comando mount com as seguintes configurações:

    mount -t nfs -o options server:path mountpoint

    Para options, use as seguintes configurações:

    rw,bg,hard,rsize=1048576,wsize=1048576,vers=3,tcp,nconnect=16,noatime,nolock

    A opção vers=3 indica NFSv3. A opção nconnect=16 especifica a compatibilidade com várias conexões TCP.

  4. Interrompa o SAP HANA e todos os serviços relacionados que usam os volumes de disco permanente anexados.

  5. Copie o conteúdo dos volumes de disco permanente para os volumes correspondentes do NetApp CVS-Performance.

  6. Remova os discos permanentes.

  7. Reconecte os volumes NetApp CVS-Performance aos pontos de montagem permanentes atualizando o /etc/fstab com as seguintes configurações:

    server:path   /mountpoint   nfs   options   0 0

    Para options, use as seguintes configurações:

    rw,bg,hard,rsize=1048576,wsize=1048576,vers=3,tcp,nconnect=16,noatime,nolock

    Para mais informações sobre como atualizar o arquivo /etc/fstab, consulte a página nfs no manual de formatos de arquivo do Linux.

  8. Para um melhor desempenho, atualize a categoria fileio no arquivo global.ini do SAP HANA com as seguintes configurações sugeridas:

    Parâmetro Valor
    async_read_submit on
    async_write_submit_active on
    async_write_submit_blocks all
    max_parallel_io_requests 128
    max_parallel_io_requests[data] 128
    max_parallel_io_requests[log] 128
    num_completion_queues 4
    num_completion_queues[data] 4
    num_completion_queues[log] 4
    num_submit_queues 8
    num_submit_queues[data] 8
    num_submit_queues[log] 8
  9. Reinicie o SAP HANA.

  10. Depois de confirmar que tudo funciona conforme o esperado, exclua os discos permanentes para evitar que sejam cobrados.

Identificação do usuário e acesso a recursos

Ao planejar a segurança de uma implantação do SAP no Google Cloud, é preciso identificar o seguinte:

  • As contas de usuário e os aplicativos que precisam de acesso aos recursos do Google Cloud no seu projeto do Google Cloud.
  • Os recursos específicos do Google Cloud em seu projeto que cada usuário precisará acessar.

É necessário adicionar cada usuário a seu projeto incluindo o ID da conta do Google ao projeto como membro. Para programas aplicativos que usam os recursos do Google Cloud, crie uma conta de serviço, que fornece uma identificação ao usuário para o programa dentro do projeto.

As VMs do Compute Engine dispõem de suas próprias contas de serviço. Qualquer programa que seja executado na VM pode usar uma conta de serviço da VM, contanto que essa conta tenha as permissões de recursos necessárias para o programa.

Depois de identificar os recursos do Google Cloud que cada usuário precisa, conceda permissões para que eles usem esses recursos atribuindo papéis específicos do recurso ao usuário. Revise os papéis predefinidos que o IAM oferece para cada recurso e atribua, a cada usuário, papéis que forneçam apenas as permissões suficientes para que eles concluam suas tarefas ou funções.

Se você precisar de um controle mais granular ou restritivo do que os papéis predefinidos do IAM, poderá criar papéis personalizados.

Para mais informações sobre os papéis do IAM necessários aos programas SAP no Google Cloud, consulte Gerenciamento de identidade e acesso para programas SAP no Google Cloud.

Para uma visão geral do gerenciamento de identidade e acesso do SAP no Google Cloud, consulte este artigo.

Considerações sobre preço e cota para o SAP HANA

Você é responsável pelos custos cobrados para usar os recursos criados por seguir este guia de implantação. Use a calculadora de preços para ajudar a estimar os custos reais.

Cotas

Se você tiver uma conta do GCP nova ou não tiver solicitado uma cota maior, será necessário fazer isso para implantar o SAP HANA. Visualize sua cota atual e a compare com a tabela a seguir para ver o aumento a ser solicitado. É possível então solicitar um aumento no limite da cota.

Na tabela a seguir, mostramos os valores de cota para sistemas SAP HANA de escalonamento vertical e de host único por tipo de instância de VM. Se você hospedar o SAP HANA Studio no GCP ou usar um gateway NAT e um Bastion Host, adicione os valores mostrados na tabela ao seu requisito de cota total.

Tipo de instância CPU Memória PD padrão PD SSD DP equilibrado
n1-highmem-32 32 208 GB 448 GB 834 GB 1.429 GB
n1-highmem-64 64 416 GB 864 GB 1.155 GB 1.980 GB
n1-highmem-96 96 624 GB 1.280 GB 1.716 GB 3.264 GB
n2-highmem-32 32 256 GB 544 GB 834 GB 1.429 GB
n2-highmem-48 48 384 GB 800 GB 1.068 GB 1.830 GB
n2-highmem-64 64 512 GB 1.056 GB 1.414 GB 2.422 GB
n2-highmem-80 80 640 GB 1.312 GB 1.760 GB 2.860 GB
m1-megamem-96 96 1.433 GB 2.898 GB 3.287 GB 3.287 GB
m1-ultramem-40 40 961 GB 1.954 GB 2.626 GB 2.900 GB
m1-ultramem-80 80 1.922 GB 3.876 GB 3.874 GB 3.874 GB
m1-ultramem-160 160 3.844 GB 7.720 GB 6.180 GB 6.180 GB
m2-megamem-416 416 5.888 GB 11.832 GB 8.667 GB 8.667 GB
m2-ultramem-208 208 5.888 GB 11.832 GB 8.667 GB 8.667 GB
m2-ultramem-416 416 11.766 GB 23.564 GB 15.766 GB 15.766 GB
Gateway NAT/Bastion 1 3,75 GB 8 GB 0 GB 0 GB
SAP HANA Studio 1 3,75 GB 50 GB 0 GB 0 GB

Observação: no momento, o tipo de instância "m2-megamem-416" do Compute Engine é certificado pela SAP somente se os dados e volumes de registro estiverem armazenados no NetApp Cloud Volumes Service para Google Cloud, então não é necessário armazenamento em disco permanente.

Licenciamento

Para executar o SAP HANA no GCP, é necessário que você traga sua própria licença (BYOL, na sigla em inglês).

Para mais informações da SAP sobre o gerenciamento de licenças do SAP HANA, consulte Chaves de licença para o banco de dados SAP HANA.

Arquitetura de implantação

O SAP HANA no GCP oferece suporte a arquiteturas de host único e de vários hosts.

Arquitetura de host único

Veja a arquitetura de host único no diagrama a seguir. No diagrama, observe a implantação no GCP e o layout do disco. Use o Cloud Storage para fazer backup dos seus backups locais disponíveis em /hanabackup. Essa ativação precisa ser igual ou maior que a ativação de dados.

Layout de implantação

Observe que a VM do SAP HANA não tem IP público, o que significa que não pode ser acessada por uma rede externa. Em vez disso, a implantação usa um Bastion Host NAT e o SAP HANA Studio para acessar o SAP HANA. A instância do SAP HANA Studio e o Bastion Host são implantados na mesma sub-rede que a instância do SAP HANA.

Provisione um host Windows em que você instala o SAP HANA Studio, com a instância colocada na mesma sub-rede e com regras de firewall que permitem a conexão ao banco de dados SAP HANA pelo SAP HANA Studio.

Implante o SAP HANA usando uma arquitetura de escalonamento vertical de host único que tem os componentes a seguir:

  • Uma instância do Compute Engine para o banco de dados SAP HANA, com um disco permanente SSD de 834 GB ou maior e uma rede com largura de banda de até 16 Gbps. O disco permanente SSD é particionado e ativado em /hana/data e /hana/log para hospedar os dados e os registros.

  • Uma sub-rede opcional, mas recomendada, com topologia personalizada e intervalos de IP na região do GCP de sua escolha. O banco de dados SAP HANA e as outras instâncias do Compute Engine são inicializados nessa sub-rede. É possível usar uma sub-rede atual para o SAP HANA.

  • Um gateway de Internet opcional, mas recomendado, configurado para acesso à Internet de saída para sua instância do SAP HANA e outras instâncias. Neste guia, pressupomos que você esteja usando esse gateway.

  • Regras de firewall do Compute Engine que restringem o acesso a instâncias.

  • Disco permanente para backup do banco de dados SAP HANA.

  • VM do Compute Engine, n1-standard-2, com o sistema operacional Windows para hospedar o SAP HANA Studio.

  • VM do Compute Engine, n1-standard-1, como um Bastion Host.

  • Instalação automatizada do banco de dados SAP HANA com um arquivo de configuração criado de um modelo.

  • SAP HANA Studio.

Como implantar sistemas de escalonamento vertical com o Deployment Manager

O Google Cloud fornece modelos de configuração do Deployment Manager que podem ser usados para automatizar a implantação de sistemas de escalonamento vertical de host único do SAP HANA.

Os scripts do Deployment Manager podem ser usados para os cenários a seguir:

Os scripts do Deployment Manager podem implantar as VMs, os discos permanentes, o SAP HANA e, no caso do cluster de alta disponibilidade do Linux, os componentes de alta disponibilidade necessários.

Os scripts do Deployment Manager não implantam os componentes do sistema a seguir:

  • A rede e a sub-rede
  • Regras de firewall
  • Gateways NAT, Bastion Hosts ou as VMs deles
  • SAP HANA Studio ou a VM dele

Arquitetura de vários hosts

No diagrama a seguir, vemos uma arquitetura de vários hosts no Google Cloud.

Diagrama de arquitetura de vários hosts.

Conforme a demanda da carga de trabalho aumenta, especialmente ao usar o OLAP, uma arquitetura de vários hosts e de escalonamento horizontal pode distribuir a carga entre todos os hosts.

A arquitetura de escalonamento horizontal consiste em um host principal, vários hosts worker e, opcionalmente, um ou mais hosts em espera. Os hosts são interconectados por meio de uma rede compatível com envio de dados entre hosts a taxas de até 16 Gbps.

Os hosts em espera são compatíveis com a solução de recuperação de falhas de failover automático de hosts do SAP HANA. Para mais informações sobre o failover automático do host no Google Cloud, consulte o Guia de planejamento de alta disponibilidade e recuperação de desastres para SAP HANA.

Estruturas de disco para sistemas de escalonamento horizontal do SAP HANA no Google Cloud

Com exceção dos hosts em espera, cada host tem seus próprios volumes /hana/data, /hana/log e, normalmente, /usr/sap em discos SSD permanentes, que oferecem serviços de E/S consistentes e com IOPS alto. O host principal também serve como o principal do NFS para os volumes /hana/shared e /hanabackup, o que é ativado em cada worker e host em espera.

Para um host em espera, os volumes /hana/data e /hana/log não são ativados até que ele também seja ativado.

Alta disponibilidade para sistemas de escalonamento horizontal do SAP HANA no Google Cloud

Os recursos a seguir ajudam a garantir a alta disponibilidade de um sistema de escalonamento horizontal do SAP HANA:

  • Migração em tempo real do Compute Engine
  • Reinicialização automática de instâncias do Compute Engine
  • Failover automático do host do SAP HANA com até três hosts em espera do SAP HANA

Para mais informações sobre as opções de alta disponibilidade no Google Cloud, consulte o Guia de planejamento de alta disponibilidade e recuperação de desastres para SAP HANA.

No caso de uma migração em tempo real ou evento de reinicialização de instância automática, os volumes /hana/shared e /hanabackup baseados no armazenamento permanente protegido poderão ficar on-line novamente assim que uma instância estiver em execução.

Se estiver usando um host em espera, em caso de falha, o failover automático do SAP HANA desativará os volumes /hana/data e /hana/log do host com falha e os ativará no host em espera.

Componentes em um sistema de escalonamento horizontal do SAP HANA no Google Cloud

Uma arquitetura de escalonamento horizontal de vários hosts do SAP HANA no Google Cloud contém os componentes a seguir:

  • 1 instância de VM do Compute Engine para cada host do SAP HANA no sistema, incluindo 1 host principal, até 15 hosts workers e até 3 hosts em espera opcionais.

    Cada VM usa o mesmo tipo de máquina do Compute Engine. Para os tipos de máquina compatíveis com o SAP HANA, consulte Tipos de VM.

    Cada VM precisa incluir armazenamento SSD e HDD, ativado no local correto.

  • Uma solução NFS implantada separadamente para compartilhar os volumes /hana/shared e /hanabackup com o worker e os hosts em espera. É possível usar o Filestore ou outra solução de NFS.

  • Uma sub-rede opcional, mas recomendada, com topologia personalizada e intervalos de IP na região do GCP de sua escolha. O banco de dados SAP HANA e as outras instâncias do Compute Engine são inicializados nessa sub-rede. Se preferir, use uma sub-rede atual.

  • Opcionalmente, um gateway de Internet configurado para acesso à Internet de saída para sua instância do SAP HANA e outras instâncias.

  • Opcionalmente, uma VM n1-standard-2 do Compute Engine com o sistema operacional Windows instalado para hospedar o SAP HANA Studio.

  • Opcionalmente, uma VM n1-standard-1 do Compute Engine para um Bastion Host.

  • Regras de firewall do Compute Engine ou outros controles de acesso à rede que restringem o acesso a instâncias do Compute Engine e também permitem a comunicação entre instâncias e outros recursos distribuídos ou remotos exigidos pelo sistema SAP HANA.

Como implantar sistemas de escalonamento horizontal com o Deployment Manager

O Google Cloud fornece modelos de configuração do Deployment Manager que podem ser usados para automatizar a implantação de sistemas de escalonamento horizontal de vários hosts do SAP HANA.

Os scripts do Deployment Manager podem implantar as VMs, os discos permanentes e o SAP HANA. O script também ativa a solução NFS para as VMs.

Os scripts do Deployment Manager não implantam os componentes do sistema a seguir:

  • A rede e a sub-rede
  • A solução NFS
  • Regras de firewall
  • Gateways NAT, Bastion Hosts ou as VMs deles
  • SAP HANA Studio ou a VM dele

Suporte

Em caso de problemas com a infraestrutura ou os serviços do Google Cloud, entre em contato com o Customer Care. É possível ver os dados de contato na página Visão geral do suporte no Console do Google Cloud. Se o Customer Care determinar que há um problema nos seus sistemas SAP, você será encaminhado ao Suporte da SAP.

Para problemas relacionados a produtos SAP, registre sua solicitação de suporte no site da SAP. A SAP avalia o tíquete de suporte e, se ele parecer ser um problema de infraestrutura do Google Cloud, transfere o tíquete para o componente do Google Cloud, BC-OP-LNX-GOOGLE ou BC-OP-NT-GOOGLE.

Requisitos de suporte

Antes de receber suporte para sistemas SAP e a infraestrutura e os serviços do Google Cloud que eles usam, você precisa atender aos requisitos mínimos do plano de suporte.

Saiba mais sobre os requisitos mínimos de suporte para SAP no Google Cloud em:

A seguir