Introdução

Software IBM Tivoli® O Storage Manager supre as necessidades de gerenciamento de armazenamento por meio de vários recursos fáceis de gerenciar. Esses recursos avançados incluem backup e restauração inteligentes, gerenciamento de armazenamento hierárquico, archives gerenciados e redundância de dados. Os requisitos de armazenamento de dados e metadados podem ser imensos. Usando a tecnologia de unidade de estado sólido para remover o gargalo dos metadados relacionado à E/S, é possível obter melhorias de desempenho (em alguns casos, de até 229%) em muitas funções do Tivoli Storage Manager. Este documento fornece configuração e ajustes para que outros tenham esses ganhos.

Voltar para parte superior

Tecnologia de ruptura

Os Solid-state drives (SSDs), também conhecidos como discos de estado sólido, são dispositivos de armazenamento persistente em bloco sem as partes móveis de um disco giratório tradicional (hard disk drive, HDD). Em vez disso, os SSDs não voláteis usam memória DRAM baseada em Flash para fazer os dados persistirem. Dessa forma, não têm partes móveis, o que proporciona tempos de acesso muito mais rápidos evitando o atraso de busca. Os SSDs usam a mesma interface dos HDDs, para permitir um uso totalmente integrado com o software já existente. Os SSDs vêm em fatores de forma semelhantes aos do HDD e com adaptadores PCIe.

Voltar para parte superior

IBM Tivoli Storage Manager

O IBM Tivoli Storage Manager é um aplicativo de gerenciamento de armazenamento para toda a empresa. Fornece serviços de gerenciamento de armazenamento automatizado, como backup, restauração, archive e recuperação para servidores de arquivos, servidores de banco de dados, estações de trabalho e computadores pessoais com uma série de sistemas operacionais.

Programa de servidor

O programa de servidor fornece serviços de backup, archive e gerenciamento de espaço aos clientes. É possível configurar vários servidores em uma rede corporativa para equilibrar os recursos de armazenamento, processador e rede.

Banco de dados de servidor

O servidor do Tivoli Storage Manager usa um banco de dados para acompanhar as informações (por exemplo, metadados) sobre armazenamento no servidor, clientes, dados de cliente, política e programações. Nos experimentos com SSD realizados neste artigo, o banco de dados do servidor reside no SSD.

Armazenamento no servidor

O servidor pode armazenar e recuperar dados usando dispositivos de armazenamento de disco e fita e subsistemas provenientes de uma longa lista de fornecedores. As mídias de armazenamento no servidor são agrupadas em pools de armazenamento. Os dispositivos de armazenamento podem ser conectados diretamente ao servidor ou por meio de uma local area network (LAN) ou storage area network (SAN).

Interface administrativa do servidor

A interface administrativa permite que os administradores controlem e monitorem as atividades do servidor, definam políticas de gerenciamento para clientes e configurem programações para prestar serviços a clientes em intervalos regulares. As interfaces administrativas disponíveis incluem um cliente administrativo de linha de comando e uma interface de navegador da Web (chamada de Administration Center). O Tivoli Storage Manager permite gerenciar e controlar vários servidores a partir de uma única interface acessível por meio de um navegador da Web.

Nó cliente do archive de backup

O cliente do archive de backup permite que os usuários mantenham versões de backup dos arquivos, que podem ser restaurados caso os arquivos originais sejam perdidos ou danificados. Os usuários também podem arquivar os arquivos para armazenamento de longo prazo e recuperar os arquivos arquivados quando necessário. O programa cliente de backup/archive é instalado nos servidores de arquivos, servidores de banco de dados, estações de trabalho e computadores pessoais e registrado no servidor.

Nó de cliente de aplicativo

Os clientes de aplicativo permitem que os usuários realizem backups online dos dados para os aplicativos, como programas de banco de dados. Os produtos a seguir fornecem clientes de aplicativos para usar com o servidor do Tivoli Storage Manager: Tivoli Storage Manage para Databases, Tivoli Storage Manager para Enterprise Resource Planning e Tivoli Storage Manager para Mail.

Voltar para parte superior

Detalhes de hardware e software

Estes são os detalhes do system under test (SUT) e dos drivers de teste.

Servidor do Tivoli Storage Manager, versão 6, Release 2, nível 1

• 4 pacotes de processadores Intel® Xeon™ E7450 (6 núcleos) a 2,4 GHz (24 núcleos no total)
• 32 GB de memória real,
• 2 portas Intel(R) 82575EB Gigabit Network
• 2 portas Intel(R) PRO/1000 EB Network com aceleração de E/S
• 2 adaptadores IBM 320 GB High IOPS SD Class SSD PCIe
• 2 HBAa de fibra de porta única Qlogic QLE2460 4 Gbps
• 1 HBA de fibra de porta única Qlogic QLE2560 8 Gbps (usado para fita)
• Microsoft® Windows Server 2008 R2 Enterprise x64 Edition
• Recurso de E/S Multipath instalado
• IBM Subsystem Device Driver DSM, versão 2.4.2.1-2
• 8 LUNS de disco de 256 GB no DS8100 modelo 921 usando 8 ranks
• 8 LUNS de disco de 64 GB no DS8100 modelo 921 usando 8 ranks (ranks iguais aos acima)
• 1 biblioteca de fita IBM TS3500 com 4 IBM LTO™ Ultrium® 5 unidades de fita (compartilhadas)

Clientes de Tivoli Storage Manager (32x), versão 6, Release 2, nível 1

• Lenovo ThinkCentre M55 8810-BE2
• 1 Intel Core2 Duo a 2,66 GHz
• 2 GB de memória real
• 1 placa de rede Broadcom NetXtreme Gigabit
• Disco IDE de 150 GB
• Microsoft Windows XP Professional, SP3

Redes

• Netgear® GSM7352S 10 Gbps/1 switch de LAN de 1 Gbps e 48 portas
• Switch de fibra IBM 2005B32 de 32 portas e 4 Gbps

Unidades de estado sólido

Os dois adaptadores IBM 320 GB High IOPS SD Classe SSD PCIe requeriam o software Windows Fusion-IO versão 2.1.0. O firmware do adaptador SSD foi atualizado ao nível 43247 em todos os adaptadores. Os dispositivos foram formatados com baixo nível, de acordo com a capacidade padrão anunciada, que fornece dois dispositivos de 160 GB em cada adaptador. Finalmente, os volumes de NTFS foram criados usando o tamanho padrão da unidade de alocação. Em um conjunto de medições, foi usado um único volume de NTFS em um único dispositivo de adaptador. Em outro conjunto de medições, foi criado um volume RAID5 usando todos os quatro dispositivos de adaptador SSD.

Descrição da carga de trabalho

Um conjunto de cargas de trabalho padrão de sistema de arquivos é usado para os testes de desempenho da função do cliente de archive de backup e os testes de desempenho da função do servidor. As cargas de trabalho padrão do sistema de arquivos têm os seguintes atributos:

• Nomes de arquivo e de diretório atribuídos aleatoriamente usando nomes com tamanho variável.
• Profundidade máxima de diretório de dez níveis.
• Máximo de 32 arquivos por diretório.
• Os arquivos são criados a partir da fonte de dados com uma proporção de compactação típica de três para um ao usar o cliente de compactação Tivoli Storage Manager.
• Os arquivos contêm efetivamente zero por cento de dados duplicados dentro de cada volume de carga de trabalho e entre todos os volumes em todos os clientes.
• O tamanho total da carga de trabalho é escalado dependendo do tempo decorrido da função medida, dos requisitos para iniciar múltiplos segmentos, da repetibilidade da medida exigida ou do valor de espaço em disco disponível.
• As cargas de trabalho são criadas em sistemas de arquivo recém-definidos ou partições recém-formatadas.

Cargas de trabalho separadas são criadas com base no tamanho médio de seus arquivos, 10 KB.

Todas as medições de desempenho neste relatório foram realizadas em um ambiente isolado, como mostra a Figura 1, portanto não houve contenção de recursos de fontes além do produto sendo medido. O servidor do Tivoli Storage Manager foi configurado com um armazenamento de disco contendo oito Logical Unit Numbers (LUNs) de 256 GB e oito LUNs de 64 GB em um DS8100 modelo 921, usando oito ranks de unidades de disco de canal de fibra de 146 GB, 10.000 RPM, usando arrays RAID 5 6+P ou 7+P. Cada LUN foi formatado usando o sistema de arquivos NTFS com um tamanho de unidade de alocação de 4 KB. O banco de dados do servidor do Tivoli Storage Manager estava localizado em um único diretório em um volume DS8100 de 64GB, no volume SSD RAID 5 ou no volume SSD JBOD. Os arquivos de log ativo e de archive do servidor do Tivoli Storage Manager foram colocados em LUNs DS8100 de 64GB separados.

O banco de dados do servidor do Tivoli Storage Manager foi preenchido com objetos suficientes e o runstats do DB2 foi executado antes da execução das medições de desempenho, de modo que o melhor uso dos índices de banco de dados foi alcançado. O recurso de reorganização automática de banco de dados foi desativado durante esses testes.

Para medições de backup de banco de dados usando um dispositivo de fita, o tempo de montagem e o tempo de abertura do volume foram incluídos nas medições. A compactação de hardware de fita e mídia de fita de cartucho do IBM LTO™ Ultrium® 5 foi usada nessas medições. Consulte a tabela específica de medições para saber o formato de fita. A compactação de hardware de fita foi ativada para todas as medições de fita nesse relatório.

O objetivo dessas medições é comparar o desempenho entre o banco de dados do servidor do Tivoli Storage Manager usando um único diretório de banco de dados em um volume DS8100, um volume JBOD SSD e um volume RAID 5 SSD. Em todos esses testes, os diretórios de log ativo e de archive do servidor do Tivoli Storage Manager foram colocados em arrays DS8100 e não foram considerados obstáculos em qualquer um dos testes.

Diversas condições variáveis e ambientais podem afetar o desempenho. Os resultados apresentados aqui representam uma perspectiva dos ganhos de desempenho possíveis em um ambiente controlado. Outros resultados podem variar.

Voltar para parte superior

Desempenho da função de cliente da estação de trabalho

Esta seção inclui medições para as funções de cliente/servidor de backup incremental e backup seletivo usando clientes da estação de trabalho. Todas as medições foram feitas com os dados fluindo sobre a LAN. O servidor é configurado com quatro adaptadores Ethernet de 1 GB e cada cliente tem um único adaptador Ethernet de 1 GB. Esses testes com múltiplos clientes foram equilibrados de modo que todas as conexões LAN do servidor ficaram igualmente ocupadas; no entanto, nesses testes com pequenos arquivos, a LAN não é um obstáculo. Todas as comunicações usaram frames Ethernet padrão (1500 bytes).

Todas as medições de função de cliente foram feitas usando o cliente Backup/Archive de linha de comando para cada plataforma cliente.

Backup incremental de LAN

A função de backup incremental é usada para fazer backup de arquivos alterados no sistema de arquivos cliente especificado. Os dados são transferidos do cliente para o servidor por meio da LAN e gravados no disco. O tempo decorrido do backup depende do número total de arquivos e diretórios no sistema de arquivos; o número de arquivos novos, alterados ou excluídos; e o tamanho dos arquivos armazenados em backup, além de outros fatores. Após a determinação dos arquivos e diretórios que precisam ser armazenados embackup, a taxa de transferência de arquivos grandes é normalmente limitada pelo dispositivo de armazenamento ou largura de banda de rede e a taxa de transferência de arquivos pequenos é normalmente limitada pelas operações de abrir/fechar arquivo no cliente e no banco de dados em processamento no servidor. Consequentemente,as medições nesta seções são realizadas apenas com a carga de trabalho de arquivos de 10 KB com foco no tempo, a fim de determinar os arquivos alterados nos sistemas de arquivo do cliente e no desempenho de atualização do banco de dados do servidor do Tivoli Storage Manager com essas alterações. O Tivoli Storage Manager pode realizar backups incrementais usando vários métodos otimizados disponíveis para situações diferentes.

Backup incremental usando a opção memoryefficientbackup no significa que o cliente do Tivoli Storage Manager recebe uma lista de arquivos e diretórios e seus atributos do servidor do Tivoli Storage Manager para o sistema de arquivos que está sendo armazenado em backup. Portanto, é possível fazer uma comparação para determinar quais objetos são novos ou alterados e precisam ser armazenados em backup e quais objetos foram excluídos e precisam ser expirados. Backup incremental com base em diário significa que o cliente do Tivoli Storage Manager mantém sua própria lista de objetos novos ou alterados e precisam ser armazenados em backup e objetos que foram excluídos e precisam ser expirados. Como o backup incremental com base em diário não consulta o servidor para obter osdados de inventário e não examina o sistema de arquivos que está sendo armazenado em backup, ele é normalmente mais rápido do que o backup incremental usando a opção memoryefficientbackup no . No entanto, se um número grande o suficiente de clientes estiver fazendo o backup de dados ao mesmo tempo, o banco de dados do servidor do Tivoli Storage Manager poderá se tornar um obstáculo. Isso pode resultar em condições nas quais o backup incremental com base em diário não é mais rápido do que o backup incremental completo.

Os resultados do backup incremental com as diversas opções são exibidos na Figura 2. Observe que os parâmetros de teste estão na tabela 2. O uso de SSDs gerou uma aumento de 70 por cento da taxa de transferência para o backup incremental usando um backup que não tem base em diário. O backup com base em diário mostrou um aumento impressionante de 229 por cento usando SSDs configurados em um array RAID 5. O benefício adicional de proteção RAID não prejudicou o desempenho, como ocorria normalmente.

Backup seletivo de LAN usando deduplicação do cliente

A função de backup seletiva é usada para fazer backup de uma única cópia de cada arquivo e diretório no sistema de arquivos especificado do cliente. Os dados são transferidos do cliente para o servidor por meio da LAN e gravados no disco. A taxa de transferência do backup depende do tamanho dos arquivos processados. A taxa de transferência de arquivos grandes é normalmente limitada pelo dispositivo de armazenamento ou largura de banda de rede e a taxa de transferência de arquivos pequenos é normalmente limitada pelas operações de abrir/fechar arquivo no cliente e no banco de dados em processamento no servidor.

Figura 3 mostra os resultados de backups seletivos usando deduplicação no lado do cliente. No primeiro caso (rotulado "0,1"), cada verificação de um pedaço duplicado descobre que o pedaço é exclusivo e, após a verificação, os dados precisam ser enviados ao servidor. No segundo caso ("100, 2"), cada verificação de um pedaço duplicado descobre que o pedaço é uma duplicação e, após a verificação, os dados não precisam ser enviados ao servidor; no entanto, as informações do banco de dados dos pedaços precisam ser atualizadas.

O segundo caso também exige que a versão existente de cada arquivo seja atualizada para inativa e que a nova versão seja inserida. Essencialmente, o segundo caso envolve mais trabalho de banco de dados, o que significa mais estresse no servidor e, dessa forma, uma diferença maior quando o disco do banco de dados é um obstáculo.

Observe que a taxa de transferência tem base no valor dos dados enviados ou recebidos do servidor. Como os testes que usam a deduplicação podem transferir uma quantidade muito menor de dados do que os testes que não usam a deduplicação, a taxa de transferência pode ser muito menor, mesmo se o tempo decorrido for igual. Por esse motivo, é mais útil se concentrar nas diferenças do tempo decorrido entre esses testes do que da taxa de transferência.

Como mostra a Figura 3, o tempo decorrido do primeiro backup seletivo usando a deduplicação no lado do cliente foi 20 por cento menor ao usar um volume JBOD SSD e 19 por cento menor ao colocar o diretório do banco de dados em um volume RAID 5 SSD, comparado ao uso de um volume DS8100. O tempo decorrido do segundo backup seletivo usando a deduplicação no lado do cliente foi 57 por cento menor com o volume único JBOD SSD e 54 por cento menor ao empregar um volume RAID 5 SSD, comparado ao volume DS8100. O número médio de operações de E/S do banco de dados por segundo (IOPS) executadas durante os testes do segundo backup seletivo foi 1.200 no volume DS8100, 2.900 no volume JBOD SSD e 2.660 no volume RAID 5 SSD. Esses resultados mostram um benefício significativo de SSDs para backup seletivo quando há dados duplicados.

Voltar para parte superior

Desempenho da função do servidor

Esta seção inclui medições para funções do servidor, incluindo expiração do inventário, atualização do banco de dados e backup do banco de dados. O objetivo das medições é comparar o desempenho entre o banco de dados do servidor do Tivoli Storage Manager usando um único diretório de banco de dados em um volume DS8100, um volume JBOD SSD e um volume RAID 5 SSD.

Expiração do inventário

A função de expiração do inventário é usada para remover referências de banco de dados a objetos de backup ou de archive do cliente do armazenamento do servidor com base nas definições de política do Tivoli Storage Manager.

O servidor do Tivoli Storage Manager inclui a capacidade de executar vários processos de expiração do inventário em paralelo, o que pode fornecer uma taxa de transferência bem maior, contanto que o desempenho do banco de dados subjacente seja suficiente. A expiração do inventário pode exigir um valor alto de E/S aleatória de banco de dados e, como não há E/S de dados no pool de armazenamento ou na rede correspondente, o desempenho da expiração do inventário é quase completamente determinado pelo desempenho do banco de dados de metadados. O desempenho do banco de dados depende da velocidade do processador do servidor, do tamanho da memória do servidor, do desempenho do banco de dados e do subsistema de disco do log ativo e da organização das linhas de dados dentro das páginas do banco de dados. Especialmente importante é o desempenho do subsistema de disco no qual o uso de subsistemas com gravação em cache ativada pode melhorar o desempenho do banco de dados.

Quando o volume DS8100 se torna o obstáculo do IOPS com dez processos, a taxa de transferência de expiração do inventário fica 43 por cento mais rápida com o volume JBOD SSD e 44 por cento mais rápida no volume RAID 5 SSD. O número médio de IOPS executados durante esses dez processos de testes de expiração do inventário foi 1.840 no volume DS8100, 3.180 no volume JBOD SSD e 3.230 no volume RAID5 SSD.

Atualização do banco de dados

Os utilitários de atualização do banco de dados foram usados para atualizar o banco de dados do servidor do Tivoli Storage Manager do formato de banco de dados nativo usado para o servidor Tivoli Storage Manager 5.5 para o banco de dados DB2 usado para o servidor Tivoli Storage Manager 6.2. Essa é uma operação demorada, pois os formatos de banco de dados são completamente diferentes. O método de rede foi usado para a atualização, pois é o método mais rápido e não exige recursos de armazenamento intermediários. Para esses testes, o banco de dados existente e o novo banco de dados estavam no mesmo sistema. À medida que um banco de dados é movido para a nova estrutura de banco de dados, a validade dos dados é verificada com base nas restrições aplicadas ao novo banco de dados. Os utilitários de atualização corrigem automaticamente alguns erros no banco de dados.

O processo de atualização exige recursos consideráveis de processador, memória e E/S. Para o mesmo banco de dados, o processo de atualização normalmente exigirá menos tempo decorrido ao usar processadores mais rápidos e um armazenamento de disco mais rápido para o novo banco de dados. Como os utilitários de atualização leem sequencialmente os dados do banco de dados do servidor existente em formato de página, não há a probabilidade de o banco de dados existente se tornar um obstáculo e não é útil fornecer um hardware mais rápido para o banco de dados existente. Apesar de o banco de dados do servidor do Tivoli Storage Manager ser composto por mais de 100 tabelas, na prática há apenas duas ou três tabelas com um número grande de linhas de banco de dados, portanto, há apenas alguns segmentos que executarão a maioria do trabalho. Isso significa que apenas alguns processadores são necessários e a adição de mais processadores não reduzirá o tempo decorrido.

O banco de dados do servidor do Tivoli Storage Manager atualizado nesses testes incluía informações para 128 nós com várias versões de backup incremental e arquivos. O número total de objetos armazenados foi de aproximadamente 60 milhões, todos armazenados em um pool de armazenamento de disco aleatório. Os processos de backup e de archive foram executados simultaneamente de modo que o banco de dados existente foi organizado sem as sequências longas de páginas alocadas em uma única tabela.

Como mostra a Figura 5 acima, a taxa de transferência de atualização do banco de dados foi 100 por cento mais rápida ao usar um volume JBOD SSD e 90 por cento mais rápida ao usar um volume RAID 5 SSD, comparado ao armazenamento do diretório em um volume DS8100. O número médio de IOPS executados durante os testes de atualização foi 790 no volume DS8100, 1.710 no volume JBOD SSD e 1.630 no volume RAID 5 SSD, com um tamanho médio de E/S de aproximadamente 30 KB. O volume DS8100 único foi um obstáculo para a operação de atualização. Embora o uso de mais de um volume DS8100 pudesse aprimorar a taxa de transferência de atualização do banco de dados, o volume JBOD SSD ou o volume RAID 5 SSD não foi um obstáculo.

Backup do banco de dados

A função de backup do banco de dados foi usada para fazer uma cópia do banco de dados do Tivoli Storage Manager no armazenamento do servidor para fins de recuperação. Nesses testes, o banco de dados do servidor do Tivoli Storage Manager incluiu informações para 128 nós com várias versões de backup incremental e arquivos. O número total de objetos armazenados foi de aproximadamente 60 milhões e todos os objetos foram armazenados em um pool de armazenamento de disco aleatório. Não houve uma deduplicação ativa no servidor para esse experimento.

Como mostra a Figura 6 abaixo, a taxa de transferência do backup completo de banco de dados foi essencialmente idêntica para todos os testes, independentemente do posicionamento do banco de dados do servidor do Tivoli Storage Manager. A taxa de transferência de leitura sequencial do adaptador IBM High IOPS SSD foi rápida o suficiente, de modo que outros componentes foram o obstáculo para essa operação.

Voltar para parte superior

Conclusão

Os resultados exibidos aqui mostram o enorme impacto dos SSDs sobre o desempenho do Tivoli Storage Manager quando usado para o armazenamento de diretório de metadados, comparado a um array de disco HDD padrão. O Tivoli Storage Manager deve manter um conjunto detalhado de metadados sobre os arquivos armazenados em backup. Esse banco de dados se torna um obstáculo de ES quando as consultas ou atualizações ao banco de dados se tornam significativas. Os SSDs removem o obstáculo de ES do servidor do banco de dados, fornecendo enormes ganhos de taxa de transferência, mesmo em uma configuração de tolerância a falhas de RAID5. O backup incremental e o backup seletivo mostraram ganhos de até 229 por cento e 50 por cento respectivamente. A expiração do inventário e a atualização do banco de dados também experimentaram ganhos significativos.

Recursos

Aprender

• A tecnologia de armazenamento IBM Solid State usa um dispositivo parecido com uma memória para armazenamento em massa, em vez de um disco giratório ou fita.
  
  
• Os adaptadores PCIe de armazenamento do IBM Solid State representam a tecnologia de cluster NAND mais avançada.
  
  
• O Tivoli Storage Manager fornece uma ampla gama de recursos de gerenciamento de armazenamento.
  
  
• Fusion IO fornece uma tecnologia de estado sólido e soluções de E/S de alto desempenho.
  
  

Discutir

• Participe do Fórum do IBM Tivoli Storage Management
  
  

Sobre os autores

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Tecnologia de ruptura
• IBM Tivoli Storage Manager
• Detalhes de hardware e software
• Desempenho da função de cliente da estação de trabalho
• Desempenho da função do servidor
• Conclusão
• Recursos
• Sobre os autores
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais