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

Edge for Private Cloud גרסה 4.18.01

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

הטבלה הבאה מתארת את הקשרים ביניהם:

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

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

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

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

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

אזור	פודקאסטים באזור
"dc-1"	"gateway", "central", "analytics"

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

בתמונה הזו מוצג מאזן העומסים שמפנה את התנועה אל רצף "השער". pod "gateway" מכיל את הרכיבים של Edge Router ו-Messageprocessor שמטפלים בבקשות API. אין צורך ליצור אזורים נוספים, אלא אם מגדירים כמה מרכזי נתונים.

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

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

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

מידע על Pods

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

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

פוד	רכיבי קצה	מאגרי נתונים של Cassandra
"gateway"	נתב, מעבד הודעות	cache-datastore מונה-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 "gateway" נדרשים לעיבוד API. הרכיבים ומאגרי הנתונים האלה צריכים להיות פעילים כדי לעבד בקשות API. הרכיבים ומאגרי הנתונים שנמצאים ברצפי ה-API ה'מרכזי' וב'analytics' לא נדרשים לעיבוד ממשקי ה-API, אלא מוסיפים פונקציונליות ל-Edge.

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

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

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

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

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

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

• gateway
• central
• analytics

לדוגמה, עבור pod "gateway":

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

הפלט מוצג באופן הבא:

[ {
  "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 שרשומים ב-pod. צומתי Cassandra מותקנים ב-podway, אבל מאגרי הנתונים של Cassandra רשומים בכל ה-pods.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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