NASCloud SSD e cifra local para dispositivos de Storage na ... · SSD e cifra local para...

NASCloud – CachingSSD e cifra local para dispositivos de Storage na CloudMiguel José Costa Soá LoboDissertação de Mestrado apresentada à

Faculdade de Ciências da Universidade do Porto em

Ciência de Computadores

2014

NA

SC

lou

d–

Ca

ch

ing

SS

D e

cifra

loca

l para

dis

po

sitiv

os d

e S

tora

ge

na C

lou

dM

igu

el J

osé C

osta

So

áL

ob

oM

Sc

FCUP

2014

2.º

CICLO

NASCloud – Caching

SSD e cifra local para

dispositivos de

Storage na CloudMiguel José Costa Soá LoboMestrado Integrado em Engenharia de Redes

e Sistemas InformáticosDepartamento de Ciência dos Computadores

2014

Orientador Manuel Eduardo Correia, Faculdade de Ciências da Universidade do Porto

CoorientadorHugo Ribeiro, Faculdade de Ciências da Universidade do Porto

Todas as correções determinadas

pelo júri, e só essas, foram efetuadas.

O Presidente do Júri,

Porto, ______/______/_________

Miguel Jose Costa Soa Lobo

NASCloud – Caching SSD e cifra localpara dispositivos de Storage na cloud

Departamento de Ciencia de Computadores

Faculdade de Ciencias da Universidade do Porto

27 de Junho de 2014

Miguel Jose Costa Soa Lobo

NASCloud – Caching SSD e cifra localpara dispositivos de Storage na cloud

Relatorio de Estagio submetido a Faculdade de Ciencias da

Universidade do Porto como parte dos requisitos para a obtencao do grau de

Mestre em Engenharia de Redes e Sistemas Informaticos

Orientador: Manuel Eduardo Correia

Co-orientador: Hugo Ribeiro

Departamento de Ciencia de Computadores

Faculdade de Ciencias da Universidade do Porto

27 de Junho de 2014

dedicado as pessoas mais importantes da minha vida

i

Agradecimentos

Ao longo deste estagio houve alguns momentos em que foi essencial um pequeno em-

purrao. Gostaria de agradecer a todos os que me motivaram, ajudaram e que estavam

la no momento certo.

Comeco por agradecer ao orientador de estagio, Manuel Eduardo Correia, pela oportu-

nidade de trabalho proporcionada, o que me permitiu abrir novos horizontes e aprender

mais sobre a area e o trabalho que tanto gosto de fazer.

Um grande e merecido ”Obrigado!”ao meu co-orientador de estagio, Hugo Ribeiro.

Agradeco por toda a ajuda, atencao e disponibilidade dispensada, e pelo conhecimento

que me transmitiu. Considero que foi um elemento essencial para a realizacao deste

projecto e pelo meu enriquecimento profissional, e por isso estou-lhe imensamente grato.

Agradeco a uma boa parte dos professores da Faculdade de Ciencias, principalmente

aos professores do DCC, pelo facto de fazerem parte da minha carreira academica e por

terem contribuıdo para o meu crescimento profissional.

Gostaria de deixar uma agradecimento especial aos meus pais, por me terem sempre

apoiado e motivado durante todo este tempo e proporcionado os meios necessarios a

minha formacao. Nao podia deixar de agradecer a minha irma, que ao longo destes anos

esteve sempre disponıvel para me ouvir e para me dar a forca necessaria.

Agradeco aos meus amigos e colegas que, de uma forma ou outra, estiveram sempre

presentes neste percurso. Gostava de deixar um agradecimento especial ao Carlos

Ferreira, Mario Pinto, Pedro Oliveira, Pedro Ramalho, Goncalo Martins, Ze Carlos e

Luıs Moreira, por toda a amizade, ajuda e companheirismo.

Last but not the least, um agradecimento especial a minha namorada, por estar sempre

ao meu lado, apoiar-me e ajudar-me. Por me fazer feliz. Sem ela nada disto era possıvel

:)

A todos, muito obrigado!

ii

Resumo

A decisao das empresas aderirem a Cloud deve-se principalmente a motivos financeiros.

Estas precisavam de adquirir o seu proprio hardware, cujo valor diminui com o passar do

tempo, e a performance, quando comparada com equipamentos mais recentes, e menor.

Com o aparecimento e uso da Cloud as empresas passaram a pagar aos Cloud Providers

pelos recursos que necessitam/consomem, e deixam de ter necessidade de investir em

equipamento dispendioso.

O acesso ao espaco disponibilizado pelos Cloud Providers normalmente e feito atraves

de Application Programming Interface (API)s proprias. Para que esse espaco seja

disponibilizado aos utilizadores das empresas, de uma forma facil e transparente, e

necessario o uso varias ferramentas/softwares.

O Cloud Storage Gateway (CSG) pretende desempenhar o papel de mediador entre o

fornecedor de espaco na Cloud e os seus utilizadores, atraves de metodos e protocolos

de rede ja conhecidos e com implementacoes robustas.

O objectivo principal deste projecto e a criacao de uma appliance local, que ira acelerar

o acesso ao espaco de armazenamento importado da Cloud, sob a forma de dispositivos

de blocos. Esta appliance e toda baseada em software Open-Source.

A aceleracao e feita atraves do uso de software que providencia mecanismos de cache

local e discos Solid-State Drive (SSD). Juntamente com a aceleracao de dispositivos de

blocos, de modo a se poder garantir a confidencialidade dos dados que sao guardados na

Cloud, os dispositivos de blocos importados serao cifrados localmente, para que assim

desta forma os dados escritos passem sempre cifrados, e de forma transparente para a

Cloud.

iii

Abstract

The main decision that leads companies joining the Cloud in mainly due to financial

reasons. These need to purchase their own hardware, whose value decreases over time,

and its performance, when compared with more recent equipment, is worst. With the

appearance and use of the Cloud, companies started to pay to Cloud Providers for the

resources they need/consume, and they no longer need to invest in expensive equipment.

Access to storage provided by Cloud Providers is usually done through proprietary APIs.

To make this storage available to the companies users, in an easy and transparent way,

it is necessary the use of various tools/software.

The Cloud Storage Gateway (CSG) intends to play the role of mediator between the

Cloud Provider and the enterprise users, through already known methods and network

protocols, with robust implementations.

The main goal of this project is to create a local appliance, which will accelerate the

access to the storage imported from the Cloud in the form of block devices. This

appliance is all based on Open-Source software.

The acceleration is done through the use of software that provide mechanisms for local

cache and Solid-State Drive (SSD) drives. Along with the acceleration of block devices,

so as to be able to guarantee the confidentiality of the data that is stored in the Cloud,

the imported block devices are encrypted locally, so that thus pass the written data

always encrypted and transparently to the Cloud.

iv

oduetnoC

Resumo iii

Abstract iv

iiivsalebaTedatsiL

ixsarugiFedatsiL

3oacudortnI1

1.1 Objectivos do projecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

.............................oirotalerodaruturtsE2.1 5

7sadazilitusaigolonceT/erawtfoS2

2.1 Sistemas de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Polıticas de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.2 Softwares de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.2 Software /ecnamrofrepedesilanaed benchmark . . . . . . . . . . . . . . . 11

2.3 Sistemas de Ficheiros Distribuıdo na Cloud . . . . . . . . . . . . . . . . . 12

2.4 LUKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.5 iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

v

2.6 LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3 Desenvolvimento 20

3.1 Cenarios de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 FIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.3 Software de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.4 Ceph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4.1 Cenario Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3.4.2 Cenario Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

3.5 iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5.1 iSCSI Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

3.5.2 iSCSI Initiator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.6 RAID . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.7 Linux Unified Key Setup (LUKS) . . . . . . . . . . . . . . . . . . . . . . . 38

3.8 Logical Volume Manager (LVM) . . . . . . . . . . . . . . . . . . . . . . . 39

4 Testes e Resultados 41

4.1 Testes de Velocidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.1.1 Caso Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.1.2 [Ceph] → [CSG] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.1.3 [Ceph] → [CSG] → [Cliente] . . . . . . . . . . . . . . . . . . . . . . 46

4.1.4 [Ceph] → [CSG+EIO WB+RAID1+LUKS+LVM] → [CLIENTE] 48

4.2 Testes de Integridade de dados . . . . . . . . . . . . . . . . . . . . . . . . 49

4.2.1 1o Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

4.2.2 2o Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

vi

4.2.3 3o Cenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

5 Conclusoes 55

5.1 Discussao de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

A Script FIO 58

B Script BCache 60

C Script EnhanceIO 62

Referencias 63

vii

Lista de Tabelas

2.1 Header da particao LUKS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2 Composicao de um key-slot . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 Tabela de Estados EnhanceIO . . . . . . . . . . . . . . . . . . . . . . . . . 50

viii

Lista de Figuras

3.1 NASCloud - Caso Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.2 NASCloud - Cenario Base com aceleracao local . . . . . . . . . . . . . . . 22

3.3 NASCloud - Cenario Base com falha na aceleracao local . . . . . . . . . . 22

3.4 NASCloud - Cenario Final . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.5 Diagrama Ceph - cenario virtual . . . . . . . . . . . . . . . . . . . . . . . 28

3.6 Diagrama Ceph - Cluster Ceph+Ceph Client . . . . . . . . . . . . . . . . 31

3.7 Diagrama Ceph - Cluster Ceph+scsi targets utils . . . . . . . . . . . . . . 31

3.8 Diagrama Ceph - Cenario real . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.1 Grafico comparativo caso base . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.2 Grafico comparativo Bloco Ceph vs Bloco Ceph+EnhanceIO WB/WT -

Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44


Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45


Real vs Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

4.5 Grafico comparativo Bloco Cloud vs Bloco Cloud+EnhanceIO WB/WT

- Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.6 Grafico comparativo Bloco Cloud+EIO WB+RAID1+LUKS+LVM - Real

vs Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

ix

Acronimos

API Application Programming Interface

DoS Denial of Service

FIFO First In First Out

FIO Flexible I/O

FTP File Transfer Protocol

GB Giga Bytes

CSG Cloud Storage Gateway

HDD Hard Disk Drive

IaaS Infrastructure as a Service

IOPS I/O Operations per Second

IQN iSCSI Qualified Name

iSCSI Internet SCSI

I/O Input/Output

LRU Least Recently Used

LUKS Linux Unified Key Setup

LV Logical Volume

LVM Logical Volume Manager

MB Mega Bytes

1

2

MDS Metadata Server

MRU Most Recently Used

NFS Network File Systen

PaaS Platform as a Service

PDU Protocol Data Unit

PG Placement Group]

PV Physical Volume

RAID Redundant Array of Independent Disks

RBD RADOS Block Device

R2T Ready to Transfer

SaaS Software as a Service

SO Sistema Operativo

SSD Solid-State Drive

VG Volume Group

WB Write back

WT Write through

Capıtulo 1

Introducao

A decisao das empresas aderirem a Cloud deve-se principalmente a motivos financeiros.

Estas precisavam de adquirir o seu proprio hardware, cujo valor e performance diminuem

com o passar do tempo. Com o aparecimento e uso da Cloud as empresas passaram a

pagar aos Cloud Providers pelos recursos que necessitam/consomem, e deixam de ter

necessidade de investir em equipamento dispendioso [1] [2].

Um Cloud Provider e uma empresa ou entidade que fornece aos seus clientes espaco

de armazenamento e/ou servicos (Infrastructure as a Service (IaaS), Software as a

Service (SaaS) ou Platform as a Service (PaaS)), atraves de uma rede publica (Cloud)

ou privada (Cloud privada) [3].

O acesso ao espaco disponibilizado pelos Cloud Providers normalmente e feito atraves

de APIs! (APIs!) proprias. Para que esse espaco seja disponibilizado aos utilizadores

das empresas, de uma forma facil e transparente, e necessario o uso de varias ferramen-

tas/softwares.

No projecto NASCloud pretende-se definir um Cloud Storage Gateway (CSG), que

desempenhara o papel de mediador entre o fornecedor de espaco na Cloud e os seus

utilizadores, atraves de metodos e protocolos de rede ja conhecidos e com implementacoes

robustas, tais como o Internet SCSI (iSCSI) ou o Fibre Channel, com provas dadas dos

seus bons desempenhos.

Uma das vantagens do uso de um CSG num ambiente empresarial e a possibilidade de ter

multiplos fornecedores de armazenamento na Cloud e nao estar dependente de somente

um. Deste modo e possıvel adicionar mais resiliencia aos dados que serao armazenados

3

CAPITULO 1. INTRODUCAO 4

[2] utilizando redundancia e backups, por exemplo.

O uso da solucao proposta traz vantagens tanto aos fornecedores de espaco na Cloud,

assim como as empresas que os contratam. Os Cloud Storage Providers tem a opor-

tunidade de aumentar o alcance dos seus servicos, enquanto que os clientes finais, que

sao maioritariamente empresas, tiram vantagem das funcionalidades que os Providers

fornecem, tais como [4] [5]:

• Acessibilidade: facilidade de acesso aos dados a partir de qualquer dispositivo/lo-

calizacao;

• Custo: o armazenamento na Cloud permite reduzir os custos associados aos backups

dos dados, ja que deixa de haver necessidade de aquisicao de equipamento para a

funcao, os backups sao feitos directamente para a Cloud ;

• Seguranca e recuperacao de dados: os dados armazenados nos Cloud Providers sao

cifrados quer durante a transmissao entre o cliente e os Providers, quer enquanto

estes estiverem armazenados.

Em caso de perda de dados, a sua recuperacao e facilitada devido aos backups

efectuados pelos Cloud Providers.

O uso de um CSG na estrutura informatica de uma empresa vai permitir que aos seus

utilizadores usufruam das vantagens acima assinaladas, de um modo transparente, sem

necessidade de utilizar directamente software de terceiros (APIs).

1.1 Objectivos do projecto

O objectivo principal do projecto NASCloud e a criacao de uma appliance local, que

vai acelerar o acesso ao espaco de armazenamento importado da Cloud, sob a forma de

dispositivos de blocos, via iSCSI.

Essa aceleracao e feita recorrendo a mecanismos de cache local e discos SSD. Juntamente

com a aceleracao de dispositivos de blocos, de modo a garantir a confidencialidade dos

dados, os dispositivos de blocos serao cifrados localmente, para que desta forma os dados

passem sempre protegidos de forma transparente para a Cloud.

Esta appliance vai executar o papel de CSG, com foco na seguranca dos dados e com

performances apropriadas, a serem utilizadas para aplicacoes e armazenamento na rede.


Um CSG e uma ferramenta de rede que fornece conectividade e servicos de traducao de

protocolos entre um Cloud Storage Provider e aplicacoes locais. A sua implementacao

e feita numa maquina local, para facilitar a implementacao de seguranca dos dados e a

transferencia de dados entre protocolos incompatıveis.

Um CSG e projectado para oferecer interoperabilidade entre diferentes protocolos de

transferencia de dados usados em arquitecturas cliente/servidor. Este permite a traducao

entre APIs dos Cloud Providers que utilizam SOAP ou REST, para protocolos de

dispositivos de blocos, tais como iSCSI ou Fibre Channel [6] [7].

O armazenamento na Cloud e providenciado por um servico Ceph, e esse armazenamento

e exposto via iSCSI para o CSG. A instalacao e configuracao de um cluster Ceph esta

presente nos objectivos do projecto, assim como o estabelecimento de conexoes iSCSI

entre as varias tecnologias utilizadas no projecto.

Outro dos objectivos passa por determinar a aplicacao e localizacao da camada de

encriptacao, fornecida pelo LUKS, para que os dados a serem escritos passem sempre

cifrados para a Cloud. Esta pode ficar localizada entre a Cloud e o CSG, e ser aplicada

directamente sobre os discos iSCSI da Cloud, ou entre o CSG e os seus utilizadores, por

cima do dispositivos de blocos que serve de abstracao a cache local.

De modo a atingir o ponto de equilıbrio e melhor compromisso entre fiabilidade, segu-

ranca dos dados e velocidades de acesso, faz parte dos objectivos do projecto executar

varios testes de benchmark, e ajustar as definicoes e configuracoes de acordo com os

resultados obtidos.

Dos objectivos do projecto fazem ainda parte a testar a reexportacao por iSCSI dos

dispositivos de blocos carregados no CSG, para a rede local, para que desta forma os

computadores clientes possam utilizar o armazenamento na Cloud, devidamente cifrado

e acelerado.

1.2 Estrutura do relatorio

Este relatorio esta composto por cinco capıtulos. No presente capıtulo e feita uma

introducao a varios conceitos importantes que foram abordados ao longo do estagio

efectuado. E tambem feita uma breve descricao da motivacao para realizacao do projecto,

e sao apresentados os objectivos do mesmo.


No Capıtulo 2 e apresentada uma descricao dos softwares e tecnologias utilizadas para

a realizacao e conclusao deste projecto. Sao explicadas as caracterısticas de cada com-

ponente utilizado e o seu modo de funcionamento.

No Capıtulo 3 e demonstrada a interligacao entre os varios elementos utilizados no

projecto (Ceph, iSCSI, softwares de cache), juntamente com os procedimentos e passos

que foram executados para a instalacao e configuracao dos softwares utilizados.

No Capıtulo 4 sao apresentados os testes e respectivos resultados, que foram feitos ao

longo de todo o processo de construcao da appliance. Os testes apresentados sao sobre

a performance de leitura/escrita e sobre a integridade dos dados, em situacao normal de

funcionamento e situacoes de falhas de componentes/conexoes.

Por fim, no Capıtulo 5, sao apresentadas as principais conclusoes do projecto NASCloud

e uma descricao do trabalho futuro/melhoramentos a serem feitos.

Sao tambem apresentados possıveis cenarios onde todo o trabalho efectuado podera ser

aplicado com sucesso.

Capıtulo 2

Software/Tecnologias utilizadas

Neste capıtulo serao apresentados os softwares explorados para a construcao do prototipo

de uma appliance CSG. De referir que todo o software utilizado e gratuito e Open-

Source.

Este capıtulo e composto pela apresentacao aos sistemas de cache, onde e explicado

o que sao, como e o seu funcionamento e quais os softwares decache utilizados no

ambito do projecto. Tambem sao apresentados varios softwares de benchmark a sistemas,

juntamente com a definicao de benchmark e qual a sua funcao.

Outro topico deste capıtulo e relativo ao software Ceph. Aqui e explicado o que e o

Ceph, qual as funcoes que este pode desempenhar e as vantagens que a sua utilizacao

traz.

Desde sempre a seguranca da informacao e um assunto sensıvel e importante. No

topico relativo ao LUKS e apresentado o software escolhido para cifrar os dados a serem

transferidos para a Cloud.

No topico sobre LVM, e explicada o que e, para que serve e quais sao os elementos que

compoe esta ferramenta de gestao de volumes logicos no Linux.

2.1 Sistemas de cache

Entende-se por cache uma localizacao onde armazenar algo temporariamente, de modo

a reduzir o tempo de acesso aparente ao armazenamento principal. Por exemplo, quando

se consulta uma pagina de Internet, os ficheiros descarregados sao guardados no disco

rıgido, numa pasta de cache. Quando mais tarde se retorna a essa pagina consultada,

7

CAPITULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS 8

se a cache ainda estiver valida, o browser utiliza esses ficheiros que foram previamente

descarregados, em vez de fazer um novo pedido ao servidor web, o que se vai traduzir

numa poupanca de tempo e recursos (ex. largura de banda).

Os sistemas informaticos utilizam cache em varios nıveis de operacao. Alguns exemplos

onde o uso de cache e aplicado sao os seguintes [8]:

• Cache de servidores locais, tais como servidores de ficheiros, servidores Web (proxys)

ou servidores de DNS, ;

• Cache do browser de Internet;

• Cache do disco rıgido: onde existem copias dos dados que foram mais recentemente

utilizados, para um posterior acesso mais rapido a estes;

• Memoria RAM: tambem pode ser vista como um dispositivo de cache, onde os

dados estao carregados, para um acesso mais rapido;

• Cache L1 e L2: memorias cache que estao localizadas no mesmo chip que o CPU.

Uma cache e composta por um conjunto de entradas. Cada uma destas entradas contem

dados, que sao copias dos dados existentes no seu local de origem, e tambem uma tag, que

identifica os dados presentes na entrada em questao e a localizacao destes no dispositivo

de armazenamento original.

Quando um cliente da cache precisa de aceder aos dados existentes na localizacao de

armazenamento, primeiro consulta a sua cache, para verificar se os dados em questao

estao la disponıveis. Se for encontrada uma entrada com os dados requisitados, entao

estes sao retornados ao cliente, o que se denomina por ”Cache Hit”. No caso contrario,

em que nao se encontra nenhuma entrada na cache com os dados pedidos, durante o

processo de leitura dos dados para os retornar ao cliente , estes sao entao lidos e copiados

para a cache, para um posterior acesso mais rapido. A esta situacao chama-se ”Cache

Miss”.

2.1.1 Polıticas de cache

Uma polıtica de cache e um conjunto de regras que sao usadas para determinar se um

pedido pode ser satisfeito usando uma copia armazenada em cache do recurso solicitado.

Existem polıticas de substituicao de cache e polıticas de escrita.


Durante o processo de ”Cache Miss”, as entradas da cache vao sendo substituıdas por

novas entradas, de modo a actualizar a cache. A forma utilizada para escolher e substituir

a entrada a ser trocada e conhecida como polıtica de substituicao. Existem varias

polıticas, que seguem algoritmos de substituicao optimizados para a funcao, tais como

First In First Out (FIFO), aleatorio, Most Recently Used (MRU) ou Least Recently

Used (LRU), que normalmente e a mais comum de ser usada.

No momento em que os dados sao escritos na cache, estes tambem tem de ser escritos

no seu local de armazenamento (ex. disco HDD). Esse momento e determinado pela

polıtica de cache que esta ativa no dispositivo. Existem duas polıticas de cache mais

utilizadas [9] [10]:

• Write Back : E um metodo de armazenamento em que os dados sao escritos na

cache sempre que ocorra alguma alteracao, mas sao escritos na sua localizacao

de armazenamento a partir de um determinado intervalo de tempo definido, ou

consoante certas condicoes, tais como quando algum limite de dados presentes na

cache e atingido.

Quando os dados sao escritos na cache, estes sao diferentes dos que estao na

localizacao de armazenamentos dos dados. Quando esse trigger e ativado, os dados

que foram escritos na cache sao replicados para o seu local de armazenamento, o

que vai actualizar a origem.

O uso da polıtica Write Back tem como principal vantagem a optimizacao da

velocidade do sistema, isto porque e muito mais rapido escrever directamente na

cache do que no local de armazenamento. Contudo, aliado a esse aumento de

velocidade tambem existe um maior risco de perda de dados, em caso de crash do

sistema ou qualquer outro motivo adverso. Um metodo de reduzir esse risco de

perda de dados e fazer um mirror da cache. Isto permite que, em caso de falha

do dispositivo de cache, haja outro pronto a ser usado. Na situacao de um crash

do sistema, os softwares de cache tentam recuperar o conteudo do dispositivo de

cache e actualizar o dispositivo de origem no momento do arranque do sistema,

antes de voltarem a desempenhar o seu papel no processo de cache.

• Write Through: Metodo de armazenamento em que os dados sao escritos simulta-

neamente na cache e no local de armazenamento. O uso desta polıtica de cache

permite que os dados requisitados sejam devolvidos mais rapidamente (se estes

tiverem presentes na cache), e tambem garante que nao existe perda de dados,

caso ocorra alguma situacao nao planeada.


Apesar desta polıtica garantir a inexistencia de perda de dados devido a replicacao

destes em duas localizacoes distintas, tal metodo torna o processo mais lento.

Uma operacao de escrita de dados so pode prosseguir quando a anterior estiver

concluıda, e tal so acontece quando houver confirmacao da escrita nos dispositivos

de cache e local de armazenamento.

2.1.2 Softwares de cache

Com o aparecimento das flash drives, o desempenho do armazenamento de dados tornou-

se mais facil e simples de melhorar. Antes desse acontecimento, os metodos utilizados

para melhorar as performances de Input/Output (I/O) de armazenamento passavam por

caches de baixa capacidade para a memoria RAM ou RAM drives [11].

Os tradicionais discos Hard Disk Drive (HDD) fornecem bastante espaco de armaze-

namento (quando comparados com discos SSD), mas o seu desempenho em relacao a

velocidade de acesso e baixo. Os discos SSD permitiram reduzir esses tempos de acesso,

diminuindo em grande parte essa lacuna. A utilizacao simultanea destes dois discos

HDD e SSD permitem tambem criar um sistema hıbrido, que combina o espaco de

armazenamento do HDD com a velocidade do SSD [12].

O papel do SSD neste novo tipo de sistema e de servir como cache aos dados armazenados

no HDD, deixando uma copia dos dados mais usados no SSD, para que o seu acesso seja

mais rapido.

O objectivo do uso de softwares de cache e tornar o Sistema Operativo (SO) e o acesso

aos dados tao rapido como se de um dispositivo SSD se tratasse. Dado um SSD e um

outro dispositivo de armazenamento, o software vai interpor o SSD entre o kernel do

sistema e o dispositivo de armazenamento, e usar o SSD para acelerar as operacoes de

I/O de e para o dispositivo de armazenamento. Desta forma, se um pedido de leitura

de dados puder ser satisfeito pelo SSD, nao ha necessidade de envolver o dispositivo de

armazenamento no processo, o que vai agilizar e acelerar o pedido [13] [14].

No ambito deste projeto, os dois softwares de cache testados e analisados foram o BCache

[15] e o EnhanceIO [16].

Tanto o BCache [15] como o EnhanceIO sao softwares de cache que actuam sobre blocos

de dados, permitindo que um ou mais discos rapidos, tal como discos SSD, facam cache

de outros dispositivos de blocos mais lentos.

As principais diferencas entre os dois softwares analisados sao as seguintes:


• Por defeito, o BCache nao faz cache de I/O sequenciais mas sim aleatorios, que e

o ponto forte dos discos SSD. Ja o EnhanceIO ja faz cache de todos os I/O, sejam

estes sequenciais ou aleatorios [16] [17].

• Para evitar que o dispositivo de armazenamento seja acedido directamente sem

recorrer ao software de cache, o BCache requer o acesso exclusivo ao dispositivo.

Este e formatado com um marcador especial pelo BCache, onde so atraves do uso do

software e possıvel aceder ao seu conteudo, utilizando um dispositivo virtual. Esta

medida de prevencao permite que evitar que o sistema de ficheiros do dispositivo

de armazenamento e os seus dados fiquem corrompidos [13].

• Enquanto que no BCache e necessaria a utilizacao de um dispositivo virtual, tal

facto nao acontece com o EnhanceIO. A principal vantagem deste ponto e que torna

possıvel adicionar cache a qualquer dispositivo sem que seja necessario desmonta-lo

e formata-lo.

2.2 Software de analise de performance/benchmark

Em informatica, benchmark e um teste ou conjunto de testes concebidos para medir e

comparar a performance de um determinado elemento ou componente do computador.

Um benchmark e concebido para imitar um tipo de workload especıfico para um sistema

ou componente. As informacoes mais importantes a retirar dos testes de performance

e benchmark de discos rıgidos sao os tempos de latencia e as velocidades de leitura

e escrita, tanto aleatoria como sequencial (dependendo da situacao a ser testada). A

performance de um sistema e influenciada pelos seguintes factores:

• Velocidade de rotacao do disco rıgido;

• Tamanho do bloco do sistema de ficheiros;

• Tempo de procura;

• Tipo de leitura/escrita (sequencial ou aleatorio);

O software FIO [18] e uma ferramenta que permite gerar pedidos de I/O e e bastante

versatil e flexıvel. Esta ferramenta pode ser usada tanto para benchmark como para

executar stress tests no sistema.

Stress tests sao uma forma de testar a estabilidade do sistema, de uma forma intensa.


Sao feitos para levar o sistema ao extremo das suas capacidades, ate ao seu ponto de

falha. A ideia de conduzir o sistema ate este ponto e para se poder determinar quais os

seus limites e em que ponto e como falham.

Esta ferramenta suporta multiplos motores de I/O, o que permite simular varios tipos

diferentes de input de testes (ex. sıncrono, assıncrono), assim como especificar o numero

de threads ou processos por teste a executar, tipo de teste (leitura e/ou escrita), entre

outros parametros.

O output do FIO e composto por varias informacoes de performance, tais como tempos

de latencia, velocidades maximas, mınimas e medias ou tempo que o processo fica na

fila de espera para ser processado.

O site storagereview.com, sıtio de referencia em comparacoes e analise de estatısticas e

velocidades de discos rıgidos, utiliza o FIO como o seu metodo de benchmarking [19].

Tal como o Flexible I/O (FIO), existem outros softwares semelhantes, como por exemplo

o Bonnie++ [20].

O Bonnie++ e uma ferramenta de benchmark destinada a testar o desempenho de discos

rıgidos e sistema de ficheiros, desenvolvida para sistemas Unix. O Bonnie++ analisa

os desempenhos de velocidade de leitura e escrita de dados, numero de pesquisas por

segundo e o volume de I/O Operations per Second (IOPS).

Outro metodo de analisar a performance de um sistema e atraves da ferramenta dd.

Esta ferramenta permite fazer copias de e para ficheiros e dispositivos. O seu output e

composto pelo numero de blocos transferidos, numero de bytes copiados, o tempo que

demorou a operacao e a velocidade medida.

O principal problema desta ferramenta e que nao e filesystem independent, isto e, o

dd so testa velocidades de acesso ao sistema de ficheiros. Dependendo do sistema de

ficheiros em uso na altura do teste, os resultados podem variar, pois este ao ler o bloco

para copiar, pode carrega-lo na memoria, o que vai originar valores mais rapidos e nao

fidedignos [21].

2.3 Sistemas de Ficheiros Distribuıdo na Cloud

Em computacao Cloud, o armazenamento e considerado um dos problemas mais difıceis

de resolver. O armazenamento na Cloud deve ser facilmente escalavel e de baixo custo.

Contudo deve ser pensado de modo a nao menosprezar a fiabilidade ou velocidade, e

evitar falhas de hardware a medida que o tamanho do cluster aumenta.


Um sistemas de ficheiros distribuıdo na Cloud e um sistema de ficheiros que permite

a varios hosts aceder aos mesmos dados simultaneamente. Esses dados podem estar

divididos em varias partes, que por sua vez sao armazenadas em maquinas distintas, o

que facilita o multiplo acesso aos dados e a execucao paralela de aplicacoes.

De modo a nao comprometer o acesso e a integridade dos dados armazenados, conceitos

como a confidencialidade, disponibilidade e integridade sao essenciais para a definicao

de um sistema informatico seguro.

Hoje em dia, gracas a computacao Cloud, os utilizadores podem partilhar dados a partir

de qualquer dispositivo com uma ligacao a Internet (ex. Smartphone, Tablet, pc). Isto e

possıvel devido a facilidade de escalabilidade de recursos dos servidores de um cluster,

recursos esses que sao virtualizados e disponibilizados dinamicamente.

Os sistemas de ficheiros distribuıdos destacam-se pela forma como lidam com o desem-

penho do cluster, escritas simultaneas de dados, falhas temporarias ou permanentes de

nos ou capacidade de armazenamento no cluster.

O Ceph [22] e uma plataforma de armazenamento concebida para fornecer armazena-

mento de blocos, objectos e ficheiros, a partir de um cluster de computadores.

O seu principal objectivo e ser um sistema completamente distribuıdo, sem um ponto

de falha unico (pois os dados guardados no cluster sao replicados pelos seus elementos,

tornando-o assim tolerante a falhas [23]). E tambem facilmente escalavel, pois o software

Ceph pode ser executado em hardware comum, o que desta forma possibilita baixar os

custos de implementacao [24].

O Ceph pode desempenhar varios papeis na rede. Pode fornecer armazenamento de

objectos ou dispositivos de blocos para plataformas de Cloud, como por exemplo OpenS-

tack, CloudStack ou OpenNebula, ou funcionar como sistema de ficheiros (Ceph Filesys-

tem).

O Ceph Filesystem e um sistema de ficheiros compatıvel com POSIX [25], que usa o

cluster Ceph para armazenar os seus dados.

Um cluster e composto, pelo menos, por um Ceph Monitor e por dois Ceph OSD

daemons. Existe ainda outro elemento que pode pertencer a um cluster, Ceph Metadata

Server, mas esse elemento so e utilizado se o cluster funcionar como Ceph Filesystem

[26].

O Ceph OSD daemon (OSD) armazena dados, e responsavel pela replicacao e recu-

peracao dos dados, rebalanceamento do cluster e providencia informacao de monito-


rizacao aos Ceph Monitors, ao verificar regularmente o estado dos outros OSDs.

O Ceph Monitor (Monitor) mantem mapas do estado do cluster, entre os quais mapas

dos monitores do cluster e mapas dos OSD.

O Ceph Metadata Server (MDS) guarda metadados dos ficheiros quando o Ceph esta

a operar como sistema de ficheiros. O MDS possibilita aos utilizadores do sistema de

ficheiros Ceph executar comandos basicos de procura e listagem de ficheiros sem causar

um grande aumento de carga ao cluster Ceph [26].

O Ceph armazena os dados como objectos dentro de pools de armazenamento. Ao usar o

algoritmo CRUSH [27] [28], o Ceph calcula qual o Placement Group (o Placement Group

junta um conjunto de objectos num grupo, que depois vai ser armazenado em um ou

mais OSD, estando assim os objectos espalhados pelo cluster [29]) que deve conter o

objecto, e tambem calcula qual o OSD que vai armazenar esse Placement Group.

O Gluster [30] e o Ceph, sao sistemas de ficheiros distribuıdos, facilmente escalaveis e

idealizados para serem usados em hardware comum, o que permite baixar os custos de

implementacao e escalabilidade do cluster.

A arquitetura do Gluster agrega varios servicos que podem ser disponibilizados numa

rede informatica. Esses servicos sao armazenamento e capacidade de computacao. Cada

servidor presente no cluster e considerado um no, e a capacidade do cluster e escalavel ao

adicionar mais nos a este, ou ao adicionar mais armazenamento ao no. Consequentemente

ao aumento da capacidade do cluster, a sua performance e aumentada com o aumento

de armazenamento disponıvel e da rapida disponibilidade dos dados, devido a replicacao

dos dados entre os nos [31].

O algoritmo utilizado pelo Gluster para a gestao dos ficheiros e dados esta presente em

todos os servidores do cluster, logo nao existe servidores com papeis definidos, como por

exemplo a gestao dos metadados [31].

O Gluster apresenta um design modular, que utiliza pequenos plugins chamados de

translators, que permitem estender as funcionalidades base do cluster. Essas funcionali-

dades podem passar pela mudanca do metodo de redundancia dos dados, assim como a

alteracao de como os estes sao distribuıdos pelo cluster [32].


2.4 LUKS

O LUKS [33] e a especificacao standard para encriptacao de discos em Linux. Enquanto

que uma grande parte dos softwares de encriptacao de discos usam formatos e processos

de encriptacao diferentes e incompatıveis entre si, o formato utilizado pelo LUKS e uni-

versal entre as distribuicoes Linux, o que facilita a compatibilidade e interoperabilidade

entre diferentes programas.

Um disco/dispositivo formatado com o LUKS e composto pelos seguintes campos: LUKS

partition header (PHDR), oito seccoes chamadas Key Material, numeradas de 1 a 8, e

um campo chamado bulk data, que contem os dados cifrados. O layout da estrutura esta

representado abaixo [34] [35].

LUKS partition header KM 1 KM 2 ... KM 8 bulk data

O pormenor de existirem oito Key Material significa que podem existir ate oito passwords

que decifram o dispositivo encriptado.

O PHDR tambem contem informacoes sobre os key slots, que estao associados aos Key

Material, que se encontram a seguir ao PHDR.

Quando um key slot esta activo, isto e, tem uma password associada ao dispositivo

cifrado, e guardada uma copia da Master Key no Key Material correspondente, estando

este encriptado com uma password. Fornecer essa password permite a desencriptacao do

Key Material, o que leva ao acesso da Master Key, que vai ser utilizada para desbloquear

a bulk data.

Para um key slot, todos os parametros necessarios para decifrar o seu Key Material com

uma determinada password estao guardados no PHDR.

Na tabela 2.1 esta representado o layout do campo PHDR, que se encontra no inıcio de

uma particao formatada com LUKS.

O header pode ser dividido em duas partes: a primeira parte e composta pelas in-

formacoes necessarias para decifrar a bulk data, parte essa composta pelos campos cipher-

name, cipher-mode, payload-offset e pelo campo key-bytes.

A segunda parte e usada para a verificacao dos candidatos a master-key (mk-digest,

mk-digest-salt e mk-digest-iter).

Cada key-slot contem informacao relativa ao processo de decifrar o Key Material. Como

ja descrito acima, o key-slot refere-se a uma copia da Master Key, que esta guardada


Campo Descricao

magic Valor do campo ”magic”para o header do LUKS

version Versao do LUKS

cipher-name Nome da cifra

cipher-mode Modo da cifra

hash-spec Especificacoes da hash

payload-offset Inıcio da bulk data

key-bytes Numero de bytes na chave

mk-digest Checksum da master key

mk-digest-salt ”Sal”usado para determinar o mk-digest

mk-digest-iter Numero de iteracoes para calcular o mk-digest

uuid UUID (Universal Unique Identifier) da particao

key-slot-1 Key Slot 1


... ...


Tabela 2.1: Header da particao LUKS

no Key Material, que por sua vez esta cifrado por uma password. Uma descricao da

composicao do key-slot esta representada na tabela 2.2.

Campo Descricao

active Estado da key slot

iterations Numero de iteracoes para cifrar a password

salt ”Sal”para a cifra da password

key-material-offset Indicacao do sector inicial do Key Material correspondente

stripes Numero de stripes usados pelo processo de cifra

Tabela 2.2: Composicao de um key-slot

Como o LUKS guarda a informacao de setup no header da particao cifrada, isto permite

que, por exemplo, se cifre uma pen num computador, e seja possıvel aceder ao seu

conteudo noutro [33] [34].

Um exemplo do comando e respectivos switches para formatar um dispositivo com LUKS

esta descrito no comando abaixo indicado [36]:


cryptsetup -v --cipher aes-xts-plain64 --key-size 256 --hash sha1

--iter-time 1000 --use-urandom --verify-passphrase luksFormat

<dispositivo>

Os switches do comando acima exemplificado sao descritos da seguinte forma:

• --cipher aes-xts-plain64: Indica qual a cifra que ira ser utilizada para encrip-

tar o dispositivo;

• --key--size 256: O tamanho da chave a ser utilizada. Por omissao, o LUKS

utiliza chaves de tamanho 256 bit;

• --hash sha1: O algoritmo de hash usado; Desde Janeiro de 2014, o algoritmo

SHA1 e considerado adequado para uso [37];

• --iter-time 1000: Tempo, em milisegundos, usado para cifrar a password ;

• --use-urandom: Utiliza o dispositivo /dev/random para gerar entropia durante o

processo de criacao da Master Key do dispositivo LUKS;

• --verify-passphrase: Switch que obriga a reinsercao da palavra-passe, como

metodo de confirmacao durante o processo de criacao da particao LUKS;

Por omissao, o comando cryptsetup -v luksFormat <dispositivo> substitui todas

as opcoes dos switches acima descritos.

Apesar de, por omissao, o LUKS usar a cifra AES, com o modo xts-plain64, e usar o

algoritmo de hash SHA1, estes parametros podem ser modificados.

Para cifras utilizadas, o LUKS suporta as seguintes: AES, twofish, serpent, cast5

e cast6. Em relacao ao modo da cifra, esta pode tomar os seguintes valores: ecb,

ecb-plain, cbc-essiv:hash (ex: cbc-essiv:sha256), e o modo xts-plain64, que e o

modo usado por omissao.

Quanto aos valores utilizados para o switch relativo a hash, podem ser os seguintes:

sha1, sha256, sha512 e finalmente ripemd160 [34].

Nao existe uma combinacao ideal entre cifras, modos e hashs a serem usados no momento

de criacao do dispositivo cifrado, logo torna-se necessario adaptar a forca da cifra, e a

dificuldade existente para a quebrar, de acordo com o tipo de informacao que se pretende

armazenar no dispositivo.

O LUKS tem como base uma versao melhorada do cryptsetup que, por sua vez, utiliza

o dm-crypt como base para a encriptacao de discos.


O dm-crypt [38] e um subsistema de encriptacao de discos, que faz parte da infraestrutura

do device mapper. Este pode ser utilizado por cima de outros dispositivos criados atraves

do device mapper, tais como dispositivos RAID ou volumes criados pelo LVM.

O dm-crypt so faz a encriptacao do dispositivo de bloco, nao le ou analisa quaisquer

dados la existentes. O facto deste software so lidar com encriptacao de dispositivos

de blocos, de uma forma transparente, torna-o bastante flexıvel, pois permite encriptar

qualquer dispositivo de blocos, independentemente do SO la instalado.

2.5 iSCSI

iSCSI e um protocolo de transporte que foi desenvolvido com o intuito de permitir a

comunicacao de blocos de dados entre um computador anfitriao, chamado de Initiator,

e um dispositivo de destino, chamado Target, atraves de redes TCP/IP, possibilitando

que comandos SCSI sejam encapsulados em pacotes IP [39].

Por transportar comandos SCSI em redes IP, o iSCSI e usado para facilitar a transferencia

de dados em intranets e para gerir armazenamento em longas distancias. O iSCSI pode

ser usado para transmitir dados em LANs, WANs, ou na Internet e pode permitir o

armazenamento de dados e sua recuperacao independente da localizacao.

No iSCSI, quando uma aplicacao envia uma pedido I/O, o sistema operativo gera o

comando SCSI necessario, o qual e entao encapsulado num pacote IP, que vai ser

transmitido normalmente atraves de uma rede Ethernet. Este pacote e recebido pelo

iSCSI Target, sendo depois o comando extraıdo e interpretado pelo dispositivo SCSI

[40].

Atraves do protocolo iSCSI, o acesso a unidade de armazenamento ocorre ao nıvel de

blocos (Block Level), ao contrario do que acontece com os protocolos FTP ou NFS, onde

o acesso e feito ao nıvel de ficheiros (File Level) [41].

No Block Level, a gestao do sistema de ficheiros e feito pelo host, o que faz com que

apenas transitem pacotes SCSI entre o Initiator e o Target, fazendo com que o SO

cliente (iSCSI Initiator) reconheca o volume alocado em storage como se de um disco

local se tratasse.

Ja em File Level, o sistema de ficheiros esta do lado do dispositivo de armazenamento,

bem como os protocolos para partilha de ficheiros (ex. NFS ou FTP), que tambem sao

executados do lado do servidor.

As caracterısticas do protocolo iSCSI tornam-no ideal para o armazenamento de dados


num volume alocado remotamente. No entanto este protocolo nao e adequado para a

partilha de um volume remoto, isto porque caso ocorram multiplos acessos simultaneos

provenientes de iSCSI Initiators distintos, existe uma grande probabilidade de os dados

ficarem corruptos.

2.6 LVM

LVM e visto como uma ferramenta para a gestao de volumes logicos no Linux. Ao criar

uma camada de abstraccao sobre o armazenamento fısico (ex. HDD, SSD), faz com que

a criacao e gestao de volumes logicos seja mais flexıvel e dinamica.

Na estrutura LVM existem tres componentes principais:

• Physical Volume (PV): sao a base do LVM e representam o armazenamento fısico;

• Volume Group (VG): composto por um ou mais PV, de modo a criar uma pool de

armazenamento;

• Logical Volume (LV): sao criado sobre os VG, e sao estes volumes que sao utilizados

para aceder/manipular o espaco existente no armazenamento fısico;

O uso de LVM traz algumas vantagens, entre as quais a possibilidade de personalizar os

nomes dos dispositivos, o que facilita a sua identificacao e o pormenor do redimensiona-

mento da particao sem que haja qualquer necessidade de refazer o seu conteudo.

Existem tres tipos de LV: linear volume, striped volume e mirrored volume.

• Linear Volumes: Neste tipo de LV, varios PV sao concatenados num so LV. Todo

o espaco disponıvel nos PV e entao utilizado neste LV;

• Stripped Volumes: Neste tipo de LV, os dados sao repartidos e escritos em varios

discos fısicos, o que pode originar uma melhor performance de I/O. Este tipo de

LV e semelhante ao RAID 0;

• Mirrored Volumes: Quando os dados sao escritos para o LV, estes sao escritos

simultaneamente em dois dispositivos, o que faz com que haja, pelo menos, duas

copias dos mesmos dados. Analogamente, este modo e semelhante ao RAID 1, o

que origina redundancia dos dados;

Capıtulo 3

Desenvolvimento

Neste capıtulo serao descritos os procedimentos seguidos para a instalacao e configuracao

dos softwares utilizados no projecto NASCloud.

Na seccao 3.1 sao apresentados os varios cenarios montados e testados, onde e dada uma

explicacao da composicao de cada um, juntamente com o seu proposito.

Na seccao seguinte (3.2) e apresentado e descrito o script criado para a execucao dos

benchmarks de velocidade. O script pode ser consultado no apendice A.

Quanto aos softwares de cache utilizados, as suas configuracoes estao descritas na seccao

3.3. Aqui sao explicados os passos necessarios para estabelecer a associacao do disco

SSD ao dispositivo proveniente da Cloud atraves do BCache e EnhanceIO, para desta

forma acelerar o seu acesso.

Logo de seguida, na seccao 3.4, sao indicados quais os procedimentos usados para a

criacao e estabelecimento de um cluster Ceph. Este cluster e usado para fornecer espaco

de armazenamento na forma de dispositivos de blocos, tal como se de uma cloud se

tratasse. O cluster foi configurado em dois cenarios: virtual e real. Em cada um existem

detalhes diferentes de configuracao, detalhes esses que sao indicados na seccao referida.

Para estabelecer as comunicacoes entre os varios elementos do projecto, utilizou-se

o protocolo iSCSI. Na seccao 3.5 sao explicados os procedimentos seguidos para a

instalacao e configuracao dos dois elementos que compoem o protocolo iSCSI - iSCSI

target e iSCSI initiator. Aqui sao tambem explicadas algumas alteracoes feitas ao SO,

de modo a aumentar a performance.

Seguindo a estrutura definida apos os primeiros testes integridade de dados efectuados,

criou-se e configurou-se um array em RAID 1, com dispositivos de blocos provenientes da

20

CAPITULO 3. DESENVOLVIMENTO 21

cloud. Este array vai permitir adicionar uma camada de redundancia. Os procedimentos

relativos a este processo estao explicados na seccao 3.6.

Como a seguranca dos dados e cada vez mais importante e essencial, para a definicao

final da appliance a componente ”Seguranca” era um requisito obrigatorio. Na seccao

3.7 sao explicadas as vantagens do uso desta componente, juntamente com uma descricao

da etapas seguidas, para a instalacao e configuracao do LUKS.

Finalmente, na seccao 3.8 e feita uma descricao dos passos seguidos para a implementacao

do LVM, o que vai facilitar a gestao do espaco de armazenamento proveniente da cloud.

3.1 Cenarios de teste

Foram implementados e testados varios cenarios de teste, com objectivos definidos. O

primeiro objectivo foi medir a performance dos softwares de cache utilizados no projecto

(EnhanceIO e BCache), para se poder definir qual o mais adequado.

Na figura 3.1 esta representado o cenario base do projecto. Da Cloud, simulada pelo

cluster Ceph, sao exportados por iSCSI dispositivos de blocos para o CSG, onde este

por sua vez os reexporta, tambem por iSCSI, para o Cliente.

Este cenario foi utilizado para definir e configurar as conexoes entre os varios elementos

do projecto (Ceph, CSG e Cliente), e estabelecer os valores iniciais de comparacao para os

testes de velocidade a serem feitos no projecto, a medida que a instalacao e configuracao

dos restantes softwares utilizados e feita.

ISCSI

ClienteCloud Storage Server

/dev/sdxISCSI

Figura 3.1: NASCloud - Caso Base

O cenario representado na figura 3.2 e, de um modo geral, igual ao cenario acima

descrito, mas com a diferenca de existir um dispositivo SSD, que vai servir de cache

aos dispositivos de blocos provenientes da Cloud.

A utilizacao deste cenario permitiu estabelecer as definicoes do software de cache usado

no projecto (EnhanceIO), e verificar os ganhos de velocidade que este permitiu obter,


face ao cenario anterior.

ISCSI ISCSI


EnhanceIOWB/WT

SSD

Figura 3.2: NASCloud - Cenario Base com aceleracao local

Outro cenario de teste, desta vez de integridade de dados, esta representado na figura

3.3. Este cenario representa a ocorrencia de falhas no dispositivo SSD, que serve de

cache e acelera o acesso aos dados localizados na Cloud, o que permite observar o

comportamento do software de cache neste tipo de situacoes, e estabelecer metodos

e outros cenarios de testes, de modo a prevenir perda de dados e garantir que estes estao

sempre salvaguardados, na eventualidade de ocorrerem falhas no sistema ou no setup do

projecto.

ISCSI


EnhanceIOWB/WT

SSD

ISCSI

Figura 3.3: NASCloud - Cenario Base com falha na aceleracao local

Finalmente, a figura 3.4 representa a estrutura final do projecto NASCloud, onde sao

importados da Cloud para o CSG dois dispositivos de blocos, via iSCSI, cujo acesso foi

acelerado pelo software de cache EnhanceIO. Depois de acelerados, foi criado um RAID

1 composto pelos dois dispositivos importados, para garantir redundancia dos dados.

A criacao deste cenario e uma consequencia dos testes efectuados no cenario anterior

(figura 3.3), em que se identificou os possıveis pontos de falha na estrutura, e tentou-se

elimina-los atraves da duplicacao de conexoes para a cloud, e do estabelecimento de um

array RAID 1.


ISCSI

Cliente

Cloud Storage Server

EnhanceIOWB/WT

SSD

EnhanceIOWB/WT

SSD

ISCSI 1

ISCSI 2

Figura 3.4: NASCloud - Cenario Final

Em cima destes cenario de testes, foram feitos mais alguns testes de integridade de dados,

ao simular diversas falhas durante o funcionamento do sistema. As falhas testadas foram

a quebra de uma ligacao iSCSI a Cloud, e falhas num disco SSD.

Depois dos testes de integridade feitos, e descobertos os pontos de falha deste cenario,

continuou-se a montar o resto da estrutura, que incluıa a camada de encriptacao, forne-

cida pelo LUKS, e o software para gestao do espaco proveniente da Cloud, o LVM.

3.2 FIO

Para os testes de performance e velocidade, foi utilizado o software FIO, que permite

executar benchmarks de velocidade de leitura e escrita de dados em dispositivos de

blocos.

De modo ao FIO simular um determinado workload de I/O, e necessario indicar uma

serie de parametros com a descricao do setup pretendido. A esse conjunto de parametros

da-se o nome de job.

Foram executados dois processos do FIO: o primeiro para fazer um warm-up da cache,

que consiste em executar leituras e escritas sequenciais, de modo a colocar dados na

cache, e o segundo para retirar os dados a serem analisados, representando o benchmark

propriamente dito.

De modo a agilizar todo o processo de benchmarking, foi criado um script bash em que,

consoante o tipo de teste a ser executado (writeback ou writethrough), ou o dispositivo

a ser testado, era modificado.

Essas modificacoes eram efectuadas na linha source device=/dev/sdb1, onde era in-

dicado qual o dispositivo a ser testado. e na linha cache mode=wb, onde se indicava


que tipo de teste era efectuado (writeback ou writethrough). Esta ultima opcao neste

script era so usada por motivos de organizacao dos ficheiros criados, em que se cria

uma directoria de acordo com o tipo de teste a efectuar. O script completo pode ser

consultado no apendice A.

Para executar o FIO de acordo com o que se pretendia simular, houve necessidade de

utilizar varios switches, para personalizar e fazer um fine tuning aos processos a serem

executados. Os switches utilizados estao descritos abaixo, juntamente com uma breve

descricao do significado de cada um. De notar que, para os testes de benchmark, foram

feitos acessos de leitura e escrita aleatorios, cenarios onde os discos SSD sao mais rapidos

que os discos HDD, o que permite tirar mais partido da aceleracao de cache.

• direct=1: A funcao deste switch e garantir que os dados que estao a ser escri-

tos/lidos sao passados directamente para o dispositivo, evitando assim que estes

fiquem armazenados no buffer e sejam mais rapidamente processados. Este buffer

e uma memoria que esta embebida no dispositivo de armazenamento, que actua

como uma memoria cache. Isto permite que os resultados sejam mais fidedignos;

• –size=XX: Executa um processo do tamanho indicado nesta variavel. Esse tama-

nho pode ser num valor em MB/GB , ou entao uma percentagem do tamanho de

um ficheiro ou dispositivo indicado;

• –filesize=2GB: Tamanho maximo do ficheiro criado;

• –blocksize=4K: O tamanho do bloco usado para o I/O, tanto para leituras como

para escritas;

• –ioengine=libaio: Define como o processo FIO trata os I/O para o ficheiro. O

modo ”libaio” significa Linux Native Asynchronous I/O. Este modo so pode ser

utilizado com o switch –direct=1;

• –rw=rw/randrw: Define o tipo de leituras/escritas a serem executadas. rw =

leituras/escritas sequenciais; randrw = leituras/escritas aleatorias;

• –rwmixread=XX: Percentagem de leitura a ser feita no job;

• –rwmixwrite=XX: Percentagem de escrita a ser feita no job. A juncao deste switch

com o definido anteriormente (rwmixread) tem de ser igual a 100;

• –iodepth=X: Numero de I/O units que vao ser processados ao mesmo tempo. Uma

I/O unit e equivalente a um ”ficheiro”a ser processado;


• –numjobs=X: Numero de jobs que sao executados ao mesmo tempo;

• –filename=/dev/sd?: Dispositivo/ficheiro que vai ser usado para executar o teste;

• –group reporting: Agrupa as estatısticas de cada job num so grupo;

• –name=??: Nome de cada job executado;

• –random distribution: Modelo de distribuicao usado pelo FIO para execucao de

IO aleatorios;

3.3 Software de cache

Para a manipulacao dos dispositivos de cache, pelos softwares EnhanceIO e BCache,

foram criados dois scripts, um para cada caso. Os scripts podem ser consultados nos

apendices B e C.

O modo de utilizacao destes scripts e semelhante ao do FIO, isto e, existem blocos

de codigo que sao modificados conforme o tipo de sistema de cache que se pretende

implementar.

Em relacao do BCache, nas linhas source device="/dev/sda" e cache device="/dev/vdb"

sao indicados os dispositivos que serao utilizados como dispositivo lento, a ser acelerado,

e o disco SSD, que serve de cache ao dispositivo lento.

Na linha cache mode=wb e indicado o tipo de polıtica de cache a ser utilizada. Finalmente

a linha cache=bcache0 indica o nome dado ao dispositivo virtual utilizado pelo BCache.

Os restantes blocos de codigo dizem respeito ao processo de criacao e eliminacao da cache.

Durante o processo de criacao de cache, sao alterados algumas definicoes de cache para

se obter resultados de benchmark mais fidedignos. Essas alteracoes sao referentes aos

tempos de latencia dos discos SSD para I/O sequenciais, em que por vezes podem ser

mais lentos do que os dispositivos de armazenamento. O que foi feito foi retirar os limites

de tempo para que assim nao ocorra nenhum atraso do disco SSD. A opcao relativa ao

sequential cutoff tambem esta relacionada com I/O sequenciais. Ao alterar o seu

valor para 0, esta-se a indicar ao BCache para nao descartar I/O sequenciais [42].

Sobre o processo de eliminacao de cache, primeiro e dada a indicacao para parar o

dispositivo de cache, para copiar o seu conteudo, caso haja, para o dispositivo lento.

O passo seguinte no processo de eliminacao da cache e retirar a ligacao entre os dois

dispositivos (SSD e dispositivo lento).


No ultimo bloco de codigo, descomenta-se a opcao que se pretende executar (criacao ou

eliminacao da cache).

Quanto ao metodo de criacao e eliminacao de cache utilizando o software EnhanceIO, o

script apresentado no apendice C esta dividido em quatro blocos.

O primeiro bloco e referente as definicoes da cache, onde e indicado qual o dispositivo a

ser acelerado, o dispositivo que serve de cache (disco SSD), a polıticas de substituicao

e de cache utilizadas, o tamanho do bloco da cache, e finalmente o nome a ser dado a

cache.

O segundo bloco do script diz respeito ao comando de criacao da cache e os switches

utilizados para tal, previamente indicados no bloco anterior.

No terceiro bloco de codigo esta o comando utilizado para a eliminacao de uma cache

criada pelo software EnhanceIO. Finalmente no ultimo bloco de codigo, a imagem do

script referente ao BCache (apendice B), basta descomentear a opcao que se pretende

executar, se a criacao ou eliminacao da cache.

3.4 Ceph

Como ja descrito na seccao 2.3, o Ceph e uma plataforma de armazenamento open-

source, que disponibiliza armazenamento de blocos e ficheiros a partir de um cluster

distribuıdo. A grande vantagem do uso do Ceph e ser tolerante a falhas, devido a

replicacao de dados entre os elementos do cluster, o que faz que nao haja um ponto de

falha e os dados estejam sempre disponıveis para os utilizadores.

Para o projecto NASCloud utilizou-se o armazenamento de blocos, pois assim foi possıvel

exportar o espaco disponıvel no cluster via iSCSI. Para a gestao e manipulacao de

imagens de dispositivos de blocos, o Ceph utiliza a interface RADOS Block Device

(RBD).

Pode-se assumir que um dispositivo de blocos do Ceph e um disco de rede virtual, que

pode ser anexado a um host Linux, estando este a partir deste ponto disponıvel como

se de um disco local se tratasse.

O que motivou a escolha do Ceph sobre o Gluster foi o facto deste nao permitir criar e

exportar dispositivos de blocos nativamente, como acontece com o Ceph [43].

No Gluster o metodo utilizado para criar e exportar dispositivos de blocos passa por

montar o Gluster numa maquina pertencente ao cluster, e criar um ficheiro que representa


o dispositivo de blocos proveniente do Gluster, atraves do comando dd. Depois disso,

tem de se exportar por iSCSI o ficheiro criado no passo anterior.

Executados todos os passos descritos no paragrafo anterior, o cliente, liga-se ao disposi-

tivo exportado como iSCSI Initiator [44].

O problema desta abordagem e que o dispositivo de blocos nao e acedido directamente,

como acontece no Ceph. Este e simulado por um ficheiro, que por sua vez, e exportado

por iSCSI.

A instalacao do Ceph obriga a certas regras. Uma delas e que todos os computadores

envolvidos no cluster tem de poder aceder uns aos outros atraves de ”root”, sem uso

de password. Este passo foi feito atraves do comando ”ssh-copy-id root@dest node”,

onde dest node e a maquina de destino. Outra regra essencial para a instalacao de um

cluster Ceph e que as maquinas envolvidas tem de comunicar entre si atraves dos seus

hostnames.

Nos dois cenarios de teste, a versao do Ceph que foi utilizada foi a 0.72 Emperor.

Antes de proceder a instalacao, foram criadas os seguintes directorios em todas as

maquinas envolvidas no cluster, que sao as localizacoes onde o Ceph armazena os seus

dados. Apesar deste passo nao ser obrigatorio, este procedimento e aconselhado para

evitar problemas na instalacao do cluster [45]:

• /etc/ceph

• /var/lib/ceph/tmp,mon,bootstrap-osd

• /var/log/ceph

E adicionado o repositorio do Ceph ao sistema, pela criacao do ficheiro ceph.repo no

directorio /etc/yum.repos.d, com o seguinte conteudo:

[ ceph−noarch ]

name=Ceph noarch packages

b a s e u r l=ht tp : //ceph.com/rpm-emperor/fc19/noarch

enab l ed=1

gpgcheck=1

type=rpm−md

gpgkey=h t t p s : //ceph.com/git/?p=ceph.git;a=blob plain;f=keys/release.asc


3.4.1 Cenario Virtual

O cenario virtual foi a primeira hipotese a ser explorada para a implementacao de um

cluster Ceph. Tal deve-se a facilidade de criacao e de utilizacao de maquinas virtuais

para o efeito.

Para a criacao do cluster Ceph foi usado o esquema de rede representado na figura 3.5.

Ceph Monitor

OSD Daemon

Ceph Monitor

OSD Daemon

Ceph Monitor

OSD Daemon

Rede Intra-OSD

Cluster Ceph

Cloud StorageGateway

Ceph-node1 Ceph-node3Ceph-node2

CSG

Figura 3.5: Diagrama Ceph - cenario virtual

O hardware das maquinas virtuais Ceph-Node1, Ceph-Node2 e Ceph-node3 era identico.

Todas elas tinham um processador Single Core a 2.6 GHz, 512 Mega Bytes (MB) RAM,

e dois discos rıgidos: um de 7 Giga Bytes (GB), que era o disco do sistema, e outro de

20 GB, que iria ser usado para o cluster Ceph.

A maquina CSG tambem tinha um processador Single Core a 2.6 GHz, mas o dobro da

memoria RAM das maquinas Ceph (1024 MB RAM). Quanto aos discos rıgidos, esta era

composta por quatro discos: um de 7 GB para o sistema, e os restantes tres como discos

SSD, de modo a funcionarem como cache para os dispositivos de bloco provenientes do

cluster Ceph.

A velocidade da rede virtual utilizada era de 1 Gbps.

Na altura da instalacao foram utilizadas duas sub-redes, com propositos diferentes: a

rede interna do cluster, servia para comunicacao exclusiva entre os elementos do cluster,

e a rede publica. O uso da rede interna permite reduzir a carga de utilizacao da rede

publica, ao eliminar o trafego de heartbeat e replicacao entre OSDs.

Existem mais razoes para usar duas redes distintas:


• Seguranca: ter uma rede separada para o cluster previne possıveis ataques de

Denial of Service (DoS). Quando o trafego entre os OSDs e interrompido, o estado

do cluster deixa de estar em active+clean, o que vai impedir de ler/escrever dados

para o cluster;

• Performance: Os OSDs sao responsaveis pela replicacao de dados entre os OSDs do

cluster. Quando os OSDs replicam os dados, a carga gerada na rede rapidamente

supera a carga da rede entre os clientes e o cluster, o que origina latencia na rede

e problemas de performance. A verificacao de heartbeat dos OSDs tambem origina

mais trafego na rede, o que pode comprometer a performance desta.

Os passos seguidos para a instalacao e configuracao do cluster estao enumerados e

explicados abaixo. Todo o processo foi executado a partir de uma maquina (Ceph-

Node1).

1. Criacao do primeiro Ceph-monitor:

• yum install ceph-deploy: Antes de iniciar todo o processo de instalacao

do cluster Ceph, teve de se instalar o programa ceph-deploy, na maquina

Ceph-Node1, que vai ser o monitor principal do cluster;

• ceph-deploy new Ceph-Node1: Para criar o cluster, de nome ”ceph”, sendo

o Ceph-Node1 o monitor principal;

• ceph-deploy install Ceph-Node1: Instala o Ceph na maquina Ceph-Node1;

• ceph-deploy mon create-initial: Adiciona a maquina como monitor do

cluster. A partir deste ponto o cluster esta criado, e o seu estado pode ser

consultado atraves do comando ceph status;

• Foram acrescentadas as seguintes entradas em /etc/ceph/ceph.conf:

[global]

public network=192.168.10.0/24

cluster network=192.168.20.0/24

• service ceph restart: Reiniciou-se o servico Ceph, no monitor principal,

para confirmar que ficou correctamente instalado;

2. Adicao de monitores ao cluster:


• ceph-deploy install Ceph-Node2 Ceph-Node3;

• ceph-deploy mon create Ceph-Node2 Ceph-Node3: Cria e define as maquinas

Ceph-Node2 e Ceph-Node3 como monitores do cluster;

3. Instalacao dos OSDs:

• ceph-deploy disk list Ceph-Node1: Lista os discos/particoes disponıveis

na maquina Ceph-Node1, que vao ser utilizadas para o servico OSD;

• ceph-deploy disk zap Ceph-Node1:vdb: Este comando remove a tabela de

particoes do disco vdb, para preparar a instalacao do Ceph, como OSD;

• ceph-deploy osd prepare Ceph-Node1:vdb: Transforma a maquina num

no OSD do cluster, e criar duas particoes no disco vdb: uma para servir como

journal do OSD, outra que vai ser utilizada para armazenar os dados (vdb1 );

• ceph-deploy osd activate Ceph-Node1:vdb1 Activa o Ceph-Node1 como

OSD, na particao vdb1, depois desta ter sido preparada no passo anterior;

A partir deste ponto do processo de instalacao e configuracao, ao executar o

comando ceph -s, foi possıvel verificar que o estado do cluster esta como AC-

TIVE+CLEAN, o que significa que tudo correu como esperado.

Para a instalacao dos restantes OSDs, todos os passos descritos no ponto 3 foram

repetidos, mas alterou-se para o nome das maquinas pretendidas (Ceph-Node2,

Ceph-Node3).

4. Criacao de dispositivos de bloco no Ceph:

• rbd create block-csg --size 2048: Criou-se uma imagem de um dispo-

sitivo de blocos no Ceph, com o nome block-csg, com tamanho de 2 GB;

Inicialmente, para disponibilizar o dispositivo de bloco criado no Ceph ao CSG,

utilizou-se o comando rbd para mapear o dispositivo localmente, na maquina

monitor do cluster Ceph. O comando rbd permite criar, listar, alterar e remover

imagens de dispositivos de bloco com origem no Ceph. Ao longo dos testes

efectuados chegou-se a conclusao que este metodo nao era o ideal para exportar os

dispositivos via iSCSI para os clientes, porque as velocidades obtidas eram muito

baixas.

Outro inconveniente deste procedimento era o facto da maquina CSG tomar o

papel de Ceph Client, o que implica que o CSG faca parte do cluster. Isto iria

eliminar o objectivo da utilizacao do Ceph, que passava pela simulacao de uma


Cloud para exportacao de espaco existente na nuvem, de uma forma transparente

e atraves de iSCSI, para o CSG. A figura 3.6 ilustra o esquema inicial.

Ceph Monitor + OSD Daemon

Cluster Ceph original Ceph Client

CSG

RBD

Cluster Ceph original + Ceph Client

Cliente

ISCSI

Figura 3.6: Diagrama Ceph - Cluster Ceph+Ceph Client

A solucao encontrada foi exportar, via iSCSI, os dispositivos de blocos directamente

a partir das maquinas pertencentes ao cluster. Para isso teve de se instalar o

pacote scsi-targets-utils modificado para poder exportar imagens de dispositivos

criados pelo rbd. Isto acontece porque o pacote scsi-targets-utils, por omissao,

nao suporta dispositivos rbd. O pacote utilizado estava disponıvel no repositorio

extra do Ceph [46]. Desta forma, para o CSG, a importacao dos dispositivos de

bloco provenientes do cluster Ceph foi feita usando os procedimentos habituais em

Linux, como pode ser consultado na seccao 3.5. Na figura 3.7 pode-se visualizar

como ficou a estrutura usada ao longo do projecto.

Ceph Monitor + OSD Daemon

Ceph Monitor+ scsi-targets- utils

Cluster Ceph original

CSG

ISCSI

Cliente

ISCSI

Figura 3.7: Diagrama Ceph - Cluster Ceph+scsi targets utils

3.4.2 Cenario Real

Para estes testes foram utilizadas 14 computadores reais, todos com hardware identico.

Como caracterısticas tecnicas, as maquinas dispunham de um processador Quad Core

1.4GHz, 4GB RAM, sendo criadas tres particoes, todas com 5 GB, para o SO, journal


dos OSDs do Ceph e para o armazenamento dos dados gravados nos OSDs. A maquina

que serviu com CSG, alem do hardware ja descrito, tinha instalado um disco SSD com

240 GB de capacidade, que foi utilizado para cache dos dispositivos de blocos importados

do cluster Ceph. A velocidade da rede era de 100Mbps.

OSDs Daemons

Cluster Ceph

Cloud StorageGateway

Ceph Monitors

T0101 T0102 T0103

T0104 T0105 T0106 T0107 T0108 T0109 T0110 T0111 T0112 T0113

Figura 3.8: Diagrama Ceph - Cenario real

O esquema deste cenario esta representado na figura 3.8, e para a implementacao do

Ceph foram seguidos os mesmos passos descritos na seccao 3.4.1, apenas com ligeiras

alteracoes relativas a localizacao dos dados e do journal dos OSD’s.

Como neste cenario foi utilizado um maior numero de computadores, foram criados e

utilizados alguns pequenos scripts.

O primeiro script foi utilizado para instalar o Ceph nas maquinas T0101 ate T0112.

for i in ‘seq -w 01 12‘;do ceph-deploy install T01$i; done

Os restantes scripts utilizados tinham como objectivo preparar e configurar os discos

rıgidos e os OSDs.

for i in ‘seq -w 04 12‘;do ceph-deploy disk zap T01$i:sda10; done

for i in ‘seq -w 04 12‘;do ceph-deploy disk zap T01$i:sda11; done

for i in ‘seq -w 04 12‘;do ceph-deploy osd prepare

T01$i:sda11:/dev/sda10; done

for i in ‘seq -w 04 12‘;do ceph-deploy osd activate

T01$i:sda11:/dev/sda10; done

Os codigos das ultimas duas linhas indicam os dispositivos sda11 e sda10 como a


localizacao onde o OSD vai armazenar os dados, e o caminho para o journal do OSD,

respectivamente. Para obter uma melhor performance, deve-se colocar o journal do OSD

numa particao/dispositivo diferente da dos dados [47].

3.5 iSCSI

Para estabelecer as comunicacoes entre os varios elementos envolvidos no projecto (Ceph,

CSG e Cliente), utilizou-se o protocolo iSCSI. O CSG desempenha o papel de iSCSI

Initiator e iSCSI Target simultaneamente, ja que disponibiliza os dispositivos de blocos

aos Clientes, apos os ter importado do cluster Ceph.

3.5.1 iSCSI Target

Para que fosse possıvel exportar por iSCSI as imagens dos dispositivos de blocos cria-

dos pelo rbd, houve necessidade de instalar o pacote ”scsi-target-utils”, disponıvel nos

repositorios extra do Ceph [46]. A necessidade da instalacao deste pacote modificado

e devida a incompatibilidade do pacote ”scsi-target-utils” existente nos repositorios do

SO com as imagens criadas atraves do rbd. Apos o mapeamento do dispositivo atraves

do comando rbd map nome bloco, a exportacao do mesmo por iSCSI no Cliente tinha

uma performance muito abaixo do esperado.

Tanto nos cenarios virtuais como nos reais, as maquinas escolhidas para serem os iSCSI

targets foram os monitores principais dos clusters, Ceph-Node1 e T0101 respectivamente.

Depois de instalar o pacote referido acima, procedeu-se a configuracao do target. No

ficheiro /etc/tgt/targets.conf adicionaram-se as seguinte linhas, de modo a expor a

imagem do dispositivo de blocos rbd como um target a exportar [48] [49]:

<t a r g e t i qn . 2 0 1 4 . 0 4 . com . csg : b l o c k c eph . t a r g e t>

d r i v e r i s c s i

bs−t ype rbd

# back ing−s t o r e pool name/ block name

back ing−s t o r e rbd / b lock−csg# EXPOR O TARGET SO PARA O CSG − IP CSG

i n i t i a t o r −add r e s s 192 . 168 . 10 . 10

</t a r g e t>

Apos estas modificacoes, recarregou-se o servico, atraves do comando service tgtd


reload, para activar o target.

Apos alguns testes efectuados, chegou-se a conclusao que era necessario acrescentar mais

alguns detalhes as configuracoes iniciais. Isto acontece nao so porque as velocidades me-

didas eram mais baixas do que as esperadas, mas tambem porque elas eram constantes,

estivesse ou nao a ser utilizado o software de aceleracao de cache, o que se traduzia em

resultados condicionados e adulterados.

As solucoes encontradas passaram por desactivar o Write Cache no iSCSI target [50] [51]

e acrescentar algumas configuracoes globais aos iSCSI targets, no ficheiro /etc/tgt/targets.conf

[52] [53], de modo a fazer um ligeiro tuning a performance do target. O facto de desactivar

o Write Cache no iSCSI target faz com que os dados, a medida em que sao recebidos

sejam logo guardados no dispositivo que serve de base ao bloco exportados, impedindo

assim que estes fiquem armazenados temporariamente na cache.

As linhas inseridas no ficheiro targets.conf foram as seguintes:

MaxRecvDataSegmentLength 262144

MaxXmitDataSegmentLength 262144

I n i t i a l R 2T No

ImmediateData Yes

MaxOutstandingR2T 8

O significado de cada linha e o seguinte:

• MaxRecvDataSegmentLength 262144: Maximo de dados recebidos por PDU;

PDU significa Protocol Data Unit (PDU) (Unidade de Dados de Protocolo), que

descreve um bloco de dados que e transmitido entre duas instancias da mesma

camada do modelo OSI.

Cada camada recebe a PDU da camada superior como um bloco de dados, adiciona

os seus cabecalhos de controlo, criando a sua propria PDU. A este processo chama-

se de encapsulamento [54].

• MaxXmitDataSegmentLength 262144: Maximo de dados transmitidos por PDU;

• InitialR2T No: Nao envia ao iSCSI initiator o sinal a indicar que esta pronto

receber dados. O nao envio do sinal elimina as pausas entre a transmissao de

pacotes iSCSI [55].

• ImmediateData Yes: Indica ao iSCSI initiator que envie de imediato dados para

escrita junto do pacote TCP, indicando o comando SCSI WRITE [55].


• MaxOutstandingR2T 8: O numero maximo de Ready to Transfer (R2T) PDUs em

transmissao antes do PDU de confirmacao do termino do comando SCSI entre o

initiator e o target ter sido recebido [56];

Quando o iSCSI initiator submete um comando SCSI a indicar que pretende enviar

dados para o seu iSCSI target, o target envia varios R2T ao initiator, para que este

inicie o envio dos dados [57] [58].

Para desactivar o Write Cache no iSCSI target [50] [51] utilizou-se o seguinte comando:

tgtadm --lld iscsi --op update --mode logicalunit --tid 1 --lun 1

--params mode page=8:0:18:0x10:0:0xff:0xff:0:0:0xff:0xff:0xff:

0xff:0x80:0x14:0:0:0:0:0:0

O que resulta da aplicacao do comando e a actualizacao do parametro mode page para

o valor indicado, da unidade logica 1, pertencente ao target 1.

A maquina CSG, alem de desempenhar a funcao de iSCSI initiator em relacao ao cluster

Ceph, tambem foi configurada como um iSCSI target, para poder exportar os dispositivos

de blocos ja acelerados para os computadores Clientes.

Para isso, o ficheiro /etc/tgt/targets.conf foi configurado da seguinte forma:

<t a r g e t i qn . 2 0 1 4 . 0 4 . com . csg : b l o c k c s g . t a r g e t>


back ing−s t o r e /dev / sda

</t a r g e t>

Todas as restantes configuracoes acima indicadas foram tambem feitas no CSG.

3.5.2 iSCSI Initiator

As maquinas CSG e Cliente foram configuradas como iSCSI Initiators, tanto nos cenarios

reais como virtuais. O CSG funciona como o Initiator dos Targets que exportavam o

dispositivo de blocos proveniente do cluster Ceph, e os Clientes como Initiators dos

CSG (neste caso, configurados como iSCSI targets), onde importavam os dispositivos de

blocos disponibilizados por estes, devidamente acelerados.


Os procedimentos de instalacao, deteccao dos targets e ligacao a estes foram os seguintes:

1. yum install iscsi-initiator-utils && service iscsi start: Instalou-se o

pacote iSCSI Initiator padrao, existente nos repositorios do SO, e iniciou-se o

servico iSCSI quando a instalacao deste terminou;

2. iscsiadm -m discovery -t sendtargets -p csg: descobre no CSG se este dis-

ponibilza iSCSI targets, e retorna os seus iSCSI Qualified Name (IQN). O IQN e

o nome pelo qual o target disponibilizado e conhecido [59];

3. iscsiadm -m node -T iqn.2014.04.com.csg:block ceph.target -p csg:3260

--login: Estabelece a conexao com o target indicado. Apos este passo, o target

esta mapeado no sistema, como se um dispositivo de blocos local se tratasse;

De modo a tentar obter a melhor performance de leitura/escrita possıvel, houve ne-

cessidade de configurar algumas definicoes existentes que actuam sobre o dispositivo de

blocos. Estas alteracoes foram feitas no Initiator, apos a conexao iSCSI estar estabelecida

[60] [61] [62].

echo noop > /sys/block/sdX/queue/scheduler

echo 1024 > /sys/block/sdX/queue/nr requests

echo 16384 > /sys/block/sdX/queue/max sector kb

A alteracao do scheduler de cfq para a configuracao noop fez com que a performance de

leitura/escrita melhorasse significativamente. O noop e um scheduler de pedidos I/O,

baseado em FIFO (First In, First Out), ou seja, o primeiro pedido I/O que entra na fila

de espera e o primeiro a sair desta. A vantagem desta alteracao e que deixa de existir

reordenacao e prioridade nos pedidos de I/O, tal como acontece com a configuracao por

omissao (cfq).

A nao prioritizacao dos pedidos de I/O permite que estes sejam controlados totalmente

pelo software que os esta a lancar, evitando assim conflitos entre os servicos utilizados.

Desta forma diminui-se o numero de possıveis interferencias (o que se traduz num

aumento de performance), passando a gestao de I/O do dispositivo para o protocolo

iSCSI.

A alteracao do parametro do dispositivo nr requests de 256 para 1024 resulta num

aumento do numero de pedidos I/O que o dispositivo faz para ler e escrever dados.

Aumentar a quantidade maxima de pedidos tende a melhorar a performance geral do


dispositivo, principalmente em relacao a gravacao de dados [63].

Foi escolhido este valor porque providencia um aumento consideravel do numero de

pedidos I/O face ao valor por omissao. O valor escolhido poderia ser maior (ex. 2048),

mas tambem poderia afectar a latencia do sistema, caso existisse um grande numero de

dados pequenos.

A alteracao do parametro do sistema operativo max sectors kb para 16384 significa

uma reducao no numero de PDUs transmitidos entre os intervenientes.

O campo max sectors kb define o tamanho maximo permitido por I/O, em kb, no

dispositivo. Por omissao, o valor definido neste campo e de 512, isso significa que

quanto mais baixo for o valor definido em max sectors kb, maior sera a quantidade de

SCSI PDUs necessarios para a mesma quantidade de dados. Baseado nessa observacao,

aumentar o valor de max sectors kb reduz o numero de SCSI PDUs necessarios, o que

se traduz num aumento de performance.

3.6 RAID

Para garantir a redundancia dos dados a serem escritos no cluster Ceph, na maquina

CSG foi criado um array RAID do nıvel 1 (mirroring).

Foi utilizado o seguinte comando para a criacao do array RAID 1 /dev/md0, utilizando os

dispositivos /dev/sdd e /dev/sde, que representam dispositivos provenientes do cluster

Ceph:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/sdd /dev/sde

Durante os varios testes de integridade de dados que foram efectuados, houve necessidade

de simular diversas falhas, tanto de software como de hardware. Entre as falhas simuladas

e testadas encontra-se a de um dos dispositivos do array.

Esta simulacao passou por marcar um dos dispositivos como Faulty, para que nao fossem

escritos dados nesse dispositivo e o estado do RAID estivesse como Degraded. O comando

utilizado para foi o seguinte:

mdadm --manage --set-faulty /dev/md0 /dev/sde

Para verificar a integridade e igualdade dos dados nos dois dispositivos do array, foi

necessario o RAID e iniciar novos dispositivos RAID, cada um deles com um dos discos


pertencentes ao array anteriormente parado. Para este procedimento utilizaram-se os

seguintes comandos:

mdadm --stop /dev/md0

mdadm --assemble /dev/md0 /dev/sdd

mdadm --assemble /dev/md1 /dev/sde

Os resultados dos testes efectuados podem ser consultados na seccao 4.2.3.

3.7 LUKS

A aplicacao de uma camada de encriptacao de dados sobre o espaco disponibilizado pelo

cluster Ceph era um dos pontos obrigatorios no projecto NASCloud.

Desta forma, os dados enviados para a Cloud ja estao cifrados e protegidos, o que

impossibilita que alguem alheio ou mal intencionado consiga visualizar o seu conteudo,

atraves de ataques do tipo ”man-in-the-middle”, conseguindo capturar os pacotes TCP

transmitidos entre o CSG e a Cloud.

Para este efeito, foi utilizado o software LUKS de modo a cifrar o dispositivo RAID 1

que foi criado no passo anterior (seccao 3.6).

A ideia inicial passava cifrar primeiro os dispositivos de blocos importados do Ceph para

o CSG e so entao criar o RAID 1 usando os dispositivos cifrados. O problema desta

abordagem seria a duplicacao de dispositivos cifrados: alem de criar uma maior carga de

trabalho para o SO para os processos de cifra dos dispositivos, iria-se estar a adicionar

mais um ponto crıtico de configuracao no projecto, sem necessidade para tal.

Nesse sentido, revelou-se preferıvel cifrar o dispositivo criado pelo RAID, pois alem de

reduzir os possıveis pontos crıticos, consegue-se a garantia de que o conteudo dos dois

dispositivos de blocos pertencentes ao array RAID sao exactamente iguais.

Os comandos utilizados para cifrar o dispositivo foram os seguintes:

• cryptsetup luksFormat /dev/md0: cifra o dispositivo de blocos /dev/md0. Foi

utilizada a cifra por omissao, aes-xts-plain64, por se considerar bastante segura, e

praticamente indecifravel [64]. A cifra AES utiliza um tamanho de bloco de 128

bits e o LUKS, para o tamanho da chave, usa 256 bits;


• cryptsetup luksOpen /dev/md0 cloud space: mapeia o dispositivo cifrado an-

teriormente num novo dispositivo de nome ”cloud space”, que fica localizado no

directorio de sistema /dev/mapper/;

3.8 LVM

Escolheu-se usar o software LVM para melhor gerir o espaco a exportar desde o CSG

para os Clientes. Esta escolha deveu-se a facilidade com que e possıvel redimensionar o

espaco do dispositivo, sem que haja qualquer interrupcao no servico ou downtime.

Os comandos utilizados para implementar as funcionalidades do LVM foram os seguintes:

• pvcreate /dev/mapper/cloud space: Neste passo criou-se um PV, tendo por

base o dispositivo cifrado cloud space;

• vgcreate cloud volume /dev/mapper/cloud space: Criou-se um VG de nome

cloud volume, sobre o PV cloud space;

• lvcreate -L 200M -n user1 space cloud volume: Criou-se um LV, com o nome

user1 space, de tamanho 200 MB, sobre o VG cloud volume.

Este passo foi repetido varias vezes, de modo a criar os volumes a serem atribuıdos

aos varios Clientes;

A partir deste ponto, os LV a serem exportados por iSCSI para os Clientes estavam

criados. O passo seguinte foi adicionar os LV a lista dos iSCSI targets. Para isso foram

acrescentadas as seguintes linhas ao ficheiro /etc/tgt/targets.conf:

<t a r g e t i qn .2014−05.com . cgs : c g s u s e r 1 . t a r g e t>


back ing−s t o r e /dev / c l oud vo lume / u s e r 1 s p a c e

</t a r g e t>

<t a r g e t i qn .2014−05.com . cgs : c g s u s e r 2 . t a r g e t>


back ing−s t o r e /dev / c l oud vo lume / u s e r 2 s p a c e

</t a r g e t>


Para poder utilizar o dispositivo proveniente do CSG na maquina Cliente, e apos im-

porta-lo atraves de iSCSI foi necessario formata-lo, atraves do comando mkfs.ext4

/dev/sdX (onde /dev/sdX e o dispositivo importado), e monta-lo (tornando-o acessıvel)

numa pasta do sistema (mount /dev/sdX /mnt).

Capıtulo 4

Testes e Resultados

Este capıtulo e composto por duas seccoes, Testes de Velocidade e Teste de Integridade

de dados, onde estao descritos os testes que foram efectuados durante a composicao do

projecto NASCloud e comentados os respectivos resultados registados.

De modo a determinar a configuracao ideal do CSG, foram efectuados testes de veloci-

dade em varios cenarios possıveis. Esses cenarios sao o resultado da evolucao do projecto

ao longo do tempo. Os resultados desses testes estao descritos na seccao 4.1.

Na seccao 4.2 sao apresentados e descritos os testes de integridade de dados que foram

feitos. Sao explicados os passos e parametros seguidos durante este processo, e qual o

ponto em que se considera que a integridade dos dados e garantida.

4.1 Testes de Velocidade

Nesta seccao e feita uma descricao dos varios testes efectuados e um comparativo entre

os valores registados. Para estes testes foi utilizado o software de benchmarking FIO [18].

Foi tambem utilizado um script composto por dois processos: o primeiro para fazer um

warm-up da cache e o segundo para a execucao do benchmark, de onde foram retirados

os valores apresentados. Esse script pode ser consultado no apendice A.

A excepcao do Caso Base (seccao 4.1.1), em que o script de benchmark foi executado

cinco vezes, em todos os restantes cenarios o script foi executado tres vezes, e os

resultados apresentados sao uma media aritmetica simples do conjunto de resultados, isto

e, a soma dos resultados (de cada campo) a dividir pelo numero de testes efectuados.

41

CAPITULO 4. TESTES E RESULTADOS 42

Importante lembrar que o objectivo projecto NASCloud, e a consequente construcao

da appliance e verificar se e possıvel utilizar todas as tecnologias mencionadas em

simultaneo, de maneira a que seja possıvel obter ganhos consideraveis de performance,

face a nao existencia da appliance. Por este motivo nao foi dada grande relevancia a

validacao estatıstica dos resultados registados.

De modo a calcular o ganho de um valor em relacao a outro foi utilizada a formula

abaixo indicada:

ganho = (valor maior

valor menor− 1)× 100 (4.1)

4.1.1 Caso Base

Os primeiros testes de todo o projecto foram executados numa maquina virtual utilizando

o SO Fedora Core 19 e quatro discos virtuais: tres discos SSD e um disco HDD mais

lento, quando comparado com os discos SSD. Os discos SSD tinham como funcao servir

de cache ao disco mais lento.

Importante referir que o espaco que compunha os discos virtuais SSD era fornecido por

um conjunto de discos SSD instalados num suporte rapido no servidor de maquinas

virtuais, o que so por si poderia modificar os resultados obtidos.

O teste inicial passou por medir a performance de um disco SSD, e compara-la com a

de um dispositivo RAID 0, composto pelos restantes discos SSD instalados, de modo

a existirem dados que ajudassem a decidir qual o cenario a utilizar. Nestes testes nao

foram notorias diferencas que justificassem a utilizacao de RAID 0 como dispositivo de

cache. Para alem do maior risco de seguranca dos dados armazenados, caso um dos

discos falhasse, as performances comparadas eram praticamente iguais.

Para se poder ter um termo de comparacao entre dispositivos, software e modos de cache,

foram feitos testes de benchmarking ao disco SSD, disco lento sem aceleracao (HDD),

disco lento com aceleracao Write back (WB) e Write through (WT), usando os softwares

BCache e EnhanceIO. Importa referir que estes testes foram executados cinco vezes, e

os resultados apresentados sao uma media do conjunto dos testes. Os resultados podem

ser consultados na imagem 4.1.

Pela analise dos resultados obtidos e apresentados nessa imagem e visıvel a diferenca

entre os discos SSD e HDD, tanto em velocidade de leitura e escrita, assim como


2,58

71,98

11,72

1,30

3,92

47,14

13,57

1,51

3,11

33,95

18,19

2,02

2,37

18,38

27,97

3,11

8,91

27,64

10,53

1,17

1,92

2,18

57,24

6,36

0 5 10 15 20 25 30 35 40 45 50 55 60 65 70 75

Latência de leitura (ms)

Latência de escrita (ms)

Leitura (MB/s)

Escrita (MB/s)

Bcache Vs EnhanceIOWritethrough Vs Writeback

SSD HDD EnhanceIO Writeback Bcache Writeback EnhanceIO Writethrough Bcache Writethrough

Figura 4.1: Grafico comparativo caso base

nos tempos de latencia. Apos a aplicacao do software de cache Bcache e EnhanceIO,

obtiveram-se resultados muito melhores do que os registados pelo disco HDD, como seria

de esperar.

No modo WB, o Bcache tem um ganho de velocidade de cerca de 72% em leitura e escrita

quando comparado com o disco HDD. Ja com o EnhanceIO, obtem-se um aumento de

performance de 158% em velocidade de leitura, e de 165% em relacao a velocidade de

escrita.

Importante salientar a diferenca de performance entre os dois mecanismos de cache

local testados. No modo de cache WB, o EnhanceIO tem performances superiores ao

seu concorrente, em todos os testes efectuados. Tanto em velocidade de escrita como de

leitura, o EnhanceIO tem um ganho de aprox. 54%, em relacao ao BCache. Quanto aos

tempos de latencia medidos, em escrita o EnhanceIO e cerca de 45% mais rapido, e em

leitura de dados tem uma performance superior ao Bcache em cerca de 24%.

Ja no modo de cache WT, O EnhanceIO continua a ter melhores prestacoes que o Bcache,

mas de um modo geral, com resultados mais aproximados. A diferenca medida entre os

dois softwares de cache foi de cerca de 15%.


4.1.2 [Ceph] → [CSG]

Neste cenario testou-se e comparou-se as performances da aceleracao de cache no CSG,

em relacao ao dispositivo exportado pelo cluster Ceph. A exportacao foi feita por iSCSI,

e os testes foram feitos sobre o bloco Ceph exportado, com e sem aceleracao (WB e WT).

Importa mencionar que a partir deste cenario descartou-se o uso do software BCache,

pelos seguintes motivos:

• Baixa performance comparativamente ao EnhanceIO (de acordo com os resultados

obtidos nos testes anteriores);

• Incompatibilidade com o Ceph. Os testes efectuados com o BCache, neste cenario,

apresentavam valores de leitura/escrita tremendamente baixos, ainda mais baixos

do que os registados no bloco Ceph, e com valores de latencia muito elevados;

Os resultados destes testes podem ser consultados na imagem 4.2. Os dados referem-

se aos testes efectuados nas maquinas virtuais. Estes testes de benchmarking foram

efectuados tres vezes, e os resultados apresentados sao a media do conjunto dos testes.

17,31

194,78

3,17

0,35

4,08

47,52

13,14

1,47

32,14

130,47

2,67

0,30

0 20 40 60 80 100 120 140 160 180 200



Leitura (MB/s)

Escrita (MB/s)

Bloco Ceph Vs Bloco Ceph+EnhanceIO WB/WT

Bloco Ceph Bloco Ceph+EnhanceIO Writeback Bloco Ceph+EnhanceIO Writethrough

Figura 4.2: Grafico comparativo Bloco Ceph vs Bloco Ceph+EnhanceIO WB/WT -

Virtual

Com base nos resultados obtidos, e possıvel verificar que o uso de cache permite obter

um grande aumento de performance em relacao ao bloco Ceph. Ao utilizar a aceleracao


em WB conseguiu-se obter um aumento de performance de aprox. 390% em velocidade

de leitura/escrita. Ja em WT, os ganhos situam-se nos 18% em leitura e 16% em escrita.

Em relacao a latencia de leitura/escrita, pela analise dos graficos e possıvel verificar que

o uso de cache em WB reduz bastante os tempos, comparando quer com o bloco Ceph

sem aceleracao, quer com aceleracao em WT.

Estes mesmos testes foram efectuados num cenario identico mas com maquinas reais,

podendo os resultados ser consultados na imagem 4.3.

7,21

54,01

5,63

0,62

6,29

7,81

10,48

1,16

7,12

52,89

5,71

0,64

0 10 20 30 40 50 60



Leitura (MB/s)

Escrita (MB/s)

Bloco Ceph Vs Bloco Ceph+EnhanceIO WB/WT

Bloco Ceph Bloco Ceph+EnhanceIO Writeback Bloco Ceph+EnhanceIO Writethrough


Real

Tal como demonstrado nas experiencias com maquinas virtuais, aqui o aceleracao em

WB tambem foi bastante superior. Tanto em relacao ao bloco Ceph importado, como

em relacao ao mesmo bloco mas com cache em WT, utilizar a cache em WB permitiu

obter ganhos na ordem dos 85%, nas velocidades de leitura/escrita.

Quanto aos valores de latencia medidos, em relacao a escrita, a cache em WB obteve

valores mais baixos do que os restantes, o que vai de encontro a um dos objectivos

pretendidos, que passava por definir qual o melhor modo de cache, WB ou WT.

Na imagem 4.4, e possıvel ver um comparativo entre os resultados virtuais e reais, para

este cenario.


10,39

116,87

3,17

0,35

7,21

54,01

5,63

0,62

2,45

28,51

13,14

1,47

6,29

7,81

10,48

1,16

0 20 40 60 80 100 120



Leitura (MB/s)

Escrita (MB/s)

Comparativo Real vs VirtualBloco Ceph Vs Bloco Ceph+EIO WB/WT

REAL - Bloco Ceph+EIO WB VIRTUAL - Bloco Ceph+EIO WB REAL - Bloco Ceph+EIO WT VIRTUAL - Bloco Ceph+EIO WT


Real vs Virtual

Comparando, dentro do mesmo cenario, os resultados das maquinas virtuais com os das

maquinas reais, de um modo geral os valores medidos foram relativamente proximos,

quando se fala sobre as velocidades de leitura/escrita. Os valores em WB nas maquinas

virtuais foram ligeiramente superiores que os das maquinas reais, se bem que em relacao

a velocidade de leitura, o numero apresentado (10,48 MB/s) esta no limite da velocidade

maxima permitida pela rede de 100mbps, o que pode levar a concluir que, fora esta

limitacao de velocidade existente no cenario real, este valor poderia ser mais elevado.

Quanto aos valores de latencia, os das maquinas reais foram mais baixos do que os das

maquinas virtuais.

Apesar de o hardware dos computadores reais ser sensivelmente mais fraco do que o

do Host das maquinas virtuais, inclusive a velocidade da rede utilizada (100Mbps vs

1Gbps), o facto da virtualizacao limitar o desempenho dos discos utilizados para os

testes fez com que os resultados ”virtuais” fossem mais baixos do que os esperados.

4.1.3 [Ceph] → [CSG] → [Cliente]

Este cenario representa a configuracao base do modelo que se pretende implementar.

O cluster Ceph, ao simular uma cloud, exporta via iSCSI o seu espaco para o CSG.

Este, por sua vez, acelera o acesso a este espaco via EnhanceIO que o disponibiliza, por

iSCSI, aos clientes. Os resultados apresentados foram todos medidos no Cliente, e sao o


resultado da media de tres testes.

Ao espaco importado pelo Cliente chamou-se Bloco Cloud. Os resultados medidos estao

representados na imagem 4.5.

19,88

191,14

3,02

0,34

5,55

7,43

19,71

2,19

19,52

179,81

3,15

0,35

0 20 40 60 80 100 120 140 160 180 200



Leitura (MB/s)

Escrita (MB/s)

Bloco Cloud Vs Bloco Cloud+EnhanceIO WB/WT

Bloco Cloud Bloco Cloud+EnhanceIO Writeback Bloco Cloud+EnhanceIO Writethrough

Figura 4.5: Grafico comparativo Bloco Cloud vs Bloco Cloud+EnhanceIO WB/WT -

Virtual

Estes resultados confirmam a vantagem do uso de cache em WB, sobre o dispositivo

importado da Cloud. A aceleracao permitiu obter um ganho de cerca de 525% em relacao

ao original, sobre as velocidades de leitura/escrita. Isto traduziu-se num aumento de 0,35

MB/s para 2,19 MB/s em velocidade de escrita, e de 3,15 MB/s para 19,71 MB/s em

velocidade de leitura.

Comparando com os resultados das maquinas virtuais da seccao 4.1.2 e apesar de nesta

configuracao existir mais um elemento, o Cliente, seria expectavel que os valores medidos

fossem mais baixos. No entanto, tal nao se verificou. Isto porque, apesar de se ter

desactivado a cache que o protocolo iSCSI utiliza (como indicado na seccao 3.5.1), o

proprio SO tambem faz cache do que esta a ler/escrever [65], o que faz com que os dados,

quando sao acedidos novamente, sejam lidos da cache do sistema e nao directamento do

dispositivo, o que contribuiu para um ligeiro aumento das velocidades de leitura/escrita.


4.1.4 [Ceph]→ [CSG+EIO WB+RAID1+LUKS+LVM]→ [CLIENTE]

Este cenario de teste representa a configuracao final de toda a estrutura ”NASCloud”.

Foram importados do cluster Ceph, via iSCSI, dois dispositivos de blocos para o CSG,

onde aqui foram acelerados pelo EnhanceIO, em modo WB. Posteriormente foi criado um

array RAID 1 com os dois dispositivos importados e ja acelerados (/dev/mdX), isto para

garantir redundancia dos dados, sendo depois implementada a camada de encriptacao

LUKS sobre esse array.

A partir deste ponto foi utilizado o LVM, devido a sua facilidade de gestao do espaco do

disco, para depois re-exportar os dispositivos via iSCSI, para os clientes. Do lado do cli-

ente, apos este ter importado o espaco disponibilizado pelo CSG, so lhe resta formatar o

dispositivo para o poder utilizar normalmente, como se de um disco/particao/dispositivo

local se tratasse. Um esquema desta configuracao esta retratado na figura 3.4.

Na figura 4.6 pode-se consultar os resultados dos testes de velocidade sobre este cenario,

feitos tanto nas maquinas virtuais como nas reais.

4,84

13,57

12,04

1,34

6,37

8,76

10,21

1,14

0 2 4 6 8 10 12 14



Leitura (MB/s)

Escrita (MB/s)

Comparativo Real vs VirtualBloco Cloud+EIO WB+RAID1+LUKS+LVM

REAL - Bloco Cloud+EIO WB+RAID1+LUKS+LVM VIRTUAL - Bloco Cloud+EIO WB+RAID1+LUKS+LVM

Figura 4.6: Grafico comparativo Bloco Cloud+EIO WB+RAID1+LUKS+LVM - Real

vs Virtual

E possıvel verificar que as velocidades de leitura e escrita registadas nas experiencias

efectuadas nas maquinas virtuais sao superiores do que as executadas nas maquinas

reais. A diferenca entre ambas ronda os 17%. Importante referir que em relacao as

velocidades de leitura registadas nas maquinas reais, estas estao no limite permitido

pela rede utilizada (100Mbps).


Quanto aos valores de latencia registados, em relacao aos valores de escrita, as maquinas

virtuais apresentaram valores superiores em praticamente o dobro do que nas maquinas

reais (55%). Essa diferenca deve-se ao facto de, tal como ja referido na seccao 4.1.2, a

virtualizacao limitar o desempenho dos discos.

Em relacao ao tempo de latencia de leitura, o cenario virtual foi mais rapido do que o

cenario de testes real.

4.2 Testes de Integridade de dados

Nesta seccao serao descritas as conclusoes dos varios testes de integridade de dados

realizados. Estes testes tem como objectivo definir e estabelecer uma configuracao que

garanta fiabilidade e seguranca aos utilizadores deste sistema.

Para testar a integridade dos dados, de um modo geral, foram utilizados um conjunto de

ficheiros, composto por ficheiros de vıdeo, imagens, musicas, executaveis e ficheiros de

texto, verificados os checksums dos ficheiros originais e comparados com os checksums

dos ficheiros copiados. Se nao houve alteracao entre os checksums entao, para o cenario

testado, considera-se que existe a garantia de integridade dos dados.

Em todos os testes efectuados verificaram-se, sempre que possıvel, os checksums dos

ficheiros em duas localizacoes distintas na rede: no computador Cliente e no computador

CSG.

Na tabela 4.1 estao indicados os quatro estados possıveis do EnhanceIO: Active, Degra-

ded, Disabled e Failed, o que originam esses estados e de que forma e tratado o I/O, de

acordo com o estado da cache. A informacao apresentada nesta tabela e particularmente

util para se poder ter uma percepcao das conclusoes relativas aos testes de integridade.

Apesar de existirem cenarios em que a integridade dos dados e garantida (quando existe

um array RAID 1), ha sempre a possibilidade de tal facto nao ser verdade.

Esta situacao pode ocorrer quando falha em simultaneo algum elemento que esteja

directamente relacionado com ambos os dispositivos pertencentes ao RAID 1, como por

exemplo a ligacao iSCSI entre a cloud e o CSG de um dispositivo do RAID, e o disco

SSD que serve de cache para o outro elemento do RAID. Quando ocorre esta situacao

(falha em dois pontos do cenario) nao e possıvel garantir integridade dos dados.


Tabela de estados da cache

Estado Descricao I/O

ActiveAmbos os dispositivos source e SSD estao pre-

sentes no sistema.I/O sao acelerados

Degraded

Disco SSD e removido do sistema (ex. falha

do disco), quando o estado da cache esta como

”Active”, e no modo Write Through.

I/O nao sao acelerados

Disabled

Quando o disco SSD nao esta presente durante

o boot do sistema. Este estado so e possıvel

quando a cache esta como Write Through.

I/O nao sao acelerados

Failed

O dispositivo source nao esta presente durante

o boot do sistema, ou quando este e removido do

sistema estado a cache como ”Active”. Falha do

disco SSD, quando em modo Write Back.

Falha e erros de I/O

Tabela 4.1: Tabela de Estados EnhanceIO

4.2.1 1o Cenario

Neste cenario foi testada a integridade dos dados referente ao esquema representado na

figura 3.2, apresentado no capıtulo 3.

Neste cenario, o dispositivo de bloco e importado, via iSCSI, do Cluster Ceph para o

CSG, onde aqui e acelerado pelo EnhanceIO, no modo WB. Esse mesmo bloco e entao

re-exportado para o Cliente, tambem via iSCSI.

• Cliente:

– Apos copiar ficheiros, os md5sums dos ficheiros copiados eram iguais aos dos

ficheiros originais;

• CSG:

– Apos desmontar o dispositivo iSCSI no Cliente, o dispositivo exportado foi

montado localmente, no CGS, e comparou-se os md5sums dos ficheiros pre-

sentes no dispositivo com os md5sums dos ficheiros originais, presentes no

Cliente. Verificou-se que eram identicos;


– Esta experiencia permitiu verificar que a cache EnhanceIO, em WB, funcio-

nou correctamente, e nao houve erros relativos ao iSCSI.

Conclusao: Este cenario garante uma integridade dos dados.

4.2.2 2o Cenario

Para este cenario de testes, reproduziu-se o mesmo teste que o anterior, mas desta vez

simulou-se que o disco SSD, que funciona como cache ao EnhanceIO, falha. Este cenario

esta representado na figura 3.3. Simulou-se a falha do disco SSD em duas situacoes:

quando esta a copiar ficheiros, e depois de copiar, ao libertar a cache.

1. Quando esta a copiar ficheiros:

• Ao desligar o disco SSD (echo 1 >/sys/block/sda/device/delete), ocor-

reram de imediato erros de I/O no Cliente, originando falhas na copia dos

ficheiros;

• No CSG, o estado do EnhanceIO passou de ”Active” para ”Failed”;

• Ao existir falhas na copia dos ficheiros, torna-se obvio que os md5sums destes

sao diferentes dos originais;

• Nao e possıvel copiar conteudo para o dispositivo iSCSI, no Cliente (erros

I/O);

Conclusao: Este cenario NAO garante uma integridade dos dados.

2. Depois de copiar, durante o flush da cache:

• Cliente:

– md5sum dos ficheiros copiados sao iguais aos dos ficheiros originais;

– Apesar dos ficheiros, para o sistema , estarem correctamente copiados e

serem iguais aos originais, ao tentar aceder a alguns ficheiros ocorrem

erros de I/O;

– A outros ficheiros, com tamanho mais pequeno, ja e possıvel aceder sem

problemas nem erros;

– Este comportamento deve-se ao facto de alguns blocos ja terem sido

descarregados da cache para o dispositivo source, enquanto que outros

blocos nao, o que origina os erros de I/O;


• CSG:

– dmesg | grep ssd → surgiram mensagens de erro I/O;

– dmesg | grep cache → surgiram mensagens a informar que a cache

EnhanceIO esta em modo ”Failed”, porque o disco SSD foi retirado/-

falhou;

– eio cli info → estado da cache passou para ”Failed”;

– cat /proc/enhanceio/cache ceph/errors→ a variavel no cache dev

ficou igual a 1.

O facto do valor desta variavel ser igual a 1 significa que nao existe

dispositivo de cache no sistema;

– Apos desmontar o dispositivo iSCSI no Cliente e desligar a ligacao iSCSI,

tentou-se montar o dispositivo exportado localmente, mas sem sucesso;

– Ao tentar recriar todo o cenario (iSCSI entre CSG e Cliente, e montar o

dispositivo no Cliente), ocorreram erros ao voltar a montar o dispositivo;

– So e possivel voltar a montar o dispositivo se:

∗ Se apagar a cache criada pelo EnhanceIO;

∗ Ao reiniciar o CSG, este voltar a detectar o disco SSD, ainda com a

cache para descarregar. Neste caso, o EnhanceIO volta ao seu estado

normal, e o flush da cache para o dispositivo de bloco proveniente do

Cluster Ceph tem inıcio;

Conclusao: Este cenario NAO garante uma integridade dos dados.

4.2.3 3o Cenario

O terceiro cenario de testes representa o esquema da figura 3.4. Neste esquema de

teste foram importados dois dispositivos de blocos para o CSG, via iSCSI, onde aqui

estes foram acelerados pelo EnhanceIO e colocados em RAID1, para replicarem o seu

conteudo. O dispositivo RAID foi depois exportado, via iSCSI, para o Cliente.

Mais uma vez, os testes e comparacoes foram feitas em dois pontos da rede: o Cliente e

o CSG. Foram testadas 3 situacoes: sem falhas nos dispositivos e ligacoes iSCSI, falha

de uma ligacao iSCSI entre o Cluster Ceph e CSG, e a falha do disco SSD na cache2.

Como neste cenario foram importados dois dispositivos de bloco para o CSG para serem

acelerados pelo EnhanceIO, existem duas caches configuradas, cache1 e cache2, que

dizem respeito a cache de cada dispositivo importado, que depois constituem o RAID 1.


1. Sem falhas nos dispositivos e ligacoes iSCSI:

• Cliente:

– Apos copiar os ficheiros para o dispositivo importado por iSCSI, foram

verificados os md5sum dos ficheiros copiados contra os dos ficheiros ori-

ginais, e eram identicos;

• CSG:

– Desmontou-se o bloco iSCSI no Cliente, desconectou-se a ligacao iSCSI

entre o CGS e o Cliente, e montou-se o dispositivo RAID directamente

no CGS. Comparou-se os md5sum com os originais e eram identicos;

– Parou-se o RAID criado, montou-se cada disco do array individualmente,

atraves do comando mdadm (porque os dispositivos fazem parte de um

array), e comparou-se os seus conteudos um com o outro. Eram iguais,

o que significa que o RAID funcionou correctamente;

Importante referir que os estes testes foram feitos quer apos o flush da cache estar

concluıdo, quer durante o flush da cache.

Conclusao: Este cenario garante integridade dos dados.

2. Falha de uma ligacao iSCSI entre o Cluster Ceph e CSG:

A falha foi simulada quando o flush da cache estava a decorrer.

• Cliente:

– Apos a copia ser concluıda com sucesso, comparou-se os md5sums (Copia

Vs Original) e estes eram identicos;

• CSG:

– RAID 1 ficou no estado ”degraded”, pois faltou um dos discos do array ;

– No outro disco do array, a aceleracao EnhanceIO continuou a funcionar

correctamente, fazendo o flush da cache para o Ceph;

– O estado da aceleracao EnhanceIO, no dispositivo que deixou de existir,

passou para ”Failed”;


entre o CSG e o Cliente, e montou-se o dispositivo RAID previamente ex-

portado directamente no CSG. Comparou-se os md5sum com os originais

e eram identicos;


– Desligou-se o RAID 1, e montou-se o disco pertencente ao array num novo

RAID 1 (forcado para utilizar so um disco), e comparou-se os md5sums

dos ficheiros la existentes com os dos ficheiros originais. Eram identicos;

– Apos reconectar a ligacao iSCSI entre o Ceph e CSG, tentou-se refazer

o RAID 1 com o dispositivo reconectado, mas sem sucesso (de notar

que este dispositivo reconectado e o disco que foi retirado originalmente

do array). Mesmo que tal fosse possıvel, o conteudo do disco estaria

corrompido, isto porque o flush da cache que estava associada a esse

disco nao foi efectuado;

Conclusao: Este cenario garante integridade dos dados. O uso do RAID 1 permite

prevenir possıveis erros e problemas que possam surgir, desde que nao ocorra erros

na transmissao dos dados entre o Cliente e o CSG.

3. Falha do disco SSD na cache2:

Tal como na experiencia anterior, o disco falhou quando o flush da cache estava a

ocorrer.

• Cliente:

– Apos a copia ser concluıda com sucesso, compararam-se os md5sums

(copia Vs original) e estes eram identicos;

• CSG:

– Apos se ter desligado o disco SSD que servia de cache, associado ao

cache2, o estado do RAID 1 continuou como ”Clean”, isto porque os dois

discos pertencentes ao array continuavam ligados;

– Passado uns segundos, o RAID mudou o seu estado para ”Degraded”, e

o dispositivo que entretanto ficou sem cache, ficou marcado como Faulty.

Esta mudanca de estado do RAID aconteceu devido a erros de I/O que

ocorreram no dispositivo que ficou sem cache, fornecida pelo disco SSD

que falhou. Nesta situacao, o estado da cache EnhanceIO ficou marcado

como ”Failed”, o que implica que nao ocorra I/O nesse dispositivo;


entre o CSG e o Cliente, e montou-se o dispositivo RAID directamente

no CSG. Compararam-se os md5sum com os originais e eram identicos;

Conclusao: Este cenario garante integridade dos dados. Esta integridade e ga-

rantida pela redundancia do RAID 1.

Capıtulo 5

Conclusoes

O trabalho desenvolvido neste projecto seguiu varias etapas que foram previamente bem

definidas.

Comecou com um trabalho de pesquisa e investigacao sobre cache, quais os softwares

de cache local existentes e o seu funcionamento. De seguida, para ser possıvel retirar

conclusoes sobre qual o software de cache indicado para o projecto, exploraram-se varios

metodos e programas de benchmarking de performance a dispositivos de armazenamento.

O passo seguinte foi investigar o funcionamento do protocolo iSCSI. Durante o decorrer

do projecto houve necessidade de aprofundar a investigacao sobre este topico, para se

conseguir obter melhores performances do que as registadas no momento dos testes

iniciais.

Depois do trabalho anterior estar concluıdo, iniciou-se a instalacao e configuracao do

Cluster Ceph, que serviu para simular o armazenamento proveniente da Cloud. Depois

de seguir todo o guideline acima descrito, foi implementada a componente de resiliencia

do projecto, composta pelo RAID e pela camada de encriptacao, fornecida pelo LUKS.

5.1 Discussao de Resultados

Durante a instalacao e configuracao do CSG, chegou-se a conclusao de que as confi-

guracoes do software de cache utilizado influenciam as performances a serem obtidas e

medidas. Se, por exemplo, a polıtica de cache estiver definida como LRU, os dados mais

requisitados estarao presentes na cache local, pelo que o seu acesso sera quase imediato,

quando comparado com os restantes dados que estao na Cloud.

55

CAPITULO 5. CONCLUSOES 56

As configuracoes e definicoes aplicadas tambem dependem do tipo de dados a serem

tratados. Por exemplo, se a baixa latencia for um requisito obrigatorio, como em

consultas a base da dados, entao sera preferıvel aumentar a duracao de tempo em que

os dados ficam retidos na cache.

Tambem se concluiu que quanto maior for o tamanho do disco/particao que faz de cache,

melhor sera o desempenho, pois mais dados ficarao disponıveis para um acesso com maior

rapidez.

A componente de seguranca sempre foi um pensamento constante ao longo da execucao

do projecto, por isso tanto a integridade dos dados a serem escritos na Cloud, a forma

como eles sao transmitidos, e a encriptacao da informacao foi tida em conta.

Equacionou-se adicionar uma camada de encriptacao directamente ao protocolo iSCSI,

o que faria com que todos os pacotes a serem transmitidos entre a Cloud e o CSG

estivessem cifrados. Mas isso iria causar um problema no projecto, pois alem de causar

um maior over-head a todo o processo de transmissao e um maior tempo de latencia

(pois era necessario cifrar o pacote na origem, transmiti-lo, e no receptor decifra-lo), a

seguranca dos dados armazenados na Cloud nao era garantida. So durante o transporte

dos pacotes e que isso estava garantido.

Com a aplicacao da camada de encriptacao no momento em que os dados chegam ao

CSG, vindos dos computadores clientes que estao localizados na rede interna, ja se

consegue garantir que a informacao que depois vai ser guardada na Cloud esta cifrada.

O uso do LVM permitiu agilizar e simplificar a atribuicao e gestao do espaco disponıvel

no CSG, pois esta e feita de uma forma dinamica, permitindo facilmente redimensio-

nar a particao a ser atribuıda ao cliente, sem que haja necessidade de desligar algum

servico/computador, o que se traduz na inexistencia de down-time.

No cenario apresentado na figura 3.4 (que representa o setup final da appliance), existe o

risco de falhar simultaneamente a conexao iSCSI entre o CSG e a cloud de um elemento

do RAID e o dispositivo de cache do outro elemento do RAID montado. Nessa situacao,

como ja referido na seccao 4.2, nao e possıvel garantir que nao haja perda de dados. Uma

forma de prevenir este ponto podera ser aumentar o numero de elementos do RAID, o que

tambem implica estabelecer mais uma conexao a um Cloud Provider. Apesar de nesta

nova possıvel configuracao existir uma grande percentagem de desperdıcio de espaco de

armazenamento, tambem existe uma maior seguranca dos dados.

CAPITULO 5. CONCLUSOES 57

5.2 Trabalho Futuro

Durante todo o projecto, o sistema operativo utilizado foi o Linux Fedora 19 e Fedora

20. Teoricamente, as performances serao iguais ou quanto muito semelhantes, mas testar

o desempenho geral desta appliance quando os computadores clientes sao maquinas de

outros sistemas operativos, como o Windows faz parte do trabalho futuro do projecto.

Nos cenarios reais, o facto de existirem limitacoes de velocidade impostas pela rede

(100Mbps), aliado com a performance do equipamento dos computadores, condicionou

os resultados registados. Faz parte do trabalho futuro do projecto repetir todas as

experiencias realizadas nos cenarios reais, mas num contexto de infraestrutura de rede

que esteja devidamente estruturada, segmentada e configurada para uma performance

adequada. Para o CSG, a possibilidade de agregar varias placas de rede de elevada

performance (trunking) tambem faz parte do trabalho futuro.

Com esta nova configuracao de rede e equipamento, as performances da appliance po-

derao melhorar drasticamente, quando comparadas com os valores registados durante as

experiencias realizadas.

O foco principal do projecto NASCloud e acelerar o armazenamento proveniente da

Cloud, mas com as devidas modificacoes [66] (tais como definir o tempo em que os

dados ficam na cache, ou os limites de espaco de armazenamento de dados na cache),

esta appliance pode ser utilizada para acelerar o acesso a qualquer tipo de dispositivo,

desde que a origem do espaco de armazenamento seja disponibilizado em blocos, tal

como acontece nos cenarios montados. Por exemplo, as performances de um servidor de

ficheiros local ou ate de um servidor de mail podem ser aumentadas significativamente

somente pelo uso de software de cache e respectivas polıticas adequadas a situacao.

O trabalho futuro deste projecto pode passar por definir varios perfis de configuracao,

adequados a multiplas hipoteses de cenario, de modo a criar ”black-boxes”, prontas a

serem usadas.

Outro ponto de trabalho futuro e a aplicacao da appliance num ambiente de producao

controlado, onde se podera retirar conclusoes mais realistas sobre a aplicabilidade do

projecto. Desse modo sera possıvel ”afinar” melhor as configuracoes que entretanto

foram aplicadas, de maneira a tirar melhor proveito de todos os conceitos explorados no

projecto.

Apendice A

Script FIO

#!/ b in / bash

# VARIAVEIS CACHE

s o u r c e d e v i c e=/dev/ sdb1

cache mode=wb # WB/WT

c a c h e b l o c k s i z e =4096

# VARIAVEIS FIO

f i o b l o c k s i z e=4K

f i l e s i z e =2G

iodep th=8

numjob=4

r r e a d=90

r w r i t e=10

runt ime=300

h i t s =90

# CRIAR A PASTA ONDE GUARDA OS OUTPUTS

outpu t pa th=”/ roo t / benchmarks / p e r f / e i o /${ cache mode} $ { r r e a d } r e a d $ { r w r i t e

} w r i t e $ { f i o b l o c k s i z e } I O 4K b l o c k s i z e $ { h i t s } h i t s ”

mkdir −p ${ ou tpu t pa th }

# WARM−UP DA CACHE

f i o −−d i r e c t=1 −−s i z e=50\% −− f i l e s i z e=${ f i l e s i z e } −−b l o c k s i z e=${f i o b l o c k s i z e } −− i o e n g i n e=l i b a i o −−rw=rw −−rwmixread=100 −−rwmixwr i t e=0

−−i o d ep th=${ i o d ep th } −−f i l e n ame=${ s o u r c e d e v i c e } −−name=${ h i t } H i t $ {f i o b l o c k s i z e } WarmUp −−output=${ ou tpu t pa th }/${ h i t } H i t $ {f i o b l o c k s i z e } WarmUp . t x t

# TESTE BENCHMARK

58

APENDICE A. SCRIPT FIO 59

f i o −−d i r e c t=1 −−s i z e =100\% −− f i l e s i z e=${ f i l e s i z e } −−b l o c k s i z e=${f i o b l o c k s i z e } −− i o e n g i n e=l i b a i o −−rw=randrw −−rwmixread=${ r r e a d } −−rwmixwr i t e=${ r w r i t e } −−i o d ep th=${ i o d ep th } −−numjob=${numjob} −−g r o u p r e p o r t i n g −−f i l e n ame=${ s o u r c e d e v i c e } −−name=${ h i t } H i t $ {f i o b l o c k s i z e } −−r a n d om d i s t r i b u t i o n=z i p f : 1 . 2 −−output=${ ou tpu t pa th }/${ h i t } H i t $ { f i o b l o c k s i z e } . t x t

Apendice B

Script BCache

#!/ b in / bash

# CACHE

s o u r c e d e v i c e=”/dev/ sda ”

c a c h e d e v i c e=”/dev/vdb”

cache mode=”wb”

# ALTERAR CONFORME O NUMERO CRIADO

cache=bcache0

# CRIACAO DA CACHE

bc a c h e c r e a t e ( ) {make−bcache −B ${ s o u r c e d e v i c e } −C ${ c a c h e d e v i c e }i f [ $cache mode = ”wb” ] ; then

echo w r i t e ba ck > / s y s / b l o ck / $cache / bcache / cache mode

f i

i f [ $cache mode = ”wt ] ; then

echo w r i t e t h r o ugh > / s y s / b l o ck / $cache / bcache / cache mode

f i

# MELHORAR A PERFORMANCE DOS BENCHMARKINGS

echo 0 > / s y s / b l o ck / $cache / bcache / s e q u e n t i a l c u t o f f

echo 0 > / s y s / f s / bcache / $cache / c o n g e s t e d r e a d t h r e s h o l d u s

echo 0 > / s y s / f s / bcache / $cache / c o n g e s t e d w r i t e t h r e s h o l d u s

echo Cache c r i a d a !

}

# ELIMINACAO DA CACHE

bc a c h e d e l e t e ( ) {echo 1 > / s y s / b l o ck / bcache / $cache / s top

uu id=bcache−super−show −f ${ c a c h e d e v i c e } | grep c s e t . uu id | awk

’{ p r i n t $2 } ’

60

APENDICE B. SCRIPT BCACHE 61

echo 1 > / s y s / f s / bcache / $uu id / u n r e g i s t e r

echo Cache e l im i n ad a !

}

# DESCOMENTAR O PRETENDIDO

#bca ch e c r e a t e

#b c a c h e d e l e t e

Apendice C

Script EnhanceIO

#!/ b in / bash

# CACHE

s o u r c e d e v i c e=”/dev/ sda ”

c a c h e d e v i c e=”/dev/vdb”

c a c h e p o l i c y=” l r u ”

cache mode=”wb”

c a c h e b l o c k s i z e=”4096”

cache name=” c a c h e e i o ”

# CRIACAO DA CACHE

e i o c r e a t e ( ) {e i o c l i c r e a t e −d ${ s o u r c e d e v i c e } −s ${ c a c h e d e v i c e } −p ${

c a c h e p o l i c y } −m ${ cache mode} −b ${ c a c h e b l o c k s i z e } −c ${cache name}

echo Cache c r i a d a !

}

# ELIMINACAO DA CACHE

e i o d e l e t e ( ) {e i o c l i d e l e t e −c ${ cache name}echo Cache e l im i n ad a !

}

# DESCOMENTAR O PRETENDIDO

#e i o c r e a t e

#e i o d e l e t e

62

Referencias

[1] Cloud-related spending by businesses to triple from 2011

to 2017. http://press.ihs.com/press-release/design-supply-chain/

cloud-related-spending-businesses-triple-2011-2017. Consultado em Junho de

2014.

[2] Show me the gateway - taking storage to the cloud. http://gigaom.com/2010/06/22/

show-me-the-gateway-taking-storage-to-the-cloud. Consultado em Junho de 2014.

[3] Cloud provider. http://searchcloudprovider.techtarget.com/definition/

cloud-provider. Consultado em Maio de 2014.

[4] Cloud file storage pros and cons. http://searchstorage.techtarget.com/

Cloud-file-storage-pros-and-cons. Consultado em Junho de 2014.

[5] Buying a cloud storage gateway appliance. http://searchcloudstorage.techtarget.

com/feature/Buying-a-cloud-storage-gateway-appliance. Consultado em Junho de

2014.

[6] Cloud storage gateway. http://en.wikipedia.org/wiki/Cloud storage gateway. Con-

sultado em Maio de 2014.

[7] All-in-one cloud storage gateways. http://www.ctera.com/products/products/

cloud-storage-gateways. Consultado em Maio de 2014.

[8] Definition of Cache. http://searchstorage.techtarget.com/definition/cache. Consul-

tado em Abril de 2014.

[9] Definition of Write Back. http://whatis.techtarget.com/definition/write-back. Con-

sultado em Abril de 2014.

63

http://press.ihs.com/press-release/design-supply-chain/cloud-related-spending-businesses-triple-2011-2017

http://press.ihs.com/press-release/design-supply-chain/cloud-related-spending-businesses-triple-2011-2017

http://gigaom.com/2010/06/22/show-me-the-gateway-taking-storage-to-the-cloud

http://gigaom.com/2010/06/22/show-me-the-gateway-taking-storage-to-the-cloud

http://searchcloudprovider.techtarget.com/definition/cloud-provider

http://searchcloudprovider.techtarget.com/definition/cloud-provider

http://searchstorage.techtarget.com/Cloud-file-storage-pros-and-cons

http://searchstorage.techtarget.com/Cloud-file-storage-pros-and-cons

http://searchcloudstorage.techtarget.com/feature/Buying-a-cloud-storage-gateway-appliance

http://searchcloudstorage.techtarget.com/feature/Buying-a-cloud-storage-gateway-appliance

http://en.wikipedia.org/wiki/Cloud_storage_gateway

http://www.ctera.com/products/products/cloud-storage-gateways

http://www.ctera.com/products/products/cloud-storage-gateways

http://searchstorage.techtarget.com/definition/cache

http://whatis.techtarget.com/definition/write-back

REFERENCIAS 64

[10] Definition of Write Through. http://whatis.techtarget.com/definition/

write-through. Consultado em Abril de 2014.

[11] Advanced hard drive caching techniques. http://porky.linuxjournal.com:8080/LJ/

233/11481.html. Consultado em Marco de 2014.

[12] SSDs vs. Hard Drives vs. Hybrids: Which storage tech

is right for you? http://www.pcworld.com/article/2025402/

ssds-vs-hard-drives-vs-hybrids-which-storage-tech-is-right-for-you-.html.

Consultado em Abril de 2014.

[13] A Bcache update. http://lwn.net/Articles/497024. Consultado em Novembro de

2013.

[14] EnhanceIO SSD cache software technical overview.

https://www.yumpu.com/en/document/view/10896725/

enhanceiotm-ssd-cache-software-technical-overview-stec-inc. Consultado em

Maio de 2014.

[15] Bcache. http://bcache.evilpiepirate.org. Consultado em Novembro de 2013.

[16] EnhanceIO. https://github.com/stec-inc/EnhanceIO. Consultado em Novembro de

2013.

[17] Why sequential IO bypass feature removed in enhanceIO. https://github.com/

stec-inc/EnhanceIO/issues/55. Consultado em Novembro de 2013.

[18] FIO. http://freecode.com/projects/fio. Consultado em Novembro de 2013.

[19] FIO - flexible I/O tester synthetic benchmark. http://www.storagereview.com/fio

flexible i o tester synthetic benchmark. Consultado em Novembro de 2013.

[20] Bonnie++. http://www.coker.com.au/bonnie++. Consultado em Maio de 2014.

[21] Simple disk benchmarking in linux using ‘dd’. http://systembash.com/content/

simple-disk-benchmarking-in-linux-using-dd. Consultado em Maio de 2014.

[22] Ceph. http://ceph.com. Consultado em Marco de 2014.

[23] Ceph distributed network file system. http://archive.today/JrXgq. Consultado em

Abril de 2014.

http://whatis.techtarget.com/definition/write-through

http://whatis.techtarget.com/definition/write-through

http://porky.linuxjournal.com:8080/LJ/233/11481.html

http://porky.linuxjournal.com:8080/LJ/233/11481.html

http://www.pcworld.com/article/2025402/ssds-vs-hard-drives-vs-hybrids-which-storage-tech-is-right-for-you-.html

http://www.pcworld.com/article/2025402/ssds-vs-hard-drives-vs-hybrids-which-storage-tech-is-right-for-you-.html

http://lwn.net/Articles/497024

https://www.yumpu.com/en/document/view/10896725/enhanceiotm-ssd-cache-software-technical-overview-stec-inc

https://www.yumpu.com/en/document/view/10896725/enhanceiotm-ssd-cache-software-technical-overview-stec-inc

http://bcache.evilpiepirate.org

https://github.com/stec-inc/EnhanceIO

https://github.com/stec-inc/EnhanceIO/issues/55

https://github.com/stec-inc/EnhanceIO/issues/55

http://freecode.com/projects/fio

http://www.storagereview.com/fio_flexible_i_o_tester_synthetic_benchmark

http://www.storagereview.com/fio_flexible_i_o_tester_synthetic_benchmark

http://www.coker.com.au/bonnie++

http://systembash.com/content/simple-disk-benchmarking-in-linux-using-dd

http://systembash.com/content/simple-disk-benchmarking-in-linux-using-dd

http://ceph.com

http://archive.today/JrXgq

REFERENCIAS 65

[24] Ceph architecture. http://ceph.com/docs/master/architecture. Consultado em

Abril de 2014.

[25] POSIX (Portable Operating System Interface). http://searchenterpriselinux.

techtarget.com/definition/POSIX. Consultado em Maio de 2014.

[26] Intro to Ceph. http://ceph.com/docs/master/start/intro. Consultado em Abril de

2014.

[27] CRUSH (Controlled Replication Under Scalable Hashing). http://whatis.techtarget.

com/definition/CRUSH-Controlled-Replication-Under-Scalable-Hashing. Consul-

tado em Maio de 2014.

[28] Pulling apart Ceph’s CRUSH algorithm. http://www.anchor.com.au/blog/2013/

02/pulling-apart-cephs-crush-algorithm. Consultado em Maio de 2014.

[29] Ceph placement groups. http://ceph.com/docs/master/rados/operations/

placement-groups. Consultado em Maio de 2014.

[30] Official GlusterFS. https://www.gluster.org. Consultado em Marco de 2014.

[31] “Cloud storage for modern data center - an introduction to gluster architecture,”

2011.

[32] GlusterFS. http://en.wikipedia.org/wiki/GlusterFS. Consultado em Marco de 2014.

[33] LUKS. https://code.google.com/p/cryptsetup. Consultado em Maio de 2014.

[34] C. Fruhwirth, “Luks on-disk format specification,” 2011.

[35] C. Fruhwirth, “New methods in hard disk encryption,” 2005.

[36] dm-crypt/device encryption. https://wiki.archlinux.org/index.php/Dm-crypt/

Device encryption. Consultado em Junho de 2014.

[37] Linux kernel device mapper - dm-crypt. http://article.gmane.org/gmane.linux.

kernel.device-mapper.dm-crypt/7093. Consultado em Junho de 2014.

[38] dm-crypt: Linux kernel device-mapper crypto target. https://code.google.com/p/

cryptsetup/wiki/DMCrypt. Consultado em Maio de 2014.

[39] iSCSI: O que e e para que serve. Consultado em Junho de 2014.

http://ceph.com/docs/master/architecture

http://searchenterpriselinux.techtarget.com/definition/POSIX

http://searchenterpriselinux.techtarget.com/definition/POSIX

http://ceph.com/docs/master/start/intro

http://whatis.techtarget.com/definition/CRUSH-Controlled-Replication-Under-Scalable-Hashing

http://whatis.techtarget.com/definition/CRUSH-Controlled-Replication-Under-Scalable-Hashing

http://www.anchor.com.au/blog/2013/02/pulling-apart-cephs-crush-algorithm

http://www.anchor.com.au/blog/2013/02/pulling-apart-cephs-crush-algorithm

http://ceph.com/docs/master/rados/operations/placement-groups

http://ceph.com/docs/master/rados/operations/placement-groups

https://www.gluster.org

http://en.wikipedia.org/wiki/GlusterFS

https://code.google.com/p/cryptsetup

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption

https://wiki.archlinux.org/index.php/Dm-crypt/Device_encryption

http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7093

http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/7093

https://code.google.com/p/cryptsetup/wiki/DMCrypt

https://code.google.com/p/cryptsetup/wiki/DMCrypt

REFERENCIAS 66

[40] iSCSI (Internet Small Computer System Interface). http://searchstorage.techtarget.

com/definition/iSCSI. Consultado em Junho de 2014.

[41] What is file level storage vs. block level storage? http://www.iscsi.com/resources/

File-Level-Storage-vs-Block-Level-Storage.asp. Consultado em Junho de 2014.

[42] Bcache documentation). http://evilpiepirate.org/git/linux-bcache.git/tree/

Documentation/bcache.txt?h=bcache-dev#n126. Consultado em Novembro de

2013.

[43] GlusterFS: First impressions. http://liquidat.wordpress.com/2013/03/04/

glusterfs-first-impressions/. Consultado em Abril de 2014.

[44] GlusterFS iSCSI. http://www.gluster.org/community/documentation/index.php/

GlusterFS iSCSI. Consultado em Marco de 2014.

[45] Ceph storage - Next big thing. http://karan-mj.blogspot.pt/2013/12/

ceph-storage-part-2.html. Consultado em Marco de 2014.

[46] Repositorio Ceph extras. http://ceph.com/packages/ceph-extras/rpm/fedora19/

x86 64/scsi-target-utils-1.0.38-48.bf6981.ceph.fc19.x86 64.rpm. Consultado em

Marco de 2014.

[47] Ceph OSD config reference. https://ceph.com/docs/master/rados/configuration/

osd-config-ref. Consultado em Abril de 2014.

[48] Ceph and stgt. http://stuartl.longlandclan.yi.org/blog/2014/02/25/ceph-and-stgt.

Consultado em Maio de 2014.

[49] Adding support for rbd to stgt. https://ceph.com/dev-notes/

adding-support-for-rbd-to-stgt. Consultado em Maio de 2014.

[50] Disabling write cache. http://osdir.com/ml/linux.iscsi.tgt.devel/2008-06/

msg00022.html. Consultado em Maio de 2014.

[51] tgt-admin source code. https://github.com/fujita/tgt/blob/master/scripts/

tgt-admin. Consultado em Maio de 2014.

[52] CentOS 6 iSCSI tgtd target setup and performance adjustments. http://

www.dbarticles.com/centos-6-iscsi-tgtd-setup-and-performance-adjustments. Con-

sultado em Maio de 2014.

http://searchstorage.techtarget.com/definition/iSCSI

http://searchstorage.techtarget.com/definition/iSCSI

http://www.iscsi.com/resources/File-Level-Storage-vs-Block-Level-Storage.asp

http://www.iscsi.com/resources/File-Level-Storage-vs-Block-Level-Storage.asp

http://evilpiepirate.org/git/linux-bcache.git/tree/Documentation/bcache.txt?h=bcache-dev#n126

http://evilpiepirate.org/git/linux-bcache.git/tree/Documentation/bcache.txt?h=bcache-dev#n126

http://liquidat.wordpress.com/2013/03/04/glusterfs-first-impressions/

http://liquidat.wordpress.com/2013/03/04/glusterfs-first-impressions/

http://www.gluster.org/community/documentation/index.php/GlusterFS_iSCSI

http://www.gluster.org/community/documentation/index.php/GlusterFS_iSCSI

http://karan-mj.blogspot.pt/2013/12/ceph-storage-part-2.html

http://karan-mj.blogspot.pt/2013/12/ceph-storage-part-2.html

http://ceph.com/packages/ceph-extras/rpm/fedora19/x86_64/scsi-target-utils-1.0.38-48.bf6981.ceph.fc19.x86_64.rpm

http://ceph.com/packages/ceph-extras/rpm/fedora19/x86_64/scsi-target-utils-1.0.38-48.bf6981.ceph.fc19.x86_64.rpm

https://ceph.com/docs/master/rados/configuration/osd-config-ref

https://ceph.com/docs/master/rados/configuration/osd-config-ref

http://stuartl.longlandclan.yi.org/blog/2014/02/25/ceph-and-stgt

https://ceph.com/dev-notes/adding-support-for-rbd-to-stgt

https://ceph.com/dev-notes/adding-support-for-rbd-to-stgt

http://osdir.com/ml/linux.iscsi.tgt.devel/2008-06/msg00022.html

http://osdir.com/ml/linux.iscsi.tgt.devel/2008-06/msg00022.html

https://github.com/fujita/tgt/blob/master/scripts/tgt-admin

https://github.com/fujita/tgt/blob/master/scripts/tgt-admin

http://www.dbarticles.com/centos-6-iscsi-tgtd-setup-and-performance-adjustments

http://www.dbarticles.com/centos-6-iscsi-tgtd-setup-and-performance-adjustments

REFERENCIAS 67

[53] How to optimize iSCSI performance. http://capitoshka.blogspot.com/2012/04/

how-to-optimize-iscsi-performance.html. Consultado em Maio de 2014.

[54] Data encapsulation, Protocol Data Units (PDUs) and Ser-

vice Data Units (SDUs). http://www.tcpipguide.com/free/t

DataEncapsulationProtocolDataUnitsPDUsandServiceDa-2.htm. Consultado

em Maio de 2014.

[55] Understanding the iSCSI protocol for performance tuning. http://utcc.utoronto.ca/

∼cks/space/blog/tech/UnderstandingiSCSIProtocol. Consultado em Maio de 2014.

[56] Maxoutstandingr2t iSCSI parameter and its influence on performance in case of high

latency links. http://scst.sourceforge.net/max outstanding r2t.txt. Consultado em

Maio de 2014.

[57] Ready to transfer (R2T) PDU. http://my.safaribooksonline.com/book/

operating-systems-and-server-administration/storage-systems/020178419x/

iscsi-function-pdus/app01lev1sec9. Consultado em Maio de 2014.

[58] iSCSI technical white paper. http://www.diskdrive.com/iSCSI/reading-room/

white-papers/Nishan iSCSI Technical White Paper.pdf. Consultado em Maio de

2014.

[59] iSCSI name structure. http://tools.ietf.org/html/rfc3720#section-3.2.6.3. Consul-

tado em Maio de 2014.

[60] Performance of read-write throughput with iSCSI. http://www.monperrus.net/

martin/performance+of+read-write+throughput+with+iscsi. Consultado em Maio

de 2014.

[61] I/O scheduling for SAN and virtualization. http://www.monperrus.net/martin/

IO+scheduling+for+san+and+virtualization. Consultado em Maio de 2014.

[62] Queue sysfs files. https://www.kernel.org/doc/Documentation/block/queue-sysfs.

txt. Consultado em Maio de 2014.

[63] Tunando a transferencia de dados com o nr request e o read ahead kb. http://

ubuntuforum-br.org/index.php/topic,87597.0.html. Consultado em Abril de 2014.

[64] How secure is AES against brute force attacks? http://www.eetimes.com/

document.asp?doc id=1279619. Consultado em Maio de 2014.

http://capitoshka.blogspot.com/2012/04/how-to-optimize-iscsi-performance.html

http://capitoshka.blogspot.com/2012/04/how-to-optimize-iscsi-performance.html

http://www.tcpipguide.com/free/t_DataEncapsulationProtocolDataUnitsPDUsandServiceDa-2.htm

http://www.tcpipguide.com/free/t_DataEncapsulationProtocolDataUnitsPDUsandServiceDa-2.htm

http://utcc.utoronto.ca/~cks/space/blog/tech/UnderstandingiSCSIProtocol

http://utcc.utoronto.ca/~cks/space/blog/tech/UnderstandingiSCSIProtocol

http://scst.sourceforge.net/max_outstanding_r2t.txt

http://my.safaribooksonline.com/book/operating-systems-and-server-administration/storage-systems/020178419x/iscsi-function-pdus/app01lev1sec9



http://www.diskdrive.com/iSCSI/reading-room/white-papers/Nishan_iSCSI_Technical_White_Paper.pdf

http://www.diskdrive.com/iSCSI/reading-room/white-papers/Nishan_iSCSI_Technical_White_Paper.pdf

http://tools.ietf.org/html/rfc3720#section-3.2.6.3

http://www.monperrus.net/martin/performance+of+read-write+throughput+with+iscsi

http://www.monperrus.net/martin/performance+of+read-write+throughput+with+iscsi

http://www.monperrus.net/martin/IO+scheduling+for+san+and+virtualization

http://www.monperrus.net/martin/IO+scheduling+for+san+and+virtualization

https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt

https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt

http://ubuntuforum-br.org/index.php/topic,87597.0.html

http://ubuntuforum-br.org/index.php/topic,87597.0.html

http://www.eetimes.com/document.asp?doc_id=1279619

http://www.eetimes.com/document.asp?doc_id=1279619

REFERENCIAS 68

[65] Linux memory management – swapping, caches and shared vm. http://www.

thegeekstuff.com/2012/02/linux-memory-swap-cache-shared-vm. Consultado em

Maio de 2014.

[66] EnhanceIO. https://github.com/stec-inc/EnhanceIO/blob/master/README.txt.

Consultado em Maio de 2014.

http://www.thegeekstuff.com/2012/02/linux-memory-swap-cache-shared-vm

http://www.thegeekstuff.com/2012/02/linux-memory-swap-cache-shared-vm

https://github.com/stec-inc/EnhanceIO/blob/master/README.txt

NASCloud – CachingSSD e cifra local para dispositivos de Storage na CloudMiguel José Costa Soá LoboDissertação de Mestrado apresentada à

Faculdade de Ciências da Universidade do Porto em

Ciência de Computadores

2014

NA

SC

lou

d–

Ca

ch

ing

SS

D e

cifra

loca

l para

dis

po

sitiv

os d

e S

tora

ge

na C

lou

dM

igu

el J

osé C

osta

So

áL

ob

oM

Sc

FCUP

2014

2.º

CICLO

NASCloud SSD e cifra local para dispositivos de Storage na ... · SSD e cifra local para...

Documents

Transcript of NASCloud SSD e cifra local para dispositivos de Storage na ... · SSD e cifra local para...