0sennijLis

0sennijLis

На Пикабу
29К рейтинг 14 подписчиков 12 подписок 45 постов 27 в горячем
Награды:
Ежегодное приключениеПизанская ёлкаМакаронная статуяСкуфзаводЧайкам тут не местоЗа киберзащитуЗа киноманство5 лет на Пикабу лучший авторский текстовый пост недели
12

Повышение производительности с использованием LVM Striping

В области управления хранилищами приоритетом является достижение оптимальной производительности дисков. Стремление к более быстрому доступу к данным, уменьшению задержек и повышению количества операций ввода-вывода (I/O) и пропускной способности привело к использованию передовых техник. Одной из таких является LVM Striping (полосование), мощная функция менеджера логических томов (LVM), которая существенно повышает производительность дисковых томов.

Линейный (Linear) LVM против LVM Striping:

1.1 — Линейный LVM:

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

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Хотя линейный LVM прост и удобен для расширения хранилищ, он не полностью раскрывает потенциал параллельной обработки и увеличения общей пропускной способности.

1.2 — LVM Striping (Полосование):

Напротив, LVM Striping представляет собой более продвинутый подход, при котором данные распределяются одновременно по нескольким физическим томам. Это создает логический том, охватывающий сразу несколько дисков, что позволяет осуществлять параллельные операции чтения и записи. В результате значительно повышается производительность, что делает LVM Striping особенно привлекательным для систем с высоким уровнем нагрузки ввода-вывода.

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Процесс создания полос:

  1. Создание полос:

  • Данные разделяются на сегменты («полосы»).

  • Каждая полоса записывается на отдельный диск в составе логического тома.

2. Параллельная запись полос:

  • Полосы записываются параллельно на несколько физических томов (дисков).

3. Равномерное распределение:

  • Полосы равномерно распределены по дискам, предотвращая появление узкого места (bottleneck).

4. Увеличение IOPS и пропускной способности:

  • Благодаря параллельной записи полос LVM Striping существенно увеличивает общую производительность и пропускную способность логического тома.

1.3 — Пример использования:

Рассмотрим пример с тремя дисками, каждый из которых обеспечивает пропускную способность 125 МБ/с:

  • При использовании LVM Striping суммарная производительность составит 375 МБ/с.

  • В случае же с линейным LVM, производительность останется равной 125 МБ/с, вне зависимости от количества добавленных дисков.

Настройка Linear LVM и Striping LVM:

В этом разделе мы создадим две группы томов (Volume Groups, VG): одну линейную, вторую — с полосованием, каждая с использованием трёх дисков. Затем создадим логические тома (Logical Volumes, LV), отформатируем и смонтируем их.

2.1 — Исходные данные:

  • Сервер: AWS EC2 instance типа m4.10xlarge

  • EBS-диски: 6 штук по 20ГБ (тип GP3, 3000 IOPS, 125MiB/s пропускная способность каждый)

  • ОС: Amazon Linux 2

Просмотр подключенных дисков:

# lsblk

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

2.2 — Создание групп томов (VG):

Создадим две группы томов:

# vgcreate vg_linear /dev/sdb /dev/sdc /dev/sdd
# vgcreate vg_striping /dev/sde /dev/sdf /dev/sdg

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

# vgs

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

2.3 — Создание линейного логического тома (Linear LVM):

# lvcreate -l 100%FREE -n lv_linear vg_linear

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Параметры:

  • -l 100%FREE — задействовать весь доступный объем VG.

  • -n lv_linear — имя логического тома.

  • vg_linear — целевая группа томов.

2.4 — Создание логического тома с полосованием (Striping LVM):

# lvcreate -l 100%FREE -i 3 -I 64k -n lv_striping vg_striping

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Параметры:

  • -l 100%FREE — задействовать весь объем VG.

  • -i 3 — количество полос (равно числу дисков).

  • -I 64k — размер полосы.

  • -n lv_striping — имя логического тома.

  • vg_striping — целевая группа томов.

2.5 — Проверка созданных LV:

Проверка линейного LV:

# lvdisplay -m /dev/vg_linear/lv_linear

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Проверка LV с полосованием:

# lvdisplay -m /dev/vg_striping/lv_striping

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Здесь мы можем увидеть различные детали наших настроек.

2.6 — Форматирование и монтирование LV:

# mkfs.xfs /dev/vg_linear/lv_linear

# mkfs.xfs /dev/vg_striping/lv_striping

# mkdir /mnt/linear

# mkdir /mnt/striping

# mount /dev/vg_linear/lv_linear /mnt/linear/

# mount /dev/vg_striping/lv_striping /mnt/striping/

# df -h

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

LV успешно смонтированы.

3 — Тестирование производительности LV (benchmark):

Для тестирования используем инструмент fio:

# yum install fio -y

3.1 — Тестирование линейного LV:

Чтобы сравнить LV, мы будем использовать файл конфигурации FIO, который поможет нам генерировать трафик на 400м:

# cat fio_config-1.fio

[global]

ioengine=libaio

runtime=60

time_based

direct=1

rw=write

size=10G

bs=512K

rate=400M

numjobs=16

[job1]

filename=/mnt/linear/testfile

Запуск тестирования с созданным конфигом:

# fio fio_config-1.fio

Одновременно с этим в отдельном терминале запустим iostat, чтобы контролировать использование дисков:

# iostat -xdmt 2

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Видим, что используется только один диск xvdb со скоростью 125 МБ/с.

Ту же картину нам демонстрирует и fio:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Операции записи были выполнены исключительно на одном диске.

3.2 — Тестирование LV с полосованием:

Теперь снова запустим fio, но изменим параметр filename в файле конфигурации:

filename=/mnt/striping/testfile

Запускаем iostat:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Все три диска работают параллельно, суммарная скорость равна 375 МБ/с (125 x 3).

Аналогичную картинку нам демонстрирует и fio:

Повышение производительности с использованием LVM Striping Системное администрирование, Linux, Shell, IT, Исследования, Сервер, Длиннопост

Вывод:

LVM Striping является мощным решением для организаций, которые хотят максимально эффективно использовать ресурсы своих хранилищ. Распределяя данные параллельно на несколько дисков, LVM Striping не только значительно увеличивает производительность, но и обеспечивает масштабируемость и гибкость управления хранилищами.

Используйте LVM Striping, чтобы раскрыть потенциал параллельной обработки данных и вывести производительность дисковой подсистемы на новый уровень.

Показать полностью 14
19

Влияние максимального размера I/O-запросов на производительность систем Linux

В области оптимизации производительности Linux важнейшим фактором является производительность дискового ввода-вывода (I/O), которая существенно влияет на общую эффективность системы. Одним из ключевых параметров, влияющих на производительность дискового ввода-вывода, является максимальный размер I/O-запроса, определяемый параметром max_sectors_kb. Понимание и настройка этого параметра могут привести к значительному улучшению производительности системы. В этой статье мы рассмотрим понятие максимального размера I/O, его важность в системах Linux, а также его влияние на производительность в целом.

Понимание максимального размера I/O (max_sectors_kb)

Параметр max_sectors_kb определяет максимальный размер отдельного I/O-запроса в килобайтах. Он устанавливает объём данных, который может быть передан в рамках одного I/O-запроса. Значение параметра max_sectors_kb ограничено логическим размером блока файловой системы и аппаратными возможностями устройства хранения данных. Оно не может быть меньше логического размера блока, делённого на 1024, и не должно превышать значение параметра max_hw_sectors_kb, который является параметром только для чтения и показывает максимально поддерживаемый аппаратурой размер запроса.

Минимальное значение = max(1, logical_block_size/1024) 

Максимальное значение = max_hw_sectors_kb

Примечание: Максимальный размер I/O в Linux преимущественно применим к ядрам версии 4.x и выше. Рекомендуется проверить это в конкретном ядре вашей системы. Хотя впрочем очевидно - если у вас не какой-нибудь embedded, то ядро скорее всего будет выше 5.x

Важность в системах Linux

В Linux параметр максимального размера I/O существенно влияет на эффективность чтения и записи данных с устройств хранения. Он оказывает влияние на следующие аспекты производительности:

1. Баланс между пропускной способностью и задержками:

  • Пропускная способность (Throughput): Крупные размеры I/O-запросов увеличивают общую пропускную способность ввода-вывода за счёт обработки больших блоков данных за одну операцию. Это снижает накладные расходы на обработку множества мелких запросов, особенно эффективно при работе с последовательными потоками данных (видеостриминг, резервные копии баз данных).

  • Задержки (Latency): В то время как большие размеры I/O-запросов могут повысить пропускную способность для больших наборов наборов, они также могут увеличить задержку отдельных операций. Это происходит потому, что более крупные запросы требуют больше времени для завершения. Поэтому необходим баланс между улучшением производительности и допустимым уровнем задержек, особенно в чувствительных к задержкам интерактивных или real-time приложениях. В таких случаях предпочтительнее меньшие размеры запросов.

2. Использование CPU:

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

3. Использование памяти:

  • Максимальный размер I/O влияет на объём выделяемой памяти под буферы ввода-вывода, что также отражается на общем использовании памяти системой.

Факторы, влияющие на максимальный размер I/O

Есть несколько факторов, которые влияют на максимальный размер запросов в Linux:

  • Аппаратные ограничения: Значение max_sectors_kb не должно превышать аппаратные возможности накопителя (значение параметра max_hw_sectors_kb). Превышение аппаратного лимита может привести к ошибкам или снижению производительности.

  • Драйверы устройств: Драйверы контроллеров хранения и накопителей могут задавать свои лимиты на размер запросов.

  • Ограничения файловых систем: У разных файловых систем разные лимиты на размер запроса ввода-вывода.

  • Параметры ядра Linux: Настройки блочных устройств ядра влияют на размер запроса.

Бенчмаркинг и мониторинг

Для определения оптимального размера I/O-запросов необходимо проводить тестирование (бенчмарки) и мониторить показатели производительности (например, с помощью утилиты iostat).

Рекомендуется учитывать:

  • Red Hat советует, чтобы значение max_sectors_kb было кратно оптимальному размеру I/O и внутреннему размеру блока стирания устройства. Если таких данных нет, рекомендуется выставить значение, совпадающее с логическим размером блока устройства.

  • Характеристики рабочей нагрузки: разные приложения выигрывают от разных размеров I/O.

  • Особенности накопителя: HDD и SSD имеют разные оптимальные диапазоны размеров I/O.

  • Ресурсы системы: доступная память и мощность CPU влияют на выбор оптимального размера I/O.

Практические аспекты настройки

Для настройки max_sectors_kb используется команда:

/sys/block/{device}/queue/max_sectors_kb

Например:

echo 256 | sudo tee /sys/block/sda/queue/max_sectors_kb

Данная команда устанавливает максимальный размер запроса в 256 КБ для диска /dev/sda. Перед изменениями желательно протестировать настройки на тестовой системе во избежание негативного влияния на производительность или стабильность системы.

Изменения параметра действуют только до перезагрузки системы. Чтобы изменения сохранялись, добавьте команду в rc.local или настройте сервис для применения параметров при загрузке.

Практическое исследование

Рассмотрим практический сценарий. Создадим лабораторную среду на Linux-сервере и проверим производительность диска. Нагрузку (IOPS) будем генерировать с помощью инструмента fio, а мониторинг производительности проводить с помощью утилиты iostat. Наша задача — оценить влияние параметра max_sectors_kb на производительность системы.

Среда для тестирования:

  • Тип EC2-инстанса: c5.12xlarge

  • EBS-том:

  • тип: GP3

  • размер: 20 GiB

  • IOPS: 3000

  • пропускная способность: 750 MB/s

  • Операционная система: Amazon Linux 2

Проверка дисков и установка fio

Для начала проверим доступные диски:

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Мы будем создавать нагрузку на диск nvme1n1 при помощи утилиты fio и параллельно мониторить производительность диска, в частности показатель IOPS. Если fio не установлен, используйте команды ниже:

Для Amazon Linux:

sudo yum install -y fio

Для Ubuntu:

sudo apt-get install -y fio

Запуск теста

Откройте два терминала одновременно:

Терминал 1: Генерируем нагрузку:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Терминал 2: Мониторим диск:

iostat 1 -d /dev/nvme1n1

Обратите внимание, что в команде fio мы задали размер запроса 256 KiB.

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост
Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Наблюдения

На первом скриншоте видно, что утилита fio генерирует 1082 IOPS, однако утилита iostat показывает примерно 2164 IOPS (то есть в два раза больше).

Причина различий

Чтобы выяснить причину этого несоответствия, проверим значение параметра max_sectors_kb:

cat /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Объяснение:

Инструмент fio создавал IOPS с размером 256 KiB, а max_sectors_kb был установлен на значение 128 KiB. В результате ядро Linux разбивало каждый запрос на два меньших запроса по 128 KiB каждый (256 KiB = 128 KiB × 2). Именно поэтому количество операций, регистрируемых iostat, было в два раза больше, чем указывал fio (1082 × 2 = 2164).

Важно: Увеличение числа запросов из-за неправильно настроенного max_sectors_kb может негативно повлиять на производительность сервера и привести к троттлингу производительности диска (например, EBS-тома), если число операций превышает базовый уровень IOPS.

Проверка максимального аппаратного лимита max_hw_sectors_kb

Проверим максимальное значение I/O, которое поддерживает наш сервер:

cat /sys/block/nvme1n1/queue/max_hw_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: наш сервер поддерживает максимальный размер I/O-запроса в 256 KiB.

Попытка увеличения max_sectors_kb

Попробуем увеличить значение до 512 KiB:

echo 512 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: Мы получили ошибку «Invalid argument» («Недопустимый аргумент»), так как указали значение, превышающее аппаратный лимит max_hw_sectors_kb.

Теперь установим допустимое значение 256 KiB:

echo 256 | sudo tee /sys/block/nvme1n1/queue/max_sectors_kb

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: Значение успешно изменено на 256 KiB.

Повторный запуск теста fio

Повторим тест командой:

sudo fio --filename=/dev/nvme1n1 --rw=read --bs=256K --ioengine=libaio --direct=1 --name=volume-initialize

Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост
Влияние максимального размера I/O-запросов на производительность систем Linux Системное администрирование, Компьютерное железо, Linux, Исследования, Производительность, Сервер, Длиннопост

Результат: После изменения параметра max_sectors_kb количество операций IOPS, отображаемое fio и iostat, совпало.

Заключение:

Максимальный размер I/O-запроса (max_sectors_kb) является мощным инструментом для тонкой настройки производительности дисковой подсистемы в Linux. Правильно подобранное значение позволяет оптимизировать производительность ввода-вывода и снизить нагрузку на CPU, однако следует учитывать возможное увеличение задержек и аппаратные ограничения. Любые изменения параметров производительности следует предварительно тестировать и внимательно анализировать перед внедрением в продуктивную среду. Это гарантирует стабильность работы системы и её оптимальную производительность в различных сценариях.

Показать полностью 9
87

Ответ на пост «Мегафон радует»3

Оооо. Подержите моё пиво.

Со мной недавно Мегафон тоже интересный фокус пытался провернуть.

У меня редкий (по нынешним меркам) тариф с безлимитным интернетом. И меня, внезапно, всё устраивает (даже учитывая что они нещадно режут полосу для анлимов). Тем более за 715 рублей в месяц.

Но тут внезапно приходит смска от мегафона с следующим содержанием:

Ответ на пост «Мегафон радует» Мегафон, Обман, Жадность, Мошенничество, Наглость, Ответ на пост, Длиннопост, Негатив

Вот это великодушие @megafon. Тариф на 100 с лишним рублей дороже и с гораздо более худшими условиями. Что тут сказать.

Ответ на пост «Мегафон радует» Мегафон, Обман, Жадность, Мошенничество, Наглость, Ответ на пост, Длиннопост, Негатив

Расчёт очевидно на то, что какой-то процент людей проморгает сообщение, а после смены тарифа обратно уже ничего не будет поменять.
А как только этот вариант отработает, придумают что-то более изощрённое.
И главное смысла особого менять оператора нет. У других в том или ином виде тоже присутствуют регулярные попытки нае обмануть клиента. Это же конторы одного профиля:

Ответ на пост «Мегафон радует» Мегафон, Обман, Жадность, Мошенничество, Наглость, Ответ на пост, Длиннопост, Негатив
Показать полностью 3
1

А как прошло ваше обновление Pikabu?

У меня вот сегодня пост целый день в горячее выходит)

А как прошло ваше обновление Pikabu? Обновление на Пикабу, Картинка с текстом, Техподдержка Пикабу, Уведомление

@Support, похоже что-то пошло не так.

61

У админского эффекта присутствия есть и обратная сторона...1

У админского эффекта присутствия есть и обратная сторона...
100

Свободная и доступная память в Linux

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

Свободная и доступная память в Linux Linux, IT, Оперативная память, Операционная система, Системное администрирование, Длиннопост, Мемы

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

Свободная vs. Доступная память

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

Свободная память (free memory) - это объем памяти, который сейчас ни для чего не используется. По этой причине, особенно на серверах, удобно воспринимать свободную память, как тратящуюся впустую. После того, как ваши приложения/процессы были запущены и прошло значительное время безотказной работы, это число почти всегда должно быть небольшим.

Доступная память (available memory) - это объем памяти, который доступен для выделения новому или существующему процессу. Доступная память оценивается в количестве памяти которую можно выделить, без использования подкачки.

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

Сравнение свободной и доступной памяти на практике

Учитывая всё вышесказанное, давайте взглянем на пару серверов Linux с 60 гигами памяти на борту, 12 ядрами и swap разделом на Raid 10 собранном из NVMe накопителей. Условно обозначим их как "Server A" и "Server B". В первую очередь воспользуемся командой free.

free -h

Вывод будет примерно похож на демонстрируемый на скриншотах ниже (там так же выполнена команда uptime, чтобы показать, что сервера живут без ребута уже достаточно давно)

Свободная и доступная память в Linux Linux, IT, Оперативная память, Операционная система, Системное администрирование, Длиннопост, Мемы

У этого сервера меньше 1% свободной памяти, и 13% доступной

Свободная и доступная память в Linux Linux, IT, Оперативная память, Операционная система, Системное администрирование, Длиннопост, Мемы

А вот здесь, спустя 153 дня работы 30гигов памяти по прежнему тратятся впустую

На этих скриншотах хорошо видна разница между свободной и доступной памятью. При сравнении двух систем явно видно, что даже несмотря на то, что средняя загрузка у них очень похожая (обрабатываются одни и те же рабочие нагрузки), один сервер использует практически 100% памяти (Server A), а второй тратит больше 50% памяти впустую (Server B).

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

При взгляде на эти системы любой админ задастся сразу несколькими справедливыми вопросами:

  • Замедляет ли свопинг производительность на сервере A

  • Следует ли вытащить пару плашек из сервера B, чтобы задействовать в другом месте?

  • Например может задействовать в сервере А, которому явно не хватает?

  • Ожидается ли в ближайшее время рост трафика/загрузки?

  • В часы пиковой нагрузки, когда задействован свпо, средняя загрузка остаётся ниже 12.00?

  • Можно ли настроить сервер B на использование большего количество буфферов и кэша?

Поскольку часть вопросов риторическая, то разумеется каждому администратору, при возникновении подобной ситуации придётся самому отвечать на них (или запрашивать помощь друга).

Заключение

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

Для более детального изучения механизма управления памятью можно например почитать - https://docs.kernel.org/admin-guide/mm/index.html.

tg

Показать полностью 3
863

О траблшутинге в IT (и не только)

О траблшутинге в IT (и не только) IT, Будни сисадмина, Сисадмин, Helpdesk, Диагностика, Картинка с текстом, IT юмор, Инфографика
Показать полностью 1
25

Разница между обратным прокси и ingress контроллером

Эта статья навеяна комментарием к предыдущей.

Разница между обратным прокси и ingress контроллером IT, Технологии, Linux, Kubernetes, Сети, Длиннопост

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

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

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

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

Разница между обратным прокси и ingress контроллером IT, Технологии, Linux, Kubernetes, Сети, Длиннопост

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

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

Разница между обратным прокси и ingress контроллером IT, Технологии, Linux, Kubernetes, Сети, Длиннопост

Ingress контроллер

Если в двух словах, то в мире Kubernetes ingress контроллер является обратным прокси (кстати именно поэтому тот же Istio в прошлой статье был упомянут в контексте перечисления вариантов обратных прокси).

Он действует по принципу обратного прокси, маршрутизируя трафик из внешней сети к целевому сервису в пределах кластера Kubernetes, и позволяя вам настроить балансировщик нагрузки HTTP и HTTPS для кластера.

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

Kubernetes Ingress - это объект API, задача которого определять как приходящий трафик из интернета будет направляться на внутренние сервисы кластера, которые затем в свою очередь будут отправлять запросы Pod'ам. Сам по себе Ingress не имеет влияния на систему, представляя собой просто набор правил для Ingress контроллера. Для проведения аналогии можно сравнить Ingress с автомобилем, у которого снят двигатель, а Ingress контроллер с самим двигателем, то есть при наличие Ingress ресурса, без установленного контроллера, работать ничего не будет.

Ingress контроллер принимает трафик снаружи Kubernetes платформы, и распределяет его по Pod'ам внутри платформы, таким образом накладывая еще один уровень абстракции на маршрутизацию трафика. Контроллеры Ingress преобразуют конфигурации из ресурсов Ingress в правила маршрутизации, распознаваемые и реализуемые обратными прокси-серверами.

Обычно Ingress контроллеры используются для предоставления доступа к множеству сервисов через единую точку входа (DNS-имя или IP-адрес).

В частности, входные контроллеры используются для:

  • предоставления нескольких служб под одним DNS-именем

  • реализации маршрутизации на основе пути, при которой разные URL-адреса сопоставляются с разными службами

  • реализации маршрутизации на основе хоста, при которой разные имена хостов сопоставляются с разными службами

  • реализации базовой аутентификации, или других методы контроля доступа для ваших приложений.

  • включения ограничения скорости для ваших приложения

Заключение

Если ingress контроллер делает практически ту же самую работу, что и обратный прокси (обрабатывает входящий трафик и перенаправляет на соответствующий сервер/сервис), то чем они отличаются?
Ingress контроллер - это частный случай прокси-сервера, предназначенный для работы в кластерах Kubernetes. Он находится не на границе инфраструктуры, а на границе кластера.

Показать полностью 1
Отличная работа, все прочитано!