[Info-vax] Integrity iLO Configuration?

[Dave Froble]

On 6/25/2021 4:48 AM, Jan-Erik Söderholm wrote:
> Den 2021-06-25 kl. 00:38, skrev Dave Froble:
>> On 6/24/2021 3:10 PM, Bill Gunshannon wrote:
>>> On 6/24/21 2:44 PM, Dave Froble wrote:
>>>> On 6/24/2021 1:19 PM, Stephen Hoffman wrote:
>>>>> On 2021-06-24 00:50:32 +0000, Dave Froble said:
>>>>>
>>>>>> Apparently I'm getting an itanic on Friday.  Do I have to use iLO and
>>>>>> such, or, can I ignore tham?
>>>>>
>>>>> That's your call.
>>>>>
>>>>> Around here, I'd want to configure and connect the iLO to the network,
>>>>> yes. With any Integrity server. Regardless of the intended usage of
>>>>> the
>>>>> Integrity server.
>>>>>
>>>>> If this Integrity server includes graphics hardware and a graphics
>>>>> display (that via separate controller, or via the iLO), that'll likely
>>>>> be the primary usage, and not the iLO network-connected serial
>>>>> console.
>>>>>
>>>>> If using this Integrity server as a remote server with interactive
>>>>> sessions—traditional timesharing, not graphics—then the iLO can be one
>>>>> of the various network connections, or can be ignored.
>>>>>
>>>>> For a development-only system, the iLO is akin to a backup. Handy to
>>>>> have when something goes wrong, also handy for upgrades and for
>>>>> restarting the host and for restarting the network stack, but probably
>>>>> not used heavily otherwise.
>>>>>
>>>>>
>>>>
>>>> I need to do some TCP/IP research and development.  The Alpha doesn't
>>>> get the latest stuff, and, I really need to be using the latest stuff.
>>>>
>>>> Didn't want the damn thing, but, I need to do the research.
>>>>
>>>
>>> Can't you get involved in the "Early Implementer" stuff with VSI
>>> and do your research on an X86-64 version?
>>>
>>> bill
>>>
>>
>> Not in the mood to do any testing of pre-release stuff.
>>
>> I need to develop a better method of handling lots of socket connect
>> requests.  I also need to see if my ideas will work Ok.
>
> How many are "lots of"?

That is sort of undefined at this time.  Historically, the usage has 
continued to rise.  Not sure what it could rise to.  So far we've seen 
maybe 20K per hour at times.

Doesn't really matter, what I'm looking at is how to do it as well as 
possible.  Then let the usage attempt to catch up.

>> Current thoughts are a single listener that validates requests,
>> accepts the connection, and passes it off to a worker process, then
>> drops it's own connection to the socket.  Involves some inter-process
>> communications.  Listener might get rather busy, but will spend little
>> time on each request.
>>
>
> How are the clients deigned? Calls from Javascript running in browsers?
> Are the clients your own applications too?

Clients use a protocol we've designed and implemented.  The source of 
connection requests doesn't matter.  Some are from VMS, others from 
various types of clients.

> For the usual HTTP (and everything related to that) based communication
> WASD will provide most of what you need out of the box. Have you yet
> looked at WASD? What you describe as your "current thoughts" above
> is just a description of how WASD works.

No, WASD will not satisfy our requirements.  It's not just accepting 
connections.  It is very specific apps that handle the requests.  One of 
the requirements is identifying the incoming request as valid as early 
as possible.  Failure at this point will immediately terminate the 
connection.

WASD is  a "jack of all trades" type of app, and does that reasonably 
well.  What we require is a specialist, for various reasons.

> The WASD server is very stable. Mostly starts at boot and runs until
> you reboot or shutdown. From our production box:
>
> $ sh sys/proc=ht*
> OpenVMS V8.4-2L2    25-JUN-2021 10:34:28.60   Uptime  802 17:00:25
>   Pid    Process Name  State  pri      I/O   CPU           Page flts  Pages
> 00000452 HTTPd:80      HIB    4   36199885   0 00:44:26.89 10693      661
> $
>
>
> $ sh proc/id=00000452/acc
>
> 25-JUN-2021 10:34:46.99   User: HTTP$SERVER  Process ID:   00000452
>                           Node: HV06         Process name: "HTTPd:80"
>
> Accounting information:
>  Buffered I/O count:  32823260  Peak working set size:      12464
>  Direct I/O count:     3376625  Peak virtual size:         216496
>  Page faults:            10693  Mounted volumes:                0
>  Images activated:          29
>  Elapsed CPU time:          0 00:44:26.89
>  Connect time:            802 18:40:12.00
>
> As you can see, it is the same "connect time" for the WASD server
> as the "Uptime" for thr system.
>
> $ write sys$output f$getsyi("boottime")
> 14-APR-2019 15:50:45.00
> $
>
>
> If I access one of our web addresses, I get a "worker process":
>
>
> $ sh sys/proc=ht*
> OpenVMS V8.4-2L2    6   25-JUN-2021 10:36:04.35   Uptime  802 17:02:00
>   Pid    Process Name  State Pri      I/O      CPU       Page flts Pages
> 00000452 HTTPd:80      HIB     4 36200066  0 00:44:26.91     10693   661
> 000BF940 HTTPd:80-590  HIB     2     5761  0 00:00:03.35      6313  3426 M
> $
>
> The worker process stays alive for a configured time so the next
> access is faster without any process startup. IF the worker process
> has an active session when the next request arrives, a secons process
> is started. All automatically handled by WASD.
>
> In this case, the worker process is running a Python script, but it could
> be any application writen in any language, of course. Probably with a
> C-wrapper for the WASD CGI APIs.
>
> I do not understand why anyone would prefer to write all this from scratch.

One size does not fit all.

And, it is the sort of thing I enjoy doing.  What we're doing now is 
sort of butt ugly, at least I think so, but it is so far getting the job 
done.  Though we've had to do some tweeking to handle increasing 
activity.  I'm looking to do better, and hopefully to be able to handle 
many more connection requests.  For our customers, it seems that 
internet communications is replacing most of the previous activity.


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486