DocData

Ich bin jetzt mal böse: Wenn dir das, was NeMiX und NorbertFe dir bisher erklärt hat, immer noch nicht deutlich und ausführlich genug sein sollte, dann solltest du mit dem Gedanken spielen einen Dienstleister zu beauftragen. Im Prinzip ist die Einrichtung eines MX Records kein großes Problem, aber auch nur die halbe Miete. Dein Exchange Server, die Firewall und ein möglicherweise vorhandenes Mailrelay müssen auch passend konfiguriert sein. Ansonsten war's das mit den Mails. Und es sieht für Kunden oder Partner doof aus, wenn sie dir eine E-Mail schicken und als Antwort zurückbekommen, dass der Empfänger unbekannt ist. Vielleicht noch mal in Kurzform: 1. A-Record für die Public IP deiner Firewall setzen 2. Passenden PTR Record für den A-Record setzen 3. Firewall Policies anpassen (eingehender SMTP Verkehr muss zu einem Mailrelay oder Exchange geschickt werden) 4. MX-Record auf den neu erstellten A-Record setzen 5. Sende-Konnektor so konfigurieren, dass er per DNS den richtigen Zielserver auflöst, oder die Mails an ein Mailrelay schickt, welches dann den entsprechenden Zielserver auflöst. Den Empfangs-Konnektor so konfigurieren, dass er nur Mails für deine Domäne annimmt. 6. Der Mailversand an andere Domänen als deine eigene Domäne, darf nur für ausgewählte Hosts, nach Authentifizierung oder für den Exchange erlaubt sein. Das kannst du z.B. über einen Open Relay Test prüfen.

Bei 120 Benutzern? Wie wäre es dem Server mehr Speicherplatz zu spendieren? Für mich klingt das nach einem aufwendigen Workaround. Aber die Folder Redirection ist das Mittel der Wahl, wenn auf servergespeicherte Profile verzichtet werden soll. Aber was glaubt ihr, was ihr damit einspart? Der Großteil der Datenmenge werden mit hoher Wahrscheinlichkeit die Eigenen Dateien ausmache, oder? Habt ihr das mal ermittelt?

... weil 8x 2 TB SATA durchaus ein Flaschenhals sein können. Da ist es dann auch egal welche Switched man nimmt etc. Leider sehe ich in der Praxis, auch bei kleinen Installationen, immer wieder sehr unausgewogene Installationen.

Rein von den Specs her nehmen sich der 2530 und der D-Link nichts. Der HP hat einen 50% größeren Packet Buffer, aber der ist mit 1,5 MB, im Vergleich zu anderen Switches, immer noch sehr klein.

Dann schau dir konkret diese beiden Switches an: 2530-8G Switch (J9777A) 2915-8G-PoE Switch (J9562A)

Cut-Through bzw. Store-and-Forward bezeichnet das Frame-Handling, non-blocking bezieht sich auf die Möglichkeit Ports untereinander zu schalten, ohne dass es auf der Backplane zu Engpässen kommt. Alles was sich heute ernsthaft Switch nennen will hat eine non-blocking Architektur. Switches machen i.d.R. immer Cut-Through (gibt Situationen und Modelle die zwischen CT und S&F wechseln). Statt auf solche, eher typischen, Sachen zu achten, solltest du dein Augenmerk auf Portbuffer und die Latenz legen. Die Backplane-Kapazität ist auch noch interessant. Die Switches die ich hier bisher im Thread gesehen habe, sind (sorry...) was Nettes für zu Hause, aber nicht's für ein iSCSI SAN. Aus meiner Projekterfahrung scheitern die meisten iSCSI Projekte an zwei Dingen: Zu wenig Platten und/ oder schlechtes Netzwerk. Bei Letzterem sind es meist die Switches. Ich habe sehr gute Erfahrungen mit HP 2910, HP 55xx und HP 58xx Switches gemacht. Management ist Pflicht! Unmanaged Switches sind was für zu Hause, aber nichts für Unternehmen und schon gar nichts für iSCSI.

Da du von Storage vMotion sprichst wirst du wohl eine VMware vSphere Umgebung haben. Welche Version setzt du konkret ein? Zum LUN Design: Wird das "eine LUN pro VM" Konzept bitte schnell und gründlich über den Haufen! Die meisten machen das aus zwei Gründen: Performance oder organisatorische Probleme technisch lösen. Letzteres ist bei dir der Fall. Setzte lieber auf sauber konfiguierte Alarme um alte Snapshots zu finden. Wie du konkret die LUNs aufteilst hängt von deinen Anforderungen ab (Performance, RTO/ RPO etc.). Dazu hast du leider nichts geschrieben. Grundsätzlich kann man aber bei der CLARiiON den Hinweis geben, dass man random IO von mehreren LUNs in einem Array mischen kann. Wenn du sequentiellen IO hast (also MB/s haben willst bzw. VMs hast, die dieses IO Pattern haben), dann solltest du nur eine LUN pro Array erstellen. Die Anzahl der notwendigen Datastores bzw. LUNs musst du ermitteln. Alle VMs in ein VMFS macht aufgrund der LUN Queue Thematik keinen Sinn. Hier fehlen aber konkrete Angaben über deine Umgebung um da eine sinnvolle Empfehlung zu geben.