HP Archive Backup System for OpenVMS Guide to Operations

HP Archive Backup System for OpenVMS Guide to Operations HP Archive Backup System for OpenVMS Guide to Operations

h71000.www7.hp.com
from h71000.www7.hp.com More from this publisher
06.11.2014 Views

Architecture 11.1 The Server Process 11.1.1.2 Becoming a DB Server Note: The DECnet node name is terminated at the "::" if present. Valid TCP/IP node names: nabsco-12.cxo.dec.com nabsco-12[.cxo.dec.com]: nabsco-12[.cxo.dec.com]:2501 nabsco-12[.cxo.dec.com]:2501-2510 Because the database server list is processed from left to right one can control the order by which server nodes are tried and which network to use. Choosing a network at this point is unrelated to how the node’s transport is defined in the MDMS database.The requesting node and the contacted node must have the network for this server entry enabled otherwise the contact fails and the server continues on with the next entry in the list. The failed attempt is logged in the MDMS server logfile (“MDMS$LOGFILE_LOCATION:MDMS$LOGFILE_.LOG” or “MDMS$LOGFILE_LOCATION:MDMS$LOGFILE_DBSERVER.LOG”). The MDMS server tries to match an entry in the database server list with one of its own network name definitions. The network name definitions are obtained by retrieving the following values or translating logicals: • SCSNODE sysgen parameter • SYS$NODE for DECnet, stripping off the trailing “::” • SYS$NODE_FULLNAME for DECnet-Plus, stripping off the trailing “::” • {UCX|TCPIP}$INET_HOST and {UCX|TCPIP}$INET_DOMAIN for TCP/IP, concatenating the two strings using a dot “.” in between • MDMS$SERVER, if none of the above are available If the server finds a match it tries to open the database files. If it successfully opens all the database files it declares itself the database server. Because the files are opened for exclusive write and shared read, no other MDMS server can open the database files after that. A server remains to be a database server until it exits. At this point the database files are closed and the domain is without a database server until the next server has successfully opened the database files. If the server finds the files already open it continues on with the search for a DB server. 11.1.1.3 Finding another DB Server When contacting another server, the server passes all its network names on to the other node. If the other node happens to be a DB server it verifies that the requesting node is defined in the MDMS database. Only when all the node’s network names are defined in the node’s object the DB server grants access to the requesting node. Otherwise the DB server returns a MDMS_NODENOTENA (“node not in database or not fully enabled”). Once the node is granted access to the DB server the node updates its setting from the database. At this point the TRANSPORT setting of the node is in use. For example it is possible that a server contacted the DB server via DECnet but when it updates its TRANSPORT setting it is only allowed to use TCPIP. So from that point on this server only uses TCPIP to “talk” to the DB server. Typically all nodes in a domain have the same definition of MDMS$DATABASE_SERVER in their MDMS$SYSTARTUP.COM. But the definitions do not have to match. For example each node could list itself first in the list to give a more round-robin behavior. 11-2 Architecture

11.1.1.4 Failover of the DB Server 11.1.1.5 Role of the DB server Architecture 11.1 The Server Process Once a MDMS server loses contact to the DB server it starts to search for a new DB server using its own search list in MDMS$DATABASE_SERVER. The server tries the whole search list three times. The search for the DB server finally ends with either: a. the node became the DB server itself b. the node found another DB server c. the request failed with MDMS_NODBACC (“no access to database server”) Once a new DB server has been established, all nodes start to forward requests to this server. The DB server receives all user requests in an MDMS Domain. It coordinates all activities and accesses the MDMS database files. The DB server uses a write through cache to access the database. All database files are RMS index-sequential files and their key layout is defined by “.FDL” (File Definition Language) files in MDMS$SYSTEM. Most user requests can be executed entirely on the DB server. In some cases the DB server has to send remote requests to other servers in the domain. For example remote load volume requests or remote scheduling requests. 11.1.2 Server Communications An MDMS server can establish three types of listeners: • The Mailbox Listener • The DECnet Listener • The TCP/IP Listener The Mailbox Listener is always enabled. The server receives user request through its mailbox described by logical MDMS$MAILBOX. Each user process has its own mailbox to receive the response from the server. The DECnet Listener is enabled during server startup if DECnet is available on this node indicated by the existence of logical name SYS$NODE or logical SYS$NODE_FULL_NAME. Once the server had access to the database and DECNET is not defined in its TRANSPORT setting the server shuts down the DECnet Listener. The TCPIP Listener is enabled during server startup if TCP/IP is available on this node indicated by the existence of logical names {UCX|TCPI}$INET_HOST and {UCX|TCPI}$INET_DOMAIN. Once the server had access to the database and TCPIP is not defined in its TRANSPORT setting the server shuts down the TCPIP Listener. Startup and shutdown of the listeners is logged in the MDMS server logfile. Also the “MDMS SHOW SERVER” display shows the current servers network names at the top and its current TRANSPORT setting which reflects the active network listeners. Even though a DB server has received a request via DECnet it could use TCPIP to request a remote operation (e.g. load volume) at a third node. It all depends on the TRANSPORT setting of the individual nodes. Architecture 11–3

11.1.1.4 Failover of the DB Server<br />

11.1.1.5 Role of the DB server<br />

Architecture<br />

11.1 The Server Process<br />

Once a MDMS server loses contact <strong>to</strong> the DB server it starts <strong>to</strong> search <strong>for</strong> a new DB server using<br />

its own search list in MDMS$DATABASE_SERVER. The server tries the whole search list three<br />

times. The search <strong>for</strong> the DB server finally ends with either:<br />

a. the node became the DB server itself<br />

b. the node found another DB server<br />

c. the request failed with MDMS_NODBACC (“no access <strong>to</strong> database server”)<br />

Once a new DB server has been established, all nodes start <strong>to</strong> <strong>for</strong>ward requests <strong>to</strong> this server.<br />

The DB server receives all user requests in an MDMS Domain. It coordinates all activities and<br />

accesses the MDMS database files. The DB server uses a write through cache <strong>to</strong> access the database.<br />

All database files are RMS index-sequential files and their key layout is defined by “.FDL”<br />

(File Definition Language) files in MDMS$SYSTEM.<br />

Most user requests can be executed entirely on the DB server. In some cases the DB server has <strong>to</strong><br />

send remote requests <strong>to</strong> other servers in the domain. For example remote load volume requests<br />

or remote scheduling requests.<br />

11.1.2 Server Communications<br />

An MDMS server can establish three types of listeners:<br />

• The Mailbox Listener<br />

• The DECnet Listener<br />

• The TCP/IP Listener<br />

The Mailbox Listener is always enabled. The server receives user request through its mailbox<br />

described by logical MDMS$MAILBOX. Each user process has its own mailbox <strong>to</strong> receive the<br />

response from the server.<br />

The DECnet Listener is enabled during server startup if DECnet is available on this node indicated<br />

by the existence of logical name SYS$NODE or logical SYS$NODE_FULL_NAME.<br />

Once the server had access <strong>to</strong> the database and DECNET is not defined in its TRANSPORT setting<br />

the server shuts down the DECnet Listener.<br />

The TCPIP Listener is enabled during server startup if TCP/IP is available on this node indicated<br />

by the existence of logical names {UCX|TCPI}$INET_HOST and<br />

{UCX|TCPI}$INET_DOMAIN. Once the server had access <strong>to</strong> the database and TCPIP is not<br />

defined in its TRANSPORT setting the server shuts down the TCPIP Listener.<br />

Startup and shutdown of the listeners is logged in the MDMS server logfile. Also the “MDMS<br />

SHOW SERVER” display shows the current servers network names at the <strong>to</strong>p and its current<br />

TRANSPORT setting which reflects the active network listeners.<br />

Even though a DB server has received a request via DECnet it could use TCPIP <strong>to</strong> request a<br />

remote operation (e.g. load volume) at a third node. It all depends on the TRANSPORT setting<br />

of the individual nodes.<br />

Architecture 11–3

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!