| Dashboard > RHQ-Project > Configuring RHQ > Configuring the Server | ||||||
|
||||||
Each RHQ Server is identified by a unique name. The installer will default this value to the localhost name. Although present in rhq-server.properties this setting is managed only via the RHQ GUI. Server Endpoint AddressThe server endpoint IP address. This is required for server-to-server and agent-to-server communication. The installer will default this value to the localhost address. This setting is managed only via the RHQ GUI. The full endpoint for server-side communication is formed using this address withe either [HTTP Port] or [Secure HTTPS Port], depending on configuration. Server Affinity GroupRHQ performs load balancing and agent failover when operating with a multi-server configuration (RHQ Server Cloud). In certain situations, for example, regional datacenters, it may make sense for particular RHQ Agents to prefer (have affinity for), certain servers. RHQ Agents assigned to a particular Affinity Group will prefer RHQ Servers assigned to the same Affinity Group. Note that the pairing is not strict and RHQ can service any agent with any server depending on resource load and availability. By default a server is not assigned an Affinity Group. For larger Server Clouds Affinity Group management is performed via the RHQ GUI. Registered ServersWhen installing or upgrading the RHQ server against an existing database the installer will present a list of previously installed RHQ Server Names. These Server Names represent the servers in the current RHQ Server Cloud. If you are performing an upgrade, or for some reason are re-installing an RHQ Server select the appropriate server name from the list. The installer will populate the other High Availability settings as previously configured for the server. The server name should not be changed (otherwise the server will treat this as a new server installation) but the other HA settings can be updated at this time. If you manually enter a new server name it will be installed as a new server. If no others exist this will be a single-server configuration. Otherwise, the new server will be added to the existing High Availability Server Cloud. This list will not be presented if the database is new or there are no previously installed servers. Cluster Bindings (
|
| jboss.partition.name |
The name of the RHQ Server cluster partition. All RHQ Servers participating in the cluster must use the same name.
| jgroups.bind_addr |
The bind address used by JGroups to support clustering communications.
If you have a multi-homed machine, set this to the appropriate NIC IP address.
If you do not plan on running the RHQ Server as part of a cluster of RHQ Servers,
you may set this to 127.0.0.1 so it binds only to the local loopback interface.
| jgroups.udp.mcast_addr |
The multicast address used by the JGroups channel to broadcast messages to members of the cluster.
| jboss.hapartition.mcast_port |
Used by an internal clustering service.
| jboss.ejb3entitypartition.mcast_port |
Used by an internal clustering service to support EJB3 entity caching.
| jboss.alertcachepartition.mcast_port |
Used by an internal clustering service to support alert caching.
| rhq.server.startup.partition.udpLoopback |
On UNIX, this can typically be left as false. On Windows machines, because of the media sense feature being broken with multicast (even after disabling media sense), set this UDP loopback setting to true.
| rhq.server.startup.hajndi.port |
Used by an internal service to define the port on which the HA-JNDI stub is made available.
| rhq.server.startup.hajndi.rmiport |
Used by an internal service - to be used by the HA-JNDI service once bound.
| rhq.server.startup.hajndi.autodiscoverygroupport |
Multicast port used for cluster auto-discovery.
| rhq.server.startup.hajrmpinvoker.rmiport |
Used by an internal service.
| rhq.server.startup.hapooledinvoker.port |
Used by an internal service.
| jgroups.udp.ip_ttl |
Used by JGroups as a performance tuning parameter. See the JBossAS and JGroups documentation on the UDP protocol's "ip_ttl" setting for more information.
| rhq.server.startup.keystore.filename |
The RHQ Console can accept browser requests over HTTPS. If you want to authenticate your RHQ Console to remote browsers, you need to put an SSL certificate in a keystore file. This setting points to the location of your keystore file - note that this filename must be a relative file path relative to the <RHQ Server Install Dir>/jbossas/server/default/conf directory. The RHQ Server ships with a self-signed certificate in a default keystore file.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
| rhq.server.startup.keystore.password |
The password of the keystore file so the RHQ Console can access the keystore file in order to be able to serve the certificate to browser clients.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
| rhq.server.startup.keystore.sslprotocol |
The protocol that browser clients should use to communicate with the RHQ Console.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
These settings define how the RHQ Server will accept incoming messages from the RHQ Agents. See Communications Configuration for more information on setting up the RHQ Server's agent communications subsystem.
| rhq.communications.connector.transport |
Defines how the RHQ Agents need to transport messages to the RHQ Server. Typical values are "servlet", "socket", "sslservlet" and "sslsocket".
If you elect to use "servlet" or "sslservlet", it means you plan on routing agent requests through the RHQ Server web application layer (i.e. the secure Tomcat Connector).
If you elect to use "sslservlet", not only will agent requests route through the web application layer, but it also is secured though the secure Tomcat Connector as well. What this means is that the keystore used for incoming agent message authentication will be the same as that which you set up as described in RHQ Console Transport Security.
It is recommended that if you want to fully authenticate incoming agent requests, that you use "sslsocket" transport to allow for more flexibility in the configuration of the incoming security layer.
| rhq.communications.connector.bind-address |
The address that the RHQ Server will bind its connector to so it can receive RHQ Agent messages.
| rhq.communications.connector.bind-port |
The port that the RHQ Server will listen to in order to accept RHQ Agent messages.
| rhq.communications.connector.transport-params |
Defines additional transport parameters the RHQ Server will set on its connector that will accept incoming messages from the RHQ Agents. See Communications Configuration#TransportParameters for full details on transport parameters.
| rhq.communications.multicast-detector.enabled |
If true, the RHQ Server will attempt to auto-detect RHQ Agents coming online and going offline using multicast detection. Your network must support multicast traffic for this to work.
| rhq.communications.multicast-detector.bind-address |
The address that the multicast detector will directly bind to. This is not needed nor used if you have not enabled multicast detection.
| rhq.communications.multicast-detector.multicast-address |
The address that the multicast detector will broadcast messages to. This is not needed nor used if you have not enabled multicast detection.
| rhq.communications.multicast-detector.port |
The port that the multicast detector will broadcast messages to. This is not needed nor used if you have not enabled multicast detection.
These settings define how the server will secure its communications channel when accepting incoming messages from the RHQ Agents. See Securing Communications for more detailed information on setting up the Server-Agent communications security.
Note that if you are not using a secure incoming transport, these settings are not used.
The other half of the communications channel (that is, the outgoing side) has analogous settings. You can share keystores, truststores and other settings for both sides, or you can customize your communications for either side independently.
| rhq.communications.connector.security.secure-socket-protocol |
The secure protocol that agents must use when communicating with this RHQ Server.
| rhq.communications.connector.security.keystore.file |
The keystore file that contains a certificate that authenticates the RHQ Server to the agents.
| rhq.communications.connector.security.keystore.algorithm |
| rhq.communications.connector.security.keystore.type |
The file format of the keystore.
| rhq.communications.connector.security.keystore.password |
The password that is used to gain access to the keystore file.
| rhq.communications.connector.security.keystore.key-password |
The password that is used to gain access to the key inside the keystore.
| rhq.communications.connector.security.keystore.alias |
The alias that identifies the RHQ Server's key within its keystore.
| rhq.communications.connector.security.truststore.file |
The truststore file that contains certificates that this RHQ Server trusts. If you want or need the RHQ Server to authenticate RHQ Agents, you must set this; otherwise it is not needed. This truststore will contain certificates for all RHQ Agents that need to communicate with this RHQ Server.
| rhq.communications.connector.security.truststore.algorithm |
| rhq.communications.connector.security.truststore.type |
The file format of the truststore file.
| rhq.communications.connector.security.truststore.password |
The password that is used to gain access to the truststore file.
| rhq.communications.connector.security.client-auth-mode |
Indicates if you want or need the RHQ Server to authenticate the RHQ Agents that are sending it messages. If you are using a secured transport but do not have trusted certificates for all of your RHQ Agents in a truststore, you must set this to none.
Valid values are: none, want or need
These settings define how the server will secure its communications channel when sending outgoing messages to the RHQ Agents. See Securing Communications for more detailed information on setting up the Server-Agent communications security.
The other half of the communications channel (that is, the incoming side) has analogous settings. You can share keystores, truststores and other settings for both sides, or you can customize your communications for either side independently.
Note that if your RHQ Agents are not using a secure transport, these settings are not used.
| rhq.server.client.security.secure-socket-protocol |
The secure protocol that the server must use when sending outgoing messages to agents. The agents must be expecting to use this protocol for messages that it receives.
| rhq.server.client.security.keystore.file |
| rhq.server.client.security.keystore.algorithm |
| rhq.server.client.security.keystore.type |
| rhq.server.client.security.keystore.password |
| rhq.server.client.security.keystore.key-password |
| rhq.server.client.security.keystore.alias |
| rhq.server.client.security.truststore.file |
| rhq.server.client.security.truststore.algorithm |
| rhq.server.client.security.truststore.type |
| rhq.server.client.security.truststore.password |
| rhq.server.client.security.server-auth-mode-enabled |
Indicates if you want the RHQ Server to authenticate the RHQ Agents that it is sending messages to. If you are using a secured transport but do not have trusted certificates for all of your RHQ Agents in a truststore, you must set this to none.
You have the option of installing the RHQ Agent embedded directly in the RHQ Server, as opposed to installing and running a separate process for the RHQ Agent. The embedded agent operates just like its standalone counterpart, the only difference is it is running in the same Java virtual machine as the RHQ Server. Note that if you do this, you will not have the option of a command line interface to the agent, as you would have with a standalone RHQ Agent.
| rhq.server.embedded-agent.enabled |
Set this to true if you want to run the embedded RHQ Agent inside this RHQ Server. Set this to false if you want to run the RHQ Agent as a separate process or if you do not want a RHQ Agent running on the same machine as your RHQ Server.
| rhq.server.embedded-agent.name |
The name that the embedded RHQ Agent will register itself as.
| rhq.server.embedded-agent.disable-native-system |
The RHQ Agent has JNI native components that is used to perform some tasks. If you are having problems with the native components, you can completely disable their usage by setting this to true. Typically, you can leave this as false under normal conditions.
If you change this value, you must shutdown and restart the RHQ Server in order for the change to take effect.
| rhq.server.embedded-agent.reset-configuration |
If this is set to true, the embedded agent will reset its configuration at startup. Resetting the configuration means it will clear out any configuration settings currently persisted in the preferences store and reload the configuration from its built-in configuration file (i.e. the defaults it shipped with out-of-box). If false, the embedded agent will retain the configuration it had when it last was running - which may be different from its original configuration if a user changed those configuration settings from the RHQ Console. Note that this setting will not effect those configuration settings that are explicitly defined in or are derived from the rhq-server.properties startup properties file. This includes things like EmbeddedRHQAgentDisableNativeSystem, IncomingAgentCommunicationsTransport (which tells the embedded agent how to talk to the server) and the like.
| rhq.server.email.smtp-host |
The hostname of the SMTP server that is used when the RHQ Server sends emails.
| rhq.server.email.smtp-port |
The port that the RHQ Server will send emails over when communicating with the SMTP server.
| rhq.server.email.from-address |
The "From:" header of all emails sent by the RHQ Server.
| rhq.server.operation-timeout |
One of the features of RHQ is the ability to invoke operations (aka control actions) on a resource. The RHQ Server will be able to ask an agent to invoke a particular operation on a particular resource managed by that agent. Because of the remote, asynchronous nature of operation invocations, alot of things can go wrong (the network goes down, the resource crashes, etc.). This operation timeout is the default number of seconds that the RHQ Server will wait for an operation to complete and an agent to provide the results. If this timeout expires, the operation will be considered to have failed. Note that this is only a fallback default value - individual operations can define their own timeouts (in the plugin descriptor) or individual operation invocations can themselves specify a timeout. Those override this default rhq.operation-timeout setting.
RHQ is designed to scale to large numbers of agents. The RHQ Server must, therefore, take into account the possibility that it could get flooded with messages if many or all agents attempt to communicate with the server simultaneously (as will be the case if the RHQ Server is restarted after being down for a while; RHQ Agents will detect the RHQ Server has come back up and will attempt to immediately send it a backlog of messages).
To help alleviate problems that could occur during high load, the RHQ Server is configured to limit the number of concurrent messages allowed to be processed by different subsystems within the RHQ Server. If more messages arrive concurrently, such that the limit is exceeded, those additional messages will be dropped and the agent will be asked to send them later. The following configuration settings define types of messages that have concurrency limits associated with them.
| rhq.server.startup.web.max-connections |
RHQ limits the number of web connections that can be concurrently created. This includes GUI connections made by browsers. It may also include connections made by agents, if agent connections are made via the servlet transport (see Incoming Agent Communications Transport). Note that if agent requests are routed over web connections, you should ensure that the Global Concurrency Limit is slightly lower than this Web Connections limit so as not to lock out GUI users from accessing the user interface during times of high agent load.
This limit on web connections is the same for both non-secured http requests and secured https requests, so the total max connections allowed is actually twice what this setting is. For example, if the max web connections is set to 300, then 300 http requests will be allowed and 300 https requests will be allowed, for a possible total of 600 concurrent web connections.
| rhq.communications.global-concurrency-limit |
Aside from the Web Connections limit, all other concurrency limits will only affect incoming agent messages (not GUI/browser requests). This global concurrency limit will limit the total number of agent messages coming into the server, regardless of the type of message. In other words, if this global concurrency limit is set to 300, no more than 300 total agent messages can be processed at any one time, no matter what kinds of messages are coming in. The rest of the concurrency limit settings will put a limit on the number of messages of particular message types. Keep in mind that if other concurrency limits are set higher than this global limit, they are effectively capped at this global limit since you can never have more than this global limit number of messages concurrently being processed.
| rhq.server.concurrency-limit.inventory-report |
Inventory reports are sent from the agent when the agent starts up and periodically thereafter. Inventory reports can be large, depending on the number of resources on the agent machine.
| rhq.server.concurrency-limit.availability-report |
Availability reports are sent from the agent very often (typically every 60 seconds). Availability reports are usually very small, but occur in large numbers due to the high frequency of their transmission.
| rhq.server.concurrency-limit.inventory-sync |
Inventory synchronizations occur when the agent needs to synchronize its inventory with that of the server. Agents typically synchronize at startup. Traffic that flows as part of inventory synchronizations is usually large, depending upon the number of resources managed by the agent.
| rhq.server.concurrency-limit.content-report |
Content reports are similar to inventory reports except they contain information about discovered content (i.e. installed packages of software). These reports can be large depending on the number of installed software the agent has discovered and is managing.
| rhq.server.concurrency-limit.content-download |
Content downloads occur when a resource on an agent needs to ask for the content of a package version, usually for the purpose of installing the package.
| rhq.server.concurrency-limit.measurement-report |
Measurement reports are sent to the server periodically whenever the agent completes measurement collections. The number of measurement reports vary as do their size, depending on the number and frequency of measurements that are scheduled to be collected. The greater the number of schedule measurements the agent needs to collect, the more frequently measurement reports are sent and the larger they are.
| rhq.server.concurrency-limit.measurement-schedule-request |
Similar to inventory synchronization, measurement schedule requests are sent to the agent when the agent wants to ask the server for its up-to-date set of measurement schedules that have to be collected.
Since 1.1)
