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

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

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

Por favor, considere minha situação:
http://www.postjobfree.com é um site 24/7 com tráfego significativo:
http://www.similarweb.com/website/postjobfree.com

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

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

A receita atual do site é de aproximadamente US $ 8.000 / mês.

Considero mudar para a configuração de dois servidores (web farm de 2 servidores web e cluster de 2 servidores SQL 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á o controle.
2) Sem perda de dados: sem o cluster SQL, até um dia de dados podem ser perdidos em caso de falha de hardware (fazemos backup diário).

Contras:
1) Mais esforço para definir 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?

Resposta curta: quando o tempo de inatividade ou o risco disso custam mais do que custaria ter alta disponibilidade.

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

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

Seus stakeholders / pessoas de negócios (que podem ser você!) Precisam decidir

• perda de receita aceitável
• consequências 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 )

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

Acho que a maioria dos usuários pode lidar com um pouco de tempo de inatividade programado. Considere que o ebay tem atualizações semanais nas noites de sexta-feira e lances por aí às vezes não funcionam. O banco on-line do meu banco (principal da Austrália) agendou interrupções por horas toda semana. O Twitter fica offline o tempo todo. Heroku / EC2 caiu por dias recentemente.

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

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 capacidade de resposta da latência / site pode ter no SEO. É uma caixa preta e tudo isso, tão difícil de quantificar - embora, pelo que vale, Matt Cutts calcula que é um por cento . Eu ficaria mais preocupado com a reputação, como outros já declararam.

Lembre-se de que o HA, como segurança, não é um produto, mas um processo.

Por exemplo, a replicação do banco de dados o levará apenas ao ponto em que cada espelho do banco de dados poderá continuar por conta própria, mas você também precisará de uma estratégia de 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 ausentes do outro lado, a ordem será duplicada, o que pode não ser o que você deseja.

Como o @Slartibartfast sugeriu, tudo se resume a uma decisão econômica, no entanto, eu recomendo que você também planeje alguns anos no futuro aqui. 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.

Enquanto você pensa sobre isso, acho que você considera criar uma página "falhar baleia".

Existem várias maneiras de fazer isso, mas a combinação aws de route53 e s3 funciona bem em meus pequenos sites.

Eu configuro o domínio com verificações de integridade para que, em falhas, o DNS envie usuários aos usuários para uma página html estática localizada em s3; Custa quase nada.

De acordo com a minha experiência, ter seu site dizendo "desculpe, mas estamos trabalhando nisso" faz muita 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 a atenuar a "perda de reputação", que pode ser o impacto mais significativo de uma interrupção.

consulte: https://aws.amazon.com/blogs/aws/create-a-backup-website-using-route-53-dns-failover-and-s3-website-hosting/ para obter um guia sobre como configurá-lo.

O failover social do DynDns http://dyn.com/managed-dns/social-failover/ é um tipo de coisa semelhante.

Você pode fazer o seu próprio, executar suas verificações de saúde e, em seguida, criar um script para as alterações no DNS, desde que seus registros DNS tenham um TTL baixo e você tenha alguma maneira de manipulá-los programaticamente.

Você já pensou em usar algo como o EC2 que permitirá escalar com flexibilidade e também negar seus contras? Em última análise, é uma decisão econômica se o uso do EC2 vale a pena ou não, mas é pelo menos uma opção a considerar.

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