linuxwebcluster.com

Web Interface


 

The ease of use that comes with our software is partly due to the web interface. Currently it is possible to add and remove nodes (which used to be a very complicated process!) and view all aspects of the cluster configuration with this tool. As we continue development, more features and configuration tasks will be added.

A brief overview of the important screens will be presented. A screenshot of the configuration screen from a running cluster is included with each section.


Manage Nodes


This screen lists the nodes in the cluster and their IP and MAC addresses. In the top bar, there are buttons which automate the addition and removal of cluster nodes. The buttons call a new graphical window that does all the configuration for you.

node_management_screenshot

DHCP Configuration


This screen displays the live configuration of the cluster DHCP service. It only hands out IP addresses to members of the cluster. After adding or removing a node, the configuration is automatically updated for you. The screen is generated in real time when you access the page; to refresh, simply click on the DHCP Configuration button again.

dhcp_config_screenshot

TFTP / PXE Configuration


This screen shows everything related to the boot environment for cluster nodes, including the initramfs boot image and the list of files that are incorporated directly into the image (everything else is accessed via the cluster filesystem after boot). The kernel version is also listed, and should generally be the same as the kernel in use on the master. In the toolbar are buttons for regenerating the boot image if needed and for restarting the PXE related services.

The boot image should be regenerated if you perform any significant updates on the master server. This will ensure that the latest executables and libraries are in use inside the image. To include additional executables, just list the executable name in /cluster/.list and click Regenerate Boot Image. The full path and any required libraries will be automatically determined and included by the regeneration tool.

tftp_pxe_screenshot

LVS Load Balancing


LVS configuration details can all be found here. At the top of the screen are listed the Virtual IP (where the cluster should receive connections to be load balanced), the current Scheduler Algorithm, and the interface that the Virtual IP is attached to.

Next is a list of ports that LVS is configured to listen on, and a YES / NO indication of whether it is currently listening on each one. Last, and generally most important, is a list of currently active ports, which nodes are assigned to them, and how many active connections are assigned to each one at this moment in time.

lvs_screenshot

Performance Graphs


Performance Graphs is the gateway to the Ganglia monitoring system. This screen will open in a new browser window, where a summary screen for the cluster will be presented. Click on the “Choose a Node” drop down box for a detail screen specific to each node.

The cluster health in general can be monitored from the Ganglia main page. On the left is a pie chart that will change colors from blue to red as the cluster becomes more heavily loaded, and on the right are bar graphs that show combined CPU, memory, and network usage for all active nodes.

ganglia_screenshot

Monitoring & Alerts


This screen deals with the Mon monitoring system. There are three primary sections.

First, the names and locations of the major configuration files. Second, the names of any defined Node Groups and lists of their member nodes. This controls how monitoring works. In the case of http monitoring, for instance, a group is defined called “HTTP_NODES”. Then when we create monitoring scripts and alerts (collectively called a “Watch Group”) that check for http services, we can tell them to act on HTTP_NODES only. Third, the Watch Groups are listed one by one.

Each Watch Group consists of definitions for which nodes to watch, what health checks to run against them, how often, and what to do if the checks fail. Typically there is a “monitor” script that checks the service, an alert script that takes action if the check fails, and another alert script that emails the system administrator with a failure notification including time, service, and node name.

For more configuration detail, see the Mon documentation page.

mon_screenshot

Cluster Storage


This pulls the live configuration files for the Glusterfs cluster filesystem, created and maintained by ZResearch and puts them on the screen. The default configuration works best for most configurations, though the options can be modified if desired.

filesystem_screenshot


 

Tell the developers:

The type of clustering you are most likely to deploy is:
 
What Linux distro do you use for clusters?
 

Copyright 2010    RapidScale Clusters, LLC