הקריסה בOVH - מה ניתן להפיק מאירוע כזה?

clickone

היום נשרף אחד ממרכזי הנתונים של OVH - מה שגרם שגם חלק ממה שלא נשרף אבל היה באותו בנין לא מגיב כעת.
זו בעצם קריאת אזהרה ממש גדולה לכולנו, לא משנה היכן נמצאים השרתים שלנו כיום.
אפילו כאן בישראל, או בAWS וכו'

אני ממש נרעד לחשוב מה היה קורה אם זה היה על שרת שלי שצריך נתוני זמן אמת.

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

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

aaron

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

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

הייתי מחלק ל2.
1 - זה הדאטא של המערכת. והפתרון הוא גיבויים וredundancy (יתירות..), קלסטרים על פני אפילו יותר מDC אחד. (שזה דבר שעד היום לא עשיתי ואני מניח שעכשיו קיבלתי אזהרה למה יכול לקרות)
2 - האפליקציה עצמה. ופה הפתרון הוא פשוט 99% אוטומציה.. (אנסייבל וטרפרום?)

יכול להיות שדרך העצלנית יותר היא לדאוג לsnapshots קבועים ולהוריד אותם אל DC נפרד..

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

clickone

@aaron אמר בהקריסה בOVH - מה ניתן להפיק מאירוע כזה?:

תשתית חזקה.

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

@aaron אדרבא אולי באמת צריך להיכנס לזה קצת... אני בעד.

חברים, אל תתביישו, תתחילו להעלות נושאים. זה מלחיץ.....

aaron

@clickone אמר בהקריסה בOVH - מה ניתן להפיק מאירוע כזה?:

חברים, אל תתביישו, תתחילו להעלות נושאים. זה מלחיץ.....

תתחיל עם בעיות ספציפיות, יהיה יותר קל לזרום עם זה.

@clickone אמר בהקריסה בOVH - מה ניתן להפיק מאירוע כזה?:

אני לא חושב שOVH זו חברה שאפשר לצעוק על התשתיות שלה

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

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

chagold

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

clickone

@chagold אמר בהקריסה בOVH - מה ניתן להפיק מאירוע כזה?:

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

ואז ברגע האמת לך תעלה 10 גיגה של שרת לחווה אחרת
אבל זה בהחלט רעיון מצויין

nigun

@chagold אמר בהקריסה בOVH - מה ניתן להפיק מאירוע כזה?:

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

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

nigun

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

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

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

clickone

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

aaron

@nigun אמר בהקריסה בOVH - מה ניתן להפיק מאירוע כזה?:

איך באמת פותרים את הבעיה של הדאטא?

המושג נקרא replica sets, כנראה במקור נוצר בעיקר למטרת פיזור עומסים(?)
למשל לmongodb כאן - https://www.mongodb.com/basics/clusters
ופה יש קצת יותר פירוט - https://docs.mongodb.com/manual/replication/

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

nigun

@aaron
אם הבנתי נכון, נראה שהם כותבים כל פעם לשני nodes (או יותר)
וכל כמה זמן מפעילים sync בין כל הnodes.
זה טוב כשיודעים איפה המידע הכי מעודכן.
אבל כשלא יודעים איפה הכשל היה, איך יודעים באיזה node יש את המידע העדכני
האם יש timestamp לכל פעולה, ואז אפשר למצוא את השינוי האחרון?
מה קורה אם היה כשלים בשני nodes בזמנים שונים (בגלל עומסים למשל) ואז נעשו פעולות על בסיס המידע השגוי?

aaron

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

https://docs.mongodb.com/manual/core/replica-set-sync/#streaming-replication

nigun

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

תחומים - פורום חרדי מקצועי

הקריסה בOVH - מה ניתן להפיק מאירוע כזה?