对SharePoint 2010的job failover的一些比较深入的说明
要点如下:
1. 某台机器上的某个SharePoint Service在停掉的时候, 与这个Service对应的timer job的fail over特性, SharePoint是没有提供的.
2. SharePoint提供的是在本来运行着某个job的服务器当机(挂掉), 关机, 或者简单地owstimer.exe服务崩溃的时候的failover.
3. 在管理员在管理中心站点点击"Run Now"的时候, failover并不会立即发生的. 过一两天之后, 管理员如果点击"Run Now"的话, 他会发现这个job会在第二台服务器上开始运行.
场景一
===============
当运行着某个job的服务器挂了, 或者你需要重启这台服务器, 再或者由于某种原因你需要重启OWSTimer.exe服务的时候, 如果你想要failover立即发生, 那么你需要重启原来运行着该job的服务器的timer service(即owstimer.exe), 还要重启那台你希望用它来继续运行该job的服务器上的timer service.
如果你不想failover立即生效的话, 你可以不去管它. 最终, 这个job会自动地failover到其他可以运行这个job的服务器上去. Failover发生的频率默认情况下为一个小时一个job发生一次. 所以, 如果一台机器挂了, 那么这台机器上运行着的所有的job会需要一段时间才能全部完成failover. 在SharePoint 2010的服务器场中有个默认的timer service recycle job, 它每天运行一次来重启每台机器上的timer service. 所以, 如果要所有的job 自动地failover的话, 管理员至多等待一天就够了.
场景二
===============
基于管理需要或其他的什么原因, 你需要停止SharePoint的某个服务, 而这个服务有个对应的job. 如果这次停掉服务是临时的, 短期的, 管理员可以不去管什么job failover的事情. 当你再一次地启动这项SharePoint Service的时候, timer service会让这台机器在下一个schedule的时候继续运行该job的.
如果该服务的shutdown是长久的, 并且job failover需要立刻发生, 那么管理员需要重启两台服务器上的timer job service.
如果该服务的shutdown是长久的, 然而job failover并不需要, 管理员大可不必去理会它. 正如刚才提到的, 有那么一个定时作业的重启(scheduled job), 会每天发生一次的. 经过一天以后, timer service会重启, 你会发现job已经在新服务器上开始运行了.
关于SharePoint Timer Job的锁机制的简介
================
Timer Job的lock机制比较复杂. 下面的对象参与其中并扮演主要角色:
1. Config DB中的TimerLocks表 - 该表为每个有某种类型的lock的timer job保存一条记录(http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.spjobdefinition.locktype.aspx). 该记录指示着哪台服务器拥有着某个job的锁, 即该job仅能运行在这台服务器上.
2. LockTimeout: 如果一段时间内, 某个lock的记录没刷新, 那么这个lock就会被认为出了问题. 其他的服务器就可以要求拿到这个锁, 从而让这个job在这台新机器上运行. 这个时间段就是由LockTimeout来指定的. 默认情况下, 该值为20分钟.
3. 名为LockRefresh 的timer job: 这是一个SharePoint 2010内部的一个job, 它会定期检查某台服务器所拥有的所有的locks, 确保所有的这些locks都会得到刷新(这里所说的刷新指的是更新TimerLocks表中的时间戳). 默认情况下, 这个所谓的定期的值是15分钟.
4. 名为Sweep 的timer job: 这是一个内部的job, 它会定期检查那些某台服务器所没拥有的locks, 看看该服务器是否可以拿过这个锁, 即查看自己是否可以拥有这个锁. 查看的方式是看这个这个lock的有没有在LockTimeout之后依然没有刷新过. 如果没有刷新过的话, 该job就回去要求运行着它的服务器去拿这个锁. 这个job是每小时运行一次的.
在SharePoint 2010场中的每台机器上都运行着OWSTIMER.EXE服务器, 不管这些服务器的角色是怎样的, 在OWSTIMER.EXE服务中都有一个LockRefresh和一个Sweep作业的实例. OWSTIMER.EXE中还包含其他以它为宿主的运行中的job和services. LockRefresh和Sweep作业的实例之所以存在, 是为了一个目的: 刷新自己已经有了的锁和请求拿到自己没有拿到的锁. LockRefresh 着眼在自己已经拥有了的锁, 并刷新它们. Sweep着眼在该服务器还没有拥有的锁, 并尝试去得到这些所的所有权.
当schedule的时间到了的时候, 所有可以运行这项作业的服务器都试图去运行它. 实际上, 这总有个顺序问题. 基本上第一个访问TimerLock表的服务器会在该表上创建一个lock. 一旦lock被创建了出来之后, 它就会阻止其他的服务器来运行这项作业. 因为在运行一项作业之前, 必须先拿到该作业相关联的lock.
由于OWSTIMER.EXE中的LockRefresh每15分钟运行一次, 所以只要OWSTIMER.EXE还在正常运行, 它就会在锁被别人能拿到之前先刷新这个锁(因为timeout的时间是20分钟, 而该刷新的job每15分钟运行一次). 这样其他的服务器就拿不到这个锁, 也就无法运行这个job了.
只有在之前拥有了所的服务器上的OWSTIMER.EXE挂了(或者服务器挂了)的时候才可以拿到lock. 因为这时候, 那台服务器上的LockRefresh job不会运行, 也就无法刷新它所拥有的锁, 于是锁的状态就会变为"可获取". 其他服务器上的Sweep job会正常运行, 并且看到某些锁可以获取, 之后它们就会试图更新锁的信息来获取锁的拥有权. 一旦这发生了之后, 这台新的拥有了锁的服务器会继续运行这个job. 值得注意的是, Sweep job每次只会拿一个lock. 因为这样众服务器间对于锁的竞争会比较温和. 很可能第一台服务器当时很忙, 或者基于管理目的进行了一次重启, 因为它错过了一次对所有锁的刷新而拿走它所拥有的全部的job会显得有点过激. 这样比较公平, 如果第一个服务器赶上来刷新了锁, 它就还可以继续运行它还拥有锁的那些job.
简言之, 在某台服务器上单纯地停掉某个SharePoint Service并不会引发与该service关联的job的failover. 因为这并不会修改Config DB中的锁信息. 如果要failover的话, 至少需要重启服务器上的timer service, 或者重启服务器, 这样锁的获取和释放才会从头开始.
如果有需要的话, LockTimeout的值, LockRefresh 和 Sweep的间隔时间都是可以修改的. 它们都是SPTimerService的属性. 它们可以通过PowerShell或编码方式修改, 但是这种修改并不被推荐. 具体请参考http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.administration.sptimerservice_properties.aspx
