Dimensionamento do storage
A seção a seguir fornece uma visão geral dos considerações sobre performance e capacidade para dimensionar um sistema de storage para SAP HANA.
Entre em Contato com seu representante de vendas do parceiro NetApp ou NetApp para dar suporte ao processo de dimensionamento do storage e para criar um ambiente de storage com o tamanho adequado. |
Considerações de desempenho
A SAP definiu um conjunto estático de KPIs de storage. Esses KPIs são válidos para todos os ambientes SAP HANA de produção, independentemente do tamanho da memória dos hosts de banco de dados e das aplicações que usam o banco de dados SAP HANA. Esses KPIs são válidos para ambientes de host único, host múltiplo, Business Suite no HANA, Business Warehouse no HANA, S/4HANA e BW/4HANAHANA. Portanto, a abordagem de dimensionamento de performance atual depende apenas do número de hosts SAP HANA ativos conectados ao sistema de storage.
Os KPIs de performance de storage são necessários apenas para sistemas SAP HANA de produção. |
O SAP fornece uma ferramenta de teste de performance, que deve ser usada para validar a performance de storage de hosts ativos do SAP HANA que são conectados ao storage.
A NetApp testou e pré-definiu o número máximo de hosts SAP HANA que podem ser anexados a um modelo de storage específico, sem deixar de atender aos KPIs de storage necessários da SAP para sistemas SAP HANA baseados em produção.
Os controladores de storage da família de produtos certificados FAS também podem ser usados para SAP HANA com outros tipos de disco ou soluções de back-end de disco, desde que sejam compatíveis com a NetApp e cumpram os KPIs de desempenho do SAP HANA TDI. Os exemplos incluem criptografia de storage NetApp (NSE) e tecnologia NetApp FlexArray. |
Este documento descreve o dimensionamento de disco para unidades de disco rígido SAS e unidades de estado sólido.
Unidades de disco rígido
É necessário um mínimo de 10 discos de dados (SAS de 10k RPM) por nó SAP HANA para atender aos KPIs de performance de storage da SAP.
Esse cálculo é independente do controlador de storage e do compartimento de disco usado. |
Unidades de estado sólido
Com unidades de estado sólido (SSDs), o número de discos de dados é determinado pela taxa de transferência de conexão SAS das controladoras de storage para o compartimento SSD.
O número máximo de hosts SAP HANA que podem ser executados em um compartimento de disco e o número mínimo de SSDs necessários por host SAP HANA foram determinados executando a ferramenta de teste de performance do SAP.
-
O compartimento de disco SAS de 12GB TB (DS224C TB) com SSDs de 24 TB dá suporte a até 14 hosts SAP HANA, quando o compartimento de disco é conetado ao 12GB.
-
O compartimento de disco SAS de 6Gb TB (DS2246 TB) com SSDs de 24 TB dá suporte a até 4 hosts SAP HANA.
Os SSDs e os hosts do SAP HANA devem ser igualmente distribuídos entre as duas controladoras de storage.
A tabela a seguir resume o número com suporte de hosts SAP HANA por compartimento de disco.
6Gb gavetas SAS (DS2246 TB) totalmente carregadas com SSDs de 24 TB | 12GB gavetas SAS (DS224C TB) totalmente carregadas com SSDs de 24 TB | |
---|---|---|
Número máximo de hosts SAP HANA por compartimento de disco |
4 |
14 |
Este cálculo é independente do controlador de armazenamento utilizado. A adição de mais compartimentos de disco não aumenta o número máximo de hosts SAP HANA com suporte a um controlador de storage. |
Workloads mistos
O SAP HANA e outros workloads de aplicações executados no mesmo controlador de storage ou no mesmo agregado de storage são compatíveis. No entanto, é uma prática recomendada da NetApp separar os workloads do SAP HANA de todos os outros workloads de aplicações.
Você pode decidir implantar workloads SAP HANA e outros workloads de aplicações no mesmo controlador de storage ou no mesmo agregado. Nesse caso, você precisa ter certeza de que performance suficiente sempre estará disponível para o SAP HANA no ambiente de workload misto. A NetApp também recomenda que você use parâmetros de qualidade do serviço (QoS) para regular o impacto que essas outras aplicações podem ter nas aplicações SAP HANA.
A ferramenta de teste SAP HCMT deve ser usada para verificar se hosts SAP HANA adicionais podem ser executados em um controlador de storage que já seja usado para outras cargas de trabalho. No entanto, os servidores de aplicações SAP podem ser colocados com segurança no mesmo controlador de storage e agregados que os bancos de dados SAP HANA.
Considerações sobre capacidade
Uma descrição detalhada dos requisitos de capacidade para SAP HANA está "SAP Nota 1900823" no white paper.
O dimensionamento da capacidade do cenário geral do SAP com vários sistemas SAP HANA deve ser determinado com o uso de ferramentas de dimensionamento de storage do SAP HANA da NetApp. Entre em Contato com a NetApp ou com seu representante de vendas do parceiro da NetApp para validar o processo de dimensionamento do storage para um ambiente de storage de tamanho adequado. |
Configuração da ferramenta de teste de desempenho
A partir do SAP HANA 1,0 SPS10, a SAP introduziu parâmetros para ajustar o comportamento de e/S e otimizar o banco de dados para o sistema de arquivos e storage usado. Esses parâmetros também devem ser definidos para a ferramenta de teste de desempenho do SAP (fsperf) quando o desempenho do armazenamento é testado usando a ferramenta de teste SAP.
Os testes de desempenho foram realizados pela NetApp para definir os valores ideais. A tabela a seguir lista os parâmetros que devem ser definidos no arquivo de configuração da ferramenta de teste SAP.
Parâmetro | Valor |
---|---|
max_parallel_io_requests |
128 |
async_read_submit |
ligado |
async_write_submit_active |
ligado |
async_write_submit_blocks |
tudo |
Para obter mais informações sobre a configuração da ferramenta de teste SAP, "SAP nota 1943937" consulte HWCCT (SAP HANA 1,0) e "SAP nota 2493172" HCMT/HCOT (SAP HANA 2,0).
O exemplo a seguir mostra como as variáveis podem ser definidas para o plano de execução HCMT/HCOT.
…{ "Comment": "Log Volume: Controls whether read requests are submitted asynchronously, default is 'on'", "Name": "LogAsyncReadSubmit", "Value": "on", "Request": "false" }, { "Comment": "Data Volume: Controls whether read requests are submitted asynchronously, default is 'on'", "Name": "DataAsyncReadSubmit", "Value": "on", "Request": "false" }, { "Comment": "Log Volume: Controls whether write requests can be submitted asynchronously", "Name": "LogAsyncWriteSubmitActive", "Value": "on", "Request": "false" }, { "Comment": "Data Volume: Controls whether write requests can be submitted asynchronously", "Name": "DataAsyncWriteSubmitActive", "Value": "on", "Request": "false" }, { "Comment": "Log Volume: Controls which blocks are written asynchronously. Only relevant if AsyncWriteSubmitActive is 'on' or 'auto' and file system is flagged as requiring asynchronous write submits", "Name": "LogAsyncWriteSubmitBlocks", "Value": "all", "Request": "false" }, { "Comment": "Data Volume: Controls which blocks are written asynchronously. Only relevant if AsyncWriteSubmitActive is 'on' or 'auto' and file system is flagged as requiring asynchronous write submits", "Name": "DataAsyncWriteSubmitBlocks", "Value": "all", "Request": "false" }, { "Comment": "Log Volume: Maximum number of parallel I/O requests per completion queue", "Name": "LogExtMaxParallelIoRequests", "Value": "128", "Request": "false" }, { "Comment": "Data Volume: Maximum number of parallel I/O requests per completion queue", "Name": "DataExtMaxParallelIoRequests", "Value": "128", "Request": "false" }, …
Essas variáveis devem ser usadas para a configuração do teste. Este é geralmente o caso com os planos de execução predefinidos que o SAP entrega com a ferramenta HCMT/HCOT. O exemplo a seguir para um teste de gravação de log 4K é de um plano de execução.
… { "ID": "D664D001-933D-41DE-A904F304AEB67906", "Note": "File System Write Test", "ExecutionVariants": [ { "ScaleOut": { "Port": "${RemotePort}", "Hosts": "${Hosts}", "ConcurrentExecution": "${FSConcurrentExecution}" }, "RepeatCount": "${TestRepeatCount}", "Description": "4K Block, Log Volume 5GB, Overwrite", "Hint": "Log", "InputVector": { "BlockSize": 4096, "DirectoryName": "${LogVolume}", "FileOverwrite": true, "FileSize": 5368709120, "RandomAccess": false, "RandomData": true, "AsyncReadSubmit": "${LogAsyncReadSubmit}", "AsyncWriteSubmitActive": "${LogAsyncWriteSubmitActive}", "AsyncWriteSubmitBlocks": "${LogAsyncWriteSubmitBlocks}", "ExtMaxParallelIoRequests": "${LogExtMaxParallelIoRequests}", "ExtMaxSubmitBatchSize": "${LogExtMaxSubmitBatchSize}", "ExtMinSubmitBatchSize": "${LogExtMinSubmitBatchSize}", "ExtNumCompletionQueues": "${LogExtNumCompletionQueues}", "ExtNumSubmitQueues": "${LogExtNumSubmitQueues}", "ExtSizeKernelIoQueue": "${ExtSizeKernelIoQueue}" } }, …
Visão geral do processo de dimensionamento de armazenamento
O número de discos por host HANA e a densidade de host do SAP HANA para cada modelo de storage foram determinados com a ferramenta de teste do SAP HANA.
O processo de dimensionamento exige detalhes como o número de hosts SAP HANA de produção e não produção, o tamanho da RAM de cada host e o período de retenção de backup das cópias Snapshot baseadas em storage. O número de hosts do SAP HANA determina o controlador de storage e o número de discos necessários.
O tamanho da RAM, o tamanho líquido dos dados no disco de cada host SAP HANA e o período de retenção do backup de cópia Snapshot são usados como entradas durante o dimensionamento da capacidade.
A figura a seguir resume o processo de dimensionamento.