ONTAP Discussions

LUN sizing for a Windows file server

schaeffd901
3,365 Views

Hello all,

   I'm looking for some sizing guidance when is comes to LUN sizing.  We have a Windows Server 2003 that will be our file server

replacing Novell.  The Windows team wants one large volume that has 7TB of disk assigned to it.  What is the best way to carve

out the LUNS for them?

   Thanks!!

Dave

1 ACCEPTED SOLUTION

chriskranz
3,365 Views

I would definitely question the decision not to use CIFS natively, if you get into using NetApp more, then you'll find it much more flexible and efficient. Or perhaps you can simply have a "told you so" moment in 6 months with the Novell team

If you stick on SP2 onto Windows 2003, then you have support for GPT partitions. I have definitely used GPT with Windows 2003!!!

A word of warning, if you configure the partition with multiple 2TB LUNs and later decide to invest in SnapDrive, this may not marry up very well.

If you have no other choice, then it really won't make too much difference with the make-up of the LUNs. I'd almost be tempted with 7x 1TB LUNs just to keep things the same and if you need to add to it, it's just another of the same. But I would recommend against doing this.

View solution in original post

4 REPLIES 4

chriskranz
3,365 Views

I guess the first question would be why do you want to use a Windows File Server when you can serve CIFS directly from a filer?

If they really want 7TB in one go, then give them a 7TB LUN. SnapDrive will format with GPT partitions and you are good to go. I might suggest creating it smaller than this and gradually grow into it however, but just remember a LUN can only be grown 50x it's initial size, but if you start at say 1TB, you shouldn't have too many issues just yet!

The volume sizing would be more tricky as this needs to accomodate the LUN, and reserve space, and also any snapshots of the LUN.

Will you be deduping the data? Will you be mirroring to another box?

schaeffd901
3,365 Views

Thank you for replying Chris!

We did start out using CIFS - The Windows/Novell team wasn't comfortable with using them

and wanted just LUNS presented to them.  So this is where we are at.

At this time there isn't money budgeted to purchase SnapDrive.

There is no plans on using dedup or mirroring.

Since Windows Server 2003 can only handle 2TB LUNS would we be better off presenting them

with 3 X 2TB and 1 X 1TB LUNS or some other layout of LUN sizes?

chriskranz
3,366 Views

I would definitely question the decision not to use CIFS natively, if you get into using NetApp more, then you'll find it much more flexible and efficient. Or perhaps you can simply have a "told you so" moment in 6 months with the Novell team

If you stick on SP2 onto Windows 2003, then you have support for GPT partitions. I have definitely used GPT with Windows 2003!!!

A word of warning, if you configure the partition with multiple 2TB LUNs and later decide to invest in SnapDrive, this may not marry up very well.

If you have no other choice, then it really won't make too much difference with the make-up of the LUNs. I'd almost be tempted with 7x 1TB LUNs just to keep things the same and if you need to add to it, it's just another of the same. But I would recommend against doing this.

amiller_1
3,365 Views

Speaking as someone with lot of Novell background (and rather liking it actually), if you're moving away from Novell file servers I'd really look hard at using CIFS off the filer rather than a Windows filer server -- a NetApp running CIFS is basically a Windows file server but on major steroids as far as power and features (snapshots, replication, easy volume sizing, etc.) and patches (i.e. no Windows patches/reboots/etc.). CIFS on the NetApp is kernel-level code (so very fast) and is licensed from Microsoft so fully functional and also supported.

For comfort levels, I usually have Windows administrators just use the Windows MMC to administer their shares and permissions (NSM now feels a bit more native....but not as native as just using the Windows MMC).

Chris covered the actual question quite well....but I'd agree with him in strongly recommending looking back at using CIFS from the NetApp natively.

Public