Les différentes "couches" de la gestion du stockage

tiramiseb · Le 14/11/2013, à 23:40

Note également que 1Gb/s ça représente 128 Mo par seconde.

Est-ce que tu vas vraiment profiter d'un tel lien ? Quel type de fichier envisages-tu de transférer ?

Sur un lien à 1 Gb :
- une photo en RAW (25 Mo) est transférée en moins d'une demie-seconde : ça pose problème si ça prend une seconde ?
- une vidéo classique en DivX (700 Mo) est transférée en moins de 6 secondes : ça pose un problème si ça prend 10 secondes ?
- un DVD classique (4,7 Go) est transféré en moins de 40 secondes : ça pose un problème si ça prend 1 minute ?

Tu seras facilement dans un cas où la latence sera plus un problème que le débit... et le RAID n'améliore pas la latence, je pense même que ça l'augmente.

tiramiseb · Le 14/11/2013, à 23:43

Et tu n'as pas :
- soit un PC fixe dans un coin ?
- soit un port eSATA sur ton PC ?

cubytus · Le 14/11/2013, à 23:48

Il y a bien un port eSATA sur le PC, mais étant donné qu'il n'a jamais été entièrement compatible Linux et qu'il date de 2009, pas sûr que ce ne soit pas lui le goulot d'étranglement. Ça demande vérification par contre. Sinon il n'y a rien "dans les coins" chez moi. Le moins de bordel, le plus simple de déménager.

Un lien rapide pour ne pas avoir à planifier ses transferts de fichiers lourds et de streaming vidéo. Avec l'installation actuelle, ça hache le débit sur le HD, et impossible de ne pas transférer d'abord en local, ce que je cherche aussi à éviter avec ce NAS.

cubytus · Le 17/11/2013, à 03:28

Alors après test rapide en eSATA, le débit est insuffisant pour saturer le port gigabit:

/dev/sdc:
 Timing cached reads:   1452 MB in  2.00 seconds = 726.04 MB/sec
 Timing buffered disk reads: 178 MB in  3.03 seconds =  58.71 MB/sec

Un disque plus récent, le TM:

/dev/sdc:
 Timing cached reads:   2288 MB in  2.00 seconds = 1144.36 MB/sec
 Timing buffered disk reads: 372 MB in  3.00 seconds = 123.85 MB/sec

Ça montre bien la nécessité de mettre en RAID0 au moins les disques plus âgés, même si la bonne nouvelle est qu'il semble au moins fonctionner correctement dans cette machine.

tiramiseb · Le 17/11/2013, à 18:55

Ça montre que le disque ne sature pas un lien gigabit. Mais ça ne montre pas de nécessité particulière.

Concernant la nécessité, il faut voir si ton besoin est vraiment de ce niveau-là.

Quel serait le besoin le plus gourmand ?

cubytus · Le 17/11/2013, à 19:17

La nécessité est indiquée dans le premier post. Il s'agit de streaming de films HD, pour le moment, sans compromettre le transfert d'autres fichiers en arrière-plan.

Je suppose que c'est le lot d'anciens disques SATA, si des modèles plus récents peuvent le saturer sans peine.

Donc quelle organisation tenant compte de cette limitation fonctionnerait?

tiramiseb · Le 17/11/2013, à 23:25

La nécessité est indiquée dans le premier post. Il s'agit de streaming de films HD

Euh non désolé, ce n'est pas dans le premier post...
Tu as brièvement évoqué que « ça hache le débit sur le HD », sans donner plus de précisions, dans le post #28... sans même donner de détails sur ton "installation actuelle". Et ça reste vague, "HD" ça peut vouloir dire tout et n'importe quoi (quelle fréquence d'images ? quelle profondeur de couleurs ? quel codec vidéo ? quelle compression ?)

Par exemple, si en écrivant "HD" tu évoques des vidéos au format Blu-Ray, alors le débit maximal est de 36 Mbits/s (cf http://fr.wikipedia.org/wiki/Disque_Blu … lications)... Dans ce cas, le facteur limitant n'est pas le disque dur, étant donné que ton disque « moins récent » que tu as testé sur ton port eSATA prouve qu'il sait faire du 470 Mbits/s (58,71 Mo/s × 8) ; s'il était le seul facteur limitant, tu pourrais alors lire 10 flux "Blu-Ray" simultanément sans aucune saccade.

C'est pourquoi j'ai besoin de plus de précisions... Car il est tout à fait possible que tu sois en train de te concentrer sur un point particulier (le débit des disques durs), pensant que c'est le nœud de ton problème, alors que ton problème viendrait complètement d'ailleurs.

Dernière modification par tiramiseb (Le 17/11/2013, à 23:27)

cubytus · Le 17/11/2013, à 23:41

Ça fait une raison suffisante me semble. Le but et la nécessité est de saturer le port gigabit. D'après tests, 2 disques sur le lot ne le peuvent pas, donc il faut les associer en RAID0, ni plus ni moins. L'installation actuelle en tant que telle est inexistante, vu que je ne compte pas une interface SATA-USB comme une "installation". C'est largement assez précis pour le but de ce topic. Le contenu est là, et savoir ce qu'il y a dedans ne fera pas avancer le schmilblick étant donné qu'il ne changera pas.

Le but est d'obtenir une installation qui réponde aux critères, pas de pinailler sur ce qui ne changera pas.

tiramiseb · Le 18/11/2013, à 09:41

Eh bien tu as largement assez d'informations sur les possibilités en terme de RAID et de LVM, que veux-tu savoir de plus alors ?

Le but et la nécessité est de saturer le port gigabit.

Critère très inhabituel, dira-t-on... Car il y a tellement d'autres choses qui peuvent ralentir tes transferts...

cubytus · Le 18/11/2013, à 13:17

tiramiseb a écrit :

Eh bien tu as largement assez d'informations sur les possibilités en terme de RAID et de LVM, que veux-tu savoir de plus alors ?
Critère très inhabituel, dira-t-on... Car il y a tellement d'autres choses qui peuvent ralentir tes transferts...

Je cherche à savoir dans quel ordre le faire. Pour le moment, ce seraient 2 disques non formatés, en RAID, puis dans un LV crypté/chiffré, mais ce n'est toujours pas clair. Sinon c'est un critère comme un autre. Le cryptage peut limiter le transfert effectif, et c'est mon souci pour le moment, sachant que même un disque plus récent est à peine au-dessus de la limite du gigabit.

tiramiseb · Le 18/11/2013, à 13:20

Je pense que selon ton besoin, c'est ce que j'ai décrit en #20 qui conviendrait ; il semble que c'est ce que tu décris là (sauf que pour le chiffrement on ne parle pas de LV, vu qu'il n'y a pas de couche LVM).

Le cryptage peut limiter le transfert effectif

Oui, le chiffrement peut constituer un point de blocage ; j'imagine que pour déchiffrer 128 Mo de données par seconde (1Gb/s), il faut un processeur véloce. Mais je ne saurais te donner aucune info précise, ce n'est pas mon domaine de prédilection.

tiramiseb · Le 18/11/2013, à 13:25

La page suivante peut t'être utile :
http://askubuntu.com/questions/187874/h … erformance

cubytus · Le 07/12/2013, à 05:18

C'est assez intéressant en effet, et guide pour le choix du hardware à construire pour faire ce NAS. Il faudrait aller sur un CPU série A4, A6, A8, A10 de AMD, puisque ce sont apparemment les moins coûteux. Toutefois la compatibilité ne donne pas le débit de décryptage / écriture assisté matériellement, mais qui selon cette page est au-dessus de la vitesse de disques rotatifs de toute manière. J'en comprends que ce ne serait pas le CPU qui limiterait.

La grappe RAID0 serait effectivement construite comme le second schéma du #20 (de toute façon si j'ajoute un disque dans cette grappe, ce qui paraît improbable pour le moment, ce sera le système RAID qui se chargera de l'initialiser et calculer l'espace disponible). Les autres disques externes seraient pris en charge par un LVM, qui présenterait côté utilisateur un unique disque virtuel dont la taille changerait dynamiquement en fonction de quel disque est ajouté. Les disques externes USB seraient regroupés ensemble en fonction de leur faible vitesse de transfert, qui ne peut évidemment pas saturer le Gigabit. Pas de RAID pour ceux-là, même si cela était possible.

Ça donnerait:
DD Orange + DD Bleu = RAID0, un seul volume 500Gio présenté, le plus rapide;
DD Vert + A500 (avec adaptateur PATA-SATA) = RAID0, un seul volume 1Tio présenté, le plus rapide.
Ces deux volumes de la même vitesse (en théorie) seraient regroupés sous LVM en un seul volume de 1,5Tio capable de saturer le gigabit. Ajout possible de plus gros disques hors grappe RAID, mais dans le même volume. La différence de vitesse ne devrait pas être limitante selon les tests du #29, donc que les données tombent aléatoirement sur n'importe laquelle des grappes ne devrait pas affecter la performance attendue.

TM seul = 1,5Tio. Je veux pouvoir débrancher celui-là rapidement si besoin est et être capable de le remettre dans un boîtier convenable.
T750 seul (oui, j'ai changé d'avis car il est plus simple de le garder séparé le temps de la garantie sur la machine, car pas de service de réparation fourni si le souci est lié au disque dur non original). Ça fait trois volumes, ce qui est tout à fait raisonnable. Leur taille n'est pas impressionnante, mais suffisante pour démarrer.

Il reste à construire le hardware qui respecte des contraintes données. Dans un autre topic?

tiramiseb · Le 07/12/2013, à 10:16

Il reste à construire le hardware qui respecte des contraintes données.

Je ne pense pas que c'est très compliqué...

Si tu veux utiliser l'accélération AES du processeur, il suffit d'en prendre un listé ici : http://en.wikipedia.org/wiki/AES_instruction_set (page que tu as déjà lue, si j'ai bien compris).

Pour la mémoire, moi je mettrais 4 Go, ça devrait être amplement suffisant.

Je te conseille aussi de prendre une carte réseau plutôt haut de gamme : j'ai déjà vu des cartes bas de gamme bouffer complètement le CPU quand on sature le réseau...

Dans un autre topic?

Si vraiment tu veux une réponse pointue, il vaut mieux, oui.

cubytus · Le 08/12/2013, à 01:31

Puisque ce n'est pas compliqué, j'ai mis ça dans cet autre topic.

Ubuntu-fr

Navigation

Liens de recherche

Annonce

#26 Le 14/11/2013, à 23:40

Re : Les différentes "couches" de la gestion du stockage

#27 Le 14/11/2013, à 23:43

Re : Les différentes "couches" de la gestion du stockage

#28 Le 14/11/2013, à 23:48

Re : Les différentes "couches" de la gestion du stockage

#29 Le 17/11/2013, à 03:28

Re : Les différentes "couches" de la gestion du stockage

#30 Le 17/11/2013, à 18:55

Re : Les différentes "couches" de la gestion du stockage

#31 Le 17/11/2013, à 19:17

Re : Les différentes "couches" de la gestion du stockage

#32 Le 17/11/2013, à 23:25

Re : Les différentes "couches" de la gestion du stockage

#33 Le 17/11/2013, à 23:41

Re : Les différentes "couches" de la gestion du stockage

#34 Le 18/11/2013, à 09:41

Re : Les différentes "couches" de la gestion du stockage

#35 Le 18/11/2013, à 13:17

Re : Les différentes "couches" de la gestion du stockage

#36 Le 18/11/2013, à 13:20

Re : Les différentes "couches" de la gestion du stockage

#37 Le 18/11/2013, à 13:25

Re : Les différentes "couches" de la gestion du stockage

#38 Le 07/12/2013, à 05:18

Re : Les différentes "couches" de la gestion du stockage

#39 Le 07/12/2013, à 10:16

Re : Les différentes "couches" de la gestion du stockage

#40 Le 08/12/2013, à 01:31

Re : Les différentes "couches" de la gestion du stockage

Pied de page des forums