Domanda

Voglio accedere ai file del database del mio server sql in una memoria INTEL SS4000-E. È un archivio NAS. Potrebbe essere possibile lavorare con esso come memoria per SQL Server 2000? In caso contrario, qual è la soluzione migliore?

È stato utile?

Soluzione

Lo sconsiglio vivamente.

Metti i tuoi file di dati localmente sul server stesso, con unità con mirroring RAID. Le ragioni sono duplici:

  • SQL Server funzionerà molto più velocemente per tutti tranne i carichi di lavoro più piccoli
  • SQL Server sarà molto meno soggetto alla corruzione nel caso in cui il collegamento al NAS venga interrotto.

Utilizzare il NAS per archiviare i backup di SQL Server, non per ospitare i file di dati. Non so quale sarà la dimensione del tuo database o quale sarà il tuo modello di utilizzo, quindi non posso dirti cosa DEVI avere. Come minimo per un database che avrà un carico significativo in un ambiente di produzione, consiglierei due unità logiche (una per i dati, una per il registro delle transazioni), ognuna composta da un array RAID 1 delle unità più veloci che puoi caricare comprare. Se questo è eccessivo, metti il ??tuo database su solo due unità fisiche (una per il registro delle transazioni e una per i dati). Se anche QUELLO è oltre il budget, metti i tuoi dati su una singola unità, esegui il backup spesso. Ma se scegli la soluzione a unità singola o NAS, IMO stai riponendo la tua fiducia nel Potere della Preghiera (che potrebbe non essere una brutta cosa, non è così efficace quando si progettano database).

Si noti che un NAS non è la stessa cosa di una SAN (su cui le persone generalmente inseriscono file di database). Un NAS in genere è molto più lento e presenta una larghezza di banda molto inferiore rispetto a una connessione SAN, progettata per affidabilità molto elevata, alta velocità, gestione avanzata e bassa latenza. Un NAS è orientato maggiormente alla riduzione dei costi di archiviazione di rete.

Altri suggerimenti

La mia reazione istintiva - Penso che tu sia pazzo a rischiare i tuoi dati su un NAS. L'aspettativa di SQL è un accesso ininterrotto continuo a bassa latenza al sottosistema di archiviazione. Il NAS non è quasi certamente una di queste cose - archiviazione locale o SAN (in ordine di prestazioni, semplicità e quindi preferenza) - lasciare il NAS per l'archiviazione / backup dei file offline.

Il seguente KB elenca alcuni dei vincoli e dei problemi che potresti incontrare nel tentativo di utilizzare un NAS con SQL - mentre il KB copre SQL 7 fino al 2005, molte informazioni si applicano anche a SQL 2008.

  

http://support.microsoft.com/kb/304261

local è quasi sempre più veloce dello storage in rete.

Le tue prestazioni per sql dipenderanno dalla definizione di oggetti, file e filegroup e dal modo in cui i consumatori utilizzano i dati.

Bene " migliore " significa cose diverse per persone diverse, ma penso che "meglio" le prestazioni sarebbero un TMS RAMSAN o un RAID di SSD ... ecc.

La migliore capacità sarebbe raggiunta con un RAID di HDD di grandi dimensioni ...

La migliore affidabilità / sicurezza dei dati sarebbe raggiunta con il mirroring su molte unità e backup regolari (preferibilmente fuori sede) ...

Migliore disponibilità ... Non lo so ... forse un clone del sistema e un backup a caldo pronto per essere eseguito in qualsiasi momento.

La migliore sicurezza richiederebbe la crittografia, ma limitare l'accesso fisico alla macchina (e ai suoi backup) è sufficiente a meno che non sia connesso a Internet.

Come sottolineato dalle altre risposte, ci sarà una penalità per le prestazioni qui.

Vale anche la pena ricordare che queste cose a volte implementano una cache RAM per migliorare le prestazioni di I / O, se questo è il caso e si verifica questa configurazione, il NAS dovrebbe avere la stessa protezione dell'alimentazione / UPS dell'hardware del server , altrimenti in caso di interruzione dell'alimentazione il NAS potrebbe "perdere" la parte del file nella cache. ahi!

Può funzionare ma una SAN dedicata in fibra dedicata sarà migliore.

Il locale di solito sarà più veloce ma ha dimensioni limitate e non si ridimensionerà facilmente.

Non ho familiarità con l'hardware ma inizialmente abbiamo distribuito un magazzino su un NAS condiviso. Ecco cosa abbiamo trovato.

Siamo regolarmente in competizione per le risorse sull'unità principale - c'era solo così tanta larghezza di banda che poteva gestire. Le enormi richieste di magazzino e il carico di dati sono stati fortemente influenzati.

Avevamo bisogno di 1,5 TB per il nostro magazzino (dati / indici / registri) e abbiamo inserito ciascuna di queste risorse in un set separato di LUN (come si potrebbe fare con l'archiviazione collegata). I dati riguardavano solo 10 dischi. Ci siamo imbattuti in tutti i tipi di colli di bottiglia di IO con questo. la soluzione migliore era quella di creare una grande partizione attraverso molti piccoli dischi e archiviare dati, indicizzare e registrare tutti nello stesso posto. Ciò ha accelerato notevolmente le cose.

Se hai a che fare con un sistema OLTP usato moderatamente, potresti andare bene, ma un NAS può essere problematico.

Autorizzato sotto: CC-BY-SA insieme a attribuzione
Non affiliato a StackOverflow
scroll top