העברה בשירות עצמי מ-Looker (מקורי) אל Looker (Google Cloud Core)‎

במסמך הזה מפורטים השלבים הטכניים להעברת המכונה הקיימת של Looker מהסביבה של Looker (המקורית) אל Looker (Google Cloud Core).

‫Looker (Google Cloud core) היא סביבת פריסה שמשולבת באופן עמוק בפלטפורמת Google Cloud . ‫Looker (Google Cloud core)‎ מתארח בתשתית של Google Cloud , ואפשר לנהל אותו ישירות דרך מסוף Google Cloud . הוא משולב באופן עמוק עם הרבה מהמוצרים, השירותים והיכולות האחרים של Google Cloud.

ב-Looker (Google Cloud core) אי אפשר להעביר ממכונה של Looker (original) למכונה של Looker (Google Cloud core) עם תאימות ל-FIPS, כי מכונות של Looker (original) לא תומכות בתאימות ל-FIPS.

לפני שמתחילים

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

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

    • יצירת מכונה של Looker (Google Cloud core): אדמין ב-Looker‏ (roles/looker.admin).
    • הקצאת תפקידי IAM בפרויקט ב- Google Cloud : אדמין IAM בפרויקט (roles/resourcemanager.projectIamAdmin).
    • יצירת קטגוריה של Cloud Storage: אדמין לניהול נפח האחסון (roles/storage.admin).

    להסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

  4. כדי לנהל את המכונה של Looker (original)‎ כהכנה להעברה, צריך להיות לכם תפקיד אדמין ב-Looker במכונה הזו.

  5. יוצרים מכונה חדשה ו "ריקה" של Looker (Google Cloud core).

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

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

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

סקירה כללית

באופן כללי, תהליך ההעברה כולל את השלבים הבאים.

  1. מוודאים שהמכונה של Looker (original)‎ מוכנה להעברה.
  2. מייצאים את הנתונים מהמכונה של Looker (original).
  3. מייבאים את הנתונים למכונה "הריקה" החדשה של Looker (Google Cloud core).
  4. מסיימים את ההגדרה של המכונה של Looker (Google Cloud core).
  5. הוצאה משימוש של המכונה של Looker (Original).

בקטעים הבאים מוסבר בהרחבה על כל אחד מהשלבים האלה.

מוודאים שהמכונה של Looker (original) מוכנה להעברה

כדי שאפשר יהיה להעביר את המכונה של Looker (original), היא צריכה לעמוד בדרישות הבאות:

  • מופע Looker (original)‎ צריך להיות מנוהל על ידי Google (כלומר, לא באירוח בצד הלקוח) ומתארח ב- Google Cloud או ב-Amazon Web Services.

  • גרסת המכונה של Looker (original)‎ צריכה להיות בטווח של גרסה חודשית אחת מהגרסה הנוכחית של Looker (Google Cloud core)‎. כדי למצוא את הגרסה הנוכחית של Looker (Google Cloud core), עיינו בנתוני הגרסה של Looker וחפשו את ההודעה האחרונה על פריסה.

בנוסף, לפני ההעברה צריך לבצע את הפעולות הבאות:

  • יש כמה הבדלים בתכונות בין Looker (מקורי) לבין Looker (Google Cloud core). כדאי לעיין בהבדלים האלה כדי לוודא שהתכונות ב-Looker (Google Cloud core)‎ עונות על הצרכים שלכם.

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

  • ‫Looker (Google Cloud core) תומך רק בשיטות האימות Google OAuth,‏ SAML ו-OpenID Connect.

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

ייצוא הנתונים מהמכונה של Looker (original)‎

כדי לייצא את הנתונים מהמופעים של Looker (original), צריך לבצע שני שלבים:

  1. יצירת מקום לאחסון נתוני ההעברה.
  2. התחלת הייצוא.

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

יצירת מקום לאחסון נתוני ההעברה

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

  1. יוצרים קטגוריה חדשה ב-Cloud Storage (לדוגמה, <bucket-name>).
    • הקטגוריה הזו תשמש לאחסון נתוני ההעברה.
    • פועלים לפי ההוראות בדף התיעוד יצירת קטגוריות.
    • חשוב לזכור שהערך של <bucket-name> חייב להיות ייחודי בכל Google Cloud. מומלץ להוסיף בתחילת השם של הקטגוריה מזהה ייחודי, כמו מזהה הפרויקט.
  2. בוחרים שם לתיקייה בתוך הקטגוריה של Cloud Storage (לדוגמה, <folder-name>). לא יוצרים את התיקייה עכשיו. מציינים את שם התיקייה במהלך בקשת הייצוא. הוא ייווצר באופן אוטומטי במהלך תהליך הייצוא.
  3. יוצרים אוסף מפתחות ומפתח ב-Cloud KMS (לדוגמה, <kms_keyring_id> ו-<kms-key-id>).
  4. יוצרים חשבון שירות חדש במיוחד להעברה (לדוגמה, <export-service-account>).

  5. מקצים ל-<export-service-account> שני תפקידי IAM ספציפיים:

  6. יוצרים מפתח לחשבון שירות שמשויך ל-<export-service-account>, ומורידים את קובץ המפתח בפורמט JSON.

בקשת הייצוא

אחרי שמוודאים שהמכונה מוכנה להעברה, יוצרים מכונה "ריקה" של Looker (Google Cloud core) ויוצרים מקום לאחסון נתוני ההעברה, מזינים את הפרטים הבאים בדף Export בחלונית Admin של המכונה של Looker (original):

  • שם הקטגוריה של Cloud Storage שיצרתם.
  • שם התיקייה ב-Cloud Storage – תיקייה עם השם הזה תיווצר באופן אוטומטי במהלך הייצוא. בסיום הייצוא, קובצי הייצוא יופיעו בתיקיית משנה עם חותמת זמן בתוך התיקייה הזו בקטגוריה של Cloud Storage שיצרתם.
  • שם מפתח ה-KMS.
  • טקסט ה-JSON שמכיל את המפתח של חשבון השירות.

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

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

מייבאים את הנתונים למכונה החדשה וה "ריקה" של Looker (Google Cloud core)

אחרי שמייצאים את נתוני המכונה, אפשר לייבא אותם למכונה של Looker (Google Cloud core).

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

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

סיום ההגדרה של המכונה של Looker (Google Cloud core)

בשלב הזה, אדמינים ב-Looker יכולים לעבור אל כתובת ה-URL של המכונה ולהתחבר למכונה כדי לסיים את ההגדרה.

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

הנה כמה פריטים שדורשים תשומת לב מיוחדת:

הגדרות כלליות (בחלונית הניהול של Looker)

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

משתמשים

‫Looker (Google Cloud core) תומך רק בשיטות האימות Google OAuth,‏ SAML ו-OpenID Connect.

אם המכונה של Looker (original) הוגדרה גם ל-Google OAuth, רשומות המשתמשים והמאפיינים שלהם יועתקו (כל עוד הם משויכים לאותו מזהה Google וכתובת אימייל בשתי המכונות). אדמין IAM בפרויקט צריך להקצות לכל משתמש את תפקיד האדמין ב-Looker או את תפקיד המשתמש במכונה של Looker ב-IAM בפרויקט ב- Google Cloud שבו נמצאת המכונה.

אם המכונה של Looker (original) הוגדרה ל-SAML או ל-OpenID Connect, ודאו שבשדה Merge users using של שיטת האימות מצוינות רק שיטות אימות שנתמכות על ידי Looker (Google Cloud core).

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

כדי למנוע יצירה של חשבונות משתמשים כפולים כשממירים משתמשים, או כדי לפתור בעיות בחשבונות כפולים שנוצרו במהלך ההעברה, אפשר לעיין במאמר פתרון בעיות בחשבונות Looker כפולים בשינוי אימייל.

חיבורים למסדי נתונים

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

חיבורים למסדי נתונים באמצעות OAuth

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

חיבורים למאגר Git

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

הגדרת רשת אחרת

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

כתובת ה-URL לגישה למכונה של Looker (Google Cloud core)

למכונה של Looker (Google Cloud core) יש כתובת URL ראשית שמוקצית באופן אקראי. אם צריך לגשת למכונה דרך כתובת URL ספציפית, אפשר להגדיר דומיין מותאם אישית.

לוחות זמנים והתראות

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

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

חלונות זמן לתחזוקה

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

פעילות במערכת Elite

נתוני הפעילות של Elite System לא מועתקים כחלק מההעברה. המופע של Looker (Google Cloud core) יתחיל עם היסטוריה חדשה.

דומיין מותאם אישית

אתם יכולים ליצור דומיין מותאם אישית למכונה של Looker (Google Cloud core). כדי להבטיח את פריסת אישור ה-SSL, צריך להגדיר את רשומות ה-DNS. בנוסף, הקפידו לעדכן את כתובת ה-URL להחזרה (callback) בלקוח האימות לדומיין המותאם אישית, אחרי שהדומיין המותאם אישית מופעל ושיטת האימות מוגדרת. אי אפשר ליצור דומיינים מותאמים אישית ל-Looker (Google Cloud core) באמצעות דומיין looker.com.

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

אל תגדירו SAML או OpenID Connect למכונה של Looker (Google Cloud core) עד שהמכונה תהיה מוכנה לשימוש, רשומות ה-DNS יעודכנו והדומיין המותאם אישית יופעל.

סימניות

אם אתם משתמשים בכתובת URL מותאמת אישית במופע של Looker (original) (שלא משתמש בדומיין looker.com), תהליך ההעברה הזה אמור לשמור על הסימניות של המשתמשים אם תיצרו דומיין מותאם אישית למופע של Looker (Google Cloud core) באמצעות אותה כתובת URL כמו של המופע של Looker (original).

אחרי שמפעילים את הדומיין המותאם אישית, סימניות לתוכן של Looker (הגרסה המקורית), כמו https://www.yourcustomdomain.com/dashboard/123, יפנו לתוכן במכונה של Looker (Google Cloud core). (הערה: מהדורות Enterprise ו-Embed של Looker (ליבת Google Cloud) משתמשות בכתובות URL עם מזהי תוכן אלפאנומריים במקום מזהי תוכן מספריים, אבל סימנייה עם מזהה תוכן עדיין תפנה בצורה נכונה לאותו תוכן).

אי אפשר להשתמש בתהליך הזה עם כתובות URL של Looker (המקורית) שמשתמשות בדומיין looker.com.

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

בסיום ההעברה, ואחרי שאתם בטוחים שלא תצטרכו עוד ייצוא, אתם יכולים למחוק את <export-service-account> שיצרתם קודם. כך מפתח ה-JSON ששותף עבורו לא יהיה שימושי יותר.

הוצאה משימוש של המכונה של Looker (Original)

אחרי שהמופע של Looker (Google Cloud core) שהועבר פועל כמו שצריך, אתם יכולים לשלוח למשתמשים את כתובת ה-URL של המופע ולהנחות אותם להתחיל לגשת אליו ולהפסיק לגשת למופע של Looker (original).

פתרון בעיות

הסעיפים הבאים יכולים לעזור לכם לפתור בעיות במהלך הייבוא או הייצוא.

בעיות במהלך הייצוא

אם יש בעיה בייצוא הנתונים של Looker (original), הסטטוס ERROR יופיע בדף Export בחלונית Admin. אם לוחצים על הסטטוס ERROR, מופיעה הודעת שגיאה.

אלה כמה מהסיבות הנפוצות לשגיאות:

  • הקטגוריה של Cloud Storage, מפתח ה-KMS או <export-service-account> לא תקינים.
  • ל-<export-service-account> אין את ההרשאות הנדרשות.

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

בעיות במהלך הייבוא

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

מה השלב הבא?