[Info-vax] Integrity iLO Configuration?

[chris]

On 06/25/21 14:12, Dave Froble wrote:
> 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.
>
>
Don't know about vms, but if you are running inetd, that multiplexes
requests and spawns a new thread for that request and port number. A
bit of added code to limit number of requests, with any excess just
dropped...

Chris