SQL Server - Séparation des fichiers de données, journaux et TempDB sur un SAN

J'ai un SQL Server connecté à un SAN. Notre nouveau fournisseur de stockage recommande que tous les LUN s'étendent sur l'ensemble de la baie de disques, qui est RAID5. Je demanderais normalement 3 LUN distincts (données, journal et TempDB) à l'administrateur SAN, mais étant donné la recommandation du nouveau fournisseur, est-il utile de créer des LUN distincts? Ou verrais-je la même performance si tout était dans un seul LUN car il couvrirait tous les disques de toute façon?

Excellent article ici, mais ne traite pas tout à fait de ma situation exacte: http://www.brentozar.com/archive/2008/08/sql-server-on-a-san-dedicated-or-shared-drives/

Une chose à considérer est que les fichiers journaux sont des écritures séquentielles alors que les fichiers de données ne sont pas séquentiels. C'est l'une des raisons pour lesquelles des LUN distincts. Les fichiers journaux écrivent plus rapidement s'ils sont sur leur propre LUN car les broches n'ont pas à sauter, écrivez simplement séquentiellement. Si vous ajoutez un fichier de données, les broches doivent sauter et vous perdez des performances. J'espère avoir la bonne terminologie là-bas car je ne connais pas très bien les SAN eux-mêmes. L'idée derrière cela devrait être cependant.

Les recommandations des fournisseurs sont souvent erronées en ce qui concerne SQL Server. Tout simplement parce que SQL Server a des besoins différents de la plupart des applications qui utilisent un SAN.

Cela dépend beaucoup du SAN, vous souhaiterez généralement configurer différentes LUN avec différentes mises en cache, compression, chiffrement, lecture anticipée, politiques d'écriture / retour, priorités, etc. Les fichiers de données SQL présentent souvent un comportement différent de tempdb ou du journal des dossiers. La méthode d'accès / le réseau entrent également en jeu car les technologies de jonction, de chemins multiples et d'autres technologies peuvent ou non fonctionner selon votre méthode d'accès (FC, iSCSI, ..) et votre infrastructure. Vous voudrez pouvoir utiliser votre réseau à son maximum avec SQL Server car la latence et le débit sont critiques. J'ai vu des cas avec la configuration de l'association de réseaux, mais seulement 1 Gbit / s était utilisable en raison d'autres contraintes que le client ignorait. Je suis d'accord avec Kenneth, prenez les recommandations des vendeurs avec une grande dose de sel, ils se trompent souvent. SQL Server est une bête volage, il y a très peu d'absolu, généralement juste plus de questions. Poser les bonnes questions (par le biais de tests) est vraiment la clé.

Ne "prenez pas les recommandations des fournisseurs avec une grande dose de sel", sauf si elles proviennent du service des ventes ou du marketing. Bien au contraire, si vous pouvez avoir accès à leurs implémenteurs techniques, faites-vous des amis.

Il s'agit probablement d'une des nouvelles appliances de race qui virtualisent le pool de stockage et incluent des capacités de niveau automatique. Un exemple serait Compellent . Ils effectuent toutes sortes de vaudou SAN tels que:

• Écrivez des blocs de données actifs sur le stockage de niveau 1 avec des niveaux RAID optimisés pour les performances, tels que RAID 10.
• Migrez automatiquement des blocs de données inactifs vers un stockage de niveau inférieur avec un RAID 5 ou 6 à surcharge élevée et haute protection.

Pour le Compellent, le stockage est divisé en 3 niveaux, le niveau 1 étant le plus rapide (SSD ou RAID 10) jusqu'au niveau 3 lent qui comprend 7 000 disques SAS. Je n'en ai pas encore utilisé dans un environnement de production, mais j'y ai accès, sur lequel j'espère pouvoir effectuer des tests.

J'avoue être à la fois intrigué et effrayé par les fonctionnalités de niveau automatique, qui sur le papier semblent merveilleuses mais en production peuvent être problématiques. Le premier exemple qui s'est produit comme pouvant compromettre le mécanisme de niveau automatique a été les sauvegardes de bases de données. Vous avez là une cible d'écriture élevée répétitive qui peut tromper le mécanisme de hiérarchisation en déplaçant les blocs vers un pool haute performance, poussant potentiellement les données qui devraient y être.

À la question d'origine:

... est-il utile de créer des LUN séparés?

Probablement pas, non. Assurez-vous que le cas d'utilisation est clair pour le vendeur, mais s'il s'agit d'un périphérique de type Compellent, je ne pense pas que vous puissiez tirer profit de la division de vos LUN.

Est-il utile de séparer les LUN? Presque toujours. Sinon, vous finissez par surcharger la file d'attente LUN sur le serveur Windows. Et l'expérience de conditions qfull est douloureuse, quel que soit le système d'exploitation, la virtualisation ou la plate-forme de stockage