Gostei da tecnica de Grid utiliza os recursos de diferentes computadores com o intuito de resolver problemas de grande complexidade e/ou volume, estando portanto, não limitada apenas à execução distribuída de algoritmos de processamento, mas também gerenciamento de grande quantidade de dados distribuídos.Uma maneira mais simples de descrever a arquitetura de um grid baseia-se na divisão do mesmo em camadas de acordo com o seu recurso.Desta maneira tornando possível dividir um Grid seguintes quatro camadas:rede, recurso, middleware,Aplicação e Serviços.os grids, devido a sua estrutura descentralizada, têm uma disposição de recursos computacionais muito mais heterogênea do que um cluster. Ou seja, a variação do poder de processamento, memória, disco, etc dos membros de um grid é muito maior do que aquela encontrada nos membros de um cluster (aonde o que se deseja geralmente é o contrário, caso contrário, poderia configurar-se como um gargalo).•os membros (nós) de um grid não precisam estar permanentemente inter-conectados.Clusters tendem a serem utilizados para solução de problemas lineares, ao passo que Grids devem ser utilizados para sistemas capazes de serem processados em paralelo.Por fim, é importante ressaltar que é possível criar grids utilizando clusters como membros, entretanto o contrário não é possível.
fonte:
http://www.gridcafe.web.cern.ch
www.gridcomputing.com/gridfaq.html
apostila do Centro Universitario Positivo-UnicenP
Marcele Barreto Soares
mat 104040495
sexta-feira, 29 de fevereiro de 2008
>> Técnicas de Escalabilidade <<
Uma das principais Metas de um Sistema Distribuído diz respeito a capacidade de crescimento do sistema, ESCALABILIDADE.
Muitos desenvolvedores de Sistemas Distribuídos utilizam facilmente a palavra escalável sem deixar claro porque seus clientes realmente escalam.
Escalabilidade tem no mínimo 3 componentes:
Número de usuários e/ou processos (tamanho);
Distância máxima entre nodos (geográfica);
Número de domínios administrativos (administrativa).
Grande parte dos sistemas contam apenas Escalabilidade em tamanho. A solução são Servidores Poderosos.
Mas atualmente, o grande desafio é a Escalabilidade Geográfica e Administrativa.
Das técnicas:
> Distribuição --> Dividir dados e computações nas máquinas;
> Replicação --> Fazer cópias diponíveis em várias máquinas;
> Caching --> Permitir processos clientes acessar cópias locais.
Segue o link para o material. Achei fantástico!
http://www.inf.ufsc.br/~mario/ine6502ch1.pdf
Jeovane Firmo da Silva.
Escalabilidade em Sistemas Multiprocessadores Vs. MultiComputadores
Projetar máquinas, nas quais vários processador utilizam a mesma memória física não é tão trivial. Esta característica limita a escalabilidade de arquiteturas como multiprocessadores e multicomputadores.
Nos Sistemas multiprocessadores(memória compartilhada), duas ou mais CPU's compartilham uma mesma memória principal. Qualquer processo ou processador pode ler ou escrever nessa memória compartilhada de maneira simples. Ao contrário, nos sistemas multicomputadores(memória distribuída), cada CPU tem sua própria memória privada, sendo que a comunicação entre as máquinas é realizada por passagem de mensagens via rede.
Multicomputadores são simples de construir mas difíceis de programar, sendo os multiprocessadores o oposto, difíceis de construir mas simples de programar. Dessa forma aumentou o interesse por memórias compartilhadas distribuídas(MCD).
O objetivo do compartilhamento de memórias distribuídas é viabilizar o compartilhamento de informações entre processos que se comunicam por uma simulação de um espaço de endereçamento lógico compartilhado, sobre um conjunto de memórias locais distribuídas fisicamente.
O artigo aborda dois diferentes tipos de implementação em arquitetura NUMA: MCD(Memória Compartilhada Distribuída) e MCM(Memória Cache de Multiprocessadores).
A escalabilidade em sistemas multicomputadores é mais complicada exigindo técnicas de sistemas distribuídos, porém suporta processamentos maiores.
Bibliografia
http://www.dcce.ibilce.unesp.br/~norian/cursos/pso/seminarios2002/so10.pdf
Chrystiano Barbosa de Souza Araújo
Escalabilidade em sistemas distribuídos utilizando CORBA
Introdução
CORBA é um midleware utilizado para garantir a interoperabilidade entre sistemas abertos que sigam o seu padrão.
Atualmente muitas aplicações tolerantes a faltas estão seguindo o paradigma de orientação a objetos e considerando CORBA como a melhor alternativa de se adequar aos requisitos de sistemas abertos. Esta foi à motivação para a formação de uma força tarefa com o intuito de introduzir conceitos e abstrações para tolerância à faltas em CORBA. No entanto as especificações do Fault_Tolerant CORBA ainda não são capazes de garantir a escalabilidade para sistemas distribuídos de larga escala tolerantes a falta.
A proposta do artigo é um conjunto de propostas e extensões ao FT-CORBA, que visam tratar o problema de escalabilidade em sistemas distribuídos de larga escala.
Uma falta identificada no FT_CORBA é que o seu sistema de controle de falhas se limita a definir interfaces de uso genérico, omitindo-se por exemplo da padronização de serviços de comunicação de grupos confiáveis, base fundamental para implementação de técnicas de replicação ativa. Para a atenuação deste problema foi proposto o projeto GroupPack que corresponde a um conjunto de serviços específicos próprios para o desenvolvimento de aplicações tolerantes a falhas.
Serviço de detecção de falhas do GroupPack
O sistema de detecção de falhas do FT-CORBA é ineficaz para sistemas com características assíncronas. Para isso o GroupPack estende a noção de falhas, sem que isto represente na modificação das interfaces da especificação do FT-CORBA. É assumido que um host é considerado em crash se não responder a um certo número de detectores de falhas dentro de timeouts específicos. É necessário então um procedimento de consenso para ser executado por um conjunto de detectores na determinação de falhas, pois o monitoramento de um host a partir de um grupo de detectores minimiza a probabilidade de erros na detecção.
Localizando grupos de objetos no GroupPack
Uma forma de permitir que objetos, dos diferentes domínios de TF, pudessem ser localizados e se juntar ou sair de um grupo dinamicamente durante o ciclo de vida da replicação é através da associação de domínios de TF com o serviço de nomes, uma vez que o FT-CORBA não possui uma interface para deixar disponível as referências para grupos de objetos a objetos clientes.
Propriedades de TF para dar Suporte a Escalabilidade
Propriedades de tolerância à faltas são associadas a cada grupo de objeto em um domínio de tolerância à faltas. Dentre estas propriedade estão o tipo de replicação, estilo de monitoramento de falhas, intervalo de monitoramento de falhas, número inicial de réplicas e intervalo de atualização de estado. Estas propriedades e seus valores podem ser entendidos de acordo com as necessidades de cada aplicação. Para dar suporte aos grupos interdomínios, foram introduzidas duas novas propriedades:
1- InterdomainGroup: determina se um grupo contém membros em diferentes domínios ou não.
2- OrderingType: determina o tipo de ordenação a ser utilizada pelos Gateway Seqüenciadores, que tem como função servir de ponte para difusão de uma mensagem entre diferentes subgrupos de um grupo interdomínio.
Opinião
Sendo CORBA um dos midlewares mais utilizados para o desenvolvimento de sistemas distribuídos, com o melhoramento das técnicas de tolerância a falhas propostas para o FT_CORBA através da integração com o GroupPack, torna-se possível garantir a escalabilidade de uma outra categoria de sistemas distribuídos, que são os sistemas assíncronos e de larga escala tolerantes a falhas. Isso possibilita mais segurança na utilização desses sistemas e um maior suporte para o seu desenvolvimento.
Thiago Ribeiro Nunes \ 105040501
Sistemas Distribuídos
Fonte: http://www.ppgia.pucpr.br/~lau/papers/PaperRita.pdf
técnica de escalabilidade em Peer-to-Peer ou P2P
Com o crescimento exponencial do número de computadores ligados à Internet, vem crescendo também a necessidade de redes de computadores mais eficazes, não somente em relação a tecnologias de transmissão, mas também na forma que elas ocorrem. Arquitetura mais utilizada na Internet para comunicação, sem dúvida é a cliente/servidor, onde o cliente pode ser,desde um celular,pocket,desktop ou qualquer dispositivo que possui processador.Neste caso, todos clientes comunicam-se com um servidor central, o qual é responsável pela comunicação com todos os outros clientes envolvidos. Isso muitas vezes pode provocar uma sobrecarga excessiva no servidor, já que todas mensagens são propagadas pelo mesmo. Uma maneira de diminuir a sobrecarga do servidor é fazer com que cada cliente ligado à rede faça o papel tanto de servidor quanto cliente.
A arquitetura Peer-to-Peer(par-a-par) ou P2P difere de rede cliente/servidor convencional porque seus métodos envolve sistemas servido outros sistema. Onde cada cliente conectado pode comunicar-se diretamente com outro cliente sem haver necessidade direta de um servidor, pois o cliente também faz este papel. Em 1999, Shawn fanning criou Napster , uma aplicação para compartilhamento de arquivos de música entre computadores ligados à Internet, também usando P2P. Desde então, P2P vem ganhando um grande espaço.
Hoje existem diversas aplicações usando redes P2P :Kazaa,Shareaza,Emule,MSN,AOL entre outros. Cada uma destas aplicações implementa um conjunto de protocolos proprietários, onde não há compatibilidade entre diversas aplicações do mesmo segmento. Por exemplo, o MSN Messenger não troca mensagens com o AOL Internet Messenger e vice versa.
A principal diferença entre arquiteturas P2P e cliente/servidor é o conceito de entidades, onde nessa última existe uma entidade que faz o papel de servidor e outras entidades que fazem o papel de clientes. Já na arquitetura P2P as entidades podem atuar ao mesmo tempo como servidores e como clientes.
A principal vantagem que ela permite a distribuição de responsabilidades em prover serviços para outros computadores da rede, eliminando o processamento excessivo em um único ponto, já no caso de uma arquitetura cliente/servidor é o próprio servidor que processa todas as requisições. Além disso, redes P2P podem ter uma melhor exploração de largura de banda da rede, usando para extremidades da Internet uma maior variedade de canais de comunicação. P2P tem a capacidade de servir recursos com alta disponibilidade por um menor custo,enquanto maximiza o uso dos recursos de todos os computadores conectados à rede. Considerando que soluções cliente/servidor necessitam de equipamentos de rede e instalações diferenciadas para conseguir soluções robustas, P2P pode oferecer um nível de robustez semelhante, distribuindo as necessidades por toda rede.
Infelizmente, P2P oferece algumas desvantagens devido à natureza redundante da estrutura da rede que lhe faz necessária. A forma distribuída de canais dessa rede resulta em pedidos de serviços de natureza não-determinística. Por exemplo, clientes requisitam um mesmo arquivo da rede P2P e podem conectar-se em máquinas completamente diferentes por rotas de comunicação diferentes e com resultados diferentes. Pedidos enviados podem não ter resultados imediatos e em muitos casos pode não resultar em qualquer resposta.
Porém P2P pode superar todas essas limitações. Embora recursos possam muitas vezesdesaparecer na rede, P2P pode implementar funcionalidades para replicar os recursos maisacessados em outros computadores da rede, promovendo assim acesso redundante a este recurso.Quanto maior o número de computadores que possui recursos replicados, menor será a probabilidade de um computador receber um pedido sem resposta. Em resumo, a mesma estrutura que pode causar problemas pode ser a solução para resolvê-los.
Link: http://pt.wikipedia.org/wiki/P2p
http://brasiliavirtual.info/tudo-sobre/p2p/
http://www.gta.ufrj.br/grad/04_1/p2p/
http://info.abril.com.br/busca/resultado.shtml?qu=p2p&si=info&si=infocorporate&ac=0&np=10&rd=1&ao=0
Nome: Jefferson neves de moura
Matricula: 105040029
A arquitetura Peer-to-Peer(par-a-par) ou P2P difere de rede cliente/servidor convencional porque seus métodos envolve sistemas servido outros sistema. Onde cada cliente conectado pode comunicar-se diretamente com outro cliente sem haver necessidade direta de um servidor, pois o cliente também faz este papel. Em 1999, Shawn fanning criou Napster , uma aplicação para compartilhamento de arquivos de música entre computadores ligados à Internet, também usando P2P. Desde então, P2P vem ganhando um grande espaço.
Hoje existem diversas aplicações usando redes P2P :Kazaa,Shareaza,Emule,MSN,AOL entre outros. Cada uma destas aplicações implementa um conjunto de protocolos proprietários, onde não há compatibilidade entre diversas aplicações do mesmo segmento. Por exemplo, o MSN Messenger não troca mensagens com o AOL Internet Messenger e vice versa.
A principal diferença entre arquiteturas P2P e cliente/servidor é o conceito de entidades, onde nessa última existe uma entidade que faz o papel de servidor e outras entidades que fazem o papel de clientes. Já na arquitetura P2P as entidades podem atuar ao mesmo tempo como servidores e como clientes.
A principal vantagem que ela permite a distribuição de responsabilidades em prover serviços para outros computadores da rede, eliminando o processamento excessivo em um único ponto, já no caso de uma arquitetura cliente/servidor é o próprio servidor que processa todas as requisições. Além disso, redes P2P podem ter uma melhor exploração de largura de banda da rede, usando para extremidades da Internet uma maior variedade de canais de comunicação. P2P tem a capacidade de servir recursos com alta disponibilidade por um menor custo,enquanto maximiza o uso dos recursos de todos os computadores conectados à rede. Considerando que soluções cliente/servidor necessitam de equipamentos de rede e instalações diferenciadas para conseguir soluções robustas, P2P pode oferecer um nível de robustez semelhante, distribuindo as necessidades por toda rede.
Infelizmente, P2P oferece algumas desvantagens devido à natureza redundante da estrutura da rede que lhe faz necessária. A forma distribuída de canais dessa rede resulta em pedidos de serviços de natureza não-determinística. Por exemplo, clientes requisitam um mesmo arquivo da rede P2P e podem conectar-se em máquinas completamente diferentes por rotas de comunicação diferentes e com resultados diferentes. Pedidos enviados podem não ter resultados imediatos e em muitos casos pode não resultar em qualquer resposta.
Porém P2P pode superar todas essas limitações. Embora recursos possam muitas vezesdesaparecer na rede, P2P pode implementar funcionalidades para replicar os recursos maisacessados em outros computadores da rede, promovendo assim acesso redundante a este recurso.Quanto maior o número de computadores que possui recursos replicados, menor será a probabilidade de um computador receber um pedido sem resposta. Em resumo, a mesma estrutura que pode causar problemas pode ser a solução para resolvê-los.
Link: http://pt.wikipedia.org/wiki/P2p
http://brasiliavirtual.info/tudo-sobre/p2p/
http://www.gta.ufrj.br/grad/04_1/p2p/
http://info.abril.com.br/busca/resultado.shtml?qu=p2p&si=info&si=infocorporate&ac=0&np=10&rd=1&ao=0
Nome: Jefferson neves de moura
Matricula: 105040029
Escalabilidade em jogos massives multplayer
Um exemplo de aplicação de sistemas distribuídos amplamente utilizados atualmente são os jogos massive Multiplayer. Com a crescente popularização da internet, sistemas como esse tornam-se cada vez mais populares. Porém aumentando a quantidade de adeptos, logo a de jogadores em uma aplicação, aumentam-se as exigências de escalabilidade no processamento para não haver uma perda na jogabilidade.
Muito tem sido feito, inclusive pela comunidade acadêmica, na construção de sistemas virtuais distribuídos. Uma abordagem introdutória sucinta, porém esclarecedora sobre massives multiplayer é apresentada por Kozovits e Feijó no artigo Arquiteturas para Jogos Massive Multiplayer disponível em ftp://ftp.inf.puc-rio.br/pub/docs/techreports/03_36_kozovits.pdf (acessado em 28 de fevereiro de 2008).
Algumas abordagens para esses sistemas utilizam a tecnologia peer-to-peer. Porém uma limitação ao uso desta tecnologia nesse tipo de sistemas é a escalabilidade, pois as alterações na cena de cada personagem são notificadas a todos os outros com uma complexidade de O(n^2). Logo, aumentando o número de personagens extrapola-se as limitações da rede. Outra tecnologia que pode ser usada é a broadcast. A complexidade da escalabilidade desta é de O(n). Ainda assim pode-se haver problemas no gerenciamento de pacotes na comunicação entre os personagens. Uma boa opção é a utilização de sistemas multicast. Porém tal tecnologia ainda não está disponível em redes para consumo em massa.
Desta forma a arquitetura natural para tal sistema é a Cliente/Servidor. Nela é possível gerenciar a comunicação de modo mais eficiente, restringindo que um cliente só se comunique com os demais que estejam no mesmo ambiente fechado ou a uma distância próxima em um ambiente aberto. Utilizando essa arquitetura em sistemas com ambientes particionados a escalabilidade pode ser ainda melhorada. A abordagem de alguns temas referentes à construção de um jogo massive multiplayer neste artigo é razoável. Apesar de não se aprofundar muito sobre o modelo de escalabilidade na comunicação entre personagens e destes com o ambiente (sistema) a arquitetura proposta sugere uma implementação não tão complexa agregada um bom funcionamento da mesma.
A abordagem sobre demais problemas referentes à comunicação entre entidades deste sistema, apesar de fugir do tema principal deste blog, também é algo interessante (e como ressaltado no artigo pouco abordado na literatura).
28 de fevereiro de 2008
Leandro Moraes V. Cruz
Disciplina Sistemas Distribuídos
Curso Ciências da Computação
Universidade Cândido Mendes – Campos/RJ
Muito tem sido feito, inclusive pela comunidade acadêmica, na construção de sistemas virtuais distribuídos. Uma abordagem introdutória sucinta, porém esclarecedora sobre massives multiplayer é apresentada por Kozovits e Feijó no artigo Arquiteturas para Jogos Massive Multiplayer disponível em ftp://ftp.inf.puc-rio.br/pub/docs/techreports/03_36_kozovits.pdf (acessado em 28 de fevereiro de 2008).
Algumas abordagens para esses sistemas utilizam a tecnologia peer-to-peer. Porém uma limitação ao uso desta tecnologia nesse tipo de sistemas é a escalabilidade, pois as alterações na cena de cada personagem são notificadas a todos os outros com uma complexidade de O(n^2). Logo, aumentando o número de personagens extrapola-se as limitações da rede. Outra tecnologia que pode ser usada é a broadcast. A complexidade da escalabilidade desta é de O(n). Ainda assim pode-se haver problemas no gerenciamento de pacotes na comunicação entre os personagens. Uma boa opção é a utilização de sistemas multicast. Porém tal tecnologia ainda não está disponível em redes para consumo em massa.
Desta forma a arquitetura natural para tal sistema é a Cliente/Servidor. Nela é possível gerenciar a comunicação de modo mais eficiente, restringindo que um cliente só se comunique com os demais que estejam no mesmo ambiente fechado ou a uma distância próxima em um ambiente aberto. Utilizando essa arquitetura em sistemas com ambientes particionados a escalabilidade pode ser ainda melhorada. A abordagem de alguns temas referentes à construção de um jogo massive multiplayer neste artigo é razoável. Apesar de não se aprofundar muito sobre o modelo de escalabilidade na comunicação entre personagens e destes com o ambiente (sistema) a arquitetura proposta sugere uma implementação não tão complexa agregada um bom funcionamento da mesma.
A abordagem sobre demais problemas referentes à comunicação entre entidades deste sistema, apesar de fugir do tema principal deste blog, também é algo interessante (e como ressaltado no artigo pouco abordado na literatura).
28 de fevereiro de 2008
Leandro Moraes V. Cruz
Disciplina Sistemas Distribuídos
Curso Ciências da Computação
Universidade Cândido Mendes – Campos/RJ
Técnicas de escalabilidade
Três exemplos de técnicas de escalabilidade
1 - Esconder a Latência na Comunicação
• Construir a aplicação de forma a utilizar somente comunicação assíncrona;
• Em aplicações batch e paralelas normalmente é bem aceita mas o mesmo não ocorre em aplicações interativas;
• Neste caso, uma solução é diminuir a necessidade de comunicação movendo parte da computação do servidor para o cliente.
2 - Distribuição
• Divide-se um componente, distribuindo-o na rede.
3 - Replicação
• Aumenta a disponibilidade e ajuda a balancear a carga de trabalho entre componentes levando a um melhor desempenho;
• Caching é uma forma especial de replicação na qual a decisão de trazer o objeto é de seu cliente e não de seu proprietário;
• Pode levar a problemas de consistência.
Fonte: http://www.deinf.ufma.br/~fssilva/graduacao/sd/aulas/apresentacao.pdf
1 - Esconder a Latência na Comunicação
• Construir a aplicação de forma a utilizar somente comunicação assíncrona;
• Em aplicações batch e paralelas normalmente é bem aceita mas o mesmo não ocorre em aplicações interativas;
• Neste caso, uma solução é diminuir a necessidade de comunicação movendo parte da computação do servidor para o cliente.
2 - Distribuição
• Divide-se um componente, distribuindo-o na rede.
3 - Replicação
• Aumenta a disponibilidade e ajuda a balancear a carga de trabalho entre componentes levando a um melhor desempenho;
• Caching é uma forma especial de replicação na qual a decisão de trazer o objeto é de seu cliente e não de seu proprietário;
• Pode levar a problemas de consistência.
Fonte: http://www.deinf.ufma.br/~fssilva/graduacao/sd/aulas/apresentacao.pdf
Escalabilidade
[...]
1.2.3 Escalabilidade
A maioria dos sistemas distribuídos atuais é projetada para trabalhar com vários processadores (em rede).
· · Problemas de Escalabilidade
Quando um sistema necessita escalar diferentes tipos de problemas para serem resolvidos. Considera primeiramente, a escala com respeito ao tamanho. Se mais usuários ou recursos necessitar ser suportado, somos freqüentemente confrontados com as limitações dos serviços centralizados, dados e algoritmos (ver figura 1-3). Por exemplo, muitos serviços são centralizados no sentido que são executados por meio somente de um único servidor que “funciona” em uma máquina específica no sistema distribuído.
Concept Example
Centralized algorithms Doing routing based on complete information
Centralized data A single on-line telephone book
Centralized services A single server for all users
Figura1-3: exemplos limitações da escalabilidade
Serviços centralizados: um simples servidor pra todos os usuários.
Dados centralizados: uma única lista telefônica on-line.
Algoritmos centralizados: fazer roteamento com base em informações completas.
· · Técnica de Escalabilidade
Há discussões sobre alguns problemas da escalabilidade, problemas que podem ser geralmente solucionados. Porque os problemas nos sistemas distribuídos aparecem como problemas de desempenho causado por capacidade limitada de servidores e rede, há basicamente, três técnicas de escalabilidade: latência de comunicação, distribuição e replicação.
Latência de comunicação é aplicada no caso da escalabilidade geográfica. A idéia básica é simples: tentativa de evitar esperar para responder para um pedido de um servidor remoto com muitas possibilidades.
Entretanto, a muitos aplicativos que não fazem uso efetivo da comunicação assíncrona. Um caso típico onde há aproximação de palavras no acesso de bases de dados usando formulários. Normalmente, em formulários são feitos para serem enviados em separados para cada campo da mensagem, e espera-se por um reconhecimento do servidor, como mostra a figura 1-4(a). Por exemplo, o servidor pode checar se há erros antes de aceitar a entrada. Uma solução melhor é transportar o código preenchido no formulário, verificando a entrada, por cliente, tendo o cliente de retorna um formulário completo, como mostra a figura 1-4 (b).
Outra importante técnica de escalabilidade é a distribuição. Distribuição envolve exige componentes, divide em pequenas partes, e subseqüentemente dissemina aquelas partes através do sistema. Um bom exemplo de distribuição é a “Internet Domain Name System (DNS)”. O DNS é hierarquicamente, organizado em uma árvore de domínios, que são divididos entre zonas, como mostra a figura 1-5.
Figura 1-5: exemplo da divisão do DNS entre zonas.
[...]
Como dito pelo autor, os problemas do sistema distribuído são inúmeros. Os ditos “problemas conceito” categorizam tais problemas, tornando-os mais fáceis de serem entendidos.
O autor não cita qual técnica é a mais viável para resolução de problemas (solucionáveis), mesmo que isso dependa do problema enfrentado. A citação sobre o DNS com a utilização da técnica de distribuição utilizada para gerar a divisão das zonas foi uma parte interessante que me chamou atenção, pois nunca tinha pensado como seria o funcionamento real de tal funcionalidade.
Jônatas Oliveira Lopes Soares
Fonte: http://www1.fatecsp.br/aguiar/sistemasdistribuidos.htm
Ficou sem fotos pois nao foi possivel posta-las.
1.2.3 Escalabilidade
A maioria dos sistemas distribuídos atuais é projetada para trabalhar com vários processadores (em rede).
· · Problemas de Escalabilidade
Quando um sistema necessita escalar diferentes tipos de problemas para serem resolvidos. Considera primeiramente, a escala com respeito ao tamanho. Se mais usuários ou recursos necessitar ser suportado, somos freqüentemente confrontados com as limitações dos serviços centralizados, dados e algoritmos (ver figura 1-3). Por exemplo, muitos serviços são centralizados no sentido que são executados por meio somente de um único servidor que “funciona” em uma máquina específica no sistema distribuído.
Concept Example
Centralized algorithms Doing routing based on complete information
Centralized data A single on-line telephone book
Centralized services A single server for all users
Figura1-3: exemplos limitações da escalabilidade
Serviços centralizados: um simples servidor pra todos os usuários.
Dados centralizados: uma única lista telefônica on-line.
Algoritmos centralizados: fazer roteamento com base em informações completas.
· · Técnica de Escalabilidade
Há discussões sobre alguns problemas da escalabilidade, problemas que podem ser geralmente solucionados. Porque os problemas nos sistemas distribuídos aparecem como problemas de desempenho causado por capacidade limitada de servidores e rede, há basicamente, três técnicas de escalabilidade: latência de comunicação, distribuição e replicação.
Latência de comunicação é aplicada no caso da escalabilidade geográfica. A idéia básica é simples: tentativa de evitar esperar para responder para um pedido de um servidor remoto com muitas possibilidades.
Entretanto, a muitos aplicativos que não fazem uso efetivo da comunicação assíncrona. Um caso típico onde há aproximação de palavras no acesso de bases de dados usando formulários. Normalmente, em formulários são feitos para serem enviados em separados para cada campo da mensagem, e espera-se por um reconhecimento do servidor, como mostra a figura 1-4(a). Por exemplo, o servidor pode checar se há erros antes de aceitar a entrada. Uma solução melhor é transportar o código preenchido no formulário, verificando a entrada, por cliente, tendo o cliente de retorna um formulário completo, como mostra a figura 1-4 (b).
Outra importante técnica de escalabilidade é a distribuição. Distribuição envolve exige componentes, divide em pequenas partes, e subseqüentemente dissemina aquelas partes através do sistema. Um bom exemplo de distribuição é a “Internet Domain Name System (DNS)”. O DNS é hierarquicamente, organizado em uma árvore de domínios, que são divididos entre zonas, como mostra a figura 1-5.
Figura 1-5: exemplo da divisão do DNS entre zonas.
[...]
Como dito pelo autor, os problemas do sistema distribuído são inúmeros. Os ditos “problemas conceito” categorizam tais problemas, tornando-os mais fáceis de serem entendidos.
O autor não cita qual técnica é a mais viável para resolução de problemas (solucionáveis), mesmo que isso dependa do problema enfrentado. A citação sobre o DNS com a utilização da técnica de distribuição utilizada para gerar a divisão das zonas foi uma parte interessante que me chamou atenção, pois nunca tinha pensado como seria o funcionamento real de tal funcionalidade.
Jônatas Oliveira Lopes Soares
Fonte: http://www1.fatecsp.br/aguiar/sistemasdistribuidos.htm
Ficou sem fotos pois nao foi possivel posta-las.
Clusters e supercomputação.
Segundo a IBM:
"Supercomputadores são máquinas construídas sob encomenda, com capacidade de processamento grande o suficiente para resolver complexos problemas referentes às aplicações para as quais foram desenvolvidos".
O artigo escolhido traz informações sobre clusters e supercomputadores, básicos na supercomputação moderna.
Serão explicadas as implementações de arquiteturas de supercomputação (PVP, SMP, DSM, MPP, NOW e COW), realizando uma breve comparação entre elas.
Acredito que a supercomputação esteja intimamente associada à computação distribuída.
Autor: Moisés Omêna
Click no Artigo
Postado por: Maycon Lopes (lopes.mayconÃgmail.com)
"Supercomputadores são máquinas construídas sob encomenda, com capacidade de processamento grande o suficiente para resolver complexos problemas referentes às aplicações para as quais foram desenvolvidos".
O artigo escolhido traz informações sobre clusters e supercomputadores, básicos na supercomputação moderna.
Serão explicadas as implementações de arquiteturas de supercomputação (PVP, SMP, DSM, MPP, NOW e COW), realizando uma breve comparação entre elas.
Acredito que a supercomputação esteja intimamente associada à computação distribuída.
Autor: Moisés Omêna
Click no Artigo
Postado por: Maycon Lopes (lopes.mayconÃgmail.com)
Alta Escalabilidade e Alta disponibilidade com Linux Virtual Server (LVS)
Segundo a definição do wikipedia.org:
Link para o artigo:
http://www.linux-mag.com/2003-11/clusters_01.html
Postado por: Lucas Carvalho ( lucascarvalho arroba gmail ponto com )
O Linux Virtual Server (LVS) é uma solução de balanceamento de carga avançada para sistemas Linux. É um projeto Open Source começado por Wensong Zhang em maio de 1998. A missão do projeto é construir um servidor de alto desempenho e altamente disponível para Linux usando a tecnologia de clustering, que fornece altos níveis de escalabilidade, confiabilidade e usabilidade.O artigo escolhido que foi escrito pelo Wensong Zhang e Wenzhuo Zhang em novembro de 2003, fala sobre as vantagens de usar LVS para obter alta escalabilidade e alta disponibilidade de serviços a um preço baixo.
Link para o artigo:
http://www.linux-mag.com/2003-11/clusters_01.html
Postado por: Lucas Carvalho ( lucascarvalho arroba gmail ponto com )
JSP Escalabilidade e suas características
O artigo que escolhi mostra a necessidade que desenvolvedores têm de fornecer grandes serviços com uma rapidez confortável aos seus usuários. A peça chave, para tanto, é a redimensionalidade. Tomando JSP, se nos conectarmos ao banco de dados com aplicações de múltiplas camadas, o uso de múltiplos hosts para que a carga possa ser espalhada, ou utilizar maneiras de distribuir funcionalidades por multi-arrays de máquinas de mesma configuração, são formas otimização, sabendo que ao utilizar JSP com múltiplos servidores, será necessário gerenciar sessões com múltiplos servidores. O artigo exemplifica maneiras de personalizar o equilíbrio de cargas, configurando o web Apache ou um container JSP que migre de sessão. De qualquer forma, um primeiro caminho para os criadores é a coragem.
www.javafree.org/javabb/viewtopic.jbb?t=1411
www.javafree.org/javabb/viewtopic.jbb?t=1411
Técnicas de Escalabilidade
Neste post estarei abordando a Aproximação do Algoritmo aos Dados.
Bom, como já vimos em matérias como AC e SO, maior parte do tempo de um processo e gasto com O/I.... o tempo de acesso a disco já e retardado, em um acesso em outra máquina da rede causaria um retardo imenso.
Hoje em dia os programadores, em sua maioria, não pensam em ganhar desempenho com a diminuição de O/I. Essa Técnica mostra q minimizando o uso de recurso caros (acesso a rede, disco, banco...), otimizando o código para diminuir O/I e é claro maximizando o uso dos registrado (Exp.: em C existe um modificador de variável chamada register, ele indica ao processador q a variável deve ser mantida no registrador por ser muito usada) ganhando assim com a diminuição da busca de novas instruções.
Esse técnica pode também causa algum desperdício de memória e gargalo na rede( já q recursos caros devem ser requisitados a mais cedo possível, provocando um trafego pesado na rede).Outras técnicas podem ser utilizadas para ser evitado isto.
Fonte: Otavio Pecego Coelho ( Microsoft Brasil )http://www.microsoft.com/brasil/msdn/Tecnologias/arquitetura/Escalabilidade.mspx
Postado por: Wallace Gomes ( wallace@ucam-campos.br )
Bom, como já vimos em matérias como AC e SO, maior parte do tempo de um processo e gasto com O/I.... o tempo de acesso a disco já e retardado, em um acesso em outra máquina da rede causaria um retardo imenso.
Hoje em dia os programadores, em sua maioria, não pensam em ganhar desempenho com a diminuição de O/I. Essa Técnica mostra q minimizando o uso de recurso caros (acesso a rede, disco, banco...), otimizando o código para diminuir O/I e é claro maximizando o uso dos registrado (Exp.: em C existe um modificador de variável chamada register, ele indica ao processador q a variável deve ser mantida no registrador por ser muito usada) ganhando assim com a diminuição da busca de novas instruções.
Esse técnica pode também causa algum desperdício de memória e gargalo na rede( já q recursos caros devem ser requisitados a mais cedo possível, provocando um trafego pesado na rede).Outras técnicas podem ser utilizadas para ser evitado isto.
Fonte: Otavio Pecego Coelho ( Microsoft Brasil )http://www.microsoft.com/brasil/msdn/Tecnologias/arquitetura/Escalabilidade.mspx
Postado por: Wallace Gomes ( wallace@ucam-campos.br )
Assinar:
Comentários (Atom)