Bestes OS für ein Fibre Channel Storage-Server

van_haakonnen

Neuling
Thread Starter
Mitglied seit
18.02.2006
Beiträge
45
Hallo zusammen,

für ein kleines Lab mit zwei ESX-Servern möchte ich gerne einen Storage-Server aufbauen. Die ESX-Hosts sollen via 4GE FC-Adapter auf das System zugreifen. Hierdurch soll VMotion, etc. möglich werden. Der Storage-Server würde einen Dual-Port-FC-HBA bekommen an den die ESX-Server direkt angeschlossen werden. Das Speichersystem bekommt eine (vorhandene) Areca Raidkarte mit 1GB Speicher und BBU.

Die Frage die sich mir nun stellt ist aber, welches Betriebssystem ich auf dem Storage-System verwenden sollte. Folgende sind mir eingefallen:
- FreeNAS > kein FC Support
- Nexenta Community > FC sollte via Console konfigurierbar sein
- OpenFiler > Keine Ahnung wie gut die FC Unterstützung ist
- OpenSolaris > keine GUI / nur CLI

Habt ihr noch andere Ideen oder Systeme die möglichst via GUI oder wenig Konsolenarbeit FC unterstützen?

Viele Grüße

VanHaakonnen
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Wenig Arbeit? Eine entsprechende NetApp hinstellen. Ansonsten mit Solaris und co. vorlieb nehmen. Für den FC-HBA im Storage-Server die Target Firmware aufspielen.
 
Mir fallen auch nur bereits fertige Systeme rein (EMC, bzw. Netapp).
GGf. könnte ne Version vom "Windows Storage Server" funktioneren. Aber wirklich freie kostenlose Möglichkeiten sehe ich nicht.
 
Zuletzt bearbeitet:
Danke für eure Ideen. Also ich habe nichts gegen basteln. Das Ganze wird ein Lab für mich privat um in dem Bereich Vmware ESX, Fibrechannel und letzendlich auch Cisco Switchen etwas besser zu werden. Dementsprechend sollte die Software nichts kosten. Eine IBM DS3xxx oder Netapp hinzustellen sprengt leider sowohl den finanziellen Rahmen alsauch drückt es den Lerneffekt auf null.

Ich hatte jetzt über ein Nexentastor nachgedacht. Leider fehlt da in der CommunityVersion die FC-Unterstützung über die GUI. Hat jemand von euch Erfahrungen damit gemacht auf dem Nexentastor NAPP-IT (napp-it.org) zu installieren? Damit müsste man die fehlende FC-Unterstützung ja nachrüsten können...

Open-E hat in der kostenfreien Fassugn ein Limit auf 2TB und kein FC-Support.
 
Hrm das ist doof, dann hat sich das geändert. Schade! Hab auch nicht mehr nachgesehen, bin davon ausgegangen, dass es noch so ist :/
 
Eine IBM DS3xxx oder Netapp hinzustellen sprengt leider sowohl den finanziellen Rahmen alsauch drückt es den Lerneffekt auf null.

Das würde ich nicht sagen, ich hab von meiner nicht von Anfang an perfekt gelaufenden CX300 ne Menge gelernt... Preislich gibt sich das anschaffungstechnisch net viel, der Unterhalt ist halt mit ~500Watt Dauerlast heftig.
 
Mal ne andere Frage, was spricht gegen iSCSI/NFS für das Lab?

Es macht in meinen Augen keinen Sinn hier unbedingt an FC festzuhalten. Auch wenn der Speed natürlich besser ist. Für ein Lab, wo es wohl primär ums Testen von Sachen geht, bzw. im allgemeinen ums Erfahrungen sammeln mit den Produkten selbst/der Software selbst, spielt das aber wohl denke ich ne untergeordnete Rolle.

Ansonsten rein von der ESX(i) Seite her ist es schnurz egal, wie das zentrale Storage angebunden ist... Es muss nur eben zentral angebunden sein und nicht intern in den Hosts selbst.
Ich frage deshalb, weil einerseits der Kostenaufwand für ein schnödes iSCSI/NFS Storage Serversystem weit geringer sein sollte (keine HBAs, eine umständliche Konfiguration, vorhandene 1GBit Verbindungen können genutzt werden) und andererseits der reine Lernfaktor allein auf FC bezogen sich der Sache nur unwesentlich annimmt. Denn stellt man da ein FC SAN hin, womöglich mit doppelt Redundant angebundenen FC Switches, bzw. spricht noch über mögliche HA Lösungen und Co. bringt dich die Sache da absolut nicht weiter mit dem selfmade FC Storage Server ;) Für die interessanten FC Geschichten fehlt dann wohl wieder das "Kleingeld" für die Hardware selbst.
 
Mal ne andere Frage, was spricht gegen iSCSI/NFS für das Lab?

Es macht in meinen Augen keinen Sinn hier unbedingt an FC festzuhalten. Auch wenn der Speed natürlich besser ist. Für ein Lab, wo es wohl primär ums Testen von Sachen geht, bzw. im allgemeinen ums Erfahrungen sammeln mit den Produkten selbst/der Software selbst, spielt das aber wohl denke ich ne untergeordnete Rolle.

Ansonsten rein von der ESX(i) Seite her ist es schnurz egal, wie das zentrale Storage angebunden ist... Es muss nur eben zentral angebunden sein und nicht intern in den Hosts selbst.
Ich frage deshalb, weil einerseits der Kostenaufwand für ein schnödes iSCSI/NFS Storage Serversystem weit geringer sein sollte (keine HBAs, eine umständliche Konfiguration, vorhandene 1GBit Verbindungen können genutzt werden) und andererseits der reine Lernfaktor allein auf FC bezogen sich der Sache nur unwesentlich annimmt. Denn stellt man da ein FC SAN hin, womöglich mit doppelt Redundant angebundenen FC Switches, bzw. spricht noch über mögliche HA Lösungen und Co. bringt dich die Sache da absolut nicht weiter mit dem selfmade FC Storage Server ;) Für die interessanten FC Geschichten fehlt dann wohl wieder das "Kleingeld" für die Hardware selbst.

*sign*
 
Das es aus ESX-Sicht nicht viel Unterschied macht ist mir bewusst.. Auch iSCSI kann man redundant anbinden. Klar - auch die Kosten sind bei iSCSI zu vernachlässigen. Andererseits: 4Gbit PCI-E HBAs kosten gebraucht ca. 75 Euro... Das ist es mir in dem Moment wert. Ich brauche einfach mal wieder eine Herausforderung ;)

Aber aus der vernünftigen Sichtweise habt ihr recht.
 
Sind immerhin 225€, welche wohl besser in den Hosts bzw. im VCenter aufgehoben sind ;)
Geht man gar mal nen Schritt weiter, bgzl. Backups. Je nachdem wie du diese anstellst bzw. dich da einlernen willst. Kann es schon Sinn machen die Backup Maschine auch ans Storage zu koppeln. Das bringt Speedvorteile ohne Ende ;) Da eben nicht via SMB kopiert wird sondern direkt auf Blockebene... Sofern das Backuptool das kann. Aber sowas bekommt man eben nur dann mit, wenn man die Möglichkeit hat. Mit nem DualPort HBA und zwei Hosts wäre diese nicht gegeben. Ich würds wie gesagt nicht machen...
 
Hardwareluxx setzt keine externen Werbe- und Tracking-Cookies ein. Auf unserer Webseite finden Sie nur noch Cookies nach berechtigtem Interesse (Art. 6 Abs. 1 Satz 1 lit. f DSGVO) oder eigene funktionelle Cookies. Durch die Nutzung unserer Webseite erklären Sie sich damit einverstanden, dass wir diese Cookies setzen. Mehr Informationen und Möglichkeiten zur Einstellung unserer Cookies finden Sie in unserer Datenschutzerklärung.


Zurück
Oben Unten refresh