J'avais déjà mis ONBOOT à no dans mes fichiers mais je cherchais l'option ONPARENT que je n'avais pas trouvé jusque là. C'est exactement ce que je cherchais.
Encore merci (et en effet je suis sous redhat donc dans /etc/sysconfig/network-scripts)
NeoX>L'idée d'heartbeat est bonne (je ne la connaissais pas d'ailleurs) malheureusement, le temps me manque et pour le moment il me faut quelque chose de facile et fonctionnel très rapidement, il ne me manquait plus que cette information. A termes en revanche ça peut être une bonne solution néanmoins sais-tu si tu l'on peut désactiver le HA pendant une période de sauvegarde par exemple hormis via la crontab ?
oui mes alias sont définis via un fichier ifcfg-eth2:N.
En fait, ils sont créés sur un machine A ou B puis un script de synchro va les transférer (avec modification de l'adresse MAC) sur l'autre machine (A vers B ou B vers A). Les deux machines sont actives. Comme je le dis dans mon premier post, je voudrais pouvoir activer l'interface principale sans activer certains alias. Je préfère créer l'alias de l'instance et l'activer via un script quand nécessaire plutôt que de le créer quand l'instance tombe de l'autre bord. En effet, ce n'est pas forcément moi qui effectuera la bascule en cas de problème et celui qui la fera n'aura pas forcément les compétences Linux nécessaires. Il faut donc que ce soit simplifié un maximum.
Si j'arrive à activer/désactiver l'alias à souhait, la personne en charge de la bascule n'aura que 3 étapes à effectuer : désactivation sur A, inversement du miroir de LUN et activation sur B.
Je trouve que les participants de ce forum sont super compétents. Sur mon premier problème (extension d'un PV suite à une extension de LUN sur SAN), j'ai obtenu une réponse après laquelle je courrais depuis plusieurs semaines sur le net.
Pour en revenir à mon problème, l'inconvénient d'heartbeat est qu'il va me faire une bascule des ressources alors que je n'aurai pas fait la bascule SAN. Ou alors je peux n'utiliser heartbeat que pour ma bascule réseau et garder le reste en manuel. Dans ce cas là c'est contraignant de le mettre en place juste pour ça, je pense que c'est autant ne pas créer mes alias sur ma seconde machine, et les créer juste quand j'en ai besoin.
Dans ma dernière phrase il manque le mot ressources :
"Heartbeat gèrerait correctement ces scripts mais activerait les ressources sur la 2nde machine avant même la bascule de mes LUNS ce qui potentiellement peut entrainer des incohérences, non?"
En fait, c'est pour faire du clustering Oracle, je m'explique.
J'ai une instance associé avec un listener qui est lui même associé à une IP virtuelle. Les fichiers de mon instance sont sur un filesystem dédié géré en LVM. L'instance a donc un VG dédié qui est sur une LUN dédié sur notre SAN.
Pour activer/désactiver les ressources de cette instance (IP, VG et filesystems), j'ai créé les scripts nécessaires qui fonctionnent nickel.
La LUN dédiée est mirorrée sur notre SAN avec une LUN dédiée du second serveur.
Je ne sais pas comment gérer ma bascule de LUN dans le cas d'Heartbeat. En effet, je comptais la gérer à la mano car mes ressources sont finalement gérés à la mano. Heartbeat gèrerait correctement ces scripts mais activerait sur la 2nde machine avant même la bascule de mes LUNS non ?
c'est de la balle ton premier lien, ça m'a permis de faire exactement ce que je voulais, je vais pouvoir agrandir dans tous les sens maintenant ! (pas de mauvaises pensées hein !)
@Amand Tihon>tes 1ère et 3ème commande sont utiles, tu étais dans le vrai, merci.
J'ai peur que ma question n'ait pas été vue correctement :
En revanche, je suis obligé du coup de créer avec fdisk une seconde partition primaire, /dev/emcpowerl2, ou puis-je étendre ma première partition /dev/emcpowerl1 ?
totof>Les LUN varient de 5Go à 600Go. Mais en ce qui me concerne je préfère avoir une LUN par instance Oracle, au moins je sais tout de suite sur laquelle elle se trouve. Nous utilisons Navisphere.
Je pense que la piste est bonne. En ce qui concerne le rescan je l'avais déjà tenté, c'est ce qui est indiqué dans le lien fourni dans mon premier post d'ailleurs. En revanche, la commande blockdev m'a permis de mettre une info intéressante à jour :
On remarque que la nouvelle taille disque a bien été prise en compte au niveau partition physique. En revanche, je suis obligé du coup de créer avec fdisk une seconde partition primaire, /dev/emcpowerl2, ou puis-je étendre ma première partition /dev/emcpowerl1 ?
Merci en tout cas pour le coup de main car ça fait 3 mois que je tape à plusieurs portes et je n'ai pas eu de réponse concrète pour le moment (et c'est super bloquant).
Nous le faisons très bien "à chaud" sur des AIX 5.3 avec la commande cfgmgr. En revanche, impossible sur redhat de lui faire comprendre que le PV a changé de situation et tnat que mon PV n'est pas étendu, je ne peux pas étendre mes LVs associés.
Il est à noter également que nous le faisons sur un environnement de production et donc que nous ne pouvons pas (ou du moins il faut éviter) faire un reboot de la machine. En effet, de nombreuses bases de données y sont présentes.
Pour finir, nous préférons de loin étendre une LUN plutôt de d'en créer une autre pour la même fonctionnalité, car nous en avons environ 180 à gérer ce qui représente une grosse volumétrie
[^] # Merci beaucoup !
Posté par tck . En réponse au message [RHEL 4.8] Ne monter que l'interface et non ses alias IP associés. Évalué à 1.
Merci beaucoup JJD.
J'avais déjà mis ONBOOT à no dans mes fichiers mais je cherchais l'option ONPARENT que je n'avais pas trouvé jusque là. C'est exactement ce que je cherchais.
Encore merci (et en effet je suis sous redhat donc dans /etc/sysconfig/network-scripts)
NeoX>L'idée d'heartbeat est bonne (je ne la connaissais pas d'ailleurs) malheureusement, le temps me manque et pour le moment il me faut quelque chose de facile et fonctionnel très rapidement, il ne me manquait plus que cette information. A termes en revanche ça peut être une bonne solution néanmoins sais-tu si tu l'on peut désactiver le HA pendant une période de sauvegarde par exemple hormis via la crontab ?
[^] # Re: Suite
Posté par tck . En réponse au message [RHEL 4.8] Ne monter que l'interface et non ses alias IP associés. Évalué à 1.
oui mes alias sont définis via un fichier ifcfg-eth2:N.
En fait, ils sont créés sur un machine A ou B puis un script de synchro va les transférer (avec modification de l'adresse MAC) sur l'autre machine (A vers B ou B vers A). Les deux machines sont actives. Comme je le dis dans mon premier post, je voudrais pouvoir activer l'interface principale sans activer certains alias. Je préfère créer l'alias de l'instance et l'activer via un script quand nécessaire plutôt que de le créer quand l'instance tombe de l'autre bord. En effet, ce n'est pas forcément moi qui effectuera la bascule en cas de problème et celui qui la fera n'aura pas forcément les compétences Linux nécessaires. Il faut donc que ce soit simplifié un maximum.
Si j'arrive à activer/désactiver l'alias à souhait, la personne en charge de la bascule n'aura que 3 étapes à effectuer : désactivation sur A, inversement du miroir de LUN et activation sur B.
[^] # Re: Suite
Posté par tck . En réponse au message [RHEL 4.8] Ne monter que l'interface et non ses alias IP associés. Évalué à 1.
Merci !
Je trouve que les participants de ce forum sont super compétents. Sur mon premier problème (extension d'un PV suite à une extension de LUN sur SAN), j'ai obtenu une réponse après laquelle je courrais depuis plusieurs semaines sur le net.
Pour en revenir à mon problème, l'inconvénient d'heartbeat est qu'il va me faire une bascule des ressources alors que je n'aurai pas fait la bascule SAN. Ou alors je peux n'utiliser heartbeat que pour ma bascule réseau et garder le reste en manuel. Dans ce cas là c'est contraignant de le mettre en place juste pour ça, je pense que c'est autant ne pas créer mes alias sur ma seconde machine, et les créer juste quand j'en ai besoin.
[^] # Re: Suite
Posté par tck . En réponse au message [RHEL 4.8] Ne monter que l'interface et non ses alias IP associés. Évalué à -1.
(On ne peut pas éditer un post sur linuxfr ?)
Dans ma dernière phrase il manque le mot ressources :
"Heartbeat gèrerait correctement ces scripts mais activerait les ressources sur la 2nde machine avant même la bascule de mes LUNS ce qui potentiellement peut entrainer des incohérences, non?"
# Suite
Posté par tck . En réponse au message [RHEL 4.8] Ne monter que l'interface et non ses alias IP associés. Évalué à 0.
Merci déjà pour vos 2 messages.
En fait, c'est pour faire du clustering Oracle, je m'explique.
J'ai une instance associé avec un listener qui est lui même associé à une IP virtuelle. Les fichiers de mon instance sont sur un filesystem dédié géré en LVM. L'instance a donc un VG dédié qui est sur une LUN dédié sur notre SAN.
Pour activer/désactiver les ressources de cette instance (IP, VG et filesystems), j'ai créé les scripts nécessaires qui fonctionnent nickel.
La LUN dédiée est mirorrée sur notre SAN avec une LUN dédiée du second serveur.
Je ne sais pas comment gérer ma bascule de LUN dans le cas d'Heartbeat. En effet, je comptais la gérer à la mano car mes ressources sont finalement gérés à la mano. Heartbeat gèrerait correctement ces scripts mais activerait sur la 2nde machine avant même la bascule de mes LUNS non ?
[^] # Re: Il me semble que ce soit possible ....
Posté par tck . En réponse au message Extension LVM dans environnement SAN. Évalué à 1.
@Amand Tihon>tes 1ère et 3ème commande sont utiles, tu étais dans le vrai, merci.
[^] # Re: Il me semble que ce soit possible ....
Posté par tck . En réponse au message Extension LVM dans environnement SAN. Évalué à 1.
En revanche, je suis obligé du coup de créer avec fdisk une seconde partition primaire, /dev/emcpowerl2, ou puis-je étendre ma première partition /dev/emcpowerl1 ?
totof>Les LUN varient de 5Go à 600Go. Mais en ce qui me concerne je préfère avoir une LUN par instance Oracle, au moins je sais tout de suite sur laquelle elle se trouve. Nous utilisons Navisphere.
[^] # Re: Il me semble que ce soit possible ....
Posté par tck . En réponse au message Extension LVM dans environnement SAN. Évalué à 1.
[root@XXX bin]# blockdev --getsize /dev/emcpowerl1
10477194
[root@XXX bin]# blockdev --getsize /dev/emcpowerl
12582912
On remarque que la nouvelle taille disque a bien été prise en compte au niveau partition physique. En revanche, je suis obligé du coup de créer avec fdisk une seconde partition primaire, /dev/emcpowerl2, ou puis-je étendre ma première partition /dev/emcpowerl1 ?
Merci en tout cas pour le coup de main car ça fait 3 mois que je tape à plusieurs portes et je n'ai pas eu de réponse concrète pour le moment (et c'est super bloquant).
Bonne soirée et à demain.
[^] # Re: Il me semble que ce soit possible ....
Posté par tck . En réponse au message Extension LVM dans environnement SAN. Évalué à 1.
Nous le faisons très bien "à chaud" sur des AIX 5.3 avec la commande cfgmgr. En revanche, impossible sur redhat de lui faire comprendre que le PV a changé de situation et tnat que mon PV n'est pas étendu, je ne peux pas étendre mes LVs associés.
Il est à noter également que nous le faisons sur un environnement de production et donc que nous ne pouvons pas (ou du moins il faut éviter) faire un reboot de la machine. En effet, de nombreuses bases de données y sont présentes.
Pour finir, nous préférons de loin étendre une LUN plutôt de d'en créer une autre pour la même fonctionnalité, car nous en avons environ 180 à gérer ce qui représente une grosse volumétrie