企业在云存储方面常犯的错误及避免方法

Source: Dev.to

一次又一次，我看到大型企业因为把云存储当作神奇的无限磁盘而烧钱、性能下降，甚至制造合规噩梦。事实并非如此。它是一个工具箱。如果你把锤子用于所有工作，最终会砸到自己的拇指。以下是我常见的错误，以及如果从头重建我会如何避免它们。

1. 将云存储视为本地 SAN

我的做法

• 使用 对象存储 作为默认，适用于以下情况：
  • 跨团队共享
  • 读密集型
  • 长期存储
• 为对延迟敏感、耦合紧密的工作负载（例如数据库、某些传统应用）保留 块存储。
• 如果你发现自己把“所有东西”都放在块存储上，这就是一个红灯，表明你正在云端重新实现旧有模式。

2. 将所有内容保持在最热（最昂贵）层级

如何避免

• 将数据分类为 hot / warm / cold / archive 层级。
• 默认对每个存储桶应用自动生命周期策略：

# Example lifecycle policy (pseudo‑YAML)
rules:
  - action: transition
    days: X          # after X days → cool tier
    storageClass: COOL
  - action: transition
    days: Y          # after Y days → archive tier
    storageClass: ARCHIVE
  - action: delete
    days: Z          # optional: delete after Z days

• 仅对能够主动说明为何必须保持热状态的数据集予以例外。
• 经验法则： 如果没有人在 5 秒内说出数据集必须保持热的理由，那么它大概率不该保持热。

3. Ignoring egress and API costs

How I avoid this

• Co‑locate compute and storage in the same region by default.
• For high‑I/O workloads, shard small files into larger objects (e.g., WebDataset, TAR, Parquet).
• Use caching:

Local NVMe or node‑local SSDs as a read‑through cache for frequently accessed datasets.

• Set up cost dashboards that surface:
  • Top egress sources
  • Top buckets by API requests

If you don’t measure egress and API calls, you’ll be surprised. Cloud surprise is always expensive.

4. 对性能关键工作负载缺乏数据本地化策略

我的准则

• 数据和计算必须尽可能物理上接近。

对于大规模训练工作负载

• 将规范数据保存在同一区域的对象存储中。
• 在作业开始前，将活跃分片预置到本地 NVMe 上。

对于关键的实时推理

• 将模型和关键特征保存在本地 SSD / 高性能块存储上。

如果你在为高端 GPU 付费，几乎总是比让这些 GPU 因等待数据而空闲更划算的是对高速存储进行超额配置。

5. 过度共享和治理不足的存储桶

我的处理方式

• 为数据域设计，而不是“一桶统治一切”：
  • analytics-、ml-、raw-、archive- 等
• 为每个存储桶/域分配明确的所有者：
  • 数据所有者
  • 访问策略所有者
  • 生命周期策略所有者
• 使用 最小权限 IAM：
  • 尽可能只读
  • 限制写入权限
  • 在生产和实验存储桶之间保持强隔离

安全团队喜欢这样，审计员也喜欢。更重要的是，它能减少事故。

6. No versioning, no backups, no restore tests

My practical approach

• Turn on versioning 对于存放生产模型、配置或关键参考数据的任何 bucket。
• 定义清晰的复制 / 备份方案：
  • 跨区域复制，用于“如果这个区域挂了，我们就麻烦了”的数据集。
  • 使用独立的“备份项目/账户”，以防止意外删除。
• Actually test restores：
  • 从备份中随机提取一个数据集。
  • 记录所需时间并注意任何故障。

如果你从未进行过恢复演练，默认它是不可用的。

7. 让每个人永远“想干什么就干什么”

我的建议

• 创建一小套 storage patterns：
  • “Analytics dataset pattern”
  • “ML training dataset pattern”
  • “Archive pattern”
• 提供模板和工具：
  • Terraform modules、bucket‑naming conventions、lifecycle defaults。
• 允许偏离——但要使其成为 explicit decisions，而不是意外。

目标并非为了中心化控制本身，而是避免出现 20 种方式去做同一件事，而每种方式又各有轻微缺陷。

汇总

• 你的数据存放在哪里？
• 谁拥有哪些存储桶？
• 你的生命周期策略是什么？
• 你多久移动或恢复一次数据？

我看到的大多数“GPU 性能问题”实际上是伪装的存储设计问题。如果你把云存储视为一个战略系统（对数据进行分类、控制访问、管理生命周期、测试恢复并关注本地性），你将获得更好的安全性、更低的费用，以及更满意的 GPU。