FACULDADES INTEGRADAS DO BRASIL - UNIBRASILCURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
LEONARDO ANTÔNIO DOS SANTOS
COMPARTILHAMENTO DE DADOS EM STORAGE DE BAIXOCUSTO E ALTA DISPONIBILIDADE NA UNIBRASIL
CURITIBA
2012
LEONARDO ANTÔNIO DOS SANTOS
COMPARTILHAMENTO DE DADOS EM STORAGE DE BAIXO
CUSTO E ALTA DISPONIBILIDADE NA UNIBRASIL
Trabalho de Conclusão de Curso apresen-tado ao Curso de Bacharelado em Siste-mas de Informação da Faculdades Integra-das do Brasil - Unibrasil.
Orientador: Esp. Sabrina Vitório OliveiraSencioles
Co-orientador:Me. Pedro Eugênio Rocha
CURITIBA
2012
RESUMO
Nos últimos anos as demandas por áreas de armazenamento de dados, sejam emtermos de desempenho, confiabilidade ou tamanho, têm crescido exponencialmentee de forma desproporcional ao crescimento do processamento e memória. Diantedisso, este trabalho propõe uma solução de armazenamento de dados para a facul-dade UniBrasil, que pode ser aplicada em outros cenários, com garantia dos dadosarmazenados em caso de perda de discos e um bom nível de performance por contada distribuição entre nós do cluster. Foi também realizado um conjunto de testesdemonstrando o comportamento da solução em cenários próximos aos reais, assimcomo parametrizações que podem influenciar os resultados em cada cenário, che-gando a resultados esperados nos workloads semelhantes à principal aplicação destetrabalho, como servidor de arquivos. Ao final, são feitas considerações sobre as diver-sas contribuições deste tipo de abordagem e outros trabalhos que podem beneficiar-see ampliar este trabalho.
Palavras-chave: AoE. ATA. Ethernet. Alta Disponibilidade. Armazenamento. Com-partilhamento de Dados.
ABSTRACT
In the last years the need for data storage capacity, whether in terms of performance,reliability or size, have grown exponentially and out of proportion to the growth of theprocessing and memory. Therefore, in this paper we propose a solution for data sto-rage UniBrasil University, which can also be applied in other scenarios, with guaranteeddata stored in case of loss of disks and a high aggregated performance due to the dis-tribution among cluster nodes. We have also conducted a set of experiments showingthe behavior of the solution in near to real scenarios, as well as different paramete-rizations that can influence the results in each scenario, and at the final showing theexpected results in workloads similar to the main application of this work, like file ser-ver. Finally, we discuss about various contributions of this approach and we show howother work can benefit and yet expand this work.
Keywords: AoE. ATA. Ethernet. High Available. Storage. Data Sharing.
LISTA DE FIGURAS
–FIGURA 1 Servidor NAS e SAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18–FIGURA 2 Comparativo entre os principais protocolos SAN existentes. . . . . . 21–FIGURA 3 RAID níveis 0 a 5. Os discos cópia de segurança e paridadeestão sombreados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25–FIGURA 4 Estrutura das camadas do LVM. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28–FIGURA 5 Menus e tela de gerenciamento de volumes do FreeNAS. . . . . . . . 30–FIGURA 6 Tela de apresentação de LUNs iSCSI no Openfiler. . . . . . . . . . . . . . 31–FIGURA 7 Arquitetura do GFS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33–FIGURA 8 Arquitetura da Solução: (a) arrays de discos com RAID5; (b) má-quinas targets; e (c) switch intermediário entre a máquina initiator etarget ; (d) uma máquina initiator. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40–FIGURA 9 Componentes de interconexão de um conjunto IDE. . . . . . . . . . . . . . 42–FIGURA 10 Modelo padrão de particionamento de disco no host target. *In-dica que existem mais dois discos intermediários com a mesma con-figuração RAID do último. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44–FIGURA 11 Modelo especial de particionamento de disco no host target. *In-dica que existem mais dois discos intermediários com a mesma con-figuração RAID do último. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47–FIGURA 12 Funcionamento sumarizado da máquina gateway. Dividida emtrês partes: (1) como os clientes visualizam o gateway, (2) comoo gateway administra os volumes e (3) como os targets são vistospelo gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48–FIGURA 13 Interface do usuário com exemplos de aplicações que podem serdisponibilizadas com a solução proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . 51–FIGURA 14 Vazão de disco alcançada por diferentes tipos de workloads emdiscos locais e remotos. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54–FIGURA 15 Tempo de CPU por operação de I/O em diferentes workloads.Quando indicado no topo das barras o valor correto, foi modificadopara melhor visualização dos resultados. . . . . . . . . . . . . . . . . . . . . . . . . . . 56–FIGURA 16 Quantidade de dados trafegados na rede (transmitido + recebido)por operação. Quando indicado no topo das barras o valor correto,foi modificado para melhor visualização dos resultados. . . . . . . . . . . . . 58–FIGURA 17 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65–FIGURA 18 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66–FIGURA 19 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67–FIGURA 20 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67–FIGURA 21 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67–FIGURA 22 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68–FIGURA 23 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68–FIGURA 24 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69–FIGURA 25 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69–FIGURA 26 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70–FIGURA 27 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
–FIGURA 28 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71–FIGURA 29 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72–FIGURA 30 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72–FIGURA 31 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72–FIGURA 32 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73–FIGURA 33 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74–FIGURA 34 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74–FIGURA 35 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74–FIGURA 36 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75–FIGURA 37 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75–FIGURA 38 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75–FIGURA 39 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76–FIGURA 40 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76–FIGURA 41 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77–FIGURA 42 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77–FIGURA 43 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77–FIGURA 44 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78–FIGURA 45 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78–FIGURA 46 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79–FIGURA 47 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79–FIGURA 48 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80–FIGURA 49 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80–FIGURA 50 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80–FIGURA 51 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81–FIGURA 52 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81–FIGURA 53 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82–FIGURA 54 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82–FIGURA 55 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83–FIGURA 56 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83–FIGURA 57 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84–FIGURA 58 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84–FIGURA 59 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84–FIGURA 60 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85–FIGURA 61 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85–FIGURA 62 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86–FIGURA 63 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87–FIGURA 64 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87–FIGURA 65 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87–FIGURA 66 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88–FIGURA 67 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88–FIGURA 68 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89–FIGURA 69 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89–FIGURA 70 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90–FIGURA 71 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90–FIGURA 72 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91–FIGURA 73 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92–FIGURA 74 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92–FIGURA 75 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93–FIGURA 76 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93–FIGURA 77 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
–FIGURA 78 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94–FIGURA 79 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94–FIGURA 80 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
LISTA DE QUADROS
–QUADRO 1 Descrição do ambiente de testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52–QUADRO 2 Configuração do arquivo /etc/apt/sources.list. . . . . . . . . . . . . . . . . . . . 95–QUADRO 3 Instalação de pacotes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96–QUADRO 4 Cópia de segurança do boot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96–QUADRO 5 Restauração da partição de boot. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97–QUADRO 6 Instalação do vblade e export do volume de armazenamento re-dundante. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98–QUADRO 7 Export do volume de armazenamento não redundante. . . . . . . . . . 98–QUADRO 8 Instalação de pacotes necessários ao gateway. . . . . . . . . . . . . . . . . . 99–QUADRO 9 Configurações no gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99–QUADRO 10 Criação e manipulação dos grupos de volumes. . . . . . . . . . . . . . . . . .100–QUADRO 11 Criação e manipulação dos volumes lógicos. . . . . . . . . . . . . . . . . . . . .100–QUADRO 12 Lista de comandos úteis no gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . 102–QUADRO 13 Lista de comandos úteis no target. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
LISTA DE SIGLAS
HD Hard Disk - Disco RígidoNFS Network File SystemSMB Server Message BlockFC Fibre ChannelAoE ATA Over EthernetUSB Universal Serial BusNFS Network File SystemFTP File Transfer ProtocolHTTP Hypertext Transfer ProtocolDMA Direct Memory AccessHBAs Host Bus AdaptersLVM Logical Volume ManagerECC Error Correcting CodeFTP File Transfer ProtocolGoogleFS Google File SystemCDSBCADU Compartilhamento de Dados em Storage de Baixo Custo e Alta Dis-
ponibilidade na UnibrasilvBlade Virtual EtherDrive blade AoE targetIDE Integrated Drive ElectronicsMBR Master Boot RecordGRUB GRand Unified BootloaderMTU Maximum Transmission UnitSSH Secure Shell
LISTA DE ACRÔNIMOS
CIFS Common Internet File SystemiSCSI Internet Small Computer System InterfaceSAN Storage Area NetworkNAS Network Attached StorageDAS Direct Attached StorageATA Advanced Technology AttachmentSCSI Small Computer Systems InterfaceLAN Local Area NetworkSAS Serial Attached SCSISATA Serial ATAOSI Open Systems InterconnectionRSYNC Remote SynchronizationWebDAV Web-based Distributed Authoring and VersioningBIOS Basic Input/Output System
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131.2 OBJETIVO GERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.3 OBJETIVOS ESPECÍFICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.4 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152 REVISÃO DE LITERATURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1 MÉTODOS DE CONEXÃO A DISPOSITIVOS DE ARMAZENAMENTO . . . . . 162.1.1 Direct Attached Storage (DAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.1.2 Network Attached Storage (NAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172.1.3 Storage Area Network (SAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 PROTOCOLOS PARA COMPARTILHAMENTO DE DISCOS EM SAN . . . . . . . 192.2.1 ATA Over Ethernet (AoE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.2.2 Internet Small Computer System Interface (iSCSI) . . . . . . . . . . . . . . . . . . . . . . . . 202.2.3 Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.3 DESEMPENHO E ALTA DISPONIBILIDADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.3.1 Redundant Array of Inexpensive Disks (RAID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232.3.2 Logical Volume Manager (LVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 263 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.1 FREENAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 293.2 OPENFILER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.3 GOOGLE FILE SYSTEM (GOOGLEFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 323.4 DISCUSSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334 METODOLOGIA DA PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.1 NATUREZA DA PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 354.2 TIPO DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 355 SOLUÇÃO PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1 FERRAMENTAS UTILIZADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.1 AoE tools e vBlade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.2 Linux Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.3 Logical Volume Manager (LVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.4 MDADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.2 TOPOLOGIA GERAL DA SOLUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3 DESCRIÇÃO DETALHADA DA SOLUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.1 Hosts (Target) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.3.1.1 Modelo Padrão de Particionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.3.1.2 Modelo Especial de Particionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.3.2 Gateway (Initiator ) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 485.3.3 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 506 VALIDAÇÃO E AVALIAÇÃO DA SOLUÇÃO PROPOSTA . . . . . . . . . . . . . . . . . . . . 526.1 AMBIENTE E METODOLOGIA DE TESTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.2 VAZÃO DE DISCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.3 UTILIZAÇÃO DE CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 556.4 UTILIZAÇÃO DE REDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Apêndice A -- INSTALAÇÃO E CONFIGURAÇÃO DA MÁQUINA TARGET . . . . . 65A.1 INSTALAÇÃO NO MODELO PADRÃO DE PARTICIONAMENTO . . . . . . . . . . . . 65A.2 INSTALAÇÃO NO MODELO ESPECIAL DE PARTICIONAMENTO . . . . . . . . . . 91A.3 BACKUP E RESTAURAÇÃO DA PARTIÇÃO DE BOOT . . . . . . . . . . . . . . . . . . . . . 95A.4 EXPORTAÇÃO REMOTA DOS VOLUMES DE DISCO . . . . . . . . . . . . . . . . . . . . . . 97Apêndice B -- INSTALAÇÃO E CONFIGURAÇÃO DO GATEWAY . . . . . . . . . . . . . . 99Apêndice C -- COMANDOS ÚTEIS NA MANIPULAÇÃO DO CLUSTER . . . . . . . . 102
12
1 INTRODUÇÃO
De modo geral, a tecnologia tem se tornado cada vez mais essencial no dia a
dia das empresas e das pessoas. Grandes corporações têm utilizado sistemas infor-
matizados para gerenciar as suas linhas de produção, sistemas de controle de estoque
e compartilhamento de arquivos. Especialmente sobre o compartilhamento de arqui-
vos, os volumes de dados têm aumentado em proporção cada vez maior. Basta obser-
var o crescimento de serviços de armazenamento de dados famosos como YouTube
(YOUTUBE, LLC, 2011), 4shared (4SHARED.COM, 2005) e Source Forge (GEEK-
NET, INC, 2011). Além da necessidade de compartilhamento de grandes quantidades
de dados, muitas empresas possuem informações que precisam ser armazenadas de
forma segura e com alta disponibilidade, ou seja, a informação necessita estar dispo-
nível sempre que for solicitada.
Assim, é fácil pensar em juntar vários Hard Disk (HD - Disco Rígido, em por-
tuguês) a fim de solucionar o problema do compartilhamento de arquivos. Mas esta
solução, apesar de parecer fácil, na prática não é possível, caso se utilize para isso
métodos tradicionais de compartilhamento de arquivos, como CIFS, NFS ou SMB —
protocolos para compartilhamento de arquivos para sistemas de arquivos (filesystems)
como Windows ou Linux. A justificativa para isso é porque esses métodos comparti-
lham apenas os arquivos e não os dispositivos de armazenamento, o que impossibilita
o gerenciamento destes dispositivos de forma remota para soluções de baixo nível
tecnológico para alta disponibilidade.
Nesse contexto, surgiram outros protocolos para compartilhamento de dispo-
sitivos de armazenamento de dados (ou block devices), sendo os principais deles o
Internet Small Computer System Interface (iSCSI) (SATRAN et al., 2004) e o Fibre
Channel (FC) (CLARK, 1999). Ambos os protocolos cumprem os objetivos do ar-
mazenamento de dados de forma segura, com alta disponibilidade e para grandes
quantidades de arquivos. Os principais problemas que envolvem estes protocolos são
o alto custo de tecnologia e a dependência de hardware específico para implantação
para o FC e o alto consumo de recursos de hardware do iSCSI.
O ATA Over Ethernet (AoE) é um protocolo open source (código aberto) de-
senvolvido pela empresa Coraid (HOPKINS; COILE, 2001) e disponibilizado à comu-
nidade de ciências da computação a fim de ser estudado e melhorado em sua imple-
mentação. Ele resolve os problemas mais comuns do FC e iSCSI que são, respectiva-
mente, alto custo e sobrecarga de rede.
13
O restante deste capítulo está dividido da seguinte forma: na seção 1.1 será
feita uma explanação dos problemas enfrentados pela Unibrasil no armazenamento e
disponibilização de dados que motivaram a condução deste trabalho; a seção 1.2 e 1.3
trata dos objetivos gerais e específicos daquilo que se busca após a conclusão deste
trabalho; a seção 1.4 apresenta os principais motivos que justificam os resultados
esperados diante dos problemas expostos na seção 1.1.
1.1 PROBLEMA
Antes do fácil acesso encontrado nos dias atuais às redes de computadores,
caso um professor desejasse compartilhar um arquivo com uma turma, seja texto,
áudio ou vídeo, deveria gravar o seu conteúdo em uma mídia (discos removíveis, CD-
ROMs, DVD-ROMs ou flash-drives) e repassar uma cópia entre todos os alunos ou
distribuir várias cópias entre eles. Com o passar do tempo, o acesso à Intranet e
Internet assim como a computadores pessoais, notebooks, tablets e smartphones se
tornou mais acessível a todos. Porém, as tecnologias que proviam o acesso aos dados
não evoluíram na mesma proporção. Deste modo, as instituições de ensino se viram
diante da falta de uma área de armazenamento de dados compartilhada entre todo o
corpo docente e discente.
Além da falta de espaço, surge também o alto custo nas tecnologias de arma-
zenamento de dados para compartilhamento de arquivos em alta disponibilidade. Não
basta compartilhar dados, é necessário que estes dados estejam sempre disponíveis
quando solicitados e livres de desastres em casos de perdas casuais dos discos. Para
solucionar este problema, o custo de tecnologias como FC e iSCSI nativo torna-se alto
quando comparado com tecnologias como AoE, pois exigem hardware específico para
este fim (ZHOU; CHUANG, 2009).
Por fim, todos os dias, uma grande quantidade de hardware sem uso é lan-
çado ao meio ambiente, seja em grandes salas preparadas para recebê-los ou em
locais não tão apropriados para este fim, como lixões. Implementações de protocolos
e ferramentas em software surgiram a fim de conectar vários discos modernos e de
aumentar a sua performance em conjunto. Pesquisas recentes têm implementado es-
tes protocolos e ferramentas de uso em código livre que tornam possível a reutilização
de hardware comuns, dando a eles o comportamento de hardware mais modernos e
trazendo uma série de benefícios para a sociedade, principalmente através do cuidado
com o meio ambiente.
14
Diante do quadro apresentado, como suprir a necessidade iminente de
uma área de compartilhamento de dados sem onerar ainda mais o meio ambi-
ente, reaproveitando os recursos existentes, e sem utilizar mais recursos mone-
tários para este fim?
1.2 OBJETIVO GERAL
O objetivo geral deste trabalho é juntar tecnologias da área de armazenamento
de dados dentro de uma arquitetura que, com a utilização do protocolo de compartilha-
mento de discos em software livre juntamente com outras ferramentas e tecnologias
em software livre, disponibilize ao corpo docente e discente da UniBrasil uma área
de armazenamento de dados com altos padrões de disponibilidade e desempenho
para ser usada em conjunto com aplicações de compartilhamento de arquivos mais
diversos, permitindo aos usuários compartilharem os seus dados e auxiliando na vida
acadêmica.
A estrutura criada por este trabalho poderá ser utilizada tanto para armazenar
dados dos alunos e professores quanto para apoiar trabalhos futuros (outros siste-
mas) e outras contribuições que necessitem de uma solução de armazenamento de
dados em alta disponibilidade. Além disso, com a homologação da arquitetura, esta
poderá ser publicada em portais de software livre e ajudar a resolver problemas de
armazenamento de outras instituições de ensino que assim desejarem.
1.3 OBJETIVOS ESPECÍFICOS
Além do objetivo geral da implantação da arquitetura proposta, pode-se des-
tacar também objetivos específicos que envolvem a aplicação desta solução. Sendo
eles:
1. Estudar protocolos de armazenamento de dados em redes Storage Area Network
(SAN, ou rede exclusiva de dados), tecnologias de armazenamento de dados em
alta disponibilidade e analise de performance através de macro-benchmarks;
2. Avaliar as relações que existem entre as tecnologias existentes para o fim pro-
posto por este trabalho e, com a junção das mais adequadas, aplicá-las visando
a solução do problema apresentado;
15
3. Implantar uma solução tecnológica que, por meio da utilização das tecnologias
estudadas e avaliadas, seja capaz de entregar uma infraestrutura de armazena-
mento de dados que funcione de forma inteligente e distribuída, permitindo que
outros trabalhos possam somar a esta infraestrutura e proporcionar à UniBrasil
recursos tecnológicos que contribuam para a ampliação do conhecimento.
1.4 JUSTIFICATIVA
O compartilhamento de arquivos, apesar de utilizar ferramentas simples e co-
nhecidas, torna-se muito custoso quando se busca implantar grandes áreas de arma-
zenamento de dados, principalmente se forem distribuídas e com alta disponibilidade.
Isso acontece devido ao fato dessa implantação ser possível somente com a compra
de equipamentos caros e especializados para este fim.
Protocolos como o ATA over Ethernet (AoE) surgem com a finalidade de solu-
cionar problemas de compartilhamento de discos e consequentemente de arquivos, só
que a um baixo custo de tecnologia, se comparado a protocolos para acesso remoto
a discos como iSCSI nativo e FC.
Em conjunto com outras tecnologias que promovem a alta disponibilidade,
este trabalho será capaz de resolver os problemas de pesquisa apresentados. Ou
seja, seria possível a UniBrasil ter uma área de armazenamento de dados a um custo
baixo e sem lançar mais material sem uso no meio ambiente. Além disso, a área
de dados apresentada poderá ser utilizada para qualquer outra finalidade de ensino,
pesquisa e desenvolvimento, como por exemplo, a criação de ambientes virtualizados.
O restante deste trabalho está dividido da seguinte forma: o capítulo 2 apre-
senta um estado da arte das tecnologias que norteiam este trabalho, o capítulo 3 mos-
tra trabalhos que se assemelham ou reforçam a abordagem deste trabalho, o capítulo
4 define os métodos aplicados no processo de pesquisa, o capítulo 5 traz a solução
proposta em detalhes a qual é validada por um conjunto de testes apresentados no
capítulo 6, por fim, o capítulo 7 conclui o trabalho com uma avaliação geral, além de
citar as suas contribuições e trabalhos futuros.
16
2 REVISÃO DE LITERATURA
Neste capítulo será apresentada uma visão geral das tecnologias utilizadas
neste trabalho, além de mostrar em detalhes a principal tecnologia em que este traba-
lho se baseia, o protocolo AoE juntamente com outros protocolos similares e, ao final,
será feita uma comparação entre estes protocolos, justificando o uso do AoE para o
propósito deste trabalho. Será apresentada também uma visão conceitual sobre as
tecnologias que garantem a alta disponibilidade juntamente com uma boa administra-
ção dessas grandes áreas de armazenamento.
2.1 MÉTODOS DE CONEXÃO A DISPOSITIVOS DE ARMAZENAMENTO
Através do que se tem na literatura, Storage Area Network (SAN) e Network
Attached Storage (NAS) são termos potencialmente confundíveis. NAS significa com-
partilhar arquivos ao passo de que SAN significa compartilhar discos. A principal dife-
rença entre eles está em que no NAS o cliente acessa arquivos e diretórios individuais
compartilhados pelo servidor, no SAN o cliente tem acesso ao dispositivo físico real
podendo realizar qualquer tipo de operação sobre ele (CORAID, INC, 2008). Mas, para
se ter uma visão adequada de como se chegou a essas tecnologias, antes é necessá-
rio entender o que significa Direct Attached Storage (DAS), que será apresentado na
próxima seção.
2.1.1 DIRECT ATTACHED STORAGE (DAS)
Inicialmente, dispositivos de armazenamento de dados, sejam discos, unida-
des de fitas de backup e dispositivos de CD-ROM, eram conectados diretamente a
uma máquina, o que explica o nome DAS (ou conexão direta de armazenamento).
Isso era feito geralmente por meio de conexões sobre interfaces Advanced Technology
Attachment (ATA) ou Small Computer Systems Interface (SCSI), chegando a veloci-
dades de 160 Mbps para o ATA e 320 Mbps para o SCSI nas suas versões iniciais
(MAJSTOR, 2004; LOBUE et al., 2002).
A abordagem DAS possui vários tipos de limitações. O número de dispositivos
que poderiam ser conectados a um barramento, mesmo em versões mais recentes do
SCSI, é limitado a 16 dispositivos e a distância máxima alcançada pelo cabeamento
não ultrapassa 15 metros. Outra grande limitação é o compartilhamento do mesmo
dispositivo entre múltiplos hosts, possível apenas através da compra de controladoras
17
caras e especializadas para este fim, além desse compartilhamento ter desempenho
tipicamente inferior ao de um único dispositivo. Por último, quando é necessário rea-
lizar uma expansão de volume de armazenamento ou substituições de discos falhos,
torna-se também necessário fazer um desligamento do sistema (MAJSTOR, 2004),
exceto quando utilizados discos externos através de interfaces Universal Serial Bus
(USB).
2.1.2 NETWORK ATTACHED STORAGE (NAS)
O compartilhamento de arquivos é uma das formas mais comuns de storages
de rede e frequentemente utilizado nos sistemas operacionais Windows e Macintoch
para versões home. Um computador, em particular um servidor de arquivos, permite
outros computadores acessarem alguns dos seus arquivos e/ou diretórios. Para com-
partilhar seus arquivos, um protocolo de compartilhamento de arquivos é utilizado. Os
protocolos mais conhecidos nessa categoria são Network File System (NFS), CIFS
(formalmente chamado de SMB, a base do compartilhamento Windows e implemen-
tado no Linux pelo protocolo SAMBA), File Transfer Protocol (FTP), Hypertext Transfer
Protocol (HTTP), entre outros. A Figura 1(a) mostra uma típica conexão de clientes
a um servidor de arquivos através de uma Local Area Network (LAN, ou rede local)
(CORAID, INC, 2008).
No cenário dos compartilhamentos de arquivos NAS, uma mesma máquina
pode ser cliente e servidor, pois em ambientes pequenos normalmente todas as má-
quinas compartilharem um ou mais de seus arquivos com todas as outras máquinas.
Já em um ambiente corporativo, é comum clientes Windows acessarem via CIFS/SMB
um servidor que conecta a vários dispositivos de armazenamento maiores por meio
NFS. Além disso, é bastante utilizado o empilhamento de compartilhamentos de arqui-
vos através da rede, de modo que às vezes um servidor chega a fazer até o armazena-
mento local através da rede, ou seja, são tantas camadas de compartilhamento que,
às vezes, algumas máquinas estão se auto-compartilhando (CORAID, INC, 2008).
Por fim, o compartilhamento de arquivos pode ser um gargalo de desempenho,
uma vez que um único servidor deverá gerenciar muitos tipos de operações sobre
arquivos (leitura, escrita, criação, exclusão, incremento, etc.). Além disso, quando um
cliente escreve um arquivo no servidor, o arquivo é escrito duas vezes, uma no cliente
no seu virtual shared file space (espaço de arquivos virtual compartilhado) e outra no
servidor, no disco real (LANDOWSKI; CURRAN, 2011).
18
2.1.3 STORAGE AREA NETWORK (SAN)
O compartilhamento de discos é mais simples que o de arquivos, porém é bem
menos conhecido pela maioria das pessoas, assim, nem sempre o termo “comparti-
lhar” denota compartilhar arquivos. Normalmente um servidor de discos compartilha
um volume de disco (disco real ou virtual) com apenas um computador por vez, o com-
putador monta o volume e o usa (o termo monta remete às montagens de fitas citadas
nos manuais de fitas de 1960) (CORAID, INC, 2008). Nesse sentido, o SAN é mais
parecido com o DAS.
Servidor de ArquivosDiretórios/Arquivos
Compartilhados
NAS
Clientes
(a) Arquitetura padrão NASServidor de Discos Array de Discos
SAN
Clientes
(b) Arquitetura padrão SAN
FIGURA 1: Servidor NAS e SAN.
FONTE: O autor (2012).
Além disso, o compartilhamento de discos por muitas máquinas tem um custo
mais baixo do que no DAS, pois um disco pode simplesmente ser formatado com um
cluster filesystem – por exemplo, com o VMWare VMFS (VAGHANI, 2010) ou OCFS
(FASHEH, 2006). Este tipo de abordagem é utilizada para aplicações em que é ne-
cessário que múltiplos hosts acessem o disco compartilhado, como é o caso da virtu-
alização em cluster.
O SAN, assim como o DAS, permite acesso raw device (ou acesso bruto ao
dispositivo) a dispositivos de disco, porém com as vantagens de não ser limitado à
quantidade de dispositivos de disco e à distância entre os dispositivos. Isso permite
ao SAN não só simplesmente compartilhar discos e ser uma rede dedicada a tráfego
de armazenamento, mas realizar operações de baixo nível nesses dispositivos, como
formatar, reescrever tabelas de partições e utilizar os discos em conjunto com tecno-
logias de alta disponibilidade, o que não é possível com NAS (MAJSTOR, 2004). Com
isso, o SAN torna-se a tecnologia mais adequada ao objetivo final deste trabalho.
19
2.2 PROTOCOLOS PARA COMPARTILHAMENTO DE DISCOS EM SAN
Para tornar possível o compartilhamento de discos em SAN, são necessários
protocolos — formas padrões de comunicação entre sistemas ou entre interfaces de
dispositivo. Na subseção 2.2.1 será apresentada a principal tecnologia em que se
baseia este trabalho, o protocolo AoE; as subseções 2.2.2 e 2.2.3 mostram outros
dois protocolos que cumprem a mesma finalidade com algumas diferenças, o iSCSI e
o Fibre Channel.
2.2.1 ATA OVER ETHERNET (AOE)
De forma sumária, o AoE é um protocolo de padrão aberto que permite o
acesso direto de hosts (clientes de rede) a dispositivos de disco, realizando isto atra-
vés de uma rede. Com ele é possível compartilhar discos simples ou arrays de disco
(conjuntos de discos) usufruindo de todas as vantagens de acesso raw device (acesso
direto ao dispositivo) e ser layer 2 (HOPKINS; COILE, 2001).
O protocolo AoE foi construído para ser simples, de alta performance e baixo
custo em tecnologia, se comparado às principais tecnologias existentes no mercado
para o mesmo fim, como iSCSI e Fibre Channel, quando o objetivo é compartilhar
block device (dispositivo de bloco), pois aposta na principal vantagem da simplicidade
eliminando o overhead TCP/IP, por trabalhar na camada 2 do modelo TCP/IP (HOP-
KINS; COILE, 2001).
Advanced Technology Attachment (ATA) é um conjunto padronizado de co-
mandos para os dispositivos de armazenamento mais comuns. O AoE encapsula os
comandos ATA de um cliente por meio do protocolo Ethernet e repassa ao servidor e
vice-versa. O cliente AoE apenas solicita ao servidor qual disk block (bloco de disco),
disco e shelf (gaveta - ou conjunto de discos) está a sua informação e este bloco é
novamente encapsulado pelo enlace de dados no sentido servidor-cliente (HOPKINS;
COILE, 2001).
Estas vantagens permitem ao AoE não simplesmente acessar os arquivos de
um disco remoto, mas realizar operações de baixo nível em dispositivos de disco,
como formatar sistemas de arquivos e recriar a tabela de partições. Por padrão o AoE
é nativo nos kernels (núcleo do sistema) Linux acima da versão 2.6.11 (HOPKINS;
COILE, 2001).
20
2.2.2 INTERNET SMALL COMPUTER SYSTEM INTERFACE (ISCSI)
O Internet SCSI, ou iSCSI, é um dos mais conhecidos protocolos para stora-
ges SAN. Semelhante ao AoE, o iSCSI também encapsula comandos, mas, no seu
caso são comandos SCSI. Isto também permite ao iSCSI a qualidade de storage SAN
implementado sem o uso de componentes caros (AIKEN et al., 2003).
SCSI é uma popular família de protocolos que torna possível sistemas se
comunicarem com dispositivos E/S (entrada e saída), especialmente dispositivos de
armazenamento. Estes protocolos nada mais são do que protocolos de aplicacao re-
quest /response com um modelo de arquitetura comum, bem como um conjunto de
comandos padronizados para diferentes classes de dispositivos (dispositivos de disco,
unidades de fita, flash-drives etc.) (SATRAN et al., 2004).
Comparativamente, tanto o ATA quanto o SCSI cumprem a mesma finalidade,
ser um conjunto padrão de comandos para conectividade com dispositivos de arma-
zenamento em geral. Tradicionalmente, o ATA era considerado mais barato e simples
e o SCSI mais caro e robusto. Nos dias atuais, ambos possuem Direct Memory Ac-
cess (DMA - acesso direto à memória), que elimina o problema de interrupções à CPU
durante o processo de leitura ou escrita. Ambos também podem fazer enfileiramento
de comandos fora de ordem para a CPU. Bem como, possuem recurso de hotswap,
que permite o dispositivo ser removido e conectado sem problemas com o sistema em
execução (INSIDEHPC, LLC, 2006).
Tanto ATA quanto SCSI foram criados para arquiteturas de transferência de
dados originalmente paralela, mas atualmente já se utilizam estes padrões em arqui-
teturas serial com o Serial Attached SCSI (SAS) e Serial ATA (SATA). Comparações
de velocidade entre as interfaces não dependem apenas dos conectores, mas de ca-
racterísticas como a quantidade de giros do disco, o quão rápido a cabeça de leitura
se move, entre outros fatores (INSIDEHPC, LLC, 2006).
2.2.3 FIBRE CHANNEL
Fibre Channel (FC), além de ser um padrão industrial aberto para sistemas
de alta velocidade, é um protocolo para transferência de dados por fibra óptica que
trabalha por meio de várias camadas com diferentes funções, que podem ser vistas
na Figura 2(b). Para o funcionamento nativo do protocolo FC, é necessário a utilização
de equipamentos específicos como Host Bus Adapters (HBAs), switch fabrics e discos
específicos no padrão SCSI-3. Além disso, normalmente, esses equipamentos devem
21
Sistema de Arquivos
SCSI
iSCSI
TCP
IPSEC
IP
Ethernet
(a) iSCSI
Sistema de Arquivos
SCSI
FC4: FC ProtocolInterface
FC3: CommonServices
FC2: Framing FlowControl
FC1: Byte Encoding
FC0: PhysicalInterface
(b) Fibre Channel
Sistema de Arquivos
ATA
AoE
Ethernet
(c) ATA over Ethernet
FIGURA 2: Comparativo entre os principais protocolos SAN existentes.
FONTE: Adaptado de Coraid, Inc. (2012).
ser do mesmo fornecedor, o que ofereceu uma desvantagem para adoção desta tec-
nologia. Mesmo assim, as altas taxas de transferência de dados na rede eram muito
altas, sendo possível obter links de 1 e 2 Gbps (MAJSTOR, 2004). Nos dias atuais já
estão disponíveis especificações que permitem 4 e até 10 Gbps (CISCO, INC., 2012).
As camadas do FC funcionam de modo similar ao modelo de referência Open
Systems Interconnection (OSI), diferindo em algumas partes, e possuem as seguintes
funções: a camada FC0 define o nível físico das conexões do sistema e inclui dispositi-
vos como fibras, conectores e outros equipamentos. A camada FC1 define o protocolo
de transmissão, incluindo a codificação e decodificação de regras, caracteres especi-
ais e controle de erros. A FC2 cuida dos mecanismos de transporte da FC e define
como os dados serão transferidos entre as portas e a ordenação dos dados mesmos.
A FC3 trata do padrão FC, e provê serviços comuns a características avançadas do
FC, como striping e multicast. O FC4 é a camada mais alta e define as regras e ma-
peamentos para que interfaces de aplicação possam trabalhar com FC, como SCSI e
ATM.
Adicionalmente, o protocolo FC necessita de hardware especializado para o
funcionamento (ZHOU; CHUANG, 2009) e tanto o iSCSI quanto o FC trabalham com
o padrão SCSI, que é compatível não apenas com dispositivos de disco, como fitas,
22
scanners e impressoras, o que gera uma sobrecarga de processamento que não é
encontrada no ATA — por este ser compatível apenas com dispositivos de disco (CO-
VINGTON, 2008). Assim, o FC torna-se menos recomendado do que o AoE para a
implementação desta solução tecnológica, pois, além dos problemas apresentados,
traria altas demandas de custo para o projeto, o que fugiria ao escopo desta solução.
2.3 DESEMPENHO E ALTA DISPONIBILIDADE
Nesta seção serão apresentados conceitos relacionados às tecnologias que
provêm alta disponibilidade e que garantem desempenho às aplicações dos usuários
finais. No contexto deste trabalho, alta disponibilidade representa o conjunto das téc-
nicas utilizadas para prover acesso estável aos dados.
A utilização de aplicações em servidores que trabalham de modo simples,
ou sem alta disponibilidade, pode trazer alguns problemas, por exemplo: quando um
servidor que opera em produção começa a receber um volume de requisições além
do convencional, ele não é capaz de lidar com esta nova carga e tornará o serviço
indisponível; outro problema comum é que, quando se utiliza apenas um ponto comum
de acesso aos dados, se tem também um ponto comum de falha. Segundo Brittain
(2008), para evitar isto, algumas técnicas são necessárias, sendo assim, algumas
delas serão apresentadas:
• Fault tolerance (tolerância a falhas): trata-se do nível com que um serviço se
adapta aos diversos tipos de falhas (seja software ou hardware) de modo que
possa continuar a servir clientes transparentemente, ou seja, sem o cliente tomar
conhecimento sobre as falhas.
• Failover: quando um servidor (software ou hardware) sofre uma falha e não pode
mais atender os seus clientes, os clientes são automaticamente encaminhados
para outro servidor que suprirá a carga assumindo que o serviço não está pa-
rado.
• High Availability (alta disponibilidade): um serviço que está sempre disponível,
servindo requisições e pode servir a um número incomum de requisições é con-
siderado altamente disponível. Um serviço altamente disponível deve ser tole-
rante a falhas, ou então ele estará eventualmente indisponível devido a falhas de
hardware ou software.
23
• Distributed (distribuído): “distribuído” significa que um processo computacional
acontece sobre múltiplos servidores que trabalham em conjunto, visando um
objetivo ou formular uma resposta, ou várias, em paralelo. Por exemplo, múltiplos
conjuntos de discos espelhados provendo acesso aos dados por meio de uma
máquina intermediária constituem um servidor de discos distribuído.
• Replicated (replicado): replicação significa que todas as informações são copi-
adas entre muitas instâncias a fim de facilitar a tolerância a falhas e o acesso
distribuído. A replicação de dados será melhor entendida na subseção 2.3.1,
quando explanado o RAID nível 1.
• Load Balancing (balanceamento de carga): quando uma requisição é feita a
um serviço distribuído e a instância que recebeu esta requisição encontra-se
ocupada não podendo supri-la num intervalo de tempo razoável, outra instân-
cia pode ser capaz de suprir esta requisição. O balanceamento de carga é o
responsável por fazer o encaminhamento das novas requisições para o servidor
menos ocupado dentro do cluster (conjunto de softwares ou hardwares com um
processamento comum). Assim, o balanceamento de carga possui a vantagem
de possibilitar a utilização de todos os recursos disponíveis dentro de um cluster.
• Cluster : é considerado uma ou mais instâncias de software que rodam em um ou
mais servidores físicos, servindo os clientes de modo transparente e passando
a impressão de que tudo funciona em conjunto como um único serviço simples
altamente disponível.
No geral, os termos acima se complementam, pois, por vezes, um deles é a
junção de vários outros ou é pré-requisito para que outro seja possível. Desse modo,
as ferramentas que implementam estas características implementam várias de uma só
vez. No contexto do armazenamento de dados essa realidade também é semelhante,
visto que as ferramentas que serão apresentadas neste trabalho realizam um ou mais
desses recursos. Na subseção 2.3.1 serão apresentados os diversos níveis de RAID
e a subseção 2.3.2 será apresentada a ferramenta LVM, a qual faz o gerenciamento
lógico a nível de bloco em dispositivos de armazenamento.
2.3.1 REDUNDANT ARRAY OF INEXPENSIVE DISKS (RAID)
Nos últimos anos, o desempenho das CPUs tem crescido de forma exponen-
cial, chegando a duplicar a cada 18 meses, o que não acontece com os dispositivos de
24
disco. De 1970 aos dias atuais, o tempo médio de movimentação da cabeça de leitura
(seek time) dos discos melhorou de 50 a 100 ms para menos de 10 ms. Desse modo,
a disparidade entre CPUs e dispositivos de disco tem ficado cada vez mais acentuada
(TANENBAUM, 2010).
Por conta do processamento paralelo tornar as CPUs mais rápidas, muitos
passaram a acreditar que o mesmo poderia ser feito para dispositivos de E/S a fim
de agilizar o acesso a disco e diminuir a disparidade de desempenho entre os dispo-
sitivos de entrada e saída e os processadores, assim como de confiabilidade. Neste
sentido Patterson et al. (1988) sugeriram seis organizações para os discos e as defi-
niu como Redundant Array of Inexpensive Disks (RAID - arranjo redundante de discos
baratos), substituindo mais tarde o I por independentes (PATTERSON et al., 1988;
TANENBAUM, 2010).
A ideia básica em que o RAID se baseia é juntar vários discos em um único
volume e apresentar ao sistema um único disco, substituindo a placa controladora
por uma placa RAID, visto que discos ATA e SCSI têm um bom desempenho, con-
fiabilidade e baixo custo, podendo ainda permitir vários dispositivos em uma única
controladora (15 para dispositivos mais robustos) (LOBUE et al., 2002).
O RAID nível 0 é mostrado na Figura 3(a). Ele descreve um modelo de RAID
baseado em stripping, que consiste na divisão dos dados em faixas, cada uma con-
tendo k setores. A faixa 0 representa os setores de 0 a k−1, a faixa 1 os setores de k
a 2k−1 e assim por diante. O processo de gravação é realizado através de uma alter-
nância consecutiva entre as faixas, mais conhecido como round-robin. No exemplo da
Figura 3(a), quando uma operação de leitura é recebida, o controlador RAID quebra
esta operação em outras quatro, que são enviadas para as controladoras de disco e
processadas em paralelo, aumentando o desempenho proporcionalmente ao número
de discos que processam as requisições paralelas. Deste modo, o RAID0 trabalha
melhor em casos de requisições maiores. Uma desvantagem do RAID0 acontece no
caso da perda de dados, pois, como os dados estão divididos em várias faixas, a
perda de um disco causa a perda total dos dados (TANENBAUM, 2010).
Outro tipo de RAID é o RAID nível 1, mostrado na Figura 3(b). Neste tipo de
RAID todos os dados são duplicados em outros discos de forma que existam quatro
discos primários e quatro discos de cópia de segurança (backup). Durante o processo
de escrita, cada faixa é escrita duas vezes; durante o processo de leitura, os dados
podem ser lidos de qualquer uma das faixas. Em consequência disto, o desempenho
da escrita é um pouco pior do que o uso de um único disco, porém, o desempenho
25
Faixa 12Faixa 1Faixa 4Faixa 0
Faixa 13Faixa 1Faixa 5Faixa 1
Faixa 14Faixa 10Faixa 6Faixa 2
Faixa 15Faixa 11Faixa 7Faixa 3
(a) RAID nível 0
(b) RAID nível 1
Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7
(c) RAID nível 2
Bit 1 Bit 2 Bit 3 Bit 4 Paridade
(d) RAID nível 3
Faixa 8Faixa 4Faixa 0
Faixa 9Faixa 5Faixa 1
Faixa 10Faixa 6Faixa 2
Faixa 11Faixa 7Faixa 3 P0-3
P4-7P8-11
(e) RAID nível 4
Faixa 12Faixa 8
Faixa 16
Faixa 9
Faixa 17Faixa 13
Faixa 18Faixa 14Faixa 10
Faixa 19Faixa 15Faixa 11
Faixa 4Faixa 0
Faixa 5Faixa 1
Faixa 6Faixa 2 Faixa 3
Faixa 7
P16-19P12-15
P8-11P4-7
P0-3
(f) RAID nível 5
FIGURA 3: RAID níveis 0 a 5. Os discos cópia de segurança e paridade estão som-breados.
FONTE: Tanenbaum (2010).
da leitura pode ser até duas vezes melhor, visto que pode se obter o dado de até
dois discos em paralelo. A tolerância a falhas é a grande vantagem desta abordagem,
considerando que a perda de um dos discos não ocasiona a perda dos dados, pois o
disco de cópia passa a atuar no lugar do disco danificado. A restauração dos dados é
feita apenas com a instalação de um novo disco, copiando para ele os dados da cópia
de segurança.
Os níveis 2 e 3 de RAID não serão utilizados no desenvolvimento da solu-
ção, mas merecem um breve detalhamento. O RAID nível 2, conforme mostrado na
Figura 3(c), em vez de trabalhar com faixas, como no RAID nível 0 e 1, utiliza pala-
vras (conjuntos de bits) ou, em alguns casos, bytes. Ele trabalha quebrando essas
palavras na quantidade de discos disponíveis, sendo que parte desses bits são utiliza-
26
dos para correção de erros (ECC — Error Correcting Code). A grande desvantagem
desse nível de RAID é que os discos devem estar sincronizados para que esses bits
de correção possam funcionar corretamente. Essa abordagem só faz sentido caso se
utilize uma quantidade substancial de discos (o que, mesmo com 32 discos, tem-se
uma sobrecarga de 19%).
O RAID nível 3, mostrado na Figura 3(d), opera de modo semelhante ao RAID
nível 2, porém mais simplificado, pois guarda um único bit de paridade em um disco
separado, chamado de disco de paridade. Nesse RAID os discos também devem estar
perfeitamente sincronizados. Aparentemente o RAID nível 3 não faz correção de er-
ros, mas essa abordagem só é válida para os erros aleatórios e desconhecidos. Para
casos de erros em que um disco se perde, a posição danificada é conhecida e os bits
necessários para reconstruir os dados no disco substituído podem ser facilmente cal-
culados. A desvantagem dos níveis 2 e 3 de RAID é que, mesmo fornecendo grandes
quantidades de dados com certo nível de disponibilidade, o número de requisições que
eles podem tratar por segundo não é melhor do que um único disco (TANENBAUM,
2010).
O RAID nível 4 trabalha novamente com faixas, conforme mostrado na Figura
3(e), não necessitando que os discos estejam sincronizados. É similar ao RAID nível
0, mas exige que a paridade entre as faixas sejam escritas em um disco extra. Se as
faixas têm k bytes de tamanho, é calculado um OU EXCLUSIVO entre as faixas, que
resulta em uma faixa de paridade de k bytes, e esta é escrita em um disco separado.
Esse nível de RAID é suficiente para a perda de um único disco, mas tem o funciona-
mento prejudicado em casos de pequenas atualizações, pois, para cada atualização,
todos os discos devem ser lidos para que seja recalculada e reescrita a paridade.
Por o RAID nível 4 utilizar apenas um único disco para paridade, este pode
estar sobrecarregado e comprometer toda a performance do arranjo. Esse gargalo
não acontece no RAID nível 5, ilustrado na Figura 3(f), pois este distribui os bits de
paridade por todos os discos do arranjo de modo uniforme e circular, não sobrecarre-
gando um único disco. Entretanto, na quebra de um dos discos, a reconstrução dos
dados torna-se mais custosa, visto que este processo torna-se mais complexo.
2.3.2 LOGICAL VOLUME MANAGER (LVM)
O Logical Volume Manager (LVM) é um padrão de gerenciamento de parti-
ções para discos IDE, SCSI e FC desenvolvido inicialmente pela empresa IBM e pos-
27
teriormente seguido por outras instituições e empresas como HP. Diferente do método
usualmente utilizado de particionamento de discos, o LVM junta vários discos criando
um grande disco virtual tornando fácil o gerenciamento de suas partições lógicas. As-
sim, a sua principal vantagem consiste em um redimensionamento mais flexível das
suas partições. Além disso, o LVM fornece um bom nível de administração de grandes
áreas de armazenamento em disco através das suas subdivisões em volumes físicos,
grupos de volumes e volumes lógicos (LEWIS, 2006).
Quando utilizam-se discos com suporte a hot-swaping (inserção e remoção
física de discos à quente — semelhante a pendrives), pode-se aproveitar da vantagem
do LVM de adicionar, remover e substituir discos caso se deseje mais espaço em disco
sem interrupção dos serviços ou reinicialização do sistema. Isso mostra no LVM um
sistema coerente com os padrões de alta disponibilidade, já que, neste caso, não exige
a reinicialização do sistema (MORIMOTO, 2010).
Outro recurso importante em alta disponibilidade suportado pelo LVM é a tec-
nologia de Snapshot, que permite ao LVM criar cópias inteiras das partições lógicas
em outras partições lógicas, tudo em um tempo bastante reduzido (LEWIS, 2006). Isto
pode ser útil em situações de backup onde os dados a serem salvos devem ser atu-
alizados automaticamente e onde não se pode haver sobrecarga sobre os dados em
uso.
A Figura 4 mostra quatro discos particionados utilizando LVM. Caso fosse uti-
lizado o particionamento comum, uma vez criadas as partições nos discos físicos (ou
Hard Drivers), essas não poderiam ser desfeitas ou reajustadas sem perdas de dados
ou sem um cópia de segurança antecipada que garantisse a salvaguarda dos dados
antes do particionamento. É possível observar que a Figura 4 é composta por seis ca-
madas e, considerando uma visão bottom-up (de baixo para cima) da mesma, o LVM
é responsável pelas camadas de 3 a 5, sendo elas: (3) os volumes físicos (ou physical
volumes), (4) grupo de volumes (ou volume group) e (5) os volumes lógicos (ou logical
volumes). As outras três camadas são utilizadas no particionamento normal, quando
não se utiliza o LVM (LUNES, 2011).
Os volumes físicos representam as partições criadas nos discos rígidos e são
úteis para serem apresentados ao grupo de volumes. Apesar da Figura 4 mostrar
na camada 2 apenas uma partição tradicional apresentada ao grupo de volumes, um
mesmo disco rígido pode ter mais de uma partição física. O grupo de volumes é o
responsável por fazer todo o agrupamento dos volumes físicos e apresentar o espaço
total disponível aos volumes lógicos, evitando que haja desperdícios de espaços de
28
LVM
/dev/sda /dev/sdb /dev/sdc /dev/sde/dev/sdd
/dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
/dev/sda1 /dev/sdb1 /dev/sdc1 /dev/sdd1 /dev/sde1
vg00
/dev/vg00/data
/mnt/data (XFS) /mnt/backup (Ext3)
/dev/vg00/backup
Espaço nãoAlocado
(1) Discos Rígidos
(2) Partições
(3) Volumes Físicos
(4) Grupo de Volumes
(5) Volumes Lógicos
(6) Sistemas de Arquivos
FIGURA 4: Estrutura das camadas do LVM.
FONTE: Adaptado de Lunes (2011).
armazenamento — o que é muito comum após formatar uma partição pelo método
tradicional com um tamanho indesejado ou caso se mudem as necessidades tempos
após a formatação. No nível dos volumes lógicos acontece o processo de formatação
para o sistema de arquivos desejado (processo que no método tradicional acontece
na camada 2 da Figura 4) e assim chega-se à camada 6 da Figura 4, ou camada de
formatação do sistema de arquivos, a mais conhecida usualmente (LUNES, 2011).
Por fim, as várias características apresentadas no LVM proporcionam à solu-
ção apresentada no trabalho a flexibilidade necessária à administração e manutenção
de armazenamento de dados para que este possa ser considerado altamente dispo-
nível. Somadas as características do AoE, LVM e RAID, tem-se uma estrutura de alta
disponibilidade flexível, com a possível perda de discos físicos sem perda de dados,
substituições de hardware sem interrupção de serviço, cópias de segurança fáceis e
confiáveis e, além do mais, economia de espaço feito por um gerenciamento mais
adequado.
29
3 TRABALHOS RELACIONADOS
Nas próximas seções serão abordados alguns trabalhos que se assemelham
à solução proposta em alguns aspectos. Na seção 3.1 será apresentado o FreeNAS,
uma solução Web que faz compartilhamento NAS e possui algumas características
pontuais de SAN. A seção 3.2 apresenta o Openfiler, uma solução também Web vol-
tada para SAN. Já a seção 3.3 expõe o sistema de arquivos da Google Inc., o Goo-
gleFS (ou Google File System) mostra que é possível soluções de baixo custo serem
implementadas com alta disponibilidade e desempenho. Ao final, é feita uma discus-
são na seção 3.4 comparando as soluções apresentadas com a solução proposta.
3.1 FREENAS
O FreeNAS é um appliance (pacote de software fechado, chamado por muitos
de engessado, que possui como principal característica já vir pré-configurado) desen-
volvido em uma versão customizada do sistema operacional FreeBSD juntamente com
uma interface baseada em Web que possui a finalidade principal de prover um ambi-
ente de compartilhamento de dados NAS (ver subseção 2.1.2) para os usuários finais
(FREENAS IXSYSTEMS, INC., 2012). A Figura 5 mostra uma das telas de gerencia-
mento dos dados no FreeNAS.
Além disto, o FreeNAS possui o compartilhamento de discos ou volumes ex-
clusivamente através do protocolo iSCSI, proporcionando também características de
SAN na sua arquitetura. Deste modo, o FreeNAS pode ser visto como duas cama-
das distintas, a parte SAN de estruturação de discos e conexões, e a parte NAS, que
envolve o compartilhamento de seus recursos com os usuários. Tudo é configurado
através da interface Web que, dentre os recursos que esta ferramenta provê, podem
ser citados (FREENAS IXSYSTEMS, INC., 2012):
• FTP (File Transfer Protocol): possibilita o acesso a arquivos ou a pastas dentro
de um servidor. Não provê acesso criptografado, a menos que seja utilizado o
SFTP, que não está disponível no FreeNAS.
• RSYNC (Remote Synchronization): permite a cópia e sincronismo de diretórios
e arquivos com outros diretórios e arquivos, seja remotamente ou na própria
máquina local.
• SMB/CIFS: protocolo de compartilhamento de arquivos desenvolvido pela Micro-
30
FIGURA 5: Menus e tela de gerenciamento de volumes do FreeNAS.
FONTE: FreeNAS iXsystems, Inc. (2012).
soft e utilizado por máquinas que possuem o sistema operacional Windows (em
todas as versões).
• NFS: semelhante ao SMB/CIFS, mas desenvolvido para ambientes Unix/Linux.
• Thin Provisioning: uma tecnologia recente que permite que o espaço de arma-
zenamento possa ser concedido além do espaço total em disco. A responsabi-
lidade de fazer o gerenciamento de modo que o uso das cotas em excesso não
cause indisponibilidade no serviço é do servidor que armazena os dados.
• Snapshots: tecnologia que permite criar uma fotografia do estado atual do sis-
tema de arquivos, podendo ser utilizada para um recuperação futura.
• RAID: provê recursos de redundância de dados e tolerância a falhas (ver subse-
ção 2.3.1).
Em relação à solução tecnológica proposta, o FreeNAS possui semelhanças
no tratamento das camadas mais baixo nível, mas, diferentemente da solução apre-
sentada neste trabalho, utiliza o protocolo iSCSI na implantação do armazenamento
SAN (apenas compartilhando o disco local, ou DAS, com outras máquinas). No alto
nível (ou nível de compartilhamento com o usuário) não seria possível fazer uma com-
paração mais justa com a solução proposta, visto que este trabalho não se propõe
31
a resolver problemas de compartilhamento em relação a nenhuma tecnologia de alto
nível em específico, mas sim apresentar uma área de storage de alta disponibilidade
em que qualquer tecnologia de alto nível possa tomar proveito.
3.2 OPENFILER
O Openfiler, de modo semelhante ao FreeNAS, é um appliance baseado em
uma interface Web que é capaz de realizar tanto o compartilhamento NAS quanto SAN
dentro do mesmo framework. Além dessa semelhança, o Openfiler é também baseado
numa distribuição Linux modificada, o Fedora. Por fim, o Openfiler agrupa interfaces,
protocolos e softwares open-source de terceiros na entrega de seus recursos.
FIGURA 6: Tela de apresentação de LUNs iSCSI no Openfiler.
FONTE: Openfiler, Inc. (2012).
Dentre os principais recursos suportados pelo Openfiler estão: NFS, SMB/-
CIFS, WebDAV (Web-based Distributed Authoring and Versioning) e FTP — como
protocolos de compartilhamento NAS; iSCSI — como protocolo de armazenamento
32
SAN; NIS, LDAP (com suporte a SMB/CIFS), Active Directory e Hesiod — como di-
retórios de rede para gerenciamento de usuários e grupos; e, por fim, Kerberos 5
— como protocolo de autenticação. Quanto às tecnologias de alta disponibilidade,
o Openfiler é capaz de trabalhar com discos redundantes através de RAID e fazer o
gerenciamento mais flexível e lógico dos discos com o LVM — além dos recursos de
Snapshot do LVM. Vale ressaltar que o Openfiler não realiza thin provisoning (dife-
rentemente do FreeNAS) que permite uma utilização mais econômica dos dados no
disco.
Em relação ao trabalho apresentado, quanto aos protocolos SAN, o Openfiler
trabalha somente com iSCSI, gerando todas as desvantagens já apresentadas. Assim
como no FreeNAS, é perceptível que o Openfiler pode ser comparado a este trabalho
apenas nas camadas mais baixas, ou SAN, visto que o Openfiler apresenta recursos
além do que é objetivo foco deste solução disponibilizar e estudar.
3.3 GOOGLE FILE SYSTEM (GOOGLEFS)
O GoogleFS (Google File System) é um sistema de arquivos desenvolvido
pela empresa Google com a finalidade de resolver as suas altas demandas de acesso
a dados dos mais diversos tipos com o rigor que cada tipo de dados merece. O Goo-
gleFS provê tolerância a falhas e alta disponibilidade em hardware comum e de baixo
custo, juntamente com uma alta performance agregada para grandes quantidades de
usuários. Enquanto compartilha muitas das características dos sistemas de arquivos
distribuídos tradicionais, no GoogleFS, a Google decidiu mudar radicalmente o design
do seu sistema de arquivos, investindo numa análise prévia das cargas de trabalho
dos seus servidores e criando o seu próprio sistema de arquivos para que refletisse
comportamentos coerentes com as suas demandas (GHEMAWAT et al., 2003).
Este sistema de arquivos tem cumprido com êxito as necessidades da em-
presa e é amplamente utilizado na Google como a plataforma de armazenamento para
o processamento de dados utilizados pelos seus serviços, bem como para a pesquisa
e desenvolvimento de tecnologias que necessitam de grandes conjuntos de dados. No
maior aglomerado que comporta o seu sistema de arquivos, em 2003 eram utilizados
centenas de terabytes de armazenamento em milhares de discos dispostos em mais
de mil máquinas, os quais são acessadas simultaneamente por centenas de clientes
(GHEMAWAT et al., 2003).
A Figura 7 mostra a arquitetura do sistema de arquivos. Sumariamente, a apli-
33
Legend:
Data messagesControl messages
Application(file name, chunk index)
(chunk handle,chunk locations)
GFS master
File namespace
/foo/bar
Instructions to chunkserver
Chunkserver state
GFS chunkserverGFS chunkserver(chunk handle, byte range)
chunk data
chunk 2ef0
Linux file system Linux file system
GFS client
FIGURA 7: Arquitetura do GFS.
FONTE: Ghemawat et al. (2003).
cação cliente conecta através do GFS client ao GFS master ; o master, conhecendo
onde as réplicas de dados mais acessíveis no momento se encontram nos chunckser-
vers, responde ao GFS client que fez a solicitação inicial. Tudo isto acontece de forma
transparente à aplicação final que acessa somente o GFS client. Toda essa abor-
dagem proposta pela Google possui muitas vantagens como altíssima performance,
redundância de dados e alta disponibilidade. Detalhes mais complexos de sua imple-
mentação podem ser encontrados em Ghemawat et al. (2003).
3.4 DISCUSSÃO
Muitas características e vantagens específicas podem ser vistas nos sistemas
e soluções apresentadas neste capítulo. No geral, todas as soluções possuem recur-
sos que seriam interessantes para esta proposta e outros que seriam descartados ou
por fugirem do escopo, ou por não serem compatíveis com a solução desejada.
O FreeNAS possui muitos recursos além do que se necessitaria para se utilizar
na solução, sendo a maior parte deles, de acordo com a Figura 8, na camada acima da
máquina initiator — que fazem o compartilhamento com os usuários finais. Recursos
esses que poderiam ser implementados em cima da solução proposta neste trabalho
posteriormente, o que não é objetivo de implantação desta solução, mas fazer uma
área de armazenamento de dados com alta disponibilidade de acesso a uma grande
quantidade de discos remotos. Para o FreeNAS funcionar de modo semelhante a uma
SAN com iSCSI como proposto neste trabalho, seria necessário, de acordo com a
Figura 8, instalar uma réplica do FreeNAS em cada máquina target, o que geraria um
overhead desnecessário (FREENAS IXSYSTEMS, INC., 2012), além de utilizar um
34
protocolo custoso em desempenho, diante de pouca memória, como o iSCSI (ROCHA;
SANTOS, 2012).
Conforme já apresentado, o Openfiler trabalha apenas com iSCSI, possuindo
também a desvantagem do overhead TCP/IP e não tendo um desempenho esperado
diante de pouca memória para cache. Assim como no FreeNAS, o Openfiler possui
semelhança com esta solução apenas nas camadas mais baixas, ou SAN, e apre-
senta recursos além do escopo deste trabalho, gerando demandas de processamento
e configuração desnecessárias. Outra desvantagem desse tipo abordagem é que, ao
se utilizar appliances, tem-se uma tecnologia fechada, sobre a qual não se tem domí-
nio sem a utilização das suas próprias ferramentas de administração. Já na solução
tecnológica proposta, tem-se acesso direto e de baixo nível às ferramentas e utilitários
que configuram diretamente os dispositivos, podendo se fazer tuning (melhorias de
configuração) facilmente, além de garantir a abertura do projeto para ampliações de
pesquisas futuras na âmbito da faculdade.
A Tabela 1 faz uma breve comparação entre algumas características do Free-
NAS e do Openfiler em relação à solução proposta — chamado de CDSBCADU.
TABELA 1 – COMPARAÇÃO ENTRE TRABALHOS CORRELATOSFreeNAS OpenFiler CDSADU
Baseado em software livre Sim Sim SimÉ uma SAN completa Não Sim SimEvita overhead TCP Não Não SimAlta disponibilidade em RAID Sim Sim SimDinamicamente expansível com LVM Não Sim SimBaixo consumo de memória Não Não Sim
FONTE: O autor (2012).
O GoogleFS, exposto na seção 3.3, não foi apresentado na Tabela por não fa-
zer uma comparação direta com esta solução, até porque a solução da Google é uma
solução proprietária, não possuindo implementações disponíveis para testes, mas foi
apresentado por reforçar o potencial que pode ser encontrado na utilização de solu-
ções em baixo custo de hardware juntamente com soluções em software livre.
35
4 METODOLOGIA DA PESQUISA
Neste capítulo serão apresentados aspectos relacionados aos métodos utili-
zados no processo de pesquisa deste trabalho. A seção 4.1 define em que natureza
a pesquisa se enquadra dentre as naturezas de pesquisa propostas para o curso de
sistemas de informação da Unibrasil e a seção 4.2 mostrará os tipos de pesquisa
escolhidos para a utilização no decorrer deste trabalho.
De modo geral, este trabalho consiste num estudo sistematizado de ferramen-
tas e soluções existentes seguido da aplicação das mais adequadas com a validação
e avaliação final do conjunto estudado apresentando seus resultados.
4.1 NATUREZA DA PESQUISA
A linha de estudo denominada Redes de Computadores desenvolve pesqui-
sas nas subáreas de serviços de comunicação multimídia (voz e vídeo), transmissão
de dados em alta velocidade, redes de alta velocidade, redes sem-fio, redes móveis,
segurança em redes, protocolos de comunicação, sistemas cliente-servidor, sistemas
para dispositivos móveis e embarcados, sistemas para Internet e ambientes para en-
sino a distância. Na área de Sistemas Distribuídos são desenvolvidas pesquisas nas
subáreas de arquitetura, gerenciamento de aplicações distribuídas, mecanismos de
tolerância a falhas, monitoramento, algoritmos paralelos e distribuídos, sendo estuda-
das as tecnologias que possibilitam o desenvolvimento de novos tipos de aplicações
para Internet. Destas linhas de pesquisa, as áreas específicas que serão aplicadas
neste trabalho são (JESUS; TONO, 2010):
• Protocolos de Comunicação;
• Arquitetura de Clusters e Servidores;
• Sistemas Distribuídos;
• Alta Disponibilidade.
4.2 TIPO DE PESQUISA
Quanto aos fins, o tipo de pesquisa realizado neste trabalho é aplicada, pois
é motivada pela necessidade de resolver problemas concretos e possui uma finali-
36
dade prática, que é criar uma área de compartilhamento de dados num ambiente real
(JESUS; TONO, 2010).
Quanto aos meios, a pesquisa é bibliográfica, pois realiza um estudo sistema-
tizado desenvolvido com material publicado em livros, revistas e materiais científicos
de acesso amplo, sejam estes por meio físico ou digital (JESUS; TONO, 2010).
37
5 SOLUÇÃO PROPOSTA
Existem muitas soluções de armazenamento disponíveis no mercado assim
como na comunidade de software livre. Para soluções gerais e onde se há recursos
computacionais disponíveis as soluções exibidas são facilmente utilizáveis e atendem
grande parte dos casos de utilização mais comuns. Porém, quando se necessita de
uma solução barata e mais específica, as soluções apresentadas trazem uma série de
limitações, como licenciamento, utilização de recursos computacionais demasiados ou
mesmo limitações em características de configuração que dê abertura a trabalhos
futuros. Esta solução tecnológica funciona independente de licenças de software,
com a utilização mínima de recursos computacionais, além de dar abertura para a
continuação de trabalhos que, ou expandam a estrutura mostrada ou façam uso da
estrutura como recurso.
Na seção 5.1 serão apresentadas as tecnologias que dão funcionamento à
solução assim como a justificativa do porquê são utilizadas. Na seção 5.2 será exibida
uma visão geral sobre o trabalho que será melhor detalhada na seção 5.3.
5.1 FERRAMENTAS UTILIZADAS
Para prover a solução desejada, foi utilizado um conjunto de ferramentas e
implementações de protocolos. Esses protocolos e ferramentas assim como as suas
justificativas serão descritas nas próximas subseções.
5.1.1 AOE TOOLS E VBLADE
O protocolo ATA over Ethernet (AoE) é utilizado na comunicação entre os
dispositivos de armazenamento de dados, ou discos rígidos. Como este é o núcleo
principal desta solução tecnológica, foi explanado em mais detalhes na seção 2.2.1. O
AoE tools é o único conjunto de ferramentas implementadas e disponibilizadas de ge-
renciamento do protocolo AoE as quais possibilitam executar comandos e manipular
discos na máquina initiator que são exportados pela máquina target através do sub-
conjunto de ferramentas Virtual EtherDrive blade AoE target (vBlade) (CORAID, INC,
2012).
A partir de experimentos realizados por Rocha e Santos (2012), notou-se que
o protocolo AoE possui um desempenho global 9% melhor que o iSCSI e o iSCSI
38
apresenta cerca de 9% de aumento na vazão em workloads de escrita predominante
e desempenho muito próximo ao AoE em workloads de leitura (próximo a 1% no caso
do webserver ), caso haja memória suficiente para cache, porém com um overhead de
19%. Apesar disso, o AoE é a melhor opção para workloads que evitam o mecanismo
de cache do sistema operacional, como bancos de dados. Ademais, o protocolo iSCSI
é menos eficiente em termos de CPU e utilização de rede sob qualquer workload. Por
conta das limitações de memória e processamento presentes em máquinas reaprovei-
tadas e de baixo custo, conclui-se que o protocolo AoE é a melhor opção de escolha
para esta solução tecnológica.
5.1.2 LINUX DEBIAN
O Linux Debian, ou simplesmente Debian, é o sistema operacional que será
utilizado tanto nas máquinas initiator quando nas máquinas target, uma vez que o
Debian é uma distribuição não comercial livre (gratuita e de código fonte aberto) do
GNU/Linux (amplamente utilizada). O Debian tornou-se bastante conhecido por causa
do seu sistema de gestão de pacotes, chamado APT, que permite: atualizações mais
fáceis a partir de versões realmente antigas; instalações quase sem esforço de novos
pacotes; remoções limpas dos pacotes antigos e atualizações mais seguras dos pa-
cotes nas máquinas, visto que os pacotes são obtidos do repositório oficial (DEBIAN,
INC., 2011).
Atualmente há uma versão estável do Debian versão 6.0, denominado Sque-
eze, que será a versão utilizada nesta solução tecnológica. O Debian Stable procura
sempre manter os pacotes mais estáveis, ou seja, alguns pacotes acabam sendo mais
antigos, porém isso garante a estabilidade do sistema, item este que é o grande foco
para aplicação em servidores. Por conta da estabilidade e facilidade de uso do De-
bian, muitas distribuições comerciais se baseiam no Debian, incluindo: Linspire (antigo
Lindows), Xandros, Knoppix, Kurumin, BrDesktop e Ubuntu. Esforços têm sido feitos
para portar o Debian para outros núcleos livres além do Linux, incluindo o Hurd e o
BSD (DEBIAN, INC., 2011).
Dentre as distribuições existentes, muitas versões Linux poderiam ser utiliza-
das, mas o Debian torna-se indispensável por conta da sua estabilidade de funciona-
mento — o que garante para um sistema de grande porte e altamente disponível que
não serão feitas alterações tão frequentemente e, quando feitas, serão apenas sobre
versões de software estáveis que não trarão grande impacto ao funcionamento. Outra
grande vantagem na utilização do Debian para a solução é seu sistema de empacota-
39
mento, pois permite a fácil instalação das ferramentas necessárias para implantação,
além do que é livremente disponibilizado para download e utilização, sendo frequen-
temente manutenido por toda a comunidade de software livre.
5.1.3 LOGICAL VOLUME MANAGER (LVM)
A ferramenta LVM é open source, de livre uso e vem empacotada na distri-
buição do sistema operacional Debian que será utilizada neste trabalho — a versão
Squeeze (DEBIAN, INC., 2011; LEWIS, 2006). Essa ferramenta é essencial para que
seja possível fazer o gerenciamento lógico dos discos com as características propos-
tas na seção 2.3.2. Mais detalhes sobre a tecnologia LVM foram explanados na seção
2.3.2.
5.1.4 MDADM
O MDADM, assim como o LVM, é também uma ferramenta open source e
de livre uso que já acompanha o Debian Squeeze na sua lista de pacotes. Com o
MDADM pode-se criar dispositivos virtuais derivados de dois ou mais dispositivos de
bloco (como disco rígidos), podendo esses dispositivos virtuais serem vistos como
um dispositivo físico qualquer e podendo ser formatados com um sistema de arquivos
ou apresentados ao LVM. O Debian Squeeze juntamente com o MDADM possuem
suporte para RAID nível 0, 1, 4, 5 e 6; visto que, como o MDADM é implementado
apenas em software, não é possível fazer sincronia dos discos para tornar possível o
RAID nível 2 e 3 (maiores detalhes sobre essa limitação podem ser encontrados na
seção 2.3.1). Como apenas o RAID nível 5 será utilizado nesta solução, o MDADM é
suficiente na sua implementação existente (LINUX DIE, 2012).
A importância do MDADM neste trabalho se dá por conta da sua relevância
para a implementação da solução RAID descrita na seção 2.3.1, proporcionando o
cumprimento dos requisitos de alta disponibilidade e performance.
5.2 TOPOLOGIA GERAL DA SOLUÇÃO
A topologia geral da solução provê uma visão ampla do trabalho proposto de
modo a facilitar o entendimento de como as partes envolvidas na solução se integram
na formação do todo.
40
Máquina Initiator
Máquinas target
Rede da Unibrasil
(a)
(b)
(c)
(d)
FIGURA 8: Arquitetura da Solução: (a) arrays de discos com RAID5; (b) máquinastargets; e (c) switch intermediário entre a máquina initiator e target ; (d) uma máquinainitiator.
FONTE: O autor (2012).
Uma visão mais detalhada de cada parte e de como foi configurada será apre-
sentada na seção 5.3. Cada array de discos é formado por um aglomerado de discos
baratos que são conectados logicamente através de RAID5, o que aumenta a perfor-
mance de leitura e garante a integridade dos dados caso se perca até um dos discos.
Sobre este conjunto de discos, a máquina target utiliza o LVM, facilitando o gerencia-
mento dos discos que são apresentados à máquina initiator através do protocolo AoE.
Incremento e decremento de espaço e acréscimo de outros arrays de disco no mesmo
volume lógico são exemplos de alguns dos benefícios que podem ser extraídos do LVM
(LEWIS, 2006).
Todas as máquinas, tanto target quanto initiator, são ligadas ao switch layer
2 através de cabos par trançados com conectores RJ-45 em suas pontas formando
uma única rede SAN (tráfego exclusivo de dados). Neste ponto todos os arrays de
discos exportados pelas máquinas target são enxergados pela máquina initiator como
41
apenas um único disco, ficando para as máquinas target a tarefa de gerenciar os dis-
cos individuais. A máquina initiator, ao receber cada dispositivo de bloco dos targets,
monta todos dentro de mais um nível de volume lógico (LVM), dando mais flexibilidade
de manutenção para toda a arquitetura organizacional dos discos. Isto é importante
para facilitar o gerenciamento de toda a solução de storage.
O comportamento de gateway realizado pela máquina initiator faz o interface-
amento entre a camada de armazenamento e a apresentação para o usuário. Além
disso, é responsável por toda a lógica de acesso aos dados e políticas de permissões
de acesso aos usuários finais.
Por fim, as camadas acima da máquina initiator mostradas na Figura 8 repre-
sentam a atual rede da UniBrasil, o que significa que todos os usuários que utilizam
a rede e possuam permissões de acesso aos arquivos no gateway possam fazer uso
da solução para compartilhar seus dados. Caso houvesse um redirecionamento no
firewall (ou gateway ) da faculdade para além da rede interna, os usuários poderiam
ter acesso a essa infraestrutura através da Internet.
5.3 DESCRIÇÃO DETALHADA DA SOLUÇÃO
Nesta seção serão apresentadas em detalhes as principais estruturas da so-
lução. A subseção 5.3.1 descreve como estão configurados os hosts que exportam
os discos do storage e o porquê dos parâmetros de configuração estabelecidos. A
subseção 5.3.2 descreve como o host intermediário (ou gateway ) faz uso do protocolo
SAN para montar os dispositivos e fornecer o espaço em disco desejado. Já a sub-
seção 5.3.3 mostra os caminhos e interfaces de como os clientes podem fazer uso da
solução proposta.
5.3.1 HOSTS (TARGET )
Um host target representa, a exemplo da parte inferior da Figura 8, o conjunto
de uma máquina AoE-target juntamente com os seus discos internos, os quais formam
um único nó da estrutura da solução. O particionamento dos discos deste nó segue o
modelo apresentado na seção 5.3.1.1, adotado para todos os host target que utilizam
o formato padrão de particionamento, que será apresentado na próxima subseção.
Para os casos onde algum dos discos possuía tamanho diferente dos demais, um
modelo especial de particionamento é apresentado na subseção 5.3.1.2.
42
Os modelos descritos referem-se ao modo com que discos rígidos dos hosts
precisaram ser repartidos (ou particionados) a fim de cumprirem as restrições exis-
tentes trazendo a maior quantidade de benefícios possíveis com as ferramentas já
descritas. Como restrição, no contexto da Unibrasil, puderam ser utilizados na mai-
oria discos rígidos Integrated Drive Electronics (IDE) com no máximo quatro discos
por host. Isso acontece porque nas placas-mãe das máquinas utilizadas, é possível
conectar apenas duas interfaces IDE, sendo que cada uma delas admite somente dois
discos, um master (mestre) e outro como slave (escravo), o que resulta em um limite
de quatro discos por máquina.
Para configurar os discos mestre e escravo é necessário fazer um jumpea-
mento informando ao Basic Input/Output System (BIOS — Sistema Básico de Entrada
e Saída) que existe mais de um disco rígido conectado às portas IDE.
(a) Jumpers (b) Interface IDE
(c) Cabo flat IDE (d) Disco rígido
FIGURA 9: Componentes de interconexão de um conjunto IDE.
FONTE: (a) USB Now (2009), (b) Shuttle (2008), (c) Seagate (2012), (d) Escolas Moimenta(2009).
A Figura 9 exibe os componentes envolvidos na interconexão de um disposi-
tivo IDE, desde a placa-mãe até o disco rígido. A Figura 9(a) mostra como pode ser
configurado o jumpeamento para um modelo de disco específico — isso pode variar
43
dependendo do modelo, mas normalmente os tipos de configuração vêm anexados à
parte externa do próprio disco rígido. A Figura 9(b) mostra uma interface IDE integrada
à placa-mãe — essa interface é conectada à ponte sul do chipset (parte da placa-mãe
responsável pelos dispositivos de entrada e saída). A Figura 9(c) apresenta um cabo
flat com suas três extremidades — uma delas é ligada na interface IDE da placa-mãe
e as demais são ligadas nas interfaces IDE dos discos mestre e escravo. Já a Figura
9(d) apresenta um disco rígido IDE semelhante aos que serão utilizados nesta solução
— a parte inferior contém a interface IDE, os jumpers e a entrada de alimentação de
energia.
Os principais benefícios dos modelos de particionamento adotados sobre as
restrições apresentadas concentram-se no não desperdício do espaço em disco, já
que discos mais antigos têm, no geral, a capacidade de armazenamento reduzida.
Caso, por exemplo, um ou mais discos rígidos tenham maior capacidade de arma-
zenamento do que os demais, a sua capacidade poderá ser aproveitada no arma-
zenamento de dados de sistemas que podem ser mais voláteis, ou que não exijam
replicação, conforme será apresentado na subseção 5.3.1.2.
5.3.1.1 MODELO PADRÃO DE PARTICIONAMENTO
O modelo padrão de particionamento refere-se ao modo como os vários dis-
cos dos hosts target estão divididos considerando-se que todos os discos possuam a
mesma capacidade de armazenamento. Conforme já apresentado na seção 2.3.1, o
RAID nível 5 considera o menor disco do conjunto RAID como padrão para os demais,
caso, por exemplo, fosse utilizado um disco de 40GB e outros três discos de 80GB,
seriam considerados como quatro discos de 40GB, havendo um desperdício de ar-
mazenamento. Esta seção trata dos aspectos técnicos do modelo de particionamento
adotado quando todos os discos possuem a mesma capacidade e de forma natural
não acontece o desperdício. Aspectos práticos de como se chegar a esse modelo de
particionamento a partir do momento da instalação do SO Debian será apresentado
na seção A.1.
Conforme pode ser observado na Figura 10, o modelo está dividido em sete
camadas. A camada (1) define os dispositivos físicos dos discos rígidos conectados,
ou seja, é a representação do próprio disco rígido. A partir do momento que um dispo-
sitivo de armazenamento é reconhecido através do seu driver, este passa a aparecer
para o SO conforme é mostrado na figura. A nomenclatura segue o padrão /dev/sd[a-
d], o que significa que cada dispositivo tem a sua letra correspondente indo de “a” até
44
partição para raid100MB
sda1 sda2
/dev/sda(1)
(2)
(3)
(4)
partição para raid100MBbackup
sdd1 sdd2
/dev/sdd
(...)*
raid5 (somente particões de raid)
Logical Volume Manager
/boot
(5)
(6) /root (3GB) /dev/vg01raid5/lvhost1 (restante)
AoE export
/dev/etherd/e1.1
(7)
FIGURA 10: Modelo padrão de particionamento de disco no host target. *Indica queexistem mais dois discos intermediários com a mesma configuração RAID do último.
FONTE: O autor (2012).
“d” e assim representando os quatro discos de cada host na solução. A configuração
de qual letra será direcionada para qual disco é estabelecida conforme apresentado
na Tabela 2 para os casos onde se tem apenas quatro discos IDE.
A camada (2) determina quem são as partições de cada disco da camada (1),
assim, quando um disco é particionado pelo modelo da camada (2), é especificado
de qual é setor1 inicial e qual o setor final dessa partição dentro do disco rígido, ou
seja, é uma representação contígua de um pedaço do disco rígido. Do mesmo modo
da camada (1), a camada (2) segue um padrão de nomenclatura de números, assim,
visto que a letra representa o disco, o número representa a partição seguindo a ordem
sequencial (no geral é utilizada a ordem sequencial, mas outra ordem também pode
1Os discos rígidos são fisicamente divididos em setores, normalmente cada um possui 512 Bytes(MORIMOTO, 2007).
TABELA 2 – LETRA/PORTA/JUMPERLETRA PORTA IDE JUMPER/dev/sda Primária Master/dev/sdb Primária Slave/dev/sdc Secundária Master/dev/sdd Secundária Slave
FONTE: O autor (2012)
45
ser manualmente estabelecida).
Para a solução proposta, visando um maior aproveitamento do espaço com
a manutenção da salvaguarda dos dados, cada disco foi dividido em duas partições,
sendo elas: /dev/sda1 e /dev/sda2. Conforme pode ser visto na camada (3), a pri-
meira partição possui 100MB e é destinada à partição /boot (ou de inicialização) do
SO Debian. Também pode ser observado que, apesar de ser necessária apenas uma
partição de boot, foram destinadas partições nos outros três discos de cada host,
/dev/sd[b-d]1, destinando-se a cópias de segurança da partição de boot padrão e
dando a garantia de que, caso se perca o disco que inicializa o SO, este poderá ser
restaurado pelas demais cópias da partição um de algum dos outros três discos. Uma
cópia do Master Boot Record (MBR) também é feita em um arquivo dentro do /boot
nos outros três discos. A partições /dev/sd[a-d]2 possuem o espaço de armazena-
mento restante do disco e são destinadas à instalação do RAID nível 5 buscando-se
o aproveitamento máximo do espaço alocado e, deste modo, é nessas partições onde
ficarão dispostos os dados de alta disponibilidade.
A camada (4) destina-se ao acoplamento das partições /dev/sd[a-d]2 em um
único volume RAID nível 5. Por exemplo, caso se utilizassem quatro discos de 40 GB,
seriam destinados 120 GB (3 x 40 GB) para armazenamento e 40 GB para a paridade
dos dados. Isso não significa que um disco foi fisicamente reservado para a paridade,
mas que a quantidade de espaço equivalente a um disco será usada para paridade,
pois no RAID5 a paridade encontra-se distribuída por todo o array de discos.
A abstração das três camadas LVM (volumes físicos, grupos de volumes e vo-
lumes lógicos) são sintetizados na camada (5) da Figura 10. Como todas as partições
destinadas a armazenamento (/dev/sd[a-d]2) são reunidas em um único dispositivo
de RAID, esta etapa contará apenas com este dispositivo como volume físico. Este
único volume físico será também o único apresentado ao grupo de volumes. Apesar
dessa abordagem parecer criar uma camada desnecessária, torna-se importante para
um bom gerenciamento dos dispositivos que encontram-se em camadas inferiores ou
superiores. Detalhes de configurações como nomes e divisões desses volumes são
apresentados no Apêndice A.
Acima da camada LVM vêm as partições que serão montadas e vistas pelo
sistema operacional, conforme apresentadas na camada (6). A partição boot, à qual
foram destinados 100 MB, foi instalada fora do RAID e do LVM, visto que os seus
dados podem ser recriados pelas cópias de segurança das mesmas partições nos ou-
tros discos. Apesar do carregador de sistema operacional GRand Unified Bootloader
46
2 (GRUB) do Debian Squeeze poder ser carregado sobre o LVM (FREE SOFTWARE
FOUNDATION, 2012), neste projeto optou-se pela prática mais tradicional, que é man-
ter a inicialização em uma partição padrão.
A partição “/ ” (ou root) é o local onde será instalado o sistema operacional.
A ela são destinados 3 GB. Esta partição pode ter facilmente o seu tamanho aumen-
tado, pois encontra-se disposta sobre o LVM. A partição swap (ou área de troca) é
responsável pela área de armazenamento em disco que complementa a memória fí-
sica no sistema operacional e onde as páginas de memória menos importantes são
armazenadas após escalonadas, portanto, apesar de volátil, constitui uma área de
armazenamento importante e também é organizada sobre o LVM.
A última partição, apresentada na Figura 10 como um dispositivo, abrange
todo o espaço de armazenamento restante e constitui a partição que será exportada
pelo protocolo AoE. Constitui também a parte mais importante do projeto, pois destina-
se ao armazenamento distribuído e em cluster. A nomenclatura apresentada reflete o
grupo de volume vg01raid5 (indicando que é o primeiro grupo de volumes da máquina
e está em redundância de RAID) e o volume lógico lv1Rhost1 (lv – indicado o primeiro
volume lógico, R – redundância de dados, host1 – host em que se encontra).
Por fim, o volume redundante é exportado remotamente através do protocolo
AoE para a máquina gateway, conforme pode ser visto na camada (7). Neste ponto,
mais uma vez o dispositivo adota outro padrão de nomenclatura, mas que será visto
conforme apresentado apenas pela máquina gateway. Para a exportação é necessário
serem especificados dois números que o AoE identifica como shelf (ou gaveta) e slot
(ou disco). Esses números serão utilizados neste projeto para identificar a máquina de
origem (pelo shelf ) e o volume que esta máquina exporta (pelo slot). Após exportado,
o disco será enxergado pelo gateway no formato /etc/etherd/e1.1, com os números
representando a máquina target e o volume, respectivamente.
5.3.1.2 MODELO ESPECIAL DE PARTICIONAMENTO
O modelo especial de particionamento diz respeito ao caso onde um ou mais
discos que farão parte do array RAID possui o tamanho diferente dos demais. Por
exemplo, caso um array formado por quatro discos tenha três discos com 80 GB e
um disco com 120 GB de capacidade, seriam utilizados apenas 80 GB do disco com
maior capacidade, ficando os 40 GB restantes entregues desnecessariamente para o
RAID.
47
Tal desperdício deixa de acontecer no modelo especial de particionamento
apresentado na Figura 11. Este modelo assemelha-se ao apresentado na subseção
5.3.1.1 em todas as camadas, com exceção da camada (3), onde mais uma partição
é criada (neste caso sdd3) e apresentada diretamente ao LVM.
partição para raid100MB
sda1 sda2
/dev/sda(1)
(2)
(3)
(4)
partição para raid
sdd1 sdd2
/dev/sdd
(...)*
raid5 (somente particões de raid)
Logical Volume Manager
/boot
(5)
(6) /root (3GB) /dev/vg01raid5/lv1Rhost1
AoE export
100MBbackup
espaço não utilizado pelo raid
/dev/vg01/lv1Nhost1
AoE export
sdd3
/dev/etherd/e1.1 /dev/etherd/e1.2
(7)
FIGURA 11: Modelo especial de particionamento de disco no host target. *Indica queexistem mais dois discos intermediários com a mesma configuração RAID do último.
FONTE: O autor (2012).
O padrão de nomes de volumes adotado para este modelo de particionamento
também é diferenciado. Os grupos de volumes não recebem o sufixo raid5 (como
é o caso de vg01raid5), mas apenas seguem o padrão vg[numero]. O volume ló-
gico também realiza uma alteração na letra intermediária R (que indica redundância)
do modelo padrão, passando para N (indicando não redundância). Tanto para gru-
pos de volume quanto para volumes lógicos a numeração inicia em um, pois isso
identifica o número do volume dentro do seu tipo, redundante ou não redundante.
Na camada (7) a máquina gateway identificará pela nomenclatura o segundo volume
(/dev/etherd/e1.2) como o volume não redundante.
Deste modo, é realizado o devido aproveitamento do espaço em disco, o
qual poderá ser utilizado para armazenamento de dados que não exijam redundância,
como caches de serviços de proxies, repositórios de distribuições e software livres.
48
5.3.2 GATEWAY (INITIATOR)
Os discos exportados pelas máquinas target não possuem qualquer centrali-
zação, gerenciamento ou otimização na distribuição de requisições quando o objetivo
é o aumento na performance, isso quando vistos pela ótica do usuário do storage,
mas, diferente disso, são vistos em separado. A máquina initiator, também chamada
de gateway nesta solução, possibilita o acesso centralizado aos dados, facilita o ge-
renciamento, e realiza a distribuição adequada e o aumento da performance das re-
quisições. Além disso, faz o tratamento correto dos dados que serão armazenados
nos hosts target tornando toda lógica de armazenamento transparente ao usuário da
solução.
(1) Clientes
(2) Gateway(ou initiator)
(3) Targets
40GB 40GB 40GB 40GB
vgclusterRvgclusterN
lv-email lv-samba
160 GB
FIGURA 12: Funcionamento sumarizado da máquina gateway. Dividida em três par-tes: (1) como os clientes visualizam o gateway, (2) como o gateway administra osvolumes e (3) como os targets são vistos pelo gateway.
FONTE: O autor (2012).
A Figura 12 apresenta uma visão inicial do funcionamento do gateway, abs-
traindo os detalhes do target já expostos na seção 5.3.1 assim como a camada de
49
interface com os clientes. As linhas tracejadas mais escuras indicam conexões realiza-
das através da rede, ao passo que as linhas sólidas indicam processos e tratamentos
internos dentro da máquina gateway.
Conforme é possível observar, os discos exportados pelas máquinas target
são percebidos pela máquina initiator como discos locais, portanto, no exemplo da
Figura 12, são exportados quatro discos de 40 GB por quatro targets diferentes para
a máquina initiator que, por sua vez, enxerga-os como discos locais. Sobre esses
discos é realizado um agrupamento através do LVM que, ao final, visualiza tudo como
um único grupo de volumes de 120 GB.
O agrupamento LVM, ou grupo de volumes, é formado pela junção dos discos
exportados através do protocolo AoE por meio do conjunto de ferramentas AoEto-
ols. Os dispositivos /dev/etherd/e[1-4].1 exportados pelos targets, conforme já visto
na seção anterior, formam o grupo de volumes vgclusterR (com o R indicando que o
array possui redundância nos targets) o qual armazenará dados que são indispensá-
veis. Um segundo grupo de volumes, o vgclusterN, também será criado no gateway
para armazenamento de dados menos críticos, neste caso o N indica que não ha-
verá redundância de dados; este grupo de volumes será criado com os dispositivos
/dev/etherd/e[1-4].2 exportados pelo target.
Acima dos grupos de volumes podem ser criados volumes lógicos para o ar-
mazenamento dos dados dos clientes da solução. A Figura 12 mostra como exem-
plo dois volumes lógicos, lv-email e lv-samba, representando, respectivamente, um
volume para armazenamento de e-mails e outro para compartilhamento de arquivos
entre máquinas Windows e Linux. No entanto, sobre os 120 GB do grupo de volumes
representados na Figura 12 podem ser criados volumes lógicos para qualquer fina-
lidade e, além disso, cada volume pode ser formatado com um sistema de arquivos
específico e possuir parâmetros de configuração individuais.
Sobre os volumes lógicos há dois pontos importantes a serem ressaltados: (a)
facilidade de gerenciamento e (b) direcionamento e distribuição das requisições entre
os nós do cluster. A respeito do primeiro ponto, este é considerado o ponto mais forte
da utilização de LVM, pois permite a alocação dinâmica do espaço em disco, o que
gera um melhor aproveitamento do espaço disponível e permite aumentar e diminuir
o seu tamanho sem a necessidade de parada. O segundo ponto possibilita que as
requisições feitas ao gateway sejam balanceadas e distribuídas a todos os nós do
cluster, isso aumenta a performance e evita que apenas um target sofra sobrecarga.
Por padrão, os volumes lógicos devem ser criados com a quantidade de stri-
50
pes (onde as fatias de dados serão espalhadas) igual à de volumes físicos existentes
no grupo de volumes (o que proporciona a melhor distribuição) e com o tamanho de
stripe (fatia de dados) em 512 KB — este valor foi escolhido por ser o tamanho padrão
dos chunks (porção mínima de dados em RAID) adotados por padrão nos targets.
Detalhes de configuração que envolvem a criação dos volumes e distribuição de re-
quisições são tratados no Apêndice B.
Os motivos da escolha de se utilizar diretamente LVM na máquina gateway,
sem um RAID intermediário, são os seguintes:
1. As máquinas target já possuem uma camada de redundância no nível mais baixo
da estrutura, garantindo a salvaguarda dos dados em caso de perda de discos,
dispensando a presença de mais um nível de redundância.
2. A criação de um array RAID5 ou RAID1 é realizada por discos de mesmo tama-
nho, o que num projeto como este é inviável pela variação de tamanhos de discos
de baixo custo entre os targets, assim, a utilização de RAID nessa camada oca-
sionaria a perda desnecessária de espaço, além de dificultar o gerenciamento.
3. Por último, as demandas para as quais o projeto se apresenta possuem taxas de
disponibilidade que permitem seguramente a parada programada de uma má-
quina para a substituição de um disco ou componente defeituoso sem ocasionar
a perda dos dados.
5.3.3 CLIENTES
A interface com o cliente trata das formas possíveis de como os usuários fi-
nais podem fazer uso da solução para os casos aos quais a solução se propõe. Neste
ponto é importante observar que esta solução tecnológica limita-se a prover uma área
de disco para ser utilizada em qualquer serviço, contudo esta seção apresentará exem-
plos de possíveis aplicações que podem integrar-se com a solução, mas que não serão
implantadas neste trabalho.
Conforme pode ser observado na Figura 13, a utilização da solução para usuá-
rios finais pode ser realizada por meio da Internet ou da Intranet da UniBrasil, ficando o
desempenho limitado à largura de banda de cada caso, mas sem afetar a performance
do storage. Os serviços para compartilhamento e armazenamento de dados ficam ar-
mazenados no servidor gateway, os quais fazem a interface de armazenamento com
o storage e tornam a complexidade envolvida no cluster transparente ao usuário.
51
Internet
...
Gateway
Servidor Web
Servidor de E-mails
Servidor de Arquivos
Bancos de Dados
...
Clientes
Intranet
FIGURA 13: Interface do usuário com exemplos de aplicações que podem ser dispo-nibilizadas com a solução proposta.
FONTE: O autor (2012).
Caso se deseje desonerar o servidor gateway, uma opção de configuração é
exportar espaços em disco por NAS para servidores externos e exclusivos para os ser-
viços apresentados na Figura 13, os quais ficarão responsáveis pelo processamento
e memória, com o armazenamento sendo realizado por servidor de arquivos remoto.
52
6 VALIDAÇÃO E AVALIAÇÃO DA SOLUÇÃO PROPOSTA
Este capítulo apresentada os resultados de testes realizados sobre a solução
proposta, objetivando validá-la e avaliar o seu desempenho, com vistas à utilização
em cenários reais. A seção 6.1 explica o ambiente em que foram realizados os testes
assim como os tipos de testes adotados, a seção 6.2 trata da vazão de disco alcan-
çada em diferentes workloads, a seção 6.4 verifica o impacto da utilização de rede em
cada cenário e a seção 6.3 analisa questões quanto ao uso de CPU em cada situação
de uso.
6.1 AMBIENTE E METODOLOGIA DE TESTES
Com o objetivo de testar o desempenho da solução de armazenamento re-
moto, foi montado um ambiente contendo cinco servidores. Quatro servidores são
targets e um initiator, todos possuem o sistema operacional Debian 6.0. O Quadro 1
apresenta as características técnicas desses servidores.
# 2 TARGETsProcessador: AMD Duron 900 MHzMemória RAM: 512 MB de memória RAMDiscos: 4 / 7.500 rpm IDE / 400 GB / RAID nível 5Rede: 1 interface Ethernet 100Mbps
# 1 TARGETProcessador: AMD Duron 900 MHzMemória RAM: 512 MBDiscos: 4 / 7.500 rpm IDE / 40 GB / RAID nível 5Rede: 1 interface Ethernet 100Mbps
# 1 TARGETProcessador: Intel Pentium E2140 1.6 GHzMemória RAM: 1 GBDiscos: 2 / 7.500 rpm IDE / 400 GB; 1 / 7.500 rpm IDE / 40 GB; 1 /
7.500 rpm SATA / 80 G; todos em RAID nível 5Rede: 1 interface Ethernet 100Mbps
# GATEWAYProcessador: Intel Pentium E2140 1.6 GHzMemória RAM: 1 GBDiscos: 1 / 7.500 rpm SATA / 80 GRede: 3 interfaces Ethernet 100Mbps; 1 para uplink e
2 agregadas para tráfego exclusivo SAN.
QUADRO 1 – Descrição do ambiente de testes.FONTE: O autor (2012).
Foi executado um conjunto de macrobenchmarks sobre o mesmo ambiente
53
de testes. Os macrobenchmarks têm o objetivo de medir o desempenho de diferentes
configurações do sistema em workloads muito próximos dos encontrados em ambi-
entes reais. Tais workloads, embora sintéticos, simulam os workloads encontrados
em sistemas como servidores Web, servidores de arquivos, servidores de e-mail e
bancos de dados transacionais, por exemplo. Além disso, alguns parâmetros como a
quantidade de discos participantes na distribuição dos stripes e testes locais e remo-
tos foram comparados, visando verificar a influência na vazão de disco alcançada em
cada cenário. A partir desses resultados, será analisada a eficiência da solução em
cada uma das situações, bem como o impacto das configurações escolhidas para uso
no desempenho geral do sistema.
Após apresentar os resultados obtidos pelos macrobenchmarks, uma análise
em termos de vazão, utilização de CPU e de rede é mostrada, relacionando-os com os
obtidos. Por fim, uma discussão sobre os resultados encontrados é apresentada, enu-
merando algumas observações importantes sobre os desempenhos apresentados.
Foi utilizada a ferramenta de benchmarks filebench por ser amplamente uti-
lizada e por conter diversos workloads pré-definidos, simulando o padrão real de
acesso em servidores com diferentes finalidades. De acordo com Filebench (2011),
os workloads pré-definidos utilizados neste experimento são descritos abaixo.
Fileserver: Emula o funcionamento de um servidor de arquivos. O workload
consiste em uma sequência de operações de criação, exclusão, escrita, leitura e ope-
rações sobre meta-dados em um conjunto de 10.000 arquivos, com tamanho de, em
média, 128 KB.
Webserver: Simula o padrão de acesso de um servidor Web. O workload,
predominantemente de leitura, executa um conjunto de operações do tipo open-read-
close em diferentes arquivos de 16 KB, contando com um total de 50.000 arquivos.
Além disso, há um fluxo de operações do tipo append que simula a escrita em arquivos
de log.
Varmail: Simula a atividade de I/O de um servidor de e-mails que armazena
cada mensagem como um arquivo individual. O workload consiste em uma sequência
de operações do tipo create-append-sync, read-append-sync, leitura e exclusão de
arquivos em um mesmo diretório.
Oltp: Emula o padrão de acesso de um banco de dados transacional. Este
workload testa o desempenho de múltiplas operações aleatórias de leitura e escrita
sensíveis à latência. O padrão de acesso é baseado no banco de dados Oracle 9i.
54
Todos os testes foram executados no mínimo 5 vezes, sendo calculado o des-
vio padrão dos resultados, desprezado-se os resultados que elevassem o desvio em
10% acima da média geral. A fim de se estabelecer uma linha de base da largura
de banda da rede, foi utilizado o iperf (NLANR/DAST, 2008), que resultou uma vazão
média de rede em 94,1 Mbits/s para comunicação de apenas uma interface Ethernet
e 175,1 Mbits/s para a comunicação SAN entre targets e o initiator nas interfaces de
rede agregadas no initiator.
Nas seções seguintes serão apresentados os resultados obtidos através dos
experimentos sob três dimensões: vazão no acesso ao disco local e remoto (subseção
6.2), utilização de CPU (subseção 6.4) e utilização de rede (subseção 6.3).
6.2 VAZÃO DE DISCO
A Figura 14 apresenta os resultados obtidos para a vazão de disco através
de diferentes configurações. No gráfico, o eixo horizontal mostra a execução dos
experimentos no disco local e utilizando o protocolo de armazenamento remoto AoE
em cada workload. Para cada grupo de barras, são apresentadas as execuções para
acesso local em apenas um disco e em todos os discos, através de RAID. Já para o
acesso remoto, foi alterada a quantidade de stripes (ou targets participantes), indo de
um a quatro. O eixo vertical apresenta a vazão obtida em cada experimento.
02468
1012141618
Fileserver Webserver Varmail Oltp
Vaz
ão (
MB
/s)
1 Disco Local4 Discos Locais (RAID5)1 Target
2 Targets3 Targets4 Targets
FIGURA 14: Vazão de disco alcançada por diferentes tipos de workloads em discoslocais e remotos.
FONTE: O autor (2012).
De acordo com uma análise dos gráficos, é possível observar que nos testes
55
remotos, o workload fileserver aumenta a vazão conforme se aumenta a quantidade
de discos disponibilizados para stripe. Isso reflete o comportamento esperado ao se
distribuir a carga de trabalho entre os discos em um cluster, porém, a limitação no
caso apresentado passa a ser a largura de banda da rede em que, caso se aumente
essa largura, a segunda limitação passaria a ser o processamento na distribuição das
requisições. Porém, o resultado observado demonstra a possibilidade de expansão da
vazão enquanto houver recursos para balanceamento dessas demandas.
O mesmo não acontece para os testes locais na maioria dos workloads, de-
vido ao fato de que a utilização massiva de escritas ou leituras por meio do RAID em
software realizado em máquinas menos robustas, como os targets, onde se tem limi-
tações de memória e processamento, faz com o gargalo passe a ser o processamento
para a escrita através do RAID, resultando em testes sem RAID apresentando maior
vazão.
Em workloads que possuem um grande número de threads e operações em
arquivos menores, como webserver, varmail e oltp, somente até um certo limite, é
evidente o crescimento da vazão ao se aumentar a quantidade stripes. No caso do
webserver é possível perceber um crescimento de 70.97% entre um e dois stripes e
uma pequena diminuição, tendendo à estabilização, entre dois e três e entre três e
quatro stripes. Isso significa que após atingir o gargalo de CPU o workload webserver
começa a apresentar perda de desempenho ao se aumentar a distribuição. Já para
os workloads varmail e oltp, onde número de operações executadas chega a ser 10
vezes maior do que o webserver, não foi possível observar um grande ganho a partir
de dois stripes para varmail e em nenhum dos casos para o oltp, tornando necessário
o aumento dos recursos de processamento para que um bom ganho na distribuição
se torne possível.
6.3 UTILIZAÇÃO DE CPU
A Figura 15 apresenta a utilização de CPU em cada caso de teste. O eixo
horizontal apresenta os mesmos grupos de barras do teste anterior; o eixo vertical,
a média do tempo de CPU gasto por cada operação de I/O emitida pelo benchmark.
Quanto menor o tempo de processamento, mais eficiente em termos de CPU é o
resultado apresentado.
Através dos resultados obtidos é possível observar que em todos os casos
de testes locais o consumo de CPU é superior aos testes remotos, em média 4,91%.
56
0
200
400
600
800
1000
Tem
po d
e C
PU
/ O
pera
ção
(µs
cpu
/ op)
1 Disco Local4 Discos Locais (RAID5)1 Target
2 Targets3 Targets4 Targets
3119 4991 5309 5051 1975 2504 3191 2751
Fileserver Webserver Varmail Oltp
FIGURA 15: Tempo de CPU por operação de I/O em diferentes workloads. Quandoindicado no topo das barras o valor correto, foi modificado para melhor visualizaçãodos resultados.
FONTE: O autor (2012).
Isso acontece porque os testes locais foram executados diretamente sobre as máqui-
nas targets e, por elas possuírem menos recursos de memória e processamento, os
resultados servem para desenhar uma linha de base do quanto essas máquinas po-
dem alcançar individualmente contribuindo para a formação do cluster além de dar
subsídios para o aumento da performance em cenários remotos. Assim, conforme se
aumenta o número de máquinas target, diminui-se a quantidade de recursos individu-
ais que cada uma dessas máquinas necessita para trabalhar longe do seu limite.
Ainda sobre os testes locais, é possível observar inversões no consumo de
CPU de um workload para o outro. No fileserver, por possuir uma quantidade massiva
de operações de escrita, realiza a maioria delas em cache, através da política write-
back, jogando para o disco somente em tempo oportuno, isso faz com que, na escrita
em apenas um disco, a utilização de CPU seja mais eficiente, por conta de utilizar
menos memória do que a consumida pelo RAID5, pois, no RAID5 o cálculo dos bits
de paridade nas escritas em conjunto com a escassez de memória conduzem a um
maior consumo de CPU por operação.
O workload webserver, que tem por padrão uma grande quantidade de leitu-
ras em arquivos pequenos e médios, apresenta um consumo equilibrado de CPU, pois
as operações de leituras no RAID5 são mais eficientes do que em apenas um disco
e, por outro lado, as operações de escrita são feitas em um número tão pequeno que
conduzem a esse equilíbrio. O workload varmail possui uma quantidade equilibrada
57
entre escritas e leituras em operações pequenas e aleatórias por todo o disco, as-
sim, o resultado assemelha-se ao webserver com uma pequena melhora em apenas
um disco, por conta deste equilíbrio. No workload oltp predomina a escrita aleatória,
porém a maior parte das operações são realizadas com a flag O_DIRECT, o que eli-
mina as caches e, no equilíbrio com a melhoria do RAID5 nas leituras, conduz a um
resultado equilibrado.
Os testes remotos apresentam comportamentos, no geral, diferentes aos ob-
servados na vazão, ou seja, quanto maior a distribuição, maior é a vazão e pouca é
a influência no consumo de CPU. Isso acontece porque grande parte das operações
são colocadas em cache no gateway e em seguida distribuídas aos targets, que re-
cebem inicialmente em buffer e retornam de imediato, realizando posteriormente as
operações em disco. Isso faz com que a utilização de CPU percebida não varie sig-
nificativamente para testes remotos. No caso do workload oltp, como a maioria das
operações são realizadas com solicitação de escrita direta no disco, apresenta uma
variação diferente dos demais. Baseado nessas observações, é possível afirmar que:
havendo memória suficiente no initiator e nos targets, o consumo de CPU não é deter-
minante na maioria dos workloads, pois a capacidade de buffer/cache é somada entre
todos os nós e as operações serão distribuídas apenas em tempo oportuno.
6.4 UTILIZAÇÃO DE REDE
A Figura 16 apresenta a quantidade total de bytes transmitidos e recebidos
divididos pelo número total de operações realizadas em cada caso de teste. O eixo
horizontal apresenta os mesmos grupos de barras do testes anteriores; o eixo vertical,
o número médio de KBytes por operação realizada pelo benchmark. É importante
notar que, como parte das operações é executada em cache sem utilizar a interface de
rede, o valor apresentado não reflete a quantidade real de rede utilizada por operação;
entretanto, o valor é utilizado como métrica para comparação, na medida em que
reflete a eficiência em termos de rede dos protocolos sob diferentes configurações.
Testes locais não são apresentados por não possuírem influência na utilização de
rede.
Conforme previsto, em todos os casos, quanto maior a quantidade de memória
disponível no cluster, menor é a quantidade de dados trafegados na rede, por conta
da maior quantidade de operações que são executadas em cache local. No workload
fileserver os resultados foram decrescentes com o aumento da quantidade de targets
envolvidos e inversamente proporcionais à vazão alcançada de disco, ou seja, quanto
58
0
10
20
30
40
50
Fileserver Webserver Varmail Oltp
KB
ytes
Tx+
Rx
/ O
pera
ção
(KB
/op)
1 Target 2 Targets 3 Targets 4 Targets
69,68
FIGURA 16: Quantidade de dados trafegados na rede (transmitido + recebido) poroperação. Quando indicado no topo das barras o valor correto, foi modificado paramelhor visualização dos resultados.
FONTE: O autor (2012).
mais se aumentava a quantidade de hosts participantes, menor era a quantidade de
dados trafegados pela rede. Isso acontece porque, com o aumento do número de
hosts, aumenta-se também a área de memória destinada para caches na máquina
gateway, o que diminui o tráfego na rede.
O workload webserver apresentou comportamento semelhante ao fileserver,
porém com um aumento global no tráfego realizado. Isso acontece porque maior parte
das operações do fileserver são de leitura, o que exige a presença do dado solicitado
em, no mínimo, um acesso, podendo ser encontrado em memória nos próximos aces-
sos e, além disso, é limitado ao tamanho da memória. Adicionalmente, o webserver
por ser um workload predominantemente de leituras, deixa de beneficiar-se da política
write-back, a qual reduz o tráfego de rede.
O varmail, por conter um número balanceado de escritas e leituras, reduz seu
tráfego consideravelmente em relação ao webserver por fazer proveito das operações
de escritas em memória. Além disso, a quantidade de operações realizadas pelo
varmail é, em média, 8,65 vezes maior do que o webserver, para uma quantidade
semelhante de dados trafegados. Como a maior parte das operações do varmail são
pequenas e aleatórias, o uso da memória no gateway somado à grande quantidade
de operações leva a um tráfego de rede mais reduzido. O equilíbrio apresentado
acontece por conta de que grande parte das operações aleatórias são realizadas em
59
memória e o número de dados trafegados, em geral, não atingem o limite em memória
e, adicionalmente, a pequena variação notada é resultado da distribuição eventual da
carga do espaço em memória.
No caso do oltp pode ser observado um tráfego ainda mais estabilizado. Neste
workload, diferentemente dos demais, conforme se aumentava o número de targets,
aumentava-se proporcionalmente o número de operações e a taxa de transmissão
e recepção. O motivo de tal comportamento segue o mesmo padrão das seções
anteriores, ou seja, como a maioria das operações são com solicitação de acesso
direto ao disco, o aumento da memória no gateway não influencia na quantidade de
dados trafegados, pois o crescimento acontece proporcionalmente nos parâmetros
que se aplicam a este caso de testes.
60
7 CONCLUSÃO
As demandas por capacidades de armazenamento em servidores de discos
impulsionadas pela virtualização e cloud computing criaram a necessidade de formas
diferentes de alocação desses recursos. Especialmente no caso do acesso a disco, é
imprescindível um bom gerenciamento, alto poder de escalabilidade e performance de
forma que aplicações possam utilizar livremente storages centralizados independen-
temente das demandas solicitadas.
Este trabalho apresentou uma abordagem e realizou a implantação de uma
área de armazenamento de dados em alta disponibilidade que provê o compartilha-
mento de dados entre o corpo docente e discente da faculdade UniBrasil com a utiliza-
ção de ferramentas e implementações de protocolos que são de livre uso juntamente
com a utilização de hardwares considerados obsoletos, dando-os novo significado.
Através dos experimentos foi mostrado que, para a principal aplicação deste
trabalho, que assemelha-se ao workload fileserver, os resultados são de acordo com o
esperado, ou seja, conforme se aumenta o número de hosts na distribuição da carga,
maior é a performance alcançada nos resultados. Apesar de não tão surpreendentes
quanto o fileserver, nos demais workloads também são apresentados bons resultados,
sendo possível potencializar a performance caso se saiba antecipadamente o uso
específico ao qual se aplicará a solução. Além disso, há a garantia de que, caso
se perca algum dos discos, o cluster continuará o seu funcionamento normal com
interrupção apenas do intervalo da substituição, sem perda de dados. Com tudo isso,
este trabalho contribui para um seguro compartilhamento de dados a um nível de
performance excelente dentro da UniBrasil, possibilitando um fácil compartilhamento
de dados entre alunos e professores.
Outro benefício que pode ser extraído desta solução é a possibilidade de im-
plementações de software desenvolvidas no curso de Sistemas de Informação que ne-
cessitam de áreas de armazenamento possam ser hospedadas com a performance,
flexibilidade e espaço necessários como, por exemplo, aplicações para repositórios
de TCCs, pacotes de sistemas operacionais, vídeos utilizados em aula, apostilas e
e-books, sistemas de controles de versão para softwares desenvolvidos pelo curso de
Sistemas de Informação, entre outros.
Contudo, o trabalho apresentado não objetiva fazer o interfaceamento entre o
usuário e o storage, ficando este papel para aplicações e outros tipos de protocolos
existentes ou ainda a serem desenvolvidos. Portanto, este trabalho trata de aspectos
61
na hierarquia de um sistema operacional que vão desde a interface com o hardware
até a entrega de volumes lógicos de alta disponibilidade montados para serem utiliza-
dos por qualquer tipo de aplicação.
Para a continuidade deste trabalho, podem ser realizados mais casos de tes-
tes com o aumento do número de targets, diferentes tipos de distribuições de memó-
ria entre todos os hosts e aumento do número de interfaces de rede agregadas, ou
mesmo a troca por interfaces Gigabit, com isso, a troca de parâmetros como Maximum
Transmission Unit (MTU). Quanto ao protocolo AoE, podem ser realizadas alterações
na sua implementação de modo que permita trabalhar com duas ou mais máquinas
gateway, distribuindo a carga concentrada em apenas uma máquina. Podem também
ser realizadas melhorias em aspectos como monitoramento e correção automática de
erros relacionados aos ativos envolvidos na solução.
Ademais, podem ser realizados experimentos com a utilização de tecnologias
de deduplicação de dados (que permite que blocos de disco não sejam repetidos,
evitando o desperdício de espaço) e thin provisioning (que permite uma alocação de
espaço para uma aplicação além do que ela necessita ou do que se tem disponível
no cluster, fazendo uma alocação dinâmica e inteligente), tecnologias essas que per-
mitem um armazenamento com menor desperdício e que abrem a possibilidade de
armazenamento para grande porte com grandes massas de dados.
62
REFERÊNCIAS
4SHARED.COM. 4shared.com - free file sharing and storage. 2005. Disponível em:<http://www.4shared.com/>. Acesso em: 20 set. 2011.
AIKEN, S. et al. A performance analysis of the iscsi protocol. In: Mass Storage Sys-tems and Technologies, 2003. (MSST 2003). Proceedings. 20th IEEE/11th NASAGoddard Conference on. [S.l.: s.n.], 2003. p. 123 – 134.
BRITTAIN, I. F. D. J. Tomcat - The Definitive Guide. 2. ed. United States of America:O’Reilly Media, Inc., 2008.
CISCO, INC. Cisco MDS 9000 Family 4Port 10Gbps Fi-bre Channel Switching Module. 2012. Disponível em:<http://www.cisco.com/en/US/products/ps6784/index.html>. Acesso em: 21 jul.2012.
CLARK, T. Designing storage area networks: a practical reference for implemen-ting Fibre Channel SANs. Boston, MA, USA: Addison-Wesley Longman PublishingCo., Inc., 1999. ISBN 0-201-61584-3.
CORAID, INC. Fundamentals of Networked Storage. 2008. Disponível em:<http://www.vmworld.com/docs/DOC-1374>. Acesso em: 21 jul. 2012.
CORAID, INC. ATA over Ethernet Tools. 2012. Disponível em:<http://aoetools.sourceforge.net/>. Acesso em: 15 mai. 2012.
CORAID, INC. What is Ethernet SAN & AoE? 2012. Disponível em:<http://www.coraid.com/technology/what_is_aoe>. Acesso em: 21 jul. 2012.
COVINGTON, M. A. An overview of coraid technology and ata-over-ethernet (aoe).Coraid, Inc., 2008. Acesso em: 21 jul. 2012.
DEBIAN, INC. Sobre o Debian. 2011. Disponível em:<http://www.debian.org/intro/about>. Acesso em: 21 jul. 2012.
ESCOLAS MOIMENTA. Disco Rígido. 2009. Disponível em:<http://infoevo.escolasmoimenta.pt/9e01h01>. Acesso em: 11 nov. 2012.
FASHEH, M. OCFS2: The Oracle Clustered File System, Version 2. 2006.Disponível em: <http://oss.oracle.com/projects/ocfs2/dist/documentation/fasheh.pdf>.Acesso em: 8 jun. 2012.
FILEBENCH. 2011. http://sourceforge.net/projects/filebench/. Aces-sado em 13 de Abril, 2012.
FREE SOFTWARE FOUNDATION. GNU GRUB manual. 2012. Disponível em:<https://www.gnu.org/software/grub/manual/grub.html>. Acesso em: 24 out. 2012.
63
FREENAS IXSYSTEMS, INC. FreeNAS 8 Features. 2012. Disponível em:<http://www.freenas.org/features/feature-overview>. Acesso em: 8 jun. 2012.
GEEKNET, INC. SourceForge.net: Find, Create, and Publish Open Source soft-ware for free. 2011. Disponível em: <http://sourceforge.net/>. Acesso em: 20 set.2011.
GHEMAWAT, S.; GOBIOFF, H.; LEUNG, S.-T. The Google file system.New York, NY, USA: ACM, 2003. 29–43 p. ISSN 0163-5980. Disponível em:<http://doi.acm.org/10.1145/1165389.945450>.
HOPKINS, S.; COILE, B. ATA over Ethernet Specification. The Brantley Coile Com-pany, Inc, 2001. Disponível em: <http://support.coraid.com/documents/AoEr11.txt>.
INSIDEHPC, LLC. What is the difference between SCSI and ATA? 2006. Dispo-nível em: <http://insidehpc.com/2006/04/07/what-is-the-difference-between-scsi-and-ata/>. Acesso em: 26 mar. 2012.
JESUS, A. de; TONO, C. C. P. Orientações para Elaboração do Pro-jeto de Pesquisa. Faculdades Integradas do Brasil, 2010. Disponível em:<http://www.unibrasil.com.br/pdf/manual_metodologia_da_pesquisa.pdf>. Acessoem: 25 nov. 2012.
KOVACS, G. UNetbootin. 2012. Disponível em: <http://unetbootin.sourceforge.net/>.Acesso em: 18 out. 2012.
LANDOWSKI, M.; CURRAN, P. F. Aoe storage protocol over mpls network.In: Proceedings of the 2011 IEEE 27th Symposium on Mass StorageSystems and Technologies. Washington, DC, USA: IEEE Computer Soci-ety, 2011. (MSST ’11), p. 1–5. ISBN 978-1-4577-0427-7. Disponível em:<http://dx.doi.org/10.1109/MSST.2011.5937231>.
LEWIS, A. LVM HOWTO. The Linux Documentation Project, 2006. Disponível em:<http://www.tldp.org/HOWTO/LVM-HOWTO/>.
LINUX DIE. mdadm(8) - Linux man page. 2012. Disponível em:<http://linux.die.net/man/8/mdadm>. Acesso em: 13 dez. 2012.
LOBUE, M. T. et al. Surveying today’s most popular storage interfa-ces. Computer, IEEE Computer Society Press, Los Alamitos, CA, USA,v. 35, n. 12, p. 48–55, dez. 2002. ISSN 0018-9162. Disponível em:<http://dx.doi.org/10.1109/MC.2002.1106179>.
LUNES. Instalación de Arch linux con LVM. Matuu, 2011. Disponível em:<http://www.matuu.com.ar/?p=489>. Acesso em: 21 jul. 2012.
MAJSTOR, F. Storage Area Networks Security Protocols and Mechanisms. CiscoInc., abr. 2004. Disponível em: <http://goo.gl/3l9AM>. Acesso em: 15 jun. 2012.
MORIMOTO, C. E. Hardware - O Guia Definitivo. 2nd edi-tion. ed. SULINA, 2007. ISBN 9788599593103. Disponível em:<http://books.google.com.br/books?id=P0ZDbwAACAAJ>.
64
MORIMOTO, C. E. Entendendo o LVM. Hardware.com.br, 2010. Disponível em:<http://www.hardware.com.br/guias/opensuse/lvm.html>. Acesso em: 25 nov. 2012.
NLANR/DAST. Iperf. 2008. Disponível em: <http://iperf.sourceforge.net/>. Acessoem: 11 nov. 2012.
OPENFILER, INC. Openfiler About Us. 2012. Disponível em:<http://www.openfiler.com/about>. Acesso em: 15 jun. 2012.
PATTERSON, D. A.; GIBSON, G. A.; KATZ, R. H. A case for redundant arrays of inex-pensive disks (raid). In: SIGMOD Conference. [S.l.: s.n.], 1988. p. 109–116.
ROCHA, P.; SANTOS, L. Uma análise experimental de desempenho dos protocolosde armazenamento aoe e iscsi. In: CSBC 2012 - SEMISH. [S.l.: s.n.], 2012.
SATRAN, J. et al. Internet Small Computer Systems Interface (iSCSI). IETF, abr.2004. RFC 3720 (Proposed Standard). (Request for Comments, 3720). Updated byRFCs 3980, 4850, 5048. Disponível em: <http://www.ietf.org/rfc/rfc3720.txt>.
SEAGATE. Samsung ATA/IDE drives: Jumper settings. 2012. Disponível em:<http://goo.gl/NTdJy>. Acesso em: 11 nov. 2012.
SHUTTLE. Mainboard AS45GT, AS45GTR. 2008. Disponível em:<http://goo.gl/Em35D>. Acesso em: 11 nov. 2012.
TANENBAUM, A. S. Sistemas Operacionais Modernos. trad. 3 ed. São Paulo: Pear-son, 2010.
USB NOW. Jumper Settings When Using Hard Drive Enclosures. 2009. Disponí-vel em: <http://usbnow.co.uk/articles/2009/07/jumper-settings-when-using-hard-drive-enclosures/>. Acesso em: 11 nov. 2012.
VAGHANI, S. B. Virtual machine file system. SIGOPS Oper. Syst. Rev., ACM, NewYork, NY, USA, v. 44, n. 4, p. 57–70, dez. 2010. ISSN 0163-5980. Disponível em:<http://doi.acm.org/10.1145/1899928.1899935>.
YOUTUBE, LLC. YouTube - Broadcast Yourself. 2011. Disponível em:<http://www.youtube.com/>. Acesso em: 20 set. 2011.
ZHOU, C.; CHUANG, H. A performance analysis of the aoe protocol. In: Proceedingsof the 5th International Conference on Wireless communications, networkingand mobile computing. [S.l.]: IEEE Press, 2009. p. 3938–3941.
65
APÊNDICE A -- INSTALAÇÃO E CONFIGURAÇÃO DA MÁQUINA TARGET
Este Apêndice tem como objetivo explicar passo-a-passo como deve ser reali-
zado o particionamento no modelo padrão e especial na máquina target, assim como
apresentar as configurações necessárias para o seu perfeito funcionamento conforme
os padrões já mostrados no capítulo 5.
Para isso são utilizadas figuras de PrintScreen (imagem de tela capturada)
da instalação do Debian com os parâmetros utilizados. A seção A.1 apresentará o
particionamento no modelo padrão e a seção A.2 no modelo especial, a seção A.3
mostrará como deve ser realizado o backup das partições de boot e a seção A.4
demonstrará como exportar os volumes para o gateway.
A.1 INSTALAÇÃO NO MODELO PADRÃO DE PARTICIONAMENTO
Nesta seção serão apresentadas apenas opções e etapas que são relevantes
para a instalação do Debian nos moldes do projeto, assim, opções como por exemplo
“Idioma de Instalação”, não serão abordadas, ficando a critério de quem faz a instala-
ção escolhê-las conforme convir.
FIGURA 17: Tela de instalação.
A Figura 17 mostra a tela de instalação do Debian a partir de um pendrive
criado através da ferramenta Unetbootin (KOVACS, 2012) — disponível no diretório
66
/pendrive-boot.iso no storage do projeto assim como no CD-ROM entregue junto ao
projeto. Para fazer o deploy da imagem para o pendrive, basta utilizar o seguinte
comando na máquina gateway do cluster ou em qualquer máquina Linux que contenha
a imagem:
dd if= /pendrive-boot.iso of=/dev/sde (considerando-se que o /dev/sde seja
o dispositivo do pendrive para o qual se deseja fazer a cópia).
A opção Expert Install foi escolhida por fornecer uma maior quantidade de
opções durante a instalação.
FIGURA 18: Tela de instalação.
As opções Escolher Idioma/Choose Language e Selecione um layout de
teclado ficam a critério do usuário que fará a instalação. A opção Detectar e montar
CD-ROM, conforme mostra a Figura 18, é de grande importância, pois, como a insta-
lação é feita a partir de um pendrive, o Debian não poderá prosseguir na instalação
sem a especificação do diretório onde o CD-ROM encontra-se montado. Vale ressaltar
que não foi utilizado CD-ROM na instalação por conta de que as quatro portas IDE já
estão sendo usadas pelos discos rígidos, além disso, a instalação através de pendrive
possui uma maior performance.
A Figura 19 deve ser marcada como Não, pois não há necessidade de carre-
gamento dos drivers do CD-ROM. Na Figura 20 deve ser escolhido Sim para que seja
apontada manualmente a localização dos arquivos de instalação.
Para a Figura 21 qualquer uma das opções selecionadas trará o mesmo re-
sultado para a próxima etapa. Por padrão foi selecionado none.
O Debian, por padrão, espera que o CD-ROM esteja acessível no dispositivo
/dev/cdrom, neste caso, como a configuração segue um padrão diferente, deve ser
67
FIGURA 19: Tela de instalação.
FIGURA 20: Tela de instalação.
FIGURA 21: Tela de instalação.
68
feito um apontamento para o diretório /cdrom. Conforme mostrado na Figura 22, é
necessário abrir um terminal para montagem manual do pendrive em /cdrom, para
isso deve-se utilizar ALT+F2.
FIGURA 22: Tela de instalação.
A Figura 23 apresenta os comandos necessários para a montagem do dispo-
sitivo /dev/sda, o qual encontrava-se o pendrive, apontando para o diretório /cdrom.
Após isso, é importante listar o conteúdo com ls /cdrom para atestar que a montagem
ocorreu normalmente. Por fim, deve-se efetuar uma mudança de diretório para /c-
drom com o comando cd /cdrom. Após isso, basta retornar para a tela anterior, inserir
/cdrom na caixa de diálogo e Continuar, conforme apresentado na Figura 24.
FIGURA 23: Tela de instalação.
Após os procedimentos apresentados nas Figuras 23 e 24, é necessário se-
lecionar mais uma vez no menu principal a opção Detectar e montar CD-ROM, neste
69
FIGURA 24: Tela de instalação.
momento esta opção não carregará nenhuma outra janela, isso significa que o dire-
tório de instalação foi apontado corretamente. Após isso, é necessário selecionar a
opção Carregar componentes do instalador a partir do CD, conforme apresentado
na Figura 25.
FIGURA 25: Tela de instalação.
Na Figura 26 é necessário apenas selecionar a opção Continuar sem selecio-
nar nenhuma opção mais específica. Após o carregamento dos componentes básicos
será apresentado um novo conjunto de opções. Das novas opções apresentadas, fica
a critério do usuário que faz a instalação as configurações das seguintes opções: De-
tectar hardware de rede, Configurar rede, Configurar usuários e senhas — nesta
opção é importante que seja definida a senha do usuário root e, por último, a opção
Configurar o relógio.
O passo apresentado na Figura 27 — Detectar discos — consiste em car-
regar os drivers dos dispositivos de disco ainda não detectados e definir as suas in-
70
FIGURA 26: Tela de instalação.
FIGURA 27: Tela de instalação.
71
terfaces de configuração. Nenhuma nova janela de opções será apresentada ao se
selecionar esta opção. Na Figura 28 é apresentada uma das opções mais importantes
no processo de particionamento dos discos — Particionar discos.
FIGURA 28: Tela de instalação.
A partir do passo anterior, inicia-se o processo de particionamento. Na Figura
29 deve ser selecionada a opção de Manual, isso possibilita que o particionamento
seja feito conforme desejado, sem seguir os modelos padrões do Debian.
Na Figura 30, todos os discos rígidos existentes são exibidos. No caso apre-
sentado os discos rígidos seguem na seguinte ordem: sda (pendrive); sdb, sdc, sdd
e sde (discos rígidos do host).
Ao selecionar o primeiro disco (sdb), será exibida uma janela de opções con-
forme a Figura 31. Considerando que os discos nunca foram formatados, será neces-
sário criar uma tabela de partições para cada disco. Ainda conforme a Figura 31, é
necessário selecionar Sim para a criação dessa tabela.
A Figura 32 exibe os tipos de tabelas de partições existentes, sendo necessá-
ria a escolha de uma delas. Para este projeto foi escolhido por padrão o tipo msdos.
Após a criação da tabela de partições, o disco será exibido de acordo com
72
FIGURA 29: Tela de instalação.
FIGURA 30: Tela de instalação.
FIGURA 31: Tela de instalação.
73
FIGURA 32: Tela de instalação.
a Figura 33. O mesmo procedimento deve ser aplicado para todos os demais discos
que farão parte do host.
Ao selecionar o ESPAÇO LIVRE, é possível criar partições no disco corres-
pondente. A Figura 34 mostra a seleção da opção Criar uma nova partição. O
próximo passo é especificar o tamanho desejado para a partição que, conforme apre-
sentado na Figura 35, foram destinados 100MB com a finalidade de ser utilizado na
partição /boot, melhor detalhado na subseção 5.3.1.
Na Figura 36 pode ser escolhido o tipo de partição entre primária e lógica.
As partições primárias são limitadas a quatro, mas, como serão utilizadas no máximo
duas nesta solução, utilizaremos ambas primárias.
No próximo passo, apresentado na Figura 37, é necessário escolher a locali-
zação no disco onde serão criadas as partições. Ambas levarão a opção Início. Isso
quer dizer que todo o espaço do início do disco vazio será aproveitado, não ficando
desperdício. Na segunda partição, que é a de armazenamento, o disco se estenderá
do final da primeira (opção Início) até o final do disco.
A Figura 38 mostra todas as configurações necessárias efetuadas na partição
de /boot. Incluem: tipo da partição (ext4), ponto de montagem (/boot), rótulo (boot)
74
FIGURA 33: Tela de instalação.
FIGURA 34: Tela de instalação.
FIGURA 35: Tela de instalação.
75
FIGURA 36: Tela de instalação.
FIGURA 37: Tela de instalação.
FIGURA 38: Tela de instalação.
76
e flag de inicialização (ligado), sendo esta última uma das opções mais importantes,
pois sem ela o sistema não será inicializado após a instalação.
FIGURA 39: Tela de instalação.
FIGURA 40: Tela de instalação.
A Figura 39 inicia o processo de criação da partição de armazenamento pros-
seguindo na Figura 40 para a sua criação.
Na Figura 41 é especificado o tamanho da partição destinada a armazena-
mento. Neste caso, deve ser deixado o valor padrão que vem estabelecido pelo
processo de instalação, visto que ele apresentará todo o espaço em disco disponível
para a partição de armazenamento.
A Figura 42 escolhe a partição Primária para armazenamento dos dados e
utilização em RAID; e a Figura 43 exibe as opções que devem ser escolhidas para a
77
FIGURA 41: Tela de instalação.
FIGURA 42: Tela de instalação.
FIGURA 43: Tela de instalação.
78
partição RAID.
FIGURA 44: Tela de instalação.
A Figura 44 mostra os passos já vistos anteriormente para a partição de boot,
porém neste caso, como é o segundo disco, as configurações serão semelhantes
com exceção do Rótulo, ao qual será atribuído backup-boot. Nesta partição será
realizado periodicamente um backup da partição de boot do primeiro disco.
FIGURA 45: Tela de instalação.
A Figura 45 apresenta como devem estar configurados todos os discos após
se repetir os passos realizados anteriormente para cada disco.
79
Após concluída a configuração dos discos, é necessário configurar o RAID
com as partições destinadas a armazenamento. Para isso é necessário selecionar a
opção Configurar RAID via software, que conduzirá ao apresentado na Figura 46.
Como as configurações feitas anteriormente foram realizadas apenas em memória,
mas não efetivadas nos discos, esta tela exibe as alterações realizadas e solicita a
efetivação delas. Este passo é necessário para o início da configuração do RAID,
portanto, deve-se selecionar Sim.
FIGURA 46: Tela de instalação.
FIGURA 47: Tela de instalação.
A Figura 47 apresenta a primeira tela de configuração do RAID através da
ferramenta MD (múltiplos dispositivos). Como não há ainda nenhum dispositivo criado,
é necessário criar o primeiro através da opção Criar dispositivo MD.
Na Figura 48 deve ser selecionado o RAID5, dentre os disponíveis. A quanti-
dade de dispositivos pertencentes ao array RAID é configurada conforme apresentado
na Figura 49 que, conforme a quantidade de discos formatados e já explicados na se-
ção 5.3.1.1, devem ser setados para 4 (quatro). Como não há dispositivos reservados
80
FIGURA 48: Tela de instalação.
FIGURA 49: Tela de instalação.
FIGURA 50: Tela de instalação.
81
para hot sparing (disco que assumiria a posição de outro disco que falhasse), a Figura
50 deve ser configurado em 0 (zero).
FIGURA 51: Tela de instalação.
De acordo com a Figura 51, devem ser escolhidos as partições pertencentes
ao array RAID. Como as partições sd[b-e]1 foram destinadas para boot do sistema
operacional, neste passo serão selecionadas as partições criadas para armazena-
mento: sdb2, sdc2, sdd2 e sde2.
FIGURA 52: Tela de instalação.
Neste momento o array RAID encontra-se criado, bastando Finalizar, con-
forme mostrado na Figura 52. O próximo passo é a criação e configuração dos volu-
mes lógicos.
A Figura 53 mostra como os discos e partições devem se apresentar após
a configuração das partições e do RAID. Conforme mostra a mesma Figura, basta
selecionar Configurar o Gerenciador de Volumes Lógicos para iniciar configuração
do LVM.
82
FIGURA 53: Tela de instalação.
FIGURA 54: Tela de instalação.
83
O processo de criação dos grupos de volumes e escolha dos volumes físicos
é iniciado com a escolha da opção Criar grupo de volume, conforme mostrado na
Figura 54. Após isso, de acordo com a Figura 55, é solicitado o nome ao grupo de
volumes com redundância que, conforme a subseção 5.3.1.1, será vg01raid5.
FIGURA 55: Tela de instalação.
FIGURA 56: Tela de instalação.
O próximo passo é informar ao LVM quem serão os volumes físicos que farão
parte deste grupo de volumes, neste caso, o único volume físico pertencente será o
/dev/md0, o qual representa o array RAID (passo apresentado na Figura 56).
Agora é necessário serem criados os volumes lógicos sobre o grupo de vo-
lumes recém criado. Para tanto, deve ser selecionada a opção Criar volume lógico,
mostrada na Figura 57. Após isso, é necessário selecionar o grupo de volumes em
que este volume lógico se hospedará (Figura 58).
O passos seguintes consistem em informar o nome e o tamanho dos volumes
lógicos a serem criado. A Figura 59 apresenta a configuração do nome da partição
root e a Figura 60 o tamanho. Esses passos devem ser repetidos para swap (1GB de
tamanho) e lv01Rhost1 (com o restante do disco). Após isso, caso seja apresentado
conforme a Figura 61 basta finalizar a criação dos volumes lógicos em Finalizar.
84
FIGURA 57: Tela de instalação.
FIGURA 58: Tela de instalação.
FIGURA 59: Tela de instalação.
85
FIGURA 60: Tela de instalação.
FIGURA 61: Tela de instalação.
86
FIGURA 62: Tela de instalação.
Após a configuração completa do LVM, as configurações deverão estar de
acordo com a Figura 62.
Agora é necessário formatar os volumes lógicos seguindo as mesmas telas
já apresentadas para a formatação da partição boot. As Figuras 63 e 64, respectiva-
mente, mostram como devem ficar as configurações de formatação das partições de
boot e swap para o correto funcionamento do sistema operacional. O volume lógico
lv01Rhost1 não precisa ser formatado, pois o device será exportado remotamente e
fará parte de outro conjunto LVM no gateway.
Após isso, basta selecionar a opção Finalizar o particionamento e escrever
as mudanças no disco na tela principal de particionamento (mesma da Figura 45).
Será exibido um alerta conforme apresentado na Figura 65 informando que nenhum
ponto de montagem foi estabelecido para um ou mais sistemas de arquivos (são os
sistemas de backup do boot que serão formatados e sincronizados posteriormente).
Deve ser negada a formatação neste momento, portanto a opção que deve ser seleci-
onada é Não.
Quando questionado se as mudanças devem ser escritas nos discos (Figura
87
FIGURA 63: Tela de instalação.
FIGURA 64: Tela de instalação.
FIGURA 65: Tela de instalação.
88
FIGURA 66: Tela de instalação.
66), deve se selecionar Sim. Após este passo, todas as mudanças efetuadas: partici-
onamento, criação e configuração de RAID e LVM serão concretizadas nos discos.
FIGURA 67: Tela de instalação.
A próxima etapa consiste em instalar o sistema operacional Debian nos vo-
lumes recém criados (Figura 67). Para tanto, devem ser selecionadas as opções
apresentadas nas Figuras 68 e 69 que seleciona a última versão do kernel (núcleo
do sistema operacional) disponível e inclui o pacote com a maioria dos drivers, res-
pectivamente.
A Figura 70 instala o GRUB (software que carrega o sistema na inicialização
do computador) e a 71 questiona em qual disco o GRUB será instalado, neste caso
89
FIGURA 68: Tela de instalação.
FIGURA 69: Tela de instalação.
90
será na partição /dev/sdb, normalmente é na primeira partição de boot do array.
FIGURA 70: Tela de instalação.
FIGURA 71: Tela de instalação.
Por fim, após a instalação do GRUB, será feito um redirecionamento para o
menu principal de instalação. Feito isso, basta selecionar a opção Finalizar a insta-
lação. Pronto, o sistema operacional encontra-se instalado com os discos formatados
no modelo padrão de particionamento.
91
A.2 INSTALAÇÃO NO MODELO ESPECIAL DE PARTICIONAMENTO
Os passos a seguir descrevem o que deve ser feito para particionar os discos
do array de modo em que não haja desperdício de espaço de armazenamento, ali-
nhando os discos pertencentes ao RAID com base no tamanho do menor disco. As
Figuras que se seguem apresentam somente passos que não foram apresentados na
seção A.1, seguindo-se o mesmo padrão nos passos aqui não apresentados.
A Figura 72 apresenta quatro discos com a seguinte formação: três discos
com 21,5 GB e um disco com 32,2 GB. O objetivo dos passos seguintes é mostrarem
como criar o RAID com quatro partições de discos de 21,5 GB, aproveitando os 10 GB
restantes (aproximado).
FIGURA 72: Tela de instalação.
Na Figura 73 foram omitidos os passos para a criação das partições de boot,
pois segue o mesmo padrão da seção anterior.
Portanto, o passo demonstrado nas Figuras 73 e 74 refletem a criação e con-
figuração da partição de armazenamento do disco com espaço diferenciado (neste
caso /dev/sdd).
Ainda conforme a Figura 74, foi separado o espaço de 20 GB para a partição
que alocará o RAID no disco (arredondamento para baixo); isso é necessário para
servir como base de arredondamento das demais partições que pertencerão ao RAID.
Poderia também ser deixado com o mesmo valor da partição de armazenamento dos
92
outros discos, o que causaria uma pequena a perda neste disco se houvesse diferen-
ças.
FIGURA 73: Tela de instalação.
FIGURA 74: Tela de instalação.
A Figura 75 mostra como deve ser configurada a partição RAID do disco di-
ferenciado. Após finalização da configuração, deve ser apresentada uma tela de con-
figuração conforme mostrado na Figura 76 que, conforme mostrado, possui 12,1 GB
sobressalentes ao qual pode ser dado outro destino, porém sem redundância de da-
dos.
Os passos que se seguem (Figuras 78, 79 e 80) criam uma partição no espaço
aproveitado para que seja separado o número da partição primária, porém, ainda não
93
FIGURA 75: Tela de instalação.
FIGURA 76: Tela de instalação.
94
é definido o sistema de arquivo e não há a formatação, visto que o dispositivo será
exportado para o gateway e fará parte de um array RAID.
FIGURA 77: Tela de instalação.
FIGURA 78: Tela de instalação.
FIGURA 79: Tela de instalação.
Por fim, a Figura 80 mostra como deve ficar configurada a partição sobres-
salente, a qual será exportada remotamente para o gateway (passo apresentado na
seção A.4).
As demais configurações e opções de instalação devem seguir os mesmo
modelo apresentado na seção A.1, que tratou do modelo padrão instalação do sistema
operacional e particionamento.
95
FIGURA 80: Tela de instalação.
A.3 BACKUP E RESTAURAÇÃO DA PARTIÇÃO DE BOOT
Nesta seção serão apresentadas as etapas necessárias para realização da
cópia de segurança da partição de boot do Debian assim como a sua restauração.
Para tal, serão utilizados quadros explicativos com comandos comentados assim como
explanações do seu uso e aplicação.
Antes de realizar quaisquer configurações, a máquina que será configurada
deve ter acesso à Internet com permissões para fazer download de pacotes dos re-
positórios do Debian. Após isso, o arquivo /etc/apt/sources.list deve estar de acordo
com o apresentado no Quadro 2.
deb http://ftp.br.debian.org/debian/ squeeze main contribdeb-src http://ftp.br.debian.org/debian/ squeeze main contrib
deb http://security.debian.org/ squeeze/updates main contribdeb-src http://security.debian.org/ squeeze/updates main contrib
deb http://ftp.br.debian.org/debian/ squeeze-updates main contribdeb-src http://ftp.br.debian.org/debian/ squeeze-updates main contrib
QUADRO 2 – Configuração do arquivo /etc/apt/sources.list.FONTE: O autor (2012).
Em seguida, basta executar os comandos apresentados no Quadro 3. As li-
nhas iniciadas com “#” referem-se a comentários e as iniciadas com “$” são comandos
a serem executados. O primeiro comando apresentado faz o download da lista de pa-
cotes disponíveis nos repositórios do Debian e atualiza na máquina local. O segundo
comando instala os pacotes desejados; o primeiro pacote é o rsync, software que será
necessário para a realização da cópia fiel dos arquivos da partição de boot, o segundo
96
é o vim, um editor de textos através do terminal que facilita a edição local e remota –
por Secure Shell (SSH).
# atualiza a lista de pacotes$ apt-get update
# instala o rsync e o vim$ apt-get install rsync vim
QUADRO 3 – Instalação de pacotes.FONTE: O autor (2012).
Os comandos seguintes, apresentados no Quadro 4 realizam o backup efe-
tivamente. Para o caso apresentado, a partição que possui o boot por padrão é a
partição /dev/sda1 montada em /boot e as partições que receberão as cópias serão
/dev/sdd1, /dev/sdd1 e /dev/sdd1. Nos passos apresentados, é realizada a criação
dos diretórios onde serão montadas as partições, a montagem e cópia do /boot para
os dispositivos e, por fim, as partições são desmontadas e os diretórios temporários
removidos. A partir deste ponto, a cópia de segurança encontra-se realizada e pronta
para ser utilizada em caso de necessidade de restauração da inicialização do host.
# cria diretórios para montagem dos backups$ mkdir /mnt/b /mnt/c /mnt/d
# monta dispositivos que guardarão backups$ mount /dev/sdb1 /mnt/b$ mount /dev/sdc1 /mnt/c$ mount /dev/sdd1 /mnt/d
# realiza a cópia de segurança$ rsync -arvp /boot/ /mnt/b$ rsync -arvp /boot/ /mnt/c$ rsync -arvp /boot/ /mnt/d
# desmonta dispositivos$ umount /dev/sdb1 /dev/sdc1 /dev/sdd1
# remove pastas criadas$ rm /mnt/b /mnt/c /mnt/d
QUADRO 4 – Cópia de segurança do boot.FONTE: O autor (2012).
O processo de restauração da partição de boot podem ser executados com o
sistema operacional ativo, caso não tenha sido reiniciado o sistema após problemas no
disco da partição de boot principal. Caso o sistema tenha sido reiniciado por algum
motivo, deve ser utilizado um CD-ROM de instalação/recuperação do Debian, que
deve ocupar a interface IDE do disco defeituoso.
97
Após esses passos, com um terminal já ativo e “enxergando” os dispositivos,
basta executar os dois primeiros comandos do Quadro 5 e modificar uma das linhas
do arquivo /etc/fstab, fazendo-o apontar para a nova partição de boot. O primeiro co-
mando instala o GRUB no setor 0 (zero) do disco, também conhecido como MBR, que
carregará o GRUB na inicialização. O segundo comando realiza verifica os sistemas
instalados e atualiza o GRUB na nova partição. As modificações no /etc/fstab são
necessárias para o correto carregamento do kernel na inicialização.
# instala o GRUB no MBR do device$ grub-install /deb/sdb
# verifica os sistemas existentes a atualiza tabela$ update-grub
# substituir linha abaixo do arquivo /etc/fstabUUID=7c9cd28d-75f5-4b52-9302-b25b208dc6b0 /boot ext4 defaults 0 2
# pela linha da partição com o GRUB instalado/dev/sdb1 /boot ext4 defaults 0 2
QUADRO 5 – Restauração da partição de boot.FONTE: O autor (2012).
Após os passos apresentados, o host pode ser reiniciado normalmente sem
apresentar quaisquer problemas na inicialização.
A.4 EXPORTAÇÃO REMOTA DOS VOLUMES DE DISCO
O último passo a ser realizado consiste em exportar para o gateway os discos
destinados para armazenamento. As explanações seguirão os moldes da seção A.3.
As configurações apresentadas nesta seção requerem, do mesmo modo que na seção
A.3, que os repositórios de pacotes estejam devidamente configurados, para isso,
basta seguir os passos apresentados nos Quadros 2 e 3 (apenas primeiro comando).
O Quadro 6 mostra os passos para a instalação e configuração de export de
volumes redundantes. O primeiro comando apenas instala o pacote vblade-persist,
necessário para a criação de volumes remotos persistentes que são exportados pelo
AoE. O segundo comando configura a exportação conforme se segue: setup - refere-
se ao modo de instalação da configuração do volume; 1 - o nó do cluster que exporta
o volume; 1 - número do volume exportado (neste trabalho 1 = redundante e 2 = não
redundante); eth1 - interface de rede por onde trafegarão os dados; /dev/vg01raid5/
lv1Rhost1 - o volume lógico que está sendo exportado.
98
# instala o pacote vblade-persist$ apt-get install vblade-persist
# exporta volume redundante$ vblade-persist setup 1 1 eth1 /dev/vg01raid5/lv1Rhost1
# configura para subir automaticamente na inicialização$ vblade-persist auto 1 1
QUADRO 6 – Instalação do vblade e export do volume de armazenamento redun-dante.
FONTE: O autor (2012).
Assim como os volumes redundantes, os volumes não redundantes também
devem ser exportados, para tanto seguem os comandos apresentados no Quadro 7.
Como o grupo de volumes não foi criado no momento da instalação deverá ser criado
através do primeiro comando apresentado. O segundo comando cria um volume ló-
gico conforme o padrão do projeto, utilizando todo o espaço disponível no grupo de
volumes. O terceiro e quarto comandos repetem os passos do Quadro anterior, porém
para volumes não redundantes.
# criação do vg01$ vgcreate vg01 /dev/sdd3
# cria volume não redundante com 100% do espaço livre$ lvcreate -n lv1Nhost1 -l 100%FREE vg01
# exporta volume redundante$ vblade-persist setup 1 2 eth1 /dev/vg01/lv1Nhost1
# configura para subir automaticamente na inicialização$ vblade-persist auto 1 2
QUADRO 7 – Export do volume de armazenamento não redundante.FONTE: O autor (2012).
Finalmente, após os comandos apresentados nos Quadros anteriores serem
executados com sucesso, todos os volumes de armazenamento estarão devidamente
exportados e prontos para serem tratados pelo gateway.
99
APÊNDICE B -- INSTALAÇÃO E CONFIGURAÇÃO DO GATEWAY
Neste Apêndice serão apresentados os passos necessários para se ter uma
máquina gateway plenamente configurada, ou seja, recebendo e gerenciando os vo-
lumes exportados pelos targets. Para isso, é requisito que os targets estejam corre-
tamente configurados (Apêndice A). Os passos seguintes necessitam que a máquina
gateway possua o sistema operacional Debian devidamente instalado conforme apre-
sentado na seção A.1, porém com formatação normal e automática do disco (já que
esta máquina possui apenas um disco simples).
Com o Debian instalado, antes de executar qualquer comando de manipulação
de volumes, é preciso instalar os pacotes necessários na solução, conforme o Quadro
8. Os pacotes instalados contêm o conjunto de ferramentas AoETools, para montagem
dos volumes exportados pelos targets; o LVM, para manipulação dos volumes lógicos
e, por fim, o editor de textos vim.
# instalação de pacotes necessários$ apt-get install aoetools lvm2 vim
QUADRO 8 – Instalação de pacotes necessários ao gateway.FONTE: O autor (2012).
# inicializa aoe$ modprobe aoe
# torna o aoe persistente na inicialização$ echo aoe >> /etc/modules
# mostra dispositivos exportados pelos targets$ aoe-stat
QUADRO 9 – Configurações no gateway.FONTE: O autor (2012).
O Quadro 9 mostra os passos para a configuração do AoE. O primeiro co-
mando inicializa o módulo do AoE no kernel após o pacote instalado, a sua execução
já permite a manipulação de volumes. Entretanto, uma reinicialização do sistema exi-
giria uma nova execução deste comando e geraria uma indisponibilidade. Portanto, o
100
segundo comando executado configura o sistema operacional para carregar o módulo
AoE na inicialização do sistema, evitando a indisponibilidade. O terceiro comando
do quadro apenas lista os dispositivos que conseguem ser vistos pelo gateway, isso
possibilita saber se o export feito nos targets ocorreu com sucesso.
O Quadro 10 mostra como devem ser criados os grupos de volumes no cluster.
O primeiro comando executado cria um volum group chamado vgclusterR agregando
os discos redundantes exportados pelos quatro targets. O segundo comando cria o
volum group vgclusterN com o volume não redundante exportado pelo quarto target
do cluster.
# cria grupo de volumes "vgclusterR" com os dispositivos$ vgcreate vgclusterR /dev/etherd/e1.1 /dev/etherd/e2.1 /dev/etherd/e3.1 \
/dev/etherd/e4.1
# cria grupo de volumes "vgclusterN" com os dispositivos$ vgcreate vgclusterN /dev/etherd/e4.2
QUADRO 10 – Criação e manipulação dos grupos de volumes.FONTE: O autor (2012).
Após criados os grupos de volumes, basta criar os volumes lógicos e dar a
eles o use devido. Os comandos apresentados no Quadro 11 criam dois volumes
lógicos, um no volum group redundante e outro não. Os parâmetros utilizados para
a criação são os seguintes: -i significa quantos stripes estão presentes no cluster,
quantas divisões realizar e distribuir; -I é o tamanho do stripe, nesse caso foi utilizado
o mesmo tamanho utilizado no RAID, para não haver redivisões; -n é o nome do
volume lógico; -L é tamanho do novo volume lógico, finalizando com o volum group
em que este volume lógico residirá (vgclusterR).
O segundo comando do Quadro 11 apresenta a criação de um volume lógico
não redundante (criado no vgclusterN). No caso apresentado poderiam ser adotados
parâmetros semelhantes ao caso anterior, mas estes parâmetros só são necessários
caso exista mais de um disco envolvido no grupo de volumes.
# cria volume lógico redundante$ lvcreate -i 4 -I 512k -n lvmail -L 100g vgclusterR
# cria volume lógico não redundante$ lvcreate -n lvcache -L 10g vgclusterN
QUADRO 11 – Criação e manipulação dos volumes lógicos.FONTE: O autor (2012).
Os dispositivos criados, de acordo com o exemplo anterior, podem ser encon-
101
trados nos caminhos /dev/vgclusterR/lvmail e /dev/vgclusterN/lvcache, ou seja /dev/ +
grupo de volumes + / + volume lógico. Segue-se o mesmo padrão outros casos.
102
APÊNDICE C -- COMANDOS ÚTEIS NA MANIPULAÇÃO DO CLUSTER
Este Apêndice tem por objetivo apresentar comandos que não são necessa-
riamente de configuração, mas que podem ser úteis na manipulação do cluster, seja
na substituição de um equipamento ou numa situação de recuperação de desastre.
Serão apresentados dois quadros, um para comandos úteis ao gateway e outro para
os targets.
O Quadro 12 traz uma lista de comandos de manipulação do LVM no gateway.
O primeiro conjunto de comandos permite fazer uma varredura na máquina em que es-
tes comandos são executados à procura de dispositivos e volumes que, por qualquer
que seja o motivo, tenham saído do cluster ou de volumes já existentes que tenham
sidos conectados ao cluster. O segundo comando permite a ativação dos volumes
que estejam nesses dispositivos omissos. O terceiro comando, ao ser executado no
gateway, permite a substituição ou desligamento de um target sem afetar os dados
e a sua utilização no cluster, pois copia todos os dados daquele volume físico para o
espaço disponível em outros volumes físicos e o remove do grupo de volumes.
# fazem uma varredura nos dispositivos e volumes que venham# sumam por qualquer motivo$ pvscan$ vgscan$ lvscan
# reativa todos os volumes caídos$ vgchange -a y
# permite remover um physical volum (pv - ou volume físico)$ vgreduce -a vgclusterR /dev/etherd/e1.1
QUADRO 12 – Lista de comandos úteis no gateway.FONTE: O autor (2012).
O Quadro 13 apresenta comandos úteis nas máquinas target. O primeiro co-
mando traz um extrato na tela do RAID do array /dev/md0, o que permite verificar o
estado de cada disco do array ou se algum processo de rebuild encontra-se em exe-
cução, dentre outras informações. Os dois próximos comandos permitem remover um
103
disco defeituoso ou que deva ser substituído do RAID. O terceiro comando acrescenta
um novo disco ao RAID e inicia automaticamente o processo de rebuild.
# imprime informações importantes do array RAID$ mdadm -D /dev/md0
# remove disco falho$ mdadm /dev/md0 --fail /dev/sdb2$ mdadm /dev/md0 --remove /dev/sdb2
# adiciona novo disco e inicializa o rebuild$ mdadm /dev/md0 --add /dev/sdb2
QUADRO 13 – Lista de comandos úteis no target.FONTE: O autor (2012).
Por fim, com os comandos apresentados é possível ter um bom nível de ma-
nipulação de todos os hosts do cluster com a disponibilidade desejada.
Recommended