标签: shared-storage

我vagrant为运行 OSX 的开发人员管理一个设置，以管理 VirtualBox 系统进行开发。

为了inotify在 linux 机器内部提供支持，我们避开了与 VirtualBox 共享目录的常用方法：相反，Virtualbox 机器公开了一个 NFS 共享，该共享安装在 OSX 中。

Git（以及相关工具，如 sourcetree）在 OSX 中的共享目录中运行。其性能极差：仅运行git status. 将一个小型存储库克隆到挂载的 NFS 驱动器可能需要几分钟（在本地驱动器上为 5-10 秒）。

显然 NFS 的性能会比直接写入本地 SSD 更差，但 NFS 只是在 Virtualbox 的虚拟专用网络接口上运行。

我运行了几个基准测试。首先：

dd if=/dev/zero of=test bs=16 count=16384

每个结果都基于 100 个样本。

# local drive
Min. 1st Qu.  Median    Mean 3rd Qu.    Max.
0.990   1.000   1.020   1.021   1.030   1.130

# on the shared NFS drive
Min. 1st Qu.  Median    Mean 3rd Qu.    Max. …

我正在寻求有关支持 ESXi HA 集群的共享存储选项的建议（请注意，我不是在要求产品/品牌/型号推荐 - 我知道这违反了此处的规则）。我问了技术建议。

我工作的公司是一家小企业。目前，我们有一台带有 DAS 的 HP DL380 G9，带有 ESXi 6.0，运行我们定制开发的应用程序。我们现在正在研究如何使用最经济的选项实现 HA/FT。我们需要 HA/FT，因为我是一个人的 IT 团队，我经常出差，所以手动故障转移/恢复不是一种选择。

我知道我们至少需要 2 个 ESXi 主机（物理服务器）和共享存储才能实现 HA/FT。我认为，这就是有趣的地方：即使是最便宜的入门级存储阵列对我们来说也可能是一种矫枉过正。我们的存储容量需求可能在 200GB 左右，而且至少在 5 年内我们不会看到翻倍。然而，我们需要用于 HA/FT 的共享存储。

因此，我真的很感激任何关于我的选择的建议。谢谢。

我们即将部署共享存储研究以实现超快速存储以实现 Microsoft SQL Server 故障转移集群 (FCI)。到目前为止，项目开始时，我们将从 8k 块的 500K IOPS 开始，大约 70r/30w 模式。此外，由于 SQL Server 不断增长的期望，我们希望能够在一年左右的时间内将 pefromance 提高到 2M IOPS（对于相同的模式）。

出于该项目的目的，我们将部署 Microsoft Storage Spaces Direct (S2D) 的 4 节点集群。至于硬件，我们已经拥有 2 台戴尔机架式服务器 R730xd，配备 2 台 E5-2697 和 512GB 内存，我们准备再购买 2 台。

至于存储，微软建议使用 NVMe 或 NVMe + SSD 以获得最大性能（来源）。因此，经过一番研究，三星 SSD 很适合搭配。https://www.starwindsoftware.com/blog/benchmarking-samsung-nvme-ssd-960-evo-m-2 http://www.storagereview.com/samsung_960_pro_m2_nvme_ssd_review

我们考虑的设置如下：每个 S2D 主机 1 个三星 960 EVO NVMe + 4 个三星 PM863 SSD。

使用三星 960 EVO NVMe 和三星 PM863 的 S2D 实现能否为 SQL FCI 提供 500k？

编辑： …

我需要构建一个解决方案来托管内部 git 存储库。它需要支持数十万（或更多）存储库。

我计划将多个“哑”服务器与共享存储一起使用，因此基本上当客户端尝试访问存储库时 - 负载平衡器会将其重定向到任何可用服务器。对存储库的任何更改 - 将在所有节点上复制。

我的第一个想法是为此使用 GlusterFS，但我读过它不能很好地处理小文件。我也在考虑使用 DRBD 自己复制所有内容，但这需要更多设置，并且与 GlusterFS 相比似乎更复杂。

两者中哪一个提供更好的性能？基本上，我试图解决的问题是，当任何服务器出现故障时 - 我希望其他人仍然能够提供数据。

我们将实施远程桌面服务器群，用户的配置文件将托管在文件服务器上。我相信这样做将允许用户从他们的桌面/文档文件夹等中删除文件，并且仍然提供一种从回收站恢复的方法。

我们还需要为用户提供共享文件夹，以便他们可以存储与其部门相关的文档。我们通常这样做的方法是使用映射驱动器到文件服务器上的 SMB 共享。

这样做的缺点是，当删除映射驱动器上的文件时，它是永久删除，除非我们使用卷影副本或类似的东西，否则我们必须从磁带/磁盘备份中恢复。

是否有任何其他推荐的方法来提供对中央服务器上共享文件夹的访问权限，这些方法不是永久删除？

查看以下集群共享空间 TechNet文章，看起来这仅适用于通过外部 SAS 背板共享 JBOD 机箱的主机。

但是，双节点集群中的每个主机都具有相同数量的 SAS 15K 驱动器 (4)，当前配置为 RAID 10 阵列。

我想知道是否有与 VMWare 的 Virtual SAN 技术等效的 Hyper-V，而本地磁盘可以作为群集上的共享存储节点公开。

基本上，我们只想使用主机上的磁盘，而故障转移群集管理器似乎不想与本地磁盘打交道，就移动虚拟机的目标而言。如果 SAN 维护能够根据需要将 VM 随机播放到本地磁盘，那就太好了。

任何人都可以为生产级开源共享存储 (SAN) 文件系统提供建议吗？

我读过 GFS 和 GFS2，但第一个似乎有点过时，第二个在生产中被认为不稳定。

还有其他我可以检查的吗？

我正在配置一个双节点 A/A 集群，通过 iSCSI 连接一个公共存储，它在集群 LVM 之上使用 GFS2。到目前为止，我已经准备了一个简单的配置，但我不确定哪个是配置 gfs 资源的正确方法。

这是 /etc/cluster/cluster.conf 的 rm 部分：

<rm>
    <failoverdomains>
        <failoverdomain name="node1" nofailback="0" ordered="0" restricted="1">
            <failoverdomainnode name="rhc-n1"/>
        </failoverdomain>
        <failoverdomain name="node2" nofailback="0" ordered="0" restricted="1">
            <failoverdomainnode name="rhc-n2"/>
        </failoverdomain>
    </failoverdomains>
    <resources>
        <script file="/etc/init.d/clvm" name="clvmd"/>
        <clusterfs name="gfs" fstype="gfs2" mountpoint="/mnt/gfs"  device="/dev/vg-cs/lv-gfs"/>
    </resources>
    <service name="shared-storage-inst1" autostart="0" domain="node1" exclusive="0" recovery="restart">
        <script ref="clvmd">
            <clusterfs ref="gfs"/>
        </script>
    </service>
    <service name="shared-storage-inst2" autostart="0" domain="node2" exclusive="0" recovery="restart">
        <script ref="clvmd">
            <clusterfs ref="gfs"/>
        </script>
    </service>
</rm>

这就是我的意思：使用 clusterfs 资源代理处理 GFS 分区时，默认情况下不会卸载它（除非给出 force_unmount 选项）。这样当我发出

clusvcadm -s shared-storage-inst1

clvm …

我正在考虑在 AWS (EC2) 基础设施上设置一个共享文件系统/文件服务器，以提供复制和相当轻松的故障转移。这个文件系统可能会承载数百万个大小为几兆的文件。将从多个客户端 VM 访问（读/写）这些文件。如果主文件服务器出现故障，我希望客户端能够在不丢失任何文件的情况下故障转移到副本文件服务器（即我希望复制是实时的）。我查看了几个选项：

• 将 S3 与 s3fs 结合使用。我担心在对数千个文件执行操作时（例如，在复制/移动文件时），每个请求的延迟都会有问题。我还听到一些报道让我质疑 s3fs 的稳定性——不确定是否仍然如此。
• 在 EC2 实例上设置 NFS 服务器，使用 drbd 在两个实例之间复制块。缺点：
  1. 我过去曾遇到过 drbd 的可靠性问题，尤其是在高延迟链接上
  2. 如果主 NFS 服务器出现故障，它将关闭客户端，需要系统管理员干预和/或重新启动才能让它们重新连接到辅助服务器。没有自动故障转移。

有没有更好的解决方案？

我有两到三台较旧的 HP ProLiant DL380 G6/7 服务器，只有 x * 1 GBit 以太网，但 CPU 功率、RAM 和本地存储容量相当可观。我有兴趣构建一个由两个甚至三个节点组成的小型集群式设置，其中所有节点都提供服务，这与我目前对“超融合”流行语的理解非常相似。这些服务特别托管 VM，这些 VM 本身为不同的 Web 应用程序、一些守护程序、数据库等托管 Web 服务器。在应用程序级别上非常不同的东西，一些 I/O 绑定，一些不是。

这些服务器目前正在使用 Synology 的一些入门/中端 NAS，但事情不再那么好用了。我在让 NAS 在繁重的 I/O 负载下可靠工作时遇到了问题，除了一些基准测试之外，日常性能也不是很好。所以我正在研究不同的选项，比如集群文件系统、DRBD、即用型解决方案，比如 Proxmox 等等。

我目前问自己的主要问题是，是否有某种方法可以通过构建更喜欢本地读取和写入的“东西”来使网络成为一些可能的瓶颈。例如，DRBD 提供了复制协议 A，这正是我想到的。可能的数据丢失的时间跨度可能是某人认为可以接受的风险，查看每台服务器的冗余硬件等。此外，人们可能根本不需要在所有给定时间在所有节点上托管应用程序的可能性，但在节点更新和重启等情况下，仅在节点上移动应用程序可能是可以接受的。这样的事情可能会完成手动，经过一些准备步骤或其他什么。

重要的一点是，如果节点在大部分时间都托管自己的应用程序，则可以通过之后的异步写入通信来进行大量本地读取和写入。这也正是DRBD 文档所说的：

无论如何，在双主模式下使用 DRBD 作为 GFS 的复制存储设备是完全可能的。由于 DRBD 通常从本地存储读取和写入本地存储，而不是 GFS 通常配置为运行的 SAN 设备，因此应用程序可能会受益于减少的读/写延迟。

在块级别是否有没有 DRBD 的可比技术？也许一些集群文件系统自己已经提供了这样的东西？此外，如果所建议的内容仅适用于开箱即用的当前 Ubuntu 发行版，那将是有益的，因为这是我目前为服务器选择的操作系统。