Medida da disponibilidade
A necessidade de disponibilidade é regida pelos objectivos do negócio e os principais objectivos da sua quantificação são os seguintes:
- Fornecer e manter um referencial de disponibilidade (baseline);
- Ajudar a identificar onde melhorar os sistemas;
- Monitorizar e controlar projectos de melhoria.
A evolução tecnológica dos últimos anos tornou possível que a maioria dos sistemas possa atingir 90% de disponibilidade com pouco mais que alguma redundância e disciplina no departamento de TI, em vez de qualquer hardware ou software específicos para atingir esse objectivo. Porém, para atingir mais de 90% de disponibilidade do sistema, há que ter em conta algumas considerações especiais e nós vamos olhar para isso nos próximos posts.
É importante reconhecer que números como estes podem ser difíceis de alcançar uma vez que é necessário algum tempo para a recuperação de interrupções. A duração do tempo de recuperação correlaciona-se com os seguintes factores:
- Complexidade do sistema: Quanto mais complicado for o sistema, mais tempo levará a ser reiniciado o que significa que as interrupções que exigem desligar e reiniciar o sistema podem afectar drasticamente a sua capacidade de atingir uma desafiadora meta de disponibilidade. Por exemplo, aplicações a ser executadas num servidor de grande porte podem demorar até uma hora só para reiniciar quando o sistema foi desligado normalmente, e mais ainda se o sistema foi encerrado de forma anormal e houver necessidade de recuperar dados e ficheiros;
- Gravidade do problema: Geralmente, quanto maior a gravidade do problema, mais tempo é necessário para resolvê-lo totalmente, incluindo a recuperação de dados ou trabalho perdidos;
- Disponibilidade de pessoal de apoio: Consideremos que a interrupção ocorre após o expediente. Uma pessoa de apoio que seja chamada fora de horas poderá facilmente demorar uma ou duas horas só para diagnosticar o problema;
- Outros factores: Muitos outros factores podem impedir a resolução imediata de uma interrupção. Às vezes, uma aplicação pode sofrer uma interrupção simplesmente porque não suporta que o sistema seja desligado enquanto está a ser executada. Outros casos podem envolver a falta de hardware de substituição pelo fornecedor do sistema, ou mesmo a falta de pessoal de apoio.
Parâmetros da Disponibilidade
- Tempo Médio para Reparação (MTTR)
- Defeitos por Milhão (DPM)
- Tempo Médio entre Falhas (MTBF)
- Desempenho (por exemplo, latência, quebras de serviço)
A disponibilidade é geralmente expressa como uma percentagem de tempo de actividade num determinado ano. A tabela a seguir mostra o tempo de inactividade que será permitido para uma determinada percentagem de disponibilidade, partindo do pressuposto que o sistema opera continuamente. Os níveis de serviço acordados referem-se geralmente aos tempos de inactividade ou disponibilidade mensais de modo a calcular os créditos de serviço para combinar com os ciclos de facturação mensal. A tabela mostra a equivalência entre uma dada percentagem de disponibilidade e o correspondente tempo que um sistema estaria disponível por ano, mês ou semana.
O principal objectivo na criação de qualquer estratégia de Alta Disponibilidade (AD) e Recuperação de Desastres (RD) é garantir a continuidade do negócio (Business Continuity). Cada empresa tem o seu próprio nível de tolerância a falhas do sistema e interrupções de serviço e é exactamente em função dessa mesma tolerância que pode ser planeada e implementada uma estratégia adequada. Se uma empresa pode aceitar uma disponibilidade do sistema de 90%, então não há necessidade de construir uma infra-estrutura de alta disponibilidade.
Embora as soluções de AD sejam mais frequentemente discutidas em ambientes empresariais, estas considerações aplicam-se a qualquer tipo de organização em que a AD seja necessária, independentemente de ser na área educacional, sem fins lucrativos ou mesmo no âmbito da defesa. Quando se trata de organizações sem uma perspectiva comercial, não é muito fácil calcular os custos associados à inactividade e assim os sistemas de AD e RD nestas organizações tornam-se mais uma exigência do ponto de vista do serviço sem estarem necessariamente relacionados com custos associados à inactividade.
A disponibilidade dos sistemas deve ser vista sob a perspectiva do utilizador final. Cada vez que um utilizador não se conseguir ligar ao sistema é considerado como tempo de inactividade mas isto não significa necessariamente que o servidor central está em baixo porque, em muitos casos, um sistema com muito baixo desempenho também é considerado um sistema indisponível.
Assim, alta disponibilidade não implica apenas criar redundância num único sistema, base de dados ou aplicação, mas sim combinar várias redundâncias em todas as áreas do processo. Para cada negócio ou organização, as bases de dados têm um papel importante, tudo é construído em torno delas, portanto, a maioria dos esforços para alta disponibilidade estão orientados de forma a tornar a base de dados "altamente disponível."
Mais especificamente, uma arquitectura de alta disponibilidade deve ter as seguintes características:
- Tolerar falhas para que o processamento continue ininterruptamente ou apenas com interrupções mínimas;
- Ser transparente ou tolerante a alterações de sistema, dados ou aplicações;
- Conter medidas preventivas embebidas na própria arquitectura;
- Proporcionar monitorização proactiva e rápida detecção de falhas;
- Possibilitar recuperabilidade rápida;
- Automatizar operações de detecção e recuperação;
- Proteja os dados de modo a minimizar ou anular completamente a perda de dados;
- Implementar as melhores práticas operacionais para a gestão de toda a infra-estrutura;
- Alcançar os objectivos estabelecidos nos níveis de serviço estabelecidos (por exemplo, o RTO e o RPO) pelo menor custo possível.
Os projectistas de sistemas habitualmente introduzem fiabilidade nas suas arquitecturas através da implementação de mecanismos de correcção para os defeitos latentes que os preocupam. Estes defeitos, quando corrigíveis, não produzem erros ou falhas, uma vez que fazem parte das margens de segurança incorporadas no sistema. Ainda assim, devem ser monitorizados para medir a sua ocorrência real em relação aquilo que foi antecipado, uma vez que a ocorrência excessiva de alguns defeitos corrigíveis é frequentemente um indicador de um defeito latente potencialmente mais catastrófico.
Fiabilidade, recuperabilidade, detecção atempada de erros e a capacidade de operação contínua são as principais características de uma solução altamente disponível.
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.
