Give your SAN to the SQL Team, Part #2

In Part 1 of this series, we made the audacious claim that you could use SATA disks without RAID to run Exchange! Here’s how you can achieve it.

Exchange 2010 introduces the concept of Database Availability Groups, or DAG for short. It’s a High Availability model that uses the best bits from Exchange 2007, known then as CCR, and uses the same technology to ship the database logs to as many members of the DAG as you may have configured. Since you’re shipping logs around and NOT the database as you did previously with your replicated SAN that means that now each copy of the database on each of the DAG members is a clean copy of the live database.

If any of the copies of the database has a minor glitch because the disks you’re using develops a bad sector, then each server is able to reach out to any other copy and request the page which has corrupted and receive a known good clean copy to patch itself with automatically.

Does that mean that Exchange can’t use SAN’s anymore? Of course it doesn’t. Exchange 2010 is able to use virtually any kind of disk you allocate to it. SAN volumes, DAS (Direct Attached Storage) shelves or JBOD (Just a Bunch Of Disks). Irrespective of the disk you give Exchange, you’re able to build a highly available distributed unit of high availability.

Using lots of relatively cheap and large SATA disks means you’re able to deploy lots of cheap Exchange servers with large mailboxes, which are highly available and mostly self-repairing. Using your SAN means you’re provisioning finitely sized mailboxes and expensive storage which is now potentially overrated for the task required.  As you may know, redundancy in your SAN isn’t cheap either, and mirroring your SAN to an offsite location can be desperately expensive.  In short, the use of SATA allows high availability to be achieved by distributing Exchange databases across cheap storage as opposed to one massive SAN which is mirrored somewhere else.

CAN Exchange benefit from your SAN? Of course it can, but you may find that the performance you get using low cost SATA based storage option with Exchange built in high availability through DAG’s will service your organization better than your SAN will. In fact, if you hand your high cost SAN back to your SQL teams for their use and step away from SAN infrastructure for your email, your company will win on two counts and you will become a hero outside of your own team!



Looking Back, Going Forward: 2010 in review

If you don’t know where you’ve come from- how do you know when you’ve arrived?

Before looking forward towards Cloud in 2011- let’s look back at 2010- in acquisitions, to see where the industry is putting its money:

I think it’s clear that Cloud crossed the Chasm in 2010 and the Enterprise Software Vendors have piled in with acquisitions to sure up their positions.

The main trends I would pick up from these acquisitions are:

  • On-ramp and Integration tools are critical to help Enterprises leverage Cloud (IBM, Dell)
  • Monitoring and Automation is key to Cloud (HP, Cisco, CA)
  • PaaS is the future of Application Development (Red Hat, Salesforce)
  • IaaS is key to Public and Private Clouds (CA)

So what will 2011 see for Cloud? Come back Friday.


Migrating from Microsoft Exchange 2003…

October 2003; seven years and a couple of months ago. A long time in the life of many things, especially technology.

There are several sites dotted around the web that list the major events that occurred in the year 2003, I’ll let you discover those for yourself, but a few key moments you might remember were:

  • Apple launched iTunes
  • Concord made its last commercial flight
  • 50 million people on the East Coast lose power

Of course October 2003 is also when Microsoft launched Exchange 2003, the fifth version of the popular Microsoft Exchange Server. When you think about that in relation to the other events I’ve mentioned it seems like a long time ago doesn’t it?

Yet even today some organisations are still holding onto Exchange 2003 with no solid plans to upgrade. I’ve been thinking about these issues a lot since I helped author a whitepaper on how to migrate Exchange successfully (registration required).

Are the benefits of Exchange 2007 or Exchange 2010 clear enough? Of course some organizations are reliant on custom applications that might not support an upgrade of Microsoft Exchange (I thought we’d all learnt that lesson with Exchange 5.5?) and if that is the case, you have my sympathies.

For the rest of you who don’t have an excuse, I often find the problem lies in a combination of cost and complexity.

Or, more accurately complexity and cost, as the cost is a product of the complexity. It’s a factor of corporate caution that puts a huge amount of effort and protection into these projects to make sure every eventuality is covered and nothing goes wrong (read downtime).

Why the complexity? Well it’s organic. We’ve grown up with the environment, we’ve added solutions and services on a regular basis, and now we’re standing at the foot of a towering mountain of IT solutions. Upgrading a central component of all that technology instantly becomes a much larger project than we first anticipated, probably requiring more resources and more budget than our first estimate.

That’s why 25% of your peers said that you don’t have the resources to perform the upgrade- they’re stuck in a sea of complexity- IT getting the blame for everything whereas it’s the business not giving IT budget. (The full survey results and analysis can be found here- registration required)

But they’re now two versions of Exchange Server behind with mainstream support already at an end, and extended support due to end in 2014 – people are going to need to find a way to tackle this problem soon.


[Video] What is the impact of reduced Disk I/O on Exchange 2010 Architecture design?

There is a lot of talk about the performance improvements in Exchange 2010- in particular the reduction in Disk I/O.

Is this real or imagined? What are the tradeoffs Microsoft has had to make in order to make this work?

Join Exchange Expert and Mimecaster Barry Gill talk through some of the issues when looking to design your Exchange 2010 environment to take advantage of the improved performance.



Justin Pirie (JP): So we’re back with Barry Gill, welcome to the Mimecast video blog. So, I’ve been hearing a lot of talk about the performance improvements in Exchange 2010, can you talk me through some of those please?

Barry Gill (BG): Well certainly Justin, I think one of the most significant performance that Exchange 2010 has introduced to us is the 70 to 75 percent input output or I/O performance improvement.

JP: So that’s disks isn’t it.

BG: That’s disk, yeah. Now what Microsoft have done is something they’ve been trying to get rid of since essentially Exchange 2000, is they’ve gotten rid of Single Instance Storage, so no longer are read and write operations are being scattered across platters on a disk, they are now, all of these processes are happening sequentially. So sequentially means there’s a lot less distance for the heads to travel across the drives which means they’re able to get these massive performance improvements.