Active Storage claims that its XRAID boxes are "an evolution in storage for Apple users." With far prettier looks than other models, a Mac OS native suite of configuration and monitoring applications, and at least a commitment to this very vertical market, what we have in our midst is a very welcome alternative to what Apple thrusts upon us, which is Apple's tweaked version of Promise's Vtrack chassis.

From an economic perspective, this will mean a hopefully cheaper box for admin and integrators alike.

Apple's blessed version of the Promise VTrak have to get shipped from Promise to Apple, where they get fitted with special drives and firmware, and then are offered to sales channels with Apple's traditional razor-thin margin. The Active Storage XRAID, however, will be offered through authorized resellers, allowing much higher margins for those resellers. In the long term, this should mean that even though Active have MSRPs that mimic their Promise cousins, street prices for these boxes may be substantially lower.

It's no secret that the aim of Active is to provide a better box than Promise. The box specifications are almost identical as are their MSRPs. So the question then remains, does the XRAID hold up in real-world performance?

Well, to answer that question, some bold marketers at Active surrendered a box, early off the production line, to Meta Media and our unflinching test lab. Here then, is a summary of what we discovered in our 72 hours with the box.

Performance

Active claims 10% or higher improvement in performance over the "competition" on their website, again meaning Promise. From a raw I/O perspective, it looked like perhaps there was an increase, but when doing articulate performance tests with QuickTime-esque I/O, I would describe the difference to Promise as negligible with writes, but by no means less, and considerably better with reads. However, as you'll read, when factoring in the additional caches in the drives that Active has spec'd (32 MB), and some clearly superior algorithms in how it handles its controller caches, the box starts to pull away from the competition when placed in a multiple I/O environment such as Xsan.

Directly-Attached Tests

We first configured the box to present two 7-drive RAID-5 LUNs, with two hot spares. Since this has been and will continue to be a popular configuration for a 16-drive chassis, we used it as the basis for these tests. RAID build time was similar to promise: about 7 hours for a RAID-5.

Raw I/O tests (IOMeter & dd) found an upper write limit of around 410 MB/s and upper read at a remarkable 710 MB/s. Remember, this is a single box with two 7-drive RAID-5s. We could argue that these figures would just about double if the unit had its expansion chassis attached and two additional 7-drive RAID-5 LUNs added to the soft RAID0 that the Mac OS provides.

We then went about subjecting the box to more "real world" I/O. Here is one DAS-based test versus Promise. In this case, both boxes were configured with two 7-drive RAID-5 LUNs with two hot spares. My colleague Masashi Tanimura from Kaga Electronics in Tokyo provided me the data from one of the new Promise boxes.

	write	read
Promise (E-Class, Silver, 1TB drives)	375 MB/s	534 MB/s
Active Storage XRAID	376 MB/s	643 MB/s

AJA System Test - 1920x1080 10-bit on Two 7-drive RAID-5 LUNs in software RAID-0

Note: This graph is the XRAID.

Because the XRAID drives contain fatter drive caches, the read speeds take off.

Active boasts on its website that a 16-drive RAID-5 is the best display of the box's prowess. However, it wasn't. The most I was able to conjure out of a single 16-drive RAID-5 (which can only be presented on one controller since it's only one LUN) was around 300 MB/s write and 500 MB/s read. For the box to really fly, it needs two LUNs, so that each can have an affinity to a separate controller. So I can only imagine the throughput on a standard/expansion chassis combo where each box has a 16-drive RAID-5 with an affinity to a specific controller.

For those interested in its 8-drive RAID-5 performance (with no spares), it edged slightly higher on the reads but didn't budge on the writes.

	write	read
Active Storage XRAID	376 MB/s	665 MB/s

AJA System Test - 1920x1080 10-bit on Two 8-drive RAID-5 LUNs in software RAID-0

It should be mentioned that the system can do RAID-6, but since any RAID-6 algorithm has a corresponding performance hit, we didn't bother to wait for a rebuild to test this.

Xsan Tests

I then placed the box into an Xsan volume configuration, just using two 7-drive RAID-5 LUNs in a storage pool. (My metadata LUN was hosted on a solitary Xserve RAID controller.) The block size was 16K and the stripe for this pool was 32, following the well-worn formula: 16K x 2 LUNs x 32 SB = 1 MB.

Firing up Xsan Tuner, I could reliably pull three streams of 1080i30 10-bit, or about 475 MB/s from the box from a single machine.

Trying to find the upper limit, I managed to pull 4 streams of 1080p24 10-bit, or 506 MB/s, for as long as I wanted. Anything above that failed rather quickly.

Pulling from multiple clients, that ceiling of 500 MB/s pretty much held when doing read tests. Any combination of reads held up as long as it did not exceed the 500 MB/s threshold.

Next I tried doing simultaneous read and write on multiple clients, and the overall threshold descended to around 425 MB/s, consistently. This would mean that a conservative estimate of 400 MB/s per box (or somewhere around 800 MB/s per standard/expansion pair) could be used when planning overall bandwidth availability.

This figure alone is quite different from Promise, where the going standard is to estimate availability at 320 MB/s per box, or 640 MB/s per E-Class/J-Class pair.

Controller Failover

Active approaches failover in a more traditional way when presenting the XRAID on a fabric. All ports register as Fabric-to-Loop or FL. This way, LUNs that have an affinity to a certain controller can automatically be represented on the other. This is similar to how Infrotrend handles their active/active controllers, and it provides the fastest representation. Promise, on the other hand, registers the VTrack's controller ports as Point-to-Point which revert to Loop in the event of failure, and back to Point-to-Point when failing back. This causes a general WWN "confusion" on Macs and would usually warrant a shutdown of the SAN to right things again.

During active I/O on the SAN, I pulled either primary or secondary controller of the XRAID and saw an almost immediate representations of the LUNs on the surviving controller.

I/O continued, but performance dropped to half of its original. This is to be expected, as there are only half the spigots available to do I/O.

In cases where I pulled the "primary" controller of the box, the RAID went "red" in the Active Viewer application and it appeared non-contactable. I then had to search for the other IP address of the surviving controller in order to see the status. So at present, the Active Viewer only attaches and knows about one of the controllers, and if that happens to be the one that goes down, you'll have to scramble to connect to the surviving controller to see what has happened to the box.

Upon replacing the controller, it took about 90-120 seconds for the presentation to right itself, and in this case, there was a complete cessation of I/O for about 5-10 seconds. This would mean that in a 24/7/365 concern, there would need to be a "lull" in I/O in order to replace a failed controller. Not a shutdown of the volume, mind you, but a pause in activity while the box righted itself.

After both controllers came back online, I did get full read performance back.

However, write performance withered down to only 50 MB/s or so for the whole box. Moreover, I couldn't shut down the box either physically or through the Active Viewer app. If I pulled the plugs and powered the box back up, all was well. But this is hardly the procedure one would want for a large deployment. I brought this issue up to engineering, and they're aware of the phenomenon. They told me that it will be resolved in future firmware revisions.

Drive Failover

For drive failover, Active has opted for the system found in Apple's old Xserve RAID: a drive that is not part of a LUN is a spare. When a drive fails, a spare is used to immediately begin the rebuild. When the failed drive is replaced, it becomes a spare. Nice and simple.

I tried out this technique during I/O operations and found that the rebuild happened quite quickly and allowed I/O to continue without interruption, although performance (specifically read performance) obviously dropped while the rebuild occurred. What was more concerning was that the box once again fell off the map and couldn't be contacted. So even though the RAID began to beep and drive activity clearly indicated that a rebuild was underway, I couldn't use the GUI to ascertain that from the comfort of my desk. Engineering said this was because email notifications were not set, but even with these set, the same phenomenon occurred.

Noise

The XRAID has three variable speed fan modules, which ramp up when the box is undergoing I/O activity. They idle at around 3,200 RPM but then wind up to 4,200 RPM or higher at the first signs of activity. At this higher level, the box produces a tremendous amount of noise that will not be acceptable in DAS situations unless it is enclosed inside a noise-abating case. What's worse is that the fans do not ramp back down for literally hours after all I/O activity has ceased. Pulling one of the fan modules resulted in a sympathetic ramp of RPMs on the surviving modules.

Power Draw

Placing our Megger analyzer on the XRAID's power cables, I found that idle draw was just under 1 amp on the left supply and about .7 on the right. During max I/O tests, draw was 1.1 amp on the left and around .8 on the right. Folks should therefore calculate around 2 amps of draw per box when configuring power and UPS requirements.

Aesthetics

Obviously, one factor that completely outshines all competition is the overall look of the box and its remarkably simple administration and monitoring tools. Much has been made of the iPhone app, which sadly was not available for download. But the configuration app (Active Admin) and monitoring app (Active Viewer) both excel in their incredible ease of use and clear indicators. Geeks like us will be disappointed in what gets hidden from the end user in these apps, but there is no doubt that their simplicity lends to a quick configuration experience. We found the best part to be the very straighforward configuration section of the Active Admin app.

For large orders, Active Storage intends to custom configure XRAID boxes before they leave the factory, which should mean a lower time-to-use for the boxes in large deployments. Standard config boxes will also be released to distribution for smaller orders.

CLI

Much more important to us was the CLI tool, activeadmin, which offers a plethora of configuration and status options. One of the switches for this app, "stats," provides real-time stats on individual drives, LUNs, controllers and fibre ports, although the only ones operational at the time of this writing were those for the fibre ports.

Support

Apple thus far has committed to supporting only Promise for Xsan. But many of us know that this "support" has often been a subtle blend of finger pointing and stalling as issues with Promise firmware crept up over the spring and summer of last year. Anyone considering using Active in their deployments will have to make their own conclusions as to whether Apple "support" is critical.  For those in the reseller/integrator community, this is really a no brainer: as long as we can get clear lines of communication from Active, and current firmware issues are resolved, the probable lower cost of these boxes will make them fierce competitors with current offerings in the storage market.

Conclusions

The box delivers impressive performance with an in-rack appearance that can't be beat. Admin and monitoring tools set a new level of ease of use. However, firmware glitches in the current shipping box would prohibit us from spec'ing this for any kind of enterprise-level deployment.

It's no secret to our community that Promise took a major credibility hit with its out-of-the-blocks firmware issues, which worsened when the patch to fix them did not arrive until 9 months after their launch.

If Active Storage really wants to stand behind its "evolution" statement, it will keep clear and open lines of communication with our community. This way, when firmware issues are resolved, they can find their way into the field quickly.