Archiv verlassen und diese Seite im Standarddesign anzeigen : HP NC6170 in DL360 an Gigaline8000T
Hallo,
möchte kurz im Vorfeld abklären wie es sich bei einem HP DL360 G4 mit eingebauter HP NC6170 PCI-X Gigabit SX Karte und dem Anschluss an einen Gigaline8000T Switch verhält., bzw. was hier genau unter Suse Prof. 9.3 zu konfigurieren ist, wenn ich den Server an das bestehende Glasfasernetz anschliessen möchte. Ein theoretischer Wegweiser würde mir schon helfen.
Grüße Proximus
heatwalker
23.11.05, 09:50
Bist du sicher, was das Glasfasernetz betrifft???
Die Karte ist, soweit mir bekannt, auf Twisted Pair ausgelegt und hat
Dual Ports. Will sagen, du brauchtst Kupferkabel. :D
Zumindest bis zum nächsten Switch. :cool:
Ansonsten brauchst du lediglich diesen Treiber hier:
http://h18023.www1.hp.com/support/files/networking/us/download/22879.html
Dem Server liegt eine sogenannte Smart Start CD bei. Hier sind auch alle benötigten Treiber und Infos drauf.
Eigentlich schon. Check den Link für Infos zur Karte.
http://h30094.www3.hp.com/product.asp?mfg_partno=313879-B21
Mir gehts eingentlich nur darum, wie ich die Karte konfigurieren muss um sie in ein bestimmtes Netz zu bekommen. Kenne das Netz allerdings noch nicht. Und kenne mich auch mit den Fibre Channel Geschichten nicht wirklich aus. Daher wäre es für mich zum Verständniss wichtig, wie eine solche Karte zu konfigurieren ist.
Wird hier, wie beim Ethernet mit IP Adressen gearbeitet, oder Verwechsel ich hier jetzt was mit den Host Bus Adaptern fürs SAN? Was ist der Unterscheid?
Oder muss ich nachdem die Karte mit dem passenden Treiber installiert ist nur noch das Kabel anschliessen?
Hab eben noch etwas recherchiert, zum Thema HBA und NIC:
Beim dateiorientierten NAS-Konzept werden Speichereinheiten (Filer) plattformneutral von mehreren Computern im LAN oder WAN über das Internetprotokoll TCP/IP bedient. SAN meint dagegen ein vernetztes Speichersystem für einen oder mehrere Server, das nicht Datei-, sondern blockorientiert arbeitet. Erst im Server werden die verteilten Datenblocks wieder zu kompletten Dateien verbunden und an einen Client übergeben. Bislang basierten SAN-Konzepte auf einer eigenen physikalischen Glasfaserarchitektur (Fibre Channel - FC), die nicht IP-basiert und unabhängig vom LAN war. Die schon in die Jahre gekommenen FC-Netze sind im Unterschied zu SCSI-Verbindungen (max. 18 m) praktisch nicht längenlimitiert (10 km) und bieten heute Übertragungsraten von 100 Mbit/s bis 2 Gbit/s.
Daraus schliesse ich folgendes:
Die genannte Karte wird ganz normal mit dem von heatwalker genannten Treiber installiert und per tcp/ip in das gewünschte Netz konfiguriert.
Müsste doch passen, oder?
heatwalker
23.11.05, 12:01
Der Netzwerktreiber reicht aus!
Die Karte macht Ethernet über LWL. Nicht das du jetzt etwas verwechselst von wegen SAN.
Dafür bräuchtest du wieder eine andere Karte. :rolleyes:
Ich würde das System trotz alledem mit der beigelieferten CD installieren, da du hierüber einige Management Agents installiert bekommst, die einzelnen Komponenten in Echtzeit
überwacht.
Die schon in die Jahre gekommenen FC-Netze
Das meinst du nicht ernst, oder?
heatwalker
25.11.05, 21:25
Das meinst du nicht ernst, oder?
Ich hab ihn extra nicht darauf angesprochen :cool:
Sonst wird das hier noch ne FC-Schulung. :D
Nee, is ja auch klar. Weit über 70% der weltenweiten SANs nutzen FC oder FICON. Aber es ist ja in die Jahre gekommen.... :rolleyes:
Falls es niemand aufgefallen sein sollte war der text von anderer Quelle kopiert....
http://www.contentmanagement.de/IT/iSCSI/iscsi.html
heatwalker
28.11.05, 11:59
Nein, aufgefallen ist das nicht.
Man sollte aber nicht alles glauben, was geschrieben wird.
iScsi hat sicherlich Vorteile.
Allerdings haben FC-Netze, mal abgesehen von den Mehrkosten, technisch wesentlich mehr
Vorteile als iSCSI.
MUHAHAH!! Geiler Artikel. Erstmal an die Kollegen verteilen....
*Linkverschick*
Allerdings haben FC-Netze, mal abgesehen von den Mehrkosten, technisch wesentlich mehr
Vorteile als iSCSI.
Mehrkosten sind's nicht immer. Seitdem iSCSI so ausgereift ist, kann man einen ziehmlich hohen Preisverfall bei den FC-Komponenten feststellen; insbesondere der pro Port Preis bei den FC-Switchen wird immer günstiger, da man ja einen 2GBit/s FC Port mit zwei 1GBit/s Ethernet Ports vergleichen muss, wenn man ehrlich ist.
Was meinst Du mit wesentlich mehr Vorteile als iSCSI?
Mich würden da mal Deine Ansichten interessieren ;)
Für FC spricht allein schon die Performance. Es gibt genug herstellerneutrale Benchmarks in denen FC gegenüber iSCSI eine Leistung bei geringerer CPU Belastung attestiert wird. Selbst IP OLEs auf iSCSI HBAs bringen es nicht wirklich. Sicherlich ein Fortschritt gegenüber Karten ohne IP OLE, aber kein Vergleich zu einem FC HBA. Sehen wir es mal realistisch: iSCSI ist der Versuch SCSI (als ULP) über IP zu übertragen. Und das nicht weil IP besser ist, sondern weil es billiger ist. FC ist zwar am Anfang nicht als Protokoll für Speichersysteme gedacht gewesen (eher als richtungsweisendes Netzwerkübertragungsprotokoll im Backbone), aber es ist perfekt an die Anforderungen von blockorientierten Speichersystemen angepasst. iSCSI ist ganz nett wenn ich billigen Speicher im Netz brauche. Wenn ich es ordentlich mache, ziehe ich für iSCSI Komponenten ein eigenes Netzwerk hoch. Für alles andere nehme ich FC. Geh mal zur LH Systems, einem großen Telco (z.B. E-Plus) und sag denen die sollen ihr SAN auf iSCSI umstellen (ist dort teilweise in Randbereichen im Einsatz) - die lachen dich aus.
Sehe ich ähnlich. Vor allem sollte man zumindest für sein Storage Netzwerk(egal ob für NAS oder iSCSI) VLans erstellen. Für Enterprise(ich sag mal alles grösser 10000 User) Apps/Kunden(SAP, Exchange, DBs) führt auch (momentan) kein Weg an FCP vorbei. iSCSI wird sicher mit 10GBit Ethernet interessanter werden und ist im Mittelstand jetzt schon dicke auf dem Vormarsch. Vor allen eines ist iSCSI im Gegenzug zu FCP; Simpel zu implementieren. Da haben unsere FCP-Freunde einfach Jahre lang gepennt und tun's immer noch. Immer noch ist es so, dass z.B. der schiessmichtod HBX xyz mit Firmware 1.5.2.ad und der Treiberversion 08/17 zusammen mit dem Switch blah, Modell fasel Firmware 4711 und dann dem StorageSystem 3700 mit OS Version 7.24.9 läuft. Sorry, aber das nervt ohne Ende!
Das mit billigen Speicher sehe ich nicht bei iSCSI. Schliesslich kostet ein vernünftiges System, das iSCSI bietet(also vor allem kein M$ Storage Server) auch einiges an Geld und wenn man iSCSI direkt mit FCP vergleichen will, muss man ja auch eingene Switche und HBAs mitrechnen.
Was man IMHO wirklich extrem spart, ist Aufwand in der Administration und Wartung(Ethernet ist ja eine bekannte Technologie. Daher muss man z.B. in der Regel nicht extra schulen und man kann sofort loslegen)
Nur meine 0.02$
Ansonsten mal schauen, was "neue" Technologien im Storageumfeld so bringen werden(10 GBit/s für iSCSI, iSCSI-TOE Adapter, >4GBit/s FCP, SAS, RDMA, VI, Clustered Filesystems, etc.)...
Interessante Ausführungen!
Aber um vielleicht wieder auf das Topic zurückzukommen:
Hab immer noch das Problem das auf dem HP DL360 die Netzwerkkarte NC6170 (dual port Gigabit FC) von meinem Suse Prof 9.3 und mittlerweile auch getestet SLES9 nicht richtig erkannt wird. Bzw. erkannt wird die Karte bei der Installation schon, sie kann auch konfiguriert werden, nur kann ich nicht von extern auf die karte pingen.
Ausserdem besteht am Switch Gigaline8000T (ich weiss der kann nur 100FDx. Sehr sinnig mit der Karte ...) ein Link. Nicht jedoch an der Karte.
lsmod zeigt das der e1000 treiber geladen ist.
wenn ich in mit rmmod entlade, sind auch die konfigurierten interfaces weg.
in der /etc/modprobe.conf hab ich manuell den eintrag "alias eth0 e1000" nachgetragen.
lsmod zeigt bei e1000 unter used by 0 an.
Demnach wird der e1000 ja nicht genutzt, oder?
Warum aber sind dann die interfaces weg, wenn ich den e1000 entlade.
Und warum kann ich die karte überhaupt konfigurieren wenn ich den falschen treiber hätte.
Karte ist übrigens 100% nicht defekt. Wurde schon getauscht. Kabel auch.
Ports am Switch sind auch frei.
Und dem Suse hab ich per ethtool auch schon gesagt das es nur 100FDx machen soll, per folgender Zeile:
ethtool -s eth0 speed 100 duplex full port fibre autoneg off
Hat jemand eine Idee warum die Karte net geht?
/var/log/messages meldet, irgendwas von wegen ipv6 ...
Kann gerade nicht darauf zugreifen, desshalb weiss ichs nicht recht...
Hat jemand ne Idee?
heatwalker
05.12.05, 16:32
Das kann nicht funktionieren :rolleyes:
Da dein Switch, lt. deiner Aussage, nur 100MBit versteht und die Karte nur 1000Mbit,
kann das nicht funktionieren.
Da wird wohl ein neuer Switch fällig. :ugly:
hmm. drum dachte ich ja eben, dass ich das mit dem ethtool anpassen kann...
Oder?
Kann man mir bitte auch noch kurz erklären ob das mit lsmod used by wirklich so ist, dass wenn bei used by 0 steht, dass dasjenige Modul dann nicht genutzt ist?
Vor allen eines ist iSCSI im Gegenzug zu FCP; Simpel zu implementieren. Da haben unsere FCP-Freunde einfach Jahre lang gepennt und tun's immer noch. Immer noch ist es so, dass z.B. der schiessmichtod HBX xyz mit Firmware 1.5.2.ad und der Treiberversion 08/17 zusammen mit dem Switch blah, Modell fasel Firmware 4711 und dann dem StorageSystem 3700 mit OS Version 7.24.9 läuft. Sorry, aber das nervt ohne Ende!
Sei bloß ruhig! Wenn das einfacher wird habe ich bald nix mehr zu tun. :ugly: Was soll ich denn sonst den ganzen Tag machen, wenn die Kompatibilitätslisten nicht mehr das Format einer 10 bändigen Enzyklopädie haben?
Das mit billigen Speicher sehe ich nicht bei iSCSI. Schliesslich kostet ein vernünftiges System, das iSCSI bietet(also vor allem kein M$ Storage Server) auch einiges an Geld und wenn man iSCSI direkt mit FCP vergleichen will, muss man ja auch eingene Switche und HBAs mitrechnen.
Was man IMHO wirklich extrem spart, ist Aufwand in der Administration und Wartung(Ethernet ist ja eine bekannte Technologie. Daher muss man z.B. in der Regel nicht extra schulen und man kann sofort loslegen)
Joar, kann man so stehen lassen. Dazu kommen dann noch z.B. Multiprotokollswitches (z.B. von CISCO) wenn man iSCSI und FC-SAN verbinden will.
Ansonsten mal schauen, was "neue" Technologien im Storageumfeld so bringen werden(10 GBit/s für iSCSI, iSCSI-TOE Adapter, >4GBit/s FCP, SAS, RDMA, VI, Clustered Filesystems, etc.)...
[/quote]
Vor allem auf RDMA und VI bin ich gespannt. Da läuft aktuell noch viel zu wenig. :)
ja ignoriert mich nur ... ;-)
was bitte ist VI ?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/NetXP_d/hh/NetXp_d/san_40b8fde4-a879-425e-a89f-8e1867e9584e.xml.asp
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.