4. ✔
Não existem Sistemas Operacionais Distribuídos, existem
apenas Sistemas Operacionais de rede como
✔
Linux
✔
MAC
✔
Windows
✔
Neste caso os SO’s devem oferecer suporte na implementação
de sistemas distribuídos
✔
Através da Combinação de Middleware + Sistema Operacional
podemos oferecer transparência em relação a rede e
abstração de certas atividades do SO.
Introdução
5. Processos
• É o conceito mais central em qualquer sistema
operacional
• É simplesmente um programa em execução,
incluindo os valores correntes do contador de
programa, dos registradores e das variáveis.
• Durante a execução do SO, a CPU alterna de
processo para processo, dando a impressão de
paralelismo
6. Processos
• SO cria vários processadores virtuais, sendo cada
um para executar um dado programa.
• SO possui uma tabela de processos para
monitorar esses processadores virtuais.
– A tabela possui:
• entradas para armazenar valores de
registradores de CPU
• Mapas de memória
• Arquivos abertos
• Informações sobre contabilidade
• Privilégios, etc...
• SO garante que os processos sejam
independentes de forma que não afetem uns aos
outros
• O compartilhamento da mesma CPU e outros
dispositivos é transparente para os processos.
7. Problemática dos Processos
• Nos anos 80, foi descoberto que a noção
tradicional de um sistema operacional, de um
processo que executa um único fluxo de execução,
era diferente dos requisitos dos sistemas
operacionais distribuídos.
• Diferente dos requisitos dos aplicativos mais
sofisticados que utilizam um único
processador, mas que exigem concorrência de
suas atividades internas.
• O único modo para seu programa acessar a dados
na estrutura (contexto) de um processo, consultar
ou mudar seu estado, é via uma chamada de
sistema.
8. Solução
• Aprimorar a noção de processo, para que ele
pudesse ser associado a múltiplas atividades
internas a ele.
• Com o surgimento de processadores de mais
alto desempenho, uma nova unidade de
processamento concorrente pode ser definida
dentro do próprio processo, novos fluxos de
execução e assim pode-se ter múltiplos fluxos
de execução (múltiplas threads) num mesmo
processo.
• Cada fluxo de execução é chamada Thread.
9. Threads
●
Executam sua própria porção de código
independente de outros threads
●
Rodam no espaço do usuário em contrapartida
aos processos que rodam no espaço do sistema
●
Mais barato do ponto de vista da CPU
●
Podem compartilhar áreas de endereçamento
●
Atualmente, um processo consiste em um
ambiente de execução, contendo uma ou mais
threads.
●
Threads (linhas de execução) são atividades
(tarefas internas) concorrentes executadas dentro
de um processo.
●
Um processo pode ter uma ou mais threads.
12. Multithread
• Múltiplas threads executam concorrentemente em
um processo, e é análogo a múltiplos processos
executando concorrentemente em um único
processador.
• Threads pertencentes a um mesmo processo,
compartilham os mesmos recursos e memória
(espaço de endereçamento) do processo.
• Cada thread pode ser associada a uma CPU
diferentes (em processadores modernos
• Exemplo de uma planilha rodando com 3 threads
de controle
– Controle interação do usuário
– Realizar atualização da planilha
– Realizar cópia de segurança
– Todos usando os mesmos dados
compartilhados em memória
13. Multithread
• No linux podemos avaliar as threds e processos através de
comandos como ps, top ou htop.
• TGID = Thread Group ID
• PID = Processo ID
14. Threads em Sistemas Distribuídos
• Clientes Multithread
– Para se obter alto grau de transparência de
distribuição, é necessário esconder o tempo de
propagação de mensagens entre processos
– Comumente o cliente deve executar mais outra
ação enquanto realiza a troca de mensagens
– Ex: Browser WEB
• Tão logo o arquivo HTML seja recebido,
threads separados se encarregam de buscar
outras partes
• Cada thread estabelece uma conexão
separada com o servidor
15. Threads em Sistemas Distribuídos
• Clientes Multithread
– Como servidores WEB normalmente são
replicados e cada thread abre uma nova
conexão com o servidor
– Temos a oportunidade de balancear carga do
servidor da aplicação, tendo em vista que cada
solicitação ao nosso servidor poderá ser
balanceada pelo DNS.
17. Threads em Sistemas Distribuídos
• Servidores Multithread
– Além da performance, através de Thread, é
possível elaborar um paralelismo;
– De forma fácil e simplificado;
– Ainda mais quando computadores possui
multiprocessadores;
– Também evitamos que a CPU fica ociosa;
18. Threads em Sistemas Distribuídos
• Servidores Multithread
– Para exemplificar:
• Implementação de um filesystem sem
recurso de threads
– Enquando o FS processa uma requisição e
aguarda pelo disco, a CPU fica bloqueada
para receber novas solicitações
• Implementação de um filesystem com
recurso de threads
– Modelo despachante/operário
– Ao receber uma solicitação, o
despachante entrega a uma thread que
vai solicitar ao disco
– Em paralelo o despachante recebe outras
demadnas e entrega para outras threads
22. Virtualização
“É um termo que se refere a criação de máquinas virtuais que se
comportam com se fosse um computador real. O software
executado nesta máquina virtual é separado do hardware real da
máquina.” Wikipedia
“É a criação de substitutos flexíveis para recursos reais —
substitutos que têm as mesmas funções e interfaces externas que
seus equivalentes reais, mas diferem em atributos como tamanho,
desempenho e custo. Esses substitutos são denominados recursos
virtuais; seus usuários geralmente não têm conhecimento da
substituição.”
IBM DeveloperWorks: Hypervisores, virtualização e a nuvem
23. Virtualização
“É um termo amplo da computação que se refere a capacidade de
executar software, comumente, sistemas operacionais, concorrentemente
e isolados de outros programas do sistema.
A maioria das implementações utiliza um hypervisor, uma camada de
software ou subsistema que controla o hardware e provê sistemas
operacionais guest com acesso ao nível mais baixo do hardware.
O hypervisor permite multiplos sistemas operacionais, chamados de guest,
a rodar no mesmo sistema, oferecendo hardware virtualizado ao sistema
operaciona guest.”
Red Hat Enterprise Linux 6 - Virtualization Getting Started
25. Por que Virtualizar ?
• Estende ou substitui uma interface existente de
modo a imitar o comportamento de um outro
sistema;
• Essência da virtualização é imitar o comportamento
das interfaces (instruções de máquina, chamadas
de sistema)
• Muito utilizado na década de 70, nos mainframes
da IBM, onde executava aplicativos e S.O. de vários
fornecedores (através das máquinas virtuais)
• Isolação de uma aplicação completa e seu ambiente
– Falhas, ataques ou vulnerabilidades afetam
apenas uma aplicação e não todas que rodam na
máquina
• Alocação rápida de novos hosts.
• Aproveitamento do tempo ocioso das CPU’s
26. Métodos para Virtualização de SO
• Full Virtualization:
– Utiliza funcionalidades do Hardware do
processador
– Oferece ao guest total abstração sistema físico
hospedeiro
– Permite rodar sistemas operacionais guest sem
modificação
– Aplicações e o próprio sistema operacional não
percebem que estão virtualizados
27. Métodos para Virtualização de SO
• Para-Virtualization:
– Utiliza conjunto de software e estrutura de
dados que deve estar presentes no sistema
guest
– Requer modificação de software no guest para
utilização do sistema para-virtualizado
– Pode englobar todo o kernel, ou drivers ou
dispositivos de i/o
– Desempenho próximo da máquina real
28. Métodos para Virtualização de SO
• Software Virtualization (or emulation)
– Utiliza técnica de slow binary translation ou
outras técnicas para rodar sistemas guest sem
modificação.
31. Hypervisor
• Os hypervisors são componentes de software
ou firmware que podem virtualizar recursos
do sistema.
• A virtualização geralmente é implementada através
de um Hypervisor
• Também chamado de Virtual Machine Monitor
(Monitor de Máquina Virtual) ou VMM
• Oferecem uma forma conveniente de usar o mesmo
hardware do computador físico para outras tarefas
diferentes
• Os hypervisors não são iguais, mas todos oferecem
recursos semelhantes
32. Tipos de Hypervisors
• Tipo 1
– Funcionam diretamente no HW
– Chamados de HardV
– Recomendados para servidores de produção
– Pode ser carregado via pendrive
– Baixo overhead
• Tipo 2
– Funcionam sobre um sistema operacional host e
oferecem o serviço de virtualização
– Chamados de SoftV
– Não recomendado para servidores de produção
– Normalmente utilizados como porta de entrada para a
virtualização
– Alto overhead, pois o SO Host consome recursos do Hw
• Temos outros tipos de virtualização, mas para escopo deste trabalho,
não foram descritos aqui
34. Exemplos de Hypervisor
• PowerVM
• VMware ESX Server (vSphere)
• Xen (Citrix)
• KVM
• z/VM
• Hyper-V
35. Funcionalidades desejadas em um
Hypervisor
• Desempenho da máquina virtual
Os sistemas virtuais deveriam ter desempenho similar
ou superior aos seus equivalentes, pelo menos em
relação aos aplicativos dentro cada servidor. Qualquer
coisa além dessa referência é lucro.
• Gerenciamento de memória
• Alta disponibilidade
Cada grande fornecedor tem sua própria solução de
alta disponibilidade e a maneira como cada um atinge
isso pode ser bem diferente, variando desde métodos
minimalistas até muito complexos
36. Funcionalidades desejadas em um
Hypervisor
• Migração ativa
Migração ativa em diferentes plataformas é a
capacidade de migrar simultaneamente duas ou mais
Vms
• Redes, armazenamento e segurança
Em rede, os hypervisors devem suportar agrupamento
de cartões de interface de rede (NICs) e
balanceamento de carga, isolamento Unicast e
suporte para o entroncamento de rede de área local
virtual (VLAN) padrão (802.1Q).
Em armazenamento, devem suportar armazenamento
em rede iSCSI e Fibre Channel
39. Servidor
• Um servidor é um processo que implementa um
serviço especifico
• Cada servidor é organizado do mesmo modo:
– Espera por uma requisição
– Processa-a
– Depois, espera pela próxima requisição
40. Servidor
• Na elaboração de um servidor, temos que
responder as seguintes perguntas:
– Como o cliente irá acessar o servidor?
– Como interromper a comunicação com o
servidor?
– Servidor deve guardar o estado dos clientes?
41. Servidor
Como os cliente irão acessar o servidor?
• Os servidores devem escolher um terminal (porta)
do computador para receber as requisições;
• Algumas portas são conhecidas (tais como o HTTP –
80 e o FTP – 20/21);
– Definidas pela IANA
• Existem duas maneiras de manipular portas:
– Utilizar um daemon
– Supeservidor (inetd no unix)
42. Servidor
Como os cliente irão acessar o servidor?
• O servidor cadastra a sua porta no daemon;
• O Cliente, antes de acessar o servidor, pergunta
qual porta está sendo disponibilizado;
• Depois, acessa o servidor;
43. Servidor
Como os cliente irão acessar o servidor?
• Para evitar que tenha processos ociosos esperando
por uma requisição;
• O supervisor monitora cada porta associada com
um serviço específico;
• Ao receber um requisição em uma dessas portas,
executa outro programa para continuar com o
requisição, e quanto terminar de atender, finaliza-o
• Ex.: Daemon inetd no Unix
44. Servidor
Como interromper a conexão com o servidor?
• Abordagem mais simples
– usuário finaliza o processo da aplicação cliente →
servidor encerrará a conexão antiga
• Abordagem mais completa:
– dados “urgentes” (fora da banda)
– Pacotes TCP possuem no header o campo URG.
– Servidor ao receber um pacote com o campo
URG setado é interrompido, através de um sinal.
45. Servidor
Servidor deve guardar o estado dos clientes?
• Existem três tipos de servidor:
– Sem estado
• Não mantém informações sobre os estados
dos clientes
• Pode mudar seu próprio estado sem ter de
informar a nenhum cliente
• As requisições atuais não influenciaram as
próximas requisições
• Vantagem: o serviço pode ser reiniciado e
não afeta as requisições dos clientes
• ex. Páginas WEB comuns
46. Servidor
Servidor deve guardar o estado dos clientes?
• Existem três tipos de servidor:
– Estado Flexível
• Armazena temporariamente o estado do
Cliente
• Após o tempo limitado, o servidor descarta
estas informações
• As requisições atuais não influenciaram as
próximas requisições
• ex. Session de uma página WEB
47. Servidor
Servidor deve guardar o estado dos clientes?
• Existem três tipos de servidor:
– Com Estado
• O servidor irá armazenar o estado do Cliente;
• As informações sobre precisam ser
explicitamente removidos pelo servidor;
• Problema: além de ter que armazenar o
estado de cada cliente, caso o servidor caia e
volte a funcionar, pode perder todos os
estados de todos os clientes;
• ex. Servidor de arquivos que permite a um
cliente manter cópia local de um arquivo.
Servidor mantêm uma tabela, com entradas
(cliente, arquivo). Permite monitorar as
permissões sobre um arquivo, etc.
• ex2: Tracker Bittorrent
48. Servidor - Clusters
• Uma forma de tornar o serviço mais disponível
agrupando computadores formando um Cluster
• Cluster é: Conjunto de máquinas conectadas por
uma rede, no qual cada máquina executa um ou
mais servidores. Estas máquinas estão conectadas
por uma rede local, com alta largura de banda e
baixa latência.
• Geralmente, é divido em 3 camadas;
50. Servidor - Clusters
• Primeira Camada
– Forma o ponto de entrada para o cluster de
servidores, oferecendo um único endereço de
rede.
– Considerando TCP, o comutador aceita
requisições e as transfere a um dos servidores
– Deve elaborar algum esquema de
balanceamento de carga: identificando o melhor
servidor a tratar a requisição ou sempre
selecionado um servidor diferente
52. Servidor - Clusters
• Segunda Camada
– Servidores dedicados a processamento de
aplicações
– Normalmente servidores que executam
hardware de alto desempenho dedicado a
aumentar a capacidade de computação
– Clusters corporativos podem rodar com
máquinas comuns quando o gragalo for o acesso
ao disco.
53. Servidor - Clusters
• Terceira Camada
– Servidores de processamento de dados,
especialmente servidores de arquivo e banco de
dados
– Podem usar máquinas especializadas para
acesso a alta velocidade a disco e que têm
grandes caches dedos ao lado do servidor
54. Um exemplo de um site a utilizar técnicas de balanceamento de carga é a
própria Wikimedia Foundation e os seus projetos. Em Junho de 2004, a carga
era balanceada usando uma combinação de:
➔
Round robin DNS, que distribui os pedidos uniformemente para um dos
três servidores de cache Squid;
➔
Estes servidores de cache usam os tempos de resposta para distribuir os
pedidos para cada um dos sete servidores de páginas. Em média, os
servidores Squid já têm em cache páginas suficientes para satisfazer 75%
dos pedidos sem sequer consultar os servidores de páginas;
➔
Os scripts PHP que formam a aplicação distribuem a carga para um de vários
servidores de base de dados dependendo do tipo do pedido, com as
atualizações indo para um servidor primário e as consultas para um ou mais
servidores secundários.
- http://pt.wikipedia.org/wiki/Balanceamento_de_Carga
Balanceamento de Carga (Load Balancing)
55. Migração de Código
• Migração de código ocorre, tradicionalmente, na
forma de migração de processo;
• Todo o processo migra de uma máquina à outra;
• Isso é uma tarefa custosa e complicada;
• O motivo para fazer isso é sempre a
otimização (desempenho);
• Exemplo de um uso:
– Em um cluster, para melhorar o balanceamento
de carga, pode migrar programas para máquinas
ociosas, liberando as demais;
– Um cliente, antes de interagir com o servidor,
necessita baixa um código;
57. Migração de Código
• Consiste em três segmentos:
– Segmento de código: contém o conjunto de
instruções que compõem o programa que está
em execução
– Segmento de recursos: contém referências a
recursos externos (arquivos, impressoras)
– Segmento de execução: armazenar o estado
em execução de um processo no momento da
migração (dados privados, pilha,contador de
programa)
58. Migração de Código
• Mobilidade pode ser de dois tipos:
– Mobilidade Fraca: possível transferir somente
o segmento de código, junto com alguns dados
de inicialização. Requer somente que a
máquina-alvo possa executar o código
(portabilidade)
– Mobilidade Forte: segmento de execução
também pode ser transferido. O processo em
execução pode ser parado e movido para uma
outra máquina e retomar a execução no ponto
original
59. Migração de Código
• Em relação do ponto de início da migração:
– Iniciada pelo remetente: a migração é
iniciada na máquina em que o código está em
execução
• Ex.: enviar programa de busca pela Internet
a um servidor de banco de dados para
realização de pesquisas; agente móvel que→
passa de site para site
– Iniciada pelo destinatário: Iniciativa da
migração de código é tomada pela máquina-alvo
(cliente);
• Ex.: Applet do Java
60. Migração de Código
• Destinatário:
– Mais simples que pelo remetente.
– Cliente toma iniciativa de migração.
• Contrário requer mecanismos de confiança entre
cliente e servidor
– Login/identificação
• Destinatário pode ser feita no anonimato
– Servidor não se interessa pelos dados do cliente
– Migração serve para melhorar desempenho do
cliente.
61. Migração de Código - Recursos
• Três tipos de vinculações processo-recurso:
– Vinculação por identificador
• Processo requer exatamente o recurso
referenciado (URL de um site)
– Vinculação por valor
• É necessário somente um valor
• Se outro recurso fornece o mesmo valor,
execução não é afetada (bibliotecas
padronizadas)
– Vinculação por tipo
• Processo requer um recurso de um tipo
específico (monitores,impressoras)
62. Migração de Código - Recursos
• Três tipos de vinculações recurso-máquina:
– Recursos não ligados: recursos podem ser
movidos com facilidade entre maquinas
diferentes(arquivos de dados)
– Recursos amarrados: recursos podem ser
movidos ou copiados, mas só a custo
relativamente alto ( banco de dados locais)
– Recurso fixos: recursos estão intimamente
vinculados a uma máquina ou ambiente
especifico e não podem ser movidos (porta)
63. Migração de Código
• Referência global
– Caso vários processos referenciem um recurso,
uma alternativa é estabelecer uma referência
global, que atravesse as fronteiras das máquinas
• URL (baixa complexidade)
• Memória compartilhada entre processos
(referência global significa memória
compartilhada)
64. Migração de Código
• Complexidade está ligada aos tipos de vínculo
processo-recurso e recurso-máquina
– Recursos não ligados: Melhor solução é copiar
ou mover o recurso para o novo destino
– Vinculações por tipo: A solução é vincular
novamente o processo a um recurso do mesmo
tipo disponível no local
65. Migração de Código - Heterogêneos
• Sistemas distribuído são construídos em ambientes
heterogêneos (S.O. E arquitetura de máquina);
• A migração de código neste cenário requer que
cada plataforma seja suportada pelo sistemas;
• Assegurando que cada segmento de código pode
ser executado e representado em cada plataforma;
66. Migração de Código - Heterogêneos
• Existem duas alternativas:
– Utilizar linguagens de programação alta
portabilidade (ex. Baseadas em
interpretadores/scripts – PHP – ou “compiladas”
- Java );
• conseguimos executar segmento de processo
em máquina diferentes
– Usar máquinas virtuais, virtualizando
recursos da máquina, possibilitando uniformiza
estes recursos;
• permite migra todo um sistema operacional
de uma máquina a outra;