что такое trash в распределенной fs

Русские Блоги

2. HDFS распределенная файловая система

1. Содержание курса

Во-вторых, распределенная файловая система воспринимается как должное

Три, что такое распределенная файловая система

4. Псевдораспределенные шаги установки для построения среды HDFS

Пять, API-интерфейс JAVA HDFS

5.1 Используйте IDEA для создания проекта maven и введения зависимых пакетов jar

5.2 Использование Java API для работы с HDFS

* Работа Hadoop HDFS Java API

public class HDFSApp <

public static final String HDFS_PATH = «hdfs://hadoop000:8020»;

FileSystem fileSystem = null;

Configuration configuration = null;

* Создать каталог HDFS

public void mkdir() throws Exception <

public void create() throws Exception <

FSDataOutputStream output = fileSystem.create(new Path(«/hdfsapi/test/a.txt»));

* Просмотр содержимого файла HDFS

public void cat() throws Exception <

FSDataInputStream in = fileSystem.open(new Path(«/hdfsapi/test/a.txt»));

IOUtils.copyBytes(in, System.out, 1024);

public void rename() throws Exception <

Path oldPath = new Path(«/hdfsapi/test/a.txt»);

Path newPath = new Path(«/hdfsapi/test/b.txt»);

* Загрузить файлы в HDFS

public void copyFromLocalFile() throws Exception <

Path localPath = new Path(«/Users/rocky/data/hello.txt»);

Path hdfsPath = new Path(«/hdfsapi/test»);

* Загрузить файлы в HDFS

public void copyFromLocalFileWithProgress() throws Exception <

InputStream in = new BufferedInputStream(

FSDataOutputStream output = fileSystem.create(new Path(«/hdfsapi/test/spark-1.6.1.tgz»),

public void progress() <

System.out.print («.»); // С информацией о напоминании прогресса

IOUtils.copyBytes(in, output, 4096);

public void copyToLocalFile() throws Exception <

Path localPath = new Path(«/Users/rocky/tmp/h.txt»);

Path hdfsPath = new Path(«/hdfsapi/test/hello.txt»);

* Просмотр всех файлов в каталоге

public void listFiles() throws Exception <

FileStatus[] fileStatuses = fileSystem.listStatus(new Path(«/»));

for(FileStatus fileStatus : fileStatuses) <

Источник

Hadoop Distributed File System

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

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

Ответом GFS стал open source проект Hadoop, с его Hadoop Distributed File System. Проект активно поддерживается и развивается компанией Yahoo (18 человек). Проведем сравнительный анализ терминов, используемых в данных системах, установим их соответствие и остановимся подробнее на HDFS:

HDFS — распределенная файловая система, используемая в проекте Hadoop. HDFS-кластер в первую очередь состоит из NameNоde-сервера и DataNode-серверов, которые хранят непосредственно данные. NameNode-сервер управляет пространством имен файловой системы и доступом клиентов к данным. Чтобы разгрузить NameNode-сервер, передача данных осуществляется только между клиентом и DataNode-сервером.

Secondary NameNode:

Основной NameNode-сервер фиксирует все транзакции, связанные с изменением метаданных файловой системы, в log-файле, называемом EditLog. При запуске основного NameNode-сервера, он считывает образ HDFS (расположенный в файле FsImage) и применяет к нему все изменения, накопленные в EditLog. Затем записывается новый образ уже с примененными изменениями, и система начинает работу уже с чистым log-файлом. Следует заметить, что данную работу NameNode-сервер выполняет единожды при его первом запуске. В последующем, подобные операции возлагаются на вторичный NameNode-сервер. FsImage и EditLog в конечном итоге хранятся на основном сервере.

Механизм репликации:

При обнаружении NameNode-сервером отказа одного из DataNode-серверов (отсутствие heartbeat-сообщений от оного), запускается механизм репликации данных:

— выбор новых DataNode-серверов для новых реплик
— балансировка размещения данных по DataNode-серверам

Аналогичные действия производятся в случае повреждении реплик или в случае увеличения количества реплик присущих каждому блоку.

Стратегия размещение реплик:

Данные хранятся в виде последовательности блоков фиксированного размера. Копии блоков (реплики) хранятся на нескольких серверах, по умолчанию — трех. Их размещение происходит следующим образом:

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

При чтении данных клиент выбирает ближайшую к нему DataNode-сервер с репликой.

Целостность данных:

Ослабленная модель целостности данных, реализованная в файловой системе, не гарантирует идентичность реплик. Поэтому HDFS перекладывает проверку целостности данных на клиентов. При создании файла клиент рассчитывает контрольные суммы каждые 512 байт, которые в последующем сохраняются на DataNode-сервере. При считывании файла, клиент обращается к данным и контрольным суммам. И, в случае их несоответствия происходит обращение к другой реплике.

Запись данных:

«При записи данных в HDFS используется подход, позволяющий достигнуть высокой пропускной способности. Приложение ведет запись в потоковом режиме, при этом HDFS-клиент кэширует записываемые данные во временном локальном файле. Когда в файле накапливаются данные на один HDFS-блок, клиент обращается к NameNode-серверу, который регистрирует новый файл, выделяет блок и возвращает клиенту список datanode-серверов для хранения реплик блока. Клиент начинает передачу данных блока из временного файла первому DataNode-серверу из списка. DataNode-сервер сохраняет данные на диске и пересылает следующему DataNode-серверу в списке. Таким образом, данные передаются в конвейерном режиме и реплицируются на требуемом количестве серверов. По окончании записи, клиент уведомляет NameNode-сервер, который фиксирует транзакцию создания файла, после чего он становится доступным в системе»

Удаление данных:

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

— удаление файла из пространства имен HDFS
— освобождение связанных с данными блоков

Текущие недостатки:

— отсутствие автоматического запуска главного сервера в случае его сбоя (данная функциональность реализована в GFS)
— отсутствие операций append (предполагается в версии 0.19.0) и snapshot (данные функциональности также реализованы в GFS)

Почитать, что будет в следующих версиях HDFS можно в вики проекта на сайте Apache Foundation. Дополнительную информацию и мнения людей работающих с Hadoop можно найти в блогах компаний активно использующих данную технологию: Yahoo, A9, Facebook, Last.fm, Laboratory

Источники:

— Dhruba B. Hadoop Distributed File System, 2007
— Tom W. A Tour of Apache Hadoop
— Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung The Google File System
— Сухорослов О.В. Новые технологии распределенного хранения и обработки больших массивов данных

Источник

Понимая, как используется дисковое пространство в Linux

Прим перев.: Автор оригинальной статьи — испанский Open Source-энтузиаст nachoparker, развивающий проект NextCloudPlus (ранее известен как NextCloudPi), — делится своими знаниями об устройстве дисковой подсистемы в Linux, делая важные уточнения в ответах на простые, казалось бы, вопросы…

Сколько пространства занимает этот файл на жёстком диске? Сколько свободного места у меня есть? Сколько ещё файлов я смогу вместить в оставшееся пространство?

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

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

Размер файла

Что такое размер файла? Ответ вроде бы прост: совокупность всех байтов его содержимого, от начала до конца файла.

Зачастую всё содержимое файла представляется как расположенное байт за байтом:

Здесь можно увидеть знакомые атрибуты, такие как время доступа и модификации, а также i_size — это и есть размер файла, как он был определён выше.

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

Блоки и размер блока

Для внутреннего хранения файла файловая система разбивает хранилище на блоки. Традиционным размером блока были 512 байт, но более актуальное значение — 4 килобайта. Вообще же при выборе этого значения руководствуются поддерживаемым размером страницы на типовом оборудовании MMU (memory management unit, «устройство управления памятью» — прим. перев.).

Файловая система вставляет порезанный на части (chunks) файл в эти блоки и следит за ними в метаданных. В идеале всё выглядит так:

… но в действительности файлы постоянно создаются, изменяются в размере, удаляются, поэтому реальная картина такова:

Это называется внешней фрагментацией (external fragmentation) и обычно приводит к падению производительности. Причина — вращающейся головке жёсткого диска приходится переходить с места на место, чтобы собрать все фрагменты, а это медленная операция. Решением данной проблемы занимаются классические инструменты дефрагментации.

Что происходит с файлами меньше 4 КБ? Что происходит с содержимым последнего блока после того, как файл был порезан на части? Естественным образом будет возникать неиспользуемое пространство — это называется внутренней фрагментацией (internal fragmentation). Очевидно, этот побочный эффект нежелателен и может привести к тому, что многое свободное пространство не будет использоваться, особенно если у нас большое количество очень маленьких файлов.

Таким образом, мы смотрим на две величины: размер файла и использованные блоки. Мы привыкли думать в терминах первого, однако должны — в терминах последнего.

Специфичные для файловой системы возможности

Помимо актуального содержимого файла ядру также необходимо хранить все виды метаданных. Метаданные inode’а мы уже видели, но есть и другие данные, с которыми знаком каждый пользователь UNIX: права доступа, владелец, uid, gid, флаги, ACL.

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

Метаданные размещения блоков

Эти данные сильно зависят от используемой файловой системы — в каждой из них по-своему реализовано сопоставление блоков с файлами. Традиционный подход ext2 — таблица i_block с прямыми и непрямыми блоками (direct/indirect blocks).

Эту же таблицу можно увидеть в структуре памяти (фрагмент из fs/ext2/ext2.h ):

Для больших файлов такая схема приводит к большим накладным расходам, поскольку единственный (большой) файл требует сопоставления тысяч блоков. Кроме того, есть ограничение на размер файла: используя такой метод, 32-битная файловая система ext3 поддерживает файлы не более 8 ТБ. Разработчики ext3 спасали ситуацию поддержкой 48 бит и добавлением extents:

Идея по-настоящему проста: занимать соседние блоки на диске и просто объявлять, где extent начинается и каков его размер. Таким образом мы можем выделять файлу большие группы блоков, минимизируя количество метаданных и заодно используя более быстрый последовательный доступ.

Примечание для любопытных: у ext4 предусмотрена обратная совместимость, то есть в ней поддерживаются оба метода: непрямой (indirect) и extents. Увидеть, как распределено пространство, можно на примере операции записи. Запись не идёт напрямую в хранилище — из соображений производительности данные сначала попадают в файловый кэш. После этого в определённый момент кэш записывает информацию на постоянное хранилище.

Контрольные суммы

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

Более современные системы вроде BTRFS и ZFS поддерживают контрольные суммы для данных, а у более старых, таких как ext4, реализованы контрольные суммы для метаданных.

Журналирование

Это специальный скрытый файл, обычно с номером inode 8 и размером 128 МБ, объяснение про который можно найти в официальной документации:

Журнал, представленный в файловой системе ext3, используется в ext4 для защиты ФС от повреждений в случае системных сбоев. Небольшой последовательный фрагмент диска (по умолчанию это 128 МБ) зарезервирован внутри ФС как место для сбрасывания «важных» операций записи на диск настолько быстро, насколько это возможно. Когда транзакция с важными данными полностью записана на диск и сброшена с кэша (disk write cache), запись о данных также записывается в журнал. Позже код журнала запишет транзакции в их конечные позиции на диске (операция может приводить к продолжительному поиску или большому числу операций чтения-удаления-стирания) перед тем, как запись об этих данных будет стёрта. В случае системного сбоя во время второй медленной операции записи журнал позволяет воспроизвести все операции вплоть до последней записи, гарантируя атомарность всего, что пишется на диск через журнал. Результатом является гарантия, что файловая система не застрянет на полпути обновления метаданных.

«Упаковка хвостов»

Возможность tail packing, ещё называемая блочным перераспределением (block suballocation), позволяет файловым системам использовать пустое пространство в конце последнего блока («хвосты») и распределять его среди различных файлов, эффективно упаковывая «хвосты» в единый блок.

Замечательно иметь такую возможность, что позволяет сохранить много пространства, особенно если у вас большое количество маленьких файлов… Однако она приводит к тому, что существующие инструменты неточно сообщают об используемом пространстве. Потому что с ней мы не можем просто добавить все занятые блоки всех файлов для получения реальных данных по использованию диска. Эту фичу поддерживают файловые системы BTRFS и ReiserFS.

Разрежённые файлы

Большинство современных файловых систем поддерживают разрежённые файлы (sparse files). У таких файлов могут быть дыры, которые в действительности не записаны на диск (не занимают дисковое пространство). На этот раз реальный размер файла будет больше, чем используемые блоки.

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

Чтобы медленно создать 10-гигабайтный файл, который занимает около 10 ГБ дискового пространства, можно выполнить:

Чтобы создать такой же большой файл мгновенно, достаточно лишь записать последний байт… или даже сделать:

Или же воспользоваться командой truncate :

Команда cp поддерживает работу с разрежёнными файлами. С помощью простой эвристики она пытается определить, является ли исходный файл разрежённым: если это так, то результирующий файл тоже будет разрежённым. Скопировать же неразрежённый файл в разрежённый можно так:

… а обратное действие (сделать «плотную» копию разрежённого файла) выглядит так:

Таким образом, если вам нравится работать с разрежёнными файлами, можете добавить следующий алиас в окружение своего терминала (

Когда процессы читают байты в секциях дыр файловая система предоставляет им страницы с нулями. Например, можно посмотреть, что происходит, когда файловый кэш читает из файловой системы в области дыр в ext4. В этом случае последовательность в readpage.c будет выглядеть примерно так:

Файловые системы COW (copy-on-write)

Следующее (после семейства ext) поколение файловых систем принесло очень интересные возможности. Пожалуй, наибольшего внимания среди фич файловых систем вроде ZFS и BTRFS заслуживает их COW (copy-on-write, «копирование при записи»).

Когда мы выполняем операцию copy-on-write или клонирования, или копии reflink, или поверхностной (shallow) копии, на самом деле никакого дублирования extent’ов не происходит. Просто создаётся аннотация в метаданных для нового файла, которая отсылает к тем же самым extents оригинального файла, а сам extent помечается как разделяемый (shared). При этом в пользовательском пространстве создаётся иллюзия, что существуют два отдельных файла, которые можно отдельно модифицировать. Когда какой-то процесс захочет написать в разделяемый extent, ядро сначала создаст его копию и аннотацию, что этот extent принадлежит единственному файлу (по крайней мере, на данный момент). После этого у двух файлов появляется больше отличий, однако они все ещё могут разделять многие extents. Другими словами, extents в файловых системах с поддержкой COW можно делить между файлами, а ФС обеспечит создание новых extents только в случае необходимости.

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

/.bashrc ) может пригодиться, если вы хотите по умолчанию делать быстрые shallow-копии:

Следующий шаг — если есть не-shallow-копии или файл, или даже файлы, с дублирующимися extents, можно дедуплицировать их, чтобы они использовали (через reflink) общие extents и освободили пространство. Один из инструментов для этого — duperemove, однако учтите, что это естественным образом приводит к более высокой фрагментации файлов.

Если мы попытаемся теперь разобраться, как дисковое пространство используется файлами, всё будет не так просто. Утилиты вроде du или dutree всего лишь считают используемые блоки, не учитывая, что некоторые из них могут быть разделяемыми, поэтому они покажут больше занятого места, чем на самом деле используется.

К сожалению, я не знаю простых способов отслеживания занятого пространства отдельными файлами в файловых системах с COW. На уровне подтома с помощью утилит вроде btrfs-du мы можем получить приблизительное представление о количестве данных, которые уникальны для снапшота и которые разделяются между снапшотами.

Источник

Распределенные файловые системы. Технологический обзор. Продуктовый обзор

Файловая система (file system) — это способ организации, хранения и именования данных на носителях информации в компьютерах. Файловые системы используются также в другом электронном оборудовании: в цифровых фотоаппаратах и диктофонах, в мобильных телефонах, и т. п.

Распределенные файловые системы (distributed file system) работают сразу на многих компьютерах (серверах) с репликацией для защиты от сбоев. Иногда «распределенными» также называют сетевые файловые системы, тем самым показывая, что распределенные файловые системы имеют больше возможностей, чем обычная передача данных по сети. Носители СХД, связанные с распределенными файловыми системами, могут (и даже должны) быть распределены между многими компьютерными системами.

Определения

Существует также понятие «кластерная файловая система». Различия между всеми этими терминами (сетевая, распределенная, кластерная) немного расплывчаты. Поэтому сначала нужно определить, что такое сетевая, кластерная и распределенная система.

С таким определением, например, NFSv3 можно отнести к сетевой файловой системе (network file system). GFS2 – это кластерная файловая система. GlusterFS – это распределенная файловая система. NFSv4, в свою очередь, это некий гибрид между сетевой файловой системой, но с поддержкой нескольких серверов, внедренных в нее.

Сумятицу иногда вносит то, что иногда вкладывается разный смысл в понятие «распределенный» (distributed). Здесь надо понимать, что «распределенность» должна присутствовать не только между серверами (тогда это кластер) в локальной сети, но также и между местоположениями этих серверов в глобальной сети (WAN), со всеми присущими ей особенностями. А именно: большими задержками и низкой надежностью соединений.

Распределенные (в таком определении) файловые системы состоят из нескольких географически разнесенных серверов, соединенных по модели sharing nothing, где каждый активный сервер имеет собственную СХД. Кроме того, распределенные файловые системы делятся на два типа: параллельные системы (Parallel file systems) и полностью параллельные файловые системы (Fully parallel file systems).

Так называются системы, которые предоставляют параллельный доступ к их серверам хранения для каждого клиента. Это позволяет устранить «узкие места» одного сервера по всем параметрам: IOPS, полоса, ограничения вычислительной способности процессора и кэш-памяти. Такие системы используются в высокопроизводительных компьютерных системах и бизнес-приложениях, например, в информационных системах фондовых бирж, Примеры: pNFS, Lustre.

Сравнение между сетевой и распределенной файловой системой на примере Lustre (источник: https://www.atipa.com/lustre-parallel-storage)

Полностью параллельными такие системы называются в том случае, когда не только данные, но и метаданные (различные индексы и пр.), также распределяются параллельно между всеми клиентами. Примеры таких систем – OrangeFS и Ceph.

Соотношения между сетевыми системами (Network), кластерными системами (Cluster), распределенными (Distributed), а также параллельными (Parallel) и полностью параллельными системами (Fully parallel) могут быть представлены следующим образом.

Соотношения между видами и типами распределенных (distributed file system) файловых систем (источник: lvee.org/en/abstracts/33)

С какой целью создавались распределенные файловые системы и какие задачи они решают

Во-первых, как уже указывалось, они нужны для защиты от сбоев и облегчения масштабирования СХД. Большое значение имеет API (Application Programming Interface), который они обеспечивают. Это значит, что каждое приложение, скрипт или библиотека стандартных подпрограмм, написанные в течение последних нескольких десятков лет, могут использовать распределенную файловую систему без коррекций их кода, без процедур импорта и экспорта данных. Даже такие решения, как SQL, не могут сравниться с универсальностью и простотой API распределенных файловых систем.

Во-вторых, распределенные файловые системы стали настолько популярными, что, используя их, мы иногда этого и не замечаем. Например, стриминг фильмов с сайта популярных видеохостингов (того же YouTube) почти всегда делается через распределенные файловые системы.

При производстве анимационных фильмов модели сцен и рендерные части в процессе производства почти всегда централизованно хранятся в распределенной файловой системе.

Виртуальные «блочные устройства» в облаке на самом деле часто являются файлами в распределенной файловой системе.

Системы распределенных вычислений в крупных научных лабораториях, таких как ЦЕРН, часто состоящие из более чем 100 тысяч процессоров, используют распределенные файловые системы для хранения данных экспериментов и результатов их обработки.

Можно сказать, что распределенные файловые системы – это то, как сегодня хранятся большинство данных, особенно «неструктурированных», которые используются при анализе «больших данных» (Big Data). Без этих систем провайдерам было бы очень сложно предоставлять различные онлайновые и медиауслуги.

Как пример можно было бы привести неудачу широко рекламировавшейся в свое время услуги «интернет-телевидения» (IPTV). Для того, чтобы ей воспользоваться, нужно было провести ряд сетевых настроек, которые любому IT-шнику могут показаться элементарными (например, «маска подсети» и пр.), но для простого обывателя они являлись отпугивающим фактором, несмотря на возможность смотреть «100 фильмов за 100 рублей в месяц». В результате эта услуга, что называется, «не пошла». Распределенные файловые системы с удобным интерфейсом как раз и помогают решить эти проблемы. Пример – любой популярный видеохостинг, либо пакет онлайн-телевидения от интернет-провайдера (например, «ОнЛайм» от Ростелекома).

Для различных предприятий и организаций распределенные файловые системы помогут решить проблемы управления данными и снизить стоимость хранения данных.

Распределенные файловые системы – кто они?

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

Продуктовый обзор

ZFS, IBM GPFS (Spectrum Scale), Ceph, Lustre

Файловая система ZFS была разработана в 2001 году в компании Sun Microsystems, приобретенной компанией Oracle в 2010 году. Аббревиатура ZFS означала «Zettabyte File System» (файловая система для объемов зеттабайт). Однако в настоящее время ZFS может хранить данные много большего объема.

Эта система проектировалась с очень большим запасом по параметрам, на основе совершенно справедливого прогноза огромного роста данных, подлежащих хранению в распределенных системах в будущем.

ZFS от Oracle и открытая система OpenZFS пошли разными путями, с тех пор, как Oracle закрыл проект OpenSolaris. OpenZFS — это общий проект, объединяющий разработчиков и компаний, которые используют файловую систему ZFS и работают над ее совершенствованием, чтобы сделать ZFS более широко используемым продуктом с открытым исходным кодом.

Некоторые теоретические пределы параметров, заложенные при проектировании ZFS:

Функции ZFS

ZFS обладает рядом полезных функций:

Хранение в пулах (Pooled storage)

В отличие от большинства файловых систем, ZFS объединяет функции файловой системы и менеджера томов (volume manager). Это означает, что ZFS может создавать файловую систему, которая будет простираться по многим группам накопителей ZVOL или пулам. Более того, можно добавлять емкость в пул простым добавлением нового накопителя. ZFS сама выполнит партицию и форматирование нового накопителя.

Пулы хранения в ZFS

В пулах можно легко создавать файловые системы (области хранения данных) для каждого приложения и предмета использования.

Копирование при записи (Copy-on-write)

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

Снапшоты (Snapshots)

Copy-on-write закладывает основу для другой функции ZFS: моментальных снимков системы (снапшотов). ZFS использует для отслеживания изменений в системе.

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

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

Снапшоты могут устанавливаться в режим read-only (только чтение), чтобы восстановить прежнюю версию файла. Также можно сделать откат «живой» системы на предыдущий снапшот. При этом будут потеряны только те изменения, которые были сделаны после момента этого снапшота.

Верификация целостности данных и автоматическое восстановление данных

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

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

Верификация целостности и автоматическое восстановление данных в ZFS

RAID-Z

ZFS может создавать RAID-массивы без необходимости использования дополнительного программного или аппаратного обеспечения. Поэтому неудивительно, что ZFS имеет собственный вариант RAID: RAID-Z.

RAID-Z представляет собой вариант RAID-5, котором предусмотрены средства преодоления ошибки write hole error, присущей RAID-5, когда данные и информация о паритете становятся не соответствующими друг другу после случайного перезапуска системы.

RAID-Z имеет три уровня: RAID-Z1, в котором нужно по крайней мере два диска для хранения и один для паритета; RAID-Z2, который требует по крайней мере двух дисков для хранения и двух для паритета; RAID-Z3 требует по крайней мере двух дисков для хранения и трех для паритета.

Добавление дисков в пул RAID-Z делается попарно.

Автоматическая замена на запасной диск (Hot spare)

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

Автоматическая замена дисков при отказе

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

При создании ZFS преследовалась цель сделать их «последним словом» в файловых системах. Во времена, когда большинство файловых систем были 64-битными, создатели ZFS решили, что лучше сразу заложить адресное пространство на 128 бит для будущего развития. Это означает, что ZFS имеет емкость в 16 миллиардов раз большую емкость, чем 32- или 64-битные системы. Создатель ZFS Джефф Бонвик (Jeff Bonwick), характеризуя величину этой емкости, сказал, что система в полной конфигурации с такой емкостью потребует для электропитания энергию, достаточную, чтобы вскипятить все океаны в мире.

IBM Spectrum Scale

Объем создаваемых, хранимых и анализируемых данных в мире возрастает экспоненциально. Часто требуется анализировать информацию быстрее конкурентов, причем в условиях роста собственной IT-инфраструктуры.

Файловая система в СХД организации должна поддерживать как большие данные (Big Data), так и традиционные приложения. IBM Spectrum Scale™ решает широкий спектр задач, и представляет собой высокопроизводительное решение для управления данными со встроенными функциями архивирования и аналитики.

IBM Spectrum Scale – это универсальная программно-конфигурируемая система хранения корпоративного класса, которая работает со многими типами носителей и автоматически переводит данные с уровня на уровень в зависимости от частоты их использования, обеспечивая отказоустойчивость, масштабируемость и управляемость.

Это решение, созданное на основе файловой системы IBM General Parallel File System (GPFS), способно масштабировать емкость и производительность для аналитических систем, репозиториев контента и других задач.

Когнитивные механизмы IBM умеют распределять данные среди различных устройств хранения, тем самым оптимизируя использование доступной емкости, упрощая администрирование и обеспечивая высокую производительность. IBM Spectrum Scale поддерживает глобального пространства имен с универсальным доступом, которое объединяет современные средства для работы с файлами, размещенных в сетевых файловых системах (NFS), блочные хранилища и серверы со встроенными хранилищами данных большого объема. Файловая система IBM Spectrum Scale может использоваться для работы с файлами (POSIX, NFS, CIFS), объектами (S3, SWIFT) и распределенной файловой системой Hadoop (HDFS) при решении задач анализа больших данных на месте хранения.

Задачи и возможности IBM Spectrum Scale.

Свойства IBM Spectrum Scale

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

Аналитика с учетом данных, позволяющая автоматически переносить данные на оптимальный уровень хранения (флеш, диск, кластер, лента), что позволяет до 90 % снизить расходы на архивирование данных.

Автоматическое размещение данных по уровням в файловой системе IBM Spectrum Scale

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

Безопасность данных, технологии идентификация, шифрования, защиты Erasure Coding и репликации позволяют достичь соответствия регулятивным требованиям.

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

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

Интеллектуальное кэширование данных, технология Active File Management (AFM) распространяет глобальное пространство имен Spectrum Scale за пределы географических границ, обеспечивая высокую производительность при чтении и записи данных и автоматическое управление пространством имен. Данные записываются или изменяются локально и в других местах эти данные получают с минимальной задержкой.

Графический интерфейс IBM Spectrum Scale GUI обеспечивает простое администрирование объемов данных уровня петабайт различных типов: файловых, объектных или блочных.

IBM Spectrum Scale – это хорошо зарекомендовавшее себя масштабируемое решение по администрированию данных, которое ранее называлось GPFS (General Parallel File System). Начиная с версии 4.1, это решение называется Spectrum Scale. Однако версии до 4.1 будут поддерживаться под старым названием GPFS.

Основные характеристики

Применения

Spectrum Scale используется уже более 15 лет во многих отраслях экономики во всем мире, и в таких областях, требовательных к объему и производительности обработки данных, как:

Функциональные возможности

Основные компоненты системы

Три NSD, определенные как диски tiebreaker disk для кворумных узлов (источник: IBM)

Три редакции Spectrum Scale

Есть три разных редакции (Edition) Spectrum Scale:

Источник