public Front-end cluster members
To review the current front-end cluster members, you need to do:
- Log in to the WordFrame Integra Core Administration
- Click on the "Architect" tab in the upper left corner
- Click on the "Platform monitoring" menu in the main navigation bar
- Click on the "Cluster members" link in the "Front-end cluster" section on the left of the screen
On this screen is presented the list of all currently subscribed applications as members of this cluster. The fields for each member are:
- Server IP
- The primary IP address of the cluster member. If two application are running on the same webserver, this IP address could be duplicated. In the platform itself each server is recognized by an unique key generated by many of the applications characteristics.
- Last activity
- Each cluster member pings on specific period of time the platform. This ping is used to alert the platform if a cluster member is down, to abort all jobs that are marked by this server for processing. The last ping is represented in this grid as server's last activity
- WordFrame Agent
- This is a windows service installed and used by the WordFrame Integra platform, that provides hardware monitoring of the server and many more additional services that are vital for the platform. This service communicates with the platform via port 18085.
If wordframe agent column appears as "not running" for a cluster member, most probably the windows service "wordframe agent" is not running on that server or the service port 18085 is not allowed by the firewall. If the service is not running, you need to restart it urgently!
- Host type
- Presents what kind of WordFrame Integra application is running on that server. Whether it is a public website ("site") or Platform's Core ("core")
- Status
- The status is applicable only for the Core type of application. It presents whether this Core application is executing jobs (enabled) or not (disabled). A cluster member must be disabled before it is excluded from the frontend cluster. If not, all currently running jobs on that server will be aborted and never executed.
action - disable / enable Click on this link to either enable or prevent the server from executing scheduled background jobs.
action - debug With this functionality, one server can impersonate another. This is useful during the software development process or for application debugging. The reason to have this is that when the core application is in "development mode", each server will execute only its own background jobs.
Last edited by Boz Zashev on 29 Sep 2010 | Rev. 1 |
This page is
public |
Views: 1
Comments:
0 |
Filed under:
Platform monitoring |
Tags: