tibco silver fabric - tibco software · † silver fabric developer’s guide developer-related...

Two-Second Adv

TIBCO Silver® Fabric

Installation GuideSoftware Release 5.7.1October 2015

antage®

Important Information

SOME TIBCO SOFTWARE EMBEDS OR BUNDLES OTHER TIBCO SOFTWARE. USE OF SUCH EMBEDDED OR BUNDLED TIBCO SOFTWARE IS SOLELY TO ENABLE THE FUNCTIONALITY (OR PROVIDE LIMITED ADD-ON FUNCTIONALITY) OF THE LICENSED TIBCO SOFTWARE. THE EMBEDDED OR BUNDLED SOFTWARE IS NOT LICENSED TO BE USED OR ACCESSED BY ANY OTHER TIBCO SOFTWARE OR FOR ANY OTHER PURPOSE.USE OF TIBCO SOFTWARE AND THIS DOCUMENT IS SUBJECT TO THE TERMS AND CONDITIONS OF A LICENSE AGREEMENT FOUND IN EITHER A SEPARATELY EXECUTED SOFTWARE LICENSE AGREEMENT, OR, IF THERE IS NO SUCH SEPARATE AGREEMENT, THE CLICKWRAP END USER LICENSE AGREEMENT WHICH IS DISPLAYED DURING DOWNLOAD OR INSTALLATION OF THE SOFTWARE (AND WHICH IS DUPLICATED IN THE LICENSE FILE) OR IF THERE IS NO SUCH SOFTWARE LICENSE AGREEMENT OR CLICKWRAP END USER LICENSE AGREEMENT, THE LICENSE(S) LOCATED IN THE “LICENSE” FILE(S) OF THE SOFTWARE. USE OF THIS DOCUMENT IS SUBJECT TO THOSE TERMS AND CONDITIONS, AND YOUR USE HEREOF SHALL CONSTITUTE ACCEPTANCE OF AND AN AGREEMENT TO BE BOUND BY THE SAME.This document contains confidential information that is subject to U.S. and international copyright laws and treaties. No part of this document may be reproduced in any form without the written authorization of TIBCO Software Inc.TIBCO, Two-Second Advantage, GridServer, FabricServer, GridClient, GridBroker, FabricBroker, LiveCluster, VersaUtility, VersaVision, SpeedLink, Federator, and RTI Design are either registered trademarks or trademarks of TIBCO Software Inc. in the United States and/or other countries.Enterprise Java Beans (EJB), Java Platform Enterprise Edition (Java EE), Java 2 Platform Enterprise Edition (J2EE), and all Java-based trademarks and logos are trademarks or registered trademarks of Oracle Corporation in the U.S. and other countries.All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only.THIS SOFTWARE MAY BE AVAILABLE ON MULTIPLE OPERATING SYSTEMS. HOWEVER, NOT ALL OPERATING SYSTEM PLATFORMS FOR A SPECIFIC SOFTWARE VERSION ARE RELEASED AT THE SAME TIME. SEE THE README FILE FOR THE AVAILABILITY OF THIS SOFTWARE VERSION ON A SPECIFIC OPERATING SYSTEM PLATFORM.THIS DOCUMENT IS PROVIDED “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT.THIS DOCUMENT COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS. CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN; THESE CHANGES WILL BE INCORPORATED IN NEW EDITIONS OF THIS DOCUMENT. TIBCO SOFTWARE INC. MAY MAKE IMPROVEMENTS AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS DOCUMENT AT ANY TIME.THE CONTENTS OF THIS DOCUMENT MAY BE MODIFIED AND/OR QUALIFIED, DIRECTLY OR INDIRECTLY, BY OTHER DOCUMENTATION WHICH ACCOMPANIES THIS SOFTWARE, INCLUDING BUT NOT LIMITED TO ANY RELEASE NOTES AND "READ ME" FILES.TIBCO products may include some or all of the following:Software developed by Terence Parr.Software developed by the Apache Software Foundation (http://www.apache.org/).This product uses c3p0. c3p0 is distributed pursuant to the terms of the Lesser General Public License. The source code for c3p0 may be obtained from http://sourceforge.net/projects/c3p0/. 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 c3p0.Software developed by MetaStuff, Ltd.

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 http://eclipse.org/.Software developed by Info-ZIP.This product includes Javassist licensed under the Mozilla Public License, v1.1. You may obtain a copy of the source code from http://www.jboss.org/javassist/This product includes software licensed under the Common Development and Distribution License (CDDL) version 1.0. The source code for such software licensed under the Common Development and Distribution License (CDDL) version 1.0 is available upon request to TIBCO.Software developed by Jason Hunter & Brett McLaughlin.Software developed by JSON.org.Software developed by QOS.ch.Software developed by the OpenSymphony Group (http://www.opensymphony.com/).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.Software developed by the Indiana University Extreme! Lab (http://www.extreme.indiana.edu/).Software developed by Jean-loup Gailly and Mark Adler.All other product and company names and marks mentioned in this document are the property of their respective owners and are mentioned for identification purposes only.This Product is covered by U.S. Patent No. 6,757,730, 7,093,004, 7,093,004, and patents pending. Copyright © 1999-2015 TIBCO Software Inc. ALL RIGHTS RESERVED.TIBCO Software Inc. Confidential Information

| v

Contents

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

Related Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xTIBCO Silver Fabric Documentation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xOther Documentation and Help . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xi

Typographical Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xii

Connecting with TIBCO Resources . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvHow to Join TIBCOmmunity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvHow to Access All TIBCO Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xvHow to Contact TIBCO Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . xv

Chapter 1 Installation Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1

1) Know the Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2) Meet Silver Fabric System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

3) Optimize Silver Fabric Broker Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4Component OS and Version Interoperability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5Silver Fabric Brokers on an NFS File System. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

4) Configure Your Network. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Name Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Communication Port Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7Broker-Broker Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Broker-Engine Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Broker-VirtualRouter Communication. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Engine-Engine Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8Using NAT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Using a VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9Resource Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10SSL. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5) Install the Silver Fabric Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Silver Fabric Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Silver Fabric Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11Silver Fabric VirtualRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Skyway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12Command Line Interface Tool. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

TIBCO Silver® Fabric Installation Guide

vi |

Chapter 2 Broker Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

About Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16Updates and Other Supported Platforms. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

Installing Silver Fabric Brokers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Silent Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Installing Additional Enablers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25Deleting Grid Libraries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

Clustering Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

Configuration Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28Changing the Broker HTTP Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

A Sample Unix rc.d Script . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

Chapter 3 Windows Engine Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

Manual Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

Network Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

Installing Windows Engines in a Non-default Location . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Engine JRE Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

Engine Permissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

Running Engines in Console Mode. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

Application Extraction Issues With Windows Engines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

Engine Configuration and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Chapter 4 Unix Engine Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

Installing the Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

Running the Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

Engine JRE Synchronization. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Engine Configuration and Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Chapter 5 VirtualRouter Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Installing VirtualRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

Configuring VirtualRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52The virtualrouter.properties File. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52VirtualRouter Settings on the Broker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52Configuring the Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52JBoss . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53Verifying Your VirtualRouter Installation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54


| vii

Using VirtualRouter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

VirtualRouter Authentication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

Chapter 6 Verifying your Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .57

Using the VirtualRouter Status Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

Chapter 7 Uninstalling Silver Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .61

Uninstalling Silver Fabric on Windows Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Uninstalling an Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Manual Uninstall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62Uninstalling a Broker. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62

Uninstalling Silver Fabric on Unix Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64

Uninstalling Enablers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65

Chapter 8 Upgrading Silver Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .67

Upgrading From Previous Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Supported Upgrade Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68Requirements Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

Silver Fabric Upgrade Checklist . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69

Installing Hotfixes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71Uninstallation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

Broker Upgrade and Engine Restarts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72Disabling Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Upgrading a Failover Pair . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73Standalone Broker Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

Engine Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

VirtualRouter Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77

PCM and Skyway Upgrade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

Silver Fabric 5.7 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Requirements Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Silver Fabric 5.6 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Requirements Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

Silver Fabric 5.5 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81API . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82Requirements Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82


viii |

Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

Silver Fabric 5.0 SP1 Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

Silver Fabric 5.0 Changes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85PCM and Skyway. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Terminology Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Other Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Enabler Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

Appendix A Asset Manager Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

Installing Asset Managers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

Installing and Using the VMware Asset Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Preparation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91Example Startup Scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94Configuring and Enabling the Asset Manager for VMware . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96VMware Behavior During Failover . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96VMware Scripted Engine Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97Customization Specifications. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Available Asset Manager Configuration Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98Available Policy and Component Configuration Properties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

Appendix B Database Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

Installing Standalone HSQLDB. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106

Reporting Database Installation and Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107

Third-Party Database Known Issues. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Microsoft SQL Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110Sybase. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110


| ix

Preface

TIBCO Silver® Fabric combines the flexibility and scalability of the public cloud with the security and control of your own data center. It brings the elasticity of cloud computing to your organization – supporting existing solutions within your current infrastructure while automatically scaling resources to meet demand.

Topics

• Related Documentation, page x

• Typographical Conventions, page xii

• Connecting with TIBCO Resources, page xv


x |

Related Documentation

This section lists documentation resources you may find useful.

For the latest version of documentation, including any changes or additions made since the last product release, please visit http://docs.tibco.com.

TIBCO Silver Fabric DocumentationThe following documentation is included with Silver Fabric in Adobe Acrobat (PDF) format. To view the guides, log in to the Administration Tool and go to Admin > Documentation. The PDF files are also on the Broker at SF_HOME/webapps/livecluster/admin/docs. The following documents form the Silver Fabric documentation set:

• Silver Fabric Concepts Contains an introduction to Silver Fabric, including definitions of key concepts and terms, such as Enablers, Stacks, Components, Engines, and Brokers. Read this first if you are new to Silver Fabric.

• Silver Fabric Installation Guide Covers installation of Silver Fabric for Windows and Unix, including Brokers, Engines, and pre-installation planning.

• Silver Fabric Cloud Administration Guide Covers Silver Fabric cloud administration, configuration of Engines, Enablers, and Components, and configuration and use of Skyway. Also covers security, general maintenance, performance tuning, and database administration.

• Silver Fabric Developer’s Guide Developer-related topics such as logging and debugging, using the Admin API, and the Enabler SDK.

• Silver Fabric Developer’s Tutorial Tutorials for developers, such as how to write Enablers and Asset Managers.

• Silver Fabric User’s Guide Covers Silver Fabric use and operation, including management of Engines, Enablers, Components, and Stacks.

• Silver Fabric Skyway User’s Guide Covers usage of Skyway, which enables users to quickly and easily provision and manage their Silver Fabric Stacks.

• Silver Fabric Tomcat Enabler Guide Covers installation and configuration of applications run on the Tomcat Enabler.

• Silver Fabric Command Line Enabler Guide Covers installation and configuration of applications run on the Command Line Enabler.


http://docs.tibco.com

| xi

Other Documentation and HelpAdditional help and information is available from the following sources:

• Silver Fabric Administration Tool Help Context-sensitive help is provided throughout the Silver Fabric Administration Tool by clicking the Page Help button located on any page.

• API Reference Silver Fabric API reference information is available in the Silver Fabric SDK in the api directory in JavaDoc format. You can also view and search them from the Silver Fabric Administration Tool; log in to the Administration Tool and go to Admin > Documentation.


xii |

Typographical Conventions

The following typographical conventions are used in this manual.

Table 1 General Typographical Conventions

Convention Use

TIBCO_HOME

SF_HOME

Many TIBCO products must be installed within the same home directory. This directory is referenced in documentation as TIBCO_HOME. The default value of TIBCO_HOME depends on the operating system. For example, on Windows systems, the default value is C:\tibco.

TIBCO Silver® Fabric installs into a directory within TIBCO_HOME. This directory is referenced in documentation as SF_HOME. The default value of SF_HOME depends on the operating system. For example on Windows systems, the default value is C:\tibco\fabric.

code font Code font identifies commands, code examples, filenames, pathnames, and output displayed in a command window. For example:

Use MyCommand to start the foo process.

bold code

font Bold code font is used in the following ways:

• In procedures, to indicate what a user types. For example: Type admin.

• In large code samples, to indicate the parts of the sample that are of particular interest.

• In command syntax, to indicate the default parameter for a command. For example, if no parameter is specified, MyCommand is enabled: MyCommand [enable | disable]

italic font Italic font is used in the following ways:

• To indicate a document title. For example: See TIBCO ActiveMatrix BusinessWorks Concepts.

• To introduce new terms. For example: A portal page may contain several portlets. Portlets are mini-applications that run in a portal.

• To indicate a variable in a command or code syntax that you must replace. For example: MyCommand PathName


| xiii

Key combinations

Key names separated by a plus sign indicates keys pressed simultaneously. For example: Ctrl+C.

Key names separated by a comma and space indicate keys pressed one after the other. For example: Esc, Ctrl+Q.

The note icon indicates information that is of special interest or importance, for example, an additional action required only in certain circumstances.

The tip icon indicates an idea that could be useful, for example, a way to apply the information provided in the current section to achieve a specific result.

The warning icon indicates the potential for a damaging situation, for example, data loss or corruption if certain steps are taken or not taken.

Table 1 General Typographical Conventions (Continued)

Convention Use

Table 2 Syntax Typographical Conventions

Convention Use

[ ] An optional item in a command or code syntax.

For example:

MyCommand [optional_parameter] required_parameter

| A logical OR that separates multiple items of which only one may be chosen.

For example, you can select only one of the following parameters:

MyCommand param1 | param2 | param3


xiv |

{ } A logical group of items in a command. Other syntax notations may appear within each logical group.

For example, the following command requires two parameters, which can be either the pair param1 and param2, or the pair param3 and param4.

MyCommand {param1 param2} | {param3 param4}

In the next example, the command requires two parameters. The first parameter can be either param1 or param2 and the second can be either param3 or param4:

MyCommand {param1 | param2} {param3 | param4}

In the next example, the command can accept either two or three parameters. The first parameter must be param1. You can optionally include param2 as the second parameter. And the last parameter is either param3 or param4.

MyCommand param1 [param2] {param3 | param4}

Table 2 Syntax Typographical Conventions (Continued)

Convention Use


| xv

Connecting with TIBCO Resources

How to Join TIBCOmmunityTIBCOmmunity is an online destination for TIBCO customers, partners, and resident experts, a place to share and access the collective experience of the TIBCO community. TIBCOmmunity offers forums, blogs, and access to a variety of resources. To register, go to http://www.tibcommunity.com.

How to Access All TIBCO DocumentationAfter you join TIBCOmmunity, you can access the documentation for all supported product versions here:


How to Contact TIBCO SupportFor comments or problems with this manual or the software it addresses, please contact TIBCO Support as follows.

• For an overview of TIBCO Support, and information about getting started with TIBCO Support, visit this site:

http://www.tibco.com/services/support

• If you already have a valid maintenance or support contract, visit this site:

https://support.tibco.com

Entry to this site requires a user name and password. If you do not have a user name, you can request one.


http://www.tibco.com/services/support

https://support.tibco.com


http://www.tibcommunity.com

xvi |


| 1

Chapter 1 Installation Overview

This guide is your starting point for planning, installing, and configuring TIBCO Silver® Fabric software for your site. The document is divided into several sections to explain how to install, test, and uninstall the Broker, Client, and Engines on both Windows and Unix platforms.

Use this guide if you are:

• A business or technology manager planning or assessing requirements for a Silver Fabric installation.

• An engineer or administrator installing and configuring a Silver Fabric system.

This chapter provides a road map of prerequisites and required steps for a Silver Fabric installation. It is intended to assist developers, system architects, and network architects in planning a Silver Fabric production deployment. Read this chapter carefully before beginning installation to prepare for installation.

Before you begin your Silver Fabric installation, you must first determine what Silver Fabric components you must install, and how your overall system will be configured. You must also prepare for the installation, meet system requirements, and have an overall understanding of Silver Fabric and the installation process.

Topics

• 1) Know the Basics, page 2

• 2) Meet Silver Fabric System Requirements, page 3

• 3) Optimize Silver Fabric Broker Architecture, page 4

• 4) Configure Your Network, page 7

• 5) Install the Silver Fabric Components, page 11


2 |

1) Know the Basics

This guide presumes a basic familiarity with the operating concepts of Silver Fabric. Introducing Silver Fabric is a technical overview of the Silver Fabric component architecture and principles of operation. This guide is included in your installation package.

You should also be familiar with Windows and Unix operating systems and TCP/IP networking.

Terminology used to name objects changed in Silver Fabric 5.0. See Terminology Changes on page 85 for more information.


| 3

2) Meet Silver Fabric System Requirements

Before starting your installation, your environment must meet the minimum hardware and software system requirements for memory, disk space, and processor speed. Please see the included Silver Fabric Readme for the complete list of all hardware and software requirements, including supported operating systems (Windows, Linux, UNIX), Java or .NET software, web browsers and accompanying components.


4 |

3) Optimize Silver Fabric Broker Architecture

The Silver Fabric Broker architecture can be deployed to give varying degrees of redundancy, depending on the available computing resources. Before installation, it’s important to ascertain how Silver Fabric will be used, and survey what hardware and networking is required for the installation. With this information, you can plan the architecture that best supports your needs.

First, it’s important to understand the architecture of a Broker. See Introducing Silver Fabric for a detailed explanation of the Silver Fabric architecture.

A minimal configuration of Silver Fabric consists of a single Broker. You can add an additional failover Broker to address redundancy concerns.

A Broker’s configuration (as primary or failover) is initially set during Broker installation on the Broker Type screen. To change Broker configuration on a running Broker, go to Admin > Reinstall, follow the screens for Broker reinstallation, and restart your Broker when the configuration is complete.

FailoverGiven a minimal configuration of a single Broker, Engines and Clients log in to the Broker. In this configuration, failure of the Broker (such as in the case of hardware or network failure), Clients or Engines cannot establish new connections.

To prevent this, you can run a second Broker configured as a Failover Broker, and configure Engines and Clients with the address of both Brokers. If the Primary Broker fails, Engines and Clients contact the Failover Broker, which routes Engines and Clients in the same manner as the Primary Broker.

The following limitations apply to Failover Brokers:

• Stacks, Schedules, and Component settings on a Failover Broker are synchronized from the Primary Broker, but are read-only on the Failover Broker, and can’t be changed.

• Broker configuration is not synchronized between Brokers. You must change configurations at each Broker. You can also use the Import/Export feature to export setting from one Broker and import them to others.

• Any Stack starts or stops made on the Failover Broker will be lost when the Primary Broker is restored.

• Allocation overrides made on the Console page are lost during a migration from Primary to Failover Broker or vice-versa.


| 5

Component OS and Version InteroperabilityA Silver Fabric installation requires that all Silver Fabric components are of the same version. This is true of Brokers, Engines, and Clients. When you upgrade a Silver Fabric Broker, you must also upgrade Clients.

There is no requirement or performance benefit to running Brokers on the same OS as other components. However, running the same OS for all components simplifies administration and troubleshooting.

Silver Fabric Brokers on an NFS File SystemBecause of the large number of files that need to be shared among Silver Fabric Brokers and Engines, it is tempting to consider using a shared file system (such as NFS) to reduce the space and time lag associated with downloading the files locally to every Engine. However, NFS can be unreliable on congested networks, and applications like the Silver Fabric Broker and its Engines have not been implemented to handle the complexities of recovering from disk I/O failures involving underlying transient network problems. The problems can be compounded when files that were there a moment ago suddenly disappear only to reappear seconds later by which time the damage is done and logs are filling with messages, or worse, components are being deactivated..

The reliability of physical disks is such that they either work or fail catastrophically. This differs from network-based disks which can temporarily fail due to a transient network issue and then suddenly work again. In the case of a physical disk failure, the machine in which it resides needs a repair, and if that machine is where Silver Fabric is running, then it will also be down along with whatever other applications run on that machine. Everyone will know it is broken and in need of manual intervention. Due to the all-or-nothing reliability profile of physical disks, applications don’t normally include extra logic to retry failed I/O operations as this responsibility is delegated to the physical disk hardware and the software driver. With a network disk, this responsibility is delegated to the network file system driver. Due to the inherent nature of networks (packets are lost, connections are dropped, cables are cut mistakenly by large machines working on the street) the network file system driver is much more likely to raise errors to the application level, such as the Silver Fabric Broker or Engine. While in theory the physical disk driver can also pass errors up to the application layer, the reality is that physical disk reliability is such that it almost never does, and when it does, it is usually the last gasp before it catastrophically fails and you find yourself installing a new disk and restoring from backup.

As stated, an individual I/O on a physical disk can, in theory, fail all the way back to the application level to allow the application to recover possibly by retrying the operation and hoping for a better outcome. In reality, this is not done because if the underlying system call made by the application cannot succeed with all the


6 |

retry logic in the disk controller, and layers of driver software then retrying from the application is pointless, such is the nature of physical disk. With shared network disk technology such as NFS, this is not so, because the network read or write operation that timed out a second ago due to lost or delayed packets resulting from a transient network condition may now succeed if the operation is retried. The NFS driver is largely transparent as it exposes network endpoints as if they were local physical disks to the application but because network transmissions are not as fast, consistent or reliable as physical disk electronics the NFS driver occasionally returns potentially recoverable I/O errors to the application. The issue then is that if the application is not implemented with this in mind, it is likely to consider any such I/O error as catastrophic or in worst case misinterpret their result.

Due to this behavior of NFS filesystems and the fact that the Silver Fabric software has not been implemented to counter NFS unreliability, we cannot recommend its use with Silver Fabric. If one chooses to disregard this recommendation, they should consider the implications of NFS transient failures and plan or tune the software and systems accordingly to minimize the impact.


| 7

4) Configure Your Network

Since Silver Fabric is a distributed computing application, successful deployment depends on your network configuration. Treat Silver Fabric Brokers and Engines the same way you treat your other mission-critical file and application servers: assign Silver Fabric Brokers and Engines static IP addresses and resolvable DNS hostnames.

Name ServiceRun Silver Fabric Brokers and Engines on systems with static IP addresses and resolvable DNS hostnames. In a pure Windows environment, it is possible to run Silver Fabric using only WINS name resolution, but this is not recommended for larger deployments or heterogeneous environments. Silver Fabric does not support DHCP-assigned client addresses for Broker components; DHCP-assigned addresses are acceptable for Engines and Clients.

Communication Port RequirementsBy default, the following ports must be open on the Broker machines. See Changing the Broker HTTP Ports on page 28 for information on changing Broker ports.

Table 3 Broker Communication Port Requirements

Port Type Description

8080 HTTP Administration Tool port. Configurable in the conf/server.xml file, but also requires a Broker reinstallation.

8000 HTTP Broker messaging and resource download port for Engines. Configurable in the conf/server.xml file, but also requires a Broker reinstallation.

8005 HTTP Tomcat shutdown listener port. Configurable in the conf/server.xml file.

8443 HTTPS Optional Administration Tool port. Configurable in the conf/server.xml file, but also requires a Broker reinstallation.

8043 HTTPS Optional Broker messaging and resource download port for Engines. Configurable in the conf/server.xml, but also requires a Broker reinstallation.

2000 TCP Login port for the failover/primary Broker. Configurable in the Broker installation.


8 |

By default, the following ports must be open on Engine machines:

Broker-Broker CommunicationThe Primary and Failover Brokers communicate using TCP on port 2000. This port is used for both initial login and further communication. You can specify another port at installation, or by reinstalling the Broker at Admin > Reinstall.

A range of ephemeral ports are also used for Broker to Broker communication. This can be configured to use a set of static ports in the Administration Tool at Config > Broker > Communication, with the Port Range property.

Broker-Engine CommunicationAll communication between Engines and Brokers uses the HTTP protocol, with the Engine acting as HTTP client and the Broker acting as HTTP server.

Broker-VirtualRouter CommunicationAll VirtualRouter to Broker communication uses socket connections, as opposed to HTTP. This uses a range of ephemeral ports. This can be configured to use a set of static ports in the Administration Tool at Config > Broker > Communication, with the Port Range property.

For an external VirtualRouter, the Java system property ds.externalVR.portRange can be set to the desired port range. The property DSClientPortRange can also be set in the virtualrouter.properties file.

Engine-Engine CommunicationWhen using the load balancing WebLogic plugin on an Apache or SunOne server or when using JBoss or WebSphere clustering, multicast broadcasting is required between Engines, or all Engines must be on the same subnet. (Normally, routers and switches are configured to prevent multicast traffic.)

The WebLogic plugin can use VirtualRouter to pick up WebLogic nodes and obtain information on other nodes in the WebLogic cluster from them. Without multicasting, it will only successfully pick up other Engines in same subnet.

Table 4 Engine Communication Port Requirements

Port Type Description

27159 HTTP Messaging and log retrieval port. Configurable in the Engine Configuration.


| 9

Engines and Clients can run behind a VPN, provided that the Engine Daemon or Client can determine the correct IP address to use. If the VPN is handled by VPN client software on the Engine/Client machine, can possibly specify which IP address to use. For Engines, in the Engine Configuration, use the Net Mask setting to force the engine to pick the VPN interface. For Clients, you can set the DSLocalIPAddress property to the IP number of the correct interface.

If the Engine/Client-side VPN is handled by an external device, like a router, it is unlikely that the Engine Daemon or Client can determine the VPN address. Running Engines or Clients in this configuration is not possible.

Using NATYou can configure the Broker to work with a NAT device between the Broker and the Engines or Clients. If the untranslated site of the network has no Engines, you can configure to work with a NAT device by specifying the external (translated) address of the NAT device when referring to the Broker address in the Broker URL field during Broker installation, in Client installation, and in manual Windows, Linux, and Solaris Engine installation.

If clients (Engines and Drivers) exist on both sides of a NAT device, you can configure NAT Translation on the Broker. This enables the URLs used for Broker-to-client communication.

To configure NAT Translation in the Silver Fabric Administration Tool:

1. Go to Config > Broker > Communication.

2. Find the NAT Translation heading.

3. The first field, NAT Translation Range, specifies the range of IP addresses within the NAT untranslated network to be translated. In the NAT URL field, type the external URL to use for the Broker on the translated side of the network. If you want the NAT URL used for clients inside the NAT Translation range, set Translate Inside Range (True/False) to True; to use NAT translation for clients outside the NAT Range, set this to False.

Using a VPNEngines and Clients can run behind a VPN, provided that the Engine Daemon or Client can determine the correct IP address to use. If VPN client software on the Engine/Client machine handles the VPN, can possibly specify which IP address to use. For Engines, in the Engine Configuration, use the Net Mask setting to force the engine to pick the VPN interface. For Clients, you can set the DSLocalIPAddress property to the IP number of the correct interface.


10 |

If an external device like a router handles the Engine/Client-side VPN, it is unlikely that the Engine Daemon or Client can determine the VPN address. Running Engines or Clients in this configuration is not possible.

Resource SynchronizationNormally, Silver Fabric synchronizes resources from Brokers to Engines. However, in situations where you want to deploy Grid Libraries to only a subset of Engines, you can disable resource synchronization in an Engine Configuration, and then provide a list of Grid Library locations to use instead. On the Engine Configuration page, set the Synchronize Resources property in the Resource Validation section to false to disable resource synchronization for that Engine Configuration. Then define resource locations on the Config > Grid Library Locations page, and define a list of locations in the Engine Configuration’s Gridlib Locations property.

Consider the following business use case: using offsite rented systems (on-demand systems) for Engines. An offsite shared collocation facility hosts some Engine systems. You do not fully trust the collocation provider to erase all sensitive data before reusing the systems, so you keep all resources, including code, on a file server at your site. The offsite Engines have a special offsite Engine Configuration pointing lib directories to a file server at your site. You configure other Engines at your site to use resource deployment in the normal way.

Note that the use of a shared resource directory may not be transparent to all Enablers. If a given Enabler is affected by the use of such a directory, its guide’s chapter on installation should contain a note detailing any such impact.

For more information, see “Configuring Alternate Shared Grid Library Locations” in the Silver Fabric Cloud Administration Guide.

SSLYou can configure your Broker to use SSL selectively or for all component communication and administration.

For more information on using SSL, see “Configuring Security” in the Silver Fabric Cloud Administration Guide.


| 11

5) Install the Silver Fabric Components

After preparing for your installation, install the Silver Fabric components as described below.

Silver Fabric BrokerTo install a Broker, follow the installation procedure outlined in the Broker Installation chapter. Repeat the procedure if installing a Failover Broker. A running Broker is required before proceeding to Engine installation.

For more information on installing Brokers, see Chapter 2, Broker Installation, on page 15.

Silver Fabric EngineSilver Fabric Engines come in two variants: Windows Engines and Unix Engines. The following deployment methods are available for Windows platforms only:

• One-Click Web Install uses an InstallShield installer for ease of use when installing small numbers of Windows Engines.

• Windows also supports SMS installation of Engines.

The following deployment methods are available for both Windows and Unix systems:

• If you can map a directory on the Broker using Windows file sharing or Samba to be visible to Engines, use Network Installation from Server to run a .bat file when the Engine’s OS is booted. Also, an installation script can be used with Unix distributions to install Engines remotely.

• Manual Installation is supported through a Windows self-extracting installer executable and .tgz files in Unix.

Security Considerations

On the Windows platform, both Engines and Brokers run as services owned by the Local System account. You must reboot the machine after install to run the Engine with the Local System account. The Engine then automatically runs as a service after each system reboot.

To prevent unauthorized users from accessing files in the Engine’s directory tree, the Windows system administrator can set up the Engine directory so that it does not inherit permission from the parent directory and it grants full access to the built-in SYSTEM and SERVICE users but does not grant access to any other users.


12 |

On Unix platforms, Engines and Brokers install with the file permissions of the user that installs them. Engines and Brokers should be started by that same user. For this reason, choose a Broker port above 1024.

For more information on installing Engines, see Chapter 3, Windows Engine Installation, on page 33, and Chapter 4, Unix Engine Installation, on page 43.

Silver Fabric VirtualRouterTo install a VirtualRouter, follow the installation procedure outlined in Chapter 5, VirtualRouter Installation, on page 49.

SkywaySkyway is installed with the the Broker installation and does not require a separate installation.

DatabaseSilver Fabric uses an included internal database. You can also configure Silver Fabric to use an external reporting database, on an enterprise database system.

For more information on database configuration, see Appendix B, Database Configuration, on page 105.

Command Line Interface ToolSilver Fabric’s optional Command Line Interface tool enables you to perform common Stack and Component management tasks from a command line interface. The Command Line Interface is useful when you want to administer Silver Fabric from a machine that does not have GUI components installed. The Command Line Interface also provides an alternative to Silver Fabric's REST-based admin API, enabling the integration of Silver Fabric functionality into third-party or custom, in-house applications when using the REST API is undesirable.

To install the Command Line Interface tool:

1. In the Silver Fabric Administration Tool, go to Admin > Downloads.

By default, no reporting database is configured. The included HSQLDB reporting database can be used for lightweight reporting, but it is primarily for demonstration, development, and integration purposes. For production environments, use an enterprise database system that supports JDBC.


| 13

2. Click the link for the Silver Fabric command line admin tool and TAR file: SilverFabricCLI.tar.gz.

3. Save the file locally, and extract the archive.

4. Edit the fabric-cli.properties file located in the base directory of the extracted archive. Set the DSUserName and DSPassword properties to the name and password of the user you want to use when connecting to Silver Fabric with the Command Line Interface tool.

5. You may also consider setting logging location and level with the DSLogDir and DSLogLevel properties in the fabric-cli.properties file.


14 |


| 15

Chapter 2 Broker Installation

To begin your TIBCO Silver® Fabric installation, you must install one or more Brokers. This chapter describes installation of the Broker, plus installation of a Failover Broker.

Before installation, read the previous chapter, Chapter 1, Installation Overview, on page 1 thoroughly.

Topics

• About Installation, page 16

• Installing Silver Fabric Brokers, page 17

• Silent Installation, page 24

• Installing Additional Enablers, page 25

• Clustering Configuration, page 27

• Configuration Options, page 28

• A Sample Unix rc.d Script, page 30


16 |

About Installation

The Installation includes an embedded Tomcat application server, plus the Silver Fabric software, packaged as a tar.gz file. Use the same archive for Windows, Linux, and Solaris installations. Your software is provided on a CD-ROM or downloaded install package. Make sure the files are available on your machine before you begin.

Updates and Other Supported PlatformsOther supported platforms are optionally available from TIBCO customer support as a Silver Fabric update. These typically include a Readme file with further instructions or requirements for installation.


| 17

Installing Silver Fabric Brokers

To install the Silver Fabric Broker, complete the following steps:

Task A Copy files before installation

To copy files used to install Silver Fabric:

1. Decide where to install the Broker. The recommended location for Unix machines is /opt/TIBCO/fabric; the recommended location for Windows is c:\TIBCO\fabric. This installation procedure refers to this installation directory as SF_HOME.

The following limitations apply to the Broker installation directory:

— Do not install the Broker in a directory containing a space, such as c:\Program Files.

— Do not install the Broker in a directory that is a symbolic link to another directory.

— Do not install the Broker in an NFS file system. See Silver Fabric Brokers on an NFS File System on page 5.

2. The software is shipped as a gzipped TAR archive containing the Broker installation. To unpack it on a Windows system, use WinZip or a similar tool. On a Unix system, use tar and gzip. (Note that for Solaris you must use GNU tar.) For Unix, use the following command:

gzip -d -c TIB_Silver_Fabric*gz | tar xvf -

3. Install the unlimited strength JCE for your Java SDK. The files are located in SF_HOME/webapps/livecluster/WEB-INF/etc/jce. Follow the instructions in the README.txt for your SDK to install the files.

Task B Configure server settings

If you need to make changes to any of the following, make the changes to the appropriate config file or environment variable, as required:

The TAR file contains the fabric directory. If you expand the archive in /opt/TIBCO, then /opt/TIBCO/fabric is created.


18 |

Java Settings

You must set the JAVA_HOME environment variable to the root directory of your Java installation. If you are using a JRE instead of the JDK, you can set the JRE_HOME environment instead.

In Windows, to set the JAVA_HOME environment variable:

1. Right click My Computer and select Properties.

2. Click Advanced System Settings.

3. On the Advanced tab, select Environment Variables, and then add or edit JAVA_HOME to point to where the Java JDK installation is located, for example, C:\Program Files\Java\jdk1.7.0_72.

In Unix, to set the JAVA_HOME environment variable, if the Java installation is located in java-install-dir:

— Korn and bash shells:

export JAVA_HOME=java-install-dir; export PATH=$JAVA_HOME/bin:$PATH

— Bourne shell:

JAVA_HOME=java-install-dir; export JAVA_HOME; PATH=$JAVA_HOME/bin:$PATH; export PATH

— C shell:

setenv JAVA_HOME java-install-dir; setenv PATH $JAVA_HOME/bin:$PATH; export PATH=$JAVA_HOME/bin:$PATH

Default File Handle Limit

If you are installing a Broker on a Unix system and plan to run a large cloud, you may need to increase the default limit for the number of open file handles. The default on most Unix systems is 1024. In Linux, this is done in the /etc/security/limits.conf file.

Task C Start the Broker

Start the Broker, as follows:

Windows

Start the Windows Broker by running the server.bat file, located in the root directory of the Silver Fabric distribution. To test, open a command window and run server.bat run to launch the Broker and start Silver Fabric. The command window will contain log messages from the application server.


| 19

The server.bat script takes the following arguments:

The Broker is typically run as a Windows Service in production systems. To do so, open a command window and run service.bat with the following arguments:

In Windows 7, you must run the service.bat command as an administrator.

When installing as a service on Windows Server 2008, before starting the service, either add %JAVA_HOME%/bin to your PATH, or copy %JAVA_HOME%/bin/mscvr71.dll to a directory in your path.

For initial installation, install the Broker as a Windows service, then start the service.

Unix

Launch the Broker by invoking the server.sh script in the install directory with following arguments:

Argument Description

start Start the Broker. The first time this runs, it will copy volatile files into the base directory.


install Install the Broker as a Windows service.

remove Remove the Broker’s service.

start Start the installed service.

stop Stop the service.


run Start the Broker in the foreground. The first time this runs, it will copy volatile files into the base directory.

start Start the Broker in the background.

stop Stop the Broker running in the background


20 |

You can configure the Broker to launch automatically at system startup and stop cleanly at shutdown. Since the server.sh script conforms to the standard start/stop argument convention (“rc script”), you can accomplish this simply by linking to the appropriate files in the /etc/rc.d directories. For more information on initialization and termination scripts, refer to the init and init.d man pages on your Unix system and see A Sample Unix rc.d Script on page 30.

Task D Initialize Your Broker

After the Broker is running for the first time, you must initialize it.

To initialize the Broker:

1. Start the Silver Fabric Administration Tool

Go to http://yourhost:port/livecluster to open the installation page.

2. Accept the End User License Agreement, and click Proceed.

Figure 1 Accepting the End User License Agreement.


| 21

3. Select Installation Type

4. There are two different options for installation: Typical, and Custom. The default is a Typical installation, which installs a Broker with all default settings. If you select Typical, click Next and skip to step 6.

To change any other parts of your configuration, choose Custom. Additional configuration steps let you further configure your Broker.

5. Enter Configuration Values.

In the Silver Fabric Configuration page, select New Broker Installation, click Next, and enter values for each applicable item on each screen. For more information, on any page, click Page Help.

When installing a failover Broker, go through the installation process and install your primary Broker first. Then, install a second Broker on another machine, and when using the Custom option, change the Broker type option to failover.

6. Verify and Install

After you complete a Custom or Typical installation, the Verify Setup Parameters screen shows the installation parameters. Review the parameters

Figure 2 Selecting Installation Type.

Note that the username and password for the internal database, which is set on the Miscellaneous page, must be the same on both Primary and Failover Brokers.


22 |

to ensure they are correct.To change parameters, restart the installation process with the Previous button.

When installing the Silver Fabric Broker on a Unix system, if the installer shows the fully qualified hostname for the Primary Broker name or uses the machine hostname as the full name, this can cause potential routing problems after installation. Change the hostname of the machine with the Custom install option. Go back to beginning of the installation screens and repeat the installation from Step 2, above, entering the correct DNS-resolvable hostname in the Local Installation screen.

If you are satisfied with the parameter values, click Start Installation to begin installation.

7. Restart the Broker

After Broker installation finishes, you are prompted to shut down the application server. On Windows machines, use the service stop command; in Unix, use the server.sh stop command. Restart the Broker, using the same command used earlier.

8. Create a root user

After restarting the application server, go to http://<yourhost>:<port>/livecluster again. You are prompted to enter a username, password, and password verification. This creates an initial admin user, also called the root user, which is in the cloud account. See the Silver Fabric Cloud Administration Guide for more information on the root user.

Figure 3 Verify Setup Parameters screen.


| 23

After creating the root user, the home page in the Administration Tool appears.

If errors occur during installation, they will be listed in the installation log file located at SF_HOME/webapps/livecluster/WEB-INF/log/install.log.


24 |

Silent Installation

The Broker also has a silent installation mode, which can be used to non-interactively install and configure the Broker for automation purposes. In silent mode, the installer does not prompt for any inputs during installation. Instead, the inputs are read from a response file that is provided as a command-line parameter. The silent installer can be used for new Broker installations, or to upgrade or reinstall Brokers.

The install.silent file is packaged in the root directory of the Silver Fabric distribution. Edit the file with information for your environment before launching the silent installation. The file includes comments that describe the installation properties you can set. You can also specify properties on the command line that you don’t want to put in the properties file (such as passwords).

If errors occur during installation, they will be listed in the installation log file located at SF_HOME/webapps/livecluster/WEB-INF/log/install.log.

To use the silent installer:

1. Perform Copy files before installation on page 17 and Configure server settings on page 17.

2. Using a text editor, open the install.silent file in the root directory of the Silver Fabric distribution and edit the properties for the Broker installation.

By default, the acceptEULA property is set to false. You must set this to true after reading the EULA.txt file in the root directory of the Silver Fabric installation.

3. If you are upgrading an existing Broker, ensure that it is not running.

4. Run the install.sh or install.bat file:

install.sh/bat properties-file [var1=x var2=y ...]

The var1...varx are optional, and enable you to specify properties on the command line instead of in the properties file (such as passwords).

For upgrades performed with the silent installer, database migration will not overwrite existing entries. If you have configured the Broker and added anything to the database, the upgrade will not overwrite the new data from the previous Broker.


| 25

Installing Additional Enablers

By default, Silver Fabric comes with several Enablers installed. You can install additional optional Enablers, available from TIBCO technical support. You can also create your own Enablers using the Enabler SDK. For more information on the Enabler SDK, see “Using the Enabler SDK” in the Silver Fabric Developer’s Guide. For more information on obtaining additional Enablers or creating custom Enablers, please contact TIBCO technical support.

Enablers consist of one or more Grid Libraries, or archives. The Enablers Runtime Grid Library contains information specific to a Silver Fabric version that is used to integrate the Enabler. The Enabler may also require one or more Enabler Distribution Grid Libraries, which contain the application server or program used for the Enabler, or other components.

To install an Enabler, copy the two Grid Library files to the SF_HOME/webapps/livecluster/deploy/resources/gridlib directory. An Enabler includes at least two Grid Libraries, the Runtime and the Distribution. Add the Enabler Distribution first, and then the Enabler Runtime.

Adding files to this directory causes the following to happen:

• If a new Grid Library or an upgrade to an existing Grid Library is added, it is extracted into the deployed directory (SF_HOME/webapps/livecluster/deploy/expanded/domain.)

• You can upgrade active Grid Libraries—those where the respective Component and Enabler are currently running. The updates are detected and affect the running system.

• When Component Types are found in an added Grid Library, they are added to the Component Type repository. New Component Types replace existing

Some Enabler Grid Libraries contain dependencies on other Grid Libraries, which are typically also included with the Enabler. For example, Enabler Runtimes depend on Enabler Distributions. You must install Grid Libraries in the reverse order of dependency. So, if Grid Library A depends on Grid Library B, and Grid Library B depends on Grid Library C, install C, B, then A. Likewise, Enablers should be deleted before their distributions; for the previous example, you would uninstall Grid Library A, B, and C.

This overwrites any changes to the existing Grid Library in the staging directory.


26 |

types. There is no method for automatically removing Component Types that aren’t in a Grid Library.

Installed Enablers are listed in the Silver Fabric Administration Tool on the Stacks > Enablers page. Installed Distributions are also listed on the Stacks > Distributions page.

Deleting Grid LibrariesNever delete active Grid Libraries—those where the respective Component and Enabler are currently running on an Engine.

You can also install Enabler Grid Libraries using the Silver Fabric Command Line Interface. See Chapter 9, The Command Line Interface, on page 129 of the Silver Fabric Developer’s Guide for more details.


| 27

Clustering Configuration

Silver Fabric supports clustered applications when using the Tomcat, JBoss, WebLogic, or WebSphere Enabler, however, additional configuration is required to support it. See the applicable Enabler Guide for instructions.


28 |

Configuration Options

The following configuration options can be made to customize your Broker installation.

Changing the Broker HTTP PortsBy default, component messaging uses HTTP port 8000, and the web-based Administration Tool uses port 8080. The Tomcat server is also configured to use port 8005 for administration/shutdown.

To change any of the HTTP ports:

1. Stop the Broker.

2. In the SF_HOME/conf directory, edit the server.xml file.

3. To change the shutdown port, replace the value of 8005 in the following line:

<Server port="8005" shutdown="SHUTDOWN">

4. To change the port used by the Administration Tool, replace the value of 8080 in the following line:

<Connector port="8080"

5. To change the messaging port, replace the value of 8000 in the following line:

<Connector port="8000"

6. Start the Broker.

7. If this is the first time you’ve installed the Broker, continue the installation normally.

If you are changing the ports on an existing installation, do one of the following:

— Log in to the Administration Tool, go to Admin > Reinstall, and reinstall the Broker.

or

— Edit the SF_HOME/install.silent and use the silent installer to reinstall the Broker. Make sure to specify correct new values for primaryBrokerAdminURL and primaryBrokerMessagingURL. See Silent Installation on page 24 for more information on the silent installer.

If you change the Administration Tool port, you must use the silent installer and not the Administration Tool to perform the Broker upgrade.


| 29

You can verify your changes by opening your browser at the new Web Administration URL on the new port. For example: http://broker:9000


30 |

A Sample Unix rc.d Script

The following is an example of a simple startup script for the Silver Fabric Broker running on a Linux system:

#!/bin/sh# Startup script for Silver Fabric Broker#

# Source function library.. /etc/rc.d/init.d/functions

prog="server"DSBASE=/opt/fabricJAVA_HOME=/usr/local/javaexport JAVA_HOME

case "$1" in start) cd $DSBASE ./server.sh start ;; stop) cd $DSBASE ./server.sh stop ;; restart) cd $DSBASE ./server.sh stop ./server.sh start ;; *) echo $"Usage: $0 {start|stop|restart|condrestart|status}" exit 1

esac

exit 0

After creating the above file, place it in /etc/rc.d/init.d/. Your Linux system does not directly run scripts from this directory. Instead, a different directory within /etc/rc.d corresponds to each runlevel of your system. When your system enters a runlevel (for example, during system startup), each script in that runlevel’s associated directory is run and passed the start or stop parameter.

Instead of creating several identical copies of your script, you can create symbolic links in each runlevel directory. Links beginning with K run the script with the stop parameter; those with S run the start parameter. The number at the start of each link dictate the order in which scripts run.


| 31

The following is an example of the links created when installing the above script. These links start the Silver Fabric Broker at runlevels 3 and 5 and stop it at runlevels 0, 1, and 6:

lrwxrwxrwx 1 root root 18 Apr 8 16:26 /etc/rc.d/rc0.d/K02silverfabric -> ../init.d/dsserverlrwxrwxrwx 1 root root 18 Apr 8 16:27 /etc/rc.d/rc1.d/K02silverfabric -> ../init.d/dsserverlrwxrwxrwx 1 root root 18 Apr 8 16:27 /etc/rc.d/rc3.d/S98silverfabric -> ../init.d/dsserverlrwxrwxrwx 1 root root 18 Apr 8 16:27 /etc/rc.d/rc5.d/S98silverfabric -> ../init.d/dsserverlrwxrwxrwx 1 root root 18 Apr 8 16:27 /etc/rc.d/rc6.d/K02silverfabric -> ../init.d/dsserver


32 |


| 33

Chapter 3 Windows Engine Installation

Silver Fabric Engines are installed using a manual installer that is downloaded from the Administration Tool to a machine. You can also use a network installation to install Engines on many machines, or install the Engine on a Windows Terminal Server for use by multiple PCs.

Topics

• Manual Installation, page 34

• Network Installation, page 35

• Installing Windows Engines in a Non-default Location, page 36

• Engine JRE Synchronization, page 37

• Engine Permissions, page 38

• Running Engines in Console Mode, page 39

• Application Extraction Issues With Windows Engines, page 40

• Engine Configuration and Management, page 41

Custom certificates are supported by network installation only. If a Broker uses a custom cert, it is impossible to install Engines by manual installation.


34 |

Manual Installation

You can manually install an Engine by clicking the Manual Installation link from the Engine Install page.

To manually install Engines:

1. Ensure the Broker is installed correctly and is running.

2. Log in to the Silver Fabric Administration Tool.

3. Go to Engines > Install.

4. Click Manual Installation.

This downloads a file named DSIntranetInstall.exe, which you can either run or save and move to another machine.

5. Run DSIntranetInstall.exe.

6. You are prompted to enter a Broker name. Enter the URL of your Broker, such as http://hostname.example.com:8000.

7. When installation completes, click Finish.

8. After the Engine service starts running, the Engine downloads additional files from the Broker. This can take a minute or two. When downloading completes, the Engine is ready to take work.

Once installed, the Engine activates and logs in to the Broker according to the settings in its Engine Configuration.

Figure 4 Specifying the Broker URL.


| 35

Network Installation

Engines can also be installed onto multiple PCs from a shared drive with a login or update script.

To set up a network installation:

1. Copy the contents of SF_HOME/webapps/livecluster/WEB-INF/engineInstall/win32/network to a shared directory, such as /share/silverfabric.

2. Copy ssl.pem and ssl.keystore from SF_HOME/webapps/livecluster/engineUpdate/shared into that shared directory.

3. In a login or update script include the following:cd /share/silverfabric

install.bat

You can also modify the install.bat file to install Engines in either the system or a user account. install.bat runs the program setup.exe, which can take username arguments.

The setup.exe program takes a username and password argument before other installation arguments. The username argument in the form of DomainName\UserName, or can be .\UserName if the account belongs to the built-in domain.

For example, the following command silent installs the Engine and runs the Engine Daemon service with the account .\dave and the password joshua7, writing a log file to c:\silverfabric.log:

Setup.exe .\dave joshua7 -s -f2c:\silverfabric.log

Note that when running the Windows Engine Daemon service as a user other than Local System, the user account running the DataSynapse Engine service is granted the Logon As a Service (SeTcbLogonService) right by the installer, provided the domain name given does not end with “.”. The user account requires read access to perflib in the registry as mentioned below in “Running Engines in Console Mode”.


36 |

Installing Windows Engines in a Non-default Location

By default, the Windows Engine installer installs Engines at C:\TIBCO\DataSynapse\Engine.

To install an Engine manually or from a network script in another location:

1. Edit the setup.iss file located in the Windows Engine network installer, which is SF_HOME/webapps/livecluster/WEB-INF/engineInstall/win32/network.

2. Change the value of the szDir property to another location.

3. Copy the contents of the directory to the install destination and run install.bat.


| 37

Engine JRE Synchronization

The Engine’s JRE is always kept in synchronization, by default, with its Primary Broker. For example, when the Engine is installed, it downloads a JRE from the Broker with which it was configured. If the Engine is moved to another cloud that has a different JRE, it will synchronize prior to login to that cloud.

There may be certain cases in which you may not want the JRE to automatically synchronize. To disable this, add the line jre=local to the intranet.dat file. This prevents the installer from downloading and unpacking the JRE.

If a primary Broker is not available and an Engine uses a secondary Broker, the JRE will not be updated.

If JRE updating is disabled, it is the responsibility of the user to make sure the JRE is properly deployed on the Engines.


38 |

Engine Permissions

Engines installed by an administrator but run by a non-admin user can have permission issues, especially if the Engine removes a registry key and creates it on an update event. This section contains a list of keys created and used by Engines, to aid you in determining what permissions to set so that Engines function properly.

The following registry keys are used for performance monitoring and require only read access after install:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NetFrameworkHKEY_LOCAL_MACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\0HKEY_DYN_DATA\PerfStats\\StartStatHKEY_DYN_DATA\PerfStats\\StatDataHKEY_DYN_DATA\PerfStats\StopStatHKEY_LOCAL_MACHINE\SOFTWARE\microsoft\windows nt\currentversion\perflib


| 39

Running Engines in Console Mode

You can run Windows Engines in console mode, which lets you see logs interactively as the Engine is running.

To run an Engine from console mode:

1. Open a command prompt in Windows by choosing Start > Run, then entering cmd.

2. Change to the directory containing your Engine installation, usually C:\TIBCO\DataSynapse\Engine.

3. Type engine.exe -console to run the Engine in console mode. The Engine runs, and log information appears in a new console window.


40 |

Application Extraction Issues With Windows Engines

When deploying applications to Windows Engines, there may be cases where an application’s WAR file does not fully extract on the Engine. This is due to a path limit in the Windows OS. When the path of the Engine installation plus the path of the deploy directory plus the length of the classes reaches an arbitrary length, directories and files aren’t written to the Engine.

There are a few workarounds for this issue:

• Change the install location of your Windows Engines. For example, instead of installing in C:\TIBCO\DataSynapse\Engine, install in C:\Engine.

• Shorten the filenames of archives.

• Shorten the application name.

• Use JAR files instead of individual classes in a WAR file.


| 41

Engine Configuration and Management

For more information on configuring and managing installed Engines, see “Engine Configuration and Management” in the Silver Fabric Cloud Administration Guide.


42 |


| 43

Chapter 4 Unix Engine Installation

To install Engines on Unix systems, you must download and install an Engine on each system, and run a configure script. The script creates a profile on the Broker that you can use for other Engines, or you can use an existing profile on the Broker.

Topics

• Installing the Engine, page 44

• Running the Engine, page 45

• Engine JRE Synchronization, page 47

• Engine Configuration and Management, page 48


44 |

Installing the Engine

The TIBCO Silver® Fabric Unix Engine is packaged as a gzip-compressed tar archive. The Engine installation process installs the files on the Unix system, creates or uses a profile on the Broker, and associates the Engine with that profile.

To install an Engine:

1. Download the installation to a Unix machine from the Engines > Install page in the Silver Fabric Administration Tool.

2. Unpack the archive to the directory of your choice. For example, the following extracts the tar file into the directory /usr/local/DSEngine:

cd /usr/local

gzip -d -c DSEngineLinux.tar.gz | tar xvf –

3. Run the configure.sh script located in the directory in which you unpacked the archive. Run the script only once, not once per Engine.

The configure.sh arguments are summarized below:

Solaris systems that run Engines require GNU tar to be installed.

Switch Argument Description

-s Broker:port The domain name or IP address for the Broker, and HTTP(S) port.

-P profiles_dir Optional target directory for host-specific directories for native code logging and configuration info to be created. The default value is ./profiles

-l y|n If the Broker port uses HTTPS.


| 45

Running the Engine

The engine.sh script follows the standard start/stop argument convention for system initialization scripts (“rc scripts”), so you can incorporate it in the start-up and shutdown sequence by inserting appropriate links in the /etc/rc.d files.

The engine.sh arguments are summarized below:

The following is an example of a simple startup script for the Silver Fabric Engine running on a Linux system:

!/bin/sh# Startup script for Silver Fabric Engine#DSBASE=/opt/DSEngineJAVA_HOME=/opt/j2sdk1.6.0_0export JAVA_HOMEcase "$1" in

start)cd $DSBASE./engine.sh start;;

stop)cd $DSBASE./engine.sh stop;;

restart)cd $DSBASE./engine.sh stop./engine.sh start;;

*)echo $"Usage: $0{start\|stop\|restart}"exit 1

esacexit 0

Switch Argument Description

start n/a Starts the Engine.

stop n/a Stops the Engine.

startfg n/a Starts the Engine, and runs it in the foreground. Useful for monitoring or debugging purposes.


46 |

If a machine is installed without a default route, the Unix Engine returns 0.0.0.0 as the IP address, which causes communication issues with the Broker. You must ensure that a default route is set for Engines to operate properly. See 4) Configure Your Network in Chapter 1, Installation Overview, on page 1 for more information on properly configuring your network.


| 47

Engine JRE Synchronization

The Engine’s JRE is always kept in synchronization, by default, with its Primary Broker. For example, when the Engine is installed, it downloads a JRE from the Broker with which it was configured. If the Engine is moved to another cloud that has a different JRE, it will synchronize prior to login to that cloud.

There may be certain cases in which you may not want the JRE to automatically synchronize. To disable this, add the line jre=local to the intranet.dat file. This prevents the installer from downloading and unpacking the JRE.

If a primary Broker is not available and an Engine uses a secondary Broker, the JRE will not be updated.

If JRE updating is disabled, it is the responsibility of the user to make sure the JRE is properly deployed on the Engines.


48 |

Engine Configuration and Management

For more information on configuring and managing Engines you have installed, see “Engine Configuration and Management” in the Silver Fabric Cloud Administration Guide.


| 49

Chapter 5 VirtualRouter Installation

A Client is a component that connects to the Broker and utilizes Components. In particular, a web browser or HTTP client connects to a VirtualRouter instance, which forwards requests to an Engine running the Component that matches the request. This chapter contains information on installing VirtualRouter.

Topics

• Overview, page 50

• Installing VirtualRouter, page 51

• Configuring VirtualRouter, page 52

• Using VirtualRouter, page 55

• VirtualRouter Authentication, page 56


50 |

Overview

VirtualRouter is a client that logs into the Broker. It receives notifications when Engines activate or deactivate HTTP enabled Components and keeps a map of the current state of the cloud. When VirtualRouter receives requests, it identifies the Component to which that request belongs based on the context root, and forwards it to an Engine running that Component.

By default, an embedded instance of VirtualRouter runs on the Broker. The number of simultaneous requests it can handle is controlled by the number of threads available in the application server running Silver Fabric. You can run additional instances of VirtualRouter externally, on other application servers. This provides greater overall performance, as VirtualRouter can handle greater loads without affecting general Broker performance. It also provides greater system stability in the event of a Broker failure, as VirtualRouter continues to function with its last known state. Multiple VirtualRouters may be run for redundancy and load sharing. They can also be partitioned such that some VirtualRouters only forward to a certain set of Components and other VirtualRouters to other Components.

You can also run multiple VirtualRouters in a cluster to get sticky session mapping replication. See “Storing Sticky Session Mappings” in the Silver Fabric Cloud Administration Guide.


| 51

Installing VirtualRouter

VirtualRouter is packaged as a WAR archive, and included with Silver Fabric.

To install VirtualRouter:

1. Install an application server (such as Tomcat, WebLogic, or JBoss) on the target machine.

2. Download the server-specific WAR file in the Silver Fabric Administration Tool at Admin > Downloads.

3. Install the archive on your application server. See your application server’s documentation for instructions.


52 |

Configuring VirtualRouter

The virtualrouter.properties FileVirtualRouter is configured by a properties file within the web application located at WEB-INF/config/virtualrouter.properties. By default, the virtualrouter.properties file is configured to point to the Broker from which the WAR file was downloaded. You can configure another Broker, the username and password, and logging options in the virtualrouter.properties file. You may also configure a partition name to have the VirtualRouter only forward requests to certain Components. For more information on VirtualRouter partitioning, see the Silver Fabric Cloud Administration Guide.

Some application servers extract the VirtualRouter WAR file in the server's deploy directory, where you can find and edit the virtualrouter.properties file. If your application server does not, you must extract the WAR file, modify the virtualrouter.properties file, then rearchive it.

VirtualRouter Settings on the BrokerSome VirtualRouter settings are stored on the Silver Fabric Broker, and are retrieved when the VirtualRouter logs in. These settings are located on the Config > Broker > General page.

Changes to the VirtualRouter settings on this page only take effect after new VirtualRouter logins. To have VirtualRouter update its settings immediately, use the Disconnect VirtualRouter action on the Admin > VirtualRouter page so that VirtualRouter will re-login and get the updated settings.

Configuring the Application ServerYou can configure your application server to define VirtualRouter behavior. For example, if you are using Tomcat, you can edit the server.xml file and change the HTTP port to another value.

However, you must configure VirtualRouter to run with the Root (/) context of the application server. The download for WebLogic is preconfigured to run this way by default. To do this for Tomcat or JBoss, follow the instructions below.


| 53

JBossJBoss ships with a web application (ROOT.war) defined to run with the root (/) context. This needs to be deleted or renamed so it will not conflict with the VirtualRouterJBoss.war web application.

To do this for JBoss 5.1 and 6.1, delete or rename the server/all/deploy/ROOT.war directory from your JBoss install (if running VirtualRouter on an external JBoss server) or JBoss distribution Grid Library (if running VirtualRouter on the JBoss Enabler).

To do this for JBoss 7.1, edit the standalone/configuration/standalone-full.xml and standalone/configuration/standalone-full-ha.xml files to change the enable-welcome-root attribute of the default-virtual-server for the urn:jboss:domain:web subsystem to false.

Tomcat

Option 1:

1. Delete the webapps/ROOT directory.

2. Rename VirtualRouterTomcat.war to ROOT.war and copy it to the webapps directory.

Option 2:

1. Delete the webapps/ROOT directory.

2. Copy VirtualRouterTomcat.war to the webapps directory.

3. Modify conf/server.xml to make the following changes:

— Under the <Host> tag, add the following: <Context path="" docBase="VirtualRouterTomcat"/>

— In the <Host> tag, set the attribute autoDeploy="false" and add deployOnStartup="false". This prevents the VirtualRouter application from being initialized twice.

Option 3 (only for running on the Tomcat Enabler for Silver Fabric):

1. Create a J2EE Component that uses the Tomcat Enabler and deploy the VirtualRouterTomcat.war normally as an archive.


54 |

2. On the Add/override/edit Enabler and Component-specific runtime context variables page, click Add From Enabler and select the ROOT_CONTEXT_WEBAPP variable.

3. Edit the value of the ROOT_CONTEXT_WEBAPP variable to be VirtualRouterTomcat.war.

4. Click Add From Enabler and select the SESSION_COOKIE_NAME variable.

5. Edit the value of the SESSION_COOKIE_NAME to be the desired cookie name for VirtualRouter to use to store session mapping information. This should be chosen so that it does not conflict with other cookie names that will be used by application servers to which VirtualRouter will be forwarding requests. See the VirtualRouter Session Handling section in the Cloud Administration Guide for more information.

6. Click Finish.

Verifying Your VirtualRouter InstallationOnce your VirtualRouter is up and running, you can verify a successful installation by accessing the Admin > VirtualRouter page in the Silver Fabric Administration Tool. If the VirtualRouter is running and logged into the Broker, you will see an entry for the VirtualRouter in the table. Note that by default, the embedded VirtualRouter that runs along with the Broker will also be visible.

You can also access the status page for the VirtualRouter by selecting the VirtualRouter Status action next to the appropriate entry. This links to the status page served up directly by the VirtualRouter. This page contains useful information about the current state of the running VirtualRouter, including which Components and Engines are currently in the routing table, and the number of active sessions associated with each.


| 55

Using VirtualRouter

After installation, VirtualRouter runs on the port specified by your application server. For example, when running VirtualRouter at http://example:8000, a web browser connecting at http://example:8000/MyApp is forwarded to an Engine running the Component corresponding to the relative URL /MyApp. In scenarios where multiple VirtualRouters are used, it's possible to consolidate connections to multiple VirtualRouter instances using an external software or hardware load balancing solution.


56 |

VirtualRouter Authentication

VirtualRouter authentication is disabled by default. To enable authentication, in Config > Broker > Engines and Clients, change Client Authentication Enabled to true, and enter a valid Silver Fabric username and password in all virtualrouter.properties files.

User access to the VirtualRouter status page (/control/status.jsp) from a web browser can also optionally be authenticated by setting DSAuthenticationWebAccess=true in the virtualrouter.properties file. By default this is set to false.


| 57

Chapter 6 Verifying your Installation

After installing a Silver Fabric Broker and one or more Engines, you can test your installation by using the VirtualRouter Status page.

Topics

• Using the VirtualRouter Status Page, page 58


58 |

Using the VirtualRouter Status Page

To test your installation:

1. In the Silver Fabric Administration Tool go to Stacks > Stacks.

2. Select Run Stack in Manual Mode from the Actions list of the Example Stack.

3. Go to Admin > VirtualRouter. The VirtualRouter page contains a table for each VirtualRouter client that is currently running. Select the VirtualRouter Properties action next to each client to show the Component each host is running.

Figure 5 Activating the Example Stack.


| 59

4. When you find the client running your Component, select the Status Page action. The VirtualRouter Status page is shown:

5. In the Relative URLs column, entries for each web application (such as the HelloWorld and JSPWiki web applications in the example Component) are listed. Click a URL to connect to the web application.

Figure 6 Viewing the VirtualRouter status page.


60 |


| 61

Chapter 7 Uninstalling Silver Fabric

This chapter explains how to uninstall Silver Fabric. The Engine and Broker uninstalls are separate procedures as explained below, for Windows and Unix operating systems.

Topics

• Uninstalling Silver Fabric on Windows Systems, page 62

• Uninstalling Silver Fabric on Unix Systems on page 64

• Uninstalling Enablers on page 65


62 |

Uninstalling Silver Fabric on Windows Systems

Uninstalling an EngineTo uninstall an Engine on a Windows system:

1. If you’ve previously engaged the Engine manually, right-click the Engine icon in the Task Tray and select Stop. The Engine Icon turns red. Then right-click the red Engine icon and select Exit.

If the Engine is running as a service, open the Computer Management tool (%windir%\system32\compmgmt.msc /s) and under Services and Applications, choose Services and stop the Datasynapse Engine service. You can also run sc stop datasynapse or net stop datasynapse from an elevated command prompt.

2. In Windows, select Start > Control Panel > Add/Remove Programs. Remove the DataSynapse Engine. Follow the onscreen instructions through the uninstall.

When the uninstall finishes, delete the remaining Engine directories from your disk. (The default location for these files is C:\TIBCO\DataSynapse\Engine.)

Manual UninstallYou can remove Engines using silent installation scripts similar to those described in Network Installation on page 35. However, instead of the install.bat script, use the uninstall.bat script.

To uninstall an Engine manually:

1. Change directories to the shared network installation directory containing the uninstall.bat. If this directory no longer exists, you can re-copy the contents of SF_HOME/webapps/livecluster/WEB-INF/engineInstall/win32/network to a shared directory.

2. Stop the Engine. To script this, write a batch file that contains the command net stop "DataSynapse Engine" before the uninstall command.

3. Run uninstall.bat from the shared network installation directory.

Uninstalling a BrokerTo uninstall a Broker with on a Windows system:


| 63

1. If the Broker is installed as a Service, select Start > Control Panel > Administrative Tools > Services.

2. Click DataSynapse Silver Fabric Broker and click the Stop icon to stop the application.

3. Open a command line, go to the Silver Fabric Broker root directory, and issue a service remove name command to uninstall the Server named name. Omit name if you did not name your Broker during installation.

4. In the SF_HOME/webapps directory, remove the livecluster directory and its contents. You can also remove the entire SF_HOME directory containing Silver Fabric and the application server.

Figure 7 Stopping a Broker installed as a Windows Service.


64 |

Uninstalling Silver Fabric on Unix Systems

To remove a Silver Fabric Broker or Engines on a Unix system:

1. Stop the Engine or the Broker (engine.sh stop or server.sh stop).

2. Remove any modifications you made to startup files, typically located in /etc/rc.d directories.

3. Remove all files in the installation directory.


| 65

Uninstalling Enablers

Enablers can be uninstalled by removing the relevant Grid Libraries from the Broker. This is best accomplished using the Command Line Interface or REST Services.

Using The Command Line Interface

The Command Line Interface can be used to remove an Enabler’s Grid Libraries.

To uninstall an Enabler:

1. Unpublish and remove all Stacks and Components that use the Enabler.

2. List all of the Grid Libraries on the Broker to determine the name and version of the Grid Libraries you want to uninstall:

listGridlibs

3. Remove each Grid Library in the reverse order in which it was installed. This means you typically would remove the JDK (provided it’s not being used by other Enablers), then the Enabler Runtime, then the distribution. See your Enabler’s relevant guide for the installation order. For example:

removeGridlib j2sdk-win64 1.6.0.23

removeGridlib jboss5_1-container 5.0.0.63

removeGridlib jboss5_1-distribution 5.0.0.63

Using REST Services

REST Services can also be used. As shown above, you must first unpublish and remove any dependent Stacks and Components, and remove Grid Libraries in the reverse order of installation.

The following is the resource used with the DELETE method to delete a Grid Library:

gridlibs/{gridlibrary-name}/version/{gridlibrary-version}/os/{gridlibrary-os}

Do not uninstall Enablers by manually removing Grid Libraries from the Broker or Engines.


66 |


| 67

Chapter 8 Upgrading Silver Fabric

This chapter explains how to upgrade Silver Fabric. It contains a Silver Fabric Upgrade Checklist, which explains what to do before, during, and after your new Silver Fabric installation when migrating from a previous version of FabricServer. Also described are any changes in requirements for running this version of Silver Fabric, and a list of API changes between this version and earlier versions.

Topics

• Upgrading From Previous Versions, page 68

• Silver Fabric Upgrade Checklist, page 69

• Installing Hotfixes, page 71

• Engine Upgrade, page 76

• VirtualRouter Upgrade, page 77

• PCM and Skyway Upgrade, page 78

• Silver Fabric 5.7 Changes, page 79



• Silver Fabric 5.0 SP1 Changes, page 84

• Silver Fabric 5.0 Changes on page 85

• Enabler Changes, page 88


68 |

Upgrading From Previous Versions

Software from TIBCO uses three (or sometimes four) numbers to indicate whether the release is major, minor, a patch, or a hotfix. For example, 5.0.0 indicates a major release, 5.5.0 indicates a minor release and 5.5.2 indicates a service pack release. 5.5.2 HF-1 refers to a hotfix.

When upgrading to a new major, minor, or service pack release, follow the steps beginning with Silver Fabric Upgrade Checklist on page 69 to install a new Broker and migrate the information from your prior installation.

When upgrading to a new hotfix, the hotfix is a JAR archive that is run, which is applied to the current Broker installation. Hotfixes are cumulative. Typically a service pack can also be applied with a JAR archive by following the hotfix instructions. To apply a hotfix, follow the steps at Installing Hotfixes on page 71.

Supported Upgrade VersionsSilver Fabric can be upgraded from version 4.1 or 5.0 to version 5.5. Upgrade to Silver Fabric from versions of Silver Fabric earlier than 4.1 is not supported.

Hotfixes are specific to a major, minor, and patch level of Silver Fabric. You must have already upgraded to that version to apply a hotfix.

Requirements ChangesPlease see the system requirements in the included Readme file to ensure that your software and hardware meet the minimum system requirements.


| 69

Silver Fabric Upgrade Checklist

You can migrate settings from your previous version of Silver Fabric to your new version of a Silver Fabric installation, but it’s important to not install over of your previous installation. Instead, shut down your old Broker, rename the old installation directory, then install the newer version of Silver Fabric in the original location. Later during installation, you are prompted for a path to the renamed old installation so Silver Fabric can copy the earlier settings. Instead of renaming your install directory, you could also install your new version of Silver Fabric in a directory with a different name, and migrate your old settings to the new one.

Broker configuration values, such as backlog, log level, and timeout seconds do not migrate to the new version during a Broker upgrade. However, installation generates an upgrade.log that lists all changed configuration values so that you can restore your settings.

Broker upgrade can also be performed using the silent installer. See Silent Installation on page 24 for more information.

Task A After Stopping the Broker

— Rename your Broker directory if you plan on installing the new version of Silver Fabric in the same location as the earlier version. Do not install a new version of Silver Fabric over an existing installation.

— If you are running Silver Fabric as a Windows service, you should remove the service prior to upgrading.

Task B During Installation

— For Installation Type, choose Custom, Broker Upgrade.

— Under Previous Base Directory, enter the livecluster directory of your previous installation, such as /fabric.last/webapps/livecluster.

— You must generate the server.keystore file before installing an SSL server. See the Silver Fabric Cloud Administration Guide for more details on setting up SSL.

— Note that Engines keep running Components during upgrade. Engines do not upgrade their resources or restart until instructed to do so.

Task C After Installation

— Check the upgrade.log file in the livecluster/WEB-INF/log directory. Any changes to the defaults in the prior version are logged. All values are


70 |

restored to default on an upgrade, so you may want to restore these settings.

— To upgrade an external reporting database schema from a previous version of Silver Fabric, run the upgradedb.sh or upgradedb.bat script located in SF_HOME/webapps/livecluster/WEB-INF/etc/db.

— Once you have upgraded a Primary Broker, you must upgrade its Failover Broker as well. (A non-upgraded Failover Broker will not be able to login to an upgraded Primary Broker.)

While the Primary Broker is down, the Engines will report to the Failover Broker and continue running Components. They will stay there, even when the upgraded Primary Broker is started. At this point, you should shut down the Failover Broker to upgrade it. When the Failover Broker is shut down, the Engines will fail back to the Primary Broker, and continue running Components, while Engine Daemons turn red on the Engines > Daemons page, indicating manual upgrade is necessary.

See Broker Upgrade and Engine Restarts, page 72 for more information.


| 71

Installing Hotfixes

Installation To install a hotfix on your Broker machines:

1. Shut down the Silver Fabric Brokers that will be updated.

2. Run the JAR archive. The syntax for running the JAR is:java -jar hotfix_file.jar SF_HOME/webapps/livecluster.

The JAR also supports the following options:

--ignore-platforms

Specifies a comma-separated list of platforms to exclude. For example: win32,win64.

--batch

Batch mode, install without prompting to continue.

All files that are changed will be saved in SF_HOME/webapps/livecluster/WEB-INF/uninstall/ORIGINAL_VERSION

Engines require manual upgrade after a hotfix is installed, as they do after an upgrade. Note that in situations where a new Broker is installed and then a hotfix is applied, new Engines will also require an upgrade. This can be prevented by installing the hotfix with the flag --manual-engine-upgrade-disabled.

UninstallationTo remove a hotfix:

1. Restore all directory hierarchies from SF_HOME/webapps/livecluster/WEB-INF/uninstall/ORIGINAL_VERSION to SF_HOME/webapps/livecluster. ORIGINAL_VERSION refers to the version you are attempting to restore.

2. Remove the file SF_HOME/webapps/livecluster/WEB-INF/config/update.HOTFIX_VERSION.properties. HOTFIX_VERSION refers to the build version of this Hotfix.


72 |

Broker Upgrade and Engine Restarts

With a fault-tolerant setup of a Primary and Failover Broker, the upgrade procedure is to take the Primary Broker down, update it, bring it back online, and then immediately take the Failover down to trigger all the Engines to re-connect to the Primary. If this is done and the time to get all the Engines to re-attach to the Broker is less than the Failover Wait Interval then no Components should be re-allocated and no Engines restarted. It is important to note that before you do this, the Broker admin setting for Director, Broker and Client version mismatch should be set to False and Engine version mismatch must be set to True.

It is absolutely crucial to make the Failover Wait Interval and the Initial Wait Period long enough to accommodate the time it takes for Engines to get logged into the Primary or Failover Broker. The more Engines you have and the slower or more unreliable your network is, the longer those times need to be to make sure that all the Engines (especially Engines currently running Components) have time enough to get logged into the Broker before the interval expires. Once the interval expires, the Broker will do its best to apply the current set of policies to the current set of resources. If all Engines have logged in and the current set of policies has not changed since the Broker was taken down or at the very least the current set of policies does not result in an allocation map that would exceed available resources, then everything should be fine and no Engines should restart except those in which the current policy calls for their Components to be deactivated and the Component/Enabler calls for an Engine to restart on deactivation.

Engines that restart on deactivation will update themselves when they re-login to the Broker. This is the same behavior you would see if you if manually stopped and started an Engine that had previously been marked for manual update.

If when the Failover Wait Interval or Initial Wait Period expires and there are not currently enough free (unallocated) Engines available to adequately service the current policy, the Silver Fabric allocation algorithm will make the best of a bad situation and attempt to optimize the allocation of Components across the current set of Engines, which most likely will result in currently activated Components being stopped to make room for others (arguably making the situation worse.) This is a bad state that you do not ever want to get into since it will likely result in most if not all of your Components being moved around to different Engines over the course of a few hours. If this ever happens, your best bet is to disable the allocator until everything settles down and you have enough free Engines on hand to take the remaining activations.


| 73

Disabling AllocationAn additional precaution to prevent Component restarts on update is to disable the allocator before taking the primary Broker down (this needs to be done on the failover as well.) This will prevent any reallocation of Components and Engines until it is re-enabled. If you do this, you can take the Primary Broker down, upgrade it, and bring it back up while the Components continue to run on their respective Engines. Then when you are sure that all of your Engines have reconnected to the Primary Broker, you can re-enable allocation and allow the Broker to function normally. It is important to note that prior to taking the Primary Broker down, you should make sure that all Components currently in an activating or deactivating state are allowed to complete, as this will ensure that the Broker is in a known stable state before you begin.

Disabling allocation is not a substitute for correctly setting the Failover Wait Interval and Initial Wait Period, because if Engines with running Components login after the interval has expired they will be deactivated for being out of policy once the allocator is re-enabled. The log message INFO: [Allocation] Reconstructed allocation map of n components, n Engines, and n

Clients is written at the end of the interval (where n is the number it finds in your environment) and tells you how many active Components there are and how many Engines it thinks it has. If those numbers, especially the Engines, don’t correspond to what you expected then you should increase the Failover Wait Interval and stop and restart the Broker.

Upgrading a Failover Pair1. Lock the Broker to prevent other users from making changes while you

upgrade. In the upper right corner of the Administration Tool, click Lock.

2. On the primary and failover Broker, at Config > Broker > Admin > Version Management, make sure that the Allow Engine Version Mismatch is set to true and that Allow Director Version Mismatch, Allow Broker Version Mismatch, and Allow Client Version Mismatch are all set to false.

3. On the primary and failover Broker, at Config > Broker > General > Allocation, make sure that the Failover Wait Interval and Initial Wait Period are set to values large enough to accommodate the number of Engines you have. Setting each to an hour is not out of the question just to be on the safe side. Since the values are entered in seconds an hour is 3600. Be advised this means that while running Components will be available for the duration, the ability to start and stop Stacks will be suspended for an hour.

4. As an extra precaution and to prevent others from making changes to the environment that you are unaware of, disable the allocator (set Config > Broker > General > Allocation > Allocation Disabled to true) and then wait


74 |

until all activations and deactivations are completed before proceeding. This must be done on both the primary and failover Broker.

5. Shut down the primary Broker.

6. Upgrade the primary Broker.

7. Wait until all Engines have connected to the failover Broker (longer than the interval set above in step 3.)

8. Start the primary Broker.

9. Shut down the failover Broker (do this soon after starting the primary Broker; don’t wait more than 5 minutes as we want to make the most of the configured wait time.)

10. Wait until all Engines have connected to the primary Broker and the environment appears stable (at least one hour.)

11. Upgrade the failover Broker.

12. Start the failover Broker.

13. Once the failover Broker is up and functioning normally re-enable allocation on the primary Broker and the failover Broker.

14. Unlock the Broker by clicking Unlock in the upper right corner of the Administration Tool.

Standalone Broker ConfigurationA standalone Broker upgrade is similar to a fault-tolerant pair and it is crucial to have values for Failover Wait Interval and Initial Wait Period long enough that all the Engines are able to log in to the Broker with running Components before the Broker attempts to allocate whatever is missing from the current policy. Once the Broker starts allocating, if there are not enough resources, already activated Components will likely get shuffled around leading to a lot of Component restarts. Also Engines that login after the interval are considered out of policy and will be deactivated.

As in the failover case, the best way to avoid unintended Component restarts is to disable the allocator for the period in which the Broker is down and until all the Engines have reconnected. That way, when the allocator is re-enabled and attempts to apply the current policy, it will have enough Engines and in theory have nothing to do since all the Components should have already been activated prior to beginning the upgrade process. As was stated above if you notice Engines logging in after the Failover Wait Interval expires with running components, increase the Failover Wait Interval and restart the Broker and do not enabler the allocator until all Engines with active components can login before the interval expires.


| 75

Standalone Step By Step

1. Lock the Broker to prevent other users from making changes while you upgrade. In the upper right corner of the Administration Tool, click Lock.

2. On the Broker, at Config > Broker > Admin > Version Management, make sure that the Allow Engine Version Mismatch is set to true and that Allow Director Version Mismatch, Allow Broker Version Mismatch, and Allow Client Version Mismatch are all set to false.

3. On the Broker, at Config > Broker > General > Allocation, make sure that the Failover Wait Interval and Initial Wait Period are set to values large enough to accommodate the number of Engines you have. Setting each to an hour is not out of the question just to be on the safe side. Since the values are entered in seconds an hour is 3600. Be advised this means that while running Components will be available for the duration, the ability to start and stop Stacks will be suspended for an hour.

4. As an extra precaution and to prevent others making changes to the environment that you are unaware of, disable the allocator (set Config > Broker > General > Allocation > Allocation Disabled to true) and then wait until all activations and deactivations are completed before proceeding.

5. Shut down the Broker.

6. Upgrade the Broker.

7. Start the Broker.

8. Wait until all Engines have connected to the Broker and the environment appears stable (at least one hour) and re-enable allocation.

9. Unlock the Broker by clicking Unlock in the upper right corner of the Administration Tool.


76 |

Engine Upgrade

Silver Fabric Engines do not automatically upgrade themselves. You must manually upgrade Engines from the Engines > Daemons page.

If there are multiple Unix Engines running from the same shared directory, the Engines do not auto-update to the latest version. You must manually install the new Engine once into the shared installation directory, which causes all Engines to run the latest version.

GridServer Engines that migrate to Silver Fabric will automatically update to the 1.8 JRE if they use a different version JRE, but won’t update back to the previous version if the Engine migrates back to GridServer. In order to keep a previous version of the JRE on Engines, you must run a subset of Engines to use that JRE and disable automatic upgrade. See the "Updating Engine JREs" section of the Silver Fabric Cloud Administration Guide for details.


| 77

VirtualRouter Upgrade

Make sure you upgrade all VirtualRouter Clients by replacing the old web archive with the new one and restarting the application server. See your application server documentation for more information.

You can download the new version of VirtualRouter in the Silver Fabric Administration Tool.


78 |

PCM and Skyway Upgrade

In Silver Fabric 5.0, the Private Cloud Manager (PCM) was replaced with Skyway. Skyway enables users to easily control provisioning of Stacks to the Silver Fabric Broker. Skyway users can capture Stacks from a running Broker to create templates that other users can use to develop and provision new Stacks.

There is no upgrade path for existing PCM installations to Skyway.

There are a number of key differences between PCM and Skyway:

• Skyway is automatically installed at the same time as the Broker. It does not run in a separate Tomcat instance, and does not require its own database.

• With PCM, a PCM instance interacted with multiple Brokers in your cloud. Skyway only interacts with the Broker with which it is installed.

• Skyway uses the Broker for user authentication method. It does not require the administration and maintenance of its own users.

• Instead of using its own system of Templates and Images, Skyway uses the Stacks that already exist on the Broker. Administrators can edit Stacks and designate them as Templates for provisioning by Skyway users.

• Skyway does not include functionality for moving Stacks from one Broker to another (referred to as "promotion" in PCM). To do this with Skyway, export the Stack to be moved from its current Skyway instance and, in another Skyway instance, import the resulting ZIP archive.

• Skyway is intended to allow users to provision Stacks for themselves. As a result, it does not include the "ticketing" aspect of PCM. If you prefer an approach in which users submit tickets regarding provisioning activities and administrators perform or reject those tickets, you will need to use a third-party workflow system.

For more information on using Skyway, see the Skyway User’s Guide. For more information on managing Templates for Skyway users, see the Cloud Administration Guide.


| 79

Silver Fabric 5.7 Changes

The following have been changed in Silver Fabric 5.7:

Requirements Changes• SLES 10 is no longer supported.

• VMware vSphere/vCenter 4.x is no longer supported.

• Internet Explorer 8 and Safari 5 are no longer supported.

• Running Brokers on all 32-bit Linux platforms is deprecated.

Other Changes• SOAP Admin API Web Services are deprecated.

• Strict validation of deployed archive names is now disabled by default.

• Windows Engines are now installed in the C:\TIBCO\DataSynapse\Engine directory by default.

• Asset Manager scripts are now loaded once, at Broker start. They were previously loaded on Asset Manager invocation. If there is an error or a change is made in a script, it will not be reloaded, and a Broker restart is required to load changes.


80 |



API• The ArchiveLocator class has been changed to allow arbitrary URL strings to

be specified instead of exclusively using the java.net.URL class. In particular, setURL() and getURL() have been changed to set the URL string and return the URL string instead.

Requirements Changes• AIX and IBM Power platforms are no longer supported.

• All versions of Windows XP are no longer supported.

• VMWare Asset Managers on Windows 2003 are no longer supported.

Other Changes• The J2EE Example Component now uses the 5.6 version of the Tomcat 6

Enabler. Previous versions of Silver Fabric that install with the JAR archive will need to upgrade the example to the newer Enabler using the Change Enabler action on the Components page.


| 81



API• Archive management APIs have changed as follows:

— In the AbstractContainer interface, the deployArchive(), deployFileArchive(), and undeployArchive() methods are deprecated. The same methods can now be found in the ArchiveManagement interface. The detectArchives() method is also now declared in the ArchiveManagement interface.

— The ArchiveScaling interface is deprecated. Use the ArchiveManagement interface instead.

— The ArchiveFeatureInfo and FileArchiveFeatureInfo classes are deprecated. Use the ArchiveManagementFeatureInfo class instead.

— The default behavior for archives uploaded to the ArchiveFeatureInfo object was to copy the files to the location specified by ${J2EE_ARCHIVE_DEPLOY_DIRECTORY}. For ArchiveManagementFeatureInfo, this will not happen by default. You can implement the archiveDeploy() or archiveStart() methods to do this with the utility method ContainerUtils.copyFile(File, File). For the exact behavior as before, you should pass the second argument as the value of ${J2EE_ARCHIVE_DEPLOY_DIRECTORY}.

— Similarly, the default behavior for archives uploaded to the FileArchiveFeatureInfo object was to extract the files to the location specified by ${FILE_ARCHIVE_DEPLOY_DIRECTORY}. For ArchiveManagementFeatureInfo, this will not happen by default but you can implement the archiveDeploy() or archiveStart() methods to do this with the utility method ContainerUtils.extractFileTo(File, File). For the exact behavior as before, you should pass the second argument as the value of ${FILE_ARCHIVE_DEPLOY_DIRECTORY}.


82 |

Scripting• Archive management APIs have changed, similar to the above Java API

changes. The following have been deprecated:

— def deployArchive(archive, deploymentRoot)

— def deployFileArchive(archive, deploymentRoot)

— def scaleArchiveUp(name)

— def scaleArchiveDown(name, id)

— def undeployArchive(archive, deploymentRoot)

Requirements Changes• Windows 2003 Server is no longer supported.

• Linux Red Hat Enterprise Linux 4 is no longer supported.

• Solaris Sparc 9 is no longer supported.

• JDK 1.6 is supported as a Grid Library for Enablers, but is no longer supported for Brokers and Engines.

• The default JDK is now JDK 1.7. You may need to either upgrade Enablers to support JDK 1.7 or deploy JDK 1.6 to continue using it.

• Oracle 10g and Microsoft SQL 2005 are no longer supported reporting databases.

Other Changes• The Tomcat option ALLOW_ENCODED_SLASH is now set to true for the Broker.

This is done to enable the ad hoc Stack name "N/A" to be used. Note that this option is typically set to false for public-facing instances of Tomcat, because slashes could lead to a potential exploit. To change this option, edit the Broker’s server.sh or server.bat file.

• The Elliptical Curve Cryptography libraries are no longer included in the shipped Engine JREs and JDKs. If it is required for your application, you must either copy Sun’s sunec.dll or libsunec.so file in the JRE, or package a new JRE that includes it.

• When upgrading from Silver Fabric 4.1, the example Application and its Components are not copied during upgrade. This includes j2ee-example-gridlib.zip, commandline-example-database-gridlib.zip and


| 83

application_example_application.xml. Use the example provided in Silver Fabric 5.5 instead.


84 |

Silver Fabric 5.0 SP1 Changes

The following have been changed in Silver Fabric 5.0 SP1.

• Upgrading from Silver Fabric 4.0 to 5.0 will now copy any LDAP groups found in roles into the cloud account, so that LDAP users are able to log in after upgrade. This will also provide all LDAP users access to all objects.


| 85


The following have been changed in Silver Fabric 5.0.

PCM and SkywayThe Private Cloud Manager (PCM) has been replaced with Skyway. Skyway is installed by default on all Brokers.

For more information on changes with Skyway, see PCM and Skyway Upgrade on page 78.

Terminology ChangesThe terminology used to name objects in Silver Fabric has changed. The following objects have been renamed:

Names in the Silver Fabric SDK have not been changed, to preserve backward compatibility. For example, the Container interface is used to implement Enablers.

The Admin API has new classes to reflect the name changes, and the old classes remain and are deprecated. For example, there is a ComponentAdmin class, and the ApplicationComponentAdmin class is deprecated.

In the Command-Line interface, commands containing terms that have changed have been renamed.

Because of the terminology changes, Administration Tool table personalization information will be lost for Components, Stacks, and Enablers.

Table 5 Terminology Changes

Old Term New Term

Container Enabler

Application Stack

Application Component Component

Template Baseline

Deploy/Undeploy Publish/Unpublish

Silver Fabric Container SDK Silver Fabric SDK


86 |

Other Changes• Non-recurring Schedule intervals now have a start and end date. Previously,

they started and ended according to the Schedule’s range. If you have pre-existing non-recurring intervals and you do not edit them, they will continue to behave as they did prior to upgrade. If you edit them, you must set a start and end date. If you edit them and do not set a start and end date, 1. the start/end date will be that of the Schedule if it has a set start/end date; 2. the end date uses either the later of Schedule’s start date or the current date if there is no end date set and the interval hasn't crossed midnight; 3. the end date will advance a day into the future if there is no end date set and the interval has crossed midnight. If you want to replicate the original behavior, you can use a daily interval that recurs every day, or you can keep the interval as non-recurring and set the end date in the far future.

• If you use the SOAP ScheduleAdmin.updateSchedule() method to update an existing schedule, and if that schedule, prior to the update, had a non-recurring interval whose non-recurrence had a (new) start date and end date, after the update, that interval will lose its start date and end date, because you won't be able to supply them in the ScheduleInfo argument to the updateSchedule() method.

• The installation archive is now in a directory named fabric; it was previously in a directory named datasynapse. The recommended installation location for Unix machines is now /opt/TIBCO/fabric; the recommended location for Windows is c:\TIBCO\fabric.

• The Search control shown on Administration Tool pages containing tables no longer has case-sensitive search or column search options.

• The CloudManagerAdmin SOAP Service has been deprecated.

• The example Application included in previous versions of Silver Fabric has been replaced by an Example Stack. If you upgrade, both Stacks will be present. You should unpublish and remove the Stack named "Example Application".

• The download and VirtualRouter pages are located in the Admin menu, but in previous versions, the relevant permissions were available in the User role. Access to these pages now requires the Admin view permission.

• The CLI command downloadGridlib does not work when passing only the Grid Library name as parameter. You must now pass the name, version, and OS.

• Component Types are now versioned. This allows users to upgrade which Enabler is used by a Component, provided multiple Enabler and Component Type versions are installed, and the Enabler developer has implemented this behavior.


| 87

• Logging of velocity variable replacement activity was previously logged in the Engine log. This is now logged to a separate velocity.log file on the Engine.


88 |

Enabler Changes

For the latest information on Enabler requirements, see the included Readme file. For additional information see the applicable Enabler-specific guide.


| 89

Appendix A Asset Manager Installation

This chapter covers how to extend Silver Fabric functionality by installing optional Asset Managers. It also contains information on installing and using the VMWare Asset Manager.

Topics

• Installing Asset Managers, page 90

• Installing and Using the VMware Asset Manager, page 91


90 |

Installing Asset Managers

An Asset Manager is a Silver Fabric Broker add-on component that enables a Broker to manage resources beyond the allocation of Engines to Components. For instance, the VMware Asset Manager that ships with Silver Fabric enables Silver Fabric to use VMware APIs to start, stop and monitor VMware virtual machines.

Asset Managers can be implemented in Java, or you can also implement Asset Managers using Jython or JavaScript scripts. For more information on developing your own Asset Manager, see the Silver Fabric Developer’s Guide.

An Asset Manager consists of an XML descriptor file and one or more JAR files. To deploy the Asset Manager:

1. Copy the JAR and the XML descriptor to the SF_HOME/webapps/livecluster/WEB-INF/assets directory of the Silver Fabric Broker.

The Asset Manager will automatically be detected and loaded.

Asset Managers can also be installed using the REST API. See Transferring Broker Resources Using REST Services on page 114 in the Silver Fabric Developer’s Guide for more details.

You can verify successful deployment by ensuring that the Asset Manager appears on the Admin > Assets page in the Silver Fabric Administration Tool. That page may also be used to Enable and Disable Asset Managers as well as edit Asset Managers that have an AssetManagerConfig implementation.

Multiple Asset Managers deployed to the same directory will share the same set of JARs. The addition, removal, or modification of any JAR in that directory will cause all Asset Managers in that directory to be reloaded. To segregate Asset Managers, you may add the Asset Manager JARs and XML file to a first-level subdirectory of the SF_HOME/webapps/livecluster/WEB-INF/assets directory.


| 91

Installing and Using the VMware Asset Manager

Silver Fabric supports Engines hosted on virtual machines running VMware through an Asset Manager for VMware. This Asset Manager analyzes the current allocation and can start or stop virtual machines based on Component Engine minima and maxima.

The Asset Manager for VMware can start and stop existing virtual machines and clone new virtual machines from existing templates. You can optionally configure new Engine installation using VMWare Guest OS Access, but otherwise it does not create new virtual machines or install the Engine on pre-existing virtual machines or templates.

For information on the versions of VMware supported by Silver Fabric, see the Silver Fabric readme file.

PreparationThe Asset Manager for VMware does not configure VirtualCenter. All paths you reference in the Asset Manager configuration must exist before enabling the Asset Manager.

To prepare for installation and configuration:

1. Create a base location for Silver Fabric related activity such as /TIBCO/fabric

2. Create a folder for templates such as /TIBCO/fabric/templates

3. Create a folder for cloned virtual machines, such as: /TIBCO/fabric/engines

4. Optionally, create a folder called init for the initial virtual machine pool under the base location, such as: /TIBCO/fabric/engines/init. If you do not create this folder, it is created automatically.


92 |

5. Create templates for each Component:

a. Create a virtual machine with the desired OS.

b. Install VMware Tools. Silver Fabric relies on functionality provided by VMware Tools.

c. Install the Silver Fabric Engine in the usual way.

d. Run configure.sh, start the Engine, and ensure that the Engine can communicate with the Broker.

e. Shut down the Engine and remove the contents of the profiles directory.

f. Create a file in the Engine directory named engine-session.properties, and add a property with the name vimTemplate with the value set to the name of the template.

g. Configure the Engine to start up automatically upon boot, using the OS-appropriate procedure. See “Example Startup Scripts” below for details.

h. Shut down the VM cleanly.

i. Convert the VM to a template.

6. Ensure that all templates reside in the templates folder you created above.

7. Assign permissions to the user running the Engine, if required. Ensure that users have the following permissions set:

OPERATION PRIVILEGE

cloneVMTask VirtualMachine.Inventory.CreateFromExisting, VirtualMachine.Inventory.Create, VirtualMachine.Provisioning.DeployTemplate

createCustomizationSpec VirtualMachine.Provisioning.ModifyCustSpecs

createFilter System.View

createFolder Folder.Create

createTemporaryFileInGuest VirtualMachine.GuestOperations.Modify

deleteDirectoryInGuest VirtualMachine.GuestOperations.Modify

deleteFileInGuest VirtualMachine.GuestOperations.Modify

destroyPropertyFilter NONE

destroyTask VirtualMachine.Inventory.Delete


| 93

enterMaintenanceModeTask Host.Config.Maintenance

exitMaintenanceModeTask Host.Config.Maintenance

findByInventoryPath System.View

findByIp System.View

getCustomizationSpec VirtualMachine.Provisioning.ReadCustSpecs

initiateFileTransferFromGuest VirtualMachine.GuestOperations.Query

initiateFileTransferToGuest VirtualMachine.GuestOperations.Modify

listFilesInGuest VirtualMachine.GuestOperations.Query

listProcessesInGuest VirtualMachine.GuestOperations.Query

makeDirectoryInGuest VirtualMachine.GuestOperations.Modify

moveIntoFolderTask Host.Inventory.MoveHost, Host.Inventory.AddStandaloneHost, Host.Inventory.EditCluster

moveIntoTask Host.Inventory.EditCluster, Host.Inventory.MoveHost

powerOffVMTask VirtualMachine.Interact.PowerOff

powerOnVMTask VirtualMachine.Interact.PowerOn

reconfigVMTask VirtualMachine.Config.AdvancedConfig

retrieveProperties System.Anonymous

retrievePropertiesEx System.Anonymous

shutdownGuest VirtualMachine.Interact.PowerOff

startProgramInGuest VirtualMachine.GuestOperations.Execute

waitForUpdates System.View

OPERATION PRIVILEGE


94 |

Example Startup ScriptsThe Asset Manager passes several properties to cloned virtual machines that can be retrieved from VMware Tools. See the “Available Asset Manager Configuration Properties” for a list of properties available to the virtual machine to automatically configure the Engine at operating system startup.

The following is an example startup script for Red Hat Linux:

#!/bin/sh# Startup script for Silver Fabric Engine#DSBASE=/opt/silverfabric/DSEngineJAVA_HOME=/usr/local/javaVMWARE_TOOLS=/usr/sbin/vmtoolsdVMWARE_TOOLS_CMD='info-get guestinfo.broker_url'export JAVA_HOMEcase "$1" in

start)cd $DSBASEif [ ! -d profiles ]; then

BROKER_URL=while [ $SECONDS -lt 60 ]; do

echo $VMWARE_TOOLS --cmd "$VMWARE_TOOLS_CMD"BROKER_URL=`$VMWARE_TOOLS --cmd "$VMWARE_TOOLS_CMD"`

if [ "$BROKER_URL" == "" -o "$BROKER_URL" == "No value found" ]; then

echo sleepingsleep 5

elseecho $BROKER_URLENGINE_OPTIONS=`echo $BROKER_URL | sed

's/https\?:\/\/$.*$/\1/'`if [[ $BROKER_URL == https* ]]; then

ENGINE_OPTIONS=$ENGINE_OPTIONS -lfi./configure.sh -s $ENGINE_OPTIONS./engine.sh startexit 0

fidone

VMware uses SSL by default for client communication. When using SSL to communicate with VirtualCenter, add the certificate used by VirtualCenter to Silver Fabric’s SF_HOME/webapps/livecluster/WEB-INF/certs/ssl.keystore file. The certificate is on the VirtualCenter at: C:\ProgramData\VMware\VMware VirtualCenter\SSL\rui.crt. In addition, you must set up a server.keystore file for the Broker; see “Enabling HTTPS on the Application Server” in the Silver Fabric Cloud Administration Guide for details.


| 95

echo "Error: no Broker URL found"exit 6

else./engine.sh start

fi;;

stop)cd $DSBASE./engine.sh stop;;

restart)cd $DSBASE./engine.sh stop./engine.sh start;;

*)echo $"Usage: $0 {start|stop|restart}"exit 1;;

esac

The following is an example RunOnce script for Windows:

@REM Copyright 2014 TIBCO Software Inc. All Rights Reserved. @echo offsetlocalset COMMAND_PATH=C:\Program Files\VMware\VMware Toolsset COMMAND_NAME=vmtoolsd.exeset COMMAND_ARGS="info-get guestinfo.broker_url"set BROKER_URL=No Value Foundset DS_ENGINE_SERVICE=DataSynapse Engineset ENGINE_BASE_DIR=C:\TIBCO\DataSynapse\Engineset INTRANET_DAT="%ENGINE_BASE_DIR%\intranet.dat"set COUNT=1cd %COMMAND_PATH%:checkToolsif %COUNT% gtr 20 ( echo Failed to get Broker URL goto:EOF) else ( set /a COUNT+=1)for /F "usebackq tokens=*" %%i in (`%COMMAND_NAME% --cmd %COMMAND_ARGS%`) do @set BROKER_URL=%%iif /i "%BROKER_URL%" == "No Value Found" ( @REM Sleep for 5 seconds using the Windows PowerShell call C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe sleep 5) else ( goto:configureEngine) goto:checkTools

:configureEngineecho Configuring Engine with Broker URL %BROKER_URL%net stop "%DS_ENGINE_SERVICE%"


96 |

if EXIST %ENGINE_BASE_DIR%\profiles ( del /S /Q %ENGINE_BASE_DIR%\profiles)set NEW_BROKER_URL=%BROKER_URL%/livecluster/public_html/register/register.jspecho %NEW_BROKER_URL% > %INTRANET_DAT%net start "%DS_ENGINE_SERVICE%"

Configuring and Enabling the Asset Manager for VMwareThe Asset Manager for VMware is a standard part of the Silver Fabric installation. After preparing VirtualCenter for Silver Fabric use, configure the Asset Manager, on the primary Broker only, as follows:

1. Edit the Asset Manager by selecting Admin > Assets in the Administration Tool, and selecting Edit Asset Manager from the Actions list for the Asset Manager.

2. Select Configure the Asset Manager's properties and set the following properties:

— The login info for VirtualCenter, including the URL, username, and password.

— The information Silver Fabric requires to find templates, that is, datacenter, datastore, templateFolderPath, defaultTemplate, and computeResource.

3. If you want to install new Engines, click Next to configure VMWare Guest OS Access. See VMware Scripted Engine Installation on page 97 for more information.

4. Click Finish.

5. Enable the Asset Manager for VMware by selecting Enable Asset Manager from the Actions list for the Asset Manager.

VMware Behavior During FailoverWhen the cloud transitions to the Failover Broker, Engines residing on running virtual machines will move to the Failover Broker, but the number of running virtual machines will not change — the Failover Broker will not start new virtual machines or stop existing ones.


| 97

VMware Scripted Engine InstallationYou can prepare a VMware image and have the Engine installed by the Asset Manager on any image with VMware tools installed. To configure scripted Engine Installation:

1. Ensure you have Linux or Windows VM images with VMware tools installed and without Engines installed.

2. Edit the Asset Manager by selecting Admin > Assets in the Administration Tool, and selecting Edit Asset Manager from the Actions list for the Asset Manager.

3. Select Configure the Asset Manager's properties and set the following properties:

— The login info for VirtualCenter, including the URL, username, and password.

— The information Silver Fabric requires to find templates, that is, datacenter, datastore, templateFolderPath, defaultTemplate, and computeResource.

4. On the wizard page for Configure VMware Guest OS Access, you can add, edit or remove rules to provide credentials for access to the VMware images. Click Add.

5. For Property, select a VMware image property to match to select a subset of your images, and enter a regular expression in Regular Expression. For example, you could select the property OS and a regular expression of linux to install on any linux Engines.

6. Enter a username, password, and remote install directory for the image.

7. Select Ignore Host Certificate unless you want to check the host certificate when making the SSL connection to port 902 on the Virtual Machine's Host.

8. Click OK.

9. Add more rules, or continue editing the Asset Manager.

For linux images, the Asset Manager installs a silver_fabric service that automatically pulls vmware guestinfo for the Broker URL set by the Asset Manager and starts the Engine when the image restarts. The Asset Manager provisioned Engine and services can be uninstalled by calling uninstall.sh in the remote install directory.

For Windows images, the Asset Manager installs the scheduled startup task Datasynapse, which automatically pulls vmware guestinfo for the Broker URL set by the Asset Manager and starts the Engine when the image restarts. The Asset Manager provisioned Engine and services can be uninstalled by calling uninstall.bat in the remote install directory.


98 |

Customization SpecificationsVMware customization specifications are applied to the virtual machine during cloning when:

• vimSpecName is defined in a runtime context variable.

• hostname is defined in an Engine Preference Rule.

Customization specifications are automatically created with the hostname of the virtual machine when:

• hostname is defined in an Engine Preference Rule.

• IP is defined in an Engine Preference Rule.

• vimSpecName is not defined in a runtime context variable.

• A customization specification matching the hostname is not already defined

• The operating system of the virtual machine template is Linux.

Available Asset Manager Configuration PropertiesThe following table describes the VMware-specific configuration properties.

Note that for both the Vm Folder Path and Template Folder Path properties, the Vsphere/VMWare object model adds a vm to the path that is not visible in the client. The format of folder paths are /datacenter/vm/folder, where datacenter is the value of the Datacenter property. You can also have multiple folders after the vm, such as /datacenter/vm/folder/folder2.

For example, if your configuration has a Datacenter value of dev-vsphere5 and your template folder is fabric-templates, the template folder path would appear to be /dev-vsphere5/fabric-templates in the client. Additionally, if your vm folder path is fabric-vms the vm folder path would appear to be

If a customization specification is applied, it takes precedence over Runtime Context Variables set in a Component. For example, if you define three Components with the same customization specification, but different values for vimComputeResource, vimResourcePool, and vimDataStore, all Components will use the values set in the first Component started. This would cause the three VMs to be created in the same cluster, pool, and datastore.


| 99

/dev-vsphere5/fabric-vms in the client. However, in your Asset Manager configuration, the property value for Template Folder Path should be set to /dev-vsphere5/vm/fabric-templates and the Vm Folder Path set to /dev-vsphere5/vm/fabric-vms.

Table 6 VMware-Specific Configuration Properties

Property Description

Broker Options A property passed to a newly cloned virtual machine that can be retrieved with VMware Tools. The property is stored as guestinfo.broker_options. Note that this is only available in newly-cloned virtual machines.

Compute Resource A comma-separated list of hosts or clusters associated with the templates

Datacenter The name of the datacenter where the virtual machines and ComputeResources reside

Datastore A comma-separated list of datastores on which virtual machines will be created.

Default Template The name of the template to use when no template is specified for a particular Component.

Destroy Whether or not to destroy virtual machines after shutting them down.

DNS Domain The DNS domain to use when configuring the Customization Specification.

DNS Server The comma-separated list of DNS servers to use when configuring the customization specification.

Engine Idle Age The idle time in milliseconds before an Engine is shut down.

Engine Startup Timeout

The amount of time to wait for Engine startup and login before timing out and starting up a new virtual machine.

Gateway The comma-separated list of gateways to use when configuring the customization specification.


100 |

Max Engines The maximum number of VMs your VMware setup supports. When the asset manager is started, the number of available units is set to this number. As VMs are allocated, this number decreases. This also defines the number of potential units available to Skyway for allocation.

Max Resource Pool Cpu Usage

The maximum resource pool CPU utilization above which new virtual machines will not be cloned.

Max Resource Pool Mem Usage

The maximum resource pool memory utilization above which new virtual machines will not be cloned.

Min Free Datastore Mem in MB

The minimum free space in the datastore required for cloning a new virtual machine.

NFS Options A property passed to a cloned virtual machine that can be retrieved with VMware Tools. The property is stored as guestinfo.nfs_options.

Password The password used to login to VirtualCenter

Policy Analysis Interval

The amount of time in between analyses of the cloud and the running Stack

Require Policy Rule If set to true, only spin up virtual machines for Components that specify templates via rule. If set to false always use VMware to try to meet Engine deficits.

Resource Pool A comma-separated list of resource pools associated with the templates and virtual machines. If not specified, computeResource is used instead.

Sdk Client The VIM SDK implementation class to use. Do not edit this property.

Table 6 VMware-Specific Configuration Properties (Continued)



| 101

Shutdown Whether or not to shut down excess, free virtual machines. This is used when there are active policies that use VMware. If there are no active policies using VMware, VMs are always shut down.

The shutdown flag also only works on excess and free VMs, which do not include VMs that are started due to the Spare Vm Percentage parameter.

Shutdown occurs after the Engine exceeds the period defined by the Engine Idle Age parameter.

Spare Vm Percentage The percentage of spare virtual machines, expressed as a float, to power on (for example, .25f means 25% of the total number of virtual machines are free at all times.) Due to cloning times, one extra VM will be started at all times.

Subnet The subnet to use when configuring the customization specification.

Template Folder Path The path to the folder containing image templates

Username The username used to login to VirtualCenter

Vim Algorithm The VM allocation implementation to use. Do not edit this property.

Vm Folder Path The path to the folder in which cloned virtual machines are created

Vm Name The base name to use during image name generation (for example, setting this to fabric-vm will result in VM names of the form fabric-vm-<randomnumber>)

VMware URL The VirtualCenter web services base URL, for example, https://host/sdk

Table 6 VMware-Specific Configuration Properties (Continued)



102 |

Available Policy and Component Configuration PropertiesThe following table describes additional properties available to control interaction with the Asset Manager for VMware:

Table 7 VMWare Asset Manager Properties

Property Type Description

vimTemplate Resource Preference Rule

The name of the required template where the Component must run. The operator for the rule must be specified as ‘equals’.

SPEC_NAME Runtime Context Variable

Deprecated. Use vimSpecName instead.

vimSpecName Runtime Context Variable

The Customization Specification to use for the Component. Hostname or IP address must also be specified.

vimComputeResource

Runtime Context Variable

Overrides the Compute Resource configuration property for the Component.

vimResourcePool Runtime Context Variable

Overrides the Resource Pool configuration property for the Component.

vimDatacenter Runtime Context Variable

Overrides the Datacenter configuration property for the Component.

vimDataStore Runtime Context Variable

Overrides the Data Store configuration property for the Component.

vimVmFolderPath


Overrides the Vm Folder Path configuration property for the Component.

vimTemplateFolderPath


Overrides the Template Folder Path configuration property for the Component.


| 103

vimVmName Runtime Context Variable

Overrides the Vm Name configuration property for the Component.

vimDestroy Runtime Context Variable

Overrides the Destroy configuration property for the Component.

vimShutdown Runtime Context Variable

Overrides the Shutdown configuration property for the Component.

vimEngineIdleAge


Overrides the Engine Idle Age configuration property for the Component.

vimDnsDomain Runtime Context Variable

Overrides the DNS Domain configuration property for the Component.

vimDnsServer Runtime Context Variable

Overrides the DNS Server configuration property for the Component.

vimGateway Runtime Context Variable

Overrides the Gateway configuration property for the Component.

vimSubnet Runtime Context Variable

Overrides the Subnet configuration property for the Component.

vimBrokerOptions


Overrides the Broker Options configuration property for the Component. This does not populate the broker_url vmware property. It populates the broker_options vmware property. This only available for newly cloned images.

Table 7 VMWare Asset Manager Properties (Continued)



104 |

vimNfsOptions Runtime Context Variable

Overrides the NFS Options configuration property for the Component.

guestinfo.* Runtime Context Variable

All properties prefixed with guestinfo. will be passed to the cloned virtual machine and available from VMware Tools.

guestinfo.broker_url

Cloned Virtual Machine Property

The Broker URL is passed to the cloned virtual machine and can be retrieved with VMware Tools.

hostname Resource Preference Rule

The hostname in the Customization Specification.

IP Resource Preference Rule

The IP address in the Customization Specification.

Table 7 VMWare Asset Manager Properties (Continued)



| 105

Appendix B Database Configuration

The Silver Fabric Broker can use a reporting database to store tables containing statistics for Components, allocation, Engines, and other records. You can configure Silver Fabric to use an enterprise-grade database from another vendor for the reporting database. The HSQLDB database that is included with Silver Fabric can be used as a test reporting database for demonstration purposes.

Topics

• Installing Standalone HSQLDB, page 106

• Reporting Database Installation and Configuration, page 107

• Third-Party Database Known Issues, page 110

If a Broker has already been running against a different third-party database and the contents of the database have not been migrated to the new database, all data will be lost. Establish the database you plan on running against prior to Broker initialization.


106 |

Installing Standalone HSQLDB

Silver Fabric includes a sample HSQLDB reporting database, which can be used to demonstrate the use of a reporting database. It is located at SF_HOME/webapps/livecluster/WEB-INF/etc/db/hsqldb.

Its default port is 5000, and you can change it in the server.properties file. The username and password are set in the reporting.script, and are ADMIN/ADMIN by default. The database is started by running the run.bat or run.sh script.

To use HSQLDB as your test reporting database, copy the SF_HOME/webapps/livecluster/WEB-INF/etc/db/hsqldb directory to an appropriate application location, start the database, and follow the database configuration instructions below. The steps for setting the CLASSPATH and running the createdb script can be skipped.

The included HSQLDB reporting database can be used for testing and lightweight reporting, but it is primarily for demonstration, development, and integration purposes. For production environments, use an enterprise database system that supports JDBC.


| 107

Reporting Database Installation and Configuration

There are three steps to configure the reporting database. First, you install your Broker; second, configure the database; third, configure the Broker to use the database. You will also need to restart the Broker after configuring it for a new database.

Task A Install the Broker

1. Install and configure your Silver Fabric Broker. Do not change any of the database settings during installation. Restart the Broker after completing the installation.

2. Ensure that the tables.<db>.sql file needed by the createdb script is located in the SF_HOME/webapps/livecluster/WEB-INF/etc/db directory. Supported databases are listed in the Silver Fabric readme file.

Task B Configure the database (skip these steps for HSQLDB)

1. Set the CLASSPATH. The CLASSPATH must include the database driver JAR files applicable to your database. For example, to create an MSSQL database in a Unix shell:

export

CLASSPATH=JDBCDriver/msbase.jar:JDBCDriver/mssqlserver.jar:JDBCDriver/msutil.jar

replacing JDBCDriver with the actual path to the directory containing your driver JAR files.

2. Run the createdb script provided in SF_HOME/webapps/livecluster/WEB-INF/etc/db directory on your Broker. You must pass the name of the appropriate properties file as an argument, specify the one which corresponds to your database. Before you run the script, change the property file settings to match those of your database.

Task C Configure the Broker

1. Log in to the Silver Fabric Administration Tool as a user in the cloud account with the Administer role.

2. Go to Config > Broker > Database.


108 |

3. Configure the values in the Reporting Database Connection section using the appropriate table below. Note that hostname is the hostname and database is the name of the database.

Property Value

HSQLDB

URL jdbc:hsqldb:hsql://hostname:5000/reporting

Driver org.hsqldb.jdbcDriver

Transaction Isolation

TRANSACTION_READ_UNCOMMITED

Database Type

hsql

Oracle

URL jdbc:oracle:thin:@hostname:1521:database

Driver oracle.jdbc.OracleDriver

Transaction Isolation

TRANSACTION_READ_COMMITTED

(The default value is TRANSACTION_READ_UNCOMMITTED, which does not work properly with Oracle.)

Database Type

oracle

Sybase Adaptive Server Enterprise

URL jdbc:sybase:Tds:hostname:5000/database

Driver com.sybase.jdbc2.jdbc.SybDriver

Database Type

sybase

Microsoft SQL Server

URL jdbc:sqlserver://hostname:1433;DatabaseName=dbName;SelectMethod=cursor

(SelectMethod=cursor is required)


| 109

4. Copy the corresponding JDBC driver’s JAR file into the Broker’s SF_HOME/webapps/livecluster/WEB-INF/lib directory.

5. Restart the Silver Fabric Broker.

Driver com.microsoft.sqlserver.jdbc.SQLServerDriver

Database Type

mssql

MySQL

URL jdbc.url=jdbc:mysql://host:port/database

Driver com.mysql.jdbc.Driver

Database Type

mysql

PostgreSQL

jdbc:postgresql://host:port/database

org.postgresql.Driver

postgresql

Property Value


110 |

Third-Party Database Known Issues

Microsoft SQL ServerSetting the SelectMethod property to Direct will result in errors. Set SelectMethod must to cursor to prevent direct query connection cloning from conflicting with the Silver Fabric Broker’s connection pooling scheme.

The SelectMethod=cursor property is only required when using the Type 4 JDBC drivers provided by Microsoft. Other drivers have not been tested.

OracleFor Oracle 11g, use the Oracle JDBC 11.1 drivers. For Oracle 12c, use the Oracle JDBC 12.1 drivers.

SybaseBy default, Sybase does not allow null values in string columns (like VARCHAR, TEXT, and so on.) You can change this default value for a database using isql by issuing the following command:sp_dboption databasename, "allow nulls by default", true

In this example, databasename is your database name. You must execute this command before creating the DB schema.


tibco silver fabric - tibco software · † silver fabric developer’s guide developer-related...

Documents