J'ai 40 ans dans l'informatique, mais je n'ai jamais eu à construire un serveur comme celui-ci, donc cela pourrait être une question n00b.
J'ai un client qui va proposer le téléchargement de fichiers musicaux ultra haute définition. Dans ce cas, cela signifie 24 / 192Khz compressé FLAC = ~ 10 Go / album. (Non, je ne veux pas discuter de l'opportunité du produit, juste de la configuration du serveur.) Le catalogue comptera environ 3000 albums, avec des versions ultra haute et basse définition (pour leurs iPod, je suppose), donnant environ 35 à 40 To environ de données primaires.
Comme il s'agit d'un produit très spécialisé, la taille du marché est relativement petite (pensez: aux personnes qui dépensent plus de 20000 $ sur leurs systèmes audio), ce qui signifie que la plupart du temps, le serveur sera 100% inactif (ou proche). J'ai ce qui ressemble à une bonne offre de colocation de ColocationAmerica avec une connexion à 1 Gbit / s et une bande passante à environ 20 $ / To, alors maintenant je n'ai plus qu'à construire une boîte pour livrer les marchandises.
Le cas d'utilisation de l'accès aux données est en écriture unique / en lecture multiple, je pense donc à utiliser uniquement le logiciel RAID 1 pour les paires de disques. Cela me permettrait (je pense ) de reconfigurer les disques de rechange pour les disques défectueux à la volée, ce qui permettrait de démarrer la reconstruction du deuxième disque avant que certains administrateurs système ne remarquent le voyant rouge sur le système (ils font un échange gratuit). Ce serait formidable si je pouvais mettre la plupart des disques en veille / ralentir s'ils ne sont pas nécessaires, ce qui sera la plupart du temps pour la plupart des disques.
Je n'ai pas besoin de beaucoup de puissance de calcul - cette chose ne fait que pousser des objets gras dans le tuyau - et donc le CPU / carte mère peut être assez modeste tant qu'il peut prendre en charge ce nombre de disques.
J'envisage actuellement la configuration suivante:
Chasis: Supermicro CSE-847E26-RJBOD1
Drives: 30 4TB SAS drives (Seagate ST4000NM0023 ?)
MB: SUPERMICRO MBD-X10SAE-O w/ 8GB
CPU: Xeon E3-1220V3 3.1GHz LGA 1150 80W Quad-Core Server
Alors, est-ce que je vais dans la bonne direction, ou est-ce une façon complètement n00b / dinosaure d'aborder le problème?
Mise à jour pour clarifier quelques points:
- Je n'ai aucune expérience avec ZFS, car le dernier produit Sun que je possédais était de retour à la fin des années 80. Je vais faire un peu de RTFMing pour voir si ça me va.
- Je n'ai pas vraiment besoin du système de fichiers pour faire quoi que ce soit de spectaculaire, car les noms de fichiers seront de simples UUID et les objets seront équilibrés sur les disques (un peu comme un grand système de mise en cache). Donc, je pensais vraiment à ces derniers comme 40 systèmes de fichiers distincts, et cela donnait un son RAID 1 à peu près correct (mais j'avoue l'ignorance ici).
- Parce que nos attentes actuelles sont qu'il est peu probable que nous téléchargions plus d'une douzaine de fichiers à la fois, et dans la plupart des cas, il y aura exactement une personne téléchargeant un fichier donné, je ne sais pas si nous avons besoin de tonnes de mémoire pour les tampons. Peut-être que 8 Go est un peu léger, mais je ne pense pas que 128 Go feront plus que consommer de l'énergie.
- Il y a 2 machines distinctes non mentionnées ici: leur boutique en ligne actuelle et un Download Master presque complètement découplé qui gère toute l'authentification, la gestion de l'ingestion de nouveaux produits, l'application des politiques (après tout, c'est le terrain de jeu de la RIAA), la création d'URL éphémère (et éventuellement remise des téléchargements à plus d'une de ces bêtes si le trafic dépasse nos attentes), suivi de l'utilisation et génération de rapports. Cela signifie que cette machine pourrait presque être construite en utilisant des gerbilles sur Quaaludes.
ZFS? Quel est l'avantage?
OK, je me fraye un chemin à travers plusieurs guides ZFS, FAQ, etc. Pardonnez-moi de paraître stupide, mais j'essaie vraiment de comprendre l'avantage d'utiliser ZFS sur ma notion antédiluvienne de N paires RAID1. Sur cette page des meilleures pratiques (de 2006), ils suggèrent même de ne pas faire un ZFS à 48 appareils, mais 24 miroirs à 2 appareils - cela ressemble un peu à ce que je parlais de faire. D'autres pages mentionnent le nombre d'appareils auxquels il faut accéder pour délivrer 1 (un) bloc ZFS. N'oubliez pas non plus qu'à 10 Go par objet et à 80% d'utilisation du disque, je stocke un grand total de 320 fichiers par lecteur de 4 To . Mon temps de reconstruction avec N RAID 1, pour une panne de disque donnée, est une écriture de 4 To d'un périphérique à un autre.Comment ZFS améliore-t-il cela?
J'avoue être un dinosaure, mais le disque est bon marché, RAID 1 je comprends, mes besoins en gestion de fichiers sont triviaux, et ZFS sur Linux (mon OS préféré) est encore un peu jeune. Je suis peut-être trop conservateur, mais quand je regarde un système de production, c'est comme ça que je roule.
Je vous remercie tous pour vos commentaires qui m'ont fait réfléchir à ce sujet. Je ne suis toujours pas complètement décidé et je devrai peut-être revenir et poser d'autres questions sur le n00b.
la source
Réponses:
En fonction de la description de votre problème, votre problème n'est pas tant le serveur que le stockage.
Vous voulez un système de fichiers fiable et robuste comme ZFS , conçu pour gérer correctement une grande capacité de stockage et doté de capacités de gestion intégrées pour faciliter la gestion de cette extrémité du système.
Comme mentionné dans les commentaires, j'irais avec ZFS pour le pool de stockage (probablement sur FreeBSD parce que je suis le plus familier avec ce système d'exploitation et parce qu'il a une longue expérience éprouvée de performances solides avec ZFS - Mon deuxième choix OS serait Illumos , encore une fois en raison du support ZFS bien testé).
En ce qui concerne la distribution des fichiers, je suis d'accord - vous n'avez pas besoin de beaucoup de matériel pour simplement pousser les données hors du port réseau. Votre pilote principal pour CPU / RAM sera les besoins du système de fichiers (ZFS).
La règle générale est que ZFS a besoin de 1 Go de RAM, plus 1 Go pour chaque 10 To d'espace disque qu'il gère (donc pour 40 To, vous auriez besoin de 5 Go de RAM pour ZFS) - la relation n'est cependant pas tout à fait linéaire (il y a beaucoup de bons livres / tutoriels / documents sur ZFS qui peuvent vous aider à trouver une estimation pour votre environnement).
Notez que l'ajout de cloches et de sifflets ZFS comme la déduplication nécessitera plus de RAM.
Évidemment, arrondissez les besoins en RAM plutôt que vers le bas et ne soyez pas avare: si vos calculs indiquent que vous avez besoin de 5 Go de RAM, ne chargez pas le serveur avec 8 Go - passez à 16 Go.
Vous pouvez ensuite soit exécuter votre serveur directement sur le boîtier de stockage (ce qui signifie que vous aurez besoin d'encore plus de RAM sur ce boîtier pour prendre en charge les processus du serveur), soit monter à distance le stockage sur des serveurs "frontaux" pour servir réellement les demandes des clients.
(Le premier est moins cher au départ, le second évolue mieux à long terme.)
Au - delà de ce conseil les meilleures suggestions que je peux vous donner sont déjà bien couverts dans notre série de planification des capacités de questions - essentiellement « des tests de charge, tests de charge , tests de charge ».
la source
fsck
si vous utilisez ZFS et la machine plante. J'aifsck
des téraoctets de fichiers. C'est assez terrible.J'utilise ZFS pour un serveur multi-TB et il a été très solide. J'ai utilisé OpenIndiana pour commencer et je suis maintenant passé à FreeNAS car il fait ce dont j'ai besoin.
Je recommanderais d'utiliser une carte LSI HBA (9211-8i est une bonne carte de base) avec des expandeurs SAS (les boîtiers SuperMicro peuvent être commandés avec des expandeurs SAS intégrés basés sur des chipsets LSI). Le firmware LSI est pris en charge dans FreeNAS et FreeBSD. Vérifiez les versions appropriées (V16 est bon sur FreeBSD V9.x).
Compte tenu de l'écriture une fois lue de la nature de votre système, j'utiliserais une topologie ZFS Z2 (évitez RAID-5 et Z1 avec des disques de cette taille). Étant donné que vous utilisez des disques de 4 To, le temps de reconstruction (resilver) pour un grand tableau vDev unique serait long si le pool est plein. Pour éviter de longs temps de reconstruction, organisez les vDev en groupes de 6 ou 10 pour créer le pool (recommandations de la documentation FreeNAS). Un pool composé de trois vDev à 6 disques (disques de 4 To supposés) aurait une capacité utile de ~ 48 To et offre un bon niveau de tolérance aux pannes (rappelez-vous que vous devez toujours sauvegarder des données car le RAID ne remplace pas les sauvegardes :)).
Pour accélérer les choses pour les fichiers couramment consultés, vous pouvez ajouter quelques SSD pour L2ARC (probablement pas nécessaires pour votre application, mais ils sont assez bon marché pour les SSD de 120 Go).
Et comme indiqué, utilisez beaucoup de RAM. 64 Go n'est pas trop cher compte tenu de l'autre matériel du système. Malheureusement, le plus petit XEON ne peut pas utiliser plus de 32 Go. Vous pouvez l'essayer, mais plus de RAM serait mieux selon la littérature ZFS (j'utilise le XEON que vous mentionnez avec 32 Go de RAM et une matrice Z2 de 24 To et cela fonctionne très bien).
Un autre avantage de ZFS est que vous pouvez configurer des instantanés périodiques. De cette façon, vous pouvez restaurer facilement les versions précédentes et les instantanés sont très économes en espace. De plus, vous pouvez répliquer n'importe quel instantané vers un autre ensemble de données (local ou distant) et cela peut être fait via SSH pour plus de sécurité.
J'aime vraiment la fiabilité du système ZFS. J'aime aussi le fait que ce soit du matériel INDÉPENDANT !! Tout système qui peut voir les lecteurs peut importer le pool. Pas de dépendances de firmware, etc., qui peuvent se produire avec un raid matériel (ce n'est pas un problème avec de meilleures cartes, mais elles sont plus chères que les cartes HBA et ont besoin de pilotes, etc. - elles ont été mordues par le passé).
Étant donné que ce message est plus ancien, vous avez probablement une solution. Si oui, ça vous dit ce que vous avez construit?
À votre santé,
la source