متطلبات التثبيت

Edge for Private Cloud الإصدار 4.16.05

متطلبات الأجهزة

يجب استيفاء الحدّ الأدنى من متطلبات الأجهزة التالية للحصول على بنية أساسية عالية التوفّر في بيئة على مستوى الإنتاج. بالنسبة إلى جميع سيناريوهات التثبيت الموضّحة في مخططات التثبيت، تسرد الجداول التالية الحد الأدنى لمتطلبات الأجهزة لمكونات التثبيت.

في هذه الجداول، تُضاف متطلبات القرص الصلب إلى مساحة القرص الصلب التي يتطلبها نظام التشغيل. بناءً على تطبيقاتك وحركة بيانات الشبكة، قد يتطلّب التثبيت موارد أكثر أو أقل من الموارد المدرَجة أدناه.

بالإضافة إلى ذلك، في ما يلي متطلبات الأجهزة إذا أردت تثبيت "خدمات تحقيق الربح":

في ما يلي متطلبات الأجهزة إذا أردت تثبيت API BaaS:

ملاحظة:

• إذا لم يكن نظام الملفات الجذر كبيرًا بما يكفي للتثبيت، ننصحك بوضع البيانات على قرص أكبر.
• في حال تثبيت إصدار قديم من Apigee Edge for Private Cloud على الجهاز، تأكَّد من حذف المجلد ‎/tmp/java قبل إجراء عملية تثبيت جديدة.
• يحتاج المجلد المؤقت على مستوى النظام /tmp إلى أذونات تنفيذ من أجل بدء Cassandra.
• إذا تم إنشاء المستخدم "apigee" قبل التثبيت، تأكَّد من أنّ "/home/apigee" متوفّر كدليل رئيسي وأنّه مملوك من قِبل "apigee:apigee".

متطلبات نظام التشغيل والبرامج الخارجية

تم اختبار تعليمات التثبيت هذه وملفات التثبيت المرفقة على أنظمة التشغيل والبرامج الخارجية المدرَجة هنا: https://apigee.com/docs/api-services/reference/supported-software.

جارٍ إنشاء مستخدم Apigee

تنشئ عملية التثبيت مستخدمًا لنظام Unix باسم "apigee". وتكون أدلة وملفات Edge مملوكة لـ "apigee"، وكذلك عمليات Edge. يعني ذلك أنّ مكوّنات Edge تعمل كمستخدم "apigee". ويمكنك تشغيل المكوّنات كمستخدم مختلف إذا لزم الأمر. يمكنك الاطّلاع على "ربط جهاز التوجيه بمنفذ محمي" في تثبيت مكوّنات Edge على عقدة للحصول على مثال.

دليل التثبيت

تكتب أداة التثبيت تلقائيًا جميع الملفات في الدليل /opt/apigee. ولا يمكنك تغيير موقع هذا الدليل.

في التعليمات الواردة في هذا الدليل، يُشار إلى دليل التثبيت باسم /<inst_root>/apigee، حيث يكون /<inst_root> هو /opt تلقائيًا.

جافا

يجب تثبيت إصدار متوافق من 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 بحلقة.

يضبط Cassandra حجم كومة Java تلقائيًا استنادًا إلى الذاكرة المتاحة. لمزيد من المعلومات، يُرجى الاطّلاع على ضبط موارد Java. في حال انخفاض الأداء أو ارتفاع استهلاك الذاكرة

بعد تثبيت Edge for Private Cloud، يمكنك التحقّق من ضبط Cassandra بشكل صحيح من خلال فحص ملف /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml. على سبيل المثال، تأكَّد من أنّ النص البرمجي لتثبيت Edge for Private Cloud يضبط السمات التالية:

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

jsvc

"jsvc" هو شرط أساسي لاستخدام API BaaS. يتم تثبيت الإصدار 1.0.15-dev عند تثبيت API BaaS.

خدمات أمان الشبكة (NSS)

&quot;خدمات أمان الشبكة&quot; (NSS) هي مجموعة من المكتبات التي تتيح تطوير تطبيقات العميل والخادم المزوّدة بميزات الأمان. يجب التأكّد من تثبيت الإصدار 3.19 من NSS أو إصدار أحدث.

للتحقّق من الإصدار الحالي:

> yum info nss

لتحديث NSS:

> yum update nss

لمزيد من المعلومات، يُرجى الاطّلاع على هذه المقالة من RedHat.

AWS AMI

إذا كنت بصدد تثبيت Edge على صورة جهاز Amazon Machine Image (AMI) في AWS لنظام التشغيل 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" لتثبيت الأداة المساعدة. ويُعدّ ذلك مفيدًا بشكل خاص لتكرار إعدادات OpenLDAP. يُرجى العِلم أنّه يتم ضبط المنطقة الزمنية للخادم على التوقيت العالمي المتفق عليه (UTC).

‫openldap 2.4: يتطلّب التثبيت داخل المؤسسة الإصدار 2.4 من OpenLDAP. إذا كان الخادم متصلاً بالإنترنت، سيتم تنزيل وتثبيت OpenLDAP من خلال نص Edge البرمجي للتثبيت. إذا لم يكن الخادم متصلاً بالإنترنت، عليك التأكّد من أنّ OpenLDAP مثبَّت قبل تشغيل نص Edge البرمجي للتثبيت. على نظام التشغيل RHEL/CentOS، يمكنك تشغيل "yum install openldap-clients openldap-servers" لتثبيت OpenLDAP.

بالنسبة إلى عمليات التثبيت التي تتضمّن 13 مضيفًا وعمليات التثبيت التي تتضمّن 12 مضيفًا مع مركزَي بيانات، عليك استخدام النسخ المتماثل لـ OpenLDAP لأنّ هناك عُقدًا متعددة تستضيف OpenLDAP.

جدران الحماية والأجهزة المضيفة الظاهرية

يتم استخدام المصطلح "افتراضي" بشكل مفرط في مجال تكنولوجيا المعلومات، وينطبق ذلك على عمليات نشر Apigee Edge for Private Cloud والمضيفين الافتراضيين. للتوضيح، هناك استخدامان أساسيان لمصطلح "افتراضي":

• الأجهزة الافتراضية (VM): ليست مطلوبة، ولكن تستخدم بعض عمليات النشر تكنولوجيا الأجهزة الافتراضية لإنشاء خوادم معزولة لمكوّنات Apigee. يمكن أن تحتوي مضيفات الأجهزة الافتراضية، مثل المضيفات الفعلية، على واجهات شبكة وجدران حماية. لا تتيح تعليمات التثبيت هذه تحديدًا عمليات تثبيت الأجهزة الافتراضية.
• المضيفون الافتراضيون: نقاط نهاية الويب، مثل المضيف الافتراضي Apache

يمكن لجهاز توجيه في جهاز افتراضي عرض عدة مضيفين افتراضيين (طالما أنّهم يختلفون عن بعضهم البعض في الاسم المستعار للمضيف أو في منفذ الواجهة).

على سبيل المثال، قد يشغّل خادم فعلي واحد "أ" جهازَين افتراضيَين باسم "VM1" و"VM2". لنفترض أنّ VM1 يعرض واجهة إيثرنت افتراضية باسم eth0 داخل الجهاز الافتراضي، ويتم تخصيص عنوان IP‏ 111.111.111.111 لها من خلال جهاز المحاكاة الافتراضية أو خادم بروتوكول الإعداد الديناميكي للمضيف (DHCP) على الشبكة. لنفترض بعد ذلك أنّ VM2 يعرض واجهة إيثرنت افتراضية باسم eth0 أيضًا، ويتم تخصيص عنوان IP‏ 111.111.111.222 لها.

قد يكون لدينا موجّه 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.

المسار الأساسي هو المكوّن الثالث الذي يشارك في توجيه طلبات البيانات من واجهة برمجة التطبيقات إلى الخوادم الوكيلة المختلفة لواجهة برمجة التطبيقات التي قد تكون نشرتها. يمكن أن تشارك حِزم الخوادم الوكيلة لواجهة برمجة التطبيقات نقطة نهاية إذا كانت لها مسارات أساسية مختلفة. على سبيل المثال، يمكن تحديد مسار أساسي واحد على النحو التالي: http://api.mycompany.com:80/‎ وتحديد مسار آخر على النحو التالي: http://api.mycompany.com:80/salesdemo.

في هذه الحالة، تحتاج إلى جهاز موازنة الحمل أو موجّه زيارات من نوع ما لتقسيم زيارات http://api.mycompany.com:80/ بين عنوانَي IP (111.111.111.111 على الجهاز الافتراضي 1 و111.111.111.222 على الجهاز الافتراضي 2). هذه الوظيفة خاصة بعملية التثبيت المحددة، ويتم ضبطها من خلال مجموعة الشبكات المحلية.

يتم ضبط المسار الأساسي عند نشر واجهة برمجة تطبيقات. من المثال أعلاه، يمكنك نشر واجهتَي برمجة تطبيقات، mycompany وtestmycompany، للمؤسسة mycompany-org مع المضيف الافتراضي الذي يتضمّن الاسم المستعار للمضيف api.mycompany.com والمنفذ الذي تم ضبطه على 80. إذا لم تحدّد مسارًا أساسيًا في عملية النشر، لن يتمكّن جهاز التوجيه من معرفة واجهة برمجة التطبيقات التي يجب إرسال الطلبات الواردة إليها.

ومع ذلك، إذا نشرت واجهة برمجة التطبيقات testmycompany باستخدام الجزء الأساسي من عنوان URL ‎/salesdemo، سيتمكّن المستخدمون من الوصول إلى واجهة برمجة التطبيقات هذه باستخدام http://api.mycompany.com:80/salesdemo. إذا نشرت واجهة برمجة التطبيقات mycompany باستخدام الجزء الأساسي من عنوان URL ‏/، سيتمكّن المستخدمون من الوصول إلى واجهة برمجة التطبيقات من خلال عنوان 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 الوصول إلى جهاز التوجيه، على المنافذ التي تعرضها الخوادم الوكيلة لواجهة برمجة التطبيقات، لإتاحة الزر إرسال في أداة التتبُّع.
• يتطلّب خادم الإدارة الوصول إلى منفذ 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، يمكن أن ينهي جدار الحماية الاتصال. ومع ذلك، لم يتم تصميم معالج الرسائل لإعادة إنشاء الاتصالات بـ Cassandra.

لتجنُّب هذا الموقف، تنصح Apigee بأن يكون خادم Cassandra ومعالج الرسائل وأجهزة التوجيه في الشبكة الفرعية نفسها حتى لا يشارك جدار الحماية في نشر هذه المكوّنات.

إذا كان هناك جدار حماية بين جهاز التوجيه ومعالِجات الرسائل، وتم ضبط مهلة TCP غير نشطة، ننصحك بما يلي:

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 restart
4. في جميع أجهزة التوجيه، عدِّل /<inst_root>/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، يمكنك إضافة مكوّنات حزمة واجهة برمجة التطبيقات BaaS وبوابة واجهة برمجة التطبيقات BaaS. تستخدم هذه المكوّنات المنافذ الموضّحة في الشكل أدناه:

ملاحظات حول هذا المخطّط البياني:

• يمكن تخصيص عُقد Cassandra لـ API BaaS، أو يمكن مشاركتها مع Edge.
• يستخدم تثبيت الإنتاج في API BaaS جهاز موازنة الحمل بين عقدة بوابة API BaaS وعقد حزمة API BaaS. عند ضبط &quot;البوابة&quot; وإجراء طلبات بيانات من واجهة برمجة التطبيقات في BaaS، عليك تحديد عنوان IP أو اسم نظام أسماء النطاقات لجهاز موازنة الحمل، وليس لعُقد Stack.
• يجب ضبط جميع عُقد Baas Stack لإرسال الرسائل الإلكترونية من خلال خادم SMTP خارجي. بالنسبة إلى بروتوكول SMTP غير المتوافق مع بروتوكول أمان طبقة النقل (TLS)، يكون رقم المنفذ عادةً 25. بالنسبة إلى بروتوكول SMTP المفعَّل فيه بروتوكول أمان طبقة النقل (TLS)، غالبًا ما يكون المنفذ 465، ولكن يُرجى مراجعة مقدّم خدمة SMTP.

يعرض الجدول أدناه المنافذ التلقائية التي يجب فتحها في جدران الحماية، حسب المكوّن:

الترخيص

يتطلّب كل تثبيت لـ Edge ملف ترخيص فريدًا تحصل عليه من Apigee. يجب تقديم المسار إلى ملف الترخيص عند تثبيت خادم الإدارة، على سبيل المثال /tmp/license.txt.

ينسخ المثبِّت ملف الترخيص إلى /<inst_root>/apigee/customer/conf/license.txt.

إذا كان ملف الترخيص صالحًا، يتحقّق خادم الإدارة من تاريخ انتهاء الصلاحية وعدد معالجات الرسائل (MP) المسموح بها. إذا انتهت صلاحية أي من إعدادات الترخيص، يمكنك العثور على السجلّات في الموقع التالي: /<inst_root>/apigee/var/log/edge-management-server/logs. في هذه الحالة، يمكنك التواصل مع فريق دعم Apigee للحصول على تفاصيل حول عملية نقل البيانات.