none
Exchange 2010 DAG由两台MBX服务器扩充为三台, 有什么需要注意的? RRS feed

  • 问题

  • Exchange 2010 DAG由两台MBX服务器扩充为三台, 有什么需要注意的? 是否还需要见证服务器等等.
    2015年9月28日 2:01

答案

  • 你好,

    “错误: ArgumentNotValid: 无效的角色、角色服务”
     

    一般来说,当用户在命令行中提供了不存在的参数或省略了指定参数的必需部分时,将出现此消息。请确保第三台服务器有正确安装邮箱角色,并且在添加第三台MBX服务器到当前的DAG时,输入无误。

    另外,奇数个成员的DAG是不需要见证服务器的,只有偶数个成员的DAG才需要见证服务器,具体建议你参考下面的文章:

    数据库可用性组仲裁模式

    管理数据库可用性组成员身份

    谢谢!


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Niko Cheng
    TechNet Community Support

    2015年9月29日 6:32
    版主

全部回复


  • 具体一些场景描述可以参考

    http://www.shudnow.net/2011/08/12/exchange-2010-site-resilient-dags-and-majority-node-set-clustering-part-2/

    Real World Examples

    In Part 1, I showed a Real World example when you have one Exchange DAG member in the Primary Site and one Exchange DAG member in the Failover Site.  In this Part, I am showing a Real World example when you have two Exchange DAG members in the Primary Site and one Exchange DAG member in the Failover Site.

    3 Node DAG  (Two in Primary and One in Failover)

    In the following screenshot, we have 3 Servers.  Two are Exchange 2010 Multi-Role Servers; one in the Primary Site and one on the Failover Site.  The Cluster Service is running on all three Exchange Multi-Role Servers.  More specifically, it would run on the Exchange 2010 Servers that have the Mailbox Server Role. When Exchange 2010 utilizes an even number of Nodes, it utilizes Node Majority with File Share Witness.  Because we have an odd number of Nodes, we are utilizing Node Majority and will not utilize a File Share Witness.

    So now we have our three Servers; all three of them being Exchange.  This means we have three voters and do not need a File Share Witness as we have a third node.  So the question is, how many voters/servers/cluster objects can I lose?  Well if you read the section on Majority Node Set (which you have to understand), you know the formula is (number of nodes /2) + 1.  This means we have (3 Exchange Servers / 2) rounded down = 1 + 1 = 2.  This means that 2 cluster objects must always be online for your Exchange Cluster to remain operational just like if we were utilizing 2 DAG members with a File Share Witness.

    But now let’s say one of your Exchange Servers go offline.  Well, you still have at least two cluster objects online.  This means your cluster will be still be operational.  If all users/services were utilizing the Primary Site, then everything continues to remain completely operational.  If you were sending SMTP to the Failover Site or users were for some reason connecting to the Failover Site, they will need to be pointed to the Exchange Server in the Primary Site.

    But what happens if you lose a second node? Well, based on the formula above we need to ensure we have 2 cluster objects operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Primary Site and specify a new Alternative File Share Witness Server that exists in the Primary Site so you can active the Exchange 2010 Server in the Primary Site.  The DAG won’t actively use the File Share Witness but you should specify it anyways because part of the Failback process is re-adding the Primary Site Servers back to the DAG once they become operational. And once you re-add the second DAG node, you now have two DAG members in the DAG which will want to switch the DAG Cluster into a Node Majority with File Share Witness which is why you need to still specify a File Share Witness.

    But what happens if you lose two nodes in the Primary Site? Well, based on the formula above we need to ensure we have 2 cluster objects operational at all times.  At this time, the entire cluster goes offline.  You need to go through steps provided in the site switchover process but in this case, you would be activating the Failover Site and specify a new Alternative File Share Witness Server that exists (or will exist) in the Failover Site so you can activate the Exchange 2010 Server in the Primary Site.   The DAG won’t actively use the File Share Witness but you should specify it anyways because part of the Failback process is re-adding the Primary Site Servers back to the DAG once they become operational.

    Once the Datacenter Switchover has occurred, you will be in a state that looks as such.  An Alternate File Share Witness is not for redundancy for your 2010 FSW that was in your Primary Site.  It’s used only during a Datacenter Switchover which is a manual process.

    Once your Primary Site becomes operational, you will re-add the Primary DAG Server to the existing DAG which will still be using the 2010 Alternate FSW Server in the Failover Site and you will now be switched into a Node Majority with File Share Witness Cluster instead of just Node Majority.  Remember I said with an odd number of DAG Servers, you will be in Majority Node Witness and with an even number, the Cluster will automatically switch itself to Node Majority with File Share Witness?  You will now be in a state that looks as such.

    Part of the Failback Process would be to switch to a FSW Server in the Primary Site.  Once done, you will be back into your original operational state.

    Now the final step of the Failback Process would be to re-add your final remaining DAG Member in the Primary Site.  Once done, your cluster will switch back into a Node Majority Cluster and will no longer be utilizing the FSW.

    As you can see with how this works, the question that may arise is where to put your the majority of your Exchange DAG Members?  Well, it should be in the Primary Site with the most users or the site that has the most important users.  With that in mind, I bet another question arises?  Well, why with the most users or the most important users?  Because some environments may want to use the above with an Active/Active Model instead of an Active/Passive.  Some databases may be activated in both sites.  But, with that, if the WAN link goes down, the Exchange 2010 Server in the Failover Site loses quorum since it can’t contact at least 1 other cluster object.  Again, you must have two cluster objects online.  This also means that each cluster object must be able to see one other cluster object.  Because of that, the Exchange 2010 Server will go completely offline.

    To survive this, you really must use 2 different DAGs.  One DAG where the majority of your Exchange 2010 DAG Members is in the First Site and a second DAG where the majority of the Exchange 2010 DAG Members is in the Second Site.  Users that live in the First Active Site would primarily be using the Exchange 2010 DAG Members in the First Active Site.  Users that live in the Second Active Site would primarily be using the Exchange 2010 DAG Members in the Second Active Site. This way, if anything happens with the WAN link, users in the First Active Site would still be operational as the majority of its Exchange 2010 DAG Members for their DAG is in the First Active Site and DAG 1 would maintain Qourum.  Users in the Second Active Site would still be operational as the majority of its Exchange 2010 DAG Members for their DAG is in the Second Active Site and DAG 2 would maintain Quorum.

    Note: This would require twice the amount of servers since a DAG Member cannot be a part of more than one DAG.  As shown below, each visual representation below of a 2010 HUB/CAS/MBX is a separate server.

    The Multi-DAG Model would look like this.


    • 已编辑 yyycx 2015年9月29日 20:21
    2015年9月28日 20:09
  • Thanks yyycx, 但操作过程中出现如下错误:(已检查没有在第三台机上安装故障群集功能, 所有服务器上均无防病毒软件)

    因为遇到错误,操作未成功。可在日志文件"C:\ExchangeSetupLogs\DagTasks\dagtask_2015-09-28_08-43-45.637_add-databaseavaila
    biltygroupserver.log"中找到更多详细信息。
    服务器端数据库可用性组管理操作失败。错误: 无法添加或删除故障转移群集功能。错误: ArgumentNotValid: 无效的角色、角色服务
    或功能:“Failover-Clustering”。找不到该名称。
     [服务器: SZ-TEST-MBX03.test.pvmcn.com]
        + CategoryInfo          : InvalidArgument: (:) [Add-DatabaseAvailabilityGroupServer],DagTaskComponen...anagerPSFai
        lure
        + FullyQualifiedErrorId : 636B578D,Microsoft.Exchange.Management.SystemConfigurationTasks.AddDatabaseAvailabilityG
       roupServer
        + PSComputerName        : sz-test-mbx02.test.pvmcn.com

    2015年9月29日 1:12
  • 你好,

    “错误: ArgumentNotValid: 无效的角色、角色服务”
     

    一般来说,当用户在命令行中提供了不存在的参数或省略了指定参数的必需部分时,将出现此消息。请确保第三台服务器有正确安装邮箱角色,并且在添加第三台MBX服务器到当前的DAG时,输入无误。

    另外,奇数个成员的DAG是不需要见证服务器的,只有偶数个成员的DAG才需要见证服务器,具体建议你参考下面的文章:

    数据库可用性组仲裁模式

    管理数据库可用性组成员身份

    谢谢!


    Please remember to mark the replies as answers if they help, and unmark the answers if they provide no help. If you have feedback for TechNet Support, contact tnmff@microsoft.com.

    Niko Cheng
    TechNet Community Support

    2015年9月29日 6:32
    版主
  • 谢谢两位的热心帮助!
    另"错误: 无法添加或删除故障转移群集功能" 已找到原因, 乃是因为MBX03的Windows版本是2008 R2标准版, 所以无法安装故障转移群集功能, 切换为企业版之后问题已解决.
    2015年9月29日 7:22