Introduction
Although various materials and documents for HANA networks have been available to ease your implementations and re-configurations, you might have found it time-consuming and experienced a hard time to see a whole picture at a glance.
Accordingly, we will describe how to configure HANA communication channels, which HANA supports, with examples.
This blog contains 2 Parts.
1. Public communication channel configurations
2. Internal communication channel configurations(Scale-out & System Replication)
Part1. Public communication channel configurations
During the execution of SQLs that include table accesses, customer's applications communicate with SAP HANA through various Client Libraries, such as JDBC, ODBC, or SQLDBC.
While you are reading this page, you will meet several configuration changes. I am going to demonstrate test results with a HANA system in the below topology environment.
Terminology:
Public Hostname Resolution:
A SQL client library on application side, firstly connects to SAP HANA using host names specified in connection strings.
Then, the HANA host sends back a list of all the hosts(Topology Information) with locations of tables and partitions in the HANA system to the client library. Especially, in distributed systems, this topology information is used for the purpose of load balancing.
By default, IP addresses of primary network interfaces on the hosts are returned to the client library.
Depending on network environments, you may need to have different entries into the topology. They can be IP addresses, FQDNs(Fully Qualified Domain Name), hostnames, of the primary network interfaces, internal hostnames of hosts, or IP addresses of another network interface configured in hosts.
In order to meet such requirements, SAP HANA provides two parameters under [public_hostname_resolution] section in global.ini and they are 'use_default_route' and 'map_<internal_hostname>'.
You can also get the information in the 'Host Name Resolution for SQL Client Communication' section of SAP HANA Administration Guide.
IMPORTANT: The two parameters of the [public_hostname_resolution] section determine what will be sent to client libraries on application side. Then, applications will create connections to hosts in the HANA system using that information and those are expressed as 'net_publicname' in HANA.
No matter what becomes 'net_publicname' on each HANA host, that MUST BE resolved on application side and routed from client libraries to each HANA host.
Please, read the rest of this blog carefully, so a configuration set, that suits your network environment, is determined.
How to verify current environment:
In order to know what information is returned to the client library with the current configurations, query the monitoring view 'SYS.M_HOST_INFORMATION'.
You can use the statement "SELECT "HOST","KEY","VALUE" FROM SYS.M_HOST_INFORMATION WHERE KEY = 'net_publicname'" and the 'VALUE' column of 'net_publicname' tells what we need.
Default Route Mechanism:
global.ini -> [public_hostname_resolution] -> use_default_route = ip, fqdn, name, or no
Mapping Hostnames for Database Client Access:
If change to the 'use_default_route' doesn't fit your requirements, network mapping should be specified.
Available Configuration Options & Expected Results:
You might have a requirement that Database Administration and Business Application's Networks are separated, and that can be implemented with parameters described in this blog.
Please, see the below example.
NOTE : When HANA Cockpit connects to tenant DBs, HANA Cockpit, firstly, accesses to the SYSTEM DB to request connection information of tenant DBs. Then, the SYSTEM DB returns topology information of the requested tenant DBs using 'net_publicname'.
Conclusion:
You might be planning to install a HANA instance or already running several HANA systems. Either case, SAP HANA's hostname resolution feature provides flexibility and various configuration options to meet your requirements and adapt to your changing network environments. This series of blogs will help you draw network architectures at a glance.
Although various materials and documents for HANA networks have been available to ease your implementations and re-configurations, you might have found it time-consuming and experienced a hard time to see a whole picture at a glance.
Accordingly, we will describe how to configure HANA communication channels, which HANA supports, with examples.
This blog contains 2 Parts.
1. Public communication channel configurations
2. Internal communication channel configurations(Scale-out & System Replication)
Part1. Public communication channel configurations
During the execution of SQLs that include table accesses, customer's applications communicate with SAP HANA through various Client Libraries, such as JDBC, ODBC, or SQLDBC.
While you are reading this page, you will meet several configuration changes. I am going to demonstrate test results with a HANA system in the below topology environment.
[The landscape of the test HANA system]
- Scale-out System : 3Nodes
- Default Host Name : s1host1 / s1host2 / s1host3
- Internal Host Name(ERP QA System) : erp_qa1 / erp_qa2 / erp_qa3
[The content of /etc/host files on all the 3hosts]
## Default Hostnames configured at OS level
10.0.1.11 s1host1.sap.corp.com s1host1
10.0.1.12 s1host2.sap.corp.com s1host2
10.0.1.13 s1host3.sap.corp.com s1host3
## Internal Hostnames(ERP QA System)
10.0.1.11 erp_qa1.sap.corp.com erp_qa1
10.0.1.12 erp_qa2.sap.corp.com erp_qa2
10.0.1.13 erp_qa3.sap.corp.com erp_qa3
Terminology:
- Default Host Name : The default host names that defined at operating system level. The installation extracts the host names known to the operating system.
- Internal(Virtual) Host Name : Internal(Virtual) Host Names are host names that are entered during the installation of SAP HANA. Internal host names could differ from Default Host Names. Configured host names can retrieved at OS as seen below.
[Hostname Location at OS level]
/usr/sid/<SID>/HDB<instance_number>/<hostname>/sapprofile.ini
[An example of looking up internal host names]
s1host1:/usr/sap/<SID>/HDB00> ll
total 52
.......
.......
drwxr-x--- 9 adm sapsys 198 Aug 7 09:35 erp_qa1
drwxr-x--- 9 adm sapsys 169 Jul 5 13:58 erp_qa2
drwxr-x--- 9 adm sapsys 169 Jul 5 13:58 erp_qa3
.......
.......
.......
s1host1:/usr/sap/<SID>/HDB00> cat erp_qa1/sapprofile.ini | grep SAPLOCALHOST
SAP_RETRIEVAL_PATH = $(DIR_INSTANCE)/$(SAPLOCALHOST)
SAPLOCALHOST=erp_qa1
s1host1:/usr/sap/<SID>/HDB00> cat erp_qa2/sapprofile.ini | grep SAPLOCALHOST
SAP_RETRIEVAL_PATH = $(DIR_INSTANCE)/$(SAPLOCALHOST)
SAPLOCALHOST=erp_qa2
s1host1:/usr/sap/<SID>/HDB00> cat erp_qa3/sapprofile.ini | grep SAPLOCALHOST
SAP_RETRIEVAL_PATH = $(DIR_INSTANCE)/$(SAPLOCALHOST)
SAPLOCALHOST=erp_qa3
- Primary Network Interface : The network interface with the default route.
It can be retrieved with the Linux commands as seen below.
s1host1:/usr/sap/<SID>/HDB00> gw_if=`ip route list match 0.0.0.0 | awk '{print $5}'`
s1host1:/usr/sap/<SID>/HDB00> ip addr show dev ${gw_if}
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP qlen 1000
link/ether 00:00:00:00:00:00 brd ff:ff:ff:ff:ff:ff
inet 10.0.1.11/22 brd 10.0.1.255 scope global eth0
inet6 :: : : :/64 scope link
valid_lft forever preferred_lft forever
Public Hostname Resolution:
A SQL client library on application side, firstly connects to SAP HANA using host names specified in connection strings.
[An example of a connection string]
jdbc:sap://erp_qa1:30015;erp_qa2:30015;erp_qa3:30015/Then, the HANA host sends back a list of all the hosts(Topology Information) with locations of tables and partitions in the HANA system to the client library. Especially, in distributed systems, this topology information is used for the purpose of load balancing.
By default, IP addresses of primary network interfaces on the hosts are returned to the client library.
Depending on network environments, you may need to have different entries into the topology. They can be IP addresses, FQDNs(Fully Qualified Domain Name), hostnames, of the primary network interfaces, internal hostnames of hosts, or IP addresses of another network interface configured in hosts.
In order to meet such requirements, SAP HANA provides two parameters under [public_hostname_resolution] section in global.ini and they are 'use_default_route' and 'map_<internal_hostname>'.
You can also get the information in the 'Host Name Resolution for SQL Client Communication' section of SAP HANA Administration Guide.
IMPORTANT: The two parameters of the [public_hostname_resolution] section determine what will be sent to client libraries on application side. Then, applications will create connections to hosts in the HANA system using that information and those are expressed as 'net_publicname' in HANA.
No matter what becomes 'net_publicname' on each HANA host, that MUST BE resolved on application side and routed from client libraries to each HANA host.
Please, read the rest of this blog carefully, so a configuration set, that suits your network environment, is determined.
How to verify current environment:
In order to know what information is returned to the client library with the current configurations, query the monitoring view 'SYS.M_HOST_INFORMATION'.
You can use the statement "SELECT "HOST","KEY","VALUE" FROM SYS.M_HOST_INFORMATION WHERE KEY = 'net_publicname'" and the 'VALUE' column of 'net_publicname' tells what we need.
Default Route Mechanism:
global.ini -> [public_hostname_resolution] -> use_default_route = ip, fqdn, name, or no
- IP(Default Value) : IP address of the interface with the default route
- fqdn : FQDN of the interface with the default route
- name : host name of the interface with the default route
- no : Disable feature and use internal host name
Mapping Hostnames for Database Client Access:
- Pattern Mapping
- global.ini -> [public_hostname_resolution] -> map_<internal-prefix>* = <public-prefix>*<public-suffix>
-- Host Name Pattern Mapping
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa*')='erp_qa_test*' with reconfigure;
-- IP Pattern Mapping
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa*')='192.168.222.20*' with reconfigure;
- global.ini -> [public_hostname_resolution] -> map_<internal-prefix>* = <public-prefix>*<public-suffix>
- 1:1 Mapping
- global.ini -> [public_hostname_resolution] -> map_<internal-name> = <public-name>
-- 1:1 Host Name Mapping
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa1')='erp_qa_test1' with reconfigure;
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa2')='erp_qa_test2' with reconfigure;
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa3')='erp_qa_test3' with reconfigure;
-- 1:1 IP Mapping
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa1')='192.168.222.201' with reconfigure;
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa2')='192.168.222.202' with reconfigure;
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa3')='192.168.222.203' with reconfigure;
- global.ini -> [public_hostname_resolution] -> map_<internal-name> = <public-name>
If change to the 'use_default_route' doesn't fit your requirements, network mapping should be specified.
Available Configuration Options & Expected Results:
- use_default_route = ip(Default Value) / No Hostname Mapping
- Statements for configuration change
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','use_default_route')='ip' with reconfigure;
- Confirm Configuration Change
- If you don't find a use_default_route entry, it means 'use_default_route' is set as 'ip'.
- Confirm Configuration Change
- Verify configuration change
- Statements for configuration change
- use_default_route = name / No Hostname Mapping
- Statements for configuration change
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','use_default_route')='name' with reconfigure;
- Confirm Configuration Change
- Confirm Configuration Change
- Verify configuration change
- Statements for configuration change
- use_default_route= fqdn / No Hostname Mapping
- Statements for configuration change
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','use_default_route')='fqdn' with reconfigure;
- Confirm Configuration Change
- Confirm Configuration Change
- Verify configuration change
- Statements for configuration change
- use_default_route= no / No Hostname Mapping
- Statements for configuration change
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','use_default_route')='no' with reconfigure;
- Confirm Configuration Change
- Confirm Configuration Change
- Verify configuration change
- Statements for configuration change
- use_default_route = name / 1:1 Hostname Mapping
- Statements for configuration change
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','use_default_route')='name' with reconfigure;
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa1')='192.168.222.201' with reconfigure;
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa2')='192.168.222.202' with reconfigure;
alter system alter configuration('global.ini','system') set ('public_hostname_resolution','map_erp_qa3')='192.168.222.203' with reconfigure;
- Confirm Configuration Change
- Confirm Configuration Change
- Verify configuration change
- As the above result, hostname mapping has the higher priority than Default Route Mechanism.
- Statements for configuration change
Case Study - Separating DBA and Application Networks:
You might have a requirement that Database Administration and Business Application's Networks are separated, and that can be implemented with parameters described in this blog.
Please, see the below example.
- Requirements
- You want your HANA system multi-tenant and have a tenant DB(DB1) where your business application S/4 HANA runs.
- You want to have separate Database Administration(DBA) and Application(S/4 HANA) networks by subnetting technique.
- They are completely isolated and can't communicate each other.
- Each network has its own DNS server.
- You want to use the hostname 's1host1' to access to the HANA system in DBA network and the hostname 'erp_qa1' in application network.
- The landscape of the test environment
- HANA Server Side
[The test HANA system]
- Databases in the MDC : SYSTEM DB / DB1
- Configurations under [public_hostname_resolution]
- use_default_route=name
- 2NIC(Network Interface Card)s & assigned IP addresses
- IP address(NIC1) : 10.0.1.11
- IP address(NIC2) : 192.168.1.11
[The content of the '/etc/host' file on the host]
## Default Hostnames configured at OS level(DBA Network)
10.0.1.11 s1host1.sap.corp.com s1host1
## Internal Hostnames(S/4 HANA Application Network)
192.168.1.11 erp_qa1.sap.corp.com erp_qa1
- Client Side
[HANA Cockpit]
- IP Address : 10.0.1.100
- A list of hosts registered at DNS in the network(10.0.1.*)
10.0.1.11 s1host1
10.0.1.11 erp_qa1 * This entry is required to access to the tenant DB1 through the DBA network. Please, refer to the below NOTE for detail.
[S/4 HANA Application]
- IP Address : 192.168.1.100
- A list of hosts registered at DNS in the network(192.168.1.*)
192.168.1.11 erp_qa1
- HANA Server Side
- At this point...
- Your S/4 HANA application is communicating and working well with HANA.
- You can connect to SYSTEM DB using HANA Cockpit.
- You can connect to the tenant DB1 using HANA Cockpit.
- Please, refer to the below NOTE.
NOTE : When HANA Cockpit connects to tenant DBs, HANA Cockpit, firstly, accesses to the SYSTEM DB to request connection information of tenant DBs. Then, the SYSTEM DB returns topology information of the requested tenant DBs using 'net_publicname'.
- Why the entry '10.0.1.11 erp_qa1' was added to the DNS in the Application Network.
- Now, we know 'net_publicname' is 'erp_qa1' because 'use_default_route' is set to 'name' and 'erp_qa1' is the internal hostname.
- As you can see in the above NOTE, 'erp_qa1' is returned to the HANA Cockpit and HANA Cockpit tries to connect to the tenant DB using 'erp_qa1'.
- Because the HANA Cockpit cannot resolve the name 'erp_qa1' other than 's1host1', the connection attempts will fail.
- Therefore, the hostname 'erp_qa1' has to be resolved by the host, on which the HANA Cockpit resides.
- As the host where HANA Cockpit is in the network of '10.0.1.*', the hostname 'erp_qa1' has to be resolved as '10.0.1.11'.
- There are various ways to configure it.(e.g. DNS, /etc/hosts on Linux/OS, and C:\Windows\System32\Drivers\etc\hosts on Windows/OS)
Conclusion:
You might be planning to install a HANA instance or already running several HANA systems. Either case, SAP HANA's hostname resolution feature provides flexibility and various configuration options to meet your requirements and adapt to your changing network environments. This series of blogs will help you draw network architectures at a glance.
- SAP Managed Tags:
3 Comments
