SURVEY - Hard Disk Configuration for Large LabVIEW Application Development?

[Mark.Ridgley]

Please take a few minutes to comment on the following items as they relate to hard disk configuration for large LabVIEW application development for Production test systems:

Hard disk configuration

Describe the number of hard disks typically used.

Describe the size and use each disk partition.

Hard Disk Redundancy and Disaster Recovery

Describe the strategies typically used to:

• Implement hard disk redundancy.
• Guard against an operating system crash / corruption.
• Rebuild system hard disks after an operating system crash / corruption.

LabVIEW Software Installation and File Locations

Describe the LabVIEW software installation used  (development environment or run-time only?).

Describe the paths where drivers, application VIs and configuration files are stored on disk.

Thanks for your input.

[Elijah_K]

I'm afraid that I can't speak from the experience of having my own production test system, but I am a big fan of RAID 0+1 and use it on my Linux server at home, though I hear RAID 6 is where it's at these days.  Most RAID configurations are designed to allow one HDD to fail and quickly be swapped without any down-time.  While the hard drive is being replaced, the performance can take a slight hit and the system is at risk of catastrophic failure if additional drives fail.  As a result, this is typically combined with an off-site mirror or even tape backups.

As solid-sate HDDs become cheaper and more common, these will also greatly reduce the risk of failure since they have absolutely 0 mechanical parts that can fail (unlike traditional HDDs, which, aside from getting smaller and having increased size, still use the same concepts as several decades ago).

I'm also very curious to hear from any of you with production test systems who have insight into Mark's questions.

[tstahl]

Our customers have vastly different needs and specifications.  A lower-end system will have two hard drives, one for the OS, application and configuration (~40 GB) and the second for test data storage (~80 GB) with customer's IT performing disk imaging when they decide to.  The highest-end system we've created had two hot-swap RAID-0 15,000 RPM 160 GB SCSI hard drives with drive imaging software automatically backing up the system nightly to a server and the server to rotating tape set nightly.  Our customers almost always require single partitions.

Our current software installs under Program Files as any Windows appllication.  Configuration files are in an adjacent directory to the LabVIEW based application.  We have VB based software that also installs in adjacent directories to the LabVIEW based application.  Device drivers are installed to their default directories.

Tim

[Evan R.]

All that *and* a Linux Kernel... where do you find the time?

I just spent about 12 hours fighting with KDE 4.1 before switching to Gnome. What distro do you use? Given that I want the ability to use NI HW I am somewhat limited, but have opted for Mandriva.

[Elijah_K]

I setup that server several years ago and selected Red Hat.  It's basically just a file server and a backup storage location.  If I were to start over now, I'd probably use Ubuntu.

[Elijah_K]

To Tim's point, keeping the application on a seperate HDD from the OS is a common solution, since the OS is more likely to get corrupted than a drive used purely for data storage.  That being said, mirroring both on a production system to minimize downtown is important.

[Mark.Ridgley]

I'd like to thank everyone for their input and insight on this topic.

I have worked with Production test systems that were set up with a primary and secondary hot-swappable drive with the secondary drive serving as a mirror of the primary drive and both drives partitioned as shown in the following image:

(NOTE: Click on the image to see an enlarged and readable view)

The C:\ partition was for the OS and applications. The E:\ partition was strictly for test reports and the F:\ partition was where the test code (VIs, sequences and supporting files) resided. The rationale given for this setup was that the C:\ partition could be rebuilt without having to worry about the test data or test code should the operating system become corrupted. While this rationale may have had some merit, I'm not sure that this arrangement was the best for redundancy and deployment of the systems. In addition, I believe that the exposure to the risk of data loss due to a physical disk failure was greater since all of the partitions were on a single physical disk (Although we could switch over to the secondary mirror drive if the primary drive failed).

In my opinion, this arrangement called into question the value of setting up and maintaining the E:\ and F:\ partitions, so my recommendation was to switch to a single partition setup consisting of either two single partition drives with the secondary drive set up as a mirror of the primary drive or two single partition drives with the OS on the primary drive and everything else on the secondary drive. In either case IT would have performed disk imaging.

I welcome any additional feedback on this topic.

[Elijah_K]

Of course, data redundancy is always an issue no matter what type of software application you're working with.  The concerns for LabVIEW applications are no different from any other software, but since LabVIEW is often running expensive, high-volume production test facilities, it's important that any sort of redudancy be readily available to minimize downtime.

To that end, RAID arrays seem like an increasingly popular solution.  Depending upon your RAID configuration, one or more drives can completely fail and the system will be able to continue operation until a backup is supplied.  To mitigate the risk of any failure, I've seen an increasing number of customers using solid-state hard drives as they become less cost prohibitive.

And of course, for those really expensive projects where data preservation means everything, off-site backups are a must, but you'll probably want to enlist the help of IT for that project.