blog.scottlowe.org

I’m relatively new to NetApp deduplication (formerly A-SIS), so this article won’t be an advanced treatise on NetApp deduplication or its deep inner workings. Instead, this is intended to be a quick guide to setting up NetApp deduplication for others, like myself, who may be familiar with Data ONTAP but not necessarily deduplication.

Obviously, the first step will be to ensure that your NetApp storage system is licensed for deduplication. As of March 10, NetApp made the NearStore option, which was a prerequisite for deduplication, free. Yes, you read that right: free. Since NearStore is a prerequisite, you’ll need to be sure to license that first:

license add <Code for NearStore>
license add <Code for Deduplication>

Once deduplication is licensed, then you can enable it on a per-volume basis using the “sis on” command:

sis on /vol/<volname>

Note, however, that the volume cannot exceed a certain size, based on the storage system model, in order for deduplication to work. These volume size limits are laid out in TR3505. Note that the volume must never have been any bigger than the size limits described, so this means you can’t size it down to the limits set forth and then run deduplication.

Once it’s running, you can check the status with:

sis status /vol/<volname>

After it’s finished running, you can see your space savings like this:

df -s /vol/<volname>

After running deduplication on a small NFS volume that housed only three VMs, the “df -s” command showed a space savings of 64%. That’s pretty impressive!

Moving forward, deduplication will run automatically every night at midnight, as shown by this command:

sis config /vol/<volname>

That should be enough to get most everyone started. Feel free to post comments or corrections below.

A niggling doubt about thin provisioned disks was placed in my head when I read Duncan’s article on a Storage VMotion problem; in that article, a statement is made that ESX Server 3.5 no longer supports thin provisioned disks. Intrigued by that comment, I started doing some digging to see if that was actually the case. I was unable to find any concrete statement one way or the other.

Some testing in my lab showed that with ESX Server 3.5, VMDKs are still thin provisioned by default when stored on an NFS datastore. So that put to rest the idea that thin provisioned disks had been abandoned, but now I was curious to follow up on the issue of how ESX Server handled cloning thin provisioned disks, as mentioned in Virtualization Short Take #1.

Additional testing showed that although the VMDKs are indeed thin provisioned at the beginning of their life, they won’t necessarily stay that way:

• Migration of the VMs files from one datastore to another, even if the destination datastore is also NFS, will cause the VMDKs to revert to thick (fully allocated) VMDKs.
• Clones made from the thin provisioned disks have thick provisioned VMDKs.
• A Storage VMotion operation will cause the disks to become fully allocated instead of thin provisioned.

This is a strong counterpoint to the arguments in favor of using NFS for your VMware storage in order to gain thin provisioned disks. In order to really take advantage of thin provisioned disks, every VM must be provisioned from scratch—no cloning within VirtualCenter—and you must give up Storage VMotion or cold migration of the VMDKs.

So far, I have not found any workaround for this behavior. If anyone knows of a workaround, please share it in the comments. (To be honest, I don’t really expect to find one.)

At the start of 2007, I wrote a pair of articles on Mac FTP/SFTP clients, lamenting the performance of the open source Cyberduck application and eventually settling on Interarchy as my replacement product.

Quite a bit has happened since that time, and I now find myself in a bit of a quandary. Cyberduck has replaced the underlying file transfer engine to dramatically improve overall throughput, and Interarchy has “refined” the user interface to make it look more Mac-like. Unfortunately, in the process, Interarchy has become downright ugly. I don’t like the ugly chiclet buttons in Leopard’s Finder, I don’t like them in Safari, and I don’t like them in Interarchy, either. I very much prefer “old school” color icons in the toolbars.

Given that the new Interarchy interface was really bugging me—the Finder, at least, is still usable when you turn off the sidebar and close the toolbar—I thought I’d try Cyberduck again. Simple, one-file performance tests showed that Cyberduck, with the option to transfer files via SCP enabled, was coming much closer to matching Interarchy’s performance; Interarchy remained in the lead for raw performance, however. I figured that I could live with the performance degradation for most tasks, and started trying to use Cyberduck whenever possible.

Until tonight, that was. I needed to transfer a large number of smaller files up to one of my web sites, and Cyberduck simply dragged. I guess it’s the method whereby Cyberduck manages connections that slowed down the process, since it appeared that it checked the connection to the server for each file it was transferring. In any case, I’ve found that it looks like I’ll just have to suffer through Interarchy’s new look; the alternative is just too slow.

If I had one complaint about being a Mac OS X user, it would be that there is no Visio equivalent on the Mac. Yes, OmniGraffle is an awesome program; this is especially true for version 5, which can open native Visio drawing (VSD) and shape (VSS) files. That one new feature was, to me, worth the upgrade price.

<aside>Note to OmniGroup developers: It would be really, really, REALLY helpful to do something with the Windows Metafile images that Visio uses instead of just replacing them with a gray rectangle. Do you have something up your sleeve to help with that? Perhaps a trick of which I am not aware?</aside>

OK, so I suppose a more accurate complaint is about a lack of shapes for OmniGraffle more so than anything else. Fortunately, I came across this link last night. Now, my need for high-quality NetApp shapes for OmniGraffle diagrams has been almost entirely satisfied. To the person that created these shapes and posted them, you have my sincere thanks!

Anyone else have any little gems like this they’d like to share with other readers?

Some time last week, one of my NetNewsWire subscriptions turned up an article titled “HP VirtualConnect” from Brent Ozar. It turns out that Brent’s blog, while heavily SQL Server-oriented, has a few nuggets of HP Blade information:

HP C-Class Blade Chassis Review
HP C-Class Blade Chassis Review Part 2: The Cisco/Brocade Interconnect Switches
HP Virtual Connect

Of course, Brent must be pretty smart since he linked back to my site…

Seriously, though, have a look at Brent’s HP c-Class articles for a good overview of the product and its associated technologies.

I received word this morning that Embotics, a maker of software intended to help manage the virtual machine lifecycle, had been selected to participate in the Microsoft Startup Accelerator Program. I’d never heard of this program, but it sounds interesting based on the Embotics press release:

Stewarded by the Emerging
Business Team (EBT) at Microsoft Corp., the program is designed to
connect high-potential startups committed to the Microsoft platform to
an extensive support network. This program provides access to Microsoft
people and programs, guidance on future directions and support to
accelerate their success.

Naturally, I assume this means that Embotics’ flagship product, V-Commander, is going to work well with Hyper-V once it becomes available later this year.

This announcement joins a number of other announcements in recent weeks by other vendors as well in support of Hyper-V, following Microsoft’s release of a release candidate last week. Some might interpret this as the beginning of a sea change in the virtualization market, further bolstered by HP’s integration of XenServer management (more information here as well). Is the tide turning against VMware? As more and more vendors announce support for XenServer and Hyper-V, the landscape for VMware becomes more competitive.

Within the last few days, VMware has released a beta version of the VI Toolkit for Windows, a set of PowerShell cmdlets that enable users to do some very useful, very powerful things with Microsoft’s new scripting language. Personally, I’ve never been a good programmer and so learning a new language like the PowerShell scripting language will take some time (something I have precious little of these days), but I do hope to be able to become more familiar with these tools and how to use them for my benefit and the benefit of my customers.

After a brief mention of this topic in Virtualization Short Take #4, the battle between Citrix, Microsoft, and VMware over memory overcommitment has heated up.

The latest round comes from VMware, who provides some real-world statistics on memory overcommitment. In addition, I’ll draw readers’ attention to this comment on VMware’s original article, in which a VMware customer describes the benefits his organization is seeing from memory overcommitment. (BTW, this commenter apparently also started a VMware Communities thread which was, in turn, the basis for this article by Duncan over at Yellow Bricks. My, what a tangled web we weave!)

In any case, VMware’s response uses real data from a customer; only the names have been changed to protect the innocent. In the case study, a 64GB server has been oversubscribed to support VMs requiring 89GB of RAM, and only 20GB of the server’s 64GB is actually in use. So, by reducing the RAM configured in the server, VMware comes up with a way to show that—in this very specific example, at least—it is cheaper to buy VMware than to add RAM to the server. Looks like they called Microsoft’s bluff:

If someone can show me a customer who is running, in production, a VMware VI3 Enterprise system with a 2:1 memory overcommit ratio on all the VMs, where spending the cost of VMware on RAM wouldn’t remove the need to use overcommitment then I’ll give… lets say $270 to their choice of charity.

Apparently, VMware feels they’ve met those criteria:

So, James, the charity of choice is One Laptop Per Child. And just in case you believe that we’ve cherry picked a use case we’ll be more than happy to connect you directly via phone to any one of the numerous customers we have leveraging memory overcommitment in their environment today.

Now things are really getting interesting. Stay tuned!

I’m posting this stuff here on the off chance that it someday might be useful to someone out there somewhere. About four years ago, I had a wild hunch to start learning Novell NetWare 6.5, and to perform some integration testing with some other technologies with which I was already familiar. Along the way, I gathered these notes. I make no warranties about the accuracy, validity, or relevance of this information; I’m just publishing it here in case it may prove useful later. (You never know.)

So, that being said, here are the notes:

• SSH “shell” access to NetWare 6.5 server: The SSHD NetWare Loadable Module (NLM) had to be loaded first. Attempts to login failed; the sshd_config file had to be edited and a Novell-specific directive (eDirNameContext) had to be modified in order to add the context where the admin account was stored (in this case, OU=Users.O=Company). After the configuration file was modified and the SSHD NLM unloaded and loaded again (to reflect the changes to the configuration file), logins via SSH were successful. (Note: It appears that NetWare 6.5 does not support the Blowfish-CBC cipher.)
• SFTP access to NetWare 6.5 server: After successful SSH “shell” access (see previous bullet point), SFTP access also worked correctly. Tests using Fugu (a native Mac OS X SFTP application) were successful and without any major events or problems. In fact, SFTP was used to transfer the files necessary for the VNC testing (see next bullet point) to the NetWare server.
• VNC access to NetWare 6.5 console: Using SFTP, a VNC server NLM was copied to the server. After setting the VNC password (using VNCPASS.NLM) and loading the VNC server (VNCSRV.NLM), access to the NetWare server’s GUI via VNC was successful. The VNC client used was Chicken of the VNC, a freeware Mac OS X VNC client. Performance was on par for LAN access to a server.
• Native file access from Mac OS X: As indicated in several online sources, the AFPTCP NLM had to be unloaded and then reloaded with the CLEARTEXT option. Then the SYS volume on the server could be mounted using the Go To Server command. After an initial login, the AFPTCP NLM was unloaded and reloaded without the CLEARTEXT option, and everything continued to work just fine.
• Rconsole access from Mac OS X: Using RconJ, a Java-based port of Rconsole to Mac OS X, Rconsole access was successful. The RCONAG6 NLM had to be loaded first on the server in order for this to work.
• VNC inside SSH tunnel: Creating SSH tunnels (using the –L switch) works in NetWare 6.5 just as it does with Linux or OpenBSD. Using the VNC NLM discussed earlier and an SSH tunnel, the VNC traffic was secured and encrypted across the wire. This worked exactly as expected.
• Native file access from Windows XP: Initial attempts to access the server from a Windows XP system failed (authentication problems). The NDS user object had been created in iManager and a simple password had also been created in iManager as well (necessary before CIFS will work). However, the cifsctxs.cfg file (that specifies contexts) had not been updated with the correct context (OU=Users.O=Company, which is where all user objects are stored). After modifying this file and reloading CIFS, then access from Windows XP still failed (network path not found). Further tests showed that typing the UNC path from the Run command on the Start menu failed, but browsing through My Network Places or typing the UNC path including a share name worked just fine.
• NTP on NetWare 6.5: XNTPD.NLM is an NTP daemon for NetWare, similar in implementation and purpose as NTP on Linux or OpenBSD. Upon editing the NTP.CONF file in SYS:\ETC, XNTPD could be loaded only after TIMESYNC.NLM was unloaded. Even then, XNTPD seemed to unload occasionally and without reason, and the NTPDATE utility had to be used to manually synchronize the time.
• Autoloading specific NLMs on startup: Upon reboot, the VNC, SSH, and Rconsole NLMs weren’t loaded, and so the server was inaccessible except from the console. Using the “rconag6 encrypt” command, a LDRCONAG.NCF file was created with an encrypted Rconsole password. Then, AUTOEXEC.NCF was edited to reference this file (in order to load the Rconsole agent) as well as the SSH and VNC NLMs. This would ensure that the necessary NLMs were loaded every time the server booted.
• Universal passwords: After some difficulty mounting a volume from Mac OS X, setting passwords, and such, the server was rebooted and Universal Passwords were enabled for the Users.Company container. The passwords were then set for various accounts. Following that, native file access from both Mac OS X and Windows XP (with one caveat; see below) worked flawlessly. The caveat for Windows XP native file access is that browsing shares using just the server name in the UNC path does not work; at least one share name must also be included (i.e., \vsninteg does not work, but \vsninteg\sys works just fine). SSH access worked fine after enabling universal passwords. SFTP access worked fine as well, as long as the user logging in had sufficient permissions.

OK, there you go. Here’s hoping it may prove useful to someone. Feel free to correct me, clarify these notes, or just tell me I’m crazy in the comments below.

Reader Jeffrey Spear contacted me a while back with some problems he was experiencing in trying to integrate some Linux systems into Active Directory. Basically, Kerberos was working but LDAP wasn’t. He was able to use “kinit <AD username>” to generate a Kerberos ticket, but using the “getent passwd <AD username>” was not working. No error messages, nothing; it just didn’t work.

We traded e-mails back and forth for a while, and eventually he found the solution himself:

We work with a locked down version of OSs and in this case a domain policy on the Windows server was preventing the RHEL machines from accessing account info.  The policy was “Domain controller: LDAP server signing requirements” which was set to “Require signature.”  When I changed this setting to “None” it worked great.

This is good information and important to keep in mind; I’ll be sure to incorporate this into the next revision of the Linux-AD integration instructions. (No, I don’t have a timeframe on when that will be!)

In the meantime, if anyone has a workaround for this problem that will allow LDAP to work with signatures enabled or required, I’d love to hear it. Speak up in the comments below!