Le site des administrateurs systèmes sous Mac OS X
  Un grand pouvoir implique de grandes responsabilités.



Accueil du site > Dossiers > Choix d’un serveur et d’une solution de stockage
Choix d’un serveur et d’une solution de stockage


XSan, NAS, DAS, et autres systèmes de stockage. vendredi 5 septembre 2008, par Jayce Piel

Le choix d’Apple de ne plus commercialiser de XServe-RAID m’a fait me pencher sur l’existant en ce qui concerne le stockage. Nous allons voir dans cet article les solutions disponibles pour aiguiller votre choix.


Problématique

Dans une entreprise, quelle que soit sa taille, la question d’avoir un serveur de fichiers se pose forcément. Ce n’est pas forcément la réponse adéquat à tout le monde, mais c’est à coup sûr une solution qu’il faut étudier. Et quand cette question se pose, une autre arrive tout de suite : quel type de stockage ?

Nous verrons dans cet article que le choix est très varié et qu’il faut avoir une réelle réflexion sur les besoins avant le budget, même si celui-ci, vu les écarts de prix importants, reste un critère de choix important.

Nous ne parlerons pas, dans cet article, des solutions de sauvegarde électrique, à base d’onduleur ou autre protection plus ou moins chère. De même, la sauvegarde ne sera qu’abordée, mais à titre d’exemple. Là encore cela dépend beaucoup des besoins et du budget et la gestion des sauvegarde mériterait un article à part.

Un peu de définitions

Avant de commencer, il faut absolument être au clair sur les différents termes utilisés. On va parler de NAS, de SAN, de DAS, de RAID etc.

Qu’est-ce que le RAID ?

Pour avoir des informations complètes sur les technologies RAID, je vous invite à consulter l’excellent article Wikipédia sur le sujet. Pour résumer un peu, voici les quelques définitions et réflexions que l’on peut resortir :

  • RAID logiciel/matériel, avantages et inconvénients :

— le RAID logiciel permet de monter une configuration RAID sans tenir compte des contraintes matérielles. Il permet également un support parfait du RAID si on change les disques de machine (pour une machine ayant le même OS), on peut donc facilement remettre en marche le RAID si la machine l’hébergeant a un problème. Les performances sont en revanche moins bonnes qu’avec un RAID matériel. Mac OS X ne permet de faire que du RAID 0 ou du RAID 1 (et de la concaténation, appelée aussi NRAID [1]). Linux et BSD, en revanche, permettent de faire du RAID logiciel 0, 1, 4, 5, 6 et même de les combiner.

— le RAID matériel offre une plus grande souplesse dans le choix du type de RAID ainsi que de meilleures performances. Cependant, la configuration du RAID est très liée à la baie, et en cas de défaillance matérielle, il faut trouver une baie du même modèle avec la même version de firmware pour espérer reconstruire le RAID. De plus, plus il y a d’électronique, plus le risque de panne augmente. Si on opte pour une solution à base de RAID matériel, il ne faut pas hésiter à aller dans le haut de gamme offrant une redondance des alimentations et des contrôleurs.

  • les différents types de RAID utiles, avantages et inconvénients (on considère ici que tous les disques de la baie sont de même capacité, sinon, c’est toujours le plus petit pris en référence)

— Le RAID 0 permet d’augmenter la capacité et la rapidité en combinant les différents disques en un seul volume. La vitesse d’écriture et la taille du volume disponible sont proportionnels au nombre de disque. Un système RAID-0 avec 3 disque de 100Go donnera une volume de 300Go avec un débit théoriquement 3 fois plus important que le débit d’un seul disque. Par contre, la panne d’un seul disque de la baie entraîne la perte totale des données.

— Le RAID 1 (mirroring/miroitage permet d’augmenter la sécurité au détriment de l’espace disponible. Chaque disque de la baie est une copie conforme des autres. Les informations sont écrites en même temps sur tous les disques. La taille du volume est par contre la taille d’un seul disque, mais il faut que tous les disques tombent en panne en même temps pour que les données soient perdues.

— Le RAID 5 permet un compromis entre le RAID 1 et le RAID 0. En effet, grâce à de sombres techniques de calcul de parité, le système tourne encore parfaitement avec un disque HS, et peut reconstruire le contenu de ce disque si il est changé. Attention, cependant, la perte d’un deuxième disque pendant la panne d’un premier (y compris durant la phase de reconstruction) entraîne la perte totale des données. [2] Au niveau performance en écriture, il est un peu moins bon que les autres RAID à cause du temps de calcul de la parité. Ce type de RAID nécessite au minimum 3 disques et la taille du volume disponible est égale à la taille d’un des disques multipliée par le nombre de disque moins un. Avec 4 disques de 100Go, on aura donc un volume de 300Go.

— Le RAID 6 est un RAID 5 permettant la perte de 2 disques simultanément. La perte des données intervient donc seulement au troisième disque en panne simultanément. Les inconvénients sont des performances en écriture encore plus affectées et l’obligation d’avoir un disque en plus.

— La combinaison de RAID permet, en échange d’un coût matériel important, de combiner les avantages des différents niveaux de RAID en en limitant les inconvénients. Il faut faire attention au sens de la combinaison. Une combinaison de RAID xy (ou RAID x+y) indique que l’on a des grappes en RAID x, et que chaque grappe est vue comme un disque dans un RAID y. Ainsi un RAID 10 est un très bon choix pour la fiabilité (il faut que tous les disques d’une grappe soient défectueux pour avoir une perte de données). En revanche, un RAID 01 perd une grappe dés qu’un seul disque de la grappe est défectueux. Le RAID 05 n’a aucun intérêt tandis qu’un RAID 15 ou 51 sont, coût matériel mis à part, très intéressants.

SAN, NAS, DAS… kesako ?

Commençons par le plus simple, celui que vous avez sûrement déjà rencontré, même sans le savoir, le DAS. De l’anglais Direct Attached Storage, le DAS est donc une unité de stockage raccordée directement à la machine. En fait, un disque dur externe quelconque est un DAS, tout comme une baie de disques FireWire.

Le NAS Network Attached Storage, à l’inverse, est une unité de disque que l’on ne peut contacter que par le réseau. C’est en fait un serveur de fichiers. On peut citer par exemple les Filer de NetApp qui furent les premiers véritables NAS. Par extension, on peut considérer comme un NAS un ordinateur faisant office de serveur de fichiers. Il est cependant plus courant de n’appeler NAS que les solutions dédiées avec un système d’exploitation allégé ne servant qu’au partage de fichiers. Certains disent pourtant qu’un NAS peut être le point d’entrée d’un SAN…..

Le SAN Storage Area Network est en fait une mutualisation des système de stockage, à l’inverse du NAS qui en est une centralisation. En fait, le SAN permet à chaque serveur de voir un réseau d’unités de stockage comme si il était un de ses propres disques durs. Là encore, les concepts étant relativement compliqués, je vous renvoie vers la page idoine sur Wikipédia qui sera beaucoup plus précise que moi. XSan est la solution logicielle d’Apple pour gérer un SAN.

Fibre Channel, iSCSI, FireWire, eSATA ?

Le FireWire et le eSATA sont des interfaces assez bien connues car très répandues sur les boîtiers de disques pour leur facilité d’utilisation et leurs débits (400 ou 800 Mbps pour le premier, 1.5 ou 3 Gbps pour le deuxième). C’est les interfaces privilégiées pour la plupart des DAS.

Le Fiber Channel, lui, permet un débit de 1, 2 ou 4 Gbps mais est clairement un type d’interface dédié à la gestion des SANs. Sa mise en place n’est ni simple ni économique si on veut l’utiliser au mieux.

Enfin, l’iSCSI serait un compromis intéressant entre les deux. Il permet de se connecter à un système via un réseau ethernet en considérant ce système comme un simple périphérique SCSI rattaché directement à l’ordinateur. L’iSCSI peut s’utiliser sur une infrastructure réseau existante ou dédiée et permet des débits allant jusqu’à 1Gbps, voir 2 en cas d’agrégation de ports. Sa mise en place ne nécessite que l’installation des drivers [3] adéquats sur les serveurs. Bien que certains considère l’iSCSI comme un Fiber Channel via Ethernet permettant de faire un SAN à faible coût, on peut surtout le considérer comme un DAS réseau

Les critères de choix

Même si cela paraît évident, le choix de la solution se fera en fonction de deux critères primordiaux : le besoin et le budget.

Un budget illimité ne veut pas forcément dire qu’il faut prendre tout de suite un truc avec tout plein de serveurs en redondance et de baies en redondance, si la seule chose que va faire notre serveur de fichier est de servir de serveur d’archivage. Dans ce cas, on peut se permettre de ne pas avoir le serveur en ligne pendant quelques heures en cas de problème sans que cela gêne. Et il y a des solutions beaucoup plus simples à gérer et répondant bien mieux au problème de 2 XServe + X baies RAID Promise… :-) Un serveur hébergeant les comptes utilisateur pourra difficilement être indisponible pendant plus de quelques minutes, et encore…

Mais il est évident que le budget doit être pris en compte parce que la différence de prix entre une solution RAID 0 ou 1 à deux disques (quelques centaines d’euros au pire) et une baie Promise (plus de 10000 euros) amène à faire réfléchir.

En fait, le choix se résume souvent à choisir entre l’importance des données ou l’importance des sauvegardes.

Les questions que l’on peut se poser sont, à mon avis dans l’ordre, les suivantes :
 1) Quelle taille de donnée vais-je devoir gérer ?
 2) Les données stockées sont-elles vitales ?
 2.1) En cas de panne, quel est le délai de rétablissement maximum ?
 2.2) En cas de panne, peut-on envisager une intervention manuelle « immédiate » ou faut-il tout automatiser ?
 3) En cas de panne, puis-je me permettre de tourner quelques temps avec des performances réduites ?
 4) Quels sont les services que gérera mon serveur principal ?

La première question est certainement la plus importante. On ne regardera pas vers les mêmes matériels si on veut gérer 200Go ou 4To. Bien dimensionner ses besoins va permettre de mieux cibler les matériels et les solutions disponibles.

Une fois le problème de la taille des données réglé, reste leur valeur. C’est ce que l’on va évaluer avec la deuxième question et les deux question qui en découlent. Les données sont-elles vitales ? On aurait tendance à dire oui automatiquement, mais ce n’est pas forcément le cas. Si par exemple, le serveur stocke les données utilisateurs et que tous les utilisateurs sont en compte mobiles, les données sur le serveur ne sont pas cruciales. De même si les données ne sont que des archives qui n’évoluent pas beaucoup et ne sont pas nécessaires au quotidien (et qui, bien sûr, sont sauvegardées ailleurs).

Si on considère nos données comme vitales, il faut ensuite déterminer à quel point. Je ne considère même pas une solution n’acceptant pas la moindre coupure, c’est d’un autre niveau que celui développé dans cet article. Mais les choses ne sont pas les mêmes si il faut un délai de quelques minutes, de quelques heures ou d’un ou deux jours, c’est le but de la question 2.1 :

  • si on doit avoir un délai de rétablissement de quelques minutes maximum, il faut s’orienter vers la gestion d’un service d’IP-FailOver. Dans ce cas là, si le serveur principal tombe, le secondaire « prend » son IP et se met à gérer ses services. Pour ce qui est des données, on ne peut utiliser de DAS, aucun DAS, à ma connaissance, ne gérant une double connexion. Il faut donc absolument utiliser un NAS ou un SAN. Tout doit donc être totalement automatisé, ce qui répond à la question 2.2…
  • pour un délai de rétablissement de quelques heures (ou quelques dizaines de minutes), la gestion de l’IP-FailOver n’est pas judicieuse. C’est en effet très compliqué à mettre en place et il faut être extrêmement rigoureux, notamment lors des mises à jour systèmes. L’utilisation d’un deuxième serveur « esclave » est par contre tout à fait envisageable, il prendra alors facilement le relais en cas de panne du maître. Ensuite, plus le délai doit être faible, plus on s’orientera plutôt vers un NAS, pour faciliter la transition.
  • toujours dans le cadre d’un délai de rétablissement raisonnable, une autre solution peut-être d’avoir un serveur « de spare ». Que ce soit une machine dédiée ou un autre serveur non vital. Il suffit alors de gérer une sauvegarde régulière et bootable du serveur principal sur un disque externe que l’on branchera sur ce serveur de secours pour démarrer dessus (les données étant sur la baie de stockage). Dans ce cas là, on peut utiliser le système que l’on veut pour les données, avec en revanche en tête qu’il faut, si on choisit un DAS, que la connectique de celui-ci soit compatible avec le serveur de secours…
  • Si on peut se permettre jusqu’à un ou deux jours de coupure, le plus simple est alors peut-être de dépenser son argent et son énergie dans une bonne solution de sauvegarde (système + données) que l’on récupérera simplement lors d’un problème. Il faut donc juste prévoir des pièces de rechange d’avance.

La réponse à la question de l’intervention manuelle ou automatique est à la fois dépendante de la question précédente, mais pas seulement. Il se peut que le serveur soit sur un site où il n’y a pas forcément quelqu’un susceptible d’intervenir physiquement sur les serveurs en cas de problème, ou pas dans un délai raisonnable au vu de la question 2.1… Là encore, il faudra se pencher sur la question et éventuellement, en cas d’intervention manuelle nécessaire, définir une procédure écrite au cas ou les admins ne seraient pas disponibles.

Enfin, dois-je impérativement faire tourner mon système à performances égales en cas de problème (flux de production tendu) ou puis-je me permettre de dégrader les performances le temps de réparer les problèmes ? Si on doit garder des performances maximales, il va falloir penser à « doubler » le serveur principal pour s’assurer d’un service équivalent. Sinon, prendre un Mac mini ou une autre machine disponible en guise de machine de secours peut nettement suffir.

La question 4, enfin, nous ramène sur terre en nous faisant réfléchir à quoi va servir notre serveur. Est-ce que ce sera simplement un serveur de fichier ? (inutile en cas d’utilisation d’un NAS) Uniquement un serveur de fichiers et serveur OpenDirectory ? (à ce moment là, un XServe est nettement surdimensionné et il vaut mieux se pencher vers des machines plus abordables.) Ou est-ce qu’il gérera d’autres choses comme des machines virtuelles et autres joyeusetés bouffeuses de ressources ?

Un peu de docs

Ci joint un lien vers un rapport de Google sur les pannes de disque. (malheureusement en anglais)

Une solution premier-prix

J’ai actuellement, à la Fédération Française de Tir, une solution simple et abordable qui répondait jusqu’ici à mes besoins.

En guise de serveur principal, j’avais un PowerMac G5. Branché à ce serveur, un boîtier firewire avec deux disques en RAID-1 (BF). Également branchés sur ce serveur deux disques externes (DF1 et DF2), également firewire, pour les sauvegardes.

BF contient deux partition : la première est une copie du système faite chaque soir. La deuxième contient l’ensemble des données utilisateurs et mes bases 4D.

Chaque Week-End, je fais une sauvegarde intégrale et compressée des données sur un des disques externe (je change de disque chaque semaine), et chaque jour de la semaine je fais une sauvegarde incrémentale sur ce même disque. Cela me permet de rechercher dans des sauvegardes datant de minimum une semaine et jusqu’à deux.

Pour assurer bretelles et ceinture, je fais même une copie de ces disques externes sur BF. Enfin, chaque Vendredi, je sors un des deux disques de BF pour l’emmener à la banque et je remets celui de la banque à la place.

En cas de problème sur mon boîtier BF, je peux utiliser un des deux disques dans un boîtier Firewire standard. En cas de problème matériel sur le PowerMac, je peux brancher le boîtier sur un autre ordinateur (j’ai justement un PowerMac G4 qui ne gère que DeployStudio et ma base d’inventaire) le temps de trouver mieux.

Cette solution est relativement fiable et m’assure de pouvoir retomber sur mes pattes facilement, mais n’est pas vraiment souple. En effet, BF est limitée en taille à la taille maximum d’un disque (j’ai des disques de 500Go, et les plus gros actuellement font 1To, à condition que le boîtier gère bien les disques de 1To, ce qui n’est pas le cas d’un autre boîtier équivalent qui ne gère pas les disques de plus de 250Go). L’augmentation de la taille du volume passe cependant forcément par le rachat de minimum 3 disque à la nouvelle taille et la copie des données des disques actuels vers les nouveaux. L’un de mes problème est justement que je veux gérer beaucoup plus de données. Je veux pouvoir stocker les données d’un poste sur lequel je fais actuellement des sauvegardes manuelles et qui gère un peu moins d’1 To de données. Je vais donc être très largement à l’étroit, même en changeant les disques.

Cette solution implique également des manipulations manuelle à faire en cas de problème. Dans mon cas, ce n’est pas forcément gênant, mais cela peut limiter le choix de certains.

Une solution optimale

Bien qu’on ne puisse jamais parler de solution typiquement optimale, cela dépendant toujours des besoins spécifiques, voici une configuration qui a presque toutes les qualités, sauf le coût.

1 XServe en serveur principal.

1 baie Promise VTrack E-Class avec 16 disques de 300Go en SAS. On gérera la baie en RAID 61 avec de grappes de 8 disques en RAID 6, les deux grappes étant miroitées en RAID-1 [4].

1 XServe en serveur secondaire, avec gestion de l’IP-FailOver.

XSan installé sur les deux serveurs.

Au moins un kit de pièces de rechange pour XServe…

Avec une telle solution (voir devis sur l’AppleStore en pièce jointe), qui tourne à plus de 30000 euros, on peut voir venir sereinement les problèmes… (et le livreur, car ce panier bénéficie de la livraison gratuite m’indique l’AppleStore….. :-) ) (à noter qu’il faut rajouter deux licences XSan à 1000 euros l’une)

PDF - 103 ko
Devis solution optimale
Voici un devis pour une solution complète gérant la redondance des serveurs et des données.

Il reste, en plus de tout cela, à gérer un système de sauvegarde qui se devra d’être à la hauteur de cette solution.

Un compromis intéressant

Si on veut un compromis intéressant, on peut envisager la solution suivante :

1 Xserve en serveur principal avec un kit de pièces de rechange (entre 5000 et 8000 euros suivant la configuration et les options de support)

1 deuxième machine en serveur secondaire, suivant les besoins, on pourra se pencher vers un deuxième XServe, un Mac Pro (bien que le gain en prix ne soit pas énorme par rapport au XServe), voir même un Mac Mini ou un Mac Book Pro [5].

1 disque Firewire externe pour la sauvegarde du système du serveur principal si on ne souhaite pas automatiser la bascule entre les deux serveurs.

Un boîtier (ou baie rackable) gérant 4 à 5 disques minimum pouvant être utilisé en FireWire ou en eSATA ou en liaison avec une carte PCI-Express dédiée. Là encore, cela dépendra des serveurs (surtout le secondaire) que vous aurez choisi et de sa connectique. À noter qu’à l’heure actuelle, je n’ai trouvé aucun moyen « normal » (il existe des bidouilles ou on ouvre le mac mini et où on le laisse tourner ouvert) de brancher une carte PCI-Express sur un Mac Mini…

Quelques solutions types

Voici un petit tableau récapitulatif de certaines solutions types pour comparer les différents types de solutions. Ce tableau n’est pas exhaustif et ne représente que quelques offres au moment ou ce tableau est écrit, il ne doit donc être utilisé que pour orienter le choix.

Comparatif des solutions (première partie)
SATABeast XiPromise VTrakAccuRAID AR316F4EliteRAID ER104I
Baie Rackable 4UBaie Rackable 3UBaie Rackable 3UBaie Rackable 1U
De 4 à 42 disques SATA (jusqu’à 41To)
RAID 0, 1, 1+0, 4, 5, and 6
de 8 à 16 disques SATA ou SAS (jusqu’à 12To)
RAID 0, 1, 1E, 5, 6, 10, 50 et 60
de 2 à 16 disques SATA (jusqu’à 16To)
RAID 0, 1, 0+1, 3, 5, 6
de 2 à 4 disques SATA (jusqu’à 4To)
RAID 0, 1, 5, 6
4Gb Fibre Channel
iSCSI Gigabit
4Gb Fibre Channel4Gb Fibre ChanneliSCSI Gigabit
De 12000€ (4 disques 500Go) à 52000€ (42 disques 1To)
(hors options de maintenance/formation)
de 10000€ (8 disques SATA) à 15000€ (16 disques SAS)de 4900€ (sans disque) à 6500€ (16 disques 1To)de 1500€ (sans disque) à 2000€ (4 disques 1To)
Mémoire cache de 512Mo, 1Go ou 2Go au choix.
1 ou 2 contrôleurs RAID
1 ou 2 contrôleurs Fibre Channel et iSCSI
2 alimentations redondantes
officiellement supporté avec XSan2
2Go de mémoire Cache
2 contrôleurs RAID avec 2 ports Fibre Channel chacun
Plus de modèles d’AccuRAID (jusqu’à 42 disques)
4 ventilateurs + senseur de température pour chaque disque
2 alims redondantes (jusqu’à 4 en option)
possibilité de le brancher avec un EliteSTOR ES104TI pour qu’il se comporte comme une baie 2U de 8 disques pour moins de 400€ de plus. Voir la description détaillée.
Voir également en MobileRAID + MobileSTOR.
Comparatif des solutions (deuxième partie)
iSAN Storage 80MobileRAID MR5CT1LaCie Biggest QuadraeXtremStor MSH 8
Baie Rackable 2UBoîtier externeBoîtier externeBaie Rackable 2U ou Boîtier externe
De 4 à 8 disques SATA
RAID 0/1/10/3/5/6
De 2 à 5 disques SATA (jusqu’à 5To)
RAID 0, 1, 1+0, 3, 5, et 6
de 2 à 4 disques SATA (jusqu’à 4To)
RAID 0, 0+1, 5, 5+spare
de 2 à 8 disques SATA ou SAS (jusqu’à 8To)
RAID 0, 1, 3, 5, 6, 10, 50
iSCSI Gigabit
FC en option
FireWire 800
USB 2.0
eSATA
FireWire 800 et 400
USB 2.0
eSATA
2 connecteurs mini-SAS (pour connexion à une carte RAID matériel)
de 5500€ (4 disques 500Go) à 11000€ (8 disques 1To)de 1000€ (sans disque) à 2500€1520€ (avec 4 disques 1To)de 2800€ (5 disques 750Go) à 5200€ (8 disques 1To)
jusqu’à 4Go de mémoire
3 ventilateurs extractibles
2 alimentations redondantes
modules de ventilation et d’alimentation redondants et échangeables à chaud
Migration de niveau de RAID possibles (par ex. de RAID0 vers RAID5)
Livré avec une carte RAID Highpoint HPT-3522 (PCI-eXpress)

Il est important de noter que la plupart des baies Fibre Channel sont entièrement compatibles avec XSan 2.0, même si Apple ne supporte officiellement que la baie Promise. C’est le cas par exemple de l’AccuRAID AR316F4, mais certainement, aussi, du SATABeast Xi.

Un cas réel

En conclusion de cet article, voici la solution que je vais envisager à la FFTir. (À compléter une fois le choix fait.)


[1] La concaténation permet de combiner l’ensemble des disques en un seul. À la différence du RAID 0, on attends de remplir complètement un disque avant de commencer à remplir les autres. C’est moins rapide, mais ça permet d’avoir moins de risque de perdre les données en cas de défaillance.

[2] En général, les disques contenus dans une baie RAID ont le même âge, sont de la même série, ont été utilisés autant de fois, et donc, ont statistiquement autant de chance de tomber en panne en même temps, il n’est donc pas que théorique de penser à ce problème. Une solution pour amoindrir ce risque pourrait être de changer les disques un par un, à intervalle régulier pour qu’aucun des disques n’ait une durée de vie similaire.

[3] Voir par exemple l’initateur iSCSI de globalSAN. Vous trouverez également sur leur site une introduction à l’iSCSI.

[4] Je ne suis pas sûr que le VTrack sache faire du RAID 61, mais, si ce n’est pas le cas, il est tout à fait envisageable, je pense, de gérer deux grappes en RAID-6 et de gérer le RAID-1 logiciellement.

[5] L’utilisation d’un portable comme les MacBook Pro en guise de serveur n’est pas un mauvais choix. En effet, ils disposent, de fait, d’un onduleur intégré, ont un large choix de connecteurs, et permettent même de se connecter à n’importe quel périphérique nécessitant une carte PCI-Express via un adaptateur ExpressCard.


[ Haut ] Enregistrer au format PDF

Creative Commons License

Cette création est mise à disposition sous un contrat Creative Commons.




Recommandez ce site à un ami :

Votre Prénom : E-mail de votre ami :

Valid XHTML 1.0 Transitional

FORUM DE L'ARTICLE :



3 Messages de forum
Choix d’un serveur et d’une solution de stockage

2 septembre 2008 10:03, par Yoc
Excellent article qui tombe à pique pendant une étude en cours sur le changement des serveurs et du système de stockage dans notre entreprise. L’arrivée d’un serveur de messagerie et de workgroup digne de ce nom, en plus d’un serveur d’archivage qui aura besoin d’un gros volume de stockage nous oblige à revoir le tout. On nous a préconisé un Vtrack en SAS (temps d’accès bien meilleurs que le SATA) connecté avec XSan. Gros budget, mais l’idée de travailler avec un SAN est plus que séduisante :)
Choix d’un serveur et d’une solution de stockage

2 septembre 2008 10:14, par Jayce Piel
Héhé, c’est fou comme l’été est souvent le moment de se poser ce genre de questions… Effectivement, le VTrak en SAS doit être un foudre de guerre… Attention à vérifier que ce n’est pas non plus surdimensionné… Je n’ai pas encore fini le tableau comparatif, je vais rajouter quelques solutions abordables…
Choix d’un serveur et d’une solution de stockage

2 septembre 2008 10:42, par Yoc
On nous a aussi proposé un Storex Pro raa12rf (http://www.storex-pro.com/storex-pr…) : une baie RAID en Fiber Channel avec connectique en SATA, RAID : 0, 1, 0+1, 3 & 5, 30 et 50, 12 Disques max. J’ai eu un devis à 5000 € avec 8 disques de 500 Go, double alim et double ventilateur. Par contre, je ne sais pas si ça fonctionne avec XSan, en tous cas Apple n’a pas l’air de l’avoir certifié.