This topic includes a specific configuration example of ADNR. This example assumes that the z/OS® Load Balancing Advisor solution is installed.
In Figure 1, two systems, SYSA and SYSB, are in a sysplex. The z/OS Load Balancing Advisor solution is configured and deployed in the sysplex, with the Advisor and ADNR running on SYSB and an Agent running on both SYSA and SYSB. The TN3270E Telnet server and FTPD are active on both systems. ADNR manages a name server in the network.
The following example shows an ADNR configuration file. The numbers in the left margin were added for annotation purposes and are used in the description that follows the example. This example configuration does not use subplexing or AT-TLS.
001 debug_level 7 # Error, Warning, Event
002
003 uuid mycorp_sysplex_adnr
004
005 dns network_name_server # Label used by other stmts
006 # and commands
007 {
008 dns_id 10.1.10.55 # Network name server
009
010 zone mvsplex.mycorp.com_zone
011 # Label used by other stmts
012 # and commands
013 {
014 domain_suffix mvsplex.mycorp.com
015 # Zone name in name server
016 } # end of zone
017
018 } # end of dns
019
020 gwm z/os_lba_advisor
021 {
022 gwm_id 10.1.5.1..3860 # LBA lb_connection_v4 address
023 host_connection_addr 10.1.10.11 # Local address
024 } # end of gwm
025
026 host_group production_sysplex
027 # Addrs available to intranet
028 {
029 host_group_name prodplex # Prepended to domain suffix
030 dns network_name_server # Name server to update
031 zone mvsplex.mycorp.com_zone
032 # Determines zone suffix for
033 # this group
034 # (mvsplex.mycorp.com)
035
036 member # sysa.mvsplex.mycorp.com,
037 # and
038 # prodplex.mvsplex.mycorp.com
039 {
040 host_name sysa # Prepended to domain suffix
041 ipaddrlist sysa_vipa_addrs
042 ipaddrlist sysa_non_vipa_addrs
043 }
044
045 member # sysb.mvsplex.mycorp.com,
046 # and
047 # prodplex.mvsplex.mycorp.com
048 {
049 host_name sysb # Prepended to domain suffix
050 ipaddrlist sysb_vipa_addrs
051 ipaddrlist sysb_non_vipa_addrs
052 }
053
054 } # end of host_group
055
056 ipaddrlist sysa_vipa_addrs
057 {
058 ipaddr 10.1.1.22
059 } # end of ipaddrlist
060
061 ipaddrlist sysa_non_vipa_addrs
062 {
063 ipaddr 10.1.10.22 # OSA on sysa
064 } # end of ipaddrlist
065
066 ipaddrlist sysb_vipa_addrs
067 {
068 ipaddr 10.1.1.1
069 } # end of ipaddrlist
070
071 ipaddrlist sysb_non_vipa_addrs
072 {
073 ipaddr 10.1.10.1 # OSA on sysb
074 } # end of ipaddrlist
075
076 server_group tn3270_group # TN3270E Telnet servers
077 {
078
079 port 23 # TN3270E Telnet server port
080 protocol TCP # Protocol for this port
081 server_group_name ztelnet # Prepended to domain suffix
082 dns network_name_server # Name server to update
083 zone mvsplex.mycorp.com_zone
084 # Determines zone suffix for
085 # this group
086 # (mvsplex.mycorp.com)
087 member # telnetprimary.ztelnet.mvsplex.mycorp.com
088 # and,
089 # ztelnet.mvsplex.mycorp.com
090 {
091 server_name telnetprimary # Prepended to
092 # server_group_name.domain
093 # suffix
094 ipaddrlist sysa_vipa_addrs
095 }
096
097 member # telnetsecondary.ztelnet.mvsplex.mycorp.com
098 # and,
099 # ztelnet.mvsplex.mycorp.com
100 {
101 server_name telnetsecondary # Prepended to
102 # server_group_name.domain
103 # suffix
104 ipaddrlist sysb_vipa_addrs
105 }
106 } # end of server_group
107
108 server_group ftp_group # FTP daemons
109 {
110
111 port 21 # FTP port
112 protocol TCP # Protocol for this port
113 server_group_name zftp # Prepended to domain suffix
114 dns network_name_server
115 # Name server to update
116 zone mvsplex.mycorp.com_zone
117 # Determines zone suffix for
118 # this group
119 # (mvsplex.mycorp.com)
120 member # zftp.mvsplex.mycorp.com
121 {
122 ipaddrlist sysa_vipa_addrs
123 ipaddrlist sysb_vipa_addrs
124 }
125 } # end of server_group - Line 1:
In this example ADNR configuration file, the debug level is set to 7 in the optional debug_level statement on line 1. The value of 7 is the default value, so this statement is redundant but is shown for completeness. At the default level of 7, messages are written to the log if they are at error, warning, or event level. Messages at other debug levels, such as info or debug, are not written to the log file.
- Line 3:
The uuid statement on line 3 uniquely identifies this ADNR from all other ADNR instances and external load balancers. In this example, it is a character string giving some useful information about the location of the ADNR application.
- Line 5:
There is one name server that ADNR will manage in this example, which is represented by the dns statement on line 5. The statement is given a label of network_name_server that is used for references from other statements, like host_group and server_group, and might be used in display commands. This dns statement is referenced on lines 30, 82, and 114.
- Line 8:
The dns_id keyword within the dns statement on line 8 tells ADNR how to reach the name server. The name server configured is at address 10.1.10.55, listening on port 53. The port is not explicitly specified because the default port is being used.
- Line 10:
The zone keyword within the dns statement on line 10 indicates which zones ADNR manages at the name server indicated on the dns_id keyword. There can be multiple zone keywords in this statement. However, in this example, only one zone is managed by ADNR in this name server. The zone keyword has the label mvsplex.mycorp.com_zone, which is used for references from other statements like host_group and server_group. In this example, the zone is referenced on lines 31, 83, and 116.
- Line 14:
The domain_suffix keyword within the zone keyword on line 14 assigns the domain suffix to be used for all updates to the zone. In this example, the domain suffix of mvsplex.mycorp.com is appended to the host names that ADNR creates when it adds resource records to the name server. In this example, one of the resource records added to the name server is ztelnet.mvsplex.mycorp.com. Because the zone keyword containing this domain suffix is under the dns statement representing the name server at 10.1.10.55, this implies that the name server at 10.1.10.55 is configured as the primary master name server for the mvsplex.mycorp.com domain.
- Line 20:
The gwm statement on line 20 describes how ADNR communicates with the GWM. The gwm statement has a label of z/os_lba_advisor.
- Line 22:
The gwm_id keyword on line 22 identifies the IP address and port on which the GWM is listening for connections from load balancers. In this example, the GWM is located at 10.1.5.1 and is listening on port 3860 for load balancer connections. The port of 3860 on the gwm_id keyword does not need to be specified because that is the default port for this keyword. However, it is explicitly coded in this example for clarity. ADNR establishes a long-lived TCP connection to the GWM.
- Line 23:
The host_connection_addr keyword of the gwm statement on line 23 identifies the source IP address that ADNR uses when connecting to the GWM. The host_connection_addr keyword is optional if you are using AT-TLS. In this example, 10.1.10.11 is used. The GWM might require configuration to enable a load balancer to connect from this address. Because the Advisor is acting as the GWM, it requires either that the source IP address of all load balancers that connect to it appear in an access control list or that AT-TLS is used. This list is defined by the lb_id_list statement in the Advisor. Therefore, in this example, 10.1.10.11 must appear in the Advisor's lb_id_list statement to enable ADNR to connect to it.
- Line 26:
The host_group statement defines a set of IP addresses to potentially add to the ADNR-managed name server, which represents the hosts in the sysplex. They are used to map names for the hosts to IP addresses in the name server. This is one of the traditional uses of resource records in a name server. In this example, production_sysplex is the label for this host_group on line 26. This label can be used in display commands. There can be multiple host_group statements in an ADNR configuration file, although only one is shown in this example.
- Lines 29 and 31:
The host_group_name keyword identifies the DNS host name that is associated with all IP addresses identified in this host_group statement. The value of the host_group_name keyword, prodplex on line 29 in this example, is prepended to the domain suffix identified by the zone keyword of this host_group statement on line 31. In this example, all IP addresses identified by the ipaddrlist statements in this host_group statement have the potential to be added to the name server with the name prodplex.mvsplex.mycorp.com. The IP addresses that are actually added to the name server with this name are the intersection of all of the IP addresses identified in all ipaddrlist keywords in this host_group statement, with the addresses that exist in the union of all home lists in the sysplex. This assumes that an Agent is running on all systems in the sysplex. If an address is removed from the home list of a system in the sysplex (for example, using VARY TCPIP,,OBEYFILE), all resource records associated with that IP address are update-deleted from the ADNR-managed name server. Similarly, if an IP address is added to the home list of a system in the sysplex and that address is already represented in this host_group statement, one or more resource records with that IP address are update-added to the ADNR-managed name server. The number of resource records added depends upon ADNR configuration. Assuming that all IP addresses configured to this host group actually exist in the sysplex, the following resource records are added to the ADNR-managed name server (TTLs are omitted):
prodplex.mvsplex.mycorp.com IN A 10.1.1.22 prodplex.mvsplex.mycorp.com IN A 10.1.10.22 prodplex.mvsplex.mycorp.com IN A 10.1.1.1 prodplex.mvsplex.mycorp.com IN A 10.1.10.1Thus, the DNS name prodplex.mvsplex.mycorp.com can be used by a client to reach any system in the sysplex. Because there is no guarantee that a server is listening on each of these addresses, this DNS name should not be used by clients to connect to servers in the sysplex. This DNS name is probably most useful for utilities like ping and traceroute.
- Line 30:
The dns keyword in the host_group statement on line 30 identifies the name server that is to be updated for this host group. The dns keyword identifies this name server by the label network_name_server, which is a label on a dns statement (line 5 in this example). Thus, in this example, the names for this host_group statement are added to the name server located at 10.1.10.55.
- Line 31:
The zone keyword of the host_group statement on line 31 identifies the zone to which the names for this host group are to be added. In this example, the label mvsplex.mycorp.com_zone matches a zone keyword label in the dns statement on line 10. Because multiple zone keywords are possible in a dns statement, the zone within the dns statement must be identified from all host_group and server_group statements. The zone keyword in the host_group statement is how the domain suffix is determined for this host_group statement.
- Lines 36 and 45:
This host_group statement contains two member definitions on lines 36 and 45. Both of these member definitions are named members because they contain a host_name keyword. An unnamed member has no host_name keyword. You can code one unnamed member per host_group. However, if one is not coded, a virtual unnamed member is created for you. A virtual unnamed member contains the union of all IP addresses coded in named members within that host group. An explicitly coded unnamed member also contains the union of all IP addresses coded in the named members that belong to that host group, in addition to any IP addresses coded in the unnamed member itself. An explicitly coded unnamed member might be useful for configuring movable dynamic VIPAs that do not always belong to a specific host.
- Line 40:
The first member definition in this host_group statement contains the host_name keyword with a value of sysa. All IP addresses that are coded in this member belong to the sysa system. The value sysa of the host_name keyword on line 40 is prepended to the domain suffix for this host group to create the name sysa.mvsplex.mycorp.com. Assuming that all IP addresses configured to this member actually exist on sysa, the following resource records are added to the ADNR-managed name server (TTLs are omitted):
sysa.mvsplex.mycorp.com IN A 10.1.1.22 sysa.mvsplex.mycorp.com IN A 10.1.10.22Thus, the DNS name sysa.mvsplex.mycorp.com can be used to specifically connect to the sysa system. This name might be useful for ping or traceroute.
- Line 45:
The second member definition in the host_group statement on line 45 represents IP addresses that are to be associated with the sysb system, like the first member definition associated IP addresses with the sysa system. Assuming that all IP addresses configured to this member actually exist on sysb, the following resource records are added to the ADNR-managed name server (TTLs are omitted):
sysb.mvsplex.mycorp.com IN A 10.1.1.1 sysb.mvsplex.mycorp.com IN A 10.1.10.1Similar to the first member definition, the sysb.mvsplex.mycorp.com DNS name can be used to specifically connect to the sysb system.
- Lines 41, 42, 50, and 51:
The two ipaddrlist keywords in each of the two members of the host_group statement (lines 41, 42, 50, and 51) specify the IP addresses that belong to this host group. As this example shows, multiple ipaddrlist keywords are allowed and the group represents the union of all ipaddrlist statements in the host_group statement. Each ipaddrlist statement can contain multiple IP addresses, although this example has only one IP address per ipaddrlist statement. In this host_group statement, the two ipaddrlist keywords in the first member (lines 41 and 42) reference ipaddrlist statements with the labels sysa_vipa_addrs and sysa_non_vipa_addrs at lines 56 and 61, and the two ipaddrlist keywords in the second member (lines 50 and 51) reference the ipaddrlist statements with the labels sysb_vipa_addrs and sysb_non_vipa_addrs at lines 66 and 71. Thus, the IP addresses 10.1.1.22 and 10.1.10.22 are associated with this host group, as are the IP addresses 10.1.1.1 and 10.1.10.1, as reflected in the IP addresses associated with the name prodplex.mvsplex.mycorp.com as previously shown. Furthermore, the IP addresses of the first member, 10.1.1.22 and 10.1.10.22, are associated with system sysa, as reflected in the IP addresses associated with the name sysa.mvsplex.mycorp.com, and the IP addresses in the second member, 10.1.1.1 and 10.1.10.1, are associated with system sysb, as reflected in the IP addresses associated with the name sysb.mvsplex.mycorp.com.
- Lines 56, 61, 66, and 71:
This example shows four ipaddrlist statements, each with one IP address, at lines 56, 61, 66, and 71. There can be multiple ipaddrlist statements and each can have multiple IP addresses. Each ipaddrlist statement has a label that is referenced from host_group and server_group statements. The labels in this example are sysa_vipa_addrs, sysa_non_vipa_addrs, sysb_vipa_addrs, and sysb_non_vipa_addrs. This example shows only IPv4 addresses, but IPv6 addresses can also be coded in ipaddrlist statements. The sample ADNR configuration file shows examples of IPv6 addresses coded in ipaddrlist statements. The sample ADNR configuration file can be found in the EZBADNRC member of SEZAINST.
- Lines 58, 63, 68, and 73:
The ipaddr keyword on lines 58, 63, 68, and 73 identifies a single IP address to register. This example shows only IPv4 addresses, but IPv6 addresses can also be coded in ipaddrlist statements. The sample ADNR configuration file shows examples of IPv6 addresses coded in ipaddrlist statements. The sample ADNR configuration file can be found in the EZBADNRC member of SEZAINST.
- Lines 76 and 108:
This example shows two server_group statements; one at line 76 to represent the TN3270E Telnet servers in the sysplex, and the other at line 108 to represent the FTP daemons in the sysplex. The server_group statements are used to create DNS names in the name server that map to IP addresses, which can actually be used to reach an active instance of the server.
- Line 76:
The first server_group statement on line 76 is given the label tn3270_group. This label can be used in display commands. This group represents TN3270E Telnet servers in the sysplex.
- Line 79:
The port keyword on line 79 in the first server_group statement indicates the port that the TN3270E Telnet servers listen on, which is 23 in this example.
- Line 80:
The protocol keyword on line 80 in the first server_group statement indicates the protocol of the listening application (TCP or UDP). Because the TN3270E Telnet server is a TCP application, the value for this keyword is TCP.
- Line 81:
The server_group_name keyword on line 81 identifies the DNS host name that is associated with all IP addresses identified in this server_group statement. The value of the server_group_name keyword, ztelnet in this example, is prepended to the domain suffix identified by the zone keyword of this server_group statement. In this example, all IP addresses identified by the ipaddrlist statements in this server_group statement have the potential to be added to the name server with the name ztelnet.mvsplex.mycorp.com. The IP addresses that are actually added to the name server with this name are the intersection of all of the IP addresses identified in all ipaddrlist keywords in this server_group statement, with the addresses on which the server instances in the sysplex are available. In the case of TCP applications, this is the set of IP addresses that the servers are listening on, and for UDP applications, this is the set of IP addresses to which the servers are bound. This assumes that an Agent is running on all systems in the sysplex. The TN3270E Telnet server listens on INADDR_ANY, so in effect, it listens on all IP addresses available. If a server instance is stopped (or abnormally terminates), all resource records associated with that server instance are update-deleted from the ADNR-managed name server. Similarly, if a new server instance in that group is started and an IP address on which that server instance is available is already coded in the server_group statement, one or more resource records with that IP address are update-added to the ADNR-managed name server. The number of resource records added depends upon ADNR configuration. Assuming the TN3270E Telnet servers are running on sysa and sysb, the following resource records are added to the ADNR-managed name server (TTLs are omitted):
ztelnet.mvsplex.mycorp.com IN A 10.1.1.22 ztelnet.mvsplex.mycorp.com IN A 10.1.1.1Thus, the DNS name ztelnet.mvsplex.mycorp.com can be used to reach any available TN3270E Telnet server in the sysplex.
- Lines 82 and 83:
On lines 82 and 83, the dns and zone keywords of the server_group statement serve the same purpose as those keywords on the host_group statement.
- Lines 87 and 97:
There are two named members defined in the server_group statement on lines 87 and 97. Named members contain a server_name keyword, but unnamed members do not. As in host_group statements, you can code one unnamed member per server group. However, if one is not coded, a virtual unnamed member is created for you. A virtual unnamed member contains the union of all IP addresses coded in named members within that server group. An explicitly coded unnamed member also contains the union of all IP addresses coded in the named members that belong to that server group, in addition to any IP addresses coded in the unnamed member itself. The IP addresses in the unnamed member, whether explicitly coded or not, are associated with the group name. In this example, the IP addresses of the unnamed member for this server_group statement are associated with the name ztelnet.mvsplex.mycorp.com. Coding an explicit unnamed member without any named members might suffice for servers where affinity to a particular instance is not needed. Also, if an application instance is freely movable from one system to another, or from one TCP/IP stack to another, coding an unnamed member without any named members might be acceptable. In this case, code the DVIPAs on which the application could be reached in the unnamed member. If, however, it is important for clients to be able to connect to specific instances of a server, you must code separate named members for each instance.
- Line 91:
The first member definition in this server_group statement contains the server_name keyword with a value of telnetprimary at line 91. All IP addresses that are coded in this member are IP addresses that one instance of the TN3270E Telnet server could potentially be listening on. The value telnetprimary of the server_name keyword is prepended to the DNS name created for the server group to create the name telnetprimary.ztelnet.mvsplex.mycorp.com. Assuming that the IP address configured to this member actually exists on sysa, and that the TN3270E Telnet server is active on this system, the following resource record is added to the ADNR-managed name server (TTLs are omitted):
telnetprimary.ztelnet.mvsplex.mycorp.com IN A 10.1.1.22Thus, the DNS name telnetprimary.ztelnet.mvsplex.mycorp.com can be used to specifically connect to the TN3270E Telnet server instance on sysa.
- Line 97:
The second member definition in this server group on line 97 is similar to the first, with the exception that this member identifies an application instance on system sysb instead of the one on system sysa. Assuming that the IP address configured to this member actually exists on sysb, and that the TN3270E Telnet server is active on this system, the following resource record is added to the ADNR-managed name server (TTLs are omitted):
telnetsecondary.ztelnet.mvsplex.mycorp.com IN A 10.1.1.1Thus, the DNS name telnetsecondary.ztelnet.mvsplex.mycorp.com can be used to specifically connect to the TN3270E Telnet server instance on sysb.
- Line 108:
The second server_group statement on line 108 is similar to the server_group statement for the TN3270E Telnet servers, except that it represents FTP daemons in the sysplex. Thus, the value of the port keyword specifies the port number on which the FTP daemon listens. The server_group_name value specifies a name that is appropriate to a group of equivalent FTP daemons. This server group has one unnamed member and no named members. Thus, the resource records that can potentially be added to the name server are as follows:
zftp.mvsplex.mycorp.com IN A 10.1.1.22 zftp.mvsplex.mycorp.com IN A 10.1.1.1