Gibt es im BIOS eine Möglichkeit, den RAM zu konfigurieren?
Gibt es im BIOS eine Möglichkeit, den RAM zu konfigurieren?
Verstand op nul, frituur op 180.
Was steht denn auf den Speicher-Modulen?
Das Bild ist leider "etwas" unscharf...
Die Typenbezeichnung gibt Auskunft über die max. mögliche Geschwindigkeit.
Ich erahne da ein "PC3-8500R", sprich der RAM sollte max. 1066Mhz erreichen...
Wühl dich mal durch Bios, ob es da irgendwo eine passende Option "memory settings" oder so ähnlich gibt.
Den Backup-Server mit dem alten RAM/HDDs zu betreiben klingt erstmal sinnvoll...
Aufrüsten kann man den ja immer noch, wenn man merkst, daß es irgendwo hakt.
Jepp, ist PC3-8500R, ergo geplante 1066MHz.
Ich versuch mein Glück im BIOS nach Dienstschluss...
Mundus vult decipi, ergo decipiatur.
Ich kam noch nicht dazu, war zeitlich immer zu knapp, aber inzwischen las ich:
DELL Community
Dann kann ich mir experimentieren vielleicht auch sparen...
In's BIOS schauen werde ich trotzdem mal.
Mundus vult decipi, ergo decipiatur.
Das wäre eine Erklärung für den reduzierten RAM-Takt.4 of them will max out the memory at 32GB.
Even though they are 1066MHz they will operate at 800MHz if you use 4 of them.
If you only put in 2 then they will operate at 1066MHz.
Thanks
Daniel Mysinger
Dell EMC, Enterprise Engineer
Im Zweifelsfall ist aber mehr "langsamer" RAM besser als weniger "schneller" RAM.
Zumindest wenn man sich nicht 100% sicher ist, daß der RAM ausreichend dimensioniert ist.
Wenn dir der RAM ausgeht, nutzt das System die verbauten Massenspeicher als virtuellen RAM (Stichwort "swappen").
Dann wird es irgendwo zwischen sehr, sehr langsam (HDDs) oder langsam (SSD).
Aber du hast nun auch die Möglichkeit mit der Speicherbestückung ein wenig zu experimentieren.
z.B. ein Server mit 2x8GB + 2x 4GB bestücken und den anderen 2x 8GB (Stichwort "Dualchannel").
Sinnvoll wäre auch den "neuen" Server als Hauptserver zu nutzen (höher getaktet CPU iirc) und die aktuelle Maschine
zum Backupserver zu degradieren.
Damit hättest du in beiden Maschinen noch 8GB Reserve bezgl. der Kaufempfehlung/des geposteten Angebots.
PS
Fehlt in dem neuen Server nicht ein "CPU-Lüfter"?
Und rein Interessehalber ->sind die Deckel der Servergehäuse verschraubt, oder kann man die per Quickrelease einfach öffnen?
PPS
Wie gestaltet sich die Infrastruktur eigentlich nach dem Softwareupdrade?
Fällt der ESXi weh (klingt so in dem Angebot)
Der Hauptserver übernimmt die Rolle der bisherigen Server-VM?
Und der Backupserver macht nun was konkret, außer die Rolle der bisherigen "Wartungs-/Admin-VM" zu übernehmen?
Geändert von drdope (05. Juli 2018 um 15:40 Uhr)
Jetzt wo du es sagst...Zitat von drdope
<dejavu>Jetzt wo du...</dejavu>
Noch gar nicht aufgefallen, aber da kann ich nochmal fragen.
Auch was "hinten rechts" an der Blende verbaut ist, weiß ich ad hoc nicht, der Unterschied fällt mir auch grad erst auf.
Zweiteres. Fand ich zwar beim ersten Öffnen doch recht krampfhaft, aber wenn es mal einmal geglitten ist, geht es fortan.
Angedacht hätte ich, dass der ESXi weiterhin auf dem Hauptserver läuft.
Da ich allerdings (noch) nicht weiß, inwieweit die Lizenz wirklich vorhanden ist und das ganze ja auf eine neue HDD muss, müsste das Dingen ja auch erstmal "irgendwo herkommen". Bis auf die Möglichkeit zur Fernwartung für den "Erbauer" gibt es keine wirkliche Notwendigkeit für die VM, das Konstrukt könnte man sicher überdenken.
Die Firma, über die die branchenspezifische Software läuft, klinkt sich eh anderweitig in's System (wie auch immer das konkret geht):
Für Fragestellungen an der Software wird so eine Art TeamViewer genutzt, bei Fragestellungen zum Server gehen die "irgendwie per Router rein", das ist jedenfalls Hardware von denen hier im Serverschrank. So mein Kenntnisstand. Nicht lachen.
Wenn kein ESXi, dann ist der Hauptserver einfach Linux-basiert (wo krieg ich die 12 eigentlich her?) mit der Branchensoftware laufend.
Wenn ESXi, dann würde alles wie bisher virtualisiert auf dem Hauptserver laufen, der Backupserver wäre dann ohne ESXi. Fände ich zumindest bei der voraussichtlichen Auslastung nicht sinnvoll, dort auch die Struktur komplizierter zu machen, als notwendig.
Was genau der Backupserver machen soll, weiß ich nicht. Die Wartungs-/Admineigenschaft wird er nicht übernehmen.
Wie gesagt: Bisher ist das Backupsystem virtualisiert auf dem Haupt-Klienten, springt aber nur ein, wenn auf Ausfall des Servers hin die Klient-PCs merken, dass die Datenbank unerreichbar ist und streiken. Dann kann man manuell den "Notlauf" im virtuellen Backup aktivieren, was dann einen virtuellen Server auf dem PC herstellt und ist prinzipiell an den Klientrechnern weiter arbeitsfähig im Alltag. So wäre die Theorie.
Mehr macht m.W. der "Backup-Server" aktuell nicht.
Das eigentliche Daten-Backup (unser voriges Thema) findet aktuell auf dem Haupt-Klienten statt und stellt einfach nur allnächtlich die firmenspezifischen Daten in einem Ordner auf ebendiesem PC zur Verfügung, damit ich sie täglich auf einen USB-Stick ziehen kann. Zusätzlich dazu spiegelt momentan ein Skript auf dem virtualisierten Verwaltungsrechner die gleichen Software-Daten und zusätzlich noch unsere interne "Office-Datensammlung" auf den/das NAS. Das Skript kann ich aber auch auf den Haupt-Klienten kopieren und dort initiieren, das allein rechtfertigt imho ja auch keine VM.
Verstanden habe ich es so, dass der Backup-Server auch weiterhin tatsächlich nur "Notnagel" ist und nebenher laufen soll, ohne ein Datenbackup zu tätigen. Eben "nur" bei Serverausfall ein echter Zweitserver, um arbeitsfähig zu bleiben.
Das lässt sich vermutlich aber spezifizieren, wenn ich dort mal nachfragen täte...
Mundus vult decipi, ergo decipiatur.
Die Anfrage mit dem "Sicherheitssystem"/Zweitserver habe ich eben mal mit Bitte um konkrete schriftliche Stellungnahme weitergeleitet.
Was übrigens auch den bisherigen System-Admin hier nicht wirklich mit Logik erfüllt ist das permanente Betonen des Softwareanbieters einer 64-bit fähigen SUSE Linux Version als Voraussetzung für die kommende Software.
Nicht mal auf das Argument hin, dass laut vSphere aktuell doch schon eine 64-bit-Version läuft, konnte das Thema abgehakt werden. Überseh' ich was? Warum soll die Hardware nicht 64-bit-fähig sein?
Mundus vult decipi, ergo decipiatur.
Was sind denn Rückseitig für Anschlüsse an dem "Modul" oben rechts?
Könnte evtl. ein IPMI + KVM-over-LAN addon sein...
Die Hardware ist definitiv "64bit-fähig".
Zum Thema Virtualisierung/ESXi:
Für den ESXi brauchst du keine Lizenz, den gibt es von VMWare kostenlos (böse Zungen behaupten zum anfixen).
--> https://my.vmware.com/de/web/vmware/...r?p=free-esxi6
--> https://en.wikipedia.org/wiki/VMware_ESXi
Ich denke genau das kommt bei dir auch zum Einsatz.
Eine Lizenz brauchst du für vSphere:
--> https://de.wikipedia.org/wiki/VMware_vSphere
Ist schweineteuer, kann aber viele tolle Sachen...
edit (sorry längeres Telefonat hat meine Schreiberei unterbrochen):
Ein bissl unglücklich ist, daß bis zum ESXi 5.0 dessen rudimentäres Webmanagement iirc auch vSphere hieß.
Virtualisierung ist grundsätzlich charmant, weil man
a) die Software von der Hardware "entkoppelt" -> Hardwareausfall heißt dann nicht mehr "alles neu machen", sondern lediglich die VM-Container bzw. deren Backups
auf neuer Hardware zurück zu spielen und zu starten
b) vorhandene Ressourcen (CPU/RAM/Storage) bündeln kannst,
c) das Ganze zentral zu managen ist
Bei einem Bekannten, hab ich das z.B. so realisiert, daß auf einem ESXi sowohl der Server, als auch diverse Clients laufen.
An den Arbeitsplätzen stehen dann nur noch Thin-Clients, die sich per RDP mit dem Server verbinden.
Dadurch hat man dann Clientseitig (Hardware) kaum Konfigaufwand mehr, Softwareseitig reduziert es auch den zeitlichen Aufwand
Geht die Clienthardware defekt, muß man das System nicht mehr zeitaufwändig wieder herstellen.
Hardwareclient tauschen, zum Server verbinden und weiter gehts.
Last but not least, spart es Clientseitig auch viel Geld -> man braucht nicht für jeden Client eine "schnelle" CPU, RAM, SSD", nur damit man nicht schon bei einem
Windowsupdate, einen Schreikrampf kriegt, obwohl die Geräte das gro des Tages eigentlich nur in Mail/Office vor sich hin idlen...
Geändert von drdope (05. Juli 2018 um 18:59 Uhr)
Hast Recht, auch laut R310-Handbuch und Artikelbeschreibung ist es eine iDRAC6-Schnittstelle.
Wenn ich es richtig verstehe also eine Art BIOS-per-Browser-Zugang?!
Da ich damit nix zu tun habe: Worin besteht der tiefere Nutzen? Reine "Remote-Kontrolle"?
Was ich habe ist schon das hier (wenn auch nicht mit meinen eigenen Bilder diesmal, wie zu erkennen ist):
Die Macht über viele tolle Sachen erkenne ich zwar noch nicht, für die Sinnhaftigkeit dessen ist mein Mini-Netzwerk hier wahrscheinlich auch völlig ungeeignet, aber der Titulierung nach scheint es schon das teure Ding zu sein...
Naja, das werden wir hier nicht erörtern können. Wenn ich es erfahre, sag ich hier aber mal Bescheid.
Das Virtualisierungs-Thema erahne ich von der Tragweite her, deine Beschreibung macht es mir schon ganz gut begreiflich. Ist aber für mich schwierig zu verstehen, da fehlt mir einfach die Routine.
Wenn es mal für alles so ein schöne Hexal/Ratiopharm-Exempel gäbe...
Das mit der ThinClient-Idee klingt schon schick, hier im Klinikum umme Ecke scheint das ja auch nur auf die Art und Weise zu laufen, zumindest stelle ich es mir anhand deiner Beschreibung so in etwa vor.
Braucht man aber wahrscheinlich einen (auf welcher Ebene auch immer) deutlich leistungsstärkeren Server, vermute ich?!
Mundus vult decipi, ergo decipiatur.
Damit könnte ich mich z.B. aus Neuseeland per VPN mit deinem Server verbinden, ins Bios schauen, dir zeitnah am Telefon sagen kann:
Hast Recht, auch laut R310-Handbuch und Artikelbeschreibung ist es eine iDRAC6-Schnittstelle.
Wenn ich es richtig verstehe also eine Art BIOS-per-Browser-Zugang?!
Da ich damit nix zu tun habe: Worin besteht der tiefere Nutzen? Reine "Remote-Kontrolle"?
"Yo, die HDD im RAID1 ist defekt, tausch die mal gegen eine vorhandene Ersatz-HDD aus deiner Coldspare-Reserve aus" damit selbige, nach dem Rebuild auf die Hotspare, deren Rolle übernehmen kann.
Danach ackert der Server ein paar Stunden und morgen früh löppt wieder alles wie gewohnt (das rote Lämpchen an der "zweiten HDD" leuchtet wieder grün) und ich schaue noch kurz drüber und ich sag dir beruhigend "Alles wieder gut! Besorg mal eine Ersatz-Coldspare...
Im Prinzip kannst du mit einem solchen Modul (theoretisch) jeden Rechner so managen, als wärst du lokal vor Ort.
Reale Menschen braucht man VorOrt nur noch für "Hardwarebastelei"...
Schwierig da eine Analogie zu kreieren...Das Virtualisierungs-Thema erahne ich von der Tragweite her, deine Beschreibung macht es mir schon ganz gut begreiflich. Ist aber für mich schwierig zu verstehen, da fehlt mir einfach die Routine.
Wenn es mal für alles so ein schöne Hexal/Ratiopharm-Exempel gäbe...
Überleg mal, wie viel Zeitaufwand es dich kostet, lokal 1000 Menschen eine Packung ASS-Hexal 100 zu verkaufen und welche Marge du daran hast...
Jetzt stell dir vor eine weltweit agierende Internetapotheke hat für Bestellungen/Artikel rauskramen, verpacken und versenden 1000 identische Arbeitsplätze in der "dritten Welt" (Lohnkosten sehr gering)...
Der IT-Admin richtet einen Arbeitsplatz ein und klont selbigen über die Welt 1000mal (Zeitaufwand -> ein Script dafür erstellen)...
Wenn du (lokal) die Kunden im 2min.Takt abfertigst, brauchst du knapp 1,5Tage non Stop...
Die "Konkurrenz Internetapotheke" hat den Prozess bis an die Grenzertrags(lohn)kosten soweit automatisiert, daß nur noch so viel Menschen in der Rechnung vorkommen wie maximal nötig.
Optimalerweise würde man den Prozess komplett automatisieren, damit man gar keine Menschen braucht, um pro 2 Minuten 1000 Artikel zu verkaufen, verpacken und zu versenden zu können.
Wenn der vollautomatisierte Prozess nur 1 Cent pro Packung ASS-Hexal 100 verdient, kann er 30k€/h damit verdienen...
Selbst wenn der Konkurrent den Auftrag in 2min mit 1000 billigen Lohnsklaven abwickelt, kannst du da nicht mithalten.
Das nennen wir heute Amazon...
Diese vereinfachte Perspektive ist gegenüber Amazon nicht fair... die beschäftigen in der EU viele Menschen zum "Mindestlohn" oder gar mehr, weil es unterm Strich günstiger ist als Vollautomatisierung...
Geändert von drdope (06. Juli 2018 um 01:05 Uhr)
Verstehe ich. Fast. Inwieweit braucht's da den Kartenslot? Das ist ja geschätzt...SD-Karten-Größe?
Sag nicht, jetzt kommt die Möglichkeit eines Drahtlos-SIM-Karten-Zugriffs in's Spiel...
Und die andere sich daraus ergebende Frage ist ja:
Wie sinnvoll ist es vermeintlich für mich, das Teil zu nutzen bei meinem rudimentären Know-How?
Der Server kriegt freilich eh früher oder später eine fixe IP-Adresse und mehr braucht es dann vermutlich auch nicht für den Zugriff, wenn ich ihn einmal mit dem Switch vernetzt habe?
Jetzt müsste ich mich aber vielleicht erst mal wieder meinem SSD-Thema widmen...
Bin mal recherchieren.
Mundus vult decipi, ergo decipiatur.
Also, ich fasse nochmal den bisherigen Stand, sowie mein bisher soweit vermeintlich Verstandenes zum Thema Festplatten zusammen:
Server 1-Istzustand:
- läuft bereits mit internem, modularen RAID-Controller "SAS 6iR für Hot Plug Festplatten", zusätzlich "C18 Hot-Swap - R1 für SAS 6iR/PERC H200/H700, Genau 2 SAS/SATA/SSD Hot Plug Laufwerke"
- läuft im RAID1 mit aktuell 2 HDD (1x 500GB, 1x 1TB) + 1 HotSpare HDD (1x 500GB)
- funktioniert unter VMware ESXi 5 reibungslos
Server 2-Istzustand:
- läuft ohne zusätzlichen RAID-Controller, besitzt nur den onboard "Intel(R) 5 Series/3400 Series SATA AHCI Controller (4x SATA)"
- ist völlig blank an Festplatten
- noch unklar, ob ESXi zum Laufen kommen wird
Was ich herausfinden müsste:
- welcher RAID-Controller überhaupt mit der übrigen Hardware des R310 konform geht; hierzu finde ich außer folgendem in der Betriebsanleitung des R310 aber keine echte Aufzählung:
Hierbei geht es aber nur um die Steckplatzpriorität und nicht explizit um die Kompatibilität.
Immer wieder auftauchen tun ja die Nennungen SAS 6iR, PERC H200 und PERC H700 - wo aber die echten (und für mich ggf. relevanten) Unterschiede liegen, wird mir nicht ersichtlich.
- welcher RAID-Controller überhaupt mit dem ESXi 5.0 arbeitet; hierzu gab es von drdope schon folgende Übersicht auf der ich jetzt nur die aktuelle ESXi-Version ergänzt habe: VMware-Übersicht
Da allerdings überfordert mich die Fülle an Aufzählungen (wobei da viele Redundanzen allein des Anschlusses halber [modular, intern, extern] sind, das sehe ich) und echte Spezifikationen im Sinne von "unterstützt werden folgende Festplattentypen: …" werden mir jetzt auch nicht ersichtlich.
Oder ist das SAS/SATA-RAID in der Mitte tatsächlich alles was ich wissen muss und dann kann ich davon ausgehen, dass die Platten mit entsprechender Schnittstelle allesamt gingen?
- ob es SSDs gibt, die überhaupt nicht unter bestimmten (den genannten) RAID-Controllern funktionieren?!
- ob es pro forma nicht das einfachste wäre den ja prinzipiell bereits funktionablen SAS 6iR weiterhin zu verwenden (den hat drdope aber schonmal hier im Thread für suboptimal befunden)
Muss noch mehr beachtet werden für die Fragestellung des RAID-Systems samt Speichermedien?
Mundus vult decipi, ergo decipiatur.
--> https://en.wikipedia.org/wiki/Dell_DRACVerstehe ich. Fast. Inwieweit braucht's da den Kartenslot? Das ist ja geschätzt...SD-Karten-Größe?
Sag nicht, jetzt kommt die Möglichkeit eines Drahtlos-SIM-Karten-Zugriffs in's Spiel...
Und die andere sich daraus ergebende Frage ist ja:
Wie sinnvoll ist es vermeintlich für mich, das Teil zu nutzen bei meinem rudimentären Know-How?
Der Server kriegt freilich eh früher oder später eine fixe IP-Adresse und mehr braucht es dann vermutlich auch nicht für den Zugriff, wenn ich ihn einmal mit dem Switch vernetzt habe?
Jetzt müsste ich mich aber vielleicht erst mal wieder meinem SSD-Thema widmen...
Bin mal recherchieren.
Ist eine Dell-eigene Remote-Admin-Lösung... Ob es für dich sinnvoll ist -> k.A.
Denke das ist wenn man eh regelmäßig lokalen Zugriff auf die Maschine hat eher ein Bequemlichkeitsfeature.
Von Supermicro-Boards mit IPMI/KVM over IP kenne ich es so, daß man damit z.B. zentral Temperaturen/Lüfterdrehzahlen überwachen kann.
Auch kann den Server remote über ein ISO-Image, daß auf dem Client liegt (z.B. für OS-Installation).
Das hab ich noch zu der SD-Karte gefunden:
--> http://en.community.dell.com/techcen...ature-on-idracThe partitions are managed remotely using the iDRAC6 Web interface and the RACADM command line. Users can expose the partition to the operating system much like a USB flash drive, and can even physically move it to another supported Dell server. In addition, partitions can be bootable making them ideal candidates for a persistent diagnostic boot image, or other bootable utility. This is also an excellent management tool for customers that have low bandwidth, or high latency, links to the remotely managed server.
Bei den Controllern würde ich schauen, ob irgendwas dabei ist, daß a) Sata3 und b) TRIM für SSDs unterstützt.Hierbei geht es aber nur um die Steckplatzpriorität und nicht explizit um die Kompatibilität.
Immer wieder auftauchen tun ja die Nennungen SAS 6iR, PERC H200 und PERC H700 - wo aber die echten (und für mich ggf. relevanten) Unterschiede liegen, wird mir nicht ersichtlich.
- welcher RAID-Controller überhaupt mit dem ESXi 5.0 arbeitet; hierzu gab es von drdope schon folgende Übersicht auf der ich jetzt nur die aktuelle ESXi-Version ergänzt habe: VMware-Übersicht
Da allerdings überfordert mich die Fülle an Aufzählungen (wobei da viele Redundanzen allein des Anschlusses halber [modular, intern, extern] sind, das sehe ich) und echte Spezifikationen im Sinne von "unterstützt werden folgende Festplattentypen: …" werden mir jetzt auch nicht ersichtlich.
Oder ist das SAS/SATA-RAID in der Mitte tatsächlich alles was ich wissen muss und dann kann ich davon ausgehen, dass die Platten mit entsprechender Schnittstelle allesamt gingen?
- ob es SSDs gibt, die überhaupt nicht unter bestimmten (den genannten) RAID-Controllern funktionieren?!
- ob es pro forma nicht das einfachste wäre den ja prinzipiell bereits funktionablen SAS 6iR weiterhin zu verwenden (den hat drdope aber schonmal hier im Thread für suboptimal befunden
Muss noch mehr beachtet werden für die Fragestellung des RAID-Systems samt Speichermedien?
--> https://de.wikipedia.org/wiki/TRIM
Der 6IR ist insofern suboptimal, als das er nur Sata2 unterstützt -> wenn du eine aktuelle SSD dran hängst, bremst die Schnittstelle die auf ca. 50%
ihrer maximalen Datenrate.
Ob das bei dir wirklich ein spürbares Problem wird, kann ich dir nicht beantworten.
Es wird trotzdem noch deutlich schneller sein, als eine mechanische HDD.
Google doch einfach mal nach "Dell R310 SSD Upgrade", da finden sich diverse Händler die SSDs für den R310 anbieten.
Aus dem Bauch raus würde ich sagen -> kein Hersteller kann es sich leisten, Samsung SSDs nicht zu unterstützen.
Meine Erfahrungen mit SSD-Raids sind begrenzt auf LSI/Areca-Controller
-> da kann man auf der Herstellerseite einfach schauen, welche SSDs für den jeweiligen Controller freigegeben sind und kauft dann eine die "passt".
Geändert von drdope (06. Juli 2018 um 17:15 Uhr)
2 Updates (wieder samt Unklarheit, versteht sich...)
1)
Auch beim Vorbetreiber lief der RAM in gleicher Konstellation auf einem R310-Server nur mit 800MHz Taktfrequenz, wie er mir mitteilte, also ist es tatsächlich ein DELL R310-Kapitel für sich, dass der RAM eben heruntergetaktet wird, wenn 4 RAM-Riegel aufwärts werkeln.
2)
Ich habe mich jetzt für - aller Wahrscheinlichkeit nach - den DELL PERC H700 fast entschieden, meine anderen durchgedachten Optionen (modular-Controller) scheinen hardwaretechnisch gar nicht umsetzbar zu sein.
Was mich irritiert:
Sowohl der H200 als auch der H700 haben je 2 SAS-Anschlüsse auf dem Controller, die natürlich mit entsprechenden Kabeln versehen werden können:
Der aktuelle RAID-Controller SAS 6iR besitzt solche Anschlüsse nicht, muss also nicht separat mit den Massenspeichern konnektiert werden, sondern wird nur am PCI-Slot des Boards verbunden. Da übernimmt dann also irgendwie die Mainboard-Architektur die Festplatten-Ansteuerung...
Wenn ich jetzt den leistungsfähigeren Controller verbaue, MUSS ich denn dann die Festplatten über diese zusätzlichen Schnittstellen verstöpseln oder dürfte es auch hier reichen, die Controller-Karte per PCIe zum Board zu verbinden und das Mainboard schafft es die Festplatten zu versorgen? Die HDDs werden bisher schon über völlig eigene SATA-Kabel mit dem Mainboard konnektiert, ich wüsste gar nicht wo Kabel vom RAID-Controller da noch "ran" sollen...
Mundus vult decipi, ergo decipiatur.
Beim nochmaligen Betrachten der beiden Server - nachdem ich also wieder alles dekonnektiert und geöffnet habe- stelle ich fest, dass der "neue" Server (links im Bild) gar keine Hot Swap-Rückwandplatine besitzt (auf dem "alten" Server rechts direkt quer hinter den Festplatten verlaufend zu sehen, rechts und links je mit dem blauen Halteclip), sondern die Festplatten fest verkabelt werden müssen...
Dabei fällt mir dann auch auf, dass im "alten" Server sehr wohl 2 SAS-Anschlüsse an ebendieser Rückwand-Platine sind, da wo aktuell rechts unten und mittig unten die hellblauen Kabel fortgehen und sich zu dem SAS-Kabel mit Netzumwicklung verbinden, was auf dem Foto lose über den PSUs hängt. Dort könnte ich, wenn ich die hellblauen Kabel entferne, natürlich die beiden SAS-Kabel vom RAID-Controller dranpacken.
Dessen war ich mir vorhin beim Betrachten des neuen Server nicht bewusst, dort läuft die Laufwerk-Verkabelung komplett per SATA, ein SAS-Kabel ist da nicht zu sehen...
Mundus vult decipi, ergo decipiatur.
Berechtigungen
Zitieren
