Servidor de arquivos em cluster no Windows 2012 com armazenamento local

5

Portanto, tenho um grupo SQL Always-On que requer uma testemunha de compartilhamento de arquivos. Eu quero que essa testemunha de compartilhamento de arquivos seja redundante e, como não tenho outra necessidade para um servidor de arquivos nessa rede, gostaria de fazê-lo com o menor número de servidores.

Eu pensei em configurar dois servidores com DFS, mas este artigo diz que não fazer isso porque o DFS às vezes pode usar os dados de um servidor e às vezes usar outro, atrapalhando o quorum: link

Parece que eu preciso de um cluster de failover do Windows verdadeiro / real, configurado na função de servidor de arquivos. O problema é que todos os artigos que li falam sobre o uso de armazenamento compartilhado. Mas o armazenamento compartilhado (por exemplo, uma SAN) exigiria um terceiro servidor e, novamente, eu tenho um único ponto de falha (a SAN). E realmente prefiro comprar apenas 2 novos servidores em vez de 3. Vejo que também posso usar os Espaços de Armazenamento do Windows como uma alternativa a uma SAN, mas isso requer 3 discos, o que é ainda pior na compra de hardware.

Qual é a melhor maneira de configurar um compartilhamento de arquivos redundante para uma testemunha sem comprar muitos servidores ou ter uma única falha no ponto da SAN? Obviamente, gostaria de usar o armazenamento local, mas posso configurar o cluster de arquivos para que ele use o disco rígido do servidor 1 o tempo todo quando o servidor 1 for o primário e o disco rígido do servidor 2 o tempo todo quando o servidor 2 for o primário e usar o DFS para replicar dados no caso de um dos servidores morrer? Eu acho que desta forma evitaria a preocupação "somente DFS" mencionada no artigo acima e ainda me manteria em apenas 2 servidores.

    
por stackonfire 15.01.2016 / 21:50

3 respostas

5

Com base no requisito de armazenamento compartilhado, presumo que seja AlwaysON FCI (Instâncias de Cluster de Failover) A solução mais fácil para você seria implantar uma SAN virtual. O Virtual SAN tomará o armazenamento local dos 2 nós SQL que você possui e apresentará de volta a eles como um disco virtual altamente disponível. Agora, se um dos nós do cluster SQL falhar, você ainda terá uma cópia dinâmica dos seus dados e um failover de SQL. Embora a maioria dos produtos de Virtual SAN sejam apenas comerciais, também é possível obter os gratuitos com diferentes níveis de restrições:

  1. Datacore SAN vitrual - Emula apenas armazenamento FC, livre somente para uso não-produtivo. Precisa enviar um formulário e responder algumas perguntas para obtê-lo.
  2. O VSA gratuito da HP - emula iSCSI, tem limitação de 1 TB (não deve ser um problema com o SQL), mas requer pelo menos 3 servidores. Não tenho certeza se o uso de produção é permitido.
  3. StarWind Virtual SAN Free - Emula iSCSI, NFS & SMB3. Há também pelo menos duas ofertas de licenças gratuitas. Uma é uma licença de 2 nós disponível para todos, pode fornecer NFS & Armazenamento SMB3. Uso de produção é suportado. O segundo é um Virtual SAN de dois nós totalmente desenvolvido que oferece armazenamento tolerante a falhas por meio de iSCSI, DMA, NFS e SMB3. Uso de produção também suportado. Para obter esse, você precisa ser um MCP / MVP ou VCP / vExpert ou um colaborador ativo de comunidades on-line. (Eu tenho atualmente o segundo, você terá que contatá-los para obter um)

Veja um vídeo sobre a implantação do SQL AlwaysOn FCI com armazenamento de SAN virtual (no Azure, mas o processo é o mesmo)

    
por 18.01.2016 / 13:09
2

O Windows Server não oferece suporte a clusters de failover sem compartilhamento até o momento. Você precisa de um dispositivo compartilhado que suportaria reservas SCSI para servir como armazenamento em cluster (em qualquer tipo de função). Isso vai mudar com o Windows Server 2016, que está introduzindo as réplicas de armazenamento :

Storage Replica is a new feature in Windows Server 2016 Technical Preview that enables storage-agnostic, block-level, synchronous replication between clusters or servers for disaster preparedness and recovery, as well as stretching of a failover cluster across sites for high availability. Synchronous replication enables mirroring of data in physical sites with crash-consistent volumes ensuring zero data loss at the file system level.

Mas o seu problema será o de um tipo de galinha e ovo. Você deseja um compartilhamento de testemunha para que seu cluster possa criar um quórum para uma decisão de failover em casos de falha. Você deseja colocar esse compartilhamento de testemunha em um cluster de máquinas que consiste em dois nós físicos. Então, o que você precisa agora, de repente, é outra testemunha para seu cluster de servidores de arquivos . Isso não vai resolver o seu problema.

A linha inferior é: você não deve criar um cluster de servidores de arquivos apenas para o compartilhamento de testemunhas do Grupo de Disponibilidade . A disponibilidade da testemunha não é tão crucial, pois não afetará as operações de suas instâncias do servidor SQL. Se a testemunha não estiver disponível, tudo o que você perderá será o recurso de failover automático para outro (s) membro (s) de sua AG.

Dito isto, você ainda deve tomar cuidado para manter o tempo de reparo do compartilhamento de testemunhas baixo. Especialmente porque provavelmente não lhe custará nada além de documentação de procedimentos - uma máquina de backup em espera que precisaria lidar com apenas 2 conexões com baixas taxas de dados pode ser literalmente o desktop de domínio de seu chefe por uma conexão VPN.

    
por 16.01.2016 / 15:29
-1

Você também pode usar o DFS com dois servidores e armazenamento local. Basta configurar o DFS corretamente. Desculpe, mas não posso fornecer mais informações neste momento.

    
por 16.01.2016 / 08:13