SAP HANA

O SAP HANA é uma plataforma de computação in-memory que pode ser implementada on-premise ou em nuvem e permite acelerar processos de negócios, oferecer mais inteligência de negócios e simplificar o ambiente de TI.

Soluções que podem ser criadas com essa plataforma:

  • Uso da própria linguagem e microsserviços: A partir do HANA SPS 11, o XS Advanced será fornecido, e com suporte total, com Apache TomEE Java e Google V8 JavaScript/Node.js. Além disso, você poderá aproveitar microsserviços aprimorados que permitam que serviços únicos sejam destinados a diferentes versões de tempo de execução, paralelamente;
  • Análise de Dados com o Apache Hadoop:  Para agilizar a análise de dados do Hadoop, o HANA SPS 11 inclui um novo conector do SAP Vora. O SAP Vora é um novo mecanismo de consulta in-memory para Apache Spark e Hadoop que adiciona contexto de negócios à análise, combinando dados empresariais e do Hadoop;
  • Funções analíticas de texto: Com a pataforma HANA, você pode obter insights reais de seus dados textuais não estruturados. A plataforma fornece funcionalidade de pesquisa, análise de texto e extração de texto de fontes de textos não estruturados;

  • Funções analíticas de streamingAs funções analíticas de streaming adicionam processamento de fluxo de eventos de alto desempenho e processamento complexo de eventos (CEP) à plataforma, facilitando para os desenvolvedores incorporarem captura de fluxo inteligente, alertas e monitoramento de eventos ativos e resposta orientada a eventos aos aplicativos HANA;

  • Geoespacial: Armazene, processe e visualize dados geográficos no HANA. Você pode também realizar operações, como cálculos de distância, e determinar a união e a intersecção de vários objetos. Além disso, pode integrar dados geográficos a outros dados estruturados e não estruturados;
  • Funções analíticas preditivas: Incorpore cenários de previsão de mineração de dados aos apps. Escolha dentre mais de 20 algoritmos diferentes, incluindo análise de associação, clustering de agrupamento, classificação que inclui regressão, séries temporais de previsões, detecção de valores atípicos e preparação de dados;
  • Hibernate: Use facilmente a velocidade da computação in-memory e as funções analíticas multimodais do HANA via Hibernate ORM (relacional) e Hibernate OGM (NoSQL). Os recursos incluem o suporte ao processamento avançado de dados multimodal, como texto e espaciais via dialetos do Hibernate, nível de abstração para valor-chave, armazenamento de documentos e gráfico, além do mapeamento XML. Comece a criar novos aplicativos no HANA – menos código, já que o Hibernate faz o mapeamento objeto-relacional (O/R).

SAP HANA no VMware All-Flash Virtual SAN

Como alguns fanáticos por SAP HANA no Virtual SAN sabem, a VMware tem testado e validado o SAP HANA no vSAN. Oficialmente a SAP não dá suporte ao HANA no Virtual SAN ou em qualquer arquitetura HCI hoje em dia, a VMware está trabalhando em conjunto com a SAP para determinar a melhor abordagem para alcançar o suporte ao vSAN. Por fim, essa é uma prévia do que está por vir na arquitetura referência da SAP no VMware Virtual SAN All-Flash.

Testes com a HANA e outras plataformas como Oracle e MSSQL resultaram em números de desempenho bem adequados para suportar as cargas de trabalho SAP de maior demanda. Além de atender aos requisitos das aplicações e bancos de dados modernos, o vSAN agora está pronto para os empreendimentos por suportar já que conta com características de suporte ao armazenamento, como o Storage Based Policy Management (SBPM), necessário para rodar os dados mais críticos.

Com o VMware Virtual SBPM, a política de armazenamento é definida no nível VMDK do banco de dados do vSAN. Ao mudar a política de armazenamento, a base de dados da VM (Máquina Virtual) SAP HANA pode ser aplicada para diferentes perfis e propósitos.

Nesse post, serão abordadas os impactos de performances para cada configuração de políticas sob diferentes cargas de trabalho.

Especificações All-Flash Virtual SAN

A configuração usada para testar as diferentes configurações foi:

  • Especificação do servidor (por host):
    • 2x Xeon E5-2670 v3 @2.3 GHz 12-core
    • 256GB RAM
    • SSD: 2 x 400GB Solid State Drive (Intel SSDSC2BA40) como Cache SSD
    • SSD: 8 x 400GB Solid State Drive (Intel SSDSC2BX40) como Capacity SSD
    • ESXi versão: 6.0 U2
  • Configuração da base de dados da VM SAP HANA:
    • 24 vCPU
    • 230GB RAM
    • Disco0: 100GB
    • Disco de Dados: 690GB no VMware Paravirtual-1
    • Disco de Log: 230GB no VMware Paravirtual-2
    • Disco Backup: 690GB no VMware Paravirtual-3 (se necessário)
    • OS: SUSE Linux Enterprise 11 sp3 64bit
    • SAP HANA Database Server: 1.00.112.02
    • Parâmetros de Teste dos Arquivos HWCCT do Sistema:
      • async_write_submit_active = on
      • async_write_submit_blocks = all
      • param async_read_submit = on
      • max_parallel_io_requests = 256

Preparando para rodar SAP Hana no Virtual SAN

O vSAN 6.2 introduziu novas funcionalidades como soma de verificação, eficiência de espaço (deduplicação e compressão) e codificação de apagamento (RAID 5/RAID 6). Para avaliar se as novas funcionalidades suportam o HANA e avaliar o custo de impacto das novidades no resultado da performance, foi instalada uma Máquina Virtual com base de dados HANA no Virtual SAN Cluster e foram conduzidos testes de Arquivos HWCCT de Sistema, utilizando 5 diferentes configurações e políticas de armazenamento no Virtual SAN.

Como apresentado na imagem abaixo, todas as políticas de armazenamento foram configuradas para usar os 8 grupos (Stripe Width ou SW) de disco do cluster, aumentar esses grupos de disco traz à carga de trabalho melhor performance.

O teste 1a é o aprovisionamento do tradicional VMDK fino, enquanto o teste 1b é o aprovisionamento VMDK grosso-lento-zero, dos testes 1c a 1e, as novas funcionalidades do vSAN 6.2 foram habilitadas. Para os primeiros 4 casos de teste, as políticas de armazenamento definidas foram aplicadas tanto para os dados como os discos de log. Em referência ao teste 1e, RAID 5 foi aplicado só no disco de dados e o disco de log permaneceu com RAID 1. Nesse caso de testes, o HWCCT foi rodado só no disco de dados já que não houve mudanças no disco de log.

SAP HANA

Em todos os casos acima, os KPIs (Key Performance Indicators, ou Indicadores Chave de Performance) foram atingidos nos testes de HWCCT. Agora vamos revisar alguns dos dados de dois testes de caso HWCCT para cada desses cenários como demonstração: I/O (Input/Output) aleatório de 1MB no disco de dados e I/O sequencial 4K no disco de log.

O aprovisionamento grosso-lento sem quaisquer funcionalidades habilitadas é o que teve a melhor taxa de transferência entre os cinco caso, isso ocorre porque esse tipo de provisão de disco reserva o espaço no armazenamento enquanto está sendo aprovisionado, ajudando a evitar desbalanceamento dos objetos distribuídos. assim todas as cargas de trabalho serão distribuídas igualmente entre todos os grupos de discos.

A taxa de transferência dos testes 1a e 1d são idênticas porque a mesmo política de armazenamento é usada em ambos os casos, a única diferença é que o teste 1d tem eficiência de espaço (deduplicação e compressão), a qual só será executada se os dados estiverem escalando da camada de cache para a camada de capacidade, logo, o teste com HWCCT não sofrerá impacto dessa característica.

Os casos de teste com soma de verificação (1c) e codificação de apagamento (1e) habilitados também atingiram os KPIs, embora tenha sido inferior aos resultados obtidos caso estivessem desabilitados, isso em parte se deve ao preço do Write Amplification, fenômeno em que o montante de informação fisicamente escrita na mídia de armazenamento é um múltiplo lógico do montante que deveria estar escrito.

Quanto à performance de leitura, o teste 1b obteve a melhor performance, para todos os outros cenários, a performance de leitura é relativamente a mesma já que foram baseados em um aprovisionamento “fino” (thin). Além disso, a carga de trabalho ficou na camada de cache porque o arranjo de dados do teste HWCCT é pequeno. Outro ponto é a amplificação I/O, que não afeta a carga de trabalho de leitura, assim os testes 1c e 1e obtiveram resultados parecidos entre si.

De uma perspectiva da latência de transcrição, quanto menor melhor, e todas as configurações do vSAN podem performar I/O sequencial 4K em menos de 400 microssegundos, podendo a diferença entre os testes ser ignorada, uma vez que varia em cerca de 60 microssegundos.

Para a taxa de transferência da transcrição, o cenário 1e não foi envolvido, e entre os restantes a variação foi de apenas 7%, que é relativamente pequena. O menor tamanho de bloco é o menos impactado pela Write Amplification (explicada acima) e por isso, o cenário 1c com soma de verificação habilitada, consegue ficar até 10% abaixo do patamar.

Com isso, fica claro que o Virtual SAN pode suportar o SAP HANA mesmo com as funcionalidades da versão 6.2 habilitadas. Entretanto, se você deseja habilitar as novas funcionalidades e escalar as bases de dados HANA no cluster, garanta que as máquinas virtuais conseguem atingir os KPIs do HWCCT.

Performance do SAP HANA Backup e Recuperação no Virtual SAN

Não há necessidade de enfatizar a importância do backup e da recuperação em bases de dados de empreendimentos. Um trabalho de rotina de backup é esperado de forma que otimize a configuração para reduzir impactos.

A recuperação não acontece com frequência, entretanto, quando você precisar fazê-la, o tempo é um fator essencial. Muitos fatores podem ajudar a determinar o objetivo de tempo de recuperação (RTO), e para esse caso, foram usados apenas 3:

  • Impacto na performance da base de dados;
  • Tempo de Backup;
  • Tempo de recuperação.

De uma perspectiva de banco de dados, a deduplicação e a compressão estão habilitadas no vSAN. Um banco de dados NFS é introduzido em cada host ESXi como um armazenamento externo, e com isso, ambos os bancos são considerados candidatos para destino do backup.

Para a VM com SAP HANA, um backup adicional aprovisionado de VMDK fino com 600GB foi adicionado usando um controlador PVSCSI. Para esse backup VMDK, a política de armazenamento é considerada outro critério para diferenciar cenários de teste caso resida no banco de dados vSAN.

Os cenários de teste abaixo avaliam o impacto da performance do banco de dados comparando a performance de execução dos dados enquanto faz backup com diferentes configurações de armazenamento, tendo todos os cenários atingido os KPIs HWCCT.

HANA SAP

Como primeiro passo, foram usados scripts para criar 48 mesas com 10 colunas de cada e inserir 8 milhões de linhas em cada mesa. Então foi usado “hdbsql” para fazer o backup completo dos dados para o caminho montado no backup VMDK. Esse comando foi enviado para cada VM com base de dados SAP HANA assim que a execução dos dados (achar o número máximo de 8 milhões de linhas em cada coluna) foi desencadeada.

Após o backup dos dados e a execução terem sidos feitos, foram baixadas as mesas geradas pelos scripts de teste de recuperação de dados do backup. Todas os trabalhos de execução de dados, backup e recuperação aconteceram simultaneamente em todas as VMs HANA.

Comparando primeiramente os cenários 2a e 2b, devido à Write Amplification causada pela codificação de apagamento, a performance de execução de dados é melhor e tem menos impacto quando o backup está sendo feito no RAID 1 VMDK (2a) do que no RAID 5 VMDK (2b). Além disso, a velocidade de backup do VMDK com RAID 1 é 2,5 vezes mais rápida do que na RAID 5. De qualquer forma, em ambos os casos todos os dados foram recuperados em cinco minutos.

Agora, comparando os casos de teste de VMDK no Virtual SAN com VMDK em banco de dados NFS externo, foram levados em conta os valores médios de dados através das 4 VMs. Com isso, pôde-se observar que, ao observar o tempo médio de execução dos dados entre 2c e 2d, ter o backup VMDK no armazenamento externo tem menos impacto de performance do que no vSAN, isso porque a carga de trabalho fica mais intensa no vSAN quando está processando a base de dados. Entretanto, a velocidade de backup e recuperação é absolutamente dependente da performance do armazenamento externo, a velocidade média de backup do cenário 2c (backup no vSAN RAID1) é mais de 3 vezes melhor que no cenário 2d, e o tempo de recuperação em 2c é apenas 25% do necessário em 2d.

Em resumo, custa menos tempo de backup e tempo de recuperação utilizar o Virtual SAN, mas há um impacto na performance da base de dados de produção. Se a performance da base de dados durante o backup e a recuperação for importante, considere a utilização de armazenamento externo para essas operações.

Porém, se não há armazenamento externo adequado para backup e recuperação, utilizar um backup VMDK no Virtual SAN pode diminuir a janela dessas operações, que é uma boa alternativa para o desenho da sua arquitetura de backup e recuperação.

O VMware vSAN é um grande encaixe para SAP HANA, os resultados de performance provam que o Virtual SAN, mesmo com as funcionalidades do 6.2 habilitadas, dá conta das cargas de trabalho. Além disso, vSAN pode entregar uma plataforma rápida de backup e recuperação para a HANA enquanto continua a servir a base de dados de produção.

Referência

Leia também...