שימוש ברישיונות קיימים

במאמר הזה מוסבר איך Google Cloud תומך בהעברת רישיונות קיימים (BYOL) עם דרישות חומרה ייעודיות ל-Compute Engine. לפני שאתם מנסים להעלות ל- Google Cloudתמונות עם רישיונות קיימים, קראו את התנאים וההגבלות של הרישיונות.

כדי להעביר רישיונות קיימים לליבה פיזית או למעבד פיזי עם דרישות חומרה ייעודיות, צריך להביא מדיה משלכם ולהפעיל אותה בהגדרות חומרה שתואמות לרישיונות, כמו צמתים לדייר יחיד (sole-tenant). אפשר להביא קובצי אימג' עם רישיונות קיימים בכל אזור שתומך בצמתים של דייר יחיד. למרות שאין חיוב נוסף על הבאת קובצי אימג' עם רישיונות קיימים, עדיין צריך לשלם על הרישיונות בהתאם להסכמים.

תרחישי רישוי כמו רישיונות שקשורים ל-Linux BYOS עם RHEL או SLES, וגם אפליקציות של מיקרוסופט, לא דורשים שרתי לדייר יחיד. אם אתם שוקלים להביא רישיונות מאפליקציות של מיקרוסופט כמו SharePoint Server ו-SQL Server, השתמשו ב-Microsoft License Mobility.

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

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

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

  1. מכינים את התמונות בהתאם להסכמי הרישיון.

  2. מפעילים את הרישיונות.

  3. לייבא קובצי דיסק וירטואלי וליצור קובצי אימג' מקובצי הדיסק האלה.

  4. ליצור תבניות של צמתים לדייר יחיד.

  5. ליצור קבוצות של שרתים לדייר יחיד.

  6. מקצים מכונות וירטואליות בקבוצות הצמתים עם קובצי הדיסק הווירטואלי המיובאים.

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

  8. לדווח לספק על ניצול הרישיונות.

אם אתם צריכים תמיכה או שיש לכם שאלות לגבי רישוי, פנו למפיץ הרישוי שלכם. אם אתם צריכים תמיכה או שיש לכם שאלות לגבי העברת תמונות עם רישיונות קיימים אל Google Cloud, אתם יכולים לפנות לתמיכה של Google Cloud .

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

  • בדיקת מדיניות התחזוקה של המארח בקבוצת הצמתים: ב-BYOL יש שתי אפשרויות למדיניות תחזוקה של המארח, שמצמצמות את מספר השרתים הפיזיים שמשמשים למטרות רישוי. האפשרויות האלה הן restart-in-place ו-migrate-within-node-group.
  • בקשת מכסת מעבד (CPU) נוספת: פרויקטים חדשים מקבלים מכסת מעבד של 72. חשוב לוודא שיש לכם מכסת מעבד (CPU) מספיקה כדי לתמוך בקבוצת הצמתים. לדוגמה, סוג הצומת n1-node-96-624 מכיל 96 מעבדים, ואם קבוצת הצמתים משתמשת במספר המינימלי של צמתים (2), מכסת המעבדים צריכה להיות לפחות 192. בהתאם להגדרות ולצרכים של עומסי העבודה, יכול להיות שתצטרכו גם לבקש התאמה של המכסות למכונות וירטואליות או לכתובות IP.
  • הפעלת Cloud Build API: כדי לייבא את קובץ האימג' של מערכת ההפעלה, צריך להפעיל את Cloud Build API. כשמפעילים את ה-API הזה, Compute Engine נותן לפרויקט את תפקידי ה-IAM המתאימים כדי שתוכלו לייבא תמונות לפרויקט. כדי להציג את רשימת התפקידים שהוקצו לפרויקט, משתמשים בפקודה gcloud projects get-iam-policy. במאמר ניהול הגישה למשאבים של Compute Engine מוסבר איך מקצים תפקידים לפרויקט.
  • הפעלת Cloud Logging API: צריך להפעיל את ה-API הזה אם הסכמי הרישיון מחייבים מעקב אחרי השימוש בשרתים פיזיים. כשה-API הזה מופעל, אתם יכולים לייבא ולראות את נתוני השימוש בשרת, כמו מספר הליבות הפיזיות, באמצעות BigQuery (מומלץ מאוד על ידי Google). במאמר ניתוח השימוש בצומתי sole-tenant מוסבר איך לקבוע את מספר הליבות הפיזיות.
  • אם עדיין לא עשיתם את זה, תצטרכו להגדיר אימות. אימות הוא התהליך שבו מאמתים את הזהות שלכם כדי לקבל גישה לממשקי API ולשירותים של Google Cloud . כדי להריץ קוד או דוגמאות מסביבת פיתוח מקומית, אפשר לבצע אימות ל-Compute Engine באחת מהדרכים האלה:

    צריך לבחור את הכרטיסייה הרלוונטית לאופן שבו תכננתם להשתמש בדוגמאות בדף הזה:

    המסוף

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

    gcloud

    1. התקינו את ה-CLI של Google Cloud. אחר כך, אתחלו את ה-CLI של Google Cloud באמצעות הפקודה הבאה:

      gcloud init

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

  • הגדרת אזור ותחום כברירת מחדל.
  • REST

    כדי להשתמש בסביבת פיתוח מקומית בדוגמאות של API בארכיטקטורת REST שבדף הזה, צריך להשתמש בפרטי הכניסה שאתם נותנים ל-CLI של gcloud.

      התקינו את ה-CLI של Google Cloud.

      אם אתם משתמשים בספק זהויות חיצוני (IdP), קודם אתם צריכים להיכנס ל-CLI של gcloud באמצעות המאגר המאוחד לניהול זהויות.

    מידע נוסף מופיע במאמר אימות לשימוש ב-REST במסמכי האימות של Google Cloud .

ייבוא ויצירה של קובץ אימג' מדיסק וירטואלי אופליין

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

אם יש לכם דיסקים וירטואליים (golden disks או golden images) בסביבה המקומית עם הגדרות תוכנה או רישיונות שאתם צריכים, אתם יכולים להשתמש בכלי לייבוא דיסקים וירטואליים כדי:

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

  2. מגדירים את הרישיון המתאים.

  3. מתקינים את החבילות ומנהלי ההתקנים שנדרשים לתאימות עםGoogle Cloud.

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

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

קבצים שמאוחסנים ב-Cloud Storage ותמונות ב-Compute Engine כרוכים בחיובים. אחרי שמוודאים שהתמונה מיובאת ומופעלת בצורה תקינה כמכונה וירטואלית, אפשר למחוק את קובץ הדיסק הווירטואלי מ-Cloud Storage.

המסוף

  1. עוברים לדף Images.

    כניסה לדף Images

  2. לוחצים על יצירת תמונה.

  3. נותנים שם לתמונה.

  4. בקטע Source, בוחרים באפשרות Virtual disk (VMDK, VHD).

  5. בקטע Cloud Storage file, לוחצים על Browse ומחפשים את מיקום התמונה לייבוא ב-Cloud Storage.

  6. בקטע Operating system on virtual disk, בוחרים את מערכת ההפעלה של קובץ האימג' שרוצים לייבא.

  7. מוודאים שהאפשרות Install guest packages מסומנת, כדי שניתן יהיה להפעיל את קובץ האימג' שאתם מייבאים.

  8. מרחיבים את הקטע אפשרויות למפתח רישיון. בקטע OS License, בוחרים באפשרות Use your own license key.

  9. לוחצים על יצירה כדי לייבא את התמונה.

gcloud

מריצים את הפקודה gcloud compute images import כדי לייבא קובץ דיסק וירטואלי וליצור קובץ אימג' של דיסק מקובץ הדיסק הווירטואלי:

gcloud compute images import IMAGE_NAME \
    --source-file VMDK_NAME \
    --byol

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

  • ‫IMAGE_NAME: השם שרוצים לתת לתמונה שנוצרה מקובץ הדיסק הווירטואלי.
  • ‫VMDK_NAME: השם של הדיסק הווירטואלי שממנו רוצים לייבא וליצור קובץ אימג'. אפשר לייבא קובץ VMDK מהמקורות הבאים:

    • קובץ מקומי: אם אתם מייבאים מקובץ מקומי, השתמשו בנתיב מוחלט או בנתיב יחסי לקובץ. בהתאם לגודל הדיסק הווירטואלי ולמהירות החיבור לרשת, ההעלאה עשויה להימשך כמה עשרות דקות.
    • ‫Cloud Storage: אם מייבאים מ-Cloud Storage, הקטגוריה של Cloud Storage צריכה להיות באותו פרויקט שבו משתמשים כדי לייבא את הדיסק הווירטואלי, וצריך לציין את הנתיב המלא לקובץ בתור gs://BUCKET_NAME/OBJECT_NAME. מחליפים את BUCKET_NAME בשם הקטגוריה של Cloud Storage ואת OBJECT_NAME בשם האובייקט של Cloud Storage.

הפעלת רישיונות

אחרי שמוודאים שמייבאים מערכת הפעלה תואמת, אתם צריכים לבדוק שהסכמי הרישיון שלכם מאפשרים לכם להביא את הרישיון שלכם (BYOL), ושאתם רשאים להשתמש בקובץ האימג' של מערכת ההפעלה של האורח ובסביבת ייבוא הרישיונות ש-Google מספקת. אתם גם אחראים להכין את קובץ האימג' של מערכת ההפעלה של האורח לייבוא, בהתאם להסכמי הרישיון שלכם.

כדי להפעיל רישיון, משתמשים בסקריפטים לטעינה בזמן ההפעלה עם מפתח ההפעלה המרובה (MAK), או מגדירים גישה לשירות ניהול המפתחות (KMS) של מיקרוסופט בארגון. אי אפשר להפעיל קובצי אימג' עם רישיונות קיימים מול שרת הרישיונות של Compute Engine.

אחרי שמייבאים את קובץ האימג' ומפעילים את הרישיון, מקצים מכונה וירטואלית שמבוססת על קובץ האימג' המיובא לשרת לדייר יחיד (sole-tenant).

יצירת שרתים לדייר יחיד (sole-tenant)

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

  1. יוצרים תבניות של צומתי דייר יחיד לפי ההוראות במאמר יצירת תבניות של צומתי דייר יחיד.

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

    • אם הרישיונות שלכם מוקצים לכל ליבה פיזית, השתמשו במדיניות התחזוקה של המארח restart-in-place או migrate-within-node-group כדי לצמצם את מספר השרתים הפיזיים שבהם אתם משתמשים.
    • אם הרישיונות שלכם מוקצים לכל משתמש או מכשיר (כמו רישיונות של Virtual Desktop), השתמשו במדיניות התחזוקה של המארח default, כי במודלים האלה לא צריך להגביל את השימוש בשרת הפיזי.

    מידע נוסף זמין במאמר כללי מדיניות לתחזוקת מארחים.

הקצאת VM לדייר יחיד

מקצים VM בקבוצת הצמתים ומציינים את מדיניות התחזוקה של המארח. חשוב לשים לב לדרישות הבאות:

  • כדי להקצות בקבוצות של צמתים עם מדיניות תחזוקה של מארח restart-in-place, צריך לוודא שהערך של האפשרות on host maintenance במכונה הווירטואלית הוא TERMINATE.
  • כדי להקצות בקבוצות צמתים עם מדיניות תחזוקה מסוג migrate-within-node-group, צריך לוודא שהמכונה הווירטואלית מטרגטת קבוצת צמתים אחת עם תווית השיוך (affinity) node-group-name, ושהיא לא מטרגטת צמתים בודדים עם תווית השיוך (affinity) node-name. כל סוג של אפשרות לתחזוקת מארח מתאים, אבל מומלץ להשתמש ב-MIGRATE.

המסוף

אם השתמשתם בתוויות של שיוך לצומת בתבנית, אתם יכולים ליצור כמה מכונות וירטואליות באמצעות קבוצות מופעי מכונה מנוהלים (MIGs) ולציין את התוויות של השיוך לצומת בהגדרות של Sole-tenant nodes. לחלופין, אתם יכולים ליצור מכונות וירטואליות נפרדות מדף הפרטים של קבוצת הצמתים:

  1. נכנסים לדף Sole-tenant nodes.

    כניסה לדף Sole-tenant nodes

  2. לוחצים על Name של קבוצת הצמתים שבה רוצים להקצות מכונה וירטואלית.

  3. יוצרים מכונה וירטואלית בשרת לדייר יחיד באחת מהדרכים הבאות:

    • כדי ליצור מכונה וירטואלית בכל מקום בקבוצת השרתים לדייר יחיד, לוחצים על Create instance.
    • כדי ליצור מכונה וירטואלית בשרת ספציפי לדייר יחיד, לוחצים על Name של קבוצת שרתים לדייר יחיד, ואז על Name של שרת לדייר יחיד, ואז על Create instance.
  4. מגדירים את המכונה הווירטואלית של הדייר היחיד. כבר בחרתם את קבוצת הצמתים או צומת ספציפי, ולכן Region,‏ Zone ו-Node affinity labels כבר צוינו בתבנית.

  5. בוחרים Machine configuration על ידי ציון משפחת מכונות,‏ Series ו-סוג מכונה. בוחרים את Series שתואמת ל-sole-tenant node type.

  6. בוחרים את דיסק האתחול של ה-VM בדייר יחיד, שהוא קובץ האימג' של הדיסק הווירטואלי שיובא קודם לכן.

  7. לוחצים על הכרטיסייה ניהול:

    • בקטע Availability policy > On host maintenance, בוחרים את אופן ההפעלה מחדש של המכונה הווירטואלית.
    • בקטע הפעלה מחדש אוטומטית, בוחרים באפשרות מופעלת (מומלץ) או מושבתת.
  8. לוחצים על יצירה.

gcloud

מקצים VM של דייר יחיד בקבוצת צמתים של דייר יחיד באמצעות הפקודה gcloud compute instances create.

gcloud compute instances create VM_NAME \
    --machine-type MACHINE_TYPE \
    --image IMAGE_NAME \
    --zone ZONE \
    --node-group GROUP_NAME \
    RESTART_BEHAVIOR \
    --maintenance-policy MAINTENANCE_POLICY

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

  • ‫VM_NAME: השם של המכונה הווירטואלית שרוצים ליצור.
  • ‫MACHINE_TYPE: סוג המכונה של ה-VM החדש.
  • ‫IMAGE_NAME: התמונה שממנה יוצרים מכונה וירטואלית. זו התמונה שנוצרה בתהליך הייבוא.
  • ‫ZONE: האזור שבו יוצרים את המכונה הווירטואלית.
  • ‫GROUP_NAME: שם קבוצת הצמתים שבה רוצים להקצות את המכונה הווירטואלית.
  • ‫RESTART_BEHAVIOR: התנהגות ההפעלה מחדש של המכונה הווירטואלית הזו. מגדירים את התנהגות ההפעלה מחדש לאחד מהערכים הבאים:

    • --restart-on-failure
    • --no-restart-on-failure
  • ‫MAINTENANCE_POLICY: ההתנהגות של המכונה הווירטואלית במהלך אירועי תחזוקה. מגדירים את מדיניות התחזוקה לאחד מהערכים הבאים:

    • MIGRATE
    • TERMINATE

REST

מקצים VM בשרת לדייר יחיד בקבוצת שרתים לדייר יחיד באמצעות השיטה instances.insert.

POST https://compute.googleapis.com/compute/v1/projects/PROJECT_ID/zones/VM_ZONE/instances

{
  "name": "VM_NAME",
  "machineType": "/zones/MACHINE_TYPE_ZONE/machineTypes/MACHINE_TYPE",
  "scheduling": {
    "nodeAffinities": [
      {
        "key": "node-group",
        "operator": "IN",
        "values": [
        "GROUP_NAME"
        ]
      }
    ],
    "onHostMaintenance": "MAINTENANCE_POLICY",
    "automaticRestart": "AUTOMATIC_RESTART"
  },
  "networkInterfaces": [
    {
     "network": "/global/networks/NETWORK",
     "subnetwork": "/regions/region/subnetworks/SUBNETWORK"
    }
  ],
  "disks": [
    {
      "boot": true,
      "initializeParams": {
        "sourceImage": "/projects/IMAGE_PROJECT/global/images/family/IMAGE_FAMILY"
       }
    }
  ]
}

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

  • ‫PROJECT_ID: מזהה הפרויקט שבו יוצרים את המכונה הווירטואלית.
  • ‫VM_ZONE: האזור שבו יוצרים את המכונה הווירטואלית.
  • ‫VM_NAME: השם של המכונה הווירטואלית החדשה.
  • ‫MACHINE_TYPE_ZONE: האזור שבו נמצא סוג המכונה.
  • ‫MACHINE_TYPE: סוג המכונה שבה רוצים להקצות את המכונה הווירטואלית.
  • ‫GROUP_NAME: שם קבוצת הצמתים שבה רוצים להקצות את המכונה הווירטואלית.
  • ‫MAINTENANCE_POLICY: ההתנהגות של המכונה הווירטואלית במהלך אירועי תחזוקה, שמוגדרת ל-MIGRATE או ל-TERMINATE.
  • ‫AUTOMATIC_RESTART: קובע אם המכונה הווירטואלית תופעל מחדש באופן אוטומטי אם Compute Engine יעצור אותה. ערך ברירת המחדל הוא true.
  • ‫NETWORK: שם הרשת שאליה רוצים לחבר את המכונה הווירטואלית.
  • ‫SUBNETWORK: השם של רשת המשנה שאליה רוצים לחבר את המכונה הווירטואלית.
  • ‫IMAGE_PROJECT: פרויקט התמונה שמכיל את תמונת המקור.
  • ‫IMAGE_FAMILY: משפחת התמונות של תמונת המקור.

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