Cherche retour d'exp sur l'install de FB 5.3 sur des CM RAID 1 IDE

Le
christophe
Hello ttout le monde,

j'aurais d'ici peu de temps a monter un serveur FreeBSD 5.3 en raid 1 IDE ou
SATA.
Le raid materiel est trop cher, le logiciel trop long a installer (je
n'aurais que tres peu de temps a lui consacrer) donc j'envisage d'utiliser
une CM avec controleur raid integré mais la je galère pour trouver des infos
sur ce qui est supporté ou pas

Donc je cherche des réferences des cartes mères (bas prix donc on oublie les
TYAN :( ) dont le controleur raid fonctionne immediatement et sans probleme
sous FB 5.3

Sinon a default, quelle carte raid puis-je utiliser (tjrs les mêmes
critères: bas prix et fonctionne sans pb sur FB 5.3 )

PS: dans les archives j'ai trouvé la Asus PSCH-L


merci d'avance
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
pornin
Le #746798
According to christophe
j'aurais d'ici peu de temps a monter un serveur FreeBSD 5.3 en raid
1 IDE ou SATA. Le raid materiel est trop cher, le logiciel trop long
a installer (je n'aurais que tres peu de temps a lui consacrer) donc
j'envisage d'utiliser une CM avec controleur raid integré mais la je
galère pour trouver des infos sur ce qui est supporté ou pas ...


J'ai fait ça, en logiciel, il y a peu -- et ça marche bien.


Il y a plusieurs manières de faire du RAID1 sous FreeBSD :

-- une carte matérielle qui fait tout bien ;

-- une fausse carte matérielle, ou un BIOS spécial (aka carte mère avec
"contrôleur RAID intégré"), qui nécessite un support de FreeBSD ;

-- une variante du précédent, sur de l'IDE de base, avec "atacontrol" ;

-- vinum (ou gvinum) ;

-- geom_mirror.


Dans un système RAID, il y a sur chaque disque des données, et des
méta-données. Les méta-données indiquent quel disque fait quoi dans
le système.

Dans le cas d'une carte matérielle qui fait tout, l'OS ne voit qu'un
seul disque (virtuel), et c'est la carte qui fait tout le boulot de
reconnaître les méta-données, et envoyer les données où il faut.

Dans le cas d'une "fausse carte", beaucoup moins chère, c'est l'OS qui
doit se charger d'envoyer les données en plusieurs exemplaires et de
reconnaître les méta-données. Tout ce que fait la carte, c'est fournir
un support BIOS pour permettre à l'OS de booter depuis le disque (ce
support est du code qui reconnaît suffisamment les méta-données pour
faire des accès en lecture). FreeBSD supporte quelques types de cartes
de ce genre (apparemment, des "Promise", des "Highpoint" et des "Silicon
Image"). La plupart des cartes mères avec "contrôleur RAID" intégré
sont de ce type : de l'IDE de base, avec juste un peu de code finaud
dans le BIOS.

Puisque dans le cas d'une fausse carte, l'OS doit tout faire, il peut
tout aussi bien le faire tout seul, sur de l'IDE de base. FreeBSD
sait faire. La commande pour gérer ça est "atacontrol" (chercher la
commande "create"). Évidemment, sans support BIOS, la machine boote
en ne regardant qu'un seul disque, donc ça ne marche que si le format
des données sur un disque seul est compatible (i.e. lisible comme un
filesystem normal). Chance : c'est le cas de RAID1.

Dans mes essais, ce support RAID1 logiciel au niveau du support ATA
n'est _pas_ fiable : en cas de coupure de courant, le système ne
considère pas les disques comme potentiellement désynchronisés, et
il ne reconstruit pas le miroir. Il peut en résulter une corruption
du disque.

Vinum est un "logical volume manager" qui met en place une structure
complexe pour faire beaucoup de choses, incluant divers types de RAID,
dont RAID1. Gvinum est une réimplémentation de vinum par-dessus GEOM,
qui est le nouveau système interne d'organisation des accès aux disques
dans FreeBSD. (G)vinum, c'est compliqué. J'ai essayé et je n'ai pas
tout compris. Disons qu'on peut arriver à mettre en place une config
qui marche, mais en cas d'ennui, c'est très fragile : une commande de
travers, et hop, plus de filesystem.

Geom_mirror est ce que j'utilise. cf "man gmirror". La méthode est la
suivante :

1. Installer un FreeBSD fonctionnel sur un troisième disque quelconque.

2. Monter dans la machine ayant ce FreeBSD les deux disques sur lesquels
on va faire du RAID1.

3. Créer un miroir sur les deux disques, avec gmirror. Mettons que ce
miroir s'appelle "world".

4. Créer dans /dev/mirror/world une slice (avec fdisk) et dans cette
slice des partitions (avec bsdlabel). On se retrouve avec des
/dev/mirror/worlds1a, /dev/mirror/worlds1b, etc...

5. Rendre /dev/mirror/world bootable avec boot0cfg.

6. Copier le FreeBSD dans le miroir, avec des newfs, dump et restore.
Typiquement, pour copier de /dev/ad0s1a dans /dev/mirror/worlds1a :

newfs /dev/mirror/worlds1a
mount /dev/mirror/worlds1a /mnt
cd /mnt
dump -0 -L -f - /dev/ad0s1a | restore rf -

cf man dump et man restore pour plus de détail. "newfs" a aussi quelques
options à regarder, particulièrement "-U" pour activer les softupdates
(ce que je recommande, sauf peut-être pour le filesystem racine).

7. Rendre bootable /dev/mirror/worlds1 (la slice) avec bsdlabel
(bsdlabel -B /dev/mirror/worlds1).

8. Modifier, dans la copie (sur le miroir), le fichier /boot/loader.conf :
il faut y rajouter la ligne suivante :

geom_mirror_load="YES"

(ce fichier est souvent vide dans une installation standard.)

9. Toujours dans le miroir, modifier le /etc/fstab pour qu'il référence
les /dev/mirror/worlds1a & co, et plus les /dev/ad0s1a & co.

10. Éteindre la machine, enlever le disque temporaire, ne laisser que
les deux disques du miroir, en en mettant un dans une position bootable
pour le BIOS. Le mieux est de mettre un disque en master sur le premier
contrôleur IDE, et l'autre disque en master sur le deuxième contrôleur.
Certains BIOS pourront booter indifféremment sur un disque ou l'autre,
par un simple réglage logiciel.

11. Allumer la machine. Normalement, tout marche et c'est fini.


Cette procédure fonctionne parce que :

-- C'est du RAID1 ; chaque disque indépendamment est un disque avec
des partitions et un filesystem valides. Les méta-données installées
par gmirror sont, for idoinement, placées à la _fin_ des disques, et
pas au début.

-- Le bootloader (installé par bsdlabel -B) sait lire un filesystem et
charger le noyau. Il sait également charger des modules, et c'est ce
qu'il fait avec geom_mirror.ko, ainsi que l'indique le loader.conf.
Comme cela, avant même le montage du filesystem racine, le miroir est
accessible en tant que tel.

-- De même, le filesystem racine est repéré par le bootloader, qui
regarde le contenu du fichier /etc/fstab. Il peut ainsi avertir le noyau
d'accéder à /dev/mirror/worlds1a, et comme le module geom_mirror est
chargé, /dev/mirror/worlds1a existe (enfin, le miroir existe, et le
noyau sait traduire ce nom correctement, avant même d'avoir monté la
partition racine).

À noter, quand même, un bug : gmirror a tendance à oublier d'écrire un
0 quelque part, lors de la création du miroir. Ça se manifeste de façon
spectaculaire : lors de la création, la machine plante. Le contournement
consiste à, préalablement, écraser avec des 0 la fin des disques (avec
"dd if=/dev/zero of=/dev/ad1 bs48576" par exemple -- ça, ça écrase le
disque ad1 en entier, ce qui marche aussi mais est plus long). Le bon
côté de l'affaire, c'est que si le bug ne se manifeste pas au début,
alors il est évité et il ne posera plus de problèmes ensuite.

Un détail : gmirror peut faire du RAID1 entre des disques de tailles
différentes, mais en utilisant, fatalement, la taille du plus petit
des deux disques. Ce qui veut dire qu'après la panne d'un des disques,
on peut le remplacer, à condition d'en mettre un au moins aussi grand.
Tous les disques vendus pour une taille donnée (par exemple "80G") ne
font pas la même taille. Mes deux disques font respectivement 78167 MB
et 76319 MB, donc je "perds" près de 2 Go sur un des disques. Rien de
grave.

Un dernier détail : le chargement de geom_mirror implique un passage
en revue des disques, et notamment les deux messages suivants :

acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x01 error=0
acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x01 error=0

Ces messages n'ont rien de grave : c'est juste que geom_mirror essaye de
voir s'il y a un miroir mettant en jeu le cdrom, et comme il n'y a pas
de disque dans le lecteur, ça fait une erreur. À part ces deux messages
au boot, la seule conséquence est qu'il faut attendre dix secondes de
plus pour booter.


Toutes ces informations sont bien sûr données sans aucune garantie
de quoi que ce soit. Je ne veux prendre aucune responsabilité. Vous
êtes prévenus. Il s'avère juste qu'à mon travail, j'ai fait comme ça
et ça marche. Notamment, on a eu une coupure de courant (de plus de
quatre heures !) et, au reboot, la machine a fait tout ce qu'il faut
(reconstruction automatique du miroir).


--Thomas Pornin

christophe
Le #746790
Tout d'abord merci pour votre explication très précise qui sera très utile
a beaucoup de monde mais malheureusement pas pour moi (aujourd'hui en tout
cas ;))
en effet, bien que suffisamment a l'aise sous FreeBSD pour tenter le coup
du raid soft je n'en aurais pas temps !
En fait j'aurais très peu de temps a consacrer a cette machine et le timing
est déjà suffisemment serré comme ca ...

Donc comme le raid hard est hors budget il ne me reste que le raid
"pseudo-hard"
via une CM avec controlleur intégré ou via une carte spécifique.

Seulement ces cartes necessitent un driver spécifique et c'est la que je me
pert ...

Je cherche donc des references de CM ou carte controlleur fonctionnant
immédiatement
et sans pb avec FB 5.3 ...

Encore merci et bonne journée





"Thomas Pornin" news:crlo48$2dva$
According to christophe
j'aurais d'ici peu de temps a monter un serveur FreeBSD 5.3 en raid
1 IDE ou SATA. Le raid materiel est trop cher, le logiciel trop long
a installer (je n'aurais que tres peu de temps a lui consacrer) donc
j'envisage d'utiliser une CM avec controleur raid integré mais la je
galère pour trouver des infos sur ce qui est supporté ou pas ...


J'ai fait ça, en logiciel, il y a peu -- et ça marche bien.


Il y a plusieurs manières de faire du RAID1 sous FreeBSD :

-- une carte matérielle qui fait tout bien ;

-- une fausse carte matérielle, ou un BIOS spécial (aka carte mère avec
"contrôleur RAID intégré"), qui nécessite un support de FreeBSD ;

-- une variante du précédent, sur de l'IDE de base, avec "atacontrol" ;

-- vinum (ou gvinum) ;

-- geom_mirror.


Dans un système RAID, il y a sur chaque disque des données, et des
méta-données. Les méta-données indiquent quel disque fait quoi dans
le système.

Dans le cas d'une carte matérielle qui fait tout, l'OS ne voit qu'un
seul disque (virtuel), et c'est la carte qui fait tout le boulot de
reconnaître les méta-données, et envoyer les données où il faut.

Dans le cas d'une "fausse carte", beaucoup moins chère, c'est l'OS qui
doit se charger d'envoyer les données en plusieurs exemplaires et de
reconnaître les méta-données. Tout ce que fait la carte, c'est fournir
un support BIOS pour permettre à l'OS de booter depuis le disque (ce
support est du code qui reconnaît suffisamment les méta-données pour
faire des accès en lecture). FreeBSD supporte quelques types de cartes
de ce genre (apparemment, des "Promise", des "Highpoint" et des "Silicon
Image"). La plupart des cartes mères avec "contrôleur RAID" intégré
sont de ce type : de l'IDE de base, avec juste un peu de code finaud
dans le BIOS.

Puisque dans le cas d'une fausse carte, l'OS doit tout faire, il peut
tout aussi bien le faire tout seul, sur de l'IDE de base. FreeBSD
sait faire. La commande pour gérer ça est "atacontrol" (chercher la
commande "create"). Évidemment, sans support BIOS, la machine boote
en ne regardant qu'un seul disque, donc ça ne marche que si le format
des données sur un disque seul est compatible (i.e. lisible comme un
filesystem normal). Chance : c'est le cas de RAID1.

Dans mes essais, ce support RAID1 logiciel au niveau du support ATA
n'est _pas_ fiable : en cas de coupure de courant, le système ne
considère pas les disques comme potentiellement désynchronisés, et
il ne reconstruit pas le miroir. Il peut en résulter une corruption
du disque.

Vinum est un "logical volume manager" qui met en place une structure
complexe pour faire beaucoup de choses, incluant divers types de RAID,
dont RAID1. Gvinum est une réimplémentation de vinum par-dessus GEOM,
qui est le nouveau système interne d'organisation des accès aux disques
dans FreeBSD. (G)vinum, c'est compliqué. J'ai essayé et je n'ai pas
tout compris. Disons qu'on peut arriver à mettre en place une config
qui marche, mais en cas d'ennui, c'est très fragile : une commande de
travers, et hop, plus de filesystem.

Geom_mirror est ce que j'utilise. cf "man gmirror". La méthode est la
suivante :

1. Installer un FreeBSD fonctionnel sur un troisième disque quelconque.

2. Monter dans la machine ayant ce FreeBSD les deux disques sur lesquels
on va faire du RAID1.

3. Créer un miroir sur les deux disques, avec gmirror. Mettons que ce
miroir s'appelle "world".

4. Créer dans /dev/mirror/world une slice (avec fdisk) et dans cette
slice des partitions (avec bsdlabel). On se retrouve avec des
/dev/mirror/worlds1a, /dev/mirror/worlds1b, etc...

5. Rendre /dev/mirror/world bootable avec boot0cfg.

6. Copier le FreeBSD dans le miroir, avec des newfs, dump et restore.
Typiquement, pour copier de /dev/ad0s1a dans /dev/mirror/worlds1a :

newfs /dev/mirror/worlds1a
mount /dev/mirror/worlds1a /mnt
cd /mnt
dump -0 -L -f - /dev/ad0s1a | restore rf -

cf man dump et man restore pour plus de détail. "newfs" a aussi quelques
options à regarder, particulièrement "-U" pour activer les softupdates
(ce que je recommande, sauf peut-être pour le filesystem racine).

7. Rendre bootable /dev/mirror/worlds1 (la slice) avec bsdlabel
(bsdlabel -B /dev/mirror/worlds1).

8. Modifier, dans la copie (sur le miroir), le fichier /boot/loader.conf :
il faut y rajouter la ligne suivante :

geom_mirror_load="YES"

(ce fichier est souvent vide dans une installation standard.)

9. Toujours dans le miroir, modifier le /etc/fstab pour qu'il référence
les /dev/mirror/worlds1a & co, et plus les /dev/ad0s1a & co.

10. Éteindre la machine, enlever le disque temporaire, ne laisser que
les deux disques du miroir, en en mettant un dans une position bootable
pour le BIOS. Le mieux est de mettre un disque en master sur le premier
contrôleur IDE, et l'autre disque en master sur le deuxième contrôleur.
Certains BIOS pourront booter indifféremment sur un disque ou l'autre,
par un simple réglage logiciel.

11. Allumer la machine. Normalement, tout marche et c'est fini.


Cette procédure fonctionne parce que :

-- C'est du RAID1 ; chaque disque indépendamment est un disque avec
des partitions et un filesystem valides. Les méta-données installées
par gmirror sont, for idoinement, placées à la _fin_ des disques, et
pas au début.

-- Le bootloader (installé par bsdlabel -B) sait lire un filesystem et
charger le noyau. Il sait également charger des modules, et c'est ce
qu'il fait avec geom_mirror.ko, ainsi que l'indique le loader.conf.
Comme cela, avant même le montage du filesystem racine, le miroir est
accessible en tant que tel.

-- De même, le filesystem racine est repéré par le bootloader, qui
regarde le contenu du fichier /etc/fstab. Il peut ainsi avertir le noyau
d'accéder à /dev/mirror/worlds1a, et comme le module geom_mirror est
chargé, /dev/mirror/worlds1a existe (enfin, le miroir existe, et le
noyau sait traduire ce nom correctement, avant même d'avoir monté la
partition racine).

À noter, quand même, un bug : gmirror a tendance à oublier d'écrire un
0 quelque part, lors de la création du miroir. Ça se manifeste de façon
spectaculaire : lors de la création, la machine plante. Le contournement
consiste à, préalablement, écraser avec des 0 la fin des disques (avec
"dd if=/dev/zero of=/dev/ad1 bs48576" par exemple -- ça, ça écrase le
disque ad1 en entier, ce qui marche aussi mais est plus long). Le bon
côté de l'affaire, c'est que si le bug ne se manifeste pas au début,
alors il est évité et il ne posera plus de problèmes ensuite.

Un détail : gmirror peut faire du RAID1 entre des disques de tailles
différentes, mais en utilisant, fatalement, la taille du plus petit
des deux disques. Ce qui veut dire qu'après la panne d'un des disques,
on peut le remplacer, à condition d'en mettre un au moins aussi grand.
Tous les disques vendus pour une taille donnée (par exemple "80G") ne
font pas la même taille. Mes deux disques font respectivement 78167 MB
et 76319 MB, donc je "perds" près de 2 Go sur un des disques. Rien de
grave.

Un dernier détail : le chargement de geom_mirror implique un passage
en revue des disques, et notamment les deux messages suivants :

acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x01 error=0
acd0: FAILURE - READ_BIG HARDWARE ERROR asc=0x08 ascq=0x01 error=0

Ces messages n'ont rien de grave : c'est juste que geom_mirror essaye de
voir s'il y a un miroir mettant en jeu le cdrom, et comme il n'y a pas
de disque dans le lecteur, ça fait une erreur. À part ces deux messages
au boot, la seule conséquence est qu'il faut attendre dix secondes de
plus pour booter.


Toutes ces informations sont bien sûr données sans aucune garantie
de quoi que ce soit. Je ne veux prendre aucune responsabilité. Vous
êtes prévenus. Il s'avère juste qu'à mon travail, j'ai fait comme ça
et ça marche. Notamment, on a eu une coupure de courant (de plus de
quatre heures !) et, au reboot, la machine a fait tout ce qu'il faut
(reconstruction automatique du miroir).


--Thomas Pornin



Christophe Cuq
Le #746043
(Xavier) writes:

Il y a un contrôleur RAID sur la corte pour les deux ports SATA. Bien
sûr, avec ça, tu ne feras pas du RAID 0+5, mais ça doit répondre à ton
besoin.


Moi j'ai une ASUS P4P800S-X et le moins qu'on puisse dire, c'est que
le SATA intégré fait la gueule avec Fribi5.3 :

ad8: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBAw549759
ad8: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA4624639
ad8: WARNING - WRITE_DMA UDMA ICRC error (retrying request) LBA0092991


Il y en a des dizaines comme ça tous les jours et quoi que j'ai pu
tenter après avoir fouillé gougle et autres n'ont fait que des blocages du
système avec reboot hard obligatoire...

(le disque est neuf et ne pose aucun problème sous d'autres systèmes
ni avec l'ancien contrôleur SATA qui tournait très bien sous 5.2.1 ...)

--
CHC

Christophe Cuq
Le #750845
(Xavier) writes:

Ben là, je suis précisément en train de recompiler un
5_STABLE/amd64, ça baigne. Ce serait pas un Pb de disque, plutôt
(CRC error, ça y ressemble)


C'est ce que je croyais aussi, mais non, au vu des lectures que j'ai
pu avoir...

D'autant que le disque fonctionnait parfaitement et sans aucune erreur
avec l'ancienne carte Mère (qui a fondu, cause du rachat de la nouvelle)
et la carte SATA PCI qui était dessus et le tout en 5.2.1...

Et ce n'est pas un amd64, j'aurais dû précider, mais un fribi 5.3 i386
tout neuf et tout ce qu'il y a de standard sur un celeron 2.4. Ça
marche du feu de Dieu, sauf ces messages de warninge.

Et comme serveur de news, il est parfait (le HD de 80 Go en question
ne sert que pour /usr/local/news et donc le spool) :)

Mais bon, tout ça ne règle pas mes problèmes de messages :)

--
CHC

Olivier Brisson
Le #761931
christophe
Hello ttout le monde,

Sinon a default, quelle carte raid puis-je utiliser (tjrs les mêmes
critères: bas prix et fonctionne sans pb sur FB 5.3 ...)

[...]

merci d'avance



Bonjour Christophe,

En ce qui concerne les cartes RAID, j'aime bien les 3ware. La AMCC's
3ware 8500-4LP n'est pas trop chère et marche très bien avec FreeBSD
5.3. Plus d'infos: "man 4 twe"

Sinon, si tu veux toujours du ATA, tu peux utiliser les cartes promises
comme indiqué dans le handbook: (Pas essayé)
16.4.2 Hardware RAID
http://www.ch.freebsd.org/doc/en_US.ISO8859-1/books/handbook/raid.html

Cordialement,

Olivier
--

Christophe Cuq
Le #761355
(Xavier) writes:

Ben là, je suis précisément en train de recompiler un 5_STABLE/amd64, ça
baigne. Ce serait pas un Pb de disque, plutôt (CRC error, ça y
ressemble)


Bon, ben je confirme c'était pas un problème de disque, mais le BIOS
qui n'envoyai pas les bonnes infos de type de disque et donc le fribi
essayait d'écrire en mode UDMA100 sur un disque SATA

Enfin, c'est ce que j'ai compris depuis que j'ai résolu le problème :)

Je suis allé chez Asus voir ce qu'ils disaient du problème :
rien. Mais il y avait une mise à jour de Bios suite à des problèmes de
SATA sur winxp. Bon, c'est sur winxp, certes, mais ça parle de
SATA. Au pire, on installera un XP :)

Ah ben non, c'est un serveur de news, INN va pas être content.

Bon, ben tant pis, on va tenter la manip, on verra bien.

Hop, download, disquette, reboot, flashage, reboot et hop magnifique
page d'erreur, il ne trouvait même plus la partoche de boot.

Et je suis arrivé sur un prompt que j'avais jamais vu (rootmount ou un
truc du genre, j'ai pas noté)

Je lui donne à manger la partoche qu'il me demandait et là, en
regardant mon /etc/fstab je me suis rendu compte que les noms des
/dev/ ne correspondaient plus avec ce qu'il y avait dans le dmesg (ad4
dans le fstab était devenu ad0 dans le dmesg et ad8 (celui qui posait
problème) était devenu ad4).

Qu'à celà ne tienne, on monte /usr et / en rw avec les nouveaux noms
des /dev, un coup de vi sur /etc/fstab pour changer les références (je
pase sur les emmerdes du clavier pas en fr ouski faut aller chercher
les : ! et autres joyeusetés), on trace les pentagrammes qui vont
bien, on sort le paquet d'ail (pas le temps d'aller cherche de l'eau
bénite) et on reboote.

Et hop, la machine reboote toute seule et depuis plus une seule
erreur ni WARNING ni quoi que ce soit.

C'est bô Fribi :)

--
CHC

Publicité
Poster une réponse
Anonyme