AVFS installation with Job Processor

[jparks_79]

Hello Everyone,

Couldn't find any posts that answered this question...

We are looking at deploying AVFS at one of our sites to replace a full replicated location. I am curious how the JOB processing works with AVFS. Will jobs still get qued on the AVFS server, or will they get picked up at the ADMS site?

Thanks for the help.

[paul.gunn · Accepted solution]

Hi,

The jobs would be queued for the AVFS server.

Paul

[cbolton]

We have a Vault 2015 infrastructure and I was searching for the answer to this question. I have several Vault file servers scattered around the network and they have the issue of users kicking off Job Processor jobs but then Job Processors never pick them up. The Job Processors are paired to the ADMS servers and not the VFS servers. If a user logs into the ADMS via the client and takes ownership of the jobs they still run on the job processors but without the take ownership they just hang out there and never get sent to the Job Processor. From Paul's response this appears to be the way things work but that makes little sense to me since the jobs are central administration and not file server related processes. If I have to have job processors for all my VFS servers that will significantly balloon my entire system. As it is I have two VFS servers at each remote site so I can host databases from the two primary ADMS servers. There are two job processors for the ADMS servers so this would effectively mean I would need four Job Processors at each remote site. Tell me I am wrong and that there is a better way.

[Neil_Cross]

Yea, it sucks.

Other than theoretical convenience related issues, I have no idea why it has to be like this without giving users the option to make the choice.  

One such issue could be that for example if someone at an AVFS site checks in 2GB of Inventor data and then submits a job for a DWF/PDF publish.  If the one and only JP is logged into the main ADMS situated 5000 miles away, in order for the JP to publish that DWF/PDF it would need to transfer that 2GB of CAD data to JP machine which could take hours or days depending on line quality, the JP would be stuck on that job causing a massive backlog for other jobs at the ADMS site.  But then what if your AVFS is 1 mile up the road from the ADMS like mine is... 

Yah you can have more than 1 JP per site, but that's not recommended due to issues with job ordering for sequentially generated jobs on lifecycle state change.

The other option is to look at Q-Tools from Doug Redmond, a custom app which creates a centralised job queue at 1 site, it forwards all jobs from all sites to a single JP.  However, for some reason Doug stopped developing that at Vault 2014 but the source code is available for anyone who wants to maintain it for themselves.

[cbolton]

Thanks Neil, I will definitely check out Q Tools. It isn't really feasible for us to implement all the extra hardware to support job processors where we have the AVFS servers. It was enough just to get these AVFS servers deployed.

[paul.gunn]

Hi,

I believe the original intention was to avoid a lot of file replication. e.g. if you check-in a design file on one site then file replication would be needed to do DWF generation at a different site. By having the job associated with the originating site, it is not necessary to do any file replication.

That said, I do understand your concerns about maintaining a lot of job processor machines - especially on lightly utilized AVFS environments. A couple thoughts on this:

(1) Short-term, you don't necessarily have to run job processor on standalone machines. It is always an option to run the job processor on the end-user machines - especially in cases where the AVFS is lightly used.

(2) Long-term, it sounds like Vault should have more options around this behavior to cater to different customer needs. I would recommend adding an Idea Station request about this for consideration in future releases.

Paul

[cbolton]

Paul,

    The challenge we face with the Job Processors is that we are also using CoolOrange to process custom scripts and so multiplying Job Processors regardless of whether they are run from existing machines or not, means that we would have to purchase many more licenses for CoolOrange and also manage a lot more software. We are trying to keep the system as focused and streamlined as possible. I suppose I could change the direction of the conversation and ask about improved performance for the system.

    We have good bandwidth between sites but we see a significant performance hit when users at remote sites attempt to check in/out documents. I have observed that this seems to be caused by the IIS application pool process that handles the transactions. When users who are local to a ADMS server check in/out files the CPU processes stay low on the ADMS server but the same transaction from a remote site seems to kick the CPU into overdrive and this seems to be because of the IIS application pool. Why does this behavior happen? If I could get the same kind of performance without AVFS I would much rather do without the added complexity (and Job Processor problems).

Thanks,

Chris 

[paul.gunn]

Hi Chris,

I don't have any good explanation for your observations around CPU usage with remote users. This isn't something I have seen - and cannot think of any obvious explanation for why that might be the case. I would expect performance of remote users to be slower (due to reduced bandwidth + higher latency), but this would normally impact factors like memory and I/O rather than CPU. I assume other aspects like whether the clients are using SSL are the same? I wish I could give you an explanation or suggestion on this but it isn't something I have encountered before.

Paul

[cbolton]

I am also looking for a solution to this challenge. We have two primary ADMS servers with up to six vault databases on each. The two ADMS servers are not setup to sync SQL and the reason for this is that we need to have high availability and each of the primary servers are on a different physical site. The purpose for all the databases is to keep the business units and client data very isolated. We have a growing number of remote sites (13 as of the time of this writing with more expected) and so we have setup AVFS servers to replicate and house data and improve network speeds. As with other posts before mine, we also heavily use CoolOrange during the course of job setup, notification, transmittal and more. Users who logon to AVFS servers to interact with Vault data have no issue with normal check-in/check-out but if they kick off any process that would require a Job Processor the job stalls and can only be completed if the user logs onto the ADMS server directly. As a result we have most users just logging into the ADMS servers all the time but that isn't desirable as it doesn't take best advantage of network architecture.

My primary question is why does a Job Processor have to be separate from the AVFS server? If each AVFS server could also run it's own Job Processor that would make setting up the system a lot easier. I had previously read about Q-Tools and the possibility of job forwarding but that wouldn't always make good use of the network either as this still requires a considerable amount of cross site traffic rather than keeping the AVFS and Job Processor together. What I am trying to avoid is having to setup 4 job processors at each site (a cool orange JP and a 3rd part app JP for each primary site server - AVFS can only be paired to a single ADMS).

There has got to be a better way!!!!

[paul.gunn]

Hi Chris,

Did you ever log an Idea Station on this? That would be the best way to get this on product management's radar. I agree that it would be good to have such an option (to associate jobs with the AVFS), but this has greatest weight as a customer-initiated Idea Station request.

Paul