העברת פרויקטים בין משאבי ארגון

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

פרויקטים בהיררכיית המשאבים

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

יכול להיות שתצטרכו להעביר פרויקטים בין משאבי ארגון בגלל רכישות, דרישות רגולטוריות או הפרדה של יחידות עסקיות. אפשר להשתמש ב-Resource Manager API כדי להעביר את הפרויקטים האלה. פעולת ההעברה מחזירה מחרוזת שמייצגת את שם הפעולה. ממשק ה-API מאפשר גם לבטל את ההעברה ולהחזיר את הפרויקט למקום המקורי שלו בהיררכיה, אם צריך.

תרחישי העברה

המיקום של הפרויקט קובע באיזו מבין שתי הדרכים תבחרו:

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

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

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

זיהוי המצב הנוכחי של הפרויקט

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

אם אין לכם את ההרשאה resourcemanager.organizations.get במשאב הארגון ברמת ההורה של הפרויקט, סביר להניח שהפרויקטים לא יוצגו כמו שציפיתם בארגון בפועל במסוףGoogle Cloud . יכול להיות שייראה כאילו הפרויקט לא משויך למשאב ארגוני כלשהו.

כדי לבדוק אם הפרויקט משויך למשאב ארגון, מריצים את הפקודה הבאה:

gcloud

gcloud projects get-ancestors PROJECT_ID

מחליפים את PROJECT_ID במזהה הפרויקט שרוצים להעביר.

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

אם הסוג organization חסר או ריק, הפרויקט הוא פרויקט עצמאי ללא משאב ארגוני.

בהתאם למצב הפרויקט, פועלים לפי המדריך הרלוונטי:

איך ההעברה פועלת

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

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

השפעה על המכסה

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

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

בדפים הבאים אפשר לראות אילו מכסות חלות על משאב ארגוני:

דוגמה

$ gcloud alpha services quota list --service=compute.googleapis.com --consumer=projects/workloadyee --filter="metric: compute.googleapis.com/cpus"

...
  - defaultLimit: '600'
    dimensions:
      region: us-central1
    effectiveLimit: '650'
...

שיקולים חשובים

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

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

  • מאגר משאבים: יכולים לחלוף כמה ימים עד שהעדכונים לרשימה המלאה של המשאבים במאגר המשאבים יתעדכנו באופן מלא אחרי ההעברה.

  • עלות והנחות: אם בארגון המקורי היו הנחות על סמך מק"ט או הנחות במסגרת תוכנית ההנחות של Enterprise (EDP), ההנחות האלה לא יחולו בארגון החדש עד שתנהלו משא ומתן לגביהן עם נציג המכירות של Google. יכול להיות שיהיה צורך גם לרכוש מחדש הנחות תמורת התחייבות לשימוש (CUD) ורכישות מ-Google Cloud Marketplace.

  • רמות תמיכה: אם אין חוזה תמיכה פעיל או רמת תמיכה נמוכה יותר בארגון היעד, יכול להיות שתאבדו את רמת התמיכה הנוכחית שלכם.

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

תוכנית ההעברה

התוכנית הבאה תעזור לכם להתמצא בתהליך העברת הפרויקט:

  1. הכנה: יוצרים תוכנית העברה כדי לתאם את התזמון.
  2. ביצוע: הקצאת תפקידי IAM והגדרת מדיניות ארגונית והפעלת ההעברה.
  3. אימות: השלמת משימות אחרי ההעברה, כמו ביקורת על מדיניות שהועברה ועדכון החיוב.

המאמרים הבאים