ESX / ESXi - Hilfethread
- Ersteller XTaZY
- Erstellt am
LichtiF
Enthusiast
Und du hast ihn nicht verstanden 
Für deine Karte gibt es offiziell keine Treiber für ESXi da musst du selbst Treiber einbinden für die restlichen Karten gibt es offizielle Unterstützung von Vmware.
Hier mal ein Beispiel:
VMware Front Experience: How to make your unsupported SATA AHCI Controller work with ESXi 5.5 and 6.0
Für deine Karte gibt es offiziell keine Treiber für ESXi da musst du selbst Treiber einbinden für die restlichen Karten gibt es offizielle Unterstützung von Vmware.Hier mal ein Beispiel:
VMware Front Experience: How to make your unsupported SATA AHCI Controller work with ESXi 5.5 and 6.0
teqqy
Enthusiast
Unterstützt ESXi den Spindown von Festplatten, wenn man deinen kompletten Controller durchreicht? Mein blödes XPenology schafft das anscheinend nicht (trotz IT Firmware auf dem LSI 3008). Wenn es funktioniert womit habt ihr es hin bekommen?
LichtiF
Enthusiast
Bei XPenology 5.2 ging soweit ich weiß kein Spindown bei 5.1 hatte das noch funktioniert.
fdiskc2000
Enthusiast
- Mitglied seit
- 30.05.2007
- Beiträge
- 2.230
Das sollte ähnlich wie bei einer bare metal Installation gehen. Man muss nur bedenken, dass einige Dienste einen SpinDown verhindern. Ist bei originalen Synology genau so. Wenn Du danach googelst kann man eine Liste der Dienste finden, welche da Probleme machen.
Zum Test einfach mal alles deaktivieren. Und die Zeiten die eingestellt ist nicht 100% genau stoppen, sondern ruhig 100% Aufschlag geben.
Zum Test einfach mal alles deaktivieren. Und die Zeiten die eingestellt ist nicht 100% genau stoppen, sondern ruhig 100% Aufschlag geben.
Der M1015 ist sehr zu empfehlen. Und den bekommst du in der Bucht locker für 70-90€.
Habe ihn selber über nem Jahr in Betrieb gehabt.
Ich habe gestern eine meiner Ubuntu 12.04 LTS Versionen auf die Version 14.04 gebracht. Funktioniert soweit alles gut.
Das einzige, was mich wirklich stört: die Kiste verbraucht jetzt fast 12Watt mehr als vorher.
Fahre ich die virtuelle Machine herunter, liegt der Stromverbrauch des ESXI-Servers im Leerlauf ohne aktive virtuelle Maschine auf den gleichen iDLE werten wie zuvor auch.
Wo kann ich nun Strom einsparen ?
Das einzige, was mich wirklich stört: die Kiste verbraucht jetzt fast 12Watt mehr als vorher.
Fahre ich die virtuelle Machine herunter, liegt der Stromverbrauch des ESXI-Servers im Leerlauf ohne aktive virtuelle Maschine auf den gleichen iDLE werten wie zuvor auch.
Wo kann ich nun Strom einsparen ?
besterino
Legende
Was treibt denn die VM? Was sagt darin die CPU-Auslastung?
besterino
Legende
Ich würd der einfach mal ein paar Stunden nach dem Update geben. Vielleicht laufen halt noch weitere Einzelupdates, Indizierungen usw. die für Last sorgen. Wenn die Last nach einer Nacht immer noch hoch ist, würde ich eher Ursachenforschung als Begrenzung betreiben.
Das ist eine Ubuntu minimal Installation. Da läuft nur ein Unifi-Controller. Keine weitere Software aus anderen Quellen.
Habe mal eben schnell direkt 14.04 installiert. Das gleiche "Problem". Unter Ubuntu 12.04 alles kein Problem.
Natürlich gebe ich dir recht, aber da lohnt sich der Aufwand nicht. Kein Prozess dümpelt bei mehr als 10% CPU last.
Habe mal eben schnell direkt 14.04 installiert. Das gleiche "Problem". Unter Ubuntu 12.04 alles kein Problem.
Natürlich gebe ich dir recht, aber da lohnt sich der Aufwand nicht. Kein Prozess dümpelt bei mehr als 10% CPU last.
Wer den Vmware Hostclient einfach und auch unter ESXI 5.5 installieren will:
VMware Front Experience: An important heads-up for users of the Embedded Host Client!
SSH aktivieren, per Putty auf den ESXi verbinden und den vierzeiler ausführen.
VMware Front Experience: An important heads-up for users of the Embedded Host Client!
SSH aktivieren, per Putty auf den ESXi verbinden und den vierzeiler ausführen.
Wenn die Last der VM vor dem Update deutlich geringer war als nach dem Update, dann ist da grundsätzlich was faul.
Das entscheidende ist dabei ja nicht, ob ein Prozess hohe Last erzeugt, sondern die Summe der Last erzeugenden Prozesse... Wenn dort bei dir bei 12.04 wenig bis keine Last im Betrieb zu sehen ist und nach dem Update auf 14.04 Last von verschiedenen Diensten/Prozessen hohe Gesamtlast erzeugt, dann kann da einfach was nicht richtig sein. Vor allem, wenn du sagst, die Kiste macht effektiv sogut wie nix.
An deiner Stelle würde ich mir selbst den Gefallen tun und einfach mal schauen, was dort das Problem ist.
Die Begrenzung der CPU Ressourcen auf ein Minimum ist dabei der grundsätzlich falsche Weg. -> denn damit gibst du der VM schlicht keine Rechenzeit mehr... Alles was dort läuft und CPU Leistung "frisst", wird nun gezwungen, langsamer zu laufen... Ein komischer Ansatz das Problem zu lösen
Ansonsten, warum von 12.04 auf 14.04? Aktuell ist doch die 16.04 LTS... Wäre ggf. noch einen Test wert.
Ich habe auf der Arbeit eine ganze Latte von 14.04er Ubuntus am laufen. Bis auf wenige Ausnahmen alle samt minimal + benötigte Dienste. Da ist keine dabei, die CPU Leistung frisst, wenn es nicht von einem Dienst dediziert notwendig ist.
morumbinas
Enthusiast
- Mitglied seit
- 01.12.2007
- Beiträge
- 403
Nur mal so ne Frage: Warum soll man für ein NAS einen eigenen Controller nehmen? Ich kann ja auch ganz normal die Festplatten durchreichen, also warum dafür einen eigenen Controller? Ich hab das jetzt mehrfach schon gelesen...
Und wo hast du die Datastores z.b.?
Ich kann mir gut vorstellen, dass das Probleme geben könnte, wenn man ein RAID einsetzt.
Ich habe mein NAS (Openmediavault) auch als VM in ESXi. Die Platten sind einzeln durchgereicht ((noch) kein separater Controller), in ext4 formatiert und mit SnapRAID (aufs) on top. So sind das alles Einzelplatten und das sollte kein Problem darstellen, da SnapRAID kein richtiges RAID ist. Bei sowas kannste auch locker die Platten einzeln durchreichen, sofern SnapRAID für dein NAS überhaupt sinnvoll ist.
Der Hintergrund ist wohl eher theoretischer Natur.
Beim durchreichen eines ganzen Controllers übergibt man eben den Controller samt HDDs direkt der VM. Die VM bzw. das Gast OS ist damit Herr über die Platten und den Controller. Alles was du physisch mit dem Ding machen kannst, kann damit die VM tätigen. Inkl. solcher Sachen wie Smart Daten auslesen, Temperaturen auslesen usw.
Beim Durchreichen via RDM hat der Host die Finger einerseits auf dem Controller und andererseits wird nicht direkt die Platte als physisches Gerät weitergegeben, sondern es wird eine Art virtueller Container erstellt, der auf die physische Platte mappt. Bin mir gerade nicht ganz sicher ob du damit überhaupt Smart Daten und Temperaturen in der VM sehen würdest?
Die dritte Möglichkeit wäre, die Verwaltung komplett beim Host zu lassen und nur VMDK Container an die VM zu reichen. Geht technisch gesehen auch, allerdings sieht die VM dann gar nix von der physik, nix mit Smart, nix mit Temperaturen und auch nix mit dedizierten Befehlen an die Physik.
Der optimale Weg sollte das Durchreichen des ganzen Controllers sein, welcher bestenfalls auch nur ein HBA sein sollte. Also ohne Raidfunktionen. So dass eben die Platten als einzelne Devices an der VM ankommen. Funktionalitäten für Redundanzen und Spieglungen nutzt man dann in Software auf/in der VM. Eben mit einem ZFS fähigen System bspw. mit allen Vor- und Nachteilen davon.
Am Ende ist immer entscheidend, was du genau damit vor hast. Das Durchreichen von Geräten schränkt möglicherweise die Funktion der VM etwas ein. Bspw. wirst du keine Snapshots mehr machen können. Bei einem RDM Mapping muss das nicht zwingend der Fall sein
Beim durchreichen eines ganzen Controllers übergibt man eben den Controller samt HDDs direkt der VM. Die VM bzw. das Gast OS ist damit Herr über die Platten und den Controller. Alles was du physisch mit dem Ding machen kannst, kann damit die VM tätigen. Inkl. solcher Sachen wie Smart Daten auslesen, Temperaturen auslesen usw.
Beim Durchreichen via RDM hat der Host die Finger einerseits auf dem Controller und andererseits wird nicht direkt die Platte als physisches Gerät weitergegeben, sondern es wird eine Art virtueller Container erstellt, der auf die physische Platte mappt. Bin mir gerade nicht ganz sicher ob du damit überhaupt Smart Daten und Temperaturen in der VM sehen würdest?
Die dritte Möglichkeit wäre, die Verwaltung komplett beim Host zu lassen und nur VMDK Container an die VM zu reichen. Geht technisch gesehen auch, allerdings sieht die VM dann gar nix von der physik, nix mit Smart, nix mit Temperaturen und auch nix mit dedizierten Befehlen an die Physik.
Der optimale Weg sollte das Durchreichen des ganzen Controllers sein, welcher bestenfalls auch nur ein HBA sein sollte. Also ohne Raidfunktionen. So dass eben die Platten als einzelne Devices an der VM ankommen. Funktionalitäten für Redundanzen und Spieglungen nutzt man dann in Software auf/in der VM. Eben mit einem ZFS fähigen System bspw. mit allen Vor- und Nachteilen davon.
Am Ende ist immer entscheidend, was du genau damit vor hast. Das Durchreichen von Geräten schränkt möglicherweise die Funktion der VM etwas ein. Bspw. wirst du keine Snapshots mehr machen können. Bei einem RDM Mapping muss das nicht zwingend der Fall sein
onlyReaver
Enthusiast
- Mitglied seit
- 07.07.2013
- Beiträge
- 316
Das Durchreichen von Geräten schränkt möglicherweise die Funktion der VM etwas ein. Bspw. wirst du keine Snapshots mehr machen können. Bei einem RDM Mapping muss das nicht zwingend der Fall sein
Nicht nur das.
- Keine Snapshots
- Keine Hochverfügbarkeit
- Keine Fault Tolerance
- Kein vMotion
- Kein DRS
- Kein anhalten des Gastsystemes
- Kein Pagesharing/Speicherüberbelegung
- Kein Hotplug von Geräten bzw. Festplatten
Somit sind quasi alle Vorteile von vSphere damit ausgehebelt, da sollte man sich wirklich zwei mal Überlegen ob man solche Basteleien machen mag.
Natürlich ist das im Privaten Umfeld eine andere Sache. Für den Halbwegs produktiven Einsatz ist DirectPath fast undenkbar, nur in sehr seltenen Fällen sinnvoll.
Hardware Pass-through macht man meist dann, wenn man keinen extra SAN Storageserver haben möchte, sondern dieses virtualisieren möchte - aus Gründen der Performance, um jedem ESXi sein eigenes SAN zu geben oder um weniger Server zu haben. Man muss aber darauf achten, dass man das Storage OS problemlos virtualisiseren kann, aber keinesfalls das Storage/ die Platten.
Die genannten Einschränkungen sind uninteressant.
Snapshots: Macht man eh unter dem SAN z.B. ZFS, da gibts auch die ESXi Snapshot Einschränkungen nicht
Hochverfügbarkeit: Ist für die SAN VM egal, wenn man das braucht geht das auf SAN Service Level z.B. iSCSI oder NFS
Hotplug von Festplatten: Eine der Gründe für Pass-through, das ist alles Sache des SAN und geht natürlich problemlos mit pass-through
Der Rest: interessiert nicht für die Storage VM, die kann man ohne die Platten eh nicht verschieben
besterino
Legende
Sehe ich auch so: vMotion und Co gehen davon aus, dass da irgendwo ne SAN dranhängt und die ESXi Kisten darauf zugreifen. Hattu keine SAN, mussu andere Lösung finden...
Neja, auf nem Single Host mag das zutreffen. Im Verbund hingegen ist das schon eklatant... Wenn du die Storage VM nicht aus welchen Gründen auch immer migrieren kannst, ist nix mit Host Wartung. Die macht man ja nicht, weil man das gut findet, sondern weil es teils notwendig ist. Bugs, Security Issues usw.
Die einzige Möglichkeit das zu lösen wäre mehrere dieser Storage VMs aufzuziehen und via Host/Storage VMotion die VMs komplett umzuziehen. Geht natürlich auch, ist halt etwas mehr Aufwand...
Die vollredundante geclusterte externe SAN Lösung via NFS/iSCSI/FC/FCoE oder gar SAS an die Hosts würde das möglich machen... Bietet dafür aber idR nicht die Vorteile einer ZFS based Storagelösung.
Wie so oft gilt, die Wahl der Lösung muss zum Anwendungsfall passen. So ne Storage VM Zuhause im HomeLab auf dem Blech zu betreiben ist aus meiner Sicht doch recht sinnvoll. Vor allem spart man "Blech". Und die Platten brauch es sowieso... ZFS Vorteile dann noch mitzunehmen kommt auch gut. In größeren Umgebungen halte ich diese "Bastellösung", denn was anderes ist es im Endeffekt ja nicht, für nach wie vor eher unüblich/untypisch. Sicher gibt es Fälle, wo man sowas einsetzt. Im Großen und Ganzen zumeist aber eher nicht. Das Thema mit dem Support/der Zertifizierung ist ja auch noch so eine Sache. Kann man sich selbst ja nichtmal groß gegen zur Wehr setzen, wenn Hersteller XY für Software AB da irgendwelche Vorgaben tätigt und Bedingungen kreiert.
Das wäre ja auch mit dieser Lösung gegeben... Nur brauch es eben halt mehrere davon, sonst wird das nix
Eine Storage VM auf einen anderen Host migrieren geht grundsätzlich nicht da man den physikalischen Storage nicht mit migrieren kann - das sind ja lokale, reale Festplatten. Ansonsten ist das Handling eines virtualisierten SAN identisch zum Handling eines dedizierten SAN. ESXi ist es ja auch egal ob der NFS oder iSCSI Storage auf einem fremden Server liegt oder von ESXi selber per VM bereitgestellt wird. Man kann nur die Daten selber z.B. auf dem NFS Storage migrieren.
Man muss hier den Wartungsaspekt immer als Kombination ESXi + Storage sehen, fast so wie bei lokalem ESXi Storage. Wenn man eine Wartung ohne downtime machen wollte, muss man natürlich die VMs und den NFS oder iSCSI Storage migrieren oder eben einen HA Mechanismus bereitstellen, der den Storage switched. Das Handling eines virtuellen SAN unterscheidet sich damit in keiner Weise von einem SAN auf dedizierter Hardware. Bei einer ESXi Wartung ist ein SAN Down nicht relevant da der Storage ja primär für den lokalen ESXi Host bereitgestellt wird. Die Idee dahinter ist ja, dass jeder ESXi Host sein eigenes lokales SAN hat - als Alternative zu dem dicken zentralen SAN für alle, das niemals ausfallen darf. Der wechselweise Zugriff wird nur im Problemfall oder zum Transfer der VMs benötigt. Lediglich im Heim- oder Laborbereich nutzt man das virtualisierte SAN auch als normalen Filer, für ESXi geht es um Ersatz des lokalen Datatastores mit den Möglichkeiten, die ein ZFS SAN hat (Cache, Snaps, Replikation, einfacher Zugriff für Backup/Clone/Move, Sicherheit etc)
Ansonsten ist ein Recovery der SAN VM z.B. nach einem Crash im Minutenbereich erledigt. Die VM als Template importieren, den Pool importieren, NFS aktivieren und ESXi hat wieder Zugriff auf seine VMs. So schnell geht kein Recovery eines echten SAN.
Eine Storage VM mit Spiegelung ist in der Praxis oftmals als "Billig" SAN im produktiven Einsatz. Selbst VMware hatte mit der "vSA" ( VMware vSphere Storage Appliance (vSA) for Shared Storage | VMware Österreich ) für einige Jahre eine entsprechende Lösung im Angebot.
onlyReaver
Enthusiast
- Mitglied seit
- 07.07.2013
- Beiträge
- 316
Ist nur schon lange ersetzt durch die immer häufiger anzutreffende vSAN Lösung. Die übrigens immer stärker supported wird, und auch immer öfter anzutreffen ist, sogar in größeren Produktiven Umgebungen.
Gerade mit der neuen Version 6.2 ist Deduplication & Compression, Checksummen, etc. dabei. vSAN wäre der einzige Grund warum ich Festplatten lokal in vSphere Hosts verbauen würde, sonst für nichts anderes.
Übrigens beherbergen "dedizierte" SAN Systeme praktisch nur noch virtuellen Storage. Am Ende kann jede SAN mindestens Snapshots, Replikation, irgendeine Art von Prüfsummen bzw. Healthchecks und so weiter.
Selbst in kleinen Umgebungen hat man eher mindestens 2 SAN statt nur eines, so das ein Komplettausfall praktisch keinen fühlbaren Einfluss auf die Infrastruktur hat, um danach gemütlich dem Problem entgegenzugehen.
Ich selbst hätte auch keine Lust bei >5 Hosts oder gar 20 oder 100 auf jedem einzelnen einen lokalen Storage zu haben. Mal ganz abgesehen von der Umsetzung einer Hochverfügbarkeit sowie der Performance.
Ein "Recovery" in gewohnten Umgebungen läuft folgendermaßen ab: Storage fällt aus => Ein anderer Groupmember übernimmt den LUN => VMs sind ohne oder nur mit kurzer Verzögerung weiterhin Online.
Weiteres Ersatz-SAN wird in die Group eingebunden, LUNs werden automatisch auf den neuen Member repliziert, Redundanz ist wiederhergestellt. (Wenn nicht sowieso noch vorhanden)
Habe bis jetzt allerdings noch keinen einzigen Ausfall einer SAN erlebt. Höchstens mal eine Platte wechseln, dann war wieder Ruhe. Aber wie auch, je Member ist alles mindestens doppelt vorhanden.
Über Storage kann man sich lange streiten, jeder hat eine andere Auffassung, Ansprüche und vor allem Größenordnungen in denen er arbeitet. Irgendwo gibt es halt für jede Lösung eine Grenze.
Storagevirtualisierung ermöglicht lediglich den physikalischen Storage dynamisch zu strukturieren, zu limitieren oder garantieren und bereitzustellen, ohne dass man z.B. eine Größe oder Partition festlegen muss. Letztlich brauchts aber unterhalb der logischen Struktur physikalische Platten, entweder am zentralen SAN oder im Fall des virtualisierten SAN am ESXi Host. Das gegenseitige Bereitstellen via iSCSI, FC, NFS oder SMB ist davon unabhängig.
Aber ganz klar ist es eine konzeptionelle Frage ob man Storage lokal/dezentral per virtualisisertem SAN OS oder per ein oder zwei dicken zentralen SANs mit eigener Hardware bereitstellt. Es ist auch eine Preisfrage.
Ein lokales virtualisiertes SAN braucht üblicherweise wenige SSDs ab einem Mirror - ausreichend für den lokalen Host um damit 10G Performance und 10k-80k iops für die lokalen VMs bereitzustellen. Die Extra Kosten belaufen sich auf die SSDs und den lokalen HBA Controller neben einer etwas dickeren CPU und Extra RAM für die Storage VM. Ein zentrales SAN muss ganz anders dimensioniert sein, um auch nur annähernd die gleiche Performance zu liefern. Dazu kommt dass ein virtualisiertes SAN intern zwischen ESXi und Storage in Software arbeitet. Bei einem externen SAN brauchts redundante 10G Netze für auch nur annähernd ähnliche Performance und Ausfallsicherheit.
Zuletzt gibts den Kosten und Komplexitätsfaktor. Ein hochverfügbares zentrales SAN z.B. von NetApp ist von den Kosten und der Komplexität ein ganz anderes Kaliber als kleine dezentrale virtualisierte SAN Lösungen zumal da auf kompliziertes HA/active/active Failover verzichtet wird und man mit Replikation auf ein Backupsystem arbeitet von dem man die VMs im Problemfall hochfährt. Alternativ schiebt man die SSDs mit dem ZFS Pool in ein anderes System ein, importiert dort den Pool und fährt die VMs wieder hoch. Downtime für die lokalen VMs liegt bei max 30 Minuten falls der ESXi Host samt lokalem Storage plötzlich komplett den Geist aufgibt und man die SSDs zu einem anderen ESXi switchen muss oder man die VMs von einem anderen ESXi und vom replizierten Backup hochfahren muss. Alle anderen VMs sind eh nicht betroffen, die haben ja ihr eigenes SAN. Im Fehlerfall eine simple Standardprozedur.
Damit ist auch klar, wo man was nimmt. Die Lösung virtualisiertes NAS/SAN gibts ja nicht von NetApp und Konsorten. Das ist typischerweise OpenSource mit einer ZFS Storageappliance auf Basis einer BSD oder Solaris Variante wie mein ZFS Storageserver Template. Damit gibts zwar durchaus ähnliche Features wie bei einer netApp aber kein SLA mit 4 Stunden Reaktionszeit. Man ist also selber verantwortlich. Das ist daher keine Lösung für jede Firma. Es handelt sich aber um recht einfach zu beherrschende Systeme, daher auch der häufige Einsatz z.B. im Labor oder wie bei mir im Hochschulbereich. Es gibt aber auch kommerzielle Installationen, meist in USA wo Solaris und ZFS einfach häufiger genutzt wird als hier in DE.
Zuletzt bearbeitet:
Hallöchen,
ich hatte hier neulich schonmal bezüglich eines RAID-Controllers gefragt, da hatte ich so einen Billig-Controller rausgesucht. Ich habe mir ein wenig Gedanken gemacht und halte es durchaus für sinnvoll, da etwas mehr auszugeben. Es sollte Neuware sein, aber nicht mehr als 200€ kosten (zumindest nicht viel mehr).
Mainboard ist ein ASUS P10S-I. Wenn die Karte länger als der PCIe-Slot ist, sollte die Karte nur Low-Profile sein, da es hinten etwas enger wird.
Von ASUS selbst wird dieser hier vorgeschlagen: ASUS PIKE II 3008-8i Preisvergleich | Geizhals Deutschland
Der Chipsatz wird sogar von ESXi unterstüzt. Problem ist nur, dass das Teil nirgends lieferbar ist. Bin jetzt auch nicht wirklich bewandert, was RAID-Controller angeht. Also, was man kaufen sollte und was nicht ...
Ich habe übrigens nicht vor, die RAID-Funktion des Controllers zu nutzen. Es geht mir einzig darum, mehr Festplatten anschließen zu können.
Also ... Vorschläge?
ich hatte hier neulich schonmal bezüglich eines RAID-Controllers gefragt, da hatte ich so einen Billig-Controller rausgesucht. Ich habe mir ein wenig Gedanken gemacht und halte es durchaus für sinnvoll, da etwas mehr auszugeben. Es sollte Neuware sein, aber nicht mehr als 200€ kosten (zumindest nicht viel mehr).
Mainboard ist ein ASUS P10S-I. Wenn die Karte länger als der PCIe-Slot ist, sollte die Karte nur Low-Profile sein, da es hinten etwas enger wird.
Von ASUS selbst wird dieser hier vorgeschlagen: ASUS PIKE II 3008-8i Preisvergleich | Geizhals Deutschland
Der Chipsatz wird sogar von ESXi unterstüzt. Problem ist nur, dass das Teil nirgends lieferbar ist. Bin jetzt auch nicht wirklich bewandert, was RAID-Controller angeht. Also, was man kaufen sollte und was nicht ...
Ich habe übrigens nicht vor, die RAID-Funktion des Controllers zu nutzen. Es geht mir einzig darum, mehr Festplatten anschließen zu können.
Also ... Vorschläge?
Bei dem Controller handelt es sich um eine OEM Version eines
SAS 9300-8i Host Bus Adapter
Der ist schnell und ideal um lediglich Festplatten ohne Raid anzuschließen.
Dazu gibt es eine spezielle Firmware (IT Firmwatre) ohne Raid
Gute Alternativen kommen alle von LSI/ Broadcom z.B.
LSI 9207 (serienmäßig IT Firmware)
LSI 9211 oder OEM Varianten wie IBM M1015
SAS 9300-8i Host Bus Adapter
Der ist schnell und ideal um lediglich Festplatten ohne Raid anzuschließen.
Dazu gibt es eine spezielle Firmware (IT Firmwatre) ohne Raid
Gute Alternativen kommen alle von LSI/ Broadcom z.B.
LSI 9207 (serienmäßig IT Firmware)
LSI 9211 oder OEM Varianten wie IBM M1015
Habe mir mal ein paar rausgesucht, die was zu taugen scheinen und nicht zu teuer wären. Dachte, hier gäbe es irgendwie sowas wie einen Geheimtipp, aber das scheint wohl nicht zu sein. Wobei ich Empfehlungen für den M1015 schon häufiger gelesen habe. Allerdings gibt es auf Geizhals keinen gelisteten Shop aus Deutschland, der die noch hat und ich würde nur ungern im Ausland bestellen.
Also: Mein Favorit wäre der HP H220, allerdings könnten die Anschlüsse, die nach hinten führen zu Platzproblemen führen. Schade.
Im akzeptablen Preisrahmen fielen mir noch der Dell PERC H200 und der IBM ServeRAID M5110 ins Auge.
Und da bräuchte ich eure Meinung. Welchen? Und warum? Sorry, wenn meine Fragen grad blöde klingen, aber ich will auch nicht einfach irgendeinen Müll kaufen.
Ob die Karte es schafft, alle Ports gleichzeitig wirklich mit 6 Gb/s zu versorgen, ist nicht so wichtig, da ich nicht vorhatte, SSDs anzuschließen.
//Edit: Hat sich schon wieder fast erledigt. Der Dell PERC H200 ist fast nirgends lieferbar ... Was haltet ihr von dem M5110?
Also: Mein Favorit wäre der HP H220, allerdings könnten die Anschlüsse, die nach hinten führen zu Platzproblemen führen. Schade.
Im akzeptablen Preisrahmen fielen mir noch der Dell PERC H200 und der IBM ServeRAID M5110 ins Auge.
Und da bräuchte ich eure Meinung. Welchen? Und warum? Sorry, wenn meine Fragen grad blöde klingen, aber ich will auch nicht einfach irgendeinen Müll kaufen.
Ob die Karte es schafft, alle Ports gleichzeitig wirklich mit 6 Gb/s zu versorgen, ist nicht so wichtig, da ich nicht vorhatte, SSDs anzuschließen.
//Edit: Hat sich schon wieder fast erledigt. Der Dell PERC H200 ist fast nirgends lieferbar ... Was haltet ihr von dem M5110?
Zuletzt bearbeitet:
besterino
Legende
Zum M5110 hab ich keine Erfahrung. Frage nur mal vorsichtig, ob es denn wirklich Neuware sein muss? Bei Ebay kannst Du da schon ein paar Taler sparen.
Es sollte zumindest von einem Händler kommen, wegen Rückgabe, Garantie, etc ... Möchte daher nicht von Privat kaufen, das hat in der Vergangenheit schon zu Ärger geführt.
Wenn ihr mir sagt, dass 200€ ein scheiß Budget ist für solche Controller und ich sollte eher 250€ einplanen, dann ist das okay. Ich hatte mir die 200€ nur als Limit gesetzt, könnte aber auch das Limit anheben, wenn ihr meint, dass ich da nichts passendes finde.
Allerdings hätte ich jetzt auch keine Lust, mir einen Controller für 500€ oder so zu kaufen. Das wäre mir das Geld nicht wert.
Ich suche in erster Linie eine sichere (stabile) Möglichkeit, mehr Platten anschließen zu können, die so preiswert wie möglich sein soll.
Wenn ihr mir sagt, dass 200€ ein scheiß Budget ist für solche Controller und ich sollte eher 250€ einplanen, dann ist das okay. Ich hatte mir die 200€ nur als Limit gesetzt, könnte aber auch das Limit anheben, wenn ihr meint, dass ich da nichts passendes finde.
Allerdings hätte ich jetzt auch keine Lust, mir einen Controller für 500€ oder so zu kaufen. Das wäre mir das Geld nicht wert.
Ich suche in erster Linie eine sichere (stabile) Möglichkeit, mehr Platten anschließen zu können, die so preiswert wie möglich sein soll.