Flipping Bits

What’s in your SLA?

People have been considering and comparing public (hosted) and private (on-premises) cloud solutions for some time in the messaging world, and at increasing rates for database and other application workloads.  I’m often surprised at how many people either don’t know the contents and implication of their service provider service level agreement (SLA), or fail to adjust the architecture of private cloud solution and then directly compare cost. 

Here are my five lessons for evaluating SAAS, PAAS, and IAAS provider SLAs:

Lesson 1: Make sure that what’s important to you is covered in the SLA

Lesson 2: Make sure that the availability guarantee is what you require of the service

Lesson 3: Evaluate the gap between a service outage’s cost to business and the financial relief from the provider

Lesson 4: Architect public and private clouds to the similar levels of availability for cost estimate purposes

Lesson 5: Layer availability features onto private clouds for business requirement purposes

I’ll use the Office 365 SLA to explore this topic – not because I want to pick on Microsoft,  but because it’s a very typical SLA, and one of the services it offers (email) is so universal that it’s easy to translate the SLA’s components into the business value that you’re purchasing from them.

Defining availability

The math is simple.  It’s a 99% uptime guarantee with a periodicity of one month:

If that number falls below 99, then they have not met their guarantee.  For what it’s worth, during a 30 day month, the limit will be about 44 minutes of downtime before they enter the penalty, or about 8.7 hours per year.

But what does “Downtime” mean?  Well, it’s stated clearly for each service.  This is the definition of downtime for Exchange Online:

“Any period of time when end users are unable to send or receive email with Outlook Web Access.”

Here’s what’s missing:

• Data:  The mailbox can be completely empty of email the user has previously sent and received.  In fact the email can disappear as soon as they receive it.  As long they can log in via OWA, the service is considered to be “up”.
• Clients:  Fat outlook, blackberry, and Exchange ActiveSync (iPhone/iPad/Winmopho, and most Android) clients are not covered in any way under the SLA

Lesson 1: Make sure that what’s important to you is covered in the SLA

Lesson 2: Make sure that the availability guarantee is what you require of the service

Balancing SLA penalties with business impact

My Internet service is important to me.  When it’s down, I lose more productivity than the $1/day or so I spend on it.  Likewise, email services are probably worth more than the $8/month/user or so that you might pay your provider for it.  That doesn’t mean that you should spend more than you need for email services.  But it does mean that if you do suffer an extended or widespread outage, there will likely be a large gap between the productivity cost of the downtime and the financial relief you’ll see in the form of free services you’ll see from the provider. 

Callahan Auto Parts also offers a guarantee

I’ll put this in real numbers.  Let’s say I have a 200 person organization.  I might pay $1600/month for email services from a provider.  If my email is down for a day during the month, my organization experiences 96% uptime for that month, and as a result, my organization is entitled to a month of free email from the provider, worth about $800.

The actual cost of my downtime will very likely exceed $800.  To calculate that cost we need the number of employees, the loaded cost per hour for the average employee, and and the productivity cost of the loss of email services.  For our example of 200 employees, let’s imagine a $50/hour average loaded cost to business and a 25% loss of productivity when email is down:

200 employees x $50 cost per hour x .75 productivity rate x 8 hour outage = $60,000 of lost productivity

Subtract the $800 in free services the organization will receive the next month, and the organization’s liability is $59,200 for that outage.

Now how do you fill that gap?  I’m not entirely sure.  It could be just the risk of doing business – after all, the business would just absorb that cost if they were hosting email internally and suffered an outage.  If the risk and impact were large enough, I would probably seek to hedge against it – exploring options to bring services in house quickly, or even looking to an insurance company to defray the cost of outages – if Merv Hughes can insure his mustache for $370,000, then surely you can insure the availability of your IT services.  Regardless, it’s wise not to confuse a “financially backed guarantee” with actual insurance or assurance against outage.

File Photo:  What a $370k mustache may look like.  Strong.

Lesson 3: Evaluate the gap between a service outage’s cost to business and the financial relief from the provider

Comparing Apples to Oranges

See what I did there?

Doing a cost comparison between public cloud designed to deliver 99.9% availability and a private cloud designed to provide 99.99% or 99.999% availability makes little sense, but I see people do it very frequently.  Usually it’s because the internal IT group’s mandate is to “make it as highly available as possible within the budget”.  So I’ll see a private cloud solution with redundancy at every level, capabilities to quickly recover from logical corruption, and automated failover between sites in the event of a regional failure, compared to a public cloud solution that provides nothing but a slim guarantee of 99.9% availability.  In this instance, it’s obvious why the public cloud provider is less expensive, even without factoring in efficiencies of scale.

To illustrate this, I usually refer to Maslow’s hand-dandy Hierarchy of Needs, customized for IT high availability.

 

Single Site and Multi-site Hierarchies of Need

If I want to make an accurate comparison between a public cloud provider’s service and pricing and what I can do internally, I often have to strip out a lot of the services that are normally delivered internally.  Here’s the steps:

1. Architect for equivalence.  If I have a public cloud provider just offering 3 9’s and no option for site to site failover, for my database services, I might just do a standalone database server.  Maybe I’d add a cheap rapid recovery solution (like snapshots or clones) to hedge against compete storage failure and cluster at the hypervisor layer to provide some level of hardware redundancy.  If my cloud provider offers disaster recovery, I’d figure out what their target RPO/RTO and insert some solution that matches that capability.
2. Do a baseline price comparison.  Once I’ve got similar solutions to compare, I can compare price.  We’ll call this the price of entry.
3. Add capabilities to the private cloud solution after the baseline.  I only start layering features that add availability and flexibility to the solution after I’ve obtained my baseline price.  Only then can I illustrate the true cost of those features, and compare them to the business benefits.

Lesson 4: Architect public and private clouds to the same levels of availability for cost estimate purposes

Lesson 5: Layer availability features onto private clouds for business requirement purposes

Is it time to say goodbye to Jetstress?

The short answer?  “Yes”  The long answer?  “Yyyyyesssss”

But first let me get this out of the way:  If you want to run Jetstress against any storage configuration I come up with, feel free.  I wouldn’t put it forward if I weren’t confident it could handle the workload. 

Prior to 2007, Jetstress REALLY mattered.  You had 500MB mailboxes that could easily 2-5 IO/s per mailbox.  Cached clients were rare – so storage latency was the primary driver of customer complaints.  Over the last ten years, Microsoft has put a lot of effort into making Exchange a much more storage-friendly application, and they’ve succeeded.  Today you have 0.1 IO/s per mailbox, and it’s spread over 2-5 GB.  Exchange is now Just Another Workload.  So why are we spending all this time and money (not to mention implementation delays) using an unwieldy purpose-built testing tool for something that’s Just Another Workload?

With Exchange 2010 and its very modest IO profile, I question the value of Jetstress as opposed to other testing tools.  The level of effort and sheer amount of time required to create the databases, replicate them, and then run the test are significant.  It can run to weeks for reasonably sized deployment.  Yes, you get assurance that your storage rig is operating properly, but you can get that assurance from tools like Iometer, which can take seconds to set up, and mere hours to complete.

For all the effort and time involved in a Jetstress run, I just expect more.  I’d expect that my entire infrastructure would be validated.  I’d expect assurance that I have enough RAM and CPU in my virtual machines, that my network is up to snuff, access to my domain controllers and global catalog servers is sufficient… but I don’t get any of that with Jetstress.

If I’m going to put in the kind of time and effort into my testing that Jetstress requires, I’m going to fire up an entire infrastructure and use Loadgen and verify my entire configuration – not just my storage.  On the other hand, if I’m going to test my storage independently from my server and network, I would:

Roll my own Exchange IO test with Iometer in 30 minutes

• Set up your storage on a your production mailbox server
• Determine the file sizes for your database and logs  You can find that on the LUN Requirements tab of the Exchange Mailbox Storage Calculator

• Using fsutil (built in Windows command line tool), create files called iobw.tst sized according to the DB Size + Overhead and Log Size + Overhead using fsutil.  For our example, we’re looking at 1595 GB database files and  34 GB log files.  This part is not strictly necessary, but I like it.  Creating a file called iobw.tst in the root directory of the target will prevent ioMeter from creating thick files that occupy the entire LUN.
  • fsutil file createnew e:\iobw.tst 1672478720 <----------simulated 1.5 TB database file
  • fsutil file createnew f:\iobw.tst 35651584 <-------------simulated 34 GB log file
• Download Iometer and the Exchange 2010 .icf file I’ve created.  Launch ioMeter and open the icf file.
  • If you’re using mount points instead of drive letters, download the latest Iometer Release candidate for mount point support
• Determine the target IO throughput for the databases and logs.  This can be determined from the Role requirements tab of the Exchange 2010 Storage calculator

 

• Modify the transfer delay in “Exchange 2010 DB Workload” Global Access specification so it will generate the desired number of IOs. The math is: 1000 ÷ target IO/s. Our example requires 30 IO/s per database, and 1000 ÷ 30=33.3.  So we’ll set it to 33.  The original in the icf file is 25, which would generate 40 IO/s.

• Modify the transfer delay in the “Exchange 2010 Log Workload” Global Access Specification so it will generate the desired number of IOs.  Our example requires 7 IO/s per log LUN, and 1000 ÷ 7=142.8, so we’ll set it to 143.  The orignial in the .icf file is 100, which would generate about 10 IO/s.

• Assign the DB Worker and BDM Worker to the database LUNs
• Assign the Log Worker to the Log LUNs
• Click the Green Flag and start.  Let it run for 5-10 minutes for a quick sanity check, and stop it.  Make sure it’s driving the IO you want at the latencies you expect, and you’re not gated by CPU or anything like that.
• Start a perfmon data collection (perfcollect is good for this).
• Modify the test tab for a however long you’d like.  I recommend at least a few hours.

• Take a nap
• Go for a run
• Eat some food
• Watch some TV
• When the test completes, open up your perfmon file, look at your disk latencies, make sure they’re steady, there were no spikes, and there were no aberrations in number of IO/s
  • If you’re an EMC customer and use perfcollect, zip up the perfcollect data collection and send it to your TC, or reseller TC, and ask for a WPA (miTrend) report on the server(s).  You’ll get a nicely formatted report with graphs and tables and twenty-seven 8x10 color glossy pictures with circles and arrows and a paragraph on the back of each one

Using this method, you can get in and out of testing mode within easily 36 total hours, and your time will be less than an hour of setup and analysis.  That translates into weeks of time where your users can spend enjoying your cool new messaging infrastructure.

SQL Licensing and Virtualization: Lemons and Lemonade

Virtualizing SQL Server is not a new conversation for anybody who’s been around the technology over the last few years.  But recently there’s been a new twist to the conversation regarding licensing.

Microsoft has changed the licensing model for SQL Server Enterprise Edition 2012 (SQLEE).  It’s important to remind people here that Enterprise Edition is the only way to get high availability with SQL Server.  With SQL 2008, you could license Enterprise Edition under the “Server+CAL” model.  This meant that customers could buy virtually unlimited SQL processing with Enterprise features and, by limiting the number of clients directly accessing SQL, they could limit the cost of the SQL licensing.

The Lemons (SQL Licensing Changes)

“Per core” licensing is the only option available to SQL 2012 EE customers.  In a virtual environment, it’s “per vCPU”.  What’s more is that any server licensed for SQLEE needs a minimum of 4 licenses, regardless of the number of cores or vCPUs in use.  This is no surprise, and I don’t think any of us should hold this against Microsoft.  SQL Server is a very robust database platform, and its primary competitor has used this licensing model for many years now – Microsoft has been undervaluing their technology for the better part of a decade.

But let’s take a look at the kind of effect this can have on licensing costs.  Most of the time I see physical SQL Servers with 16 cores.  This makes sense – a decent server with 4 quad core processors is of pretty good value from almost any server vendor.  Through savvy application layer design, customers can limit the number of clients and devices directly querying the database; normally I see between 4 and 10 clients per server.  The list price for SQL 2008 EE was $8,500 per server, plus $150 per CAL.  So you could walk out the door with a highly available SQL Server for $10,000.  With SQL 2012 EE at $6,874 per core, this same server would cost $109,984 – nearly an 11x increase in price.

Even if you don’t have a processor intensive workload, this can still be costly.  Let’s say you can rip out 3 of those 4 processors and still run efficiently.  After all, not all business critical workloads are processor intensive, right?  But even the smallest possible server is going to cost nearly 3x the licensing of a 2008 Server+CAL model

The Sugar (All-you-can-eat SQL Server Enterprise)

Microsoft has embraced virtualization with its new SQL licensing model.  I might need HA for a workload, but it might not be processor intensive.  The graph below shows a prime example, where the CPU at peak is 31% busy.

This particular server has 16 cores, and as we’ve seen, cores = money in the SQL 2012 world.  If this customer could find a way to use those idle cycles for other SQL workloads, then they can save some significant money ($63,000 to be exact).  There are a few different ways to do this:

• Putting multiple databases in a single instance
• Putting multiple instances on a single physical machine
• Putting multiple virtual machines on a single physical host

Microsoft has embraced virtualization here, because if you license the processors on a given physical machine SQL Server Enterprise, you can put all the SQL Server Enterprise VMs you want on that physical machine.  It doesn’t matter which hypervisor you’re using – VMware, Hyper-V, Xen, or Joe’s Hyperific Emporium and Bait Shack’s HyperVisor.  As long as it’s on the SVVP list, you can do it.  The two big caveats are:

• If a VM is running SQL Server, either all the cores on the physical box hosting it must be licensed, or the VM must be licensed in a per vCPU manner
• If you have gone with the core model in a virtualized environment, you need Software Assurance, or you are limited to one physical server move per 90 days.

The Water (Sub-Cluster licensing)

One of the biggest mistakes people make is licensing all the cores in a hypervisor cluster, or going to the trouble of building a dedicated cluster for SQL Server.  The first is far more expensive than it needs to be, and the second eats into the flexibility and value proposition of virtualization.  Let’s say I have an 8 node cluster, with 16 cores each.  This would cost about $900,000 to license.  I might be tempted to create a smaller cluster just dedicated to SQL Server.  But then I would be creating a processing silo, which wouldn’t be able to be shared amongst my other workloads.

The best option by far is sub-cluster licensing.  I could license just one of my servers, run as many VMs that can fit on that server.  I can still have HA, because passive nodes in a failover cluster do not need to be licensed.  If I move all my SQL VMs en masse to another host, I still have to license only one host.  Density is the key here.  Most people will do 4:1 vCPU:Core ratio and still get by just fine.  Some of Microsoft’s models do up to 12:1 vCPU:Core ratio, and if you can get assure performance with that model, you can get absolutely fantastic savings.  This graph compares 4 Physical Servers with the minimum of 4 cores each compared to a virtualized infrastructure with the 4 vCPUS and a conservative 4:1 vCPU:core ratio.  Most shops I see will consolidate more aggressively for more savings.

The Lemonade (Enterprise Edition for All)

Being able to choose SQL features like failover clustering and availability groups based on the workload rather than the licensing cost is by far the best aspect of this approach.  Imagine you have 8 SQL Standard Edition servers and you can consolidate those on a virtual platform with a 2 vCPUs:VM and a 4:1 vCPU:Core ratio.  You can get Enterprise features for those instances, and STILL save money on licensing.

The Blender (Performance Metrics)

For most folks, it’s not a matter of whether you can benefit from the approach, it’s how much you can benefit from it.  Everybody has some spare CPU on their physical servers, and a renewed server infrastructure would only create more spare CPU cycles.  So do some simple data gathering.  Look at how much CPU you have left over today.  Do some math to figure out how much spare CPU you’d have on a new compute infrastructure.  I’ve stepped through this exercise with numerous customers, and they’ve all been surprised at the extent to which this can not just save money, but add features and functionality to their environment.

Perfcollect 4.1

I’ve updated perfcollect with a number of new features:

• New perfmon counters:  These new data will be in the larger of the two files in the perfmon directory.  The new counters are related to:
  • Hyper-V
  • Cluster Shared Volumes
  • VMware guests
  • Xendesktop
• Visibility into the physical storage:  These files will have “inq” in the file name and reside in the config\detail directory of the output.
  • Detailed information about the LUNs serviced by EMC mid-range and high-end storage arrays
  • Vendor, model number, revision, serial number and capacity of disk drives
• Partial non-english language support: Because perfcollect relies on string searches to determine which counters to collect, previous versions of perfcollect would fail to execute the data collection when some (but not all) language packs were active (as outlined in the readme).  Version 4.1 detects this condition performs a number of actions:
  • Creates and runs a perfmon collect with a subset of the counters.  This counter file includes all the PhysicalDisk, LogicalDisk, Cluster Shared Volume, and SMB Client Share counters.
  • Notifies the user with the text “Building Perfmon counter list for the Non-English Language Pack...” during the run
  • Completes entry into the debug\progress.txt file with “Non-english perfmon counter build finished”

The resulting non-english perfmon file should be adequate for sizing purposes, but will not have all the counters required to evaluate application-level performance (for example, there will be no detail around SQL Server, Exchange, Hyper-V performance).  If you need to troubleshoot or triage a performance problem with a particular server, please install and enable the English language pack, or manually create the data collector set.  Installing and enabling a language pack does not require a reboot.

Perfcollect video series

Perfcollect is really easy to use, but generates a bunch of interesting data which can be bewildering to a new user of the tool.  So I’ve started a little video series on the topic, which perhaps will blossom into a series on Windows performance analysis and triage in general.

I’ve got three up now, all linked off the perfcollect page.  The videos are hosted on EMC’s Everything Microsoft at EMC site – you don’t need to have a login to watch the videos.

Right now, here's what's up there:

• Running Perfcollect
• Troubleshooting Perfcollect
• Evaluating Perfcollect data
• Using Perfcollect with the PAL tool

 

Enterprise Flash Drives: not just performance

I often encounter the misconception that EFDs are not beneficial unless you need to either reduce latencies below what traditional disks can get you, or you’re short-stroking your disk in order to maintain performance.  So I figured I’d go through the three general use cases I talk about with EFDs:

1. Do more stuff
2. Do the same stuff faster
3. Do the same stuff, but with less gear

These are not mutually exclusive.  In most cases, EFDs allow people to do more stuff, faster, with less gear.  But your goals for EFDs will certainly flavor how to best deploy them.

Do more stuff (increase scale)

Let’s use an entirely contrived order processing system (like a trading desk). Let’s say this system can support 1,000 trades a minute. But during peak trading times, you’re getting more trades than you can process.

The business case for EFDs here would be that you can increase revenue by processing more orders.  Here’s an example where six EFDs supported seven times the transactions of six traditional fibre channel drives.  And this is a perfect example of how increased scale and reduced latency are not mutually exclusive – the response times on the EFD drives were 7 times lower than the response times on the spinning disks.

source

Note that both of the cases thus far really depend on how much your EFDs cost, and how much productivity improvement you’re going to see from their deployment.  That’s significantly different than this one:

Do the same stuff faster (reduce latency):

Let’s take a large manual order-entry system, where user wait time for a query is 5 seconds, and users do about a one query per minute. Let’s say the performance gate in this scenario is storage and it’s getting about 5-7 ms latency (about as good as you can get with a performance HDD at scale due to rotational latency).

The business case for EFDs here would be that employees in this role spend about 8% of their time waiting on the database. If you can reduce that to 1.6%, you realize massive productivity improvements.

Here’s some data: Note the graphs are not on the same scale.

source

Do the same stuff, but with less gear (decrease footprint): 

Let’s say that you’ve got an application that’s fat and happy residing on ninety 10k performance HDDs.  You’re not short-stroking them too badly, but it’s still taking about $6,000 a year to power them, $2,000 a year to cool them, about 18U of rack space to store them, not to mention the maintenance cost associated with them.  But the fact is that in most environments, only part of the data set is actually frequently accessed.  An example of this might be an order processing or inventory system that may go back years or even decades.  The old data isn’t accessed very frequently at all, while the newer data is getting hammered.

Using either manual or automated tiering, you put the older data on cheaper, denser, and more power efficient nl-SAS drives, while the most frequently accessed data can reside on faster, less dense (but still more power efficient) EFDs.

Here’s some supporting data.  Now, the performance was slightly increased, but the bulk of the savings came in the form of footprint – acquisition, power, management, and so forth.  Had the goal been to increased scale or reduce response time, then the deployment method would have differed.

  

source

Three SQL Server 2012 Game Changers you might not know about

SQL 2012 has a lot of changes for storage – naturally people focus on Availability Groups and all the flexibility that they bring in terms of workload isolation, high availability, and disaster recovery.  Here are a couple of nuggets you might not know about:

• Support for SMB/CIFS shares:  For at least a decade (if not longer) Oracle DBAs running in *nix environments have enjoyed the possibility of accessing their data files over NFS.  It allows a lot of flexibility, opens new possibilities for disaster recovery, and greatly simplifies storage provisioning, maintenance and expansion.  Now SQL admins have access to the same storage technique as their Oracle counterparts.  There are some considerations – particularly for those who choose to achieve high availability with shared-storage clusters.  The current version of SMB doesn’t support transparent failover, but that will be fixed with the new version of SMB (arriving with Windows Server 8).
• Placement of tempdb on local disk in clustered environments:  This is probably not a big deal for folks who don’t do geographically dispersed clustering.  But in past versions of SQL server, tempdb had to be placed on a clustered disk on which the SQL resource group was dependent.  In geographically dispersed environments, this meant that tempdb had to be replicated (something that’s not necessary if you’re just replicating the data and not trying to stretch the cluster).  There have always been methods to achieve it, but the methods required going outside the context of SQL Server.  Reduced bandwidth utilization and faster failover FTW!
• Multi-subnet clustering:  Microsoft made a lot of improvements in their clustering model with Windows 2008.  One of those improvements allowed administrators to have nodes in a cluster reside in separate subnets.  Unfortunately, SQL Server 2008 didn’t support it, but SQL Server 2012 does.

Max Worker Threads in upgraded SQL instances

The default Max Worker Threads setting is 255 in SQL 2000, and 0 in SQL 2005 and later.  It’s not actually zero, but setting it to zero allows SQL to determine the setting based on the server configuration (whether it’s 32 or 64 bit, and number of processors).

Microsoft is pretty clear that the setting should only be changed under their guidance:

“If you configure a number of worker threads to a value that is greater than the default, it is almost always counterproductive and slows performance because of scheduling and resource overhead. Only increase this setting under very unusual circumstances and when rigorous methodical testing demonstrates that it is useful to do so.”  (Emphasis theirs.  Link)

So I was surprised when a customer found it set to 255 on their SQL08 instance, and asked our advice on changing it.  They said nobody had changed it from the default.

It turns out that when you upgrade an instance, the setting is inherited from previous version.

So if you’ve got an ancient install that’s been upgraded, it’s worth your time to check it out and change it if necessary.

SQL Server Logical Disk Layout

A few weeks ago, I was talking to a meetup of SQL Server folks here in the Hartford area about storage and SQL Server. We were going through the ideal storage layout of SQL server, and someone in the group summarized it as "so I need a minimum of five disks (LUNs) for a SQL Server?" I'd never really thought of it in those terms, so let's get down to the thinking:

First, this has mostly to do with logical layout of data. Aside from separating logs and databases on different physical media, it has nothing to do with physical layout of data. Even if you have only a couple of disks to allocate to the server, you can still logically partition it so that it's easy to evaluate performance later on.

As with almost everything else related to SQL Server, it's going to depend on the workload. The key aspects are:

• Performance sensitivity - This is not necessarily a performance intensive workload – it could be nearly idle. The key question is "if performance of this application suffers, which business processes will suffer, and how many users will suffer?" If there's a chance that someone important is going to call you up and ask you to fix a performance problem with this SQL server, it's performance sensitive. Even if you're resource constrained, it would help to have things laid out so you can evaluate performance without reconfiguring the database (which in reality includes nearly as much effort as migrating to entirely new storage).
• Recoverability – This would be dictated by whether you'll need to be able to perform up to the minute recovery of the database. If you do, you'll need to consider the physical layout of the data so that the failure of a physical disk or RAID group doesn't take out the database and its transaction logs at the same time.

Here's a quick version of the rules:

1. If your database is neither performance sensitive and you do not need the ability to recover data up to the last transaction, then you only need one or two:
   1. OS/Apps
   2. Databases and transaction logs
2. If the data in your database is critical enough that you'll want to be able to recover up to the latest transaction, you'll need three.
   1. OS
   2. Databases
   3. Transaction logs (you also need to make sure that these are physically separated from the databases, so that you don't lose data from both of them at the same time).
3. If your data is performance sensitive (regardless of whether the data is sensitive), you need a minimum of five, and possibly more:
   1. OS
   2. System databases (other than tempdb)
   3. User databases
   4. User database transaction logs
   5. One for tempdb and its logs

The principle behind this separation is the performance evaluation of these components independently of each other. If I have my user databases mixed with tempdb, and I'm having performance issues, I have no real way of telling which database is presenting the IO, and which database is starving. All I know is that performance stinks equally on both databases. More importantly for transaction logs, you want to both avoid contention between the IO that log flushes create and normal user IO, and you also want to make sure that transaction log disks get a write response time of well less than 10 milliseconds.

These five LUNs are a starting point – I often see systems with a dozen or even a couple dozen LUNs. What's the reason for adding LUNs above this five?

• Additional segregation of the unrelated workloads. I can put two different databases on two different LUNs.
• Segregation of related, but different workloads. For example, I could put my non-clustered indexes on different disk than my data files.
• Simply adding queues – each disk gets an additional queue
• Increase the granularity of restore options if you're using hardware-based snapshots, clones, or CDP. In this case, the management boundary is the LUN itself, so if you want to do rapid restore of a failed or corrupt data file using this method, then you would restore all the databases on that LUN together (whether they are corrupt or not). There are ways to do selective restore in this case, but it can take longer to perform the restore.

Remember that multiple LUNs can actually share the same physical disks, so your workloads can still step on each other if that's the case. However, it makes the troubleshooting process much easier. And if you're using the right technology, fixing the problems can be completely seamless.

Hartford SQL Server Meetup!

Chuck Boyce has created a SQL Server meetup.  He spun up the Philadelphia SSUG, and I’m hoping he can weave his magic for Hartford!

Our first event will be on January 24th at the EMC office in Rocky Hill at 7pm.  I’ll be presenting on storage basics for DBAs, including techniques to analyze and improve storage performance and availability, various techniques for disaster recovery and application failover.  We’ll have a few giveaways and some food.

Make sure to RSVP here at meetup if you’d like to attend so we can make sure you get information around how get there and into the building.  We look forward to seeing you there!