Did you know that BACKUP automatically tells OpenVMS to avoid use of the XFC when it requests data? But most other backup applications do not know how to do this. (Hint: It’s a modifier to the $QIO call requesting the data. Most third party backup applications do not use it.) If you have a backup application that uses OpenVMS BACKUP (SLS, ABS are two examples), then you are automatically covered.
But why would you care? Well, when you have an applications (backup or otherwise) that walks through a volume, unless the application tells OpenVMS to not cache the data, it will end up bumping everything else out of the XFC cache. So, your Customer Service Rep suddenly has to read all the way to the back end of the array to get the data. As a result, such jobs can result in poor system performance when they run.
So, a large end of day job that wades through an entire database, a large SQL query job. A backup job that does not tell OpenVMS to avoid XFC cache. All of them can lead to po
HP OpenVMS version 8.4
for Integrity server systems and AlphaServer—New features and benefits
Performance and Scaling Enhancements
Dynamic Enabling/Disabling of XFC Cache for Mounted Volumes
New features in XFC to dynamically enable/disable cache for mounted
volumes
Users can dynamically disable caching on a volume and then perform huge
backup, copy and search operations. Once this is complete caching can be
enabled on that volume.
With OpenVMS V8.4 you will find new Storage Capabilities. This note will just deal with a couple different issues.
First, the volume size limit is increased to 2TB from 1TB. In fact the size is just short of 2TB and 1TB respectively. Here’s some information from Rob Eulenstein:
“At the present time (V8.3/V8.3-1H1) the maximum volume size supported by OpenVMS is just under 1 terabyte (TB). The actual number of 512-byte disk blocks is 2,147,475,456 decimal or 7FFFE000 hex.
Support for 2 TB volumes is expected in OpenVMS Alpha & Integrity V8.4. In VAX V5.5-2 and earlier versions, the maximum supported volume size was just 16,777,215 blocks decimal or 00FFFFFF hex. That’s only 8 GB. The maximum number of files on an OpenVMS volume is 16,711,679. This value is calculated as follows: 2**24 – 2**16 – 1 and is not expected to change in V8.4.”
When configuring volume space on a storage array, it is VERY important to note that you are not configuring 1TB or 2TB. It is just shy of that amount. Use the number of 512-byte blocks (V8.3 is 2,147,475,456, V8.4 is 4,294,959,104) to configure the storage on a storage array. While these are ALMOST 1TB and 2TB, they are in fact just shy of that.
Why are they not exactly 1TB and 2TB, respectively? Well, there are numerous problems that arise when a volume is right up at the 1TB limit (under OpenVMS V8.3 and V8.4). Thus, HP’s OpenVMS engineering set the actual number of blocks comfortably below that number of blocks.
Why the change with BACKUP? Well, imagine dealing with very large volumes on a lower end system that does not have one of the fancier / expensive tape libraries. It would be nice to both COMPRESS and ENCRYPT the output saveset. And that’s exactly what HP’s OpenVMS engineering heard as a need. Remember the concern that Rich Jordan had with lack of ENCRYPTION and COMPRESSION? While this won’t be done in the tape device, the OpenVMS system can do this for output to a tape that will be sent offsite (such as to an offsite storage and/or DR location).
Both of these key features clearly show that HP’s OpenVMS engineering continues to listen to your needs as you implement your systems. They hear and help implement features you need to meet your business needs.
So, enjoy OpenVMS V8.4 is here. And OpenVMS continues to grow and change to meet your changing needs.
HP OpenVMS version 8.4
for Integrity server systems and AlphaServer—New features and benefits
This document describes the new features and enhancements included in OpenVMS
Version 8.4 for AlphaServer and Integrity server systems and its associated
products.
When we build systems, it’s never what we expect that causes the problems, it’s the unexpected that eventually causes problems. For example, this news article demonstrates why we need to try to prepare for the unexpected. Of course, with OpenVMS it is quite possible to build a split site cluster to provide greater disaster tolerance.
But the eruption of a volcano would cover more territory than a split site cluster. In that case, a business requires a two fold strategy. I tend to think of this as a strategy to provide disaster tolerance and one to handle disaster recovery.
Hopefully the first strategy allows the business to keep functioning with minimal or no interruption in the event of a problem. Think of this as Disaster Tolerance.
Sometimes some natural or man-made disaster impacts an entire metropolitan area and the Disaster Tolerant setup can not provide the resilience needed. Then we turn to Disaster Recovery, where the business should be ready to restart operations as quickly as needed.
Thus, no matter who makes the storage array (You were wondering how this deals with storage, weren’t you?), one array does not suffice for Mission Critical data and applications. Period.
From Rob Eulenstein, who taught me the difference between the common wisdom and what actually happens:
We often heat that MOUNT/NOCACHE disables all the XQP caches. This is not the case. MOUNT/NOCACHE disables the per-volume specialized caches (FIDCACHE, EXTCACHE and QUOCACHE) which are allocated from non-paged pool and XFC caching on that volume. MOUNT/NOCACHE also disables the deferred write feature for file headers. The system-wide I/O buffer pool a.k.a. the FCP cache (HDRCACHE, MAPCACHE, DIRCACHE and DINDXCACHE) cannot be disabled.
Sometimes it is necessary to erase the contents of a volume either before or after it is put into use in an OpenVMS environment. This can be driven by corporate rules and regulations. The need to erase the data can be driven by the need to follow governmental rules and regulations. And as we all know, it can be driven by the need to protect secrets.
Whatever the driving force behind the need to protect the contents of a volume, the use of SAN storage greatly complicates this issue. For example, how do you ensure the data is fully protected from scavenging of data in an environment that might move from location to location? Let’s expand upon this with two different storage array technologies.
EVA Storage Arrays
EVA Storage Arrays provide virtual RAID volumes. The advantage of this approach is that the volume is automatically spread across as many physical spindles as possible to decrease the utilization of any single spindle and thus decrease the overall response time from all physical spindles.
Unfortunately, this also implies the data will migrate from physical volume to physical volume. What happens if a physical disk fails? Can we guarantee the data on that volume has been properly erased, even if we performed an INITIALIZE/ERASE using the DoD erasure pattern?
Update on 2008/08/10: I put on my thinking cap on this, and realized there are two potential solutions to this issue with the EVA storage arrays. First, the EVA Storage Array can be used to contain similar data. Second, if a mixed environment is needed (such as patient information mixed with user data storage), then a separate disk group to contain the sensitive data can be used. This helps isolate the data within the EVA storage array.
For most sites, destruction of that failed physical spindle would probably suffice. But some sites might need to be able to ascertain the contents of the physical disk. In those situations, virtual raid technology, such as the EVA Storage Arrays might not be the best choice.
For most OpenVMS installations (probably over 98% of them), this is not an issue. However, since many in the OpenVMS community must deal with sensitive data of various levels, it is important to realize this could be an issue.
XP Disk Arrays
XP Disk Arrays do offer the chance to better control the contents of the physical volumes. While the data can be spread across numerous physical disks, the assignment of the data to specific physical disks is completely up to the SAN administrator. This would allow a customer, who handles sensitive data, to assign a specific pool of physical disks to handle the sensitive data.
Additionally, you can purchase software to provide Data Shredding for XP Disk Arrays. There are several advantages to this. First, it ensures data presented to various hosts follow corporate / regulatory guidelines. Second, the work is done outside of the host environment. Though INITIALIZE/ERASE with the DoD erasure pattern can do the same, with very large volumes, the time required is extensive. Performing this operation on the array allows the array to completely offload the work from the host.
Some Pointers
The following pointers might provide a better understanding of this information.
To subscribe (1) enter your information, then (2) click on the link in the email to activate your subscription.
Why two steps? This approach protects your privacy.
With 30 years experience, John harmonizes OpenVMS, Linux and VMware with storage.
