Безболезненное руководство для начинающих по Nginx

Nginx
Безболезненное руководство для начинающих по Nginx

В этой новой теме автор разобрал базовое содержимое Nginx и смоделировал развертывание высокодоступного кластера высокой доступности в среде виртуальной машины. В основном мы начинаем со следующего:

  1. Что такое Nginx? Для чего это используется?
  2. Установка Nginx в системе Linux включает в себя обратный прокси, балансировку нагрузки, динамическое и статическое разделение и настройку кластера высокой доступности.

Введение в Nginx

Nginx (engine x) — это высокопроизводительный веб-сервер HTTP и обратный прокси-сервер, который также предоставляет услуги IMAP/POP3/SMTP. Он характеризуется:Небольшой объем памяти и мощная возможность параллелизма.

Nginx может использоваться как статический веб-сервер и поддерживает динамические языки протокола CGI, такие как perl и php. Проект JavaWeb должен быть завершен с помощью tomcat.Nginx специально разработан для оптимизации, производительность является наиболее важным фактором.

Nginx поддерживает горячее развертывание. Версия программного обеспечения может быть обновлена ​​с бесперебойным обслуживанием.

обратный прокси

Прежде чем вводить обратный прокси, прежде всего, что такое прямой прокси?

Виртуальная частная сеть, которую мы используем каждый день, представляет собой прямой прокси. Например, внутренние клиенты, которые хотят получить прямой доступ к официальному веб-сайту Google, не могут подключиться, но если пользователь может получить доступ к определенному серверу A, а A может получить доступ к официальному веб-сайту Google, тогда клиент может установить этот сервер A в качестве прокси-сервера и использовать сервер A для запроса Google Ответное сообщение пересылается пользователю. В настоящее время этот сервер A называется прямым прокси-сервером.

Другими словами, прямой прокси-сервер требует от пользователя активной настройки прокси-сервера.

С обратным прокси-сервером клиент не знает о прокси-сервере. Клиенту нужно только отправить запрос на прокси-сервер по общедоступному URL-адресу, а прокси-сервер выбирает целевой сервер для обработки запроса и возврата данных, как показано на следующем рисунке. Пользователю все равно, какой именно целевой сервер выполняет за него услугу, а целевой сервер справа от пунктирной линии прозрачен для клиента.

балансировки нагрузки

Если одному фургону тяжело тянуть большой груз, вызовите еще несколько.

Терминал обслуживания клиентов отправляет несколько запросов на сервер, сервер обрабатывает запросы, и некоторые запросы должны взаимодействовать с базой данных, пока сервер не завершит обработку, а затем возвращает результаты клиенту.

Этот архитектурный шаблон больше подходит для ранних одновременных запросов, когда количество одновременных запросов меньше, а стоимость обслуживания также относительно низка. Но мы уже знаем, что закон Мура постепенно дает сбой, и повышение производительности оборудования больше не может соответствовать нашим реальным требованиям к производительности. Например, на Tmall Double Eleven мгновенный объем доступа очень велик, даже если мы апгрейдим одиночную ноду до текущей топовой конфигурации, с этим сложно справиться (это без учета стоимости апгрейда оборудования ). Поэтому текущие службы постепенно переходят в режим кластера.

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

Динамическое и статическое разделение

Для ускорения парсинга сайта,Мы можем раздавать динамические страницы и статические страницы на разные серверы для разбора, чтобы ускорить синтаксический анализ и снизить нагрузку на один сервер.

Установка Nginx

Нашим домом по-прежнему остается система Linux. Мы можем зайти на официальный сайт nginx, загрузить соответствующую версию, а затем отправить ее на наш облачный сервер/виртуальную машину для установки, но установка Nginx должна решить множество проблем с зависимостями, что здесь не рекомендуется.

Виртуальная машина автора — это версия CentOS 7.8 x86_64, которая устанавливается здесь путем простой настройки источника yum (аналогично авторскому процессу установки Docker):

Если вы еще не устанавливали yum-utils, вам необходимо сначала установить его:

$ yum install yum-utils

Входить/etc/yum.reops.d/каталог, создайте исходный файл конфигурации загрузки nginx:

$ vim nginx.repo

Добавьте в этот файл следующую конфигурацию:

[nginx-stable]
name=nginx stable repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=1
enabled=1
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

[nginx-mainline]
name=nginx mainline repo
baseurl=http://nginx.org/packages/mainline/centos/$releasever/$basearch/
gpgcheck=1
enabled=0
gpgkey=https://nginx.org/keys/nginx_signing.key
module_hotfixes=true

После настройки вы можете использовать команду yum для установки сервера nginx.

#centOS7默认是没有nginx安装包的。
$ yum search nginx
$ yum install nginx

Мы можем использовать команду find для просмотра пути установки nginx:

$ find / | grep nginx.conf

Кроме того, на официальном веб-сайте Nginx представлены способы быстрой установки, такие как RHEL/CentOS, Debian, Ubuntu и т. д.

📦Официальное руководство по установке, предоставленное Nginx (для ядра Linux)

Попробуйте запустить Nginx

Находим скрипт запуска Nginx, а затем запускаем службу Nginx (скрипт запуска Nginx находится в/usr/sbinПод содержанием):

$ /usr/sbin/nginx
# 或者直接nginx也可以。
# 或者systemctl start nginx
# 查看进程中是否有nginx
$ ps -ef | grep nginx

Файл конфигурации/etc/nginx/nginx.conf, если вы не можете найти путь конфигурации nginx, вы можете передатьfindкоманда найдена.

user  nginx;
worker_processes  1;

error_log  /var/log/nginx/error.log warn;
pid        /var/run/nginx.pid;

events {
    worker_connections  1024;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    #tcp_nopush     on;

    keepalive_timeout  65;

    #gzip  on;

    include /etc/nginx/conf.d/*.conf;
}

Наблюдая за последней строкой конфигурационного файла, автор заметил, что в этой скачиваемой версии конфигурация nginx разбросана по двум путям:/etc/nginx/conf.d/*.conf

давайте просмотрим это/cet.nginx/conf.d/каталог, изначально есть только один файл (/etc/nginx/conf.d/default.conf),пройти черезlistenМожно заметить, что порт запуска Nginx по умолчанию — 80.

server {
    listen       80;
    server_name  localhost;

    #charset koi8-r;
    #access_log  /var/log/nginx/host.access.log  main;

    location / {
        root   /usr/share/nginx/html;
        index  index.html index.htm;
    }

    #error_page  404              /404.html;

    # redirect server error pages to the static page /50x.html
    #
    error_page   500 502 503 504  /50x.html;
    location = /50x.html {
        root   /usr/share/nginx/html;
    }

    # proxy the PHP scripts to Apache listening on 127.0.0.1:80
    #
    #location ~ \.php$ {
    #    proxy_pass   http://127.0.0.1;
    #}

    # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
    #
    #location ~ \.php$ {
    #    root           html;
    #    fastcgi_pass   127.0.0.1:9000;
    #    fastcgi_index  index.php;
    #    fastcgi_param  SCRIPT_FILENAME  /scripts$fastcgi_script_name;
    #    include        fastcgi_params;
    #}

    # deny access to .htaccess files, if Apache's document root
    # concurs with nginx's one
    #
    #location ~ /\.ht {
    #    deny  all;
    #}
}

Мы вводим соответствующий URL-адрес в браузере (если порт прослушивания по умолчанию равен 80, мы не можем активно вводить номер порта) для доступа к серверу nginx, где hadoop102 — это имя хоста, которое настроил автор.

hadoop102

Когда вы видите эту страницу, это означает, что сервер Nginx, который мы запустили в виртуальной машине, был успешно запущен.

Настройка правил брандмауэра Linux

Когда брандмауэр Linux firewalld включен, мы не можем получить доступ к порту 80 без какой-либо настройки. Сначала мы используем команду брандмауэра для просмотра открытых в данный момент портов:

$ firewall-cmd --list-all

Ставим порт номер 80 открытым:

$ firewall-cmd --add-service=http --permanent
$ firewall-cmd --add-port=80/tcp --permanent
#重启firewall-cmd --reload
$ firewall-cmd --reload

Общие команды Nginx

Проверьте номер версии Nginx:

$ nginx -v
#笔者的安装版本是：
#nginx version: nginx/1.18.0

Запустите службу Nginx:

$ nginx

Остановите службу Nginx:

$ nginx -s stop

Перезагрузите Nginx (как мы упоминали в начале, Nginx поддерживает горячее развертывание, поэтому вам нужно только обновить службу Nginx):

$ nginx -s reload

Конфигурационный файл Nginx

Прежде всего, мы должны иметь ясное представление о следующих трех путях:

启动脚本 -> /usr/sbin/nginx
主配置文件 -> /etc/nginx/nginx.conf
副配置文件-> /etc/nginx/conf.d/default.conf

Файл конфигурации Nginx в основном состоит из трех блоков:глобальный блок, блок событий, блок http. Среди них блок http является ядром, которое можно подразделить в деталях. :

全局块
events块
http块
  ┗ http全局块
  ┗ server块
      ┗ 全局server块
      ┗ location块

глобальный блок

Область действия — от начала файла до части перед блоком событий. Конфигурация здесь будетВлияет на общую работу сервера nginx.

в,work_processУказывает количество запросов, которые могут обрабатываться одновременно. Эта конфигурация зависит от фактической аппаратной/программной конфигурации машины.

work_process 1

блок событий

Конфигурация здесь будетВлияет на сетевые подключения к серверам Nginx и пользователям..

в,worker_connectionsУказывает максимальное количество подключений, которое повлияет на общую производительность Nginx, поэтому его следует настраивать гибко.

http-блок

Этот блок является основным содержимым конфигурации. Блок http также состоит из двух частей: глобального блока http и блока сервера. Среди них nginx по умолчанию переносит блок сервера в другой файл конфигурации.

Глобальный блок http включает импортированные файлы (например, файл конфигурации, в котором находится импортированный блок сервера), определения MIME-TYPE, настройки журнала, время ожидания соединения и верхний предел количества одноканальных запросов.

серверный блок

Блок сервера и виртуальный хост тесно связаны, и с точки зрения клиента нет никакой разницы между виртуальным хостом и независимым хостом. Это в основном для экономии стоимости оборудования интернет-сервера.

Блок http может содержать несколько серверных блоков. Каждый блок сервера эквивалентен виртуальному хосту. Каждый серверный блок делится на глобальный серверный блок и один (или более) блок локации..

Ниже представлен один из виртуальных хостов: запустите локально и откройте порт 80.

listen			80;
server_name		localhost;

Блок location настраивает сопоставление URL-адресов запросов и ресурсов (мы настроим более подробно в последующих примерах).На самом деле в исходном файле конфигурации есть много связанной информации.location, но мы можем в основном вывести его общую функцию.

location / {
	root html;
	index index.html index.htm
}

Настроить обратный прокси

Мы рассмотрели роль обратного прокси-сервера во введении в Nginx. мы в основном зависим отhttp block -> servr block ->location blockдля настройки определенного обратного прокси. Для динамических запросов мы часто используемproxy_passСопоставьте с соответствующим портом указанного номера хоста. Для статических запросов мы также можем использоватьrootУстановите этот компьютер в качестве сервера статических ресурсов для возврата статических страниц (подробности см. в главе о настройке динамического и статического разделения). Нам также необходимо базовое понимание части местоположения, соответствующей uri, чтобы избежать непредвиденных проблем 404.

Директивы конфигурации о местоположении

На самом деле location может содержать следующие формы:

location [ = | ~ | ~* | ^~ ] uri{
	....
}

  • =Представляет самое строгое точное совпадение. Например, настройте местоположение следующим образом:

    # www.nginxText.com/hi/a.html => 127.0.0.1:9998/hello/a.html
location = /hi/a.html {
	proxy_pass http://127.0.0.1:9998;
}

  • ^~выражатьдо совпадения с регулярным выражениемВыполните сопоставление префиксов.

    # www.nginxText.com/hi/a.html => 127.0.0.1:9998/helloworld/a.html
location ^~ /hi {
	proxy_pass http:127.0.0.1:9998/helloworld
}

  • ~просьбаuri содержит регулярное соответствие с учетом регистра.

    # www.nginxText.com/hello/a.html => 127.0.0.1:9998/hello/a.html
location ~ /hello/ {
	#不允许在proxy_pass配置uri
	proxy_pass http:127.0.0.1:9998
}

  • ~*просьбаuri содержит обычные совпадения без учета регистра.

    # www.nginxText.com/hello/cafe.jpg => 127.0.0.1:9998/hello/cafe.jpg
# www.nginxText.com/hello/cafe.JPG => 127.0.0.1:9998/hello/cafe.jpg
location ~* \.(jpg|png)$ {
	#不允许在proxy_pass配置uri
	proxy_pass http:127.0.0.1:9998
}

  • Без какого-либо символа это означаетпосле совпадения с регулярным выражениемВыполните сопоставление префиксов.

соответствующий заказ

Порядок соответствия следующий (источник изображения):

(location `=` ) 
(location `完整路径` )  
(location `^~` 路径)  
(location `~`,`~*` 正则顺序) 
(location 部分起始路径) 
(location `/`)

Обратите внимание на следующие моменты:

  1. Сопоставление префиксов следует принципу наибольшего совпадения.

  2. При обычном сопоставлении (~и~*), настроенныйproxy_passВключение uri не допускается. В противном случае будет сообщено об ошибке:

    "proxy_pass" cannot have URI part in location given by regular expression

Дополнительные сведения о сопоставлении местоположенияобратитесь сюда.

Обратный прокси сервер Tomcat

Согласно конфигурации обратного прокси, мы в основном хотим добиться следующих эффектов:

Откройте браузер, введите www.nginxtest.com, чтобы получить доступ к нашему серверу Nginx, сервер Nginx перенаправляет запрос на сервер Tomcat в системе виртуальной машины.

Во-первых, введите физическую машину (физическая машина автора - система Window10)C:\Windows\System32\drivers\etcВ каталоге измените файл hosts и добавьте следующую строку в конец файла:

{虚拟机ip地址} www.nginxtest.com

Затем введите прямо в браузереwww.nginxtest.com, порт доступа по умолчанию 80, вы можете получить доступ к службе Nginx, запущенной на виртуальной машине.

Автор использует Docker для запуска контейнера tomcat здесь, а сопоставление портов0.0.0.0:10000->8080. Теперь, чтобы получить доступ к сервису Tomcat, нам нужно ввести:

www.nginxtest.com:10000/

Мы хотим войти толькоwww.nginxtest.comВы можете получить доступ к серверу Tomcat, поэтому вам необходимо настроить обратный прокси-сервер Nginx.

Мы открываем файл конфигурации Nginx и добавляем следующую конфигурацию местоположения в домен сервера, указывая, что мы будем:

www.nginxtest.com/helloworldсопоставить с127.0.0.1:10000/helloworld. (по умолчанию tomcat вернется/helloworld/index.jsp)

location /helloworld {
	proxy_pass http://127.0.0.1:10000;
}

Затем обновите сервер Nginx:

$ nginx -s reload

Набираем в браузереwww.nginxtest.com, вы можете позволить Nginx сопоставляться с сервером Tomcat, фактически работающим на виртуальной машине, через обратный прокси-сервер.

Сопоставьте разные серверы Tomcat на основе URI

Настроив обратный прокси, мы надеемся добиться следующих эффектов:

www.nginxtest.com/hi/* -> 127.0.0.1:10000/hi/*

www.nginxtest.com/hello/* ->127.0.0.1:9998/hello/*

когда путь/hi/.., перешлите этот запрос127.0.0.1:10000соответствующий/hi/..ресурсы под ; когда путь/hello/.., перешлите этот запрос127.0.0.1:10000соответствующий/hello/..ресурсы под;

Автор использует образ Docker Tomcat для создания нового экземпляра здесь, а сопоставление портов0.0.0.0:9998->8080.

мы открытыdefault.conf, настройте следующим образом:

location ~ /hi/ {
	proxy_pass http://127.0.0.1:10000;
}

location ~ /hello/ {
	proxy_pass http://127.0.0.1:9998;
}

Обратите внимание, что в этой конфигурации есть еще один~символ, означающий регулярное совпадение. Эта конфигурация сообщает Nginx: все включают/hi/URI запроса будет перенаправлен на сервер Tomcat через порт 10000; все содержащие/hello/URI перенаправляются на сервер Tomcat через порт 9998. Обратите внимание, что каждый элемент конфигурации должен быть приведен после;символ.

Настроить балансировку нагрузки

Мы хотим добиться такого эффекта: и Tomcat1 (порт 10000), и Tomcat2 (порт 9998) имеют/helloworld/b.htmlРесурсы (чтобы наблюдать эффект, вы можетеb.htmlСделайте следующий знак отличия). Когда клиент постоянно запрашивает URI этого ресурса, есть надежда, что Nginx сможет выполнить балансировку нагрузки в соответствии с соответствующей стратегией.

Самая базовая конфигурация

Открытым/etc/nginx/nginx.confосновной файл конфигурацииhttp-блок, настроить динамические группы серверов:

#upstream 后面加上自己配置的服务器组名字。
upstream dynamic {
    server localhost:10000; # docker->tomcat
    server localhost:9998; # docker->tomcat
}

сохранить и выйти, войти в/etc/nginx/conf.d/default.confизсерверный блоквниз вproxy_passНастройте имя группы серверов в элементе.

location = /helloworld/b.html {
	proxy_pass http://dynamic;
}

Эта конфигурация являетсяточное совпадение. указывает при посещении/helloworld/b.htmlКогда этот ресурс используется, Nginx решит получить доступ к Tomcat1 или Tomcat2 в соответствии со стратегией балансировки нагрузки.

пройти черезnginx -s reloadСохраните конфигурацию и введите в браузере:www.nginxTest/helloworld/b.html, и многократно обновляется, можно заметить, что содержимое каждый раз разное, что доказывает эффективность стратегии балансировки нагрузки Nginx.

Стратегия балансировки нагрузки в Nginx

Вышеупомянутое является лишь самой базовой сложной сбалансированной конфигурацией.На самом деле, в зависимости от конфигурации сервера следует применять разные стратегии. Nginx поддерживает 6 стратегий балансировки нагрузки, но 2 из них должны полагаться на третьи стороны. Здесь подробно описаны четыре часто используемых метода.

параметр Способ
Не выполнять никаких настроек, по умолчаниюголосованиеСпособ.
weight на основе опроса, вес элемента конфигурации сервера указывается после элемента конфигурации.
ip_hash в соответствии сipМетод распределения решает междоменную проблему сеансов.
least_conn наименьшая связь
fair(третья сторона) метод времени отклика
url_hash(третья сторона) По способу распространения URL

режим опроса (по умолчанию)

опросupstreamСтратегия балансировки нагрузки по умолчанию, когда запросы распределяются по каждому серверу в хронологическом порядке. Стратегию опроса можно настроить со следующими параметрами:

параметр эффект
fail_timeout Установите время ожидания, используемое в сочетании с max_fails.
max_fails Установите максимальное количество отказов за время, заданное параметром fail_timeout, если все запросы к серверу не будут выполнены в течение этого времени, сервер будет считаться неработающим.
fail_time Продолжительность времени, в течение которого сервер будет считаться отключенным, по умолчанию — 10 с.
backup Отметьте этот сервер как альтернативный сервер. Когда основной сервер останавливается, на него отправляются запросы.
down Сервер маркеров постоянно недоступен.

Стратегия опроса подходит для конфигурации между различными серверами без сохранения состояния (нет необходимостиcoookie,session) Сервисы.

весовой метод

Без какой-либо настройки вес каждого сервера по умолчанию равен 1.

Чем выше вес сервера, тем выше вероятность пропуска трафика. Он часто используется, когда разрыв в конфигурации сервера велик. Мы позволим более производительным серверам обрабатывать больше трафика.

#upstream 后面加上自己配置的服务器组名字。
upstream dynamic {

	# 假定此服务器性能更好，则上调它的访问权重。
    server localhost:10000 weight=2; 
    
    # 如果20秒内有10个请求都失败了，则该server会被停用。
    server localhost:9998 max_fails=10 fail_timeout=20; 
}

метод ip_hash

sessionИспользуется для записи сеанса клиент сервер, поэтому службы с отслеживанием состояния не могут напрямую пересекать серверы. Мы используемip_hashна основе клиентаipРаспределить, чтобы гарантировать, что запросы от одного и того же клиента будут отправляться только на указанный сервер, чтобы гарантировать, чтоsessionсостояние сеанса.

#upstream 后面加上自己配置的服务器组名字。
upstream dynamic {
	#每个访客分配到固定的服务器中。
	ip_hash; 
	
	# ip_hash方式可以基于轮询一起使用。
    server localhost:10000 weight=2; 
    server localhost:9998 max_fails=10 fail_timeout=20; 
}

Обратите внимание на следующее:

  • При использованииip_hash, вы больше не можете назначить альтернативный серверbackup(Имеет смысл, так как даже резервный сервер не регистрируетsessionинформация, бессмысленная).

  • До версии Nginx 1.3.1 было невозможноip_hashВес настраивается в политике.

  • Когда сервер необходимо удалить, его необходимо отключить вручную.

наименьший_подход

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

#upstream 后面加上自己配置的服务器组名字。
upstream dynamic {
	#基于连接数分配。
	least_conn
	
    server localhost:10000 weight=2; 
    server localhost:9998 max_fails=10 fail_timeout=20; 
}

применять кВремя обработки разных запросов существенно различаетсяСлучай.

Настройка динамического и статического разделения

Разделение динамических и статических заключается в том, чтобы отличать статические ресурсы (изображения, видео, css, js и другие файлы) от динамических ресурсов (jsp, php). Динамическое разделение заключается не в том, чтобы просто различать эти два ресурса, а в том, чтобы использовать Nginx для обработки статических ресурсов и Tomcat (или другие серверы) для обработки динамических ресурсов.

Кроме того, настроив обратный прокси-сервер и параметры expires,Мы можем напрямую отправить некоторые статические ресурсы, которые не часто меняются, в браузер другой стороны для сохранения.

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

Обычно сервер отправляет два кода состояния:

  1. 304 => Файл не изменился, браузер напрямую использует кешированный ресурс.
  2. 200 => Файл был изменен, и браузер успешно загрузил новый файл.

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

Конфигурация динамического и статического разделения

Перед разделением статики и динамики автор сначала/usr/images/сохранить некоторые в каталоге.jpg,.pngи другие форматы файлов изображений, а также настроить локальный репозиторий как статический ресурс.

Способ настройки 1: сопоставление префикса

location ^~ /images {
	root /usr;
	autoindex on;
}

Поскольку мы используем локальную папку напрямую, здесь настроено следующее:root. поэтому все префиксы удовлетворяют/images/...Ресурсы будут сопоставлены с локальным/usr/iamges/...под дорожкой.

При настройкеautoindex on;, мы можем ввести в браузереwww.nginxTest.com/images/Просмотрите все файлы по этому пути напрямую. Чтобы китайские файлы не отображали искаженные символы, рекомендуетсясерверный блокСредняя конфигурацияcharset utf-8.

Способ конфигурации 2: обычное сопоставление

Другая идея состоит в том, чтобы встретить все суффиксы имени.jpg, .JPG, .png, .PNGПри ожидании URI файла используйте собственную библиотеку статических ресурсов. Поскольку имя префикса здесь не точно, здесь будетautoindex on;опция удалена.

location ~* \.(jpg|png|gif|jepg)$ {
	root /usr;
}

Если статические ресурсы размещены на другом сервере, вы также можете использоватьproxy_passДелайте обратный прокси.

Установить кеш с истекающим сроком действия

Настройка срока действия относительно проста, мы можем настроить ее непосредственно внутри локации. Синтаксис следующий:

expires 30s;   #缓存30秒
expires 30m;   #缓存30分钟   
expires 2h;    #缓存2小时
expires 30d;   #缓存30天

Мы прямо сейчас добавляем эту конфигурацию в обычное соответствие, обновляем Nginx, вводим uri в браузере и смотримresponse header:

location ~* \.(jpg|png|gif|jepg)$ {
	#缓存1天
	expires 1d
	root /usr;
}

Автор проверил его через инструмент Postman и отметил ключевые части.

Создайте кластер высокой доступности в локальной сети*

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

Изучив Nginx, мы можем нарисовать такую ​​топологию: разделить статические ресурсы на серверы ресурсов через динамическое и статическое разделение, дать возможность разным серверам работать вместе через балансировку нагрузки... Особенно автор, я только что научился использовать Docker для быстрого развертывания сервисов, и Я чувствую, что дерево навыков сильно засветилось.

На рисунке показана звездообразная топология, полностью построенная вокруг сервера Nginx, что требует от нас решения фатальной проблемы: если сам Nginx выйдет из строя, все запросы не будут выполняться. Таким образом, очевидно, что текущая практикаСуществует рискиз.

Конфигурация режима высокой доступности

Чтобы не класть все яйца в одну корзину, самый интуитивно понятный и очевидный способ — подготовить один (или несколько) резервных копий Nginx (резервных серверов).Когда мастер неожиданно выйдет из строя, резервная копия может быстро заменить работающего мастера.

Нам нужно использоватьkeepalivedРеализовать активно-резервный режим Nginx.В то же время он также скрывает детали от пользователей, позволяя пользователям получать доступ в соответствии с унифицированным интерфейсом..

Перед настройкой режима высокой доступности

Начнем со списка того, что необходимо для настройки режима высокой доступности:

  1. Два сервера (вместо них я использовал две виртуальные машины)
  2. Используйте поддерживающее программное обеспечение.
  3. Для проверки активности, чтобы определить, работает ли целевой Nginxисполняемыйсценарий.
  4. Требуется виртуальный IP-адрес (используется для предоставления унифицированного доступа пользователям).
  5. Отключите SElinux, очистите правила iptables, отключите брандмауэр.

keepalived обнаруживает процесс Nginx

Внутри кластера поддержки активности есть несколько серверов Nginx,При работе этого кластера в рабочем состоянии находится только один Nginx, то есть Master (хост), а остальные Nginx находятся в состоянии Backup (кандидат).. Keepalived на каждом хосте отслеживает состояние Nginx, работающего на этой машине.

Однако независимо от того, выполняет ли главный или резервный обратный прокси работу, это невидимо для клиентов. Это делается в основном за счет предоставления единого VIP (Virtual IP)реализовать. Таким образом, независимо от того, кто работает, клиенты запрашивают обслуживание только через этот VIP.

keepalived работает на основе режима широковещательной рассылки arp, так что все keepalived находятся в локальной сети. (Если несколько облачных серверов используются друг для друга, они должны быть настроены в одном и том же виртуальном частном облаке VPC)

Keepalived для каждого хоста привязан к Nginx только для этой машины. keepalived будет использовать скрипт, чтобы определить, находится ли локальный Nginx в нормальном состоянии (или выполнить проверку работоспособности). Когда keepalived обнаруживает, что Nginx находится в неперезапускаемом состоянии,Он прервет свой собственный процесс проверки активности вместе.(что означает «Nginx умер» для этой машины).

Каждый keepalived в кластере будетОбнаружение сердцебиения(реализовано в виде мультикаста). Когда другой keepalived «обнаружит» keepalived Мастера (указывая на то, что Master Nginx не работает), он выберет кандидата из Резервной копии, чтобы получить право на использование VIP, а затем путь, введенный клиентом, будет полностью за этого кандидата отвечает Nginx.

Для фактического рабочего узла Nginx мы можем передатьip addrУбедитесь, что сетевой порт привязан к VIP. И узел в состоянии кандидата,ip addrVIP-привязки нет.

Конфигурация keepalived может принимать две формы:

  1. Упреждающий (по умолчанию), после отказа основного узла резервная машина будет работать. Когда основной узел перезапустится, резервный вернется в состояние кандидата.
  2. Без вытеснения, после отказа основного узла работает резервная машина. Когда основной узел перезагружается, резервная машина продолжает работать.

Настройте Nginx для другой виртуальной машины

Ранее мы настроили обратный прокси-сервер Nginx/балансировку нагрузки/динамическое и статическое разделение в хосте «hadoop102», поэтому в Nginx из hadoop102 многие конфигурации указывают на «localhost», «127.0.0.1».

Для нового хоста «hadoop101» эти конфигурации должны быть заменены хостом hadoop102 или его IP-адресом соответственно. Мы напрямую скопировали файл конфигурации предыдущего хоста hadoop102 и исправили его.nginx.confиdefault.confНекоторые детали:

upstream dynamic{
    #由于这次我们需要通讯，所以要配置max_fails和fail_timeout。
	server hadoop102:10000 max_fails=10 fail_timeout=10s;
	server hadoop102:9998 max_fails=10 fail_timeout=10s;
}

существуетdefault.confВнесите следующие изменения, каталог статических ресурсов больше не находится на этой машине, поэтому для проксирования требуется proxy_pass.

location ~* \.(jpg|png|gif|jepg)$ {
	expires 1d;
	proxy_pass http://hadoop102;
}

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

В случае работы MASTER Nginx в состоянии BACKUP по-прежнему работает нормально.

установить поддержку активности

Уведомление! ! Пожалуйста, внимательно прочитайте каждую деталь следующего содержимого, потому что небольшая небрежность может привести к тому, что keepalived не будет работать должным образом.

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

$ yum install keepalived -y

Мы можем использовать команду find, чтобы найти каталог, в котором находится файл конфигурации поддержки активности (на самом деле он находится в/etc/keepalived/Под содержанием):

$ find / | grep keepalived.conf

Кроме того, на другой виртуальной машине также необходимо установить сервер Nginx, процесс см. выше.

Написать скрипты обнаружения

Настройки автора в скрипте определения работоспособности: keepalived попытается снова запустить службу Nginx, когда Nginx будет закрыт, и будет считаться мертвым, если обнаружится, что Nginx по-прежнему не может быть запущен через 2 секунды.

aftived использует сценарий для обнаружения того, работает ли цель Nginx правильно. Когда скрипт обнаруживает, что Master Nginx находится вниз, он переключится на резервное копирование Nginx.

#!/bin/bash
A=`ps -C nginx --no-header |wc -l`
if [ $A -eq 0 ];then
    systemctl start nginx
    sleep 2
    if [ `ps -C nginx --no-header |wc -l` -eq 0 ];then
        killall keepalived
    fi
fi

❗notes на написании скриптов:

  1. ввод командного режимаset ffПроверьте формат кодировки файла. Если формат кодирования отображаемого файлаdoc, вам нужно изменить наset off=unix.

  2. Этот скрипт должен быть настроен с помощьюxразрешения, вы можете использоватьchmod a+xвносить изменения.

Я сохраняю этот файл как/usr/local/src/nginx_check.sh. Лучше всего вручную выполнить этот скрипт для устранения проблемы, чтобы последующая проверка активности не вступила в силу.

Настройка поддержки активности [Тщательная настройка]

Конфигурационный файл для поддержки активности:/etc/keepalived/keepalive.conf.По умолчанию существует довольно много конфигураций по умолчанию.

Из этого примера мыТолько нужно использовать следующие три части:global_defs(глобальное определение),vrrp_script(для сценариев обнаружения необходимо добавить вручную),vrrp_instance(настроить виртуальный IP).

❗Для элементов конфигурации, которые нельзя использовать или функции которых неясны, настоятельно рекомендуется удалить их все, в противном случае очень легко заставить keepalived не действовать.

Сначала мы настроим мастер-узел Master в качестве примера:

Здесь нам не нужно отправлять и получать сообщения в виде почты. Таким образом, вglobal_defsраздел, нам просто нужно сохранитьrouter_idпункт, чтобы назвать ваш хост.

# 配置此主机的主机名。相当于在配置/etc/hosts
global_defs {
   router_id r1
}

Не в исходном файле конфигурацииvrrp_scriptвариант, нам нужно добавить его вручную.Путь к сценарию — это абсолютный путь к только что созданному сценарию.. Возможны отличия, внимательно проверяйте.

# vrrp_script后面的名称可以自定义（此处为check），但是要和稍后track_script块配置对应。
vrrp_script check {
   script  "/usr/local/src/nginx_check.sh"
   interval 4
}

❗ Обратите внимание, что этоintervalбольше, чем время сна в сценарииsleepбыть большим,В противном случае скрипт не запустится. (В авторском скрипте время сна равно 2, поэтому здесь настроено 4)

Среди них, вvrrp_instanceНам нужно внести 5 изменений, которые автор дал в виде комментариев. Фактическое значение изменения зависит от вашей собственной сетевой среды, например от выбора VIP.В среде виртуальной машины нам нужно только выбрать любой незанятый IP-адрес интрасети. Если это кластер высокой доступности, созданный облачным сервером, вам необходимо приобрести дополнительный HAVIP у поставщика услуг (Tencent Cloud, HUAWEI CLOUD)..

Физическая машина автора и кластер хост-машин подключены через NAT и находятся в сети 192.168.229.0/24.. Все хост-системы — это системы CentOS 7, поэтому имена портов сетевых картens33. Все они зависят от личной конфигурации и не могут быть вставлены напрямую.

vrrp_instance VI_1 {
    #1 可设置BACKUP和MASTER，取决于设置。
    state MASTER
    #2 配置成自己的网卡口！centOS7一般都叫ens33.
    #  可以使用ip addr来查看。
    interface ens33
    
    # 注意，同一个集群下的virtual_router_id必须保持一致！
    virtual_router_id 51
    
    #3 保证BACKUP的优先级要比MASTER的优先级低。
    priority 100
    
    # 设置每1秒组播心跳消息，证明keepalived还存活。
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass 1111
    }
    #4 这一块需要自己手动添加。注意要写到virtual_ipaddress项的上面！
    #  内部的脚本名称实际上取决于你刚才在vrrp_script的配置名称
    track_script {
        check
    }
    
    #5 无论是BACKUP/MASTER，为了让用户通过统一域名访问，因此都要选择统一的VIP。
    #  这个IP根据你的局域网IP号而定。
    virtual_ipaddress {
        192.168.229.171
    }
}

Для хостов, сконфигурированных как BACKUP, просто введитеstateПодойдет одна модификация.

Запустите поддерживающий кластер

Убедившись, что приведенная выше конфигурация готова, мы передаемsystemctlзапуск командыnginxиkeepalived.

$ systemctl start nginx
$ systemctl start keepalived.service

Убедитесь, что службы Nginx и keepalived запущены нормально:

$ systemctl status nginx
$ systemctl status keepalived.service

После запуска кластера сервер, находящийся в рабочем состоянии, может пройтиip addrпроверьте, чтобыens33Сетевой порт привязан к VIP.Другие хосты Nginx, которые работают, но находятся в состоянии кандидатаТогда нет привязки к VIP.

Если вы случайно ошибетесь!

Обязательно поищите подсказки в журнале и получите код ошибки, включив режим отладки на стороне браузера.

#nginx错误日志默认位置
cat /var/log/nginx/error.log

Автор обнаружил и устранил следующие ошибки:

(13: Permission denied) while connecting to upstream

Решение: это может быть вызвано открытием брандмауэра selinux, проверьте состояние брандмауэра:

$ sestatus -v

Здесь автор временно принимает прямое решение: отключить брандмауэр selinux.

# SELINUX = disabled
$ vim /etc/selinux/config
# 重启生效
$ reboot

Кроме того, поскольку у насupstreamКаждый из узлов имеет установленное время ожидания, поэтому, если все узлы находятся вdownстатус, файл журнала напечатает следующую ошибку:

...no live upstreams while connecting to upstream...

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

Решение высокой доступности в общедоступной сетевой среде

Alibaba Cloud: серверы Alibaba Cloud больше не поддерживают отдельные покупки IP-адресов, поэтому в общедоступной сетевой среде метод поддержания активности нельзя использовать для горячего резервного копирования. Однако, похоже, что Alibaba Cloud предоставляет услуги балансировки нагрузки напрямую? (Хотите поесть)

Принципы реализации Tencent Cloud и HUAWEI CLOUD схожи: вам нужно создать виртуальное частное облако VPC для нескольких облачных серверов, а затем приобрести их отдельно для плавания.HAVIP, связывать.

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

Дополнение Nginx

Мастер и рабочий

Когда мы используем команду ps для просмотра процесса, мы можем заметить, что служба Nginx на самом деле имеет два процесса:

$ ps -ef | grep nginx
#root       2016      1  0 10:49 ?        00:00:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
#nginx      2017   2016  0 10:49 ?        00:00:00 nginx: worker process

Количество рабочих процессов на самом деле может быть несколько. Это было нашим/etc/nginx/nginx.confнастроен вworker_processКоличество (по умолчанию 1, фактическое количество зависит от производительности машины). При внешнем доступе к серверу Nginx рабочие процессы проходят черезконкурироватьспособ получить это соединение.

В чем преимущество этого Мастера, управляющего несколькими Работниками?

  1. На основе этого шаблона мы можем использоватьnginx -s reloadГорячее развертывание Nginx: это делается для того, чтобы работники, обрабатывающие запросы, не отвлекались на текущую работу,Бездействующий воркер немедленно обновляет конфигурацию.
  2. Каждый работник независимпроцесс(без резьбы). Следовательно, экономятся накладные расходы, вызванные различными блокировками синхронизации. Кроме того, даже если отдельные воркеры закрываются из-за исключения, другие воркеры все еще могут нормально работать, что повышает общую стабильность Nginx и снижает риски.

Высокая производительность Nginx зависит от epoll ядра Linux 2.6 или kqueue ядра BSD для предоставления эффективных служб опроса состояния сетевых сокетов [время сложности составляет O(1)]. На ядре без этих двух сервисов он вырождается в низкопроизводительный select [*nix, в Windows он есть, а временная сложность O(n)], в Windows нет epoll и kqueue, а Nginx плохо работает с выберите в Windows.

Другое программное обеспечение базы данных NoSQL, Redis, по той же причине приводит к тому, что его производительность в Windows ниже по сравнению с платформами * nix.

Сколько рабочих мы должны установить наиболее подходящее число? Обычно мы устанавливаем это значение равным количеству процессоров физической машины.

worker_connection

Во-первых, вопрос: исходя из протокола Http 1.1, когда пользователь отправляет запрос на Worker, сколько подключений Worker будет занято? Ответ 2 или 4.

При доступе к статическим ресурсам Nginx должен занимать два соединения при возврате ресурсов напрямую из локального.

Когда Nginx выполняет обратное проксирование, ему необходимо занять 4 соединения.

Таким образом, если предположить, что значение подключения каждого рабочего процесса равно worker_connection, фактический объем одновременного доступа (относительно количества одновременных клиентских запросов) составляет:

  1. (worker_connection * worker_process) / 2 => как статический сервер

  2. (worker_connection * worker_process) / 4 => как обратный прокси-сервер

Категории