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

Edge for Private Cloud v4.18.05

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

בטבלה הבאה מתוארים היחסים האלה:

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

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

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

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

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

אזור	Pods באזור
‎"dc-1"‎	"gateway",‏ "central",‏ "analytics"

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

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

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

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

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

מידע על 'פודקאסטים'

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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