Aqui está o Mapa prático da Wikipedia sobre a busca de noves:
Curiosamente,apenas
No gráfico, deve ficar evidente quão ridícula a busca por 100% de tempo de atividade é ...
Recebemos um "requisito" interessante de um cliente hoje.
Eles querem 100% de tempo de atividade com o off-site failover em um aplicativo da web. Do ponto de vista da nossa aplicação web, isso não é um problema. Ele foi projetado para ser dimensionável em vários servidores de banco de dados, etc.
No entanto, de um problema de rede, não consigo descobrir como fazer isso funcionar.
Em poucas palavras, o aplicativo vai viver em servidores dentro da rede do cliente. É acessado por pessoas internas e externas. Eles querem que mantenhamos uma cópia do sistema que, em caso de falha grave em suas instalações, imediatamente pegaria e retomaria o controle.
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 percebam.
Francamente, não tenho a mínima idéia de como isso é 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?
UPDATE
Eu tive uma conversa com o cliente hoje e eles esclareceram sobre o assunto.
Eles ficaram com o número de 100%, dizendo que o aplicativo deve permanecer ativo mesmo no caso de uma inundação. No entanto, esse requisito só entra em ação se hospedá-lo para eles. Eles disseram que lidariam com o requisito de tempo de atividade se o aplicativo estivesse inteiramente em seus servidores. Você pode adivinhar minha resposta.
Aqui está o Mapa prático da Wikipedia sobre a busca de noves:
Curiosamente,apenas
No gráfico, deve ficar evidente quão ridícula a busca por 100% de tempo de atividade é ...
Peça-lhes que definam 100% e como será medido durante o período de tempo. Eles provavelmente querem dizer o mais próximo de 100% do que podem pagar. Dê-lhes os custos.
Para elaborar. Eu estive em discussões com clientes ao longo dos anos com requisitos supostamente ridículos. Em todos os casos, eles estavam apenas usando linguagem não precisa o suficiente.
Muitas vezes eles moldam as coisas de formas que parecem absolutas - como 100%, mas, na verdade, em investigações mais profundas, elas são razoáveis o suficiente para fazer as análises de custo / benefício que são necessárias quando apresentadas aos cálculos dos dados de mitigação de riscos. Perguntar a eles como eles medirão a disponibilidade é uma questão crucial. Se eles não sabem disso, então você está em posição de sugerir a eles que isso precisa ser definido primeiro.
Gostaria de pedir ao cliente para definir o que aconteceria em termos de impacto / custo do negócio se o site falhasse nas seguintes circunstâncias:
E também como eles vão medir isso.
Desta forma, você pode trabalhar com eles para determinar o nível correto de '100%'. Suspeito que ao fazer esse tipo de pergunta, eles poderão determinar melhor as prioridades de seus outros requisitos. Por exemplo, eles podem querer pagar determinados níveis de SLA e comprometer outras funcionalidades para conseguir isso.
Seus clientes são loucos. 100% de tempo de atividade é impossível não importa quanto dinheiro você gasta com ele. Simples e simples - impossível. Olhe para o Google, Amazon, etc Eles têm quantidades quase infinitas de dinheiro para jogar em sua infra-estrutura e ainda assim eles conseguem ter tempo de inatividade. Você precisa entregar essa mensagem para eles, e se eles continuarem a insistir que eles oferecem exigências razoáveis. Se eles não reconhecerem que alguma quantidade de tempo de inatividade é inevitável, então os trancam.
Dito isso, você parece ter a mecânica de escalar / distribuir o próprio aplicativo. A parte de rede precisará envolver uplinks redundantes para ISPs diferentes, obtendo uma alocação de ASN e IP e chegando ao fundo do BGP e equipamento de roteamento real para que o espaço de endereço IP possa se mover entre ISPs, se necessário.
Esta é, obviamente, uma resposta muito concisa. Você não teve experiência com aplicativos que exigem esse tempo de atividade, então você realmente precisa envolver um profissional se quiser chegar perto do mítico 100% de tempo de atividade.
Bem, isso é definitivamente interessante. Não tenho certeza se gostaria de me comprometer contratualmente com 100% de tempo de atividade, mas se eu tivesse que pensar que seria algo 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 o failover para o outro. Um programa como o Heatbeart pode ajudar com o failover automático deles.
O verniz é principalmente conhecido como uma solução de armazenamento em cache, mas também faz um balanceamento de carga bastante decente. Talvez isso seja uma boa escolha para lidar com o balanceamento de carga. Ele pode ser configurado para ter 1 a n backends agrupados opcionalmente em directors que farão o balanceamento de carga aleatoriamente ou round-robin. O verniz pode ser inteligente o suficiente para verificar a saúde de cada back-end e remover back-ends insalubres do ciclo até que ele volte a ficar online. Os backends não precisam estar na mesma rede.
Estou meio que apaixonado pelos Elastic IPs no Amazon EC2 atualmente, então provavelmente eu criaria meus balanceadores de carga no EC2 em diferentes regiões ou pelo menos em diferentes zonas de disponibilidade na mesma região. Isso lhe daria a opção de manualmente (deus proíbe) girar um novo balanceador de carga se você tivesse que fazer isso e mover o IP do registro A existente para a nova caixa.
O verniz não pode finalizar o SSL, portanto, se isso for uma preocupação, você pode querer ver algo como Nginx.
Você pode ter a maioria de seus back-ends na rede de seus clientes e um ou mais fora de sua rede. Acredito, mas não tenho 100% de certeza, que você pode priorizar os back-ends para que as máquinas de seus clientes recebam prioridade até que todas elas se tornem prejudiciais.
É aí que eu começaria se tivesse essa tarefa e, sem dúvida, refinaria isso à medida que prosseguisse.
No entanto, como afirma @ErikA, é a Internet e sempre haverá partes da rede que estão fora de seu controle. Você vai querer ter certeza de que o seu direito só te amarra com coisas que estão sob seu controle.
Não há problema - formulação de contrato ligeiramente revisada:
... guarantee an uptime of 100% (rounded to zero decimal places).
Eu não entendo qual é o problema. O cliente quer que você planeje um desastre, e eles não são orientados à 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 o fizesse. Quando eles dizem isso, eles não estão pensando em inverno nuclear, eles estão pensando em Fred jogando seu café no servidor do escritório, um disco quebrando, ou um ISP indo para baixo. Além disso, você pode conseguir isso. Com servidores de auto-monitoramento independentes, geograficamente distintos, você basicamente não terá tempo de inatividade. Com 3 servidores operando em uma confiabilidade independente (1), com bons modos de failover, seu 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 tem que lidar com cenários apocalípticos, mas Godzilla excluído, ele terá um serviço que está "sempre" aberto.
(1) Um servidor em LA é razoavelmente independente do servidor em Boston, mas sim, eu entendo que há alguma intersecção envolvendo guerra nuclear, hackers chineses quebrando a rede elétrica, etc. Eu não acho que seu cliente fique chateado com isso.
(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, o que é, novamente, dentro de um SLA razoável, e normalmente não é considerado na mesma linha como "tempo de inatividade". Com um aplicativo que reencaminha automaticamente para um nó disponível em caso de falha, isso pode ser imperceptível.
Se o Facebook e a Amazon não podem fazer isso, você não pode. É tão simples assim.
Você está sendo perguntado por algo impossível.
Analise as outras respostas aqui, sente-se com seu cliente e explique POR QUE é impossível avaliar sua resposta.
Se eles ainda insistirem em 100% de tempo de atividade, informe-os educadamente de que isso não pode ser feito e recusar o contrato. Você nunca atenderá a demanda deles e, se o contrato não for totalmente ruim, você será atacado com penalidades.
Avalie adequadamente e estipule no contrato que qualquer tempo de inatividade passado após o SLA será reembolsado na taxa que eles estão pagando.
O ISP no meu último trabalho fez isso. Tivemos a escolha de uma linha DSL "regular" com 99,9% de tempo de atividade por US $ 40 / mês, ou um trio de T1s com 99,99% de tempo de atividade por US $ 1100 / mês. Houve interrupções freqüentes de 10+ horas por mês, o que trouxe seu tempo de atividade bem abaixo do DSL $ 40 / mo, mas nós só foram reembolsados em torno de US $ 15 ou mais, porque é isso que a taxa por hora * horas acabou em. Eles se tornaram bandidos do acordo.
Se você faturar US $ 450.000 por mês para 100% de tempo de atividade e só atingir 99,999%, será preciso reembolsá-los por US $ 324,00. Estou disposto a apostar que os custos de infra-estrutura para atingir 99,999% estão na faixa de US $ 45 mil por mês, assumindo colos totalmente distribuídos, vários uplinks de nível 1, hardware sofisticado, etc.
Se os profissionais questionarem se 99,999% de disponibilidade [é] uma possibilidade prática ou financeiramente viável , então 99,9999% de disponibilidade é ainda menos possível ou prático. Deixe sozinho 100%.
Você não atingirá a meta de 100% de disponibilidade por um período prolongado. Você pode se safar por uma semana ou um ano, mas então algo acontecerá e você será responsabilizado. O emissário pode variar de reputação prejudicada (você prometeu, você não entregou) à falência de multas contratuais.
Existem dois tipos de pessoas que solicitam 100% de tempo de atividade:
Meu conselho, tendo sofrido ambos os tipos de clientes em muitas ocasiões, é não aceitar esse cliente. Deixe-os conduzir outra pessoa à loucura.
* Essa mesma pessoa pode não ter nenhum constrangimento perguntando sobre viagens mais rápidas que a luz, movimento perpétuo, fusão a frio, etc.
Eu me comunico com o cliente para estabelecer com eles exatamente o que significa 100% de tempo de atividade. É possível que eles não percebam uma diferença entre 99% de tempo de atividade e 100% de tempo de atividade. Para a maioria das pessoas (ou seja, não são administradores de servidores), esses dois números são os mesmos.
100% de tempo de atividade?
Veja 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 forma eficaz.
Isso é fácil. O SLA do Amazon EC2 afirma claramente:
“Annual Uptime Percentage” is calculated by subtracting from 100% the percentage of 5 minute periods during the Service Year in which Amazon EC2 was in the state of “Region Unavailable.”
Basta definir 'tempo de atividade' para ser relativo a todo o pacote de serviços que você pode realmente manter operacional em 100% do tempo, e você não deve ter problemas.
Além disso, vale a pena ressaltar que todo o objetivo de um SLA é definir quais são suas obrigações e o que acontece se você não puder atendê-las. Não importa se o cliente pede 3 noves ou 5 noves ou um milhão e noves - a questão é o que eles recebem quando / se você não pode entregar. A resposta óbvia é fornecer um item de linha com 100% de tempo de atividade a 5x o preço que você deseja cobrar e, em seguida, eles recebem um reembolso de 4x se você perder essa meta. Você pode pontuar!
Alterações no DNS levam tempo apenas se estiverem configuradas para levar tempo. Você pode definir o TTL em um registro para 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 na 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 é retomado quase imediatamente. Máximo de 30 segundos de interrupção, mas esse é o caso limite, 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 duvido que 100% seja possível, você pode querer considerar o Azure (ou algo com um SLA similar) 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 eu não tenha certeza de como o estado de suas sessões seria afetado).
Dito isto, mesmo com este failover, a diferença entre 99,999 e 100 limita a insanidade.
Você terá que ter controle total sobre os seguintes fatores.
- Fatores humanos, internos e externos, malícia e impotência. Um exemplo disso é alguém empurrando algo para código de produção que derruba um servidor. Pior ainda, e sabotagem?
- questões de negócios. E se o seu fornecedor ficar sem trabalho ou se esquecer de pagar suas contas de luz ou simplesmente parar de dar suporte à sua infraestrutura sem aviso suficiente?
- natureza. E se tornados não relacionados atingirem centros de dados suficientes para sobrecarregar a capacidade de backup?
- Um ambiente completamente livre de bugs. Você tem certeza de que não há um caso extremo com algum controle de terceiros ou do sistema principal que não tenha se manifestado, mas que ainda pudesse fazê-lo no futuro?
- Mesmo que você tenha total controle sobre os fatores acima, você tem certeza de que o software / pessoa que está monitorando isso não apresentará falsos negativos ao verificar se o seu sistema está funcionando?
Honestamente, 100% é completamente insano sem pelo menos hesitar 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 você tem seu site e banco de dados replicados em vários servidores em vários locais geográficos. Isso garantirá uma grande catástrofe, como o backbone da Internet sendo cortado em uma região (o que acontece de vez em quando) ou algo quase apocalíptico.
Eu colocaria uma cláusula para tais casos (DDOS, corte de backbone na internet, ataque terrorista apocalíptico ou uma grande guerra, etc.).
Além disso, veja os serviços em nuvem do Amazon S3 ou Rackspace. Essencialmente, a configuração da nuvem não apenas oferecerá a redundância em cada local, mas também a escalabilidade e a distribuição geográfica do tráfego, juntamente com a capacidade de redirecionar as áreas geográficas com falha. Embora meu entendimento seja que a geodistribuição custa mais dinheiro.
Eu só queria adicionar outra voz ao "it can (teoricamente)" party.
Eu não aceitaria um contrato que tivesse isso especificado, não importando o quanto eles 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 delinear as etapas, mas imagino que uma combinação de configurações relacionadas à rede + failovers de fiação elétrica / de hardware + failovers de software, possivelmente, em alguma configuração ou outro trabalho realmente funcione. / p>
Quase sempre há um único ponto de falha em qualquer configuração, mas se você trabalhar bastante, você pode empurrar esse ponto de falha para algo que pode ser reparado "ao vivo" (isto é, o dns raiz fica inativo, mas os valores ainda estão em cache em qualquer outro lugar, então você tem tempo para consertá-lo).
Mais uma vez, não estou dizendo que é viável. Eu simplesmente não gostei de como nem uma única resposta abordou o fato de que não está "lá fora" - não é algo que eles realmente querem se eles pensarem bem. / p>
Repita sua metodologia de medição de disponibilidade e trabalhe com seu cliente para definir metas significativas .
Se você estiver executando um site grande, o tempo de atividade não será útil. Se você soltar as consultas por 10 minutos quando seus clientes mais precisarem delas (pico de tráfego), isso poderá ser mais prejudicial para os negócios do que uma interrupção de uma hora às três da manhã de um domingo.
Às vezes, grandes empresas da web avaliam a disponibilidade ou a confiabilidade usando as seguintes métricas:
A disponibilidade deve ser não medida usando probes de amostra, que é o que uma entidade externa, como pingdom e pingability, é capaz de relatar. Não confie apenas nisso. Se você quiser fazer isso da maneira correta, todas as consultas devem contar . Meça sua disponibilidade observando seu sucesso real e percebido.
A maneira mais eficiente é coletar registros ou estatísticas de seu balanceador de carga e calcular a disponibilidade com base nas métricas acima.
A porcentagem de quedas de consultas também deve contar com suas estatísticas. Pode ser contabilizado no mesmo intervalo que os erros do lado 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 X consultas para esse dia da semana, mas obteve o X-1000, provavelmente descartou 1000 consultas. Plote seu tráfego em consultas por minuto (ou segundo) gráficos. Se as lacunas aparecerem, você descartou as consultas. Use a geometria básica para medir a área dessas lacunas, o que lhe dá o número total de consultas descartadas.
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.
Depois, você pode assinar um contrato com base nas melhorias na linha de base. Digamos que, se eles estiverem passando por 95% da disponibilidade, você pode prometer melhorar a situação dez vezes chegando a 98,5%.
Nota: há desvantagens nesta maneira de medir a disponibilidade. Primeiro, coletando logs, processando e gerando os relatórios você mesmo pode não ser trivial, a menos que você use ferramentas existentes para fazê-lo. Segundo, os erros de aplicação podem prejudicar sua disponibilidade. Se o aplicativo for de baixa qualidade, ele servirá mais erros. A solução para isso é considerar apenas os 500s criados pelo balanceador de carga, em vez daqueles que vêm do aplicativo.
As coisas podem ficar um pouco complicadas desta forma, mas é um passo além de medir apenas o tempo de atividade do seu servidor .
Enquanto algumas pessoas notaram aqui que 100% é insano ou impossível , eles 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 podem alcançá-lo.
Bem, é muito mais simples que isso. É matematicamente impossível .
Tudo tem uma probabilidade. Poderia haver um terremoto simultâneo em todos os locais onde você armazena seus servidores, destruindo todos eles. É uma probabilidade ridiculamente pequena, mas não é 0. Todos os provedores de internet podem enfrentar um ataque terrorista / cibernético simultâneo. Novamente, não é muito provável, mas também não é zero. O que quer que você forneça, você pode obter um cenário de probabilidade diferente de zero que reduz o serviço inteiro. Por isso, seu tempo de atividade também não pode ser 100%.
Vá pegar um livro sobre controle de qualidade de fabricação usando amostragem estatística. Uma discussão geral neste livro, cujos conceitos teriam sido expostos a qualquer gerente em um curso de estatística geral na faculdade, dita os custos de passar de 1 exceção em mil para 1 em dez mil para 1 em um milhão para 1 em um bilhão aumenta exponencialmente. Essencialmente, a capacidade de atingir 100% de tempo de atividade custaria uma quantidade quase ilimitada de fundos, como a quantidade de combustível necessária para empurrar um objeto até a 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 é mais um desejo do que um requisito verdadeiro. Com as dependências de aplicativos que existem fora de qualquer aplicativo para rede, resolução de nomes, roteamento, defeitos causados por componentes arquiteturais subjacentes ou ferramentas de desenvolvimento, torna-se uma impossibilidade prática de alguém garantir 100% de tempo de atividade.
Eu não acho que o cliente esteja realmente pedindo 100% de tempo de atividade ou até 99,999% de tempo de atividade. Se você olhar para o que eles estão descrevendo, eles estão falando sobre como continuar de onde eles pararam se um meteoro remover seu datacenter local.
Se o requisito é que pessoas externas nem percebem, o quão drástico isso tem que ser? Faria uma solicitação do Ajax tentar novamente e mostrar um controle giratório por 30 segundos para o usuário final ser 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, eles saberiam o suficiente para expressá-lo como 99,99 ou 99,999.
meus 2 centavos. Eu era responsável por um site muito popular para uma empresa da Fortune-5 que tiraria anúncios para o super bowl. Eu tive que lidar com grandes picos de tráfego e a maneira como resolvi isso foi usar um serviço como o Akamai. Eu não trabalho para Akamai mas achei o serviço deles extremamente bom. Eles têm seu próprio sistema DNS mais inteligente que sabe que com um determinado nó / host está sob carga pesada ou está inativo e pode rotear o tráfego de acordo.
A melhor coisa sobre o serviço deles é que eu realmente não precisava fazer nada muito complicado para replicar o conteúdo em servidores no meu próprio data center para o seu data center. Além disso, sei que, ao trabalhar com eles, eles fizeram uso intenso de servidores HTTP do Apache.Embora não tenha 100% de tempo de atividade, você pode considerar essas opções para dispersar conteúdo em todo o mundo. Como eu entendia as coisas, a Akamai também tinha a capacidade de localizar o tráfego, ou seja, se eu estivesse em Michigan, obtinha conteúdo de um servidor Michigan / Chicago e, se estivesse na Califórnia, supostamente recebi o conteúdo de um servidor baseado na Califórnia. p>
Em vez de failover externo, basta executar o aplicativo em dois locais simultaneamente, internos e externos. E sincronize os dois bancos de dados ... Então, se o interno cair, as pessoas internas ainda poderão trabalhar e as pessoas externas ainda poderão usar o aplicativo. Quando interno volta a ficar on-line, sincronize as alterações. Você pode ter duas entradas DNS para um nome de domínio ou até mesmo um roteador de rede com round robin.
Para sites hospedados externamente, o mais próximo que você terá 100% de tempo de atividade é hospedar seu site no Google App Engine e usar seus armazenamento de dados de alta replicação (HRD) , que replica automaticamente seus dados em pelo menos três datacenters 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 SLA do App é apenas "99.95% do tempo em qualquer mês do calendário".
Simples e direto: Anycast
Isso é o que o cloudflare, o google e qualquer outra grande empresa usa para redundância, baixa latência, failover / balanceamento continental.
Mas também tenha em mente que é impossível ter 100% de tempo de atividade e que os custos para passar de 99,999% para 99,9999% são MUITO maiores.