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

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

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

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

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

תרחישי העברה

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

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

אם אתם צריכים להעביר פרויקט בחזרה ל-No organization אחרי שהוא משויך למשאב ארגון, אתם צריכים לפנות ל-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'
...

שיקולים קריטיים

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

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

  • Asset Inventory: עדכונים לרשימה המלאה של המשאבים ב-מאגר משאבי ענן יכולים להימשך כמה ימים עד להשלמת ההעברה.

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

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

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

מפת הדרכים של המעבר

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

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

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