Arquitetura
Sugerir alterações
PDFs
Os hosts do SAP HANA são conectados aos 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 FAS podem ser usados na camada de storage. O número máximo de hosts SAP HANA conectados ao storage é definido pelos requisitos de performance do SAP HANA. O número de compartimentos de disco necessário é 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 adicionais e capacidade de disco ao storage, supondo que os controladores de storage possam fornecer desempenho suficiente sob a nova carga para atender aos principais indicadores de desempenho (KPIs)
-
Adicionando mais sistemas de storage e capacidade de disco 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.
Independente do modelo de storage do sistema FAS implantado, o cenário SAP HANA também pode ser dimensionado adicionando mais controladores de storage, como mostrado na figura a seguir.
Backup de SAP HANA
O software NetApp ONTAP fornece um mecanismo integrado para fazer backup de bancos de dados SAP HANA. O backup Snapshot baseado em storage é uma solução de backup totalmente compatível e integrada, disponível para sistemas de contêiner único SAP HANA e para sistemas de locatário único SAP HANA MDC.
Os backups Snapshot baseados em storage são implementados usando o plug-in NetApp SnapCenter para SAP HANA, que permite backups Snapshot consistentes baseados em storage usando as interfaces fornecidas pelo banco de dados SAP HANA. O SnapCenter Registra os backups Snapshot no catálogo de backup do SAP HANA para que os backups fiquem visíveis no estúdio do SAP HANA e possam ser selecionados para operações de restauração e recuperação.
Com o uso do software NetApp SnapVault, as cópias Snapshot criadas no storage primário podem ser replicadas para o storage de backup secundário controlado pelo SnapCenter. Diferentes políticas de retenção de backup podem ser definidas para backups no storage primário e no storage secundário. O plug-in do SnapCenter para banco de dados SAP HANA gerencia 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 banco de dados 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.
É possível fazer backup dos logs do banco de dados diretamente no storage secundário usando uma montagem NFS, como mostrado na figura a seguir.
Os backups Snapshot baseados em storage oferecem vantagens significativas em comparação aos backups baseados em arquivos. Essas vantagens incluem o seguinte:
-
Backup mais rápido (poucos minutos)
-
Restauração mais rápida na camada de storage (alguns minutos)
-
Nenhum efeito na performance do host, rede ou storage do banco de dados SAP HANA durante o backup
-
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 SAP HANA usando o SnapCenter, "TR-4614: Backup e recuperação do SAP HANA com o SnapCenter" consulte .
Recuperação de desastres do SAP HANA
A recuperação de desastres do SAP HANA pode ser realizada na camada de banco de dados usando a replicação do sistema SAP 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 a solução de recuperação de desastres do SAP HANA usando o SnapCenter, "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 replicação síncrona de SnapMirror para o data center de DR local e SnapMirror assíncrona para replicar dados para o data center de DR remoto.
A replicação de dados com o SnapMirror síncrono oferece RPO de zero. A distância entre o data center principal e o data center local de DR é limitada a cerca de 100km km.
A proteção contra falhas do local de DR primário e do local é executada replicando os dados para um terceiro data center remoto de DR usando o SnapMirror assíncrono. O RPO depende da frequência das atualizações de replicação e da rapidez com que elas podem ser transferidas. Em teoria, a distância é ilimitada, mas o limite depende da quantidade de dados que devem ser transferidos e da conexão que está disponível entre os data centers. Os valores típicos de RPO estão no intervalo de 30 minutos a várias horas.
O rto para ambos os métodos de replicação depende principalmente do tempo necessário para iniciar o banco de dados HANA no local 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.
A replicação síncrona oferece o modo StrictSync. Se a gravação no storage secundário não for concluída por qualquer motivo, a e/S da aplicação falhará, garantindo assim que os sistemas de storage primário e secundário sejam idênticos. A e/S da aplicação para o primário é retomada somente após a relação SnapMirror retornar ao status InSync. Se o storage primário falhar, a e/S da aplicação poderá ser retomada no storage secundário após o failover sem perda de dados. No modo StrictSync, o RPO é sempre zero.
Replicação de storage baseada no NetApp MetroCluster
A figura a seguir mostra uma visão geral de alto nível da solução. O cluster de storage em cada local fornece alta disponibilidade local e é usado para workloads de produção. Os dados em cada local são replicados em sincronia para o outro local e estão disponíveis em caso de failover de desastres.
