HAHTsite Application Server Administration Guide

Transcription

1 HAHTsite Application Server Administration Guide

2 Application Server Administration Guide release 4.0

3 Notice Copyright 1999 HAHT Software, Inc. All Rights Reserved March 1999 MN05-C No part of this publication may be copied, photocopied, reproduced, transmitted, transcribed, or reduced to any electronic medium or machine-readable form without the prior written consent of HAHT Software, Inc. Information in this document is subject to change without notice. Names and information used in examples are fictitious. U.S. GOVERNMENT RESTRICTED RIGHTS. It is acknowledged that the Software and the Documentation were developed at private expense, that no part is in the public domain, and that the Software and Documentation are Commercial Computer Software provided with RESTRICTED RIGHTS under Federal Acquisition Regulations and agency supplements to them. Use, duplication, or disclosure by the U.S. Government is subject to restrictions as set forth in subparagraph (c)(1)(ii) of The Rights in Technical Data and Computer Software clause at DFAR et. seq. or subparagraph (c)(1) and (2) of the Commercial Computer Software 96 Restricted Rights at FAR , as applicable. Contractor is HAHT Software, Inc., 4200 Six Forks Rd, Raleigh, NC Rights are reserved under copyright laws of the United States with respect to unpublished portions of the Software. Trademarks HAHT, HAHT Software, HAHTsite, e-scenario, and e-nable your enterprise are trademarks or U.S. registered trademarks of HAHT Software, Inc. All other tradenames are trademarks or registered trademarks of their respective companies. Specifications subject to change without notice. Portions Copyright Summit Software Company. This product includes software developed by the Apache Group for use in the Apache HTTP server project ( Inprise, Visibroker, and Visibroker for Java are trademarks or registered trademarks of Inprise Corporation. IBM and IBM-AIX are registered trademarks of International Business Machines Corporation. UNIX is a registered trademark exclusively licensed through X/Open Company, Ltd. Sun, Solaris, Java, and JavaScript are trademarks or registered trademarks of Sun Microsystems, Inc. Microsoft, Windows, Windows NT, Visual Basic, VBScript, Active X, and SQL Server are trademarks or registered trademarks of Microsoft Corporation. DG and DG/UX are U.S. registered trademarks of Data General Corporation. Any other product names, trademarks, tradenames, service marks, or service names owned or registered by any other company and mentioned herein are the property of their respective companies. HAHT Software, Inc Six Forks Road Raleigh, NC USA (919) (888) (in the USA) (919) (Technical Support)

4 Contents About This Book What s in This Book ix Other HAHTsite documentation x Other HAHTsite products x Conventions xi HAHTsite Application Server installation directory xi Continuation characters in sample code xi HAHT Software s commitment to you xi 1 Introducing the HAHTsite Application Server What s in this chapter Functional overview HAHTsite Application Server architecture Performance Scalability High availability Manageability Deployment flexibility Application Server editions Application Server configurations Administrative overview Application Server components Application Server group components What is the Administrator utility? HAHTsite Application Server processes hsrun hsredir hsrexec hsserver iii

5 Contents hsadmsrv hscontrol and hsradmin Session Objects and StateIDs How the Application Server is Licensed Administering the HAHTsite Application Server Getting started with the Administrator utility Starting the utility Logging in Selecting server groups and operations Distributed server groups Configuring the Application Server s SNMP interface Menu Bar buttons Exiting from the Administrator Administering hosts, server groups, and Administrator accounts Maintaining host computers Maintaining server groups User account authentication Performing Administrative Tasks Directories Directories and publish parameters FTP parameters Runtime Options If you enter invalid parameters on the Runtime options form Language options Logging options Auditing options Statistics Current statistics Cumulative statistics History iv

6 Contents Sessions Services Application services tasks Applications View log files Analyzing log files Access control Admin rights Changing the master administrator account Creating the HAHTsite password file Maintaining the HAHTsite password file HAHTsite username and password syntax Setting an initial master administrator password (UNIX) Changing authentication methods Assigning administrative rights License information Upgrading the number of active session licenses Configuring information for warning messages Other Administrative Procedures Introduction Manually starting administration services Distributed Application Server configuration hscontrol hsredir hsradmin Starting HAHTsite Application Server Installations Changing the Application Server s user/group ownership (UNIX) 122 Defining the Application Server s environment Changing the UID/GID of the server group s configuration file Tuning Tips Introduction v

7 Contents Selecting a hardware configuration for the Application Server Web server performance considerations Configuring Application Server processes and threads Can you use multi-threading in the Application Server? What controls the number of processes and threads? Guidelines for the process/thread configuration Analyzing performance problems High communication time High page queue time High page run time A HAHTsite Application Server Error Messages Introduction hsserver error messages Customizing your hsserver error messages Redirecting a user when an application times out Returning a static page Automatically redirecting the user Appending the log file entry to the hsserver error message hsrun error messages B Setting up NSAPI, ISAPI, and the Oracle Cartridge Introduction Setting up NSAPI Windows NT UNIX Setting up ISAPI for IIS Setting up ISAPI for IIS Setting up the Oracle Web Application Server Configuring the Administrator as an NSAPI, ISAPI, or Oracle application. 156 vi

8 Contents C Creating Redistributable Applications Introduction General procedure Creating the redistributable application Delivering the application Creating an installation script Advanced installation script notes About the.ini file D Configuring the Application Server to Use DES Encryption What is DES? Triple DES and the HAHTsite Application Server vii

9 Contents viii

10 About This Book This book describes how the HAHTsite Application Server works and how it interacts with the other components of HAHTsite. The book also tells Web site administrators how to configure, administer, and tune a HAHTsite Application Server. Unless otherwise noted, the information in this book applies to UNIX and Windows NT 4.0. What s in This Book The following table summarizes the contents of this book: Chapter/Appendix Chapter 1, Introducing the HAHTsite Application Server Chapter 2, Administering the HAHTsite Application Server Chapter 3, Performing Administrative Tasks Chapter 4, Other Administrative Procedures Chapter 5, Tuning Tips Contents Introduces the HAHTsite Application Server and describes how it fits into the family of HAHTsite products. Describes how to use the Administrator utility to configure and administer the HAHTsite Application Server. Describes configuration and monitoring procedures that you can perform with the Administrator utility. Describes administrative procedures that are not part of the Administrator utility. You perform them from the operating system of the Application Server host. Describes the resources that the Application Server uses and the factors that you should consider in tuning your Application Server. ix

11 About This Book Chapter/Appendix Appendix A, HAHTsite Application Server Error Messages Appendix B, Setting up NSAPI, ISAPI, and the Oracle Cartridge Appendix C, Creating Redistributable Applications Contents Describes the error messages that the HAHTsite Application Server displays when an error occurs at runtime, and explains how these error messages can be customized. Describes how to configure NSAPI, ISAPI, and Oracle s Web Application Server for use with the HAHTsite Application Server. Describes how to create redistributable, or shrink wrapped, HAHTsite applications. Other HAHTsite documentation Other documentation shipped with the HAHTsite Application Server includes: HAHTsite Application Server Installation Guide Online help for the HAHTsite Application Server Other HAHTsite products In addition to the Application Server and Application Server Administrator utility, the HAHTsite family of products includes: The HAHTsite IDE, a complete environment for building, publishing, and maintaining Web applications. Web developers use the suite of tools that come with the IDE to create their Web site applications. The HAHTsite IP, a subset of the IDE consisting of the features used by page layout artists, graphics designers, and content editors. x

12 About This Book Conventions The conventions used in this book are described here. HAHTsite Application Server installation directory The directory into which you install the HAHTsite Application Server is called the Application Server installation directory. This book uses the variable HAHTsiteInstallDir as a placeholder for the Application Server installation directory (for example, c:\hahtsite). When you see this variable, you should replace it with the name of the Application Server installation directory on your system. Here is an example: 1 Copy the files from HAHTsiteInstallDir\bin into the Web server s CGI- BIN directory. If you installed the Application Server in c:\hahtsite, you would copy the files from c:\hahtsite\bin. Continuation characters in sample code Some lines of sample code are too long to fit on one line. In that case, this book uses the HAHTtalk Basic line-continuation character ("_") at the end of a line. Example: Function Create (instancehandle As Long, createtime As Integer, _ scopecount As Long) As Integer HAHT Software s commitment to you We want you to be completely satisfied with your HAHT Software products. If you have questions about HAHTsite, the HAHTsite IDE, the HAHTsite IP, or the HAHTsite Application Server, you can contact HAHT Software in the following ways: xi

13 About This Book Telephone (919) Technical Support (Voice) (919) Technical Support (FAX) (888) Sales (Voice in the USA) (919) Office (Voice) (919) Office (FAX) General Information Sales Support World Wide Web xii

14 Introducing the HAHTsite Application Server 1 What s in this chapter...2 Functional overview...2 HAHTsite Application Server architecture...4 Performance...4 Scalability...5 High availability...7 Manageability...10 Deployment flexibility...10 Administrative overview...17 What is the Administrator utility?...19 HAHTsite Application Server processes...20 Session Objects and StateIDs...23 How the Application Server is Licensed

15 Chapter 1: Introducing the HAHTsite Application Server What s in this chapter This chapter gives a functional and administrative overview of the HAHTsite Application Server. The functional overview describes how the Application Server interacts with other HAHTsite components in different configurations. The administrative overview describes administrative features and the processes that make up the Application Server. 2

16 Functional overview Chapter 1: Introducing the HAHTsite Application Server The HAHTsite Application Server provides a high performance, highly scalable, and highly reliable mechanism for enabling browser-based access to a variety of enterprise data stored in relational databases, ERP systems, or other legacy systems. Using the HAHTsite IDE, Web developers create content and business logic, then deploy and manage the application. Together, the HAHTsite Application Server and HAHTsite IDE are a complete platform and development tool for Web enabling the enterprise. HAHTsite applications are developed with the HAHTsite IDE or a subset of the IDE, the IP. Web developers use the IDE or IP to design and build Web applications and publish them to a HAHTsite Application Server, where the applications are executed and made available to the Web browsers of the application s users. A HAHTsite server cluster consists of one or more host computers running TCP/IP, a Web server, and a HAHTsite Application Server. The Web server can be any standard Hypertext Transfer Protocol (HTTP) server capable of executing Common Gateway Interface (CGI) programs and providing static Hypertext Markup Language (HTML) pages to Web browsers. For example, the Web server may be one of those available from Netscape, Microsoft, O Reilly & Associates, or Apache. Applications developed with the IDE usually include dynamic as well as static pages. The Web server processes requests for static HTML pages, but sends requests for dynamic pages (requests containing program statements in HAHTtalk Basic or Java) to the Application Server. In this way, the Application Server works in conjunction with the Web server to make possible the advanced function and high performance of HAHTsite applications. The Web server and Application Server communicate via one of several versions of a program, hsrun. The IDE ensures that the URL for dynamic pages instructs the Web server to execute hsrun. Execution of hsrun links the Web server to the right Application Server process, sends the request to that process, gets back the results, and returns the results to the Web server, which then returns them to the requesting Web browser. A special feature of the Application Server is that it maintains the state of a HAHTsite application. At the time the Application Server receives an initial request from hsrun, a unique StateID identifying the user and application instance is generated. Subsequent pages pertaining to the same user and application instance are tagged with the StateID and matched with the same Application Server instance. (See Session Objects and StateIDs on page 23 for information on how StateIDs are generated.) 3

17 Chapter 1: Introducing the HAHTsite Application Server StateIDs facilitate the sharing of information among pages and make it easier to use a database. For example, a HAHTsite application user can logon to a database and move from one Web page to another without having to reconnect to the database. The Web server alone, by contrast, does not retain information about pages that it processes. This statelessness of standard Web applications makes the sharing of information among pages difficult and the use of a database inefficient. Application Server component interactions The following figure illustrates how the HAHTsite Application Server cooperates with a standard Web server at a HAHTsite location. The following is a summary of the HAHTsite application runtime interactions: A user s browser sends a request, in the form of a URL, to the Web server s HTTP layer. The HTTP layer passes the URL to the Web server program. If the request is for a static (HTML) page, the Web server program retrieves the page and sends it back to the HTTP layer, which forwards the page back to the user s browser. 4

18 Chapter 1: Introducing the HAHTsite Application Server If the request is for a dynamic page, the Web server passes the URL, which can include arguments, to the HAHTsite Application Server through the interface layer, hsrun. The Application Server reads the (optional) arguments that are passed with the URL, then executes the page s code to assemble the dynamic page on-the-fly. To assemble a page, the Application Server can access files on the server, files on the network, or tables in a database management system, or it can execute other programs. When the Application Server has assembled the dynamic page (in the form of HTML), it sends the assembled page to the HTTP layer. The HTTP layer sends the page back to the user s browser. 5

19 Chapter 1: Introducing the HAHTsite Application Server HAHTsite Application Server architecture As enterprise-class middleware, the HAHTsite Application Server is designed to meet enterprise-class requirements for: Performance Scalability High availability Manageability Deployment flexibility Performance The primary architectural goal of the HAHTsite Application Server is performance measured as its rate of delivering dynamically generated Web pages. Web applications are by nature intended to serve large numbers of concurrent users, so application servers must be fast and efficient in serving requests if they are to be deployable at the enterprise level. The HAHTsite Application Server supports applications written in HAHTtalk Basic or in Java. HAHTtalk Basic is fully syntax compatible with Visual Basic, but it is compiled, giving it a large speed advantage over comparable systems that interpret VBScript or JavaScript from source at runtime. For executing Java code, the HAHTsite Application Server works with standard Java Virtual Machines (VMs) from Microsoft and Sun, including associated Just-In-Time (JIT) compilers. The Application Server is designed for minimum interprocess communication. Requests from browsers go to a standard Web server, and then are routed directly to the proper Application Server process via standard Web server interfaces such as CGI, or for best performance, NSAPI, or ISAPI. Each Application Server process contains all of the facilities necessary to service the request, and does not require communicating with another process or another computer. Scalability The HAHTsite Application Server is designed for scalability into the tens of thousands of concurrent users. Scalability is achieved by replicating Application Server components across multiple processes and computers so that the replicated components can operate in parallel to serve more users. The 6

20 Chapter 1: Introducing the HAHTsite Application Server result is an Application Server Cluster with one or more computers cooperating to serve users. A cluster contains three types of logical hosts: Foreground hosts Background hosts Control hosts In smaller configurations, two or more of these types can be run on the same computer. Foreground host A foreground host runs each Web server in the cluster. Multiple Web server systems, each running the foreground software, may be used to increase the cluster's capacity to serve user requests and to provide redundancy in case of a system failure. The foreground software is lightweight. It works with the control host to perform load balancing, but otherwise simply redirects the user's request to the appropriate background host. Background host The background hosts do the actual work of servicing the user request. The background host contains the HAHTtalk Basic or Java VM that executes the application logic and that connects to backend data sources. As a result of executing the application logic, the background host generates HTML that is returned to the foreground and the Web server for delivery to the end user's browser. Multiple background hosts can be used in a cluster to increase performance and to provide redundancy in case of a system failure. Control host The control host is comprised of the Cluster Membership Manager and various administrative functions. The Cluster Membership Manager is responsible for knowing at any given point in time which computers are active in the cluster. When a computer leaves the cluster due to a failure or phased shutdown, or (re)joins the cluster as a new member, the Membership Manager coordinates the transition and informs other cluster members of the change. The control host's administrative functions include managing the licensed user count, keeping performance statistics, and running the Application Server Administrator application. A cluster contains a primary control host, and optionally, one or more backup control hosts to provide redundancy in case of a failure. Once a user session is created, new requests in that session can be handled by any Web server on any foreground host. Because there is no communication between replicated foregrounds or replicated backgrounds, adding a new 7

21 Chapter 1: Introducing the HAHTsite Application Server foreground or background host produces nearly linear scalability, even with a significant number of hosts. The HAHTsite Application Server allows extremely large numbers of users to be supported efficiently. Consequently you can easily add additional computers to handle additional load without having to redesign your application. The HAHTsite Application Server uses dynamic, weighted, load balancing to ensure that user sessions are evenly distributed across the background hosts. Dynamic means the load balancing module uses actual load information from each background host at the time the decision is made not just a preset algorithm. Weighted means that each background host can be assigned a performance factor that biases the load balancing algorithm so that background hosts of different hardware performance can be mixed in the same cluster. For example, a 4-way SMP computer can be assigned a performance factor of 40 while a 2-way computer is assigned a performance factor of 20. With this weighting configuration, the load balancing module will tend to assign twice as much load to the 4-way computer. High availability High availability systems are designed to minimize downtime by using redundancy to route around a failure. User operation may be disrupted briefly a few seconds to a minute or two but never for hours or days as could occur with an unenhanced system. The HAHTsite Application Server includes a number of features to ensure the availability of a HAHTsite cluster. They include: the ability to define multiple foreground, background and control hosts; eliminating single points of failure online reconfiguration of many settings without server group restart; providing the administrator with extra flexibility implementation of high availability features without degrading system performance The replication architecture of the HAHTsite Application Server allows each software component to run on multiple computers or hosts providing high availability in addition to performance and scalability. In a fully configured cluster, if a computer fails, other computers running the same component pick up the load. If a foreground host in the cluster fails, the frontend router can direct traffic to other foreground hosts, and operation continues unaffected. If a background host fails, other background hosts continue operating. Sessions on the failed host are lost and must be restarted, but are directed to one of the remaining good background hosts along with 8

22 Chapter 1: Introducing the HAHTsite Application Server any new sessions. If a control host fails, the cluster includes one or more backup control hosts that assume the administrative and management functions. All of the HAHTsite Application Server hosts can be replicated for highavailablity (HA): control host (backup and primary) background host foreground host The HAHTsite Application Server provides application isolation by configuring clusters with one or more independent server groups. A server group consists of one or more processes running on the background hosts and servicing user requests. Applications are deployed to a particular server group, and execute only in the processes that make up that server group. By deploying different applications to different server groups, isolation is ensured. If an application should fail and cause abnormal termination of a process, other applications running in other server groups are isolated from the failure. Server group processes are monitored. If a process should abnormally terminate due to an application error, the termination is detected and the process is automatically restarted (though any user sessions running in that process are lost). This high availability feature ensures that the server group keeps running without operator intervention in spite of an occasional application error. In summary, the HAHTsite Application Server takes a broad, system approach to high availability. Cluster configurations provide redundancy with no single point of failure. Failures are automatically routed around by reconfiguring the cluster. But the Application Server also explicitly addresses the broader issues of system maintenance and upgrades that can often have as much effect on availability as recovery from failures. The online management features, phased shutdown option, and parallel installation capabilities eliminate causes of downtime that occur if these issues aren't addressed. Overview of host failure processing Background host failure - If a background host fails, the active control host detects the failure typically within about 15 seconds and ensures that new work requests are not sent to the failed background. However, sessions active on the failed background are lost. When the background is restarted, the active control will recognize this fact, and ensure that new session requests are routed to the background. 9

23 Chapter 1: Introducing the HAHTsite Application Server Active control host failure - When the active control host fails, the failure is detected by the other hosts. A backup control will take over management of the cluster (if there are multiple backup controls defined, an arbitration mechanism determines which one will become active) and the foreground and background hosts will connect to the new active control. Foreground host failure - If a foreground host fails, the active control host will detect that fact, but take no additional action; when the foreground host is restarted, the active control will begin forwarding the host load information for so it can route new session requests correctly. Backup control host In addition to the primary control host, you can define additional backup control hosts. Should the primary control host fail, a backup control host takes over control functions for the cluster until the primary control host becomes available. The primary control host then takes over control host functions. Primary vs backup control Note - For clarity, whichever control host is managing the cluster is designated as active in this section. There is one important difference in functionality between the backup and primary control hosts: when the backup control is active, you cannot change the cluster configuration. (For example, you can t add a server group or change parameters for existing server groups.) When running the HAHTsite Application Server Administrator while a backup control host is active, the administrator can review current server group settings, current session information, license information etc all the information that can be read while the primary control is active. In addition, existing server groups can be stopped or started. Since the backup control host needs to be able to run the HAHTsite Application Server administration utility, it must have a Web server installed. Like the primary control host, the backup control host can be installed on a machine hosting foreground or background functions. It is possible, although not very useful, to install a backup control on the same host as the primary control host (using a different install directory). Configuration changes made on the primary control hosts are propagated to backup control hosts via a mirror transfer. In essence, a copy of the configuration files (those in the conf directory) are sent to each backup control host that is running. This transfer is done both when a backup control host starts and initially connects with the active primary host, and whenever 10

24 Chapter 1: Introducing the HAHTsite Application Server the configuration (server group or license information) is changed. The mirror transfer protocol has some important implications: Make configuration changes when all backup controls are running, to ensure all backups have the latest configuration Once a backup control has a current mirror copy of the primary control host configuration, you can continue operations without the running the primary control host. For example, with all the machines in a cluster down, you can run an application by starting all the cluster s hosts except the primary control. (The backup control host takes over.) A backup control host cannot manage cluster operations until it has connected to the primary control host at least once (to get its initial mirror copy of the control host s configuration) On-the-fly configuration changes HAHTsite also allows the administrator to change many server group parameters without taking the server group down. The ability to do a soft server group shutdown on a node also provides considerable flexibility. The application itself can be re-published without restarting the server group. By replicating host functions, and using the online reconfiguration features, HAHTsite administrators should be able to provide continuous service even in the face of scheduled machine maintainance or unplanned host outages. Manageability The HAHTsite Application Server is easily managed for performance and availability in a corporate environment. Basic management functions are performed with the Application Server Administrator, which is itself a HAHTsite application that runs in a browser. Consequently, the Administrator runs on any platform that supports a browser, and it can run remotely from any location with browser access to the control host even over a modem line from home. One instance of the Administrator manages the Application Server across all computers that make up a cluster. Access to the Administrator is controlled by username and password, which may be kept in a HAHTsite specific access control list, or which may piggyback off the underlying operating system's username/password authentication. Authentication may be applied at the server group level so that different operators can manage only their own server groups. 11

25 Chapter 1: Introducing the HAHTsite Application Server Deployment flexibility The HAHTsite Application Server has the deployment flexibility to be used in enterprise environments with a variety of different computer systems and network configurations. Businesses often have standard choices for operating systems, Web servers, databases, development languages, and networks. Enterprise class middleware, such as application servers, should operate in the existing environment and not require the introduction of non-standard components. The HAHTsite Application Server can be deployed on Microsoft Windows NT for Intel, Sun Solaris for SPARC, Hewlett-Packard HP-UX, and IBM AIX. Different architectures can be used in any combination in a single heterogeneous cluster. For example, the foreground hosts can be on Sun Solaris while the background and control hosts are on Windows NT. In more exotic configurations, backgrounds can be of different architectures in the same cluster. The Application Server normalizes network traffic to a common byte-order so that differing architectures communicate with each other correctly. In smaller configurations, foreground, background, and control components can all be deployed on the same computer to minimize hardware requirements for development or test configurations. The Application Server can operate across a firewall for security in an application deployed over the Internet. The foreground, background, and control hosts can run on either side of the firewall as dictated by the application. With multiple foregrounds, one foreground can be deployed outside the firewall for Internet access and another foreground inside the firewall for Intranet access, allowing an application to be accessed by employees and non-employees without violating security guidelines. The Application Server connects with other parts of the Web application infrastructure using standard interfaces. It can be used with any Web server via the standard CGI interface. With Microsoft IIS or Netscape Enterprise Server, ISAPI or NSAPI interfaces can be used for higher performance. The Application Server supports the use of persistent connections by the Web server for higher performance as specified in the HTTP/1.1 standard. Changing the configuration of the Application Server does not require any changes to Web applications that it runs. The platform, replication, and configuration of foreground, background, and control hosts does not affect the application. At most, the application may need to redeployed using the HAHTsite IDE s one button publishing feature. Changes in the Web server and the usage of CGI, NSAPI, or ISAPI are also accommodated by simply republishing the application. 12

26 Chapter 1: Introducing the HAHTsite Application Server HAHTsite works with any browser. It requires no plug-ins or other software on the browser, and it does not require the complexity of a Java execution environment in the browser. It is at home with browsers running on Windows 3.1, Windows 95/98, Windows NT, Macintosh, or Unix workstations. Applications running in the Application Server can make use of features that are available in newer browsers, but the choice is entirely up to the application designer and is not dictated by HAHTsite. Consequently the HAHTsite Application Server is appropriate for applications accessed over the Internet where any possible browser may be used, and it is appropriate in a corporate intranet where a standard browser is used. The Application Server offers language flexibility. The bundled Virtual Machines execute HAHTtalk Basic or Java code, and Basic code can call into Java code. Java code executes using standard virtual machines from Microsoft or Sun (JDK 1.1.x or 2.x). You can make the choice on a per-server group basis so that one application might run with the Microsoft Java VM while another application executes with the Sun Java VM. HAHTtalk Basic or Java code can call out to code and API s written in other languages through native integration services supplied by the Application Server. Application Server editions There are two versions of the HAHTsite Application Server, one for the development environment only and one for production environments. The Developer Edition is provided with the HAHTsite IDE so that Web developers have a complete development and testing system for their HAHTsite applications, and is not licensed for use in a production environment. It runs as a desktop application on a Web developer s Windows 95 or Windows NT workstation, and is documented in the HAHTsite IDE and IP User s Guide. Note - If you plan to run both the Developer Edition and the full Application Server on a single machine, be sure to name your full Application Server installation something other than Default, as this name would create a conflict with the Developer Edition installation. The information in the remainder of this manual applies only to the full HAHTsite Application Server. To execute HAHTsite applications in a production environment, a site needs the HAHTsite Application Server, which is sold separately from the IDE. The Application Server is available for Windows NT and UNIX (Solaris, HP-UX, and IBM AIX) platforms. On Windows NT, the Application Server runs as a service 13

27 Chapter 1: Introducing the HAHTsite Application Server with one or more multi-threaded processes. On UNIX, it runs as one or more multi-threaded daemon processes. The Application Server is a per-concurrent-user licensed product. The Application Server can be installed on the same computer as the Web server, or on several, separate host computers. Concurrent users are counted across all hosts in the cluster. Application Server configurations One of the most important responsibilities of a HAHTsite administrator is configuring the site to deliver the best performance for each application served to Web browsers. Administrators must be able to combine multiple systems to meet the scalability demands of applications. The distributed architecture of the HAHTsite Application Server lets administrators configure it to support even the most demanding performance requirements supporting a large number of concurrent users with good response times for dynamic page requests. The Application Server Administrator utility assists administrators in achieving high performance by allowing configuration of Application Server parameters such as the number of processes. In addition, the Application Server Administrator provides usage and performance statistics as the application is running. Performance is not the only issue for many sites. You may also be concerned with: Security - The ability to limit access to sensitive information, whether to an entire Web site, or to specific pages therein. High-availability - focused on making the service available to the user as much of the time as possible. In the event of a fault, the user may notice some interruption of service, but will always be able to reconnect to the service and use it again either immediately or within a sharply bounded period of time. The HAHTsite Application Server can be configured to meet any or all of these needs. Basic Application Server configurations The following figure shows an Application Server operating on a single host. In the figure, page requests from the user s Web browser are sent to the Web server. Requests for static pages are handled by the Web server and the static HTML page is returned to the user s Web browser. Requests for dynamic pages are forwarded to the HAHTsite Application Server, which processes the information passed with the URL, accesses any database or external resource 14

28 Chapter 1: Introducing the HAHTsite Application Server needed to create the dynamic page, and passes the page back to the Web server, which then forwards it back to the user s Web browser. Functionally, this configuration is identical to a multi-machine configuration. The next figure shows a standard Application Server configuration using two host computers, where the Web server is installed on only one of them, the foreground host, and the Application Server runs alone on a separate 15

29 Chapter 1: Introducing the HAHTsite Application Server background host. In this configuration, the Web server and Application Server communicate via TCP/IP across the network. Configurations with one foreground host can run the Web server on a public host computer and the Application Server inside an optional firewall (not shown). This is a good choice for small sites that serve both public and private applications, or applications with public and private elements. The figure on the following page shows a basic high availability configuration. In this model, there are multiple Web servers, fronted by a load-balancing router that makes them all appear as a single IP address. The Web servers are coupled to redundant background hosts running the HAHTsite Application Server. One of the background hosts doubles as the cluster s control host managing communications among the Application Server elements. The other background host acts as a backup control host and takes over if the primary control host fails. 16

30 Chapter 1: Introducing the HAHTsite Application Server This configuration gives a site administrator several levels of control over application performance and security. For example: The workload of executing HAHTsite applications is shared among a variable number of host computers. The host computers can be assigned different priorities, such that highcapacity computers (those with more or faster processors, more memory, or access to special hardware) receive a larger share of the workload. The foreground host computers can be located in a public area, while the background hosts can be located behind a security firewall. The intelligent router divides the incoming workload among the Web servers running on the foreground host computers. 17

31 Chapter 1: Introducing the HAHTsite Application Server Each Web server distributes its share of the workload among the Application Servers running on the background hosts, based on each computer s capacity. Each Application Server subdivides its share of the work among the optimal number of processes based on the capacity of the computer. The modular nature of a HAHTsite server allows you to easily configure your server hardware to meet your exact requirements. Modifying the basic server to achieve high security, high availability, or both, is simply a matter of how many hosts you configure, and their placement relative to your firewall. The previous example shows a simple high security (HS), high availability (HA) configuration. By providing redundant foreground, background, and control hosts (primary and backup) along with a router to direct traffic to and from the Web servers, you can reduce the possibility of a critical fault to near zero. Adding a firewall to the configuration, and placing the control hosts safely behind it turns this into a high security configuration. The following table shows what elements are required to create the specific type of server you need. Hardware Configuration Foreground Hosts Background Hosts Control Hosts Router Firewall Base no no Base + HA >1 >1 >1 yes no Base + HS no yes Base + HA + HS >1 >1 >1 yes yes 18

32 Administrative overview Chapter 1: Introducing the HAHTsite Application Server The tasks of Application Server administration include: starting and stopping the server configuring it to work smoothly with the Web server and with the operating system tuning it for performance monitoring and upgrading (if necessary) concurrent user license counts Application Server components The Application Server is not implemented as a single process, but as a group of independent, cooperating processes. This implementation makes the Application Server scalable and adjustable to particular site capacities and application characteristics. A server group consists of one or more processes running on the background host(s) and servicing user requests. Applications are deployed to a particular server group, and execute only in the processes that make up that server group. The server group is the primary unit of Application Server administration. A HAHTsite administrator accesses the cooperating processes that comprise an Application Server at the server group level as a single entity. Thus, to start, stop, or otherwise configure an Application Server, an administrator performs these actions on the server s group a one-step operation. Without server groups, starting and stopping an Application Server would require multiple steps, and performance tuning would be difficult and error-prone. Application Server group components The processes of an Application Server group are distributed among three types of host computers: Foreground Host - Runs the Web server and a subset of the Application Server (the Application Redirector) Background Host - Runs the main portion of the Application Server (the processes that execute dynamic pages) Control Host - Manages communications among the Application Servers (running on the background hosts) and Application Redirectors (running on the foreground hosts). A backup control Host, when configured, takes over all control host functions if the primary control host fails during processing. 19

33 Chapter 1: Introducing the HAHTsite Application Server The foreground, background, and control host (primary, backup) roles can be performed by separate computers, or these roles can overlap. Thus, an administrator at a site with four server computers might install a Web server and Application Server on each of the four, and install the control software on one of them. Here s how the process framework is normally established: The control host starts hscontrol as part of its boot sequence. Each foreground host, as part of its boot sequence, starts hsredir, which connects with hscontrol on the control host and gets the foreground host s configuration information. Each background host, as part of its boot sequence, starts hsradmin, which connects with hscontrol on the control host and gets the background host s configuration information. When a server group starts The hsradmin process running on each background host starts an hsrexec child process. The hsrexec process, in turn, starts the configured number of hsserver processes for the server group on that background host. Debugging processes start as needed, and run on the appropriate background host computer as children of hsrexec. When an IDE developer publishes an application to an Application Server group, dynamic pages are sent to each of the group s background hosts. 20

34 Chapter 1: Introducing the HAHTsite Application Server What is the Administrator utility? The Administrator is the tool you use to configure, administer, and monitor the HAHTsite Application Server. Functions performed from the Administrator utility include: setting runtime performance parameters setting up Publish destinations for IDE developers starting and stopping server groups monitoring runtime statistics of applications defining logging options monitoring and upgrading concurrent user license counts A site has one master administrator and, optionally, one or more group administrators. The master administrator can administer all groups. Conversely, a group administrator only has access to one or more server groups. The HAHTsite Administrator is username and password protected. Responsibilities of the master administrator include the setting up of server groups and server group administrators. The Administrator runs only on the control host. At startup, the control host starts hscontrol, which starts the child process hsadmsrv. All concurrent Administrator sessions run as separate StateIDs under this single hsadmsrv process. Management of a HAHTsite Application Server cluster can be conducted online while the cluster is serving users. Most operations in the Application Server Administrator tool take effect immediately without having to stop and restart the Application Server. For example, server groups can be stopped and started, timeout values can be changed, process and thread counts can be increased, log files can be managed, license keys can be installed, and performance statistics can be viewed without interrupting service to users. Cluster transitions can be initiated under operator control. For example, a background host can undergo a phased shutdown. User sessions already on the background host continue running and complete normally, but new user sessions are directed to other background hosts. When no sessions are running on the designated host, the shutdown occurs. Using phased shutdown, individual computers in a cluster can be temporarily removed from the cluster in order to perform hardware or software maintenance such as installing a service pack. After maintenance service is complete, the background host can re-join the cluster. The load balancing module realizes the new background host is present with no load, and so allocates new user sessions to this 21