NASCloud - Caching SSD e cifra local para dispositivos de Storage na Cloud

Texto

(1)MSc 2.º CICLO FCUP 2014. NASCloud – Caching SSD e cifra local para dispositivos de Storage na Cloud. NASCloud – Caching SSD e cifra local para dispositivos de Storage na Cloud Miguel José Costa Soá Lobo Dissertação de Mestrado apresentada à Faculdade de Ciências da Universidade do Porto em Ciência de Computadores. 2014. Miguel José Costa Soá Lobo.

(2) NASCloud – Caching SSD e cifra local para dispositivos de Storage na Cloud Miguel José Costa Soá Lobo Mestrado Integrado em Engenharia de Redes e Sistemas Informáticos Departamento de Ciência dos Computadores 2014. Orientador Manuel Eduardo Correia, Faculdade de Ciências da Universidade do Porto. Coorientador Hugo Ribeiro, Faculdade de Ciências da Universidade do Porto.

(3) Todas as correções determinadas pelo júri, e só essas, foram efetuadas.. O Presidente do Júri,. Porto, ______/______/_________.

(4) Miguel Jos´ e Costa So´ a Lobo. NASCloud – Caching SSD e cifra local para dispositivos de Storage na cloud. Departamento de Ciˆ encia de Computadores Faculdade de Ciˆ encias da Universidade do Porto 27 de Junho de 2014.

(5) Miguel Jos´ e Costa So´ a Lobo. NASCloud – Caching SSD e cifra local para dispositivos de Storage na cloud. Relat´ orio de Est´ agio submetido ` a Faculdade de Ciências da Universidade do Porto como parte dos requisitos para a obten¸c˜ ao do grau de Mestre em Engenharia de Redes e Sistemas Inform´ aticos. Orientador: Manuel Eduardo Correia Co-orientador: Hugo Ribeiro. Departamento de Ciência de Computadores Faculdade de Ciências da Universidade do Porto 27 de Junho de 2014.

(6) dedicado ` as pessoas mais importantes da minha vida. i.

(7) Agradecimentos Ao longo deste est´ agio houve alguns momentos em que foi essencial um pequeno empurrão. Gostaria de agradecer a todos os que me motivaram, ajudaram e que estavam lá no momento certo. Come¸co por agradecer ao orientador de estágio, Manuel Eduardo Correia, pela oportunidade 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 estágio, Hugo Ribeiro. Agrade¸co por toda a ajuda, aten¸c˜ ao e disponibilidade dispensada, e pelo conhecimento que me transmitiu. Considero que foi um elemento essencial para a realiza¸cão deste projecto e pelo meu enriquecimento profissional, e por isso estou-lhe imensamente grato. Agrade¸co a uma boa parte dos professores da Faculdade de Ciências, principalmente aos professores do DCC, pelo facto de fazerem parte da minha carreira académica 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 necessários à minha forma¸c˜ ao. N˜ ao podia deixar de agradecer à minha irmã, que ao longo destes anos esteve sempre dispon´ıvel para me ouvir e para me dar a for¸ca necessária. Agrade¸co 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, M´ ario Pinto, Pedro Oliveira, Pedro Ramalho, Gon¸calo Martins, Zé Carlos e Lu´ıs Moreira, por toda a amizade, ajuda e companheirismo. Last but not the least, um agradecimento especial à 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.

(8) Resumo A decisão das empresas aderirem ` a Cloud deve-se principalmente a motivos financeiros. Estas precisavam de adquirir o seu próprio hardware, cujo valor diminui com o passar do tempo, e a performance, quando comparada com equipamentos mais recentes, é 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 espa¸co disponibilizado pelos Cloud Provider s normalmente é feito através de Application Programming Interface (API)s próprias. Para que esse espa¸co seja disponibilizado aos utilizadores das empresas, de uma forma fácil e transparente, é necessário o uso v´ arias ferramentas/softwares. O Cloud Storage Gateway (CSG) pretende desempenhar o papel de mediador entre o fornecedor de espa¸co na Cloud e os seus utilizadores, através de métodos e protocolos de rede j´ a conhecidos e com implementa¸cões robustas. O objectivo principal deste projecto é a cria¸cão de uma appliance local, que irá acelerar o acesso ao espa¸co de armazenamento importado da Cloud, sob a forma de dispositivos de blocos. Esta appliance é toda baseada em software Open-Source. A acelera¸c˜ ao é feita através do uso de software que providencia mecanismos de cache local e discos Solid-State Drive (SSD). Juntamente com a acelera¸cão de dispositivos de blocos, de modo a se poder garantir a confidencialidade dos dados que são guardados na Cloud, os dispositivos de blocos importados serão cifrados localmente, para que assim desta forma os dados escritos passem sempre cifrados, e de forma transparente para a Cloud.. iii.

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

(10) Conteu ´do Resumo. iii. Abstract. iv. Lista de Tab elas. viii. Lista de Figuras. ix. 1 Intro duc ¸˜ ao. 3. 1.1. Objectivos do projecto . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 4. 1.2. Estrutura do relato ´rio . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 5. 2 Software/Tecnologias utilizadas 2.1. Sistemas de cache. 7. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 2.1.1. Pol´ıticas de cache. 2.1.2. Softwares de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . 10. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 8. 2.2. Software de ana ´lise de performance/benchmark . . . . . . . . . . . . . . . 11. 2.3. Sistemas de Ficheiros Distribu´ıdo na Cloud . . . . . . . . . . . . . . . . . 12. 2.4. LUKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15. 2.5. iSCSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 v.

(11) 2.6. LVM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19. 3 Desenvolvimento. 20. 3.1. Cen´ arios de teste . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21. 3.2. FIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. 3.3. Software de cache . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25. 3.4. Ceph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26. 3.5. 3.4.1. Cen´ ario Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28. 3.4.2. Cen´ ario Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31. 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 4.1. 4.2. 41. 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. Testes de Integridade de dados . . . . . . . . . . . . . . . . . . . . . . . . 49 4.2.1. 1o Cen´ ario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50. 4.2.2. 2o Cen´ ario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 vi.

(12) 4.2.3. 3o Cen´ ario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52. 5 Conclus˜ oes. 55. 5.1. Discuss˜ ao de Resultados . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55. 5.2. Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57. A Script FIO. 58. B Script BCache. 60. C Script EnhanceIO. 62. Referˆ encias. 63. vii.

(13) Lista de Tabelas 2.1. Header da parti¸c˜ ao LUKS . . . . . . . . . . . . . . . . . . . . . . . . . . . 16. 2.2. Composi¸c˜ ao de um key-slot . . . . . . . . . . . . . . . . . . . . . . . . . . 16. 4.1. Tabela de Estados EnhanceIO . . . . . . . . . . . . . . . . . . . . . . . . . 50. viii.

(14) Lista de Figuras 3.1. NASCloud - Caso Base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21. 3.2. NASCloud - Cen´ ario Base com acelera¸cão local . . . . . . . . . . . . . . . 22. 3.3. NASCloud - Cen´ ario Base com falha na acelera¸cão local . . . . . . . . . . 22. 3.4. NASCloud - Cen´ ario Final . . . . . . . . . . . . . . . . . . . . . . . . . . . 23. 3.5. Diagrama Ceph - cen´ ario 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 - Cen´ ario real . . . . . . . . . . . . . . . . . . . . . . . . . 32. 4.1. Gr´ afico comparativo caso base . . . . . . . . . . . . . . . . . . . . . . . . . 43. 4.2. Gr´ afico comparativo Bloco Ceph vs Bloco Ceph+EnhanceIO WB/WT Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44. 4.3. Gr´ afico comparativo Bloco Ceph vs Bloco Ceph+EnhanceIO WB/WT Real . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45. 4.4. Gr´ afico comparativo Bloco Ceph vs Bloco Ceph+EnhanceIO WB/WT Real vs Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46. 4.5. Gr´ afico comparativo Bloco Cloud vs Bloco Cloud+EnhanceIO WB/WT - Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47. 4.6. Gr´ afico comparativo Bloco Cloud+EIO WB+RAID1+LUKS+LVM - Real vs Virtual . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 ix.

(15) Acr´ onimos 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.

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

(17) Cap´ıtulo 1. Introdu¸ c˜ ao A decisão das empresas aderirem ` a Cloud deve-se principalmente a motivos financeiros. Estas precisavam de adquirir o seu próprio 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 é uma empresa ou entidade que fornece aos seus clientes espa¸co de armazenamento e/ou servi¸cos (Infrastructure as a Service (IaaS), Software as a Service (SaaS) ou Platform as a Service (PaaS)), através de uma rede p´ ublica (Cloud ) ou privada (Cloud privada) [3]. O acesso ao espa¸co disponibilizado pelos Cloud Providers normalmente é feito através de APIs! (APIs!) pr´ oprias. Para que esse espa¸co seja disponibilizado aos utilizadores das empresas, de uma forma f´ acil e transparente, é necessário o uso de várias ferramentas/softwares. No projecto NASCloud pretende-se definir um Cloud Storage Gateway (CSG), que desempenhar´ a o papel de mediador entre o fornecedor de espa¸co na Cloud e os seus utilizadores, através de métodos e protocolos de rede já conhecidos e com implementa¸cões 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 é a possibilidade de ter m´ ultiplos fornecedores de armazenamento na Cloud e não estar dependente de somente um. Deste modo é poss´ıvel adicionar mais resiliência aos dados que serão armazenados. 3.

(18) ˜ CAPÍTULO 1. INTRODUC ¸ AO. 4. [2] utilizando redundˆ ancia e backups, por exemplo. O uso da solu¸c˜ ao proposta traz vantagens tanto aos fornecedores de espa¸co na Cloud, assim como ` as empresas que os contratam. Os Cloud Storage Providers têm a oportunidade de aumentar o alcance dos seus servi¸cos, enquanto que os clientes finais, que são 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/localiza¸c˜ ao; • Custo: o armazenamento na Cloud permite reduzir os custos associados aos backups dos dados, j´ a que deixa de haver necessidade de aquisi¸cão de equipamento para a fun¸c˜ ao, os backups s˜ ao feitos directamente para a Cloud ; • Seguran¸ca e recupera¸c˜ ao de dados: os dados armazenados nos Cloud Providers são cifrados quer durante a transmissão entre o cliente e os Providers, quer enquanto estes estiverem armazenados. Em caso de perda de dados, a sua recupera¸cão é facilitada devido aos backups efectuados pelos Cloud Providers. O uso de um CSG na estrutura informática 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 é a cria¸cão de uma appliance local, que vai acelerar o acesso ao espa¸co de armazenamento importado da Cloud, sob a forma de dispositivos de blocos, via iSCSI. Essa acelera¸c˜ ao é feita recorrendo a mecanismos de cache local e discos SSD. Juntamente com a acelera¸c˜ ao de dispositivos de blocos, de modo a garantir a confidencialidade dos dados, os dispositivos de blocos ser˜ ao 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 seguran¸ca dos dados e com performances apropriadas, a serem utilizadas para aplica¸cões e armazenamento na rede..

(19) ˜ CAPÍTULO 1. INTRODUC ¸ AO. 5. Um CSG é uma ferramenta de rede que fornece conectividade e servi¸cos de tradu¸cão de protocolos entre um Cloud Storage Provider e aplica¸cões locais. A sua implementa¸cão é feita numa m´ aquina local, para facilitar a implementa¸cão de seguran¸ca dos dados e a transferência de dados entre protocolos incompat´ıveis. Um CSG é projectado para oferecer interoperabilidade entre diferentes protocolos de transferência de dados usados em arquitecturas cliente/servidor. Este permite a tradu¸cão 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 é providenciado por um servi¸co Ceph, e esse armazenamento é exposto via iSCSI para o CSG. A instala¸cão e configura¸cão de um cluster Ceph está presente nos objectivos do projecto, assim como o estabelecimento de conexões iSCSI entre as v´ arias tecnologias utilizadas no projecto. Outro dos objectivos passa por determinar a aplica¸cão e localiza¸cão da camada de encripta¸c˜ ao, 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 abstra¸cão à cache local. De modo a atingir o ponto de equil´ıbrio e melhor compromisso entre fiabilidade, seguran¸ca dos dados e velocidades de acesso, faz parte dos objectivos do projecto executar vários testes de benchmark, e ajustar as defini¸cões e configura¸cões de acordo com os resultados obtidos. Dos objectivos do projecto fazem ainda parte a testar a reexporta¸cão 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 relat´ orio. Este relat´ orio est´ a composto por cinco cap´ıtulos. No presente cap´ıtulo é feita uma introdu¸c˜ ao a v´ arios conceitos importantes que foram abordados ao longo do estágio ´ efectuado. E também feita uma breve descri¸cão da motiva¸cão para realiza¸cão do projecto, e são apresentados os objectivos do mesmo..

(20) ˜ CAPÍTULO 1. INTRODUC ¸ AO. 6. No Cap´ıtulo 2 é apresentada uma descri¸cão dos softwares e tecnologias utilizadas para a realiza¸c˜ ao e conclus˜ ao deste projecto. São explicadas as caracter´ısticas de cada componente utilizado e o seu modo de funcionamento. No Cap´ıtulo 3 é demonstrada a interliga¸cão entre os vários elementos utilizados no projecto (Ceph, iSCSI, softwares de cache), juntamente com os procedimentos e passos que foram executados para a instala¸cão e configura¸cão dos softwares utilizados. No Cap´ıtulo 4 s˜ ao apresentados os testes e respectivos resultados, que foram feitos ao longo de todo o processo de constru¸cão da appliance. Os testes apresentados são sobre a performance de leitura/escrita e sobre a integridade dos dados, em situa¸cão normal de funcionamento e situa¸c˜ oes de falhas de componentes/conexões. Por fim, no Cap´ıtulo 5, s˜ ao apresentadas as principais conclusões do projecto NASCloud e uma descri¸c˜ ao do trabalho futuro/melhoramentos a serem feitos. São também apresentados poss´ıveis cenários onde todo o trabalho efectuado poderá ser aplicado com sucesso..

(21) Cap´ıtulo 2. Software/Tecnologias utilizadas Neste cap´ıtulo ser˜ ao apresentados os softwares explorados para a constru¸cão do protótipo de uma appliance CSG. De referir que todo o software utilizado é gratuito e OpenSource. Este cap´ıtulo é composto pela apresenta¸cão aos sistemas de cache, onde é explicado o que são, como é o seu funcionamento e quais os softwares decache utilizados no âmbito do projecto. Também s˜ ao apresentados vários softwares de benchmark a sistemas, juntamente com a defini¸c˜ ao de benchmark e qual a sua fun¸cão. Outro tópico deste cap´ıtulo é relativo ao software Ceph. Aqui é explicado o que é o Ceph, qual as fun¸c˜ oes que este pode desempenhar e as vantagens que a sua utiliza¸cão traz. Desde sempre a seguran¸ca da informa¸cão é um assunto sens´ıvel e importante. No tópico relativo ao LUKS é apresentado o software escolhido para cifrar os dados a serem transferidos para a Cloud. No tópico sobre LVM, é explicada o que é, para que serve e quais são os elementos que compõe esta ferramenta de gest˜ ao de volumes lógicos no Linux.. 2.1. Sistemas de cache. Entende-se por cache uma localiza¸cão onde armazenar algo temporariamente, de modo a reduzir o tempo de acesso aparente ao armazenamento principal. Por exemplo, quando se consulta uma p´ agina de Internet, os ficheiros descarregados são guardados no disco r´ıgido, numa pasta de cache. Quando mais tarde se retorna a essa página consultada, 7.

(22) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 8. se a cache ainda estiver v´ alida, 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 poupan¸ca de tempo e recursos (ex. largura de banda). Os sistemas inform´ aticos utilizam cache em vários n´ıveis de opera¸cão. Alguns exemplos onde o uso de cacheé aplicado s˜ ao 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 cópias dos dados que foram mais recentemente utilizados, para um posterior acesso mais rápido a estes; • Mem´ oria RAM: também pode ser vista como um dispositivo de cache, onde os dados est˜ ao carregados, para um acesso mais rápido; • Cache L1 e L2: mem´ orias cache que estão localizadas no mesmo chip que o CPU. Uma cache é composta por um conjunto de entradas. Cada uma destas entradas contém dados, que s˜ ao c´ opias dos dados existentes no seu local de origem, e também uma tag, que identifica os dados presentes na entrada em questão e a localiza¸cão destes no dispositivo de armazenamento original. Quando um cliente da cache precisa de aceder aos dados existentes na localiza¸cão de armazenamento, primeiro consulta a sua cache, para verificar se os dados em questão estão lá dispon´ıveis. Se for encontrada uma entrada com os dados requisitados, então estes são retornados ao cliente, o que se denomina por ”Cache Hit”. No caso contrário, em que n˜ ao se encontra nenhuma entrada na cache com os dados pedidos, durante o processo de leitura dos dados para os retornar ao cliente , estes são então lidos e copiados para a cache, para um posterior acesso mais rápido. A esta situa¸cão chama-se ”Cache Miss”.. 2.1.1. Pol´ıticas de cache. Uma pol´ıtica de cache é um conjunto de regras que são usadas para determinar se um pedido pode ser satisfeito usando uma cópia armazenada em cache do recurso solicitado. Existem pol´ıticas de substitui¸c˜ ao de cache e pol´ıticas de escrita..

(23) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 9. Durante o processo de ”Cache Miss”, as entradas da cache vão sendo substitu´ıdas por novas entradas, de modo a actualizar a cache. A forma utilizada para escolher e substituir a entrada a ser trocada é conhecida como pol´ıtica de substitui¸cão. Existem várias pol´ıticas, que seguem algoritmos de substitui¸cão optimizados para a fun¸cão, tais como First In First Out (FIFO), aleat´ orio, Most Recently Used (MRU) ou Least Recently Used (LRU), que normalmente é a mais comum de ser usada. No momento em que os dados s˜ ao escritos na cache, estes também têm de ser escritos no seu local de armazenamento (ex. disco HDD). Esse momento é determinado pela pol´ıtica de cache que est´ a ativa no dispositivo. Existem duas pol´ıticas de cache mais utilizadas [9] [10]: ´ um método de armazenamento em que os dados são escritos na • Write Back : E cache sempre que ocorra alguma altera¸cão, mas são escritos na sua localiza¸cão de armazenamento a partir de um determinado intervalo de tempo definido, ou consoante certas condi¸c˜ oes, tais como quando algum limite de dados presentes na cache é atingido. Quando os dados s˜ ao escritos na cache, estes são diferentes dos que estão na localiza¸c˜ ao de armazenamentos dos dados. Quando esse trigger é ativado, os dados que foram escritos na cache são 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 optimiza¸cão da velocidade do sistema, isto porque é muito mais rápido escrever directamente na cache do que no local de armazenamento. Contudo, aliado a esse aumento de velocidade também existe um maior risco de perda de dados, em caso de crash do sistema ou qualquer outro motivo adverso. Um método de reduzir esse risco de perda de dados é fazer um mirror da cache. Isto permite que, em caso de falha do dispositivo de cache, haja outro pronto a ser usado. Na situa¸cão de um crash do sistema, os softwares de cache tentam recuperar o conte´ udo 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: Método de armazenamento em que os dados são escritos simultaneamente 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 também garante que não existe perda de dados, caso ocorra alguma situa¸c˜ ao não planeada..

(24) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 10. Apesar desta pol´ıtica garantir a inexistência de perda de dados devido à replica¸cão destes em duas localiza¸c˜ oes distintas, tal método torna o processo mais lento. Uma opera¸c˜ ao de escrita de dados só pode prosseguir quando a anterior estiver conclu´ıda, e tal s´ o acontece quando houver confirma¸cão 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 tornouse mais f´ acil e simples de melhorar. Antes desse acontecimento, os métodos utilizados para melhorar as performances de Input/Output (I/O) de armazenamento passavam por caches de baixa capacidade para a memória RAM ou RAM drives [11]. Os tradicionais discos Hard Disk Drive (HDD) fornecem bastante espa¸co de armazenamento (quando comparados com discos SSD), mas o seu desempenho em rela¸cão à velocidade de acesso é baixo. Os discos SSD permitiram reduzir esses tempos de acesso, diminuindo em grande parte essa lacuna. A utiliza¸cão simultânea destes dois discos HDD e SSD permitem também criar um sistema h´ıbrido, que combina o espa¸co de armazenamento do HDD com a velocidade do SSD [12]. O papel do SSD neste novo tipo de sistema é de servir como cache aos dados armazenados no HDD, deixando uma c´ opia dos dados mais usados no SSD, para que o seu acesso seja mais rápido. O objectivo do uso de softwares de cache é tornar o Sistema Operativo (SO) e o acesso aos dados t˜ ao r´ apido 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 opera¸cões de I/O de e para o dispositivo de armazenamento. Desta forma, se um pedido de leitura de dados puder ser satisfeito pelo SSD, não há necessidade de envolver o dispositivo de armazenamento no processo, o que vai agilizar e acelerar o pedido [13] [14]. No âmbito 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 são softwares de cache que actuam sobre blocos de dados, permitindo que um ou mais discos rápidos, tal como discos SSD, fa¸cam cache de outros dispositivos de blocos mais lentos. As principais diferen¸cas entre os dois softwares analisados são as seguintes:.

(25) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 11. • Por defeito, o BCache n˜ ao faz cache de I/O sequenciais mas sim aleatórios, que é o ponto forte dos discos SSD. Já o EnhanceIO já faz cache de todos os I/O, sejam estes sequenciais ou aleat´ orios [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 é formatado com um marcador especial pelo BCache, onde só através do uso do software é poss´ıvel aceder ao seu conte´ udo, utilizando um dispositivo virtual. Esta medida de preven¸c˜ ao permite que evitar que o sistema de ficheiros do dispositivo de armazenamento e os seus dados fiquem corrompidos [13]. • Enquanto que no BCache é necessária a utiliza¸cão de um dispositivo virtual, tal facto n˜ ao acontece com o EnhanceIO. A principal vantagem deste ponto é que torna poss´ıvel adicionar cache a qualquer dispositivo sem que seja necessário desmontá-lo e format´ a-lo.. 2.2. Software de an´ alise de performance/benchmark. Em inform´ atica, benchmark é um teste ou conjunto de testes concebidos para medir e comparar a performance de um determinado elemento ou componente do computador. Um benchmark é concebido para imitar um tipo de workload espec´ıfico para um sistema ou componente. As informa¸c˜ oes mais importantes a retirar dos testes de performance e benchmark de discos r´ıgidos s˜ ao os tempos de latência e as velocidades de leitura e escrita, tanto aleat´ oria como sequencial (dependendo da situa¸cão a ser testada). A performance de um sistema é influenciada pelos seguintes factores: • Velocidade de rota¸c˜ ao do disco r´ıgido; • Tamanho do bloco do sistema de ficheiros; • Tempo de procura; • Tipo de leitura/escrita (sequencial ou aleatório); O software FIO [18] é uma ferramenta que permite gerar pedidos de I/O e é bastante versátil e flex´ıvel. Esta ferramenta pode ser usada tanto para benchmark como para executar stress tests no sistema. Stress tests s˜ ao uma forma de testar a estabilidade do sistema, de uma forma intensa..

(26) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 12. São feitos para levar o sistema ao extremo das suas capacidades, até ao seu ponto de falha. A ideia de conduzir o sistema até este ponto é para se poder determinar quais os seus limites e em que ponto e como falham. Esta ferramenta suporta m´ ultiplos motores de I/O, o que permite simular vários tipos diferentes de input de testes (ex. s´ıncrono, ass´ıncrono), assim como especificar o n´ umero de threads ou processos por teste a executar, tipo de teste (leitura e/ou escrita), entre outros parˆ ametros. O output do FIO é composto por várias informa¸cões de performance, tais como tempos de latência, velocidades m´ aximas, m´ınimas e médias ou tempo que o processo fica na fila de espera para ser processado. O site storagereview.com, s´ıtio de referência em compara¸cões e análise de estat´ısticas e velocidades de discos r´ıgidos, utiliza o FIO como o seu método de benchmarking [19]. Tal como o Flexible I/O (FIO), existem outros softwares semelhantes, como por exemplo o Bonnie++ [20]. O Bonnie++ é 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, n´ umero de pesquisas por segundo e o volume de I/O Operations per Second (IOPS). Outro método de analisar a performance de um sistema é através da ferramenta dd. Esta ferramenta permite fazer c´ opias de e para ficheiros e dispositivos. O seu output é composto pelo n´ umero de blocos transferidos, n´ umero de bytes copiados, o tempo que demorou a opera¸c˜ ao e a velocidade medida. O principal problema desta ferramenta é que não é filesystem independent, isto é, o dd só 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 carreg´ a-lo na memória, o que vai originar valores mais rápidos e não fidedignos [21].. 2.3. Sistemas de Ficheiros Distribu´ıdo na Cloud. Em computa¸c˜ ao Cloud, o armazenamento é considerado um dos problemas mais dif´ıceis de resolver. O armazenamento na Cloud deve ser facilmente escalável e de baixo custo. Contudo deve ser pensado de modo a não menosprezar a fiabilidade ou velocidade, e evitar falhas de hardware ` a medida que o tamanho do cluster aumenta..

(27) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 13. Um sistemas de ficheiros distribu´ıdo na Cloud é um sistema de ficheiros que permite a vários hosts aceder aos mesmos dados simultaneamente. Esses dados podem estar divididos em v´ arias partes, que por sua vez são armazenadas em máquinas distintas, o que facilita o m´ ultiplo acesso aos dados e a execu¸cão paralela de aplica¸cões. De modo a n˜ ao comprometer o acesso e a integridade dos dados armazenados, conceitos como a confidencialidade, disponibilidade e integridade são essenciais para a defini¸cão de um sistema inform´ atico seguro. Hoje em dia, gra¸cas ` a computa¸c˜ ao Cloud, os utilizadores podem partilhar dados a partir de qualquer dispositivo com uma liga¸cão à Internet (ex. Smartphone, Tablet, pc). Isto é poss´ıvel devido ` a facilidade de escalabilidade de recursos dos servidores de um cluster, recursos esses que s˜ ao virtualizados e disponibilizados dinamicamente. Os sistemas de ficheiros distribu´ıdos destacam-se pela forma como lidam com o desempenho do cluster, escritas simultˆ aneas de dados, falhas temporárias ou permanentes de nós ou capacidade de armazenamento no cluster. O Ceph [22] é uma plataforma de armazenamento concebida para fornecer armazenamento de blocos, objectos e ficheiros, a partir de um cluster de computadores. O seu principal objectivo é ser um sistema completamente distribu´ıdo, sem um ponto de falha u ńico (pois os dados guardados no cluster são replicados pelos seus elementos, ´ também facilmente escalável, pois o software tornando-o assim tolerante a falhas [23]). E Ceph pode ser executado em hardware comum, o que desta forma possibilita baixar os custos de implementa¸c˜ ao [24]. O Ceph pode desempenhar v´ arios papéis na rede. Pode fornecer armazenamento de objectos ou dispositivos de blocos para plataformas de Cloud, como por exemplo OpenStack, CloudStack ou OpenNebula, ou funcionar como sistema de ficheiros (Ceph Filesystem). O Ceph Filesystem é um sistema de ficheiros compat´ıvel com POSIX [25], que usa o cluster Ceph para armazenar os seus dados. Um cluster é 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 s´ o é utilizado se o cluster funcionar como Ceph Filesystem [26]. O Ceph OSD daemon (OSD) armazena dados, é responsável pela replica¸cão e recupera¸cão dos dados, rebalanceamento do cluster e providencia informa¸cão de monito-.

(28) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 14. riza¸cão aos Ceph Monitors, ao verificar regularmente o estado dos outros OSDs. O Ceph Monitor (Monitor) mantém 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 está a operar como sistema de ficheiros. O MDS possibilita aos utilizadores do sistema de ficheiros Ceph executar comandos básicos 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 também calcula qual o OSD que vai armazenar esse Placement Group. O Gluster [30] e o Ceph, s˜ ao sistemas de ficheiros distribu´ıdos, facilmente escaláveis e idealizados para serem usados em hardware comum, o que permite baixar os custos de implementa¸c˜ ao e escalabilidade do cluster. A arquitetura do Gluster agrega vários servi¸cos que podem ser disponibilizados numa rede inform´ atica. Esses servi¸cos s˜ ao armazenamento e capacidade de computa¸cão. Cada servidor presente no cluster é considerado um nó, e a capacidade do cluster é escalável ao adicionar mais n´ os a este, ou ao adicionar mais armazenamento ao nó. Consequentemente ao aumento da capacidade do cluster, a sua performance é aumentada com o aumento de armazenamento dispon´ıvel e da rápida disponibilidade dos dados, devido à replica¸cão dos dados entre os n´ os [31]. O algoritmo utilizado pelo Gluster para a gestão dos ficheiros e dados está presente em todos os servidores do cluster, logo não existe servidores com papéis definidos, como por exemplo a gest˜ ao 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 funcionalidades podem passar pela mudan¸ca do método de redundância dos dados, assim como a altera¸cão de como os estes s˜ ao distribu´ıdos pelo cluster [32]..

(29) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 2.4. 15. LUKS. O LUKS [33] é a especifica¸c˜ ao standard para encripta¸cão de discos em Linux. Enquanto que uma grande parte dos softwares de encripta¸cão de discos usam formatos e processos de encripta¸c˜ ao diferentes e incompat´ıveis entre si, o formato utilizado pelo LUKS é universal entre as distribui¸c˜ oes Linux, o que facilita a compatibilidade e interoperabilidade entre diferentes programas. Um disco/dispositivo formatado com o LUKS é composto pelos seguintes campos: LUKS partition header (PHDR), oito seçcões chamadas Key Material, numeradas de 1 a 8, e um campo chamado bulk data, que contém os dados cifrados. O layout da estrutura está 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 até oito passwords que decifram o dispositivo encriptado. O PHDR também contém informa¸cões sobre os key slots, que estão associados aos Key Material, que se encontram a seguir ao PHDR. Quando um key slot est´ a activo, isto é, tem uma password associada ao dispositivo cifrado, é guardada uma c´ opia da Master Key no Key Material correspondente, estando este encriptado com uma password. Fornecer essa password permite a desencripta¸cão 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 parˆ ametros necessários para decifrar o seu Key Material com uma determinada password est˜ ao guardados no PHDR. Na tabela 2.1 est´ a representado o layout do campo PHDR, que se encontra no in´ıcio de uma parti¸c˜ ao formatada com LUKS. O header pode ser dividido em duas partes: a primeira parte é composta pelas informa¸cões necess´ arias para decifrar a bulk data, parte essa composta pelos campos ciphername, cipher-mode, payload-offset e pelo campo key-bytes. A segunda parte é usada para a verifica¸cão dos candidatos a master-key (mk-digest, mk-digest-salt e mk-digest-iter ). Cada key-slot contém informa¸c˜ ao relativa ao processo de decifrar o Key Material. Como já descrito acima, o key-slot refere-se a uma cópia da Master Key, que está guardada.

(30) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS Campo. 16. Descri¸ c˜ ao. magic. Valor do campo ”magic”para o header do LUKS. version. Vers˜ ao do LUKS. cipher-name. Nome da cifra. cipher-mode. Modo da cifra. hash-spec. Especifica¸cões da hash. payload-offset. In´ıcio da bulk data. key-bytes. N´ umero de bytes na chave. mk-digest. Checksum da master key. mk-digest-salt. ”Sal”usado para determinar o mk-digest. mk-digest-iter. N´ umero de itera¸cões para calcular o mk-digest. uuid. UUID (Universal Unique Identifier ) da parti¸cão. key-slot-1. Key Slot 1. key-slot-2. Key Slot 2. .... .... key-slot-8. Key Slot 8 Tabela 2.1: Header da parti¸cão LUKS. no Key Material, que por sua vez está cifrado por uma password. Uma descri¸cão da composi¸c˜ ao do key-slot est´ a representada na tabela 2.2. Campo. Descri¸ c˜ ao. active. Estado da key slot. iterations. N´ umero de itera¸cões para cifrar a password. salt. ”Sal”para a cifra da password. key-material-offset. Indica¸c˜ ao do sector inicial do Key Material correspondente. stripes. N´ umero de stripes usados pelo processo de cifra Tabela 2.2: Composi¸cão de um key-slot. Como o LUKS guarda a informa¸c˜ ao de setup no header da parti¸cão cifrada, isto permite que, por exemplo, se cifre uma pen num computador, e seja poss´ıvel aceder ao seu conte´ udo noutro [33] [34]. Um exemplo do comando e respectivos switches para formatar um dispositivo com LUKS está descrito no comando abaixo indicado [36]:.

(31) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 17. 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 são descritos da seguinte forma: • --cipher aes-xts-plain64: Indica qual a cifra que irá ser utilizada para encriptar o dispositivo; • --key--size 256: O tamanho da chave a ser utilizada. Por omissão, o LUKS utiliza chaves de tamanho 256 bit; • --hash sha1: O algoritmo de hash usado; Desde Janeiro de 2014, o algoritmo SHA1 é 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 cria¸c˜ ao da Master Key do dispositivo LUKS; • --verify-passphrase: Switch que obriga a reinser¸cão da palavra-passe, como método de confirma¸c˜ ao durante o processo de cria¸cão da parti¸cão LUKS; Por omiss˜ ao, o comando cryptsetup -v luksFormat <dispositivo> substitui todas as op¸cões dos switches acima descritos. Apesar de, por omiss˜ ao, o LUKS usar a cifra AES, com o modo xts-plain64, e usar o algoritmo de hash SHA1, estes parˆ ametros podem ser modificados. Para cifras utilizadas, o LUKS suporta as seguintes: AES, twofish, serpent, cast5 e cast6. Em rela¸c˜ ao 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 é o modo usado por omiss˜ ao. Quanto aos valores utilizados para o switch relativo à hash, podem ser os seguintes: sha1, sha256, sha512 e finalmente ripemd160 [34]. Não existe uma combina¸c˜ ao ideal entre cifras, modos e hashs a serem usados no momento de cria¸cão do dispositivo cifrado, logo torna-se necessário adaptar a for¸ca da cifra, e a dificuldade existente para a quebrar, de acordo com o tipo de informa¸cão que se pretende armazenar no dispositivo. O LUKS tem como base uma vers˜ ao melhorada do cryptsetup que, por sua vez, utiliza o dm-crypt como base para a encripta¸cão de discos..

(32) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 18. O dm-crypt [38] é um subsistema de encripta¸cão de discos, que faz parte da infraestrutura do device mapper. Este pode ser utilizado por cima de outros dispositivos criados através do device mapper, tais como dispositivos RAID ou volumes criados pelo LVM. O dm-crypt s´ o faz a encripta¸c˜ ao do dispositivo de bloco, não lê ou analisa quaisquer dados lá existentes. O facto deste software só lidar com encripta¸cão de dispositivos de blocos, de uma forma transparente, torna-o bastante flex´ıvel, pois permite encriptar qualquer dispositivo de blocos, independentemente do SO lá instalado.. 2.5. iSCSI. iSCSI é um protocolo de transporte que foi desenvolvido com o intuito de permitir a comunica¸c˜ ao de blocos de dados entre um computador anfitrião, chamado de Initiator, e um dispositivo de destino, chamado Target, através de redes TCP/IP, possibilitando que comandos SCSI sejam encapsulados em pacotes IP [39]. Por transportar comandos SCSI em redes IP, o iSCSI é usado para facilitar a transferência de dados em intranets e para gerir armazenamento em longas distâncias. O iSCSI pode ser usado para transmitir dados em LANs, WANs, ou na Internet e pode permitir o armazenamento de dados e sua recupera¸cão independente da localiza¸cão. No iSCSI, quando uma aplica¸c˜ ao envia uma pedido I/O, o sistema operativo gera o comando SCSI necess´ ario, o qual é então encapsulado num pacote IP, que vai ser transmitido normalmente através de uma rede Ethernet. Este pacote é recebido pelo iSCSI Target, sendo depois o comando extra´ıdo e interpretado pelo dispositivo SCSI [40]. Através do protocolo iSCSI, o acesso à unidade de armazenamento ocorre ao n´ıvel de blocos (Block Level ), ao contr´ ario do que acontece com os protocolos FTP ou NFS, onde o acesso é feito ao n´ıvel de ficheiros (File Level ) [41]. No Block Level, a gest˜ ao do sistema de ficheiros é 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) reconhe¸ca o volume alocado em storage como se de um disco local se tratasse. Já em File Level, o sistema de ficheiros está do lado do dispositivo de armazenamento, bem como os protocolos para partilha de ficheiros (ex. NFS ou FTP), que também são executados do lado do servidor. As caracter´ısticas do protocolo iSCSI tornam-no ideal para o armazenamento de dados.

(33) CAPÍTULO 2. SOFTWARE/TECNOLOGIAS UTILIZADAS. 19. num volume alocado remotamente. No entanto este protocolo não é adequado para a partilha de um volume remoto, isto porque caso ocorram m´ ultiplos acessos simultâneos provenientes de iSCSI Initiators distintos, existe uma grande probabilidade de os dados ficarem corruptos.. 2.6. LVM. LVM é visto como uma ferramenta para a gestão de volumes lógicos no Linux. Ao criar uma camada de abstraçc˜ ao sobre o armazenamento f´ısico (ex. HDD, SSD), faz com que a cria¸cão e gest˜ ao de volumes l´ ogicos seja mais flex´ıvel e dinâmica. Na estrutura LVM existem três componentes principais: • Physical Volume (PV): s˜ ao 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): s˜ ao criado sobre os VG, e são estes volumes que são utilizados para aceder/manipular o espa¸co 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 identifica¸cão e o pormenor do redimensionamento da parti¸c˜ ao sem que haja qualquer necessidade de refazer o seu conte´ udo. Existem três tipos de LV: linear volume, striped volume e mirrored volume. • Linear Volumes: Neste tipo de LV, vários PV são concatenados num só LV. Todo o espa¸co dispon´ıvel nos PV é então utilizado neste LV; • Stripped Volumes: Neste tipo de LV, os dados são repartidos e escritos em vários discos f´ısicos, o que pode originar uma melhor performance de I/O. Este tipo de LV é semelhante ao RAID 0; • Mirrored Volumes: Quando os dados são escritos para o LV, estes são escritos simultaneamente em dois dispositivos, o que faz com que haja, pelo menos, duas cópias dos mesmos dados. Analogamente, este modo é semelhante ao RAID 1, o que origina redundˆ ancia dos dados;.

(34) Cap´ıtulo 3. Desenvolvimento Neste cap´ıtulo ser˜ ao descritos os procedimentos seguidos para a instala¸cão e configura¸cão dos softwares utilizados no projecto NASCloud. Na seçcão 3.1 s˜ ao apresentados os vários cenários montados e testados, onde é dada uma explica¸cão da composi¸c˜ ao de cada um, juntamente com o seu propósito. Na seçcão seguinte (3.2) é apresentado e descrito o script criado para a execu¸cão dos benchmarks de velocidade. O script pode ser consultado no apêndice A. Quanto aos softwares de cache utilizados, as suas configura¸cões estão descritas na seçcão 3.3. Aqui s˜ ao explicados os passos necessários para estabelecer a associa¸cão do disco SSD ao dispositivo proveniente da Cloud através do BCache e EnhanceIO, para desta forma acelerar o seu acesso. Logo de seguida, na seçc˜ ao 3.4, s˜ ao indicados quais os procedimentos usados para a cria¸cão e estabelecimento de um cluster Ceph. Este cluster é usado para fornecer espa¸co de armazenamento na forma de dispositivos de blocos, tal como se de uma cloud se tratasse. O cluster foi configurado em dois cenários: virtual e real. Em cada um existem detalhes diferentes de configura¸c˜ ao, detalhes esses que são indicados na seçcão referida. Para estabelecer as comunica¸c˜ oes entre os vários elementos do projecto, utilizou-se o protocolo iSCSI. Na seçc˜ ao 3.5 são explicados os procedimentos seguidos para a instala¸cão e configura¸c˜ ao dos dois elementos que compõem o protocolo iSCSI - iSCSI target e iSCSI initiator. Aqui s˜ ao também explicadas algumas altera¸cões feitas ao SO, de modo a aumentar a performance. Seguindo a estrutura definida ap´ os os primeiros testes integridade de dados efectuados, criou-se e configurou-se um array em RAID 1, com dispositivos de blocos provenientes da 20.

(35) CAPÍTULO 3. DESENVOLVIMENTO. 21. cloud. Este array vai permitir adicionar uma camada de redundância. Os procedimentos relativos a este processo est˜ ao explicados na seçcão 3.6. Como a seguran¸ca dos dados é cada vez mais importante e essencial, para a defini¸cão final da appliance a componente ”Seguran¸ca” era um requisito obrigatório. Na seçcão 3.7 são explicadas as vantagens do uso desta componente, juntamente com uma descri¸cão da etapas seguidas, para a instala¸c˜ ao e configura¸cão do LUKS. Finalmente, na seçc˜ ao 3.8 é feita uma descri¸cão dos passos seguidos para a implementa¸cão do LVM, o que vai facilitar a gest˜ ao do espa¸co de armazenamento proveniente da cloud.. 3.1. Cen´ arios de teste. Foram implementados e testados vários cenários 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 est´ a representado o cenário base do projecto. Da Cloud, simulada pelo cluster Ceph, s˜ ao exportados por iSCSI dispositivos de blocos para o CSG, onde este por sua vez os reexporta, também por iSCSI, para o Cliente. Este cen´ ario foi utilizado para definir e configurar as conexões entre os vários elementos do projecto (Ceph, CSG e Cliente), e estabelecer os valores iniciais de compara¸cão para os testes de velocidade a serem feitos no projecto, à medida que a instala¸cão e configura¸cão dos restantes softwares utilizados é feita.. ISCSI. /dev/sdx. Cloud Storage Server. ISCSI. Cliente. Figura 3.1: NASCloud - Caso Base. O cenário representado na figura 3.2 é, de um modo geral, igual ao cenário acima descrito, mas com a diferen¸ca de existir um dispositivo SSD, que vai servir de cache aos dispositivos de blocos provenientes da Cloud. A utiliza¸c˜ ao deste cen´ ario permitiu estabelecer as defini¸cões do software de cache usado no projecto (EnhanceIO), e verificar os ganhos de velocidade que este permitiu obter,.

(36) CAPÍTULO 3. DESENVOLVIMENTO. 22. face ao cen´ ario anterior.. ISCSI. ISCSI SSD. EnhanceIO WB/WT. Cliente. Cloud Storage Server. Figura 3.2: NASCloud - Cenário Base com acelera¸cão local. Outro cen´ ario de teste, desta vez de integridade de dados, está representado na figura 3.3. Este cen´ ario representa a ocorrência 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 situa¸cões, e estabelecer métodos e outros cen´ arios de testes, de modo a prevenir perda de dados e garantir que estes estão sempre salvaguardados, na eventualidade de ocorrerem falhas no sistema ou no setup do projecto.. ISCSI. ISCSI SSD. EnhanceIO WB/WT. Cloud Storage Server. Cliente. Figura 3.3: NASCloud - Cenário Base com falha na acelera¸cão local. Finalmente, a figura 3.4 representa a estrutura final do projecto NASCloud, onde são 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 redundância dos dados. A cria¸cão deste cen´ ario é uma consequência dos testes efectuados no cenário anterior (figura 3.3), em que se identificou os poss´ıveis pontos de falha na estrutura, e tentou-se eliminá-los através da duplica¸c˜ ao de conexões para a cloud, e do estabelecimento de um array RAID 1..

(37) CAPÍTULO 3. DESENVOLVIMENTO. SSD. 23. EnhanceIO WB/WT. ISCSI 1 ISCSI. ISCSI 2 SSD. EnhanceIO WB/WT. Cliente. Cloud Storage Server. Figura 3.4: NASCloud - Cenário Final. Em cima destes cen´ ario 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 liga¸c˜ ao iSCSI ` a Cloud, e falhas num disco SSD. Depois dos testes de integridade feitos, e descobertos os pontos de falha deste cenário, continuou-se a montar o resto da estrutura, que inclu´ıa a camada de encripta¸cão, fornecida pelo LUKS, e o software para gestão do espa¸co 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, é necessário indicar uma série de parˆ ametros com a descri¸c˜ ao do setup pretendido. A esse conjunto de parâmetros dá-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 modifica¸c˜ oes eram efectuadas na linha source device=/dev/sdb1, onde era indicado qual o dispositivo a ser testado. e na linha cache mode=wb, onde se indicava.

(38) CAPÍTULO 3. DESENVOLVIMENTO. 24. que tipo de teste era efectuado (writeback ou writethrough). Esta u ´ltima op¸cão neste script era s´ o usada por motivos de organiza¸cão 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 apêndice A. Para executar o FIO de acordo com o que se pretendia simular, houve necessidade de utilizar v´ arios switches, para personalizar e fazer um fine tuning aos processos a serem executados. Os switches utilizados estão descritos abaixo, juntamente com uma breve descri¸cão do significado de cada um. De notar que, para os testes de benchmark, foram feitos acessos de leitura e escrita aleatórios, cenários onde os discos SSD são mais rápidos que os discos HDD, o que permite tirar mais partido da acelera¸cão de cache. • direct=1: A fun¸c˜ ao deste switch é garantir que os dados que estão a ser escritos/lidos s˜ ao passados directamente para o dispositivo, evitando assim que estes fiquem armazenados no buffer e sejam mais rapidamente processados. Este buffer é uma mem´ oria que est´ a embebida no dispositivo de armazenamento, que actua como uma mem´ oria cache. Isto permite que os resultados sejam mais fidedignos; • –size=XX: Executa um processo do tamanho indicado nesta variável. Esse tamanho pode ser num valor em MB/GB , ou então uma percentagem do tamanho de um ficheiro ou dispositivo indicado; • –filesize=2GB: Tamanho m´ aximo 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 só 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 aleatórias; • –rwmixread=XX: Percentagem de leitura a ser feita no job; • –rwmixwrite=XX: Percentagem de escrita a ser feita no job. A jun¸cão deste switch com o definido anteriormente (rwmixread) tem de ser igual a 100; • –iodepth=X: N´ umero de I/O units que vão ser processados ao mesmo tempo. Uma I/O unit é equivalente a um ”ficheiro”a ser processado;.

(39) CAPÍTULO 3. DESENVOLVIMENTO. 25. • –numjobs=X: N´ umero de jobs que são 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 só grupo; • –name=??: Nome de cada job executado; • –random distribution: Modelo de distribui¸cão usado pelo FIO para execu¸cão de IO aleat´ orios;. 3.3. Software de cache. Para a manipula¸c˜ ao dos dispositivos de cache, pelos softwares EnhanceIO e BCache, foram criados dois scripts, um para cada caso. Os scripts podem ser consultados nos apêndices B e C. O modo de utiliza¸c˜ ao destes scripts é semelhante ao do FIO, isto é, existem blocos de código que s˜ ao modificados conforme o tipo de sistema de cache que se pretende implementar. Em rela¸c˜ ao do BCache, nas linhas source device="/dev/sda" e cache device="/dev/vdb" são indicados os dispositivos que serão utilizados como dispositivo lento, a ser acelerado, e o disco SSD, que serve de cache ao dispositivo lento. Na linha cache mode=wb é 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 c´ odigo dizem respeito ao processo de cria¸cão e elimina¸cão da cache. Durante o processo de cria¸c˜ ao de cache, são alterados algumas defini¸cões de cache para se obter resultados de benchmark mais fidedignos. Essas altera¸cões são referentes aos tempos de latência 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 n˜ ao ocorra nenhum atraso do disco SSD. A op¸cão relativa ao a relacionada com I/O sequenciais. Ao alterar o seu sequential cutoff também est´ valor para 0, est´ a-se a indicar ao BCache para não descartar I/O sequenciais [42]. Sobre o processo de elimina¸c˜ ao de cache, primeiro é dada a indica¸cão para parar o dispositivo de cache, para copiar o seu conte´ udo, caso haja, para o dispositivo lento. O passo seguinte no processo de elimina¸cão da cache é retirar a liga¸cão entre os dois dispositivos (SSD e dispositivo lento)..

(40) CAPÍTULO 3. DESENVOLVIMENTO. 26. No u ´ltimo bloco de c´ odigo, descomenta-se a op¸cão que se pretende executar (cria¸cão ou elimina¸c˜ ao da cache). Quanto ao método de cria¸c˜ ao e elimina¸cão de cache utilizando o software EnhanceIO, o script apresentado no apêndice C está dividido em quatro blocos. O primeiro bloco é referente ` as defini¸cões da cache, onde é indicado qual o dispositivo a ser acelerado, o dispositivo que serve de cache (disco SSD), a pol´ıticas de substitui¸cão e de cache utilizadas, o tamanho do bloco da cache, e finalmente o nome a ser dado à cache. O segundo bloco do script diz respeito ao comando de cria¸cão da cache e os switches utilizados para tal, previamente indicados no bloco anterior. No terceiro bloco de c´ odigo est´ a o comando utilizado para a elimina¸cão de uma cache criada pelo software EnhanceIO. Finalmente no u ´ltimo bloco de código, à imagem do script referente ao BCache (apêndice B), basta descomentear a op¸cão que se pretende executar, se a cria¸c˜ ao ou elimina¸c˜ ao da cache.. 3.4. Ceph. Como já descrito na seçc˜ ao 2.3, o Ceph é uma plataforma de armazenamento opensource, que disponibiliza armazenamento de blocos e ficheiros a partir de um cluster distribu´ıdo. A grande vantagem do uso do Ceph é ser tolerante a falhas, devido à replica¸cão de dados entre os elementos do cluster, o que faz que não 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 espa¸co dispon´ıvel no cluster via iSCSI. Para a gestão e manipula¸cão 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 é 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 não permitir criar e exportar dispositivos de blocos nativamente, como acontece com o Ceph [43]. No Gluster o método utilizado para criar e exportar dispositivos de blocos passa por montar o Gluster numa m´ aquina pertencente ao cluster, e criar um ficheiro que representa.

(41) CAPÍTULO 3. DESENVOLVIMENTO. 27. o dispositivo de blocos proveniente do Gluster, através do comando dd. Depois disso, tem de se exportar por iSCSI o ficheiro criado no passo anterior. Executados todos os passos descritos no parágrafo anterior, o cliente, liga-se ao dispositivo exportado como iSCSI Initiator [44]. O problema desta abordagem é que o dispositivo de blocos não é acedido directamente, como acontece no Ceph. Este é simulado por um ficheiro, que por sua vez, é exportado por iSCSI. A instala¸c˜ ao do Ceph obriga a certas regras. Uma delas é que todos os computadores envolvidos no cluster têm de poder aceder uns aos outros através de ”root”, sem uso de password. Este passo foi feito através do comando ”ssh-copy-id root@dest node”, onde dest node é a m´ aquina de destino. Outra regra essencial para a instala¸cão de um cluster Ceph é que as m´ aquinas envolvidas têm de comunicar entre si através dos seus hostnames. Nos dois cen´ arios de teste, a vers˜ ao do Ceph que foi utilizada foi a 0.72 Emperor. Antes de proceder ` a instala¸c˜ ao, foram criadas os seguintes directórios em todas as máquinas envolvidas no cluster, que são as localiza¸cões onde o Ceph armazena os seus dados. Apesar deste passo n˜ ao ser obrigatório, este procedimento é aconselhado para evitar problemas na instala¸c˜ ao do cluster [45]:. • /etc/ceph • /var/lib/ceph/tmp,mon,bootstrap-osd • /var/log/ceph ´ adicionado o reposit´ E orio do Ceph ao sistema, pela cria¸cão do ficheiro ceph.repo no directório /etc/yum.repos.d, com o seguinte conte´ udo: [ ceph−n o a r c h ] name=Ceph n o a r c h p a c k a g e s b a s e u r l=h t t p : //ceph.com/rpm-emperor/fc19/noarch e n a b l e d =1 g p g c h e c k=1 t y p e=rpm−md g p g k e y=h t t p s : //ceph.com/git/?p=ceph.git;a=blob plain;f=keys/release.asc.

(42) CAPÍTULO 3. DESENVOLVIMENTO. 3.4.1. 28. Cen´ ario Virtual. O cenário virtual foi a primeira hipótese a ser explorada para a implementa¸cão de um cluster Ceph. Tal deve-se ` a facilidade de cria¸cão e de utiliza¸cão de máquinas virtuais para o efeito. Para a cria¸c˜ ao do cluster Ceph foi usado o esquema de rede representado na figura 3.5.. Cluster Ceph Rede Intra-OSD Ceph Monitor. Ceph Monitor. Ceph Monitor. OSD Daemon. OSD Daemon. OSD Daemon. Ceph-node1. Ceph-node2. Ceph-node3. Cloud Storage Gateway. CSG. Figura 3.5: Diagrama Ceph - cenário virtual. O hardware das m´ aquinas virtuais Ceph-Node1, Ceph-Node2 e Ceph-node3 era idêntico. 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 máquina CSG também tinha um processador Single Core a 2.6 GHz, mas o dobro da memória RAM das m´ aquinas 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 três 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 instala¸c˜ ao foram utilizadas duas sub-redes, com propósitos diferentes: a rede interna do cluster, servia para comunica¸cão exclusiva entre os elementos do cluster, e a rede p´ ublica. O uso da rede interna permite reduzir a carga de utiliza¸cão da rede p´ ublica, ao eliminar o tr´ afego de heartbeat e replica¸cão entre OSDs. Existem mais raz˜ oes para usar duas redes distintas:.

(43) CAPÍTULO 3. DESENVOLVIMENTO. 29. • Seguran¸ca: ter uma rede separada para o cluster previne poss´ıveis ataques de Denial of Service (DoS). Quando o tráfego entre os OSDs é 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 s˜ ao responsáveis pela replica¸cão 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 latência na rede e problemas de performance. A verifica¸cão de heartbeat dos OSDs também origina mais tr´ afego na rede, o que pode comprometer a performance desta.. Os passos seguidos para a instala¸cão e configura¸cão do cluster estão enumerados e explicados abaixo. Todo o processo foi executado a partir de uma máquina (CephNode1). 1. Cria¸c˜ ao do primeiro Ceph-monitor: • yum install ceph-deploy: Antes de iniciar todo o processo de instala¸cão do cluster Ceph, teve de se instalar o programa ceph-deploy, na máquina 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 máquina Ceph-Node1; • ceph-deploy mon create-initial: Adiciona a máquina como monitor do cluster. A partir deste ponto o cluster está criado, e o seu estado pode ser consultado através 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 servi¸co Ceph, no monitor principal, para confirmar que ficou correctamente instalado; 2. Adi¸c˜ ao de monitores ao cluster:.