ערוץ סיבים לעומת iSCSI: המלחמה נמשכת

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

הזמן שהתערב ראה הרבה התלהמות לא מושכלת לגבי מי עדיף. לפעמים הדיון ב- iSCSI נגד FC הגיע לרמה של מלחמת דת.

[גם ב- .com: הורד את הצלילה העמוקה של Logan Harbaugh בארכיון וקבל את היסודות של ציות לתקנות. | למד כיצד כפילות נתונים יכולה להאט את הצמיחה הנפוצה של נתונים באמצעות דו"ח הצלילה העמוקה של קית 'שולץ. ]

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

עכשיו כשאנחנו כשנה במורד הפייק אחרי אישור תקן FCoE (FC over Ethernet), הדברים לא טובים בהרבה. קונים רבים עדיין לא מבינים את ההבדלים בין תקני iSCSI לבין ערוץ הסיבים. למרות שהנושא יכול למלא ספר בקלות, הנה סקירה מהירה.

יסודות ה- FC

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

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

FC זמין במהירות 1Gbps, 2Gbps, 4Gbps, 8Gbps, 10Gbps ו- 20Gbps. מתגים והתקנים התומכים במהירויות 1Gbps, 2Gbps, 4Gbps ו- 8Gbps בדרך כלל תואמים לאחור לאחיהם האיטיים יותר, בעוד שמכשירי 10Gbps ו- 20Gbps אינם מתאימים, בשל העובדה שהם משתמשים במנגנון קידוד מסגרות שונה (בדרך כלל נעשה שימוש בשני אלה. לקישורי interswitch).

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

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

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

הגרעיני ב- iSCSI

iSCSI הוא פרוטוקול רשת אחסון הבנוי על גבי פרוטוקול הרשת TCP / IP. אושר כסטנדרט בשנת 2004, הטענה הגדולה ביותר לתהילה של iSCSI היא שהיא פועלת על גבי ציוד רשת זה שמריץ את שאר הרשת הארגונית. זה לא דורש ספציפית חומרה נוספת, מה שהופך אותה לזולה יחסית ליישום.

מנקודת מבט ביצועית, iSCSI משתרך אחרי FC / FCP. אך כאשר ה- iSCSI מיושם כראוי, ההבדל מסתכם בכמה אלפיות שניות של זמן אחזור נוסף בגלל התקורה הנדרשת בכדי להכיל פקודות SCSI במסגרת פרוטוקול הרשתות TCP / IP הכללי. זה יכול לעשות הבדל עצום בעומסי קלט / פלט עסקיים גבוהים במיוחד והוא המקור לרוב הטענות ש- iSCSI אינו מתאים לשימוש בארגון. עומסי עבודה כאלה הם נדירים מחוץ ל- Fortune 500, עם זאת, ולכן ברוב המקרים דלתא הביצועים צרה בהרבה.

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

iSCSI יכולה להחזיק את עצמה עם FC מבחינת תפוקה באמצעות קישורי Ethernet מרובים של 1Gbps או 10Gbps Ethernet. זה גם מרוויח מלהיות TCP / IP בכך שהוא יכול לשמש למרחקים גדולים באמצעות קישורי WAN קיימים. תרחיש שימוש זה מוגבל בדרך כלל לשכפול SAN ל- SAN, אך הוא קל משמעותית וזול יותר ליישום מאשר חלופות FC בלבד.

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

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

ערוץ סיבים ב- IP

FCoIP (פרוטוקול Fibre Channel over Internet) הוא פרוטוקול נישה אשר אושר בשנת 2004. זהו תקן להכללת מסגרות FCP בתוך חבילות TCP / IP כך שניתן יהיה לשלוח אותן ברשת TCP / IP. הוא משמש כמעט אך ורק לגישור בדים של FC במספר אתרים כדי לאפשר שכפול וגיבוי SAN ל- SAN למרחקים ארוכים.

בשל חוסר היעילות של פיצול מסגרות FC גדולות למספר חבילות TCP / IP (מעגלי WAN בדרך כלל אינם תומכים בחבילות מעל 1,500 בתים), הוא אינו בנוי לחביון נמוך. במקום זאת, הוא בנוי כדי לאפשר קישור בין בדי ערוץ סיבים המופרדים גיאוגרפית כאשר סיבים כהים אינם זמינים לעשות זאת עם FCP מקומי. FCIP נמצא כמעט תמיד בשערים מרחוק של FC - למעשה גשרים של FC / FCP אל FCIP - ולעיתים נדירות אם בכלל נעשה שימוש מקורי על ידי התקני האחסון כשיטת גישה לאחסון.

ערוץ סיבים באמצעות אתרנט

FCoE (Fibre Channel over Ethernet) הוא פרוטוקול רשת האחסון החדש ביותר של החבורה. אשרור כסטנדרט ביוני אשתקד, FCoE הוא התשובה של קהילת ערוץ הסיבים ליתרונותיה של iSCSI. כמו iSCSI, FCoE משתמש ברשתות אתרנט רב תכליתיות סטנדרטיות לחיבור שרתים עם אחסון. בניגוד ל- iSCSI, הוא אינו פועל על TCP / IP - זהו פרוטוקול אתרנט משלו התופס מקום ליד ה- IP במודל OSI.

חשוב להבין את ההפרש הזה מכיוון שיש לו תוצאות טובות וגם רעות. הטוב הוא שלמרות ש- FCoE פועל על אותם מתגים למטרות כלליות שעושה iSCSI, הוא חווה חביון מקצה לקצה נמוך משמעותית בשל העובדה שאין צורך ליצור ולפרש את כותרת ה- TCP / IP. הגרוע הוא שלא ניתן לנתב אותו דרך WAN TCP / IP. כמו FC, FCoE יכול לרוץ רק על רשת מקומית ודורש גשר כדי להתחבר למרקם מרוחק.

בצד השרת, רוב היישומים של FCoE משתמשים ב- 10Gbps Ethernet FCoE CNAs (מתאמי רשת ממוחשבים), שיכולים לשמש כמתאמי רשת וגם כ- FCoE HBA - מה שמוריד את עבודת הדיבור לאחסון בדומה לאופן שעושים ה- FC HBA. זו נקודה חשובה שכן הדרישה ל- FC HBA נפרד הייתה לרוב סיבה טובה להימנע לחלוטין מ- FC. ככל שעובר הזמן, בדרך כלל שרתים נשלחים עם רכיבי CNA מסוג FCoE המובנים, ובעצם מסירים זאת כגורם עלות לחלוטין.

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

מחברים את הכל ביחד

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

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

מאמר זה, "ערוץ הסיבים לעומת iSCSI: המלחמה נמשכת", הופיע במקור באתר .com. קרא עוד בבלוג של עומס המידע של מאט פריג 'ועקוב אחר ההתפתחויות האחרונות באחסון נתונים ובניהול מידע באתר .com.