it-swarm-pt.tech

Arquivos locais do SQL Server ou NAS ou SAN?

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

E quanto ao iSCSI, devo usá-lo?

E sobre SAN?

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

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

15
Jedi Master Spooky

[~ # ~] nas [~ # ~]

Definitivamente não NAS para SQL Server. SMB/CIFS não tem suporte adequado para bloqueio de arquivo para dar suporte a DBMS (pelo menos não tinha há alguns anos, ca. 2002-2003). Observe que 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. Pode até não permitir que você coloque arquivos em compartilhamentos montados em CIFS.

[~ # ~] san [~ # ~]

Isso é bom para aplicativos transacionais, pois o cache nos controladores RAID pode absorver conjuntos de trabalho bastante grandes. SAN Controladores RAID normalmente suportam mais cache do que controladores RAID baseados em Host, particularmente em kits de alta tecnologia onde um controlador RAID pode ser um multiprocessador que é tão poderoso quanto um servidor.

SANs com controladores duplos também têm uma arquitetura sem ponto único de falha e oferecem muitas opções para backup dinâmico. Isso os torna uma vitória de uma perspectiva de gerenciabilidade e confiabilidade. No entanto, eles são caros e limitados para volumes de dados de streaming, embora o último seja improvável que 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 executando sistemas de volume baixo-médio. No entanto, eles vêm com um preço que impõe um limite inferior substancial no menor sistema com o qual a tecnologia pode ser usada.

Conexão direta

Em alguns casos, o armazenamento de conexão direta é melhor. Uma possibilidade são os aplicativos de streaming com restrição de largura de banda, em que o número limitado de conexões de canal de fibra restringirá a largura de banda disponível para menos do que seria possível com um controlador SAS de ponta). No entanto, é provável que isso ocorra ser aplicativos bastante especializados, como armazéns de dados muito grandes, onde uma arquitetura nada compartilhado pode fornecer o melhor rendimento.

Na verdade, o armazenamento de conexão direta muitas vezes é melhor do que um SAN para sistemas de data warehouse por uma série de razões:

  • Os data warehouses colocam grandes picos de carga transitória nos subsistemas de disco. Isso os torna bastante anti-sociais em SANs, pois podem afetar o desempenho de outros sistemas em SANs.

  • O gargalo de streaming mencionado anteriormente.

  • O armazenamento de conexão direta é muito mais barato do que o armazenamento SAN).

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

20
ConcernedOfTunbridgeWells

Local ou SAN é a única maneira de manter o desempenho. Em alguns casos, SAN pode ser mais rápido que o disco local por causa do cache de gravação maior e configuração de taxa de transferência do disco paralelo .

Evite fazer qualquer I/O de arquivo 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, medi uma grande transferência de arquivo em um WAN era ~ 50% mais rápido usando FTP em compartilhamentos do Windows.

2
spoulson

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" o SAN com outros sistemas e recuperar muito do gasto inicial.

4 GB RAM é bom para a maioria dos sistemas, desde que seja um SQL Server dedicado (e sempre deve ser). Se você ainda não considerou isso, use o sistema operacional de 64 bits e o servidor SQL para que possa facilmente jogue mais RAM sem mexer com coisas 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 a postagem anterior: sql-server-in-vmware )

1
Guy

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

Com um banco de dados pequeno, apenas use os discos locais em RAID 1 ou RAID 10. Se seu banco de dados cabe na RAM, você não precisa se preocupar tanto com o desempenho de IO. Use 64- bit windows e colocar 8 Gigs nele. Isso vai deixar bastante para o sistema operacional e dar-lhe espaço para crescer.

1
Eric Z Beard

Eu trabalho com sistemas que usam disco RAID local e também SAN com conexão de fibra. O SAN parece ter um desempenho melhor, mesmo com o anterior 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 E/S de disco com o sistema operacional e o arquivo de troca. Isso provavelmente está contribuindo muito para o arrasto.

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

Em nosso caso, estamos usando SAN porque fornece uma área de armazenamento centralizado para grupos de serviço VERITAS SQL Server de failover automático. Quando a máquina primária falha, as unidades do Windows são montadas no SAN seja remontado à máquina de backup ativo e o servidor volta a funcionar muito rapidamente. Claro, isso requer um sistema semelhante ao VERITAS para gerenciamento de grupo de serviço que pode estar fora do seu escopo.

A única ressalva com a qual lutamos é que a atribuição de espaço em disco SAN atribuição de espaço em disco é tratada de forma conservadora. Como é cara, eles não o distribuem por capricho. Com o EMC SAN que usamos, você não pode recuperar o espaço atribuído sem despejar um LUN inteiro. Portanto, se descobrirmos que o espaço alocado é mais do que precisamos e quisermos usar parte desse espaço para outro LUN, não podemos basta reduzir o tamanho maior. Temos que descartá-lo e reatribuí-lo. Isso não funciona tão bem em um ambiente de produção.

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

0
Peter

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

De modo geral, você não deseja que seus drives SQL sejam compartilhados com nenhum outro aplicativo. Da mesma forma, quanto mais fusos (discos) você espalhar seus arquivos, melhor. Novamente, com um pequeno banco de dados como você descreveu, você será capaz de colocar tudo o que precisa na RAM, de forma que o desempenho do disco será menos importante.

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

Se você tiver orçamento para atualizar, adicione outro volume separado para TempDB (se você fizer qualquer relatório complexo/consultas analíticas) ou dê ao volume de registro mais discos e configure-o como RAID10 se seu sistema for mais transações com um volume alto de atualizações.

A SAN provavelmente custaria 3-4x mais do que o armazenamento de conexão direta para um número equivalente de unidades. As SANs fornecem muitos recursos avançados para backup/instantâneo, suporte a cluster e migração e expansão de LUNs. Se isso for importante para você, pode valer a pena a despesa adicional.

0
Chris B

Isenção de responsabilidade: 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 das questões relevantes está em MS KB304261 . No entanto, este tópico tornou-se um problema tudo para outras questões relacionadas ao SQL Server em um compartilhamento de rede, prefiro postar referências ao estado de NAS nas versões do SQL Server.

Muitas pessoas agora experimentam o uso de NAS com MS SQL.

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

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 em postagem de setembro de 201 no blog do MSDN de Varun Dhawan.

Pelo menos tecnicamente, executar o 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.

0
Dmitri Chubarov