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

Edge for Private Cloud גרסה 4.16.09

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

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

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

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

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

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

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

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

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

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

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

מידע על Pods

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

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

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

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

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

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

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

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

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

• שער
• מרכז
• Analytics

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

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

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

ארגון הוא קונטיינר של כל האובייקטים בחשבון 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 על ידי שליחת בקשה אל:

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.

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

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

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

/<inst_root>/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}

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

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