Académique Documents
Professionnel Documents
Culture Documents
MC714
Sistemas Distribuídos
1° semestre, 2017
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Tipos de SDs
• Sistemas de computação distribuídos
• Sistemas de informação distribuídos
• Sistemas embuJdos (embarcados)
distribuídos
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Sistemas de Computação
Distribuídos
• UJlizado para tarefas de computação
(frequentemente de alto desempenho).
• Computação em cluster
• Computação em grade
• Computação em nuvem
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Cluster Computing
• Tornaram-se populares pela razão preço/desempenho.
• Estações mais potentes e mais baratas
• Rede melhor
• Computação intensiva paralela.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Cluster Computing
• Ex.: Beowulf. Fig 22.
• Mestre
• Alocação de nós / fila / escalonamento
• Interface para usuário
• Executa middleware para execução de programas e gerência
do cluster.
• Nós de computação: SO padrão pode ser suficiente.
• Bibliotecas de execução em sistemas paralelos:
facilidades para comunicação por troca de mensagem.
• Migração de processos: movimento transparente de
processos de um nó naJvo para qualquer outro nó.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Computação em grade
• Cluster: homogêneo.
• Grade: heterogênea, nenhuma premissa adotada
em relação a hardware, S.O., rede, domínio
administraJvo, políJca de segurança, etc.
• Recursos de diferentes organizações reunidos para
permiJr colaboração.
• Organização virtual: pessoas em uma organização
virtual têm direitos sobre recursos dessa
organização.
• Servidores de computação (inclusive clusters),
armazenamento, instrumentos, bancos de dados,
equipamentos, sensores, telescópios, etc.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Computação em grade
h1p://wlcg.web.cern.ch/
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Computação em grade
h1p://wlcg.web.cern.ch/
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Computação em grade
h1p://wlcg.web.cern.ch/
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Computação em grade
• So`ware de grade: grande parte com finalidade de prover
acesso a recursos de diferentes domínios administraJvos.
• Fig 23.
• Camada base: interfaces para recursos locais em site
específico. Consultar estado de recursos e gerência de
recursos locais.
• Camada de conecJvidade: protocolos de comunicação para
suportar transações uJlizando múlJplos recursos. Ex.:
transferência de dados, autenJcação, protocolos de
segurança.
• Camada de recurso: gerência de um único recurso. Ex.: criar
processo, ler dados. Responsável por controle de acesso –
necessita autenJcação.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Computação em grade
• Camada coleJva: manipular acesso a múlJplos recursos.
Serviços de descoberta de recursos, alocação /
escalonamento de tarefas para múlJplos recursos,
replicação de dados, etc.
• Muitos serviços - pode consisJr de muitos protocolos
independentes.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Computação em grade
• Camadas ColeJva+conecJvidade+recurso formam o
cerne de um middleware de grade.
• Dão acesso e gerenciam recursos dispersos por vários “sites”.
• Noção de “site” é comum: tendência do SOA (acesso às
camadas através de serviços web).
• OGSA à Open Grid Services Architecture
• Várias camadas e muitos componentes voltados a definir uma
grade aberta orientada a serviços
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Cloud Computing
• Introduz noção de “computação como serviço”.
• Relação com u"lity grids.
• Recursos virtualizados.
• Diferentes níveis de serviço. Canônicos: IaaS, PaaS, SaaS.
• Pagamento pelo uso.
• Nuvem pública / privada / híbrida / comunitária.
• Evita alto invesJmento inicial.
• Fig. 24
• Visões: provedor e cliente.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Sistemas de Informação
distribuídos
• Organizações se defrontaram com uma profusão
de aplicações em rede.
• Interoperabilidade complicada.
• Algumas soluções de middleware existentes são
resultado da integração de tais aplicações em um
sistema empresarial
• Mais fácil que desenvolver todas novamente.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Sistemas de Informação
distribuídos
• Integração em vários níveis.
• Aplicação (servidor + banco de dados) disponibilizada a
clientes remotos.
• Cliente envia requisição, recebe resposta.
• Integração em nível mais baixo: clientes poderiam empacotar
várias requisições para diferentes servidores em uma única
requisição maior.
• Envio para execução em forma de transação distribuída.
• Idéia fundamental: ou todas ou nenhuma seria executada.
Sistemas de Informação
distribuídos
• Aplicações tornaram-se gradualmente separadas em
componentes independentes
• Componentes de banco de dados e de processamento
• Integração deveria ocorrer em nível mais alto
• Comunicação também entre aplicações
• Indústria de integração de aplicações empresariais
(Enterprise ApplicaJon IntegraJon – EAI).
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Transações
• Aplicações de bancos de dados costumam ser
realizadas sob a forma de transações.
• Programá-las requer primiJvas especiais que devem ser
fornecidas pelo sistema distribuído ou pela linguagem
em tempo de execução.
• Lista de primiJvas depende dos Jpos de objetos que
estão sendo usados na transação.
• Read e write são primiJvas mpicas.
• Chamadas de procedimento remoto (RPC – remote
procedure calls) costumam ser encapsuladas em
transações – RPC transacional.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Transações
• BEGIN_TRANSACTION: marca o início de uma transação.
• END_TRANSACTION: finaliza transação e tenta commit.
• ABORT_TRANSACTION: mata a transação e restaura
valores anteriores.
• READ: lê dados de um arquivo, tabela, etc.
• WRITE: escreve dados em um arquivo, tabela, etc.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Transações
• Propriedades (ACID):
• Atomicidade: (para o mundo externo) transação
ocorre de forma indivisível.
• Consistência: transação não viola invariantes do
sistema.
• Isolamento: transações concorrentes não interferem
uma na outra.
• Durabilidade: uma vez dado commit
(“compromeJmento”), as mudanças são
permanentes.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Transações aninhadas
• Transações aninhadas.
• Subtransações.
• 1 transação pode gerar subtransações paralelas e distribuídas,
que podem gerar subtransações ...
• Fig. 25.
• Problema:
• Transações em paralelo, uma se compromete, tornando
resultados visíveis à transação-pai.
• Transação-pai é abortada, restaurando o sistema ao estado
anterior ao início da transação de nível mais alto.
• Resultados da subtransação compromeJda devem ser anulados –
“permanência” (durabilidade) se aplica somente às transações de
nível mais alto.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Transações aninhadas
• Profundidade arbitrária.
• Considerável trabalho administraJvo para conseguir que tudo
esteja correto.
• SemânJca é:
• Transação ou subtransação inicia, recebe uma cópia privada de
todos os dados presentes no sistema inteiro, manipulando como
desejar.
• Se abortar, seu universo privado some.
• Se comprometer, seu universo privado subsJtui o do pai.
• Dessa forma, se uma subtransação é compromeJda e mais tarde
uma nova é iniciada, a segunda vê os resultados da primeira.
• Se uma transação do nível mais alto abortar, todas as subjacentes
também têm de ser abortadas.
• Fig 26
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Transações aninhadas
• Importantes em sistemas distribuídos.
• Modo natural de distribuir uma transação em
várias máquinas.
• Divisão lógica do trabalho da transação original.
• Ex: reserva de diversos trechos de vôo.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Transações
• No início dos middlewares empresariais, componente
que manipulava transações formava o núcleo para
integração de aplicações no nível do servidor ou do
banco de dados.
• Componente denominado monitor de processamento de
transações (monitor TP).
• PermiJr modelo de programação transacional para
aplicações.
• Fig. 27.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Integração de aplicações
empresariais
• Aplicações passaram a se desvincular dos bancos de
dados sobre os quais eram construídas.
• Necessidade de integrar aplicações
independentemente de seus bancos de dados.
• Componentes de aplicação deveriam comunicar-se
diretamente uns com os outros.
Integração de aplicações
empresariais
• Vários Jpos de middleware de comunicação
Integração de aplicações
empresariais
• RPC e RMI: ambos precisam estar ligados (chamador e
chamado) e precisam saber como se referir um ao outro
– esse acoplamento pode ser desvantagem.
• Middleware orientado a mensagem (MOM)
• Aplicações enviam mensagem a pontos lógicos de
contato.
• Aplicações podem indicar interesse por um Jpo
específico de mensagem que o middleware cuidará
para que sejam entregues a essas aplicações.
• Sistemas publicar/inscrever (publish/subscribe).
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
• Requisitos:
• Aceitar/adotar mudanças de contexto.
• Encorajar composição ad hoc.
• Reconhecer comparJlhamento como comportamento
padrão.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
• Dois extremos:
• Fig 29: armazenamento e processamento somente no
servidor do operador da rede.
• Fig 30: armazenamento e processamento somente nos
sensores.
• Ambas tem problemas.
• 29: Enviar todos os dados medidos pode ser
desperdício de recursos.
• 30: Despreza capacidade de agregação, o que
retornaria menos dados ao operador.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Resumo
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Resumo
• SDs: computadores autônomos que trabalham juntos
para dar a aparência de um único sistema.
• Facilita integração de diferentes aplicações que
executam em computadores diferentes.
• Ampliação fácil.
• Custo: so`ware mais complexo, menos segurança,
menor desempenho
• Meta: ocultar parte da complexidade relacionada à
distribuição de processos.
• Premissas erradas dificultam desenvolvimento. Ex:
latência é baixa.
Prof. Luiz Fernando Bi1encourt IC - UNICAMP
Resumo
• Tipos diferentes de SDs:
• Computação: derivado da computação
paralela.
• Informação: sistemas empresariais, bancos de
dados, intergração de aplicações.
• Pervasivos: ubiquidade do sistema,
administração distribuída.