Intel X710-DA4 mit unterschiedlicher NVM in einem Server
Moin,
ich nehme gerade zwei neue Fujitsu Primergy RX2540 M7 mit Windows Server 2022 in Betrieb. In den Servern war jeweils eine Intel X710 DA-4, dank meiner verpeilten Planung musste ich jeweils zwei X710 nachkaufen (refurbished) und habe diese mit installiert.
Über Intel ProSet habe ich jetzt gesehen, dass die verbauten und die nachgekauften Netzwerkkarten unterschiedliche NVM-Stände haben.
Verbaut: 9.30
Nachgekauft: 9.40
Aktuell: 9.53
Treiber sind natürlich identisch, aber sollten alle NVM-Stände gleich / aktuell sein? Oder spielt das keine Rolle, solange es keine Probleme gibt?
Gruß
ich nehme gerade zwei neue Fujitsu Primergy RX2540 M7 mit Windows Server 2022 in Betrieb. In den Servern war jeweils eine Intel X710 DA-4, dank meiner verpeilten Planung musste ich jeweils zwei X710 nachkaufen (refurbished) und habe diese mit installiert.
Über Intel ProSet habe ich jetzt gesehen, dass die verbauten und die nachgekauften Netzwerkkarten unterschiedliche NVM-Stände haben.
Verbaut: 9.30
Nachgekauft: 9.40
Aktuell: 9.53
Treiber sind natürlich identisch, aber sollten alle NVM-Stände gleich / aktuell sein? Oder spielt das keine Rolle, solange es keine Probleme gibt?
Gruß
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 670708
Url: https://administrator.de/forum/intel-x710-da4-mit-unterschiedlicher-nvm-in-einem-server-670708.html
Ausgedruckt am: 24.02.2025 um 14:02 Uhr
13 Kommentare
Neuester Kommentar
Zitat von @Coreknabe:
Ist ja eben die Frage, ob es dadurch Probleme geben kann.
Gruß
Wenns keine Probleme gibt, wo ist dann das Problem.
Ist ja eben die Frage, ob es dadurch Probleme geben kann.
Gruß
könnte....würde....sollte....diese Garantie wird dir keiner geben. Wenn du unsicher bist, dann kaufe über deinen Händler eine neue Karte nach, welche dann auf von Fujitsu über die serviceleistung supported wird. ( ja das ist möglich)
Andernfalls update einfach die Firmware.
Utility zur Aktualisierung des nichtflüchtigen Speichers (NVM) für Intel® Ethernet-Netzwerkadapter 700er-Reihe
Moin @Coreknabe,
jup, sie sollten gleich sein und vor allem ...
... der entsprechenden Treiberversion entsprechen. 😉
Das Problem ist eher, dass wenn du zum verwendeten Treiber eine nicht passende NVM Version verwendest und das zu einem Problem führt, du dir auf jeden Fall den 🐺 nach der Ursache dafür absuchst. Denn bei den meisten Problemen die daraus entstehen könnten, steht in der entsprechenden Fehlermeldung, falls es überhaupt eine gibt, eben nicht drinn, dass es an der falschen NVM Version liegen könnte. 😔
Gruss Alex
Treiber sind natürlich identisch, aber sollten alle NVM-Stände gleich / aktuell sein?
jup, sie sollten gleich sein und vor allem ...
... der entsprechenden Treiberversion entsprechen. 😉
Oder spielt das keine Rolle, solange es keine Probleme gibt?
Das Problem ist eher, dass wenn du zum verwendeten Treiber eine nicht passende NVM Version verwendest und das zu einem Problem führt, du dir auf jeden Fall den 🐺 nach der Ursache dafür absuchst. Denn bei den meisten Problemen die daraus entstehen könnten, steht in der entsprechenden Fehlermeldung, falls es überhaupt eine gibt, eben nicht drinn, dass es an der falschen NVM Version liegen könnte. 😔
Gruss Alex
Moin,
Hat Flutschi kein Tool, bei dem auf einem Schlag alle relevanten Komponenten mit FirmwareUpdates versorgt werden können?
Kenne das von IBM/ Lenovo und deren Bootable Media Creator so: davon bootet man (nachdem man die ISO erstellt hat), das Tool prüft das aktuelle Inventar und zieht dann die Firmware auf ein Supportetes Level hoch.
Recht simpel und man bewegt sich immer im Hersteller-Support…
Hat Flutschi kein Tool, bei dem auf einem Schlag alle relevanten Komponenten mit FirmwareUpdates versorgt werden können?
Kenne das von IBM/ Lenovo und deren Bootable Media Creator so: davon bootet man (nachdem man die ISO erstellt hat), das Tool prüft das aktuelle Inventar und zieht dann die Firmware auf ein Supportetes Level hoch.
Recht simpel und man bewegt sich immer im Hersteller-Support…
Moin @em-pie,
das funktioniert aber nur in der Theorie wirklich gut und zwar bei so gut wie allen Serverherstellern.
Denn zum einen, hinken die Firmwarestände, die man über solche Tools und oder die Serverherstellerportale herunterladen kann, oft Monate, wenn nicht gar Jahre hinter denen der Komponentenhersteller hinterher und selbst wenn du sowohl die Firmware als auch die Treiber über die Plattformen der Serverhersteller aktualisierst/beziehst, ist nicht wirklich sichergestellt, dass die Serverhersteller selbst, sich wiederum an z.B. die oben zu sehende Matrix der entsprechenden Komponentenhersteller sauber halten. 😭
Glaub mir, viele A-Brands sind heutzutage ihren Namen nicht mehr wirklich Wert, zumindest was deren Technologie angeht, da viele davon mittlerweile nicht mehr wirklich primär Technologieunternehmen sind, sprich Unternehmen die (effiziente/nachhaltige) Technologie entwickeln, sondern eher etwas Richtung Investmentfonds, sprich, Unternehmen die für ihre Anleger so viel wie möglich Rendite erwirtschaften müssen. 😔
Gruss Alex
Hat Flutschi kein Tool, bei dem auf einem Schlag alle relevanten Komponenten mit FirmwareUpdates versorgt werden können?
Kenne das von IBM/ Lenovo und deren Bootable Media Creator so: davon bootet man (nachdem man die ISO erstellt hat), das Tool prüft das aktuelle Inventar und zieht dann die Firmware auf ein Supportetes Level hoch.
Kenne das von IBM/ Lenovo und deren Bootable Media Creator so: davon bootet man (nachdem man die ISO erstellt hat), das Tool prüft das aktuelle Inventar und zieht dann die Firmware auf ein Supportetes Level hoch.
das funktioniert aber nur in der Theorie wirklich gut und zwar bei so gut wie allen Serverherstellern.
Denn zum einen, hinken die Firmwarestände, die man über solche Tools und oder die Serverherstellerportale herunterladen kann, oft Monate, wenn nicht gar Jahre hinter denen der Komponentenhersteller hinterher und selbst wenn du sowohl die Firmware als auch die Treiber über die Plattformen der Serverhersteller aktualisierst/beziehst, ist nicht wirklich sichergestellt, dass die Serverhersteller selbst, sich wiederum an z.B. die oben zu sehende Matrix der entsprechenden Komponentenhersteller sauber halten. 😭
Glaub mir, viele A-Brands sind heutzutage ihren Namen nicht mehr wirklich Wert, zumindest was deren Technologie angeht, da viele davon mittlerweile nicht mehr wirklich primär Technologieunternehmen sind, sprich Unternehmen die (effiziente/nachhaltige) Technologie entwickeln, sondern eher etwas Richtung Investmentfonds, sprich, Unternehmen die für ihre Anleger so viel wie möglich Rendite erwirtschaften müssen. 😔
Gruss Alex
Moin @Coreknabe,
Entweder das, oder du bügelst auf die NIC's die neusten NVM's von Hand rauf und verwendest dann auch die aktuellesten Treiber.
Aber, das Letztere ist dann wiederum seitens der Serverhersteller, nicht wirklich supportet. 😔😭
Ja mir fällt dazu sehr wohl was ein und zwar eine ganze Menge. 😁
Suboptimale NIC-Konfiguration und zwar schon seitens der Hersteller, suboptimal SMB Konfiguration seitens Microsoft und eventuell ist auch die NetApp, nicht ganz optimal konfiguriert.
Das von dir beschriebene Phänomen kenne ich auf jeden Fall zugenüge und es lässt sich meistens auch beheben/lindern.
Weitere Details gerne später, bin gerade etwas kurz angebunden.
Oder wir machen mal ne Stunde eine Remotesession, danach kann ich dir auf jeden Fall schneller die Richtung zeigen, wo bei dir der Hund wahrscheinlich begraben ist.
Ja, Jumbo Frames werden sehr oft überbewertet, dennoch sagt mir deine Aussage, das CPU-Auslastung eher nicht dein Problem ist. 😉
Ausserdem machen Dinge wie LSO oder RSC(🤢🤮), Jumbo Frames, zumindest OS Seitig, eh überflüssig und oder beissen sich sogar gegenseitig. 🙃
Gruss Alex
Ich sollte also kein Upgrade, sondern ein Downgrade vornehmen.
Entweder das, oder du bügelst auf die NIC's die neusten NVM's von Hand rauf und verwendest dann auch die aktuellesten Treiber.
Aber, das Letztere ist dann wiederum seitens der Serverhersteller, nicht wirklich supportet. 😔😭
Problem, was ich nämlich habe, und deshalb klopfe ich auch die NVMs ab, über die iSCSI-Verbindung zur NetApp ist der Datendurchsatz superlahm. Kopiere ich eine 6GB-ISO vom Server auf die NetApp, komme ich auf maximal 600MB/s, bei einer 10Gbit-Anbindung. Zwei Server, der eine kopiert zumindest lahm, der andere kommt auf max 1,7GB/s, hängt dann aber vor Abschluss des Kopiervorganges. Irgendwann reagiert der Server dann gar nicht mehr und muss neu gestartet werden. Das ist zwar ein anderes Thema, aber vielleicht fällt Dir dazu auch was ein...
Ja mir fällt dazu sehr wohl was ein und zwar eine ganze Menge. 😁
Suboptimale NIC-Konfiguration und zwar schon seitens der Hersteller, suboptimal SMB Konfiguration seitens Microsoft und eventuell ist auch die NetApp, nicht ganz optimal konfiguriert.
Das von dir beschriebene Phänomen kenne ich auf jeden Fall zugenüge und es lässt sich meistens auch beheben/lindern.
Weitere Details gerne später, bin gerade etwas kurz angebunden.
Oder wir machen mal ne Stunde eine Remotesession, danach kann ich dir auf jeden Fall schneller die Richtung zeigen, wo bei dir der Hund wahrscheinlich begraben ist.
Jumbo Frames sind überall aktiviert, für den Durchsatz bei meinem Testkopiervorgang aber unerheblich, die Werte bleiben gleich, ob Jumbo Frames oder nicht.
Ja, Jumbo Frames werden sehr oft überbewertet, dennoch sagt mir deine Aussage, das CPU-Auslastung eher nicht dein Problem ist. 😉
Ausserdem machen Dinge wie LSO oder RSC(🤢🤮), Jumbo Frames, zumindest OS Seitig, eh überflüssig und oder beissen sich sogar gegenseitig. 🙃
Gruss Alex
Moin @Coreknabe,
https://www.intel.de/content/www/de/de/download/683939/814931/nvm-downgr ...
Siehe unterster Download. 😉
Gruss Alex
vielleicht ist aber kein Downgrade vorgesehen. Gelieferte NICs: 9.30, nachgekauft: 9.40
https://www.intel.de/content/www/de/de/download/683939/814931/nvm-downgr ...
Siehe unterster Download. 😉
Gruss Alex
Moin @Coreknabe,
na ja, ich habe auch nie geschrieben, dass dir Flow Control bei deinem Problem mit welchem du übrigens erst im Nachgang un die Ecke gekommen bist, auch wirklich hilft. Deine ursprüngliche Frage war ja, ob man es quasi generell bei iSCSI einschalten sollte oder nicht und entsprechend habe ich auch geantwortet.
Und das das aktivieren oder deaktivieren von Flow Control überhaupt keine Auswirkungen bei dir hat, hat etwas damit zu tun, dass dieses Feature im Grunde lediglich eine Art Überlaststeuerung ist, die nur eingreifen sollte, wenn eben eine Überlast entsteht. Du hast aber eher das Problem, dass bei dir nicht wirklich viel Last entsteht, weil andere Konfigurationen nicht passen und daher bringt dir Flow Control in dem jetzigen Stadium auch nicht wirklich etwas.
Wenn du jedoch deine Umgebung mal soweit optimiert hast, dass die Server und oder das SAN, die Bandbreite der NIC's voll ausreizen können und somit auch eher eine Überlastsituation erzeugen können, wirst du um Flow Control nicht wirklich drumherum kommen.
Wobei, Flow Control ist in dem Zusammenhang mit iSCSI nicht nur dafür wichtig, um Überlastsituationen innerhalb des Netzwerks abzufangen, sondern greift auch dann, wenn entweder das SAN oder der Server den entsprechenden IO aufgrund von z.B. vollem Cache/Buffer oder einer CPU-Überlastung nicht mehr schnell genug verarbeiten kann. Aber wie schon oben geschrieben, wenn keine Last wirklich zustande kommt, dann sollte eine Überlaststeuerung auch nicht wirklich greifen.
Gruss Alex
Tipp: Flow Control ist es nicht, habe ich deaktiviert und ändert nix..
na ja, ich habe auch nie geschrieben, dass dir Flow Control bei deinem Problem mit welchem du übrigens erst im Nachgang un die Ecke gekommen bist, auch wirklich hilft. Deine ursprüngliche Frage war ja, ob man es quasi generell bei iSCSI einschalten sollte oder nicht und entsprechend habe ich auch geantwortet.
Und das das aktivieren oder deaktivieren von Flow Control überhaupt keine Auswirkungen bei dir hat, hat etwas damit zu tun, dass dieses Feature im Grunde lediglich eine Art Überlaststeuerung ist, die nur eingreifen sollte, wenn eben eine Überlast entsteht. Du hast aber eher das Problem, dass bei dir nicht wirklich viel Last entsteht, weil andere Konfigurationen nicht passen und daher bringt dir Flow Control in dem jetzigen Stadium auch nicht wirklich etwas.
Wenn du jedoch deine Umgebung mal soweit optimiert hast, dass die Server und oder das SAN, die Bandbreite der NIC's voll ausreizen können und somit auch eher eine Überlastsituation erzeugen können, wirst du um Flow Control nicht wirklich drumherum kommen.
Wobei, Flow Control ist in dem Zusammenhang mit iSCSI nicht nur dafür wichtig, um Überlastsituationen innerhalb des Netzwerks abzufangen, sondern greift auch dann, wenn entweder das SAN oder der Server den entsprechenden IO aufgrund von z.B. vollem Cache/Buffer oder einer CPU-Überlastung nicht mehr schnell genug verarbeiten kann. Aber wie schon oben geschrieben, wenn keine Last wirklich zustande kommt, dann sollte eine Überlaststeuerung auch nicht wirklich greifen.
Gruss Alex