الزامات نصب

لبه برای ابر خصوصی نسخه ۴.۱۸.۰۱

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

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

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

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

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

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

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

ایجاد کاربر apigee

مراحل نصب، یک کاربر سیستم یونیکس به نام 'apigee' ایجاد می‌کند. دایرکتوری‌ها و فایل‌های Edge و همچنین فرآیندهای Edge متعلق به 'apigee' هستند. این بدان معناست که اجزای Edge به عنوان کاربر 'apigee' اجرا می‌شوند. در صورت لزوم، می‌توانید اجزا را به عنوان یک کاربر دیگر اجرا کنید.

دایرکتوری نصب

به طور پیش‌فرض، نصب‌کننده تمام فایل‌ها را در دایرکتوری /opt/apigee می‌نویسد. شما نمی‌توانید مکان این دایرکتوری را تغییر دهید. اگرچه نمی‌توانید این دایرکتوری را تغییر دهید، می‌توانید یک symlink برای نگاشت /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. مالکیت ریشه نصب و لینک نمادین را به کاربر "apigee" تغییر دهید:

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

جاوا

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

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

SELinux

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

تنظیمات شبکه

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

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

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

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

ENABLE_DYNAMIC_HOSTIP=y

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

بسته‌بندی‌های TCP

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

آی‌پی‌تیبل‌ها

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

sudo/etc/init.d/iptables stop

روی CentOS 7.x:

systemctl stop firewalld

اطمینان حاصل کنید که روتر Edge می‌تواند به /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 فراهم شود.

کاساندرا

تمام گره‌های کاساندرا باید به یک حلقه متصل شوند. کاساندرا کپی‌های داده‌ها را روی چندین گره ذخیره می‌کند تا قابلیت اطمینان و تحمل خطا را تضمین کند. استراتژی تکثیر برای هر فضای کلید Edge، گره‌های کاساندرا را که کپی‌ها در آنها قرار می‌گیرند، تعیین می‌کند. برای اطلاعات بیشتر، به «فاکتور تکثیر کاساندرا» و «سطح سازگاری» مراجعه کنید.

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

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

• cluster_name
• initial_token
• partitioner
• seeds
• listen_address
• rpc_address
• snitch

پایگاه داده پستگرس‌کیوال

پس از نصب Edge، می‌توانید تنظیمات پایگاه داده PostgreSQL زیر را بر اساس میزان رم موجود در سیستم خود تنظیم کنید:

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

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

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

• در گره‌های کاساندرا، محدودیت‌های نرم‌افزاری و سخت‌افزاری 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" پیش‌نیاز استفاده از API BaaS است. نسخه 1.0.15-dev هنگام نصب API BaaS نصب می‌شود.

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

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

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

yum info nss

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

yum update nss

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

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

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

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

1. در هر گره پردازشگر پیام، فایل /etc/nscd.conf را ویرایش کنید.
2. ویژگی زیر را تنظیم کنید:

   enable-cache hosts no

غیرفعال کردن IPv6 در پلتفرم ابری گوگل برای 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

ابزارها

نصب‌کننده از ابزارهای یونیکس زیر در نسخه استاندارد که توسط EL5 یا EL6 ارائه شده‌اند، استفاده می‌کند.

ntpdate

توصیه می‌شود زمان سرورها را همگام‌سازی کنید. اگر قبلاً پیکربندی نشده است، ابزار ntpdate می‌تواند این کار را انجام دهد، که تأیید می‌کند آیا سرورها از نظر زمانی همگام‌سازی شده‌اند یا خیر. می‌توانید yum install ntp برای نصب این ابزار استفاده کنید. این ابزار به ویژه برای تکرار تنظیمات OpenLDAP مفید است. توجه داشته باشید که منطقه زمانی سرور را بر اساس UTC تنظیم می‌کنید.

اوپن‌لدپ ۲.۴

نصب در محل به OpenLDAP 2.4 نیاز دارد. اگر سرور شما به اینترنت متصل باشد، اسکریپت نصب Edge، OpenLDAP را دانلود و نصب می‌کند. اگر سرور شما به اینترنت متصل نیست، باید قبل از اجرای اسکریپت نصب Edge، مطمئن شوید که OpenLDAP از قبل نصب شده است. در RHEL/CentOS، می‌توانید yum install openldap-clients openldap-servers برای نصب OpenLDAP اجرا کنید.

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

فایروال‌ها و میزبان‌های مجازی

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

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

یک روتر در یک ماشین مجازی می‌تواند میزبان‌های مجازی متعددی را در معرض نمایش قرار دهد (تا زمانی که نام مستعار میزبان یا پورت رابط آنها با یکدیگر متفاوت باشد).

به عنوان مثالی از نامگذاری، یک سرور فیزیکی A ممکن است دو ماشین مجازی با نام‌های "VM1" و "VM2" را اجرا کند. فرض کنید "VM1" یک رابط اترنت مجازی را در معرض نمایش قرار می‌دهد که در داخل ماشین مجازی "eth0" نامگذاری می‌شود و آدرس IP آن توسط ماشین مجازی‌سازی یا یک سرور DHCP شبکه 111.111.111.111 تعیین می‌شود؛ و سپس فرض کنید 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 اجازه اتصال دهند.

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

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

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

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

تصویر زیر الزامات پورت‌ها برای هر جزء Edge را نشان می‌دهد:

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

• * پورت ۸۰۸۲ در پردازشگر پیام فقط باید برای دسترسی روتر باز باشد، زمانی که TLS/SSL را بین روتر و پردازشگر پیام پیکربندی می‌کنید. اگر TLS/SSL را بین روتر و پردازشگر پیام پیکربندی نکنید، طبق پیکربندی پیش‌فرض، پورت ۸۰۸۲ همچنان باید روی پردازشگر پیام باز باشد تا بتواند این مؤلفه را مدیریت کند، اما روتر نیازی به دسترسی به آن ندارد.
• پورت‌هایی که با پیشوند "M" مشخص شده‌اند، پورت‌هایی هستند که برای مدیریت کامپوننت استفاده می‌شوند و باید روی کامپوننت باز باشند و برای دسترسی توسط سرور مدیریت نیز باید روی کامپوننت باز باشند.
• اجزای زیر نیاز به دسترسی به پورت ۸۰۸۰ در سرور مدیریت دارند: روتر، پردازنده پیام، رابط کاربری، پستگرس و Qpid.
• یک پردازشگر پیام باید پورت ۴۵۲۸ را به عنوان پورت مدیریت خود باز کند. اگر چندین پردازشگر پیام دارید، همه آنها باید بتوانند از طریق پورت ۴۵۲۸ به یکدیگر دسترسی داشته باشند (که با فلش حلقه‌ای در نمودار بالا برای پورت ۴۵۲۸ روی پردازشگر پیام نشان داده شده است). اگر چندین مرکز داده دارید، این پورت باید از همه پردازشگرهای پیام در همه مراکز داده قابل دسترسی باشد.
• اگرچه الزامی نیست، اما می‌توانید پورت ۴۵۲۷ را روی روتر برای دسترسی توسط هر پردازشگر پیام (Message Processor) باز کنید. در غیر این صورت، ممکن است پیام‌های خطایی را در فایل‌های گزارش پردازشگر پیام (Message Processor) مشاهده کنید.
• یک روتر باید پورت ۴۵۲۷ را به عنوان پورت مدیریتی خود باز کند. اگر چندین روتر دارید، همه آنها باید بتوانند از طریق پورت ۴۵۲۷ به یکدیگر دسترسی داشته باشند (در نمودار بالا با فلش حلقه‌ای برای پورت ۴۵۲۷ روی روتر نشان داده شده است).
• رابط کاربری Edge برای پشتیبانی از دکمه ارسال در ابزار ردیابی، نیاز به دسترسی به روتر، روی پورت‌های در معرض پروکسی‌های API دارد.
• سرور مدیریت نیاز به دسترسی به پورت JMX در گره‌های کاساندرا دارد.
• دسترسی به پورت‌های JMX را می‌توان طوری پیکربندی کرد که نیاز به نام کاربری/رمز عبور داشته باشد. برای اطلاعات بیشتر به نحوه نظارت مراجعه کنید.
• شما می‌توانید به صورت اختیاری دسترسی TLS/SSL را برای اتصالات خاصی پیکربندی کنید که می‌توانند از پورت‌های مختلف استفاده کنند. برای اطلاعات بیشتر به TLS/SSL مراجعه کنید.
• اگر دو گره Postgres را برای استفاده از تکثیر master-standby پیکربندی می‌کنید، باید پورت ۲۲ را روی هر گره برای دسترسی ssh باز کنید. می‌توانید به صورت اختیاری پورت‌ها را روی گره‌های جداگانه باز کنید تا دسترسی ssh امکان‌پذیر شود.
• شما می‌توانید سرور مدیریت و رابط کاربری Edge را طوری پیکربندی کنید که ایمیل‌ها را از طریق یک سرور SMTP خارجی ارسال کنند. در این صورت، باید مطمئن شوید که سرور مدیریت و رابط کاربری می‌توانند به پورت لازم در سرور SMTP دسترسی داشته باشند. برای SMTP بدون TLS، شماره پورت معمولاً ۲۵ است. برای SMTP با TLS فعال، اغلب ۴۶۵ است، اما با ارائه‌دهنده SMTP خود مشورت کنید.

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

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

جدول بعدی همان پورت‌ها را که به صورت عددی فهرست شده‌اند، به همراه اجزای منبع و مقصد نشان می‌دهد:

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

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

اگر فایروال بین روتر و پردازنده‌های پیام قرار دارد و دارای زمان انتظار غیرفعال TCP است، توصیه‌های ما این است:

1. در تنظیمات sysctl در سیستم عامل لینوکس، مقدار net.ipv4.tcp_keepalive_time = 1800 قرار دهید، که در آن ۱۸۰۰ باید کمتر از زمان انتظار غیرفعال بودن 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

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

الزامات پورت API BaaS

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

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

• پورتال API BaaS هرگز مستقیماً به یک گره BaaS Stack درخواست ارسال نمی‌کند. وقتی یک توسعه‌دهنده وارد پورتال می‌شود، برنامه پورتال در مرورگر دانلود می‌شود. سپس برنامه پورتال که در مرورگر اجرا می‌شود، درخواست‌هایی را به گره‌های BaaS Stack ارسال می‌کند.
• نصب API BaaS در محیط عملیاتی از یک متعادل‌کننده بار بین گره پورتال API BaaS و گره‌های پشته API BaaS استفاده می‌کند. هنگام پیکربندی پورتال و هنگام برقراری تماس‌های API BaaS، آدرس IP یا نام DNS متعادل‌کننده بار را مشخص می‌کنید، نه گره‌های پشته را.
• تمام گره‌های پشته باید پورت ۲۵۵۱ را برای دسترسی از سایر گره‌های پشته باز کنند (در نمودار بالا با فلش حلقه‌ای برای پورت ۲۵۵۱ روی گره‌های پشته نشان داده شده است). اگر چندین مرکز داده دارید، این پورت باید از تمام گره‌های پشته در تمام مراکز داده قابل دسترسی باشد.
• شما باید تمام گره‌های Baas Stack را برای ارسال ایمیل از طریق یک سرور SMTP خارجی پیکربندی کنید. برای SMTP بدون TLS، شماره پورت معمولاً ۲۵ است. برای SMTP با قابلیت TLS، اغلب ۴۶۵ است، اما با ارائه‌دهنده SMTP خود مشورت کنید.
• گره‌های کاساندرا می‌توانند به 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 تماس بگیرید.