Escalabilidade Horizontal

A seu dado tempo, a capacidade e o desempenho das infraestruturas em ambientes de produção deixam de servir os requisitos das várias aplicações, uma vez que existe um limite para o quanto se pode atualizar o mesmo servidor, adicionando novos recursos, com isto, estamos a falar de escalabilidade horizontal.

Escalar horizontalmente não é necessariamente um novo conceito, no entanto, é a es- tratégia ideal para suportar a evolução das infraestruturas de armazenamento de grandes volumes de dados.

O sistema Ceph segue uma arquitetura que escala horizontalmente, em que cada ser- vidor é carregado com discos, e que possibilita a adição de mais servidores de forma a melhorar a capacidade de armazenamento e desempenho do sistema de armazenamento. Uma das maiores vantagens de utilizar o Ceph é o facto do armazenamento escalar de acordo com os requisitos; a adição de novos servidores não tem qualquer impacto no sistema, exceto a migração de dados que é observada no momento em que o novo OSD toma a responsabilidade de armazenar todos os objetos que são mapeados com o seu identificador.

Os testes de escalabilidade horizontal centraram-se na instalação do Ceph, num se- gundo nó (totalizando o número de discos em 24) e num terceiro nó (36 discos).

Os testes iniciais de escalabilidade horizontal (Figura 4.16), em que não há replica- ção de objetos, mostram que o cluster escala horizontalmente, ou seja, com a adição de mais máquinas físicas podemos ver o desempenho a escalar. Para escritas, observam-se resultados semelhantes ao esperado, sendo 304 MB/s, 612 MB/s e 947 MB/s para 1, 2 e 3 nós; para leituras, obteve-se 794 MB/s, 1442 MB/s e 2012 MB/s, sendo estes resultados abaixo do resultado, o que significa uma perda de desempenho de 9 % para 2 nós e 15 % para 3 nós.

4. AVALIAÇÃOEXPERIMENTAL 4.5. Resultados e Análise

Nas situações em que introduzimos replicação de objetos (Figura 4.17), tendo uma réplica por objeto, podemos ver que para as escritas, obteve-se 335 MB/s e 773 MB/s para 2 e 3 nós, para leituras obteve-se 1401 MB/s e 2009 MB/s para 2 e 3 nós.

Figura 4.17: Gráfico comparativo de repositórios com replicação, 1 réplica por objeto, para 2 e 3 nós.

A replicação, seguramente não tem nenhum impacto em operações de leitura; o caso muda significamente para escritas (Figura 4.18), em que se regista 947 MB/s quando não incluímos replicação, 773 MB/s quando replicamos 1 vez o objeto e 336 MB/s quando replicamos 2 vezes cada objeto; sendo visível um maior agravamento do desempenho no último caso, verificando-se que o desempenho decrementa por um factor de 3. O impacto no desempenho, deve-se ao facto de ser necessário ao OSD primário esperar pela criação dos objetos no OSD secundário e terciário, para poder concluir a operação com sucesso.

Por último, é reunido os resultados de testes anteriores e são comparados (Figura 4.19), mas também é introduzido um novo tipo de mecanismo para tolerância a faltas, através do mecanismo erasure coding. Uma pool com erasure coding em que dividimos um objeto em objetos de dados ou data chunks, sendo calculado m objetos de paridade (ou coding chunk), para permitir a tolerância a falta de um disco, juntamente com k-m objetos onde irão ser guardados os dados efetivos (k é por isso mesmo o total de discos a serem utilizados). A utilização de repositórios com erasure coding, implica que é necessário me- nos espaço de armazenamento, comparando com replicação de objetos , neste caso em especifico precisa de 33

Como podemos ver, o desempenho de leituras para 2 nós com replicação e para 3 nós com erasure coding é semelhante, 335 MB/s e 336 MB/s, , apesar de estarmos com mais uma máquina, as leituras incidem sobre os nós responsáveis por guardar os objetos de

4. AVALIAÇÃOEXPERIMENTAL 4.5. Resultados e Análise

Figura 4.18: Gráfico comparativo de repositórios com replicação, 1 réplica por objeto, para 2 e 3 nós.

dados; estes dois casos também são semelhantes para escritas, devendo-se novamente ao facto de mesmo com 3 nós, o facto de ser necessário o cálculo do objeto de paridade leva a um impacto muito grande no desempenho. Os casos, em que temos um cluster formado por 3 nós e um repositório replicado com 1 ou 2 réplicas por objeto, são semelhantes apenas em leituras, 2009 MB/s e 1998 MB/s, pois neste caso a operação é exatamente a mesma; para escritas o desempenho diminui de 773 MB/s e para 336 MB/s, quando aumentamos o nível de replicação, devido ao facto de ser necessário contactar um 3º servidor e enviar uma operação de escrita com esse objeto.

Figura 4.19: Gráfico comparativo de repositórios com replicação e com erasure coding.

Em conclusão, podemos observar na tabela 4.5 que as diversas configurações acar- retam com vantagens e desvantagens, a nível de tolerância de faltas e de desempenho,

4. AVALIAÇÃOEXPERIMENTAL 4.5. Resultados e Análise

Config. Nós Pool Tol. a Falhas (discos) Escritas (MB/s) Leituras (MB/s)

1 1 Replicada 0 304.301 793.66 2 ₂ Replicada 0 650.076 1443.067 3 Replicada 1 334.501 1401.064 4 3 Replicada 0 946.993 2012.071 5 Replicada 1 772.714 2009.329 6 Replicada 2 335.645 1998.885 7 Erasure Coded 1 495.02 1236.797

Tabela 4.5: tabela comparativa do desempenho de vários tipos de pools.

cabe ao administrador do armazenamento em questão decidir qual o aspeto a que deve dar mais prioridade; caso decida dar prioridade à utilização de espaço em deterioração de tolerância a faltas, deve proceder com a configuração número 4, obterá o melhor pro- veito da largura de banda; caso decida dar prioridade à utilização de espaço mantendo a tolerância a falta de 1 disco, configuração número 7, deverá considerar que o sistema irá operar com o mesmo desempenho que um sistema com dois nós (sem replicação), pois para cada operação, um dos três nós estará a calcular e armazenar o objeto de paridade; caso o administrador priorize a segurança de dados (isto é, priorizar a recuperação de dados em caso de falta), situação número 6, deverá ter em conta que esta configuração consome mais espaço útil em discos que qualquer outra configuração anunciada; por fim, se o administrador quer um equilíbrio entre desempenho e utilização de espaço útil dos discos, deve optar pela configuração número 5. Para finalizar, podemos através dos da- dos apresentados, que o Ceph escala linearmente, dado que o desempenho aumenta em conformidade com o número de nós.