Exchange 2010 iSCSI vs. NFS

[autowolf 12]

Hallo Leute,

 

bei meinem neuen Arbeitgeber hat die alte IT den Exchangeserver komisch konfiguriert.

Exchange 2010 SP3 UP (aktuelles)

 

VMWare ESX --> Windows 2008 R2 Datacenter --> Exchange 2010

Das C Laufwerk liegt als "normale" vmdk auf meiner Netapp. Die Netapp stellt ihren Platz den ESX Server per NFS zur verfügung.

Innerhalb des Exchangeservers sind per iSCSI 3 Festplatten eingebunden, auf denen die Datenbanken und die Logs liegen. Die iSCSI Quelle ist die selbe Netapp.

 

Ich möchte jetzt auf Veeam umstellen. Die Software kann mir aber die iSCSI Laufwerke innerhalb des Exchangeservers nicht sichern.

 

Somit meine Frage:

 

Ist es eine gute Idee die Datenbanken auf einen vmdk zu legen die wiederreum auf einem NFS Speicher liegt ?

Exchange ist ja hier immer etwas empfindlich. Fragmentierung, Geschwindigkeit etc.

Wie schaut da eure Erfahrung aus ?

(Nabe in den 15 Jahre noch nie NFS gehabt. (iSCSI, FC oder interne Festplatten :D )

 

Meine Idee wäre sonst noch, den ESX Servern per iSCSI ein Laufwerk zur verfügung zu stellen und hier den Exchangeserver draufzupacken.

[testperson 1.539]

Hi,

 

welche VMWare Version wird denn genutzt?

Der Exchange bekommt seine Platten als "In-Guest-ISCSI"? Oder liegen die VMDKs für Log / DB einfach nur auf nem VMFS formatierten ISCSI Target?

 

Gruß

Jan

[NilsK 2.789]

Moin,

 

ESX per NFS ist eine typische NetApp-Konfiguration. Das verkaufen die so gern, weil ihre NFS-Lizenz so teuer ist.

 

Grundsätzlich sollte meiner Erfahrung nach nichts dagegensprechen. Parallel noch iSCSI in den VMs zu machen, ist natürlich nicht so schön - zwei Storageprotokolle parallel ist technisch zwar kein Problem, steigert aber nicht die Performance und verkompliziert das Troubleshooting.

 

Für Exchange sollte technisch nichts dagegensprechen, auf VMDK umzustellen. Wie die im Host angebunden sind, sollte dabei sekundär sein. Im Fall von Exchange ginge das auch bei Clustering, weil eine Exchange-DAG ja kein Shared Storage braucht. Mit so einem Aufbau sollte das dann auch per Veeam sicherbar sein. LUNs, die direkt an eine VM angebunden sind, kann Veeam in der Tat nicht sichern - immer wieder ein Problem z.B. bei SQL-Clustern.

 

Gruß, Nils

bearbeitet 18. November 2016 von NilsK

[autowolf 12]

@ testperson

 

ESX 5.0 :nene: gibt aber nächstes Jahr neue Server :jau: , somit will ich daran jetzt auch nichts ändern.

 

C: ist eine vmdk und liegt auf der netapp (NFS)

D,E,F (Datenbanken und Logs) sind über in-guest-iscsi angebunden.

 

@NilsK

 

Nach dem was ich gelesen habe wird von Microsoft Exchange nicht auf NFS untersützt. :suspect:

 

 

"All storage used by an Exchange guest machine for storage of Exchange data must be block-level storage because Exchange 2010 doesn't support the use of network attached storage (NAS) volumes."

 

Genau die Probleme sind da und ich habe keine Lust es so komplex aufzubauen.

Ich weiß auch warum es so gemacht wurde, da im Exchange noch eine Software läuft von netapp um snapshots der iSCSI (D,E,F) Laufwerke zu machen.

Ist aber alles für den Ar...

Hatte das Problem das eine DB defekt war und sie nicht mehr online ging. OK dachte ich kein Problem, DB wegkopiert und das Laufwerk den Snap vor einer Stunde wieder online gestellt.

Diese DB war auch nicht ok.

Ich glaube irgentwie nicht, das die Snaps auch richtig erstellt werden und der Exchange mir da einen konsistenten Datenbestand für die Snaps zur verfügung stellt.

bearbeitet 18. November 2016 von autowolf

[magheinz 100]

was nutzt ihr als Backuplösung?

[testperson 1.539]

Hi,

 

VMWare scheint sich da gerne mit MS und insbesondere dem Exchange-Team "anzulegen" ;) Wenn ich mich daran erinner das ein VMWare CTO da mal mit "MS hat keine Ahnung von Exchange" im Bezug zum Exchange Sizing gegen MS geschossen hat und MS schuld dran sei, dass virtuelle Exchange Server das Nummer 1 Performance Problem seien. Die gleiche "Diskussion" hatte VMWare auch bzgl. Exchange auf NFS. AFAIK kümmert sich VMWare genau um die Probleme die MS beim Einsatz von File-Level-Storage für virtuelle Festplatten sieht. Es bleibt allerdings seitens MS unsupported.

 

Zu In Guest ISCSI sagt MS (https://technet.microsoft.com/en-us/library/jj126252(v=exchg.141).aspx):

Configuring iSCSI storage to use an iSCSI initiator inside an Exchange guest virtual machine is supported. However, there will be reduced performance in this configuration if the network stack inside a virtual machine isn't full-featured (for example, not all virtual network stacks support jumbo frames).

 

 

Die Farm sollte zügig upgedatet werden. Im Problemfall steht ihr ziemlich alleine da ;)

 

P.S.: Heißt das auch, dass ein Exchange unter Hyper-V auf einem SMB3 Share nicht supported ist oder nickt MS das irgendwo ab?

[NilsK 2.789]

Moin,

 

Nach dem was ich gelesen habe wird von Microsoft Exchange nicht auf NFS untersützt.

 

ja, trifft aber hier nicht zu. Exchange greift ja mit Blocklevel auf seine Disks zu. Die NFS-Anbindung findet auf Ebene des Hosts statt, nicht auf Ebene des Gastes. Dabei kann es durchaus auch zu Problemen kommen (meist weil das Gesamtdesign nicht stimmt), aber die sind außerhalb von Exchange.

 

 

Ich weiß auch warum es so gemacht wurde, da im Exchange noch eine Software läuft von netapp um snapshots der iSCSI (D,E,F) Laufwerke zu machen.

[...]

Hatte das Problem das eine DB defekt war und sie nicht mehr online ging. OK dachte ich kein Problem, DB wegkopiert und das Laufwerk den Snap vor einer Stunde wieder online gestellt.

Diese DB war auch nicht ok.

 

Man "sichert" Exchange auch nicht per Snapshot. Predige ich schon seit 14 Jahren, wollen die NetApp-Leute aber nie hören.

 

Gruß, Nils

[testperson 1.539]

ja, trifft aber hier nicht zu. Exchange greift ja mit Blocklevel auf seine Disks zu. Die NFS-Anbindung findet auf Ebene des Hosts statt, nicht auf Ebene des Gastes. Dabei kann es durchaus auch zu Problemen kommen (meist weil das Gesamtdesign nicht stimmt), aber die sind außerhalb von Exchange.

 

Im Link von meinem Post vor dir (https://technet.microsoft.com/en-us/library/jj126252(v=exchg.141).aspx):

 

 

The storage used by the Exchange guest machine for storage of Exchange data (for example, mailbox databases or Hub transport queues) can be virtual storage of a fixed size (for example, fixed virtual hard disks (VHDs) in a Hyper-V environment), SCSI pass-through storage, or Internet SCSI (iSCSI) storage. Pass-through storage is storage that's configured at the host level and dedicated to one guest machine. All storage used by an Exchange guest machine for storage of Exchange data (Exchange Binaries, Transaction Logs, Transport or Mailbox or Public Folder Databases) must be block-level storage because Exchange 2010 doesn’t support the use of non-block-level storage protocols, such as, but not limited to NFS or CIFS/SMB. The volumes must be block-level storage protocols from the storage device to the guest machine. It also isn’t supported to present a volume to a hypervisor using a non-block-level storage protocol, even if the hypervisor presents the volume to the guest machine as a block-level storage protocol. The following virtual disk requirements apply for volumes used to store Exchange data:

• Virtual disks that dynamically expand aren't supported by Exchange.

• Virtual disks that use differencing or delta mechanisms (such as Hyper-V's differencing VHDs or snapshots) aren't supported.

[autowolf 12]

was nutzt ihr als Backuplösung?

 

z.Z. BackupExec 2014 :thumb2:

Einmal pro Woche ist was mit der Software, obwohl ich nichts verändert habe.

 

Somit ist die Lösung:

1. Neues iSCSI Volume von der Netapp an die ESX anbinden.
2. Exchangeserver darauf umziehen
3. Netapp Software im Exchange deinstallieren

 

oder ?

bearbeitet 18. November 2016 von autowolf

[NilsK 2.789]

Moin,

 

ah, OK. Na gut, dann gilt das durch den ganzen Stack. Dann ist die Sache ja klar. Meine Aussage oben ist so also nicht richtig.

 

SMB 3.0 wird übrigens ausdrücklich ausgenommen, aber erst ab Exchange 2013:

 

https://technet.microsoft.com/en-us/library/jj619301(v=exchg.150).aspx

https://technet.microsoft.com/en-us/library/jj619301(v=exchg.160).aspx#BKMK_ExchangeStor

 

Trotzdem sollte es natürlich nicht zu Problemen mit NFS kommen - wenn doch, spricht das gegen den konkreten Gesamtaufbau.

 

Gruß, Nils

[testperson 1.539]

Teils OT oder falls ein Bus mit Leuten vorbeikommt die es Interessiert ;) :

 

Irgendwo müsste ich noch ne PowerPoint dazu haben. In irgendeinem der VMWare Trainings hatte ich nen Trainer der nicht nur tief in VMWare steckte sonder auch ziemlich fit in Exchange war. Der hatte uns die PowerPoint dazu gegeben.

 

Auf die schnelle habe ich "nur" (einen Teil?) der Probleme die MS sieht gefunden:

 

• Forced Unit Access (FUA) and Write-Through, including statements such as “All components in a solution must honor the write-to-stable media intent. This includes, but is not limited to, caching components.”
• Write Ordering. This is required to preserve the integrity of transactions going to the database (you clearly don’t want data written in the wrong order).
• Torn I/O Protection. The document says that “a solution must provide sector alignment and sizing in a way that prevents torn I/O including splitting I/Os across various I/O entities in the I/O path.” In other words, storage must ensure that all of the data for a transaction is written and never reports success when partial writes occur.

(http://windowsitpro.com/blog/raging-debate-around-lack-nfs-support-exchange)

 

Im gleichen Blog verliert der Autor übrigens auch ein paar Worte zum anderen Fall: http://windowsitpro.com/blog/vmware-tells-microsoft-they-dont-know-anything-about-exchange-2013-performance

[magheinz 100]

Man "sichert" Exchange auch nicht per Snapshot. Predige ich schon seit 14 Jahren, wollen die NetApp-Leute aber nie hören.

komischerweise machen das mittlerweile alle so.

Wo sollte auch das Problem sein? Selbst Microsoft schreibt ja nichts anderes:

https://blogs.msdn.microsoft.com/webdav_101/2015/06/01/about-exchange-vss-writer-exchange-backup-and-restore/

Darauf setzt Netapp mit seinen Snapmanagern auf.

genau so wie es Veeam, comvault, arkaia und so gut wie alle anderen auch machen.

bearbeitet 18. November 2016 von magheinz

[NilsK 2.789]

Moin,

 

Wo sollte auch das Problem sein?

 

der TO berichtet von Problemen. Und sowas höre ich immer wieder, dabei erstaunlich oft in NetApp-Umgebungen.

Ich glaube auch, dass die Tolles können. Möglicherweise ist es auch der Umgang der Admins damit. Jedenfalls erlebe ich zu oft Probleme mit solchen Sicherungsmethoden, als dass ich ihnen einfach so vertrauen würde. Daher meine Predigt. ;)

 

Gruß, Nils

[magheinz 100]

z.Z. BackupExec 2014 :thumb2:

Einmal pro Woche ist was mit der Software, obwohl ich nichts verändert habe.

 

Somit ist die Lösung:

1. Neues iSCSI Volume von der Netapp an die ESX anbinden.
2. Exchangeserver darauf umziehen
3. Netapp Software im Exchange deinstallieren

 

oder ?

Welche Netapp-software willst du deinstallieren? SD? SME?

Die Netapp SnapManager benötigen pRDMs. Ob deine Backupsoftware das braucht weiss ich nicht. Falls nicht kannst du statt der LUNs auch VMDKs nehmen. Für ganz faule: du kannst die LUNs in vmdks umwandeln, glaube ich.

[testperson 1.539]

Neue VMDKs an die VM, neue DB erstellen und Postfächer verschieben dürfte ohne Downtime funktionieren ;)

Ggfs. wird man dabei auch noch was Whitespace der alten DB los.