הגדרת Config Controller לזמינות גבוהה

בדף הזה מוסבר איך הכי טוב להשתמש ב-Config Controller כשמפעילים שירותים עם זמינות גבוהה או כשמנהלים משאבים בכמה Google Cloud אזורים.

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

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

הסבר על תרחישי כשל

‫Config Controller משתמש באשכול GKE אזורי. למרות שאשכול אזורי יכול לעמוד בכשל של תחום אחד באזור, האשכול לא יהיה זמין אם יהיו כשלים בכמה תחומים באזור.

אם מופעלת יחידת בקרה של Config Controller, המשאבים הקיימים Google Cloud נשארים במצב הנוכחי שלהם. עם זאת, גם אם האפליקציות שלכם עדיין פועלות, לא תוכלו לשנות את ההגדרה שלהן אם Config Controller לא זמין. ההגבלה הזו חלה על משאבים באותו אזור וגם על משאבים באזורים אחרים שאתם מנהלים מ-Config Controller באזור הלא זמין.

מכיוון שאי אפשר להגדיר מחדש משאבים באותו אזור, אם כשל אזורי משפיע על משאבי Google Cloud קיימים באזור של Config Controller, אי אפשר לתקן את המשאבים האלה.

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

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

שימוש באשכול יחיד לזמינות אזורית

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

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

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

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

מעבר ידני לגיבוי למופע שני של Config Controller

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

למרות שלא מומלץ, אפשר להריץ שני מופעים של Config Controller עם הגדרות זהות. שני המופעים מתחרים על קריאה מאותו מאגר Git ועל החלת אותם שינויים ב- Google Cloud. עם זאת, יש הרבה מקרים קיצוניים שגורמים לכך שההגדרה הזו לא אמינה. שני המופעים של Config Controller בודקים את ה-repository ב-Git בזמנים שונים, ולכן יכול להיות שהם ינסו להחיל גרסאות שונות של ההגדרה שלכם ב- Google Cloud . כמה כותבים פעילים בו-זמנית, מה שמגדיל את הסיכוי שתיתקלו במכסות או במגבלות קצב. Google Cloud יש גם מספר קטן של משאבי Config Connector שהם לא אידמפוטנטיים, וצריך לטפל בהם בזהירות רבה יותר, כמו שמוסבר בהמשך הקטע הזה. לכן, לא מומלץ להפעיל שני אשכולות של Config Controller שמתבצע בהם תהליך גישור באופן פעיל.

במקום זאת, אנחנו ממליצים שאם האזור שבו פועל Config Controller ייכשל, תפעילו Config Controller נוסף באזור שני. צריך להגדיר את המופע החדש של Config Controller באופן זהה למופע הראשון, כך שהוא יקרא מאותו מאגר Git. במקרה כזה, יכול להיות שיהיה שימושי להכין מראש סקריפט להפעלת מופע של Config Controller ולהגדרתו. כשיוצרים את מופע Config Controller החדש,‏ סנכרון תצורות קורא את המצב הרצוי מ-Git ומחיל אותו על Kubernetes, ו-Config Connector מסנכרן את המצב הרצוי עם Google Cloud.

יש שני דברים שצריך להיזהר מהם במצב הזה:

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

  • לא ניתן להחיל מחדש את כל המשאבים של Config Connector מ-Git בצורה חלקה. רשימת המשאבים שדורשים טיפול מיוחד זמינה במאמר משאבים עם הגבלות על רכישה. בפרט, מומלץ לנקוט משנה זהירות לגבי משאבי Folder ולהימנע משימוש במשאבי IAMServiceAccountKey (לדוגמה, להשתמש ב-איחוד זהויות של עומסי עבודה ל-GKE במקום ב-GKE).

מופע אחד של Config Controller לכל אזור

אם רוצים למנוע ממכונת Config Controller באזור אחד להשפיע על אזור אחר, אפשר גם להריץ מכונת Config Controller לכל אזור, כך שכל מכונת Config Controller תנהל את המשאבים באותו אזור.

ההגדרה הזו אפשרית, אבל היא לא אחת מהאפשרויות המומלצות שלנו מהסיבות הבאות:

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

  • באופן כללי, אם יש לכם אשכול Config Controller באותו אזור, אתם עלולים להיתקל בבעיה של כשלים שקשורים זה לזה: אתם רוצים להגדיר מחדש משאבים בדיוק כשכשל אזורי משפיע על Config Controller באותו אזור.

  • צריך לפצל את המשאבים של Config Connector לפי אזור.

  • כרגע, Config Controller לא זמין בכל האזורים.

הגדרה ישירה של Google Cloud משאבים

במקרים חריגים, יכול להיות שתצטרכו לבצע שינויים ישירות ב Google Cloud משאבים הבסיסיים, בלי להשתמש ב-Git או ב-Config Connector. ‫Config Connector מנסה לתקן כל "סחף", ולכן אם מופעל עדיין מופע של Config Controller, ‏ Config Connector מחשיב כל שינוי שאתם מבצעים באופן ידני כ "סחף" ומנסה לבטל אותו.

עם זאת, אם תפסיקו את מופע Config Controller או אם האזור יהיה במצב אופליין, זה יכול להיות פתרון שימושי.

כשמופע Config Controller יחזור לפעולה, סביר להניח ש-Config Connector ינסה לבטל את השינויים הידניים שביצעתם. כדי להימנע ממצב כזה, אפשר לבצע שינויים תואמים ב-Git לכל שינוי שמבצעים באופן ידני.