Displaying group icons representing respective groups of nodes

BACKGROUND

0001To manage or to monitor information associated with nodes (e.g., computer nodes, storage server nodes, web server nodes, application server nodes, and so forth), graphical user interface (GUI) software can be used to present a GUI window that displays icons representing the nodes. Typically, information about the nodes is displayed with the corresponding icons. For small-scale arrangements of nodes (that have relatively small numbers of nodes), icons representing the nodes can be effectively viewed in a GUI window. A relatively small number of icons can easily fit within a GUI window displayed by a display device. However, as the number of nodes increase, then even tiny icons will have trouble fitting in a large GUI window. Attempting to fit a large number of icons representing corresponding nodes into a GUI window will cause clutter in the GUI window, and prevent the user from easily identifying information associated with any specific node. Moreover, with small icons, the amount of information associated with each icon that can be displayed is reduced such that the user will unlikely be able to view any meaningful information regarding any node.

0002Some conventional GUI tools represent each node as a “blob” in which just one piece of information associated with the corresponding node is presented, which denies the user the ability to simultaneously view other information associated with nodes. Also, other conventional GUI tools provide for scrolling to allow the display of larger icons; however, having to scroll to different parts of a display window does not allow the user to view the entire arrangement of icons representing corresponding nodes.

BRIEF DESCRIPTION OF THE DRAWINGS

0003Some embodiments of the invention are described with respect to the following figures:

0004<figref idref="DRAWINGS">FIG. 1</figref> is a block diagram of an arrangement that includes a computer and a display device, where the display device contains a graphical user interface (GUI) window to display group icons representing corresponding groups of nodes, in accordance with an embodiment;

0005<figref idref="DRAWINGS">FIG. 2A</figref> illustrates a tuple associated with a corresponding node, where the tuple contains several metrics that are associated with the node;

0006<figref idref="DRAWINGS">FIGS. 2B-2D</figref> illustrate several examples in which tuples corresponding to different nodes are compared, in accordance with some embodiments;

0007<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram of a node display procedure, according to an embodiment;

0008<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram of a process of grouping nodes, according to an embodiment;

0009<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram of a process of subsuming nodes, according to an embodiment;

0010<figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram of a process of evicting nodes, according to an embodiment;

0011<figref idref="DRAWINGS">FIG. 7</figref> illustrates icons representing individual nodes prior to grouping in accordance with an embodiment; and

0012<figref idref="DRAWINGS">FIG. 8</figref> illustrates group icons representing corresponding groups of nodes, according to an embodiment.

DETAILED DESCRIPTION

0013In accordance with some embodiments, a grouping technique is used to allow group icons to be displayed in a graphical user interface (GUI) window associated with a tool that is used to monitor and/or manage an arrangement of nodes. Examples of nodes include computers, storage devices, switches, routers, and so forth. The group icons represent corresponding groups of nodes, where the nodes are grouped based on characteristics associated with the nodes. In one embodiment, the characteristics associated with the nodes include metrics associated with the nodes, where a metric can include any one or more of the following: central processing unit (CPU) utilization; utilization of network interconnect bandwidth for read accesses; network interconnect bandwidth utilization for write accesses; memory utilization; network interface controller utilization; storage interconnect bandwidth utilization for read accesses; storage interconnect bandwidth utilization for write accesses; and other metric information. Grouping based on metrics of the nodes refers to grouping based on whether differences between one or more of the metrics are within predefined tolerance(s). Although reference is made to multiple metrics, it is noted that grouping can alternatively be based on just one metric.

0014Other characteristics of nodes that can be used for grouping include one or more of the following: types of software applications run by the nodes; whether the node is operating as a master or a slave; number of CPUs in each node; or some other characteristic. In one implementation, these latter characteristics are actually used to identify different classes of nodes, with grouping of nodes being performed within each class of nodes. For example, nodes running the same type of software application can be considered to be part of the same class. Alternatively, nodes operating as masters are classified in one class, whereas nodes operating as slaves are classified in another class. In yet another example, the number of CPUs in each node determines the class of the node (e.g., nodes having one CPU can be classified in one class; nodes having two CPUs can be classified in another class, and so forth). In another example, nodes are divided into a computing node class and an administrative node class. Computing nodes can be nodes that perform primary computing tasks, whereas administration nodes are nodes that are used to perform various administrative tasks with respect to the computing nodes. In other examples, classification can be based on bus speeds, types of interconnect, and so forth. As noted above, grouping of nodes occurs within each class; for example, if there are two classes (A and B) of nodes, then class A nodes can be grouped into one or more groups, and class B nodes can be grouped into one or more groups. Thus, in some embodiments, two levels of partitioning can be performed to perform grouping, with a first level of partitioning to partition nodes into different classes, and a second level of partitioning to group nodes within each class. In other embodiments, separation of nodes into different classes is not performed. Note also in another implementation a user is able to pre-select the nodes of interest as the arrangement for which grouping is to be performed.

0015Using the techniques above, nodes that are doing “roughly the same thing” are able to be grouped into a grouped node, where group icons are used to represent corresponding grouped nodes to allow a user to quickly identify differences, disparities, and/or anomalies associated with the various grouped nodes.

0016The grouping of the nodes can evolve over time due to changing characteristics of the nodes. Membership of each group can change, where the membership change includes evicting individual nodes from a group, or adding individual nodes to a group. Also, during operation, additional groups can be created, and groups can be combined by subsuming one group into another group.

0017The concept of grouping nodes based on metrics associated with the nodes assumes that nodes performing similar activities will have similar metrics and thus can be collected into grouped nodes. By grouping the nodes, a smaller number of group icons have to be displayer in a GUI window, which allows the group icons to more easily fit into the GUI window. The smaller number of displayed group icons allows the user to more easily view information associated with the grouped nodes and to perform various management tasks. Each group icon displayed in the GUI window can have a representative name and can contain group metrics that represent some aggregation of the metrics associated with the individual nodes. The aggregation can include one or more of the following: average, median, minimum, maximum, mode (most frequent metric value), and range (the maximum and minimum metric values within the group). Also, a membership count can be displayed with the group icon to indicate the number of members in the group. A user can select (by use of an input device such as a mouse or keyboard) the group icon to allow the user to expand the group into individual icons representing individual nodes, such as in some portion of the GUI window or in a pop-up window. Alternatively, selecting the group icon can bring up more detailed information regarding the corresponding group of nodes.

0018<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example arrangement that includes a computer <b>100</b> on which a grouper <b>102</b> is executed. The grouper <b>102</b> is a software module (or software modules) executable on one or more central processing units (CPUs) <b>104</b> of the computer <b>100</b>. The grouper <b>102</b> is used to define groups of nodes <b>106</b> that are part of an arrangement of nodes <b>106</b> (e.g., a cluster of nodes, a network of nodes, etc.). The nodes <b>106</b> are coupled by a communications network <b>110</b> (e.g., a local area network, a wide area network, the Internet, etc.). Each node <b>106</b> is associated with a metrics monitor <b>108</b> to monitor metrics associated with the respective node, including any of the metrics mentioned above. The metrics monitor <b>108</b> communicates collected metrics information over the communications network <b>110</b> to the computer <b>100</b>. The metrics information received from metrics monitors <b>108</b> are collected by a metrics collector <b>112</b> in the computer <b>100</b>, which can also be implemented as software executable on the CPU(s) <b>104</b>. The node metrics information is stored as information <b>114</b> in a storage <b>116</b> of the computer <b>100</b>, where the storage <b>116</b> can be volatile memory (e.g., dynamic random access memory or static random access memory) or persistent storage (e.g., a disk-based persistent storage).

0019The defined groups are stored as group information <b>118</b>, also in the storage <b>116</b>. The group information <b>118</b> can also include aggregated metrics, membership count, and other information associated with corresponding grouped nodes.

0020The computer <b>100</b> further includes client software <b>120</b> that is executable on the one or more CPU(s) <b>104</b>, where the client software <b>120</b> includes a GUI control module <b>122</b> to control the display of a GUI window (or multiple GUI windows) <b>124</b> in a display device <b>125</b> attached to the computer <b>100</b>. The client software <b>120</b> receives information from the grouper <b>102</b>, and the GUI control module <b>122</b> controls the display of group icons <b>126</b> in the GUI window <b>124</b>. Information displayed with the group icons <b>126</b> can be extracted from the group information <b>118</b>, including aggregated metrics, membership count information, and other information relating to the grouped nodes. Also, if display of metrics associated with individual nodes is desirable, such as in response to clicking of a particular group icon (or selection of a menu control item in the GUI window <b>124</b>), then the node metrics information <b>114</b> stored in the storage <b>116</b> can be accessed to display such information in the GUI window <b>124</b> (or in some other window such as a pop-up window).

0021<figref idref="DRAWINGS">FIG. 2A</figref> shows an example tuple <b>200</b> associated with a node (an individual node). The tuple <b>200</b> includes several entries corresponding to different metrics, which in the example are utilizations of different resources of a node. The example tuple <b>200</b> includes an entry <b>202</b> to store CPU utilization, an entry <b>204</b> to store network interconnect bandwidth utilization for read accesses, an entry <b>206</b> to store network interconnect bandwidth utilization for write accesses, an entry <b>208</b> to store memory utilization, an entry <b>210</b> to store network interface controller utilization, an entry <b>212</b> to store storage interconnect bandwidth utilization for read accesses, and an entry <b>214</b> to store storage interconnect utilization for write accesses. Note that in other example implementations, other metrics can be stored in the tuple <b>200</b>. Examples of other types of metric information that can be included in a tuple include utilization of a front side bus of a node, utilization of a memory bus, utilization of an I/O (input/output) bus, and so forth. Moreover, in other implementations, the entries of the tuples can store metrics having different dimensions.

0022In a node having multiple CPUs, the CPU utilization metric in entry <b>202</b> of the tuple <b>200</b> can refer to the collective utilization of the multiple CPUs rather than to individual CPUs. The collective utilization of multiple CPUs can be a simple sum of the utilizations of individual CPUs. CPUs of a node are considered a shared resource, although metrics associated with the CPUs can be individually monitored. A scheduler in the node can move tasks among CPUs without changing the quality of the intended grouping. Consequently, the metrics of the CPUs can be combined for purposes of determining grouping. However, the metrics of the individual CPUs (rather than the collected metric) can be displayed with in the GUI window. In other implementations, metrics for other types of resources in a node can be processed in similar fashion—combine metrics for purposes of grouping but display metrics individually.

0023In the example of <figref idref="DRAWINGS">FIG. 2A</figref>, the tuple <b>200</b> also separates utilization of bandwidth (network interconnect bandwidth or storage interconnect bandwidth) for read accesses and write accesses (entries <b>204</b>, <b>206</b>, <b>212</b>, and <b>214</b>). In other implementations, segregating bandwidth utilizations for read and write accesses is not performed.

0024A tuple for a grouped node (representing a group of nodes) has the same format as the tuple <b>200</b> of <figref idref="DRAWINGS">FIG. 2A</figref>, except that each entry of the tuple contains a corresponding aggregated metric. For example, the CPU utilization aggregate metric is an aggregate (range, average, minimum, maximum, etc.) of the individual CPU utilization metrics of respective individual nodes in the group. If the aggregated metric is a range, then each entry of the tuple for the grouped node stores a range defined by the minimum and maximum metric values corresponding to the nodes in the group. For example, if the minimum CPU utilization associated with a first node in the group is 55%, and the maximum CPU utilization associated with a second node in the group is 64%, then the range would be [55%, 64%].

0025<figref idref="DRAWINGS">FIG. 3</figref> shows a flow diagram of a node display procedure executable by the software modules (<b>102</b>, <b>112</b>, <b>120</b>, <b>122</b>) in <figref idref="DRAWINGS">FIG. 1</figref> to display group icons <b>126</b> in the GUI window <b>124</b> that relate to grouped nodes that represent corresponding groups of the nodes <b>106</b> on the network <b>110</b>. First, the metrics collector <b>112</b> collects (at <b>302</b>) metrics information from the nodes <b>106</b>, and stores the metrics information in storage <b>116</b> as node metrics information <b>114</b>. Next, if there are any groups that are in existence, eviction is performed (at <b>304</b>) by the grouper <b>102</b> to evict members from one or more groups that do not belong to their corresponding group(s) based on the members falling out of tolerance with respect to the other members of the group. If there are N (N is an integer) groups, then eviction is performed for each group j, j=1 to N. Eviction is described further in connection with <figref idref="DRAWINGS">FIG. 6</figref>.

0026Next, grouping of nodes that are not part of any group is performed (at <b>306</b>). In one embodiment, a tolerance can be defined for a particular metric to determine how close two metrics should be to be considered “close enough” to be part of the same group. For example, a tolerance of 10% would allow a first node having 56% utilization and a second node having 63% utilization to be considered “close enough” to be part of the same group. However, if the first node has a 50% utilization, then that would be outside the tolerance of 10% with respect to the second node's utilization of 63%. In another example, if the 50% utilization and 56% utilization associated with corresponding nodes were encountered first, then the 63% utilization associated with another node would be considered outside the tolerance of the first two utilizations. Thus, grouping of the nodes is dependent upon the order in which the nodes are processed.

0027The above example considers just one metric when determining whether the tuples of two nodes are considered to be within tolerance of each other. As discussed above, a tuple can have multiple entries corresponding to different metrics. Thus, to determine whether two tuples are within tolerance of each other such that the nodes corresponding to two tuples can be added to the same group, each metric of one tuple is compared to the corresponding metric of the other tuple to determine whether the two metrics are within tolerance. <figref idref="DRAWINGS">FIG. 2B</figref> shows a comparison between metrics of two example tuples <b>200</b>A and <b>200</b>B, where tuple <b>200</b>A corresponds to node A and tuple <b>200</b>B corresponds to a node B. In the example of <figref idref="DRAWINGS">FIG. 2B</figref>, metric <b>202</b>A (the CPU utilization metric) is compared to the corresponding CPU utilization metric <b>202</b>B of tuple <b>200</b>B to determine whether metrics <b>202</b>A and <b>202</b>B are within tolerance T<b>1</b> of each other. Similarly, metrics <b>204</b>A and <b>204</b>B are compared to each other to determine whether they are within tolerance T<b>2</b>. The same is performed for the remaining pairs of tuples; metrics <b>206</b>A, <b>206</b>B compared with respect to tolerance T<b>3</b>; metrics <b>208</b>A, <b>208</b>B compared with respect to tolerance T<b>4</b>; metrics <b>210</b>A, <b>210</b>B compared with respect to tolerance T<b>5</b>; metrics <b>212</b>A, <b>212</b>B compared with respect to tolerance T<b>6</b>; and metrics <b>214</b>A, <b>214</b>B compared with respect to tolerance T<b>7</b>. The various tolerances T<b>1</b>-T<b>7</b> associated with the different metrics can have the same value or can have different values. The two tuples <b>200</b>A, <b>200</b>B are considered to be within tolerance if every two corresponding metrics of the tuples <b>200</b>A, <b>200</b>B are within tolerance of each other; in other words, metrics <b>202</b>A, <b>202</b>B are within tolerance T<b>1</b>; metrics <b>204</b>A, <b>204</b>B are within tolerance T<b>2</b>; metrics <b>206</b>A, <b>206</b>B are within tolerance T<b>3</b>; metrics <b>208</b>A, <b>208</b>B are within tolerance T<b>4</b>; metrics <b>210</b>A, <b>210</b>B are within tolerance T<b>5</b>; metrics <b>212</b>A, <b>212</b>B are within tolerance T<b>6</b>; and metrics <b>214</b>A, <b>214</b>B are within tolerance T<b>7</b>.

0028In an alternative implementation, a single tuple-wide tolerance can be defined for comparing metrics in tuples.

0029<figref idref="DRAWINGS">FIG. 2C</figref> shows a comparison of metrics in a tuple <b>200</b>A (associated with a node A that does not belong to any group) with corresponding aggregated metrics of a group tuple <b>201</b> associated with group <b>220</b>. As noted above, the group tuple according to one implementation can include ranges of metric values in each entry of the group tuple. The metrics in tuple <b>200</b>A are compared to corresponding ranges in the group tuple <b>201</b> to determine whether tuple <b>200</b>A is within tolerance of the group <b>220</b>. If so, then node A can be added to the group <b>220</b>. If not, then node A is not added to the group <b>220</b>.

0030In embodiments in which the group tuple <b>201</b> does not store ranges, then tuple <b>200</b>A may be compared to tuples of all individual nodes in the group <b>220</b> to determine whether tuple <b>200</b>A is within tolerance.

0031As part of the grouping at <b>306</b>, new groups can be created (discussed further below) if a particular node cannot properly be added to any existing group. After the grouping performed at <b>306</b>, subsuming is performed (at <b>308</b>), where one group can be subsumed into another group when the metrics of the various tuples in the two groups converge such that all tuples within the two groups are within tolerance of every other tuple in the two groups. <figref idref="DRAWINGS">FIG. 2D</figref> illustrates comparisons of a group tuple <b>201</b>A associated with group <b>220</b>A with a group tuple <b>201</b>B associated with group <b>220</b>B to determine whether the metrics of the two groups <b>220</b>A, <b>220</b>B have converged such that the two groups are within tolerance and can be combined. The comparison can be a comparison of the ranges of the corresponding group tuples <b>201</b>A, <b>201</b>B. For example, if the CPU utilization metric in group tuple <b>201</b>A is a range [10%, 15%], and the CPU utilization metric in group tuple <b>201</b>B is a range [14%, 19%], then the CPU utilizations are within tolerance (assuming tolerance of 10%) since the minimum value 10% in the group tuple <b>201</b>A is within 10% of the maximum value 19% in group <b>201</b>B.

0032In some embodiments, when performing the subsuming at <b>308</b>, a larger group subsumes the smaller group. A simple example of a scenario where the metrics of various nodes in different groups converge close to each other is when nodes of the two groups become idle. Further details regarding subsuming are described in connection with <figref idref="DRAWINGS">FIG. 5</figref>.

0033Next, the various groups can be displayed (at <b>310</b>) as group icons <b>126</b> by the GUI control module <b>122</b>, where the group icons <b>126</b> are displayed in the GUI window <b>124</b> (<figref idref="DRAWINGS">FIG. 1</figref>). In displaying the group icons, the grouper <b>102</b> can read the node metrics information <b>114</b> to perform some aggregation with respect to the metrics such that aggregated metric information is displayed with each of the group icons. Alternatively, the aggregated metric information can already be part of the group information <b>118</b> that has been pre-computed by the grouper <b>102</b>.

0034The process of <figref idref="DRAWINGS">FIG. 3</figref> can be repeated (at <b>312</b>) for the next display cycle.

0035<figref idref="DRAWINGS">FIG. 4</figref> is a flow diagram of a process of grouping nodes that are not part of any group (<b>306</b> in <figref idref="DRAWINGS">FIG. 3</figref>). The grouper <b>102</b> iterates through nodes that are not part of any group, which is depicted in <figref idref="DRAWINGS">FIG. 4</figref> as being a For loop that iterates through nodes i that are not part of any group. Tuple i for node i is read (at <b>402</b>) by the grouper <b>102</b>. The grouper determines (at <b>404</b>) if a group exists that is within tolerance of tuple i (e.g., by comparing the metrics of tuple i with the group tuple of each group). Tuple i is within tolerance of a particular group if each metric of tuple i is within tolerance of the metric range of each corresponding entry of the group tuple. If tuple i is determined to be within tolerance of the group, then tuple/node i is added (at <b>406</b>) to the existing group. However, if it is determined at <b>404</b> that tuple i is not within tolerance of any existing group, then a new group is created (at <b>408</b>), with tuple i added as the initial member of the new group (at <b>410</b>). The value of i is incremented (at <b>412</b>) to the next node that is not part of any group, and the process at <b>402</b>-<b>410</b> is repeated.

0036<figref idref="DRAWINGS">FIG. 5</figref> shows the subsuming process (<b>308</b> of <figref idref="DRAWINGS">FIG. 3</figref>) in greater detail. During operation of the nodes, the metrics of the tuples associated with the nodes are likely to change (such as due to software processes completing or new software processes being invoked). The updated metrics are provided to the metrics collector <b>112</b> and stored as node metrics information <b>114</b>. The subsuming process performed by the grouper <b>102</b> (which can be performed by a subsuming subroutine of the grouper <b>102</b>, for example) is able to read (at <b>502</b>) updated metrics of the various nodes of the corresponding groups. The subsuming process then identifies (at <b>504</b>) groups whose metrics have converged within tolerance. In one implementation, two groups converge within tolerance when the metric ranges of the group tuples within the two respective group tuples are within tolerance of each other. For a newly-identified set of groups whose metrics have converged, the newly-identified set is marked (at <b>506</b>) with a timestamp. This timestamp is used to later determine whether the groups of the set are still within tolerance of each other after some predefined time delay has transpired. Without a delay, nodes of a group that go idle temporarily would immediately be subsumed into an idle group, followed by subsequent eviction within a short period of time when the nodes again become active. Such behavior can be distracting and confusing, and is wasteful of computing resources. A delay allows nodes of a group a chance to stay together should they resume computation.

0037Note that there may be multiple sets of groups that were previously identified as having converged, where each set is associated with a respective timestamp. The subsuming process checks (at <b>508</b>), for each such set, if the predefined time delay has passed from the timestamp associated with the set, and if so, if the identified groups within the set are still within tolerance. If the groups of the set are still within tolerance, the groups in the set are combined at <b>510</b> (such as by subsuming a smaller group into a larger group in some embodiments).

0038<figref idref="DRAWINGS">FIG. 6</figref> shows the eviction process for a particular group j (<b>304</b> in <figref idref="DRAWINGS">FIG. 3</figref>). The eviction process (which can be performed by an eviction subroutine in the grouper <b>102</b>, for example) reads (at <b>602</b>) updated metrics of nodes in group j. The grouper <b>102</b> next determines (at <b>604</b>) the tolerance range for group j. There is a variety of possible different ways to determine a group's new tolerance range as the underlying metrics of nodes change. A first technique involves using the lowest metric value as the anchor, such that any tuples containing higher metric values that are outside of tolerance with respect to the anchor will be evicted. The tolerance range is defined based on the anchor. Alternatively, the highest value of a metric can be used as an anchor. In yet another technique, the medium value or an average value can be used as the anchor.

0039Next, the grouper <b>102</b> computes (at <b>606</b>) a grace range for group j, where the grace range (used to prevent immediate eviction of a node from a group when the node falls outside the tolerance range) is somewhat larger than the tolerance range (such as by some predefined amount). For example, the tolerance can be set at 10%, while the grace is set at 16%. In such example, the tolerance range is 10% on either side of the anchor, while the grace range is 16% on either side of the anchor. The notion here is that if a metric is outside the tolerance range but within the grace range, then the particular node is not evicted immediately, but rather, is given some chance to drift back within tolerance.

0040Next, the grouper <b>102</b> iterates through all the nodes (nodes i) in group j. For each node i, the grouper <b>102</b> determines (at <b>610</b>) if tuple i for node i is outside the tolerance range for group j. If not, the value of i is incremented (at <b>612</b>) to the next node i in group j. If tuple i for node i is outside the tolerance range for group j, as determined at <b>610</b>, then the grouper <b>102</b> determines (at <b>612</b>) if tuple i for node i is outside the grace range. If so, then node i is evicted (at <b>614</b>) from group j. However, if node i is not outside the grace range, as determined at <b>612</b>, then a variable GraceCount(i) is incremented (at <b>616</b>). GraceCount(i) is associated with node i. The value of GraceCount(i) is then compared (at <b>618</b>) with a threshold to determine if GraceCount(i) is greater than the threshold. If so, then node i can be evicted (at <b>614</b>). The threshold of step <b>618</b> is used to define how many processing cycles node i is allowed to stay outside the tolerance range but within the grace range before node i is evicted.

0041<figref idref="DRAWINGS">FIG. 7</figref> shows a GUI window <b>700</b> in which icons corresponding to individual nodes are displayed. A representative one of the icons <b>702</b> is described. Note that the window <b>700</b> shown in <figref idref="DRAWINGS">FIG. 7</figref> does not depict group icons according to some embodiments. The individual icon <b>702</b>, according to the example of <figref idref="DRAWINGS">FIG. 7</figref>, has several elements. A node number <b>704</b> (which is “1” in the example) at the upper left corner of the icon <b>702</b> identifies the number or identifier of the corresponding node. In the example of <figref idref="DRAWINGS">FIG. 7</figref>, each node has two network interface controllers. Two left boxes <b>706</b> in the icon <b>702</b> are used to depict utilization values of the two network interface controllers.

0042In the example, each of some of the nodes has two CPUs (e.g., two processing cores of a duo-core microprocessor). The two boxes <b>708</b> in the middle of the icon <b>702</b> depict utilizations of the respective two CPUs in the corresponding node. The right box <b>710</b> of the icon <b>702</b> depicts the memory utilization of the node. At the top of icon <b>702</b>, an incoming arrow <b>712</b> represents the utilization of the network interconnect bandwidth for read accesses, whereas arrow <b>714</b> represents network interconnect bandwidth utilization for write accesses.

0043On the bottom side of icon <b>702</b>, arrow <b>716</b> represents the storage interconnect bandwidth utilization for write accesses, whereas arrow <b>718</b> represents storage interconnect bandwidth utilization for read accesses.

0044Example icon <b>720</b> in the GUI window <b>700</b> represents a node in which there are four CPUs, with the icon <b>720</b> having four boxes <b>722</b> representing respective utilizations of the four CPUs (rather than the two CPUs of the node represented by icon <b>702</b>). Thus, in <figref idref="DRAWINGS">FIG. 7</figref>, two classes of nodes are depicted, with a first class including nodes with two CPUs, and a second class including nodes with four CPUs.

0045<figref idref="DRAWINGS">FIG. 8</figref> shows a GUI window <b>800</b> (corresponding to GUI window <b>124</b> of <figref idref="DRAWINGS">FIG. 1</figref>) that displays group icons. A first example group icon is identified as icon <b>802</b>. The group icon <b>802</b> has a number <b>804</b> (“61” in the example) at the left upper corner of the icon <b>802</b>, where the number <b>804</b> represents the number of nodes in the group represented by group icon <b>802</b>. Following the number <b>804</b> is a list <b>806</b> (in parentheses) that lists the nodes, by node number, that are part of the group represented by the group icon <b>802</b>. The structure of group icon <b>802</b> is similar to the structure of individual icon <b>702</b>. The group icon <b>802</b> represents a grouped node having plural nodes of the first class (nodes with two CPUs). The remaining group icons depicted in <figref idref="DRAWINGS">FIG. 8</figref> (such as group icon <b>820</b>) are used to represent grouped nodes for a second class of nodes (namely, nodes with four CPUs). The various values associated with group icons <b>802</b> and <b>820</b> can be some aggregated value that represents an aggregation of the corresponding metrics associated with the individual nodes. As discussed above, the aggregation can be any one of an average, median, maximum, minimum, mode, and range.

0046<figref idref="DRAWINGS">FIG. 8</figref> also shows some empty boxes, such as empty box <b>830</b>, which indicates a zero-member group. To create new groups, any one of the zero-member groups can be converted into an actual group icon to represent a corresponding group of nodes.

0047Instructions of software described above (including grouper <b>102</b>, metrics collector <b>112</b>, client application <b>120</b>, and GUI control module of <figref idref="DRAWINGS">FIG. 1</figref>) are loaded for execution on a processor (such as one or more CPUs <b>104</b> in <figref idref="DRAWINGS">FIG. 1</figref>). The processor includes microprocessors, microcontrollers, processor modules or subsystems (including one or more microprocessors or microcontrollers), or other control or computing devices.

0048Data and instructions (of the software) are stored in respective storage devices, which are implemented as one or more computer-readable or computer-usable storage media. The storage media include different forms of memory including semiconductor memory devices such as dynamic or static random access memories (DRAMs or SRAMs), erasable and programmable read-only memories (EPROMs), electrically erasable and programmable read-only memories (EEPROMs) and flash memories; magnetic disks such as fixed, floppy and removable disks; other magnetic media including tape; and optical media such as compact disks (CDs) or DVDs.

0049In the foregoing description, numerous details are set forth to provide an understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these details. While the invention has been disclosed with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover such modifications and variations as fall within the true spirit and scope of the invention.