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

מבוא

בדרך כלל, בעיות בחיבור משתייכות לאחד משלושת התחומים הבאים:

  • מתבצע חיבור – האם יש לך אפשרות להגיע למכונה שלך דרך הרשת?
  • הרשאה – האם יש לך הרשאה להתחבר למופע?
  • אימות – האם מסד הנתונים מקבל את פרטי הכניסה שלכם למסד הנתונים?

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

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

הודעות שגיאה

הודעות שגיאה ספציפיות של 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. כך, כל הלקוחות הפרטיים יכולים לגשת למסד הנתונים בלי לעבור דרך שרת proxy ל-Cloud SQL Auth. צריך להגדיר טווחי כתובות שאינם 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 משתמשים בשרת proxy ל-Cloud SQL Auth, או שהם הגיעו מ-App Engine. יכול להיות שחלק מהתהליכים הפנימיים של Cloud SQL משתמשים בחיבורים מ-localhost.

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

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

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

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

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

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

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

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

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

הצגת הערך הנוכחי של 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 כדי לראות את הסטטוס של ממשקי הרשת.

בדיקה באמצעות בדיקת קישוריות

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

בדיקת החיבור

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

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

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

  • אם המחשב לא נמצא מאחורי שרת proxy או חומת אש, מתחברים למחשב ומשתמשים באפשרות מהי כתובת ה-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. ב-Query builder, מוסיפים את הפרטים הבאים:
    • משאב: בוחרים באפשרות מסד נתונים של Cloud SQL. בתיבת הדו-שיח, בוחרים מכונה של Cloud SQL.
    • שמות יומנים: גוללים לקטע Cloud SQL ובוחרים את קובצי היומן המתאימים למופע. לדוגמה:
    • רמת חומרה: בוחרים רמת יומן.
    • טווח זמן: בוחרים הגדרה קבועה מראש או יוצרים טווח בהתאמה אישית.

gcloud

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

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

חיבורים למכונת Cloud SQL באמצעות כתובת IP פרטית מקבלים הרשאה אוטומטית לטווח כתובות RFC 1918. צריך להגדיר טווחי כתובות שאינם RFC 1918 ב-Cloud SQL כרשתות מורשות. צריך גם לעדכן את שיוך הרשת ל-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 Peering), כשהחיבורים נכשלים מופיעות בדרך כלל שגיאות כלליות כמו 'פסק זמן לחיבור' או 'החיבור נדחה', בלי לציין את הסיבה הבסיסית.

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

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

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

המסוף

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

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

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

gcloud

  1. מפעילים את Network Management API: 
    gcloud services enable networkmanagement.googleapis.com --project=PROJECT_ID
  2. יוצרים ומריצים בדיקת קישוריות מכתובת ה-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

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

    • ‫TEST_NAME: שם לבדיקה, כמו cloudsql-vpc-test.
    • ‫SOURCE_IP: כתובת ה-IP הפנימית של מכונת הלקוח הווירטואלית.
    • ‫INSTANCE_PRIVATE_IP: כתובת ה-IP הפרטית של מופע Cloud SQL.
    • ‫DB_PORT: יציאת מסד הנתונים (3306 ל-MySQL,‏ 5432 ל-PostgreSQL או 1433 לשרת SQL).
  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.