Требования к установке

Edge для частного облака v4.18.01

Требования к оборудованию

Вы должны соответствовать следующим минимальным требованиям к оборудованию для высокодоступной инфраструктуры в среде производственного уровня. Для всех сценариев установки, описанных в разделе «Топологии установки» , в следующих таблицах указаны минимальные требования к оборудованию для компонентов установки.

В этих таблицах требования к жесткому диску указаны в дополнение к пространству на жестком диске, необходимому операционной системе. В зависимости от ваших приложений и сетевого трафика для вашей установки может потребоваться больше или меньше ресурсов, чем указано ниже.

Компонент установки БАРАН Процессор Минимальный жесткий диск
Кассандра 16 ГБ 8-ядерный Локальное хранилище объемом 250 ГБ с твердотельным накопителем или быстрым жестким диском с поддержкой 2000 операций ввода-вывода в секунду.
Процессор сообщений/маршрутизатор на одном компьютере 16 ГБ 8-ядерный 100 ГБ
Аналитика — Postgres/Qpid на том же сервере (не рекомендуется для производства) 16 ГБ * 8-ядерный * 500 ГБ – 1 ТБ ** сетевое хранилище *** , желательно с SSD-накопителем, поддерживающим 1000 IOPS или выше *
Аналитика — автономный Postgres 16 ГБ * 8-ядерный * 500 ГБ – 1 ТБ ** сетевое хранилище *** , желательно с SSD-накопителем, поддерживающим 1000 IOPS или выше *
Аналитика – автономный Qpid 8 ГБ 4-ядерный 30–50 ГБ локальной памяти с SSD или быстрым жестким диском

Для установок с производительностью более 250 TPS рекомендуется использовать жесткий диск с локальным хранилищем, поддерживающим 1000 IOPS.

Размер очереди Qpid по умолчанию составляет 20 ГБ. Если вам нужно увеличить емкость, добавьте дополнительные узлы Qpid.

Другое (OpenLDAP, пользовательский интерфейс, сервер управления) 4ГБ 2-ядерный 60 ГБ

* Скорректируйте системные требования Postgres в зависимости от пропускной способности:

  • Менее 250 TPS: 8 ГБ, 4-ядерный процессор можно рассмотреть с управляемым сетевым хранилищем *** с поддержкой 1000 операций ввода-вывода в секунду или выше
  • Более 250 TPS: 16 ГБ, 8-ядерный управляемый сетевой накопитель ** * поддержка 1000 операций ввода-вывода в секунду или выше.
  • Более 1000 TPS: 16 ГБ, 8-ядерное управляемое сетевое хранилище. *** Поддержка 2000 операций ввода-вывода в секунду или выше. Более
  • 2000 TPS: 32 ГБ, 16-ядерное управляемое сетевое хранилище. *** Поддержка 2000 операций ввода-вывода в секунду или выше.
  • Более 4000 TPS: 64 ГБ, 32-ядерное управляемое сетевое хранилище *** с поддержкой 4000 операций ввода-вывода в секунду или выше

** Значение жесткого диска Postgres основано на готовых аналитических данных, полученных Edge. Если вы добавляете пользовательские значения к данным аналитики, то эти значения следует соответствующим образом увеличить. Используйте следующую формулу для оценки необходимого объема памяти:

bytes of storage needed =

(# bytes of analytics data/request) *

(requests/second) *

(seconds/hour) *

(hours of peak usage/day) *

(days/month) *

(months of data retention)

Например:

(2K bytes) * (100 req/sec) * (3600 secs/hr) * (18 peak hours/day) * (30 days/month) * (3 months retention)

= 1,194,393,600,000 bytes or 1194.4 GB

*** Сетевое хранилище рекомендуется для базы данных Postgresql, поскольку:

  • оно дает возможность динамически увеличивать размер хранилища, если и когда это необходимо.
  • Сетевые операции ввода-вывода в секунду можно регулировать «на лету» в большинстве современных сред/хранилищ/сетевых подсистем.
  • Снимки уровня хранилища можно включить как часть решений резервного копирования и восстановления.

Кроме того, ниже перечислены требования к оборудованию, если вы хотите установить Службы монетизации:

Компонент с монетизацией БАРАН Процессор Жесткий диск
Сервер управления (со службами монетизации) 8 ГБ 4‑ядерный 60 ГБ
Аналитика — Postgres/Qpid на том же сервере 16 ГБ 8-ядерный Сетевое хранилище от 500 ГБ до 1 ТБ, желательно с серверной частью SSD, поддерживающее 1000 IOPS или выше, или используйте правило из таблицы выше.
Аналитика — автономный Postgres 16 ГБ 8-ядерный Сетевое хранилище от 500 ГБ до 1 ТБ, желательно с серверной частью SSD, поддерживающее 1000 IOPS или выше, или используйте правило из таблицы выше.
Аналитика – автономный Qpid 8 ГБ 4-ядерный 40–500 ГБ локальной памяти с SSD или быстрым жестким диском

Для установок с производительностью более 250 TPS рекомендуется использовать жесткий диск с локальным хранилищем, поддерживающим 1000 IOPS.

Ниже перечислены требования к оборудованию, если вы хотите установить API BaaS:

API-компонент BaaS БАРАН Процессор Жесткий диск
ЭластичныйПоиск * 8 ГБ 4‑ядерный 60-80 ГБ
Стек API BaaS * 8 ГБ 4-ядерный 60-80 ГБ
API BaaS-портала 1 ГБ 2-ядерный 20 ГБ
Кассандра ** 16 ГБ 8-ядерный Локальное хранилище объемом 250 ГБ с твердотельным накопителем или быстрым жестким диском с поддержкой 2000 операций ввода-вывода в секунду.

* Вы можете установить ElasticSearch и API BaaS Stack на одном узле. Если да, настройте ElasticSearch на использование 4 ГБ памяти (по умолчанию). Если ElasticSearch установлен на отдельном узле, настройте его на использование 6 ГБ памяти.

** Необязательный; обычно вы используете один и тот же кластер Cassandra как для Edge, так и для API BaaS Services.

Требования к операционной системе и стороннему программному обеспечению

Эти инструкции по установке и прилагаемые установочные файлы были протестированы на операционных системах и стороннем программном обеспечении, перечисленных в разделе Поддерживаемое программное обеспечение и поддерживаемые версии .

Создание пользователя apigee

Процедура установки создает пользователя системы Unix с именем «apigee». Каталоги и файлы Edge, как и процессы Edge, принадлежат Apigee. Это означает, что компоненты 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. Измените владельца корневого каталога установки и символической ссылки на пользователя «apigee»:
    chown -h apigee:apigee /srv/myInstallDir /opt/apigee

Джава

Перед установкой на каждом компьютере должна быть установлена ​​поддерживаемая версия Java 1.8. Поддерживаемые JDK перечислены в разделе Поддерживаемое программное обеспечение и поддерживаемые версии .

Убедитесь, что JAVA_HOME указывает на корень JDK пользователя, выполняющего установку.

SELinux

В зависимости от ваших настроек SELinux, Edge может столкнуться с проблемами при установке и запуске компонентов Edge. При необходимости вы можете отключить SELinux или перевести его в разрешительный режим во время установки, а затем снова включить его после установки. Дополнительные сведения см. в разделе Установка утилиты Edge 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

Убедитесь, что нет политик 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 , не устанавливайте для них значение 700, иначе маршрутизатор не запустится. Разрешения могут быть установлены на 744, чтобы разрешить доступ для чтения к /etc/rc.d/init.d/functions .

Кассандра

Все узлы Cassandra должны быть подключены к кольцу. Cassandra хранит реплики данных на нескольких узлах, чтобы обеспечить надежность и отказоустойчивость. Стратегия репликации для каждого пространства ключей Edge определяет узлы Cassandra, на которых размещаются реплики. Дополнительные сведения см. в разделе О коэффициенте репликации Cassandra и уровне согласованности .

Cassandra автоматически корректирует размер кучи Java в зависимости от доступной памяти. Дополнительную информацию см. в разделе Настройка ресурсов Java . В случае ухудшения производительности или высокого потребления памяти.

После установки Edge для частного облака вы можете проверить правильность настройки Cassandra, изучив файл /opt/apigee/apigee-cassandra/conf/cassandra.yaml . Например, убедитесь, что в сценарии установки Edge для частного облака заданы следующие свойства:

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

База данных PostgreSQL

После установки 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

Системные ограничения

Убедитесь, что вы установили следующие системные ограничения для узлов Cassandra и Message Processor:

  • На узлах Cassandra установите ограничения программной и жесткой блокировки памяти, nofile и адресного пространства (как) для пользователя установки (по умолчанию — «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
  • На узлах процессора сообщений установите максимальное количество дескрипторов открытых файлов равным 64 КБ в /etc/security/limits.d/90-apigee-edge-limits.conf , как показано ниже:
    apigee soft nofile 32768
    apigee hard nofile 65536

    При необходимости вы можете увеличить этот лимит. Например, если у вас одновременно открыто большое количество временных файлов.

JSVC

«jsvc» является обязательным условием для использования API BaaS. Версия 1.0.15-dev устанавливается при установке API BaaS.

Службы сетевой безопасности (NSS)

Службы сетевой безопасности (NSS) — это набор библиотек, которые поддерживают разработку клиентских и серверных приложений с поддержкой безопасности. Вам следует убедиться, что у вас установлена ​​NSS v3.19 или более поздняя версия.

Чтобы проверить текущую версию:

yum info nss

Чтобы обновить NSS:

yum update nss

Дополнительную информацию см. в этой статье RedHat.

Отключить поиск DNS на IPv6 при использовании NSCD (демон кэша службы имен)

Если вы установили и включили NSCD (демон кэша службы имен), процессоры сообщений выполняют два поиска DNS: один для IPv4 и один для IPv6. При использовании NSCD следует отключить поиск DNS на IPv6.

Чтобы отключить поиск DNS на 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. Сохраните файл.

АВС АМИ

Если вы устанавливаете Edge на образ машины AWS Amazon (AMI) для Red Hat Enterprise Linux 7.x, сначала необходимо выполнить следующую команду:

yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

Инструменты

Программа установки использует следующие инструменты UNIX в стандартной версии, предоставляемой EL5 или EL6.

ок

выражение

libxslt

об/мин

разархивировать

базовое имя

grep

Lua-сокет

rpm2cpio

добавить пользователя

бить

имя хоста

лс

СЭД

Туалет

До нашей эры

идентификатор

сетевые инструменты

судо

wget

завиток

Либайо

perl (из реквизита)

смола

xerces-c

Сайрус-Сасл libdb4 pgrep (из procps) тр ням

дата

libdb-cxx

пс

uuid

chkconfig

имя каталога libibглаголы страдающий не называть имя
эхо librdmacm питон

нтпдате

Рекомендуется синхронизировать время серверов. Для этой цели может служить утилита 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 хостами с двумя центрами обработки данных требуется репликация OpenLDAP, поскольку существует несколько узлов, на которых размещен OpenLDAP.

Брандмауэры и виртуальные хосты

Термин virtual обычно перегружен на ИТ-арене, как и в случае с Apigee Edge для развертывания частного облака и виртуальных хостов. Чтобы уточнить, есть два основных использования термина virtual :

  • Виртуальные машины (ВМ) : не обязательно, но в некоторых развертываниях используется технология виртуальных машин для создания изолированных серверов для своих компонентов Apigee. Хосты виртуальных машин, как и физические хосты, могут иметь сетевые интерфейсы и брандмауэры.
  • Виртуальные хосты : конечные точки веб-сайта, аналогичные виртуальному хосту Apache.

Маршрутизатор в виртуальной машине может предоставлять доступ к нескольким виртуальным хостам (при условии, что они отличаются друг от друга псевдонимом хоста или интерфейсным портом).

В качестве примера именования: на одном физическом сервере A могут работать две виртуальные машины с именами «VM1» и «VM2». Предположим, «VM1» предоставляет виртуальный интерфейс Ethernet, который внутри виртуальной машины получает имя «eth0» и которому назначается IP-адрес 111.111.111.111 механизмом виртуализации или сетевым DHCP-сервером; а затем предположим, что VM2 предоставляет виртуальный интерфейс Ethernet, также называемый «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 с базовым URL-адресом /salesdemo , пользователи получат доступ к этому API с помощью http://api.mycompany.com:80/salesdemo . Если вы развертываете свой API mycompany с базовым URL-адресом / , тогда ваши пользователи получают доступ к API по URL-адресу http://api.mycompany.com:80/ .

Требования к пограничному порту

Необходимость управления брандмауэром выходит за рамки только виртуальных хостов; Межсетевые экраны как виртуальной машины, так и физического хоста должны разрешать трафик для портов, необходимых компонентам для связи друг с другом.

На следующем изображении показаны требования к портам для каждого компонента Edge:

Примечания к этой схеме:

  • * Порт 8082 на процессоре сообщений должен быть открыт для доступа маршрутизатора только при настройке TLS/SSL между маршрутизатором и процессором сообщений. Если вы не настраиваете TLS/SSL между маршрутизатором и процессором сообщений, в конфигурации по умолчанию порт 8082 по-прежнему должен быть открыт на процессоре сообщений для управления компонентом, но маршрутизатору не требуется доступ к нему.
  • Порты с префиксом «M» — это порты, используемые для управления компонентом, они должны быть открыты на компоненте и должны быть открыты на компоненте для доступа со стороны сервера управления.
  • Следующие компоненты требуют доступа к порту 8080 на сервере управления: маршрутизатор, процессор сообщений, пользовательский интерфейс, Postgres и Qpid.
  • Процессор сообщений должен открыть порт 4528 в качестве порта управления. Если у вас есть несколько процессоров сообщений, все они должны иметь доступ друг к другу через порт 4528 (обозначен стрелкой цикла на схеме выше для порта 4528 на процессоре сообщений). Если у вас несколько центров обработки данных, порт должен быть доступен всем процессорам сообщений во всех центрах обработки данных.
  • Хотя это и не требуется, вы можете открыть порт 4527 на маршрутизаторе для доступа к нему любого процессора сообщений. В противном случае вы можете увидеть сообщения об ошибках в файлах журнала процессора сообщений.
  • Маршрутизатор должен открыть порт 4527 в качестве порта управления. Если у вас несколько маршрутизаторов, все они должны иметь доступ друг к другу через порт 4527 (обозначен стрелкой петли на схеме выше для порта 4527 на маршрутизаторе).
  • Пользовательскому интерфейсу Edge требуется доступ к маршрутизатору через порты, предоставляемые прокси-серверами API, для поддержки кнопки «Отправить» в инструменте трассировки.
  • Серверу управления требуется доступ к порту JMX на узлах Cassandra.
  • Доступ к портам JMX можно настроить так, чтобы требовалось имя пользователя и пароль. Дополнительную информацию см. в разделе «Как отслеживать» .
  • При желании вы можете настроить доступ TLS/SSL для определенных соединений, которые могут использовать разные порты. Дополнительную информацию см. в разделе TLS/SSL .
  • При настройке двух узлов Postgres для использования репликации главный-резервный необходимо открыть порт 22 на каждом узле для доступа по ssh. При желании вы можете открыть порты на отдельных узлах, чтобы разрешить доступ по ssh.
  • Вы можете настроить сервер управления и пограничный пользовательский интерфейс для отправки электронных писем через внешний SMTP-сервер. Если вы это сделаете, вы должны убедиться, что сервер управления и пользовательский интерфейс могут получить доступ к необходимому порту на 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.

59001 Порт, используемый для тестирования установки Edge с помощью утилиты apigee-validate . Для этой утилиты требуется доступ к порту 59001 на маршрутизаторе. Дополнительную информацию см. в разделе Проверка установки на порту 59001.
Работник зоопарка 2181 Используется другими компонентами, такими как сервер управления, маршрутизатор, процессор сообщений и т. д.
2888, 3888 Используется внутри ZooKeeper для связи кластера ZooKeeper (известного как ансамбль ZooKeeper).
Кассандра 7000, 9042, 9160 Порты Apache Cassandra для связи между узлами Cassandra и доступа к другим компонентам Edge.
7199 JMX-порт. Должен быть открыт для доступа Сервера управления.
Qpid 5672 Используется для связи между маршрутизатором и процессором сообщений с сервером Qpid.
8083 Порт управления по умолчанию на сервере Qpid должен быть открыт на компоненте для доступа к нему со стороны сервера управления.
1102 JMX-порт
4529 Для распределенного кэша и вызовов управления
Постгрес 5432 Используется для связи между Qpid/сервером управления и Postgres.
8084 Порт управления по умолчанию на сервере Postgres должен быть открыт на компоненте для доступа к нему со стороны сервера управления.
1103 JMX-порт
4530 Для распределенного кэша и вызовов управления
22 При настройке двух узлов Postgres для использования репликации главный-резервный необходимо открыть порт 22 на каждом узле для доступа по ssh.
ЛДАП 10389 OpenLDAP
СмартДокс 59002 Порт на Edge-маршрутизаторе, куда отправляются запросы страниц SmartDocs.

В следующей таблице показаны те же порты, пронумерованные, с компонентами источника и назначения:

Номер порта Цель Исходный компонент Целевой компонент
virtual_host_port HTTP плюс любые другие порты, которые вы используете для трафика вызовов API виртуального хоста. Чаще всего используются порты 80 и 443; Маршрутизатор сообщений может завершать соединения TLS/SSL. Внешний клиент (или балансировщик нагрузки) Прослушиватель на маршрутизаторе сообщений
с 1099 по 1103 Управление JMX JMX-клиент Сервер управления (1099)
Процессор сообщений (1101)
Qpid-сервер (1102)
Сервер Postgres (1103)
2181 Связь с клиентом Zookeeper Сервер управления
Маршрутизатор
Процессор сообщений
Qpid-сервер
Постгрес-сервер
Работник зоопарка
2888 и 3888 Управление межузлами Zookeeper Работник зоопарка Работник зоопарка
4526 Порт управления RPC Сервер управления Сервер управления
4527 Порт управления RPC для распределенного кэша и вызовов управления, а также для связи между маршрутизаторами. Сервер управления
Маршрутизатор
Маршрутизатор
4528 Для вызовов распределенного кэша между процессорами сообщений и для связи с маршрутизатором. Сервер управления
Маршрутизатор
Процессор сообщений
Процессор сообщений
4529 Порт управления RPC для распределенного кэша и вызовов управления. Сервер управления Qpid-сервер
4530 Порт управления RPC для распределенного кэша и вызовов управления. Сервер управления Постгрес-сервер
5432 Клиент Postgres Qpid-сервер Постгрес
5672

Используется для отправки аналитики из маршрутизатора и процессора сообщений в Qpid.

Маршрутизатор
Процессор сообщений
Qpid-сервер
7000 Межузловая связь Cassandra Кассандра Другой узел Кассандры
7199 Управление JMX. Должен быть открыт для доступа на узле Cassandra со стороны Сервера управления. JMX-клиент Кассандра
8080 Порт API управления Клиенты API управления Сервер управления
с 8081 по 8084

Порты API компонентов, используемые для отправки запросов API непосредственно к отдельным компонентам. Каждый компонент открывает отдельный порт; точный используемый порт зависит от конфигурации, но он должен быть открыт на компоненте для доступа к нему со стороны сервера управления.

Клиенты API управления Маршрутизатор (8081)
Процессор сообщений (8082)
Qpid-сервер (8083)
Сервер Postgres (8084)
8998 Связь между маршрутизатором и процессором сообщений Маршрутизатор Процессор сообщений
9000 Порт пользовательского интерфейса управления Edge по умолчанию Браузер Сервер пользовательского интерфейса управления
9042 Собственный транспорт CQL Маршрутизатор
Процессор сообщений
Сервер управления
Кассандра
9160 Кассандра, клиент бережливости Маршрутизатор
Процессор сообщений
Сервер управления
Кассандра
10389 LDAP-порт Сервер управления OpenLDAP
15999 Порт проверки работоспособности. Балансировщик нагрузки использует этот порт, чтобы определить, доступен ли маршрутизатор. Балансировщик нагрузки Маршрутизатор
59001 Порт, используемый утилитой apigee-validate для проверки установки Edge. Apigee-проверить Маршрутизатор
59002 Порт маршрутизатора, на который отправляются запросы страниц SmartDocs. СмартДокс Маршрутизатор

Обработчик сообщений поддерживает выделенный пул соединений, открытый для Cassandra, который настроен на отсутствие тайм-аута. Когда межсетевой экран находится между процессором сообщений и сервером Cassandra, брандмауэр может прервать соединение. Однако процессор сообщений не предназначен для восстановления соединения с Cassandra.

Чтобы предотвратить такую ​​ситуацию, Apigee рекомендует, чтобы сервер Cassandra, процессор сообщений и маршрутизаторы находились в одной подсети, чтобы межсетевой экран не участвовал в развертывании этих компонентов.

Если между маршрутизатором и процессорами сообщений установлен межсетевой экран и для него установлен тайм-аут простоя TCP, мы рекомендуем:

  1. Установите net.ipv4.tcp_keepalive_time = 1800 в настройках sysctl в ОС Linux, где 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

Если вы устанавливаете кластерную конфигурацию из 12 узлов с двумя центрами обработки данных, убедитесь, что узлы в двух центрах обработки данных могут обмениваться данными через порты, показанные ниже:

Требования к порту API BaaS

Если вы решите установить API BaaS, вы добавите компоненты API BaaS Stack и API BaaS Portal. Эти компоненты используют порты, показанные на рисунке ниже:

Примечания к этой схеме:

  • Портал API BaaS никогда не отправляет запросы непосредственно к узлу стека BaaS. Когда разработчик входит на портал, приложение портала загружается в браузер. Приложение портала, работающее в браузере, затем отправляет запросы к узлам стека BaaS.
  • Рабочая установка API BaaS использует балансировщик нагрузки между узлом портала API BaaS и узлами стека API BaaS. При настройке портала и при выполнении вызовов API BaaS вы указываете IP-адрес или DNS-имя балансировщика нагрузки, а не узлов стека.
  • Все узлы стека должны открыть порт 2551 для доступа со всех других узлов стека (обозначено стрелкой цикла на схеме выше для порта 2551 на узлах стека). Если у вас несколько центров обработки данных, порт должен быть доступен со всех узлов стека во всех центрах обработки данных.
  • Вы должны настроить все узлы Baas Stack для отправки электронной почты через внешний SMTP-сервер. Для SMTP без TLS номер порта обычно равен 25. Для SMTP с поддержкой TLS это часто 465, но уточните у своего поставщика SMTP.
  • Узлы Cassandra могут быть выделены для API BaaS или могут использоваться совместно с Edge.

В таблице ниже показаны порты по умолчанию, которые необходимо открыть в брандмауэрах, по компонентам:

Компонент Порт Описание
API BaaS-портала 9000 Порт для пользовательского интерфейса API BaaS
API-стек BaaS 8080 Порт, на который принимаются запросы API
2551

Порт для связи между всеми узлами стека. Должен быть доступен всем остальным узлам стека в центре данных.

Если у вас несколько центров обработки данных, порт должен быть доступен со всех узлов стека во всех центрах обработки данных.

ЭластичныйПоиск с 9200 до 9400 Для связи со стеком API BaaS и для связи между узлами ElasticSearch.

Лицензирование

Для каждой установки Edge требуется уникальный файл лицензии, который вы получаете от Apigee. При установке сервера управления вам потребуется указать путь к файлу лицензии, например /tmp/license.txt.

Установщик копирует файл лицензии в /opt/apigee/customer/conf/license.txt .

Если файл лицензии действителен, сервер управления проверяет срок действия и разрешенное количество процессоров сообщений (MP). Если срок действия каких-либо настроек лицензии истек, вы можете найти журналы в следующем месте: /opt/apigee/var/log/edge-management-server/logs . В этом случае вы можете обратиться в службу поддержки Apigee Edge для получения подробной информации о миграции.

Если у вас еще нет лицензии, обратитесь в отдел продаж Apigee .