-=kussi=- 10 Geschrieben 21. März 2009 Melden Teilen Geschrieben 21. März 2009 Hallo, diese Diskussion wurde hier schon mal geführt: https://www.mcseboard.de/windows-forum-allgemein-28/san-iscsi-fc-128671.html Aber leider ohne Ergebnisse. Darum möchte ich das Thema noch mal aufgreifen. Wir haben geplant: Storage: NetApp-Cluster mit FAS2050 und iSCSI Switch: HP Procurve 2900-Series Server: 5x HP DL360 oder 5x BL460c mit QC CPU und 8GB RAM Host: Citrix XenServer 5 Gäste: XenApp, Exchange, MS SQL, DC, PrintServer Die Frage ist machen wir FC oder iSCSI? Für iSCSI spricht die einfache und günstige Infrastrukur, aber reicht die Performace? Was muss man betrachten: 1. die Latenz (bzw. Geschwindigkeit) auf der Leitung 2. die benötigte Bandbreite 3. die I/O pro Sekunde die die Systeme benötigen iSCSI unterscheiden sich maßgeblich in der Bandbreite nicht in der Geschwindigkeit. Es gilt also herauszufinden, welche Bandbreite die Systeme benötigen und wie viele I/O`s (oder IOPS) das Storage-System verarbeiten kann. Wie komme ich also am besten an die Daten? Habt ihr eine Idee? Entscheident sind hier wohl der Exchange, der MS SQL und die XenApp-Server? Achso, wir haben ca. 250 User! ;) – Es gibt dazu einen tollen Calc: You Had Me At EHLO... : Exchange 2007 Mailbox Server Role Storage Requirements Calculator Für unseren Exchange hat der ca. 220 IOPS rausgeworfen. Wenn man nun davon ausgeht, dass eine SAS-HDD ca. 250 IOPS verarbeiten kann, dann bin ich mit der NetApp FAS2050 und ca. 10 aktiven HDDs pro Aggregat auf der sicheren Seite (entspricht also ca. 2500 IOPS). Aber mit welche Bandbreite muss ich rechnen? Wie viele IOPS und Bandbreite brauchen XenApp und MS SQL durchschnittlich? Hülfe!!! :cry: Zitieren Link zu diesem Kommentar
TheDonMiguel 11 Geschrieben 21. März 2009 Melden Teilen Geschrieben 21. März 2009 Hi Ich habe einige iSCSI Installationen in Zusammenhang mit Virtualization gesehen welche sehr gut laufen! Einfach gut klären was der Hersteller (Citrix, Microsoft, VMware) supported und welche Best Practices vorgeschlagen werden. XenServer bietet zum Beispiel eine gute iSCSI Integration mit NetApp... Bei iSCSI ist aus meiner Sicht wichtig dass a) ein dedizierter iSCSI HBA (Zertifizierte HW) und b) ein eigenes VLAN oder eigene Switches dafür eingesetzt werden. Das Design sollte also gleich aussehen wie bei FC um eine stabile Infrastruktur zu erhalten! Cheers Miguel Zitieren Link zu diesem Kommentar
gelöscht 0 Geschrieben 21. März 2009 Melden Teilen Geschrieben 21. März 2009 Hallo, mit einer kleinen FAS2050 schaffst Du es nich annähernd die Möglichkeiten von iSCSI auszureizen. Ich frage mich seit Jahren wo das Märchen herkommt iSCSI "ist für uns zu langsam, wir brauchen FC". Schau mal hier: da findest Du Storage Lösungen für 90.000 Exchange User die iSCSI verwenden: Microsoft Exchange Solution Reviewed Program (ESRP) ? Storage v2.1 ASR Zitieren Link zu diesem Kommentar
Lian 2.421 Geschrieben 21. März 2009 Melden Teilen Geschrieben 21. März 2009 FibreChannel Lösungen sind von Haus aus dedizierte Lösungen für den Storage Bereich, d.h. innerhalb einer Fabric werden rein Storage Anfragen verarbeitet: Es werden FC Switche eingesetzt, FC HBAs und Verbindungen, die nichts anderes tun als die Verarbeitung von Storage I/O. Highend Lösungen sind immer noch zu einem sehr hohen Prozentsatz FC Lösungen. Im iSCSI Bereich kann man ebenso professionell und mit hohem Anspruch arbeiten, in der Praxis sind aber auch sehr viele Low Cost Lösungen im Einsatz. Verwendet werden i.d.R. normale NICs ohne TOE, schon gar keine iSCSI HBAs. Auf den Netzwerkswitchen läuft iSCSI neben normalem Netzwerkverkehr, oft nicht mal in eigenen VLANs. Das möchte ich bei einem Vergleich zu bedenken geben. Zitieren Link zu diesem Kommentar
zahni 550 Geschrieben 21. März 2009 Melden Teilen Geschrieben 21. März 2009 Die Frag ist wirklichg, ob man einen Kostenvorteil hat, wenn man ISCSI richtig aufbaut, also mit dedizierten Switches inkl. Multipathing und richtigen ISCSI-HBA's. Ich war bei der Installation unserer FC-Umgebung bei, und war überrascht, wie einfach das war. Und es funktioniert tadellos. -Zahni Zitieren Link zu diesem Kommentar
NilsK 2.927 Geschrieben 22. März 2009 Melden Teilen Geschrieben 22. März 2009 Moin, Storage: NetApp-Cluster mit FAS2050 und iSCSI na, ist doch ideal. Bei NetApp kannst du recht problemlos nachträglich von iSCSI auf FC umsteigen, falls du feststellen solltest, dass iSCSI zu wenig performant sei. Die Frage ist machen wir FC oder iSCSI? Die Entscheidung werden wir dir nicht abnehmen können. Die Argumente scheinen dir ja schon bekannt zu sein. Für iSCSI spricht die einfache und günstige Infrastrukur, aber reicht die Performace? Das wird man nur mit einer Betrachtung der realen Umgebung beantworten können. Faustregeln helfen im Zweifel gar nichts. Wir haben Kunden mit an die 1000 Usern, die mit iSCSI problemlos klarkommen und welche unter 200, die nur mit FC arbeiten können. Aber: Bei dem, was du angibst, würde ich iSCSI positiv in Erwägung ziehen. Wenn die Umgebung richig designt ist (z.B. dedizierte NICs/Teams, dediziertes VLAN usw.), erwarte ich erstmal keine grundsätzlichen Pronleme. Wie viele IOPS und Bandbreite brauchen XenApp und MS SQL durchschnittlich? Darauf erwartest du jetzt aber nicht wirklich eine Antwort, oder? Falls doch: Was ist denn deiner Meinung nach ein "durchschnittlicher" SQL- oder Terminalserver? Hülfe!!! :cry: Was sagt denn euer NetApp-Dienstleister zu dem Thema? Wenn du mit dem nicht darüber reden kannst, sondern ein Forum benötigst, solltest du dich fragen, ob du mit dem richtigen Partner zusammenarbeitest ... Gruß, Nils Zitieren Link zu diesem Kommentar
thorsatten 10 Geschrieben 22. März 2009 Melden Teilen Geschrieben 22. März 2009 Für unseren Exchange hat der ca. 220 IOPS rausgeworfen. Wenn man nun davon ausgeht, dass eine SAS-HDD ca. 250 IOPS verarbeiten kann, dann bin ich mit der NetApp FAS2050 und ca. 10 aktiven HDDs pro Aggregat auf der sicheren Seite (entspricht also ca. 2500 IOPS). Aber mit welche Bandbreite muss ich rechnen? Wie viele IOPS und Bandbreite brauchen XenApp und MS SQL durchschnittlich? Hülfe!!! :cry: Hallo, ich bin nun schon ne ganze Weile im Storagebereich unterwegs, hauptsächlich FC, aber auch iSCSI (kein Netapp, war Equalogic). Deine 250 IOPS für ne SAS-HDD halte ich für einen sehr optimistischen Wert. Wenn man sich so die aktuellen Werte der SAS Disks bei Seagate o.a. ansieht kommt man eher auf 125 (10k) bzw. 175 (15k) IOPS. Diese Werte würd ich aber auch nicht als Fix Werte nehmen, da auch das Schreib/Lese Verhalten, also Random oder Sequentiel IO, hier zu einem besseren oder auch schlechterem Ergebnis führen können. Zu deiner Frage bzgl. XenApp oder MS SQL DB: Du setzt die Sachen ein und dann solltest du auch wissen, wie viele IOPS deine Datenbank braucht! Das kann dir hier keiner sagen, da wir nicht wissen, wieviele User da drauf arbeiten und wieviele Transaktionen die erzeugen. Was sagt den der Anbieter der Netapp dazu? In dem Systemhaus, wo ich aktuell tätig bin, wird sehr viel Netapp gemacht, da ist dann aber auch immer einer unserer Spezialisten mit dem Vertriebler unterwegs, damit der Kunde eine passende Lösung bekommt. Also meine Empfehlung: Sprich mit dem Dienstleister, der die Netapp anbietet, der sollte dir alles beantworten können. Kann er das nicht, dann würd ich mir eine Zusammenarbeit nochmal überlegen, da es ja nicht nur um den Aufbau geht, sondern auch um den Support während des Betriebs später. Gruß, Thorsten Zitieren Link zu diesem Kommentar
-=kussi=- 10 Geschrieben 22. März 2009 Autor Melden Teilen Geschrieben 22. März 2009 Hallo, danke für eure zahlreichen Antworten. Die Dimensionierung für das System steht ja auch schon. Wir werden ein dediziertes SAN aufbauen, mit eigenem Switch und HBAs. Soweit so gut. Mit dem Hersteller und unserem Dienstleister habe ich auch schon gesprochen und die sagen: Alles wird gut ;) Dennoch interessiert mich mal, ob wir zusammen es hinbekommen, das ganze auch mathematisch zu untermauern. Die Aussagen wie: sollte eigentlich klappen sind mir zu waage. Deine 250 IOPS für ne SAS-HDD halte ich für einen sehr optimistischen Wert.Wenn man sich so die aktuellen Werte der SAS Disks bei Seagate o.a. ansieht kommt man eher auf 125 (10k) bzw. 175 (15k) IOPS. Diese Werte würd ich aber auch nicht als Fix Werte nehmen, da auch das Schreib/Lese Verhalten, also Random oder Sequentiel IO, hier zu einem besseren oder auch schlechterem Ergebnis führen können. Das finde ich ja sehr interessant. Bis jetzt hieß es immer: Mit 250 kannst du locker rechnen. Danke für den Hinweis! Zu deiner Frage bzgl. XenApp oder MS SQL DB:Du setzt die Sachen ein und dann solltest du auch wissen, wie viele IOPS deine Datenbank braucht! Das kann dir hier keiner sagen, da wir nicht wissen, wieviele User da drauf arbeiten und wieviele Transaktionen die erzeugen. Bei XenApp kann ich es tatsächlich selbst messen, da wir die Server im Einsatz haben. Bei MS SQL ist es mir nicht möglich, da es sich um ein System handelt, was im Zuge der Migration von Oracle 9 auf MS SQL 2005 migriert wird. Aber vielleicht helfen mir die Werte vom Oracle Server. Ich erwarte hier nicht das mir jemand (wie ein Oracle) voraussagt, wie die Systeme regieren werden. Ich möchte mit euch nur diskutieren, wie man am besten die benötigten Werte ermitteln kann, um herauszufinden ob iSCSI die richtige Wahl ist. Ich werde morgen mal ein bischen messen und die Werte mal ins Forum stellen. Darauf erwartest du jetzt aber nicht wirklich eine Antwort, oder? Falls doch: Was ist denn deiner Meinung nach ein "durchschnittlicher" SQL- oder Terminalserver? Doch ;) Schließlich muss man ja mit etwas planen. Ein durchschnittlicher TS hat aus meiner Sicht ca. 30 User und gängige Apps, wie Office, IE, SAP, usw. Beim MS SQL gebe ich dir recht, aber vieleicht gibt es da so einen CALC wie bei Exchange? Na ich werd mal ein paar Server von uns anzapfen und mal sehen was die für Werte ausspucken. Wir werden übrigends auf den 5 XenServern: 8x TS, 1x Exchange, 1x MS SQL, 2x DC, 1x Printserver, 1x BlackBerry hosten. Was mir immernoch ein wenig unklar ist, wie ich die Bandbreite für die einzelnen Systeme bestimmen kann ohne diese zu messen. Danke! :) Gruß kussi Zitieren Link zu diesem Kommentar
Empfohlene Beiträge
Schreibe einen Kommentar
Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.