[gull] NAS a la maison - Open Media Vault ?

Sun Nov 11 11:09:22 CET 2018

Hello,

Le hardware pose deux questions :

- Consommation d'énergie pendant l'utilisation.

- Énergie grise contenu dans du matériel.

Si on veut choisir un matériel "responsable" avec une faible empreinte
environnementale, je vois plusieurs choix (tout dépend de l'usage et des
besoins) :

- J'avais monté un OMV sur un Banana-pi. C'est un Raspberry-pi qui
dispose d'un port esata, bien mieux géré que du USB2, notamment pour la
montée en charge. Sur le Banana-pi, j'ai un disque 2.5'' de 1To, mais on
peut potentiellement mettre des disques plus gros. L'avantage, c'est
l'empreinte environnementale ET la consommation (j'ai dû tout de même
mettre une alimentation 3.5A/5V, l'habituelle 1A/5V n'était pas
suffisante pour alimenter le pi et le disque).

- On peut monter un NAS avec OMV sur un desktop d'occasion revalorisé.
La plupart proposent deux slots SATA (pour du RAID). Et les desktops
d'occasion de gamme pro n'ont pas des processeurs de fou qui consomment
trop, mais ça reste un desktop qui consomme bien plus qu'un PI. Au
niveau de l'énergie grise, c'est excellent, parce que dans le cycle de
vie d'un ordinateur, c'est la fabrication qui consomme le plus d'énergie
(et qui pollue le plus).

- Si on monte en gamme, on peut s'orienter vers un HP Proliant
Microserver, comme celui-ci :

https://www.digitec.ch/fr/s1/product/hpe-proliant-microserver-gen10-amd-opteron-x3216-opteron-x3216-8go-35-serveurs-6359954

Pas besoin de le monter, c'est une entrée de gamme, mais pro, pas trop
chère, avec du RAID matériel sur 4 disques si on veut et un proc qui ne
consomme pas trop. C'est vraiment une solution top pour un NAS libre
avec du gros stockage.

a+

Samuel

Le 09.11.18 à 19:16, Daniel Cordey a écrit :
>
>
> On 09.11.18 18:08, Frederic Dumas wrote:
>>
>> Coté hardware, j'aurai bien retenu une petite carte mère
>> microATX/mini-ITX avec un Celeron ou un Pentium récent à très faible
>> consommation : les J4105 et J5005 brulent l'un comme l'autre 10W max,
>> on les achète soudés sur la carte mère, on parle de moins d'une
>> centaine de francs pour l'ensemble.
>
> Il y a déjà trois ans, j'avais investigué des cartes Pico-ITX avec des
> processeurs à faible consommation comme les Intel J1900, N3710 ou
> N4200 (entre autre). Ces CPUs ont un TDP compris entre 4.5 et 6 W.
>
> Sur des cartes Pico-ITX ont a jusqu'à 8 GB de DDR3 et toutes ont au
> moins un port Gigabit Ethernet, mais certains en ont deux. Les cartes
> diffèrent au niveau du stockage et de l'alimentation. Chez Commell, on
> a seulement du mSATA de base, un port SATA3 et deux ports USB 2.0. Les
> autres constructeurs offrent jusqu'à 4 ports USB 2.0, un ou deux slots
> M.2 (PCIe !) et un ou deux port Sata 2-3 (ça dépend).
>
> L'avantage de ces cartes est un encombrement très faible (100x72 mm)
> et une consommation très restreinte. Il y a assez de port SATA/M.2 ou
> USB pour planter tout type de disque (SSD pour les M.2 et mSATA). Ca
> peut donc bien servir de NAS sans prendre beaucoup de place et en
> consommant un minimum.
>
> Les processeurs mentionnés datent un peu, mais Intel ne semble pas
> trop pressé d'en sortir de nouveaux dans cette gamme de TDP. Ces
> cartes sont destinées au marché de l'embarqué, ce qui fait que les
> clients sont peut réactifs et ne cherchent pas vraiment la dernière
> techno... Donc, ce monde évolue lentement. Mais, je sais que,
> normalement, Intel a sorti des versions *lake plus récentes mais je
> n'en ai pas trouvé de trace chez les fabricants de petites carte-mère...
>
>> Le problème, c'est que le prix des cartes mères compatibles s'envole
>> alors.
>
> Sans doute lié à un chipset plus cher et des prix de production plus
> élevés, dus à une demande plus faible.
>
>>
>> Je ne vois pas bien quoi choisir comme plateforme Intel pour un NAS
>> domestique avec OMV, pour garder le processeur vers les 10W mais
>> utiliser pourtant de la RAM ECC. La RAM ECC est fortement recommandée
>> par OMV. Je ne sais pas si c'est complètement justifié, mais tant
>> qu'à faire les choses bien,
>
> Ouai... ça fait longtemps (plus de 20 ans) que j'ai cessé de me
> prendre le chou avec la RAM ECC. C'est cher et si tu n'as pas un
> système avec un chipset maousse au niveau memory-management (aliasing
> !), ce n'est pas vraiment utile. De plus, si l'on s'attache aux
> probabilités d'erreur de bit, ont doit plutôt s'inquiéter des
> probabilités d'erreur sur les disques SDD (et HDD) que de la RAM où
> l'information est présente beaucoup moins longtemps et en moins grande
> quantité avec une densité plus faible. Comme le disait Marc Schaefer,
> la probabilité d'une erreur de bit sur un disque de 10 TB est énorme
> par rapport à la probabilité d'une erreur sur une barrette de 8 GB de
> RAM (je paraphrase Marc, je sais...).
>
> Pendant longtemps j'ai utilisé de la RAM ECC, mais depuis que j'ai
> abandonné cette pratique, j'avoue n'avoir jamais expérimenté de
> problème lié à de problèmes de corruption de mémoire. Les corruptions
> de mémoire sont principalement dus à des problèmes de hardware à
> l'intérieur du chip et la probabilité de corruption due à des rayons
> cosmiques existe, mais 1) on ne peut pas le prouver 2) c'est hyper
> rare 3) ça peut aussi se passer dans le CPU 4) ou la cache 5) ou le
> chipset 6) on un chip sur une carte I/O 7) etc. !!!
>
> Je ne partage pas la paranoïa au sujet de la mémoire ECC et je pense
> que c'est largement surfait. Même à l'époque où j'utilisais de la
> mémoire ECC, je n'ai jamais expérimenté de message système me
> signalent des problèmes de bits erronés. Il se peut que des messages
> me soient passés sous le nez sans que je les voie... mais en tout cas,
> sur 30 ans, j'ai produit sans doute mille fois plus de bugs dans mes
> codes qu'il n'y a eu de corruption de bits dans la RAM. Si OMV est si
> sûr de son code au point de penser qu'une corruption de bit est plus
> probable que l'effet d'un bug dans leur code, je comprends leur
> recommandation au sujet de la RAM ECC. Mais seulement si... :-)
>
>>
>>
>> Si quelqu'un a des suggestions, je suis preneur.
>
> Juste mon humble avis.
>
> dc
>
>     
>
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> https://forum.linux-gull.ch/mailman/listinfo/gull
>
-- 

-----------------------
Samuel Chenal
https://www.ll-dd.ch
samuel.chenal at ll-dd.ch
-----------------------

Merci d'utiliser des formats
de fichiers ouverts (comme ODF)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20181111/41cbdb0a/attachment-0001.sig>