Я превратил дешевое облачное хранилище в локальный диск на 1 ПБ (с помощью JuiceFS)

BBetter Stack
Computing/SoftwareInternet Technology

Transcript

00:00:00Это JuiceFS. Высокопроизводительная распределенная файловая система с открытым исходным кодом, созданная для обеспечения бесконечной масштабируемости облачного объектного хранилища при сохранении полной функциональности и скорости локальной файловой системы.
00:00:14В этом видео мы рассмотрим JuiceFS, узнаем, как он работает, и я покажу, как настроить собственное локальное высокопроизводительное сетевое хранилище (NAS) с помощью JuiceFS.
00:00:24Будет интересно, так что давайте приступим.
00:00:30Стандартные объектные хранилища, такие как S3, Google Cloud Storage или Backblaze B2, невероятно экономичны, но работа с ними обычно требует использования специальных API или инструментов, которые нарушают традиционные рабочие процессы приложений.
00:00:48JuiceFS выступает в роли прозрачного уровня абстракции.
00:00:51Он отделяет данные от метаданных, отправляя «сырые» блоки данных напрямую облачному провайдеру, в то время как структура файловой системы, права доступа и дерево каталогов управляются быстрой базой данных, такой как Redis, Postgres или TiKV.
00:01:07Что делает JuiceFS совершенно отличным от традиционных облачных шлюзов или обычных сетевых файловых ресурсов, так это строгое архитектурное разделение и агрессивный многоуровневый движок кэширования.
00:01:19Вместо того чтобы заставлять приложения ждать ответов от облака с высокой задержкой при каждом обращении к файлу,
00:01:26JuiceFS разбивает файлы на небольшие оптимизированные блоки и использует локальный раздел NVMe или SSD в качестве «горячего» пространства для кэша.
00:01:35При первом чтении или записи данных приложение взаимодействует через сеть, но при повторном запросе данные мгновенно считываются с локального накопителя на аппаратной скорости.
00:01:47Это позволяет устаревшим приложениям, базам данных, конвейерам обучения машинного обучения и контейнерным средам работать поверх объектного хранилища без изменения ни одной строки кода.
00:01:59Звучит здорово, но давайте проверим это на практике и посмотрим, как это работает.
00:02:04Для этого демо я настрою локальное сетевое хранилище (NAS), которое будет хранить все данные в моем удаленном S3-бакете, используя Redis в качестве движка метаданных.
00:02:16Первое, что нужно сделать — это запустить экземпляр Redis с помощью Docker, что легко делается этой командой.
00:02:24Затем нам нужно инициализировать файловую систему, выполнив команду форматирования juicefs format.
00:02:29Этот шаг объясняет JuiceFS, как именно сопоставить нашу базу данных с бакетом для хранения.
00:02:34Мы передаем строку подключения к Redis, имя нашего S3-бакета AWS и наши облачные учетные данные.
00:02:41Но перед этим убедитесь, что вы создали бакет S3, ключ доступа и секретный ключ до запуска команды.
00:02:48Я уже сделал это заранее.
00:02:50Итак, когда я запускаю это, JuiceFS пока ничего не меняет внутри нашего бакета S3.
00:02:56Он просто настраивает схему хранения внутри Redis и присваивает уникальный UUID нашей новой виртуальной файловой системе.
00:03:03После завершения форматирования мы монтируем устройство к нашей локальной машине с помощью команды монтирования juicefs mount.
00:03:10Мы указываем JuiceFS на наш экземпляр Redis и предоставляем локальный путь к каталогу.
00:03:15В моем случае это папка в домашнем каталоге.
00:03:18И перед тем как запустить это, есть важная оговорка.
00:03:21Если вы используете Mac, поскольку macOS не поддерживает сторонние файловые системы «из коробки», вам нужно сначала установить расширение ядра под названием MacFUSE.
00:03:30Оно предоставляет базовые программные хуки, необходимые JuiceFS для взаимодействия с операционной системой Mac.
00:03:37И я также добавляю флаг с коэффициентом свободного места, потому что по умолчанию он установлен на 20% вашего диска, что довольно много.
00:03:47По сути, он говорит JuiceFS, что если локальный диск, на котором размещен кэш, опускается ниже определенного процента общей емкости,
00:03:55он должен перестать записывать новые файлы кэша и начать агрессивно удалять старые, наименее используемые блоки.
00:04:01Это не дает вашей локальной ОС полностью исчерпать дисковое пространство.
00:04:05Хорошо.
00:04:06Теперь давайте запустим эту команду.
00:04:07В ту же секунду операционная система регистрирует стандартную POSIX-совместимую точку монтирования файловой системы.
00:04:15И для компьютера это выглядит так, будто мы только что подключили массивный внешний жесткий диск объемом в один терабайт.
00:04:23И теперь я могу легко перетаскивать файлы в этот каталог, как на внешний диск.
00:04:28А если мы теперь зайдем в панель управления бакетом S3, мы увидим, что JuiceFS сохранил наши файлы, разбив их на блоки данных.
00:04:37Все это происходит за кулисами, и нам не нужно делать тяжелую работу.
00:04:42Чтобы показать, как работает кэширование, мы протестируем производительность файловой системы с помощью классической команды терминала dd.
00:04:49Если вы еще не использовали dd, это встроенная утилита для копирования необработанных данных.
00:04:55В этой конкретной команде 'if' означает входной файл (input file), указывающий на один из больших видеофайлов, которые я добавил на наш диск JuiceFS.
00:05:03А 'of' означает выходной файл (output file).
00:05:06Мы направляем эти данные прямо в /dev/null, что является своего рода «черной дырой» в операционной системе, которая мгновенно отбрасывает данные, так как мы не копируем их на самом деле.
00:05:17Мы просто проводим бенчмарк в этом примере.
00:05:19Также мы устанавливаем размер блока в 4 мегабайта, чтобы он соответствовал тому, как JuiceFS разбивает фрагменты данных.
00:05:25И, наконец, мы добавляем утилиту time перед всей строкой, чтобы увидеть, сколько времени занимает передача файла.
00:05:32Когда мы нажимаем Enter в первый раз, это называется «холодным» чтением, потому что файл только что был загружен.
00:05:38У нашей локальной машины его копии еще нет.
00:05:41Поэтому JuiceFS должен обратиться через Интернет к нашему бакету S3, забрать все эти 4-мегабайтные блоки данных один за другим и скачать их.
00:05:50На моем соединении первый запуск занимает, как вы видите, довольно много времени.
00:05:55Но посмотрите, что произойдет, когда мы запустим ту же команду второй раз.
00:05:59И вот.
00:06:00Готово.
00:06:01Приглашение терминала возвращается почти мгновенно.
00:06:03Второй запуск занял меньше секунды, потому что теперь данные в нашем кэше, и мы считываем их практически мгновенно.
00:06:10Так работает многоуровневый движок кэширования.
00:06:14Пока JuiceFS был занят скачиванием этих блоков во время первого запуска, он молча копировал их на наш локальный NVMe-диск.
00:06:22Но при втором проходе система полностью обошла Интернет, получая данные напрямую с локального оборудования на аппаратной скорости.
00:06:29Таким образом, вы получаете бесконечное дешевое облачное хранилище в сочетании с нулевой задержкой локального диска.
00:06:37В этом демо я использовал видеофайлы, чтобы показать функциональность, но это применимо практически к любому реальному инфраструктурному сценарию.
00:06:45Если вы DevOps-инженер, управляющий контейнерными средами, вы можете использовать JuiceFS для обеспечения общего постоянного хранилища для кластера Kubernetes.
00:06:54И вместо того чтобы платить за дорогое облачное блочное хранилище для каждого узла, все ваши поды могут монтировать один и тот же том JuiceFS одновременно.
00:07:03Обмениваясь файлами конфигурации, ресурсами приложений или пользовательскими загрузками глобально, сохраняя при этом крайне низкие затраты.
00:07:10Это также огромный плюс для машинного обучения и конвейеров обработки данных.
00:07:14Потому что если у вас огромный набор данных, скажем, сотни гигабайт обучающих изображений или текстовых данных, лежащих в бакете S3, обучение модели обычно требует предварительной загрузки всего набора данных локально, что тратит время и место.
00:07:30Но с JuiceFS ваш скрипт обучения может начать работать мгновенно.
00:07:35Конвейер последовательно считывает данные через точку монтирования, а JuiceFS в фоновом режиме обрабатывает высокоскоростную потоковую передачу и локальное кэширование, удерживая ваши GPU полностью загруженными без узких мест локального хранилища.
00:07:49И есть еще кое-что крутое, что я хочу вам показать.
00:07:51Вы также можете легко подключить метрики к вашей файловой системе с помощью Better Stack.
00:07:55Каждый раз, когда вы монтируете том JuiceFS, он молча запускает в фоновом режиме локальный сервер метрик, совместимый с Prometheus.
00:08:03Если вы откроете браузер и перейдете по этому URL, вы увидите все метрики в виде обычного текста: каждое попадание в кэш, длительность чтения и ошибки запросов S3 в реальном времени.
00:08:13Чтобы направить эти телеметрические данные прямо в наш дашборд, мы можем использовать встроенную функцию скрапинга Prometheus в Better Stack.
00:08:21Сначала нам нужно перейти к источникам (sources) и подключить JuiceFS в качестве источника.
00:08:25Затем выберем Prometheus scrape на вкладке метрик и нажмем connect source.
00:08:31Теперь нужно получить логи.
00:08:33Но перед этим нужно открыть безопасный публичный туннель к нашему локальному порту метрик с помощью инструмента вроде ngrok, а затем вставить наш URL от ngrok.
00:08:43Чтобы все заработало с ngrok, нам также нужно перейти в дополнительные параметры (advanced options) и добавить пользовательский HTTP-заголовок с названием ngrok-skip-browser-warning и установить его значение в true.
00:08:53Это говорит ngrok полностью пропустить страницу с предупреждением, позволяя Better Stack безопасно считывать необработанные метрики каждые несколько секунд.
00:09:01И теперь наши метрики должны начать поступать автоматически.
00:09:05А теперь покажу самую крутую часть.
00:09:07Если мы теперь перейдем к AI SRE в Better Stack, мы можем просто попросить ИИ создать нам дашборд, который мониторит производительность кэша, задержки и пропускную способность нашей системы.
00:09:19И через несколько секунд AI SRE создаст для нас красивый кастомный дашборд со всеми метриками, поступающими из JuiceFS.
00:09:27И мы видим, что данные обновляются в режиме реального времени.
00:09:32Разве это не круто?
00:09:34Надеюсь, это небольшое демо показало вам, насколько мощным может быть JuiceFS в сочетании с современным мониторингом инфраструктуры.
00:09:41Нам удалось взять дешевый стандартный облачный бакет, превратить его в бесконечно масштабируемый локальный диск, работающий на аппаратной скорости, и подключить его к полностью автоматизированному дашборду мониторинга всего за несколько минут.
00:09:57Вот такие дела, друзья.
00:09:58Это был JuiceFS в двух словах.
00:10:00Что вы думаете о JuiceFS?
00:10:02Вы уже пробовали его?
00:10:03Будете ли вы его использовать?
00:10:04Дайте нам знать в комментариях ниже.
00:10:06Друзья, если вам нравятся такие технические обзоры, дайте мне знать, нажав кнопку «лайк» под видео.
00:10:12И не забудьте подписаться на наш канал.
00:10:15С вами был Андрус из Better Stack, увидимся в следующих видео.

Key Takeaway

Использование JuiceFS в связке с локальным NVMe-кэшем позволяет превратить бюджетные объектные хранилища в высокопроизводительный сетевой диск, обеспечивая аппаратную скорость доступа к данным при сохранении бесконечной масштабируемости облака.

Highlights

  • JuiceFS превращает объектные хранилища S3, Google Cloud Storage или Backblaze B2 в локальные файловые системы, сохраняя POSIX-совместимость.

  • Архитектура разделяет хранение «сырых» блоков данных у провайдера и управление метаданными в Redis, Postgres или TiKV.

  • Агрессивное многоуровневое кэширование на NVMe или SSD обеспечивает скорость локального диска при повторном доступе к файлам.

  • Настройка файловой системы включает запуск Redis, инициализацию через 'juicefs format' и монтирование с помощью 'juicefs mount'.

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

  • Встроенная поддержка Prometheus позволяет мониторить метрики, такие как попадания в кэш и ошибки запросов, в реальном времени.

Timeline

Архитектура и концепция JuiceFS

  • JuiceFS разделяет поток данных и метаданные для обеспечения масштабируемости.
  • Локальный кэш на NVMe минимизирует задержки, характерные для облачных хранилищ.

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

Развертывание и настройка файловой системы

  • Инициализация требует настройки Redis и бакета S3.
  • Команда 'juicefs mount' создает стандартную POSIX-совместимую точку монтирования.

Для работы системы сначала разворачивается экземпляр Redis через Docker, затем выполняется форматирование файловой системы, связывающее базу метаданных с S3-бакетом. После монтирования ОС распознает хранилище как внешний диск, автоматически разбивая файлы на блоки для хранения в облаке.

Бенчмаркинг и преимущества кэширования

  • Первичное чтение файла ограничено скоростью сети к S3.
  • Повторное чтение из кэша происходит практически мгновенно.

Тестирование с помощью утилиты 'dd' демонстрирует значительную разницу во времени при холодном и горячем доступе к данным. При повторном запросе система исключает сетевые обращения, извлекая данные напрямую с локального NVMe-диска.

Практические сценарии и мониторинг

  • Общее хранилище JuiceFS оптимизирует работу Kubernetes-кластеров.
  • Система обеспечивает непрерывную подачу данных для GPU при обучении моделей.
  • Интеграция с Better Stack позволяет визуализировать метрики через Prometheus.

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

Community Posts

No posts yet. Be the first to write about this video!

Write about this video