VMware Horizon 6的一个新特性就是Cloud Pod架构，该架构使组织能够横跨多个数据中心扩展虚拟桌面的部署规模。

VMware的Cloud Pod架构提供了一些优势，包括容错、负载均衡以及集中管理，对灾难恢复来说具备这些功能简直太棒了。

为理解Cloud Pod架构，你先要熟悉VMware View构造块以及View pod，了解公司是否在使用持久型虚拟桌面，如果在pod级别发生运行中断，那么你需要使用一款复制工具在不同pod间复制持久型虚拟桌面。

了解View构造块及pods

View构造块在本质上是VMware vCenter实例，虽然其不止包括vCenter，但vCenter是该构造块不可分割的一部分。

除VMware vCenter Server外，构造块还包括一个或多个vSphere集群。改构造块还拥有共享存储，还可能包括其他组件，比如数据库，VLAN以及网络交换机。构造块中的所有资源能够容纳2000个虚拟桌面。

View pod是一个View构造块集合，每个pod能够包含多达5个构造块，因此能够容纳多达1000个虚拟桌面。View pod是一个独立的实体，你无法通过现有的其他pod对其进行管理。

Cloud Pod架构基于View pod，尽管每个Pod使用了单独的资源集合，但Horizon 6使通过单个界面管理多个pods集合成为了可能，即使这些pod位于不同的数据中心也没有任何问题。

除pod全局管理外，Cloud Pod架构还提供了扩展至多个pod的全局用户权利层。pod级别的用户权利层仍旧存在，但是在本地进行处理。全局的用户权利层以及新的pod间通信通道使得将位于一个或多个数据中心内的虚拟桌面的访问权限授权给用户成为了可能。

在灾难恢复情景中，这一可扩展性可能非常有用。例如，如果主数据中心发生宕机，员工可以使用位于另一个数据中心 pod内的虚拟桌面。

Cloud Pod桌面分配

当然，Cloud Pod架构引发的一个问题就是在Cloud Pod环境中虚拟桌面如何被分配给最终用户。

答案是在大多数情况下由连接代理进行分配。当用户连接到连接代理并通过认证后，代理会向用户匹配最合适的虚拟桌面，或者允许用户选择他想使用的虚拟桌面。在为用户分配桌面时Cloud Pod架构支持一些不同的方法。

可能最常见的用例就是代理基于地理位置向用户分配桌面。例如，假定组织在纽约和洛杉矶都有办公室，公司使用的是非持久型虚拟桌面，那么位于纽约办公室的用户应该会被分配位于纽约数据中心的虚拟桌面。

如果使用持久型虚拟桌面事情会变得有些不同，因为桌面要分配给特定的用户。在正常情况下，无论桌面位于哪个pod中，用户连接到都是他自己的持久型虚拟桌面。

值得注意的是，在谈到提供pod级故障保护时持久型虚拟桌面会面临挑战。如果数据中心发生故障，用户被重定向到另一个数据中心是有可能的—即使用户拥有的是持久型虚拟桌面—但要使用户能够在第二个数据中心使用持久型虚拟桌面，那么必须使用复制工具在不同的pod间进行持久型虚拟桌面的拷贝。