Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
В течение августа и сентября 2015 года мы переносим наши облачные маршрутизаторы и балансировщики нагрузки Apigee Edge на NGINX (произносится как «Engine X»). NGINX, веб-сервер с открытым исходным кодом, обеспечивает еще лучшую производительность и более высокий уровень параллелизма, чем наши существующие балансировщики нагрузки и маршрутизаторы.
Что это значит для наших облачных клиентов
Суть в том, что это изменение должно быть прозрачным для вас и не требует никаких действий с вашей стороны, кроме проверки того, что ваши системы работают должным образом. Ниже приведены описания шагов, которые мы предпримем, а также ответы на некоторые часто задаваемые вопросы.
Шаг 1. Обновление программного обеспечения.
Мы обновим все маршрутизаторы до нового маршрутизатора на базе NGINX, используя нашу модель поэтапного развертывания, чтобы гарантировать, что это действие не повлияет на службы.
Шаг 2. Удаление уровня балансировки нагрузки в непроизводственных средах.
Поскольку новый маршрутизатор NGINX поддерживает функцию балансировки нагрузки, мы сначала начнем процесс удаления существующего уровня балансировки нагрузки в ваших непроизводственных средах. На этом этапе производственные балансировщики нагрузки останутся нетронутыми и неизмененными. Прежде чем удалять существующие балансировщики нагрузки, мы примем исчерпывающий подход к обеспечению правильной работы трафика. Для выполнения этого шага с вашей стороны не требуется никаких действий. Однако вам следует сообщать о любых проблемах в Apigee, и мы будем работать с вами над их решением, прежде чем переходить к шагу 3.
Шаг 3. Удаление уровня балансировки нагрузки в производственных средах
После успешного завершения шага 2 мы определим набор окон обслуживания для удаления уровня балансировщика нагрузки в производственных средах, используя тот же подход, который указан в шаге 2, чтобы гарантировать, что трафик API во время выполнения продолжает работать должным образом.
Изменения в функционале продукта
Вот некоторые изменения в функциональности продукта при переходе на NGINX.
Устарело
Следующие свойства больше не поддерживаются в ProxyEndpoints:
- разрешить.http10
- разрешить.http11
- разрешить.http.method.*
- разрешить.POST.без.content.length
- разрешить.PUT.без.content.length
Чтобы обойти это устаревание, см. следующую статью сообщества: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html .
Часто задаваемые вопросы
Ниже приведены ответы на некоторые часто задаваемые вопросы о миграции NGINX.
На шаге 1 ответ — «Нет», поскольку мы не затрагиваем существующие балансировщики нагрузки, которые не изменят напрямую ни один из IP-адресов, обслуживающих трафик. Однако, учитывая характер службы балансировки нагрузки Amazon Web Services (AWS), применяются обычные правила масштабирования, а это означает, что IP-адреса могут меняться как часть логики масштабирования (существующей функциональности). Вот почему мы не рекомендуем реализовывать конфигурации списков разрешений Northbound с помощью пакета продуктов Apigee Edge. На шагах 2 и 3 могут возникнуть последствия из списка разрешенных, связанные с удалением балансировщика нагрузки и связанных с ним IP-адресов. В результате мы будем тесно сотрудничать с вами на этих этапах, чтобы обеспечить плавный переход, предоставив новый набор IP-адресов, к которым будет разрешен доступ.
Никаких изменений не требуется, если исходные серверы являются целевыми конечными серверами (серверами, вызываемыми из пакета прокси). Это изменение происходит на северной стороне Apigee или в точке входа в Apigee.
Нет. Существующие записи CNAME продолжат работать должным образом.
Если вы используете SSL, первый шаг не повлияет на существующую конфигурацию SSL. Однако нам необходимо будет тесно сотрудничать с вами, чтобы убедиться, что SSL правильно настроен на новом маршрутизаторе, прежде чем переходить к шагам 2 и 3.
Шаги 2 и 3 будут отложены до тех пор, пока не будет подтверждена поддержка SNI.
Мы не ожидаем простоев. Изменения будут реализованы с использованием нашей стандартной модели развертывания в течение существующих периодов выпуска.
Вы просматриваете документацию Apigee Edge .
Перейдите к документации Apigee X. информация
В течение августа и сентября 2015 года мы переносим наши облачные маршрутизаторы и балансировщики нагрузки Apigee Edge на NGINX (произносится как «Engine X»). NGINX, веб-сервер с открытым исходным кодом, обеспечивает еще большую производительность и более высокий уровень параллелизма, чем существующие балансировщики нагрузки и маршрутизаторы.
Что это значит для наших облачных клиентов
Суть в том, что это изменение должно быть прозрачным для вас и не требует никаких действий с вашей стороны, кроме проверки того, что ваши системы работают должным образом. Ниже приведены описания шагов, которые мы предпримем, а также ответы на некоторые часто задаваемые вопросы.
Шаг 1. Обновление программного обеспечения.
Мы обновим все маршрутизаторы до нового маршрутизатора на базе NGINX, используя нашу модель поэтапного развертывания, чтобы гарантировать, что это действие не повлияет на службы.
Шаг 2. Удаление уровня балансировки нагрузки в непроизводственных средах.
Поскольку новый маршрутизатор NGINX поддерживает функцию балансировки нагрузки, мы сначала начнем процесс удаления существующего уровня балансировки нагрузки в ваших непроизводственных средах. На этом этапе производственные балансировщики нагрузки останутся нетронутыми и неизмененными. Прежде чем удалять существующие балансировщики нагрузки, мы примем исчерпывающий подход к обеспечению правильной работы трафика. Для выполнения этого шага с вашей стороны не требуется никаких действий. Однако вам следует сообщать о любых проблемах в Apigee, и мы будем работать с вами над их решением, прежде чем переходить к шагу 3.
Шаг 3. Удаление уровня балансировки нагрузки в производственных средах
После успешного завершения шага 2 мы определим набор окон обслуживания для удаления уровня балансировщика нагрузки в производственных средах, используя тот же подход, который указан в шаге 2, чтобы гарантировать, что трафик API во время выполнения продолжает работать должным образом.
Изменения в функционале продукта
Вот некоторые изменения в функциональности продукта при переходе на NGINX.
Устарело
Следующие свойства больше не поддерживаются в ProxyEndpoints:
- разрешить.http10
- разрешить.http11
- разрешить.http.method.*
- разрешить.POST.без.content.length
- разрешить.PUT.без.content.length
Чтобы обойти это устаревание, см. следующую статью сообщества: https://community.apigee.com/questions/16134/proxy-endpoint-http-allow-method-properties-not-wo.html .
Часто задаваемые вопросы
Ниже приведены ответы на некоторые часто задаваемые вопросы о миграции NGINX.
На шаге 1 ответ — «Нет», поскольку мы не затрагиваем существующие балансировщики нагрузки, которые не изменят напрямую ни один из IP-адресов, обслуживающих трафик. Однако, учитывая характер службы балансировки нагрузки Amazon Web Services (AWS), применяются обычные правила масштабирования, а это означает, что IP-адреса могут меняться как часть логики масштабирования (существующей функциональности). Вот почему мы не рекомендуем реализовывать конфигурации списков разрешений Northbound с помощью пакета продуктов Apigee Edge. На шагах 2 и 3 могут возникнуть последствия из списка разрешенных, связанные с удалением балансировщика нагрузки и связанных с ним IP-адресов. В результате мы будем тесно сотрудничать с вами на этих этапах, чтобы обеспечить плавный переход, предоставив новый набор IP-адресов, к которым будет разрешен доступ.
Никаких изменений не требуется, если предположить, что исходные серверы являются целевыми конечными серверами (серверами, вызываемыми из пакета прокси). Это изменение происходит на северной стороне Apigee или в точке входа в Apigee.
Нет. Существующие записи CNAME продолжат работать должным образом.
Если вы используете SSL, первый шаг не повлияет на существующую конфигурацию SSL. Однако нам необходимо будет тесно сотрудничать с вами, чтобы убедиться, что SSL правильно настроен на новом маршрутизаторе, прежде чем переходить к шагам 2 и 3.
Шаги 2 и 3 будут отложены до тех пор, пока не будет подтверждена поддержка SNI.
Мы не ожидаем простоев. Изменения будут реализованы с использованием нашей стандартной модели развертывания в течение существующих периодов выпуска.