HP ProLiant DL380G5-WSS 3.7.0 HP StorageWorks HP Scalable NAS File Serving Sof - Page 354

A sample custom monitor, application caches transactions induced by requests from external users

Page 354 highlights

script that connects to the port and then tests how the script responds to various commands. NOTE: The user-defined monitor dialog prompts you for a service monitor name and not a port because you may be writing a monitor for an application that does not provide network services and therefore needs no port. A sample custom monitor This example uses service monitors with a custom application called myservice. This application provides some facilities to clients who connect to port 2468 and speak a protocol. You have already set up a virtual host called vh1 for the IP address to which external clients are going to connect. How do you make a service monitor for this application? The simplest way is to use a generic built-in TCP monitor on port 2468. This monitor verifies that it is possible to connect to port 2468, which probably indicates most of the time that the application is functioning. However, a problem might occur that causes the application to continue accepting connections but not produce meaningful output. To detect this situation, you will need a more complex and robust monitor involving a script written with a utility such as expect(1). This script connects to port 2468, sends a string specified by the protocol, and determines whether it has received an expected response. Distribute this script to the same location on all servers on virtual host vh1 and then create a CUSTOM service monitor, specifying the path of the script as the "user probe script" parameter. This provides verification of the connection and also a degree of content verification. The CUSTOM monitor can also include Start and Stop scripts. Suppose the myservice application caches transactions induced by requests from external users for later commitment to a back-end database server. You want to ensure that if a failover occurs, any transactions previously acknowledged by one server appear as complete to users connecting to the new server. This is the kind of situation where Start and Stop scripts are useful. The Stop script should commit all cached transactions to the back-end database. The Start script should force an update of your view of the database from the back-end server. Then, if the service moves from the primary server to a backup, all transactions performed on the primary will be sent to the database and from there to the backup server before connections are directed to the backup server. 354 Advanced monitor topics

  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24
  • 25
  • 26
  • 27
  • 28
  • 29
  • 30
  • 31
  • 32
  • 33
  • 34
  • 35
  • 36
  • 37
  • 38
  • 39
  • 40
  • 41
  • 42
  • 43
  • 44
  • 45
  • 46
  • 47
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102
  • 103
  • 104
  • 105
  • 106
  • 107
  • 108
  • 109
  • 110
  • 111
  • 112
  • 113
  • 114
  • 115
  • 116
  • 117
  • 118
  • 119
  • 120
  • 121
  • 122
  • 123
  • 124
  • 125
  • 126
  • 127
  • 128
  • 129
  • 130
  • 131
  • 132
  • 133
  • 134
  • 135
  • 136
  • 137
  • 138
  • 139
  • 140
  • 141
  • 142
  • 143
  • 144
  • 145
  • 146
  • 147
  • 148
  • 149
  • 150
  • 151
  • 152
  • 153
  • 154
  • 155
  • 156
  • 157
  • 158
  • 159
  • 160
  • 161
  • 162
  • 163
  • 164
  • 165
  • 166
  • 167
  • 168
  • 169
  • 170
  • 171
  • 172
  • 173
  • 174
  • 175
  • 176
  • 177
  • 178
  • 179
  • 180
  • 181
  • 182
  • 183
  • 184
  • 185
  • 186
  • 187
  • 188
  • 189
  • 190
  • 191
  • 192
  • 193
  • 194
  • 195
  • 196
  • 197
  • 198
  • 199
  • 200
  • 201
  • 202
  • 203
  • 204
  • 205
  • 206
  • 207
  • 208
  • 209
  • 210
  • 211
  • 212
  • 213
  • 214
  • 215
  • 216
  • 217
  • 218
  • 219
  • 220
  • 221
  • 222
  • 223
  • 224
  • 225
  • 226
  • 227
  • 228
  • 229
  • 230
  • 231
  • 232
  • 233
  • 234
  • 235
  • 236
  • 237
  • 238
  • 239
  • 240
  • 241
  • 242
  • 243
  • 244
  • 245
  • 246
  • 247
  • 248
  • 249
  • 250
  • 251
  • 252
  • 253
  • 254
  • 255
  • 256
  • 257
  • 258
  • 259
  • 260
  • 261
  • 262
  • 263
  • 264
  • 265
  • 266
  • 267
  • 268
  • 269
  • 270
  • 271
  • 272
  • 273
  • 274
  • 275
  • 276
  • 277
  • 278
  • 279
  • 280
  • 281
  • 282
  • 283
  • 284
  • 285
  • 286
  • 287
  • 288
  • 289
  • 290
  • 291
  • 292
  • 293
  • 294
  • 295
  • 296
  • 297
  • 298
  • 299
  • 300
  • 301
  • 302
  • 303
  • 304
  • 305
  • 306
  • 307
  • 308
  • 309
  • 310
  • 311
  • 312
  • 313
  • 314
  • 315
  • 316
  • 317
  • 318
  • 319
  • 320
  • 321
  • 322
  • 323
  • 324
  • 325
  • 326
  • 327
  • 328
  • 329
  • 330
  • 331
  • 332
  • 333
  • 334
  • 335
  • 336
  • 337
  • 338
  • 339
  • 340
  • 341
  • 342
  • 343
  • 344
  • 345
  • 346
  • 347
  • 348
  • 349
  • 350
  • 351
  • 352
  • 353
  • 354
  • 355
  • 356
  • 357
  • 358
  • 359
  • 360
  • 361
  • 362
  • 363
  • 364
  • 365
  • 366
  • 367
  • 368
  • 369
  • 370
  • 371
  • 372
  • 373
  • 374
  • 375
  • 376
  • 377
  • 378
  • 379
  • 380
  • 381
  • 382
  • 383
  • 384
  • 385
  • 386
  • 387
  • 388
  • 389
  • 390
  • 391
  • 392
  • 393
  • 394
  • 395
  • 396
  • 397
  • 398
  • 399
  • 400
  • 401
  • 402
  • 403
  • 404
  • 405
  • 406
  • 407
  • 408
  • 409
  • 410
  • 411
  • 412
  • 413
  • 414
  • 415
  • 416
  • 417
  • 418
  • 419
  • 420
  • 421
  • 422
  • 423
  • 424
  • 425
  • 426
  • 427
  • 428
  • 429
  • 430
  • 431
  • 432
  • 433
  • 434
  • 435

script that connects to the port and then tests how the script responds to various
commands.
NOTE:
The user-defined monitor dialog prompts you for a service monitor name and not
a port because you may be writing a monitor for an application that does not provide
network services and therefore needs no port.
A sample custom monitor
This example uses service monitors with a custom application called
myservice
.
This application provides some facilities to clients who connect to port 2468 and
speak a protocol. You have already set up a virtual host called vh1 for the IP address
to which external clients are going to connect. How do you make a service monitor
for this application?
The simplest way is to use a generic built-in TCP monitor on port 2468. This monitor
verifies that it is possible to connect to port 2468, which probably indicates most of
the time that the application is functioning. However, a problem might occur that
causes the application to continue accepting connections but not produce meaningful
output. To detect this situation, you will need a more complex and robust monitor
involving a script written with a utility such as
expect(1)
.
This script connects to port 2468, sends a string specified by the protocol, and
determines whether it has received an expected response. Distribute this script to the
same location on all servers on virtual host vh1 and then create a CUSTOM service
monitor, specifying the path of the script as the
user probe script
parameter. This
provides verification of the connection and also a degree of content verification.
The CUSTOM monitor can also include Start and Stop scripts. Suppose the
myservice
application caches transactions induced by requests from external users
for later commitment to a back-end database server. You want to ensure that if a
failover occurs, any transactions previously acknowledged by one server appear as
complete to users connecting to the new server. This is the kind of situation where
Start and Stop scripts are useful.
The Stop script should commit all cached transactions to the back-end database. The
Start script should force an update of your view of the database from the back-end
server. Then, if the service moves from the primary server to a backup, all transactions
performed on the primary will be sent to the database and from there to the backup
server before connections are directed to the backup server.
Advanced monitor topics
354