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

‫MySQL   |  PostgreSQL   |  PostgreSQL ל-AlloyDB

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

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

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

פינג

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

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

Traceroute

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

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

אם traceroute לא מצליח להשלים את הפעולה, יכול להיות שתוכלו להבין איפה הוא הפסיק. מחפשים את כתובת ה-IP האחרונה שמופיעה ב-traceroute output ומבצעים חיפוש בדפדפן של 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. עוברים לדף AlloyDB clusters (אשכולות AlloyDB) ב- Google Cloud console.

   כניסה לדף AlloyDB clusters

2. מאתרים את האשכול שמשויך למשימת ההעברה שמבצעים בה ניפוי באגים.

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.

Cloud Logging

‫Database Migration Service ו-AlloyDB משתמשים ב-Cloud Logging. מידע מלא זמין במאמרי העזרה בנושא Cloud Logging. כדאי גם לעיין בשאילתות לדוגמה ב-Cloud SQL.

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

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

המסוף

1. כניסה לדף Logs Explorer
2. בוחרים פרויקט קיים של AlloyDB בחלק העליון של הדף.
3. ב-Query builder, מוסיפים את הפרטים הבאים:
• משאב: בוחרים באפשרות AlloyDB Database (מסד נתונים של AlloyDB). בתיבת הדו-שיח, בוחרים מופע של AlloyDB.
• שמות יומנים: גוללים לקטע AlloyDB ובוחרים את קובצי היומן המתאימים למופע. לדוגמה:
  • alloydb.googlapis.com/postgres.log
• רמת חומרה: בוחרים רמת יומן.
• טווח זמן: בוחרים הגדרה קבועה מראש או יוצרים טווח בהתאמה אישית.

gcloud

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

gcloud logging read "projects/[PROJECT_ID]/logs/alloydb.googleapis.com/postgres.log" --limit=10

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

אפשר לעיין בדף Google Cloud פתרון בעיות ב-Cloud VPN.

פתרון בעיות ב-TCP Proxy

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

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

ההודעה הבאה מוצגת כשמפעילים את מכונת ה-VM ב-Compute Engine:

You do not currently have an active account selected.

פעולות שכדאי לנסות

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

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

  gcloud auth login
  

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

  gcloud config set account ACCOUNT
  

  מחליפים את 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. במסוף, נכנסים לדף VM instances של Compute Engine.

      כניסה לדף VM instances

   2. מחפשים את מכונת ה-VM שנוצרה כחלק מתהליך ההגדרה של השרת הפרוקסי. אם הוא לא מופיע או לא פועל, צריך להגדיר את פרוקסי ה-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 היא חלק ממנה. אחרת, למכונה הווירטואלית לא תהיה גישה לממשקי Google Enterprise API, כמו 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) שונה מזו של המכונה הווירטואלית שמארחת את פרוקסי ה-TCP.

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

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

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

   2. לוחצים על יצירת בדיקת קישוריות.

   3. נותנים שם לבדיקה.

   4. בוחרים בפרוטוקול TCP.

   5. ברשימה Source endpoint (נקודת קצה של המקור), בוחרים באפשרות IP address (כתובת IP). אם אפשר לגשת למסד הנתונים של המקור באמצעות כתובת IP ציבורית, מזינים את כתובת ה-IP הציבורית של שרת ה-TCP proxy שנוצר. אחרת, מזינים את כתובת ה-IP הפרטית של שרת ה-TCP proxy.

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

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

   8. לוחצים על יצירה.

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

   1. נכנסים אל VM instances ב-Compute Engine.

      כניסה לדף VM instances

   2. בוחרים את המכונה הווירטואלית שנוצרה כחלק מתהליך ההגדרה של ה-Proxy. בקטע Logs (יומנים), לוחצים על Cloud Logging.

   3. אם מופיעה רשומת היומן Connection to source DB verified, המשמעות היא ששרת ה-proxy של TCP יכול להתחבר עכשיו למופע המקור.

4. מוודאים שבדיקת ההעברה לא נכשלת בגלל בעיות בחיבור.

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

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

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

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

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

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

2. לוחצים על יצירת בדיקת קישוריות.

3. מגדירים את הפרמטרים הבאים לבדיקה:

   1. נותנים שם לבדיקה.
   2. בוחרים בפרוטוקול TCP.
   3. ברשימה Source endpoint (נקודת קצה של המקור), בוחרים באפשרות IP address (כתובת IP) ומזינים את כתובת ה-IP של אשכול AlloyDB החדש שנוצר.
   4. בוחרים באפשרות כתובת IP מהרשימה נקודת קצה של יעד ומזינים את כתובת ה-IP הפרטית של ה-TCP Proxy.
   5. מזינים 5432 בשדה יציאת יעד.

4. לוחצים על יצירה.

5. מריצים את בדיקת הקישוריות ומטפלים בבעיות קישוריות שמתגלות.

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

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

פעולות שכדאי לנסות

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

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

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

פעולות שכדאי לנסות

בוחרים את אותו VPC עבור מכונת היעד.

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

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

אתה מנסה להגדיר את הדברים הבאים: AlloyDB DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB

למרות ש-Database Migration Service מעביר נתונים ממקור ליעד, צריך להפעיל קישוריות מהיעד למקור.

ההנחה היא:

• ל-AlloyDB destination יש גישה אל Compute Engine VM bastion.

• ל-source network bastion יש גישה ל-source DB (הגישה מתאפשרת באמצעות קישור בין רשת AlloyDB לרשת המכונה הווירטואלית ב-Compute Engine).

לאחר מכן מגדירים מנהרת 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.
   • ‫[db_client] -h[source_db_host_or_ip] -P[source_db_port] – צפוי לראות שהגישה נדחתה

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

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.
   • ‫[db_client] -h127.0.0.1 -P[tunnel_port] – צפו לראות שנדחתה הגישה

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

AlloyDB DB ---> source DB

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

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

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

1. נכנסים לדף VPC networks במסוף Google Cloud .

2. בוחרים את רשת ה-VPC שרוצים להשתמש בה.

3. בוחרים באפשרות גישה לשירותים פרטיים > הקצאת טווחי כתובות IP לשירותים.

4. מאתרים את טווח כתובות ה-IP הפנימיות שמשויך לחיבור שנוצר על ידי servicenetworking-googleapis-com.

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