本文将为大家简单介绍SAN技术创建群集系统的注意事项的相关内容，以下是文章的详细内容，有兴趣的读者不妨看看此篇文章，希望能为各位读者带来些许的收获。

　　Active/active and active/passive需要考虑的事项

　　一个 active/active (a/a)群集有两个节点或服务器，它们同时都很活跃、平分负荷，相互映射对方的数据更新。如果一台服务器离线了，另外一台服务器就会接着工作。一个a/p方案就是一台服务器不停运作，另外一台随时待命。如果主要的那台服务器不运转了，只需要进行备份。

　　有了a/a群集，每台数据库服务器都应该有自己的一套磁盘镜像，这两台服务器不能共享同一个数据库逻辑驱动。这样一来很明显就要贵得多，但是如果你想要得到最好的运行时间，那么这里增加所需磁盘的价格还是值得的。

　　一些数据库管理员甚至给每个群集的节点都提供了SAN。然而如果在节点之间数据复制的数量超过了在用户之间来回传送的数据的数量，那在同一个SAN 上设置a/a群集可能就更加有意义了(虽然是在不同的物理磁盘)。

　　有了a/p群集，你能跟轻松地让数据库共享磁盘或者是SAN集合。既然一台数据库服务器在任何时候都能起到作用，就没有什么可以争论的了。

　　保持群集之间的驱动器名一致

　　这是有关群集最详细的建议，需要牢记。所有在一个群集中的主机节点必须是有着相同驱动器名称的驱动器，所以要广泛策划你的驱动器名称。集合起来的软件能够掌握能够访问具体设备的用户信息，因此你不必担心这种事情会发生，但是每个节点都必须对存储持一致的意见。

　　不要尝试来回迁移临时数据库

　　SQL Server临时数据库是失效转移过程的一部份，需要作为共享文件来利用。不要来回迁移临时数据库。你可能认为你正在通过本地寄宿数据库获取SAN的带宽，但是为了基本功能所用的费用并不值得。

　　仅通过映射驱动器进行备份

　　如果你正使用SAN存储SQL Server备份，这些备份就应该通过映射驱动器名而不是通过UNC名称运行。SQL Server群集失效转移只能通过用Cluster Service Cluster Administrator登记的存储设备来操作。

　　如果你操作失败并需要通过群集里的共享设备登录SQL Server备份的话，这一点就尤其重要。同样在为你的备份设置驱动的时候也要记的第几点建议。