Arquivos do SQL Server Local ou NAS ou SAN?

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

E o iSCSI devo usá-lo?

E quanto à SAN?

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

Para me esclarecer hoje que o servidor não possui RAID, tenho que implementar algum tipo de estratégia para que, se algo aconteça, eu possa ter meus arquivos seguros, então O que devo escolher Arquivos Locais, NAS, SAN? Qual opção tem mais desempenho, qual é a mais segura?

NAS

Definitivamente não é NAS para SQL Server. O SMB / CIFS não possui suporte adequado ao bloqueio de arquivos para suportar um DBMS (pelo menos há alguns anos, ca. 2002-2003). Observe 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. 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. Os controladores SAN RAID normalmente oferecem suporte a mais cache do que os controladores RAID baseados em host, particularmente no kit high-end, onde 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 ponto único de falha e oferecem muitas opções para backup quente. Isso os torna uma vitória do ponto de vista de gerenciamento e confiabilidade. No entanto, eles são caros e restritos ao fluxo de volumes de dados, embora não seja provável que este seja um problema em um sistema transacional.

Para sistemas operacionais, as SANs são quase sempre a melhor opção, se disponível. Eles também podem ser compartilhados entre vários servidores executando sistemas de baixo volume médio. No entanto, eles vêm com um preço que coloca 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 é o 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 Fibre Channel 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 sejam aplicativos bastante especializados, como data warehouses muito grandes, nos quais uma arquitetura de nada compartilhado pode fornecer a melhor taxa de transferência.

De fato, o armazenamento de conexão direta geralmente é melhor do que uma SAN para sistemas de data warehouse por vários motivos:

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

• O gargalo de streaming mencionado acima.

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

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

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 a uma configuração maior de cache de gravação e taxa de transferência de disco paralela.

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

Não use NAS.

Use local (OK a 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 recuperar grande parte das despesas iniciais.

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

Pense também em 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 )

Com um tamanho de banco de dados de 2 GB, não há motivo para considerar uma SAN. Um NAS não funcionará; você deve pensar apenas em usá-lo para backups, para não armazenar backups na mesma máquina que os 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 se preocupar tanto com o desempenho das E / S. Use janelas de 64 bits e coloque 8 Gigs lá. Isso deixará bastante para o sistema operacional e dará a você espaço para crescer.

Trabalho com sistemas que usam disco RAID local e SAN de conexão por 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 de disco local é uma unidade única, então o SQL está compartilhando a E / S de disco com o sistema operacional e o arquivo de troca. Provavelmente, isso está contribuindo fortemente para o arrasto.

Como o @spoulson mencionou, a SAN pode fornecer 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 centralizado para grupos de serviços VERITAS SQL Server de 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. Obviamente, isso requer um sistema semelhante ao VERITAS para gerenciamento de grupos de serviços que pode estar fora do seu escopo.

A única preocupação com a qual lutamos é que a atribuição de espaço em disco da SAN é tratada de maneira conservadora. Por ser caro, eles não dão a mínima por capricho. Com a EMC SAN que usamos, você não pode recuperar o espaço atribuído sem descarregar um LUN inteiro. Portanto, se acharmos que o espaço alocado é mais do que precisamos e queremos usar parte desse espaço para outro LUN, não podemos simplesmente reduzir o tamanho exagerado. Temos que largar e reatribuir. Isso não funciona tão bem em um ambiente de produção.

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

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

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

Dito isto, não 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, logs RAID1 - 2x 73GB 15K RPM, backups RAID1 - ú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ório / análise) ou dê ao volume de log mais discos e configure-o como RAID10 se o sistema tiver mais transações com um volume alto de atualizações.

Uma SAN provavelmente custaria de 3 a 4 vezes mais que o armazenamento de conexão direta para um número equivalente de unidades. As SANs oferecem muitos recursos avançados para backup / captura instantânea, suporte a cluster e migração e expansão de LUN. Se estes são importantes para você, pode valer a pena a despesa adicional.

Isenção de responsabilidade: Existem muitos problemas sérios no armazenamento de arquivos de banco de dados do SQL Server em um NAS. Sendo todas as outras opções iguais, é correto escolher a opção SAN. Uma discussão detalhada dos problemas relevantes está no 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 ao NAS nas versões do SQL Server.

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

Isso costumava ser proibido por padrão, no entanto, era possível suspender a restrição no MS SQL 2008 e no MS SQL 2005. Desde o MS SQL 2008 R2, não há 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 na publicação de setembro de 2010 no blog MSDN de Varun Dhawan.

É possível executar pelo menos tecnicamente o SQL Server em um NAS. 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.