Introdução ao armazenamento em cluster do servidor da web

Question

Eu trabalho para um pequeno ISP, e nós hospedamos cerca de 250 domínios e todo o material que vem junto com isso: DNS, email, filtragem de spam e backups. Atualmente, temos servidores DNS separados (dois deles) e servidores de email (o email de saída está, na verdade, no servidor DNS secundário, mas estava anteriormente em seu próprio servidor). No passado, isso foi feito como uma medida de seguro. A última coisa que precisamos é de algum doofus (geralmente o seu verdadeiro) para limpar um servidor, remover o DNS e o correio, ou para que os spammers bloqueiem o nosso servidor SMTP de entrada, impedindo que o email de saída seja enviado também. No passado, isso era um problema, e nossos servidores foram configurados do jeito que estão agora para combatê-lo.

No entanto, soluções de cluster como o Cobalt RAQ da Sun (em dias de olde) e o Virtualmin parecem atender a uma abordagem all-in-one e, então, lidar com falhas por meio de servidores redundantes. Eu evitei isso até agora, mas estamos usando o Virtualmin em nosso servidor da Web há algum tempo, e gostaria de expandir para usá-lo em um cluster de alta disponibilidade. Nosso parceiro de rede construiu recentemente um datacenter que eliminou todos os nossos outros bugs, como problemas de rede, refrigeração e energia, então agora a única coisa que resta para dar errado é o fato de eu ter lavado um servidor, o que aconteceu no início deste mês.

Um dos maiores motivos pelos quais evitamos seguir esse caminho é porque nossos requisitos de hardware não são particularmente altos. Um servidor lida facilmente com todos os sites que hospedamos (a maioria deles são sites planos). Além disso, os roteadores de balanceamento de carga tendem a ser caros e complicados. Tudo o que eu realmente espero fazer é criar um cluster de dois nós para redundância, de modo que, quando eu mantenho um servidor (por mais raro que seja), não estamos fora por 8 a 12 horas enquanto eu o reconstruo.

O que eu preciso saber é como começar, e se estou realmente em posição de me preocupar com esse tipo de coisa.

    

Answer 1

Descobri que o uso do balanceamento de carga é a minha solução preferida para a introdução de alta disponibilidade em servidores da Web. Há vantagens para implantar implementações de código, não desativar os recursos disponíveis e introduzir redundância. O LVS é a minha solução preferida. Outros parecem gostar Libra e eu também estou intrigado com HAProxy . Com o LVS, configurar um servidor ldirectord e usar arptables no servidor da Web pode ser uma implementação direta. Você pode evitar o ponto único de falha com o LVS por meio de uma implementação de servidor ativo / passivo com failover usando pulsação .

Agora, se você estiver compartilhando hospedagem vendendo contas, a introdução de alta disponibilidade com failover automático será mais complicada. Com isso, você pode ter que considerar uma solução de armazenamento redundante que vários servidores possam acessar e configurar um servidor ativo / passivo usando heartbeat. DRBD parece que pode ser útil aqui.

Você pode implementar soluções completas de alta disponibilidade sem um único ponto de falha usando hardware totalmente aberto e de commodity. Se você quiser recomendações adicionais, eu ficaria feliz em ajudar. Esta é uma das minhas áreas favoritas para se concentrar.

    

Answer 2

O que fizemos recentemente foi configurar ucarp em nosso cluster e configurar 4 nós configurados de maneira idêntica. Nós executamos uma webapp desenvolvida internamente, então os 4 nós, quando não estão servindo como front-end, realmente fazem o trabalho de back-end.

O UCARP e alguns scripts que eu coloco juntos automaticamente ativarão um IP em outro nó quando o nó que estiver servindo as coisas começar a agir. O NGINX é o nosso servidor front-end e lida com as solicitações garantidas para um nó disponível.

O resultado de tudo isso é que eu posso, sem aviso, derrubar praticamente qualquer um dos nossos quatro nós, e os serviços migrarão automaticamente para outro nó disponível em segundos. (Conexões existentes para esse nó são interrompidas, mas há apenas um pequeno handfull em um dado momento, no momento em que elas são recarregadas, as coisas estão de volta a toda velocidade.) UCARP detectará falhas na conectividade IP --- se outras coisas forem ruim, você tem que descobrir uma maneira de tirar a conectividade IP do nó ruim, para que os outros nós funcionem.

Todos os 4 nós montam um sistema de arquivos exportado pelo nfs, que é manipulado por um par de máquinas rodando drbd