Fichiers SQL Server locaux ou NAS ou SAN?

Je dois installer un nouveau serveur avec SQL Server 2008, que recommandez-vous, un serveur avec Raid 10 ou les fichiers dans un NAS?

Qu'en est-il de l'iSCSI dois-je l'utiliser?

Et le SAN?

Le serveur dispose de 4 Go de RAM et ce fichier de base de données fait environ 2 Go.

Pour être clair aujourd'hui, le serveur n'a pas de RAID, je dois implémenter une sorte de stratégie, donc si quelque chose arrive, je peux avoir mes fichiers en sécurité, alors que dois-je choisir Local Files, NAS, SAN? Quelle option a le plus de performances, quelle est la plus sécurisée?

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.

Local ou SAN est le seul moyen de maintenir les performances. Dans certains cas, le SAN peut être plus rapide que le disque local en raison d'un cache d'écriture plus important et d'une configuration de débit de disque parallèle.

Évitez de faire des E / S de fichiers hautes performances sur des partages Windows. Il y a une grande quantité de surcharge de protocole qui ralentira considérablement le débit. Par exemple, il y a des années, j'ai mesuré qu'un transfert de fichiers volumineux sur un réseau étendu était ~ 50% plus rapide à l'aide de partages FTP sur Windows.

N'utilisez pas de NAS.

Soit utiliser local (OK pour moyen terme avec un bon contrôleur RAID) mais si le budget le permet, optez pour un SAN décent. Avec de la chance, vous pouvez commencer à «partager» le SAN avec d'autres systèmes et récupérer une grande partie de la dépense initiale.

4 Go de RAM conviennent à la plupart des systèmes tant qu'il s'agit d'un serveur SQL dédié (et il devrait toujours l'être). Si vous ne l'avez pas déjà envisagé, utilisez le système d'exploitation 64 bits et le serveur SQL afin de pouvoir facilement ajouter plus de RAM sans bouger avec des trucs PAE / AWE.

Pensez également à la virtualisation. Vous allez avoir besoin d'un serveur de test? Un serveur de développement? Tester l'installation de SP1? (Shameless plus pour poste plus tôt: sql-server-en-vmware )

Avec une taille de base de données de 2 Go, il n'y a aucune raison d'envisager même un SAN. Un NAS ne fonctionnera pas, vous ne devriez penser qu'à utiliser un NAS pour les sauvegardes afin de ne pas stocker de sauvegardes sur la même machine que vos données, et il est facile de faire des copies à partir du NAS pour un stockage hors site.

Avec une petite base de données, utilisez simplement des disques locaux dans un RAID 1 ou RAID 10. Si votre base de données tient dans la RAM, vous n'avez pas à vous soucier des performances d'E / S. Utilisez des fenêtres 64 bits et placez-y 8 concerts. Cela laissera beaucoup de place à l'OS et vous laissera de la place pour grandir.

Je travaille avec des systèmes qui utilisent à la fois un disque RAID local et un SAN à fibre optique. Le SAN semble mieux fonctionner même si le premier est une machine plus récente et plus rapide. Je pense qu'un facteur important est que l'arrangement de disque local est un seul lecteur, donc SQL partage les E / S de disque avec le système d'exploitation et le fichier d'échange. Cela contribue probablement fortement à la traînée.

Comme @spoulson l'a mentionné, le SAN peut fournir des performances de disque bien meilleures. Non seulement c'est un lecteur séparé, mais il est probablement sur un matériel disque beaucoup plus rapide.

Dans notre cas, nous utilisons SAN car il fournit une zone de stockage centralisée pour les groupes de services de basculement automatique VERITAS SQL Server. Lorsque la machine principale tombe en panne, les lecteurs Windows montés sur le SAN sont remontés sur la machine de sauvegarde à chaud et le serveur revient assez rapidement. Bien sûr, cela nécessite un système similaire à VERITAS pour la gestion des groupes de services qui pourrait être en dehors de votre portée.

La seule mise en garde avec laquelle nous nous sommes battus est que l'attribution d'espace disque SAN est traitée de manière conservatrice. Parce que c'est cher, ils ne le mettent pas sur un coup de tête. Avec le SAN EMC que nous utilisons, vous ne pouvez pas récupérer l'espace attribué sans vider un LUN entier. Donc, si nous constatons que l'espace alloué est supérieur à ce dont nous avons besoin et que nous voulons utiliser une partie de cet espace pour un autre LUN, nous ne pouvons pas simplement réduire celui surdimensionné. Nous devons l'abandonner et réaffecter. Cela ne fonctionne pas si bien dans un environnement de production.

Comme d'autres l'ont suggéré, évitez le NAS. Vous pourriez aussi bien mettre vos fichiers de données sur un disque dur externe USB.

Pour une petite base de données de 2 Go, un SAN serait exagéré.

D'une manière générale, vous ne souhaitez pas que vos lecteurs SQL soient partagés avec une autre application. De même, plus il y a de broches (disques) sur lesquelles vous pouvez répartir vos fichiers, mieux c'est. Encore une fois, avec une petite base de données comme vous le décrivez, vous pourrez adapter tout ce dont vous avez besoin en RAM, donc les performances du disque seront moins importantes.

Cela dit, n'allez pas créer un seul volume RAID-10 et placez TOUS vos fichiers de base de données dessus. Vous pouvez commencer avec quelque chose de simple comme: Données - 2 x 73 Go à 15 000 tr / min, journaux RAID1 - 2 x 73 Go à 15 000 tr / min, sauvegardes RAID1 - une seule grande à 7 200 tr / min ou une paire en RAID1

Si vous avez le budget à mettre à niveau, ajoutez un autre volume distinct pour TempDB (si vous effectuez des requêtes de rapport / d'analyse complexes) ou donnez au volume Log plus de disques et configurez-le en RAID10 si votre système est plus de transactions avec un volume élevé des mises à jour.

Un SAN coûterait probablement 3 à 4 fois plus que le stockage à connexion directe pour un nombre équivalent de disques. Les SAN offrent de nombreuses fonctionnalités avancées pour la sauvegarde / la capture instantanée, la prise en charge des clusters et la migration et l'extension des LUN. Si ceux-ci sont importants pour vous, cela peut valoir le coup.

Avertissement: le stockage de fichiers de base de données SQL Server sur un NAS pose de nombreux problèmes graves. Toutes les autres options étant égales, il est correct de choisir l'option SAN. Une discussion détaillée des questions pertinentes se trouve dans MS KB304261 . Pourtant, ce fil est devenu un piège pour toutes les autres questions concernant SQL Server sur un partage réseau, je préfère poster des références à l'état de la prise en charge NAS dans les versions de SQL Server.

Beaucoup de gens expérimentent maintenant l'utilisation de NAS avec MS SQL.

Auparavant, cela était interdit par défaut, mais on pourrait lever la restriction dans MS SQL 2008 et MS SQL 2005. Depuis MS SQL 2008 R2, il n'y a pas une telle restriction.

Dans MS SQL 2005 et 2008, la clé est l'indicateur de trace qui interdit l'utilisation de partages réseau. On peut émettre

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

Plus de détails dans le post de septembre 2010 sur le blog MSDN de Varun Dhawan.

Au moins techniquement, exécuter SQL Server sur un NAS est possible. Le choix dépend de nombreux facteurs et il n'est pas difficile d'imaginer une situation où le stockage d'une base de données est facilement disponible sur un NAS.