在准备基础设施以利用像MooseFS或XtreemFS这样的分布式存储系统时，单个节点应该如何向其余环境提供存储？ 将分区放置在物理硬件附近还是单独放置逻辑卷和/或卷组？ 在之前的一个问题中，“ 是否有一种方法可以执行像LVM一样的事情？ ”，我通过使用VMware这样的中介来获得与使用像GlusterFS这样的分布式系统类似的结果。 应该如何最好地处理分布式文件系统？ 这种方法取决于所选的分布式文件系统吗？
我试图build立一个由两台服务器组成的冗余设置， 数据库（MySQL master-master在主动/被动模式下） 文件系统（分布式/复制） 我们的应用软件（使用分布式文件系统保持同步） 大多数情况下，两台服务器中的一台将成为“主要”服务器，另一台将复制所有数据，并将用于分配工作量（Gearman）。 在主服务器出现故障的情况下，一切都切换到“备用”服务器，该服务器将成为“主动”服务器并继续工作。 为了降低两台服务器完全失败的风险，它们在两个遥远的数据中心（相同的国家/直接连接）中在地理上是分开的 。 我读了很多关于分布式文件系统，但仍然没有线索，哪个解决scheme适合只有两个节点… 对分布式文件系统有更多的要求： 必须符合POSIX标准 必须在两个方向上复制一切 （所有数据必须在两台服务器上都可用）（所有数据都可以在任何地方更改） 与现有数据有关的当前统计数据应该在未来被复制： 约30 GB的数据 ，自3年以来不断增长 在7500个目录中约有300万个文件 平均文件大小约。 5-10kb ; 有10-50 MB的大文件 大多数文件都是定期在一天中添加，一旦处理就移动到另一个目录（类似于基于文件的邮件服务器） 一天一次，几千个文件（前一天收到的）被存档到一些TAR档案中，并“离开” 在添加文件时，首先将数据写入以“。”开始的临时文件。 然后在完成时重命名。 只有很less的现有文件正在改变。 系统应该处理意外的连接损失，重启服务器等。 没有问题，如果复制滞后1-2秒，但它应该始终处于一致的状态 正如所说，分配。 的filesys。 将只包含两个节点，但是如果我可以添加额外的节点/服务器将会是一个很大的好处，未来我是否需要更多的计算能力 更新/更多细节： 我只需要“在两台服务器上存储的文件，立即同步”的意义上的冗余。 当访问文件时，我不需要文件系统从另一台服务器读取数据，只是因为本地硬盘出现故障。 当本地硬盘故障时，整个服务器机器被认为是“坏”，因此应该停止工作。 哪种文件系统适合在这种情况下？
有人可以分享他们在多个FreeBSD机器之间构build分布式镜像文件系统的经验吗？ I. e。 我们有两个（三，四…）服务器和每个安装的特殊分区“part1”。 我们在machine1上对其进行一些更改，这些更改立即在所有其他机器的“part1”上生效。 在我们的“集群”上经常没有写操作，但经常是读操作（比如高负载的Internet项目的静态Web数据）。 我们希望同时对所有机器进行对称访问（不要“阻止”访问其中一个）。 我们的目标是提供高可用性，容错和减less（可能热插拔添加和删除这个“群集”的成员）。 是否有像Ceph for Linux这样的本地技术？
我正在寻找容错并易于维护的DFS（分布式文件系统）。 我将有吨（100M +）的小文件（从1K到500K）。 文件将位于某些目录中，将构build数据的逻辑结构。 我将有100Mb / s的平均读取负载和写入负载100Mb / s。 我希望得到一些关于哪个文件系统对于给定的需求最好的input。 有什么想法吗？
这是在这里被问到的同样的问题，但已经差不多两年了。 与此同时，Ceph已经看到了不断的发展（361内核提交）和btrfs，在我看来，它正处于生产准备的边缘。 不过，这两个项目的网站都有（date）部分，明确指出。 Gluster不活跃也从此设法推出了3.1,3.2版本，即将发布3.3版本。 一路上，他们被红帽收购 ，这可能有助于在遥远的将来稳步发展。 那么，Ceph是否已经获得了生产级别的部署呢？ 它如何与GlusterFS比较呢？
我的头脑里有一个图像，链接太慢，无法实现文件的实时传输，但速度足够快，可以赶上每天。 我想看到的是一个主要的主设备，当我向服务器A写入一个文件时，元数据将立即传输到服务器B，并且当服务器B的客户端尝试读取服务器A发送它之前的文件。 似乎有很多文件系统可以在快速链接上运行得很好，但是我不知道有什么好的做法能够解决瓶颈问题和几个小时的延迟问题。
我一直在考虑我所有的工作站（约50台）以及他们每个人都有的浪费的硬盘空间。 例如，我的机器只能使用大约30G到40G的本地存储，但是他们是从500G到1T驱动器的制造商。 所有额外的空间在我看来是浪费。 有没有办法把所有这些额外的空间集中在一起，在所有的工作站上使用某种forms的冗余（如果有一台机器或三台或四台机器脱机），然后像一个大的SAN那样访问它？
注：这是一个“理论上的”问题，因为我还没有那种数据。 如果你有一个分布式的文件系统跨越十几个或更多的服务器和TB的数据，你如何执行备份？ 本地磁带驱动器不是一个选项，因为我正在租用服务器，并且没有物理访问权限。 我看到它的方式，我只需要有一个与源集群成比例的备份集群。 并行发送所有这些数据可能会使数据饱和，从而导致吞吐量下降。 但备份都必须同时进行，因此循环备份似乎没有意义。 解决这个问题的方法之一就是只保留大部分（在我的情况下）驱动器，剩下的部分用于旋转本地LVM快照。 不幸的是，如果服务器受到威胁，那么这种备份将毫无用处。 是否有其他选项可以创build不会中断networking的时间点备份？ [编辑]解决scheme： 1）将（接近）实时全部数据集复制到一个大的本地备份服务器，因此带宽使用和IO在一天中分布，本地带宽通常是“空闲”的。 2）创buildclosures该机器的真实备份并将其发送到现场。 如果将所有数据组合在一起，则应该很容易地执行差异备份，这可以节省计费带宽。
请告诉我这种情况的解决scheme： 几百万个文件，位于一个目录（“img / 8898f6152a0ecd7997a68631768fb72e9ac2efe1_1.jpg”） 〜平均80k文件大小 90％的随机读取权限 备份（复制）到其他服务器（每5分钟或立即） 图像的元数据保存到数据库中 当文件数量超过200万时，我们遇到了随机访问时间慢的问题。 文件系统是使用noatime和dir_index选项的ext3，但不需要使用诸如“ls”或“find”之类的命令。 我认为可能的解决scheme： 留在ext3并简单地将目录树结构转换为“img / 889 / 8f6 / 152 / a0ecd7997a68631768fb72e9ac2efe1_1.jpg” 迁移到其他文件系统（ReiserFS，XFS，EXT4等） 使用分布式文件系统设置存储引擎（举例） 或者其他… 如果我们select1或2，我们如何复制？ rsync无法在ext3文件系统上处理这么多的数据。 对我们来说最好的解决scheme是使用Amazon S3，但是对于我们的stream量来说，这太昂贵了…也许你会推荐一些类比（便宜的CDN或开源项目）
我想实现以下设置： 每当我将笔记本电脑连接到本地networking时，我的分区就会自动镜像到本地服务器上的分区。 我只想反映上一次改变了什么。 （据我所知，这不是一个适当的备份解决scheme，因为没有变化的历史，它会更像是一个非永久性的networkingRAID。） 有没有一个分布式的文件系统，允许这样的设置？ 我做了一些search，在我看来，大多数分布式文件系统都集中在数据可用性和分布上，而不是重复它们。 我会很感激的build议。 编辑：对不起，我忘了提及：我正在使用Linux。