FACULDADES INTEGRADAS DO BRASIL - UNIBRASIL
CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
LEONARDO ANTÔNIO DOS SANTOS
COM...
LEONARDO ANTÔNIO DOS SANTOS
COMPARTILHAMENTO DE DADOS EM STORAGE DE BAIXO
CUSTO E ALTA DISPONIBILIDADE NA UNIBRASIL
Trabal...
RESUMO
Nos últimos anos as demandas por áreas de armazenamento de dados, sejam em
termos de desempenho, confiabilidade ou t...
ABSTRACT
In the last years the need for data storage capacity, whether in terms of performance,
reliability or size, have ...
LISTA DE FIGURAS
–FIGURA 1 Servidor NAS e SAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
–FIGURA 28 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
–FIGURA 78 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
LISTA DE QUADROS
–QUADRO 1 Descrição do ambiente de testes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...
LISTA DE SIGLAS
HD Hard Disk - Disco Rígido
NFS Network File System
SMB Server Message Block
FC Fibre Channel
AoE ATA Over...
LISTA DE ACRÔNIMOS
CIFS Common Internet File System
iSCSI Internet Small Computer System Interface
SAN Storage Area Networ...
SUMÁRIO
1 INTRODUÇÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
7 CONCLUSÃO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ...
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...
13
O restante deste capítulo está dividido da seguinte forma: na seção 1.1 será
feita uma explanação dos problemas enfrent...
14
Diante do quadro apresentado, como suprir a necessidade iminente de
uma área de compartilhamento de dados sem onerar ai...
15
3. Implantar uma solução tecnológica que, por meio da utilização das tecnologias
estudadas e avaliadas, seja capaz de e...
16
2 REVISÃO DE LITERATURA
Neste capítulo será apresentada uma visão geral das tecnologias utilizadas
neste trabalho, além...
17
caras e especializadas para este fim, além desse compartilhamento ter desempenho
tipicamente inferior ao de um único dis...
18
2.1.3 STORAGE AREA NETWORK (SAN)
O compartilhamento de discos é mais simples que o de arquivos, porém é bem
menos conhe...
19
2.2 PROTOCOLOS PARA COMPARTILHAMENTO DE DISCOS EM SAN
Para tornar possível o compartilhamento de discos em SAN, são nec...
20
2.2.2 INTERNET SMALL COMPUTER SYSTEM INTERFACE (ISCSI)
O Internet SCSI, ou iSCSI, é um dos mais conhecidos protocolos p...
21
Sistema de Arquivos
SCSI
iSCSI
TCP
IPSEC
IP
Ethernet
(a) iSCSI
Sistema de Arquivos
SCSI
FC4: FC Protocol
Interface
FC3:...
22
scanners e impressoras, o que gera uma sobrecarga de processamento que não é
encontrada no ATA — por este ser compatíve...
23
• Distributed (distribuído): “distribuído” significa que um processo computacional
acontece sobre múltiplos servidores q...
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 5...
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
F...
26
dos para correção de erros (ECC — Error Correcting Code). A grande desvantagem
desse nível de RAID é que os discos deve...
27
teriormente seguido por outras instituições e empresas como HP. Diferente do método
usualmente utilizado de particionam...
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 /...
29
3 TRABALHOS RELACIONADOS
Nas próximas seções serão abordados alguns trabalhos que se assemelham
à solução proposta em a...
30
FIGURA 5: Menus e tela de gerenciamento de volumes do FreeNAS.
FONTE: FreeNAS iXsystems, Inc. (2012).
soft e utilizado ...
31
a resolver problemas de compartilhamento em relação a nenhuma tecnologia de alto
nível em específico, mas sim apresentar...
32
SAN; NIS, LDAP (com suporte a SMB/CIFS), Active Directory e Hesiod — como di-
retórios de rede para gerenciamento de us...
33
Legend:
Data messages
Control messages
Application
(file name, chunk index)
(chunk handle,
chunk locations)
GFS master
...
34
protocolo custoso em desempenho, diante de pouca memória, como o iSCSI (ROCHA;
SANTOS, 2012).
Conforme já apresentado, ...
35
4 METODOLOGIA DA PESQUISA
Neste capítulo serão apresentados aspectos relacionados aos métodos utili-
zados no processo ...
36
dade prática, que é criar uma área de compartilhamento de dados num ambiente real
(JESUS; TONO, 2010).
Quanto aos meios...
37
5 SOLUÇÃO PROPOSTA
Existem muitas soluções de armazenamento disponíveis no mercado assim
como na comunidade de software...
38
apresenta cerca de 9% de aumento na vazão em workloads de escrita predominante
e desempenho muito próximo ao AoE em wor...
39
mento, pois permite a fácil instalação das ferramentas necessárias para implantação,
além do que é livremente disponibi...
40
Máquina Initiator
Máquinas target
Rede da Unibrasil
(a)
(b)
(c)
(d)
FIGURA 8: Arquitetura da Solução: (a) arrays de dis...
41
apenas um único disco, ficando para as máquinas target a tarefa de gerenciar os dis-
cos individuais. A máquina initiato...
42
Os modelos descritos referem-se ao modo com que discos rígidos dos hosts
precisaram ser repartidos (ou particionados) a...
43
dependendo do modelo, mas normalmente os tipos de configuração vêm anexados à
parte externa do próprio disco rígido. A F...
44
partição para raid100MB
sda1 sda2
/dev/sda(1)
(2)
(3)
(4)
partição para raid
100MB
backup
sdd1 sdd2
/dev/sdd
(...)*
rai...
45
ser manualmente estabelecida).
Para a solução proposta, visando um maior aproveitamento do espaço com
a manutenção da s...
46
2 (GRUB) do Debian Squeeze poder ser carregado sobre o LVM (FREE SOFTWARE
FOUNDATION, 2012), neste projeto optou-se pel...
47
Tal desperdício deixa de acontecer no modelo especial de particionamento
apresentado na Figura 11. Este modelo assemelh...
48
5.3.2 GATEWAY (INITIATOR)
Os discos exportados pelas máquinas target não possuem qualquer centrali-
zação, gerenciament...
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
tcc2 (versao final 2)
Próximos SlideShares
Carregando em…5
×

tcc2 (versao final 2)

465 visualizações

Publicada em

0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
465
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
2
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

tcc2 (versao final 2)

  1. 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. 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. 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. 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. 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. 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. 7. –FIGURA 78 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 –FIGURA 79 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94 –FIGURA 80 Tela de instalação. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
  8. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

×