As I noted in my “quick walk” post’s comments, I had difficulty getting LDAP working initially on my corporate Active Directory network. The crux for me turned out to be getting the LDAP Schema Definitions correct. Here are the settings that worked correctly for me, authenticating against an AD instance with the schema extended by Microsoft’s Services for Unix add-on (other LDAP schemata will, of course, need different mappings):

USERS
Search descriptor: Don’t leave this blank - according to the Fishworks documentation this “sets the LDAP search descriptor, attribute mappings and object class mappings for users and groups. By default, the search descriptor for users is ou=people,dc=example,dc=com, and for groups is ou=group,dc=example,dc=com” - so what you enter will be site-specific.

Attribute mappings:

• uid=msSFU30Name
• uidNumber=msSFU30UidNumber
• gidNumber=msSFU30GidNumber

Object class mappings:

• posixAccount=User

GROUPS
Search descriptor: Again, don’t leave this blank - enter the appropriate value for your site.

Attribute mappings:

• gidNumber=msSFU30GidNumber
• uniqueMember=msSFU30PosixMember

Object class mappings:

• posixGroup=group

How did I know that the schema definition mappings were the problem? The logs gave it away: Maintenance -> Logs -> System, where I saw messages similar to the following: “libsldap: Status: 0 Mesg: Unable to set value: schema map already existed for ‘User’.”

How did I know that I had the schema definitions working? Share settings that I had created using numeric UIDs and GIDs automatically became mapped to the correct user and group names.

I’ll update this post if I find additional configuration that may be necessary.

That virtualized Fishworks appliance got me thinking: What if you combined this with this? Yeah, managing Elastic Block Store devices would require some changes, but, if you needed a NAS for your EC2 instances…

That was easy...

Below is a quick walkthrough of my experience booting and installing the Fishworks VMware appliance; my thoughts follow.

Fishworks Boot Screen

Initial network configuration

Yes, Virginia, there is a command line - but not a conventional shell

Web interface login screen

Network configuration

Configure DNS - pretty basic stuff

NTP is a good thing

Name service configuration choices

Active Directory integration for CIFS shares is straightforward

Fishworks phone home...

Storage configuration made fast and easy

All done!

Thoughts: First off, as a VMware appliance and an introduction to Fishworks, this virtual machine is extremely well done; it gives users a low “activation energy” method to try out Fishworks. There’s a lot more effort involved getting a sixty-day loaner from Sun, as neat as that program is - even the logistics of racking and cabling the machine are relatively expensive in terms of time, after all. Of course, there are limitations inherent to a virtual machine; for example, I’d love to see how VMware ESX performs using a hybrid storage pool, but only real hardware can answer that. However, for most of my questions about Fishworks, the VM fits the bill.

Once you hit the VM’s virtual power button, it boots up quickly - faster than most OpenSolaris machines, subjectively - and the initial configuration is straightforward. Although I didn’t try it, it does appear that the machine can be completely configured from the command line, either at the console or over SSH. Once the system is configured, you have HTTPS or SSH remote administration access; however, SSH does not give you a standard Solaris shell, such as sh or bash. Instead, you get an interface very similar to Solaris’ zonecfg - a command line interface with multiple modes. (I suspect that a shell can be launched on the machine somewhere, somehow - it may even be documented - but I wouldn’t be stunned if it’s “unsupported.”)

The six-step configuration process via the web interface is smooth and consistent, and not particularly time-consuming - you get this sense that this is truly intended to be an appliance. My only complaints: The online docs were not immediately helpful (seriously - links to Wikipedia?), and when something does go wrong, you don’t get much more immediate help than this:

Uh-oh - how do I get to those log files?

By far, the best part of the configuration interface is step six - the storage configuration. You see a list of your configuration choices, with availability, performance and capacity rated. The left-hand column shows a pie-chart breakdown of your storage utilization, with the tiny “Reserved” slice surely being a jab at NetApp. (Well, maybe not - but as a NetApp user, it sure got my attention.) Simply pick your RAID type, click “commit” and you’re on your way. Genius.

All in all, very impressive. Makes me wish even more that I had a pair of 7410s to put behind ESX. And Exchange. And SQL Server. And my CIFS and NFS users… you get the idea.

• NFS v3 and v4
• CIFS
• iSCSI
• HTTP
• WebDAV
• FTP
• RAID-Z (RAID-5 and RAID-6), Mirrored, and Striped disk configurations
• Unlimited Read-only and Read-write Snapshots, with Snapshot Schedules
• Built-in Data Compression
• Remote Replication of data for Disaster Recovery
• Active-Active Clustering (in the Sun Storage 7410) for High Availability
• Thin Provisioning of iSCSI LUNs
• Virus Scanning and Quarantine
• NDMP Backup and Restore

A few comments: Looks like all of the usual ZFS features are there, with a few additions - in particular, I wasn’t aware that the virus scanning project existed, and I didn’t know that NDMP was far enough along to be included in a production release. Additionally, from looking at various Sun blogs, I believe that the remote replication feature is zfs send/recv, not AVS. Finally, from the nomenclature (”2008.11″), I’d guess that the software is based on the forthcoming release of OpenSolaris, not the recently released update to Solaris 10.

What’s missing? Off the top of my head:

• Fibre Channel - COMSTAR is coming, presumably.
• HSM - ADM is also presumably on its way in a future release.
• HCL entries for various products like VMware, but again, I have to believe that Sun is working hard on this as well.

My first impression from the launch materials: Neat, but the price seems high. Looking at list prices for the models, and doing some quick calculations for RAID-Z2 configurations with at least one hot spare, the price per usable TB ranges from $3999 and $3933 for a 7210 with 250GB and 1TB drives, respectively, to $11,209 for a single head 7410. Compare this to the hardware that the 7210/250GB is based on, the X4540, where you pay $2513.71 per usable TB. Now, as far as I know, Sun isn’t offering flash drives with their non-Fishworks hardware, so it makes direct comparisons of the price of the Fishworks Special Sauce impossible for most of the rest of the line, but that may change later this fall.

Other thoughts: Why not use the UltraSPARC T2 instead of Opterons? I’d expect better performance from the UltraSPARCs, especially when using 10GbE. Is it a cost issue?

One final note: Sun is making their simulator (a VMware image) available for download - nice touch.

Now when did VMWare say that I’d be able to automatically Storage VMotion my VMs off those hot, power-sucking Fibre Channel drives to SATA drives so I can power down my first tier storage overnight again?

This articles describes changing the default location for your virtual machines [sic] swap files. You may need to use this if you are running virtual machines from NFS storage.
Note: VMware recommends storing your swap on a VMFS3 volume, when running virtual machines on NFS storage.

(Emphasis mine.) The article provides none of the reasoning behind this recommendation, and a search of the VMware Knowledge Base for “nfs swap” only returns this article. There are quite a few mentions of not putting swap on NFS in the VMware Communities forums, citing performance reasons, but, as far as I could find, no support for the performance issue assertion.

Personally, I’m not buying the performance claims without substantiation - NFS and iSCSI to the same filer should be nearly equally performant. I could imagine a difference in locking behavior, but I’m having trouble imagining a scenario where lock contention with a VM swap file would become an issue.

On the other side of the issue, I’ve been hearing from a few folks - mostly NetApp employees or users - that placing swap on NFS is okay. On the viops site, Steve Chambers writes in a preview of VMworld TA 2784 (which I did not attend) that “there is no need to place swap space on non IP storage.” IP storage could mean iSCSI here, of course, but in the VM /ETC write up of TA 2784, Rich Brambley’s notes state: “Do not place [swap] space on other storage – do not place the vswap on VMFS. Follow best practices and keep the swap on the NFS storage.”

So, who’s right here? VMware or NetApp? I suppose the conservative thing is to keep the swap on VMFS until VMware tells us otherwise, with the only negatives being the increased operational complexity and reduced storage utilization - that’s what I’m doing. I can’t help but wonder if this is like VMware’s Linux timekeeping recommendations, though - conflicting information subject to change - and hopefully clarification - at a later date.

Suppose, for example, that you have a FAS2050; the maximum size FlexVol that you can dedupe is 1 TB. If the volume has ever been larger than 1 TB and then shrunk below that limit, it can’t be deduped, and, of course, you can’t grow a volume with A-SIS enabled beyond 1 TB. Fair enough, you say - but consider those limitations in the case of a volume where you aren’t sure how large it will eventually grow.

If you think your volume could eventually grow beyond 1 TB (deduped), and you’re getting a healthy 50% savings from dedupe you’ll actually need to undo A-SIS at 500GB. If you let your deduped data approach filling a 1TB volume, you will not be able to run “sis undo” - you’ll run out of space. TR-3505 has this to say about it:

Note that if sis undo starts processing and then there is not enough space to undeduplicate, it will stop, complain with a message about insufficient space, and leave the flexible volume dense. All data is still accessible, but some block sharing is still occurring. Use “df –s” to understand how much free space you really have and then either grow the flexible volume or delete data or Snapshot copies to provide the needed free space.

Bottom line: Either be absolutely sure you won’t ever need to grow your volume beyond the A-SIS limitations of your hardware platform, or run “sis undo” before the sum of the “used” and “saved” columns of “df -s” reaches the volume limit.

Postscript: If you were thinking - like I was - that ONTAP 7.3 would up the A-SIS limitations, apparently you need to think again.