Contact

Subscribe via Email

Subscribe via RSS/JSON

Categories

Creative Commons Attribution 4.0 International License
© Rakhesh Sasidharan

Elsewhere

TIL: The Exchange PAM can move to another node when the FSW reboots

Didn’t know this. The Exchange PAM (Primary Active Manager) can move to another node when the FSW (File Share Witness) reboots or is offline. There’s no impact, but it’s worth being aware o if you are wondering what could be affected when the FSW server is rebooted.

From this blog post (via this forum post where I found it):

When the File Share Witness host server becomes unavailable, the File Share Witness resource will still fail in cluster and cause the Cluster Core Resources to move between nodes. In this case assuming the File Share Witness host server is still not available, the resource remains in a failed state. If it becomes necessary to utilize the File Share Witness to maintain Quorum, and the witness resource is in a failed state, cluster will attempt to online the witness resource. If the online is successful the witness share is alive and accessible – quorum is maintained. If the online is not successful, the witness share is not alive and accessible – a lost quorum condition is encountered.

Brief background on PAM (via this blog post):

At any given time, in every database availability group (DAG), there is one member that is responsible for the coordination of database actions across the DAG. This member is known as the Primary Active Manager (PAM). The current PAM can be determined by using Get-DatabaseAvailabilityGroup –Status. The cluster group may contain several cluster resources. The PAM does not depend on the state of any of the resources in this group, and the PAM role will always be assigned to the node that owns the Cluster Group. The Cluster Group can be moved between members using the cluster management tools.

Each DAG member that does not own the Cluster Group is a Standby Active Manager (SAM). When the Cluster Group is moved between nodes, a notification process detects that the Cluster Group owner has changed. This triggers detection logic to determine the new PAM. 

Automatic arbitration may occur for a number of reasons including: 

  • The failure of a member
  • The failure of a resource contained within the Cluster Group

In most cases, Exchange administrators should not be concerned with the owner of the Cluster Group or the node designated as the PAM.  This is true even for DAGs that span multiple sites where the PAM may be a node in a distant datacenter.

Some more details regarding PAM  (via this blog post):

Active manager is a role that runs on a mailbox server. A single active manager role “Standalone Active Manager” which runs on a mailbox server that has no high-availability configured. Two active manager roles will be in use when the mailbox server is a member of a DAG; Primary Active Manager (PAM) and Standby Active Manager (SAM). 

PAM is the Active Manager in a DAG that decides which database copies will be active and passive. PAM is responsible for getting topology change notifications and reacting to server failures. 

SAM provides information on which server hosts the active copy of a mailbox database to other components of Exchange that are running an Active Manager client component (for example, RPC Client Access service or Hub Transport server). The SAM detects failures of local databases and the local Information Store. It reacts to failures by asking the PAM to initiate a failover. A SAM does not determine the target of failover, nor does it update a database’s location state in the PAM. SAM runs on all mailbox servers in a DAG except on the one where PAM is running.

TIL: The Exchange PAM can move to another node when the FSW reboots by rakhesh is licensed under a Creative Commons Attribution 4.0 International License.