SAN avec quelques disques SSD, ou beaucoup de disques durs à l'ancienne?


9

Mon entreprise essaie de déterminer le type de SAN à acheter. Ceci est spécifiquement pour les serveurs de base de données qui deviennent limités en E / S (le stockage est actuellement DAS, mais nous atteignons la limite d'un seul serveur et nous aimerions également ajouter le clustering).

Nous avons besoin d'une solution qui produira environ 3000 IOPS à long terme (nous atteignons actuellement environ 1000 IOPS). La plupart de nos opérations de base de données sont de petites lectures / écritures. Sur la base de discussions avec des ingénieurs HP et d'autres personnes en ligne, un HP P2000 avec 24 disques durs SAS dans une configuration RAID 10 fournira juste en deçà de cette vitesse pour environ 20 000 $. Ajouter des contrôleurs et d'autres éléments pour construire le SAN nous place autour de notre budget maximum de 30 000 $.

Mais en ligne, je constate que de nombreux SSD SAS offrent des vitesses de 80 000 IOPS +. Est-ce réaliste d'attendre? Dans l'affirmative, serait-il réaliste d'obtenir un P2000 ou un SAN d'entrée de gamme similaire et d'y ajouter quelques SSD? Nos bases de données sont petites, seulement quelques TB au total. Si nous faisions cela, nous aurions de l'argent pour acheter un deuxième SAN pour la mise en miroir / basculement, ce qui semble prudent.


3
Je répondrai à cette question sous peu.
ewwhite

Pouvez-vous établir un lien vers le modèle / type de SAN spécifique que vous souhaitez utiliser? De nombreuses mises en garde sont fournies avec les baies de stockage de style HP P2000. Comment comptez-vous vous connecter? iSCSI? Fibre? SAS?
ewwhite

De quelle plateforme de base de données s'agit-il également?
ewwhite

Voici le modèle que je regardais, juste avec une configuration de lecteur différente: aventissystems.com/product-p/200385.htm . Le SGBD est SQL Server Standard 2008 R2. Nous sommes vraiment ouverts à n'importe quelle configuration / fournisseur tant que nous pouvons évoluer "à moindre coût" à l'avenir, et aussi longtemps que nous respectons notre budget modeste.
Bip bip

De quelle capacité avez-vous besoin?
ewwhite

Réponses:


4

Je peux parler des détails de ce que vous essayez d'accomplir. Honnêtement, je ne considérerais pas un HP P2000 / MSA2000 d'entrée de gamme pour votre usage.

Ces périphériques ont de nombreuses limitations et, du point de vue des fonctionnalités SAN, ne sont rien de plus qu'une boîte de disques. Pas de hiérarchisation, pas de mise en cache intelligente, un maximum de 16 disques dans un groupe de disques virtuels , de faibles capacités IOPS, une mauvaise prise en charge des SSD (en particulier sur l'unité que vous avez sélectionnée).

Vous devrez passer au HP MSA2040 pour voir tout avantage de performance ou support officiel avec les SSD. De plus, voulez-vous vraiment utiliser iSCSI?

Le DAS peut être votre meilleure option si vous pouvez tolérer le stockage local. Le stockage flash PCIe sera inclus dans votre budget, mais la capacité devra être soigneusement planifiée.

Pouvez-vous élaborer sur les spécifications de vos serveurs actuels? Marque / modèle, etc.

Si la mise en cluster est un must-have, une autre option est de faire l'unité HP MSA2040, mais utilisez une unité SAS au lieu d'iSCSI. Ceci est moins coûteux que les autres modèles, vous permet de connecter 4 à 8 serveurs, offre une faible latence et un excellent débit et peut toujours prendre en charge les SSD. Même avec les modèles Fibre ou iSCSI, cette unité vous offrirait plus de flexibilité que celle que vous avez liée.


Merci! Nous avons tous les serveurs HP, principalement les HP DL380. La seule raison pour laquelle nous envisagions iSCSI est qu'il semblait plus facile d'étendre les 4 derniers serveurs (si nous voulions pousser d'autres données de serveur sur le SAN) et qu'il était légèrement plus rapide (10 Go contre 6 Go).
Bip bip

Cela dit, je vais jeter un œil au MSA2040 ... je ne sais pas pourquoi il n'est pas apparu sur notre radar auparavant.
Bip bip

Je peux voir la confusion ... Si vous ne prévoyez pas d'étendre au-delà de 4 ou 8 serveurs, SAS fonctionne assez bien. Et ce n'est pas 10 Gb contre 6 Gb ... c'est 10 Gb contre une interface SAS 12 Gbit / s à 4 voies (48 Gbit / s vers le boîtier).
ewwhite

Je viens de voir que le logiciel Remote Snap ne fonctionne que sur iSCSI ou FC ... nous avions espéré utiliser le snap distant pour refléter le SAN pour la reprise après sinistre. Ou existe-t-il un autre processus via SAS qui permettrait la même capacité?
Bip bip

@Beepbeep J'utiliserais probablement un processus DR différent. J'ai tendance à ne pas me fier à la réplication au niveau de l'appliance de stockage ou du SAN. Mais les versions 10GbE et FC du MSA2040 peuvent vous convenir mieux.
ewwhite

6

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.


Merci, nous sommes 100% RAID10 parce que nous nous concentrons sur les bases de données.
Bip bip

C'est commun, mais c'est aussi une erreur. RAID10 est en fait assez inutile pour les charges de travail principalement orientées en écriture. Le RAID5 / RAID6 en cache écrit a une pénalité en écriture plus faible lorsque vous effectuez par exemple l'écriture de fichiers journaux de base de données.
Sobrique

3

Votre analyse est assez correcte.

Utilisez quelques disques durs pour beaucoup de Go et beaucoup de disques durs pour quelques IOps.
Utilisez quelques SSD pour de nombreux IOP et de nombreux SSD pour quelques Go

Qu'est-ce qui est le plus important pour toi? L'espace est le principal facteur de coût pour les solutions SSD, car le prix par Go est beaucoup plus élevé. Si vous parlez d'une base de données de 200 Go nécessitant des IOP 4K, une paire de SSD vous y mènera. Ou une baie de 24 disques de 15 000 disques, vous laissant beaucoup d'espace pour le stockage en vrac.

Le nombre d'E / S que vous obtiendrez réellement de ces SSD varie beaucoup en fonction de l'infrastructure de stockage (ewwhite en parlera), mais il est raisonnable d'obtenir ce type de vitesses. Surtout avec Raid10, où la parité n'est pas calculée.


Merci pour les commentaires! Est-il raisonnable de mélanger des disques? C'est-à-dire configurer 4 SSD pour des tâches axées sur les performances, puis un tas de disques durs pour le stockage en vrac?
Bip bip

3
@Beepbeep Oui, mais soyez conscient des compromis. De nombreux iops consomment des ressources de contrôleur, ce qui signifie que vous n'obtiendrez pas le débit séquentiel maximal des disques durs. De nombreux débits séquentiels sur les disques durs peuvent évincer les E / S des disques SSD, ce qui augmente la latence en raison de la contention des canaux. Si cela vous importe, mais sur différents canaux.
sysadmin1138

0

J'ai récemment construit une paire de serveurs de stockage pour mon employeur, en utilisant le châssis Dell C2100, exécutant FreeBSD 10.1 avec douze disques SATA d'entreprise Western Digital «SE» de 2 To à 7200 tr / min. Les disques sont dans un seul pool ZFS composé de deux périphériques virtuels RAIDZ-2 à 6 disques (vdevs). Attachés au pool sont une paire de SSD Intel DC S3500 qui sont protégés par supercap contre les coupures de courant, ils sont utilisés à la fois comme SLOG et L2ARC. En testant ce serveur sur iSCSI, j'ai pu atteindre 7500-8200 IOPS. Notre coût total, disques durs compris, était d'environ 2700 $ par serveur.

Pendant le fonctionnement de ces systèmes basés sur BSD, l'une de nos unités SAN HP MSA2012i a rencontré deux défauts de contrôleur, et notre autre unité MSA2012i a corrompu un grand volume NTFS nécessitant 12 heures d'indisponibilité pour réparer.

Dell et HP vous vendent 10% de matériel et 90% de promesse d'assistance que vous ne pourrez jamais utiliser.


C'est vrai ... Une partie de moi voulait recommander un serveur HP exécutant ZFS (ou un système d'exploitation basé sur ZFS), car il fonctionnerait beaucoup mieux qu'un MSA / P2000 ... mais je ne voulais pas m'éteindre sur une tangente.
ewwhite

Oh, je n'ai aucun problème avec HP. HP et Dell constituent un excellent matériel serveur. Charge généralement mieux que certains châssis Whitebox iStarUSA ou Norco. Mais quand il s'agit de périphériques critiques (SAN / NAS est critique dans mon livre), je recommande une solution avec autant de transparence que possible. Les appareils SAN sont de grandes boîtes noires. Ils fonctionnent très bien jusqu'à ce qu'ils ne le fassent pas, puis vous êtes en haut **** ruisseau.
cathode du
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.