Review | Brent Ozar PLF | Brent Ozar PLF

Tag Archive: review

Book Review: SQL Server 2008 Administration in Action

Written on March 10, 2009 by Brent Ozar in SQL Server, SQL Server Book Reviews, SQLServerPedia Syndication

Let’s start with the obvious: yes, there’s a man on the cover smoking something. It’s probably not a coincidence that when I started writing this review, the iTunes Genius started playing Poison’s “Nothin’ But A Good Time.” There’s a reason they call it the Genius, and yes, I do have Poison in my MP3 collection, and yes, I paid for it. (It was in my CD collection back when I listened to physical media, and it was in my tape collection before CDs came out.)

Sssssmokin!

It’s Online, But It’s Not Books Online

Rod Colledge covers a wide range of material here, but the surprising part is that it doesn’t read like a copy/paste of Books Online. Seems like the thicker a book is, the more it feels like a copy of BOL, and I can certainly understand why – it’s tough to produce a big volume of material with a personality of its own. Big books require multiple authors, and then sometimes editors set about stripping the personality out to make it blend together. Nothing against Books Online – I rely on it all the time for help with syntax and minute details. Thing is, I don’t want to read a book cover to cover when it’s full of syntax and minute details. Right now, Manning is offering an Early Access Edition via PDF, and I hope the casual language survives the editing process.

If anything, this book is probably a little light on syntax and implementation details – for example, Instant File Initialization is covered, but not in enough detail to explain step by step exactly how to configure it in Windows. I don’t have a problem with this approach: I like reading books to understand concepts, and I rarely sit with the book propped open next to me and type the code in off the printed page. I’m fine with doing a quick web search to get the exact content I need from sites like BOL.

Target Audience: Production Database Administrators and Performance Tuners

I recently write a book review of SQL Server 2008 Management in Action by Ross Mistry and Hilary Cotter, and I called it a great book for production DBAs and accidental DBAs. I would categorize this book differently: it’s more focused at production DBAs who want to dive deeper into SQL Server. Accidental DBAs will find this book too detailed and deep for their needs.

For example, in Chapter 14, Monitoring and Automation, Rod talks about deadlocks, including how to create them, how to monitor for them, and how to create a a SQL Server Profiler trace to catch blocked processes. He also shows how to use the RML utilities to clean up your Profiler traces and get better insight out of them. These types of topics are probably outside of what an accidental DBA would want to accomplish, but it’s exactly the kind of thing that a full-time production DBA has to get involved with sooner or later.

Both of these books, however, take the same approach of focusing on administration, not development. If you want to learn how to write T-SQL, how to use functions, or how to design a schema, this is not the book for you – look for a SQL Server development book instead. If you spend your day managing more than 25 instances of SQL Server, this is a good book for you.

Areas for Improvement

I’d quibble about the book’s organization. For example, Chapter 2 is titled Storage System Sizing, but it encompasses a lot of aspects of storage from RAID levels, direct attached storage, SANs, solid state drives, etc. Chapter 3 is called Physical Server Design, but it continues with storage topics like disk configurations and RAID array stripe sizes. My advice: ignore the table of contents, and just dig through the entire book. It’s worth it.

Appendix A lists the Top 25 DBA Worst Practices, including things like “Using RAID 5 volumes for write intensive applications.” They’re great advice, but I might include a pointer to the section of the book that explains why it’s a worst practice. It’d help the DBA drill down to learn more, and there’s certainly enough information in the book to back up what Rod suggests. It’s not an issue of just tossing out suggestions without backing them up – if you read this book cover to cover, you’ll understand the reasoning behind each suggestion.

Overall: Good Resource for Curious Production DBAs

I’d describe the perfect buyer as someone who’s been working with SQL Server for a year or two, and who’s facing a lot of challenges on the job around configurations they haven’t seen before. They might be tasked with building their first disaster recovery plan, not sure whether to choose log shipping or database mirroring, and they want to know what types of production issues they’ll face with each of those options. They can read this book’s High Availability section and feel like they’re having a conversation with a friend who’s been there and done that.

I’d also recommend this book to someone preparing to get their MCITP certifications in SQL Server. If you devour the material in this book, then you’re going to have the kind of skills and knowledge that it takes to get certified. If you find this book too intimidating or too technically detailed, then you’re probably not going to like the certification process either – and the cost of this book beats the cost of most full-blown MCITP training materials.

Buy SQL Server 2008 Administration in Action from Amazon

Brent Ozar

Brent specializes in performance tuning for SQL Server, VMware, and storage. He's one of the very few Microsoft Certified Masters of SQL Server, a published author, and a Microsoft MVP. He likes travel, Jeeps, Apple gear, jokes, and writing about himself in the third person. Read more and contact Brent.

More Posts - Website

Follow Me:

1 Comment - Leave a comment!

Dell PowerEdge 1650 Review

Written on March 7, 2009 by Brent Ozar in Computers

(Warning – blast from the past! This was originally published by HAL-PC’s print magazine. I’m copying it into a blog entry because I’m getting rid of my old review sections in my blog, and this was the only page still getting hits from 2002. It’s funny to read in retrospect, but regular readers can just mark this as read and go on with their merry lives.)

We’ve talked about how to evaluate servers for small businesses, and now let’s take a look at a server marketed to small businesses. The Dell PowerEdge 1650 is a low-end rack server, but still very powerful, and it exhibits a lot of the features we discussed for reliability. First, we’ll look at the advantages and disadvantages of rack-mount servers in general, and then we’ll dive into more detail on the 1650 itself.

Rack-Mounted Servers Versus Towers

Dell’s PowerEdge line consists of both rack-mount and tower-based systems. Rack-mount systems (like this 1650) are designed to fit into a 42” wide rack, a lot like the stereo gear you carried around that summer when you toured as a roadie for the Rolling Stones. Rack-mount servers are as tough as Keith Richards: they’re designed to be in operation around the clock and take the worst kind of abuse. But just like Richards, they have their ups and downs.

On the plus side, rack servers are small. They allow you to fit a lot more firepower in a smaller area. The Dell 1650 is a typical 1u rack server, meaning it fits into 1 unit of rack space, about 1.75” high. Think about a large pizza box, and you’ve got a pretty good idea of the Dell 1650’s size.

Even with that small size, Dell manages to cram in a lot of redundancy. In my last column, I talked about how important it was to have redundant features in your server so that if any one part fails, your server doesn’t grind to a halt. The PowerEdge 1650 has four fans, two built-in network cards, and optional redundant power supplies. The model I evaluated didn’t have the redundant power supplies, but we do take advantage of the redundant network cards, hooking each one up to a separate switch in our network. In the event that a network switch dies (it’s happened to us before), the servers don’t go down – they’re still accessible via the other network cable.

On the minus side, rack servers are – well, small. Since they’re only 1.75” tall, there’s a limited amount of space inside the case – so limited, in fact, that you can only have three hard drives and two PCI cards. While that may seem like a lot if you’ve never bought servers, three hard drives doesn’t allow for much expansion. If you’ve got plenty of space for your servers, then you should consider a tower unit like the similar PowerEdge 2500, which allows for 6 or more hard drives and as many PCI slots. Even with just three hard drives, you can still have a RAID (Redundant Array of Inexpensive Disks). We won’t explore RAID in this particular article.

Dell PowerEdge 1650 Specs and Features

Enough about rack-mounts – now, let’s talk about the 1650’s specific features. If you decide that a rack-mount machine isn’t for your business, you can still get the same features in a normal tower case in the PowerEdge 2500.

This machine is built for tomorrow’s needs. Servers are a hassle to replace: if you have to take your network down for a day while you put a new server into place, then it costs you real money. Instead, you want a server that can easily be upgraded without changing operating system settings, reinstalling programs, and generally disrupting your business.

The PowerEdge 1650 can use dual Pentium 3 processors running at 1.4 GHz and up to four gigabytes of error-correcting (ECC) memory. This particular example has dual 1.26GHz processors and just one gigabyte of memory: there’s no sense in buying more hardware than you need, but it’s good to know the server will be able to grow when we need more power.

Buying For Tomorrow

Another example of buying for tomorrow: the 1650 has dual onboard Intel 10/100/1000 network cards. This machine is only connected to a 10/100 switch, because gigabit Ethernet switches are so expensive, but when the switches get cheaper this machine will be ready. Increasing network speed will be as simple as plugging the server into a new switch, rather than hassling with installing new network cards.

The concept of buying-for-tomorrow extends beyond hardware capacity: think about software capacity. What happens when you want to upgrade to a newer version of Windows? Just as Keith Richards extends his life with blood infusions, you need to be able to get more lifetime out of your server by getting fresh software. Dell uses industry-standard components, like Intel network chips, so it’s very easy to upgrade to future operating systems. We’ve already tested this by installing the beta versions of Windows .Net Web Server Edition onto this machine, and it went flawlessly. Dell’s planning paid off. Part of this is due to the next point…

Integrated Motherboard with Lots of Features

In the 1650, everything is integrated onto the motherboard. In your typical home computer, you’ll find a video card, a network card, a sound card, and so on. With serious servers, everything is integrated onto a single board (the motherboard) to minimize configuration problems. You don’t have to worry about conflicts between cards, because everything was designed to work together.

As we ordered it, this 1650 doesn’t have a single plug-in card. Everything we need is all onboard, and we don’t ever anticipate needing to add a card to this system. That’s helpful because we can do a backup of this system’s hard drive, and then easily restore it at any time without worrying if someone’s changed the video card or network cards.

A lot of people put generic $20 video cards into servers. The logic seems to be: “Nobody’s going to sit in front of this server and use it all day, so why should I care about the video card?” In a word: drivers. You want an industry-standard card that won’t give you problems with each new Windows version and service pack. Using an industry-standard video card integrated onto the motherboard helps this cause and makes your upgrade process easier. If you save $50 on the video card, and then it takes you an extra three hours to get the Windows upgrade done right, did you really save any money?

Monitoring Your 1650 with Dell OpenManage

You can check up on your 1650 from anywhere, over the web. When you’ve got a rack full of servers, you don’t want to waste time looking at each server to make sure the CPU fans are working or that a hard drive hasn’t failed. You want to be alerted when bad things happen. Dell’s OpenManage software, included with all PowerEdge servers, handles this – and you can use it from any web browser on your network.

In the OpenManage web console, you can get all kinds of useful information about your server’s health. You can see exactly how fast each fan is spinning, including the fan in the power supply. Of course, you don’t want to keep surfing the web to make sure your fans are spinning and your drives aren’t failing, so you can also set up alerts to be sent via email, network broadcast, or by simply beeping the server’s speaker. You can even update your server’s bios, check how many memory slots are in use, run diagnostic tests on any component, and more – all from a web browser.

Most major server manufacturers have similar programs with varying levels of power. When you’re spending server-level dollars, you’ll want to see these management programs in action – ask for a demo from your salesperson.

The Bottom Line: It’s a Great Value

The bottom line: price. Dell’s machines are built-to-order, and with the wide range of options available for the 1650, you can end up with a price tag anywhere from $2,000 to over $10,000. While that may seem like a lot for a small business server, concentrate on the lower end of the spectrum. You want to buy a server that you can grow with, and maxing out the options doesn’t make sense for a small business server. You wouldn’t buy it with dual CPU’s and 4 gigabytes of ram right away: instead, start with a single CPU and 512 megs of ram, and grow the server with your needs.

Brent Ozar

More Posts - Website

Follow Me:

0 Comments - Leave a comment!

Book Review: Microsoft SQL Server 2008 Management and Administration

Written on February 13, 2009 by Brent Ozar in SQL Server, SQL Server Book Reviews, SQLServerPedia Syndication

Production database administrators have to know at least a little about a lot of things:

Microsoft SQL Server 2008 Management and Administration

How to install or upgrade SQL Servers
How to build clusters
How to plan for disaster recovery and high availability
How to do performance tuning
How to secure and protect databases

The production role revolves around management, not creation. Sure, they do need to know T-SQL and be able to debug problem code, but the majority of their day is making the trains run on time – not designing the seats inside the train cars.

Windows administrators who are forced into the SQL Server DBA role need this same type of information. They get handed a database server to manage, often with a database from a third party vendor like Citrix or Blackberry. They have to manage the server, make sure it performs as needed, and back it up safely – but they’ll never touch a line of T-SQL code that runs on the server.

Ross Mistry and Hilary Cotter’s book Microsoft SQL Server 2008 Management and Administration is a great companion for production DBAs and accidental DBAs. It covers this wide variety of topics in a good depth, and leaves topics like beginning T-SQL or how to write stored procedures out to other books.

No-Nonsense, Need-To-Know Approach

I liked this book right from the first chapter because I understand the target audience well. At Southern Wine, I worked in a Windows infrastructure team that also had several Windows administrators and an Exchange admin. These other administrators often had to install SQL Servers for various third party products, and they would ask questions like:

What’s the right version of SQL Server for my needs?
How should I configure memory settings?
How do I cluster SQL Server?

This book gives just enough explanation for the reader to make a decision – without droning on about minutiae. For example, during setup, when the user has to choose where to place the SQL Server data and log files, the book notes:

“Because I/O to log files is sequential and I/O to database files is random, for increased performance, it is a best practice to place log files on a separate disk from database files.”

When a production DBA or a Windows administrator reads that sentence, it will click immediately, and they’ll understand what’s going on. Throughout the book, I kept finding myself nodding and saying, “Yep, I learned that the hard way,” or “Ah, I always wondered about that.”

Just Enough Programming Where It Matters

The book doesn’t focus on T-SQL programming, but where programming is necessary to get the job done, it demonstrates concepts and code clearly. For example, in the “Securing the Data Storage” chapter, there’s an excellent example of how to compromise salary data by copying encrypted data. The DBA doesn’t have to be skilled with T-SQL to understand the ramifications, but knowing these concepts helps them have a better discussion around security issues.

Chapters You Might Not Expect: SSIS, PowerShell, Hyper-V Virtualization

In another sign that this book is targeted at production DBAs, not T-SQL developer DBAs, this book includes a chapter on SQL Server Integration Services package development. SSIS comes in handy for production DBAs because they have to move data from one server to the next, and because maintenance plans are designed in SSIS. As someone who learned DTS the hard way – by force – I like having an SSIS chapter that’s available when I have a need to shuffle data around.

The PowerShell chapter starts with the raw basics and doesn’t assume the DBA knows anything about PowerShell. A production DBA or Windows admin can pick up this book and get what they need to know in order to start using PowerShell for server management. I appreciate this because most of the DBAs I talk to aren’t focusing on learning PowerShell yet, but having this chapter included will give them a foot up – and might just get them to try it out. (Heck, I’m thinking about trying it out just because it’s in the book, and that says a lot – I’m Mr. Anti-PowerShell.)

Another pleasant surprise was the chapter on virtualization with Microsoft Hyper-V. When I write on SQL Server topics these days, I try to stop and think, “If this server is virtual, what changes? What factors do I need to think about and what advice do I need to change?” This chapter focuses on the basic implementation of Hyper-V as it relates to servers in general, but not necessarily specific to Microsoft SQL Servers. The snapshot backup section talks about how to take snapshot backups, but not how it relates to a SQL Server disaster recovery strategy. If you plan to implement SQL Server in production on Hyper-V, this chapter will get you started, but I would advise learning it in more detail before proceeding. I only mention this because the rest of the book is so thorough: I wouldn’t hesitate to tell a Windows admin, “Pick up this book and you’ll have all you need to know in order to build production servers.” I would not be as comfortable giving them that advice about the Hyper-V chapter. The chapter’s still a nice bonus though, especially given how new Hyper-V is in the market.

In Summary: Great Book for Production DBAs and Accidental DBAs

I’m really glad Todd Robinson (DevSQL on Twitter) sent me a copy of this book to review, because my local bookstore has an astoundingly bad selection of SQL Server 2008 books. I highly recommend this book for production SQL Server database administrators and “accidental” DBAs, Windows admins who’ve been tasked with managing SQL Server. This book gives you the information you need without burdening you with unneccessary details, and it’s laced with practical tips and real-world good ideas.

You can buy Microsoft SQL Server 2008 Management and Administration from Amazon for around $30, and a Kindle version is available for around $20.

Brent Ozar

More Posts - Website

Follow Me:

1 Comment - Leave a comment!

Are blades right for small businesses?

Written on December 3, 2008 by Brent Ozar in Computers

After reading my HP c7000 Blade Chassis review, a reader contacted me with a question:

“I do computer consulting and web hosting, and I recently bought a blade chassis. I was going to use it for web hosting at a colo datacenter, but I’m debating whether to use it or keep using 1u pizza box servers. Any thoughts?”

I like blades because they solve some business problems as well as IT problems.

Blades can require less power and cooling. If you have fifty pizza box servers with redundant power supplies versus fifty blades, you’re probably going to have lower electricity bills with the blades. Notice that I didn’t say a rack full of blades versus a rack full of 1u servers: you can pack more blades in a rack, which means the rack full of blades may require MORE power and cooling than the rack full of 1u boxes. At the same time, though, the rack full of blades should have more computing power. (Yes, there’s exceptions to this – let’s just talk as a general rule first.)

Blades can require less cabling. A rack full of 1u servers is a cabling nightmare. However, if you buy passthrough network ports instead of real switches in order to save money, you won’t be better off in the cabling department.

Blades can be easier to manage. If you have an army of hundreds of blades, they’re really easy to manage. If you just have a few, then some of the concepts are going to be difficult to implement. Blades are fantastic when you’re booting from SAN or when you have lots of images to boot from, but if your server installation method involves using a CD and watching progress on a monitor, you’re not going to be quite as happy with blades. They’re great once you get used to ‘em – I would loooove to have an HP c3000 chassis at home for my work lab – but one-person IT shops don’t usually like them in the beginning.

Blades are really easy to move around if you have more than one chassis. At Southern Wine, we had lots of ‘em. We could grab a blade in Miami, ship it to our lights-out disaster recovery datacenter, and the remote tech could slide it into the chassis without any input from us. We’d get an email that the blade had been inserted, and we could start managing it remotely with hardly any configuration. Total joy to work with.

Here’s the downside: for a small business, none of these issues are problems. Instead, small businesses have to worry about two problems with blades:

Blades aren’t as easy to move around if you just have one chassis. If I’m a small business with ten blades in a colo datacenter, and I suddenly want to move some of those to my local office, or if I want to play around with them at home to set them up before putting them in the colo, I can’t just plug ‘em in at home or in the office. I have to put them in a blade chassis, and those cost money. Pizza boxes don’t have that issue: you can slap a pizza box server on a desk, plug it into the wall and to a monitor, and you’re off and running.

When I discussed this issue with the reader, he decided he’d be better off sticking with the 1u servers he knew so well, and that led us to another blade drawback:

Blades have poor resale values. Blades are bought by big companies. Big companies like to buy new equipment with warranties. This is great news if you want to buy used blade gear, because you can pick it up all day long on Ebay for a fraction of what it costs new. This is really bad news if you’re a small business and you need to change strategy. If you want to sell some of those blades in order to get standalone boxes for a remote office or to use at home, well, you’re going to take a bath.

Brent Ozar

More Posts - Website

Follow Me:

4 Comments - Leave a comment!

Welcome to the Social…Hell! (My Zune experience)

Written on October 25, 2008 by Brent Ozar in Computers

I bought a Microsoft Zune 8 to test the new SQLServerPedia video podcasts and the user experience was so unpolished, so unprofessional that I just had to bang out a blog about it. Looking at the iPod Nano next to the Zune 8, I could never understand why somebody would buy the Zune 8. Now having used both of them, it makes even less sense.

Forget the bulky size of the device. Forget the user interface. Check out the software. Brand new Zune fresh out of the box, brand new install of the Zune software, connect them together and:

Kablammo. Okay, okay, no problem, I’ll reboot. I know how this stuff works.

After a reboot and some black magic, I got it installed. Great, now I’ll log in. The window tells me to put in my user name and my password, so I do that, and:

Wait – the error says you want my email address, not the user name I just set up. Fix your login screen. And hey, while you’re at it, can you get rid of all the empty space across the bottom? It looks like I bought the stripper version with no options, and I’m missing a bunch of option boxes or something. Or maybe you’re being “artsy”. Whatever.

Poor decisions on screen space abound throughout the program. Check out this screenshot:

Big huge window, tons of white space, and they choose to cram the message into a tiny messagebox in the middle of the screen and put a scroll bar on it. Why do I need to scroll through a message when you have all this white space all over the screen? You think I want to concentrate on the white space? Is the message that bad that you don’t want me to see it?

Now let’s test those podcasts. I set up the Zune one-click subscription link (rather spiffy), subscribe to the podcasts and watch the downloads start. Nice download progress bars – or are they?

Both progress bars are gradients, and they don’t change as the download changes? The 27% bar and the 10% bar look exactly the same. I’m not sure what you call the opposite of a progress bar, but that’s what this is.

I was going to keep this thing after I tested our podcasts because I really wanted to give it a shot, but every time I interact with it, it makes my blood pressure rise. I can EXPENSE this thing as a part of my job, and I STILL won’t keep it – it’s going back to the store tomorrow.

During the several times I had to reboot to get it to work, I ran across an absurdly in-depth review of the Zune 8 versus the iPod Nano. Read that, and you’ll get a good idea of what a train wreck this thing is.

Brent Ozar

More Posts - Website

Follow Me:

1 Comment - Leave a comment!

Recommended Books for SQL Server DBAs

Written on August 14, 2008 by Brent Ozar in SQL Server

There’s a ton of SQL Server books out there to help get you started on the road to becoming a database administrator. I’m going to start at the start of your career, and go forward.

Category

Beginner Books

Advanced Books

Performance Tuner Books

Production Database Administration:
Backups, restores, installing SQL, clustering, security.

SQL 2008:
SQL Server 2008 Administration in ActionSQL 2005:
Professional SQL 2005 Administration

SQL 2008:
SQL Server 2008 Management and Administration

SQL 2008:
SQL Server 2008 Internals and Troubleshooting(I coauthored this)SQL 2005:
Inside SQL 2005: The Storage Engine and
Professional SQL Server 2005 Performance Tuning

T-SQL Development:
Stored procedures, queries, views, triggers.

SQL 2008:
SQL Server 2008 T-SQL Fundamentals

SQL 2008:
Inside SQL 2008 T-SQL QueryingSQL 2005:
Inside SQL 2005 T-SQL Querying

SQL Server, Oracle, and MySQL:
SQL in a Nutshell

SQL 2008:
SQL Server 2008 Query Performance Tuning DistilledSQL 2005:
Same book as 2008. Almost everything applies.

My Favorite Non-SQL Server Books

These books aren’t specific to DBAs, but are things I’ve found really helpful in my career:

Getting Things Done

Getting Things Done by David Allen

Do you get nervous at the thought of opening your email in-box because there’s so much piled up, and you don’t know where to begin? Do you struggle with to-do lists and project management software? Tired of struggling to keep your dayplanner up-to-date? Feel like you’re never going to catch up? Jealous of those folks on Twitter who keep shouting “Inbox Zero!”?

David Allen’s book Getting Things Done has been the answer for me and for a few of the folks I work with. It’s a simple, no-nonsense approach to managing daily tasks. Knowledge workers these days have an unending stream of incoming “stuff”, and the GTD philosophy is about rapidly handling as much as you can, as fast as you can, and feeling absolutely comfortable knowing that you can’t handle everything.

I showed my current manager into the GTD philosophy, and he caught on right away. He went from hundreds of emails in his in-box down to less than half a dozen in a couple of weeks. He responds faster to requests, and clearly feels confident in managing his day-to-day inflow of tasks.

You can buy the paperback on Amazon, and there’s also a Kindle version.

Time Management for Systems Administrators by Thomas Limoncelli

If you’re not quite ready for the GTD strategy, check out this lighter version of the philosophy that’s tailored specifically for IT workers. It’s a much smaller book, and breaks down just what you need to know in order to get your work done faster. One of my former managers gave this out as a Christmas present a few years ago to all of his staff after I converted him to GTD.

You can buy the paperback on Amazon, and there’s also a Kindle version.

The Whuffie Factor by Tara Hunt

Whuffie is slang for social capital: your reputation, your credibility, your personal bankability. It’s not as simple as the number of followers you have on Twitter, because that doesn’t necessarily indicate your trustworthiness – there’s plenty of spammers who’ve mastered the art of the followback. It’s not as simple as the number of posts you’ve made on a forum somewhere, because that just indicates you’re really good at clicking the Submit button.

This concept isn’t just for marketing people – it matters to IT professionals. As we go through more and more layoffs, the concept of a lifelong career at the same company is nearly gone. You need to find out how to market yourself to find a job before it’s too late – and when you’ve been laid off, it’s already too late.

You can read my review of the Whuffie Factor, buy the paperback on Amazon, and there’s also a Kindle version.

Brent Ozar

More Posts - Website

Follow Me:

78 Comments - Leave a comment!

Microsoft DPM 2007 review

Written on August 7, 2008 by Brent Ozar in SQL Server

I spent some time last week digging into Microsoft Data Protection Manager 2007, Microsoft’s solution for SQL Server backups, and I’m going to share some of my findings here with you, dear reader.

“But You Work For Quest Software! You can’t write a Microsoft DPM review!”

Yeah, disclaimer time – I work for the people who make Quest LiteSpeed, a big player in the SQL Server backup market. What you’re about to read is not sanctioned by Quest, is not the opinion of Quest, has not been edited by Quest, etc. This is just Brent talking to DBAs out there.

This review is not going to be the pros versus cons. This review is only going to cover the things I uncovered that surprised me – things I didn’t expect to find, and things that I would have really wanted to know as a DBA before I bought the product. There are plenty of places where you can find gushing, glowing reviews of DPM that say things like DPM is the “ultimate solution for protecting SQL Server data.” You will not find that language here.

I’m not saying DPM sucks, and I’m not saying you shouldn’t buy it. DPM struck me as a really cool solution for its target audience, but DBAs that fall outside that target audience need to understand some of the limitations.

Microsoft DPM installation involves agents and reboots.

Software companies, Quest included, get in trouble when we use agents because there’s some agents out there that slow servers down. Some DBAs have big problems with installing additional agents on their servers, and those DBAs are going to have a problem with the DPM agent.

The DPM agent relies on the Volume Shadow Copy Service (VSS), and before you even get started with DPM, you have to apply Microsoft hotfix #940349 to all DPM-protected servers. That hotfix requires a reboot, and only then can you install the DPM agent – which also requires a reboot.

Further DPM upgrades may also require a reboot. In the case of DPM 2007 and the updated Feature Pack that came out afterwards to address some issues, the agent updates required reboots for me. The release notes aren’t clear about whether or not a reboot is required for the agents, but for me, it was. Your mileage may vary.

As a DBA, this bothers me because scheduling reboots is such a pain. You can’t schedule the DPM agent update & deployment ahead of time – you have to reboot to get it to take effect – so it means the DBA is sitting at a console on a Saturday night, pushing out agents and doing reboots. This is a tough sell for me because other conventional backup software doesn’t require reboots. I’m thinking back to when I used Idera SQLsafe or Veritas NetBackup, for example, and I don’t think those required reboots for agent updates.

Microsoft DPM backup jobs don’t show up in SQL Server Agent.

Backup jobs are controlled by the DPM service, not by SQL Server Agent. This isn’t good or bad, it’s just different. It means that DBAs can’t look at SQL Server Agent to see when backups are running, how long they’re taking, whether they were successful, or when the most recent backup was. Instead, to get any information about backups, the DBA has to open Microsoft DPM.

I love having backups controlled inside Agent because if someone complains that the server is running slow, I like going into Agent to see what jobs are currently running. SP_Who2 is great as well, but I like Agent’s status because I can tell what regularly scheduled jobs are going on. DPM’s jobs aren’t there, though, so I have to resort to sp_who2 and poking around.

On the other hand, I gotta tell you that DPM’s management console interface is pretty nice for Wintel admins. It does a great job of showing what jobs are currently running across your enterprise, and the restore process is really intuitive. Shops that have a few Wintel admins, no DBA, and a few SQL Servers to back up will be comfortable working with the DPM user interface.

Microsoft DPM can’t back up faster than once every 15 minutes.

Vipul’s DPM article says “Transaction logs are continuously synchronized to the DPM 2007 server, as often as every 15 minutes.”

That is not “continuously”.

If you manage financial data, sales data, healthcare data, security & auditing data, etc, and you lose 15 minutes of data, you can lose your job.

I’ll give you another example – before application upgrades, server firmware upgrades or SQL Server patches, I like to take a quick t-log backup before I make changes. I hop into SQL Server Agent, right-click on the t-log backup job, start it, and wait for it to finish. It’s an easy and quick insurance policy, but you can’t do that with DPM.

DPM is sometimes called Continuous Data Protection (CDP), but that only works if you can access the server’s live log file. The theory is that if you have a crash between t-log backups, you restore all of the t-log backups, and then apply the live transactions from the SQL Server log file (LDF).

But wait – didn’t we have a crash?

How do we access the SQL Server’s LDF files if the server crashed?

If the LDF files are still available, then the SQL Server is still available. So you only have CDP if there’s data corruption in the MDF file, or if there’s some kind of problem that stops SQL Server but still lets the log files be read and copied somewhere else. I’m not saying that never happens, but it’s pretty rare. Usually, when I have a crash, I can’t even get the server to boot, like I’ve had a serious hardware issue or a Windows issue. In those events, DPM isn’t continuous data protection, and I lost the data since the last 15-minute backup.

That isn’t a showstopper problem for most shops, but it’s just something to be aware of.

Microsoft DPM backups can only be written to DPM servers.

DPM is a service-based backup: the agent on your SQL Server communicates directly with the DPM Server, and the backups go straight to the DPM server. Makes sense, right?

Now what happens when you need to do a bunch of backups at once, like if your servers have similar maintenance windows? Suddenly the DPM server becomes a bottleneck, because it’s only got so much network throughput and IO speed. With backup software like LiteSpeed, you can put your backups anywhere you want. You can write to different file servers, you can write to CIFS appliances like NetApp or EMC SAN controllers, you can write to local disk, you can write to DR servers, etc.

And now what happens if your DPM server goes offline? The sad reality is that no server is ever 100% reliable. With LiteSpeed, if your file share server goes offline, you can point your backups somewhere else. With DPM, when your DPM server is down, you’re unprotected – no backups, and even scarier for me, no restores.

Ideally, DPM would use a farm-style architecture like Veritas NetBackup. With NetBackup, you can put backup servers in pools, and when you set up backups, you can point backups at entire pools of servers. That way NetBackup can automatically load-balance the backup activity across multiple media servers.

You can’t see DPM backups in Windows Explorer.

Call me old school, but I like to go into Windows Explorer and see that my backup files exist. That’s not possible with DPM – it uses raw disk space to create storage pool partitions, and you can’t access these. You can’t back the backups up to tape with your enterprise backup software like TSM or NetBackup or Backup Exec.

This isn’t necessarily better or worse – DPM is doing you a favor in the sense that it’s masking a lot of complexity from you. But for those of us who are used to poking around behind the scenes, running verify-only backups, or just plain looking at file datestamps and sizes, that’s no longer an option.

DPM’s Active Directory reliance means problems for DMZ servers, workgroups.

Yes, it’s bad practice, but I had to manage SQL Servers in the DMZ, in workgroups, and in other domains. DPM relies on Active Directory, so setting up these servers is more complex than typical backup software setup.

I didn’t build out a multi-domain lab, but if you have multiple domains, test the deployment of this. I’d be curious to hear if any of my readers (that’s right, EITHER of you) have tried this.

DPM doesn’t allow log shipping.

DPM backup files aren’t traditional backup files per se. If you want to do log shipping, you have to use something else – either native SQL Server backup files or a third party product like LiteSpeed.

That means shops with log shipping will have to manage their backups under two systems: both under DPM, and under their log shipping. One of the selling points of DPM is that it reduces complexity, but if you use log shipping, you need to be aware that this is going to get tricky.

“My sources are unreliable, but their information is fascinating.” – Ashleigh Brilliant

I work for a company that in some ways competes with Microsoft DPM 2007, so take my info with a grain of salt.

If I had to choose a backup method for your database servers, and if I was seriously considering Microsoft DPM, I would spend two days evaluating traditional third-party backup products like Quest LiteSpeed, Red Gate SQL Backup, and Idera SQLsafe. (Yep, that’s right, I’m linking to my competitors, and I’d also like to give a shout-out to Red Gate SQL Backup for winning SQL Magazine’s Gold Award this year. Enjoy it while it lasts, fellas, because I’m gonna wipe the floor with you next year. (Ha! I kid. (Not really.))) These kinds of products basically operate the same way, but with different featuresets and user interfaces. You can get a really good feel for any of these products within a few hours.

Then, I would spend three very solid days evaluating Microsoft DPM. DPM is seriously, significantly different than conventional SQL backup software, and it’s going to take you a few days to dig deep enough into it to discover the ways that it’s different. (Remember, it installs agents that require multiple reboots, so you can’t test this on your normal SQL boxes.)

Data Protection Manager is not necessarily better or worse, it’s just dramatically different from the SQL Server backups that you’ve used in the past. When you evaluate DPM, you need to start with a fresh, open mind and don’t take anything for granted. Build yourself a lab and do several backups and restores to get a feel for what the process is like. Make a list of all of your servers and how they get backed up, and make sure DPM can fit those needs – especially DMZ servers, mission-critical servers and log shipped servers.

DPM has some awesome features, like restoring Windows system state info and detecting which blocks got changed instead of doing a full backup, but in your excitement about those features, make sure you don’t miss things that you just assume it’s going to handle.

If You Liked This Review…

Check out my Microsoft SQL Server Best Practices for Backup article.

Brent Ozar

More Posts - Website

Follow Me:

29 Comments - Leave a comment!

The Wine Trials: a wine book for donut lovers

Written on July 18, 2008 by Brent Ozar in Personal

Last night, the author & editor of The Wine Trials held a release party at the Caroline Collective, the Houston coworking office where I lay my weary laptop. Robin Goldstein and Alexis Herschkowitsch talked vino, signed books and raised glasses. I liked them, and I liked the book, and I’ll tell ya why.

I’m just a regular guy. When I go to a restaurant or a wine shop, I don’t want to dazzle anybody with a deep knowledge of wine. I just want to spend a reasonable amount of money (say, two or three glasses should cost less than an entree) and drink something that tastes as good as what I’m eating.

I don’t have a very sophisticated palate (mmm, donuts) and I gotta think there are some wines that basically taste good to everybody – like, well, donuts. You don’t need a sophisticated palate to like donuts – you just like ‘em. Granted, there are a few wackos who don’t like donuts, and there are a few of us who have graduated to beignets, but walk into any office meeting in America with a box of donuts and you’ll win friends and influence people.

So how do we find wines that are the equivalent of donuts – beverages with a wide, almost universal appeal and reasonable donut-style pricetags? The Wine Trials took the approach of a large quantity of blind tastings: hundreds of people sampling wine from brown paper bags. (Sounds a lot like downtown Houston, only with feedback forms for each wine.) Their tastings covered wines in all price ranges, but they focused the book on the top 100 wines under $15.

My test for any review book is to open it up and read their opinions about something I personally have tried and know well. Erika and I are on a champagne kick at the moment, and Editor’s Pick in the book is Friexenet Cordon Negro Brut. Sold – that’s our second favorite budget bubbly, and I can forgive them for not including our favorite (Francois Montand) because it’s nearly impossible to find.

You can buy The Wine Trials from Amazon.

In related news, today is Champagne Friday at Caroline, and in honor of Robin & Alexis, we’ll be serving Friexenet. If you’re in the Houston downtown or museum district area, come join us for a glass.

Brent Ozar

More Posts - Website

Follow Me:

0 Comments - Leave a comment!

HP Virtual Connect Review

Written on March 9, 2008 by Brent Ozar in Computers

We originally rolled out our HP C-Class blade infrastructure with Cisco network & Brocade SAN switches, and I’ve blogged about some of the challenges of lots of blade switches. Today, I’m going to talk about how the HP Virtual Connect equipment solved a lot of those problems for us and gave us a more flexible, easier to configure blade system.

When blades first started rolling out, we had two ways of connecting them to networks and storage:

Switches – just like regular switches, except they slide into the back of the blade chassis. They have internal wiring to each blade, and a few network ports in the back to connect to the rest of the datacenter’s switches. These ports can be used as uplinks, or other devices can be plugged in as well, like iSCSI storage. This solution is hard to maintain because it takes specialized Cisco knowledge (or whoever’s switches are used) and they’re not typically integrated with the blade chassis management.
Pass-throughs – a device in the back of the blade chassis that just had one network port for every single blade with a network connection. In the case of a fully populated C-Class chassis, that’s 32 network ports just for the 2 onboard NICs in each server, let alone any additional mezzanine NICs. This solution is much cheaper in terms of blade equipment, but it’s a cabling nightmare, and every time the admin needs to change a network port, they have to walk into the datacenter and manage the cabling.

HP’s Virtual Connect offers a new hybrid solution that takes the best of both, and offers some new abilities that aren’t available with either of the previous architectures.

Virtual Connect is a Smarter Passthrough

In a nutshell, the Virtual Connect module dynamically passes any network port’s traffic through to another network port. It’s a smarter passthrough that can aggregate traffic from multiple servers into a single uplink or multiple uplinks.

VMware administrators will see Virtual Connect management as something extremely similar to the network management built into VMware. Think of the blade chassis as being the VMware host: a couple of network cards can be configured with trunking to support multiple guests, each with their own individual VLANs. The Virtual Connect gear acts just like a VMware host would, adding the appropriate VLAN tags to traffic as it exits the VirtualConnect module and goes up to the core network switches.

Virtual Connect can also handle VMware servers inside the chassis, passing even VLAN-trunked traffic through to the servers. Be aware that this is does require some deeper network knowledge, but shops running VMware hosts can easily handle this. I’ve done VMware administration part-time at our shop for the last couple of years, and I was easily able to configure Virtual Connect for VMware hosts.

Here are a few links I found really helpful with Virtual Connect and VMware:

VMware ESX Server networking with HP Virtual Connect by Scott Lowe
HP VirtualConnect Clarification by Scott Lowe
And yes, Scott Lowe’s blog in general

When two Virtual Connect modules are plugged side-by-side into the same blade chassis, they have a built-in hard-wired 10gb crossconnect link between them. This allows for some amazing failover configurations. We wired both modules up to the same datacenter core switch, and set up a single virtual uplink port across both Virtual Connect Modules. The Virtual Connect will automatically push all of the traffic through one side by default, but if that uplink fails, the traffic will automatically switch over to the other module’s uplink – completely seamlessly to the blade server. That’s something we couldn’t even do with our Cisco gear.

Virtual Connect beats regular passthroughs in another way: VC dramatically reduces the amount of cabling required. Set up the Virtual Connect uplinks once with just one or two uplink cables per switch, and only add additional uplinks when performance requires it. Instead of two uplink cables per server with traditional passthrough solutions, Virtual Connect requires as little as two cables per sixteen servers! Of course, most shops will opt for at least a couple of additional cables for redundancy and performance, but it’s an option instead of a 32-cable requirement.

Virtual Connect is a Simpler Switch

Like the rest of our Wintel server management team, I don’t know anything about managing Cisco switches, and I’m not about to learn at this stage in my life. Therefore, I was exceedingly happy to open the Virtual Connect page and see this:

The Virtual Connect web user interface looks and feels exactly like the rest of HP’s management tools like System Insight Manager, the iLO2, and the C7000′s Onboard Administrator. Server managers will immediately feel comfortable with the wizard-based UI that can be used without any training. If you’ve managed HP servers, you can manage HP Virtual Connect.

That’s not to say that users shouldn’t read the documentation carefully when deciding the initial infrastructure: like switches, the Virtual Connect modules can do some powerful stuff, but it takes planning and forethought.

Faster Rollouts

Most of our blade network connections consist of a few simple profiles:

Basic server – two network cards both on the server subnet, using failover between the two
Clustered server – the basic server, plus two network cards on a heartbeat subnet
iSCSI server – the basic server, plus two network cards on an iSCSI subnet
VMware server – a specialized configuration with traffic from multiple VLANs

We roll out these same types of servers over and over, but with conventional switchgear, every server rollout was like reinventing the wheel. We had to double-check every network port, and human error sometimes delayed us by hours or days.

Virtual Connect brings a “Profile” concept to switchgear: we can set up these basic profiles, and then duplicate them with a few mouse clicks. A junior sysadmin rolling out a new VMware blade doesn’t need to understand the complexities of trunked VLAN traffic, a dedicated VMotion nic, and so on – they just use the custom VMware profile we set up ahead of time, and all of the network ports are configured according to our standards.

Since the Virtual Connect infrastructure is managed by the same staff who do blade implementations and rollouts, there’s no delays waiting for the network team, no failures in communication, and no finger-pointing when configurations go wrong. Blade rollouts are handled entirely by one team start to finish.

Easier Recovery from Server Hardware Failures

We haven’t implemented boot-from-SAN yet, but with the VC infrastructure, I can finally see a reason to boot VMware and Windows servers from the SAN. Virtual Connect manages the MAC addresses of each network card and the WWN addresses of each HBA, remapping them to its own internal database (or the company’s chosen list).

In the event of a blade hardware failure, like a motherboard, the system administrator can simply remap that blade’s network profile to another blade and start it up. The new blade takes over the exact same MAC addresses and WWN’s of the failed blade, and can therefore immediately boot from SAN using the failed blade’s storage and network connections! That gives administrators much more time to troubleshoot the hardware of the failed blade.

With this kind of flexibility, we can justify having a high-performance blade as a standby, ready to recover from any blade’s hardware failure. The cost on this is relatively low, since it acts as a standby for all of the blades in any chassis.

Easier Hardware Upgrades

Along the lines of hardware failure recovery, VC also allows for easier hardware upgrades & swaps. If the company goes with a standard blade hardware rollout (like all Intel 2-socket blades, or all AMD 2-socket blades), this means that hardware upgrades can be done in a single reboot:

Ahead of time, build a new blade with the desired new configuration (more or faster CPUs, more memory, etc). Burn it in and do load testing in a leisurely manner, making sure the hardware is good.
Shut down the old blade.
Using Virtual Connect, copy the old blade’s profile over to the new one. Takes a matter of seconds, and can be done remotely.
Boot up the new blade.

Taking this concept to an extreme, one could even use this approach for firmware upgrades. Upgrade a standby blade to the latest firmware, burn it in to make sure it works, and then do the hardware swap. (I wish I would have done this recently – I had a SQL blade firmware go wrong, but thankfully it was in a cluster.)

Simple Packet Sniffing Built In

When we run into difficult-to-solve network issues, sometimes we rely on our network team to capture packets going to & from a machine in question. I was pleasantly surprised to find that the Virtual Connect ethernet modules have the ability to mirror a network port’s traffic to any other network port. We can set up a packet sniffer on a blade, then use that blade as a diagnostic station when another blade is having network-related problems. For even more flexibility, we can take a laptop into the datacenter, plug it into one of the Virtual Connect’s external ports, and set that port up as the mirror.

Is this something the Cisco switchgear can do? Absolutely, but it’s not something that a Wintel server administrator can do with Cisco switches. I would never dream of trying to set that up on a Cisco, but with the HP, it only takes me a few mouse clicks in a web browser.

The Drawbacks of Virtual Connect

HP’s question-and-answer page about Virtual Connect points to one political challenge: the network team may not like bringing a new network technology into the datacenter. When given the option between buying their standard switches versus the new Virtual Connect switchgear, they’re probably going to prefer the former. For me, the important message was the ease of configuration, and getting everyone to see it as an extension of the blade system’s capabilities instead of an extension to the core network switch’s capabilities. Virtual Connect is a big piece of what makes blades faster and easier to roll out than conventional services. It’s a part of a larger picture, part of a new way to implement server infrastructures.

The second challenge is that to see the real benefit, organizations need to have Virtual Connect modules in every blade chassis. That way, administrators can transplant profiles and servers from one chassis to another, giving the best flexibility. To do that, chassis buyers need to take the first leap and buy Virtual Connect modules in their first blade chassis. Otherwise, they probably won’t go back and retrofit each pre-existing chassis with the Virtual Connect modules, especially since they’re more expensive than the traditional Cisco switches.

Finally, yes, the Virtual Connect modules are somewhat more expensive than the Cisco blade switches. It’s odd for me to think of something more expensive than Cisco, but having worked with both the HP Virtual Connect modules and Cisco switches, I can completely understand why they’re worth the additional price.

For me, the return on investment is clearly there: blades are all about faster rollouts, a more flexible infrastructure, and higher uptime. The HP Virtual Connect system delivers on all three of those goals, and I would recommend it for any shop building an HP blade infrastructure.

Want to Read More About My HP Blade Experiences?

Here’s a couple more related posts:

HP C-Class Blade Chassis Review Part 1 – about the chassis and blades
HP C-Class Blade Interconnects Review – about the Cisco and Brocade switches

Brent Ozar

More Posts - Website

Follow Me:

18 Comments - Leave a comment!

HP C-Class Blade Chassis Review Part 2: The Cisco/Brocade Interconnect Switches

Written on February 27, 2008 by Brent Ozar in SQL Server

In my last article about the C-Class chassis, I talked a little about the interconnect switches, and today I’m going to dive deeper.

As with most full-factor servers these days, each single-height HP blade like the BL460c includes an onboard dual-port network card. The difference between standalone and blade servers starts here: thoe two ports connect to two different interconnect bays (bays 1 & 2). They are hard-wired to these bays, each of which must contain a network switch. With standalone servers, a network admin can cable both of the server’s network cards to the same switch (HP, Cisco, etc), possibly utilizing empty ports on an existing switch. With a blade infrastructure, however, the admins need to buy at least a pair of switches for each blade enclosure.

We use two Cisco switches in those interconnect bays, each of which route to a different core Cisco switch. We tie the whole thing together by using the free HP network teaming software included with the blades, which means either of the interconnect bay switches can go down without taking down the blade’s networking. This does have weaknesses, but I’ll talk about that in an upcoming article about the HP Virtual Connect infrastructure.

A blade cannot live by two ports alone, so the BL460c includes 2 mezzanine card bays. The two mezzanine bays are HP’s version of an internal PCI Express slot designed for the tiny blade form factor, and they accommodate a variety of mezzanine cards including dual-port and quad-port network cards, dual-port SAN HBAs, and even Infiniband. This makes even the small BL460c well-suited for a variety of low to mid-range database server duties, especially for iSCSI shops. At our shop, some of the database server setups include:

Standalone high-performance OLTP server – one mezzanine bay holds a SAN HBA for storage, the other bay is empty
Clustered high-performance OLTP server – one bay has a SAN HBA, and the other bay has a dual-port network card
Standalone iSCSI OLTP server – one bay has a multipurpose iSCSI network card

The more connectivity a blade needs, the more switchgear needs to be involved. A typical C7000 chassis configuration might look like this:

Interconnect bay #1: a Cisco 3020 network switch
Interconnect bay #2: a Cisco 3020 network switch (for redundancy)
Interconnect bay #3: a Brocade SAN switch
Interconnect bay #4: a Brocade SAN switch (for redundancy)
Interconnect bay #5: a Cisco 3020 network switch (for 4-port NICs, especially for VMware)
Interconnect bay #6: a Cisco 3020 network switch (for redundancy on the 4-port NICs)

The Problem with Lots of Switches

Having six additional switches for every 16 servers (or even less servers, depending on whether the shop uses full-height blades) presents some problems.

To me, the beauty of blades is their reduced complexity: it’s all about making deployments easier, more predictable, and faster. Adding more switchgear doesn’t eliminate that simplicity, but it doesn’t help the case. I still have to put in a ticket for our networking staff to set up the Cisco switches, and I can’t double-check their work. The only way I find out that the setup wasn’t right is when I put in the new blade and it can’t communicate on all of its network cards. I don’t have to put in a ticket for the SAN admin because – well, because it’s me – but the other Windows admins have to wait for me to configure their SAN connections. In all, this can add days of lag time for a new blade setup, and that takes the shine off the simplicity of blades.

This is made more frustrating by the fact that most of our blade configurations come from just a couple of types: VMware hosts with specific VLAN, iSCSI and SAN needs, SQL Servers with SAN needs, and plain vanilla servers with one subnet. This should be a cookie-cutter setup job, but because the setup is done by multiple teams, there’s lag times, misunderstandings and finger-pointing when something goes wrong.

The fact that there’s a growing army of switches makes the initial configuration that much more difficult: we have to be extremely explicit with the network staff. Where we could easily just specify Core Switch A or Core Switch B before, now we have to specify which blade chassis we’re working with, which bay the switch is in, and so forth. Plus, when we hire new network administrators, they’re not always familiar with blade switches, so we have to walk them through the datacenter to explain how the different switches uplink to the core switches.

More switches also mean more firmware administrative headaches. These are another six switches that we have to keep on a synchronized versions of firmware. For example, we recently ordered a new chassis with Brocade switches, and the new switches arrived with a newer version of firmware. Thankfully we caught that before we plugged it into our infrastructure, because that firmware version was not compatible with other switch firmware versions in our fabric.

Another problem with this sudden growth of switches is that some management software is licensed by the switch port, regardless of whether that switch port is actively in use. We license our SAN path management software by the switch port, and the instant we plug in another pair of Brocades, we have to license that software for the additional switch ports. In some of our C7000s, we only have half of the servers connected to the SAN – meaning we’re paying licensing for more switch ports than we’d use.

The Limits of 2 Mezzanine Cards with Conventional Switches

The two mezzanine card slots are the BL460c’s first weakness as a database server: it can’t get seriously high throughput with conventional switches.

Most midrange fiber channel SANs don’t have true multipathing for their arrays. Each LUN (drive letter) is sent through a single 4gb HBA until that HBA path fails over, and then it switches to the other HBA. For SQL Servers, especially data warehouses, this presents a bandwidth problem.

We did a Microsoft Technology Center lab for our data warehouse in the winter of 2007, and one of the findings was that we were hitting a SAN throughput bottleneck. We were using two 4gb HBAs with IBM’s RDAC failover multipathing, which does not truly load balance between HBAs. The recommendation was to switch to at least 4 HBAs – something we couldn’t do with the BL460c blades. Granted, we weren’t running a data warehouse on a BL460c, but my point is that it shouldn’t be done for performance reasons.

The same thing holds true with iSCSI, especially when using just 1gb switches. Since each pair of network cards is divided between two Cisco switches, we’ve been unable to get 2gb of combined throughput at any given time even when using the vendor’s multipathing software. We got an eval system from LeftHand Networks hoping it would resolve that issue, but the onsite tech agreed that it just couldn’t be done if the two network cards were connected to two different Cisco switches.

Summary: A Problem, but There’s a Solution…

These problems haven’t slowed our adoption of C-Class blades with conventional switchgear – the switches were an inconvenience that we can get around.

There’s also a solution to most of these problems: the HP Virtual Connect system. More about that in the next article in the series.

Continue to Part 3: HP Virtual Connect Review

Brent Ozar

More Posts - Website

Follow Me:

11 Comments - Leave a comment!