נשלח: 01/03/2011 21:06
בוא נתחיל בהבהרה קטנה, אני לא חולק על erezsolan מכיוון שאכן מקריאת מסמכים ופוסטים מקצועיים תמיד מוזכר כי RAID 5 יפזר את ה PARITY שלו על כל הדיסקים המשתתפים באותו רייד, אך אף אחד מהפוסטים לא מזכיר מהי הסביבה הנתונה אלא מדבר רק על סוגי ההגנה בצורה כללית, בעקבות זאת חשוב להעלות פה כמה נקודות שאולי ייעזרו להבהיר למה אני מתכוון.
בואו נקח לדוגמא דיסק טיפוסי של 1TB, אותו הדיסק הוא בעל קצב נתונים (פנימי) של בערך 60MB לשניה, עכשיו בואו נניח שאותו הדיסק משתתף ברייד 5 טיפוסי של 4+1 (המינימום הוא 3 דיסקים אבל אני בא מעולם האיחסון ואצלנו הסטנדרט הוא 5 דיסקים) כלומר 5 דיסקים כפול 60 מגה בייט לשניה ייתנו לנו בעולם אידיאלי 300 מגה בייט לשניה, ואתם אומרים וואוו המון!
אך בואו נפחית לרגע את ה 25% OVERHEAD שיש ל Raid5 ואנחנו צריכים לקבל 225 מגה בייט בשניה של BANDWITH בואו גם נוריד עוד 25% לכתיבות PARITY ועוד מני מריעין בישין שאני אפרט בהמשך ואנחנו כבר בסביבות ה 150 מגה בייט לשניה, עכשיו בואו נראה משתמש מערך מבוסס תוכנה שהצליח להגיע למספרים הנ"ל אפילו בהעתקות פנימיות, לא קיים! למה? כי מערכת מבוססת תוכנה לא מסוגלת לתמוך בעיבוד PARITY שלRaid 5 מהיר כל כך ולכן היא בד"כ מגבילה אותו לדיסק בודד, ולכן המספרים שבד"כ תראו ממערכת כזאת בהגנת Raid 5 היא 60-80 מ"ב לשניה שהם הרוחב פס של דיסק בודד אם הוא מנוצל כראוי ע"י המערכת.
עכשיו נשליך את כל הכתוב מעלה על Raid 5 כאשר אנחנו כותבים מידע במערכות מבוססות תוכנה הפקטור המשמעותי בכתיבה תאמינו או לא אלו חישובי ה PARITY, כי לכתוב סתם מידע לדיסק כל אחד יכול, אבל כתיבת PARITY היא שונה בתכלית מכתיבה רגילה, על כל כתיבה טיפוסית של 8K צריך להיות מנגון אשר:
1. מוודא את הכתיבה
2. מוודא שנכתב ביט PARITY תואם במיקום הנכון
3. מנגנון שדואג לפיזור כתיבות ה PARITY בסדר הנכון
4. מנגנון שעובר ובודק את רציפות הכתיבות ומדווח תקלות – Stripe consistency
בהנחה שאלו מתבצעים בתוכנה בלבד ללא תמיכה של בקר חומרה ייעודי, המעבד וראשי הדיסקים פשוט לא יעמדו בעומס, מכיוון שכל מה שהמעבד והדיסקים יהיו עסוקים בו יהיה פשוט לשלוח אינסוף פקודות (בהנחה שאנחנו רושמים באופן רציף – סוג הכתיבות הכי קל!) של הכתיבות וחישובי ה PARITY ולקבל עליהם במינימום לפחות את חלק מ שלושת האישורים הבסיסיים שהוזכרו מקודם,
עכשיו בהנחה שה PARITY אכן סובב את כל הדיסקים, ובהנחה שבנוסף לחישובים ישנה גם מערכת ההפעלה של ה RAID שלא חס וחלילה נשכח שהעומס גם עליה הוא בלתי רגיל, לא אפקטיבי עד לא אפשרי למערכי ה RAID מבוססי תוכנה ללא סיוע חומרה לכתוב CHANK של PARITY על כל דיסק במערך תוך כדי העבודה.
הבעיה נפתרה ע"י כך שברוב מערכי התוכנה ישנו דיסק יעודי אשר מתעד את רישומי ה PARITY, כאשר הדבר מתבטא בחיסכון משמעותי של הפעולות המוזכרות. חלקכם יקרא לו RAID4 כמו שהזכיר המשתמש erezsolan חלקכם אשר מכירים מערכות איחסון מבוססי חומרה יקראו לו RAID3 – אבל מדובר בסה"כ בישומים שונים של RAID5 כאשר בכל מקרה אם נאבד דיסק אחד במערך אנחנו במצב Degraded וכאשר נאבד את הדיסק הבא אחריו אנחנו עמוק בח!$%& א.
לסיום אני מקווה שכולנו מבינים שאנחנו לא מתעסקים פה בדיסקים של 15K עם INTERFACE של FIBER ואו SAS במהירויות של 4GB ואו 6GB, אנשים בונים מערכים מבוססי תוכנה עם דיסקים של SATA במהירות 7200RPM עם מנגנון CACHING ו queue פנימי הבסיסיים של הדיסקים, כמו כן אלו דיסקים המצטיינים בעיקר בכתיבות רציפות sequential כאשר כתיבות RANDOM כלומר אקראיות פשוט "יהרגו" את הדיסק וזמני התגובה שלו יהיו לא אפקטיביים בעליל! – גם לא למערך הבסיסי שבבסיסי של RAID5 עם PARITY מפוזר על פני כמה דיסקים.
אני מקווה שהצלחתי להסביר את עצמי.
בואו נקח לדוגמא דיסק טיפוסי של 1TB, אותו הדיסק הוא בעל קצב נתונים (פנימי) של בערך 60MB לשניה, עכשיו בואו נניח שאותו הדיסק משתתף ברייד 5 טיפוסי של 4+1 (המינימום הוא 3 דיסקים אבל אני בא מעולם האיחסון ואצלנו הסטנדרט הוא 5 דיסקים) כלומר 5 דיסקים כפול 60 מגה בייט לשניה ייתנו לנו בעולם אידיאלי 300 מגה בייט לשניה, ואתם אומרים וואוו המון!
אך בואו נפחית לרגע את ה 25% OVERHEAD שיש ל Raid5 ואנחנו צריכים לקבל 225 מגה בייט בשניה של BANDWITH בואו גם נוריד עוד 25% לכתיבות PARITY ועוד מני מריעין בישין שאני אפרט בהמשך ואנחנו כבר בסביבות ה 150 מגה בייט לשניה, עכשיו בואו נראה משתמש מערך מבוסס תוכנה שהצליח להגיע למספרים הנ"ל אפילו בהעתקות פנימיות, לא קיים! למה? כי מערכת מבוססת תוכנה לא מסוגלת לתמוך בעיבוד PARITY שלRaid 5 מהיר כל כך ולכן היא בד"כ מגבילה אותו לדיסק בודד, ולכן המספרים שבד"כ תראו ממערכת כזאת בהגנת Raid 5 היא 60-80 מ"ב לשניה שהם הרוחב פס של דיסק בודד אם הוא מנוצל כראוי ע"י המערכת.
עכשיו נשליך את כל הכתוב מעלה על Raid 5 כאשר אנחנו כותבים מידע במערכות מבוססות תוכנה הפקטור המשמעותי בכתיבה תאמינו או לא אלו חישובי ה PARITY, כי לכתוב סתם מידע לדיסק כל אחד יכול, אבל כתיבת PARITY היא שונה בתכלית מכתיבה רגילה, על כל כתיבה טיפוסית של 8K צריך להיות מנגון אשר:
1. מוודא את הכתיבה
2. מוודא שנכתב ביט PARITY תואם במיקום הנכון
3. מנגנון שדואג לפיזור כתיבות ה PARITY בסדר הנכון
4. מנגנון שעובר ובודק את רציפות הכתיבות ומדווח תקלות – Stripe consistency
בהנחה שאלו מתבצעים בתוכנה בלבד ללא תמיכה של בקר חומרה ייעודי, המעבד וראשי הדיסקים פשוט לא יעמדו בעומס, מכיוון שכל מה שהמעבד והדיסקים יהיו עסוקים בו יהיה פשוט לשלוח אינסוף פקודות (בהנחה שאנחנו רושמים באופן רציף – סוג הכתיבות הכי קל!) של הכתיבות וחישובי ה PARITY ולקבל עליהם במינימום לפחות את חלק מ שלושת האישורים הבסיסיים שהוזכרו מקודם,
עכשיו בהנחה שה PARITY אכן סובב את כל הדיסקים, ובהנחה שבנוסף לחישובים ישנה גם מערכת ההפעלה של ה RAID שלא חס וחלילה נשכח שהעומס גם עליה הוא בלתי רגיל, לא אפקטיבי עד לא אפשרי למערכי ה RAID מבוססי תוכנה ללא סיוע חומרה לכתוב CHANK של PARITY על כל דיסק במערך תוך כדי העבודה.
הבעיה נפתרה ע"י כך שברוב מערכי התוכנה ישנו דיסק יעודי אשר מתעד את רישומי ה PARITY, כאשר הדבר מתבטא בחיסכון משמעותי של הפעולות המוזכרות. חלקכם יקרא לו RAID4 כמו שהזכיר המשתמש erezsolan חלקכם אשר מכירים מערכות איחסון מבוססי חומרה יקראו לו RAID3 – אבל מדובר בסה"כ בישומים שונים של RAID5 כאשר בכל מקרה אם נאבד דיסק אחד במערך אנחנו במצב Degraded וכאשר נאבד את הדיסק הבא אחריו אנחנו עמוק בח!$%& א.
לסיום אני מקווה שכולנו מבינים שאנחנו לא מתעסקים פה בדיסקים של 15K עם INTERFACE של FIBER ואו SAS במהירויות של 4GB ואו 6GB, אנשים בונים מערכים מבוססי תוכנה עם דיסקים של SATA במהירות 7200RPM עם מנגנון CACHING ו queue פנימי הבסיסיים של הדיסקים, כמו כן אלו דיסקים המצטיינים בעיקר בכתיבות רציפות sequential כאשר כתיבות RANDOM כלומר אקראיות פשוט "יהרגו" את הדיסק וזמני התגובה שלו יהיו לא אפקטיביים בעליל! – גם לא למערך הבסיסי שבבסיסי של RAID5 עם PARITY מפוזר על פני כמה דיסקים.
אני מקווה שהצלחתי להסביר את עצמי.
