ANÁLISE COMPARATIVA DE DESEMPENHO DE FILESYSTEMS EM AMBIENTES VIRTUALIZADOS

Transcrição

1 ANÁLISE COMPARATIVA DE DESEMPENHO DE FILESYSTEMS EM AMBIENTES VIRTUALIZADOS Kleber José da Silva Professor da Faculdade Sumaré Mestre em Redes de Computadores

2 2 RESUMO: Neste artigo será apresentada uma comparação entre filesystems em ambientes virtualizados. Os objetivos são avaliar seus resultados de desempenho na máquina virtual, a utilização de recursos de storage e características de provisionamento e backup em fita, para auxiliar na melhor escolha para uma implementação de consolidação de servidores e ambientes de computação em nuvem. PALAVRAS-CHAVE: Filesystems, Virtualização, Desempenho, Máquinas Virtuais. INTRODUÇÃO A consolidação de servidores em um ambiente virtualizado é uma solução que qualquer empresa, mesmo de pequeno porte, tem buscado implementar. As médias e grandes organizações possuem ambientes enormes e crescendo, vertiginosamente, com a adoção de virtualização não somente de servidores, mas também de desktops, e algumas partindo para a inclusão de uma camada de computação em núvem sobre a infraestrutura de virtualização. Uma parte importante dessa infraestrutura está relacionada à arquitetura do armazenamento dos dados: mais de um filesystem e protocolos de Storages estão disponíveis para o arquiteto de solução escolher durante o planejamento da implementação. Neste artigo será apresentado um experimento de comparação de desempenho e outras características dos filesystems nesse tipo de ambiente. CONTEXTO Para que um sistema computacional seja virtualizado, é necessário um componente de gerenciamento, denominado Virtual Machine Monitor (VMM) ou hypervisor, que consiste de uma camada de software que provê uma interface entre os recursos reais e as máquinas virtuais, fornecendo uma abstração dos recursos computacionais para elas. O hypervisor virtualiza a Central Processing Unit (CPU), o sistema de gerenciamento de memória e o sistema de entrada/saída (E/S). Dentre os componentes de hardware virtualizados (CPU, memória e E/S) como pode ser visto na Figura 1, o que gera maior sobrecarga, são operações de (E/S), sendo que

3 3 uma requisição deve ser tratada por múltiplas camadas de protocolos existentes entre o espaço de usuário e o hardware do sistema [ROSE04]. Figura 1 Estrutura de máquinas virtuais. Fonte: [ROSE04] Para o experimento deste artigo o hypervisor vsphere da empresa VMware foi escolhido por se tratar da maior base instalada, atualmente, nas organizações. FUNDAMENTAÇÃO TEÓRICA Filesystems Os filesystems são responsáveis pela organização, armazenamento, recuperação, atribuição de nomes, compartilhamento e proteção de arquivos [COUL05]. Eles fornecem uma interface de programação que caracteriza a abstração de arquivo, liberando os usuários da preocupação com os detalhes da alocação e do armazenamento físico no disco [TANE02]; [COUL05]. Os sistemas de arquivos são projetados para armazenar e gerenciar um grande número de arquivos, com recursos para criação, atribuição de nomes e exclusão de arquivos [TANE02]. Os sistemas de arquivos assumem a responsabilidade pelo controle de acesso aos arquivos, restringindo o acesso de acordo com as autorizações dos usuários e com o tipo de acesso solicitado (leitura, atualização, execução etc.) [COUL05].

4 4 O hypervisor vsphere da VMware, na sua última versão 5, possibilita a criação de unidades de discos virtuais para as máquinas virtuais por pelo menos quatro maneiras diferentes, sendo a maioria delas utilizando DataStores que são as áreas disponibilizadas pelos Storage. Neste artigo serão testados quatro tipos de discos em uma máquina virtual Windows 2008: a) Disco criado em um DataStore Virtual Machine File System version 3 (S3); b) Disco criado em um DataStore Virtual Machine File System version 5 (S5); c) Disco criado em um área no Storage mapeado, diretamente, para a máquina virtual, ou seja, no esquema Raw Device Mapping (RDM), sendo a formatação em New Technology File System (NTFS); d) Disco criado em um DataStore Network File System (NFS). S3 e S5 Os DataStores S são áreas disponibilizadas no Storage para os hypervisors vsphere por meio do protocolo Fibre Channel Protocol (FCP) em uma infraestrutura Storage Area Network Fibre Channel ou Internet Small Computer System Interface (SAN FC ou iscsi) por uma infraestrutura SAN IP. Uma visão mais simples dessa arquitetura pode ser visualizada na figura 2. Figura 2 Arquitetura de Storage para Datastores S. Fonte: [VMWA07]

5 5 O arquivo.vmdk é a unidade de disco apresentada para a máquina virtual. O Filesystem S3 foi lançada na versão 3 do hypervisor da VMware e introduziu a estrutura de diretórios. O S5 foi iniciado com a versão 5 do vsphere e dentre outras funcionalidades permite a criação de Datastores maiores que 2TBytes. RDM - NTFS O vsphere possibilita a apresentação da área do storage, diretamente, para a máquina virtual com sua funcionalidade RDM, conforme visto na figura 3. Figura 3 Arquitetura de Storage para RDM. Fonte: [VMWA07] Neste caso não é criado o arquivo.vmdk, pois a formatação da Logical Unit Number (LUN) no storage é feita pela máquina virtual, por exemplo NTFS no Windows. Essa arquitetura é recomendada pela VMware para algumas aplicações de cluster ou para utilização de snapshots no próprio storage [VMWA07]. NFS

6 6 Os DataStores NFS são áreas disponibilizadas no Storage para os hypervisors vsphere por meio do protocolo NFS utilizando uma infraestrutura TCP/IP. Figura 4 Arquitetura de Storage para Datastores NFS. Fonte: [VMWA07] A versão do protocolo NFS suportada pela VMware é a versão 3, especificada na RFC 1813 [CALL95]. TRABALHOS RELACIONADOS Alguns artigos foram escritos com o propósito de avaliar os filesystems disponíveis, como o da própria VMware intitulado Performance Characteristics of S and RDM [VMWA07] que explorou os filesystems S3 e RDM, aplicando variações na ferramenta de simulação de carga e tamanho de blocos. Para acessos randômicos ambos produziram vazão similar, e para acessos sequenciais o disco em RDM apresentaram resultados melhores que S3. Esse presente trabalho se diferencia do artigo da VMware por compreender a comparação de desempenho dos filesystems S5 e NFS, além de S3 e RDM - NTFS. Ele pretende analisar o resultado de desempenho dos quatro filesystems após várias execuções e não somente a primeira, a fim de verificar seus comportamentos mediante fragmentação a que são submetidos nos testes. Outra complementação é a análise de outras características dos filesystems como provisionamento e backup.

7 7 ESPECIFICAÇÃO DO EXPERIMENTO Todas as execuções dos testes foram realizadas em uma única topologia mostrada figura 5, sendo que essa arquitetura permitiu a disponibilização dos quatro filesystems testados na mesma máquina virtual e na mesma infraestrutura, sendo assim possível a comparação entre eles. Figura 5 Topologia do Experimento. Fonte: elaborado pelo autor A topologia apresentada é composta por dois servidores físicos HP Proliant DL360G5 como hypervisors, com sistema operacional VMware vsphere 5, identificados na topologia como ESX1 e ESX2. Esses servidores têm conectividade TCP/IP com o Storage por meio de portas Gigabit Ethernet. O Storage é do fabricante NetApp modelo FAS2040, identificado na topologia como FAS01, com sistema operacional proprietário Data ONTAP 8.1. Sua configuração de discos foi disponibilizada em Redundant Array of Independent Disks (RAID 4) formada por sete discos de dados e um de paridade (7D + 1P), do tipo Serial Attached SCSI (SAS) de Rotations Per Minute (RPM). A máquina virtual utilizada no experimento é um Windows 2008 R2 64 bits com 2 vcpu e 1 GB de memória RAM, identificada na topologia como W2K8R2SVR. No storage foram criadas três LUNs e disponibilizadas para os servidores vsphere via iscsi. Um volume NFS também criado no Storage e mapeado para os servidores. No

8 8 gerenciador do hypervisor VMware Virtual Center foram criados 3 datastores (S3, S5 e NFS) e adicionados quatro discos na máquina virtual Windows, sendo uma LUN em RDM. A cada disco foi atribuído um identificador (label) com seu respectivo nome de datastore ou RDM e na máquina virtual foram criadas partições iguais de 10GBytes cada e formatadas com NTFS. SIMULAÇÃO DA CARGA DE ACESSO Por se tratar de um experimento em laboratório e não um estudo de caso em ambiente real, a carga de produção foi simulada pela ferramenta IoMeter [OSDL04]. Esse software foi instalado na máquina virtual Windows 2008 com o propósito de gerar cargas de acesso nos discos locais disponibilizados pelo hypervisor vsphere. A ferramenta permite a simulação do perfil de acesso por meio de ajustes de relação leitura x escrita, tamanho dos blocos transferidos, número de threads simultâneos e relação de acesso randômico x sequencial. Com o intuito de delimitar as combinações possíveis, todas as simulações foram executadas utilizando configurações fixas: relação 75% leitura x 25% escrita, 40% randômico x 60% sequencial, usando 16 threads (# of outstanding I/O), tamanho de arquivo em 32Kbytes, I/O alinhado em blocos de 4Kbytes (o mesmo do Storage Netapp). A figura 6 apresenta a especificação do acesso configurado na ferramenta. Figura 6 Especificação do acesso no IoMeter.

9 9 Os testes foram executados com o ambiente de laboratório dedicado, dessa forma, o resultado não foi influenciado por outros acessos externos. Os demais recursos não citados nos resultados como memória e CPU dos servidores VMware e memória da máquina virtual Windows foram monitorados apenas para identificar eventuais gargalos. Como nenhum ponto foi observado nesses elementos, então, somente o resultado dos principais recursos desejados foi coletado e apresentado, graficamente, conforme identificados a seguir. RESULTADOS Cada teste foi executado por três vezes e a média dos resultados seguintes foi coletada a partir da ferramenta IoMeter na máquina virtual Windows e da ferramenta nativa sysstat no Storage, conforme valores exemplos e explicações seguintes: Servidor Windows IOPs Vazão (MB/s) Tempo de Resposta (ms) Util. CPU MB/s 8.5ms 4% Tabela 1 Exemplo de resultados obtidos das execuções máquina virtual Windows. Storage Netapp Util. CPU Operações/Seg Util. Disco 58% % Tabela 2 Exemplo de resultados obtidos das execuções Storage Netapp. IOPs: operações de entrada e saída por segundo no Servidor; Vazão: taxa de transferência efetiva de dados, leitura e/ou escrita, expressa em Mega Bytes por Segundo (em Inglês: throughput);

10 10 Tempo de resposta: fração média de tempo gasta por uma solicitação de acesso feita pelo servidor retornar com a resposta requerida, expressa em milisegundos (ms); Utilização da CPU: porcentagem média do tempo que a CPU do Servidor ou Storage está ocupada durante a execução do teste; Operações por segundo: quantidade de operações iscsi ou NFS executadas no Storage por segundo; Utilização de Disco: porcentagem média do tempo que os discos do sistema de armazenamento estão ocupados. ANÁLISE COMPARATIVA DOS GRÁFICOS DE DESEMPENHO Nesta seção serão apresentados e analisados os sete gráficos com os valores coletados durante as quatro execuções dos testes, para os quatro filesystems: S3, S5, RDM - NTFS e NFS. A primeira execução inclui um processo de preparação dos discos feito pela ferramenta IoMeter antes da execução inicial e devido a esse comportamento diferente, o resultado também foi diferente em relação às execuções subsequentes. Esse desvio é justificado pela fragmentação dos filesystems a partir da segunda execução. IOPs (Servidor) Na primeira execução, os resultados de IOPs no servidor para os filesystems S3 e 5 apresentaram resultados, ligeiramente, melhores que NFS e esse, por sua vez, um pouco melhor que RDM. A partir da segunda execução, os resultados do NFS foram melhores que os de ambos S, concluindo assim que o disco criado no datastore NFS apresenta melhores índice de fragmentação em relação aos demais. Dados coletados do IoMeter no servidor Windows:

11 Vazão (MB/s) IOPs Servidor a Exec. + Prep 2a Exec. 3a Exec. Execução dos Testes 4a Exec. S3 S5 Figura 7 Gráfico de desempenho de IOPs no servidor. Vazão O próximo gráfico de vazão mostra valores proporcionais ao gráfico anterior de IOPs no servidor, conforme esperado, ou seja, valores muitos próximos na primeira execução para os quatros filesystems, na faixa de 58 MegaBytes/s e a partir da terceira execução o disco em NFS apresenta uma melhoria de cerca de 1 MegaByte/s em relação aos demais. Dados coletados do IoMeter no servidor Windows: (75% leitura x 25% escrita) a Exec. + Prep 2a Exec. 3a Exec. Execução dos Testes 4a Exec. VM FS3 VM FS5 Figura 8 Gráfico de desempenho de Vazão.

12 Utilização de CPU do Servidor (%) Tempo de Resposta (ms) 12 Tempo de Resposta Os resultados de tempo de resposta também são proporcionais aos dois primeiro gráficos, como era de se esperar. Para situações de maior número de IOPs e vazão, o tempo de resposta é menor. Dados coletados do IoMeter no servidor Windows: a Exec. + Prep 2a Exec. 3a Exec. Execução dos Testes 4a Exec. VM FS3 VM FS5 Figura 9 Gráfico de desempenho de tempo de resposta. Utilização de CPU do Servidor Na primeira execução, o S3 gerou uma maior utilização de CPU do servidor virtual, mas reduziu esse número a partir da segunda execução. Na quarta execução o NFS apresenta um valor um pouco maior, porém devido à vazão atingida ter sido maior também. Dados coletados do IoMeter no servidor Windows: 4,5 4 3,5 3 2,5 2 1a Exec. + Prep 2a Exec. 3a Exec. Execução dos Testes 4a Exec. S3 S5

13 Utilização de CPU do Storage (%) 13 Figura 10 Gráfico de utilização de CPU do servidor. Utilização de CPU do Storage Para todas as execuções, os filesystems S3, 5 e RDM geraram uma utilização parecida de CPU no Storage, apenas o NFS gerou um ou dois pontos porcentuais para todas as execuções, justificada pela característica diferenciada de manipulação dos dados em NAS e em SAN. Dados coletados pelo sysstat no Storage: a Exec. + Prep 2a Exec. 3a Exec. Execução dos Testes 4a Exec. S3 S5 Figura 11 Gráfico de utilização de CPU do storage. Operações por segundo no Storage A quantidade de operações dos respectivos protocolos no Storage, iscsi para os três primeiros filesystems e NFS para o último, são proporcionais aos IOPs e a vazão gerados pelo servidor, ou seja, o NFS produziu mais operações no storage a partir da segunda execução pois também havia apresentado melhores resultados de IOPs e vazão no servidor. Dados coletados pelo sysstat no Storage.

14 Utilização de Disco no Storage(%) Operações no Storage a Exec. + Prep 2a Exec. 3a Exec. Execução dos Testes 4a Exec. S3 S5 Figura 12 Gráfico de operações no storage. Utilização de discos do Storage A utilização de discos no Storage foi um pouco menor para o S3 na primeira execução, e nas demais os resultados ficaram parecidos. Uma vez que a vazão do NFS foi mais alta pelos gráficos anteriores, ele deveria ter apresentado maior utilização de disco, mas acabou sendo igual aos demais e com isso apresentando um comportamento otimizado. Para todos os casos, a cada execução nota-se um aumento excessivo da utilização de disco no storage mediante a incidência de fragmentação no filesystem no servidor. Dados coletados pelo sysstat no Storage: a Exec. + Prep 2a Exec. 3a Exec. Execução dos Testes 4a Exec. S3 S5 Figura 13 Gráfico de utilização de disco no storage.

15 15 ANÁLISE COMPARATIVA DAS DEMAIS CARACTERÍSTICAS DOS FILESYSTEMS Outras características dos filesystems, além do desempenho, são importantes para a tomada de decisão na escolha entre eles para uma implementação: Provisionamento: Para comparar o comportamento de provisionamento de espaço entre os quatro filesystems, foram analisados dois procedimentos: criação e deleção dos discos para a máquina virtual. Na criação, verifica-se que todos os quatro filesystems suportam o provisionamento fino (thin provisioning) que usa o espaço no storage somente após a gravação de dados no servidor. Uma desvantagem verificada no experimento para os discos criados nos Datastores S3 e 5 em relação à RDM e NFS está na pequena perda de espaço para a formatação do filesystem S, que não ocorre no NTFS direto em RDM ou em um datastore NFS. No processo de deleção, após a execução dos testes, os discos foram removidos da máquina virtual e apagados do DataStore no VMware vsphere. Nesse caso observam-se comportamentos diferentes: a) Para S3, S5 e RDM, devido a características de SAN, ou seja das LUNs iscsi, o storage não é capaz de identificar os blocos alterados pois os filesystems S ou NTFS informam ao Storage que os blocos não são mais virgens e com isso não há liberação de espaço, imediatamente. A liberação de blocos no Storage só ocorreria após um processo de reclamação de blocos no servidor (block reclamation), ou na criação de novos discos por cima daquele espaço disponível. b) Para o datastore NFS o espaço é, imediatamente, liberado do volume no Storage, característica nativa de volumes NAS. Por esse quesito de provisionamento de datastores NFS apresentou melhor comportamento que S e RDM (NTFS). Backup em fita Um dos grandes vieses da consolidação de servidores em um ambiente virtualizado está

16 16 no backup para fita (tape). Em ambientes com servidores físicos, a capacidade de processamento considerada desperdiçada em horário comercial, era aproveitada durante a madrugada para fazer o backup dos seus dados em fita, já no conceito de otimização da utilização de processamento do hardware de servidores obtida pela virtualização, o Backup passou a ser uma preocupação mais latente. Nos experimentos deste artigo nenhum teste prático comparativo de Backup em fita foi realizado para os filesystems, mas na teoria e nos casos práticos conhecidos para S (3 ou 5) e NTFS em RDM o método de backup para fita tem sido o uso de agente de backup, de qualquer fornecedor, instalado na máquina virtual e os dados sendo copiados pela rede ethernet para um servidor físico responsável por copiar os dados para unidade de fita (Tape Library). Esse servidor é o chamado Media Server que possui conectividade com a unidade de fita, normalmente, por interfaces Fibre Channel. Esse método apresenta algumas deficiências tais como: custo da aquisição de uma licença do agente de backup para cada máquina virtual, gerenciamento de máquinas virtuais novas e que não possuem agente de backup instalado, eventual sobrecarga da rede ethernet da máquina virtual ou do hypervisor durante a janela de backup, etc. A vantagem desse método é permitir a restauração granular de arquivos do filesystem da máquina virtual pela própria ferramenta de Backup. Para datastores NFS, a arquitetura NAS permite realizar o backup para fita dos dados a partir do Storage utilizando o protocolo Network Data Management Protocol (NDMP) [NDMP]. Nesse caso, normalmente, é utilizada a infraestrutura SAN FC em que o Storage esteja conectado, diretamente, a um dispositivo de fita (tape device) e o Backup não consome recursos do servidor hypervisor. Esse método NDMP não exige licenciamento de agente de backup para cada máquina virtual e sim, apenas a aquisição de licença para um agente NDMP instalado no servidor de Backup. O backup pode ser configurado para ser feito de todas as máquinas virtuais presentes no Datastore NFS ou, granularmente, do diretório da máquina virtual. A restauração pela ferramenta de Backup também pode ser feita de forma granular até o nível da máquina virtual, mas não de arquivos dentro do filesystem sendo esta uma desvantagem do modelo. Como alternativa, o administrador do ambiente pode disponibilizar (montar) o disco restaurado na máquina virtual como outra unidade e efetuar a cópia dos arquivos específicos de volta para a unidade de produção.

17 17 TRABALHOS FUTUROS O próximo estágio no estudo da diferença de resultados dos filesystems seria explorar as otimizações possíveis nas configurações ethernet e avaliar se haverá melhorias de desempenho em algum filesystem em relação a outro. Por exemplo: implementar Jumbo Frames em todos os pontos de comunicação para reduzir a sobrecarga de mensagens devido à fragmentação, e analisar se há melhor influencia para iscsi e NFS. Outra sugestão seria utilizar uma comunicação baseada em IPv6 e explorar sua funcionalidade de jumbogramas e comparar a evolução dos protocolos iscsi e NFS com a nova versão do IP na camada de rede. Uma funcionalidade adicional do VMware vsphere que não foi avaliada neste artigo e que pode ser explorada nos trabalhos futuros é a vstorage APIs for Array integration (VAAI) [VAAI]. Sendo suportada na versão 5 do vsphere para todos os filesystems testados, invariavelmente, os resultados deste artigo foram influenciadas pelo VAAI porém não se sabe o quanto, pois não foram avaliadas. Pode-se explorar também a influência da fragmentação dos filesystems conforme pode ser visto nas execuções dos testes subsequentes. Alguns storages possuem comandos para fazer a desfragmentação dos blocos nos discos, como também existem ferramentas no próprio servidor a serem analisadas. O alinhamento de blocos do filesystem com o Storage também é um ponto a ser estudado. Alguns storages trabalham com blocos de 4Kbytes, outros com 512bytes, e isso pode influenciar no número de operações do protocolo gerada no Storage e também na vazão e IOPs do servidor, dependendo da configuração adotada pelo filesystem. Por último, esse estudo pode ser estendido a outros hypervisors, como o XenServer da Citrix e HyperV da Microsoft. Além disso, esse mesmo teste poderá ser feito a partir de uma máquina virtual Linux com o Filesystem ext3 ao invés do NTFS do Windows. CONCLUSÃO Em linhas gerais, os resultados de desempenho do S5 foram um pouco melhores que os demais na primeira execução e preparação dos discos. A partir da segunda execução o

18 18 NFS obteve comportamento melhor, se mostrando um filesystem mais eficiente se submetido à fragmentação natural dos testes executados, intensivamente. Porém as diferenças entre eles, em ambos os casos, não chega a ser significativa a ponto de influenciar, totalmente, na escolha. Neste caso, pode-se concluir que as demais características analisadas, são tão importantes quando o desempenho e ao final entrarem em uma somatória de considerações. Sobre as demais funcionalidades, no provisionamento o NFS apresenta melhor comportamento na liberação de espaço após uma deleção de discos na máquina virtual, característica comum em ambientes de computação em nuvem. No backup em fita, os filesystems S e NTFS - RDM permitem o backup e restauração granular de arquivos porém com desvantagens de maior custo e maior utilização de recursos do servidor. O NFS possibilita o backup NDMP direto do Storage para fita, sem onerar o processamento do servidor e com custo de licenciamento inferior, porém não suporta a restauração granular de arquivos na máquina virtual pela própria ferramenta de backup, o que deve ser feito pelo administrador, alternativamente. Para uma análise global somando desempenho, provisionamento e backup em fita, os discos criados em Datastores NFS se mostram como opção mais interessante para uma implementação de ambientes virtualizados. REFERÊNCIAS BIBLIOGRÁFICAS [ROSE04], Robert W. Rose; Survey of System Virtualization Techniques. Artigo, USA (2004). [COUL05] George Coulouris et al; Distributed systems: concepts and design, 4. ed. Harlow: Addison Wesley Longman, 927 p (2005). [TANE02] Andrew S. Tanenbaum, Maarten van Steen; Distributed Systems: Principles and Paradigms, New Jersey: Prentice Hall, 803 p (2002). [VMWA07] VMware Inc; Performance Characteristics of S and RDM. Artigo, USA (2007). [CALL95] B. Callaghan et al; NFS version 3 Protocol Specification, RFC 1813, USA (1995). [OSDL04] Open Source Development Lab; Iometer project, (2004).

19 19 [NDMP] Network Data Management Protocol; The NDMP Initiative, [VAAI] VAAI - vsphere Storage APIs for Array Integration,