Editar

Partilhar via

Executar o SAP HANA para máquinas virtuais do Linux numa arquitetura de aumento vertical no Azure

Azure
Azure Virtual Machines

Esta arquitetura de referência mostra um conjunto de práticas comprovadas para executar o SAP HANA em um ambiente de expansão altamente disponível que oferece suporte à recuperação de desastres no Azure. Essa implementação se concentra apenas na camada de banco de dados.

Arquitetura

Esta arquitetura de referência descreve um sistema de produção comum. Você pode escolher os tamanhos das máquinas virtuais para acomodar as necessidades da sua organização. Essa configuração também pode ser reduzida a uma máquina virtual, dependendo dos requisitos de negócios.

O diagrama a seguir mostra uma arquitetura de referência para o 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.

Nota

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

Fluxo de Trabalho

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 nos requisitos de negócios (RTO, RPO, expectativas de tempo de atividade, função do sistema) e potencialmente reduzidos a uma única VM. O layout da rede é simplificado para demonstrar os princípios de arquitetura desse ambiente SAP e não se destina a descrever uma rede corporativa completa.

Rede

Redes virtuais. O serviço de Rede Virtual do Azure conecta recursos do Azure entre si com segurança aprimorada. Nessa arquitetura, a rede virtual se conecta a um ambiente local por meio de um gateway de Rota Expressa implantado no hub de uma topologia hub-spoke. O banco de dados SAP HANA está contido em sua própria rede virtual falada. As redes virtuais spoke contêm uma sub-rede para as máquinas virtuais (VMs) de banco de dados.

Se os aplicativos que se conectam ao SAP HANA estiverem sendo executados em VMs, as VMs de aplicativos deverão estar localizadas na mesma rede virtual, mas dentro de uma sub-rede de aplicativo dedicada. Como alternativa, se a conexão SAP HANA não for o banco de dados primário, as VMs do aplicativo poderão ser localizadas em outras redes virtuais. A separação em sub-redes por carga de trabalho permite facilitar a ativação de grupos de segurança de rede (NSG) para definir regras de segurança aplicáveis apenas a VMs do SAP HANA.

Gateway redundante de zona. Um gateway conecta redes distintas, estendendo sua rede local para a rede virtual do Azure. Recomendamos que você use a Rota Expressa para criar conexões privadas que não passem pela Internet pública, mas você também pode usar uma conexão site a site. Use gateways de VPN ou Rota Expressa do Azure com redundância de zona para se proteger contra falhas de zona. Consulte Gateways de rede virtual com redundância de zona para entender as diferenças entre uma implantação zonal e uma implantação com redundância de zona. Vale a pena mencionar aqui que os endereços IP usados precisam ser de SKU padrão 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 de banco de dados e de aplicativos são protegidas com NSGs específicos da carga de trabalho.

Grupos de segurança de aplicativos (ASG). Para definir políticas de segurança de rede refinadas dentro de seus NSGs com base em cargas de trabalho centradas em aplicativos, use grupos de segurança de aplicativos em vez de endereços IP explícitos. Eles permitem agrupar interfaces de rede de VMs por nome e ajudam a proteger aplicativos filtrando o tráfego de segmentos confiáveis da sua rede.

Placas de interface de rede (NICs). As placas de interface de rede permitem toda a comunicação entre máquinas virtuais em uma rede virtual. As implantações SAP locais tradicionais implementam várias NICs por máquina para segregar o tráfego administrativo do tráfego comercial.

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. Mas se sua organização precisar segregar o tráfego, você poderá implantar várias 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 diferentes políticas de controle de acesso 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 obter um esboço completo, consulte a nota SAP 962955. (Para acessar as notas SAP, você precisa de uma conta do SAP Service Marketplace.)

Nota

Conforme especificado no SAP Note 2731110, não coloque nenhum dispositivo virtual de rede (NVA) entre o aplicativo e as camadas de banco de dados para qualquer pilha de aplicativos SAP. Isso introduz um tempo de processamento significativo de pacotes de dados e diminui inaceitavelmente o desempenho do aplicativo.

Máquinas virtuais

Essa arquitetura usa máquinas virtuais (VM). O Azure oferece escala de nó único até 32 Tebibytes (TiB) de memória em máquinas virtuais. O SAP Certified and Supported SAP HANA Hardware Directory lista as máquinas virtuais certificadas para o banco de dados SAP HANA. Para obter detalhes sobre o suporte SAP para tipos de máquina virtual e métricas de taxa de transferência (SAPS), consulte SAP Note 1928533 - SAP Applications on Microsoft Azure: Produtos suportados e tipos de VM do Azure. (Para aceder a esta e a outras notas SAP, é necessária uma conta SAP Service Marketplace.)

A Microsoft e a SAP certificam em conjunto uma variedade de tamanhos de máquinas virtuais para cargas de trabalho do SAP HANA. Por exemplo, implantações menores podem ser executadas em uma máquina virtual Edsv4 ou Edsv5 com 160 GiB ou mais de RAM. Para suportar os maiores tamanhos de memória 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 2. As VMs de 2ª geração suportam os principais recursos que não estão disponíveis para VMs de 1ª geração. Para o SAP HANA, isso é particularmente importante porque algumas famílias de VMs, como Mv2, Mdsv2, Msv3 e Mdsv3 são suportadas apenas como VMs Gen2. Da mesma forma, a certificação SAP no Azure pode exigir que VMs mais recentes sejam Gen2, mesmo que o Azure permita Gen1 e Gen2. Para obter detalhes, consulte SAP Note 1928533 - SAP Applications on Microsoft Azure: Produtos suportados e tipos de VM do Azure.

Como todas as outras VMs que suportam SAP HANA permitem a escolha entre Gen2 ou Gen1+2 seletivamente, recomendamos que você implante todas as VMs SAP apenas como Gen2. Isso também se aplica a VMs com poucos requisitos de memória. Mesmo a menor SAP HANA VM pode ser executada como Gen2 VM e pode ser, quando deslocalizada, redimensionada para a maior VM disponível em sua região.

Grupos de colocação de proximidade. Para otimizar a latência da rede, você pode usar grupos de posicionamento de proximidade, que priorizam a colocalização. As VMs estão localizadas no mesmo datacenter para minimizar a latência entre o SAP HANA e a conexão de VMs de aplicativos. Para a arquitetura SAP HANA em si, grupos de posicionamento de 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 de proximidade, você deve adicionar o conjunto de disponibilidade do banco de dados ao grupo de posicionamento de proximidade do sistema SAP somente quando isso for necessário para a latência entre o aplicativo SAP e o tráfego do banco de dados. Para obter mais informações sobre os cenários de uso de grupos de posicionamento de proximidade, consulte Opções de configuração para minimizar a latência da rede com aplicativos SAP. Como os grupos de posicionamento de proximidade restringem as cargas de trabalho a um único datacenter, um grupo de posicionamento de proximidade não pode abranger várias zonas de disponibilidade. Implantações de alto volume que fazem referência a grupos de posicionamento de 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 ser dimensionadas 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 HANA de vários nós. Para aplicativos OLTP (processamento de transações online), a capacidade total de memória de expansão pode chegar a 4 x 23 TiB. Para aplicativos OLAP (processamento analítico online), a capacidade de memória de expansão pode chegar a 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 que executam Red Hat Enterprise Linux ou SUSE Linux Enterprise Server e usar de Arquivos NetApp do Azure para os volumes de armazenamento compartilhados. Para identificar as SKUs de VM certificadas que suportam configurações de expansão, consulte o Certified and Supported SAP HANA Hardware Directory. Analise 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 nos Arquivos NetApp do Azure. As diretrizes para implantação de armazenamento com discos gerenciados estão em detalhes no documento de configurações de armazenamento de máquina virtual do SAP HANA Azure. Como alternativa aos discos gerenciados, os volumes NFS do Azure NetApp Files podem ser usados como solução de armazenamento para o SAP HANA.

Para obter IOPS (operações de entrada/saída por segundo) e taxa de transferência de armazenamento em disco elevadas, as práticas comuns na otimização do desempenho do volume de armazenamento também se aplicam ao layout de armazenamento do Azure. Por exemplo, a combinação de vários discos com o LVM para criar um volume de disco distribuído melhora o desempenho de E/S. O cache de disco do Azure também desempenha um papel significativo 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 armazenam /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 do Azure v2 foi projetado para cargas de trabalho críticas de desempenho, como o SAP. O Acelerador de Escrita não é necessário quando /hana/log está sendo executado no SSD Premium v2. Para obter informações sobre os benefícios e limitações atuais dessa solução de armazenamento, consulte Implantar um SSD Premium v2.

Para obter detalhes sobre os requisitos de desempenho do SAP HANA, consulte SAP Note 1943937 - Hardware Configuration Check Tool.

  • Design de armazenamento consciente dos custos para sistemas que não são de 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 utilizados 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 dos SSDs Premium ou Ultra usados para ambientes de produção. Ele 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 for SAP HANA, poderá usar volumes de tamanho reduzido para atingir a mesma meta.

  • Redimensionamento do armazenamento durante a expansão. Quando você redimensiona uma máquina virtual devido a demandas de negócios alteradas ou devido ao aumento do tamanho do banco de dados, a configuração de armazenamento pode ser alterada. O Azure suporta a expansão de disco online, sem qualquer interrupção do serviço. Com uma configuração de disco distribuído, como usado para o SAP HANA, uma operação de redimensionamento deve ser feita igualmente para todos os discos no grupo de volumes. A adição de mais discos a um grupo de volumes pode potencialmente desequilibrar os dados distribuídos. Se você estiver adicionando mais discos a uma configuração de armazenamento, é preferível criar um novo 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 volume de aplicativos Arquivos NetApp do Azure. Para implantações com arquivos SAP HANA contidos em volumes NFS do Azure NetApp Files, os grupos de volumes de aplicativos permitem implantar todos os volumes de acordo com as práticas recomendadas. Esse processo também garante o desempenho ideal para seu banco de dados SAP HANA. Estão disponíveis detalhes sobre como proceder com este processo. Requer intervenção manual. Reserve algum tempo para a criação.

Elevada disponibilidade

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

Balanceadores de carga.O Azure Load Balancer é usado para distribuir tráfego para máquinas virtuais SAP HANA. Ao incorporar o Azure Load Balancer em uma implantação zonal do SAP, certifique-se de selecionar o balanceador de carga SKU padrão. O balanceador de SKU básico não suporta redundância zonal e foi 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 instância de banco de dados primária. A arquitetura ativa/habilitada para leitura do SAP HANA está opcionalmente disponível (SLES/RHEL), onde 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 de leitura intensa.

O Standard Load Balancer fornece uma camada de segurança por padrão. As máquinas virtuais que estão por trás do Balanceador de Carga Padrão 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 Balanceador de Carga Padrão. Além disso, você também pode usar um Gateway NAT do Azure para obter conectividade de saída.

Para clusters de banco de dados SAP HANA, você deve habilitar o Direct Server Return (DSR), 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áquina Virtual 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 (incluindo entre zonas, dentro de uma única zona ou em uma região sem zonas), consulte 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. O SAP HANA System Replication (HSR) é usado para replicar dados entre os sistemas SAP HANA primário e secundário (réplica). O HSR também é usado para recuperação de desastres entre regiões ou entre zonas. Dependendo da latência na comunicação entre suas máquinas virtuais, a replicação síncrona pode ser usada em uma região. O HSR entre regiões para recuperação de desastres será, na maioria dos casos, executado de forma assíncrona.

Para o cluster Linux Pacemaker, você precisa decidir qual mecanismo de vedação de cluster usar. A cerca de cluster é o processo de isolar uma VM com falha do cluster e reiniciá-la. Para o RedHat Enterprise Linux (RHEL), o único mecanismo de vedação suportado para o Pacemaker no Azure é o agente de vedação do Azure. Para o SUSE Linux Enterprise Server (SLES), você pode usar o agente de cerca do Azure ou o STONITH Block Device (SBD). Compare os tempos de failover para cada solução e, se houver uma diferença, escolha uma solução com base em seus requisitos de negócios para RTO (Recovery Time Objetive, objetivo de tempo de recuperação).

Agente de cerca do Azure. Esse método de vedação depende da API ARM do Azure, com o Pacemaker consultando a API ARM sobre o status de ambas as VMs do SAP HANA no cluster. Se uma VM falhar, por exemplo, sistema operacional sem resposta ou falha da VM, o gerenciador de cluster usará novamente a API ARM para reiniciar a VM e, se necessário, falhará o banco de dados 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 em relação à API 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 dispositivo de bloco STONITH (SBD) usa um disco que é acessado como dispositivo de bloco (bruto, sem sistema de arquivos) pelo gerenciador de cluster. Este disco, ou discos se múltiplos, atua como um voto. Cada um dos dois nós de cluster que executam o SAP HANA acessa os discos SDB e lê/grava periodicamente neles pequenos bits de informações sobre o status. Assim, cada nó de cluster sabe o status sobre o outro sem depender apenas da rede entre as VMs.

De preferência, três pequenas VMs 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 votantes suficientes estejam disponíveis em caso de tempo de inatividade planejado ou não planejado para qualquer VM SBD.

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

Recuperação após desastre

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

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

Para obter estratégias de DR 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.

Nota

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. Como todos os serviços do Azure, o Azure Site Recovery continua a adicionar recursos e capacidades. Para obter as informações mais recentes sobre a replicação do Azure para o Azure, consulte a matriz de suporte.

Além de uma implementação local de alta disponibilidade de dois nós, o HSR oferece suporte à replicação multicamadas e multidestino . Portanto, o HSR suporta replicação entre zonas e entre regiões. A replicação multidestino está disponível para SAP HANA 2.0 SPS 03 e posterior.

Certifique-se de verificar a capacidade de recursos da região de destino.

Arquivos NetApp do Azure. Como opção, os Arquivos NetApp do Azure podem ser usados para fornecer uma solução de armazenamento escalável e de alto desempenho para dados e arquivos de log do SAP HANA. Os Arquivos NetApp do Azure dão suporte a instantâneos para backup, recuperação e replicação local rápidos. Para replicação de conteúdo entre regiões, a Replicação entre Regiões de Arquivos NetApp do Azure pode ser usada para replicar os dados de instantâneo entre duas regiões. Estão disponíveis detalhes sobre a replicação entre regiões e um whitepaper que descreve todos os aspetos da recuperação de desastres com os Ficheiros NetApp do Azure.

Backup

O backup dos dados do SAP HANA pode ser feito de várias maneiras. Depois de migrar para o Azure, você pode continuar a usar quaisquer soluções de backup de parceiros existentes que já tenha. O Azure fornece duas abordagens nativas: backup no nível de arquivo do SAP HANA e Backup do Azure para SAP HANA na 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. Suas políticas de backup definirão 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 Blob do Azure para proteção. Os arquivos de backup locais são mantidos para uma recuperação rápida.

O Backup do Azure oferece uma solução simples de nível empresarial para cargas de trabalho executadas em máquinas virtuais. O Backup do Azure para SAP HANA fornece integração total com o catálogo de backup do SAP HANA e garante recuperações consistentes com o banco de dados, completas ou point-in-time. O Backup do Azure é certificado pela SAP. Consulte também as Perguntas frequentes e a matriz de suporte do Backup do Azure.

Os Arquivos NetApp do Azure oferecem suporte para backups baseados em instantâneo. A integração com o SAP HANA para instantâneos consistentes de aplicativos é feita por meio da ferramenta Azure Application Consistent Snapshot (AzAcSnap). Os snapshots criados podem ser usados para restaurar um novo volume para restauração do sistema ou copiar o banco de dados SAP HANA. Os snapshots criados podem ser usados para recuperação de desastres, onde atuam como ponto de restauração com logs do SAP HANA salvos em um volume NFS diferente.

Monitorização

Para monitorizar as suas cargas de trabalho no Azure, o Azure Monitor permite-lhe recolher, analisar e agir de forma abrangente na telemetria a partir dos seus ambientes na nuvem e no local.

Para aplicativos SAP executados no SAP HANA e em outras soluções de banco de dados importantes, consulte Azure Monitor for SAP solutions para saber como o Azure Monitor for SAP pode ajudá-lo 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, integridade e disponibilidade de um cenário SAP. Para proteger o acesso do usuário, por exemplo, a SAP tem seu próprio User Management Engine (UME) para controlar o acesso e a autorização baseados em funções no aplicativo SAP e nos bancos de dados. Para obter mais informações, consulte Segurança do SAP HANA — uma visão geral.

Para dados em repouso, diferentes funcionalidades de criptografia fornecem segurança da seguinte forma:

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

  • Para criptografar discos de máquina virtual, você pode usar as funcionalidades descritas em Visão geral da criptografia de disco.

  • Servidores de banco de dados SAP: use a criptografia de dados transparente oferecida pelo provedor DBMS (por exemplo, a tecnologia de criptografia nativa SAP HANA) para ajudar a proteger seus dados e arquivos de log e garantir que os backups também sejam criptografados.

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

  • Para obter informações sobre o suporte da Criptografia de Disco do Azure em distros, versões e imagens Linux específicas, consulte Azure Disk Encryption for Linux VMs.

Nota

Não combine a tecnologia de criptografia nativa do SAP HANA com a Criptografia de Disco do Azure ou a 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 oferecem suporte à Criptografia de Disco do Azure. Em vez disso, ao usar a criptografia nativa do SAP HANA, combine-a com a criptografia do lado do servidor, que é ativada automaticamente. Lembre-se de que o uso de chaves gerenciadas pelo cliente pode afetar a taxa de transferência de armazenamento.

Para segurança de rede, use NSGs (grupos de segurança de rede) e o 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 aplicativos/bancos de dados. Aplique apenas NSGs a sub-redes. Os NSGs aplicados à NIC e à sub-rede muitas vezes levam a problemas durante a solução de problemas e devem ser usados raramente ou nunca.

  • Use o Firewall do Azure ou o dispositivo virtual de rede do Azure para inspecionar e controlar o roteamento do tráfego da rede virtual do hub para a rede virtual spoke onde estão seus aplicativos SAP e também para controlar sua conectividade de saída com a Internet.

Para Usuário e Autorização, implemente o controle de acesso baseado em função (RBAC) e bloqueios de recursos da seguinte maneira:

  • Siga o princípio do menor privilégio, usando RBAC para atribuir privilégios administrativos em recursos de nível IaaS que hospedam sua solução SAP no Azure. O objetivo fundamental do RBAC é a segregação e controle de funções para seus usuários/grupo. O RBAC foi projetado para conceder apenas a quantidade de acesso aos recursos necessários para permitir que os usuários façam seus trabalhos.

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

Mais recomendações de segurança podem ser encontradas em estes artigos da Microsoft e SAP .

Comunidades

As comunidades podem responder às suas perguntas e ajudá-lo a configurar uma implementação com êxito. Considere as seguintes comunidades:

Contribuidores

Este artigo é mantido pela Microsoft. Foi originalmente escrito pelos seguintes contribuidores.

Autor principal:

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

Próximos passos

Saiba mais sobre as tecnologias de componentes:

Explore arquiteturas relacionadas: