Arquitetura
Sugerir alterações
PDFs
Os hosts do SAP HANA são conectados a controladores de storage usando uma infraestrutura FCP redundante e software multipath. Uma infraestrutura de switch FCP redundante é necessária para fornecer conectividade de host para storage SAP HANA tolerante a falhas em caso de falha no switch ou no adaptador de barramento do host (HBA). O zoneamento apropriado deve ser configurado no switch para permitir que todos os hosts HANA alcancem os LUNs necessários nos controladores de storage.
Diferentes modelos da família de produtos do sistema ASA podem ser combinados e combinados na camada de storage para permitir crescimento e diferentes necessidades de desempenho e capacidade. O número máximo de hosts SAP HANA que pode ser anexado ao sistema de storage é definido pelos requisitos de performance do SAP HANA e pelo modelo de controladora NetApp usado. O número de compartimentos de disco necessários só é determinado pelos requisitos de capacidade e performance dos sistemas SAP HANA.
A figura a seguir mostra um exemplo de configuração com oito hosts SAP HANA conectados a um par de HA de storage.
Essa arquitetura pode ser dimensionada em duas dimensões:
-
Anexando hosts SAP HANA e capacidade de storage adicionais ao storage existente, se os controladores de storage fornecerem performance suficiente para atender aos KPIs atuais do SAP HANA
-
Adicionando mais sistemas de storage com capacidade de storage adicional para hosts SAP HANA adicionais
A figura a seguir mostra um exemplo de configuração no qual mais hosts SAP HANA são conectados aos controladores de storage. Neste exemplo, mais compartimentos de disco são necessários para atender aos requisitos de capacidade e desempenho dos hosts SAP HANA de 16HANA. Dependendo dos requisitos de taxa de transferência total, você precisa adicionar conexões FC adicionais às controladoras de storage.
Independentemente do sistema ASA implantado, o cenário SAP HANA também pode ser dimensionado adicionando qualquer controlador de storage certificado para atender à densidade de nó desejada, como mostrado na figura a seguir.
Backup de SAP HANA
O software ONTAP presente em todas as controladoras de storage NetApp fornece um mecanismo incorporado para fazer backup de bancos de dados SAP HANA em operação sem afetar a performance. Os backups de Snapshot baseados em storage NetApp são uma solução de backup totalmente compatível e integrada, disponível para volumes únicos SAP HANA e para sistemas SAP HANA MDC com um único locatário ou vários locatários.
Os backups Snapshot baseados em storage são implementados com o plug-in NetApp SnapCenter para SAP HANA. Isso permite que os usuários criem backups Snapshot consistentes com base em storage usando as interfaces fornecidas nativamente pelos bancos de dados SAP HANA. O SnapCenter Registra cada um dos backups Snapshot no catálogo de backup do SAP HANA. Portanto, os backups feitos pelo SnapCenter são visíveis no SAP HANA Studio ou Cockpit, onde podem ser selecionados diretamente para operações de restauração e recuperação.
A tecnologia NetApp SnapMirror permite que cópias Snapshot criadas em um sistema de storage sejam replicadas para um sistema de storage de backup secundário controlado pelo SnapCenter. Diferentes políticas de retenção de backup podem ser definidas para cada um dos conjuntos de backup no storage primário e também para os conjuntos de backup nos sistemas de storage secundário. O plug-in do SnapCenter para SAP HANA gerencia automaticamente a retenção de backups de dados baseados em cópia Snapshot e de log, incluindo o serviço de limpeza do catálogo de backup. O plug-in do SnapCenter para SAP HANA também permite a execução de uma verificação de integridade de bloco do banco de dados SAP HANA executando um backup baseado em arquivo.
Os backups Snapshot baseados em storage oferecem vantagens significativas em comparação aos backups convencionais baseados em arquivos. Estas vantagens incluem, mas não estão limitadas ao seguinte:
-
Backup mais rápido (alguns minutos)
-
Rto reduzido devido a um tempo de restauração muito mais rápido na camada de storage (poucos minutos), bem como backups mais frequentes
-
Sem degradação do desempenho do host, rede ou storage do banco de dados SAP HANA durante operações de backup e recuperação
-
Replicação com uso eficiente de espaço e com uso eficiente de largura de banda para storage secundário com base em alterações de bloco
Para obter informações detalhadas sobre a solução de backup e recuperação do SAP HANA, "Proteção de dados do SAP HANA e alta disponibilidade com o SnapCenter, o SnapMirror active Sync e o cluster de storage VMware Metro"consulte .
|
Na criação destes documentos, apenas VMs baseadas em VMware usando VMDKs como armazenamento eram suportadas pelo SnapCenter para ASA. |
Recuperação de desastres do SAP HANA
A recuperação de desastres do SAP HANA pode ser feita na camada de banco de dados usando a replicação do sistema SAP HANA ou na camada de storage usando tecnologias de replicação de storage. A seção a seguir fornece uma visão geral das soluções de recuperação de desastres com base na replicação de storage.
Para obter informações detalhadas sobre as soluções de recuperação de desastres do SAP HANA, "TR-4646: Recuperação de desastres do SAP HANA com replicação de storage"consulte .
Replicação de storage baseada no SnapMirror
A figura a seguir mostra uma solução de recuperação de desastres em três locais usando a sincronização ativa do SnapMirror para o datacenter de recuperação de desastres local e o SnapMirror assíncrono para replicar os dados para o datacenter de recuperação de desastres remoto. A sincronização ativa do SnapMirror permite que os serviços de negócios continuem operando mesmo em caso de falha total do local, permitindo que os aplicativos realizem failover transparente usando uma cópia secundária (RPO = 0 e RTO = 0). Não há necessidade de intervenção manual ou script personalizado para acionar um failover com a sincronização ativa do SnapMirror. A partir do ONTAP 9.15.1, o SnapMirror active Sync é compatível com uma funcionalidade ativo-ativo simétrica. Ativo-ativo simétrico habilita operações de e/S de leitura e gravação de ambas as cópias de um LUN protegido com replicação síncrona bidirecional, de modo que ambas as cópias LUN possam servir operações de e/S localmente.
Mais detalhes podem ser encontrados em "Descrição geral da sincronização ativa do SnapMirror no ONTAP" ..
O RTO para a replicação assíncrona do SnapMirror depende principalmente do tempo necessário para iniciar o banco de dados HANA no site de DR e carregar os dados na memória. Partindo do pressuposto de que os dados são lidos com uma taxa de transferência de 1000Mbps Gbps, o carregamento de 1TB TB de dados levaria aproximadamente 18 minutos.
Os servidores nos locais de DR podem ser usados como sistemas de desenvolvimento/teste durante a operação normal. No caso de um desastre, os sistemas de desenvolvimento/teste precisariam ser desligados e iniciados como servidores de produção de DR.
Ambos os métodos de replicação permitem que você execute testes de fluxo de trabalho de DR sem influenciar o RPO e o rto. Os volumes do FlexClone são criados no storage e são anexados aos servidores de teste de DR.
