- Community Home
- >
- Storage
- >
- HPE Nimble Storage
- >
- Application Integration
- >
- Exchange 2013 NTFS Mount Points on VMware Performa...
-
- Forums
-
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
- HPE Blog, Austria, Germany & Switzerland
- Blog HPE, France
- HPE Blog, Italy
- HPE Blog, Japan
- HPE Blog, Middle East
- HPE Blog, Russia
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
-
Blogs
- Advancing Life & Work
- Advantage EX
- Alliances
- Around the Storage Block
- HPE Blog, Latin America
- HPE Blog, Middle East
- HPE Blog, Saudi Arabia
- HPE Blog, South Africa
- HPE Blog, UK & Ireland
- HPE Ezmeral: Uncut
- OEM Solutions
- Servers & Systems: The Right Compute
- Tech Insights
- The Cloud Experience Everywhere
-
Information
- Community
- Welcome
- Getting Started
- FAQ
- Ranking Overview
- Rules of Participation
- Tips and Tricks
- Resources
- Announcements
- Email us
- Feedback
- Information Libraries
- Integrated Systems
- Networking
- Servers
- Storage
- Other HPE Sites
- Support Center
- Aruba Airheads Community
- Enterprise.nxt
- HPE Dev Community
- Cloud28+ Community
- Marketplace
-
Forums
-
Blogs
-
Information
-
English
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-07-2014 03:27 PM
04-07-2014 03:27 PM
We are in the process of rolling out Exchange 2013 SP1 on Server 2012 R2 in a VMware environment.
The plan is to use NTFS mount points for all the database and log volumes, mainly we don't want to deal with looking at 15+ drive letters and in general is a lot cleaner.
The question really comes down to is would we be better off creating small Nimble iSCSI volumes and using those for the mount point drive letters? (seems like a waste to me).
Or should we use a small VMDK to contain the NTFS mount points? (seems cleaner to me)
The only real gotcha here is that the NTFS mount points will be using the Microsoft Exchange 2013 best practice of 64K allocation units where as the VMDK will of course be using the 1MB block size, both with different Nimble performance policies of course.
I guess the next question should be, do I use the Exchange 2010 performance policy for Exchange 2013?
Solved! Go to Solution.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-10-2014 01:10 AM
04-10-2014 01:10 AM
Re: Exchange 2013 NTFS Mount Points on VMware Performance Policy?
The blocksize of VMFS is indeed 1MB, but this is only for file operations done directly on the VMFS volume (= done by ESXi). Things like creating VMDK files, growing thin VMDK files, creating vmware.log files, ... So if you grow a VMDK file, it will be done in 1 MB blocks. (you have sub-blocks on VMFS-5 for small files though).
But ANY guest IO will be untouched and independant of the VMFS-5 blocksize. So if you Exchange VM send 32K blocks, that's what the Nimble will see, no matter what blocksize you use on VMFS (even on VMFS-3 with those different blocksizes).
Bottomline: if you VMFS contains only VMDKs with exchange databases then yes, chose the Exchange performance policies on the Nimble for those OS-es and NOT the VMware one. Same applies for SQL or Oracle running on VMs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-10-2014 02:52 AM
04-10-2014 02:52 AM
Re: Exchange 2013 NTFS Mount Points on VMware Performance Policy?
Hey Sammy,
I believe even in VMFS 5, VMware will still use 4k blocks to send and receive IO to the storage array regardless of the IO being sent from the VM layer. Therefore regardless of the application type being stored in the VMFS, the ESX 5 performance policy should be used on the array for all VMFS volumes. Otherwise this could cause unnecessary block misalignment and/or fragmentation and wasted space.
EDIT: Above is incorrect - VMware doesn't divvy up the blocks to 4k increments (as pointed out by Sammy).
The SQL/Exchange performance policies should only be used if doing direct connect iSCSI volumes to Windows VMs through the VM iSCSI Initiator & using Nimble Connection Manager for Windows.
Global Storage Field CTO & Evangelist
twitter: @nick_dyer_
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-10-2014 03:05 AM
04-10-2014 03:05 AM
Re: Exchange 2013 NTFS Mount Points on VMware Performance Policy?
Hi Nick,
that's not true. VMware will NOT break IOs from the Guest VMs in smaller pieces. Check out the blog below by one of the Nimble engineers:
Myth Buster: Top three myths in block size
He also confirmed to me that you can and should use the SQL/Exchange performance policies when you use VMFS/VMDK but only when you limit that VMFS datastore to those disks. So one VMFS for Exchange DB, one VMFS for Exchange Logs, one VMFS for SQL DB, ... each with the correct perf policy set.
The vSphere 5 policy will be valid for your general VMs and the systems drives of those SQL, Exchange, ... VMs.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-10-2014 03:10 AM
04-10-2014 03:10 AM
Re: Exchange 2013 NTFS Mount Points on VMware Performance Policy?
Ah yes, I forgot about that post. Well referenced!
You're right in the respect that if and ONLY if that VMFS will store Exchange volumes then the Exchange perf policy can be used. However if Storage DRS is in place, or the VMFS may be shared by other applications then the ESXi 5 policy should be used instead.
Global Storage Field CTO & Evangelist
twitter: @nick_dyer_
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-10-2014 03:13 AM
04-10-2014 03:13 AM
Re: Exchange 2013 NTFS Mount Points on VMware Performance Policy?
True indeed.
We use this method for our SQL & Exchange VMs because our policy is VMDK only and not in guest iSCSI. So then we set up dedicated VMFS volumes for those applications. Works fine, but you have to pay attention to those things you mentioned like Storage DRS etc.
Blocksizes, NTFS allocation units, ... it's always a fun thing to discuss and lead to may interesting discussions :-)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-10-2014 03:35 PM
04-10-2014 03:35 PM
Re: Exchange 2013 NTFS Mount Points on VMware Performance Policy?
So I guess the real question here then is since we're using mount points instead of drive letters. The mount points have a performance policy based on what is on them, in this case Exchange DB and logs.
The question was really since we are using mount points, would the performance policy need to be for Exchange or for VMware for the VMDK holding the guest initiated mount points.
I would assume the VMDK could have whatever performance policy (preferably the VMFS5 one) and the mount points would actually need the performance policy of the data on them.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-14-2014 07:32 AM
04-14-2014 07:32 AM
SolutionHi Julez
The performance policy bit of this question has been answered above i.e. if iscsi direct connect to guest then exchange, if vmdk's to host exchange data then either ESX if shared datastore or exchange if dedicated datastore.
In terms of the policy for Exchange 2013 yes use the Exchange 2010 which sets the block size to 32KB (which is the same for Exchange 2013 anyhow).
In terms of the mount point root i.e. the disk which holds the mount points to the actual Exchange disks I would go with a small VMDK that is hosted on the same datastore as your Exchange server C:\ VMDK - mount points are just a reference to another disk and using a VMDK saves you a separate Nimble volume as you suggest.
Jason
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-14-2014 12:40 PM
04-14-2014 12:40 PM
Re: Re: Exchange 2013 NTFS Mount Points on VMware Performance Policy?
Thanks Jason, that was the route I was thinking about going with and just hearing it from a third party helps to solidify our data-store architecture for the new exchange deployment.
Now I just need to figure out why our third party consultant seems to think the new Microsoft best practice for Exchange 2013 is to keep the database and logs for that database on the same volume...which is contradictory to everything I've ever been taught up to this point, we're still waiting on the documentation that states that.
But in case anyone was interested in what we're doing, I've attached a PDF from the Visio diagram for the architecture we're proposing.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Email to a Friend
- Report Inappropriate Content
04-15-2014 06:45 AM
04-15-2014 06:45 AM
Re: Re: Exchange 2013 NTFS Mount Points on VMware Performance Policy?
Hi Julez
Thanks for sharing the architecture. My first thought in reviewing this is how are you intending on backing up Exchange? If you intend to use Nimble VSS snapshots I'd suggest you might want to have a single database per volume. Having only a single db per volume means that recovery of that volume doesn't impact the other replica db on the same volume (which of course would be restored as well). If however you are using another backup/recovery mechanism having more than one per volume would work fine.
I guess the other thing is that its only with Exchange 2013 that you can have more than one db per volume, but this change was primarily to support JBOD solutions to improve reseed times. Again you could always leverage Nimble VSS to help with reseeds anyhow - or at least to allow incremental rather than full reseeds, again this is dependent on your intended backup method.
I haven't seen the recommendation to store logs with dbs on the same volume, typically I've always kept them on separate volumes.
Jason
Hewlett Packard Enterprise International
- Communities
- HPE Blogs and Forum
© Copyright 2021 Hewlett Packard Enterprise Development LP