Você está na página 1de 37

Índice

Agradecimentos ................................................................. Error! Bookmark not defined.

Dedicatórias ...................................................................... Error! Bookmark not defined.

Epígrafe ............................................................................ Error! Bookmark not defined.

Índice................................................................................................................................ i

Índice de Figuras ............................................................................................................. iii

Capítulo I – Introdução .................................................................................................... 1

1.1. Contextualização .............................................................................................. 2

1.2. Problematização ............................................................................................... 3

1.3. Perguntas de Pesquisa ..................................................................................... 4

1.4. Objectivos ......................................................................................................... 5

1.4.1. Geral ............................................................................................................ 5

1.4.2. Específicos .................................................................................................. 5

1.5. Organização do Trabalho ................................................................................. 5

Capítulo II – Metodologia ................................................................................................ 7

2.1. Classificação da pesquisa ................................................................................ 8

2.1.1. Quanto a Natureza ...................................................................................... 8

2.1.2. Quanto aos Objectivos ................................................................................ 8

2.1.3. Quanto aos os procedimentos técnicos ........................................................ 8

2.1.4. Quanto a abordagem do problema .............................................................. 8

2.2. Metodologia para desenvolvimento do trabalho teórico .................................... 9

2.3. Metodologia para desenvolvimento do trabalho Pratico ................................... 9

2.3.1. Paradigma de Programação ........................................................................ 9

2.3.2. Linguagem de Programação ....................................................................... 9

CARLOS GAZITE AJM i


2.3.3. Ambiente de Desenvolvimento Integrado (IDE)......................................... 10

2.3.4. Sistema de Gestão de Base de Dados (SGBD) ........................................ 10

2.3.5. Sistema Operativo e de Virtualização de Maquinas .................................. 10

Capítulo III – Revisão da Literatura ........................................................................... 11

3.1. Replicação ...................................................................................................... 12

3.1.1. Desafios dos Sistemas distribuídos resolvidos pela replicação ................. 12

3.1.2. Consistência como um desafio na replicação............................................ 13

3.1.2.1. Modelos de Consistência .................................................................... 13

3.1.2.1.1. Modelos de Consistência “Data-Centric” ...................................... 14

3.1.2.1.2. Modelos de Consistência “Client-Centric” ..................................... 15

3.1.3. Gerenciamento de réplicas ........................................................................ 15

3.1.3.1. Replicação e posicionamento de servidores ....................................... 16

3.1.3.2. Replicação e posicionamento de conteúdo......................................... 16

3.1.3.2.1. Réplicas permanentes .................................................................. 16

3.1.3.2.2. Réplicas iniciadas por servidores ................................................. 17

3.1.3.2.3. Réplicas iniciadas por clientes ...................................................... 17

3.1.3.2.4. Distribuição do conteúdo .............................................................. 17

3.1.3.3. Estado versus operações.................................................................... 17

3.1.4. Protocolos de recuperação de actualizações versus protocolos de envio de


actualizações ......................................................................................................... 18

3.1.5. Disponibilidade e Tolerância a Falhas ....................................................... 19

3.1.5.1. Algoritmos de Aceitação das Réplicas ................................................... 20

3.1.6. Transparência de replicação ..................................................................... 21

3.1.7. Arquitecturas de replicação de sistema distribuídos .................................. 22

3.1.7.1. Distribuição ......................................................................................... 22

CARLOS GAZITE AJM ii


3.1.7.2. Consolidação ...................................................................................... 23

3.1.7.3. Deslocamento de dados ..................................................................... 23

3.1.7.4. Workflow ............................................................................................. 24

3.1.7.5. Multi-site data sharing ......................................................................... 24

3.1.8. Tipos de replicação ................................................................................... 25

3.1.8.1. Replicação de dados........................................................................... 25

3.1.8.1.1. Tipos de replicação de dados ....................................................... 25

3.1.8.1.2. Modelos de Replicação de dados ........................................................ 26

3.2. Backup ............................................................................................................ 27

Capítulo IV – Implementação da Proposta de Solução ................................................. 28

Capítulo VI - Considerações Finais ............................................................................... 31

6.1. Conclusão ....................................................................................................... 32

Referências Bibliográficas ............................................................................................. 33

Índice de Figuras
Figura 1 - Cenário com servidor de bases de dados único ............................................. 2
Figura 2 - Exemplar da mímica da interligação entre uma agencia e o servidor de bases
de dados ......................................................................................................................... 4
Figura 3 - Modelos de Consistência .............................................................................. 14
Figura 4 - Organização geral de uma base de dados fisicamente distribuído e replicado
sobre múltiplos processos. ............................................................................................ 14
Figura 5 - Arquitectura de Distribuição .......................................................................... 22
Figura 6 - Arquitectura de Consolidação ....................................................................... 23
Figura 7 - Arquitectura de Deslocamento de dados ...................................................... 23
Figura 8 - Arquitectura de workflow ............................................................................... 24
Figura 9 - Arquitectura de Multi-site Data sharing ......................................................... 24
Figura 10 - Modelos de Replicação de dados ............................................................... 26
Figura 11 - Modelo Muti mestre .................................................................................... 26

CARLOS GAZITE AJM iii


CARLOS GAZITE AJM iv
Capítulo I - Introdução

Capítulo I – Introdução

CARLOS GAZITE AJM 1


Capítulo I - Introdução

1.1. Contextualização
Os Softwares, têm desempenhado um papel importante no dia-a-dia da população em
todo o mundo, isso devido a possibilidade facilitadora que eles trazem na realização das
actividades, dando maior eficácia e eficiência. Devido a essas e outras facilidades, o uso
de softwares torna-se cada vez mais indispensável. Primordialmente, os sistemas eram
centralizados por serem instalados e configurados em um único computador, o qual
funcionava como controlador dos recursos físicos (o hardware) e lógicos (o software)
disponíveis numa organização. E uma das dificuldades que leva ao abandono dos
sistemas centralizados é que com
Um maior número de usuários reduz a fatia de tempo (time-slice) disponível para cada
um, aumenta o número de interrupções e consumo dos recursos do sistema para tarefas
de gerenciamento. Além disso, o barramento pode causar um gargalo no sistema pela
limitação de dados que podem circular nas conexões. (Barcelar, 2013, p. 1)

E porque nem todos sistemas são de natureza centralizada, há por vezes, a necessidade
de tornar remoto o acesso a determinados recursos ou um sistema inteiro; o que faz com
que em alguns sistemas exista “[…] conjunto de computadores independentes que se
apresenta a seus usuários como um sistema único e coerente” (Tanenbaum & Steen,
2006), a este dá-se o nome de Sistema Distribuído. Em relação ao primeiro tipo
(Sistemas centralizados), este tem a vantagem de ser eficiente no compartilhamento de
recursos e da carga de trabalho, a
distribuição mais eficiente o que
permite a computação mais rápida,
a tolerância a falhas e a
capacidade de redundância.
No cenário da Figura 1 (ao lado)
tem-se um servidor de bases de
dados cujo acesso é remoto, e
possui diversas bases de dados de
diversas organizações diferentes
operando em Moçambique, uma

Figura 1 - Cenário com servidor de bases de dados único dessas possui software com a
Fonte: o Autor
Arquitectura Cliente-Servidor.
Cada um dos computadores do conjunto distribuído em todas agências é dependente da
base de dados remota. Apesar disso, pela definição acima colocada, este sistema é

CARLOS GAZITE AJM 2


Capítulo I - Introdução

distribuído. Ele possui uma dependência que faz com que a falha do servidor torna
todas agências da organização não operacionais criando assim inúmeros prejuízos
(desde os de logística aos económicos) o que faz dele não confiável. Por outro lado,
todas agências estão geograficamente distribuídas e com cada uma, tendo diversos
computadores usando o sistema o que dependendo da infra-estrutura de rede de
computadores instalada pode afectar ao desempenho primeiro do servidor e em
segundo o de cada sistema que usada os recursos deste servidor. Por tanto estes
desafios, o desempenho e a tolerância a podem ser resolvidos a partir da a replicação
dos sistemas distribuídos, o que será o centro das atenções deste trabalho. E neste, tem-
se em vista estudar o mecanismo de salvaguarda de problemas (a confiabilidade e o
desempenho) que afectam sistemas como o do cenário anterior tendo como solução a
replicação de dados. Por tanto, a meta global é demonstrar a importância do uso da
replicação em sistema distribuídos e como aspecto pratico trar-se-á uma simulação
usando máquinas virtuais interagindo em uma rede com um programa (um sistema
distribuído com arquitectura cliente-servidor) onde o foco será mostrar o ganho da
tolerância a falha usando-se a replicação.

1.2. Problematização
O grupo de recrutamento tsintsiva, possui representações em todas províncias do país,
onde que, em cada possui agencias de operações, estas que são destacadas pela
facilidade que têm na comunicação interna entre os funcionários desta organização, a
mesma, facilita muitos processo internos ao grupo, essa comunicação é obtida atreveis
do uso de uma aplicação de bate-papo que conecta cada computador de operações ao
servidor de bases de dados que esta localizada em sua sede em Maputo-cidade. Nesta
aplicação, os funcionários podem conversar de forma partícula, podem conversar em
um grupo geral ou da sua Província, podendo também trocar documentos e outros
ficheiros. Um exemplar da interligação pode ser visto na Figura 2 (nesta figura traz-se
apenas aspectos relevantes a nossa análise, aspectos como a representação do
servidor de DHCP, da firewall e outros é descartada). Nesta rede, existem períodos em
que:

CARLOS GAZITE AJM 3


Capítulo I - Introdução

1. o sistema de bate-papo fica indisponível devido ao uso excecivo dos recurso da rede
estes que fazem com que a largura;
2. o sistema de bate-papo fica indisponível devido a queda do servidor de bases de
dados quando este recebe actualizações;
Quando o sistema fica indisponível, a comunicação torna-se deficiente, fazendo que o
trabalho seja oneroso.

Figura 2 - Exemplar da mímica da interligação entre uma agência e o servidor de bases de dados

Fonte: O autor
Segundo Tanembaum e Steen (2006, p. 165) os problemas de confiabilidade e
desempenho são os dois principais problemas para a replicação de sistemas
distribuídos, não só, pode também existir a necessidade de replicar sistemas quando as
organizações pretender ampliar-se geograficamente (o que no nosso problema não foi
tido em conta no momento a da ampliação geográfica). E para Coulouris et al (2007, p.
521) a replicação fornecer um melhor desempenho, alta disponibilidade e tolerância a
falhas. Pelo que ambos entram em convergência sobre o assunto neste aspecto de
melhorias trazidas pela replicação. Assim, com este problema trar-se-á propostas de
solução sob a perspectiva de como melhorar a confiabilidade e desempenho nos
sistemas geograficamente distribuídos?

1.3. Perguntas de Pesquisa


o Como é garantida a consistência e integridade de dados durante a
replicação?

CARLOS GAZITE AJM 4


Capítulo I - Introdução

o Como é resolvido o problema de desempenho em sistemas distribuídos


usando a replicação?
o Como é garantida a tolerância a falha em sistemas distribuídos usando a
replicação?

1.4. Objectivos
1.4.1. Geral
 Descrever os conceitos da replicação de sistema distribuídos

1.4.2. Específicos
 Descrever o princípio de funcionamento dos tipos de replicação de dados
 Discriminar a replicação de dados de backup
 Testar um sistema de chat (bate-papo) em um ambiente com replicação de dados

1.5. Organização do Trabalho


Este trabalho está dividido em conjunto de 6 capítulos. Que fora ao presente, o resto dele
está organizado da seguinte forma:

Capítulo II – Metodologia
Neste capítulo, serão mostrados os procedimentos usados para a conspecção do
corrente trabalho e a classificação do mesmo.

Capítulo III – Revisão da Literatura


Neste capítulo, serão trazidos os conceitos teóricos que serão abordados durante o
trabalho, também trar-se-á os conhecimentos produzidos em outros trabalhos e manuais
de pesquisas.

Capítulo VI – Implementação da Proposta de Solução


Neste capítulo, serão usados os conceitos discutidos no Capítulo III – Revisão da
Literatura e mostradas as propostas de solução ao cenário colocado na secção de

CARLOS GAZITE AJM 5


Capítulo I - Introdução

Problematização, onde depois de uma discussão, será implementada a melhor proposta


(todos procedimentos serão mostrados).

Capítulo V – Resultados Obtidos e Discussão


Neste capítulo, será observada a implementação feita no Capítulo VI – Implementação
da Proposta de Solução e discutidos os resultados, sendo estes confrontados com os
conceitos discutidos no Capítulo III – Revisão da Literatura.

Capítulo VI - Considerações Finais


Mostra as conclusões do trabalho e apresenta sugestões de continuação do mesmo.

CARLOS GAZITE AJM 6


Capítulo II - Metodologia

Capítulo II – Metodologia

CARLOS GAZITE AJM 7


Capítulo II - Metodologia

2.1. Classificação da pesquisa


2.1.1. Quanto a Natureza
Quando a natureza, esta é uma pesquisa aplicada, pois define-se como sendo aplicada
aquela que produz “conhecimentos para aplicação prática dirigidos à solução de
problemas específicos. Envolve verdades e interesses locais” (Prodanov & Freitas, 2013,
p. 126) .

2.1.2. Quanto aos Objectivos


Quanto à pesquisa, esta é uma exploratória, porque segundo Prodanov e Freitas (2013,
p. 51) “quando a pesquisa se encontra na fase preliminar, tem como finalidade proporcionar mais
informações sobre o assunto que vamos investigar, possibilitando sua definição e seu delineamento
[…]”.

2.1.3. Quanto aos os procedimentos técnicos


Quando aos procedimentos, esta é uma estudo de caso, pois segundo Prodanov e
Freitas (2013, p. 128) este tipo é usado quando quere-se responder “[…] questões do
tipo “como” e “por que”, quando o pesquisador tem pouco controle sobre os eventos e
quando o foco se encontra em fenómenos contemporâneos inseridos em algum contexto
da vida real”.

2.1.4. Quanto a abordagem do problema


Quando a abordagem do problema, esta é uma pesquisa qualitativa, pois segundo
Prodanov e Freitas (2013, p. 128) considera-se que “o ambiente natural é fonte directa
para colecta de dados, interpretação de fenómenos e atribuição de significados”.

CARLOS GAZITE AJM 8


Capítulo II - Metodologia

2.2. Metodologia para desenvolvimento do trabalho teórico


Assim de modo a alcançar-se os objectivos do trabalho, em conformidade com as
normas da Faculdade de Engenharia - Universidade Eduardo Mondlane a metodologia
de realização do trabalho consistiu em:
• Pesquisa e revisão bibliográfica;
• Cinco consultas ao supervisor das quais duas foram ocasionais;
• Consulta a páginas credíveis da Internet e outros documentos relevantes a esta
pesquisa;
• Revisão de trabalhos que abordam a mesma temática semestres passados desta
disciplina;
• Para fins de modelagem, usou-se o MS Visio e ConceptDraw.

2.3. Metodologia para desenvolvimento do trabalho pratico


Para implementação do sistema de chat (bate-papo) por testar foi utilizada a linguagem
de programação Java, no Ambiente Integrado de Desenvolvimento (IDE) IntelliJ IDEA
20181.3, Sistema de Gestão de Base de Dados MariaDB, hospedado no Ubuntu Server
18.04 LTS numa máquina virtualizada no Oracle VM Virtual Box ponde foi instalado um
adaptador de rede para que o computador físico possa comunicar com a(s) máquina(s)
virtual(is).

2.3.1. Paradigma de Programação


Como paradigma de programação, foi utilizada a Orientação à Objectos (OO) pela
proximidade que ela proporciona entre conceitos de modelação e entidades do mundo
real, destacando-se assim como vantagem de sua utilização a melhoria da captura e
validação de requisitos além de aproximar o “espaço do problema” e o “espaço da
solução”.

2.3.2. Linguagem de Programação


A linguagem de programação utilizada é o Java por ter uma sintaxe simples, ser
completamente orientada à objectos e compatível com qualquer plataforma (Sistema

CARLOS GAZITE AJM 9


Capítulo II - Metodologia

Operativo); constituiu também critério de sua selecção a rica documentação que possui
e a vasta comunidade de desenvolvedores activos.

2.3.3. Ambiente de Desenvolvimento Integrado (IDE)


O IDE utilizado é o IntelliJ IDEA 2018.1.3, foi devido à sua facilidade de integração com
vários Sistemas de Gestão de Bases de Dados e os vários recursos de geração de
interface gráfica e código o tornam muito flexível e apropriado tendo em conta a
linguagem de programação e plataforma definidos e ainda, é desenvolvido e mantido na
linguagem Java.

2.3.4. Sistema de Gestão de Base de Dados (SGBD)


O SGBD utilizado é o MariaDB por ser altamente compatível com linguagens de
programação como Java, php, Ruby e outras; possui alto desempenho e estabilidade e
é pouco exigente quanto a recursos de hardware e é free Open Source.

2.3.5. Sistema Operativo e de Virtualização de Máquinas


O sistema operativo utilizado é o Ubuntu Server 18.04 LTS, por ser de uso gratuito e por
possuir uma larga comunidade de utilizadores e documentação gratuita. O sistema
Virtualização de Máquinas usado é o Oracle VM Virtual Box, por ser de uso gratuito e
por possuir uma larga comunidade de utilizadores.

CARLOS GAZITE AJM 10


Capítulo III – Revisão da Literatura

Capítulo III – Revisão da Literatura

CARLOS GAZITE AJM 11


Capítulo III – Revisão da Literatura

3.1. Replicação
Como mencionado na secção de Problematização, Segundo Tanembaum e Steen (2006,
p. 165) os problemas de confiabilidade e desempenho são os dois principais problemas
para a replicação de sistemas distribuídos, e para Coulouris et al (2007, p. 521) a
replicação fornecer um melhor desempenho, alta disponibilidade e tolerância a falhas.
Pelo que ambos entram em convergência sobre o assunto neste aspecto de melhorias
trazidas pela replicação. Já se mencionou antes, dezoito vez a palavra replicação ainda
não foi dito o que é ou diz-se ser.
Segundo Coulouris et al (2007, p. 521) replicação é “uma técnica para melhorar
serviços” cujas motivações do seu são de “melhorar o de um serviço, aumentar sua
disponibilidade ou torná-lo tolerante a falhas”. E Tanembaum & Steen (2006, p. 165)
converge com essas motivações.
Assim, se um sistema de arquivos for replicado, pode ser possível continuar trabalhando
após a queda de uma réplica simplesmente com comutação para uma das outras
réplicas. “Manter várias réplicas permite melhor protecção contra dados corrompidos”
(Tanenbaum & Steen, 2006).
Realmente, a replicação traz bons frutos, a fiabilidade e o desempenho, mas infelizmente
traz com ela alguns problemas quando os dados são replicados. Um dos quais é a
consistência, que segundo Tanembaum e Steen (2006) “Um conjunto de cópias é
considerado consistente quando as cópias são iguais, ou seja, à qualquer operação de
leitura efectuada em qualquer uma das cópias o resultado deve ser o mesmo”, diz-se
tambem que é
essencialmente, um contracto entre diferentes processos e os dispositivos de armazenamento
de dados, garantindo a coerência e a certeza dos dados dadas determinadas regras que
precisam ser seguidas. (Omicini, 2012).

3.1.1. Desafios dos Sistemas distribuídos resolvidos pela replicação


A replicação é o segredo da eficácia dos sistemas distribuídos, pois ela resolve os
seguintes desafios dos sistemas distribuídos:
 Disponibilidade;
réplicas propiciam o aumento da disponibilidade do sistema como consequência
da confiabilidade.

CARLOS GAZITE AJM 12


Capítulo III – Revisão da Literatura

 Confiabilidade;
réplicas garantem que não haverá um único ponto de falha no sistema.
 Tolerância a falhas;
em caso de falha, o usuário pode ser movido para outra réplica sem notar que a
falha ocorreu.
 Escalabilidade;
 Desempenho.
balanceamento de carga, uso de “cache”, escalabilidade geográfica, aumento do
sistema.
Neste trabalho, serão resolvidos discutidos apenas dois dos acima listados, a
confiabilidade e o desempenho.

3.1.2. Consistência como um desafio na replicação


Quando uma operação de actualização é efectuada numa das cópias, essa deve ser
propagada para todas as cópias antes que ocorra uma operação subsequente, sem
importar qual cópia essa operação for iniciada. A ideia fundamental é que uma
actualização seja realizada em todas as cópias como uma operação atómica, ou
transacção. Infelizmente, implementar atomicidade envolvendo um grande número de
réplicas que podem estar amplamente difíceis quando também é exigido que as
operações sejam concluídas rapidamente.
As dificuldades surgem do facto de que precisamos sincronizar as réplicas. Desta forma,
o que determina a viabilidade da replicação é como e quando essas modificações
precisam ser executadas.

3.1.2.1. Modelos de Consistência


“Um modelo de consistência é, em essência, um contracto entre processos e o deposito
de dados” (Tanenbaum & Steen, 2006, p. 167). Ele diz que, se os processos
concordarem em obedecer a certas regras, o deposito promete funcionar de maneira
correcta. Os modelos de consistencia podem ser resumidos atraveis da Figura 3 abaixo.

CARLOS GAZITE AJM 13


Capítulo III – Revisão da Literatura

 Consistência Contínua
 Modelos de Consistência “Data - Centric” 
  Ordenação Consistente de Operações


Modelo Consistência 
 Consistência Eventual
 
Modelos de Consistência “Client - Centric” Leituras Monotônicas
  Escritas Monotônicas
 
Figura 3 - Modelos de Consistência

Fonte: adaptado do texto de (Faina, 2018)

3.1.2.1.1. Modelos de Consistência “Data-Centric”


Os modelos de consistência são analisados tradicionalmente por meio de operações de
leitura/escrita sobre dados compartilhados (memória ou base de dados compartilhado).
a) Base de Dados - pode se encontrar fisicamente distribuído em diferentes
máquinas e com as seguintes características:
 cada processo pode aceder a dados do repositório através de uma cópia
local de todo o conteúdo do repositório;
 operações de escrita são propagadas para todas as cópias;
 operação de dados é classificada como escrita quando altera o dado,
diferentemente da operação de leitura.

Figura 4 - Organização geral de uma base de dados fisicamente distribuído e replicado


sobre múltiplos processos.
Autor: (Tanenbaum & Steen, 2006, p. 167)

CARLOS GAZITE AJM 14


Capítulo III – Revisão da Literatura

3.1.2.1.2. Modelos de Consistência “Client - Centric”


Os modelos de consistência descritos anteriormente têm por objectivo prover uma
consistência global do repositório de dados, ou seja, a suposição é a de processos
concorrentes podem simultaneamente actualizar o repositório e, assim, é necessária
consistência face a concorrência entre os mesmos.
Exemplo: em modelos baseados em objectos, o repositório garante que uma cópia actual
do objecto será fornecida ao processo chamador, que durante a chamada, nenhum outro
processo pode interferir, ou seja, acesso exclusivo é concedido ao processo chamador,
ou seja, manipular operações concorrentes em dados com- partilhados enquanto se
mantém a consistência sequencial é fundamental em sistemas distribuídos.
Por razões de desempenho, consistência sequencial pode ser garantida somente com o
uso de mecanismos de sincronização tais como transacções e “locks”.
Nesta seção discutiremos uma classe especial de “base de dados” distribuídos
caracterizados pela ausência de actualizações simultâneas ou quando acontecem
podem ser resolvidas facilmente. Tais modelos de consistência são denominados
“eventualmente consistentes” e de modo geral escondem as inconsistências.

3.1.3. Gerenciamento de réplicas


Há duas questões fundamentais para qualquer sistema distribuído que suporta
replicação, que são:
 Onde ser posicionada a replica?
 Quando deve ser posicionada?
 Por quem as réplicas devem ser posicionadas? e,
 Quais mecanismos usar para manter as réplicas consistentes?
Segundo Tanenbaum & Steen (2006) o problema de posicionamento deve ser dividido
em dois, a:
• Replicação e posicionamento de servidores; e
• a Replicação e posicionamento de conteúdo.

CARLOS GAZITE AJM 15


Capítulo III – Revisão da Literatura

3.1.3.1. Replicação e posicionamento de servidores


O posicionamento de servidores de réplicas está relacionado à identificação de melhores
localizações geográfica para colocar um servidor que pode hospedar um repositório de
dados. Vários métodos de optimização são propostos para o cálculo do melhor
posicionamento, envolvendo aspectos como: latência, largura de banda, distância entre
os clientes e os servidores, entre outros. Um desses modelos é o proposto por
Radoslavov et al. (2001) que ignora a posição dos clientes e considerando apenas que
a topologia da Internet é formada o pelos Sistemas Autónomos (AS) . Nesta proposta,
coloca-se em primeiro lugar o maior AS e coloca-se um servidor no roteador que tenha
o maior número de interfaces de rede. Esse algoritmo é repetido com o segundo maior
AS, e assim por diante.

3.1.3.2. Replicação e posicionamento de conteúdo


O posicionamento de conteúdo refere-se a achar os melhores servidores para colocar o
conteúdo, procurando assim o posicionamento óptimo de um único item de dados.
Segundo Tanenbaum & Steen (2006) quando se trata de replicação e posicionamento
de conteúdo, podem-se distinguir três tipos de réplicas organizadas logicamente:
 Réplicas permanentes;
 Réplicas iniciadas por servidores; e
 Réplicas iniciadas por clientes

3.1.3.2.1. Réplicas permanentes


São consideradas como o conjunto inicial de réplicas que constituem um depósito e
dados. Em muitos casos, o número de réplicas é pequeno. Casos concretos de uso de
réplicas permanentes verificam-se nos sites Web e em bases de dados distribuídas. No
caso dos sites Web os arquivos que os constituem ou as cópias dos próprios sites são
replicados por vários servidores. Para o caso de bases de dados, estes são distribuídos
e replicados por uma quantidade de servidores que, juntos, formam um cluster de
servidores que costuma ser denominado arquitectura compartilhada-nada, ressaltando
que nem discos nem memória principal são compartilhados por processadores. Como

CARLOS GAZITE AJM 16


Capítulo III – Revisão da Literatura

alternativa, uma base de dados é distribuída e possivelmente replicada por uma


quantidade de sites dispersos geograficamente.

3.1.3.2.2. Réplicas iniciadas por servidores


Ao contrário das réplicas permanentes, as réplicas iniciadas por servidores são cópias
de um depósito de dados que existem para aprimorar desempenho e que são criadas
por iniciativa do (proprietário do) depósito de dados. Os servidores não têm dificuldade
de manipular as requisições locais, porém, pode-se dar o caso de receber requisições
de locais geograficamente distantes. Neste último caso, convém instalar réplicas
temporárias nas regiões de onde as requisições estão vindo. São criados também
algoritmos que fazer essa replicação de arquivos de forma dinâmica de assegurando um
melhor desempenho.

3.1.3.2.3. Réplicas iniciadas por clientes


As réplicas iniciadas por cliente são mais conhecidas como caches (de cliente), que são
recursos de armazenamento local usados por clientes para armazenar temporariamente
cópias dos dados por eles requisitados recentemente, de forma a melhorar o tempo de
acesso aos dados. A cache normalmente actua como intermediário entre o cliente e o
depósito de dados. Desta forma, se a maioria das operações envolve somente leitura de
dados, o desempenho pode ser melhorado com a permissão de que o cliente armazene
dados requisitados em uma cache próxima. A cache pode estar localizada na máquina
cliente ou em uma máquina separada na mesma rede local do cliente.

3.1.3.2.4. Distribuição do conteúdo


O gerenciamento de réplicas também trata de propagação de conteúdo (actualizado)
para os servidores de réplicas relevantes.

3.1.3.3. Estado versus operações


Uma importante questão de projecto refere-se àquilo que deve ser propagado, havendo
tês possibilidades (Tanenbaum & Steen, 2006):
 Propagação de notificações de actualização;

CARLOS GAZITE AJM 17


Capítulo III – Revisão da Literatura

 Transferência de dados de uma cópia para a outra;


 Propagação da operação e actualização para outras cópias.
A propagação de notificações é feita por protocolos de invalidação, cuja operação é de
informar às outras cópias sobe a ocorrência de actualização, tal que estas últimas
considerem os dados actualizados inválidos. A principal vantagem do uso desta técnica
é de usar pouca largura de banda de rede e funcionam melhor quando há muitas
operações de actualização em comparação com as de leitura.
A transferência de dados modificados é útil quando a razão leitura/escrita é
relativamente alta. Também é possível, ao invés de transferir dados modificados, registar
as alterações e transferir somente esses registos para poupar a largura de banda.
Ademais, transferências costumam ser agregadas no sentido de que várias modificações
são empacotadas em uma única mensagem, o que poupa a sobrecarga de comunicação.
A terceira abordagem consiste em não transferir absolutamente as modificações
de dados, mas informar a cada réplica qual operação de actualização ela deve realizar
(e somente enviar os valores de parâmetros de que essas operações necessitam). O
principal benefício desta abordagem é que as actualizações muitas vezes podem ser
propagadas com custos mínimos de largura de banda, desde que o tamanho dos
parâmetros associados com uma operação seja relativamente pequeno. Além do mais,
as operações podem ser de complexidade arbitrária, o que pode permitir mais melhorias
na manutenção a consistência das réplicas. Por outro lado, talvez seja preciso mais
capacidade de processamento por cada réplica, em especial nos casos em que as
operações são relativamente complexas.

3.1.4. Protocolos de recuperação de actualizações versus protocolos de


envio de actualizações
Uma outra questão de projecto é se as actualizações são recuperadas ou enviadas. Em
uma abordagem baseada em envio, denominada protocolo de baseado em servidor, as
actualizações são propagadas para outras réplicas sem que estas tenham solicitado
essas actualizações. Esta abordagem costuma ser usada entre réplicas permanentes e
iniciadas por servidor, mas também podem ser usadas para enviar actualizações a
caches de clientes. Protocolos baseados em servidor são muito aplicados quando a

CARLOS GAZITE AJM 18


Capítulo III – Revisão da Literatura

razão leitura/actualização é alta as réplicas precisam manter um grau de consistência


relativamente alto.
Em uma abordagem baseada em recuperação de actualizações, um servidor ou
cliente requisita que um outro servidor lhe envie quaisquer actualizações que ele tiver no
momento em questão. Protocolos baseados em recuperação de actualização, também
denominados protocolos baseados no cliente, costumam ser usados por caches de
clientes. Esta abordagem é eficiente quando a razão leitura/actualização é relativamente
baixa e, em situações em que as caches são raramente compartilhadas. A principal
desvantagem de uma estratégia baseada em recuperação em comparação co uma
abordagem baseada em envio é que o tempo de resposta aumenta no caso de uma
ausência de cache.

3.1.5. Disponibilidade e Tolerância a Falhas


A disponibilidade dos servidores é sempre desejável, mas em muitos domínios de
aplicação é crítica. A replicação é uma técnica útil para melhorar a disponibilidade de um
sistema, aumentando a proporção de tempo em que este opera correctamente com
tempos de resposta razoáveis. Ou seja, replicação é uma forma de contrariar os efeitos
dos tipos de falhas que reduzem a disponibilidade de um sistema. Se os dados de que
depende um serviço forem distribuídos por vários servidores com probabilidades
independentes de falhar, então o serviço estará sempre disponível enquanto for possível
aos clientes dirigir-se a um servidor alternativo sempre que o servidor habitual falhar. A
disponibilidade que é possível conseguir irá depender do número de réplicas utilizado e
da probabilidade de falha (independente) de cada réplica/servidor. Se p é a probabilidade
de um servidor falhar, então a probabilidade de todos terem falhado será 𝑝𝑝𝑛𝑛 e a
disponibilidade: 1 − 𝑝𝑝𝑛𝑛 .
Um sistema tolerante a falhas é um sistema que produz resultados correctos na presença
das mesmas. Ou, em alternativa, não produz resultados. A replicação de dados e de
funcionalidade por múltiplos dispositivos consiste em aplicar o mesmo princípio de
redundância para conseguir tornar um sistema distribuído tolerante a uma certa classe
de falhas.

CARLOS GAZITE AJM 19


Capítulo III – Revisão da Literatura

3.1.5.1. Algoritmos de Aceitação das Réplicas


Thomas descreve o algoritmo no qual os servidores armazenando as cópias de um
arquivo replicado votam na aceitação ou não de cada requisição de alteração no arquivo.
Para uma requisição ser aceita e aplicada em todas as cópias, apenas a maioria dos
servidores precisam aprová-la. Cada arquivo tem um campo de tempo para mostrar o
instante da actualização mais recente. Quando um cliente requisita a leitura de um
arquivo, o servidor encarregado de atender a esta requisição verifica a versão da cópia
que ele possui daquele arquivo e a localização das outras cópias do arquivo. O servidor
então se comunica com os outros servidores que armazenam cópias do arquivo,
comparando a versão da sua cópia com a versão das cópias dos outros. Quando um
servidor verifica que sua cópia tem a mesma versão do servidor que fez a pergunta,
então, ele vota a favor da versão, senão, vota contra. Para que a versão seja considerada
a versão corrente do arquivo, basta que o servidor inicial consiga o (número de
servidores/2) +1 votos a favor da sua versão, neste caso, ele permite que cliente faça a
leitura com sucesso e garantia de consistência.
Quando um cliente requisita a actualização de um arquivo, o servidor encarregado de
atender a esta requisição verifica a versão da cópia que o cliente possui é mesma da
que ele possui, se não for veta a actualização, o servidor então verifica a localização das
outras cópias do arquivo.

Gifford desenvolveu um esquema de replicação de arquivos no qual um número de votos


são assinalados para cada representativo em um file suite. Um voto pode ser
considerado com um peso relacionado a preferência de se usar um determinado
representativo. O número de votos alocados para cada representativo é gravado na
definição do file suite.
Cada operação de leitura deve primeiramente obter um quorum de leitura de r votos
antes de proceder a leitura de algum representativo corrente e cada operação de escrita
deve obter um quorum de escrita de w votos antes de proceder a actualização dos
arquivos.

CARLOS GAZITE AJM 20


Capítulo III – Revisão da Literatura

3.1.6. Transparência de replicação


A transparência é uma característica fundamental em um Sistema Distribuído, seja ela
qual for. Com a introdução da técnica de replicação de arquivos num Sistema Distribuído,
surge a necessidade de mais um tipo de transparência, a transparência de replicação.
A transparência de replicação permiti que o utilizador do sistema e suas aplicações
utilizem seus arquivos sem a necessidade de se saber se eles são replicados ou não e
onde suas réplicas estão localizadas, isto é, para o utilizador seus arquivos só tem uma
cópia localizada no servidor de arquivos do sistema e as chamadas de sistema utilizadas
para aceder o arquivo são as mesmas.
A replicação de arquivos é uma técnica importante na implementação e
configuração de serviços de dados compartilhados em um Sistema Distribuído. A
utilização desta técnica constitui uma estratégia que vem garantir aos sistemas
distribuídos melhor fiabilidade, maior disponibilidade e tolerância a falhas, melhor
balanceamento de carga e maior escalabilidade. Um dos principais desafios da
replicação é manter as réplicas consistentes à cada actualização que é efectuada em
cada uma delas, o que exige que sejam criados mecanismos de sincronização entre
essas réplicas. Vários mecanismos de gerenciamento de réplicas foram adoptados para
resolver esta questão. Estes mecanismos relacionam vários aspectos como o
posicionamento dos servidores, alocação de conteúdos nesses servidores e técnicas de
propagação das actualizações sobre as réplicas. A escolha destes mecanismos não é
linear, pois é dependente dos requisitos e complexidade de cada sistema distribuído. O
posicionamento dos servidores está relacionado com a identificação dos melhores locais
para instalar os servidores, o posicionamento de conteúdo relacionado com a
identificação dos servidores onde alocar os dados e a propagação de actualizações
relacionada em “como”, “o quê” e “quando” actualizar. A razão entre as operações de
leitura e actualização também se apresenta como um forte indicador para a decisão do
mecanismo de gerenciamento de réplicas a usar.
A replicação é largamente aplicada em sistemas de dados compartilhados, tais como:
sistemas de arquivos distribuídos e bases de dados distribuídas.
Nos sistemas de arquivos distribuídos e bases de dados, ainda que os ficheiros se
encontrem fisicamente distribuídos por vários servidores numa rede, os clientes podem

CARLOS GAZITE AJM 21


Capítulo III – Revisão da Literatura

aceder aos dados de forma transparente. Nos sistemas de arquivos distribuídos caches
de clientes são usadas para garantir a disponibilidade e bom desempenho, e mantém
um a semântica de actualização de arquivos com cópia única e toleram e se recuperam
de falhas.

3.1.7. Arquitecturas de replicação de sistema distribuídos


Existem diversas arquitecturas, quais as mais comuns são:
 Distribuição
 Consolidação
 Deslocamento de dados
 Workflow
 Multi-site data sharing

3.1.7.1. Distribuição

Figura 5 - Arquitectura de Distribuição

Fonte: o Autor
Nesta arquitectura, existe uma entidade central que faz a gestão de todos os dados e
disponibiliza à replicas apenas para leitura.

CARLOS GAZITE AJM 22


Capítulo III – Revisão da Literatura

3.1.7.2. Consolidação

Figura 6 - Arquitectura de Consolidação

Fonte: o Autor
Nesta arquitectura, a informação é gerida de forma central, no entanto, as réplicas só
acedem à informação que lhes diz respeito.

3.1.7.3. Deslocamento de dados

Figura 7 - Arquitectura de Deslocamento de dados

Fonte: o Autor
Nesta arquitectura, a informação é partilhada entre um componente original que aplica o
conceito de transacções e uma réplica que serve apenas para leitura para evitar conflitos.

CARLOS GAZITE AJM 23


Capítulo III – Revisão da Literatura

3.1.7.4. Workflow

Figura 8 - Arquitectura de workflow

Fonte: o Autor
Um modelo de workflow ilustra o conceito de exclusão dinâmica de propriedade
passando a propriedade dos dados da localização do base de dados para a localização
o base de dados dentro de um ambiente replicado. O ambiente de fluxo de trabalho de
replicação é extremamente tolerante a falhas, permitindo diferentes funções ao longo de
um fluxo para proceder de forma independente no caso de falha em locais dedicados a
outras funções.
3.1.7.5. Multi-site data sharing

Figura 9 - Arquitectura de Multi-site Data sharing

Fonte: O autor
Nesta arquitectura, a informação é partilhada entre um componente original que aplica o
conceito de transacções e uma réplica que serve apenas para leitura para evitar conflitos.

CARLOS GAZITE AJM 24


Capítulo III – Revisão da Literatura

3.1.8. Tipos de replicação


Existem várias abordagens na classificação dos tipos de replicação que seguem abaixo:
 Quanto à categoria:
Replicação de dados
Replicação de processos
Replicação de objectos
Replicação de mensagens

 Quanto ao estado de actividade e hierarquia:


Replicação activa
Replicação semi-activa
Replicação passiva

3.1.8.1. Replicação de dados


Ikematu (2005) citado por Ferreira et al (2018, p. 2), diz que “o objectivo de um
mecanismo de replicação de dados é permitir a manutenção de várias cópias idênticas
de um mesmo dado em vários sistemas gerenciadores de base de dados (SGBD)”
3.1.8.1.1. Tipos de replicação de dados
 Assíncrona
Quando um BD é alterado, a alteração nos outros bases de dados será feita em uma
transição separada levando algum tempo (segundos, minutos, horas até dias) para
concluir. Esse tipo de replicação é utilizado quando não há necessidade dos dados
serem actualizado em tempo real e quando os conflitos entre transacções não
acontecem com muita frequência.
Algumas vantagens:
Baixo custo de comunicação, Aumento do desempenho das aplicações, Menor
concorrência, Maior disponibilidade.

 Síncrona
Quando um base de dados é alterado, a alteração nos outros bases de dados é
feita instantaneamente.

CARLOS GAZITE AJM 25


Capítulo III – Revisão da Literatura

Exemplos de sistemas que utilizam replicação síncrona: sistema de aviação, bancário,


comércio electrónico e militar.

3.1.8.1.2. Modelos de Replicação de dados


Os modelos de replicação de dados podem ser resumidos pela
 Modelo Muti mestre
Modelo de Replicação
 Modelo Mestre / Escravo
Figura 10 - Modelos de Replicação de dados

 Modelo Muti mestre

Figura 11 - Modelo Muti mestre

Vários sites gerenciam os objectos replicados de base de dados. Aplicativos actualizam


e as tabelas replicadas em qualquer site que pertença ao grupo de bases de dados.
Servidores têm um papel importante, porque convergem dados automaticamente todas
as replicas de tabelas, assim, garantindo consistência global e integridade de dados.
 Modelo Mestre / Escravo

Figura 12 -Modelo Mestre-Escravo

Fonte: O autor

CARLOS GAZITE AJM 26


Capítulo III – Revisão da Literatura

Apenas a base mestre recebe actualizações enquanto na base só é permitida a


leitura.

3.2. Backup
Backup refere-se ao armazenamento em um dispositivo de armazenamento virtual ou
físico, diferente do dispositivo onde encontram-se os dados de origem. Formalmente é
definida como
uma cópia de segurança dos dados armazenados no sistema de informação da instituição ou
dos dados de uso pessoal. Este backup é fundamental para qualquer sistema de informação
ou pessoa, pois ele é a garantia da restauração dos dados caso haja uma pane nos
equipamentos da instituição ou pessoa. (INNARELLI, 2003, p. 24)
Para o SANT’ANA (2004, p. 14) significa protecção e segurança de qualquer tipo de
informação dada como importante para uma empresa, seja na forma impressa ou digital,
independentemente da área de actuação sendo um recurso de extrema importância.

CARLOS GAZITE AJM 27


Capítulo IV – Implementação da Proposta de Solução

Capítulo IV – Implementação da Proposta de Solução

CARLOS GAZITE AJM 28


Capítulo IV – Implementação da Proposta de Solução

Figura 13 -Proposta de Solução

Fonte: o autor
Para a resolução do problema descrito na Problematização sistema passará a contar
com replicas regionais, onde que os aplicativos actualizam e as tabelas replicadas em
qualquer base dados que pertença ao grupo de bases de dados. Servidores têm um
papel importante, porque convergem dados automaticamente todas as replicas de
tabelas, assim, garantindo consistência global e integridade de dados.

4.1. Configuração
Editar o ficheiro /etc/mysql/my.cnf ou /etc/mysql/mysql.conf.d/mysqld.cnf
server_id = 1 [2]
log_bin = /var/log/mysql/mysql-bin.log
log_bin_index = /var/log/mysql/mysql-bin.log.index
relay_log = /var/log/mysql/mysql-relay-bin
relay_log_index = /var/log/mysql/mysql-relay-bin.index
expire_logs_days = 10

CARLOS GAZITE AJM 29


Capítulo IV – Implementação da Proposta de Solução

max_binlog_size = 100M
log_slave_updates = 1
auto-increment-increment = 2
auto-increment-offset = 1
bind-address = x.x.x.x (ip de do servidor mestre)
sudo service mysql restart

CHANGE MASTER TO
MASTER_HOST='192.168.2.3',
MASTER_USER='replication',
MASTER_PASSWORD='1234567',
MASTER_LOG_FILE='mysql-bin.000008',
MASTER_LOG_POS=154;

O código da aplicação feita e o das Máquinas era encontrado em


http://bit.ly/Matlule_SD

CARLOS GAZITE AJM 30


Capítulo VI - Considerações Finais

Capítulo V - Considerações Finais

CARLOS GAZITE AJM 31


Capítulo VI - Considerações Finais

5.1. Conclusão
Existem dois tipos de replicação de dados, a que quando há uma base de dados a ser
alterada, a alteração será feita em uma transição separada levando algum tempo
(segundos, minutos, horas até dias) para concluir noutras bases de dados. Esse tipo de
replicação é utilizado quando não há necessidade de os dados serem actualizados em
tempo real e quando os conflitos entre transacções não acontecem com muita
frequência; a essa dá-se o nome de assíncrona. E a segunda que possui o nome de síncrona
que quando uma base de dados é alterada, a alteração é aplicada instantaneamente noutras.
Em quanto que a replicação é uma técnica para melhoria serviços, a o backup
uma cópia de segurança dos dados armazenados no sistema de informação da
instituição ou dos dados de uso pessoal, na replicação cria-se também uma copia como
em backups, porém, com a motivação de melhorar o de um serviço, aumentar sua
disponibilidade ou torná-lo tolerante a falhas, enquanto que no backup a motivação é a
garantia da restauração dos dados. Não só, sempre que se faz a replicação de sistemas,
todas replicas permanecem em uso (operação) “constante”, sendo que os backups
podem ser feitos e conservados esperando a ocorrência de uma catástrofe.
Do teste feito podou-se perceber que realmente fazendo se a replicação consegue-se
garantir os aspectos discutidos na secção de Desafios dos Sistemas distribuídos resolvidos
pela replicação, que no sistema em estudo com as réplicas propiciam o aumento da
disponibilidade do sistema como consequência da confiabilidade – disponibilidade; com as
réplicas garantiu-se que não haverá um único ponto de falha no sistema – confiabilidade;
e em caso de falha, os usuário podem ser movido para outra réplica sem notar que a
falha ocorreu - tolerância a falhas.

CARLOS GAZITE AJM 32


Capítulo VI - Considerações Finais

Referências Bibliográficas

Barcelar, R. R. (01 de Setembro de 2013). Fundamentos de Sistemas Distribuídos.


Brazil.
Coulouris, G., Dollimore, J., & Kindberg, T. (2007). Sistemas Distribuidos Conceitos e
Projeto. Bookman.
Faina, L. F. (18 de Maio de 2018). Cap. 07 – Consistência e Replicação. Obtido de
www.facom.ufu.br/~faina/BCC_Crs/GSI028-2014-1S/DL/DS-Ch07.pdf
Ferreira, A. d., França, J. N., & da Silva Junior, V. P. (20 de Maio de 2018). Replicação
de base de dados MySql e PostgreSQL. Campinas, Brasil.
GIL, C. A. (2008). Métodos e técnicas de pesquisa social. São Paulo: Atlas.
INNARELLI, H. C. (2003). Preservação de Documentos Digitais Apostila do Arquivo
Central do Sistema de Arquivos – Agência para Formação Profissional –
UNICAMP/AC/SIARQ/AFPU. São Paulo: Universidade Estadual de Campinas,
Campinas.
Omicini, A. (2012). campus.unibo.it. Obtido em 01 de Outubro de 2017, de
http://campus.unibo.it/109047/1/8-SD-consistency.pdf
Prodanov, C. C., & Freitas, E. C. (2013). Metodologia do trabalho Científico: Métodos e
Técnicas da Pesquisa e do Trabalho Acadêmico. Rio Grande do Sul - Brasil:
Universidade Feevale.
S/A. (15 de Maio de 2018). www.cimm.com.br. Obtido em 01 de outubro de 2017, de
https://www.cimm.com.br/portal/verbetes/exibir/1162-replicacao
SANT’ANA, F. E. (2004). Solução profissional de Backup e Restore Monografia
(Bacharelado em Ciência da Computação) – Curso de Ciência da Computação.
São Paulo: Faculdade de Jaguariúna.
Tanenbaum, A. S., & Steen, M. V. (2006). Sistemas Distribuídos: princípios e
paradigmas. Prentice Hall.

CARLOS GAZITE AJM 33

Você também pode gostar