tcc2 (versao final 2)

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




(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 11Faixa 7Faixa 3 P0-3

P4-7P8-11

(e) RAID nível 4

Faixa 12Faixa 8

Faixa 16

Faixa 9

Faixa 17Faixa 13



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


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.


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.


“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.


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.


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.


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.


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


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.


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


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.


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.


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




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.


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.


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


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.


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



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.


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




73


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




75




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.



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




78

partição RAID.


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.


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.



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




81

para hot sparing (disco que assumiria a posição de outro disco que falhasse), a Figura

50 deve ser configurado em 0 (zero).


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.


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



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.



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




85



86


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




88


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.


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



90

será na partição /dev/sdb, normalmente é na primeira partição de boot do array.



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).


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.



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



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.




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


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.


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.

Documents

tcc2 (versao final 2)