menu_book Índice

Logo UFPR

DEE354 - Sistemas Distribuídos

Logo Curso

Disciplina: DEE354 – Sistemas Distribuídos

Universidade Federal do Paraná

Professor: Prof. Jéfer – jefer@ufpr.br

Carga Horária: 60 horas (15 semanas, 4h/semana)

Faltas: 60 horas x 0,25 = 15 horas ou 7 aulas

Pré-requisitos: Redes de Computadores, Sistemas Operacionais, Programação Concorrente

Logo UFPR

LTSP e Sistemas Multiusuários

Logo Curso

LTSP (Linux Terminal Server Project) é um projeto open source que permite a execução de múltiplas sessões de usuários, com processamento centralizado em um único servidor Linux.

Em vez de computadores completos, os usuários utilizam Thin Clients — máquinas simples, com pouco poder de processamento, que apenas exibem a interface gráfica e enviam comandos de entrada (mouse/teclado).

Funcionamento do LTSP

  • O servidor LTSP executa todas as aplicações (LibreOffice, navegadores, etc.).
  • O cliente leve se conecta via rede (geralmente PXE boot), carrega uma imagem mínima e inicia uma sessão remota no servidor.
  • A comunicação ocorre por protocolos como SSH, X11 ou VNC.

Esquema Ilustrativo

Esquema LTSP Moderno

Vantagens do LTSP

  • Redução de custos: Thin clients podem ser reaproveitados de máquinas antigas.
  • Manutenção centralizada: Apenas o servidor precisa de atualizações e configuração de softwares.
  • Segurança: Os dados e aplicações estão centralizados.
  • Eficiência energética: Menor consumo em comparação a PCs tradicionais.

Aplicações Reais

  • Laboratórios escolares e universitários com orçamento limitado.
  • Ambientes corporativos com terminais para atendimento ao cliente (bancos, repartições públicas).
  • Telecentros, bibliotecas e centros comunitários.

Comparação com Outros Modelos

  • LTSP vs. Virtualização: LTSP oferece sessões independentes para usuários, mas todos os processos rodam diretamente no servidor, sem uma VM por usuário.
  • LTSP vs. VDI (Virtual Desktop Infrastructure): VDI geralmente usa máquinas virtuais para cada usuário, o que exige mais recursos.

Sistemas Operacionais Compatíveis

  • Distribuições Linux com suporte a LTSP: Ubuntu, Debian, Fedora, openSUSE.
  • LTSP moderno (versão 20+): Compatível com Ubuntu 20.04+ e Debian 11+, com suporte a ltsp-manager e imagens baseadas em systemd-nspawn.
Logo UFPR

Clusters e HPC: Arquitetura, Aplicações e Futuro

Logo Curso

O que é um Cluster?

Definição: Sistema composto por múltiplos computadores (nós) interligados, operando como uma única entidade lógica para:

Desempenho (HPC)
Escalabilidade Horizontal
Tolerância a Falhas

Arquitetura de um Cluster

Diagrama Cluster
Head Node (Gerenciador) Compute Nodes (Tarefas Paralelas) Storage (Lustre, NFS) Rede (Infiniband/100Gbps)
  • Head Node: Agenda tarefas (SLURM, PBS) e gerencia usuários.
  • Compute Nodes: Nós homogêneos ou heterogêneos (CPU/GPU).
  • Comunicação: Latência ultrabaixa (Infiniband) ou Ethernet.

Stack Tecnológico

Hardware

x86_64, ARM, GPUs (NVIDIA A100), TPUs, FPGAs

Rede

Infiniband (200Gbps), Ethernet, NVLink (GPU-to-GPU)

Software

Linux (CentOS/Rocky), SLURM, Kubernetes, MPI, OpenMP

Clusters na Prática

2009: Avatar

4.000 nós Linux (Top500) para renderização 3D.

2012: PlayStation 2 Cluster

70 PS2 simulando buracos negros (Universidade de Illinois).

2023: Meta RSC

16.000 GPUs NVIDIA para treino de IA.

O Futuro: Cloud HPC e Edge Clustering

Cloud HPC

AWS Batch, Azure CycleCloud, Google HPC Toolkit.

Edge Clusters

Clusters descentralizados (ex.: carros autônomos).

Logo UFPR

Grid Computing: Potência Distribuída Globalmente

Logo Curso

O que é Grid Computing?

Sistema distribuído que integra recursos computacionais heterogêneos (CPU, GPU, armazenamento) de diferentes domínios administrativos para resolver problemas em larga escala.

🌐

Geograficamente disperso

🧩

Multi-organizacional

Computação voluntária

Grid vs. Cluster: Principais Diferenças

Característica Cluster Grid
Localização Único data center Global (várias instituições)
Gestão Uma entidade Múltiplos domínios
Hardware Homogêneo Heterogêneo (CPU/GPU/ARM)
Comunicação Rede local (Infiniband) Internet (alta latência)
Casos de Uso HPC, Big Data Ciência cidadã, projetos globais

Arquitetura de um Grid

Diagrama Grid Computing
Middleware (Globus Toolkit) Recursos Distribuídos Usuário Final
  • Middleware: Camada de software que unifica recursos heterogêneos (ex: Globus Toolkit).
  • Segurança: Autenticação federada (certificados X.509).

Projetos Famosos de Grid Computing

1999
SETI@Home

Analisou sinais de rádio astronômicos com 5 milhões de voluntários.

2000
Folding@home

Simulação de dobra de proteínas para pesquisa de doenças (ex: COVID-19).

2008
LHC Computing Grid

Processou dados do Large Hadron Collider (CERN) em 170 data centers.

O Futuro do Grid Computing

🖥️ Edge Grids

Integração com dispositivos IoT (ex: carros autônomos compartilhando poder computacional).

🔗 Blockchain + Grid

Incentivos via tokens para participantes (ex: Golem Network).

Logo UFPR

Computação em Névoa: A Nuvem Desce ao Chão

Logo Curso

O que é Fog Computing?

Extensão da computação em nuvem que aproxima processamento e armazenamento dos dispositivos de borda, criando uma camada intermediária ("névoa") entre IoT e cloud.

⏱️

Latência < 10ms

📶

Processamento local

🔒

Segurança distribuída

Arquitetura: Cloud vs. Fog vs. Edge

Cloud
Datacenters centralizados (alta latência)
Fog
Roteadores, gateways (processamento intermediário)
Edge
Dispositivos IoT (sensores, câmeras)

Exemplo: Em uma fábrica inteligente, sensores (edge) enviam dados para um gateway (fog) que filtra informações antes de enviar à nuvem.

Aplicações Práticas

🏙️ Smart Cities

Semaforos inteligentes processam dados de tráfego localmente para evitar congestionamentos.

🏭 Indústria 4.0

Gateways em fábricas detectam falhas em máquinas em tempo real (manutenção preditiva).

🚗 Veículos Autônomos

Carros compartilham dados de tráfego via RSUs (Roadside Units) em tempo real.

Fog vs. Cloud: Quando Usar?

Cenário Cloud Fog
Latência 100-500ms < 10ms
Largura de Banda Alto consumo Otimizada (filtro local)
Custo Pay-as-you-go Investimento inicial
Exemplo Big Data analytics Monitoramento de saúde em tempo real

Desafios e Tendências

🔐 Segurança

Autenticação distribuída em dispositivos heterogêneos (ex: padrão IEEE 1934-2018: Standard for Adoption of OpenFog Reference Architecture for Fog Computing.).

🤖 IA na Névoa

Modelos de ML compactos (TinyML) rodando em gateways.

🌐 5G + Fog

Network slicing para priorizar tráfego crítico.

Logo UFPR

Padrões e Tecnologias para Sistemas Distribuídos

Logo Curso

Sistemas distribuídos exigem tecnologias adaptadas a três pilares:

⏱️

Latência

MPI: 0.5µs (Infiniband) vs. gRPC: 100µs

📈

Escalabilidade

Erlang: 2M conexões/nó vs. Java: 50K

🛡️

Tolerância

OTP (Erlang) vs. Kubernetes (Go)

Evolução Histórica

Padrões Críticos

  • CORBA (1991): Objetos distribuídos via IDL. Problema: Complexidade e overhead.
  • MPI (1994): Padrão para HPC. Vantagem: Controle fino sobre comunicação.
  • gRPC (2015): Evolução do RPC. Destaque: HTTP/2 + Protobuf.

Comparativo Detalhado

Tecnologia
Arquitetura
Desempenho
Melhor Caso
Erlang
Modelo Actor
2M conexões/nó
Chats em tempo real
MPI
Passagem de Mensagens
0.5µs latência
Simulações científicas
gRPC
RPC Stream
10x REST
Microsserviços

Quem Usa e Como?

WhatsApp (Erlang)

2B usuários com OTP para gerência de falhas.

  • 1 nó = 2M conexões
  • Hot code reload

Netflix (gRPC)

1B requisições/dia entre microsserviços.

  • Protobuf: 30% menor payload vs. JSON
  • Streaming bidirecional

Tendências Emergentes

Logo UFPR

CORBA: O Middleware Clássico para Objetos Distribuídos

Logo Curso

Common Object Request Broker Architecture

1991

Padronizado pela OMG (Object Management Group) para unificar comunicação entre objetos em linguagens diferentes.

"Permitia que um objeto Java chamasse métodos de um objeto C++ remotamente, como se fosse local."

Arquitetura CORBA

Arquitetura CORBA
IDL (Interface Definition Language)
ORB (Object Request Broker)
IIOP (Protocolo de Rede)
  • IDL: Linguagem neutra para definir interfaces (compilável para Java, C++, etc.).
  • ORB: "Middleware" que roteia chamadas entre objetos.
  • IIOP: Protocolo binário sobre TCP/IP (alternativa ao DCE-RPC).

Exemplo Prático: IDL + Java

// Calculator.idl
module Calculadora {
  interface Operacoes {
    double soma(in double a, in double b);
    double subtrai(in double a, in double b);
  };
};
// Servidor Java
public class OperacoesImpl extends OperacoesPOA {
  public double soma(double a, double b) {
    return a + b;
  }
  // ... outras implementações
}

O IDL é compilado para stubs (cliente) e skeletons (servidor).

Onde CORBA ainda é Usado?

🏦 Sistemas Bancários Legados

Integração entre mainframes (COBOL) e frontends Java.

🛰️ Sistemas Embarcados Críticos

Comunicação em sistemas de defesa (ex: controle de tráfego aéreo).

CORBA vs. Alternativas Modernas

CORBA gRPC
Protocolo IIOP (binário) HTTP/2 + Protobuf
Performance ~500µs latency ~100µs latency
Complexidade Alta (IDL, ORB) Moderada

Por que CORBA "Morreu"?

  • Complexidade: Configurar ORBs era doloroso.
  • Alternativas: SOAP (2000s) e gRPC (2010s) ofereciam simplicidade.
  • Performance: Protocolos modernos são mais eficientes.

Contribuições

✔ Pioneiro em objetos distribuídos
✔ Padrão multi-linguagem

Lições Aprendidas

✖ Middleware não deve ser invisível
✖ Simplicidade > Features

Logo UFPR

MPI: Padrão Ouro para HPC Distribuído

Logo Curso

Message Passing Interface

1994

Criado por um consórcio de universidades e laboratórios para padronizar a comunicação em clusters HPC.

"Linguagem neutra: funciona com C, C++, Fortran, Python (via mpi4py)."

Arquitetura MPI

👋 Comunicação Ponto-a-Ponto

MPI_Send(buffer, count, datatype, dest, tag, comm);
MPI_Recv(buffer, count, datatype, source, tag, comm, status);

📢 Comunicação Coletiva

MPI_Bcast(data, count, datatype, root, comm);
MPI_Reduce(sendbuf, recvbuf, count, datatype, op, root, comm);
  • Processos: Cada instância do programa tem um rank único (0 a N-1).
  • Comunicadores: MPI_COMM_WORLD agrupa todos os processos.
  • Latência: Tão baixa quanto 0.5µs com Infiniband.

Exemplo Prático: "Hello World" em MPI

#include <mpi.h>
#include <stdio.h>

int main(int argc, char** argv) {
  MPI_Init(&argc, &argv);
  
  int rank, size;
  MPI_Comm_rank(MPI_COMM_WORLD, &rank);
  MPI_Comm_size(MPI_COMM_WORLD, &size);
  
  printf("Hello from rank %d of %d\n", rank, size);
  
  MPI_Finalize();
  return 0;
}
from mpi4py import MPI

comm = MPI.COMM_WORLD
rank = comm.Get_rank()
size = comm.Get_size()

print(f"Hello from rank {rank} of {size}")

Compilação (C): mpicc hello.c -o hello && mpirun -np 4 ./hello

Onde MPI Brilha?

Supercomputador Fugaku

Supercomputadores

Fugaku (Japão): 7.3M núcleos usando MPI+OpenMP.

Modelagem Climática

CESM (EUA): Simulações com 100+ variáveis em paralelo.

MPI vs. Outras Abordagens

MPI OpenMP gRPC
Escala Clusters (1K+ nós) Multicore (1 nó) Microsserviços
Latência 0.5µs (Infiniband) 10ns (memória) 100µs (rede)
Melhor Caso Cálculos científicos Paralelismo fino Comunicação heterogênea

Evolução do MPI

  • MPI-4.0 (2021): Suporte a fault tolerance e operações persistentes.
  • MPI + GPU: Aceleradores (CUDA, ROCm) via MPI_Send direto entre GPUs.
Logo UFPR

OpenMP: Paralelismo em Memória Compartilhada

Logo Curso

Open Multi-Processing (OpenMP)

"Framework para paralelismo em memória compartilhada com diretivas simples em C/C++/Fortran."

Latência: ~10ns (acesso direto à memória RAM)

🧵

Threads: Gerenciadas automaticamente (1 por núcleo)

🔀

Modelo: Fork-Join (threads criadas/destruídas sob demanda)

Arquitetura OpenMP

Thread 1
Núcleo 1
Thread 2
Núcleo 2
Thread 3
Núcleo 3
Thread 4
Núcleo 4
Memória Compartilhada
  • Escopo de Variáveis: private (cópia por thread) ou shared (acesso concorrente).
  • Diretivas-Chave: #pragma omp parallel, for, reduction.

Exemplos Práticos

Método de Monte Carlo

Método de Monte Carlo

π ≈ 4 × (pontos dentro do círculo / pontos totais). Paralelize a geração de pontos:

#include <stdio.h>
#include <stdlib.h>

int main() {
  int points = 1e6;
  int inside = 0;
  
  for (int i = 0; i < points; i++) {
    double x = (double)rand() / RAND_MAX;
    double y = (double)rand() / RAND_MAX;
    if (x*x + y*y <= 1) inside++;
  }
  
  double pi = 4.0 * inside / points;
  printf("π ≈ %f\n", pi);
  return 0;
}
#include <omp.h>
// ...
  #pragma omp parallel for reduction(+:inside)
  for (int i = 0; i < points; i++) {
    // Geração de pontos (igual ao serial)
  }
  printf("π ≈ %f (%d threads)\n", pi, omp_get_max_threads());

Compilação: gcc -fopenmp pi.c -o pi && OMP_NUM_THREADS=4 ./pi

Soma de Elementos de Vetor

Paralelize a soma de um vetor grande usando reduction:

double sum = 0;
for (int i = 0; i < N; i++) {
  sum += array[i];
}
double sum = 0;
#pragma omp parallel for reduction(+:sum)
for (int i = 0; i < N; i++) {
  sum += array[i];
}

Compilação: gcc -fopenmp sum.c -o sum

Análise de Desempenho

Cálculo de π (1M pontos)

Serial: 12ms
4 threads: 3ms

Soma de Vetor (10M elementos)

Serial: 18ms
4 threads: 6ms
  • Speedup ideal: N threads → N× mais rápido (mas overhead de gerenciamento existe).
  • Dica: Use #pragma omp parallel for schedule(static, chunk) para controlar o balanceamento de carga.

🔄 Casos de Uso

  • Processamento de imagens (filtros, convoluções)
  • Simulações científicas (equações diferenciais)
  • Pré-processamento de dados (ML)

⚠️ Limitações

  • Não substitui MPI para clusters (só memória compartilhada)
  • race conditions em variáveis compartilhadas sem reduction ou critical
  • Overhead em loops pequenos (< ~1ms)

Exercício: Multiplicação Matriz-Vetor

Paralelize este código com OpenMP:

double result[N];
for (int i = 0; i < N; i++) {
  result[i] = 0;
  for (int j = 0; j < N; j++) {
    result[i] += matrix[i][j] * vector[j];
  }
}
Solução
#pragma omp parallel for
for (int i = 0; i < N; i++) {
  result[i] = 0;
  #pragma omp simd  // Otimização adicional
  for (int j = 0; j < N; j++) {
    result[i] += matrix[i][j] * vector[j];
  }
}

Dica: Note o uso de simd para vetorização interna do loop.

Logo UFPR

gRPC: Chamadas Remotas de Alto Desempenho

Logo Curso

O que é gRPC?

"Framework moderno para chamadas remotas (RPC) usando HTTP/2 e Protocol Buffers, desenvolvido pelo Google."

Latência: ~100µs (5x mais rápido que REST)

📡

Streaming: Suporte a fluxos bidirecionais

🔐

Segurança: TLS nativo e autenticação

Como Funciona?

Arquitetura gRPC
Cliente
Servidor
HTTP/2
Protocol Buffers
  • Protocol Buffers: Estrutura de dados binária (menor que JSON).
  • HTTP/2: Multiplexação, compressão de cabeçalhos.
  • Stubs Gerados: Código em múltiplas linguagens (Go, Python, Java...).

Exemplo: Serviço de Calculadora

syntax = "proto3";

service Calculator {
  rpc Add (AddRequest) returns (AddResponse);
}

message AddRequest {
  int32 a = 1;
  int32 b = 2;
}

message AddResponse {
  int32 result = 1;
}

Compilação: protoc --go_out=. --python_out=. calculator.proto

package main

import (
  "context"
  "log"
  "net"

  "google.golang.org/grpc"
  pb "caminho/do/proto"
)

type server struct{}

func (s *server) Add(ctx context.Context, req *pb.AddRequest) (*pb.AddResponse, error) {
  return &pb.AddResponse{Result: req.A + req.B}, nil
}

func main() {
  lis, _ := net.Listen("tcp", ":50051")
  s := grpc.NewServer()
  pb.RegisterCalculatorServer(s, &server{})
  s.Serve(lis)
}
import grpc
import calculator_pb2
import calculator_pb2_grpc

channel = grpc.insecure_channel('localhost:50051')
stub = calculator_pb2_grpc.CalculatorStub(channel)

response = stub.Add(calculator_pb2.AddRequest(a=5, b=3))
print("Resultado:", response.result)  # Output: 8

gRPC vs REST

gRPC REST/JSON
Protocolo HTTP/2 (binário) HTTP/1.1 (texto)
Payload Protocol Buffers (compacto) JSON (verboso)
Streaming ✅ Bidirecional ❌ Unidirecional
Casos de Uso Microsserviços, IoT APIs públicas

Quem Usa gRPC?

Netflix

Netflix

Comunicação entre microsserviços (1B+ requisições/dia).

Google

Google

Originalmente criado para conectar serviços na nuvem.

Exercício: Implemente um Serviço de Chat

Modifique o exemplo para suportar streaming bidirecional:

service Chat {
  rpc SendMessage (stream Message) returns (stream MessageResponse);
}
Solução (Dica)

Use yield no Python e stream.Send() no Go para enviar mensagens assíncronas.

Logo UFPR

NFS: Sistema de Arquivos Distribuído

Logo Curso

Network File System (NFS)

"Protocolo que permite acesso transparente a arquivos remotos como se fossem locais, usando RPC para comunicação."

📅

Origem: Sun Microsystems (1984)

📡

Protocolo: Baseado em RPC (chamadas remotas)

🔗

Versões: NFSv3 (RFC 1813), NFSv4 (RFC 3530)

Como o NFS Funciona?

Arquitetura NFS
Cliente
Servidor
RPC/XDR
VFS (Virtual File System)
  • VFS: Camada que abstrai operações de arquivo (open, read, etc.).
  • XDR: Padroniza representação de dados entre sistemas heterogêneos.
  • Stateless: NFSv3 não mantém estado (simplicidade, mas exige cache no cliente).

Configuração em Linux

# Instale o NFS no servidor (Ubuntu)
sudo apt install nfs-kernel-server

# Configure o diretório exportado
sudo mkdir /shared
sudo chown nobody:nogroup /shared
echo "/shared *(rw,sync,no_subtree_check)" | sudo tee /etc/exports

# Inicie o serviço
sudo exportfs -a
sudo systemctl start nfs-kernel-server
# Instale o cliente NFS
sudo apt install nfs-common

# Monte o diretório remoto
sudo mkdir -p /mnt/nfs/shared
sudo mount -t nfs servidor:/shared /mnt/nfs/shared

# Verifique
df -h | grep nfs
ls /mnt/nfs/shared  # Arquivos aparecem como locais!

Evolução do Protocolo

NFSv3 (1995) NFSv4 (2000)
Estado Stateless Stateful
Segurança Limitada (Unix auth) Kerberos, ACLs
Performance UDP (rápido, não confiável) TCP (confiável)
Firewall Múltiplas portas RPC Porta única (2049)

Aplicações no Mundo Real

Linux

Clusters HPC

Compartilhamento de datasets grandes entre nós de computação.

VMware

Virtualização

Armazenamento centralizado para máquinas virtuais.

Desafios e Alternativas

  • ⚠️ Gargalo: Servidor único pode limitar escalabilidade.
  • 🔒 Segurança: NFSv3 sem criptografia (use NFSv4 + Kerberos).
  • 🔄 Alternativas:
    • CephFS: Sistema distribuído com alta disponibilidade.
    • Lustre: Para HPC com milhões de arquivos.

Exercício: Monte um Servidor NFS

  1. Configure um servidor NFSv4 em uma VM Linux.
  2. Exporte um diretório com rw (leitura/escrita) para um cliente.
  3. Teste a persistência após reiniciar o servidor.
Dica de Solução

Adicione a montagem automática no /etc/fstab do cliente:

servidor:/shared  /mnt/nfs/shared  nfs  defaults  0  0
Logo UFPR

Heterogeneidade e Computação Ubíqua

Logo Curso

Heterogeneidade em Sistemas Distribuídos

Definição: Capacidade de integrar diferentes tecnologias em um mesmo sistema:

  • Sistemas Operacionais: Windows, Linux, macOS, Android, iOS trabalhando juntos
  • Arquiteturas de Hardware: x86, ARM, GPUs, TPUs, dispositivos com diferentes capacidades
  • Linguagens de Programação: Microserviços em Java, Python, Go, Node.js comunicando-se
  • Protocolos de Comunicação: HTTP/REST, gRPC, MQTT, WebSockets coexistindo
Exemplo Prático: Um aplicativo bancário que:
  • Front-end web (JavaScript) + mobile (Swift/Kotlin)
  • Back-end em Java (contas) e Python (machine learning para fraudes)
  • Banco de dados Oracle e MongoDB
  • Comunica via REST e mensageria com Kafka

Computação Ubíqua (Pervasiva)

Conceito: Tecnologia integrada ao ambiente do usuário, invisível e disponível em qualquer lugar:

  • Dispositivos Pessoais: Smartwatches (monitoramento contínuo de saúde), fones inteligentes
  • Casa Inteligente: Alexa/Google Home, lâmpadas e termostatos conectados
  • Cidades Inteligentes: Sensores de tráfego, iluminação pública adaptativa
  • Indústria 4.0: Sensores em equipamentos, manutenção preditiva
  • Saúde: Wearables médicos, implantes monitorados remotamente

Desafios na Integração

  • Interoperabilidade: Padrões como Matter para IoT, APIs GraphQL
  • Segurança: Autenticação entre dispositivos (OAuth, certificados digitais)
  • Escalabilidade: Arquiteturas baseadas em eventos (Event-Driven Architecture)
  • Latência: Edge computing para processamento próximo aos dispositivos
  • Consumo de Energia: Protocolos otimizados como LoRaWAN para IoT
Cenário Real: Hospital inteligente:
  • Pulseiras de pacientes (wearables) coletam dados vitais
  • Sensores de ambiente monitoram temperatura/umidade
  • Todos os dispositivos se comunicam via protocolos padronizados
  • Sistema central toma decisões (alertas para equipe médica)
  • Integração com prontuário eletrônico em nuvem
Logo UFPR

Redes de Sensores e Satélites: IoT e Comunicação Global

Logo Curso

Redes de Sensores Sem Fio (WSN)

🔋 Arquitetura Típica

Arquitetura WSN
  • Nós sensores: Microcontroladores (ex: ESP32) + bateria.
  • Gateway: Coleta dados e envia para a nuvem.
  • Protocolos: Zigbee, LoRaWAN, Bluetooth Low Energy (BLE).

📊 Casos Reais

Agricultura IoT

Agricultura de Precisão: Sensores monitoram umidade do solo e otimizam irrigação (economia de 30% de água).

Cidade Inteligente

Cidades Inteligentes: Sensores em lixeiras acionam coleta quando cheias (ex: Barcelona).

⚙️ Desafios Técnicos

🔋

Energia: Baterias durando anos (ex: LoRaWAN = 10km com AA).

📶

Conectividade: Baixa largura de banda (ex: Zigbee = 250kbps).

🔄

Roteamento: Protocolos como RPL para redes mesh.

🛠️ Exemplo Prático: Sensor ESP32 com LoRa

#include <SPI.h>
#include <LoRa.h>

// Pinos (ajuste para seu hardware)
#define SCK 5   // GPIO5
#define MISO 19 // GPIO19
#define MOSI 27 // GPIO27
#define SS 18   // GPIO18
#define RST 14  // GPIO14
#define DIO0 26 // GPIO26

void setup() {
  Serial.begin(115200);
  LoRa.setPins(SS, RST, DIO0);
  
  if (!LoRa.begin(915E6)) { // Frequência para Brasil
    Serial.println("Falha ao iniciar LoRa!");
    while (1);
  }
  Serial.println("LoRa inicializado!");
}
void loop() {
  float temperatura = readTemperature(); // Simulação
  float umidade = readHumidity();
  
  // Envia pacote LoRa
  LoRa.beginPacket();
  LoRa.print("T:");
  LoRa.print(temperatura);
  LoRa.print("|H:");
  LoRa.print(umidade);
  LoRa.endPacket();
  
  delay(10000); // Envia a cada 10s
}
void onReceive(int packetSize) {
  if (packetSize == 0) return;
  
  String data;
  while (LoRa.available()) {
    data += (char)LoRa.read();
  }
  
  Serial.print("Dados recebidos: ");
  Serial.println(data);
  // Processa dados (ex: aciona alarme se temperatura > 30°C)
}

void loop() {
  LoRa.onReceive(onReceive);
  LoRa.receive();
}

Biblioteca: LoRa.h | Plataforma: Arduino IDE/PlatformIO

Redes de Satélites

🛰️ Tipos de Órbitas

Órbitas de Satélites
  • LEO (300-2000km): Starlink, latência ~20ms (para Internet).
  • MEO (2000-35,786km): GPS, latência ~100ms.
  • GEO (35,786km): Satélites geoestacionários (TV), latência ~500ms.

🌍 Aplicações Críticas

Starlink

Starlink (SpaceX): 4,000+ satélites LEO para Internet global (velocidade ~300Mbps).

GPS

GPS (EUA): 24 satélites MEO para posicionamento (precisão ~3m).

⚡ Desafios de Comunicação

⏱️

Latência: GEO: 500ms ida e volta (vs fibra óptica: ~10ms).

💻

Protocolos: DTN (Delay-Tolerant Networking) para conexões instáveis.

☄️

Ambiente Hostil: Radiação cósmica, lixo espacial.

WSN vs. Satélites: Quando Usar?

Critério Redes de Sensores (WSN) Redes de Satélites
Custo 💰 Baixo (nó sensor: $10-$100) 🚀 Alto (satélite: $500k-$500M)
Cobertura 📶 Local (até 10km com LoRa) 🌍 Global (incluindo oceanos)
Latência ⚡ Baixa (<100ms) ⏳ Alta (LEO: 20ms, GEO: 500ms)
Manutenção 🔧 Troca de baterias 🛰️ Impossível (em órbita)
Melhor Caso 🏭 IoT industrial, agricultura 🌐 Internet remota, GPS
WSN: $100/nó
Satélite: $10M/unidade

Exemplo Integrado: Monitoramento da Amazônia

🌳

Sensores no solo: Medem desmatamento (via vibração e som).

🛰️

Satélites CubeSat: Validam dados e retransmitem.

☁️

Nuvem: Aciona alertas em tempo real.

LoRaWAN DTN AWS IoT

Exercício: Decida a Tecnologia Ideal

Cenário: Monitorar vulcões ativos em áreas remotas.

  • Opção A: Rede de sensores com gateway LoRa via drone.
  • Opção B: Nanossatélites CubeSat com sensores térmicos.
Solução

Resposta: Combinação de ambas! Sensores no solo (WSN) para dados precisos + CubeSats para retransmissão em áreas sem infraestrutura.

Por quê? WSN é mais barato para alta densidade de sensores, enquanto satélites garantem cobertura em locais inacessíveis.

Exercício: Simule uma Rede de Sensores

Use o simulador TOSSIM (para TinyOS) ou Cooja (para ContikiOS):

# Exemplo no Cooja (simulando sensores em uma floresta)
1. Crie 10 nós sensores virtuais
2. Implemente roteamento mesh com RPL
3. Monitore consumo de energia
Recursos Adicionais
Logo UFPR

Arquiteturas Distribuídas

Logo Curso

1. Cliente-Servidor

Características Principais

  • Papéis bem definidos: Cliente (interface/consome) e Servidor (processamento/dados)
  • Modelo de comunicação: Síncrono (request-response) ou assíncrono
  • Protocolos comuns: HTTP(S), RPC, gRPC, WebSockets
  • Padrões arquiteturais: REST, SOAP, GraphQL

Variações Modernas

  • Multi-tier: Apresentação, lógica e dados em camadas separadas
  • Serverless: Cliente ↔ API Gateway ↔ Funções como Serviço (AWS Lambda, Azure Functions)

Vantagens

  • Simplicidade de desenvolvimento e manutenção
  • Controle centralizado de segurança e dados
  • Monitoramento e logging facilitados
  • Caching eficiente no servidor

Desafios

  • Single Point of Failure (SPOF)
  • Gargalo no servidor sob alta carga
  • Escalabilidade vertical limitada
  • Latência em clientes distantes
Exemplos Reais:
  • Aplicativos bancários (cliente mobile ↔ servidores bancários)
  • Websites tradicionais (navegador ↔ servidor web)
  • Streaming de vídeo (Netflix/HBO Max com CDNs como edge servers)

2. Peer-to-Peer (P2P)

Características Principais

  • Topologia: Rede descentralizada de nós equivalentes (peers)
  • Modelos:
    • Puro (totalmente descentralizado)
    • Híbrido (com servidores de indexação/tracker)
  • Mecanismos: DHT (Distributed Hash Tables), gossip protocols

Avanços Recentes

  • Blockchain como evolução do conceito P2P
  • Redes overlay para otimização de roteamento
  • P2P em edge computing

Vantagens

  • Alta escalabilidade (cada novo peer adiciona capacidade)
  • Resiliência a falhas (não há SPOF)
  • Redução de custos com infraestrutura centralizada
  • Baixa latência (comunicação direta entre peers próximos)

Desafios

  • Dificuldade de garantir consistência de dados
  • Problemas de segurança (ataques Sybil, envenenamento)
  • Complexidade de implementação
  • Qualidade de serviço variável
Exemplos Reais:
  • Redes de compartilhamento de arquivos (BitTorrent, eMule)
  • Blockchains (Bitcoin, Ethereum - cada nó mantém ledger completo)
  • Comunicação VoIP (Skype original, WebRTC em alguns modos)
  • CDNs P2P (Akamai Netsession, Peer5 para streaming)

3. Arquiteturas Híbridas e Emergentes

P2P com Servidores Especiais

  • Trackers em BitTorrent
  • Supernodes em Skype antigo
  • Bootstrapping servers em redes blockchain

Microsserviços

  • Decomposição funcional em serviços independentes
  • Comunicação via API (REST, gRPC, mensageria)
  • Ex.: Uber (serviços separados para geolocalização, pagamentos, etc.)

Edge/Fog Computing

  • Processamento distribuído próximo aos dispositivos
  • Combina elementos cliente-servidor e P2P
  • Ex.: Carros autônomos processando dados localmente
Critério Cliente-Servidor P2P Microsserviços
Acoplamento Alto Baixo Médio
Escalabilidade Vertical Horizontal Horizontal
Ponto Único de Falha Sim Não Parcial
Complexidade Baixa Alta Média-Alta
Logo UFPR

Comunicação em Sistemas Distribuídos

Logo Curso

1. Fundamentos de Comunicação em Rede

Protocolos Base

  • TCP/IP: - Conexão orientada, confiável - Controle de fluxo/congestionamento - Ex.: HTTP, gRPC, bancos de dados
  • UDP: - Sem conexão, não confiável - Baixa sobrecarga - Ex.: VoIP, streaming, DNS
  • QUIC: Novo padrão (HTTP/3) combinando benefícios TCP+UDP

Desafios de Comunicação

  • Problemas Comuns: - Perda de pacotes - Atrasos variáveis (jitter) - Mensagens duplicadas - Ordem invertida
  • Cenários de Falha: - Network partitioning (split-brain) - Silent failures (não detectadas) - Byzantine failures (comportamento arbitrário)

Falhas Parciais - Casos Reais

Amazon S3 Outage (2017): Falha em uma região afetou serviços dependentes
Padrões de Resiliência: - Circuit Breaker (Hystrix) - Retries com backoff exponencial - Timeouts adequados

2. Modelos de Comunicação

Síncrona

  • Cliente espera resposta para continuar
  • Técnicas: RPC, REST, gRPC
  • Vantagens: Simplicidade conceitual
  • Desvantagens: Baixa resiliência a falhas
  • Caso: Chamadas a APIs de pagamento

Assíncrona

  • Uso de intermediários (brokers)
  • Tecnologias: Kafka, RabbitMQ, AWS SQS
  • Padrões: Pub/Sub, Filas de Trabalho
  • Vantagens: Desacoplamento temporal
  • Caso: Processamento de pedidos em e-commerce

Multicast/Group

  • Comunicação 1-para-N
  • Protocolos: IGMP, PGM
  • Aplicações: - Atualização de caches - Notificações em massa - Consenso distribuído
  • Caso: Atualização de inventário em lojas

Técnicas Avançadas

  • Event Sourcing: Armazenamento como sequência de eventos
  • CQRS: Separação de leitura/escrita
  • Stream Processing: Processamento contínuo (Kafka Streams, Flink)

3. Qualidade de Serviço (QoS)

Métricas-Chave

  • Throughput: Mensagens/segundo
  • Latência: Tempo requisição-resposta
  • Disponibilidade: % tempo operacional
  • Consistência: Modelos (strong, eventual)

Técnicas de Otimização

  • CDNs: Cache geograficamente distribuído
  • Compressão: Protocol buffers, Avro
  • Priorização: QoS em nível de rede (DSCP)
  • Load Balancing: Distribuição inteligente

Caso Real: Video Streaming

  • Adaptação de bitrate baseada em QoS
  • Balanceamento entre latência e qualidade
  • Uso de UDP com correção de erros (QUIC)
  • Ex.: Netflix, YouTube, Twitch

Trade-offs em SD

  • Consistência vs. Disponibilidade (CAP Theorem)
  • Latência vs. Throughput
  • Sincronia vs. Escalabilidade
Logo UFPR

SBRC e Bibliografia

Logo Curso

Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SBRC)

  • Evento anual promovido pela SBC e LARC.
  • Mais importante evento de pesquisa no Brasil em Redes e Sistemas Distribuídos.
  • Acontece desde 1983, com publicações de artigos científicos, tutoriais, minicursos, etc.

Bibliografia Básica

  • Coulouris, G., et al. Distributed Systems: Concepts and Design.
  • Tanenbaum, A. S., & Van Steen, M. Distributed Systems: Principles and Paradigms.
  • Lynch, N. A. Distributed Algorithms.
  • Attiya, H. & Welch, J. Distributed Computing.
Logo UFPR

Quiz de Múltipla Escolha

Logo Curso

Responda as seguintes questões:

Logo UFPR

Perguntas Descritivas

Logo Curso

Responda as seguintes questões:

1. Explique o conceito de LTSP e em que cenários ele é útil.

O LTSP transforma um único servidor em host para vários terminais leves. É útil em ambientes que buscam economia de hardware, administração centralizada e baixo consumo de recursos, como laboratórios de escolas ou empresas.

2. Diferencie brevemente um cluster de computação de um grid.

Um cluster normalmente fica concentrado em um único local, com nós homogêneos geridos por uma única entidade. Já um grid pode abranger diversos domínios administrativos e físicos, combinando recursos heterogêneos de várias instituições.

3. Em que situações a computação em névoa traz vantagens em comparação à computação em nuvem convencional?

Quando o sistema requer baixa latência (tempo de resposta muito curto) ou quando é desejável pré-processar dados perto da fonte para reduzir o tráfego na nuvem. Exemplos: aplicações de IoT industrial, carros autônomos e cidades inteligentes.

4. Por que o MPI é considerado um sistema distribuído, embora seja focado em HPC?

Porque em um cluster MPI cada nó possui seu próprio SO e se comunica via rede para coordenar a computação, caracterizando a independência e interconexão de componentes típica de sistemas distribuídos, mesmo com foco em alto desempenho.

5. Explique a importância dos sistemas distribuídos na computação moderna.

Sistemas distribuídos possibilitam o processamento paralelo, maior escalabilidade, tolerância a falhas e melhor aproveitamento de recursos, fundamentais para aplicações de alta performance e computação em nuvem.

6. Qual a diferença entre comunicação síncrona e assíncrona em SD?

Na comunicação síncrona, o remetente espera a resposta antes de prosseguir (RPC). Na assíncrona, a mensagem é enviada e o remetente pode continuar, recebendo a resposta em outro momento (filas de mensagens, publish-subscribe).

7. Quais são os principais componentes de uma arquitetura CORBA e como eles interagem?

Os principais componentes são: ORB (Object Request Broker) que gerencia a comunicação, IDL (Interface Definition Language) para definir interfaces, Stubs/Skeletons como proxies locais, e o Interface Repository que armazena definições. O ORB atua como intermediário, permitindo que objetos distribuídos se comuniquem transparentemente.

8. Como o MPI lida com a comunicação coletiva em comparação com operações ponto-a-ponto?

Enquanto operações ponto-a-ponto (como MPI_Send/MPI_Recv) conectam dois processos específicos, as operações coletivas (MPI_Bcast, MPI_Reduce, MPI_Gather) envolvem grupos de processos. Estas otimizam padrões comuns como broadcast, redução e sincronização, sendo implementadas de forma eficiente pelo runtime do MPI.

9. Quais são as diferenças fundamentais entre OpenMP e MPI para processamento paralelo?

OpenMP é para memória compartilhada (multicore), usando diretivas de compilação e threads, enquanto MPI é para memória distribuída (clusters), usando troca explícita de mensagens. OpenMP tem menor overhead mas escala menos, MPI é mais complexo mas escala para milhares de nós.

10. Como redes de sensores sem fio se beneficiam de abordagens distribuídas?

Abordagens distribuídas permitem: processamento local para reduzir transmissão (edge computing), auto-organização da rede, tolerância a falhas (já que sensores podem falhar), e algoritmos como data aggregation que combinam dados de múltiplos sensores antes do envio para economizar energia.

11. Quais os três principais padrões de comunicação em SD e quando usar cada um?

1) Request-Reply (RPC/REST): para interações síncronas que exigem resposta imediata. 2) Publish-Subscribe: quando múltiplos consumidores precisam receber eventos assincronamente. 3) Mensageria ponto-a-ponto (filas): para processamento assíncrono com garantia de entrega e balanceamento de carga entre workers.

12. Por que a computação em névoa é particularmente útil em IoT industrial?

Porque: 1) Reduz latência para decisões em tempo real (ex: parada de emergência), 2) Funciona mesmo com conectividade intermitente com a nuvem, 3) Processa localmente grandes volumes de dados de sensores antes do envio, e 4) Atende requisitos de privacidade/segurança mantendo dados sensíveis no local.

13. Como o modelo de objetos distribuídos do CORBA difere de abordagens modernas como microsserviços?

CORBA promove acoplamento forte com interfaces binárias complexas via ORB, enquanto microsserviços usam APIs leves (REST/gRPC) e independência de implementação. Microsserviços favorecem decentralização, tolerância a falhas e deploy independente, enquanto CORBA busca transparência total de localização.

14. Quais estratégias MPI oferece para lidar com a heterogeneidade em clusters?

MPI oferece: 1) Tipos de dados derivados para lidar com diferentes representações, 2) Operações coletivas que se adaptam à topologia, 3) Comunicações não-bloqueantes para sobrepor computação e comunicação, e 4) Processos dinâmicos (MPI_Comm_spawn) para integrar nós heterogêneos durante a execução.

15. Como redes de sensores sem fio implementam algoritmos distribuídos básicos como eleição de líder?

Usam algoritmos como: 1) Bully Algorithm (nós "desafiam" com IDs), 2) Ring-based (mensagens circulam), adaptados para restrições de energia. Frequentemente elegem líderes temporários baseados em energia residual, proximidade aos dados, ou capacidades computacionais, com reeleição periódica.