דפוסי שימוש בכתובות IP צפות ב-Compute Engine

Last reviewed 2025-02-03 UTC

במאמר הזה מתוארים דפוסי הטמעה של כתובות IP צפות, שבהם אפשר להשתמש כשמעבירים אפליקציות ל-Compute Engine מסביבת רשת מקומית. המסמך הזה מיועד למהנדסי רשת, לאדמינים של מערכות ולמהנדסי תפעול שמבצעים מיגרציה של אפליקציות אלGoogle Cloud.

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

מאגר GitHub שמצורף למסמך הזה כולל פריסות לדוגמה לכל תבנית, שאפשר לפרוס אוטומטית באמצעות Terraform.

כתובות IP צפות בסביבות מקומיות

כתובות IP צפות נפוצות בסביבות מקומיות. דוגמאות לתרחישי שימוש:

  • מכשירים פיזיים עם זמינות גבוהה, כמו קבוצה של חומות אש או מאזני עומסים, משתמשים לעיתים קרובות בכתובות IP צפות למעבר לגיבוי במקרה של כשל.
  • בשרתים שנדרשת בהם זמינות גבוהה נעשה בדרך כלל שימוש בכתובות IP צפות – למשל, מסדי נתונים רלציוניים שמשתמשים בשרת ראשי ובשרת גיבוי. דוגמה נפוצה היא Microsoft SQL Server, שמשתמש ב-AlwaysOn Availability Groups. כדי ללמוד איך להטמיע את התבניות האלה ב- Google Cloud, אפשר לעיין במאמר הגדרת קבוצות זמינות של SQL Server AlwaysOn עם אישור סינכרוני .
  • בסביבות Linux שמטמיעות מאזני עומסים או שרתי proxy הפוכים, נעשה שימוש בכתובות IP צפות, כמו IP Virtual Server (IPVS),‏ HAProxy ו-nginx. כדי לזהות כשלים בצמתים ולהעביר כתובות IP צפות בין מופעים, בסביבות האלה נעשה שימוש בדמונים כמו Heartbeat,‏ Pacemaker או Keepalived.
  • שירותי Windows עם זמינות גבוהה שמשתמשים ב-Windows Server Failover Clustering משתמשים בכתובות IP צפות כדי להבטיח זמינות גבוהה. כדי להטמיע שירותי Windows באמצעות אשכולות מעבר לגיבוי בענן ב- Google Cloud, אפשר לעיין במאמר בנושא הפעלת אשכולות מעבר לגיבוי בענן של Windows Server.

יש כמה דרכים להטמיע כתובות IP צפות בסביבה מקומית. בדרך כלל, שרתים שמשתפים כתובות IP צפות משתפים גם מידע על מצב באמצעות מנגנון פעימות לב. המנגנון הזה מאפשר לשרתים להעביר אחד לשני את סטטוס התקינות שלהם, וגם מאפשר לשרת המשני להשתלט על כתובת ה-IP הצפה אחרי שהשרת הראשי נכשל. הסכימה הזו מיושמת לעיתים קרובות באמצעות Virtual Router Redundancy Protocol, אבל אפשר להשתמש גם במנגנונים דומים אחרים.

אחרי שמפעילים מעבר לגיבוי במקרה של כשל בכתובת IP, השרת שמקבל את כתובת ה-IP הצפה מוסיף את הכתובת לממשק הרשת שלו. השרת מודיע על ההשתלטות הזו למכשירים אחרים באמצעות שכבה 2 על ידי שליחת מסגרת פרוטוקול ARP (פרוטוקול לפתרון כתובות) ללא תמורה. לחלופין, לפעמים פרוטוקול ניתוב כמו Open Shortest Path First (OSPF) מודיע על כתובת ה-IP לנתב בשכבה 3 במעלה הזרם.

התרשים הבא מציג הגדרה אופיינית בסביבה מקומית.

סביבה מקומית טיפוסית.

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

ההגדרה שונה מעט כשמשתמשים בפתרונות לאיזון עומסים מקומיים, כמו Windows Network Load Balancing או Linux Load Balancing עם תגובה ישירה של השרת כמו IPVS. במקרים האלה, השירות שולח גם פריימים של Gratuitous ARP, אבל עם כתובת ה-MAC של שרת אחר כמקור של ה-Gratuitous ARP. הפעולה הזו בעצם מזייפת את מסגרות ה-ARP ומשתלטת על כתובת ה-IP של שרת אחר.

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

אתגרים בהעברת כתובות IP צפות ל-Compute Engine

‫Compute Engine משתמש במערך רשת וירטואלי בתוך רשת של ענן וירטואלי פרטי (VPC), ולכן מנגנוני הטמעה רגילים לא פועלים בלי שינויים ב-Google Cloud. לדוגמה, רשת ה-VPC מטפלת בבקשות ARP ברשת מוגדרת באמצעות תוכנה, ומתעלמת מפריימים של ARP מיותרים. בנוסף, אי אפשר לשנות ישירות את טבלת הניתוב של רשת ה-VPC באמצעות פרוטוקולי ניתוב רגילים כמו OSPF או Border Gateway Protocol ‏ (BGP). המנגנונים הרגילים לכתובות IP צפות מסתמכים על בקשות ARP שמטופלות על ידי תשתית מיתוג, או על רשתות שניתנות לתכנות על ידי OSPF או BGP. לכן, כתובות IP לא עוברות אוטומטית למצב פעולה חלופית באמצעות המנגנונים האלה ב-Google Cloud. אם מעבירים תמונה של מכונה וירטואלית (VM) באמצעות כתובת IP צפה מקומית, כתובת ה-IP הצפה לא יכולה לבצע מעבר לגיבוי ללא שינוי האפליקציה.

אפשר להשתמש ברשת שכבת-על כדי ליצור הגדרה שמאפשרת תקשורת מלאה בשכבה 2 והשתלטות על כתובת IP באמצעות בקשות ARP. עם זאת, הגדרת רשת שכבת-על היא מורכבת ומקשה על ניהול משאבי הרשת של Compute Engine. הגישה הזו לא נכללת במסגרת המסמך הזה. במקום זאת, במאמר הזה מתוארים דפוסים להטמעה של תרחישי מעבר לגיבוי במקרה של כשל בסביבת רשת של Compute Engine, בלי ליצור רשתות שכבת-על.

כדי להטמיע אפליקציות עם זמינות גבוהה ואמינות ב-Compute Engine, צריך להשתמש בארכיטקטורות של הרחבה אופקית. הארכיטקטורה הזו מצמצמת את ההשפעה של כשל בצומת יחיד.

במאמר הזה מתוארים כמה דפוסים להעברת אפליקציה קיימת באמצעות כתובות IP צפות משרת מקומי ל-Compute Engine, כולל:

לא מומלץ להשתמש בכתובות IP של כינוי שמועברות בין מכונות וירטואליות כמנגנון מעבר לגיבוי (failover), כי הן לא עומדות בדרישות של זמינות גבוהה. בתרחישי כשל מסוימים, כמו אירוע כשל אזורי, יכול להיות שלא תהיה לכם אפשרות להסיר כתובת IP של כינוי ממופע. לכן, יכול להיות שלא תוכלו להוסיף אותו למופע אחר, מה שימנע מעבר לגיבוי בעת כשל.

בחירת תבנית לתרחיש השימוש

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

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

  • כתובת IP פנימית צפה או כתובת IP חיצונית צפה: ברוב האפליקציות שנדרשות להן כתובות IP צפות נעשה שימוש בכתובות IP פנימיות צפות. מעט מאוד אפליקציות משתמשות בכתובות IP חיצוניות צפות, כי בדרך כלל התנועה לאפליקציות חיצוניות צריכה להיות מאוזנת.

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

  • פרוטוקולי אפליקציה: אם המכונה הווירטואלית משתמשת רק ב-TCP וב-UDP, אפשר להשתמש בכל הדפוסים בטבלה. אם נעשה שימוש בפרוטוקולים אחרים בנוסף ל-IPv4 כדי להתחבר, רק חלק מהדפוסים מתאימים.

  • תאימות לפריסה פעילה-פעילה: אפליקציות מסוימות, שמשתמשות בכתובות IP צפות בפריסה מקומית, יכולות לפעול במצב פריסה פעיל-פעיל. היכולת הזו מאפשרת להם לא להזדקק למעבר אוטומטי (failover) מהשרת הראשי לשרת המשני. יש לכם יותר אפשרויות של תבניות להעברת סוגי האפליקציות האלה ל-Compute Engine. אפליקציות שנדרש להן רק שרת אפליקציות אחד כדי לקבל תנועה בכל זמן נתון לא תואמות לפריסה פעילה-פעילה. אפשר להטמיע את האפליקציות האלה רק עם חלק מהתבניות שמפורטות בטבלה הבאה.

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

  • תאימות לבדיקות תקינות: אם אתם לא מצליחים לבדוק אם האפליקציה שלכם רספונסיבית באמצעות בדיקות תקינות של Compute Engine, לא תוכלו להשתמש בחלק מהדפוסים שמתוארים בטבלה הבאה.

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

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

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

שם דוגמת העיצוב כתובת IP פרוטוקולים נתמכים מצב פריסה Failback נדרשת תאימות לבדיקת תקינות האפליקציה אפשר לשלב מנגנון פעימת לב
תבניות שמשתמשות באיזון עומסים
איזון עומסים פעיל-פעיל פנימי או חיצוני TCP/UDP בלבד פעיל-פעיל לא רלוונטי כן לא
איזון עומסים עם יתירות כשל ובדיקות תקינות שחשופות לאפליקציה פנימי או חיצוני TCP/UDP בלבד פעיל-סביל מיידי (למעט קישורים קיימים) כן לא
איזון עומסים עם מעבר לגיבוי (failover) ובדיקות תקינות שחושפות פעימות לב פנימי או חיצוני TCP/UDP בלבד פעיל-סביל ניתן להגדרה לא כן
דפוסים באמצעות Google Cloud מסלולים
שימוש בנתיבי ECMP פנימי כל פרוטוקולי ה-IP פעיל-פעיל לא רלוונטי כן לא
שימוש במסלולים שונים עם עדיפות שונה פנימי כל פרוטוקולי ה-IP פעיל-סביל מיידי (למעט קישורים קיימים) כן לא
שימוש במנגנון של אותות חיים כדי להחליף את הצעד הבא במסלול פנימי כל פרוטוקולי ה-IP פעיל-סביל ניתן להגדרה לא כן
תבנית שמשתמשת בתיקון אוטומטי
שימוש במכונה יחידה עם תיקון אוטומטי פנימי כל פרוטוקולי ה-IP לא רלוונטי לא רלוונטי כן לא

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

עץ החלטות שיעזור לכם לבחור מאזן עומסים.

בתרשים שלמעלה מפורטים השלבים הבאים:

  1. האם מופע יחיד של תיקון אוטומטי מספק זמינות טובה מספיק לצרכים שלכם?
    1. אם כן, אפשר לעיין בקטע שימוש במופע יחיד עם תיקון אוטומטי בהמשך המאמר. תיקון אוטומטי משתמש במנגנון בקבוצת מכונות וירטואליות כדי להחליף באופן אוטומטי מכונה וירטואלית פגומה.
    2. אם לא, עוברים לנקודת ההחלטה הבאה.
  2. האם האפליקציה שלך צריכה פרוטוקולים מעל IPv4 שאינם TCP ו-UDP?
    1. אם כן, עוברים לנקודת ההחלטה הבאה.
    2. אם לא, עוברים לנקודת ההחלטה הבאה.
  3. האם האפליקציה שלך יכולה לפעול במצב פעיל-פעיל?
    1. אם התשובה היא כן וצריך פרוטוקולים מעל IPv4 שאינם TCP ו-UDP, כדאי לעיין בקטע שימוש בנתיבים מרובים עם עלות שווה (ECMP) בהמשך המאמר הזה. מסלולי ECMP מחלקים את התנועה בין הצעדים הבאים של כל המסלולים האפשריים.
    2. אם התשובה היא כן ולא צריך פרוטוקולים מעל IPv4 מלבד TCP ו-UDP, אפשר לעיין במאמר איזון עומסים פעיל-פעיל בהמשך המסמך הזה. איזון עומסים פעיל-פעיל משתמש במכונות וירטואליות כבק-אנד למאזן עומסים פנימי מסוג TCP/UDP.
    3. אם לא – באף אחד מהמקרים – עוברים לנקודת ההחלטה הבאה.
  4. האם האפליקציה שלך יכולה לחשוף Google Cloud בדיקות תקינות?
    1. אם התשובה היא כן, ולא נדרשים פרוטוקולים מעל IPv4 מלבד TCP ו-UDP, כדאי לעיין במאמר איזון עומסים עם יתירות כשל ובדיקות תקינות שחשופות לאפליקציה בהמשך המסמך הזה. איזון עומסים עם יתירות כשל ובדיקות תקינות שחשופות לאפליקציה משתמש במכונות הווירטואליות שלכם כקצוות עורפיים למאזן עומסים פנימי מסוג TCP/UDP. הוא גם משתמש בכתובת ה-IP של איזון העומסים ב-TCP/UDP פנימיים ככתובת IP וירטואלית.
    2. אם התשובה היא כן וצריך פרוטוקולים מעל IPv4 שאינם TCP ו-UDP, אפשר לעיין בקטע שימוש בנתיבי עדיפות שונים בהמשך המסמך. שימוש במסלולים שונים עם עדיפות שונה עוזר לוודא שהתנועה תמיד תזרום למופע הראשי, אלא אם המופע הזה ייכשל.
    3. אם התשובה היא לא, ונדרשים פרוטוקולים מעל IPv4 מלבד TCP ו-UDP, אפשר לעיין במאמר איזון עומסים עם יתירות כשל ובדיקות תקינות שחושפות פעימות לב בהמשך המסמך הזה. בדפוס של איזון עומסים עם יתירות כשל ובדיקות תקינות שחושפות פעימות לב, בדיקות התקינות לא נחשפות על ידי האפליקציה עצמה, אלא על ידי מנגנון פעימות לב שפועל בין שתי המכונות הווירטואליות.
    4. אם התשובה היא לא, ולא נדרשים פרוטוקולים מעל IPv4 מלבד TCP ו-UDP, אפשר לעיין בקטע שימוש במנגנון פעימות לב כדי להחליף את הצעד הבא במסלול בהמשך המסמך הזה. שימוש במנגנון פעימות לב כדי להחליף את הצעד הבא במסלול משתמש במסלול סטטי יחיד עם הצעד הבא שמצביע על מכונת ה-VM הראשית.

דפוסים שמשתמשים באיזון עומסים

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

אם האפליקציה מתקשרת באמצעות פרוטוקולים מעל IPv4, מלבד TCP או UDP, צריך לבחור תבנית שלא משתמשת באיזון עומסים. בהמשך המאמר נפרט על הדפוסים האלה.

אם האפליקציה שלכם משתמשת ב-HTTP(S), אתם יכולים להשתמש במאזן עומסים פנימי של אפליקציות כדי להטמיע את התבנית 'פעיל-פעיל'.

אם השירות שאתם מנסים להעביר זמין חיצונית, אתם יכולים להטמיע את כל התבניות שמוסברות בסעיף הזה באמצעות מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי. בפריסות פעילות-פעילות, אפשר גם להשתמש במאזן עומסים חיצוני של אפליקציות (ALB), בשרת proxy של TCP או בשרת proxy של SSL אם האפליקציה משתמשת בפרוטוקולים ובפורטים שנתמכים באפשרויות האלה של איזון עומסים.

כדאי לשים לב להבדלים הבאים בין הטמעות מקומיות שמבוססות על כתובות IP צפות לבין כל התבניות שמבוססות על איזון עומסים:

  • זמן המעבר לגיבוי: שילוב של Keepalived עם gratuitous ARP בסביבה מקומית עשוי להעביר כתובת IP לגיבוי תוך כמה שניות. בסביבת Compute Engine, הזמן הממוצע לשחזור לאחר מעבר לגיבוי תלוי בפרמטרים שהגדרתם. במקרה של כשל במכונה וירטואלית (VM) או בשירות של מכונת VM, הזמן הממוצע למעבר אוטומטי של תעבורה תלוי בפרמטרים של בדיקת התקינות, כמו Check Interval ו-Unhealthy Threshold. אם הפרמטרים האלה מוגדרים לערכי ברירת המחדל שלהם, המעבר לגיבוי נמשך בדרך כלל 15-20 שניות. כדי לקצר את הזמן, אפשר להקטין את ערכי הפרמטרים האלה.

    ב-Compute Engine, משך הזמן של מעבר לשירות גיבוי בתוך תחומים או בין תחומים זהה.

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

    • מציינים לפחות יציאה אחת ועד חמש יציאות לפי מספר.
    • מציינים ALL כדי להעביר תנועה בכל היציאות עבור TCP או UDP.
    • כדי להעביר תעבורת נתונים של TCP ו-UDP או להשתמש ביותר מחמש יציאות עם כתובת IP אחת, אפשר להשתמש בכמה כללי העברה עם אותה כתובת IP:
      • רק TCP או UDP ו-1 עד 5 יציאות: משתמשים בכלל העברה אחד.
      • ‫TCP ו-UDP ו-1 עד 5 יציאות: צריך להשתמש בכמה כללי העברה.
      • 6 יציאות או יותר ו-TCP או UDP: צריך להשתמש בכמה כללי העברה.

  • בדיקות תקינות: בסביבה מקומית, אפשר לבדוק את מהירות התגובה של האפליקציה במחשב בדרכים הבאות:

איזון עומסים פעיל-פעיל

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

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

הדיאגרמה הבאה מציגה הטמעה של דפוס איזון העומסים הפעיל-פעיל:

איך לקוח פנימי מתנהל לפי דפוס איזון העומסים הפעיל-פעיל.

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

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

לדוגמה מלאה להטמעה של התבנית הזו, אפשר לעיין בדוגמה לפריסה באמצעות Terraform ב-GitHub.

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

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

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

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

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

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

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

לדוגמה מלאה להטמעה של התבנית הזו, אפשר לעיין בדוגמה לפריסה באמצעות Terraform ב-GitHub.

איזון עומסים עם מעבר לגיבוי (failover) ובדיקות תקינות שחושפות פעימות לב

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

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

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

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

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

לדוגמה, באמצעות Keepalived אפשר להפעיל סקריפטים באמצעות notify_master,‏ notify_backup ו-notify_fault משתני התצורה שמשנים את סטטוס בדיקת תקינות. במעבר למצב primary (ב-Keepalived המצב הזה נקרא master), אפשר להפעיל אפליקציה שמקשיבה ליציאת TCP מותאמת אישית. כשעוברים למצב גיבוי או למצב שגיאה, אפשר להפסיק את האפליקציה הזו. במקרה כזה, בדיקת התקינות יכולה להיות בדיקת תקינות של TCP שתצליח אם יציאת ה-TCP המותאמת אישית הזו פתוחה.

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

לדוגמה מלאה להטמעה של התבנית הזו באמצעות Keepalived, אפשר לעיין בדוגמה לפריסה באמצעות Terraform ב-GitHub.

דפוסים באמצעות Google Cloud מסלולים

במקרים שבהם האפליקציה שלכם משתמשת בפרוטוקולים אחרים מלבד TCP או UDP על גבי IPv4, אתם יכולים להעביר את כתובת ה-IP הצפה שלכם לתבנית שמבוססת על מסלולים.

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

באמצעות אחד מהדפוסים האלה, אתם מגדירים כמה מסלולים סטטיים לכתובת IP ספציפית עם המכונות השונות כצעדים הבאים. כתובת ה-IP הזו הופכת לכתובת ה-IP הצפה שכל הלקוחות משתמשים בה. היא צריכה להיות מחוץ לכל טווח כתובות ה-IP של תת-רשתות VPC, כי מסלולים סטטיים לא יכולים לבטל מסלולים קיימים של תת-רשתות. צריך להפעיל העברה של כתובות IP במכונות היעד. הפעלת העברת כתובות IP מאפשרת לכם לקבל תעבורה לכתובות IP שלא הוקצו למופעים – במקרה הזה, כתובת ה-IP הצפה.

אם רוצים שניתוב כתובות ה-IP הצפות יהיה זמין מרשתות VPC שכנות, צריך לייצא מסלולי ניתוב מותאמים אישית כדי שניתוב כתובות ה-IP הצפות יתבצע לכל רשתות ה-VPC השכנות.

כדי שתהיה קישוריות מרשת מקומית שמחוברת דרך Cloud Interconnect או Cloud VPN, צריך להשתמש בהודעות על נתיבים של כתובות IP בהתאמה אישית כדי לפרסם את כתובת ה-IP הצפה ברשת המקומית.

לדפוסים מבוססי-נתיב יש את היתרון הבא על פני דפוסים מבוססי-איזון עומסים:

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

לתבניות שמבוססות על ניתוב יש את החסרונות הבאים בהשוואה לתבניות שמבוססות על איזון עומסים:

  • בדיקות תקינות: אי אפשר לצרף בדיקות תקינות לGoogle Cloud מסלולים. המסלולים משמשים ללא קשר למצב של שירותי המכונות הווירטואליות הבסיסיים. כל עוד המכונה הווירטואלית פועלת, המסלולים מנתבים את התנועה למופעים, גם אם השירות לא תקין. צירוף מדיניות לתיקון אוטומטי למופעים האלה מחליף את המופעים אחרי תקופה לא תקינה שאתם מציינים. עם זאת, ברגע שהמופעים האלה מופעלים מחדש, התנועה מתחדשת באופן מיידי – עוד לפני שהשירות מתחיל לפעול. הפער הזה בשירות עלול לגרום לשגיאות בשירות אם מופעלים מופעים לא תקינים או אם הם מופעלים מחדש.
  • זמן מעבר לגיבוי (Failover): אחרי שמוחקים או מפסיקים מכונה וירטואלית, מערכת Compute Engine מתעלמת מכל נתיב סטטי שמפנה למכונה הזו. עם זאת, מכיוון שאין בדיקות תקינות במסלולים, Compute Engine עדיין משתמש במסלול הסטטי כל עוד המכונה עדיין זמינה. בנוסף, לוקח זמן לעצור את המופע, ולכן זמן המעבר לגיבוי (failover) גבוה משמעותית בהשוואה לזמן המעבר לגיבוי בדפוסים שמבוססים על איזון עומסים.
  • רק כתובות IP צפות פנימיות: אפשר להטמיע תבניות באמצעות איזון עומסים עם מאזן עומסי רשת חיצוני אזורי להעברת סיגנל ללא שינוי כדי ליצור כתובת IP צפה חיצונית, אבל תבניות מבוססות-ניתוב פועלות רק עם כתובות IP צפות פנימיות.
  • בחירת כתובת IP צפה: אפשר להגדיר מסלולים רק לכתובות IP צפות פנימיות שלא שייכות לאף תת-רשת – אי אפשר לשנות מסלולים של תת-רשתות ב- Google Cloud. כדאי לעקוב אחרי כתובות ה-IP הצפות האלה כדי שלא תקצו אותן בטעות לרשת אחרת.
  • נגישות של מסלולים: כדי שכתובות IP צפות פנימיות יהיו נגישות מרשתות מקומיות או מרשתות שבוצע בהן שיתוף פעולה, צריך להפיץ את המסלולים הסטטיים האלה כמו שמתואר למעלה.

שימוש בנתיבים מרובים עם עלות שווה (ECMP)

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

כדי להטמיע את התבנית הזו, יוצרים שני נתיבים סטטיים עם עדיפות שווה, ומגדירים את המכונות של Compute Engine כנקודות קפיצה (next-hop).

בתרשים הבא מוצגת הטמעה של תבנית המסלולים של ECMP:

איך לקוח פנימי ניגש לשירות באמצעות אחד משני נתיבי ECMP.

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

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

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

במאגר GitHub שמשויך למסמך הזה אפשר למצוא דוגמה להטמעה של התבנית הזו באמצעות Terraform.

שימוש במסלולים שונים עם עדיפות שונה

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

כדי להטמיע את התבנית הזו, פועלים לפי אותם השלבים שמופיעים בתבנית של נתיבי ECMP. כשיוצרים את המסלולים הסטטיים, צריך לתת למסלול עם הצעד הבא שמצביע על המכונה הראשית ערך עדיפות נמוך יותר (המסלול הראשי). נותנים למופע שבו ה-next-hop מצביע על המופע המשני ערך עדיפות גבוה יותר (נתיב משני).

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

בתרשים הקודם מוצג לקוח פנימי שניגש לשירות באמצעות נתיב ראשי עם ערך עדיפות של 500 שמצביע על מכונת VM 1 כקפיצה הבאה בנסיבות רגילות. מסלול שני עם ערך עדיפות של 1,000 זמין ומפנה למכונה וירטואלית 2, המכונה הווירטואלית המשנית, כנקודת הקפיצה הבאה.

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

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

במאגר GitHub שמצורף למסמך הזה אפשר למצוא דוגמה להטמעה של התבנית הזו באמצעות Terraform.

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

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

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

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

בתרשים שלמעלה מוצג לקוח פנימי שניגש לשירות באמצעות מסלול עם קפיצה הבאה שמפנה למכונת ה-VM הראשית. המכונה הווירטואלית הראשית מחליפה מידע על אותות חיים עם המכונה הווירטואלית המשנית באמצעות Keepalived. במקרה של יתירות כשל, Keepalived מפעיל פונקציית Cloud Run שמשתמשת בקריאות ל-API כדי להפנות את הצעד הבא למכונה הווירטואלית המשנית.

הצמתים משתמשים במנגנון הדופק שנבחר כדי להחליף ביניהם מידע על סטטוס השירות. כל צומת של מכונה וירטואלית בודק את הסטטוס שלו ומעביר אותו לצומת המרוחק של המכונה הווירטואלית. בהתאם לסטטוס של צומת ה-VM המקומי ולסטטוס שמתקבל מהצומת המרוחק, צומת VM אחד נבחר כצומת הראשי וצומת VM אחד נבחר כצומת הגיבוי. אחרי שצומת הופך לצומת ראשי, הוא מפנה את הצעד הבא במסלול של כתובת ה-IP הצפה לעצמו. אם אתם משתמשים ב-Keepalived, אתם יכולים להפעיל סקריפט באמצעות notify_master משתנה ההגדרה שמחליף את המסלול הסטטי באמצעות קריאה ל-API או Google Cloud CLI.

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

הפעלת התהליך הבא במעבר לגיבוי מבטיחה שזמן המעבר לגיבוי יהיה מינימלי, כי התנועה עוברת לגיבוי אחרי השלמת קריאה אחת ל-API בשלב 1:

  1. יוצרים מסלול סטטי חדש עם כתובת ה-IP הצפה כיעד, והמכונה הראשית החדשה כצעד הבא. למסלול החדש צריך להיות שם מסלול שונה ועדיפות מסלול נמוכה יותר (לדוגמה, 400) מאשר למסלול המקורי.
  2. מוחקים את הנתיב המקורי למכונה הווירטואלית הישנה הראשית.
  3. יוצרים מסלול עם אותו שם ועדיפות כמו המסלול שמחקתם. מפנים אותו אל מכונת ה-VM הראשית החדשה כקפיצה הבאה.
  4. מוחקים את המסלול הסטטי החדש שיצרתם. לא צריך את זה כדי לוודא שהתנועה תזרום למכונה הווירטואלית הראשית החדשה.

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

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

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

לדוגמה מלאה להטמעה של התבנית הזו באמצעות Keepalived, אפשר לעיין בדוגמה לפריסה באמצעות Terraform ב-GitHub.

תבנית באמצעות תיקון אוטומטי

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

שימוש במכונה יחידה עם תיקון אוטומטי

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

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

איך לקוח פנימי מתחבר ישירות למכונה של Compute Engine.

בתרשים שלמעלה אפשר לראות איך לקוח פנימי מתחבר ישירות למופע Compute Engine שמוצב בקבוצת מופעים מנוהלת בגודל 1, עם הפעלה של תיקון אוטומטי.

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

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

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

  • זמן מעבר לגיבוי: התהליך הזה איטי בהרבה מתבניות שמבוססות על איזון עומסים. אחרי שבדיקות תקינות מזהות כשל במכונה, מחיקה ויצירה מחדש של המופע שנכשל נמשכות לפחות דקה, אבל לרוב יותר זמן. הדפוס הזה לא נפוץ בסביבות ייצור. עם זאת, זמן המעבר לגיבוי עשוי להיות מספיק טוב עבור שירותים פנימיים או ניסיוניים מסוימים
  • תגובה לכשלים באזור: קבוצת מופעים מנוהלת בגודל 1 לא שורדת כשל באזור. כדי להגיב לכשלים באזור, כדאי להוסיף התראה של Cloud Monitoring כשהשירות נכשל, וליצור קבוצת מופעים באזור אחר אם מתרחש כשל באזור. במקרה הזה אי אפשר להשתמש באותה כתובת IP, לכן צריך להשתמש באזור פרטי של Cloud DNS כדי לטפל במכונה הווירטואלית ולשנות את שם ה-DNS לכתובת ה-IP החדשה.

אפשר למצוא הטמעה לדוגמה של התבנית הזו באמצעות Terraform במאגר GitHub.

המאמרים הבאים