עבר כחודש מאז החלו שתי המכונות לרוץ זו בצד זו, כשעל שתיהן צבור אוסף קבצי מולטימדיה זהה בקיבול של כ 1.3 טרה, והגיע הזמן לדו"ח מצב. במשך כ 28 יום לא אירע דבר, פרט לעידכונים אחדים – אותם הקבצים נוספו לשתיהן. ואז אירעה הפסקת חשמל קצרה. שני המחשבים נפלו, והיה מעניין לבדוק כיצד הם עלו לאחר הנפילה, וכיצד שרד עליהם המידע.
במחשב pcbsd-zfs נערכת הבדיקה כך:
ראשית מרעננים את הזכרון ברשימת "מצבורי" (pools) ה zfs שמחשב הנידון:
[root@pcbsd-zfs] ~# zpool list
NAME SIZE USED AVAIL CAP HEALTH ALTROOT
tank 3.62T 1.80T 1.82T 49% ONLINE -ולומדים משהו על ההיסטוריה שלהם (סטטיסטיקת כניסה\יציאה):
[root@pcbsd-zfs] ~# zpool iostat
capacity operations bandwidth
pool used avail read write read write
---------- ----- ----- ----- ----- ----- -----
tank 1.80T 1.82T 73 10 9.08M 1.21Mשימו לב להבדל הגדול בין מהירות הכתיבה (איטית) למהירות הקריאה, הגדולה כמעט פי שמונה. ולבסוף, הבדיקה עצמה:
[root@pcbsd-zfs] ~# zpool status -v tank
pool: tank
state: ONLINE
scrub: none requested
config:
NAME STATE READ WRITE CKSUM
tank ONLINE 0 0 0
raidz1 ONLINE 0 0 0
ad10 ONLINE 0 0 0
ad4 ONLINE 0 0 0
ad6 ONLINE 0 0 0
ad8 ONLINE 0 0 0
errors: No known data errorsscrub הוא בערך שווה-הערך ל fsck במערכות קבצים מקובלות; הוא מייצר חתימה של קובץ, ואם חתימה זו משתנה בקובץ שלא שינינו מרצוננו – הקובץ נהיה חשוד בשגיאה.
במחשב BT ספריית הבית, בת 1.5 טרה, היא בעלת מערכת הקבצים btrfs.
בדיקת מצב מערכת הקבצים:
BTR:~ # btrfsctl -A /dev/mapper/pdc_ceeefdgfb_part1
operation complete
Btrfs Btrfs v0.19שלא סיפקה יותר מדי מידע, יש לציין. יצירת תמונת מצב לספריית הוידאו:
BTR:~ # btrfsctl -s /home/lulibt/snap1 /home/lulibt/Videos
operation complete
Btrfs Btrfs v0.19באותו אופן יוצרים תמונת-מצב גם לספריות אחרות.
מכבר רציתי להגדיל את כונן המולטימדיה ב"גיבוי". ב"גיבוי" שני כוננים; כל אחד מהם הוא מערך raid10 השוכן על כרטיס רייד חומרה מתוצרת 3ware. הבעיה העיקרית שעמדה לפני היתה היכן לשמור את כל החומר שהצטבר בכונן המולטימדיה. חומר זה יאבד עם פירוק הכוננים הישנים מעל הבקר, תכולתם כבר הגיעה ל 88% משני טרה. והנה יש לי גיבוי אמין לכל הקבצים הללו, גם על BT וגם על pcbsd-ZFS.
המערך הישן היה מורכב מארבעה כוננים בני 1T כל אחד, והרעיון היה להחליף אותם בארבעה כונני caviar black בני 2T כל אחד, מה שיכפיל את תכולת המערך. המערך הישן היה מפורמט במערכת הקבצים XFS שפעלה היטב, מהר ובניצול טוב של שטח הדיסקים. אולם יש לה חסרון אחד: הפעלת fsck עליה איטית ביותר, בעיה קשה כאשר מדובר במערכים גדולים.
החלטתי לפרמט את המערך החדש ב Ext4 - הוא כבר אינו בגדר נסיוני, ביצועיו טובים, והוא מתאים למערכות מרובות טרות (המערך החדש יהיה בן 4 טרה). אבל גם ext4 וגם caviar black דורשים גרסת לינוקס עכשווית, ולא את אופן-סוזה 11.1 שהיתה מותקנת על "גיבוי".
החלטתי איפה ששלבי העבודה יהיו כאלו: א. עידכון מערכת ההפעלה לאופן-סוזה 11.3 (מערכת ההפעלה נמצאת על מערך הרייד הראשון) ב. פירוק הכוננים הישנים, החלפתם בחדשים, יצירת מערך raid10 עליהם, פירמוטם ב ext4 ואז העתקה חוזרת של תוכנם אליהם מ pcb-zfs או מ BT. עוד פעולה מקדימה אחת הייתי צריך לעשות: להסיר מעיגון את שיתופי NSF מיתר המחשבים שברשת, שבכולם כונני המולטימדיה והגיבוי נמצאים על "גיבוי". אחרת עלולים לחול שיבושים רציניים בפעולתם.
על "גיבוי" נמצא בין היתר מאגר מקומי של אופן-סוזה 11.3 ומשמש להתקנה ולעידכון מחשבים אחרים. אי לכך העתקתי מתוכו את הקבצים linux ו initrd למחיצת boot וערכתי את menu.lst בהתאם (פרטים מלאים ראו כאן). איתחלתי את המחשב, בחרתי ב rescue ותכנית ההתקנה עלתה. בחרתי ב"התקן מהדיסק הקשיח" וניווטתי למאגר 11.3.
בחרתי ב"עידכון" והוא התבצע במהירות רבה ביותר, ובהצלחה. עכשיו היה גיבוי מוכן להחלפת הדיסקים.
עם כרטיסי 3ware מגיע CD של מדריכים, דרייברים ותוכנות שירות. בין היתר נמצאת בו גם תכנת שירות ללינוקס, ושמה tw_cli , וכשמה כן היא: פועלת משורת הפקודה. כדי להתקינה יש להעתיקה לספרייה usr/sbin/. בעזרתה ניתן לבדוק את מצב המערך ולבצע עליו פעולות שונות:
//gibooi> show
Ctl Model Ports Drives Units NotOpt RRate VRate BBU
------------------------------------------------------------------------
c6 9550SX-4LP 4 4 1 0 5 5 OK
c7 9550SXU-4LP 4 4 1 1 4 4 - אוי ואבוי... אחד הדיסקים במערך החדש אינו פעיל:
/gibooi> /c7 show
Unit UnitType Status %Cmpl Stripe Size(GB) Cache AVerify IgnECC
------------------------------------------------------------------------------
u0 RAID-10 DEGRADED - 64K 3725.27 ON OFF OFF
Port Status Unit Size Blocks Serial
---------------------------------------------------------------
p0 NOT-PRESENT - - - -
p1 OK u0 1.82 TB 3907029168 WD-WMAY001896
p2 OK u0 1.82 TB 3907029168 WD-WMAUR02079
p3 OK u0 1.82 TB 3907029168 WD-WMAUR02762סביר שאחד מכבלי ה SATA אינו מחובר כפי שצריך. אני אשבית אם כן את "גיבוי", אערוך חיזוק כבלים ואשוב לבדוק את המצב. אחרי החלפת הכבל הפגום המצב הוא כזה (ב 18:12):
//gibooi> /c7/u0 show
Unit UnitType Status %Cmpl Port Stripe Size(GB) Blocks
-----------------------------------------------------------------------
u0 RAID-10 REBUILDING 65 - 64K 3725.27 7812456448
u0-0 RAID-1 REBUILDING 30 - - - -
u0-0-0 DISK DEGRADED - p0 - 1862.63 3906228224
u0-0-1 DISK OK - p1 - 1862.63 3906228224
u0-1 RAID-1 OK - - - - -
u0-1-0 DISK OK - p2 - 1862.63 3906228224
u0-1-1 DISK OK - p3 - 1862.63 3906228224 ובשעה 22:00:
//gibooi> /c7/u0 show
Unit UnitType Status %Cmpl Port Stripe Size(GB) Blocks
-----------------------------------------------------------------------
u0 RAID-10 OK - - 64K 3725.27 7812456448
u0-0 RAID-1 OK - - - - -
u0-0-0 DISK OK - p0 - 1862.63 3906228224
u0-0-1 DISK OK - p1 - 1862.63 3906228224
u0-1 RAID-1 OK - - - - -
u0-1-0 DISK OK - p2 - 1862.63 3906228224
u0-1-1 DISK OK - p3 - 1862.63 3906228224והמערך חזר לאיתנו.
כאמור, ניתן לכתוב למערך זה משכניו ברשת במהירות של כ 80 mb/s, מתאים ביותר למאגר של קבצים גדולים.
עם סיום עבודה זו היו בידי עוד כוננים אחדים בקיבול 1T שאינם מתוצרת WD, והתעורר בי הרצון להחליף את הכונן מתוצרתה ב pcbsd-ZFS.
היו לכך שני טעמים: הראשון, רציתי לראות אם יש לכך השפעה על הביצועים (ראו כאן). והשני, להתנסות בהתאוששות מערך ZFS (רייד 5) מאובדן דיסק.
הצעד הראשון שיש לעשות כדי להחליף דיסק במערך הוא הצעד הבא:
[root@pcbsd-zfs] ~# zpool scrub tank
[root@pcbsd-zfs] ~# zpool offline tank ad4עכשיו ניתן לכבות את המחשב ולהחליף את הדיסק. אחרי שהמחשב עלה מחדש, עושים פעולה דומה למדי לזו שנעשתה ב 3ware:
[root@pcbsd-zfs] ~# zpool status tank
pool: tank
state: DEGRADED
status: One or more devices is currently being resilvered. The pool will
continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
scrub: resilver in progress for 0h0m, 0.34% done, 2h3m to go
config:
NAME STATE READ WRITE CKSUM
tank DEGRADED 0 0 0
raidz1 DEGRADED 0 0 0
ad10 ONLINE 0 0 0 1.48M resilvered
replacing DEGRADED 0 0 0
ad4/old OFFLINE 0 621 0
ad4 ONLINE 0 0 0 1.55G resilvered
ad6 ONLINE 0 0 0 1.45M resilvered
ad8 ONLINE 0 0 0 1.20M resilvered
errors: No known data errorsואמנם אחרי מספיק זמן חזר המערך למצבו הראשוני. לא הבחנתי בשום הבדל בביצועים.
זהו. עד כה אין מפסיד או מנצח, אם כי מורגש שעדיין ZFS יותר בשלה ובעלת אפשרויות שליטה וניהול רבות יותר.
עוד מהבלוג של SML
הכרות עם פדורה 14
טיפ: התחברות למחשב מרוחק באמצעות KDM4
התחרות הגדולה – המשך (2)
* 19:23 עריכה, קישורים ותמונה (cheukiecfu, רישיון by-nc-sa/2.0): אורי