דרישות התקנה

Edge for Private Cloud גרסה 4.16.09

דרישות חומרה

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

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

רכיב התקנה

RAM

מעבדים (CPU)

נפח אחסון מינימלי

קסנדרה

16GB

8 ליבות

אחסון מקומי בנפח 250GB עם SSD או HDD מהיר שתומך ב-2,000 IOPS

מעבד/נתב הודעות באותו מחשב

8/16GB

4 ליבות

100GB

Analytics – Postgres/Qpid באותו שרת (לא מומלץ לייצור)

16GB*

8 ליבות*

אחסון ברשת בנפח 500GB עד 1TB**, עדיף עם קצה עורפי SSD, שתומך ב-1,000 IOPS ומעלה*.

Analytics – פוסטים עצמאיים

16GB*

8 ליבות*

אחסון ברשת בנפח 500GB עד 1TB**, רצוי עם קצה עורפי של SSD עם תמיכה ב-1,000 IOPS ומעלה*.

Analytics – Qpid עצמאי

8GB

4 ליבות

30GB - 50GB לאחסון מקומי עם SSD או HDD מהיר

בהתקנות עם קיבולת גדולה מ-250 TPS, מומלץ להשתמש ב-HDD עם אחסון מקומי שתומך ב-1,000 IOPS.

אחר (OpenLDAP, ממשק משתמש, שרת ניהול)

4GB

2 ליבות

60GB

1 שנו את דרישות המערכת של מעבד ההודעות בהתאם לתפוקה:

ההמלצה המינימלית היא 4 ליבות ו-8 ליבות למערכת תפוקה גבוהה. אתם יכולים להריץ בדיקות של ביצועים כדי לקבוע את הגודל האופטימלי של ממשקי ה-API שלכם.

*התאמה של דרישות המערכת של Postgres בהתאם לתפוקה:

  • פחות מ-250 TPS: 8GB, 4 ליבות, שאפשר להשתמש בהם באחסון רשת מנוהל*** עם תמיכה ב-1000 IOPS ומעלה
  • יותר מ-250 TPS: 16GB, אחסון מנוהל ברשת עם 8 ליבות***, תמיכה ב-1,000 IOPS ומעלה
  • יותר מ-1,000 TPS: 16GB, אחסון רשת מנוהל עם 8 ליבות*** תומך ב-2,000 IOPS ומעלה
  • יותר מ-2,000 TPS: 32GB, 16 ליבות, אחסון רשת מנוהל***, עם תמיכה ב-2,000 IOPS ואילך
  • יותר מ-4,000 TPS: 64GB, אחסון רשת מנוהל של 32 ליבות*** שתומך ב-4,000 IOPS ואילך

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

(# בייטים לבקשה) * (בקשות לשנייה) * (10 שניות לשעה) * (שעות של שימוש שיא ביום) * (ימים של שימוש בחודש) * (מספר חודשים של שמירת נתונים) = בייטים של נפח אחסון נדרש

לדוגמה:

(2,000 בייטים לכל בקשה) * 100 30 60 שעות * 30 שעות * 90 שעות * 100 30 שעות * 9 בייטים לשנייה

*** Network Storage מומלץ למסד נתונים Postgresql מהסיבות הבאות:

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

בנוסף, ברשימה הבאה מפורטות דרישות החומרה אם ברצונך להתקין את שירותי המונטיזציה:

רכיב בהפעלת מונטיזציה

RAM

מעבדים (CPU)

דיסק קשיח

שרת ניהול (עם שירותי מונטיזציה)

8GB

4 ליבות

60GB

Analytics - Postgres/Qpid באותו שרת

16GB

8 ליבות

אחסון ברשת בנפח 500GB – 1TB, עדיף עם קצה עורפי SSD, שתומך ב-1,000 IOPS או יותר, או שאפשר להשתמש בכלל שמפורט בטבלה שלמעלה.

Analytics – פוסטים עצמאיים

16GB

8 ליבות

אחסון ברשת בנפח 500GB – 1TB, עדיף עם קצה עורפי SSD, שתומך ב-1,000 IOPS או יותר, או שאפשר להשתמש בכלל שמפורט בטבלה שלמעלה.

Analytics – Qpid עצמאי

8GB

4 ליבות

40GB

ברשימה הבאה מפורטות הדרישות לחומרה כדי להתקין BaaS של API:

רכיב BaaS ל-API

RAM

מעבדים (CPU)

דיסק קשיח

ElasticSearch*

8GB

4 ליבות

60 - 80GB

מחסנית BaaS של API *

8GB

4 ליבות

60 - 80GB

פורטל BaaS ל-API

בנפח1GB

2 ליבות

20GB

Cassandra (אופציונלי – בדרך כלל משתמשים באותו אשכול Cassandra גם לשירותי Edge וגם לשירותי BaaS של API)

16GB

8 ליבות

אחסון מקומי בנפח 250GB עם SSD או HDD מהיר שתומך ב-2,000 IOPS

* אפשר להתקין את ElasticSearch ו-API BaaS Stack באותו צומת. אם כן, צריך להגדיר את ElasticSearch לשימוש בנפח של 4GB בזיכרון (ברירת המחדל). אם ElasticSearch מותקן בצומת משלו, הגדירי אותו לשימוש ב-6GB בזיכרון.

הערה:

  • אם מערכת הקבצים ברמה הבסיסית (root) לא גדולה מספיק לצורך ההתקנה, מומלץ למקם את הנתונים בכונן גדול יותר.
  • אם הותקנה במחשב גרסה ישנה יותר של Apigee Edge לענן פרטי, חשוב למחוק את התיקייה /tmp/java לפני התקנה חדשה.
  • לתיקייה הזמנית /tmp ברמת המערכת נדרשות הרשאות הפעלה כדי להפעיל את Cassandra.
  • אם המשתמש "apigee" נוצר לפני ההתקנה, צריך לוודא שה-"/home/apigee" קיים בספריית הבית והוא נמצא בבעלות "apigee:apigee".

דרישות מערכת הפעלה ותוכנה של צד שלישי

הוראות התקנה אלה וקובצי ההתקנה שסופקו נבדקו במערכות ההפעלה ובתוכנות הצד השלישי הרשומות כאן: https://apigee.com/docs/api-services/reference/supported-software.

יצירת המשתמש בממשק API

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

ספריית התקנה

כברירת מחדל, מנהל ההתקנה כותב את כל הקבצים בספרייה /opt/apigee. לא ניתן לשנות את מיקום הספרייה.

בהוראות במדריך הזה, ספריית ההתקנה מצוינת בתור /<inst_root>/apigee, כאשר /<inst_root> הוא /opt כברירת מחדל.

Java

לפני ההתקנה, צריכה להיות מותקנת גרסה נתמכת של Java1.8 בכל מחשב. מפתחות JDK נתמכים מפורטים כאן:

https://apigee.com/docs/api-services/reference/supported-software

מוודאים ש-JAVA_HOME מפנה לשורש של ה-JDK אצל המשתמש שמבצע את ההתקנה.

הגדרת רשת

מומלץ לבדוק את הגדרות הרשת לפני ההתקנה. המתקין מצפה שלכל המכונות יש כתובות IP קבועות. כדי לבדוק את ההגדרה, יש להשתמש בפקודות הבאות:

  • hostname מחזיר את שם המכונה
  • hostname -i מחזיר את כתובת ה-IP של שם המארח שניתן לכתובת ממכונות אחרות.

בהתאם לסוג ולגרסה של מערכת ההפעלה שלך, ייתכן שיהיה עליך לערוך את /etc/hosts ואת /etc/sysconfig/network אם שם המארח לא מוגדר כהלכה. למידע נוסף, עיינו בתיעוד של מערכת ההפעלה הספציפית שלכם.

קסנדרה

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

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

אחרי שמתקינים את Edge for Private Cloud, אפשר לבדוק אם Cassandra מוגדרת בצורה נכונה, על ידי בדיקה של הקובץ /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml. לדוגמה, צריך לוודא שהסקריפט להתקנה של Edge לענן הפרטי מגדיר את המאפיינים הבאים:

  • cluster_name
  • initial_token
  • מחיצות (partitioner)
  • זרעים
  • listen_address
  • rpc_address
  • snitch

אזהרה: אין לערוך את הקובץ הזה.

מסד נתונים PostgreSQL

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

conf_postgresql_shared_buffers = 35% of RAM      # min 128kB
conf_postgresql_effective_cache_size = 45% of RAM
conf_postgresql_work_mem = 512MB       # min 64kB

כדי להגדיר את הערכים האלה:

  1. עריכה של postgresql.properties:
    > vi /<inst_root>/apigee/customer/application/postgresql.properties

    אם הקובץ לא קיים, יוצרים אותו.
  2. מגדירים את המאפיינים שמפורטים למעלה.
  3. שומרים את השינויים.
  4. מפעילים מחדש את מסד הנתונים PostgreSQL:
    > /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql הפעלה מחדש

jsvc

'jsvc' הוא דרישה מוקדמת לשימוש ב-API BaaS. גרסה 1.0.15-dev מותקנת כאשר מתקינים את ה-BaaS של ה-API.

שירותי אבטחת רשת (NSS)

Network Security Services (NSS) היא קבוצת ספריות שתומכת בפיתוח של אפליקציות לקוח ושרת שמופעלות על ידי אבטחה. עליך לוודא שהתקנת את NSS את גרסה 3.19 ואילך.

כדי לבדוק את הגרסה הנוכחית:

> yum info nss

כדי לעדכן את ה-NSS:

> yum update nss

מידע נוסף זמין במאמר הזה מ-RedHat.

השבתה של IPv6 ב-Google Cloud Platform ל-RedHat/CentOS 7

אם מתקינים את Edge ב-RedHat 7 או את CentOS 7 ב-Google Cloud Platform, צריך להשבית את IPv6 בכל צומתי Qpid.

לקבלת הוראות להשבתת IPv6, אפשר לעיין בתיעוד של RedHat או CentOS לגבי הגרסה הספציפית של מערכת ההפעלה.

AWS AMI

אם אתם מתקינים Edge ב-AWS Amazon Machine Image (AMI) עבור Red Hat Enterprise Linux 7.x, צריך קודם להריץ את הפקודה הבאה:

> yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

כלים

מנהל ההתקנה משתמש בכלי UNIX הבאים בגרסה הרגילה, כפי שסופק על ידי EL5 או EL6.

awk

dirname

ls

RPM

unzip

basename

echo

perl

rpm2cpio

הוספת משתמש

באש

expr

PgRep (מ-Procps)

sed

wc

bc

grep

ps

זפת

טעים

curl

hostname

pwd

tr

chkconfig

date

id

python

Uname

sudo

הערה:

  • קובץ ההפעלה של הכלי 'useradd' נמצא ב-/usr/sbin וב-chkconfig ב-/sbin.
  • באמצעות גישת sudo אפשר לקבל גישה בסביבה של המשתמש המבצע את השיחה. לדוגמה, לקרוא בדרך כלל לפקודה "sudo <command>" או "sudo Path=$Path:/usr/sbin:/sbin <command>".
  • יש לוודא שהכלי "patch" מותקן לפני ההתקנה של חבילת שירות (תיקון).

ntpdate – מומלץ לסנכרן את זמן השרתים. אם תוכנת העזר 'ntpdate' לא מוגדרת כבר, היא יכולה לשמש כדי לאמת אם השרתים מסונכרנים בזמן. אפשר להשתמש ב-yum install ntp כדי להתקין את כלי השירות. האפשרות הזו שימושית במיוחד לשכפול הגדרות OpenLDAP. שימו לב שהגדרתם את אזור הזמן של השרת לפי שעון UTC.

openldap 2.4 – ההתקנה המקומית מחייבת OpenLDAP 2.4. אם לשרת יש חיבור לאינטרנט, סקריפט ההתקנה של Edge יוריד ויתקין את OpenLDAP. אם לשרת שלך אין חיבור לאינטרנט, עליך לוודא ש-OpenLDAP כבר מותקן לפני הפעלת הסקריפט להתקנת Edge. ב-RHEL/CentOS, אפשר להריץ את "yum install openldap-clients openldap-servers" כדי להתקין את OpenLDAP.

להתקנות עם 13 מארחים ולהתקנות של 12 מארחים עם שני מרכזי נתונים, צריך שכפול של OpenLDAP כי יש צמתים מרובים שמארחים את OpenLDAP.

חומות אש ומארחים וירטואליים

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

  • מכונות וירטואליות (VM): לא חובה לעשות זאת, אבל בחלק מהפריסות נעשה שימוש בטכנולוגיית מכונות וירטואליות כדי ליצור שרתים מבודדים לרכיבי Apigee שלהם. למארחי מכונות וירטואליות, כמו מארחים פיזיים, יכולים להיות ממשקי רשת וחומות אש. הוראות ההתקנה האלה לא תומכות באופן ספציפי בהתקנות של מכונות וירטואליות.
  • מארחים וירטואליים: נקודות קצה באינטרנט, בדומה למארח וירטואלי של Apache.

נתב במכונה וירטואלית יכול לחשוף כמה מארחים וירטואליים (כל עוד הם שונים זה מזה בכינוי המארח או ביציאת הממשק שלו).

דוגמה למתן שמות: בשרת פיזי יחיד 'A' אפשר להפעיל שתי מכונות וירטואליות, שנקראות VM1 ו-VM2. נניח ש-VM1 חושפת ממשק Ethernet וירטואלי שנקרא eth0 בתוך המכונה הווירטואלית, ומוקצית לו כתובת IP 111.111.111.111 על ידי מכונה וירטואלית 1.111.111. לאחר מכן מוקצית כתובת IP1, ולאחר מכן מכונה Ethernet2, ולאחר מכן מוקצית כתובת IP1. לאחר מכן מכונה Ethernet2 או רשת IP1. לאחר מכן מוקצית כתובת IP1. לאחר מכן היא חושפת את ממשק Ethernet1 שנקרא eth0 בתוך המכונה הווירטואלית.

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

נתב Apigee ב-VM1 חושף שלושה מארחים וירטואליים בממשק ה-eth0 שלו (יש לו כתובת IP מסוימת), api.mycompany.com:80, api.mycompany.com:443 ו-test.mycompany.com:80.

הנתב ב-VM2 חושף את api.mycompany.com:80 (שם ויציאה זהים כפי שנחשפו על ידי VM1).

יכול להיות שבמערכת ההפעלה של המארח הפיזי יש חומת אש של רשת. במקרה כזה, צריך להגדיר את חומת האש הזו להעברת תעבורת הנתונים של TCP המחויבת ליציאות הנחשפות בממשקים הווירטואליים ( 111.111.111.111:{80, 443} ו-111.111.111.222:80). בנוסף, כל מערכת הפעלה של כל מכונה וירטואלית עשויה לספק חומת אש משלה בממשק ה-eth0, וגם המערכות האלה צריכות לאפשר ליציאות 80 ו-443 להתחבר.

נתיב הבסיס הוא הרכיב השלישי שמעורב בניתוב קריאות ל-API לשרתי proxy שונים של API שאולי פרסת. חבילות proxy של API יכולות לשתף נקודת קצה אם יש להן נתיב בסיס שונה. לדוגמה, נתיב בסיסי אחד יכול להיות מוגדר כ-http://api.mycompany.com:80/ ונתיב בסיסי אחר כ-http://api.mycompany.com:80/salesdemo.

במקרה כזה, יש צורך במאזן עומסים או במנהל תעבורת נתונים מסוג כלשהו שמפצל את תעבורת הנתונים http://api.mycompany.com:80/ בין שתי כתובות ה-IP (111.111.111.111 ב-VM1 ו-111.111.111.222 ב-VM2). הפונקציה הזו היא ספציפית להתקנה הספציפית שלכם, והיא מוגדרת על ידי קבוצת הרשת המקומית.

נתיב הבסיס מוגדר בזמן פריסת ה-API. מהדוגמה שלמעלה, אפשר לפרוס שני ממשקי API, mycompany ו-testmycompany, עבור הארגון mycompany-org, עם המארח הווירטואלי שבו כינוי המארח של api.mycompany.com והיציאה מוגדרת כ-80. אם לא מצהירים על נתיב בסיס בפריסה, הנתב לא יידע לאיזה API לשלוח בקשות נכנסות.

עם זאת, אם תטמיעו את ה-API testmycompany עם כתובת ה-URL הבסיסית של /salesdemo, המשתמשים ייגשו ל-API הזה באמצעות http://api.mycompany.com:80/salesdemo. אם בחרת לפרוס את ה-API mycompany עם כתובת ה-URL הבסיסית של /, המשתמשים ייגשו ל-API לפי כתובת ה-URL http://api.mycompany.com:80/.

הדרישות לגבי יציאת Edge

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

בתמונה הבאה אפשר לראות את דרישות היציאות לכל רכיב Edge:

הערות בתרשים הזה:

  • *יציאה 8082 במעבד ההודעות צריכה להיות פתוחה לגישה מהנתב רק כאשר מגדירים TLS/SSL בין הנתב למעבד ההודעות. אם לא מגדירים TLS/SSL בין הנתב למעבד ההודעות, הגדרת ברירת המחדל, יציאה 8082 עדיין צריכה להיות פתוחה במעבד ההודעות כדי לנהל את הרכיב, אבל הנתב לא מחייב גישה אליו.
  • היציאות עם הקידומת M הן יציאות המשמשות לניהול הרכיב. היציאות חייבות להיות פתוחות ברכיב וצריכות להיות פתוחות ברכיב כדי לאפשר גישה של שרת הניהול.
  • הרכיבים הבאים דורשים גישה ליציאה 8080 בשרת הניהול: נתב, מעבד הודעות, ממשק משתמש, Postgres ו-Qpid.
  • מעבד הודעות חייב לפתוח את יציאה 4528 כיציאת הניהול שלו. אם יש לך כמה מעבדי הודעות, כולם צריכים להיות מסוגלים לגשת זה לזה ביציאה 4528 (אם יש לך חץ הלולאה שמופיע בתרשים שלמעלה לגבי יציאה 4528 במעבד ההודעות). אם יש לך מספר מרכזי נתונים, היציאה צריכה להיות נגישה מכל מעבדי ההודעות בכל מרכזי הנתונים.
  • למרות שזו לא חובה, אפשר לפתוח את יציאה 4527 בנתב כדי לקבל גישה לכל מעבד הודעות. אחרת, ייתכן שיופיעו הודעות שגיאה בקובצי היומן של מעבד ההודעות.
  • נתב חייב לפתוח את יציאה 4527 כיציאת הניהול שלו. אם יש לך כמה נתבים, לכולם צריכה להיות גישה זה לזה דרך יציאה 4527 (הדבר יצוין באמצעות חץ הלולאה בתרשים שלמעלה לגבי יציאה 4527 בנתב).
  • כדי לתמוך בלחצן Send בכלי המעקב, בממשק המשתמש של Edge נדרשת גישה לנתב, ביציאות החשופות של שרתי ה-proxy של ה-API.
  • שרת הניהול מחייב גישה ליציאת JMX בצומתי Cassandra.
  • אפשר להגדיר את הגישה ליציאות JMX כך שתדרוש שם משתמש/סיסמה. מידע נוסף זמין במאמר איך עוקבים.
  • אפשר להגדיר גישה ל-TLS/SSL בחיבורים מסוימים, שיכולים להשתמש ביציאות שונות. אפשר לקרוא מידע נוסף בקטע TLS/SSL.
  • אם מגדירים שני צומתי Postgres לשימוש בשכפול של מצב המתנה ראשית, צריך לפתוח את יציאה 22 בכל צומת לגישת SSH. אפשר לפתוח יציאות בצמתים נפרדים כדי לאפשר גישת SSH.
  • אפשר להגדיר את שרת הניהול ואת ממשק המשתמש של Edge לשליחת אימיילים דרך שרת SMTP חיצוני. צריך לוודא ששרת הניהול וממשק המשתמש יכולים לגשת ליציאה הדרושה בשרת ה-SMTP. ב-SMTP שאינו TLS, מספר היציאה הוא בדרך כלל 25. ב-SMTP שמופעל בו TLS, בדרך כלל הוא 465, אבל יש לבדוק זאת עם ספק ה-SMTP.

בטבלה הבאה אפשר לראות שצריך לפתוח את היציאות בחומות אש באמצעות רכיב Edge:

רכיב

יציאה

תיאור

יציאות HTTP רגילות

80, 443

HTTP ועוד יציאות אחרות שבהן השתמשת למארחים וירטואליים

שרת ניהול

8080

יציאה לקריאות ל-Edge Management API. לרכיבים האלה נדרשת גישה ליציאה 8080 בשרת הניהול: נתב, מעבד הודעות, ממשק משתמש, Postgres ו-Qpid.

1099

יציאת JMX

4526

עבור שיחות ניהול ומטמון מבוזרות

ממשק משתמש לניהול

9000

יציאה לגישה של דפדפן לממשק המשתמש לניהול

מעבד הודעות

8998

יציאה של מעבד ההודעות לתקשורת מהנתב

8082

יציאת הניהול המוגדרת כברירת מחדל למעבד ההודעות חייבת להיות פתוחה ברכיב כדי לאפשר גישה של שרת הניהול.

כאשר מגדירים TLS או SSL בין הנתב למעבד ההודעות, והנתב משמש את הנתב לביצוע בדיקות תקינות של מעבד ההודעות.

1101

יציאת JMX

4528

עבור מטמון מבוזר ושיחות ניהול בין מעבדי הודעות, ועבור תקשורת מהנתב

נתב

8081

יציאת הניהול של הנתב המוגדרת כברירת מחדל, חייבת להיות פתוחה ברכיב כדי לאפשר גישה של שרת הניהול.

4527

עבור שיחות ניהול ומטמון מבוזרות

15999

יציאה של בדיקת תקינות. מאזן עומסים משתמש ביציאה הזו כדי לקבוע אם הנתב זמין.

כדי לבדוק את הסטטוס של הנתב, מאזן העומסים שולח בקשה ליציאה 15999 בנתב:

> curl -v http://<routerIP>:15999/v1/servers/self/reachable

אם ניתן להגיע אל הנתב, הבקשה מחזירה HTTP 200.

ZooKeeper

2181

בשימוש על ידי רכיבים אחרים, כמו 'שרת ניהול', 'נתב', 'מעבד הודעות' וכו'

2888, 3888

משמש באופן פנימי על ידי NaturalKeeper לצורך תקשורת באשכול גן החיות (ZooKeeper)

קסנדרה

7000, 9042, 9160

יציאות Apache Cassandra לתקשורת בין צומתי Cassandra ולגישה לרכיבי Edge אחרים.

7199

יציאת JMX. חייב להיות פתוח לגישה של שרת הניהול.

QPID

5672

משמש לתקשורת מהנתב וממעבד ההודעות לשרת Qpid

8083

יציאת הניהול המוגדרת כברירת מחדל בשרת Qpid חייבת להיות פתוחה ברכיב כדי לאפשר גישה של שרת הניהול.

1102

יציאת JMX

4529

עבור שיחות ניהול ומטמון מבוזרות

Postgres

5432

משמש לתקשורת מ-Qpid/Management Server ל-Postgres

8084

יציאת הניהול המוגדרת כברירת מחדל בשרת Postgres חייבת להיות פתוחה ברכיב כדי לאפשר גישה של שרת הניהול.

1103

יציאת JMX

4530

עבור שיחות ניהול ומטמון מבוזרות

22

אם מגדירים שני צומתי Postgres לשימוש בשכפול של מצב המתנה ראשית, צריך לפתוח את יציאה 22 בכל צומת לגישת SSH.

LDAP

10389

OpenLDAP

SmartDocs

59002

היציאה בנתב Edge שאליה נשלחות הבקשות לדפי SmartDocs.

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

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

מספר יציאה

מטרה

רכיב מקור

רכיב יעד

<virtual Host#>

HTTP בנוסף לכל יציאות אחרות שבהן אתה משתמש לתנועת קריאות ל-API של מארח וירטואלי. יציאות 80 ו-443 הן הנפוצות ביותר. נתב ההודעות יכול לסיים חיבורי TLS/SSL.

לקוח חיצוני (או מאזן עומסים)

האזנה בנתב ההודעות

1099 עד 1103

ניהול JMX

לקוח JMX

Management Server (1099)

מעבד הודעות (1101)

Qpid Server (1102)

Postgres Server (1103)

2181

תקשורת עם לקוח של שמוצגים בגן החיות

שרת ניהול

נתב

מעבד בקשות

שרת Qpid

שרת Postgres

מטפל בגן חיות

2888 ו-3888

ניהול מוקדים פנימיים של חיות מחמד

מטפל בגן חיות

מטפל בגן חיות

4526 עד 4530

יציאות לניהול RPC המשמשות למטמון מבוזר ולקריאות משרתי הניהול לרכיבים אחרים

שרת ניהול

Management Server (4526)

נתב (4527)

מעבד הודעות (4528)

Qpid Server (4529)

Postgres Server (4530)

4,528

לקריאות מבוזרות של מטמון בין מעבדי הודעות ולתקשורת מהנתב

נתב

מעבד בקשות

מעבד בקשות

5,432

לקוח Postgres

שרת Qpid

Postgres

5,672

משמש לשליחת ניתוח נתונים מהנתב וממעבד ההודעות אל Qpid

נתב

מעבד בקשות

שרת Qpid

7000

תקשורת בין צמתים של Cassandra

קסנדרה

צומת אחר של Cassandra

7,199

ניהול JMX. חייב להיות פתוח לגישה בצומת Cassandra של שרת הניהול.

לקוח JMX

קסנדרה

8080

יציאת ממשק API לניהול

לקוחות של ממשק API לניהול

שרת ניהול

8081 עד 8084

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

לקוחות של ממשק API לניהול

Router (8081)

מעבד הודעות (8082)

Qpid Server (8083)

Postgres Server (8084)

8,998

התקשורת בין נתב למעבד הודעות

נתב

מעבד בקשות

9,000

יציאת ברירת המחדל של ממשק המשתמש לניהול Edge

דפדפן

שרת ניהול ממשק המשתמש

9042

העברה מקומית של CQL

נתב

מעבד בקשות

שרת ניהול

קסנדרה

9160

לקוח יקר ל-Kassandra

נתב

מעבד בקשות

שרת ניהול

קסנדרה

10389

יציאת LDAP

שרת ניהול

OpenLDAP

15,999

יציאה של בדיקת תקינות. מאזן עומסים משתמש ביציאה הזו כדי לקבוע אם הנתב זמין.

מאזן עומסים נתב

59002

יציאת הנתב שאליה נשלחות הבקשות לדפי SmartDocs

SmartDocs

נתב

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

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

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

  1. מגדירים את net.ipv4.tcp_keepalive_time = 1800 בהגדרות ה-sysctl במערכת ההפעלה של Linux, כאשר הערך של 1800 צריך להיות נמוך יותר מהזמן הקצוב לתפוגה של tcp בחומת האש. ההגדרה הזו אמורה להשאיר את החיבור במצב קיים, כדי שחומת האש לא תנתק את החיבור.
  2. בכל מעבדים ההודעות, עורכים את /<inst_root>/apigee/customer/application/message-processor.properties כדי להוסיף את המאפיין הבא. אם הקובץ לא קיים, יוצרים אותו.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  3. מפעילים מחדש את מעבד ההודעות:
    > /opt/apigee/apigee-service/bin/apigee-service edge-message-processor מחדש
  4. בכל הנתבים, עורכים את /<inst_root>/apigee/customer/application/router.properties כדי להוסיף את הנכס הבא. אם הקובץ לא קיים, יוצרים אותו.
    conf_system_casssandra.maxconnecttimeinmillis=-1
  5. מפעילים מחדש את הנתב:
    > /opt/apigee/apigee-service/bin/apigee-service edge-router מחדש

אם מתקינים את התצורה של 12 מארחים באשכולות עם שני מרכזי נתונים, צריך לוודא שהצמתים בשני מרכזי הנתונים יכולים לתקשר דרך היציאות שמוצגות למטה:

הדרישות ליציאת BaaS ל-API

אם תבחרו להתקין את ממשקי BaaS של ה-API, תצטרכו להוסיף את הרכיבים של Stack BaaS Stack ו-API BaaS Portal. הרכיבים האלה משתמשים ביציאות שמוצגות באיור למטה:

הערות בתרשים הזה:

  • פורטל BaaS של ה-API לעולם לא שולח בקשות ישירות לצומת ב-BaaS Stack. כשמפתח מתחבר לפורטל, אפליקציית הפורטל יורדת לדפדפן. אפליקציית הפורטל שפועלת בדפדפן שולחת בקשות לצומתי BaaS Stack.
  • במהלך התקנה של API BaaS בסביבת ייצור, נעשה שימוש במאזן עומסים בין הצומת של פורטל BaaS של ה-API לבין הצמתים של Stack BaaS ב-API. כשמגדירים את הפורטל, וכשמבצעים קריאות ל-BaaS API, צריך לציין את כתובת ה-IP או את שם ה-DNS של מאזן העומסים, ולא של צומתי ה-Stack.
  • צריך להגדיר את כל צומתי Baas Stack לשליחת אימיילים דרך שרת SMTP חיצוני. ב-SMTP שאינו TLS, מספר היציאה הוא בדרך כלל 25. ב-SMTP שמופעל בו TLS, בדרך כלל הוא 465, אבל יש לבדוק זאת עם ספק ה-SMTP.
  • אפשר להקצות את צומתי Cassandra ל-API BaaS, או לשתף אותם עם Edge.

בטבלה הבאה מוצגות יציאות ברירת המחדל שיש לפתוח בחומות אש, לפי רכיב:

רכיב

יציאה

תיאור

פורטל API BaaS

9000

יציאה לממשק המשתמש BaaS של ה-API

מקבץ של ממשקי BaaS של API

8080

היציאה שבה מתקבלת בקשת API

ElasticSearch

9200 עד 9400

לתקשורת עם מקבץ BaaS של API ולתקשורת בין צומתי ElasticSearch

רישוי

לכל התקנה של Edge נדרש קובץ רישיון ייחודי שמקבלים מ-Apigee. כשמתקינים את שרת הניהול, צריך לספק את הנתיב לקובץ הרישיון, לדוגמה /tmp/License.txt.

המתקין מעתיק את קובץ הרישיון ל-/<inst_root>/apigee/customer/conf/license.txt.

אם קובץ הרישיון תקף, שרת הניהול מאמת את תפוגת התוקף ומתיר את הספירה של מעבדי ההודעות (MP). אם פג התוקף של הגדרה כלשהי של הרישיון, תוכלו למצוא את היומנים במיקום הבא: /<inst_root>/apigee/var/log/edge-management-server/logs. במקרה כזה, אפשר לפנות לתמיכה של Apigee כדי לקבל את פרטי ההעברה.