Comentários sobre geo-replicação de dados

O uso de temporizadores em sistemas que operam sobre redes não síncronas é comum. Hybris (Seção 3.1.8) utiliza um temporizador para decidir se consegue armazenar dados em apenas f + 1 provedores. Em caso de falha, provedores adicionais precisam ser contactados. DepSky e Gnothi (Seção 3.1.3) sugerem o uso de temporizadores para melhorar a escrita e a leitura de dados, atuando apenas em réplicas preferidas. Réplicas adicionais são contactadas após um timeout. Temporizadores são usados também para vericar omissão ou parada de líder em pro- tocolos que ordenam requisições com uso de sequenciadores xos (por exemplo, PBFT, Seção 2.1.4).

São diversos os problemas que surgem ao usar temporizadores em redes não síncronas. Um problema prático consiste no fato de que contratos de utilização de recursos em provedores de nuvens são feitos com base em necessidades e cargas médias, e não em valores de pico, de- vido a custos (CHO; AGUILERA, 2012). Assim, praticamente pode-se esperar que ocorram incrementos na latência, mediante eventos como particionamento de rede ou sobre-alocação de recursos. Outro problema encontra-se na denição precisa de um temporizador, que requer infor- mações de tempo máximo de processamento, tempo de comunicação em rede e diferença entre relógios dos processos (Seção 2.1.2). É difícil denir essas informações fora do contexto de ambientes síncronos.

No contexto de armazenamento, sistemas que evitam o uso de temporizadores ainda estão sujeitos a desperdício de recursos. O uso de quóruns (Seção 2.1.5), praticado pelo DepSky (Seção 3.1.3) e pelo MDS- tore (Seção 3.1.7), dispensa temporizadores. Requisições pendentes são canceladas quando o quórum mínimo é obtido, tornando o protocolo livre de espera (Seção 2.2.2). Em escrita de dados, o cancelamento pode ocorrer em diversos momentos, inclusive quando o dado é quase totalmente enviado ao provedor. Esses dados escritos parcialmente no provedor são taxados, apesar de não serem usados pelo protocolo.

A paralelização de tarefas é uma estratégia que pode aumentar a eciência de sistemas, reduzindo a latência geral. Reduzir latência é o objetivo de vários sistemas que toleram faltas. O Vivace (Seção 3.1.4) busca manter um bom desempenho durante congestionamentos de rede, tornando mensagens de metadados menores e com prioridade de rote- amento. O DepSky, o SPANStore e o Hybris mencionam o uso de réplicas preferidas, a m de obter menor latência nas operações. Uma possibilidade pouco explorada é a execução de tarefas paralelamente ao envio de dados. Uma análise de tráfego em sistemas de armazena-

mento remoto (HU; YANG; MATTHEWS, 2010) sugere que a execução de tarefas de pré-processamento (cifragem, compressão, criação de me- tadados), que fazem uso intensivo de CPU, podem reduzir a latência geral de operação. Apenas no Vivace (Seção 3.1.4) observou-se uma melhoria de eciência relacionada à paralelização de tarefas. No caso, a leitura de dados e a escrita de metadados mais recentes (write-back, Seção 2.1.5) são realizadas em paralelo. Em nenhum dos outros traba- lhos relacionados observou-se a prática desta paralelização.

O uso de latência dos provedores tem ganhado importância na construção de sistemas geo-distribuídos mais ecientes. O SPANStore (Seção 3.1.6) atualiza recomendações fornecidas ao usuário observando latências entre provedores e padrões de acesso aos dados. No DepSky (Seção 3.1.3), os critérios sugeridos para a ordem de acesso a provedo- res são a latência e o custo do provedor. A latência tende a apresentar relação direta com localização geográca. Porém, há provedores próxi- mos aos clientes que possuem latências maiores do que provedores mais distantes (COUTO et al., 2014). Assim, é possível usar provedores de menor latência e simultaneamente favorecer a sobrevivência do dado.

Um fato conhecido e que se aplica ao cenário de nuvens híbridas é o uso de provedores de dados locais (próximos ao cliente) para favorecer desempenho. Provedores locais ao cliente de modo geral não são taxa- dos e possuem baixa latência. RACS apresenta, dentre seus trabalhos futuros, o uso integrado de um PC desktop local atuando como servi- dor, uma nuvem e um cluster. Vivace (Seção 3.1.4) usa réplicas locais como cache para aumentar desempenho. Para cada réplica remota, há uma réplica local que é atualizada de forma síncrona. Réplicas remotas são atualizadas assincronamente. Hybris (Seção 3.1.8) menciona o uso de réplicas locais para aumentar desempenho.

Uma comparação entre os trabalhos de armazenamento apresen- tados (Tabela 1) permite observar que, apesar de tolerância a faltas bizantinas ter sido tratada em trabalhos anteriores, a maioria dos tra- balhos trata apenas faltas de parada. Nota-se que Gnothi usa tem- porizadores mas não menciona uso de latências para possíveis ajustes no temporizador. Apenas o Hybris e o SPANStore usam efetivamente as latências dos provedores na operação de seus protocolos (Vivace e DepSky apenas sugerem esse uso como forma de melhorar a eciência do sistema). Em detalhe, o SPANStore considera o cliente localizado no interior de um data center, onde encontram-se também as réplicas. Clientes reais (usuários) acessam o cliente do SPANStore localizado no data center mais próximo. Portanto, apenas no Hybris a latência entre um cliente externo (ao data center) e o provedor é considerada.

Tabela 1  Características dos trabalhos de armazenamento em nuvens. Trabalho Réplicas

de Dados F Consist. EC timer Latência

RACS m + f p eventual S N N

ICStore m + f p eventual opc N N

DepSky 3f + 1 B eventual opc N N*

VivaceF 2f + 1 p atômica N N N* Gnothi f + 1 p atômica N S N SPANStore f + 1 ou 2f + 1 p eventual / atômica N S S MDStore 2f + 1 B atômica N N N Hybris f + 1 a 2f + 1 p / B atômica opc S S

F=tipo de falta, p=parada, B=bizantina, opc=opcional, EC=usa erasure code, timer=usa temporizadores, Latência=considera latências observadas pelo cliente.

FPara o Vivace foi considerado apenas o algoritmo ABD modicado.

*Sugere uso de provedores com menor latência, pelo cliente.

Fonte: próprio autor (2017).

O armazenamento de dados com uso de erasure code é obriga- tória apenas no RACS. No DepSky-CA, usa-se EC por necessidade de espalhar o fragmento da chave de cifragem. O Hybris apresenta o EC como possibilidade, ao custo de aumentar o número de provedores. Discussões sobre EC e replicação integral são apresentadas em ponto posterior desta tese (Seção 7.2.6).