Jump to content

Exchange 2010 iSCSI vs. NFS


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

Geschrieben

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

Der TO hat doch von keinem Problem berichtet sondern nur von einer, für ihn, nicht erklärbaren Konfiguration eines Servers.

Die Konfiguration erklärt sich durch den Einsatz von Netapp Snapdrive/SnapManager Exchange.

 

Das lustige ist: Veeam macht auch StorageSnapshots, also kein Unterschied in der grundsätzlichen Technik...

Geschrieben

Moin,

 

ja, ziemlich genau so verlaufen die Diskussionen üblicherweise. Da ich allerdings gar nichts beweisen muss, müssen wir das auch nicht fortführen. Ich weise nur auf meine Erfahrung mit "sowas" hin - ist ja weder mein "Backup" noch mein System.

 

Gruß, Nils

Geschrieben

Zur ursprünglichen Frage: Solange ISCSI nicht direkt in die VM durchgereicht wird (wie bei TO) dürfte die Art des Datastores unter VMWare egal sein. 

NFS ist bei der Netapp prinzipiell eine gute Idee, da es u.U. auch andere Backup-Varianten ermöglicht. Ein ISCSI würde ich jedenfalls nicht parallel betreiben.

Geschrieben

Moin,

 

Zur ursprünglichen Frage: Solange ISCSI nicht direkt in die VM durchgereicht wird (wie bei TO) dürfte die Art des Datastores unter VMWare egal sein. 

NFS ist bei der Netapp prinzipiell eine gute Idee, da es u.U. auch andere Backup-Varianten ermöglicht.

 

naja, eben nicht. Es ist für Exchange dann ja nun mal nicht supportet. Das habe ich in diesem Thread ja auch gelernt. ;)

 

Gruß, Nils

Geschrieben

Ich hab das so verstanden dass Exchange seine Datenbanken nicht auf NFS , CIFS o.ä. ablegen kann.

Ob aber der Hypervisor seine VMDKs auf NFS, CIFS oder als (p)RDM per ISCSI oder FC anbindet ist Exchanche egal.

 

Die Frage ist also: Welche Anbindung der Daten verlangt die Backuplösung. Die Netapp eigenen verlangen derzeit (Snapmanager) eben die Einbindung als pRDM.

Geschrieben

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.

Steht jedenfalls weiter oben im Thread. ;) Aber Exchange 2010 hat ja sowieso kaum noch jemand. ;)

Geschrieben

https://technet.microsoft.com/en-us/library/ee832792%28v=exchg.150%29.aspx

 

 

All storage used by Exchange for storage of Exchange data must be block-level storage because Exchange 2013 doesn't support the use of NAS volumes, other than in the SMB 3.0 scenario outlined in the topic Exchange 2013 virtualization. Also, in a virtualized environment, NAS storage that's presented to the guest as block-level storage via the hypervisor isn't supported.

Geschrieben

Moin,

 

 

naja, eben nicht. Es ist für Exchange dann ja nun mal nicht supportet. Das habe ich in diesem Thread ja auch gelernt. wink.gif

 

Gruß, Nils

 

Vermutlich explodiert Exchange, wenn man das so macht?  

Mal im Ernst: An welcher Stelle merkt Exchange das und wo könnten potenzielle Probleme auftreten? Zumal  es völlig egal ist, ob ich  Blocklevel auf Blocklevel oder auf  File emuliere. Und die Netapp scheidet dann auch aus. Die speichert alles als Files (auch ISCSI und FC). Die sind dann halt recht groß.

Geschrieben

Moin,

 

Vermutlich explodiert Exchange, wenn man das so macht?  

 

warum dieser Ton?

 

Und: Das ist doch in diesem Thread bereits diskutiert und belegt worden. Wir müssen das ja nicht wiederholen - nachlesen reicht. :D

 

Gruß, Nils

Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...