How many Linux-clients updates can be triggered to run in parallel via a client-task?

[Guest Satoshi.S]

Hi there,

I and my IT vendor is planning to update ESET PROTECT from v8.1 to v10.1 (running on Windows server),

then to update 20 Linux-clients (v8.1.685.0 to v8.1.823.0) and their EMAs (v8.1.1223.0 to v10.0.2130.0) in a test environment,

then to update 40 Linux-clients and EMAs (the same version) in a production environment within THREE HOUR maintenance time.

<Questions>

Can we trigger to update 40 Linux-EMAs in a client-task at once, then 40 Linux-clients in another client-task at once?

Or should we divide 40 Linux into serveral groups to be triggered through several client-tasks, in order to avoid ESET PROTECT manager's over-workload?

Finally can we expect to run the updates of EMAs then clients for 40 Linux servers in three hours?

<System Enviroment>

ESET PROTECT manager's spec:  Xeon E5-2690v4 (2.66GHz) two CPU-cores (HT-disabled) on VMware,  1GbE to the Linux-clients (RHEL7.x).

<File size of Linux-EMA and Linux-clients>

Agent-Linux-x86_64.sh  is  48MB size.

efs.x86_64.bin  is  16MB size.

(NW bandwidth of 1GbE may be the bottleneck for the above updates.  I'd like to hear your experiences of many clients updates thru client-tasks.)

Thank you very much in advance. 

Satoshi.S

[Marcos 5,189]

40 machines are not many, you could upgrade them at once. However, if you want to lower the load on a proxy or the Internet connection, you can set up a random delay in the task trigger setup:

[Guest Satoshi.S]

Marcos,

thank you for your prompt answer with the suggestion of the random delay in a task trigger for slow networks.

I should have said that my Linux clients are sitting in the same 1GbE LAN as the ESET PROTECT manager,

so it sounds I don't need to be nervous about those numbers of clients to be updated in a task at once.

I try 20 clients updates in a task in the test environment and monitor how long it would take and consume the manager's resource, then apply the similar task on the production environment later.

Thanks,  Satoshi.S

[Guest Satoshi.S]

Dear Marcos,

I need your help again in this regard, to distribute 40-Linux servers' ESET EMAs and clients updates workloads in one client-task, hopefully for 40 minutes or so.

My vendor tried in our test environment, 20-Linux servers' ESET EMAs and clients updates in a client-task with the "Random Delay Interval" of 10 seconds, expecting EMA updates for 20-Linux servers distributed for over 200 seconds for the file downloads and following their EMA updates by each of them for over a few minutes.

However the 20-Linuxs' EMAs updates looked like finished in two minutes,  first 10secs file downloads then 60-90secs executing the file to apply the updates in almost the same time.(*1)   So the "Random Delay Interval" of 10 seconds didn't look like working as expected for our test case.

Please take look the attached three screen shots to show our Trigger settings.
(sorry for the Japanese menu.  I try to translate the key words to English, but they may not be correct.
In the left pane, 4 options are "Basic", "Target", "Trigger", and "Details - Arrangement".  
The 4th words may not be correct.)

Scr1:  In Trigger,  we specified "Random Delay Interval"  10seconds.
Scr2:  In Details - Arrangement,  at Time based Conditions,
Scr3:  "Duration"  1 minute  (it was specified as Default.)
 

Here, is the "Duration" of 1 minute the key point?

I'm suspecting the Duration of 1min forced the client task to be executed in that time duration, even though the Random Delay Interval of 10secs specified for 20-Linux targets.   Should I specify it like 20 minutes or so?

(*1) Impact of 20-Linux servers' EMAs & clients updates almost at the same time:
the servers' OS disks are allocated in a VMware VMFS of single RAID6 6D+2P HDDs-array, and their EMAs and clients updates by their own at the same time overwhelmed the poor RAID array for about 2minutes with very slow I/O response time for the OS area.
I have to circumvent the situation for the production environment even in a maintenance time window.
(My concern of the workload for ESET Manager or its 1GbE LAN bandwidth were tiny)

Thank you again.

Scr1:  In Trigger,  we specified "Random Delay Interval"  10seconds.

Scr2:  In Details - Arrangement,  at Time based Conditions,

Scr3:  "Duration"  1 minute  (it was specified as Default.)

[Marcos 5,189]

Please raise a support ticket. The above is rather a complex question not intended for this Quick questions forum where guests can post without signing up.