Creating Server Connection Definitions (Vnodes)
Server Connection Definitions (Virtual Nodes)
To connect to a remote instance, you can specify all the required information dynamically in the connection string.
If you do not use the dynamic method, you must define a Server Connection Definition (also known as a virtual node, or vnode).
A vnode is a name defined on the local instance to identify a particular remote instance. The definition contains connection data and authorization data for a remote instance.
Using vnodes is generally simpler for users because they only have to enter a single, user-friendly vnode name when they run an application, rather than detailed network-specific connection information. Another advantage of vnodes is that network changes can be updated for a vnode without notifying the user or changing the application.
Tools for Defining Vnodes
You can define vnode names and their corresponding connection data entries and remote user authorizations using one of these tools:
• Director
• Network Utility (ingnet)
• Visual DBA (available on Windows only)
• Net Management Utility (netutil)
Naming Rules for Vnodes
Valid vnode names cannot include:
• Double colons (::)
• Slashes (/)
• Commas (,)
Vnode names are not case-sensitive.
Connection Data
The Connection data specifies the network address of the remote node, the listen address of the remote instance’s Communications Server, and the network protocol that is used to make the connection.
The Connection data has the following items:
Type
Specifies type of connection, either global or private.
Net Address
Identifies the network address or name of the remote node.
Your network administrator specifies this address or name when the network software is installed. Normally, the node name as defined at the remote node is sufficient for the node address.
Protocol
Specifies the keyword for the protocol used by the local node to connect to the remote node. Use the keyword tcp_ip.
Listen Address
Identifies the unique identifier used by the remote Communications Server for interprocess communication. See
Listen Address Format.
Just as the vnode name identifies an instance on the network, the listen address identifies a process (the Communications Server) in the remote instance.
Network Address Format
The network address in a TCP/IP environment has the following format:
host_name | ip_address
where:
host_name
Is the name of the remote node in character form
ip_address
Is the internet address of the remote node in the following format:
For IPv4: d.d.d.d (For example: 123.45.67.89) dotted decimal
For IPv6: x:x:x:x:x:x:x:x (For example: fe80::208:dff:fe7c:fecd%3) colon-hexadecimal
Listen Address Format
A listen address is a unique identifier used for interprocess communications. A Communications Server has two kinds of listen addresses. It uses one to receive messages from local processes and the other to receive messages from remote Communications Servers.
This section describes the format of the listen address used to receive messages from remote processes when the network protocol is TCP/IP.
Note: To view or change your instance’s listen addresses, use the Configuration-By-Forms (cbf) utility or Configuration Manager (vcbf).
When you install Ingres Net on a machine that is using the TCP/IP protocol, the listen address has two possible formats, as follows:
ax[n]
or
ppppp
where:
a
Is an alphabetic character (case is not significant)
x
Is an alphabetic character or a decimal digit (0-9)
n
Is a numeric digit from 0 - 7, inclusive
p
Is a numeric digit. The range depends on your operating system. For specific details, see your operating system documentation.
The format ax[n] is the default format, where ax is the instance ID (found in II_INSTALLATION) and n = 0. The digit n is incremented by 1 for each successive Communications Server started in an installation. For example, if the installation has three Communications Servers using the default format for their listen addresses, the addresses are ax0, ax1, and ax2.
Simple and Advanced Vnodes
Virtual nodes are classified as simple or advanced. A simple vnode is one in which there is only one set of login and connection parameters associated with it. An advanced vnode is one in which there is more than one connection data definition and/or up to two login data definitions.
Advanced Vnode Parameters
You can maintain up to two login data definitions for each vnode. If the first definition has been defined as private, the other login must be global (and vice versa). A global entry is available to all users on the local instance. A private entry is available only to the user who creates it.
If one of the login data definitions is private and the other is global, the vnode is considered to be an advanced vnode. A vnode is also considered to be an advanced vnode if it has more than one connection data definition and/or has one or more vnode attribute definitions.
Multiple Connection Data Entries
If a remote instance has more than one Communications Server or can be accessed by more than one network protocol, that information can be included in the vnode definition by adding another connection data entry. This allows you to distribute the load of communications processing and increase fault tolerance.
Note: When more than one Communications Server listen address is defined for a given vnode, Ingres Net automatically tries each server in random order until it finds one that is available. Similarly, when a connection fails over one network protocol, Ingres Net automatically attempts the connection over any other protocol that has been defined.
End users can create private connection data for an existing vnode by adding an entry to the Connection Data table. For the user who creates it, a private connection data entry overrides a global connection data entry defined to the same vnode. In other words, Ingres Net uses the private connection data entry whenever the user who created the entry uses the vnode.
You need the following information before adding a connection data entry:
• The network address of the node on which the remote instance resides
• The listen address of the remote instance’s Communications Server. (For the correct listen address format for your network protocol, see the appropriate appendix or check the Configure Net Server Protocols screen in the Configuration-By-Forms utility on the remote instance.)
• The keyword for the network protocol that is used to make the connection.
Additional Remote User Authorization
End users can create a private remote user authorization for an existing vnode.
For the user who creates it, a private authorization overrides a global authorization defined to the same vnode. Ingres Net uses the private authorization whenever that user uses the vnode.
Vnode Attributes Configuration
In addition to login and connection data, you can configure additional vnode attributes.
For a description of each attribute and its associated values, see
Vnode Attribute Names and Values.
Vnode Attribute Names and Values
Valid vnode attribute names and values are as follows:
connection_type
Abbreviation: conntype
Indicates how the connection is to be established. Valid values are:
default
Establishes a standard connection. In general, this means the connection is established between the client application process and the remote instance using the Net protocol.
comsvr
Establishes the connection using the Communications Server in the local instance, where it is then routed across the network.
direct
Establishes a direct connection with the server in the remote instance without using Net. This attribute improves performance because data goes directly from the application process on the client machine to the DBMS process on the server machine, thus bypassing Communications Server processing, except for initial connection setup.
For direct access to occur, the following conditions must be met:
• The client and server machines must be the same platform type (for example, both Windows, or both Linux, or Windows to Linux on Intel-based machines) and the environment variable II_CHARSET must be identical on both the client and server machines.
• The same network protocol must be used for the local IPC on the client and server machines.
• On Windows, the client and server machines must be logged into the same Windows network domain if using (default) named pipes for local IPC.
• On any platform which uses the IPC protocol for local and network connections, the environment variable, II_GC_REMOTE must be set (for the DBMS Server instance) to ON or ENABLED to allow direct connections. For important information on network security and II_GC_REMOTE, see the Vector System Administrator Guide.
• Between Windows and Linux, II_GC_PROT is set to tcp_ip on Windows, and the Linux system is running TCP/IP for its local protocol.
Note: II_GC_PROT should be changed only when Vector (including tools such as IVM) is completely shut down; otherwise, failures will occur for Vector shutdown, startup, and connection requests.
• A client installation should not be at a higher major release level than the Vector server. The reverse configuration works: An older release Vector client can directly access a newer release Vector server.
encryption_mode
Abbreviation: emode
Specifies the encryption mode for the connection. If set, this value overrides the Communications Server’s ob_encrypt_mode parameter value configured using Configuration Manager or the Configuration-By-Forms utility. The local and remote Communications Servers must be able to negotiate a common mechanism to perform the encryption.
Valid values are:
off
(Default) No encryption. The connection fails if the remote Communications Server encryption mode is ON.
optional
Abbreviation: opt
Encryption occurs if the remote Communications Server encryption mode is PREFERRED or ON and a compatible encryption mechanism is available.
preferred
Abbreviation: pre
Encryption occurs if a compatible encryption mechanism is available unless the remote Communications Server encryption mode is OFF. No warning is given if encryption is not possible.
on
Encryption occurs unless no compatible encryption mechanism is available or if the remote Communications Server encryption mode is OFF. Connection fails if encryption is not possible.
Note: The ON setting replaces REQUIRED, which is deprecated, but available for backward compatibility.
encryption_mechanism
Abbreviation: emech
Specifies the mechanism to be used to encrypt the remote connection. If set, this value overrides the Communications Server’s ob_encrypt_mech parameter value configured using Configuration Manager or the Configuration-By-Forms utility. Valid values are:
none – Disables encryption
* – Allows all encryption mechanisms to be considered during Communications Server negotiations
mechanism_name – Indicates a specific mechanism to be considered during Communications Server negotiations
compression_type
Abbreviation: compress
Specifies the compression type to be used on the connection. Only a single compression type is supported, so current values simply allow compression to be enabled or disabled. Valid values are:
none or off – Disables compression
default or on – Enables compression using the default compression type
authentication_mechanism
Specifies the mechanism to be used for remote authentication in a distributed security environment. This setting replaces the need for a user ID and password. If set, this value overrides the Communications Server’s remote_mechanism parameter value configured using Configuration Manager or the Configuration-By-Forms utility. The only valid value is kerberos.
character_set
Abbreviation: charset
Specifies the character set used on the remote instance. This attribute is necessary when connecting a UTF8 configured client instance with an older version remote instance that is not configured as UTF8 and the connection cannot be established because a common communication character set cannot be negotiated. Valid values are any character set names that can be used in the II_CHARSET environment variable.
Installation Password Definitions for the Local Instance
Users can access a remote Ingres or Vector instance using a login account set up on the remote instance’s host machine, or through an Installation Password, which allows users direct access to the instance. The Installation Password is configured for the local instance containing the databases that remote users want to access.
Detailed steps for this procedure can be found in the Procedures section of online help for Network Utility and Visual DBA. See the online topic Adding an Installation Password.
Changing Installation Passwords
Changing installation passwords requires special care. Because of caching of information on the client and server, installation passwords must be changed at least 30 minutes after the last use of Ingres Net. Failure to do this can cause connections to fail with “E_GC0141_GCN_INPW_INVALID.”