Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11

[un peu HS...] RAID1 sata et ssd

4 réponses
Avatar
steve
Salut la liste,

Mon système est en raid1 logiciel (mdadm) avec deux disques durs sata. L'un des
deux commence à faire de drôles de bruits, je vais donc devoir le changer. Je
me demande si c'est possible de le changer pour un disque ssd afin de passer en
douceur en un système tout ssd (je changerai le second plus tard). Est-ce que
cela pose un problème particulier ? Je n'ai rien trouvé sur le Net qui le
déconseille mais je voulais avoir un retour de vos expériences sur le sujet
avant de me lancer. Et en passant avez-vous des conseils pour de bons disques
ssd ? C'est plus la fiabilité qui m'intéresse que la taille ou le prix.

Merci d'avance pour vos lumières.

steve


PS : message un peu HS mais pas tout à fait vu que tout se fait sur une wheezy à jour.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: http://lists.debian.org/20121116061217.GA9712@localhost

4 réponses

Avatar
Bzzz
On Fri, 16 Nov 2012 07:12:17 +0100
steve wrote:

changer. Je me demande si c'est possible de le changer pour un disque ssd
afin de passer en douceur en un système tout ssd (je changerai le se cond plus
tard). Est-ce que cela pose un problème particulier ?



À vue de tarbouif pas vraiment, cependant en écriture la dispo de l'array sera
directement liée au HD normal, plus lent.

sur le sujet avant de me lancer. Et en passant avez-vous des conseils pou r de
bons disques ssd ? C'est plus la fiabilité qui m'intéresse que la taille ou
le prix.



Étant donné le peu de fondeurs il-y-a peu de chances de se trompe r; je dirais
que les 'grandes' marques n'ont aucun intérêt à passer pour des minables; par
ailleurs, le développement de firmwares efficaces passe par des moyens humains
conséquents (quoique là, ces marques sont souvent les premiè res à renâcler à
fixer les bugs...)

Cependant si l'array a beaucoup de clients simultanés il faut 'gader d e près
le nombre d'IOPS, qui peut varier du simple au quadruple.

Sans compter que là, plus qu'avec les HDz, il serait prudent d'adopter à terme
2 SSD de marques différentes - YMMV; mais au vu des commentaires rà ©cents sur
le peu de fiabilité des SSD en utilisation pro, peut-être serait- il mieux
d'adopter une solution hybride: soit des HDz intégrant directement un cache
SSD, soit une solution logicielle de cache des HDz par des SSD; en commen çant
par des HDz haut de gamme ultra-rapides.

Perso, je ne prendrais pas le risque de reposer sur une solution 100% SSD.
--
<lea> Question 28 : Qu'est ce que le petit prince ramone régulièr ement
sur sa planète ?
<Ewilan> la petite princesse

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
Olivier Lange
Le 16 novembre 2012 08:54, Bzzz a écrit :
On Fri, 16 Nov 2012 07:12:17 +0100
steve wrote:

changer. Je me demande si c'est possible de le changer pour un disque ss d
afin de passer en douceur en un système tout ssd (je changerai le s econd plus
tard). Est-ce que cela pose un problème particulier ?



À vue de tarbouif pas vraiment, cependant en écriture la dispo de l'array sera
directement liée au HD normal, plus lent.

sur le sujet avant de me lancer. Et en passant avez-vous des conseils po ur de
bons disques ssd ? C'est plus la fiabilité qui m'intéresse que la taille ou
le prix.





Personnellement, je ne jure que par de l'intel. Ils ont fait depuis le
début de très bon disques, avec un rapport qualité prix corr ecte. Y a
peut être plus haut de gamme, mais en tout cas, jamais été d éçu pour
les SSD, et on les utilises en embarqué comme en dédiés.


Étant donné le peu de fondeurs il-y-a peu de chances de se trom per; je dirais
que les 'grandes' marques n'ont aucun intérêt à passer pou r des minables; par
ailleurs, le développement de firmwares efficaces passe par des moye ns humains
conséquents (quoique là, ces marques sont souvent les premià ¨res à renâcler à
fixer les bugs...)

Cependant si l'array a beaucoup de clients simultanés il faut 'gader de près
le nombre d'IOPS, qui peut varier du simple au quadruple.

Sans compter que là, plus qu'avec les HDz, il serait prudent d'adopt er à terme
2 SSD de marques différentes - YMMV; mais au vu des commentaires r écents sur
le peu de fiabilité des SSD en utilisation pro, peut-être serai t-il mieux
d'adopter une solution hybride: soit des HDz intégrant directement u n cache
SSD, soit une solution logicielle de cache des HDz par des SSD; en commen çant
par des HDz haut de gamme ultra-rapides.

Perso, je ne prendrais pas le risque de reposer sur une solution 100% SSD .



Ah bon? Et pourquoi donc? J'ai quasi tout mes serveurs dédiés qui sont
en full SSD, et pas le moindre problème. Les chances pour que les 2
disques tombent en même temps sont quand même relativement faible , et
si l'un tombe, y a toujours le second qui est la, le temps de le
changer. Après, ca n'empèche pas de faire du backup, hein...

Mais je ne jure plus que par le SSD, en tout cas pour les hosts
(Debian / Proxmox). Les datas restent sur du NAS/ou du sata 10k, car
bonne chance pour trouver des SSD de 1To ou plus :p.

Olivier

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/CABGC0bsH74gU8LiQb3x=OELbhhUGS-e0HSNqi6MXMHyT=
Avatar
Bzzz
On Fri, 16 Nov 2012 09:03:48 +0100
Olivier Lange wrote:


Personnellement, je ne jure que par de l'intel. Ils ont fait depuis le
début de très bon disques, avec un rapport qualité prix co rrecte. Y a
peut être plus haut de gamme, mais en tout cas, jamais été déçu pour
les SSD, et on les utilises en embarqué comme en dédiés.



Wai, ça semble avoir été le premier fondeur à booster l es IOPS; et puis
dans sa position, difficile de commercialiser des daubes (quoique...:)


Ah bon? Et pourquoi donc? J'ai quasi tout mes serveurs dédiés q ui sont
en full SSD, et pas le moindre problème. Les chances pour que les 2
disques tombent en même temps sont quand même relativement faib le, et
si l'un tombe, y a toujours le second qui est la,



Excepté que tous les fabricants ne brassent pas les S/N (différen ts
S/N & lots dans le même carton de N disks), et les vendeurs encore
moins, par conséquent le risque de se retrouver avec 2 SSDz contigus
reste assez élevé, d'où un risque non-négligeable de pa nne simultanée.

--
guigui : tain j'ai une gastro qui me lache pas depuis 3 jour
hime : une fidèle gastro.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/
Avatar
steve
Merci pour vos réponses.


Le 16-11-2012, à 08:54:15 +0100, Bzzz () a écrit :

On Fri, 16 Nov 2012 07:12:17 +0100
steve wrote:

> changer. Je me demande si c'est possible de le changer pour un disque ssd
> afin de passer en douceur en un système tout ssd (je changerai le second plus
> tard). Est-ce que cela pose un problème particulier ?

À vue de tarbouif pas vraiment, cependant en écriture la dispo de l'array sera
directement liée au HD normal, plus lent.



Oui c'est bien ce que je pensais. L'idée sous-jacente est de passer un premier
disque de la grappe en ssd, puis de remplacer le second disque sata par un ssd,
ce qui m'éviterais de devoir tout réinstaller (et tout se qui va avec). Avec
cette solution, une simple reconstruction de la grappe et le tour est joué.
C'est donc ce que je vais faire, très probablement.


> sur le sujet avant de me lancer. Et en passant avez-vous des conseils pour de
> bons disques ssd ? C'est plus la fiabilité qui m'intéresse que la taille ou
> le prix.

Étant donné le peu de fondeurs il-y-a peu de chances de se tromper; je dirais
que les 'grandes' marques n'ont aucun intérêt à passer pour des minables; par
ailleurs, le développement de firmwares efficaces passe par des moyens humains
conséquents (quoique là, ces marques sont souvent les premières à renâcler à
fixer les bugs...)

Cependant si l'array a beaucoup de clients simultanés il faut 'gader de près
le nombre d'IOPS, qui peut varier du simple au quadruple.



Je regarderai, merci du conseil.


Sans compter que là, plus qu'avec les HDz, il serait prudent d'adopter à terme
2 SSD de marques différentes - YMMV;



Je partage totalement cette idée, qui se généralise pour tout type de support
de données.

mais au vu des commentaires récents sur
le peu de fiabilité des SSD en utilisation pro, peut-être serait-il mieux
d'adopter une solution hybride: soit des HDz intégrant directement un cache
SSD, soit une solution logicielle de cache des HDz par des SSD; en commençant
par des HDz haut de gamme ultra-rapides.



Les avis sur la fiabilité du SSD sont vraiment partagés.


Perso, je ne prendrais pas le risque de reposer sur une solution 100% SSD.



Moi si à l'heure actuelle, mais avec un spare dans la grappe et une sauvegarde
régulière des données importantes, il va de soi.


Merci et bonne journée,
steve

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: http://lists.debian.org/