NAS
Certainement pas NAS pour SQL Server. SMB / CIFS ne dispose pas d'une prise en charge adéquate du verrouillage de fichiers pour prendre en charge un SGBD (du moins il n'y a pas quelques années, vers 2002-2003). Notez que NFS le fait et vous pouvez réellement le faire avec Oracle sur un serveur NFS. Cependant, SQL Server sur un partage CIFS n'est pas fiable en raison des limitations du protocole. Il peut même ne pas vous permettre de placer des fichiers sur des partages montés CIFS.
SAN
C'est bon pour les applications transactionnelles car le cache des contrôleurs RAID peut absorber des ensembles de travail assez volumineux. Les contrôleurs RAID SAN prennent généralement en charge plus de cache que les contrôleurs RAID basés sur l'hôte, en particulier sur les kits haut de gamme où un contrôleur RAID peut être un boîtier multiprocesseur aussi puissant qu'un serveur.
Les SAN avec deux contrôleurs ont également une architecture sans point de défaillance unique et offrent de nombreuses options de sauvegarde à chaud. Cela en fait une victoire dans une perspective de gérabilité et de fiabilité. Cependant, ils sont coûteux et limités pour le streaming de volumes de données, bien que ce dernier ne soit probablement pas un problème sur un système transactionnel.
Pour les systèmes opérationnels, les SAN sont presque toujours le meilleur choix s'ils sont disponibles. Ils peuvent également être partagés entre plusieurs serveurs exécutant des systèmes de volume faible à moyen. Cependant, ils viennent avec un prix qui met une limite inférieure assez importante sur le plus petit système avec lequel la technologie peut être utilisée.
Attache directe
Dans certains cas, le stockage à attachement direct est préférable. Une possibilité est les applications de streaming à bande passante limitée, où le nombre limité de connexions Fibre Channel contraindra la bande passante disponible à moins que ce qui pourrait être possible avec un contrôleur SAS haut de gamme. Cependant, il s'agit probablement d'applications assez spécialisées telles que de très grands entrepôts de données où une architecture sans partage peut fournir le meilleur débit.
En fait, le stockage à connexion directe est souvent meilleur qu'un SAN pour les systèmes d'entrepôt de données pour un certain nombre de raisons:
Les entrepôts de données placent de grandes pointes de charge transitoires sur les sous-systèmes de disques. Cela les rend assez anti-sociaux sur les SAN car ils peuvent affecter les performances d'autres systèmes sur le SAN.
Le goulot d'étranglement de streaming susmentionné.
Le stockage à connexion directe est beaucoup moins cher que le stockage SAN.
Un autre marché pour le stockage à connexion directe est lorsque vous vendez sur un marché qui ne paiera pas assez d'argent pour un SAN. C'est souvent le cas des applications vendues aux clients PME. Pour un système de point de vente ou un système de gestion de cabinet qui comptera six utilisateurs, un SAN est probablement exagéré. Dans ce type de situation, un petit serveur tour autonome avec quelques disques internes est une solution beaucoup plus appropriée.