none
JBOD'ing the enterprise? RRS feed

  • General discussion

  • With E2010's improvements in Jet/ESE I/O & DAG redundancy, is anyone else thinking of JBOD'ing their servers if you have 3-plus copies of the database like MS has suggested? It is a very interesting proposition from Microsoft, a scary one at that and a mind-shift that wouuld have to take place when moving away from RAID, but the more we look at it the more it actually appears feasible. Being able to take a disk array and change those 50 spindles from supporting 15-20 databases to supporting 50 larger databases certainly makes our CapEx/OpEx look a lot better.
    Wednesday, April 15, 2009 5:19 PM

All replies

  • Sounds like a reasonable path to go in. Looks like MS is going to have to update its Storage Calculator spreadsheet again, lol.
    Keif Machado
    Wednesday, April 15, 2009 5:28 PM
  • Poor Ross. :P
    Wednesday, April 15, 2009 5:30 PM
  • You're not alone there.  But in our case the "rethinking" goes well beyond the concept of moving away from RAID but into considerations around our backup strategy (do we really want to do backups anymore with 3+ copies of the database available) and further considerations around moving away from our SAN architecture toward DAS and the IOPS considerations around that. 

    We will certainly be looking forward to a new version of the storage calculator - particularly with the changes around the store reducing IOPS requirements!

    I think my architecture team will be gleefully scratching our heads as we build our sandbox.
    Wednesday, April 15, 2009 6:37 PM
  • considerations around our backup strategy (do we really want to do backups anymore with 3+ copies of the database available)

    Do you really want to ditch the ability to restore accidentally deleted items, mailboxes etc? While I agree with the concept of replacing RAID with redundant databases (RAIB?), backups are already unnecessary from a disaster recover point of view (SCR, SAN clones) but we all still do them because backups offer a fundamentally different function, that of recovering data which is no longer on the disk, even if that data was removed on purpose.
    To put this in perspective, I recently recovered a mailbox which had been deleted, then purged, then the database and SG removed, then the user account deleted in AD. I am reletively confident Exchange 2010 won't help with this scenario. Of course, that client has been severely reprimanded so this scenario should never happen again!
    Dave
    Wednesday, April 15, 2009 8:50 PM
  • I am reletively confident Exchange 2010 won't help with this scenario. Of course, that client has been severely reprimanded so this scenario should never happen again!
    Dave

    You can only do so much to protect from an admin's mistake. :) Why was the mailbox itself purged in the first place? This is why there are deleted mailbox retention systems in place.
    Wednesday, April 15, 2009 8:54 PM
  • As you say, there's only so much you can do to prevent people harming their systems. The person in question doesn't really know Exchange, and decided to have a bash at fixing the problem rather than call support. We'll try to arrange him a special "admin" account for next time, one with all of the priveleges to open his mail :o)
    Wednesday, April 15, 2009 9:04 PM
  • "because backups offer a fundamentally different function, that of recovering data which is no longer on the disk, even if that data was removed on purpose."

    Indeed a decision around moving away from backups will of course be based on what purpose you have for backups.  Your enviornment and mine certainly differ in this respect.    As I don't utilize backups for recovery of data I would never be in the position to have to go through the process you describe.  I am lucky enough to have some support from my executive management and legal departments around the restoration of data and the "appropriateness" of storing critical data in our messaging system.  Additionally to supplement our data/mail retention policies we are/will use technologies such as archival systems, to supplement and enforce those policies.

    I certainly didn't mean to imply that anybody should go out and stop backing up their data without fully considering the implications.  A number of fundamental questions would need to be asked first.

    What I did hope to point out in my statement is that a number of "fundamental rules" which I - and I presume many other IT professionals - have taken as gospel are changing with E2010. 
    Wednesday, April 15, 2009 9:15 PM
  • I fully agree with what you say, and any well informed IT professional will make those choices as you describe so it's good that they are mentioned and discussed here and in technet docs. My devils advocate approach was mainly aimed at whether it should be marketed as a feature as it looks like it will since it's mentioned quite a few places.

    Wednesday, April 15, 2009 9:23 PM
  • Any thoughts on preventing incoming mail data loss during a site failure?

    Thursday, April 16, 2009 3:34 AM
  • Any thoughts on preventing incoming mail data loss during a site failure?


    Hey, Josh. At which point is the incoming mail? Not yet at the perimter, at the perimeter, on a hub server? The new Shadow Redundancy (I think that's the name) on the HUB servers tries to help with that, but if you lose a whole site's connectivity I bet we'll still have to go mail collecting at some point since the hubs in the site that failed can't be reached by the mailbox servers in the now-active site. :)
    Brian Day / MCSA / CCNA, Exchange/AD geek.
    Thursday, April 16, 2009 3:38 AM
  • Isn't that what archiving is for?
    Thursday, April 16, 2009 3:39 AM
  • No, Archiving is a replacement for client side PST's.
    Thursday, April 16, 2009 5:23 AM