Editar

Compartilhar via

Executar SAP HANA para máquinas virtuais do Linux em uma arquitetura de escala vertical no Azure

Azure
Máquinas Virtuais do Azure

Esta arquitetura de referência mostra um conjunto de práticas comprovadas para executar o SAP HANA em um ambiente de alta disponibilidade e capacidade de expansão que dá suporte à recuperação de desastre no Azure. O foco da implementação é apenas a camada de banco de dados.

Arquitetura

Essa arquitetura de referência descreve um sistema de produção comum. Você pode escolher os tamanhos da máquina virtual para atender às necessidades da sua organização. Também é possível reduzir a configuração a uma máquina virtual, dependendo dos requisitos comerciais.

O seguinte diagrama mostra uma arquitetura de referência para SAP HANA no Azure:

Diagrama que mostra uma arquitetura de implantação regional.

Baixe um arquivo do Visio que contém os diagramas neste artigo.

Observação

Para implantar essa arquitetura de referência, você precisa do licenciamento apropriado de produtos SAP e outras tecnologias que não são da Microsoft.

Workflow

Esta arquitetura de referência descreve um banco de dados SAP HANA típico em execução no Azure, em uma implantação altamente disponível para maximizar a disponibilidade do sistema. A arquitetura e seus componentes podem ser personalizados com base em requisitos de negócios (RTO, RPO, expectativas de tempo de atividade, função do sistema) e potencialmente reduzidos a uma única VM. O layout de rede é simplificado para demonstrar os princípios da arquitetura desse ambiente SAP e não descreve uma rede corporativa completa.

Rede

Redes virtuais. O serviço Rede Virtual do Azure conecta os recursos do Azure entre si com segurança avançada. Nessa arquitetura, a rede virtual se conecta a um ambiente local por meio de um ExpressRoute que está implantado no hub de uma topologia hub-spoke. O banco de dados SAP HANA está contido em sua própria rede virtual spoke. A rede virtual spoke contém uma sub-rede para as VMs (máquinas virtuais) do banco de dados.

Se os aplicativos que se conectam ao SAP HANA estão em execução em VMs, as VMs do aplicativo precisam estar na mesma rede virtual, mas dentro de uma sub-rede de aplicativo dedicada. Como alternativa, se a conexão do SAP HANA não for o banco de dados primário, as VMs do aplicativo poderão estar localizadas em outras redes virtuais. A separação em sub-redes por carga de trabalho permite facilitar a habilitação de NSGs (Grupos de Segurança de Rede) para definir regras de segurança aplicáveis somente às VMs do SAP HANA.

Gateway com redundância de zona. Um gateway conecta redes distintas, estendendo sua rede local para a rede virtual do Azure. Recomendamos que você use o ExpressRoute para criar conexões privadas que não passam pela Internet pública, mas você também pode usar uma conexão site a site. Use gateways de VPN ou do Azure ExpressRoute com redundância de zona para se proteger contra falhas de zona. Confira Gateways de rede virtual com redundância de zona para entender as diferenças entre uma implantação com zonas e uma implantação com redundância de zona. Vale a pena mencionar aqui que os endereços IP usados precisam ser do SKU Standard para uma implantação de zona dos gateways.

Grupos de segurança de rede (NSG). Para restringir o tráfego de entrada e saída da rede virtual, crie grupos de segurança de rede que, por sua vez, são atribuídos a sub-redes específicas. As sub-redes do banco de dados e do aplicativo são protegidas com NSGs específicos da carga de trabalho.

Grupos de segurança do aplicativo (ASG). Para definir políticas de segurança de rede refinadas dentro de seus NSGs baseados em cargas de trabalho que são centralizadas nos aplicativos, use grupos de segurança de aplicativo em vez de endereços IP explícitos. Eles permitem que você agrupe adaptadores de rede de VMs por nome e ajudam a proteger aplicativos filtrando o tráfego de segmentos confiáveis da rede.

NICs (Placas de interface de rede). Os cartões de adaptador de rede permitem toda a comunicação entre máquinas virtuais em uma rede virtual. Implantações tradicionais locais da SAP implementam vários NICs por computador para separar o tráfego administrativo do tráfego de negócios.

No Azure, não é necessário usar várias NICs por motivos de desempenho. Várias NICs compartilham o mesmo limite de taxa de transferência de rede de uma VM. No entanto, se sua organização precisa separar o tráfego, você pode implantar vários NICs por VM e conectar cada NIC a uma sub-rede diferente. Em seguida, você pode usar grupos de segurança de rede para impor políticas de controle de acesso diferentes em cada sub-rede.

As NICs do Azure dão suporte a vários IPs. Esse suporte está em conformidade com a prática recomendada pela SAP de usar nomes de host virtual para instalações. Para ver uma descrição completa, confira a nota SAP 962955. (Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.)

Observação

Conforme especificado na nota SAP 2731110, não coloque NVAs (Soluções de Virtualização de Rede) entre o aplicativo e as camadas de banco de dados em pilhas de aplicativos SAP. Isso aumenta bastante o tempo de processamento de pacotes de dados e reduz o desempenho do aplicativo de maneira inaceitável.

Máquinas virtuais

Essa arquitetura usa VMs (Máquinas Virtuais). O Azure oferece escala de nó único até 32 Tebibytes (TiB) de memória em máquinas virtuais. O Diretório de Hardware SAP HANA certificado e com suporte lista as máquinas virtuais certificadas para o banco de dados SAP HANA. Para saber mais sobre o suporte do SAP para tipos de máquina virtual e métricas de taxa de transferência (SAPS), confira a Nota SAP 1928533 – Aplicativos SAP no Microsoft Azure: produtos com suporte e tipos de VM do Azure. Para acessar essa e outras notas do SAP, é necessário ter uma conta do SAP Service Marketplace.

A Microsoft e a SAP certificam conjuntamente vários tamanhos de máquina virtual para cargas de trabalho do SAP HANA. Por exemplo, implantações menores podem ser executadas em uma máquina virtual Edsv4 e Edsv5 com 160 GiB ou mais de RAM. Para dar suporte aos maiores tamanhos de memória do SAP HANA em máquinas virtuais, até 30 TiB, você pode usar máquinas virtuais da série Mv3.

Máquinas virtuais de 2ª geração (Gen2). Ao implantar VMs, você pode usar VMs de geração 1 ou geração 2. As VMs da Geração 2 dão suporte a recursos importantes que não estão disponíveis nas VMs da Geração 1. Para o SAP HANA, isso é particularmente importante porque algumas famílias de VM, como Mv2, Mdsv2, Msv3 e Mdsv3 têm suporte apenas como VMs Gen2. Da mesma forma, a certificação SAP no Azure pode exigir que as VMs mais recentes sejam Gen2, mesmo que o Azure permita Gen1 e Gen2. Para obter detalhes, consulte nota SAP 1928533 – Aplicativos SAP no Microsoft Azure: produtos com suporte e tipos de VM do Azure.

Como todas as outras VMs compatíveis com o SAP HANA permitem a escolha de geração 2 somente ou geração 1+2 seletivamente, recomenda-se implantar todas as VMs SAP apenas como Gen2. Isso também se aplica a VMs com requisitos de memória baixa. Mesmo a menor VM do SAP HANA pode ser executada como VM Gen2 e pode ser, quando desalocada, redimensionada para a maior VM disponível em sua região.

Grupos de posicionamento por proximidade. Para otimizar a latência de rede, você pode usar grupos de posicionamento por proximidade, que priorizam a colocação. As VMs estão localizadas no mesmo datacenter para minimizar a latência entre o SAP HANA e as VMs de aplicativo de conexão. Para a arquitetura do SAP HANA em si, os grupos de posicionamento por proximidade não são necessários, mas usá-los pode ajudá-lo a otimizar seu desempenho. Devido a possíveis restrições com grupos de posicionamento por proximidade, você deve adicionar o conjunto de disponibilidade do banco de dados ao grupo de posicionamento por proximidade do sistema SAP somente quando isso for necessário para latência entre o aplicativo SAP e o tráfego de banco de dados. Para obter mais informações sobre os cenários de uso de grupos de posicionamento por proximidade, consulte Opções de configuração para minimizar a latência de rede com aplicativos SAP. Como os grupos de posicionamento por proximidade restringem cargas de trabalho a um único datacenter, um grupo de posicionamento por proximidade não pode abranger várias zonas de disponibilidade. Implantações de alto volume que fazem referência a grupos de posicionamento por proximidade podem estar sujeitas a limitações de alocação de recursos.

Componentes

Considerações

Esta seção descreve as principais considerações para executar o SAP HANA no Azure.

Escalabilidade

Essa arquitetura executa o SAP HANA em máquinas virtuais que podem escalar verticalmente até 32 TiB em uma instância.

Se sua carga de trabalho exceder o tamanho máximo da máquina virtual, use configurações de expansão do HANA de vários nós. Para aplicativos OLTP (processamento de transações online), a capacidade total de memória horizontal pode ser de até 4 x 23 TiB. Para aplicativos OLAP (processamento analítico online), a capacidade de expansão da memória pode ser de até 16 x 7,6 TiB. Por exemplo, você pode implantar o SAP HANA em uma configuração de expansão com espera em máquinas virtuais executando Red Hat Enterprise Linux ou do SUSE Linux Enterprise Server e usar do Azure NetApp Files para os volumes de armazenamento compartilhado. Para identificar as SKUs de VM certificadas que dão suporte a configurações de expansão, consulte o de Hardware do SAP HANA certificado e com suporte. Examine os detalhes do certificado para cada SKU de VM para garantir o suporte à sua configuração.

Armazenamento

Essa arquitetura usa discos gerenciados do Azure para armazenamento nas máquinas virtuais ou Azure NetApp Files. As diretrizes para implantação de armazenamento com discos gerenciados estão detalhadamente no documento de configurações de armazenamento de máquina virtual do SAP HANA do Azure. Como alternativa aos discos gerenciados, os volumes de NFS do Azure NetApp Files podem ser usados como solução de armazenamento para o SAP HANA.

Para alcançar altos valores de IOPS (Operações de Entrada/Saída por Segundo) e taxa de transferência de armazenamento em disco, as práticas comuns na otimização de desempenho de volumes de armazenamento também se aplicam ao armazenamento do Azure. Por exemplo, a combinação de vários discos com LVM para criar um volume de discos distribuídos melhora o desempenho de E/S. O cache de disco do Azure também desempenha um papel importante na obtenção do desempenho de E/S necessário.

Para discos de log do SAP HANA executados no SSD Premium do Azure v1, use uma das seguintes tecnologias em locais que contêm /hana/log para produção:

Essas tecnologias são necessárias para atender consistentemente à latência de armazenamento necessária de menos de 1 ms.

O SSD Premium v2 do Azure foi projetado para cargas de trabalho críticas de desempenho, como o SAP. O Acelerador de Gravação não é necessário quando /hana/log está em execução no SSD Premium v2. Para obter informações sobre os benefícios da solução de armazenamento e suas limitações atuais, confira Implantar um SSD Premium v2.

Para obter detalhes sobre os requisitos de desempenho do SAP HANA, confira a Nota SAP 1943937 – Ferramenta de verificação de configuração de hardware.

  • Design de armazenamento focado em economia para sistemas de não produção. Para ambientes SAP HANA que não exigem desempenho máximo de armazenamento em todas as situações, você pode usar uma arquitetura de armazenamento otimizada para custo. Essa opção de otimização de armazenamento pode ser aplicada a sistemas de produção pouco usados ou a alguns ambientes SAP HANA que não são de produção. A opção de armazenamento com custo otimizado usa uma combinação de SSDs padrão em vez de SSDs Premium ou Ultra usadas para ambientes de produção. Ela também combina os sistemas de arquivos /hana/data e /hana/log em um único conjunto de discos. Diretrizes e práticas recomendadas estão disponíveis para a maioria dos tamanhos de VM. Se você usar o Azure NetApp Files para SAP HANA, poderá usar volumes reduzidos de tamanho para atingir a mesma meta.

  • Redimensionar o armazenamento ao aumentar a escala. Quando você redimensiona uma máquina virtual devido a demandas de negócios alteradas ou a um tamanho de banco de dados cada vez maior, a configuração de armazenamento pode ser alterada. O Azure dá suporte à expansão de disco online, sem nenhuma interrupção no serviço. Com uma configuração de disco distribuído, conforme usado para o SAP HANA, uma operação de redimensionamento deve ser feita igualmente a todos os discos no grupo de volumes. A adição de mais discos a um grupo de volumes pode desequilibrar os dados distribuídos. Se estiver adicionando mais discos a uma configuração de armazenamento, será muito preferível criar um volume de armazenamento em novos discos. Em seguida, copie o conteúdo durante o tempo de inatividade e modifique os pontos de montagem. Finalmente, descarte o grupo de volumes antigo e os discos subjacentes.

  • Grupo de volumes de aplicativo do Azure NetApp Files. Para implantações com arquivos SAP HANA contidos em volumes do NFS Azure NetApp Files, os grupos de volume de aplicativos permitem implantar todos os volumes de acordo com as práticas recomendadas. Esse processo também garante o desempenho ideal para o banco de dados SAP HANA. Detalhes estão disponíveis sobre como proceder com este processo. Ele requer intervenção manual. Reserve algum tempo para a criação.

Alta disponibilidade

A arquitetura anterior ilustra uma implantação altamente disponível, com o SAP HANA contido em duas ou mais máquinas virtuais. Os componentes a seguir são usados.

Balanceadores de carga.O Azure Load Balancer é usado para distribuir o tráfego para a máquina virtual SAP HANA. Ao incorporar o Azure Load Balancer em uma implantação zonal do SAP, selecione o balanceador de carga de SKU padrão. O balanceador de SKU Básico não dá suporte à redundância zonal e ao preterido. Nessa arquitetura, o Load Balancer atua como o endereço IP virtual do SAP HANA. O tráfego de rede é enviado para a VM ativa com a instância de banco de dados primária. A arquitetura ativa/habilitada para leitura do SAP HANA está disponível opcionalmente (SLES/RHEL), em que um segundo IP virtual endereçado no balanceador de carga é usado para direcionar o tráfego de rede para a instância secundária do SAP HANA em outra VM para cargas de trabalho com uso intenso de leitura.

O Standard Load Balancer fornece uma camada de segurança por padrão. As máquinas virtuais que estão por trás do Standard Load Balancer não têm conectividade de saída com a Internet. Para habilitar a Internet de saída nessas máquinas virtuais, você precisa atualizar a configuração do Standard Load Balancer. Além disso, você também pode usar um Gateway da NAT do Azure para obter conectividade de saída.

Para clusters de banco de dados SAP HANA, você deve habilitar o DSR (Retorno Direto do Servidor), também conhecido como IP flutuante. Esse recurso permite que o servidor responda com o endereço IP do front-end do balanceador de carga.

Opções de implantação. No Azure, a implantação da carga de trabalho SAP pode ser regional ou zonal, dependendo dos requisitos de disponibilidade e resiliência dos aplicativos SAP. O Azure fornece diferentes opções de implantação, como Conjuntos de Dimensionamento de Máquinas Virtuais com orquestração flexível (FD=1), zonas de disponibilidade e conjuntos de disponibilidade para melhorar a disponibilidade de recursos. Para obter uma compreensão abrangente das opções de implantação disponíveis e sua aplicabilidade em diferentes regiões do Azure (inclusive entre zonas, em uma única zona ou em uma região sem zonas), confira Arquitetura e cenários de alta disponibilidade para SAP NetWeaver.

SAP HANA. Para alta disponibilidade, o SAP HANA é executado em duas ou mais máquinas virtuais Linux. A HSR (Replicação de Sistema do SAP HANA) é usada para replicar dados entre os sistemas SAP HANA primário e secundário (réplica). O HSR também é usado para recuperação de desastre entre regiões ou entre zonas. Dependendo da latência na comunicação entre as máquinas virtuais, a replicação síncrona pode ser usada em uma região. A HSR entre regiões para recuperação de desastres, na maioria dos casos, é executada de maneira assíncrona.

Para o cluster do Linux Pacemaker, você precisa decidir qual mecanismo de isolamento de cluster usar. A cerca de cluster é o processo de isolar uma VM com falha do cluster e reiniciá-la. Para o RHEL (RedHat Enterprise Linux), o único mecanismo de cerca com suporte para o Pacemaker no Azure é o agente de cerca do Azure. Para o SLES (SUSE Linux Enterprise Server), você pode usar o agente de cerca do Azure ou o SBD (Dispositivo de Bloco STONITH). Compare os tempos de failover de cada solução e, se houver diferença, escolha uma solução com base no RTO (Objetivo de Tempo de Recuperação) necessário.

Agente de isolamento do Azure. Esse método de isolamento depende da API do ARM do Azure, com o Pacemaker consultando a API do ARM sobre o status de ambas as VMs do SAP HANA no cluster. Se uma VM falhar, por exemplo, o sistema operacional não responde ou falha da VM, o gerenciador de cluster usará novamente a API do ARM para reiniciar a VM e, se necessário, falhará no banco de dados do SAP HANA para o outro nó ativo. Para essa finalidade, uma entidade de nome de serviço (SPN) com uma função personalizada para consultar e reiniciar VMs é usada para autorizar a API do ARM. Nenhuma outra infraestrutura é necessária. As VMs SBD nos diagramas de arquitetura não serão implantadas se o agente de cerca do Azure for usado.

SBD. O SBD (Dispositivo de Bloco STONITH) usa um disco acessado como dispositivo de bloco (bruto, sem sistema de arquivos) pelo gerenciador de cluster. Esse disco ou discos, se vários, atuam como um voto. Cada um dos dois nós de cluster que executam o SAP HANA acessa os discos do SDB e lê/grava periodicamente neles pequenos bits de informações sobre status. Portanto, cada nó de cluster sabe o status do outro sem depender apenas da rede entre as VMs.

Preferencialmente, três VMs pequenas são implantadas em um conjunto de disponibilidade ou configuração de zona de disponibilidade. Cada VM exporta pequenas partes de um disco como um dispositivo de bloco que é acessado pelos dois nós de cluster do SAP HANA. Três VMs SBD garantem que membros de votação suficientes estejam disponíveis em caso de tempo de inatividade planejado ou não planejado de qualquer VM do SBD.

Como alternativa ao uso de VMs SBD, o disco compartilhado do Azure pode ser usado. Os nós de cluster do SAP HANA acessam o único disco compartilhado. O disco compartilhado pode ser redundante localmente (LRS) ou na zona (ZRS), se o ZRS estiver disponível em sua região do Azure.

Recuperação de desastre

A arquitetura a seguir mostra um ambiente HANA de produção no Azure que fornece recuperação de desastre. A arquitetura incorpora zonas de disponibilidade.

Diagrama que mostra uma arquitetura com recuperação de desastres.

Para obter estratégias de recuperação de desastres e detalhes de implementação, consulte Visão geral de recuperação de desastres e diretrizes de infraestrutura para carga de trabalho SAP e Diretrizes de recuperação de desastres para aplicativos SAP.

Observação

Se houver um desastre regional que cause um grande evento de failover para muitos clientes do Azure em uma região, a capacidade de recursos da região de destino não será garantida. Assim como todos os serviços do Azure, o Azure Site Recovery continua adicionando recursos. Para obter as informações mais recentes sobre a replicação do Azure para Azure, confira a matriz de suporte.

Além de uma implementação local de alta disponibilidade de dois nós, o HSR dá suporte à replicação multiplataforma e multidestino. O HSR, portanto, dá suporte à replicação entre zonas e inter-regional. A replicação multidestino está disponível para o SAP HANA 2.0 SPS 03 e posterior.

Verifique a capacidade de recurso da região de destino.

Azure NetApp Files. Como opção, os Azure NetApp Files podem ser usados como uma solução de armazenamento escalonável e de alto desempenho para arquivos de log e dados do SAP HANA. Azure NetApp Files dá suporte a instantâneos para backup rápido, recuperação e replicação local. Para replicação de conteúdo entre regiões, a replicação entre regiões dos Azure NetApp Files pode ser usada para replicar os dados de instantâneo entre duas regiões. Detalhes sobre replicação entre regiões e um artigo que descreve todos os aspectos para recuperação de desastre com Azure NetApp Files estão disponíveis.

Backup

Há várias maneiras de fazer backup dos dados do SAP HANA. Depois de migrar para o Azure, você pode continuar a usar as soluções de backup de parceiros que você já tenha. O Azure oferece duas abordagens nativas: backup no nível de arquivo do SAP HANA e Backup do Azure para o SAP HANA pela interface Backint.

Para backup no nível de arquivo do SAP HANA, você pode usar sua ferramenta preferida, como hdbsql ou SAP HANA Studio, e armazenar os arquivos de backup em um volume de disco local. Um ponto de montagem comum para esse volume de backup é /hana/backup. As políticas de backup definem o período de retenção de dados no volume. Assim que o backup for feito, uma tarefa agendada deverá copiar os arquivos de backup para o Armazenamento de Blobs do Azure para segurança. Os arquivos de backup locais são mantidos para recuperação rápida.

O Backup do Azure oferece uma solução simples e de nível empresarial para cargas de trabalho em execução em máquinas virtuais. Backup do Azure para SAP HANA tem integração completa com o catálogo de backup do SAP HANA e garante recuperações consistentes com o banco de dados, completas ou pontuais. O Backup do Azure tem certificação BackInt pela SAP. Confira também as perguntas frequentes do Backup do Azure e a matriz de suporte.

Azure NetApp Files traz suporte para backups baseados em instantâneo. A integração com o SAP HANA para instantâneos consistentes do aplicativo é por meio da ferramenta Azure Application Consistent Snapshot (AzAcSnap). Os instantâneos criados podem ser usados para restaurar um novo volume para restauração do sistema ou cópia do banco de dados SAP HANA. Instantâneos criados podem ser usados para recuperação de desastre, em que atuam como ponto de restauração com logs do SAP HANA salvos em um volume NFS diferente.

Monitoramento

Para monitorar cargas de trabalho no Azure, o Azure Monitor permite que você colete, analise e responda a telemetria dos ambientes locais e de nuvem, de maneira abrangente.

Para aplicativos SAP executados no SAP HANA e em outras soluções de banco de dados importantes, confira Azure Monitor para soluções SAP para saber como o Azure Monitor para SAP pode ajudar a gerenciar a disponibilidade e o desempenho dos serviços SAP.

Segurança

Muitas medidas de segurança são usadas para proteger a confidencialidade, a integridade e a disponibilidade de um cenário SAP. O SAP tem o próprio UME (Mecanismo de Gerenciamento de Usuários) para controlar o acesso e a autorização baseados em função no aplicativo e nos bancos de dados SAP. Para saber mais, confira Segurança do SAP HANA — Uma visão geral.

Para dados inativos, diferentes funcionalidades de criptografia fornecem segurança da seguinte maneira:

  • Junto com a tecnologia de criptografia nativa do SAP HANA, considere o uso de uma solução de criptografia de um parceiro que dê suporte a chaves gerenciadas pelo cliente.

  • Para criptografar discos de máquina virtual, você pode usar as funcionalidades descritas em Visão geral das opções de criptografia de disco gerenciado.

  • Servidores de banco de dados SAP: use Transparent Data Encryption oferecida pelo provedor DBMS (por exemplo, tecnologia de criptografia nativa do SAP HANA) para ajudar a proteger dados e arquivos de log e criptografar backups.

  • Os dados no armazenamento físico do Azure (criptografia do lado do servidor) são criptografados automaticamente em repouso com uma chave gerenciada do Azure. Você também pode escolher uma CMK (chave gerenciada pelo cliente) em vez da chave gerenciada do Azure.

  • Para obter informações sobre suporte da Azure Disk Encryption em distribuições, versões e imagens específicas do Linux, confira Azure Disk Encryption para VMs Linux.

Observação

Não combine a tecnologia de criptografia nativa do SAP HANA com Azure Disk Encryption nem criptografia baseada em host no mesmo volume de armazenamento. Além disso, os discos de inicialização do sistema operacional para máquinas virtuais Linux não dão suporte ao Azure Disk Encryption. Em vez disso, ao usar a criptografia nativa do SAP HANA, combine-a com a criptografia do lado do servidor, que é habilitada automaticamente. Lembre-se de que o uso de chaves gerenciadas pelo cliente pode impactar a taxa de transferência de armazenamento.

Para segurança de rede, use NSGs (Grupos de Segurança de Rede) e Firewall do Azure ou um dispositivo virtual de rede da seguinte maneira:

  • Use NSGs para proteger e controlar o tráfego entre sub-redes e camadas de aplicativo/banco de dados. Aplique somente NSGs a sub-redes. A aplicação de NSGs a NICs e sub-redes simultaneamente costuma causar problemas durante o diagnóstico e deve ser usada raramente.

  • Use Firewall do Azure ou dispositivo virtual de rede do Azure para inspecionar e controlar o roteamento do tráfego da rede virtual hub para a rede virtual spoke onde estão os aplicativos SAP, bem como controlar a conectividade de saída com a Internet.

Para usuário e autorização, implemente o RBAC (Controle de Acesso Baseado em Função) e os bloqueios de recursos da seguinte maneira:

  • Siga o princípio de privilégios mínimos, usando o RBAC para atribuir privilégios administrativos em recursos no nível de IaaS que hospedam a solução SAP no Azure. A finalidade essencial do RBAC é a segregação e o controle de tarefas dos usuários/grupo. O RBAC concede aos usuários apenas o acesso necessário aos recursos para executarem seus trabalhos.

  • Use bloqueios de recursos para ajudar a evitar alterações acidentais ou mal-intencionadas. Os bloqueios de recursos ajudam a impedir que os administradores excluam ou modifiquem recursos críticos do Azure em que a solução SAP está localizada.

Veja mais recomendações de segurança nestes artigos da Microsoft e da SAP.

Comunidades

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

Colaboradores

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

Autor principal:

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

Próximas etapas

Saiba mais sobre as tecnologias dos componentes:

Explorar arquiteturas relacionadas: