Tempo de atividade de 100% para um aplicativo Web

Recebemos um "requisito" interessante de um cliente hoje.

Eles querem 100% de tempo de atividade com off-site failover em uma aplicação web. Do ponto de vista de nosso aplicativo Web, isso não é um problema. Ele foi projetado para poder expandir em vários servidores de banco de dados, etc.

No entanto, a partir de um problema de rede, simplesmente não consigo descobrir como fazê-lo funcionar.

Em poucas palavras, o aplicativo permanecerá em servidores na rede do cliente. É acessado por pessoas internas e externas. Eles querem que mantenhamos uma cópia externa do sistema que, no caso de uma falha grave em suas instalações, seria imediatamente retomada e assumida.

Agora sabemos que não há absolutamente nenhuma maneira de resolvê-lo para pessoas internas (pombo-correio?), Mas eles querem que os usuários externos nem notem.

Francamente, não tenho a menor idéia de como isso pode ser possível. Parece que se eles perderem a conectividade com a Internet, teríamos que fazer uma alteração no DNS para encaminhar o tráfego para as máquinas externas ... O que, é claro, leva tempo.

Idéias?

ATUALIZAR

Eu tive uma discussão com o cliente hoje e eles esclareceram sobre o assunto.

Eles mantiveram o número de 100%, dizendo que o aplicativo deve permanecer ativo mesmo em caso de inundação. No entanto, esse requisito só entra em ação se o hospedarmos para eles. Eles disseram que atenderiam ao requisito de tempo de atividade se o aplicativo residisse inteiramente em seus servidores. Você pode adivinhar minha resposta.

Aqui está o útil mapa da Wikipedia sobre a busca de nove:

Curiosamente, apenas três dos 20 principais sites foram capazes de atingir os 5 noves míticos ou 99,999% de tempo de atividade em 2007. Eles eram Yahoo, AOL e Comcast. Nos primeiros 4 meses de 2008, algumas das redes sociais mais populares nem chegaram perto disso.

A partir do gráfico, deve ser evidente o quão ridícula é a busca de 100% de tempo de atividade ...

Peça-lhes para definir 100% e como será medido. Em que período de tempo. Eles provavelmente significam o mais próximo de 100% possível. Dê-lhes os custos.

Para elaborar. Estive em discussões com clientes ao longo dos anos com requisitos supostamente ridículos. Em todos os casos, eles usavam apenas linguagem não precisa o suficiente.

Muitas vezes, eles estruturam as coisas de maneira que parecem absolutas - como 100%, mas, na realidade, em investigações mais aprofundadas, são razoáveis ​​o suficiente para fazer as análises de custo / benefício necessárias quando apresentadas com custos para dados de mitigação de riscos. Perguntar a eles como medirão a disponibilidade é uma questão crucial. Se eles não souberem disso, você poderá sugerir a eles que isso precisa ser definido primeiro.

Eu pediria ao cliente para definir o que aconteceria em termos de impacto / custos nos negócios se o site fosse desativado nas seguintes circunstâncias:

• Nas horas mais movimentadas por x horas
• No horário menos ocupado por x horas

E também como eles vão medir isso.

Dessa forma, você pode trabalhar com eles para determinar o nível certo de '100%'. Eu suspeito que, ao fazer esse tipo de pergunta, eles serão capazes de determinar melhor as prioridades de seus outros requisitos. Por exemplo, eles podem querer pagar certos níveis de SLA e comprometer outras funcionalidades para conseguir isso.

Seus clientes são loucos. O tempo de atividade de 100% é impossível, não importa quanto dinheiro você gaste nele. Puro e simples - impossível. Veja o Google, a Amazon etc. Eles têm quantias quase infinitas de dinheiro para investir em sua infraestrutura e, no entanto, ainda conseguem tempo de inatividade. Você precisa entregar essa mensagem a eles e se eles continuarem insistindo em oferecer demandas razoáveis. Se eles não reconhecerem que uma certa quantidade de tempo de inatividade é inevitável, evite-os.

Dito isto, você parece ter a mecânica de dimensionar / distribuir o próprio aplicativo. A parte da rede precisará envolver uplinks redundantes para diferentes ISPs, obtendo uma alocação de ASN e IP e aprofundando o BGP e o equipamento de roteamento real, para que o espaço de endereço IP possa se mover entre os ISPs, se necessário.

Esta é, obviamente, uma resposta muito concisa. Você não teve experiência com aplicativos que exigem esse nível de tempo de atividade; portanto, você realmente precisa envolver um profissional se quiser chegar perto do mítico tempo de atividade de 100%.

Bem, isso é definitivamente interessante. Não tenho certeza se gostaria de me comprometer contratualmente a 100% de tempo de atividade, mas, se precisasse, acho que ficaria assim:

Comece com o IP público em um balanceador de carga completamente fora da rede e construa pelo menos dois deles para que um possa fazer failover no outro. Um programa como o Heatbeart pode ajudar com o failover automático deles.

O verniz é conhecido principalmente como uma solução de cache, mas também faz um balanceamento de carga bastante decente. Talvez essa seja uma boa opção para lidar com o balanceamento de carga. Ele pode ser configurado para ter 1 a n back-end opcionalmente agrupados em diretores que carregarão o saldo aleatoriamente ou round-robin. O verniz pode ser inteligente o suficiente para verificar a integridade de todos os back-ends e remover back-ends não saudáveis ​​do circuito até que volte a ficar on-line. Os back-end não precisam estar na mesma rede.

Atualmente, estou apaixonada pelos IPs elásticos no Amazon EC2, então provavelmente criaria meus balanceadores de carga no EC2 em diferentes regiões ou pelo menos em diferentes zonas de disponibilidade na mesma região. Isso daria a você a opção de ativar manualmente (Deus não permita) ativar um novo balanceador de carga, se necessário, e mover o IP de registro A existente para a nova caixa.

No entanto, o verniz não pode finalizar o SSL, por isso, se isso for uma preocupação, você pode procurar algo como o Nginx.

Você pode ter a maioria dos seus back-end na rede de seus clientes e um ou mais fora da rede deles. Acredito, mas não tenho 100% de certeza, que você pode priorizar os back-ends para que as máquinas de seus clientes tenham prioridade até que todas elas se tornem prejudiciais.

É aí que eu começaria se tivesse essa tarefa e, sem dúvida, a refinasse à medida que prosseguisse.

No entanto, como afirma o @ErikA, é a Internet e sempre haverá partes da rede que estão fora do seu controle. Você deseja garantir que seu departamento jurídico o vincule apenas a coisas que estão sob seu controle.

Não há problema - embora a redação do contrato seja ligeiramente revisada:

... garante um tempo de atividade de 100% (arredondado para zero casas decimais).

Se o Facebook e a Amazon não conseguem, você não pode. É simples assim.

Para adicionar a resposta do oconnore do Hacker News

Não entendo qual é o problema. O cliente quer que você planeje um desastre, e eles não são orientados para a matemática, portanto, pedir 100% de probabilidade parece razoável. O engenheiro, como os engenheiros costumam fazer, lembrou-se de seu primeiro dia de prob & stat 101, sem considerar que o cliente talvez não. Quando dizem isso, não estão pensando no inverno nuclear, estão pensando em Fred despejando seu café no servidor do escritório, em um disco travando ou em um ISP caindo. Além disso, você pode conseguir isso. Com servidores de auto-monitoramento geograficamente distintos e independentes, você basicamente não terá tempo de inatividade. Com três servidores operando com uma confiabilidade independente (1) três 9, com bons modos de failover, o tempo de inatividade esperado é inferior a um segundo por ano (2). Mesmo que isso aconteça de uma só vez, você ainda está dentro de um SLA razoável para conexões da Web e, portanto, o tempo de inatividade praticamente não existe. O cliente ainda precisa lidar com os cenários do dia do juízo final, mas Godzilla excluiu, ele terá um serviço que está "sempre" ativo.

(1) Um servidor em LA é razoavelmente independente do servidor em Boston, mas sim, eu entendo que há alguma interseção envolvendo guerra nuclear, hackers chineses travando a rede elétrica etc. Não acho que seu cliente ficará chateado com esta.

(2) O failover de DNS pode adicionar alguns segundos. Você ainda está em um cenário em que o cliente precisa repetir uma solicitação uma vez por ano, que está novamente dentro de um SLA razoável e normalmente não é considerado da mesma maneira que o "tempo de inatividade". Com um aplicativo que redireciona automaticamente para um nó disponível em caso de falha, isso pode ser imperceptível.

Você está sendo solicitado por algo impossível.

Revise as outras respostas aqui, sente-se com seu cliente e explique POR QUE é impossível e avalie a resposta delas.

Se eles ainda insistirem em 100% de tempo de atividade, informe-os educadamente que isso não pode ser feito e recuse o contrato. Você nunca atenderá à demanda deles e, se o contrato não for totalmente ruim, você será penalizado.

Preço em conformidade e, em seguida, estipular no contrato que qualquer tempo de inatividade após o SLA será reembolsado à taxa que eles estão pagando.

O ISP no meu último trabalho fez isso. Tivemos a opção de uma linha DSL "regular" com 99,9% de tempo de atividade por US $ 40 / mês ou um trio de T1s ligados com 99,99% de tempo de atividade por US $ 1100 / mês. Houve interrupções freqüentes de mais de 10 horas por mês, o que elevou o tempo de atividade abaixo da DSL de US $ 40 / mês, mas só fomos reembolsados ​​em torno de US $ 15 ou mais, porque é assim que a taxa por hora * hora termina. Eles se divertiram como bandidos do acordo.

Se você faturar US $ 450.000 por mês pelo tempo de atividade de 100% e atingir apenas 99,999%, precisará reembolsar US $ 324. Estou disposto a apostar que os custos de infraestrutura para atingir 99,999% estão em torno de US $ 45.000 por mês, assumindo colos totalmente distribuídos, vários uplinks de nível 1, hardware de fantasia, etc.

Se os profissionais questionarem se 99,999% da disponibilidade [é] uma possibilidade prática ou financeiramente viável , a disponibilidade de 99,9999% é ainda menos possível ou prática. Muito menos 100%.

Você não atingirá a meta de disponibilidade de 100% por um longo período de tempo. Você pode se safar por uma semana ou um ano, mas então algo acontecerá e você será responsabilizado. O problema pode variar de reputação prejudicada (você prometeu e não entregou) a falência e multas contratuais.

Existem dois tipos de pessoas que solicitam 100% de tempo de atividade:

1. Pessoas com absolutamente nenhum conhecimento sobre computadores, sistemas de computador ou Internet. *
2. Aqueles que estão intencionalmente se convencendo, ou para testar sua capacidade de dizer Não (Google "o Teste de Suco de Laranja"), ou tentando obter algum tipo de alavancagem contratual do SLA para não pagar mais tarde.

Meu conselho, tendo sofrido esses dois tipos de clientes em muitas ocasiões, é não aceitar esse cliente. Deixe-os deixar alguém mais louco.

* Essa mesma pessoa pode não ter vergonha de perguntar sobre viagens mais rápidas que a luz, movimento perpétuo, fusão a frio etc.

Eu me comunicava com o cliente para estabelecer com eles o que exatamente 100% do tempo de atividade significa. É possível que eles realmente não vejam uma distinção entre 99% de tempo de atividade e 100% de tempo de atividade. Para a maioria das pessoas (ou seja, não administradores de servidor), esses dois números são iguais.

100% de tempo de atividade?

Aqui está o que você precisa:

Vários servidores DNS (e redundantes), apontando para vários sites em todo o mundo, com SLAs adequados para cada ISP.

Verifique se os servidores DNS estão configurados corretamente, com o TTL reconhecido de maneira eficaz.

Isso é facil. O Amazon EC2 SLA afirma claramente:

“Porcentagem anual de tempo de atividade” é calculada subtraindo de 100% a porcentagem de períodos de 5 minutos durante o ano de serviço em que o Amazon EC2 estava no estado de “Região não disponível”.

http://aws.amazon.com/ec2-sla/

Basta definir 'tempo de atividade' para ser relativo a todo o pacote de serviços. Você pode realmente manter a operação 100% do tempo e não deve ter problemas.

Além disso, vale ressaltar que o objetivo de um SLA é definir quais são suas obrigações e o que acontece se você não puder cumpri-las. Não importa se o cliente pede 3 noves, 5 noves ou um milhão de noves - a questão é o que eles recebem quando / se você não pode entregar. A resposta óbvia é fornecer um item de linha com tempo de atividade 100% a 5x o preço que você deseja cobrar e, em seguida, eles receberão um reembolso de 4x se você atingir essa meta. Você pode marcar!

As alterações no DNS demoram apenas se estiverem configuradas para demorar. Você pode definir o TTL em um registro como um segundo - seu único problema seria garantir que você forneça uma resposta oportuna às consultas DNS e que os servidores DNS possam lidar com esse nível de consultas.

É exatamente assim que o GTM funciona no F5 Big IP - o DNS TTL por padrão é definido como 30 segundos e, se um membro do cluster precisar assumir, o DNS é atualizado e o novo IP é adotado quase imediatamente. Máximo de 30 segundos de interrupção, mas esse é o caso extremo, a média seria de 15 segundos.

Você sabe que isso é impossível.

Sem dúvida, o cliente está focado em ver "100%", então o melhor que você pode fazer é prometer 100%, exceto por [todas as causas razoáveis ​​que não são sua culpa].

Embora eu duvide que 100% seja possível, você pode considerar o Azure (ou algo com um SLA semelhante) como uma possibilidade. O que acontece:

Seus servidores são máquinas virtuais. Se houver algum problema de hardware em um servidor, sua máquina virtual será movida para uma nova máquina. O balanceador de carga cuida do redirecionamento para que o cliente não veja nenhum tempo de inatividade (embora não tenha certeza de como o estado das suas sessões seria afetado).

Dito isto, mesmo com esse failover, a diferença entre 99,999 e 100 faz fronteira com a insanidade.

Você precisará ter controle total sobre os seguintes fatores.
- Fatores humanos, internos e externos, malícia e impotência. Um exemplo disso é alguém enviando algo para o código de produção que derruba um servidor. Pior ainda, e a sabotagem?
- questões de negócios. E se o seu fornecedor perder o interesse ou esquecer de pagar as contas de energia elétrica, ou simplesmente decidir parar de dar suporte à sua infraestrutura sem aviso suficiente?
Natureza. E se tornados não relacionados atingirem simultaneamente data centers suficientes para sobrecarregar a capacidade de backup?
- Um ambiente completamente livre de erros. Você tem certeza de que não há um caso de ponta com algum controle de terceiros ou do sistema principal que não se manifestou, mas que ainda pode fazê-lo no futuro?
- Mesmo se você tiver total controle sobre os fatores acima, tem certeza de que o software / pessoa que monitora isso não apresentará falsos negativos ao verificar se o seu sistema está funcionando?

Honestamente, 100% é completamente insano, sem pelo menos vacilar nos termos de um ataque de hackers. Sua melhor aposta é fazer o que o Google e a Amazon fazem, pois você tem uma solução de hospedagem distribuída geograficamente, onde seu site e banco de dados são replicados em vários servidores em vários locais geográficos. Isso garantirá tudo, exceto um grande desastre, como o backbone da Internet sendo cortado para uma região (o que acontece de tempos em tempos) ou algo quase apocalíptico.

Eu colocaria uma cláusula para esses casos (DDOS, corte na espinha dorsal da Internet, ataque terrorista apocalíptico ou uma grande guerra, etc.).

Fora isso, observe os serviços de nuvem Amazon S3 ou Rackspace. Essencialmente, a configuração da nuvem não oferecerá apenas a redundância em cada local, mas também a escalabilidade e a distribuição geográfica do tráfego, além da capacidade de redirecionar as falhas nas áreas geográficas. Embora eu entenda que a distribuição geográfica custa mais dinheiro.

Eu só queria adicionar outra voz à festa "isso pode (teoricamente) ser feito".

Eu não aceitaria um contrato que tivesse isso especificado, não importa quanto me pagassem, mas como um problema de pesquisa, ele tem algumas soluções bastante interessantes. Não estou familiarizado o suficiente com a rede para descrever as etapas, mas imagino que uma combinação de configurações relacionadas à rede + failovers de fiação elétrica / hardware + failovers de software funcionaria, possivelmente, em algumas configurações ou em outro trabalho para realmente executá-las.

Quase sempre há um único ponto de falha em algum lugar de qualquer configuração, mas se você trabalhar duro o suficiente, poderá empurrar esse ponto para algo que possa ser reparado "ao vivo" (ou seja, o DNS raiz diminui, mas os valores ainda estão em cache em qualquer outro lugar para que você tenha tempo para corrigi-lo).

Mais uma vez, não estou dizendo que é viável. Eu simplesmente não gostei de como uma única resposta não abordou o fato de que ela não está "lá fora" - não é algo que elas realmente querem se pensam nisso.

Repensar sua metodologia de medir a disponibilidade e trabalhar com seu cliente para definir metas significativas .

Se você estiver executando um site grande, o tempo de atividade não será útil. Se você interromper as consultas por 10 minutos quando seus clientes mais precisam (pico de tráfego), poderá ser mais prejudicial para os negócios do que uma interrupção de uma hora às 3 da manhã de um domingo.

Às vezes, grandes empresas da web medem a disponibilidade ou a confiabilidade usando as seguintes métricas:

1. porcentagem de consultas que foram respondidas com sucesso, sem erro do servidor (HTTP 500s).
2. porcentagem de consultas que são respondidas abaixo de uma certa latência de destino .
3. as consultas descartadas devem contar com suas estatísticas (veja abaixo).

A disponibilidade não deve ser medida usando testes de amostra, que é o que uma entidade externa, como pingdom e pingability, pode relatar. Não confie apenas nisso. Se você quiser fazer o certo, todas as consultas devem contar . Avalie sua disponibilidade observando seu sucesso real e percebido.

A maneira mais eficiente é coletar logs ou estatísticas do seu balanceador de carga e calcular a disponibilidade com base nas métricas acima.

A porcentagem de consultas eliminadas também deve contar com suas estatísticas. Ele pode ser contabilizado no mesmo intervalo que os erros do servidor. Se houver problemas com a rede ou com outra infraestrutura, como DNS ou balanceadores de carga, você pode usar matemática simples para estimar quantas consultas você perdeu . Se você esperava consultas X naquele dia da semana, mas recebeu o X-1000, provavelmente descartou 1000 consultas. Plote seu tráfego em gráficos de consultas por minuto (ou segundo). Se aparecerem lacunas, você eliminou as consultas. Use a geometria básica para medir a área dessas lacunas, o que fornece o número total de consultas eliminadas.

Discuta essa metodologia com seu cliente e explique seus benefícios. Defina uma linha de base medindo sua disponibilidade atual. Ficará claro para eles que 100% é um alvo impossível.

Em seguida, você pode assinar um contrato com base em melhorias na linha de base. Digamos, se eles estiverem com 95% de disponibilidade, prometa melhorar a situação dez vezes , chegando a 98,5%.

Nota: existem desvantagens nessa maneira de medir a disponibilidade. Primeiro, coletar logs, processar e gerar os relatórios você mesmo pode não ser trivial, a menos que você use as ferramentas existentes para fazer isso. Segundo, os erros do aplicativo podem prejudicar sua disponibilidade. Se o aplicativo for de baixa qualidade, ele fornecerá mais erros. A solução para isso é considerar apenas os 500s criados pelo balanceador de carga, em vez daqueles provenientes do aplicativo.

As coisas podem ficar um pouco complicadas dessa maneira, mas é um passo além de medir apenas o tempo de atividade do servidor .

Enquanto algumas pessoas observaram aqui, que 100% são loucos ou impossíveis , elas de alguma forma perderam o ponto real. Eles argumentaram que a razão para isso é o fato de que mesmo as melhores empresas / serviços não conseguem alcançá-lo.

Bem, é muito mais simples que isso. É matematicamente impossível .

Tudo tem uma probabilidade. Pode haver um terremoto simultâneo em todos os locais onde você armazena seus servidores, destruindo todos eles. Concordantemente, é uma probabilidade ridiculamente pequena, mas não é 0. Todos os seus provedores de Internet podem enfrentar um ataque terrorista / cibernético simultâneo. Novamente, não é muito provável, mas também não é zero. Tudo o que você fornece, você pode obter um cenário de probabilidade diferente de zero, que reduz todo o serviço. Por isso, seu tempo de atividade também não pode ser de 100%.

Vá pegar um livro sobre controle de qualidade de fabricação usando amostragem estatística. Uma discussão geral deste livro, cujos conceitos qualquer gerente teria sido exposto em um curso geral de estatística na faculdade, dita os custos de passar de 1 exceção em mil para 1 em dez mil a 1 em um milhão a 1 em um bilhão aumenta exponencialmente. Essencialmente, a capacidade de atingir 100% de tempo de atividade custaria uma quantia quase ilimitada de fundos, como a quantidade de combustível necessária para empurrar um objeto à velocidade da luz.

De uma perspectiva de engenharia de desempenho, eu rejeitaria o requisito como não testável e irracional, que essa expressão seja mais um desejo do que um requisito verdadeiro. Com as dependências de aplicativos que existem fora de qualquer aplicativo de rede, resolução de nomes, roteamento, defeitos propagados por componentes arquiteturais subjacentes ou ferramentas de desenvolvimento, torna-se uma impossibilidade prática que alguém garanta 100% de tempo de atividade.

Eu não acho que o cliente esteja realmente pedindo 100% de tempo de atividade ou mesmo 99,999% de tempo de atividade. Se você observar o que eles estão descrevendo, eles estão falando sobre continuar de onde pararam se um meteoro derrubar seu datacenter no local.

Se o requisito é que pessoas externas nem notem, quão drástico isso deve ser? Fazer uma solicitação do Ajax tentar novamente e mostrar um botão giratório por 30 segundos para o usuário final seria aceitável?

Esses são os tipos de coisas com os quais o cliente se importa. Se o cliente estivesse realmente pensando em SLAs precisos, saberia o suficiente para expressá-lo como 99,99 ou 99,999.

meus 2 centavos. Fui responsável por um site muito popular de uma empresa da Fortune-5 que publicaria anúncios para o super bowl. Eu tive que lidar com grandes picos no tráfego e a maneira que resolvi foi usar um serviço como o Akamai. Não trabalho para a Akamai, mas achei o serviço deles extremamente bom. Eles têm seu próprio sistema DNS mais inteligente, que sabe que um nó / host específico está sob carga pesada ou está inoperante e pode rotear o tráfego de acordo.

O mais interessante sobre o serviço deles era que eu realmente não precisava fazer nada muito complicado para replicar o conteúdo dos servidores do meu próprio data center para o data center deles. Além disso, sei que ao trabalhar com eles, eles fizeram uso pesado de servidores HTTP Apache.

Embora não tenha 100% de tempo de atividade, você pode considerar essas opções para dispersar o conteúdo em todo o mundo. Pelo que entendi, a Akamai também tinha a capacidade de localizar o significado do tráfego, se eu estivesse em Michigan, obtivesse conteúdo de um servidor de Michigan / Chicago e, se estivesse na Califórnia, supostamente obtivesse o conteúdo de um servidor baseado na Califórnia.

Em vez de failover externo, basta executar o aplicativo em dois locais simultaneamente, interno e externo. E sincronize os dois bancos de dados ... Se o interno diminuir, as pessoas internas ainda poderão trabalhar e as pessoas externas ainda poderão usar o aplicativo. Quando o interno voltar a ficar online, sincronize as alterações. Você pode ter duas entradas DNS para um nome de domínio ou mesmo um roteador de rede com round robin.

Para sites hospedados externamente, o mais próximo possível de obter 100% de tempo de atividade é hospedar seu site no Google App Engine e usar seu HRD (alto nível de replicação de replicação) , que replica automaticamente seus dados em pelo menos três data centers em tempo real. Da mesma forma, os servidores front-end do App Engine são dimensionados / replicados automaticamente para você.

No entanto, mesmo com todos os recursos do Google e a plataforma mais sofisticada do mundo, a garantia de tempo de atividade do App Engine SLA é de apenas "99,95% do tempo em qualquer mês do calendário".

Simples e direto: Anycast

http://en.wikipedia.org/wiki/Anycast

É isso que o cloudflare, o google e qualquer outra grande empresa usam para fazer redundância, baixa latência, cross-over / balanceamento continental.

Mas lembre-se de que é impossível ter 100% de tempo de atividade e que os custos variam de 99,999% a 99,9999% é MUITO maior.