דרישות התקנה

Edge for Private Cloud גרסה 4.16.05

דרישות החומרה

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

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

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

אלה דרישות החומרה הנדרשות להתקנת API BaaS:

הערה:

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

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

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

יצירת המשתמש ב-apigee

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

ספריית התקנה

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

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

Java

נדרשת גרסה נתמכת של Java1.8 בכל מחשב לפני ההתקנה. אלה גרסאות ה-JDK הנתמכות:

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

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

הגדרת רשת

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

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

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

קסנדרה

כל הצמתים של Cassandra צריכים להיות מחוברים לטבעת.

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

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

• cluster_name
• initial_token
• שותף עריכה
• זרעים
• 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:
   &gt; vi /&lt;inst_root&gt;/apigee/customer/application/postgresql.properties
   
   אם הקובץ לא קיים, יוצרים אותו.
2. מגדירים את המאפיינים המפורטים למעלה.
3. שומרים את השינויים.
4. מפעילים מחדש את מסד הנתונים של PostgreSQL:
   &gt; /<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. אפשר לקבל מידע נוסף.

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.

הערה:

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

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

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

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

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

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

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

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

לדוגמה, בשם של שרת פיזי יחיד 'A' יכולות לפעול שתי מכונות וירטואליות, בשמות 'VM1' ו-'VM2'. נניח ש-VM1 חושפת ממשק Ethernet וירטואלי שנקרא eth0 בתוך המכונה הווירטואלית, ושהמכונה הווירטואלית קיבלה את כתובת ה-IP 111.111.111.111 מהמכונה הווירטואלית או משרת DHCP ברשת. נניח גם ש-VM2 חושפת ממשק Ethernet וירטואלי שנקרא גם eth0, ושהמכונה הווירטואלית קיבלה את כתובת ה-IP 111.111.111.222.

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

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

עם זאת, אם פורסים את ה-API testmycompany עם כתובת ה-URL הבסיסית /salesdemo, לאחר מכן משתמשים יוכלו את ממשק ה-API הזה באמצעות http://api.mycompany.com:80/salesdemo. אם לפרוס את mycompany של API עם כתובת ה-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 בנתב).
• כדי לתמוך בממשק המשתמש של 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:

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

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

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

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

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

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

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

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

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

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

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

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

רישוי

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

מנהל ההתקנה מעתיק את קובץ הרישיון אל /&lt;inst_root&gt;/apigee/customer/conf/license.txt.

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