When I used to be a system administrator, back when 2GB hard drives were the norm, I remember an Oracle system that only needed about 4GB of storage space, but our Oracle savvy system administrator configured an environment with around 30 x 2GB drives.

That was my first introduction to spindles and their relationship to performance.

As the years have gone by, and drive capacities have increased, the spindle problem only briefly appeared to go away – not due to capacity, but due to increasing rotational speed and other improved performance characteristics of drives.

However, perhaps even more so than high performance databases, virtualisation is forcing system administrators to become reacquainted with spindle configuration issues; multi-core systems supporting dozens of virtualised servers create IO problems even within relatively small environments.

If you’re interested in reading more about spindle issues, you may want to check out this article on Search Storage – Get More IOPS per dollar with SSD, 2.5″ Drives. Regardless of the actual vendors discussed, this article is a good overview of the spindle problem. If you’re struggling with virtualised (or even database) IO performance, and were not previously aware of spindle issues, check it out for an introduction. (As practically all storage vendors are moving into high performance options involving either SSDs and/or massive numbers of 2.5″ drives, the article is relevant regardless of your preferred storage platform.)

(If you’re looking for a backup angle to this posting, consider the following: as you virtualise and or put in applications/systems with increasingly higher demands for IOPS, you affect not only primary production operations, but also protection, maintenance and management functions, including (but not limited to) backups. Sometimes performance issues that exist, but are not yet plaguing production operations, manifest first in backup situations where there are high intensity prolonged sequential reads.)

 

To me the most valuable documents produced by EMC in relation to NetWorker or the modules are the Release Notes. These accompany any cited version update and typically contain at least the following chunks of information:

  • New features to the product
  • Changes to existing behaviour
  • Fixed problems
  • Known issues and limitations

This information is gold. To anyone thinking of updating either a NetWorker server or a NetWorker module who isn’t planning on thoroughly reading the release notes first I say this: are you nuts?

I’m the first to admit that I don’t re-read the administration guides every time they are updated. There’s just too much content in them. Instead, I rely on the release notes to tell me what has been added, and if any of that is relevant to my needs, I go searching through the administration guides for said information. In fact, I consider the release notes important enough that they’re the only NetWorker documentation I ever print. Why do I print them? Because it means I can take them away from the computer and go sit down and read them carefully – very carefully.

The release notes don’t always contain all information about an update. They also may not fully elucidate on particular problems that have been fixed*.

To me the most important aspect to the release notes – the bit I check first, is the “Known problems and limitations”. Why? This is the bit that gives you the warnings of “things that don’t work”, or “things that you may have to pay more attention to than you would otherwise think to”. I.e., what is known to not work. One would ignore these in particular at ones own peril.

So, next time you’re thinking of updating any part of your NetWorker environment, please, make sure you download and read the release notes.


* I can attest to this when I review release notes and see LGTscABCDEF numbers that have been created in response to bug filings I’ve made … a 2-3 line entry can’t convey all the details of sometimes complex, sometimes esoteric escalations.

© 2012 The NetWorker Blog Suffusion theme by Sayontan Sinha