User manual NOVELL PLATESPIN ORCHESTRATE 2.0.2 ADMINISTRATOR REFERENCE 06-17-2009

[. . . ] novdocx (en) 13 May 2009 AUTHORIZED DOCUMENTATION Administrator Reference Novell® 2. 0. 2 June 17, 2009 PlateSpin® Orchestrate www. novell. com PlateSpin Orchestrate 2. 0 Administrator Reference novdocx (en) 13 May 2009 Legal Notices Novell, Inc. makes no representations or warranties with respect to the contents or use of this documentation, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. reserves the right to revise this publication and to make changes to its content, at any time, without obligation to notify any person or entity of such revisions or changes. makes no representations or warranties with respect to any software, and specifically disclaims any express or implied warranties of merchantability or fitness for any particular purpose. [. . . ] The Development Client is a robust desktop GUI designed for administrators to apply, manage, and monitor usage-based policies on all infrastructure resources. The Development Client also provides at-a-glance grid health and capacity checks. For more information, see the PlateSpin Orchestrate 2. 0 Development Client Reference. 18 PlateSpin Orchestrate 2. 0 Administrator Reference novdocx (en) 13 May 2009 Figure 1-6 PlateSpin Orchestrate Development Client Job Interface: Includes a customizable/replaceable Web application and the zosadmin command line tool. The Web-based Server Portal built with this API provides a universal job viewer from which job logs and progress can be monitored. PlateSpin Orchestrate Monitoring System: Monitors all aspects of the data center through an open source, Eclipse*-based interrface referred to as the PlateSpin Orchestrate VM Client. This interface operates in conjunction with the Orchestrate Server and monitors the following objects: Deployed jobs that teach PlateSpin Orchestrate and provide the control logic that PlateSpin Orchestrate runs when performing its management tasks. Users and Groups Virtual Machines For more information, see the PlateSpin Orchestrate 2. 0 VM Client Guide and Reference. Basic PlateSpin Orchestrate Concepts 19 novdocx (en) 13 May 2009 Figure 1-7 The PlateSpin Orchestrate VM Client Interface 1. 2 Understanding PlateSpin Orchestrate Functionality Section 1. 2. 1, "Resource Virtualization, " on page 20 Section 1. 2. 2, "Policy-Based Management, " on page 21 Section 1. 2. 3, "Grid Object Visualization, " on page 21 Section 1. 2. 4, "Understanding Job Semantics, " on page 22 Section 1. 2. 5, "Distributed Messaging and Failover, " on page 23 Section 1. 2. 6, "Web-Based User Interaction, " on page 24 1. 2. 1 Resource Virtualization Host machines or test targets managed by the Orchestrate Server form nodes on the grid (sometimes referred to as the matrix). All resources are virtualized for access by maintaining a capabilities database containing extensive information (facts) for each managed resource. This information is automatically polled and obtained from each resource periodically or when it first comes online. The extent of the resource information the system can gather is customizable and highly extensible, controlled by the jobs you create and deploy. The PlateSpin Orchestrate Virtual Machine Builder is a service of VM Management that allows you to build a VM to precise specifications required for your data center. You designate the parameters required: processor, memory, hard drive space, operating system, virtualization type, whether it is based on an auto-install file, and any additional parameters. When you lauch the build job, VM Builder sends the build request to a machine that meets the hardware requirements of the defined VM and builds the VM there. For more information, see "Creating a Xen VM" in the PlateSpin Orchestrate 2. 0 VM Client Guide and Reference. 20 PlateSpin Orchestrate 2. 0 Administrator Reference novdocx (en) 13 May 2009 1. 2. 2 Policy-Based Management Policies are aggregations of facts and constraints that are used to enforce quotas, job queuing, resource restrictions, permissions, and other user and resource functions. Policies can be set on all objects and are inherited, which facilitates implementation within related resources. Facts, which might be static, dynamic or computed for complex logic, are used when jobs or test scenarios require resources in order to select a resource that exactly matches the requirements of the test, and to control the access and assignment of resources to particular jobs, users, projects, etc. through policies. This abstraction keeps the infrastructure fluid and allows for easy resource substitution. An example of a policy that constrains the selection of a resource for a particular job or test is shown in the sample below. Although resource constraints can be applied at the policy level, they can also be described by the job itself or even dynamically composed at runtime. <policy> <constraint type="resource"> <and> <eq fact="resource. os. family" value="Linux"/> <gt fact="resource. os. version" value="2. 2" /> <and> </constraint> </policy> An example of a policy that constrains the start of a job or test because too many tests are already in progress is shown in the following sample: <policy> <!-- Constrains the job to limit the number of running jobs to a defined value but exempt certain users from this limit. All jobs that attempt to exceed the limit are qued until the running jobs count decreases and the constraint passes. --> <constraint type="start" reason="Too busy"> <or> <lt fact="job. instances. active" value="5"/> <eq fact="user. name" value="canary" /> </or> </constraint> </policy> 1. 2. 3 Grid Object Visualization One of the greatest strengths of the PlateSpin Orchestrate solution is the ability to manage and visualize the entire grid. This is performed through the PlateSpin Orchestrate Development Clientand the PlateSpin Orchestrate VM Monitoring System. The desktop Development Client is a Java application that has broad platform support and provides job, resource, and user views of activity as well as access to the historical audit database system, cost accounting, and other graphing features. [. . . ] Most systems are configured to have at least a "default" route, and on such systems, multicast messages use the default route like any other network traffic. Multicasting might not function correctly on systems that lack a default route. Attempts to send messages on such systems fail with a Network Unreachable message because the operating system is unable to determine the correct network interface on which to send the message. In some environments, however, it might not make sense to add a default route. [. . . ]