במאמר הזה מוסבר על דפוסי ארכיטקטורה לחיפוש ולאיסוף מידע על נכסים ב- Google Cloud, בפלטפורמות ענן אחרות ובסביבות מקומיות באמצעות ServiceNow Cloud Discovery. המסמך מיועד לצוותי ארכיטקטורה או לצוותי תפעול בענן שמכירים את ניהול תפעול ה-IT (ITOM), את ספריית תשתית טכנולוגיית המידע (ITIL), Google Cloud שירותים כמו Compute Engine, Google Kubernetes Engine (GKE) ומאגר משאבי ענן, ואת ServiceNow Cloud Discovery.
סקירה כללית
ארגונים גדולים רבים משתמשים בפריסת תשתית IT היברידית שמשלבתGoogle Cloud, פלטפורמות ענן אחרות ותשתית מקומית. פריסה היברידית כזו היא בדרך כלל האיטרציה הראשונית באסטרטגיית העברה לענן. מחלקות ה-IT בארגונים האלה נדרשות לגלות את כל הנכסים במערכת האקולוגית הטכנית שלהם ולעקוב אחריהם, ומספר הנכסים יכול להגיע למיליונים. מחלקות ה-IT צריכות לבנות מערכת לניהול ההגדרות שמקשרת בין הנכסים האלה לבין השירותים הטכניים שהנכסים מספקים. המערכת הזו צריכה גם לעקוב אחרי הנכסים והשירותים באופן שתומך בשיטות המומלצות לניהול פעולות IT (ITOM) ולניהול שירותי IT (ITSM).
לקוחות Google Cloud משתמשים בארכיטקטורה נפוצה שכוללת את הכלי לאיתור משאבי ענן של ServiceNow כדי למצוא ולאסוף מידע על נכסים ב- Google Cloud, בפלטפורמות ענן אחרות ובמערכות מקומיות. ServiceNow מציעה מגוון רחב של כלים לאוטומציה של תהליכי עבודה ב-IT לניהול משאבים אצל ספקי ענן שונים. כלים כמו Cloud Operations Workspace מאפשרים למחלקות IT ליצור לוחות בקרה של משאבים בענן מרובה ולנהל תצורות מורכבות באמצעות ממשק מאוחד (לפעמים נקרא single pane of glass). במסמך הזה מוצגות קבוצה של דפוסי ארכיטקטורה לתרחיש הזה, סקירה כללית של הרכיבים ברמה הגבוהה ודיון בשיקולי עיצוב כלליים.
רכיבי ServiceNow בארכיטקטורה הזו
הרכיבים של פלטפורמת ServiceNow בדפוסי הארכיטקטורה האלה כוללים את הרכיבים הבאים:
- מופע של ServiceNow שמכיל מסד נתונים לניהול הגדרות (CMDB) של פריטי הגדרה (CI). כל פריט CI מייצג רכיבים בסביבה התפעולית שלכם שמעורבים באספקת שירותים דיגיטליים. לפריט CI יש כמה מאפיינים שמכילים מטא-נתונים ספציפיים לגבי הרכיב והקשרים שלו לפריטי CI אחרים.
- אחד או יותר משרתי ServiceNow Management, Instrumentation, and Discovery (MID) שפועלים בפרויקט Google Cloud . שרתי MID אוספים את המטא-נתונים של פריטי התצורה ומאחסנים אותם ב-CMDB.
בדפוסי הארכיטקטורה האלה מוגדרות כמה שיטות נפוצות לייבוא נתונים ממאגר משאבי הענן של Google אל מאגר הנכסים של Google Cloud Platform ב-ServiceNow.
דפוסי ארכיטקטורה לשילוב Google Cloud
במסמך הזה נדון בדפוסי הארכיטקטורה הבאים לשילוב שלGoogle Cloud עם ServiceNow:
דפוסי הארכיטקטורה לדוגמה האלה מיועדים לפריסה היברידית שכוללת תשתית מסוימת ב- Google Cloud וחלק ב-ServiceNow Cloud. הם מדגימים איך ServiceNow פועל Google Cloud בין תשתית שמנוהלת על ידי Google ותשתית שמנוהלת על ידי הלקוח. שרתי ServiceNow MID שולחים שאילתות לכל התשתית שמנוהלת על ידי Google באמצעות קריאה ל-Google Cloud APIs. מידע נוסף על ממשקי ה-API שמתבצעת אליהם קריאה זמין במאמר ממשקי Google Cloud Platform API שמשמשים אפליקציות ITOM.
בכל אחד מהדפוסים הבאים, רכיבי הארכיטקטורה פועלים יחד בתהליך הגילוי של מלאי הנכסים ב-Google Cloud Platform כדי לאסוף את המידע על מלאי הנכסים בענן שנדרש לאפליקציית ServiceNow Discovery ולכלים קשורים.
Google Cloud תבנית גילוי
הארכיטקטורה הבסיסית של גילוי הענן ב-ServiceNow משתמשת ב-ServiceNow MID Servers כדי לקרוא ל-Google Cloud Asset Inventory ולממשקי API אחרים של Google Cloud, במטרה לאסוף נתונים על משאבים כמו:
- מכונות וירטואליות
- תגים (מפתחות/ערכים)
- אמצעי אחסון ומיפוי אחסון
- משאבים במרכזי נתונים, כולל סוגי חומרה
- רשתות, תת-רשתות ושערים בענן
- תמונות
- מאזני עומסים ב-Cloud ואזורי זמינות
- מסדי נתונים בענן ואשכולות של מסדי נתונים
- קונטיינרים (GKE)
- מיפוי שירותים על סמך תוויות משאבים
בתבנית הזו, לשרתי ה-MID לא נדרשים פרטי כניסה, כי הם לא מתחברים למכונות הווירטואליות כדי לאסוף נתונים. כך מוגבלת היכולת של תהליך הגילוי לאסוף מידע נוסף. אבל העלות התפעולית שלו נמוכה יותר, כי הוא מבטל את הצורך לנהל ולשנות את פרטי הכניסה של MID Server.
התרשים הבא ממחיש את דפוס הארכיטקטורה הזה.
החלק Google Cloud בדפוס הזה כולל את הרכיבים הבאים:
- פרויקט אחד Google Cloud (פרויקט שירות א' בתרשים), שכולל שני Google Cloud מאזני עומסים, מכונה וירטואלית אחת או יותר, מופע GKE ושרת MID אחד או יותר של ServiceNow. כל שרת MID פועל במכונה וירטואלית משלו.
- פרויקט שני Google Cloud (פרויקט שירות ב' בתרשים), שכולל שרתי MID שפועלים במכונות וירטואליות משלהם.
- פרויקט שלישי Google Cloud (פרויקט מארח C בתרשים), שמורכב מחיבור Partner Interconnect.
- שירותים מנוהלים נוספים, כמו Cloud APIs, BigQuery ו-Cloud Storage.
- נתיבי רשת שמוגדרים משרתי ה-MID אל Google Cloud APIs.
החלק של ServiceNow כולל את המכונה של ServiceNow, שמתעדת את המטא-נתונים משרתי ה-MID ומאחסנת אותם ב-CMDB.
Google Cloud תבנית גילוי מבוססת-IP ללא סוכן
בדפוס הארכיטקטורה הזה נוספת גילוי מבוסס-IP לדפוס הגילוי הבסיסי בענן, באמצעות משימה באצווה וGoogle Cloud חשבון שירות כדי להתחבר למכונות וירטואליות ולאסוף פרטים נוספים. התבנית הזו דורשת יותר עומס תפעולי לניהול שרת ה-MID מאשר התבנית הבסיסית, כי צריך לנהל את פרטי הכניסה של שרת ה-MID ולשנות אותם מדי פעם. עם זאת, הוא מרחיב את תהליך הגילוי מעבר לנתונים שמסופקים על ידי מאגר משאבי הענן (CAI) וכולל נתונים נוספים, כמו:
- ניהול אבטחה ואישורים במערכת ההפעלה
- גילוי משופר, כמו גילוי מבוסס-קבצים וגילוי של רישיונות
- פרטי מערכת ההפעלה
- תהליכים פעילים
- חיבורי TCP
- תוכנה מותקנת
בדפוס הארכיטקטורה הזה, שרת MID אחד או יותר של ServiceNow ממוקמים ב-Google Cloud, בעוד שמופע ServiceNow מתארח בפלטפורמת הענן של ServiceNow. שרתי ה-MID מחוברים למופע ServiceNow דרך תור ערוץ התקשורת החיצוני של שרת ה-MID (ECC) (לא מוצג). הארכיטקטורה הזו מוצגת בתרשים הבא.
החלק Google Cloud בדפוס הזה כולל את הרכיבים הבאים:
- פרויקט שירות א', שמורכב משני Google Cloud מאזני עומסים, מכונה וירטואלית אחת או יותר, מופע GKE ושרת MID אחד או יותר של ServiceNow. כל שרת MID פועל במכונה וירטואלית משלו.
- פרויקט שירות ב', שמורכב משרתי MID שפועלים במכונות וירטואליות משלהם.
- פרויקט מארח C, שכולל את קישוריות השותף.
- שירותים מנוהלים נוספים, כמו Cloud APIs, BigQuery ו-Cloud Storage.
- ServiceNow Kubernetes Discovery נפרס בתשתית GKE.
- נתיבי רשת שמוגדרים משרתי ה-MID אל Google Cloud APIs.
- חשבונות שירות שמאפשרים לשרתי MID להיכנס לכל Google Cloud המכונות הווירטואליות שנדרש בהן זיהוי של כתובות IP בלי שרת (serverless).
- מסלולי רשת שמוגדרים משרתי ה-MID לכלGoogle Cloud מכונה וירטואלית שנדרש בה זיהוי של כתובת IP ללא שרת.
החלק של ServiceNow כולל את המכונה של ServiceNow, שמתעדת את המטא-נתונים משרתי ה-MID ומאחסנת אותם ב-CMDB.
Google Cloud גילוי באמצעות התבנית Agent Client Collector
דפוס הארכיטקטורה הזה כולל את הרכיבים הבאים:
- הגילוי הראשוני של הענן.
- שרת MID אחד או יותר.
סוכן נוסף של ServiceNow, Agent Client Collector, שמתקינים במכונות הווירטואליות. הסוכנים האלה מתחברים ישירות לשרתים של MID ומעבירים את המידע הנוסף הבא ל-ServiceNow:
- גילוי מבוסס-דחיפה כמעט בזמן אמת
- מדידת השימוש בתוכנה
- תצוגת CI בזמן אמת
- אוטומציה של תהליכי עבודה בשרתים
התרשים הבא ממחיש את דפוס הארכיטקטורה הזה.
החלק Google Cloud בדפוס הזה כולל את הרכיבים הבאים:
- פרויקט שירות א', שמורכב משני מאזני Google Cloud עומסים, ממכונה וירטואלית אחת או יותר, ממופע GKE ומשרת ServiceNow MID אחד או יותר. כל שרת MID פועל במכונה וירטואלית משלו.
- פרויקט שירות ב', שמורכב משרתי MID שפועלים במכונות וירטואליות משלהם.
- פרויקט מארח C, שכולל את קישוריות השותף.
- ServiceNow Kubernetes Discovery נפרס בתשתית GKE.
- שירותים מנוהלים נוספים, כמו Cloud APIs, BigQuery ו-Cloud Storage.
- נתיבי רשת שמוגדרים משרתי ה-MID אל Google Cloud APIs.
- נתיבי רשת שמוגדרים משרתי ה-MID למכונות וירטואליות שלGoogle Cloud שמותקנים בהן סוכני ServiceNow Discovery.
החלק של ServiceNow מורכב מהרכיבים הבאים:
- מופע ServiceNow, שמתעד את המטא-נתונים משרתי ה-MID ומאחסן אותם ב-CMDB.
- סוכני ServiceNow Discovery שמותקנים במכונות וירטואליות (VM) שלGoogle Cloud בניהול הלקוח.
תהליך העבודה של גילוי נכסי ענן
בקטעים הבאים מפורט תהליך העבודה של Google Cloud גילוי נכסים. תהליך העבודה הזה רלוונטי לכל שלושת דפוסי הארכיטקטורה שמתוארים במסמך הזה.
התקנה והגדרה של רכיבי ServiceNow
- מפעילים את ממשקי ה-API של מאגר משאבי הענן.
- מתקינים את Agent Client Collector במכונות הווירטואליות. מידע נוסף זמין במאמר בנושא התקנת Agent Client Collector.
- הקצאת משאבים למחשבים שמארחים את שרתי ה-MID.
- מגדירים כללי חומת אש כדי לאפשר חיבורים ביציאה 443 בין מופע המכונה הווירטואלית לבין המחשבים שמארחים את שרתי ה-MID.
- הגדרת קישוריות לרשת של שרת MID
- התקנת שרתי MID
- מגדירים את שרתי ה-MID כך שיקראו לממשקי Google Cloud APIs הרלוונטיים. מוודאים שלשרתי ה-MID יש נתיב רשת תקין לביצוע קריאות לממשקי Google Cloud API.
תהליך עבודה
- ב-Cloud Asset Inventory נוצר מסד נתונים של כל סוגי הנכסים הנתמכים בסביבת Google Cloud . ServiceNow משתמשת במאגר משאבי ענן כמקור לאחזור מידע נוסף כדי לעדכן את CMDB.
- שרתי ה-MID של ServiceNow שולחים שאילתות למסד הנתונים של מאגר משאבי הענן כדי לקבל מידע על כל הנכסים בסביבת Google Cloud .
- שרתי ה-MID מאחסנים את פרטי נכסי הענן בקטגוריה של Cloud Storage.
- לא ניתן לקבל את כל המידע הנדרש ממסד הנתונים של מאגר משאבי ענן. בתבנית ללא סוכן, פרטי ה-VM לא כוללים את גרסת הטלאי הנוכחית של מערכת ההפעלה. כדי לקבל את רמת הפירוט הזו, שרתי ה-MID מבצעים גילוי מעמיק באמצעות הפעולות הבאות:
- שרתי ה-MID יוצרים משימה באצווה על סמך כתובות ה-IP של המכונות הווירטואליות שנדרש לגביהן גילוי מעמיק.
- במשימת האצווה, שרתי ה-MID מתחברים לכל מכונה וירטואלית ושולחים שאילתה למערכת ההפעלה כדי לקבל מידע על גרסת התיקון ומידע נוסף.
- אם מותקנים כלי איסוף של סוכני לקוחות, הנתונים שהם אוספים מועברים ישירות לשרתים של MID, ולא מאוחסנים במאגר משאבי ענן. מידע נוסף זמין במאמרים הכנה של הרשת והגדרת שרת MID.
- אחרי איסוף הנתונים של גילוי הנכסים, שרתי ה-MID מאחסנים אותם ב-CMDB באופן הבא:
- שרתי ה-MID יוצרים פריטי תצורה ב-CMDB כדי לייצג את היכולת התפעולית שכל נכס מספק.
- שרתי ה-MID מגלים באופן אוטומטי תוויות מ-Google Cloud ומאחסנים אותן ב-CMDB. התוויות האלה ממופות ל-CIs באופן אוטומטי, והן שימושיות ליצירת מפות שירות.
צריך לחזור על תהליך העבודה מדי פעם לפי הצורך. בהתאם להיקף ולתצורה של הפריסה, יכול להיות שתבחרו ב-discovery מבוסס-אירועים או ב-discovery מבוסס-לוח זמנים. מידע נוסף זמין במאמר בנושא הנחיות לעיצוב CMDB, בקטע 'ניהול מחזור החיים של ה-CI'.
שיקולים בתכנון
בקטעים הבאים מפורטות הנחיות לתכנון של הטמעה של כל אחד מדפוסי הארכיטקטורה שמתוארים במסמך הזה.
המיקום של מופע ServiceNow
ברוב תרחישי השימוש, מומלץ לפרוס את שרתי ה-MID ב-Google Cloud. כך המכונות יהיו קרובות לנכסי הענן שבהם הן מבצעות גילוי מעמיק.
ההנחה לגבי דפוסי הארכיטקטורה שמתוארים במסמך הזה היא שבמסד הנתונים שלכם לניהול תצורה (CMDB) מאוחסנים נתוני גילוי של כל משאבי הענן וכל המשאבים המקומיים, ולא רק של נכסי Google Cloud החברה. ה-CMDB יכול להיות ממוקם בענן של ServiceNow, ב- Google Cloudאו בשרת מקומי. ההחלטה הסופית לגבי המיקום של CMDB בסביבה שלכם תלויה בדרישות הספציפיות שלכם.
החלטה להשתמש בסוכני MID Server
שיקול נוסף בתכנון הוא אם להשתמש בסוכני MID Server ובחשבונות שירות. אם בתהליך הגילוי שלכם נדרש איסוף מידע מעבר למטא-נתונים שמאגר משאבי ענן מספק, אתם צריכים להשתמש בתשתית של שרת MID עם חשבונות שירות, או לחלופין, בשרת MID עם Agent Client Collector. כל אחת מהגישות האלה יכולה להשפיע על עלות התמיכה התפעולית, וצריך לקחת את זה בחשבון בתכנון. הגישה שבה צריך להשתמש תלויה בנתונים שאתם צריכים לתעד ובאופן שבו תשתמשו בנתונים. העלות התפעולית של איסוף הנתונים עשויה להיות גבוהה מהערך שהנתונים מספקים.
תמיכה בשרתי MID בכמה אזורים
אם החברה שלכם דורשת תמיכה במספר אזורים בתשתית של שרת ה-MID, כדאי לתכנן פריסה של כל שרת MID בשני אזורי זמינות לפחות, ולשכפל אותו לאזור אחר.
השלכות על העלויות
כשבוחרים איפה לפרוס את רכיבי ServiceNow לGoogle Cloud גילוי נכסים, צריך לקחת בחשבון את עלות היציאה ואת עלות המחשוב.
עלות של תעבורת נתונים יוצאת (egress)
חיובים על תעבורת נתונים יוצאת חלים בכל פעם שנתונים יוצאים מ- Google Cloud. לכן, כדאי לנתח את עלות היציאה לתרחיש השימוש שלכם כדי לקבוע מהי האפשרות הטובה ביותר למיקום רכיבי ServiceNow. בדרך כלל, עלויות היציאה של שרתים מסוג MID שמבצעים גילוי מעמיק נמוכות יותר אם הם פועלים ב-Google Cloud מאשר אם הם פועלים בענן אחר או בשרת מקומי.
עלות מחשוב
רכיבי ServiceNow שפועלים ב- Google Cloud כרוכים בעלויות מחשוב שכדאי לנתח כדי לקבוע מהו הערך הטוב ביותר לחברה שלכם.
לדוגמה, כדאי לשקול את מספר שרתי ה-MID שאתם פורסים במכונות שלGoogle Cloud Compute Engine. הטמעה של יותר שרתי MID מאפשרת לזרז את תהליך איתור הנכסים. אבל הפעולה הזו מגדילה את עלות המחשוב, כי כל שרת MID נפרס במכונת VM משלו. מידע נוסף על פריסה של שרת MID אחד או כמה שרתי MID זמין במאמר בנושא התקנה של כמה שרתי MID במערכת אחת.
שיקולים לגבי תמיכה תפעולית
הפריסה שלכם כנראה כוללת אמצעי בקרה לאבטחת רשתות, כמו חומות אש, מערכות להגנה מפני פריצות, מערכות לזיהוי פריצות ותשתית של שיקוף מנות. אם יש אמצעי בקרה נרחבים לאבטחת רשת בין Google Cloud לסביבה שבה שרתי ה-MID נפרסים, אמצעי הבקרה האלה עלולים ליצור בעיות בתמיכה התפעולית. כדי למנוע את הבעיות האלה, מומלץ לארח את שרתי ה-MID ב- Google Cloudאו קרוב ככל האפשר לתשתית Google Cloud שאליה יופנו שאילתות של גילוי עמוק.
אבטחת שרתי MID
אנחנו ממליצים על שיטות האבטחה הבאות עבור מופעי MID Server:
- חשוב לוודא ששרתי ה-MID מבודדים כדי להבטיח שרק אדמינים מהימנים יוכלו להתחבר אליהם.
- חשוב לוודא ששרתי ה-MID מוגנים מפני מחיקה.
- חשוב לוודא שתפקידי IAM מוחלים כדי להגביל את היכולת לבצע שינויים רק לשינויים שאושרו באמצעות תהליכי ITIL או באמצעות צינור עיבוד נתונים של CI/CD.
אבטחת חשבונות שירות
אלה שיטות מומלצות לאבטחה של חשבונות שירות:
- חשוב לוודא ששרתי ה-MID משתמשים בחשבון שירות שיש לו רק את תפקידי ה-IAM וההרשאות שנדרשים לגילוי נכסים. מידע נוסף על שיטות מומלצות לעבודה עם חשבונות שירות
- כדי לבצע אימות ב-ServiceNow, צריך להעתיק את התוכן של מפתח חשבון שירות לממשק המשתמש של ServiceNow.
מפתחות של חשבונות שירות מהווים סיכון אבטחה אם לא מנהלים אותם בצורה נכונה. באחריותכם לאבטח את המפתח הפרטי ולבצע פעולות אחרות שמתוארות במאמר
שיטות מומלצות לניהול מפתחות לחשבונות שירות.
אם אין לכם אפשרות ליצור מפתח לחשבון שירות, יכול להיות שהיצירה של מפתחות לחשבון שירות מושבתת בארגון שלכם. מידע נוסף זמין במאמר בנושא
ניהול משאבי ארגון שמוגדרים כמאובטחים כברירת מחדל.
אם קיבלתם את המפתח של חשבון השירות ממקור חיצוני, אתם צריכים לאמת אותו לפני השימוש. מידע נוסף זמין במאמר בנושא דרישות אבטחה לפרטי כניסה ממקור חיצוני.
מבנה התיקיות והפרויקטים
תיקיות ופרויקטים הם צמתים ב Google Cloud היררכיית המשאבים. כדי לתמוך באיתור נכסים, מבנה התיקיות והפרויקטים צריך לשקף את מבנה האפליקציה ואת הסביבות שבהן האפליקציה נפרסת. בנוסף, המבנה הזה של המשאבים מאפשר ל-ServiceNow למפות את הנכסים לשירותים הטכניים שהם מספקים.
חשוב לשים לב לשינויים שמבצעים במבנה התיקיות והפרויקטים כדי לתמוך באיתור של ServiceNow. המטרה העיקרית של מבנה התיקיות והפרויקטים היא לתמוך בחיוב ובגישה ל-IAM. לכן, כל שינוי שתבצעו כדי לתמוך ב-ServiceNow צריך לתמוך בGoogle Cloud מבנה החיוב של הארגון שלכם ולהתאים לו. במאמרים היררכיית משאבים ויצירה וניהול של ארגונים מוסבר על שיטות מומלצות לבניית היררכיה שלGoogle Cloud ארגונים, תיקיות ופרויקטים.
בתרשים הבא מוצגת דוגמה להיררכיית משאבים מלאה של Google Cloud . בדוגמה הזו, מבנה התיקיות מגדיר את האפליקציה, וכל פרויקט מגדיר סביבה.
תוויות
תוויות הן צמדי מפתח/ערך שאפשר להקצות למשאבי הענן. (ServiceNow, AWS ו-Azure מתייחסים לתוויות כתגים).
ServiceNow משתמשת בתוויות שאתם מקצים לנכסים Google Cloud שלכם כדי לזהות את הנכסים ולמפות אותם לשירותים (אופציונלי). בחירת תוכנית טובה של תיוג עוזרת ל-ServiceNow לעקוב אחרי התשתית שלכם כדי לספק דיווח מדויק ותאימות ל-ITOM/ITSM.
מומלץ להשתמש בתוויות לכל המשאבים שנדרש עבורם זיהוי ייחודי ספציפי יותר ממה שמאפשרת מבנה התיקיות והפרויקטים. לדוגמה, כדאי להשתמש בתוויות במקרים הבאים:
- אם יש דרישות תאימות מחמירות לאפליקציה שלכם, אתם יכולים להוסיף תוויות לכל משאבי האפליקציה כדי שהארגון יוכל לזהות בקלות את כל התשתית שנכללת בהיקף.
- בסביבה מרובת עננים, אפשר להשתמש בתוויות כדי לזהות את ספק הענן והאזור של כל המשאבים.
- אם אתם צריכים נראות מפורטת יותר מזו שמופיעה כברירת מחדל בדוחות החיוב ב-Cloud או בייצוא של נתוני החיוב ב-Cloud ל-BigQuery, תוכלו לסנן את הנתונים לפי תוויות.
Google מקצה באופן אוטומטי תוויות לנכסים שמנוהלים על ידי Google ופועלים ב-VPC שלכם. התוויות שמוקצות על ידי Google מתחילות בקידומת goog-. שרתי ה-MID שלכם לא צריכים לנסות לבצע בדיקה מעמיקה של הנכסים האלה. למידע נוסף על תוויות למשאבים שמנוהלים על ידי Google, אפשר לעיין במאמרים בנושא מיפוי מבוסס-תגים והוספת תוויות למשאבים באופן אוטומטי על סמך התראות בזמן אמת ממאגר משאבי ענן.
בטבלה הבאה מפורטות התוויות ש Google Cloud שירותים מקצים ל משאבים שהם מנהלים.
| שירותGoogle Cloud | תוויות או קידומות של תוויות |
|---|---|
| Google Kubernetes Engine |
goog-gke-
|
| Compute Engine |
goog-gce-
|
| Managed Service for Apache Spark |
goog-dataproc-
|
| Gemini Enterprise Agent Platform Workbench |
goog-caip-notebook and goog-caip-notebook-volume
|
כדי לתמוך בניהול משאבים בצורה יעילה, תהליך הפריסה של הארגון צריך ליצור מבני פרויקטים ותיקיות ולהקצות תוויות נכסים באופן עקבי בכל הארגון. חוסר עקביות בתשתית ובתוויות יכול להקשות על שמירה של CMDB תקין ללא תהליכים ידניים, שסביר להניח שלא ניתן יהיה לתמוך בהם ושיוצבו אתגרים לגבי הרחבת היקף השימוש בהם בטווח הארוך.
הרשימה הבאה כוללת שיטות מומלצות שיעזרו לכם להפוך את תהליך הפריסה לעקבי וניתן לחזרה:
- שימוש בתשתית כקוד (IaC) או במערכות הקצאת משאבים אוטומטיות כמו Terraform, ServiceNow ITOM או הקצאת משאבים בענן וניהול באמצעות Google Cloud Deployment Manager.
- חשוב להגדיר תהליך ניהול תקין לתוויות. סקירה כללית על ניהול תוויות זמינה במאמר Tag Governance (ניהול תוויות) במסמכי העזרה של ServiceNow.
המאמרים הבאים
- מידע על מחבר השילוב ל-ServiceNow
- במאמרים מדריך בנושא ארגון משאבים וניהול הרשאות גישה בחיוב ב-Cloud ומדריך להגדרה של Cloud Insights ב-Google Cloud מפורטות שיטות מומלצות נוספות לארגון המשאבים בחיוב ב-Cloud.
- במאמרים שיטות מומלצות לתכנון חשבונות וארגונים והקצאת הרשאות וניהול ב-Cloud מפורטות שיטות מומלצות להגדרת הרשאות IAM בארגון.
- לשיטות מומלצות בנוגע למבנה של מדיניות חומת האש ב-VPC בארגון, אפשר לעיין במאמר בנושא מדיניות חומת אש היררכית.
- איך משתמשים בתוויות כדי לתמוך באיתור מבוסס-תגים ב-ServiceNow
- ServiceNow Agent Client Collector הוא מנגנון לשליחת נתונים שפועל בפרויקט Google Cloud שלכם ושולח נתוני פלט למופע ServiceNow דרך MID Server, ומאחסן אירועים ומדדים במסד הנתונים הרלוונטי.
- לדוגמאות נוספות של ארכיטקטורות, תרשימים ושיטות מומלצות, עיינו במאמר Cloud Architecture Center.