По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Из предыдущих статей (тут и тут) мы узнали, что очень немногие механизмы, учитывают изменения в топологии. Большинство этих решений ориентированы на вычисления loop-free пути через очевидно стабильную сеть. Но что происходит при изменении топологии? Как сетевые устройства создают таблицы, необходимые для пересылки пакетов по loop-free путям в сети?
В этой серии статей мы рассмотрим очередную подзадачу этой всеобъемлющей проблемы и ответим на вопрос: Как плоскости управления обнаруживают изменения в сети и реагируют на них?
На этот вопрос мы ответим, рассмотрев две составляющие процесса конвергенции в плоскости управления. Процесс конвергенции в сети может быть описан в четыре этапа. Рисунок 1 используется для справки при описании этих четырех стадий. Как только связь [C,E] выходит из строя, должны произойти четыре этапа: обнаружение, распространение, вычисление и установка.
Обнаружение изменения: будь то включение нового устройства или линии связи, или удаление устройства или линии связи, независимо от причины, изменение должно быть обнаружено любыми подключенными устройствами. На рисунке 1 устройства C и E должны обнаруживать отказ канала [C, E]; когда линия восстанавливается, они также должны обнаружить включение этой (очевидно новой) линии связи в топологию.
Распространение информации об изменении: каждое устройство, участвующее в плоскости управления, должно каким-то образом узнавать об изменении топологии. На рисунке 1 устройства A, B и D должны каким-то образом уведомляться о сбое канала [C, E]; когда линия будет восстановлена, они должны быть снова уведомлены о включении этой (очевидно новой) линии связи в топологию.
Вычисление нового пути к пункту назначения без петель: на рисунке 1 B и C должны вычислить некоторый альтернативный путь, чтобы достичь пунктов назначения за пределы E (или, возможно, непосредственно самого E).
Установка новой информации о пересылке в соответствующие локальные таблицы: На рисунке 1 B и C должны установить вновь вычисленные loop-free пути к пунктам назначения за пределами E в свои локальные таблицы пересылки, чтобы трафик мог коммутироваться по новому пути.
Далее мы сосредоточимся на первых двух из четырех шагов, описанных в предыдущем списке, размышляя в начале об обнаружении изменений топологии. Будут рассмотрены некоторые примеры протоколов, специализирующихся на обнаружении изменений топологии. Распределение топологии и информации о достижимости будет рассмотрена в конце этой серии статей. Поскольку эта проблема, по сути, является проблемой распределенной базы данных, она будет решаться с этой точки зрения.
Обнаружение изменений топологии
Первым шагом в реакции на изменение топологии сети является обнаружение изменения. Вернемся к рисунку 1. Каким образом два устройства, подключенные к каналу, C и E, обнаруживают сбой канала? Решение этой проблемы не так просто, как может показаться на первый взгляд, по двум причинам: информационная перегрузка и ложные срабатывания.
Информационная перегрузка возникает, когда плоскость управления получает так много информации, что просто не может распространять информацию об изменениях топологии и/или вычислять и устанавливать альтернативные пути в соответствующие таблицы на каждом устройстве достаточно быстро, чтобы поддерживать согласованное состояние сети. В случае быстрых, постоянно происходящих изменений, таких как отключение связи и подключение каждые несколько миллисекунд, плоскость управления может быть перегружена информацией, в результате чего сама плоскость управления потребляет достаточно сетевых ресурсов, чтобы вызвать сбой сети. Также возможно, что серия отказов вызовет петлю положительной обратной связи, и в этом случае плоскость управления “сворачивается” сама по себе, либо реагируя очень медленно, либо вообще отказывая. Решение проблемы информационной перегрузки состоит в том, чтобы скрыть истинное состояние топологии от плоскости управления до тех пор, пока скорость изменения не окажется в пределах, которые может поддерживать плоскость управления.
Ложные срабатывания - это проблема второго типа. Если канал отбрасывает один пакет из каждых 100, и каждый раз отбрасывается единственный пакет, который оказывается пакетом плоскости управления, используемым для отслеживания состояния канала, будет казаться, что канал выходит из строя и довольно часто возобновляет работу - даже если другой трафик перенаправляется по каналу без проблем.
Существует два широких класса решений проблемы обнаружения событий:
Реализации могут периодически отправлять пакеты для определения состояния канала, устройства или системы. Это опрос (Polling).
Реализации могут вызвать реакцию на изменение состояния канала или устройства в некотором физическом или логическом состоянии внутри системы. Это обусловлено событиями.
Как всегда, есть разные компромиссы с этими двумя решениями и подкатегории каждого из них.
Опрос (Polling) для обнаружения сбоев.
Опрос может выполняться удаленно или вне диапазона, или локально, или в группе. Рисунок 2 демонстрирует это.
На рисунке 2 A и B периодически отправляют приветствие или какой-либо другой пакет опроса по тому же каналу, через который они подключены, и по тому же каналу, по которому они пересылают трафик. Это внутриполосный опрос, который имеет преимущество отслеживания состояния канала, по которому пересылается трафик, передается информация о доступности и т. д. С другой стороны, D запрашивает у A и B некоторую информацию о состоянии канала [A, B] из другого места в сети. Например, D может периодически проверять состояние двух интерфейсов на канале [A, B] или, возможно, периодически отправлять пакет по пути [C, A, B, C] и т. д. Преимущество заключается в том, что информация о состоянии большого количества каналов может быть централизована, что упрощает управление сетью и устранение неполадок. Оба типа опроса часто используются в реальных сетевых развертываниях.
Для работы механизмов опроса часто используются два отдельных таймера:
Таймер для определения частоты передачи опроса. Он часто называется интервалом опроса в случае внеполосного опроса и часто называется таймером приветствия в случае внутриполосного опроса.
Таймер, чтобы определить, как долго ждать, прежде чем объявить связь или устройство отключенным, или включить сигнал тревоги. Это часто называют мертвым интервалом или мертвым таймером в случае внутриполосного опроса.
Цели внутриполосного и внеполосного опроса часто различаются. Внеполосный опрос для обнаружения изменений в состоянии сети часто (но не всегда - особенно в случае централизованной плоскости управления) используется для мониторинга состояния сети и позволяет централизованно реагировать на изменения в состоянии. Внутриполосный опрос наиболее часто используется (как и следовало ожидать) для локального обнаружения изменений состояния, чтобы управлять реакцией распределенных плоскостей управления.
Обнаружение сбоев на основе событий
Обнаружение сбоев на основе событий основывается на некотором локальном, измеримом событии для определения состояния конкретного канала или устройства. Рисунок 3 демонстрирует это.
На рисунке 3, который показывает одну из возможных реализаций элементов архитектуры между физическим интерфейсом и протоколом маршрутизации, есть четыре шага:
Связь между двумя микросхемами физического интерфейса (phy), расположенными на обоих концах связи, не работает. Микросхемы физического интерфейса обычно являются оптическими для электрических передач обслуживания. Большинство микросхем физического интерфейса также выполняют некоторый уровень декодирования входящей информации, преобразуя отдельные биты в сети в пакеты (десериализация) и пакеты в биты (сериализация). Информация кодируется физическим интерфейсом на носителе, который предоставляется двумя физическими микросхемами, подключенными к физическому носителю. Если канал не работает или один из двух интерфейсов отключен по какой-либо причине, микросхема физического интерфейса на другом конце канала увидит падение несущей почти в реальном времени - обычно в зависимости от скорости света и длины физического носителя. Это состояние называется потерей носителя.
Микросхема физического интерфейса при обнаружении потери несущей отправляет уведомление в таблицу маршрутизации (RIB) на локальном устройстве. Это уведомление обычно запускается как прерывание, которое затем транслируется в некоторую форму вызова интерфейса прикладного программирования (API) в код RIB, что приводит к тому, что маршруты, доступные через интерфейс, и любая информация о следующем переходе через интерфейс помечаются как устаревшие или удаляются из таблицы маршрутизации. Этот сигнал может или не может проходить через базу пересылаемой информации (FIB) по пути, в зависимости от реализации.
RIB будет уведомлять протокол маршрутизации о маршрутах, которые он только что удалил из локальной таблицы, на основе события отключения интерфейса.
Протокол маршрутизации затем может удалить любых соседей, доступных через указанные интерфейсы (или, скорее, через подключенные маршруты).
На рисунке 3 нет места, в котором бы присутствовал периодический процесс, проверяющий состояние чего-либо, а также не было бы пакетов, перемещающихся по сети. Весь процесс основан на том, что микросхема физического интерфейса теряет носитель на подключенной среде, следовательно, этот процесс управляется событиями.
Часто бывает, что состояние, управляемое событиями, и статус опроса совмещаются. Например, на рисунке 3, если бы станция управления периодически опрашивала статус интерфейса в локальном RIB, процесс от набора микросхем физического интерфейса к RIB был бы управляемым событием, а процесс от RIB на станцию управления будет направлен опросом.
Сравнение обнаружения на основе событий и на основе опроса
Таблица 1 отображает преимущества и недостатки каждого механизма обнаружения событий.
Внеполосный опросВнутриполосный опросУправляемый событиямиРаспределение статусовСтатус управляется централизованной системой; централизованная система имеет более полное представление об общем состоянии сетиСтатус определяется локальными устройствами; для получения более широкой картины состояния всей сети требуется сбор информации с каждого отдельного сетевого устройстваСтатус определяется локальными устройствами; для получения более широкой картины состояния всей сети требуется сбор информации с каждого отдельного сетевого устройстваСвязь состояния пересылки со связью или состоянием устройстваСообщение о состоянии связи и / или устройства может быть ложным; не проверяет возможность пересылки напрямуюСостояние канала и/или устройства может быть напрямую связано с возможностью пересылки (исключение сбоев в механизме проверки состояния)Состояние канала и/или устройства может быть напрямую связано с возможностью пересылки (исключение сбоев в механизме проверки состояния)Скорость обнаруженияПеред объявлением канала или устройства должен пройти некоторый интервал ожиданияне удалось предотвратить ложные срабатывания; замедляет сообщение об изменениях в сетиПеред объявлением канала или устройства должен пройти некоторый интервал ожиданияне удалось предотвратить ложные срабатывания; замедляет сообщение об изменениях в сетиНекоторый таймер перед сообщением о сбоях может быть желательным, чтобы уменьшить сообщение о ложных срабатываниях, но этот таймер может быть очень коротким и подкрепляться двойной проверкой состояния самой системы; как правило, гораздо быстрее при сообщении об изменениях сетиМасштабированиеДолжен передавать периодические опросы, потребляя пропускную способность, память и циклы обработки; масштабируется в этих пределахДолжен передавать периодические опросы, потребляя пропускную способность, память и циклы обработки; масштабируется в этих пределахНебольшие объемы текущего локального состояния; имеет тенденцию масштабироваться лучше, чем механизмы опроса
Хотя может показаться, что обнаружение, управляемое событиями, всегда должно быть предпочтительным, есть некоторые конкретные ситуации, когда опрос может решить проблемы, которые не могут быть решены механизмами, управляемыми событиями. Например, одно из главных преимуществ систем, основанных на опросе, особенно при внутриполосном развертывании, заключается в том, чтобы «видеть» состояние невидимых блоков. Например, на рисунке 4 два маршрутизатора соединены через третье устройство, обозначенное на рисунке как ретранслятор.
На рисунке 4 устройство B представляет собой простой физический повторитель. Все, что он получает по каналу [A, B], он повторно передает, как и получил, по каналу [B, C]. На этом устройстве нет какой-либо плоскости управления (по крайней мере, о том, что известно A и C). Ни A, ни C не могут обнаружить это устройство, поскольку оно не изменяет сигнал каким-либо образом, который мог бы измерить A или C.
Что произойдет, если канал [A, B] выйдет из строя, если A и B используют управляемый событиями механизм для определения состояния канала? A потеряет несущую, конечно, потому что физический интерфейс в B больше не будет доступен. Однако C будет продолжать принимать несущую и, следовательно, вообще не обнаружит сбой соединения. Если A и C могут каким-то образом общаться с B, эту ситуацию можно разрешить. Например, если B отслеживает все запросы протокола разрешения адресов (ARP), которые он получает, он может, когда канал [A, B] разрывается, каким-то образом отправить «обратный ARP», уведомляющий B о том, что A больше недоступен. Другое решение, доступное в этой ситуации, - это своего рода опрос между A и C, который проверяет доступность по всему каналу, включая состояние B (даже если A и C не знают, что B существует).
С точки зрения сложности, управляемое событиями обнаружение увеличивает поверхности взаимодействия между системами в сети, в то время как опрос имеет тенденцию сохранять состояние внутри системы. На рисунке 3 должен быть какой-то интерфейс между чипсетом физического интерфейса, RIB и реализацией протокола маршрутизации. Каждый из этих интерфейсов представляет собой место, где информация, которая может быть лучше скрыта через абстракцию, передается между системами, и интерфейс, который должен поддерживаться и управляться. Опрос, с другой стороны, часто может проводиться в рамках одной системы, полностью игнорируя существующие механизмы и технологии.
Пример: обнаружение двунаправленной переадресации
В этом подразделе будет изучен пример протокола, разработанного специально для определения состояния канала в сети. Ни один из этих протоколов не является частью более крупной системы (например, протокола маршрутизации), а скорее взаимодействует с другими протоколами через программные интерфейсы и индикаторы состояния.
Обнаружение двунаправленной переадресации (Bidirectional Forwarding Detection - BFD) основано на одном наблюдении: на типичном сетевом устройстве работает множество плоскостей управления, каждая со своим собственным механизмом обнаружения сбоев. Было бы более эффективно использовать один общий механизм обнаружения для всех различных плоскостей управления. В большинстве приложений BFD не заменяет существующие протоколы приветствия, используемые в каждой плоскости управления, а скорее дополняет их. Рисунок 5 демонстрирует это.
В модели BFD, скорее всего, будет по крайней мере два различных процесса опроса, работающих по одному и тому же логическому каналу (их может быть больше, если есть логические каналы, наложенные поверх других логических каналов, поскольку BFD также может использоваться в различных технологиях сетевой виртуализации). Опрос плоскости управления будет использовать приветствия (hellos) для обнаружения соседних устройств, выполняющих один и тот же процесс плоскости управления, для обмена возможностями, определения максимального блока передачи (MTU) и, наконец, для того, чтобы убедиться, что процесс плоскости управления на соседнем устройстве все еще работает. Эти приветствия проходят через соединение плоскости управления на рисунке 5, которое можно рассматривать как своего рода «виртуальный канал», проходящий через физический канал.
Опрос BFD будет выполняться под соединением уровня управления, как показано на рисунке, проверяя работу физического соединения и плоскостей пересылки (переадресации) на двух подключенных устройствах. Этот двухуровневый подход позволяет BFD работать намного быстрее, даже в качестве механизма опроса, чем любой механизм обнаружения на основе протокола маршрутизации.
BFD может работать в четырех различных режимах:
Асинхронный режим: в этом режиме BFD действует как облегченный протокол приветствия. Процесс BFD в A, потенциально работающий в распределенном процессе (или даже в специализированной интегральной схеме [ASIC]), отправляет пакеты приветствия в C. Процесс BFD в C подтверждает эти пакеты приветствия. Это довольно традиционное использование опроса через hellos.
Асинхронный режим с эхом: в этом режиме процесс BFD в A будет отправлять пакеты приветствия в C, поэтому пакеты приветствия будут обрабатываться только через путь пересылки, что позволяет опрашивать только путь пересылки. Для этого A отправляет пакеты приветствия в C, сформированные таким образом, что они будут переадресованы обратно в A. Например, A может отправить пакет C с собственным адресом A в качестве пункта назначения. C может забрать этот пакет и переслать его обратно к A. В этом режиме приветствия, передаваемые A, полностью отличаются от приветствий, передаваемых C. Подтверждения нет, только две системы посылают независимые приветствия, которые проверяют связь в двух направлениях с каждого конца.
Режим запроса: В этом режиме два одноранговых узла BFD соглашаются отправлять приветствия только тогда, когда подключение должно быть проверено, а не периодически. Это полезно в том случае, когда существует какой-то другой способ определения состояния канала—например, если канал [A, C] является каналом Ethernet, что означает, что обнаружение несущей доступен для обнаружения сбоя канала, - но этот альтернативный метод не обязательно является надежным для обеспечения точного состояния соединения во всех ситуациях. Например, в случае «коммутатора посередине», где B отключен от A, но не C, C может послать BFD привет, отметив любую проблему с подключением, чтобы убедиться, что его соединение с A все еще есть. В режиме запроса некоторые события, такие как потерянный пакет, могут вызвать локальный процесс для запуска события обнаружения BFD.
Режим запроса с эхом: этот режим похож на режим запроса - обычные приветствия не передаются между двумя устройствами, на которых работает BFD. Когда пакет передается, он отправляется таким образом, чтобы другое устройство переадресовало пакет приветствия обратно отправителю. Это снижает нагрузку на процессор на обоих устройствах, позволяя использовать гораздо более быстрые таймеры для приветствий BFD.
Независимо от режима работы, BFD вычисляет различные таймеры опроса (hello) и обнаружения (dead) отдельно по каналу связи. Лучший способ объяснить этот процесс-на примере. Предположим, что A отправляет управляющий пакет BFD с предлагаемым интервалом опроса 500 мс, а C отправляет управляющий пакет BFD с предлагаемым интервалом опроса 700 мс. Для связи выбирается большее число или, скорее, более медленный интервал опроса. Объясняется это тем, что более медленная система должна быть в состоянии идти в ногу с интервалом опроса, чтобы предотвратить ложные срабатывания.
Частота опроса изменяется при фактическом использовании, чтобы предотвратить синхронизацию пакетов приветствия в нескольких системах на одном и том же проводе. Если было четыре или пять систем, развертывающих Border Gateway Protocol (BGP) на одном канале множественного доступа, и каждая система устанавливает свой таймер для отправки следующего пакета приветствия на основе получения последнего пакета, все пять систем могут синхронизировать их передачу приветствия, чтобы все приветствия по сети передавались в один и тот же момент. Поскольку BFD обычно работает с таймерами длиной менее одной секунды, это может привести к тому, что устройство будет получать приветствия от нескольких устройств одновременно и не сможет обрабатывать их достаточно быстро, чтобы предотвратить ложное срабатывание.
Конкретная используемая модификация заключается в джиттере пакетов. Каждый передатчик должен взять базовый таймер опроса и вычесть некоторое случайное количество времени, которое составляет от 0% до 25% от таймера опроса. Например, если таймер опроса составляет 700 мсек, как в приведенном примере, A и C будут передавать каждый пакет приветствия примерно между 562 и 750 мсек после передачи последнего приветствия.
Последний момент, который следует учитывать, - это количество времени, в течение которого A и C будут ждать перед объявлением соединения (или соседа) отключенным. В BFD каждое устройство может вычислить свой собственный таймер отключения, обычно выраженный как кратное таймеру опроса. Например, A может решить считать канал (или C) отключенным после пропуска двух приветствий BFD, в то время как C может решить дождаться пропуска трех приветствий BFD.
В этом руководстве узнаем, как настроить сервер Nginx для производственной среды.
Тестовый веб-сервер отличается от рабочего сервера в планах безопасности и производительности.
По умолчанию, веб-сервер Ngnix готов к работе сразу после установки. Тем не менее, настройки по умолчанию недостаточны для рабочего севера. Поэтому мы сфокусируемся на настройке сервера для большей производительности в случае высокой и нормальной нагрузки, а также на настройках безопасности в целях защиты от любопытного пользователя.
Если у вас не установлен веб-сервер, можете узнать, как сделать это перейдя по ссылке. Здесь показано как установить Ngnix на Unix платформы. Рекомендуется выбирать установку из исходного кода, так как обычный релиз не включает некоторые модули, используемые в этом руководстве.
Настройка производительности и безопасности Nginx
Требования
У вас должны быть установлены нижеследующие компоненты и убедитесь, что веб-сервер запущен на системе на базе Debian, например Ubuntu.
Ubuntu или любая система семейства Debian
wget
Vim (текстовый редактор)
Также имейте ввиду, что некоторые команды из этого руководства придется запускать от имени привилегированного пользователя пользуясь командой sudo.
Разбор структуры конфигурации Nginx
В этом разделе рассмотрим следующие вопросы:
Структура Nginx
Разделы событий, HTTP и Mail
Правильный синтаксис Nginx
В конце раздела узнаете об структуре конфигурационного файла Nginx, роль и назначение каждого раздела и как задавать директивы внутри разделов.
Весь файл конфигурации Nginx разделен на такие разделы, как event section, http section, mail section и т.д.
Основной конфигурационный файл расположен по пути /etc/ngnix/ngnix.conf, а другие - /etc/nginx.
Основная секция
В этой секции расположены директивы, для которых нет специальных разделов. Такие директивы как user nginx, worker_processes 1, error_log /var/log/nginx/error.log warn, pid /var/run/nginx.pid могут быть расположены в этом разделе.
Но некоторые из этих директив могут быть в секции event, например werker_processes.
Разделы (Секции)
В Nginx разделы используются для определения конфигурации разных модулей. Например, секция http section содержит настройки ngx_http_core module, секция even section определяет настройки ngx_event module, а секция mail хранит настройки модуля ngx_mail module.
Список доступных разделов можно просмотреть по этой ссылке.
Директивы
Директивы в Nginx состоят из имени переменной и ряда аргументов. Например, директива worker_processes – имя переменной, а auto – значение:
worker_processes auto;
В конце каждой директивы обязательно нужно поставить точку с запятой ;
Наконец, файл конфигурации Nginx должен соответствовать определенному набору правил. Ниже приведен допустимый синтаксис конфигурации Nginx:
Директивы начинаются с имени переменной, а затем следуют один или несколько аргументов
Директивы заканчиваются точкой с запятой ;
Разделы определяются фигурными скобками {}
Раздел может быть внутри другого раздела
Конфигурация вне любого раздела является частью глобальной конфигурации Nginx.
Строки, начинающиеся со знака #, являются комментариями.
Настройка производительности Nginx
В этой части мы сконфигурируем Nginx для лучшей работы как во время интенсивного трафика, так и во время пиковой нагрузки. Будут рассмотрены следующие настройки:
Workers
Активность Ввода/вывода диска
Сетевой активности
Буферов
Сжатия
Кеширования
Времени ожидания
Итак, в терминале введите следующую команду, чтобы перейти в директорию nginx и показать ее содержимое:
cd nginx && ls
Найдите папку conf. В этой папке и находится файл nginx.conf. Мы используем этот файл для настройки Nginx.
Теперь, чтобы перейти в папку conf и открыть файл nginx.conf с помощью редактора vim, выполните следующие команды:
cd conf
sudo vim nginx.conf
Ниже на скриншоте показан как выглядит файл nginx.conf
Workers
Чтобы улучшить работу веб-сервера Nginx нужно настроить должным образом так называемые воркеры. Это своего рода потоки ядра, которые управляют параллельным выполнением процессов. Настройка воркеров дает возможность эффективней обрабатывать запросы клиентов.
Если все еще не закрыли vim, нажмите i чтобы перейти к режиму редактирования nginx.conf. Скопируйте и вставьте код указанный ниже в раздел events:
events {
worker_processes auto;
worker_connections 1024;
worker_rlimit_nofile 20960;
multi_accept on;
mutex_accept on;
mutex_accept_delay 500ms;
use epoll;
epoll_events 512;
}
worker_processes: Эта директива регулирует количество воркеров в Nginx. Значение этой директивы устанавливается на auto, чтобы разрешить Nginx определять количество доступных ядер, дисков, загрузки сервера и сетевой подсистемы. Однако можно определить количество ядер, выполнив команду lscpu на терминале.
worker_connections: Эта директива задает значение количества одновременных подключений, которые могут быть открыты воркером. Значение по умолчанию - 512, но здесь оно установлено 1024, что позволяет одному воркеру одновременно принимать соединение от клиента.
worker_rlimit_nofile: Эта директива как-то связана с worker_connections. Для обработки большого одновременного соединения устанавливается большое значение.
multi_accept: Эта директива позволяет воркеру принимать множество соединений в очереди одновременно. Очередь в этом контексте просто означает последовательность объектов данных, ожидающих обработки.
mutex_accept: Эта директива отключена по умолчанию. Но поскольку мы настроили много работников в Nginx, мы должны включить его, как показано в коде выше, чтобы позволить работникам принимать новые соединения один за другим.
mutex_accept_delay: Эта директива определяет время ожидания воркера перед принятием нового подключения. После включения accept_mutex воркеру назначается блокировка mutex на период, указанный в accept_mutex_delay. По истечении этого периода следующий воркер готов принять новые подключения.
use: Эта директива указывает метод обработки подключения от клиента. В этом руководстве мы решили установить значение epoll, потому что мы работаем на платформой Ubuntu. Метод epoll является наиболее эффективным методом обработки для платформ Linux.
epoll_events: Значение этой директивы указывает количество событий, которые Nginx передаст ядру.
Чтение/запись диска
В этом разделе мы настроим асинхронные операции ввода-вывода в Nginx для обеспечения эффективной передачи данных и повышения эффективности кэширования.
Дисковый ввод-вывод относится к операциям записи и чтения между жестким диском и ОЗУ. Мы будем использовать функцию sendfile() внутри ядра для отправки небольших файлов.
Для задания директив можно использовать http section, location section и server section.
location section и server section могут быть вложены в разделе http section, чтобы сделать конфигурацию более читабельной.
Скопируйте и вставьте следующий код в location section, расположенный в http section:
location /pdf/ {
sendfile on;
aio on;
}
location /audio/ {
directio 4m
directio_alignment 512
}
Sendfile: Чтобы использовать ресурсы операционной системы, установите для этой директивы значение on. Sendfile передает данные между дескрипторами файлов в пространстве ядра ОС, не отправляя их в буферы приложений. Эта директива будет использоваться для обслуживания небольших файлов.
Directio: Эта директива повышает эффективность кэширования, позволяя выполнять чтение и запись непосредственно в приложение. Directio - это функция файловой системы каждой современной операционной системы. Эта директива будет использоваться для обслуживания больших файлов, например видео.
Aio: Эта директива обеспечивает многопоточность для операций записи и чтения. Многопоточность - это модель выполнения, позволяющая выполнять несколько потоков отдельно друг от друга при совместном использовании ресурсов процесса хостинга.
directio_alignment: В этой директиве для переноса данных назначается значение размера блока. Она касалась директивы directio.
Сетевой уровень
В этом разделе мы используем такие директивы, как tcp_nodelay и tcp_nopush, чтобы небольших пакеты не ждали в очереди перед отправкой.
Обычно, когда пакеты передаются в "частях", они имеют тенденцию заполнять высоконагруженную сеть. Джон Нагл построил алгоритм буферизации для решения этой проблемы. Целью алгоритма буферизации Nagle является предотвращение заполнения высоконагруженной сети небольшими пакетами.
Скопируйте и вставьте следующий код в раздел HTTP:
http {
tcp_nopush on;
tcp_nodelay on;
}
tcp_nodelay: Эта директива по умолчанию отключена, чтобы позволить небольшим пакетам ждать указанный период времени, прежде чем они будут отправлены одновременно. Для немедленной отправки всех данных эта директива включена.
tcp_nopush: Поскольку tcp_nodelay директива включена, небольшие пакеты отправляются одновременно. Однако, если вы все еще хотите использовать алгоритм буферизации Джона Нагле, мы также можем включить
tcp_nopush, чтобы собрать пакеты в одну пачку и отправлять их все одновременно.
Буфер
Рассмотрим, как настроить буферы запросов в Nginx для эффективной обработки запросов. Буфер - это временное хранилище, где данные хранятся в течение некоторого времени и обрабатываются.
Можно скопировать код указанный ниже в раздел server.
server {
client_body_buffer_size 8k;
client_max_body_size 2m;
client_body_in_single_buffer on;
client_body_temp_pathtemp_files 1 2;
client_header_buffer_size 1m;
large_client_header_buffers 4 8k;
}
Важно четко понимать, функции указанных директив
client_body_buffer_size: Эта директива задает размер буфера для тела запроса. Если планируется запустить веб-сервер на 64-разрядных системах, необходимо установить значение 16k. Если требуется запустить веб-сервер в 32-разрядной системе, установите значение 8k.
client_max_body_size: Если вы собираетесь обрабатывать большие загрузки файлов, необходимо установить для этой директивы значение не менее 2m или более. По умолчанию установлено значение 1m.
client_body_in_file_only: Если вы отключили директиву, закомментировав ее client_body_buffer_size, а директива client_body_in_file_only включена, Nginx будет сохранять буферы запросов во временный файл. Это не рекомендуется для производственной среды.
client_body_in_single_buffer: Иногда не все тело запроса хранится в буфере. Остальная часть сохраняется или записывается во временный файл. Однако если предполагается сохранить или хранить все запросы в буфер запросов в одном буфере, необходимо включить эту директиву.
client_header_buffer_size: Эту директиву можно использовать чтобы дать заголовков запросов доступ к буферу. Это значение можно задать равным 1m.
large_client_header_buffers: Эта директива используется для задания максимального количества и размера для чтения заголовков больших запросов. Максимальное число и размер буфера можно точно установить в 4 и 8k.
Сжатие
Еще одним способом оптимизации работы веб-сервера является сжатие объема данных, передаваемых по сети, является. В этом разделе мы используем директивы, такие как gzip, gzip_comp_level, и gzip_min_length, чтобы сжать данные.
Вставьте следующий код в раздел http, как показано ниже:
http {
gzip on;
gzip_comp_level 2;
gzip_min_length 1000;
gzip_types text/xml text/css;
gzip_http_version 1.1;
gzip_vary on;
gzip_disable "MSIE [4-6] .";
}
gzip: Если требуется включить сжатие ответа, установите значение этой директивы в on. По умолчанию он отключен.
gzip_comp_level: Эту директиву можно использовать для установки степени сжатия ответа. Чтобы не тратить ресурсы ЦП, не нужно устанавливать слишком высокий уровень сжатия. По шкале от 1 до 9 лучше установить уровень сжатия 2 или 3.
gzip_min_length: Устанавливает минимальную длину ответа, который будет сжиматься методом gzip. Длина определяется только из поля content-length заголовка ответа. Можно установить значение более 20 байт.
gzip_types: Эта директива разрешает сжатие ответа методом gzip для указанных MIME-типов. По умолчанию, тип text/html всегда сжимается. Можно добавить другой тип, например, text/css, как показано в коде выше
gzip_http_version: Эта директива позволяет выбрать минимальную HTTP-версию запроса, необходимую для сжатия ответа. Можно использовать значение по умолчанию 1.1.
gzip_vary: Разрешает или запрещает выдавать в ответе поле заголовка Vary: Accept Encoding, если директива gzip включена.
gzip_disable: Некоторые браузеры, такие как Internet Explorer 6, не поддерживают сжатие gzip. Эта директива использует поле User-Agent заголовка для отключения сжатия методом gzip для определенных браузеров.
Кеширование
Используйте функции кэширования, чтобы сократить количество обращений для многократной загрузки одних и тех же данных. Nginx предоставляет функции кэширования метаданных статического содержимого через директиву open_file_cache.
Эту директиву можно поместить в разделы server, location и http:
http {
open_file_cache max=1,000 inactive=30s;
open_file_cache_valid 30s;
open_file_cache_min_uses 4;
open_file_cache_errors on;
}
open_file_cache: Эта директива по умолчанию отключена. Включите его, если требуется внедрить кэширование в Nginx. В нем могут храниться дескрипторы открытых файлов, информация об их размерах и времени модификации, информация о существовании каталогов, информация об ошибках поиска файла — “нет файла”, “нет прав на чтение”
open_file_cache_valid: Эта директива определяет время, через которое следует проверять актуальность информации об элементе в open_file_cache.
open_file_cache_min_uses: Задаёт минимальное число обращений к файлу в течение времени, заданного параметром inactive директивы open_file_cache, необходимых для того, чтобы дескриптор файла оставался открытым в кэше.
open_file_cache_errors: Эту директиву можно использовать, чтобы разрешить Nginx кэшировать ошибки, такие как “нет файла”, “нет прав на чтение” при доступе к файлам. Таким образом, каждый раз, когда к ресурсу обращается пользователь, не имеющий на это права, Nginx отображает тот же самый отчет об ошибке «в доступе отказано»
Время ожидания
Настройте время ожидания, используя директивы, такие как keepalive_timeout и keepalive_requests, чтобы предотвратить растрачивание ресурсов при длительном ожидании подключений.
В разделе HTTP скопируйте и вставьте следующий код:
http {
keepalive_timeout 30s;
keepalive_requests 30;
send_timeout 30s;
}
keepalive_timeout: Сохраняйте связь в течение 30 секунд. Значение по умолчанию - 75 секунд.
keepalive_requests: Настройка количества запросов для поддержания активности в течение определенного времени. Количество запросов можно задать равным 20 или 30.
keepalive_disable: если вы хотите отключить поддержку keepalive для определенной группы браузеров, используйте эту директиву.
send_timeout: Установка времени ожадания для передачи данных клиенту.
Настройки безопасности Nginx
В этой части рассматриваются только способы настройки безопасности самого Nginx, а не веб-приложения. Мы не будем разбирать такие методы веб-атаки, как инъекция SQL и так далее.
Здесь мы рассмотрим настройки следующих параметров:
Ограничение доступа к файлам и каталогам
Настройка журналов для мониторинга подозрительных действий
Защиту от DDoS атак
Отключение вывода списка файлов и директорий
Ограничение доступа к файлам и каталогам
Давайте рассмотрим как можно ограничить доступ к важным и чувствительным файлам системы с помощью следующих методов.
Использование HTTP Аутентификации
С ее помощью мы можем ограничить доступ к конфиденциальным файлам или разделам системы, не предназначенных для публичного доступа, запросив аутентификацию у пользователей или даже администраторов. Выполните следующую команду, чтобы установить утилиту создания файлов паролей, если она не установлена.
apt-get install -y apache-utils
Далее создайте файл паролей и пользователя с помощью утилиты htpasswd. htpasswd входит в набор утилит apache2-utils.
sudo htpasswd -c /etc/apache2/ .htpasswd mike
Проверить результат работы можно командой:
cat etc/apache2/ .htpasswd
Скопируйте и вставьте следующий код в разделе location:
location /admin {
basic_auth "Admin Area";
auth_basic_user_file /etc/apache2/ .htpasswd;
}
Используя директиву Allow
В дополнение к директиве basic_auth мы можем использовать директиву allow для ограничения доступа к указанным каталогам.
Чтобы разрешить доступ как конкретным каталогам только с указанных адресов вставьте нижеследующий код в раздел location:
location /admin {
allow 192.168.34.12;
allow 192.168.12.34;
}
Настройка журналирования подозрительных действий
В этом разделе настроим error и access логи, чтобы вести мониторинг запросов. Их можно использовать для определения кто заходил систему в указанный период времени или какой пользователь открывал конкретный файл и т.д.
error_log: Позволяет настроить запись событий в определенный файл, например syslog или stderr. Можно также указать уровень журналирования, которые требуется записывать.
access_log: Позволяет регистрировать запросы пользователей в файле access.log
Для этого в разделе http введите следующие изменения:
http {
access_log logs/access.log combined;
error_log logs/warn.log warn;
}
Предотвращение DDoS атак
DDoS атаки один из самых легкореализуемых и потому часто применяемых видов атак. Защитить свой веб-сервер от атак такого вида можно поменяв следующие настройки.
Ограничение запросов пользователей
Для ограничения числа запросов от пользователей можно использовать директивы limit_req_zone и limit_req. Следующий код нужно добавить в раздел location, который вложен в раздел server
limit_req_zone $binary_remote_addr zone=one:10m rate=30r/m;
server {
location /admin.html {
limit_req zone=one;
}
}
Ограничение на число подключений
Директивы limit_conn и limit_conn_zone можно использовать для ограничения числа подключение к конкретным зонам. Например, код указанный ниже ограничивает число подключений десятью.
Код должен располагаться в разделе location раздела server
server {
location /products/ {
limit_conn addr 10;
}
}
Разрыв медленных соединений
Директива как client_body_timeout задаёт таймаут при чтении тела запроса клиента. Таймаут устанавливается не на всю передачу тела запроса, а только между двумя последовательными операциями чтения. Если по истечении этого времени клиент ничего не передаст, обработка запроса прекращается с ошибкой 408 (Request Time-out). А client_header_timeout задаёт таймаут при чтении заголовка запроса клиента. Если по истечении этого времени клиент не передаст полностью заголовок, обработка запроса прекращается с ошибкой 408 (Request Time-out).
Добавьте следующее в раздел server.
server {
client_body_timeout 5s;
client_header_timeout 5s;
}
Отключение вывода списка директорий
Чтобы отключить вывод директорий на странице можно использовать директиву auto_index. Она располагается в разделе location, а значение должно быть установлено в off.
location / {
auto_index off;
}
Заключение
Итак, в этом руководстве показали, как можно настроить веб-сервер Nginx для более безопасной и оптимальной работы. На этом, конечно, работа не заканчивается. Если на Nginx крутится какое-то приложение с доступом в Интернет, то можно прибегнуть к облачным решениям защиты и оптимизации.
Друг, начнем с цитаты:
Redis – это высокопроизводительная БД с открытым исходным кодом (лицензия BSD), которая хранит данные в памяти, доступ к которым осуществляется по ключу доступа. Так же Редис это кэш и брокер сообщений.
Надо признаться, определение не дает точного понимания, что же такое Redis. Если это так круто, то зачем вообще нужны другие БД? На самом деле, Redis правильнее всего использовать в определенных кейсах, само собой, зная про подводные камни – именно об этом и поговорим.
Про установку Redis в CentOS 8 мы рассказываем в этой статье.
Redis как база данных
Говорим про случай, когда Redis выступает в роли базы данных:
Пару слов про ограничения такой модели:
Размер БД ограничен доступной памятью
Шардинг (техника масштабирования) ведет к увеличению задержки
Это NoSQL - никакого языка SQL
LUA скриптинг в качестве альтернативы
Это нереляционная СУБД!
Нет сегментации на пользователей или группы пользователей. Отсутствует контроль доступа
Доступ по общему паролю. Что скажут ваши безопасники?
Теперь про преимущества модели:
Скорость
Хранение данных в памяти делает быстрее работу с ними
Скрипты на LUA
Выполнение прямо в памяти, опять же, ускоряет работу
Удобные форматы запросов/данных
Geospatial – геоданные (высота, ширина, долгота и так далее)
Hyperloglog – статистическе алгоритмы
Hash – если коротко, то хэш в Redis делают между строковыми полями и их значениями
Алгоритмы устаревания данных
Примеры использования
Представь, у нас есть приложение, где пользователям необходимо авторизоваться, чтобы выполнять какие – либо действия внутри приложения. Каждый раз, когда мы обновляем авторизационные данные клиента, мы хотим их получать для последующего контроля.
Мы могли бы отправлять лист авторизационных параметров (с некими номерами авторизаций, сроком действия с соответствующими подписями), чтобы каждое действие внутри приложения, сопровождалось авторизацонной транзакцией из листа, который мы прислали клиенту. С точки зрения безопасности, в этом подходе нет ничего плохого, если мы храним на своей стороне данные в безопасности и используем Javascript Object Signing and Encryption (JOSE), например. Но проблема появится в том случае, когда наш пользователь имеет более одной авторизации внутри приложения – такие схемы плохо поддаются масштабированию.
А что если вместо отправки листа авторизационных параметров, мы сохраним его у себя, а пользователю отправим некий токен, который они должны отправлять для авторизации? Далее, по этому токену, мы легко сможем найти авторизации юзера. Это делает систему гораздо масштабируемой. Redis, такой Redis.
Итого, для указанной выше схемы, мы хотим:
Скорость
Мы не хотим, чтобы пользователь долго ожидал авторизации
Масштабирумость системы
Сопоставление ключа (токена) с авторизациями юзера
А вот, что на эти вызовы может ответить Redis:
Redis хранит данные в памяти – он быстрый.
Redis можно кластеризовать через компонент Sentinel. Масштабируемость? Пожалуйста.
В Redis куча вариантов хранения списков. Самый простой будет являться набором данных.
В качестве бонуса от Redis, вы получите механизм экспайринга токенов (устаревания). Все будет работать.
Redis как кэш!
Redis почти заменил memcached в современных приложениях. Его фичи делают супер – удобным кэширование данных.
Ограничения:
Значения не могут превышать 512 МБ
Отсутствует искусственный интеллект, который будет очищать ваше хранилище данных
Профит:
Совместное использование кэша разными сервисами по сети
Удобные фичи, такие как LUA скриптинг, который упрощает работы с кэшом
Временные ограничения для данных
Еще один кейс
Предположим, перед нами такая задача: приложение, отображает пользователям данные с определенными значениями, которые можно сортировать по множеству признаков. Все наши данные хранятся в БД (например, MySQL) и показывать отсортированные данные нужно часто. Дергать БД каждый раз весьма тяжело и ресурсозатратно, а значит, нам нужно кэшировать данные в отсортированном порядке.
Окей, кейс понятен. Рэдис, что скажешь на такие требования?
Кэш должен хранить сортированные наборы данных
Нам нужно вытаскивать наборы данных внутри наборов данных (для пагинации, например, то есть для переключения между страницами)
Это должно быть быстрее, чем пересчет данных с нуля
Что скажет Redis:
Хранить наборы данных - легко
Может вытаскивать сабсеты из наборов - легко
Конечно быстрее. Ведь данные хранятся в памяти
Redis как брокер сообщений
Редис может выступать в качестве брокера сообщений. Схема обычная и весьма базовая - publish–subscribe (pub/sub), или как можно перевести на русский язык «Издатель - подписчик».
Как и раньше, давайте обсудим плюсы и минусы, хотя их тут и не так много. Минусы:
Только тривиальная модель pub/sub
Отсутствие очередей сообщений
Ну а плюсы, как обычно для Редиса – скорость и стабильность.
Кейс напоследок
Простой пример – коллаборация сотрудников одной компании. Предположим, у них есть приложение, где они работают над общими задачами. Каждый пользователь делает свой набор действий, о котором другие пользователи должны знать. А так же, юзеры могут иметь разные экземпляры приложений – десктоп, мобильный или что то еще.
Требования по этой задаче:
Низкая задержка
Мы не хотим иметь трудности в процессе совместной работы сотрудников
Стабильная работа и непрерывность
Масштабирование
Кампания растет и развивается
Редис, твой выход!
Низкая задержка – да, говорили об этом ранее
Стабильность – минимальное количество точек отказа в Redis
Стабильная работа и непрерывность
Масштабирование – сделаем кластер, нет проблем.
Выводы
Redis - крутая штука, которая позволяет объединять сервисы и следовать 12 принципам приложений. Для приложений, в которых нагрузка ориентирована на быстрое изменение наборов данных и высокая безопасность данных не имеет завышенных требований – Redis прекрасный выбор.
Если данные нуждаются в усиленной защите, Редис подойдет в меньшей степени, лучше посмотрите в сторону MongoDB или Elasticsearch.