Data Backup and Recovery

Exchange 2010 Volume & Lun Best Practices

cit_fas2050
4,341 Views

Dear all,

I've read a lot of netapp doc but I'm still confused about volume & lun best practices.

Should I put all lun DB in a single volume and all lun LOG in an another one, or should I put each lun in a different volume ?

Let's take a simple exchange environment ==> 1 Exchange 2010 server with 3 Mailbox database without DAG.

123

aggr1

     vol1

          lun1 -> Mailbox DB1

     vol2

          lun1 -> Mailbox DB2

     vol3

          lun1 -> Mailbox DB3

aggr2

     vol1

          lun1 -> Mailbox LOG1 + SnapInfo

     vol2

          lun1 -> Mailbox LOG2 + SnapInfo

     vol3

          lun1 -> Mailbox LOG3 + Snapinfo

aggr1

     vol1

          lun1 -> Mailbox DB1

          lun2 -> Mailbox DB2

          lun3 -> Mailbox DB3

aggr2

     vol1

          lun1 -> Mailbox LOG1 + SnapInfo

          lun2 -> Mailbox LOG2 + Snapinfo

          lun3 -> Mailbox LOG3 + Snapinfo

aggr1

     vol1

          lun1 -> Mailbox DB1

     vol2

          lun1 -> Mailbox DB2

     vol3

          lun1 -> Mailbox DB3

aggr2

     vol1

          lun1 -> Mailbox LOG1 + SnapInfo

          lun2 -> Mailbox LOG2 + Snapinfo

          lun3 -> Mailbox LOG3 + Snapinfo


Is there performance issue if we use solution 2 instead of the 1 ?

Regards,

1 ACCEPTED SOLUTION

jausch
4,341 Views

First, you need to keep in mind that the aggregate is the performance boundary, not the Volume.  In your picture above, all DB's are always in Aggr1, so there will be no performance difference.  In general, NetApp best practice is to make your Aggregates as large as possible as this will allow WAFL more spindles to manage and give you the optimal performance across all your LUNs.

The main reason to separate your DB's onto separate Volumes is to separate your snapshots.  Snapshots are taken at the Volume level, not the LUN level.  If, for some reason DB1 was on a different backup or retention schedule from DB2, it might make sense to separate them onto different volumes.

Alex

View solution in original post

3 REPLIES 3

jausch
4,342 Views

First, you need to keep in mind that the aggregate is the performance boundary, not the Volume.  In your picture above, all DB's are always in Aggr1, so there will be no performance difference.  In general, NetApp best practice is to make your Aggregates as large as possible as this will allow WAFL more spindles to manage and give you the optimal performance across all your LUNs.

The main reason to separate your DB's onto separate Volumes is to separate your snapshots.  Snapshots are taken at the Volume level, not the LUN level.  If, for some reason DB1 was on a different backup or retention schedule from DB2, it might make sense to separate them onto different volumes.

Alex

cit_fas2050
4,341 Views

Thank you for the clarification.

christoph
4,341 Views

hi,

we'd quite a lot databases in a configuration of a customer hitting the same question. We did the test with around 20 Databases on one node and two different volume layouts.

first layout was 20 LUNs with 20 Volumes

second layout was 20 LUNs with 1 big Volume

The basic disk performance was absolutly the same as stated before as the disk performance depends on the aggregate not the volume layout.

the backup performance was a bit different as the process of doing 20 snapshots in a row takes much more time than taking just one snapshot. Even if SME is not aware of this configuration and verification always flexclones for each DB (deletes if verify for the first db is ready and recreates flexclone again for the second db.. which is also quite a bit overhead and time consuming)

Backupjob as a whole completed (without verification as it depends on the db sizes) with first layout after around 15 Minutes, second layout took around 9-10 minutes. not that much and especially if you do verification the 5 minutes more or less will not count in the whole process. (tested configuration with SME 6.0 no P release or 6.0.2 as the  config was a bit older and never updated, SDR 6.3 was in use, also no P release)

BG Christoph

Public