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

Edge for Private Cloud גרסה 4.17.01

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 של השער כדי לטפל בעומסי תנועה גוברים.

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

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

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

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

• gateway
• מרכז
• analytics

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

http://<routerIP>:<port>/{proxy-base-path}/{resource-name}
https://<routerIP>:<port>/{proxy-base-path}/{resource-name}

where:

• 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.

מידע נוסף זמין בכתובת http://apigee.com/docs/api-services/content/virtual-hosts.

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

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

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

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

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

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

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

http://<router-ip>:9001/{proxy-base-path}/{resource-name}

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

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