Ícaro: uma abordagem integrada para configuração remota de sistemas de arquivos paralelos distintos
Gianor Caon
Florianópolis – SC 2019/2
UNIVERSIDADE FEDERAL DE SANTA CATARINA DEPARTAMENTO DE INFORMÁTICA E ESTATÍSTICA CURSO DE BACHARELADO EM SISTEMAS DE INFORMAÇÃO
Ícaro: uma abordagem integrada para configuração remota de sistemas de arquivos paralelos distintos
Gianor Caon
Trabalho de conclusão de curso apresentado como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação da Universidade Federal de Santa Catarina.
Orientador: Prof. Ph.D. Mario Antônio Ribeiro Dantas
Coorientador: Dr. Eduardo Camilo Inacio
Gianor Caon
Ícaro: uma abordagem integrada para configuração remota de sistemas de arquivos paralelos distintos
Trabalho de conclusão de curso apresentado como parte dos requisitos para a obtenção do grau de Bacharel em Sistemas de Informação da Universidade Federal de Santa Catarina
Orientador: Prof. Ph.D. Mário Antônio Ribeiro Dantas Coorientador: Dr. Eduardo Camilo Inacio
Banca Examinadora
Prof. Dr. Elder Rizzon Santos Prof. Ph.D. Márcio Bastos Castro
SUMÁRIO
LISTA DE FIGURAS ... 5 LISTA DE TABELAS ... 6 LISTA DE ABREVIAÇÕES ... 7 1. INTRODUÇÃO ... 7 1.1 Objetivos ... 8 1.2 Objetivos Específicos ... 9 1.3 Escopo ... 9 1.4 Organização do Documento ... 9 2. SISTEMAS DISTRIBUÍDOS ... 11 2.1 Arquiteturas Computacionais ... 14 2.1.1 Multiprocessadores ... 15 2.1.2 Multicomputadores ... 162.2 Computação de Alto Desempenho ... 17
2.3 Considerações do Capítulo ... 19
3. SISTEMAS DE ARQUIVOS DISTRIBUÍDOS ... 21
3.1 OrangeFS ... 26
3.2 Lustre ... 27
3.3 Estado da Arte em SAP ... 29
3.4 Considerações do Capítulo ... 29
4. PROPOSTA ... 31
4.1 Motivação e proposta ... 31
4.2 Trabalhos Relacionados ... 32
4.3 Formas de configurar cada SAP ... 33
4.4 Parâmetros Abordados ... 35
4.5 Ícaro ... 36
4.5.1 Como Funciona ... 40
4.6 Considerações do capítulo ... 42
5. AMBIENTE E RESULTADOS EXPERIMENTAIS ... 44
5.1 Estrutura do Ambiente Experimental ... 44
5.2 OrangeFS ... 46
5.4.1 Cenário de configuração 1 – Distribuição de arquivo ... 48
5.4.2 Cenário de configuração 2 – Distribuição de arquivo ... 52
5.4.3 Cenário de configuração 3 – Tempo gasto para configurar ... 54
5.4.4 Resultados preliminares ... 55
5.5 Considerações do capítulo ... 58
6. CONCLUSÕES E TRABALHOS FUTUROS ... 59
6.2 Trabalhos Futuros ... 59
REFERÊNCIAS ... 61
APÊNDICE ... 65
Apêndice I – Instalação do OrangeFS no Ubuntu Server ... 65
Apêndice II – Instalação do Lustre no CentOS ... 67
Apêndice III – Artigo SBC... 69
LISTA DE FIGURAS
Figura 1 - Classificação de arquiteturas MIMD ... 15
Figura 2 - Arquitetura básica NFS em sistemas UNIX ... 22
Figura 3 - Componentes de um SAP ... 24
Figura 4 - Layouts de distribuição de dados em SAP... 25
Figura 5 - Arquitetura dos componentes de software do OrangeFS ... 27
Figura 6 - Arquitetura Básica do Lustre ... 29
Figura 7 - Formas de Utilização do Ícaro ... 32
Figura 8 - Módulos de Ícaro ... 37
Figura 9 - Ambiente Experimental ... 45
Figura 10 - Interface Gráfica ... 48
Figura 11 - Montando Sistema de Arquivos no cliente Lustre ... 50
Figura 12 - Montando sistema de arquivos no cliente OrangeFS ... 50
Figura 13 - Lustre: valores das tiras para arquivo LibreOffice_6.3.2_Win_x64.msi ... 51
Figura 14 - OrangeFS: valores das tiras para arquivo LibreOffice_6.3.2_Win_x64.msi ... 51
Figura 15 - Lustre: valores das tiras para arquivo debian-10.1.0-amd64-netinst.iso ... 53
Figura 16 - OrangeFS: valores das tiras para arquivo debian-10.1.0-amd64-netinst.iso ... 53
Figura 17 - Relação de tempo gasto de configuração (Ícaro X Manualmente) ... 57
LISTA DE TABELAS
Tabela 1 - Parâmetros de configuração do Lustre e do OrangeFS considerados pelo Ícaro. 35 Tabela 2 - Mapeamento do Ícaro entre parâmetros coletados e parâmetros de configuração
no Lustre e OrangeFS ... 37
Tabela 3 - Relação Parâmetros Específicos conforme o SAP ... 48
Tabela 4 - Parâmetros Cenário de configuração 1 ... 49
Tabela 5 - Parâmetros Cenário de configuração 2 ... 52
LISTA DE ABREVIAÇÕES
CAD – Computação de Alto Desempenho E/S – Entrada e Saída
HDD – Hard Disk Drive
NFS – Network File System (Sistema de Arquivos em Rede) SAD – Sistema de Arquivos Distribuído
SAP – Sistema de Arquivos Paralelo SD – Sistema Distribuído
SO – Sistema Operacional SSD – Solid State Drive
MGS – Servidor de Gerenciamento
MDT – Metadata Targets (Servidor de Armazenamento de Metadados) OST – Object Storage Target (Servidor de Armazenamento de Objetos) JDK – Java SE Development Kit
IDE – Integrated Development Environment (Ambiente Desenvolvimento Integrado) VM – Virtual Machine (Máquina Virtual)
RAM – Random Access Memory (Memória de Acesso Aleatório) MB – Megabyte
GB – Gigabyte
RESUMO
Plataformas computacionais de alto desempenho são o centro das atenções para a aplicação de inúmeras áreas de pesquisa e desenvolvimento, pois, tem dado condições de proporcionar resultados a essas áreas de forma rápida, concisa e muitas vezes com economia de recursos se comparado a outros métodos.
As plataformas computacionais iniciaram com arquiteturas centralizadas, porém, para computação de alto desempenho tornaram-se inadequadas devido às limitações físicas dos dispositivos envolvidos. Portanto, a computação paralela e distribuída tornou-se alvo para desenvolvimento e aplicação de sistemas computacionais, de simulações, de pesquisas, dentre outros.
O principal foco da computação paralela e distribuída é o desenvolvimento de melhores estruturas para o processamento de alto desempenho. Em consonância, as plataformas de alto desempenho para armazenamento paralelo e distribuído para abrigam os dados inerentes. Entretanto, há uma variedade de soluções voltadas a área e cada qual possui suas características de configuração.
A proposta traz uma abordagem integrada para configuração de plataformas de armazenamento paralelo e distribuído abstraindo para usuários e sistemas as especificidades das plataformas ao oferecer protótipo de aplicativo que provê uma entrada de configuração de parâmetros única independente do Sistema de Arquivos Paralelo e configura esse Sistema. Sendo possível perceber ganho de tempo e menor número de operações a executar ao utilizar-se do aplicativo.
Palavras Chave: computação de alto desempenho, computação paralela e distribuída, sistemas de arquivos paralelo, configuração de parâmetros única.
ABSTRACT
High performance computing platforms are the focus of application for numerous areas of research and development as it has been able to deliver results to these areas quickly, concisely and often with resource savings compared to other methods.
Computing platforms started with centralized architectures, but for high performance computing they became inadequate due to the physical limitations of the devices involved. Therefore, parallel and distributed computing has become a target for the development and application of computer systems, simulations, research, among others.
The main focus of parallel and distributed computing is the development of better structures for high performance processing. Accordingly, high performance platforms for parallel and distributed storage to house inherent data. However, there are a variety of area-oriented solutions, each with its own configuration characteristics. The proposal brings an integrated approach to configuring distributed and parallel storage platforms by abstracting platform specificities for users and systems by offering application prototypes that provide a unique parameter configuration entry independent of the Parallel File System and configure that System. Being able to realize time savings and fewer operations to perform when using the application.
Keywords: high performance computing, parallel and distributed computing, parallel file systems, unique parameter configuration.
1. INTRODUÇÃO
Plataformas computacionais fornecem processamento e respostas aos aplicativos nelas inseridos. No início, fez-se uso de arquiteturas centralizadas tendo em vista que tal tipo de arquitetura respondia as necessidades dessas aplicações.
Atualmente, plataformas computacionais de alto desempenho tem sido o centro das atenções para a aplicação de inúmeras áreas de pesquisa e desenvolvimento, pois, trazendo alto poder de processamento, num sentido final, tem dado condições de proporcionar resultados a essas áreas de forma rápida, concisa e muitas vezes com economia de recursos se comparado a outros métodos.
As plataformas computacionais evoluíram num primeiro momento com arquiteturas centralizadas, porém, o desenvolvimento desse tipo de arquitetura para computação de alto desempenho tornou-se inadequado devido, principalmente, às limitações físicas dos dispositivos envolvidos (TANENBAUM; STEEN, 2007). Desta forma, a computação paralela e distribuída, que outrora era abrangida praticamente somente na literatura, tornou-se alvo para o desenvolvimento e aplicação de sistemas computacionais, de simulações, de pesquisas, dentre outros, tendo em vista que ela ultrapassa os limites impostos pela computação centralizada.
De forma geral, o principal foco da computação paralela e distribuída é o desenvolvimento de melhores estruturas para o processamento das aplicações, simulações, sistemas, dentre outros, chegando à computação de alto desempenho. Dentro desse contexto, estão os middlewares de computação distribuída que proporcionam administração e uso dessas estruturas, como por exemplo, o Dédalo (INACIO; SIQUEIRA; DANTAS, 2016). Entretanto, quão importante é a evolução do
processamento, são importantes também as plataformas de alto desempenho para armazenamento paralelo e distribuído, tendo em vista que, a quantidade de dados utilizados nessas plataformas é gigantesca e necessitam de estruturas que as comportem e as tratem de forma otimizada e eficiente. E, nesse campo, há algumas propostas de middlewares de computação distribuída que visam proporcionar tal necessidade, por exemplo, o Callicrates (INACIO; DANTAS, 2016).
As plataformas para armazenamento paralelo e distribuído oferecem para as aplicações diferentes formatos de configuração de uso, e, cabe a cada tipo de aplicação realizar a configuração conforme sua necessidade. De forma geral, essas plataformas dispõem de uma configuração padrão, porém, cada aplicação possui características e necessidades inerentes ao seu conjunto de dados e interações. Portanto, facilitaria aos desenvolvedores ou mesmo aos usuários das aplicações a existência de uma abordagem integrada para a gerência das configurações das diferentes plataformas disponíveis.
Para propor essa abordagem integrada faz-se necessário entender o funcionamento das plataformas de armazenamento distribuído existentes, bem como compreender suas estruturas e parâmetros.
1.1 Objetivos
Entender e compreender plataformas de armazenamento paralelo e distribuído para então propor uma abordagem integrada que padronize os parâmetros de configurações disponíveis para diferentes plataformas existentes.
1.2 Objetivos Específicos
• Analisar conceitos de sistemas distribuídos;
• Analisar conceitos e estruturas de armazenamento paralelo e distribuído;
• Desenvolver aplicativo que contemple a configuração de diferentes plataformas de armazenamento distribuído seguindo os preceitos da abordagem integrada;
• Implantar plataforma de armazenamento paralelo e distribuído para executar ajustes de configuração utilizando a abordagem integrada proposta.
1.3 Escopo
Este trabalho foca no desenvolvimento de protótipo de aplicativo para configuração de Sistemas de Arquivos Paralelos (SAP) existentes e na implantação de plataformas de SAP para testar o aplicativo. Questões sobre segurança para acesso e para dados, tolerância à falta, redundância e rendimento dos servidores não são abrangidos.
1.4 Organização do Documento
Este trabalho encontra-se assim organizado: Nos Capítulos 2 e 3 é apresentada a revisão da literatura, sendo que o Capítulo 2 é abrangido com conceitos de sistemas distribuídos e computação de alto desempenho; já o Capítulo 3 expande a revisão sobre sistemas de arquivos distribuídos. O Capítulo 4 discorre sobre a proposta desse trabalho. No Capítulo 5, é abordado o ambiente de testes e a aplicação da proposta no mesmo com os resultados obtidos. Por fim, o Capítulo 6 finaliza o trabalho com um apanhado do aprendizado desenvolvido, bem como possibilidades futuras.
2. SISTEMAS DISTRIBUÍDOS
Conforme Coulouris et al. (2013), “um sistema distribuído é aquele no qual os componentes localizados em computadores interligados em rede se comunicam e coordenam suas ações passando apenas mensagens”. Para Tanenbaum e Steen (2007), sistema distribuído é “um conjunto de computadores independentes que se apresenta a seus usuários como um sistema único e coerente”.
Os sistemas computacionais vêm evoluindo consideravelmente, principalmente a partir dos anos 80. Essa evolução, proporciona produção de elementos computacionais com alto poder de processamento aliado a custo de produção reduzido. Juntando-se a isso, a invenção e evolução das redes de computadores de alta velocidade que permitiram a interligação e troca de informações entre os computadores, ocasionaram o surgimento da computação distribuída (TANENBAUM; STEEN, 2007).
Para Coulouris et al. (2013) o motivador principal dos sistemas distribuídos (SD) é o de compartilhamento dos recursos, estes, por sua vez, podem ser hardware, como discos e impressoras, e software, como arquivos, banco de dados e objetos de dados em geral. Da definição de SD surgem três consequências. A primeira delas, trata sobre concorrência, onde, numa rede de computadores a regra geral é a execução concorrente de programas e deve existir uma coordenação entre esses programas quando estão compartilhando recursos. A segunda consequência é sobre a inexistência de relógio global, onde, a coordenação das ações se dá por troca de mensagens e depende de noção compartilhada de tempo, porém, há limites na precisão de sincronização dos relógios dos computadores na rede. Por fim, a terceira consequência reza sobre falhas independentes, onde por serem inúmeros
computadores interligados na rede, falhas nesses computadores podem demorar em ser percebidas e o sistema como um todo não chega a parar, ou seja, falhas independentes podem ocorrer e o restante do sistema pode continuar a funcionar.
O surgimento dos SD envolvem outras características essenciais às quais são desafios constantes (COULOURIS et al., 2013):
• Heterogeneidade: diferentes componentes de hardware e software compõem os sistemas e esses componentes devem se comunicar e colaborar para que o sistema funcione. Para proporcionar isso, camadas de programas intermediárias abstraem e mascaram os componentes. Além disso, protocolos de comunicação proporcionam as trocas de mensagens entre esses componentes.
• Sistemas abertos: quando o sistema pode ser estendido e reimplementado de diferentes modos, ou seja, qual o grau com que novos recursos podem ser adicionados e compartilhados. Suas principais interfaces são publicadas e mecanismos de comunicação uniformes são estipulados. A construção de SD aberto pode ser por hardware e software heterogêneo, porém, os componentes de tais ambientes devem ser compatibilizados com os padrões publicados.
• Segurança: as informações disponíveis num SD podem ter muito valor individual para os usuários, dessa forma, a segurança dessas informações deve contemplar confidencialidade (para não expor a acesso não autorizado), integridade (proteger contra alterações ou ações danosas) e disponibilidade (proteger contra interferência no acesso aos recursos).
• Escalabilidade: um SD deve funcionar com efetividade e eficácia em diferentes escalas, desde pequeno conjunto em uma intranet até a própria Internet. A eficiência deve permanecer quando há aumento dos recursos e dos usuários.
• Tratamento de falhas: num SD as falhas são parciais, pois, enquanto um componente falha os outros continuam em funcionamento e, essa característica dificulta o tratamento das falhas. Há técnicas para o tratamento de falhas no SD, por exemplo, detecção, mascaramento, tolerância, recuperação e redundância.
• Concorrência: o SD deve garantir que recursos compartilhados sejam operados corretamente em ambiente concorrente. As operações devem ser sincronizadas de tal forma que os dados permaneçam consistentes.
• Transparência: o SD deve ser percebido como um sistema único ao invés de inúmeros componentes independentes interligados para o usuário final. Para que isso ocorra há formas de transparência: de acesso, onde recursos locais e remotos fazem uso de operações idênticas para acesso; de localização, onde o recurso é acessado sem conhecer sua localização física; de concorrência, para acesso a recursos compartilhados sem causar interferência entre os processos; de replicação, onde os recursos possuem várias instâncias que aumentam confiabilidade e desempenho mas os usuários não tem conhecimento das réplicas; de falhas, onde falhas são ocultadas e as tarefas podem ser terminadas sem percebê-las; de mobilidade, onde os recursos podem ser movimentados no sistema e não afeta a utilização dos mesmos pelos usuários; de desempenho, onde o
sistema pode ser reconfigurado conforme a necessidade mantendo o desempenho; de escalabilidade, que possibilita o sistema expandir sem alterar sua estrutura e aplicações.
• Qualidade de serviço: além de o serviço ser fornecido, a qualidade com que o mesmo ocorre é importante. Para tal, aspectos de confiabilidade, segurança e desempenho são abrangidos.
2.1 Arquiteturas Computacionais
Conforme Dantas (2005) há inúmeras arquiteturas computacionais baseadas em taxonomias propostas, mas, a taxonomia mais aceita é a de Flynn. Esta considera a quantidade de instruções executadas paralelamente em relação ao conjunto de dados em que as instruções se submetem. A taxonomia de Flynn (FLYNN, 1972) traz quatro classificações:
• SISD (Single Instruction Single Data): computador com processador único que executa uma única instrução por vez. Por exemplo, computador pessoal com processador convencional de núcleo único.
• SIMD (Single Instruction Multiple Data): uma única instrução sendo executada sobre múltiplos fluxos de dados. Utilizada quando da existência de armazenamento vetorial ou array. Por exemplo, as máquinas ILLIAC IV e Thiking Machine CM-2.
• MISD (Multiple Instruction Single Data): múltiplas instruções sendo executadas sobre único fluxo de dados. Não há arquiteturas de máquinas que abordem essa classificação.
• MIMD (Multiple Instruction Multiple Data): múltiplos processadores que executam instruções de forma independente dos demais sobre diferentes conjuntos de dados. Por exemplo, as máquinas Intel Paragon e Thinking Machine CM-5. A arquitetura MIMD usualmente classifica-se em multicomputadores e multiprocessadores, conforme a Figura 1.
Figura 1 - Classificação de arquiteturas MIMD
Fonte: Dantas (2005)
2.1.1 Multiprocessadores
Conforme Dantas (2005), a arquitetura de multiprocessadores é caracterizada por ter vários processadores compartilhando a memória do sistema. Há forte ligação entre processadores e memória, assim, essa arquitetura é conhecida como fortemente acoplada. A conectividade se dá localmente através de barramento que liga
processadores e memórias e pela rede de interconexão através de comutadores. A comunicação entre processos ocorre através de variável de memória uma vez que esta é global aos processadores. Outra característica dos multiprocessadores é que há um único sistema operacional sendo executado. Uma desvantagem do compartilhamento global é que a escalabilidade do sistema é restrita.
Há alguns ambientes que se utilizam do conceito de multiprocessadores, um deles é conhecido como multiprocessadores simétricos (SMP) onde há compartilhamento total dos recursos disponíveis e o custo para acesso a memória é igual para todos os processadores, porém, explicita a desvantagem da escalabilidade restrita. Outro, que visa minimizar a escalabilidade restrita citada anteriormente é o ambiente com acesso não uniforme a memória com coerência de cache (ccNUMA), onde o custo de acesso a memória é diferente para os processadores, pois, nós multiprocessadores são ligados através de interconexão e localmente possuem sua memória, mas, há visão global de memória, assim, o processador tem acesso mais rápido a dados globais contidos em sua memória local do que dados globais dispostos na memória de outro dispositivo ligado ao conjunto (DANTAS, 2005).
2.1.2 Multicomputadores
Para Dantas (2005), a arquitetura de multicomputadores se caracteriza por processadores que possuem sua própria memória local não havendo compartilhamento dos processadores e memórias ou mesmo visão global de memória. Assim, essa arquitetura é conhecida por ter um ambiente fracamente acoplado e, a interligação é realizada através de redes de interconexão seja por barramento ou comutação. A comunicação entre os processos executados se dá através de troca de mensagens pela rede de interconexão. Nos ambientes
multicomputados, cada nó refere-se ao conjunto que engloba processador, memória, interface de interconexão e demais dispositivos. Cada nó possui uma cópia do sistema operacional sendo executado individualmente.
Na arquitetura multicomputada há diferentes ambientes, um deles é conhecido como máquinas com configuração massivamente paralelas (MPP), onde, cada nó pode ser o conjunto de processador com cache e memórias locais ou mesmo um conjunto multiprocessador e a interligação se dá através de redes de alta velocidade, além disso, MPP são compostos por milhares de nós com sua própria cópia do sistema operacional e a troca de mensagens faz uso de pacotes voltados a redes de alta velocidade como MPI (MPIFORUM, 2016) e PVM (PVM, 2011). Há também o ambiente de agregado (cluster) computacional, onde inúmeros computadores dentro de um mesmo limite geográfico (laboratório, departamento ou organização) são agrupados de forma dedicada ou não (com gerenciamento centralizado) para executar aplicações específicas da organização; traz o diferencial da escalabilidade onde, à medida que novos recursos forem necessários, basta interliga-los ao ambiente (DANTAS, 2005).
2.2 Computação de Alto Desempenho
Para Dantas (2005), Computação de Alto Desempenho (CAD) “é um paradigma computacional que tem como um de seus principais objetivos a execução de milhares de aplicações ao mesmo instante e ainda o processamento de tarefas paralelas complexas com um elevado grau de sucesso”.
Os ambientes de CAD têm entregado recursos computacionais e de dados para domínios mais abrangentes da ciência e engenharia, onde, as simulações estão em escalas cada vez maiores devido aos modelos com maior resolução e representação
de processos físicos mais precisa. Para isso, esses ambientes têm sido construídos em extrema escala, com milhares de nodos de computação, redes de interconexão de alto desempenho e sistemas de entrada e saída (E/S) paralelas com rendimento na casa dos terabytes por segundo de taxa de transmissão com armazenamento na casa dos petabytes (PRABHAT; KOZIOL, 2014).
Para Dantas (2005), a agregação de recursos computacionais objetiva ultrapassar limites da computação centralizada e o surgimento da computação distribuída de larga escala resulta em CAD.
Conforme Prabhat e Koziol (2014), no campo de armazenamento, para que CAD obtenha desempenho e capacidade os sistemas de arquivos paralelos, como Lustre (BRAAM, 2002) e PVFS (LIGON III; ROSS, 1996), passaram a ser adotados, pois, oferecem armazenamento confiável e de alto desempenho persistentes, aliados a compatibilidade com o padrão POSIX (IEEE, 2004) para acesso aos arquivos.
Redes de interconexão de alto desempenho devem ofertar escalabilidade, tolerância à falta e taxas de transmissão acima dos gigabytes por segundo com retardo pequeno. Dispositivos convencionais, como Ethernet (Fast ou Gigabit), não são adequados para conexões em larga escala, assim, há dispositivos para alto desempenho, como Myrinet, Infiniband, Quadrics, dentre outros que, além de prover altas taxas de transmissão e demais, são voltadas aos mecanismos de troca de mensagens (arquiteturas multicomputadas) e de memória virtual única (arquiteturas multiprocessadas) (DANTAS, 2005).
Os ambientes de E/S paralelos possuem também bibliotecas que aplicam técnicas e métodos sobre os dados e assim obtêm alto rendimento para o sistema.
Alguns exemplos são o MPI-IO (MPIFORUM, 2016), HDF5 (THE HDF GROUP, 1997), ADIOS (PRABHAT; KOZIOL, 2014).
Para Dantas (2005), a administração e uso dos ambientes de CAD são providos por sistemas gerenciadores de recursos, por exemplo, HTCondor (UNIVERSITY OF WISCONSIN-MADISON, 2016) e o PBS (PBSWorks, 2016), que são voltados a gerência de tarefas e recursos dos agregados computacionais, e, por ambientes de middleware, como Globus (FOSTER, 2005) e Dédalo (INACIO; SIQUEIRA; DANTAS, 2016), que são voltados a administração mais ampla de diferentes ambientes de CAD.
2.3 Considerações do Capítulo
A evolução que as plataformas computacionais vêm sofrendo ao longo do tempo traz inúmeras possibilidades nos mais variados campos da ciência, engenharia e outros. Entretanto, os limites físicos dos computadores, mesmo sendo superpotentes, estrangulam aspirações de resultados com maior rapidez quando submetidos a cargas cada vez maiores (como é o caso de estruturas multiprocessadas). Um caminho encontrado para transpor esses limites é a agregação de recursos independentes em prol de um objetivo comum podendo assim conforme a carga a ser processada, gerar resultados com rapidez e eficiência (como é o caso de estruturas multicomputadas). Embarcando nas estruturas multicomputadas, a comunidade científica e a indústria têm dado ênfase a computação de alto desempenho, que, alinhado a utilização de recursos potentes, seja de processamento, comunicação entre os componentes, tráfego e armazenamento de dados, etc., está possibilitando extrair resultados rápidos e concisos sobre gigantescos conjuntos de dados e simulações. O armazenamento distribuído só é possível pelo conjunto de estruturas provindas das estruturas multicomputadas, principalmente no advento de
clusters computacionais, onde, nodos independentes se agregam para dividir o trabalho de armazenar conjuntos de dados fazendo uso de troca de mensagens entre os mesmos via interconexão de rede, logo, é necessário existir coordenação superior para esses elementos e assim poder entregar o armazenamento de forma eficaz.
3. SISTEMAS DE ARQUIVOS DISTRIBUÍDOS
Sistemas de Arquivos Distribuídos (SAD) são as bases para aplicações distribuídas, pois fornecem compartilhamento de dados entre inúmeros processos com confiabilidade e segurança (TANENBAUM; STEEN, 2007).
Para Coulouris et al. (2013), um SAD é o mecanismo que possibilita que arquivos remotos, isto é, arquivos que estejam em outro nodo computacional, sejam manipulados pelas aplicações de forma que esses arquivos são vistos por essas aplicações como se estivessem no nodo local.
Segundo Tanembaum e Steen (2007), há três grupos de arquiteturas para SAD: cliente-servidor, simétrica e baseada em cluster.
Na arquitetura cliente-servidor, um servidor oferece acesso aos dados contidos para que clientes em nodos remotos realizem operações sobre esses dados (TANEMBAUM; STEEN, 2007), logo, há centralização do armazenamento pelo servidor e o acesso se dá por um ou mais clientes. O NFS (Network File System) é um dos exemplos desse tipo de arquitetura e um dos mais difundidos da mesma em ambientes UNIX (TANEMBAUM; STEEN, 2007). A Figura 2 mostra a arquitetura básica do NFS denotando a comunicação do cliente com o servidor através da rede de interconexão.
Conforme Coulouris et al. (2013), sistemas cliente-servidor são dispostos em servidor único gerenciando e fornecendo acessos aos recursos oferecidos. Nesse tipo de sistema, o gerenciamento e controle dos recursos oferecidos bem como da estrutura que fornece é facilitado por ser sistema centralizado, entretanto, a escalabilidade fica limitada a capacidade do nodo servidor e da interconexão existente.
A característica de o nodo servidor estar centralizado traz a desvantagem de ser gargalo no desempenho do sistema quando é aplicada uma carga de trabalho pesada (LU et al. 2015).
Figura 2 - Arquitetura básica NFS em sistemas UNIX
Fonte: Baseado em Tanenbaum e Steen (2007).
Arquiteturas simétricas baseiam-se na tecnologia par-a-par (peer-to-peer), por exemplo, o sistema de arquivos Ivy (MUTHITACHAROEN et al., 2002), onde, não há a figura específica de cliente ou servidor, mas sim, a visão de nodos participantes que pode armazenar arquivos completos ou mesmo partes de arquivos. Para distribuição dos dados entre os nodos participantes é utilizado como base um sistema de Tabela de Hash Distribuído (THD) e a consulta desses dados faz uso de mecanismo baseado em chaves (TANEMBAUM; STEEN, 2007).
O projeto dos sistemas par-a-par traz como objetivo distribuir o serviço provido de forma descentralizada e organizada com maior eficácia no armazenamento de dados imutáveis (COULOURIS et al., 2013).
Na arquitetura baseada em cluster, com o advento de aglomerados (cluster) de servidores destinados à execução de aplicações em paralelo, os sistemas de arquivos passaram a utilizar essa arquitetura para paralelizar seu conjunto de dados, dessa forma, arquivos podem ser divididos em várias partes e distribuídos nos nodos servidores que compõem o aglomerado e, quando for necessário recuperar algum arquivo a busca poderá ser feita de forma paralela (TANEMBAUM; STEEN, 2007).
Há alguns tipos de SAD que possuem arquitetura baseada em cluster, dentre eles, há os Sistemas de Arquivos Paralelos (SAP).
A comunidade de CAD tem feito uso massivo dos SAP nos últimos anos (HE; SUN; HAIDER, 2015; SHAN; ANTYPAS; SHALF, 2008). Um SAP possibilita alta vazão de E/S de dados aliada a ampla capacidade de armazenamento através do acesso simultâneo a múltiplos nodos servidores de E/S (HE; SUN; HAIDER, 2015).
De forma geral, a estrutura de um SAP é segmentada em três componentes: cliente, servidor de metadados e servidor de dados (WANG; JIANG; YANG, 2013; LU et al., 2015; SHAN; ANTYPAS; SHALF, 2008). A Figura 3 demonstra esses componentes.
O cliente normalmente é separado dos servidores de metadados e dados e proporciona aos nodos de computação acesso ao SAP para que possam executar suas operações sobre os dados. O cliente fornece interfaces específicas para essa comunicação, como MPI-IO, além de suportar o padrão POSIX.
Os servidores de metadados estão associados aos nodos servidores que comportam as informações sobre os arquivos. Assim, são de responsabilidade desses servidores o controle de nomes, permissões, estruturas de diretórios, dentre outros, bem como a localização dos dados (ou das partes) em si nos servidores de dados. Os servidores de metadados acabam por ser o primeiro acesso pelos clientes em busca de dados, assim, conforme o aumento da consulta por dados esses servidores podem se tornar o gargalo no sistema dependendo da configuração utilizada, por exemplo, em configurações onde o servidor de metadados é centralizado, como no sistema Lustre, abrangido adiante. Visando solucionar ou ao menos minimizar esse gargalo, alguns SAP permitem distribuir os metadados em múltiplos servidores como nos sistemas OrangeFS (MOORE et al. 2011), visto adiante.
Os servidores de dados ficam a cargo da armazenagem dos dados em si, ou seja, persistir os blocos de dados dos arquivos. Esses nodos servidores são responsáveis por operar as requisições de leitura e escrita sobre conteúdo dos arquivos.
Figura 3 - Componentes de um SAP
A principal característica dos sistemas de arquivos paralelos é possibilitar a divisão do arquivo em múltiplas partes e assim distribuir entre os diferentes nodos de armazenamento. Essa característica é conhecida como desmembramento de arquivos em tiras e o seu tamanho é configurável (TANEMBAUM; STEEN, 2007). As tiras dos arquivos são distribuídas entre os servidores geralmente com três layouts de distribuição: horizontal, vertical e bidimensional (SONG et al., 2012), conforme a Figura 4. O layout horizontal, as tiras são distribuídas entre todos os servidores de dados extraindo assim, a máxima paralelização do sistema; no layout vertical, todas as tiras de um arquivo são armazenadas no mesmo servidor de dados, nesse caso perde-se a paralelização de operações; já o layout bidirecional é combinação dos dois anteriores onde as tiras são distribuídas em subconjuntos de nodos de armazenamentos (INACIO, 2015).
Figura 4 - Layouts de distribuição de dados em SAP
Fonte: Inacio (2015)
A comunidade de CAD dispõe de inúmeras implementações de SAP distintos, com especialidades para todos os tipos de necessidades. Exemplos existem dos mais variados, como OrangeFS (MOORE et al. 2011), Lustre (BRAAM, 2002), GPFS(IBM,
2000), PanFS(WELCH; GIBSON, 2004), PLFS(BENT et al. 2009), dentre tantos outros.
Lustre, OrangeFS e PLFS ganharam atenção nos últimos anos por comportar grandes cargas de trabalho (CHEN et al. 2019). Para Bent et. al. (2009) os SAP PanFS, GPFS e Lustre estão entre os principais SAP para CAD. Lustre é um dos SAP mais populares para sistemas de CAD (DAI; GATLA; ZHENG, 2019). Lustre, GPFS e OrangeFS são SAP amplamente utilizados para CAD (HAN; KIM; EOM, 2016, HE et al., 2018).
3.1 OrangeFS
OrangeFS (MOORE et al. 2011) é a evolução do SAP de código aberto PVFS2 (CARNS et al. 2000).
Conforme Prabhat e Koziol (2014), o OrangeFS oferece acesso paralelo de alto desempenho para variados tipos de aplicações, desde engenharia chegando a aplicações para grandes volumes de dados. O OrangeFS pode ser executado em nível de usuário ou através de módulos de kernel sendo visto como sistema de arquivo comum pelos sistemas operacionais (SO) compatíveis; oferece também, espaço de nomes global POSIX, enquanto que pode relaxar semânticas de consistências visando eliminar gargalos; provê diferentes interface para os clientes através de kernel do SO, MPI-IO, WebDAV, dentre outros.
O PVFS1 trouxe, principalmente, a distribuição dos dados em múltiplos servidores e suporte ao TCP/IP; já o PVFS2, agregou a distribuição dos metadados em múltiplos servidores além de suporte a outros tipos de redes de interconexão; o OrangeFS, por sua vez, trouxe o recurso de diretórios distribuídos, segurança
baseada em criptografia, dentre outros e o suporte do mesmo passou a ser da empresa Omnibond (PRABHAT; KOZIOL, 2014).
A Figura 5 traz a arquitetura dos componentes de software do OrangeFS, onde, alguns tem destaque: BMI, provê interface comum para diferentes tecnologias de rede, como TCP/IP, Myrinet (MX), Infiniband (IB), Portals; Trove, provê camada de abstração para manipulação dos objetos (dados ou metadados) nos sistemas de arquivos locais; Flow, controla fluxos de dados entre clientes e servidores combinando Trove e BMI.
Figura 5 - Arquitetura dos componentes de software do OrangeFS
Fonte: Prabhat e Koziol (2014)
3.2 Lustre
O Lustre (BRAAM, 2002) é um SAP de código aberto focado em escalabilidade para o uso em agregados computacionais grandes. Conforme Prabhat e Koziol (2014), o Lustre é utilizado por cerca de 60% dos 100 melhores supercomputadores listados pelo TOP500 suportando na casa dos petabytes de capacidade de armazenamento bem como vazão de E/S acima de 1TB/s (terabytes por segundo). O Lustre foi
implementado diretamente no kernel do Linux, tendo sua arquitetura baseada em armazenamento distribuído de objetos. Os objetos podem agregar dois tipos de componentes POSIX: dados de arquivos ou indexadores para diretórios.
A Figura 6 mostra a arquitetura básica do Lustre. Nela, há os Targets, os quais efetivamente armazenam dados (OST – Object Storage Target) ou metadados (MDT – Metadata Target); há os Servers, que gerenciam um ou mais Targets, respectivamente, dados (OSS – Object Storage Servers) e metadados (MDS – Metadata Servers); além dos componentes de dados e metadados, o Lustre traz também o MGS (Management Server), o qual gerencia e armazena configurações e registros de clientes e servidores. Para rede de interconexão, provê o LNET (Lustre Network), onde, suporta diferentes tipos de redes como TCP/IP, Infiniband, etc. através de API (sigla do inglês, Application Programming Interface)) simples fornecendo também, operações de rede não bloqueantes e comunicação por passagem de mensagem ou por acesso remoto a memória (RMA). A serialização de conflitos entre servidores e clientes e a manutenção da coerência de cache nos clientes é abrangida pelo LDLM (Lustre Distributed Lock Manager) (PRABHAT; KOZIOL, 2014).
Figura 6 - Arquitetura Básica do Lustre
Fonte: http://doc.lustre.org/lustre_manual.xhtml.
3.3 Estado da Arte em SAP
Conforme He et al. (2019) e He et al. (2018), a comunidade de CAD faz uso massivo de SAP para minimizar o gargalo de I/O perante o volume cada vez maior de dados. Porém, o incremento cada vez maior no volume de dados está trazendo limitações com a estrutura atual de armazenamento físico. Assim, o uso de SSD (Solid State Drives) torna-se uma possibilidade de incrementar o rendimento dos SAP existentes. Entretanto, o custo envolvido na aquisição de SSD ainda é um limitador para uso em larga escala e, atualmente ocorre investimento na pesquisa e desenvolvimento de SAP híbridos, combinando HDD (Hard Disk Drives) com SSD.
3.4 Considerações do Capítulo
O quesito armazenamento para os sistemas distribuídos é um dos pilares para um excelente rendimento. Partindo do pressuposto que sistemas distribuídos oferecem resultados rápidos para larga escala de processamento, o desenvolvimento
de SAD se deu por natural. Além disso, percebe-se que a paralelização do processamento traz ganhos em escalas superiores para os resultados. Os SAP oferecem altas taxas de tráfego dos dados armazenados e que precisam ser ou foram processados, assim, o gargalo que o armazenamento comum traz aos sistemas é minimizado. Tanto é que, os ambientes de computação de alto desempenho fazem uso massivo dos SAP.
Em decorrência do estudo dos sistemas distribuídos, em especial dos sistemas de arquivos distribuídos, constatou-se diferentes implementações que se encontram no cenário atual. Sistemas gerenciadores e ou middlewares de computação distribuída são desenvolvidos em paralelo aos ambientes para que estes possam ser administrados e utilizados da melhor forma possível. Porém, devido essas diferentes implementações, a configuração dos variados sistemas e estruturas que estão a cargo dos desenvolvedores das soluções de gerenciamento ou mesmo do usuário final tende a ser um passo trabalhoso, pois, deve-se conhecer a estrutura e como configurar cada sistema que faça parte do ambiente de computação distribuída.
A estrutura de um SAP é genérica, com clientes, servidores de dados e de metadados, mas, cada solução existente de SAP tem suas características, por exemplo, o Lustre segmenta seus servidores de dados e metadados em Targets e Servers, onde, os Targets são voltados a persistência e os Servers a gerência do conjunto, mas, há também a figura do servidor de gerenciamento (MGS) tendo por função manter configurações e registros de clientes e servidores; já no OrangeFS, gerenciamento e armazenamento são realizados pelo próprio servidor de dados ou de metadados e não há a figura de um servidor de gerenciamento como no Lustre.
4. PROPOSTA
Dentre a variedade de SAP existentes, optou-se por abordar dois dos mais utilizados pela comunidade CAD (Lustre e OrangeFS), devido terem fatia considerável de utilização, mas também por serem distribuídos de forma opensource. Enquanto outros SAP analisados, até podem ser difundidos no meio de CAP, porém são privados (GPFS, PanFS).
4.1 Motivação e proposta
Tendo em vista a existência de diferentes SAP e, por consequência, cada qual possuir sua própria sintaxe de utilização. O que, pode onerar ao utilizador (seja de forma manual ou através de middlewares) dos SAP o conhecimento de cada sintaxe específica para poder utilizar os SAP. A proposta desse trabalho é produzir um aplicativo, chamado Ícaro, para configuração remota de diferentes SAP, fornecendo ao utilizador do mesmo a facilidade de independente do SAP que for configurar, a sintaxe de configuração ser única.
O aplicativo, pretende abordar duas formas de utilização (Figura 7). Uma delas, é através de interface gráfica, a qual pode ser utilizada diretamente pelo usuário na configuração do SAP pretendido. A outra, é através da passagem de parâmetros por chamada de método, assim, poderia ser integrada a sistemas gerenciadores de recursos ou middlewares de computação distribuída.
Figura 7 - Formas de Utilização do Ícaro
Fonte: elaborado pelo autor.
Para o desenvolvimento da proposta, a linguagem utilizada é o Java, pois, ele oferece suporte a múltiplas plataformas eliminando a necessidade de compatibilização para diferentes sistemas. Além disso, a intercomunicação entre os dispositivos para aplicação das configurações é realizada por SSH (Secure Shell, protocolo para uso em serviços de rede).
4.2 Trabalhos Relacionados
A ideia de prover uma entrada padrão para que se ajuste/configure diferentes sistemas do mesmo gênero é difundida em diferentes áreas. Para os SAP, isso também existe.
A gigante Amazon, possui o serviço Amazon FSx (Amazon, 2019), que, provê configuração do Lustre e do Windows File Server integrado com suas soluções de armazenamento e afins. No momento somente esses dois sistemas de arquivos são providos, e somente o Lustre é voltado para CAD. O subproduto do FSx para o Lustre chama-se Amazon FSx for Lustre e tem como base o próprio Lustre, ou seja, a
Amazon disponibiliza o SAP Lustre adaptado a configuração provida pelo FSx for Lustre abstraindo do cliente o conhecimento de toda a estrutura envolvida na configuração do Lustre (o cliente somente precisa configurar nome do sistema de arquivos, tamanho do armazenamento e questões de rede e segurança; o cliente não tem possibilidade de alterar os nodos servidores envolvidos, pois o FSx possui somente um servidor de metadados (MDT) e tantos servidores de dados (OST) conforme o tamanho do armazenamento escolhido pois, em média cada servidor OST tem a capacidade de 1.2TB). O trabalho proposto tem um viés diferente pois, tem por base disponibilizar entrada padrão de valores de configuração independente do SAP escolhido (no momento, para o OrangeFS e Lustre) possibilitando ao utilizador escolher a quantidade de nodos servidores dentre outros parâmetros conforme sua própria necessidade. Além disso, o produto da Amazon requer pagamento para utilização.
4.3 Formas de configurar cada SAP
Especializando melhor o desenvolvimento proposto no trabalho atual, ele inicia-se e restringe-inicia-se a alguns parâmetros comuns ao Lustre e ao OrangeFS. Apesar de conceitualmente serem parâmetros comuns, a aplicação deles ocorre de forma diferente para cada um dos SAPs, conforme abordado a seguir.
O procedimento de configuração para o Lustre consiste primeiramente em preparar o sistema local para o sistema de arquivos do Lustre e depois montar o referido sistema de arquivos, através do comando “mkfs.lustre {--ost|--mdt|--mgs} [options] device”. Onde, escolhemos se o sistema a ser configurado no referido servidor (para cada nodo servidor é necessário executar esse comando com suas opções) será para armazenar os dados dos arquivos (OST), os metadados (MDT) ou
mesmo o servidor de gerenciamento (MGS, lembrando que, a figura do MGS não existe no OrangeFS, e, no Lustre pode ser combinado com um servidor de metadados – geralmente o primeiro nodo servidor de metadados configurado – especificando os dois no momento do comando). Além disso, configura-se as opções inerentes ao sistema, como nome do sistema de arquivos, parâmetros referentes as tiras (tamanho e quantidade de pedaços a dividir), qual servidor de gerenciamento, dentre outros. Então, define-se o bloco de disco ou disco a ser usado para armazenar os dados inerentes ao tipo de configuração. Por fim, após executar a preparação do sistema, monta-se o mesmo no nodo com o comando “mount -t lustre <block device name> <mount point>”, onde especifica-se o tipo do sistema de arquivos (lustre) e faz-se uso do bloco de disco/disco (<bloco device name>) e um ponto de montagem.
Ao que se percebe, tendo o nodo servidor de gerenciamento (MGS) configurado e ativo, os demais nodos servidores (dados e metadados) do sistema configurado irão consultar e alimentar o MGS para poderem se comunicar e aplicar as configurações inerentes (note que, na configuração de cada nodo, não se faz referência ao outro nodo, somente ao nodo MGS).
No OrangeFS, o procedimento de configuração consiste em gerar um arquivo de configuração, depois distribui-se esse arquivo por entre os nodos participantes e então executa-se o mesmo em cada nodo. Para gerar a configuração, executa-se o comando “pvfs2-genconfig [options] config_file”, onde, nas opções, define-se quem são os nodos de dados, os de metadados, nome do sistema de arquivo, local de armazenamento no nodo, parâmetros referentes as tiras (tamanho e quantidade de pedaços a dividir), tipo de rede a utilizar, dentre outros. Então, define-se o arquivo para armazenar as configurações geradas. Com o arquivo de configuração gerado, o
mesmo é transferido para os demais nodos inerentes a configuração. Então, aplica-se a configuração em cada nodo, primeiramente com o comando “pvfs2-aplica-server -f -a nodo config_file” para inicializar o armazenamento (‘-f’ na linha de comando) e então o comando “pvfs2-server -a nodo config_file” para iniciar o processo do servidor e deixá-lo ativo na rede.
Em contraponto ao Lustre, percebe-se que o OrangeFS cria um arquivo prévio que engloba as configurações, bem como referencia nodos de armazenamento de dados e de metadados e então distribui o mesmo entre os nodos para então iniciar o sistema. Logo, cada nodo tem conhecimento de todos seus pares já no iniciar do sistema.
4.4 Parâmetros Abordados
Dessa forma, os parâmetros abordados em Ícaro são expostos na Tabela 1 e, Ícaro, a partir dos dados coletados irá converter para o respectivo comando dependendo do SAP escolhido.
Tabela 1 - Parâmetros de configuração do Lustre e do OrangeFS considerados pelo Ícaro.
Parâmetro Lustre OrangeFS
Tamanho das tiras --param
lov.stripesize=TAMANHO
--dist-name simple_stripe --dist_params
strip_size:TAMANHO Quantidade de
tiras por arquivo --param lov.stripecount=QUANTIDADE
--default-num-dfiles QUANTIDADE Especificar servidores de Dados (IO) ou Metadados --ost ou --mdt e/ou --mgs
em cada servidor (OST ou MDT) aponta-se o MGS com --mgsnode=endereço (excluso o próprio servidor MGS) --ioservers lista_de_servidores_IO e/ou --metaservers lista_de_servidores_Metadados Local de
Armazenamento /dev/sdX (partição ou disco usado, após, montar com mount --storage pasta_armazenar_dados e/ou
-t lustre /dev/sdX /ponto_de_montagem
--metadata
pasta_armazenar_Metadados Tipo de rede
utilizada Comandos: lnetctl lnet configure &&
lnetctl net add --net protocolo_rede+ID --if interface_rede_associada
--protocol
protocolo_utilizado
Nome do Sistema
de Arquivo --fsname=NOMEdoFS --fsname NOMEdoFS Id do Sistema de
Arquivo --index=ID --fsid ID
Conforme citado anteriormente e verificado no aprofundamento do estudo sobre os SAPs, cada um deles possuem particularidades (por exemplo, a figura do MGS existente no Lustre não existe no OrangeFS) e que outros não possuem em sua estrutura tal opção. Assim, nesse momento, os componentes exclusivos de cada SAP não são tratados no desenvolvimento da aplicação proposta, logo, a abordagem deles poderá ser dada em outro momento oportuno.
4.5 Ícaro
Tendo como norte os parâmetros abordados, Ícaro tem parâmetros adicionais que servem para orientar qual SAP é direcionada a configuração bem como – dependendo do SAP escolhido –, intrínsecos aos SAPs e que são necessários. Essa relação entre componentes comuns e específicos é resolvido na aplicação com o uso de objeto específico de cada SAP em que cada qual possui seus componentes específicos, bem como o componente comum englobado em sua estrutura (Figura 8).
Figura 8 - Módulos de Ícaro
Fonte: elaborado pelo autor.
O mapeamento dos parâmetros entre coletados e utilizados na configuração do Lustre e do OrangeFS (Tabela 2), é estruturado em dois segmentos, o primeiro deles, é o que coleta os valores pela entrada genérica, o segundo, são efetivamente os configuradores de cada SAP, onde, com os valores coletados, é produzido o comando a ser aplicado em cada nodo participante conforme o SAP escolhido.
Tabela 2 - Mapeamento do Ícaro entre parâmetros coletados e parâmetros de configuração no Lustre e OrangeFS
Parâmetro
coletado Como cada SAP usa o valor coletado na configuração e, o valor para o SAP é OBrigatório ou OPcional (usa valores padrão)
Qual SAP Parâmetro pré SAP, para definir qual SAP irá utilizar
Login SSH Parâmetros necessários para poder conectar nos servidores, independe do tipo de servidor
Senha SSH Porta SSH
Lustre OB
Tamanho das Tiras
STRIPESIZE --param lov.stripesize= STRIPESIZE OP --dist-name simple_stripe --dist_param strip_size: STRIPESIZE OP
Tiras por Arquivo
STRIPECOUNT --param lov.stripecount= STRIPECOUNT OP --default-num-dfiles STRIPECOUNT OP Servidores de Dados DATASERVERS Adiciona “--ost” na configuração de nós em DATASERVERS OB --ioservers DATASERVERS OB Servidores de Metadados METASERVERS Adiciona “--mdt” na configuração de nós em METASERVERS OB --metaservers METASERVERS OB Local do Armazenamento STORAGEPLACE mount -t lustre JOKER1 STORAGEPLACE OB --storage STORAGEPLACE OB Rede Utilizada
PROTONETUSED lnetctl lnet configure && lnetctl net add --net PROTONETUSED +ID --if JOKER2
OB --protocol
PROTONETUSED OB
Nome do Sistema de Arquivos criado FSNAME
--fsname=FSNAME OB --fsname FSNAME OP
Coringa 1
JOKER1 Partição usada para armazenar dados OB --fspath JOKER1 (local OrangeFS instalado) OP Coringa 2
JOKER2 Interface de rede utilizada pelo Lustre configurada junto com o protocolo escolhido
OB Nome do arquivo de configuração gerado OB
A solução aplicada para a questão de parâmetros intrínsecos de cada SAP e que podem ou não ser obrigatórios dependendo do SAP parte da utilização de parâmetros coringas, onde, conforme o SAP escolhido o coringa representa determinado parâmetro do SAP.
Ícaro, em seu frontend (seja interface gráfica ou chamada de procedimento), faz a coleta dos dados e, em seu core faz o tratamento dos valores coletados, para então, dependendo do SAP, os repassar ao configurador específico. Mesmo que os
parâmetros sejam opcionais ou obrigatórios, dependendo do SAP, o valor é tratado para que seja ativado o configurador com os dados já validados.
Dos parâmetros comuns abordados entre o OrangeFS e Lustre, para o OrangeFS, Servidores de Metadados/Dados, Protocolo de Rede utilizado e Local do Armazenamento são obrigatórios declarar, o restante, o SAP possui valores padrão caso não houver declaração. Já nos parâmetros específicos (coringas), o OrangeFS necessita que seja declarado o nome do arquivo de configuração gerado. Já para o Lustre, somente Tamanho e Quantidade das Tiras não é necessário declarar, o restante, inclusive os parâmetros coringas, são necessários. De qualquer forma, ocorre a validação dos valores dos parâmetros conforme:
• STRIPESIZE e STRIPECOUNT: valores numérico inteiros, maiores que zero (para o Lustre, STRIPESIZE também deve ser múltiplo de 64KB (65536);
• DATASERVERS e METASERVERS: declaração linear dos servidores, por exemplo, “nodeX,nodeY,...,nodeN” e/ou intervalo, exemplo, “node{X-N}”, podendo combinar os dois padrões, separando por vírgula cada elemento (X, Y e N, nos exemplos são números e node é o prefixo do nome dos servidores);
• STORAGEPLACE: diretório onde será montado o armazenamento no servidor, deve seguir o padrão, ambiente Linux no momento, “/dirA/.../dirParaMontar”;
• PROTONETUSED: para o OrangeFS, pode-se usar “tcp”, “gm”, “mx”, “ib” ou “portals” – na fase atual, somente um protocolo por configuração é possível –, já para o Lustre, pode-se usar “tcp”, “o2ib”, “ra” ou “elan” – também um protocolo por configuração é possível;
• FSNAME: nome do sistema de arquivos gerado, somente combinação de letras e números;
• JOKER1: diretório de instalação do OrangeFS, deve seguir o padrão, ambiente Linux no momento, “/dirA/.../dirInstalado”;
• JOKER2: nome do arquivo de configuração gerado, pode conter letras e números combinados (iniciado por esses), além dos caracteres “.”, “-” ou “_”.
4.5.1 Como Funciona
O princípio básico do funcionamento do Ícaro é a coleta dos parâmetros de configuração, validação e normalização dos valores coletados e posteriormente entrega dos valores ao configurador do SAP escolhido. Entretanto, cada módulo (Figura 8) do Ícaro desempenha seu papel no conjunto, conforme:
• Interface Gráfica: dividida em três partes, a primeira, para os valores referentes à conexão SSH (nome de usuário, senha e porta de conexão), a segunda, contém os parâmetros comuns entre os SAP abordados (citados anteriormente) e a terceira, contém os parâmetros específicos de cada SAP necessários para configuração inicial (também citados anteriormente). A interface coleta esses dados e encaminha para o módulo Configurador Mestre fazendo uso da chamada de método pública;
• Chamada de Método: passagem dos parâmetros de conexão SSH, parâmetros comuns e específicos dos SAP através de método único público fornecido pelo módulo Configurador Mestre;
• Configurador Mestre: disponibiliza o método público para receber os parâmetros abordados. De posse dos parâmetros, valida, no âmbito geral, se os valores passados estão de acordo com os requisitos do parâmetro (através de validação com expressões regulares que delimitam a forma de declaração
dos parâmetros). Para o SAP escolhido, valida os demais parâmetros intrínsecos (apesar de ser parâmetro comum entre os SAP, a forma como o valor é utilizado pode ser diferente) e exclusivos e então aciona método privado referente ao SAP. O método privado referente ao Lustre aciona o módulo Configurador Lustre (enquanto o método privado referente ao OrangeFS aciona o módulo Configurador OrangeFS) repassando os parâmetros comuns bem como os exclusivos para o respectivo módulo englobados em objeto inerente ao SAP (módulo Parâmetros Lustre ou Parâmetros OrangeFS);
• Configurador Lustre: recebe o objeto do módulo Parâmetros Lustre, faz uso dos parâmetros comuns e dos exclusivos e gera a lista de servidores de dados (OSTs) e de metadados (MDTs), retira o primeiro registro da lista de metadados para ser o servidor de gerenciamento (nessa versão do Ícaro, o primeiro servidor de metadados também será o servidor de gerenciamento MGS), gera o comando de configuração do MGS e aplica no mesmo através de conexão SSH. Depois disso, parte para a configuração dos MDTs, gerando o comando de configuração e aplicando (via conexão SSH) nos servidores da lista de MDTs. Por fim, aborda a configuração dos OSTs gerando o comando de configuração e aplicando (via conexão SSH) nos servidores contidos na lista de OSTs;
• Configurador OrangeFS: recebe o objeto do módulo Parâmetros OrangeFS, com os valores comuns e exclusivos gera o comando de configuração e executa no primeiro servidor da lista criando o arquivo de configuração (nesse caso, a lista de servidores engloba tanto de Metadados quanto de Dados, pois o arquivo de configuração é único e igual para todos os participantes) e desse
servidor copia o arquivo de configuração gerado para os demais da lista. Depois disso, com o arquivo de configuração distribuído, via conexão SSH, Ícaro aplica a configuração e ativa os servidores;
• Parâmetros Lustre: módulo que compõe o objeto com os parâmetros comuns (módulo Parâmetros Comuns) e os parâmetros exclusivos do Lustre necessários para configuração e ativação básica;
• Parâmetros OrangeFS: módulo que compõe o objeto com os parâmetros comuns (módulo Parâmetros Comuns) e os parâmetros exclusivos do OrangeFS necessários para configuração e ativação básica;
• Parâmetros Comuns: módulo que compõe objeto abrigando os parâmetros comuns entre os SAPs, independe do SAP e é utilizado pelos módulos inerentes a cada SAP para agregar ao seu objeto de parâmetros;
• Serviço SSH: módulo para conexão entre Ícaro e os servidores explicitados na configuração. Nessa versão do Ícaro, está embutido tanto no Configurador Lustre quanto no Configurador OrangeFS pois cada qual executa diferentes ações em cada SAP.
4.6 Considerações do capítulo
A abundância de opções configuráveis que traz a relação entre os diferentes SAPs existentes (mesmo que no momento abordamos somente dois SAPs em específico) pode ser um fator que atrapalhe o pleno uso dos referidos SAPs, levando-se em consideração que um usuário de SAP pode ter vários a sua disposição, pois, cada SAP pode atender determinada particularidade melhor que outros. Assim, uma aplicação, que receba de forma padronizada os parâmetros de configuração e transmita na sintaxe que o SAP escolhido entenda, remove do usuário a necessidade
de saber detalhes dos parâmetros de cada SAP e assim, ele pode alocar seu esforço para outros fatores de seu ambiente. Em Ícaro, além dos parâmetros comuns coletados pelas entradas genéricas, fez-se uso de parâmetros coringas, para poder atender parâmetros intrínsecos de cada SAP.
5. AMBIENTE E RESULTADOS EXPERIMENTAIS
Para avaliar a efetividade da proposta deste trabalho, um aplicativo protótipo foi desenvolvido utilizando Java e Netbeans. Com isso gerou-se classes de objetos para tratar a configuração específica de cada SAP abordado, classe genérica para tratar parâmetros comuns, classe mestre para gerenciar as classes específicas bem como gerar/aplicar configuração, além de classe para entrada dos parâmetros (uma interface gráfica que faz uso da passagem de parâmetros por chamada de procedimento).
Experimentos foram conduzidos sobre ambientes virtualizados através do software VirtualBox utilizando o protótipo, com o objetivo de verificar se o protótipo alcança a facilidade almejada de oferecer a sintaxe única de configuração independente do SAP escolhido.
5.1 Estrutura do Ambiente Experimental
A plataforma de desenvolvimento foi a Java SE (JDK versão 1.8.0_181, 64bits) e a IDE utilizada para o desenvolvimento do aplicativo bem como de suas sub-rotinas foi o Netbeans (Netbeans IDE 8.2, build 201609300101, 64bits) instalados em computador com SO Microsoft Windows 10 Education 64bits (versão 1903, compilação 18362.418).
Para a execução dos servidores e clientes de SAPs e assim testar o aplicativo desenvolvido na proposta, utilizou-se computador anfitrião com virtualização dos servidores do aplicativo através da ferramenta Oracle VM VirtualBox. A capacidade do computador em alocar máquinas virtuais dependeu principalmente da quantidade
de memória RAM do anfitrião, o qual possui 16 Gigabytes de memória RAM, sendo possível utilizar 24 servidores virtuais (12 do OrangeFS e 12 do Lustre, sendo 1 cliente e 11 servidores de cada SAP) simultaneamente (Figura 9). No restante, o anfitrião possui processador AMD FX8320 (8 núcleos, 3.5GHz), SSD PCIe (Adata SX8200NP) de 240 GB (máquinas virtuais criadas nesse dispositivo), placa de vídeo discreta (não consome memória RAM) NVIDIA GT620, interface de rede wired Realtek Gigabit, interface de rede wireless Intel AC9260.
Figura 9 - Ambiente Experimental
Fonte: elaborado pelo autor.
Cada servidor virtualizado foi criado com a seguinte configuração de hardware virtual:
• Aceleração: Paravirtualização padrão, VT-x/AMD-V e Paginação Aninhada habilitados;
• Memória RAM: 512MB;
• Interfaces de rede: 2 (uma rede interna, para comunicação entre os servidores da aplicação e a outra interface para conexão externa, acesso à internet, atualizações etc.);
• Armazenamento: unidade de disco virtual VDI dinamicamente alocado (para o Lustre, uma unidade de disco virtual VDI adicional, utilizada para armazenamento).
• Unidade óptica: unidade óptica virtual (para carga de imagens de disco ou mesmo discos físicos).
5.2 OrangeFS
Para os servidores que atendem ao OrangeFS, foi utilizado as versões de software:
• SO: Ubuntu Server 11.04 64bits;
• SAP: OrangeFS versão 2.9.3;
• SSH: OpenSSH versão 5.8p1;
A implantação do OrangeFS decorreu seguindo a documentação encontrada no portal do OrangeFS e adaptando conforme o SO utilizado (Apêndice I), primeiramente configurando as dependências, depois implantando o OrangeFS e por fim clonando as máquinas virtuais e ajustando configurações (endereço IP da rede interna, nome do servidor e alimentar arquivo /etc/hosts para resolução de nomes dos
servidores de forma direta) para posterior uso com o aplicativo, seja como servidores ou como clientes.
5.3 Lustre
Para os servidores que atendem ao Lustre, foi utilizado as versões de software:
• SO: CentOS versão 7.7.1908 64bits;
• SAP: Lustre versão 2.12.3;
• SSH: OpenSSH versão 7.4p1-21;
Para a implantação do Lustre, fez-se uso da documentação encontrada no portal do Lustre (Apêndice II), primeiramente configurando as dependências, depois implantando o Lustre com as modificações de kernel intrínsecas e por fim clonando as máquinas virtuais e ajustando configurações (endereço IP da rede interna, nome do servidor e alimentar arquivo /etc/hosts para resolução de nomes dos servidores de forma direta) para posterior uso com o aplicativo, seja como servidores ou como clientes.
5.4 Resultados
Ícaro prove um método público único para a entrada dos parâmetros no aplicativo, assim, com os servidores virtuais ligados e aguardando conexão e demais, fez-se uso de interface gráfica para coleta dos valores, e essa interface gráfica passou os parâmetros para Ícaro, o qual então executa as validações necessárias dos dados e aplica a configuração nos servidores conforme o SAP escolhido.
A interface gráfica (Figura 10), na coleta dos parâmetros divide-se em duas partes: comuns e específicos. Do Lustre para o OrangeFS altera-se a parte de parâmetros específicos (Tabela 3).
Tabela 3 - Relação Parâmetros Específicos conforme o SAP
Parâmetro Específico Rótulo Lustre Rótulo OrangeFS Coringa 1 “Partição a usar” “Pasta do OrangeFS” Coringa 2 “Interface de Rede” “Nome Arquivo de
Configuração”
Figura 10 - Interface Gráfica
5.4.1 Cenário de configuração 1 – Distribuição de arquivo
Neste cenário primeiro de configuração, os SAP são configurados com os parâmetros conforme a Tabela 4.
Tabela 4 - Parâmetros Cenário de configuração 1
Parâmetro Lustre OrangeFS
Tamanho das Tiras 524288
Quantidade das Tiras 4
Servidores de Dados lustre{200-205} ofs{200-205} Servidores de Metadados lustre{208-210} ofs{208-210} Local do Armazenamento /mnt/lustrehdd /mnt/orangehdd
Protocolo de Rede tcp
Nome do Sistema de Arquivos gianor
Coringa 1 (Lustre: partição a usar para armazenar, OrangeFS: caminho do programa)
/dev/sdb1 /opt/orangefs
Coringa 2 (Lustre: interface de rede utilizada, OrangeFS: nome do arquivo de configuração)
eth0 ofs-server.conf
Com os servidores configurados e ativos, configuração do cliente Lustre é possível (Figura 11). Para montar o Sistema de Arquivos do Lustre no cliente, necessita ter o MGS (lustre208), qual a rede LNET (tcp0), nome do sistema de arquivos (gianor) e por fim, o ponto de montagem no cliente (/mnt/lustre). Com o comando “lfs check servers”, é possível verificar os servidores que fazem parte do Sistema de Arquivos criado, bem como qual função faz no sistema (se serve Metadados ou Dados).
