שירותי תכנון וניהול אחסון

מדוע אשכול Ceph מתחיל להאט?

אשכול Ceph עם 15 OSD מציג health: HEALTH_WARN בלילה. ceph -s מחזיר too many PGs per OSD (400 > max 250). זמן האחזור של RBD I/O מוכפל — סימפטום קלאסי של תכנון אחסון ללא חישוב PG. זה לא אסון, אבל במשך שנים רבות של ניסיון (יותר מ-50 אשכולות Ceph שנפרסו) למדנו לתכנן כך שזה לא יקרה.

טעות נפוצה אחת בתכנון אחסון היא הערכה שגויה של קבוצות מיקום. המהנדסים שלנו בוחרים pg_num עבור הטופולוגיה הנוכחית ומפעילים קנה מידה אוטומטי ב-Ceph Nautilus+, מה שמבטיח SLA של 99.9% על זמינות נתונים. הניסיון מראה: חישוב PG נכון מפחית את זמן האחזור השיא של I/O ב-40–60% בהשוואה לתצורת ברירת מחדל.

Ceph: ארכיטקטורה ומלכודות

Ceph הוא אחסון מוגדר תוכנה עם אלגוריתם CRUSH שמפיץ אובייקטים ללא קטלוג מרכזי. זה מעניק מדרגיות אופקית, אך דורש חישוב PG מדויק.

מפת CRUSH והפצת נתונים. כל אובייקט עובר גיבוב ל-PG, וה-PG ממופה ל-OSD דרך CRUSH. תחום הכשל מוגדר כך שעותקים לא נוחתים על אותו מארח, מדף או מרכז נתונים.

# Просмотр CRUSH map и расчёт pg_num ceph osd getcrushmap -o /tmp/crushmap.bin crushtool -d /tmp/crushmap.bin -o /tmp/crushmap.txt ceph osd pool get <pool_name> pg_num # Рекомендация: (OSD_count * 100) / replica_count → округлить до степени 2 

עבור 12 OSD עם שכפול 3x: # Просмотр CRUSH map и расчёт pg_num ceph osd getcrushmap -o /tmp/crushmap.bin crushtool -d /tmp/crushmap.bin -o /tmp/crushmap.txt ceph osd pool get <pool_name> pg_num # Рекомендация: (OSD_count * 100) / replica_count → округлить до степени 2 . אם יש חמישה pools, סך ה-PG לכל OSD עולה בחדות, ומופיע (12 * 100) / 3 = 400 → 512. הפעל too many PGs per OSD — זה פותר את הבעיה.

ביצועי RBD. RBD (RADOS Block Device) הוא הבסיס למכונות וירטואליות (Proxmox, OpenStack). פרמטרים קריטיים:

• ceph osd pool autoscale-status עם rbd_cache = true — מטמון כתיבה-אחורה בצד הלקוח (מאיץ כתיבה אקראית, אך סיכון לאובדן נתונים בקריסה). עבור מסדי נתונים השתמש ב-rbd_cache_size = 128 MB או השבת את המטמון.
• rbd_cache_writethrough = true — עבור NVMe הגדל ל-8–16 במקום 3 כברירת מחדל.

# Бенчмарк пула rados bench -p <pool_name> 60 write --no-cleanup rados bench -p <pool_name> 60 seq rados bench -p <pool_name> 60 rand 

בעיות אופייניות באשכול Ceph:

• ms_async_op_threads — פעולות ממתינות >30 שניות. # Бенчмарк пула rados bench -p <pool_name> 60 write --no-cleanup rados bench -p <pool_name> 60 seq rados bench -p <pool_name> 60 rand יציג את הגורם: OSD עמוס, זמן אחזור רשת (בדוק MTU, jumbo frames), slow ops נמוך.
• איזון מחדש לאחר הוספת OSD מאט את כל האשכול. אנו מתאימים:

ceph osd set-backfillfull-ratio 0.90 ceph config set osd osd_max_backfills 1 ceph config set osd osd_recovery_max_active 3 

הקטנת ceph daemon osd.<id> dump_ops_in_flight ל-1 מפחיתה עומס אך מאריכה את זמן השחזור — אנו מוצאים איזון עבור האשכול הספציפי.

ניטור. bluestore_throttle_bytes מאפשר exporter בפורט 9283. מדדים: ceph osd set-backfillfull-ratio 0.90 ceph config set osd osd_max_backfills 1 ceph config set osd osd_recovery_max_active 3 , osd_max_backfills, ceph mgr module enable prometheus. ב-Grafana השתמש במזהה לוח מחוונים 2842.

חישוב PG: כיצד להימנע מעומס OSD

בעת תכנון אחסון, אנו תמיד מחשבים PG כך שלכל OSD לא יהיו יותר מ-250 PG. אם יש pools רבים, אנו משתמשים בקנה מידה אוטומטי (/etc/exports). לפי תיעוד Ceph (Placement Groups), חריגה מ-250 PG לכל OSD מגדילה את זמן האחזור בעד 50%. עבור אשכול היברידי (CephFS + RBD) עם 12 OSD, 3 עותקים ו-4 pools, הנוסחה /data/shared 10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash) נותנת 512 PG לכל pool. סך ה-PG לכל OSD = sync, הרבה מתחת למגבלת 250. קנה מידה אוטומטי מופעל.

NFS: כשהוא פשוט עובד וכשהוא מפסיק

NFS v4.1 עם pNFS לגישה מקבילה הוא מוגזם עבור רוב המשימות. עבור אחסון משותף של שרתי אינטרנט או ספריות ביתיות, NFS v4 ללא pNFS מספיק.

no_root_squash:

/data/shared 10.0.0.0/24(rw,sync,no_subtree_check,no_root_squash) 

• 10.0.0.1:/data/shared /mnt/shared nfs rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,nfsvers=4.1 — אישור כתיבה לאחר flush לדיסק (ייצור).
• rsize/wsize — הכרחי עבור Kubernetes Persistent Volumes עם NFS provisioner.

אפשרויות הרכבה בצד הלקוח:

10.0.0.1:/data/shared /mnt/shared nfs rsize=1048576,wsize=1048576,hard,timeo=600,retrans=2,nfsvers=4.1 

hard 1 MB אופטימליים עבור קבצים גדולים. soft — הלקוח ממתין לשרת ללא הגבלת זמן (בניגוד ל-mc alias set myminio http://localhost:9000 minioadmin minioadmin mc mb myminio/backups mc cp backup.tar.gz myminio/backups/ ).

מערכות תואמות S3: MinIO ו-RadosGW

MinIO בצומת יחיד — עבור dev/staging. מצב מבוזר עם קידוד מחיקה — מ-4 צמתים, עמיד לאובדן חצי מהדיסקים. עבור Ceph RadosGW נתונים מאוחסנים ב-RADOS, ומתרחבים אופקית:

mc alias set myminio http://localhost:9000 minioadmin minioadmin mc mb myminio/backups mc cp backup.tar.gz myminio/backups/ 

הגדרת MinIO: radosgw-admin user create --uid=s3user --display-name="S3 User" --access-key=KEY --secret=SECRET radosgw-admin quota set --quota-scope=user --uid=s3user --max-size=100G .

מדוע RAID 6 עדיף על RAID 5 עבור דיסקים ≥16 TB?

RAID תוכנה דרך mdadm חי על bare metal. במהלך שחזור RAID 5 עם דיסקים מודרניים (16–20 TB), השחזור אורך 20–40 שעות. ההסתברות לכשל דיסק שני בזמן זה גבוהה פי 3–5 מאשר בשחזור של 4 שעות עם דיסקים ישנים. RAID 6 סובל כשל בו-זמני של שני דיסקים — הבטיחות גבוהה פי 2 מבחינת שימור נתונים.

radosgw-admin user create --uid=s3user --display-name="S3 User" --access-key=KEY --secret=SECRET radosgw-admin quota set --quota-scope=user --uid=s3user --max-size=100G 

הקפד להגדיר # Создание RAID6 из 6 дисков mdadm --create /dev/md0 --level=6 --raid-devices=6 /dev/sd[bcdefg] # Мониторинг cat /proc/mdstat mdadm --detail /dev/md0 ב-MAILADDR עבור התראות.

כיצד לבחור סוג אחסון?

הבחירה בין Ceph, NFS ו-MinIO נקבעת על ידי פרופיל העומס. עבור גישת בלוקים (מכונות וירטואליות, מסדי נתונים) — Ceph RBD. עבור גישת קבצים — NFS v4 או CephFS. עבור אובייקטים — MinIO או RadosGW. סכמות היברידיות (למשל, CephFS + RBD) דורשות תכנון קפדני של שורשי CRUSH.

מה כוללת עבודת תכנון האחסון?

• תיעוד ארכיטקטורה (מפת CRUSH, טופולוגיית רשת, חישוב PG).
• קבצי תצורה וסקריפטים לאוטומציה (Ansible, Terraform).
• אינטגרציה עם ניטור (Prometheus, Grafana, לוחות מחוונים).
• מדריך ניהול ושחזור מאסון.
• הכשרת צוות (2–3 מפגשים של 4 שעות).

כיצד אנו מתכננים אחסון עמיד לתקלות

1. ניתוח דרישות — פרופילי עומס, RPO/RTO, תקציב.
2. בחירת ארכיטקטורה — Ceph, NFS, MinIO או היברידי.
3. תכנון — מפת CRUSH, PG, רשת, ניטור.
4. יישום — פריסה, תצורה, בדיקות ביצועים.
5. עלייה לאוויר — מדריך, הכשרת צוות, SLA 99.9%.

העלות מחושבת באופן אישי לאחר ניתוח דרישות האחסון. הזמינו ביקורת על התשתית הנוכחית שלכם — נציע פתרון עם TCO נמוך ב-30–50% מ-SAN/NAS מסחרי. צרו קשר לייעוץ; נעריך את האחסון שלכם ונספק תוכנית מפורטת תוך שבוע. לארכיטקטורת אחסון מותאמת אישית לעומס העבודה שלכם, קבעו פגישת ייעוץ עם המהנדסים שלנו.