BO 4.1 recover after FileShare disconnect

[tomas_lindberg]

Hi,

Is there any easy way to restart a single server in BO and schedule this somehow?

Our Clustered Fileshare environment which is used for the Input and Output File Repository is patched from time to time and it seems that the BO environment can't recover after this, but that the IN/OUT FRS is "running with errors" after this.

Is there anyway to have BO recover after that the FRS's have been disconnected for awhile, or would it be possible as an "approved" workaround to restart these servers somehow after that the FileRepository is back online?

Ive seen the possibility to perhaps restart the filserver.exe file but it seems a bit brute.

Best regards

Tomas

[Former Member · Accepted solution]

Is there any easy way to restart a single server in BO and schedule this somehow?

I don't know whether there is an easy way or hard way to perform a restart of BO.   You might be talking of entire server OS or else the SIA node of BO. In both context a script can be created to stop / start programs. Your OS System Administrators would be aware of how to create such programs to restart a server by schedules

Our Clustered Fileshare environment which is used for the Input and Output File Repository is patched from time to time and it seems that the BO environment can't recover after this, but that the IN/OUT FRS is "running with errors" after this.

Is there anyway to have BO recover after that the FRS's have been disconnected for awhile, or would it be possible as an "approved" workaround to restart these servers somehow after that the FileRepository is back online?

This question is not quite clear for me. I believe you go for upgrading only the file shared location; post which you start getting some errors. BO should be able to recover (i.e., must be connecting to the server post the upgrade and making the I/O FRS online) At times you would find errors such as you mentioned a manual server restart should not impact in any manner I believe, as it would help in releasing and creating new sessions.

I hope that is was what you were looking for. If not please rephrase your query.

Ive seen the possibility to perhaps restart the filserver.exe file but it seems a bit brute.

What is so brute about it? Or why do you believe that fileserver.exe should not be restarted. It can be restarted at al times. Ensure that all activties (processing / scheduling) are paused / stopped while going for a CMC, I/O FRS restart.(Helps in releasing memory and helps avail the memory while the servers are being started )

[tomas_lindberg · Accepted solution]

Thanks,

With a restart in this case i was refering to the actual servers for InputFileRepository and OutputFileRepository. It seems that the BO server was restarted at the same time as the FileRepository Cluster was restarted, but the BO server went online earlier than the FileRepository causing the Running with errors issue. I was hoping that the FRS server would be able to recover automatically when the FileShare was available again, but this is not the case.

I will try to schedule a restart of the actual server by restarting fileserver.exe at a later state than the restart of theFileShare  Cluster.

[jens_grotholtmann]

Well, first of all, you should use the RDT to clean up your CMS-Database and resync it with your FRS.

Next question: why don't you stop your FRS bevor maintining the fileserver? This would avoid getting in trouble ...

Btw. the real question is, why has your FRS to be down? If its for backup, use the Hot Backup Option and you'll be fine.

[tomas_lindberg]

Thanks for your input.

FileSHare is down for patching purposes on an agreed time, and during this time also BO is down, but the problem is to syncronize the start of the different hosts etc. I would say that this is unrelated to RDT.

We could of course stop FRS before mainting the FileShare, and I will investigate this, but the patching process includes several hundreds of hosts so I need to check how to control this in the best way.

P.S our FS for FRS is not located in the default location but moved to a clustered environment.