|
Storage management is taking an ever-increasing amount of time and effort
from systems administrators—the ever-increasing rate of storage growth impacts
file, database, messaging and application servers alike. Systems administrators
are hard-pressed to keep up. Many businesses have few or no policies for
data and message retention, and the problem may be compounded as users store
multiple copies of files that take up lots of space, such as zipped installation
files, development kits. Not to mention those videos and music files that
eat disk space the way an F-15 on full afterburner guzzles JP-7 jet fuel.
The storage growth for messaging alone, especially in view of recent statutory
changes like parts of the Sarbanes-Oxley legislation requiring companies
to maintain archives of message traffic, is staggering.
Many companies have implemented hierarchical storage management (HSM) systems
that replace stale files with stubs or links that take up little or no space
while still allowing users access to files sent to tape or slower disk. Other
companies have not yet put forth the effort and investment it takes to implement
HSM, and the burden of keeping up with storage growth (and more importantly,
free space shrinkage!) is on the shoulders of the systems administrator.
Even savvy systems administrators have had the experience of a file server
running out of space and heard the shrill cries of users who can’t store
the latest joke video making circulation. And the experience of the email
server that begins to refuse messages when its disk is full is also all too
common. The systems administrator faces the whining of users and the wrath
of management. Management might not have any policy regarding file or email
retention, but it’s the systems administrator who is held responsible when
the server runs out of space.
Scripting doesn’t provide a magic bullet for dealing with the plethora of
challenges presented by storage management. But The script provided with this article provides a way to keep
track of storage growth, and keep the systems administrator out of trouble.
This script will:
· Record
the free space on networked volume(s) in a file
· Compare
today’s free space with yesterday’s
· Save
daily figures to an archive file for long-term trending
· Automatically
sends the report to specified recipients
The last function is especially useful. You’ve told management time and
again that the server is running out of space, but
when it finally happens, they’ll ask why you didn’t warn them. This script
sends your manager a daily message to keep storage growth needs on the radar
screen, and avoids the “Why wasn’t I told this was coming?” question altogether.
It’s a sort of automatic “get out of jail free” card for the harried systems
admin, and also helps justify purchase of more disk space.
Okay, enough of the litany of the slings and arrows of outrageous user and
management demands we systems admins have to face; let’s look at how to code
our way around some of them! For those of you who are already familiar with
the Windows Script Host (WSH) and VBScript, you can go right
to the code. For those who are still neophytes at using WSH and VBScript,
I’ll try to wring a few teaching opportunities out of the code.
First, download the script here: StorageGrowth.zip (zipped
text file) and open it up using your favorite script editor. If you
have Microsoft Office 2000 or newer installed on your PC, you already have
a very good one in Microsoft Script Editor.
Look in the path where your Office executables are (typically ..\Program
Files\Microsoft Office\Office 10 for Office XP) and you should see MSE7.EXE.
If you don’t see it, bring up Word and install the web page editing functionality
to get the Script Editor. You can use the MSE7 executable
or go into Word and click Tools, Macro, Microsoft Script Editor, or
hit Alt+Shift+F11, the Word hotkey to bring up Script Editor.
Otherwise, you can use Notepad or any of several third-party
script editors to do the job—my personal favorite is PrimalScript,
by Sapien Technologies.
If you have Visual Studio installed, you also have a very
good Integrated Development Environment you can use for Script editing.
Before we get started you’ll need to set up a folder to hold the raw data
file we’ll generate. In that folder, create a backup folder as well. You
will also need to create a dummy data file for the first time you run the
script—you’ll see why as you look at the code. And, finally, a text file
to which archive data can be appended.
Now, to the code. First things first. We’re not going to get too fancy to gather
our information. Our script breaks down into several blocks, to wit:
1. Set
up objects and variables used throughout the script.
2. Get
yesterday’s free space information (saved by this script yesterday to a
file.)
3. Map
drives.
4. Get
today’s free space information from the drives we mapped in step 2, hold
it in memory and save a file for tomorrow’s run.
5. Unmap
drives.
6. Build
our storage report.
7. Archive
data to a file that saves data over time to use for long-term trending.
8. Send
the report we built in step 5 as an SMTP message to specified recipients.
This is the outline of the script, and for the remainder of this article.
First things first. This script uses the Network
Object to map drives to the volumes we want to track, and the File
System Object and its methods to get information about those drives
as well as to get and store our data to files. We’ll dimension variables for
the File system object and the Network object here, and also a string variable
to hold the fully distinguished path to the raw data file we’ll use each
day to track storage changes.
We assign values to the variables we’ve dimensioned. For the file path to
our raw data file, this is a string. For the File System and Network Objects,
what we do with the SET command is to instantiate those objects and make them
and their methods usable by the rest of the script. We are also going to
set up some constants used by the File System Object for the reading
and writing of text files—one of these concerns how files are opened, the
other is a VB tristate variable with values of true, false and default. We’ll
use these below.
Now let’s get to the action. The GetYesterday block gets the free space
we stored yesterday to a text file. In our example script we’re monitoring
four volumes, so we’ll store the raw data to an array with four elements, arrYest(0-3).
Before you run this script the first time, you will want to stick a file
out with the same name you defined as strRaw. This file
will have numbers that represent free space on each of the drives monitored
by the script. For the first time, you can simply create a file with a zero
for each drive you’re monitoring. The content of the file should look like
this:
0
0
0
0
The first time you run this script you will show a gain of free space equivalent
to the entire amount of free space you have on each monitored volume. Second
and subsequent runs will show actual storage deltas. The GetYesterday block
reads in each line of the raw data file to an element of the arrYest()
array, in our example, 0-3. Now we can close that file and press
on.
Before we can get today’s data to compare with what we’ve stored, we need
to be able to touch the drives we’re monitoring. In order to do this we will
store the drive letters we’ll use to an array, the UNC path to each monitored
volume to another array, and we’ll use a little for-next loop to map each
drive. On the way, if there is already a drive mapped to the letter we’re
trying to use, we’ll delete that mapping. Note that we could just as easily
use a single array with two dimensions for this step, but here I’ve used
two arrays for the sake of clarity.
Now let’s proceed to get today’s information from the volumes we mapped
in the previous block. Look at the block marked GetToday.
First, we’ll back up yesterday’s raw data file—it’s already stored to memory
so we don’t need it any more, but we might want to keep it around for a day
just in case. We’ll delete the backup we made yesterday and move yesterday’s
file into the backup folder. This simply follows the prime directive of systems
administration: whatever you do, make sure it’s reversible, i.e., back it
up.
Next we use the File System Object to create our Raw data
file, or re-create it. Now we have a file to write our data to, and we’ve
mapped drives to get them from. What remains is to get the data. We use
the File System Object to enumerate all the drives on our system into the colDrives collection.
Next, we’ll go through each of the drives on our system. We’re only interested
in drives that are really there, so we’ll check to see if drives are ready,
and finally we only want to get information on the drives we’re monitoring,
so we’ll use a for-next loop to run through the array of drive letters we
used for mapping. We’ll collect data only when a drive matches one of our
target drives—this
is why we check to see if the drive letter equals the path of the drive
we’re
currently checking.
Now we’ll take the free space on our target drive. The raw available space
returned by the File System object is divided by 1073741824 to yield
Gigabytes, and we format the number to two decimal places. We’ll assign the
result to our array containing all the numbers, and also write it out to
the raw data file the script will use tomorrow. On the way out we’ll close
the raw data file—we’re done with it for today—and
clear the drives collection from memory. We’ll also unmap our drives as they’re
not needed any more.
Now we have all the information we need—we’ll build our report text. In
the environment where I use this report, my manager wants to see the
aggregate free space for all storage systems, so I add the total free space
up from each monitored drive. The values we saved in the previous block,
like all VBScript values, are saved as variable data. We have to use a technique
called data
type coercion to make the script engine recognize this value as a number
instead of a string, otherwise the script engine
can’t do mathematical operations on them. We use CSng to
coerce the values to singular numeric data, which adds just fine. Now
for my report I simply take yesterday’s total free space and subtract
today’s to get the total storage Delta for today. If the delta is a negative
number, we’ve gained space, and if positive, we’ve used space.
You may want to be more granular about what you report, so you can modify
the GetToday block to get a wide variety of information
about your monitored drives. In my report, the example volumes each contain
150 total GB of space, so I have that amount recorded as a string.
You could just as easily get the TotalSize property at the
same time as AvailableSpace and populate this information
here.
Our monitored volumes are part of a SAN infrastructure, so my managers were
interested in the total storage delta for each day. Modify your report according
to your needs and those of your management. Note that what we are doing is
building the report body as a single text string with a VB carriage return
linefeed character at the end of each line. For testing, I echo the entire
report string to the console, but for production there’s no need to do so.
We’ve built our report text, and now before we send it off, let’s take today’s
raw data and add it to a file we can use for long-term trending. To do this
we will append the raw data delimited by commas to the archive file we set
up. I would suggest setting up the file with comma-delimited field names
with the volume or UNC path of each column. You’ll be able to bring this
file up in Excel and create snazzy graphs using techniques you’ve learned
from Jon
Peltier's Excel Charting article, here in TechTrax.
Okay, we’re almost done. The last thing we want to do is to take the report
we generated and send it off to our specified recipients. In order to do
this we’ll use the CDO Message Object—this technique sends
an email without using any email client on the host running the script, and
uses an external SMTP server, so you won’t need to install any ancillary
services. You can add as many recipients as you need separated by semicolons.
This portion of the script is very standardized—the text in the example can
be your boilerplate—you’ll only need to change the host name or substitute
the IP address of your SMTP server. If your SMTP server uses no authentication
(quite common for intranet SMTP servers) you can comment out or delete the
sections needed for authentication only. Otherwise, you can put your SMTP
username and password where needed, and your script is complete.
After tweaking and testing your script by sending it to yourself, you can
add your real recipient list and run the script using the Windows Scheduler.
Click Start, Control Panel, Scheduled Tasks. Add a new scheduled
task and you can browse directly to your .vbs file for this script—Windows
will run the script using Wscript, the default engine. Alternately you can
write a batch file with CScript (pathname)\storgrowth.vbs. You’ll
want to run the task every weekday or perhaps every day—this will provide
a daily report to your recipients and keep storage growth on the radar screen.
In review, this script doesn’t do anything to your storage systems; it just
gathers information, presents it in a useful format, and sends it to whoever
you want to send it to. When management calls a meeting to discuss long-term
storage growth trends, you’ll have the snazzy graphs you made from your archive
file, and your managers will appreciate being kept apprised of the current
needs of the enterprise. You can also use this to help estimate storage needs
for next budget year, and use this data to justify the purchase of more drive
space. And you’ll have all this information at your fingertips without having
to manually go and find the information, re-inventing the wheel each time
management asks for it. The time you’ll save is yours to use as you please—advancing
your career or improving your chip shot—you choose.
|
