Redes e Servidores: Alta Disponibilidade

Interrupção planeada

Interrupções planeadas incluem a manutenção, backups offline e actualizações. Estas muitas vezes podem ser agendadas fora dos períodos de alta disponibilidade, quando é necessário.

Interrupções não planeadas

Embora as interrupções planeadas sejam um mal necessário, uma interrupção não planeada pode ser um verdadeiro pesadelo para um negócio. Dependendo do negócio em questão e da duração do tempo de inactividade, uma interrupção não planeada pode resultar em perdas tão avassaladoras que a empresa seja forçada a fechar. Independentemente da sua natureza, as interrupções são algo que as empresas normalmente não toleram. Há sempre pressão sobre a TI para eliminar totalmente estas paragens não planeadas e de reduzir drasticamente, se não eliminar, o tempo de inactividade planeado.

Note-se que uma aplicação ou sistema de computador não precisa estar totalmente em baixo para se considerar inactivo. É possível que o desempenho de uma aplicação se degrade de tal forma que é inútil. Do ponto de vista do utilizador empresarial ou final está em baixo, embora esteja disponível.

As paragens não planeadas podem ter várias causas e podem ser categorizadas em:

Falhas de Hardware - Falha de componentes principais sistemas, tais como processadores e memória ou periféricos, discos, controladores de disco, placas de rede, ou equipamentos auxiliares, tais como módulos de alimentação e ventiladores, e equipamentos de rede, como switches, hubs, cabos, etc, podem ser as causas de falhas de hardware.

Falhas de Software - As possibilidades de falha de software dependem principalmente do tipo de software utilizado. Uma das principais causas de falha de software é aplicar um patch. Às vezes, se um patch não corresponde ao tipo de aplicação, o software aplicacional pode começar a comportar-se de maneira estranha, trazendo para baixo a aplicação e revertendo as alterações, se possível. Às vezes, uma actualização também pode causar um problema. Os principais problemas com as actualizações serão relacionados com o desempenho ou o comportamento inadequado de qualquer produto de terceiros, que depende dos upgrades.

Erros Humanos - Uma acção acidental de qualquer utilizador pode causar uma falha grave no sistema. Apagar um ficheiro necessário, apagar os dados ou uma tabela, actualizando a base de dados com um valor errado, etc, são alguns exemplos.

Redundância

A redundância é usada para eliminar a necessidade de intervenção humana. Os dois tipos de redundância são redundância activa e passiva.

A redundância passiva é utilizada para obter alta disponibilidade, incluindo excesso de capacidade suficiente no projecto para suportar uma quebra no desempenho. O exemplo mais simples é um barco com dois motores independentes ligados a duas hélices separadas. O mau funcionamento de componentes individuais não é como falha a não ser que o declínio do desempenho resultante exceda os limites de especificação para todo o sistema.

A redundância activa é usada em sistemas complexos para atingir alta disponibilidade, sem diminuição do desempenho. Vários itens do mesmo tipo são incorporados num projecto que inclui um método para detectar falhas e reconfigurar automaticamente o sistema de modo a ignorar os itens falhados um esquema de votação. Isto é usado em sistemas computacionais complexos que estão ligados. A redundância activa pode apresentar modos de falha mais complexos do sistema, tais como a reconfiguração contínua do sistema, devido a uma lógica de votação defeituosa.

Fiabilidade

Fiabilidade é uma medida de prevenção de falhas. É a probabilidade de um sistema ainda estar a funcionar no instante t+1 quando ele trabalhou no tempo t. Uma definição semelhante é a probabilidade de um sistema estar disponível ao longo de um intervalo de tempo T.

Hardware fiável é um componente de uma solução de alta disponibilidade. Software fiável, incluindo bases de dados, servidores Web e aplicações, é também crucial para implementar uma solução de alta disponibilidade. Uma característica relacionada com isto é a resiliência. Por exemplo, hardware de baixo custo, combinado com bom software, pode ser usado para implementar um sistema muito fiável, pois o software permite continuar o processamento de dados apesar de falhas em servidores individuais.

Fiabilidade não mede paragens, planeadas ou não; os valores de MTTR não influenciam a fiabilidade, esta é frequentemente expressa como em termos de MTBF.

Valores de fiabilidade ajudam a prevenir e detectar falhas. Este último é muito importante, mesmo que muitas vezes é ignorado; o pior desempenho de um sistema é continuar depois de uma falha e criar resultados errados ou dados corrompidos!

À semelhança do que foi feito para a disponibilidade, olhando para a fiabilidade do ponto de vista matemático podemos afirmar que a fiabilidade é a probabilidade de sobrevivência (ou ausência de falhas) num determinado período de tempo ou, ao número de dispositivos que não falhará nesse mesmo período de tempo. Fiabilidade anual será a probabilidade de sobrevivência num ano.

Disponibilidade versus Fiabilidade

Um avião precisa ser fiável, mas para isso não precisa estar disponível para voar 24 horas por dia, porém, deve ser de confiança quando o utilizador determina deve estar disponível;

Fiabilidade implica que o sistema executa a sua tarefa especificada correctamente;
A disponibilidade significa que o sistema está pronto para uso imediato por exemplo, das 9 às 5, 24x7, etc
As redes de hoje precisam estar disponíveis 24 horas por dia, 7 dias por semana, 365 dias por ano; elas precisam de alta disponibilidade.

A fiabilidade é uma “probabilidade de engenharia” de que os serviços estejam disponíveis.
A disponibilidade medida é o produto resultante de medições físicas executadas ao longo do tempo sobre um sistema de engenharia.

Crescimento da Fiabilidade

Crescimento da fiabilidade é definido como a melhoria contínua da fiabilidade nos sistemas. É geralmente medida e alcançada pelo aumento no intervalo entre as sucessivas falhas.

Recuperabilidade

Porque pode haver muitas opções para recuperação de uma falha, é importante determinar quais os tipos de falhas que podem ocorrer no seu ambiente de alta disponibilidade e como recuperar dessas falhas em tempo útil que atenda às necessidades do seu negócio. Por exemplo, se uma tabela crítica é acidentalmente apagada da base de dados, que medidas devem ser tomadas para recuperá-la? A sua arquitectura oferece a possibilidade de se recuperar no tempo especificado no acordo de nível de serviço (SLA)?

Tempo Médio de Recuperação

O Tempo Médio de Recuperação (Mean Time to Recovery – MTTR) é uma medida estatística que indica o tempo médio que leva para se recuperar de uma falha. Quanto menor o MTTR, melhor. Sistemas de auto-recuperáveis podem recuperar de um erro de software dentro de segundos. Uma catástrofe como um terramoto ou um incêndio podem desligar os sistemas definitivamente. Ter um plano de recuperação de desastres é essencial para lidar com este tipo de evento catastrófico. A manutenção de um conjunto de peças de reposição no local e tendo frequentes backups completos irá diminuir o MTTR.

Objectivo para Tempo de Recuperação

O Objectivo para Tempo de Recuperação (Recovery Time Objective - RTO) é o período de tempo após o desastre em que as funções do negócio têm que ser restauradas a fim de evitar consequências inaceitáveis associadas com uma quebra na continuidade do negócio, isto é, o tempo que decorre entre a perda de acesso aos dados e recuperação do acesso aos mesmos. Por outras palavras, é o duração máximo de tempo tolerável que um computador, sistema, rede ou aplicação pode estar em baixo após uma falha ou catástrofe.

Funções empresariais diferentes podem ter diferentes tempos de recuperação. Por exemplo, o RTO para a função de processamento de vencimentos ser de duas semanas, enquanto que o RTO para o processamento das vendas e pedidos pode ser de apenas dois dias.

O RTO (por vezes também referido como Máxima Paragem Permitida) é uma função da medida em que a interrupção perturba o funcionamento normal e da perda de receita por unidade de tempo como resultado do desastre. O RTO é medido em segundos, minutos, horas ou dias, incluindo o tempo para tentar corrigir o problema sem recuperação, a recuperação em si, os testes e a comunicação com os utilizadores e é uma consideração importante no planeamento de Recuperação de Desastres. Quanto menor o RTO, o melhor.

Objectivo para Ponto de Recuperação

O Objectivo para Ponto de Recuperação (Recovery Point Objective - RPO), de certa forma exprime a quantidade de dados que uma empresa se pode dar ao luxo de perder em caso de catástrofe, no sentido de em é o momento em que o último backup de dados ocorreu. Por isso, é geralmente a definição daquilo que uma organização considera ser "perda aceitável" numa situação de desastre.

O RPO é a idade dos arquivos que têm que ser recuperados a partir de armazenamento de backup para o reinício das operações normais no caso de um sistema, computador ou a rede forem abaixo como resultado de uma falha no hardware, num programa ou de comunicação.

O RPO é expresso para trás no tempo (isto é, para o passado) a partir do instante em que a falha ocorre, e pode ser especificado em segundos, minutos, horas ou dias. Também é uma consideração muito importante no planeamento de Recuperação de Desastres.

Objectivo para a Recuperação do Acesso

O Objectivo para a Recuperação do Acesso (Recovery Access Objective - RAO) é uma parte do RTO, que mede o tempo que a rede demora a restabelecer a ligação dos utilizadores, clientes e parceiros com as aplicações no site alternativo uma vez que a do sítio primário foi interrompida. O RAO identifica o momento em que os utilizadores que estavam ligados a aplicações e serviços em execução num centro de dados têm acesso às mesmas aplicações e serviços em execução num centro de dados alternativo. O RAO será tipicamente menor que o RTO para qualquer aplicação, de modo a que uma aplicação recuperada não esteja à espera de acesso à rede a fim de retomar a prestação de serviços aos utilizadores.

Objectivo para a Recuperação de Rede

Muito semelhante ao RAO, o Objectivo para a Recuperação de Rede (Network Recovery Objective - NRO) indica o tempo necessário para recuperar as operações de rede. A recuperação do sistemas não estará completa se os clientes não puderem aceder aos serviços das aplicações através da rede. Assim, o NRO inclui o tempo necessário para colocar as linhas de comunicação alternativas, re-configurar os routers e servidores de nomes (DNS) e alterar os parâmetros do sistema de cliente para endereços TCP/IP alternativos. O planeamento cuidado das respostas a dar em caso de falhas da rede é de grande importância para a recuperação de dados num cenário de desastre.

Máximo Tolerável de Inactividade

O Máximo Tolerável de Inactividade (Maximum Tolerable Downtime - MTD) é o tempo após o qual a indisponíbilidade dos serviços cria danos irreversíveis. É a duração de tempo máxima que uma função de negócios pode ser interrompido sem provocar danos irreparáveis à empresa. Dependendo do processo, o MTD pode ser expresso em horas, dias ou mesmo semanas. Funções do negócio associadas ao serviço a clientes e facturação têm muitas vezes os mais baixos valores de MTD. Um termo similar e talvez mais padronizado é o Período Máximo Tolerável de Disrupção (Maximum Tolerable Period of Disruption - MTPD).

Tempo de Trabalho de Recuperação

O trabalho de recuperação Time (Work Recovery Time - WRT) é o resto do MTD usado para restaurar todas as operações comerciais. Normalmente, o RTO é utilizado para cuidar da infra-estrutura, enquanto o WRT é usado para garantir recuperação de dados, processos de teste e verificação.

Manutenção

Manutenção é uma medida que expressa a facilidade com que um sistema é mantido ou reparado. Por exemplo, um sistema com componentes modulares, hot-swappable, teria um bom nível de operacionalidade. Ela pode ser expressa como a quantidade inverso do tempo de manutenção e do número de acidentes durante o ciclo de vida completo de um sistema. Por exemplo, o serviço de 1,5 h em 720 horas de tempo decorrido (720 h é cerca de 1 mês). Como tal, esta grande grandeza mede o trabalho de sustentação que deve ser colocado num sistema e por quanto tempo demora a recuperá-lo uma vez em baixo. Como a disponibilidade, existem duas medidas que são de interesse: manutenção planeada e real.

Cluster

Um cluster é um conjunto de duas ou mais máquinas chamados de nós ligados entre si para aparecer como um. Todos os nós do cluster compartilham "discos comuns" chamados "discos partilhados", que contêm as bases de dados e aplicações para além dos discos locais próprios. Os discos locais contêm os SO e outros dados importantes para eles. São também constituídos pelos seus próprios recursos, como CPUs, memória e controladores de disco, etc.

Esta é a situação mais típica mas vejamos quais são o três principais tipos de clusters:

Os Failover Clusters são implementados tendo nós redundantes que são então utilizados para garantir o serviço quando os componentes, ou mesmo um dos nós, falham;
Network Load Balancing cluster é quando vários computadores estão ligados entre si para responder, como um único computador virtual, a um elevado número de solicitações de rede. Isso resulta em trabalho computacional equilibrado entre diferentes máquinas, melhorando o desempenho dos sistemas de cluster;
Clusters de computação são utilizados principalmente para fins computacionais, ao invés de lidar com operações de entrada e saída, como serviços web ou bases de dados. Vários computadores estão ligados entre si para compartilhar a carga de trabalho computacional ou funcionar como um único computador virtual.