Quando é o momento certo para introduzir alta disponibilidade para o site?

Question

Quando é o momento certo para apresentar alta disponibilidade para o site?

Existem muitos artigos sobre opções de alta disponibilidade. Não é tão óbvio, no entanto, QUANDO é o momento certo para mudar de configuração de servidor único para alta disponibilidade.

Por favor, considere a minha situação: O link é um site 24/7 com tráfego significativo:
link

Atualmente eu o executo em um único servidor: tanto o servidor web IIS 7.0 quanto o SQL Server 2008 são executados na mesma caixa de hardware.

Há ocasional (~ um por mês) ~ 5 minutos de inatividade geralmente causados pela reinicialização exigida por alguma atualização do Windows Server. Normalmente, o tempo de inatividade é agendado e acontece à noite. Ainda assim, é desagradável, porque o Google Bot e alguns usuários ainda estão ativos à noite.

A receita atual do site está em ~ $ 8K / mês.

Eu considero a mudança para a configuração de dois servidores (web farm de dois servidores da web e cluster de dois SQL Servers hospedados em dois servidores de hardware).

Prós:
1) Alta Disponibilidade (teoricamente sem tempo de inatividade). Mesmo se um dos servidores cair, outro servidor assumirá.
2) Sem perda de dados: sem cluster SQL, até um dia de dados pode ser perdido em caso de falha de hardware (fazemos backup diário).

Contras:
1) Mais esforço para configurar e manter essa configuração.
2) Maior custo de hospedagem. Em vez de US $ 600 / mês, seria cerca de US $ 1200 / mês.

Qual seria sua recomendação?

    

Answer 1

Resposta curta: Quando o tempo de inatividade ou o risco de isso custar mais do que custaria para você ter alta disponibilidade.

É fundamentalmente uma decisão econômica. Como um exemplo. $ 8k / mês implica que uma interrupção de 2 horas custará $ 22. Se você puder configurar seu sistema de modo que você possa ir do zero para um site totalmente funcional em 2 horas, a alta disponibilidade só lhe renderá US $ 22 de funcionalidade acima disso.

Em outras palavras, você pode economizar dinheiro, a menos que você tenha 54 horas de inatividade inevitável em um determinado mês.

    

Answer 2

Seus stakeholders / empresários (que podem ser você!) precisam decidir

• perda aceitável de receita
• consequências da perda de reputação, respeitabilidade, etc.
• perda de dados aceitável ( objetivo do ponto de recuperação )
• tempo de inatividade aceitável ( Objetivo do tempo de recuperação )

A perda de receita é fácil de quantificar: o resto não pode ser respondido aqui, desculpe ...

    

Answer 3

Acho que a maioria dos usuários aguenta um pouco de tempo de inatividade programado. Considere que o ebay tem atualizações semanais nas noites de sexta-feira, e as ofertas por aí, às vezes, não funcionam. O banco on-line do meu banco (principal australiano) programou interrupções por horas a cada semana. Twitter fica offline o tempo todo. Heroku / EC2 ficou inativo recentemente.

Eu manteria isso nessa perspectiva, se você estiver falando apenas 5 minutos por mês, você está fazendo um bom trabalho como administrador de sistema.

    

Answer 4

Você já mencionou o Google como um fator em termos de indexação, mas também pode valer a pena considerar o impacto que a latência / capacidade de resposta do site pode ter sobre o SEO. É uma caixa preta e tudo isso, tão difícil de quantificar - apesar de que vale a pena, Matt Cutts calcula que é um percentual . Eu ficaria mais preocupado com a reputação, como outros afirmaram.

    

Answer 5

Tenha em mente que o HA, como segurança, não é um produto, mas sim um processo.

Por exemplo, a replicação de banco de dados só levará você ao ponto em que cada espelho do banco de dados poderá continuar por conta própria, mas também será necessária uma estratégia para ressincronização após a substituição dos componentes com falha.

Considere um sistema de pedidos como um exemplo: o cliente envia um pedido e, durante o processamento, o sistema físico com o qual ele estava falando falha após armazenar as informações do pedido em sua cópia local do banco de dados. Impaciente, o cliente pressiona "enviar" novamente e é direcionado para outro servidor, que aceita o pedido. Se seus bancos de dados forem ressincronizados simplesmente reproduzindo as instruções INSERT perdidas no outro lado, o pedido será duplicado, o que pode não ser o que você deseja.

Como o @Slartibartfast sugeriu, tudo se resume a uma decisão econômica, mas eu recomendo que você também planeje alguns anos no futuro. Se você espera precisar de uma configuração adequada de HA, então agora seria um bom momento para reservar recursos para o trabalho preparatório.

    

Answer 6

Enquanto pensa nisso, acho que você considera a possibilidade de configurar uma página "fail whale".

Existem muitas maneiras de fazer isso, mas o combo aws de route53 e s3 funciona bem em meus sites pequenos.

Configurei o domínio com verificações de integridade para que, em caso de falhas, o DNS enviasse os usuários para os usuários em uma página HTML estática em s3; Custa quase nada.

Na minha experiência, ter seu site dizendo "desculpe as coisas estão quebradas, mas estamos trabalhando nisso" faz uma grande diferença para os usuários. Uma conta no Twitter onde você pode se comunicar com os usuários é ainda melhor.

Isso leva muito tempo para mitigar a "perda de reputação" que pode ser o impacto mais significativo de uma interrupção.

veja: link para um guia sobre como configurá-lo.

O link do failover social da DynDns é um tipo de coisa simples.

Você pode criar suas próprias verificações de integridade e, em seguida, fazer o script das alterações de DNS, desde que seus registros de DNS tenham um TTL baixo e você tenha alguma maneira de manipulá-los de forma programática.

    

Answer 7

Já pensou em usar algo como o EC2, que permite dimensionar de forma flexível e também negar seus contras? Em última análise, é uma decisão econômica se vale a pena usar o EC2 ou não, mas é, no mínimo, uma opção a ser considerada.

    

Answer 8

Para evitar a perda de dados, você deve examinar as configurações de Raid antes dos clusters. Você também deve configurar um IP de failover que pode alternar de um servidor para outro em caso de um desastre, sem ter que esperar pela propagação do DNS.