דרישות התקנה

Edge for Private Cloud גרסה 4.16.09

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

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

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

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

אם רוצים להתקין את BaaS ל-API, מפורטות בהמשך דרישות החומרה:

הערה:

• אם מערכת הקבצים ברמה הבסיסית לא גדולה מספיק להתקנה, מומלץ למקם את הנתונים בדיסק גדול יותר.
• אם הותקנה במחשב גרסה ישנה יותר של 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> הוא /opt כברירת מחדל.

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

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

אחרי שמתקינים את Edge לענן פרטי, אפשר לבדוק ש-Cassandra מוגדרת בצורה נכונה באמצעות עיון ב-/&lt;inst_root&gt;/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; וי /&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. אפשר לקבל מידע נוסף.

השבתת IPv6 ב-Google Cloud פלטפורמה ל-RedHat/CentOS 7

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

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

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 חושפת אתרנט וירטואלי eth0, במכונה הווירטואלית, שכתובת ה-IP שהוקצתה לה 111.111.111.111 על ידי הווירטואליזציה מכונות או שרת DHCP ברשת, ואז נניח ש-VM2 חושפת ממשק אתרנט וירטואלי שנקרא 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/.

הדרישות ליציאת קצה

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

בתמונה הזו אפשר לראות את דרישות היציאות לכל רכיב של 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. להפעלה ב-TLS ב-SMTP הוא בדרך כלל 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. מפעילים מחדש את הנתב:
   &gt; /opt/apigee/apigee-service/bin/apigee-service edge-router מחדש

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

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

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

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

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

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

רישוי

כל התקנה של 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 לקבלת פרטי ההעברה.