La règle de base que j'utilise pour les disques IO est la suivante:
75 IOP par broche pour SATA.
150 IOP par broche pour FC / SAS
1500 IOP par broche pour SSD.
Les IOP par baie prennent également en compte les IOP par téraoctet. Il n'est pas rare de se retrouver avec un très mauvais rapport IOP par To si l'on fait SATA + RAID6. Cela peut ne pas sembler trop, mais vous vous retrouverez souvent avec quelqu'un qui repérera de «l'espace libre» sur un tableau et voudrez l'utiliser. Il est courant que les gens achètent des concerts et ignorent les iops, alors que le contraire est vrai dans la plupart des systèmes d'entreprise.
Ajoutez ensuite le coût de la pénalité d'écriture pour le RAID:
- 2 pour RAID1, RAID1 + 0
- 4 pour RAID5 (ou 4)
- 6 pour RAID6.
La pénalité en écriture peut être partiellement atténuée par de belles caches d'écriture et dans les bonnes circonstances. Si vous avez beaucoup d'E / S d'écriture séquentielle (comme les journaux DB), vous pouvez réduire ces pénalités d'écriture sur RAID 5 et 6 de manière assez significative. Si vous pouvez écrire une bande complète (par exemple un bloc par broche), vous n'avez pas à lire pour calculer la parité.
Supposons un ensemble RAID 6 8 + 2. En fonctionnement normal pour une seule E / S d'écriture, vous devez:
- Lisez le bloc «mis à jour».
- Lire le premier bloc de parité
- Lire le deuxième bloc de parité
- Recalculez la parité.
- écrivez tous les 3. (6 IO).
Avec une écriture pleine bande mise en cache - par exemple, 8 «morceaux» consécutifs de la taille de la bande RAID, vous pouvez calculer la parité sur l'ensemble du lot, sans avoir besoin d'une lecture. Vous n'avez donc besoin que de 10 écritures - une pour chaque donnée et deux parités.
Cela rend votre pénalité en écriture 1.2.
Vous devez également garder à l'esprit que l'écriture d'E / S est facile à mettre en cache - vous n'avez pas besoin de l'obtenir sur le disque immédiatement. Il fonctionne sous une contrainte de temps douce - tant que, en moyenne, vos écritures entrantes ne dépassent pas la vitesse de la broche, elles pourront toutes s'exécuter à la «vitesse du cache».
La lecture d'E / S, en revanche, souffre d'une contrainte de temps difficile - vous ne pouvez pas terminer une lecture tant que les données n'ont pas été récupérées. Les algorithmes de mise en cache de lecture et de chargement de cache deviennent importants à ce stade - les modèles de lecture prévisibles (par exemple séquentiels, comme vous le feriez avec la sauvegarde) peuvent être prédits et prélus, mais les modèles de lecture aléatoires ne le peuvent pas.
Pour les bases de données, je vous suggère généralement de supposer que:
la plupart de vos E / S de base de données sont lues au hasard. (par exemple, mauvais pour l'accès aléatoire). Si vous pouvez vous permettre la surcharge, RAID1 + 0 est bon - car les disques en miroir offrent deux sources de lectures.
la plupart de vos entrées / sorties «log» sont des écritures séquentielles. (par exemple, bon pour la mise en cache, et contrairement à ce que de nombreux administrateurs de base de données suggèrent, vous souhaiterez probablement RAID50 plutôt que RAID10).
Le rapport des deux est difficile est difficile à dire. Cela dépend de ce que fait la DB.
Parce que les E / S en lecture aléatoire sont le pire des cas pour la mise en cache, c'est là que le SSD entre vraiment en jeu - de nombreux fabricants ne prennent pas la peine de mettre en cache le SSD car il est de toute façon à peu près à la même vitesse. Ainsi, en particulier pour les choses comme les bases de données temporaires et les index, le SSD offre un bon retour sur investissement.