Planejamento Dimensionamento Node Failover Cluster

Neste blog vou discutir considerações sobre o planejamento do número de nós em um cluster de failover do Windows Server.

A partir do Windows Server 2012, Failover Clustering pode apoiar para cima de 64 nós em um único cluster tornando-se líder de mercado em escala para uma nuvem privada. Enquanto isso é emocionante, a realidade é que ele é provavelmente maior do que a média das pessoas se preocupa em fazer. Também não há limitação de tamanhos de cluster em diferentes versões do Windows Server (Padrão vs Datacenter, etc …). Como não há nenhuma limitação prática em escala para o administrador de TI da média, então quantos nós se você implantar com seu cluster? A principal consideração trata de definir um domínio de falha. Vamos discutir as considerações …

Resiliência para falhas de hardware

Ao pensar sobre os domínios de falha, resiliência de hardware é um dos maiores considerações. Seja chassis, rack, ou datacenter.Vamos começar com lâminas como um exemplo; você provavelmente não quer um chassi para ser um ponto único de falha. Para mitigar uma falha chassis você provavelmente vai querer divididos entre vários chassis. Se você tem oito lâminas por chassis, seria desejado para seus nós para residir em toda a dois chassis diferentes para resiliência, para que criar um cluster de 16 nós com oito nós em cada chassi. Ou talvez você quer ter rack de resiliência, nesse caso, criar um cluster de nós que se estendem por vários racks. O número de nós do cluster será influenciada pela quantidade de servidores que você tem no rack. Se você quiser que o seu grupo para conseguir a recuperação de desastres, além de alta disponibilidade, você terá os nós do cluster que irá abranger toda datacenters. Definindo domínios de falha podem protegê-lo de falhas de classe hardware.

Clusters multi-site

Para expandir o tópico anterior um pouco … quando se pensa em cenários de recuperação de desastres e ter um cluster de failover que podem atingir não só a alta disponibilidade, recuperação de desastres, mas também você pode abranger grupos em todo locais físicos. De um modo geral, o failover local é menos caro do que local de failover. O que significa que a replicação de dados no local de failover precisa virar, IP de pode mudar para diferentes sub-redes, e tempos de failover pode ser mais longo. Na verdade, a mudança para outro local pode exigir a aprovação de TI liderança. Ao implantar um cluster multi-site é recomendado para ampliar o número de nós de modo que há 2 ou mais nós em cada site. O objectivo é que, quando existe uma falha do servidor, existe rápido failover para um nó de sites locais. Então, quando há uma falha no site catastrófica, os serviços de failover para o site de recuperação de desastres. Definindo vários nós por domínio de falha pode dar-lhe melhores acordos de nível de serviço.

Todos os seus ovos em uma cesta

Não há limitações técnicas, o que torna um cluster tamanho melhor do que outro. Enquanto esperamos que nunca há uma falha enorme que resulta em um cluster inteiro para ir para baixo, alguns podem apontar que eles já vi isso acontecer … por isso não é uma questão de quantos ovos que você quer em uma cesta? Ao quebrar-se seus clusters, você pode ter vários domínios de falha, onde em caso de perda de um cluster inteiro também atenua impacto. Então, digamos que você tem 1.000 VMs … se você tem um único cluster de 32 nós, e todo o cluster vai para baixo, isso significa que todos os 1.000 VMs ir para baixo. Onde se eles tinham quebrado em dois grupos de 16 nós, apenas 500 VMs (meia) ir para baixo. Definindo domínios de falha podem protegê-lo de falhas de classe cluster.

Flexibilidade com um maior número de nós

System Center Virtual Machine Manager tem um recurso chamado Dynamic Optimization, que analisa a carga entre os nós e se move em torno de VMs para carregar equilibrar o cluster. Quanto maior o grupo, mais dinâmico Otimização nós tem que trabalhar com o melhor equilíbrio e que pode alcançar. Assim, enquanto a criação de vários clusters menores podem dividir-se vários domínios de falha, criando muito pequeno de clusters pode aumentar a gestão e mantê-los de que está sendo utilizada de forma otimizada. A definição de um conjunto maior cria granularidade a se espalhar e mover-se através.

Maior resiliência a falhas

Quanto mais nós que você tem em seu conjunto, menos impactante perdendo cada nó se torna. Então, digamos que você criar um grupo de pequenos grupos de 2 nós, se você fosse a perder 2 nós … todas as VMs ir para baixo. Onde se você tivesse um cluster de 4 nós, você pode perder 2 servidores eo cluster permanece acima e continua correndo. Novamente, isso os laços de volta mais para a discussão domínios de falha de hardware.

Outro aspecto disto é que, quando um nó falha, os mais nós sobreviventes tem de distribuir a carga através de. Então, digamos que você tem 2-nós … se você perder um nó, o nó sobrevivente está agora funcionando com capacidade de 200% (em execução tudo o que era antes, e todos os nós que falharam também). Se você dimensionar o número de nós, as VMs podem ser espalhados em mais hosts, ea perda de um nó individual é menos impactante. Se você tiver um cluster de 3 nós e perder um nó, cada nó está operando com capacidade de 150%.

Outra maneira de pensar sobre isso, é o quanto de esforço que você quer colocar em si mesmo? Se você tiver um cluster de 2 nós, e você perde um nó … você provavelmente terá uma simulação de incêndio para obter urgentemente esse nó fixo. Onde se você perder um nó em um cluster de 32 nós … que você pode estar ok terminar sua partida de golfe antes de se preocupar com isso. O aumento da escala pode protegê-lo de um maior número de falhas e faz um fracasso individual menos impactante.

Diagnosticabilidade

Solução de problemas um grande aglomerado às vezes pode ser mais difícil do que clusters menores. Digamos, por exemplo, você tem um problema em seu cluster de 64 nós, que pode envolver a puxar e correlacionando registros em todos os 64 servidores. Isto pode ser mais complexo e complicado para lidar com o grande número de registos. Outro exemplo é que a ferramenta de validação de cluster é uma ferramenta de teste funcional, e também vai demorar mais tempo em grupos maiores … quando as coisas dão errado e você quiser verificar o seu cluster. Alguns TI administração do preferem domínios de falhas menores na solução de problemas.

Workload

Você também escalar diferentes tipos de clusters de forma diferente com base na carga de trabalho que estão em execução:

  • Hyper-V: Você quer que sua nuvem privada para ser um sistema de fluido onde VMs estão se movendo em torno de forma dinâmica e ajustando. Ferramentas como o SCVMM dinâmico Otimização realmente começar a brilhar com grupos maiores para monitorar a carga dos nós e facilmente mover máquinas virtuais em torno de otimizar e balancear o cluster. Clusters de Hyper-V são geralmente o maior e pode ter 16, 24, 32 ou superior.
  • Servidor Scale-out do arquivo: armazenamento baseada em arquivo para as suas aplicações com sofs geralmente deve ser 2-4 nós. Por exemplo, grupos internos Microsoft sofs são implantados com 4 nós.
  • File Server tradicional: Tradicional Clusters operador de informações de arquivos tendem a ser também menor, novamente no 2-4 gama nó.
  • SQL Server: A maioria dos agrupamentos do SQL Server implantados com uma instância de cluster de failover (FCI) são 2-nós, mas isso tem mais a ver com o licenciamento do SQL Server ea capacidade de criar um FCI 2 nós com edição padrão SQL Server. A outra consideração é que cada instância do SQL requer uma letra de unidade. Então, isso é, no máximo, digamos que 24 casos. Esta questão é abordada com o SQL Server 2014 suporte para Volumes Compartilhados do Cluster … mas de um modo geral, não faz muito sentido para implantar um cluster do SQL Server de 32 nós. Então, acho que menor … 2, 4, ou talvez até 8. Um cluster SQL com um grupo de disponibilidade (AG) é geralmente um cluster multi-site e terá mais nós do que um FCI.

Conclusão

Não há resposta certa ou errada aqui em quantos nós de ter no seu cluster, muitos outros fornecedores têm fortes recomendações para contornar as limitações que possam ter … mas aqueles não se aplicam ao Windows Server Failover Clustering. É mais sobre o pensamento sobre os seus domínios de falha, e de preferência pessoal por uma grande parte. Grandes grupos são frescos e vêm com direito de se gabar graves, mas algumas considerações … pequenos grupos parecer simples, mas realmente não brilhar, bem como deveriam … você provavelmente vai encontrar o ajuste certo para você em algum lugar no meio.

Deixe uma resposta

Preencha os seus dados abaixo ou clique em um ícone para log in:

Logotipo do WordPress.com

Você está comentando utilizando sua conta WordPress.com. Sair / Alterar )

Imagem do Twitter

Você está comentando utilizando sua conta Twitter. Sair / Alterar )

Foto do Facebook

Você está comentando utilizando sua conta Facebook. Sair / Alterar )

Foto do Google+

Você está comentando utilizando sua conta Google+. Sair / Alterar )

Conectando a %s

%d blogueiros gostam disto: