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 la séparation des fichiers sur le disque physique Windows, de l'ajout de vHBA supplémentaires et de la distribution des disques physiques entre eux.
Les avantages attendus de la séparation des E / S disque aléatoires et séquentiels au niveau du disque physique Windows supposent généralement que les périphériques HDD sont stockés. Il suppose également généralement que des disques physiques Windows séparés signifient des périphériques HDD distincts. L'idée est que certains ensembles de disques durs gèrent principalement les E / S disque séquentielles et ont un mouvement de tête de disque très limité (par exemple, les disques durs hébergeant un seul txlog occupé) tandis qu'un ensemble distinct de disques durs gère les E / S disque aléatoires.
Ces hypothèses sont rarement valables aujourd'hui - en particulier dans une machine virtuelle. Tout d'abord, à moins que les disques physiques des machines virtuelles Windows ne soient des RDM, plusieurs d'entre eux pourraient se trouver dans une seule banque de données - ou peut-être plusieurs banques de données se trouvent sur un seul LUN hôte ESXi. Ainsi, ce qui est séparé dans l'invité peut être mélangé au niveau de l'hôte ESXi.
Mais disons que des RDM sont utilisés ou que chaque disque physique invité se trouve sur sa propre banque de données, sur son propre LUN ESXi. Même dans ce cas, les io séquentiels et aléatoires séparés dans l'invité sont souvent mélangés à la baie, car les LUN présentés à l'hôte ESXi peuvent provenir du même pool unique de périphériques de disque. Presque toutes les baies de stockage le font désormais - exclusivement ou en option pour faciliter la gestion et augmenter l'efficacité des baies / l'utilisation des ressources.
Enfin, aujourd'hui, le stockage est soit entièrement flash, soit hybride flash + disque dur. Sans mouvement de tête à craindre, le flash ne se soucie pas de la séparation du séquentiel pour le hasard ... ne se soucie même pas du tissage IO.
Donc… ce sont toutes les raisons pour lesquelles la séparation du séquentiel du aléatoire peut ne pas être si bénéfique. Ensuite, pourquoi la répartition des fichiers sur les disques physiques et la répartition des disques physiques sur les vHBA peut de toute façon améliorer les performances.
* J'ai délibérément mentionné un seul journal des transactions dans cet exemple de disque dur. Lorsque plusieurs flux d'E / S de disque séquentiels distincts (par exemple, 8 journaux de transactions occupés) ont lieu sur les mêmes disques durs - à moins que la quasi-totalité de l'activité se trouve dans le cache SAN - un mouvement constant de la tête entre les pistes d'E / S séquentielles conduit au tissage d'E / S. C'est un type spécifique de débordement de tête de disque qui conduit à une latence du disque "pire que aléatoire". Cela se produit sur RAID5 et RAID10, bien que RAID10 puisse tolérer un peu plus de variations à cet égard que RAID5 avant une dégradation significative.
Maintenant - étant donné que cette discussion de longue haleine sur la façon dont la séparation de séquentiel de aléatoire pourrait ne pas aider - comment la répartition des fichiers sur les disques physiques peut-elle encore aider? Comment la répartition des disques physiques entre les vHBA peut-elle aider?
Il s'agit de files d'attente d'E / S disque.
Tout disque physique ou disque logique Windows peut avoir jusqu'à 255 E / S de disque en suspens à la fois dans ce qui est signalé par perfmon comme «File d'attente actuelle». À partir des E / S de disque en attente dans la file d'attente du disque physique, storport peut transmettre jusqu'à 254 au minidriver. Mais le minidriver peut également avoir à la fois une file d'attente de service (transmise au niveau inférieur suivant) et une file d'attente. Et le port de stockage peut être invité à réduire le nombre de transmissions à partir de 254.
Dans un invité VMware Windows, le pilote pvscsi a une profondeur de file d'attente «périphérique» par défaut de 64, où le périphérique est un disque physique. Ainsi, bien que perfmon puisse afficher jusqu'à 255 E / S de disque dans la «longueur de file d'attente de disque actuelle» pour un seul disque physique, seulement 64 d'entre elles seraient passées au niveau suivant à la fois (sauf si les valeurs par défaut sont modifiées).
Combien d'ES disque peuvent être en attente pour unjournal des transactions occupé à la fois? Eh bien, les écritures du journal des transactions peuvent atteindre 60 Ko. Lors d'un ETL à grande échelle, je verrai souvent chaque écriture dans le txlog à 60 Ko. L'enregistreur txlog peut avoir jusqu'à 32 écritures de 60 ko en attente sur un txlog à la fois. Et si j'ai un txlog de préparation occupé et un txlog dw occupé sur le même disque physique, avec les paramètres VMware par défaut? Si les deux txlogs atteignent un maximum de 32 écritures de 60 ko en attente chacune, ce disque physique est à sa profondeur de file d'attente de 64. Maintenant… que se passe-t-il s'il existe également des fichiers plats en tant que source ETL sur le disque physique? Eh bien ... entre les lectures des fichiers plats et les écritures txlog, ils devraient utiliser la file d'attente, car seuls 64 peuvent sortir à la fois. Pour les bases de données avec des txlog occupés comme celui-ci, que ce soit un serveur physique ou virtuel, je recommande le txlog sur son propre disque physique, avec rien d'autre sur le disque physique. Cela empêche la mise en file d'attente à ce niveau et élimine également tout problème avec le contenu de plusieurs fichiers entrelacés (ce qui est beaucoup, beaucoup moins préoccupant de nos jours).
Combien d'E / S disque peuvent être en attente dans un fichier de lignes à la fois (du point de vue de SQL Server, pas nécessairement soumises à des niveaux inférieurs)? Il n'y a pas vraiment de limite dans SQL Server lui-même (que j'ai trouvé, de toute façon). Mais en supposant que le fichier se trouve sur un seul disque physique Windows (je ne recommande pas d'utiliser des disques dynamiques rayés pour SQL Server, c'est un sujet pour une autre fois), il y a une limite. C'est le 255 que j'ai mentionné auparavant.
Avec la magie de la lecture anticipée de SQL Server et des E / S asynchrones, j'ai vu 4 requêtes simultanées s'exécutant chacune sur un lecteur série pour une «longueur de file d'attente de disque actuelle» totale de plus de 1 200! En raison de la limite de 255, cela n'est même pas possible avec tout le contenu du fichier de lignes sur un seul disque physique. C'était contre un groupe de fichiers principal avec 8 fichiers, chacun sur son propre disque physique.
Les lectures en lecture anticipée peuvent donc être très agressives et stresser les files d'attente d'E / S. Ils peuvent être si agressifs que d'autres fichiers et lectures de fichiers en ligne finissent par attendre. Si les journaux de transactions sont sur le même disque physique que les fichiers de lignes, pendant les lectures en lecture simultanée et les écritures txlog, il est très facile d'attendre. Même si cette attente n'est pas au niveau de la "longueur de la file d'attente du disque en cours", elle peut être en attente au niveau de la file d'attente du périphérique (64 par défaut avec pvscsi).
Les lectures de sauvegarde par rapport aux fichiers de lignes peuvent également être agressives, surtout si le nombre de tampons a été réglé afin de maximiser le débit de sauvegarde.
Il y a un autre type d'io SQL Server à prendre en compte lorsque vous envisagez d'isoler les txlogs: le déversement de requêtes vers tempdb. Lorsqu'un déversement de requête a lieu, chaque opération de déversement écrit dans tempdb. Vous avez beaucoup de travailleurs parallèles qui se déversent tous en même temps? Cela peut être une charge d'écriture assez importante. Garder un txlog occupé et des fichiers de lignes importants loin de cela peut être très utile :-)
Maintenant, il est possible de modifier la profondeur de file d'attente de périphérique par défaut pour le pilote pvscsi. Il est réglé par défaut sur 64 et peut être réglé jusqu'à 254, ce qui est le plus grand port de stockage. Mais attention à changer cela. Je recommande toujours d'aligner la profondeur de file d'attente du périphérique invité avec la profondeur de file d'attente LUN de l'hôte ESXi sous-jacent. Et en définissant la profondeur de file d'attente des LUN des hôtes ESXi selon les meilleures pratiques de la baie. Vous utilisez un EMC VNX? La profondeur de la file d'attente du LUN de l'hôte doit être de 32. L'invité utilise des RDM? Génial. Définissez la profondeur de file d'attente du périphérique pvscsi invité sur 32 afin qu'elle soit alignée sur la profondeur de file d'attente du LUN de l'hôte ESXi. EMC VMAX? Généralement 64 au niveau de l'hôte ESXi, 64 en invité. Pure / Xtremio / IBM FlashSystem? Parfois, la profondeur de la file d'attente du LUN de l'hôte sera fixée à 256! Allez-y et définissez la profondeur de la file d'attente du périphérique pvscsi sur 254 (Max possible).
Voici un lien avec des instructions.
https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2053145
Le lien parle également de requestringpages - WhatAreThose ?? Ils déterminent la profondeur de 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, requestringpages est égal à 8 pour une profondeur de file d'attente d'adaptateur de 256. Il peut être défini sur 32 pour 1024 emplacements de profondeur de file d'attente d'adaptateur.
Disons que tout est par défaut. J'ai 8 disques physiques avec des fichiers de lignes sur eux, et SQL Server est légèrement occupé. Il y a en moyenne 32 «longueur de file d'attente de disque actuelle» sur les 8, et aucune n'est supérieure à 64 (tout tient dans les différentes files d'attente de service de périphérique). Génial - cela donne 256 OIO. Il tient dans les files d'attente de service de périphérique, il tient dans la file d'attente de service d'adaptateur afin que tous les 256 sortent de l'invité pour les files d'attente au niveau de l'hôte ESX.
Mais… si les choses deviennent un peu plus occupées, alors une moyenne de 64 avec une file d'attente de certains disques physiques aussi élevée que 128. Pour les appareils avec plus de 64 en attente, le dépassement est dans une file d'attente. Si plus de 256 se trouvent dans la file d'attente de service des périphériques sur les 8 disques physiques, le dépassement y est dans une file d'attente jusqu'à ce que les emplacements de la file d'attente de service de l'adaptateur s'ouvrent.
Dans ce cas, l'ajout d'un autre vHBA pvscsi et la répartition des disques physiques entre eux double la profondeur totale de la file d'attente de l'adaptateur à 512. Davantage d'io peut être transmis de l'invité à l'hôte en même temps.
Quelque chose de similaire pourrait être obtenu en restant sur un adaptateur pvscsi et en augmentant les pages de demande. Passer à 16 donnerait 512 emplacements et 32 à 1024 emplacements.
Dans la mesure du possible, je recommande d'aller plus loin (ajouter des adaptateurs) avant d'aller plus loin (augmenter la profondeur de la file d'attente des adaptateurs). Mais… sur la plupart des systèmes les plus occupés, je dois faire les deux: mettre 4 vHBA sur l'invité et augmenter les pages de demande à 32.
Il y a aussi beaucoup d'autres considérations. Des choses comme sioc et la limitation de la profondeur de file d'attente adaptative si des vmdks sont utilisés, la configuration du multichemin, la configuration de l'adaptateur ESXi au-delà de la profondeur de la file d'attente LUN, etc.
Mais je ne veux pas prolonger mon accueil :-)
Lonny Niederstadt @sqL_handLe
