F00D Is G00D
New member
אנשי האנטרפריז - חלוקת הענן לאזורים. כיצד?
אנשי האנטרפריז - חלוקת הענן לאזורים. כיצד? מטעמי גדילה ומעבר לפלאש, החברה בה אני עובד עוברת ממערכת אחסון מרכזית ועמוסה לעייפה אחת בפרודקשן בכל חוות שרתים לשש או שבע מערכות בגדלים, דגמים, ווונדורים שונים בכל חוות שרתים. התוכנית נכון להיום: שים את ה vm על כל קלאסטר וירטואליזציה פנוי, שממוקם על כל סטורג' פנוי, וחבר lun על כל סטורג' שפנוי באותו הרגע. ה exception היחיד הוא שאם יש קלאסטר ווינדוס על ה vm, שים את שני ה vm על קלאסטר שונה בהיפריזור. נשמע מאוזן, קל לניהול ונחמד - נכון? לי יש בעיה עם זה: אם כונן c של האפליקציה על סטורג' אחד. כונן c של ה db על סטורג' אחר. והlun של ה db על סטורג' שלישי, כל אחד מהסטורג'ים הופך לנקודת כשל שלוקח את האפליקציה למטה. נרחיב את הבעיה לכל הארגון: נניח שעל כל סטורג' יש לפחות שרת אחד של כל אפליקציה - כל הארגון בעצם למטה אם כל אחד מהסטורג'ים או הקלאסטרים של ההיפרויזור למטה. תיאום של כל פעילות תחזוקה על כל אחד מאלה דורש מעורבות של כל הארגון (כמו היום, אבל זה כי היה רק סטורג' מרכזי אחד). אז איך מחלקים? הפתרון שלי: לבנות כמה cloud או tenant (עדיין מחפש את המילה הנכונה) שכל זוג קלאסטרים בהיפרויזור יהיה משויך אליו. והוא יוקצה לטובת מטרה ארגונית ספציפית, זאת אומרת שכל אפליקציה בהכרח תהיה קשורה רק לאותו ענן. ונאכוף את זה בכך שכל ענן יכיל רק vlans של אותן אפליקציות ו vlans לסטורג' שייחודיים לו. הבעיה עם זה היא הקצאת משאבים. אני כבר לא ייכול להקצות שטח או ביצועים פר שרת בודד - אלא פר אפליקציה. או כל הגדרה ארגונית אחרת שאני מגדיר מראש. אז מה אני מחפש; קודם כל, אם השיטה שפירטתי מעלה נהוגה, איך קוראים לה? האם יש למישהו כיוון לדוקמנטציה? האם יש דרך נכונה לנהל את המשאבים במצב כזה? אולי כלי כלשהוא חוץ מטבלאות אקסל? איך משאירים/ממקסמים גמישות כלשהיא בהקצאת המשאבים? (אחרת המהלך הזה הולך לעלות הרבה כסף) לצערי הקולגות שלי חלקם לא מבינים על מה אני מדבר, וחלקם פוטרים את עצמם בזה שסטורג' וקלאסטר של היפרביזור אמורים להיות אמינים (נכון אבל עדיין - פחחחחח)
אנשי האנטרפריז - חלוקת הענן לאזורים. כיצד? מטעמי גדילה ומעבר לפלאש, החברה בה אני עובד עוברת ממערכת אחסון מרכזית ועמוסה לעייפה אחת בפרודקשן בכל חוות שרתים לשש או שבע מערכות בגדלים, דגמים, ווונדורים שונים בכל חוות שרתים. התוכנית נכון להיום: שים את ה vm על כל קלאסטר וירטואליזציה פנוי, שממוקם על כל סטורג' פנוי, וחבר lun על כל סטורג' שפנוי באותו הרגע. ה exception היחיד הוא שאם יש קלאסטר ווינדוס על ה vm, שים את שני ה vm על קלאסטר שונה בהיפריזור. נשמע מאוזן, קל לניהול ונחמד - נכון? לי יש בעיה עם זה: אם כונן c של האפליקציה על סטורג' אחד. כונן c של ה db על סטורג' אחר. והlun של ה db על סטורג' שלישי, כל אחד מהסטורג'ים הופך לנקודת כשל שלוקח את האפליקציה למטה. נרחיב את הבעיה לכל הארגון: נניח שעל כל סטורג' יש לפחות שרת אחד של כל אפליקציה - כל הארגון בעצם למטה אם כל אחד מהסטורג'ים או הקלאסטרים של ההיפרויזור למטה. תיאום של כל פעילות תחזוקה על כל אחד מאלה דורש מעורבות של כל הארגון (כמו היום, אבל זה כי היה רק סטורג' מרכזי אחד). אז איך מחלקים? הפתרון שלי: לבנות כמה cloud או tenant (עדיין מחפש את המילה הנכונה) שכל זוג קלאסטרים בהיפרויזור יהיה משויך אליו. והוא יוקצה לטובת מטרה ארגונית ספציפית, זאת אומרת שכל אפליקציה בהכרח תהיה קשורה רק לאותו ענן. ונאכוף את זה בכך שכל ענן יכיל רק vlans של אותן אפליקציות ו vlans לסטורג' שייחודיים לו. הבעיה עם זה היא הקצאת משאבים. אני כבר לא ייכול להקצות שטח או ביצועים פר שרת בודד - אלא פר אפליקציה. או כל הגדרה ארגונית אחרת שאני מגדיר מראש. אז מה אני מחפש; קודם כל, אם השיטה שפירטתי מעלה נהוגה, איך קוראים לה? האם יש למישהו כיוון לדוקמנטציה? האם יש דרך נכונה לנהל את המשאבים במצב כזה? אולי כלי כלשהוא חוץ מטבלאות אקסל? איך משאירים/ממקסמים גמישות כלשהיא בהקצאת המשאבים? (אחרת המהלך הזה הולך לעלות הרבה כסף) לצערי הקולגות שלי חלקם לא מבינים על מה אני מדבר, וחלקם פוטרים את עצמם בזה שסטורג' וקלאסטר של היפרביזור אמורים להיות אמינים (נכון אבל עדיין - פחחחחח)