מבוא
בדרך כלל, בעיות בחיבור משתייכות לאחד משלושת התחומים הבאים:
- מתבצעת התחברות – האם יש לך אפשרות לגשת למכונה שלך דרך הרשת?
- הרשאה – האם יש לכם הרשאה להתחבר למופע?
- אימות – האם מסד הנתונים מקבל את פרטי הכניסה שלכם למסד הנתונים?
כל אחד מהם יכול להתפצל לנתיבים שונים לצורך בדיקה. בקטע הבא מופיעות דוגמאות לשאלות שכדאי לשאול את עצמכם כדי לצמצם עוד יותר את הבעיה:
רשימת משימות לפתרון בעיות בחיבור
- מתבצע חיבור
- כתובת IP פרטית
- האם הפעלת את
Service Networking APIבפרויקט? - האם אתם משתמשים ב-VPC משותף?
- האם למשתמש או לחשבון השירות יש את הרשאות ה-IAM הנדרשות לניהול חיבור של גישה פרטית לשירותים?
- האם חיבור הגישה לשירותים פרטיים מוגדר בפרויקט שלכם?
- האם הקציתם טווח כתובות IP לחיבור הפרטי?
- האם טווח כתובות ה-IP שהוקצה כולל לפחות מקום ל- /24 לכל אזור שבו אתם מתכננים ליצור מופעי postgres?
- אם אתם מציינים טווח כתובות IP שהוקצה למופעי postgres, האם הטווח מכיל לפחות מקום ל- /24 לכל אזור שבו אתם מתכננים ליצור מופעי postgres בטווח הזה?
- האם נוצר חיבור פרטי?
- אם החיבור הפרטי השתנה, האם החיבורים בין רשתות ה-VPC עודכנו?
- האם יומני ה-VPC מציינים שגיאות כלשהן?
- האם כתובת ה-IP של מכשיר המקור היא כתובת שהיא לא RFC 1918?
- האם הפעלת בדיקת קישוריות כדי לעקוב אחרי נתיב המנות ולבדוק אם יש מנות שאבדו?
- כתובת IP ציבורית
- האם כתובת ה-IP של המקור מופיעה כרשת מורשית?
- האם נדרשים אישורי SSL/TLS?
- האם למשתמש או לחשבון השירות יש את הרשאות ה-IAM הנדרשות כדי להתחבר למכונה של Cloud SQL?
- אישור הרשאה
- שרת proxy ל-Cloud SQL Auth
- האם שרת ה-Proxy ל-Cloud SQL Auth מעודכן?
- האם שרת ה-Proxy ל-Cloud SQL Auth פועל?
- האם שם החיבור של המופע נוצר בצורה נכונה בפקודת החיבור של שרת proxy ל-Cloud SQL Auth?
- האם בדקת את הפלט של שרת ה-proxy ל-Cloud SQL Auth? מעבירים את הפלט לקובץ או צופים בטרמינל Cloud Shell שבו הפעלתם את שרת ה-proxy ל-Cloud SQL Auth.
- האם למשתמש או לחשבון השירות יש את הרשאות ה-IAM הנדרשות כדי להתחבר למכונה של Cloud SQL?
- האם הפעלת את
Cloud SQL Admin APIבפרויקט? - אם יש לכם מדיניות חומת אש ליציאה, ודאו שהיא מאפשרת חיבורים ליציאה 3307 במכונת היעד של Cloud SQL.
- אם אתם מתחברים באמצעות שקעי דומיין של UNIX, אתם יכולים לוודא שהשקעים נוצרו על ידי הצגת רשימת הספרייה שצוינה באמצעות -dir כשאתם מפעילים את שרת ה-proxy ל-Cloud SQL Auth.
- מחברים של Cloud SQL וקוד ספציפי לשפה
- האם מחרוזת החיבור נוצרה בצורה נכונה?
- האם השוויתם את הקוד שלכם לקוד לדוגמה בשפת התכנות שלכם?
- האם אתם משתמשים בסביבת זמן ריצה או במסגרת שאין לנו עבורה קוד לדוגמה?
- אם כן, בדקת בקהילה אם יש חומר עזר רלוונטי?
- אישורי SSL/TLS בניהול עצמי
- האם הותקן אישור לקוח במחשב המקור?
- האם אישור הלקוח מאוית בצורה נכונה בארגומנטים של החיבור?
- האם אישור הלקוח עדיין בתוקף?
- האם מופיעות שגיאות כשמתחברים באמצעות SSL?
- האם אישור השרת עדיין בתוקף?
- רשתות מורשות
- האם כתובת ה-IP של המקור נכללת?
- האם אתם משתמשים בכתובת IP שאינה RFC 1918?
- האם אתם משתמשים בכתובת IP שלא נתמכת?
- כשלים בחיבור
- יש לך הרשאה להתחבר?
- האם מופיעות שגיאות של מגבלת חיבורים?
- האם האפליקציה שלך סוגרת את החיבורים בצורה תקינה?
- אימות
- אימות מקורי של מסד נתונים (שם משתמש/סיסמה)
- האם מופיעות שגיאות
access denied? - האם שם המשתמש והסיסמה נכונים?
- אימות מסד נתונים ב-IAM
- הפעלת את התכונה הניסיונית
cloudsql.iam_authenticationבמופע שלך? - האם הוספת קישור למדיניות לחשבון?
- האם אתם משתמשים בשרת proxy ל-Cloud SQL Auth עם
-enable_iam_loginאו עם אסימון OAuth 2.0 כסיסמה למסד הנתונים? - אם משתמשים בחשבון שירות, האם משתמשים בשם האימייל המקוצר?
- מידע נוסף על אימות מסד נתונים ב-IAM ב-PostgreSQL
הודעות שגיאה
הודעות שגיאה ספציפיות של API מפורטות בדף ההפניה הודעות שגיאה.
פתרון בעיות נוספות בקישוריות
לבעיות אחרות, אפשר לעיין בקטע קישוריות בדף פתרון הבעיות.
בעיות נפוצות בחיבור
מוודאים שהאפליקציה סוגרת את החיבורים בצורה תקינה
אם מופיעות שגיאות שמכילות את המחרוזת Aborted connection nnnn to db:, בדרך כלל זה מצביע על כך שהאפליקציה לא מפסיקה את החיבורים בצורה תקינה. גם בעיות ברשת יכולות לגרום לשגיאה הזו. השגיאה לא אומרת שיש בעיות במופע Cloud SQL. מומלץ גם להריץ את הפקודה tcpdump כדי לבדוק את החבילות ולזהות את מקור הבעיה.
דוגמאות לשיטות מומלצות לניהול חיבורים מפורטות במאמר ניהול חיבורים למסדי נתונים.
מוודאים שהתוקף של האישורים לא פג
אם המופע מוגדר לשימוש ב-SSL, עוברים אל הדף Cloud SQL Instances במסוף Google Cloud ופותחים את המופע. פותחים את הדף Connections (חיבורים), בוחרים בכרטיסייה Security (אבטחה) ומוודאים שאישור השרת תקף. אם התוקף שלו פג, צריך להוסיף אישור חדש ולעבור אליו.
אימות ההרשאה להתחבר
אם החיבורים נכשלים, צריך לבדוק שיש לכם הרשאה להתחבר:
- אם אתם נתקלים בבעיות בחיבור באמצעות כתובת IP, למשל, אם אתם מתחברים מהסביבה המקומית שלכם באמצעות לקוח psql, אתם צריכים לוודא שלכתובת ה-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-postgres-googleapis-com \ --network=NETWORK \ --export-subnet-routes-with-public-ip \ --project=PROJECT_ID
כתובת ה-IP הנוכחית שלך היא:
- אפשר לנסות את הפקודה
gcloud sql connectכדי להתחבר למכונה. הפקודה הזו מאשרת את כתובת ה-IP שלכם למשך זמן קצר. אפשר להריץ את הפקודה הזו בסביבה שבה מותקנים ה-CLI של gcloud ולקוח psql. אפשר גם להריץ את הפקודה הזו ב-Cloud Shell, שזמין במסוףGoogle Cloud , וכולל את ה-CLI של gcloud ואת לקוח psql שכבר מותקנים. Cloud Shell מספק מכונת Compute Engine שבה אפשר להשתמש כדי להתחבר ל-Cloud SQL. - כדי לאפשר לכל כתובות ה-IP להתחבר למכונה באופן זמני, צריך לתת הרשאה ל-
0.0.0.0/0.
אימות אופן החיבור
אם מופיעה הודעת שגיאה כמו:FATAL: database `user` does not exist.
הפקודה gcloud sql connect --user פועלת רק עם משתמש ברירת המחדל (postgres). הפתרון הוא להתחבר באמצעות משתמש ברירת המחדל, ואז להשתמש בפקודה "\c" psql כדי להתחבר מחדש כמשתמש אחר.
קביעה של אופן יצירת החיבורים
כדי לראות מידע על החיבורים הנוכחיים, מתחברים למסד הנתונים ומריצים את הפקודה הבאה:
SELECT * from pg_stat_activity ;
חיבורים שמוצגת בהם כתובת 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. מידע נוסף זמין במאמר בנושא ניהול חיבורים למסדי נתונים.
הצגת החיבורים והשרשורים
כדי לראות את התהליכים שפועלים במסד הנתונים, משתמשים בטבלה pg_stat_activity:
select * from pg_stat_activity;
הזמן הקצוב לתפוגה של החיבורים (מ-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, פועלים לפי ההוראות האלה.
בדיקת החיבור
אתם יכולים להשתמש בלקוח psql כדי לבדוק את היכולת שלכם להתחבר מהסביבה המקומית. מידע נוסף זמין במאמרים חיבור לקוח psql באמצעות כתובות IP וחיבור לקוח psql באמצעות שרת proxy ל-Cloud SQL Auth.
קביעת כתובת ה-IP של האפליקציה
כדי לזהות את כתובת ה-IP של מחשב שבו האפליקציה פועלת, כדי שתוכלו לאשר גישה למכונה של Cloud SQL מהכתובת הזו, אתם יכולים להשתמש באחת מהאפשרויות הבאות:
- אם המחשב לא נמצא מאחורי שרת proxy או חומת אש, מתחברים למחשב ומשתמשים באפשרות מהי כתובת ה-IP שלי? האתר כדי לקבוע את כתובת ה-IP שלו.
- אם המחשב מוגן על ידי שרת Proxy או חומת אש, צריך להתחבר למחשב ולהשתמש בכלי או בשירות כמו whatismyipaddress.com כדי לזהות את כתובת ה-IP האמיתית שלו.
פתיחת יציאות מקומיות
כדי לוודא שהמארח מאזין ליציאות שאתם חושבים שהוא מאזין להן, מריצים את הפקודה ss -tunlp4. כך אפשר לדעת אילו יציאות פתוחות ומאזינות.
לדוגמה, אם יש לכם מסד נתונים של PostgreSQL שפועל, היציאה 5432 צריכה להיות פעילה ולהאזין. ב-SSH, אמורה להופיע יציאה 22.
כל הפעילות של יציאת נתונים מקומית
אפשר להשתמש בפקודה netstat כדי לראות את כל הפעילות של היציאה המקומית. לדוגמה, הפקודה netstat -lt מציגה את כל היציאות שפעילות כרגע.
התחברות למכונה של Cloud SQL באמצעות telnet
כדי לוודא שאפשר להתחבר למופע Cloud SQL באמצעות TCP, מריצים את הפקודה telnet. פרוטוקול Telnet מנסה להתחבר לכתובת ה-IP ולפורט שציינתם.
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 מייצג אימות מבוסס-מארח).
מוודאים שהקטע [replication connections] בקובץ pg_hba.conf
במסד הנתונים של המקור עודכן כך שיקבל חיבורים מטווח כתובות ה-IP של Cloud SQL VPC.
Cloud Logging
ב-Cloud SQL נעשה שימוש ב-Cloud Logging, שמאפשר לכם לאחסן נתוני יומן, לחפש אותם, לנתח אותם, לעקוב אחריהם ולקבל התראות לגביהם. מידע נוסף זמין במאמרי העזרה בנושא Cloud Logging. רשימת שאילתות לניתוח היומנים של Cloud SQL זמינה במאמר שאילתות לדוגמה ב-Cloud SQL.
צפייה ביומנים
אפשר להציג את היומנים של מכונות Cloud SQL ושל פרויקטים אחרים Google Cloud , כמו Cloud VPN או מכונות Compute Engine. כדי לראות את הרשומות ביומן של מכונת Cloud SQL:
המסוף
-
נכנסים לדף Cloud Logging במסוף Google Cloud .
- בוחרים פרויקט קיים של Cloud SQL בחלק העליון של הדף.
- ב-Query builder, מוסיפים את הפרטים הבאים:
- משאב: בוחרים באפשרות מסד נתונים של Cloud SQL. בתיבת הדו-שיח, בוחרים מכונה של Cloud SQL.
- שמות היומנים: גוללים לקטע Cloud SQL ובוחרים את קובצי היומן המתאימים למופע. לדוגמה:
- cloudsql.googleapis.com/postgres.log
- רמת חומרה: בוחרים רמת יומן.
- טווח זמן: בוחרים הגדרה קבועה מראש או יוצרים טווח בהתאמה אישית.
gcloud
משתמשים בפקודה gcloud logging כדי להציג את הרשומות ביומן. בדוגמה הבאה, מחליפים את PROJECT_ID.
הדגל limit הוא פרמטר אופציונלי שמציין את המספר המקסימלי של רשומות שיוחזרו.
gcloud logging read "projects/PROJECT_ID/logs/cloudsql.googleapis.com/postgres.log" \ --limit=10
כתובות IP פרטיות
חיבורים למכונת Cloud SQL באמצעות כתובת IP פרטית מקבלים הרשאה אוטומטית לטווח כתובות RFC 1918. צריך להגדיר ב-Cloud SQL טווחי כתובות שאינם RFC 1918 כרשתות מורשות. צריך גם לעדכן את שיוך הרשת ל-Cloud SQL כדי לייצא נתיבים שאינם RFC 1918. לדוגמה:
gcloud compute networks peerings update cloudsql-postgres-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 למסד נתונים של מקור במהלך העברה):
המסוף
- במסוף Google Cloud , נכנסים לדף בדיקות קישוריות:
- לוחצים על יצירת בדיקת קישוריות.
- בקטע מקור:
- מציינים את נקודת הקצה של המקור (לדוגמה, מכונה וירטואלית של Compute Engine או כתובת IP ורשת VPC).
- בקטע יעד:
- מציינים את נקודת הקצה של היעד:
- כתובת IP: מזינים את כתובת ה-IP הפרטית של מכונת Cloud SQL.
- רשת: בוחרים את רשת ה-VPC.
- יציאה: מזינים את היציאה של מסד הנתונים (
3306ל-MySQL,5432ל-PostgreSQL או1433ל-SQL Server). - פרוטוקול: בוחרים באפשרות
TCP.
- מציינים את נקודת הקצה של היעד:
- לוחצים על יצירה.
- מעיינים בתוצאות הבדיקה:
- ניתן להגעה: הנתיב ברשת בין המקור ליעד פתוח. אם עדיין לא הצלחתם להתחבר, בדקו את פרטי הכניסה של המשתמש במסד הנתונים וודאו שתהליך מסד הנתונים פועל.
- לא ניתן להגיע ליעד / נתונים שהושמטו: מרחיבים את פרטי האיתור כדי לראות את הניתוב המדויק שבו הושמטו נתונים:
- הבקשה נדחתה על ידי חומת האש: בודקים את כלל חומת האש שמוצג בנתוני המעקב ומוסיפים כלל שמאפשר תעבורת נתונים נכנסת (ingress) ביציאה של מסד הנתונים ברשת היעד.
- אין נתיב: צריך לוודא שנתיבים מותאמים אישית מיוצאים ומייובאים בחיבור VPC Network Peering.
- הקישור בין רשתות VPC שכנות (peering) לא פעיל: מוודאים שהחיבור בין רשתות ה-VPC נמצא במצב
ACTIVEבשתי הרשתות.
gcloud
- מפעילים את Network Management API:
gcloud services enable networkmanagement.googleapis.com --project=PROJECT_ID
- יוצרים ומריצים בדיקת קישוריות מכתובת ה-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).
-
- צפייה בנתוני האבחון ובסיבה לניתוק השיחה:
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.