הגדרתם קישוריות בין מסדי הנתונים של המקור והיעד, אבל איך אתם יודעים שהם מחוברים? אם התקשורת ביניהם נכשלת, איך אפשר לגלות מה השתבש ואיפה?
הכלים הבסיסיים ביותר הם 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 היוצאת), בצעו את השלבים הבאים:
נכנסים לדף SQL Instances ב- Google Cloud console.
לוחצים על שם המכונה שמשויכת למשימת ההעברה שמנפים בה באגים.
גוללים למטה עד שמופיע החלונית Connect to this instance (התחברות למופע הזה). כתובת ה-IP היוצאת מופיעה בחלונית הזו.
פתיחת יציאות מקומיות
כדי לוודא שהמארח מאזין ליציאות שאתם חושבים שהוא מאזין להן, מריצים את הפקודה ss -tunlp4. כך תוכלו לדעת אילו יציאות פתוחות ומאזינות. לדוגמה, אם יש לכם מסד נתונים של MySQL שפועל, היציאה 3306 צריכה להיות פעילה ולהאזין. ב-SSH, אמורה להופיע יציאה 22.
כל פעילות הניוד המקומי
אפשר להשתמש בפקודה netstat כדי לראות את כל הפעילות של היציאה המקומית. לדוגמה, הפקודה netstat -lt מציגה את כל היציאות הפעילות כרגע.
מתחברים למארח המרוחק באמצעות telnet
כדי לוודא שאתם יכולים להתחבר למארח המרוחק באמצעות TCP, מריצים את הפקודה telnet. פרוטוקול Telnet מנסה להתחבר לכתובת ה-IP ולפורט שציינתם.
אם המארח המרוחק מריץ מסד נתונים של MySQL, למשל, אז אמורה להיות לכם אפשרות להתחבר אליו באמצעות Telnet ביציאה 3306:
telnet 35.193.198.159 3306.
אם הפעולה תצליח, תראו את ההודעה הבאה:
Trying 35.193.198.159...
Connected to 35.193.198.159.
.
אם הפעולה נכשלת, telnet מפסיק להגיב עד שסוגרים את הניסיון באופן ידני:
Trying 35.193.198.159...
^C.
.
Cloud Logging
Database Migration Service ו-Cloud SQL משתמשים ב-Cloud Logging. מידע מלא זמין במאמרי העזרה בנושא Cloud Logging. כדאי גם לעיין בשאילתות לדוגמה ב-Cloud SQL.
צפייה ביומנים
אתם יכולים לראות את היומנים של מכונות Cloud SQL ושל פרויקטים אחרים ב- Google Cloud, כמו מכונות של Cloud VPN או של Compute Engine. כדי לראות את רשומות היומן של המכונה ב-Cloud SQL:
המסוף
- כניסה לדף Logs Explorer
- בוחרים פרויקט קיים ב-Cloud SQL בחלק העליון של הדף.
- בכלי ליצירת שאילתות, מוסיפים את הפרטים הבאים:
- Resource: בוחרים באפשרות Cloud SQL Database. בתיבת הדו-שיח, בוחרים מכונה של Cloud SQL.
- שמות יומנים: גוללים לקטע Cloud SQL ובוחרים את קובצי היומן המתאימים למופע. לדוגמה:
- cloudsql.googlapis.com/mysql-general.log
- cloudsql.googleapis.com/mysql.err
- חומרה: בוחרים רמת יומן.
- טווח תאריכים: בוחרים הגדרה קבועה מראש או יוצרים טווח בהתאמה אישית.
gcloud
משתמשים בפקודה gcloud logging כדי להציג רשומות ביומן. בדוגמה הבאה, מחליפים את PROJECT_ID.
הדגל limit הוא פרמטר אופציונלי שמציין את המספר המקסימלי של רשומות שיוחזרו.
gcloud logging read "projects/[PROJECT_ID]/logs/cloudsql.googleapis.com/mysql-general.log" --limit=10
כתובות IP פרטיות
חיבורים למכונת Cloud SQL באמצעות כתובת IP פרטית מקבלים הרשאה אוטומטית לטווח כתובות RFC 1918. צריך להגדיר טווחי כתובות שאינם RFC 1918 ב-Cloud SQL כרשתות מורשות. צריך גם לעדכן את הקישור בין רשתות שכנות (peering) ל-Cloud SQL כדי לייצא נתיבים שאינם RFC 1918. לדוגמה:
gcloud compute networks peerings update cloudsql-mysql-googleapis-com --network=NETWORK --export-subnet-routes-with-public-ip --project=PROJECT
טווח כתובות ה-IP 172.17.0.0/16 שמור לרשת הגשר של Docker. לא תהיה אפשרות להגיע למכונות Cloud SQL שנוצרו עם כתובת IP בטווח הזה. חיבורים מכל כתובת IP בטווח הזה למכונות Cloud SQL באמצעות כתובת IP פרטית ייכשלו.
פתרון בעיות ב-VPN
Google Cloud דף פתרון הבעיות של Cloud VPN
פתרון בעיות במנהרת SSH הפוכה
תיעול SSH הוא שיטה להעברת תקשורת מסוימת על גבי חיבור SSH. מנהור SSH הפוך מאפשר להגדיר מנהרת SSH, אבל הרשת של היעד היא זו שיוזמת את חיבור המנהרה. האפשרות הזו שימושית כשלא רוצים לפתוח יציאה ברשת שלכם מטעמי אבטחה.
כדי להשיג את המטרה, צריך להגדיר את הדברים הבאים: Cloud SQL DB ---> Compute Engine VM bastion ---> tunnel ---> source network bastion ---> source DB
ההנחה היא:
לCompute Engine VM bastion יש גישה אל Cloud SQL DB.
ל-source network bastion יש גישה ל-source DB (באמצעות התאמת רשתות בין הרשת של Cloud SQL לרשת של המכונה הווירטואלית ב-Compute Engine).
לאחר מכן מגדירים מנהרת SSH מה-source network bastion אל ה-Compute Engine VM bastion, שמנתבת את כל החיבורים הנכנסים ליציאה כלשהי ב-Compute Engine VM bastion דרך המנהרה אל ה-source DB.
כל קישור בתרחיש שלמעלה יכול להיות מוגדר באופן שגוי ולמנוע את הפעולה של כל התהליך. פותרים את הבעיות בכל קישור, אחד אחרי השני:
source network bastion ---> source DB
- מתחברים אל source network bastion באמצעות SSH, או מהטרמינל אם מדובר במכונה המקומית.
- בודקים את הקישוריות למסד הנתונים של המקור באחת מהשיטות הבאות:
-
telnet [source_db_host_or_ip] [source_db_port]– אמורה להופיע בקשה להזנת סיסמה ל-MySQL (משהו כמו5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection) -
[db_client] -h[source_db_host_or_ip] -P[source_db_port]– אמורה להופיע הודעת דחייה (משהו כמוERROR 1045 (28000): Access denied for user...)
-
אם הבדיקה נכשלת, צריך לוודא שהפעלתם את הגישה מהמחשב המתווך הזה למסד הנתונים של המקור.
Compute Engine VM bastion ---> source DB
- חיבור SSH ל-Compute Engine VM bastion (באמצעות
gcloud compute ssh VM_INSTANCE_NAME) - בודקים את הקישוריות למסד הנתונים של המקור באמצעות אחת מהשיטות הבאות:
-
telnet 127.0.0.1 [tunnel_port]– אמורה להופיע ההנחיה להזנת סיסמת MySQL (משהו כמו5.7.12-logPuN0%`D5G??f9nVS'Pmysql_native_passwordConnection) -
[db_client] -h127.0.0.1 -P[tunnel_port]– צפוי לראות דחייה של הגישה (משהו כמוERROR 1045 (28000): Access denied for user...)
-
אם הבדיקה נכשלת, צריך לוודא שהמנהרה פועלת כמו שצריך.
הפעלת sudo netstat -tupln מציגה את כל התהליכים שממתינים במכונה הווירטואלית הזו, ואתם אמורים לראות את sshd listening on the tunnel_port.
Cloud SQL DB ---> source DB
הדרך הכי טובה לבדוק את זה היא באמצעות testing the migration job מ-Database Migration Service.
אם הפעולה נכשלת, סימן שיש בעיה בקישור בין רשתות VPC שכנות (peering) או בניתוב בין הרשת של Cloud SQL לבין הרשת של Compute Engine VM bastion.
חומת האש של שרת מסד הנתונים של המקור צריכה להיות מוגדרת כך שתאפשר את כל טווח כתובות ה-IP הפנימיות שהוקצה לחיבור לשירות הפרטי של רשת ה-VPC, שבה מכונת היעד של Cloud SQL תשתמש בתור השדה privateNetwork של הגדרות ה-ipConfiguration שלה.
כדי למצוא את טווח כתובות ה-IP הפנימיות במסוף:
נכנסים לדף VPC networks במסוף Google Cloud .
בוחרים את רשת ה-VPC שבה רוצים להשתמש.
בוחרים באפשרות Private services access > Allocated IP ranges for services.
מאתרים את טווח כתובות ה-IP הפנימיות שמשויך לחיבור שנוצר על ידי servicenetworking-googleapis-com.
אפשר גם לראות את התעבורה בין מופע Cloud SQL לבין מופע VM של Compute Engine במסוף Cloud Logging בפרויקט Cloud VPN gateway. ביומנים של המכונה הווירטואלית ב-Compute Engine, חפשו תנועה שמגיעה מהמכונה של Cloud SQL. ביומנים של המכונה ב-Cloud SQL, מחפשים תנועה מהמכונה הווירטואלית ב-Compute Engine.