J'envisage d'utiliser une configuration RAID0 pour l'un de nos clusters SQL Server. Je vais décrire la situation et chercher pourquoi cela peut être une mauvaise idée. De plus, si vous avez des cas d'utilisation, des livres blancs ou d'autres documents sur lesquels vous pouvez m'orienter, ce serait bien.
Nous avons 3 serveurs dans 2 centres de données qui font partie d'un cluster SQL. Ils exécutent tous SQL Server dans un groupe de disponibilité. Le principal a une réplique juste à côté et une autre dans l'autre centre de données. Ils exécutent une réplication synchrone avec basculement automatique. Tous les disques sont des disques SSD de classe entreprise. Ils exécuteront SQL Server 2017 ou 2019.
Je pense qu'il y aurait de multiples avantages à les exécuter sur des matrices RAID0 par rapport à d'autres méthodes avec peu ou pas d'inconvénients réels. Le seul point négatif que je vois actuellement est le manque de redondance sur le serveur principal, donc l'échec augmente. En tant que pros:
Si un disque tombe en panne, plutôt que de fonctionner dans un état ralenti et dégradé jusqu'à ce que quelqu'un reçoive une notification et agisse manuellement sur celui-ci, le serveur échouera immédiatement à un secondaire conservant la pleine capacité opérationnelle. Cela aura l'avantage supplémentaire de nous avertir d'un basculement, afin que nous puissions enquêter plus tôt sur la cause.
Il réduit le risque d'échec global par capacité TB. Comme nous n'avons pas besoin de lecteurs de parité ou de miroir, nous réduisons le nombre de lecteurs par baie. Avec moins de disques, il y a moins de risques totaux de panne de disque.
C'est moins cher. Avoir besoin de moins de disques pour notre capacité requise coûte évidemment moins cher.
Je sais que ce n'est pas la pensée commerciale conventionnelle, mais y a-t-il quelque chose que je ne considère pas? J'adorerais n'importe quelle entrée, pour ou contre.
Je n'essaie pas de le faire pour les gains de performances des requêtes, mais s'il y en a, n'hésitez pas à les signaler. Ma principale préoccupation est de ne pas considérer ou résoudre un problème de fiabilité ou de redondance auquel je n'ai pas pensé.
Le système d'exploitation se trouve sur un lecteur en miroir séparé, donc le serveur lui-même doit rester en place. L'un de ces disques peut être remplacé et à nouveau mis en miroir. Il est petit et il n'y a aucun fichier de base de données autre que les bases de données système. Je ne peux pas imaginer que cela prenne plus de minutes. Si l'un des tableaux de données échoue, nous remplaçons le lecteur, reconstruisons le tableau, restaurons et resynchronisons avec l'AG. D'après mon expérience personnelle, la restauration a été BEAUCOUP plus rapide qu'une reconstruction de disque RAID5. Je n'ai jamais eu de panne RAID1, donc je ne sais pas si cette reconstruction serait plus rapide ou non. Les restaurations proviendraient d'une sauvegarde et seraient reportées pour correspondre au serveur principal, donc l'augmentation de la charge sur le serveur principal devrait être très minimale en synchronisant uniquement les dernières minutes de journaux avec le réplica récupéré.
la source
Réponses:
Je pense que vous manquez un aspect très important dans votre évaluation:
Comment comptez-vous récupérer?
Lorsque raid5 perd un lecteur, il s'exécute dans un état dégradé jusqu'à ce qu'il se soit rétabli automatiquement. (Au moins si vous avez un disque de rechange à portée de main.)
Lorsqu'un raid0 perd un disque, il ne peut jamais récupérer du tout. Cela signifie que vous avez perdu la redondance, et pour la récupérer, vous devez reconstruire votre raid0 et copier toutes les données (pas seulement les données sur le disque cassé) depuis le secondaire qui est maintenant sous charge de production. C'est-à-dire qu'au lieu de la seule matrice raid5 dégradée, c'est maintenant toute votre configuration de production qui obtient les performances.
Si la pénalité de performance de l'état dégradé raid5 (ou raid6) n'est pas quelque chose que vous pouvez gérer, vous devriez probablement faire le raid 1 + 0 à la place . Oui, cela coûte plus cher, mais les prix des disques étant ce qu'ils sont, ce sera de l'argent bien dépensé.
Peut-être que "surveiller activement l'état raid5 et transférer la charge du primaire en cas de panne d'un disque" est la solution qui vous offre la plupart des avantages sans aucun inconvénient? (En plus de perdre le facteur de fraîcheur de l'exécution sans aucune redondance locale, bien sûr.) Si la récupération de votre disque raid5 prend beaucoup plus de temps qu'une synchronisation complète des données de la base de données, soit votre logiciel de raid agit étrangement, soit vous avez des disques sérieusement surdimensionnés, Je pense.
la source
La panne du lecteur doit être prise en compte ici.
Imaginez une seconde que nos disques durs un jour donné ont un taux de panne de 1/1000. Imaginez alors que nous avons 20 disques dans chacune de nos 3 baies.
Le risque qu'un seul disque tombe en panne dans un module RAID est donc de 20/1000 = 1/50. La probabilité que deux disques tombent en panne dans la même baie est proche de 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000. Donc, en passant de RAID 0 à RAID 5, nous sommes déjà beaucoup moins susceptibles de tuer l'un de nos tableaux.
Nous pouvons donc aller plus loin - si la probabilité de défaillance d'une baie un jour est de 1/50, alors la probabilité de défaillance de deux baies en une journée est de 1 / (50 * 50) = 1/2500. Le risque de défaillance de deux baies RAID 0 identiques est deux fois plus élevé qu'une défaillance d'une baie RAID 5, en supposant le même ensemble de disques. Cette augmentation exponentielle des chances de défaillance devrait vous inquiéter, car elle augmente considérablement les risques de défaillance de plusieurs baies à la fois.
Comme ces disques sont susceptibles d'avoir une longue durée de vie, vous pouvez probablement exécuter les chiffres comme ci-dessus et voir directement quel effet cela aura sur la fiabilité - si vous pouvez publier les spécifications du lecteur, je peux ajouter ce calcul à ce message. Si le risque est alors acceptable ou non, c'est à votre organisation d'en décider.
Un autre élément à noter est que la probabilité de panne de disque peut être augmentée en utilisant des SSD fabriqués dans le même lot (même usine, même heure). Si vous ne faites pas attention, vous pourriez vous retrouver avec les 3 nœuds en panne à cause de ce problème.
Avertissement: Les calculs ci-dessus ont été simplifiés - ils sont encore relativement précis.
la source
Il s'agit d'une configuration assez courante lors de l'exécution d'AG avec des lecteurs de stockage internes / à connexion directe. Surtout avec NVMe ou d'autres périphériques de stockage flash basés sur PCI.
Cela revient simplement à traiter une panne de disque comme une panne de serveur. Avec un petit nombre de disques SSD, vous n'avez pas vraiment un MTBF significativement plus faible pour les disques que pour les autres composants SSD du serveur, et vous traitez donc simplement chaque disque comme un point de défaillance pour le serveur et remplacez / reconstruisez le serveur en cas de panne de disque.
la source
Je suis intrigué par ce que vous essayez de réaliser? Vous vous dites que vous n'essayez pas d'obtenir des gains de performances de cette configuration, alors quel gain essayez-vous d'obtenir?
Remarque sur le problème de performances: si vous exécutez des SSD de classe entreprise, votre calcul RAID est-il vraiment un goulot d'étranglement dont vous avez besoin pour l'améliorer?
En prenant vos 3 pros, je ne pense pas que vous y ayez suffisamment réfléchi:
Le basculement SQL sera-t-il immédiatement? Qu'est-ce qui va déclencher le basculement automatiquement? Le serveur mettra-t-il le lecteur hors ligne dès que quelqu'un le frappera? Et si c'est juste un mauvais secteur sur un disque? Si SQL ne touche pas le mauvais secteur, est-ce qu'il basculera? Je ne suis pas sûr à 100% à ce sujet.
Cela réduit-il le risque d'échec global par capacité TB? Votre pensée semble être que moins de disques signifie moins de points de défaillance, mais je ne pense pas que ce soit vrai. Les chances que 1 disque tombe en panne restent les mêmes si vous avez 1 disque ou 10 disques (ou 100 disques), mais avec RAID 0, cela signifie également qu'il s'agit d'une défaillance catastrophique.
Un SSD supplémentaire coûtera-t-il trop cher pour que vous obteniez RAID5? J'obtiens comment RAID1 OU 1 + 0 pourrait faire exploser le budget, mais 1 disque supplémentaire?
Sans redondance, si un disque tombe en panne et que le RAID est hors ligne, ce nœud sera hors ligne jusqu'à ce que vous reconstruisiez le RAID et restauriez toutes vos bases de données à partir de zéro. Quel processus allez-vous suivre pour y arriver? Vous ne pouvez pas supprimer la base de données du groupe de disponibilité car cela arrêtera la réplication vers DR, mais si vous n'effectuez aucune action, les deux autres serveurs ne pourront pas tronquer leurs fichiers journaux. Est-ce que ça va? Que se passe-t-il en cas d'échec un vendredi soir d'un long week-end? C'est toujours ok? Vos secondaires peuvent-ils faire face à cette quantité de données accumulées?
Mes dernières questions porteraient sur le temps de reconstruction que vous mentionnez sera plus rapide. Êtes-vous sûr à 100% que ça va être plus rapide? Combien plus rapide?
La configuration du serveur Brent Ozar est toujours mon go-to guide pour la mise en place de nouvelles instances SQL. Le tout premier point du guide est de valider que vous n'utilisez RAID0 pour aucun lecteur.
==== MISE À JOUR ====
Une pensée supplémentaire, que se passe-t-il lorsque vos serveurs secondaires ne sont pas synchronisés avec votre serveur principal? Même avec la réplication synchrone, vos secondaires peuvent toujours revenir automatiquement en async, et une fois qu'ils le font, vous perdez la capacité de basculement automatique, car tout basculement entraînera une perte de données. Quelques exemples où cela pourrait se produire:
Ce sont des cas marginaux, mais ils pourraient être catestrophiques en fonction de ce qui est perdu pendant ces périodes.
la source