TCC HA

CURSO SUPERIOR DE TECNOLOGIA EM REDES DE

COMPUTADORES

JOSE CARLOS DOS SANTOS

JOSE DE RIBAMAR VIEIRA MERCES

NAILTON ARAUJO DE LIMA

ESTUDO DA ALTA DISPONIBILIDADE EM SERVIDORES DE

ARQUIVOS UTILIZANDO HEARTBEAT, DRBD E MON

RECIFE

2015

NAILTON ARAUJO DE LIMA

ESTUDO DA ALTA DISPONIBILIDADE EM SERVIDORES DE

ARQUIVOS UTILIZANDO HEARTBEAT, DRBD E MON

Trabalho de Conclusão de Curso apresentado ao Curso de Tecnologia de Redes de Computadores, para obtenção do título acadêmico de Graduação em Redes de Computadores, da UNIBRATEC, sob a orientação dos Professores Dailson de Oliveira Fernandes e Marcos Antonio Alves Gondim.

Orientadores: Prof. Marcos Antonio Alves Gondim e Prof. Dailson de Oliveira Fernandes

RECIFE 2015

NAILTON ARAUJO DE LIMA

ESTUDO DA ALTA DISPONIBILIDADE EM SERVIDORES DE

ARQUIVOS UTILIZANDO HEARTBEAT, DRBD E MON

Trabalho de Conclusão de Curso apresentado ao Curso de Tecnologia de Redes de Computadores, para obtenção do título acadêmico de Graduação em Redes de Computadores, da UNIBRATEC, sob a orientação dos Professores Dailson de Oliveira Fernandes e Marcos Antonio Alves Gondim.

.

Aprovado em:______/_______/_________

BANCA EXAMINADORA

__________________________________ Prof.Marcos Antonio Alves Gondim

Orientador ___________________________________ Nome do 2º Membro Função ou Instituição ___________________________________ Nome do 3º Membro Função ou Instituição

alegrias que ele tem me proporcionado, em especial meu filho que ainda está por vir a esse mundo. Dedico este trabalho a minha adorável esposa Stéfany dos Anjos Melo pela paciência e compreensão demonstrada nos momentos de ausência necessários para a elaboração desse trabalho, me apoiando e motivando a sempre seguir em frente rumo a meus objetivos. Não poderia deixar de citar meus pais que sempre me confortam, minha mãe Maria Josefa Fátima da silva sempre atenciosa e cuidadosa e meu pai Severino Francisco dos Santos que sempre demonstrou plena confiança quanto à realização desse trabalho. Agradeço a meus colegas de equipe pelo empenho e comprometimento demonstrados ao longo desse projeto. Por fim, porém não menos importante agradeço a meus orientadores, Professores Dailson de Oliveira Fernandes e Marcos Antonio Alves Gondim, que nos instruíram com seriedade e presteza.

JOSE DE RIBAMAR VIEIRA MERCES

Dedico este a trabalho primeiramente a Deus que me deu o ar da graça de viver nesse belo mundo, aos meus pais, Valdemar Vieira Evangelista e Nadia Narcisa de Lira Mercês, aos meus irmãos Marcos Vieira Mercês, Márcio Viera Mercês, Mário Vieira Mercês, Maurício Vieira Mercês e Maxwell Vieira Mercês, aos meus sogros Daniel Farias de Almeida e Maria José Fonsêca Aguiar de Almeida, a minha esposa Fernanda Fonsêca Aguiar de Almeida que me em corajou e me motivou em toda minha vida fazendo com que eu nunca desistisse de meus objetivos e sonhos, aos meus cunhados Daniela Jordão e Maurício Jordão enfim a toda minha família, pois sem eles não teria base para chegar até aqui, dedico também a todos os professores da graduação, onde muitos se tornaram meus amigos, sempre me motivaram e mederam conselhos. E aos meus companheiros de grupo de conclusão de curso composto por José Carlos dos Santos e Nailton Araujo de Lima que me acompanharam por esses anos durante o curso, foram grandes amigos em todos os momentos, obrigado pelo apoio e a todos os meus amigos do Curso de Redes de Computadores.

Dedico este trabalho primeiramente a Deus nosso criador e a toda a minha família, em especial ao meu pai Antônio Batista de Lima (in memoriam) pessoa na qual eu me inspiro todos os dias para conseguir meus objetivos, aos meus amigos e companheiros do grupo José Carlos dos Santos e José de Ribamar Vieira Mercês, pois sem a ajuda e incentivo dos mesmos eu não estaria onde estou hoje e aos orientadores, professores Dailson de Oliveira Fernandes e Marcos Antonio Alves Gondim pelo comprometimento e ensinamentos ao longo do curso.

DE ARQUIVOS UTILIZANDO HEARTBEAT, DRBD E MON 2015. Trabalho de Conclusão de Curso (Graduação em Tecnologia em Redes de

Computadores)-Faculdade de Tecnologia Ibratec. Recife-PE, 2015.

RESUMO

O presente trabalho tem como objetivo explorar ferramentas Open-Source que possibilitem a implementação de um sistema cluster de alta disponibilidade, propondo um ambiente tolerante a falhas, aumentando a disponibilidade dos recursos computacionais. Para isso será implementado um servidor de arquivos baseado em software livre utilizando o Samba, bem como os software, Heartbeat, DRBD e Mon.

DE ARQUIVOS UTILIZANDO HEARTBEAT, DRBD E MON 2015. Trabalho de Conclusão de Curso (Graduação em Tecnologia em Redes de Computadores)

-Faculdade de Tecnologia Ibratec. Recife-PE, 2015.

ABSTRACT

This work has as its main objective to explore Open-Source tools that enable the implementation of a high availability cluster system, offering a fault-tolerant environment, increasing the availability of computing resources. For it will be implemented a file server based on free software using the Samba, as well as software, Heartbeat, DRBD and Mon.

Figura 2.1: Modelo de três universos 22

Figura 2.2: Código contendo erro 22

Figura 2.3: Redundância Modular Tripla (TMR) 27

Figura 2.4: Processo de detecção e remoção de falhas 28

Figura 2.5: Detecção de falhas com verificação de limites 28

Figura 2.6: Recuperação de falhas por Rollback 29

Figura 2.7: Verificação de paridade par 31

Figura 2.8: Curva de banheira 32

Figura 2.9: Cluster de Processamento Distribuído 36

Figura 2.10: Split Brain 37

Figura 2.11: Balanceamento de carga 39

Figura 2.12: Balanceamento de carga global 40

Figura 2.13: Balanceamento de Carga de Firewall 41

Figura 2.14: LVS utilizando NAT 43

Figura 2.15: LVS utilizando Túnel 44

Figura 2.16: LVS utilizando roteamento 45

Figura 2.17: Combinação HA & Load Balancing 46

Figura 2.18: Cluster de Alta Disponibilidade 47

Figura 2.19: Failback 48

Figura 2.20: Heartbeat 56

Figura 2.21: Replicação de dados no DRBD 58

Figura 2.22: Cenário convencional 64

Figura 2.23: Cenário proposto 65

Figura 2.24: Node1 com IP virtual 69

Figura 2.25: Comunicação Heartbeat 69

Figura 2.26: Node2 assumindo o IP virtual 70

Figura 2.27: Transferência de arquivos 71

Figura 2.28: Sicronismo dos DRBDs 71

Figura 2.29: Partição montada node1 72

Figura 2.30: Partição montada node2 72

Figura 2.31: Erro de transferência de arquivo 73

Figura 2.32: Duplicidade de IP 74

Figura 2.33: Tabela ARP 74

Figura 2.34: Mon monitorando o smb do Samba 75

Figura 2.35: Mon notificando a paralização do Samba do node1 75

Figura 3.1: Arquivo de configuração authkeys do Heartbeat 82

Figura 3.2: Arquivo de configuração haresources do Heartbeat 84

Figura 3.3: IP virtual em funcionamento no servidor primário 85

Figura 3.4: IP virtual em funcionamento no servidor secundário 85

Figura 3.8: Script de aviso sobre paralização do Samba 92

Figura 3.9: Script de paralização do Heartbeat 93

Figura 3.10: Arquivo sudoers 94

Quadro 2.1: Medidas da Confiabilidade 51 Quadro 2.2: Descrição das características dos cenários 66

Tabela 2.1: Medidas da Disponibilidade 53 Tabela 2.2: Descrição dos hardware utilizados 67

BC Balanceamento de Carga CPU Central Processing Unit

CIFS Common Internet File System DNS Domain Name System

DRBD Distributed Replicated Block DDoS Distributed Denial of Service DWC Duplication With Comparation FSCK File System Check

HD Hard Disk IP Internet Protocol LVS Linux Virtual Server

MTBF Mean Time Between Failure MTTF Mean Time to Failure

MTTR Mean Time to Repair NAT Network Adress Translation NFS Network File System

NMR N-Modular Rendundancy PDC Primary Domain Controller PHP Hipertext Preprocessor

RAID Redundant Array of Independent Disks RAM Random Access Memory

SMB Server Message Block SO Sistema Operacional SPOF Single Point of Failure SSH Secure Shell

TCP Transmission Control Protocol TMR Triple Modular Redundancy UDP User Datagram Protocol

1 INTRODUÇÃO...16 1.1 JUSTIFICATIVA...17 1.2 OBJETIVOS...18 1.2.1 Objetivo geral...18 1.2.2 Objetivos específicos...18 2 DESENVOLVIMENTO...19

2.1 SISTEMA DE MISSÃO CRÍTICA...19

2.2 FALHA, ERRO E DEFEITO...21

2.2.1 Classificação de falhas...23 2.2.2 Prevenção de falhas...24 2.2.3 Tolerância a falhas...25 2.2.4 Redundância de hardware...26 2.2.4.1 Detecção de falhas...28 2.2.4.2 Recuperação de falhas...29 2.2.5 Redundância de software...29 2.2.6 Redundância de informação...30 2.2.7 Redundância de procesamento...31 2.2.8 Remoção de falhas...32 2.2.9 Previsão de falhas...32 2.3 CLUSTER...33 2.3.1 Classificação...34

2.3.2 Cluster de processamento distribuído...35

2.3.3 Cluster de balanceamento de carga...37

2.3.3.1 Balanceamento de carga de servidores globais...39

2.3.3.2 Banlaceamento de carga de firewall...40

2.3.3.3 Balanceamento de carga por replicação de site...41

2.3.3.4 Balanceamento de carga (Linux Virtual Server)...42

2.3.4 Combinação HA & Load Balancing...45

2.3.5 Cluster de alta disponibilidade (HA)...46

2.4 NÍVEIS DE DISPONIBILIDADE...48 2.4.1 Disponibilidade básica...49 2.4.2 Alta disponibilidade...50 2.4.3 Disponibilidade continuada...51 2.4.4 Cálculo da disponibilidade...51 2.5 APLICAÇÕES UTILIZADAS...53 2.5.1 Heartbeat...53

2.5.2 DRBD (Distributed Replicated Block Device)...56

2.5.3 Mon...60

2.5.4 Samba...60

2.6 ANÁLISE DOS DADOS...63

2.6.1 Cenário convencional...64

2.6.2 Cenário proposto...64

2.6.3 Implementação...66

2.6.4 Análise do funcionamento...68

3 CONCLUSÃO...76

REFERÊNCIAS...77

APÊNDICES...82

mercado por sistemas informatizados. Sistemas estes que em sua maioria concentram boa parte, senão todas as informações necessárias para realização das atividades das mais variadas empresas e instituições [CITATION Heb09 \l 1046 ].

Entretanto nem sempre estes sistemas estão disponíveis falhas de hardware ou software são fatores que podem ocasionar a interrupção de serviços de extrema importância causando transtornos irreparáveis, como prejuízos financeiros ou à reputação da organização. Estes tipos de incidentes são inevitáveis, mas podem ser amenizados através da utilização de tecnologias como: sistemas redundantes com conceito de master e slave, balanceamento de carga, software de gerenciamento, entre outros trazendo à tona o conceito de (HA) alta disponibilidade.

Para Brushi (2013), alta disponibilidade consiste na característica de um sistema informatizado resistente a falhas, visando manter os serviços disponíveis por um maior período de tempo possível. Apesar de sistema algum ser totalmente seguro, confiável ou disponível na presença de falhas [CITATION Mat11 \l 1046 ], ao longo deste trabalho serão abordadas tecnologias que possibilitem a implementação de um sistema de alta disponibilidade, tendo como foco a construção de um servidor de arquivos Open-Source tolerante a possíveis falhas provendo a continuidade dos serviços.

1.1 JUSTIFICATIVA

Segundo Acheroniano (2013), atualmente no mundo corporativo o sucesso de qualquer negócio está diretamente relacionado à disponibilidade das informações, motivando a adoção de tecnologias que possibilitem níveis aceitáveis de disponibilidade, provendo a continuidade dos serviços. No entanto essas soluções demandam certos investimentos, tornando-se muitas vezes inviáveis em alguns cenários.

Com a possibilidade de se alcançar níveis de alta disponibilidade com software Open-Source, o presente trabalho propõe a utilização conjunta do Heartbeat, Mon e DRBD (Distributed Replicated Block Device), empregando-se técnicas de redundância e contingência visando disponibilidade das informações no ambiente corporativo.

Será utilizado para exemplificar as funcionalidades da implementação o Samba, que consiste de um software de código aberto, que permite interoperabilidade entre sistemas operacionais Unix e Windows.

1.2 OBJETIVOS

1.2.1 OBJETIVO GERAL

Implementar através de ferramentas Open-Source um ambiente de alta disponibilidade utilizando-se de técnicas de redundância, contingência e monitoramento dos serviços em servidores de arquivos utilizando o Samba, evitando assim sua inoperabilidade, otimizando a utilização dos recursos computacionais de forma imperceptível para o usuário.

1.2.2 OBJETIVOS ESPECÍFICOS

 Tornar transparente, do ponto de vista do usuário, possíveis falhas de

hardware ou software, provendo a continuidade do serviço;

 Manter o sincronismo das informações em servidores distintos de forma dinâmica;

Amenizar danos provocados por falhas, reduzindo o período de indisponibilidade dos serviços.

2 DESENVOLVIMENTO

O desenvolvimento tem por objetivo apresentar os conceitos que serão abordados neste trabalho, que se fazem necessários para uma boa compreensão da implementação aqui proposta. Entre os temas abordados, destacam-se os intens “Falha, Erro e Defeito”, “Cluster”, “Alta Disponibilidade” e “Aplicações Utilizadas”.

2.1 SISTEMA DE MISSÃO CRÍTICA

Segundo Ribeiro (2012), sistemas de missão crítica são sistemas sociotécnicos ou técnicos, dos quais pessoas dependem. Deste modo, esses sistemas não podem parar de funcionar.

O sistema de missão crítica voltado para ambiente tecnológico tem uma grande importância, já que a continuação do negócio está sempre dependente dele, por esse motivo sua construção foi desenvolvida para evitar interrupções de serviços computacionais e tais perdas de dados que são importantes para um negócio. Isso envolve uma série de equipamentos e tecnologias que são aplicadas ao ambiente possibilitando um nível de confiabilidade elevado.

O que vai decidir que tipo de equipamento e que tipo de tecnologia será usado em um ambiente de missão crítica é o nível de importância do negócio e de sua operação, caso esses pontos não sejam bem observados uma determinada organização pode investir mais do que realmente precisa ou pior ainda pode investir menos significando que esse investimento de pouco adiantou [ CITATION Eme15 \l 1046 ].

Em seu artigo Ribeiro (2012), exemplifica alguns sistemas de missão crítica, sendo:

 Instituições financeiras (Bancos): Caso esse sistema fique fora do ar por muito tempo podem ocorre perdas de clientes para a concorrência, além de comprometer sua imagem ou ainda caso haja perda de dados desses clientes o banco pode vir a ter prejuízos incalculáveis já que não houve medidas ou planejamento para sanar esse problema;

 Hospitais: Pode-se considerar um sistema de missão crítica já que existem equipamentos que não podem parar de funcionar em hípotese alguma como scanners, tomógrafos, dispositivos de ultrassom, leitores dopplers em tempo real entre outros mais sofisticados em medicina, esses sendo extremamente críticos em seus resultados;



software ou até por falha humana vidas de pessoas estarão em perigo.

Em seu artigo Cambiucci (2009), descreve outros sistemas de missão crítica, porém analisando o impacto que esses sistemas podem causar em casos de falhas.

 Sistema de e-mails: É um sistema de missão crítica agumas empresas simplesmente param ou perdem negócios em casos de falha em suas caixas postais, causando impacto financeiro à mesma;

 Sistemas Hídroelétricos: Esse sistema responde mais de 70% da produção elétrica, caso ocorra falha em seu sistema o impacto causado pode ser grande casionando blecaute e prejuízos para empresas que necessitem da funcionalidade desse sistema caso não exista uma solução preventiva.

Todos os sistemas descritos operam em diferentes níveis, esses envolvendo riscos para o negócio como:

 Riscos Materiais: Perdas de equipamentos que são vitais para a continuação do negócio de uma determinada organização;

 Riscos Financeiros: Reparo ou aquisição de um novo equipamento, indenizações ou multas;

 Riscos Envolvendo Vidas Humanas: Morte de paciente por falha em equipamentos médicos, ou erro médico. Acidente de trabalho ocasionando morte ou invalidez devido a não precauções tomadas.

2.2 FALHA, ERRO E DEFEITO

A interrupção de serviços de crucial importância para as organizações ocorre devido à existência de falhas de diversas naturezas. Falhas de hardware, software ou links de rede são alguns dos motivos mais comuns da paralização dos sistemas e consequentimente dos serviços por eles providos.

Segundo Conceição (2012), a identificação precisa de uma falha é de extrema importância para implementação de mecanismos tolerantes que possam suporta-las.

No universo computacional, falha, erro e defeito possuem definições distintas que estão relacionadas, podendo uma falha levar ao surgimento de um erro e por sua vez um erro a ocorrência de um defeito [CITATION Kle14 \l 1046 ].

Em Silva, D.S (2011), falha, erro e defeito são definidos da seguinte forma:

 Falha: Consiste de um fenômeno natural que possui origem interna ou externa proveniente de ações humanas intencionais ou acidentais e estão relacionadas tanto a hardware como software. Desgaste de componentes ou interferência externa são exemplos que podem provocar falhas;

 Erro: É definido como um estado errôneo, o erro é ocasionado devido à ocorrência de uma falha;

 Defeito: É o não cumprimento de finalidade para a qual o sistema foi projetado, desvio de especificação.

A Figura 2.1 ilustra o modelo de três universos adotado por Kruger (2014). Este modelo define que as falhas estão relacionadas ao universo físico, os erros ao universo da informação e os defeitos ao universo do usuário.

Figura 2.1: Modelo de três universos

Fonte: Adaptada [ CITATION Dhi11 \l 1046 ]

Vale ressaltar que uma falha não necessariamente irá levar a ocorrência de um erro, assim como ilustrado na Figura 2.2, onde um código utilizado para verificar a classe de um endereço IP inserido pelo usuário, testando os três primeiros dígitos, classificando o endereço de acordo com os intervalos, esses sendo: classe A (0 -126), B (128 - 191) e C (192 - 223) encontra-se com um erro na linha dez, onde o valor 193 deveria ser na verdade 192. No entanto, por pertencer a uma estrutura condicional o erro pode nunca ser manifestado. Da mesma forma, um erro não necessariamente irá levar a um defeito, pois determinada informação incorreta pode nunca ser utilizada [CITATION Kle14 \l 1046 ].

Figura 2.2: Código contendo erro option explicit

dim ip

ip=inputbox ("informe o end ip") if left (ip,3) <= 126 then

msgbox”ip de classe A" elseif left (ip,3) = 127 then msgbox"ip loopback"

elseif left (ip,3) >= 128 and left (ip,3) <= 191 then msgbox"ip de classe B"

elseif left (ip,3) >= 193 and left (ip,3) <=223 then msgbox"ip de classe C"

end if

2.2.1 CLASSIFICAÇÃO DE FALHAS

Diversas são as causas pelas quais as falhas surgem em sistemas computacionais, todavia, a maior delas está na complexidade as quais esses sistemas são construídos, falhas não podem ser evitadas, porém podem ser toleradas [CITATION Mat141 \l 1046 ].

Com a vasta possibilidade de ocorrência, implementar mecanismos torelantes a falhas constitui-se um desafio.

Segundo Barros (2011), é de fundamental importância à especificação de um modelo que defina quais falhas devem ser tratadas, bem como características sendo: fonte da falha, perfil de ocorrência, duração e granularidade da falha.

Em Silva, D.S (2011), as falhas são classificadas de acordo com a dimensão que elas ocorrem, podendo ser por (software/hardware):

 Falhas de software: São inerentes a especificação do projeto de desenvolvimento do software, não constituindo uma falha física;

 Falhas de hadware: Ocorrem durante o processo de operação do sistema. São classificadas de acordo com sua duração:

 Falhas permanentes: São causadas por danos irreversíveis em componentes. A restauração desse tipo de falha ocorre somente através da substituição ou reparo do componente defeituoso.  Falhas transientes: São ocasionadas por interferências

externas como variação de corrente ou tensão elétrica, interferência eletromagnética ou radiação. Ocorrem com mais frequência que as falhas permanentes.

 Falhas intermitentes: Caracteriza-se por oscilar entre o estado errôneo e dormência, causando instabilidade no sistema.

Em seu trabalho Braga (2014), afirma que todas as falhas possíveis em um sistema se classificam de acordo com oito pontos de vista, esses sendo:

 Fase de criação ou ocorrência (desenvolvimento/operacional);  Dimensão (hardware / software);

 Fronteira do sistema (interna / externa);

 Causa fenomenológica (natural / causada pelo homem);  Objetivo (malicioso / não malicioso);

 Intenção (intencional / não intencional);  Capacidade (acidental / incompetência);  Persistência (permanente / temporária).

Um ponto crucial na construção de sistemas tolerantes a falhas é sua granularidade, que consiste na dimensão dos componentes que podem ser comprometidos. Uma falha pode afetar um módulo de hardware, uma aplicação, um link de comunicação ou até mesmo todo um parque computacional conforme a granularidade, diferentes mecanismos de tolerância devem ser utilizados para resolver essa questão [CITATION Mat11 \l 1046 ].

Conforme Traue (2012) há ainda outras características que devem ser observadas quanto a falhas em hardware e software:

 Ao contrário do software, mesmo em hardware não utilizado podem ocorrer falhas decorrentes da degradação do equipamento, por exemplo.

 As falhas de software são estritamente relacionadas à lógica ou dados incorretos, já em hardware são causadas por erros de projeto, deterioração, uso indevido ou fatores externos.

 Na maioria das vezes, quando ocorrem em hardware, as falhas são precedidas por avisos, enquanto que em software não ocorre da mesma forma.

2.2.2 PREVENÇÃO DE FALHAS

A prevenção de falhas consiste em agir de forma proativa buscando eliminar possíveis falhas antes que elas ocorram. Uma estratégia utilizada para a prevenção de falhas em ambientes computacionais é a manutenção preventiva de hardware, software e infraestrutura de rede [CITATION CON12 \l 1046 ].

Quanto à prevenção de falhas em software, diversas metodologias são empregadas pela engenharia do mesmo tendo o objetivo de reduzir falhas no processo de desenvolvimento. Outras metodologias utilizam técnicas como, catalogar falhas em produtos para aperfeiçoar o processo de desenvolvimento [CITATION Mat141 \l 1046 ].

2.2.3 TOLERÂNCIA A FALHAS

A tolerância a falhas é uma característica que permite a um sistema manter seu correto funcionamento mesmo na presença de falhas, sendo uma propriedade almejada em sistemas de alta disponibilidade [CITATION Thi12 \l 1046 ].

Conforme Kruger (2014), todas as técnicas de tolerância a falhas exigem a utilização de algum tipo de redundância, motivando a definição de “sistemas redundantes” para designar sistemas tolerantes a falhas.

Em Bruschi (2013), o conceito de redundância é definido como a capacidade de um sistema em superar falhas de um de seus componentes através do uso imediato de um segundo dispositivo previamente estabelecido. A redundância em sistemas computacionais pode ser obtida das seguintes formas:

 Redundância de hardware;  Redundância de software;  Redundância de informação;  Redundância de processamento.

Vale ressaltar que a utilização de qualquer forma de redundância deve ser bem planejada, uma vez que o emprego de tais técnicas pode impactar em aspectos

importantes do sistema como: desempenho, custo, consumo de energia, área, peso, entre outos [CITATION Hel11 \l 1046 ].

2.2.4 REDUNDÂNCIA DE HARDWARE

Segundo Amaral (2014), a redundância de hardware pode ser obtida através de três possíveis configurações:

 Hot standby: Neste modo de configuração todos os componentes pertencentes à redundância são mantidos totalmente ativos e operantes;

 Cold standby: Configuração em que todos os componentes da redundância são mantidos inativos até a ocorrência de uma falha;  Warm standby: Nesta configuração os componentes que constituem

a redundância são mantidos parcialmente inativos.

Para Franck (2011) e Kruger (2014), a redundância de hardware baseia-se na replicação física dos componentes de um sistema, sendo a forma de redundância mais comum e utilizada em sistemas computacionais. Entre as técnicas de redundância de hardware, podem ser citadas a redundância de hardware passiva ou estática e a redundância ativa ou dinâmica.

Na redundância passiva todos os componentes redundantes realizam o mesmo processamento e o resultado correto é definido por um votador. NMR, TMR e DWC são exemplos de técnicas passivas.

NMR (N-Modular Rendundancy): É a técnica mais comum de redundância de hardware, nesta técnica o hardware é replicado muitas vezes onde é utilizado para processar simultaneamente determinada informação, onde o valor do processamento é definido por um sistema de votação. Desta forma uma falha em apenas um dos componentes redundantes é mascarada evitando a ocorrência de erros.

TMR (Triple Modular Redundancy): É a técnica em que é utilizado o mesmo princípio da NMR, porém o hardware é apenas triplicado e o resultado é submetido a um votador. Nesta implementação o sistema votador é definido como um SPOF (Single Point of Failure), pois a ocorrência de uma falha no mesmo comprometerá o funcionamento de todo o sistema, conforme ilustrado na Figura 2.3.

Figura 2.3: Redundância Modular Tripla (TMR)

Fonte: Adaptado de [CITATION Hel11 \l 1046 ].

DWC (Duplication With Comparation): Essa técnica consiste na duplicação do hardware para fins de comparação de seus respectivos processamentos. Sendo utilizada para impedir que erros se propaguem pelo sistema, pois uma vez detectada divergência nos resultados a operação é abortada.

Kruger (2014), ainda descreve que na redundância ativa ou dinâmica são empregadas técnicas de detecção, localização e recuperação de falhas, no entanto o uso desta técnica se restringe a aplicações que suportam permanecer em estado errôneo por alguns instantes de tempo, esses instantes são utilizados para detecção e correção de falhas.

Em seu trabalho, Rebouças (2011), descreve o processo de detecção e recuperação de falhas em quatro fases, como mostrado na Figura 2.4 esses sendo:

 Detecção: Consiste em determinar a ocorrência ou não de uma falha;  Identificação: Objetiva identificar as variáveis envolvidas que são de

fundamental importância para o diagnóstico correto;

Ponto único

de falhas

 Diagnóstico: Determina qual a falha ocorrida. Essa fase deve ser bastante precisa, reunindo o máximo de informações possíveis, tais como, localização, intensidade e momento da ocorrência da falha;  Recuperação ou intervenção: É a fase em que os efeitos da falha

são removidos do sistema.

Figura 2.4: Processo de detecção e remoção de falhas

Fonte: Adptada [CITATION Dio11 \l 1046 ].

2.2.4.1 DETECÇÃO DE FALHAS

Entre os diversos métodos de detecção de falhas descritos em Rebouças (2011), destacam-se a detecção com verificação de limites e a detecção com modelos de sinais, ambos descritos adiante.

A detecção de falhas com verificação de limites consiste de um dos métodos mais intuitivos e simples, baseando-se na medição de uma determinada variável ao longo do tempo e comparação de seu valor com valor de limiar mínimo e máximo previamente estabelecido.

Conforme Figura 2.5, para que seja considerado o funcionamento correto do sistema (livre de falhas), o valor da variável Y deve estar contido entre os limites mínino e máximo de limiares definidos, onde Ymin < Y <Y max,

Outra técnica de

detecção de falhas é a detecção com modelos de sinais, que utiliza a comparação das características dos sinais como, fase, frequência e amplitude, com características dos sinais coletados durante o funcionamento normal do sistema. As diferenças dessas características são denominadas sintomas analíticos, que irão auxiliar na detecção das falhas.

2.2.4.2 RECUPERAÇÃO DE FALHAS

O processo de recuperação de falhas busca restaurar a normalidade de funcionamento de um sistema após a ocorrência de falhas. Na realização desse processo diversas técnicas são empregadas, no entanto a mais comum é a recuperação de falhas por retorno (Rollback), que consiste em retornar o sistema a um ponto anterior a ocorrência da falha. Esse processo é possível graças ao armazenamento dos estados dos processos do sistema, que são denomidados checkpoints [CITATION Mat11 \l 1046 ]. Como ilustrado na Figura 2.6.

Figura 2.6: Recuperação de falhas por Rollback

2.2.5 REDUNDÂNCIA DE SOFTWARE

De acordo com Franck (2011), diversas são as formas possíveis de se implementar redundância de software. No entanto a replicação de software indênticos não é uma técnica viável, uma vez que software idênticos irão apresentar falhas idênticas.

Em Kruger (2014), são definidas as seguintes técnicas de redundância de software:

 Programação N-versões: técnica que emprega diversas versões do mesmo software, desenvolvido por equipes distintas de desenvolvedores. Essa técnica utiliza o principio básico de que diferentes implementações dificilmente irão apresentar as mesmas falhas. Complexidade de sincronismo e elevado custo de produção e manutenção são algumas das desvantagens dessa técnica;

 Blocos de recuperação: técnica que utiliza um módulo principal e outros módulos secundários. Nessa técnica apenas o programa principal é executado e os demais programas serão executados em ordem sequencial caso ocorram erros no programa principal;

 Verificação de consistência: consiste em uma extenção da técnica N-versões, onde diversas equipes desenvolvem separadamente o software a partir de uma única especificação, porém desenvolvem também um módulo de verificação para a saída de seu próprio sistema em tempo de execução. A saída correta a ser selecionada precisa passar pelo seu próprio teste de verificação.

2.2.6 REDUNDÂNCIA DE INFORMAÇÃO

Este tipo de redundância é obtido através da utilização de códigos de detecção de erros, adicionando bits ou sinais extras no armazenamento ou envio dos dados que se deseja verificar a integridade, possibilitando a detecção e mascaramento de falhas [CITATION Hel11 \l 1046 ].

Uma das formas mais simples de redundância de informação é a verificação de paridade, que consiste na inserção de um bit a mais na informação a ser enviada. O valor desse bit (0 ou 1) será definido de acordo com o esquema de paridade utilizado, que pode ser par ou ímpar. No esquema de paridade par o valor do bit adicionado será selecionado de modo que o total de bits da informação mais o bit de paridade tenha um número par de bits ‘1’, como demonstrado na Figura 2.7. O esquema de paridade ímpar utiliza o mesmo raciocínio, no entanto o total de bits ‘1’ da informação mais o bit de paridade terá um valor ímpar [CITATION Kur11 \l 1046 ].

Figura 2.7: Verificação de paridade par

Fonte: Adaptado de [CITATION Kur11 \l 1046 ].

Verificação de Redundância Cíclica (CRC), Soma de Verificação, Checksum, Código M de N, Código Berger, Hamming e Reed-Slomon são outros exemplos de cóigos de detecção e correção de erros [CITATION Hel11 \l 1046 ] e [CITATION Kle14 \l 1046 ].

2.2.7 REDUNDÂNCIA DE PROCESAMENTO

Conforme Kruger (2014), a redundância de processamento (ou redundância temporal) é uma técnica utilizada em sistemas em que o tempo não é um fator crítico, pois a informação é processada por mais de uma vez no intuito de detectar falhas transientes ou permanentes. Essa técnica possui a vantagem de evitar custos adicionais com hardware:

 Detecção de falhas transientes: é repetida a execução de um determinado código e comparado os resultados, caso sejam diferentes implica na ocorrência de falha transiente. Essa obordagem

não é adequada para detecção de falhas permanentes, uma vez que a execução do código irá apresentar resultados semelhantes;

 Detecção de falhas permanentes: o processamento é repetido com um código codificado e o mesmo código decodificado. O resultado do processamento antes da codificação é comparado com o resultado depois da codificação, casa haja divergência é detectada falha permanente.

2.2.8 REMOÇÃO DE FALHAS

A remoção de falhas é realizada durante o processo de desenvolvimento do sistema, analizando e corrigindo falhas impedindo que essas sejam repassadas aos usuários [CITATION CON12 \l 1046 ].

Em seu trabalho Lima (2014), descreve os procedimentos para a remoção de falhas.

 Verificação: consiste em verificar a existência de novas falhas a cada nova funcionalidade adicionada ao sistema;

 Diagnóstico: realiza a identificação e localização de falhas existentes no sistema;

 Remoção: É a remoção propriamente dita das falhas identificas nos processos anteriores.

2.2.9 PREVISÃO DE FALHAS

A previsão de falhas tem por objetivo estimar quando irá ocorrer uma falha no sistema, possibilitando a remoção desta antes mesmo de sua ocorrência [CITATION CON12 \l 1046 ].

Em Traue (2012), é descrito o conceito de curva de banheira, que demonstra o comportamento do sistema no decorrer do tempo em relação à ocorrência de falhas, conforme ilustrado na Figura 2.8.

Figura: 2.8 Curva de banheira

Fonte: [CITATION Thi12 \l 1046 ].

O período A é denominado mortalidade infantil, que corresponde ao início do desenvolvimento do sistema e realização de testes, apresentando uma curva de falhas decrescente. O período B corresponde à vida útil do sistema, e apresenta taxa de falhas constante, seguido pelo período C em que há um aumento considerável da taxa de falhas, definido como período de envelhecimento.

A previsão de falhas pode ainda ser realizada baseada em eventos passados. Um histórico das falhas ocorridas pode ser utilizado para prever de forma aproximada quando e quais falhas irão ocorrer. Com base nessas informações é possível corrigir as falhas antes de sua ocorrência [CITATION CON12 \l 1046 ].

2.3 CLUSTER

Nesta seção será abordado o conceito sobre cluster, também serão descritos no decorrer dessa seção suas classificações, características, vantagens e desvantagens.

Quando se utiliza de soluções para prover alta disponibilidade o sistema cluster se torna uma escolha imprescindível, já que na maioria das vezes falhas existirão ocasionando indisponibilidade de serviços, além de sobrecarga do servidor que provém o serviço, esse não conseguindo processar múltiplas tarefas. Por esse aspecto faz-se necessário a utilização de um sistema cluster almejando um nível maior de disponibilidade.

Para Pintanga (2014), cluster é um sistema distribuído de computadores conectado em rede, cujo objetivo é suprir a necessidade de um grande poder computacional, melhorando o desempenho de aplicações e criando redundância para que em caso de falhas de hardware ou software, os recursos e aplicativos continuem disponíveis para o usuário final.

O cluster consegue dividir processos de uma aplicação ou serviço para os demais nodes aparentando ser um único computador. Cada computador em um sistema cluster é denominado (nó ou node), os nodes são interconectados formando uma rede onde a mesma deva ter uma capacidade de crescimento [CITATION EspaçoReservado1 \l 1046 ]. A utilização de um sistema cluster proporciona diversas vantagens como:

 Escalabilidade: capacidade de processar uma grande quantidade de dados ao mesmo tempo;

 Alto desempenho: Consegue processar os dados com mais rapidez já que utiliza a distribuição dos serviços por entre os nodes;

 Alta disponibilidade: Utiliza redundância tanto de hardware quanto de software através de replicação de serviços e servidores mantendo assim serviços, aplicações e dados armazenados sempre disponíveis;  Uso de hardware de baixo custo: Podendo utilizar máquinas de uso

diário sem a necessidade de hardware para um alto desempenho.  Facilidade de manutenção: Uma vez que pode ser realizada a

paralização em um dos nodes sem afetar o funcionamento dos serviços.

2.3.1 CLASSIFICAÇÃO

O cluster pode ser classificado de acordo com suas características necessárias à funcionalidade que se busca obter. Sendo elas:



 Cluster Workstations: Essa classificação de cluster é composta de computadores pessoais, onde se obtem (teclado, monitor e mouse) tendo propriedade de cluster não dedicado;

 Cluster de SMPs (CLUMPs): Composto por vários processadores interligados entre si por meio de uma única memória e de um único sistema operacional, sendo possível compartilhar todos os recursos computacionais disponíveis como (Discos, placas de rede, impressoras e outros), essa solução é empregada para servidores de pequeno porte.

Em seu trabalho Bacellar (2010), afirma que para que um sistema cluster possa operar de forma eficiente é preciso que o sistema operacional dos nodes (computadores) venha ser igual, isso evita problemas em sua operação já que cada sistema tem sua particularidade. Ao fazer o uso de sistemas híbridos suas particularidades poderiam causar paralização na operação do sistema cluster já que determinadas aplicações são desenvolvidas apenas para um determinado sistema operacional.

Independentemente do sistema operacional que esteja sendo usando é importante escolher a melhor solução de um sistema cluster que se adeque à necessidade de uma organização [ CITATION Pit \l 1046 ].

2.3.2 CLUSTER DE PROCESSAMENTO DISTRIBUÍDO

O cluster de processamento distribuído trabalha utilizando partes das operações que ocorrem em máquinas diferentes, executando o fluxo principal de um programa. O processamento distribuído deve ser utilizado muitas vezes por organizações que necessitem de um grande poder computacional [CITATION Rod12 \l 1046 ].

Em seu trabalho Ferrão (2012), relata que esse tipo de cluster é confiável, consistente e atraente economicamente, pois é possível utilizar recursos computacionais distribuídos em uma rede centralizada ou geograficamente separada, obtendo assim capacidade computacional elevada com baixo custo.

O intuito desta solução é aumentar o nível de disponibilidade em conjunto com o desempenho das aplicações, esse processo pode ser visto na Figura 2.9, onde os clientes fazem requisições, essas sendo representadas por setas, ao

receber essas requisições o node principal denominado Master do sistema cluster envia as mesmas para os demais nodes esses denominados Slavers, entretanto as requisições são enviadas aos nodes secundários já fragmentadas. Deste modo o precessamento se torna eficiente já que partes das requisições são processadas em diferentes nodes. Em outras palavras, os nodes desse sistema cluster conseguem processar e executar tarefas de grande porte dividindo-as em pequenas tarefas distribuindo as mesmas para os demais nodes.

Ao término do processo, o node principal devolve as requisições solicitadas para os seus respectivos clientes

Essa solução funciona de modo ativo/ativo já que todos os nodes do sistema cluster de distribuição encontram-se operantes podendo receber e responder requisições de usuários, sua topologia faz com que diversos nós do cluster processem em conjunto, ao mesmo tempo os dados que eles comportam, deste modo seu funcionamento se compara a uma linha de produção, onde cada nó tem um papel específico operando de forma simultânea com a mesma finalidade de se obter o resultado no processamento fazendo isso da melhor forma possível[ CITATION Pit \l 1046 ].

Figura 2.9: Cluster de Processamento Distribuído

Fonte: Próprios autores.

Entretanto Jerps (2011), em seu artigo relata que um sistema cluster pode trazer sérios problemas, caso não venha ser bem planejada sua implementação, ocasionando transtornos para a continuação do negócio de uma organização, a Figura 2.10 detalha como ocorre esse incidente. Caso um nó ou mais nós desse sistema venham a falhar o cluster após essa falha irá reagrupar os demais nodes que se encontram ativos recorrente de uma falha, porém pode haver um erro no reagrupamento desse sistema, em vez de ser um único grupo de nós pode ocorrer a existência de dois grupos de nós, esse incidente é conhecido como Split Brain (Cérebro Dividido) geralmente ocorre quando um grupo de nós enxergam somente a si supondo serem os únicos ativos no sistema cluster não enxergado outros nós que se encontram operantes no sistema. Deste modo não existi um node principal esse sendo o responsável pelo envio e recebimentos das requisições tanto para usuários quanto paras os nodes secundários como foi ilustrado anteriormente na Figura 2.9.

Figura 2.10: Split Brain

2.3.3 CLUSTER DE BALANCEAMENTO DE CARGA

Com o crescimento rápido da internet muitos problemas de desempenho incluindo tempo de resposta baixo, congestionamento da rede e interrupções dos serviços, inúmeras vezes causados por sobrecarga do sistema ou por ataques de cyber criminosos que utilizam de métodos como DDoS (Distributed Denial of Service), deste modo há a necessidade de mitigar esse problema podendo utilizar de soluções já conhecidas como o balanceamento de carga, seu objetivo principal é fazer divisão de tarefas de um serviço entre os nodes de um sistema cluster[ CITATION Mar15 \l 1046 ].

DDoS (Distributed Denial of Service) constitui um ataque de negação de serviço distribuído, ou seja, um conjunto de computadores é utilizado para tirar de operação um ou mais serviços ou computadores conectados à Internet. Normalmente estes ataques procuram ocupar toda a banda disponível para o acesso a um computador ou rede, causando grande lentidão ou até mesmo indisponibilizando qualquer comunicação com este computador ou rede[ CITATION Jor111 \l 1046 ].

Muitas empresas que operam com plataforma Web recorrem à utilização de BC (Balanceamento de Carga) por possuirem grandes volumes de tráfegos em seus sites, onde muitas vezes um único servidor Web não consegue lidar com tráfego demasiado, esse vindo a travar [ CITATION Rui11 \l 1046 ].

Para resolver esse incidente às empresas fazem instalação de "webfarm" (Fazendas de Servidores), fazendo distribuição dos tráfegos que foram gerados pelos clientes para os demais servidores da rede, evitando assim gargalos criados pelos acessos simultâneos [ CITATION Pit \l 1046 ]. O cluster BC pode ser usado de dois modos, esses sendo:

 Hardware: Utilização de appliances equipamentos físicos;

 Software, Utilização de ferramentas instaladas em servidores que ficarão responsáveis pelo balanceamento dos tráfegos.

A Figura 2.11 ilustra como funciona o balanceamento de carga. Nesse recurso existe apenas um servidor responsável pelo balanceamento de carga denominado servidor virtual, este servidor é colocado em front-ed (de frente), onde

ficará recebendo as requisições solicitadas pelos utilizadores após receber as requisições o servidor as repassa de maneira balanceada para os outros servidores que executam a mesma aplicação, caso haja uma falha em um dos nós esses nós serão excluídos da relação de máquinas receptoras.

A vantagem de se utilizar essa solução é que se podem adicionar novos computadores ao sistema evitando a necessidade de atualização de hardware dos já existentes [CITATION EspaçoReservado1 \l 1046 ].

Figura 2.11: Balanceamento de carga

Fonte: (CANALTECH, 2010)

2.3.3.1 BALANCEAMENTO DE CARGA DE SERVIDORES GLOBAIS

É voltado para múltiplos servidores Web espalhados pelo mundo. Esse sistema prover disponibilidade de serviço constante, onde os servidores estão interligados por uma plataforma totalmente dedicada, deste modo os servidores Web que estão espalhados geograficamente aparentam estar interligados localmente, assim caso um servidor Web que esteja sendo acessando fique fora do ar as requisições que foram solicitadas para o mesmo serão redirecionadas para um próximo servidor Web em qualquer lugar do mundo. Na Figura 2.12 é possível visualizar o cliente 4 enviando uma mensagem para um servidor denominado Datacenter 2 esse servidor encotra-se inoperante a requisição enviada ao mesmo será redirecionado para o servidor denominado Datacenter 3, entretanto o

solicitante no caso o cliente 4 não percebe esse procedimento sendo totalmente transparente para o mesmo. Esse sistema não opera somente em casos de falhas, mas em demanda excessiva de requisições essas sendo balanceadas [CITATION Mar15 \l 1046 ].

Figura 2.12: Balanceamento de carga global

Fonte: (CANALTECH, 2010)

2.3.3.2 BANLACEAMENTO DE CARGA DE FIREWALL

Esse balanceamento utiliza das mesmas características de um balanceamento de carga para servidores, entretanto para que funcione de maneira eficaz é necessário manter todas as sessões em memória na outra extremidade

obtendo-se uma cópia de todo conteúdo armazenado na memória do Firewall primário, contendo todas as sessões que estão em tráfego fazendo sua replicação e alocando sua tabela de sessões no Firewall secundário [ CITATION Pit \l 1046 ]. Como apresentado na Figura 2.13

Figura 2.13: Balanceamento de Carga de Firewall

Fonte: Adaptada (IDAQ, 2010)

2.3.3.3 BALANCEAMENTO DE CARGA POR REPLICAÇÃO DE SITE

Nesse método é feito o espelhamento de um site (mirroing) sendo exato ao site original contendo as mesmas informações do mesmo, as réplicas são utilizadas normalmente para oferecer fontes múltiplas do mesmo dado, isso serve para equilibrar a carga de tráfego de vários pedidos solicitados pelos usuários (download) na Web.

Essas réplicas na maioria das vezes são colocadas em locais diferentes em toda Internet com servidores de arquivos contendo um conjuto duplicado/cópia de arquivos de outro servidor de arquivos balanceando assim a carga de distribuíção

garantindo uma rápida disponibilização dos dados quando existe uma grande procura [ CITATION Pit \l 1046 ].

Todos os balanceadores de carga descritos anteriormente podem ser utilizados tanto em sistema Windows quanto Unix, entretanto quando se deseja implementar balanceador de carga exclusivamente para sistema Linux a melhor opção é o LVS (Linux Virtual Server), sendo uma solução Open-Source avançada que foi desenvolvida por Wensong Zhang em maio de 1998. Essa ferramenta será abordada na próxima seção.

2.3.3.4 BALANCEAMENTO DE CARGA (LINUX VIRTUAL SERVER)

Segundo JR (2011), LVS (Linux Virtual Server) é uma solução criada para balanceamento de carga voltada para sistema Linux, é um projeto de código aberto, o objetivo dessa ferramenta é construir um servidor tendo alto desempenho e uma alta disponibilidade.

O sistema VLS trabalha com conjunto de servidores onde o centralizador dessa tecnologia é denominado diretor do LVS, este diretor funciona como se fosse um switch de camada 4 TCP/IP, mas com algumas funcionalidades a mais. O diretor recebe a conexão do cliente e então decide para qual servidor backend vai entregar a requisição solicitada para ser atendida.

Os servidores reais podem ser adicionados ou removidos sem que os clientes percebam essa mudança, permitindo que servidores sejam removidos para manutenção sem problemas. Os servidores reais podem oferecer qualquer serviço na Internet como: Proxy, Web, SSH e outros. Esse sistema tem a capacidade de construir três modelos, são eles:

 NAT (Network Adress Translation). Utiliza IP público no diretor e IPs privados nos servidores reais. Neste modelo o diretor do LVS vai ser o gateway de todos os servidores reais, por esse motivo o ip_forward deve estar ativo em ambas placas de redes, as requisições de respostas entre os clientes e o LVS serão tratadas pelo diretor este modelo é o mais simples, porém o diretor se torna um limitante à quantidade de servidores reais que podem ser utilizados, porém não existe

limitação quanto ao sistema operacional bastando apenas ter suporte ao TCP/IP a Figura 2.14 ilustra essa topologia. [ CITATION Ser11 \l 1046 ].

Figura 2.14: LVS utilizando NAT

Fonte: Adaptada de (SERVER,2011)

 Túnel: Neste modelo o diretor envia as requisições dos clientes através de um túnel esse, fazendo o encapsulamento dos dados, deste modo as requisições são enviadas diretamente ao servidor real que foi solicitado pelo cliente sem que os demais servidores reais tenham acesso a essa informação, as respostas para os clientes são feitas diretamente pelos servidores reais. Neste modelo o node denominado diretor fica apenas responsável em repassar as

requisições dos clientes para os servidores reais. No entanto a limitação deste modelo é o fato de que os servidores reais são obrigados a suportarem túneis. Uma curiosidade deste modo é que um servidor que está mais próximo do cliente pode ser "escolhido" para reduzir a latência. A Figura 2.15 ilustra essa topologia [ CITATION Ser11 \l 1046 ].

Figura 2.15: LVS utilizando Túnel

Fonte: Adaptada de (SERVER,2011)

Túnel consiste na criação de uma passagem alternativa da rede local para que os dados possam ser enviados sem que outros usuários dessa rede venham a ter acesso às informações onde essas são criptografadas e enviadas por esse túnel até seu destino final esse método proporciona um nível de

segurança alto [ CITATION Ela09 \l 1046 ].

 Roteamento direto: Neste modelo todos os nodes do sistema LVS incluindo o diretor node resposável pelo balanceamento de carga estarão na mesma sub-rede, essa sendo 192.168.0.0/24 assim o IP público 200.100.1.135 que foi utilizado somente pelo diretor nos modelos descritos anteriormente agora passa a ser utilizado também pelos servidores reais, deste modo as requisições dos usuários que são enviadas através do diretor essas são analisadas pelo mesmo, onde essas analises são feitas através do IP da sub-rede que o servidor real contém e pela porta de destino que esse IP responde, quando o node diretor enviar a requisição para o servidor que foi solicitado em vez do servidor que recebeu a solicitação do cliente por intermédio do diretor enviar devolta a resposta da requisição para o mesmo, é o servidor real que responde diretamente para o cliente. Em outras palavras o diretor do sistema LVS fica apenas recebendo as requisições já que as respostas são feitas pelos servidores reais. A Figura 2.16 ilustra essa topologia [ CITATION Bri13 \l 1046 ].

Figura 2.16: LVS utilizando roteamento

Fonte: Adaptada de (SERVER,2011). 2.3.4 COMBINAÇÃO HA & LOAD BALANCING

Essa implementação utiliza as duas características proporcionando alta disponibilidade e escalabilidade dos serviços esse sistema opera em sincronia não só oferecendo alta disponibilidade, mas oferecendo distribuição de carga, esse tipo de cluster é bastante utilizado em serviços como sites, e-mail e compartilhamento de arquivos, onde são considerados serviços de missão crítica já que algumas organizações só funcionam com esses serviços [ CITATION Jor11 \l 1046 ].

A Figura 2.17 mostra como funciona esse mecanismo, quando N clientes fazem pedidos para o servidor o mesmo tem que responder esses pedidos em um tempo hábil para os clientes, entretanto quem recebe essas solicitações é o balanceador de carga que atua como mediador, ao receber as solicitações o balanceador irá analisar a quantidade de pedidos que são enviados para o servidor principal, caso o servidor principal tenha uma quantidade de requisição maior do que possa suportar o balanceador enviará as requisições restantes para o nó secundário deste modo as requisições são respondidas rapidamente para os usuários locais da rede.

Figura 2.17: Combinação HA & Load Balancing

Fonte: Adapatada (IMASTERS, 2010).

2.3.5 CLUSTER DE ALTA DISPONIBILIDADE (HA)

Esse cluster é voltado para prover uma disponibilidade de serviço e dos recursos de forma ininterruptas utilizando o método de redundância ao sistema a Figura 2.18 ilustra como ocorre esse processo, caso um nó primário venha parar de funcionar devido a uma falha ou manutenção do sistema, o nó secundário será encarregado de assumir os serviços e recursos rapidamente esse método é conhecido como (failover) ocorre quando um sistema que está ativo tem uma falha e o servidor que estava em stand-by entra em ação ocupando seu lugar. Geralmente essa solução é utilizada para aplicações de dados e serviços de missões críticas [ CITATION Mar15 \l 1046 ].

Fonte: Adptada (MSSERVERPRO, 2011)

Existe a situação inversa, onde ela ocorre quando o sistema que ficou inoperante volta a ficar ativo podendo assim operar os serviços e as aplicações que foram migradas para o servidor secundário exercendo suas funções originais é conhecido como Failback [ CITATION Rui11 \l 1046 ].

Muitas vezes o sistema não consegue fazer isso de forma automática tendo que ter a intervenção humana fazendo todo processo manualmente para colocá-lo ativo novamente tudo isso de forma transparente sem que o usuário perceba. A Figura 2.19 ilustra esse processo.

Fonte: Adptada (MSSERVERPRO, 2011).

2.4 NÍVEIS DE DISPONIBILIDADE

Nesta seção serão abordados detalhadamente os conceito de Alta Disponibilidade HA (HighAvailability), níveis de disponibilidade e cálculo.

Para se atingir um grau elevado de disponibilidade é importante entender que a redundância de recursos é um pré-requisito. É importante analisar que falhas não são restritas apenas a hardware e software, entretanto também as redes de computadores, as redes elétricas e à localização dos recursos estão sujeitas a essas falhas [ CITATION Jor11 \l 1046 ].

A respeito de redes de computadores, devem-se levar em considerações os switchs, routers, cabos e todos os restantes dos ativos físicos de uma rede.

Para rede elétrica é importante entender que qualquer tipo de oscilação ou interrupção do serviço deve ser complementado por outra forma de geração de energia podendo ser utilizado geradores, no-breaks e energia solar, a redundância desses equipamentos é um ponto forte para a continuação do negócio.

É imprescindível observar a localização física dos recursos para proteção contra possíveis incidentes como enchentes, roubos e até ataques terroristas, para evitar qualquer ocorrência de incidente relacionada é importante a utilização de equipamentos em locais diferentes, deste modo caso ocorra indisponibilidade de um equipamento ou serviço o outro equipamento ou serviço possa suprir de forma operante o serviço que se encontra ativo. Quando se fala que um sistema é de alta disponibilidade, é essencial que esse sistema deva envolver não apenas uma simples redundância de recursos, mas toda uma estrutura que possa evitar determinadas paralizações [ CITATION Jor11 \l 1046 ].

Em seu trabalho Neves (2012), define três níveis de alta disponibilidade, essas sendo: “Disponibilidade Básica”; “Alta Disponibilidade” e “Disponibilidade Continuada”.

2.4.1DISPONIBILIDADE BÁSICA

Primeiro nível de alta disponibilidade é voltado para máquinas comuns que são implementadas com componentes de (hardware e software), não possui habilidade de ocultar falhas encontradas, deste modo a visualização da mesma fica visível para usuários. Este nível apresenta uma porcentagem de disponibilidade de 99% a 99.9% com isso os equipamentos podem ficar inativos 8 horas e 45 minutos por ano [ CITATION Jor11 \l 1046 ].

2.4.2 ALTA DISPONIBILIDADE

Em seu trabalha Aguiar (2012), define alta disponibilidade sendo um sistema voltado para resistência a falhas objetivando manter os serviços de um determinado sistema disponível por um tempo máximo, garantindo a ausência de paradas de serviços, sendo necessário muitas vezes dispor de hardware ou serviços redundantes que entre em funcionamento automaticamente caso haja uma inoperabilidade, quanto mais redundância se tiver menores serão os pontos únicos de falhas SPOF (Single Point Of Failure), garantindo assim uma menor interrupção no serviço proporcionando menor probabilidade dessas interrupções ocorrerem com frequência.

A alta disponibilidade significa que o serviço de TI está continuamente disponível para os usuários havendo poucas paralizações e tendo rápida recuperação, a alta disponibilidade é algo que se deseja manter onde normalmente será empregada em ambientes de missão crítica, evitando ao máximo a indisponibilidade que tem fortes impactos sobre o negócio.

A alta disponibilidade busca por altos percentuais níveis mais altos, quanto maior o nível melhor será a disponibilidade.

Para ter um sistema ou serviço que garanta a alta disponibilidade é preciso investir isso vai de aquisição de hardwares adicionais, software, redundância de links, atualização de arquitetura de aplicação e treinamentos de profissionais, todo

esse conjunto será utilizado tanto para prover disponibilidade de sistema e seus serviços quanto para resolver os problemas causados pela indisponibilidade.

De acordo com Neves (2012), ativos que apresentem um nível de porcentagem de disponibilidade elevado entre quatro e cinco noves (99.99%, 99.999%), podem ficar inativos por cinco minutos a uma hora em um ano de funcionamento, entretanto se esse nível for menor pode existir uma inatividade por um período maior nesse sistema, o que traria perdas financeiras demasiadas para uma organização.

2.4.3 DISPONIBILIDADE CONTINUADA

Alta disponibilidade continuada aumenta os níveis conseguindo obter uma disponibilidade próxima aos 100% a vantagem desta disponibilidade é que suas inatividades tanto planejadas ou não são mascaradas por se utilizar redundância e replicação deixando assim o sistema sempre disponível. Esse nível nos dar uma porcentagem de 99.9999% onde o sistema ou serviço pode ficar 32 segundos inativos por ano, em termos práticos é muito difícil obter esse nível [ CITATION Pit \l 1046 ].

2.4.4 CÁLCULO DA DISPONIBILIDADE

Uma forma para descobrir quanto tempo um sistema ou serviço ficaria disponível em um determinado ano é utilizar o cálculo que é voltado tanto para equipamentos em uma topologia de rede quanto em sistemas, o cálculo é baseado nas taxas de falhas podendo apresentar um parâmetro de confiabilidade. Para se calcular a disponibilidade é de fundamental importância conhecer as siglas MTBF, MTTR, MTTF isso irá facilitar o entendimento do cálculo [ CITATION Ald13 \l 1046 ]. O Quadro 2.1 mostra os significados das mesmas. Isso irá facilitar o entendimento do cálculo [ CITATION Ald13 \l 1046 ].

Fo

nt e:

Neves, 2012.

Segundo Brandão (2011), para calcular a disponibilidade de um equipamento é utilizado uma fórmula que mostra todo o detalhamento do processo. Exemplificando considerando que em um período de 4 anos um equipamento tenha ficado indisponivel por 6 horas, utilizando o cálculo pode-se analisar que a disponibilidade desse equipamento foi:

24 = Horas; 365 = Dias;

8760 = Total de horas em um ano.

Como já foi obtida a disponibilidade do equipamento calculado será necessário encontrar o tempo em que o mesmo ficou fora do ar por ano primero se pega a parte total de 100% e subtrai a disponibilidade assim é possível encontrar a indisponibilidade que nesse caso foi 0, 0002% [ CITATION Ald13 \l 1046 ].

Sabendo que o valor 0,0002 é o percentual de tempo em que o equipamento ficou em (downtime) em um período de 35040 horas (4 anos) que foi o MTBF do equipamento é importante descobrir o tempo que esse equipamento ficou realmente em (downtime) em um ano. Onde um ano tem 8760 horas utilizando a formula:

MEDIDA SIGNIFICADO

MTTF Mean Time to Failure

(Tempo médio para falha) É o tempo esperado até a primeira ocorrência de defeito.

MTTR Mean Time to Repair (Tempo médio para reparo)

É o tempo médio para o reparo do sistema

MTBF Mean Time Between Failure (Tempo médio entre falha)

O resultado mostrou que em um ano o equipamento ficou em (downtime) 1,752 horas dando aproximadamente 2 horas de indisponibilidade. Abaixo temos a Tabela 2.1 que ilustra as medidas da disponibilidade [ CITATION Ald13 \l 1046 ].

Tabela 2.1: Medidas da Disponibilidade

Código Uptime Downtime Downtime por ano

1 100% 100% Nenhum

2 99,999% 0,0001% Menos de 5,26 min.

3 99,99% 0,001%

De 5,26 a 52 min

4 99,9% 0.01% De 52 min. a 8 horas e 45 min.

5 99% 0,1% De 8 horas e 45 min. a 87 horas e 56 min

6 90,0 % 10% 87 horas e 56 min a 875 horas 54 min

Fonte: [CITATION JOR10 \l 1046 ].

2.5 APLICAÇÕES UTILIZADAS

Nesta seção serão abordadas as ferramentas Open-Source utilizadas na implementação do cluster de alta disponibilidade, com objetivo de alcançar altos níveis de disponibilidade em servidores de arquivos. Para isto serão utilizadas as seguintes aplicações: Heartbeat, que terá a função de monitorar a disponibilidade dos servidores; DRBD que ficará encarragado da replicação dos dados entre os servidores; o Mon que é uma ferramenta open-source que será utilizado para monitorar o serviço do Samba; e o próprio Samba que será utilizado para o compartilhamento dos arquivos, ambos descritos a seguir. Entretanto por ser utilizado apenas para exemplificar as funcionalidades do cluster, não serão