Archiv verlassen und diese Seite im Standarddesign anzeigen : SuSE 9.x o. 10.x mit iSCSI auf NetApp Filer
Hallo,
wir haben zwei Suse 10.0 mit laufendem Vmware GSX Server und Vmware Server. Nachdem wir nun einen NetApp Filer FAS270c erhalten haben, will ich diese Server an die Suse´s binden. Dies soll mit iSCSI geschehen.
Entweder per Initiator oder per iSCSI-Netzwerkkarte.
Im Forum hier wird einiges berichtet, meistens in Verbindung mit SLES9.
Jetzt will ich wissen, ob ein iSCSI-Betrieb mit Suse 10.0 auch möglich ist. Ich würde viel Zeit ersparen, wenn jemand seine Erfahrungen posten könnte.
Gruss
Mull
Sorry für den aufgewärmten Thread. Ja geht, open-iSCSI ist dein Freund. Für die 10.0 wirst du dir das selber backen müssen, bei der 10.1 ist es dabei. Das ist aber lediglich ein iSCSI Initiator, kein Target.
Das ist aber lediglich ein iSCSI Initiator, kein Target.
Das sollte unkritisch sein, denn so wie ich ihn verstanden habe ist der netapp das target. Ich kenne auch keinen iSCSI Initiator von NetApp. Nur auf FC-Basis.
Den Linux Rechner als Initiator zu nehmen ist unkritisch und relativ simpel. Wenn du aber beim durchsatz über ein 100MBit/s Netzwerk hinaus willst und die ISCSI LUN's wirklich datenbewegungen haben werden, solltest du auf eine Hardware-.iSCSI Karte zurückgreifen. Die sind teurer, weil sie eine eigene CPU mitbringen um den TCP/IP Stack abzuarbeiten. Ansonsten macht das die CPU des Servers und als Faustregel gilt: pro 1GBit/s (Netz) frist das ca. 1 Ghz Rechenleistung.
Bei Hardware iSCSI Karten sollte man aber den Vergleich zu FC Karten anstellen.
Vermutlich wird da bei Euch aber wieder eine FC Lizenz auf dem Filer notwendig und die iSCSI-Karte ist in der Summe auf jeden Fall günstiger.
Hinzu kommt, dass auch der NetApp keine iSCSI Hardwarekarte hat und die 270er eher die "kleineren" NetApps sind.
Insofern ist die Frage, ob es überhaupt Sinn macht auf Gigabit Ethernet hochzugehen oder einfach, ganz solide über 100MBit/ s anzuschließen....
Gruß, Borner
Das sollte unkritisch sein, denn so wie ich ihn verstanden habe ist der netapp das target.
Korrekt. Da es aber kein Paket gibt, welches Target und Initiator vereint, ist der Hinweis notwendig. Wenn er iSCSI Enterprise Target verwendet, kann er nicht als Initiator funngieren.
Ich kenne auch keinen iSCSI Initiator von NetApp. Nur auf FC-Basis.
FC im Sinne von "SCSI-3 ist ULP und SCSI arbeitet nach dem Prinzip Target / Initiator"?
Den Linux Rechner als Initiator zu nehmen ist unkritisch und relativ simpel.
Siehe mein Thread. Open-iSCSI steht nach 5 Minuten, sofern GCC, make, Kernel-Sorucen und db-devel vorhanden sind.
Wenn du aber beim durchsatz über ein 100MBit/s Netzwerk hinaus willst und die ISCSI LUN's wirklich datenbewegungen haben werden, solltest du auf eine Hardware-.iSCSI Karte zurückgreifen. Die sind teurer, weil sie eine eigene CPU mitbringen um den TCP/IP Stack abzuarbeiten.
Man nannte es auch TCP/IP Offload Engine. :rolleyes: iSCSI HBAs machen in jedem Fall Sinn, da man sich hier auch den ganzen Softwarekram spart und auch problemlos von iSCSI Targets booten kann. Wenn man einen Software-Initiator nimmt, muss man da etwas mit initrd usw. rumtricksen.
Ansonsten macht das die CPU des Servers und als Faustregel gilt: pro 1GBit/s (Netz) frist das ca. 1 Ghz Rechenleistung.
Wobei ein Opteron mit open-iSCSI eine normale GigEth-Karte zum Anschlag bringt. Daher kann es durchaus Sinn machen über mehrere Pfade zum Target zu gehen.
Bei Hardware iSCSI Karten sollte man aber den Vergleich zu FC Karten anstellen.Vermutlich wird da bei Euch aber wieder eine FC Lizenz auf dem Filer notwendig und die iSCSI-Karte ist in der Summe auf jeden Fall günstiger.
Also einen iSCSI HBA gegen einen FC-HBA antreten zu lassen ist unfair. FC ist teurer, hat aber auch seine deutlichen Vorteile gegenüber iSCSI.
Hinzu kommt, dass auch der NetApp keine iSCSI Hardwarekarte hat und die 270er eher die "kleineren" NetApps sind.
Insofern ist die Frage, ob es überhaupt Sinn macht auf Gigabit Ethernet hochzugehen oder einfach, ganz solide über 100MBit/ s anzuschließen....
Kommt auf die geforderte Performance an. Alternativ Multipathing nutzen, wobei ich nicht weiß ob der Filer das kann. Ich bin weiß Gott kein NetApp-Experte, ich bin da eher auf "reine" Primärspeicherlösungen spezialisiert.
....ganz schöner Klug******er! :-P *G*
sorry...
FC im Sinne von "SCSI-3 ist ULP und SCSI arbeitet nach dem Prinzip Target / Initiator"?
Der Hintergrund zu meiner Aussage besteht darin, dass man einen NetApp einfach nicht als Nutzer einer iSCSI Lun konfigurieren kann. Insofern war für mich die Richtung klar. Das man dann auf dem "cileint" nur den Initator braucht war für mich auch klar! ;-)
iSCSI HBAs machen in jedem Fall Sinn,
Aus meiner Sicht auch. Es ist nur oft eine Frage des Geldes.Ich habe keine Vorstellungen, was diese Karten aktuell kosten. Ich weiss nur, dass vor ca. 1 1/2 Jahren die Preise noch mit FC HBA's vergleichbar oder zumindest ähnlich waren, so das FC durchaus eine Alterntive (preislich betrachtet) war. Ich denke ähliches gilt auch heute noch.
Insofern finde ich den Vergleich nicht unfair. Wenn FC ggf. nur ein paar prozent teurer ist lohnt der Umstieg.
Wobei ein Opteron mit open-iSCSI eine normale GigEth-Karte zum Anschlag bringt. Daher kann es durchaus Sinn machen über mehrere Pfade zum Target zu gehen
Klar, es war auch nur eine "Faustformel" da viele unterschätzen, wie viel CPU Last das I/O einer Gigabitkarte verkraften kann. Ich glaube auch nicht, dass eine Ultra Sparc VI+ CPU mit etwas über 1 Ghz stress bekommt eine Netzwerkkarte zu bedienen.
Multipathing kann der NetApp grundsätzlich. In FC auf jeden Fall, wie es bei iSCSI umgesetzt wird bin ich mir selber nicht sicher. Da dieses Feature hauptsächlich bei hocherfügbaren und performanten Systemen eine Rolle spielt ist es durchaus legitim das bei iSCSI nicht zu berücksichtigen. Ich zumindest lass keine Primäranwendungen per iSCSI laufen.
Beim 270er wird - wie bereits gesagt - auch die CPU der Engpass sein Datenraten wie 50MB/s oder mehr zu bringen.
....ganz schöner Klug******er! :-P *G*
sorry...
Ich darf das.
Der Hintergrund zu meiner Aussage besteht darin, dass man einen NetApp einfach nicht als Nutzer einer iSCSI Lun konfigurieren kann. Insofern war für mich die Richtung klar. Das man dann auf dem "cileint" nur den Initator braucht war für mich auch klar! ;-)
Aber vielleicht für die anderen nicht. Da der Trend im Storageumfeld eh zur Virtualisierung geht, wird es nicht mehr lange dauern bis auch NetApp auf den Zug aufspringt und es möglich sein wird LUNs anderer Storagesysteme über einen Filer zu präsentieren (Stichwort "Tiered Storage"), so wie es z.B. HDS bei der TagmaStor macht. Dann wird auch der Filer einen Initiator brauchen. *g*
Aus meiner Sicht auch. Es ist nur oft eine Frage des Geldes.Ich habe keine Vorstellungen, was diese Karten aktuell kosten. Ich weiss nur, dass vor ca. 1 1/2 Jahren die Preise noch mit FC HBA's vergleichbar oder zumindest ähnlich waren, so das FC durchaus eine Alterntive (preislich betrachtet) war. Ich denke ähliches gilt auch heute noch.
Insofern finde ich den Vergleich nicht unfair. Wenn FC ggf. nur ein paar prozent teurer ist lohnt der Umstieg.
FC nur ein paar Prozent teurer? Hui... informier dich mal über die Preise. iSCSI ist Lowend. FC-Infrastruktur kostet immer noch richtig Geld, ganz zu schweigen von passenden Storagesystemen (nein, ich rede jetzt nicht von den SCSI-2-FC Systemen mancher günstiger Hersteller). Selbst eine MSA1500cs kostst mit einem Controller round about 8000 €. Wenn wir mal in den Bereich EVA oder XP von HP (oder Symmetrix bei EMC², TagmaStor oder Thunder / Lightning bei HDS) gehen, wird es ganz schnell richtig teuer. iSCSI ist kostengünstiger, aber bei weitem nicht so performant. Zudem muss ich für iSCSI, je nach Anwendungsfall auch eine eigene Infrastruktur aufbauen (eigene Switches, VLANs usw.).
Klar, es war auch nur eine "Faustformel" da viele unterschätzen, wie viel CPU Last das I/O einer Gigabitkarte verkraften kann. Ich glaube auch nicht, dass eine Ultra Sparc VI+ CPU mit etwas über 1 Ghz stress bekommt eine Netzwerkkarte zu bedienen.
ACK.
Multipathing kann der NetApp grundsätzlich. In FC auf jeden Fall, wie es bei iSCSI umgesetzt wird bin ich mir selber nicht sicher. Da dieses Feature hauptsächlich bei hocherfügbaren und performanten Systemen eine Rolle spielt ist es durchaus legitim das bei iSCSI nicht zu berücksichtigen. Ich zumindest lass keine Primäranwendungen per iSCSI laufen.
Was sind in deinen Augen "Primäranwendungen"? Wenn du jetzt von Datenbanken sprichst: Kommt auf die geforderte Performance an. Geforderte Performance, Verfügbarkeit, Preis / Leistung - nach diesen Kriterien werden Storages und Infrastruktur ausgewählt. Und wenn wir von einer kleinen ERP Anwendung für 50 User reden, dann kann man dann schon mal zu einem iSCSI Storage greifen.
Beim 270er wird - wie bereits gesagt - auch die CPU der Engpass sein Datenraten wie 50MB/s oder mehr zu bringen.
ACK.
Hi,
Ich darf das.
Ich auch?
*fg*
Da der Trend im Storageumfeld eh zur Virtualisierung geht, wird es nicht mehr lange dauern bis auch NetApp auf den Zug aufspringt und es möglich sein wird LUNs anderer Storagesysteme über einen Filer zu präsentieren [...] Dann wird auch der Filer einen Initiator brauchen.
NetApp hat bereits die Schienen verlegt, als HDS gerade die Eisenverarbeitung entdeckte! ;-)
Das Anbinden von exterenem Storage ist unkritisch bei NetApp. Da Funktioniert der NetApp natürlich auch als Initiator. Allerdings geht das nur über FC, deshalb schrieb ich auch:
dass man einen NetApp einfach nicht als Nutzer einer iSCSI Lun konfigurieren kann.
Also bitte genauer lesen!
FC nur ein paar Prozent teurer? Hui... informier dich mal über die Preise. iSCSI ist Lowend. FC-Infrastruktur kostet immer noch richtig Geld
Moment, es war nie die Rede von High-End.
Bezüglich der Preise habe ich mich eben Informiert und wurde bestätigt. iSCSI und FC HAB's sind jeweils für unter 1000€ zu bekommen und können somit auch im Low-End eingesetzt werden könne.
Beispiele:
http://www.electronicscout24.de/catalog/article.do?id=278050729120307250&sid=NDk2RTgwNzY4NzYxQUI2NUM0NUU5QjI4NEZDNzU3NDcwMT E1NDQzMTU1MzQwOTAwMDAwMDAwMDAwMDAwMDAwMDAwMDAwMDAw MA
http://www.hardwarehouse.de/catalog/product_info.php?products_id=1281857
Es macht wirklich Sinn zu vergleichen und warum sollte man zum gleichen Preis iSCSI nehmen?
Weiterhin hatte ich bisher (für diesen Fall) nur direct Attached im Kopf. Ich glaube nicht, dass es hier um ein komplexes Storage Subsystem geht. Insofern sind natürlich SAN Switche hohe Kostenfaktoren, aber in der Thematik nicht relevant...
...unterstelle ich jetzt mal.
Selbst eine MSA1500cs kostst mit einem Controller round about 8000 €.
In dem Level kenne ich micht nicht so aus...
(oder Symmetrix bei EMC², TagmaStor oder Thunder / Lightning bei HDS) gehen
da kenn ich mich schon eher aus, die 99er Serie von HDS ist eben mein täglich Brot. Und sicher hast du recht, dass es hier richtig teuer wird. Eine Festpaltte einer TagmStore kostet etwa soviel wie das von dir genannte MSA1500cs.
Aber wir bewegen uns im kleinen Bereich: es geht in dem Thema darum 2 Server an einen NetApp anzuschließen und ich bin noch immer der Meinung, dass FC eine Alternative ist, sofern beim NetApp die FC Lizens da ist.
Sonst sprengt die den Rahmen!
Was sind in deinen Augen "Primäranwendungen"?
Das, mit dem das Unternehmen in erster Linie seine Brötchen verdient.
Betreibt man eine 50-user-Anwendung braucht man sicher kein FC-SAN, die Frage ist, ob man überhapt ein Speichersubsystem braucht....
Hi,
Ich auch?
*fg*
Lass mich kurz nachdenken...ähh... nein.
NetApp hat bereits die Schienen verlegt, als HDS gerade die Eisenverarbeitung entdeckte! ;-)
Das Anbinden von exterenem Storage ist unkritisch bei NetApp. Da Funktioniert der NetApp natürlich auch als Initiator. Allerdings geht das nur über FC, deshalb schrieb ich auch:
Also bitte genauer lesen!
Darauf war das doch bezogen. Das wird kommen. Wobei das der Filer FC-LUNs binden kann, war mir klar. Aber AFAIK nicht im gleichen Sinne wie eine TagmaStor. Das ist ja das lustige am Filer. Der ist ja (mal einfach formuliert) ein SAN/NAS Mischsystem.
Bezüglich der Preise habe ich mich eben Informiert und wurde bestätigt. iSCSI und FC HAB's sind jeweils für unter 1000€ zu bekommen und können somit auch im Low-End eingesetzt werden könne.
Es macht wirklich Sinn zu vergleichen und warum sollte man zum gleichen Preis iSCSI nehmen?
Weiterhin hatte ich bisher (für diesen Fall) nur direct Attached im Kopf.
Point-2-Point ist nicht bei allen FC-Storages erlaubt. Der Kostenpunkt ist i.d.R. das Storage und die Switches. Weniger die HBAs. Und wie ich schon sagte: Wenn du eine größere iSCSI Umgebung aufbaust, dann wirst du auch dort Switches brauchen, zwar Ethernet, aber das treibt die Kosten auch nach oben.
da kenn ich mich schon eher aus, die 99er Serie von HDS ist eben mein täglich Brot. Und sicher hast du recht, dass es hier richtig teuer wird. Eine Festpaltte einer TagmStore kostet etwa soviel wie das von dir genannte MSA1500cs.
Siehe XPs von HP. ;)
Aber wir bewegen uns im kleinen Bereich: es geht in dem Thema darum 2 Server an einen NetApp anzuschließen und ich bin noch immer der Meinung, dass FC eine Alternative ist, sofern beim NetApp die FC Lizens da ist.
Sonst sprengt die den Rahmen!
Nein, in dem Bereich ist FC kein Thema. Da ist es eher angebracht iSCSI zu nutzen, oder gleich direct-attatched mit SCSI (sofern man nicht plant weitere Server anzubinden).
Das, mit dem das Unternehmen in erster Linie seine Brötchen verdient.
Betreibt man eine 50-user-Anwendung braucht man sicher kein FC-SAN, die Frage ist, ob man überhapt ein Speichersubsystem braucht....
ACK.
Lass mich kurz nachdenken...ähh... nein.
Na, ich hätt' nicht fragen sollen, es kam ja ohnehin eine nicht legitimierte Antwort zurück.
Wie kommst du eigentlich auf diese wirre Aussage? =)
Aber AFAIK nicht im gleichen Sinne wie eine TagmaStor
Doch. Die Teile wurde früher sogar von HDS vertrieben und nannten sich gFiler. Jetzt heißen sie vFiler und sind trotzdem ganz normale NetApps, nur eben mit der Lizenz LUN's vom Fremdstorage zu verarbeiten.
Ob NetApp iSCSI Targets verarbeite wird man sehen. Momentan bin ich mir nicht sicher, ob es aktuell einen Markt dafür gibt. Ich mein, wer stellt sich für meherere 10 oder 100-tausend € NetApps hin und packt dann ein low-budget-iscsi storge dahinter?
Naja, vielleicht siehts in der Zukunft ja anders aus.
Point-2-Point ist nicht bei allen FC-Storages erlaubt.
Ich sprach ja auch von directAtteched. Von mir aus können die da auch FCAL sprechen....
Aber ich habe noch kein Storage gesehen, was per FC zwingend an einen Switch muss.....
Wenn du eine größere iSCSI Umgebung aufbaust, dann wirst du auch dort Switches brauchen, zwar Ethernet, aber das treibt die Kosten auch nach oben.
Völlig klar, wird aber der Threadersteller (der ohnehin umfallen wird, wenn er das hier liest) nachdem was er geschrieben hat nicht nutzen.
Nein, in dem Bereich ist FC kein Thema. Da ist es eher angebracht iSCSI zu nutzen
Aber warum nicht? Ich habe einen netApp mit iSCSI Lziens und/oder FC Lizenz. Ich habe den Tip bekommen über einen HBA nachzudenken. Wenn die iSCSI Version (ähnlich) gleich viel kostet wie die FC Version: warum soll ich kein FC nehmen?
Doch. Die Teile wurde früher sogar von HDS vertrieben und nannten sich gFiler. Jetzt heißen sie vFiler und sind trotzdem ganz normale NetApps, nur eben mit der Lizenz LUN's vom Fremdstorage zu verarbeiten.
Oh, interessante Info. Das war mir neu.
Ob NetApp iSCSI Targets verarbeite wird man sehen. Momentan bin ich mir nicht sicher, ob es aktuell einen Markt dafür gibt. Ich mein, wer stellt sich für meherere 10 oder 100-tausend € NetApps hin und packt dann ein low-budget-iscsi storge dahinter? Naja, vielleicht siehts in der Zukunft ja anders aus.
Na ja, der Trend geht ja schon dahin. Wer stellt irgendwelche SATA-2-FC Kisten hinter seine TagmaStor? Ziel ist es ja den Speicher zu virtualisieren und den TCO zu senken.
Ich sprach ja auch von directAtteched. Von mir aus können die da auch FCAL sprechen....
Aber ich habe noch kein Storage gesehen, was per FC zwingend an einen Switch muss.....
Direct-attached ist für mich Point-2-Point. Ich sprach nicht von Fibre-Channel. *g* Namensgleichheit ist manchmal ein Teufelszeug. ;) Bezüglich des Storage: Klar, da fällt mir sofort die HP VA ein. Mi einem simplen Firmware Update (nicht mal ein Major Releasewechsel) war Point-2-Point nicht mehr supportet.
Aber warum nicht? Ich habe einen netApp mit iSCSI Lziens und/oder FC Lizenz. Ich habe den Tip bekommen über einen HBA nachzudenken. Wenn die iSCSI Version (ähnlich) gleich viel kostet wie die FC Version: warum soll ich kein FC nehmen?
Setzt aber einen Filer mit FC-Lizenz voraus. Um weiteren Missverständnissen vorzubeugen: Ich setze lieber auf FC als auf iSCSI! Ich denke wir sind im gleichen Markt aktiv (/me SAN, NAS und Backup, vornehmlich HP StorageWorks MA, EVA, MSA, XP, MSL Tape-Libs, ESL Tape-Libs usw). iSCSI kommt bei mir nur bei sehr kleinen Installationen zum Einsatz. Etwas weiter unten müsstest du noch einen Thread von mir von gestern finden. Habe da mal mit den iSCSI Enterprise Target und open-iSCSI unter VMware rumgespielt. Schau mal rein.
hey, meine erste und "wichtigste" frage haste ja gar nicht beantwortet! :-)
Wer stellt irgendwelche SATA-2-FC Kisten hinter seine TagmaStor? Ziel ist es ja den Speicher zu virtualisieren und den TCO zu senken.
Ja, bei der TagmaStore gilt vielleicht auch noch das Argument der Performance, in dem man auf deren Technik und Cache zurückgreift um vorhandenen SATA-FC Storage zu beschleunigen. Wobei ich sagen muss, bei kleinen Installationen ist SATA gar nicht mal soo langsam. Ich cache unser Backup auf SATA (und mehr auch nicht). Es greift also nur ein Server drauf zu, das dann aber mit über 100MB/s.
Aber auch bei der TagmaStore glaube ich nicht, dass in absehbarer Zeit iSCSI Targets unterstützt werden.
Naja, mal schauen was der Nachfolger bringt.
Klar, da fällt mir sofort die HP VA ein. Mi einem simplen Firmware Update (nicht mal ein Major Releasewechsel) war Point-2-Point nicht mehr supportet
krass, jetzt weiss ich auch, warum ich kein HP Storage habe! =)
Setzt aber einen Filer mit FC-Lizenz voraus.
Ja, das andere setzt eben eine iSCSI Lizens voraus.
Ich setze lieber auf FC als auf iSCSI!
dito - iSCSI setze ich bisher noch nichtmal produtkiv ein.
In erster Line aber darin begründet, dass ich kein Gerät mit Hardware iSCSI Initiator habe und die Netzer mich von der Seite anspringen würden....
Ich denke wir sind im gleichen Markt aktiv
Ja, SAN, NAS, ohne Backup, mit HDS 99er Storage-Serie, SUN Storage und NetApps
Habe da mal mit den iSCSI Enterprise Target und open-iSCSI unter VMware rumgespielt. Schau mal rein.
mit IET spiele ich seit gestern auf einem SUSE Rechner rum..
...es wird langsam Mainstreamtauglich.
Ja, bei der TagmaStore gilt vielleicht auch noch das Argument der Performance, in dem man auf deren Technik und Cache zurückgreift um vorhandenen SATA-FC Storage zu beschleunigen. Wobei ich sagen muss, bei kleinen Installationen ist SATA gar nicht mal soo langsam. Ich cache unser Backup auf SATA (und mehr auch nicht). Es greift also nur ein Server drauf zu, das dann aber mit über 100MB/s.
SATA ist für mich Nearline Storage, was werder von der Performance, noch von der Verfügbarkeit an SCSI rankommt (FC Platten haben die gleiche Technik, nur anderes Interface). SATA nehme ich eigentlich gerne für Snapshots, Disk-2-Disk-2-Tape Backups usw. Halt Daten zweiter Wahl und nichts was performancekritisch ist.
krass, jetzt weiss ich auch, warum ich kein HP Storage habe! =)
Die VA war eines der ersten reinen FC Systeme, sehr performant, skalierbar und gut administrierbar. Ein System welches ich heute immer noch gerne beim Kunden sehe, aber mittlerweile EOL ist. EVAs, MSAs und XPs haben damit keine Probleme, wobei die auch von Compaq kommen. :rolleyes:
Hi blazilla, hi borner,
vielen Dank für Eure überaus detailreichen Antworten. Dazu brauche ich jetzt erstmal einen Tag um die zu lesen. :-)
Wir verwenden auf alle Fälle HBA´s und zwar von Qlogic. Diese werden dann an das SAN-Netzwerk angeschlossen und gut ist es. Wie blazilla erwähnte spare ich mir dann die Konfiguration mit open-iscsi und booten per LUN in der initrd.
Zur Servervirtualisierung kann ich folgendes sagen:
Netapp ist schon auf diesen Zug aufgesprungen. Nach einem Gespräch mit einem Techniker wird demnächst das OS "ONTAP GX" herauskommen, mit dem ich den Speicher von mehreren Filer auf einen Hostnamen z. B. darstellen kann.
Ob es jetzt Sinn macht, bzw. in der Performance OK ist, wenn man versucht einen ESX "Light" :-) zu bauen, ist die andere Frage.
Das ganze sieht folgendermaßen aus:
Suse Linux 10.0 bzw. 10.1, 8 GB RAM, IBM 346er Server mit Dual Xeon 3,06 und HBA 1.0G von QLogic. Dazu den neuen Vmware-Server 1.0.0. Die Virtual Hosts sollen dann direkt von der Netapp aus gestartet werden.
Vorteil:
Die größe der physischen Festplatten im Server spielen keine Rolle mehr.
Die Sicherung ist faktisch hinfällig, da ja die Hosts eh auf der Storage liegen. Wenn eine Sicherung erfolgen soll, kann diese bequem über unsere zukünftige Tape Storage per FC-Anbindung an die Netapp superschnell ablaufen.
Tja, das wäre die Wunsch-Konfig. Mal sehen obs klappt.
Gruss
Mull
Ob es jetzt Sinn macht, bzw. in der Performance OK ist, wenn man versucht einen ESX "Light" :-) zu bauen, ist die andere Frage.
ESX Light? Das hört sich schon nicht gut an...
Das ganze sieht folgendermaßen aus:
Suse Linux 10.0 bzw. 10.1, 8 GB RAM, IBM 346er Server mit Dual Xeon 3,06 und HBA 1.0G von QLogic. Dazu den neuen Vmware-Server 1.0.0.
Tu dir selber einen Gefallen und nimm einen SLES10. Da ist Support bei. ;) VMware-Server 1.0.... aber bitte auch Support bei VMware einkaufen.
Die Virtual Hosts sollen dann direkt von der Netapp aus gestartet werden.
Vorteil:
Die größe der physischen Festplatten im Server spielen keine Rolle mehr.
Die Sicherung ist faktisch hinfällig, da ja die Hosts eh auf der Storage liegen. Wenn eine Sicherung erfolgen soll, kann diese bequem über unsere zukünftige Tape Storage per FC-Anbindung an die Netapp superschnell ablaufen.
Na ja, so abwägig ist das nicht. Ich habe diverse ESX Maschinen bei Kunden stehen, die lokale einen Spiegelsatz haben, auf dem der ESX installiert ist. Über zwei oder vier HBAs werden dann LUNs von einem Storagesystem gezogen (über vier Fabrics). Diese LUNs dienen dann als Platz für das VMFS des ESX. Im Prinzip läuft es bei euch dann auch so.
Was das Backup angeht: Gut, der Filer kann Snapshots machen, aber bitte beschäftigt euch mal eindringlich mit dem Backup vom VMs. Bei VMware gibt es da einige nette Dokumente zu. Sicherlich: Der VMware Server bietet nicht die gleichen Funktionen im Bereich Backup wie der ESX 3, aber es gibt da mehrere Möglichkeiten. Bezüglich Tape und FC-Anbindung. Kein Thema, ist heute recht häufig, aber die entscheidende Frage ist: LAN-free oder Server-free Backup? LAN-free sollte kein großes Problem sein, Server-free dagegen schon. Das klappt nicht mit allen Kombinationen.
ESX Light? Das hört sich schon nicht gut an...
Da hast Du recht. Auf jeden Fall ist es eine Idee und wie weit die ausgebaut wird, werden wir sehen.
Tu dir selber einen Gefallen und nimm einen SLES10. Da ist Support bei. ;) VMware-Server 1.0.... aber bitte auch Support bei VMware einkaufen.
Die ca. 600,-- Euro für den SLES10 krieg ich nicht durch. Da wir 4 Stück dieser Server haben, kommen wir dann wieder auf fast 2.500,-- Euro. Das ist einfach zu viel. Das wäre ja schon der Einstiegs-ESX. Warum Support für VMware-Server 1.0.0??? Dieses Produkt ist jetzt nicht so anstrengend, das ich dort die Supportunterstützung bräuchte. Außerdem haben wir auch einen GSX mit Goldsupport. Diese wurde auch öfters kontaktiert, nur kam da auch nix gescheites rüber.
Na ja, so abwägig ist das nicht. Ich habe diverse ESX Maschinen bei Kunden stehen, die lokale einen Spiegelsatz haben, auf dem der ESX installiert ist. Über zwei oder vier HBAs werden dann LUNs von einem Storagesystem gezogen (über vier Fabrics). Diese LUNs dienen dann als Platz für das VMFS des ESX. Im Prinzip läuft es bei euch dann auch so.
Was das Backup angeht: Gut, der Filer kann Snapshots machen, aber bitte beschäftigt euch mal eindringlich mit dem Backup vom VMs. Bei VMware gibt es da einige nette Dokumente zu. Sicherlich: Der VMware Server bietet nicht die gleichen Funktionen im Bereich Backup wie der ESX 3, aber es gibt da mehrere Möglichkeiten. Bezüglich Tape und FC-Anbindung. Kein Thema, ist heute recht häufig, aber die entscheidende Frage ist: LAN-free oder Server-free Backup? LAN-free sollte kein großes Problem sein, Server-free dagegen schon. Das klappt nicht mit allen Kombinationen.
Auch hier muss ich mal einhacken. Bei den Low-Server Varianten von Vmware bleibt mir ja nicht viele Möglichkeiten der Sicherung. Bei mir wird das .vmdk gesichert und das reicht mir. Eine neue virtuelle Maschine darum gebaut und fertig ist es.
Na ja, bei dem was ihr da an Hardware stehen habt sind 2500 € nicht wirklich viel. Wieviele VMs sollten denn betrieben werden? Ich mache mehr ernsthafte Gedanken über die Performance des Storage. Was den VMware Support angeht: Ich kann nur Gutes berichten, immer perfekte Hilfe, sowohl beim GSX, als auch beim ESX. Es geht ja nicht um die Administration, sondern was passiert wenn ihr mal ein Problem habt, was sich nicht auf Anhieb lösen lässt, und da ein ganzer Maschinenpark aus VMs steht?
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.