الزامات نصب

Edge for Private Cloud نسخه ۴.۱۸.۰۱

الزامات سخت‌افزاری

باید حداقل سخت‌افزار موردنیاز زیر را برای زیرساخت با دسترسی بالا در محیطی با درجه تولید داشته باشید. برای همه سناریوهای نصب شرح‌داده‌شده در توپولوژی‌های نصب، جدول‌های زیر حداقل الزامات سخت‌افزاری را برای مؤلفه‌های نصب فهرست می‌کنند.

در این جدول‌ها، الزامات دیسک سخت علاوه‌بر فضای دیسک سخت موردنیاز سیستم‌عامل است. بسته به برنامه‌ها و ترافیک شبکه، ممکن است نصب شما به منابع بیشتر یا کمتری نسبت به موارد فهرست‌شده در زیر نیاز داشته باشد.

علاوه‌براین، اگر می‌خواهید «سرویس‌های درآمدزایی» را نصب کنید، الزامات سخت‌افزاری زیر فهرست شده است:

اگر می‌خواهید API BaaS را نصب کنید، موارد زیر الزامات سخت‌افزاری را فهرست می‌کند:

الزامات سیستم‌عامل و نرم‌افزار شخص ثالث

این دستورالعمل‌های نصب و فایل‌های نصب ارائه‌شده در سیستم‌عامل‌ها و نرم‌افزارهای طرف سوم فهرست‌شده در نرم‌افزارهای پشتیبانی‌شده و نسخه‌های پشتیبانی‌شده آزمایش شده‌اند.

درحال ایجاد کاربر apigee

فرایند نصب، کاربر سیستم Unix به‌نام «apigee» ایجاد می‌کند. Edge directories and files are owned by 'apigee', as are Edge processes. این یعنی مؤلفه‌های Edge به‌عنوان کاربر «apigee» اجرا می‌شوند. درصورت لزوم، می‌توانید مؤلفه‌ها را به‌عنوان کاربر دیگری اجرا کنید.

فهرست راهنمای نصب

به‌طور پیش‌فرض، نصب‌کننده همه فایل‌ها را در دایرکتوری /opt/apigee می‌نویسد. نمی‌توانید مکان این فهرست راهنما را تغییر دهید. اگرچه نمی‌توانید این دایرکتوری را تغییر دهید، می‌توانید یک پیوند نمادین برای نگاشت /opt/apigee به مکان دیگری ایجاد کنید، همان‌طور که در زیر توضیح داده شده است.

در دستورالعمل‌های این راهنما، دایرکتوری نصب به‌صورت /opt/apigee ذکر شده است.

درحال ایجاد پیوند نمادین از opt /apigee/

قبل‌از ایجاد پیوند نمادین، ابتدا باید کاربر و گروهی با نام «apigee» ایجاد کنید. این همان گروه و کاربری است که توسط نصب‌کننده Edge ایجاد شده است.

برای ایجاد پیوند نمادین، این مراحل را قبل‌از بارگیری فایل bootstrap_4.18.01.sh انجام دهید. باید همه این مراحل را به‌عنوان root انجام دهید:

1. کاربر و گروه «apigee» را ایجاد کنید:

   groupadd -r apigee > useradd -r -g apigee -d /opt/apigee -s /sbin/nologin -c "Apigee platform user" apigee

2. پیوند نمادینی از /opt/apigee به ریشه نصب موردنظرتان ایجاد کنید:

   ln -Ts /srv/myInstallDir /opt/apigee

   که /srv/myInstallDir مکان موردنظر برای فایل‌های Edge است.

3. Change ownership of the install root and symlink to the "apigee" user:

   chown -h apigee:apigee /srv/myInstallDir /opt/apigee

جاوا

قبل‌از نصب، باید نسخه پشتیبانی‌شده‌ای از Java 1.8 در هر دستگاه نصب شده باشد. کیت‌های توسعه جاوا پشتیبانی‌شده در نرم‌افزارهای پشتیبانی‌شده و نسخه‌های پشتیبانی‌شده فهرست شده‌اند.

مطمئن شوید که JAVA_HOME به ریشه JDK برای کاربری که نصب را انجام می‌دهد اشاره می‌کند.

SELinux

بسته به تنظیمات شما برای SELinux، ممکن است Edge با مشکلاتی در نصب و راه‌اندازی مؤلفه‌های Edge مواجه شود. درصورت لزوم، می‌توانید SELinux را غیرفعال کنید یا آن را درحین نصب روی حالت مجاز تنظیم کنید، و سپس آن را پس‌از نصب دوباره فعال کنید. برای اطلاعات بیشتر، نصب ابزار کمکی apigee-setup در Edge را ببینید.

تنظیم شبکه

توصیه می‌شود قبل‌از نصب، تنظیمات شبکه را بررسی کنید. نصب‌کننده انتظار دارد که همه دستگاه‌ها نشانی IP ثابت داشته باشند. از فرمان‌های زیر برای اعتبارسنجی تنظیمات استفاده کنید:

• ‫hostname نام دستگاه را برمی‌گرداند
• ‫hostname -i نشانی IP را برای نام میزبان برمی‌گرداند که می‌توان از دستگاه‌های دیگر به آن دسترسی داشت.

بسته به نوع و نسخه سیستم‌عاملتان، اگر نام میزبان به‌درستی تنظیم نشده باشد، ممکن است لازم باشد /etc/hosts و /etc/sysconfig/network را ویرایش کنید. برای اطلاعات بیشتر، به اسناد سیستم‌عامل خاص خود مراجعه کنید.

اگر سروری چند کارت رابط داشته باشد، فرمان «hostname -i» فهرستی از نشانی‌های IP را که با فاصله از هم جدا شده‌اند برمی‌گرداند. به‌طور پیش‌فرض، نصب‌کننده Edge از اولین نشانی IP برگردانده‌شده استفاده می‌کند که ممکن است در همه شرایط درست نباشد. به‌عنوان جایگزین، می‌توانید ویژگی زیر را در فایل پیکربندی نصب تنظیم کنید:

ENABLE_DYNAMIC_HOSTIP=y

با تنظیم این ویژگی روی «y»، نصب‌کننده از شما می‌خواهد نشانی IP را برای استفاده به‌عنوان بخشی از نصب انتخاب کنید. مقدار پیش‌فرض «n» است. برای اطلاعات بیشتر، مرجع فایل پیکربندی Edge را ببینید.

TCP Wrappers

TCP Wrappers می‌تواند ارتباط برخی‌از درگاه‌ها را مسدود کند و بر نصب OpenLDAP،‏ Postgres، و Cassandra تأثیر بگذارد. در آن گره‌ها، /etc/hosts.allow و /etc/hosts.deny را بررسی کنید تا مطمئن شوید هیچ محدودیت درگاهی در درگاه‌های لازم OpenLDAP،‏ Postgres، و Cassandra وجود ندارد.

iptables

تأیید کنید که هیچ خط‌مشی iptables وجود ندارد که از اتصال بین گره‌ها در درگاه‌های Edge موردنیاز جلوگیری کند. درصورت لزوم، می‌توانید iptables را درطول نصب بااستفاده از فرمان زیر متوقف کنید:

sudo/etc/init.d/iptables stop

در CentOS 7.x:

systemctl stop firewalld

مطمئن شوید Edge Router می‌تواند به ‎ /etc/rc.d/init.d/functions دسترسی داشته باشد

گره‌های Edge Router و BaaS Portal از مسیریاب Nginx استفاده می‌کنند و به دسترسی خواندن به /etc/rc.d/init.d/functions نیاز دارند.

اگر فرایند امنیتی شما را ملزم می‌کند اجازه‌ها را روی /etc/rc.d/init.d/functions تنظیم کنید، آن‌ها را روی ۷۰۰ تنظیم نکنید، درغیراین‌صورت رهیاب راه‌اندازی نخواهد شد. اجازه‌ها را می‌توان روی ۷۴۴ تنظیم کرد تا دسترسی خواندن به /etc/rc.d/init.d/functions مجاز شود.

Cassandra

همه گره‌های Cassandra باید به یک حلقه متصل باشند. Cassandra نسخه‌های تکراری داده‌ها را در چندین گره ذخیره می‌کند تا اطمینان‌پذیری و تحمل خطا را تضمین کند. استراتژی تکرار برای هر فضای کلید Edge، گره‌های Cassandra را که تکرارها در آن قرار می‌گیرند تعیین می‌کند. برای اطلاعات بیشتر، درباره Cassandra Replication Factor and Consistency Level را ببینید.

Cassandra به‌طور خودکار اندازه پشته Java را براساس حافظه دردسترس تنظیم می‌کند. برای اطلاعات بیشتر، تنظیم منابع Java را ببینید. درصورت افت عملکرد یا مصرف بالای حافظه.

پس‌از نصب Edge for Private Cloud، می‌توانید با بررسی فایل /opt/apigee/apigee-cassandra/conf/cassandra.yaml مطمئن شوید که Cassandra به‌درستی پیکربندی شده است. برای مثال، مطمئن شوید که متن نصب Edge for Private Cloud ویژگی‌های زیر را تنظیم کرده باشد:

• cluster_name
• initial_token
• partitioner
• seeds
• 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 /opt/apigee/customer/application/postgresql.properties

   اگر فایل وجود ندارد، آن را ایجاد کنید.

2. خصوصیات فهرست‌شده در بالا را تنظیم کنید.
3. ویرایش‌هایتان را ذخیره کنید.
4. پایگاه داده PostgreSQL را بازراه‌اندازی کنید:

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

محدودیت‌های سیستم

مطمئن شوید که محدودیت‌های سیستم زیر را در گره‌های Cassandra و «پردازشگر پیام» تنظیم کرده‌اید:

• در گره‌های Cassandra، محدودیت‌های memlock،‏ nofile، و فضای نشانی (as) نرم و سخت را برای کاربر نصب (پیش‌فرض «apigee» است) در /etc/security/limits.d/90-apigee-edge-limits.conf به‌صورت زیر تنظیم کنید:

  apigee soft memlock unlimited
  apigee hard memlock unlimited
  apigee soft nofile 32768
  apigee hard nofile 65536
  apigee soft as unlimited
  apigee hard as unlimited

• در گره‌های «پردازشگر پیام»، حداکثر تعداد توصیف‌گرهای فایل باز را روی ۶۴ هزار در /etc/security/limits.d/90-apigee-edge-limits.conf تنظیم کنید، همان‌طور که در زیر نشان داده شده است:

  apigee soft nofile 32768
  apigee hard nofile 65536

  درصورت لزوم، می‌توانید این حد را افزایش دهید. برای مثال، اگر تعداد زیادی فایل موقت به‌طور هم‌زمان باز باشد.

jsvc

«jsvc» پیش‌نیاز استفاده از API BaaS است. وقتی API BaaS را نصب می‌کنید، نسخه 1.0.15-dev نصب می‌شود.

خدمات امنیت شبکه (NSS)

«سرویس‌های امنیتی شبکه» (NSS) مجموعه‌ای از کتابخانه‌ها است که از توسعه برنامه‌های کارخواه و سرور با قابلیت امنیتی پشتیبانی می‌کند. باید مطمئن شوید که NSS نسخه ۳.۱۹ یا جدیدتر را نصب کرده‌اید.

برای بررسی نسخه فعلی:

yum info nss

برای به‌روزرسانی NSS:

yum update nss

برای اطلاعات بیشتر، این مقاله از RedHat را ببینید.

غیرفعال کردن جستجوی ساناد در IPv6 هنگام استفاده از NSCD (Name Service Cache Daemon)

اگر NSCD (Name Service Cache Daemon) را نصب و فعال کرده باشید، «پردازشگرهای پیام» دو جستجوی ساناد انجام می‌دهند: یکی برای IPv4 و یکی برای IPv6. هنگام استفاده از NSCD، باید جستجوی ساناد را در IPv6 غیرفعال کنید.

برای غیرفعال کردن جستجوی ساناد در IPv6:

1. در هر گره «پردازشگر پیام»، /etc/nscd.conf را ویرایش کنید
2. خصوصیت زیر را تنظیم کنید:

   enable-cache hosts no

غیرفعال کردن IPv6 در Google Cloud Platform برای RedHat/CentOS 7

اگر Edge را روی RedHat 7 یا CentOS 7 در Google Cloud Platform نصب می‌کنید، باید IPv6 را در همه گره‌های Qpid غیرفعال کنید.

برای دستورالعمل‌های غیرفعال کردن IPv6، به اسناد RedHat یا CentOS برای نسخه سیستم‌عامل خاص خود مراجعه کنید. برای مثال، می‌توانید:

1. /etc/hosts را در ویرایشگر باز کنید.
2. نویسه «#» را در ستون یک خط زیر وارد کنید تا آن را به‌صورت نظر درآورید:

   #::1 localhost localhost.localdomain localhost6 localhost6.localdomain6

3. فایل را ذخیره کنید.

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 استفاده می‌کند.

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 اجرا کنید.

برای نصب‌های ۱۳ میزبانی و نصب‌های ۱۲ میزبانی با دو «مرکز داده»، به تکرار OpenLDAP نیاز دارید زیرا چندین گره میزبان OpenLDAP هستند.

دیوارهای آتش و میزبان‌های مجازی

اصطلاح virtual معمولاً در حوزه فناوری اطلاعات بیش‌ازحد استفاده می‌شود و این موضوع در مورد استقرار Apigee Edge برای Private Cloud و میزبان‌های مجازی نیز صدق می‌کند. برای شفاف‌سازی، دو کاربرد اصلی برای اصطلاح virtual وجود دارد:

• ماشین‌های مجازی (VM): الزامی نیست، اما برخی‌از استقرارها از فناوری VM برای ایجاد سرورهای مجزا برای مؤلفه‌های Apigee خود استفاده می‌کنند. میزبان‌های VM، مانند میزبان‌های فیزیکی، می‌توانند میانای شبکه و دیوار آتش داشته باشند.
• میزبان‌های مجازی: نقاط پایانی وب، مشابه میزبان مجازی Apache.

یک رهیاب در VM می‌تواند چندین میزبان مجازی را نمایش دهد (تا زمانی که از یکدیگر در نام مستعار میزبان یا در درگاه رابط خود متفاوت باشند).

برای مثال، یک سرور فیزیکی واحد A ممکن است دو ماشین مجازی را اجرا کند، به نام «VM1» و «VM2». فرض کنیم «VM1» یک میانای اترنت مجازی را نشان می‌دهد که در VM «eth0» نامیده می‌شود و نشانی IP 111.111.111.111 توسط ماشین مجازی‌سازی یا سرور DHCP شبکه به آن اختصاص داده می‌شود؛ و سپس فرض کنیم VM2 یک میانای اترنت مجازی را نشان می‌دهد که آن هم «eth0» نامیده می‌شود و نشانی IP 111.111.111.222 به آن اختصاص داده می‌شود.

ممکن است یک مسیریاب Apigee داشته باشیم که در هریک از دو VM اجرا می‌شود. رهیاب‌ها نقاط پایانی میزبان مجازی را همانند این مثال فرضی نشان می‌دهند:

مسیریاب 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 ارائه دهد و این دیوار آتش نیز باید به ترافیک درگاه‌های ۸۰ و ۴۴۳ اجازه اتصال دهد.

مسیر پایه سومین مؤلفه درگیر در مسیریابی فراخوانی‌های API به پراکسی‌های 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، mycompany و testmycompany، را برای سازمان mycompany-org با میزبان مجازی که نام مستعار میزبان api.mycompany.com و درگاه تنظیم‌شده روی 80 دارد مستقر کنید. اگر مسیر پایه را در استقرار اعلام نکنید، مسیریاب نمی‌داند درخواست‌های ورودی را به کدام API ارسال کند.

بااین‌حال، اگر میانای برنامه‌سازی کاربردی testmycompany را با نشانی وب پایه /salesdemo مستقر کنید، کاربران بااستفاده از http://api.mycompany.com:80/salesdemo به آن میانای برنامه‌سازی کاربردی دسترسی پیدا می‌کنند. اگر میانای برنامه‌سازی کاربردی mycompany را با نشانی وب پایه / مستقر کنید، کاربران شما ازطریق نشانی وب http://api.mycompany.com:80/ به میانای برنامه‌سازی کاربردی دسترسی پیدا می‌کنند.

الزامات درگاه Edge

نیاز به مدیریت دیوار آتش فراتر از میزبان‌های مجازی است؛ هم دیوار آتش ماشین مجازی و هم دیوار آتش میزبان فیزیکی باید ترافیک درگاه‌های موردنیاز مؤلفه‌ها را برای برقراری ارتباط با یکدیگر مجاز کنند.

تصویر زیر الزامات درگاه را برای هر مؤلفه Edge نشان می‌دهد:

نکاتی درباره این نمودار:

• * درگاه ۸۰۸۲ در «پردازشگر پیام» فقط زمانی باید برای دسترسی «مسیریاب» باز باشد که «امنیت لایه انتقال»/SSL را بین «مسیریاب» و «پردازشگر پیام» پیکربندی کنید. اگر TLS/SSL را بین «مسیریاب» و «پردازشگر پیام» پیکربندی نکنید، پیکربندی پیش‌فرض، درگاه ۸۰۸۲، همچنان باید در «پردازشگر پیام» باز باشد تا مؤلفه را مدیریت کند، اما «مسیریاب» نیازی به دسترسی به آن ندارد.
• درگاه‌هایی که پیشوند «M» دارند درگاه‌هایی هستند که برای مدیریت مؤلفه استفاده می‌شوند و باید در مؤلفه باز باشند و باید در مؤلفه برای دسترسی توسط «سرور مدیریت» باز باشند.
• مؤلفه‌های زیر به دسترسی به درگاه ۸۰۸۰ در «سرور مدیریت» نیاز دارند: روتر، پردازشگر پیام، میانای کاربر، Postgres، و Qpid.
• «پردازشگر پیام» باید درگاه ۴۵۲۸ را به‌عنوان درگاه مدیریتی خود باز کند. اگر چند «پردازشگر پیام» دارید، همه آن‌ها باید بتوانند ازطریق درگاه ۴۵۲۸ به یکدیگر دسترسی داشته باشند (با پیکان حلقه در نمودار بالا برای درگاه ۴۵۲۸ در «پردازشگر پیام» نشان داده شده است). اگر چندین «مرکز داده» دارید، درگاه باید از همه «پردازشگرهای پیام» در همه «مراکز داده» دردسترس باشد.
• اگرچه الزامی نیست، می‌توانید درگاه ۴۵۲۷ را در «مسیریاب» باز کنید تا هر «پردازشگر پیام» بتواند به آن دسترسی داشته باشد. درغیراین‌صورت، ممکن است پیام‌های خطا را در فایل‌های گزارش «پردازشگر پیام» ببینید.
• روتر باید درگاه ۴۵۲۷ را به‌عنوان درگاه مدیریتی خود باز کند. اگر چند «رهیاب» دارید، همه آن‌ها باید بتوانند ازطریق درگاه ۴۵۲۷ به یکدیگر دسترسی داشته باشند (با پیکان حلقه در نمودار بالا برای درگاه ۴۵۲۷ در «رهیاب» نشان داده شده است).
• ‫Edge UI برای پشتیبانی از دکمه ارسال در ابزار ردیابی، به دسترسی به «مسیریاب» در درگاه‌های ارائه‌شده توسط پراکسی‌های میانای برنامه‌سازی کاربردی نیاز دارد.
• «سرور مدیریت» به دسترسی به درگاه JMX در گره‌های Cassandra نیاز دارد.
• دسترسی به درگاه‌های JMX را می‌توان به‌گونه‌ای پیکربندی کرد که به نام کاربری/گذرواژه نیاز داشته باشد. برای اطلاعات بیشتر، نحوه پایش را ببینید.
• می‌توانید به‌طور اختیاری دسترسی «امنیت لایه انتقال»/SSL را برای اتصالات خاصی که می‌توانند از درگاه‌های مختلف استفاده کنند پیکربندی کنید. برای اطلاعات بیشتر، به TLS/SSL مراجعه کنید.
• اگر دو گره Postgres را برای استفاده از تکرار اصلی-آماده‌به‌کار پیکربندی می‌کنید، باید درگاه ۲۲ را در هر گره برای دسترسی ssh باز کنید. می‌توانید به‌طور اختیاری درگاه‌ها را در گره‌های جداگانه باز کنید تا دسترسی ssh مجاز شود.
• می‌توانید «سرور مدیریت» و Edge UI را برای ارسال ایمیل ازطریق سرور SMTP خارجی پیکربندی کنید. اگر این کار را انجام دهید، باید مطمئن شوید که «سرور مدیریت» و میانای کاربر می‌توانند به درگاه لازم در سرور SMTP دسترسی داشته باشند. برای SMTP غیر TLS، شماره درگاه معمولاً ۲۵ است. برای SMTP با TLS فعال، اغلب ۴۶۵ است، اما با ارائه‌دهنده 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 تنظیم کنید، که ۱۸۰۰ باید کمتر از زمان اتمام tcp غیرفعال دیوار آتش باشد. این تنظیم باید اتصال را در حالت برقرارشده نگه دارد تا دیوار آتش اتصال را قطع نکند.
2. در همه «پردازشگرهای پیام»، /opt/apigee/customer/application/message-processor.properties را ویرایش کنید تا ویژگی زیر را اضافه کنید. اگر فایل وجود ندارد، آن را ایجاد کنید.

   conf_system_cassandra.maxconnecttimeinmillis=-1

3. «پردازشگر پیام» را بازراه‌اندازی کنید:

   /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart

4. در همه «مسیریاب‌ها»، /opt/apigee/customer/application/router.properties را ویرایش کنید تا ویژگی زیر را اضافه کنید. اگر فایل وجود ندارد، آن را ایجاد کنید.

   conf_system_cassandra.maxconnecttimeinmillis=-1

5. بازراه‌اندازی رهیاب:

   /opt/apigee/apigee-service/bin/apigee-service edge-router restart

اگر پیکربندی خوشه‌ای ۱۲ میزبان را با دو «مرکز داده» نصب می‌کنید، مطمئن شوید که گره‌ها در دو «مرکز داده» می‌توانند ازطریق درگاه‌های نشان‌داده‌شده در زیر ارتباط برقرار کنند:

الزامات درگاه میانای برنامه‌سازی کاربردی BaaS

اگر تصمیم به نصب API BaaS بگیرید، مؤلفه‌های API BaaS Stack و API BaaS Portal را اضافه می‌کنید. این مؤلفه‌ها از درگاه‌های نشان‌داده‌شده در شکل زیر استفاده می‌کنند:

نکاتی درباره این نمودار:

• «درگاه BaaS میانای برنامه‌سازی کاربردی» هرگز مستقیماً به گره «پشته BaaS» درخواست نمی‌دهد. وقتی توسعه‌دهنده‌ای به سیستم «درگاه» وارد می‌شود، برنامه «درگاه» در مرورگر بارگیری می‌شود. سپس برنامه «درگاه» که در مرورگر اجرا می‌شود، درخواست‌هایی به گره‌های BaaS Stack ارسال می‌کند.
• نصب تولید API BaaS از متعادل‌کننده بار بین گره «درگاه API BaaS» و گره‌های «پشته API BaaS» استفاده می‌کند. هنگام پیکربندی «پورتال» و هنگام برقراری تماس‌های BaaS API، نشانی IP یا نام ساناد متعادل‌کننده بار را مشخص می‌کنید، نه گره‌های Stack.
• همه گره‌های Stack باید درگاه ۲۵۵۱ را برای دسترسی از همه گره‌های Stack دیگر باز کنند (با پیکان حلقه در نمودار بالا برای درگاه ۲۵۵۱ در گره‌های Stack نشان داده شده است). اگر چند «مرکز داده» دارید، درگاه باید از همه گره‌های «پشته» در همه «مراکز داده» دردسترس باشد.
• باید همه گره‌های Baas Stack را پیکربندی کنید تا ایمیل‌ها را ازطریق سرور SMTP خارجی ارسال کنند. برای SMTP غیرTLS، شماره درگاه معمولاً ۲۵ است. برای SMTP با TLS فعال، اغلب ۴۶۵ است، اما با ارائه‌دهنده SMTP خود بررسی کنید.
• گره‌های Cassandra را می‌توان به API BaaS اختصاص داد یا با Edge هم‌رسانی کرد.

جدول زیر درگاه‌های پیش‌فرضی را نشان می‌دهد که باید در دیوارهای آتش باز شوند، براساس مؤلفه:

صدور پروانه

هر نصب Edge به یک فایل پروانه یکتا نیاز دارد که از Apigee دریافت می‌کنید. هنگام نصب سرور مدیریت، باید مسیر فایل پروانه را ارائه دهید، برای مثال ‎/tmp/license.txt.

نصب‌کننده فایل پروانه را در /opt/apigee/customer/conf/license.txt کپی می‌کند.

اگر فایل پروانه معتبر باشد، سرور مدیریت تاریخ انقضا و تعداد مجاز «پردازشگر پیام» (MP) را اعتبارسنجی می‌کند. اگر هرکدام از تنظیمات پروانه منقضی شده باشد، می‌توانید گزارش‌ها را در مکان زیر پیدا کنید: /opt/apigee/var/log/edge-management-server/logs. در این صورت، می‌توانید برای جزئیات انتقال با پشتیبانی Apigee Edge تماس بگیرید.

اگر هنوز پروانه ندارید، با بخش فروش Apigee تماس بگیرید.