我需要使用Drupal的内置多站点function来组合一个Drupal实例，这将允许我为所有站点使用单个代码库，这是一个节省时间和防止头痛的大事情。 不过，我们将从单一安装中运行几十个站点，所以我们需要一种高性能的方式来透明地共享这些服务器上的文件（包括用户上传等）。 这是否意味着我们需要一个SAN和一堆本地从数据库？ 或者我不知道我在说什么？
我不明白drupal，但是当遇到这个问题时，通常可以把事情分成三个数据存储类别。
1.）数据库 – 这个是“容易的”，因为mysql复制是一个成熟的有据可查的解决scheme。 复制或DRBD可以提供高可用性，但为了提高性能，要一次性利用多台服务器，您的应用程序需要内置的function来将主查询和从查询拆分为读取（select）和写入（插入/更新/删除）查询。
2）文件系统 – 这个更棘手。 “普通”文件系统（ext3 / ntfs）并不是为多主机扩展而devise的，（gfs / ocfs）几乎总是比它们更值得复杂（特别是如果你不得不问的话）。 最常见的解决scheme是基于NAS的方法（unix上的nfs，windows上的cifs），但是引入了单点故障，所以它不是可用性解决scheme。 它通常不是一个性能解决scheme，因为你依赖于一个文件服务器的性能。 它的主要价值在于提供来自多个主机的连贯的读写访问。 如果您的应用程序是CPU瓶颈，那么NAS将帮助您扩展，因为您的服务器将花费时间等待cpu完成，而不是加载文件。
3.）代码和configuration – 通常这是在文件系统，数据库或两者上完成的。 我在这里将它分开，因为它通常比＃1和＃2更多的面向内容的数据存储的范围小得多，系统pipe理员的问题更多。 通常情况下，您只需手动（或脚本化）复制文件即可离开。
因此，考虑到这一切，您需要评估drupal如何处理这三个类别，以及如何复制它们。 你可能会从NAS和负载平衡器开始。 它不太可能你还想要一个SAN。
我不确定SAN和从服务器在哪里（最初），因为你说这是“单一安装”。
您要指定的参数是“文件系统path”。 所以也许如果你打算在你要创build/指定一个值“sites / all / files”（即每个Drupal站点的DB将存储这个值）的所有站点之间共享那个目录。
如果/当您遇到扩展问题，并且需要将站点/所有/文件同时共享到每个Web节点，则可以使用（iSCSI）SAN存储与OCFS2等群集文件系统。 （即文件成为挂载到OCFS2文件系统的SAN存储）。
同样的奴隶服务器。 用于可扩展性（从从站读取）和/或高可用性（将从站升级到主站），或者从从站进行备份，但并不涉及到透明共享文件的初始规范。
希望这可以帮助。
干杯