Миграция на маршрутизаторы NGINX и балансировщики нагрузки

Вы просматриваете документацию Apigee Edge .
Перейдите в документацию Apigee
X.info

В течение августа и сентября 2015 года мы переводим наши облачные маршрутизаторы и балансировщики нагрузки Apigee Edge на NGINX (произносится как «Энджин Икс»). NGINX, веб-сервер с открытым исходным кодом, обеспечивает еще более высокую производительность и более высокую параллельную обработку данных, чем наши существующие балансировщики нагрузки и маршрутизаторы.

Что это значит для наших облачных клиентов

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

Шаг 1 — Обновление программного обеспечения

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

Шаг 2 — Удалите уровень балансировки нагрузки в непроизводственных средах.

Поскольку новый маршрутизатор NGINX отвечает за балансировку нагрузки, мы начнем процесс удаления существующего уровня балансировки нагрузки в ваших непроизводственных средах. Производственные балансировщики нагрузки останутся нетронутыми на этом этапе. Перед удалением существующих балансировщиков нагрузки мы тщательно проверим, работает ли трафик должным образом. От вас не требуется никаких действий для завершения этого шага. Однако вы должны сообщить о любых проблемах в Apigee, и мы будем сотрудничать с вами для их решения, прежде чем переходить к шагу 3.

Шаг 3 — Удаление уровня балансировки нагрузки в производственных средах

После успешного завершения Шага 2 мы определим набор периодов технического обслуживания для удаления уровня балансировщика нагрузки в производственной среде (средах), используя тот же подход, что и в Шаге 2, чтобы обеспечить бесперебойную работу API-трафика во время выполнения.

Изменения в функциональности продукта

Вот некоторые изменения в функциональности продукта, произошедшие после перехода на NGINX.

Устаревший

Следующие свойства больше не поддерживаются в ProxyEndpoints:

  • allow.http10
  • allow.http11
  • allow.http.method.*
  • allow.POST.without.content.length
  • allow.PUT.without.content.length

Чтобы обойти это устаревшее решение, ознакомьтесь со следующей статьей сообщества: Proxy Endpoint HTTP allow method properties not working .

Часто задаваемые вопросы

Ниже приведены ответы на некоторые часто задаваемые вопросы о миграции на NGINX.

Может ли это потенциально изменить общедоступные IP-адреса? Некоторые из наших продавцов специально разрешают доступ с известных IP-адресов, и когда эти адреса меняются, рабочий процесс продавца нарушается.
На шаге 1 ответ — «Нет», поскольку мы не затрагиваем существующие балансировщики нагрузки, что не повлияет напрямую на IP-адреса, обслуживающие трафик. Однако, учитывая особенности службы балансировки нагрузки Amazon Web Services (AWS), применяются обычные правила масштабирования, а это значит, что IP-адреса могут изменяться в рамках логики масштабирования (существующей функциональности). Именно поэтому мы не рекомендуем внедрять конфигурации разрешенного доступа для северного направления с помощью пакета продуктов Apigee Edge. На шагах 2 и 3 удаление балансировщика нагрузки и связанных с ним IP-адресов повлияет на работу разрешенного доступа. В результате мы будем тесно сотрудничать с вами на этих этапах, чтобы обеспечить плавный переход, предоставив новый набор IP-адресов для разрешения доступа.
Повлияет ли это на ограничения по IP-адресам, которые действуют на наших исходных серверах?
Никаких изменений не требуется, при условии, что исходные серверы являются целевыми конечными серверами (серверами, вызываемыми из пакета прокси). Это изменение касается северной стороны Apigee или точки входа в Apigee.
Потребуются ли изменения в существующем CNAME?
Нет. Существующие записи CNAME будут продолжать функционировать должным образом.
Перенос SSL-сертификата будет сложным процессом. Как вы собираетесь с этим справиться?
Если вы используете SSL, первый шаг не повлияет на существующую конфигурацию SSL. Однако нам потребуется тесно сотрудничать с вами, чтобы убедиться в правильной настройке SSL на новом маршрутизаторе, прежде чем переходить к шагам 2 и 3.
Что если мое приложение/клиент не поддерживает SNI?
Выполнение шагов 2 и 3 будет отложено до подтверждения поддержки SNI.
Будут ли какие-либо простои?
Мы не ожидаем никаких простоев. Изменения будут внедрены с использованием нашей стандартной модели развертывания в рамках существующих периодов выпуска.