در AI training، data lake، و container platform معمولاً سه نیاز جدا دارید:

POSIX  →  mount برای training / checkpoint
S3     →  object API برای pipeline و toolها
HDFS   →  سازگاری با stack بیگ‌دیتا

راه‌حل کلاسیک: سه سیستم جدا، سه کپی داده، سه تیم ops.

CubeFS یک سیستم است:

A Cloud Native Unstructured Data Storage — Multi-protocol access (S3, HDFS, POSIX) with interoperable data.

یعنی همان فایل را با aws s3 بخوانید، با FUSE mount کنید، و با HDFS client ببینید — یک volume، یک truth.

CNCF Graduated — ۱۱ دسامبر ۲۰۲۴ (Incubating از ژوئیه ۲۰۲۲؛ ورود به CNCF دسامبر ۲۰۱۹). Production در OPPO، BIGO، JD.com، NetEase در مقیاس PB/EB.

مشکل storage در cloud-native و AI

Ceph (عمومی):
  قدرتمند — complexity بالا، یادگیری سنگین

MinIO (فقط object):
  S3 عالی — POSIX/HDFS native نیست

HDFS کلاسیک:
  بیگ‌دیتا — cloud-native / CSI ضعیف‌تر

CubeFS:
  S3 + POSIX + HDFS روی یک cluster
  replica یا erasure coding
  CSI برای Kubernetes

CubeFS برای unstructured data در مقیاس بزرگ و سناریوهای AI / data lake / container طراحی شده — نه block storage جایگزین local SSD برای database OLTP.

CubeFS چیست؟

CubeFS (قبلاً ChubaoFS) یک distributed storage cloud-native است که:

• Multi-protocol — S3، POSIX، HDFS با داده مشترک بین پروتکل‌ها
• Multi-engine — replica و erasure coding (قابل انتخاب per volume/scenario)
• Highly scalable — افقی تا PB و EB
• Multi-tenancy — isolation و سیاست ظرفیت per tenant
• High performance — multi-level cache، بهینه‌سازی small file، پروتکل‌های replication
• Cloud-native — CSI Driver برای Kubernetes

Repo: github.com/cubefs/cubefs

CSI: github.com/cubefs/cubefs-csi

Helm: github.com/cubefs/cubefs-helm

Paper: SIGMOD 2019

License: Apache 2.0

تاریخچه و CNCF

Adopters عمومی: OPPO (AI training ~3× acceleration در گزارش‌ها)، BIGO (ML platform)، JD.com، NetEase.

معماری

طبق معماری رسمی:

Clients
  ├── cfs-client (FUSE / POSIX)
  ├── ObjectNode (S3 SDK / s3cmd)
  └── HDFS SDK / client
           │
           ▼
    ┌─────────────┐
    │   Master    │  resource management, volume, topology
    └──────┬──────┘
           │
     ┌─────┴──────┐
     ▼            ▼
 MetaNode      Data subsystem
 (metadata)    ├── Replica: DataNode
               └── EC: BlobStore (BlobNode, …)

۱. Master (Resource Management)

چند Master (معمولاً Raft) مسئول:

• مدیریت volume و capacity
• ایجاد / تعادل metadata و data partition
• health check روی MetaNode / DataNode
• topology و zone awareness

Client و ObjectNode از Master volume view می‌گیرند.

۲. Metadata Subsystem (MetaNode)

• چند Meta Partition روی MetaNodeها
• هر partition محدوده inode دارد
• Multi-Raft برای consistency
• دو B-Tree در حافظه: inode B-Tree و dentry B-Tree

این جداسازی metadata از data همان الگوی مقیاس‌پذیر file systemهای مدرن است — MetaNodeها CPU/RAM-heavy، DataNodeها disk-heavy.

۳. Data Subsystem — دو engine

هر دو می‌توانند همزمان در یک cluster باشند؛ انتخاب per workload.

۴. Object Subsystem (ObjectNode)

• Gateway S3-compatible
• Stateless و افقی مقیاس‌پذیر
• با MetaNode و DataNode مستقیم صحبت می‌کند
• semantic conversion از S3 key به POSIX path/dentry

از v3.2.1 به بعد ObjectNode بهتر با erasure-coded volumes کار می‌کند.

BlobStore: erasure coding در مقیاس EB

برای کاهش هزینه نسبت به 3-replica، CubeFS زیرسیستم BlobStore را دارد:

Highly reliable, highly available, low-cost, EB-scale independent key-value storage.

اجزا:

Reed-Solomon EC

• داده به N block تقسیم می‌شود
• M parity ساخته می‌شود
• stripe کامل = N+M
• تا M failure قابل بازسازی است

دو سبک: Block EC و Stripe EC — بسته به نحوه جمع‌آوری داده برای stripe.

نتیجه عملی: برای cold data و data lake، EC هزینه storage را نسبت به multi-copy کم می‌کند — همان دلیلی که OPPO برای مهاجرت از HDFSهای پرهزینه مطرح کرده است.

Multi-protocol: یک داده، چند دسترسی

Write via S3:
  PUT s3://vol/models/v1.bin
       │
       ▼ (ObjectNode → Meta + Data)
  Same inode/dentry in MetaNode

Read via POSIX:
  cat /mnt/cubefs/models/v1.bin   # cfs-client FUSE

Read via HDFS:
  hdfs dfs -cat /models/v1.bin

نکته semantic S3 ↔ POSIX

Object storage key-value است (a/b و a/b/c مستقل‌اند). CubeFS پایه POSIX دارد؛ ObjectNode مسیر را به directory + file تبدیل می‌کند:

• a/b/c → پوشه a/b + فایل c
• a/b → فایل b زیر a

برای applicationهایی که فرض S3 خالص دارند، این تبدیل را در طراحی key رعایت کنید.

Atomic S3 write

Write از S3 ابتدا به temporary object (inode بدون dentry) می‌رود؛ بعد از موفقیت کامل، dentry ساخته می‌شود و فایل visible می‌شود — جلوگیری از partial object.

ویژگی‌های کلیدی

Kubernetes و CSI

CubeFS CSI بر اساس Container Storage Interface است:

• Driver name: csi.cubefs.com
• Provisioner برای PVC / PV
• معمولاً با cubefs-helm نصب می‌شود

StorageClass (مفهومی)

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: cfs-sc
provisioner: csi.cubefs.com
reclaimPolicy: Delete
parameters:
  masterAddr: "master-0:17010,master-1:17010,master-2:17010"
  # capacity / owner / other volume params per docs

PVC + Pod

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: cfs-pvc
spec:
  accessModes:
  - ReadWriteMany
  volumeMode: Filesystem
  resources:
    requests:
      storage: 100Gi
  storageClassName: cfs-sc
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: training-job
spec:
  replicas: 3
  selector:
    matchLabels:
      app: training
  template:
    metadata:
      labels:
        app: training
    spec:
      containers:
      - name: trainer
        image: my-ml:latest
        volumeMounts:
        - name: data
          mountPath: /data
          mountPropagation: HostToContainer
      volumes:
      - name: data
        persistentVolumeClaim:
          claimName: cfs-pvc

ReadWriteMany — چند Pod همزمان روی همان volume (مناسب training shared dataset و checkpoint directory).

Cluster CubeFS می‌تواند خارج از K8s یا داخل همان cluster (via Helm) باشد؛ CSI فقط masterAddr را می‌خواهد.

استقرار

حالت‌ها

Client POSIX (FUSE)

# نمونه — مسیرها و config را از docs بگیرید
cfs-client -c /etc/cubefs/fuse.json
# mount point در config — مثلاً /mnt/cubefs
ls /mnt/cubefs

fuse.json معمولاً شامل: mount point، volume name، master addresses، log path، owner credentials.

S3 access

# endpoint → ObjectNode
aws --endpoint-url http://objectnode:17410 s3 ls s3://myvolume/
aws --endpoint-url http://objectnode:17410 s3 cp ./model.bin s3://myvolume/models/

یا SDKهای استاندارد Amazon S3.

Multi-tenancy و ظرفیت

CubeFS مدیریت ظرفیت و tenant را در لایه volume/user دارد:

• Volume به‌عنوان واحد isolation
• Quota / capacity per user یا volume
• Zone برای قرارگیری فیزیکی و failure domain

برای platform team: هر تیم یک volume (یا چند volume با QoS) — شبیه bucket در S3 اما با قابلیت mount POSIX.

سناریوهای کاربردی

۱. AI / LLM training

• dataset مشترک RWX روی CSI
• checkpoint با throughput بالا
• مدل‌ها از S3 API به pipeline CI/CD

گزارش OPPO: شتاب قابل‌توجه AI training روی hybrid cloud با CubeFS.

۲. Data lake

• جایگزینی/تکمیل HDFS برای cold+hot
• EC برای کاهش هزینه redundancy
• دسترسی S3 برای tools مدرن + HDFS برای legacy

۳. Container platform

• PVC مشترک بین microservices
• جداسازی storage از compute برای middleware

۴. Database / middleware storage-compute separation

• state پایدار روی CubeFS
• compute ephemeral روی K8s

۵. Data sharing و protection

• یک منبع truth بین تیم‌ها و پروتکل‌ها
• multi-AZ / zone برای durability

مقایسه با جایگزین‌ها

CubeFS جایگزین etcd یا database نیست — unstructured file/object است. State کنترل‌پلین Kubernetes همچنان در etcd می‌ماند.

عملیات و troubleshooting

چک‌های رایج

# health Master / cluster — از ابزارهای admin CubeFS
# logs client
tail -f /cfs/logs/...

# CSI driver logs
kubectl logs -n cubefs -l app=csi-cubefs -c cfs-driver

مشکلات متداول (از FAQ عمومی)

Capacity

Monitor فضای DataNode / BlobNode و meta partition — قبل از full شدن، node اضافه کنید (horizontal scale).

امنیت

• Authentication روی volume/user (access key برای S3)
• Network isolation — Master/Meta/Data در شبکه خصوصی؛ فقط ObjectNode/CSI در edge
• TLS در مسیرهای client در صورت پیکربندی
• روی K8s: NetworkPolicy / Cilium برای محدود کردن CSI و client pods
• RBAC روی PVC/StorageClass — چه تیمی چه volume بسازد

برای certificateهای endpoint عمومی ObjectNode می‌توانید از cert-manager استفاده کنید.

ارتباط با stack شما

Kubernetes apps
  ├── CSI PVC (CubeFS) ← shared models, datasets, logs
  ├── [CoreDNS](/blog/coredns-kubernetes-dns-guide/) ← service discovery
  ├── CNI ([Cilium](/blog/cilium-ebpf-kubernetes-networking/))
  └── CRI ([containerd](/blog/containerd-container-runtime-guide/))

Platform / GitOps
  ├── [Argo CD](/blog/argo-project-kubernetes-gitops-cicd/) ← deploy CSI + apps
  └── [Crossplane](/blog/crossplane-kubernetes-control-plane-guide/) ← optional: provision nodes/volumes as API

CubeFS cluster
  ├── Master / MetaNode / DataNode / BlobStore
  └── ObjectNode ← S3 for pipelines outside cluster

CubeFS لایه data plane storage است — مکمل control plane (etcd) و networking، نه جایگزین آن‌ها.

Best practices

1. Hot vs cold جدا — replica برای hot؛ EC برای cold/archive
2. MetaNode را disk-bound نکنید — RAM و CPU کافی برای B-Treeها
3. Master فرد (۳) — HA برای control plane CubeFS
4. Zone-aware برای multi-AZ
5. CSI mountPropagation: HostToContainer طبق docs
6. Monitor قبل از 80% disk — repair EC به free space نیاز دارد
7. نسخه ObjectNode را با EC align کنید
8. Benchmark با workload واقعی — AI sequential vs small-file random
9. Backup / snapshot policy در سطح volume و application
10. یک protocol را primary کنید در هر app تا semantic غافلگیر نکند

چه زمانی CubeFS؟

✅ استفاده کنید

• نیاز همزمان به S3 + POSIX (و/یا HDFS)
• AI/ML با shared dataset و checkpoint روی K8s
• Data lake با فشار هزینه multi-copy → EC
• Multi-tenant storage platform داخلی
• مقیاس PB با تیم ops cloud-native

⚠️ شاید نه

• فقط چند PVC کوچک → NFS/cloud CSI ساده‌تر
• فقط object بدون POSIX → MinIO/cloud S3
• Database block با latency بسیار پایین → local NVMe / RBD
• تیم بدون ظرفیت ops برای distributed storage

جمع‌بندی

CubeFS پاسخی است به این سؤال: «چطور یک storage داشته باشیم که هم training job با FUSE بخواند، هم pipeline با S3 بنویسد، هم هزینه cold data را با EC پایین بیاورد؟» — بدون سه silo جدا.

قدم بعدی

1. Quick Start — standalone یا docker-compose
2. یک volume + cfs-client mount و تست POSIX
3. ObjectNode + aws s3 روی همان volume
4. با Helm CSI یک PVC RWX در Kubernetes بسازید
5. برای cold data، BlobStore / EC را در lab ارزیابی کنید

منابع

• CubeFS — cubefs.io
• Architecture
• Kubernetes / CSI
• CNCF CubeFS
• GitHub — cubefs/cubefs
• cubefs-csi
• cubefs-helm

منتشر شده در P30Light — بخش زیرساخت و سرور.