ניפוי באגים בבעיות בחיבור

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

רשימת משימות לפתרון בעיות בחיבור

הודעות שגיאה

לגבי הודעות שגיאה ספציפיות של API, אפשר לעיין בדף העזרה בנושא הודעות שגיאה.

פתרונות נוספים לבעיות בקישוריות

אם נתקלתם בבעיות אחרות, עיינו בקטע קישוריות בדף פתרון הבעיות.

בעיות נפוצות בחיבור

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

אם מופיעות שגיאות שמכילות את הטקסט "Aborted connection nnnn to db:", בדרך כלל זה אומר שהאפליקציה לא מפסיקה את החיבורים כמו שצריך. גם בעיות ברשת יכולות לגרום לשגיאה הזו. השגיאה לא אומרת שיש בעיות במכונה של Cloud SQL. מומלץ גם להריץ את tcpdump כדי לבדוק את החבילות ולאתר את מקור הבעיה.

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

מוודאים שהאישורים בתוקף

אם המכונה מוגדרת לשימוש ב-SSL, נכנסים לדף Cloud SQL Instances במסוף Google Cloud ופותחים את המכונה. פותחים את הדף Connections, בוחרים בכרטיסייה Security ומוודאים שאישור השרת תקף. אם התוקף שלו פג, צריך להוסיף אישור חדש ולהחליף אליו.

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

אם החיבורים נכשלים, צריך לבדוק שיש לכם הרשאה להתחבר:

  • אם אתם לא מצליחים להתחבר באמצעות כתובת IP, למשל כשאתם מתחברים מהסביבה המקומית באמצעות לקוח sqlcmd, ודאו שכתובת ה-IP שממנה אתם מתחברים מורשית להתחבר למכונה של Cloud SQL.

    חיבורים למכונה של Cloud SQL באמצעות כתובת IP פרטית מאושרים באופן אוטומטי לטווחי כתובות RFC 1918. כך כל הלקוחות הפרטיים יכולים לגשת למסד הנתונים בלי לעבור דרך Cloud SQL Auth Proxy. צריך להגדיר טווחי כתובות שהם לא RFC 1918 כרשתות מורשות.

    כברירת מחדל, Cloud SQL לא לומד נתיבים של תת-רשתות שאינן RFC 1918 מה-VPC. כדי לייצא נתיבים שאינם RFC 1918, צריך לעדכן את קישור הרשתות (peering) ל-Cloud SQL. לדוגמה: 

    gcloud compute networks peerings update cloudsql-mysql-googleapis-com \
--network=NETWORK \
--export-subnet-routes-with-public-ip \
--project=PROJECT_ID

  • כתובת ה-IP הנוכחית שלכם.

איך החיבורים נוצרים

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

sp_who
go

חיבורים שמוצגת בהם כתובת IP, כמו 1.2.3.4, מתחברים באמצעות IP. חיבורים עם cloudsqlproxy~1.2.3.4 משתמשים ב-Cloud SQL Auth Proxy, או שהם מגיעים מ-App Engine. יכול להיות שחלק מהתהליכים הפנימיים של Cloud SQL ישתמשו בחיבורים מ-localhost.

מגבלות על החיבורים

אין מגבלות QPS למכונות של Cloud SQL. עם זאת, יש מגבלות ספציפיות לחיבור, לגודל ול-App Engine. מידע נוסף זמין במאמר מכסות ומגבלות.

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

הצגת החיבורים והשרשורים

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

במאמרי העזרה של SQL Server מוסבר איך לפרש את העמודות שמוחזרות מ-sp_who.

הזמן הקצוב לתפוגה של החיבורים (מ-Compute Engine)

החיבורים למכונה של Compute Engine נסגרים אחרי 10 דקות של חוסר פעילות, מה שיכול להשפיע על חיבורים ארוכי טווח שלא בשימוש בין המכונה של Compute Engine למכונה של Cloud SQL. למידע נוסף, קראו את המאמר רשתות וחומות אש במרכז העזרה של Compute Engine.

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

מציגים את הערך הנוכחי של tcp_keepalive_time.

cat /proc/sys/net/ipv4/tcp_keepalive_time

מגדירים את tcp_keepalive_time ל-60 שניות וקובעים שההגדרה תהיה קבועה בכל ההפעלות מחדש.

echo 'net.ipv4.tcp_keepalive_time = 60' | sudo tee -a /etc/sysctl.conf

מחילים את השינוי.

sudo /sbin/sysctl --load=/etc/sysctl.conf

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

cat /proc/sys/net/ipv4/tcp_keepalive_time

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

tcpdump

‫tcpdump הוא כלי ללכידת חבילות. מומלץ מאוד להריץ את tcpdump כדי לתעד ולבדוק את החבילות בין המארח לבין המכונות של Cloud SQL כשמנסים לפתור בעיות בקישוריות.

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

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

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

בדיקה באמצעות Connectivity Test

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

בדיקת החיבור

אתם יכולים להשתמש בלקוח sqlcmd כדי לבדוק את היכולת להתחבר מהסביבה המקומית. למידע נוסף, ראו חיבור לקוח sqlcmd באמצעות כתובות IP וחיבור לקוח sqlcmd באמצעות Cloud SQL Auth Proxy.

מציאת כתובת ה-IP של האפליקציה

כדי לזהות את כתובת ה-IP של המחשב שבו פועלת האפליקציה, כדי שתוכלו לאשר גישה למכונה של Cloud SQL מהכתובת הזו, אתם יכולים להשתמש באחת מהאפשרויות הבאות:

  • אם המחשב לא נמצא מאחורי שרת proxy או חומת אש, מתחברים למחשב ומשתמשים בכלי What is my IP?‎ כדי לקבוע את כתובת ה-IP שלו.
  • אם המחשב נמצא מאחורי שרת proxy או חומת אש, צריך להתחבר למחשב ולהשתמש בכלי או בשירות כמו whatismyipaddress.com כדי לזהות את כתובת ה-IP האמיתית שלו.

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

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

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

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

התחברות למכונה של Cloud SQL באמצעות telnet

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

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

Trying 35.193.198.159...

Connected to 35.193.198.159. .

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

Trying 35.193.198.159...

^C. .

Cloud Logging

ב-Cloud SQL משתמשים ב-Cloud Logging, שמאפשר לאחסן, לחפש, לנתח, לעקוב ולקבל התראות על נתוני רישום ביומן. מידע נוסף זמין במאמרי העזרה של Cloud Logging. במאמר שאילתות לדוגמה ב-Cloud SQL יש רשימה של שאילתות לניתוח יומני Cloud SQL.

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

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

המסוף

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

    כניסה ל-Cloud Logging

  2. בוחרים פרויקט קיים ב-Cloud SQL בחלק העליון של הדף.
  3. בכלי ליצירת שאילתות, מוסיפים את הפרטים הבאים:
    • ‫Resource: בוחרים באפשרות Cloud SQL Database. בתיבת הדו-שיח, בוחרים מכונה של Cloud SQL.
    • שמות של יומנים: גוללים לקטע Cloud SQL ובוחרים את קובצי היומן המתאימים למכונה. לדוגמה:
    • חומרה: בוחרים רמת יומן.
    • טווח תאריכים: בוחרים טווח מוגדר מראש או יוצרים טווח בהתאמה אישית.

gcloud

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

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

חיבורים למכונה של Cloud SQL באמצעות כתובת IP פרטית מאושרים באופן אוטומטי לטווחי כתובות RFC 1918. צריך להגדיר טווחי כתובות שהם לא RFC 1918 ב-Cloud SQL כרשתות מורשות. צריך גם לעדכן את קישור הרשתות השכנות (peering) ל-Cloud SQL כדי לייצא נתיבים שאינם RFC 1918. לדוגמה: 

gcloud compute networks peerings update cloudsql-sqlserver-googleapis-com 

--network=NETWORK 

--export-subnet-routes-with-public-ip 

--project=PROJECT_ID

אבחון של כשלים בחיבור לרשת VPC ולכתובת IP פרטית

כשמתחברים למכונה של Cloud SQL או ממנה דרך רשת VPC (למשל, באמצעות גישה לשירותים פרטיים או קישור רשת VPC), כשלים בחיבור בדרך כלל מייצרים שגיאות כלליות כמו "תם הזמן הקצוב לחיבור" או "החיבור נדחה" בלי לציין את שורש הבעיה.

כדי לאבחן למה החיבור נכשל (לדוגמה, אם תעבורת הנתונים נחסמת על ידי כלל של חומת אש, נתיב חסר או קישור לא פעיל), משתמשים בבדיקות הקישוריות של Network Intelligence Center.

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

אתם יכולים לבדוק את הקישוריות ממכונה וירטואלית של לקוח למכונה של Cloud SQL (או בכיוון ההפוך, למשל כשמתחברים מ-Cloud SQL למסד נתונים של מקור במהלך העברה):

המסוף

  1. במסוף Google Cloud , נכנסים לדף בדיקות קישוריות:

    כניסה לדף Connectivity Tests

  2. לוחצים על Create connectivity test.
  3. בקטע מקור:
    • מציינים את נקודת הקצה של המקור (לדוגמה, כתובת ה-IP ורשת ה-VPC או המכונה הווירטואלית של הלקוח ב-Compute Engine).
  4. בקטע יעד:
    • מציינים את נקודת הקצה (endpoint) של היעד:
      • כתובת IP: מזינים את כתובת ה-IP הפרטית של המכונה של Cloud SQL.
      • ‫Network: בוחרים את רשת ה-VPC.
      • יציאה: מזינים את היציאה של מסד הנתונים (3306 ל-MySQL,‏ 5432 ל-PostgreSQL או 1433 ל-SQL Server).
      • פרוטוקול: בוחרים באפשרות TCP.
  5. לוחצים על יצירה.
  6. בודקים את תוצאות הבדיקה:
    • ניתן להגעה: נתיב הרשת בין המקור ליעד פתוח. אם עדיין לא הצלחתם להתחבר, ודאו שפרטי הכניסה של המשתמש למסד הנתונים נכונים ושתהליך מסד הנתונים פועל.
    • ‫Unreachable / Dropped: מרחיבים את פרטי המעקב כדי לראות את הדילוג המדויק שבו התנועה נפסקה:
      • ‫Dropped by firewall: בודקים את הכלל של חומת האש שמוצג במעקב ומוסיפים כלל שמאפשר תעבורת נתונים נכנסת (ingress) ברשת היעד של יציאת מסד הנתונים.
      • אין מסלול: צריך לוודא שהמסלולים בהתאמה אישית מיוצאים ומיוצאים דרך החיבור של VPC Network Peering.
      • קישור לא פעיל בין רשתות שכנות (peering): ודאו שהחיבור של קישור בין רשתות VPC שכנות (peering) נמצא במצב ACTIVE בשתי הרשתות.

gcloud

  1. מפעילים את Network Management API: 
    gcloud services enable networkmanagement.googleapis.com --project=PROJECT_ID
  2. יוצרים ומריצים בדיקת קישוריות מה-VM או מכתובת ה-IP של המקור למכונה של Cloud SQL: 
    gcloud network-management connectivity-tests create TEST_NAME \
    --project=PROJECT_ID \
    --source-network=projects/PROJECT_ID/global/networks/VPC_NETWORK_NAME \
    --source-ip=SOURCE_IP \
    --destination-ip=INSTANCE_PRIVATE_IP \
    --destination-port=DB_PORT \
    --protocol=TCP \
    --round-trip

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

    • ‫TEST_NAME: שם לבדיקה, למשל cloudsql-vpc-test.
    • ‫SOURCE_IP: כתובת ה-IP הפנימית של ה-VM של הלקוח.
    • ‫INSTANCE_PRIVATE_IP: כתובת ה-IP הפרטית של המכונה ב-Cloud SQL.
    • ‫DB_PORT: היציאה של מסד הנתונים (3306 ל-MySQL,‏ 5432 ל-PostgreSQL או 1433 ל-SQL Server).
  3. כדי לראות את המעקב לאבחון ואת הסיבה לביטול: 
    gcloud network-management connectivity-tests describe TEST_NAME \
    --project=PROJECT_ID

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

אימות של קישור בין רשתות VPC שכנות (peering) וכללי חומת אש

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

  • מצב קישור בין רשתות VPC שכנות (peering): מוודאים שמצב החיבור של הקישור הוא ACTIVE: 
    gcloud compute networks peerings list \
    --network=VPC_NETWORK_NAME \
    --project=PROJECT_ID
  • מסלולים שהוחלפו: בודקים את המסלולים שהוחלפו בחיבור ה-peering: 
    gcloud compute networks peerings list-routes PEERING_NAME \
    --network=VPC_NETWORK_NAME \
    --region=REGION \
    --direction=OUTGOING \
    --project=PROJECT_ID
  • כללים של חומת אש לתעבורת נתונים נכנסת (ingress): ודאו שברשת ה-VPC יש כלל לתעבורת נתונים נכנסת שמאפשר תעבורת נתונים ביציאה של מסד הנתונים מטווח ה-IP של הלקוח: 
    gcloud compute firewall-rules list \
    --project=PROJECT_ID \
    --filter="network:VPC_NETWORK_NAME AND allowed[].ports:DB_PORT"

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

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