Este documento propõe uma solução de armazenamento de dados para a faculdade UniBrasil utilizando tecnologias de compartilhamento de dados de baixo custo e alta disponibilidade. A solução envolve a criação de um cluster de armazenamento com discos configurados em RAID5 e acesso remoto aos dados por meio de protocolos como iSCSI. Testes demonstraram que a solução oferece bom desempenho e escalabilidade para aplicações como servidor de arquivos.

1. FACULDADES INTEGRADAS DO BRASIL - UNIBRASIL
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
LEONARDO ANTÔNIO DOS SANTOS
COMPARTILHAMENTO DE DADOS EM STORAGE DE BAIXO
CUSTO E ALTA DISPONIBILIDADE NA UNIBRASIL
CURITIBA
2012

2. 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 Oliveira
Sencioles
Co-orientador:Me. Pedro Eugênio Rocha
CURITIBA
2012

3. RESUMO
Nos últimos anos as demandas por áreas de armazenamento de dados, sejam em
termos de desempenho, confiabilidade ou tamanho, têm crescido exponencialmente
e de forma desproporcional ao crescimento do processamento e memória. Diante
disso, 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 dados
armazenados em caso de perda de discos e um bom nível de performance por conta
da distribuição entre nós do cluster. Foi também realizado um conjunto de testes
demonstrando o comportamento da solução em cenários próximos aos reais, assim
como parametrizações que podem influenciar os resultados em cada cenário, che-
gando a resultados esperados nos workloads semelhantes à principal aplicação deste
trabalho, 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-se
e ampliar este trabalho.
Palavras-chave: AoE. ATA. Ethernet. Alta Disponibilidade. Armazenamento. Com-
partilhamento de Dados.

4. 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 the
processing 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 guaranteed
data 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 showing
the 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 the
expected 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 how
other work can benefit and yet expand this work.
Keywords: AoE. ATA. Ethernet. High Available. Storage. Data Sharing.

5. 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 paridade
estã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 e
target; (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 em
três partes: (1) como os clientes visualizam o gateway, (2) como
o gateway administra os volumes e (3) como os targets são vistos
pelo gateway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
–FIGURA 13 Interface do usuário com exemplos de aplicações que podem ser
disponibilizadas com a solução proposta. . . . . . . . . . . . . . . . . . . . . . . . . . . 51
–FIGURA 14 Vazão de disco alcançada por diferentes tipos de workloads em
discos 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 modificado
para 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

6. –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

7. –FIGURA 78 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
–FIGURA 79 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
–FIGURA 80 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

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

9. LISTA DE SIGLAS
HD Hard Disk - Disco Rígido
NFS Network File System
SMB Server Message Block
FC Fibre Channel
AoE ATA Over Ethernet
USB Universal Serial Bus
NFS Network File System
FTP File Transfer Protocol
HTTP Hypertext Transfer Protocol
DMA Direct Memory Access
HBAs Host Bus Adapters
LVM Logical Volume Manager
ECC Error Correcting Code
FTP File Transfer Protocol
GoogleFS Google File System
CDSBCADU Compartilhamento de Dados em Storage de Baixo Custo e Alta Dis-
ponibilidade na Unibrasil
vBlade Virtual EtherDrive blade AoE target
IDE Integrated Drive Electronics
MBR Master Boot Record
GRUB GRand Unified Bootloader
MTU Maximum Transmission Unit
SSH Secure Shell

10. LISTA DE ACRÔNIMOS
CIFS Common Internet File System
iSCSI Internet Small Computer System Interface
SAN Storage Area Network
NAS Network Attached Storage
DAS Direct Attached Storage
ATA Advanced Technology Attachment
SCSI Small Computer Systems Interface
LAN Local Area Network
SAS Serial Attached SCSI
SATA Serial ATA
OSI Open Systems Interconnection
RSYNC Remote Synchronization
WebDAV Web-based Distributed Authoring and Versioning
BIOS Basic Input/Output System

11. SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.1 PROBLEMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.2 OBJETIVO GERAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 OBJETIVOS ESPECÍFICOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 JUSTIFICATIVA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2 REVISÃO DE LITERATURA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 MÉTODOS DE CONEXÃO A DISPOSITIVOS DE ARMAZENAMENTO . . . . . 16
2.1.1 Direct Attached Storage (DAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1.2 Network Attached Storage (NAS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.1.3 Storage Area Network (SAN) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.2 PROTOCOLOS PARA COMPARTILHAMENTO DE DISCOS EM SAN . . . . . . . 19
2.2.1 ATA Over Ethernet (AoE) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Internet Small Computer System Interface (iSCSI) . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Fibre Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.3 DESEMPENHO E ALTA DISPONIBILIDADE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.3.1 Redundant Array of Inexpensive Disks (RAID) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.3.2 Logical Volume Manager (LVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.1 FREENAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2 OPENFILER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3 GOOGLE FILE SYSTEM (GOOGLEFS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4 DISCUSSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4 METODOLOGIA DA PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.1 NATUREZA DA PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2 TIPO DE PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
5 SOLUÇÃO PROPOSTA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1 FERRAMENTAS UTILIZADAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 AoE tools e vBlade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.2 Linux Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5.1.3 Logical Volume Manager (LVM) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.1.4 MDADM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.2 TOPOLOGIA GERAL DA SOLUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
5.3 DESCRIÇÃO DETALHADA DA SOLUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1 Hosts (Target) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
5.3.1.1 Modelo Padrão de Particionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
5.3.1.2 Modelo Especial de Particionamento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5.3.2 Gateway (Initiator) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5.3.3 Clientes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 VALIDAÇÃO E AVALIAÇÃO DA SOLUÇÃO PROPOSTA . . . . . . . . . . . . . . . . . . . . 52
6.1 AMBIENTE E METODOLOGIA DE TESTES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 VAZÃO DE DISCO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
6.3 UTILIZAÇÃO DE CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
6.4 UTILIZAÇÃO DE REDE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

12. 7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Apêndice A -- INSTALAÇÃO E CONFIGURAÇÃO DA MÁQUINA TARGET . . . . . 65
A.1 INSTALAÇÃO NO MODELO PADRÃO DE PARTICIONAMENTO . . . . . . . . . . . . 65
A.2 INSTALAÇÃO NO MODELO ESPECIAL DE PARTICIONAMENTO . . . . . . . . . . 91
A.3 BACKUP E RESTAURAÇÃO DA PARTIÇÃO DE BOOT . . . . . . . . . . . . . . . . . . . . . 95
A.4 EXPORTAÇÃO REMOTA DOS VOLUMES DE DISCO . . . . . . . . . . . . . . . . . . . . . . 97
Apêndice B -- INSTALAÇÃO E CONFIGURAÇÃO DO GATEWAY . . . . . . . . . . . . . . 99
Apêndice C -- COMANDOS ÚTEIS NA MANIPULAÇÃO DO CLUSTER . . . . . . . . 102

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

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

15. 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;

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

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

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

19. 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 Arquivos
Diretórios/Arquivos
Compartilhados
NAS
Clientes
(a) Arquitetura padrão NAS
Servidor 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.

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

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

22. 21
Sistema de Arquivos
SCSI
iSCSI
TCP
IPSEC
IP
Ethernet
(a) iSCSI
Sistema de Arquivos
SCSI
FC4: FC Protocol
Interface
FC3: Common
Services
FC2: Framing Flow
Control
FC1: Byte Encoding
FC0: Physical
Interface
(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,

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

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

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

26. 25
Faixa 12
Faixa 1
Faixa 4
Faixa 0
Faixa 13
Faixa 1
Faixa 5
Faixa 1
Faixa 14
Faixa 10
Faixa 6
Faixa 2
Faixa 15
Faixa 11
Faixa 7
Faixa 3
(a) RAID nível 0
(b) RAID nível 1
Bit 1 Bit 2 Bit 3 Bit 4 Bit 5 Bit 6 Bit 7
(c) RAID nível 2
Bit 1 Bit 2 Bit 3 Bit 4 Paridade
(d) RAID nível 3
Faixa 8
Faixa 4
Faixa 0
Faixa 9
Faixa 5
Faixa 1
Faixa 10
Faixa 6
Faixa 2
Faixa 11
Faixa 7
Faixa 3 P0-3
P4-7
P8-11
(e) RAID nível 4
Faixa 12
Faixa 8
Faixa 16
Faixa 9
Faixa 17
Faixa 13
Faixa 18
Faixa 14
Faixa 10
Faixa 19
Faixa 15
Faixa 11
Faixa 4
Faixa 0
Faixa 5
Faixa 1
Faixa 6
Faixa 2 Faixa 3
Faixa 7
P16-19
P12-15
P8-11
P4-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-

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

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

29. 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ão
Alocado
(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.

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

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

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

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

34. 33
Legend:
Data messages
Control 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

35. 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 CORRELATOS
FreeNAS OpenFiler CDSADU
Baseado em software livre Sim Sim Sim
É uma SAN completa Não Sim Sim
Evita overhead TCP Não Não Sim
Alta disponibilidade em RAID Sim Sim Sim
Dinamicamente expansível com LVM Não Sim Sim
Baixo consumo de memória Não Não Sim
FONTE: O autor (2012).
O GoogleFS, exposto na seção 3.3, não foi apresentado na Tabela por não fa-
zer uma comparação direta com esta solução, até porque a solução da Google é uma
solução proprietária, não possuindo implementações disponíveis para testes, mas foi
apresentado por reforçar o potencial que pode ser encontrado na utilização de solu-
ções em baixo custo de hardware juntamente com soluções em software livre.

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

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

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

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

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

41. 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áquinas
targets; e (c) switch intermediário entre a máquina initiator e target; (d) uma máquina
initiator.
FONTE: O autor (2012).
Uma visão mais detalhada de cada parte e de como foi configurada será apre-
sentada na seção 5.3. Cada array de discos é formado por um aglomerado de discos
baratos que são conectados logicamente através de RAID5, o que aumenta a perfor-
mance de leitura e garante a integridade dos dados caso se perca até um dos discos.
Sobre este conjunto de discos, a máquina target utiliza o LVM, facilitando o gerencia-
mento dos discos que são apresentados à máquina initiator através do protocolo AoE.
Incremento e decremento de espaço e acréscimo de outros arrays de disco no mesmo
volume lógico são exemplos de alguns dos benefícios que podem ser extraídos do LVM
(LEWIS, 2006).
Todas as máquinas, tanto target quanto initiator, são ligadas ao switch layer
2 através de cabos par trançados com conectores RJ-45 em suas pontas formando
uma única rede SAN (tráfego exclusivo de dados). Neste ponto todos os arrays de
discos exportados pelas máquinas target são enxergados pela máquina initiator como

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

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

44. 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é

45. 44
partição para raid100MB
sda1 sda2
/dev/sda(1)
(2)
(3)
(4)
partição para raid
100MB
backup
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 que
existem mais dois discos intermediários com a mesma configuração RAID do último.
FONTE: O autor (2012).
“d” e assim representando os quatro discos de cada host na solução. A configuração
de qual letra será direcionada para qual disco é estabelecida conforme apresentado
na Tabela 2 para os casos onde se tem apenas quatro discos IDE.
A camada (2) determina quem são as partições de cada disco da camada (1),
assim, quando um disco é particionado pelo modelo da camada (2), é especificado
de qual é setor1 inicial e qual o setor final dessa partição dentro do disco rígido, ou
seja, é uma representação contígua de um pedaço do disco rígido. Do mesmo modo
da camada (1), a camada (2) segue um padrão de nomenclatura de números, assim,
visto que a letra representa o disco, o número representa a partição seguindo a ordem
sequencial (no geral é utilizada a ordem sequencial, mas outra ordem também pode
1Os discos rígidos são fisicamente divididos em setores, normalmente cada um possui 512 Bytes
(MORIMOTO, 2007).
TABELA 2 – LETRA/PORTA/JUMPER
LETRA 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)

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

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

48. 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
100MB
backup
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 que
existem mais dois discos intermediários com a mesma configuração RAID do último.
FONTE: O autor (2012).
O padrão de nomes de volumes adotado para este modelo de particionamento
também é diferenciado. Os grupos de volumes não recebem o sufixo raid5 (como
é o caso de vg01raid5), mas apenas seguem o padrão vg[numero]. O volume ló-
gico também realiza uma alteração na letra intermediária R (que indica redundância)
do modelo padrão, passando para N (indicando não redundância). Tanto para gru-
pos de volume quanto para volumes lógicos a numeração inicia em um, pois isso
identifica o número do volume dentro do seu tipo, redundante ou não redundante.
Na camada (7) a máquina gateway identificará pela nomenclatura o segundo volume
(/dev/etherd/e1.2) como o volume não redundante.
Deste modo, é realizado o devido aproveitamento do espaço em disco, o
qual poderá ser utilizado para armazenamento de dados que não exijam redundância,
como caches de serviços de proxies, repositórios de distribuições e software livres.

49. 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 os
volumes e (3) como os targets são vistos pelo gateway.
FONTE: O autor (2012).
A Figura 12 apresenta uma visão inicial do funcionamento do gateway, abs-
traindo os detalhes do target já expostos na seção 5.3.1 assim como a camada de