Je voudrais voir quel débit j'ai en lecture sur un serveur.
Ceci en faisant abstraction de ce qui s'y connecte.
Mais en incluant l'accès disque, le serveur lui-même, la connextion
réseau et si possible le protocole.
J'ai tenté ceci :
time scp -qr folder_source autreServer.ici.ch:/dev/null/
Mais ça me dit :
scp: /dev/null/: Not a directory
Alors j'ai fait ça :
find source -type f -exec cat {} \; | ssh -l user server.ici.ch "dd
of=/dev/null" ; date
Qui semble fonctionner.
Mais ça prends pas en compte le protocole.
Conaissez vous un truc pour tester le débit en différents protocoles ?
(afp, cifs, rsync/ssh, scp, ...)
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la même chose que le FC, beaucoup de gens ont tendance à intervertir les deux termes) qui est une arnaque, c'est l'utilisation d'une architecture qui n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit s'adapter au besoin et non pas l'inverse.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la
même chose que le FC, beaucoup de gens ont tendance à intervertir les deux
termes) qui est une arnaque, c'est l'utilisation d'une architecture qui
n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit
s'adapter au besoin et non pas l'inverse.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la même chose que le FC, beaucoup de gens ont tendance à intervertir les deux termes) qui est une arnaque, c'est l'utilisation d'une architecture qui n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit s'adapter au besoin et non pas l'inverse.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
laurent.pertois
"fx [François-Xavier Peretmere]" wrote:
Ces questions me semblent porter sur aucun des deux cas, mais plutôt sur Xsan, le système de fichiers clusterisé d'Apple. Un SAN, c'est juste un réseau de données en mode bloc.
J'essaie de cerner ce qu'il a et effectivement j'ai visé le Xsan d'Apple qui est bien un FS clusterisé, mais il y a tellement de confusions, comme tu le relevais par ailleurs.
Mais je ne pense pas que Nicolas ait un Xsan.
Je pense plutôt que dans le cas de Nicolas, on a un bête cas de DAS sur son Xserve et son Xserve RAID.
Quant à la définition du SAN, j'y ajouterais le partage par plusieurs machines des mêmes ressources de stockage (baies de disque, bibliothèque de bandes...).
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Ces questions me semblent porter sur aucun des deux cas, mais plutôt sur
Xsan, le système de fichiers clusterisé d'Apple. Un SAN, c'est juste un
réseau de données en mode bloc.
J'essaie de cerner ce qu'il a et effectivement j'ai visé le Xsan d'Apple
qui est bien un FS clusterisé, mais il y a tellement de confusions,
comme tu le relevais par ailleurs.
Mais je ne pense pas que Nicolas ait un Xsan.
Je pense plutôt que dans le cas de Nicolas, on a un bête cas de DAS sur
son Xserve et son Xserve RAID.
Quant à la définition du SAN, j'y ajouterais le partage par plusieurs
machines des mêmes ressources de stockage (baies de disque, bibliothèque
de bandes...).
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
Ces questions me semblent porter sur aucun des deux cas, mais plutôt sur Xsan, le système de fichiers clusterisé d'Apple. Un SAN, c'est juste un réseau de données en mode bloc.
J'essaie de cerner ce qu'il a et effectivement j'ai visé le Xsan d'Apple qui est bien un FS clusterisé, mais il y a tellement de confusions, comme tu le relevais par ailleurs.
Mais je ne pense pas que Nicolas ait un Xsan.
Je pense plutôt que dans le cas de Nicolas, on a un bête cas de DAS sur son Xserve et son Xserve RAID.
Quant à la définition du SAN, j'y ajouterais le partage par plusieurs machines des mêmes ressources de stockage (baies de disque, bibliothèque de bandes...).
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
fx [François-Xavier Peretmere]
on the 6/06/08 0:43 Laurent Pertois wrote the following: ...
Je pense plutôt que dans le cas de Nicolas, on a un bête cas de DAS sur son Xserve et son Xserve RAID.
C'est mon impression aussi, mais il manque les détails sur tout le reste.
Quant à la définition du SAN, j'y ajouterais le partage par plusieurs machines des mêmes ressources de stockage (baies de disque, bibliothèque de bandes...).
On s'égare légèrement vers les plaisirs contre-nature et drosophiles, mais si le SAN permet cela, ce n'est pas une caractéristique intrinsèque. Le réseau SAN permet mais n'assure pas ce partage de ressource.
Plus spécifiquement, si on peut mettre des LUNs (que ce soit des "morceaux" de stockage disque ou des unités de bandes) à disposition de plusieurs serveurs, il faudra un mécanisme au-dessus pour gérer le partage de cette ressource. De ce point de vue, un SAN est "bête", et ne comprend pas les couches applicatives que sont NFS ou CIFS pour TCP/IP (je simplifie un poil).
Pour du stockage à accès aléatoire (disque), alors un système de fichiers dit clusterisé comme <pub> Xsan et StorNext </pub> qui joueront ce rôle. Pour des lecteurs de bandes, alors ce sera généralement une option d'un logiciel de sauvegarde qui l'assurera, <pub> tels l'option SSO de NetBackup ou le DDS de NetWorker. </pub>
On est limite fc.stockage là.
Fx
-- Stay the patient course. Of little worth is your ire; The network is down.
on the 6/06/08 0:43 Laurent Pertois wrote the following:
...
Je pense plutôt que dans le cas de Nicolas, on a un bête cas de DAS sur
son Xserve et son Xserve RAID.
C'est mon impression aussi, mais il manque les détails sur tout le reste.
Quant à la définition du SAN, j'y ajouterais le partage par plusieurs
machines des mêmes ressources de stockage (baies de disque, bibliothèque
de bandes...).
On s'égare légèrement vers les plaisirs contre-nature et drosophiles, mais
si le SAN permet cela, ce n'est pas une caractéristique intrinsèque. Le
réseau SAN permet mais n'assure pas ce partage de ressource.
Plus spécifiquement, si on peut mettre des LUNs (que ce soit des "morceaux"
de stockage disque ou des unités de bandes) à disposition de plusieurs
serveurs, il faudra un mécanisme au-dessus pour gérer le partage de cette
ressource. De ce point de vue, un SAN est "bête", et ne comprend pas les
couches applicatives que sont NFS ou CIFS pour TCP/IP (je simplifie un poil).
Pour du stockage à accès aléatoire (disque), alors un système de fichiers
dit clusterisé comme <pub> Xsan et StorNext </pub> qui joueront ce rôle.
Pour des lecteurs de bandes, alors ce sera généralement une option d'un
logiciel de sauvegarde qui l'assurera, <pub> tels l'option SSO de NetBackup
ou le DDS de NetWorker. </pub>
On est limite fc.stockage là.
Fx
--
Stay the patient course.
Of little worth is your ire;
The network is down.
on the 6/06/08 0:43 Laurent Pertois wrote the following: ...
Je pense plutôt que dans le cas de Nicolas, on a un bête cas de DAS sur son Xserve et son Xserve RAID.
C'est mon impression aussi, mais il manque les détails sur tout le reste.
Quant à la définition du SAN, j'y ajouterais le partage par plusieurs machines des mêmes ressources de stockage (baies de disque, bibliothèque de bandes...).
On s'égare légèrement vers les plaisirs contre-nature et drosophiles, mais si le SAN permet cela, ce n'est pas une caractéristique intrinsèque. Le réseau SAN permet mais n'assure pas ce partage de ressource.
Plus spécifiquement, si on peut mettre des LUNs (que ce soit des "morceaux" de stockage disque ou des unités de bandes) à disposition de plusieurs serveurs, il faudra un mécanisme au-dessus pour gérer le partage de cette ressource. De ce point de vue, un SAN est "bête", et ne comprend pas les couches applicatives que sont NFS ou CIFS pour TCP/IP (je simplifie un poil).
Pour du stockage à accès aléatoire (disque), alors un système de fichiers dit clusterisé comme <pub> Xsan et StorNext </pub> qui joueront ce rôle. Pour des lecteurs de bandes, alors ce sera généralement une option d'un logiciel de sauvegarde qui l'assurera, <pub> tels l'option SSO de NetBackup ou le DDS de NetWorker. </pub>
On est limite fc.stockage là.
Fx
-- Stay the patient course. Of little worth is your ire; The network is down.
laurent.pertois
"fx [François-Xavier Peretmere]" wrote:
On s'égare légèrement vers les plaisirs contre-nature et drosophiles, mais si le SAN permet cela, ce n'est pas une caractéristique intrinsèque. Le réseau SAN permet mais n'assure pas ce partage de ressource.
Yep.
Plus spécifiquement, si on peut mettre des LUNs (que ce soit des "morceaux" de stockage disque ou des unités de bandes) à disposition de plusieurs serveurs, il faudra un mécanisme au-dessus pour gérer le partage de cette ressource. De ce point de vue, un SAN est "bête", et ne comprend pas les couches applicatives que sont NFS ou CIFS pour TCP/IP (je simplifie un poil).
Pour du stockage à accès aléatoire (disque), alors un système de fichiers dit clusterisé comme <pub> Xsan et StorNext </pub> qui joueront ce rôle. Pour des lecteurs de bandes, alors ce sera généralement une option d'un logiciel de sauvegarde qui l'assurera, <pub> tels l'option SSO de NetBackup ou le DDS de NetWorker. </pub>
Que tout cela est si bien dit ;-)
On est limite fc.stockage là.
Participons à l'édification des masses.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
On s'égare légèrement vers les plaisirs contre-nature et drosophiles, mais
si le SAN permet cela, ce n'est pas une caractéristique intrinsèque. Le
réseau SAN permet mais n'assure pas ce partage de ressource.
Yep.
Plus spécifiquement, si on peut mettre des LUNs (que ce soit des "morceaux"
de stockage disque ou des unités de bandes) à disposition de plusieurs
serveurs, il faudra un mécanisme au-dessus pour gérer le partage de cette
ressource. De ce point de vue, un SAN est "bête", et ne comprend pas les
couches applicatives que sont NFS ou CIFS pour TCP/IP (je simplifie un poil).
Pour du stockage à accès aléatoire (disque), alors un système de fichiers
dit clusterisé comme <pub> Xsan et StorNext </pub> qui joueront ce rôle.
Pour des lecteurs de bandes, alors ce sera généralement une option d'un
logiciel de sauvegarde qui l'assurera, <pub> tels l'option SSO de NetBackup
ou le DDS de NetWorker. </pub>
Que tout cela est si bien dit ;-)
On est limite fc.stockage là.
Participons à l'édification des masses.
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
On s'égare légèrement vers les plaisirs contre-nature et drosophiles, mais si le SAN permet cela, ce n'est pas une caractéristique intrinsèque. Le réseau SAN permet mais n'assure pas ce partage de ressource.
Yep.
Plus spécifiquement, si on peut mettre des LUNs (que ce soit des "morceaux" de stockage disque ou des unités de bandes) à disposition de plusieurs serveurs, il faudra un mécanisme au-dessus pour gérer le partage de cette ressource. De ce point de vue, un SAN est "bête", et ne comprend pas les couches applicatives que sont NFS ou CIFS pour TCP/IP (je simplifie un poil).
Pour du stockage à accès aléatoire (disque), alors un système de fichiers dit clusterisé comme <pub> Xsan et StorNext </pub> qui joueront ce rôle. Pour des lecteurs de bandes, alors ce sera généralement une option d'un logiciel de sauvegarde qui l'assurera, <pub> tels l'option SSO de NetBackup ou le DDS de NetWorker. </pub>
Que tout cela est si bien dit ;-)
On est limite fc.stockage là.
Participons à l'édification des masses.
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
Thierry B.
--{ Michel Nicolas Alex a plopé ceci: }--
Argh, bon sang, il faut être root pour envoyer du taff sur /dev/null C'est pour ça que ça ne voulait pas <:o)
Je ne pense pas, ton système doit avoir un _gros_ souci,
si c'est le cas.
--
Tant qu'on a pas (essayer d') utiliser vi, on ne connait rien de la souffrance humaine. Et pour comprendre la souffrance d'une machine il faut avoir installé emacs.
--{ Michel Nicolas Alex a plopé ceci: }--
Argh, bon sang, il faut être root pour envoyer du taff sur /dev/null
C'est pour ça que ça ne voulait pas <:o)
Je ne pense pas, ton système doit avoir un _gros_ souci,
si c'est le cas.
--
Tant qu'on a pas (essayer d') utiliser vi, on ne connait rien
de la souffrance humaine.
Et pour comprendre la souffrance d'une machine il faut avoir installé emacs.
Argh, bon sang, il faut être root pour envoyer du taff sur /dev/null C'est pour ça que ça ne voulait pas <:o)
Je ne pense pas, ton système doit avoir un _gros_ souci,
si c'est le cas.
--
Tant qu'on a pas (essayer d') utiliser vi, on ne connait rien de la souffrance humaine. Et pour comprendre la souffrance d'une machine il faut avoir installé emacs.
Nicolas-Michel_REMOVE
"fx [François-Xavier Peretmere]" wrote:
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la même chose que le FC, beaucoup de gens ont tendance à intervertir les deux termes) qui est une arnaque, c'est l'utilisation d'une architecture qui n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit s'adapter au besoin et non pas l'inverse.
Toutes mes confuses à toute l'équipe, je chauffe un peu quand je suis confronté à un truc que je ne maitrise pas.
Mais bref, je sort d'un jour de formation sur le sujet et j'ai les idées un peu plus clair.
Ce que tu dis ici résume probablement mon problème : Notre infrastructure réseau gigabit est sans-doute le goulet. Quand je compare nos divers serveurs, NAS, DAS ou autre, les résultats sont similaires parce que ils sont tous plus performants que ce qui les relient entre eux ou aux utilisateurs. Il faut que je discute avec l'équipe réseau pour valider la chose et trouver des solutions.
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la
même chose que le FC, beaucoup de gens ont tendance à intervertir les deux
termes) qui est une arnaque, c'est l'utilisation d'une architecture qui
n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit
s'adapter au besoin et non pas l'inverse.
Toutes mes confuses à toute l'équipe, je chauffe un peu quand je suis
confronté à un truc que je ne maitrise pas.
Mais bref, je sort d'un jour de formation sur le sujet et j'ai les idées
un peu plus clair.
Ce que tu dis ici résume probablement mon problème :
Notre infrastructure réseau gigabit est sans-doute le goulet.
Quand je compare nos divers serveurs, NAS, DAS ou autre, les résultats
sont similaires parce que ils sont tous plus performants que ce qui les
relient entre eux ou aux utilisateurs.
Il faut que je discute avec l'équipe réseau pour valider la chose et
trouver des solutions.
Le FC c'est du FC. Ce n'est pas le FC (ou un SAN, même si ce n'est pas la même chose que le FC, beaucoup de gens ont tendance à intervertir les deux termes) qui est une arnaque, c'est l'utilisation d'une architecture qui n'est pas adapté au besoin. Bis repetita, c'est l'architecture qui doit s'adapter au besoin et non pas l'inverse.
Toutes mes confuses à toute l'équipe, je chauffe un peu quand je suis confronté à un truc que je ne maitrise pas.
Mais bref, je sort d'un jour de formation sur le sujet et j'ai les idées un peu plus clair.
Ce que tu dis ici résume probablement mon problème : Notre infrastructure réseau gigabit est sans-doute le goulet. Quand je compare nos divers serveurs, NAS, DAS ou autre, les résultats sont similaires parce que ils sont tous plus performants que ce qui les relient entre eux ou aux utilisateurs. Il faut que je discute avec l'équipe réseau pour valider la chose et trouver des solutions.
Merci à tous -- Nicolas Michel
patpro ~ Patrick Proniewski
In article <1ii4jat.jmm9bz1p47oriN%, (Michel Nicolas Alex) wrote:
Il faut que je discute avec l'équipe réseau pour valider la chose et trouver des solutions.
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes serveurs de fichiers disposent d'une bande passante plus grande. C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch dignes de ce nom supporte ça.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article
<1ii4jat.jmm9bz1p47oriN%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
Il faut que je discute avec l'équipe réseau pour valider la chose et
trouver des solutions.
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes
serveurs de fichiers disposent d'une bande passante plus grande.
C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch
dignes de ce nom supporte ça.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <1ii4jat.jmm9bz1p47oriN%, (Michel Nicolas Alex) wrote:
Il faut que je discute avec l'équipe réseau pour valider la chose et trouver des solutions.
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes serveurs de fichiers disposent d'une bande passante plus grande. C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch dignes de ce nom supporte ça.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Nicolas-Michel_REMOVE
patpro ~ Patrick Proniewski wrote:
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes serveurs de fichiers disposent d'une bande passante plus grande. C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch dignes de ce nom supporte ça.
C'est clair. Après, entre une solution technique "simple" et sa mise en oeuvre dans une structure complexe, il y a parfois des nuances.
Bon, je vais me renseigner
Merci encore
-- Nicolas Michel
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes
serveurs de fichiers disposent d'une bande passante plus grande.
C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch
dignes de ce nom supporte ça.
C'est clair.
Après, entre une solution technique "simple" et sa mise en oeuvre dans
une structure complexe, il y a parfois des nuances.
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes serveurs de fichiers disposent d'une bande passante plus grande. C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch dignes de ce nom supporte ça.
C'est clair. Après, entre une solution technique "simple" et sa mise en oeuvre dans une structure complexe, il y a parfois des nuances.
Bon, je vais me renseigner
Merci encore
-- Nicolas Michel
patpro ~ Patrick Proniewski
In article <1ii9iik.i51slx1qlmmv4N%, (Michel Nicolas Alex) wrote:
patpro ~ Patrick Proniewski wrote:
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes serveurs de fichiers disposent d'une bande passante plus grande. C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch dignes de ce nom supporte ça.
C'est clair. Après, entre une solution technique "simple" et sa mise en oeuvre dans une structure complexe, il y a parfois des nuances.
si tu as de la chance :
- un cable par port réseau du serveur, branchés sur le même switch. - 2 ou 3 cliques dans les pref réseau du serveur.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article
<1ii9iik.i51slx1qlmmv4N%Nicolas-Michel_REMOVE@THIS_bluewin.ch>,
Nicolas-Michel_REMOVE@THIS_bluewin.ch (Michel Nicolas Alex) wrote:
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes
serveurs de fichiers disposent d'une bande passante plus grande.
C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch
dignes de ce nom supporte ça.
C'est clair.
Après, entre une solution technique "simple" et sa mise en oeuvre dans
une structure complexe, il y a parfois des nuances.
si tu as de la chance :
- un cable par port réseau du serveur, branchés sur le même switch.
- 2 ou 3 cliques dans les pref réseau du serveur.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <1ii9iik.i51slx1qlmmv4N%, (Michel Nicolas Alex) wrote:
patpro ~ Patrick Proniewski wrote:
déjà, tu dois pouvoir agréger des ports Gigabits pour que ton ou tes serveurs de fichiers disposent d'une bande passante plus grande. C'est pas hyper sorcier, surtout sur Mac OS X, et la majorité des switch dignes de ce nom supporte ça.
C'est clair. Après, entre une solution technique "simple" et sa mise en oeuvre dans une structure complexe, il y a parfois des nuances.
si tu as de la chance :
- un cable par port réseau du serveur, branchés sur le même switch. - 2 ou 3 cliques dans les pref réseau du serveur.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
laurent.pertois
patpro ~ Patrick Proniewski wrote:
si tu as de la chance :
- un cable par port réseau du serveur, branchés sur le même switch. - 2 ou 3 cliques dans les pref réseau du serveur.
Oui, mais pas obligé que ce soit sur le même switch, l'autre jour dans une université le Xserve a été relié à deux switchs différents et ces derniers configurés pour faire de l'aggrégation, ça permettait aussi d'assurer la redondance, en cas de perte d'un switch la machine était toujours accessible.
Par contre, c'est l'équipe réseau qui a fait ça, ils étaient 2 sur la config des Cisco et moi je me contentais de dire "rouge"... "rouge"... "vert, ne touchez plus à rien, en plus j'ai récupéré l'adresse via DHCP".
Bon, on a perdu le LOM quand même... :-/
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
si tu as de la chance :
- un cable par port réseau du serveur, branchés sur le même switch.
- 2 ou 3 cliques dans les pref réseau du serveur.
Oui, mais pas obligé que ce soit sur le même switch, l'autre jour dans
une université le Xserve a été relié à deux switchs différents et ces
derniers configurés pour faire de l'aggrégation, ça permettait aussi
d'assurer la redondance, en cas de perte d'un switch la machine était
toujours accessible.
Par contre, c'est l'équipe réseau qui a fait ça, ils étaient 2 sur la
config des Cisco et moi je me contentais de dire "rouge"... "rouge"...
"vert, ne touchez plus à rien, en plus j'ai récupéré l'adresse via
DHCP".
Bon, on a perdu le LOM quand même... :-/
--
Politically Correct Unix - UTILITIES
The "touch" command has been removed from the standard distribution due
to its inappropriate use by high-level managers.
- un cable par port réseau du serveur, branchés sur le même switch. - 2 ou 3 cliques dans les pref réseau du serveur.
Oui, mais pas obligé que ce soit sur le même switch, l'autre jour dans une université le Xserve a été relié à deux switchs différents et ces derniers configurés pour faire de l'aggrégation, ça permettait aussi d'assurer la redondance, en cas de perte d'un switch la machine était toujours accessible.
Par contre, c'est l'équipe réseau qui a fait ça, ils étaient 2 sur la config des Cisco et moi je me contentais de dire "rouge"... "rouge"... "vert, ne touchez plus à rien, en plus j'ai récupéré l'adresse via DHCP".
Bon, on a perdu le LOM quand même... :-/
-- Politically Correct Unix - UTILITIES The "touch" command has been removed from the standard distribution due to its inappropriate use by high-level managers.
