פתרון בעיות בחיבורים דרומה

בדף הזה מוסבר איך לפתור בעיות בחיבורים דרומיים (יוצאים) במופעים של Looker (ליבת Google Cloud) שמשתמשים בהגדרת IP פרטי עם Private Service Connect.

אם נתקלתם בכשל בחיבור Private Service Connect מדרום לצפון, תוכלו להשתמש בתרשים הבא של עץ ההחלטות כדי להתחיל לפתור את הבעיה.

מידע נוסף זמין במאמר גישה יוצאת לשירותים חיצוניים באמצעות Private Service Connect ב-Looker (Google Cloud core).

פתרון בעיות בחיבור

גם אם סטטוס החיבור של Private Service Connect הוא Accepted, יכול להיות שעדיין יופיעו שגיאות חיבור כש-Looker (Google Cloud core) ינסה להגיע לשירות שלכם.

בעיות בתרגום שם המארח

אם אתם מקבלים את השגיאה Unknown host (מארח לא ידוע) בממשק המשתמש של Looker (Google Cloud core) כשאתם בודקים חיבור למסד נתונים, או כש-Looker (Google Cloud core) מנסה להתחבר לשירות שלכם, יכול להיות שזה מצביע על כך שפענוח ה-DNS נכשל עבור שם המארח שהגדרתם לחיבור Private Service Connect מדרום.

במקרה כזה, אפשר לנסות את השלבים הבאים לפתרון הבעיה:

• מוודאים ששם המארח שהוגדר ב-Looker (Google Cloud core) עבור השירות נכון ושהוא זהה לשם המארח שעבורו אמורה להיות רשומת DNS.
• מוודאים שמאזן העומסים ושירות הקצה העורפי תקינים.
• בודקים את הקישוריות ממכונה וירטואלית ב-VPC של ספק השירות כדי לוודא שאפשר להגיע לשירות לקצה העורפי דרך כלל ההעברה של מאזן העומסים. אפשר ליצור מכונה וירטואלית זמנית באותו VPC ואזור כמו מאזן העומסים, ולהשתמש בכלי כמו curl או telnet כדי לבדוק את הקישוריות לכתובת ה-IP ולפורט של השירות.

אם הבעיות בפתרון שמות המארחים נמשכות, אפשר לפנות ל-Cloud Customer Care כדי לקבל עזרה.

תם הזמן הקצוב לחיבור

אם החיבורים מ-Looker (Google Cloud core) לשירות שלכם נכשלים בגלל פסק זמן, יכול להיות שהסיבה לכך היא כללי חומת אש ב-VPC של היצרן שחוסמים תנועה מרשת המשנה של Private Service Connect NAT, או בעיות אחרות ברשת.

• בודקים את כללי חומת האש כדי לוודא שתעבורת נתונים נכנסת (ingress) מותרת מתת-רשת ה-NAT של Private Service Connect לשרתים העורפיים (backend) של מאזן העומסים.
• כדי לאבחן בעיות בחיבור, אפשר להשתמש בVPC Flow Logs וברישום ביומן של מאזן העומסים (למשל רישום ביומן של מאזן עומסים של אפליקציות פנימי או רישום ביומן של מאזן עומסי רשת פנימי להעברת סיגנל ללא שינוי). יומני זרימת נתונים של ענן וירטואלי פרטי (VPC) יכולים לעזור לכם לקבוע אם תעבורת נתונים מתת-רשת ה-NAT מגיעה למאזן העומסים (LB), ויומני מאזן העומסים יכולים לספק פרטים לגבי העברה מוצלחת של תעבורת נתונים לשרתים עורפיים תקינים.

אימות ההגדרה של Private Service Connect מדרום לצפון

כדי לוודא שהחיבור בין מופע Looker (Google Cloud core) לבין הרשת שלכם נוצר בצורה תקינה, פועלים לפי השלבים הבאים:

בדיקת הסטטוס של נקודת קצה מסוג Private Service Connect במכונה של Looker (Google Cloud Core)‎

כדי לאמת את הסטטוס של החיבור של קובץ השירות מדרום לצפון מתוך ההגדרה של מופע Looker (Google Cloud core):

1. נכנסים לדף Looker במסוף Google Cloud .
2. לוחצים על שם המכונה שרוצים לבדוק את החיבור שלה.
3. בקטע Networking, מתחת לService attachment, מוצאים את נקודת הקצה שרוצים לפתור בה בעיות.
4. בודקים שהסטטוס Status הוא Accepted.

אם הסטטוס הוא Pending, יכולות להיות לכך כמה סיבות:

• העדפת החיבור של קובץ השירות המצורף לא מוגדרת ל'אישור אוטומטי של כל החיבורים', והחיבור לא אושר באופן ידני.
• הפרויקט של מופע Looker (ליבת Google Cloud) לא נמצא ברשימת ההיתרים של קובץ השירות.

כדי לפתור בעיה עם סטטוס Pending, צריך לבדוק את ההגדרה של Service Attachment ולוודא שהעדפת החיבור מוגדרת ל-Automatically accept all connections, או שהפרויקט של Looker (Google Cloud core) קיבל אישור מפורש.

אם הדומיין או ה-URI של הקובץ המצורף שגויים, מריצים שוב את הפקודה gcloud looker instances update עם הערכים הנכונים. הפקודה הזו מחליפה את כל הקבצים המצורפים הקיימים, ולכן צריך לכלול את כל הקבצים המצורפים שנבחרו. מידע נוסף זמין במאמר בנושא עריכת הגדרות של מופע Looker (Google Cloud core).

אימות ההגדרה של קובץ מצורף עם שירות ההפקה

כדאי גם לבדוק את ההגדרה של קובץ השירות בפרויקט של הספק כדי לוודא שהוא מוגדר בצורה נכונה לקבלת חיבורים מ-Looker (Google Cloud core).

במסוף Google Cloud , עוברים אל Network Services > Private Service Connect ולוחצים על הכרטיסייה Published Services. כדי לראות את הפרטים של קובץ ה-service attachment שמשמש לחיבור, לוחצים עליו.

צריך לוודא שהדרישות הבאות מתקיימות:

• הקובץ המצורף של השירות מוגדר עם כלל העברה תקף ליעד ועם רשת משנה ייעודית של Private Service Connect NAT.
• העדפת החיבור מוגדרת ל-Accept automatically. אם העדפת החיבור היא Accept for selected networks או Accept for selected projects, צריך לוודא שהחיבור מהפרויקט של Looker (Google Cloud core) אושר.
• שירות היעד מפנה לכלל ההעברה הנכון.
• רשת המשנה של ה-NAT מוגדרת בצורה נכונה ויש בה מספיק כתובות IP.
• ה-URI של קובץ השירות שסופק למופע Looker (Google Cloud core) תקין.

אפשר לעדכן את ההגדרה של קובץ מצורף לשירות באמצעות Google Cloud המסוף או באמצעות הפעלת הפקודה gcloud compute service-attachments update.

אימות הכללים של חומת האש

התנועה מ-Looker (ליבת Google Cloud) נכנסת ל-VPC דרך רשת המשנה של Private Service Connect NAT. צריכים להיות לכם כללי חומת אש שמאפשרים לתנועה הזו להגיע לשרתים העורפיים של מאזן העומסים.

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

1. מזהים את טווח כתובות ה-IP של רשת המשנה של Private Service Connect NAT שהוגדרה בקובץ המצורף של השירות.
2. במסוף Google Cloud , עוברים לדף Firewall ב-VPC של ספק השירות.
3. מוודאים שיש כלל חומת אש לתעבורת נתונים נכנסת (ingress) שמאפשר תעבורת TCP מתת-רשת NAT של Private Service Connect לשרתים העורפיים (backend) של מאזן העומסים ביציאה שבה השירות שלכם משתמש. הכלל צריך לעמוד בקריטריונים הבאים:
   • מסנן מקור: טווחי כתובות ה-IP של המקור כוללים את טווח כתובות ה-IP של רשת המשנה של Private Service Connect NAT.
   • יעדים: הכלל חל על העורפים של מאזן העומסים הפנימי (לדוגמה, באמצעות תגי רשת).
   • פרוטוקולים ויציאות: הכלל מאפשר תעבורת TCP ביציאה של שירות היעד.

אם לא קיים כלל כזה, או אם כלל בעדיפות גבוהה יותר דוחה את התנועה הזו, צריך ליצור כלל של חומת אש לתנועה נכנסת כדי לאפשר תנועה מרשת המשנה של NAT ב-Private Service Connect.

אימות ההגדרות של מאזן העומסים ושל קבוצת נקודות הקצה ברשת

השירות שלכם נחשף ל-Looker (ליבת Google Cloud) דרך מאזן עומסים פנימי ו-Network Endpoint Group‏ (NEG) שמפנה לשירות שלכם. מוודאים שהרכיבים האלה תקינים ומוגדרים בצורה נכונה.

כדי לבדוק את הגדרת ה-NEG:

1. במסוף Google Cloud , עוברים אל Network Services > Load balancing.
2. לוחצים על מאזן העומסים ואז על שירות לקצה העורפי כדי לראות את הפרטים שלו.
3. בפרטי שירות לקצה העורפי, לוחצים על השם של קבוצת נקודות הקצה ברשת.
4. בודקים את סוג קבוצת נקודות הקצה ברשת:
   • בשביל שירותים מקומיים או שירותי מולטי-ענן שאפשר להגיע אליהם דרך Cloud VPN או Cloud Interconnect, הסוג צריך להיות Hybrid connectivity NEG ‏ (NON_GCP_PRIVATE_IP_PORT).
   • בשירותי אינטרנט ציבוריים, כמו ספקי Git, הסוג צריך להיות Internet NEG ‏ (INTERNET_FQDN_PORT).
5. בקטע Network endpoints (נקודות קצה ברשת), מוודאים שכתובת ה-IP והיציאה (עבור NEGs היברידיות) או ה-FQDN והיציאה (עבור NEGs באינטרנט) תואמים בצורה נכונה לשירות היעד.

אם ה-NEG לא מוגדר בצורה נכונה, יכול להיות שתצטרכו לעדכן אותו או ליצור חדש.

אימות של פענוח DNS וניתוב

אם אתם לא מצליחים להתחבר מ-Looker (Google Cloud core), אבל שלבי פתרון הבעיות האחרים לא מראים בעיות, כדאי לבדוק את הקישוריות מתוך ה-VPC של היצרן כדי לבודד את הבעיה:

1. יוצרים מכונה וירטואלית זמנית ב-Compute Engine באותו VPC ורשת משנה של הספק שבהם נמצא מאזן העומסים הפנימי.
2. מתוך מכונת ה-VM הזו, משתמשים בכלים כמו telnet או nc כדי לבדוק את הקישוריות לכתובת ה-IP של כלל ההעברה של מאזן העומסים ביציאה של השירות – לדוגמה: telnet LOAD_BALANCER_IP TARGET_PORT.

אם החיבור מה-VM מצליח, סביר להניח שהבעיה היא בנתיב מ-Looker (הליבה של Google Cloud) אל ה-VPC. בודקים מחדש את ההגדרה של קובץ השירות ואת המופע של Looker (Google Cloud core).

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

בדיקת בעיות ספציפיות בחיבור לשירות

לשירותי יעד מסוימים יש דרישות או תלות ייחודיות כשמתחברים אליהם דרך Private Service Connect.

‫Snowflake: נקודות קצה של אחסון משני

מנהל ההתקן של Snowflake JDBC מוריד לעיתים קרובות קבוצות תוצאות או מטא-נתונים ממיקום אחסון בענן (כמו Amazon S3 או Azure Blob Storage), ולא ממארח מסד הנתונים הראשי. אם Looker (Google Cloud core) לא מצליח להגיע לנקודות הקצה המשניות האלה, יכול להיות שהחיבורים או השאילתות ייכשלו, במיוחד אם מדובר במערכי תוצאות גדולים.

כדי לפתור את הבעיה:

1. בודקים ביומנים של Looker (Google Cloud core) אם יש שגיאות של פסק זמן שמתייחסות לדומיינים של אחסון חיצוני, כמו s3.amazonaws.com או blob.core.windows.net.
2. מזהים את ה-FQDN המדויק של נקודת הקצה של האחסון שנדרשת על ידי מופע Snowflake. אפשר למצוא את המידע הזה ביומני Snowflake או לפנות לתמיכה של Snowflake.
3. צריך להגדיר כל FQDN חיצוני כחיבור נפרד מדרום לצפון. יוצרים הגדרה חדשה של Private Service Connect (קבוצה של נקודות קצה ברשת באינטרנט, מאזן עומסים וקובץ מצורף לשירות) בשביל ה-FQDN של נקודת הקצה של האחסון.
4. מוסיפים את קובץ השירות החדש להגדרות של מופע Looker (Google Cloud core).

ספקי Git ציבוריים: תעבורת נתונים יוצאת (egress) לאינטרנט

למכונות Looker (Google Cloud core) עם הגדרת IP פרטית אין נתיב ברירת מחדל לאינטרנט הציבורי. כדי להתחבר לספקי Git ציבוריים כמו GitHub או GitLab, צריך להגדיר במפורש נתיב יציאה.

כדי לפתור את הבעיה:

1. בודקים אם אתם מנסים להתחבר לספק Git ציבורי ממופע של כתובת IP פרטית. כשלים בחיבור מתבטאים לעיתים קרובות כזמן קצוב לתפוגה כללי או כשגיאות ב-SSL handshake.
2. יוצרים חיבור Private Service Connect מדרום לצפון באמצעות Internet NEG.
3. מוודאים שקבוצת ה-NEG של האינטרנט מוגדרת ליציאה הנכונה (לדוגמה, יציאה 22 ל-SSH או יציאה 443 ל-HTTPS).
4. אם יש לכם מדיניות החלפה של DNS ב-VPC שיוצרת לולאת ניתוב עם NEG באינטרנט שמבוסס על FQDN, כדאי להשתמש במקום זאת ב-NEG באינטרנט שמבוסס על IP ‏(INTERNET_IP_PORT).

מרכז הפעולות ו-Marketplace

כברירת מחדל, אי אפשר לגשת אל Google-hosted Looker (שירות הליבה של Google Cloud) Marketplace ו-Action Hub, שהם שירותים ציבוריים באינטרנט, ממכונות עם כתובות IP פרטיות.

• מרכז הפעולות: כדי להשתמש במרכז הפעולות עם מופע של כתובת IP פרטית, צריך לפרוס שרת פרטי של מרכז הפעולות שמתארח באופן עצמאי ולהתחבר אליו באמצעות חיבור Private Service Connect מדרום לצפון.
• ‫Marketplace: כדי להתחבר אל Looker Marketplace, אפשר להפעיל את האפשרות להתחבר אל Marketplace בהגדרות של חיבורים יוצאים במופע. כשמפעילים את Looker (הליבה של Google Cloud), המערכת משתמשת בSecure Web Proxy כדי להתחבר ישירות אל Marketplace ואל github.com. מידע נוסף זמין במאמר חיבור ל-Looker Marketplace. אם לא תפעילו את החיבור הזה, תצטרכו להוריד ידנית את התוספים או את הבלוקים ממאגרי ה-Git שלהם ולהתקין אותם כפרויקטים מקומיים.

בדיקת היומנים

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

מפעילים את יומני הזרימה של הענן הווירטואלי הפרטי (VPC) ברשתות המשנה שבהן נעשה שימוש במאזן העומסים, ומפעילים את הרישום ביומן בשירות הקצה העורפי של מאזן העומסים הפנימי. לאחר מכן מנסים להתחבר מ-Looker (Google Cloud core) כדי לשחזר את השגיאה.

ב-Cloud Logging, מריצים שאילתה על יומני התנועה של הענן הפרטי הווירטואלי, ומסננים את התנועה מטווח כתובות ה-IP של רשת המשנה של NAT ב-Private Service Connect לכתובת ה-IP של איזון העומסים. אם התנועה מגיעה למאזן העומסים, שולחים שאילתה ליומני מאזן העומסים כדי לקבל מידע על סטטוס החיבור לקצה העורפי.