Journal : Fusion-IO, l'unité de stockage du futur-présent?
Posté par NickNolte () le 08 novembre 2007
Il semble que bien qu'on attende les fameux unités de stockage basé sur la techno SDD tant encencée , il y en déjà une qui se montre particulièrement plus performantes, utilisant le bus PCIe, et dont la disponibilité semble imminente et en avance sur la fameuse SDD.
http://www.fusionio.com
Personnellement, c'est à peine aujourd'hui que j'entend parler de cette technologie, qu'en est-il pour vous?
Pensez-vous que c'est developpé avec un soucis de support des systèmes d'exploitations alternatifs, notamment libres?
Il y a un support pour Red Hat AS mais il n'est pas dit que le pilote soit libre ou implémentable librement.
Ça serait dommage car même à 30$ le gigas, ça reste intéressant.
http://www.fusionio.com
Personnellement, c'est à peine aujourd'hui que j'entend parler de cette technologie, qu'en est-il pour vous?
Pensez-vous que c'est developpé avec un soucis de support des systèmes d'exploitations alternatifs, notamment libres?
Il y a un support pour Red Hat AS mais il n'est pas dit que le pilote soit libre ou implémentable librement.
Ça serait dommage car même à 30$ le gigas, ça reste intéressant.
> Lire le journal (19 commentaires, moyenne: 2,7).
Vous avez demandé le commentaire #880678.
Run by 
Cette page a été générée par Templeet en 0.0621s (dont 0.0059 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Bof...
La première carte à une capacité de 80Go, ça fait cher, cher.
J'aurais bien joué avec une plaquette à 10Go =), enfin...
[^]Re: Bof...
C'est vrai que c'est dommage, mais j'imagine qu'en dessous ce n'est plus très rentable.
M'enfin c'est un nouveau produit et les prix finirons par baisser !
[^]Re: Bof...
Ils annoncent $30 par Go, ce qui donne $2400 ou encore 1600 ¤ au taux actuel (2400 ¤ selon le taux Apple).
La cible de ce produit est l'entreprise, considérons donc les besoins d'une entreprise. La conception de ce produit est basée sur l'idée que l'on y déplace tout le système de fichier. Or les systèmes journalisés permettent de faire des choses beaucoup plus intéressantes je pense.
ext3 permet de créer un système de fichier avec un journal externe, un journal fait entre 1 et 400 Mo. L'option journal_data permet d'écrire les données dans le journal, permettant ainsi de terminer une écriture dès que l'enregistrement du journal est terminé.
En plaçant le journal sur un périphérique bloc tel que celui-ci on peut s'attendre logiquement à une énorme augmentation de la vitesse instantanée d'écriture (au final, il faudra quand même jouer les évènements du journal avant qu'il soit plein, il faut donc qu'il y ait des pauses dans l'activité disque.)
Les bases de données peuvent fonctionner selon le même principe, Oracle et PostgreSQL au moins, permettent de placer le journal de la base sur un système de fichier différent, si celui-ci est ultra-rapide, cela améliore d'autant la vitesse des transactions.
Ce genre d'amélioration est aujourd'hui possible, sans doubler le cout de la machine (3200¤ pour 2 cartes de 80 Go avec la solution Fusion-IO); hélas, aucun fabriquant ne propose ce genre de produit.
[^]Re: Bof...
hélas, aucun fabriquant ne propose ce genre de produit.
Excuse moi, mais ta dernière phrase me chiffonne, tu es peiné de l'absence de quel produit?
Parce que ton idée semble plutôt logiciel, non?
Très intéressant en tout cas.
[^]Re: Bof...
La solution n'est pas uniquement logiciel.
L'idée est d'utiliser une petite quantité de mémoire non volatile, très rapide pour accélérer les écritures disque.
l'i-Ram de Gigabyte avait la bonne capacité, mais elle utilise de la D-Ram, grande consommatrice électrique, qui fait que la batterie embarquée ne tiens même pas 24h. Pour de la mémoire non volatile, c'est un peu court. La latence extrêmement basse est un avantage, mais le fait de passer par le bus SATA entraine probablement un cout important. De toute façon la distribution de ce produit est resté extrêmement confidentiel.
Le produit Fusion-IO est très intéressant, il se connecte directement sur le bus PCI-Express, mémoire non-volatile, mais sa capacité commence à 80 Go, le cout est trop important pour équiper un serveur de deux cartes en redondance, en regard du gain envisagé.
Voici la carte que j'aimerais trouver:
- Connexion sur le bus PCI-Express
- Mémoire constitué de barrettes de mémoire classique, comme l'I-Ram, parce je pense que les débits de la carte Fusion-IO sont obtenues par la mise en parallèle d'un grand nombre de puces mémoire, ce qui explique la grande capacité. Le fait d'utiliser des barrettes produites en très grande quantité permet de réduire le cout.
- Connecteur Compact-Flash.
- Petite batterie permettant d'écrire le contenu de la mémoire dans la carte Compact-Flash en cas de coupure de courant. Ça permet de rendre le contenu non-volatile.
Ça permet de faire soit un disque très rapide et à la latence très très basse de 2 ou 4 Go; soit de l'utiliser pour les journaux, de FS ou de SGBD, pour booster la vitesse des transactions.
Pour les applications nécessitant de gigantesques quantité de mémoire, ça permet d'installer un swap dont les temps d'accès ne sont pas trop pénalisant.
Avec un driver adéquat dans le kernel, on peut même envisager d'en faire une zone de mémoire non locale utilisable pour faire du cache disque.
[^]Re: Bof...
La RAM la plus prometteuse c'est la MRAM :
http://fr.wikipedia.org/wiki/Magnetic_Random_Access_Memory
En attendant, il faut faire avec les DD. Et vu le prix des DD, ça revient pas trop cher de se faire un RAID 0+1.
Si vraiment tu recherches des performances pour un serveur, et bien tu achètes beaucoup de RAM et tu fous toutes tes données en cache disque.
[^]Re: Bof...
y'a la PRAM aussi
Subete ga wakatta toki…watashi ga anta wo korosu.
[^]Re: Bof...
Non, la RAM étant volatile, elle n'offre aucune garantie d'écriture. Les transactions du FS ou d'un SGBD ne se font pas en RAM, en cas d'erreur ou de coupure de courant, on serait incapable de récupérer quoi que ce soit.
[^]Re: Bof...
Pas du tout.
Sous Linux par exemple, le maximum de RAM est utilisé pour le cache disque pour accelerer les temps d'accès.
L'écriture se fait en différé sur les médias en asynchrone, tu imagines si tu devais attendre que ton os rende la main à l'applicatif avant chaque écriture ?
Un serveur digne de ce nom n'est pas sensible aux coupure de courant, il est soit relié à un onduleur, soit il dispose de double alim reliée chacune à une source d'alimentation différente.....
Sinon, tu es au courant pour les mini batteries dans les cartes RAID qui permettent de commiter une écriture même en cas de coupure de courant (pour les serveurs sans double alim par exemple) ?
[^]Re: Bof...
Dans le cas qui nous intéresse, les écritures ne se font justement pas de manière asynchrone. Une transaction ne doit jamais être validée si elle n'a pas été écrite sur disque.
D'une part, les applications comme les SGBD font explicitement un appel à sync() ou ouvrent les fichiers en écriture synchrone.
D'autre part, un système de fichier ne peut pas se permettre de faire les écritures dans le désordre, il est obligé d'écrire son journal de façon séquentiel, il est donc obligé d'attendre. Sans cela, la relecture du journal ne serait pas garantie.
[^]Re: Bof...
J'ai oublié de répondre au RAID.
Le stripping en RAID permet d'augmenter le débit; mais pas la latence, or c'est bien la latence qui est déterminante dans ce cas; les écritures ne sont pas forcément importantes, une ligne de log, un enregistrement modifié en base... Tout cas tiens aisément dans un paquet de données.
Le système va quand même attendre que le sous-système de stockage ait garanti l'écriture avant de passer à la suite.
Un jour j'essayerai de bencher ça avec un ramdisk.