התחברות לאשכול מחוץ ל-VPC שלו

בדף הזה נבחנות דרכים שונות להתחבר לאשכול AlloyDB ל-PostgreSQL מחוץ לענן הווירטואלי הפרטי (VPC) שהוגדר לו. המדריך יוצא מנקודת הנחה שכבר יצרתם אשכול AlloyDB.

מידע על חיבורים חיצוניים

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

יש מצבים שבהם האפליקציה שלכם צריכה להתחבר לאשכול מחוץ ל-VPC המחובר הזה:

  • האפליקציה שלכם פועלת במקום אחר במערכת האקולוגית של Google Cloud , מחוץ ל-VPC שאליו התחברתם לאשכול באמצעות גישה לשירותים פרטיים.

  • האפליקציה שלכם פועלת ב-VPC שנמצא מחוץ לרשת של Google.

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

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

סיכום של פתרונות לחיבור חיצוני

אנחנו ממליצים על שני פתרונות כלליים ליצירת חיבורים חיצוניים, בהתאם לצרכים שלכם:

בקטעים הבאים נסביר בפירוט על הפתרונות האלה לחיבורים חיצוניים.

התחברות דרך מכונה וירטואלית (VM) מתווכת

כדי ליצור חיבור לאשכול AlloyDB מחוץ ל-VPC שלו באמצעות כלים בקוד פתוח ומספר מינימלי של משאבים נוספים, מריצים שירות proxy במכונה וירטואלית (VM) מתווכת שהוגדרה ב-VPC הזה. אפשר להגדיר מכונה וירטואלית חדשה למטרה הזו, או להשתמש במכונה וירטואלית שכבר פועלת ב-VPC של אשכול AlloyDB.

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

התחברות דרך IAP

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

כדי להגדיר גישת IAP לאשכול, פועלים לפי השלבים הבאים:

  1. מתקינים את Google Cloud CLI בלקוח החיצוני.

  2. הכנת הפרויקט להעברת TCP של IAP

    כשמגדירים את כלל חומת האש החדש, צריך לאפשר תעבורת TCP נכנסת ליציאה 22 (SSH). אם אתם משתמשים ברשת שמוגדרת כברירת מחדל בפרויקט עם כלל default-allow-ssh שאוכלס מראש ומופעל, לא צריך להגדיר כלל נוסף.

  3. מגדירים העברת יציאות בין הלקוח החיצוני לבין המכונה הווירטואלית המתווכת באמצעות SSH דרך IAP.

    gcloud compute ssh my-vm \
       --tunnel-through-iap \
       --zone=ZONE_ID \
       --ssh-flag="-L PORT_NUMBER:ALLOYDB_IP_ADDRESS:5432"

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

    • ‫ZONE_ID: המזהה של האזור שבו נמצא האשכול, לדוגמה us-central1-a.
    • ‫ALLOYDB_IP_ADDRESS: כתובת ה-IP של מופע AlloyDB שאליו רוצים להתחבר.
    • ‫PORT_NUMBER: מספר היציאה של המכונה הווירטואלית.

  4. בודקים את החיבור באמצעות psql בלקוח החיצוני, ומחברים אותו ליציאה המקומית שצוינה בשלב הקודם. לדוגמה, כדי להתחבר בתור תפקיד המשתמש postgres ליציאה 5432:

    psql -h localhost -p 5432 -U USERNAME

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

    • ‫USERNAME: משתמש postgreSQL שאליו רוצים להתחבר למכונה – לדוגמה, משתמש ברירת המחדל postgres.

חיבור דרך שרת SOCKS proxy

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

הפתרון הזה כולל את השלבים הבאים:

  1. מתקינים, מגדירים ומריצים שרת SOCKS במכונת ה-VM המתווכת. דוגמה אחת היא Dante, פתרון פופולרי בקוד פתוח.

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

  2. מגדירים את חומת האש של ה-VPC כדי לאפשר תעבורת TCP מכתובת ה-IP או מהטווח המתאימים ליציאה שהוגדרה בשרת SOCKS.

  3. מתקינים את AlloyDB Auth Proxy בלקוח החיצוני.

  4. מריצים את AlloyDB Auth Proxy בלקוח החיצוני, כשמשתנה הסביבה ALL_PROXY מוגדר לכתובת ה-IP של מכונת ה-VM המתווכת, ומציינים את היציאה שבה שרת SOCKS משתמש.

    בדוגמה הזו, שרת ה-proxy לאימות של AlloyDB מוגדר להתחבר למסד הנתונים בכתובת my-main-instance, דרך שרת SOCKS שפועל בכתובת 198.51.100.1 ביציאה 1080:

    ALL_PROXY=socks5://198.51.100.1:1080 ./alloydb-auth-proxy \
/projects/PROJECT_ID/locations/REGION_ID/clusters/CLUSTER_ID/instances/INSTANCE_ID

    אם אתם מתחברים מ-VPC שנוצר עבור שירותי עמיתים, אתם יכולים להשתמש בכתובת ה-IP הפנימית של המכונה הווירטואלית המתווכת. אחרת, אתם צריכים להשתמש בכתובת ה-IP החיצונית שלה.

  5. בודקים את החיבור באמצעות psql בלקוח החיצוני, ומחברים אותו ליציאה שבה שרת ה-proxy של AlloyDB Auth מאזין. לדוגמה, כדי להתחבר בתור תפקיד המשתמש postgres ליציאה 5432:

    psql -h IP_ADDRESS -p PORT_NUMBER -U USERNAME

קישור באמצעות מאגר PostgreSQL

אם אתם צריכים להתקין ולהפעיל את שרת ה-proxy לאימות AlloyDB במכונת ה-VM המתווכת, במקום בלקוח חיצוני, אתם יכולים להפעיל חיבורים מאובטחים אליו על ידי שיוך שלו לשרת proxy שמודע לפרוטוקול, שנקרא גם pooler. בין ה-pooler הפופולריים בקוד פתוח ל-PostgreSQL נכללים Pgpool-II ו-PgBouncer.

בפתרון הזה, מריצים את AlloyDB Auth Proxy ואת pooler במכונה הווירטואלית המתווכת. הלקוח או האפליקציה שלכם יכולים להתחבר ישירות למאגר באמצעות SSL בצורה מאובטחת, בלי להפעיל שירותים נוספים. ‫Pooler מעביר שאילתות PostgreSQL לאשכול AlloyDB דרך Auth Proxy.

לכל מכונה באשכול AlloyDB יש כתובת IP פנימית נפרדת, ולכן כל שירות proxy יכול לתקשר רק עם מכונה ספציפית אחת: המכונה הראשית, מכונת הגיבוי או מאגר לקריאה. לכן, צריך להפעיל שירות נפרד של מאגר, עם אישור SSL מוגדר כראוי, לכל מכונה באשכול.

חיבור דרך Cloud VPN או Cloud Interconnect

לצורך עבודה בסביבת ייצור שדורשת זמינות גבוהה (HA), מומלץ להשתמש במוצר Google Cloud Network Connectivity: ‏ Cloud VPN או Cloud Interconnect, בהתאם לצרכים של השירות החיצוני ולטופולוגיית הרשת. לאחר מכן מגדירים את Cloud Router כך שיפרסם את הנתיבים המתאימים.

השימוש במוצר של Network Connectivity הוא תהליך מורכב יותר מהגדרת מכונה וירטואלית (VM) כמתווך, אבל הגישה הזו מעבירה את האחריות לזמן פעולה ולזמינות מבעל העסק אל Google. בפרט, רמת זמינות השירות (SLA) של HA VPN היא 99.99%, ולכן הוא מתאים לסביבות ייצור.

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

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

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