fabionevesrezende/trabalho-sd-2018-2

Trabalho de sistemas distribuidos 2018-2

Importante!!!

Conforme conversado na última apresentação(alunos Nicolas e Pedro no dia 19/12), as alterações foram realizadas permitindo que o servidores subam corretamente em conjuntos com suas respectivas replicas.

Ao iniciar o cliente, por algum motivo não identificado os primeiros comandos demoram um pouco para serem respondidos, mas o cliente funciona.

Instalação

Para rodar a aplicação, é necessário ter as bibliotecas python: termcolor, pytest, pyyaml e gRPC

sudo apt install python-pip
sudo python -m pip install importlib
sudo python -m pip install termcolor
sudo python -m pip install pytest
sudo python -m pip install pyyaml
sudo python -m pip install grpcio grpcio-tools
sudo python -m pip install numpy
sudo python -m pip install future
sudo python -m  pip install concoord

Geração de stubs

python -m grpc_tools.protoc -I . --python_out=. --grpc_python_out=. interface.proto

Execução

Para iniciar os servidores:

sudo python inicia_servidores.py 2 2

Para corretude da aplicação, é necessário definir um M que serão os bits possíveis da chave, e o N: número de servidores, sendo M o primeiro parâmetro e N o segundo. Se precisar de ajuda:

python inicia_servidores.py -h

Testes

trabalho-sd-2018-2's Issues

Especificar as portas de comunicação via arquivo de configuração

Implementar a configuração de portas via arquivos externo conforme descrito no slide

"Todas as portas usadas na comunicação são especificadas via arquivos de configuração."

Tratar o Read

Tratamento de falhas

• Assuma que não haverão falhas permanentes ou envio de
  requisições enquanto algum nó estiver falho.
• Nós podem ser reiniciados e, como na primeira entrega,
  devem ter seu estado recuperado pelo uso do log de
  operações e de snapshot do banco de dados

Snapshoting

• A cada U segundos, o estado atual do banco será gravado
  em um arquivo nomeado snap.X, onde X é um contador de
  logs. Isto é, o primeiro snapshot será gravado como snap.1,
  o segundo como snap.2 e assim por diante.
• As operações executadas antes de um snapshot X serão
  gravadas e um arquivo de log.(X-1). O primeiro arquivo de
  logs será então o log.0.
• Uma vez iniciado snapshot que cria snap.X, nenhuma nova
  operação será escrita em log.(X-1). Novas operações são
  escritas em log.X.
• Serão mantidos pelo sistema os últimos 3 arquivos de log e
  de snapshot. Isto é, se o último snapshot executado foi o
  décimo, então há no sistema os logs log.8, log.9. log.10
  (sendo escrito), e os snapshots snap.8, snap.9, e snap.10.

Read de item J é executado e novo atualizado é recebido no cliente

Reexecutar todos os testes anteriores, paralelamente, com 10 clientes, com chaves diferentes e verificar que os resultados não se alteram.

Roteamento

De acordo com a especificação da entrega anterior, cada
requisição é colocada em uma fila F1, de onde é re-enfileirada
nas filas F2 e F3.

Para esta entrega, antes de re-enfileirar a mensagem, o
servidor deverá analisar se é realmente responsabilidade
deste servidor.

• Caso o seja, a requisição é re-enfileirada em F2 e F3. Caso
  contrário, será colocada em uma fila F4.
• Um thread retira de F4 e invoca, consultando uma tabela de
  roteamento, o nó responsável pela requisição para que a
  processe ou que pelo menos esteja mais próximo que o
  mesmo.
• O servidor primeiro contactado pelo cliente é o responsável
  por enviar a resposta para o cliente

Particionamento

O particionamento da responsabilidade sobre os dados seguirá o
esquema de anel lógico definido pelo Chord.

• Seja n o número de nós a serem colocados no sistema na
  execução de testes.
• Cada servidor é identificado por um número de m bits.
• O primeiro nó a entrar no sistema recebe necessariamente o
  identificador 2m − 1
• O nó seguinte recebe identificador menor 2m/n que o
  anterior.
• Seja uma sequência de nós com identificadores X < Y < Z.
  O nó Y é responsável pelos dados com chaves na faixa
  (X, Y].

Create de item I existente é executada e NOk é recebido pelo cliente

Read de item I é executado e valor escrito anteriormente é recebido no cliente.

Ordem de execução

• Escrever o valor 1 no item a0
• Repita de i = 1 ate i = 1000 vezes
  • Ler o valor de v = ai−1
  • Escrever o valor de ai = v + 1
• Ler o valor de a1000 e confirmar que é igual a 1001.

Update de item I é executado e Ok é recebido pelo cliente

Update de item J não existente é executado e NOk é recebido pelo cliente

Comunicação

• Toda comunicação deve ser agora feira usando gRPC.
• Cada operação é realizada via uma função diferente (i.e., há
  uma função para C, outra para R, ...).
• Servidores redirecionam requisições também usando gRPC,
  usando a mesma interface usada por clientes.
• Toda requisição é executada assincronamente do ponto de
  vista de quem invoca a requisição.
• Uma requisição é redirecionada para o nó seguinte ou
  anterior, dependendo de qual o caminho mais curto até o nó
  responsável pelos dados.
• Múltiplos saltos podem ser necessários até que a requisição
  seja respondida.

Create de novo item I é executada e Ok é recebido pelo cliente.

Corrigir a resposta de conexão para que seja possível responder o usuário em caso de erro;

Read de item I é executado e novo atualizado é recebido no cliente

Parar de salvar operações de READ no log

Create de item I não existente é executada e Ok é recebido pelo cliente

Recuperação do estado

• 5 itens são criados.
• processo servidor é morto
• processo servidor é reiniciado
• 5 itens criados anteriormente são lidos
• Repetir com novos itens, sem limpar o estado

Delete de item J não existente é executado e NOk é recebido pelo cliente.

Utilizar array de bytes no mapa

Implementar o delete

Delete de item existente é executado e Ok é recebido pelo cliente

Read de item J não existente é executado e NOk é recebido pelo cliente