С помощью существующего протокола единого входа OpenID Connect 3 страница
|
Команды NGINX
nginx -h
Показывает справочное меню NGINX.
nginx -v
Показывает версию NGINX.
|
Показывает версию NGINX, информацию о сборке и аргументы конфигурации, где даны модули, встроенные в двоичный файл NGINX.
nginx -t
Проверяет конфигурацию NGINX.
nginx -T
Проверяет конфигурацию NGINX и выводит ее проверенной на экран. Эта команда полезна при поиске поддержки.
nginx -s signal
Флаг -s отправляет сигнал главному процессу NGINX. Вы можете отправлять такие сигналы, как stop, quit, reload и reopen. stop немед- ленно прекращает процесс NGINX, quit останавливает процесс NGINX после завершения обработки запросов в полете, reload пе- резагружает конфигурацию, reopen дает NGINX команду повторно открывать файлы журнала.
Обсуждение
Освоив эти ключевые файлы, каталоги и команды, вы можете при- ступить к работе с NGINX. Обладая данными знаниями, вы можете из- менять файлы конфигурации по умолчанию и тестировать свои изме- нения с помощью команды nginx -t. Если ваш тест пройдет успешно, вы также будете знать, как проинструктировать NGINX для перезагрузки конфигурации с помощью команды nginx -s reload.
18 v Глава 1. Основы
|
|
|
1.6. Обслуживание статического контента
Задача
Вам необходимо обслуживать статический контент с помощью
NGINX.
|
Перепишите конфигурацию HTTP-сервера по умолчанию, располо- женную в /etc/nginx/conf.d/default.conf, используя приведенный ниже пример конфигурации NGINX:
server {
listen 80 default_server; server_name www.example.com;
location / {
root /usr/share/nginx/html;
# alias /usr/share/nginx/html; index index.html index.htm;
}
}
|
Данная конфигурация обслуживает статические файлы по протоколу HTTP через порт 80 из каталога /usr/share/nginx/html/. Первая строка в этой конфигурации определяет новый блок server. Это определяет но- вый контекст, который NGINX будет слушать. Вторая строка дает NGINX команду слушать порт 80, а параметр default_server указывает NGINX использовать этот сервер в качестве контекста по умолчанию для пор- та 80. Директива server_name определяет имя хоста или имена запросов, которые должны быть направлены на этот сервер. Если конфигурация не определила этот контекст как default_server, NGINX будет направлять запросы на этот сервер, только если заголовок HTTP-узла соответствует значению, указанному в директиве server_name.
Блок location определяет конфигурацию на основе пути в URL-адресе.
|
|
|
Путь или часть URL-адреса после домена называется URI. NGINX луч- ше всего будет соответствовать запрошенному URI для блока location. В этом примере используется символ / для сопоставления всех запросов. Директива root показывает NGINX, где искать статические файлы при
1.7. Аккуратная перезагрузка v 19
|
1.7. Аккуратная перезагрузка
Задача
Вам необходимо перезагрузить конфигурацию, не отбрасывая пакеты.
Решение 
Используйте метод reload для аккуратной перезагрузки конфигура- ции без остановки сервера:
$ nginx -s reload
В этом примере выполняется перезагрузка системы NGINX с исполь- зованием двоичного файла NGINX для отправки сигнала главному про- цессу.
|
|
|
Обсуждение
Перезагрузка конфигурации NGINX без остановки сервера предо- ставляет возможность изменять конфигурации на лету, не отбрасывая никаких пакетов. В динамичной среде с высокой продолжительностью работы в какой-то момент вам потребуется изменить конфигурацию балансировки нагрузки. NGINX позволяет делать это, сохраняя балан- сировщик нагрузки в сети. Эта функция предоставляет бесчисленные возможности, такие как повторный запуск управления конфигураци- ей в реальной среде или создание модуля с поддержкой приложений и кластеров для динамической настройки и перезагрузки NGINX, чтобы удовлетворять потребностям среды.
Глава 2
|
2.0. Введение
|
|
|
|
При балансировке нагрузки важно, чтобы влияние на клиента было
только положительным. Многие современные веб-архитектуры ис- пользуют уровни приложений без фиксации состояния, храня состоя- ние в системе с общей памятью или базах данных. Однако такое про- исходит не у всех. Состояние сеанса чрезвычайно ценно и обширно в интерактивных приложениях. Оно может храниться локально на сер- вере приложений по ряду причин; например, в приложениях, для ко- торых обрабатываемые данные настолько велики, что нагрузка на сеть слишком высока по производительности. Когда состояние хранится
|
локально на сервере приложений, пользователю крайне важно, чтобы последующие запросы продолжали доставляться на тот же сервер. Еще один аспект этой ситуации заключается в том, что серверы не должны быть освобождены до завершения сеанса. Для работы с масштабными приложениями, которые фиксируют состояние, требуется интеллек- туальный балансировщик нагрузки. NGINX Plus предлагает несколько способов решения этой проблемы путем отслеживания куки-файлов или маршрутизации. В этой главе рассматривается постоянство сеан- сов, поскольку оно касается балансировки нагрузки с помощью NGINX и NGINX Plus.
Также важно обеспечить работоспособность приложения, которое
|
2.1. Балансировка нагрузки для HTTP
Задача
Вам необходимо распределить нагрузку между двумя или более сер- верами HTTP.
22 v Глава 2. Высокопроизводительная балансировка нагрузки
Решение
Используйте HTTP-модуль NGINX для выполнения балансировки по
HTTP-серверам с использованием блока upstream:
upstream backend {
server 10.10.12.45:80 weight=1; server app.example.com:80 weight=2;
|
server {
location / {
proxy_pass http://backend;
}
}
|
Обсуждение
Модуль upstream управляет балансировкой нагрузки для HTTP. Этот модуль определяет пул адресатов – любую комбинацию сокетов Unix, IP-адресов и записей DNS или их комбинацию. Модуль upstream также определяет, каким образом любой отдельный запрос назначается лю- бому из вышестоящих серверов.
Каждый получатель в восходящем потоке определяется в восходящем пуле директивой server. В этой директиве указывается сокет Unix, IP-ад- рес или полное доменное имя, а также ряд необязательных параметров. Необязательные параметры дают больший контроль над маршрутиза- цией запросов. Эти параметры включают в себя вес сервера в алгоритме балансировки; находится ли сервер в режиме ожидания, доступен он или недоступен; и как определить, что сервер недоступен. NGINX Plus предоставляет ряд других удобных параметров, таких как ограничения подключения к серверу, расширенный контроль над DNS-преобразова- нием и возможность медленного увеличения количества подключений к серверу после его запуска.
2.2. Балансировка нагрузки для TCP v 23
2.2. Балансировка нагрузки для TCP
Задача
Вам необходимо распределить нагрузку между двумя или более сер- верами TCP.
Решение
Используйте модуль stream для балансировки нагрузки на TCP-сер-
веры с использованием блока upstream:
stream {
|
server read1.example.com:3306 weight=5; server read2.example.com:3306;
server 10.10.12.34:3306 backup;
}
server {
listen 3306; proxy_pass mysql_read;
}
}
Блок server в этом примере дает NGINX команду слушать TCP- порт 3306, выполняет балансировку нагрузки между двумя репликами на чтение базы данных MySQL и перечисляет еще одну в качестве ре- зервной копии, в которой будет передаваться трафик, если указанные первичные будут остановлены. Эту конфигурацию не нужно добавлять в папку conf.d, поскольку она включена в блок http; вместо этого следует создать другую папку с именем stream.conf.d, открыть блок stream в файле nginx.conf и включить в состав новую папку для потоковых конфигура- ций.
Обсуждение
Балансировка нагрузки TCP определяется модулем stream. Модуль stream, как и модуль HTTP, позволяет определять пулы вышестоящих серверов и настраивать слушающий сервер. При настройке сервера для прослушивания данного порта вы должны определить порт для про- слушивания или – по желанию – адрес и порт. Оттуда нужно настроить
24 v Глава 2. Высокопроизводительная балансировка нагрузки
|
Блок upstream для балансировки нагрузки TCP очень похож на тот, что используется для протокола HTTP, в том смысле, что он определяет восходящие ресурсы как серверы, настроенные с использованием со- кета Unix, IP-адреса или полностью определенного доменного имени (FQDN), а также вес сервера, максимальное количество подключений, DNS-решатели и периоды вывода в рабочий режим; а также является ли сервер активным, выключен или находится в режиме резервного ко- пирования.
NGINX Plus предлагает еще больше возможностей для балансировки
нагрузки для протокола TCP.
Эти расширенные функции, предлагаемые в NGINX Plus, можно встретить на протяжении всей книги. Проверка работоспособности всей балансировки нагрузки будет рассмотрена позже в этой главе.
2.3. Балансировка нагрузки UDP
Задача
Вам необходимо распределить балансировку нагрузку между двумя или более серверами UDP.
|
Используйте модуль stream для балансировки нагрузки по UDP-серве-
рам, взяв блок upstream, определенный как udp:
stream {
upstream ntp {
server ntp1.example.com:123 weight=2; server ntp2.example.com:123;
}
server {
listen 123 udp; proxy_pass ntp;
}
}
Данный раздел распределяет нагрузку между двумя вышестоящими
NTP-серверами, использующими протокол UDP. Задать балансировку
2.3. Балансировка нагрузки UDP v 25
нагрузки для UDP так же просто, как использовать параметр udp в ди- рективе listen.
|
stream {
server {
|
}
}
Обсуждение
Вы можете спросить: «Зачем нужен балансировщик нагрузки, когда у меня может быть несколько хостов в записи DNS A или SRV?» Ответ заключается в том, что есть не только альтернативные алгоритмы ба- лансировки, с помощью которых выполняют балансировку нагрузки, а можно делать это поверх самих DNS-серверов. Службы UDP состав- ляют большую часть служб, от которых мы зависим в таких сетевых системах, как DNS, NTP и VoIP. Балансировка нагрузки UDP для кого-то может быть менее привычной, но столь же полезной в мире масштаби- рования.
Можно найти балансировку нагрузки для протокола UDP в модуле
stream, как и для TCP, и настроить его в основном таким же образом. Главное отличие состоит в том, что директива listen указывает на то, что открытый сокет предназначен для работы с датаграммами. При работе с датаграммами существуют другие директивы, которые могут применяться там, где их нет в TCP, например директива proxy_response, указывающая NGINX, сколько ожидаемых ответов можно отправить с вышестоящего сервера. По умолчанию эта цифра не ограничена, до тех пор пока не будет достигнут лимит времени proxy_time out.
Дата добавления: 2021-01-21; просмотров: 118; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!