Plusieurs PVSCSI avec SQL Server
En ce qui concerne la virtualisation SQL Server, essayé de trouver des informations s'il existe un impact positif sur la performance sur la séparation des périphériques de données à partir de périphériques de journaux dans différents adaptateurs paravirtuels SCSI (PVSCSI), similaires à ce qui est fait ici .
Il y a eu un scénario sur un client où une PVSCSI supplémentaire a été ajoutée et des périphériques de journalisation ont été séparés dans le nouveau PVSCSI, montrant des gains de performance considérables. Pourtant, le doute reste si cela était dû à cette séparation ou simplement en raison du fait qu'un PVSCSI supplémentaire était maintenant présent.
Comme on le sait, les disques de journalisation sont généralement écrits de manière séquentielle, tandis que les disques de données suivent un motif plus aléatoire dans leur R/W, et il y a des avantages de performance pour placer ces deux types de fichiers différents sur des disques distincts.
Mais qu'en est-il des contrôleurs? Y a-t-il un avantage également pour garder ces différents modèles dans des contrôleurs PVSCSI distincts?
Quelqu'un a une idée de cela?
Merci d'avance
Je vais répondre en deux parties: d'abord "pourquoi la réponse traditionnelle sur la séparation séquentielle et aléatoire ne s'applique souvent pas."
Ensuite, je discuterai des avantages potentiels de séparer les fichiers sur Windows PhysicalDisk et d'ajouter des VHBAS supplémentaires et de la distribution des physicalsisks entre eux.
Attendez-vous bénéficier de la séparation du disque aléatoire et séquentiel IO au niveau Windows PhysicalDisk suppose généralement des périphériques HDD pour le stockage de données. Cela suppose généralement que des physicules Windows distincts signifie des périphériques distincts de disque dur. L'idée est qu'un ensemble de disques de disque dur gère principalement un disque séquentiel IO _ et dispose de mouvements de tête de disque très limités (par exemple, les HDDS hébergeant un seul TXLog occupé *), tandis qu'un ensemble de disques disques séparés permet de gérer un disque aléatoire IO.
Ces hypothèses tiennent rarement aujourd'hui - surtout dans une machine virtuelle. Tout d'abord, à moins que les VMS Windows PhysicalDisks soient RDMS, plusieurs de personnes pourraient être dans un seul magasin de données - ou peut-être plusieurs données de données sont sur un seul LUN d'hôte ESXI. Donc, ce qui est séparé dans l'invité peut être mélangé au niveau de l'hôte ESXI.
Mais disons que les TDR sont utilisés ou que chaque personne physique est sur son propre magasin de données, sur sa propre esxi Lun. Ensuite, alors, séquentiellement séparé de l'IO aléatoire dans l'invité est souvent mélangé au tableau, car les LUN présentés à l'hôte ESXI peuvent provenir de la même piscine individuelle de périphériques de disque. Presque chaque matrice de stockage le fait maintenant - exclusivement ou comme une option pour faciliter la gestion et augmenter l'efficacité de la matrice/utilisation des ressources.
Enfin, tant de stockage aujourd'hui est soit tous les flash ou Hybrid Flash + HDD. Avec aucun mouvement de tête à craindre, Flash ne se soucie pas de la séparation de séquentielle pour ... ne se soucie même pas de IO tisser.
Donc ... ce sont toutes les raisons pour lesquelles séquences séquentielles du hasard peut ne pas être tout ce bénéfique. Ensuite, pourquoi l'épandage de fichiers à travers des physicalsisks et l'épandage des physicules à travers les VHBAS peut toujours augmenter la performance de toute façon.
* J'ai mentionné délibérément un seul journal de transaction dans cet exemple de disque dur. Lorsque plusieurs flux disques séquentiels séquentiels distincts IO (par exemple 8 journaux de transactions occupés) se déroulent sur le même disque dur - sauf si la quasi-totalité de l'activité est dans la zoneSAN cache - Mouvement de la tête constante entre Les pistes séquentielles IO conduisent à IO tissage. C'est un type spécifique de croisement de la tête de disque qui conduit à la latence de disque "pire que aléatoire". Il se produit sur RAID5 et RAID10, bien que RAID10 puisse tolérer un peu plus de variation à cet égard que RAID5 avant une dégradation significative.
Maintenant - étant donné que la discussion à long terme sur la manière dont la séquence séquentielle de Random pourrait ne pas aider - comment l'épandre des fichiers à travers des physicalsisks aident-elles toujours? Comment épandre des physicalsisks parmi l'aide de VHBAS?
Tout est sur le disque IO files d'attente.
Toute Windows PhysicalDisk ou LogicalDisk peut avoir jusqu'à 255 iOS de disque exceptionnels à la fois dans ce qui est rapporté par Perfmon comme "file d'attente de disque actuelle". Depuis le disque exceptionnel iOS dans la file d'attente physique, Storport peut passer jusqu'à 254 au minidriver. Mais le minidriver peut également avoir à la fois une file d'attente de service (transmis au niveau inférieur suivant) et une file d'attente d'attente. Et le sport peut être dit de réduire le nombre qu'il passe de 254.
Dans un invité VMware Windows, le pilote PVSCSI a une profondeur de file d'attente de "périphérique" par défaut de 64, où le périphérique est un physicalDisk. Donc, bien que Perfmon puisse apparaître jusqu'à 255 iOS de disque dans la "longueur de la file d'attente de disque actuelle" pour un seul physicalDisk, seulement 64 d'entre eux seraient transmis au niveau suivant à la fois (sauf modification des valeurs par défaut).
Combien de disques iOS peut être exceptionnel à un Banque de transaction occupée à la fois? Eh bien, les écritures de journal des transactions peuvent être de taille maximale de 60 ko. Pendant un ETL à haute échelle, je verrai souvent chaque écriture sur le TXLog à 60kb. L'écrivain TXLOG peut avoir jusqu'à 32 écrit de 60kb exceptionnel à un txlog à la fois. Alors, que se passe-t-il si j'ai une stadification occupée txlog et un TZLog occupé sur le même physicalDisk, avec des paramètres VMware par défaut? Si les deux txlogs se situent à 32 euros 60kb écrit chacun, que PhysicalDisk est à sa profondeur de file d'attente de 64. Maintenant ... Et s'il y a aussi des sacs à colons en tant que source ETL sur le physicalisk? Eh bien ... entre les lectures aux flots et txlog écrit, ils devraient utiliser la file d'attente d'attente, car seulement 64 peuvent sortir à la fois. Pour les bases de données avec des txlogs occupés comme celle-ci, que ce soit serveur physique ou virtuel, je recommande le TXLog sur son propre physicaldisk, rien d'autre sur le physique. Cela empêche la mise en file d'attente à ce niveau et élimine également toute préoccupation avec le contenu de plusieurs fichiers entrelacés (qui est une préoccupation beaucoup moins moindre de ces jours).
Combien de disques iOS peuvent être exceptionnels à un fichier Rowfile à la fois (du point de vue de SQL Server, pas nécessairement soumis à des niveaux inférieurs)? Il n'y a pas vraiment une limite dans SQL Server lui-même (que j'ai trouvé, de toute façon). Mais en supposant que le fichier est sur un seul physique Windows PhysicalDisk (je ne recommande pas d'utiliser des disques dynamiques rayé pour SQL Server, c'est un sujet pour une autre fois), il est une limite. C'est le 255 que j'ai mentionné auparavant.
Avec la magie de SQL Server Readahead et d'Io asynchrones, j'ai vu 4 requêtes simultanées qui s'exécutent en série d'une "longueur de la file d'attente de disque actuelle" de plus de 1200! En raison de la limite de 255, cela n'est même pas possible avec tous les contenus de filfile sur un seul physique. C'était contre un groupe de fichiers primaire avec 8 fichiers, chacun sur propre physique.
Donc, les lectures de Readahead peuvent être très agressives et peuvent souligner IO files d'attente. Ils peuvent être tellement agressifs que d'autres lignes se littent et écrit finissent par attendre. Si les journaux de transaction sont sur le même physical disent que les filfiles, lors de lectures simultanées ReadAhead et TXLOG écrit, il est très facile d'attendre pour avoir lieu. Même si cette attente n'est pas au niveau de la "longueur de la queue de disque actuelle", il peut être en attente de la file d'attente du périphérique (64 par défaut avec PVSCSI).
Les lectures de sauvegarde contre Rowfiles peuvent également être agressives, en particulier si bufferkeCount a été à l'écoute afin de maximiser le débit de sauvegarde.
Il y a un autre type SQL Server io à être conscient de la prise en compte de l'isolation des TXLogs: la requête sur TEMPDB. Lorsque la chute de la requête a lieu, chaque effusion de travail écrit sur TEMPDB. Vous avez beaucoup de travailleurs parallèles tous déversés en même temps? Cela peut être une charge d'écriture. Garder un txlog occupé et des fils de ramification importants loin de ceux-ci peuvent être vraiment utiles :-)
Maintenant, il est possible de modifier la profondeur de la file d'attente du périphérique par défaut pour le pilote PVSCSI. Il est par défaut à 64 et peut être défini aussi haut que 254, ce qui est le plus de sport passera. Mais faites attention à changer cela. Je recommande toujours d'aligner la profondeur de la file d'attente du périphérique invité avec la profondeur de la file d'attente LUN d'ESXI sous-jacente. Et définir la profondeur de la file d'attente LUN d'hôte ESXI par des meilleures pratiques. Utiliser un EMC VNX? La profondeur d'attente LUN hôte devrait être 32. L'invité utilise des RDMS? Génial. Définissez la profondeur de la file d'attente de la file d'attente de l'invité PVSCSI de sorte qu'il est aligné sur la profondeur de la file d'attente LUN d'hôte ESXI. EMC vmax? En règle générale 64 au niveau de l'hôte ESXI, 64 dans l'invité. System pure/xtremio/ibm? La profondeur de la file d'attente LUN peut parfois être définie aussi élevée que 256! Allez-y et définissez la profondeur de la file d'attente de périphérique PVSCSI à 254 (max possible) alors.
Voici un lien avec des instructions. https://kb.vmware.com/SelfService/microsites/search.do?language=fr_us&cmd=displaykc&externalid=2053145
Le lien parle également des demandeurs de demande - whatethose ?? Ils déterminent la profondeur de la file d'attente pour l'adaptateur PVSCSI lui-même. Chaque page donne 32 emplacements dans la profondeur de la file d'attente de l'adaptateur. Par défaut, DemandRingPages est 8 pour une profondeur de file d'attente de l'adaptateur de 256. Il peut être réglé aussi haut que 32 pour 1024 emplacements de profondeur de la file d'attente 1024.
Disons que tout est à défaut. J'ai 8 physiques physiques avec des filfiles sur eux et SQL Server est très occupé. Il y a une moyenne de 32 "la longueur de la file d'attente de disque actuelle" à l'écran 8 et aucune n'est supérieure à 64 (tout convient aux différentes files d'attente de service de périphérique). Super - cela donne 256 OIO. Il s'inscrit dans les files d'attente de service de l'appareil, il convient à la file d'attente de service de l'adaptateur, de sorte que tous les 256 sont sortis de l'invité aux files d'attente au niveau de l'hôte ESX.
Mais ... si les choses deviennent un peu plus occupées, une moyenne de 64 ans avec une file d'attente de quelques disques physiques aussi élevée que 128. Pour les appareils de plus de 64 exceptionnels, le suragrance est dans une file d'attente d'attente. Si plus de 256 se trouve dans la file d'attente des périphériques sur les 8 physicalsisks, la suragrance se trouve dans une file d'attente d'attente jusqu'à la file d'attente de la file d'attente de l'adaptateur.
Dans ce cas, l'ajout d'un autre PVSCSI VHBA et de diffuser les physicules entre eux double la profondeur de la file d'attente totale de l'adaptateur à 512. Plus d'IO peut être transmis d'invité à accueillir en même temps.
Quelque chose de similaire pourrait être obtenu en séjournant dans un adaptateur PVSCSI et en augmentant les demandeurs de demande. Aller à 16 générerait 512 emplacements et 32 donne 1024 emplacements.
Dans la mesure du possible, je recommande de devenir large (ajout d'adaptateurs) avant de partir en profondeur (augmentation de la profondeur de la file d'attente de l'adaptateur). Mais ... sur de nombreux systèmes les plus fréquentés, je dois faire les deux: Mettez 4 VHBAS sur l'invité et augmentez les demandeurs de demande de 32.
Il y a beaucoup d'autres considérations aussi. Des choses telles que SIOC et la file d'attente adaptative Logement de la profondeur Si VMDKS sont utilisées, la configuration de la multithèse de la configuration de l'adaptateur ESXI au-delà de la profondeur de la file d'attente LUN, etc.
Mais je ne veux pas dépasser mon accueil :-)
Lonny Niederstadt @sql_handle