מידע על כוכבי לכת, אזורים, Pods, ארגונים, סביבות ומארחים וירטואליים

Edge for Private Cloud גרסה 4.19.01

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

הטבלה הבאה מתארת את קשרי הגומלין האלה:

רכיב	מכיל	משויך אל	ברירת מחדל
כוכב לכת	אזור אחד או יותר		לא רלוונטי
אזור	קבוצה אחת או יותר		'dc-1'
Pod	רכיב אחד או יותר של Edge		"central" "gateway" "ניתוח נתונים"
ארגון	סביבת אחת או יותר	רצף אחד או יותר שמכיל את מעבדי ההודעות, ומשתמש שפועל כאדמין בארגון	אין
סביבה	מארח וירטואלי אחד או יותר	מעבד הודעות אחד או יותר בקבוצות שמשויכות לארגון ההורה	אין
מארח וירטואלי	כינוי אחד או יותר של מארח		אין

מידע על כוכבי לכת

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

מידע על אזורים

אזור הוא קיבוץ של Pod אחד או יותר. כברירת מחדל, כשמתקינים את Edge, מנהל ההתקנה יוצר אזור יחיד בשם "dc-1" שמכיל שלושה רצפי מודעות, כטבלה הבאה מציג:

אזור	Pods באזור
'dc-1'	'gateway', 'central', 'analytics'

בתמונה הזו מוצגים אזורי ברירת המחדל:

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

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

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

לדוגמה, בתמונה הבאה מוצגים שני אזורים, שתואמים לשני מרכזי נתונים:

מידע על Pods

Pod הוא קיבוץ של רכיב אחד או יותר של Edge ומאגרי נתונים של Cassandra. הקצה רכיבים באותו צומת, אבל הם מותקנים בדרך כלל בצמתים שונים. מאגר נתונים של Cassandra הוא מאגר נתונים שמשמש את רכיבי Edge ב-Pod.

כברירת מחדל, כשמתקינים את Edge, מנהל ההתקנה יוצר שלושה רצפי מודעות ומשייך את רכיבי Edge ומאגרי הנתונים של Cassandra עם כל Pod:

Pod	רכיבי קצה	מאגרי נתונים של קסנדרה
'gateway'	נתב, מעבד הודעות	מטמון-datastore מאגר נתונים מונה dc-datastore	keyvaluemap-datastore kms-datastore
'central'	שרת ניהול, גן חיות, LDAP, ממשק משתמש, Qpid	application-datastore apimodel-datastore audit-datastore auth-datastore	identityzone-datastore edgenotification-datastore management-server scheduler-datastore user-settings-datastore
Analytics	Postgres	analytics-datastore	reportcrud-datastore

רכיבי Edge ומאגרי הנתונים של Cassandra ב"שער" נדרשים pod ל-API בעיבוד. הרכיבים ומאגרי הנתונים האלה צריכים להיות פעילים כדי לעבד בקשות API. וממאגרי הנתונים ב ו-Analytics לא נדרשים Pods לעיבוד ממשקי API, אבל להוסיף פונקציונליות נוספת ל-Edge.

בתמונה הזו מוצגים הרכיבים בכל Pod:

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

שימו לב ש"השער" רצף המודעות מכיל את הרכיבים 'נתב Edge' ו'מעבד הודעות'. נתבים שולחים בקשות רק למעבדי הודעות באותו pod ולא למעבדי הודעות של קבוצות אחרות.

אפשר להשתמש בקריאה הבאה ל-API כדי להציג את פרטי הרישום של השרת בסוף עבור כל קבוצה. זהו כלי שימושי למעקב.

curl -u adminEmail:pword http://ms_IP:8080/v1/servers?pod=podName

כאשר ms_IP הוא כתובת ה-IP או שם ה-DNS של שרת הניהול, ו-podName הוא אחד מהבאים:

• gateway
• central
• analytics

לדוגמה, בשביל "השער" צוות:

curl -u adminEmail:pword http://ms_IP:8080/v1/servers?pod=gateway

Apigee מחזירה פלט שדומה לזה:

[ {
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1101"
    }, ... ]
  },
  "type" : [ "message-processor" ],
  "uUID" : "276bc250-7dd0-46a5-a583-fd11eba786f8"
}, 
{
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ ]
  },
  "type" : [ "dc-datastore", "management-server", "cache-datastore", "keyvaluemap-datastore", "counter-datastore", "kms-datastore" ],
  "uUID" : "13cee956-d3a7-4577-8f0f-1694564179e4"
},
{
  "externalHostName" : "localhost",
  "externalIP" : "192.168.1.11",
  "internalHostName" : "localhost",
  "internalIP" : "192.168.1.11",
  "isUp" : true,
  "pod" : "gateway",
  "reachable" : true,
  "region" : "dc-1",
  "tags" : {
    "property" : [ {
      "name" : "jmx.rmi.port",
      "value" : "1100"
    }, ... ]
  },
  "type" : [ "router" ],
  "uUID" : "de8a0200-e405-43a3-a5f9-eabafdd990e2"
} ]

המאפיין type מפרט את סוג הרכיב. שימו לב שמצוינת שם קסנדרה. מאגרי הנתונים שרשומים בקבוצה. למרות שצמתים של Cassandra מותקנים ב"שער" צוות יראו מאגרי נתונים של Cassandra רשומים בכל רצפי ה-Pod.

מידע על ארגונים

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

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

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

ארגון יכול להכיל סביבה אחת או יותר. הליך ההתקנה המוגדר כברירת מחדל עבור Edge תופיע הנחיה ליצור שתי סביבות: "test" ו-'prod'. אבל אפשר ליצור עוד לפי הצורך, כמו 'סביבת Staging', 'ניסויים' וכו'.

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

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

מידע על סביבות

סביבה היא הקשר של ביצוע בזמן ריצה לשרתי proxy ל-API בארגון. צריך לפרוס שרת proxy ל-API בסביבה לפני שאפשר יהיה לגשת אליה. אפשר לפרוס ממשק API שרת proxy לסביבה יחידה או למספר סביבות.

ארגון יכול להכיל כמה סביבות. לדוגמה, אפשר להגדיר מפתח, 'test' ו-'prod' את הסביבה בארגון.

כשיוצרים סביבה, משייכים אותה למעבד הודעות אחד או יותר. אפשר אפשר לחשוב על סביבה כקבוצה בעלת שם של מעבדי הודעות שבהם פועלים שרתי proxy ל-API. הכול יכולים להיות משויכים לאותם מעבדי הודעות או למעבדי הודעות שונים.

כדי ליצור סביבה, מציינים שני פריטי מידע:

1. הארגון שמכיל את הסביבה.
2. מעבדי ההודעות שמטפלים בבקשות לשרת proxy של API אל הסביבה. ההודעות האלה המעבדים חייבים להיות ב-pod שמשויך לארגון ההורה של הסביבה.
   כברירת מחדל, כשיוצרים סביבה, Edge משייך את כל מעבדי ההודעות הזמינים "השער" עם הסביבה. לחלופין, אפשר לציין קבוצת משנה של מעבדי הודעות זמינים, כדי שמעבדי הודעות שונים יטפלו בבקשות בסביבות שונות.

אפשר לשייך מעבד הודעות למספר סביבות. לדוגמה, מכשיר Edge שלך שיש בה שני מעבדי הודעות: A ו-B. לאחר מכן יוצרים שלוש סביבות Organization: "dev", "test" ו-"prod":

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

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

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

מידע על מארחים וירטואליים

מארח וירטואלי מגדיר את היציאה ב-Edge Router שבה נחשף שרת proxy ל-API. ואת כתובת ה-URL שבה אפליקציות משתמשות כדי לגשת לשרת ה-proxy ל-API. כל סביבה חייבת להגדיר לפחות מארח וירטואלי אחד.

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

http://routerIP:port/proxy-base-path/resource-name
https://routerIP:port/proxy-base-path/resource-name

כאשר:

• http או https: אם המארח הווירטואלי מוגדר לפעול תומך ב-TLS/SSL, צריך להשתמש ב-HTTPS. אם המארח הווירטואלי לא תומך ב-TLS/SSL, צריך להשתמש ב-HTTP.
• routerIP:port הוא כתובת ה-IP ומספר היציאה של המארח הווירטואלי.
• proxy-base-path ו-resource-name מוגדרים במהלך היצירה את ה-Proxy ל-API.

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

http://myAPI.myCo.com/proxy-base-path/resource-name
https://myAPI.myCo.com/proxy-base-path/resource-name

בנוסף, עליך ליצור עבור המארח הווירטואלי כינוי מארח שתואם לשם הדומיין של ה-DNS רשומה. מהדוגמה שלמעלה, צריך לציין כינוי מארח של myAPI.myCo.com. אם אין לך רשומת DNS, הגדר את כינוי המארח לכתובת ה-IP של הנתב והיציאה של המארח הווירטואלי, בתור routerIP:port.

למידע נוסף, ראו מידע על מארחים וירטואליים.

יצירת הארגון הראשון שלכם, ומארח וירטואלי

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

/opt/apigee/apigee-service/bin/apigee-service apigee-provision setup-org -f configFile

הפקודה הזו מקבלת קובץ קלט שמגדיר משתמש, ארגון, סביבה מארח וירטואלי.

לדוגמה, יוצרים:

• משתמש לבחירתך כאדמין ארגוני
• ארגון בשם example
• סביבה בארגון בשם prod שמשויכת לכל ההודעות מעבדים ב"שער" צוות
• מארח וירטואלי בסביבה בשם default שמאפשר גישת HTTP ביציאה 9001
• כינוי המארח של המארח הווירטואלי

לאחר הרצת הסקריפט, תוכלו לגשת לממשקי ה-API שלכם באמצעות כתובת URL בתבנית:

http://routerIP:9001/proxy-base-path/resource-name

בהמשך ניתן להוסיף כמה ארגונים, סביבות ומארחים וירטואליים ללא הגבלה.

מידע נוסף זמין במאמר הצטרפות לארגון.