Journaux de transactions SQL Server dans le cloud

Il est courant de placer les journaux de transactions ( *.ldf) sur un système de disque physique distinct des fichiers de base de données ( *.mdf, *.ndf).

Dans un environnement cloud de machine virtuelle, est-il correct de placer les journaux de transactions sur la même lettre de lecteur que les autres fichiers de données? Comment cela est-il généralement géré dans les environnements de machines virtuelles cloud populaires d'aujourd'hui?

REMARQUE: n'utilisez pas SQL Azure. Utilisation d'une machine virtuelle Windows avec accès complet.

— Jason Kresowaty
source

Si vous parlez d'Azure, je ne pense pas que vous ayez vraiment le moindre contrôle sur le placement des fichiers, ni même sur le système de disque sous-jacent. Cela dit, je ne pense pas qu'il serait très intelligent de la part de Microsoft de violer les meilleures pratiques et de placer des données et des fichiers journaux sur le même disque, en particulier compte tenu de la surcharge d'écriture supplémentaire inhérente à la plate-forme.

— Aaron Bertrand

Clarifié: ne pas utiliser SQL Azure. Utiliser une machine virtuelle Windows complète pour que le placement du journal des transactions dépend de moi.

— Jason Kresowaty

Donc, si vous avez plusieurs volumes indépendants accessibles à votre machine virtuelle, pourquoi pensez-vous que les considérations de placement de journaux seraient différentes pour une machine virtuelle par rapport à une machine physique?

— Aaron Bertrand

Je suppose que l'on a besoin de connaître les recommandations du fournisseur particulier pour répondre avec certitude. Je suppose que je voudrais juste quelques idées générales sur ce que les gens ont réellement fait à cet égard avec les fournisseurs de cloud populaires.

— Jason Kresowaty

Alors de quoi parle-t-on ici? Une machine virtuelle hébergée par vous sur le matériel et le stockage que vous contrôlez ou une machine virtuelle hébergée par un fournisseur de cloud comme Azure ou EC2?

— Mark Storey-Smith

Réponses:

Lors de mes tests approfondis sur le cloud SQL sur des serveurs cloud (cloud rackspace, pour être spécifique), j'ai constaté que le fractionnement du ldf et du mdf en volumes de stockage de blocs distincts a fait une amélioration significative des performances. J'ai réalisé des performances vraiment chaudes en plaçant le ldf sur un volume de stockage en bloc basé sur SSD et le mdf sur un volume de stockage en bloc standard.

En fin de compte, bien sûr, un volume de stockage en bloc est quelque part un SAN partagé. Et le stockage "d'instance" local se trouve sur l'hyperviseur lui-même. La topologie matérielle de votre environnement cloud dictera donc quelle configuration fonctionnera le mieux.

— Jonesome réintègre Monica
source

Cela dépend de l'environnement cloud que vous utilisez, mais il est généralement judicieux de les placer sur le même lecteur logique. Si vous avez besoin d'IOPS supplémentaires, vous pouvez répartir sur plusieurs volumes, mais toujours présenter un seul lecteur.

Dans un environnement cloud, vous n'êtes pas le seul consommateur du stockage qui vous est alloué. Vous obtenez une petite tranche d'un très gros gâteau et en tant que tel, tous les E / S sont de nature aléatoire. Il n'y a rien à gagner à essayer de séparer l'accès séquentiel (journal) de l'accès aléatoire (données).

Rien à gagner de l'angle de récupération non plus, car vous ne pouvez pas insister pour que les deux volumes soient alloués à partir de tableaux différents. En outre, il existe généralement une classe de protection différente en fonction de la disponibilité de stockage des grands acteurs. Le stockage Azure, par exemple, est triple répliqué dans le centre de données, avec une copie supplémentaire répliquée sur un centre de données de basculement par défaut.

— Mark Storey-Smith
source