problem in albd and rpc server
736 views
Skip to first unread message
micky
Jan 29, 2008, 2:56:15 AM1/29/08
to ClearCase
hi all,
can any one give me the full white paper of albd , rpc and other
server which all used in clear case .please help me out.
thanking you,
Roland
can any one give me the full white paper of albd , rpc and other
server which all used in clear case .please help me out.
thanking you,
Roland
Anand Mehta
Jan 30, 2008, 3:53:00 PM1/30/08
to Clea...@googlegroups.com
you can find everything in the AdminGuide pdf.
ClearCase Server Processes
ClearCase is a distributed application. Many of its operations involve several host
computers and several server processes on each host. This section introduces the
ClearCase server processes.
For the most part, these servers do not need to be explicitly configured, started,
stopped, or managed. The information in this section is intended to help you
understand status and error messages that may be generated by these servers, to access
server logs, and to get a better idea of the role each server process plays in a ClearCase
network.
Two server processes— albd_server and admin_server—run on every host that has
been configured to support local VOBs and views, regardless of whether any VOBs or
views have been created on the host. Other server processes are started as necessary to
manage any VOBs and views that reside on the host.
Note: ClearCase LT clients cannot be configured with support for local VOBs or views.
No ClearCase server processes run on a ClearCase LT client host or on a ClearCase host
that has been configured with no support for local VOBs and views.
albd_server
The albd_server handles a variety of tasks on hosts configured to support local VOBs
and views:
Starting and stopping other ClearCase services as needed.
Setting up network communications between ClearCase clients and servers.
Managing execution of tasks run by the ClearCase scheduler.
Chapter 1 - ClearCase Network Planning and Administration 9
Responding to requests for registry information on a ClearCase registry server
host.
Responding to requests for licenses on a ClearCase license server host.
(ClearCase LT does not use the albd_server in this way.)
On UNIX hosts, responding to load-balancing queries from a remote clearmake
process. (This feature is not supported on ClearCase LT.)
When you start ClearCase, the albd_server starts first, and runs with one of the
following user identities:
root on UNIX
The built-in LocalSystem identity on ClearCase LT on Windows
A specially created privileged user account on ClearCase on Windows
When you stop ClearCase, the albd_server stops all ClearCase services on the host and
then exits.
Note: On a ClearCase LT client or a ClearCase client configured without support for
local VOBs and views, the albd_server is not installed, and there are no other
ClearCase services to stop or start.
When a client program wants to access a service (a VOB or view server, for example)
on a ClearCase server host, it uses a remote procedure call (RPC) to send a request to
the albd_server process on that host. The albd_server starts the requested service if it
is not already started, then issues a response telling the client the service's port number.
Thereafter, the client communicates directly with the specific service, without
involving the albd_server.
ClearCase services started by the albd_server generally run with the identity of the
resource (VOB or view) owner on UNIX and with the identity of the albd_server on
Windows.
Port Assignment
The albd_server listens for RPCs on a well-known port (port 371) that has been
reserved for it by the Internet Assigned Numbers Authority. ClearCase installation
verifies that no other service uses this port for UDP or TCP communications. If a
conflict is detected, we recommend that you modify the conflicting service to use
another port. If you cannot reconfigure or remove the conflicting service, you must
configure the albd_server to use a different UDP port.
On UNIX, edit the local host's services database and/or the NIS services map.
10 Administrator's Guide: Rational ClearCase and Rational ClearCase LT
On Windows, create the appropriate entry in the
file%SystemRoot%\System32\drivers\etc\services. (If there is no entry for the
albd_server in this file, it will use port 371.)
Note: All albd_server processes in a community must use the same port number. If you
change the albd_server port assignment on any ClearCase host, you must change it on
every ClearCase host.
The albd_server reads configuration file albd.conf during startup to determine which
services to provide. Do not modify this file.
admin_server
The ClearCase administration server (admin_server) is invoked as needed by the
host's albd_server process. This short-lived server performs miscellaneous
administrative support functions:
Retrieving server log files for display by the getlog command and the ClearCase
Administration Console.
Retrieving and changing the local host's ClearCase properties when requested by
the ClearCase Administration Console.
Moving registry files and reconfiguring clients if the host is a backup registry
server.
credmap_server
The credentials mapping server credmap_server runs on any ClearCase host that is
configured to support local VOBs and views. This server handles credentials mapping
in environments where users access a common set of VOBs and views from both UNIX
and Windows computers. For more information, see Credentials Mapping on page 56.
view_server
A view_server is a long-lived process that manages activity in a particular view. A
view_server is started by the host's albd_server process whenever a client requests
access to a view. A view_server remains active until it is terminated by a cleartool
endview –server command, a system shutdown, or an operating system command
that terminates the view_server process.
When it begins execution, a view_server reads configuration information from
the .view file in the view-storage directory. Values in this file are established by
mkview, chview, and similar commands. Do not modify this file with a text editor.
vob_server
For each VOB, a long-lived vob_server process runs on the VOB host. The vob_server
manipulates data in the VOB's storage pools in response to requests from client
processes.
The vob_server is the only process that ever creates or deletes VOB data containers;
only the VOB owner or a privileged user can modify VOB data containers and storage
pools. For more information, see The VOB Storage Directory on page 105.
A vob_server process is started as needed by albd_server. It remains active until any
of the following events occur:
The VOB is removed with the rmvob command.
ClearCase is stopped on the VOB server host.
The VOB server host is shut down and restarted.
When it begins execution, the vob_server reads configuration information from the file
vob_server.conf in the VOB storage directory. Values in this file are established by the
vob_snapshot_setup utility and other commands. Do not modify this file.
db_server
A host's db_server processes manage VOB database transactions on that host in
response to requests from client programs. Because client programs cannot access VOB
databases directly, they must send database transaction requests to a db_server process
when they need to create, read, or modify VOB data or metadata.
Each db_server process services a single client at a time, but can operate on any
number of VOBs. A client establishes a connection to a db_server with the help of the
albd_server on the VOB host. If necessary, the albd_server starts a new db_server
process to handle a request. The connection is broken when the client exits or becomes
idle (stops requesting database transactions for an extended period). At that point, the
db_server becomes available for use by another client. After a period of idleness, an
unconnected db_server is terminated by its host's albd_server.
vobrpc_server
Each VOB server host runs one or more vobrpc_server processes for each of its VOBs.
Each vobrpc_server process handles requests from view_server processes throughout
the network. These requests can generate both metadata (VOB database) and file
system data (storage pool) activity. The vobrpc_server accesses the VOB database in
the same way as a db_server; it forwards storage pool access requests to the
vob_server.
vobrpc_server processes are started by albd_server, which also routes new requests to
the least-busy servers and terminates unneeded vobrpc_server processes when the
system is lightly loaded.
lockmgr
Each VOB server host runs one lock manager process, lockmgr, which arbitrates
transaction requests to all VOB databases on that host. The calling program polls
lockmgr, which either grants or prohibits access to the requested data. If the data is
available, the transaction proceeds immediately: the data is read or written, and output
is returned to the calling program. If the data is unavailable (locked because another
caller has been granted write access to the data), the caller waits until lockmgr grants
it access to the data.
Unlike most other ClearCase services, the lockmgr is not started by the albd_server.
Instead, it is started when the VOB host starts. Lock manager startup options can be
changed if necessary to improve VOB server performance for certain configurations.
For more information, see Modify Lock Manager Startup Options on page 291.
rwp
The Rational Web Platform rwp provides application support for the ClearCase Web
interface. RWP servers are normally configured at install time and need no further
administrative attention unless special configurations (for example, a configuration to
support access by proxy) are required. A ClearCase community may have one or more
rwp servers. For more information, see Appendix C.
Server Logs
Each ClearCase server process maintains a log on the host where it runs. Because an
error returned by a command entered on the local host can generate a log entry on a
remote host, ClearCase on UNIX provides two remote log retrieval tools: the cleartool
getlog command and the Server Logs node of the ClearCase Administration Console.
(On Windows, ClearCase server processes write to the local host's Windows event log,
which can be viewed with the Windows event viewer on any Windows host.)
Regards,
-Anmev
ClearCase Server Processes
ClearCase is a distributed application. Many of its operations involve several host
computers and several server processes on each host. This section introduces the
ClearCase server processes.
For the most part, these servers do not need to be explicitly configured, started,
stopped, or managed. The information in this section is intended to help you
understand status and error messages that may be generated by these servers, to access
server logs, and to get a better idea of the role each server process plays in a ClearCase
network.
Two server processes— albd_server and admin_server—run on every host that has
been configured to support local VOBs and views, regardless of whether any VOBs or
views have been created on the host. Other server processes are started as necessary to
manage any VOBs and views that reside on the host.
Note: ClearCase LT clients cannot be configured with support for local VOBs or views.
No ClearCase server processes run on a ClearCase LT client host or on a ClearCase host
that has been configured with no support for local VOBs and views.
albd_server
The albd_server handles a variety of tasks on hosts configured to support local VOBs
and views:
Starting and stopping other ClearCase services as needed.
Setting up network communications between ClearCase clients and servers.
Managing execution of tasks run by the ClearCase scheduler.
Chapter 1 - ClearCase Network Planning and Administration 9
Responding to requests for registry information on a ClearCase registry server
host.
Responding to requests for licenses on a ClearCase license server host.
(ClearCase LT does not use the albd_server in this way.)
On UNIX hosts, responding to load-balancing queries from a remote clearmake
process. (This feature is not supported on ClearCase LT.)
When you start ClearCase, the albd_server starts first, and runs with one of the
following user identities:
root on UNIX
The built-in LocalSystem identity on ClearCase LT on Windows
A specially created privileged user account on ClearCase on Windows
When you stop ClearCase, the albd_server stops all ClearCase services on the host and
then exits.
Note: On a ClearCase LT client or a ClearCase client configured without support for
local VOBs and views, the albd_server is not installed, and there are no other
ClearCase services to stop or start.
When a client program wants to access a service (a VOB or view server, for example)
on a ClearCase server host, it uses a remote procedure call (RPC) to send a request to
the albd_server process on that host. The albd_server starts the requested service if it
is not already started, then issues a response telling the client the service's port number.
Thereafter, the client communicates directly with the specific service, without
involving the albd_server.
ClearCase services started by the albd_server generally run with the identity of the
resource (VOB or view) owner on UNIX and with the identity of the albd_server on
Windows.
Port Assignment
The albd_server listens for RPCs on a well-known port (port 371) that has been
reserved for it by the Internet Assigned Numbers Authority. ClearCase installation
verifies that no other service uses this port for UDP or TCP communications. If a
conflict is detected, we recommend that you modify the conflicting service to use
another port. If you cannot reconfigure or remove the conflicting service, you must
configure the albd_server to use a different UDP port.
On UNIX, edit the local host's services database and/or the NIS services map.
10 Administrator's Guide: Rational ClearCase and Rational ClearCase LT
On Windows, create the appropriate entry in the
file%SystemRoot%\System32\drivers\etc\services. (If there is no entry for the
albd_server in this file, it will use port 371.)
Note: All albd_server processes in a community must use the same port number. If you
change the albd_server port assignment on any ClearCase host, you must change it on
every ClearCase host.
The albd_server reads configuration file albd.conf during startup to determine which
services to provide. Do not modify this file.
admin_server
The ClearCase administration server (admin_server) is invoked as needed by the
host's albd_server process. This short-lived server performs miscellaneous
administrative support functions:
Retrieving server log files for display by the getlog command and the ClearCase
Administration Console.
Retrieving and changing the local host's ClearCase properties when requested by
the ClearCase Administration Console.
Moving registry files and reconfiguring clients if the host is a backup registry
server.
credmap_server
The credentials mapping server credmap_server runs on any ClearCase host that is
configured to support local VOBs and views. This server handles credentials mapping
in environments where users access a common set of VOBs and views from both UNIX
and Windows computers. For more information, see Credentials Mapping on page 56.
view_server
A view_server is a long-lived process that manages activity in a particular view. A
view_server is started by the host's albd_server process whenever a client requests
access to a view. A view_server remains active until it is terminated by a cleartool
endview –server command, a system shutdown, or an operating system command
that terminates the view_server process.
When it begins execution, a view_server reads configuration information from
the .view file in the view-storage directory. Values in this file are established by
mkview, chview, and similar commands. Do not modify this file with a text editor.
vob_server
For each VOB, a long-lived vob_server process runs on the VOB host. The vob_server
manipulates data in the VOB's storage pools in response to requests from client
processes.
The vob_server is the only process that ever creates or deletes VOB data containers;
only the VOB owner or a privileged user can modify VOB data containers and storage
pools. For more information, see The VOB Storage Directory on page 105.
A vob_server process is started as needed by albd_server. It remains active until any
of the following events occur:
The VOB is removed with the rmvob command.
ClearCase is stopped on the VOB server host.
The VOB server host is shut down and restarted.
When it begins execution, the vob_server reads configuration information from the file
vob_server.conf in the VOB storage directory. Values in this file are established by the
vob_snapshot_setup utility and other commands. Do not modify this file.
db_server
A host's db_server processes manage VOB database transactions on that host in
response to requests from client programs. Because client programs cannot access VOB
databases directly, they must send database transaction requests to a db_server process
when they need to create, read, or modify VOB data or metadata.
Each db_server process services a single client at a time, but can operate on any
number of VOBs. A client establishes a connection to a db_server with the help of the
albd_server on the VOB host. If necessary, the albd_server starts a new db_server
process to handle a request. The connection is broken when the client exits or becomes
idle (stops requesting database transactions for an extended period). At that point, the
db_server becomes available for use by another client. After a period of idleness, an
unconnected db_server is terminated by its host's albd_server.
vobrpc_server
Each VOB server host runs one or more vobrpc_server processes for each of its VOBs.
Each vobrpc_server process handles requests from view_server processes throughout
the network. These requests can generate both metadata (VOB database) and file
system data (storage pool) activity. The vobrpc_server accesses the VOB database in
the same way as a db_server; it forwards storage pool access requests to the
vob_server.
vobrpc_server processes are started by albd_server, which also routes new requests to
the least-busy servers and terminates unneeded vobrpc_server processes when the
system is lightly loaded.
lockmgr
Each VOB server host runs one lock manager process, lockmgr, which arbitrates
transaction requests to all VOB databases on that host. The calling program polls
lockmgr, which either grants or prohibits access to the requested data. If the data is
available, the transaction proceeds immediately: the data is read or written, and output
is returned to the calling program. If the data is unavailable (locked because another
caller has been granted write access to the data), the caller waits until lockmgr grants
it access to the data.
Unlike most other ClearCase services, the lockmgr is not started by the albd_server.
Instead, it is started when the VOB host starts. Lock manager startup options can be
changed if necessary to improve VOB server performance for certain configurations.
For more information, see Modify Lock Manager Startup Options on page 291.
rwp
The Rational Web Platform rwp provides application support for the ClearCase Web
interface. RWP servers are normally configured at install time and need no further
administrative attention unless special configurations (for example, a configuration to
support access by proxy) are required. A ClearCase community may have one or more
rwp servers. For more information, see Appendix C.
Server Logs
Each ClearCase server process maintains a log on the host where it runs. Because an
error returned by a command entered on the local host can generate a log entry on a
remote host, ClearCase on UNIX provides two remote log retrieval tools: the cleartool
getlog command and the Server Logs node of the ClearCase Administration Console.
(On Windows, ClearCase server processes write to the local host's Windows event log,
which can be viewed with the Windows event viewer on any Windows host.)
Regards,
-Anmev
micky
Feb 1, 2008, 12:45:24 AM2/1/08
to ClearCase
hi mehta,
thank u for your response , but i am unable to find full technical
information about the servers.so please send the link or pdf .
thanking u,
roland
thank u for your response , but i am unable to find full technical
information about the servers.so please send the link or pdf .
thanking u,
roland
micky
Feb 5, 2008, 12:20:48 AM2/5/08
to ClearCase
hello mehta,
thank you very much for your need full.
thanking u,
roland
Reply all
Reply to author
Forward
0 new messages