Editar

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 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.

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 gateway de Rota Expressa implantado no hub de uma topologia hub-spoke. O banco de dados SAP HANA está contido na 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 estiverem sendo executados em VMs, as VMs de aplicativo deverão estar localizadas 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. Os gateways do Azure ExpressRoute ou da VPN podem ser implantados em zonas para proteção 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. 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 rede 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 de aplicativos (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 agrupar interfaces 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é 23,5 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 ou Edsv5 com 160 GiB ou mais de RAM. Para oferecer suporte aos maiores tamanhos de memória SAP HANA em máquinas virtuais, até 23 TiB, você pode usar máquinas virtuais da série Mv2. Os tipos de máquina virtual M208 atingem aproximadamente 260.000 SAPS e os tipos de máquina virtual M832ixs alcançam aproximadamente 795.900 SAPS.

Máquinas virtuais de 2ª geração (Gen2). Ao implantar VMs, você pode usar VMs de geração 1 ou 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 VMs, como Mv2 e Mdsv2, são suportadas apenas como VMs Gen2. Da mesma forma, a certificação SAP no Azure para algumas VMs mais recentes pode exigir que elas sejam apenas Gen2 para suporte total, mesmo que o Azure permita ambos. Confira mais detalhes na Nota SAP 1928533 – Aplicativos SAP no Microsoft Azure: produtos e tipos de VM do Azure com suporte

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

Grupos de posicionamento de proximidade (PPG). Para otimizar a latência da rede, você pode usar grupos de posicionamento de proximidade, que favorecem a colocação, o que significa que as máquinas virtuais estão no mesmo datacenter para minimizar a latência entre o SAP HANA e as VMs de aplicativos conectadas. Para a própria arquitetura do SAP HANA, PPGs não são necessários. Eles são apenas uma opção para colocação do SAP HANA com VMs da camada de aplicativo. Devido a possíveis restrições com PPGs, a adição do AvSet de banco de dados ao PPG do sistema SAP deve ser feita de forma esparsa e somente quando necessário devido a latência entre o aplicativo SAP e o tráfego de banco de dados. Para saber mais sobre os cenários de uso de PPGs, confira a documentação vinculada. Como os PPGs restringem cargas de trabalho a um único datacenter, um PPG não pode abranger várias zonas de disponibilidade.

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é 23 TiB em uma instância.

Se sua carga de trabalho exceder o tamanho máximo da máquina virtual, recomendamos que você use configurações HANA de vários nós. Para aplicativos OLTP (processamento de transações on-line), a capacidade total de memória de expansão pode ser de até 4 x 23 TiB. Para aplicativos OLAP (processamento analítico on-line), 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 o Red Hat Enterprise Linux ou o SUSE Linux Enterprise Server, usando Azure NetApp Files para os volumes de armazenamento compartilhado.

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 significativo na obtenção do desempenho de E/S necessário.

Para discos de log do SAP HANA executados no SSD Premium v1 do Azure, 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á sendo executado no SSD Premium v2. Para obter informações sobre os benefícios e as 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, confira a Nota SAP 1943937 – Ferramenta de verificação de configuração de hardware.

  • Projeto de armazenamento consciente de custos para sistemas que não são de produção. Para ambientes SAP HANA que não exigem o máximo desempenho de armazenamento em todas as situações, você pode usar uma arquitetura de armazenamento otimizada para o 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 que são 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 o mesmo objetivo.

  • Redimensionamento do armazenamento durante a expansão. Quando você redimensiona uma máquina virtual devido a demandas de negócios alteradas ou devido a um tamanho de banco de dados crescente, 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 você estiver adicionando mais discos a uma configuração de armazenamento, é muito 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 volumes de aplicativos Azure NetApp Files. 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 o banco de dados SAP HANA. Estão disponíveis detalhes sobre como proceder com este processo. Requer intervenção manual. Dê um tempo para a criação.

Alta disponibilidade

A arquitetura anterior descreve 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 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 de SKU padrão. O balanceador de SKU básico não oferece suporte à redundância zonal. 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 onde a instância do banco de dados primário é executada. A arquitetura ativa/habilitada para leitura do SAP HANA está disponível (SLES/RHEL), em que um segundo IP virtual endereçado no balanceador de carga é usado para direcionar o tráfego de rede à instância secundária do SAP HANA em outra VM para cargas de trabalho intensas de leitura.

O Standard Load Balancer fornece uma camada de segurança por padrão. As máquinas virtuais que estão atrá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 NAT do Azure para obter conectividade de saída.

Para clusters de banco de dados do SAP HANA, você deve habilitar o DSR (Retorno do Servidor Direto), também conhecido como IP Flutuante. Esse recurso permite que o servidor responda ao endereço IP do front-end do balanceador de carga. Essa conexão direta impede que o balanceador de carga se torne um gargalo no caminho da transmissão de dados.

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 aprimorar 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), 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. 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 Linux Pacemaker, você precisa decidir qual mecanismo de vedação de cluster usar. A vedação 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 SUSE Linux Enterprise Server (SLES), você pode usar o agente de cerca do Azure ou o SBD (STONITH Block Device). Compare os tempos de failover de cada solução e, se houver diferença, escolha uma solução com base em seus requisitos de negócios para o RTO (Recovery Time Objective, 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 de VM, o gerenciador de cluster usará novamente a API ARM para reiniciar a VM e, se necessário, transferirá o banco de dados SAP HANA para o outro nó ativo. Para essa finalidade, uma entidade de serviço (SPN) com uma função personalizada para consultar e reiniciar VMs é usada para autorizar na API ARM. Nenhuma outra infraestrutura é necessária. As VMs SBD nos desenhos de arquitetura não são implantadas caso o agente de cerca do Azure seja 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. 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 desastres. 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. 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 multidestinos . Portanto, o HSR oferece suporte à replicação entre zonas e entre regiões. 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 Arquivos NetApp do Azure podem ser usados para fornecer uma solução de armazenamento escalonável e de alto desempenho para arquivos de dados e de log 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, consulte Azure Monitor para soluções SAP 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, 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 a criptografia de dados transparente oferecida pelo provedor de 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 criptografados automaticamente 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 distribuições, versões e imagens específicas do Linux, consulte Criptografia de Disco do Azure para VMs Linux.

Observação

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 é habilitada automaticamente. Lembre-se de que o uso de chaves gerenciadas pelo cliente pode afetar a taxa de transferência do 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 do privilégio mínimo, usando o RBAC para atribuir privilégios administrativos em recursos de nível IaaS que hospedam sua solução SAP no Azure. O objetivo fundamental da 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 mal-intencionadas. 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.

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

Comunidades

As comunidades podem responder a perguntas e ajudá-lo 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: