Performances RAID logicielles vs matérielles et utilisation du cache
J'ai beaucoup lu sur les contrôleurs/configurations RAID et une chose qui revient souvent est la façon dont les contrôleurs matériels sans cache offrent les mêmes performances que le RAID logiciel. Est-ce vraiment le cas?
J'ai toujours pensé que les cartes RAID matérielles offriraient de meilleures performances même sans cache. Je veux dire, vous avez du matériel dédié pour effectuer les tâches. Si tel est le cas, quel est l'avantage d'obtenir une carte RAID sans cache, quelque chose comme un LSI 9341-4i qui n'est pas vraiment bon marché.
De plus, si un gain de performances n'est possible qu'avec le cache, existe-t-il une configuration de cache qui écrit sur le disque immédiatement mais conserve les données dans le cache pour les opérations de lecture, ce qui fait du BBU une priorité?
En bref: si vous utilisez une carte RAID bas de gamme (sans cache), faites-vous plaisir et passez au RAID logiciel. Si vous utilisez une carte milieu à haut de gamme (avec BBU ou NVRAM), le matériel est souvent (mais pas toujours! Voir ci-dessous) un bon choix.
Réponse longue: lorsque la puissance de calcul était limitée, les cartes RAID matérielles avaient l'avantage significatif de décharger le calcul de parité/syndrome pour les schémas RAID les impliquant (RAID 3/4/5, RAID6, ecc).
Cependant, avec les performances du processeur en constante augmentation, cet avantage a pratiquement disparu: même l'ancien processeur de mon ordinateur portable (Core i5 M 520, génération Westmere) a des performances XOR de plus de 4 Go/s et des performances du syndrome RAID-6 de plus de 3 Go/s sur un seul noyau d'exécution .
L'avantage que le RAID matériel conserve aujourd'hui est la présence d'un cache DRAM protégé contre les pertes de puissance, sous la forme de BBU ou de NVRAM. Ce cache protégé donne une latence très faible pour l'accès en écriture aléatoire (et les lectures qui frappent) et transforme essentiellement les écritures aléatoires en écritures séquentielles. n contrôleur RAID sans un tel cache est presque inutile. De plus, certains contrôleurs RAID bas de gamme sont non seulement livrés sans cache, mais désactivent de force le cache DRAM privé du disque, conduisant à des performances plus lentes que sans carte RAID. Un exemple sont les cartes Dell PERC H200 et H300: si le micrologiciel plus récent n'a pas changé cela, elles désactivent totalement le cache privé du disque (et il ne peut pas être réactivé pendant que les disques sont connectés au contrôleur RAID). Faites-vous plaisir et n'achetez jamais, jamais de tels contrôleurs. Bien que les contrôleurs haut de gamme désactivent souvent le cache privé du disque, ils ont au moins leur propre cache protégé, ce qui rend le cache privé des disques durs (mais pas des SSD!) Quelque peu redondant.
Ce n'est pas la fin, cependant. Même les contrôleurs capables (celui avec le cache BBU ou NVRAM) peuvent donner des résultats incohérents lorsqu'ils sont utilisés avec des SSD, essentiellement parce que les SSD ont vraiment besoin d'un cache privé rapide pour une efficacité Programmation/effacement de page FLASH. Et tandis que certains contrôleurs (la plupart?) Vous permettent de réactiver le cache privé du disque (par exemple: PERC H700/710/710P permettent à l'utilisateur de le réactiver), si ce cache privé n'est pas protégé en écriture, vous risquez de perdre des données au cas où de perte de puissance. Le comportement exact dépend vraiment du contrôleur et du micrologiciel (par exemple: sur un Dell S6/i avec 256 Mo de cache WB et le cache du disque activé , j'avais pas de pertes lors de multiples tests de perte de puissance prévus), ce qui donne de l'incertitude et beaucoup d'inquiétude.
Les RAID logiciels libres, en revanche, sont des bêtes beaucoup plus contrôlables - leurs logiciels ne sont pas enfermés dans un micrologiciel propriétaire et ont des modèles et des comportements de métadonnées bien définis. Le RAID logiciel suppose (à droite) que le cache DRAM privé du disque n'est pas protégé, mais en même temps, il est essentiel pour des performances acceptables - ils ne le désactivent donc généralement pas, ils utilisent plutôt les commandes ATA FLUSH/FUA pour être certains que les données atterrissent sur un stockage stable. Comme ils s'exécutent souvent à partir des ports SATA connectés au chipset SB, leur bande passante est très bonne et la prise en charge des pilotes est excellente.
Cependant, s'il est utilisé avec des disques durs mécaniques, le modèle d'accès en écriture aléatoire synchronisé (par exemple: bases de données, machines virtuelles) souffrira considérablement par rapport à un contrôleur RAID matériel avec cache WB. D'un autre côté, lorsqu'il est utilisé avec des SSD d'entreprise (c'est-à-dire avec un cache d'écriture protégé contre les pertes de puissance), le RAID logiciel excelle souvent et donne des résultats encore plus élevés que ce qui est réalisable avec des cartes RAID matérielles. Cela dit, vous devez vous rappeler que les SSD grand public (lire: avec cache d'écriture différée non protégé), bien que très bons en lecture et en écriture asynchrone, fournissent des IOPS très faibles dans les charges de travail d'écriture synchronisée.
Considérez également que les RAID logiciels ne sont pas tous créés égaux. Le RAID logiciel Windows a une mauvaise réputation, en termes de performances, et même l'espace de stockage ne semble pas trop différent. Linux MD Raid est exceptionnellement rapide et polyvalent, mais la pile d'E/S Linux est composée de plusieurs éléments indépendants que vous devez soigneusement comprendre pour extraire des performances maximales. Le RAID de parité ZFS (ZRAID) est extrêmement avancé mais, s'il n'est pas correctement configuré, il peut vous donner des IOP très médiocres; mirroring + striping, de l'autre côté, fonctionne assez bien. Quoi qu'il en soit, il a besoin d'un périphérique SLOG rapide pour la gestion d'écriture synchrone (ZIL).
Conclusion:
- si vos charges de travail ne sont pas sensibles à l'écriture aléatoire synchronisée, vous n'avez pas besoin d'une carte RAID
- si vous avez besoin d'une carte RAID, n'achetez pas un contrôleur RAID sans cache WB
- si vous prévoyez d'utiliser un logiciel SSD, le RAID est préférable, mais gardez à l'esprit que pour les écritures aléatoires synchronisées, vous avez besoin d'un SSD protégé contre les pertes de puissance (par exemple: Intel S4600, Samsung PM/SM863, etc.). Pour des performances pures, le meilleur choix est probablement Linux MD Raid, mais de nos jours j'utilise généralement des miroirs ZFS rayés. Si vous ne pouvez pas vous permettre de perdre la moitié de l'espace à cause des miroirs et que vous avez besoin des fonctionnalités avancées de ZFS, optez pour ZRAID mais soigneusement pensez à votre configuration VDEV.
- si vous, même en utilisant un SSD, avez vraiment besoin d'une carte RAID matérielle, utilisez des SSD avec des caches protégés en écriture (les Micron M500/550/600 ont une protection partielle - pas vraiment suffisante mais meilleure que rien - tandis qu'Intel DC et S series ont une protection complète contre les pertes de puissance, et la même chose peut être dite pour les SSD Samsung d'entreprise)
- si vous avez besoin de RAID6 et que vous utiliserez des disques durs mécaniques normaux, pensez à acheter une carte RAID rapide avec 512 Mo (ou plus) de cache WB. RAID6 a une forte pénalité en termes de performances d'écriture et un cache WB de taille appropriée peut au moins fournir un stockage intermédiaire rapide pour les petites écritures synchrones (par exemple: journal du système de fichiers).
- si vous avez besoin d'un RAID6 avec disques durs mais que vous ne pouvez pas/ne voulez pas acheter une carte RAID matérielle, réfléchissez bien à la configuration de votre logiciel RAID. Par exemple, une solution possible avec Linux MD Raid consiste à utiliser deux matrices: une petite matrice RAID10 pour les écritures de journal/journaux de base de données et une matrice RAID6 pour le stockage brut (comme serveur de fichiers). D'un autre côté, le logiciel RAID5/6 avec SSD est très rapide, vous n'avez donc probablement pas besoin d'une carte RAID pour une configuration entièrement SSD.
Le contrôleur RAID dont vous avez l'œil est bon marché et est essentiellement un fakéraid. Cela dépend même de votre carte mère pour fournir certaines fonctions comme la mémoire et peu de cartes mères sont prises en charge, ce qui signifie que vous ne pouvez pas charger le pilote.
À propos de HW vs SW-RAID lui-même. Je n'utilise plus HW-RAID sauf s'il s'agit d'une boîte avec un logo EMC par exemple. Pour tout le reste, je suis revenu à SW-RAID de nombreuses lunes à nouveau pour quelques raisons très simples.
Vous avez besoin de matériel supplémentaire et devez les faire correspondre. Vous devez également faire correspondre le micrologiciel et le synchroniser. Beaucoup de disques ne fonctionneront pas correctement et vous aurez des pics de latence d'E/S sans raison claire.
Le matériel supplémentaire est cher, vous pouvez donc utiliser ces 1000 $ supplémentaires (contrôleur décent avec deux/trois disques) pour une meilleure solution. Investissez-le dans plus de disques et de contrôleurs standard, de mémoire ECC, de CPU plus rapide. Et un disque de rechange sur place peut-être si vous prévoyez de le faire fonctionner plus longtemps que la période de garantie ou si vous ne voulez pas payer les frais express pour l'expédition de nuit.
La mise à niveau est pénible car vous devez garder une trace des correctifs du système d'exploitation et du micrologiciel pour le disque et le contrôleur. Cela peut entraîner une situation où la mise à niveau/mise à jour n'est plus possible.
Sur les formats de disque. Un nombre suffisant de fournisseurs utilisent une disposition interne pour stocker des données liées à une révision de votre combinaison matériel et micrologiciel. Cela peut entraîner une situation où une pièce de rechange vous empêche d'accéder à vos données.
C'est un SPOF et un goulot d'étranglement. Avoir un seul contrôleur derrière un seul pont PCI ne vous donne pas les performances et la redondance dont vous avez vraiment besoin. Avec cela, il n'existe également aucun chemin de migration pour migrer les données vers un autre ensemble de disques hors de portée des contrôleurs.
La plupart de ces points ont été pris en charge avec les nouvelles générations de logiciels SW-RAID ou de solutions comme ZFS et BtrFS. Gardez à l'esprit qu'en fin de compte, vous voulez protéger vos données et non les déchets accessibles rapidement, mais redondants.
Vous aurez besoin d'une solution de batterie ou de cache flash pour tout contrôleur matériel que vous achetez. La plupart regrettent de ne pas l'avoir fait .
Mais pour répondre à votre question, la plupart des contrôleurs ont des ratios de cache configurables ... donc 100% lisent cache et 0% le cache en écriture annule le besoin de protection BBU. Vos performances d'écriture seront nulles.
Je ne peux pas répondre à votre question RAID logiciel car cela dépend. Linux MD RAID est différent de Windows Software RAID, qui est différent de quelque chose comme ZFS . Des solutions comme ZFS peuvent mieux fonctionner que le matériel car elles exploitent les RAM et ressources CPU du serveur).
J'ai passé la dernière année (de temps en temps jusqu'en 2014-2015) à tester plusieurs configurations parallèles CentOS 6.6 RAID 1 (en miroir) à l'aide de 2 contrôleurs LSI 9300 HBA vers 2 contrôleurs RAID LSI 9361-8i avec des systèmes basés sur les éléments suivants: 2U Supermicro CSE- Châssis 826BAC4-R920LPB, carte mère ASUS Z9PE-D16, 2 processeurs Intel Xeon E5-2687W v2 à huit cœurs 3,4 GHz, miroir Seagate ST6000NM0014 6 To SAS 12 Go, 512 Go de RAM. Notez qu'il s'agit d'un configuration entièrement compatible SAS3 (12 Gbit/s).
J'ai parcouru des articles écrits sur les logiciels de réglage et j'utilise le RAID logiciel Linux depuis plus de 10 ans. Lors de l'exécution de tests d'E/S de base (dd-oflag = fichiers directs de 5k à 100G, hdparam -t, etc.), le RAID logiciel semble s'empiler favorablement en raid matériel. Le RAID logiciel est mis en miroir via des adaptateurs de bus hôte distincts. Je suis allé jusqu'à faire des tests avec les configurations standard du noyau CentOS 6, kernel-lt et kernel-ml. J'ai également essayé divers réglages mdadm, système de fichiers, sous-système de disque et o/s suggérés par une variété d'articles en ligne écrits sur le RAID logiciel Linux. Malgré l'optimisation, les tests, l'optimisation et les tests, lors de l'exécution dans un monde en lecture, système de traitement des transactions (ayant une base de données MySQL ou Oracle), j'ai constaté que l'exécution d'un contrôleur RAID matériel entraîne une augmentation de 50 fois les performances. J'attribue cela au contrôle du cache optimisé par RAID matériel.
Pendant de nombreux mois, je n'étais pas convaincu que le RAID matériel pouvait être tellement mieux, cependant, après des recherches exhaustives sur le RAID logiciel Linux, les tests et le réglage, ce sont mes résultats.
La plupart des auteurs ici ignorent tout simplement " trou d'écriture ". C'est la base qui permet de crier pour les unités de sauvegarde battey des RAID matériels contre l'absence d'un tel pour les RAID logiciels. Eh bien, pour e. g., L'implémentation RAID du logiciel Linux prend en charge les bitmaps des opérations d'écriture ou effectue un recalcul complet de la "parité" en cas d'arrêt non propre. ZFS s'efforce toujours de réaliser des écritures complètes pour éviter cette incohérence ou reporter sa nouvelle vérification. Donc, pour résumer, le RAID logiciel suffisamment intelligent de nos jours est souvent assez bon pour être utilisé au lieu de "qui sait ce qu'il y a à l'intérieur", ce qu'on appelle le "RAID matériel".
En ce qui concerne la partie cache de la question, cela n'a pas vraiment d'importance, car le cache d'écriture du système d'exploitation lui-même peut être beaucoup plus grand que l'adaptateur "matériel".
Je travaille ça tout le temps. Cela dépend fortement de ce que vous faites et du niveau de raid de votre soutien. Un contrôleur SW exécutant un Raid 0 ou 1 pour le système d'exploitation et rien de spécial n'est bien. Exécuter un contrôleur SW avec un Raid 5 sur une base de données demande des ennuis! CERTAINS contrôleurs matériels vous offrent de meilleures performances, mais cela dépend s'il peut mettre en cache et le chipset du processeur de la carte RAID. De plus, tous les contrôleurs logiciels ne sont pas pris en charge par tous les systèmes d'exploitation. Donc, parfois, vous devrez peut-être acheter un HW pour exécuter ESXi ... À moins que vous n'utilisiez des connexions SATA.