SQL Server - armazenamento local (ssd) vs SAN

2

Eu pretendo alterar o hardware para o SQL Server e atualizá-lo para o SQL Server 2016 Enterprise. AlwaysOn AG será construído em cima de dois nós + dr.

Existem duas opções que tenho em mente para armazenamento:

tem apenas discos locais, ssd em RAID1, com discos separados para Windows, Dados, Logs e TempDb ter um híbrido de armazenamento local com ssd's para TempDb (RAID1) e o restante dos discos para Windows, Data e Logs ser provisionado de uma SAN pela rede Eu pessoalmente prefiro a opção com tudo no armazenamento local, porque:

você se livra do ponto único de falha (a SAN) velocidades mais rápidas no armazenamento local, a SAN não terá sem gargalos de rede Há alguma desvantagem importante de usar armazenamento local?

O uso de SAN para armazenamento é uma opção melhor?

Independentemente da solução, o hardware será alugado de um provedor de hardware. Portanto, não haverá compra envolvida.

Obrigado antecipadamente!

    
por silviu.f 31.03.2017 / 09:54

3 respostas

2

Com relação ao docs você deve ir com armazenamento local ou armazenamento compartilhado ou Microsoft Storage Spaces Direct.

Supondo que você alcance a disponibilidade para o MSSQL Server, sugiro que você use o armazenamento local, configuração idêntica para cada host, que forneceria o mesmo desempenho para o caso de falha no nó.

Vá com armazenamento compartilhado se você quiser usar o MSSQL FCI.

Quanto ao SAN, seu SPoF. IMHO

    
por 03.04.2017 / 19:13
1

Como sempre, há muitas vantagens e desvantagens em tudo.

Um storage array fornece alta capacidade e gerenciamento centralizado. Você pode capturar alguns volumes e apresentá-los a outro host. Embora os switches e o cabeamento para conectar o SAN possam ser um pouco mais complicados.

O armazenamento local tem menos nós de servidor envolvidos e pode ser mais familiar para o administrador do sistema operacional. Pode haver limites na capacidade que cabem no servidor, a menos que você adicione algo como um compartimento de disco.

A replicação em nível de banco de dados torna relativamente fácil usar dois sistemas de armazenamento independentes para uma solução de continuidade de negócios. Uma falha no nível de armazenamento pode ser atenuada ativando o DR. O ponto único de análise de falhas ainda é uma boa ideia, verificando fontes de alimentação redundantes, caminhos de SAN e outros. A cópia de DR, possivelmente em um site remoto, torna a recuperação mais rápida se a cópia principal ficar indisponível.

    
por 01.04.2017 / 15:48
0

Pessoalmente, estou vendo SANs se tornando uma relíquia de uma época passada. Não me entenda mal - como o mainframe, eles têm o seu lugar e, usados apropriadamente, são extremamente valiosos. Grandes instalações de virtualização não seriam possíveis sem elas. Era uma vez, o armazenamento compartilhado como uma SAN era a única maneira de tornar as coisas como SQL Server ou VMWare ESXi altamente disponíveis.

Mas obter uma SAN tão rápida quanto o armazenamento SSD local é muito caro. Para obter um que é tão rápido quanto o armazenamento NVMe (como um Intel P3608) é em seis dígitos. Em comparação com US $ 8.000 para um top de linha 4TiB P3608 - mais barato se você não precisa de 4TiB de armazenamento.

Com o Always On do SQL Server fornecendo uma boa opção de alta disponibilidade, com armazenamento local, opções de replicação síncrona ou assíncrona e com Grupos de disponibilidade distribuídos , não há motivo para implantar uma SAN na grande maioria das novas instalações do SQL Server.

Não há desvantagem em usar o armazenamento local no que diz respeito ao SQL Server.

    
por 03.04.2017 / 19:27