Tempo de atividade de 100% para um aplicativo Web

312

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.

Eu não
fonte
49
Não subestime o enorme tempo de inatividade causado por hackers, veja a Sony e a rede PlayStation. você pode garantir que eles tenham a mesma ideia de tempo de atividade de 100% e o dinheiro / hardware para fazer o backup. deixar claro para o cliente que 100% do tempo de atividade é uma expectativa inviável, mesmo os técnicos do Google hesitariam em murmurar "100% do tempo de atividade". uma dica é procurar usar o DNS dinâmico, eles ficam em cache por 60 segundos, isso deve incluir o SO e os servidores DNS locais.
Silverfire
182
Eu pessoalmente executaria esse cliente o mais rápido possível. Eu suspeito que essa não seja a última ideia maluca que eles possam ter (do ponto de vista da tecnologia).
precisa saber é o seguinte
137
Eu gostaria de poder diminuir o voto do seu cliente.
Joeqwerty
81
Se você descobrir 100% de tempo de atividade, me avise. Vou criar um negócio com ele e vendê-lo para o Google. É impossível garantir 100%. Mesmo empresas como a microsoft, amazon ou google não vão tão alto porque sabem que é impossível. O melhor que eu já vi é 99.999% e até isso é um alongamento (5 minutos em um ano). O melhor que você provavelmente poderia fazer é 99,99% confiável.
Matt
39
Basta criar um preço incrivelmente alto para fazer seu pedido insano. Isso provavelmente os trará de volta aos seus sentidos. Ou então, ou irá enviá-los à procura de alguém disposto a mentir para eles.
Nate CK

Respostas:

368

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

insira a descrição da imagem aqui

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 ...

GregD
fonte
62
Pingdom também não está verificando a cada segundo. Além disso, os que atingiram cinco noves provavelmente ainda tinham interrupções localizadas que Pingdom pode não ter detectado ou falhas que tornavam alguns serviços indisponíveis enquanto respondiam a pings.
ceejayoz
8
O que, por si só, torna os cinco noves duvidosos ...
GregD
5
Precisamente. E eles têm US $ bilhões para trabalhar!
ceejayoz
43
Desculpe atrapalhar o bate-papo, mas a pergunta do OP era como prosseguir em direção à meta de 100% de tempo de atividade em um nível técnico, não conceitualmente, tenho certeza de que ele sabe que nem sempre é possível por causa de ocorrências naturais que acontecem com o hardware e o meio ambiente. Podemos ajudá-lo com isso?
David d C e Freitas
5
Para o OP: vi SLAs que garantiam o tempo de atividade no contexto de "fora da manutenção normal". A manutenção normal do curso está sendo programada por um tempo de inatividade por mês para atualizações, patches, etc., que geralmente ocorrem no dia menos movimentado do mês durante os períodos menos movimentados do mês (geralmente no meio da noite). Eles devem ter algum tipo de métrica para seus negócios em relação aos negócios. Você poderia oferecer um tempo de atividade melhor (4 noves) para eles apenas durante esse período.
precisa saber é o seguinte
186

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.

Preet Sangha
fonte
21
Acordado. Eles podem significar apenas tempo de atividade "muito alto" (anos 90?) Com uma estratégia de failover bastante sólida. Se não, então uma explicação da escala custo envolvido seria espero convencê-los ...
Martin Dow
32
+1 por não tirar conclusões precipitadas e apenas pedir ao cliente que explique o que ele tem em mente.
sleske
4
Repito a declaração "não tire conclusões precipitadas" ... se o cliente significa 100% de tempo de atividade (menos manutenção programada), pode ser um requisito mais razoável.
Tim Reddy
1
Com relação ao impacto nos negócios, na verdade conhecemos e entendemos completamente os negócios e os custos envolvidos para a queda do site não são financeiros. Mais na linha dos nativos aparecendo com forcados, possíveis enforcamentos, etc.;) Imagine 40.000 pessoas aparecendo à sua porta gritando. É isso que eles querem evitar com paixão.
NotMe
7
@ Chrishrively Mais uma razão para ter uma compreensão madura dos riscos. O paradigma dominante para a engenharia de segurança é a avaliação probabilística de riscos . Existem sistemas que podem matar (não apenas irritar) milhares de pessoas e eles ainda têm uma probabilidade baixa, esperançosamente bem compreendida, mas diferente de zero de falha.
poolie 29/09/11
140

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%.

EEAA
fonte
7
Acordado. Totalmente. Louco.
JDW
2
Eles costumavam ??
Sirex 29/09
2
@Sirex Referindo-se ao experimento recente @ CERN, onde se descobriu que os neutrinos viajam mais rápido que a luz. Resultados ainda a serem confirmados por cientistas independentes.
TC1
9
@ TC1 Aposto que $ 200 que não dão certo.
dpatchery
4
@ErikA Uma solicitação de 100% de tempo de atividade é indicativa de desconhecimento das características técnicas dos sistemas. Tudo bem, porque o trabalho do cliente está fazendo o que ele faz. Seu trabalho é projetar sistemas de TI. Clientes difíceis como esse podem ser pesadelos, mas também podem se tornar seus melhores clientes.
precisa saber é o seguinte
54

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.

jdw
fonte
2
Por um tempo, eu estava pensando na Amazon e no MS para uma implantação na nuvem, mas os dois tiveram grandes interrupções nos últimos meses. SSL é crítico.
NotMe 29/09
3
Se você fosse usar a Amazon, com certeza gostaria de espalhar suas máquinas pelas 5 zonas de disponibilidade. É muito improvável que todas as suas zonas desapareçam ao mesmo tempo.
JDW
11
+1 para realmente abordar a questão principal do OP.
Phil
você sempre terá um ponto de falha, jdw, desde que haja algo não distribuído na cadeia (no seu caso, pulsação, a menos que você tenha várias instâncias em execução em máquinas remotas, todas monitorando uma à outra, bem como sua servidores, que algum deles pode ou não ver devido a problemas de rede ao longo do roteamento). O que nos leva ao "tempo de inatividade". Os servidores podem estar em funcionamento e ainda indisponíveis para o cliente sem que o batimento cardíaco o detecte se a falha não estiver no caminho de roteamento.
usar o seguinte comando
Acordado. Como TODOS já apontaram, não existe 100% de tempo de atividade. Tudo o que você pode fazer é tentar e o que descrevi é como começaria a tentar.
JDW
30

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).

Nick Pierpoint
fonte
2
+1 para anotar, que 100% não é 100,0% ou 100.000% etc. Os dígitos decimais assuntos, eles indicam precisão;)
Sailor Danubian
4
Por algumas convenções, "100%" possui apenas um número significativo, de modo que todos os números entre metade e um arredondariam para "100%"; 50% arredondaria para 100%.
Thomas Levine
1
Dependendo do padrão de contagem, alguns dirão que 50% tem dois números intermediários, onde 100% possui três números intermediários. 50,5 e 100 são igualmente precisos. Outros contarão dígitos após o ponto decimal. Então 50,5 e 100,4 serão igualmente precisos. Se nada mais dissesse, eu assumiria que 100% é de 99,5% ou mais. 100,0% é de 99,95% e até etc.
Tillebeck
26

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

Mike
fonte
17
ele poderia ser mais esperto do que todos os seus povos combinado, quem sabe: p
Matt
3
O tempo de atividade de 100% não precisa ser uma pessoa tão literal - significa: 100% disponível durante o tempo necessário. Por exemplo, os sistemas bancários devem estar sempre disponíveis e funcionam muito bem. Só porque eles ficam em manutenção por 1 segundo uma vez por ano não significa que eles falharam em sua meta de 100% de tempo de atividade.
David d C e Freitas
13
@DavidFreitas - Acho que em contratos geralmente é bastante literal ...
UpTheCreek
2
@ Matt apenas porque o Facebook / Amazon não pode fazê-lo, não significa que um site menor não possa fazê-lo. Muitos sites grandes enfrentam problemas muito mais difíceis de superar do que um site menor.
Xorlev 30/09/11
1
Então, o que você está dizendo é que você não tem 100% de uptime desde que você teve alguns clientes que tinham erros .. além de DNS não é um interruptor instantâneo desde que você tem ISPs que ignoram TTLs curto
Mike
25

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.

Caçador da selva
fonte
6
O problema é que eles estão dizendo isso em contrato. O que significa que se um desastre não ocorrer e você precisa de mais do que dez segundos para levar o site de volta on-line através de backups teriam legitimidade ativa.
Shadur 2/10/11
@Shadur: Se eles realmente querem, então você deve realmente cobrá-los. Espalhe os servidores geograficamente em toda parte, espero que não haja desastre em todos os lugares.
Jungle Hunter
3
Vi um site que ofereceu 100% de tempo de atividade ou seu dinheiro de volta. O truque era que eles carregavam uma carga de barco e dividiam em meses. Assim, alguns meses não são remunerados e você agenda tudo em torno disso e cobre a perda com os meses que dão certo.
jldugger
17

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.

voretaq7
fonte
2
É necessário definir 100%, ou seja, 100% disponível, exceto ao fazer manutenção ou atualizações, e esse tempo será limitado a horas de silêncio por algumas horas por mês, no máximo. Tudo depende de qual é o propósito e uso do aplicativo web é, neste caso ...
David d C e Freitas
1
e defina "tempo de inatividade". Teoricamente, não posso garantir que eles possam acessar um servidor em Omaha a partir de seus escritórios em Fairbanks, a menos que você controle toda a rede no meio (embora você possa dar garantias de que o servidor esteja em funcionamento).
jwenting
As definições são, IMHO, irrelevantes se pedirem "100% de tempo de atividade": mesmo se você negociar manutenção agendada e aumentar a redundância de N + N, se uma pequena falha causar uma reinicialização não programada ou um piscar de serviço, você interrompeu o seu SLA. DEFINITIVAMENTE relevante se você estiver negociando um SLA de 3, 4 ou 5 noves.
precisa saber é o seguinte
Depende dos termos do SLA, não é? Se você receber US $ 100 mil por mês e cada minuto de inatividade acarretar uma multa de US $ 1 mil, isso pode ser totalmente factível (se você tiver outros contratos para amortizar o custo de administradores de sistema no local, 24 horas por dia, 7 dias por semana).
Michael Borgwardt
@MichaelBorgwardt, existem definitivamente maneiras de "fazê-lo funcionar" do ponto de vista de números puros, mas eu ainda recusaria por causa de um potencial de relações públicas ruins ($ _CLIENT vai no Twitter e diz ao mundo 'estamos perdidos porque $ _PROVIDER é incompetente e não pode atender ao seu SLA! '). Pessoalmente, eu prefiro ter 10 menores, clientes mais razoáveis pagar-me $ 10kA mês :-)
voretaq7
13

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.

Bryan Boettcher
fonte
3
Se você vir alguém prometendo 100% de tempo de atividade, é exatamente isso que está fazendo. Há uma diferença entre prometer 100% de tempo de atividade e entregá-lo. Seria uma boa idéia explicar isso ao cliente se ele tentar citar o SLA de um concorrente para você.
sjbotha
10

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.

Paweł Brodacki
fonte
10

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.

Irving
fonte
2
+1 para o teste de suco de laranja .. eu gosto e não sabia sobre isso :)
Oliver M Grech
8

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.

jhocking
fonte
6

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.

AT
fonte
1
Sim, o DNS é um bom começo - por exemplo, nslookup google.comretorna 6 IPs diferentes para redundância, caso alguns deles não funcionem. Também check out RobTex.com um ótimo local para olhar para as configurações de certos domínios, por exemplo, robtex.com/dns/google.com.html#records
David d C e Freitas
6

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!

Campos
fonte
5

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.

Paulo
fonte
10
Tem sido minha experiência que alguns servidores DNS desconsiderem um TTL que eles consideram extremamente desagradável (apesar da RFC). Qualquer coisa com menos de 5 minutos se torna um pouco confiável na escala global.
JDW
13
@Paul ignorar a realidade não é uma prática aceitável, não importa o quanto isso irrite todos.
MDMarra 29/09
5
Estou com jdw sobre isso. Eu já vi vários servidores DNS ignorarem completamente o TTL, mesmo uma configuração de 1 hora e o padrão volta para algo como 24 horas ou mais.
NotMe 29/09
6
@Paul - o OP não tem controle sobre os resolvedores de DNS de todos os ISPs do planeta. Portanto, eles não têm a opção de dizer "se você for usar nosso site, não use Comcast / Roadrunner / quem quer que seja seu ISP, porque eles ignorarão nossas configurações de TTL". É algo que simplesmente está fora de controle e, portanto, é muito frágil para ser considerado uma solução para este problema IMHO. A solução precisa incluir uma maneira de poder forçar internamente os IPs sem depender de outros bits da rede que podem não ser cooperativos.
JDW
3
É como não ter um no-break porque o poder 'deveria funcionar'. Não é uma maneira inovadora de arquitetar um sistema. Se você sabe que existe uma parte frágil do sistema, por qualquer motivo, tente explicá-lo.
JDW
5

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].

Marcin
fonte
Sem dúvida, o cliente não quer nenhuma solução. Eles querem um declínio. Então eles podem dizer que tentaram pelo menos.
Mbx #
Bem, talvez. Você está assumindo um alto nível de pista.
Marcin
4

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?

JSWork
fonte
2
O Azure e o EC2 tiveram recentemente falhas quase completas e totais. Acredito que o Azure foi retirado recentemente simplesmente devido a uma entrada de configuração incorreta em um servidor DNS. De qualquer forma, obrigado pela informação.
NotMe
e se o seu balanceador de carga (que faz a troca) passar despercebido (o monitor também pode passar despercebido, ad infinitum) quando o nó cair, você ainda está ferrado.
jwenting
1
Eu acho que você quis dizer 'incompetência'. 'Impotência' não deve ter um grande impacto na capacidade da equipe de TI de realizar seu trabalho.
mfinni
4

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.

Patrick
fonte
3

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.

Mahmoud Al-Qudsi
fonte
3

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 .

Yves Junqueira
fonte
3

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%.

Karoly Horvath
fonte
Na verdade, eu ficaria louco ou impossível e chamaria isso de estúpido. Nada que os humanos sabem é 100%.
quadruplebucky
2

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.

James Pulley
fonte
1

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.

Kevin Peterson
fonte
Se o cliente pensa que deseja "100% de tempo de atividade" e é aí que acaba a verborragia do contrato, você pode se apegar a ela se terminar em tribunal. É melhor conversar e ajudar o cliente a entender o que realmente deseja, em vez de assumir que você sabe o que está pensando.
Chris S
Ah, eu concordo que isso precisa ser esclarecido antes de entrar em um contrato. Só estou dizendo que isso precisa ser abordado, pois o cliente não está comunicando o que realmente deseja, ao contrário do cliente está pedindo algo ridículo.
Kevin Peterson
1

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.

Quilo
fonte
-1 porque esta é uma resposta prática, mas não é de todo útil. Todas as perguntas neste site podem ser respondidas com "contratar alguém para fazer isso", mas não é por isso que estamos aqui.
Yves Junqueira
Eu peço desculpa mas não concordo. "Não é útil?" Certamente foi útil para mim e, ao contrário do seu comentário "contrate alguém para fazê-lo", suponho que, com o seu raciocínio, o cara deveria abrir seu próprio cabo de fibra óptica e projetar seus próprios switches em vez de comprá-los também? Você está falando sério, Yves? Você parece alguém que não passou muito tempo no campo de TI.
Quilo 03/03
0

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.

cristão
fonte
0

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".

convencer
fonte
0

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.

Leon Waldman
fonte