ניפוי באגים בקישוריות

ניפוי באגים בקישוריות

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

הכלים הבסיסיים ביותר הם ping ו-traceroute.

פינג

‫Ping מבצע בדיקה בסיסית כדי לקבוע אם היעד ("המארח המרוחק") זמין מהמקור. ‫Ping שולח חבילת ICMP Echo Request למארח מרוחק, ומצפה לקבל בחזרה ICMP Echo Reply. אם ping לא מצליח, אין מסלול מהמקור ליעד. עם זאת, הצלחה לא אומרת שהחבילות יכולות לעבור, אלא רק שבאופן כללי אפשר להגיע למארח המרוחק.

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

Traceroute

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

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

אם traceroute לא הושלם, יכול להיות שתוכלו להבין איפה הוא נעצר. מוצאים את כתובת ה-IP האחרונה שמופיעה בפלט של traceroute, ומחפשים בדפדפן את who owns [IP_ADDRESS]. יכול להיות שהבעלים של הכתובת יופיע בתוצאות, אבל לא בטוח. בכל מקרה, שווה לנסות.

mtr

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

איתור כתובת ה-IP המקומית

אם אתם לא יודעים את הכתובת המקומית של המארח, הריצו את הפקודה ip -br address show. ב-Linux, מוצגים ממשק הרשת, הסטטוס של הממשק, כתובת ה-IP המקומית וכתובות ה-MAC. לדוגמה: eth0 UP 10.128.0.7/32 fe80::4001:aff:fe80:7/64.

אפשר גם להריץ את ipconfig או את ifconfig כדי לראות את הסטטוס של ממשקי הרשת.

איתור כתובת ה-IP היוצאת

אם אתם לא יודעים מהי כתובת ה-IP שבה מסדי הנתונים של המקור והיעד משתמשים כדי לתקשר זה עם זה (כתובת ה-IP היוצאת), בצעו את השלבים הבאים:

  1. נכנסים לדף Clusters במסוף Google Cloud :

    כניסה לדף AlloyDB for PostgreSQL Clusters

  2. מאתרים את אשכול AlloyDB ל-PostgreSQL שמשויך למשימת ההעברה שמנפים בה באגים.
  3. שתי כתובות ה-IP הציבוריות היוצאות מופיעות בפרטים של המכונה הראשית של האשכול.

פתיחת יציאות מקומיות

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

לדוגמה, אם יש לכם מסד נתונים של PostgreSQL שפועל, יציאה 5432 צריכה להיות פעילה ולהאזין. ל-SSH, אמורה להופיע היציאה 22.

כל הפעילות ביציאה המקומית

משתמשים בפקודה netstat כדי לראות את כל הפעילות ביציאה המקומית. לדוגמה, הפקודה netstat -lt מציגה את כל היציאות הפעילות כרגע.

מתחברים למארח המרוחק באמצעות telnet

כדי לוודא שאפשר להתחבר למארח המרוחק באמצעות TCP, מריצים את הפקודה telnet. ‫Telnet מנסה להתחבר לכתובת ה-IP וליציאה שציינתם.

לדוגמה, אם המארח המרוחק מריץ מסד נתונים של PostgreSQL, אתם אמורים להיות מסוגלים להתחבר אליו באמצעות telnet ביציאה 5432: telnet 35.193.198.159 5432.

אם הפעולה בוצעה בהצלחה, תראו את ההודעה הבאה: 

Trying 35.193.198.159...
Connected to 35.193.198.159.

אם הניסיון נכשל, telnet מפסיק להגיב עד שסוגרים אותו באופן ידני: 

Trying 35.193.198.159...
^C

אימות לקוח

אימות הלקוח נשלט על ידי קובץ תצורה שנקרא pg_hba.conf (HBA מייצג אימות מבוסס-מארח).

מוודאים שהקטע של חיבורי הרפליקציה בקובץ pg_hba.conf במסד הנתונים של המקור מעודכן, כדי לקבל חיבורים מטווח כתובות ה-IP של ה-VPC של AlloyDB ל-PostgreSQL.

Cloud Logging

‫Database Migration Service ו-AlloyDB ל-PostgreSQL משתמשים ב-Cloud Logging. למידע מלא, קראו את המסמכים של Cloud Logging.

צפייה ביומנים

אתם יכולים לראות את היומנים של מכונות AlloyDB ל-PostgreSQL ושל פרויקטים אחרים של Google Cloud, כמו Cloud VPN או מכונות Compute Engine. כדי לראות את רשומות היומן של מכונת AlloyDB ל-PostgreSQL:

המסוף

  1. כניסה לדף Logs Explorer
  2. בוחרים את הפרויקט של AlloyDB ל-PostgreSQL בחלק העליון של הדף.
  3. בכלי ליצירת שאילתות, מוסיפים את הפרטים הבאים:
    • ‫Resource: בוחרים באפשרות AlloyDB ל-PostgreSQL Instance. בתיבת הדו-שיח, בוחרים את המכונה של AlloyDB ל-PostgreSQL.
    • ‫Log names: גוללים לקטע AlloyDB ל-PostgreSQL ובוחרים את קובצי היומן שמתאימים למכונה. לדוגמה:
      • alloydb.googleapis.com/postgres.log
    • חומרה: בוחרים רמת יומן.
    • טווח תאריכים: בוחרים הגדרה קבועה מראש או יוצרים טווח תאריכים בהתאמה אישית.

gcloud

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

gcloud logging read "projects/PROJECT_ID/logs/alloydb.googleapis.com%2Fpostgres.log" --limit=10

כתובות IP פרטיות

חיבורים לאשכול של AlloyDB ל-PostgreSQL באמצעות כתובת IP פרטית מורשים לטווחי כתובות RFC 1918. אם הרשת שלכם משתמשת בטווחי כתובות שאינם RFC 1918, אתם צריכים לעדכן את הקישור בין רשתות שכנות (peering) כדי לייצא את כל הנתיבים שאינם RFC 1918. לדוגמה: gcloud compute networks peerings update servicenetworking-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT

טווח כתובות ה-IP‏ 172.17.0.0/16 שמור לרשת הגשר של Docker. חיבורים מכל כתובת IP בטווח הזה לאשכולות של AlloyDB ל-PostgreSQL באמצעות כתובת IP פרטית ייכשלו.

פתרון בעיות ב-VPN

Google Cloud פתרון בעיות ב-Cloud VPN

פתרון בעיות בשרת ה-proxy של TCP

גם האופן שבו מוגדר שרת ה-proxy של TCP עלול לגרום לשגיאות. כדי לפתור שגיאה בשרת proxy מסוג TCP, אפשר להיעזר בדוגמאות הבאות לבעיות ולדרכים לפתור אותן:

המכונה הווירטואלית (VM) לא הופעלה

כשמפעילים את המכונה הווירטואלית ב-Compute Engine, מופיעה ההודעה הבאה:

You do not currently have an active account selected.

דברים שכדאי לנסות

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

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

    gcloud auth login

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

    gcloud config set account <var>ACCOUNT</var>

    מחליפים את ACCOUNT בשם של החשבון שרוצים להגדיר.

החיבור למכונה של מסד הנתונים במקור נכשל

הודעת השגיאה הבאה מופיעה כשבודקים את משימת ההעברה:

Failure connecting to the source database. Make sure the connectivity information on the connection profile is correct and the source database is reachable.

דברים שכדאי לנסות

כדי להבין איפה יכולה להיות הבעיה, צריך לבצע את השלבים הבאים:

  1. בודקים אם המכונה הווירטואלית שמארחת את מאגר ה-proxy של TCP פועלת:
    1. במסוף Google Cloud , נכנסים לדף VM instances של Compute Engine.

      כניסה לדף VM instances

    2. מחפשים את המכונה הווירטואלית שנוצרה כחלק מתהליך ההגדרה של שרת ה-proxy. אם הוא לא מופיע או לא פועל, מגדירים את שרת ה-proxy ל-TCP מההתחלה ומעדכנים את הגדרות פרופיל החיבור של המקור במשימת ההעברה עם כתובת ה-IP הנכונה.
  2. אם המכונה הווירטואלית פועלת, מוודאים שלא הייתה שגיאה בהורדה של קובץ האימג' של קונטיינר ה-proxy של TCP:
    1. בוחרים את המכונה הווירטואלית שנוצרה כחלק מתהליך ההגדרה של שרת ה-Proxy ל-TCP. בקטע Logs, לוחצים על יציאה טורית 1 (console).
    2. אם הרשומה Launching user container 'gcr.io/dms-images/tcp-proxy' לא מופיעה ביומנים, יכול להיות שהמכונה לא הצליחה לשלוף את קובץ האימג' מ-Container Registry. כדי לבדוק אם זה המצב, מתחברים ל-VM ומנסים לשלוף ידנית את קובץ האימג' מ-Container Registry באמצעות הפקודה הבאה: 
      docker pull gcr.io/dms-images/tcp-proxy

      אם מופיעה השגיאה Error response from daemon: Get "https://gcr.io/v2/": net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers), סימן שהמכונה הווירטואלית לא הצליחה להתחבר ל-Container Registry. אם למכונה הווירטואלית יש רק כתובת IP פרטית, צריך להפעיל גישה פרטית ל-Google ברשת המשנה שכתובת ה-IP היא חלק ממנה. אחרת, למכונה הווירטואלית לא תהיה גישה לממשקי API של Google Enterprise, כמו Container Registry.

  3. מוודאים שהקונטיינר יכול להתחבר למכונה המקורית:
    1. בוחרים את המכונה הווירטואלית שנוצרה כחלק מתהליך ההגדרה של שרת ה-Proxy. בקטע Logs, לוחצים על Cloud Logging.
    2. אם מופיעה ההודעה הבאה: Connection refused, please verify that the machine you are using to run the script can connect to the source database at, סימן שהקונטיינר של שרת ה-proxy של TCP לא הצליח להתחבר למכונה של מסד הנתונים במקור. יכולות להיות לכך כמה סיבות:
      • כתובת ה-IP של מכונת המקור שגויה.
      • יש מדיניות חומת אש שדוחה חיבורים משרת ה-Proxy של TCP למכונה המקורית.
      • המכונה המקורית נמצאת ברשת VPC שונה מהמכונה הווירטואלית שמארחת את שרת ה-Proxy של TCP.

    כדי לפתור את בעיית הקישוריות, אתם יכולים להשתמש בבדיקות הקישוריות של Google Cloudולוודא שיש קישוריות בין המכונה הווירטואלית שמארחת את שרת ה-proxy של TCP לבין מסד הנתונים של המקור:

    1. נכנסים לדף Connectivity Tests במסוף Google Cloud .

      בדיקות קישוריות

    2. לוחצים על Create Connectivity Tests.
    3. נותנים שם לבדיקה.
    4. בוחרים באפשרות TCP בתור הפרוטוקול.
    5. ברשימה Source endpoint, בוחרים באפשרות כתובת IP. אם אפשר לגשת למסד הנתונים של המקור באמצעות כתובת IP ציבורית, מזינים את כתובת ה-IP הציבורית של שרת ה-proxy החדש ל-TCP. אחרת, מזינים את כתובת ה-IP הפרטית של שרת ה-proxy ל-TCP.
    6. ברשימה Destination endpoint, בוחרים באפשרות IP address ומזינים את כתובת ה-IP של מסד הנתונים של המקור.
    7. בשדה Destination port, מזינים את מספר היציאה שמשמשת לחיבור למסד הנתונים של המקור.
    8. לוחצים על יצירה.

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

    1. עוברים אל VM instances ב-Compute Engine.

      כניסה לדף VM instances

    2. בוחרים את המכונה הווירטואלית שנוצרה כחלק מתהליך ההגדרה של שרת ה-Proxy. בקטע Logs, לוחצים על Cloud Logging.
    3. אם מופיעה רשומת היומן Connection to source DB verified, סימן ששרת ה-Proxy של TCP יכול עכשיו להתחבר למכונה המקורית.
  4. מוודאים שבדיקת ההעברה לא נכשלת בגלל בעיות בחיבור.

החיבור לאשכול של מסד הנתונים ביעד נכשל

אם מארז ה-TCP proxy יכול להתחבר למכונה המקורית, אבל בדיקת ההעברה עדיין נכשלת בגלל בעיות בחיבור, יכול להיות שהבעיה היא בקישוריות בין אשכול היעד של AlloyDB ל-PostgreSQL לבין המכונה הווירטואלית שמארחת את מארז ה-TCP proxy.

ניפוי באגים בבעיה

כדי לנפות באגים בבעיה, אתם יכולים להשתמש בבדיקות קישוריות כדי לוודא שיש קישוריות בין אשכול היעד של AlloyDB ל-PostgreSQL לבין המכונה הווירטואלית שמארחת את שרת ה-proxy של TCP: Google Cloud

  1. נכנסים לדף Connectivity Tests במסוף Google Cloud .

    בדיקות קישוריות

  2. לוחצים על Create Connectivity Tests.
  3. מגדירים את הפרמטרים הבאים לבדיקה:
    1. נותנים שם לבדיקה.
    2. בוחרים באפשרות TCP בתור הפרוטוקול.
    3. ברשימה Source endpoint, בוחרים באפשרות IP address ומזינים את כתובת ה-IP של אשכול AlloyDB ל-PostgreSQL החדש שיצרתם.
    4. ברשימה Destination endpoint בוחרים באפשרות IP address ומזינים את כתובת ה-IP הפרטית של שרת ה-proxy ל-TCP.
    5. מזינים 5432 בשדה יציאת היעד.
  4. לוחצים על יצירה.
  5. מריצים את בדיקת הקישוריות ומטפלים בבעיות שמתגלות.

סיבות אפשריות

יש כלל חומת אש שמונע תקשורת בין אשכול היעד לבין ה-VM של שרת ה-proxy ל-TCP.

דברים שכדאי לנסות

מוסיפים כלל של חומת האש שמאפשר לאשכול היעד לתקשר עם שרת ה-proxy של TCP באמצעות יציאה 5432.

סיבות אפשריות

יש חוסר התאמה ב-VPC בין אשכול היעד לבין המכונה הווירטואלית שמריצה את מאגר ה-TCP proxy.

דברים שכדאי לנסות

בוחרים את אותו VPC לאשכול היעד.

פתרון בעיות במנהרת SSH הפוכה

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

כדי להגדיר את זה, צריך לבצע את הפעולות הבאות:

AlloyDB for PostgreSQL cluster ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

ההנחה היא:

  • ל-AlloyDB for PostgreSQL cluster יש גישה ל-Compute Engine VM bastion (באמצעות התאמת רשתות בין הרשת של AlloyDB ל-PostgreSQL לבין הרשת של המכונה הווירטואלית ב-Compute Engine).

  • לsource network bastion יש גישה אל source DB.

לאחר מכן מגדירים מנהרת SSH מהמכונה source network bastion למכונה Compute Engine VM bastion, שמנתבת את כל החיבורים הנכנסים ליציאה כלשהי במכונה Compute Engine VM bastion דרך המנהרה למכונה source DB.

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

source network bastion ---> source DB

  1. מתחברים אל source network bastion באמצעות SSH, או מהטרמינל אם מדובר במכונה המקומית.
  2. בודקים את הקישוריות למסד הנתונים של המקור באחת מהשיטות הבאות:
    • ‫telnet [source_db_host_or_ip] [source_db_port] – אמורות להופיע מחרוזות החיבור של telnet, שמסתיימות ב-Connected to x.x.x.x.
    • ‫psql -h [source_db_host_or_ip] -p [source_db_port] -U [username] -d [database_name] – אמורה להופיע בקשה להזנת סיסמה או הודעה על דחיית הגישה.

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

Compute Engine VM bastion ---> source DB

  1. מבצעים SSH אל Compute Engine VM bastion (באמצעות gcloud compute ssh VM_INSTANCE_NAME).
  2. בודקים את הקישוריות למסד הנתונים של המקור באחת מהשיטות הבאות:
    • ‫telnet 127.0.0.1 [tunnel_port] – אמורות להופיע מחרוזות החיבור של telnet, שמסתיימות ב-Connected to x.x.x.x.
    • psql -h 127.0.0.1 -p [tunnel_port] -U [username] -d [database_name] – צפויה להופיע בקשה להזנת סיסמה או הודעה על דחיית הגישה.

אם הבדיקה נכשלת, צריך לוודא שהמנהרה פועלת כמו שצריך. הרצת sudo netstat -tupln מציגה את כל התהליכים שממתינים ב-VM הזה, וצריך לראות את sshd listening on the tunnel_port.

AlloyDB for PostgreSQL cluster ---> source DB

הדרך הכי טובה לבדוק את זה היא testing the migration job מ-Database Migration Service. אם הפעולה נכשלת, סימן שיש בעיה בקישור בין רשתות VPC שכנות (peering) או בניתוב בין הרשת של AlloyDB ל-PostgreSQL לבין הרשת של Compute Engine VM bastion.

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

כדי למצוא את טווח כתובות ה-IP הפנימיות במסוף:

  1. נכנסים לדף VPC networks במסוף Google Cloud .
  2. בוחרים את רשת ה-VPC שבה רוצים להשתמש.
  3. בוחרים באפשרות Private services access > Allocated IP ranges for services.
  4. מוצאים את טווח כתובות ה-IP הפנימיות שמשויך לחיבור שנוצר על ידי servicenetworking-googleapis-com.

אפשר גם לראות את התנועה בין אשכול AlloyDB ל-PostgreSQL לבין המכונה הווירטואלית של Compute Engine במסוף Cloud Logging בפרויקט Cloud VPN gateway. ביומנים של המכונה הווירטואלית ב-Compute Engine, מחפשים תנועה שמגיעה מאשכול AlloyDB ל-PostgreSQL. ביומנים של אשכול AlloyDB ל-PostgreSQL, מחפשים תנועה מה-VM של Compute Engine.