הגדרת שרת ZFS: מאגרים, מערכי נתונים, שכפול

מנהל מערכת מגלה שבקר RAID חומרתי נכשל, ושחזור נתונים אורך שבועות. נתקלנו בזה עשרות פעמים — הפתרון נקרא ZFS. זה לא רק מערכת קבצים, אלא מנהל נפחים מלא עם הגנה על שלמות נתונים, תמונות מצב (snapshots) ושכפול בזמן אמת. ZFS מונע אובדן נתונים ברמת התקן הבלוק על ידי תיקון אוטומטי של ריקבון סיביות (bit rot). בניגוד ל-RAID חומרתי, ZFS אינו קשור לבקר ספציפי — ניתן להעביר את ה-pool לשרת אחר. החיסכון מהימנעות מבקרים יקרים יכול להגיע ל-50% מתקציב האחסון — עבור שרת עם 10 דיסקים, מדובר במאות דולרים של חיסכון בשנה. הזמינו הגדרת ZFS המותאמת לעומס העבודה שלכם — נבחר את התצורה האופטימלית של pools ו-datasets, תוך הבטחת סובלנות לתקלות וביצועים.

למה ZFS אמין יותר מ-RAID חומרתי?

בקרי RAID חומרתיים הם יקרים, קשורים לדגמים ספציפיים, ואינם בודקים שלמות נתונים. ZFS משתמש ב-parity ברמת מערכת הקבצים (RAIDZ) ומתקן אוטומטית ריקבון סיביות. לפי OpenZFS, ההסתברות לשגיאה שלא זוהתה ב-ZFS נמוכה פי 100 מאשר ב-RAID קלאסי עם ext4. בנוסף, ZFS תומך בתמונות מצב מיידיות, דחיסת lz4 והצפנה ללא פגיעה בביצועים.

איך לייעל את ZFS למסדי נתונים?

עבור PostgreSQL, אנו יוצרים dataset נפרד עם recordsize=8k ו-loghbias=throughput — כך ZFS לא מאחסן במטמון את יומן מסד הנתונים, שמסד הנתונים כותב דרך fsync בכל מקרה. עבור MySQL, recordsize=16k הוא אופטימלי. בכל מקרה, אנו משביתים atime ומפעילים דחיסת lz4: חיסכון בשטח עד 40% ללא פגיעה ב-IOPS. עבור מערכות בעומס גבוה, אנו גם מגדירים primarycache=metadata כדי לשמור במטמון רק מטא-דאטה.

למה ashift=12 הוא קריטי?

לדיסקים מודרניים יש סקטור פיזי של 4K, לא 512 בתים. אם ashift=9 (512 בתים), כל פעולת קריאה/כתיבה גורמת לעומס נוסף על תרגום, מה שמפחית ביצועים עד 50% בהשוואה ל-ashift=12. הגדרת ashift=12 מבטיחה יישור ומהירות אופטימלית.

מושגי מפתח לפני שמתחילים

Pool (zpool) — קבוצת דיסקים פיזיים, מקבילה למערך RAID. Dataset — מערכת קבצים או נפח בתוך ה-pool. פרמטרים (דחיסה, הצפנה, מכסות) מוגדרים ברמת ה-dataset ועוברים בירושה ל-datasets צאצאיים.

פרט חשוב מהותי: ZFS מנהל מטמון משלו (ARC). אין צורך לכוון את vm.dirty_ratio — ZFS עובד מחוץ למטמון העמודים של הליבה. ARC תופס כברירת מחדל עד מחצית מה-RAM, וזה נכון עבור שרת אחסון ייעודי. לשיפור ביצועים, ניתן להוסיף L2ARC על SSD, אך רק אם יש מספיק RAM (לפחות 8 GB לכל 1 TB של L2ARC).

יצירת pool ותצורה בסיסית

צרו pool משוקף (mirrored) משני דיסקים (ashift=12 הוא קריטי):

zpool create -o ashift=12 \
    -O compression=lz4 \
    -O atime=off \
    -O xattr=sa \
    -O dnodesize=auto \
    tank mirror /dev/sdb /dev/sdc

עבור נפחים גדולים, השתמשו ב-RAIDZ2 (מקביל ל-RAID6) עם recordsize=1M:

zpool create -o ashift=12 \
    -O compression=lz4 \
    -O atime=off \
    -O recordsize=1M \
    storage raidz2 /dev/sdd /dev/sde /dev/sdf /dev/sdg /dev/sdh /dev/sdi

Datasets והיררכיה

מבנה dataset נכון חוסך זמן בניהול. צרו היררכיה והגדירו פרמטרים עבור PostgreSQL:

zfs create tank/data
zfs create tank/data/databases
zfs create tank/data/applications
zfs create tank/backups
zfs create -o recordsize=8k -o logbias=throughput -o primarycache=metadata tank/data/databases/postgres

תמונת מצב לפני עדכון: zpool create -o ashift=12 \ -O compression=lz4 \ -O atime=off \ -O xattr=sa \ -O dnodesize=auto \ tank mirror /dev/sdb /dev/sdc .

שכפול בין שרתים

שכפול מצטבר דרך תמונות מצב על גבי SSH ללא תוכנה נוספת:

zfs send tank/data@snapshot-01 | ssh backup-server zfs receive backup/data 

לאוטומציה, השתמשו ב-zrepl — הוא מנהל תזמון, גיזום ושכפול.

הבטחת סובלנות לתקלות

סריקות (scrubs) קבועות בודקות את שלמות כל הנתונים ומשחזרות בלוקים פגומים. תזמנו סריקות פעם בחודש למערכות שולחניות ופעם בשבוע לשרתי מסדי נתונים. נטר את בריאות ה-pool עם Prometheus:

zpool status -v tank arc_summary | grep -E 'ARC size|Cache Hit' 

לאיסוף מדדים אוטומטי, השתמשו ב-node_exporter עם מודול ZFS מופעל. כאשר מתגלות שגיאות, ZFS עובר אוטומטית לעותקים בריאים (בתצורות mirror).

הצפנת Dataset

ההצפנה המקורית של ZFS (aes-256-gcm) פועלת ברמת התקן הבלוק. המפתח נטען בזמן ההרכבה; ניתן לבצע אוטומציה דרך systemd או Vault.

תהליך העבודה

1. ניתוח: ביקורת על תוכנית האחסון הנוכחית, פרופיל עומס, דרישות SLA.
2. תכנון: בחירת טופולוגיה (mirror/RAIDZ), גודל pool, מדיניות תמונות מצב.
3. יישום: פריסת ZFS, הגדרת datasets, שכפול, ניטור.
4. בדיקות: בדיקות עומס, בדיקות סובלנות לתקלות, שחזור מגיבוי.
5. השקה: מסירת תיעוד, הדרכת צוות, תמיכה לאחר ההשקה.

קבלו ייעוץ ממהנדס DevOps: צרו קשר לביקורת.

מה כלול

• פריסת ZFS על שרתים (Debian/Ubuntu/CentOS)
• יצירת pool עם פרמטרים אופטימליים (ashift, דחיסה, recordsize)
• הגדרת datasets עבור DBMS ויישומים ספציפיים
• אוטומציה של תמונות מצב ושכפול (zrepl, sanoid)
• ניטור pool דרך Prometheus/Grafana
• הצפנת נתונים רגישים
• תיעוד: תוכנית pool, runbook לשחזור, תוכנית תחזוקה
• הדרכת צוות: פעולות טיפוסיות, פתרון תקלות

אנו מבטיחים שהתצורה עומדת בשיטות המומלצות של OpenZFS. הניסיון שלנו: 10+ שנים בפרויקטי תשתית, מעל 50 פריסות אחסון ZFS מוצלחות.

טעויות נפוצות

• הוספת L2ARC על SSD זול ללא מספיק RAM — מבזבזת RAM על מטא-דאטה.
• יצירת pool עם ashift=9 על דיסקי 4K — מחצית את הביצועים.
• הרצת scrub בשעות שיא — תזמנו אותו לחלון לילי.

לוחות זמנים

העלות מחושבת באופן אישי לאחר ביקורת תשתית. נבחן את הפרויקט שלכם — צרו קשר.