tag:blogger.com,1999:blog-1691893524480808637.post7334600005479503050..comments2014-08-26T05:02:21.385+01:00Comments on Virtually Insane?: Exchange 2010 - Infinite Instance StorageDaniel Easonhttp://www.blogger.com/profile/09989008409906349470noreply@blogger.comBlogger8125tag:blogger.com,1999:blog-1691893524480808637.post-58095021942214455482010-01-07T17:53:05.063+00:002010-01-07T17:53:05.063+00:00Daniel,
Thanks for the clarification and concur a...Daniel,<br /><br />Thanks for the clarification and concur about the confusion around DAS being thought of as internal or dedicated. You bring up an interesting point about the class of shared external arrays such as the HP MSA which can be attached to servers via FC, iSCSI or SAS. What I find interesting is that yes, compared to an iSCSI or FC/FCoE or even NAS access, the shared external direct attached via SAS arrays are limited in terms of host connectivity. <br /><br />However that too is changing with table stakes currently at about two dual attached servers (assuming a dual controller array config), or 4 to 8 single attached servers (Dejavu or early FC and multi-init pSCSI?). An example of how things are changing is that some vendors including HP are supporting SAS switches to boost the number of dual/redundant attached servers to the arrays. Now that could beg the question of if that then qualifies switched SAS as a SAN however let’s leave that for the SAN police to debate.<br /><br />Disclosure: I have no affiliation with HP, Im simply a fan of and using for the applicable scenario including among others SAS as well as iSCSI, FC, FCoE and NAS as a means of accessing and using technologies in support of resilient, scalable and flexible data infrastructures ;)...<br /><br />Cheers gsgreg schulzhttp://storageioblog.comnoreply@blogger.comtag:blogger.com,1999:blog-1691893524480808637.post-18085256569854523632010-01-05T21:39:23.613+00:002010-01-05T21:39:23.613+00:00Greg,
Welcome to the blog....Very good point her...Greg, <br /><br />Welcome to the blog....Very good point here, DAS/SAN is misconstrued quite heavily in definition.<br /><br />When I hear MS Say DAS I think Directly attached SAS/SATA via SAS Cards and host level replication doing its "thang" to provide the continuity....<br /><br />I agree certain Directly attached fibre arrays like MSA's offer snapshots etc but they usually only scale to single figure server environments, which from a management perspective is still a large constraint on resource to manage.Daniel Easonhttps://www.blogger.com/profile/09989008409906349470noreply@blogger.comtag:blogger.com,1999:blog-1691893524480808637.post-59577780956132670172010-01-04T22:02:12.446+00:002010-01-04T22:02:12.446+00:00To clarify, I assume that in your examples, DAS is...To clarify, I assume that in your examples, DAS is being used to mean dedicated, direct attached internal disks vs. an external shared direct attached storage via SAS (or iSCSI or FC for that matter) type of connection?<br /><br />If that is the case, then things make much more sense.<br /><br />However, not all DAS is internal and dedicated as is a common perception. There are also external shared (e.g. SAS or FC or iSCSI) direct attached storage (e.g. no switches or SAN per say) RAID solutions with snapshots and other features that are being deployed for exchange (See MSFT ESRP results for some examples), vmware and other applications or workloads.<br /><br />Cheers gsgreg schulzhttp://storageioblog.comnoreply@blogger.comtag:blogger.com,1999:blog-1691893524480808637.post-64834160244735693702009-12-14T13:02:24.719+00:002009-12-14T13:02:24.719+00:00Here's the thing. In most of the Exchange impl...Here's the thing. In most of the Exchange implementations I've seen since Ex5.5, the gating factor that determines the amount of disk that Exchange uses hasn't been the quantity of email but the level of IO. What I suspect has happened here is that MS has run the numbers and determined that the space savings resulting from SIS don't outweigh the IO cost of additional look-ups in secondary indexes and tables. <br /><br />The thing is, the example of the company-wide mail with a 5MB attach isn't the reality of the situation with SIS. In practice, the vast majority of attachments go to a comparatively small number of people who may (or likely may not) be on the same server. Where they aren't on the same server (or storage group - I can't remember), SIS will be broken from the get-go. For years, MS have been telling people not to expect too great an effect from SIS due to the impact of things like mailbox moves and inter-generation migrations (both of which break SIS).<br /><br />Ultimately, anything that reduces the IO load for Exchange is probably going to end up reducing the number of disks you use for it. MS likely have the evidence and (I would imagine) have done the maths. I'd give them the benefit of the doubt on this one.Matt Poveyhttps://www.blogger.com/profile/07077636881622103599noreply@blogger.comtag:blogger.com,1999:blog-1691893524480808637.post-53107442950594174272009-12-12T14:34:07.396+00:002009-12-12T14:34:07.396+00:00@Simon Glad you agree :), I maybe jumping in feet ...@Simon Glad you agree :), I maybe jumping in feet first with this to critise (whats new), but generally I get concerned when Microsoft mention DAS as the answer to reducing my storage costs. They tried this with 2007 and it just dosnt cut it in Enteprise environments.<br /><br />The new Archiving again is a bit lame from what i've read, it dosnt again deduplicate messages like Evault or Quest Archive manager would, its basically a secondary mailbox with policy. However the target customer for this is the SMB sector I believe. <br /><br />@Andrew and @Anonymous, you make a valid point, and again it's all about how you change the way you think about Exchange. However even with a single Database of say 200 users, everyone receiving email within that DB could still amount to Gigs of data not MB....<br /><br />On compression and relevant benefits i am a bit skeptical about this, it must be file type dependant and only capable of benefiting compression with certain file types?<br /><br />Thanks for the hot replies (and flaming me down)...keep it comingDaniel Easonhttps://www.blogger.com/profile/09989008409906349470noreply@blogger.comtag:blogger.com,1999:blog-1691893524480808637.post-80027085064681958772009-12-12T05:55:05.765+00:002009-12-12T05:55:05.765+00:00As Anonymous mentioned the benefits of SIS have di...As Anonymous mentioned the benefits of SIS have diminished greatly in the last couple Exchange releases. The dedup only occurs within a single database and best practice says those shouldn't exceed 200GB (100GB if CCR is used), with mailbox size limits growing in many companies, usually 100-200 mbxs per database (perhaps as much as 500 users in rare cases). <br /><br />Also Exchange 2010 now compresses all attachments before storing them in the information store; this change is likely to have a greater impact than SIS did for 2007 deployments.Andrew Storrshttps://www.blogger.com/profile/18056687667967806573noreply@blogger.comtag:blogger.com,1999:blog-1691893524480808637.post-3066424171472106312009-12-11T17:43:33.025+00:002009-12-11T17:43:33.025+00:00Just a thought here. The advantages of SIS have b...Just a thought here. The advantages of SIS have been declining for some time now, as most organizations have gone from large databases with small mailboxes, to large mailboxes broken out into smaller databases for manageability reasons. SIS was great in Exchange 5.5, but the returns have diminished greatly. So in reality, the effects of dropping SIS aren't as harsh as you'd think.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-1691893524480808637.post-12144591724953121122009-12-11T16:46:16.826+00:002009-12-11T16:46:16.826+00:00Wow, this is the first I've heard of SIS being...Wow, this is the first I've heard of SIS being removed and not replaced by something similar. I'm going to have to do some investigation into it myself now.<br /><br />This is a massive oversight on Microsoft's part as IMHO although the arguement of disk now being cheaper is true the same arguement could be made in that CPU clock speeds are now much higher (increased core count, etc) for effectively the same money as in the past. I would much rather throw extra CPU resource (for the very little overhead I'm sure SIS actually adds) than that of adding extra disk any day of the week. <br /><br />I wonder how all this plays into Exchange 2010's new found archival functionality - does it dedupe at this stage perhaps? <br /><br />Also, wouldn't it be greener to burn a few extra watts of power on CPU cycles to keep SIS or similar as opposed to keeping additional disk spindles running to accomodate all this extra duplicated email data?<br /><br />Thanks for an interesting post and I'd be interested to hear the thoughts of others on this.<br /><br />Keep up the good work on the blog.<br /><br />Cheers,<br /><br /><br /><br />Simon<br />www.techhead.co.ukSimon (TechHead)http://www.techhead.co.uknoreply@blogger.com