Data Backup and Recovery

SDW 6.2P1 & Windows 2008 Clusters - Extremely slow response in SDW

mheimberg
2,615 Views

Hi

Though there are some threads existing to this topic (

SDW 6.2 & Windows 2008 R2 Clusters - Extremely slow response in SDW http://communities.netapp.com/message/31254#31254

Windows 2008 R2, SnapDrive and iSCSI http://communities.netapp.com/message/28906#28906 )

I take the liberty of opening another one, because this is a slightly different environment:

NetApp FAS3140 Fabric MetroCluster Ontap 7.3.1.1P2

Windows 2008 SP2

Exchange 2007 CCR SP3 (thus replication is not done by the MetroCluster, but by Exchange)

LUNs connected by FC, mounted as drive letters (9 pcs)

SnapDrive 6.2P1

NetApp DSM 3.3.1

HostUtils 5.3

Strangewise on one Windows node SnapDrive reacts quite fast (enumerationg of LUNs approx. 1min, Space Reclaimer starts after 2-3min)

but on the other Windows node LUN enumaration takes up to 10min, starting Space Reclaimer checks 30min wether reclaim is needed or not etc...everything is extremely slow.

Cluster Configuration check for the MetroCluster shows no errors in DFM.

The Windows admin insists that both Windows nodes are configured exactly the same way.

Any idea how to troubleshoot?

Regards

Markus

3 REPLIES 3

thomas_glodde
2,615 Views

Did you check proper name resolution from all involved machines?

mheimberg
2,615 Views

Yes, we did, though the setup is suboptimal:

DNS resolves the hostname nas-fas1 to IP 10.x.y.z, but the Exchange Servers don't have access to this net.

The management through E0M is IP 129.x.y.z, so there is a hosts file on the Exchange, resolving

fas1 129.x.y.z

nas-fas1 129.x.y.z

and thus overriding DNS....

But ping from Exchange to storage is <1ms (2 hops, tracert) and ping from storage to Exchange also succeeds.

Transport protocol settings are HTTPS to nas-fas1.

thx

Markus

thomas_glodde
2,615 Views

If possible, give HTTP only a try, back in the days, certain setups made HTTPS extremly slow compared to RPC & HTTP.

Public