FAQs and Myths for Storage Foundation Keys
FAQs and Myths for Storage Foundation Keys
Keys have gotten simpler, but explanations and awareness haven’t kept up
June 16, 2009To start, let’s review the difference between a license and a key, as the two terms are often (but incorrectly) used interchangeably. A license – a Storage Foundation end user license agreement (EULA) – is a legal contract between Symantec and a customer. An example of a EULA for Storage Foundation Basic is posted here. A Storage Foundation (SF) key is a 23 digit alphanumeric string that unlocks SF software for use, for example ‘A1BC-DE2F-3GHI-JKL4-M5N6-OP7‘. So a license is a legal contract, and a key is a cryptographic string that activates or enables software. Figure 1 further illustrates the situation.
SF, VCS and NBU use the same key infrastructure (known as SIG, for ‘Shared Infrastructure Group’) but SIG offers some latitude in specific behaviors, so this article’s scope is limited to Storage Foundation UNIX & Linux keys.
Node locking
Node locking refers to tying a key to a server’s unique hostid, so that the key to unlock SF on one host will not unlock SF on a different host. Node locking was removed from SF a couple of releases back (see Figure 2 for details). Customers using those old versions (and encountering added administration due to node locking) should be aware that current versions of SF are not node locked.Removing node locks allows for more operational consistency. Using the same key to unlock SF on both ‘server a’ and ‘server b’ increases data center standardization, which is usually desirable. Again, note the distinction between a license and a key. If you do not have a SF license for each server running SF, you (and your employer) are committing software piracy; a license cannot be ‘shared’ among multiple servers. In contrast, the same key can be used on multiple servers to simplify and standardize your operating environment.
Platform enforcement
SF is currently licensed on a per-platform basis, where a platform approximately corresponds to an {operating system, chip architecture} pair. SF keys are specific to a platform, so a Solaris SPARC key will not unlock SF on a Solaris x64 server – nor will it unlock SF on an AIX server. An exception is Linux keys, which work on both RHEL and on SuSE.Tiers
On AIX, HP-UX, and Solaris SPARC, SF is licensed for distinct server tiers. Tier 1 maps to entry level servers, and Tier 4 to the largest enterprise machines. Each SF license is only good for the Tier on which it was issued. In contrast, SF keys do not enforce / check for the machine tier. This is partly because the operating systems’ utilities to check server model are not always sufficient, and partly because server tiers are sometimes (albeit rarely) reclassified by Symantec. Note that in the past SF keys did enforce tier.On Linux, SF is licensed by number of CPUs, not by tier. From SF 4.0 onward, the key does not enforce CPU count; prior versions did. Solaris x64 is also licensed by CPU and current keys do not enforce CPU count.
Product enforcement (e.g., SF vs. SFRAC)
Within the SF and VCS family, Symantec markets several different products. Each product has a distinct combination of features and functionality, and each product is licensed separately. Examples include Storage Foundation, Storage Foundation Enterprise, Storage Foundation HA, Cluster File System, and Storage Foundation for Oracle RAC™. A key unlocks the features and functionality of its corresponding product. It does not unlock the features and functions of other products; in other words, keys do enforce a given product’s features. Mapping features to products is beyond the scope of this article.Compatibility between Keys and Software (Binary) Versions
Users often ask whether a version x key will work with SF version x+1; and also whether a version x key will work with SF version x-1. To better understand why this works in one direction but not in the other, it helps to understand that the key fits into a software ‘lock’. The lock decodes the key and, using the decoded information, enables functionality in Storage Foundation. The lock ships with and is updated with each new version of Storage Foundation. The lock is compatible with old keys, i.e., keys from prior versions, because the structure of old keys is known. In effect, the lock can be ‘shaped’ so that those old keys ‘fit’ the lock.In contrast, the structure of new keys is not known in advance; the lock cannot be ‘pre-shaped’ to anticipate what a key might or might not look like in the future. The upshot: older keys can be used with newer software versions, but new keys cannot generally be used with older software versions. There are two caveats.
First, an old key will unlock all the functionality of the product version it maps to, but new features may not be unlocked. From a user perspective, the features you used before the upgrade will continue to work using the old key. However, some new features in the new version may not work until you apply a new key.
Second, a new key may sometimes unlock an old version, but this is neither by intent nor by design. Do not rely on it to work, even if you have seen it work in the past. A full explanation of why it sometimes works would be lengthy, but it centers on adding new features.
Note that the above behavior is the same, even across the ELM-SIG “boundary”. SIG locks, introduced in 2002-2004, replaced the older “ELM” locks which had been used starting with Storage Foundation 2.x. But, to avoid customer disruption, SIG locks recognize and honor ELM keys. See Figure 2 for the version/platform detail when SIG replaced ELM.
Temporary keys
Temp keys unlock a product for a limited time period. Currently, the SF licensing system allows a single 30 day temp key to be installed, plus a single 60 day temp extension, for 90 days of total temp key time. Removing the temp keys does not ‘reset’ this 90 day cumulative limit. This is a change from SF’s old licensing system (ELM), which allowed temp keys to be repeatedly applied in perpetuity. For specific details on SIG and ELM versions, see Figure 2 at the end of this article.Key Additivity
People occasionally ask if the order of entry, or if specific key combinations, affect what gets unlocked. For example: “If I enter a permanent key first, then later enter a temp key for the same product, will the product stop working when the temp key expires?” or “If I enter a Cluster File System key, and then later enter a VCS key, will CFS stop working because VCS doesn’t enable CFS?”In this respect, keys are very simple. Keys are only additive, and the order in which keys are entered is irrelevant. Using database terminology, adding keys performs a union function. If an installed key unlocks a given product or feature, it stays unlocked regardless of any other keys added.
Myths
Myth #1 – “Only certain customers get Gold Keys.”In the past, Symantec (then Veritas) supplied some customers with “Gold Keys”. A Gold Key is a key that is not restricted by Tier, and is not node locked (but is still limited by product and by platform). As noted above, SF keys are no longer restricted by tier, and are no longer node locked. So, all SF keys are Gold Keys.
Myth #2 – “Symantec requires you to upgrade your key when upgrading to a new version of SF.”
Customers are not required to upgrade SF keys when upgrading the SF binaries to a new version. As noted above, old SF keys are recognized and accepted by new SF binaries. One benefit of upgrading the key is that it may unlock new features in the new binary. (Old keys rarely unlock new features, for the simple reason that when old keys are created, the new feature’s existence is not known, and thus isn’t coded into the key). Symantec Support may recommend upgrading keys to avoid future confusion over new features not being enabled by a new key.
Note: Upgrading to a new SF version requires a current support contract.
Myth #3 – “You have to remove the old keys / temp keys after installing a new key.”
Symantec does not require that old keys or temp keys be removed from a server. As noted above, keys are additive. So old keys and temp keys can be kept indefinitely. There are pros and cons either way. Keeping old keys eliminates the risk of accidentally removing the wrong key. But keeping old keys also clutters the output of reporting utilities.
Published 16 years ago
Version 1.0