O seu negócio depende de serviços na nuvem, bases de dados, servidores remotos ou dados armazenados de algum tipo?
Obviamente que sim.
Você está com medo constante de tempo de inatividade?
Obviamente que você está.
No nosso mercado 24 horas por dia, sempre ligado, sempre ligado, alguém está sempre acordado, o tempo de atividade é crítico. Simplificando, ficar escuro é mau para o negócio… e é inaceitável. É por isso que as soluções de engenharia de alta disponibilidade – como as oferecidas pela Liquid Web, e outras empresas modernas de alojamento web – são tão importantes. Desde infraestrutura de alta disponibilidade e bancos de dados SQL, até replicação redundante, logs de transações e a eliminação de pontos únicos de falha, um servidor web é tão bom quanto seus serviços de engenharia de alta disponibilidade (HA).
Sigamos que sua aplicação será hospedada em uma infraestrutura gerenciada tradicional.
Agora, vamos ver porque um servidor de alta disponibilidade é uma solução melhor.
Alta disponibilidade resumida
Quando se trata de HA, os três princípios da engenharia de confiabilidade devem ser considerados:
- Reduzir ou eliminar pontos únicos de falha.
- Em sistemas redundantes, certifique-se de que os pontos de cruzamento são confiáveis.
- O sistema em vigor deve detectar e reagir a falhas em tempo real.
Quando esses três princípios são implementados de forma confiável, uma redução significativa no tempo de inatividade é alcançada. Um servidor web de qualidade terá estes princípios em mente ao projetar seus serviços.
Reduzir pontos únicos de falha em um sistema HA significa redundância em dados virtuais, físicos, ou uma combinação dos dois. Uma estrutura HA terá um volume primário, e pelo menos um volume físico de backup. Uma configuração padrão é composta de dois volumes primários idênticos, com backup de dois volumes físicos DR:BD (Distributed Replicated Block Device), com backup de dois volumes virtuais DR:BD. Os volumes DR:BD executam replicação seletiva e síncrona de dados, o que significa que apenas os blocos de dados alterados (não o volume inteiro) são reescritos e com backup em tempo real.
DR:BD volumes acabam por reduzir os tempos de backup, pois requerem menos recursos computacionais de uma só vez. Cada camada de backup (dois volumes primários idênticos, dois volumes virtuais DR:BD idênticos, etc.) é armazenada em servidores físicos separados – alguns hosts farão o backup até mesmo em um servidor em um local remoto. Uma configuração com uma localização remota elimina outro ponto único de falha ao proteger seus dados de desastres naturais e outros problemas baseados em localização como quedas de energia e falhas de rede.
O que fazer com a base de dados
Em um sistema HA, é recomendado que sua base de dados SQL seja armazenada em um ambiente de servidor separado e redundante, uma vez que melhora o desempenho e reduz a sobrecarga no servidor primário. Um servidor SQL dedicado também trabalha com/encaminhar os princípios da engenharia de confiabilidade, pois foi especificamente projetado para alta disponibilidade, incluindo crossovers automatizados e confiáveis e detecção de falhas em tempo real.
SQL bancos de dados também criam logs incrementais de transações; outra proteção contra pontos únicos de falha. Os registros de transações registram cada mudança no banco de dados em intervalos definidos com a mesma freqüência de um minuto – o banco de dados SQL pode usar os registros de transações como um conjunto de dados, escrevendo para os servidores de backup em sua configuração HA.
Configuração padrão da Web para hospedagem de banco de dados SQL inclui um backup diário de todo o banco de dados e 24 horas de rollings de registros de transações por hora.
Monitorização para Failover
No centro da configuração do HA deve estar um sistema de monitorização que esteja constante e consistentemente atento à saúde dos servidores em cluster e que realize automaticamente failovers quando necessário. O subsistema de monitoramento mais popular em toda a indústria é o Heartbeat. O Heartbeat é um monitor baseado em Linux que pode suportar vários nós de forma confiável. O Heartbeat pode identificar rápida e precisamente falhas críticas e fazer a transição automática do sistema para um servidor redundante.
Como você pode ver, cada parte do sistema HA trabalha com/encaminhar mais de um dos três princípios da engenharia de alta disponibilidade. Os nós de dados redundantes (físicos e virtuais) reduzem pontos únicos de falha e criam pontos cruzados confiáveis.
Um servidor SQL dedicado cria outra camada de redundância, outra proteção contra pontos únicos de falha, e tem embutidos pontos cruzados automatizados.
Finalmente, o Heartbeat está no centro de toda a configuração, monitorando o sistema em tempo real e automatizando crossovers quando necessário.
Com um sistema HA de qualidade instalado, o tempo de inatividade é reduzido ou praticamente eliminado, mantendo o seu negócio ligado e operacional o dia todo, todos os dias.