Prefácio: unidades de medida para dados/informações

Muitas vezes, o Armazenamento de rede de rendimento é mostrado em Mbps ou Gbps.

É importante notar que Mb (Megabits) é um prefixo decimal e MiB (Mebibyte) é um prefixo binário. Portanto, eles estão em escalas diferentes. Mais confusão surge porque MiB (Mebibyte) era comumente conhecido no Microsoft Windows como Megabyte.

Para referência futura em toda a documentação de rede, Mb (Megabits) e MiB (Mebibyte) são usados com base no sistema de unidades (SI) definido pelo IEC e adotado pelo IEEE, ISO e NIST.

Por exemplo,:

• 100 Mbps (Megabits por segundo) seriam 12 MiB/s (Mebibyte por segundo)
• 1000 Mbps (Megabits por segundo) também conhecido como 1 Gbps (Gigabits por segundo) seriam 120 MiB/s (Mebibyte por segundo)
• 10 Gbps (Gigabits por segundo) seriam 1200 MiB/s (Mebibyte por segundo)

Considerações sobre conectividade de rede

Para obter uma visão geral das opções de conectividade disponíveis, consulte Determinando o acesso à sua paisagem do sistema SAP.

Os Sistemas SAP são geralmente o ponto focal das operações de negócios, com um grande número de aplicativos integrados (incluindo aplicativos anteriores).

Na maioria das circunstâncias para as cargas de trabalho SAP, é necessária uma conexão com a rede interna existente e recomenda-se usar o IBM Cloud® Direct Link 2.0 para operar o alto rendimento seguro de baixa latência (disponível até 10 Gbps) como uma conexão Camada OSI 2/3 encaminhada.

Essas opções de conectividade são dependentes de necessidades de negócios, por exemplo, se o negócio deseja usar a Nuvem e também diminuir o risco de segurança, isolando fluxos de rede por meio de sua estrutura de rede e segurança existentes. Nesses designs de conectividade "desconectados" ou "somente privado", é melhor solicitar à IBM Cloud® por informações adicionais e discutir seus casos de uso.

Além disso, é fortemente não recomendado pela SAP dividir a camada do Sistema SAP no local e nos locais da Nuvem e cabe ao negócio avaliar isso. Por exemplo, não é recomendado pela SAP reter o SAP AnyDB executado por meio da infraestrutura no local e se conectar ao SAP NetWeaver executado por meio da infraestrutura em um local da Nuvem. Para IBM Power Virtual Servers, essa divisão de camada do Sistema SAP não é suportada.

Considerações sobre topologia de rede

A topologia de rede será significativamente diferente dependendo da contagem e da configuração de Sistemas SAP que são combinados com a organização dos fluxos de rede entre esses sistemas por razões de segurança ou de desempenho. O design dessa topologia reflete as necessidades de segurança, desempenho, custo, flexibilidade e conectividade do negócio.

Usar o aplicativo de negócios de planejamento de recursos corporativos (ERP), por exemplo, um Sistema SAP que hospeda a instância de Produção que usa a abordagem de Camada do Sistema SAP com Alta disponibilidade de SAP NetWeaver e de SAP HANA:

• SAP NetWeaver, há pelo menos quatro hosts em vez de um:

  • Central Services (ASCS)
  • Primary Application Server (PAS), também conhecido como Instância central (CI)
  • Instância do Enqueue Replication Server (ERS)
  • Additional Application Server (AAS)

• SAP HANA, há pelo menos dois hosts (possivelmente três) em vez de um:

  • Nó primário SAP HANA (usando SAP HANA System Replication)
  • Nó de failover secundário SAP HANA (usando SAP HANA System Replication)
  • Nó de failover de recuperação de desastre terciário SAP HANA (usando SAP HANA System Replication)

• Este descreve o Sistema SAP 1 dentro da Paisagem SAP. Uma Paisagem SAP pode usar:

  • Uma faixa, cinco Sistemas SAP (Ambiente de simulação > Desenvolvimento > Teste > Preparação > Produção)
  • Faixa dual, cinco Sistemas SAP (Ambiente de simulação > Desenvolvimento de novo recurso + Desenvolvimento de manutenção > Teste do novo recurso + Teste de manutenção > Preparação > Produção)

Portanto, podem ser necessárias possivelmente de 30 a 50 instâncias do SAP para uma Paisagem SAP, difundidas entre 10 a 50 servidores host (físicos ou virtualizados). Isso é antes de mais aplicativos de negócios serem incluídos para operações de negócios, setores ou funções geográficas específicas.

O tamanho das Paisagens SAP tem um impacto direto na Topologia de rede.

Geralmente, embora isso varie de caso para caso, as redes a seguir são necessárias para atender aos cenários e ao desempenho necessários ao negócio que usa os Aplicativos de negócios SAP:

• Rede interna para comunicação entre múltiplas instâncias em uma Paisagem da SAP com abordagens diferentes do SAP System Tiering
• Rede para as transferências de gerenciamento e armazenamento de sistemas de banco de dados
• Rede usada na produção

No entanto, no cenário mais simples, pode haver uma rede privada para todos os fins. Depende das necessidades de negócios.

Considerações sobre consumo de rede

A comunicação tradicional de rede de carga de trabalho SAP é relativamente pequena com menos de 100 MiB de tráfego de rede por dia possíveis, tais como:

• Transações do usuário da SAPGUI; para Windows, para Java (usado com macOS ou Linux)
• Transações do usuário da SAP WebGUI
• Transações do usuário com apps Web Dynpro da SAP do SAP NetWeaver Business Client (NWBC)
• SAP Remote Function Call (SAP RFC) entre sistemas SAP e não SAP
• Entrada/saída de SAP iDOC entre sistemas SAP e não SAP com terceiros (por exemplo, bancos, fornecedores)

No entanto, há comunicações de rede de carga de trabalho SAP muito maiores que consomem significativamente mais tráfego de rede, tais como:

• Bibliotecas de pré-instalação SAPUI5 e temas para SAP Fiori Launchpad e Apps
  • 10 MiB a 25 MiB (estimativa) por nova sessão que é carregada do SAP web Assistant (também conhecido como XRay); em seguida, essas bibliotecas de pré-instalação são armazenadas em cache pelo navegador. Uma vez armazenadas em cache, as bibliotecas ficam disponíveis para uso em qualquer nova guia do navegador, mesmo após o reinício do navegador ou o logout do SAP Fiori; até o cache do navegador ser limpo
  • 20 KiB a 500 KiB (estimativa) por cada novo app Fiori que é carregado dentro da sessão
• SAP HANA System Replication (HSR) síncrono ou assíncrono, que transmite Gigabytes de dados por mês dos nós primário para secundário (ou terciário)

Com o aumento do tráfego de novos softwares de design SAP, é possível ultrapassar muito a quantidade de tráfego de rede vista no uso passado da SAP.

É importante projetar seus aplicativos SAP para usar o backbone privado da IBM Cloud para essas transferências de dados, já que não há taxas de ingresso/egresso; considerando que o uso sobre a Internet pública incorre encargos de egresso.

É necessário estimar a quantidade de dados que são transferidos. Durante os estágios iniciais de implementação do projeto, isso pode ser difícil. No entanto, pelo menos por uma ordem de magnitude, uma estimativa deve ser executada.

Considerações sobre desempenho de Rendimento de redes

A SAP geralmente recomenda o rendimento de rede 10 Gbps (redundante) para tráfego entre seus servidores de aplicativos e bancos de dados SAP HANA, além de outros clientes SAP HANA, como o SAP Business Intelligence.

Para implementações do SAP NetWeaver que usam SAP AnyDB com armazenamento local, mesmo para configurações de três camadas, geralmente redes de 1 Gbps são suficientes.

Considerações sobre o desempenho da latência de rede

Para suas operações de negócios e sistemas dependentes não SAP, é possível exigir que certos principais indicadores de desempenho (KPIs) de latência necessários sejam atendidos. Isso deve considerar o local do site de seus hosts e testar a latência usando a rede de backbone privada da IBM Cloud.

O teste de latência usando a métrica Round Trip Time (RTT) é necessário ao projetar Alta disponibilidade (HA) e Recuperação de desastre (DR) para SAP HANA.

Se um failover de HA estiver sendo projetado dentro de um local do site, em quase todos os casos, isso será possível para os requisitos do SAP HANA System Replication.

No entanto, se você estiver projetando a Alta disponibilidade para SAP HANA em vários sites dentro de uma Região ou projetando a Recuperação de desastre em várias Regiões, a latência que usa a métrica Round Trip Time (RTT) deverá ser cuidadosamente testada e considerada.

Isso é porque a IBM Cloud busca garantir a alta disponibilidade da plataforma, usando locais de site dispersos geograficamente com tolerância a falhas (por exemplo, diferentes avaliações de risco). Mais informações disponíveis em Como o IBM Cloud garante alta disponibilidade e redundância.

Em particular, para a Infraestrutura de VPC, as Zonas de disponibilidade são localizações geograficamente dispersas dentro da Região. Para a maioria das cargas de trabalho, esse design proporciona mais redundância em toda a Região. No entanto, o SAP HANA System Replication requer baixa latência de rede e pode se tornar difícil de atender à métrica necessária de Round Trip Time (RTT) devido às atuais limitações de transferência de dados físicos de tecnologia de cabeamento do ponto de vista da física (ou seja, velocidade da luz sobre o cabo de fibra óptica).

Considerações sobre segurança de portas de rede

As informações a seguir são um breve resumo do SAP Help Portal - TCP/IP Ports of All SAP Products, que fornece um exemplo das considerações necessárias para a segurança de seus sistemas SAP e de todo o cenário da infraestrutura de TI em IBM Cloud.

Dependendo dos Aplicativos técnicos SAP usados e dos cenários de negócios que estão sendo abordados, diferentes hosts precisarão de portas abertas. Geralmente, para atender a esse requisito, os Grupos de portas de firewall são combinados com Regras de firewall. Também é possível usar Regras de firewall individuais por host, embora muitas vezes se torne ingerenciável.

A tabela abaixo inclui algumas das Portas chave para Sistemas SAP que usam SAP NetWeaver e SAP HANA, que precisam de correção, dependendo do número de instância do Aplicativo técnico SAP. Os números de instância 00, 01, 02 são os padrões entre os vários Aplicativos técnicos SAP e estarão em padrões diferentes (esses padrões são mostrados com destaque de code blocks):

Considerações sobre segurança de segregação de tráfego de rede

É possível separar diferentes tipos de tráfego de rede em sua paisagem, seja por causa de restrições de segurança ou por causa de considerações de rendimento.

A segregação de redes é útil para os casos de uso de carga de trabalho SAP a seguir:

• Vários servidores que trocam dados
  • Sistemas SAP em uma arquitetura lógica de três camadas, na qual o banco de dados SAP e as instâncias de aplicativos SAP estão em hosts diferentes.
• Vários Sistemas SAP que trocam grandes quantidades de dados
  • Servidores de banco de dados, que precisam ter baixa latência de rede e alto rendimento de rede para bloqueio de rede/armazenamento de arquivos, portanto, precisam evitar firewalls. No entanto, o banco de dados ainda precisa de proteção para outros sistemas e acesso às redes.

Para usar a segregação de redes de forma eficaz, a interconectividade deve ser permitida em condições específicas.