O que é um Sistema Distribuído (SD)

Pela definição um Sistema Distribuído é um sistema com múltiplos componentes distribuídos por diferentes máquinas que comunicam e coordenam ações que resultam num único sistema coerente para o utilizador final.

As máquinas são parte do SD, que podem ser servidores físicos ou virtuais que tenham memória e capacidade de comunicar através de mensagens codificadas, usando para esse efeito o mesmo protocolo para ser consistente.

Os SD podem ser muito complexos e distintos uns dos outros, mas geralmente partilham três características, que são:

• Todos os componentes do sistema são executados em simultâneo;
• Não têm um relógio global, por exemplo parte do sistema pode estar em diferentes países da Europa, e de país para país a hora é diferente, logo cada máquina tem a hora do sitio onde se encontra, mas isso não é problema porque as máquinas do SD falam entre si usando mensagens.
• Todos os componentes falham de forma independente uns dos outros, ou seja, por um falhar o sistema continua a funcionar normalmente e o utilizador final não notará qualquer diferença na utilização do serviço.

Como em tudo, também num SD, temos prós e contras, começando pelos benefícios:

• Escalabilidade horizontal - Como a computação é feita de forma independente em cada nó, torna-se fácil e por norma barato adicionar nós.
• Confiabilidade - Na maioria dos casos estes tipo de sistemas são tolerantes a falhas, ou seja em caso de falha esta deve ser ocultada do utilizador, deve ter redundância suficiente, ao nível da rede, tendo vários caminhos para a mesma máquina, ao nível dos dados, tendo os mesmos dados em vários locais, ao nível dos servidor, tendo um servidor duplicado por exemplo.
• Transparência - O sistema deve ser visto pelo utilizador como um todo e não como um conjunto de componentes distribuídos.
• Transparência de acesso - O acesso a recursos locais e remotos deve ser feito usando as mesmas operações.
• Transparência de localização - Deve permitir que os recursos possam ser acedidos sem que se conheça a sua localização
• Transparência de concorrência - Deve permitir que os clientes não necessitem de ter em conta o acesso concorrente ao serviço.
• transparência de replicação - Deve permitir que os clientes de um componente não se apercebam se existe replicação de dados e se estão a usar a réplica ou o original.
• Transparência de falhas - Deve permitir que o sistema funcione na presença de falhas de hardware ou software sem que os utilizadores saibam como essa falha foi resolvida, ou sequer que ela ocorreu.
• Transparência de migração - Deve permitir que um recurso possa mudar de localização sem que isso afete a sua utilização.
• Transparência de desempenho - Deve permitir que o sistema seja reconfigurado para melhorar o seu desempenho sem que o utilizador se aperceba.
• Transparência de escalabilidade - Deve permitir que o sistema seja expandido sem que os utilizadores se apercebam.

como pode ser composto por inúmeros nós que funcionam em conjunto, o que permite não apresentar interrupções por falhar uma máquina.

• Desempenho - Estes sistemas são extremamente eficientes porque as cargas de trabalho podem ser divididas e enviadas para várias máquinas, o que pode tornar as operações mais “leves”, para cada máquina.
• Heterogeneidade - Possui diferentes tipos de rede, hardware, sistema operativo e linguagens de programação.

Contudo vamos ver agora os desafios colocados na implementação de um SD.

Arquitetura complexa, a construção e os processos de debbugging, são os principais desafios, para que um sistema distribuído seja realmente eficaz.

Para alem destes ainda há outros desafios associados, como por exemplo:

• O agendamento (scheduling) de trabalhos, o SD deve decidir que trabalhos precisam de ser executados e onde devem ser executados, os agendadores (schedulers), tem limitações, o que pode levar a termos hardware subutilizado, bem como tempos de execução imprevisíveis.
• A latência, quanto mais ampla for a distribuição do sistema, mais provável que este desafio seja colocado, para colmatar este problema normalmente quem implementa o SD tentam fazer compensações, balanceando a disponibilidade, a consistência e a latência.
• Observabilidade, juntar, processar, apresentar, e monitorizar a utilização do hardware pode ser um grande desafio.

Para que um SD funcione corretamente, tem que estar tudo interligado, os CPUs através da rede e os processos através do sistema de comunicação do SD.

Os SD podem ter vários tipos de arquiteturas entre elas, as mais comuns são:

Client-to-Server (Cliente-Servidor), em que os clientes fazem pedidos ao servidor, para consultar dados, o servidor formata os dados e exibe-os ao utilizador final, por exemplo o servidor, servidor de email da Google.

Three-Tier (Três Camadas), nesta arquitetura as informações do cliente são armazenadas numa camada intermédia em vez de serem armazenadas na camada do cliente, para simplificar a implementação da aplicação, esta arquitetura é mais comum em aplicações web.

N-Tier (Multi-Camandas), esta arquitetura é normalmente usada quando uma aplicação ou um servidor precisa encaminhar solicitações a serviços adicionais na rede, esta arquitetura consiste na separação das funções em diferentes camadas (processamento de dados, gestão de dados, apresentação) por exemplo a Azure Aplication, em que o seu sistema é dividido pelas camadas que podemos ver na figura seguinte.

Peer-to-Peer(Ponto-a-Ponto), nesta arquitetura não há máquinas adicionais a fornecer os serviços ou a gerir os recursos, em vez disso as responsabilidades são distribuídas entre as máquinas do sistema de forma uniforme, em que a mesma maquina pode num momento funcionar como cliente e noutro como servidor, um exemplo deste tipo de arquitetura é o Torrentz, em que cada utilizador funciona como cliente e como servidor não sendo assim necessário um servidor central, como em outras arquiteturas.

Agora vamos ver alguns exemplos de SD:

Serviços de Bancos Online.

Serviços de reservas de companhias aéreas.

Todos estes serviços referidos necessitam, entre outras coisas, de uma elevada disponibilidade, o que é garantido através de um SD, para que possam estar inúmeros utilizadores a utilizar o mesmo serviço, sem comprometer a capacidade de resposta ou a rapidez do sistema.

Para gerir SDs temos ferramentas que nos facilitam essa tarefa, como o Hadoop, Spark, Kafka, Hive, Rdbms, Hdfs.

Vamos falar um pouco sobre algumas destas plataformas de middleware.

A Hadoop é uma plataforma de software em java de computação distribuída virada para os clusters e processamento de grandes volumes de dados, é um projeto da apache desenvolvido por uma comunidade de desenvolvedores o Yhaoo utiliza esta plataforma na maioria dos seus negócios, é disponibilizada pela IBM e pela Amazon nas suas plataformas.

A Spark é uma framework de open-source para computação distribuída, foi desenvolvido no AMPLab da Universidade da Califórnia e posteriormente adquirido pela Apache Software Fundation. Tem uma interface para programação de clusters com paralelismo, é usado por norma para cargas de trabalho de big data.

A Kafka é uma plataforma open-source de processamento de streams desenvolvida pela Apache Software Fundation, escrita em Scala e java, tem como objetivo fornecer uma plataforma unificada, de alta capacidade e de baixa latência para tratamento de dados em tempo real.