По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
Основная цель любого проекта по разработке ПО – получить прибыль за счет автоматизации бизнес-процессов. Чем быстрее вы начнете выпускать новые версии, тем лучше для компании. Но как же научиться выпускать новые версии максимально быстро? Конечно же, все можно делать вручную. Например, подключить удаленный сервер через SSH, клонировать клонировать репозиторий с новым кодом, собрать его и запустить через командную строку. Да, такой способ работает, но он малоэффективен. Сегодня мы поговорим об автоматизации процесса разработки и выхода новых версий.
CI и CD – это два сокращения, которые означают Continuous Integration (Непрерывная интеграция) и Continuous Delivery (Непрерывное развертывание).
CI
CI описывает процесс добавления изменений в репозиторий. Ниже схематически представлен простой пример коллективной разработки.
Одновременно может работать целая группа людей, но все изменения передаются в главную ветку master поэтапно. Хотя даже в такой простой схеме возникает несколько вопросов.
Как мы узнаем, что код, который идет в ветку master, компилируется?
Мы хотим, чтобы разработчики писали тесты для кода. Как быть уверенными в том, что тестовое покрытие не уменьшится?
Все сотрудники команды должны форматировать код в соответствие с определенным стилем. Как отследить возможные нарушения?
Конечно же, все это можно проверить вручную. Но такой подход весьма хаотичен. Кроме того, по мере разрастания команды выполнять подобные проверки становится сложнее.
CI используется для автоматизации выше обозначенных пунктов.
Начнем с первого пункта. Как можно проверить, что новые изменения не сломают сборку? Для этого нам потребуется еще один блок в схеме.
Большинство CI-процессов можно описать по следующему алгоритму.
При открытии каждого Pull Request (запроса на включение изменений) и отправке новых изменений, Git-сервер отправляет уведомление CI-серверу.
CI-сервер клонирует репозиторий, проверяет исходную ветку (например bugfix/wrong-sorting) и сливает ее с основной веткой master.
Затем запускается скрипт сборки. Например ./gradlew build.
Если команда возвращает код «0», то сборка прошла успешно. Все остальные значения считаются ошибкой.
CI-сервер отправляет запрос на Git-сервер с результатом сборки.
Если сборка прошла без ошибок, то Pull Request разрешается слить. В противном случае он блокируется.
Данный процесс гарантирует, что код, попадающий в ветку master, не сломает дальнейшие сборки.
Проверка тестового покрытия
Давайте немного усложним задачу. Предположим, нам захотелось установить минимальный охват тестового покрытия. Это означает, что в любой момент времени покрытие ветки master должно быть не менее 50%. Плагин Jacoco идеально справляется с этой задачей. Вы просто настраиваете его так, чтобы при охвате тестового покрытия ниже допустимого, сборка уходила в ошибку.
Реализовать такой подход проще некуда. Но есть небольшая оговорка. Этот метод работает только при условии, что плагин настраивался на старте проекта.
Представим ситуацию: вы работаете над проектом, которому уже 5 лет. С момента первого коммита никто не проверял тестовое покрытие. Разработчики добавляли тесты в случайном порядке и без какой-либо организации. Но вот однажды вы решаете увеличить количество тестов. Вы настраиваете плагин Jacoco на минимальную планку в 60%. Спустя какое-то время разработчик открывает новый Pull Request. Затем разработчики вдруг понимают, что покрытие – всего лишь 30%. Так что для успешного закрытия задачи нужно покрыть не менее 30% кода продукта. Как вы можете догадаться, для проекта 5-летней давности – это практически неразрешимая проблема.
Но что, если будут проверяться только будущие изменения в коде, а не весь продукт? Если в Pull Request разработчик изменит 200 строк, то нужно будет охватить не менее 120 из них (при тестовом покрытии в 60%). Тогда не придется проходить по множеству модулей, которые не относятся к задаче. В принципе, проблема решаема. Но как применить все это к проекту? К счастью, есть решение.
Отчет Jacoco отправляется на сервер тестового покрытия.
Одно из самых популярных решений – SonarCloud.
Сервер хранит статистику по предыдущим вычислениям. Это очень удобно: вычислять тестовое покрытие не только всего кода, но и будущих изменений. Затем результат анализа отправляется на CI-сервер, который перенаправляет его на Git-сервер.
Такая рабочая модель позволяет применять культуру обязательного тестирования на любой стадии развития продукта, поскольку проверяется лишь часть изменений.
Если говорить о стиле оформления кода, то отличий практически нет. Можете попробовать плагин Checkstyle. Он автоматически отклоняет сборку, которая нарушает любое из заявленных требований. Например, в коде есть неиспользованный импорт. Кроме того, вы можете присмотреться к облачным сервисам, которые выполняют анализ кода и визуально отображают результаты в виде графиков (SonarCloud это тоже умеет).
CD
CD описывает процесс автоматического развертывания новой версии продукта.
Давайте еще немного подкорректируем схему CI. Вот так конвейерный процесс CI/CD мог бы выглядеть в реальном проекте.
Первое отличие – теперь CI-сервер называется CI/CD-сервером. Дело в том, что зачастую оба процесса (CI и CD) выполняются одним и тем же диспетчером задач. Так что мы будем рассматривать именно этот случай.
Но так бывает не всегда. Например, задачи по интеграции могут делегироваться на GitLab CI, а задачи по доставке – отдаваться в Jenkins.
Правая часть схемы изображает CI. Мы обсудили ее выше. Слева показана CD. Задача по CD создает проект (или повторно использует артефакты, полученные на стадии CI) и развертывает его на конечном сервере.
Стоит отметить, что сервер в нашем случае – это понятие абстрактное. Например, развертывание может выполняться в кластер Kubernetes. Так что самих серверов может быть несколько.
Обычно после стадии развертывания на почту приходят сообщения о выполнении. Например, CD-сервер может уведомлять подписчиков об успешном развертывании/ошибках.
В любом случае, возникает важный вопрос. В какой момент мы должны запускать задачи по CD? Триггеры могут быть разными.
Развертывание после каждого слияния Pull Request.
Развертывание по расписанию.
Развертывание после каждого слияния Pull Request с определенной веткой.
Сочетание нескольких вариантов.
В первом пункте процесс выстроен так, что задачи по CI и CD всегда выполняются последовательно. Данный подход весьма популярен при разработке программ с исходным кодом. Библиотека Semantic Release помогает настроить проект для прозрачной интеграции данной модели.
Важно помнить о трактовке понятия deploy (развертывание). Это не всегда «что-то где-то запустить». Например, при разработке библиотеки, нет никакого запуска. В данном случае процесс развертывания означает выпуск новой версии библиотеки.
Второй пункт не зависит от процесса CI, ведь проект развертывается по определенному расписанию. Например, ежедневно в 01:00.
Третий пункт аналогичен первому, но с небольшими отличиями. Предположим, в репозитории у нас есть 2 основные ветки: develop и master. В develop содержатся самые последние изменения, а в master – только релизы версий. Если мы хотим развертывать только ветку master, то не нужно вызывать CD-задачу по слиянию в develop.
Последний пункт – это сочетание подходов. Например, ветку develop можно развертывать по расписанию в среду разработки. А ветку master – в реальную среду по каждому слиянию Pull Request.
Инструменты
На рынке доступно множество решений по автоматизации процессов CI/CD. Ниже представлено несколько продуктов.
Jenkins. Один из самых востребованных инструментов CI/CD в мире. Свою популярность он заслужил, благодаря политике открытого кода (open-source). То есть вам не нужно ни за что платить. В Jenkins вы можете императивно описывать конвейеры сборки с помощью Groovy. С одной стороны это достаточно гибкое решение, но с другой – требует более высокого уровня квалификации.
GitHub Actions. Этот инструмент для CI/CD доступен для GitHub и GitHub Enterprise. В отличие от Jenkins, GitHub Actions предлагает декларативные сценарии сборки с YAML-конфигурацией. Кроме того, в данном решении доступна интеграция с различными системами обеспечения качества (например SonarCube). Таким образом, сборку можно описать в нескольких текстовых строках.
GitLab CI. Во многом похож на GitHub Actions, но со своими особенностями. Например, GitLab CI может указывать на определенные тесты, вызывающие ошибку в сборке.
Travis CI. Облачный CI/CD-сервис. Предлагает множество возможностей, не требующих сложных настроек. Например, шифрование данных, которые следует скрыть в публичном репозитории. Есть и приятный бонус в том, что Travis CI можно совершенно бесплатно использовать в публичных open-source проектах на GitHub, GitLab и BitBucket.
База данных временных рядов, она же Time Series Database (TSDB), оптимизирована для меток времени или данных временных рядов. Данные временных рядов - это средние измерения или события, которые прослежены, собраны, или объединены в течение определенного времени. Это могут быть данные, собранные из контрольных сигналов датчиков движения, метрики JVM из java-приложений, данные рыночной торговли, сетевые данные, ответы API, время безотказной работы процесса и т.д.
Базы данных временных рядов полностью настраиваются с данными временных меток, которые индексируются и эффективно записываются таким образом, что можно вставить данные временных рядов. Эти данные временных рядов можно запрашивать гораздо быстрее, чем из реляционной базы данных или базы данных NoSQL.
В последнее время она приобрела большую популярность. А почему нет? Это замечательный инструмент для мониторинга бизнеса и ИТ-операций. Хорошая новость в том, что есть множество вариантов выбора, и большинство из них - с открытым исходным кодом.
1. InfluxDB
InfluxDB является одной из самых популярных баз данных временных рядов среди DevOps, которая написана в Go. InfluxDB была разработана с самого начала, с целью обеспечить высокомасштабируемый механизм приема и хранения данных. Он очень эффективен при сборе, хранении, запросе, визуализации и выполнении действий с потоками данных временных рядов, событий и метрик в реальном времени.
Она предоставляет политики понижающей дискретизации и хранения данных для поддержания высокой ценности, высокой точности данных в памяти и более низкой ценности данных на диске. Он построен на основе "облачной" технологии для обеспечения масштабируемости в нескольких топологиях развертывания, включая локальную облачную среду и гибридные среды.
InfluxDB - это решение с открытым исходным кодом и готовое для развертывания на предприятии. Он использует InfluxQL, который очень похож на язык SQL, для взаимодействия с данными. Последняя версия содержит агенты, панели мониторинга, запросы и задачи в наборе инструментов. Это универсальный инструмент для панели мониторинга, визуализации и оповещения.
Особенности
Высокая производительность для данных временных рядов с высоким уровнем приема и запросов в реальном времени
InfluxQL для взаимодействия с данными, которые схож с языком запросов SQL.
Основной компонент стека TICK (Telegraf, InfluxDB, Chronograf и Kapacitor)
Поддержка плагинов для таких протоколов, как collectd, Graphite, OpenTSDB для приема данных
Может обрабатывать миллионы точек данных всего за 1 секунду
Политики хранения для автоматического удаления устаревших данных
Так как это открытый исходный код, вы можете загрузить и поднять его на своем сервере. Тем не менее, они предлагают InfluxDB Cloud на AWS, Azure и GCP.
2. Prometheus
Prometheus - это решение для мониторинга с открытым исходным кодом, используемое для анализа данных метрик и отправки необходимых предупреждений. Он имеет локальную базу данных временных рядов на диске, которая хранит данные в пользовательском формате на диске.
Модель данных Prometheus многомерна на основе временных рядов; он сохраняет все данные в виде потоков значений с временной меткой. Это очень полезно при работе с полностью числовым временным рядом. Сбор данных о микросервисах и их запрос - одна из сильных сторон Prometheus.
Он плотно интегрируется с Grafana для визуализации.
Особенности
Имеет многомерную модель, в которой использовались пары "имя метрики" и "ключ-значение" (метки)
PromQL используется для запроса данных временных рядов для создания таблиц, оповещений и графиков Adhoc
Использует режим HTTP pull для сбора данных временных рядов
Использует промежуточный шлюз для передачи временных рядов
У Prometheus есть сотни экспортеров для экспорта данных из Windows, Linux, Java, базы данных, API, веб-сайта, серверного оборудования, PHP, обмена сообщениями и т.д.
3. TimescaleDB
TimesterDB - реляционная база данных с открытым исходным кодом, которая делает SQL масштабируемым для данных временных рядов. Эта база данных построена на PostgreSQL.
Он предлагает два продукта - первый вариант - это бесплатное издание, которое вы можете установить на свой сервер. Второй вариант - TimesterDB Cloud, где вы получаете полностью размещенную и управляемую инфраструктуру в облаке для вашего развертывания.
Он может использоваться для мониторинга DevOps, понимания показателей приложений, отслеживания данных с устройств Интернета вещей, понимания финансовых данных и т.д. Можно измерять журналы, события Kubernetes, метрики Prometheus и даже пользовательские метрики.
Владельцы продуктов могут использовать его для понимания производительности продукта с течением времени, что помогает принимать стратегические решения для роста.
Особенности
Выполнение запросов 10-100X быстрее, чем PostgreSQL, MongoDB
Возможность горизонтального масштабирования до петабайт и записи миллионов точек данных в секунду
Очень похож на PostgreSQL, что облегчает работу с ним разработчиков и администраторов.
Сочетание функций реляционных баз данных и баз данных временных рядов для создания мощных приложений.
Встроенные алгоритмы и функции производительности для защиты от больших затрат.
4. Graphite
Graphite - это универсальное решение для хранения и эффективной визуализации данных в реальном времени. Графит может выполнять две функции: хранить данные временных рядов и визуализировать графики по требованию. Но она не собирает данные для вас; для этого можно использовать такие инструменты, как collectd, Ganglia, Sensu, telegraf и т. д.
Он имеет три компонента - Carbon, Whisper и Graphite-Web. Carbon получает данные временных рядов, агрегирует их и сохраняет на диске. Whisper - это хранилище базы данных временных рядов, в котором хранятся данные. Graphite-Web - это интерфейс для создания панелей мониторинга и визуализации данных.
Особенности Graphite:
Формат метрик, в котором передаются данные, прост.
Комплексный API для визуализации данных и создания диаграмм, панелей мониторинга, графиков
Предоставляет богатый набор статистических библиотек и функций преобразования
Связывает несколько функций визуализации для создания целевого запроса.
5. QuestDB
QuestDB - это реляционная база данных, ориентированная на столбцы, которая может выполнять анализ данных временных рядов в реальном времени. Он работает с SQL и некоторыми расширениями для создания реляционной модели для данных временных рядов. QuestDB был создан с нуля и не имеет зависимостей, повышающих его производительность.
QuestDB поддерживает реляционные соединения и соединения временных рядов, что помогает сопоставлять данные. Самый простой способ начать работу с QuestDB - развернуть его внутри контейнера Docker.
Функции QuestDB:
Интерактивная консоль для импорта данных с помощью перетаскивания и запроса
Поддерживается работа как на облачных технологиях (AWS, Azure, GCP), так и локально.
Поддерживает такие корпоративные возможности, как работа с Active Directory, обеспечение высокой доступности, корпоративная безопасность, кластеризация
Предоставляет информацию в режиме реального времени с использованием оперативной и прогнозируемой аналитики
6. AWS Timestream
Как AWS может отсутствовать в списке?
AWS Timestream - это служба базы данных временных рядов без сервера, которая является быстрой и масштабируемой. Он используется главным образом для приложений Интернета вещей, чтобы хранить триллионы событий в день и в 1000 раз быстрее при 1/10 стоимости реляционных баз данных.
С помощью специализированного механизма запросов можно одновременно запрашивать последние данные и архивные сохраненные данные. Она предоставляет множество встроенных функций для анализа данных временных рядов для поиска полезной информации.
Функции Amazon Timestream:
Нет серверов для управления или экземпляров для выделения; все обрабатывается автоматически.
Экономичный, платите только за то, что вы принимаете, храните и запрашиваете.
Способен ежедневно принимать триллионы событий без снижения производительности
Встроенная аналитика со стандартными функциями SQL, интерполяции и сглаживания для определения тенденций, шаблонов и аномалий
Все данные шифруются с помощью системы управления ключами AWS (KMS) с ключами управления клиента (CMK)
7. OpenTSDB
OpenTSDB - масштабируемая база данных временных рядов, написанная поверх HBase. Он способен хранить триллионы точек данных при миллионах операций записи в секунду. Данные в OpenTSDB можно хранить вечно с его исходной меткой времени и точным значением, чтобы не потерять данные.
Имеет демон временных рядов (TSD) и утилиты командной строки. Демон временных рядов отвечает за хранение данных в HBase или их извлечение из нее. С TSD можно общаться с помощью HTTP API, telnet или простого встроенного графического интерфейса. Для сбора данных из различных источников в OpenTSDB нужны такие инструменты, как flume, collectd, vacuumetrix и т.д.
Функции OpenTSBD:
Может агрегировать, фильтровать, понижать метрики на огромной скорости
Хранение и запись данных с точностью до миллисекунды
Работает на Hadoop и HBase и легко масштабируется, добавляя узлы в кластер
Использование графического интерфейса для создания графиков
Заключение
Поскольку в наши дни используются все больше и больше IoT или умных устройств, на веб-сайтах с миллионами событий в день в реальном времени генерируется огромный трафик, увеличивается торговля на рынке, что и привело к созданию база данных временных рядов! Базы данных временных рядов являются обязательным элементом производственного стека для мониторинга.
Большая часть вышеперечисленной базы данных временных рядов доступна для бесплатного использования, поэтому получите облачную виртуальную машину и попробуйте посмотреть, что подойдет именно вам.
Linux поддерживает множество файловых систем, таких как ext4, ZFS, XFS, Btrfs, Reiser4 и другие.
Различные типы файловых систем решают разные проблемы, и их использование зависит от приложения.
Что такое файловая система Linux
Почти каждый бит данных и программ, необходимых для загрузки системы Linux и поддержания ее работы, сохраняется в файловой системе. Например, сама операционная система, компиляторы, прикладные программы, разделяемые библиотеки, файлы конфигурации, файлы журналов, точки монтирования мультимедиа и т.д.
Файловые системы работают в фоновом режиме. Как и остальная часть ядра операционной системы, они практически невидимы при повседневном использовании.
Файловая система Linux обычно представляет собой встроенный уровень операционной системы Linux, используемый для управления данными хранилища. Он контролирует, как данные хранятся и извлекаются. Он управляет именем файла, размером файла, датой создания и другой информацией о файле.
Файловая система ext4
В 1992 году была запущена файловая Extended File System или ext специально для операционной системы Linux. Она уходит своими корнями в операционную систему Minix. В 1993 году было выпущено обновление под названием Extended File System 2 или ext2, которое в течение многих лет было файловой системой по умолчанию во многих дистрибутивах Linux. К 2001 году ext2 была обновлена до ext3, которая ввела журналирование для защиты от повреждений в случае сбоев или сбоев питания.
Ext4 была представлена в 2008 году и является файловой системой Linux по умолчанию с 2010 года. Она была разработана как прогрессивная версия файловой системы ext3 и преодолевает ряд ограничений в ext3. Она имеет значительные преимущества перед своим предшественником, такие как улучшенный дизайн, лучшая производительность, надежность и новые функции.
В настоящее время ext4 является файловой системой по умолчанию в большинстве дистрибутивов Linux. Она может поддерживать файлы и файловые системы размером до 16 терабайт. Она также поддерживает неограниченное количество подкаталогов (файловая система ext3 поддерживает только до 32 000). Кроме того, ext4 обратно совместима с ext3 и ext2, что позволяет монтировать эти старые версии с драйвером ext4.
Есть причина, по которой ext4 является выбором по умолчанию для большинства дистрибутивов Linux. Она опробована, протестирована, стабильна, отлично работает и широко поддерживается. Если вам нужна стабильность, ext4 - лучшая файловая система Linux для вас.
Однако несмотря на все свои функции, ext4 не поддерживает прозрачное сжатие, прозрачное шифрование или дедупликацию данных.
Файловая система XFS
XFS - это высокомасштабируемая файловая система, разработанная Silicon Graphics и впервые развернутая в операционной системе IRIX на базе Unix в 1994 году. Это файловая система с журналированием которая отслеживает изменения в журнале перед фиксацией изменений в основной файловой системе. Преимущество заключается в гарантированной целостности файловой системы и ускоренном восстановлении в случае сбоев питания или сбоев системы.
Первоначально XFS была создана для поддержки чрезвычайно больших файловых систем с размерами до 16 эксабайт и размером файлов до 8 эксабайт. Она имеет долгую историю работы на больших серверах и массивах хранения.
Одной из примечательных особенностей XFS является гарантированная скорость ввода-вывода. Это позволяет приложениям зарезервировать пропускную способность. Файловая система рассчитывает доступную производительность и корректирует свою работу в соответствии с существующими резервированиями.
XFS имеет репутацию системы, работающей в средах, требующих высокой производительности и масштабируемости, и поэтому регулярно оценивается как одна из самых производительных файловых систем в больших системах с корпоративными рабочими нагрузками.
Сегодня XFS поддерживается большинством дистрибутивов Linux и теперь стала файловой системой по умолчанию в Red Hat Enterprise Linux, Oracle Linux, CentOS и многих других дистрибутивах.
Лучшие варианты использования файловой системы XFS
У вас большой сервер? У вас большие требования к хранилищу или у вас есть локальный медленный диск SATA?
Если и ваш сервер, и ваше устройство хранения большие и нет необходимости уменьшать размер файловой системы, XFS, вероятно, будет лучшим выбором. XFS - отличная файловая система, которая хорошо масштабируется для больших серверов. Но даже с меньшими массивами хранения XFS работает очень хорошо, когда средние размеры файлов велики, например, размером в сотни мегабайт.
Файловая система btrfs
Btrfs - это файловая система Linux общего назначения нового поколения, которая предлагает уникальные функции, такие как расширенное интегрированное управление устройствами, масштабируемость и надежность. Он распространяется под лицензией GPL и открыт для внесения вклада кем угодно. Для файловой системы используются разные имена, в том числе «Butter FS», «B-tree FS» и «Better FS».
Разработка Btrfs началась в Oracle в 2007 году. Она была объединена с основным ядром Linux в начале 2009 года и дебютировала в версии Linux 2.6.29.
Btrfs не является преемником файловой системы ext4 по умолчанию, используемой в большинстве дистрибутивов Linux, но предлагает лучшую масштабируемость и надежность. Btrfs - это файловая система с копированием при записи (Copy-on-Write - CoW), предназначенная для устранения различных недостатков в текущих файловых системах Linux. Основное внимание уделяется отказоустойчивости, самовосстановлению и простоте администрирования.
Btrfs может поддерживать до 16 эксбибайт раздела и файл того же размера. Если вас смущают цифры, все, что вам нужно знать, это то, что Btrfs может поддерживать до шестнадцати раз больше данных Ext4.
Как работает Copy-on-Write и зачем вам это нужно
В традиционной файловой системе при изменении файла данные считываются, изменяются, а затем записываются обратно в то же место. В файловой системе с копией при записи он считывает данные, изменяет их и записывает в новое место. Это предотвращает потерю данных во время транзакции чтения-изменения-записи, поскольку данные всегда находятся на диске.
Поскольку вы не «перенаправляете» до тех пор, пока новый блок не будет полностью записан, если пропадет питание или выйдет из строя в середине записи, вы получите либо старый блок, либо новый блок, но не наполовину записанный поврежденный блокировать. Таким образом, вам не нужно проверять файловые системы при запуске, и вы снижаете риск повреждения данных.
Вы можете сделать снимок файловой системы в любой момент, создав запись снимка в метаданных с текущим набором указателей. Это защищает старые блоки от последующего сбора мусора и позволяет файловой системе представить том в том виде, в котором он был во время моментального снимка. Другими словами, у вас есть возможность мгновенного отката. Вы даже можете клонировать этот том, чтобы сделать его доступным для записи на основе снимка.
Особенности Btrfs
Copy-on-Write и создание снепшотов - Сделайте инкрементное резервное копирование безболезненным даже из файловой системы в процессе работы или виртуальной машины (VM).
Контрольные суммы на уровне файла - метаданные для каждого файла включают контрольную сумму, которая используется для обнаружения и исправления ошибок.
Сжатие - файлы можно сжимать и распаковывать "на лету", что увеличивает скорость чтения.
Автоматическая дефрагментация - файловые системы настраиваются фоновым потоком, пока они используются.
Подтомы - файловые системы могут совместно использовать единый пул пространства вместо того, чтобы помещаться в свои собственные разделы.
RAID - Btrfs выполняет свои собственные реализации RAID, поэтому LVM или mdadm не требуются для наличия RAID. В настоящее время поддерживаются RAID 0, 1 и 10. RAID 5 и 6 считаются нестабильными.
Разделы необязательны - хотя Btrfs может работать с разделами, он может напрямую использовать необработанные устройства (/dev/<device>).
Дедупликация данных - поддержка дедупликации данных ограничена; однако дедупликация со временем станет стандартной функцией Btrfs. Это позволяет Btrfs экономить место, сравнивая файлы через двоичные файлы diff.
Хотя это правда, что Btrfs все еще считается экспериментальным и в настоящее время находится в активной разработке, время, когда Btrfs станет файловой системой по умолчанию для систем Linux, приближается. Некоторые дистрибутивы Linux уже начали переходить на него в своих текущих выпусках.
Файловая система ZFS
ZFS (Zettabyte File System) остается одной из наиболее технически продвинутых и полнофункциональных файловых систем с момента ее появления в октябре 2005 года. Это локальная файловая система (например, ext4) и менеджер логических томов (например, LVM), созданные Sun Microsystems. ZFS публиковалась под лицензией с открытым исходным кодом, пока Oracle не купила Sun Microsystems и не закрыла лицензию.
Вы можете думать о ZFS как о диспетчере томов и как о RAID-массиве одновременно, что позволяет добавлять дополнительные диски к вашему тому ZFS, что позволяет одновременно добавить дополнительное пространство в вашу файловую систему. В дополнение к этому ZFS обладает некоторыми другими функциями, которых нет в традиционных RAID.
ZFS сильно зависит от памяти, поэтому для запуска вам потребуется не менее 8 ГБ. На практике используйте столько, сколько можете получить в соответствии с вашим аппаратным обеспечением или бюджетом.
ZFS обычно используется сборщиками данных, пользователями NAS и другими гиками, которые предпочитают полагаться на собственную избыточную систему хранения, а не на облако. Это отличная файловая система для управления несколькими дисками с данными, которая может соперничать с некоторыми из лучших конфигураций RAID.
ZFS похожа на другие подходы к управлению хранилищем, но в некотором смысле радикально отличается. ZFS обычно не использует Linux Logical Volume Manager (LVM) или разделы диска, и обычно удобно удалять разделы и структуры LVM перед подготовкой носителя для zpool.
Zpool - это аналог LVM. Zpool охватывает одно или несколько устройств хранения, а члены zpool могут быть нескольких различных типов. Основные элементы хранения - одиночные устройства, зеркала и raidz. Все эти элементы хранения называются vdevs.
ZFS может обеспечить целостность хранилища намного лучше, чем любой RAID-контроллер, поскольку он досконально знает структуру файловой системы. Безопасность данных - важная особенность конструкции ZFS. Все блоки, записанные в zpool, тщательно проверяются контрольной суммой для обеспечения согласованности и правильности данных.
Для использования на сервере, где вы хотите почти полностью исключить любую возможность потери данных и стабильности, вы можете изучить ZFS.
Возможности ZFS
Бесконечная масштабируемость. Что ж, технически она не бесконечна, но это 128-битная файловая система, способная управлять зеттабайтами (одним миллиардом терабайт) данных. Поэтому независимо от того, сколько у вас места на жестком диске, ZFS подойдет для управления им.
Максимальная целостность. Все, что вы делаете внутри ZFS, использует контрольную сумму для обеспечения целостности файла. Вы можете быть уверены, что ваши файлы и их резервные копии не испытают скрытого повреждения данных. Кроме того, пока ZFS незаметно проверяет целостность ваших данных, она будет выполнять автоматическое восстановление в любое время.
Объединение дисков. Создатели ZFS хотят, чтобы вы думали об этом как о том, как ваш компьютер использует оперативную память. Когда вам нужно больше памяти на вашем компьютере, вы вставляете другую карту, и все готово. Точно так же с ZFS, когда вам нужно больше места на жестком диске, вы вставляете другой жесткий диск, и все готово. Не нужно тратить время на разбиение на разделы, форматирование, инициализацию или что-то еще с вашими дисками. Если вам нужен «пул» хранилища большего размера, просто добавьте диски.
RAID. ZFS поддерживает множество различных уровней RAID, обеспечивая при этом производительность, сравнимую с производительностью аппаратных RAID-контроллеров. Это позволяет сэкономить деньги, упростить настройку и получить доступ к превосходным уровням RAID, которые были улучшены в ZFS.
Файловая система Reiser4
ReiserFS - это файловая система общего назначения с журналированием, первоначально разработанная и реализованная командой Namesys во главе с Хансом Райзером. Представленная в версии 2.4.1 ядра Linux, это была первая файловая система с журналированием, включенная в стандартное ядро.
За исключением обновлений безопасности и исправлений критических ошибок, Namesys прекратила разработку ReiserFS. Reiser4 является преемницей файловой системы ReiserFS. Добавилось шифрование, улучшил производительность и многое другое.
Reiser4 обеспечивает наиболее эффективное использование дискового пространства среди всех файловых систем во всех сценариях и рабочих нагрузках. ReiserFS предлагает преимущества перед другими файловыми системами, особенно когда дело доходит до обработки большого количества небольших файлов. Она поддерживает ведение журнала для быстрого восстановления в случае возникновения проблем. Структура файловой системы основана на деревьях. Кроме того, Reiser4 потребляет немного больше ресурсов ЦП, чем другие файловые системы.
Reiser4 обладает уникальной способностью оптимизировать дисковое пространство, занимаемое небольшими файлами (менее одного блока). Они полностью хранятся в своем индексном дескрипторе, без выделения блоков в области данных.
Помимо реализации традиционных функций файловой системы Linux, reiser4 предоставляет пользователям ряд дополнительных возможностей: прозрачное сжатие и шифрование файлов, полное ведение журнала данных, а также практически неограниченную (с помощью архитектуры подключаемых модулей) расширяемость.
Однако в настоящее время нет поддержки прямого ввода-вывода (началась работа по реализации), квот и POSIX ACL.