מערכות production all in one

[DuuGi]

מערכות production all in one

עוד תרומה קטנה...
מגמה נוספת שרואים לאחרונה היא חברות שמציעות מערכות all in one , כלומר חומרה שכוללת סטורג' מקומי + מערכת ניהול יעודית שמתלבשת על ה-VMWARE.
כך שבעצם מכונת 2U אחת היא גם הסטורג' וגם ההוסט לשרתים הוירטואלים כאשר יש תוכנה או חומרה יחודית שמבצעת את ניהול הכתיבה/קריאה לסטורג' ושמירת המידע בכמה מכונות. (בדומה למה שעושים בסטורג ענן).
דוגמאות לחברות שהן יחסית מובילות שוק בתחום הן SIMPLIVITY ו- NUTANIX. כל אחת עושה את הדברים קצת שונה אבל הרעיון דומה.
גם כאן משתמשים בinline dedup ובמערכים משולבים של SSD ודיסקים מגנטיים.

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

 

[skepper]

עם יד על הלב, היית הולך לכיוון כזה ?

 

[DuuGi]

לי זה לא מתאים כרגע אבל

אחרי שמבינים איך זה עובד זה בהחלט מתאים לסביבות מסוימות.

 

[harpiya]

לפי ההצלחה שיש לחברות שהזכרת

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

 

[yossik111]

יתרון אחד (לפחות) מובהק שאני רואה כרגע במערכת all in one

כנ"ל הוא אפשרות לקיצור זמנים משמעותי ביותר להורדה "מסודרת" של המערכת במקרה של כשל הספקות הכוח (הרבה נקודות כשל נחסכות כאן (בייחוד בקטע של התקשורת)) , מכווין שנוהל הורדה שכזאת אמור להיות מהיר מאד יחסית , הייתי חושב אפילו על
גיבוי סוללות בתוך מכשיר שכזה (הבנתי שזה מכשיר 2U ? ) כך שכאשר הוא חש בכשל של הספקות החשמל מתבצע נוהל חרום אוטומטי של ירידה "מסודרת" של המערכת (לא בשמיים ליישום - קיימים כבר מנגנונים כאילו ל"שרתים")
אני שובר כרגע ת'ראש איך לקצר זמנים עבור תרחיש של כשל כנ"ל עבור אופרציה מתוכננת שבו מפסיקים ל 6 שעות את הפסקת מתח חברת החשמל אצלנו ומסתמכים
על הגנרטור שידחוף את הups הרגיל שלנו , המערכת הווירטואלית שלנו כולל שני הסטוראג'ם שלנו הם אומנם בעלי הזנה כפולה אך קרה כבר מקרה לפני זמן לא רב שקפץ הממ"ט הראשי של ה ups בחדר שרתים – מסיבה לא ידועה כרגע , מכווין שכך (ומכווין שאין סיכוי שישביתו את עבודת הסניפים בחו"ל ) אני מארגן (דרך חבר שלי) זוג ups (בעלי הספק וביחוד קיבול סוללות די מינימליים ) שיחליפו את הזנת חברת החשמל , הבעיה היא שברגע כשל של הגנרטור ו/או ה ups הראשי - גורם הזמן הוא קריטי (אני בספק אם זוג ה ups יחזיקו 15 דקות יחד) במצב הזה אני נדרש להיות דרוך כול הזמן וכ'ו ...באסה , מערכת all in one כאמור הייתה פותרת לי הרבה כאב ראש ...

 

[ping2004]

לפחות לגבי Simplivity

כמה יתרונות
ואני לא ממש איש שרתים אז אל תתפסו אותי במילה

א. כל כתיבה מתבצעת לשתי מכונות במקביל ואם אין ACK על הכתיבה למכונה השניה הוא לא מחזיר ACK למערכת הפעלה לכן נפילת חשמל של שרת אחד משניים לא תגרום לבעיה למידע וה VM יכול לעבור לשרת השני באותו האתר.
ב. יש חסכון גדול ב IO כי לא כל דבר נכתב לדיסק מה שעושה את ה dedup ואת הדחיסה הוא כרטיס חומרה בניגוד לכל המתחרים לכן הוא לא מושפע מהעומס על השרת.
ג. בגלל היכולות הנ"ל גיבוי של VM (חוסך את הצורך בתוכנת גיבוי ) הוא מאוד פשוט לשרת אחר או לאמזון ורוחב הפס הדרוש הוא קטן בהרבה מפתרונות אחרים.
ד. שוב בגלל הנ"ל שטח הדיסק בפועל הוא גדול בהרבה ממה שמותקן בשרת
ה. הניהול הוא מ vcenter plugin

חסרון אחד קטן הוא שבינתיים זה ל vmware בלבד

 

[yossik111]

אני מדבר על המקרה ששתי המכונות באותו אתר

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

 

[DuuGi]

יוסי, ההתפסות שלך לנושא החשמל לא רלוונטית

כשחשמל נופל הוא נופל וזה ממש לא משנה אם יש לך 100 מכונות או 2 כי הגנת המידע קיימת בכל שרת על ידי סוללה או קבלים שמאפשרים לסיים את הכתיבה לפני הקריסה של המערכת.
מה שכתב PING מסביר את יתרונות המערכת באופן כללי ללא התיחסות ספציפית לנושא החשמל.
&nbsp
&nbsp

 

[yossik111]

אני רוצה להבין (ובאמת ובתמים בלי טיפ טיפה של ציניות)

כול שרת מכיל את המנגנון הגנת המידע (על ידי סוללה או קבלים שמאפשרים לסיים את הכתיבה לפני הקריסה של המערכת) ולעניני - שרתי 3650 / 3550 ibm ( ההוסטים ) + שני סטוראגים של נטאפ 2020 / 2220 ? כלומר לא "להתרגש" מכשל הספקת המתח (בנושא שרידות הדסקים / מידע ) ?
שוב , אני שואל באמת ובתמים (ובלי ציניות) מכווין שאני משקיע עכשיו המון אנרגיה בנושא הגיבוי החשמלי (כפי שכתבתי) לקראת האופרציה המתוכננת (וזה למה אני "נתפס" לקטע החשמלי ) .
התשובה לשאלה ששאלתי עתה תקבע אם אכן רלוונטי או לא (אישית אני מקווה (מאד) שאכן לא רלוונטי) .
יוס.

 

[DuuGi]

אז התשובה מורכבת

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

 

[yossik111]

ברשותך , אני דווקא רואה קשר / אופן ישיר ומובהק

בין אבוד מידע לדפיקת דיסקים , אולי אכן לא בפאזה הראשונה / המיידית בחלקי שניה הראשונות לאחר הפסקת החשמל , אך זה לא משנה את העובדה שאיבוד המידע יתרחש זמן קצרצר לאחר מכן לאחר כשל הדיסק - בכול מקרה הבנתי את כוונתך .
שוב , לא שלא קיימים יתרונות אחרים (ומשמעותיים יותר מן הסתאם ) למערכת all in one , אך הצגתי כרגע יתרון (שוב , לדעתי כמובן ) שהיה יכול לעזור לי כרגע עם הבעייה שכרגע אני ניצב מולה והוא אפשרות לקיצור משמעותי של זמן הורדה "מסודר" ובטוח יחסית של מערכת כנ"ל בזמן "חרום" (בוא נקח לדוגמא לחיץ soft reset (ריסט במובן shutdown) , כמה אלגנטי זה יכול להיות עבור מקרה כנ"ל ) .
יוס.

 

[F00D Is G00D]

אני אענה שניה לגבי הנטאפ

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

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

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

מה לגבי שאר סיכונים, כן - יש סיכוי כלשהוא לפגיעה אפשרית במידע. שכבה נוספת שתגן עליך היא ה RAID. אם המידע לא נכתב באופן עקבי למערך, יש ב ONTAP שתי אופציות לתאוששות מבעיות שהם לא רק parity reconstruct אלא ממש בעיות של חוסר עקביות: wafl iron, wafl scan זה שתי אופציות שכדאי מאוד להתייעץ עם התמיכה לפני שמריצים אותן (גם אם זה דחוף) - אבל טוב לדעת שהן קיימות.

<b>זו לא המלצה להקל ראש: </b>אני פשוט מציג לך את מה שבאמת קיים בתוך הברזל, כוח עליון כמובן ייכול להשפיע, וגם רכיבים פנימיים עלולים כמובן להינזק (בעיקר אם החזרת החשמל הייתה ברוטאלית "ספייק"), רוב תוכנות הניהול של מכשירי ה UPS ואם לא-תוכנות בקרה אחרות יודעות לקבל מה UPS הודעה על נפילת חשמלת ואם החשמל לא חזר לאחר כמה דקות הן ייכולות לפעול בשביל לכבות שרתים באופן מסודר.
בfas2020 שלך אמורה להייות לך אופציה כזו מובנת (זה בוטל ב ONTAP עדכני יותר) - וגם אם לא בשימוש באופציה המובנת, ניתן לכתוב סקריפט שיעשה זאת.


ערב טוב

 

[yossik111]

ראשית תודה על הסקירה המעניינת , החכמתי (כרגיל) .

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

(כמובן לא שמרתי את המייל שבו אני עורך את ההודעה הנ"ל ואני כותב אותה שוב – מגיע לי

)
אני רוצה ברשותך לדון באירוע "ברוטלי" של הפסקת חשמל לדוגמא (מהחיים) נפילת הממ"ט הראשי ביציאת המתח של ה ups כך שאינטרקציה עם הups להורדה מסודרת לא רלוונטית , ולהתרכז אם כך במנגנון ההגנה ה"פיזי" של הדיסקים (בנוסף למנגנונים שציינת).
ראשית שאלה אינטואיטיבית משהוא : מה הסיכוי שבאירוע כנ"ל ידפקו "פיזית" יותר משני דיסקים (2 נקודות כשל דיסקים עבור הפיילרים הנ"ל) , אם זה עוזר - SAS ב 2020 ו SATA ב 2220 ?
סתאם מעניין , בנוסף להגנה הלוגית של הכתיבה לדיסקים ושתי אופציות ההתאוששות שציינת , האם קיים איזה מנגנון "פיזי" יעודי בפיילרים האילו (מתח סוללה / מתח שיורי / קבלים וכ'ו ) שיוצר "חציצה" / ריכוך עבור הדיסקים שגורם בחלקי שניה הראשונים לאחר האירוע (שמתרחש באמצע הכתיבה עצמה לדיסקים) להורדה / תאום / כתיבה מסודרת וכ'ו בין הראשים לצלינדרים של הדיסק עצמו ?
יוס.

 

[F00D Is G00D]

הי

ראשית אתה אמור להימנע ממצב שקופץ לך מאמ"ת גם אחרי ה UPS בזכות שתי הזנות החשמל שהציוד תומך בהם.
&nbsp
אם רק המדף איבד חשמל, ONTAP יהיה מודע לזה וייגרום ל mutli disk failure panic. בזמן הזה המידע יישמר גם ב NVRAM לכתיבה מאוחר יותר.
במדף עצמו אין מנגנון כזה להמשך הכתיבה - הוא חתיכת פלסטיק ומתכת עם ספקי כוח, דיסקים, פאנל LED, ומודולים שמעבירים מידע.
הדיסקים - הם מיצרנים שונים, שכל אחד מהם ייכול היה לעשות מה שבא לו בפנים.
&nbsp
יש קבלים בכל לוח אלקטרוני, אבל הם לא תמיד למטרה הזו, הם כן יאירכו במעט את החיים אבל לא נועדו בשביל זה.
בכל אופן - כל עוד ה CP לא סיים לרדת אל הדיסק, הוא לא יימחק מה NVRAM, ולכן בהפעלה הבאה של הפיילר הוא יינסה לכתוב מחדש את ה CP. ממידע קיים הוא ייתעלם - מידע חדש הוא ייכתוב.
&nbsp
זה מתואר ב "Write interruption scenario" :
https://kb.netapp.com/support/index?page=content&id=3014024 - FAQ: Consistency Point
&nbsp
לגבי נפילה של שני דיסקים, עם RAID-DP אתה תשרוד נפילה של 2 באותו raid group בשלישי ייגרם multi disk panic. כשהמערכת תעלה אחרי הפאניק, יש נפילות מסוימות של דיסקים שאפשר להתאושש מהם, אם הדיסק רק סימן את עצמו כתקול (בד"כ כשעובר threshold של תקלות) אפשר לעשות לו unfail. אם יש corruption למידע. אפשר לעשות את שתי האופציות שדיברתי עליהן ואפשר לנסות לתקן את ה raid label.
&nbsp
אם הדיסקים נפגעו פיזית - זה לא אירוע שאני אפילו נתקלתי בתיעוד כתוב לגביו, מכיוון שהדיסקים גנריים, אני מאמין שאפשר ליישם עליהם את הטכניקות שמיישמים בשוק השחזור (להחליף לוח על הדיסק, להחליף ראש כתיבה/קריאהת מנוע וכ'ו).
&nbsp
אבל כל ארגון נורמאלי מודאג יותר מארועים של נזק פיזי וכ'ו ולכן מגבים את המידע לאתר מרוחק.

 

[yossik111]

תודה בשנית על תובנות המעניינות שהעלית כאן

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

 

[דלית - delete]

שאלה שמטרידה אותי כבר שניות ארוכות

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

 

[F00D Is G00D]

מממ

מה שכביכול מונע זה הסבירות שרכיבים אחרים יישרפו קודם

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

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

הפתרון הראשון והיחסית פשוט זה synchronized snapmirror, זה ש volumes מתרפלק באופן קבוע דרך הרשת או הפאבריק ל filer מרוחק. המידע לא מאושר לקליינט עד שהוא לא נמצא ב nvmem של שני הפאילריים. זה מצריך תקשורת מאוד מאוד אמינה.

האפשרות הנוספת היא כזו:
בגלל ששני ה nvram ב ha pairs מסונכרנים בינהם, אתה ייכול להרחיק את ה ha-pairs אחד מהשני, להזין ממקורות חשמל שונים לגמרי, ולהרחיק את החיבור בין הראשים רק באופטיקה.
עד 10 מטר אתה ייכול לעשות את זה עם interconnect רגיל (אופטי) - תלוי כמובן בדגם המכונה שלך , בוודאי תרצה כבר גם לשים מדפים בשני הצדדים, בשביל שגם הם יהנו מהזנה ממקורות שונים, וזה כבר יצריך עוד סט מדפים, ורשיון sync mirror בשביל לסנכרן את ה aggregate לשני הסטים של המדפים.

במרחקים גדולים יותר כבר יהיה צורך בפתרון metro cluster (strech up to 500m, fabric for above), שבגדול - זה אותו רעיון כמו האחרון רק למרחקים גדולים יותר ועם תהליך failover נכון יותר לסביבת dr מאשר סתם מירורינג.

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

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

, וריפליקציה פעם/פעמיים ביום מספיקה.