C’est à peu près à cette époque en 2013 que Michael Corey, Jeff Szastak et j’ai commencé à écrire Virtualizing SQL Server avec VMware: Doing IT Right (VMware Press) 2014. À l’époque, Microsoft SQL Server était l’application critique la plus virtualisée au monde, et c’est encore le cas aujourd’hui. Notre livre est toujours aussi pertinent aujourd'hui qu'il l'était lorsque nous l'avons publié et les recommandations que nous avons documentées sont toujours valables. Bien que ce soit l'application critique la plus populaire pour la virtualisation, il existe encore de nombreux cas où certaines meilleures pratiques simples ne sont pas suivies. Meilleures pratiques susceptibles d'améliorer considérablement les performances. Toutes les pratiques recommandées ne s’appliquent pas à tous les types de base de données à tout moment, vous devez donc faire preuve de prudence. Notre expérience nous a appris que la seule similitude dans les environnements de base de données des clients est qu’ils sont tous différents. Ainsi, cet article se concentrera sur les 5 principales choses que vous pouvez faire pour améliorer les performances de nombreux types de bases de données et donne quelques exemples de tests de performances effectués par mon équipe et moi-même.\nGestion de la mémoire SQL Server – Mémoire serveur maximale, réservations, pages de verrouillage, fichiers d'échange\nSQL Server, comme n'importe quel SGBDR, est vraiment un gros cache pour les données à la fin de votre stockage, quel que soit le stockage sous couvert. Allouer la quantité de mémoire appropriée à l’instance SQL Server et veiller à ce que le système d’exploitation dispose de suffisamment de mémoire pour éviter tout échange est notre principal objectif. Nous devons ensuite envisager de protéger le cache de la mémoire tampon SQL contre la pagination et de protéger la mémoire de la machine virtuelle. La pagination du cache de la base de données peut entraîner des problèmes de performances pour un serveur de base de données occupé.\nLa mémoire maximale doit passer de la valeur par défaut de 2 Po à une valeur qui laisse au système d'exploitation une marge de manœuvre. Sur les petites machines virtuelles SQL Server avec seulement 16 Go ou 32 Go de RAM paramétré Mémoire max. Sur mémoire allouée – 4 Go est un bon point de départ. Pour les plus grandes VM, le système d’exploitation peut nécessiter 16 Go ou 32 Go, ce qui peut être affecté par le nombre d’agents et d’autres outils que vous utilisez dans le système d’exploitation. J'ai vu des recommandations selon lesquelles vous devriez laisser 10% disponibles pour le système d'exploitation. Toutefois, cela devient problématique si votre machine virtuelle dispose de beaucoup de RAM, par exemple de 512 Go à 2 To.\nRéservez la mémoire attribuée à la machine virtuelle SQL. Cela garantit les niveaux de service de la base de données SQL, garantit que du moins, du point de vue de la mémoire, il obtiendra les meilleures performances possibles, et que le fichier de page de l'hyperviseur n'occupera pas de mémoire précieuse. Pour les serveurs virtuels SQL> plus de 16 Go de mémoire et lorsque des pages verrouillées sont utilisées, cela est d'autant plus critique que les bulles d'hyperviseurs ne sont pas efficaces.\nActivez la stratégie de sécurité locale «verrouillez les pages en mémoire» pour le compte de service SQL Database et définissez l'indicateur de suivi -T834. Cela garantira que l’instance SQL Server utilise d’énormes pages sur le système d’exploitation et protège la base de données de tout échange de système d’exploitation, car les pages volumineuses ne peuvent pas être échangées. Cela réduit également le travail que le système d’exploitation doit faire en matière de gestion de la mémoire. Les pages énormes sur x86 ont une taille de 2 Mo, par rapport à la taille de page standard de 4 Ko utilisée par défaut. L'utilisation de ce paramètre évite également que la montgolfière ait un impact sur l'instance SQL Server et constitue une autre raison de réserver de la mémoire.\nJe vous recommande d'allouer un fichier d'échange suffisamment volumineux pour un dump de noyau de petite taille au minimum et de 16 Go à 32 Go au maximum. Si vous concevez correctement votre machine virtuelle SQL Server, vous ne recevrez aucune pagination de système d’exploitation. Par conséquent, vous n’avez pas besoin d’un fichier d'échange volumineux. Si vous concevez un modèle qui sera utilisé pour plusieurs machines virtuelles SQL de tailles différentes, vous pouvez envisager de définir le fichier d'échange sur une taille standard de 16 Go et de le laisser tel quel. Moins il y a de variation, mieux c'est. En réservant la mémoire de la VM, verrouiller les pages en mémoire et utiliser -T834, le cache de la base de données ne peut pas être paginé. Ces paramètres garantiront le meilleur niveau de service et les meilleures performances possibles pour votre base de données, au moins en mémoire.\nSéparer les fichiers de données de la base de données utilisateur et la base de données TempDB sur plusieurs lecteurs et contrôleurs\nCeci s'applique particulièrement aux bases de données hautes performances. SQL Server peut générer un grand nombre d'opérations d'E / S en suspens, ce qui peut entraîner la saturation de la file d'attente d'un lecteur particulier et empêcher le transfert des E / S au stockage sous-jacent. Pour atténuer ce problème dans le cas de bases de données volumineuses hautes performances, vous devez créer les bases de données avec plusieurs fichiers de données (1 recommandé par unité de vCPU allouée à la base de données) et allouer chaque fichier de données sur un lecteur différent. Si vous avez beaucoup de bases de données plus petites et moins performantes, vous pouvez simplement diviser les fichiers de données de base de données sur plusieurs lecteurs ou points de montage si vous déterminez qu'un seul lecteur ne fournit pas des performances suffisantes.\nPour TempDB, la recommandation est 1 fichier de données par vCPU jusqu’à 8 au départ puis 4 fichiers à la fois, selon les besoins. Le processus d’allocation de fichiers de données à TempDB a été automatisé dans SQL Server 2016 afin que le numéro initial correct soit choisi en fonction du nombre de vCPU attribuées. Cela a pour but d'éviter les conflits entre GAM et SGAM.\nChaque lecteur virtuel et chaque contrôleur virtuel ayant une limite de profondeur de file d'attente, la division des fichiers de données entre plusieurs contrôleurs permet également d'éliminer les goulots d'étranglement. Dans un environnement VMware, vous pouvez utiliser jusqu'à 4 contrôleurs SCSI virtuels, tels que PVSCSI, et il serait recommandé de scinder les fichiers de données entre eux. Vous pouvez également ajuster la profondeur de chaque file d'attente du contrôleur en modifiant les paramètres de registre, mais soyez conscient de l'impact potentiel sur votre stockage principal. Avoir de très grands lecteurs / disques virtuels peut vous donner une capacité supplémentaire, mais cela ne vous donne pas plus de performances car la profondeur de la file d'attente par périphérique est toujours limitée. C'est également le cas dans les environnements cloud tels qu'Azure et s'aligne sur les recommandations de Microsoft SQL CAT.\nL'image ci-dessous montre une telle conception qui peut être appropriée pour fractionner des fichiers de données. Cet exemple utilise des points de montage, mais vous pouvez également utiliser des lettres de lecteur.
"},{"id":"text-2","type":"text","heading":"","plain_text":"Grâce à Kasim Hansia et Nutanix pour l'image ci-dessus.\nDimensionnement du processeur, NUMA et MaxDOP\nQuand il s’agit de dimensionner le processeur de votre base de données, la meilleure taille est celle qui s’intègre dans une limite NUMA. Donc, pour une plate-forme à deux sockets, ce serait une taille qui s’intègre dans une seule socket ou qui est facilement divisible par le nombre de cœurs dans une seule socket. Si vous possédez actuellement de très grands serveurs physiques contenant de nombreuses bases de données, leur découpage en ordinateurs virtuels de taille plus petite, adaptés à un nœud NUMA, contribuera à améliorer les performances. La taille optimale d'une machine virtuelle sur un système avec 8 cœurs par socket serait de 2, 4 ou 8 vCPU à titre d'exemple. En termes de surengagement de l'unité centrale, il est recommandé de commencer par un rapport noyau de vCPU à pCPU inférieur, à moins que vous ne connaissiez bien les performances réelles du système, du moins pour les systèmes de production critiques. Pour démarrer / tester, vous pouvez utiliser une ration plus élevée. Vous pouvez modifier augmenter le ratio à mesure que vous surveillez les performances réelles du système. Les systèmes de production fonctionnent généralement entre 2: 1 et 4: 1, en supposant de manière réaliste que toutes les instances de base de données et les ordinateurs virtuels exécutés sur l’hôte ou le cluster n’ont pas besoin des mêmes ressources au même moment. Vous devez concevoir pour des demandes de charges de travail de pointe, puis les moyennes se prendront en charge.\nPour les bases de données très volumineuses, cela peut ne pas être possible. Dans ce cas, il est correct de disposer d'une machine virtuelle couvrant plusieurs nœuds NUMA, car Windows et SQL Server sont compatibles avec NUMA et utiliseront les processeurs disponibles en supposant que la licence appropriée est utilisée, mais la mise à l'échelle des processeurs Au-delà des limites de NUMA dans une seule machine virtuelle, les performances ne sont pas linéaires, tandis que diviser plusieurs bases de données plus petites en plusieurs plus petites d'entre elles qui correspondent aux limites de NUMA peut offrir de meilleures performances que celles qui seraient autrement disponibles sur un seul système d'exploitation ou machine physique. Pour ce qui est de la mémoire et de NUMA, il en faut plus pour les bases de données et comme la mémoire est beaucoup plus rapide que le disque ou le disque dur SSD ou même NVMe, la pénalité d'avoir de la mémoire dans différents nœuds NUMA lorsque NUMA virtuel est disponible n'est pas un problème.\nEn ce qui concerne le paramètre SQL Degré de parallélisme maximum qui contrôle le nombre de threads ou de processeurs qu'une seule requête peut consommer, vous devez faire preuve de prudence lors de sa modification. Pour les bases de données transactionnelles de type OLTP, vous pouvez obtenir des gains de performances significatifs globaux lorsqu'un grand nombre d'utilisateurs accèdent simultanément au système si MaxDOP est défini sur un nombre petit ou égal à 1. Il s'agit toutefois d'un paramètre global sur l'instance SQL Server dans les versions antérieures à 2016 et par conséquent. aura une incidence sur toutes les bases de données sur une instance. Une bonne règle peut être de définir une taille de nœud NUMA ou un certain nombre de processeurs que vous êtes content d’être consommés par une seule requête. Dans SQL Server 2016, vous pouvez le définir pour chaque base de données afin qu'il soit plus finement ajusté aux charges de travail de base de données individuelles. Le fait de laisser la valeur par défaut égale à 0, c'est-à-dire illimité, peut également avoir des conséquences négatives sur les performances, en particulier lorsque de nombreux utilisateurs accèdent à une base de données, car une requête unique peut consommer toutes les ressources et avoir un impact négatif sur les autres utilisateurs.\nMise en réseau, migration en direct, cadres jumbo\nEn matière de mise en réseau, vous devez prendre en compte plus que l'accès des utilisateurs à la base de données, vous devez également prendre en compte les charges de travail de gestion, notamment la migration en direct pour la maintenance et l'équilibrage de charge, la sauvegarde, la surveillance et la gestion hors bande. Avec de très grandes machines virtuelles SQL Server de 512 Go et plus, le réseau de migration en direct peut avoir des exigences lourdes. Surtout avec les machines virtuelles SQL Server très actives. J'ai constaté que les réseaux de migration en direct avaient du mal à évacuer un hôte pour maintenance s'ils n'étaient pas conçus et implémentés correctement. Si vous avez des hôtes avec plusieurs To de RAM et suffisamment de machines virtuelles pour occuper cette RAM, vous devez envisager plusieurs réseaux 10G pour le trafic de migration en direct. L'utilisation de configurations de réseau LACP peut en effet aider, de même que l'utilisation de trames étendues. Lorsque vous commencez à adopter les cartes réseau 40 GbE, 50 GbE et supérieures, l’utilisation des trames étendues pour augmenter les performances et réduire l’utilisation de la CPU devient de plus en plus importante. Vous pouvez obtenir des performances supplémentaires allant jusqu'à 10% à 15% en utilisant des trames étendues pour le trafic de migration en direct, en fonction du type de processeur et de la bande passante de votre carte réseau. Mais faites attention car cela doit être mis en œuvre correctement. Heureusement, de nombreux commutateurs de classe entreprise sont désormais livrés avec les trames jumbo activées par défaut, mais vous devrez toujours l'activer dans votre hyperviseur et sur la carte réseau virtuelle de migration de vie. Si vous utilisez des trames Jumbo, pourquoi ne pas autoriser SQL Server à utiliser une taille de paquet de 8 192 octets au lieu de la taille standard 4096 (taille identique à celle d’une page de base de données bien qu’il n’y ait pas de relation directe), 8 192 octets, ce qui convient parfaitement au TCP de 8972 octets paquet (9000 octets avec surcharge inclus) sur le fil. Tenez compte de l’impact sur le réseau de toute solution de stockage définie par logiciel, en particulier lors de l’adoption de tous les systèmes flash modernes, car votre réseau peut être trop lent pour le flash.\nMaintenir une base de performance précise et objective\nMaintenir une base de données de performances objective et précise de vos bases de données est le seul moyen réel de déterminer quand les choses tournent mal ou lorsque les performances ne sont pas acceptables. Avant, pendant et après la virtualisation, vous devez mettre à jour vos lignes de base chaque fois que des modifications majeures sont apportées à la configuration. Cela empêche le «sentiment» qu’il est lent, sans définir ce qui le ralentit, ou sans pouvoir quantifier le sentiment. Si vous pouvez tester avec précision les performances acceptables et répéter ce test, vous pouvez être sûr que votre système se comporte comme prévu tout au long de sa vie utile. Ce n'est pas aussi facile que cela en a l'air, et en raison des centaines, voire des milliers de bases de données dont disposent la plupart des clients, une approche basée sur les risques est recommandée. Pour les systèmes les plus importants ou les plus risqués, il est utile d’investir dans des bases de référence et une surveillance appropriées. Pour les personnes non lavées, cela pourrait ne pas être pratique. Il existe de nombreux outils pouvant vous aider. Ils partent de tests de performance standard et d’outils de surveillance des systèmes pour aboutir à des suites de tests plus élaborées. Notre livre couvre un certain nombre d’options différentes, mais une option simple pourrait être d’utiliser HammerDB, Record and Replay et / ou SCOM / PerfMon. Sans base de référence, vous ne disposez d'aucun moyen objectif de mesurer le succès.\nRésultats de performance avec et sans meilleures pratiques\nUne fois que vous avez réussi à virtualiser SQL Server pendant des années et que vous connaissez les meilleures pratiques, il est assez difficile de revenir en arrière et de créer une machine virtuelle de base de données avec les étapes suivante, suivante et d'ignorer tout ce que vous avez appris. Mais c’est ce que nous devions faire pour mesurer la différence entre la configuration par défaut et l’application des meilleures pratiques. Dans ce cas, nous avons utilisé une machine virtuelle avec 8 vCPU, 32 Go de RAM et HammerDB. La seule différence entre les deux tests réside dans la configuration de SQL Server et du système d'exploitation. Le même nombre d'utilisateurs dans HammerDB est utilisé pour chaque test.\nConfiguration par défaut sans les meilleures pratiques appliquées:","html":"Grâce à Kasim Hansia et Nutanix pour l'image ci-dessus.\nDimensionnement du processeur, NUMA et MaxDOP\nQuand il s’agit de dimensionner le processeur de votre base de données, la meilleure taille est celle qui s’intègre dans une limite NUMA. Donc, pour une plate-forme à deux sockets, ce serait une taille qui s’intègre dans une seule socket ou qui est facilement divisible par le nombre de cœurs dans une seule socket. Si vous possédez actuellement de très grands serveurs physiques contenant de nombreuses bases de données, leur découpage en ordinateurs virtuels de taille plus petite, adaptés à un nœud NUMA, contribuera à améliorer les performances. La taille optimale d'une machine virtuelle sur un système avec 8 cœurs par socket serait de 2, 4 ou 8 vCPU à titre d'exemple. En termes de surengagement de l'unité centrale, il est recommandé de commencer par un rapport noyau de vCPU à pCPU inférieur, à moins que vous ne connaissiez bien les performances réelles du système, du moins pour les systèmes de production critiques. Pour démarrer / tester, vous pouvez utiliser une ration plus élevée. Vous pouvez modifier augmenter le ratio à mesure que vous surveillez les performances réelles du système. Les systèmes de production fonctionnent généralement entre 2: 1 et 4: 1, en supposant de manière réaliste que toutes les instances de base de données et les ordinateurs virtuels exécutés sur l’hôte ou le cluster n’ont pas besoin des mêmes ressources au même moment. Vous devez concevoir pour des demandes de charges de travail de pointe, puis les moyennes se prendront en charge.\nPour les bases de données très volumineuses, cela peut ne pas être possible. Dans ce cas, il est correct de disposer d'une machine virtuelle couvrant plusieurs nœuds NUMA, car Windows et SQL Server sont compatibles avec NUMA et utiliseront les processeurs disponibles en supposant que la licence appropriée est utilisée, mais la mise à l'échelle des processeurs Au-delà des limites de NUMA dans une seule machine virtuelle, les performances ne sont pas linéaires, tandis que diviser plusieurs bases de données plus petites en plusieurs plus petites d'entre elles qui correspondent aux limites de NUMA peut offrir de meilleures performances que celles qui seraient autrement disponibles sur un seul système d'exploitation ou machine physique. Pour ce qui est de la mémoire et de NUMA, il en faut plus pour les bases de données et comme la mémoire est beaucoup plus rapide que le disque ou le disque dur SSD ou même NVMe, la pénalité d'avoir de la mémoire dans différents nœuds NUMA lorsque NUMA virtuel est disponible n'est pas un problème.\nEn ce qui concerne le paramètre SQL Degré de parallélisme maximum qui contrôle le nombre de threads ou de processeurs qu'une seule requête peut consommer, vous devez faire preuve de prudence lors de sa modification. Pour les bases de données transactionnelles de type OLTP, vous pouvez obtenir des gains de performances significatifs globaux lorsqu'un grand nombre d'utilisateurs accèdent simultanément au système si MaxDOP est défini sur un nombre petit ou égal à 1. Il s'agit toutefois d'un paramètre global sur l'instance SQL Server dans les versions antérieures à 2016 et par conséquent. aura une incidence sur toutes les bases de données sur une instance. Une bonne règle peut être de définir une taille de nœud NUMA ou un certain nombre de processeurs que vous êtes content d’être consommés par une seule requête. Dans SQL Server 2016, vous pouvez le définir pour chaque base de données afin qu'il soit plus finement ajusté aux charges de travail de base de données individuelles. Le fait de laisser la valeur par défaut égale à 0, c'est-à-dire illimité, peut également avoir des conséquences négatives sur les performances, en particulier lorsque de nombreux utilisateurs accèdent à une base de données, car une requête unique peut consommer toutes les ressources et avoir un impact négatif sur les autres utilisateurs.\nMise en réseau, migration en direct, cadres jumbo\nEn matière de mise en réseau, vous devez prendre en compte plus que l'accès des utilisateurs à la base de données, vous devez également prendre en compte les charges de travail de gestion, notamment la migration en direct pour la maintenance et l'équilibrage de charge, la sauvegarde, la surveillance et la gestion hors bande. Avec de très grandes machines virtuelles SQL Server de 512 Go et plus, le réseau de migration en direct peut avoir des exigences lourdes. Surtout avec les machines virtuelles SQL Server très actives. J'ai constaté que les réseaux de migration en direct avaient du mal à évacuer un hôte pour maintenance s'ils n'étaient pas conçus et implémentés correctement. Si vous avez des hôtes avec plusieurs To de RAM et suffisamment de machines virtuelles pour occuper cette RAM, vous devez envisager plusieurs réseaux 10G pour le trafic de migration en direct. L'utilisation de configurations de réseau LACP peut en effet aider, de même que l'utilisation de trames étendues. Lorsque vous commencez à adopter les cartes réseau 40 GbE, 50 GbE et supérieures, l’utilisation des trames étendues pour augmenter les performances et réduire l’utilisation de la CPU devient de plus en plus importante. Vous pouvez obtenir des performances supplémentaires allant jusqu'à 10% à 15% en utilisant des trames étendues pour le trafic de migration en direct, en fonction du type de processeur et de la bande passante de votre carte réseau. Mais faites attention car cela doit être mis en œuvre correctement. Heureusement, de nombreux commutateurs de classe entreprise sont désormais livrés avec les trames jumbo activées par défaut, mais vous devrez toujours l'activer dans votre hyperviseur et sur la carte réseau virtuelle de migration de vie. Si vous utilisez des trames Jumbo, pourquoi ne pas autoriser SQL Server à utiliser une taille de paquet de 8 192 octets au lieu de la taille standard 4096 (taille identique à celle d’une page de base de données bien qu’il n’y ait pas de relation directe), 8 192 octets, ce qui convient parfaitement au TCP de 8972 octets paquet (9000 octets avec surcharge inclus) sur le fil. Tenez compte de l’impact sur le réseau de toute solution de stockage définie par logiciel, en particulier lors de l’adoption de tous les systèmes flash modernes, car votre réseau peut être trop lent pour le flash.\nMaintenir une base de performance précise et objective\nMaintenir une base de données de performances objective et précise de vos bases de données est le seul moyen réel de déterminer quand les choses tournent mal ou lorsque les performances ne sont pas acceptables. Avant, pendant et après la virtualisation, vous devez mettre à jour vos lignes de base chaque fois que des modifications majeures sont apportées à la configuration. Cela empêche le «sentiment» qu’il est lent, sans définir ce qui le ralentit, ou sans pouvoir quantifier le sentiment. Si vous pouvez tester avec précision les performances acceptables et répéter ce test, vous pouvez être sûr que votre système se comporte comme prévu tout au long de sa vie utile. Ce n'est pas aussi facile que cela en a l'air, et en raison des centaines, voire des milliers de bases de données dont disposent la plupart des clients, une approche basée sur les risques est recommandée. Pour les systèmes les plus importants ou les plus risqués, il est utile d’investir dans des bases de référence et une surveillance appropriées. Pour les personnes non lavées, cela pourrait ne pas être pratique. Il existe de nombreux outils pouvant vous aider. Ils partent de tests de performance standard et d’outils de surveillance des systèmes pour aboutir à des suites de tests plus élaborées. Notre livre couvre un certain nombre d’options différentes, mais une option simple pourrait être d’utiliser HammerDB, Record and Replay et / ou SCOM / PerfMon. Sans base de référence, vous ne disposez d'aucun moyen objectif de mesurer le succès.\nRésultats de performance avec et sans meilleures pratiques\nUne fois que vous avez réussi à virtualiser SQL Server pendant des années et que vous connaissez les meilleures pratiques, il est assez difficile de revenir en arrière et de créer une machine virtuelle de base de données avec les étapes suivante, suivante et d'ignorer tout ce que vous avez appris. Mais c’est ce que nous devions faire pour mesurer la différence entre la configuration par défaut et l’application des meilleures pratiques. Dans ce cas, nous avons utilisé une machine virtuelle avec 8 vCPU, 32 Go de RAM et HammerDB. La seule différence entre les deux tests réside dans la configuration de SQL Server et du système d'exploitation. Le même nombre d'utilisateurs dans HammerDB est utilisé pour chaque test.\nConfiguration par défaut sans les meilleures pratiques appliquées:
"},{"id":"text-3","type":"text","heading":"","plain_text":"Configuration après application des meilleures pratiques:","html":"Configuration après application des meilleures pratiques:
"},{"id":"text-4","type":"text","heading":"","plain_text":"Grâce à Bas Raayman et Bruno Sousa pour les deux images ci-dessus.\nDans cet exemple, la différence de performances est de 12x entre la configuration par défaut et la configuration optimisée. Les avantages augmentent lorsque vous commencez à augmenter le nombre de machines virtuelles et de serveurs, comme le montre l’image suivante.\nNous avons ici un certain nombre de VM de base de données en cours de dimensionnement sur plusieurs serveurs, dans le cas présent utilisant des systèmes Nutanix. La croissance des performances est linéaire. Plus vous ajoutez de machines virtuelles et de nœuds Nutanix, plus vous obtenez les mêmes performances par nœud, et l’évolutivité linéaire des performances globales en termes de transactions par minute.","html":"Grâce à Bas Raayman et Bruno Sousa pour les deux images ci-dessus.\nDans cet exemple, la différence de performances est de 12x entre la configuration par défaut et la configuration optimisée. Les avantages augmentent lorsque vous commencez à augmenter le nombre de machines virtuelles et de serveurs, comme le montre l’image suivante.\nNous avons ici un certain nombre de VM de base de données en cours de dimensionnement sur plusieurs serveurs, dans le cas présent utilisant des systèmes Nutanix. La croissance des performances est linéaire. Plus vous ajoutez de machines virtuelles et de nœuds Nutanix, plus vous obtenez les mêmes performances par nœud, et l’évolutivité linéaire des performances globales en termes de transactions par minute.
"},{"id":"text-5","type":"text","heading":"","plain_text":"#TBT Explosion du passé (2014) Mise à l'échelle d'un million de transactions MS SQL par #Nutanix node.https: //t.co/CDwiVQKMbQ pic.twitter.com/eViiA3b10m\n– Gary Little (@garyjlittle) 26 janvier 2017","html":"#TBT Explosion du passé (2014) Mise à l'échelle d'un million de transactions MS SQL par #Nutanix node.https: //t.co/CDwiVQKMbQ pic.twitter.com/eViiA3b10m\n– Gary Little (@garyjlittle) 26 janvier 2017
"},{"id":"text-6","type":"text","heading":"","plain_text":"Mot final\nNous avons présenté quelques meilleures pratiques pouvant contribuer à améliorer les performances et à garantir le succès de tout projet de virtualisation. La virtualisation de SQL Server avec VMware: bien faire les choses (VMware Press 2014) est bien plus complète. J'ai également participé à l'élaboration des meilleures pratiques Nutanix pour SQL Server, qui sont disponibles gratuitement. Nutanix a publié de nombreux guides de bonnes pratiques pour de nombreuses applications, et beaucoup d'entre eux sont applicables quel que soit le système utilisé. J'espère que l'application de certaines de ces meilleures pratiques simples contribuera à améliorer les performances de vos environnements SQL Server virtualisés. J'aimerais entendre vos réactions ou commentaires.","html":"Mot final\nNous avons présenté quelques meilleures pratiques pouvant contribuer à améliorer les performances et à garantir le succès de tout projet de virtualisation. La virtualisation de SQL Server avec VMware: bien faire les choses (VMware Press 2014) est bien plus complète. J'ai également participé à l'élaboration des meilleures pratiques Nutanix pour SQL Server, qui sont disponibles gratuitement. Nutanix a publié de nombreux guides de bonnes pratiques pour de nombreuses applications, et beaucoup d'entre eux sont applicables quel que soit le système utilisé. J'espère que l'application de certaines de ces meilleures pratiques simples contribuera à améliorer les performances de vos environnements SQL Server virtualisés. J'aimerais entendre vos réactions ou commentaires.
"},{"id":"text-7","type":"text","heading":"","plain_text":"Ce billet a été publié pour la première fois sur le blog Long White Virtual Clouds à longwhiteclouds.com. Par Michael Webster +. Droits d'auteur © 2012 – 2016 – IT Solutions 2000 Ltd et Michael Webster +. Tous les droits sont réservés. Ne pas reproduire à des fins commerciales sans autorisation écrite.","html":"Ce billet a été publié pour la première fois sur le blog Long White Virtual Clouds à longwhiteclouds.com. Par Michael Webster +. Droits d'auteur © 2012 – 2016 – IT Solutions 2000 Ltd et Michael Webster +. Tous les droits sont réservés. Ne pas reproduire à des fins commerciales sans autorisation écrite.
"},{"id":"text-8","type":"text","heading":"","plain_text":"Comme ça:\nComme Chargement…","html":"Comme ça:\nComme Chargement…
"},{"id":"text-9","type":"text","heading":"","plain_text":"en relation","html":"en relation
"},{"id":"text-10","type":"text","heading":"","plain_text":"Click to rate this post!\n \n [Total: 0 Average: 0]","html":"Click to rate this post!\n \n [Total: 0 Average: 0]
"}],"sections":[{"id":"text-1","heading":"Text","content":"C’est à peu près à cette époque en 2013 que Michael Corey, Jeff Szastak et j’ai commencé à écrire Virtualizing SQL Server avec VMware: Doing IT Right (VMware Press) 2014. À l’époque, Microsoft SQL Server était l’application critique la plus virtualisée au monde, et c’est encore le cas aujourd’hui. Notre livre est toujours aussi pertinent aujourd'hui qu'il l'était lorsque nous l'avons publié et les recommandations que nous avons documentées sont toujours valables. Bien que ce soit l'application critique la plus populaire pour la virtualisation, il existe encore de nombreux cas où certaines meilleures pratiques simples ne sont pas suivies. Meilleures pratiques susceptibles d'améliorer considérablement les performances. Toutes les pratiques recommandées ne s’appliquent pas à tous les types de base de données à tout moment, vous devez donc faire preuve de prudence. Notre expérience nous a appris que la seule similitude dans les environnements de base de données des clients est qu’ils sont tous différents. Ainsi, cet article se concentrera sur les 5 principales choses que vous pouvez faire pour améliorer les performances de nombreux types de bases de données et donne quelques exemples de tests de performances effectués par mon équipe et moi-même.\nGestion de la mémoire SQL Server – Mémoire serveur maximale, réservations, pages de verrouillage, fichiers d'échange\nSQL Server, comme n'importe quel SGBDR, est vraiment un gros cache pour les données à la fin de votre stockage, quel que soit le stockage sous couvert. Allouer la quantité de mémoire appropriée à l’instance SQL Server et veiller à ce que le système d’exploitation dispose de suffisamment de mémoire pour éviter tout échange est notre principal objectif. Nous devons ensuite envisager de protéger le cache de la mémoire tampon SQL contre la pagination et de protéger la mémoire de la machine virtuelle. La pagination du cache de la base de données peut entraîner des problèmes de performances pour un serveur de base de données occupé.\nLa mémoire maximale doit passer de la valeur par défaut de 2 Po à une valeur qui laisse au système d'exploitation une marge de manœuvre. Sur les petites machines virtuelles SQL Server avec seulement 16 Go ou 32 Go de RAM paramétré Mémoire max. Sur mémoire allouée – 4 Go est un bon point de départ. Pour les plus grandes VM, le système d’exploitation peut nécessiter 16 Go ou 32 Go, ce qui peut être affecté par le nombre d’agents et d’autres outils que vous utilisez dans le système d’exploitation. J'ai vu des recommandations selon lesquelles vous devriez laisser 10% disponibles pour le système d'exploitation. Toutefois, cela devient problématique si votre machine virtuelle dispose de beaucoup de RAM, par exemple de 512 Go à 2 To.\nRéservez la mémoire attribuée à la machine virtuelle SQL. Cela garantit les niveaux de service de la base de données SQL, garantit que du moins, du point de vue de la mémoire, il obtiendra les meilleures performances possibles, et que le fichier de page de l'hyperviseur n'occupera pas de mémoire précieuse. Pour les serveurs virtuels SQL> plus de 16 Go de mémoire et lorsque des pages verrouillées sont utilisées, cela est d'autant plus critique que les bulles d'hyperviseurs ne sont pas efficaces.\nActivez la stratégie de sécurité locale «verrouillez les pages en mémoire» pour le compte de service SQL Database et définissez l'indicateur de suivi -T834. Cela garantira que l’instance SQL Server utilise d’énormes pages sur le système d’exploitation et protège la base de données de tout échange de système d’exploitation, car les pages volumineuses ne peuvent pas être échangées. Cela réduit également le travail que le système d’exploitation doit faire en matière de gestion de la mémoire. Les pages énormes sur x86 ont une taille de 2 Mo, par rapport à la taille de page standard de 4 Ko utilisée par défaut. L'utilisation de ce paramètre évite également que la montgolfière ait un impact sur l'instance SQL Server et constitue une autre raison de réserver de la mémoire.\nJe vous recommande d'allouer un fichier d'échange suffisamment volumineux pour un dump de noyau de petite taille au minimum et de 16 Go à 32 Go au maximum. Si vous concevez correctement votre machine virtuelle SQL Server, vous ne recevrez aucune pagination de système d’exploitation. Par conséquent, vous n’avez pas besoin d’un fichier d'échange volumineux. Si vous concevez un modèle qui sera utilisé pour plusieurs machines virtuelles SQL de tailles différentes, vous pouvez envisager de définir le fichier d'échange sur une taille standard de 16 Go et de le laisser tel quel. Moins il y a de variation, mieux c'est. En réservant la mémoire de la VM, verrouiller les pages en mémoire et utiliser -T834, le cache de la base de données ne peut pas être paginé. Ces paramètres garantiront le meilleur niveau de service et les meilleures performances possibles pour votre base de données, au moins en mémoire.\nSéparer les fichiers de données de la base de données utilisateur et la base de données TempDB sur plusieurs lecteurs et contrôleurs\nCeci s'applique particulièrement aux bases de données hautes performances. SQL Server peut générer un grand nombre d'opérations d'E / S en suspens, ce qui peut entraîner la saturation de la file d'attente d'un lecteur particulier et empêcher le transfert des E / S au stockage sous-jacent. Pour atténuer ce problème dans le cas de bases de données volumineuses hautes performances, vous devez créer les bases de données avec plusieurs fichiers de données (1 recommandé par unité de vCPU allouée à la base de données) et allouer chaque fichier de données sur un lecteur différent. Si vous avez beaucoup de bases de données plus petites et moins performantes, vous pouvez simplement diviser les fichiers de données de base de données sur plusieurs lecteurs ou points de montage si vous déterminez qu'un seul lecteur ne fournit pas des performances suffisantes.\nPour TempDB, la recommandation est 1 fichier de données par vCPU jusqu’à 8 au départ puis 4 fichiers à la fois, selon les besoins. Le processus d’allocation de fichiers de données à TempDB a été automatisé dans SQL Server 2016 afin que le numéro initial correct soit choisi en fonction du nombre de vCPU attribuées. Cela a pour but d'éviter les conflits entre GAM et SGAM.\nChaque lecteur virtuel et chaque contrôleur virtuel ayant une limite de profondeur de file d'attente, la division des fichiers de données entre plusieurs contrôleurs permet également d'éliminer les goulots d'étranglement. Dans un environnement VMware, vous pouvez utiliser jusqu'à 4 contrôleurs SCSI virtuels, tels que PVSCSI, et il serait recommandé de scinder les fichiers de données entre eux. Vous pouvez également ajuster la profondeur de chaque file d'attente du contrôleur en modifiant les paramètres de registre, mais soyez conscient de l'impact potentiel sur votre stockage principal. Avoir de très grands lecteurs / disques virtuels peut vous donner une capacité supplémentaire, mais cela ne vous donne pas plus de performances car la profondeur de la file d'attente par périphérique est toujours limitée. C'est également le cas dans les environnements cloud tels qu'Azure et s'aligne sur les recommandations de Microsoft SQL CAT.\nL'image ci-dessous montre une telle conception qui peut être appropriée pour fractionner des fichiers de données. Cet exemple utilise des points de montage, mais vous pouvez également utiliser des lettres de lecteur."},{"id":"text-2","heading":"Text","content":"Grâce à Kasim Hansia et Nutanix pour l'image ci-dessus.\nDimensionnement du processeur, NUMA et MaxDOP\nQuand il s’agit de dimensionner le processeur de votre base de données, la meilleure taille est celle qui s’intègre dans une limite NUMA. Donc, pour une plate-forme à deux sockets, ce serait une taille qui s’intègre dans une seule socket ou qui est facilement divisible par le nombre de cœurs dans une seule socket. Si vous possédez actuellement de très grands serveurs physiques contenant de nombreuses bases de données, leur découpage en ordinateurs virtuels de taille plus petite, adaptés à un nœud NUMA, contribuera à améliorer les performances. La taille optimale d'une machine virtuelle sur un système avec 8 cœurs par socket serait de 2, 4 ou 8 vCPU à titre d'exemple. En termes de surengagement de l'unité centrale, il est recommandé de commencer par un rapport noyau de vCPU à pCPU inférieur, à moins que vous ne connaissiez bien les performances réelles du système, du moins pour les systèmes de production critiques. Pour démarrer / tester, vous pouvez utiliser une ration plus élevée. Vous pouvez modifier augmenter le ratio à mesure que vous surveillez les performances réelles du système. Les systèmes de production fonctionnent généralement entre 2: 1 et 4: 1, en supposant de manière réaliste que toutes les instances de base de données et les ordinateurs virtuels exécutés sur l’hôte ou le cluster n’ont pas besoin des mêmes ressources au même moment. Vous devez concevoir pour des demandes de charges de travail de pointe, puis les moyennes se prendront en charge.\nPour les bases de données très volumineuses, cela peut ne pas être possible. Dans ce cas, il est correct de disposer d'une machine virtuelle couvrant plusieurs nœuds NUMA, car Windows et SQL Server sont compatibles avec NUMA et utiliseront les processeurs disponibles en supposant que la licence appropriée est utilisée, mais la mise à l'échelle des processeurs Au-delà des limites de NUMA dans une seule machine virtuelle, les performances ne sont pas linéaires, tandis que diviser plusieurs bases de données plus petites en plusieurs plus petites d'entre elles qui correspondent aux limites de NUMA peut offrir de meilleures performances que celles qui seraient autrement disponibles sur un seul système d'exploitation ou machine physique. Pour ce qui est de la mémoire et de NUMA, il en faut plus pour les bases de données et comme la mémoire est beaucoup plus rapide que le disque ou le disque dur SSD ou même NVMe, la pénalité d'avoir de la mémoire dans différents nœuds NUMA lorsque NUMA virtuel est disponible n'est pas un problème.\nEn ce qui concerne le paramètre SQL Degré de parallélisme maximum qui contrôle le nombre de threads ou de processeurs qu'une seule requête peut consommer, vous devez faire preuve de prudence lors de sa modification. Pour les bases de données transactionnelles de type OLTP, vous pouvez obtenir des gains de performances significatifs globaux lorsqu'un grand nombre d'utilisateurs accèdent simultanément au système si MaxDOP est défini sur un nombre petit ou égal à 1. Il s'agit toutefois d'un paramètre global sur l'instance SQL Server dans les versions antérieures à 2016 et par conséquent. aura une incidence sur toutes les bases de données sur une instance. Une bonne règle peut être de définir une taille de nœud NUMA ou un certain nombre de processeurs que vous êtes content d’être consommés par une seule requête. Dans SQL Server 2016, vous pouvez le définir pour chaque base de données afin qu'il soit plus finement ajusté aux charges de travail de base de données individuelles. Le fait de laisser la valeur par défaut égale à 0, c'est-à-dire illimité, peut également avoir des conséquences négatives sur les performances, en particulier lorsque de nombreux utilisateurs accèdent à une base de données, car une requête unique peut consommer toutes les ressources et avoir un impact négatif sur les autres utilisateurs.\nMise en réseau, migration en direct, cadres jumbo\nEn matière de mise en réseau, vous devez prendre en compte plus que l'accès des utilisateurs à la base de données, vous devez également prendre en compte les charges de travail de gestion, notamment la migration en direct pour la maintenance et l'équilibrage de charge, la sauvegarde, la surveillance et la gestion hors bande. Avec de très grandes machines virtuelles SQL Server de 512 Go et plus, le réseau de migration en direct peut avoir des exigences lourdes. Surtout avec les machines virtuelles SQL Server très actives. J'ai constaté que les réseaux de migration en direct avaient du mal à évacuer un hôte pour maintenance s'ils n'étaient pas conçus et implémentés correctement. Si vous avez des hôtes avec plusieurs To de RAM et suffisamment de machines virtuelles pour occuper cette RAM, vous devez envisager plusieurs réseaux 10G pour le trafic de migration en direct. L'utilisation de configurations de réseau LACP peut en effet aider, de même que l'utilisation de trames étendues. Lorsque vous commencez à adopter les cartes réseau 40 GbE, 50 GbE et supérieures, l’utilisation des trames étendues pour augmenter les performances et réduire l’utilisation de la CPU devient de plus en plus importante. Vous pouvez obtenir des performances supplémentaires allant jusqu'à 10% à 15% en utilisant des trames étendues pour le trafic de migration en direct, en fonction du type de processeur et de la bande passante de votre carte réseau. Mais faites attention car cela doit être mis en œuvre correctement. Heureusement, de nombreux commutateurs de classe entreprise sont désormais livrés avec les trames jumbo activées par défaut, mais vous devrez toujours l'activer dans votre hyperviseur et sur la carte réseau virtuelle de migration de vie. Si vous utilisez des trames Jumbo, pourquoi ne pas autoriser SQL Server à utiliser une taille de paquet de 8 192 octets au lieu de la taille standard 4096 (taille identique à celle d’une page de base de données bien qu’il n’y ait pas de relation directe), 8 192 octets, ce qui convient parfaitement au TCP de 8972 octets paquet (9000 octets avec surcharge inclus) sur le fil. Tenez compte de l’impact sur le réseau de toute solution de stockage définie par logiciel, en particulier lors de l’adoption de tous les systèmes flash modernes, car votre réseau peut être trop lent pour le flash.\nMaintenir une base de performance précise et objective\nMaintenir une base de données de performances objective et précise de vos bases de données est le seul moyen réel de déterminer quand les choses tournent mal ou lorsque les performances ne sont pas acceptables. Avant, pendant et après la virtualisation, vous devez mettre à jour vos lignes de base chaque fois que des modifications majeures sont apportées à la configuration. Cela empêche le «sentiment» qu’il est lent, sans définir ce qui le ralentit, ou sans pouvoir quantifier le sentiment. Si vous pouvez tester avec précision les performances acceptables et répéter ce test, vous pouvez être sûr que votre système se comporte comme prévu tout au long de sa vie utile. Ce n'est pas aussi facile que cela en a l'air, et en raison des centaines, voire des milliers de bases de données dont disposent la plupart des clients, une approche basée sur les risques est recommandée. Pour les systèmes les plus importants ou les plus risqués, il est utile d’investir dans des bases de référence et une surveillance appropriées. Pour les personnes non lavées, cela pourrait ne pas être pratique. Il existe de nombreux outils pouvant vous aider. Ils partent de tests de performance standard et d’outils de surveillance des systèmes pour aboutir à des suites de tests plus élaborées. Notre livre couvre un certain nombre d’options différentes, mais une option simple pourrait être d’utiliser HammerDB, Record and Replay et / ou SCOM / PerfMon. Sans base de référence, vous ne disposez d'aucun moyen objectif de mesurer le succès.\nRésultats de performance avec et sans meilleures pratiques\nUne fois que vous avez réussi à virtualiser SQL Server pendant des années et que vous connaissez les meilleures pratiques, il est assez difficile de revenir en arrière et de créer une machine virtuelle de base de données avec les étapes suivante, suivante et d'ignorer tout ce que vous avez appris. Mais c’est ce que nous devions faire pour mesurer la différence entre la configuration par défaut et l’application des meilleures pratiques. Dans ce cas, nous avons utilisé une machine virtuelle avec 8 vCPU, 32 Go de RAM et HammerDB. La seule différence entre les deux tests réside dans la configuration de SQL Server et du système d'exploitation. Le même nombre d'utilisateurs dans HammerDB est utilisé pour chaque test.\nConfiguration par défaut sans les meilleures pratiques appliquées:"},{"id":"text-3","heading":"Text","content":"Configuration après application des meilleures pratiques:"},{"id":"text-4","heading":"Text","content":"Grâce à Bas Raayman et Bruno Sousa pour les deux images ci-dessus.\nDans cet exemple, la différence de performances est de 12x entre la configuration par défaut et la configuration optimisée. Les avantages augmentent lorsque vous commencez à augmenter le nombre de machines virtuelles et de serveurs, comme le montre l’image suivante.\nNous avons ici un certain nombre de VM de base de données en cours de dimensionnement sur plusieurs serveurs, dans le cas présent utilisant des systèmes Nutanix. La croissance des performances est linéaire. Plus vous ajoutez de machines virtuelles et de nœuds Nutanix, plus vous obtenez les mêmes performances par nœud, et l’évolutivité linéaire des performances globales en termes de transactions par minute."},{"id":"text-5","heading":"Text","content":"#TBT Explosion du passé (2014) Mise à l'échelle d'un million de transactions MS SQL par #Nutanix node.https: //t.co/CDwiVQKMbQ pic.twitter.com/eViiA3b10m\n– Gary Little (@garyjlittle) 26 janvier 2017"},{"id":"text-6","heading":"Text","content":"Mot final\nNous avons présenté quelques meilleures pratiques pouvant contribuer à améliorer les performances et à garantir le succès de tout projet de virtualisation. La virtualisation de SQL Server avec VMware: bien faire les choses (VMware Press 2014) est bien plus complète. J'ai également participé à l'élaboration des meilleures pratiques Nutanix pour SQL Server, qui sont disponibles gratuitement. Nutanix a publié de nombreux guides de bonnes pratiques pour de nombreuses applications, et beaucoup d'entre eux sont applicables quel que soit le système utilisé. J'espère que l'application de certaines de ces meilleures pratiques simples contribuera à améliorer les performances de vos environnements SQL Server virtualisés. J'aimerais entendre vos réactions ou commentaires."},{"id":"text-7","heading":"Text","content":"Ce billet a été publié pour la première fois sur le blog Long White Virtual Clouds à longwhiteclouds.com. Par Michael Webster +. Droits d'auteur © 2012 – 2016 – IT Solutions 2000 Ltd et Michael Webster +. Tous les droits sont réservés. Ne pas reproduire à des fins commerciales sans autorisation écrite."},{"id":"text-8","heading":"Text","content":"Comme ça:\nComme Chargement…"},{"id":"text-9","heading":"Text","content":"en relation"},{"id":"text-10","heading":"Text","content":"Click to rate this post!\n \n [Total: 0 Average: 0]"}],"media":{"primary_image":"https://tutos-gameserver.fr/wp-content/uploads/2019/05/HammerDB-Screen-Shot-2017-01-13-at-08.55.14.png"},"relations":[{"rel":"canonical","href":"https://tutos-gameserver.fr/2019/05/03/meilleures-pratiques-pour-lexecution-de-sql-server-virtualise-serveur-dimpression/"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/05/03/meilleures-pratiques-pour-lexecution-de-sql-server-virtualise-serveur-dimpression/llm","type":"text/html"},{"rel":"alternate","href":"https://tutos-gameserver.fr/2019/05/03/meilleures-pratiques-pour-lexecution-de-sql-server-virtualise-serveur-dimpression/llm.json","type":"application/json"},{"rel":"llm-manifest","href":"https://tutos-gameserver.fr/llm-endpoints-manifest.json","type":"application/json"}],"http_headers":{"X-LLM-Friendly":"1","X-LLM-Schema":"1.1.0","Content-Security-Policy":"default-src 'none'; img-src * data:; style-src 'unsafe-inline'"},"license":"CC BY-ND 4.0","attribution_required":true,"allow_cors":false}