TIBCO DataSynapse Federator

Transcription

1 TIBCO DataSynapse Federator User Guide Software Release 2.1 October 2010

2 Confidentiality and Disclaimer Copyright 2010 TIBCO Software Inc. All Rights Reserved. Neither this document nor any of its contents may be used or disclosed without the express written consent of TIBCO. This document does not carry any right of publication or disclosure to any other party. While the information provided herein is believed to be accurate and reliable, TIBCO makes no representations or warranties, express or implied, as to the accuracy or completeness of such information. Only those representations and warranties contained in a definitive license agreement shall have any legal effect. In furnishing this document, TIBCO reserves the right to amend or replace it at any time and undertakes no obligation to provide the recipient with access to any additional information. Nothing contained within this document is or should be relied upon as a promise or representation as to the future. TIBCO products may include some or all of the following: Software developed by the Apache Software Foundation. Software developed by the OpenSSL Project for use in the OpenSSL Toolkit. Software developed by Sam Stephenson. Software developed by Yahoo! Inc. Code licensed from RSA Data Security. Spring Framework software. Code licensed under the Lesser Gnu Public License (LGPL) Repackaged JBoss Enterprise Middleware open source software. Product integration with the BEA WebLogic Server software developed and copyrighted by BEA Systems, Inc. Certain third party software is distributed by the BEA WebLogic Server. GridServer, and FabricServer software are a registered trademarks. TIBCO, the TIBCO logo, GridClient, GridBroker, FabricBroker, LiveCluster, VersaUtility, VersaVision, SpeedLink, Federator, and RTI Design are trademarks. GRIDesign is a registered servicemark of TIBCO Software Inc. WebLogic is a registered trademark of BEA Systems, Inc. WebSphere is a registered trademark and CloudScape is a trademark of International Business Machines Corporation in the United States, other countries, or both. Software developed using the Eclipse open source development platform. Software developed by the Massachusetts Institute of Technology. VMware, the VMware boxes logo and design, Virtual SMP and VMotion are registered trademarks or trademarks of VMware, Inc. in the United States and/or other jurisdictions. Portions copyright 2009 John Resig. PuTTY, copyright Simon Tatham. ANTLR Developed by Terence Parr. Copyright (C) MetaStuff, Ltd. All Rights Reserved. This product includes software licensed under the Eclipse Public License. The source code for such software licensed under the Eclipse Public License is available upon request to TIBCO and additionally may be obtained from This product includes HTML Parser software which is licensed under the Common Public License, v1.0. For a period of time not to exceed three years from the Purchase Date, TIBCO also offers to provide Customer, upon written request of Customer, a copy of the source code for this software. This product includes Javassist licensed under the Mozilla Public License, v1.1. You may obtain a copy of the source code from This product uses Open Thundergraph. Open Thundergraph is distributed pursuant to the terms of the Lesser General Public License. The source code for Open Thundergraph may be obtained from For a period of time not to exceed three years from the Purchase Date, TIBCO also offers to provide Customer, upon written request of Customer, a copy of the source code for Open Thundergraph. This product includes software developed by the Indiana University Extreme! Lab ( This product includes WSDL4J software which is licensed under the Common Public License, v1.0. The source code for this software may be obtained from TIBCO's software distribution site.

3 This product includes software licensed under the Common Developement and Distribution License (CDDL) version 1.0. The source code for such software licensed under the Common Developement and Distribution License (CDDL) version 1.0 is available upon request to TIBCO. Copyright (C) Jason Hunter & Brett McLaughlin. All rights reserved. Copyright (c) QOS.ch All rights reserved. This product includes software developed by the OpenSymphony Group ( This product includes Junit software which is licensed under the Common Public License, v1.0. For a period of time not to exceed three years from the Purchase Date, TIBCO also offers to provide Customer, upon written request of Customer, a copy of the source code for this software. Portions copyright Robert de Bath, Joris van Rantwijk, Delian Delchev, Andreas Schultz, Jeroen Massar, Wez Furlong, Nicolas Barry, Justin Bradford, Ben Harris, Malcolm Smith, Ahmad Khalifa, Markus Kuhn, Colin Watson, and CORE SDI S.A. Portions copyright 2005 Envoi Solutions LLC. All other product names are trademarks or registered trademarks of their respective companies. TIBCO products are protected by U.S. Patent No. 6,757,730, U.S. Patent No. 7,093,004 and U.S. Patent No. 7,130,891; other patents pending. TIBCO Software Inc., 3303 Hillview Avenue, Palo Alto, CA 94304, USA Tel: Fax: info@tibco.com Web: For technical support issues and product updates, please visit: support.tibco.com Change Value of VAR Book Title 3

4 Contents Chapter 1 - Introduction...5 Document Conventions...5 Chapter 2 - An Introduction to Federator...7 What Can I Do with Federator?...8 Chapter 3 - Installation...9 Setting up the Database...9 Configuring the Database Server...9 Setting up the JDBC Driver...10 Installing Third Party Libraries...10 Running Federator in FabricServer...10 Enabling DataSynapse Grids for Federator...12 Running Federator for the First Time...13 Creating an Administrator Account...13 Uploading Your License...13 Chapter 4 - Administration...15 Managing User Accounts...15 LDAP Configuration...15 Non-LDAP Configuration...17 Enabling and Disabling Accounts...18 Modifying Federator s Configuration and Licensing...18 Configuring Federator...19 Federator Licensing...21 Viewing Federator Logs...22 Monitoring Federator Activity...22 Alerts and Scheduler Events...23 Recent History...23 Migrating Resources...23 Policies...23 Additional Monitoring Pages...23 Chapter 5 - Working with Resource Managers...25 DataSynapse Resource Managers...25 Creating a New DataSynapse Resource Manager...25 Viewing or Editing a DataSynapse Resource Manager...26 Deleting DataSynapse Resource Managers...26 Enabling or Disabling a DataSynapse Resource Manager...27 EC2 Resource Managers...27 Creating a New EC2 Resource Manager...27 Viewing or Editing an EC2 Resource Manager...30 Enabling or Disabling an EC2 Resource Manager...30 Deleting EC2 Resource Managers...30 Proxy Servers for EC2 Resource Managers...30 Creating and Populating DataSynapse Resource Groups...31 Creating Static Resource Groups...32 Viewing or Editing a Static Resource Group...33 Deleting Static Resource Groups...33 TIBCO DataSynapse Federator User Guide 1

5 Assigning Resources to Static Resource Groups...34 Creating Dynamic Resource Groups...36 Deleting Dynamic Resource Groups...38 Rules for Finding Resources...39 Working with Static Resources...40 Using EC2 Resource Groups...40 Creating EC2 Resource Groups...41 Viewing or Editing an EC2 Resource Group...42 Deleting EC2 Resource Groups...43 Scheduling Resource Migration...43 Creating Placement Policy Intervals...43 Creating Demand Based Policy Intervals...45 Viewing or Editing a Policy Interval...47 Deleting Policy Intervals...47 Enabling or Disabling a Policy Interval...48 Resource Draining...48 Reclaiming Abandoned Resources Manually...48 Moving Resources Manually...49 Resource Migration Details...50 Target Configuration Changes, Target Manager Doesn t...50 Target Manager Changes, Configuration Doesn t, No Initial Configuration...50 Target Manager Changes, Configuration Changes, No Initial Configuration...50 Target Manager Changes, Configuration Changes, Initial Configuration Set...51 Chapter 6 - Platform as a Service...53 Using Platform as a Service...53 Definitions...53 Typical Usage...54 Configuring PaaS...55 Working with Tickets...56 Working with Applications...58 Working with Templates...59 Working with Images...60 Artifact Locking and Maintenance Mode...66 Appendix A - Database Configuration...67 Database-Specific Configuration...67 MySQL Installing MySQL...67 Setting Up the Federator Database...67 Setting Up Access Controls...68 Variable Values...68 Microsoft SQL Server Installing SQL Server...69 Setting Up the Federator Database...69 Variable Values...69 Oracle 10g...70 Installing Oracle 10g...70 Setting Up the Federator Database Contents

6 Variable Values...70 Sybase ASE Installing Sybase...71 Setting Up the Federator Database...71 Variable Values...71 Appendix B - Using Amazon EC2 with Federator...73 Federator and EC Configuring GridServer for Use with EC Obtaining an EC2 Account...73 Tools for Working with AWS and EC Configuring EC2 for Federator...74 Increasing the Instance Limit...74 Getting Access Identifiers and a Certificate Pair...74 Creating an Elastic IP Address...74 Creating Security Groups...75 Creating Key Pairs...75 Amazon Machine Images...75 AMIs on S Additional Resources...76 Appendix C - Web Services API Reference...77 The Federator Web Services API...77 ResourceManagerAdmin...77 ResourceGroupAdmin...78 PolicyIntervalAdmin...78 SharedResourceAdmin...79 Orchestration...79 Classes Used by the API...80 DatasynapseResourceGroupInfo...80 DynamicResourceGroupInfo...81 DynamicResourceRuleInfo...81 DatasynapseResourceManagerInfo...82 Ec2LaunchConfigInfo...82 Ec2ResourceManagerInfo...82 Ec2ResourceGroupInfo...83 PolicyIntervalInfo...83 DemandRuleInfo...84 ResourceInfo...84 SharedResourceInfo...85 TemplateInfo...85 ImageInfo...85 RuntimeVariableInfo...85 RightsInfo...85 ComponentStatusInfo...86 Third Party Software License Agreements...87 TIBCO DataSynapse Federator User Guide 3

7 4 Chapter 1

8 Chapter 1 Introduction This guide is your starting point for planning, installing, and configuring Federator for your site. Document Conventions Convention Explanation Example [bracketed italics] Variable user input Go to where [hostname] is the computer running your Engine. bold text Interface labels or options Enter your URL in the Address box and click Next. Courier New [FS Broker Dir] User input, directories, file names, file contents, and program scripts The directory where FabricServer is installed, such as c:\datasynapse or /opt/datasynapse. Run the script in the /opt/datasynapse directory. The files are located in [FS Broker Dir]/webapps/livecluster TIBCO DataSynapse Federator User Guide 5

9 Document Conventions 6 Chapter 1 Introduction

10 Chapter 2 An Introduction to Federator Federator extends the power of your existing DataSynapse grids by letting you move groups of resources among your FabricServer and GridServer grids. You can do this automatically through a schedule, through a schedule with demand based rules, or manually. In addition to resources running within your datacenter or organization, it can allow you to access virtual resources running in an external infrastructure such as Amazon s Elastic Compute Cloud (EC2). Federator also allows you to develop and deploy applications to your FabricServer grids using its Platform as a Service functionality. First, a few definitions: Resource In Federator, a resource is a DataSynapse Engine Daemon and all of its Engine instances. Resource Manager Resource managers represent sources and destinations for resources. There are two types of resource manager, as described below. DataSynapse Resource Manager DataSynapse resource managers represent FabricServer and GridServer grids. They are able to be both the source and target for resources. Virtual Resource Manager Virtual resource managers represent the source of resources from some virtual provider. Federator allows for Amazon EC2 resource managers, which are a type of virtual resource manager. Resource Group A resource group specifies multiple resources (Engine Daemons) and allows them to be manipulated as a single unit. Static Resource Group Static resource groups represent resources being explicitly shared by a DataSynapse resource manager for use in policies. Dynamic Resource Group Dynamic resource groups also represent resources used in policies, but they are comprised of resources determined at policy startup time by a set of criteria. TIBCO DataSynapse Federator User Guide 7

11 What Can I Do with Federator? Virtual Resource Group Virtual resource groups represent resources coming from virtual resource managers, such as Amazon EC2. Policy Interval A policy interval is the basic building block for scheduling resources in Federator. It defines which resource groups will be assigned to which target DataSynapse resource manager at what time of the day. Placement A policy interval that moves resource groups based upon the schedule. Demand Based A policy interval that moves a number of resources based upon the demand based rules. Platform as a Service This allows you to pre-configure application platforms (application servers, databases, etc.) to use as the basis for easily deploying new applications onto your FabricServer grid. Federator s Platform as a Service (PaaS) functionality is described in detail in Chapter 6, Platform as a Service. What Can I Do with Federator? Federator lets you do the following: Indicate which grids to federate by associating a DataSynapse resource manager with each grid. Federator lets you federate the following types of DataSynapse grids: GridServer 4.2 (update 10 or later) GridServer 5.0 GridServer 5.1 FabricServer 2.6 FabricServer 3.0 Designate which resources on the federated grids are shareable, by assigning them to resource groups. Create virtual resource managers to provide additional resources for your grids to use. In the case of Amazon EC2 resource managers, these resources run on instances of virtual machines in Amazon s Elastic Compute Cloud. Move resources among federated grids, either manually, according to schedules, or demand based rules. Monitor federated grids for (and repair) potential problems. Create templates for FabricServer applications for developers to use. Develop applications for FabricServer based on templates and manage their deployment life cycle. Maintain a repository of FabricServer applications independent of the brokers they are deployed to and run on. 8 Chapter 2 An Introduction to Federator

12 Chapter 3 Installation Federator installation is a multi-step process involving the following tasks: Setting up the Database Installing Third Party Libraries Running Federator in FabricServer Enabling DataSynapse Grids for Federator Running Federator for the First Time Before you set up Federator, you should be familiar with installing and configuring Domains to run on FabricServer. For more details, see the FabricServer Admin Guide. Setting up the Database Federator requires a relational database to maintain its data. You must provide the database server and set it up with user credentials, permissions, and a database for Federator to use. When you set up the Federator Domain on FabricServer (see Running Federator in FabricServer on page 10), you specify information that allows Federator to find and use the database. Configuring the Database Server Setting up the database is similar, regardless of the particular database server you are using. (Federator has been tested with MySQL 5.0, Oracle 10g, Microsoft SQL Server 2005, and Sybase ASE 12.5 databasespecific information for configuring these can be found in Appendix A, Database Configuration, on page 67.) See Running Federator in FabricServer on page 10 for details on setting database-related configuration variables. 1. Install the database server according to the manufacturer s directions. 2. Create a user for Federator to log in as. By default, Federator will use the username federator and the password server to connect, but these can be changed when configuring the Federator Domain (using the DB_USERNAME and DB_PASSWORD variables, respectively). 3. Create a database for Federator to use. By default, Federator will look for a database named federator_prod but you can specify the name of the database when configuring the Federator Domain (as part of the DB_URL variable). 4. Set up access controls so that the engine machines where the Federator Domain will be running will be able to connect to the database and that the Federator account (for example, federator ) will have full access to the newly created database. The first time that Federator starts and connects to the database, it creates all tables and indices it requires; there is no need to run a set-up script to do this. TIBCO DataSynapse Federator User Guide 9

13 Installing Third Party Libraries Setting up the JDBC Driver Federator needs to have access to the JDBC driver for your particular database in order to communicate with it. You can set this up in one of two ways: you can manually put the driver JAR file at a known location on the Engine machines where Federator will run (at the same location on every machine) or you can bundle the JAR file into your Federator Domain using the FabricServer user interface. In either case, you must tell Federator where the JAR file is using the EXTERNAL_JDBC_JAR variable in the Domain. If you installed the JAR on each Engine machine manually, set this variable to the path you used. If you bundled the JAR into the Domain, specify the path relative to the grid library using a value such as ${CATALINA_BASE}/jars/[JDBC JAR file name] (see Running Federator in FabricServer, below). Installing Third Party Libraries Federator requires the installation of third party libraries into the grid library archive. Install the libraries as follows: 1. Download the patch jar federator_third_party_libs.jar. 2. Apply the patch file: java -jar federator_third_party_libs.jar [path to federator-gridlib.zip] Running Federator in FabricServer Federator is designed to run as a Domain on top of DataSynapse FabricServer. Federator works with version of FabricServer. Install FabricServer according to the installation instructions in the FabricServer Installation Guide. Install the FabricServer Engine software on at least one machine (the FabricServer license that comes with Federator allows for up to two Engine Daemons). Install Federator on FabricServer as follows: 1. Copy the Federator-related grid libraries to your FabricServer Broker s [FS Broker Dir]/webapps/livecluster/deploy/resources/gridlib directory. They are: federator-gridlib.zip, tomcat55-container-gridlib.zip, and tomcat55-distribution-gridlib.zip. If you are using Federator with Amazon EC2, and Federator will be running on a Windows engine, you will also need to include squid-win32-distribution-gridlib.zip. 2. Log in to the FabricServer administration tool. 3. Verify that the existence of the Application Component called Federator. 4. If you want to include the JDBC driver JAR file as part of the Federator grid library, upload it as a configuration file on the Add/override/customize Container and Component-specific config files page of the Application Component wizard for Federator. For example, set the relative path to jars, choose Any for the operating system, and make sure Resolve Variables is not checked. 10 Chapter 3 Installation

14 5. Edit the variables for the Federator Application Component using the Add/override/edit Container and Component-specific runtime context variables page of the Application Component wizard. The values will depend on how you configured your database as well as which database product you are using. The variables are described below: Variable Name Description Default Value DB_USERNAME DB_PASSWORD DB_DRIVER_CLASS DB_URL EXTERNAL_JDBC_JAR The username used to connect to the database. federator The password used to connect to the database. server The fully qualified class name of the JDBC driver used for communication with the database. This depends on the database and JDBC driver you are using. See your database manufacturer s documentation for details. The URL for the database in use. Note that the URL contains the name of the database you created for Federator to use. The format and contents of the URL depend on the particular database and JDBC driver you are using. See your database manufacturer s documentation or for details. The full path to the JDBC driver JAR file. This may either be the path to the install location of the JAR file if you installed it manually (e.g. C:\jdbc\mysql-connector-java bin.jar), or a path relative to the Tomcat Container variable CATALINA_BASE if you included the JAR file in your Domain in Step 4, above (e.g. ${CATALINA_BASE}/jars/mysql-connectorjava bin.jar). com.mysql.jdbc.driver jdbc:mysql://localhost:3306 /federator_prod?autoreconne ct=true blank JAVA_OPTS SSL_CLIENT_TRUST_STORE_FI LE SSL_CLIENT_TRUST_STORE_PA SSWORD Memory options for the Java Virtual Machine running Federator. The default is to use 1GB for Federator. The full path to the trust store required if you connect to managers via secure connections (i.e. via HTTPS). Leave this blank to use the default DataSynapse trust store on GridServer or FabricServer. The password used for the trust store specified by SSL_CLIENT_TRUST_STORE_FILE. If using the default DataSynapse trust store, leave this blank. -Xmx1g Xms1g blank blank TIBCO DataSynapse Federator User Guide 11

15 Enabling DataSynapse Grids for Federator 6. Create a Federator Application that includes the Federator Application Component and is scheduled to run continuously. 7. Deploy the Application Component and the Application Federator should be copied to the engine and start running. Enabling DataSynapse Grids for Federator To enable DataSynapse grids for federation, run the EnablerInstaller JAR file included with your copy of Federator. NOTE: You must enable all servers associated with a given grid to be able to federate that grid. This includes all Directors and Brokers as well as any failover servers (but not Engines). To run the enabler, do the following: 1. Type the following from into the command shell from the directory containing the enablement JAR file: java -jar EnablementInstaller.jar [path to GridServer/FabricServer installation] For example, the path might be /opt/datasynapse/webapps/livecluster. 2. Check the output from the command line for a message indicating a successful installation. When successful, the installer will have added an enablement[version].properties file to the server to record the installation. NOTE: The enablement version shown in the message may not match your GridServer or FabricServer update version exactly, as some enablement versions support multiple service release levels. If you update FabricServer or GridServer after applying an enablement, updating the Federator enablement may also be required. To determine if an updated enablement is required, re-run the EnablementInstaller. Any required updates install automatically; if no update is required, no changes will occur. 12 Chapter 3 Installation

16 Running Federator for the First Time Once Federator has started up on the FabricServer Engine, you are ready to log in for your first session. Open your web browser and point it to the Federator Domain. FabricServer s Virtual Router makes it available at a constant URL, regardless of which Engine it is actually running on. Append /federator to your FabricServer URL (for example, to get the URL where Federator is running. When you first launch Federator, you will need to do two things: create an initial administrator account and upload your license file. Creating an Administrator Account Simply enter the username and password for the initial administrator account (retype the password to verify it) and click the Create and Login button. Federator will create the new account and log you in using it. You will probably want to create additional accounts for Federator users, as described in Creating User Accounts on page 17. Uploading Your License In the top banner, Federator will display a flashing key icon indicating a problem with the license for the product. If you hover over the key, you ll see a message indicating what the problem is. When you first install Federator, the error will be that there is no license installed. You ll need to install the license file you received with Federator. 1. Click the blinking key icon to go to the License page. 2. Click the Browse or Choose File button to browse for the license file it should be called license.ser. TIBCO DataSynapse Federator User Guide 13

17 Running Federator for the First Time 3. Click the Upload button to install the license. You should see a message that the license was successfully installed and the flashing key icon should now be steady and white. Your Federator installation is now ready. 14 Chapter 3 Installation

18 Chapter 4 Administration This chapter discusses common Federator administrative tasks such as Creating User Accounts and Modifying Federator s Configuration and Licensing. Managing User Accounts Federator gives you the option of managing all of your user accounts within Federator itself or of using an external LDAP server to provide account validation. Regardless of which method you configure, user accounts in Federator fall into one or more of the following permission categories (an individual user account may be assigned to one or more of these categories): View-Only User accounts have permission to view most of Federator's functionality, outside of the Platform as a Service pieces. Federator User accounts have permission to access most of Federator's functionality, outside of the Platform as a Service pieces. They can create, modify, and use Resource Managers, Resource Groups, and Policy Intervals. They cannot manage user accounts or configure parameters on the Admin tab of the UI. PaaS User accounts have permission to access the Templates and Images used to deploy applications to FabricServer. Individual accounts may have permissions added for specific Image objects, but can always submit requests for any action they need to accomplish (though a PaaS Administrator user may need to approve them). PaaS Administrator accounts have permission to access all of the PaaS-related functionality in Federator-the permissions afforded PaaS User accounts plus the ability to create templates and import images directly from FabricServer and to configure the PaaS-related parameters on the Admin tab. Administrator accounts have permission to do anything any of the other types of accounts can do. In addition, they can administer user accounts and perform all configuration of Federator on the Admin tab. LDAP Configuration If your organization has an LDAP server that you wish to use for authentication of users in Federator, you can configure this on the LDAP page of the Admin tab in the UI. NOTE: Enabling LDAP means that you will not be able to create and edit non-ldap accounts other than the initial Administrator account. Also, since Federator accesses the LDAP server in a read-only manner, you will need to use other tools to modify users and their attributes on the LDAP server. TIBCO DataSynapse Federator User Guide 15

19 Managing User Accounts If you check the Enable LDAP Authentication checkbox, then the remaining fields on the page are enabled. You configure LDAP as follows: Parameter Description Default Value LDAP Server Manager Username Manager Password Search Subtrees User Search Base User Search Filter Group Search Base Group Search Filter Group Role Attribute Attribute Federator User Group(s) Federator Admin Group(s) PaaS User Group(s) PaaS Admin Group(s) The URL for the LDAP server. It should include the port number and start with ldap:// The username that Federator uses to log into the LDAP server. The password that Federator uses to log into the LDAP server. Check this if you want to search the LDAP trees deeply as opposed to just at the search bases. The search base to use when locating users in the LDAP directory. A filter to use when locating users in the LDAP directory. The search base to use when locating groups in the LDAP directory. A filter to use when locating groups in the LDAP directory. The attribute on the group record which indicates the role name. The attribute on the user record which indicates the user s address The group or groups whose members should have Federator User access to the system. (A comma-delimited list if more than one.) The group or groups whose members should have full Federator Admin access to the system. (A comma-delimited list if more than one.) The group or groups whose members should have PaaS User access to the system. (A comma-delimited list if more than one.) The group or groups whose members should have PaaS Admin access to the system. (A comma-delimited list if more than one.) ldap://localhost:389 blank blank Checked blank (cn={0}) blank uniquemember={0} cn 16 Chapter 4 Administration

20 Parameter Description Default Value View-Only User Group(s) The group or groups whose members should have View-Only access to the system. (A comma-delimited list if more than one.) Non-LDAP Configuration If you are not using an LDAP server to manage Federator's user authentication, you will need to create accounts for the users in your system. Creating User Accounts To create new accounts, do the following: 1. Click the Users tab. The Users page appears. 2. Click New. The Create User page appears. 3. Enter the log-in credentials and other information to create the user account. 4. Click Create. The new account is created and appears in the list of users. NOTE: Only admin users can create user accounts. Editing Accounts To edit an existing account, do the following: 1. Click the Users tab. The Users page appears. If you are not an admin user, you are brought directly to the Show User page for your account and you can skip over step 2. TIBCO DataSynapse Federator User Guide 17

21 Modifying Federator s Configuration and Licensing 2. Click the login name of the user you wish to edit. The Show User page for that user appears. 3. Click Edit. (As a shortcut, you can get to the Edit page by clicking the edit (pencil) icon for the user on the list page.) 4. Make the desired changes. 5. Click Update. The account is updated with the new information. NOTE: If you are logged on as a non-admin-level user, you can only edit the password, full name, and description fields, and only of your own account. Deleting Accounts To delete an account, click the delete (trash can) icon next to its name in the list. NOTE: Only admin users can delete user accounts. Enabling and Disabling Accounts To change whether a user account is enabled, do the following: 1. Click the Users tab. The Users page appears. 2. Click the login name of the user you wish to edit. The Show User page for that user appears. 3. Click Enable or Disable. The button that appears depends on the current state of the account if the account is currently enabled, the button reads Disable, and vice-versa. After you click the button, the account s status changes. (As a shortcut, you can click the enable or disable icon for the user on the list page.) NOTE: Only admin users can enable or disable accounts, and even admin users cannot disable the account they re currently logged in with. Modifying Federator s Configuration and Licensing If you are an admin user, you can change the configuration parameters Federator uses in the user interface as well as upload license files. These are done using the Admin tab. 18 Chapter 4 Administration

22 Configuring Federator On the General page of the Admin tab you can specify global parameters affecting how Federator runs. To edit them, simply change one or more values and click the Update button (click Revert to undo any changes you have made). The parameters you can configure are: Parameter Description Default Value Logging Level Scheduler Interval Scheduler Minimum Interval Migration Timeout The level of granularity of the information contained in Federator s logs. The default setting, Info, provides standard informational output and should be appropriate most of the time. Changing this setting to Debug, Trace, or All increases the amount of information written to the logs and can be helpful when troubleshooting problems. See Viewing Federator Logs on page 22 for more details about Federator s logging. The interval between runs of Federator s scheduler, in seconds. The shorter this interval, the more often Federator reallocates resources among your DataSynapse Resource Managers. While resources are being migrated among resource managers, the short scheduler interval (see below) is used instead, to provide more responsive migration. The scheduler interval must be greater than or equal to the minimum interval (see below). The interval between runs of Federator s scheduler while resources are being migrated, in seconds. The two intervals work in tandem to allow your Federator to only poll frequently for resource status from the managers while migration is occurring. The minimum interval must be at least 5 seconds and less than or equal to the scheduler interval (see above). The time, in minutes, that migrating Engine Daemons have to log into their new target resource manager. If they fail to do so within in this time frame, Federator will generate an alert. Info 60 seconds 5 seconds 3 minutes TIBCO DataSynapse Federator User Guide 19

23 Modifying Federator s Configuration and Licensing Parameter Description Default Value Alert Timeout Statistics Expiration Policy Interval Minimum License Expiration Warning Amazon EC2 Parameters Enable Proxy Local Proxy Hostname The time, in minutes, that the alert panel on the dashboard will keep alerts visible. [Alerts are visible on the drill-down pages until they end of the Statistics Expiration period (see below).] The time, in days, that statistics, scheduler events, and alerts are maintained in Federator s database. Information older than this will be removed. The minimum duration, in minutes, that policy intervals must have when created. If you try to create a policy interval shorter than this, Federator will show an error and force you to lengthen the interval. The amount of time, in days, before your license expires that Federator will begin warning you of the impending expiration. During this period, Federator will show a warning when you log on and the license (key) icon at the top of the pages will flash red. This should be checked to enable the proxy server on the Federator machine which the cloud-side proxy (running on an EC2 instance) can talk through via an SSH connection. If you want to configure your cloud-side proxy to use some other mechanism for secure communication, you can disable this. See Proxy Servers for EC2 Resource Managers on page 30 for details. NOTE: This setting should only be changed if you are an advanced user and are sure what you are doing or your EC2 engines will cease to work properly. The hostname for the local proxy server. Only change this value if you want to host your own proxy server and have Federator manage the SSH connection. 60 minutes 30 days 15 minutes 30 days Checked localhost 20 Chapter 4 Administration

24 Parameter Description Default Value Startup Timeout Shutdown Threshold The time, in minutes, that Engine Daemons on EC2 instances have to log into their target resource manager. If they fail to do so within this time frame, Federator will generate an alert. The time, in minutes, that an EC2 resource group must be idle (not specified in a current policy) before Federator will terminate its instances. For example, if you have two policies that use a particular EC2 resource group and the second one starts within this threshold from the time the first one ends, Federator will simply migrate the already running EC2 instances to the new target rather than terminating the instances and spinning up new ones. This can diminish the time spent waiting for instances to start. 20 minutes 20 minutes Federator Licensing On the Licensing page of the Admin tab you can see information about the currently installed license and also upload a new license file to replace the current one. The License Details section shows when your license will expire, the version of Federator you are running, how many DataSynapse resource managers you are allowed to have, which virtual resource providers, if any, you are allowed to use, and whether the license restricts you to running on particular hosts. To upload a new license file: 1. Click the Admin tab. The General page appears. 2. Click the Licensing sub-navigation link. The Licensing page appears. 3. Click the Browse or Choose File button (the name depends on the web browser you are using) in the License Upload section and locate the new license file you want to upload (usually named license.ser). 4. Click the Upload button to upload the license file to Federator. Federator validates the license and updates the page to show the new details. TIBCO DataSynapse Federator User Guide 21

25 Viewing Federator Logs To view the current Federator log, do the following: 1. Access the administration tool for the FabricServer grid where Federator is running. 2. Navigate to System > Engine Admin. 3. Select the Log URL List action in the row for the Engine that is running Federator. 4. Click on the link labeled federator.log. Viewing Federator Logs NOTE: When you restart Federator, it archives the previous log file and starts a new one (Federator will also automatically switch its log file and archive when the file s size reaches 10MB). The three most recent archived logs are visible on the page as well, named federator.log.1, federator.log.2, and federator.log.3. Monitoring Federator Activity Click Federator s Activity tab at any time to monitor current Federator activity. The Activity Dashboard is divided up into sections that show: The most recent alerts regarding problems migrating resources (within the alert timeout specified on the configuration page; the default is within the last hour) A chart showing the history of resource migration (within the past hour) A list of any resources currently being migrated, and A list of active policies as well as any policies that are scheduled to become active within the next hour Each of these sections provides links that let you drill down and find out more detail about its contents. The activity dashboard automatically updates itself periodically you don t need to refresh it manually. 22 Chapter 4 Administration

26 Alerts and Scheduler Events When Federator s scheduler detects resource changes, it creates and logs change events. Some important change events that merit the administrator s attention are also shown as alerts. The Latest Alerts panel has two links (More Alerts and All Events ) that take you to detail pages (Alerts and Scheduler Events, respectively) that show all the alerts and events currently on record in the Federator database. If you want to acknowledge an alert and allow room for others to be displayed on the panel abbreviated list, click the delete button next to the alert and it will be removed from the panel (it will remain on the drill-down pages). Alerts and other events are kept for a period determined by the configuration property named Statistics Expiration (thirty days by default), though the panel on the dashboard only shows alerts for the Alert Timeout period (one hour by default). See Configuring Federator on page 19 for details. Recent History The Recent History chart shows the number of resources allocated to various DataSynapse resource managers over the past hour. Clicking the More button will show the Resource History page with a moredetailed chart. Here you can specify which managers resources to include, and the exact time frame you d like to see. Migrating Resources The Migrating Resources panel shows resources which are in the process of being migrated to a new target DataSynapse resource manager. These are resources which have been told to move but which haven t yet logged into the target s Director or Broker. The list is limited to the five most recently migrated resources. To see the full list, click the All link to go to the Migrating Resources page. (Note that the link tells you how many total migrating resources there are.) Policies The Active Policies panel shows you the policy intervals which are currently active. It will show up to five policies click the More link to see them all. The Upcoming Policies panel shows any policies which are scheduled to start within the next hour. Additional Monitoring Pages In addition to the Activity Dashboard and its drill-down pages, you can see information about the state of Federator using pages available throughout Federator s user interface. For details, see: Viewing or Editing a DataSynapse Resource Manager on page 26 Viewing or Editing an EC2 Resource Manager on page 30 Viewing or Editing a Static Resource Group on page 33 Creating Dynamic Resource Groups on page 36 Viewing or Editing an EC2 Resource Group on page 42 Viewing or Editing a Policy Interval on page 47 Reclaiming Abandoned Resources Manually on page 48 TIBCO DataSynapse Federator User Guide 23

27 Monitoring Federator Activity 24 Chapter 4 Administration

28 Chapter 5 Working with Resource Managers Federator uses the concept of resource managers to keep track of the various external servers with which it interacts when manipulating resources (Engine Daemons). There are two types of resource managers, DataSynapse resource managers and virtual ones. DataSynapse resource managers represent GridServer Directors and FabricServer Brokers, and can be both the sources of the resources Federator works with and also the targets to which resources are migrated. Virtual resource managers such as those for Amazon EC2, on the other hand, only contribute resources which Federator can make available to your grids. This chapter will help you set up the resource managers necessary to federate your grids. DataSynapse Resource Managers In Federator, DataSynapse resource managers represent your GridServer and FabricServer grids. Each resource manager is associated with a Director (for GridServer grids) or Broker (for FabricServer grids) and contains the URLs and credentials that allow Federator to communicate with the grid. Federator communicates with DataSynapse resource managers to find out about resources logged into the grid, to tell resources to migrate to a different grid, and to see the status of migration. You will create a DataSynapse resource manager for each GridServer or FabricServer grid you want to federate. Creating a New DataSynapse Resource Manager To create a DataSynapse resource manager, do the following: 1. Click the Resource Managers tab. The Resource Managers summary page appears. 2. Click DataSynapse in the Type column to show the list of DataSynapse resource mangers. 3. Click New. The Create DataSynapse Resource Manager page appears. 4. Enter information about your grid: Name: Enter a name for the resource manager. Resource managers are referred to by name when specified in resource groups and policy intervals. Description: Optionally, enter a description for the resource manager. Primary Manager URL: Enter the URL to your grid the Director for a GridServer grid or Broker for a FabricServer grid. This is generally in the form Secondary Manager URL: If your grid has a secondary, i.e. failover, manager, enter its URL here. If not, leave this field blank. Admin Username: Enter the username that Federator should use when connecting to your grid. This user must have administrative privileges for the grid. Admin Password: Enter the password that Federator should use when connecting to your grid with the given username. (Note that all passwords are stored encrypted within Federator.) TIBCO DataSynapse Federator User Guide 25

29 DataSynapse Resource Managers PaaS Tag: Choose the tag used by the PaaS subsystem to categorize this resource manager among the various environments where applications can be deployed. The list of tags available is configured on the PaaS Configuration page (see Configuring PaaS on page 55). Note that PaaS tags only apply to FabricServer 3.0 resource managers. Also, users with no PaaS permissions (e.g. Federator User accounts) will not see the PaaS Tag field. 5. Click Test to make sure you entered the information correctly. Test can reveal the following types of problems: Whether you ve typed an incorrect URL Whether you ve typed incorrect login credentials Whether the grid hasn t yet been enabled for Federator (see Enabling DataSynapse Grids for Federator on page 12) 6. Correct any errors that appear and test again until the errors are resolved. 7. Click Create. The DataSynapse resource manager is created for the specified grid and appears in the list of resource managers. Viewing or Editing a DataSynapse Resource Manager To view or edit an existing resource manager, do the following: 1. Click the Resource Managers tab. The Resource Managers summary page appears. 2. Click DataSynapse in the Type column to show the list of DataSynapse resource mangers. 3. Click the name of the resource manager you want to view or edit. It appears on the Show DataSynapse Resource Manager page. 4. If you want to edit the values, click the Edit button to show the Edit DataSynapse Resource Manager page. (As a shortcut, you can get to the Edit page by clicking the edit (pencil) icon for the resource manager on the list page.)` 5. Make any changes you want and click Update to save them. Note that you can use the Test button when editing a resource manager to validate your changes just as when you created it. Deleting DataSynapse Resource Managers To delete a resource manager, click the delete (trash can) icon next to its name in the list. 26 Chapter 5 Working with Resource Managers

30 Enabling or Disabling a DataSynapse Resource Manager Federator lets you enable and disable resource mangers. Since Federator ignores disabled resource managers when migrating resources, disabling one can be useful when that grid is temporarily unavailable. To enable or disable a resource manager, do the following: 1. Click the Resource Managers tab. The Resource Managers summary page appears. 2. Click DataSynapse in the Type column to show the list of DataSynapse resource mangers. 3. Click the name of the resource manager you want to modify. It appears on the Show DataSynapse Resource Manager page. 4. Click Enable or Disable to modify the resource manager (if the resource manager is currently enabled, the button says Disable, and vice-versa). (As a shortcut, you can click the enable or disable icon for the resource manager on the list page.) EC2 Resource Managers An EC2 resource manager represents a connection to the Amazon Web Services (AWS) Elastic Compute Cloud (EC2) service. Using an EC2 resource manager, Federator can launch Engine Daemons in the Amazon cloud which can be assigned to your DataSynapse resource managers in order to do work as part of your grids. In order to use EC2 resource managers, you must set up an account with Amazon and properly configure it. See Appendix B, Using Amazon EC2 with Federator, on page 73 for more details. Many of the fields used to specify an EC2 resource manager govern the manager s proxy server. For more about proxy servers, see Proxy Servers for EC2 Resource Managers on page 30. Creating a New EC2 Resource Manager To create an EC2 resource manager, do the following: 1. Click the Resource Managers tab. The Resource Managers summary page appears. 2. Click Amazon EC2 in the Type column to show the list of EC2 resource mangers. 3. Click New. The Create Amazon EC2 Resource Manager page appears. (Note that some of the fields on the page are not populated until you fill in others. For example, the Elastic IP pop-up list isn t populated until you specify the access keys for your EC2 account.) 4. Enter the information about your EC2 account: Name: Enter a name for the resource manager. Resource managers are referred to by name when specified in resource groups. Description: Optionally, enter a description for the resource manager. Engine Instance Limit: Enter the maximum number of instances you want to run on this account (this limit does not include the proxy server s instance, which will always run while the EC2 resource manager is enabled). AWS Access Key ID: Enter the AWS access key ID for your AWS account. Secret AWS Access Key: Enter the secret access key for your AWS account. The two keys are used to allow Federator to log onto EC2 on your behalf. See Getting Access Identifiers and a Certificate Pair on page 74 for more about access keys. TIBCO DataSynapse Federator User Guide 27

31 EC2 Resource Managers Region: Choose the EC2 region your resource manager will run in. If you want to run Engines in multiple regions, you will need to create one EC2 resource manager for each region. (Note that Amazon may charge different fees based on regions.) Elastic IP: Choose the IP address to use for the proxy instance. The list shows the elastic IP addresses configured for your account and indicates which ones aren t currently bound to a running instance. See Creating an Elastic IP Address on page 74 for more about elastic IP addresses. AWS Image: Choose the Amazon Machine Image (AMI) to use for the proxy server associated with this EC2 resource manager. (Note that this list is filtered to only show images with proxy in their manifest name.) Instance Type: Choose the instance type to use when running the proxy server. The instance type determines how much processing power and disk space the instance will have. Standard instances may be small, large, or extra large. High-CPU instances may be medium or extra large. Note that the values in this list change to reflect the types appropriate for the image you have chosen. For the proxy server, you will want to use a standard type the size will be determined by the size of the grid resources you need to cache. For specific details on the instance types and their pricing, see the EC2 website. Security Groups: You can choose one or more of the EC2 security groups defined in your account for the proxy server to run in. Generally, you would have defined a security group specifically for the proxy server and would choose that group here (see Creating Security Groups on page 75). Availability Zone: Choose the availability zone for the proxy server. Choose Automatic to let Amazon choose for you at start-up time. User Data: You should only enter user data here if you are using a custom AMI for the proxy server and it requires this field. Kernel ID: You should only enter a kernel ID here if you are using a custom AMI for the proxy server and it requires this field. Ram Disk ID: You should only enter a kernel ID here if you are using a custom AMI for the proxy server and it requires this field. 28 Chapter 5 Working with Resource Managers

32 Block Device Mappings: You should only enter block device mappings if you are using a custom AMI for the proxy server and it requires this field. This field maps block devices from Amazon Elastic Block Store (EBS) to devices visible to the instance. The format is the same as for the run-instances command in the command-line interface see Amazon s documentation for details. 5. Click Test to make sure you entered the information correctly. Test can reveal the following types of problems: Whether any of the required fields are missing Whether any of the fields values are incompatible with one another Whether you ve typed incorrect access keys Whether there are communication issues talking to the EC2 server 6. Correct any errors that appear and test again until the errors are resolved. TIBCO DataSynapse Federator User Guide 29

33 EC2 Resource Managers 7. Click Create. The EC2 resource manager is created and appears in Federator s list. Viewing or Editing an EC2 Resource Manager To view or edit an existing resource manager, do the following: 1. Click the Resource Managers tab. The Resource Managers summary page appears. 2. Click Amazon EC2 in the Type column to show the list of EC2 resource mangers. 3. Click the name of the resource manager you want to view or edit. It appears on the Show Amazon EC2 Resource Manager page. 4. If you want to edit the values, click the Edit button to show the Edit Amazon EC2 Resource Manager page. (As a shortcut, you can get to the Edit page by clicking the edit (pencil) icon for the resource manager on the list page.) 5. Make any changes you want and click Update to save them. The fields are the same as when creating an new EC2 resource manager. Note that you can use the Test button when editing a resource manager to validate your changes just as when you created it. Enabling or Disabling an EC2 Resource Manager Federator lets you enable and disable resource mangers. Federator uses the enabled state of EC2 resource managers to know start and stop the associated proxy server instance (see Proxy Servers for EC2 Resource Managers on page 30 for more about proxy servers). To enable or disable a resource manager, do the following: 1. Click the Resource Managers tab. The Resource Managers summary page appears. 2. Click Amazon EC2 in the Type column to show the list of EC2 resource mangers. 3. Click the name of the resource manager you want to modify. It appears on the Show Amazon EC2 Resource Manager page. 4. Click Enable or Disable to modify the resource manager (if the resource manager is currently enabled, the button says Disable, and vice-versa). As mentioned above, the proxy server will be started or stopped by this action. (As a shortcut, you can click the enable or disable icon for the resource manager on the list page.) Deleting EC2 Resource Managers To delete an EC2 resource manager, click the delete (trash can) icon next to its name in the list. Proxy Servers for EC2 Resource Managers EC2 resource managers use proxy servers to allow Engines in the Amazon cloud to securely communicate with the Directors and Brokers in your corporate network. To do this, the Federator starts up a machine instance in the cloud according to the parameters specified when configuring the resource manager (see Creating a New EC2 Resource Manager on page 27 for details about these parameters). It also starts up a corresponding server on the Federator machine inside your network. Then, the servers create a secure tunnel for communication, using SSH. In order for the Engine Daemons to be able to communicate with the grids 30 Chapter 5 Working with Resource Managers

34 they re assigned to, the proxies must be running on both ends of the tunnel. When running on a Windows engine, the Federator-side proxy requires that the Squid grid library be installed on the FabricServer hosting Federator. See Running Federator in FabricServer on page 10 for details. The proxy server also caches the grid resources that are transferred when Engine Daemons synchronize with their Brokers. This helps to minimize the network traffic into and out of the Amazon cloud. Depending on the quantity of data your grids need to synchronize, you may wish to alter the instance type used for the proxy server to provide more storage. Downloading the Proxy s Key Pair Federator automatically tells Amazon to generate an X.509 key pair to use for the SSH tunnel; the key pair s name is based on the elastic IP address chosen for the proxy. (If you like, you can use this key pair when setting up EC2 resource groups so that the EC2 instances running Engines use the same encryption key. See Creating EC2 Resource Groups on page 41 for details about configuring EC2 resource groups. See Creating Key Pairs on page 75 for more about generating key pairs in Amazon.) You can download the proxy s key data as a PEM file if you need to securely connect to the proxy server instance yourself. To do so: 1. Click the Resource Managers tab. The Resource Managers summary page appears. 2. Click Amazon EC2 in the Type column to show the list of EC2 resource mangers. 3. Click the name of the resource manager whose key you want to download. It appears on the Show Amazon EC2 Resource Manager page. 4. Click Download Proxy Key. Your browser should start downloading the PEM file, which will be named fed-[proxy IP Address]-keypair.pem. See the documentation that came with your SSH tools for details on using the PEM file to access the cloud-based proxy machine. Creating and Populating DataSynapse Resource Groups Like resource managers, resource groups come in two flavors: DataSynapse resource groups and virtual resource groups (including EC2 resource groups). DataSynapse resource groups represent resources shared into Federator by DataSynapse resource managers (i.e. FabricServer and GridServer grids) while EC2 resource groups represent resources shared by EC2 resource managers. This section describes DataSynapse resource groups; EC2 resource groups are described later; see Using EC2 Resource Groups on page 40. GridServer and FabricServer resources are not assigned to resource groups by default. To use Placement policies to control migration of resources, you must assign them to DataSynapse resource groups. DataSynapse resource groups are divided into static and dynamic groups. Note that resources are not assigned to resources groups may still be migrated to satisfy Demand-Based policy intervals. Static resource groups contain, as their name implies, a static set of resources. Resources in a static resource group are migrated en masse to the target resource manager while they re in use by an active policy interval. When not in use, resources in a static group return to the resource manager (and configuration) designated as the default for that group. You add resources to a static resource group by selecting them on one of the resource pages in the user interface and then explicitly adding them to the group. TIBCO DataSynapse Federator User Guide 31

35 Creating and Populating DataSynapse Resource Groups Dynamic resource groups, on the other hand, contain potentially a different set of resources every time they are used. Dynamic groups contain a set of rules which specify their resources. When a dynamic resource group comes into effect as part of an active policy interval, its set of rules is used to find available resources. These resources are added to the group only for the duration of the current policy interval, after which time they revert back to the resource managers they had been assigned to prior to being grouped. The sections that follow discuss creating, populating, and using these types of DataSynapse resource groups in more detail. Creating Static Resource Groups To create a static DataSynapse resource group, do the following: 1. Click the Resource Group tab. The Resource Groups summary page appears. 2. Click Static in the Type column. The Static Resource Groups page appears. 3. Click New. The Create Static Resource Group page appears. 4. Enter the details for the resource group: Name: Give the resource group a name. Resource groups are referred to by name when specified in policy intervals. All resource group names must be unique, even across different types of groups. Description: Optionally, enter a description for the resource group. Default Manager: Choose the default DataSynapse resource manager for this group. When the resources in the group are not involved in a policy interval, they will be returned to this resource manager. Default Initial Configuration: You can optionally specify the name of the configuration to use when the Engine Daemons first start up. Use this field, for example, if you want them to synchronize with a particular Broker but then connect to their real Broker (as defined by the default configuration) afterwards. This is in effect when the group is not part of a policy interval; when in a policy interval, the policy interval s settings have precedence. Default Configuration: Specify the name of the configuration to use when the Engine Daemons are running. This is in effect when the group is not part of a policy interval; when in a policy interval, the policy interval s settings have precedence. Default Busy Action: Specify the action that should be taken when Federator wants to migrate resources in this group but they are busy. Choosing Force causes the resources to be migrated regardless of their busy status. Choosing Abandon causes Federator to give up on migrating resources that are still busy (taking them out of draining mode as well). This is in effect when the group is not part of a policy interval; when in a policy interval, the policy interval s settings have precedence. Default Warning Period: Specify the warning period for resources in this group (in minutes). This is the amount of time before the resources are to be migrated that they will be put into draining mode (see Resource Draining on page 48). This is in effect when the group is not part of a policy interval; when in a policy interval, the policy interval s settings have precedence. 32 Chapter 5 Working with Resource Managers

36 Default Success Threshold: Optionally, specify a percentage of the resources in the group (an integer between 0 and 100) that must be successfully migrated; if this threshold is not reached, Federator will generate an alert. Leaving this blank means Federator will never generate alerts when resources fail to migrate. This is in effect when the group is not part of a policy interval; when in a policy interval, the policy interval s settings have precedence. 5. Click Create. The new resource group is created and appears in the list of static resource groups. Viewing or Editing a Static Resource Group To view or edit an existing resource group, do the following: 1. Click the Resource Groups tab. The Resource Groups summary page appears. 2. Click Static in the Type column to show the list of static DataSynapse resource groups. 3. Click the name of the resource group you want to view or edit. It appears on the Show Static Resource Group page. 4. If you want to edit the values, click the Edit button to show the Edit Static Resource Group page. (As a shortcut, you can get to the Edit page by clicking the edit (pencil) icon for the group on the list page.) 5. Make any changes you want and click Update to save them. Deleting Static Resource Groups To delete a static resource group, click the delete (trash can) icon next to its name in the list. TIBCO DataSynapse Federator User Guide 33

37 Creating and Populating DataSynapse Resource Groups Assigning Resources to Static Resource Groups Newly created DataSynapse resource groups have no resources associated with them. To make them useful, you need to add resources to them from your grids. You can do this in two ways: using the resource-managerbased resources page, or using the rule-based resources page. For details on removing shared resources from resource groups, see Working with Static Resources on page 40. Finding Resources by Resource Manager To find resources based on the resource manager to which they are currently assigned: 1. Click the Resources tab. The list of all DataSynapse resources appears. 2. Choose which resource manager s resources you want to see. The Resource Manager pop-up shows your DataSynapse resource managers. Choose All to show resources assigned to all resource managers; choose a specific manager to show only resources assigned to that manager. 3. You can further filter the list by using the Match button and its related controls (such as Match default in configuration to match resources with configuration named default ). 4. Select the resources you want to add to the group by clicking their checkboxes. You can click the checkbox in the table header to select all of the resources on the page. 5. Select the resource group you would like to add the resources to from the Add Checked To pop-up list. 6. Click the Add Checked To button to add the selected resources to the that group. 7. Repeat these steps to add additional resources to static resource groups. You can add resources from multiple managers to the same group and you can add resources from any given manager to multiple groups; you just cannot add the same resource to multiple groups. NOTE: When you add resources to a static resource group, they will be immediately migrated to the current target (manager and configuration) of the group, if they are not already there. If the group is in use by an active policy interval, they will be migrated to that policy interval s target; if not, they will be migrated to the default manager for the group. Finding Resources Using Rules To find resources using resource rules: 1. Click the Resources tab. The list of all DataSynapse resources appears. 34 Chapter 5 Working with Resource Managers

38 2. Click on the Rule-Based Search link in the sub-navigation bar. You will see the Search Resources Using Rules page. 3. Specify the criteria for your search as follows: Target Resource Count: Specifies the maximum number of resources you want to find. If this many resources do not meet your criteria, only those that do will be shown; otherwise this many matches will be shown. Resource Managers: Specify which DataSynapse resource managers resources should be searched. To add a resource manager to the search, select it in the left list and click the right arrow button to move it to the right. To remove one, select it and click the left arrow button. To change the order of the resource managers on the right, use the up and down arrow buttons. You must specify at least one resource manager for the search. Search Resource Managers in Order: Check this box to make the order of the resource managers in the list above be significant; if it is checked, then all resources from the first manager in the list will be included in the search results before any resources from the second manager are chosen, and so on. If this is not checked, the resources from all selected resource managers will be searched in a random order to help distribute the results across all resource managers. Note that while this is designed to help distribute the burden over the list of resource managers, it does not necessarily guarantee an even distribution of that burden. Rules: Choose a type of rule from the Add a New Rule pop-up menu to add it to the criteria. To remove a rule, click its delete button. You can add only one instance of each rule type, except for custom rules (where you can add as many as you need). The specific rule types are described in detail in Rules for Finding Resources on page When you are satisfied with the criteria, click the Search button. Federator performs your search and takes you to the Rules Search Results page where you can see the list of resources that it found. TIBCO DataSynapse Federator User Guide 35

39 Creating and Populating DataSynapse Resource Groups 5. Select the resources you want to add to the group by clicking their checkboxes. You can click the checkbox in the table header to select all of the resources on the page. 6. Select the resource group you would like to add the resources to from the Add Checked To pop-up list. 7. Click the Add Checked To button to add the selected resources to the that group. 8. You can also click the Add All To button to add all of the search results to a group without having to page through the results. 9. If you want to do a new search, click the Search Again button to go back to the search page. 10.Repeat these steps to add additional resources to static resource groups. You can add resources from multiple managers to the same group and you can add resources from any given manager to multiple groups; you just cannot add the same resource to multiple groups. NOTE: When you add resources to a static resource group, they will be immediately migrated to the current target (manager and configuration) of the group, if they are not already there. If the group is in use by an active policy interval, they will be migrated to that policy interval s target; if not, they will be migrated to the default manager for the group. Creating Dynamic Resource Groups Unlike static resource groups, dynamic resource groups use rules to find available resources at the point when they are being activated. These resources remain part of the dynamic group for the duration of the policy interval. At the end of the policy interval, the resources are returned to their source resource managers. To create a dynamic resource group, do the following: 1. Click the Resource Group tab. The Resource Groups summary page appears. 2. Click Dynamic in the Type column. The Dynamic Resource Groups page appears. 3. Click New. The Create Dynamic Resource Group page appears. 4. Enter the details for the resource group: Name: Give the resource group a name. Resource groups are referred to by name when specified in policy intervals. All resource group names must be unique, even across different types of groups. Description: Optionally, enter a description for the resource group. Target Resource Count: Specifies the maximum number of resources you want the group to include. Minimum Resource Count: Specifies the minimum number of resources you want the group to include. If this number cannot be met, then the group will fail to activate. Resource Managers: Specify which DataSynapse resource managers resources should be searched. To add a resource manager to the search, select it in the left list and click the right arrow button to move it to the right. To remove one, select it and click the left arrow button. To change the order of the resource managers on the right, use the up and down arrow buttons. You must specify at least one resource manager for the group. Search Resource Managers in Order: Check this box to make the order of the resource managers in the list above be significant; if it is checked, then all resources from the first manager in the list will be included in the search results before any resources from the second manager are chosen, and so on. If this is not checked, the resources from all selected resource managers will be searched in a random 36 Chapter 5 Working with Resource Managers

40 order to help distribute the results across all resource managers. Note that while this is designed to help distribute the burden over the list of resource managers, it does not necessarily guarantee an even distribution of that burden. Rules: Choose a type of rule from the Add a New Rule pop-up menu to add it to the criteria. To remove a rule, click its delete button. You can add one instance of each rule type, except for custom rules (where you can add as many as you need). The specific rule types are described in detail in Rules for Finding Resources on page 39. Default Busy Action: Specify the action that should be taken when Federator wants to migrate resources in this group but they are busy. Choosing Force causes the resources to be migrated regardless of their busy status. Choosing Abandon causes Federator to give up on migrating resources that are still busy (taking them out of draining mode as well). This has effect when a policy interval using this group ends and resources are being migrated back to their original managers; when in a policy interval, the policy interval s settings have precedence. Default Warning Period: Specify the warning period for resources in this group (in minutes). This is the amount of time before the resources are to be migrated that they will be put into draining mode (see Resource Draining on page 48). This has effect when a policy interval using this group ends and resources are being migrated back to their original managers; when in a policy interval, the policy interval s settings have precedence. TIBCO DataSynapse Federator User Guide 37

41 Creating and Populating DataSynapse Resource Groups Default Success Threshold: Optionally, specify a percentage of the resources in the group (an integer between 0 and 100) that must be successfully migrated if this threshold is not reached, Federator will generate an alert. Leaving this blank means Federator will never generate alerts when resources fail to migrate. This has effect when the group is not part of a policy interval; when in a policy interval, the policy interval s settings have precedence. 5. Click Create. The new resource group is created and appears in the list of dynamic resource groups. Deleting Dynamic Resource Groups To delete a dynamic resource group, click the delete (trash can) icon next to its name in the list. 38 Chapter 5 Working with Resource Managers

42 Rules for Finding Resources The Search Resources Using Rules and the Create Dynamic Resource Group pages use lists of rules for defining the search criteria that select resources. To add a rule to the list, choose a type of rule from the Add a New Rule pop-up. To remove one, click the delete icon for that rule. (Note that except for custom rules, you can only add one of each type.) Type various types of rules are described in the following table: Rule Type Operators Description IP Address Matches Does not match Operating System Is one of Is not one of Total Memory CPU Count Configuration Is exactly equal to Is not equal to Is less than or equal to Is less than Is greater than or equal to Is greater than Is between (inclusive) Is not between (exclusive) Is exactly equal to Is not equal to Is less than or equal to Is less than Is greater than or equal to Is greater than Is between (inclusive) Is not between (exclusive) Matches Does not match Searches using the IP addresses of the resources. You can choose whether the resource s address must match or not match the value you specify. The value is a commaseparated list of one or more IP addresses or IP address ranges. IP addresses can be specified using the wildcard character (*), which matches any sequence of characters. IP address ranges can be specified using CIDR notation. (CIDR, or Classless Inter-Domain Routing, notation, specifies a range of IP addresses using a base address and a subnet mask. The base address is specified in standard dot notation followed by a forward slash and then by an integer specifying the number of bits in the subnet mask. For example, /22 would specify the range of IPv4 addresses from to ) Searches using the resources operating system. Select one or more operating systems to match (or exclude) from the list. Compares the value you supply against the actual value of total memory on the resource s machine. Values specified should be in megabytes. If you choose either of the between operators, you must supply two values, for the upper and lower limits. Compares the value you supply against the actual number of CPUs on the resource s machine. If you choose either of the between operators, you must supply two values, for the upper and lower limits. Compares the resources configuration names against the value or values specified. You specify one or more values in a comma-separated list. Each value may include the wildcard character (*), which matches any sequence of characters. TIBCO DataSynapse Federator User Guide 39

43 Using EC2 Resource Groups Rule Type Operators Description Busy State Other Property Is busy Is not busy Matches Does not match Is exactly equal to Is not equal to Is less than or equal to Is less than Is greater than or equal to Is greater than Is between (inclusive) Is not between (exclusive) Is present Is not present Compares the resources busy state. (Note that if any of the Engines on the resource is busy, then the entire resource is deemed busy for the purposes of this rule; therefore resources with several Engine instances will seldom appear to Federator as not busy.) Compares the Engine Daemon property whose name you specify against the value or values you provide. The standard properties available from GridServer and FabricServer Engines can be specified, as well as any custom properties that have been defined on your grids. If you choose either of the matches operators, the value you supply should be a comma-separated list of one or more possible values. Each value may include the wildcard character (*), which matches any sequence of characters. If you choose the numeric operators, the value should be an appropriate number (integer or floating point) and the property s value must also be numeric. If you choose either of the present operators, there is no value to specify the rule will match any resource whose list of properties includes the one you name, regardless of its value. Working with Static Resources Once resources have been shared and made part of a resource group, you can view and manipulate them using the Static Resources page in the user interface. To see the shared resources in your system: 1. Click the Resources tab. The DataSynapse Resources page appears. 2. Click the Static Resources link in the sub-navigation bar. The Static Resources page appears. You can page to see the static resources in your Federator system. If you would like to remove resources from a group, effectively un-sharing them, select them in the list and click the Ungroup Checked button. If resources have been abandoned during a migration, you can see this in the Status column. To reclaim them, select them and click the Reclaim Abandoned button. For more about abandoned resources, see Reclaiming Abandoned Resources Manually on page 48. Using EC2 Resource Groups Like DataSynapse resource groups, EC2 resource groups provide resources that Federator can assign to the grids it manages. Unlike DataSynapse resource groups, the resources don t actually exist, except when Federator requests them. 40 Chapter 5 Working with Resource Managers

44 Creating EC2 Resource Groups To create an EC2 resource group, do the following: 1. Click the Resource Group tab. The Resource Groups summary page appears. 2. Click Amazon EC2 in the Type column. The Amazon EC2 Resource Groups page appears. 3. Click New. The Create Amazon EC2 Resource Group page appears. 4. Enter the details for the resource group: Name: Give the resource group a name. Resource groups are referred to by name when specified in policy intervals. Description: Optionally, enter a description for the resource group. Default Warning Period: Specify the warning period for resources in this group (in minutes). This is the amount of time before the resources are to be migrated that they will be put into draining mode (see Resource Draining on page 48). This can be overridden when you create policy intervals. Amazon EC2 Manager: Specify the EC2 resource manager that will be used to create resource instances for this group. (Federator uses the credentials AWS access key, secret access key, region of this manager to communicate with the EC2 server when dealing with this resource group.) Resource Count: Specify the number of resources (Amazon EC2 instances running Engine Daemons) that the group contains. When this group is activated in a policy interval, this many instances will be started. AWS Image: Choose the Amazon Machine Image (AMI) to use for the Engine Daemons launched as part of this group. Instance Type: Choose the instance type to use when running the proxy server. The instance type determines how much processing power the instance will have. Standard instances may be small, large, or extra large. High-CPU instances may be medium or extra large. (For specific details on the instance types and their pricing, see the EC2 website.) Note that the values in this list change to reflect the types appropriate for the image you have chosen. Security Groups: You can choose one or more of the EC2 security groups defined in your account for the instances to run in. See Creating Security Groups on page 75 for more. Key Pair Name: Choose one of the key pairs associated with your account. Instances started as part of this resource group will use this key pair to secure themselves. Availability Zone: Choose the availability zone for the proxy server. Choose Automatic to let Amazon choose for you at start-up time. Note that you choosing to run the Engine instances in the same availability zone as the EC2 resource manager s proxy server can avoid inter-zone networking fees. See Amazon s fee schedule for details. User Data: You should only enter user data here if you are using a custom AMI for the engines and it requires this field. Kernel ID: You should only enter a kernel ID here if you are using a custom AMI for the engines and it requires this field. Ram Disk ID: You should only enter a kernel ID here if you are using a custom AMI for the engines and it requires this field. TIBCO DataSynapse Federator User Guide 41

45 Using EC2 Resource Groups Block Device Mappings: This field maps block devices from Amazon Elastic Block Store (EBS) to devices visible to the instance. The format is the same as for the run-instances command in the command-line interface see Amazon s documentation for details. 5. Click Create. The new resource group is created and appears in the list of EC2 resource groups. Viewing or Editing an EC2 Resource Group To view or edit an existing resource group, do the following: 1. Click the Resource Groups tab. The Resource Groups summary page appears. 2. Click Amazon EC2 in the Type column to show the list of EC2 resource groups. 3. Click the name of the resource group you want to view or edit. It appears on the Show Amazon EC2 Resource Group page. 4. If you want to edit the values, click the Edit button to show the Edit Amazon EC2 Resource Group page. (As a shortcut, you can get to the Edit page by clicking the edit (pencil) icon for the group on the list page.) 5. Make any changes you want and click Update to save them. 42 Chapter 5 Working with Resource Managers

46 Deleting EC2 Resource Groups To delete an EC2 resource group, click the delete (trash can) icon next to its name in the list. Scheduling Resource Migration The main purpose of Federator, of course is to let you control the resources (Engine Daemons) associated with your grids. You can move resources from one grid to another (including between GridServer and FabricServer and between different versions of each product) and you can add virtual resources into the pool available to your grids. This movement is generally done using a daily schedule, although ad hoc movement is also possible. Federator s schedule consists of a collection of named policy intervals. Placement policy intervals consist of a time range, the resource group to migrate during that time, and the target resource manager to migrate to. Based on a policy interval, Federator will make the resources in the resource group available to the target manager, moving them to that manager from another if necessary or creating them in the case of virtual resources. At any given time, there can be a policy interval in effect for each of Federator s resource groups (whether DataSynapse and virtual), but policy intervals involving the same resource group cannot overlap in time. Demand based policy intervals consist of a time range, a priority, a set of rules, and the target resource manager to migrate to. Demand policies do not use resource groups, but instead choose resources for the target manager based upon the Service with the most pending tasks. When a condition is satisfied and an action is required in the policy rule, resources are chosen to migrate that satisfy the discriminators from the Service with the most pending tasks. These resources are not chosen from static resource groups or currently assigned dynamic resources. Demand policies will only pick unassigned resources or resources from a lower priority demand policy interval. When the DataSynapse resource group is not referenced by an active policy interval, Federator attaches the group to its default manager. When an EC2 resource group is not referenced by an active policy interval, Federator releases the groups resources, shutting down the instances they are running on. NOTE: If a second policy interval using the same resource group starts at the end of the first policy interval, the second policy interval s settings take precedence over the resource group's defaults; the resources are migrated as the second policy interval dictates and don t return to the group s default resource manager. Creating Placement Policy Intervals To create a policy interval, do the following: 1. Click the Policy Intervals tab. The Policy Intervals page appears. 2. Click New. The Create Policy Interval page appears. 3. Enter values for the policy interval: Name: Give the policy interval a name. Description: Optionally, give the policy interval a description. Type: Choose the type Placement. Resource Group: The group whose resources are affected by this policy interval. Each policy interval affects exactly one group s resources. This may be either a DataSynapse resource group (static or dynamic) or a virtual one. TIBCO DataSynapse Federator User Guide 43

47 Scheduling Resource Migration Target Manager: Choose the DataSynapse resource manager that should own the resources for this policy interval. Start: The Start group contains several fields that affect the way the policy interval behaves when coming into effect: Time: This is the time of day the policy interval takes effect. It can be set in increments of five minutes. Warning Period: Specify the start warning period for this policy interval (in minutes). When resources are migrated for the policy interval, they are put into draining mode, preventing them from accepting new jobs from their current target resource manager for this period of time (see Resource Draining on page 48 for details). If, after this time, they are still busy, then they are dealt with according to the if still busy action (see below). If Still Busy: Specify the action that should be taken when Federator wants to migrate resources targeted by this policy interval but they are busy processing tasks for their current resource manager. Choosing Force causes the resources to be migrated regardless of their busy status. Choosing Abandon causes Federator to give up on migrating resources that are still busy (taking them out of draining mode as well). Note that this action only occurs if the resources are still busy after the start warning period has expired. Initial Configuration: You can optionally specify the name of the configuration to use when the Engine Daemons first start up. Use this field, for example, if you want them to synchronize with a particular Broker but then connect to their real Broker (as defined by the target configuration) afterwards. Target Configuration: Specify the name of the configuration to use when the Engine Daemons are running. Success Threshold: Optionally, specify a percentage of the resources in the group (an integer between 0 and 100) that must be successfully migrated if this threshold is not reached, Federator will generate an alert. Leaving this blank means Federator will never generate alerts when resources fail to migrate. End: The End group contains fields that affect the way the policy interval behaves when ending: Time: This is the time of day the policy interval ends. It can be set in increments of five minutes. Warning Period: Specify the end warning period for this policy interval (in minutes). Resources will be put into draining mode, preventing them from accepting new jobs from their current target resource manager, this many minutes before the policy interval ends (see Resource Draining on page 48 for details). If they are still busy after this time and if the resource group is not in a new policy interval, they are either returned to their default manager (if the default busy action for the group is set to Force ) or taken out of draining mode and left connected to the current resource manager (if the default busy action for the group is Abandon ). 44 Chapter 5 Working with Resource Managers

48 4. Click Create to create the policy interval. Creating Demand Based Policy Intervals To create a policy interval, do the following: 1. Click the Policy Intervals tab. The Policy Intervals page appears. 2. Click New. The Create Policy Interval page appears. 3. Enter values for the policy interval: Name: Give the policy interval a name. Description: Optionally, give the policy interval a description. Type: Choose the type Demand-Based. Target Manager: Choose the DataSynapse resource manager that should own the resources for this policy interval. Start: The Start group contains several fields that affect the way the policy interval behaves when coming into effect: Time: This is the time of day the policy interval takes effect. It can be set in increments of five minutes. Warning Period: Specify the start warning period for this policy interval (in minutes). When resources are migrated for the policy interval, they are put into draining mode, preventing them from accepting new jobs from their current target resource manager for this period of time (see Resource Draining on page 48 for details). If, after this time, they are still busy, then they are dealt with according to the if still busy action (see below). If Still Busy: Specify the action that should be taken when Federator wants to migrate resources targeted by this policy interval but they are busy processing tasks for their current resource manager. Choosing Force causes the resources to be migrated regardless of their busy status. Choosing Abandon causes Federator to give up on migrating resources that are still busy (taking them out of draining mode as well). Note that this action only occurs if the resources are still busy after the start warning period has expired. TIBCO DataSynapse Federator User Guide 45

49 Scheduling Resource Migration Initial Configuration: You can optionally specify the name of the configuration to use when the Engine Daemons first start up. Use this field, for example, if you want them to synchronize with a particular Broker but then connect to their real Broker (as defined by the target configuration) afterwards. Target Configuration: Specify the name of the configuration to use when the Engine Daemons are running. Success Threshold: Optionally, specify a percentage of the resources in the group (an integer between 0 and 100) that must be successfully migrated if this threshold is not reached, Federator will generate an alert. Leaving this blank means Federator will never generate alerts when resources fail to migrate. End: The End group contains fields that affect the way the policy interval behaves when ending: Time: This is the time of day the policy interval ends. It can be set in increments of five minutes. Warning Period: Specify the end warning period for this policy interval (in minutes). Resources will be put into draining mode, preventing them from accepting new jobs from their current target resource manager, this many minutes before the policy interval ends (see Resource Draining on page 48 for details). If they are still busy after this time and if the resource group is not in a new policy interval, they are either returned to their default manager (if the default busy action for the group is set to Force ) or taken out of draining mode and left connected to the current resource manager (if the default busy action for the group is Abandon ). Allocation Priority: Choose the priority of this policy interval over other policy intervals: Critical, High, Medium or Low. Higher priority intervals will be evaluated before lower priority intervals. Allocation Rules: Add, remove or reorder the list of demand based rules. Rules are evaluated top down until the first condition is satisfied and the corresponding action is taken. The following fields need to be specified: Statistic: Defines which value reported by the resource manager that should be examined by this rule. The following statistics are available: Pending Invocation Count: The number of pending service invocations on the target resource manager. Average Invocation Duration: The average time it takes to complete an invocation on the target resource manager. Predicted Time to Complete: The estimated time to complete all the pending invocations on the target resource manager. The value is (Average Invocation Duration * Pending Task Count) / Engine Count. Operator: Defines the relationship between the Statistic field and that of the Value field. The following operators are available: <, <=, =, >=, >. Value: The value against which the statistic will be compared. It must be an integer greater than or equal to zero. Action: The action to take on the provided number of resources. The following actions are available: Return: causes the number of resources specified by the Resource Count field to be migrated back to their original resource managers immediately. Release: causes the number of resources specified by the Resource Count field to be released from the current resource manager's hold, making them eligible for other resource managers to take (though the will remain on their current manager until another manager needs them). Do nothing: causes no resource migration for the current cycle. 46 Chapter 5 Working with Resource Managers

50 Migrate (abandon if busy): migrates the number of resources specified by the Resource Count field to the policy's resource manager using the Abandon heuristic. Migrate (forcing if busy): migrates he number of resources specified by the Resource Count field to the policy's resource manager using the Force heuristic. Resource Count: the number of resources that should be affected by the action. It must be a positive integer. If the action is "do nothing," then the Resource Count field is not shown. 4. Click Create to create the policy interval. Viewing or Editing a Policy Interval To view or edit an existing policy interval, do the following: 1. Click the Policy Intervals tab. The Policy Intervals page appears. 2. Click the name of the policy interval you want to view or edit. It appears on the Show Policy Interval page. 3. If you want to edit the values, click the Edit button to show the Edit Policy Interval page. (As a shortcut, you can get to the Edit page by clicking the edit (pencil) icon for the policy interval on the list page.) 4. Make any changes you want and click Update to save them. The fields are the same as when creating a new policy interval. Deleting Policy Intervals To delete a policy interval, click the delete (trash can) icon next to its name in the list. TIBCO DataSynapse Federator User Guide 47

51 Scheduling Resource Migration Enabling or Disabling a Policy Interval Federator lets you enable and disable policy intervals. Federator only schedules enabled policy intervals. If a currently active policy interval is disabled, it behaves the same way as if it had reached its end time. To enable or disable a policy interval, do the following: 1. Click the Policy Intervals tab. The Policy Intervals page appears. 2. Click the name of the policy interval you want to modify. It appears on the Show Policy Interval page. 3. Click Enable or Disable to modify the policy interval (if the policy interval is currently enabled, the button says Disable and vice-versa). As mentioned above, disabling a policy interval that is currently in effect will stop it. (As a shortcut, you can click the enable or disable icon for the policy interval on the list page.) Resource Draining Because Engines can be busy with important work when a move is scheduled or otherwise indicated, it is not always desirable to move those Engines immediately when a policy interval begins. Federator cooperates with your grids to let Engines complete their current tasks before assigning them further work. This process is called draining. Draining occurs during a warning period that begins at the time of any resource group-related move. Idle resources, and those that become idle during the warning period, always move. The if still busy property of policy intervals and resource groups lets you determine what happens to resources that are not idle by the end of a warning period. There are two choices: Force directs Federator to move the resource even though it s still busy; any tasks it may have been working on are discarded (the Broker that assigned them will reassign them to another Engine automatically, though they may take longer to complete). Abandon directs Federator to leave the busy resource in place and tells its current resource manager that it no longer needs to drain, and can once again accept new tasks. Note that abandonment is not permanent. It lasts only until the next policy transition or other Federator-directed move. NOTE: FabricServer 2.6 does not implement resource draining. This makes the Busy Action especially important when moving resources away from FabricServer 2.6 grids. In such moves, Federator monitors the resources scheduled for movement during the warning period to see if any of them go idle, but in most cases moving those resources away from that FabricServer requires the Force busy action. (FabricServer 3.0 includes this feature and resource draining there works as described above.) Reclaiming Abandoned Resources Manually There may be occasions where Federator abandons a resource that stays busy through a warning period, but business necessity requires that you override the general abandon setting. You can try again to move abandoned resources manually as follows: 1. Click the Static Resources tab. The Static Resources page appears. 2. Locate the Static Resources with status of Abandoned. (You can filter the list, matching the value Abandoned for the Status field.) 3. Select the check boxes that correspond to the abandoned resources you would like to retry. 48 Chapter 5 Working with Resource Managers

52 4. Click Reclaim Abandoned. The resources begin draining again and, when they become idle, Federator moves them according to the policy interval or resource group settings currently in effect. Moving Resources Manually There may be cases where you want to move selected resources on a one-time basis from one grid to another. Manually moving lets you migrate resources from one resource manager to another without making those resources part of a shared resource group and without scheduling them to move on a regular basis. NOTE: When you designate a resource for a manual move, Federator removes it from the resource group it belongs to, if any. It remains ungrouped after the move until you add it back into a resource group. To manually move resources between DataSynapse resource mangers, do the following: 1. Click the Resource Manager tab. The Resource Managers summary page appears. 2. Click DataSynapse in the Type column. The DataSynapse Resource Managers page appears. 3. Find the DataSynapse resource manager that owns the resources you d like to share. Click the number in the Resources column for that row. The Resources page appears. (You can also navigate to the All Resources or Static Resources page on the Resources tab.) 4. Select the checkboxes corresponding to the resources you want to move. You can click the checkbox in the table header to select all of the resources on the page. 5. Click Move Checked. 6. On the Resources to Move page, specify the following parameters about the destination: Target Manager: Choose the DataSynapse resource manager to which you want to move the resources. Initial Configuration: You can optionally specify the name of the configuration to use when the Engine Daemons first start up. Use this field, for example, if you want them to synchronize with a particular Broker but then connect to their real Broker (as defined by the target configuration) afterwards. Target Configuration: Specify the name of the configuration to use when the Engine Daemons are running. Warning Period: Specify the warning period for the move, in minutes. Resources will be put into draining mode, preventing them from accepting new jobs from their current resource manager for this period of time (see Resource Draining on page 48 for details). If, after this time, they are still busy, then they are dealt with according to the if still busy action (see below). If Still Busy: Specify the action that should be taken resources are still busy processing tasks for their previous resource manager after the warning period is over. Choosing Force causes the resources to be migrated regardless of their busy status. Choosing Abandon causes Federator to give up on migrating resources that are still busy (taking them out of draining mode as well). 7. Click Move. Federator begins migrating the selected resources. TIBCO DataSynapse Federator User Guide 49

53 Resource Migration Details Resource Migration Details Depending on what is changing for the resource as it is migrated, the specifics of what Federator does can vary. The parameters that affect what happens during migration are the target resource manager, the target configuration, and the initial configuration, if any. Different scenarios are discussed below, based on which of these parameters are changing. Target Configuration Changes, Target Manager Doesn t Federator: 1. Puts the resource into draining mode and waits until the resource is idle or the warning period has expired 2. Sets the new target configuration for the resource, causing it to restart (if the resource is idle or the busy action is Force ) 3. Takes the resource out of draining mode (if the resource has been abandoned) Note that the initial configuration is ignored here, since the resource will have already synchronized with this resource manager. Target Manager Changes, Configuration Doesn t, No Initial Configuration Federator: 1. Puts the resource into draining mode and waits until the resource is idle or the warning period has expired 2. Sets the new target resource manager for the resource, causing it to restart (if the resource is idle or the busy action is Force ) 3. Takes the resource out of draining mode (if the resource has been abandoned) Target Manager Changes, Configuration Changes, No Initial Configuration Federator: 1. Puts the resource into draining mode and waits until the resource is idle or the warning period has expired 2. Disables the resource (if the resource is still busy and the busy action is Abandon, the resource is abandoned skip to Step 6) 3. Sets the new target resource manager for the resource, causing the Daemon to restart 4. Sets the new configuration for the resource, causing the Daemon to restart 5. Enables the resource 6. Takes the resource out of draining mode (if the resource has been abandoned) Note that the Engine Daemon needs to restart multiple times for this type of migration. 50 Chapter 5 Working with Resource Managers

54 Target Manager Changes, Configuration Changes, Initial Configuration Set Federator: 1. Puts the resource into draining mode and waits until the resource is idle or the warning period has expired 2. Disables the resource (if the resource is still busy and the busy action is Abandon, the resource is abandoned skip to Step 7) 3. Sets the new target resource manager for the resource, causing the Daemon to restart 4. Sets the configuration for the resource to the initial configuration, causing the Daemon to restart 5. Enables the resource for synchronization 6. After synchronization, sets the configuration for the resource to the target configuration, causing the Daemon to restart 7. Takes the resource out of draining mode (if the resource has been abandoned) Note that the Engine Daemon needs to restart multiple times for this type of migration. TIBCO DataSynapse Federator User Guide 51

55 Resource Migration Details 52 Chapter 5 Working with Resource Managers

56 Chapter 6 Platform as a Service This chapter describes the Platform as a Service (PaaS) functionality within Federator. PaaS allows you to easily control deployment of applications to your FabricServer 3.0 brokers (note that PaaS does not work with older versions of FabricServer). Brokers can be tagged with a particular stage of development, allowing you to deploy the same application to development, testing, and production servers (the number and name of the tags is up to your organization). PaaS administrators can pull applications from a running FabricServer to create templates that other users can use to develop and deploy new applications. Using Platform as a Service This section describes how to use the PaaS functionality within Federator. Definitions Application Within the context of PaaS, the term application refers to applications as deployed in FabricServer 3.0. An application may consist of multiple components, containers, and distributions. Within Federator, applications are either templates or images, depending on their purpose (see below). Template Templates are FabricServer applications which have been pulled into Federator where they are usable by developers who want to build applications on top of them. Templates are not designed to be deployed as full-fledged applications themselves, but generally need to be populated with the actual application's components, such as EAR files. Image Images are instantiated templates and represent a copy within Federator of a deployed (or deployable) application. Multiple images can be created from any given template. Environment Within the PaaS subsystem, FabricServer 3.0 Resource Managers which have been configured to have a PaaS tag are known as environments, as they host your applications. Environment Tag Environments are tagged to specify which stage of the development cycle they are used for. For example, your organization may want to designate environments as Development, Testing, and Production. You may want more or fewer stages, depending on your desired workflow. Environments are assigned tags by the Federator Administrator on the Resource Manager pages. Ticket Tickets represent PaaS actions taken in Federator and include all of the necessary details to execute the request. When a user requests an action, whether or not she has permission to perform the action herself, a ticket is created containing all of the request's details. If the user does not have permissions, then the ticket sits in a queue until a user with PaaS administrator privileges either approves it (at which point the action takes place) or denies it. TIBCO DataSynapse Federator User Guide 53

57 Using Platform as a Service Typical Usage The basic steps involved in using Federator s Platform as a Service functionality are: 1. Create FabricServer applications to use as templates. This would generally be done by someone familiar with the way applications work on FabricServer as it involves some basic configuration (such as setting up the interactions between an application s components or configuring the initial rules governing instantiation of these components). 2. Create templates in Federator. The applications created in the previous step are imported into Federator and made available for all PaaS users as the basis for deploying new applications. See Creating a Template on page 58 for details on how to import templates. 3. Instantiate a template as an image and deploy it to a development FabricServer. Generally, the person developing the application (or deploying a finished application) performs this step. This creates a copy of the template s contents within Federator in a way that can be modified as necessary to make it into a useful application. See Instantiating a Template on page 60 for instructions. 4. Make changes to the running instance of the image s application (and application components), generally using the tools for the components containers. For example, if your application includes a component that uses the IBM WebSphere container, you could use WebSphere s Administrative Console to modify it. At this time, you would deploy any EAR or WAR files needed, configure startup scripts, and so on. 5. Capture the changes to the running application and save the captured version to Federator. When an application is captured, FabricServer pulls any changes made on the engines where the application s components were running back to the broker to become the canonical version of the application on that broker from that point forward. In order for the changes to be brought into Federator, however, you must also save the image, which updates Federator s copy with the one on FabricServer. See Capturing an Image on page 63 and Saving an Image on page 64 for more on capturing and saving images. 6. Repeat steps 4 and 5 until the application is working properly. 7. When the application seems to be working, it would generally be promoted to a separate FabricServer environment for testing purposes. Within Federator you use the Promote command to do this. When the image is promoted, you have the chance to modify the runtime variables FabricServer uses when launching the application, so you can provide values relevant to the test environment instead of the development environment. See Promoting an Image on page 62 for the specifics of image promotion. 8. If an application passes testing it would be promoted once again, to a production FabricServer, again modifying any variables if necessary, to accommodate the new environment. If the application fails testing, it can be undeployed ( Undeploying an Image on page 65) from the test environment and bugs can be worked out in the development environment where it started; in other words, returning to step 4, above. Federator remembers the variables distinctly for each type of environment you deploy to, so redeploying a previously deployed application doesn t necessarily require respecifying their values. Your organization s workflow may vary from this, of course. For instance you may have more or fewer stages than those described here. Federator allows you the flexibility to define your own deployment stages, and doesn t impose a restrictive workflow. 54 Chapter 6 Platform as a Service

58 While not the primary use case, PaaS can also be used as a way to migrating working applications between FabricServer instances, while at the same time maintaining an archive in Federator of the applications contents. This can be accomplished using the image import and deployment functionality (see Importing an Image on page 59 and Deploying an Image on page 63), bypassing the template and developmental iteration steps. Configuring PaaS PaaS administrator users will need to configure Federator to provide PaaS functionality. All PaaS-related settings are configured on the PaaS page of the Admin tab. They are: Parameter Description Default Value Environment Tags Repository Location Repository Monitoring Interval A comma-separated list of the tag names you want to use in Federator, for example, setting it to Dev, QA, Prod would produce three tags, Dev, QA, and Prod. These are the tags seen on the Resource Manger pages and by which environment are grouped within the PaaS pages. The order of the tags is important images can be promoted forward through the series (from Dev to QA to Prod, in the example case), but not backwards. The directory where Federator should maintain the files describing the images and templates it organizes. It must be a directory available to the Federator machine using a standard file-system path specifier. If the repository will be on a shared file server, make sure that the path is valid for any engine that may be running Federator. Note: if you change the location of the repository once Federator is using it, you will need to stop Federator and move the contents of the old repository to the new location (or delete all Images and Templates already in Federator before changing the location). The frequency, in minutes, with which Federator will check the repository for consistency against the database. blank. (Federator s working directory) 60 minutes TIBCO DataSynapse Federator User Guide 55

59 Using Platform as a Service Parameter Description Default Value Application Locking Timeout SMTP Server SMTP Username SMTP Password Maintenance Mode The duration, in minutes, for which PaaS artifacts (images and templates) are locked when being modified. Federator locks images and templates when they're being accessed by a user action, such as editing a template or deploying an image. After this interval, items which have been locked by one user will once again be accessible to other users. The Simple Mail Transfer Protocol server (by DNS name or IP address) that Federator will use to send notifications to users regarding ticket approval and denial. If it is not set, no notifications will be sent. If the SMTP server requires a username to log in as when sending mail, set it here. If the SMTP server requires a password when sending mail, set it here. When checked, the PaaS subsystem is in maintenance mode, preventing modification of any images or templates. Unchecking this checkbox takes the server out of maintenance mode, allowing normal functioning. See Artifact Locking and Maintenance Mode on page 66 for more details. 5 minutes blank blank blank Unchecked Working with Tickets Federator uses tickets to track PaaS requests. Whenever a user requests a PaaS action, a ticket is created describing the request. If the user has permission to perform the action himself, the action is performed immediately. If the user does not have permission to perform the action, the ticket will be placed into a queue until an administrator either approves or denies the request. If the request is approved, the request is processed. Either way, a notification is sent to the user who submitted the ticket indicating the new status of the request. Tickets are listed on the Tickets page of the PaaS tab of the user interface. Administrator users can see all tickets while non-administrator users can only see tickets that they have submitted. To include in the list tickets which have already been completed, check the Show completed tickets checkbox. To permanently remove all currently completed tickets from the list, click the Remove Completed Tickets button. You can also remove an individual ticket by clicking the Delete (trash can) button next to it in the list. 56 Chapter 6 Platform as a Service

60 When an administrator approves or denies a ticket, Federator will attempt to send a notification to the user who submitted the request. This requires that the SMTP-related configuration parameters be set correctly and that the user have an address specified (either from the LDAP server or on the user configuration page). Viewing a Ticket To view details about a ticket, click the Show (magnifying glass) button in the table next to the ticket. A page appears describing the ticket in detail. Click Edit to edit the ticket, Delete to delete it, or Return to List to go back to the Tickets page. Editing a Ticket You can edit tickets for requests which haven t yet been completed. You must either be the ticket submitter or have PaaS Administrator permissions to edit a ticket. To do so: 1. Click the Edit (pencil) button in the table next to the ticket. The Edit Ticket page appears. 2. Depending on the type of request, different properties of the ticket may be edited. 3. Click the Update button to save your changes or Cancel to abandon them. Approving or Denying a Ticket Administrators will see an Approve button in the list next to incomplete tickets. To approve or deny a ticket: 1. Click the Approve (check mark) button in the table next to the ticket. The Approve Ticket page appears. 2. You have a chance to modify the ticket, if desired, before approving it. This works the same way as editing a ticket. 3. You may optionally add a comment explaining why the ticket is being denied or why parameters may have been changed before approval. These comments will be included in the notification sent to the submitter 4. Click Approve Ticket to approve it. The requested action is performed immediately and an notification is sent to the submitter saying that the ticket has been approved. Or, TIBCO DataSynapse Federator User Guide 57

61 Using Platform as a Service 5. Click Deny Ticket to deny it. An notification is sent to the submitter saying that the ticket has been denied. Or, 6. Click Cancel to leave the ticket for later approval. Completing Approved Tickets Sometimes when an administrator approves a ticket, it will fail to complete due to a problem such as, for example, the target environment being offline. In this case, the ticket will be moved to the Approved rather than the Completed state. In this case, you can retry completing the ticket. 1. Click the Show (magnifying glass) button in the table next to the ticket. The Show Ticket page appears. 2. Click the Complete Ticket button. The Complete Ticket page appears. 3. Review the parameters of the ticket if desired and then click the Complete Ticket button. The ticket action is retried. If the situation that prevented it from completing in the first place has been rectified, then it completes normally. If an error occurs again, then the ticket remains in the Approved state. Removing Tickets from the List To remove a completed ticket from the list, click the delete (trash can) icon next to its name in the list. You can remove all completed tickets by clicking the Remove Completed Tickets link at the top of the page. NOTE: Tickets removed from the list still exist in Federator s database and can provide a history of changes to the PaaS components. Working with Applications The Applications page of the PaaS tab is available to users with PaaS Administrator privileges. It allows the importing of applications running on a FabricServer environment into Federator so that they may be deployed to create new applications or to migrate them to a new broker. Creating a Template To create a template from a running application, do the following: 1. Select the environment where the application is running from the Environment pop-up list. The Application pop-up list updates to show the applications running with the chosen environment. 58 Chapter 6 Platform as a Service

62 2. Select an application from the Application pop-up list. If there is already a corresponding image within Federator (either it has previously been imported from or was previously deployed to that FabricServer), then additional information about the status of the application is shown next to Application Details. 3. Click the Create Template button. The Create Template page appears. 4. Optionally, enter a name for the template. The name defaults to the name of the application but you can change it here. 5. Click the Create Template button. Federator retrieves the components of the application from the FabricServer broker and creates a new Template with the name you specified. A ticket (approved, since the user is an administrator) is also created for the operation. The new template shows up on the Templates page for all users to access. Importing an Image To import an image from a running application, do the following: 1. Select the environment where the application is running from the Environment pop-up list. The Application pop-up list updates to show the applications running with the 7chosen environment. 2. Select an application from the Application pop-up list. If there is already a corresponding image within Federator (either it has previously been imported from or was previously deployed to that FabricServer), then additional information about the status of the application is shown next to Application Details. 3. Click the Import button. The Import Image page appears. 4. Optionally, enter a name for the image. The name defaults to the name of the application but you can change it here. 5. Click the Import button. Federator retrieves the components of the application from the FabricServer broker and creates a new Image with the name you specified. A ticket (approved, since the user is an administrator) is also created for the operation. The new image shows up on the Images page for all users to access. Working with Templates The Templates page of the PaaS tab is available to users with PaaS User or PaaS Administrator privileges. It allows the instantiation of templates as images within Federator, the first step in creating a new FabricServer application using PaaS. Note that templates are created on the Applications page (see Creating a Template on page 58). TIBCO DataSynapse Federator User Guide 59

63 Using Platform as a Service Viewing a Template To view details about a template, click the Show (magnifying glass) button in the table next to the template. A page appears describing the template in detail. Click Edit to edit the template, Delete to delete it, or Return to List to go back to the Templates page. Editing a Template Administrators can edit existing templates. Any changes made to template will apply to instantiation of images after the template is edited, but do not impact images previously instantiated from that template. To edit a template: 1. Click the Edit (pencil) button in the table next to the template. The Edit Template page appears. 2. Edit the description and/or variables for the template (see Editing Runtime Variables below for details on runtime context variables and PaaS). 3. Click the Update button to save your changes or Cancel to abandon them. Deleting Templates To delete a template, click the delete (trash can) icon next to its name in the list. You must be a PaaS Administrator to delete templates. Instantiating a Template To instantiate a template: 1. Select the template in the list. It highlights to indicate it is selected. 2. Click the Instantiate Template button. The Create Request Ticket Instantiate Template page appears. 3. Specify the name of the image to create from the template. 4. Specify the environment on which to deploy the initial image. 5. Click the Edit Variables button to modify the runtime context variables used by is instance of the application (see Editing Runtime Variables below for details on runtime context variables and PaaS). 6. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 7. Click the Instantiate (administrators) or Submit Ticket (other users) button. The ticket is created and, for administrators, the template is instantiated. Non-administrator users will have created a ticket which will need to be approved by an administrator before the template will be instantiated. Working with Images The Images page of the PaaS tab is available to users with PaaS User or PaaS Administrator privileges. It allows the manipulation of images both within Federator and on the FabricServer grids where they are deployed. Unlike templates, images can have specific permissions configured per user for the various operations you can perform on them. See Editing an Image s Permissions below for more details. Note that the Images page lets users filter images by showing the environments they are deployed to to 60 Chapter 6 Platform as a Service

64 selectively show only a certain environment s images choose it from the Show only images deployed to environment pop-up list. Also, note that images for which a user has no view privileges will not appear on the Images page. Viewing an Image To view details about an image, click the Show (magnifying glass) button in the table next to the image. A page appears describing the image in detail. Click Edit to edit the image, Delete to delete it, or Return to List to go back to the Images page. Editing an Image Administrators and users with modify permission can edit an image s description. Note that editing permissions for the image is described under Editing an Image s Permissions below. To edit an image: 1. Click the Edit (pencil) button in the table next to the image. The Edit Image page appears. 2. Edit the description for the image. 3. Click the Update button to save your changes or Cancel to abandon them. Deleting Images To delete an image, click the delete (trash can) icon next to its name in the list. You must have modify permission for the image to delete it. Editing an Image s Permissions Images can have permissions set on a per-user basis for the following actions: view, modify, capture, deploy, undeploy, start, shutdown, save, and grant. To modify an image s permissions: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Edit Permissions button. The Create Request Ticket Edit Image Permissions page appears. 3. You can modify the image s owner. The owner of an image automatically has permission to do view, modify, or capture the image without needing to appear explicitly in the list of permissions. 4. Modify the permissions for an individual user by checking and un-checking the checkboxes in the table. 5. Add a new user to the table using the Add a New User link. You must enter the new user s username in the Name field. 6. Remove a user from the list by clicking the Delete (trash can) icon next to the user s name. 7. Optionally enter a comment; for example to explain the request to the administrator who will approve it. TIBCO DataSynapse Federator User Guide 61

65 Using Platform as a Service 8. Click the Edit Permissions (administrators and users with grant permission for the image) or Submit Ticket (other users) button. The ticket is created and, for users with permission, the image s permissions are updated. Users without grant permission will have created a ticket which will need to be approved by an administrator before the permissions will be updated. Duplicating an Image Duplicating an image copies it within Federator, creating a second image with a new name that is otherwise identical to the original. The new image won t be deployed to a FabricServer until you explicitly do so. To duplicate an image: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Duplicate button. The Create Request Ticket Duplicate Image page appears. 3. Specify the name for the duplicate image. 4. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 5. Click the Duplicate (administrators) or Submit Ticket (other users) button. The ticket is created and, for administrators, the image is duplicated using the new name. Non-administrator users will have created a ticket which will need to be approved by an administrator before the image will be duplicated. Promoting an Image Promotion of images means deployment onto an environment that is further along the workflow. For example, images that are deployed onto a Dev environment may be promoted to a Test environment. The workflow is defined by the environment tags your organization specified on the PaaS configuration page. Note that if the image has already been deployed to the last stage in the workflow, it can not be promoted any further. To promote an image: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Promote button. The Create Request Ticket Promote Image page appears. 3. Click the Edit Variables button to modify the runtime context variables used by is instance of the application (see Editing Runtime Variables below for details on runtime context variables and PaaS). 4. Choose the environment to promote to. The list shows only environments at stages the image hasn t yet been deployed to. 5. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 62 Chapter 6 Platform as a Service

66 6. Click the Promote (administrators and users with deploy permission for the image) or Submit Ticket (other users) button. The ticket is created and, for users with permission, the image is deployed to the new environment. Users without deploy permission will have created a ticket which will need to be approved by an administrator before the image will be deployed. Deploying an Image To deploy an image: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Deploy button. The Create Request Ticket Deploy Image page appears. 3. Click the Edit Variables button to modify the runtime context variables used by is instance of the application (see Editing Runtime Variables below for details on runtime context variables and PaaS). 4. Choose the environment to deploy to. 5. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 6. Click the Deploy (administrators and users with deploy permission for the image) or Submit Ticket (other users) button. The ticket is created and, for users with permission, the image is deployed to the new environment. Users without deploy permission will have created a ticket which will need to be approved by an administrator before the image will be deployed. Capturing an Image Capturing an image forces any changes made to engines running the application s components to be copied back to the environment s FabricServer broker (and redeployed, so that the changes will become canonical for that broker). Note that capturing an image doesn t update Federator with the changes you must save the image (see below) to update the version in Federator. Images can only be captured if they are currently deployed to an environment. NOTE: The application must have the capture functionality enabled (for details on capturing in FabricServer, see the FabricServer User Guide). To capture an image: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Capture button. The Create Request Ticket Capture Image page appears. 3. Choose the environment to capture on. Only environments where the image is currently deployed are available for capturing. 4. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 5. Click the Capture (administrators and users with capture permission for the image) or Submit Ticket (other users) button. The ticket is created and, for users with permission, the image is captured on the environment. Users without capture permission will have created a ticket which will need to be approved by an administrator before the image will be captured. TIBCO DataSynapse Federator User Guide 63

67 Using Platform as a Service Starting an Image Starting an image in Federator is equivalent to putting the corresponding application into manual mode within FabricServer. Note that the application may not run immediately if the FabricServer has no engines available to run it. Images can only be started if they are currently deployed to an environment. To start an image: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Start button. The Create Request Ticket Start Image page appears. 3. Choose the environment to start on. Only environments where the image is currently deployed are available for starting. 4. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 5. Click the Start (administrators and users with start permission for the image) or Submit Ticket (other users) button. The ticket is created and, for users with permission, the image is started on the environment. Users without start permission will have created a ticket which will need to be approved by an administrator before the image will be started. Shutting an Image Down Shutting an image down is equivalent to stopping the application on the FabricServer. Images can only be shut down if they are currently deployed to an environment. To shut an image down: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Shutdown button. The Create Request Ticket Shut Image Down page appears. 3. Choose the environment to shut the image down on. Only environments where the image is currently deployed are available for shutting down. 4. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 5. Click the Shutdown (administrators and users with shutdown permission for the image) or Submit Ticket (other users) button. The ticket is created and, for users with permission, the image is shut down on the environment. Users without shutdown permission will have created a ticket which will need to be approved by an administrator before the image will be shut down. Saving an Image Saving an image updates the copy in Federator with the version currently deployed to an environment. Note that any changes you have made to the application running on the FabricServer s engines will need to be captured before saving or they won t be brought back into Federator. Images can only be saved if they are currently deployed to an environment. To save an image: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Save button. The Create Request Ticket Save Image page appears. 3. Choose the environment to save the image from. Only environments where the image is currently deployed are available for saving. 4. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 64 Chapter 6 Platform as a Service

68 5. Click the Save (administrators and users with save permission for the image) or Submit Ticket (other users) button. The ticket is created and, for users with permission, the image is saved to Federator from the environment. Users without save permission will have created a ticket which will need to be approved by an administrator before the image will be saved. Undeploying an Image Undeploying an image removes it from an environment where it is currently deployed. Images can only be undeployed if they are currently deployed to an environment. To undeploy an image: 1. Select the image in the list. It highlights to indicate it is selected. 2. Click the Undeploy button. The Create Request Ticket Undeploy Image page appears. 3. Choose the environment to undeploy the image from. Only environments where the image is currently deployed are available for undeployment. 4. Optionally enter a comment; for example to explain the request to the administrator who will approve it. 5. Click the Undeploy (administrators and users with undeploy permission for the image) or Submit Ticket (other users) button. The ticket is created and, for users with permission, the image is undeployed from the environment. Users without undeploy permission will have created a ticket which will need to be approved by an administrator before the image will be undeployed. Editing Runtime Variables Runtime variables in Federator translate into runtime context variables on the FabricServer broker; they let you modify configuration on a per-environment basis when deploying from Federator. This allows you to, for example, use one value for a given parameter while in development and another when the application is promoted to a production FabricServer. For more about runtime context variables, see the FabricServer User Guide. When templates are created or when images are imported from FabricServer, the Federator object maintains the values for all of the runtime context variables. When an image is deployed, the user deploying it can replace these values with new ones (or even add or remove variables altogether) as appropriate for the new environment. Federator remembers variables on a per-environment-tag basis; for example, variables used to deploy to an environment tagged as Dev are remembered distinctly from those used to deploy to an environment tagged as Prod. Variables can be edited when instantiating a template, or when deploying or promoting an image. They can also be edited directly for a template or for a deploy/promote/instantiate ticket. To edit variables: 1. On a page with editable variables, click the Edit Variables button. The Edit Variable List dialog appears, showing the current state of the variables. Variables are listed by the component they belong to. 2. For image deployment and promotion, choose the starting point from the Start with variables for stage pop-up list. (When editing templates, there is only one option default. ) When you choose from the pop-up list, the variables table is updated with the values saved for that tag. Once you ve used the dialog box to edit variables and clicked OK, the pop-up will show as Custom, indicating that you ve made changes to one of the tagged sets. 3. For existing variables, you can edit their fields: name, value, type, increment type, and export status. TIBCO DataSynapse Federator User Guide 65

69 Using Platform as a Service 4. Click the Add a New Variable link to add a new variable to the end of the list. In addition to the other fields, you will need to specify the component to which the new variable belongs. 5. To remove an existing variable, click the Delete (trash can) button to its right. 6. When you are done editing the variables, click the OK button to save your changes or click Cancel to abandon your changes. Artifact Locking and Maintenance Mode Federator locks the images and templates when users edit them or otherwise try to perform operations on them. This prevents multiple users from accessing the same image or template at the same time and overwriting each other s changes. (The current locking status of an image or template, including who locked it and when, can be seen by using the Show button from the Images and Templates pages.) Normally, locks are released when the operation is finished; however, if a sufficient amount of time has elapsed since the image or template was locked, Federator assumes that the lock is invalid. This duration is specified by the Application Locking Timeout configuration property (see Configuring PaaS on page 55). When it is necessary to prevent users from modifying any images or templates whatsoever, maintenance mode can be turned on (on the PaaS page of the Admin tab). This effectively locks all artifacts in the system, for example allowing an administrator to back up Federator s repository without worrying that it might change during the backup. To unlock them again, turn off maintenance mode. Note that unlike normal locking, the timeout never comes into effect, so it is important that maintenance mode be disabled when it is no longer needed. 66 Chapter 6 Platform as a Service