Arquivos do SQL Server Local ou NAS ou SAN?

Question

Eu tenho que instalar um novo servidor com o SQL Server 2008, o que você recomendaria, um servidor com Raid 10 ou os arquivos em um NAS?

E o iSCSI, devo usá-lo?

E a SAN?

O servidor tem 4Gb de RAM e esse arquivo de banco de dados tem cerca de 2GB.

Para deixar claro hoje, o servidor não tem RAID, eu tenho que implementar algum tipo de estratégia, então se algo acontecer eu puder ter meus arquivos seguros, então o que devo escolher Arquivos locais, NAS, SAN? Qual opção tem o maior desempenho, qual é o mais seguro?

    

Answer 1

NAS

Definitivamente, não é NAS para o SQL Server. O SMB / CIFS não possui suporte adequado para o bloqueio de arquivos para suportar um DBMS (pelo menos há alguns anos, ca. 2002-2003). Note que o NFS faz e você pode realmente fazer isso com o Oracle em um servidor NFS. No entanto, o SQL Server em um compartilhamento CIFS não é confiável devido às limitações do protocolo. Talvez nem permita colocar arquivos em compartilhamentos montados no CIFS.

SAN

Isso é bom para aplicativos transacionais, pois o cache nos controladores RAID pode absorver conjuntos de trabalho bastante grandes. Os controladores SAN RAID normalmente suportam mais cache do que os controladores RAID baseados em host, particularmente no kit high-end, no qual um controlador RAID pode ser uma caixa de multiprocessador tão poderosa quanto um servidor.

As SANs com controladores duplos também têm uma arquitetura sem nenhum ponto de falha e oferecem muitas opções para backups a quente. Isso os torna uma vitória de uma perspectiva de gerenciamento e confiabilidade. No entanto, eles são caros e restritos para o streaming de volumes de dados, embora seja improvável que o último seja um problema em um sistema transacional.

Para sistemas operacionais, as SANs são quase sempre a melhor escolha, se disponível. Eles também podem ser compartilhados entre vários servidores que executam sistemas de volume baixo-médio. No entanto, eles vêm com um preço que coloca um limite inferior bastante substancial no menor sistema com o qual a tecnologia pode ser usada.

Ligação Directa

Em alguns casos, o armazenamento direto de anexos é o melhor. Uma possibilidade são os aplicativos de fluxo limitado por largura de banda, em que o número limitado de conexões de canal de fibra restringirá a largura de banda disponível a menos do que seria possível com um controlador SAS de ponta. No entanto, é provável que esses aplicativos sejam bastante especializados, como armazéns de dados muito grandes, em que uma arquitetura shared-nothing pode oferecer a melhor Taxa de transferência.

Na verdade, o armazenamento de anexação direta geralmente é melhor do que uma SAN para sistemas de data warehouse por vários motivos:

• Os data warehouses colocam grandes picos de carga temporários nos subsistemas de disco. Isso os torna bastante antissociais em SANs, pois podem afetar o desempenho de outros sistemas na SAN.

• O afunilamento de streaming acima mencionado.

• Armazenamento de anexação direta é muito mais barato que o armazenamento SAN.

Outro mercado para armazenamento de anexação direta é quando você está vendendo para um mercado que não pagará dinheiro suficiente para uma SAN. Isso geralmente é verdade para aplicativos vendidos a clientes SMB. Para um sistema de ponto de venda ou sistema de gerenciamento de prática que terá seis usuários, uma SAN é provavelmente um exagero. Nesse tipo de situação, um pequeno servidor de torre independente com alguns discos internos é uma solução muito mais apropriada.

    

Answer 2

Local ou SAN é a única maneira de manter o desempenho. Em alguns casos, a SAN pode ser mais rápida que o disco local, devido à configuração maior de cache de gravação e de rendimento de disco paralelo.

Evite fazer qualquer E / S de arquivos de alto desempenho em compartilhamentos do Windows. Há uma grande quantidade de sobrecarga de protocolo que reduzirá drasticamente a taxa de transferência. Por exemplo, anos atrás, eu medi que uma grande transferência de arquivos em uma WAN era ~ 50% mais rápida usando FTP sobre compartilhamentos do Windows.

    

Answer 3

Não use NAS.

Use local (OK para médio prazo com um bom controlador RAID), mas se o orçamento permitir, escolha uma SAN decente. Com sorte, você pode começar a "compartilhar" a SAN com outros sistemas e a recuperar muito do desembolso inicial.

A RAM de 4 GB é adequada para a maioria dos sistemas, desde que seja um SQL Server dedicado (e deve ser sempre). Se você ainda não o considerou, use um sistema operacional de 64 bits e um servidor SQL para que você possa facilmente adicionar mais RAM sem mexer com o material PAE / AWE.

Pense também na virtualização. Você vai precisar de um servidor de teste? Um servidor de desenvolvimento? Testar a instalação do SP1? (Shameless plus para post anterior: sql-server-in-vmware )

    

Answer 4

Com um tamanho de banco de dados de 2 GB, não há motivo para considerar sequer uma SAN. Um NAS não funcionará, você deve pensar apenas em usar um NAS para backups, para que não esteja armazenando backups na mesma máquina que seus dados, e é fácil fazer cópias do NAS para armazenamento externo.

Com um banco de dados pequeno, basta usar discos locais em um RAID 1 ou RAID 10. Se o seu banco de dados couber na RAM, você não precisa ficar tão preocupado com o desempenho do IO. Use janelas de 64 bits e coloque 8 Gigs lá. Isso deixará bastante espaço para o sistema operacional e dará espaço para você crescer.

    

Answer 5

Eu trabalho com sistemas que usam disco RAID local, bem como SAN de conexão de fibra. A SAN parece ter um desempenho melhor, mesmo com a primeira sendo uma máquina mais nova e mais rápida. Eu acho que um fator significativo é que o arranjo do disco local é uma única unidade, então o SQL está compartilhando a E / S do disco com o SO e o arquivo de troca. Isso provavelmente está contribuindo strongmente para o arrasto.

Como o @spoulson mencionou, a SAN pode oferecer um desempenho de disco muito melhor. Não é apenas uma unidade separada, mas é provavelmente em um hardware de disco muito mais rápido.

No nosso caso, estamos usando a SAN porque ela fornece uma área de armazenamento centralizada para grupos de serviços do VERITAS SQL Server com failover automático. Quando a máquina principal falha, as unidades do Windows montadas na SAN são remontadas para a máquina de backup quente e o servidor volta rapidamente. É claro que isso requer um sistema semelhante ao VERITAS para gerenciamento de grupos de serviços que pode estar fora do seu escopo.

A única ressalva com a qual nos debatemos é que a atribuição de espaço em disco da SAN é tratada de maneira conservadora. Porque é caro, eles não fazem isso por capricho. Com o EMC SAN usado, você não pode recuperar o espaço atribuído sem despejar um LUN inteiro. Portanto, se acharmos que o espaço alocado é maior do que o necessário e queremos usar um pouco desse espaço para outro LUN, não podemos simplesmente reduzir o espaço maior. Temos que abandonar e reatribuir. Isso não funciona tão bem em um ambiente de produção.

Como outros sugeriram, evite o NAS. Você pode também colocar seus arquivos de dados em um disco rígido externo USB.

    

Answer 6

Para um pequeno banco de dados de 2 GB, uma SAN seria um exagero.

Em geral, você não quer que suas unidades SQL sejam compartilhadas com qualquer outro aplicativo. Da mesma forma, quanto mais fusos (discos) você puder distribuir seus arquivos, melhor. Novamente, com um banco de dados pequeno como você descreve, você poderá ajustar tudo o que precisa na RAM, para que o desempenho do disco seja menos importante.

Dito isso, não crie um único volume & RAID-10; Coloque TODOS os seus arquivos de banco de dados nele. Você poderia começar com algo simples como: Dados: 2x 73 GB 15K RPM, RAID1 Registros - 2x 73GB 15K RPM, RAID1 Backups - único grande 7200 RPM ou um par em RAID1

Se você tiver o orçamento para atualizar, adicione outro volume separado para o TempDB (se você fizer consultas complexas de relatórios / análises) ou forneça ao volume de registro mais discos & configurá-lo como RAID10 se você é o sistema é mais transação w / um alto volume de atualizações.

Uma SAN provavelmente custaria 3-4x tanto quanto o armazenamento de conexão direta para um número equivalente de unidades. As SANs fornecem muitos recursos avançados para backup / snapshot, suporte a clustering & Migração e expansão do LUN. Se isso for importante para você, pode valer a despesa adicional.

    

Answer 7

Aviso: Existem muitos problemas sérios com o armazenamento de arquivos de banco de dados do SQL Server em um NAS. Todas as outras opções sendo iguais, é correto escolher a opção SAN. Uma discussão detalhada dos problemas relevantes está em MS KB304261 . No entanto, esse segmento tornou-se um problema para outras questões relacionadas ao SQL Server em um compartilhamento de rede; prefiro postar referências ao estado do suporte NAS nas versões do SQL Server.

Muita gente já experimenta usar o NAS com o MS SQL.

Isso costumava ser proibido por padrão, no entanto, pode-se levantar a restrição no MS SQL 2008 e no MS SQL 2005. Desde o MS SQL 2008 R2 não existe essa restrição.

No MS SQL 2005 e 2008, a chave é o sinalizador de rastreamento que proíbe o uso de compartilhamentos de rede. Pode-se emitir

 DBCC TRACEON(1807, -1)
 CREATE DATABASE [test] ON  PRIMARY 
 ( NAME = N'test', FILENAME = N'\storage\mssql_db\test.mdf' )

Mais detalhes no postagem de setembro de 2010 no blog do MSDN de Varun Dhawan.

Pelo menos, a execução técnica do SQL Server em um NAS é possível. A escolha depende de muitos fatores e não é difícil imaginar uma situação em que o armazenamento de um banco de dados esteja prontamente disponível em um NAS.