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

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

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

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

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

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

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

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

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

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

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

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

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

Устаревший

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

  • разрешить.http10
  • разрешить.http11
  • allow.http.method.*
  • разрешить.POST.без.длины.контента
  • разрешить.PUT.без.длины.контента

Чтобы обойти это ограничение, см. следующую статью сообщества: Свойства метода разрешения HTTP конечной точки прокси-сервера не работают .

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

Ниже приведены ответы на некоторые часто задаваемые вопросы о миграции 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.
Будут ли простои?
Мы не ожидаем простоев. Изменения будут реализованы с использованием нашей стандартной модели развертывания в течение текущих периодов выпуска.