Reprise du message précédent :
Sinon faudrait préciser ce que t'utilises comme soft de multipath (si multipath), le matos concerné, etc...

C'est à quel niveau que ça manque ? Les block devices ? Les partitions sur les blocks dev ? Plus loin : une fois passé dans le multipath ?

La détection des Luns se passent correctement (modifier la configuration de udev.d tel qu'indiqué dans la doc pour éviter que ca prenne 3 heures).

Le problème se situe à l'ajout des partitions dans /dev/mapper lors du boot : toutes les entrées attendues n'y sont pas (environ une 40 de partitions manquantes)
Ces entrées peuvent ensuite être ajoutées "manuellement" après le boot via partprobe.

Après re-lecture du script d'init rc.syslinux, je pense avoir trouvé un point :
=================================================
* The kpartx utility creates device maps from partition tables. Device-mapper devices with minor numbers greater than 255 caused kpartx to use the UUID from the wrong device when trying to create partitions. If the device had pre-existing partitions, kpartx would fail to create the new partitions. With this update, kpartx is now able to handle device-mapper devices with minor numbers greater than 255. (BZ#526550)
=================================================

Pour le détail dans le script d'ini rc.syslinux, avant montage du / en rw, est lancé un "multipath.static" et un kpartx -a -p p pour chaque device multipathé ...

Je vérifierai lundi la version du paquet multipath (je suis quasi sur qu'il n'est pas à jour), et également si les partitions ajoutées via partprobe auraient pas un minor number supérieure à 255.

Pour ceusse qui s'amusent avec les kickstart et RHEL6.

Prenez note que le point de montage du CD/DVD durant le kickstart n'est plus /mnt/source mais /mnt/stage2.
Faut adapter les %pre/%post scripts

Dans la même série, dans le cas d'une installation NFS, c'est le répertoire "images" de l'arborescence du DVD qui est monté sous /mnt/sysimage, et pas la racine de l'arbo elle-même.
Donc l'arbo complète d'installation n'est par défaut PAS accessible lors d'une installation NFS, contrairement à l'installation par DVD.

 
Pas de probleme pour des serveurs ayant plus de 200 LUNs, mais on utilise pas multipath. Par contre, merci pour le tip sur udev (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/DM_Multipath/many_luns.html, remplacer le 5 par 6 pour la RHEL6), je verrai lundi si on a cette regle pour la virer. Car 200+ LUNs fois deux chemins fois deux baies, il faut 2h pour booter si on se trouve en plus sur la console série...
 

 
Nous on utilise la méthode http via un Red Hat Satellite, et on n'a pas du changer grand chose. L'ajout d'un serveur ssh pendant l'install, ça c'était une bonne idée, backportée en RHEL 5.6 ou 7 je crois

Simple curiosité, mais pourquoi + de 200 LUNs sur un même serveur ?

 
Datawarehouse de plusieurs To nécessitant de la performance, donc un certain nombres de LUNs sur lequel on crée un certain nombre e volume pour bien répartir les IO

 
 
Mais au bout d'un moment, c'est pas ta HBA qui devient bottleneck ?

 
Tous les volumes ne sont pas utilisés en même temps, donc ça va. Il y a des données de 2008 qui ne sont que rarement utilisées.
 
On a du rajouter une HBA car la baie ne voulait pas plus de 255 LUNs pour un meme WWN
 

Y a combien de baies en face ? de volumes RAID ?

Répartition optimale des IOs de milliers de serveurs sur de nombreux axes de plusieurs baies. Et également un coût au To très élevé.
Heureusement les baies dites virtualisées sont arrivées et gèrent la répartition automatique des IOs sur les axes

Quand la HBA devient bottleneck il suffit de rajouter des HBA mais après vaut mieux rajouter un serveur aussi xD

Là tu parles de milliers de serveurs, mais pourquoi 200 LUNs sur 1 serveur, c'est ça ma question

 
deux clariion complet dédiés aux deux machine. Pour les volumes, je ne sais plus, mais plusieurs dizaines

Sinon si tu mutualises plusieurs base de données (Oracle par exemple) sur un serveur un peu costaud comme un Dell R910, tu peux vites te retrouver avec 200 luns ;-)

Là je comprend

Par contre pour l'histoire de perfs, moins. T'as beau multiplier les LUNs, si elles sont sur les mêmes axes coté baie SAN, je vois pas en quoi ça apporte de meilleures I/Os, le goulot d'étranglement se situant sur les axes.

 
quand tu as une baie entièrement dédiée à l'appli et aux deux serveurs, c'est plus facile de la découper comme tu le veux niveau HVE/LUNs dés le début en fonction des besoins. Tu peux tout choisir à ta guise (nombre d'axe, de disques, etc.)

Plus facile Ok, mais niveau I/O je vois pas la différence entre avoir 2 grosses LUNs (c'est un exemple) sur 2 volumes RAIDs, que 2x100 LUNs sur ces 2 mêmes volumes RAID.
Je dirais même qu'au niveau de la baie, la gestion du cache risque de faire baisser les perfs au final.

Je ne suis pas un expert SAN, loin de la, mais j'ai vu la différence. L'équipe SAN a taillé des LUNs d'une manière optimisée dans la baie et nous les ont fournies. Le but était de bien répartir les LUNs sur les disques pour éviter les contentions.
 
Sur ces LUNs, via volume manager, nous avons construit nos volumes (strip-mirror, raid5, concat) en fonction de nos besoins.

 
Apparement l'ordre de céation des partitions n'est pas non plus respecté dans le fichier kickstart.
Le kickstart de RHEL6 semble faire en premier les partitions classiques et ensuite les PV pour LVM.  
Du coup pour ceux dont l'ordre des partitions est important (au hasard, moi ) ça fout un peu le merdier ...

 
En fait tu as beaucoup plus que deux volumes RAID : genre des centaines.  
Tu répartis la charge de l'ensemble des serveurs sur sur l'ensemble des RG des baies (beaucoup de RG, beaucoups de serveurs => beaucoup de LUNs)

Ok, si plusieurs centaines de Raid Group je comprends
 
Mais vos baies ne permettent pas de le faire coté SAN tout ça ?
Par exemple chez EMC on peut faire des Metaluns (en mode stripped, sinon aucun intérêt point de vue perfs).

Certaines baies dites virtualisées permettent de faire des pools consitutés de plusieurs RAID Groups. La baie répartie "automatiquement" la charge d'une LUN sur les RAID Groups, la LUN étant découpée dans le pool

D'autres baie ne le permettent pas (même haut de gamme).
Encore dans certains il n'est pas souhaitable d'activer la gestion automatique de la répartition de charge (surconsommation de ressources au niveau des contrôleurs)

 
Bien sur que si elles peuvent le faire. Mais après tu peux repartir les LUNs sur différents port FA, et refaire un strip ou un concat au niveau de l'OS peut encore amener un gain.
 
Et puis ça dépend aussi de la taille des volumes. Parfois, tu n'as pas besoin d'un gros volumes mais il doit être rapide. Il faut donc tailler les LUNs dans des disques spécifiques

 
Confirmé c'était bien ce bug ...

Bonjour à tous,
 
J'aurais besoin de désactiver certaines fonctionnalitées d'offloading sur les cartes réseaux. En cli la commande est la suivante :  

 
Par contre je ne vois pas où  ajouter ce paramétrage dans les fichiers de configuration ou de script d'init sur redhat ... une idée ?
 
Le paramétrage via "ETHTOOL_OPTS" dans ifcfg-ethX ne fonctionne pas ... ce qui est l'ogique vu le code dans /etc/sysconfig/network-scripts/ifup-eth :  

 
Reste la possibilité du /etc/rc.local mais bon c'est pas top ...
 
Merci d'avance !
 
 

La derniere fois que j'ai eu à faire ce genre de chose je suis passé par la création d'interfaces "bidons" pour rouler des scripts propres au réseau.
 
Par contre, je pense pas que je le referai : des que tu sors du service network stop/start/restart, et que tu rentres dans des ifup/ifdown directement sur les interfaces, ça devient trop facile d'oublier la fameuse interface bidon ...

 
Nous on a un script rc.d qui fait ce genre de truc. Faut juste penser à tout réappliquer si tu reload le driver ou relance le réseau

C'est pour ça que j'avais fait une interface bidon : un service network restart et tout est appliqué. Par la suite j'étais tombe sur des softs qui faisaient des ifup ifdown ... Donc ça foutait un peu le truc en l'air.

 
ajoute  
 
ETHTOOL_OPTS="mesoptions"
 
à /etc/sysconfig/network et teste.

Merci à tous,

Effectivement je voyais que deux solutions que vous confirmé :
- script d'init "custom"
- /etc/rc.local

Rien d'intégré quoi

ps : ca va surement finir dans /etc/rc.local

Je vois pas pourquoi le ETHTOOL_OPTS ne fonctionne pas quand défini dans ifcfg-ethX, y a pas de raison, et c'est la solution à privilégier.

Car la commande voulue est la suivante :
    ethtool -K ethX  sg off tco off

Et dans les scripts rhel, ils font
    /sbin/ethtool -s ${REALDEVICE} $ETHTOOL_OPTS
Ce qui donne l'echec suivant :
    /sbin/ethtool -s eth1 -K ethX  sg off tco off

Je viens de voir que la possibilité de spécifier tous les paramètres possibles par ETHTOOL_OPTS vient d'apparaitre dans la rhel6.2 (cf le changelog du paquet initscript)

https://bugzilla.redhat.com/show_bug.cgi?id=519535
=> une soluce à base de règle udev
 
Sinon oui, y a une soluce pour les RH > 6, tu dois pouvoir backporter sans trop de soucis :
https://bugzilla.redhat.com/show_bug.cgi?id=692410
 
Et "au pire", si tu utilises pas le ETHTOOL_OPTS pour quoique ce soit d'autre, ben tu édite le script ifup et tu met -K à la place de -s.

Merci, je vais voir si je peux appliquer ces techniques dans le contexte d'ici ...

y a un problème avec ma solution ? C'est un fichier de configuration qui est là pour être configuré.

Relis les posts avant le tiens, tu verras bien le problème

non je ne le vois pas. tant pis.

Tu fais pas d'effort quand même

Bonjour à tous,
 
Auriez vous déjà effectué de "zero page reclaim" avec une baie faisant du thin provisionning (dans mon cas HDS) ?
 
Pour l'instant je vois que deux solutions :
- Utiliser un script écrivant des 0 sur l'ensemble des blocks libres (bourrin ; pas testé )
- Utiliser la fonction "discard" de l'ext4 (marqué comme nécessitant  plus de tests dans la doc kernel ... )
- Je regarde également du côté de LVM si qq chose pourrait etre fait ... (sans succès jusqu'à maintenant)
 
A+
 

Perso je suis un adepte du dd.
Mais on ne peut pas dire que je soit très fin comme garçon ...