11
Versch. IP-Adressen je Rechner, Client bzw. Server mit Openfiler (rPath Linux)
Hallo zusammen,
als Linux- Anfänger und Forums-Neuling habe ich ein Problem und hoffe auf Eure Hilfe. Da ich schon lange inkognito im Forum stöbere, habe ich das Gefühl, hier richtig zu sein. Nun zu meinem Problem:
Ich betreibe einen Openfiler-Server unter rPath-Linux mit insgesamt 4 Netzwerkschnittstellen (zwei Karten je zwei Anschlüsse). Zwei Schnittstellen hatte ich bzw. möchte ich wieder per Round Robin Bonding zusammenschalten (Verbindung geht über einen konfigurierbaren Layer-3-Switch). Das frühere Bonding habe ich zwecks Reorganisation aufgelöst (unter ifconfig bond0 ist jedoch noch ein Eintrag aber ohne Werte vorhanden). Ein Anschluss wäre übrig (könnte evtl. später noch ins Round Robin eingebunden werden), ein weiterer Anschluss sollte eine direkte Verbindung per Crossover Kabel zum Arbeitsrechner für eine ISCSI-Verbindung herstellen. Somit sind im Arbeitsrechner (W-XP) auch zwei Schnittstellen vorhanden.
Die Server-IP-Konfiguration ist folgende:
Anschluss 1: 192.168.1.1 Subnet 255.255.255.0 Gateway 192.168.1.100
Anschluss 2: 192.168.1.2 Subnet dto.
Anschluss 3: 192.168.1.3 dto.
Anschluss 4: 192.168.2.4 Subnet 255.255.255.0 Gateway 192.168.2.10 (per Crossover Kabel direkt)
Arbeitsrechner:
Anschluss 1: 192.168.1.10 Subnet 255.255.255.0 Gateway 192.168.1.100
Anschluss 2: 192.168.2.10 Subnet 255.255.255.0 Gateway 192.168.2.10 (per Crossover Kabel direkt)
Jetzt habe ich folgende Situation:
Ping vom Arbeitsrechner auf physikalischen Anschluss 1 mit IP .....1.1 klappt, gleiches gilt für die IP´s ....1.2 und ....1.3 --- das dürfte doch schon mal gar nicht gehen?
Ping vom Arbeitsrechner auf physikalischen Anschluss 2 bzw. 3 geht mit keiner IP --- beim booten werden alle 4 Schnittstellen korrekt mit ok angezeigt, der ifconfig zeigt überalle die korrekten Einstellungen, ein ifconfig bond0 ist zwar vorhanden, zeigt aber keine IP, Netmask (0.0.0.0) bzw. Gateway
Ping vom Arbeitsrechner auf physikalischen Anschluss 4 geht nicht. Auch der Ping vom Server zu AP-Rechner geht nicht (ich kann beim ping ja nicht anwählen, über welche physik. Karte er gehen soll).
Ping vom Server zum AP-Rechner ......1.10 geht, nicht aber auf 2.10 .
Was mache ich falsch?
Kann es sein, dass das früher vorhandene bonding nicht korrekt aufgelöst ist? Befehl war ifconfig del bond0 (Syntax korrekt eingegeben lt. rPath Hilfe)
Darüber hinaus habe ich noch alle Netzwerkanschlüsse im Bios deaktiviert bzw. abgesteckt, gebootet und wieder runtergefahren, anschließend alle wieder aktiviert.
Oder habe ich irgendwo etwas falsch gemacht? Wie ginge es korrekt?
Oder liegt es evtl. sogar an einem IRQ-Problem (kann ich mir bei einer aktuellen Hardwareausstattung jedoch kaum mehr vorstellen)
Schon mal vorab vielen Dank für Eure Hilfe
Grüße Oliver
Die Server-IP-Konfiguration ist folgende:
Anschluss 1: 192.168.1.1 Subnet 255.255.255.0 Gateway 192.168.1.100
Anschluss 2: 192.168.1.2 Subnet dto.
Anschluss 3: 192.168.1.3 dto.
Anschluss 4: 192.168.2.4 Subnet 255.255.255.0 Gateway 192.168.2.10 (per Crossover Kabel direkt)
Arbeitsrechner:
Anschluss 1: 192.168.1.10 Subnet 255.255.255.0 Gateway 192.168.1.100
Anschluss 2: 192.168.2.10 Subnet 255.255.255.0 Gateway 192.168.2.10 (per Crossover Kabel direkt)
Jetzt habe ich folgende Situation:
Ping vom Arbeitsrechner auf physikalischen Anschluss 1 mit IP .....1.1 klappt, gleiches gilt für die IP´s ....1.2 und ....1.3 --- das dürfte doch schon mal gar nicht gehen?
Ping vom Arbeitsrechner auf physikalischen Anschluss 2 bzw. 3 geht mit keiner IP --- beim booten werden alle 4 Schnittstellen korrekt mit ok angezeigt, der ifconfig zeigt überalle die korrekten Einstellungen, ein ifconfig bond0 ist zwar vorhanden, zeigt aber keine IP, Netmask (0.0.0.0) bzw. Gateway
Ping vom Arbeitsrechner auf physikalischen Anschluss 4 geht nicht. Auch der Ping vom Server zu AP-Rechner geht nicht (ich kann beim ping ja nicht anwählen, über welche physik. Karte er gehen soll).
Ping vom Server zum AP-Rechner ......1.10 geht, nicht aber auf 2.10 .
Was mache ich falsch?
Kann es sein, dass das früher vorhandene bonding nicht korrekt aufgelöst ist? Befehl war ifconfig del bond0 (Syntax korrekt eingegeben lt. rPath Hilfe)
Darüber hinaus habe ich noch alle Netzwerkanschlüsse im Bios deaktiviert bzw. abgesteckt, gebootet und wieder runtergefahren, anschließend alle wieder aktiviert.
Oder habe ich irgendwo etwas falsch gemacht? Wie ginge es korrekt?
Oder liegt es evtl. sogar an einem IRQ-Problem (kann ich mir bei einer aktuellen Hardwareausstattung jedoch kaum mehr vorstellen)
Schon mal vorab vielen Dank für Eure Hilfe
Grüße Oliver
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 134411
Url: https://administrator.de/contentid/134411
Printed on: April 19, 2024 at 23:04 o'clock
11 Comments
Latest comment
Wieso sollte ein Ping vom Arbeitsrechner auf .1.1, .1.2 und .1.3 nicht gehen ?? Alle Geräte befinden sich doch im gleichen IP Netzwerk und da ist es doch mehr als logisch das da auch ein Ping funktioniert.
Einen kardinalsfehler hast du in deiner Konfiguration:
Du darfst keine 2 Default Gateways auf dem Arbeitsrechner definieren. Windows kann da nicht mit umgehen. Wie auch, denn es kann immer nur ein Default Gateway gehen !! Das dann noch das eingestellte Gateway an NIC 2 auf die eigene IP zeigt ist natürlich totaler Blödsinn !! Das gehört da entfernt !
Der Arbeitsrechner "kennt" ja logischerweise bei IP Netze .1.0 und .2.0 da sie direkt an ihm angeschlossen sind...Gateways sind da dann logischerweise überflüssig. Damit findet der Arbeitsrechner dann logischerweise auch dir richtige NIC ! Ein Traceroute (tracert) oder Pathping auf die Ziel IP bestätigt das dir sofort.
Du solltest also nur, und wirklich nur an der NIC an der auch ein Internet Router ist ein def. Gateway eingestellt haben. Vermutlich also NIC 1 mit der .1.100 ?!
Bei der anderen NIC bleibt Gateway und DNS Eintrag leer !! Dort steht nur IP und Maske...mehr nicht !!
Das fixt vermutlich schon dein Problem, denn ein Ping vom Arbeitsrechner in beide IP Netze .1.0 /24 und .2.0 /24 sollte natürlich problemlos möglich sein !!
Was dein Bonding (Link Aggregation) Problem anbetrifft kannst du das leicht checken. Ein arp -a zeigt dir an ob alle 1er IPs am Server separate Mac Adressen benutzen. Sind sie das gibts kein Bonding mehr.
Welche Vorgaben du beim Bonding, Teaming bzw. Link Aggregation beachten musst kannst du in diesen Threads nachlesen !!
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Einen kardinalsfehler hast du in deiner Konfiguration:
Du darfst keine 2 Default Gateways auf dem Arbeitsrechner definieren. Windows kann da nicht mit umgehen. Wie auch, denn es kann immer nur ein Default Gateway gehen !! Das dann noch das eingestellte Gateway an NIC 2 auf die eigene IP zeigt ist natürlich totaler Blödsinn !! Das gehört da entfernt !
Der Arbeitsrechner "kennt" ja logischerweise bei IP Netze .1.0 und .2.0 da sie direkt an ihm angeschlossen sind...Gateways sind da dann logischerweise überflüssig. Damit findet der Arbeitsrechner dann logischerweise auch dir richtige NIC ! Ein Traceroute (tracert) oder Pathping auf die Ziel IP bestätigt das dir sofort.
Du solltest also nur, und wirklich nur an der NIC an der auch ein Internet Router ist ein def. Gateway eingestellt haben. Vermutlich also NIC 1 mit der .1.100 ?!
Bei der anderen NIC bleibt Gateway und DNS Eintrag leer !! Dort steht nur IP und Maske...mehr nicht !!
Das fixt vermutlich schon dein Problem, denn ein Ping vom Arbeitsrechner in beide IP Netze .1.0 /24 und .2.0 /24 sollte natürlich problemlos möglich sein !!
Was dein Bonding (Link Aggregation) Problem anbetrifft kannst du das leicht checken. Ein arp -a zeigt dir an ob alle 1er IPs am Server separate Mac Adressen benutzen. Sind sie das gibts kein Bonding mehr.
Welche Vorgaben du beim Bonding, Teaming bzw. Link Aggregation beachten musst kannst du in diesen Threads nachlesen !!
Motherboard mit 2 Onboard LAN Anschlüssen
Traffic am Server auf 2 NICs verteilen
Kann man einen Server zur Performacesteigerung mit 2 Netzwerkkarten parallel an einem Switch betreiben? Wenn ja mit welcher Konfiguration ?
Bonding mit Broadcom - SLB
Hallo,
@aqui
hast du Links auswendig im Kopf, oder ein gut sortiertes Archiv ??
@kyboyeti
Wieso eingentlich dieser total verquere Netzaufbau mit Crossover Kabeln wenn du einen Layer 3 Switch verwendest?
Ein Netzwerk aufzubauen und anschließend mit Corssover Verkabelung und "unorthodoxer" IP Adressierung das wieder zerstören kann ich nicht nachvollziehen!
Wenn du ein Trennung deiner Netze, die durch das dritte Oktet deiner IP Adressierung vornimmst, sauber aufbauen willst solltest du dir Gedanken machen über ein anständiges VLAN Konzept.
Du hast, wenn ich dein Netzwerk richtig verstehe, 3 Geräte Kategorien.
1. Kategorie = Server
2. Kategorie = Clients
3. Kategorie = Crossover Verbindungen (deren Sinn sich mir nicht erschließt)
Das kann man mit 3 VLANs und normaler Verkabelung machen und dabei sogar noch Redundanzen aufbauen.
Die Trunks oder Link Aggregation kombiniert mit einem PVST und neben einer Ausfall sicheren redundanz hast du durch das Trunking auch noch eine höhere Geschwindigkeit.
brammer
@aqui
hast du Links auswendig im Kopf, oder ein gut sortiertes Archiv ??
@kyboyeti
Wieso eingentlich dieser total verquere Netzaufbau mit Crossover Kabeln wenn du einen Layer 3 Switch verwendest?
Ein Netzwerk aufzubauen und anschließend mit Corssover Verkabelung und "unorthodoxer" IP Adressierung das wieder zerstören kann ich nicht nachvollziehen!
Wenn du ein Trennung deiner Netze, die durch das dritte Oktet deiner IP Adressierung vornimmst, sauber aufbauen willst solltest du dir Gedanken machen über ein anständiges VLAN Konzept.
Du hast, wenn ich dein Netzwerk richtig verstehe, 3 Geräte Kategorien.
1. Kategorie = Server
2. Kategorie = Clients
3. Kategorie = Crossover Verbindungen (deren Sinn sich mir nicht erschließt)
Das kann man mit 3 VLANs und normaler Verkabelung machen und dabei sogar noch Redundanzen aufbauen.
Die Trunks oder Link Aggregation kombiniert mit einem PVST und neben einer Ausfall sicheren redundanz hast du durch das Trunking auch noch eine höhere Geschwindigkeit.
brammer
@brammer
Ein gut sortiertes Archiv
Mit dem L3 Switch hast du übrigens absolut Recht. Dann so ein völlig unsinniges Design zu machen ist schon der Grundfehler, da hast du zweifelsfrei Recht !
2 VLANs am L3 Switch einrichten und routen, den OpenFiler mit 802.3ad/LACP Linkaggregation an den L3 Switch ankoppeln im Serversegment, Arbeitsrechner dazu ins Client VLAN und gut ist.
Was der tiefere Sinn des obigen ist, ist wahrlich schwer nachzuvollziehen...
Wenn aber jemand schon den eigenen Rechner als Gateway IP konfiguriert am eigenen Interface, ist mal zu bezweifeln oder er jemals ein saubers Design so zurechtbekommt ?!!
Ein gut sortiertes Archiv
Mit dem L3 Switch hast du übrigens absolut Recht. Dann so ein völlig unsinniges Design zu machen ist schon der Grundfehler, da hast du zweifelsfrei Recht !
2 VLANs am L3 Switch einrichten und routen, den OpenFiler mit 802.3ad/LACP Linkaggregation an den L3 Switch ankoppeln im Serversegment, Arbeitsrechner dazu ins Client VLAN und gut ist.
Was der tiefere Sinn des obigen ist, ist wahrlich schwer nachzuvollziehen...
Wenn aber jemand schon den eigenen Rechner als Gateway IP konfiguriert am eigenen Interface, ist mal zu bezweifeln oder er jemals ein saubers Design so zurechtbekommt ?!!
Ironie an
Hallo,
@ aqui
Wenn aber jemand schon den eigenen Rechner als Gateway IP konfiguriert am eigenen Interface, ist mal zu bezweifeln oder er jemals
ein saubers Design so zurechtbekommt ?!!
Dafür gibt es ein guten Grund!!
Damit die Pakete auch sicher wissen wo sie lang müssen. Eine gute Bechilderung mit vielen Schuldern ist doch sinnvoll, Ein schild könnte man ja übersehen..
brammer
Ironie aus
Hallo,
@ aqui
Wenn aber jemand schon den eigenen Rechner als Gateway IP konfiguriert am eigenen Interface, ist mal zu bezweifeln oder er jemals
ein saubers Design so zurechtbekommt ?!!
Dafür gibt es ein guten Grund!!
Damit die Pakete auch sicher wissen wo sie lang müssen. Eine gute Bechilderung mit vielen Schuldern ist doch sinnvoll, Ein schild könnte man ja übersehen..
brammer
Ironie aus
Was macht ihr denn hier?
Zum Problem:
Wenn dein Switch LinkAggregation (802.3ad) unterstützt, wird er "vermutlich" auch VLAN Trunking (802.3q) unterstützen. Ich würde dir dringends empfehlen, baue die einen "großen Bond" auf deinen Switch und transportiere die Netze per VLAN vom Switch auf das System.
Ob es nun Sinn macht deinen Rechner mit 2 Karten in 2 Netzen zu betreiben, musst du selbst wissen. Konfigurieren kannst du es wie folgt:
L2 Konfiguration
Port05 - PC-NET1
Port06 - PC-NET2
Port07 - Gateway-Router
Linux-Server Port eth0-eth3 bond0
Linux-Server Bond0:VLAN2
Linux-Server Bond0:VLAN3
Wie du bei deiner Distribution VLANS konfigurierst sollte in der Dokumentation stehen. Per Hand geht das über
vconfig add bond0 2
vconfig add bond0 3
L3 Konfiguration
Auf dem Linux-System muss net.ipv4.ip_forwarding deaktiviert werden. Sonst wird es eklig im Netz.
VLAN3 ist somit Isoliert, profitiert aber trotzdem von dem Bond-Device (zumindest bis zum Switch).
Kleine Frage, was hast du denn für ein Platten-Subsystem in dem Server um diese Interfaces zu sättigen? Sinn macht das nur, wenn du mehrere iSCSI LUNs konfigurierst, den iSCSI target auf beide Adressen bindest und LUN1 über die Server-IP in VLAN2 und LUN2 über die IP in VLAN3 ansprichst.
Zum Problem:
Wenn dein Switch LinkAggregation (802.3ad) unterstützt, wird er "vermutlich" auch VLAN Trunking (802.3q) unterstützen. Ich würde dir dringends empfehlen, baue die einen "großen Bond" auf deinen Switch und transportiere die Netze per VLAN vom Switch auf das System.
Ob es nun Sinn macht deinen Rechner mit 2 Karten in 2 Netzen zu betreiben, musst du selbst wissen. Konfigurieren kannst du es wie folgt:
L2 Konfiguration
| Switch Port | Konfiguration |
|---|---|
| 01-04 | Member Aggregated Link AL1 |
| AL1 | VLAN Trunk Permit vlan 1-3 |
| 05 | Access-Port, VLAN 2 |
| 06 | Access-Port, VLAN 3 |
| 07 | Access-Port, VLAN 2 |
Port05 - PC-NET1
Port06 - PC-NET2
Port07 - Gateway-Router
Linux-Server Port eth0-eth3 bond0
Linux-Server Bond0:VLAN2
Linux-Server Bond0:VLAN3
Wie du bei deiner Distribution VLANS konfigurierst sollte in der Dokumentation stehen. Per Hand geht das über
vconfig add bond0 2
vconfig add bond0 3
L3 Konfiguration
| System | IP/Mask | Gateway |
|---|---|---|
| pc-net01 | 192.168.1.10/24 | 192.168.1.100 |
| pc-net02 | 192.168.2.10/24 | LEER |
| Linux eth0.2 | 192.168.1.200/24 | 192.168.1.100 |
| Linux eth0.3 | 192.168.2.200/24 | LEER |
Auf dem Linux-System muss net.ipv4.ip_forwarding deaktiviert werden. Sonst wird es eklig im Netz.
VLAN3 ist somit Isoliert, profitiert aber trotzdem von dem Bond-Device (zumindest bis zum Switch).
Kleine Frage, was hast du denn für ein Platten-Subsystem in dem Server um diese Interfaces zu sättigen? Sinn macht das nur, wenn du mehrere iSCSI LUNs konfigurierst, den iSCSI target auf beide Adressen bindest und LUN1 über die Server-IP in VLAN2 und LUN2 über die IP in VLAN3 ansprichst.
@datasearch
Klasse ! Perfekter hätte man das Konzept von oben nicht rüberbringen können !!
Hoffentlich kann der Kollege kiboyeti das denn auch umsetzen ??? Nach dem mangelnden Feedback von ihm zu urteilen hat er ja vermutlich schon jegliche Lust verloren und frickelt vermutlich weiter mit seinen 7 1/2 Interfaces ?!
Klasse ! Perfekter hätte man das Konzept von oben nicht rüberbringen können !!
Hoffentlich kann der Kollege kiboyeti das denn auch umsetzen ??? Nach dem mangelnden Feedback von ihm zu urteilen hat er ja vermutlich schon jegliche Lust verloren und frickelt vermutlich weiter mit seinen 7 1/2 Interfaces ?!
Er kann aber nicht sagen, ihm wurde hier nicht geholfen. Und mir bringt das durchdenken des Szenarios wieder 0.xx% mehr Routine für die anstehende LPIC2 . So eine Konfiguration werde ich selbst warscheinlich nie benötigen geschweige denn auf die Idee kommen einen Rechner per "vlan iscsi Multipath" anzubinden. Theoretisch könnte man das noch ausbauen und jeweils Reservepfade für die iscsi-tagets auf dem initiator konfigurieren
. So eine Konfiguration werde ich selbst warscheinlich nie benötigen geschweige denn auf die Idee kommen einen Rechner per "vlan iscsi Multipath" anzubinden. Theoretisch könnte man das noch ausbauen und jeweils Reservepfade für die iscsi-tagets auf dem initiator konfigurieren
Hallo,
@ datasearch
bringe ihn doch nicht noch auif dumme Ideen!
brammer
@ datasearch
bringe ihn doch nicht noch auif dumme Ideen!
brammer
Hallo zusammen,
erst mal vielen Dank für Eure klasse Anregungen.
@aqui
Der Grund weshalb ich bis jetzt noch nicht geantwortet habe ist, dass ich in der Arbeit durchaus zeitweise ausgelastet bin (Ironie). Ich bin kein Netzwerkfachmann, arbeite auch nicht im IT-Bereich (war ja klar, aufgrund der Konfiguration). Jetzt habe ich die Antworten gelesen und finds wirklich viele gute Anregungen, die persönlichen Spitzen mal ausgeblendet. Mit VLAN habe ich auch schon experimentiert, mich jedoch noch nicht so weit vorgetraut, das mit ISCSI zu verbinden. Ich war froh, vor gut einem Jahr mal einen Test hinzukriegen, der mit Schreibraten übers Netz mit konstant über 70 MB lieferte. Der tiefere Sinn meiner Überlegung war eigentlich eine physikalische Trennung der Architeturen, damit sich auch gegenseitig keine Datenpakete behindern. Die iSCSI-Verbindung soll ausschließlich für Videoschnitt übers Netz verwendet werden. Ich werd im ersten Schritt mal versuchen, jede Schnittstelle einzeln per ping zu erreichen - wenn das klappt, stimmt zumindest hardwareseitig alles. Dann mache ich mich an die weitere Konfiguration.
@datasearch
Ich werd mich Deinem Vorschlag mal annehmen und später (das wird sicher ein bis zwei Wochen dauern) berichten, ob und wie´s geklappt hat. Der Switch kann sowohl Link Aggregation 802.3ad als auch VLAN Trunking 802.3q. Ach ja: das Plattensystem ist ein Hardware RAID 5 mit zur Zeit 4+1 Platten auf Basis eines Adaptec 3805. Drei weitere Platten liegen da und warten auf den Einbau, den ich nach der Netzwerkkonfiguration und einem Systemupdate angehen will. Und um sicher zu gehen, dass iSCSI auch Vorrang hat, werde ich das vielleicht noch mit Priorisierung versuchen - auch das kann der Swich (Netgear GS108T). Insgesamt ist die Konfiguration noch ein bisschen größer wie dargestellt, mit zwei Switchen, die untereinander verbunden sind und mit weiteren IP´s - den Transfer krieg ich jedoch auf jeden Fall hin - denke ich.
@brammer
Die dummen Gedanken hatte ich schon lange, nur hat mir bislang ein fundierter Hinweis zur Umsetzung gefehlt. Die Anleitungen im Netz sind zwar gut und Recht, was ich bislang jedoch nicht gefunden habe war eine Antwort auf die Frage, wie soll ich´s überhaupt angehen bzw. welche Struktur ist die richtige.
Dafür erst mal herzlichen Dank. Wenn ich die Umsetzung geschafft habe, gebe ich Bescheid.
Viele Grüße
kiboyeti
erst mal vielen Dank für Eure klasse Anregungen.
@aqui
Der Grund weshalb ich bis jetzt noch nicht geantwortet habe ist, dass ich in der Arbeit durchaus zeitweise ausgelastet bin (Ironie). Ich bin kein Netzwerkfachmann, arbeite auch nicht im IT-Bereich (war ja klar, aufgrund der Konfiguration). Jetzt habe ich die Antworten gelesen und finds wirklich viele gute Anregungen, die persönlichen Spitzen mal ausgeblendet. Mit VLAN habe ich auch schon experimentiert, mich jedoch noch nicht so weit vorgetraut, das mit ISCSI zu verbinden. Ich war froh, vor gut einem Jahr mal einen Test hinzukriegen, der mit Schreibraten übers Netz mit konstant über 70 MB lieferte. Der tiefere Sinn meiner Überlegung war eigentlich eine physikalische Trennung der Architeturen, damit sich auch gegenseitig keine Datenpakete behindern. Die iSCSI-Verbindung soll ausschließlich für Videoschnitt übers Netz verwendet werden. Ich werd im ersten Schritt mal versuchen, jede Schnittstelle einzeln per ping zu erreichen - wenn das klappt, stimmt zumindest hardwareseitig alles. Dann mache ich mich an die weitere Konfiguration.
@datasearch
Ich werd mich Deinem Vorschlag mal annehmen und später (das wird sicher ein bis zwei Wochen dauern) berichten, ob und wie´s geklappt hat. Der Switch kann sowohl Link Aggregation 802.3ad als auch VLAN Trunking 802.3q. Ach ja: das Plattensystem ist ein Hardware RAID 5 mit zur Zeit 4+1 Platten auf Basis eines Adaptec 3805. Drei weitere Platten liegen da und warten auf den Einbau, den ich nach der Netzwerkkonfiguration und einem Systemupdate angehen will. Und um sicher zu gehen, dass iSCSI auch Vorrang hat, werde ich das vielleicht noch mit Priorisierung versuchen - auch das kann der Swich (Netgear GS108T). Insgesamt ist die Konfiguration noch ein bisschen größer wie dargestellt, mit zwei Switchen, die untereinander verbunden sind und mit weiteren IP´s - den Transfer krieg ich jedoch auf jeden Fall hin - denke ich
.@brammer
Die dummen Gedanken hatte ich schon lange, nur hat mir bislang ein fundierter Hinweis zur Umsetzung gefehlt. Die Anleitungen im Netz sind zwar gut und Recht, was ich bislang jedoch nicht gefunden habe war eine Antwort auf die Frage, wie soll ich´s überhaupt angehen bzw. welche Struktur ist die richtige.
Dafür erst mal herzlichen Dank. Wenn ich die Umsetzung geschafft habe, gebe ich Bescheid.
Viele Grüße
kiboyeti
Na dann viel Erfolg bei der Umsetzung. Aso, wenn da noch mehrere auf den Server zugreifen, musst du die Ports der Rechner in die entsprechenden VLANs legen. Bei dieser Konfiguration würde ich persönlich ein getrenntes iSCSI VLAN einsetzen. Die oben genannte Konfiguration gibt das her. Wenn du deine Targets ausschließlich auf die Server-IP in VLAN3 legst, hast du den Traffic ganz klar vom "normalen LAN" inkl. Internettraffic getrennt. Eventuell könntest du am Server auf VLAN-Trunking verzichten und den Bond direkt in VLAN3 legen (so würde ich es bevorzugen). Für normale Internetanbindung des Servers kannst du ja ein Interface normal in VLAN2 konfigurieren. Damit ist der Aggregated Link frei für iSCSI Traffic.
Nochwas, wenn du noch Platten liegen hast, würde ich dir fast vorschlagen ein RAID50 (2 gestripte RAID5 Arrays) anzulegen. Hier hast du wesentlich höhere Durchsätze. Mit der Anbindung 3xGBit zum Switch hättest du dann theoretisch (1000/8*3) - (15% verlust durch IP usw..) = ~280MB/s zum Switch und ca. (1000/8) - 15% = ~90MB/s. Das Plattensystem muss bei diesen Raten ganz schön was leisten um dein Netzwerk auszulasten. Schafft dein RAID weniger, haben auch mehr Interfaces am Server keinen Sinn
Nochwas, wenn du noch Platten liegen hast, würde ich dir fast vorschlagen ein RAID50 (2 gestripte RAID5 Arrays) anzulegen. Hier hast du wesentlich höhere Durchsätze. Mit der Anbindung 3xGBit zum Switch hättest du dann theoretisch (1000/8*3) - (15% verlust durch IP usw..) = ~280MB/s zum Switch und ca. (1000/8) - 15% = ~90MB/s. Das Plattensystem muss bei diesen Raten ganz schön was leisten um dein Netzwerk auszulasten. Schafft dein RAID weniger, haben auch mehr Interfaces am Server keinen Sinn
Hi!
Der Server brauch eigentlich nur äußerst selten I-Net-Anbindung, deshalb kann ich das ignorieren. Die Arbeitsplatzrechner greifen ohne Umweg über den Server auf das I-Net zu.
Das mit den Platten wäre schon was, wenn ich nicht bald den Speicherplatz brauche. Der geht nämlich langsam zur Neige. Darüber hinaus wird mir der Geschwindigkeitsgewinn nichts bringen, da der Flaschenhalts die Verbindung vom Schnitt-PC (Arbeitsplatzrechner) aus mit 1 Gbit besteht. Somit bin ich eh bei ca. 100 MB/s, das müssten die Platten im RAID 5 (wenn es denn mal 6 oder 7 aktive sind) schon schaffen. Zusätzlich reichen mir dann die Anschlüsse am Switch auch nicht mehr aus, da darüber das gesamte Haus (fast in jedem Zimmer eine Netzwerkdose) läuft. Der normale Zugriff wäre ja mit der VLAN-Lösung getrennt. Somit müsste ein Interface am Server für iSCSI und zwei für den restlichen Traffic locker reichen. Soviel zur Theorie.
Praktisch habe ich das Problem, dass ich gestern nacht die IP-Konfiguration versucht habe, so zu korrigieren, wie´s aqui empfohlen hat. Aber leider ohne Erfolg. Ich werde heute abend noch mal auf der Konsole des Servers rumspielen, denn es scheint dort ein Prob zu geben. Ich habe nämlich sowohl beim AP-Rechner über Switch oder über Crossover den ping versucht, nachdem ich sogar den Netzwerkkartentreiber neu installiert habe (als auch die beiden Interfaces probeweise mal vertauscht habe - jeweils ohne Kardinalsfehler ) als auch über ein Notebook unmittelbar anpingen wollte - aber alles ohne Erfolg. Somit kanns weder an der Karte / den Einstellungen des AP Rechners, noch an der Leitung bzw. den Switches liegen. Verbleibende Ursachen nur noch das Crossover-Kabel oder die Servereinstellung. Mehr aber dann morgen - mit hoffentlich guten Nachrichten.
Der Server brauch eigentlich nur äußerst selten I-Net-Anbindung, deshalb kann ich das ignorieren. Die Arbeitsplatzrechner greifen ohne Umweg über den Server auf das I-Net zu.
Das mit den Platten wäre schon was, wenn ich nicht bald den Speicherplatz brauche. Der geht nämlich langsam zur Neige. Darüber hinaus wird mir der Geschwindigkeitsgewinn nichts bringen, da der Flaschenhalts die Verbindung vom Schnitt-PC (Arbeitsplatzrechner) aus mit 1 Gbit besteht. Somit bin ich eh bei ca. 100 MB/s, das müssten die Platten im RAID 5 (wenn es denn mal 6 oder 7 aktive sind) schon schaffen. Zusätzlich reichen mir dann die Anschlüsse am Switch auch nicht mehr aus, da darüber das gesamte Haus (fast in jedem Zimmer eine Netzwerkdose) läuft. Der normale Zugriff wäre ja mit der VLAN-Lösung getrennt. Somit müsste ein Interface am Server für iSCSI und zwei für den restlichen Traffic locker reichen. Soviel zur Theorie.
Praktisch habe ich das Problem, dass ich gestern nacht die IP-Konfiguration versucht habe, so zu korrigieren, wie´s aqui empfohlen hat. Aber leider ohne Erfolg. Ich werde heute abend noch mal auf der Konsole des Servers rumspielen, denn es scheint dort ein Prob zu geben. Ich habe nämlich sowohl beim AP-Rechner über Switch oder über Crossover den ping versucht, nachdem ich sogar den Netzwerkkartentreiber neu installiert habe (als auch die beiden Interfaces probeweise mal vertauscht habe - jeweils ohne Kardinalsfehler
) als auch über ein Notebook unmittelbar anpingen wollte - aber alles ohne Erfolg. Somit kanns weder an der Karte / den Einstellungen des AP Rechners, noch an der Leitung bzw. den Switches liegen. Verbleibende Ursachen nur noch das Crossover-Kabel oder die Servereinstellung. Mehr aber dann morgen - mit hoffentlich guten Nachrichten.
