Like in SAP ABAP or Java based system the Hardware key is decided based on the server which run the message server/service, to know the hardware key we can find it from SLICENSE tcode from SAP or we can execute the command with sap admin user $>saplicense -get
Something similar we expect from HANA Database system, but so far there is no way we can get the HANA hardware key from any command at OS level.
There are two methods known, in both cases the Database should be in open state, means either we or Hana Studio can connect to the database.
We can check the Hardware Key from HANA Studio as follows: Right click the HANA system -> Properties -> License.
Other method is by using SQL Console and execute any of the following SQL command:
SELECT * FROM M_LICENSE
SELECT HARDWARE_KEY, PRODUCT_NAME FROM M_LICENSE
Now the question is “Why can't we determine the Hardware Key with a single command at OS?”
To answer this, lets first find out the scenario when HANA Database Hardware Key changes even in the case when there is no change in hardware and hostname with same configuration:
- Re-installation
- Restore or Recovery
- Rename
These all event will change hardware key.
For new installation or re-installation a new landscape ID will be generated.
During recovery the landscape id of the installation (from the nameserver.ini) will be written into the data volumes (persistency) of the nameserver (topology.ini)
...this is new!
In SAP we have seen that Hardware Key is mostly govern by some form of command output of uname or MAC address of Network Card etc, in other word it is mostly hardware intensive, except Windows uses a hardware key that does NOT depend on the hardware.
With the old SAP NetWeaver approach there was an extra work in case of HA (High Availability) configuration, we need to install more than one SAP license based on different failover location of message server, though the hostname remains the same hardware key changes.
In HANA if you have a standby Node or distributed Node the Hardware Key is stored in global directory, which is common for all (worker, standby) node.
This approach gives our answer; SAP is now generating single Hardware Key for one system; one SID - one Hardware Key - one License Key! Regardless of the SID consisting more than one host/server in form of Worker Node/Standby Node/Primary Node/Secondary Node/Tertiary Node so login at OS level of one server cannot tell us the overall Hardware Key for a Hana system. |
|---|
You can view the encrypted hardware key information at this location
/usr/sap/<SID>/SYS/global/hdb/custom/config/nameserver.ini
The first line under [landscape] is the Hardware Key information. For example,
[landscape]
id = xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxx
As this is not the exact key we see through HANA Studio, I am guessing it is encrypted and most probably merged with further information like SID etc.
This convinces us that for worker and standby we don't have to worry about applying different license for individual server.
But here is the best part.....
If you have replication setup, even with 3 level of replication. The global directory will be different for replication server.
If we compare the hardware key ID in nameserver.ini it will be same !!!
When the replication is setup the process modifies the file nameserver.ini and includes an extra line for idsr.
This extra line you will not notice on Primary server file.
Here is the screenshot where replication is setup with Primary and its Standby to Secondary with its Standby
Fig. [Primary server and its Standby Node]
Fig. [Secondary server and its Standby Node]
Next time if you break the replication between Primary and Secondary server. and check the Hardware Key and License Key on both server through HANA Studio you will find same Hardware Key with same license.
if for some reason the ID will change in nameserver.ini after disabling the replication. You will get this error and your HANA Database will not start:
comment file contains: nameserver: landscape ID mismatch between nameserver.ini/[landscape]/id (xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx) and topology.ini (yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy)
As we cannot reach the physical topology.ini file change the value of nameserver.ini equals to the value shown for topology.ini, of course after taking the backup of nameserver.ini file. To read more about topology.ini you can refer Who moved my topology.ini
It is not advisable to manually change the landscapeid in nameserver.ini
(but while I was getting ID mismatch error I manually changed it, and it worked for me, do it on your own risk!)
A new landscape ID can be forcefully generated by removing the ID from nameserver.ini and use the following command
hdbnsutil -convertTopology
After this, a new landscape id will be generated in nameserver.ini and imported into the topology.ini.
To read my other blogs please follow this link:
ishteyaque.ahmad
References:
174911 - Determining the hardware key (customer key)
1644792 - License key/installation of SAP HANA platform edition
1899480 - How to handle HANA Alert 31: 'License expiry'
- SAP Managed Tags:
1 Comment
