Visualization and Movement Approach

Important:The product name for this user guide has changed from Foundation and Cloudscape to Business Service Discovery and Migration Planning. Previous UI pages known as Foundation have changed to Business Service Discovery. Previous UI pages known as CloudScape have changed to Migration Planning.

This approach works well in environments that are not heavily shared (no large DB farms or jboss/tomcat layers). We recommend having the application owners participate in this process as they can more rapidly disposition hosts based on their knowledge of the environment.

Run auto-grouping without the 95th group. This can sometimes result in large vertical stacks that may join together multiple stacks if they use a shared resource or an unmapped RSG (an infrastructure service that we have not identified yet).

Once you begin to go through AutoApp-xxx stacks, you can visualize them. In many cases you will see a single server or a small group of servers that link all of the hosts together. You can use the table following the visualization to see the actual application processes in use on the connections (if netstat data was collected).

Our auto generated groupings may group single applications or multiple if they share DBs for example. Your objective is to decide how to and if application stacks should be broken into smaller ones. You can then make a decision as to whether that host (or small group of hosts) should be enabled to link those groups together. (We have already decided YES, but you can overrule us!) If not, right click on the host, select Edit Stack Membership and create a new application stack to move the host into. You can then immediately close the visualization and re-open it, to see the result of your move.

The visualization may now show multiple clusters of servers. What you are seeing is the result that you will get the NEXT time you run Build App Stacks. You must re-run the auto-grouping to have the system break that stack apart, into two or more application stacks.

Once this has been completed you should disposition that group by giving it a friendly name that is meaningful to you and the business (e.g. AutoApp-xxx should be renamed to ApplicationName).

Repeat this process for each AutoApp_XXX Application Stack. All of this should be done with the application owners input. So while you may iterate a few times before you engage the application owner(s), they are critical to making the ultimate decisions on validating groups.

Tip:Remember to view connectivity data to check the inter-stack relationships and make sure that there are not any critical dependencies that would require further investigation or stack membership changes. This is also where you can check and verify that you don’t have unlicensed hosts using a service on a licensed node.