What I mean is following the best practices when building your cluster servers that you will mount the LUNS from.     We had Microsoft here and we asked them how to manage volumes at the TB level, and they told us to simply not create volumes that large because they will be unmanageable.  The NTFS file system is not made for large volumes as such, thats why there is no solution to the management because that is not what it is made for.  Trying to defrag a TB of data is something that you do not want to attempt.  Our Unix folks always get a laugh because their filesystem has not had the problem with fragmenting for 20 years, and Microsoft still has yet to conquer that area.  I tell them, that some things are just better suited for different jobs, Unix is good for storage and storage management,  Windows is good a the presentation and authentication of that storage.
 
Nate


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Noah Eiger
Sent: Monday, December 12, 2005 3:35 PM
To: [email protected]
Subject: RE: [ActiveDir] [OT] iSCSI SAN Due Diligence

Thanks. Nathaniel, could you elaborate a bit on what you mean by "server build consistency," what constitutes a "large" NTFS volume, and what you see as the management difficulties associated with that large volume?

 

-- nme

 


From: Brian Desmond [mailto:[EMAIL PROTECTED]
Sent: Monday, December 12, 2005 12:03 PM
To: [email protected]
Subject: RE: [ActiveDir] [OT] iSCSI SAN Due Diligence

 

You must have meant Veritas Volume Damager. The software that comes with the HBAs from EMC and Qlogic is both fine in my experience of presenting large lun's to Exchange, SQL, and F & P clusters over FC at least.

 

Thanks,
Brian Desmond

[EMAIL PROTECTED]

 

c - 312.731.3132

 

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bahta Nathaniel V Contractor NASIC/SCNA
Sent: Monday, December 12, 2005 1:50 PM
To: [email protected]
Subject: RE: [ActiveDir] [OT] iSCSI SAN Due Diligence

 

I have never had a problem with seeing LUNs on a SAN using Windows NT, Windows 2000 or Windows 2003 server.  However, making sure you follow the best practices for a fileserver and if you are using MSCS following those best practices as well.  Your server build consistency will dictate the availability of your resources.

I would however hesitate when creating large volumes on Windows platforms, they are hard to manage.  The key solution would be to load Veritas Storage Manager and then mount the SAN LUNs onto the virtual volume, this would allow you to expand the volume as you see fit, but it would not leave you with a giant NTFS file system to manage.

 

Nate

 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Noah Eiger
Sent: Monday, December 12, 2005 1:40 PM
To: [email protected]
Subject: [ActiveDir] [OT] iSCSI SAN Due Diligence

Hello:

 

I realize the posting a message to a listserv probably does not count as DD in the legal sense, but for my own peace of mind...

 

I have made a strong and (apparently) convincing case to management that we should consolidate our storage (file, Exchange, SQL, 90% Windows, <200 users but several TB worth of data) onto an iSCSI SAN. All of my research so far has indicated that once you create a LUN on the SAN, servers do not have a problem "seeing" or using the drives.

 

Do list folks have any experiences or resources that might give me pause in following through with this more expensive solution (vis-à-vis NAS, fiber SAN was never a real option)? BTW: I am aware of the reservations about SATA drives and do not mean to re-hash that discussion.

 

Thanks.

 

-- nme

 

--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/198 - Release Date: 12/12/2005


--
No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/198 - Release Date: 12/12/2005


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.371 / Virus Database: 267.13.13/198 - Release Date: 12/12/2005

Reply via email to