nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

OpenDeploy bahavior when targeting 2 servers

NathansDIS

Hello All-

We have a deployment that is targeting 2 OD receiver servers. For reasons I don't want to go into here, we are setting the transactional attribute for this deployment to 'no'. We are using TS 6.1, OD 6.0 on Windows 2000. I am wondering what happens to this deployment in the case of a failure?

If a rcvr was not running on one of the target servers when the deploy starts, would the deployment fail to both servers or would one server get the entire deployment, while the other would fail?

If a rcvr crashed halfway through the deploy, would the other rcvr get the rest of the deployment (possibly leaving the servers with different content) or would both servers end up with the same set of files. Since these servers are both cluster masters in a load balanced environment, I am very interested in knowing how OD handles a deploy failure when you are targeting more than 1 server. Let me know if you need any additional info. Thanks in advance for any comments, insights, suggestions, etc.

Regards,

Nathan
Washington State DIS
~~~

Find more posts tagged with

Comments

Adam Stoller

I believe, and I'm sure someone will correct me if I'm wrong, that if you are doing this non-transactionally that the down-server will not cause the up-server's deployment to stop nor rollback - but the overall return value from the launching of the deployment will indicate something along the lines of "succeeded with errors". The net result is that one of your targets will have been updated and the other one will not have been updated.

In the scenario where one server goes down in the midst of the deployment - any files which were successfully deployed will remain deployed - thus leaving an inconsistant state on that one server (a new source/target comparison or filelist) deployment should be executed as soon as that server is brought back up to get it synchronized.

If you were running it transactionally - then in the first scenario (one server down to begin with) the deployment would fail for both targets, in the second scenario the up-server's content would be rolled back and the down-server's content would probably be unchanged but there would be temporary files sitting around from the incompleted deployment.

--fish
Senior Consultant, Quotient Inc.
http://www.quotient-inc.com

Migrateduser

Fyi, if you want to ensure that each target gets "all or nothing" without one failed target causing the other to roll back, you can use a transactional deployment with a quorum value of 1.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

NathansDIS

Thanks for the input guys. Unfortunately, our transactional deployment fails because it is a deployment to a IIS/.NET web application. When the OD rcvr tries to rename the folder that is the root of the .NET application, The OD rcvr logs an error (errno=5) and unceremoniously crashes, leaving the website in a foobar state.

I opened a case with support and they reported that increasing the timeout interval and count in the deployment configuration might help the issue, but it has not. Their only solution was to deploy to another location or to stop IIS for the deploy, both of which are suggestions that don't fit our business need for this website or my definition of a 'solution' or working OD feature.

My question to them was, it appears that OD 6.0 isn't supported (or doesn't work) with IIS/.NET application servers. Is this the case? I don't mind so much if the deployment fails (I get an email notification so I can fix it) as long as both servers end up with the same files and/or the website still functions after the failed deploy. Any input, suggestions, etc appreciated.

Regards,

Nathan

NathansDIS

Todd- In case you are wondering, the support case ID is Case: 1210755. Maybe this should be directed to an OD guru for resolution?

Thx, nathan

Migrateduser

OD has the svrTryCount / svrTryInterval attributes to address the file locking situation sometimes caused by IIS. The assumption is that IIS will eventually release the locks. So by tuning those attributes it should be possible for OD to continue retrying updating the locked file until the lock is released.

If a file cannot be updated due to the svrTryCount being exhausted, then the transactional deployment should fail gracefully (i.e., rollback.) If non-transactional, the deployment should continue chugging along deploying subsequent files and finish with a "completed with errors" status.

You mentioned your deployment is failing with error 5. On Windows that is defined as ERROR_ACCESS_DENIED. So it would seem the problem doesn't have to do with locked files, but rather with the owner of the OD receiver service not having authority to update the failing file or directory.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

NathansDIS

Thanks for the update Todd. The OD service is running as SYSTEM. If i'm not mistaken, that account should be able to rename the directory is anything can. Do you recommend running OD under another account?

More importantly, have your OD QA/Engineering teams ever tested a transactional deployment to a folder that is the root of an IIS web and the root of a .NET web application? This might be an interesting exercise to shed some light on this situation. This is the scenario that is failing and crashing the OD rcvr (ungracefully, leaving many garbage files behind) on both target servers when trying to rename this IIS/.NET/ODTarget root directory.

Thx again for your time.

-Nathan

NathansDIS

In case it matters, I should have said the LocalSystem account, not SYSTEM. HTH, -nathan

Migrateduser

Running the service as another user is fine. People often do that to enable the receiver to update a mapped drive, for example. You just need to change the LogOn parms for the OD service.

The OD should not crash as a result of not being authorized to update a target directory. I'll ask tech support to reproduce the problem you are seeing so that engineering can determine where the problem is.

Todd Scallan
Director of Product Management
Interwoven
t: 408-530-7167
e: tscallan@interwoven.com

NathansDIS

Thanks Todd-

Please have your team recreating the issue contact me via support case 1210755 if they need any details on the configuration necessary to reproduce the issue.

-Nathan

CRB

has this issue ever be resolved?

we have been exepriecing the same problem every month or 3 weeks, deployment will failed because it couldnt rename a file... and yes the file is under wwwroot that IIS is running...
support said to increate the server tryout and intervals but still didnt work...

and we also cant disable IIS while deploying nor we can deploy to different location...

any info about this issue? is there anything i can change in the IIS to not lock the files for long time? or to make sure it unlocks a file properly?

---update---

i found this much about the IIS and locking files which causes other application not being able to update those files:
http://www.chami.com/html-kit/support/docs/pages/h000130.html

but i am still hoping some update from Opendeploy users on here Smiley Happy