题
我有一个负载平衡的环境,有超过 10 个运行 IIS 的 Web 服务器。所有网站都访问托管所有图片的单个文件存储。我们目前有 200GB 的图片 - 我们将它们存储在每个目录 1000 张图片的目录中。现在,所有映像都位于连接到用作文件服务器的单个服务器的单个存储设备 (RAID 10) 中。所有 Web 服务器都连接到同一 LAN 上的文件服务器。我正在寻求改进架构,以便我们不会出现单点故障。我正在考虑两种选择:
- 将文件存储复制到所有网络服务器,以便它们都可以在本地访问数据
- 将文件存储复制到另一个存储,这样如果当前存储发生问题,我们就可以切换到它。
显然对文件存储所做的主要操作是读取,但也有很多写入操作。您认为首选方法是什么?还有其他想法吗?
我目前排除使用 CDN,因为它需要对应用程序进行架构更改,而我们现在无法进行此更改。
没有正确的解决方案
其他提示
在进行拱形更改之前我通常会考虑的某些事情是
- 当前拱门存在哪些问题
- 我对当前的拱门做错了什么。(如果这已经工作了一段时间,小的调整通常会解决很多问题)
- 它能让我轻松成长吗(这里总是有上限的)。根据过去的数据增长情况,您可以有效地进行规划。
- 可靠性
- 易于维护/监控/故障排除
- 成本
200GB 并不是很多数据,您可以使用一些自制的解决方案或使用 NAS 之类的东西,这将允许您以后进行扩展。并拥有它的热插拔副本。
复制到所有网络服务器的存储是一个非常昂贵的设置,正如您所说,有很多写入操作,复制到所有服务器会产生很大的开销(只会随着服务器数量和数据的增长而增加) )。此外还存在其他节点之一提供过时数据的问题。除此之外,对于 10 个和不断增长的节点,复制问题的故障排除将会变得一团糟。除非文件的查找/读取/写入对时间要求非常严格,否则复制到所有网络服务器并不是一个好主意。用户(网络)几乎不会注意到加载时间 100 毫秒 - 200 毫秒的差异。
由于存储中的数据很少,因此购买多个大硬盘或使用网络服务器上的可用空间来保存副本是有意义的。它将减轻后端存储系统的压力,当它出现故障时,您仍然可以为用户提供内容。更好的是,如果您需要扩展(更多下载),您只需添加一个新服务器即可,后端的压力不会发生太大变化。
如果我必须这样做,我会使用 同步 或者 一致 将图像文件复制到 Web 服务器上与存储设备上完全相同的空间中(这样,您可以随时使用网络文件系统挂载交换副本)。
时不时地运行 rsync(例如在上传后或晚上一次;您会更好地知道哪种尺寸最适合您)。
更通用的解决方案是使用像 Bittorreent 这样的 P2P 协议。这样,您可以将存储后端上的所有更改发布到 Web 服务器,它们会自动优化更新。