File di SQL Server locali o NAS o SAN?

Devo installare un nuovo server con SQL Server 2008, cosa mi consigliate, un server con Raid 10 o i file in un NAS?

Che dire di iSCSI dovrei usarlo?

Che dire di SAN?

Il server ha 4 GB di RAM e quel file di database è di circa 2 GB.

Per rendermi chiaro oggi che il server non ha RAID, devo implementare un qualche tipo di strategia, quindi se qualcosa dovesse accadere potrei avere i miei file al sicuro, quindi Cosa dovrei scegliere Local Files, NAS, SAN? Quale opzione offre il massimo delle prestazioni, qual è la più sicura?

NAS

Sicuramente non NAS per SQL Server. SMB / CIFS non ha un supporto adeguato per il blocco dei file per supportare un DBMS (almeno non alcuni anni fa, circa 2002-2003). Nota che NFS lo fa e puoi effettivamente farlo con Oracle su un server NFS. Tuttavia, SQL Server su una condivisione CIFS non è affidabile a causa delle limitazioni del protocollo. Potrebbe anche non consentire di inserire file su condivisioni montate su CIFS.

SAN

Questo è utile per le applicazioni transazionali in quanto la cache dei controller RAID può assorbire gruppi di lavoro abbastanza grandi. I controller SAN RAID in genere supportano più cache rispetto ai controller RAID basati su host, in particolare sui kit di fascia alta in cui un controller RAID potrebbe essere un box multiprocessore potente quanto un server.

Le SAN con doppio controller hanno anche un'architettura senza alcun punto di errore e offrono molte opzioni per il backup a caldo. Questo li rende una vittoria dal punto di vista della gestibilità e dell'affidabilità. Tuttavia sono costosi e limitati per i volumi di dati in streaming, anche se è improbabile che quest'ultimo sia un problema su un sistema transazionale.

Per i sistemi operativi, le SAN sono quasi sempre la scelta migliore se disponibili. Possono anche essere condivisi tra più server che eseguono sistemi di volume medio-basso. Tuttavia, vengono forniti con un prezzo che pone un limite decisamente inferiore al sistema più piccolo con cui la tecnologia può essere utilizzata.

Collegamento diretto

In alcuni casi, è preferibile l'archiviazione diretta degli allegati. Una possibilità sono le applicazioni di streaming con larghezza di banda limitata, in cui il numero limitato di connessioni a canale in fibra limiterà la larghezza di banda disponibile a un valore inferiore rispetto a quanto sarebbe possibile con un controller SAS di fascia alta. Tuttavia, è probabile che si tratti di applicazioni abbastanza specializzate come data warehouse di grandi dimensioni in cui un'architettura a nulla condiviso può fornire il miglior throughput.

In effetti, l'archiviazione diretta degli allegati è spesso migliore di una SAN per i sistemi di data warehouse per una serie di motivi:

• I data warehouse mettono forti picchi di carico transitorio sui sottosistemi di dischi. Ciò li rende piuttosto anti-social sulle SAN poiché possono influenzare le prestazioni di altri sistemi sulla SAN.

• Il suddetto collo di bottiglia in streaming.

• Lo storage con collegamento diretto è molto più economico dello storage SAN.

Un altro mercato per l'archiviazione diretta è quando si vende a un mercato che non pagherà abbastanza denaro per una SAN. Ciò vale spesso per le applicazioni vendute ai clienti delle PMI. Per un sistema point-of-sale o un sistema di gestione pratica che avrà sei utenti una SAN è probabilmente eccessiva. In questo tipo di situazione, un piccolo server tower autonomo con alcuni dischi interni è una soluzione molto più appropriata.

Local o SAN è l'unico modo per mantenere le prestazioni. In alcuni casi, SAN può essere più veloce del disco locale a causa della cache di scrittura più grande e della configurazione della velocità effettiva del disco parallelo.

Evitare di eseguire operazioni di I / O su file ad alte prestazioni su condivisioni Windows. Esiste una grande quantità di overhead di protocollo che rallenterà notevolmente la velocità di trasmissione. Ad esempio, anni fa ho misurato che un trasferimento di file di grandi dimensioni su una WAN era ~ 50% più veloce usando FTP su condivisioni Windows.

Non usare il NAS.

Utilizzare locale (OK a medio termine con un buon controller RAID) ma se il budget lo consente, scegliere una SAN decente. Con un po 'di fortuna puoi iniziare a "condividere" la SAN con altri sistemi e recuperare gran parte dell'esborso iniziale.

La RAM da 4 GB va bene per la maggior parte dei sistemi purché sia ​​un SQL Server dedicato (e dovrebbe sempre essere). Se non lo hai già considerato, usa il sistema operativo 64 bit e il server SQL in modo da poter facilmente aggiungere più RAM senza confonderti con le cose PAE / AWE.

Pensa anche alla virtualizzazione. Avrai bisogno di un server di prova? Un server di sviluppo? Testare l'installazione di SP1? (Plus spudorato per post precedente: sql-server-in-vmware )

Con una dimensione del database di 2 GB, non vi è alcun motivo per considerare una SAN. Un NAS non funzionerà, dovresti solo pensare di utilizzare un NAS per i backup in modo da non archiviare i backup sulla stessa macchina dei tuoi dati ed è facile fare copie dal NAS per l'archiviazione off-site.

Con un piccolo database, basta usare i dischi locali in un RAID 1 o RAID 10. Se il database si adatta alla RAM, non è necessario preoccuparsi delle prestazioni di I / O. Usa le finestre a 64 bit e inserisci 8 concerti. Ciò lascerà molto al sistema operativo e ti darà spazio per crescere.

Lavoro con sistemi che utilizzano sia dischi RAID locali che SAN con connessione in fibra. La SAN sembra funzionare meglio anche se la prima è una macchina più nuova e più veloce. Penso che un fattore significativo sia che la disposizione del disco locale è una singola unità, quindi SQL condivide l'I / O del disco con il sistema operativo e il file di scambio. Ciò probabilmente sta contribuendo pesantemente alla resistenza.

Come menzionato @spoulson, la SAN può fornire prestazioni del disco molto migliori. Non è solo un'unità separata, ma è probabilmente su hardware del disco molto più veloce.

Nel nostro caso, stiamo utilizzando SAN perché fornisce un'area di archiviazione centralizzata per i gruppi di servizi VERITAS SQL Server con failover automatico. Quando la macchina primaria si guasta, le unità Windows montate sulla SAN vengono rimontate sulla macchina di backup a caldo e il server torna indietro abbastanza rapidamente. Naturalmente, ciò richiede un sistema simile a VERITAS per la gestione dei gruppi di servizi che potrebbe essere al di fuori del proprio ambito di applicazione.

L'unica avvertenza con cui abbiamo lottato è che l'assegnazione dello spazio su disco SAN è gestita in modo conservativo. Perché è costoso, non lo tirano fuori per un capriccio. Con EMC SAN che utilizziamo, non è possibile recuperare spazio assegnato senza scaricare un intero LUN. Quindi se troviamo che lo spazio allocato è più del necessario e vogliamo usare parte di quello spazio per un altro LUN, non possiamo semplicemente ridurre quello sovradimensionato. Dobbiamo lasciarlo cadere e riassegnare. Questo non funziona così bene in un ambiente di produzione.

Come altri hanno suggerito, evitare il NAS. Potresti anche mettere i tuoi file di dati su un disco rigido esterno USB.

Per un piccolo database da 2 GB, una SAN sarebbe eccessiva.

In generale, non si desidera che le unità SQL vengano condivise con qualsiasi altra applicazione. Allo stesso modo, più mandrini (dischi) è possibile distribuire i file, meglio è. Ancora una volta, con un piccolo database come quello che descrivi, sarai in grado di adattare tutto ciò che ti serve nella RAM, quindi le prestazioni del disco saranno meno importanti.

Detto questo, non andare e creare un singolo volume RAID-10 e inserire TUTTI i file del database su di esso. Potresti iniziare con qualcosa di semplice come: Dati - 2x 73 GB 15K RPM, registri RAID1 - 2x 73GB 15K RPM, backup RAID1 - singolo grande 7200 RPM o una coppia in RAID1

Se si dispone del budget per l'aggiornamento, aggiungere un altro volume separato per TempDB (se si eseguono query di report / analisi complesse) o assegnare al volume Log più dischi e configurarlo come RAID10 se il sistema è più transazione con un volume elevato di aggiornamenti.

Una SAN costerebbe 3-4 volte tanto quanto lo storage collegato direttamente per un numero equivalente di unità. Le SAN offrono molte funzionalità avanzate per backup / snapshot, supporto cluster e migrazione ed espansione LUN. Se questi sono importanti per te, può valere la spesa aggiuntiva.

Dichiarazione di non responsabilità: ci sono molti problemi seri con l'archiviazione dei file di database di SQL Server su un NAS. A parità di tutte le altre opzioni, è corretto scegliere l'opzione SAN. Una discussione dettagliata delle questioni rilevanti è contenuta nel documento di riferimento KB304261 . Tuttavia, questo thread è diventato un problema per tutte le altre domande relative a SQL Server in una condivisione di rete, preferirei pubblicare riferimenti allo stato del supporto NAS nelle versioni di SQL Server.

Molte persone ora sperimentano l'uso del NAS con MS SQL.

Questo era proibito per impostazione predefinita, tuttavia si potrebbe eliminare la restrizione in MS SQL 2008 e MS SQL 2005. Da MS SQL 2008 R2 non esiste tale restrizione.

In MS SQL 2005 e 2008 la chiave è il flag di traccia che proibisce l'uso di condivisioni di rete. Uno può emettere

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

Maggiori dettagli nel post di settembre 2010 nel blog MSDN di Varun Dhawan.

Almeno tecnicamente è possibile eseguire SQL Server su un NAS. La scelta dipende da molti fattori e non è difficile immaginare una situazione in cui l'archiviazione per un database è prontamente disponibile su un NAS.