ข้อกําหนดในการติดตั้ง

Edge for Private Cloud เวอร์ชัน 4.16.05

ข้อกำหนดเกี่ยวกับฮาร์ดแวร์

คุณต้องมีคุณสมบัติตรงตามข้อกำหนดขั้นต่ำสำหรับฮาร์ดแวร์ต่อไปนี้สำหรับโครงสร้างพื้นฐานที่มีความพร้อมใช้งานสูงในสภาพแวดล้อมระดับเวอร์ชันที่ใช้งานจริง สำหรับสถานการณ์การติดตั้งทั้งหมดที่อธิบายไว้ในโทโพโลยีการติดตั้ง ตารางต่อไปนี้จะแสดงข้อกำหนดฮาร์ดแวร์ขั้นต่ำสำหรับคอมโพเนนต์การติดตั้ง

ในตารางเหล่านี้ ข้อกำหนดของฮาร์ดดิสก์จะเพิ่มจากพื้นที่ในฮาร์ดดิสก์ที่ระบบปฏิบัติการต้องการ การติดตั้งอาจต้องใช้ทรัพยากรมากกว่าหรือน้อยกว่าที่ระบุไว้ด้านล่าง ทั้งนี้ขึ้นอยู่กับแอปพลิเคชันและการจราจรของข้อมูลในเครือข่าย

คอมโพเนนต์การติดตั้ง

RAM

CPU

ฮาร์ดดิสก์ขั้นต่ำ

Cassandra

16 GB

8 คอร์

พื้นที่เก็บข้อมูลในเครื่อง 250 GB พร้อม SSD หรือ HDD ความเร็วสูงที่รองรับ 2,000 IOPS

Message Processor/เราเตอร์ในเครื่องเดียวกัน

8/16GB

4 คอร์†

100 GB

Analytics - Postgres/Qpid บนเซิร์ฟเวอร์เดียวกัน (ไม่แนะนำสำหรับเวอร์ชันที่ใช้งานจริง)

16GB*

8 คอร์*

พื้นที่เก็บข้อมูลเครือข่าย*** 500 GB - 1 TB** โดยควรมีแบ็กเอนด์ SSD ที่รองรับ 1000 IOPS ขึ้นไป*

Analytics - Postgres แบบสแตนด์อโลน

16GB*

8 คอร์*

พื้นที่เก็บข้อมูลเครือข่าย*** 500 GB - 1 TB** โดยควรมีแบ็กเอนด์ SSD ที่รองรับ 1000 IOPS ขึ้นไป*

Analytics - Qpid standalone

8GB

4 คอร์

พื้นที่เก็บข้อมูลในเครื่อง 30 GB - 50 GB พร้อม SSD หรือ HDD ความเร็วสูง

สำหรับการติดตั้งที่มากกว่า 250 TPS เราขอแนะนำให้ใช้ HDD ที่มีพื้นที่เก็บข้อมูลในเครื่องที่รองรับ 1, 000 IOPS

อื่นๆ (OpenLDAP, UI, เซิร์ฟเวอร์การจัดการ)

4 GB

2 คอร์

60GB

† ปรับข้อกำหนดของระบบ Message Processor ตามอัตราการส่งผ่านข้อมูล ดังนี้

เราขอแนะนำให้ใช้ขั้นต่ำ 4 คอร์ และ 8 คอร์สำหรับระบบที่มีการส่งข้อความปริมาณมาก คุณสามารถทำการทดสอบประสิทธิภาพเพื่อระบุขนาดที่เหมาะสมที่สุดสำหรับ API ของคุณได้

*ปรับข้อกำหนดของระบบ Postgres ตามอัตราการส่งผ่านข้อมูล ดังนี้

  • น้อยกว่า 250 TPS: 8 GB, 4 คอร์สามารถพิจารณาใช้กับพื้นที่เก็บข้อมูลเครือข่ายที่มีการจัดการ*** ซึ่งรองรับ 1,000 IOPS ขึ้นไป
  • มากกว่า 250 TPS: 16 GB, 8 คอร์, พื้นที่เก็บข้อมูลเครือข่ายที่มีการจัดการ*** รองรับ 1,000 IOPS ขึ้นไป
  • มากกว่า 1000 TPS: 16 GB, 8 คอร์, พื้นที่เก็บข้อมูลเครือข่ายที่มีการจัดการ*** รองรับ 2000 IOPS ขึ้นไป
  • มากกว่า 2,000 TPS: 32 GB, 16 คอร์, พื้นที่เก็บข้อมูลเครือข่ายที่มีการจัดการ*** ที่รองรับ 2,000 IOPS ขึ้นไป
  • มากกว่า 4,000 TPS: 64 GB, 32 คอร์, พื้นที่เก็บข้อมูลเครือข่ายที่มีการจัดการ*** รองรับ 4,000 IOPS ขึ้นไป

**ค่าฮาร์ดดิสก์ Postgres อิงตามข้อมูลวิเคราะห์ที่พร้อมใช้งานทันทีซึ่ง Edge บันทึกไว้ หากคุณเพิ่มค่าที่กำหนดเองลงในข้อมูลการวิเคราะห์ ควรเพิ่มค่าเหล่านี้ตามความเหมาะสม ใช้สูตรต่อไปนี้เพื่อประมาณพื้นที่เก็บข้อมูลที่จำเป็น

(จำนวนไบต์/คำขอ) * (คำขอต่อวินาที) * (วินาทีต่อชั่วโมง) * (ชั่วโมงที่มีการใช้งานสูงสุดต่อวัน) * (วันต่อเดือน) * (เดือนที่เก็บรักษาข้อมูล) = ไบต์ของพื้นที่เก็บข้อมูลที่จำเป็น

ตัวอย่างเช่น

(ข้อมูลวิเคราะห์ 2,000 ไบต์ต่อคำขอ) * 100 คำขอ/วินาที * 3,600 วินาที/ชั่วโมง * การใช้งานสูงสุด 18 ชั่วโมงต่อวัน * 30 วัน/เดือน * การเก็บรักษาข้อมูล 3 เดือน = 1,194,393,600,000 ไบต์หรือ 1194.4 GB

*** ขอแนะนำให้ใช้พื้นที่เก็บข้อมูลเครือข่ายสำหรับฐานข้อมูล Postgresql เนื่องจากสาเหตุต่อไปนี้

  • ซึ่งจะช่วยให้สามารถปรับขนาดพื้นที่เก็บข้อมูลแบบไดนามิกได้เมื่อจำเป็น
  • IOPS ของเครือข่ายสามารถปรับได้ทันทีในระบบย่อยของสภาพแวดล้อม/พื้นที่เก็บข้อมูล/เครือข่ายส่วนใหญ่ในปัจจุบัน
  • คุณสามารถเปิดใช้สแนปชอตระดับพื้นที่เก็บข้อมูลเป็นส่วนหนึ่งของโซลูชันการสำรองข้อมูลและการกู้คืนได้

นอกจากนี้ รายการต่อไปนี้แสดงข้อกำหนดด้านฮาร์ดแวร์หากคุณต้องการติดตั้งบริการการสร้างรายได้

องค์ประกอบที่มีการสร้างรายได้

RAM

CPU

ฮาร์ดดิสก์

เซิร์ฟเวอร์การจัดการ (พร้อมบริการการสร้างรายได้)

8GB

4 คอร์

60GB

Analytics - Postgres/Qpid บนเซิร์ฟเวอร์เดียวกัน

16 GB

8 คอร์

พื้นที่เก็บข้อมูลเครือข่าย 500 GB - 1 TB โดยควรใช้แบ็กเอนด์ SSD ที่รองรับ IOPS ตั้งแต่ 1,000 ขึ้นไป หรือใช้กฎจากตารางด้านบน

Analytics - Postgres แบบสแตนด์อโลน

16 GB

8 คอร์

พื้นที่เก็บข้อมูลเครือข่าย 500 GB - 1 TB โดยควรใช้แบ็กเอนด์ SSD ที่รองรับ IOPS ตั้งแต่ 1,000 ขึ้นไป หรือใช้กฎจากตารางด้านบน

Analytics - Qpid standalone

8GB

4 คอร์

40GB

รายการต่อไปนี้แสดงข้อกำหนดด้านฮาร์ดแวร์หากคุณต้องการติดตั้ง API BaaS

คอมโพเนนต์ API BaaS

RAM

CPU

ฮาร์ดดิสก์

ElasticSearch*

8GB

4 คอร์

60 - 80GB

API BaaS Stack *

8GB

4 คอร์

60 - 80GB

พอร์ทัล API BaaS

1GB

2 คอร์

20GB

Cassandra (ไม่บังคับ โดยทั่วไปคุณจะใช้คลัสเตอร์ Cassandra เดียวกันสำหรับทั้งบริการ Edge และ API BaaS)

16 GB

8 คอร์

พื้นที่เก็บข้อมูลในเครื่อง 250 GB พร้อม SSD หรือ HDD ความเร็วสูงที่รองรับ 2,000 IOPS

* คุณสามารถติดตั้ง ElasticSearch และ API BaaS Stack ในโหนดเดียวกันได้ หากใช้ ให้กำหนดค่า ElasticSearch ให้ใช้หน่วยความจำ 4 GB (ค่าเริ่มต้น) หากติดตั้ง ElasticSearch ในโหนดของตัวเอง ให้กำหนดค่าให้ใช้หน่วยความจำ 6 GB

หมายเหตุ

  • หากระบบไฟล์รูทมีขนาดไม่ใหญ่พอสำหรับการติดตั้ง ขอแนะนำให้วางข้อมูลลงในดิสก์ขนาดใหญ่ขึ้น
  • หากมีการติดตั้ง Apigee Edge สำหรับ 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 โดยค่าเริ่มต้น

Java

คุณต้องติดตั้ง 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 สำหรับ Private Cloud แล้ว คุณสามารถตรวจสอบว่ากำหนดค่า Cassandra อย่างถูกต้องหรือไม่โดยตรวจสอบไฟล์ /<inst_root>/apigee/apigee-cassandra/conf/cassandra.yaml ตัวอย่างเช่น ตรวจสอบว่าสคริปต์การติดตั้ง Edge สำหรับ 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 /<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)

Network Security Services (NSS) คือชุดไลบรารีที่รองรับการพัฒนาแอปพลิเคชันไคลเอ็นต์และเซิร์ฟเวอร์ที่เปิดใช้การรักษาความปลอดภัยของเครือข่าย คุณควรตรวจสอบว่าได้ติดตั้ง NSS v3.19 ขึ้นไปแล้ว

วิธีตรวจสอบเวอร์ชันปัจจุบัน

> yum info nss

วิธีอัปเดต NSS

> yum update nss

ดูข้อมูลเพิ่มเติมได้ในบทความนี้จาก RedHat

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 มีให้

awk

dirname

ls

rpm

แตกไฟล์

basename

echo

perl

rpm2cpio

useradd

bash

expr

pgrep (จาก procps)

sed

wc

bc

grep

ps

tar

อร่อย

curl

hostname

pwd

tr

chkconfig

วันที่

id

python

uname

sudo

หมายเหตุ:

  • ไฟล์ปฏิบัติการสำหรับเครื่องมือ "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 - การติดตั้งภายในองค์กรต้องใช้ OpenLDAP 2.4 หากเซิร์ฟเวอร์มีการเชื่อมต่ออินเทอร์เน็ต สคริปต์การติดตั้ง Edge จะดาวน์โหลดและติดตั้ง OpenLDAP หากเซิร์ฟเวอร์ไม่มีการเชื่อมต่ออินเทอร์เน็ต คุณต้องตรวจสอบว่าได้ติดตั้ง OpenLDAP แล้วก่อนที่จะเรียกใช้สคริปต์การติดตั้ง Edge ใน RHEL/CentOS คุณสามารถเรียกใช้ "yum install openldap-clients openldap-servers" เพื่อติดตั้ง OpenLDAP

สำหรับการติดตั้งโฮสต์ 13 รายการและการติดตั้งโฮสต์ 12 รายการที่มีศูนย์ข้อมูล 2 แห่ง คุณต้องมีการจำลอง OpenLDAP เนื่องจากมีโหนดหลายโหนดที่โฮสต์ OpenLDAP

ไฟร์วอลล์และโฮสต์เสมือน

คำว่า "เสมือน" มักจะถูกใช้มากเกินไปในแวดวงไอที และก็เป็นเช่นนั้นกับการติดตั้งใช้งาน Apigee Edge สำหรับ Private Cloud และโฮสต์เสมือน เพื่อให้ชัดเจน คำว่า "เสมือน" มีการใช้งานหลักๆ 2 แบบดังนี้

  • เครื่องเสมือน (VM): ไม่จำเป็น แต่การติดตั้งใช้งานบางอย่างใช้เทคโนโลยี VM เพื่อสร้างเซิร์ฟเวอร์แยกต่างหากสำหรับคอมโพเนนต์ Apigee โฮสต์ VM เช่น โฮสต์จริง อาจมีอินเทอร์เฟซเครือข่ายและไฟร์วอลล์ วิธีการติดตั้งเหล่านี้ไม่รองรับการติดตั้ง VM โดยเฉพาะ
  • โฮสต์เสมือน: อุปกรณ์ปลายทางบนเว็บ ซึ่งคล้ายกับโฮสต์เสมือนของ Apache

เราเตอร์ใน VM สามารถแสดงโฮสต์เสมือนหลายรายการได้ (ตราบใดที่โฮสต์เสมือนเหล่านั้นแตกต่างกันในชื่อแทนโฮสต์หรือในพอร์ตอินเทอร์เฟซ)

ตัวอย่างการตั้งชื่อ เช่น เซิร์ฟเวอร์จริง "A" เครื่องเดียวอาจเรียกใช้ VM 2 รายการชื่อ "VM1" และ "VM2" สมมติว่า VM1 แสดงอินเทอร์เฟซอีเทอร์เน็ตเสมือนซึ่งมีชื่อว่า eth0 ภายใน VM และได้รับมอบหมายที่อยู่ IP 111.111.111.111 โดยเครื่องจักรการจำลองเสมือนหรือเซิร์ฟเวอร์ DHCP ของเครือข่าย จากนั้นสมมติว่า VM2 แสดงอินเทอร์เฟซอีเทอร์เน็ตเสมือนชื่อ eth0 ด้วย และได้รับมอบหมายที่อยู่ IP 111.111.111.222

เราอาจมีเราเตอร์ Apigee ที่ทำงานอยู่ใน VM ทั้ง 2 เครื่อง เราเตอร์จะแสดงปลายทางโฮสต์เสมือนดังตัวอย่างสมมติต่อไปนี้

เราเตอร์ Apigee ใน VM1 แสดงโฮสต์เสมือน 3 รายการในอินเทอร์เฟซ 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) นอกจากนี้ ระบบปฏิบัติการของ VM แต่ละเครื่องอาจมีไฟร์วอลล์ของตัวเองในอินเทอร์เฟซ eth0 และไฟร์วอลล์เหล่านี้ต้องอนุญาตให้พอร์ต 80 และ 443 เชื่อมต่อด้วย

เส้นทางฐานเป็นองค์ประกอบที่ 3 ที่เกี่ยวข้องกับการกำหนดเส้นทางการเรียก API ไปยังพร็อกซี API ต่างๆ ที่คุณอาจติดตั้งใช้งาน แพ็กเกจพร็อกซี API สามารถแชร์ปลายทางได้หากมีเส้นทางฐานที่แตกต่างกัน เช่น คุณสามารถกำหนดเส้นทางฐานหนึ่งเป็น http://api.mycompany.com:80/ และอีกเส้นทางหนึ่งเป็น http://api.mycompany.com:80/salesdemo

ในกรณีนี้ คุณต้องมีตัวจัดสรรภาระงานหรือตัวควบคุมการรับส่งข้อมูลบางประเภทที่แยกการรับส่งข้อมูล http://api.mycompany.com:80/ ระหว่างที่อยู่ IP 2 รายการ (111.111.111.111 ใน VM1 และ 111.111.111.222 ใน VM2) ฟังก์ชันนี้มีไว้สำหรับการติดตั้งของคุณโดยเฉพาะ และกำหนดค่าโดยกลุ่มเครือข่ายในพื้นที่ของคุณ

ระบบจะตั้งค่าเส้นทางฐานเมื่อคุณติดตั้งใช้งาน API จากตัวอย่างข้างต้น คุณสามารถติดตั้งใช้งาน API 2 รายการ ได้แก่ mycompany และ testmycompany สำหรับองค์กร mycompany-org ที่มีโฮสต์เสมือนซึ่งมีชื่อแทนโฮสต์เป็น api.mycompany.com และตั้งค่าพอร์ตเป็น 80 หากคุณไม่ได้ประกาศ basepath ในการติดตั้งใช้งาน เราเตอร์จะไม่ทราบว่าต้องส่งคำขอขาเข้าไปยัง API ใด

อย่างไรก็ตาม หากคุณติดตั้งใช้งาน API testmycompany ด้วย URL ฐาน /salesdemo ผู้ใช้จะเข้าถึง API นั้นโดยใช้ http://api.mycompany.com:80/salesdemo หากคุณทำให้ API mycompany ใช้งานได้ด้วย URL ฐานเป็น / ผู้ใช้จะเข้าถึง API ได้โดยใช้ URL http://api.mycompany.com:80/

ข้อกำหนดของพอร์ต Edge

ความจำเป็นในการจัดการไฟร์วอลล์ไม่ได้จำกัดอยู่เพียงโฮสต์เสมือนเท่านั้น ทั้งไฟร์วอลล์ VM และไฟร์วอลล์โฮสต์จริงต้องอนุญาตให้มีการรับส่งข้อมูลสำหรับพอร์ตที่คอมโพเนนต์ต้องใช้เพื่อสื่อสารกัน

รูปภาพต่อไปนี้แสดงข้อกำหนดพอร์ตสำหรับคอมโพเนนต์ Edge แต่ละรายการ

หมายเหตุเกี่ยวกับแผนภาพนี้

  • *พอร์ต 8082 ใน Message Processor ต้องเปิดไว้เพื่อให้เราเตอร์เข้าถึงได้เมื่อคุณกำหนดค่า TLS/SSL ระหว่างเราเตอร์กับ Message Processor เท่านั้น หากคุณไม่ได้กำหนดค่า TLS/SSL ระหว่างเราเตอร์กับ Message Processor การกำหนดค่าเริ่มต้น พอร์ต 8082 จะยังคงต้องเปิดอยู่ใน Message Processor เพื่อจัดการคอมโพเนนต์ แต่เราเตอร์ไม่จำเป็นต้องเข้าถึงพอร์ตดังกล่าว
  • พอร์ตที่มีคำนำหน้าว่า "M" คือพอร์ตที่ใช้จัดการคอมโพเนนต์และต้องเปิดในคอมโพเนนต์เพื่อให้เซิร์ฟเวอร์การจัดการเข้าถึงได้
  • คอมโพเนนต์ต่อไปนี้ต้องมีสิทธิ์เข้าถึงพอร์ต 8080 ในเซิร์ฟเวอร์การจัดการ ได้แก่ เราเตอร์, Message Processor, UI, Postgres และ Qpid
  • Message Processor ต้องเปิดพอร์ต 4528 เป็นพอร์ตการจัดการ หากคุณมี Message Processor หลายรายการ ทั้งหมดจะต้องเข้าถึงกันและกันได้ผ่านพอร์ต 4528 (ระบุด้วยลูกศรวนซ้ำในแผนภาพด้านบนสำหรับพอร์ต 4528 ใน Message Processor) หากคุณมีศูนย์ข้อมูลหลายแห่ง พอร์ตจะต้องเข้าถึงได้จาก Message Processor ทั้งหมดในศูนย์ข้อมูลทุกแห่ง
  • แม้ว่าจะไม่จำเป็น แต่คุณสามารถเปิดพอร์ต 4527 บนเราเตอร์เพื่อให้ Message Processor เข้าถึงได้ ไม่เช่นนั้น คุณอาจเห็นข้อความแสดงข้อผิดพลาดในไฟล์บันทึกของ Message Processor
  • เราเตอร์ต้องเปิดพอร์ต 4527 เป็นพอร์ตการจัดการ หากคุณมีเราเตอร์หลายตัว เราเตอร์ทั้งหมดต้องเข้าถึงกันและกันได้ผ่านพอร์ต 4527 (ระบุด้วยลูกศรวนซ้ำในแผนภาพด้านบนสำหรับพอร์ต 4527 บนเราเตอร์)
  • Edge UI ต้องเข้าถึงเราเตอร์ในพอร์ตที่แสดงโดยพร็อกซี API เพื่อรองรับปุ่มส่งในเครื่องมือติดตาม
  • เซิร์ฟเวอร์การจัดการต้องมีสิทธิ์เข้าถึงพอร์ต JMX ในโหนด Cassandra
  • คุณสามารถกำหนดค่าการเข้าถึงพอร์ต JMX ให้ต้องใช้ชื่อผู้ใช้/รหัสผ่านได้ ดูข้อมูลเพิ่มเติมได้ที่วิธีตรวจสอบ
  • คุณสามารถกำหนดค่าการเข้าถึง TLS/SSL สำหรับการเชื่อมต่อบางรายการซึ่งใช้พอร์ตที่แตกต่างกันได้ (ไม่บังคับ) ดูข้อมูลเพิ่มเติมได้ที่ TLS/SSL
  • หากกำหนดค่าโหนด Postgres 2 โหนดเพื่อใช้การจำลองแบบ Master-Standby คุณต้องเปิดพอร์ต 22 ในแต่ละโหนดสำหรับการเข้าถึง SSH คุณสามารถเลือกเปิดพอร์ตในแต่ละโหนดเพื่ออนุญาตการเข้าถึง SSH ได้
  • คุณสามารถกำหนดค่าเซิร์ฟเวอร์การจัดการและ Edge UI ให้ส่งอีเมลผ่านเซิร์ฟเวอร์ SMTP ภายนอกได้ หากใช้ คุณต้องตรวจสอบว่าเซิร์ฟเวอร์การจัดการและ UI สามารถเข้าถึงพอร์ตที่จำเป็นในเซิร์ฟเวอร์ SMTP ได้ สำหรับ SMTP ที่ไม่ใช่ TLS หมายเลขพอร์ตมักจะเป็น 25 สำหรับ SMTP ที่เปิดใช้ TLS มักจะเป็น 465 แต่โปรดตรวจสอบกับผู้ให้บริการ SMTP ของคุณ

ตารางด้านล่างแสดงพอร์ตที่ต้องเปิดในไฟร์วอลล์ตามคอมโพเนนต์ Edge

คอมโพเนนต์

พอร์ต

คำอธิบาย

พอร์ต HTTP มาตรฐาน

80, 443

HTTP และพอร์ตอื่นๆ ที่คุณใช้สำหรับโฮสต์เสมือน

เซิร์ฟเวอร์การจัดการ

8080

พอร์ตสำหรับการเรียก API การจัดการ Edge คอมโพเนนต์เหล่านี้ต้องมีสิทธิ์เข้าถึงพอร์ต 8080 ในเซิร์ฟเวอร์การจัดการ ได้แก่ เราเตอร์, Message Processor, UI, Postgres และ Qpid

1099

พอร์ต JMX

4526

สำหรับการเรียกใช้แคชและการจัดการแบบกระจาย

UI การจัดการ

9000

พอร์ตสำหรับการเข้าถึง UI การจัดการของเบราว์เซอร์

Message Processor

8998

พอร์ต Message Processor สำหรับการสื่อสารจากเราเตอร์

8082

พอร์ตการจัดการเริ่มต้นสำหรับ Message Processor และต้องเปิดอยู่ในคอมโพเนนต์เพื่อให้ Management Server เข้าถึงได้

หากคุณกำหนดค่า TLS/SSL ระหว่างเราเตอร์และ Message Processor เราเตอร์จะใช้เพื่อตรวจสอบประสิทธิภาพการทำงานใน Message Processor

1101

พอร์ต JMX

4528

สำหรับการเรียกใช้แคชและการจัดการแบบกระจายระหว่าง Message Processor และสำหรับการสื่อสารจากเราเตอร์

เราเตอร์

8081

พอร์ตการจัดการเริ่มต้นสำหรับเราเตอร์และต้องเปิดในคอมโพเนนต์เพื่อให้เซิร์ฟเวอร์การจัดการเข้าถึงได้

4527

สำหรับการเรียกใช้แคชและการจัดการแบบกระจาย

15999

พอร์ตการตรวจสอบประสิทธิภาพการทำงาน ตัวจัดสรรภาระงานจะใช้พอร์ตนี้เพื่อพิจารณาว่าเราเตอร์พร้อมใช้งานหรือไม่

หากต้องการดูสถานะของเราเตอร์ ตัวจัดสรรภาระงานจะส่งคำขอไปยังพอร์ต 15999 บนเราเตอร์ ดังนี้

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

หากเข้าถึงเราเตอร์ได้ คำขอจะแสดงผล HTTP 200

ZooKeeper

2181

ใช้โดยคอมโพเนนต์อื่นๆ เช่น Management Server, Router, Message Processor และอื่นๆ

2888, 3888

ใช้ภายในโดย ZooKeeper สำหรับการสื่อสารคลัสเตอร์ ZooKeeper (เรียกว่า ZooKeeper ensemble)

Cassandra

7000, 9042, 9160

พอร์ต Apache Cassandra สำหรับการสื่อสารระหว่างโหนด Cassandra และสำหรับการเข้าถึงโดยคอมโพเนนต์ Edge อื่นๆ

7199

พอร์ต JMX ต้องเปิดให้เซิร์ฟเวอร์การจัดการเข้าถึงได้

Qpid

5672

ใช้สำหรับการสื่อสารจากเราเตอร์และ Message Processor ไปยังเซิร์ฟเวอร์ Qpid

8083

พอร์ตการจัดการเริ่มต้นบนเซิร์ฟเวอร์ Qpid และต้องเปิดในคอมโพเนนต์เพื่อให้ Management Server เข้าถึงได้

1102

พอร์ต JMX

4529

สำหรับการเรียกใช้แคชและการจัดการแบบกระจาย

Postgres

5432

ใช้สำหรับการสื่อสารจาก Qpid/เซิร์ฟเวอร์การจัดการไปยัง Postgres

8084

พอร์ตการจัดการเริ่มต้นบนเซิร์ฟเวอร์ Postgres และต้องเปิดในคอมโพเนนต์เพื่อให้เซิร์ฟเวอร์การจัดการเข้าถึงได้

1103

พอร์ต JMX

4530

สำหรับการเรียกใช้แคชและการจัดการแบบกระจาย

22

หากกำหนดค่าโหนด Postgres 2 โหนดเพื่อใช้การจำลองแบบ Master-Standby คุณต้องเปิดพอร์ต 22 ในแต่ละโหนดสำหรับการเข้าถึง SSH

LDAP

10389

OpenLDAP

SmartDocs

59002

พอร์ตบนเราเตอร์ Edge ที่ส่งคำขอหน้า SmartDocs

หมายเหตุ: นอกจากนี้ คุณอาจต้องเปิดพอร์ตในไฟร์วอลล์เพื่อทำการทดสอบ เช่น 59001 เป็นต้น

ตารางถัดไปแสดงพอร์ตเดียวกัน โดยแสดงตามตัวเลข พร้อมด้วยคอมโพเนนต์ต้นทางและปลายทาง

หมายเลขพอร์ต

วัตถุประสงค์

คอมโพเนนต์ต้นทาง

คอมโพเนนต์ปลายทาง

<virtual host port#>

HTTP และพอร์ตอื่นๆ ที่คุณใช้สำหรับการเข้าชมการเรียก API ของโฮสต์เสมือน พอร์ต 80 และ 443 เป็นพอร์ตที่ใช้กันโดยทั่วไป โดย Message Router สามารถสิ้นสุดการเชื่อมต่อ TLS/SSL ได้

ไคลเอ็นต์ภายนอก (หรือตัวจัดสรรภาระงาน)

Listener ในเราเตอร์ข้อความ

1099 ถึง 1103

การจัดการ JMX

ไคลเอ็นต์ JMX

เซิร์ฟเวอร์การจัดการ (1099)

Message Processor (1101)

เซิร์ฟเวอร์ Qpid (1102)

เซิร์ฟเวอร์ Postgres (1103)

2181

การสื่อสารของไคลเอ็นต์ Zookeeper

เซิร์ฟเวอร์การจัดการ

เราเตอร์

Message Processor

เซิร์ฟเวอร์ Qpid

เซิร์ฟเวอร์ Postgres

ผู้ดูแลสวนสัตว์

2888 และ 3888

การจัดการโหนดภายในของ Zookeeper

ผู้ดูแลสวนสัตว์

ผู้ดูแลสวนสัตว์

4526 ถึง 4530

พอร์ตการจัดการ RPC ที่ใช้สำหรับแคชแบบกระจายและการเรียกจากเซิร์ฟเวอร์การจัดการไปยังคอมโพเนนต์อื่นๆ

เซิร์ฟเวอร์การจัดการ

เซิร์ฟเวอร์การจัดการ (4526)

เราเตอร์ (4527)

Message Processor (4528)

เซิร์ฟเวอร์ Qpid (4529)

เซิร์ฟเวอร์ Postgres (4530)

4528

สำหรับการเรียกใช้แคชแบบกระจายระหว่าง Message Processor และสำหรับการสื่อสารจากเราเตอร์

เราเตอร์

Message Processor

Message Processor

5432

ไคลเอ็นต์ Postgres

เซิร์ฟเวอร์ Qpid

Postgres

5672

ใช้สำหรับส่งข้อมูลวิเคราะห์จากเราเตอร์และ Message Processor ไปยัง Qpid

เราเตอร์

Message Processor

เซิร์ฟเวอร์ Qpid

7000

การสื่อสารระหว่างโหนดของ Cassandra

Cassandra

โหนด Cassandra อื่นๆ

7199

การจัดการ JMX ต้องเปิดให้เข้าถึงในโหนด Cassandra โดยเซิร์ฟเวอร์การจัดการ

ไคลเอ็นต์ JMX

Cassandra

8080

พอร์ต Management API

ไคลเอ็นต์ Management API

เซิร์ฟเวอร์การจัดการ

8081 ถึง 8084

พอร์ต API ของคอมโพเนนต์ ซึ่งใช้สำหรับส่งคำขอ API ไปยังคอมโพเนนต์แต่ละรายการโดยตรง แต่ละคอมโพเนนต์จะเปิดพอร์ตที่แตกต่างกัน โดยพอร์ตที่ใช้จริงจะขึ้นอยู่กับการกำหนดค่า แต่ต้องเปิดในคอมโพเนนต์เพื่อให้เซิร์ฟเวอร์การจัดการเข้าถึงได้

ไคลเอ็นต์ Management API

เราเตอร์ (8081)

Message Processor (8082)

เซิร์ฟเวอร์ Qpid (8083)

เซิร์ฟเวอร์ Postgres (8084)

8998

การสื่อสารระหว่างเราเตอร์กับ Message Processor

เราเตอร์

Message Processor

9000

พอร์ต UI การจัดการ Edge เริ่มต้น

เบราว์เซอร์

เซิร์ฟเวอร์ UI การจัดการ

9042

การส่งข้อมูลแบบเนทีฟของ CQL

เราเตอร์

Message Processor

เซิร์ฟเวอร์การจัดการ

Cassandra

9160

ไคลเอ็นต์ Cassandra Thrift

เราเตอร์

Message Processor

เซิร์ฟเวอร์การจัดการ

Cassandra

10389

พอร์ต LDAP

เซิร์ฟเวอร์การจัดการ

OpenLDAP

15999 พอร์ตการตรวจสอบประสิทธิภาพการทำงาน ตัวจัดสรรภาระงานจะใช้พอร์ตนี้เพื่อพิจารณาว่าเราเตอร์พร้อมใช้งานหรือไม่ ตัวจัดสรรภาระงาน เราเตอร์

59002

พอร์ตเราเตอร์ที่ส่งคำขอหน้าเว็บ SmartDocs

SmartDocs

เราเตอร์

Message Processor จะเปิดพูลการเชื่อมต่อเฉพาะไว้สำหรับ Cassandra ซึ่งกำหนดค่าไว้ไม่ให้หมดเวลา เมื่อไฟร์วอลล์อยู่ระหว่าง Message Processor กับเซิร์ฟเวอร์ Cassandra ไฟร์วอลล์อาจหมดเวลาการเชื่อมต่อ อย่างไรก็ตาม Message Processor ไม่ได้ออกแบบมาเพื่อสร้างการเชื่อมต่อกับ Cassandra อีกครั้ง

เพื่อป้องกันสถานการณ์นี้ Apigee ขอแนะนำให้เซิร์ฟเวอร์ Cassandra, Message Processor และเราเตอร์อยู่ในซับเน็ตเดียวกัน เพื่อไม่ให้ไฟร์วอลล์เกี่ยวข้องกับการติดตั้งใช้งานคอมโพเนนต์เหล่านี้

หากมีไฟร์วอลล์อยู่ระหว่างเราเตอร์และ Message Processor และมีการตั้งค่าการหมดเวลา TCP ที่ไม่มีการใช้งาน เราขอแนะนำให้ทำดังนี้

  1. ตั้งค่า net.ipv4.tcp_keepalive_time = 1800 ในการตั้งค่า sysctl บนระบบปฏิบัติการ Linux โดยที่ 1800 ควรต่ำกว่าระยะหมดเวลา TCP ที่ไม่มีการใช้งานของไฟร์วอลล์ การตั้งค่านี้จะช่วยให้การเชื่อมต่ออยู่ในสถานะที่สร้างขึ้นเพื่อให้ไฟร์วอลล์ไม่ยกเลิกการเชื่อมต่อ
  2. ใน Message Processor ทั้งหมด ให้แก้ไข /<inst_root>/apigee/customer/application/message-processor.properties เพื่อเพิ่มพร็อพเพอร์ตี้ต่อไปนี้ หากไม่มีไฟล์ ให้สร้างไฟล์
    conf_system_casssandra.maxconnecttimeinmillis=-1
  3. รีสตาร์ท Message Processor:
    > /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 รายการที่มีศูนย์ข้อมูล 2 แห่ง ให้ตรวจสอบว่าโหนดในศูนย์ข้อมูลทั้ง 2 แห่งสามารถสื่อสารผ่านพอร์ตที่แสดงด้านล่างได้

ข้อกำหนดของพอร์ต API BaaS

หากเลือกติดตั้ง API BaaS คุณจะต้องเพิ่มคอมโพเนนต์ API BaaS Stack และ API BaaS Portal คอมโพเนนต์เหล่านี้ใช้พอร์ตที่แสดงในรูปภาพด้านล่าง

หมายเหตุเกี่ยวกับแผนภาพนี้

  • โหนด Cassandra สามารถใช้สำหรับ API BaaS โดยเฉพาะ หรือจะแชร์กับ Edge ก็ได้
  • การติดตั้ง API BaaS ในเวอร์ชันที่ใช้งานจริงจะใช้ตัวจัดสรรภาระงานระหว่างโหนดพอร์ทัล API BaaS กับโหนดสแต็ก API BaaS เมื่อกำหนดค่าพอร์ทัลและเมื่อทำการเรียก API BaaS คุณจะต้องระบุที่อยู่ IP หรือชื่อ DNS ของตัวจัดสรรภาระงาน ไม่ใช่ของโหนด Stack
  • คุณต้องกำหนดค่าโหนด Baas Stack ทั้งหมดให้ส่งอีเมลผ่านเซิร์ฟเวอร์ SMTP ภายนอก สำหรับ SMTP ที่ไม่ใช่ TLS หมายเลขพอร์ตมักจะเป็น 25 สำหรับ SMTP ที่เปิดใช้ TLS มักจะเป็น 465 แต่โปรดตรวจสอบกับผู้ให้บริการ SMTP ของคุณ

ตารางด้านล่างแสดงพอร์ตเริ่มต้นที่ต้องเปิดในไฟร์วอลล์ตามคอมโพเนนต์

คอมโพเนนต์

พอร์ต

คำอธิบาย

พอร์ทัล API BaaS

9000

พอร์ตสำหรับ UI ของ API BaaS

API BaaS Stack

8080

พอร์ตที่ได้รับคำขอ API

ElasticSearch

9200 ถึง 9400

สำหรับการสื่อสารกับ API BaaS Stack และสำหรับการสื่อสารระหว่างโหนด ElasticSearch

การอนุญาตให้ใช้สิทธิ

การติดตั้ง Edge แต่ละครั้งต้องใช้ไฟล์ใบอนุญาตที่ไม่ซ้ำกันซึ่งคุณได้รับจาก Apigee คุณจะต้องระบุเส้นทางไปยังไฟล์ใบอนุญาตเมื่อติดตั้งเซิร์ฟเวอร์การจัดการ เช่น /tmp/license.txt

โปรแกรมติดตั้งจะคัดลอกไฟล์ใบอนุญาตไปยัง /<inst_root>/apigee/customer/conf/license.txt

หากไฟล์ใบอนุญาตถูกต้อง เซิร์ฟเวอร์การจัดการจะตรวจสอบความถูกต้องของวันหมดอายุและจำนวน Message Processor (MP) ที่อนุญาต หากการตั้งค่าใบอนุญาตหมดอายุ คุณจะดูบันทึกได้ในตำแหน่งต่อไปนี้ /<inst_root>/apigee/var/log/edge-management-server/logs ในกรณีนี้ คุณสามารถติดต่อทีมสนับสนุนของ Apigee เพื่อขอรายละเอียดการย้ายข้อมูลได้