Conversion service Architecture¶
A simple view of the architecture is as follows:
Clients will connect using a REST API to the conversion service URL endpoint, they would need to send a POST request with a set of parameters like the callback URL to send back the results. The web conversion server will assign the document depending on the type of conversion to any of the conversion server worker queues that can deal with the document. If there are more than one that can deal with it, a random algorithm will pick one up. Once the document has been processed it will be sent back to the client using HTTP(S) protocol.
Documents are stored on EOS, a EOS policy removes documents from the file system after latest 1 month. Having EOS as storage provides quite some flexibility in terms of which Operating System to use in order to run the converters.
Sum-up of actual deployment¶
| project | eos | endpoints |
|---|---|---|
| dev-doconverter | /eos/user/c/cdsconv | https://dev-doconverter.web.cern.ch |
| doconverter | /eos/project/d/doconverter | https://doconverter.web.cern.ch |
| Worker nodes |
|---|
| doconverter01 (to be retired, W2012R2 server) |
| doconverter02 (to be retired, W2012R2 server) |
| doconv01- test (to be retired, W2012R2 server) |
| doconverter03 (Windows 10) |
| doconverter04 (Windows 10) |
| doconv02-test (Windows 10) |
Live statistics at ES cluster (only admins)