「深入 Exchange 2013」06 命名空间
在前面的章节中，你可能会注意到“命名空间”这样一个词，会联想到C#语言或是XML文档里的那个命名空间的概念。但是在这里它的意思更偏向于URL或者FQDN，比如一个Exchange 2010的RPC Client Access Array客户端访问阵列可能有这样一个命名空间叫mail.contoso.com，而属于OWA的命名空间是owa.contoso.com，在Exchange 2013里，命名空间的设计规划过程变得不那么复杂。我们来看
使用单一命名空间：
最简单也是最常用的做法就是为除了autodiscover之外的所有服务使用单一命名空间，这就要求你在内部和外部DNS都做好该条命名空间的解析；保证内部用户与外部用户都能解析到正确的地址。
并且如果是单一命名空间应用在Outlook Anywhere上（即你的Outlook Anywhere内部和外部都采用mail.contoso.com连接），你的内部和外部的验证防范必须一样。且看下文分析，在前一章已经提过了，Outlook会优先尝试内部URL，但是当前条件下，你内部和外部使用同一URL，导致Outlook认为自己是在内部网络环境，于是它就采用了内部的验证方法。
为每个服务分配一个命名空间？
在前面的负载均衡章节我们就讨论过这种做法，为每一个服务分配一个命名空间（一般都是配置其外部地址），比如owa.contoso.com,eas.contoso.com,ews.contoso.com。（注意Exchange管理中心的URL和OWA的URL往往是联动的。）这样的优势前面也提到过，一个四层的负载均衡设备就可以针对每一个服务的运行情况进行监控了，节省成本。劣势就是，多一个设置就多一个故障点，同时也增加了用户使用的复杂度，最后是证书，如果你用的是通配符公网证书，你又得额外往里增加一些成本，因为增加了可用域名嘛，同时Exchange上的证书也得加入这些额外的URL到subjectAlternativeName 使用者备用名称。
要达到这个目的，只需要使用Set-*VirtualDirectory系列命令在合适的服务器上对虚拟目录进行更改。类似下面：
Get-ActiveSyncVirtualDirectory | Set-ActiveSyncVirtualDirectory �CExternalURL activesync.contoso.com
为Outlook Anywhere配置单一内部命名
默认情况下，当你刚刚安装好了Exchange 2013之后，使用一个Get-OutlookAnywhere命令去查看默认的Outlook Anywhere配置时，会发现外部主机名是空的，而内部主机名则默认是CAS服务器的FQDN；大概是如下所示：
Get-ClientAccessServer | Get-OutlookAnywhere | select identity, *hostname Identity ExternalHostname InternalHostname -------- ---------------- ---------------- CAS01\Rpc (Default Web Site) CAS01.contoso.com CAS02\Rpc (Default Web Site) CAS02.contoso.com
那么试想一下，只要我搭好了一个负载均衡，有一个命名空间为mail.contoso.com，然后我将这两台CAS的Outlook Anywhere都配置成mail.contoso.com，是不是就可以在内部也进行负载均衡和故障转移了？配置的命令很简单
Get-OutlookAnywhere | Set-OutlookAnywhere -InternalHostname mail.contoso.com �CInternalClientsRequireSsl $true
这里要注意一下了，还记得我在前一章里提到过的嘛，内部用户使用Outlook Anywhere连接的时候，默认是走HTTP，也就是不需要SSL加密的。那么这里你可以使用-InternalClientsRequireSsl $True 来设置内部客户端的Outlook Anywhere也需要SSL加密。
为Outlook Anywhere配置外部命名
还是那句话，无论你选择啥命名，要确保他能正常被DNS解析。我见过对此严格要求的环境，内部和外部域名分开，内部使用outlook.contoso.com，外部使用mail.contoso.com。类似下面的结果：
Get-OutlookAnywhere | select identity, *hostname Identity ExternalHostname InternalHostname -------- ---------------- ---------------- CAS01\Rpc (Default Web Site) mail.contoso.com outlook.contoso.com CAS02\Rpc (Default Web Site) mail.contoso.com outlook.contoso.com
非绑定命名空间模型
所谓的Exchange 2013单一命名空间特性又是指啥呢？我们继续来看
2013中CAS只会代理客户端请求给拥有活动数据库副本的MBX服务器，这个代理的逻辑不再受Active Directory站点的限制，换句话说。在上海AD站点里的Exchange 2013的CAS，完全可以将请求代理给北京AD站点里的MBX。这样的话，就不再为每个数据中心分配一个命名，而可以采用一个统一的命名方法。
再加上Exchange 2013的CAS不再需要CAS Array，所以在一定程度上确实减少了命名空间的数量。
看下面这张图，我们再来梳理一下，先看左边绿色的站点里有两个数据中心，DAG1则是跨数据中心对的DAG，SiteA的用户无论连接到哪一个数据中心的CAS，都可以被代理到恰当的MBX上。
然后不要以为DAG就是边界了，如果我们使用了Geo-DNS之类的技术，那么处于不同地理位置的SiteB也不需要额外的命名空间，通过Geo-DNS将用户请求解析给SiteB的CAS，然后再代理给SiteA的DAG里的MBX。
这种场景的后果就是，每个数据中心里有50%的流量是从其他的数据中心代理过来的（你问两个数据中心是怎么用同一个命名空间的？DNS轮询嘛……）
![clip_image002[1]](http://s3.51cto.com/wyfs02/M01/6F/0E/wKiom1WQudvhSQsIAAFWKQYWwr0650.jpg "clip_image002[1]")
官方文档是这样描述的：https://technet.microsoft.com/zh-cn/library/dd638137(v=exchg.150).aspx#Site
“Exchange 2013 中的更改之一是使客户端可以获得多个可访问的位置。假设客户端能够使用多个可访问的位置（Exchange 2013 中的几乎所有客户端访问协议都基于 HTTP（示例包括 Outlook、Outlook 无处不在、EAS、EWS、OWA、EAC 等），并且所有受支持的 HTTP 客户端都能够使用多个 IP 地址），因而可在客户端提供故障转移。可以配置 DNS 以在名称解析过程中将多个 IP 地址传递给客户端。例如，客户端会请求 mail.contoso.com 并取回两个 IP 地址（或四个 IP 地址）。不过，客户端可以可靠地使用客户端取回的许多 IP 地址。这使客户端的情况可显著好转，因为如果某个 IP 地址失败，则客户端可以尝试连接一个或多个其他地址。如果客户端尝试一个地址但是该地址失败，则它会等待大约 20 秒，然后尝试列表中的下一个地址。因此，如果失去客户端访问服务器阵列的 VIP，则客户端的恢复会在大约 21 秒后自动进行。”
绑定命名空间模型（依据数据中心的命名空间）
在绑定的命名空间模型下，用户会被指定给某个特定的数据中心；也就是说，只有在用户被指定的首要数据中心发生故障转移的时才会切换到另外的数据中心。
见下图，给每个数据中心进行分配命名，比如mail.contoso.com，mail2.contoso.com等等。两个Datacenter之间有两个跨数据中心的DAG，这样就只需要控制邮箱数据库的挂载位置就相当于控制了用户连接。
依据地理位置的命名空间
这种做法从OWA出来到现在就一直存在，即连接到离自己最近的CAS。然后这种做法就是在绑定的命名空间模型之上，为每个数据中心配对（我们讲一个跨数据中心的DAG，被覆盖到的数据中心称为一个数据中心配对。）再为配对的数据中心，按照地理位置分配命名空间。就是如下图所示的样子：
Tips：那么在每一个地理位置的命名空间里面，是不是又被应用上了非绑定的命名空间模型？
总结
扯了这么多，虽然感觉上没有多少条理，但是主要目的是为了讲清楚，并且理解，Exchange的命名空间设计目的，在日常规划中为什么要这样或者那样去规划命名空间。关于单一命名空间特性，如果有什么不明白的，可以再看一下文中贴出来的technet链接，讲的非常好。
今天就说到这里，下一章我们会聊聊Autodiscover。
最后照例打一下广告：
http://www.itcharger.com/
你身边的 IT 加油站！
也欢迎关注 ITCharger 的微信公众号，每周更新的文章也会在这上面发布; 同时也有其他关于微软私有云技术的文章的分享。
