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.
Part2. Internal communication channel configurations(Scale-out & System Replication)
This blog provides an overview of considerations and recommended configurations in order to manage internal communication channels among scale-out / system replications.
Before we get started, let me define the term of network used in HANA.
1. external(public) network : Channels used for external access to SAP HANA functionality by end-user clients, administration clients, application servers, and for data provisioning via SQL or HTTP
2. internal network : Channels used for SAP HANA internal communication within the database or, in a distributed scenario, for communication between hosts
For your information, having internal networks under scale-out / system replication is a mandatory configuration in your production sites.
Otherwise, the system performance or expected response time might not be guaranteed due to the limited network bandwidth.
Prerequisites:
* You have installed internal networks in each nodes.
* Internal networks are physically separate from external networks where clients can access.
* The “hostname” in below refers to “internal hostname” in Part1. Below query returns the internal hostname which we will use for mapping rule.
SELECT “HOST” as hostname FROM M_HOST_INFORMATION WHERE KEY = ‘net_hostnames’;
Internal Network Configurations in Scale-out :
There are configurations you can consider changing for internal networks.
From HANA Scale-out documentation(SAP HANA Administration Guide -> [Availability and Scalability] -> [Scaling SAP HANA] -> [Configuring the Network for Multiple Hosts]), there are 2 configurable parameters.
global.ini -> [communication] -> listeninterface : .global or .internal
global.ini -> [internal_hostname_resolution] :
mapping rule : internal_ip_address=hostname
1. .global
◈ Binds the processes to all interfaces.
◈ This option does not require an internal network address entry.(Default)
2. .internal
◈ Binds the processes to this address only and to all local host interfaces.
◈ This option requires an internal network address entry.
Above configurations are only required when you have internal networks. Otherwise, please ignore this section.
Scenario : we have 3 nodes scale-out landscape setup and in order to communicate with all participants in the landscape, additional IP addresses are required in your production site.
Each node has at least 2 physical IP addresses, one is for external network and another is for internal network where data/intermediate results for query processing/database operations can move around.
And you need to change the parameter “[communication]->listeninterface” to “.internal” and add internal network entries as followings.
For instance, you have 10.0.1.* as public network and 192.168.1.* as internal network as described below picture.
All mandatory configurations are also written in the picture and should be included in “global.ini”.
mapping rule : internal_ip_address=hostname
Internal Network Configurations in System Replication :
There are also configurations you can consider changing for system replications.
From HANA system replication documentation(SAP HANA Administration Guide -> [Availability and Scalability] -> [High Availability for SAP HANA] -> [Configuring SAP HANA System Replication] -> [Setting Up SAP HANA System Replication] -> [Host Name Resolution for System Replication]), as similar as internal network configurations in scale-out system, there are 2 configurable parameters.
global.ini -> [system_replication_communication] -> listeninterface : .global or .internal
global.ini -> [system_replication_hostname_resolution] :
mapping rule : system_replication_internal_ip_address=hostname
1. .global
◈ if no mappings specified(Default), the default network route is used for system replication communication. This is normally the public network.
◈ if mappings are specified as either neighboring sites(minimum) or all hosts of own site as well as neighboring sites, an internal(separate) network is used for system replication communication.
2. .internal
◈ need to specify all hosts of own site as well as neighboring sites
◈ A separate network is used for system replication communication. The primary hosts listen on the dedicated ports of the separate network only, and incoming requests on the public interfaces are rejected.
◈ 2 tier setup is supported but not for 3 tier
As you recognized, “.internal” setting is a subset of “.global” and “.global” is a default and “.global” supports both 2-tiers and 3-tiers. Therefore, I would highly recommend to stick with the default value “.global” in the parameter “[system_replication_communication]->listeninterface”
IMPORTANT : the parameters in the “global.ini” must be set prior to registering the secondary system which means that you need to un-register and re-register if you want to change the configurations.
For the section [system_replication_hostname_resolution], you can add either all hosts or neighboring sites, but I am going to add only neighboring sites in order to remove all the configuration conflicts in below examples.
mapping rule : system_replication_internal_ip_address=hostname
1. Single node and System Replication(2 tiers)
2. Single node and System Replication(3 tiers)
3. Scale-out and System Replication(2 tiers)
4. Scale-out and System Replication(3 tiers)
Usually, tertiary site is located geographically far away from secondary site. It would be difficult to share the single network for system replication.
Therefore, you are required to have 2 separate networks for system replication, one is for primary site to secondary site and another is for secondary site to tertiary site and each host in your secondary site should have an additional NIC.
No comments:
Post a Comment