Cenário de Failover do Servidor

Question

Eu tenho dois servidores Dell PowerEdge 2950. A fim de (espero) eliminar qualquer tempo de inatividade, devo implementar uma solução para detectar e ajustar falhas de componentes, falhas de ambiente, etc ... o cenário usual de "inatividade é o inimigo".

Deste ponto em diante, eu vou me referir aos servidores como servidores , já que a solução implementada pode combinar os dois servidores em um servidor lógico, (honestamente, um servidor lógico seria preferido).

Eu terei ~ 15 thin clients apontando para o (s) servidor (es) mencionado (s) acima. O (s) servidor (es) funcionará como um servidor de terminal. Os clientes se conectarão ao (s) servidor (es) e executarão uma instância de uma GUI do cliente. O (s) próprio (s) servidor (es) em si rodará a versão do servidor do mesmo aplicativo, servindo as GUIs do cliente com as informações / dados que eles exigem ... (espero que tenha feito sentido!)

Recomendaram-me usar o software everRun 2G da Marathon Technologies. Enquanto isso parece uma solução justa, também é $ 12.000 ... parece um pouco caro para mim, (isso pode ser eu mostrando minha falta de experiência neste campo, no entanto) ...

Existe uma solução mais econômica para esse cenário? Eu fui verificar em uma solução envolvendo Citrix XenServer no momento , mas ainda tem que fazer muito leadway com isso ...

Como se pode implementar a tolerância a falhas ao grau mencionado acima?

EDITAR: Os servidores estão executando o Windows Server 2003 Enterprise.

EDIT : Para esclarecer minha falta de comunicação, estou realizando o failover para o nó ainda em execução no caso de um desastre. A aplicação a ser hospedada fornece o controle de um grande número de portas e interfones bloqueados eletronicamente. Portanto, se o aplicativo não estiver disponível, nenhuma porta será aberta e nenhuma comunicação via intercomunicador poderá ocorrer. Caramba!

EDITAR : Bem, depois de algumas mudanças no escopo, financiamento e outros ajustes não-técnicos do projeto, a solução que estou seguindo realmente usou nenhuma das abordagens listadas :) Longa história curta, nós manutenção de dois servidores de terminal separados; um backup primário e um backup quente. A troca entre os dois em um cenário de emergência será manual (embora, na verdade, seja tão rápida, se não mais rápida do que esperávamos inicialmente). O hardware do servidor (dois NICs, dois suprimentos de bateria e dois no-breaks) abordará a funcionalidade de failover necessária. Obrigado por todos os seus comentários, muito apreciados!

    

Answer 1

Eu questiono se você realmente precisa de alta disponibilidade ou se você simplesmente precisa de um failover para o nó ainda em execução no caso de falha de hardware. O HA vai ser muito caro e, com esse pequeno número de usuários, eu acho que seu orçamento não é tão alto assim.

Você já pensou em usar a funcionalidade de diretório de sessão de serviços de terminal da Microsoft e um balanceador de carga? Você já tem o "Enterprise Edition" do Windows Server 2003, então você já está "superlativo" no que diz respeito às despesas de licenciamento na implementação da funcionalidade do Diretório de Sessões.

Mais alguns detalhes: link

Você também pode ver algumas ferramentas de terceiros, como o 2X Loadbalancer . (Nenhuma experiência pessoal com isso, embora ...)

    

Answer 2

O Marathon é um sistema muito pesado, efetivamente diminui pela metade a capacidade dos sistemas que você possui. Em primeiro lugar, asseguro que você tenha o básico como o armazenamento compartilhado.

Hoje, a VMware pode fornecer HA que está efetivamente reinicializando o servidor quando um dos sistemas falhar, no futuro, o VMware poderá rastrear a máquina de tal forma que, quando um dos servidores morrer, a instância será migrada "live" de forma transparente para o outro serviço.

Gostaria de salientar que, a menos que você realmente precise de HA, geralmente é melhor ter um sistema simples que funcione bem do que um sistema complexo que deve ser mais confiável, mas na verdade não é.

    

Answer 3

Como o James mencionou, se for realmente importante, talvez valha a pena procurar carregar os servidores físicos com o ESX da VMWare. Usando essa infraestrutura, você pode utilizar o Vmotion em conjunto com as ferramentas de alta disponibilidade da VMWare para permitir que o servidor se mova facilmente entre os servidores físicos, sem tempo de inatividade para o usuário final. Isso requer uma SAN, bem como uma caixa separada para executar o software de gerenciamento, mas o software de gerenciamento pode ser executado em algo tão leve quanto um desktop.

    

Answer 4

Vou garantir o Citrix XenServer, mas usar o VMWare nunca é um erro. Pode apenas ferir a carteira da empresa se alguma coisa.

Como Charles comentou, você precisa de uma SAN (ou NAS) ou algum tipo de armazenamento compartilhado para realmente aproveitar os recursos de alta disponibilidade / VMotion do VMWare. Mas para responder às suas perguntas:

Is there a more cost-efficient solution to such a scenario? I've been checking into a solution involving Citrix XenServer at the moment, but have yet to make much leadway with it ...

O Citrix XenServer 5.5 e o XenCenter são gratuitos (como o ESXi), mas o IMO tem mais recursos que o aproximam do objetivo de "eliminar qualquer tempo de inatividade". Mas, seja usando o Xen ou o VMWare, você precisa de armazenamento compartilhado compatível com os requisitos do produto.

How can one implement fault tolerance to the degree mentioned above?

Bem, sua meta geral soava como alta disponibilidade e agora você está solicitando tolerância a falhas. Dois conceitos diferentes dentro do reino da TI. Eu diria que, dada toda a informação apresentada, pode haver uma alternativa melhor do que saltar diretamente para os altos custos da virtualização. 15 sessões não são exatamente uma carga difícil para seus servidores. Talvez a virtualização neste momento seja um pouco demais e talvez você possa sair sem ela. Equilibre a carga entre os dois servidores de terminal para facilitar a carga até que mais clientes sejam necessários e, em seguida, examine a virtualização de tudo.

Outra ideia: você pode virtualizar com o VMWare ESXi ou o XenServer 5.5 e virtualizar, mas sem os recursos HA / VMotion-esque agora . Então, quando você precisar usar esses recursos, compre os upgrades e faça o armazenamento compartilhado entre os dois servidores. Dessa forma, você não terá que fazer conversões P2V antes.

    

Answer 5

Aqui estão algumas opções que eu veria ..

Basta instalar tudo nos dois servidores, incluindo serviços de terminal, e usar o serviço embutido no servidor Windows para usar um "cluster IP" para que todos se conectem a um endereço IP e os dois decidam quem se conecta a qual máquina, dando um pseudo situação de balanceamento de carga.

Outra é investir no conjunto de ferramentas do VMWare para usar uma VM nos serviços de terminal, depois usar o VMotion e as opções de alta disponibilidade para manter a VM viva.

A maioria das situações de alta disponibilidade corporativa parece exigir dois servidores, além de um sistema de armazenamento SAN ou iSCSI de alta velocidade no qual salvar as VMs ou dados compartilhados entre os dois servidores, e os serviços de aplicativo do servidor são executados nos dois sistemas conectados para o servidor de armazenamento.

Pode ser possível usar uma instalação do Xen no Linux usando DRBD e Pacemaker, mas acho que talvez ter o "cluster IP" no Windows para distribuir conexões entre dois servidores de terminal possa ser bom o suficiente, talvez com um NAS ou outro servidor de armazenamento para compartilhar um diretório de dados do aplicativo ou um diretório base para dados. Isso funcionaria?

Eu acho que você editou sua pergunta um pouco? Ou isso ou eu desnatado muito rápido: -)

15 usuários indo para dois servidores usando serviços de terminal; Acredito que, para preocupações e gerenciamento de orçamento, talvez ainda seja melhor procurar ativar o balanceamento de carga embutido nos serviços de terminal.

Alguns cuidados: um usuário pode matar um terminal para todos. Tínhamos um usuário que saía enquanto estava logado em um terminal enquanto visualizava uma animação de weather.com. Depois de algumas horas, o uso da memória ou o uso da CPU aumentaram até o ponto em que todos os outros estavam atolados em um estado quase inutilizável.

Além disso, se houver uma desconexão e um usuário se reconectar ao segundo servidor, eles poderão ficar confusos onde seus aplicativos foram usados quando a rede faliu ou problemas de compartilhamento de arquivos no servidor de diretório inicial, porque um arquivo está aberto no servidor e agora eles estão conectados ao servidor dois.

Em outras palavras, depender muito dos serviços de terminal, independentemente de seus servidores, significa ter uma boa infraestrutura. Isso significa mais dinheiro em switches gerenciados e cabeamento confiável. E você deve ter um departamento de TI pronto para monitorar esses servidores em caso de anomalias no caso de um usuário estar sobrecarregando recursos, já que uma pessoa pode ter um problema que ocorre em cascata nas sessões de outros usuários.

    

Answer 6

Eu diria que desde que você mencionou que um segundo PC para executar o software de gerenciamento ESX seria desaprovado, sua única opção real é o balanceamento de carga. Praticamente todas as outras soluções envolvem a compra de armazenamento compartilhado, que provavelmente começará perto do que você pagou por esses dois 2950s.