הגדרת קישוריות באמצעות מנהרת SSH הפוכה

אתם יכולים ליצור קישוריות מאשכול היעד של AlloyDB ל-PostgreSQL למסד הנתונים של המקור באמצעות מנהרת SSH הפוכה ומאובטחת. בשיטה הזו צריך מכונה וירטואלית של יעד מבוצר (bastion host) בפרויקט Google Cloud , וגם מכונה (לדוגמה, שרת או תחנת עבודה ברשת המקור) שיש לה קישוריות למסד הנתונים של המקור.

חשוב: אם המקור נמצא ב-VPN (לדוגמה, ב-AWS או ב-VPN מקומי), בפרופיל החיבור של המקור צריך להשתמש בכתובת ה-IP וביציאה של ה-VPN, במקום בכתובת ה-IP וביציאה הציבוריות של המקור.

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

איור 1. דוגמה לרשת להעברה: קישוריות למקור דרך מנהרת SSH. (אפשר ללחוץ כדי להגדיל)

הגדרת מנהרת SSH הפוכה

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

1. בתפריט הנפתח Connectivity method, בוחרים באפשרות Proxy via cloud-hosted VM - Reverse-SSH tunnel.

2. בוחרים את המכונה הווירטואלית שמשמשת ליצירת קישוריות בין מסד הנתונים של המקור לבין אשכול היעד של AlloyDB ל-PostgreSQL. בדרך כלל מדובר במכונה וירטואלית שפועלת ב-VPC שבו פועלת האפליקציה שניגשת למסד הנתונים של AlloyDB ל-PostgreSQL. המכונה הווירטואלית משמשת כשרת המבוצר של מנהרת ה-SSH.

3. אתם יכולים להשתמש במכונה וירטואלית קיימת של Compute Engine למטרה הזו:

   1. בוחרים את המכונה הווירטואלית של Compute Engine מהרשימה.
   2. מציינים יציאה פנויה שאפשר להשתמש בה למנהרת ה-SSH.
   הערה: כדי שמנהרת ה-SSH ההפוכה תפעל, צריך להגדיר את הפרמטר GatewayPorts לערך yes בקובץ /etc/ssh/sshd_config בשרת המבוצר. אחרי שמעדכנים את הקובץ, מפעילים מחדש את שירות sshd באמצעות הפקודה sudo systemctl restart sshd.service. אם אתם לא רוצים לשנות את ההגדרות של המכונה הווירטואלית הקיימת, אתם יכולים ליצור מכונה וירטואלית חדשה.

4. לחלופין, אפשר ליצור מכונה וירטואלית חדשה בשלב הזה. בוחרים באפשרות CREATE A COMPUTE ENGINE VM INSTANCE, והסקריפט שנוצר כולל הוראות ליצירת המכונה.

   1. נותנים שם למכונה הווירטואלית.
   2. בוחרים סוג מכונה למכונה הווירטואלית.
   3. מציינים רשת משנה למכונה הווירטואלית.
   הערה: מכונה וירטואלית של Compute Engine שנוצרה על ידי הסקריפט לא מנוהלת על ידי Database Migration Service. אם נוצר מכונה, הארגון שלכם מחויב על המכונה לפי התמחור הרגיל, ואתם אחראים לניהול שלה, כולל מחיקת המכונה כשכבר לא צריך אותה.

5. לוחצים על הצגת התסריט כדי לראות את התסריט שנוצר.

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

   • משנים את הפקודה gcloud compute instances create על ידי הוספת הדגל --no-address.
   • משנים את הפקודה gcloud compute ssh על ידי הוספת הדגל --internal-ip.

   בנוסף, אם רוצים ליצור VM של יעד מבוצר ברשת משנה שנמצאת ב-VPC משותף, צריך לשנות את הפקודה export SUBNET_NAME מהסקריפט שנוצר כך שתצביע על projects/project_name/regions/region_name/subnetworks/subnetwork_name.

   לדוגמה:

   export SUBNET_NAME=projects/myproject/regions/myregion/subnetworks/mysubnetwork

   ‫project_name הוא שם הפרויקט שבו נמצא ה-VPC המשותף. ‫region_name ו-subnetwork_name הם השמות של האזור ושל רשת המשנה שמשויכים לפרויקט ה-VPC.

   הערה: חשוב לוודא שהקטע של חיבורי הרפליקציה בקובץ pg_hba.conf (ב-PostgreSQL באירוח עצמי) או קבוצות האבטחה בענן (ב-AWS RDS או ב-Aurora) במסד הנתונים של המקור מעודכנים כך שיקבלו חיבורים נכנסים ביציאה 5432 מכתובת ה-IP של המכונה הווירטואלית של היעד המבוצר ומטווח רשת ה-VPC של AlloyDB ל-PostgreSQL ביעד.

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

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

7. לוחצים על הגדרה והמשך.

8. מאמתים את משימת המיגרציה כדי לוודא שהיא מתחברת בצורה נכונה ומעבירה נתונים ממכונה של מסד נתונים במקור לאשכול AlloyDB ל-PostgreSQL ביעד.

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

10. אחרי שמגדירים את משימת ההעברה, מאמתים את הקישוריות ומגדירים את רשתות ה-VPN (אם צריך), אפשר להריץ את משימת ההעברה הרציפה.

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

• למידע נוסף על קישוריות רשת של מסדי נתונים ב-Database Migration Service, קראו את הסקירה הכללית על שיטות עבודה ברשת.

• במאמר תחילת העבודה עם העברות ל-AlloyDB ל-PostgreSQL מופיע מדריך מפורט להעברה.