RAID0 au lieu de RAID1 ou 5, est-ce fou?

14

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:

  1. 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.

  2. 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.

  3. 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é.

zsqlman
la source
1
La discussion sur cette question a été déplacée vers le chat .
Paul White 9

Réponses:

19

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.

Basse
la source
16

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.

George.Palacios
la source
La conversation sur cette réponse a été déplacée vers le chat .
Paul White 9
13

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.

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.

David Browne - Microsoft
la source
2

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:

  1. 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.

  2. 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.

  3. 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:

  1. Reconstruction d'un index très volumineux - la réplication peut prendre du retard sur l'un ou les deux secondaires
  2. Échec de disque sur le RAID0 lors de la correction du secondaire. Le serveur que vous corrigez peut ne pas être en mesure de revenir en ligne car le serveur principal est hors ligne.

Ce sont des cas marginaux, mais ils pourraient être catestrophiques en fonction de ce qui est perdu pendant ces périodes.

Greg
la source
Ajoutant à votre point sur # 3, si le coût d'un disque supplémentaire (ou trois) est ce qui fait ou brise le budget, alors d'où viendra l'argent pour le remplacer lorsqu'un disque tombe en panne?
un CVn
@Greg Le fait que je n'ai peut-être pas tout réfléchi est la raison pour laquelle je pose cette question. Je suppose que je dirais que je vois où je peux améliorer l'efficacité dans son ensemble. Pour répondre à vos questions: 1. Oui. L'échec de la baie entraînera immédiatement l'échec de l'AG sur un autre nœud. Un secteur défectueux dépend du fait qu'il s'agissait d'une erreur de bit récupérable ou non, mais cela entraînerait une défaillance, que le disque soit dans n'importe quel type de RAID ou non. 2. Moins de disques réduirait les risques d'échec dans la baie. RAID0 augmenterait les risques de défaillance de la baie. 3. Non, les économies d'argent sont des avantages.
zsqlman
@Greg Bonnes questions de suivi et certaines que je n'avais pas complètement développées. Il existe de nombreuses couches de redondance, les serveurs étant triples. La restauration de toutes les bases de données peut être facilement scriptée. Si un nœud tombe en panne, nous expulserions cette réplique de l'AG en supprimant le problème de backlog Tlog et même si nous ne supprimons pas le nœud, nous avons beaucoup d'espace pour contenir quelques jours de croissance de journal. En ce qui concerne le temps de récupération, je n'ai qu'un seul point de données et je n'ai plus de matériel de rechange à tester. Nous n'avons eu qu'un échec RAID et il a fallu plus de 2 jours pour récupérer et nous pouvons faire les restaurations en 8 heures.
zsqlman
@zsqlman - J'ai ajouté un temps supplémentaire où vous pourriez perdre des données parce que vous n'avez pas de RAID. De plus, je pense que la logique que vous appliquez à la réduction des échecs est encore imparfaite. Les probabilités qu'un disque tombe en panne avec moins de disques dans le RAID est identique à 1 disque défaillant avec redondance dans le RAID. La réduction du nombre de disques ne réduit pas le risque de défaillance d'un disque - chaque disque est tout aussi susceptible de tomber en panne que tout autre disque.
Greg
Vous avez raison de dire que chaque disque a les mêmes chances d'échec. Moins de disques signifie moins de risques d'échec.
zsqlman