Sistemas Distribuídos

Primavera 2021

Overvisão

15-440 é um curso introdutório em sistemas distribuídos. A ênfase será dada às técnicas de criação de sistemas distribuídos funcionais, utilizáveis e escaláveis. Para tornar as questões mais concretas, a turma inclui vários projectos de várias semanas que requerem um design e implementação significativos

Os objectivos deste curso são duplos. Primeiro, para que os alunos adquiram uma compreensão dos princípios e técnicas por trás do projeto de sistemas distribuídos, tais como travamento, simultaneidade, caching, prefetching, agendamento e comunicação através da rede. Segundo, para que os alunos adquiram experiência prática na concepção, implementação e depuração de sistemas distribuídos reais.

Os principais temas que este curso irá ensinar incluem:

• Escassez de recursos, agendamento, e simultaneidade
• Latência de comunicação e largura de banda
• Nomeação
• Abstracção e modularidade
• Imperfeita comunicação e outros tipos de falhas
• Protecção de danos acidentais e maliciosos
• Optimismo
• Consenso
• Utilização de instrumentação, monitoramento, e ferramentas de depuração na resolução de problemas.
• Desenho, implementação e depuração de projetos de programação substancial que abranjam os temas acima

Grading

Todo o trabalho do curso é feito individualmente. Não há equipes ou parceiros de projeto. Para ofertas presenciais deste curso (pré-COVID e, espera-se, pós-COVID) a avaliação foi baseada em projetos (45%), conjuntos de problemas (20%), exame intermediário (15%), e exame final (20%). Para a oferta do curso na Primavera de 2021, devido às restrições da COVID, os exames são substituídos por conjuntos de problemas cumulativos. Estes são como os exames de livro aberto, mas sem a pressão do tempo. Como o seu nome indica, eles incluem todo o material coberto na aula até esse ponto. Referimo-nos aos outros conjuntos de problemas como conjuntos de problemas tópicos, uma vez que se concentram em tópicos. Assim, a avaliação da Primavera de 2021 será a seguinte (todos os pesos aproximados, dentro de um intervalo de 5%):

• 45% para 4 projectos, igualmente ponderados
• 20% para 4 conjuntos de problemas tópicos, igualmente ponderados
• 15% para conjunto de problemas cumulativos do meio do semestre
• 20% para conjunto de problemas cumulativos finais.

Resultados de Aprendizagem

Esperamos que os alunos adquiram uma profunda compreensão, fluência no raciocínio e habilidades práticas de implementação dos seguintes conceitos centrais de sistemas distribuídos:

>

1. • Comunicação e chamada de procedimento remoto
   • Controle da semântica e limitações da linguagem
   • Exatamente-um, at-most-once, at-least-once
   • Serialização e des-serialização
   • Discussão final e sua aplicação a sistemas reais
   • Integração com threading
   • Concorrência de operações
2. • Caching de dados e umcopy semantics
   • Protocolos de consistência de cache e tradeoffs de implementação
   • Origins of temporaland spatial locality
   • Métricas de qualidade de cache
   • Protocolos de consistência específicos da aplicação
   • Pré-instalação: benefícios e riscos
   • Extração de dicas
   • Buffer bloat
3. • Falhas em sistemas distribuídos: origens e estudos empíricos
   • Falhas rápidas e falhas bizantinas
   • Limites fundamentais de resiliência a falhas
4. • Tolerância a falhas: transações atômicas; propriedade ACID
   • Desafios de implementação
   • Sombra, listas de intenções e registro de operações de escrita
   • Tradeoffs no registro físico e registro de operações
   • Transações aninhadas
   • Transações distribuídas
5. • Consenso e cadeia de bloqueios: unanimidade (compromisso em duas fases)
   • Majoridade (eleição do líder, Paxos)
   • Bizantina (disparo único e Dolev-Strong)
   • Replicação da máquina e Streamlet
   • Bitcoin

6. Padrões comuns de programação como Map-Reduce, MPI e GraphLab

7. (Só se o tempo permitir):
   >
   • Aquecer alta disponibilidade: preservação baseada em votação de semântica de uma cópia
   • Taxonomia de estratégias de replicação: abordagens pessimistas e otimistas
   • Conflitos de leitura-escrita e escrita-escrita
   • Estratégias servidor-cliente e peer-to-peer
   • Caching e operação desconectada; resolução de conflitos
   • Exploração de baixa largura de banda para melhorar a disponibilidade

Logística do curso

Professores

Nome	Horas de escritório	Escritório	Telefone	E-Mail Andrew
Mahadev Satyanarayananan (Satya)	Tua 1:00 – 15:00 pm	GHC-9123	x8-3743	satya
Padmanabhan Pillai (Babu)	Wed 11:00 am – 13:00 pm	GHC-9232		pspillai
Runting Shi (Elaine)	Mon 4:00 – 6:00 pm	CIC-2217		Contacto através de Tela

Assistentes de Ensino

Nome	Horas de escritório	Andrew email
Nathan Ang	Thu 2:00-4:00 pm	nathanan
Junwon Chang (Joseph)	Sat 9:00-11:00 am	junwonc
Wenxin Ding (Freda)	Fri 10:00-12:00	wenxind
Timothy Ganger	Sat 4:00-6:00 pm	tganger
Ziying He	Fri 5:00-7:00 pm	ziyingh
Roger Iyengar	Wed 1:00-3:00 pm	raiyenga
Ishaan Jaffer	Thu 4:00-6:00 pm	ijaffer
Ibnul Jahan	Tue 4:00-6:00 pm	iej
Chen Jin (Cristal)	Fri 8:00-10:00	chenj
Yajin Li	Mon 10:00-12:00 pm	yajinl
Diego San Miguel	Sex 2:00-4:00 pm	dsanmigu
Riccardo Santoni	Mon 8:00-10:00 pm	rsantoni
Yiwen Song (Victor)	Thu 9:00-11:00 pm	yiwenson
Haithem Turki	Wed 3:00-5:00 pm	hturki
Clarissa Xu	Tue 6:30-8:30 pm	csxu

Palestras

• Terças e quintas-feiras, 10:40 – 12:00 meio-dia
• Zoom links e gravações de vídeo: Na página Tela para este curso
• Sem aula: Terça-feira 23 de fevereiro (Dia de intervalo), quinta-feira 15 de abril (Carnaval de Primavera)
• Última aula: Quinta-feira, 6 de maio

Recitações

• Tempo: quartas-feiras 7:00 – 19:50pm (Seção A), 8:00 – 20:50pm (Seção B)
• Zoom links e gravações de vídeo: Na página Tela para este curso

Course Notes

Será colocado na área do curso AFS em: /afs/andrew/course/15/440/classnotesApós cada aula. Estas notas são apenas para seu uso pessoal. Por favor não as distribua.

Livros de texto e leituras opcionais

Não há livros de texto necessários. Aqui estão três boas referências a utilizar para leitura opcional:

• “Sistemas Distribuídos”: Principles and Paradigms” por Andrew S. Tanenbaum e Maarten Van Steen, Terceira Edição (2017), Prentice Hall
• “Guide to Reliable Distributed Systems” por Kenneth P. Birman, Springer
• Foundations of Distributed Consensus and Blockchains by Elaine Shi (2020, manuscrito do livro)

Além disso, o link “Leituras” no topo desta página web tem algumas leituras opcionais específicas que mencionaremos em diferentes pontos das palestras. Os pdf’s destas leituras opcionais estão disponíveis no site deste curso.

Políticas do curso

Prrequisitos

Porque este curso tem uma grande componente de projeto, você deve ser proficiente em programação em C e Java em sistemas UNIX. É necessário que você tenha feito 15-213 e obtido um “C” ou superior, uma vez que muitas das habilidades de programação que você vai precisar são ensinadas nesse curso. Se você recebeu um C em 15-213, você deve se reunir com seu orientador acadêmico para discutir sua formação antes de fazer 15-440, talvez fazendo um curso adicional para aprimorar suas habilidades em sistemas.

Policy on Academic Integrity

A política de integridade acadêmica da Carnegie Mellon University se aplica a este curso. Todos os alunos devem rever cuidadosamente esta política e aderir a ela para todos os aspectos deste curso.

Guia de Colaboração:

• Os alunos são encorajados a conversar uns com os outros, com os TAs, com os instrutores, ou com qualquer outra pessoa sobre qualquer uma das tarefas. Qualquer assistência, no entanto, deve limitar-se à discussão do problema e ao esboço de abordagens gerais para uma solução.
• Cada aluno deve escrever as suas próprias soluções para conjuntos de problemas. Todos os projetos devem ser feitos individualmente.
• Consultar a solução de outro aluno é proibido, e as soluções apresentadas não podem ser copiadas de nenhuma fonte. Estas ações constituem trapaças.
• Se você tiver alguma dúvida sobre se alguma atividade constituiria trapaça, sinta-se à vontade para perguntar aos instrutores.

Guia de Compartilhamento: Você não pode fornecer trabalhos que você completou durante 15-440 para outros alunos em futuras instâncias deste curso ou para uso em futuras instâncias deste curso (assim como você não pode usar trabalhos completados por alunos que fizeram o curso anteriormente).

Recordingings

Para a Primavera de 2021, sessões de Zoom de cada palestra e recitação serão gravadas pelos Serviços de Computação da CMU e postadas na página de Tela para este curso. Todas as outras gravações são proibidas.

Limite no uso do tempo de TA

Para ser justo com todos, especialmente quando há uma longa fila de alunos esperando pela atenção de uma TA, haverá um limite de 10 minutos em todas as consultas. Se um aluno não for atendido ao final dos 10 minutos, ele volta para o final da fila antes de conseguir mais tempo com a TA. Esteja preparado antes de se reunir com um TA. Se você precisar de ajuda para encontrar um bug, reduza e simplifique o problema antes de se reunir com o TA.

Piazza Policy

Este curso usa o site Piazza para responder perguntas: aqui está a página Piazza para este curso.

Pense na Piazza como levantar a mão na aula e fazer uma pergunta. Nenhuma pergunta é estúpida demais para se fazer, por isso não tenha medo. Para cada pessoa que faz uma pergunta, há provavelmente muitas outras a quem a mesma pergunta já surgiu ou irá surgir em breve. A resposta à sua pergunta pode beneficiá-los também. Além disso, pode haver algumas pessoas a quem a sua pergunta não tenha ocorrido. Ao fazer a pergunta, você está ajudando-as a ver uma sutileza que elas podem não ter visto antes. O e-mail direto para os instrutores não será respondido.

Em todos os momentos, esperamos que você use o seu bom senso nos seus posts na Piazza (perguntas, bem como respostas às perguntas dos colegas estudantes). Parte do processo de aprendizagem é lutar com o material até que você chegue à percepção certa para que você o entenda. A colocação de demasiados detalhes em resposta a um pedido de assistência pode prejudicar a aprendizagem. Por outro lado, às vezes é ótimo ser empurrado na direção certa quando não se consegue sair de uma rotina. E, claro, mal-entendidos sobre a tarefa ou ferramentas disponíveis devem ser ajudados rapidamente. Por favor, use o seu melhor julgamento ao postar no site Piazza, como se você estivesse colaborando pessoalmente com os seus amigos. Algumas diretrizes gerais:

Exemplos de coisas boas para postar e responder:

• Entendimentos do trabalho
• Clarificações sobre os requisitos
• Bugs na especificação do trabalho ou implementação de referência ou testes
• Pequeno, perguntas detalhadas sobre o funcionamento das chamadas ao sistema, funções, etc.
• Coisas que parecem ir em um FAQ para a atribuição

Exemplos de coisas ruins para postar ou responder:

• Mais do que algumas linhas de código
• Explicações profundas de como o seu sistema funciona
• Perguntas sobre a melhor abordagem para arquitectar o sistema a um nível elevado
• Perguntas sobre a sua nota

E esperamos que tenha feito um esforço razoável para pensar por si mesmo antes de colocar uma pergunta de praça. Isto é especialmente verdade no que diz respeito à depuração do seu código. Você tentou as páginas de homem? Você fez uma busca no Google por recursos possivelmente relevantes? Olhou para as perguntas anteriores que as pessoas já fizeram e para as respostas fornecidas? Você inseriu printf’s e tentou entender o que está acontecendo com seu código?

Não use o autolab como uma ferramenta de depuração. Esperamos que você tenha feito um esforço razoável para ter seu código depurado antes de enviar para o autolab. Criar casos de teste e testar o seu código é parte do que é um projeto. Sem fazer esse esforço, você está perdendo uma parte importante da oportunidade de aprendizagem no curso. A submissão ao laboratório automático deve ser o último passo de um processo no qual você testou, depurou e melhorou seu código até o limite máximo de suas habilidades. Enviar um autolab dump em um post da piazza e dizer “por favor, ajude” é uma violação flagrante da etiqueta da piazza.

Postes privados na Piazza não são suportados. Esta é uma decisão política para esta classe. Lembre-se, postar na Piazza é semelhante a levantar a mão e fazer uma pergunta. Outros alunos se beneficiam de você fazer a pergunta, e ver a resposta dos instrutores. Nós permitimos que as suas mensagens sejam anónimas para os outros alunos, se assim o desejar. Isso já é um grau de privacidade além do que é possível quando se faz uma pergunta em sala de aula. Para as ocasiões genuinamente raras em que você precisa fazer um pedido privado que não esteja relacionado ao conteúdo do curso, foi criada uma mailing list especial privada.

Para pedidos que realmente precisam ser privados Enviar e-mail para[email protected]e um dos instrutores irá responder. O e-mail para esta lista envolvendo o conteúdo do curso (por exemplo, esclarecimentos para o material de aula) será ignorado; você deve postar tais perguntas no Piazza.

Policy on Late Submissions

Para projetos:

• Cada aluno terá cinco dias de atraso para usar durante todo o semestre. Estes dias de atraso destinam-se a prestar contas de feriados, viagens, entrevistas, um frio e outras situações semelhantes. Você é livre para usá-los por qualquer motivo, sem pedir permissão dos instrutores. Você pode usar no máximo dois dias de atraso em qualquer data de vencimento (ou seja, para projetos com vários pontos de verificação, você pode usar até dois dias de atraso para cada ponto de verificação). Os dias de atraso serão automaticamente aplicados em ordem cronológica, portanto você não pode escolher adiar o uso de um dia de atraso para uma atribuição futura de maior peso.

• Um dia de atraso = (0,24] horas após a data de vencimento; dois dias de atraso = (24, 48] horas após a data de vencimento; etc.

• Se você usar todos os seus dias de atraso, você pode enviar com atraso para uma penalidade de 15% por dia, por até dois dias. Em outras palavras, se você usou todos os seus dias de atraso, você ainda pode enviar para os próximos dois dias, incorrendo em uma penalidade de 15% para cada um desses dias (dias de tolerância).

• Você não pode combinar dias de atraso e dias de tolerância para enviar mais de dois dias de atraso.

Para conjuntos de problemas: Nenhuma submissão tardia é aceite, com ou sem penalização. Certifique-se de enviar no prazo.

Guia de estilo para projetos

Além de testar a funcionalidade do seu código, também estaremos reservando uma parte dos pontos de cada projeto para o seu estilo e legibilidade. O mais importante é um estilo consistente e legível. Nós estamos principalmente procurando ver que você escolheu um estilo que seja legível e razoável, e que você use o mesmo estilo consistentemente ao longo de um projeto. Use o bom senso: não tenha linhas de código de 500 caracteres, não nomeie suas variáveis foo (a menos que isso faça sentido em seu contexto), e e evite misturar convenções de casos aleatoriamente.

Estaremos procurando as seguintes coisas:

Documentação Uma boa documentação é importante: para você mesmo no futuro, para outros mantenedores do código, e neste contexto, para os graduadores que estarão olhando para o seu código. Não sinta a necessidade de documentar cada linha de código (pois um bom código também deve ser autodocumentado de certa forma), mas normalmente é bom destacar o uso geral e o propósito de cada função, assim como blocos de código grandes ou complexos. Também é boa prática incluir um cabeçalho de arquivo em cada arquivo, detalhando como esse arquivo se encaixa na estrutura do projeto como um todo. Espaço em branco Por favor, seja consistente. Por favor, não use tab 2 espaços em alguns lugares e 4 em outros. Seja razoável e use o espaço em branco para garantir que o seu código seja legível. Comprimento da linha Seremos razoáveis quanto ao comprimento da linha, desde que você seja consistente e que seus limites de linha sejam razoáveis (500 caracteres não é… 80 ou 120 caracteres é comumente usado e aceito). Nomes das variáveis Os seus nomes de variáveis devem dar uma indicação clara do que elas representam ou do seu caso de uso. Código Morto/Teste Tente não enviar código que esteja repleto de instruções de impressão de depuração ou grandes pedaços de código comentados. Isso diminui a legibilidade e distrai do código que será realmente executado em produção. Design Tente projetar seu código e projetos de tal forma que seja razoavelmente modular. As funções de 5000 linhas são geralmente um sinal de mau design e lhe darão dores de cabeça mais tarde.

Aqui está um guia de estilo Google que pode ser útil.

Bem-estar

Aqui estão algumas dicas para o bem-estar.