primecluster_as_pcs

Document Sample
primecluster_as_pcs Powered By Docstoc
					ASCC




 ASCC™
 PCS for Adaptive Services Control Center (Linux®, Windows®)
 Configuration Guide
 Redakteur
 Fujitsu Siemens Computers GmbH Paderborn
 33094 Paderborn
 e-mail: email: manuals@fujitsu-siemens.com
 Tel.: (089) 636-00000
 Fax: (++49) 700 / 372 00000
 U42147-J-Z100-4-76
 Sprachen: En




 Edition December 2006
Comments… Suggestions… Corrections…
The User Documentation Department would like to
know your opinion of this manual. Your feedback helps
us optimize our documentation to suit your individual
needs.
Fax forms for sending us your comments are included in
the back of the manual.
There you will also find the addresses of the relevant
User Documentation Department.


Certified documentation
according DIN EN ISO 9001:2000
To ensure a consistently high quality standard and
user-friendliness, this documentation was created to
meet the regulations of a quality management system
which complies with the requirements of the standard
DIN EN ISO 9001:2000.
cognitas. Gesellschaft für Technik-Dokumentation mbH
www.cognitas.de


Copyright and Trademarks
Copyright © 2002-2006, Fujitsu Siemens Computers Inc. and Fujitsu LIMITED.

All rights reserved.
Delivery subject to availability; right of technical modifications reserved.

© 2003 by SAP AG. All rights reserved. SAP, R/3, mySAP, mySAP.com, SAP NetWeaver, xApps,
xApp, and other SAP products and services mentioned herein as well as their respective logos
are trademarks or registered trademarks of SAP AG in Germany and in several other countries
all over the world. MarketSet and Enterprise Buyer are jointly owned trademarks of SAP AG and
Commerce One.

Sun, Sun Microsystems, Solaris, and Java are trademarks or registered trademarks of Sun
Microsystems, Inc. in the United States and other countries.

Linux is a registered trademark of Linus Torvalds.

All other hardware and software names used are trademarks of their respective companies.




This manual is printed on
paper treated with
chlorine-free bleach.
Preface




Introduction




PCS configuration basics




Getting started




PCS graphical user interface




Generic Linux applications




Program and process control




File systems and disk devices




Virtual connections




Volume and storage managers
Linux configuration example




Configuring Windows applications




Appendix—Site preparation




Appendix—NFS file system notes




Appendix—Object types




Appendix—Attributes




Glossary




Abbreviations




Figures




Tables
Contents
1         Preface . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    1
1.1       About this manual . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    1
1.2       ASCC documentation list . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    3
1.3       Conventions . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
1.3.1     Notation . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
1.3.1.1   Prompts . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
1.3.1.2   Manual page section numbers            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
1.3.1.3   The keyboard . . . . . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
1.3.1.4   Typefaces . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
1.3.1.5   Example 1 . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
1.3.1.6   Example 2 . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    5
1.3.2     Command line syntax . . . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    6
1.4       Important notes and cautions .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    6

Part I: Basics

2         Introduction . . . . . . . . . . . . . . . . . . . . .                                 .   .   .   .   . . 9
2.1       ASCC overview . . . . . . . . . . . . . . . . . . . .                                  .   .   .   .   . . 9
2.2       How ASCC provides high availability . . . . . . . . .                                  .   .   .   .   . 10
2.2.1     Applications, resources, and objects . . . . . . . . .                                 .   .   .   .   . 10
2.2.2     Relationship of ASCC configurations to the real world                                  .   .   .   .   . 13
2.2.3     Node and application failover . . . . . . . . . . . . .                                .   .   .   .   . 15
2.3       How PCS provides easy configuration . . . . . . . .                                    .   .   .   .   . 16
2.4       ASCC components . . . . . . . . . . . . . . . . . .                                    .   .   .   .   . 17
2.4.1     Base monitor . . . . . . . . . . . . . . . . . . . . .                                 .   .   .   .   . 17
2.4.2     Detectors and states . . . . . . . . . . . . . . . . .                                 .   .   .   .   . 18
2.4.3     Scripts . . . . . . . . . . . . . . . . . . . . . . . . .                              .   .   .   .   . 19
2.5       Object types . . . . . . . . . . . . . . . . . . . . .                                 .   .   .   .   . 20
2.6       Object attributes . . . . . . . . . . . . . . . . . . . .                              .   .   .   .   . 21
2.7       Environment variables . . . . . . . . . . . . . . . . .                                .   .   .   .   . 21
2.7.1     Script execution environment variables . . . . . . . .                                 .   .   .   .   . 22
2.8       ASCC Directory structure . . . . . . . . . . . . . . .                                 .   .   .   .   . 22

3         PCS configuration basics       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .       25
3.1       Introduction . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .       25
3.1.1     Overview of PCS . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .       25
3.1.2     Application templates . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .       27
3.1.3     Subapplications . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .       27
3.1.4     Resources . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .       28
3.1.5     Application dependencies .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .       28
3.2       Basic PCS concepts . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .       29



U42147-J-Z100-4-76                                                                                                       vii
Contents


3.2.1      Hierarchy of applications and subapplications                 .   .   .   .   .   .   .   .   .   29
3.2.2      Template types . . . . . . . . . . . . . . . .                .   .   .   .   .   .   .   .   .   30
3.2.3      Custom application templates . . . . . . . . .                .   .   .   .   .   .   .   .   .   30
3.2.4      Generic application template . . . . . . . . .                .   .   .   .   .   .   .   .   .   31
3.2.5      Comparison of application types . . . . . . .                 .   .   .   .   .   .   .   .   .   33
3.2.6      Subapplication templates . . . . . . . . . . .                .   .   .   .   .   .   .   .   .   34
3.2.7      Understanding templates and instances . . .                   .   .   .   .   .   .   .   .   .   35
3.3        PCS directory structure . . . . . . . . . . . .               .   .   .   .   .   .   .   .   .   36
3.4        Using multiple configurations in one image . .                .   .   .   .   .   .   .   .   .   38
3.4.1      Benefits . . . . . . . . . . . . . . . . . . . .              .   .   .   .   .   .   .   .   .   38
3.4.2      Restrictions . . . . . . . . . . . . . . . . . .              .   .   .   .   .   .   .   .   .   38
3.5        Commonly used PCS terms . . . . . . . . . .                   .   .   .   .   .   .   .   .   .   40

4          Getting started . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   43
4.1        Starting PCS on a reference node      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   43
4.2        Opening a configuration . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   46
4.2.1      Creating a new configuration . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   47
4.2.2      Viewing the PCS configuration . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   48

5          PCS graphical user interface . . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   51
5.1        PCS GUI views and controls . . . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   52
5.1.1      Menu bar . . . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   52
5.1.2      Configuration tree . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   53
5.1.2.1    Structure and terminology . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   53
5.1.2.2    Appearance . . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   54
5.1.3      User input and status area . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   56
5.1.4      Button bar . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   56
5.2        File menu . . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   57
5.2.1      Exiting PCS . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   57
5.2.2      Deleting configurations . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   58
5.2.3      Closing and saving configurations . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   60
5.3        Edit menu . . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   61
5.3.1      Add More Instances or Delete Instance         .   .   .   .   .   .   .   .   .   .   .   .   .   61
5.3.2      Detector Settings . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   62
5.3.3      Rename application . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   65
5.3.4      Create application . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   65
5.3.5      Delete application . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   66
5.4        Tools menu . . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   67
5.4.1      Generate . . . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   67
5.4.2      Draw Graph . . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   68
5.4.3      Activate . . . . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   71
5.4.4      Lock and Unlock . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   72
5.4.5      Check Consistency . . . . . . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   73
5.5        Option menu . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   74


viii                                                                             U42147-J-Z100-4-76
                                                                                                      Contents


5.6       Help facility . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    76
5.6.1     Help menu . . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    76
5.6.1.1   General help . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    76
5.6.1.2   Subapplication help . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    78
5.6.1.3   Application and Resource help       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    78
5.6.2     Context-sensitive help . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    79
5.6.3     Tooltip help . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    80

Part II: Linux Configurations

6         Generic Linux applications . . . . . . . . .                        .   .   .   .   .   .   .   .   . 83
6.1       Generic application template features . . . . .                     .   .   .   .   .   .   .   .   . 84
6.2       Creating an application . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   . 86
6.3       Setting application parameters . . . . . . . .                      .   .   .   .   .   .   .   .   . 88
6.3.1     Expert mode application parameters . . . . .                        .   .   .   .   .   .   .   .   . 88
6.4       Common subapplication procedures . . . . .                          .   .   .   .   .   .   .   .   . 91
6.4.1     Subapplication initial view . . . . . . . . . . .                   .   .   .   .   .   .   .   .   . 91
6.4.2     Creating multiple instances . . . . . . . . . .                     .   .   .   .   .   .   .   .   . 93
6.4.3     Deleting instances . . . . . . . . . . . . . . .                    .   .   .   .   .   .   .   .   . 95
6.5       Expert mode . . . . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   . 95
6.5.1     Switching between expert and standard mode                          .   .   .   .   .   .   .   .   . 95
6.5.2     Common options in expert mode . . . . . . .                         .   .   .   .   .   .   .   .   . 95
6.5.2.1   AutoRecover . . . . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   . 96
6.5.2.2   MonitorOnly . . . . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   . 96
6.5.2.3   ScriptTimeout . . . . . . . . . . . . . . . . .                     .   .   .   .   .   .   .   .   . 96
6.5.3     Expert mode group options . . . . . . . . . .                       .   .   .   .   .   .   .   .   . 97
6.5.4     Dynamic subapplications . . . . . . . . . . .                       .   .   .   .   .   .   .   .   . 99
6.5.4.1   Inserting a dynamic subapplication . . . . . .                      .   .   .   .   .   .   .   .   . 100

7         Program and process control .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   103
7.1       Command Line subapplication .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   104
7.1.1     Expert mode parameters . . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   106
7.1.2     Expert mode group options . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   108
7.1.3     Command Line processing notes           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   109

8         File systems and disk devices .             .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   111
8.1       Local File System subapplication .          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   112
8.1.1     Expert mode parameters . . . . .            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   114
8.1.2     Expert mode group options . . . .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   116
8.2       Remote File System subapplication           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   117
8.2.1     Expert mode parameters . . . . .            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   119
8.2.2     Expert mode group options . . . .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   121
8.3       Raw Disk subapplication . . . . .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   122
8.3.1     Expert mode parameters . . . . .            .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   125



U42147-J-Z100-4-76                                                                                                 ix
Contents


8.3.2      Expert mode group options . . . . . . . . . . . . . . . . . . . 126

9          Virtual connections . . . . . . . . . . . . . .         .   .   .   .   .   .   .   .   129
9.1        Ip Address subapplication . . . . . . . . . . . .       .   .   .   .   .   .   .   .   130
9.1.1      Expert mode parameters . . . . . . . . . . . .          .   .   .   .   .   .   .   .   134
9.1.2      Expert mode group options . . . . . . . . . . .         .   .   .   .   .   .   .   .   135
9.2        Virtual Host Name subapplication . . . . . . . .        .   .   .   .   .   .   .   .   136
9.2.1      Generating virtual host names . . . . . . . . .         .   .   .   .   .   .   .   .   137
9.2.2      Configuring a virtual IP address . . . . . . . . .      .   .   .   .   .   .   .   .   139
9.2.2.1    Site preparation steps for runtime IP addresses         .   .   .   .   .   .   .   .   139
9.2.2.2    Virtual host without IP address . . . . . . . . .       .   .   .   .   .   .   .   .   140
9.2.2.3    Virtual host with IP address . . . . . . . . . . .      .   .   .   .   .   .   .   .   142
9.2.3      Expert mode parameters . . . . . . . . . . . .          .   .   .   .   .   .   .   .   145

10         Volume and storage managers . . . . . .         .   .   .   .   .   .   .   .   .   .   147
10.1       Volume Manager subapplication group . . .       .   .   .   .   .   .   .   .   .   .   148
10.2       LVM Linux Volume Manager subapplication .       .   .   .   .   .   .   .   .   .   .   150
10.2.1     Expert mode parameters . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   152
10.2.2     Expert mode group options . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   154
10.3       Storage Manager subapplication group . . .      .   .   .   .   .   .   .   .   .   .   155

11         Linux configuration example . . . . . . . . . . . .                 .   .   .   .   .   157
11.1       Site preparation . . . . . . . . . . . . . . . . . . . .            .   .   .   .   .   158
11.2       Configuration procedure . . . . . . . . . . . . . . . .             .   .   .   .   .   159
11.2.1     Creating the configuration . . . . . . . . . . . . . . .            .   .   .   .   .   160
11.2.2     Choosing the application template . . . . . . . . . .               .   .   .   .   .   161
11.2.3     Setting the application name . . . . . . . . . . . . .              .   .   .   .   .   162
11.2.4     Viewing template information . . . . . . . . . . . . .              .   .   .   .   .   163
11.2.5     Viewing application parameters . . . . . . . . . . . .              .   .   .   .   .   164
11.2.6     Configuring the Command Line . . . . . . . . . . . .                .   .   .   .   .   165
11.2.7     Configuring a local file system . . . . . . . . . . . .             .   .   .   .   .   167
11.2.8     Configuring a remote file system . . . . . . . . . . .              .   .   .   .   .   169
11.2.9     Configuring the Ip Address . . . . . . . . . . . . . .              .   .   .   .   .   171
11.2.10    Saving and activating . . . . . . . . . . . . . . . . .             .   .   .   .   .   173
11.3       Testing the configuration . . . . . . . . . . . . . . .             .   .   .   .   .   175
11.3.1     Viewing object properties . . . . . . . . . . . . . . .             .   .   .   .   .   181
11.4       Viewing node and application logs . . . . . . . . . .               .   .   .   .   .   182
11.4.1     Common procedures for switchlog and application log                 .   .   .   .   .   184
11.4.2     Time filter . . . . . . . . . . . . . . . . . . . . . . .           .   .   .   .   .   185
11.4.3     Keyword filters . . . . . . . . . . . . . . . . . . . . .           .   .   .   .   .   186
11.4.3.1   Resource Name . . . . . . . . . . . . . . . . . . . .               .   .   .   .   .   186
11.4.3.2   Severity . . . . . . . . . . . . . . . . . . . . . . . .            .   .   .   .   .   187
11.4.3.3   Non-zero exit code . . . . . . . . . . . . . . . . . .              .   .   .   .   .   188
11.4.3.4   Keyword . . . . . . . . . . . . . . . . . . . . . . . .             .   .   .   .   .   188


x                                                                      U42147-J-Z100-4-76
                                                                                       Contents


11.4.4     Text search . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
11.4.5     Removing filters . . . . . . . . . . . . . . . . . . . . . . . . . 189
11.5       Taking the image . . . . . . . . . . . . . . . . . . . . . . . . 190

Part III: Windows Configurations

12         Configuring Windows applications . . . . . .            .   .   .   .   .   .   .   .   195
12.1       Creating a configuration . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   196
12.1.1     Creating or editing a configuration . . . . . . .       .   .   .   .   .   .   .   .   198
12.1.2     Choosing an application template . . . . . . . .        .   .   .   .   .   .   .   .   199
12.1.3     Naming the application . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   200
12.2       Configuring services and scripts . . . . . . . .        .   .   .   .   .   .   .   .   201
12.2.1     Configuring Windows services . . . . . . . . .          .   .   .   .   .   .   .   .   203
12.2.2     Changing the startup type of a service . . . . .        .   .   .   .   .   .   .   .   205
12.2.3     Configuring Start/Stop/Monitor command scripts          .   .   .   .   .   .   .   .   207
12.2.3.1   Creating WindowsSSM instances . . . . . . . .           .   .   .   .   .   .   .   .   210
12.2.3.2   Deleting WindowsSSM instances . . . . . . . .           .   .   .   .   .   .   .   .   211
12.2.3.3   Execution order for multiple scripts . . . . . . .      .   .   .   .   .   .   .   .   211
12.2.4     Combining Windows services and scripts . . . .          .   .   .   .   .   .   .   .   212
12.3       Saving and activating the configuration . . . . .       .   .   .   .   .   .   .   .   212
12.3.1     Saving the configuration . . . . . . . . . . . . .      .   .   .   .   .   .   .   .   213
12.3.2     Activating the configuration . . . . . . . . . . .      .   .   .   .   .   .   .   .   213
12.3.3     Generating the configuration . . . . . . . . . .        .   .   .   .   .   .   .   .   214
12.4       Using instance IDs . . . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   214
12.4.1     sat_getinstanceid.exe command usage . . . . .           .   .   .   .   .   .   .   .   215
12.5       Image-independent applications . . . . . . . .          .   .   .   .   .   .   .   .   216
12.5.1     Storing PCS configurations on the filer . . . . .       .   .   .   .   .   .   .   .   216
12.5.2     Storing applications on the filer . . . . . . . . .     .   .   .   .   .   .   .   .   217
12.5.3     Changing available applications on the filer . . .      .   .   .   .   .   .   .   .   217
12.5.4     Selecting the correct image for the task group .        .   .   .   .   .   .   .   .   220

Part IV: Reference

13         Appendix—Site preparation . . . . . . . . .         .   .   .   .   .   .   .   .   .   223
13.1       Network database files . . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   223
13.1.1     /etc/hosts . . . . . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   223
13.1.1.1   Network interface names in /etc/hosts . . . .       .   .   .   .   .   .   .   .   .   224
13.1.1.2   Virtual host names in /etc/hosts . . . . . . . .    .   .   .   .   .   .   .   .   .   225
13.1.2     /root/.rhosts . . . . . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   225
13.2       Configuration resource definitions . . . . . . .    .   .   .   .   .   .   .   .   .   226
13.2.1     /opt/SMAW/SMAWRrms/etc/hvipalias.satellite          .   .   .   .   .   .   .   .   .   226
13.2.1.1   Optional fields . . . . . . . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   227
13.2.2     /opt/SMAW/SMAWRrms/etc/hvconsoles . . .             .   .   .   .   .   .   .   .   .   228
13.3       Linux file systems . . . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   229



U42147-J-Z100-4-76                                                                                  xi
Contents


13.3.1     /etc/fstab.pcl . . . . . . . . . . .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   229
13.3.1.1   Clusterwide configuration issues       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   230
13.3.2     /etc/exports.pcl . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   231
13.3.3     Linux Volume Manager (LVM) . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   231
13.4       NFS servers . . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   233
13.4.1     LVM2 on Linux . . . . . . . . . .      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   233
13.5       Log files . . . . . . . . . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   234
13.5.1      /var/log/messages . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   234

14         Appendix—NFS file system notes .                   .   .   .   .   .   .   .   .   .   .   .   .   .   235
14.1       NFS mount point management . . . .                 .   .   .   .   .   .   .   .   .   .   .   .   .   235
14.2       Synchronized NFS file systems . . . .              .   .   .   .   .   .   .   .   .   .   .   .   .   236
14.2.1     Example 1: One server and one client               .   .   .   .   .   .   .   .   .   .   .   .   .   236
14.2.2     Example 2: Multiple servers and clients            .   .   .   .   .   .   .   .   .   .   .   .   .   237

15         Appendix—Object types . . . . . . . . . . . . . . . . . . . . 239

16         Appendix—Attributes . . . . . . . . . . . . . . . . . . . . . 241
16.1       Attributes available to the user . . . . . . . . . . . . . . . . . 241
16.2       Attributes managed by configuration wizards . . . . . . . . . . 246

Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251

Abbreviations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271

Figures    . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275

Tables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 283

Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285




xii                                                                                   U42147-J-Z100-4-76
1         Preface
ASCC™ Adaptive Services Control Center incorporates a software monitor
designed to guarantee the high availability of applications in a cluster of nodes.
This manual describes how to configure an application using
PRIMECLUSTER™ Configuration Services (PCS).
The manual is aimed at system administrators who create and maintain ASCC
configurations. Familiarity with the following system functions and components
is assumed:
●   ASCC family of products
●   Linux® or Windows Server™ operating system
●   Data center components such as volume managers and storage area
    networks.
This document assumes that the ASCC software has been installed as
described in the ASCC Adaptive Services Control Center (Linux, Windows) User
Guide.


1.1       About this manual
“Part I: Basics” provides an introduction to PCS and major functions in the PCS
interface:
●   The chapter “Introduction” on page 9 introduces ASCC terminology and
    describes basic principles of its high-availability management.
●   The chapter “PCS configuration basics” on page 25 introduces PCS
    concepts and describes how it uses application and subapplication
    templates to create configurations.
●   The chapter “Getting started” on page 43 outlines the configuration workflow
    and describes how to open PCS from the Web-Based Admin View
    management interface.
●   The chapter “PCS graphical user interface” on page 51 provides an
    overview of the PCS interface and a detailed description of all functions
    available from the menus.
“Part II: Linux Configurations” describes how to create Linux configurations:




U42147-J-Z100-4-76                                                               1
About this manual                                                      Preface


●   The chapter “Generic Linux applications” on page 83 provides an overview
    of the Generic application template and the standard set of subapplication
    templates, including details about common features and controls.
●   The chapter “Program and process control” on page 103 describes how to
    configure programs and processes.
●   The chapter “File systems and disk devices” on page 111 describes how to
    configure local and remote file systems, and raw disk devices.
●   The chapter “Virtual connections” on page 129 describes how to configure
    virtual network interfaces.
●   The chapter “Volume and storage managers” on page 147 describes how to
    configure commonly used volume and storage managers.
●   The chapter “Linux configuration example” on page 157 provides a simple
    example of the configuration process, including a basic testing procedure.
“Part III: Windows Configurations” describes how to create Windows configura-
tions:
●   The chapter “Configuring Windows applications” on page 195 describes
    how to configure Windows applications and services with the Windows
    Application Control Interface.
“Part IV: Reference” provides an introduction to PCS and major functions in the
PCS interface:
●   The chapter “Appendix—Site preparation” on page 223 describes network
    and file settings required for ASCC operation.
●   The chapter “Appendix—NFS file system notes” on page 235 provides infor-
    mation about NFS servers and clients in the ASCC environment.
●   The chapter “Appendix—Object types” on page 239 lists the object types
    that are supplied with ASCC.
●   The chapter “Appendix—Attributes” on page 241 lists the attributes that are
    supported by ASCC object types.




2                                                            U42147-J-Z100-4-76
Preface                                              ASCC documentation list


1.2       ASCC documentation list
The documents listed below provide details about ASCC products. Please
contact your sales representative for ordering information. Books can be
ordered via the Internet shop www.fsc-manualshop.com.
●   Release notices for all products—These documentation files are included
    as HTML files on the ASCC CD. Release notices provide late-breaking infor-
    mation about installation, configuration, and operation. Read this infor-
    mation first.
●   ASCC Adaptive Services Control Center (Linux, Windows) User
    Guide—Describes how to install, configure, and administer Adaptive
    Services Control Center control and satellite nodes.
●   ASCC PCS for Adaptive Services Control Center (Linux, Windows) Configuration
    Guide—Describes how to use PCS (PRIMECLUSTER Configuration
    Services) to configure application monitoring for Adaptive Services Control
    Center.
●   Reliant Monitor Services (RMS) (Linux, Solaris) Reference Guide—Describes
    operational principles and diagnostic procedures for the RMS high avail-
    ability manager, including how to view and interpret RMS log files. Provides
    a list of all RMS error messages with a probable cause and suggested action
    for each condition.
●   ASCC Adaptive Services Control Center (Linux, Windows) Site Preparation
    Technical Note—Provides instructions for site preparation and installation of
    ASCC. Available from field support. This document is updated as new infor-
    mation becomes available, so the version on the ASCC CD may not address
    some recent issues. You can obtain the most recent version from your ASCC
    representative.




U42147-J-Z100-4-76                                                             3
Conventions                                                             Preface


1.3       Conventions
To standardize the presentation of material, this manual uses a number of
notational, typographical, and syntactical conventions.


1.3.1     Notation

This manual uses the following notational conventions.

1.3.1.1   Prompts

Command line examples that require system administrator (or root) rights to
execute are preceded by the system administrator prompt, the hash sign (#).
Entries that do not require system administrator rights are preceded by a dollar
sign ($).
In some examples, the notation <nodename># indicates a root prompt on the
specified node. For example, a command preceded by bxsat1# would mean
that the command was run as user root on the node named bxsat1.

1.3.1.2   Manual page section numbers

References to operating system commands are followed by their manual page
section numbers in parenthesesfor example, cp(1).

1.3.1.3   The keyboard

Keystrokes that represent nonprintable characters are displayed as key icons
such as [Enter] or [F1]. For example, [Enter] means press the key labeled Enter;
[Ctrl-b] means hold down the key labeled Ctrl or Control and then press the [B]
key.

1.3.1.4   Typefaces

The following typefaces highlight specific elements in this manual.




4                                                             U42147-J-Z100-4-76
Preface                                                            Conventions


Typeface             Usage
Constant             Computer output and program listings; commands, file
Width                names, manual page names and other literal programming
                     elements in the main body of text.
Italic               Variables in a command line that you must replace with an
                     actual value. May be enclosed in angle brackets to
                     emphasize the difference from adjacent text, e.g.,
                     <nodename>RMS. Unless directed otherwise, you should not
                     enter the angle brackets.

                     The name of an item in a character-based or graphical user
                     interface. This may refer to a menu item, a radio button, a
                     checkbox, a text input box, a panel, or a window title.
Bold                 Items in a command line that you must type exactly as
                     shown.


Typeface conventions are shown in the following examples.

1.3.1.5      Example 1

Several entries from an /etc/passwd file are shown below:
root:x:0:1:0000-Admin(0000):/:/sbin/ksh
sysadm:x:0:0:System Admin.:/usr/admin:/usr/sbin/sysadm
setup:x:0:0:System Setup:/usr/admin:/usr/sbin/setup
daemon:x:1:1:0000-Admin(0000):/:

1.3.1.6      Example 2

To use the cat(1) command to display the contents of a file, enter the following
command line:
$ cat file




U42147-J-Z100-4-76                                                             5
Important notes and cautions                                               Preface


1.3.2     Command line syntax

The command line syntax observes the following conventions.

Symbol      Name             Meaning
[]          Brackets         Enclose an optional item.
{}          Braces           Enclose two or more items of which only one is
                             used. The items are separated from each other by
                             a vertical bar (|).
|           Vertical bar     When enclosed in braces, it separates items of
                             which only one is used. When not enclosed in
                             braces, it is a literal element indicating that the
                             output of one program is piped to the input of
                             another.
()          Parentheses      Enclose items that must be grouped together when
                             repeated.
...         Ellipsis         Signifies an item that may be repeated. If a group
                             of items can be repeated, the group is enclosed in
                             parentheses.


1.4       Important notes and cautions
Material of particular interest is preceded by the following symbols in this
manual:
I       Contains important information about the subject at hand.


V       Caution
        Indicates a situation that can cause harm to data.




6                                                               U42147-J-Z100-4-76
Part I: Basics




U42147-J-Z100-4-76
2          Introduction
This chapter contains general information on Adaptive Services Control Center
(ASCC), introduces the PRIMECLUSTER family of products, details how ASCC
and PCS work together to produce high-availability configurations, and intro-
duces Cluster Admin.
Chapter contents:
●   “ASCC overview” on page 9
●   “How ASCC provides high availability” on page 10
●   “How PCS provides easy configuration” on page 16
●   “ASCC components” on page 17
●   “Object types” on page 20
●   “Object attributes” on page 21
●   “Environment variables” on page 21
●   “ASCC Directory structure” on page 22


2.1        ASCC overview
This manual focuses on ASCC products and services that relate to high avail-
ability operation. They are as follows:
●   ASCC high availability manager—This is a software monitor that provides
    high availability (HA) for customer applications in a cluster of nodes. Its task
    is to monitor systems and application resources, to identify any failures, and
    to provide application availability virtually without interruption in the event of
    any such failures.
    ASCC also provides integrated services for market-specific applications.
    See your sales representative for availability and details.
    I The ASCC high availability manager is also known as Reliant Monitor
           Services (RMS).
●   PRIMECLUSTER Configuration Services (PCS)—This configuration tool
    provides a graphical interface to create ASCC configurations. It includes
    templates for generic applications and commonly used resources.



U42147-J-Z100-4-76                                                                   9
How ASCC provides high availability                                      Introduction


     The PCS Wizard Kit works with PCS to configure popular enterprise
     products for ASCC operation.


2.2        How ASCC provides high availability
ASCC provides high availability of a customer’s application by controlling and
monitoring the state of all resources in use by a given application. Resources
include items such as network interfaces, local and remote file systems, and
storage area networks. RMS also monitors the state of each host in the cluster.


2.2.1      Applications, resources, and objects

ASCC relies on a virtual representation of the cluster called a configuration.
The configuration represents each machine, application, and system resource
as an object, and the objects are logically arranged in a tree structure according
to their dependencies. For instance, suppose a user application depends on a
network interface and a file system in order to operate properly. In the tree
structure, the corresponding application object would appear as a parent and
the network and file system objects would appear as its children. The tree
structure is commonly known as a graph.
Each object in the graph contains the state of the corresponding item along with
any other parameters that may be required. An object is typically in the online
(enabled, available) state or the offline (disabled, unavailable) state, but other
states are possible according to the type of object.
At runtime, the configuration is managed by the ASCC base monitor, which
initiates actions when an object’s state changes, or, in the case of a timeout,
when an object has remained in the same state for some specified time interval
even though a change was expected. This design is known as a state machine.

Nodes and heartbeats
Machines that are members of a cluster are called nodes. When RMS monitors
the health of a node, its highest priority is to detect a complete failure of the node
or its base monitor. Its second priority is to detect slow response times that may
be caused by system overloads.
RMS transmits a UDP heartbeat signal at regular intervals. If the elapsed time
since the last heartbeat from a node exceeds an adjustable connection timeout,
RMS assumes the node has lost connectivity. RMS then begins a recovery



10                                                                 U42147-J-Z100-4-76
Introduction                              How ASCC provides high availability


period for the node. If the node heartbeat is detected during the recovery period,
RMS assumes the node is functional and returns it to normal status. However,
if RMS receives no heartbeats from the node before the recovery period
expires, it assumes the node is down, even if other communication with the
node is possible.
Once RMS marks a node as down, it takes a series of steps to ensure appli-
cation and cluster integrity. First, it is necessary to ensure that the node is truly
shut down. Otherwise, the node and its applications could unexpectedly recover
later, causing conflicts and data corruption. To avoid these problems, RMS
directs the Shutdown Facility (described later) to eliminate the node. This is
often done by rebooting the node or turning off its power, but the exact action
depends on which shutdown agents have been configured for the node. Only
after the node has been eliminated is it safe for RMS to restart the node’s appli-
cations elsewhere in the cluster. The process of automatically switching appli-
cations from a failed node to a healthy node is called application failover.
Application switchover impacts cluster performance, so it is important to choose
a recovery timeout that avoids false detection of node outages. The optimum
UDP recovery time depends on the conditions in the cluster. A short recovery
period is the best choice to deal with failures of nodes or base monitors.
However, a long recovery period allows time for overloaded nodes to respond,
which avoids unnecessary shutdowns.

Detectors
ASCC monitors each resource by using detectors, which are processes that
deliver status reports to the ASCC base monitor process. ASCC interprets the
status reports to determine the state of the corresponding virtual object. When
an object’s state changes, ASCC takes action according to the parameters set
in the object. Each object may be associated with a detector.
Detectors are persistent: when ASCC starts on a cluster node it starts the
detectors for its configuration, which normally continue to run on that node until
ASCC is shut down. ASCC has the ability to restart a detector if it terminates
prematurely.
A complete list of the states that can be reported by detectors or displayed in
the user interface is presented later in this chapter.




U42147-J-Z100-4-76                                                                11
How ASCC provides high availability                                 Introduction


Scripts
Each object type has an associated set of scripts. A script is a command string
(possibly including pipes, redirection, command interpolation, and variable
substitution) that can be executed by the operating system shell—in other
words, a valid shell script. Normally, each script is designed to interact with
items in the operating system such as user applications or physical resources.
Scripts provide the only means for ASCC to directly influence items outside its
virtual representation.
Some scripts are reactive: they define the actions that ASCC should take in
response to state changes. Other scripts are proactive: they define the actions
that ASCC should use to take control of individual objects. For instance, ASCC
would process one script when a resource reports a transition from the online
state to the offline state; however, ASCC would process a different script when
it must force the resource to the offline state.
Scripts are transient: after performing their programmed tasks, they exit and
return a status code to the base monitor.
A complete list of the scripts that may be specified for ASCC objects is
presented later in this chapter.

Object types
Most high-availability applications rely on a set of physical resources such as
network interfaces, files systems, or virtual disks. ASCC represents these as
gResource objects. Most gResource objects have scripts that allow them to be
brought online or taken offline.
Internally, ASCC represents an actual application that runs in the operating
system environment as a satApplication object. The set of gResource
objects that represent the actual application’s resource requirements are called
its dependent resources. Bringing a satApplication object to the online
state, along with all of its dependent resources, is called online processing.
Taking a satApplication object to the offline state, along with all of its
dependent resources, is called offline processing.
Each node that may run one or more applications in the high availability config-
uration is represented by an ASCC SatNode object. Like gResource objects
and satApplication objects, SatNode objects can be brought online or taken
offline, and they have an associated set of scripts. However, booting up or
shutting down the corresponding physical machine requires more than simple
script processing.




12                                                            U42147-J-Z100-4-76
Introduction                               How ASCC provides high availability


A complete list of the ASCC object types supported by PCS is presented in the
chapter “Appendix—Object types” on page 239.

Shutdown Facility
While scripts and detectors provide a direct interface between ASCC and the
operating system, the Shutdown Facility (SF) provides an indirect interface to
the machines in the cluster. When it necessary to take a SatNode object offline,
ASCC works with the SF to guarantee that the corresponding node has been
physically shut down, or killed. ASCC waits for successful completion of the
node kill before switching any satApplication from the offline SatNode to
another SatNode. This prevents any user application from running on two
machines at the same time, which could lead to data corruption.
For more information about the Shutdown Facility, see the PRIMECLUSTER
Cluster Foundation (CF) Configuration and Administration Guide.


2.2.2      Relationship of ASCC configurations to the real
           world

It is important to understand that ASCC does not interact directly with “real-
world” items such as machines, users’ applications, or system resources—it
interacts only with the objects in its virtual representation. figure 1 illustrates the
relationship between an actual user application in the operating system
environment and the corresponding satApplication object in an ASCC
configuration.




U42147-J-Z100-4-76                                                                  13
How ASCC provides high availability                                                       Introduction



                                           satApplication
                                                object
  ASCC configuration




                                         ASCC base monitor

                           detector                    script            script
                             status                   status             execution
                             codes                    codes              control

                                detector
                                                                script
                                process
  Operating system




                           application                          application
                                status                          control


                                           User application


Figure 1: Interface between ASCC and the operating system

Note that the interface between the ASCC virtual representation and the actual
operating system depends entirely on the scripts and detectors provided by the
configuration tools. The script in the figure represents any of the standard
scripts discussed later in this chapter: it reports whether or not it completed its
tasks successfully by returning a status code, and ASCC combines this with the
status code from the object’s detector to determine the object’s state. ASCC has
no other way to determine what actually happened to the user application in the
operating system environment (the part of the figure below the dashed line).
For instance, if a satApplication object’s Online script reports success, its
detector reports that it is online, and all of its resources are online, then ASCC
considers that object to be online, regardless of the state of the actual user
application. Similarly, if a resource object’s detector reports an Offline state,
it does not necessarily mean that the physical resource is unavailable.
I For reliable high availability operation, ASCC requires scripts that
                       properly control the corresponding real world items, and detectors that
                       accurately reflect the items’ states.




14                                                                                   U42147-J-Z100-4-76
Introduction                               How ASCC provides high availability


Configuration terminology
This manual discusses configuration procedures within the ASCC context
(represented by the part of figure 1 above the dashed line). Strictly speaking,
our principle concern is with SatNode objects, satApplication objects, and
other ASCC entities, and not the real-world items they represent.
However, it is intuitive to use terms such as “node” instead of “SatNode object”
and “application” instead of “satApplication object,” because the relation-
ships are so close, and because it is always understood we are working from
the ASCC perspective. This also helps to simplify many of the technical discus-
sions. Therefore, unless there is a need to distinguish between an ASCC object
and the actual item it represents, this manual and the configuration tools it
describes use the following terms interchangeably:
●   “node” and “SatNode object” and “SatNode”
●   “application” and “satApplication object” and “satApplication”
●   “resource” and “gResource object” and “gResource”
The descriptions of object states and attributes are abbreviated similarly. For
instance, instead of “the gResource object named xyz is in the Offline state,”
it is customary to say, “the xyz file system is offline.” It is also common to refer to
a script by its attribute name, so “the script specified by the PreOnlineScript
attribute” becomes simply “the PreOnlineScript.”


2.2.3      Node and application failover

During normal operation, one instance of ASCC runs on each node in the
cluster. Every instance communicates with the others to coordinate the actions
configured for each satApplication. If a node crashes or loses contact with
the rest of the cluster, then ASCC can switch all satApplication objects from
the failed node to a surviving node in the cluster. This operation is known as
failover.
Failover can also operate with individual applications. Normally, a
satApplication object is allowed to be online on only one node at a time.
(Exceptions to this rule are shared objects like Oracle RAC vdisk.) If a fault
occurs within a resource used by a satApplication object, then only that
satApplication can be switched to another node in the cluster.
satApplication failover involves offline processing for the object on the first
node, followed by online processing for the object on a second node.




U42147-J-Z100-4-76                                                                  15
How PCS provides easy configuration                                    Introduction


There are also situations in which ASCC requires a node to be shut down, or
killed. In any case, before switching applications to a new node, ASCC works
together with the ASCC Shutdown Facility to guarantee that the original node is
completely shut down. This helps to protect data integrity.
ASCC also has the ability to recover a resource locally; that is, a faulted
resource can be brought back to the online state without switching the entire
satApplication to another cluster node.


2.3        How PCS provides easy configuration
ASCC is a mature product with many features and options. Experts who
develop, debug, and fine tune complete ASCC configurations must know how
ASCC works and what ASCC needs in order to function properly. For each
application in the configuration, the expert must do the following:
●    Define the set of resources used by the application, including:
     – Disks
     – Volume managers
     – File systems
     – processes to be monitored
     – IP addresses
●    Define the relationship between each resource and its dependent resources,
     e.g., which file system depends on which virtual or physical disk, which
     processes depend on which file systems, and so forth.
●    Define the relationship between the applications being controlled; for
     example, which applications must be up and running before others are
     allowed to start.
●    Provide scripts to bring each resource online and offline.
●    Provide a detector to determine the state of each resource.
Configuring the above set of requirements by hand can be quite time consuming
and prone to errors. This is why PCS was developed.




16                                                                U42147-J-Z100-4-76
Introduction                                               ASCC components


PCS allows the creation of flexible and quality-tested ASCC configurations while
minimizing your involvement. A simple user interface prompts you for details
regarding your applications and resources. Using these details, PCS selects the
proper scripts and detectors and combine them in a pre-defined structure to
produce a complete ASCC configuration.
Specialists skilled in popular applications and in ASCC worked together to
create PCS. The templates are designed to easily configure ASCC for certain
popular applications such as Oracle or SAP R/3, and they are flexible enough
to create custom ASCC configurations that can control any other type of appli-
cation.


2.4       ASCC components
The ASCC product is made up of the following software components that run on
each node in the cluster:
●   Base monitor
●   Detectors
●   Scripts


2.4.1     Base monitor

The base monitor process is the decision-making segment of the ASCC
process group. It has the following functions:
●   Stores the current configuration of resources as represented by objects,
    their attributes, and their interdependent relationships
●   Receives user requests for specific actions from the Cluster Admin graphical
    user interface (GUI) or the ASCC command line interface (CLI)
●   Monitors the heartbeat from every node to keep track of each machine’s
    status and its connectivity to the rest of the cluster
●   Receives input from detectors and monitors state changes
●   Launches scripts to bring applications and their dependent resources
    Online or Offline
●   Dictates the sequencing of the resource state changes to ensure resources
    and applications are brought Online or Offline in the correct order



U42147-J-Z100-4-76                                                             17
ASCC components                                                       Introduction


●    Initiates and controls automatic application switchover in case of a resource
     or node failure, or when directed by a user request
●    Performs various administrative functions


2.4.2      Detectors and states

Detectors are independent processes that monitor specific sets of resources in
order to determine their state. The detector does not determine if the current
state of a resource is the correct state or not (for example, if a resource is
Offline but is supposed to be Online)—that is the role of the base monitor.
Detectors can report the following states to the base monitor:

Faulted               Error condition encountered. The error may have occurred
                      in the resource, in one of its children, or during script
                      processing.
Offline               Disabled, not ready for use. The scripts have successfully
                      disabled the resource.
Online                Enabled, ready for use. All required children are online,
                      and no errors were encountered while scripts were
                      processed.
Standby               Ready to be quickly brought Online when needed.
The following resource states may also be displayed in the GUI status area:

Deact                 Applies to satApplication objects only. Operator inter-
                      vention has deactivated the application throughout the
                      cluster (such as for maintenance purposes).
Inconsistent          Applies to satApplication objects only. The object is
                      Offline or Faulted, but one or more resource objects in
                      its graph have their ClusterExclusive attribute set to 1
                      and are Online or Faulted.
OfflineFault          Fault that occurred in the past has not yet been cleared.
Unknown               No information is available. Reported before object initial-
                      ization is completed.




18                                                              U42147-J-Z100-4-76
Introduction                                                ASCC components


Wait                 Temporarily in transition to a known state. An action has
                     been initiated for the affected resource, and the system is
                     waiting for the action to be completed before allocating
                     one of the above states.
Warning              Some warning threshold has been exceeded.
Maintenance          Manual, temporary mode of operation in which the state of
                     an application is decoupled from the states of its
                     dependent resources. This allows, for example, a file
                     system to be taken offline for backup without disturbing the
                     state of its parent application.
                     An application in maintenance mode is usually marked
                     with its intended state, which is the state that would be
                     attained if the application were immediately taken out of
                     maintenance mode. The maintenance mode intended
                     states are Maintenance-Online, Maintenance-
                     Offline, and Maintenance-Standby.
The interpretation of Offline and Faulted may depend on the resource type.
For instance, a mount point resource can be either Online (mounted) or
Offline (not mounted); in this case, the detector would never report the
Faulted state. On the other hand, a detector for a physical disk can report
either Online (normal operation) or Faulted (input or output error); it would
never report Offline.
Detectors for common system functions are provided by PCS. Additional appli-
cation-specific detectors are included with the PCS Wizard Kit.


2.4.3     Scripts

ASCC uses scripts to perform actions such as moving a resource from one state
to another (for example, from Offline to Online). The two types of scripts are
as follows:
●   Request-triggered scripts initiate a state change to a resource.
    The request-triggered scripts are as follows:
    – InitScript —Runs only once when ASCC is first started
    – PreCheckScript—Determines if Online or Standby processing is
      needed or possible
    – PreOfflineScript—Prepares a transition to an Offline state


U42147-J-Z100-4-76                                                             19
Object types                                                       Introduction


     – OfflineScript—Transitions a resource to an Offline state
     – PreOnlineScript—Prepares a transition to an Online state
     – OnlineScript—Transitions a resource to an Online state
●    State-triggered scripts react to specific events.
     The state-triggered scripts are as follows:
     – PostOnlineScript—Reaction to the transition to the Online state
     – PostOfflineScript—Reaction to the transition to the Offline state
     – OfflineDoneScript—Reaction to a satApplication reaching the
       Offline state
     – FaultScript—Reaction to a resource transitioning to the Faulted
       state
     – WarningScript—Reaction to a detector reporting the Warning state
     – AppStateScript—Reaction to a state change by a satApplication
Scripts for common system functions are included with the subapplications
provided by PCS.


2.5          Object types
An object type represents a group of similar resources that are monitored by the
same detector (for example, all disk drives). Using PCS, you can create config-
uration files that contain objects of various types, each representing resources
or groups of resources to be monitored by ASCC. The supported types are as
follows:
●    SatNode
●    satApplication
●    gResource
●    andOp
●    orOp
Refer to the chapter “Appendix—Object types” on page 239 for the supported
types, their required attributes, and a description of each object.




20                                                           U42147-J-Z100-4-76
Introduction                                                     Object attributes


I This information is provided for reference only. These objects are created
       by PCS during the generation phase of the configuration process. The
       type of an object may be listed in diagnostic messages for use by ASCC
       experts.


2.6       Object attributes
An attribute is the part of an object definition that specifies how the base monitor
acts and reacts for a particular resource during normal operation. An attribute
can include a device name and configuration scripts. Users can specify
attributes in any order in the object definition.
Refer to the chapter “Appendix—Attributes” on page 241 for the supported
types, their associated values, and a description of each attribute.
I This information is provided for reference only. The values are deter-
       mined by PCS during the generation phase of the configuration process.


2.7       Environment variables
ASCC uses global and local environment variables:
●   Global variables generally control clusterwide operations and must have the
    same setting on all nodes in the cluster. At runtime, ASCC maintains global
    environment variables in the ENV object.
    I Global variable settings (ENV) are included in the configurations
          checksum that is common to the cluster. The checksum is verified on
          each node during startup of the base monitor. ASCC will fail to start
          if it detects a checksum difference between the values on any two
          nodes.
●   Local variables can differ from node to node. ASCC maintains local
    environment variables in the ENVL object.
    I Local variable settings (ENVL) are not included in the configurations
          checksum that is common to the cluster.
ASCC creates the ENV and ENVL objects dynamically when the base monitor
starts up:
1. First, it loads global and local variables from the
   <RELIANT_PATH>/bin/hvenv file, which is installed with the package.


U42147-J-Z100-4-76                                                               21
ASCC Directory structure                                              Introduction


     V Caution
           Do not modify the <RELIANT_PATH>/bin/hvenv file.
2. Next, it loads both global and local variables from the
   <RELIANT_PATH>/bin/hvenv.local file, which contains configuration-
   specific variables that are typically set by PCS. These settings override the
   installation defaults. Experts may change the contents of this file manually
   with a standard text editor. In any case, changes to the hvenv.local file will
   not take effect until the next ASCC startup.
I The RELIANT_PATH global variable is defined at installation. By default,
  it is set to /opt/SMAW/SMAWRrms.
I A /tmp directory that is nearly full may result in ASCC errors, because
        the base monitor uses the sort(1) command to sort ASCC environment
        variables.


2.7.1      Script execution environment variables

When the ASCC invokes a script on behalf of an object, it provides a set of
variables in the script’s environment that can be used for decision processing at
runtime. Since these variables exist only within the context of the script while it
is carrying out its tasks, they are not usually visible in the ASCC user or admin-
istrator environment. In rare cases, they could appear in a diagnostic message
in the system log or on the console.


2.8        ASCC Directory structure
ASCC software consists of a number of executables, scripts, files, and
commands, all located relative to the directory specified in the RELIANT_PATH
environment variable. table 1 illustrates the directory structure of the ASCC
software after it has been correctly installed.




22                                                              U42147-J-Z100-4-76
Introduction                                             ASCC Directory structure




 Name                                    Contents
 RELIANT_PATH                            Base directory. Default:
                                         /opt/SMAW/SMAWRrms
 <RELIANT_PATH>/bin                      Executables, including detectors,
                                         commands, and scripts.
 <RELIANT_PATH>/build                    Work and storage area for configuration
                                         files.
 <RELIANT_PATH>/etc                      Miscellaneous files used by ASCC and the
                                         configuration tools.
 <RELIANT_PATH>/include                  ASCC include files (header files) used by
                                         detectors and configuration files.
 <RELIANT_PATH>/lib                      ASCC runtime libraries.
 <RELIANT_PATH>/us                       ASCC source files. The names of the files
                                         in this directory are reserved and should
                                         not be used to name any configuration files
                                         that the user may create.
Table 1: ASCC base directory structure


As summarized in table 2, ASCC log files are located in the directory specified
in the RELIANT_LOG_PATH environment variable.



 Name                                    Contents
 RELIANT_LOG_PATH                        Contains files that can be used for ASCC
                                         analyzing and debugging. The base
                                         monitor and detectors create log files here.
                                         Default: /var/opt/SMAWRrms/log
                                         The same directory has subdirectories that
                                         contain backup copies of the ASCC log
                                         files. Each backup subdirectory has a name
                                         of the form yyyy-mm-dd_HH:MM:SS to
                                         indicate the date and time when the backup
                                         was created.
Table 2: Log directory structure




U42147-J-Z100-4-76                                                                 23
3         PCS configuration basics
This chapter describes how to configure customer applications for high avail-
ability using the PRIMECLUSTER Configuration Services graphical user
interface (PCS-GUI) for RMS.
Chapter contents:
●   “Introduction” on page 25 gives a brief description of PCS.
●   “Basic PCS concepts” on page 29 discusses application and subapplication
    templates, describes the hierarchy, and provides an overview of the PCS
    GUI.
●   “PCS directory structure” on page 36 describes the organization of PCS files
    and directories.
●   “Commonly used PCS terms” on page 40 summarizes important PCS
    terms.
The information in this chapter is also available online through the PCS HELP
facility.


3.1       Introduction
PRIMECLUSTER Configuration Services (PCS) is used to create configura-
tions that run under the control of Adaptive Services Control Center (ASCC).
ASCC checks that the various components are functioning, switches applica-
tions to alternate nodes in the event of resource failure, or initiates recovery
actions by correcting faults.


3.1.1     Overview of PCS

PCS assembles the components of the applications into an ASCC application
monitoring configuration for the customer-specific computing environment and
mission critical application. PCS collects the user inputs based on the appli-
cation and subapplication templates; these user inputs are needed to configure
and monitor the various components for such a high-availability application.
PCS provides the following capabilities through a graphical user-interface
(GUI):
●   Simplifies the process of creating ASCC configurations


U42147-J-Z100-4-76                                                             25
Introduction                                             PCS configuration basics


●    Guides the user through the process of selecting the components of the
     configuration and prompts for specific information needed by these compo-
     nents
●    Assists in grouping the components into a logical sequence
●    Includes templates, detectors, scripts used to create ASCC configurations.
The primary task of PCS is to simplify the process of creating ASCC application
monitoring configurations. This is accomplished by modelling how commercial
and custom software packages and common system components in combi-
nation with ASCC are configured for high availability. These models are created
in a form that can be later customized for a customer’s specific requirements.
Templates are used to define these models. The customized templates are
converted into ASCC configuration files.
A template that defines an entire ASCC application is referred to as an appli-
cation template. A template that defines a branch of an ASCC application is
referred to as a subapplication template. An application template models how
a particular software product, e.g., SAP or Oracle, is to operate. An application
template normally references many subapplication templates. A subapplication
models various components, e.g., a portion of a software product, a system
service such as NFS, or a hardware component such as a network interface
The major components of PCS are as follows:
●    The templates, which are discussed in subsequent sections of this chapter.
●    The user interface, which collects and displays user input data according to
     the design of the selected template. By default, the interface checks all data
     for consistency as it is input, so you can see missing information or potential
     problems as early as possible. In the event of serious problems, PCS will
     prevent you from distributing the configuration. Subsequent chapters in this
     manual describe each portion of the user interface.
●    Detectors and scripts, which monitor and control the various components
     of the configuration. PCS provides detectors and scripts for every object in
     the standard templates, so you do not have to be concerned with configu-
     ration details at this level. Most detectors and scripts can be customized to
     meet the needs of unusual operating conditions, although this usually
     requires expert knowledge of ASCC.
●    The configuration engine, which processes the user input data, templates,
     detectors, and scripts to generate ASCC configurations. When you invoke
     this component with a simple mouse click in the PCS user interface, it
     operates completely behind the scenes. In most cases, it completes its work



26                                                               U42147-J-Z100-4-76
PCS configuration basics                                               Introduction


   and notifies you of the result within a few seconds. In the event of an error,
   it displays diagnostic messages in the PCS interface that point to the cause
   of the problem.


3.1.2      Application templates

A PCS application template represents a skeleton for a user application and all
of the components it depends on. To illustrate the concept of dependency,
consider a network service. Most network services are accessed through an IP
address that is assigned to a network interface. If the network interface fails, the
service is not available. This means that the service depends on the IP address
(or equivalently the network interface) for high availability.
In general, a software application can depend on numerous hardware and
software components. The failure of some components may cause the appli-
cation to become completely unavailable, while the failure of other components
may only inhibit the application’s performance or make it less fault-tolerant. For
example, if a partition in a mirrored disk fails, an application that depends on it
will continue to function, but it will be at greater risk of becoming unavailable. To
maintain true high availability, an administrator must be notified so that the failed
disk can be replaced.
PCS application templates allows you to create ASCC configurations that can
monitor many types of standard components. When some components fail or
partially fail, PCS can configure ASCC to execute a program to repair the failed
component. Some failures, e.g., the failure of a node, will cause an application
and all its components to switch to an alternate node. PCS also has a facility to
configure RMS so that it alerts an operator in the event of specific component
failures, as in the example of the failed disk presented above.


3.1.3      Subapplications

An application template contains a number of subapplications in a pre-defined
structure that determines the dependency relationships. Each subapplication is
designed to configure a specific resource type. PCS provides subapplications
to control and monitor devices such as network interfaces, local file systems,
remote file systems, raw disks, volume managers, and storage managers. In
addition, the CommandLine subapplication controls an arbitrary process via shell
commands.




U42147-J-Z100-4-76                                                                27
Introduction                                           PCS configuration basics


Each subapplication provides its own part of the overall template structure, and
it includes pre-defined detectors and scripts designed specifically for the
resource it configures. As described earlier, you do not have to be concerned
about these internal details. PCS automatically inserts the correct objects and
definitions into the configuration, incorporating the data you specify in the user
interface.
You can create one or more instances of a subapplication, where each
instance contains its own copy of the data you specify. A satApplication
object can depend on multiple instances of a subapplication. For example, an
application usually depends on several file systems. The application will
typically contain one file system subapplication but will have several file
systems. A file system subapplication template lets the user create multiple
instances of file systems.


3.1.4     Resources

Resources are the building blocks of a subapplication. A group of resources
represent a subapplication template. A subapplication can have more than one
instance of a resource. File system mount points and network interfaces are
resources used by subapplications. An occurrence of a resource in a subappli-
cation template is known as instance. There could be several instances of a
resource. For example, a Banking application could consist of a Teller software
subapplication and a Database subapplication. The Database subapplication
would include resources such as mount-points for the database file systems
and Ethernet network interfaces. If there are multiple database file systems to
be mounted, then these mount points are known as instances.


3.1.5     Application dependencies

A satApplication object’s dependent components must be arranged in a
specific order. A file system for example, may reside on an external storage
device. The file system thus depends on the external storage device. In this
case, when RMS brings the file system online, it must first configure the external
storage device and then configure the file system.
PCS provides the flexibility of stepping the user through dependencies in an
orderly manner. There are options to choose between predetermined depen-
dencies and building specific dependencies. The arrangement of these depen-




28                                                             U42147-J-Z100-4-76
PCS configuration basics                                    Basic PCS concepts


dencies is referred to as the “ASCC graph hierarchy” or simply the “graph”. The
graph of a running ASCC configuration can be displayed from the Cluster Admin
rms&pcs tab. This display also shows the state of the resources.
A mission critical system consists of one or more satApplication objects.
The entire set of mission critical application is created as a single configuration
that is managed by ASCC as a single unit. Only one configuration can be
assigned to a task group. However, multiple task groups, each running its own
configuration, can coexist simultaneously in the ASCC cluster.
PCS produces an ASCC configuration file with a .us extension; this file is also
referred to as the .us file.
Each instance of a subapplication is usually represented in the ASCC configu-
ration file as a set of unique resources.


3.2       Basic PCS concepts
A PCS configuration consists of applications, subapplications, resources and
instances. Subapplications are composed of one or more resources. application
and subapplication templates are used to build the configuration. All the config-
uration information is stored in the Config directory under the configuration
name. Finally when a configuration is generated, the configuration file
<configuration_name>.us is created. Subsequently, the configuration must be
activated to deploy the applications under ASCC.


3.2.1     Hierarchy of applications and subapplications

figure 2 depicts the hierarchy of a configuration. A configuration consists of one
or more applications. Each application could be made up of one or more subap-
plications. The subapplication consists of other subapplications or resources.
Occurrences of the same resource are known as Instances. For example, there
may be one more instance of a mount-points resource. The subapplications
could be dependent or independent of each other.




U42147-J-Z100-4-76                                                              29
Basic PCS concepts                                            PCS configuration basics




                              PCS Configuration


                                                      Application2
               Application1

                                              Sub-App1           Sub-App2



                                                     Resource




                                                                              pcs0301
Figure 2: Hierarchy of Applications and subapplications



3.2.2      Template types

In PCS, you create configurations by using resources, such as file systems,
network addresses, or disk volumes, to build subapplications. The subapplica-
tions are logically grouped into a tree structure to provide support for your appli-
cation. Arranging the subapplications correctly in parent-child relationships is a
complex task. The process is simplified by templates that configure applications
for ASCC. PCS provides the following application templates:
●    Custom
●    Generic
The following sections describe the features of each template.


3.2.3      Custom application templates

PCS provides Custom application templates for specific, commonly-used appli-
cations. Each Custom template automatically arranges all the resources into
subapplications, which are then organized into predetermined relationships.




30                                                                   U42147-J-Z100-4-76
PCS configuration basics                                 Basic PCS concepts


Custom templates for widely used enterprise applications are available as
PRIMECLUSTER PCS Wizards. See your sales representative for more infor-
mation about the following products:
●   PCS mySAP Wizard for ASCC
●   PCS SRI Wizard for ASCC
●   PCS DBMS Wizard for ASCC
●   PCS Webserver Wizard for ASCC
Because the resource types and dependency structure are completely
predefined in a Custom template, you cannot change the list of resource types,
nor can you change their relationships. If a custom template does not match
your requirements, you can configure your application with the Generic
template. Experts and consultants can create application-specific wizards with
the FreeForm template (the description of the FreeForm template is beyond the
scope of this document).


3.2.4     Generic application template

The Generic application template provides more flexibility. When you configure
an application using the Generic template, you can use the pre-defined
CommandLine, Ip Address, Local File System, RawDisk, and Remote File System
subapplications. The template also contains subapplications for various volume
and storage managers, including LVM. These are automatically enabled if the
corresponding disk manager is installed on your system.
Generic applications free the user from defining parent-child relationships for
subapplications, because the basic configuration plan for every Generic appli-
cation is the same. figure 3 represents the relationship.




U42147-J-Z100-4-76                                                           31
Basic PCS concepts                                           PCS configuration basics




                                      CommandLine




           LocalFileSystem       RawDisk                      RemoteFileSystem




                          LVM                                    IpAddress




                                           VirtualHostName

                                                                                 asw0301
Figure 3: Typical GENERIC application structure

You may configure only the subapplications you require while ignoring the
others, and you can include multiple instances of any subapplication. However,
the parent-child dependencies will always conform to the structure shown
above. Note that a volume manager subapplication such as LVM is a child of
both the Local File System and Raw Disk subapplications.
The structure illustrated above has been simplified to show only the relation-
ships between the subapplications. PCS also includes the following items in the
actual configuration:
●    Dependencies from the parent application to child subapplications
●    Various connector objects and dependencies to maintain the correct
     relationships when some of the subapplications are not configured
After you create and activate a configuration, you can view the complete appli-
cation graph.
●    In PCS, select Tools –> Draw graph from the menu.
●    In the ASCC GUI, select View –> Satellite Graphs from the menu, and then
     select the desired satellite node from the popup dialog.
figure 4 shows a PCS graph for a typical Generic application.




32                                                                  U42147-J-Z100-4-76
PCS configuration basics                                  Basic PCS concepts




                                                                asw0302
Figure 4: Configuration graph for a Generic application

Note that each subapplication creates a sub-graph that is a part of the overall
application graph.


3.2.5       Comparison of application types

Applications built with the Custom template use a pre-defined set of subappli-
cations with pre-defined dependencies, according to the wizard employed. They
have been developed and tested for standard application configurations, so they
maximize robustness and ease-of-use. However, they provide the least flexi-
bility.




U42147-J-Z100-4-76                                                           33
Basic PCS concepts                                       PCS configuration basics


Applications built with the Generic template offer more flexibility as they allow
any combination of subapplication templates; however, their dependency
relationship is pre-defined. You may choose to ignore or discard subapplications
that are not needed, but the dependency cannot be modified.
Applications built with the FreeForm template offer the most flexibility by
allowing combination of subapplication templates with any dependency
structure you desire. However, these are the most difficult to configure, and a
high level of expertise may be required to produce a robust configuration. For
these reasons, most ASCC configurations are designed using Generic or
Custom application templates.


3.2.6       Subapplication templates

Each application wizard includes a pre-configured set of subapplications.
Generic applications allow the user to pick and choose from the following set of
base subapplications.
●    CommandLine—General-purpose subapplication that executes user-
     specified commands. Commands are specified to “Start” a program, “Stop” a
     program and “Check” (detect) that the started program is running properly.
     Used by PCS to provide a point of control for the real-world user application
     represented by the parent satApplication object.
●    Ip Address—Configures high availability virtual network interfaces. These
     present the same logical IP address or host name, either to a configured
     application or to an external network, regardless of where the interface is
     switched within the cluster by ASCC.
●    Local File System—Configures local file systems for high availability. The file
     systems are capable of being mounted on any node in the configuration. A
     local file system is only mounted on the node where the application is online.
●    LVM—Configures disk groups in clusters that are administered by the Linux
     Volume Manager.
●    Raw Disk—Configures raw disk devices. This subapplication creates
     symbolic links from physical disks to named files.
●    Remote File System—Configures remote NFS file systems.
●    Virtual Host—Configures high availability virtual host names with optional IP
     addresses. These present the same logical host name regardless of where
     ASCC switches the associated application within the cluster.



34                                                               U42147-J-Z100-4-76
PCS configuration basics                                     Basic PCS concepts


3.2.7      Understanding templates and instances

A PCS template for an object may be thought of as a container that defines the
object’s supported attributes (parameters) and internal structure. Each attribute
has a pre-defined data type (Boolean, integer, name, or string) and possibly a
default value. The template may mark an attribute as required, which means
that the user must enter a value for that attribute when the object is configured.
If the object can contain child objects, the template may also define the internal
structure. This includes the number and types of objects that can be configured,
where the objects may occur in the internal hierarchy, and whether or not each
object is required when the parent object is configured. For example, the
Generic template defines the types of subapplications (child objects) that may
be configured for the parent application and where they appear in the appli-
cation structure. However, all the subapplications are optional: you can
configure zero or more of each one.
The custom templates that have been designed for specific applications may
have different rules. Some of the subapplications may be required, and you may
have to provide certain parameter settings before the configured application is
ready to run. The choice is up to the template designer.

Object instances
When you choose a template and then configure an object, you are actually
creating an instance of that object: PCS copies the object’s internal structure
and default parameter (attribute) values from the object template and inserts
them into the configuration with the name you specify. If the object requires
additional information before it can be used in the configuration, it is marked as
inconsistent. When all the required information has been supplied and has
been validated by PCS, the object is marked as consistent. A parent object
cannot be marked as consistent if one or more of its child objects is inconsistent.
I Consistency does not guarantee optimum performance. PCS ensures
        that user data is of the correct type and in the valid range specified by the
        template. However, certain combinations of valid parameters may de-
        tune the configuration when it is run by ASCC.
Some child objects in a template may be optional, e.g., the subapplications in
the Generic template. Optional objects do not affect the consistency of the
parent application, with the exception that the parent cannot be consistent if all
subapplications are marked as optional; at least one subapplication must be
properly configured for the application to be consistent.



U42147-J-Z100-4-76                                                                35
PCS directory structure                                PCS configuration basics


When you delete a single instance of a subapplication, it is removed from the
configuration; when you delete the last instance of a subapplication, the subap-
plication is marked as inconsistent. You can clear the inconsistency by
unchecking the subapplication’s Configure this subapplication checkbox.
Note that subapplications that are marked as optional still retain the underlying
template structure even when no instances are configured. In the Generic
template, attempts to remove an optional subapplication are not allowed, as this
would remove part of the template structure.


3.3         PCS directory structure
The PCS software resides primarily in the directory contained in the PCSHOME
environment variable. By default, PCSHOME is set to /opt/SMAW/SMAWpcs.
Configuration templates and data are stored in subdirectories of <PCSHOME>
(figure 5).


       <PCSHOME>
          Config.satellite
             <configuration name>
                App0_d.xml
                Config_d.xml
                backup
                runtime
                    <configuration name>.us
          Templates
          Examples
                                         asw0303
Figure 5: PCS data directory structure

The data subdirectories include:
●    Config.satellite directory—Includes the data for all user-defined config-
     urations. This directory is the workbench during the configuration process.
     Each configuration is stored in its own subdirectory under
     Config.satellite, where the subdirectory name is the same as the
     configuration name.
     The subdirectory for each configuration contains the following items:




36                                                             U42147-J-Z100-4-76
PCS configuration basics                                 PCS directory structure


    – *_d.xml—Result templates, created whenever the configuration is
      saved. These files always include Config_d.xml, the master result
      template for the entire configuration, as well as one XML result template
      for each application.
    – runtime directory—Contains the current ASCC configuration. When the
      configuration is activated, the configuration files are copied to this
      directory on the local node and to all other nodes in the configuration.
    – backup directory—Contains the previous ASCC configuration. When a
      configuration is modified, the contents from runtime are first copied
      here.
●   Templates directory—Contains templates for applications and subapplica-
    tions.
●   Examples directory—Contains files for PCS configuration examples.
    Execute example_install.sh for instructions on how to install the
    example files. After an example file is installed, it will become available for
    further inspection in the PCS interface.

Example
    If you create a configuration named banking, then PCS creates the directory
    <PCSHOME>/Config/banking. When you activate the configuration, PCS
    performs the following steps:
    1. generates the banking.us file in the runtime subdirectory
    2. copies the <PCSHOME>/Config/banking/runtime hierarchy to all
       nodes in the configuration.
    3. sets the name of the default running configuration in
       RELIANT_PATH/etc/CONFIG.rms
    If you edit the configuration, PCS copies all existing files in runtime to
    backup before you can make any changes.




U42147-J-Z100-4-76                                                               37
Using multiple configurations in one image               PCS configuration basics


3.4        Using multiple configurations in one image
ASCC allows you to create and activate multiple configurations in one image.
Each configuration will define a different task group, because the groups are
named according to the convention <application name>_<configuration name>.
This means that one image can be associated with several task groups.
I Whenever possible, we recommend that you store as many configura-
        tions as possible in a single image, provided the all the installed software
        can coexist.


3.4.1      Benefits

This approach provides the following benefits:
●    Requires less disk space in the ASCC repository than multiple, single-
     configuration images.
●    Minimizes effort for OS updates and service packs.
●    Eliminates delays when a node is reassigned to another task group in the
     currently loaded image.
The last point is especially important. For example, suppose you have defined
two task groups, group1 and group2, and that a satellite node must be switched
from one group to the other. If each group is in its own separate image, ASCC
must take the original application monitoring configuration offline, perform a
complete shutdown of the node, deploy (clone) the image, reboot the node, and
then bring the new configuration online. This will typically take 10 to 20 minutes,
depending on the size of the installed packages in the image and the traffic on
the deployment LAN.
However, if both groups share the same image, ASCC only has to take the
original configuration offline and then bring the other configuration online. This
generally requires no more than a few minutes, depending on the resources
involved. At any rate, it avoids the shutdown, deployment, and reboot operations
entirely.


3.4.2      Restrictions

There are some restrictions to this approach:




38                                                               U42147-J-Z100-4-76
PCS configuration basics         Using multiple configurations in one image


●   All the applications must run on the same OS. An image can contain only
    one OS version and service pack, and multiboot or LILO operations are not
    supported.
●   All the installed software must be able to coexist, even when some compo-
    nents or applications are not running. There must be no conflicting use of
    items such as directories, files, user names, and access permissions.
    However, note that items such as volume managers, local and remote file
    systems, and network interfaces can be specified as part of an application
    monitoring configuration, so they can be allocated dynamically according to
    the currently active group.
●   Groups that require IP load balancing, e.g., web servers on multiple nodes,
    cannot run on satellites that were installed with ‘asconf -o NOSIS’. SAP
    license agreements prohibit the kernel drivers used by IP load balancing.
    However, if a task group will not be configured for IP load balancing, you may
    install the corresponding software on a ‘-o NOSIS’ satellite.
●   The resulting image may be very large and take a long time to deploy. This
    can hinder initial configuration and debugging efforts, especially if the
    problems are not manifest until the node is placed in automatic mode.
    However, you can develop smaller, single-configuration images for the test
    phase, and then combine the configurations in one large image for
    production purposes.




U42147-J-Z100-4-76                                                             39
Commonly used PCS terms                              PCS configuration basics


3.5       Commonly used PCS terms

Term             Definition
ASCC/PCS         A group of one or more ASCC applications that are
configuration    configured and controlled together.
ASCC appli-      A grouping of ASCC objects that usually comprise a software
cation           application and its dependent components. The state of
                 ASCC objects within the application are dependent on each
                 other.
PCS appli-      An application template typically models how a particular
cation template software product and the objects it depends on (e.g., disks,
                other software components) are configured for high avail-
                ability (HA) with ASCC. An application template usually
                includes one or more subapplication templates. The most
                frequently used application template is Generic.
PCS subappli- A subapplication template models various components. For
cation template example, a portion of software product, a system service
                (NFS), a hardware component (network interface). A PCS
                subapplication usually maps to one or more ASCC objects.
ASCC object      A single entity in an ASCC configuration that usually maps to
                 either a physical entity, known as a gResource (e.g., a mount-
                 point) or maps to an entity that represents logical behavior
                 (e.g., an andOP or orOP).
PCS CDL          Abbreviation for Configuration Description Language. CDL is
                 an XML-based programming language for defining
                 commercial and custom software packages and system
                 components in a high-availability configuration with ASCC.
                 Application and subapplication scripts are written in CDL.
                 The typical PCS end-user will not need to understand the
                 CDL language.
PCS GUI          The PCS graphical user interface that creates and edits
                 templates for a customer’s specific configuration.
PCS CUI          The PCS character-based user interface that creates and
                 edits templates for a customer’s specific configuration.
Table 3: Commonly used PCS terms




40                                                           U42147-J-Z100-4-76
PCS configuration basics                         Commonly used PCS terms


Term             Definition
pcstool          The PCS command-line tool that contains a subset of the
                 functionality of the GUI and CUI. pcstool can change simple
                 variables in result templates, add instances of PCS objects
                 (e.g., adding mount points), and clone configurations. This
                 tool is intended for OEM customers and experienced users.
PCS result       The PCS configuration files that have been customized for a
templates        particular customer environment. The files are saved in the
                 configuration directory.
PCS generate     Converts the PCS result templates into the ASCC configu-
                 ration file. This PCS operation is available from the PCS GUI,
                 CUI, or pcstool.
PCS activate     Copies the PCS and ASCC configuration files to each node
                 in the cluster and makes the current PCS configuration the
                 active ASCC configuration. This PCS operation is available
                 from the PCS GUI, CUI, or pcstool.
Table 3: Commonly used PCS terms




U42147-J-Z100-4-76                                                           41
4         Getting started
This chapter describes how to start PCS and open a configuration.
Chapter contents:
●   “Starting PCS on a reference node” on page 43 describes how to start the
    PCS GUI on a reference node.
●   “Opening a configuration” on page 46 describes how to create a new config-
    uration or edit an existing one.
The information in this chapter is also available online through the PCS HELP
facility.


4.1       Starting PCS on a reference node
This procedure assumes you have already completed the following steps:
●   The ASCC wizard has been opened.
●   The satellite nodes have been assigned to ASCC.
●   At least one satellite node has been put into manual mode so it can be used
    as a reference node.
The above steps are described in detail in the Adaptive Services Control Center
(ASCC) User Guide.
Ê Navigate to the Reference Nodes step in the left pane.
The current list of manual mode nodes appears as a subtree below the Reference
Nodes step (figure 6).




U42147-J-Z100-4-76                                                            43
Starting PCS on a reference node                                     Getting started




Figure 6: Selecting a reference node

Ê Select the radio button for the desired reference node, or click directly on the
  reference node name in the left pane.
     If the image contains any application pool configurations, their properties will
     appear in the Available Configurations pane.
Ê Click Next to continue.
After a few seconds, PCS displays information and possible actions for the
selected reference node (figure 7).




44                                                                U42147-J-Z100-4-76
Getting started                                  Starting PCS on a reference node




Figure 7: Configuring application monitoring on Linux reference node

Ê Select the Configure Application Monitoring on Node radio button.
   This action is available only for Linux or Windows ACI reference nodes.
Ê Click Next to continue.
The PCS session on the selected node will open in a separate window.
I You can switch between the ASCC GUI, the ASCC wizard, and any PCS
       session without closing any of the windows. You can also open multiple
       PCS sessions as long as each one is on a different reference node.




U42147-J-Z100-4-76                                                            45
Opening a configuration                                           Getting started


4.2        Opening a configuration
The initial PCS window requires you to supply a configuration name (figure 8).




Figure 8: Initial PCS window

If any configurations have been created previously, the Configuration Name input
box will appear as a drop-down list. By default, the last configuration activated
on the local node will be selected for you. You can edit a different configuration
by selecting it from the list.




46                                                             U42147-J-Z100-4-76
Getting started                                    Opening a configuration


4.2.1      Creating a new configuration

Ê To create a new configuration, type the new name directly into the Configu-
  ration Name input box (figure 9).




Figure 9: Entering a new configuration name

Ê Click Next to continue.




U42147-J-Z100-4-76                                                         47
Opening a configuration                                            Getting started


4.2.2      Viewing the PCS configuration

When you open a new configuration, PCS displays the Configuration Start view
(figure 10).




Figure 10: Configuration start window

The configuration name appears in the left pane at the top of the tree. In a new
configuration it will initially be the only item, marked as inconsistent with a red
status icon. Other items such as applications, subapplications, configuration
groups, and instances will appear as PCS guides you through the configuration
process.
Because your next step will be to define an application, PCS displays a
dropdown list of available templates in the right pane. By default, PCS uses the
Generic application template. Other templates may appear in the dropdown list
if they have been installed on the local host.
Ê To create an application, click the Next button in the toolbar at the bottom of
  the window.
The left pane will expand into a tree-like series of steps.




48                                                              U42147-J-Z100-4-76
Getting started                                        Opening a configuration


●   If you are not familiar with the PCS interface, we recommend that you
    proceed to the next chapter, “PCS graphical user interface” on page 51. This
    first describes the available features and controls, and then presents a walk-
    through of each menu.
●   Otherwise, you can continue the configuration process by advancing
    through the steps in the left pane. A detailed description of each step begins
    with “Generic Linux applications” on page 83.




U42147-J-Z100-4-76                                                             49
5         PCS graphical user interface
This chapter introduces the PCS graphical user interface (PCS GUI) for ASCC.
After describing the basic components of the GUI, it provides a walk-through of
each menu.
Chapter contents:
●   “PCS GUI views and controls” on page 52 describes the PCS GUI window
    layout.
●   “File menu” on page 57 explains the operations available from the File menu.
●   “Edit menu” on page 61 explains the operations available from the Edit
    menu.
●   “Tools menu” on page 67 explains the operations available from the Tools
    menu.
●   “Option menu” on page 74 explains the operations available from the Option
    menu.
●   “Help facility” on page 76 explains how to access the online documentation
    and context-sensitive help.
The information in this chapter is also available online through the PCS HELP
facility.




U42147-J-Z100-4-76                                                           51
PCS GUI views and controls                              PCS graphical user interface


5.1        PCS GUI views and controls
The PCS GUI consists of a menu bar at the top, a configuration tree in the left
pane (or sub-window), a user input area in the right pane, and a button bar at
the bottom (figure 11).




                                                                        asw0501
Figure 11: PCS configuration tree and user input area



5.1.1      Menu bar

The menu bar changes according to your progress in the configuration
procedure:
●    When you first start PCS, or when you close a configuration, the PCS GUI
     displays the initial view. In this mode, the menu bar contains only the File,
     Option, and Help menus.
●    While you are creating or modifying a configuration, PCS displays the
     editing view. In this mode, the menu bar adds the Edit and Tools menus.
Menu operations or controls vary according to the view you are in. The File, Edit,
Tools, Option, and Help menus are each described in their own sections later in
this chapter.



52                                                                U42147-J-Z100-4-76
PCS graphical user interface                       PCS GUI views and controls


5.1.2       Configuration tree

In the editing view, the configuration tree in the left pane presents a hierarchy of
steps, each of which will configure a particular resource type. PCS guides you
down the tree, expanding high-level items into sub-steps as necessary. You can
choose to skip any step if the corresponding resource will not be part of your
high-availability configuration. When you have completed (or skipped) all the
steps, your configuration is complete and ready to be activated.

5.1.2.1     Structure and terminology

There is only one item at the top of the tree, and that represents the configu-
ration. In figure 12, the configuration is named demo1.




                             asw0502
Figure 12: Configuration tree structure

Directly beneath the configuration, there must be one application. In general, a
PCS application corresponds to one or more real-world programs, processes,
or some combination of both. In the example above, demo1 contains the App0
application.
The items directly beneath the application are called subapplication templates,
or simply subapplications. Each subapplication represents a procedure that
allows you to configure a particular type of resource. You will follow a subappli-
cation’s procedure each time you want to add the corresponding resource type
to your configuration. For instance, to configure a file system on the local host,
you would go to the Local File System subapplication and let it guide you through
the necessary steps. After you complete this subapplication for the command
set, it becomes an instance in the PCS configuration. In the example above, the




U42147-J-Z100-4-76                                                               53
PCS GUI views and controls                         PCS graphical user interface


file system mounted on /mnt1 is an instance in the configuration. If you repeat
the subapplication’s procedure for another file system, you will create a second
instance.
Because each subapplication is so closely associated with the resource type
that it configures, it is natural to speak of them interchangeably. The descrip-
tions in this document follow this convention. For example, we may use the term
“local file system subapplication” and as it were an object or container, even
though it actually represents a series of configuration steps in the PCS context.
When you create one or more instances, the configuration tree displays them
as children of their subapplication, as illustrated by the location of /mnt1 in
figure 12 above. Therefore, it is natural to speak of each instance as being “in”
a subapplication, and we will follow this convention as well. However, keep in
mind that instances are actually products of subapplications.
The particular subapplications that appear in your PCS configuration are deter-
mined by the current template. PCS is shipped with the Generic template, which
contains standard subapplications that configure nodes, application param-
eters, disks and disk managers, file systems and storage managers, and
network resources. Optional, custom templates may contain subapplications
that configure enterprise hardware, commercial applications, or application
suites.

5.1.2.2     Appearance

As you proceed through the configuration, PCS indicates your position with a
blue highlight on the current item’s name. In figure 13, the configuration is
currently at a sub-step of the Local File System subapplication.




                            asw0503
Figure 13: Configuration tree icons and colors



54                                                             U42147-J-Z100-4-76
PCS graphical user interface                       PCS GUI views and controls


Every item in the tree is displayed with two icons:
●   The (first) object icon is yellow and includes an interior symbol to denote
    the type of the item.
●   The (second) status icon is a colored square that denotes the state of the
    item:
    – A blue status icon indicates a consistent state—all required information
      for the item (and its subtree, if any) has been entered.
       For example, the Command Line subapplication in figure 13 above is
       consistent.
    – A red status icon indicates an inconsistent state—the item or a member
      of its subtree has at least one required parameter or selection missing.
       For example, the Local File System subapplication in figure 13 above is
       inconsistent because it is only partially configured. (Lfs0 is a PCS place-
       holder name that must eventually be replaced with an actual mount point
       such as /mnt1.)
    – An orange status icon indicates an optional item—this is usually a
      subapplication that is not required by the parent application.
       For example, the Remote File System subapplication in figure 13 above is
       not required for any configuration, so it can be left unconfigured. (Note
       that the Local File System is not required either. Before the user decided
       to add it to the configuration, it would have been marked as an optional
       item, too.)
If the real-time consistency check option is selected, items in the tree will
change state as you add applications and subapplications.
A key at the bottom of the left pane shows all the possible icons and their
meanings.
Items with sub-trees are indicated by an additional “switch” icon to the left of the
object icon. Clicking on a switch expands or collapses that part of the tree.




U42147-J-Z100-4-76                                                               55
PCS GUI views and controls                           PCS graphical user interface


5.1.3      User input and status area

The user input area on the right contains input fields (check boxes, radio
buttons, combo-boxes, and drop-down lists) that collect information for the item
currently selected in the left tree. For some user input fields, values can be
entered directly by the user; in the case of “select only” fields, the value must be
chosen from a drop-down list.
For some configuration steps, the user input area simply displays read-only
information, or it may prompt you to click a button to proceed.


5.1.4      Button bar

The button bar is located at the bottom of the PCS window (figure 14).




                                                          pcs0504
Figure 14: PCS button bar

Depending on the current configuration step, some or all of the following buttons
are available in the PCS GUI.
●    Next—Used to write (commit) changes and proceed to the next step.
●    Cancel—Undoes the changes
●    Back—Takes you to the previous step of configuration.
●    Skip—Allows you to ignore the current step and proceed to the next step.
●    Add More—Used when additional instances of subapplications are to be
     added.




56                                                                  U42147-J-Z100-4-76
PCS graphical user interface                                                     File menu


5.2          File menu
The contents of the File menu will change according to where you are in the
configuration process:
●   Before you select a configuration (or after you close one), you are in the PCS
    initial view, where the left pane contains a logo (figure 15, left).
●   After you open a configuration, you are in the editing view, where the left
    pane contains configuration information (figure 15, right).




                               pcs0505                                 pcs0506
Figure 15: File menu in initial view (left) and editing view (right)

Note also that the Edit and Tools menus appear in editing mode, but not in the
initial view.


5.2.1        Exiting PCS

Ê From any view, select File –> Exit.
If you are in the editing view and have unsaved changes, PCS will prompt you
to save them (figure 16).




                                                                             pcs0507
Figure 16: Confirmation message if changes have not been saved

PCS will prompt you before ending the session (figure 17).



U42147-J-Z100-4-76                                                                     57
File menu                                                   PCS graphical user interface




                                                  pcs0508
Figure 17: Exiting PCS: Confirmation message

Ê Click Yes to confirm and exit PCS.


5.2.2       Deleting configurations

You must be in the initial view to delete configurations.
Ê Select File –> Delete Configurations from the menu (figure 18). Note that this
  selection is disabled (grayed out) if there are no saved configurations to
  delete.




                             pcs0509
Figure 18: File menu: Deleting configurations from initial view

The current list of configurations will appear (figure 19).




                                                                         pcs0510
Figure 19: Available configurations to delete



58                                                                    U42147-J-Z100-4-76
PCS graphical user interface                                           File menu


Ê Highlight the configurations you want to delete (figure 20).
    To select multiple items, hold down the [Ctrl] key while you click on the
    names.




                                                                  pcs0511
Figure 20: Selected configurations to delete

Ê Click Next to continue.
You will advance to a view where you can confirm or cancel the operation
(figure 21).




                                                                  pcs0512
Figure 21: Confirming the deletion

Ê Click Next to confirm the operation and return to the initial window.




U42147-J-Z100-4-76                                                              59
File menu                                           PCS graphical user interface


5.2.3       Closing and saving configurations

In the editing view, the File menu provides a set of operations for the current
configuration (figure 22).




        pcs0513
Figure 22: File menu in editing view

●    Choose Close to close the current configuration. You will be prompted to
     save any changes before returning to the initial view (figure 17). You can
     then open or create another configuration.
●    Choose Save to save the current configuration. Afterwards, you will remain in
     the editing view.
●    Choose Save As if you want to save the current configuration with another
     name. You will be prompted for the name, and prompted again if a configu-
     ration with that name already exists. Afterwards, you will remain in the
     editing view, and you will then be working on the configuration with the name
     you specified.




60                                                              U42147-J-Z100-4-76
PCS graphical user interface                                         Edit menu


5.3        Edit menu
I The Edit menu appears only after a configuration has been opened. It
        does not appear in the initial PCS window.
The Edit menu provides functions that manage application and subapplication
instances as well as some application settings. Some of the entries will be
unavailable (grayed out) according to the item selected in the PCS configuration
tree, or because the action is not applicable in the ASCC environment
(figure 23).




                 pcs0514
Figure 23: Edit menu



5.3.1      Add More Instances or Delete Instance

Select an instance of any subapplication in the tree and then open the Edit menu
(figure 24).




U42147-J-Z100-4-76                                                           61
Edit menu                                           PCS graphical user interface




                           pcs0515
Figure 24: Adding or deleting instances

Ê Use Add More Instances to add another instance of the same subapplication.
     I The Add More button at the bottom of the view can also be used to add
           another instance of the selected subapplication.
Ê Use Delete Instance to delete the selected instance.


5.3.2      Detector Settings

V Caution
        Detector settings rarely need adjustment. They should be changed only
        by expert PCS users.
Detectors monitor and report the state changes of resources for all subapplica-
tions. For example, there are mount point detectors, network interface
detectors, network file system detectors, and volume manager detectors.
Ê Enable expert mode from the Option menu.
Ê Select Edit –> Detector Settings.
A list of the available detectors appears (figure 25). Note that the detector
settings apply to the entire configuration, so the list is the same regardless of
the item selected in the left panel.




62                                                              U42147-J-Z100-4-76
PCS graphical user interface                                          Edit menu




                                                                     asw0504
Figure 25: Choosing detector settings

Ê Click any radio button to automatically advance to the corresponding
  detector settings view.
For example, pcsdet_system is the built-in detector that works with the
CommandLine subapplication. At regular intervals, pcsdet_system executes a
command that the user has specified in the subapplication’s Detector Command
setting (see the section “Command Line subapplication” on page 104). If you
click the pcsdet_system: User Defined Detector button, the corresponding Detector
Setting view appears (figure 26).




                                                                 pcs0518
Figure 26: Detector settings for pcsdet_system




U42147-J-Z100-4-76                                                             63
Edit menu                                            PCS graphical user interface


All detectors have three adjustable parameters, where the default value of each
parameter depends on the particular detector. The parameters are as follows:
Reaction Time (in sec)
       The interval between each check of the resource. Sometimes referred to
       as “cycle time” or “detector interval”.
        In the case of the user defined CommandLine resource, pcsdet_system
        uses this setting as the regular interval between successive invocations
        of the Detector Command. By default, this occurs every 10 seconds.
Detection Time (in msec)
       The estimated amount of time required to check the resource. This
       estimate along with the number of instances of each resource is used by
       PCS to determine how many resources each detector will monitor.
MemoryLogLevel
     The detail level for internal logging, where higher numbers produce more
     detail. The allowable range is 0–4, where 0 turns off logging. The default
     is 1.
        Each detector maintains a fixed-size (10KB) memory buffer to hold the
        most recent log messages. If the resource faults or unexpectedly
        changes from online to offline, the memory buffer is written out to the
        detector log file. Because the buffer size is fixed, higher memory log
        levels will produce more detail, but only for the most recent events; lower
        memory log levels retain more history, but with fewer details.
        The detector log files are stored in the following files:
        <RELIANT_LOG_PATH>/<detector_name>.g<n>log
        where <detector_name> is the name of the detector displayed in the
        Detector Setting window (figure 26) and <n> is the instance number of the
        detector. For instance, the log file for the first (or only) pcsdet_system
        detector is <RELIANT_LOG_PATH>/pcsdet_system.g1log.
Ê To close the Detector Setting window and return to the previous view, click the
  Back button or select File –> Close Detector Setting (figure 27).




                   pcs0519
Figure 27: Closing detector settings




64                                                              U42147-J-Z100-4-76
PCS graphical user interface                                          Edit menu


5.3.3      Rename application

Ê Highlight the application in the left pane and then select Edit –> Rename –>
  Application from the menu.
You will be prompted to enter a new name for the application (figure 28).




                                                                     asw0505
Figure 28: Renaming an application

Ê Enter the new name and then click Next to complete the operation.
I The new name will take effect as soon as you click Next or any active item
        in the view, including a menu item. To cancel the rename operation, blank
        out the new name and then click Next.


5.3.4      Create application

I ASCC allows only one application per configuration. You must delete all
        other applications before you can create a new one.
Ê To add a new application, select Edit –> Create and then choose Application
  from the secondary menu.




U42147-J-Z100-4-76                                                             65
Edit menu                                         PCS graphical user interface


5.3.5       Delete application

Ê Highlight the application in the tree and then select Edit –> Delete –>
  Application (figure 29).




                                 asw0506
Figure 29: Deleting an application

You will be prompted to confirm your choice (figure 30).




                                                                pcs0525
Figure 30: Confirming application deletion

Ê Click Next to delete the selected item.




66                                                            U42147-J-Z100-4-76
PCS graphical user interface                                    Tools menu


5.4        Tools menu
I The Tools menu appears only after a configuration has been opened. It
        does not appear in the PCS initial view.
The Tools menu provides actions to manage a configuration (figure 31).




                 pcs0526
Figure 31: Tools menu

Individual tools are discussed in the following sections.


5.4.1      Generate

Generating a configuration creates the following:
●   ASCC graph of the configuration
●   ASCC configuration file with a ‘.us’ extension
●   Miscellaneous configuration files.




U42147-J-Z100-4-76                                                       67
Tools menu                                                PCS graphical user interface


5.4.2      Draw Graph

You can use this operation to see a graphical representation of the current
configuration, including application and subapplication structure (figure 32).
This is useful to review the configuration before activating it.




                                                                      asw0507
Figure 32: PCS configuration graph for a Generic application




68                                                                  U42147-J-Z100-4-76
PCS graphical user interface                                         Tools menu


You can click on any object in the graph to display its properties (figure 33).




                                                                       asw0508
Figure 33: Displaying item properties from the PCS graph




U42147-J-Z100-4-76                                                                69
Tools menu                                              PCS graphical user interface


Ê To list the scripts that are available for manual execution, right-click on an
  object in the graph (figure 34).




                                                                         asw0509
Figure 34: Manually executing a script from a PCS graph context menu

Ê To test one of the available scripts for the selected object, click on the script
  name in the context menu.
The output and return status from all manually executed scripts will appear in
the Manual Script Execution window (figure 35).




70                                                                     U42147-J-Z100-4-76
PCS graphical user interface                                         Tools menu




                                                   asw0510
Figure 35: Manual script execution output window

Note that you may have to scroll down to see the output from the last execution.


5.4.3       Activate

When you activate a configuration, the configuration files are stored on the local
node in a format that can be automatically started by ASCC.
Ê Select Tools –> Activate (figure 36)




                             asw0511
Figure 36: Activating the configuration

After the configuration has been activated successfully, PCS will display infor-
mation about the process (figure 37).




U42147-J-Z100-4-76                                                             71
Tools menu                                          PCS graphical user interface




                                                                 asw0512
Figure 37: Successful activation message

Ê Click Next to continue.


5.4.4       Lock and Unlock

You may lock a configuration to provide additional security. Locked configura-
tions can be edited only if they are unlocked with the password supplied during
locking. However, any PCS user can still view, generate, or activate a locked
configuration.
Ê Select Tools –> Lock or Tools –> Unlock (figure 38). Note that only one of the
  Lock or Unlock operations is enabled at any time, according to the current
  lock state.




                           pcs0532
Figure 38: Locking or unlocking the configuration

I If you have modified the configuration, you will be prompted to save it
        before you can lock it.
A dialog will prompt you to enter the password (figure 39).




72                                                            U42147-J-Z100-4-76
PCS graphical user interface                                          Tools menu




                                                                   pcs0533
Figure 39: Providing the configuration password

Ê Enter the password in the Password field.
Ê If you are locking the configuration, you must re-enter the password in the
  Confirm Password field.
Ê Click Next to continue.
To unlock the configuration at a later time, you must provide the same password.
V Caution
        If you use File –> Save As to duplicate the current configuration, the copy
        will be created without the original’s lock and password.


5.4.5      Check Consistency

Ê To display the current state of the configuration’s consistency, select Tools –
  > Check Consistency (figure 40).




                           pcs0534
Figure 40: Manually checking configuration consistency

This operation is not usually necessary because the Real Time Consistency
Checking option is enabled by default (see its description in the Option menu
discussion in the next section).



U42147-J-Z100-4-76                                                              73
Option menu                                               PCS graphical user interface


I You can save an inconsistent configuration, but you cannot activate it. We
        recommend that you allow PCS to automatically check for consistency by
        leaving the Real Time Consistency Checking option enabled.


5.5         Option menu
The contents of the Option menu depend on the current configuration step.
In the initial view, when no configuration is open for editing, the Option menu
controls are limited to overall PCS operation (figure 41).




                             pcs0535
Figure 41: Option menu before configuration is selected

In the editing view, when you are creating or modifying a configuration, the
Option menu adds controls that apply to the editing process (figure 42).




                                        pcs0536
Figure 42: Option menu after configuration is selected

The following controls are available:
●    Expert Mode—if enabled, enables additional attributes to be displayed and
     edited. In standard mode, only the most commonly used attributes are
     displayed, and the expert mode attributes are initially set to their default
     values. The attributes available for each subapplication provided with PCS




74                                                                  U42147-J-Z100-4-76
PCS graphical user interface                                        Option menu


    are listed in their respective descriptions. A complete description of all ASCC
    attributes is provided in the chapter “Appendix—Attributes” on page 241.
    Default: disabled
    I Returning to standard mode does not disable any changes you make
           to expert mode parameter settings—it merely hides them. The hidden
           parameters continue to affect the configuration’s operation. To
           change or view a hidden expert mode parameter, you must re-enable
           expert mode.
●   Inconsistent Screen Only—if enabled, clicking the Next button will move the
    focus to the next inconsistent application or resource (if any exist) in the
    configuration tree. Default: disabled
●   Real Time Consistency Check—if enabled, PCS automatically checks consis-
    tency as you proceed with the configuration. Default: enabled
    I You can save an inconsistent configuration, but you cannot activate it.
           We recommend that you allow PCS to automatically check for consis-
           tency by leaving the Real Time Consistency Checking option enabled.
●   Trace—controls the level of trace detail for PCS as it prepares the configu-
    ration. The options are mutually exclusive, so checking one will uncheck the
    others. To disable PCS tracing completely, make sure all options are
    unchecked. Default: all levels disabled
    If one of the three detail levels (Normal, Detail, Very Detail) is selected,
    several trace files are created in the directory /var/opt/SMAWpcs/trace.
    These trace files may be helpful to service personnel when diagnosing
    problems with PCS.
    I The trace files are created on the host where you made your initial
           Cluster Admin connection, which is usually the primary Web-Based
           Admin View server. This may not be where the current PCS session
           is running.
    V Caution
           Do not activate a trace option without instructions from a PCS expert.
           The Trace option may generate a large volume of output very rapidly.




U42147-J-Z100-4-76                                                                 75
Help facility                                       PCS graphical user interface


5.6         Help facility
You can obtain help from the PCS interface in any of the following ways:
●    The Help menu
●    Context-sensitive help
●    Tooltips


5.6.1       Help menu

The items available on the Help menu will change according to where you are
in the configuration process, and which item is selected in the configuration tree
(figure 43).




                                         pcs0537
Figure 43: Help menu


5.6.1.1     General help

Ê To display the online PCS documentation in a new browser window, select
  Help –> PCS Help –> How to use PCS? (figure 44).




76                                                             U42147-J-Z100-4-76
PCS graphical user interface     Help facility




                                      pcs0538
Figure 44: General online help




U42147-J-Z100-4-76                         77
Help facility                                      PCS graphical user interface


5.6.1.2    Subapplication help

Ê To display help about a particular subapplication, click on the subapplication
  in the configuration tree, and then select Help –> PCS Help –> Subapplication
  (figure 44).




                                         asw0513
Figure 45: Subapplication help menu

The help text for that subapplication appears in the right pane (figure 46).




                                                                  pcs0540
Figure 46: Subapplication help message


5.6.1.3    Application and Resource help

In the default Generic template, the Help –> PCS Help submenu contains grayed-
out (disabled) entries for Application and Resource. Either or both items may be
enabled when you install a custom wizard.




78                                                             U42147-J-Z100-4-76
PCS graphical user interface                                         Help facility


5.6.2      Context-sensitive help

Ê To get context sensitive help for any user input field, select Help –> What’s
  this? (figure 47), and then click the left mouse button in the input field.




                                                                     asw0514
Figure 47: Context-sensitive help menu

Information for that item will appear in a popup text area (figure 48).




                                                                     asw0515
Figure 48: Context-sensitive help message

Alternatively, you can hold the [Ctrl] key while you right-click the mouse button
on an input field.




U42147-J-Z100-4-76                                                             79
Help facility                                        PCS graphical user interface


5.6.3       Tooltip help

When the mouse cursor is stationary over any user input field for about a
second, tooltip text appears. Usually, the text is a short reminder of the input you
would supply for the field (figure 49). The tooltip will disappear after 4–5
seconds.




                                                                    pcs0543
Figure 49: Tooltip help




80                                                               U42147-J-Z100-4-76
Part II: Linux Configurations




U42147-J-Z100-4-76
6         Generic Linux applications
This chapter describes the PCS GUI interface to the Generic application
template for Linux, which includes all the standard subapplications discussed in
the next four chapters. These standard subapplications are part of the basic
PCS package and are sufficient to build most configurations. Custom appli-
cation kits such as the PCS Wizard Kit may also rely on the standard set of
subapplications.
Chapter contents:
●   “Generic application template features” on page 84
●   “Creating an application” on page 86
●   “Setting application parameters” on page 88
●   “Common subapplication procedures” on page 91
●   “Expert mode” on page 95




U42147-J-Z100-4-76                                                           83
Generic application template features                   Generic Linux applications


6.1        Generic application template features
The Generic application template was introduced in the section “Basic PCS
concepts” on page 29. Each standard subapplication template configures a
particular type of system resource or control point; that is, it creates an ASCC
object to represent the actual resource. You can specify various parameters for
each resource, and PCS translates these into the appropriate attributes for that
object type. You can configure any number of resources with the same template,
each with its own parameter settings. table 4 summarizes the standard subap-
plication templates included with PCS.

Subapplication             Object type       Resource configured
CommandLine                gResource         Any program
Local File System          gResource         File system on local machine
Remote File System         gResource         File system on remote machine
Ip Address                 gResource         Network interface
LVM                        gResource         Linux volume manager
Raw Disk                   gResource         Physical disk device
Virtual Host               gResource         Network host name
Table 4: Standard PCS subapplication templates


ASCC requires that every configured object be placed in a hierarchical tree, or
graph. The parent/child relationships in the tree express dependencies. For
example, if a file system depends on a volume managed by RCVM for proper
operation, then the corresponding Local File System object will be the parent of
the RCVM object in the configuration tree.
When you use the Generic template to configure a set of resources for an appli-
cation, PCS automatically creates a dependency tree, or graph, for you. Each
object’s location in the graph is pre-determined according to the subapplication
that created it (figure 50).




84                                                                  U42147-J-Z100-4-76
Generic Linux applications                    Generic application template features




                                       CommandLine




           LocalFileSystem        RawDisk                     RemoteFileSystem




                           LVM                                   IpAddress




                                            VirtualHostName



Figure 50: Subapplications in Generic application structure

ASCC allows an object to have not only multiple children, but multiple parents
as well. For instance, the LVM subapplication can be a child of either the Local-
FileSystem subapplication or the RawDisk subapplication, or both.
When you configure multiple objects of the same type, e.g., three distinct Local-
FileSystem objects, they will all be placed in the same relative position in the
graph. Each one will share the same parents and the same children. You can
also choose to omit objects of a particular type, e.g., RawDisk. PCS automatically
creates all the logical group connectors and dependencies that may be required
to maintain the correct parent/child relationship between any two objects.




U42147-J-Z100-4-76                                                               85
Creating an application                              Generic Linux applications


6.2        Creating an application
When you create an application with the Generic template, you begin at the top
of the configuration tree with an inconsistent application (figure 51).




Figure 51: Changing the application name

By default, PCS names the first application App0. You can enter a name of your
choice directly into the New Application Name input field.
Ê Click Next to advance to the next view.
PCS will display information about the application template (figure 52).




86                                                            U42147-J-Z100-4-76
Generic Linux applications                                Creating an application




Figure 52: Viewing the application template information

There are no parameters to configure in this view.
Ê Click Next to continue.




U42147-J-Z100-4-76                                                            87
Setting application parameters                      Generic Linux applications


6.3        Setting application parameters
After you view the application template information, you will advance to the
application parameter settings view (figure 53).




                                                                   asw0603
Figure 53: Application parameters

Note that the Nodes and Application Parameters items in the left hand tree are
consistent, but the application App0 is not. This is because you must configure
at least one subapplication before the parent application can be marked as
consistent.
There are no parameters to adjust in this view unless you switch to expert mode.


6.3.1      Expert mode application parameters

Use the Option –> Expert Mode checkbox to see all available parameters
(figure 54).




88                                                           U42147-J-Z100-4-76
Generic Linux applications                        Setting application parameters




                                                                     asw0604
Figure 54: Application parameters (expert mode)

You can modify the following parameters from this view:
AppStateScript
      Specifies a script to execute whenever certain application state changes
      occur. For more information, see “AppStateScript” on page 241.
PreCheckScript, PreOnlineScript, PostOnlineScript, PreOfflineScript, PostOffline-
Script, OfflineDoneScript, FaultScript
        See the section “Scripts” on page 19 for more information about these
        items.
       PCS provides an appropriate default script for each of these items. Each
       definition entered here is appended to the corresponding default script.
       V        Caution
               Do not customize script settings in a working ASCC configuration
               without the direction of ASCC support personnel. ASCC scripts
               run with root privilege, and an improperly designed script can
               cause system outages and loss of data. Scripts provided with
               PCS have been written and tested by ASCC experts.




U42147-J-Z100-4-76                                                             89
Setting application parameters                         Generic Linux applications


PreserveState
       If set to Yes, specifies that the application’s resources are not to be taken
       offline after a fault occurs. Default: No
Persistent Fault
        If set to Yes, the application maintains a faulted state across an ASCC
        shutdown and restart: the application returns to the faulted state if it was
        faulted before, unless the fault is explicitly cleared by either ‘hvutil –c’
        or ‘hvswitch –f’. Default: No
       I The faulted state is retained only while the same image is loaded
              on the node.
PreCheckTimeout
      Specifies the maximum time (in seconds) allowed for the PreCheckScript
      to execute. This setting also affects the default value of ScriptTimeout
      below. If not specified, PCS will choose the value internally. Default:
      NONE (value determined internally)
ScriptTimeout
       See “ScriptTimeout” on page 96. Default: PreCheckTimeout+5
Many of the above parameters set ASCC attributes of the same name for the
application. See the chapter “Appendix—Attributes” on page 241 for more infor-
mation.
You can adjust the application parameters at this point, or you can click the Next
button to begin configuring the subapplications now. For the present discussion,
we will proceed to the subapplications and assume that the application param-
eters can be adjusted later.




90                                                               U42147-J-Z100-4-76
Generic Linux applications               Common subapplication procedures


6.4         Common subapplication procedures
Each subapplication has some controls that apply specifically to the resource
type that it configures, and these are described in later chapters. However, other
controls and procedures are related to the configuration process, e.g., deleting
an instance, and these operate the same way in all subapplications. This
section describes the common procedures.


6.4.1       Subapplication initial view

When you select a subapplication in the left tree, the right-hand view displays
some introductory text and a check box (figure 55).




                                                                     asw0605
Figure 55: Subapplication initial view

If you click the Back, Next, or Skip buttons, you navigate up or down through the
left-hand tree without changing the selected application. If you click the check
box, you toggle its current state as follows:
Ê If you clear the box, all previously configured subapplications of the current
  type are changed to the optional state, as if they had never been configured.
  Your settings are not immediately deleted, however.



U42147-J-Z100-4-76                                                             91
Common subapplication procedures                            Generic Linux applications


     I You can restore your previous settings by re-checking the box any
            time before the configuration is saved.
Ê If you check the box, and you have not previously configured this subappli-
  cation type, a new instance will be created for you. The current subappli-
  cation and the new instance will be marked as inconsistent with a red status
  icon. Click the Next button to advance to a view where you can fill in the
  required values (figure 56).




                                                                          asw0606
Figure 56: Configuring first instance of a subapplication




92                                                                  U42147-J-Z100-4-76
Generic Linux applications                   Common subapplication procedures


6.4.2      Creating multiple instances

When a subapplication instance is selected in the left hand tree, you can create
additional instances of the same application using either of the following
methods:

1. Add More toolbar button
Ê Select the last instance in the subapplication and click the Add More button
  (figure 57). One new instance will be created.




                                                                    asw0607
Figure 57: Creating multiple instances: Add More button


2. Add More Instances menu item
Ê Select any instance in the application with a drop-down or scrolling list of
  possible items to be managed, and then select the Edit –> Add More Instances
  menu item (figure 58).




U42147-J-Z100-4-76                                                            93
Common subapplication procedures                               Generic Linux applications




                            asw0608
Figure 58: Creating multiple instances: Add More Instances menu

Ê When the list in the right pane expands, click on one item in the list, or hold
  down the [Ctrl] key while selecting multiple items (figure 59).




                                                                             asw0609
Figure 59: Creating multiple instances: selecting multiple targets

Ê When you click Next, one new instance will be created for each item
  selected.




94                                                                     U42147-J-Z100-4-76
Generic Linux applications                                        Expert mode


6.4.3      Deleting instances

Ê To delete an instance of a subapplication and all its settings, select the
  instance in the left-hand tree and then use Edit –> Delete –> Instance.
You will be prompted to confirm the deletion.
Note that this is not the same as unchecking the subapplication’s Configure this
subapplication checkbox, because that operation retains the settings of non-
deleted instances. Those settings can be recovered by rechecking the
checkbox.


6.5        Expert mode
The operations in this section apply to most subapplications in the Generic
template, but are intended for advanced users or consultants.


6.5.1      Switching between expert and standard mode

By default, you’ll be in standard mode when you start a PCS session. In this
mode, subapplication views (like the one in figure 56 above) present all the
required settings as well as a few of those most commonly used.
You can access all available settings for the subapplication by switching to
expert mode with the Option –> Expert Mode check box (figure 60).




                       pcs0613
Figure 60: Toggling expert mode



6.5.2      Common options in expert mode

In expert mode, the following options have the same meaning wherever they are
available.



U42147-J-Z100-4-76                                                             95
Expert mode                                            Generic Linux applications


6.5.2.1   AutoRecover

If the AutoRecover flag is set to Yes, ASCC will automatically attempt to recover
the current resource if it fails. There is only one attempt to recover a resource
before switching the parent application to another node. Note that ASCC only
attempts to recover the current resource, and not the entire application.
If the AutoRecover flag is set to No, a failure of the current resource causes fault
processing for the parent application.
If a standard Generic subapplication has an AutoRecover parameter, its default
value is Yes. Some optional subapplications default to No.

6.5.2.2   MonitorOnly

The MonitorOnly flag determines whether a fault within the resource will also
cause the parent application to fault. If set to Yes, the resource will be monitored
and the state changes will remain visible, but a resource fault will not cause the
entire application to fault. In this case, the resource is considered a non-critical
resource.
If set to No, a failure of the current resource will cause the parent application to
fault.
If a Generic subapplication has a MonitorOnly parameter, its default value is No.

6.5.2.3   ScriptTimeout

Each subapplication instance is configured with scripts that ASCC uses during
online processing, offline processing, and fault processing. The ScriptTimeout
parameter of each instance specifies the time ASCC will wait for the script to
complete before sending a kill signal. The parameter is defined as follows:
ScriptTimeout
       Specifies the maximum time (in seconds) allowed for scripts to complete
       before they are sent a kill signal by ASCC. The default depends on the
       type of subapplication being configured. The valid input format options
       are:
       1. A single positive integer number. Example: 300
       2. A three-part, colon-separated string of the form
          "default_value:offline_value:online_value". The string must be
          enclosed in double-quotes. Example: "20:60:180"




96                                                               U42147-J-Z100-4-76
Generic Linux applications                                          Expert mode


        Typically, format 1 is used, in which case the value specified is used for
        all scripts. Only in rare cases would format 2 be used. The respective
        values in format 2 are:
        – default_value—timeout value used for all scripts other than offline and
          online scripts
        – offline_value—timeout for offline scripts
        – online_value—timeout for online scripts


6.5.3      Expert mode group options

In expert mode, an additional Group Options item is available for the current
subapplication (figure 61).




                                                                      asw0610
Figure 61: Subapplication group options (expert mode)

Group options allow you to set parameters that apply to all instances of the
current subapplication. These vary according to the subapplication type, but
either or both of the following two settings are available for every group:




U42147-J-Z100-4-76                                                              97
Expert mode                                            Generic Linux applications


NeedAll
      Defines how the combined state of the objects in the group is communi-
      cated to the parent object at runtime. If set to the default of Yes, the state
      is determined by a logical AND. If set to No, the state is determined by a
      logical OR.
       For example, suppose the configuration is as shown in figure 61 above,
       with one command line subapplication and two local file system subap-
       plications. As discussed earlier, PCS constructs the dependency tree
       (the graph) so the group of both file system objects is the child of the
       command line object. Now suppose one file system is in the faulted state
       while the other is online:
       – If NeedAll is set to Yes, the file system states are ANDed together, and
         the group reports its state as faulted to the parent command line
         object.
       – If NeedAll is set to No, the file system states are ORed together, and
         the group reports its state as online to the parent command line
         object.
FaultScript
       Defines a custom script for this group. By default, PCS does not provide
       a fault script for any group. If you want to implement a group fault script,
       the following information may be useful.
       PCS provides a fault script for individual objects of the form
       $PCSHOME/bin/pcs_alert <message>
       The <message> string includes the actual name of the object and is
       always recorded in the ASCC switchlog. If the ASCC hvconsoles file
       has been configured as described in the site preparation section “Config-
       uration resource definitions” on page 226, the message is also sent to a
       display or some other device to notify the operator. You can use a script
       of the same form; be sure to include the name of the group in your
       message. If you decide to use a different type of script, you should
       observe the following caution:
       V       Caution
              Do not customize script settings in a working ASCC configuration
              without the direction of ASCC support personnel. ASCC scripts
              run with root privilege, and an improperly designed script can
              cause system outages and loss of data. Scripts provided with
              PCS have been written and tested by ASCC experts.



98                                                               U42147-J-Z100-4-76
Generic Linux applications                                              Expert mode


6.5.4      Dynamic subapplications

All the subapplications in the Generic application template allow you to insert an
additional dynamic subapplication within a standard subapplication. The
dynamic subapplication, which is usually a different type than the parent,
creates an additional level of hierarchy and control over all the child instances.
It is most often used when you want to exercise some runtime control over
resources that are otherwise static.
For example, it may be desirable to insert a command line subapplication into a
local file system subapplication (figure 62).




                          asw0611
Figure 62: Dynamic Command Line inserted in Local File System subapplication

In this case, the DiskMonitor command line instance acts as a parent to the file
systems mounted on /mnt1 and /mnt2: both file systems must be brought
online before the DiskMonitor start command is issued, and both will be taken
offline after the DiskMonitor stop command is issued.
Moreover, it is the DiskMonitor command line set that actually reports the status
of the group consisting of /mnt1 and /mnt2. For instance, DiskMonitor’s Check
command could be written to return a normal status if at least one of the file
systems were mounted, and to return a fault only when both file systems were
offline. You could then take one of the file systems offline without causing a fault
in the overall configuration.
I In general, when a dynamic subapplication is present, it takes over status
        reporting for the entire group, regardless of the state of any of the
        instances. It is also responsible for passing online, offline, fault
        processing, and other requests to the instances in the group.




U42147-J-Z100-4-76                                                               99
Expert mode                                                  Generic Linux applications


6.5.4.1    Inserting a dynamic subapplication

To insert a dynamic subapplication, use the following procedure:
Ê In expert mode, click on a subapplication in the left pane with one or more
  configured instances. The Edit menu will contain an active Dynamic Subappli-
  cation item with a checkbox (figure 63).




                  pcs0616
Figure 63: Creating a dynamic subapplication (expert mode)

Ê Click the checkbox to advance to a view where you can select a subappli-
  cation template (figure 64).




100                                                                  U42147-J-Z100-4-76
Generic Linux applications                                        Expert mode




                                                                   asw0612
Figure 64: Dynamic subapplication options (expert mode)

Ê Select the desired subapplication template from the dropdown list
  (figure 65).




Figure 65: Choosing a dynamic subapplication type (expert mode)

Ê To change the instance name, type the new name directly into the Subappli-
  cation Name input box.
Ê Click Next to advance to the standard description of the subapplication
  (figure 66).




U42147-J-Z100-4-76                                                           101
Expert mode                                                Generic Linux applications




                                                                         asw0613
Figure 66: Dynamic subapplication configuration (expert mode)

From this point on, you can configure the new dynamic subapplication with the
usual procedure.
Note the following points when you work with dynamic subapplications:
●   Dynamic subapplications can only be inserted in the first-level subapplica-
    tions, i.e., they cannot be nested.
●   Only one type of dynamic subapplication can be inserted in a parent subap-
    plication. You cannot, for example, insert both a dynamic command line and
    a dynamic IP address in the same parent subapplication.
●   You can create additional instances of the same dynamic subapplication by
    using Edit –> Add More Instance from the menu or the Add More button at the
    bottom of the view.
●   To remove a dynamic subapplication, click on the instance and then select
    Edit –> Delete –> Instance from the menu.
●   You can exit expert mode any time after the dynamic subapplication instance
    has been created. Once created, a dynamic subapplication will appear in the
    left pane, even if you return to standard mode.




102                                                                U42147-J-Z100-4-76
7         Program and process control
The internal ASCC application object usually represents one or more external,
real-world processes. To create a high availability configuration, there must be
an interface that allows the internal object to control and monitor the external
process(es). The subapplication described in this chapter provides that
interface.
Chapter contents:
●   “Command Line subapplication” on page 104




U42147-J-Z100-4-76                                                          103
Command Line subapplication                        Program and process control


7.1        Command Line subapplication
The Command Line subapplication provides a general-purpose point of control
for a program or process of your choice. It is typically used to control the ASCC
application’s primary program, but it may also be used to control any number of
related programs or processes. You must specify a Start command that brings
the program online. You can also specify a Stop command to take the program
offline, and a Detector command to report the program status.
figure 67 shows the initial view of a new Command Line subapplication.




Figure 67: Command Line initial view

You can modify the following parameters from this view:
Start command (required)
        Enter the command to start this program. ASCC executes this command
        to bring the program online.
       The subapplication will be marked as consistent after you enter this
       command.
Stop command
       Enter the command to stop this program. ASCC executes this command
       to take the program offline.


104                                                            U42147-J-Z100-4-76
Program and process control                     Command Line subapplication


Detector command
       Enter the command to monitor this program. The detector
       <PCSHOME>/bin/pcsdet_system executes the script specified for
       the Detector Command at approximately 10 second intervals and reports
       its status to ASCC.
The Start, Stop, and Detector commands may be entered just as they would be
from the ksh command line.
●   In many cases, it is best to create a separate script file with the proper
    command sequence and then enter the script file name in PCS. Be sure that
    the script has execute permission set and that it returns the proper exit code.
●   Use absolute path names for all commands and files to avoid unexpected
    results.
figure 68 shows a complete command set.




Figure 68: Command Line parameters

The OS-independent example shown here is for demonstration purposes only,
so it uses the touch, rm and ls system commands with relative path names. Its
operation is explained in “Command Line processing notes” on page 109.
Ê After you enter the commands, click Next to continue to the next subappli-
  cation.


U42147-J-Z100-4-76                                                             105
Command Line subapplication                            Program and process control


7.1.1      Expert mode parameters

Use the Option –> Expert Mode checkbox to see all available parameters
(figure 69).




Figure 69: Command Line parameters (expert mode)

I If Detector command is not specified, only the NullDetector and Script-
        Timeout parameters appear.
You can modify the following additional parameters from this view:
AutoRecover
      Default: Yes. See the section “AutoRecover” on page 96.
MonitorOnly
      Default: No. See the section “MonitorOnly” on page 96.
Lie Offline
       Some programs cannot be stopped while the system is up and running.
       If this flag is set to Yes, this command reports itself as offline (it “lies”) so
       that ASCC can continue a normal shutdown. Default: No if Stop command
       is specified, and Yes otherwise




106                                                                 U42147-J-Z100-4-76
Program and process control                          Command Line subapplication


NullDetector
      This value cannot be modified directly. If Detector command is not
      specified, NullDetector is set to on, and ASCC cannot determine the
      state of this program. If Detector command is specified, NullDetector is set
      to off.
RealTime
      If set to TS, the Detector command is started in the time sharing scheduling
      class. If set to RT, the Detector command is started in the real time sched-
      uling class. Default: TS
       I Processes in the RT class have the highest priority, so deficiencies
               in a script could have a significant adverse effect when run in this
               scheduling class.
AllExitCodes
       If set to No (default), script exit codes are interpreted as follows:
       – 0 (zero): online
       – not 0 (not zero): offline
       If set to Yes, the exit codes are interpreted according to the Edit return
       codes? setting described below.
ScriptTimeout
       Default: 300 seconds. See the section “ScriptTimeout” on page 96.
Edit return codes?
        If set to Yes, the view changes so you can configure custom exit codes for
        the resource (figure 70).




Figure 70: CmdLine custom exit codes (expert mode)




U42147-J-Z100-4-76                                                             107
Command Line subapplication                        Program and process control


7.1.2      Expert mode group options

In expert mode, the Command Line Group Options are available (figure 71).




Figure 71: CmdLine group options (expert mode)

You can modify the following parameters from this view:
InParallel
      If set to No, Command Line instances are processed sequentially during
      online or offline processing, and the NeedAll parameter is disabled. If set
      to Yes, Command Line instances start and stop in parallel, and the NeedAll
      parameter is enabled. Default: No
NeedAll
      See the section “Expert mode group options” on page 97.
FaultScript
       See the section “Expert mode group options” on page 97.




108                                                            U42147-J-Z100-4-76
Program and process control                    Command Line subapplication


7.1.3     Command Line processing notes

To illustrate how the scripts work, we will use the same scripts shown in
figure 69:
●   Start command: ‘touch /tmp/HelloWorld’ (creates a file)
●   Stop command: ‘rm -f /tmp/HelloWorld’ (removes the file)
●   Detector command: ‘ls /tmp/HelloWorld’ (determines if the file exists)
The operations for the CommandLine subapplication are executed in the
following order:
1. The Detector Command is first executed at ASCC startup and repeated at
   regular intervals; by default the interval is 10 seconds. The detector
   command should return a zero status code when the application is online,
   and a non-zero status code when the application is offline.
    In this example, ‘ls /tmp/HelloWorld’ will return a zero status code if the
    file exists, and non-zero otherwise. Assuming the file does not exist when
    ASCC starts up, the detector will initially return a non-zero status. ASCC
    interprets this to mean the subapplication is offline.
2. The Start Command is executed whenever the application receives a directive
   to go online. This script is executed automatically if the application’s
   AutoStartUp option is set to Yes. If AutoStartUp is set to No, the default, the
   script will be executed when you use the Cluster Admin GUI or the
   hvswitch command to manually instruct the application to go online. In any
   case, the start command should return a zero status code to indicate
   successful completion, and a non-zero status code otherwise.
    In this example, ‘touch /tmp/HelloWorld’ creates the file specified in the
    detector script and returns a zero status code. Subsequent execution of the
    detector will return a zero status code as long as the file is present. ASCC
    interprets this to mean the subapplication is online.
3. The Stop Command is executed when a fault occurs or when the application
   is to be taken offline. During normal operation, the application may be
   automatically taken offline on the local node before ASCC switches it to
   another node; the application may also be taken offline manually via the GUI
   or CLI.




U42147-J-Z100-4-76                                                            109
Command Line subapplication                      Program and process control


  In this example, ‘rm -f /tmp/HelloWorld’ removes the file specified in
  the detector script. Subsequent executions of the detector return a non-zero
  status code, which ASCC interprets to mean the subapplication is offline.
  Note that the file could have been deleted manually by the operator, in which
  case the detector would also return a non-zero status. However, since this
  happened without an intervening Stop Command, ASCC would interpret this
  as a fault, and it would initiate its standard recovery procedure.
  Note also that this demonstration requires /tmp/HelloWorld to be deleted
  manually if the application is killed before the Stop Command is executed.




110                                                          U42147-J-Z100-4-76
8         File systems and disk devices
This chapter describes the standard PCS subapplication templates for config-
uring file systems and raw disk devices.
Chapter contents:
●   “Local File System subapplication” on page 112
●   “Remote File System subapplication” on page 117
●   “Raw Disk subapplication” on page 122




U42147-J-Z100-4-76                                                       111
Local File System subapplication                     File systems and disk devices


8.1         Local File System subapplication
The Local File System subapplication configures local file systems for high avail-
ability. The file systems are capable of being switched online on any node in the
configuration.
Before you can configure a local file system with PCS, you must create the
appropriate #RMS# entry in the local host’s file system database. See the site
preparation description in the section “/etc/fstab.pcl” on page 229.
The initial view of a new Local File System subapplication lists the available file
systems (figure 72).




Figure 72: Local File System initial view

You can modify the following parameters from this view:
Local mount point (required)
       The list of mount points available for configuration. The initial list is taken
       from the local host’s /etc/fstab.pcl file.
        To make an additional mount point available, enter its absolute path in the
        Local mount point input box and then click the Add button.




112                                                                U42147-J-Z100-4-76
File systems and disk devices               Local File System subapplication


Local mount point name filter
       Restrict the list of names displayed in the drop-down list with the pattern
       shown here. The filter string can include any characters valid in a fully
       qualified path plus the standard shell wildcards. Examples:
       */ora* *mnt*
       The filter takes effect when you press the [Enter] key or click Next.
Ê To select a mount point, highlight its name in the list and then click Next.
   To highlight multiple mount points, hold down the [Ctrl] key while you click in
   the list.
The next view displays your selection as a new instance in the configuration
tree, and the subapplication is marked as consistent (figure 73).




Figure 73: Local File System parameters

There are no additional parameters to configure in this view.
Ê Click Next to continue to the next subapplication.




U42147-J-Z100-4-76                                                             113
Local File System subapplication                        File systems and disk devices


8.1.1      Expert mode parameters

Use the Option –> Expert Mode checkbox to see all available parameters
(figure 74).




Figure 74: Local File System parameters (expert mode)

You can modify the following additional parameters from this view:
AutoRecover
      Default: Yes. See the section “AutoRecover” on page 96.
MonitorOnly
      Default: No. See the section “MonitorOnly” on page 96.
KeepOnline
     If set to Yes, the file system will be brought on line during online
     processing, but it will not be taken offline during offline processing. This
     makes the file system available for other applications and utilities even
     when ASCC is shut down. Default: No
        I Setting this flag allows the file system to be mounted and online
               on more than one node at a time.




114                                                                U42147-J-Z100-4-76
File systems and disk devices                 Local File System subapplication


Share
        If set to Yes, the file system is shared based on the settings in the #RMS#
        entries in the local host’s exported file system database. See the site
        preparation description in the section “/etc/exports.pcl” on page 231 for
        Linux.
        I A local file system that can failover to other nodes in the cluster
               must have the same combination of major device number and
               minor device number everywhere it is exported via NFS. See
               “NFS servers” on page 233 for more information.
        By default, the shared file system is not synchronized with any NFS
        client. If the client is under ASCC control and has mounted the file
        system with the Remote File System subapplication, it will not detect a
        server shutdown. In this case, setting the server’s Sync flag (see below)
        is recommended.
        Default: No
Sync
        If set to Yes, a shared local file system that is shut down will propagate a
        shutdown to every client that mounted this file system. This will contribute
        an extra delay to the overall ASCC shutdown process, and the Script
        Timeout setting for this instance my have to be increased accordingly. For
        more information about file system synchronization, see “Synchronized
        NFS file systems” on page 236. Default: No




U42147-J-Z100-4-76                                                              115
Local File System subapplication                       File systems and disk devices


8.1.2      Expert mode group options

In expert mode, the Lfs Group Options are available (figure 75).




Figure 75: Local File System group options (expert mode)

The following items can be configured from the Group Options view:
NeedAll, FaultScript
      See the section “Expert mode group options” on page 97.




116                                                               U42147-J-Z100-4-76
File systems and disk devices                Remote File System subapplication


8.2         Remote File System subapplication
The Remote File System subapplication configures file systems that are exported
from other hosts and accessed through a mount point on the local node. If the
parent application is switched to another node in the cluster, the remote file
system is first dismounted on the original node and then mounted on the new
node.
I The PCS Remote File System subapplication supports only NFS file
        systems.
Before you can configure a remote file system with PCS, you must create the
appropriate #RMS# entry in the local host’s file system database. See the site
preparation description in the section “/etc/fstab.pcl” on page 229.
The initial view of a new Remote File System subapplication lists the available file
systems (figure 76).




Figure 76: Remote File System initial view

You can modify the following parameters from this view:
NFS mount point (required)
     The list of mount points available for configuration. The initial list is taken
     from the local host’s /etc/fstab.pcl file.


U42147-J-Z100-4-76                                                              117
Remote File System subapplication                 File systems and disk devices


       To make an additional mount point available, enter its absolute path in the
       NFS mount point input box and then click the Add button.
       I ASCC will mount the file system in a private directory. A symbolic
              link with the name you enter here will point to the private mount
              point. For additional details, see “NFS mount point management”
              on page 235.
NFS mount point name filter
     Restrict the list of names displayed in the drop-down list with the pattern
     shown here. The filter string can include any characters valid in a fully
     qualified path plus the standard shell wildcards. Examples:
     */ora* *mnt*
       The filter takes effect when you press the [Enter] key or click Next.
Ê To select a mount point, highlight its name in the list and then click Next.
   To highlight multiple mount points, hold down the [Ctrl] key while you click in
   the list.
The next view displays your selection as a new instance in the configuration
tree, and the subapplication is marked as consistent (figure 77).




Figure 77: Remote File System parameters




118                                                            U42147-J-Z100-4-76
File systems and disk devices               Remote File System subapplication


There are no additional parameters to configure in this view.
Ê Click Next to continue to the next subapplication.


8.2.1      Expert mode parameters

Use the Option –> Expert Mode checkbox to see all available parameters
(figure 78).




Figure 78: Remote File System parameters (expert mode)

You can modify the following additional parameters from this view:
AutoRecover
      Default: Yes. See the section “AutoRecover” on page 96.
MonitorOnly
      Default: No. See the section “MonitorOnly” on page 96.
KeepOnline
     If set to Yes, the file system will be brought online during online
     processing, but it will not be taken offline during offline processing. This
     makes the file system available for other applications and utilities even
     when ASCC is shut down. Default: No



U42147-J-Z100-4-76                                                           119
Remote File System subapplication                    File systems and disk devices


       V Caution
              Do not set the KeepOnline flag if the file system must be cluster
              exclusive (used by only one node at a time). If this flag is set, the
              file system can be mounted and online on more than one node at
              a time.
Sync
       If set to Yes, the remote file system being synchronized with the NFS
       server will start only if the server is accessible, and it will shut down if the
       server shuts down. For more information about file system synchroni-
       zation, see “Synchronized NFS file systems” on page 236. Default: No
FileSystemType
       Default: nfs
ScriptTimeout
       Default: 180 seconds. See the section “ScriptTimeout” on page 96.




120                                                                U42147-J-Z100-4-76
File systems and disk devices                Remote File System subapplication


8.2.2      Expert mode group options

In expert mode, the NFS Group Options are available (figure 79).




Figure 79: Remote File System group options (expert mode)

You can modify the following parameters from this view:
NeedAll, FaultScript
      See the section “Expert mode group options” on page 97.




U42147-J-Z100-4-76                                                        121
Raw Disk subapplication                              File systems and disk devices


8.3         Raw Disk subapplication
The Raw Disk subapplication monitors local physical disks. It ensures that raw
devices are accessible throughout the configuration by creating a symbolic link
with the same name on every node. Each link refers to a local physical disk,
which may have a different name from node to node.
figure 80 shows the initial view of a new Raw Disk subapplication.




Figure 80: Raw Disk initial view

You can modify the following parameters from this view:
Raw Disk (required)
      The list of raw disk devices available for configuration. The initial list
      displays all raw disk devices on the system according to the following
      criteria:
        ●   The default list includes only raw disks in /dev/raw if that directory
            exists. Otherwise, the default list includes all raw disks in the /dev/rd
            directory, and all raw disks that match the pattern /dev/sd*,
            /dev/hd*, and /dev/md*.
            I The raw command can be used to associate block devices
                    with raw disks in the /dev/raw directory.


122                                                               U42147-J-Z100-4-76
File systems and disk devices                            Raw Disk subapplication


       ●   The list includes raw disks that are members of configured volume
           managers such as LVM. However, the list excludes the encapsulating
           virtual disks.
       ●   The list excludes raw disk partitions used for the root, /usr, /var and
           swap partitions.
       To make an additional device available, enter its absolute path in the Raw
       Disk input box and then click the Add button.
Raw Disk name filter
      The raw disks displayed in the Raw Disk drop-down list can be limited by
      the pattern entered in the Raw Disk name filter string. The pattern can
      include any characters valid in a fully qualified path plus the standard
      shell wildcards. For example, entering *s3 will limit all disks that reside
      in the default raw disk directories to disks ending with the string s3.
       If the string entered for Raw Disk name filter is a full path name such as
       /dev/vd/r*, then all raw devices in the path will be displayed in the
       Raw Disk drop-down list.
       V Caution
              Use care when specifying a full path name as the Raw Disk name
              filter. All raw devices will be displayed in the Raw Disk dropdown
              list, even if they are currently in use or if they are not a disk device.
       The filter takes effect when you press the [Enter] key or click Next.
Ê To select a device, highlight its name in the list and then click Next.
   To highlight multiple devices, hold down the [Ctrl] key while you click in the
   list.




U42147-J-Z100-4-76                                                                 123
Raw Disk subapplication                            File systems and disk devices


The next view displays your selection as a new instance in the configuration
tree, and the subapplication is marked as consistent (figure 81).




Figure 81: Raw Disk parameters

Note that the scrolling list collapses to a drop-down list after you have selected
a device.
You can modify the following parameters from this view:
Symbolic link suffix
      The common link name for this device. The link will be created with this
      name in <PCSHOME>/dev/rawdisk on all nodes. By default, PCS
      uses the base name of the selected device on the local node.
       For example, if the real device is /dev/raw/raw1, and the chosen suffix
       is raw1, then PCS creates a link from /dev/raw/raw1 to
       <PCSHOME>/dev/rawdisk/raw1.
Ê Click Next to continue.




124                                                            U42147-J-Z100-4-76
File systems and disk devices                           Raw Disk subapplication


8.3.1      Expert mode parameters

Use the Option –> Expert Mode checkbox to see all available parameters
(figure 82).




Figure 82: Raw Disk parameters using clusterwide name

You can modify the following additional parameters from this view:
ScriptTimeout
       Default: 60 seconds. See the section “ScriptTimeout” on page 96.




U42147-J-Z100-4-76                                                         125
Raw Disk subapplication                           File systems and disk devices


8.3.2      Expert mode group options

In expert mode, the Raw Disk Group Options are available (figure 83).




Figure 83: Raw Disk group options (expert mode)

You can modify the following parameters from this view:
Keep global device link?
       Defines whether or not the symbolic link to the real device is removed
       during offline processing. If set to Yes, the symbolic link will not be
       removed during offline processing and the resource object will remain
       online after offline processing has completed. If set to No, the symbolic
       link will be removed during offline processing and the resource object will
       go offline. Default: No




126                                                            U42147-J-Z100-4-76
File systems and disk devices                        Raw Disk subapplication


PreOnlineScript, PostOnlineScript, PreOfflineScript, PostOfflineScript
      PCS provides an appropriate default script for each of these items if it is
      empty.
       V      Caution
              Do not customize script settings in a working ASCC configuration
              without the direction of ASCC support personnel. ASCC scripts
              run with root privilege, and an improperly designed script can
              cause system outages and loss of data. Scripts provided with
              PCS have been written and tested by ASCC experts.
FaultScript
       See the section “Expert mode group options” on page 97.




U42147-J-Z100-4-76                                                           127
9         Virtual connections
This chapter describes the standard PCS subapplication templates for config-
uring virtual network connections that follow the application when it is switched
to another node.
Chapter contents:
●   “Ip Address subapplication” on page 130
●   “Virtual Host Name subapplication” on page 136




U42147-J-Z100-4-76                                                           129
Ip Address subapplication                                    Virtual connections


9.1       Ip Address subapplication
The Ip Address subapplication is used to configure network addresses (or host
names) for high availability and high resilience. The network address is
associated with the node where the parent application is online. When the appli-
cation switches to another node, the network address is transferred as well. The
actual node associated with the network address is transparent to the user, who
continues to communicate via the same IP address.
It is possible for several IP addresses (aliases) to be allocated to one physical
network interface. If the first network address on an interface (known as the
“base” network address) is deconfigured, then all other network addresses on
that interface will be deconfigured as well. To prevent this, PCS allows network
addresses to be configured as a “basic interface” (type Basic-If), which means
they are not switched during offline processing.
I Before a network address can be configured with the Ip Address subap-
       plication, it must be entered in /etc/hosts and
       <RELIANT_PATH>/etc/hvipalias.satellite as described in the
       section “Configuration resource definitions” on page 226.
       Note that you must modify the hosts and hvipalias.satellite files
       on the satellite node, not on the control nodes.
I To avoid network conflicts, a network hostname or address monitored by
       the Ip Address subapplication can be active on only one node in the
       cluster at any time. A task group that contains a configured Ip Address
       should have a maximum instance count no greater than 1.
The initial view of a new Ip Address subapplication displays the interface names
in the hvipalias.satellite file (figure 84).




130                                                            U42147-J-Z100-4-76
Virtual connections                                  Ip Address subapplication




Figure 84: Ip Address initial view

You can modify the following parameters from this view:
IP name
      The list of IP addresses or host names available for configuration. The
      initial list is taken from the
      <RELIANT_PATH>/etc/hvipalias.satellite file.
        To make additional addresses or names available, enter a value in the IP
        name input box and then click the Add button.
IP name filter
      Restrict the list of names displayed with the pattern shown here. The filter
      string can consist of alphanumeric characters plus the standard shell
      wildcards. Examples: *intf* *ip1*
        The filter takes effect when you press the [Enter] key or click Next.
Ê Highlight the name of an interface in the list, and then click Next.
The next view displays your selection as a new instance in the configuration
tree, and the subapplication is marked as consistent (figure 85).




U42147-J-Z100-4-76                                                              131
Ip Address subapplication                                      Virtual connections




Figure 85: Ip Address parameters

You can modify the following parameters from this view:
Base
       If set to Yes, this IP name is a base address. It is possible for several IP
       addresses (aliases) to be allocated to one physical network interface. If
       the first network address on an interface (known as the “base” network
       address) is deconfigured, then all other network addresses on that
       interface will be deconfigured as well. A base address is deconfigured
       during offline processing. Default: No
Basic-If
       If set to Yes, the interface is not switchable. The AutoRecover feature is
       enabled and there is no offline processing.
       If you use the Basic-If feature, then the application containing this
       Ip Address subapplication is not allowed to be defined for more than one
       host, because a Basic-If interface is not switchable.
       If IP address failover is specified for a physical interface, or MAC address
       failover is specified for an interface, all of the logical IP addresses
       associated with that interface should be configured under the same user
       application that configures physical interface failover or MAC address




132                                                             U42147-J-Z100-4-76
Virtual connections                                    Ip Address subapplication


        failover. Otherwise, failover of the physical interface or MAC address will
        cause the logical interfaces configured on that physical interface to be
        lost.
        When an application unrelated to ASCC (e.g., Cluster Admin and
        Shutdown Facility) use a network interface, you should not use that
        interface for base address failover: when that application is offline, other
        applications will not be able to communicate through its interface.
Ping
        Set to Yes to enable the ping host list (figure 86). Default: No




Figure 86: Ip Address ping host list

PingHosts List
      If the Ping flag is set to Yes a list of hosts is presented in the PingHost List
      field. A ping host is used to confirm network connectivity from the
      configured IP address to the selected destination(s). Connectivity to one
      ping host is considered success. It is advisable to configure more than
      one ping host for an IP address, in case one of the hosts is down.
        It is possible that a ping host can be reached though an alternate network
        path that does not use the interface assigned to the IP address. In this
        case, the network connectivity test may not be valid. Work with your
        network administrator when determining the appropriate ping hosts for
        an IP address.
        The initial ping host list is taken from the /etc/hosts file. To make
        additional addresses or names available, enter a value in the Ping Host
        List input box and then click the Add button.
Ê Click Next to continue to the next subapplication.




U42147-J-Z100-4-76                                                                133
Ip Address subapplication                                  Virtual connections


9.1.1      Expert mode parameters

Use the Option –> Expert Mode checkbox to see all available parameters
(figure 87).




Figure 87: Ip Address parameters (expert mode)

You can modify the following additional parameters from this view:
AutoRecover
      Default: Yes. See the section “AutoRecover” on page 96.
MonitorOnly
      Default: No. See the section “MonitorOnly” on page 96.
ScriptTimeout
       Default: 60 seconds. See the section “ScriptTimeout” on page 96.




134                                                         U42147-J-Z100-4-76
Virtual connections                                 Ip Address subapplication


9.1.2      Expert mode group options

In expert mode, the Ip Address Group Options are available (figure 88).




Figure 88: Ip Address group options (expert mode)

You can modify the following parameters from this view:
NeedAll, FaultScript
      See the section “Expert mode group options” on page 97.




U42147-J-Z100-4-76                                                        135
Virtual Host Name subapplication                              Virtual connections


9.2         Virtual Host Name subapplication
The Virtual Host Name subapplication is used to configure a host name that is to
be associated with the machine where the parent application is online. The
virtual host name (VHN) can optionally be assigned an IP address. When the
application switches to another node, the hostname and IP address (if defined)
are transferred as well. The actual node associated with the virtual host is trans-
parent to the user, who continues to communicate via the same host name.
The initial view of a new Virtual Host Name subapplication requires you to define
a virtual host name (figure 89).




Figure 89: Virtual Host initial view

You can modify the following parameters from this view:
Virtual Host Name
       You have three choices here:
        1. You can use the dropdown list of fixed host names taken from the
           /etc/hosts file.
        2. You can type a fixed host name directly into the input box.




136                                                             U42147-J-Z100-4-76
Virtual connections                          Virtual Host Name subapplication


        3. You can type a script name directly into the input box. This must be
           an absolute path name that begins with a slash (/). ASCC will execute
           the script at runtime to generate a host name based on the instance
           ID within the task group, or on any other criterion you build into the
           script. The next subsection provides more information.
        To avoid network conflicts, a fixed network hostname or address
        monitored by the Virtual Host Name subapplication can be active on only
        one node in the cluster at any time.
        I A task group that contains a fixed virtual host name in its configu-
               ration should have a maximum instance count no greater than 1.
Virtual Host Name filter
       If you use the dropdown list to select names from /etc/hosts, you can
       filter the displayed list with the pattern shown here. The filter string can
       contain alphanumeric characters as well as the standard shell wildcards.
       Examples: *intf* *ip1*
        The filter takes effect when you press the [Enter] key or click Next.


9.2.1      Generating virtual host names

You can create a script that generates a unique virtual host name for each new
instance of a deployed image. To direct ASCC to use the script, enter its
absolute path name in the Virtual Host Name input box, followed by any param-
eters you want to pass to the script. The script must comply with the following
rules:
●   The script must print the generated host name on stdout.
●   The script must return an exit code of zero for success, and non-zero
    otherwise.
ASCC provides the sat_getinstanceid command that returns the node’s
unique instance ID within its task group at runtime. You can use this in your
script to create part of the virtual host name. Execute the command as follows:
/opt/SMAW/SMAWRrms/bin/sat_getinstanceid groupname
The only argument, groupname, is the name of the local node’s task group. The
sat_getinstanceid command prints the instance ID on stdout.




U42147-J-Z100-4-76                                                              137
Virtual Host Name subapplication                            Virtual connections


Example:
Suppose you had a group called ‘oracle_group’, and you wanted each
satellite in this group to have a name of the form ‘orasat<n>’ where <n> is the
node ID. Thus, the satellite nodes would have VHNs like ‘orasat1’, ‘orasat2’,
‘orasat3’, and so on. The following VHN script could be used.

#!/bin/sh
# This is a VHN script for the group ‘oracle_group’.
GROUPNAME=oracle_group
BASENAME=orasat
# Get the node id for this group.
nodeid=”`/opt/SMAW/SMAWRrms/bin/sat_getinstanceid $GROUPNAME`”
# Did we have a problem getting the node id?
if [ $? -ne 0 ]
then
     echo $0: Could not get Node Instance ID for group $GROUPNAME
     exit 1
fi
# Got the node id. Tell ASCC what our virtual hostname is.
echo ${BASENAME}${nodeid}
exit 0
To adapt this script for general use, you could instead define ‘GROUPNAME=$1’
and ‘BASENAME=$2’ and then execute the script with the task group name and
satellite base name as the first and second arguments, respectively.




138                                                          U42147-J-Z100-4-76
Virtual connections                        Virtual Host Name subapplication


9.2.2      Configuring a virtual IP address

Ê After you select the host name from the dropdown list, click Next.
You will advance to the virtual host parameters view (figure 90).




Figure 90: Virtual Host parameters

Before the subapplication can be marked as consistent, you must choose
whether or not to assign an IP address when this virtual host is enabled at
runtime.

9.2.2.1    Site preparation steps for runtime IP addresses

If you want ASCC to assign an IP address for a virtual host name at runtime,
you must first complete the following site preparation:
1. /etc/hosts must contain the usual association of the host name and IP
   address. See the section “Virtual host names in /etc/hosts” on page 225 for
   more information.
   Note that you can assign addresses for both fixed and generated names. For
   example, if your script will generate names of the form orasat<n>, where
   <n> ranges from 1 to 8, then all eight names with their respective IP
   addresses should appear in /etc/hosts.


U42147-J-Z100-4-76                                                            139
Virtual Host Name subapplication                              Virtual connections


    Entering generated names in /etc/host will cause them to appear in the
    dropdown list of fixed names. However, you would not select one of those
    names in the opening view, because PCS would then treat it as a fixed host
    name.
2. <RELIANT_PATH>/etc/hvipalias.satellite must contain one entry
   for each virtual host name on every satellite that may activate it. This
   identifies the network interface to be assigned to the VHN runtime.
    For instance, if the task group is limited to 8 instances, but those instances
    can be deployed to a server domain of 12 nodes, then you must create 8
    entries for each of the 12 nodes, or 72 total entries. See for the section
    “Configuration resource definitions” on page 226 for details.
You should complete the above site prep steps before you can configure the IP
address(es) in PCS.

9.2.2.2     Virtual host without IP address

Ê If you choose not to configure an IP address for this virtual host name, select
  No from the Configure VHN IP? dropdown list (figure 91).




Figure 91: Assigning an IP address to a virtual host

In the next view, the subapplication is marked as consistent (figure 92).




140                                                             U42147-J-Z100-4-76
Virtual connections                          Virtual Host Name subapplication




Figure 92: Virtual host with no IP address

There are no other parameters to modify in this view.




U42147-J-Z100-4-76                                                       141
Virtual Host Name subapplication                             Virtual connections


9.2.2.3     Virtual host with IP address

Ê If you choose to configure an IP address for this virtual host name, select Yes
  from the Configure VHN IP? dropdown list (figure 93).




Figure 93: Assigning an IP address to a virtual host

In the next view, the virtual host name appears as a new, inconsistent item in
the subapplication (figure 94).




Figure 94: Inconsistent virtual host with IP address

Ê Click Next to continue.




142                                                            U42147-J-Z100-4-76
Virtual connections                                  Virtual Host Name subapplication


When you advance to the next view, the virtual host name will be marked as
consistent (figure 95).




Figure 95: Consistent virtual host with IP address

Note that you do not have to define the IP address, because that is taken from
the appropriate entry in /etc/hosts. If you entered a script name, PCS cannot
determine whether or not the correct entries are present at configuration time.
It simply assumes the correct entries will be present at runtime, so it can look
up the IP address when the VHN is activated. If a generated VHN has no corre-
sponding IP address in /etc/hosts, ASCC will generate a runtime error.
You can modify the following additional parameters from this view:
Ping
        Set to Yes to enable the ping host list (figure 96). Default: No




U42147-J-Z100-4-76                                                               143
Virtual Host Name subapplication                                 Virtual connections




Figure 96: Selecting ping host for virtual host IP address

PingHosts List
      If the Ping flag is set to Yes a list of hosts is presented in the PingHost List
      field. A ping host is used to confirm network connectivity from the
      configured IP address to the selected destination(s). Connectivity to one
      ping host is considered success. It is advisable to configure more than
      one ping host for an IP address, in case one of the hosts is down.
        It is possible that a ping host can be reached though an alternate network
        path that does not use the interface assigned to the IP address. In this
        case, the network connectivity test may not be valid. Work with your
        network administrator when determining the appropriate ping hosts for
        an IP address.
        The initial ping host list is taken from the /etc/hosts file. To make
        additional addresses or names available, enter a value in the Ping Host
        List input box and then click the Add button.
Ê To select a ping host, highlight its name in the list and then click Next.
    To highlight multiple hosts, hold down the [Ctrl] key while you click in the list.




144                                                                U42147-J-Z100-4-76
Virtual connections                              Virtual Host Name subapplication


9.2.3      Expert mode parameters

If you use the Option –> Expert Mode checkbox to see all available parameters,
only the IP address has additional settings (figure 97).




Figure 97: Virtual host name with IP address (expert mode)

You can modify the following additional parameters from this view:
ScriptTimeout
       Default: 60 seconds. See the section “ScriptTimeout” on page 96.
Since only one virtual host name can be assigned to a satellite, there are no
group parameters. However, you can insert a dynamic subapplication as
described in “Dynamic subapplications” on page 99




U42147-J-Z100-4-76                                                           145
10        Volume and storage managers
This chapter describes the standard PCS subapplication templates for config-
uring commonly used volume and storage managers.
Chapter contents:
●   “Volume Manager subapplication group” on page 148
●   “LVM Linux Volume Manager subapplication” on page 150
●   “Storage Manager subapplication group” on page 155




U42147-J-Z100-4-76                                                       147
Volume Manager subapplication group                   Volume and storage managers


10.1       Volume Manager subapplication group
The Volume Manager group contains all available volume management subappli-
cations. If no volume managers are available for configuration on the local node,
the group will not appear in the PCS configuration tree.
I PCS can configure a volume management subapplication only if the
       following two conditions are true:
       1. The volume manager software is properly installed and configured on
          the local node.
       2. The corresponding PCS subapplication is properly installed and
          configured on the local node.
Initially, the group is shown as a single, optional item.
Ê To view the contents of the group, select Volume Manager in the configuration
  tree, check the box in the right pane (figure 98), and then click Next.




Figure 98: Selecting the Volume Manager group for configuration

Note that the group will be marked as inconsistent until one of the subapplica-
tions is properly configured. All volume management subapplications available
to the local node will appear as a subtree below the Volume Manager group.



148                                                               U42147-J-Z100-4-76
Volume and storage managers             Volume Manager subapplication group


figure 99 shows a typical set of volume management subapplications.




Figure 99: Selecting a member of the Linux Volume Manager group

The procedure for configuring each volume management subapplication is
described in a separate section following this one.




U42147-J-Z100-4-76                                                       149
LVM Linux Volume Manager subapplication Volume and storage managers


10.2       LVM Linux Volume Manager subapplication
The LVM subapplication controls one or more virtual disk groups managed by
the Linux Volume Manager. The monitoring of virtual disks is an optional
feature, but it is useful to receive alert messages when virtual disks fail. When
a virtual disk fails, the corresponding resource in the Cluster Admin display will
change its status to faulted (red status icon). The user application will stay
online as long as the disk group is imported and the detector reports it as online.
I The default local major and minor device numbers assigned to a physical
       volume by the Linux Volume Manager are indeterminate. This will usually
       prevent transparent failover when the volume is shared as an NFS file
       system. See “NFS servers” on page 233 for more information.
figure 100 shows the initial view of a new LVM subapplication.




Figure 100: Linux Volume Manager initial view

You can modify the following parameters from this view:
LVM disk group (required)
     Enter the disk group number or choose one from the drop-down list.




150                                                             U42147-J-Z100-4-76
Volume and storage managers LVM Linux Volume Manager subapplication


LVM disk group filter
     Restrict the list of disk groups displayed by the pattern shown here. The
     filter string can consist of alphanumerics plus the standard shell
     wildcards. Examples: *0* *21*
       The filter takes effect when you press the [Enter] key or click Next.
Ê After you select the disk group, click Next.
The next view displays your selection as a new instance in the configuration
tree. The subapplication is marked as consistent (figure 101).




Figure 101: Linux Volume Manager parameters

Ê Click Next to continue to the next subapplication.




U42147-J-Z100-4-76                                                             151
LVM Linux Volume Manager subapplication Volume and storage managers


10.2.1 Expert mode parameters

Use the Option –> Expert Mode checkbox to see all available parameters
(figure 102).




Figure 102: Linux Volume Manager parameters (expert mode)

You can modify the following additional parameters from this view:
AutoRecover
      Default: Yes. See the section “AutoRecover” on page 96.
MonitorOnly
      Default: No. See the section “MonitorOnly” on page 96.
Share
        To share the disk among multiple machines, set Share to Yes. Default: No
        OPS-type configurations require the disk to be shared among all nodes
        in cluster. In this case, you must also set “ops” in /etc/dktab
KeepOnline
     If set to Yes, the disk group is not dismounted from the local node when
     the parent application goes offline. Default: No




152                                                           U42147-J-Z100-4-76
Volume and storage managers LVM Linux Volume Manager subapplication


      V Caution
             Do not rely on the KeepOnline setting to allow two independent
             applications to share a single disk group on the same node. The
             disk group resource is still used in the ClusterExclusive=1
             mode. High availability and cluster performance may be compro-
             mised if only one of the applications is switched to another node.
ScriptTimeout
       This defines the time interval in seconds for configuration and deconfig-
       uration of the specified disk groups before triggering an error response.
       See the section “ScriptTimeout” on page 96. Default: 60 seconds.




U42147-J-Z100-4-76                                                          153
LVM Linux Volume Manager subapplication Volume and storage managers


10.2.2 Expert mode group options

In expert mode, the LVM Group Options are available (figure 103).




Figure 103: Linux Volume Manager group options (expert mode)

You can modify the following parameters from this view:
FaultScript
       See the section “Expert mode group options” on page 97.




154                                                            U42147-J-Z100-4-76
Volume and storage managers               Storage Manager subapplication group


10.3       Storage Manager subapplication group
The Storage Manager group contains all available storage interconnect
management subapplications. If no storage interconnect managers are
available for configuration on the local node, the group will not appear in the
PCS configuration tree.
I PCS can configure a storage management subapplication only if the
       following two conditions are true:
       1. The storage interconnect software is properly installed and
          configured on the local node.
       2. The corresponding PCS subapplication is properly installed and
          configured on the local node.
Initially, the group is shown as a single, optional item.
Ê To view the contents of the group, select Storage Manager in the configuration
  tree, check the box in the right pane (figure 104), and then click Next.




Figure 104: Selecting the Storage Manager group for configuration




U42147-J-Z100-4-76                                                            155
Storage Manager subapplication group                Volume and storage managers


All storage interconnect management subapplications available to the local
node will appear as a subtree below the Storage Manager group (figure 105).




Figure 105: Selecting a member of the Storage Manager group

Note that the group will be marked as inconsistent until one of the subapplica-
tions is properly configured.
I The optional storage management subapplications are available in the
       PCS Storage Management Wizard Kit.




156                                                            U42147-J-Z100-4-76
11        Linux configuration example
This chapter provides an example of the application monitoring configuration
process using PCS for Linux. The configuration consists of one application with
simple Command Line, Local File System, Remote File System, and Ip Address
subapplications. It can be created, activated, and run on a small ASCC cluster
with relatively few adjustments for the local environment.
This example is extracted from the more detailed procedures described in the
previous two chapters. To illustrate the workflow, only the necessary steps are
presented here.
Chapter contents:
●   “Site preparation” on page 158 lists the requirements for the configuration.
●   “Configuration procedure” on page 159 describes how to open, edit, save,
    and activate the configuration.
●   “Testing the configuration” on page 175 describes how to use the configu-
    ration graph to test application operation.
●   “Viewing node and application logs” on page 182 describes how to display
    application monitoring logs.
●   “Taking the image” on page 190 describes how to save the node image that
    contains the configuration.




U42147-J-Z100-4-76                                                           157
Site preparation                                     Linux configuration example


11.1        Site preparation
For this example, we will use bxsat1 as the reference node. The system files
on bxsat1 include the following lines:
●   /etc/hosts
    # PCS Demo interface
    172.25.222.223    demovip
    172.25.222.224    demohost
    # Ping hosts
    172.25.222.165    london
●   /etc/fstab.pcl
    #RMS#/dev/sda3    /mnt1    ext3 \
              defaults   1 2
    #RMS#boat:/opt/SUNWspro    /opt/SUNWspro    nfs \
              defaults,nfsvers=2,rsize=8192,wsize=8192
●   /opt/SMAW/SMAWRrms/etc/hvipalias.satellite
    SATELLITE_NODE      demovip eth0        0xffffff00
    SATELLITE_NODE      demohost eth0       0xffffff00
The following mount points exist on bxsat1:
●   /mnt1
●   /opt/SUNWspro
The following file system has been created with fdisk on bxsat1:
●   /dev/sda3
The following hosts exist and are accessible from bxsat1:
●   london
    This is the deployment server for the ASCC cluster. It will also be configured
    as a ping host for the demohost Ip Address subapplication.
●   boat
    This is the location of the shared /opt/SUNWspro file system. It will be
    configured for the Remote File System subapplication.
If you wish to create an equivalent configuration on your local ASCC cluster, you
should replace the above names and IP addresses accordingly.




158                                                             U42147-J-Z100-4-76
Linux configuration example                        Configuration procedure


11.2        Configuration procedure
Ê From the ASCC GUI, open the ASCC wizard with Tools –> ASCC Wizard
  (figure 107).




Figure 106: Starting the configuration wizard

Ê Navigate to the reference node to be used for your configuration and select
  the Configure Application Monitoring radio button (figure 107).




Figure 107: Starting PCS on a reference node

Ê Click Next to continue.
PCS opens in a separate window.




U42147-J-Z100-4-76                                                       159
Configuration procedure                          Linux configuration example


11.2.1 Creating the configuration

Ê To create a new configuration, type the new name directly into the Configu-
  ration Name input box at the PCS initial window. For this example, we will
  name the configuration demo1 (figure 108).




Figure 108: Entering a new configuration name

I A single node image can contain multiple application monitoring config-
       urations.
Ê Click Next to continue.




160                                                         U42147-J-Z100-4-76
Linux configuration example                         Configuration procedure


11.2.2 Choosing the application template

The Configuration Start window allows you to choose the template for this appli-
cation (figure 109).




Figure 109: Configuration start window

For this example, we will use the default Generic template. There are no other
parameters to configure in this view.
Ê Click Next to continue.




U42147-J-Z100-4-76                                                          161
Configuration procedure                             Linux configuration example


11.2.3 Setting the application name

When you create an application with the Generic template, you begin at the top
of the configuration tree with an inconsistent application (figure 110).




Figure 110: Selecting application name

By default, PCS names the first application App0. You can enter a name of your
choice directly into the New Application Name input field. PCS will automatically
create a task group with a name of the form
   <Application Name>_<Configuration Name>
In this example, we will use the default name, App0. The task group will therefore
be named App0_Demo1.
Ê Click Next to advance to the next view.




162                                                            U42147-J-Z100-4-76
Linux configuration example                          Configuration procedure


11.2.4 Viewing template information

PCS displays some basic information about the application template
(figure 111).




Figure 111: Application template information

I When you open an existing configuration, PCS begins here.
There are no parameters to configure in this view.
Ê Click Next to continue.




U42147-J-Z100-4-76                                                      163
Configuration procedure                              Linux configuration example


11.2.5 Viewing application parameters

After viewing the template information, you will advance to the application
parameter settings view (figure 112).




Figure 112: Application parameters

There are no parameters to configure in this view.
Ê Click Next to continue.




164                                                            U42147-J-Z100-4-76
Linux configuration example                        Configuration procedure


11.2.6 Configuring the Command Line

Ê At the Command Line subapplication, check the Configure this subapplication
  box and click Next to open the initial view (figure 113).




Figure 113: Command Line initial view

Ê Enter the following commands:
   – Start command: ‘touch /tmp/HelloWorld’ (creates a file)
   – Stop command: ‘rm -f /tmp/HelloWorld’ (removes the file)
   – Detector command: ‘ls /tmp/HelloWorld’ (determines if the file
     exists)
I The OS-independent example shown here is for demonstration purposes
       only, so it uses the touch, rm and ls system commands with relative
       path names. Its operation is explained in “Command Line processing
       notes” on page 109.




U42147-J-Z100-4-76                                                        165
Configuration procedure                          Linux configuration example


figure 114 shows the completed command set.




Figure 114: Command Line parameters

Ê After you enter the commands, click Next to continue.




166                                                        U42147-J-Z100-4-76
Linux configuration example                           Configuration procedure


11.2.7 Configuring a local file system

Ê At the Local File System subapplication, check the Configure this subapplication
  box and click Next to open the initial view (figure 115).




Figure 115: Local File System initial view

Ê In the Local mount point drop-down list, choose the mount point. In this
  example, the mount point is /mnt1.
I The names in the drop-down list are collected from the #RMS# entries in
        the local /etc/fstab.pcl file.
Ê Click Next.




U42147-J-Z100-4-76                                                            167
Configuration procedure                          Linux configuration example


The view changes and the subapplication is marked as consistent (figure 116).




Figure 116: Local File System parameters

Ê Click Next to continue.




168                                                        U42147-J-Z100-4-76
Linux configuration example                          Configuration procedure


11.2.8 Configuring a remote file system

Ê At the Remote File System subapplication, check the Configure this subappli-
  cation box and click Next to open the initial view (figure 117).




Figure 117: Remote File System initial view

Ê At the NFS mount point field, choose the name of a mount point from the drop-
  down list. In this example, we will use the /opt/SUNWspro mount point.
I The names in the list are collected from the #RMS# entries in the local
       /etc/fstab.pcl file.
Ê After you select the remote file system, click Next.




U42147-J-Z100-4-76                                                          169
Configuration procedure                            Linux configuration example


The view changes and the subapplication is marked as consistent (figure 118).




Figure 118: Remote File System parameters

There are no additional parameters to configure in this view.
Ê Click Next to continue.




170                                                             U42147-J-Z100-4-76
Linux configuration example                          Configuration procedure


11.2.9 Configuring the Ip Address

Ê At the Ip Address subapplication, check the Configure this subapplication box
  and click Next to open the initial view (figure 119).




Figure 119: Ip Address initial view

Ê Select the name that corresponds to the interface.
    In this example, we will configure demovip.
I The names in the drop-down list are collected from the entries in the local
        /opt/SMAW/SMAWRrms/etc/hvipalias.satellite file.
Ê Click Next.




U42147-J-Z100-4-76                                                          171
Configuration procedure                                 Linux configuration example


You will advance to the interface parameters view (figure 120).




Figure 120: Ip Address parameters

Ê Set Ping to Yes to enable the ping host list (figure 121).




Figure 121: Ip Address ping host list

Note that the title of the Ping field is now in italics to indicate it has been changed
from the default setting.
Ê Highlight the desired name in the ping host list and click Next to continue.
    In this example, we will use london as a ping host.



172                                                                U42147-J-Z100-4-76
Linux configuration example                          Configuration procedure


11.2.10 Saving and activating

At this point, we have configured all the resources, and we’re ready to save and
activate the configuration.
Ê Use File –> Save to save the configuration (figure 122).




Figure 122: Saving the configuration

PCS displays a message after a successful save (figure 123).




Figure 123: Message after successful save




U42147-J-Z100-4-76                                                          173
Configuration procedure                            Linux configuration example


Ê Use Tools –> Activate to activate the configuration (figure 124).




Figure 124: Activating the configuration

PCS displays a message after a successful activation (figure 125).




Figure 125: Message after successful activation

The configuration is now ready to run.




174                                                           U42147-J-Z100-4-76
Linux configuration example                                   Testing the configuration


11.3        Testing the configuration
Before you take the image of the node for future deployment, you can test the
application monitoring configuration. To do this, you will return to the GUI and
perform a few simple operations from the graph of the configuration.
Ê From the ASCC GUI menu, select View –> Satellite Graphs (figure 126).




Figure 126: Opening the graph on the satellite node, step 1

Ê From the popup dialog, select the node with your PCS configuration. In this
  example, we used bxsat1 (figure 126).




Figure 127: Opening the graph on the satellite node, step 2

Ê When you are prompted to start application monitoring (RMS) on the node,
  click Yes (figure 128).




U42147-J-Z100-4-76                                                                 175
Testing the configuration                                    Linux configuration example




Figure 128: Starting application monitoring on the satellite node

The graph will open with the node in an online state (green bar) and the other
objects in an offline state (blue bar) (figure 129).




Figure 129: Initial satellite graph

Ê Right-click on the name of the configuration (App0_Demo) and select Online
  from the context menu (figure 130).




176                                                                    U42147-J-Z100-4-76
Linux configuration example                                   Testing the configuration




Figure 130: Starting application monitoring test from graph




U42147-J-Z100-4-76                                                                 177
Testing the configuration                                 Linux configuration example


Ê When you are prompted to bring the application online, click Yes (figure 131).




Figure 131: Prompt to bring application online

Starting from the application object at the top of the graph, the objects will be
put into the wait state (yellow bar). Then, starting from the lowest level child,
each object will be brought online (green bar). figure 132 shows the graph
appearance partway through the process.




Figure 132: Intermediate graph during online processing




178                                                                 U42147-J-Z100-4-76
Linux configuration example                            Testing the configuration


Green bars on all objects indicate that online processing has completed
successfully (figure 133).




Figure 133: Graph after successful online processing

At this point, you can login on the reference node to verify you can do the
following:
●   Ping demohost and its IP address
●   View the contents of the local file system (mounted on /mnt/data1 in this
    example)
●   View the contents of the remote file system (mounted on /opt/SUNWspro in
    this example)
You should be able to do the following on a remote host in the same subnet:
●   Ping demohost and its IP address
●   Mount and view the file system from the reference node (available as
    demohost:/mnt/data1 in this example)




U42147-J-Z100-4-76                                                            179
Testing the configuration                                     Linux configuration example


If the test are successful, you can bring the application to the offline state.
Ê Right-click on the name of the configuration (App0_Demo) and select Offline
  from the context menu (figure 134).




Figure 134: Stopping application monitoring test from graph

The graph will return to the initial state (figure 129 above).




180                                                                     U42147-J-Z100-4-76
Linux configuration example                          Testing the configuration


11.3.1 Viewing object properties

At any time, you can view the properties of any object by clicking on it
(figure 135).




Figure 135: Viewing object information

The selected object is highlighted with an orange outline, and the bottom pane
of the graph window displays the selected item’s properties. If you click another
object, its properties will replace those in the bottom pane.
The properties pane remains open until you close it.




U42147-J-Z100-4-76                                                           181
Viewing node and application logs                   Linux configuration example


11.4       Viewing node and application logs
To view the RMS switchlog for the node, right-click on the node object and select
View switchlog from the context menu (figure 136).




Figure 136: Viewing node switchlog from graph

To view the application log, right-click on the application object and select View
logfile from the context menu (figure 137).




182                                                            U42147-J-Z100-4-76
Linux configuration example                      Viewing node and application logs




Figure 137: Viewing application log from graph

The log file appears in a separate window (figure 138).




U42147-J-Z100-4-76                                                            183
Viewing node and application logs                       Linux configuration example




Figure 138: Log file viewer window



11.4.1 Common procedures for switchlog and application
       log

By default, the entire log is available in the scrolled area at the bottom of the
window. You can restrict the entries displayed with the following filters, which are
described in subsections below:
●   Time Filter—defines the time period of interest.
●   Keyword Filter—selects a particular resource name (for an application only),
    error message severity level, non-zero exit code, or keyword.
    I Refer to the RMS Reference Guide for a complete description of severity
           levels and exit codes.
Ê After you enter your filter criteria, click the Filter button to display the filtered
  log entries.
I All the selected and non-blank Time Filter and Keyword Filter controls are
       combined with a logical AND operation.




184                                                                U42147-J-Z100-4-76
Linux configuration example                   Viewing node and application logs


At any time, you can sort the displayed switchlog entries according to increasing
or decreasing time by checking or unchecking the Reverse Order checkbox in the
log viewer window.


11.4.2 Time filter

The controls in the Time Filter panel allow you to limit the entries displayed in the
log pane according to their date and time (figure 139).




Figure 139: Search based on date and time range

Check the Enable checkbox and then select the Start Time and End Time using
the scrolling input boxes (you can also type in the values directly). The controls
take effect the next time you click the Filter button.
I To remove the time filter, uncheck Enable and click Filter.




U42147-J-Z100-4-76                                                               185
Viewing node and application logs                   Linux configuration example


11.4.3 Keyword filters

The following items are available in the Keyword Filter panel.

11.4.3.1 Resource Name

Select a resource name from the dropdown list (figure 140).
I The Resource Name control is available only for application logs.




Figure 140: Search based on resource name




186                                                              U42147-J-Z100-4-76
Linux configuration example                    Viewing node and application logs


11.4.3.2 Severity

Select an message severity level from the dropdown list (figure 141).




Figure 141: Search based on severity level

table 5 summarizes the RMS message severity levels.

Severity level              Description
Emergency                   Systems cannot be used
Alert                       Immediate action is necessary
Critical                    Critical condition (fatal error)
Error                       Error condition (non-fatal error)
Warning                     Warning condition
Notice                      Normal but important condition
Info                        Miscellaneous information
Debug                       Debug messages
Table 5: RMS severity level description




U42147-J-Z100-4-76                                                          187
Viewing node and application logs                    Linux configuration example


11.4.3.3 Non-zero exit code

Enter a numeric exit code in the Non-zero exit code input box and then click Filter.

11.4.3.4 Keyword

Enter a string in the Keyword box (figure 142). Special characters and spaces
are valid, but wildcards are not interpreted. This search is not case-sensitive.




Figure 142: Search based on keyword




188                                                              U42147-J-Z100-4-76
Linux configuration example                     Viewing node and application logs


11.4.4 Text search

You can search the text in the application log by right-clicking on the displayed
text. A pop-up dialog with a Find entry allows you to perform a case-sensitive
search in the direction you specify (figure 143).




Figure 143: Using the pop-up Find dialog in log viewer

I The Find search string is processed literally You can include spaces and
       special characters, but wildcards are not interpreted.


11.4.5 Removing filters

To remove all filters, take the following steps:
●   Uncheck the time filter Enable box.
●   Set drop-down lists to No Selection
●   Clear text from input boxes
●   Click the Filter button
The unfiltered view will be restored.


U42147-J-Z100-4-76                                                           189
Taking the image                                Linux configuration example


11.5       Taking the image
I You can create multiple configurations on one node before you take the
       node image.
When you have confirmed the configuration operates as expected, you can take
an image for future deployment using either of the following methods:
Ê From the ASCC wizard view of the reference node, select Take Image and
  then click Next (figure 144).




Figure 144: Taking an image from the wizard

Ê From the ASCC GUI, right-click on the reference node and select Take Image
  and then click Next (figure 144).




190                                                        U42147-J-Z100-4-76
Linux configuration example                                  Taking the image




Figure 145: Taking an image from the wizard

In either case, you will need to supply a unique image name. For further details
about image and application pool management, see the Adaptive Services
Control Center (ASCC) User Guide.




U42147-J-Z100-4-76                                                          191
Part III: Windows Configurations




U42147-J-Z100-4-76
12        Configuring Windows
          applications
This chapter describes how to configure applications for the Windows Appli-
cation Control Interface (WACI). The PCS procedure is generally the same for
WACI configuration and Linux RMS configuration. For instance, you can
manage Windows configurations and applications using the standard proce-
dures described in the chapter “PCS graphical user interface” on page 51.
However, there are some very important differences at the subapplication level.
In a single WACI configuration, you can specify a set of Windows services, a set
of start/stop/monitor scripts, or both. However, WACI does not have the ability
to manage the resources used by an application (e.g., disks, file systems, IP
addresses, volume managers) and the dependencies between those
resources. Therefore, when you run PCS on a Windows reference node, only
the WindowsServices and WindowsSSM subapplications are available. Likewise,
there is no capability to generate a graph of resources like the one available in
RMS.
Chapter contents:
●   “Creating a configuration” on page 196
●   “Configuring services and scripts” on page 201
●   “Saving and activating the configuration” on page 212
●   “Using instance IDs” on page 214
●   “Image-independent applications” on page 216




U42147-J-Z100-4-76                                                           195
Creating a configuration                          Configuring Windows applications


12.1       Creating a configuration
Ê From the ASCC GUI, open the ASCC wizard with Tools –> Configuration
  Wizard (figure 146).




                               asp1101
Figure 146: Starting the ASCC wizard

Ê Navigate to the reference node in the left pane (figure 147).




Figure 147: Navigating to the Windows reference node

Ê Click the Configure Application Monitoring radio button.
When you click the radio button, the view changes to prompt you for the WACI
password you created when ASCCAgent was installed (figure 148).




196                                                              U42147-J-Z100-4-76
Configuring Windows applications                   Creating a configuration




Figure 148: Prompt for Windows ACI password

Ê Enter the password and then click Next to continue.
I PCS remembers the WACI password for this node for the remainder of
       the current wizard session.
The PCS session on the selected node will open in a separate window.
I You can switch between the ASCC GUI, the ASCC wizard, and any PCS
       session without closing any of the windows. You can also open multiple
       PCS sessions as long as each one is on a different reference node.




U42147-J-Z100-4-76                                                       197
Creating a configuration                        Configuring Windows applications


12.1.1 Creating or editing a configuration

The first PCS view requires you to create or select a configuration name. A
single Windows image can contain multiple WACI configurations.
Ê To edit an existing configuration, select it from the dropdown list.
Ê To create a new configuration, type the new name directly into the Configu-
  ration Name input box at the PCS initial window (figure 149).




Figure 149: Entering a new configuration name

In this example, we will create the IIScfg configuration to control the Windows
IIS services.
Ê Click Next to continue.




198                                                            U42147-J-Z100-4-76
Configuring Windows applications                     Creating a configuration


12.1.2 Choosing an application template

The Configuration Start view allows you to choose an application template
(figure 150)




Figure 150: Selecting an application template

PCS provides the WindowsServices template as part of its standard installation.
Other templates will appear in the dropdown list if you have installed one or
more optional PCS Wizards for Adaptive Services Control Center.
Ê Choose the desired template from the dropdown list.
When you click on the template name, PCS automatically advances to the next
view.




U42147-J-Z100-4-76                                                          199
Creating a configuration                          Configuring Windows applications


12.1.3 Naming the application

The next view allows you to change the name of the application. Note that the
configuration tree has expanded in the left pane. The application is marked as
inconsistent with a red status icon, and it will remain that way until you configure
a service or set of scripts in a later step (figure 151).




Figure 151: Naming the Windows ASCC application

I ASCC allows only one application to be added per configuration.
       However, a single application can control multiple Windows services, and
       the Start/Stop/Monitor command set can specify batch files that invoke
       complex operations.
By default, PCS names the application App0. If you create a task group to
manage this configuration, ASCC will automatically assign this application
name to the task group. Therefore, you should choose a more descriptive name.
In this example, we will use the application name Win_IIScfg.
Ê Type the name Win_IIScfg into the New Application Name input box.
Ê Click Next to advance to the next view.




200                                                              U42147-J-Z100-4-76
Configuring Windows applications            Configuring services and scripts


12.2       Configuring services and scripts
In the next view, PCS displays an introduction that briefly explains WACI’s
capabilities (figure 152).




Figure 152: WACI introduction view

Ê Click Next to advance to the next view.




U42147-J-Z100-4-76                                                            201
Configuring services and scripts                 Configuring Windows applications


As described in the previous view, a WACI application can include services,
scripts, or both. In this view, you will indicate which of these you want to add to
your configuration (figure 153).




Figure 153: Choosing WACI services and scripts

The red text in the right pane indicates one or more items that you must
complete before you can advance to the next view.
Ê Make your selections from the dropdown lists. You must select Yes in at least
  one of the lists.
The updated view will display the titles of the dropdown lists in black text to
indicate you have satisfied the minimum requirements for this step
Ê Click Next to advance to the next view.




202                                                             U42147-J-Z100-4-76
Configuring Windows applications               Configuring services and scripts


12.2.1 Configuring Windows services

If you choose to configure Windows services, PCS creates a WindowsServices
subapplication in the left pane and marks it as inconsistent. The WindowsServices
view in the right pane displays a scrolling list of all the services installed on the
reference node (figure 154).




Figure 154: Selecting Windows services

The Windows Services label in the right pane appears in red to indicate you need
to select at least one item from the list.
Ê To add a service name that does not appear in the list, type its name in the
  Select Windows Services input box and then click the Add button.
   I You must install the service on the reference node before the config-
           uration can run.
Ê To select a service, highlight its name in the scrolling list.
   To select multiple services, hold down the [Ctrl] key as you click on additional
   names.
In this example, IIS consists of three services, HTTPFilter, IISADMIN, and
W3SVC, so all should be selected.



U42147-J-Z100-4-76                                                               203
Configuring services and scripts                 Configuring Windows applications


Ê When you have selected all the desired services, click Next to continue.
After ASCC updates the view, the selected service appears highlighted at the
top of the scrolling list in the right pane, and the WindowsServices step in the left
pane is marked as consistent with a blue icon (figure 155).




Figure 155: Updated view showing selected Windows services

An additional information line may appear below the title line at the top of the
view (figure 156). (If the line is too long to fit on the screen, it is accompanied by
a horizontal scroll bar.)




Figure 156: Updated view with information line



204                                                                U42147-J-Z100-4-76
Configuring Windows applications              Configuring services and scripts


This indicates there are extra steps you must take before ASCC can start this
configuration.
If the line indicates the startup type of the selected service is not set properly,
you must make this adjustment before you save the image. We recommend that
you use the following procedure to make the adjustment before you proceed
with the configuration.
I WACI can control a service only if it is set to start manually when the
       system starts up.


12.2.2 Changing the startup type of a service

Ideally, you would complete this procedure before you create a WACI configu-
ration, but you can do this any time before you save the satellite’s image.
1. If you are in the middle of a PCS session, do not close the PCS window.
2. Open a remote desktop on the WACI satellite and login as Administrator. You
   can use Windows Remote Desktop Connection, VNC, or any other remote
   desktop service running on the satellite.
3. Open the Services applet. You can find this under Administrative Tools in the
   start menu or control panel. Alternatively, you can right-click on My Computer,
   select Manage, and find it under Services and Applications.
4. Find each service in the list and check its status. If its startup type is not
   Manual, double-click it to open its properties and set the Startup Type to
   Manual. Click OK to close the services properties window.
   Note that the service name in the WACI Windows Services view may not be
   what Windows displays in its Services list. For instance, the HTTPFilter
   service we selected for this example is displayed with the name HTTP SSL
   (figure 157).




U42147-J-Z100-4-76                                                              205
Configuring services and scripts                   Configuring Windows applications




Figure 157: Setting a Windows service to start manually

   Note that the Service name at the top of the General tab displays the internal
   name used by Windows and by WACI.
   Also note that you do not have to change the present service status. Only
   the Startup type is important here.
5. Click OK to close the service properties window.
6. Repeat step 2 for each service you will control with WACI.
7. When you are finished, close the Services applet and terminate the remote
   desktop session.
You can then return to the PCS window to continue your configuration where
you left off.
Ê From the WindowsServices view, click Next to continue.




206                                                               U42147-J-Z100-4-76
Configuring Windows applications                  Configuring services and scripts


12.2.3 Configuring Start/Stop/Monitor command scripts

If you choose to configure a set of scripts for this application, PCS creates a
WindowsSSM subapplication in the left pane and marks it as inconsistent. It also
creates an instance named WindowsSSM0 beneath it (figure 158).




Figure 158: Configuring Windows start/stop/monitor scripts

I WindowsSSM is shorthand for “Windows start/stop/monitor”.
You can create additional instances, each with its own set of scripts. The
procedure is described later in this section.
Use the scroll bar in the right pane or resize the window to see all the input fields
(figure 159).




U42147-J-Z100-4-76                                                               207
Configuring services and scripts                      Configuring Windows applications




Figure 159: Windows start/stop/monitor input fields

The right pane displays the following input fields:
Start command
    Executed when ASCC starts application monitoring on the node. Must return
    zero for success and non-zero otherwise.
Stop command
    Executed when ASCC stops application monitoring on the node. Must return
    zero for success and non-zero otherwise.
Monitor command
    Executed every 10 seconds to detect the application’s status. Must return
    zero for success and non-zero otherwise.
User name
    The user name to be used when executing the above commands. This user
    must have execute access for each command interpreter, read access for
    the scripts and base directories, and appropriate read, write, and execute
    access for any other files or directories processed by the script.
Password
    The password for the above user.




208                                                                  U42147-J-Z100-4-76
Configuring Windows applications               Configuring services and scripts


I If you have not configured a Windows service, you must configure all
       three scripts. However, if at least one Windows service is already
       configured, you can choose to configure only the script(s) you need.
Ê Click the checkbox for each script you want to configure.
Ê Enter a command interpreter, a script name, and, optionally, a base
  (starting) directory for each script you enable.
Input boxes with red titles are required parameters. When you complete a
required entry and move to another box, the red title will turn black.
Observe the following guidelines as you enter your data:
●   We strongly recommend that you enter the complete path for each inter-
    preter, script, and directory you specify. This approach is generally more
    reliable than relying on the PATH environment variable to locate the correct
    executable.
    Example: The standard windows command interpreter should be specified
    as c:\windows\system32\cmd.exe rather than simply cmd.exe.
●   If a path includes spaces, be sure to enclose it in quotation marks (").
●   Options for the command interpreter should be specified as part of the script
    and not at the end of the interpreter string.
    Example: If the start script is a batch file named c:\asccscripts\start.bat, the
    corresponding interpreter and script input would be as follows:
      Interpreter: c:\windows\system32\cmd.exe
      Start script: /c c:\asccscripts\start.bat
●   If you require pipes or redirection, hard-code the complete command line in
    a batch file and specify that file for the script.
●   Unlike a Windows service, monitoring or stopping an arbitrary Windows task
    from a command line is not straightforward. However, numerous freeware
    and commercial utilities are available for this purpose.
Ê When you have completed your entries, click Next to continue.
If all the required parameters are present, none of the items in the right pane of
the updated view will appear with a red title. In the right pane, the WindowsSSM
subapplication is marked as consistent with a blue status icon (figure 160).




U42147-J-Z100-4-76                                                                209
Configuring services and scripts                   Configuring Windows applications




Figure 160: Completed Start/Stop/Monitor command set

Ê Click Next to continue.

12.2.3.1 Creating WindowsSSM instances

To create additional WindowsSSM instances, use the following procedure:
Ê Select an existing instance in the left pane.
Ê From the Edit menu, select Add More Instances, or, equivalently, Create –
  > Instance (figure 161).




Figure 161: Creating another WindowsSSM instance




210                                                               U42147-J-Z100-4-76
Configuring Windows applications             Configuring services and scripts


The new instance is marked as inconsistent until you configure one or more of
the scripts as described previously (figure 162).




Figure 162: New WindowsSSM instance


12.2.3.2 Deleting WindowsSSM instances

To delete a WindowsSSM instance, use the following procedure:
Ê Select the instance in the left pane.
Ê From the Edit menu, select Delete Instance, or, equivalently, Delete –> Instance
  (figure 163).




Figure 163: Deleting a WindowsSSM instance

You will advance to a view that asks you to confirm your action. Click Next at that
view to delete the instance.

12.2.3.3 Execution order for multiple scripts

When WACI starts up, it executes the Start scripts in the order you define them
here. Each script must exit successfully before the next script is started.
Note that there is no method to reorder the instances once they are defined.



U42147-J-Z100-4-76                                                             211
Saving and activating the configuration Configuring Windows applications


12.2.4 Combining Windows services and scripts

If you choose to include both Windows services and scripts in your configu-
ration, PCS will initially create empty, inconsistent subapplications for both
(figure 164).




Figure 164: Configuring both Windows services and scripts

When you click Next after configuring the WindowsServices subapplication, you
will advance to the WindowsSSM subapplication. You can configure each of these
subapplications independently—they do not affect each other in PCS.

Execution order
At startup, WACI executes all the WindowsSSM scripts before it begins starting
the services. This allows you to set up system resources that may be required
by the services.


12.3       Saving and activating the configuration
Before you can use a configuration, you must save and activate it.




212                                                           U42147-J-Z100-4-76
Configuring Windows applications Saving and activating the configuration


12.3.1 Saving the configuration

Ê To save the configuration, select File –> Save from the PCS menu.
You can do this at any time while the configuration is open for editing. The
configuration does not have to be consistent to save it.


12.3.2 Activating the configuration

I The configuration must be consistent before you can activate it.
To prepare the configuration for automatic ASCC control, you must activate the
configuration. This operation combines template information with user input to
generate the complete configuration in an internal format. The internal form of
the configuration is then copied to a standard location, where it can be loaded
by ASCC at runtime.
Ê To activate the configuration, select Tools –> Activate (figure 165).




Figure 165: Activating the configuration

PCS displays a message after a successful activation (figure 166).




Figure 166: Message after successful activation

The configuration is now ready to run.




U42147-J-Z100-4-76                                                             213
Using instance IDs                                Configuring Windows applications


12.3.3 Generating the configuration

You can generate the internal form of the configuration without making it
available to ASCC. This is intended for internal use by PCS experts.
Ê To activate the configuration, select Tools –> Generate (figure 167).




Figure 167: Generating the configuration

PCS displays a message after a successful generation (figure 168).




Figure 168: Message after successful generation



12.4       Using instance IDs
One of the major uses of WACI is to support SAP on Windows. In a SAP group
of application servers, each SAP server in the data center must have its own
unique instance ID. When a consultant sets up a SAP group, one of the tasks
is to create these instance IDs. However, when ASCC manages a SAP task
group, it uses only a single image. Therefore, ASCC must provide a way for the
image itself to determine its unique SAP ID when it goes online on a particular
node.




214                                                              U42147-J-Z100-4-76
Configuring Windows applications                              Using instance IDs


The approach is straightforward: ASCC assigns a unique instance number to
each node that is currently running in a task group. This number ranges from 1
to the maximum node count for that group, inclusive. If a node in a group
crashes, ASCC can reassign that node’s instance number to another node in
the group when it boots up.
In general, the ASCC instance number may not be compatible with the data
center’s SAP instance ID, so there must be a way to map one to the other. PCS
allows the user to define a script to accomplish this. The script must be executed
before WACI bring the application’s services online or executes the configured
start scripts.
This approach will work for any application that requires a unique ID for each
node in its task group. The script is entirely user-defined, so it may be written in
any Windows scripting language (batch file, Windows Script Host, perl, etc.)
installed on the node. The same mechanism is available for Linux nodes (see
“Generating virtual host names” on page 137).


12.4.1 sat_getinstanceid.exe command usage

ASCC provides the sat_getinstanceid.exe command, which prints the local
node’s current instance ID. Execute the command as follows (the line has been
wrapped to fit on this page):
“C:\Program Files\Fujitsu Siemens Computers\ASCC Agent\
    sat_getinstanceid.exe” <groupname>
The only argument, <groupname>, is the name of the local node’s task group.
Note that the executable name must be enclosed in quotes because it contains
embedded blanks.
You can redirect the output of this command into a file, and then use the
Windows ‘for /f’ command to extract it for other purposes. For example, the
following sequence of commands creates an environment variable that contains
the instance ID for the App0_test task group (indentations indicate wrapped
lines):

“C:\Program Files\Fujitsu Siemens Computers\ASCC Agent\
    sat_getinstanceid.exe” App0_test >C:\Windows\temp\_id.txt
for /f "tokens=1 delims= " %%a in (C:\Windows\temp\_id.txt) do
    set TEST_ID=%%a
echo ID=%TEST_ID%




U42147-J-Z100-4-76                                                              215
Image-independent applications                 Configuring Windows applications


12.5       Image-independent applications
For some configurations, it is desirable for the applications to reside on a shared
filer rather than being embedded in the deployable images. Nodes in a task
group can then mount the applications from SMB servers or some other suitable
file sharing mechanism. This allows new applications to be added to the filer
without having to change the deployable image. In addition, multiple images
could use the same filer. This is very convenient when you need different
images to accommodate minor variations in hardware, but all the images can
run identical application binaries.
Some special setup work is required to implement this.


12.5.1 Storing PCS configurations on the filer

On Windows systems, the WACI Application Definition Directory must also reside
on a filer and be mounted automatically at system startup. As discussed in the
ASCC Adaptive Services Control Center (Linux, Windows) User Guide, this directory
is defined during the WACI agent installation procedure on the reference node
(figure 169).




Figure 169: ASCC agent settings

The default location is C:\Program Files\Fujitsu Siemens
Computers\ASCC Agent\Applications. If this directory is changed to a
location on the filer, the Windows ACI configuration files become available to
any application on the reference node, and consequently any satellite that uses
the reference node image.



216                                                             U42147-J-Z100-4-76
Configuring Windows applications                 Image-independent applications


For Linux nodes, you should set the PCS Configuration Path to a location on the
filer. This is done by selecting Options –> Set Configuration Path in the PCS initial
view (figure 170).




Figure 170: Setting the PCS Configuration Path



12.5.2 Storing applications on the filer

The applications must reside on a shared filer that is initially mounted on a
reference node for the task group. The reference node must be configured to
mount the filer’s data at startup, and this is done by including the necessary
commands in the Windows start script for the application. At a minimum, the
start script must do the following:
Create the mount point(s) for the application file system.
Mount the application file systems on the appropriate mount points. NET USE
<drive> <share>


12.5.3 Changing available applications on the filer

When the reference node image is taken, the image’s application list will contain
all the applications that are currently present on the filer and configured in
Windows ACI or PCS. However, if one of the filer’s applications is subsequently
deleted, the image's application list will continue to show the application. For
this reason, you may wish to take the reference node's image before you define
any applications in Windows ACI or PCS. No applications will show up in that
image's list, but the ASCC Wizard has a method that allows you to add new
applications later.
When you create a new application monitoring task group, one of the first steps
is to select the task definition (figure 171).




U42147-J-Z100-4-76                                                               217
Image-independent applications                      Configuring Windows applications




Figure 171: Selecting an application for a new task group

Ê Click the Look up new applications radio button and then click Next.
You will advance to a view that lists all the hosts available to ASCC.
Ê Highlight one or more hosts in the list and then click Search (figure 172).




218                                                                U42147-J-Z100-4-76
Configuring Windows applications                    Image-independent applications




Figure 172: Selecting a node to search for new task definitions

You should specify a host that has mounted the filer with the shared applica-
tions. The host must be up and running now and in the future, so the path to the
filer is available whenever a satellite in this task group attempts to run the
shared application. The host could be a highly-available virtual connection on
one of the satellite nodes.
When the search is complete, the ASCC Wizard lists all the new task definitions
it finds in a dropdown list that appears in the same view (figure 173).




U42147-J-Z100-4-76                                                            219
Image-independent applications                       Configuring Windows applications




Figure 173: Selecting a new task definition from the target node

Ê Select the task definition from the dropdown list and then click Next.
The selected task definition is now associated with the new task group, even
though it was not present when the reference node's image was taken.


12.5.4 Selecting the correct image for the task group

Later in the task group configuration procedure, you will specify an image.
However, the Wizard will let you specify any image for the task group—it does
not determine whether the image you select has access to the filer where the
application binaries are stored. This means that you must exercise extra caution
when you select the image. If the image does not mount the filer that contains
the application, then the group will fail during start-up.
Note that, for the traditional case where the applications are part of the image,
the ASCC Wizard checks that the application is contained in any image that is
offered as a candidate for the task group. However, with image-independent
applications, this check is bypassed.




220                                                                 U42147-J-Z100-4-76
Part IV: Reference




U42147-J-Z100-4-76
   13        Appendix—Site preparation
   The ASCC Adaptive Services Control Center (Linux, Windows) User Guide describes
   how to prepare your cluster to operate ASCC. Some of the procedures require
   you to modify system files so that ASCC can identify the hosts, file systems,
   and network interfaces used in a configuration. You should have completed
   these procedures when ASCC was installed.
   In some cases, you will be creating or modifying your ASCC configuration
   because changes have been made to your site. Certain site changes may
   require you to review and update your system files first. These changes include,
   but are not limited to, the following:
   ●   IP addresses were changed.
   ●   Hosts were added, removed, or renamed.
   ●   Two or more clusters were merged into one.
   ●   File systems or SANs were added or removed.
   For convenience, the site preparation descriptions for hosts, file systems, and
   networks are duplicated here. If any of these specifications have changed since
   your initial ASCC installation, you should review this material and make the
   necessary adjustments before proceeding with your ASCC configuration.
   The modifications generally involve adding ASCC-specific entries to standard
   system files; pre-existing entries required for proper operation of your hosts and
   network are not affected. Resources for market-specific applications may
   require similar customization.


   13.1      Network database files

   13.1.1 /etc/hosts

   The /etc/hosts file must contain the IP addresses and RMS names of all the
   host systems that are part of the cluster.
   RMS uses its own internal set of host names to manage the machines in the
   cluster. When you configure the cluster, you will use the RMS host names and
   not the standard host names. These names must be entered in /etc/hosts on
   each system in the cluster to avoid problems should access to the DNS fail.


U42147-J-Z100-4-76                                                           223
Network database files                             Appendix—Site preparation


By default, the names follow the conventions in table 6.

Entry type                  RMS naming pattern         Examples
RMS host name               <hostname>RMS              bxsat1RMS
                                                       bxsat2RMS
Table 6: RMS host name conventions in /etc/hosts


I The RMS host name for a machine must match the contents of the
       RELIANT_HOSTNAME variable in that machine’s hvenv.local configu-
       ration file, if that file exists.
RMS does not support IPV6 addresses.

Example
   The following entries in /etc/hosts are for a cluster with nodes bxsat1
   and bxsat2. The interface names are assigned as follows:
   – Standard host names on the public network 172.25.220
   – RMS node names on the private network 192.168.10
   172.25.220.83   bxsat1
   172.25.220.84   bxsat2
   # node names for RMS
   192.168.10.83   bxsat1RMS
   192.168.10.84   bxsat2RMS

13.1.1.1 Network interface names in /etc/hosts

If you plan to configure one or more network interfaces for switchover with the
Ip Address subapplication, you must first enter the interface name(s) in the
/etc/hosts file on every node where that interface can exist. Each entry
consists of the interface IP address and its name in the normal format; no
special comments are required.

Example
   If the interface bxcorevip with IP address 172.25.222.223 can be
   switched between nodes bxsat1 and bxsat2, then both nodes should
   contain the following line in /etc/hosts:
   172.25.222.223           bxcorevip




224                                                          U42147-J-Z100-4-76
Appendix—Site preparation                              Network database files


I When you configure the Ip Address subapplication, you specify the
       interface name as it appears in /etc/hosts, and not the IP address.

13.1.1.2 Virtual host names in /etc/hosts

The Virtual Host Name subapplication creates a list of possible virtual host
names from the satellite’s /etc/hosts file. If you select one of these host
names, you can also configure its IP address in the subapplication.
Note that this is not necessary for host names that will be generated by the
sat_getinstanceid command, since these have no associated IP address.


13.1.2 /root/.rhosts

Contains entries to control trusted login from remote hosts.
PCS requires automatic login or authentication as root on every machine in the
cluster. One method is to include the names of trusted hosts in the .rhosts file,
which must be modified appropriately on each node. See the rhosts manual
page for a complete description of the format.

Example
   If the cluster consists of hosts bxsat1 and bxsat2, then every machine’s
   .rhosts file should contain the following lines:
   bxsat1 root
   bxsat2 root
I asconf calls the sshconf utility to set up non-interactive, one-way ssh
       access from the core nodes to any satellite node during installation. You
       can use sshconf directly to set up two-way access within a specified
       group of nodes. For more information, see the ASCC Adaptive Services
       Control Center (Linux, Windows) User Guide.

Netboot satellite nodes
Netboot satellite nodes are controlled by rsh commands from the control
nodes. The satellite’s /root/.rhosts file must allow automatic login from the
control nodes as root. For more information, see the ASCC Adaptive Services
Control Center Site Preparation Guide.




U42147-J-Z100-4-76                                                             225
Configuration resource definitions                   Appendix—Site preparation


13.2      Configuration resource definitions

13.2.1 /opt/SMAW/SMAWRrms/etc/hvipalias.satellite

This file contains entries for all of the network interfaces that are to be used as
resources in the configuration. Typically, each entry associates a logical
interface name, or IP alias, with a physical interface on a specified node. The
IP alias always presents the same IP address, even though it is switched from
node to node, and even if the underlying physical interface has different charac-
teristics on each node.
I Each IP alias with its IP address must be entered in the /etc/hosts file.
  The IP address does not appear in the hvipalias.satellite file.
I You must modify the hosts and hvipalias.satellite files on the
       satellite node, not on the control nodes.
Each entry in hvipalias.satellite must contain the following fields:
    <Uname> <IfName> <IfDevice> <Netmask>
The fields are defined as follows:
●   Uname—Name of the machine to host the logical interface. For ASCC, this
    must be SATELLITE_NODE, the placeholder name.
●   IfName—Logical interface name, or IP alias. This name must appear with its
    associated IP address in the node’s /etc/hosts file.
●   IfDevice—Physical device name to be associated with the logical interface
    when it is switched to the specified machine. In an ASCC cluster, this should
    be the device used for the public LAN.
    If you specify two comma-separated device names, and the first device fails,
    the logical interface will failover to the second device.
●   Netmask—The netmask to use with the IP address associated with the
    interface name, specified in the standard hexadecimal 8-digit format. The
    netmask is set with an ifconfig command after the physical device is
    brought online.
I To avoid network conflicts, a network hostname or address monitored by
       the Ip Address subapplication can be active on only one node in the
       cluster at any time. Therefore, an active application pool that contains a
       configured Ip Address must have a maximum instance count of 1.



226                                                             U42147-J-Z100-4-76
Appendix—Site preparation                   Configuration resource definitions


An ASCC satellite node’s hvipalias.satellite file can contain multiple
entries, subject to the following restrictions:
●   The Uname field of every entry must contain the placeholder name,
    SATELLITE_NODE.
●   Each interface name can appear in only one entry. An interface name can
    be used only in one application pool configuration.
●   The device name must be the same for every entry, and it must correspond
    to the interface used by the public LAN.
After cloning, the hvipalias.satellite file is copied to hvipalias in the
same directory, and the SATELLITE_NODE placeholder name is replaced by the
actual node name.

Example
    If the interface named dbhost must follow an application pool on the current
    host, and the public LAN is connected to eth0, then
    hvipalias.satellite should contain the following lines:
    #Uname               IfName     IfDevice      Netmask
    SATELLITE_NODE       dbhost     eth0          0xffffff00

13.2.1.1 Optional fields

The following fields are optional. If specified, they must appear after the required
fields in the order presented here.

ifconfig parameters
You can specify a set of arguments to be sent to the ifconfig command. This
allows you to specify custom interface settings that may be required for a
physical device before the interface is switched there.
The field begins with the IFCONFIG keyword (all uppercase), followed by
whitespace, followed by the comma-delimited argument string that will be
passed to the ifconfig command. The keyword and arguments must appear
after the Netmask field and before any Route arguments.
For example, if an mtu value of 1200 is required for the local device associated
with the dbhost alias, the entry for the local node would be as follows:




U42147-J-Z100-4-76                                                              227
Configuration resource definitions                 Appendix—Site preparation


Example
   #uname         IfName IfDevice         Netmask
   SATELLITE_NODE dbhost eth0             0xffffff00     IFCONFIG mtu,1200
After an interface is successfully brought online, the ifconfig command with
the specified netmask and additional arguments will be invoked for the
associated device.
I The private LAN interface on a BX300 or BX600 blade is not useful for
      interface device failover, since it communicates only with the deployment
      network.
V Caution
      Use care when specifying ifconfig settings for the blade network
      interface. The public LAN interface is used for ASCC and ServerView
      management functions, and improper settings can put the node in the
      Crash state.

Route parameters
Remaining fields at the end of the line are passed to a route command for the
configured interface. If the string $INTF is encountered, it is replaced by the
interface name; otherwise, the fields are passed literally.
I Do not include the add or delete subcommands in the argument list.
      RMS generates these automatically when the interface is brought online
      or offline.

Example
   SATELLITE_NODE dbhost eth1,eth2 0xffffff00            default dev $INTF
When the dbhost interface is brought online, RMS will issue the following
command:
   route add default dev dbhost


13.2.2 /opt/SMAW/SMAWRrms/etc/hvconsoles

Controls customized handling of fault messages, usually to remote consoles or
special devices such as pagers. This does not affect the standard messages
written to the ASCC or system log files.




228                                                          U42147-J-Z100-4-76
Appendix—Site preparation                                      Linux file systems


Each entry specifies a program to be executed when an ASCC resource object
encounters a fault.
If the file does not exist, you will receive no customized fault information. A
complete description of the format is available in the comments in the
hvconsoles.template file.


13.3       Linux file systems
To manage Linux file systems with RMS, you must create entries in the
/etc/fstab.pcl and /etc/exports.pcl configuration files as described in
the following sections. These configuration files share the following features:
●   Leading whitespace and empty lines are ignored.
●   A line beginning with the string ‘#RMS#’ is a file system specification for RMS.
    The entire specification must be on the same line—continuation to additional
    lines is not allowed.
●   Any other line beginning with a pound sign (#), or any line beginning with an
    asterisk (*), is treated as a comment.
●   All other lines are presently ignored. However, they may be processed by
    future versions of RMS.


13.3.1 /etc/fstab.pcl

This file contains entries for all of the local and remote file systems that are to
be used as resources in the configuration. RMS is responsible for mounting and
unmounting each of these file systems in order to bring them online or offline,
respectively, according to the requirements of the running configuration.
For each file system to be managed by ASCC, create a line in /etc/fstab.pcl
with the standard fstab fields, and then insert the string #RMS# at the beginning
of the line. For more information, see the fstab manual page.
Note the following restrictions when you create /etc/fstab.pcl:
●   Do not specify the same file system in both a standard /etc/fstab entry
    and an RMS /etc/fstab.pcl entry. The standard entry will mount the file
    system at system startup, and this will create a conflict when ASCC starts
    up and attempts to mount the same file system.




U42147-J-Z100-4-76                                                                229
Linux file systems                                  Appendix—Site preparation


●   If a remote file system is specified in the form <server_name>:<server_path>,
    then <server_name> must be a host name that appears in the /etc/hosts
    file. It cannot be an IP address, and you should not rely on DNS to resolve
    the name.

Examples
    #RMS#/dev/sdb2 /fs2    ext2    defaults 1 2
    #RMS#/dev/sda1 /mnt/data1 auto     noauto,user 0 0
    #RMS#/dev/sda2 /mnt/data2 auto     noauto,user 0 0
    #RMS#boat:/opt/SUNWspro /opt/SUNWspro nfs \
                defaults,nfsvers=2,rsize=8192,wsize=8192

13.3.1.1 Clusterwide configuration issues

In general, if you create an /etc/fstab.pcl control entry for a remote file
system or a shared filer in one image, then you should duplicate that entry in
every other image used by that task group. This helps to ensure that the config-
uration behaves consistently throughout the cluster.
Use a similar procedure for entries that specify local file systems and mount
points. If all nodes have the same architecture, you may be able to simply copy
the entire /etc/fstab.pcl control file. However, if the local physical disk
device differs from image to image, you must individually adjust the entries for
the same mount point. For example, the respective entries for /mnt1 in image1
and image2 might be as follows:
image1:
    #RMS#/dev/sda3       /mnt1    ...
image2:
    #RMS#/dev/sdb5       /mnt1    ...
In all cases, for each mount point that appears in /etc/fstab.pcl, be sure to
create the directory in every image for the task group.
I A shared NFS file system managed by RMS must have the same major
       device number and the same minor device number on every host that will
       mount that file system. This is necessary to ensure the file system is
       remounted transparently in the event of an application failover.




230                                                            U42147-J-Z100-4-76
Appendix—Site preparation                                    Linux file systems


13.3.2 /etc/exports.pcl

This file contains entries for all file systems that may be made highly available
for mounting on other hosts. RMS is responsible for sharing and unsharing each
of these file systems according to the requirements of the running configuration.
For each file system to be managed by ASCC, create a line in
/etc/exports.pcl with the standard exports fields, and then insert the
string #RMS# at the beginning of the line. For more information, see the exports
manual page.

Example
   #RMS#/mnt/data1        bxsat*(rw),172.25.222.0/24(rw)
I ASCC cannot export a subdirectory of a file system that is mounted
       from a remote server. It can only export the root of the remote file
       system.


13.3.3 Linux Volume Manager (LVM)

By default, when a Linux node is rebooted, its LVM volume groups will be
automatically activated. This should be suppressed for volume groups defined
in shared disks, which are usually configured as ClusterExclusive in the configu-
ration.
To disable automatic activation of shared volume groups, use the following
procedure:
Ê Comment out the following blocks of lines in the indicated file according to
  the Linux flavor. Note that each block may appear more than once, so be
  sure to check the entire file. To fit in the column below, long lines have been
  allowed to wrap, and indentation levels and leading spaces have been
  adjusted. The actual lines in the file will be unbroken and may appear with
  different indentation.
   – RedHat EL 3 — /etc/rc.d/rc.sysinit
       Block 1:
       #    If [ -e /proc/lvm -a -x /sbin/vgchange ]; then
       #        action $"Setting up Logical Volume Management:"
       /sbin/vgscan && /sbin/vgchange -a y
       #    fi



U42147-J-Z100-4-76                                                            231
Linux file systems                             Appendix—Site preparation


      Block 2:
      #    if [ -e /proc/lvm -a -x /sbin/vgchange -a -f
      /etc/lvmtab ]; then
      #        action $"Setting up Logical Volume
      Management:"/sbin/vgscan && /sbin/vgchange -a y
      #    fi
   – RedHat EL 4 — /etc/rc.d/rc.sysinit
      Block 1:
      #    if [ -x /sbin/lvm.static ]; then
      #        if /sbin/lvm.static vgscan > /dev/null 2>&1 ;
      then
      #            action $"Setting up Logical Volume
      Management:" /sbin/lvm.static vgscan --mknodes
      --ignorelockingfailure && /sbin/lvm.static vgchange -a y
      --ignorelockingfailure
      #        fi
      #    fi
      Block 2:
      #    if [ -x /sbin/lvm.static ]; then
      #        if /sbin/lvm.static vgscan --mknodes
      --ignorelockingfailure > /dev/null 2>&1 ; then
      #            action $"Setting up Logical Volume
      Management:" /sbin/lvm.static vgchange -a y
      --ignorelockingfailure
      #        fi
      #    fi
   – SuSE SLES8 and later — /etc/init.d/boot.lvm
      Block 1:
      #     echo "Activating LVM volume groups..."
      #     /sbin/vgchange -a y $LVM_VGS_ACTIVATED_ON_BOOT
Ê To configure new volume groups, use the commands pvcreate, vgcreate
  and lvcreate on one host only. Then, run vgscan on the other hosts.
Ê Finally, create the corresponding /etc/fstab.pcl entries with #RMS#
  tokens as described earlier. Example:
   #RMS#/dev/vg1/vol1    /mnt1   ext2   defaults,intr 0 0
   #RMS#/dev/vg1/vol2    /mnt2   ext2   defaults,intr 0 0




232                                                     U42147-J-Z100-4-76
Appendix—Site preparation                                           NFS servers


13.4      NFS servers
In a high availability environment such as ASCC, an exported file system must
be able to failover transparently when its server node is taken out of service:
clients that mounted the file system before the failover should experience no
access problems after the failover. NFS file systems require special preparation
to achieve this result.
When a client mounts a remote NFS file system, it creates an internal file
handle that it uses for future operations with the file system. To comply with
NFS architecture, the client file handle includes the server’s major and minor
device numbers for the file system. This design can create access problems in
the ASCC environment. If the file system goes offline on the original server, and
then comes back online on a second server that assigns different major and
minor device numbers, the file handle will no longer be valid. This condition is
called a stale file handle. The solution is to assign the same major and minor
device numbers to the file system on every NFS server that may advertise that
file system.
The above discussion refers to file systems in general, but in a high availability
environment, the file system will actually be a shared disk volume that is acces-
sible from any node that will export it. Preparing a shared disk volume with the
same major and minor device number may require changes in the hardware or
software configuration. If the shared disk volume is built on top of volume
management software, additional steps may be necessary when the volume
manager is installed.
This section provides some tips for preparing volume managers for use as NFS
servers in the ASCC environment.


13.4.1 LVM2 on Linux

When creating a new volume with the lvcreate command, use the
‘--persistent=y’ and ‘--minor <num>’ options to assign the same
persistent minor number.




U42147-J-Z100-4-76                                                            233
Log files                                       Appendix—Site preparation


13.5        Log files

13.5.1      /var/log/messages

By default, all ASCC messages go to both the system log, messages, and the
ASCC switchlog file (located by default in /var/opt/SMAWRrms/log). If you
do not want to send messages to the system log, then set HV_SYSLOG_USE =
 0 in the hvenv.local file. By default, HV_SYSLOG_USE = 1.




234                                                      U42147-J-Z100-4-76
14         Appendix—NFS file system notes

14.1       NFS mount point management
When an NFS mount point is configured using PCS, RMS actually mounts the
NFS volume at a private mount point in /usr/opt/reliant/dev/nfs. The
private mount point is a unique subdirectory with a name of the form
RMSNFS<XXXXX><suffix>, where <XXXXX> is a random five-digit number in the
range 10000 to 99999, and <suffix> is the user-specified mount point with
slashes (/) changed to underscores (_). The user-requested mount point is
implemented as a symbolic link to the private mount point.
Example:
nfshost:/nfs_export_dir is configured to be mounted on /mnt/dir, but is
actually mounted at /usr/opt/reliant/dev/nfs/RMSNFS10114_mnt_dir.
The requested name, /mnt/dir, will be a symbolic link that points to the actual
NFS directory in /usr/opt/reliant/dev/nfs/.
This approach is designed to avoid the situation in which a umount command
hangs because the remote server is down or failing. Before issuing a umount
command, RMS first checks to see if the server is responding. If not, it will
simply remove the symbolic link at the user-requested mount point. The file
system at the actual NFS mount point in /usr/opt/reliant/dev/nfs/ will
remain mounted, but it will be marked as a “garbage” NFS mount point.
RMS invokes hvcleanupnfs to collect all garbage NFS mount points and
unmount them if possible. If hvcleanupnfs determines that the server for a
garbage mount point is still down, it will simply skip it and re-examine it at the
next invocation. If the server is responding, hvcleanupnfs issues a umount
command for the mount point.
I The df command shows the mount as
       /opt/SMAW/SMAWRrms/dev/nfs/RMSNFS<XXXXX><suffix> instead of
       /usr/opt/reliant/dev/nfs/RMSNFS<XXXXX><suffix>.




U42147-J-Z100-4-76                                                             235
Example 1


14.2       Synchronized NFS file systems
ASCC allows RMS applications that manage NFS file system resources to
coordinate with other applications that manage the corresponding physical
mount point resources. When both applications—the one containing the NFS
file system and the one containing the physical file system—are managed by
RMS, the NFS file system is more likely to be highly available.
The applications containing NFS file systems are referred to as NFS client
applications. Applications containing the corresponding physical mount-
point(s) are referred to as NFS server applications. For consistent operation,
these NFS applications must be synchronized as follows:
●   During online processing, NFS server applications come online before NFS
    client applications.
●   During offline processing, NFS client applications go offline before the corre-
    sponding NFS server applications go offline.
In a PCS configuration, the NFS client file system is managed by the Remote File
System subapplication (see “Remote File System subapplication” on page 117).
The server’s physical mount point is managed by the Local File System subappli-
cation (see “Local File System subapplication” on page 112).


14.2.1 Example 1: One server and one client

As a simple example, consider an RMS configuration containing the following
applications:
1. NFSserver is an NFS server application that manages the physical file
   system /physical_fs. NFSserver is configured to run only on the node
   named node1.
2. NFSclient is an NFS client application that manages the NFS file system
   /remote_fs. NFSclient is configured to run only on the node named
   node2.
The #RMS# entries in /etc/fstab.pcl on either node are:
#RMS#/dev/dsk/c0t0d0s4 - /physical_fs ...
#RMS#node1:/physical_fs /remote_fs nfs ...




236                                                             U42147-J-Z100-4-76
                                                                        Example 2


The NFSserver application must come online on node1, mount
/physical_fs, and make the file system accessible to other nodes with the
share command. This must occur before the NFSclient application attempts
to mount the /remote_fs file system. Also, /remote_fs must be unmounted
on node2 before /physical_fs is unmounted on node1.
To enable the required synchronization of the client and server applications, the
Sync flag must be set to Yes in these subapplications:
●   The Remote File System subapplication of the NFS client application
●   The Local File System subapplication for the physical file system of the NFS
    server application.
Additionally, the Share flag must be set to Yes for the physical file system.
Note that this simple example is not good practice in the real world because
NFSclient and NFSserver are each configured on only one node; if either of
the nodes fails, there is no provision for failover.


14.2.2 Example 2: Multiple servers and clients

A more complex situation occurs when the physical file system resides on a
shared storage device, and the shared storage device is accessible by more
than one server node. To represent the node where the server application is
online, an IP address and a corresponding resource (host) name is entered in
the /etc/hosts file of each client. An Ip Address resource must then be
configured in the NFS server application (see “Ip Address subapplication” on
page 130). The #RMS# entry in the /etc/fstab.pcl file will reference the Ip
Address resource name rather than the actual node name.
In our example, the NFSserver application would be configured to run on all the
nodes that can access the shared storage device. In addition, an Ip Address
resource would be added to the NFSserver application.
The clients would also be modified to run on more than one node (usually, not
on any of the server nodes). Suppose the name of the server application’s Ip
Address resource is nfs_ip_alias. The corresponding entry in
/etc/fstab.pcl of each client node would be:
#RMS#nfs_ip_alias:/physical_fs /remote_fs nfs                ...




U42147-J-Z100-4-76                                                              237
15        Appendix—Object types
The following alphabetical list describes all object types that are supplied with
ASCC and configured by PCS.
ENV
       Required attributes:
       (none required)
       Object containing clusterwide (global) environment variables.
ENVL
       Required attributes:
       (none required)
       Object containing node-specific (local) environment variables.
gResource
     Required attributes:
     rKind
     rName
       Custom (generic) object. Usually represents system resources such as
       file systems, network interfaces, or system processes.
orOp
       Required attributes:
       (none required)
       Object associated with its children by a logical OR operator. This object
       type is online if at least one child is online.
satApplication
     Required attributes:
     (none required)
       Represents an application monitoring (RMS) pool on ASCC control
       nodes. One satApplication object is required for each configured
       application monitoring pool in the cluster, whether the pool is active or
       not. Must have a SatNode object as its parent.




U42147-J-Z100-4-76                                                            239
                                                     Appendix—Object types


SatContainer
     Required attributes:
     (none required)
      Represents a collection of SatNode objects. Typically, there is one
      SatContainer object for each VMware ESX server, and each SatNode
      object in the SatContainer represents a VMware virtual machine.
SatNode
     Required attributes:
     (none required)
      Represents a satellite node in the cluster on ASCC control nodes. There
      must be one SatNode object for each machine reserved by ASCC,
      whether the machine is assigned to a server group or not. Only
      satApplication or satService objects are allowed as its children.
satService
     Required attributes:
     (none required)
      Represents an IP load balancing (SIS) pool on ASCC control nodes. One
      satService object is required for each configured IP load balancing
      pool in the cluster, whether the pool is active or not. Must have a
      SatNode object as its parent.




240                                                        U42147-J-Z100-4-76
16        Appendix—Attributes
Some object types require specific attributes for RMS to monitor that object
type. Some attributes can be modified through the user interface, while others
are managed internally by PCS. The following sections list all attributes along
with their possible settings and default values.


16.1      Attributes available to the user
Attributes in this section can be changed using the PCS user interface.
AppStateScript
     Possible Values: Valid script (character)
     Default: “” (empty)
       Valid for satApplication objects. Specifies a script to be invoked
       whenever the application’s HV_APP_STATE variable changes, whether or
       not other requests are pending or other scripts are running. Typically,
       HV_APP_STATE changes when any of the following occurs:
       – A request has been issued for the satApplication on any node in
         the cluster.
       – A resource fails on a node where the satApplication was in either
         the Online or Standby state.
AutoRecover
     Possible Values: 0, 1
     Default: 0
       Valid for resource objects. If set to 1, executes the online script for an
       object if the object becomes faulted while in an Online state. If the object
       is able to return to the Online state, the fault is recovered.
ClusterExclusive
     Possible Values: 0, 1
     Default: 0
       Valid for resource objects. If set to 1, guarantees that the resource is
       Online on only one node in the cluster at any time. If set to 0, allows a
       resource to be Online on more than one node at a time.
       The user can modify this attribute for a cmdline subapplication only. The
       configuration tools control this attribute for all other subapplications.


U42147-J-Z100-4-76                                                             241
Attributes available to the user                              Appendix—Attributes


FaultScript
     Possible Values: Valid script (character)
     Default: “” (empty)
       Valid for all object types. Specifies a script to be run if the associated
       resource enters the Faulted state.
Halt
       Possible Values: 0, 1
       Default: 0
       Valid for satApplication objects. Eliminates a node if a double fault
       occurs and the satApplication can be switched to another node.
I_List
     Possible Values: Space-separated list of SatNode names
     Default: “” (empty)
       Valid for all SatNode objects. List of additional cluster interconnects that
       should be monitored by ASCC. These interconnects are used only by
       customer applications and not by any PRIMECLUSTER products. All
       monitored interconnects must be found in the /etc/hosts database. In
       addition, all SatNode objects must have the same number of additional
       interconnects.
LieOffline
     Possible Values: 0, 1
     Default: 1
       Valid for all resource objects. If set to 1, allows the resource to remain
       Online during Offline processing.
MonitorOnly
     Possible Values: 0, 1
     Default: 0
       Valid for resource objects. If set to 1, the state of the object is ignored by
       the parent when calculating the parent’s state. Any parent should have at
       least one child for which MonitorOnly is not set.
OfflineScript
     Possible Values: Valid script (character)
     Default: “” (empty)
       Valid for all object types except SatNode objects. Specifies the script to
       be run to bring the associated resource to the Offline state.




242                                                               U42147-J-Z100-4-76
Appendix—Attributes                              Attributes available to the user


OnlinePriority
     Possible Values: 0, 1
     Default: 0
      Valid for satApplication objects. Allows ASCC to start the application
      on the node where it was last online when the entire cluster was brought
      down and then restarted. If set to 0 or not set (the default), the application
      comes online on the node with the highest priority in the attribute
      PriorityList. If set to 1, the application comes online on the node
      where it was last online. In case of AutoStartUp or a priority switch, this
      last-online node has the highest priority, regardless of its position in the
      priority list.
      ASCC keeps track of where the application was last online by means of
      timestamps. The node which has the latest timestamp for an application
      is the node on which the application will go online. Different cluster nodes
      should be in time-synchronization with each other, but this is not always
      the case. Since ASCC does not provide a mechanism for ensuring time-
      synchronization between the nodes in the cluster, this responsibility is left
      to the system administrator. If ASCC detects a severe time-discrepancy
      between the nodes in the cluster, an ERROR message is printed to the
      switchlog.
      The ntp time service should be used to establish consistent time across
      the nodes in the cluster. Refer to the manual page for ntpd or xntpd for
      more information.
      The OnlinePriority persistent state information will be cleared if
      ASCC is restarted with the last online node removed from the configu-
      ration.
OnlineScript
     Possible Values: Valid script (character)
     Default: “” (empty)
      Valid for all objects except SatNode objects. Specifies the script to bring
      the associated resource to the Online state.
PersistentFault
     Possible Values: 0, 1
     Default: 0




U42147-J-Z100-4-76                                                              243
Attributes available to the user                           Appendix—Attributes


      Valid for satApplication objects. If set to 1, the application maintains
      a Faulted state across an ASCC shutdown and restart. The application
      returns to the Faulted state if it was Faulted before, unless the fault is
      explicitly cleared by either ‘hvutil –c’ or ‘hvswitch –f’, or if ASCC is
      restarted with the Faulted SatNode removed from the configuration.
PostOfflineScript
     Possible Values: Valid script (character)
     Default: “” (empty)
      Valid for all objects except SatNode objects. Specifies the script to be run
      after the state of the associated resource changes to Offline.
PostOnlineScript
     Possible Values: Valid script (character)
     Default: “” (empty)
      Valid for all objects except SatNode objects. Specifies the script to be run
      after the state of the associated resource changes to Online.
PreOfflineScript
     Possible Values: Valid script (character)
     Default: “” (empty)
      Valid for all objects except SatNode objects. Specifies the script to run
      before the object is taken to the Offline state.
PreOnlineScript
     Possible Values: Valid script (character)
     Default: “” (empty)
      Valid for all objects except SatNode objects. Specifies the script to be run
      before the associated resource is taken to the Online state.
PreserveState
     Possible Values: 0, 1
     Default: 0
      Valid for satApplication objects. Specifies that resources are not to be
      taken Offline after a fault. Ignored if AutoSwitchOver is not set to No.




244                                                            U42147-J-Z100-4-76
Appendix—Attributes                           Attributes available to the user


ScriptTimeout
     Possible Values: 0–MAXINT (in seconds) or valid string of the form
     “timeout_value[:[offline_value][:online_value]]”
     Default: 300
      Valid for all object types. Specifies the timeout value for all scripts
      associated with that object in the configuration file. RMS sends a kill
      signal to the script if the timeout expires.
      Use the string format to specify individual timeout values of offline_value
      for OfflineScript and online_value for OnlineScript.
ShutdownPriority
     Possible Values: 0–MAXINT
     Default: 0
      Valid for satApplication objects. ShutdownPriority assigns a
      weight factor to the application for use by the Shutdown Facility.
      When interconnect failures and the resulting concurrent node elimination
      requests occur, SF calculates the shutdown priority of each subcluster as
      the sum of the subcluster’s SF node weights plus the ASCC
      ShutdownPriority of all online application objects in the subcluster.
      The optimal subcluster is defined as the fully connected subcluster with
      the highest weight.
StandbyCapable
     Possible Values: 0, 1
     Default: 0
      Valid for resource objects. If set to 1, the object performs standby
      processing on all nodes where the parent application is supposed to be
      Offline.
      The user can modify this attribute for a cmdline subapplication only. The
      configuration tools control this attribute for all other subapplications.
StandbyTransitions
     Possible Values: StartUp, SwitchRequest, ClearFaultRequest or
     any combination joined by vertical bars (|)
     Default: “” (empty)
      Valid for satApplication objects. The value specifies when standby
      processing is initiated for the application object:




U42147-J-Z100-4-76                                                              245
Attributes managed by configuration wizards                 Appendix—Attributes


        – StartUp—at startup. This setting is ignored if the real-world appli-
          cation is already online, or if the application object is forced to go
          online because the AutoStartUp attribute is set.
        – SwitchRequest—after application switchover, if the application was
          online before the switchover.
        – ClearFaultRequest—after a faulted state is cleared with
          ‘hvutil -c’.
WarningScript
     Possible Values: Valid script (character)
     Default: “” (empty)
        Valid for resource objects with detector. Specifies the script to be run
        after the posted state of the associated resource changes to Warning.


16.2       Attributes managed by configuration
           wizards
Attributes in this section are managed internally by the configuration wizards or
by ASCC at runtime. Some attributes that are valid on ASCC control nodes can
be changed indirectly via the ASCC GUI or wizard.
Affiliation
     Possible Values: Any string
     Default: “” (empty)
        Valid for resource objects. Used for display purposes in the user
        interface—no functional meaning within ASCC.
Cabinet
     Possible Values: Valid string (character)
     Default: none
        Valid for SatNode objects on ASCC control nodes. If the machine is a
        blade, specifies the name of its blade server cabinet. Empty for non-
        blades.
Class
        Possible Values: any string
        Default: Default type defined in the chapter “Appendix—Object types” on
        page 239.




246                                                            U42147-J-Z100-4-76
Appendix—Attributes           Attributes managed by configuration wizards


      Valid for all objects except SatNode. Describes the class of the resource
      object. Used by other programs for various purposes (for example,
      SNMP agents). This value is supplied by the configuration wizards.
Comment
     Possible Values: any string
     Default: “” (empty)
      Valid for all objects. Used for documentation in the configuration file—no
      functional meaning within ASCC.
DeploymentMethod
     Possible Values: Valid string (character)
     Default: none
      Valid for gResource and SatNode objects on ASCC control nodes.
      Specifies the name of the deployment method used for the machine.
DetectorStartScript
     Possible Values: Any valid detector start script
     Default: “” (empty)
      Valid for resource object with detector. Specify the detector start
      command directly in the <configname>.us file.
LastDetectorReport
     Possible Values: Online, Offline, Faulted, Standby
     Default: (none)
      Valid for resource objects with detector. This attribute contains the most
      recent detector report for the object. The value may be displayed in the
      Cluster Admin GUI; the possible values depend on the type of resource
      the object represents.
MachLocation
     Possible Values: Valid string (character)
     Default: none
      Valid for SatNode objects on ASCC control nodes. Specifies the location
      of the machine. For blades, the location is of the form
      <Cabinet>:<SlotID>.
MaxInstance
     Possible Values: Valid string (character)
     Default: 0
      Valid for satApplication and satService objects on ASCC control
      nodes. Specifies the maximum instance limit for the task group.


U42147-J-Z100-4-76                                                          247
Attributes managed by configuration wizards                  Appendix—Attributes


MinInstance
     Possible Values: Valid string (character)
     Default: 0
      Valid for satApplication and satService objects on ASCC control
      nodes. Specifies the minimum instance limit for the task group.
MonitoringAgent
     Possible Values: Valid string (character)
     Default: none
      Valid for satApplication and satService objects on ASCC control
      nodes. Specifies the name of the load monitoring agent.
NoDisplay
     Possible Values: 0, 1
     Default: 0
      Valid for all object types. If set to 1, specifies that the resource should not
      be displayed when hvdisp is active. Can be overridden by ‘hvdisp -S’.
NullDetector
     Possible Values: on, off
     Default: off
      Valid for resource objects with detector. Used to disable a detector at
      runtime by setting NullDetector to on. This attribute is for use with
      dynamic reconfiguration only. NullDetector must never be set hard-
      coded to on in the ASCC configuration file.
OfflineDoneScript
     Possible Values: Valid script (character)
     Default: “” (empty)
      Valid for satApplication objects. The last script run after the appli-
      cation has completed offline processing.
OSImage
     Possible Values: Valid string (character)
     Default: none
      Valid for gResource and SatNode objects on ASCC control nodes.
      Specifies the name of the image currently deployed to the machine.




248                                                              U42147-J-Z100-4-76
Appendix—Attributes           Attributes managed by configuration wizards


PoolID
     Possible Values: Valid string (character)
     Default: none
      Valid for satApplication and satService objects on ASCC control
      nodes. Specifies the name of the currently assigned task group.
PoolType
     Possible Values: Valid string (character)
     Default: none
      Valid for satApplication and satService objects on ASCC control
      nodes. Specifies the type of the currently assigned task group.
PreCheckScript
     Possible Values: Valid script (character)
     Default: “” (empty)
      Valid for satApplication objects. Specifies the script to be forked as
      the first action during Online or Standby processing. If the script returns
      with a zero exit code, processing proceeds. If the script returns with an
      exit code other than zero, processing is not performed and an appro-
      priate warning is logged to the switchlog file.
QoSHWM
     Possible Values: Valid string (character)
     Default: 80
      Valid for satApplication and satService objects on ASCC control
      nodes. Specifies the high watermark load level for the task group.
QoSLWM
     Possible Values: Valid string (character)
     Default: 20
      Valid for satApplication and satService objects on ASCC control
      nodes. Specifies the low watermark load level for the task group.
QoSMetric
     Possible Values: Valid string (character)
     Default: %CPU
      Valid for satApplication and satService objects on ASCC control
      nodes. Specifies the load sensing library for the task group.




U42147-J-Z100-4-76                                                           249
Attributes managed by configuration wizards                 Appendix—Attributes


rKind
        Possible Values: 0–2047
        Default: none
        Valid for gResource objects. Specifies the kind of detector for the object.
rName
        Possible Values: Valid string (character)
        Default: none
        Valid for gResource objects. Specifies a string to be forwarded to the
        generic detector.
ServerGroup
     Possible Values: Valid string (character)
     Default: none
        Valid for gResource and SatNode objects on ASCC control nodes.
        Specifies a name of the deployment Server Group assigned to the
        machine.
SlotID
     Possible Values: Valid string (character)
     Default: none
        Valid for SatNode objects on ASCC control nodes. Specifies the slot
        number of the machine in a blade server cabinet. Empty for non-blades.




250                                                             U42147-J-Z100-4-76
Glossary
Items in this glossary that apply to specific ASCC components are indicated
with the following notation:
●   (ASCC)—Adaptive Services Control Center
●   (PCS)—PRIMECLUSTER Configuration Services
●   (RMS)—Reliant Monitor Services (ASCC application monitoring)
●   (SIS)—Scalable Internet Services (ASCC IP load balancing)


activating a configuration (RMS)
       Preparing an RMS configuration to be run on a cluster. The user can
       activate a configuration using PCS.
active control node (ASCC)
       See control node (ASCC).
administrative LAN
     An optional private local area network (LAN) used for administrative
     commands to the nodes in the cluster. To provide an extra level of
     security, normal users do not have access to the administrative LAN.
       See also public LAN.
agentless node (ASCC)
      A satellite node that is controlled by the User Defined deployment
      method and that has no ASCC agents installed. If these nodes are
      VMware ESX servers, they are container nodes and can be assigned to
      server domains managed by a container task group. Otherwise, they can
      be assigned to server domains that are managed by an agentless task
      group.
       ASCC cannot directly control applications on agentless nodes. It can
       only control the node’s power or sense the node’s state with an appli-
       cation sensing method, Like other User Defined nodes, the node
       software configuration is fixed, so ASCC cannot take or deploy an image.
       However, ASCC maintains agentless nodes in server domains with
       associated pseudo-images, so these nodes can be provisioned with the
       same model as all other satellite nodes.




U42147-J-Z100-4-76                                                         251
Glossary


       See also application sensing (ASCC), deployment (ASCC), server
       domain (ASCC), User Defined deployment method (ASCC).
agentless task group (ASCC)
      A task group that controls agentless nodes. Agentless task groups have
      no load metric, so their nodes are provisioned to conform to the minimum
      and maximum number of nodes allowed for the group.
       See also load metric (ASCC), task group (ASCC).
alive method (ASCC)
       See application sensing (ASCC).
API
       See Application Program Interface.
application (RMS)
      In the RMS context, an application object is a special resource used to
      group other resources into a logical collection. Typically, it is used to
      represent a real-world application or application suite in a high-avail-
      ability configuration.
application configuration (ASCC)
      A generic term that refers to an application monitoring configuration, an
      IP load balancing configuration, or an agentless configuration. Typically,
      an application configuration is prepared and saved on a node in manual
      mode using PCS, and then the node image is saved for later deployment.
      Application monitoring configurations each have a unique name, and
      several can be stored in the same image. IP load balancing and
      agentless configurations are unnamed, and only one can be stored in an
      image.
       An application configuration and the image that contains it must be
       specified as two of the parameters in a task group, which is the funda-
       mental object monitored by ASCC.
       See also application monitoring (ASCC), IP load balancing (ASCC), task
       group (ASCC).
application monitoring (ASCC)
      An application configuration that monitors the local application to
      maintain high availability. If the local application or any of its configured
      resources fails or unexpectedly goes offline, the satellite node’s agent
      reports it to the ASCC control node. Depending on the application’s
      configuration settings, this may initiate a provisioning operation to bring
      the application online on another node.



252                                                             U42147-J-Z100-4-76
                                                                      Glossary


      Application monitoring configurations are created and edited with PCS.
      Multiple application monitoring configurations can be stored in a single
      image, which enables ASCC to retask the node by simply switching to a
      different configuration. Unless the user has chosen to omit the load
      balancing drivers during installation, application monitoring configura-
      tions allow IP load balancing specifications for one or more service ports.
      On Linux servers, the ASCC application monitoring facility is imple-
      mented by Reliant Monitor Services (RMS). On Windows servers, ASCC
      application monitoring facility is implemented by the Windows Appli-
      cation Control Interface (WACI).
      See also application configuration (ASCC), IP load balancing (ASCC),
      Reliant Monitor Services (RMS), Windows Application Control Interface
      (ASCC).
Application Program Interface
      A shared boundary between a service provider and the application that
      uses that service.
application sensing (ASCC)
      An method that checks the status of an application on a node controlled
      by the User Defined deployment method.
      See also agentless node (ASCC), load metric (ASCC), User Defined
      deployment method (ASCC).
application template (RMS)
      A predefined group of object definition value choices used by PCS or the
      PCS Wizard Kit to create object definitions for a specific type of appli-
      cation.
ASCC agents (ASCC)
     The ASCC software components that run on satellite nodes. These
     agents communicate with the control nodes to report the local node’s
     status and performance. For nodes managed by the supported
     deployment methods, the agents also provide a shutdown capability for
     provisioning operations. ASCC agents are required for nodes that will be
     part of application monitoring or IP load balancing task groups.
      See also agentless node (ASCC), deployment (ASCC).
ASCC cluster (ASCC)
     The collection of machines governed by a single ASCC configuration.
     Every ASCC cluster has two control nodes in a tightly-coupled subcluster
     that manage the satellite nodes. The satellite nodes form a loosely-


U42147-J-Z100-4-76                                                           253
Glossary


      coupled cluster that can run a variety of user applications or services.
      ASCC dynamically provisions the satellite nodes according to the appli-
      cation priority, system load, and resource limit requirements specified in
      the configuration. The number of satellites dedicated to an application
      can vary over time, and the total number of satellites in the ASCC cluster
      can be scaled to the data center’s requirements.
ASCC GUI (ASCC)
     The Java-based, graphical user interface (GUI) to ASCC management
     functions on the control nodes. The GUI can be launched from a Java-
     enabled browser on any workstation that has access to the cluster’s
     control nodes over an administrative LAN (if present), the public LAN, or
     the private LAN. Using the GUI, the administrator can monitor the
     cluster’s performance, launch the ASCC Wizard, and make a subset of
     the configuration adjustments available in the ASCC Wizard
ASCC Wizard (ASCC)
     The Java-based, graphical user interface to the complete set of ASCC
     controls. The administrator can create and modify all components of an
     ASCC configuration (including server domains, application configura-
     tions, and task groups), control the state of any satellite node, launch
     PCS on a satellite to configure application monitoring, and take and
     deploy images.
attribute (RMS)
       The part of an object definition that specifies how the base monitor acts
       and reacts for a particular object type during normal operations.
availability
      Availability describes the need of most enterprises to operate applica-
      tions via the Internet 24 hours a day, 7 days a week. The relationship of
      the actual to the planned usage time determines the availability of a
      system.
base monitor (RMS)
     The RMS module that maintains the availability of resources. The base
     monitor is supported by daemons and detectors. Each node being
     monitored has its own copy of the base monitor.
CCD (ASCC)
      See core control daemon (ASCC).
CF
      See Cluster Foundation (CF).




254                                                           U42147-J-Z100-4-76
                                                                        Glossary


child (RMS)
       A resource defined in the configuration file that has at least one parent.
       A child can have multiple parents, and can either have children itself
       (making it also a parent) or no children (making it a leaf object).
       See also resource (RMS), object (RMS), parent (RMS).
cloning (ASCC)
      A deployment method that transmits an entire image to a target host.
      After transmission, the target host typically reboots and runs a script that
      sets the appropriate host name, IP address, and other parameters as
      directed by the deployment server. Several reboots may be required to
      prepare the target host to join the cluster, domain, or workgroup. The
      host’s local disks store the image and any application data across
      reboots.
       See also deployment (ASCC), Netboot (ASCC).
cluster
      A set of computers that work together as a single computing source.
      Specifically, a cluster performs a distributed form of parallel computing.
       See also RMS configuration (RMS).
Cluster Admin
      A Java-based, OS-independent management tool for ASCC products
      such as RMS and PCS. Cluster Admin is available from the Web-Based
      Admin View interface.
       See also Reliant Monitor Services (RMS), PRIMECLUSTER Configu-
       ration Services (PCS), Web-Based Admin View.
Cluster Foundation (CF)
      The set of ASCC modules that provides basic clustering communication
      services. In ASCC clusters, these modules provide services for the
      control node sub-cluster.
container node (ASCC)
      A specific type of satellite node in an ASCC cluster that can be provi-
      sioned to run virtual machines. The administrator must install and
      configure the appropriate VM manager before assigning the container
      node to an ASCC deployment method. ASCC supports VMware ESX
      virtual servers without VirtualCenter (VC).




U42147-J-Z100-4-76                                                            255
Glossary


      Container nodes are usually referred to simply as containers. Because
      they are always User Defined nodes without ASCC agents, they cannot
      be in a server domain assigned to an application monitoring or IP load
      balancing task group. However, they are automatically associated with
      special container task groups.
container task group (ASCC)
      A type of task group in an ASCC cluster that controls only container
      nodes. Container task groups have additional parameters that ASCC
      needs to control their internal virtual machines. Like agentless tasks
      groups, they have no load metric.
      See also control node (ASCC), satellite node (ASCC), application
      monitoring (ASCC), IP load balancing (ASCC).
control node (ASCC)
      One of the two nodes in the ASCC cluster that automatically monitor and
      provision the satellite nodes. In normal operation, one control node is
      designated as the active (or primary) control node, which runs the core
      control daemon (CCD) to perform the bulk of the ASCC management
      operations. The other control node is the standby (or secondary) control
      node, which can take over ASCC management if the active node fails.
      The control nodes are actually a sub-cluster that perform ASCC tasks in
      a high-availability configuration.
      Once installed on the control nodes, the ASCC software is intended to
      run 24/7, so these nodes are never automatically reprovisioned.
      Therefore, control nodes should never be configured to run user applica-
      tions such as databases or web servers: those tasks are relegated to the
      satellite nodes.
      See also satellite node (ASCC).
core control daemon (ASCC)
      The background process that runs on the primary control node and
      controls all automatic ASCC operations on the satellite nodes. The
      administrator interacts with the core control daemon (CCD) via the ASCC
      GUI or the ASCC Wizard, either of which can modify the CCD’s configu-
      ration.
      The CCD monitors the satellite nodes by gathering information from
      various agents such as the satellite control daemon (SCD) on application
      monitoring nodes, the Scalable Internet Services (SIS) agent on IP load
      balancing nodes, or consultant-supplied metric libraries or “alive
      methods.”



256                                                          U42147-J-Z100-4-76
                                                                       Glossary


       See also control node (ASCC), satellite node (ASCC), application
       monitoring (ASCC), IP load balancing (ASCC).
daemon
     A continuous process that performs a specific function repeatedly.
deployment (ASCC)
      A method of provisioning that transmits an image and makes the
      necessary adjustments to a target host so it can be booted as a unique,
      fully functional member of a network. ASCC supports cloning and
      Netboot deployment methods.
       See also provisioning (ASCC), image (ASCC), cloning (ASCC), Netboot
       (ASCC), RemoteDeploy (ASCC).
deployment server (ASCC)
      A host that manages the deployment process. The same host often
      provides tools to manage the method’s image repository.
detector (RMS)
      A process that monitors the state of a specific object type and reports a
      change in the resource state to the RMS base monitor.
DHCP
       Dynamic Host Control Protocol. A standard method of delivering infor-
       mation to a host at boot time. This is most often used to dynamically
       assign the host’s IP address and netmask, but many other parameters
       are possible, including domain names, DNS servers, and time servers.
domain (ASCC)
     See server domain (ASCC).
environment variables
      Variables or parameters that are defined globally.
error detection (RMS)
       The process of detecting an error. For RMS, this includes initiating a log
       entry, sending a message to a log file, or making an appropriate recovery
       response.
generating a configuration (RMS)
     The process of creating a single configuration file that can be activated
     at a later time. This is normally done automatically when the configu-
     ration is activated using PCS or the CLI.
       See also activating a configuration (RMS).




U42147-J-Z100-4-76                                                           257
Glossary


generic type (RMS)
      An object type which has generic properties. A generic type is used to
      customize RMS for monitoring resources that cannot be assigned to one
      of the supplied object types.
       See also object type (RMS).
graph (RMS)
      See system graph (RMS).
graphical user interface
      A computer interface with windows, icons, toolbars, and pull-down
      menus that is designed to be simpler to use than the command-line
      interface.
group (ASCC)
      See task group (ASCC).
GUI
       See graphical user interface.
high availability
      A system design philosophy in which redundant resources are employed
      to avoid single points of failure.
       See also Reliant Monitor Services (RMS).
image (ASCC)
     A complete copy of the disk data of a host, stored in a way that makes it
     possible to restore the host to its operating state at the time the copy was
     made. ASCC images are intended to be restored to a variety of hosts, so
     they are prepared with special markers that allow such items as the host
     name and IP address to be replaced with different values after it is
     restored. Most of these details are managed by the deployment method,
     either before the image is saved, or after the image is restored.
       These images typically contain drivers for every possible device that may
       exist on the eventual targets, so identical hardware configurations are not
       a requirement. In the case of Windows images, the plug-and-play
       process is triggered after restoration.
       See also deployment (ASCC), cloning (ASCC), Netboot (ASCC).




258                                                            U42147-J-Z100-4-76
                                                                        Glossary


image repository (ASCC)
     A specified location for storage and maintenance of deployment images.
     Depending on the deployment method, this may be a local disk on the
     deployment server, a shared disk on a network filer, or a virtual disk on a
     storage area network.
       See also deployment (ASCC).
Internet Protocol address
      A numeric address that can be assigned to computers or applications.
       See also IP aliasing.
IP address
      See Internet Protocol address.
IP aliasing
       This enables several IP addresses (aliases) to be allocated to one
       physical network interface. With IP aliasing, the user can continue
       communicating with the same IP address, even though the application is
       now running on another node.
       See also Internet Protocol address.
IP load balancing (ASCC)
       An application configuration that monitors the local network load and
       reports it to the ASCC control node. This facility operates on a virtual
       interface, which must be configured with an IP address and netmask, one
       or more ports and their associated services, a default port to monitor, and
       one of the built-in algorithms to distribute the load.
       The IP load balancing facility can be included in an image as a single,
       dedicated configuration, in which case the network load is reported by
       the IP load balancing agent. The IP load balancing facility can also be
       specified as an optional feature for some application monitoring configu-
       rations, in which case the load is reported by the satellite control daemon
       (SCD).
       The ASCC IP load balancing facility is also known as Scalable Internet
       Services (SIS).
       See also application configuration (ASCC), application monitoring
       (ASCC).




U42147-J-Z100-4-76                                                            259
Glossary


keyword
     A word that has special meaning in a programming language. For
     example, in an RMS configuration file, the keyword object identifies the
     kind of definition that follows.
leaf object (RMS)
       A bottom object in a system graph. In the configuration file, this object
       definition is at the beginning of the file. A leaf object does not have
       children.
link (RMS)
       Designates a child or parent relationship between specific resources.
load metric (ASCC)
      A programmatic method that determines the relative load on a single
      satellite node and reports it to the control nodes. By default, ASCC
      provides a CPU load metric, but the load can also be calculated by a
      consultant-supplied library. In all cases, ASCC agents must be installed
      on the node so the load can be reported to the control nodes.
       A load metric is required for all nodes in application monitoring or IP load
       balancing task groups. Agentless User Defined nodes such as
       containers have no load metric,
       See also application sensing (ASCC), ASCC agents (ASCC), container
       node (ASCC), task group (ASCC).
local area network
       See public LAN.
local node
       The node from which a command or process is initiated.
       See also remote node, node.
log file
        The file that contains a record of significant system events or messages.
        The ASCC control and satellite daemons maintain log files on every node
        on which they run. PCS, the RMS base monitor, and RMS detectors each
        maintain their own log files as well.
managed server (ASCC)
     See satellite node (ASCC).




260                                                             U42147-J-Z100-4-76
                                                                        Glossary


Management Information Base
     A hierarchical database of information about the local network device.
     The database is maintained by network management software such as
     an SNMP agent.
       See also Simple Network Management Protocol.
manual mode (ASCC)
     The non-automatic state of ASCC satellite nodes that allows an admin-
     istrator to perform various maintenance tasks. These tasks include
     manually shutting down or powering up the node, installing OS or appli-
     cation software, creating configurations with the ASCC Wizard or PCS,
     and taking or loading an image. A node cannot be automatically provi-
     sioned by ASCC while it is in manual mode.
message
     A set of data transmitted from one software process to another process,
     device, or file.
message queue
     A designated memory area which acts as a holding place for messages
     so they can be processed in the same order they were received.
MIB
       See Management Information Base.
mount point
     The point in the directory tree where a file system is attached.
multihosting
      Multiple controllers simultaneously accessing a set of disk drives.
native operating system
      The part of an operating system that is always active and translates
      system calls into activities.
Netboot (ASCC)
     A deployment method that manages the image for a running host on
     network-attached disks. The host downloads only those portions of the
     image that are required to run an application and related OS processes.
     The host’s local disks are only used for swap space, so the image and
     application data are not retained across reboots.
       See also deployment (ASCC), cloning (ASCC).
node
       A host that is a member of a cluster.


U42147-J-Z100-4-76                                                           261
Glossary


object (RMS)
      A representation of a physical or virtual resource in the RMS configu-
      ration file or in a system graph.
       See also leaf object (RMS), object definition (RMS), object type (RMS).
object definition (RMS)
      An entry in the configuration file that identifies a resource to be monitored
      by RMS. Attributes included in the definition specify properties of the
      corresponding resource.
       See also attribute (RMS), object type (RMS).
object type (RMS)
      A category of similar resources monitored as a group, such as disk
      drives. Each object type has specific properties, or attributes, which limit
      or define what monitoring or action can occur. When a resource is
      associated with a particular object type, attributes associated with that
      object type are applied to the resource.
       See also generic type (RMS).
online maintenance
      The capability of adding, removing, replacing, or recovering devices
      without shutting or powering off the node.
parent (RMS)
      An object in the RMS configuration file or system graph that has at least
      one child.
       See also child (RMS), system graph (RMS).
PCS
       See PRIMECLUSTER Configuration Services (PCS).
PCS Wizard Kit (PCS)
     RMS configuration products that have been designed for specific appli-
     cations. Each component of the PCS Wizard Kit includes customized
     default settings, subapplications, detectors, and scripts. These appli-
     cation wizards also tailor the PCS interface to provide controls for the
     additional features.
       See also PCS, Reliant Monitor Services (RMS).
primary control node (ASCC)
      See control node (ASCC).




262                                                             U42147-J-Z100-4-76
                                                                       Glossary


PRIMECLUSTER Configuration Services (PCS)
     The graphical configuration interface for ASCC products. PCS uses
     standard templates to provide a user-friendly configuration environment
     for products such as RMS. The standard templates can be modified or
     replaced to provide a customized interface for specific applications or
     installations.
private network addresses
       Private network addresses are a reserved range of IP addresses
       specified by the Internet Corporation for Assigned Names and Numbers
       (ICANN). Modern switches and routers prevent these addresses from
       being routed to the Internet, allowing two or more organizations to assign
       the same private addresses for internal use without causing conflicts or
       security risks.
private resource (RMS)
       A resource accessible only by a single node and not accessible to other
       RMS nodes.
       See also resource (RMS), shared resource.
provisioning (ASCC)
      The process of allocating resources to satisfy a demand. In the ASCC
      context, the fundamental resources are nodes in the cluster, and the
      demand is determined by the relative performance of applications in their
      respective task groups. ASCC can provision a node by using either
      deployment (transmitting an image) or retasking (modifying the current
      image’s configuration).
       See also deployment (ASCC), retasking (ASCC).
public LAN
      The local area network (LAN) by which normal users access a machine.
       See also administrative LAN.
PXE (ASCC)
      Preboot Execution Environment. This protocol, typically embedded in a
      host’s firmware, allows the host to be dynamically controlled at boot time.
      When PXE is initiated, it first requests an IP address from a DHCP
      server. If this is successful, it then requests a Network Bootstrap
      Program (NBP) from a network boot server. The downloaded NBP then
      controls the remainder of the boot process.




U42147-J-Z100-4-76                                                           263
Glossary


        PXE, which is maintained by the Intel Corporation, also specifies a
        standard method of initiating the pre-boot firmware as well as a set of
        APIs to be employed by the NBP or the host BIOS.
        See also DHCP, RemoteDeploy (ASCC).
QoS (ASCC)
      See quality of service (ASCC).
quality of service (ASCC)
       A measure of performance for a system. In the ASCC context, quality of
       service (QoS) is specified by a combination of application priority,
       maximum and minimum node instance limits, and high and low loading
       watermarks.
queue
        See message queue.
redundancy
     The capability of one component to assume the resource load of another
     physically similar component in case the original component fails or is
     shut down. Common examples include RAID hardware and/or RAID
     software to replicate data stored on secondary storage devices, multiple
     network connections to provide alternate data paths, and multiple nodes
     that can be dynamically reprovisioned to maintain critical services in a
     cluster.
Reliant Monitor Services (RMS)
      The package that maintains high availability of user-specified resources
      by providing monitoring and switchover capabilities on Linux platforms.
remote node
     A node that is accessed through a LAN or telecommunications line.
        See also local node, node.
RemoteDeploy (ASCC)
     A cloning deployment method supported by ASCC. RemoteDeploy
     works with Intel Linux and Windows hosts and requires PXE in the target
     host’s firmware.
        See also deployment (ASCC), cloning (ASCC), PXE (ASCC).
reporting message (RMS)
      A message that a detector uses to report the state of a particular
      resource to the base monitor.




264                                                            U42147-J-Z100-4-76
                                                                      Glossary


repurposing (ASCC)
      See retasking (ASCC).
resource (RMS)
      A hardware or software element (private or shared) that provides a
      function such as a mirrored disk, mirrored disk pieces, or a database
      server. A local resource is monitored only by the local node.
      See also private resource (RMS), shared resource.
resource definition (RMS)
      See object definition (RMS).
resource label (RMS)
      The name of the resource as displayed in a system graph.
resource state (RMS)
      Current state of a resource.
retasking (ASCC)
      A method of provisioning in which ASCC switches to a different appli-
      cation configuration or starts a different virtual machine (VM). Retasking
      does not require an image deployment.
      See also deployment (ASCC).
RMS
      See Reliant Monitor Services (RMS).
RMS commands (RMS)
     Commands that enable RMS resources to be administered from the
     command line.
RMS configuration (RMS)
     A configuration made up of two or more nodes connected to shared
     resources. Each node has its own copy of operating system and RMS
     software, as well as its own applications.
SAN
      See Storage Area Network.
satellite container (ASCC)
       See container node (ASCC).




U42147-J-Z100-4-76                                                          265
Glossary


satellite control daemon (ASCC)
       The ASCC background process that runs on application monitoring
       satellite nodes. The satellite control daemon (SCD) maintains the
       heartbeat of the node within the cluster and reports system load infor-
       mation to the core control daemon (CCD). It also executes local retasking
       actions as directed by the CCD.
       See also core control daemon (ASCC), retasking (ASCC).
satellite node (ASCC)
       A node in an ASCC cluster that can be provisioned to run user applica-
       tions or services. In normal operation, satellite nodes are automatically
       monitored and managed by the CCD on the control nodes. Satellites may
       be put into manual mode to enable maintenance operations such as
       software updates and image saving and cloning.
       See also control node (ASCC), CCD (ASCC), provisioning (ASCC).
scalability
      The ability of a computing system to efficiently handle any dynamic
      change in work load. Scalability is especially important for Internet-based
      applications where growth caused by Internet usage presents a scalable
      challenge.
Scalable Internet Services (SIS)
      The package that dynamically balances network traffic loads across
      cluster satellite nodes while maintaining normal client/server sessions for
      each connection.
SCD (ASCC)
      See satellite control daemon (ASCC).
script (RMS)
       A shell program executed by the base monitor in response to a state
       transition in a resource. The script may cause the state of a resource to
       change.
secondary control node (ASCC)
     See control node (ASCC).
server domain (ASCC)
      A set of nodes with identical or sufficiently similar hardware such that an
      image that runs on one node will run on every other node in the domain.
      This does not mean that all nodes in the domain must run the same
      image simultaneously. For instance, a domain may be assigned to two
      different task groups, each of which is configured with a different image,



266                                                            U42147-J-Z100-4-76
                                                                    Glossary


       e.g., Linux and Windows. Depending on the QoS settings, some nodes in
       the domain may be running the Linux task, some nodes may be running
       the Windows task, and some nodes may be idle.
       Server domains are defined in the ASCC Wizard. All machines in a
       server domain must be assigned to the same deployment method.
       See also image (ASCC), task group (ASCC).
ServerView (ASCC)
      The remote management software supplied with Fujitsu Siemens
      Computers blade servers and standalone hosts.
ServerView agent (ASCC)
      A daemon or service installed on a Fujitsu Siemens host that allows the
      host to be monitored or shut down from a ServerView management
      server.
SF
       See Shutdown Facility.
shared resource
      A resource, such as a disk drive, that is accessible to more than one
      node.
       See also private resource (RMS), resource (RMS).
Shutdown Facility
     The ASCC interface that manages the shutdown of satellite nodes. The
     SF is automatically invoked during failover or deployment operations. It
     also notifies other ASCC products of the successful completion of node
     shutdown so that recovery operations can begin.
Simple Network Management Protocol
     A set of protocols that facilitates the exchange of information between
     managed network devices. The protocols are implemented by software
     agents residing in the devices. Each agent can read and write data in the
     local Management Information Base (MIB) in response to SNMP
     requests from other devices on the network.
       See also Management Information Base.
SIS
       See Scalable Internet Services (SIS).
SNMP
       See Simple Network Management Protocol.



U42147-J-Z100-4-76                                                        267
Glossary


standby control node (ASCC)
      See control node (ASCC).
state
        See resource state (RMS).
Storage Area Network
      The high-speed network that connects multiple, external storage units
      and storage units with multiple computers. The connections are
      generally fiber channels.
subapplication (RMS)
     A part of the configuration template that is designed to configure one
     resource type for high availability. The RMS configuration may include
     multiple instances of each resource type. The Generic template contains
     subapplications for commands, IP addresses, virtual host names, local
     and remote file systems, volume managers, and storage managers.
system graph (RMS)
     A visual representation (a map) of monitored resources used to develop
     or interpret the RMS configuration file.
task group (ASCC)
      A combination of QoS settings, one or more server domains, and
      compatible deployment parameters. This effectively defines the role of a
      task in an ASCC cluster by establishing where it can run and its impor-
      tance relative to other tasks.
        Task groups are defined in the ASCC Wizard. The available deployment
        parameters depend on the deployment method previously configured for
        each server domain, and may specify images (possibly with a specific
        application configuration), virtual machines, or plugin parameters. The
        performance of each task group can be viewed or modified in the ASCC
        GUI.
        See also application configuration (ASCC), image (ASCC), server
        domain (ASCC).
template
      See application template (RMS).




268                                                          U42147-J-Z100-4-76
                                                                          Glossary


tftp server (ASCC)
       A server that transmits data using the trivial file transfer protocol (tftp).
       Unlike ftp, which operates with TCP and requires a user name and
       password to initiate a transfer, tftp operates with UDP and provides no
       security features. tftp is often used to transfer boot programs to
       network-bootable devices.
type
       See object type (RMS).
User Defined deployment method (ASCC)
      A deployment method that provides rudimentary power monitoring and
      control of satellites that are not associated with any other ASCC
      deployment method. No image deployment will be done by ASCC for this
      method: the administrator must set up each host manually, and then
      provide the list of hosts to ASCC.
       The User Defined deployment method is used with VMware ESX servers
       without VirtualCenter. Its universal design allows it to be adapted to any
       Linux, Solaris, or Windows host.
User Defined node (ASCC)
      A node controlled by the User Defined deployment method. Depending
      on the architecture, a User Defined node may run the ASCC agents that
      are required for members of application monitoring or IP load balancing
      task groups. If ASCC agents are not available for the node’s architecture.
      or they are not installed, then the node can only operate as an agentless
      node. A container node is a special case of an agentless User Defined
      node.
       See also agentless node (ASCC), ASCC agents (ASCC), container node
       (ASCC).
virtual disk
       A pseudo-device that allows a portion or a combination of physical disks
       to be treated as a single logical disk. The virtual disk driver is inserted
       between the highest level of the OS logical input/output (I/O) system and
       the physical device driver(s), allowing all logical I/O requests to be
       mapped to the appropriate area on the physical disk(s).
WACI (ASCC)
      See Windows Application Control Interface (ASCC).
watermark (ASCC)
     A maximum or minimum load level specified as one of the quality of
     service (QoS) settings.


U42147-J-Z100-4-76                                                              269
Glossary


       See also quality of service (ASCC).
Web-Based Admin View
     A Java-based, OS-independent interface to ASCC management compo-
     nents.
       See also Cluster Admin.
Windows Application Control Interface (ASCC)
     An ASCC agent that provides application monitoring capabilities for
     Windows nodes. This agent can start, stop, and monitor Windows
     services, or any program or process that can be controlled from the
     command line.
wizard (RMS)
      An interactive software tool that creates a specific type of application
      using pretested object definitions.
Wizard Kit (RMS)
      See PCS Wizard Kit (PCS).




270                                                           U42147-J-Z100-4-76
Abbreviations
API
       application program interface
ASCC
       Adaptive Services Control Center
CCD
       core control daemon
CF
       Cluster Foundation or Cluster Framework
CIM
       Cluster Integrity Monitor
CIP
       Cluster Interconnect Protocol
CLI
       command line interface
DHCP
       Dynamic Host Control Protocol
DLPI
       Data Link Provider Interface
GUI
       graphical user interface
HA
       high availability
I/O
       input/output
LAN
       local area network
MIB
       Management Information Base
MMB
       Management Board (on PRIMEQUEST systems)




U42147-J-Z100-4-76                                271
Abbreviations


NIC
       network interface card
PCS
       PRIMECLUSTER Configuration Services
PXE
       Preboot Execution Environment
QoS
       Quality of Service
RMS
       Reliant Monitor Services
SA
       Shutdown Agent
SAN
       Storage Area Network
SCD
       satellite control daemon
SD
       Shutdown Daemon
SF
       Shutdown Facility
SIS
       Scalable Internet Services
SNMP
       Simple Network Management Protocol
UD
       User Defined, as in User Defined deployment method




272                                                         U42147-J-Z100-4-76
                                               Abbreviations


VC
       VirtualCenter
VIP
       Virtual Interface Provider
VNC
       Virtual Network Connection
WACI
       Windows Application Control Interface




U42147-J-Z100-4-76                                      273
Figures
Figure 1:    Interface between ASCC and the operating system . . .              14

Figure 2:    Hierarchy of Applications and subapplications . . . . . .         30

Figure 3:    Typical GENERIC application structure . . . . . . . . . .          32

Figure 4:    Configuration graph for a Generic application      . . . . . .    33
Figure 5:    PCS data directory structure . . . . . . . . . . . . . . .         36

Figure 6:    Selecting a reference node . . . . . . . . . . . . . . . .        44
Figure 7:    Configuring application monitoring on Linux reference node        45
Figure 8:    Initial PCS window . . . . . . . . . . . . . . . . . . . .         46

Figure 9:    Entering a new configuration name . . . . . . . . . . . .          47
Figure 10:   Configuration start window . . . . . . . . . . . . . . . .         48

Figure 11:   PCS configuration tree and user input area . . . . . . . .        52

Figure 12:   Configuration tree structure . . . . . . . . . . . . . . . .       53

Figure 13:   Configuration tree icons and colors . . . . . . . . . . . .       54
Figure 14:   PCS button bar . . . . . . . . . . . . . . . . . . . . . .         56

Figure 15:   File menu in initial view (left) and editing view (right) . . .   57
Figure 16:   Confirmation message if changes have not been saved .              57
Figure 17:   Exiting PCS: Confirmation message . . . . . . . . . . .           58

Figure 18:   File menu: Deleting configurations from initial view . . . .      58

Figure 19:   Available configurations to delete . . . . . . . . . . . . .       58
Figure 20:   Selected configurations to delete . . . . . . . . . . . . .        59

Figure 21:   Confirming the deletion . . . . . . . . . . . . . . . . . .        59

Figure 22:   File menu in editing view . . . . . . . . . . . . . . . . .       60
Figure 23:   Edit menu . . . . . . . . . . . . . . . . . . . . . . . . .        61

Figure 24:   Adding or deleting instances . . . . . . . . . . . . . . .         62


U42147-J-Z100-4-76                                                             275
Figures


Figure 25:   Choosing detector settings . . . . . . . . . . . . . . . .       63

Figure 26:   Detector settings for pcsdet_system . . . . . . . . . . .        63

Figure 27:   Closing detector settings . . . . . . . . . . . . . . . . .      64

Figure 28:   Renaming an application . . . . . . . . . . . . . . . . .        65

Figure 29:   Deleting an application . . . . . . . . . . . . . . . . . .      66

Figure 30:   Confirming application deletion . . . . . . . . . . . . . .      66
Figure 31:   Tools menu . . . . . . . . . . . . . . . . . . . . . . . .       67

Figure 32:   PCS configuration graph for a Generic application . . . .        68
Figure 33:   Displaying item properties from the PCS graph . . . . . .        69

Figure 34:   Manually executing a script from a PCS graph context menu        70

Figure 35:   Manual script execution output window . . . . . . . . . .        71
Figure 36:   Activating the configuration . . . . . . . . . . . . . . . .     71

Figure 37:   Successful activation message . . . . . . . . . . . . . .        72

Figure 38:   Locking or unlocking the configuration . . . . . . . . . .       72

Figure 39:   Providing the configuration password . . . . . . . . . . .       73
Figure 40:   Manually checking configuration consistency . . . . . . .        73

Figure 41:   Option menu before configuration is selected . . . . . . .       74

Figure 42:   Option menu after configuration is selected . . . . . . . .      74
Figure 43:   Help menu     . . . . . . . . . . . . . . . . . . . . . . . .    76

Figure 44:   General online help . . . . . . . . . . . . . . . . . . . .      77

Figure 45:   Subapplication help menu      . . . . . . . . . . . . . . . .    78
Figure 46:   Subapplication help message . . . . . . . . . . . . . . .        78

Figure 47:   Context-sensitive help menu . . . . . . . . . . . . . . .        79

Figure 48:   Context-sensitive help message . . . . . . . . . . . . .         79

Figure 49:   Tooltip help . . . . . . . . . . . . . . . . . . . . . . . .     80

Figure 50:   Subapplications in Generic application structure . . . . .       85


276                                                            U42147-J-Z100-4-76
                                                                         Figures


Figure 51:   Changing the application name       . . . . . . . . . . . . .    86

Figure 52:   Viewing the application template information . . . . . . .      87

Figure 53:   Application parameters . . . . . . . . . . . . . . . . . .       88

Figure 54:   Application parameters (expert mode) . . . . . . . . . .         89

Figure 55:   Subapplication initial view . . . . . . . . . . . . . . . . .   91

Figure 56:   Configuring first instance of a subapplication . . . . . . .     92
Figure 57:   Creating multiple instances: Add More button      . . . . . .    93

Figure 58:   Creating multiple instances: Add More Instances menu .           94
Figure 59:   Creating multiple instances: selecting multiple targets . .      94

Figure 60:   Toggling expert mode . . . . . . . . . . . . . . . . . . .       95

Figure 61:   Subapplication group options (expert mode) . . . . . . .         97
Figure 62:   Dynamic Command Line inserted in Local File System
             subapplication . . . . . . . . . . . . . . . . . . . . . . .     99
Figure 63:   Creating a dynamic subapplication (expert mode) . . . .         100

Figure 64:   Dynamic subapplication options (expert mode) . . . . . .        101

Figure 65:   Choosing a dynamic subapplication type (expert mode) .          101

Figure 66:   Dynamic subapplication configuration (expert mode) . . .        102
Figure 67:   Command Line initial view     . . . . . . . . . . . . . . . .   104

Figure 68:   Command Line parameters . . . . . . . . . . . . . . . .         105

Figure 69:   Command Line parameters (expert mode) . . . . . . . .           106
Figure 70:   CmdLine custom exit codes (expert mode) . . . . . . . .         107

Figure 71:   CmdLine group options (expert mode) . . . . . . . . . .         108

Figure 72:   Local File System initial view . . . . . . . . . . . . . . .    112
Figure 73:   Local File System parameters      . . . . . . . . . . . . . .   113

Figure 74:   Local File System parameters (expert mode) . . . . . . .        114

Figure 75:   Local File System group options (expert mode)       . . . . .   116



U42147-J-Z100-4-76                                                           277
Figures


Figure 76:   Remote File System initial view . . . . . . . . . . . . . .     117

Figure 77:   Remote File System parameters . . . . . . . . . . . . .         118

Figure 78:   Remote File System parameters (expert mode) . . . . .           119

Figure 79:   Remote File System group options (expert mode) . . . .          121

Figure 80:   Raw Disk initial view   . . . . . . . . . . . . . . . . . . .   122

Figure 81:   Raw Disk parameters . . . . . . . . . . . . . . . . . . .       124
Figure 82:   Raw Disk parameters using clusterwide name . . . . . .          125

Figure 83:   Raw Disk group options (expert mode) . . . . . . . . . .        126
Figure 84:   Ip Address initial view . . . . . . . . . . . . . . . . . . .   131

Figure 85:   Ip Address parameters . . . . . . . . . . . . . . . . . .       132

Figure 86:   Ip Address ping host list . . . . . . . . . . . . . . . . . .   133
Figure 87:   Ip Address parameters (expert mode) . . . . . . . . . .         134

Figure 88:   Ip Address group options (expert mode) . . . . . . . . .        135

Figure 89:   Virtual Host initial view . . . . . . . . . . . . . . . . . .   136

Figure 90:   Virtual Host parameters . . . . . . . . . . . . . . . . . .     139
Figure 91:   Assigning an IP address to a virtual host . . . . . . . . .     140

Figure 92:   Virtual host with no IP address . . . . . . . . . . . . . .     141

Figure 93:   Assigning an IP address to a virtual host . . . . . . . . .     142
Figure 94:   Inconsistent virtual host with IP address . . . . . . . . .     142

Figure 95:   Consistent virtual host with IP address . . . . . . . . . .     143

Figure 96:   Selecting ping host for virtual host IP address . . . . . .     144
Figure 97:   Virtual host name with IP address (expert mode) . . . . .       145

Figure 98:   Selecting the Volume Manager group for configuration . .        148

Figure 99:   Selecting a member of the Linux Volume Manager group            149

Figure 100: Linux Volume Manager initial view . . . . . . . . . . . .        150

Figure 101: Linux Volume Manager parameters . . . . . . . . . . . .          151


278                                                            U42147-J-Z100-4-76
                                                                         Figures


Figure 102: Linux Volume Manager parameters (expert mode) . . . .            152

Figure 103: Linux Volume Manager group options (expert mode) . . .           154

Figure 104: Selecting the Storage Manager group for configuration        .   155

Figure 105: Selecting a member of the Storage Manager group . . .            156

Figure 106: Starting the configuration wizard . . . . . . . . . . . . .      159

Figure 107: Starting PCS on a reference node . . . . . . . . . . . .         159
Figure 108: Entering a new configuration name . . . . . . . . . . . .        160

Figure 109: Configuration start window . . . . . . . . . . . . . . . .       161
Figure 110: Selecting application name . . . . . . . . . . . . . . . .       162

Figure 111: Application template information . . . . . . . . . . . . .       163

Figure 112: Application parameters . . . . . . . . . . . . . . . . . .       164
Figure 113: Command Line initial view      . . . . . . . . . . . . . . . .   165

Figure 114: Command Line parameters . . . . . . . . . . . . . . . .          166

Figure 115: Local File System initial view . . . . . . . . . . . . . . .     167

Figure 116: Local File System parameters       . . . . . . . . . . . . . .   168
Figure 117: Remote File System initial view . . . . . . . . . . . . . .      169

Figure 118: Remote File System parameters . . . . . . . . . . . . .          170

Figure 119: Ip Address initial view . . . . . . . . . . . . . . . . . . .    171
Figure 120: Ip Address parameters . . . . . . . . . . . . . . . . . .        172

Figure 121: Ip Address ping host list . . . . . . . . . . . . . . . . . .    172

Figure 122: Saving the configuration     . . . . . . . . . . . . . . . . .   173
Figure 123: Message after successful save . . . . . . . . . . . . . .        173

Figure 124: Activating the configuration . . . . . . . . . . . . . . . .     174

Figure 125: Message after successful activation      . . . . . . . . . . .   174

Figure 126: Opening the graph on the satellite node, step 1      . . . . .   175

Figure 127: Opening the graph on the satellite node, step 2      . . . . .   175


U42147-J-Z100-4-76                                                           279
Figures


Figure 128: Starting application monitoring on the satellite node . . .       176

Figure 129: Initial satellite graph . . . . . . . . . . . . . . . . . . . .   176

Figure 130: Starting application monitoring test from graph . . . . . .       177

Figure 131: Prompt to bring application online      . . . . . . . . . . . .   178

Figure 132: Intermediate graph during online processing . . . . . . .         178

Figure 133: Graph after successful online processing . . . . . . . . .        179
Figure 134: Stopping application monitoring test from graph . . . . .         180

Figure 135: Viewing object information . . . . . . . . . . . . . . . .        181
Figure 136: Viewing node switchlog from graph . . . . . . . . . . . .         182

Figure 137: Viewing application log from graph . . . . . . . . . . . .        183

Figure 138: Log file viewer window . . . . . . . . . . . . . . . . . .        184
Figure 139: Search based on date and time range . . . . . . . . . .           185

Figure 140: Search based on resource name . . . . . . . . . . . . .           186

Figure 141: Search based on severity level . . . . . . . . . . . . . .        187

Figure 142: Search based on keyword         . . . . . . . . . . . . . . . .   188
Figure 143: Using the pop-up Find dialog in log viewer . . . . . . . .        189

Figure 144: Taking an image from the wizard . . . . . . . . . . . . .         190

Figure 145: Taking an image from the wizard . . . . . . . . . . . . .         191
Figure 146: Starting the ASCC wizard . . . . . . . . . . . . . . . . .        196

Figure 147: Navigating to the Windows reference node . . . . . . . .          196

Figure 148: Prompt for Windows ACI password . . . . . . . . . . . .           197
Figure 149: Entering a new configuration name . . . . . . . . . . . .         198

Figure 150: Selecting an application template . . . . . . . . . . . . .       199

Figure 151: Naming the Windows ASCC application . . . . . . . . .             200

Figure 152: WACI introduction view . . . . . . . . . . . . . . . . . .        201

Figure 153: Choosing WACI services and scripts . . . . . . . . . . .          202


280                                                             U42147-J-Z100-4-76
                                                                        Figures


Figure 154: Selecting Windows services      . . . . . . . . . . . . . . .   203

Figure 155: Updated view showing selected Windows services . . . .          204

Figure 156: Updated view with information line . . . . . . . . . . . .      204

Figure 157: Setting a Windows service to start manually . . . . . . .       206

Figure 158: Configuring Windows start/stop/monitor scripts      . . . . .   207

Figure 159: Windows start/stop/monitor input fields . . . . . . . . . .     208
Figure 160: Completed Start/Stop/Monitor command set . . . . . . .          210

Figure 161: Creating another WindowsSSM instance . . . . . . . . .          210
Figure 162: New WindowsSSM instance . . . . . . . . . . . . . . .           211

Figure 163: Deleting a WindowsSSM instance . . . . . . . . . . . .          211

Figure 164: Configuring both Windows services and scripts       . . . . .   212
Figure 165: Activating the configuration . . . . . . . . . . . . . . . .    213

Figure 166: Message after successful activation     . . . . . . . . . . .   213

Figure 167: Generating the configuration . . . . . . . . . . . . . . .      214

Figure 168: Message after successful generation . . . . . . . . . . .       214
Figure 169: ASCC agent settings . . . . . . . . . . . . . . . . . . .       216

Figure 170: Setting the PCS Configuration Path . . . . . . . . . . . .      217

Figure 171: Selecting an application for a new task group     . . . . . .   218
Figure 172: Selecting a node to search for new task definitions . . . .     219

Figure 173: Selecting a new task definition from the target node . . .      220




U42147-J-Z100-4-76                                                          281
Tables
Table 1:   ASCC base directory structure . . . . . . . . . . . . . . . .      23

Table 2:   Log directory structure . . . . . . . . . . . . . . . . . . . .    23

Table 3:   Commonly used PCS terms . . . . . . . . . . . . . . . . .          40

Table 4:   Standard PCS subapplication templates . . . . . . . . . . .       84
Table 5:   RMS severity level description . . . . . . . . . . . . . . . .    187

Table 6:   RMS host name conventions in /etc/hosts . . . . . . . . . .       224




U42147-J-Z100-4-76                                                           283
Index
                                         Affiliation attribute 246
#RMS# entries                            application logs
    /etc/exports.pcl 115, 231                searching text 189
    /etc/fstab.pcl 112, 117, 229, 236,   application templates
        237                                  comparison of 33
/dev/raw/ directory 122                      defined 26
/dev/rd/ directory 122                       dependency structure 27
/etc/dktab file 152                          help 78
/etc/exports.pcl 115, 231                applications
/etc/fstab.pcl 229                           as objects 12
    conflicts in /etc/fstab 229              creating 65, 86
    local file systems 112                   deleting 66
    remote file systems 117                  failover 15
/etc/hosts 223                               parameter settings 89
    and /etc/fstab.pcl entries 230           renaming 65
    and network interface                    structure 28
        names 226                        AppStateScript attribute 20, 241
    Ip Address subapplication 130        ASCC
    ping host list 133, 144                  base monitor 10
    virtual host names 136               asconf utility
/opt/SMAW/SMAWRrms/ 22, 23                   trusted login 225
/root/.rhosts 225                        attributes 21
/usr/, and raw disks 123                     Affiliation 246
/var/, and raw disks 123                     AppStateScript 241
/var/log/messages 234                        AutoRecover 241
/var/opt/SMAWpcs/trace/                      Cabinet 246
    directory 75                             Class 246
/var/opt/SMAWRrms/log/ 23                    ClusterExclusive 241
                                             Comment 247
A                                            DeploymentMethod 247
absolute path names, and                     DetectorStartScript 247
    CommandLine                              ENV object 239
    subapplication 105                       FaultScript 242
activating                                   for gResource objects 239
    configurations 71                        for orOp objects 239
Adaptive Services Control Center             for satApplication objects 239
    (ASCC) User Guide 223, 225               for SatContainer objects 240
Add More button 93                           for SatNode objects 240
adding                                       for satService objects 240
    instances 61                             Halt 242
adding route, in hvipalias file 228          I_List 242


U42147-J-Z100-4-76                                                        285
Index


   LastDetectorReport 247     blades
   LieOffline 242                 interface device failover and
   MachLocation 247                   BX300 228
   MaxInstance 247            browser, and online
   MinInstance 248                documentation 76
   MonitoringAgent 248        build, RMS directory 23
   MonitorOnly 242            buttons
   NoDisplay 248                  Add More 93
   NullDetector 248               button bar 56
   OfflineDoneScript 248          Filter, log viewer 184
   OfflineScript 242              right mouse 79
   OnlinePriority 243
   OnlineScript 243           C
   OSImage 248                Cabinet attribute
   PersistentFault 243           SatNode object 246
   PoolID 249                 Caution
   PoolType 249                  defined 6
   PostOfflineScript 244         Detector settings rarely need
   PostOnlineScript 244              adjustment 62
   PreCheckScript 249            Do not activate a trace option
   PreOfflineScript 244              without instructions from a PCS
   PreOnlineScript 244               expert 75
   PreserveState 244             Do not customize script settings in
   QoSHWM 249                        a working RMS configuration
   QoSLWM 249                        without expert advice 89, 98,
   QoSMetric 249                     127
   required 35                   Do not modify the
   rName 250                         RELIANT_PATH/bin/hvenv
   ScriptTimeout 245                 file 22
   ServerGroup 250               Do not use KeepOnline setting to
   ShutdownPriority 245              allow two independent applica-
   SlotID 250                        tions to share a single disk
   StandbyCapable 245                group 153
   WarningScript 246             File –> Save As removes original
authentication, trusted 225          configuration’s lock and
AutoRecover attribute 241            password 73
AutoRecover, setting 96          Use care when specifying a full
                                     path name as the Raw Disk
B                                    name filter 123
backup directory, PCS 37         Use care when specifying ifconfig
base monitor 17                      settings for the blade network
    high availability 11             interface 228
    object states 18          changing
bin, RMS directory 23            detector settings 62


286                                                U42147-J-Z100-4-76
                                                                    Index


checking consistency 73, 75              instances, and performance 35
Class attribute 246                      objects 35
client applications                  consistent state
    NFS 236                              PCS icon 55
cloning                              context menus
    configurations 60                    PCS graph 176, 180
closing configurations 60                starting script 70
cluster 1                            context sensitive help 79
    high availability 9              controls, PCS GUI 52
Cluster Admin                        creating
    searching log text 189               applications 65, 86
cluster exclusive 120                    configurations 25, 30, 46, 47,
ClusterExclusive attribute 241               160, 198
CommandLine subapplication               instances 35
    absolute path names 105              instances, multiple 93
    defined 104                          result templates 37
    ksh used for commands 105            subapplication instances 28
Comment attribute 247                    symbolic link for Raw Disk
commonly used PCS terms 40                   subapplication 122
comparison, application types 33     Ctrl key
Config.satellite directory, PCS 36       context-sensitive help 79
configuration tree                   Ctrl-click, selecting multiple items
    PCS 53                               with 94
    PCS object icon 55               Custom templates 33
    PCS status icon 55               custom wizards 30, 31
configurations                           help 78
    activating 71
    cloning 60                       D
    closing 60                       DBMS Wizard, PCS 31
    creating 25, 47, 160, 198        Deact state 18
    defined 10                       debug messages
    deleting 58                         severity level 187
    generating 67                    deleting
    hierarchy 29                        applications 66
    locking 72                          configurations 58
    multiple, in one image 38           instances 61, 95
    password 72                         optional subapplications 36
    saved 58                            route, in hvipalias file 228
    saving 37, 60                    dependencies
    unlocking 72                        applications 28
confirmation messages                   Generic application template 84,
    unsaved changes 57, 59, 60, 66          85
consistency, checking 73, 75         dependency, and application
consistent                              resources 27


U42147-J-Z100-4-76                                                     287
Index


dependent resources, for                editing view
    application 12                          file menu 57
DeploymentMethod attribute              ENV object 21, 239
    gResource and SatNode               environment variables 21
         objects 247                        hvenv and hvenvl.local files 21
detection time, detectors 64            ENVL object 21, 239
detectors 11, 18                        etc, RMS directory 23
    changing settings 62                Examples directory, PCS 37
    CommandLine 105, 109                exit codes
    detection time 64                       RMS scripts 12
    log files 64                        exiting PCS 57
    log level 64                        expert mode, Option menu 74, 95
    memory log level 64                 exports file see /etc/exports.pcl
    pcsdet_system 63
    reaction time 64                    F
DetectorStartScript attribute 247       failover 11
device numbers, and shared NFS file          defined 15
    systems 115, 230, 233                    applications 15
dialogs                                      interface device, and BX300
    find, in log viewer 189                      blades 228
directories                                  interface device, for IP alias 226
    RMS 22                                   NFS file systems 233
directory structure, PCS 36                  nodes 15
disabled menu items 72, 78                   synchronized NFS file
disk classes                                     systems 237
    as application resources 16         Faulted state 18
disk volumes                                 FaultScript 20
    as configuration components 30      faults
DNS                                          messages, custom handling 228
    and /etc/fstab.pcl entries 230      FaultScript attribute 20, 242
    and cluster host names 223          FaultScript group option 98
Do not set the KeepOnline flag if the   file handle, NFS file systems 233
    file system must be cluster         File menu 57
    exclusive (used by only one node    file systems
    at a time) 120                           as application resources 16
documentation                                as configuration components 30
    online 76                                NFS failover 233
    related 3                                NFS, shared, and device
double faults                                    numbers 115, 230
    and Halt attribute 242                   NFS, synchronized 236
drawing a graph 68                           site preparation 223
                                        Filter button 184
E                                       FreeForm template 34
Edit menu   61                          fstab file see /etc/fstab.pcl


288                                                          U42147-J-Z100-4-76
                                                                           Index


G                                         hvutil command    90
generating, configurations 67
Generic application template 31, 35,      I
   83                                     I_List attribute 242
   features 84                            icons, PCS
   help 78                                     object, configuration tree 55
   optional subapplications 36                 status, configuration tree 55
   structure 84, 85                       ifconfig command 226, 227
Generic template 34                       images
global environment variables 21                and multiple task groups 38
graphs 10, 84                                  multiple configurations 38
   drawing 68                             include, RMS directory 23
grayed out menu items 72                  inconsistent objects 35
gResource objects 12                      Inconsistent Screen Only, Option
   object type definition 239                  menu 75
group options, subapplication 97          Inconsistent state 18
                                          inconsistent state
H                                              PCS icon 55
Halt attribute 242                        initial view
heartbeats 10, 17                              file menu 57
help                                      InitScript 19
    context sensitive 79                  instances 28, 53
    disabled menu items 78                     adding 61
    subapplications 78                         and templates 35
    tooltips 80                                consistent 35
Help menu 76                                   creating 35
hierarchy                                      creating multiple 93
    configurations 29                          deleting 61, 95
    objects 84                                 inconsistent 35
    template structure 30                 intended state, maintenance
high availability 1                            mode 19
hosts file see /etc/hosts                 internal structure, templates 35
hosts, site preparation 223               IP addresses
hvcleanupnfs, and NFS mount                    defining resources 16
    points 235                                 not allowed in /etc/fstab.pcl 230
hvconsoles file 98, 228                   IP alias 226
hvdisp command                            Ip Address subapplication 130
    no display 248                             and /etc/hosts 224
hvenv file 21                                  hvipalias.satellite file 226
hvenv.local file 22                       IPV6 addresses, RMS support 224
hvipalias.satellite file 130, 131, 140,
    226                                   K
    multiple entries 227                  kernel drivers, and IP load
hvswitch command 90, 109                     balancing 39


U42147-J-Z100-4-76                                                           289
Index


killing a node 13, 16                   Tools 67
ksh, and CommandLine                 messages
     subapplication 105                 confirmation 57, 59, 60, 66
                                        debug 187
L                                       fault, custom handling 228
LastDetectorReport attribute 247     MinInstance attribute
left pane                               satApplication and satService
     PCS configuration tree 53              objects 248
     PCS GUI 52                      MonitoringAgent attribute
lib, RMS directory 23                   satApplication and satService
LieOffline attribute 242                    objects 248
LILO, Linux boot manager 39          MonitorOnly attribute 242
local environment variables 21       MonitorOnly, setting 96
Local File System                    multiboot 39
     subapplication 112              multiple configurations in one
locking a configuration 72              image 38
log files                            multiple items, selecting 94
     and custom fault messages 228   mySAP Wizard, PCS 31
     detectors 64
     switchlog 234                   N
     system 234                      naming conventions, RMS 224
log level, detectors 64              NeedAll group option 98
logical interface name 226           netmask
login                                   in hvipalias file 226
     trusted, required by PCS 225    network addresses
LVM2 volume manager 233                 as configuration components 30
                                     network interfaces
M                                       in /etc/hosts 224
MachLocation attribute                  in hvipalias file 226
   SatNode object 247                networks
maintenance mode 19                     site preparation 223
market-specific                      NFS file systems
   applications 9                       failover 233
MaxInstance attribute                   shared, and device
   satApplication and satService             numbers 115, 230
       objects 247                      synchronized 236
memory log level, detectors 64       node names
menu bar 52                             in configuration files 223
menus                                nodes
   disabled items 72                    defined 10
   Edit 61                              failover 15
   File 57                              killing 13, 16
   Help 76                           NoDisplay attribute 248
   Option 74                         NullDetector attribute 248


290                                                     U42147-J-Z100-4-76
                                                                      Index


O                                      ops option in /etc/dktab 152
object states                          Option menu 74
     timeouts, tracking by base        optional
         monitor 10                       objects 35
object types                              subapplications, deleting 36
     ENV 239                           OSImage attribute
     ENVL 239                             gResource objects 248
     gResource 239
     orOp 239                          P
     satApplication 239                parent-child relationships, in
     SatContainer 240                     templates 30
     SatNode 240                       password, configurations 72
     satService 240                    path names, absolute, and
objects                                   CommandLine
     attributes 21                        subapplication 105
     consistent 35                     PCS 9
     environment variables 21             commonly used terms 40
     graph 84                             default scripts 89, 98, 127
     gResource 12                         directory structure 36
     hierarchical tree 84                 GUI views and controls 52
     icon, PCS configuration tree 55      online documentation 76
     inconsistent 35                      Trace option 75
     instances 35                         Wizard Kit 10
     resource types 20                 PCS Wizard Kit 31
     satApplication 12                 pcs_alert, and fault scripts 98
     SatNode 12                        pcsdet_system, detector 63, 105
offline processing 12                  performance, and consistency 35
Offline state 10, 18                   PersistentFault attribute 243
     OfflineDoneScript 20              physical interfaces
     OfflineScript 20                     IP aliases 226
     PostOfflineScript 20              ping host list 133, 144
OfflineDoneScript attribute 20, 248    PoolID attribute
OfflineFault state 18                     satApplication and satService
OfflineScript attribute 20, 242               objects 249
online documentation                   PoolType attribute
     PCS 76                               satApplication and satService
online processing 12                          objects 249
Online state 10, 18                    PostOfflineScript attribute 20, 244
     OnlineScript 20                   PostOnlineScript attribute 20, 244
     PostOnlineScript 20               PreCheckScript attribute 19, 249
     PreCheckScript 19                 PreOfflineScript attribute 244
     PreOnlineScript 20                PreOnlineScript attribute 20, 244
OnlinePriority attribute 243           PreserveState attribute 244
OnlineScript attribute 20, 243         PRIMECLUSTER 9


U42147-J-Z100-4-76                                                       291
Index


private LAN                               as configuration components 30
    and device failover 228               defining 16
proactive scripts 12                      file system entries 229
                                          help 78
Q                                         network interfaces 226
QoSHWM attribute                          object types 20
  satApplication and satService           scripts 17
     objects 249                          shared file systems 231
QoSLWM attribute                          states 10
  satApplication and satService       result templates
     objects 249                          creating 37
QoSMetric attribute                   right pane
  satApplication and satService           PCS GUI 52
     objects 249                      right-click, mouse
                                          context sensitive help with Ctrl
R                                              key 79
raw command 122                           starting script 70
Raw Disk subapplication 122           rKind attribute
RCVM subapplication 150                   gResource objects 239, 250
reaction time, detector 64            RMS
reactive scripts 12                       default directory 23
Real Time Consistency Check, Option       directory structure 22
    menu 75                               executing commands at
recovery, heartbeat timeout 10                 startup 19
related documentation 3                   naming conventions 224
Reliant Monitor Services                  severity levels 187
    see also RMS                      RMS Reference Guide 184
    components 17                     rName attribute
    high availability 10                  gResource objects 239, 250
    overview 9                        root partition, and raw disks 123
RELIANT_LOG_PATH 23                   route command 228
RELIANT_PATH 22, 23                   running processes 16
Remote File System                    runtime directory, PCS 37
    subapplication 117
renaming                              S
    applications 65                   satApplication objects 12
request-triggered scripts                object type definition 239
    InitScript 19                        state change script 20
    OfflineScript 20                  SatContainer objects
    OnlineScript 20                      object type definition 240
    PreCheckScript 19                 SATELLITE_NODE placeholder
    PreOnlineScript 20                   name 226
required attributes 35                SatNode objects 12
resources                                object type definition 240


292                                                      U42147-J-Z100-4-76
                                                                Index


satService objects               stale file handle, NFS 233
    object type definition 240   standard mode, Option menu 95
saved configurations 58          Standby state 18
saving                           StandbyCapable attribute 245
    configurations 37            state machine 10
scripts 12, 19                   states 18
    PCS default 89, 98, 127          definitions 18
    proactive 12                     changes, and initiating
    reactive 12                          actions 10
    resources 17                     changes, and scripts 12, 19
ScriptTimeout attribute 245          Deact 18
ScriptTimeout, setting 96            displayed in RMS graph 10
searching log                        Faulted 18
    case-sensitive 189               hosts 10
    not case-sensitive 188           Inconsistent 18
searching log text 189               Maintenance 19
selecting                            nodes, detecting in RMS 10
    configurations 46                objects, reported by detectors 11
    multiple items 94                Offline 18
ServerGroup attribute                OfflineFault 18
    gResource and SatNode            Online 18
        objects 250                  online and offline processing 12
servers, NFS                         reported by detectors 16
    applications 236                 resources, monitored by RMS 10
severity levels                      RMS, and real world 14
    Alert 187                        Standby 18
    Critical 187                     Unknown 18
    Debug 187                        Wait 19
    Emergency 187                    Warning 19
    Error 187                    states, PCS
    Info 187                         consistent 55
    Notice 187                       inconsistent 55
    Warning 187                  state-triggered scripts
Shutdown Facility 16                 FaultScript 20
    and RMS 13                       OfflineDoneScript 20
ShutdownPriority attribute 245       PostOfflineScript 20
site preparation 223                 PostOnlineScript 20
SlotID attribute                     WarningScript 20
    SatNode object 250           storage area networks 1
software monitor                 structure
    ASCC 9                           applications 28
    function 1                       configurations 29
SRI Wizard, PCS 31               subapplications 53
sshconf utility 225                  defined 27, 28


U42147-J-Z100-4-76                                                293
Index


   CommandLine 104                     timeouts
   common procedures 91                    heartbeat recovery 10
   configuring, checkbox 95            Tools menu 67
   creating instances 28               tooltips 80
   deleting instances 95               Trace, Option menu 75
   FaultScript group option 98         tree, configuration 53
   group options 97                    trusted login, required by PCS   225
   help 78
   Ip Address 130                      U
   Local File System 112               UDP protocol
   NeedAll group option 98                cluster heartbeat 10
   Raw Disk 122                        Unknown state 18
   RCVM 150                            unlocking a configuration 72
   Remote File System 117              unsaved changes 57, 60
   script timeout 96                   us directory, RMS 23
   templates 26, 28, 34
   Virtual Host 136                    V
swap partitions                        variables, environment 21
   raw disks 123                       virtual disks, and raw disks 123
switchlog 98, 234                      virtual host names
symbolic link, creating for Raw Disk       in /etc/hosts 225
   subapplication 122                  Virtual Host subapplication 136
synchronized NFS file systems 236      virtual representation 10
system files, and site                 volume managers 1, 16
   preparation 223
system log 234                         W
                                       Wait state 19
T                                      Warning state 19
task groups                               WarningScript 20
   and images 38                       WarningScript attribute 20, 246
   instance limits and Ip Address      Webserver Wizard, PCS 31
       subapplication 130              Wizard Kit, PCS 31
   instance limits and Virtual Host    wizards, custom 78
       subapplication 137
templates 30, 35
   and instances 35
   application 27
   Custom 33
   custom application 30
   FreeForm 34
   Generic 34
   Generic application 31, 35, 83
   subapplications 28, 34
Templates directory, PCS 37


294                                                        U42147-J-Z100-4-76
    Fujitsu Siemens Computers GmbH
    User Documentation
                                                                     Comments
    33094 Paderborn
    Germany
                                                                    Suggestions
                                                                     Corrections
    Fax: (++49) 700 / 372 00001


    email: manuals@fujitsu-siemens.com
    http://manuals.fujitsu-siemens.com

    Submitted by




    Comments on ASCC™
                PCS for Adaptive Services Control Center (Linux®, Windows®)
                Configuration Guide
✁




    U42147-J-Z100-4-76
    Fujitsu Siemens Computers GmbH
    User Documentation
                                                                     Comments
    33094 Paderborn
    Germany
                                                                    Suggestions
                                                                     Corrections
    Fax: (++49) 700 / 372 00001


    email: manuals@fujitsu-siemens.com
    http://manuals.fujitsu-siemens.com

    Submitted by




    Comments on ASCC™
                PCS for Adaptive Services Control Center (Linux®, Windows®)
                Configuration Guide
✁




    U42147-J-Z100-4-76

				
DOCUMENT INFO
Shared By:
Tags:
Stats:
views:22
posted:4/15/2011
language:German
pages:310