Получите максимальную отдачу от MinIO с помощью оптимальных сетевых конфигураций — вот как

MinIO можно развернуть распределенным образом, что позволяет эффективно использовать ресурсы вычислительных ресурсов и ресурсов хранения более чем одной физической или виртуальной машины. Это может быть MinIO, работающий в частной или общедоступной облачной среде, например, с веб-службами Amazon, облачной платформой Google, платформой Microsoft Azure и многими другими. MinIO можно развертывать в нескольких типах топологий — в производственной среде мы рекомендуем развертывание Multi-Node Multi-Drive (MNMD). MinIO рекомендует репликацию сайта , чтобы обеспечить поддержку отказоустойчивости и восстановления уровня BC/DR для развертывания на одном сайте, которую вы можете спроектировать и оптимизировать для своего варианта использования.

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

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

Простые сетевые стратегии

MinIO — это S3-совместимое серверное хранилище для облачных сервисов. В общем, мы думаем о сетевом трафике либо между приложениями и кластером, либо между узлами в кластере. Из-за межузлового трафика крайне важно, чтобы сеть между узлами работала как можно быстрее. Каждый пул состоит из независимой группы узлов со своими наборами стирания. MinIO должен опрашивать каждый пул, чтобы определить правильный набор стирания, к которому он направляет операции чтения и записи, так, чтобы каждый дополнительный пул добавлял минимальный, но увеличивал межузловой трафик за вызов. Пул, содержащий правильный набор стирания, затем реагирует на операцию, оставаясь полностью прозрачным для приложения.

Прошли те времена, когда предприятия могли обойтись сетевыми адаптерами 1 GbE или 10 GbE. В современной корпоративной рабочей нагрузке в идеале используются сетевые адаптеры 100 GbE. Учитывая физические ограничения и накладные расходы протокола TCP, ожидается, что эти сетевые карты будут обеспечивать 80-90% доступной пропускной способности, обычно около 10 ГБ/с для сетевых карт 100 Гбит/с и до 12 ГБ/с в действительно хорошо подготовленных сетях. MinIO не требует какой-либо дополнительной сетевой конфигурации, чтобы использовать всю пропускную способность, поскольку он прослушивает все интерфейсы. MinIO «из коробки» поддерживает прослушивание нескольких сетевых интерфейсов (NIC).

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

В этом примере для демонстрации мы будем использовать операционную систему Linux, но основы работы в сети одинаковы независимо от того, какую ОС вы используете. Реализация может немного отличаться в зависимости от конфигурации сети, но это должно дать вам представление.

Сначала мы начнем с вывода таблицы маршрутов

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.18

Если вы настроили свои серверы MinIO так, чтобы они находились в диапазоне CIDR 10.56.98.16/28, предположим, что один из IP-адресов узла MinIO — 10.56.98.21, который будет маршрутизироваться через интерфейс eth0, поскольку /28 соответствует записи таблицы маршрутизации для 10.56. .98.0/24.

Но если вы хотите маршрутизировать трафик MinIO через eth1, а не через eth0, нам нужно добавить определенный маршрут для MinIO CIDR, чтобы любой трафик, соответствующий этой подсети, маршрутизировался через этот конкретный сетевой интерфейс.

 $ ip route add 10.56.98.16/28 dev eth1

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

 $ ip route 10.56.98.0/24 dev eth0 proto kernel scope link src 10.56.98.33.18 10.56.98.16/28 dev eth1 scope link

Теперь мы видим маршрут для /28 CIDR. Если вы пропингуете узел MinIO 10.56.98.21, он теперь будет маршрутизироваться через интерфейс eth1. Это связано с тем, что при наличии двух маршрутов, где /24 пересекается с /28, обычно предпочтение отдается маршруту с самым длинным префиксом (в данном случае /28), и он будет иметь приоритет над любым другим маршрутом с более коротким префиксом при маршрутизации трафика. Это называется правилом самого длинного совпадающего префикса.

Вы можете убедиться, что трафик от 10.56.98.16/28 маршрутизируется правильно, если вы пропингуете 10.56.98.21, а затем проверите tcpdump, как показано ниже. Вы заметите, что трафик от источника 10.56.98.18 направляется через eth1 на 10.56.98.21.

 $ tcpdump -n -i eth1 icmp … 15:55:44.410450 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 123, length 64 15:55:44.410471 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 123, length 64 15:55:45.434489 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 124, length 64 15:55:45.434518 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 124, length 64 15:55:46.458490 IP 10.56.98.18 > 10.56.98.21: ICMP echo request, id 8416, seq 125, length 64 15:55:46.458520 IP 10.56.98.21 > 10.56.98.18: ICMP echo reply, id 8416, seq 125, length 64

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

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

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

Одной из наиболее эффективных стратегий репликации является репликация между сайтами. Это позволяет запускать MinIO с одним кластером и расширять его до числа N по мере увеличения потребности. Предположим, у вас есть приложение ETL/ELT, которое работает на трех разных сайтах. Как правило, данные доступны только в одном из регионов, а другим регионам необходимо переносить огромные объемы данных между регионами, чтобы запустить процесс. Излишне говорить, что это не только крайне неэффективно, но и оказывает огромную нагрузку на сетевую инфраструктуру и потенциально создает узкие места для других приложений, использующих глобальную сеть.

В конфигурации репликации между сайтами вы записываете данные только в кластер MinIO на первом сайте. Процесс репликации автоматически скопирует данные на другие сайты. Никаких дополнительных изменений в приложение ETL/ELT вносить не требуется. Вы просто указываете задания на каждом сайте на соответствующий кластер MinIO, поддерживаемый обратным прокси-сервером, таким как Nginx, и чтение будет намного быстрее, чем через WAN в разных регионах, как показано ниже.

Но тут возникает вопрос, можно ли еще более точно настроить трафик? Допустим, вы добавляете файл данных на сайт 1, и он немедленно реплицирует его на другие сайты, независимо от времени суток. Это может быть во время пика, когда, возможно, выполняются другие задания ETL/ELT и одновременно используются сетевые ресурсы для репликации данных, которые могут не использоваться до следующего дня, когда должен быть запущен следующий пакет. Что можно сделать в таком случае? Вот тут-то и пригодится пакетная репликация MinIO. Пакетная репликация позволяет вам выбирать тип данных, которые вы хотите реплицировать в определенное время, она полностью настраивается. В этом случае задание пакетной репликации можно настроить на выполнение в нерабочее время, когда трафик наименьший. Поскольку время доступа к приложениям может меняться в течение дня, недели и даже месяца, именно здесь может пригодиться мониторинг сетевого трафика MinIO , чтобы вы могли настроить пакетное задание для запуска точно в нужное время. Вы можете развернуть одноранговые сайты в разных стойках, центрах обработки данных или географических регионах для поддержки таких функций, как BC/DR или геолокальная производительность чтения/записи в глобально распределенном хранилище объектов MinIO.

Последние мысли

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

Как обычно, если у вас есть какие-либо вопросы о конфигурации сети MinIO или о том, как ее настроить, обязательно свяжитесь с нами в Slack или, что еще лучше, подпишитесь на подписку SUBNET !