iSCSI und Exchange

Matsushita

Semiprofi
Thread Starter
Mitglied seit
17.07.2005
Beiträge
2.907
Hallo Leute,

hat jemand Erfahrung mit der Auslagerung der Exchange-Datenbanken auf ein iSCSI-Lun, welches auf einem SSD-Raid (5) liegt? Mich würde interessieren, ob das problemlos klappt. Müsste, oder?

Ich suche eine hochverfügbare und performante Lösung, ohne Fibre-Channel einsetzen zu müssen.
 
Wenn Du diese Anzeige nicht sehen willst, registriere Dich und/oder logge Dich ein.
Generell stellt das auslagern auf iscsi kein problem dar...


"Ich suche eine hochverfügbare und performante Lösung, ohne Fibre-Channel einsetzen zu müssen."
mit welcher version willst du denn was machen?
Nur die db auf n iscsi system auszulagern ist ja nun nur sehr eingeschränkt als "hochverfügbar" anzusehen...und u.U. nicht so zielführend für dass was du evtl willst (reine mutmaßung)
 
Zuletzt bearbeitet:
Ich dachte an iSCSI, um einen Failover-Cluster aufzusetzen. Das wäre dann "hochverfügbar". Wenn es eleganter geht - immer hier mit den Ideen! :)

Mein erstes Exchange-Projekt steht vor der Tür und ich will ein performantes und ausfallsicheres System aufbauen, ohne unendlich Geld auszugeben.
 
Zuletzt bearbeitet:
Exchange 2010? Wieviel User?
Generell würde ich eher zu 2 Servern und den neuen DAGs raten. Eines der Hauptargumente von 2010 ist ja dass er deutlich weniger IO braucht und normale SATA Platten reichen. Es gibt da auch von MS n Excel Sheet mit dem man die Hardware Anforderungen berechnen kann.
Ein mögliches Setup könnten 2 Server mit jeweils 6 Platten sein (1x Raid 1 OS, 1x Raid 10 Datenbank), das sollte auf jeden Fall für 200 User reichen (evtl auch deutlich mehr). Ordentlich RAM in die Server 16GB+.
Mit 2 Servern und den DAGs ist halt gleich alles redundant, nicht nur zb der Storage. Und du kannst auch Loadbalancing betreiben indem du zb 2 Datenbanken machst, wobei jeweils 1 pro Server aktiv und die andere standby ist.
MSXFAQ.DE - 2-Server-DAG
 
Hey ara1,

vielen Dank für Deine Meldung! Wo bekomme ich das Excel-Sheet her?! Das klingt ja super :) Den Link werde ich mir gleich mal anschauen.

PS: Es wird wohl nur ein Exchange 2007 werden :S
 
Die 2007er Lizenz ist wohl noch nicht abgeschrieben ;) Danke!
 
Wie haben durchaus eine zufriedenstellende Lösung mit einem HP Server Xeon L5520, 4GB RAM und ~80 Postfächern am Laufen.
Davon werden um die 2GB für den Exchange benötigt.
Man rechnet für den Exchange 2GB + pro Postfach 2-5MB.
Macht bei Dir also insg. 3000MB.. somit könnten auch 8GB reichen.

Beim CCR benötigst Du neben einem 2. Server noch einen Witness. Hier reicht auch eine Workstation.

iSCSI ist kein Thema. Aber wozu SSD?
Bei einem vernünftig konfiguriertem Server wirst Du diese Geschwindigkeit kaum feststellen können außer vielleicht im Benchmark.
SAS würde da locker reichen.

Ansonsten überdenke mal die Möglichkeit der Servervirtualisierung.
Zum Beispiel XenServer.

Optimal wären jedoch zwei SANs und zwei "kleinere" XenServer für das OS (Hier sollte RAID1 reichen).

Man könnte dann zudem mit Snapshots arbeiten.

Grüße,
Daenni
 
Davon werden um die 2GB für den Exchange benötigt.
Man rechnet für den Exchange 2GB + pro Postfach 2-5MB.
ziemlich konservativ bei nem 2007er...gerade wenn man alle funktionen auf dem system vereint würde ich ~4gb ansetzenn + ...ms selbst empfiehlt 8gb
Planen von Speicherkonfigurationen: Exchange 2007-Hilfe

iSCSI ist kein Thema. Aber wozu SSD?
Bei einem vernünftig konfiguriertem Server wirst Du diese Geschwindigkeit kaum feststellen können außer vielleicht im Benchmark.
SAS würde da locker reichen.
würde ich so nicht unterschreiben...gerade bei extrem großen datenmengen oder vielen boxen bringen ssd`s enorm viel für die skalierbarkeit von einem einzelnen exchangesystem (da man pro postfach eigentlich selbst bei heavy usern 2mb ansetzen kann ;) ). Selbst wenn das nicht benötigt wird...kann man mit ssds gerade in überschaubaren umgebungen das plattenkabinett/partitionen deutlich einfacher gestalten (für was noch logs von db trennen ;), die paar prozent kann man sich meist schenken )

ansonsten fehlen für konkrete tipps vorallem auch die anzahl der boxen, wie groß sie sind, wie das mailaufkommen ist, ungefähres investitionsvolumen
2 speichersysteme + virtualisierung würde ich u.a. auch von obigen nicht bekannten faktoren abhängig machen
ccr ist aber generell für 2007 und die bisherigen infos das richtige "buzzword"
 
Zuletzt bearbeitet:
kurze zusammenfassung
cluster continious replication...eine non shared cluster lösung für exchange 2007. Die datenbanken liegen auf lokalen platten (wahlweise natürlich auch auf einem storage system)...die windows cluster funktionen werden nur noch genutzt um zu bestimmen wer der aktive ist.

scc (single copy cluster) entspricht in etwa dem "klassischen" shared cluster den schon 2003 kannte.

Die vorteile sind eigentlich klar...
single point of failure fällt weg (speichersystem/plattensystem)
man kann den passiven knoten sichern wärend der aktive ackern muss und hat für das produktivumfeld keine beeinträchtigung
der "failover" deutlich sanfter vonstatten geht

zudem bietet es ha mit geographischer trennung (und nicht nur brandabschnitte), was vorher nur schwer oder schlicht garnicht machbar war


Je nach anforderungsprofil gibt es noch eine 3. "ha" lösung, lcr (keine ahnung wies grad ausgeschrieben heisst, "ständige lokale kopie" oder so)...dass ist im prinzip eine lösung um lokal auf einer maschine eine kopie der aktiven db vorzuhalten (z.B. einmal auf lokalen platten, einmal auf storage).
Da ist halt die frage inwieweit man dann z.B. wartungszeiten mit diesem einen server handhabt.

Die lösungen sind halt davon abhängig wieviel man investieren will und wie hoch die verfügbarkeit sein muss (und auch wie die zu erwartende last aussieht)..."vollständiges" ha wollen alle, zahlen halt nicht ;)
 
Zuletzt bearbeitet:
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