שיטות ליצירת קשרים עסקיים

‫MySQL   |  PostgreSQL   |  PostgreSQL ל-AlloyDB

סקירה כללית

כדי ליצור מיגרציה ב-Database Migration Service, צריך ליצור קישוריות בין מופע המקור לבין מופע היעד של AlloyDB. יש מגוון שיטות נתמכות. בוחרים את האפשרות שהכי מתאימה לעומס העבודה הספציפי.

שיטת ה-Networking	תיאור	יתרונות	חסרונות
רשימת היתרים של כתובות IP	השיטה הזו פועלת על ידי הגדרת שרת מסד הנתונים של המקור כך שיקבל חיבורים מכתובת ה-IP היוצאת של מכונת Cloud SQL. אם בוחרים בשיטה הזו, Database Migration Service מנחה אתכם בתהליך ההגדרה במהלך יצירת ההעברה.	קל להגדיר. לא נדרשת הגדרה מותאמת אישית של חומת האש.	תעבורת הנתונים ברשת מתרחשת באינטרנט הציבורי. פחות מאובטח. ירידה בביצועים.
פרוקסי דרך מכונה וירטואלית באירוח ענן – מנהרת SSH הפוכה	יוצר קישוריות מהיעד למקור דרך מנהרת SSH הפוכה ומאובטחת. נדרשת מכונה וירטואלית של יעד מבוצר (bastion host) בפרויקט הפלטפורמה, וגם מכונה (לדוגמה, מחשב נייד ברשת) שיש לה קישוריות למקור. Google Cloud Database Migration Service אוסף את המידע הנדרש בזמן יצירת ההעברה, ומפיק אוטומטית את הסקריפט להגדרת הכל.	קל להגדיר. לא נדרשת הגדרה מותאמת אישית של חומת האש. מומלץ לתרחישי העברה לזמן קצר (הוכחת היתכנות או העברות של מסדי נתונים קטנים).	המכונה הווירטואלית של ה-bastion בבעלותכם ובניהולכם, ועשויות לחול עליה עלויות נוספות.
Proxy via cloud-hosted VM - TCP	יוצר קישוריות מהיעד למקור באמצעות פרוקסי TCP דרך מכונה וירטואלית שמתארחת בענן. Database Migration Service אוסף את המידע הנדרש בזמן יצירת ההעברה, ומפיק אוטומטית את הסקריפט להגדרת הכל. רלוונטי להעברות ל-AlloyDB שבהן המקור נמצא בארכיטקטורת הרשת הישנה.	קל להגדיר. לא נדרשת הגדרה מותאמת אישית של חומת האש.	המכונה הווירטואלית של ה-bastion בבעלותכם ובניהולכם, ועשויות לחול עליה עלויות נוספות.
VPC peering	השיטה הזו פועלת על ידי הגדרת רשתות ה-VPC כך שיוכלו לתקשר זו עם זו.	פתרון Google Cloud מקורי. קל להגדיר. רוחב פס גבוה. מומלץ להשתמש באפשרות הזו להעברות ארוכות או להעברות של נפח גדול של נתונים.	רלוונטי אם מסדי הנתונים של המקור והיעד מתארחים ב- Google Cloud, או אם המקור מחובר ל-VPC של היעד באמצעות VPN (מתארח בענן או מקומי) או Cloud Interconnect.
ממשקי Private Service Connect	ממשקי Private Service Connect מאפשרים למסד הנתונים של היעד ליזום חיבורים ל-IP הפרטי של מסד הנתונים של המקור בלי לנצל את מכסת הקישור בין רשתות VPC שכנות. במקום זאת, שיטת הקישוריות הזו משתמשת בחיבורי רשת שיוצרים ב-VPC.	החיבורים לכתובת ה-IP הפרטית של המקור מתבצעים באמצעות חיבור לרשת. השיטה הזו לא צורכת מכסת קישור בין רשתות שכנות (peering) ב-VPC. השיטה הכי קלה להגדרת קישוריות פרטית למקור.	שיטת הקישוריות הזו זמינה רק כש מבצעים מיגרציה למופע קיים. נדרשת הגדרה של קובץ מצורף לרשת והתאמה של כללים לחומת אש. אחרי שיוצרים את החיבור, אי אפשר לשנות את הרשת שאליה מצורף המכשיר. מידע נוסף על גישה לשירותים פרטיים ועל Private Service Connect ב-AlloyDB ל-PostgreSQL זמין במאמר סקירה כללית של כתובות IP פרטיות במסמכי AlloyDB ל-PostgreSQL.

מגבלות הקישוריות

לקישוריות מ-PostgreSQL ל-AlloyDB יש את המגבלות הבאות:

• ‫AlloyDB תומך בקישוריות פרטית באמצעות גישה לשירותים פרטיים. אין תמיכה בהקצאת כתובת IP ציבורית לאשכול.
• אחרי שיוצרים את האשכול, אי אפשר לשנות את ה-VPC שאליו האשכול מחובר באמצעות Peering.
• מכיוון ש-AlloyDB משתמש בגישה לשירותים פרטיים, שמשתמשת באופן פנימי בקישור בין רשתות VPC שכנות (peering), העברת קישור בין רשתות שכנות (transitive peering) לא נתמכת. אפשר להגיע אל כתובות IP פנימיות באותו VPC שבו האשכול שלכם ב-AlloyDB נמצא ב-peering. כדי להגיע ל-VPC אחרים, צריך להשתמש בשרת proxy מתווך. פרטים נוספים מופיעים בסעיף הבא.

תרחישים נפוצים של קישוריות ופתרונות

העברה ממכונת Cloud SQL בארכיטקטורת הרשת הישנה של ספק השירות

איור 1. חיבור פרטי שמתאפשר על ידי מכונה וירטואלית של שרת proxy ל-TCP (לחצו כדי להגדיל)

כדי לבצע מיגרציה ממופע Cloud SQL ל-PostgreSQL בארכיטקטורת הרשת הישנה של ספק השירות, צריך ליצור קישוריות באמצעות שרת proxy ביניים. הסיבה לכך היא שאי אפשר ליצור קישוריות ישירה בין מופע Cloud SQL של המקור לבין יעד AlloyDB. אפשר להגדיר פתרון פרוקסי משלכם, אבל אנחנו ממליצים להגדיר את מכונת ה-VM של פרוקסי TCP באמצעות הסקריפט שנוצר אוטומטית על ידי Database Migration Service (שירות העברת נתונים ממסדי נתונים). שיטת הקישוריות של TCP proxy

מעבר ממקור באותו פרויקט Google Cloud אבל ב-VPC אחר

מכיוון שאי אפשר לשנות את ה-VPC שבו נמצא אשכול AlloyDB אחרי שיוצרים את האשכול, יש לכם את האפשרויות הבאות:

• האפשרות המומלצת היא לשנות את ה-VPC של מכונת המקור כך שיתאים ל-VPC של מכונת היעד. לדוגמה, אם רוצים להעביר מופע Cloud SQL ל-AlloyDB, צריך לעדכן את ה-VPC של Cloud SQL כך שיתאים ל-VPC של AlloyDB.

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

• אם אי אפשר לשנות את ה-VPC של מכונת המקור כך שיתאים ל-VPC של מכונת היעד, צריך להשתמש במכונה וירטואלית (VM) כמתווך. אתם יכולים להגדיר פתרון proxy משלכם, אבל אנחנו ממליצים להשתמש ב שיטת החיבור באמצעות TCP proxy. אחרי ש-Database Migration Service יוצר את הסקריפט במסוף Google Cloud , מוסיפים עוד ממשק רשת לפקודה ליצירת מופע של TCP proxy, ומגדירים אותו כך שיתאים ל-VPC של מופע המקור. כך לשרת ה-proxy יש קישוריות גם לרשתות ה-VPC של המקור וגם לרשתות ה-VPC של היעד.

  כדי להוסיף עוד ממשק רשת, מוסיפים את --network-interface network=SOURCE_NETWORK_NAME לפקודה gcloud compute instances create-with-container שמופיעה בסקריפט.

  הערה: ברשתות VPC במצב מותאם אישית, צריך לציין במפורש את רשת המשנה. הארגומנט שצריך לצרף הוא --network-interface network=SOURCE_NETWORK_NAME,subnet=SOURCE_SUBNET_NAME.

  פקודה לדוגמה ליצירת ה-Proxy:

    gcloud compute instances create-with-container … \
    --network-interface subnet=DESTINATION-SUBNET-NAME \
    --network-interface network=SOURCE-NETWORK-NAME

  מחליפים את מה שכתוב בשדות הבאים:

  • ‫DESTINATION-SUBNET-NAME: השם של תת-הרשת של היעד.
  • ‫SOURCE-NETWORK-NAME: השם של רשת המקור.

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

העברה דרך האינטרנט הציבורי

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

העברה ממקור בפרויקט אחר Google Cloud

כדי לבצע מיגרציה ממקור בפרויקט אחר, צריך לבצע מיגרציה דרך האינטרנט, או להשתמש ב-VPC משותף לקישוריות פנימית. Google Cloud Google Cloud בוחרים באחת מהאפשרויות הבאות:

• שימוש ב-VPC משותף ללא proxy. אם רוצים שהאשכול של AlloyDB יהיה ב-VPC משותף, פשוט בוחרים את ה-VPC שבו נמצא המקור כשיוצרים את האשכול. כך למקור ולמטרה יש קישוריות ישירה.

• שימוש ב-VPC משותף עם שרת proxy. אם אתם לא רוצים שקלאסטר AlloyDB שלכם יהיה ברשת VPC משותפת, אתם צריכים להשתמש בשרת proxy מתווך. אתם יכולים להגדיר פתרון proxy משלכם, אבל אנחנו ממליצים להשתמש בשיטת הקישוריות של TCP proxy. פועלים לפי ההנחיות האלה כדי ליצור פרוקסי TCP עם ממשק רשת נוסף ב-VPC משותף.

העברה בלי לאפשר ליעד להגיע לרשת של המקור

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