Edge for Private Cloud نسخه 4.16.09
الزامات سخت افزاری
شما باید حداقل الزامات سخت افزاری زیر را برای یک زیرساخت بسیار در دسترس در یک محیط درجه تولید برآورده کنید. برای تمام سناریوهای نصب شرح داده شده در توپولوژی های نصب ، جداول زیر حداقل الزامات سخت افزاری برای اجزای نصب را فهرست می کنند.
در این جداول الزامات هارد دیسک علاوه بر فضای هارد دیسک مورد نیاز سیستم عامل است. بسته به برنامه های کاربردی و ترافیک شبکه شما، نصب شما ممکن است به منابع بیشتر یا کمتری نسبت به فهرست زیر نیاز داشته باشد.
مؤلفه نصب | RAM | CPU | حداقل هارد دیسک |
---|---|---|---|
کاساندرا | 16 گیگابایت | 8 هسته ای | 250 گیگابایت حافظه محلی با SSD یا HDD سریع که از 2000 IOPS پشتیبانی می کند |
پردازشگر/روتر پیام در همان دستگاه | 8/16 گیگابایت | 4 هسته ای † | 100 گیگابایت |
تجزیه و تحلیل - Postgres/Qpid در همان سرور (برای تولید توصیه نمی شود) | 16 گیگابایت* | 8 هسته* | 500 گیگابایت - 1 ترابایت** فضای ذخیره سازی شبکه***، ترجیحاً با پشتیبان SSD، با پشتیبانی از 1000 IOPS یا بالاتر*. |
تجزیه و تحلیل - Postgres مستقل | 16 گیگابایت* | 8 هسته* | 500 گیگابایت - 1 ترابایت** فضای ذخیره سازی شبکه***، ترجیحاً با پشتیبان SSD، با پشتیبانی از 1000 IOPS یا بالاتر*. |
تجزیه و تحلیل - Qpid مستقل | 8 گیگابایت | 4 هسته ای | حافظه محلی 30 تا 50 گیگابایت با SSD یا HDD سریع برای نصب های بیشتر از 250 TPS، HDD با حافظه محلی با پشتیبانی از 1000 IOPS توصیه می شود. |
دیگر (OpenLDAP، UI، سرور مدیریت) | 4 گیگابایت | 2 هسته ای | 60 گیگابایت |
† تنظیم سیستم مورد نیاز پردازشگر پیام بر اساس توان عملیاتی: حداقل توصیه 4 هسته ای و 8 هسته ای برای یک سیستم توان عملیاتی بالا است. شما می توانید تست های عملکرد را برای تعیین اندازه بهینه برای API های خود اجرا کنید. | |||
*نیازهای سیستم Postgres را بر اساس توان عملیاتی تنظیم کنید:
| |||
**مقدار دیسک سخت Postgres بر اساس تجزیه و تحلیل خارج از جعبه ثبت شده توسط Edge است. اگر مقادیر سفارشی را به داده های تجزیه و تحلیل اضافه کنید، این مقادیر باید متناسب با آن افزایش یابد. برای تخمین ذخیره سازی مورد نیاز از فرمول زیر استفاده کنید: | |||
*** ذخیره سازی شبکه برای پایگاه داده Postgresql توصیه می شود زیرا:
|
علاوه بر این، موارد زیر الزامات سخت افزاری را برای نصب خدمات کسب درآمد فهرست می کند:
جزء با کسب درآمد | RAM | CPU | هارد دیسک |
---|---|---|---|
سرور مدیریت (با خدمات کسب درآمد) | 8 گیگابایت | 4 هسته ای | 60 گیگابایت |
تجزیه و تحلیل - Postgres/Qpid در همان سرور | 16 گیگابایت | 8 هسته ای | 500 گیگابایت - فضای ذخیره سازی شبکه 1 ترابایت، ترجیحاً با پشتیبان SSD، از 1000 IOPS یا بالاتر پشتیبانی می کند، یا از قانون جدول بالا استفاده کنید. |
تجزیه و تحلیل - Postgres مستقل | 16 گیگابایت | 8 هسته ای | 500 گیگابایت - فضای ذخیره سازی شبکه 1 ترابایت، ترجیحاً با پشتیبان SSD، از 1000 IOPS یا بالاتر پشتیبانی می کند، یا از قانون جدول بالا استفاده کنید. |
تجزیه و تحلیل - Qpid مستقل | 8 گیگابایت | 4 هسته ای | 40 گیگابایت |
اگر میخواهید API BaaS را نصب کنید، موارد زیر الزامات سختافزاری را فهرست میکند:
کامپوننت API BaaS | RAM | CPU | هارد دیسک |
---|---|---|---|
ElasticSearch* | 8 گیگابایت | 4 هسته ای | 60 تا 80 گیگابایت |
API BaaS Stack * | 8 گیگابایت | 4 هسته ای | 60 تا 80 گیگابایت |
پورتال API BaaS | 1 گیگابایت | 2 هسته ای | 20 گیگابایت |
Cassandra (اختیاری - معمولاً از یک کلاستر Cassandra برای هر دو سرویس Edge و API BaaS استفاده می کنید) | 16 گیگابایت | 8 هسته ای | 250 گیگابایت حافظه محلی با SSD یا HDD سریع که از 2000 IOPS پشتیبانی می کند |
* می توانید ElasticSearch و API BaaS Stack را در همان گره نصب کنید. اگر این کار را انجام دادید، ElasticSearch را برای استفاده از 4 گیگابایت حافظه (پیشفرض) پیکربندی کنید. اگر ElasticSearch روی گره خودش نصب شده باشد، آن را طوری پیکربندی کنید که از 6 گیگابایت حافظه استفاده کند. |
توجه :
- اگر سیستم فایل ریشه برای نصب به اندازه کافی بزرگ نیست، توصیه می شود داده ها را روی یک دیسک بزرگتر قرار دهید.
- اگر نسخه قدیمی Apigee Edge for Private Cloud روی دستگاه نصب شده است، مطمئن شوید که پوشه /tmp/java را قبل از نصب جدید حذف کرده اید.
- پوشه موقت /tmp گسترده سیستم برای راه اندازی Cassandra به مجوزهای اجرایی نیاز دارد.
- اگر کاربر "apigee" قبل از نصب ایجاد شده است، مطمئن شوید که "/home/apigee" به عنوان فهرست اصلی وجود دارد و متعلق به "apigee:apigee" است.
سیستم عامل و نرم افزار شخص ثالث مورد نیاز
این دستورالعملهای نصب و فایلهای نصب ارائهشده بر روی سیستمعاملها و نرمافزارهای شخص ثالث فهرستشده در اینجا آزمایش شدهاند: https://apigee.com/docs/api-services/reference/supported-software .
ایجاد کاربر apigee
مراحل نصب یک کاربر سیستم یونیکس به نام "apigee" ایجاد می کند. دایرکتوریها و فایلهای Edge نیز مانند فرآیندهای Edge متعلق به 'apigee' هستند. این بدان معناست که اجزای Edge به عنوان کاربر "apigee" اجرا می شوند. در صورت لزوم، می توانید کامپوننت ها را به عنوان یک کاربر متفاوت اجرا کنید. به عنوان مثال به «پیوند روتر به پورت محافظت شده» در Install Edge components on node مراجعه کنید.
دایرکتوری نصب
به طور پیش فرض، نصب کننده همه فایل ها را در پوشه /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 را ویرایش کنید اگر نام میزبان به درستی تنظیم نشده باشد. برای اطلاعات بیشتر به اسناد مربوط به سیستم عامل خاص خود مراجعه کنید.
کاساندرا
تمام گره های کاساندرا باید به یک حلقه متصل شوند. کاساندرا برای اطمینان از قابلیت اطمینان و تحمل خطا، کپی های داده را در چندین گره ذخیره می کند. استراتژی تکرار برای هر فضای کلید Edge، گرههای Cassandra را که در آن رونوشتها قرار میگیرند، تعیین میکند. برای اطلاعات بیشتر، درباره ضریب تکرار کاساندرا و سطح سازگاری را ببینید.
Cassandra به طور خودکار اندازه پشته جاوا خود را بر اساس حافظه موجود تنظیم می کند. برای اطلاعات بیشتر، به تنظیم منابع جاوا مراجعه کنید. در صورت کاهش عملکرد یا مصرف زیاد حافظه.
پس از نصب Edge for Private Cloud، می توانید با بررسی فایل /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml بررسی کنید که Cassandra به درستی پیکربندی شده است. به عنوان مثال، مطمئن شوید که اسکریپت نصب Edge for Private Cloud ویژگی های زیر را تنظیم می کند:
- cluster_name
- نشانه_شروع
- پارتیشن کننده
- دانه ها
- listen_address
- rpc_address
- دزدیدن
هشدار : این فایل را ویرایش نکنید.
پایگاه داده 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
برای تنظیم این مقادیر:
- ویرایش postgresql.properties:
> vi /<inst_root>/apigee/customer/application/postgresql.properties
اگر فایل وجود ندارد، آن را ایجاد کنید. - ویژگی های ذکر شده در بالا را تنظیم کنید.
- ویرایش های خود را ذخیره کنید.
- پایگاه داده PostgreSQL را مجددا راه اندازی کنید:
> /<inst_root>/apigee/apigee-service/bin/apigee-service apigee-postgresql راه اندازی مجدد
jsvc
"jsvc" یک پیش نیاز برای استفاده از API BaaS است. نسخه 1.0.15-dev هنگام نصب API BaaS نصب می شود.
خدمات امنیت شبکه (NSS)
خدمات امنیت شبکه (NSS) مجموعه ای از کتابخانه ها است که از توسعه برنامه های کاربردی سرویس گیرنده و سرور با قابلیت امنیتی پشتیبانی می کند. باید مطمئن شوید که NSS نسخه 3.19 یا بالاتر را نصب کرده اید.
برای بررسی نسخه فعلی خود:
> yum info nss
برای به روز رسانی NSS:
> yum update nss
برای اطلاعات بیشتر به این مقاله از RedHat مراجعه کنید.
IPv6 را در Google Cloud Platform برای RedHat/CentOS 7 غیرفعال کنید
اگر Edge را روی RedHat 7 یا CentOS 7 در Google Cloud Platform نصب میکنید، باید IPv6 را در تمام گرههای Qpid غیرفعال کنید.
برای دستورالعمل های مربوط به غیرفعال کردن IPv6، به مستندات RedHat یا CentOS برای نسخه سیستم عامل خاص خود مراجعه کنید.
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 ارائه شده است استفاده می کند.
بیخیال | dirname | ls | دور در دقیقه | از حالت فشرده خارج کنید |
نام پایه | اکو | پرل | rpm2cpio | useradd |
ضربه شدید | expr | pgrep (از procps) | sed | WC |
قبل از میلاد | grep | ps | تار | خوشگل |
حلقه کردن | نام میزبان | pwd | tr | chkconfig |
تاریخ | شناسه | پایتون | unname | سودو |
توجه:
- فایل اجرایی ابزار 'useradd' در /usr/sbin و برای chkconfig در /sbin قرار دارد.
- با دسترسی sudo میتوانید به محیط کاربر تماسگیر دسترسی پیدا کنید، برای مثال، معمولاً « sudo <command> » یا « sudo PATH=$PATH:/usr/sbin:/sbin <command> » را فراخوانی میکنید.
- اطمینان حاصل کنید که ابزار "Patch" را قبل از نصب سرویس پک (پچ) نصب کرده اید.
ntpdate – توصیه می شود زمان سرورها را همگام سازی کنید. اگر قبلاً پیکربندی نشده باشد، ابزار 'ntpdate' میتواند این هدف را انجام دهد، که تأیید میکند آیا سرورها همزمان هستند یا خیر. برای نصب ابزار می توانید از " yum install ntp " استفاده کنید. این به ویژه برای تکرار تنظیمات OpenLDAP مفید است. توجه داشته باشید که منطقه زمانی سرور را در UTC تنظیم کرده اید.
openldap 2.4 – نصب در محل به OpenLDAP 2.4 نیاز دارد. اگر سرور شما اتصال اینترنت دارد، اسکریپت نصب Edge OpenLDAP را دانلود و نصب می کند. اگر سرور شما اتصال اینترنت ندارد، قبل از اجرای اسکریپت نصب Edge باید اطمینان حاصل کنید که OpenLDAP قبلاً نصب شده است. در RHEL/CentOS، میتوانید برای نصب OpenLDAP، « yum install openldap-clients openldap-servers » را اجرا کنید.
برای نصب 13 میزبان و نصب 12 میزبان با دو مرکز داده، شما نیاز به تکرار OpenLDAP دارید زیرا چندین گره میزبان OpenLDAP هستند.
فایروال ها و هاست های مجازی
اصطلاح "مجازی" معمولاً در عرصه فناوری اطلاعات بیش از حد بارگذاری می شود، و به همین ترتیب در مورد Apigee Edge برای استقرار Private Cloud و میزبان های مجازی نیز چنین است. برای روشن شدن، دو کاربرد اصلی از اصطلاح "مجازی" وجود دارد:
- ماشین های مجازی (VM) : لازم نیست، اما برخی از استقرارها از فناوری VM برای ایجاد سرورهای ایزوله برای اجزای Apigee خود استفاده می کنند. هاست های VM مانند هاست های فیزیکی می توانند دارای رابط های شبکه و فایروال باشند. این دستورالعمل های نصب به طور خاص از نصب VM پشتیبانی نمی کند.
- میزبان های مجازی : نقاط پایانی وب، مشابه میزبان مجازی آپاچی.
یک روتر در یک VM میتواند میزبانهای مجازی متعددی را در معرض نمایش بگذارد (تا زمانی که آنها در نام مستعار میزبان یا درگاه رابط خود با یکدیگر متفاوت باشند).
فقط به عنوان یک مثال نامگذاری، یک سرور فیزیکی واحد "A" ممکن است دو ماشین مجازی به نام های "VM1" و "VM2" را اجرا کند. بیایید فرض کنیم VM1 یک رابط اترنت مجازی را در معرض دید قرار می دهد که در داخل ماشین مجازی eth0 نامیده می شود و توسط ماشین مجازی سازی یا سرور DHCP شبکه به آدرس IP 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} and 111.111.111.222:80 ). علاوه بر این، سیستم عامل هر VM ممکن است فایروال خود را بر روی رابط 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 را با URL پایه /salesdemo مستقر کنید، کاربران با استفاده از http://api.mycompany.com:80/salesdemo به آن API دسترسی پیدا می کنند. اگر API mycompany خود را با URL پایه / مستقر کنید، کاربران شما از طریق URL http://api.mycompany.com:80/ به API دسترسی پیدا می کنند.
الزامات پورت لبه
نیاز به مدیریت فایروال فراتر از میزبان های مجازی است. هم فایروال های VM و هم فایروال هاست فیزیکی باید به ترافیک پورت های مورد نیاز اجزا اجازه دهند تا با یکدیگر ارتباط برقرار کنند.
تصویر زیر الزامات پورت ها را برای هر جزء Edge نشان می دهد:
نکات مربوط به این نمودار:
- *پورت 8082 در پردازشگر پیام فقط باید برای دسترسی روتر باز باشد که TLS/SSL را بین روتر و پردازشگر پیام پیکربندی کنید. اگر TLS/SSL را بین روتر و پردازشگر پیام پیکربندی نکنید، پیکربندی پیشفرض، پورت 8082 همچنان باید روی پردازشگر پیام باز باشد تا مؤلفه را مدیریت کند، اما روتر به دسترسی به آن نیاز ندارد.
- پورت های پیشوند "M" پورت هایی هستند که برای مدیریت کامپوننت استفاده می شوند و باید روی کامپوننت باز باشند و برای دسترسی سرور مدیریت باید روی کامپوننت باز باشند.
- اجزای زیر نیاز به دسترسی به پورت 8080 در سرور مدیریت دارند: روتر، پردازشگر پیام، رابط کاربری، Postgres و Qpid.
- یک پردازشگر پیام باید پورت 4528 را به عنوان پورت مدیریت خود باز کند. اگر چندین پردازشگر پیام دارید، همه آنها باید بتوانند از طریق پورت 4528 به یکدیگر دسترسی داشته باشند (که با فلش حلقه در نمودار بالا برای پورت 4528 در پردازشگر پیام نشان داده شده است). اگر چندین مرکز داده دارید، پورت باید از همه پردازشگرهای پیام در همه مراکز داده قابل دسترسی باشد.
- در حالی که نیازی به آن نیست، می توانید پورت 4527 روتر را برای دسترسی هر پردازشگر پیام باز کنید. در غیر این صورت، ممکن است پیامهای خطا را در فایلهای گزارش پردازشگر پیام مشاهده کنید.
- یک روتر باید پورت 4527 را به عنوان پورت مدیریت خود باز کند. اگر چندین روتر دارید، همه آنها باید بتوانند از طریق پورت 4527 به یکدیگر دسترسی داشته باشند (که با فلش حلقه در نمودار بالا برای پورت 4527 روی روتر نشان داده شده است).
- رابط کاربری Edge برای پشتیبانی از دکمه Send در ابزار ردیابی، نیاز به دسترسی به روتر، در پورتهایی دارد که توسط پراکسیهای API در معرض دید قرار میگیرند.
- سرور مدیریت نیاز به دسترسی به پورت JMX در گره های کاساندرا دارد.
- دسترسی به پورت های JMX را می توان طوری پیکربندی کرد که به نام کاربری/رمز عبور نیاز باشد. برای اطلاعات بیشتر به نحوه مانیتورینگ مراجعه کنید.
- شما می توانید به صورت اختیاری دسترسی TLS/SSL را برای اتصالات خاصی که می توانند از پورت های مختلف استفاده کنند، پیکربندی کنید. برای اطلاعات بیشتر به TLS/SSL مراجعه کنید.
- اگر دو گره Postgres را برای استفاده از replication master-standby پیکربندی کنید، باید پورت 22 را در هر گره برای دسترسی ssh باز کنید. شما می توانید به صورت اختیاری پورت ها را روی گره های جداگانه باز کنید تا امکان دسترسی به ssh فراهم شود.
- می توانید مدیریت سرور و رابط کاربری Edge را برای ارسال ایمیل از طریق یک سرور SMTP خارجی پیکربندی کنید. اگر این کار را انجام می دهید، باید اطمینان حاصل کنید که مدیریت سرور و UI می توانند به پورت لازم در سرور SMTP دسترسی داشته باشند. برای SMTP غیر TLS، شماره پورت معمولاً 25 است. برای SMTP با TLS فعال، اغلب 465 است، اما با ارائه دهنده SMTP خود تماس بگیرید.
جدول زیر نشان می دهد که پورت هایی که باید در فایروال ها باز شوند، توسط کامپوننت Edge:
جزء | بندر | توضیحات |
---|---|---|
پورت های استاندارد HTTP | 80، 443 | HTTP به علاوه هر پورت دیگری که برای هاست مجازی استفاده می کنید |
سرور مدیریت | 8080 | پورت تماسهای API مدیریت Edge. این اجزا به دسترسی به پورت 8080 در سرور مدیریت نیاز دارند: روتر، پردازشگر پیام، رابط کاربری، Postgres و Qpid. |
1099 | پورت JMX | |
4526 | برای حافظه پنهان توزیع شده و تماس های مدیریتی | |
رابط کاربری مدیریت | 9000 | پورت برای دسترسی مرورگر به رابط کاربری مدیریت |
پردازشگر پیام | 8998 | پورت پردازشگر پیام برای ارتباطات از روتر |
8082 | پورت مدیریت پیشفرض برای پردازشگر پیام است و برای دسترسی سرور مدیریت باید روی کامپوننت باز باشد. اگر TLS/SSL را بین روتر و پردازشگر پیام پیکربندی کنید، که توسط روتر برای بررسی سلامت روی پردازشگر پیام استفاده می شود. | |
1101 | پورت JMX | |
4528 | برای حافظه پنهان توزیع شده و تماس های مدیریتی بین پردازشگرهای پیام، و برای ارتباط از روتر | |
روتر | 8081 | پورت مدیریت پیشفرض برای روتر است و برای دسترسی سرور مدیریت باید روی کامپوننت باز باشد. |
4527 | برای حافظه پنهان توزیع شده و تماس های مدیریتی | |
15999 | بندر چک سلامت یک متعادل کننده بار از این پورت برای تعیین موجود بودن روتر استفاده می کند. برای به دست آوردن وضعیت روتر، متعادل کننده بار درخواست پورت 15999 روی روتر را می دهد: > curl -v http://<routerIP>:15999/v1/servers/self/reachable اگر روتر قابل دسترسی باشد، درخواست HTTP 200 را برمی گرداند. | |
باغ وحش | 2181 | توسط اجزای دیگر مانند مدیریت سرور، روتر، پردازشگر پیام و غیره استفاده می شود |
2888، 3888 | استفاده داخلی توسط ZooKeeper برای ارتباط خوشه ZooKeeper (معروف به ZooKeeper Ensemble) | |
کاساندرا | 7000، 9042، 9160 | پورت های آپاچی کاساندرا برای ارتباط بین گره های کاساندرا و برای دسترسی سایر اجزای Edge. |
7199 | پورت JMX باید برای دسترسی توسط سرور مدیریت باز باشد. | |
Qpid | 5672 | برای ارتباطات از روتر و پردازشگر پیام به سرور Qpid استفاده می شود |
8083 | پورت مدیریت پیشفرض روی سرور Qpid است و برای دسترسی سرور مدیریت باید روی کامپوننت باز باشد. | |
1102 | پورت JMX | |
4529 | برای حافظه پنهان توزیع شده و تماس های مدیریتی | |
Postgres | 5432 | برای ارتباط از سرور Qpid/Management به Postgres استفاده می شود |
8084 | پورت مدیریت پیشفرض در سرور Postgres و برای دسترسی سرور مدیریت باید روی کامپوننت باز باشد. | |
1103 | پورت JMX | |
4530 | برای حافظه پنهان توزیع شده و تماس های مدیریتی | |
22 | اگر دو گره Postgres را برای استفاده از replication master-standby پیکربندی کنید، باید پورت 22 را در هر گره برای دسترسی ssh باز کنید. | |
LDAP | 10389 | OpenLDAP |
SmartDocs | 59002 | پورت روتر Edge که در آن درخواست های صفحه SmartDocs ارسال می شود. |
توجه: علاوه بر این، ممکن است لازم باشد پورتهایی را در فایروالها برای آزمایش باز کنید. به عنوان مثال، 59001، و غیره. |
جدول بعدی همان پورت ها را نشان می دهد که به صورت عددی فهرست شده اند، همراه با اجزای مبدا و مقصد:
شماره پورت | هدف | جزء منبع | جزء مقصد |
---|---|---|---|
<پورت میزبان مجازی#> | HTTP به علاوه هر پورت دیگری که برای ترافیک تماس API میزبان مجازی استفاده می کنید. پورت های 80 و 443 بیشترین استفاده را دارند. مسیریاب پیام می تواند اتصالات TLS/SSL را خاتمه دهد. | مشتری خارجی (یا متعادل کننده بار) | شنونده در مسیریاب پیام |
1099 تا 1103 | مدیریت JMX | مشتری JMX | سرور مدیریت (1099) پردازشگر پیام (1101) سرور Qpid (1102) سرور Postgres (1103) |
2181 | ارتباط با مشتری باغ وحش | سرور مدیریت روتر پردازشگر پیام سرور Qpid سرور Postgres | نگهبان باغ وحش |
2888 و 3888 | مدیریت میانگره نگهبان باغ وحش | نگهبان باغ وحش | نگهبان باغ وحش |
4526 تا 4530 | پورت های مدیریت RPC برای حافظه نهان توزیع شده و تماس از سرورهای مدیریت به اجزای دیگر استفاده می شود | سرور مدیریت | سرور مدیریت (4526) روتر (4527) پردازشگر پیام (4528) سرور Qpid (4529) سرور Postgres (4530) |
4528 | برای تماس های حافظه پنهان توزیع شده بین پردازنده های پیام و برای ارتباط از روتر | روتر پردازشگر پیام | پردازشگر پیام |
5432 | مشتری Postgres | سرور Qpid | Postgres |
5672 | برای ارسال تجزیه و تحلیل از روتر و پردازشگر پیام به Qpid استفاده می شود | روتر پردازشگر پیام | سرور Qpid |
7000 | ارتباطات بین گره ای کاساندرا | کاساندرا | دیگر گره کاساندرا |
7199 | مدیریت JMX باید برای دسترسی به گره Cassandra توسط سرور مدیریت باز باشد. | مشتری JMX | کاساندرا |
8080 | پورت مدیریت API | مشتریان API مدیریت | سرور مدیریت |
8081 تا 8084 | پورت های کامپوننت API، برای صدور درخواست های API به طور مستقیم به اجزای جداگانه استفاده می شود. هر جزء پورت متفاوتی را باز می کند. پورت دقیق استفاده شده به پیکربندی بستگی دارد، اما برای دسترسی سرور مدیریت باید روی کامپوننت باز باشد | مشتریان API مدیریت | روتر (8081) پردازشگر پیام (8082) سرور Qpid (8083) سرور Postgres (8084) |
8998 | ارتباط بین روتر و پردازشگر پیام | روتر | پردازشگر پیام |
9000 | درگاه رابط کاربری پیش فرض مدیریت Edge | مرورگر | سرور UI مدیریت |
9042 | حمل و نقل بومی CQL | روتر پردازشگر پیام سرور مدیریت | کاساندرا |
9160 | مشتری صرفه جویی کاساندرا | روتر پردازشگر پیام سرور مدیریت | کاساندرا |
10389 | پورت LDAP | سرور مدیریت | OpenLDAP |
15999 | بندر چک سلامت یک متعادل کننده بار از این پورت برای تعیین موجود بودن روتر استفاده می کند. | متعادل کننده بار | روتر |
59002 | پورت روتر که در آن درخواست های صفحه SmartDocs ارسال می شود | SmartDocs | روتر |
یک پردازشگر پیام، یک استخر اتصال اختصاصی را برای Cassandra باز نگه میدارد، که به گونهای پیکربندی شده است که هرگز مهلت نداشته باشد. هنگامی که یک فایروال بین یک پردازشگر پیام و سرور Cassandra قرار دارد، فایروال می تواند زمان اتصال را متوقف کند. با این حال، پردازشگر پیام برای برقراری مجدد اتصالات به کاساندرا طراحی نشده است.
برای جلوگیری از این وضعیت، Apigee توصیه می کند که سرور Cassandra، پردازشگر پیام و روترها در یک زیر شبکه باشند تا یک فایروال در استقرار این مؤلفه ها دخالت نداشته باشد.
اگر یک فایروال بین روتر و پردازشگر پیام قرار دارد، و دارای زمان بندی بیکار tcp است، توصیه های ما این است:
- net.ipv4.tcp_keepalive_time = 1800 را در تنظیمات sysctl در سیستم عامل لینوکس تنظیم کنید، جایی که 1800 باید کمتر از مهلت زمانی idle tcp فایروال باشد. این تنظیم باید اتصال را در حالت ثابت نگه دارد تا فایروال اتصال را قطع نکند.
- در همه پردازشگرهای پیام، /<inst_root>/apigee/customer/application/message-processor.properties را ویرایش کنید تا ویژگی زیر را اضافه کنید. اگر فایل وجود ندارد، آن را ایجاد کنید.
conf_system_casssandra.maxconnecttimeinmillis=-1 - پردازشگر پیام را مجددا راه اندازی کنید:
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart - در همه روترها، /<inst_root>/apigee/customer/application/router.properties را ویرایش کنید تا ویژگی زیر را اضافه کنید. اگر فایل وجود ندارد، آن را ایجاد کنید.
conf_system_casssandra.maxconnecttimeinmillis=-1 - راه اندازی مجدد روتر:
> /opt/apigee/apigee-service/bin/apigee-service edge-router راه اندازی مجدد
اگر 12 پیکربندی خوشهبندی شده میزبان را با دو مرکز داده نصب میکنید، مطمئن شوید که گرهها در دو مرکز داده میتوانند از طریق پورتهای نشان داده شده در زیر ارتباط برقرار کنند:
الزامات پورت API BaaS
اگر تصمیم به نصب API BaaS دارید، API BaaS Stack و API BaaS Portal را اضافه میکنید. این قطعات از پورت های نشان داده شده در شکل زیر استفاده می کنند:
نکات مربوط به این نمودار:
- پورتال API BaaS هرگز مستقیماً به یک گره پشته BaaS درخواست نمی کند. هنگامی که یک توسعه دهنده وارد پورتال می شود، برنامه پورتال در مرورگر دانلود می شود. برنامه Portal که در مرورگر اجرا می شود، سپس به گره های پشته BaaS درخواست می کند.
- یک نصب تولیدی API BaaS از یک متعادل کننده بار بین گره پورتال API BaaS و گره های API BaaS Stack استفاده می کند. هنگام پیکربندی پورتال، و هنگام برقراری تماس های BaaS API، آدرس IP یا نام DNS متعادل کننده بار را مشخص می کنید، نه گره های Stack.
- شما باید تمام گره های Baas Stack را برای ارسال ایمیل از طریق یک سرور SMTP خارجی پیکربندی کنید. برای SMTP غیر TLS، شماره پورت معمولاً 25 است. برای SMTP با TLS فعال، اغلب 465 است، اما با ارائه دهنده SMTP خود تماس بگیرید.
- گره های Cassandra را می توان به API BaaS اختصاص داد، یا می توان با Edge به اشتراک گذاشت.
جدول زیر پورت های پیش فرضی را که باید در فایروال ها باز شوند، به تفکیک جزء نشان می دهد:
جزء | بندر | توضیحات |
---|---|---|
پورتال API BaaS | 9000 | پورت برای رابط کاربری API BaaS |
پشته API BaaS | 8080 | درگاهی که درخواست API دریافت می شود |
ElasticSearch | 9200 تا 9400 | برای برقراری ارتباط با API BaaS Stack و برای برقراری ارتباط بین گره های ElasticSearch |
صدور مجوز
هر نصب Edge به یک فایل مجوز منحصر به فرد نیاز دارد که از Apigee دریافت می کنید. هنگام نصب سرور مدیریت باید مسیر فایل لایسنس را برای مثال /tmp/license.txt ارائه دهید.
نصب کننده فایل مجوز را در /<inst_root>/apigee/customer/conf/license.txt کپی می کند.
اگر فایل مجوز معتبر باشد، سرور مدیریت تعداد انقضا و مجاز پردازشگر پیام (MP) را تأیید می کند. اگر هر یک از تنظیمات مجوز منقضی شده است، می توانید گزارش ها را در مکان زیر پیدا کنید: /<inst_root>/apigee/var/log/edge-management-server/logs . در این صورت می توانید برای جزئیات مهاجرت با پشتیبانی Apigee تماس بگیرید.