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

[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]

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