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

Edge for Private Cloud v4.18.05

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

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

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

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

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

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

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

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

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

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

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

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

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

מידע על Pods

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

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

Pod רכיבי Edge

מאגרי נתונים של Cassandra
"gateway" נתב, מעבד בקשות cache-datastore
counter-datastore
dc-datastore 		keyvaluemap-datastore
kms-datastore
"central" שרת ניהול, Zookeeper, ‏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. הרכיבים ומאגרי הנתונים ב-pods של "central" ו-"analytics" לא נדרשים כדי לעבד ממשקי API, אבל הם מוסיפים פונקציונליות ל-Edge.

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

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

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

אתם יכולים להשתמש בקריאה הבאה ל-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

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

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

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

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

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

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

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

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

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

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

ארגון יכול להכיל כמה סביבות. לדוגמה, אפשר להגדיר בארגון סביבות "פיתוח", "בדיקה" ו "ייצור".

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

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

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

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

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

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

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

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

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

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

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