עבור לתוכן

מה יותר מהיר - כונן 7200 ממוצע או 3 כונני 5400 ב-RAID5?

Featured Replies

פורסם

אני מניח שאוכל למצוא בנצ'מרקים רלוונטיים, אבל אם מישהו יודע את התשובה בשלוף אז זה יכול לחסוך לי את החפירה.

תודה!

פורסם

הנה תוצאה מחיפוש קצר בגוגל:

RAID 5 performance

RAID 5 implementations suffer from poor performance when faced with a workload which includes many writes which are smaller than the capacity of a single stripe. This is because parity must be updated on each write, requiring read-modify-write sequences for both the data block and the parity block. More complex implementations may include a non-volatile write back cache to reduce the performance impact of incremental parity updates. Large writes, spanning an entire stripe width, can however be done without read-modify-write cycles for each data + parity block, by simply overwriting the parity block with the computed parity since the new data for each data block in the stripe is known in its entirety at the time of the write. This is sometimes called a full stripe write.

Random write performance is poor, especially at high concurrency levels common in large multi-user databases. The read-modify-write cycle requirement of RAID 5's parity implementation penalizes random writes by as much as an order of magnitude compared to RAID 0.[11]

Performance problems can be so severe that some database experts have formed a group called BAARF — the Battle Against Any Raid Five.[12]

The read performance of RAID 5 is almost as good as RAID 0 for the same number of disks. Except for the parity blocks, the distribution of data over the drives follows the same pattern as RAID 0. The reason RAID 5 is slightly slower is that the disks must skip over the parity blocks.

בקיצור: הביצועים בRAID5 סובלים כתוצאה מהצורך לכתוב פריטי (עותק) לדיסק הנוסף בכל מחזור כתיבה. למרות שלכאורה צריך להיות יתרון כתוצאה מהשימוש בכמה דיסקים בו זמנית, השימוש בדיסק הנוסף כגיבוי חלקי מוריד את הביצועים.

אני אישית משתמש ב-RAID0. אבל לי אין צורך בגיבוי בשביל החומרים שלי. החשובים מגובים לענן.

פורסם
  • מחבר

אני לא מריץ בסיס נתונים או תוכנות אחרות שמבצעות הרבה כתיבות קטנות (מלבד אולי uTorrent, אבל התוכנה הזו כבויה בשעות שבן אני משתמש במחשב). אני מניח שלצרכים שלי RAID5 צריך להיות פתרון לא רע, אבל אולי אני צריך לבדוק שוב את האופציה של גיבוי מבוסס ענן. אפשר לשאול באיזה שירות אתה משתמש, מה הנפח שהם מציעים ומה העלויות?

פורסם

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

לגבי הענן אני משתמש ב-MOZY - הם נותנים 2 גיגה חינם, ומעבר לזה צריך לשלם. אבל הם מספקים תוכנה שמגבה אוטומטית.

אני לא יודע עלויות. ולא יכול לבדוק מהעבודה. תכנס ללינק ותבדוק.

כמובן שזה תלוי בנפחים שאתה צריך ובמהירות ה-UPLOAD שלך.

פורסם
  • מחבר

תודה על התגובה. Mozy יקר מדי לנפח שאני מעוניין לגבות (כ-200GB, בעיקר צילומים).

פורסם

1. RAID אינו גיבוי כי אם מספק יתירות.

2. אם התכוונת למערך RAID5 רק לצורך גיבוי (כלומר זהו שטח האחסון שעליו יועתקו עותקי הגיבוי של החומר) אז לדעתי זה מיותר אלא אם כן מדובר בנפחים עצומים.

3. אלא אם כן יש לך בקר RAID ייעודי, ואתה מתכנן שימוש בערכת השבבים של לוח האם, אז כל היתרונות התיאורטיים של מערך RAID מבחינת זמני קריאה וכתיבה הם לא ממש רלוונטיים.

4. באופן כללי לא נכון לשפוט ביצועים של כונן לפי הסל"ד. יש המון משתנים שקובעים את ביצועי הכונן שאותם לא ממש ניתן להסיק מהמפרט הטכני. לדוגמה, חלק מכונני ה-5400 סל"ד החדשים "מהירים" יותר מכונני 7200 סל"ד ישנים יותר. נכון שאם אתה משווה כוננים מאותו דור היתרון אמור להיות בידי כונן ה-7200 סל"ד רק שהוא לא תמיד משמעותי. עבור מערך אחסון אין שום בעיה לקחת כונן 5400 סל"ד מכיוון שלמטרה זו הכונן לא צריך להיות בעל "ביצועים" מיוחדים ולפעמים עדיף שיהיה קריר וחסכוני באנרגיה כמה שאפשר. עבור הכונן הראשי מומלץ עדיין לקנות כונן 7200 סל"ד.

בשביל גיבוי של 200GB אני ממליץ על כונן פנימי ייעודי במחשב שישמש כמקור ועוד כונן חיצוני שישמש כגיבוי (אוטומטי כמובן). כשכבת הגנה נוספת תוכל לקנות כונן נוסף ולגבות אליו פעם בשבוע/חודש/כל פרק זמן אחר בהתאם לצרכים שלך ואותו תאחסן מחוץ לאתר או במקום מוקם (כספת לדוגמה) באתר. עבור גיבוי Offsite, ואם יש לך גישה למחשב מרוחק (הורים, חברים או כל אדם אחר שאתה סומך עליו) אז תוכל להשתמש ב-Crashplan כדי לגבות לשם את המידע. כמובן שגם גיבוי לענן הוא אפשרות (שמלבד העלויות, אני בעצמי עוד לא גיבשתי לגמרי את דעתי בנוגע אליה).

פורסם
  • מחבר

כן, אני מודע לזה ש-RAID הוא לא גיבוי אלא רק יתירות. הבעיה היא שאני לא מגבה על בסיס יומי, ולכן חשוב לי להקטין את הסיכוי לאובדן מידע בגלל כשל בדיסק.

התוכנית היא להתקין שלושה כונני Samsung 2TB 5400RPM במערך RAID5, ולהשתמש בהם גם עבור מערכת ההפעלה והתוכנות וגם עבור הקבצים. RAID0 לא בא בחשבון מבחינתי, ו-RAID1 נראה לי קצת בזבזני. הבקר RAID שיש על הלוח שלי תומך ב-RAID1/0/5/10.‏

יש שתי בעיות עם שימוש בכונן 7200. הראשונה היא שכונני 7200 יותר רועשים ואני מעדיף להקטין את הרעש במחשב. השניה החא שיש לי רק כונן אחד כזה (בגודל 1TB), וזה לא מספיק בשביל יתירות (RAID1 דורש לפחות כונן אחד נוסף). בעקרון יש לי כונן 1TB ‏7200 נוסף, אבל לפי בדיקת SMART יש לו בעיית sector relocation (אם אני זוכר נכון), ולכן אני משתמש בו רק עבור ה-pagefile ולא מחזיק עליו שום קבצים. אמנם הבעיה הזו לא החמירה כבר תקופה די ארוכה, אבל זה יהיה אבסורד להשתמש בדיסק כזה עבור יתירות, לא?

התוכניות שהצעת לגבי גיבוי דומה למה שאני מתכנן כבר הרבה זמן, אבל אף פעם לא מגיע כדי להגדיר. כרגע אני מגבה אל המחשב השני ולדיסק חיצוני, אבל אני לא משתמש בתוכנה אוטומטית עבור זה. ניסיתי בעבר את SyncToy אבל נתקלתי בכל מיני בעיות איתה ולכן חזרתי לגיבויים ידניים (כשאני זוכר לבצע אותם). אשמח לקבל המלצה לתוכנה אחרת.

אגב, מה הבעיות שאתה רואה בגיבוי מבוסס-ענן? אני לא מתלהב מהאפשרות שהחברה תפשוט את הרגל או שמישהו לא מורשה ייגש למידע, אבל לפחות את הבעיה השניה אני חושב שאוכל לפתור עם TrueCrypt.‏

פורסם

1. בהחלט לא מומלץ להשתמש בכונן עם בעיה ככונן לאחסון מידע כלשהו. אני מניח שהוא יחסית חדש (1TB זה אומר מהשנים האחרונות). תבדוק אם הוא עדיין באחריוחת ואם כן אז תחליף אותו (במקרה שלא עשית זאת).

2. גיבוי ידני אינו גיבוי פשוט משום שהוא נועד לכשלון מראש. הסיכוי שתשכח/תתעצל/תדחה את הגיבוי גדל אקספוננציאלית בכל יום שעובר. גיבוי צריך להעשות באופן אוטומטי. אני משתמש בסקריפט Robocopy פשוט שמתוזמן לרוץ פעם ביום במתזמן המשימות של מערכת ההפעלה כדי לגבות את המידע החשוב בכל יום לכונן חיצוני. אם רוצים יתירות של הגיבוי עצמו (מגן בעיקר מפני כשל חומרתי, לא מפני גניבה, שריפה, הצפה) אז אולי אפיל כדאי לשקול יצירה של מערך RAID1 עבור הגיבוי, אם כי צריך לחשוב אם זה הכרחי.

באופן כללי הייתי פחות ממליץ לעבוד עם מערך RAID5 על בקר לוח האם, זה אפשר אבל לא אידאלי. כמו כן, לשימושים שלך אני גם לא רואה בזה צורך.

3. דווקא מכך שחברה תפשוט את הרגל אני פחות חושש, זה מקביל לכך שהכונן החיצוני שלך כושל ואתה נאלץ להחליפו. הרי מידע לא תאבד ככה כי צריך להיות לך עותק נוסף שלו במקום אחר. נושא הגישה מטריד אותי מעט ויותר מטריד אותי נושא הבעלות על החומר. האם חברת "הענן" מתירה לעצמה זכות לעשות שימוש במידע הזה, כלומר בכך שאתה מעביר אותו לשרתים שלה אתה למעשה מוסר לה זכויות שימוש מסוימות בחומר? התשובה על זה לא לגמרי ברורה תמיד. גם מטריד אותי שהם יכולים לשנות את תנאי השימוש בכל-עת, גם אם הם מודיעים, לא תמיד השינויים ברורים מקריאה ראשונה. מהסיבות האלה ועוד כרגע עדיין לא גיבשתי לגמרי דעה על שירותי הענן.

פורסם
  • מחבר

לגבי הדיסק התקול, הבעיה היא שאני לא מוצא את הקבלה ולא זוכר איפה קניתי את הדיסק הזה. מעבר לזה, הדיסק מתפקד טוב ורק בדיקת SMART מעידה שיש בעיה. זה מספיק בשבילי כדי לא לשמור עליו קבצים, השאלה אם זה מספיק כדי לדרוש החלפה שלו?

יש לי שלושה דיסקים של 2TB וחשובה לי יתירות (במחשב בחדר העבודה, ב-HTPC אני יכול לוותר עליה). איזה פתרון טוב יותר אתה רואה מ-RAID5? הלוח שלי הוא Gigabyte GA-P55A-UD3P והבקר RAID (אם אפשר לקרוא לו כך) הוא הצ'יפסט P55 של אינטל.

אגב, את הדיסק הנוסף (ה-1TB התקין) אני מתכנן להעביר למחשב בסלון.

את הבעיה שאתה ואני רואים בגיבוי מבוסס-ענן אפשר אולי לפתור עם הצפנה. אם המידע מאוכסן ב-TrueCrypt volume אז גם אם תנאי השימוש משתנים עדיין אין לבעלי השירות אפשרות לגשת או להשתמש במידע.

פורסם

^לגשת הוא יוכל, למחוק למשל.

לשאלתך - הכי פשוט והכי בטוח הוא לקנות קשיחים נוספים לגיבוי. ישנן תוכנות רבות שמגבות אוטומטית תיקיות\מחיצות שלמות. מחירי הקשיחים היום

ברצפה, לרכוש כונן 2TB או שניים אמורים להיות מספיקים בהחלט. ישנם כונני 7200RPM מהירים ודי שקטים.

פורסם
  • מחבר

יש לי כבר שלושה כונני 2TB במהירות 5400, אני לא מתכוון להחליף אותם בכונני 7200. השאלות שנותרו הן:

- RAID - כן או לא? אני נוטה כן להשתמש ב-RAID כי אני מעוניין ביתירות, ולא בטוח שגיבוי לבד (אפילו בתדירות גבוהה) יספיק לי.

- אם RAID - איזו רמה? RAID5 נראה לי הכי אפקטיבי לניצול שלושה כוננים עם יתירות לכל המידע

- אם RAID - חומרה או תוכנה? מצד אחד RAID חומרה (או ליתר דיוק ה-FakeRAID שלוח האם נותן) נראה לי יותר מתאים, כי אני מעוניין להיות מסוגל להריץ גם לינוקס על אותו מחשב וחשוב לי שהמידע יהיה נגיש מחלונות ומלינוקס. מצד שני RAID תוכנה מתאים יותר כי אם הלוח מת יהיה לי הרבה יותר קל להגיע למידע מאשר למצוא לוח חדש עם אותו בקר RAID כמו שיש בלוח העכשווי שלי.

דיעות?

פורסם

אם היתרות (redundancy) חשובה לך, והשימוש הוא לצרכי אירכוב בעיקר, לך על RAID5.

לגבי הדיסק התקול, אתה לא צריך למצוא את החנות. לך לאתר היצרן ותפתח RMA, ועקוב אחרי ההוראות (אחרי שתוודא באתר שהדיסק הוא תחת אחריות יצרן). תצטרך לשלוח אותו לחו"ל (סביר להניח לאנגליה) על חשבונך, אבל המשלוח אליך לא יהיה בתשלום.

RAID שלוח האם מספק הוא RAID חומרה. יש שבב שמסדיר את זה על הלוח. היישומים הנפוצים הם השבבים של אינטל. זה לא RAID מזויף. אני לא מכיר RAID תוכנה, או RAID מזויף. וגישה לחומר אחרי שהלוח מת תהיה רק באמצעות תוכנות דוגמת R-STUDIO וכיוב'.

מה שכן, אם אתה רוצה גישה מלינוקס תקפיד כאשר אתה מאתחל את המערך מחלונות להשתמש ב-MBR ולא ב-GPT.

GPT היא השיטה החדשה של טבלאות - מייצרת יתרות של טבלאות למקרה של קריסה. יותר בטוחה, אבל לא מזוהה על ידי מערכות הפעלה ישנות יותר, ואני גם לא בטוח שלינוקס על כל טעמיה השונים תזהה.

פורסם

לפני שניגשים לבניית מערך גיבוי צריך להגדיר את הדרישות, התקציב (או האמצעים הזמינים) ולבנות את תוכנית הגיבוי המתאימה ביותר בהתאם לכך.

1. אני לא יכול כל כך להמליץ בפה מלא על RAID5 על בקר לוח האם, בטח לא לעבודה כמערך ראשי שבו נמצאת גם מערכת הפעלה.

2. אל תבצע RAID תוכנתי ב-Windows גם זה לא פתרון אידאלי. ב-Linux הסיפור אחר.

3. אם אתה זקוק לגשת למידע מיורת ממחשב אחד (לא הבנתי אם כן או לא) אני הייתי שוקל להשתמש ב-NAS שבו כל המידע יימצא ב-RAID5 או RAID1 בהתאם לכמות כוננים.

4. אם NAS הוא לא אפשרות, אני עדיין חושב שתוכנית גיבוי בקוויים הכלליים של זאת שהצגתי תהיה פתרון יעיל יותר.

5. שוב חשוב להדגיש. RAID אינו גיבוי. מדבריך קיבלתי את הרושם שאתה חושב שאם במחשב הראשי החומר יימצא ביתירות אז זה ייתן לך "הנחה" קטנה בכל הנוגע לתדירות ועקביות הגיבוי. אני מעוניין להזהיר מראש שזאת הנחה שגויה. מחיקה של החומר בטעות, נזק פיזי למערכת, וירוס או כל מזיק אחר שיהפוך את החומר ללא נגיש ואז כל היתירות לא שווה הרבה. יתירות חשובה במערכות שבהן כל זמן השבתה הוא קריטי (מבחינה כספית או מכל בחינה אחרת) ולכן צריך לצמצם אותו למינימום האפשרי. במחשבים ביתיים/עסקיים ממוצעים שבהם הזמן השבתה של שעה-מספר שעות אינו סופר קריטי הרבה יותר נכון לדעתי ליצור Image של כונן/מחיצת מערכת ההפעלה (לאחר כל ההגדרות והתקנת כל התוכנות שלהן זקוקים, ולגבות אותו כמובן) כך שבמקרה של כשל תוכנתי ואפילו חומרתי של הכונן ניתן לחזור לעבודה תוך מספר דקות. את המידע עצמו אפשר לשמור על אותו כונן או על כונן נפרד, אך לגבות בכל יום או בכל תדירות רלוונטית אחרת.

6. השגיאה שקיבלת בנתוני ה-S.M.A.R.T מעידה על סקטורים פגומים (שהוחלפו). זאת בהחלט סיבה להחלפת הכונן במסגרת האחריות.

לגבי גיבוי הענן.

אני מחלק את הסוגיות בנושא עבור משתמשים פרטיים/עסקיים קטנים לשני נושאים מרכזיים:

טכניים:

1. יכולת של מישהו אחר לגשת לחומר - אני לא חושב שזה נכון לצפות שהצפנתו תמנע גישה של ספק השירות למידע במידת הצורך.

2. סגירה פתאומית או נפילה של השירות - לא מטריד אותי כי זה בדיוק כמו שכושל כונן הגיבוי. עותק נוסף של החומר צריך להיות לך בכל מקרה.

3. הזמן שלוקח לגבות נפחים גדולים - עניין סובייקטיבי שתלוי גם באמצעי שעומדים לרשות המשתמש.

4. פריצה של האקרים, גישה שלהם לתוכן או גניבת פרטי המשתשמ (שם משתמש, סיסמה, כתובת דוא"ל). בשלב מסוים אני מניח שהשירותים הללו יהפכו ליעד מפתה למדי להאקרים מסוגים שונים בהנחה שאכן מגמת המעבר לענן תמשיך ותגדל.

כל זה לא ממש מטריד אותי. מלבד הדיון התיאורטי, אלו דברים שצריך לקחת בחשבון, אבל לא ליחס להם חשיבות יתר.

הנושא השני הוא זכויות קניין רוחני וזכויות יוצרים. ספק השירות צריך לגשת ולעבוד עם המידע שלך לצורך עבודתו (גיבוי השרתים, ניהול השרתים, עדכוני חומרה/תוכנה וכן הלאה). לפעמים ספק השירות אפילו מעביר פרטים מסוימים על המידע שלך לצד-שלישי שאיתו הוא עובד כקבלן משנה לצורך אספקת השירות. כל זה ברוב המקרים בסדר, ואמנם אפשר לפתח תיאוריות קונספירציה בנושא, אבל לדעתי זה בגבול הסביר, בייחוד למי שלא מאחסן מידע סודי.

אולם, חלק גדול מספקי השירות מוסיפים סעיפים מעורפלים לגבי המחאת זכויות. כלומר, ברגע שאתה מעלה חומר לשרתים שלהם, אתה לא מאבד את זכויות היוצרים שלך אך אתה נותן לספק השירות רשות להשתמש בחומר בצורה מסוימת. זה בעיקר מה שמדאיג אותי. לפני כמה שבועות Dropbox עדכנו את תנאי השירות שלהם ושינו שם את הסעיפים הנוגעים בדיוק לנושא הזה. אני לא זוכר את הפרטים במדויק, אז ייתכן שיש פה איזה אי-דיוק מסוים, אבל את הנוסח החדש היה אפשר לפרש כהכרזה שלהם שכל החומר שמאוחסן בשרתים שלהם הופך להיות בחזקתם. קמה זעקה לא קטנה והם מיהרו יחסית לעדכן שוב את הסעיפים ולנסות להבהיר למה הכוונה תוך שהם מבטיחים שהגישה והשימוש בחומר הוא רק למטרת אספקת השירות וכדומה. יש כאלה שזה הרגיע אותם, אחרים לא. זאת אחת הדאגות הגדולות שלי באחסון מבוסס ענן, שכרגע לפחות לא ממש יודע להגיד מה עמדתי המלאה לגביה.

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

עוד נקודה שחשוב לבחון ולתכנן כחלק מתוכנית הגיבוי היא "היום שאחרי". מה קורה אחרי אובדן מידע. עד כמה קל לשחזר את המידע? הרבה פעמים אנשים מגבים ומגבים וברגע האמת מגלים שכל הגיבויים לא היו שווים הרבה כי תהליך השחזור לא ממש נוח. לכן צריך גם לבדוק את יכולת השחזור של המערכת מדי פעם. אני גם ממליץ לא להשתמש בתוכנות גיבוי שעושות שימוש בתבניות קנייניות שרק הן עצמן יודעות לעבוד איתה. יש לא מעט תוכנות שמגבות בתבנית Zip שזה עוד סביר, אבל לדעתי, בייחוד כשהיום נפחי אחסון זולים למדי, אין כמו סנכרון. הקבצים המגובים זמינים כמו שהם בהתקן הגיבוי ואין שום בעיה לשחזר אותם.

או אם לסכם:

1. תגדיר מהם הצרכים שלך ובהתאם לכך תתכנן את תוכנית האחסון והגיבוי

2. אני ממליץ על שימוש בסנכרון (ואפילו בניהול גרסאות) מאשר שימוש בתבניות דחוסות או קנייניות (אם כי זה כמובן סובייקטיבי לגמרי).

3. אני ממליץ לבנות תוכנית גיבוי:

א. אוטומטית - אחרת היא לא שווה הרבה.

ב. פשוטה - לא צריך לסבך דברים סתם כך. גיבוי להתקן אחד עד שלושה התקנים (חלקם או כולם חיצוניים) אמור להספיק עבור המשתמש הממוצע.

פורסם
  • מחבר

mulderfox, השימוש במערך הוא גם למערכת הפעלה וגם לקבצים. לא לגיבוי. את הגיבויים אני מבצע למחשב אחר.

הבלאגן שבמשלוח דיסק לחו"ל לא שווה לי. אני אנסה למצוא באיזו חנות קניתי את הדיסק, ואגש לשם לנסות לנצל את האחריות (אם עדיין יש).

לא אני המצאתי את המונח FakeRAID. יש מעל מאה אלף תוצאות בגוגל למושג הזה. המשמעות שלו היא שלא מדובר ב-RAID חומרה "אמיתי" אלא בכזה שדורש דרייברים שמבצעים את רוב העבודה, דומה קצת לרעיון של "מודם תוכנה". אין לי בעיה לקרוא לזה RAID-לוח-אם. למיטב הבנתי ב-RAID חומרה אמיתי אין צורך בדרייברים, כי מערכת ההפעלה רואה את הדיסק הלוגי שהבקר מציג לה.

אם R-Studio מסוגלת להוציא בשלמותו את המידע מדיסק שישב במערך של RAID-לוח-אם אז אני אהיה הרבה יותר רגוע לבחור באופציה הזו.

About:blank, מדוע אתה לא יכול להמליץ על RAID5 באמצעות לוח האם עבור דיסק שעליו יושבת מערכת ההפעלה? אם הביצועים לא נופלים מאלה של דיסק בודד אז זה מספיק עבורי. העיקר שתהיה יתירות ושלא אצטרך לבזבז 50% מנפח הדיסק עבורה (כפי שקורה ב-RAID1).

לגבי RAID תוכנה ב-Windows, הביצועים וצריכת המעבד שלו אמורים להיות לא פחות טובים משל RAID-לוח-אם, לפחות לפי המבחן הזה. איזו סיבה יש להמנע ממנו מלבד חוסר התאימות של המערך ללינוקס?

אני בהחלט מתכוון לממש פתרון גיבוי אוטומטי בדומה למה שאתה מתאר (סנכרון קבצים), אבל אני לא מכיר דרך לגבות באופן אוטומטי את מערכת הההפעלה, התוכנות וההגדרות. אם צריך לאתחל את המחשב ולהריץ גוסט אז זה לא משהו שיכול להחליף יתירות בעיני, כי מה שייקרה זה שאני לא אבצע את זה בתדירות מספיק גבוהה.

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

פורסם

יש שלוש שיטות עיקריות ליצירת RAID, בקצרה:

1. בקר RAID ייעודי - כרטיס הרחבה המכיל בקר RAID ייעודי שהוא זה שמבצע על פעולות החישוב ועיבוד הנתונים.

2. RAID תוכנתי, נוצר באמצעות תוכנה. עומס עיבוד הנתונים נופל על חומרת המערכת (בחומרה של ימינו זה זניח, מדובר על אחוזים בודדים מיכולת העיבוד של המעבד).

3. RAID היברדי שיש כאלה שקוראים לו FakeRAID (אני באופן אישי לא אוהב את המונח הזה). מדובר על כרטיס הרחבה שמכיל חיבורים להתקני האחסון וקושחה כדי לנהל את ה-RAID. עומס עיבוד הנתונים נופל על חומרת המערכת המאחסנת, אך המערך עצמו מנוהל על-ידי הקושחה שעל הבקר. RAID שנעשה על לוח האם הוא RAID מהסוג הזה, כאשר המעבד של המערכת אחראי לעיבוד ואילו ניהול המערך נעשה באמצעות קושחה שבשבב הגשר הדרומי של ערכת השבבים. החסרונות של RAID מהסוג הזה הוא שבמוקדם הוא במאוחר הוא נוטה ליפול. זה לא אומר שאסור להשתמש בו, פשוט אומר שצריך לקחת בחשבון שזאת לא בהכרח הדרך הכי אמינה ליצירת RAID.

לשאלותיך:

א. אני לא ממליץ על RAID5 על בקר לוח האם מהסיבה שציינתי לעיל, יציבות לאורך זמן, וגם בגלל שמלבד היתירות לא ממש תקבל את היתרונות היחסיים של RAID5 בקריאת נתונים וכתיבתם. שחזור של מערך RAID5 על בקר לוח האם לוקח הרבה זמן ואינו פשוט, בייחוד אם הסיבה לכך היא שהבקר שעל לוח האם כשל. לעומת זאת, RAID1 שנעשה על בקר לוח האם אינו בדיוק RAID1 "אמיתי" (שבו אי אפשר לגשת למידע מחוץ למערך ה-RAID). בכמה וכמה בקרים של לוחות אם שבהם אני נתקלתי, גם של Intel וגם של AMD, המידע זמין גם מחוץ למערך ה-RAID. כלומר, נניח שכשל הבקר שעל לוח האם, אין צורך לשחזר את המערך או למצוא לוח אם עם בקר זהה או קרוב מספיק כדי לנסות לשחזר את המערך, פשוט מנתקים את אחד הדיסקים מעבירים אותו למחשב אחר והוא זמין, גם אם המערך היה על בקר גשר דרומי של Intel ועכשיו מחובר ל-AMD ולהפך. שוב, זה תלוי בבקר, לא בכולם זה ככה, אבל הסיכון לאובדן כל המידע שבמערך הוא נמוך יותר.

ב. אני לא בטוח ש-Windows בכלל מאפשרת לך לבצע RAID5, בטח לא בכל הגרסאות, וגם אם כן, אז מערכת ההפעלה הנ"ל ידועה לשמצה בכל הנוגע לניהול מערכי RAID, לפחות בגרסאת הביתיות. שוב, מדובר על יציבות המערך לאורך זמן. אם אתה מחפש RAID תוכנתי אז לדעתי מומלץ הרבה יותר לבצע אותו על מערכת Linux או BSD.

ג. אני לא רואה טעם לבצע Image של מערכת ההפעלה באופן סדיר. אני תמיד ממליץ לבצע את ה-Image לאחר התקנת המערכת, התקנת כל התוכנות שבהן משתמשים (ואני גם ממליץ לעבוד עם תוכנות Portable עד כמה שאפשר) והגדרת כל ההגדרות השונות במערכת. זה מספיק. אם אתה מסוג המשתמשים שכל הזמן מתקין ומסיר תוכנות ומבצע שינויים תכופים לסביבת מערכת ההפעלה, אז קודם כל הייתי ממליץ לך לא לעשות זאת מסיבות שונות שאני לא אכנס אליהן עכשיו, וגם אם זה מצב נתון אז בהחלט יש פתרון. אני יודע שאתה יכול לתזמן את Acronis True Image למשל לבצע Image מתוך מערכת ההפעלה בזמנים הרצויים לך (נניח במהלך הלילה). אני בטוח שגם תוכנות אחרות ליצירת Image מאפשרות את הפונקציונליות הזאת.

ד. גם כשהמידע שלך מוצפן בענן זה לא אומר שהוא מוצפן מפני כולם. זאת אולי שכבת הגנה נוספת מפני האקרים מזדמנים, אם מישהו גונב את פרטי החשבון שלך (אני לא יודע אם ברגע שהתחברת לשירות אז כל המידע זמין או שכשכבת הגנה נוספת כדי לגשת למידע מוצפן עליך להזין סיסמה נוספת) וכדומה. הרי לא הגיוני שלשירות אחסון לא תהיה גישה למידע המאוחסן בו (רק תחשוב על כמות המידע הלא חוקי שאפשר יהיה לאחסן ככה, ואני לא מדבר רק על פיראטיות תוכן אלא על דברים הקשורים לבטחון, פשעי "צווארון לבן" וכדומה). זכויות קניין רוחני ויוצרים הן כבר בעיה. לא מעט שירותי ענן, כולל אלו של Google, מציגים תנאי שירות בעייתיים עבור חלק מהמשתמשים. ברגע שהעלית לשם משהו, טקסט, תמונה וכדומה אתה למעשה נותן לספק השירות את הזכות להשתמש בתוכן הזה. אתה עצמך לא מעבד את זכויות היוצרים (אם זה חומר שאתה יצרת) אבל מקנה לספק השירות שותפות מסוימת בהן. לדוגמה, ובהסתייגות מכך שלא בדקתי לאחרונה ואולי זה השתנה, בתנאי השירות של כלי התרגום של Google כתוב במפורש של-Google יש זכויות שימוש או משהו דומה בכל טקסט שאתה מעלה לשם. אז תאר לך שהעלית לשם מכתב עסקי עם עמית מחו"ל ובו רעיון שאתה מגדיר כסודי או לפחות רגיש...עלולות להיות לזה השלכות. לא מזמן היה סיפור דומה עם Dropbox. אז נכון, למשתמש הביתי הממוצע זה לא ממש רלוונטי, אך אותי זה קצת מטריד, וכאמור, עדיין לא גיבשתי דעה מלאה על הנושא אז כך שכרגע אני לא נגד אבל גם לא בעד.

ארכיון

דיון זה הועבר לארכיון ולא ניתן להוסיף בו תגובות חדשות.

דיונים חדשים