Ceph چیست؟ راهنمای جامع معماری و کاربردها

در زیرساخت‌های مدرن Cloud و Data Center، Storage دیگر صرفاً محلی برای ذخیره فایل‌ها نیست. با افزایش تعداد سرورها، Virtual Machineها، Containerها و Applicationهای Distributed، سازمان‌ها به یک Storage Platform نیاز دارند که بتواند همزمان Scalability، High Availability، Fault Tolerance و Performance مناسبی ارائه دهد.

یکی از شناخته‌شده‌ترین راهکارهای Open Source برای پاسخ به این نیاز، Ceph است؛ یک Distributed Storage Platform که می‌تواند از روی مجموعه‌ای از سرورهای معمولی، یک Storage Cluster قدرتمند و مقیاس‌پذیر ایجاد کند.

Ceph می‌تواند یک زیرساخت واحد برای ارائه Block Storage، Object Storage و File Storage فراهم کند و به همین دلیل در معماری‌هایی مانند OpenStack، Kubernetes، Proxmox، Private Cloud و Data Centerهای بزرگ کاربرد گسترده‌ای دارد.

در این مقاله به صورت جامع بررسی می‌کنیم که Ceph چیست، چگونه کار می‌کند، چه اجزایی دارد، تفاوت آن با SAN و NAS چیست، چگونه در OpenStack و Kubernetes استفاده می‌شود و چه زمانی انتخاب Ceph تصمیم درستی است.

Ceph چیست؟

Ceph یک سیستم ذخیره‌سازی Distributed و Open Source است که برای ارائه استوریج در مقیاس بزرگ طراحی شده است.

برخلاف بسیاری از Storageهای سنتی، Ceph برای ساخت Storage Cluster به یک Storage Appliance اختصاصی وابسته نیست. در عوض می‌توان چندین سرور را در کنار یکدیگر قرار داد و با استفاده از Diskهای موجود در آن‌ها یک Storage Pool توزیع‌شده ایجاد کرد.

        Ceph Storage Cluster

 ┌────────────┐  ┌────────────┐  ┌────────────┐
 │   Server 1 │  │   Server 2 │  │   Server 3 │
 │            │  │            │  │            │
 │ OSD  OSD   │  │ OSD  OSD   │  │ OSD  OSD   │
 │  Disk Disk │  │  Disk Disk │  │  Disk Disk │
 └──────┬─────┘  └──────┬─────┘  └──────┬─────┘
        │               │               │
        └───────────────┼───────────────┘
                        │
                        ▼
                 Ceph Storage

از دید Application، این مجموعه سرورها می‌تواند مانند یک Storage Platform واحد عمل کند؛ در حالی که داده‌ها در پشت صحنه بین Nodeهای مختلف توزیع می‌شوند.

یکی از ویژگی‌های مهم Ceph این است که با اضافه کردن Server و Disk جدید می‌توان ظرفیت و در بسیاری از معماری‌ها Performance را نیز افزایش داد.

Ceph چه مشکلی را حل می‌کند؟

فرض کنید یک سازمان چندین Server دارد و می‌خواهد Storage مرکزی خود را در اختیار Virtual Machineها، Kubernetes و Applicationهای مختلف قرار دهد.

در معماری سنتی ممکن است یک SAN یا NAS خریداری شود:

Servers
   │
   │
   ▼
┌─────────────────────┐
│      SAN / NAS      │
│                     │
│   Shared Storage    │
└─────────────────────┘

این معماری می‌تواند بسیار قدرتمند باشد، اما معمولاً Storage Appliance، Controller، Licensing و Hardware اختصاصی خودش را دارد.

Ceph تلاش می‌کند Storage را به شکل Software-Defined ارائه کند:

        Commodity Servers

 ┌────────┐ ┌────────┐ ┌────────┐
 │Server 1│ │Server 2│ │Server 3│
 │  Disk  │ │  Disk  │ │  Disk  │
 └───┬────┘ └───┬────┘ └───┬────┘
     │          │          │
     └──────────┼──────────┘
                ▼
         Ceph Distributed
             Storage

به همین دلیل Ceph یکی از گزینه‌های مهم برای ساخت Software-Defined Storage محسوب می‌شود.

مهم‌ترین ویژگی‌های Ceph

• Open Source
• Distributed Architecture
• Horizontal Scalability
• High Availability
• Fault Tolerance
• Self-Healing
• Replication
• Erasure Coding
• Block Storage
• Object Storage
• File Storage
• پشتیبانی مناسب برای Cloud و Virtualization

این ویژگی‌ها باعث شده‌اند Ceph در بسیاری از زیرساخت‌های بزرگ به عنوان Storage Backend مورد استفاده قرار بگیرد.

Ceph چگونه کار می‌کند؟

برای درک Ceph باید ابتدا با مفهوم Distributed Storage آشنا شویم.

در Storage سنتی، ممکن است یک سیستم مرکزی مسئول مدیریت Diskها و ارائه Storage باشد.

اما در Ceph، Storage بین چندین Node توزیع می‌شود.

                  Client
                     │
                     ▼
              Ceph Storage
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
      OSD 1        OSD 2        OSD 3
        │            │            │
       Disk         Disk         Disk

Ceph داده‌ها را به صورت هوشمند بین OSDهای مختلف توزیع می‌کند و با استفاده از مکانیزم‌هایی مانند CRUSH مشخص می‌کند هر داده باید روی کدام OSD قرار بگیرد.

RADOS؛ قلب Ceph

در معماری Ceph، یکی از مهم‌ترین مفاهیم RADOS یا Reliable Autonomic Distributed Object Store است.

RADOS لایه اصلی Distributed Storage در Ceph است.

سرویس‌های مختلف Ceph در نهایت روی RADOS قرار می‌گیرند.

             Ceph Services
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
      RBD       CephFS      RGW
       │          │          │
       └──────────┼──────────┘
                  ▼
                RADOS
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
      OSD        OSD        OSD

به زبان ساده، می‌توان RADOS را موتور اصلی ذخیره‌سازی Ceph دانست و RBD، CephFS و RGW را Interfaceهای مختلفی در نظر گرفت که Storage را برای کاربردهای متفاوت ارائه می‌کنند.

معماری Ceph

یک Ceph Cluster از چندین Component اصلی تشکیل شده است.

                    Clients
                       │
          ┌────────────┼────────────┐
          ▼            ▼            ▼
         RBD          CephFS        RGW
          │            │            │
          └────────────┼────────────┘
                       ▼
                     RADOS
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
      OSDs            MONs            MGR
        │
        ▼
      Disks

مهم‌ترین اجزای Ceph عبارت‌اند از:

• Ceph OSD
• Ceph MON
• Ceph Manager
• Ceph MDS
• RADOS
• CRUSH
• Pool

البته همه این Componentها در تمام Use Caseها الزاماً مورد استفاده قرار نمی‌گیرند.

Ceph OSD چیست؟

OSD مخفف Object Storage Daemon است و یکی از مهم‌ترین اجزای Ceph محسوب می‌شود.

OSD مسئول ذخیره‌سازی واقعی داده‌ها روی Storage Device و مدیریت بسیاری از عملیات مربوط به آن است.

OSD
 │
 ├── Store Data
 ├── Replication
 ├── Recovery
 ├── Rebalancing
 └── Health Reporting
      │
      ▼
     Disk

در یک Cluster واقعی معمولاً تعداد زیادی OSD وجود دارد.

برای مثال:

Server 1
 ├── OSD.0
 ├── OSD.1
 └── OSD.2

Server 2
 ├── OSD.3
 ├── OSD.4
 └── OSD.5

Server 3
 ├── OSD.6
 ├── OSD.7
 └── OSD.8

هر OSD معمولاً با یک Storage Device یا ساختار مشخصی از Storage مرتبط است.

چرا OSD مهم است؟

در بسیاری از معماری‌های Ceph، افزایش تعداد OSDها به افزایش ظرفیت Storage و در شرایط مناسب به افزایش Parallelism و Performance کمک می‌کند.

به همین دلیل Ceph بیشتر از اینکه روی یک Storage Controller قدرتمند متکی باشد، از تعداد زیادی Storage Node و OSD برای ساخت یک سیستم Distributed استفاده می‌کند.

Ceph MON چیست؟

MON یا Monitor مسئول نگهداری اطلاعات مربوط به وضعیت و Membership کلاستر است.

MONها اطلاعات مهمی درباره وضعیت Cluster و Mapهای مختلف Ceph نگهداری می‌کنند.

در یک Cluster Production معمولاً چند MON استفاده می‌شود تا در صورت از دست رفتن یک Node، سرویس Management همچنان در دسترس باشد.

             Ceph Cluster
                  │
        ┌─────────┼─────────┐
        ▼         ▼         ▼
      MON.1     MON.2     MON.3
        │         │         │
        └─────────┼─────────┘
                  ▼
             Cluster State

برای داشتن Quorum، تعداد فردی MONها در بسیاری از طراحی‌ها انتخاب می‌شود؛ برای مثال ۳ یا ۵ Monitor.

Ceph Manager چیست؟

Ceph Manager یا MGR مسئول ارائه سرویس‌های مدیریتی و Monitoring-related functionality در Ceph است.

MGR می‌تواند اطلاعات مربوط به Performance و وضعیت Cluster را در اختیار ابزارهای مدیریتی و Monitoring قرار دهد.

             Ceph Cluster
                  │
                  ▼
                MGR
             ┌────┼────┐
             ▼    ▼    ▼
          Metrics CLI Dashboard

Ceph Metadata Server چیست؟

Metadata Server یا MDS عمدتاً در زمانی مورد استفاده قرار می‌گیرد که از CephFS استفاده می‌کنیم.

MDS مسئول مدیریت Metadata مربوط به File System است.

             CephFS Client
                   │
          ┌────────┴────────┐
          ▼                 ▼
        MDS               RADOS
          │                 │
     Metadata             Data

در CephFS، داده‌های فایل و Metadata فایل دو مفهوم متفاوت هستند و MDS نقش مهمی در مدیریت Metadata دارد.

CRUSH در Ceph چیست؟

یکی از مهم‌ترین تکنولوژی‌های Ceph، الگوریتم CRUSH است.

CRUSH مخفف Controlled Replication Under Scalable Hashing است.

وظیفه اصلی CRUSH این است که مشخص کند داده‌ها در کدام OSDها قرار بگیرند، بدون اینکه برای هر Object نیاز باشد یک Lookup Table عظیم روی یک Controller مرکزی نگهداری شود.

Object
  │
  ▼
CRUSH Algorithm
  │
  ├──────────────┐
  ▼              ▼
OSD.12         OSD.37
  │              │
  ▼              ▼
Disk           Disk

این طراحی یکی از دلایل مهم Scalability بالای Ceph است.

چرا CRUSH مهم است؟

فرض کنید یک Storage Cluster شامل صدها OSD داشته باشیم.

اگر یک Controller مرکزی مسئول نگهداری Mapping تمام Objectها باشد، با افزایش Cluster پیچیدگی زیادی ایجاد می‌شود.

Ceph با استفاده از CRUSH می‌تواند Placement داده را به شکل Distributed و Algorithmic انجام دهد.

همچنین CRUSH می‌تواند اطلاعات Topology را در نظر بگیرد.

برای مثال می‌توان مشخص کرد Replicaهای یک داده روی یک Server واحد قرار نگیرند.

              Pool
               │
        ┌──────┼──────┐
        ▼      ▼      ▼
     Server A Server B Server C
        │      │      │
       OSD    OSD    OSD

این موضوع در برابر خرابی Server یا Rack اهمیت بسیار زیادی دارد.

Ceph Pool چیست؟

در Ceph، داده‌ها معمولاً داخل Poolها ذخیره می‌شوند.

Pool را می‌توان یک فضای منطقی برای مدیریت داده‌ها و Policyهای مربوط به آن‌ها در نظر گرفت.

Ceph Cluster
     │
     ├── Pool: VMs
     │
     ├── Pool: Databases
     │
     ├── Pool: Kubernetes
     │
     └── Pool: Backups

هر Pool می‌تواند Policyهای متفاوتی داشته باشد؛ برای مثال نوع Replication یا Erasure Coding.

Replication در Ceph

یکی از روش‌های محافظت از داده در Ceph، Replication است.

فرض کنید Replication Size برابر ۳ باشد.

در این حالت یک داده در سه Replica ذخیره می‌شود.

Original Object
      │
      ├──────► OSD 1
      │
      ├──────► OSD 5
      │
      └──────► OSD 9

اگر یکی از OSDها از دست برود، Replicaهای دیگر همچنان می‌توانند در دسترس باشند و Ceph می‌تواند فرآیند Recovery را انجام دهد.

مزیت Replication چیست؟

Replication طراحی Storage را ساده و قابل فهم می‌کند و برای بسیاری از Workloadهای حساس گزینه مناسبی است.

اما یک نکته مهم وجود دارد: اگر Replication Size برابر ۳ باشد، برای ذخیره ۱۰۰ ترابایت داده خام، تقریباً به ظرفیت خام بسیار بیشتری نیاز خواهیم داشت.

بنابراین Replication از نظر Capacity Efficiency بهترین انتخاب برای همه Workloadها نیست.

Erasure Coding در Ceph

Ceph از Erasure Coding نیز پشتیبانی می‌کند.

در Erasure Coding داده به Data Chunkها و Coding Chunkها تقسیم می‌شود.

              Data
               │
               ▼
        Erasure Coding
               │
       ┌───────┼───────┐
       ▼       ▼       ▼
      D1      D2      D3
       │       │       │
       └───────┼───────┘
               │
          Coding Chunks
             C1  C2

مزیت اصلی Erasure Coding این است که می‌تواند نسبت به Replication، استفاده بهینه‌تری از ظرفیت Storage داشته باشد.

در مقابل، پیچیدگی محاسباتی آن بیشتر است و برای هر Workloadی بهترین گزینه نیست.

Replication یا Erasure Coding؟

Ceph چه نوع Storageهایی ارائه می‌دهد؟

یکی از جذاب‌ترین ویژگی‌های Ceph این است که می‌تواند چند نوع Storage Interface مختلف ارائه کند.

سه سرویس مهم عبارت‌اند از:

• RBD برای Block Storage
• CephFS برای File Storage
• RGW برای Object Storage

                      Ceph
                       │
             ┌─────────┼─────────┐
             ▼         ▼         ▼
            RBD      CephFS     RGW
             │         │         │
           Block      File      Object
          Storage    Storage    Storage

Ceph RBD چیست؟

RBD یا RADOS Block Device یکی از مهم‌ترین قابلیت‌های Ceph برای Virtualization و Cloud است.

RBD یک Block Device مجازی ارائه می‌کند که روی RADOS قرار دارد.

Virtual Machine
      │
      ▼
    RBD
      │
      ▼
   RADOS
      │
      ▼
   Ceph OSDs

این قابلیت باعث شده Ceph در OpenStack، Proxmox و سایر Virtualization Platformها بسیار محبوب باشد.

CephFS چیست؟

CephFS یک Distributed File System است که Storage آن روی RADOS قرار می‌گیرد.

کاربر یا Application می‌تواند آن را مانند یک File System در اختیار داشته باشد.

Client
  │
  ▼
CephFS
  │
  ├── Metadata → MDS
  │
  └── Data ───► RADOS
                    │
                    ▼
                   OSDs

CephFS برای Workloadهایی که به Shared File System نیاز دارند کاربرد دارد.

Ceph RGW چیست؟

RGW یا RADOS Gateway لایه Object Storage در Ceph است.

RGW می‌تواند Interfaceهای Object Storage مانند S3 را در اختیار Applicationها قرار دهد.

Application
     │
     ▼
 S3 / Object API
     │
     ▼
    RGW
     │
     ▼
   RADOS
     │
     ▼
    OSDs

به همین دلیل Ceph می‌تواند در معماری‌هایی که نیاز به Object Storage دارند نیز مورد استفاده قرار گیرد.

Ceph در OpenStack

یکی از معروف‌ترین کاربردهای Ceph، استفاده از آن به عنوان Storage Backend در OpenStack است.

OpenStack می‌تواند برای VMها از Ceph RBD استفاده کند.

                 OpenStack
                     │
       ┌─────────────┼─────────────┐
       ▼             ▼             ▼
     Nova          Cinder        Glance
       │             │             │
       └─────────────┼─────────────┘
                     ▼
                  Ceph RBD
                     │
                     ▼
                   RADOS

در چنین معماری‌ای Ceph می‌تواند Storage مشترک موردنیاز یک Private Cloud را فراهم کند.

این موضوع برای معماری‌های Enterprise که چندین Compute Node دارند بسیار مهم است.

چرا Ceph برای OpenStack مناسب است؟

• Shared Storage
• High Availability
• Horizontal Scalability
• Block Storage با RBD
• Object Storage با RGW
• پشتیبانی از Snapshot
• قابلیت Replication
• Integration مناسب با Cloud Platforms

برای مثال اگر یک VM روی Compute Node شماره ۱ اجرا شود و سپس روی Compute Node دیگری منتقل شود، وجود Shared Storage می‌تواند این معماری را بسیار ساده‌تر کند.

Ceph در Kubernetes

Ceph در Kubernetes نیز کاربرد بسیار مهمی دارد.

یکی از راهکارهای معروف برای مدیریت Ceph در Kubernetes، Rook است.

                 Kubernetes
                     │
                     ▼
                    Rook
                     │
                     ▼
                 Ceph Cluster
                     │
          ┌──────────┼──────────┐
          ▼          ▼          ▼
         RBD       CephFS       RGW
          │          │           │
          ▼          ▼           ▼
         PVC        PVC       Object API

Rook می‌تواند Lifecycle و مدیریت Ceph را در محیط Kubernetes ساده‌تر کند.

در این معماری Kubernetes می‌تواند از Ceph به عنوان Storage Platform استفاده کند و از طریق CSI قابلیت‌هایی مانند Persistent Volume را در اختیار Applicationها قرار دهد.

Ceph و Persistent Volume در Kubernetes

برای Applicationهایی که نیاز به Persistent Storage دارند، Ceph می‌تواند یک Storage Backend قدرتمند باشد.

Pod
 │
 ▼
PersistentVolumeClaim
 │
 ▼
CSI
 │
 ▼
Ceph RBD
 │
 ▼
Ceph Cluster

در این معماری، حذف یا جابه‌جایی Pod لزوماً به معنی از بین رفتن داده نیست و Storage Lifecycle از Application Lifecycle جدا می‌شود.

Ceph در Proxmox

Ceph یکی از Storageهای محبوب در محیط‌های Proxmox VE نیز محسوب می‌شود.

Proxmox می‌تواند با Ceph یک Virtualization Cluster با Shared Distributed Storage ایجاد کند.

             Proxmox Cluster
       ┌────────┬────────┬────────┐
       ▼        ▼        ▼        ▼
     Node 1   Node 2   Node 3   Node 4
       │        │        │        │
       └────────┴────────┴────────┘
                    │
                    ▼
                 Ceph
                    │
                    ▼
             Distributed Storage

این ترکیب برای ساخت Private Cloudهای کوچک و متوسط و همچنین برخی محیط‌های Enterprise بسیار کاربردی است.

Ceph در Private Cloud

یکی از مهم‌ترین کاربردهای Ceph، ساخت Storage Layer برای Private Cloud است.

                  Private Cloud
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
     Compute         Network        Storage
        │                              │
        │                              ▼
        │                            Ceph
        │                              │
        └──────────────────────────────┘

در این معماری، Compute Layer و Storage Layer می‌توانند تا حد زیادی مستقل از یکدیگر Scale شوند.

این موضوع برای سازمان‌هایی که به دنبال زیرساخت Private Cloud قابل توسعه هستند اهمیت زیادی دارد.

مزایای اصلی Ceph

۱. Scalability

یکی از مهم‌ترین مزایای Ceph قابلیت Scale کردن Storage با اضافه کردن Node و OSD است.

۲. High Availability

داده‌ها می‌توانند بین چندین Node توزیع و Replicate شوند تا خرابی یک Component باعث از دست رفتن Storage نشود.

۳. Software-Defined Storage

Ceph می‌تواند روی Serverهای استاندارد اجرا شود و Storage را به صورت Software-Defined ارائه کند.

۴. چند نوع Storage

یک Cluster می‌تواند برای Block، File و Object Storage استفاده شود.

۵. Open Source

Ceph یک پروژه Open Source است و امکان طراحی و مدیریت Storage بدون وابستگی کامل به یک Storage Vendor خاص را فراهم می‌کند.

۶. Self-Healing

Ceph می‌تواند در بسیاری از سناریوهای خرابی، فرآیند Recovery و Rebalancing را به صورت خودکار انجام دهد.

۷. Integration با Cloud و Virtualization

پشتیبانی و Integration با Platformهایی مانند OpenStack، Kubernetes و Proxmox باعث شده Ceph در معماری‌های Cloud بسیار محبوب شود.

برای راه‌اندازی Ceph به چه سخت‌افزاری نیاز داریم؟

یکی از اشتباهات رایج این است که تصور کنیم چون Ceph یک Software-Defined Storage است، بنابراین روی هر سخت‌افزاری می‌توان آن را با Performance مناسب اجرا کرد. در واقع Ceph به شدت به کیفیت سخت‌افزار، Storage Deviceها و مخصوصاً شبکه وابسته است.

یک Ceph Cluster می‌تواند روی Serverهای معمولی اجرا شود، اما برای محیط Production باید طراحی سخت‌افزار بر اساس نوع Workload، ظرفیت موردنیاز، سطح Availability و Performance هدف انجام شود.

اجزای اصلی سخت‌افزاری Ceph

در یک طراحی معمول Ceph، اجزای زیر اهمیت زیادی دارند:

• CPU
• RAM
• SSD یا NVMe برای OSD
• HDD در صورت نیاز به Capacity بالا
• Network Interface
• Network Switch
• Boot Device
• Power و Redundancy

CPU در Ceph

مصرف CPU در Ceph به نوع Workload و نحوه استفاده از Storage بستگی دارد.

Replication معمولاً نسبت به Erasure Coding سربار محاسباتی کمتری دارد، در حالی که Erasure Coding و برخی عملیات Recovery می‌توانند CPU بیشتری مصرف کنند.

اگر Cluster برای Virtual Machineهای متعدد، Databaseها یا Workloadهای سنگین استفاده شود، CPU کافی برای OSDها و سایر سرویس‌های Ceph باید در نظر گرفته شود.

RAM در Ceph

RAM نیز یکی از منابع مهم Ceph است و نباید صرفاً بر اساس ظرفیت Disk محاسبه شود.

مصرف Memory به تعداد OSDها، نسخه Ceph، Configuration و نوع Workload بستگی دارد.

به همین دلیل برای طراحی Production بهتر است ظرفیت RAM بر اساس تعداد OSD و نوع استفاده واقعی Cluster محاسبه و با Benchmark و Monitoring اعتبارسنجی شود.

SSD یا HDD؛ کدام برای Ceph بهتر است؟

Ceph می‌تواند از HDD، SSD و NVMe استفاده کند؛ اما انتخاب Storage Device باید بر اساس Workload انجام شود.

برای مثال اگر هدف شما ساخت یک Storage Backend برای تعداد زیادی Virtual Machine باشد، استفاده از HDDهای معمولی ممکن است از نظر IOPS و Latency محدودیت ایجاد کند.

از طرف دیگر، برای یک Archive بزرگ که بیشتر روی Capacity تمرکز دارد، استفاده از NVMe برای تمام داده‌ها ممکن است از نظر اقتصادی منطقی نباشد.

Enterprise SSD در Ceph چرا مهم است؟

یکی از نکات مهم در Storageهای Production، توجه به Endurance و DWPD است.

هر SSD برای Workload سنگین Storage مناسب نیست.

در محیطی که تعداد زیادی VM، Database یا Container روی Ceph قرار دارند، Write Workload می‌تواند قابل توجه باشد.

بنابراین بهتر است از SSDهای Enterprise با Endurance مناسب استفاده شود.

BlueStore در Ceph

در معماری‌های جدید Ceph، OSDها معمولاً از BlueStore برای ذخیره‌سازی استفاده می‌کنند.

BlueStore مستقیماً با Block Device کار می‌کند و برای Workloadهای Storage طراحی شده است.

در طراحی OSD ممکن است علاوه بر Data Device، از Deviceهای سریع‌تر برای برخی Metadata یا Write-Ahead Log نیز استفاده شود.

            Ceph OSD

       ┌─────────────────┐
       │    BlueStore    │
       └────────┬────────┘
                │
       ┌────────┼─────────┐
       ▼        ▼         ▼
     Data      DB        WAL
      │        │          │
      ▼        ▼          ▼
     HDD      SSD        SSD

این معماری می‌تواند در برخی سناریوهای HDD-based، Performance را بهبود دهد؛ البته انتخاب درست Device و Configuration بسیار مهم است.

شبکه در Ceph چقدر اهمیت دارد؟

اگر بخواهیم فقط یک نکته سخت‌افزاری را به عنوان یکی از مهم‌ترین عوامل موفقیت Ceph انتخاب کنیم، شبکه قطعاً در صدر فهرست قرار می‌گیرد.

Ceph یک Distributed Storage است و مقدار قابل توجهی از Traffic آن بین Nodeها جابه‌جا می‌شود.

              Ceph Cluster

        ┌───────────────┐
        │    Server 1   │
        └───────┬───────┘
                │
                │ Replication
                │ Recovery
                │ Rebalance
                │
        ┌───────┴───────┐
        │    Network    │
        └───────┬───────┘
                │
        ┌───────┴───────┐
        │               │
   Server 2         Server 3

هرچه Storage سریع‌تر باشد، اهمیت Network بیشتر می‌شود؛ زیرا اگر شبکه نتواند داده را با سرعت کافی منتقل کند، Storage Deviceهای سریع نمی‌توانند تمام ظرفیت Performance خود را نشان دهند.

Public Network و Cluster Network در Ceph

در طراحی‌های Ceph می‌توان Trafficهای مختلف را از یکدیگر جدا کرد.

به صورت مفهومی دو نوع Traffic مهم داریم:

• Client/Public Traffic
• Cluster/Backend Traffic

                Clients
                   │
                   │
             Public Network
                   │
        ┌──────────┼──────────┐
        ▼          ▼          ▼
     Ceph Node  Ceph Node  Ceph Node
        │          │          │
        └──────────┼──────────┘
                   │
             Cluster Network
                   │
        Replication / Recovery

جدا کردن این Trafficها می‌تواند در برخی معماری‌ها باعث کنترل بهتر Congestion و افزایش Predictability شود.

البته در نسخه‌ها و معماری‌های جدید Ceph می‌توان از یک Network با ظرفیت مناسب نیز استفاده کرد و الزام به دو Network مستقل در همه Deploymentها وجود ندارد.

آیا 1Gbps برای Ceph کافی است؟

برای بسیاری از محیط‌های Production، شبکه 1Gbps انتخاب مناسبی برای Ceph نیست.

ممکن است Cluster با 1Gbps کار کند، اما Replication، Recovery و Client Traffic به سرعت می‌توانند Bandwidth را اشباع کنند.

در بسیاری از طراحی‌های جدید، حداقل 10Gbps برای Network در نظر گرفته می‌شود و برای Workloadهای سنگین‌تر استفاده از 25Gbps، 40Gbps یا حتی 100Gbps نیز کاملاً قابل بررسی است.

عدد مناسب باید بر اساس تعداد OSD، نوع Disk، تعداد Clientها و Workload واقعی تعیین شود.

چرا شبکه سریع‌تر برای NVMe مهم‌تر است؟

فرض کنید Storage شما از NVMeهای بسیار سریع تشکیل شده است اما Network فقط 10Gbps ظرفیت دارد.

در این شرایط ممکن است Network به Bottleneck تبدیل شود.

Fast NVMe
    │
    ▼
High IOPS
    │
    ▼
   Network
    │
    ▼
  Bottleneck

بنابراین طراحی Ceph باید به صورت End-to-End انجام شود و نمی‌توان Storage، CPU و Network را جدا از یکدیگر طراحی کرد.

Ceph چند Node نیاز دارد؟

از نظر فنی Ceph می‌تواند در محیط‌های کوچک‌تر نیز اجرا شود، اما برای Production و High Availability معمولاً باید چندین Node در نظر گرفته شود.

برای مثال یک معماری رایج می‌تواند شامل سه Storage Node باشد:

       Ceph Node 1
       ┌──────────┐
       │ OSD OSD  │
       │ MON MGR  │
       └────┬─────┘
            │
       ┌────┴─────┐
       │ Network  │
       └────┬─────┘
            │
    ┌───────┴────────┐
    │                │
┌───▼────┐      ┌────▼───┐
│Node 2  │      │Node 3  │
│OSD OSD │      │OSD OSD │
│MON     │      │MON     │
└────────┘      └────────┘

این معماری امکان تحمل برخی Failureها و ایجاد Quorum برای سرویس‌های مدیریتی را فراهم می‌کند.

آیا می‌توان Ceph را روی یک Node اجرا کرد؟

برای Lab، Development یا یادگیری می‌توان Ceph را روی یک سیستم یا حتی یک Virtual Machine اجرا کرد.

اما چنین معماری‌ای را نباید با یک Ceph Cluster Production مقایسه کرد.

اگر تمام OSDها، MONها و Network روی یک Host قرار داشته باشند، خرابی همان Host می‌تواند کل Storage را از دسترس خارج کند.

معماری پیشنهادی Ceph برای Production

برای یک Cluster کوچک Production می‌توان از سه Storage Node شروع کرد.

              10/25GbE Network

        ┌────────┐ ┌────────┐ ┌────────┐
        │ Node 1 │ │ Node 2 │ │ Node 3 │
        │        │ │        │ │        │
        │ MON    │ │ MON    │ │ MON    │
        │ MGR    │ │ MGR    │ │ MGR    │
        │ OSDs   │ │ OSDs   │ │ OSDs   │
        └────────┘ └────────┘ └────────┘
             │          │          │
             └──────────┼──────────┘
                        │
                    Ceph Cluster

در محیط‌های بزرگ‌تر می‌توان Roleها را از یکدیگر جدا کرد و تعداد بیشتری Storage Node در نظر گرفت.

Failure Domain در Ceph چیست؟

یکی از مفاهیم بسیار مهم در طراحی Ceph، Failure Domain است.

اگر سه Replica از یک داده روی سه OSD مختلف قرار داشته باشند اما هر سه OSD روی یک Server باشند، خرابی Server می‌تواند هر سه Replica را از بین ببرد.

Bad Design:

Server 1
 ├── OSD 1
 ├── OSD 2
 └── OSD 3

Replica 1 ─► OSD 1
Replica 2 ─► OSD 2
Replica 3 ─► OSD 3

Server 1 DOWN
      │
      ▼
All Replicas LOST

در طراحی صحیح، Replicaها باید تا حد امکان در Failure Domainهای مستقل قرار بگیرند.

Good Design:

Server 1 ──► Replica 1
Server 2 ──► Replica 2
Server 3 ──► Replica 3

Server 1 DOWN
      │
      ▼
Replica 2 + Replica 3
      │
      ▼
Data Available

Failure Domain می‌تواند Server، Rack یا حتی Data Center باشد؛ البته انتخاب سطح مناسب به Architecture و هدف Availability بستگی دارد.

Ceph و Rack Awareness

در Data Centerهای بزرگ، ممکن است چند Server در یک Rack قرار داشته باشند.

اگر Power یا Network یک Rack از دست برود، تمام Serverهای داخل آن ممکن است همزمان Fail شوند.

به همین دلیل می‌توان CRUSH Hierarchy را طوری طراحی کرد که Replicaها بین Rackهای مختلف توزیع شوند.

                Ceph Cluster
                     │
        ┌────────────┴────────────┐
        ▼                         ▼
      Rack 1                    Rack 2
     ┌───────┐                  ┌───────┐
     │Node A │                  │Node D │
     │Node B │                  │Node E │
     │Node C │                  │Node F │
     └───────┘                  └───────┘

Ceph و چند دیتاسنتر

در معماری‌های Multi-Data Center باید با احتیاط بسیار بیشتری Ceph را طراحی کرد.

قرار دادن یک Cluster واحد Ceph روی چند Data Center با Latency و Failure Domain متفاوت همیشه تصمیم مناسبی نیست.

Replication بین Data Centerها می‌تواند به Network، Latency و Bandwidth زیادی نیاز داشته باشد.

برای Disaster Recovery معمولاً باید معماری Replication و Failure Domain بر اساس نیاز واقعی کسب‌وکار طراحی شود و نباید صرفاً تصور کرد که «Ceph خودش Multi-Data Center است».

Ceph و High Availability

High Availability در Ceph فقط به معنی داشتن چند Server نیست.

باید چندین لایه Failure را در نظر گرفت:

• Disk Failure
• OSD Failure
• Server Failure
• Network Failure
• Rack Failure
• Power Failure
• MON Failure
• Storage Device Failure

طراحی مناسب Ceph باید مشخص کند در برابر هر یک از این Failureها چه اتفاقی رخ می‌دهد.

Ceph چگونه با خرابی Disk برخورد می‌کند؟

فرض کنید یکی از Diskهای Cluster خراب شود و OSD مربوط به آن از دسترس خارج شود.

Before:

OSD 1 ── Replica
OSD 2 ── Replica
OSD 3 ── Replica

OSD 2 FAILED
       │
       ▼
Ceph detects failure
       │
       ▼
Recovery / Rebalancing
       │
       ▼
New Replica created

Ceph وضعیت Cluster را بررسی می‌کند و در صورت نیاز Recovery را آغاز می‌کند تا Redundancy موردنظر دوباره برقرار شود.

Recovery در Ceph چیست؟

Recovery فرآیندی است که طی آن Ceph تلاش می‌کند داده‌هایی را که به دلیل Failure از دست رفته‌اند یا ناقص شده‌اند دوباره به وضعیت مطلوب برگرداند.

برای مثال اگر یک Replica از بین برود:

Replication = 3

Before:
Replica 1
Replica 2
Replica 3

Failure:
Replica 2 LOST

Recovery:
Replica 1
Replica 3
Replica 4 ← New Replica

Recovery فرآیندی بسیار مهم است، اما می‌تواند مقدار زیادی Network و Disk I/O مصرف کند.

Recovery Storm چیست؟

یکی از مشکلاتی که در طراحی Ceph باید به آن توجه کرد، تأثیر Recovery روی Performance Cluster است.

اگر تعداد زیادی OSD همزمان از دسترس خارج شوند یا یک Node بزرگ Fail شود، Ceph ممکن است حجم زیادی از داده را جابه‌جا کند.

Node Failure
     │
     ▼
Many PGs affected
     │
     ▼
Recovery starts
     │
     ├──► Network Traffic ↑
     ├──► Disk I/O ↑
     └──► Client Latency ↑

به همین دلیل Recovery و Backfill باید با توجه به Workload و ظرفیت Hardware تنظیم و Monitoring شوند.

Ceph و Placement Group یا PG چیست؟

یکی از مفاهیم کلیدی Ceph، Placement Group یا PG است.

PGها یک لایه منطقی بین Objectها و OSDها ایجاد می‌کنند و نقش مهمی در توزیع و مدیریت داده دارند.

Pool
 │
 ├── PG 1
 │    ├── OSD 1
 │    ├── OSD 4
 │    └── OSD 7
 │
 ├── PG 2
 │    ├── OSD 2
 │    ├── OSD 5
 │    └── OSD 8
 │
 └── PG 3
      ├── OSD 3
      ├── OSD 6
      └── OSD 9

PGها به Ceph کمک می‌کنند Objectها را در مقیاس بزرگ‌تر مدیریت و بین OSDها توزیع کند.

چرا تعداد PGها مهم است؟

تعداد PGها باید متناسب با تعداد OSDها، Poolها و اندازه Cluster انتخاب شود.

PG بسیار کم می‌تواند باعث توزیع نامناسب داده شود و PG بیش از حد نیز می‌تواند Overhead مدیریتی ایجاد کند.

در نسخه‌های جدید Ceph ابزارها و Mechanismهای مختلفی برای مدیریت بهتر PG وجود دارند و بهتر است تعداد PGها با توجه به توصیه‌های همان نسخه و وضعیت واقعی Cluster تعیین شود.

Ceph Rebalancing چیست؟

وقتی OSD جدیدی به Cluster اضافه می‌شود، Ceph ممکن است داده‌ها را دوباره توزیع کند تا Load بین OSDها متعادل‌تر شود.

Before:

OSD1 ██████████
OSD2 █████████
OSD3 ██████████

Add OSD4

After Rebalance:

OSD1 ███████
OSD2 ███████
OSD3 ███████
OSD4 ███████

این ویژگی یکی از دلایل مهم قابلیت Scale افقی Ceph است.

Scale کردن Ceph چگونه انجام می‌شود؟

فرض کنید Cluster شما با سه Node شروع شده است:

Node 1
Node 2
Node 3

اگر ظرفیت بیشتری نیاز داشته باشید، می‌توانید Node جدید اضافه کنید:

Node 1
Node 2
Node 3
Node 4  ← New

پس از اضافه شدن OSDهای جدید، Ceph می‌تواند داده‌ها را بر اساس CRUSH و وضعیت Cluster مجدداً توزیع کند.

این مدل با افزایش یک Storage Appliance واحد متفاوت است و نمونه‌ای از Horizontal Scaling محسوب می‌شود.

آیا Ceph واقعاً بدون Single Point of Failure است؟

Ceph برای جلوگیری از Single Point of Failure طراحی شده است، اما این موضوع فقط در صورتی محقق می‌شود که Cluster به شکل صحیح طراحی شده باشد.

برای مثال اگر سه MON داشته باشیم اما هر سه روی یک Server قرار گرفته باشند، از نظر Availability هنوز یک Failure Domain واحد داریم.

Wrong:

Server 1
 ├── MON 1
 ├── MON 2
 └── MON 3

Server 1 FAILED
       │
       ▼
All MONs FAILED

طراحی بهتر:

Server 1 ── MON 1
Server 2 ── MON 2
Server 3 ── MON 3

Server 1 FAILED
       │
       ▼
MON 2 + MON 3
       │
       ▼
Quorum Available

Ceph Performance به چه عواملی بستگی دارد؟

Performance نهایی Ceph حاصل ترکیب چندین عامل است:

• نوع Storage Device
• تعداد OSDها
• CPU
• RAM
• Network Bandwidth
• Network Latency
• Replication یا Erasure Coding
• نوع Workload
• اندازه Requestها
• Read/Write Ratio
• Recovery و Backfill
• Configuration

به همین دلیل نمی‌توان صرفاً با گفتن «Ceph سریع است» یا «Ceph کند است» درباره Performance آن قضاوت کرد.

Ceph برای Database مناسب است؟

بله، اما پاسخ دقیق به نوع Database و Workload بستگی دارد.

Databaseهایی که IOPS بالا و Latency بسیار پایین نیاز دارند، به Storage و Network مناسب نیاز دارند.

اگر Ceph با NVMeهای مناسب، Network سریع و Configuration صحیح طراحی شود، می‌تواند برای بسیاری از Database Workloadها مناسب باشد.

اما استفاده از Ceph به این معنی نیست که هر Database روی هر Ceph Cluster الزاماً Performance مناسبی خواهد داشت.

Ceph برای Virtual Machine مناسب است؟

بله. این یکی از مهم‌ترین کاربردهای Ceph است.

RBD می‌تواند Block Storage موردنیاز Virtual Machineها را فراهم کند و در کنار Virtualization Platformهایی مانند OpenStack و Proxmox استفاده شود.

VM
 │
 ▼
Virtual Disk
 │
 ▼
Ceph RBD
 │
 ▼
RADOS
 │
 ▼
Multiple OSDs

مزیت مهم این معماری این است که Virtual Disk به یک Server فیزیکی خاص وابسته نیست.

Ceph در مقایسه با SAN و NAS

یکی از رایج‌ترین سوالات هنگام بررسی Ceph این است که چرا باید به جای یک SAN یا NAS از Ceph استفاده کنیم؟

پاسخ ساده‌ای وجود ندارد، زیرا این تکنولوژی‌ها برای تمام سناریوها جایگزین مستقیم یکدیگر نیستند. با این حال، مقایسه آن‌ها می‌تواند به انتخاب معماری مناسب کمک کند.

یکی از تفاوت‌های مهم Ceph با Storage Applianceهای سنتی این است که در Ceph مسئولیت طراحی، Deployment، Monitoring و نگهداری تا حد زیادی بر عهده تیم Infrastructure قرار می‌گیرد.

در مقابل، بسیاری از SAN و NASهای Enterprise به صورت یک محصول یکپارچه ارائه می‌شوند و Vendor مسئول بخش بزرگی از طراحی Hardware و Software است.

Ceph در مقابل VMware vSAN

VMware vSAN و Ceph هر دو می‌توانند از Storageهای داخل چند Server برای ساخت یک Distributed Storage استفاده کنند، اما فلسفه و اکوسیستم آن‌ها متفاوت است.

اگر سازمانی عمدتاً در اکوسیستم VMware قرار دارد، vSAN می‌تواند گزینه طبیعی‌تری باشد. اما اگر هدف ساخت یک Storage Platform مستقل و چندمنظوره برای OpenStack، کوبرنتیس، Virtualization و Object Storage باشد، Ceph انعطاف‌پذیری بسیار بیشتری ارائه می‌کند.

Ceph در مقابل GlusterFS

GlusterFS نیز یکی از پروژه‌های شناخته‌شده Open Source در حوزه Distributed Storage است.

با این حال، معماری و Use Caseهای Ceph و GlusterFS تفاوت‌های مهمی دارند.

برای محیط‌هایی که نیاز اصلی File Storage ساده و Distributed است، ممکن است راهکارهای دیگری گزینه مناسب‌تری باشند؛ اما در معماری‌های Cloud که Block، Object و File Storage را همزمان نیاز دارند، Ceph مزیت قابل توجهی دارد.

آیا Ceph رایگان است؟

خود نرم‌افزار Ceph یک پروژه Open Source است و برای استفاده از Software آن نیاز به خرید License تجاری مشابه بسیاری از Storage Applianceها ندارید.

اما «رایگان بودن نرم‌افزار» به معنی رایگان بودن Storage نیست.

هزینه‌های واقعی Ceph می‌توانند شامل موارد زیر باشند:

• Server Hardware
• SSD و NVMe
• HDD
• Network Switch
• Network Interface
• Rack و Power
• Monitoring
• Backup Infrastructure
• Deployment
• Maintenance
• نیروی متخصص

در واقع در Ceph بخش قابل توجهی از هزینه از License به سمت Hardware و Expertise منتقل می‌شود.

آیا Ceph از SAN ارزان‌تر است؟

لزوماً نه.

در برخی محیط‌ها Ceph می‌تواند هزینه Storage را کاهش دهد، مخصوصاً زمانی که سازمان بتواند از Serverهای استاندارد و Hardware قابل تهیه استفاده کند.

اما اگر سازمان تیم متخصص Ceph نداشته باشد یا Workload آن بسیار حساس باشد، هزینه طراحی، نگهداری و Troubleshooting نیز باید در TCO محاسبه شود.

بنابراین مقایسه قیمت Ceph و SAN فقط با مقایسه قیمت Disk یا Server منطقی نیست و باید Total Cost of Ownership را در نظر گرفت.

ظرفیت واقعی Ceph را چگونه محاسبه کنیم؟

یکی از اشتباهات متداول در Capacity Planning این است که ظرفیت تمام Diskها را با یکدیگر جمع کنیم و همان عدد را به عنوان ظرفیت قابل استفاده Ceph در نظر بگیریم.

برای مثال فرض کنید سه Node داریم و روی هر Node چهار Disk هشت ترابایتی قرار گرفته است:

3 Nodes
×
4 Disks
×
8 TB

Raw Capacity = 96 TB

اما اگر Replication Size برابر ۳ باشد، تمام ۹۶ ترابایت قابل استفاده نخواهد بود.

Raw Capacity
     │
     ▼
Replication Overhead
     │
     ▼
Usable Capacity
     │
     ▼
Operational Reserve
     │
     ▼
Practical Capacity

علاوه بر Replication، باید فضای موردنیاز برای Recovery، Rebalancing و رشد آینده Cluster نیز در نظر گرفته شود.

چرا نباید Ceph را تا ۱۰۰٪ ظرفیت پر کنیم؟

Ceph برای عملکرد مناسب و مدیریت Failure به فضای آزاد نیاز دارد.

اگر Cluster بیش از حد پر شود، فضای کافی برای Recovery و Rebalancing باقی نمی‌ماند و مدیریت Failureها می‌تواند دشوارتر شود.

به همین دلیل در یک طراحی Production باید همیشه یک Capacity Reserve مناسب در نظر گرفته شود.

100% Capacity
│
├── ❌ Full
│
├── Operational Reserve
│
├── Recovery Reserve
│
└── Growth Reserve

یک سناریوی واقعی: Ceph برای Private Cloud

فرض کنیم یک سازمان قصد دارد یک Private Cloud برای اجرای حدود ۱۰۰ تا ۲۰۰ Virtual Machine ایجاد کند.

در این سناریو می‌توان معماری را به صورت زیر در نظر گرفت:

                    Users
                      │
                      ▼
               Private Cloud
                      │
        ┌─────────────┼─────────────┐
        ▼             ▼             ▼
      Compute       Network       Storage
        │                             │
        │                             ▼
        │                           Ceph
        │                    ┌────────┼────────┐
        │                    ▼        ▼        ▼
        │                  Node 1   Node 2   Node 3
        │
        ▼
      VMs

Compute Nodeها Virtual Machineها را اجرا می‌کنند و Ceph Storage مشترک موردنیاز VMها را فراهم می‌کند.

نمونه طراحی سه‌نودی Ceph

برای یک محیط کوچک تا متوسط می‌توان از سه Storage Node شروع کرد.

این اعداد صرفاً یک نمونه معماری هستند و نباید به عنوان یک Sizing عمومی برای تمام Clusterها در نظر گرفته شوند. Sizing واقعی باید بر اساس Capacity، IOPS، Throughput، نوع Workload و Failure Requirements انجام شود.

نمونه معماری OpenStack + Ceph

یکی از معماری‌های بسیار محبوب در Private Cloud، ترکیب OpenStack و Ceph است.

                    Users
                      │
                      ▼
                 OpenStack
                      │
       ┌──────────────┼──────────────┐
       ▼              ▼              ▼
      Nova          Cinder         Glance
       │              │              │
       └──────────────┼──────────────┘
                      ▼
                    Ceph
             ┌────────┼────────┐
             ▼        ▼        ▼
          Ceph-01  Ceph-02  Ceph-03

در این معماری، OpenStack مسئول مدیریت Cloud و Compute و Networking است و Ceph نقش Storage Platform را ایفا می‌کند.

نمونه معماری Kubernetes + Ceph

برای کوبرنتیس نیز می‌توان Ceph را به عنوان Storage Backend در نظر گرفت.

                Kubernetes Cluster
                       │
        ┌──────────────┼──────────────┐
        ▼              ▼              ▼
       Pod            Pod            Pod
        │              │              │
        └──────────────┼──────────────┘
                       ▼
                      CSI
                       │
                       ▼
                    RBD/FS
                       │
                       ▼
                     Ceph
              ┌────────┼────────┐
              ▼        ▼        ▼
            OSD      OSD      OSD

در این معماری Storage Lifecycle از Lifecycle خود Podها جدا می‌شود و Persistent Data می‌تواند مستقل از وضعیت یک Pod نگهداری شود.

Monitoring در Ceph

راه‌اندازی Ceph بدون Monitoring مناسب یکی از خطرناک‌ترین اشتباهات در محیط Production است.

حداقل باید وضعیت موارد زیر تحت نظر باشد:

• Cluster Health
• OSD Status
• MON Quorum
• PG State
• Capacity
• IOPS
• Throughput
• Latency
• Recovery
• Backfill
• Network Traffic
• Disk Health
• SMART Metrics

Ceph Dashboard

Ceph دارای Dashboard مدیریتی است که می‌تواند اطلاعات مختلفی از وضعیت Cluster، OSDها، Poolها و Performance را نمایش دهد.

+------------------------------------------------+
|              Ceph Dashboard                    |
+------------------------------------------------+
| Cluster Health: HEALTH_OK                      |
|                                                |
| OSDs:       24 / 24 UP                         |
| MONs:        3 / 3                             |
| PGs:        Active + Clean                     |
| Capacity:   42%                                |
|                                                |
| IOPS      █████████                             |
| Throughput ███████                             |
| Latency   ██                                    |
+------------------------------------------------+

در محیط‌های Enterprise معمولاً بهتر است Metrics مربوط به Ceph علاوه بر Dashboard داخلی، وارد سیستم Monitoring مرکزی مانند Prometheus و Grafana نیز شوند.

Ceph و Prometheus

در بسیاری از معماری‌های مدرن می‌توان Metrics مربوط به Ceph را با Prometheus جمع‌آوری و در Grafana نمایش داد.

Ceph
 │
 ▼
Metrics
 │
 ▼
Prometheus
 │
 ▼
Grafana
 │
 ├── Capacity
 ├── OSD Health
 ├── IOPS
 ├── Latency
 └── Recovery

این موضوع زمانی اهمیت بیشتری پیدا می‌کند که Ceph بخشی از یک Observability Platform بزرگ‌تر باشد.

Backup در Ceph

یکی از خطرناک‌ترین برداشت‌ها درباره Ceph این است که Replication را با Backup اشتباه بگیریم.

Replication برای افزایش Availability و تحمل Failure طراحی شده است، اما Backup برای بازیابی داده در برابر اتفاقاتی مانند حذف تصادفی، خرابی منطقی یا برخی سناریوهای Disaster طراحی می‌شود.

Replication
    │
    └──► Hardware / Node Failure

Backup
    │
    └──► Data Loss / Accidental Delete

اگر یک فایل یا VM به صورت اشتباه حذف شود، Replicaهای Ceph نیز ممکن است همان حذف را در Replicaهای دیگر اعمال کنند.

بنابراین حتی در یک Ceph Cluster بسیار High Available نیز داشتن Backup مستقل ضروری است.

Ceph و Disaster Recovery

High Availability و Disaster Recovery دو مفهوم متفاوت هستند.

High Availability معمولاً برای مقابله با Failureهای محدود در یک محیط طراحی می‌شود، در حالی که Disaster Recovery برای رخدادهای بزرگ‌تری مانند از دست رفتن کامل یک سایت یا Data Center در نظر گرفته می‌شود.

                Production Site
                      │
                    Ceph
                      │
             ┌────────┴────────┐
             │                 │
             ▼                 ▼
           Local HA         Backup / DR
                               │
                               ▼
                         Secondary Site

برای سناریوهای Disaster Recovery باید Replication، Backup و Data Protection بر اساس RPO و RTO موردنیاز سازمان طراحی شوند.

اشتباهات رایج در راه‌اندازی Ceph

Ceph یک Storage قدرتمند است، اما Configuration اشتباه می‌تواند Performance و Reliability آن را به شدت کاهش دهد.

اشتباه اول: استفاده از شبکه ضعیف

Ceph به Network وابستگی زیادی دارد. استفاده از شبکه‌ای که برای Workload موردنظر Bandwidth یا Latency کافی ندارد می‌تواند کل Cluster را تحت تأثیر قرار دهد.

اشتباه دوم: استفاده از SSDهای Consumer

SSDهای Consumer ممکن است برای Lab یا Workloadهای سبک مناسب باشند، اما برای Write-intensive Production Workload باید Endurance و Reliability آن‌ها بررسی شود.

اشتباه سوم: قرار دادن همه Replicaها روی یک Server

اگر Replicaها روی OSDهایی قرار بگیرند که همگی در یک Failure Domain هستند، خرابی همان Failure Domain می‌تواند چند Replica را همزمان از بین ببرد.

اشتباه چهارم: پر کردن Cluster تا نزدیک ۱۰۰٪

Storage Cluster به فضای آزاد برای Recovery، Rebalancing و رشد آینده نیاز دارد.

اشتباه پنجم: تصور اینکه Replication همان Backup است

Replication از داده در برابر بسیاری از Hardware Failureها محافظت می‌کند، اما Backup مستقل نیست.

اشتباه ششم: اجرای Ceph بدون Monitoring

اگر از وضعیت OSDها، PGها، Capacity، Latency و Recovery مطلع نباشید، ممکن است Failure قبل از اینکه متوجه شوید روی Availability اثر بگذارد.

اشتباه هفتم: Sizing بر اساس ظرفیت و نه Performance

دو Cluster می‌توانند ظرفیت یکسانی داشته باشند اما Performance کاملاً متفاوتی ارائه دهند.

در طراحی Ceph باید همزمان Capacity، IOPS، Throughput و Latency بررسی شوند.

اشتباه هشتم: استفاده از Hardware کاملاً نامتوازن

اگر یک Node نسبت به سایر Nodeها Storage یا Network بسیار ضعیف‌تری داشته باشد، می‌تواند باعث توزیع نامناسب Load و ایجاد Bottleneck شود.

اشتباه نهم: نادیده گرفتن Recovery Performance

ممکن است Cluster در حالت عادی Performance بسیار خوبی داشته باشد، اما پس از خرابی یک Node، Recovery باعث افزایش شدید Disk I/O و Network Traffic شود.

اشتباه دهم: استفاده از Ceph بدون درک Failure Domain

صرفاً داشتن سه یا پنج Node به معنی High Availability واقعی نیست. باید مشخص شود هر Node در چه Rack، Power Domain و Network Domain قرار دارد.

چه زمانی Ceph انتخاب مناسبی نیست؟

Ceph یک راهکار بسیار قدرتمند است، اما برای همه راهکارهای سازمانی و همه Workloadها بهترین انتخاب نیست.

در شرایط زیر بهتر است گزینه‌های دیگر نیز بررسی شوند:

• Cluster بسیار کوچک و ساده است.
• تیم متخصص برای مدیریت Distributed Storage وجود ندارد.
• Workload به Storage بسیار ساده‌ای نیاز دارد.
• سازمان ترجیح می‌دهد مسئولیت Hardware و Storage را به Vendor بسپارد.
• نیاز اصلی فقط یک File Share ساده است.
• هزینه Operational و Complexity از مزایای Ceph بیشتر می‌شود.
• Network زیرساخت لازم برای Distributed Storage را ندارد.

چه زمانی Ceph انتخاب بسیار خوبی است؟

Ceph زمانی جذاب‌تر می‌شود که چند مورد از نیازهای زیر همزمان وجود داشته باشند:

• نیاز به Storage Distributed
• نیاز به Horizontal Scaling
• نیاز به High Availability
• نیاز به Block Storage
• نیاز به Object Storage
• نیاز به File Storage
• استفاده از OpenStack
• استفاده از Kubernetes
• استفاده از Proxmox
• نیاز به کاهش Vendor Lock-in
• داشتن تیم فنی برای مدیریت Infrastructure

Ceph برای چه سازمان‌هایی مناسب‌تر است؟

Ceph معمولاً برای سازمان‌هایی مناسب‌تر است که زیرساخت IT آن‌ها از یک Server یا چند Virtual Machine ساده فراتر رفته و به Storage قابل توسعه و Highly Available نیاز دارند.

برای مثال:

• Data Centerها
• Cloud Providerها
• Private Cloudهای Enterprise
• سازمان‌های دارای Kubernetes Cluster
• محیط‌های OpenStack
• Virtualization Clusterهای بزرگ
• شرکت‌های SaaS
• سازمان‌های دارای Workloadهای Storage-intensive

Ceph در معماری Modern Data Center

در یک معماری مدرن، Ceph می‌تواند Storage Layer یک زیرساخت کامل باشد.

                       Users
                         │
                         ▼
                  Applications
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
          Kubernetes   OpenStack   VMs
              │          │          │
              └──────────┼──────────┘
                         ▼
                       Ceph
             ┌───────────┼───────────┐
             ▼           ▼           ▼
            RBD        CephFS        RGW
             │           │           │
             └───────────┼───────────┘
                         ▼
                       RADOS
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
            OSDs        OSDs       OSDs
              │          │           │
              └──────────┼───────────┘
                         ▼
                       Disks

این معماری نشان می‌دهد چرا Ceph فراتر از یک File Server ساده است و می‌تواند به عنوان یک Storage Platform کامل در یک Data Center مورد استفاده قرار گیرد.

جمع‌بندی؛ آیا Ceph انتخاب خوبی است؟

Ceph یکی از مهم‌ترین پروژه‌های Open Source در حوزه Distributed Storage است که امکان ساخت یک Storage Platform مقیاس‌پذیر، Highly Available و Software-Defined را فراهم می‌کند.

معماری Ceph بر پایه Componentهایی مانند RADOS، OSD، MON، MGR، CRUSH و Pool ساخته شده و از طریق سرویس‌هایی مانند RBD، CephFS و RGW می‌تواند Block، File و Object Storage ارائه دهد.

همین انعطاف‌پذیری باعث شده Ceph در اکوسیستم‌هایی مانند OpenStack، Kubernetes و Proxmox محبوب باشد.

با این حال، Ceph یک Storage ساده Plug-and-Play نیست. برای دستیابی به یک Cluster Production قابل اعتماد، باید مواردی مانند Network، Storage Device، Failure Domain، Capacity Planning، Recovery، Monitoring و Backup به صورت دقیق طراحی شوند.

اگر Ceph به شکل صحیح طراحی و پیاده‌سازی شود، می‌تواند یک Storage Layer قدرتمند برای Private Cloud و Data Centerهای مدرن ایجاد کند و بدون وابستگی شدید به یک Storage Appliance خاص، امکان Scale کردن زیرساخت را فراهم کند.

سوالات متداول درباره Ceph

Ceph چیست؟

Ceph یک Distributed و Open Source Storage Platform است که می‌تواند Block، File و Object Storage را روی مجموعه‌ای از Serverها و Diskها ارائه کند.

آیا Ceph رایگان است؟

نرم‌افزار Ceph Open Source است و License تجاری برای استفاده معمول از خود Software نیاز ندارد؛ اما Hardware، Network، Deployment، Monitoring و نگهداری آن هزینه دارند.

Ceph چه تفاوتی با NAS دارد؟

NAS معمولاً یک File Storage متمرکز یا Appliance-based است، در حالی که Ceph یک Distributed Storage Platform است که علاوه بر File Storage از Block و Object Storage نیز پشتیبانی می‌کند.

Ceph چه تفاوتی با SAN دارد؟

SAN معمولاً یک Storage Infrastructure اختصاصی برای ارائه Block Storage است، در حالی که Ceph می‌تواند با استفاده از Serverهای استاندارد یک Block Storage Distributed ایجاد کند و در کنار آن File و Object Storage نیز ارائه دهد.

آیا Ceph برای OpenStack مناسب است؟

بله. Ceph یکی از Storage Backendهای شناخته‌شده برای OpenStack است و به‌خصوص RBD می‌تواند برای VM، Cinder و برخی سرویس‌های Storage-related مورد استفاده قرار گیرد.

آیا Ceph برای کوبرنتیز مناسب است؟

بله. Ceph می‌تواند از طریق CSI و راهکارهایی مانند Rook در کوبرنتیز مورد استفاده قرار گیرد و Storageهایی مانند RBD و CephFS را در اختیار Workloadها قرار دهد.

RBD در Ceph چیست؟

RBD یا RADOS Block Device یک Block Storage Interface در Ceph است که برای سناریوهایی مانند Virtual Machine و Cloud Infrastructure کاربرد زیادی دارد.

CephFS چیست؟

CephFS فایل‌سیستم Distributed در Ceph است که داده‌های آن روی RADOS ذخیره می‌شوند و برای Workloadهایی که به Shared File Storage نیاز دارند کاربرد دارد.

Ceph RGW چیست؟

RGW یا RADOS Gateway لایه Object Storage در Ceph است که می‌تواند APIهای Object Storage مانند S3 را در اختیار Applicationها قرار دهد.

OSD در Ceph چیست؟

OSD یا Object Storage Daemon مسئول ذخیره و مدیریت داده‌ها روی Storage Deviceها و انجام عملیاتی مانند Replication، Recovery و Rebalancing است.

MON در Ceph چیست؟

MON یا Monitor مسئول نگهداری اطلاعات مهم مربوط به وضعیت و Membership Cluster و ایجاد Quorum برای سرویس‌های مدیریتی Ceph است.

CRUSH در Ceph چیست؟

CRUSH الگوریتمی است که Ceph از آن برای تعیین محل قرارگیری داده‌ها روی OSDها استفاده می‌کند و می‌تواند Topology و Failure Domain را نیز در Placement داده‌ها در نظر بگیرد.

آیا Ceph به سه Node نیاز دارد؟

برای Lab می‌توان Ceph را با تعداد بسیار کمتری از Nodeها اجرا کرد، اما برای یک Cluster Production و Highly Available معمولاً چندین Node مستقل لازم است و سه Node یک نقطه شروع رایج برای Clusterهای کوچک محسوب می‌شود.

آیا Ceph به Network سریع نیاز دارد؟

Ceph به Network وابستگی زیادی دارد، زیرا Replication، Recovery، Rebalancing و Client Traffic بین Nodeها انجام می‌شود. برای Production معمولاً باید Network با Bandwidth و Latency مناسب بر اساس Workload طراحی شود.

آیا می‌توان از HDD در Ceph استفاده کرد؟

بله. Ceph از HDD پشتیبانی می‌کند و HDD می‌تواند برای Workloadهای Capacity-oriented مناسب باشد. با این حال برای VM، Database و Workloadهای IOPS-intensive معمولاً SSD یا NVMe انتخاب مناسب‌تری است.

آیا Ceph برای Database مناسب است؟

Ceph می‌تواند برای بسیاری از Database Workloadها مناسب باشد، اما Performance نهایی به Storage Device، Network، Replication، Configuration و ویژگی‌های خود Database بستگی دارد. برای Databaseهای حساس باید قبل از Production، Benchmark واقعی انجام شود.

آیا Replication در Ceph همان Backup است؟

خیر. Replication برای Availability و تحمل Hardware Failure طراحی شده است. Backup برای بازیابی داده در برابر حذف تصادفی، خرابی منطقی و سایر سناریوهای Data Loss استفاده می‌شود و باید مستقل از Replication باشد.

آیا Ceph High Availability دارد؟

بله، Ceph برای Distributed و Highly Available بودن طراحی شده است؛ اما High Availability واقعی فقط با طراحی صحیح Failure Domain، MONها، OSDها، Network و Replication به دست می‌آید.

آیا Ceph Self-Healing دارد؟

Ceph می‌تواند بسیاری از Failureها را تشخیص دهد و در صورت وجود Redundancy کافی، فرآیندهایی مانند Recovery و Rebalancing را برای بازگرداندن وضعیت مطلوب Cluster انجام دهد.

آیا Ceph برای Private Cloud مناسب است؟

بله. Ceph یکی از گزینه‌های قدرتمند برای Storage Layer یک Private Cloud است و می‌تواند در کنار OpenStack، Kubernetes یا سایر Virtualization و Cloud Platformها مورد استفاده قرار گیرد.

Ceph بهتر است یا VMware vSAN؟

این دو راهکار برای تمام سناریوها جایگزین مستقیم یکدیگر نیستند. اگر زیرساخت عمدتاً مبتنی بر VMware باشد، vSAN می‌تواند گزینه طبیعی‌تری باشد؛ اما برای یک Storage Platform مستقل و چندمنظوره که با OpenStack، Kubernetes و Object Storage نیز یکپارچه شود، Ceph انعطاف‌پذیری بیشتری دارد.

Ceph بهتر است یا Proxmox Storage؟

Proxmox یک Virtualization Platform است و Ceph یک Distributed Storage Platform. این دو حتی می‌توانند در کنار یکدیگر استفاده شوند؛ Proxmox می‌تواند از Ceph به عنوان Shared Storage استفاده کند.

آیا Ceph برای یک شرکت کوچک مناسب است؟

بستگی دارد. اگر نیاز شرکت فقط یک File Server ساده باشد، Ceph احتمالاً بیش از نیاز است. اما اگر شرکت به Virtualization Cluster، High Availability، Storage قابل توسعه یا Private Cloud نیاز داشته باشد، Ceph می‌تواند گزینه مناسبی باشد.

مهم‌ترین نکته در طراحی Ceph چیست؟

هیچ Component واحدی به تنهایی مهم‌ترین عامل نیست. یک Ceph Cluster موفق نتیجه طراحی همزمان Storage، Network، CPU، RAM، Failure Domain، Capacity، Replication و Monitoring است.

آیا قبل از راه‌اندازی Ceph باید Benchmark انجام شود؟

بله. برای محیط‌های حساس، Benchmark و Proof of Concept قبل از Production بسیار مهم است. باید Workload واقعی یا نزدیک به واقعیت شبیه‌سازی شود و IOPS، Throughput، Latency و رفتار Cluster در شرایط Failure و Recovery نیز بررسی شود.

آیا Ceph جایگزین Backup است؟

خیر. Ceph یک Storage Platform است و حتی یک Cluster بسیار Highly Available نیز باید در کنار خود یک Backup Strategy مستقل داشته باشد.

آیا Ceph برای Disaster Recovery مناسب است؟

Ceph می‌تواند بخشی از معماری Disaster Recovery باشد، اما طراحی DR باید بر اساس RPO، RTO، تعداد سایت‌ها، Network و نیاز کسب‌وکار انجام شود. صرفاً داشتن یک Ceph Cluster به معنی داشتن Disaster Recovery نیست.

آیا Ceph پیچیده است؟

در مقایسه با یک NAS ساده یا برخی Storage Applianceها، Ceph پیچیدگی بیشتری دارد. در مقابل، این پیچیدگی امکان Scalability، Automation، High Availability و انعطاف‌پذیری بسیار بیشتری را فراهم می‌کند.

آیا Ceph برای محیط Production مناسب است؟

بله. Ceph در بسیاری از محیط‌های Production بزرگ استفاده می‌شود؛ اما موفقیت آن به طراحی صحیح، Hardware مناسب، Network مناسب، Monitoring و داشتن تیمی که دانش کافی برای مدیریت و Troubleshooting آن داشته باشد وابسته است.