Roteiro de estudos PF

Prévia do material em texto

Tópico: Sistemas Paralelos Com Memória Distribuída
__Introdução ao MPI ­ Computação por Passagem de Mensagens
Importante entender os conceitos relacionados à arquitetura onde este paradigma
se aplica: espaço de endereçamento de memória, arquitetura das conexões entre os
processadores e os tipos de configuração existentes.
Os modelos de programação aplicados neste paradigma são pontos a serem observa­
dos, lembrando sempre do que vimos no laboratório, ou seja, ao estudar a teoria,
lembre­se do que praticamos: os exercícios de MPI.
Tópico: Modelos de Sistemas Distribuídos
__Características de Sistemas Distribuídos
O que é um sistema distribuído? Vc sabe responder esta pergunta, consegue dar
exemplos de sistemas distribuídos.
A união de diversos computadores com o objetivo de compartilhar a execução de tarefas.
SD tem como objetivo o compartilhamento de recursos
Vc entende as implicações/consequências das definições de sistema distribuído?
(Concorrência, Falta de um relógio global, falhas independentes)
Concorrência ­ partes do sistema distribuído vão concorrer por recursos compartilhados ou
sofrer concorrência de múltiplos clientes requisitando recursos e serviços simultaneamente.
Falta de um Relógio Global ­ não existe sincronização nativa em SDs pois cada node do
sistema opera em seu proprio clock.
Pode haver falhas independentes entre os componentes.
Nos modelos de SD, uma caracterização que fizemos foi de Servidor e Cliente; vc
sabe distingui­los? Também falamos de peers, onde a cooperação e comunicação é
simétrica; vc entende isso?
Servidor é uma aplicação que vai prover serviços/funcionalidades/etc a um Cliente.
Peers, em p2p, é quando os participantes do SD todos tem as mesmas responsabilidades e
realizam as mesmas tarefas. Não existe um servindo e outro sendo cliente, todos são
servidores/clientes/etc ao mesmo tempo e com as mesmas responsabilidades.
Existem vários desafios na construção de SD; vc sabe quais são? Fez extrapola­
ções de cada conceito apresentado nos desafios, i.e., tentou fazer aplicações
destas informações?
Heterogeneidade: redes, HW, SW, SO, linguagem de programação, diferentes desenvolvedores
Middleware: camada de software que provê uma abstração de programa e mascara a heterogeneidade do
sistema que está nas camadas inferiores
Sistema aberto: Deve suportar a possibilidade de extensão do serviço, principalmente, através de interfaces
Segurança: confidencialidade, integridade e disponibilidade.
__Modelos Arquiteturais
Com relação aos modelos de SD, apresentamos uma figura com as camadas de soft­
ware e hardware. Vc chegou a pensar sobre esta figura? Entendeu o posicionamento
destas camadas? P.explo, o Middleware, que implicação ele tem para um SD?
No Mack temos um servidor de proxy, que nos obriga a fazer uma autenticação sem­
pre que queremos acessar um site web externo; onde se encaixa este proxy nos mo­
delos que vimos? Que papel(éis) ele desempenha em termos de arquitetura?
Essa eu não sei em “termos da matéria dele”... mas em termos gerais, para a gente, ele se
porta como um servidor. Nós solicitamos acesso à um endereço web para ele, ele trata nossa
requisição com suas regras internas (segurança, filtro de conteúdo, balanceamento de carga,
etc) e (a) nos redireciona para o conteúdo real. (b) dá “fetch” no conteúdo e repassa para a
gente. Se for isso que ele tá perguntando, acho que a resposta é essa.
Quando falamos dos modelos fundamentais de SD, vc se lembra de quais são? Suas
principais definições e implicações na construção de SDs?
Modelo de iteração: Foca no desempenho dos processos e canais de comunicação e na falta
de um relógio global
Modelo de segurança: Analisa as possíveis ameaças e como previni­las
Modelo de falha: Analisa as possíveis falhas e como reagir a elas
__Objetos Distribuídos e Invocação Remota ­ parte 1
Falamos sobre o protocolo request­reply; este protocolo é importante para a im­
plementação de SD; pode usar UDP ou TCP ­ vc pensou sobre as implicações da uti­
lização de um ou outro (UDP ou TCP)?
UDP:
ACKs são redudantes já que requests são seguidos de reply
Estabelecer conexão necessita de outros 2 pares de mensagens além do par request­reply
Controle de fluxo é redundante para a maior parte das invocações.
Datagrama máximo de 8Kb
TCP:
Não tem limite de datagrama
Simplifica a implementação do request­reply
TCP tem garantia de delivery, UDP não tem. O overhead de TCP é bem maior.
Quais são as falhas possíveis do protocolo request­reply? (para os dois protoco­
los de transporte)
Falhas de omissão
Não há garantia de entrega de mensagens na ordem em que foram enviadas
Falhas dos processos
Timeouts são utilizadas para controle das mensagens.
Pensando nas possíveis falhas, quais são os comportamentos do protocolo request­
­reply?
=> Request (R): Só envia o request ao server. Útil quando não há valor de retorno esperado.
=> Request­Reply (RR): Client envia request para o server, server responde.
=> Request­Reply­Acknowledge (RRA): Client envia request, server responde, cliente manda
ack. Útil para o servidor descartar históricos de mensagens.
Vc se lembra destes conceitos?
Pense na evolução da computação, desde quando os computadores eram isolados, de­
pois quando passaram a se comunicar, etc. Agora em termos de modelos de progra­
mação, ou seja, programar computadores isolados, depois programar computadores
em rede; pense em termos de facilidades para o programador: implementar todas
as rotinas de comunicação; diferentes para cada SO, fabricante, etc.
Neste contexto, vc consegue enxergar a importância da Remote Procedure Call RPC
para a computação distribuída?
O conceito de RPC permite que computadores diferentes, executando aplicações diferentes,
possam colaborar de forma simples (gerando transparência maior na conexão) através de uma
conexão de comunicação. Isto é, um programa localizado em um computador X, é programado
de forma a disponibilizar um serviço (procedure) para invocação remota e isto cria a
possibilidade de um outro programa, em outro computador Y ser programado de forma a utilizar
ou contribuir com este serviço. Este tipo de facilidade e comunicação é crítica para que a
computação distribuída seja sequer possível.
Um dos pontos importantes para a computação distribuída é o uso de interfaces;
vc sabe disto? Sabe o que é e qual a função de uma interface em SD?
O conceito de interface em computação distribuída tem a ver com o conceito de “contrato”.
Uma interface de um serviço disponível publicamente é um contrato que determina o nome do
serviço prestado (método), os pré­requisitos para operá­lo (parâmetros) e o que ele te promete
em troca (retorno). As interfaces são leves e conseguem ser consultadas por potenciais
clientes do serviço para entenderem como interagir com eles.
Aplique os modelos de falhas ao RPC => semântica da invocação.
Exactly­once ­ Para chamadas de procedimentos locais, significando que cada procedimento é
executado exatamente uma vez (exceto no caso de falha do processo)
Maybe – procedimento remoto pode ser executado uma vez ou não. Aplicada quando não se
tem nenhuma medida de tolerância a falha.Esta semântica é útil apenas para aplicações nas
quais chamadas ocasionais que falham são aceitáveis.
At­least­once – o chamador recebe ou um resultado (procedimento foi executado pelo menos
uma vez), ou uma exceção (nenhum resultado foi recebido). A retransmissão das mensagens
de request – que mascara as falhas de omissão das mensagens de request ou resultado,
produz a semântica em questão.
At­most­once – O chamador recebe ou um resultado (procedimento foi executado exatamente
uma vez) ou exceção (nenhum resultado recebido, o procedimento pode ter sido executado
uma vez ou nenhuma).
O RPC tem vários componentes; entenda o papel (função) de cada um.
1. Cliente
2. Stub cliente
3. RPC runtime
4.Stub servidor
5. Servidor
Stub cliente ­ serve para interceptaras chamadas de procedimento do cliente                     
empacotando os parâmetros e enviando ao servidor. Após a chegada da resposta do                       
servidor ele desempacota o resultado e encaminha para o cliente.
● Stub servidor ­ recebe a requisição do cliente, desempacota os parâmetros, chama o                       
procedimento passando os parâmetros e quando obtém o resultado ele empacota e                     
encaminha de volta ao cliente.
__Objetos Distribuídos e Invocação Remota ­ parte 2
O que diferencia o RPC do RMI?
RPC: invoca procedimentos em processos remotos.
RMI: obj clientes invocam métodos de obj remotos.
Quais os principais conceitos envolvidos e suas implicações práticas?
Lembre­se do que fizemos em laboratório, dos exemplos que rodamos e também do
projeto que foi implementado.
O RMI tem vários componentes; entenda o papel (função) de cada um.
Proxy­Cliente: “modelo” do objeto remoto a ser chamado. Não contém a implementação real do
funcionamento do objeto, somente é um modelo para que a programação sobre um objeto
remoto pareça normal (transparência).
Endereçamento­no­Cliente (não sei o nome certo): responsável por direcionar a solicitação feita
sobre o proxy­cliente para o host remoto que contém o objeto real.
Dispatcher (no Servidor): recebe a chamada remota vinda pro cliente, localiza o “skeleton”
correto e encaminha para ele.
Skeleton (no Servidor): um tipo especial de proxy do objeto real, que contém interface
semelhante à dele. O Skeleton recebe a chamada do dispatcher, formata (chama
“unmarshalling” o processo) e encaminha pro “Servant”.
Servant (no Servidor): é o objeto real que você queria invocar um método no cliente. Deu toda
essa volta pra isso.
__Webservices
É possível usá­los com qq linguagem e paradigma de programação?
Teoricamente sim, uma vez que a única “restrição” é operar sobre XML e HTTP. Portanto, na
teoria, qualquer software é capaz de criar um serviço que siga as regras e/ou seja capaz de
invocar um Web Service.
Como funciona um webservice? Isto é, que protocolos são utilizados e quais suas
funções?
HTTP: Protocolo de comunicação / transporte padrão da Web
SOAP: Modelo para descrição do conteúdo das mensagens.
Que tipo de mensagem é trocada entre cliente­servidor? Alguma formatação espe­
cial?
Operam com XMLs formatados no padrão SOAP.
O webservice tem vários componentes; entenda o papel (função) de cada um.
Tópico: Computação em Nuvem e Sistemas P2P
__Computação em Nuvem
Entenda o conceito (definição) de computação em nuvem e suas principais caracte­
rísticas.
Aplicações e recursos estão em algum lugar remoto.
Também atente para as tecnologias que tornam a computação em nuvem possível.
Paradigmas de computação/negócio(grades e computação utilitária), hardware(virtualização e
multicore), tecnologias de internet(SOA, WS e Web2.0), gerenciamento de
sistemas(computação autônoma)
Em termos de classificações, pense sobre os modelos de implantação (quem é o do­
no, quem utiliza, onde está localizada) e os modelos de serviço (que serviços
são prestados).
Modelos:
Publico,Privado,Hibrido,Comunitário
Serviços:
XaaS: Everything as a Service
IaaS: Parte da infra e rede (Amazon WS)
PaaS:Parte da plataforma e desenvolvimento(Google App Engine)
SaaS: Parte da aplicação como serviço(dropbox, gDocs)
De ponto de vista das organizações (empresas), quais são as vantagens e desvan­
tagens de cada modelo (implantação e serviço)?
Pública:
● Vantagens
○ Redução de investimento em TI, pessoal, energia, local.
○ Não há contratos duradouros e complexos.
○ Agilidade em resolver uma tarefa
○ Escalabilidade por demanda
○ Abstração da tecnologia sendo usada
Privada
● Vantagens
○ Segurança
○ Otimização da infra já existente
○ Primeiro passo em direção a utilização do modelo hibrido ou público
Comunitária
Híbrida
Há vários desafios no paradigma de Computação em Nuvem: segurança, confiabilida­
de, disponibilidade, QoS, Interoperabilidade (padrões) e Questões Legais. Faça
um cenários para cada desafio, identificando­os no contexto de uma empresa que
está considerando adotar a computação em nuvem.
__Sistemas peer­to­peer
Principais características e objetivos.
Objetivos: Permitir o compartilhamento de dados e recursos em grande escala,
eliminando a exigência de servidores gerenciados separadamente e sua infraestrutura
associada.
Características principais:
● Usuários contribuem com recursos;
● Nós possuem mesmas capacidades e responsabilidades funcionais;
● Não dependendem de nenhum sistema administrado de forma centralizada;
● Podem oferecer um grau limitado de anonimato para provedores e usuários de
recursos;
● Problema: algoritmo que possibilite o arranjo dos dados em muitos hosts de maneira
que a carga de trabalho seja equilibrada.
Consequências da volatilidade de recursos.
Proprietários não garantem que irão mantê­los ligados, conectados e isentos de
falhas.
A disponibilidade é imprevisível.
A utilização da sobreposição de roteamento tem várias consequências e é bastante
diferente do roteamento que ocorre na camada IP de uma rede tradicional (IPv4 e
IPv6); entenda estas distinções.
Escalabilidade IPv4 é limitada a 232 nós
endereçáveis​​. o
IPv6 espaço de nome é muito
mais generoso (2128), mas
os endereços em ambas as
versões são
hierarquicamente estruturada
e grande parte do espaço é
pré­alocados de acordo com
as exigências
administrativas.
Sistemas Peer­to­peer
podem resolver mais objetos.
O GUID espaço de nome é
muito grande e plana (>
2128), permitindo que ele
seja muito mais totalmente
ocupado.
Balanceamento de Carga Cargas em roteadores são
determinados pela topologia
da rede e os padrões de
tráfego associados.
Localizações de objetos
podem ser randomizados e,
portanto, os padrões de
tráfego são
divorciados(separados) da
topologia da rede.
Dinâmica de rede (adição /
exclusão de objetos / nós)
Tabelas de roteamento IP
são atualizados de forma
assíncrona em uma base de
melhores esforços, com
constantes de tempo da
ordem de 1 hora.
As tabelas de roteamento
podem ser atualizados de
maneira síncrona ou
assíncrona com frações de
segundo atrasos.
Tolerância a falhas Redundância é projetado
para a rede IP por seus
gestores, garantindo a
tolerância de um único
roteador ou que
conectividade de rede falhe.
Replicar n vezes é caro.
Rotas e referências de objeto
podem ser replicados n
vezes, garantindo tolerância
de n falhas de nós ou
conexões.
Indentificação do
alvo(destino)
Cada endereço IP mapeia a
exatamente um nó de
destino.
As mensagens podem ser
encaminhadas para a réplica
mais próxima de um objeto
de destino.
Segurança e Anonimato Endereçamento é apenas
seguro quando todos os nós
são confiáveis​​. Anonimato
para os proprietários de
endereços não é possível.
A segurança pode ser
alcançada, mesmo em
ambientes com confiança
limitada. Um grau limitado de
anonimato pode ser
fornecida.
Distribuição das informações em uma sobreposição de roteamento:
● O conhecimento das localizações dos objetos deve ser particionado e distribuído por
toda a rede.
● Cada nó deve ser responsável por manter o conhecimento detalhado das localizações
dos nós e objetos em uma parte do espaço de nomes, assim como o conhecimento
geral da topologia do espaço de nomes inteiro.
● Um alto grau de replicação desse conhecimento é necessário para garantir a segurança
em face da disponibilidade volátil dos hosts e da conectividade intermitente da rede.
● Algoritmo distribuído para a localização de nós e objetos.
● O middleware direciona requisições de qualquer cliente para um host que contenha o objeto
para o qual a requisição é endereçada.
● Os objetos de interesse podem ser alocados e movidos para qualquer lugar da rede sem a
participação do cliente.
● Sobreposição: roteamento é implementado na camadade aplicação.
● O conhecimento de cada nó é explorado durante o roteamento.
● As réplicas dos objetos garantem a disponibilidade.
● GUIDS: não revelam nada sobre a localização dos objetos (nomes puros ou identificadores
opacos)
A utilização de um middleware para a implementação de sistemas P2P modernos re­
presenta um grande avanço nesta modalidade de computação distribuída; pense nas
características deste middleware.
Existem 3 gerações de sistemas p2p: 1ª(índice replicado centralizado), 2ª(maior escalabilidade,
anonimato e tolerância a falhas), 3º(camadas de middleware  ­ independência de aplicativo)
Características do middleware(3ª geração):
● Garantem o envio de pedidos em um número limitado de passos intermediários de rede.
● As réplicas dos recursos são colocadas de maneira estruturada em hosts disponíveis
de acordo com disponibilidade, confiabilidade, requisitos de carga, localização do
armazenamento e uso das informações.
● Identificação dos recursos: GUIDS
○ Identificadores únicos globais
○ Originados de um código de resumo (hashing) seguro
■ Torna um recurso automaticamente certificado – clientes podem verificar
sua validade.
■ Objetos devem ser imutáveis para que o código seja válido.
Problema da localização de recursos:
3ª geração (middleware): interface de programação simples que permita a implementação
independente do tipo de recurso distribuído.
Pense também nos algoritmos de roteamento utilizados nestes middleware.
Cada nó ativo armazena um conjunto de folhas – um vetor L (tamanho 2l)
O vetor contém GUIDs e endereços de IP dos nós cujos GUIDs são numericamente mais
próximos nos dois lados de si próprio (l acima e l abaixo)
Este conjunto é mantido à medida em que os nós entram e saem