En ce moment j'ai un Maxtor IDE 120Go 8 Mo. Je desire un 2e DD identique en
stockage mais je me tate entre un SATA et un IDE car je vais changer de
config. Les constructeurs sont :
- Maxtor
- IBM/Hitachi (dont je ne veux plus entendre parler -> 3 DD morts)
- Seagate
- Western Digital.
Sachant que le Maxtor SATA est au meme prix que l'IDE, les autres subissent
une augmentation approximative de 15 euros. Le jeu en vaut il la chandelle
et quelle marque choisir ?
A ce niveau, ne pense tu pas que le SCSI s'impose ?
Vu le prix, non. Le SCSI n'est plus bon qu'à gérer des librairies et des lecteurs de bandes, en exagérant à peine.
Dans une baie professionnelle et si l'on veut de la perf, c'est le Fibre Channel qui s'impose...
Si l'on veut de la capa pas chère c'était jusqu'à hier l'IDE et aujourd'hui le SATA.
(Même pour les librairies et les lecteurs de cartouches, le marché est aujourd'hui essentiellement Fibre Channel : IBM/HP LTO2 FC, StorageTek 9840/9940 FC, etc...)
Cordialement. Didier.
-- Pour répondre par mail, enlever NOSPAM- dans l'adresse. To answer by mail, remove NOSPAM- in address.
boulu <boulu@marre_du_spam.com> :
A ce niveau, ne pense tu pas que le SCSI s'impose ?
Vu le prix, non. Le SCSI n'est plus bon qu'à gérer des librairies et des
lecteurs de bandes, en exagérant à peine.
Dans une baie professionnelle et si l'on veut de la perf, c'est le Fibre
Channel qui s'impose...
Si l'on veut de la capa pas chère c'était jusqu'à hier l'IDE et
aujourd'hui le SATA.
(Même pour les librairies et les lecteurs de cartouches, le marché est
aujourd'hui essentiellement Fibre Channel : IBM/HP LTO2 FC, StorageTek
9840/9940 FC, etc...)
Cordialement. Didier.
--
Pour répondre par mail, enlever NOSPAM- dans l'adresse.
To answer by mail, remove NOSPAM- in address.
A ce niveau, ne pense tu pas que le SCSI s'impose ?
Vu le prix, non. Le SCSI n'est plus bon qu'à gérer des librairies et des lecteurs de bandes, en exagérant à peine.
Dans une baie professionnelle et si l'on veut de la perf, c'est le Fibre Channel qui s'impose...
Si l'on veut de la capa pas chère c'était jusqu'à hier l'IDE et aujourd'hui le SATA.
(Même pour les librairies et les lecteurs de cartouches, le marché est aujourd'hui essentiellement Fibre Channel : IBM/HP LTO2 FC, StorageTek 9840/9940 FC, etc...)
Cordialement. Didier.
-- Pour répondre par mail, enlever NOSPAM- dans l'adresse. To answer by mail, remove NOSPAM- in address.
Emmanuel Florac
Dans article <3fa04210$0$5$, NOSPAM- disait...
Tu as oublié DataDirect Networks et StorageTek qui ont aussi des offres SATA ;-)
Oui, oui... :) en fait tous de façon générale.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3fa04210$0$5$afc38c87@news.easynet.fr>, NOSPAM-
didierg987@netcourrier.com disait...
Tu as oublié DataDirect Networks et StorageTek qui ont aussi des offres
SATA ;-)
Oui, oui... :) en fait tous de façon générale.
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Tu as oublié DataDirect Networks et StorageTek qui ont aussi des offres SATA ;-)
Oui, oui... :) en fait tous de façon générale.
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Didier G
Dans article <3fa02fa1$0$2799$, disait...
Sur une carte RAID 5 (3ware 7506), sous Linux, avec 8 disques 200 Go Maxtor (7200t/mn, 8Mo de cache), monté en 6+parité+hot spare, j'ai tiré 113Mo/s en lecture, 53 Mo /s en écriture, 23000 créations de fichiers par seconde (soit au minimum 69000 IO/s). Je n'ai pas tiré mieux d'un système RAID tout en Fibre Channel en double attachement (2 qla2200).
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu t'appercevras que la gestion disque de Linux est encore (très) loin d'être optimisée.
Sous Solaris, sur une baie full Fibre Channel bien configuré en RAID5 8+1, tu peux arriver à tirer 360 MB/s en read et 350 MB/s en write sur deux fibres avec un file system permettant le stripping afin d'utiliser pleinement le double attachement. Par contre, je n'ai pas noté de différence notable en fonction de la marque des HBA.
Bien sûr. En attendant, si tu veux 3 To de stockage avec une performance de 100 Mo/s je peux te le vendre pour moins de 10000 euros HT en ATA, avec le serveur qui va avec. Combien en SCSI, ou en FC? Plus du double. Aujourd'hui j'ai plusieurs systèmes de plusieurs téraoctets en ATA qui tournent; en 6 mois je n'ai du remplacer qu'un seul disque. Je n'ai pas remarqué de différence de fiabilité sensible, par contre j'ai remarqué la différence de coût :)
Les clients qui choisissent du SATA le font pour des applications bien précises exigeant de grosses capacités comme l'archivage, la sauvegarde sur disque, certaines applications scientifiques, etc. En revanche, ils continuent à privilégier le FC quand ils ont besoin de performances comme pour les bases de données, le transactionnel, les petits fichiers à accès aléatoire, etc...
Les constructeurs ne s'y sont pas trompé et ils ont à leurs catalogues les deux types de baie qui vont continuer cohabiter.
Cordialement. Didier.
-- Pour répondre par mail, enlever NOSPAM- dans l'adresse. To answer by mail, remove NOSPAM- in address.
Dans article <3fa02fa1$0$2799$626a54ce@news.free.fr>,
luiggi78AENLEVER@free.fr disait...
Sur une carte RAID 5 (3ware 7506), sous Linux, avec 8 disques 200 Go
Maxtor (7200t/mn, 8Mo de cache), monté en 6+parité+hot spare, j'ai tiré
113Mo/s en lecture, 53 Mo /s en écriture, 23000 créations de fichiers par
seconde (soit au minimum 69000 IO/s). Je n'ai pas tiré mieux d'un système
RAID tout en Fibre Channel en double attachement (2 qla2200).
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu
t'appercevras que la gestion disque de Linux est encore (très) loin
d'être optimisée.
Sous Solaris, sur une baie full Fibre Channel bien configuré en RAID5
8+1, tu peux arriver à tirer 360 MB/s en read et 350 MB/s en write sur
deux fibres avec un file system permettant le stripping afin d'utiliser
pleinement le double attachement. Par contre, je n'ai pas noté de
différence notable en fonction de la marque des HBA.
Bien sûr. En attendant, si tu veux 3 To de stockage avec une performance
de 100 Mo/s je peux te le vendre pour moins de 10000 euros HT en ATA,
avec le serveur qui va avec. Combien en SCSI, ou en FC? Plus du double.
Aujourd'hui j'ai plusieurs systèmes de plusieurs téraoctets en ATA qui
tournent; en 6 mois je n'ai du remplacer qu'un seul disque. Je n'ai pas
remarqué de différence de fiabilité sensible, par contre j'ai remarqué la
différence de coût :)
Les clients qui choisissent du SATA le font pour des applications bien
précises exigeant de grosses capacités comme l'archivage, la sauvegarde
sur disque, certaines applications scientifiques, etc. En revanche, ils
continuent à privilégier le FC quand ils ont besoin de performances
comme pour les bases de données, le transactionnel, les petits fichiers
à accès aléatoire, etc...
Les constructeurs ne s'y sont pas trompé et ils ont à leurs catalogues
les deux types de baie qui vont continuer cohabiter.
Cordialement. Didier.
--
Pour répondre par mail, enlever NOSPAM- dans l'adresse.
To answer by mail, remove NOSPAM- in address.
Sur une carte RAID 5 (3ware 7506), sous Linux, avec 8 disques 200 Go Maxtor (7200t/mn, 8Mo de cache), monté en 6+parité+hot spare, j'ai tiré 113Mo/s en lecture, 53 Mo /s en écriture, 23000 créations de fichiers par seconde (soit au minimum 69000 IO/s). Je n'ai pas tiré mieux d'un système RAID tout en Fibre Channel en double attachement (2 qla2200).
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu t'appercevras que la gestion disque de Linux est encore (très) loin d'être optimisée.
Sous Solaris, sur une baie full Fibre Channel bien configuré en RAID5 8+1, tu peux arriver à tirer 360 MB/s en read et 350 MB/s en write sur deux fibres avec un file system permettant le stripping afin d'utiliser pleinement le double attachement. Par contre, je n'ai pas noté de différence notable en fonction de la marque des HBA.
Bien sûr. En attendant, si tu veux 3 To de stockage avec une performance de 100 Mo/s je peux te le vendre pour moins de 10000 euros HT en ATA, avec le serveur qui va avec. Combien en SCSI, ou en FC? Plus du double. Aujourd'hui j'ai plusieurs systèmes de plusieurs téraoctets en ATA qui tournent; en 6 mois je n'ai du remplacer qu'un seul disque. Je n'ai pas remarqué de différence de fiabilité sensible, par contre j'ai remarqué la différence de coût :)
Les clients qui choisissent du SATA le font pour des applications bien précises exigeant de grosses capacités comme l'archivage, la sauvegarde sur disque, certaines applications scientifiques, etc. En revanche, ils continuent à privilégier le FC quand ils ont besoin de performances comme pour les bases de données, le transactionnel, les petits fichiers à accès aléatoire, etc...
Les constructeurs ne s'y sont pas trompé et ils ont à leurs catalogues les deux types de baie qui vont continuer cohabiter.
Cordialement. Didier.
-- Pour répondre par mail, enlever NOSPAM- dans l'adresse. To answer by mail, remove NOSPAM- in address.
rene-marc
Didier G :
Dans une baie professionnelle et si l'on veut de la perf, c'est le Fibre Channel qui s'impose...
Quelle pourcentage de baies installées sont vraiment utilisées au max de leurs perfs ? Assez peu, et souvent, parce que elles sont tellement cheres que les clients (ou les fournisseurs) limitent les configs.
Je suis sur que la grande majorité des baies que j'ai vu en clientele pourraient etre en SATA sans impact de perfs pour les clients.
Didier G <NOSPAM-didierg987@netcourrier.com> :
Dans une baie professionnelle et si l'on veut de la perf, c'est le Fibre
Channel qui s'impose...
Quelle pourcentage de baies installées sont vraiment utilisées au max de
leurs perfs ? Assez peu, et souvent, parce que elles sont tellement
cheres que les clients (ou les fournisseurs) limitent les configs.
Je suis sur que la grande majorité des baies que j'ai vu en clientele
pourraient etre en SATA sans impact de perfs pour les clients.
Dans une baie professionnelle et si l'on veut de la perf, c'est le Fibre Channel qui s'impose...
Quelle pourcentage de baies installées sont vraiment utilisées au max de leurs perfs ? Assez peu, et souvent, parce que elles sont tellement cheres que les clients (ou les fournisseurs) limitent les configs.
Je suis sur que la grande majorité des baies que j'ai vu en clientele pourraient etre en SATA sans impact de perfs pour les clients.
Emmanuel Florac
Dans article <3fa04b25$0$29494$, NOSPAM- disait...
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu t'appercevras que la gestion disque de Linux est encore (très) loin d'être optimisée.
En effet. Néammoins avec un noyau 2.6, ou en tweakant le module qla2x00.o sur le 2.4, on améliore beaucoup. Et j'ai suivi des tests avec de grosses baies FC ou un Sun 64 procs se faisait salement allumer par une bécane 4 procs linux : les bus PCI des Sun ne valent pas un clou.
Sous Solaris, sur une baie full Fibre Channel bien configuré en RAID5 8+1, tu peux arriver à tirer 360 MB/s en read et 350 MB/s en write sur deux fibres
Avec deux fibres 2Giga! Moi je te parle de deux fibres 1 Giga... J'ai tiré 180 Mo/s ce qui est cohérent avec ce que tu décris. Mais pour 10 fois le prix...
Les clients qui choisissent du SATA le font pour des applications bien précises exigeant de grosses capacités comme l'archivage, la sauvegarde sur disque, certaines applications scientifiques, etc. En revanche, ils continuent à privilégier le FC quand ils ont besoin de performances comme pour les bases de données, le transactionnel, les petits fichiers à accès aléatoire, etc...
Oui oui. Bien entendu. Mais toutes les applications autres que le transactionnel (serveur de fichiers, etc)...
Les constructeurs ne s'y sont pas trompé et ils ont à leurs catalogues les deux types de baie qui vont continuer cohabiter.
Bien sûr. Mais il faut regarder ce que seront les ventes!
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3fa04b25$0$29494$afc38c87@news.easynet.fr>, NOSPAM-
didierg987@netcourrier.com disait...
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu
t'appercevras que la gestion disque de Linux est encore (très) loin
d'être optimisée.
En effet. Néammoins avec un noyau 2.6, ou en tweakant le module qla2x00.o
sur le 2.4, on améliore beaucoup. Et j'ai suivi des tests avec de grosses
baies FC ou un Sun 64 procs se faisait salement allumer par une bécane 4
procs linux : les bus PCI des Sun ne valent pas un clou.
Sous Solaris, sur une baie full Fibre Channel bien configuré en RAID5
8+1, tu peux arriver à tirer 360 MB/s en read et 350 MB/s en write sur
deux fibres
Avec deux fibres 2Giga! Moi je te parle de deux fibres 1 Giga... J'ai
tiré 180 Mo/s ce qui est cohérent avec ce que tu décris. Mais pour 10
fois le prix...
Les clients qui choisissent du SATA le font pour des applications bien
précises exigeant de grosses capacités comme l'archivage, la sauvegarde
sur disque, certaines applications scientifiques, etc. En revanche, ils
continuent à privilégier le FC quand ils ont besoin de performances
comme pour les bases de données, le transactionnel, les petits fichiers
à accès aléatoire, etc...
Oui oui. Bien entendu. Mais toutes les applications autres que le
transactionnel (serveur de fichiers, etc)...
Les constructeurs ne s'y sont pas trompé et ils ont à leurs catalogues
les deux types de baie qui vont continuer cohabiter.
Bien sûr. Mais il faut regarder ce que seront les ventes!
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <3fa04b25$0$29494$, NOSPAM- disait...
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu t'appercevras que la gestion disque de Linux est encore (très) loin d'être optimisée.
En effet. Néammoins avec un noyau 2.6, ou en tweakant le module qla2x00.o sur le 2.4, on améliore beaucoup. Et j'ai suivi des tests avec de grosses baies FC ou un Sun 64 procs se faisait salement allumer par une bécane 4 procs linux : les bus PCI des Sun ne valent pas un clou.
Sous Solaris, sur une baie full Fibre Channel bien configuré en RAID5 8+1, tu peux arriver à tirer 360 MB/s en read et 350 MB/s en write sur deux fibres
Avec deux fibres 2Giga! Moi je te parle de deux fibres 1 Giga... J'ai tiré 180 Mo/s ce qui est cohérent avec ce que tu décris. Mais pour 10 fois le prix...
Les clients qui choisissent du SATA le font pour des applications bien précises exigeant de grosses capacités comme l'archivage, la sauvegarde sur disque, certaines applications scientifiques, etc. En revanche, ils continuent à privilégier le FC quand ils ont besoin de performances comme pour les bases de données, le transactionnel, les petits fichiers à accès aléatoire, etc...
Oui oui. Bien entendu. Mais toutes les applications autres que le transactionnel (serveur de fichiers, etc)...
Les constructeurs ne s'y sont pas trompé et ils ont à leurs catalogues les deux types de baie qui vont continuer cohabiter.
Bien sûr. Mais il faut regarder ce que seront les ventes!
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Emmanuel Florac
Dans article , disait...
Quelle pourcentage de baies installées sont vraiment utilisées au max de leurs perfs ? Assez peu, et souvent, parce que elles sont tellement cheres que les clients (ou les fournisseurs) limitent les configs.
Au contraire... Vu la vitesse à laquelle une baie perd sa valeur, il ne doit pas y avoir grand'monde qui ne l'utilise pas aux limites.
Je suis sur que la grande majorité des baies que j'ai vu en clientele pourraient etre en SATA sans impact de perfs pour les clients.
Sauf que le SATA n'est pas adapté pour les baies... On ne peut pas faire passer toutes les commandes dont on a besoin dessus!
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Dans article <slrnbq1ikk.2e3u.rmd@rmd.hosted.firstream.net>,
rmd@mecreant.org disait...
Quelle pourcentage de baies installées sont vraiment utilisées au max de
leurs perfs ? Assez peu, et souvent, parce que elles sont tellement
cheres que les clients (ou les fournisseurs) limitent les configs.
Au contraire... Vu la vitesse à laquelle une baie perd sa valeur, il ne
doit pas y avoir grand'monde qui ne l'utilise pas aux limites.
Je suis sur que la grande majorité des baies que j'ai vu en clientele
pourraient etre en SATA sans impact de perfs pour les clients.
Sauf que le SATA n'est pas adapté pour les baies... On ne peut pas faire
passer toutes les commandes dont on a besoin dessus!
--
Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Quelle pourcentage de baies installées sont vraiment utilisées au max de leurs perfs ? Assez peu, et souvent, parce que elles sont tellement cheres que les clients (ou les fournisseurs) limitent les configs.
Au contraire... Vu la vitesse à laquelle une baie perd sa valeur, il ne doit pas y avoir grand'monde qui ne l'utilise pas aux limites.
Je suis sur que la grande majorité des baies que j'ai vu en clientele pourraient etre en SATA sans impact de perfs pour les clients.
Sauf que le SATA n'est pas adapté pour les baies... On ne peut pas faire passer toutes les commandes dont on a besoin dessus!
-- Quis, quid, ubi, quibus auxiliis, cur, quomodo, quando?
Francois Petillon
On Wed, 29 Oct 2003 18:41:26 +0000, boulu wrote:
rene-marc s'est donné la peine d'écrire:
Si, pour cabler un raid 12 disques, c'est plus pratique :) A ce niveau, ne pense tu pas que le SCSI s'impose ?
Cela dépend essentiellement du type d'accès. S'il y a beaucoup de requetes aléatoires sur de petits blocs de données, alors oui, le SCSI sera plus interessant (faudra en reparler avec les prochaines normes ATA où il sera possible d'envoyer plusieurs commandes aux périphériques). S'il s'agit de lectures séquentielles ("environement mono-tache") ou de requetes aléatoires sur des blocs de données conséquents, alors la différence de performances sera négligeable.
François
On Wed, 29 Oct 2003 18:41:26 +0000, boulu wrote:
rene-marc <rmd@mecreant.org> s'est donné la peine d'écrire:
Si, pour cabler un raid 12 disques, c'est plus pratique :)
A ce niveau, ne pense tu pas que le SCSI s'impose ?
Cela dépend essentiellement du type d'accès. S'il y a beaucoup de
requetes aléatoires sur de petits blocs de données, alors oui, le SCSI
sera plus interessant (faudra en reparler avec les prochaines normes ATA
où il sera possible d'envoyer plusieurs commandes aux périphériques).
S'il s'agit de lectures séquentielles ("environement mono-tache") ou de
requetes aléatoires sur des blocs de données conséquents, alors la
différence de performances sera négligeable.
Si, pour cabler un raid 12 disques, c'est plus pratique :) A ce niveau, ne pense tu pas que le SCSI s'impose ?
Cela dépend essentiellement du type d'accès. S'il y a beaucoup de requetes aléatoires sur de petits blocs de données, alors oui, le SCSI sera plus interessant (faudra en reparler avec les prochaines normes ATA où il sera possible d'envoyer plusieurs commandes aux périphériques). S'il s'agit de lectures séquentielles ("environement mono-tache") ou de requetes aléatoires sur des blocs de données conséquents, alors la différence de performances sera négligeable.
François
Francois Petillon
On Wed, 29 Oct 2003 23:39:53 +0100, Emmanuel Florac wrote:
Sur une carte RAID 5 (3ware 7506), sous Linux, avec 8 disques 200 Go Maxtor (7200t/mn, 8Mo de cache), monté en 6+parité+hot spare, j'ai tiré 113Mo/s en lecture, 53 Mo /s en écriture, 23000 créations de fichiers par seconde (soit au minimum 69000 IO/s). Je n'ai pas tiré mieux d'un système RAID tout en Fibre Channel en double attachement (2 qla2200).
Bof, je crois qu'on en a discuté sur le forum Stockage. De tels specs correspondent à un environement monotache (peu de clients simultannés) sur des lectures séquentielles.
Aujourd'hui j'ai plusieurs systèmes de plusieurs téraoctets en ATA qui tournent; en 6 mois je n'ai du remplacer qu'un seul disque. Je n'ai pas remarqué de différence de fiabilité sensible, par contre j'ai remarqué la différence de coût :)
Pour ma part, j'ai observé 10% de pertes sur les disques mais uniquement sur les deux permières semaines. Plus de pertes par la suite.
François
On Wed, 29 Oct 2003 23:39:53 +0100, Emmanuel Florac wrote:
Sur une carte RAID 5 (3ware 7506), sous Linux, avec 8 disques 200 Go
Maxtor (7200t/mn, 8Mo de cache), monté en 6+parité+hot spare, j'ai tiré
113Mo/s en lecture, 53 Mo /s en écriture, 23000 créations de fichiers par
seconde (soit au minimum 69000 IO/s). Je n'ai pas tiré mieux d'un système
RAID tout en Fibre Channel en double attachement (2 qla2200).
Bof, je crois qu'on en a discuté sur le forum Stockage. De tels specs
correspondent à un environement monotache (peu de clients simultannés)
sur des lectures séquentielles.
Aujourd'hui j'ai plusieurs systèmes de plusieurs téraoctets
en ATA qui tournent; en 6 mois je n'ai du remplacer qu'un seul disque.
Je n'ai pas remarqué de différence de fiabilité sensible, par contre
j'ai remarqué la différence de coût :)
Pour ma part, j'ai observé 10% de pertes sur les disques mais uniquement
sur les deux permières semaines. Plus de pertes par la suite.
On Wed, 29 Oct 2003 23:39:53 +0100, Emmanuel Florac wrote:
Sur une carte RAID 5 (3ware 7506), sous Linux, avec 8 disques 200 Go Maxtor (7200t/mn, 8Mo de cache), monté en 6+parité+hot spare, j'ai tiré 113Mo/s en lecture, 53 Mo /s en écriture, 23000 créations de fichiers par seconde (soit au minimum 69000 IO/s). Je n'ai pas tiré mieux d'un système RAID tout en Fibre Channel en double attachement (2 qla2200).
Bof, je crois qu'on en a discuté sur le forum Stockage. De tels specs correspondent à un environement monotache (peu de clients simultannés) sur des lectures séquentielles.
Aujourd'hui j'ai plusieurs systèmes de plusieurs téraoctets en ATA qui tournent; en 6 mois je n'ai du remplacer qu'un seul disque. Je n'ai pas remarqué de différence de fiabilité sensible, par contre j'ai remarqué la différence de coût :)
Pour ma part, j'ai observé 10% de pertes sur les disques mais uniquement sur les deux permières semaines. Plus de pertes par la suite.
François
Francois Petillon
On Thu, 30 Oct 2003 00:20:04 +0100, Didier G wrote:
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu t'appercevras que la gestion disque de Linux est encore (très) loin d'être optimisée.
À mon humble avis, il est excessivement difficile d'avoir une politique d'accès disque optimale dans tous les cas de configuration. J'ai fait des tests il y a quelques temps sur les spoolers de news de Free (historiquement, il s'agissait de serveurs Raidzone qu'on a jamais pu faire fonctionner correctement que j'ai "reconditioné" en mettant des cartes 3Ware à la place, le profil est un Mhz, RAM 512 Mo, 2 cartes 3Ware pour 14 disques Maxtor 40 Go 5400rpm, bref, pas des betes de courses à tout niveau).
Sur une configuration en RAID5 avec des accès via mmap(avec un madvise en MADV_SEQUENTIAL), les serveurs pouvaient sortir environ 90 Mbps. En changeant les madvises en MADV_WILLNEED on passe à 165 Mbps (le facteur limitatif concerne la taille des blocs de 64Ko dûe au RAID5 des cartes 3Ware alors que l'article moyen fait 300 Ko dans les alt.binaries). En explosant le RAID (pour éviter le probleme des blocs plus petit que la taille des articles à récuperer), je suis passé à 250 Mbps (là, c'est les frontaux qui saturent et je ne suis pas loin de la saturation au niveau CPU).
Là, en utilisant madvise, j'ai pu forcer le kernel à charger en "une passe" l'ensemble des données que j'allais utiliser mais ce type d'accès est assez éloigné de ce qu'on pourrait attendre d'un serveur standard.
François
On Thu, 30 Oct 2003 00:20:04 +0100, Didier G wrote:
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu
t'appercevras que la gestion disque de Linux est encore (très) loin
d'être optimisée.
À mon humble avis, il est excessivement difficile d'avoir une politique
d'accès disque optimale dans tous les cas de configuration. J'ai fait
des tests il y a quelques temps sur les spoolers de news de Free
(historiquement, il s'agissait de serveurs Raidzone qu'on a jamais pu
faire fonctionner correctement que j'ai "reconditioné" en mettant des
cartes 3Ware à la place, le profil est un bi-p3@800 Mhz, RAM 512 Mo,
2 cartes 3Ware pour 14 disques Maxtor 40 Go 5400rpm, bref, pas des betes
de courses à tout niveau).
Sur une configuration en RAID5 avec des accès via mmap(avec un madvise en
MADV_SEQUENTIAL), les serveurs pouvaient sortir environ 90 Mbps. En
changeant les madvises en MADV_WILLNEED on passe à 165 Mbps (le facteur
limitatif concerne la taille des blocs de 64Ko dûe au RAID5 des cartes
3Ware alors que l'article moyen fait 300 Ko dans les alt.binaries). En
explosant le RAID (pour éviter le probleme des blocs plus petit que la
taille des articles à récuperer), je suis passé à 250 Mbps (là, c'est
les frontaux qui saturent et je ne suis pas loin de la saturation au
niveau CPU).
Là, en utilisant madvise, j'ai pu forcer le kernel à charger en "une
passe" l'ensemble des données que j'allais utiliser mais ce type d'accès
est assez éloigné de ce qu'on pourrait attendre d'un serveur standard.
On Thu, 30 Oct 2003 00:20:04 +0100, Didier G wrote:
Si tu fais des tests de la même baie sous Linux et sous Solaris, tu t'appercevras que la gestion disque de Linux est encore (très) loin d'être optimisée.
À mon humble avis, il est excessivement difficile d'avoir une politique d'accès disque optimale dans tous les cas de configuration. J'ai fait des tests il y a quelques temps sur les spoolers de news de Free (historiquement, il s'agissait de serveurs Raidzone qu'on a jamais pu faire fonctionner correctement que j'ai "reconditioné" en mettant des cartes 3Ware à la place, le profil est un Mhz, RAM 512 Mo, 2 cartes 3Ware pour 14 disques Maxtor 40 Go 5400rpm, bref, pas des betes de courses à tout niveau).
Sur une configuration en RAID5 avec des accès via mmap(avec un madvise en MADV_SEQUENTIAL), les serveurs pouvaient sortir environ 90 Mbps. En changeant les madvises en MADV_WILLNEED on passe à 165 Mbps (le facteur limitatif concerne la taille des blocs de 64Ko dûe au RAID5 des cartes 3Ware alors que l'article moyen fait 300 Ko dans les alt.binaries). En explosant le RAID (pour éviter le probleme des blocs plus petit que la taille des articles à récuperer), je suis passé à 250 Mbps (là, c'est les frontaux qui saturent et je ne suis pas loin de la saturation au niveau CPU).
Là, en utilisant madvise, j'ai pu forcer le kernel à charger en "une passe" l'ensemble des données que j'allais utiliser mais ce type d'accès est assez éloigné de ce qu'on pourrait attendre d'un serveur standard.
François
Didier G
Les clients qui choisissent du SATA le font pour des applications bien précises exigeant de grosses capacités comme l'archivage, la sauvegarde sur disque, certaines applications scientifiques, etc. En revanche, ils continuent à privilégier le FC quand ils ont besoin de performances comme pour les bases de données, le transactionnel, les petits fichiers à accès aléatoire, etc...
Oui oui. Bien entendu. Mais toutes les applications autres que le transactionnel (serveur de fichiers, etc)...
C'est là que l'on passe au sujet à la mode dans notre petit "storage world" : ILM - Information Lifecycle Management.
C'est vrai que toutes les données n'ont pas toujours besoin d'être accédées dans un temps record et c'est vrai que le besoin de perf évolue en fonction de l'âge de ces données. On devrait donc évoluer vers des configurations incluant plusieurs types de média : FC, SATA (et cartouches pour les plus grosses configurations) et un logiciel HSM pour migrer les données d'un média performant vers un média plus économique quand celles-ci vieillissent.
Jusqu'à présent, quelque soit l'HSM utilisé SAM/FS, Storage Migrator, HPSS, etc... celui-ci utilisait généralement deux niveaux de stockage : disques et cartouches.
Aujourd'hui, vu les volumes à gérer et le coût des nouveaux systèmes disques basés sur de l'IDE ou du SATA (coût au TB pour de grosses configurations qui se rapproche du coût sur cartouche automatisée performante), on voit (quelques) sites en passe d'évoluer à l'horizon 2004/2005 vers des architectures à trois voir quatre niveaux avec des SLA différents en fonctions du type de données et de l'âge de celles-ci.
Mais dans toutes les architectures envisagées, le SATA ne vient qu'en deuxième niveau derrière le FC qui reste(ra) le plus performant pour le premier niveau.
Cordialement. Didier.
-- Pour répondre par mail, enlever NOSPAM- dans l'adresse. To answer by mail, remove NOSPAM- in address.
Les clients qui choisissent du SATA le font pour des applications bien
précises exigeant de grosses capacités comme l'archivage, la sauvegarde
sur disque, certaines applications scientifiques, etc. En revanche, ils
continuent à privilégier le FC quand ils ont besoin de performances
comme pour les bases de données, le transactionnel, les petits fichiers
à accès aléatoire, etc...
Oui oui. Bien entendu. Mais toutes les applications autres que le
transactionnel (serveur de fichiers, etc)...
C'est là que l'on passe au sujet à la mode dans notre petit "storage
world" : ILM - Information Lifecycle Management.
C'est vrai que toutes les données n'ont pas toujours besoin d'être
accédées dans un temps record et c'est vrai que le besoin de perf évolue
en fonction de l'âge de ces données. On devrait donc évoluer vers des
configurations incluant plusieurs types de média : FC, SATA (et
cartouches pour les plus grosses configurations) et un logiciel HSM pour
migrer les données d'un média performant vers un média plus économique
quand celles-ci vieillissent.
Jusqu'à présent, quelque soit l'HSM utilisé SAM/FS, Storage Migrator,
HPSS, etc... celui-ci utilisait généralement deux niveaux de stockage :
disques et cartouches.
Aujourd'hui, vu les volumes à gérer et le coût des nouveaux systèmes
disques basés sur de l'IDE ou du SATA (coût au TB pour de grosses
configurations qui se rapproche du coût sur cartouche automatisée
performante), on voit (quelques) sites en passe d'évoluer à l'horizon
2004/2005 vers des architectures à trois voir quatre niveaux avec des
SLA différents en fonctions du type de données et de l'âge de celles-ci.
Mais dans toutes les architectures envisagées, le SATA ne vient qu'en
deuxième niveau derrière le FC qui reste(ra) le plus performant pour le
premier niveau.
Cordialement. Didier.
--
Pour répondre par mail, enlever NOSPAM- dans l'adresse.
To answer by mail, remove NOSPAM- in address.
Les clients qui choisissent du SATA le font pour des applications bien précises exigeant de grosses capacités comme l'archivage, la sauvegarde sur disque, certaines applications scientifiques, etc. En revanche, ils continuent à privilégier le FC quand ils ont besoin de performances comme pour les bases de données, le transactionnel, les petits fichiers à accès aléatoire, etc...
Oui oui. Bien entendu. Mais toutes les applications autres que le transactionnel (serveur de fichiers, etc)...
C'est là que l'on passe au sujet à la mode dans notre petit "storage world" : ILM - Information Lifecycle Management.
C'est vrai que toutes les données n'ont pas toujours besoin d'être accédées dans un temps record et c'est vrai que le besoin de perf évolue en fonction de l'âge de ces données. On devrait donc évoluer vers des configurations incluant plusieurs types de média : FC, SATA (et cartouches pour les plus grosses configurations) et un logiciel HSM pour migrer les données d'un média performant vers un média plus économique quand celles-ci vieillissent.
Jusqu'à présent, quelque soit l'HSM utilisé SAM/FS, Storage Migrator, HPSS, etc... celui-ci utilisait généralement deux niveaux de stockage : disques et cartouches.
Aujourd'hui, vu les volumes à gérer et le coût des nouveaux systèmes disques basés sur de l'IDE ou du SATA (coût au TB pour de grosses configurations qui se rapproche du coût sur cartouche automatisée performante), on voit (quelques) sites en passe d'évoluer à l'horizon 2004/2005 vers des architectures à trois voir quatre niveaux avec des SLA différents en fonctions du type de données et de l'âge de celles-ci.
Mais dans toutes les architectures envisagées, le SATA ne vient qu'en deuxième niveau derrière le FC qui reste(ra) le plus performant pour le premier niveau.
Cordialement. Didier.
-- Pour répondre par mail, enlever NOSPAM- dans l'adresse. To answer by mail, remove NOSPAM- in address.
