• Перевод

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


Конечный автомат в NGINX по своей сути является набором инструкций для обработки запроса. Большинство веб-серверов выполняют такую же функцию, но разница кроется в реализации.

Устройство конечного автомата

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

Как бы то ни было, правила игры могут быть очень сложными. Например, веб-серверу может потребоваться взаимодействовать с другими ресурсами (проксировать запросы на бэкенд) или обращаться к серверу аутентификации. Сторонние модули способны ещё сильнее усложнить обработку.

Блокирующийся конечный автомат

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

  1. Процесс веб-сервера ожидает новых соединений (новых партий инициированных клиентами) на слушающих сокетах.
  2. Получив новое соединение, он играет партию, блокируясь после каждого хода в ожидании ответа от клиента.
  3. Когда партия сыграна, процесс веб-сервера может находиться в ожидании желания клиента начать следующую партию (это соответствует долгоживущим keepalive-соединениям). Если соединение закрыто (клиент ушел или наступил таймаут), процесс возвращается к встрече новых клиентов на слушающих сокетах.
Важный момент, который стоит отметить, заключается в том, что каждое активное HTTP-соединение (каждая партия) требует отдельного процесса или потока (гроссмейстера). Такая архитектура проста и легко расширяема с помощью сторонних модулей (новых «правил»). Однако, в ней существует огромный дисбаланс: достаточно легкое HTTP-соединение, представленное в виде файлового дескриптора и небольшого объема памяти, соотносится с отдельным процессом или потоком, достаточно тяжелым объектом в операционной системе. Это удобно для программирования, но весьма расточительно.

NGINX, как настоящий Гроссмейстер

Вероятно вы слышали о сеансах одновременной игры, когда один гроссмейстер играет на множестве шахматных полей сразу с десятками противников?


Кирил Георгиев на турнире в Болгарии сыграл параллельно 360 партий. Его итоговый результат составил: 284 победы, 70 вничью и 6 поражений.

Таким же образом рабочий процесс NGINX «играет в шахматы». Каждый рабочий процесс (помните - обычно всего один на вычислительное ядро) является гроссмейстером, способным играть сотни (а на самом деле сотни тысяч) партий одновременно.

  1. Рабочий процесс ожидает событий на слушающих сокетах и сокетах соединений.
  2. На сокетах происходят события и процесс их обрабатывает:
    • Событие на слушающем сокете означает, что пришел новый клиент для начала игры. Рабочий процесс создает новый сокет соединения.
    • Событие на сокете соединений сигнализирует, что клиент сделал ход. Рабочий процесс ему мгновенно отвечает.
Рабочий процесс, обрабатывая сетевой трафик, никогда не блокируется, ожидая очередного хода от оппонента (клиента). После того как процесс сделал свой ход, он немедленно переходит к другим доскам, на которых игроки ожидают хода, или встречает новых у двери.

Почему так получается быстрее, чем блокирующаяся многопоточная архитектура?

Каждое новое соединение создает файловый дескриптор и потребляет небольшой объем памяти в рабочем процессе. Это очень малые накладные расходы на соединение. Процессы NGINX могут оставаться привязанными к конкретным ядрам процессора. Переключения контекста происходят достаточно редко и в основном когда не осталось больше работы.

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

Дополнительную информацию по теме можно также узнать из статьи об архитектуре NGINX от Андрея Алексеева, вице-президента по развитию и сооснователя компании NGINX, Inc.

С адекватной настройкой системы , NGINX прекрасно масштабируется до многих сотен тысяч параллельных HTTP cоединений на каждый рабочий процесс и уверенно поглощает всплески трафика (толпы новых игроков).

Обновление конфигурации и исполняемого кода

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


Обновление конфигурации NGINX - очень простая, легковесная и надежная процедура. Она заключается в простой отправке мастер-процессу сигнала SIGHUP.

Когда рабочий процесс получает SIGHUP, он производит несколько операций:

  1. Перезагружает конфигурацию и порождает новый набор рабочих процессов. Эти новые рабочие процессы сразу начинают принимать соединения и обрабатывать трафик (используя новые настройки).
  2. Сигнализирует старые рабочие процессы о плавном завершении. Они перестают принимать новые соединения. Как только завершается обработка текущих HTTP-запросов, соединения закрываются (никаких затянувшихся keep-alive соединений). Как только все соединения закрыты, рабочий процесс завершается.
Данная процедура может вызвать небольшой всплеск нагрузки на процессор и память, но в общем это практически незаметно на фоне затрат на обработку активных соединений. Вы можете перезагружать конфигурацию несколько раз в секунду (и есть немало пользователей NGINX, кто так делает). В редких случаях могут возникнуть проблемы, когда слишком много поколений рабочих процессов NGINX ожидают закрытия соединений, но они быстро разрешаются.

Обновление исполняемого кода NGINX - это Святой Грааль высокой доступности сервисов. Вы можете обновлять сервер на лету, без потери соединений, простоя ресурсов и каких-либо перерывов в обслуживании клиентов.

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

Если вы хотите, чтобы сервер Яндекса обслуживал почтовые адреса, которыми вы пользовались до настройки MX-записи, создайте такие же адреса для нужного домена. Вы также можете импортировать ящики вместе с письмами.

Если вы делегировали домен на серверы Яндекса, MX-подпись будет настроена автоматически. Вы можете просмотреть и отредактировать ее параметры в DNS-редакторе Почты для домена.

    Войдите в вашу панель управления на сайте компании, предоставляющей вам услуги DNS-хостинга.

    Удалите существующие MX-записи.

    Создайте новую MX-запись со следующими значениями полей (в разных панелях управления названия полей могут отличаться):

    • Значение - «mx.yandex.net.» .

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

      Приоритет - 10.

      Если приоритет со значением «10» не предусмотрен в панели управления, укажите любой другой отличный от нуля приоритет.

      Имя поддомена - «@» .

      В некоторых панелях управления вместо «@» нужно указать имя вашего домена (например, «yourdomain.tld.» ). Если вам не удается указать ни «@» , ни имя домена, оставьте это поле пустым.

      Если это поле отсутствует в панели управления, можно его не указывать.

    Подождите, пока изменения в DNS вступят в силу. Этот процесс может длиться до 72 часов.

Предполагаемое время выполнения: 5 минут

Завершив настройку гибридного развертывания с помощью мастера гибридной конфигурации, вы можете направить поток обработки почты через Office 365. Для этого необходимо настроить запись MX, чтобы она указывала на полное доменное имя, созданное для организации Office 365. Когда запись MX указывает на Office 365, все сообщения электронной почты для локальных получателей и пользователей Office 365 передаются через Office 365. Затем сообщения для локальных получателей передаются из Office 365 в локальную организацию.

Дополнительные сведения см. в статье Параметры транспорта при гибридных развертываниях Exchange .

Как это сделать?

Необходимо настроить общедоступную запись DNS MX для основного пространства имен SMTP так, чтобы она указывала на полное доменное имя организации Office 365.

Полное доменное имя, которое необходимо использовать, создается автоматически при добавлении основного пространства имен SMTP к организации Office 365. Полное доменное имя имеет вид <домен>.mail.protection.outlook.com, где <домен> - это основное пространство имен SMTP. Пример: contoso-com.mail.protection.outlook.com.

Чтобы определить полное доменное имя, которое будет использоваться при создании записи MX, выполните следующие действия.

    Выберите пункт Домены .

    Выберите основное пространство имен SMTP для организации Office 365 (например, contoso.com) и нажмите кнопку Параметры домена .

    Убедитесь, что в разделе Назначение домена на странице Управление DNS отображается Exchange Online . Если это не так, сделайте следующее:

    1. В разделе Назначение домена нажмите Изменить назначение домена .

      Выберите Outlook в Интернете для электронной почты, календаря и контактов , а затем нажмите кнопку Далее .

      На последующих страницах представлены инструкции по настройке записей MX, автообнаружения, MSOID и SPF для организации Office 365. Некоторые из этих параметров не работают при настройке гибридного развертывания, поэтому мы не будем рассматривать их здесь. Мы настроим параметры для гибридного развертывания далее в этой статье.

      На странице Добавьте следующие записи DNS... нажмите Запись добавлена .

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

      На странице Управление доменами снова выберите основное пространство имен SMTP и нажмите Параметры домена .

      Теперь в разделе Назначение домена должен быть указан Exchange Online .

    В таблице записей DNS Exchange Online найдите строку, где в столбце Тип указано значение MX . Используйте значение из поля Адрес "указывает на" , например contoso-com.mail.protection.outlook.com.

    Не меняйте запись автообнаружения для домена на значение из таблицы Exchange Online . Если это сделать, локальные пользователи не смогут найти свои локальные почтовые ящики.

    После определения полного доменного имени для использования с записью MX создайте запись MX в зоне DNS.

    Например, запись MX для contoso.com выглядит следующим образом:

    Дополнительные сведения о добавлении записи MX в зону DNS см. в справочной документации DNS-узла.

Проверка выполнения

Чтобы проверить правильность создания записи DNS MX для основного пространства имен, выполните на компьютере с доступом к Интернету, который может выполнять поиск в DNS, следующие действия.

    Откройте командную строку Windows.

    Выполните следующую команду.

    Nslookup -type=MX contoso.com

Если DNS-запись настроена правильно, на экран будут выведены следующие результаты. (В зависимости от конкретной конфигурации DNS репликация изменений DNS в Интернете может занять один или несколько часов.) IP-адреса, отображаемые в результатах, могут отличаться от адресов, приведенных в примере ниже.

Server: dns.corp.contoso.com Address: 192.168.1.10 Non-authoritative answer: contoso.com MX preference = 0, mail exchanger = contoso-com.mail.protection.outlook.com contoso-com.mail.protection.outlook.com internet address = 216.32.181.10 contoso-com.mail.protection.outlook.com internet address = 216.32.180.42

Возникли проблемы? Обратитесь за помощью к участникам форума Office 365. Для получения доступа к форуму необходимо войти в систему, используя учетную запись с правами администратора на доступ к облачной службе. Посетите форумы на странице