Файловое хранилище р12 что это

PKCS12

PKCS #12 v1.0 / 1999-06-24 ; 4913 days ago
Technical Corrigendum 1 / 2000-02-25 ; 4667 days ago

X.509 public key certificates, X.509 private keys, X.509 CRLs, generic data

Microsoft PFX формат файла

Содержание

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

Этот стандарт может быть рассмотрен как надстройка над стандартом PKCS8. Включена дополнительная идентификационная информация включающая закрытые ключи. Введен режим высокой безопасности с помощью сокрытия открытого ключа.

В руководстве по openssl этот формат охарактеризован, как один большой баг 🙂

Введение

Ещё несколько лет назад криптографические системы применялись лишь в исключительных случаях: в правительственных организациях, спецслужбах и иных критических к безопасности данных системах. Однако в настоящее время бурное развитие компьютерных сетей и Интернета заставляет задумываться об обеспечении безопасности все большее количество людей. В настоящее время все озабочены безопасностью передаваемых по сети данных. В результате чего появилось множество различных сертификатов, методов шифрования. В данной статье будет рассмотрен формат хранения ключей PKCS#12 и некоторые проблемы связанные с безопасным хранением закрытых ключей сертификатов.

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

Связь с форматом PFX

PKCS # 12 является преемником «PFX» от Microsoft. Термины «PKCS # 12 файл» и «PFX файл» иногда используются как синонимы.

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

Netscape использовал формат PFX, а не PKCS#12 в версиях 4.03 и ниже, потому что формат PKCS#12 просто не существовал. Из за необходимости обратной совместимости Netscape 4.04 и более новые версии, а также все версии MSIE поддерживали только импорт в формат PFX. Приведенная ниже таблица объединяет вышесказанное.

Режимы обмена информацией

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

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

Режим конфиденциальности

Режим честности

Формат контейнера ключей

Пара закрытого/открытого ключа состоит из двух наборов параметров. Открытые параметры с дополнительной идентификационной информацией, такой как имена пользователей и e-mail адреса, хранятся не зашифрованными. Закрытые параметры в основном хранятся с использованием некоторого механизма защиты, такого как шифрование.

Формат контейнера был определен на основе формата, реализованного в PKCS#7 и S/MIME. Следующий идентификатор объекта идентифицирует безопасный тип хранения содержимого закрытого ключа.

Безопасный тип хранения содержимого закрытого ключа должен иметь ASN.1 SecuredPrivateKey тип:

Поля типа SecuredPrivateKey имеют следующие значения:

Компоненты открытого ключа

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

В этой простейшей форме открытый ключ хранится как SubjectPublicKeyInfo. Однажды, когда был сгенерирован запрос сертификации, ‘сырая’ информация о открытом ключе может быть заменена в соответствии с требованием и, когда ключ сертифицирован, или сертификат или, полный шифр сертификата может быть сохранен.

Компоненты закрытого ключа

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

Поддерживаемые алгоритмы шифрования

PKCS#12 поддерживает следующие алгоритмы шифрования:

Кроме того также поддерживается режим PKCS#5 v1.5. Это позволяет пользоваться следующими алгоритмами:

Использование PKCS#5 v2.0 позволит использовать произвольный алгоритм шифрования.

OpenSSL может обрабатывать PKCS#5 v1.5 и v2.0 в файлах PKCS#12, однако другие реализации не поддерживаются.

В следующей таблице собраны данные о поддержки различного шифрования:

По умолчанию сильнейшее шифрование поддерживается всеми реализациями приложений, использующих PKCS#12: 3DES для закрытых ключей и RC2-40 для сертификатов. Также дополнительный опции позволяют шифровать сертификат с помощью 3DES.

Следует отметить, что в то время как множественные версии Netscape будут импортировать файлы с помощью разных алгоритмов, тогда как MSIE, кажется, поддерживает только RC2 и 3DES.

Обработка пароля пользователя

Существует несколько механизмов, позволяющий трансформировать пароль пользователя в ключ шифрования. Спецификация PKCS#5 ограничивается итерациями MD2 и MD5 для использования с ключами DES.

Для того, чтобы создать или преобразовать сертификат, вам необходимо программное обеспечение OpenSSL. SSL v3 функция, определена следующим образом:

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

TLS функция расширяет SSL v3 функцию и определяется следующим образом:

Функция получения ключа X.9-42 определена специально в терминах SHA-1:

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

Эти предположения выдвигают следующие требования для обработки пароля пользователя:

Другая полезная цель разработки заключается в том, чтобы сделать выход зависимым от алгоритма шифрования; ключ генерируется так, для того чтобы сделать key-recovery attack невозможными. Если тот же самый ключ используется для нескольких алгоритмов, то атакующий, который может получить ключ для одного алгоритма, может воспользоваться этой атакой во время использования других алгоритмов ( например, получение ключа DES позволяет получить примерно половину ключа IDEA). Сделав результат шага обработки ключа зависимым от алгоритма шифрования, режима и конфигурации, значит, что ключ, получаемый из того же самого пароля при помощи использования другого алгоритма режима или конфигурации не просто будет получить.

Эти требования предлагают следующий основной дизайн:

Параметры обработки пароля

Входные параметры для хэш-функции, используемые для генерации переменных состояния:

Поля типа StateHashData имеют следующие значения:

Входные параметры хэш-функции, используемой для получения ключа:

Идентификатор алгоритма обработки пароля

Когда используется тип EncryptedData, тогда содержимое contentEncryptionAlgorithm идентифицируется следующим образом:

id-passwordBasedEncryption OBJECT IDENTIFIER ::=

Поля типа PBEParameters имеют следующие значения:

Уязвимости

Однако, это не верно и в отношении объектов сертификата. Причина этого в том, что обеспечение целостности PKCS#12-файлов не является обязательной, как показано здесь:

Так как этот контроль опционален, то он может быть отключен и тогда содержимое файла может быть изменино без обнаружения или предупреждения. Таким образом контроль доступа не требуется для добавления объектов сертификата. В этом случае сертификаты используются в SSL PKI как Trust Anchor и это дает возможность злоумышленнику вставить Trust Anchor своего центра сертификации в эти файлы без необходимости какой-либо авторизации.

С того момента, как Trust Anchor злоумышленника вставлен в атакуемую систему она будет доверять и признавать любой сертификат, выпущенный центром сертификации атакующего.

Атака может быть произведена по схеме человек посередине, который перехватывает файлы в время транспортировки, вставляет вражеский Trust Anchor. В этом случае атака может так же работать против систем, не использующих PKCS#12-файлы, как хранилище ключей, но эта атака имеет недостаток, что фальшивый сертификат может быть обнаружен после выявления факта атаки.

Создание и преобразование сертификата

Расширение файла: «.p12» или «.pem». Эти файлы могут быть созданы с помощью OpenSSL.

Создание сертификатов PKCS#12

Подготовка окружения

Создайте каталог (например, cert) и перейдите в него. Создайте в нем пустой файл certindex.txt Выполните команды:

В этом каталоге создаем файл конфигурации openssl.conf следующего содержимого:

Создание сертификата сертифицирующей организации

При запросе пароля указывайте пароль не менее 4 символов. На все остальные запросы можно нажать Enter.

Создание пользовательского сертификата

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

Теперь для каждого пользователя создаем сертификат PKCS12. Выполняйте по одной команде:

При запросе пароля указывайте пароль, заданный при создании сертификата CA. На все остальные запросы можно нажать Enter.

Готовый файл: user-cert.p12

Этот файл можно импортировать в Firefox или Thunderbird, а потом использовать в OpenOffice.org.

Преобразование сертификата в формат PKCS#12

Предположим, что нам необходимо создать файл cert.p12. Допустим, что у нас имеются файлы с закрытым ключом prkey.pem и файл с сертификатом cert.pem. Выполнить это можно с помощью команды openssl pkcs12:

Создание списка недействительных сертификатов

По истечении определенного срока сертификат становится недействительным. Если это сертификат сотрудника, то, например, после его увольнения сертификат необходимо считать недействительным. Если секретный ключ сертификата стал достоянием общественности по каким-либо причинам, то его тоже необходимо внести в список недействительных сертификатов (CRL). Для управления CRL можно воспользоваться командой openssl ca.

Добавление ненужных сертификатов осуществляется с помощью команды:

После каждого применения revoke необходимо обновлять CRL командой

Больше информации можно узнать в мануале, использовав в терминале Linux команду man pkcs12 или по ссылке pkcs12(1).

Библиотека JSSE

Провайдер SunJSSE предоставляет полную реализацию java.security.KeyStore формата PKCS#12 для чтения и записи файлов pkcs12. Этот формат также поддерживается другими инструментами и приложениями для импорта и экспорта ключей и сертификатов, такими как Netscape/Mozilla, Microsoft Internet Explorer и OpenSSL. Например, эти реализации могут экспортировать сертификаты и ключи клиента в файл с расширением «.p12».

На всякий случай, нужно иметь в виду, что в Java 6 JDK одни и те же классы поддержки хранилища PKCS#12 содержатся не только внутри JSSE, но и отдельно в пакете sun.security.pkcs12.

Реализация хранилища PKCS#12 в LirJSSE дополнительно поддерживает алгоритмы ГОСТ. Далее описываются особенности этой реализации.

Особенности реализации PKCS#12 в LirJSSE

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

Цепочки сертификатов связываются с секретными ключами внутри хранилища по локальным идентификаторам. Локальный идентификатор – это массив байтов в формате UTF-8, образованный при добавлении нового ключа из строки “Time “, за которой следует текстовое представление даты и времени добавления элемента. При добавлении нового ключа всегда задаются также соответствующая цепочка сертификатов и пароль.

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

В хранилище не могут одновременно содержаться ключи ГОСТ и не ГОСТ. Соответствующий внутренний тип хранилища устанавливается либо при его загрузке, либо при добавлении первого ключа. Если хранилище пустое, то тип его в этом смысле не определен.

Алиас ключевого элемента, вообще говоря, не обязателен. Если в хранилище оказался элемент без алиаса, то алиас ему назначается принудительно в виде внутреннего порядкового номера. Дело в том, что LirJSSE, как и Sun JSSE, работает с элементами хранилищ только по алиасам.

При создании элементов хранилища различными программами может несколько отличаться внутренняя структура хранения зашифрованных элементов. Из-за этого, например, одна и та же цепочка сертификатов может упаковаться в файле хранилища средствами LirSSL и LirJSSE в структуры разного размера. Стандарт это допускает, и на функциональность хранилища это не влияет.

При работе с JSSE не нужно забывать, что пароли ключевых элементов должны совпадать с паролем хранилища. Стандарт PKCS#12, вообще говоря, допускает использование различных паролей в одном хранилище, но SunJSSE и LirJSSE не поддерживают данную возможность.

По договоренности с фирмой Топ Кросс, пароль всего хранилища перед применением преобразуется в программе LirJSSE в формат UTF-16 (последние два байта – нулевые). А отдельные элементы хранилища защищаются тем же паролем, но в формате UTF-8.

Схема работы агентства по выдачи персональных сертификатов

Использование

Такие сертификаты используются в качестве ключей на защищенных веб-страницах и в электронной подписи OpenOffice.org.

Также PKCS#12-файлы используются в многих браузерах и почтовых агентах, таких как Netscape Navigator, MSIE, MS Outlook.

Также PKCS#12 используется в MatrixSSL, начиная с версии 3.3.2.

Источник

Как устроены хранилища данных: обзор для новичков

Международный рынок гипермасштабируемых дата-центров растет с ежегодными темпами в 11%. Основные «драйверы» — предприятия, подключенные устройства и пользователи — они обеспечивают постоянное появление новых данных. Вместе с объемом рынка растут и требования к надежности хранения и уровню доступности данных.

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

Типы хранилищ и их различия

Хранение на уровне блоков лежит в основе работы традиционного жесткого диска или магнитной ленты. Файлы разбиваются на «кусочки» одинакового размера, каждый с собственным адресом, но без метаданных. Пример — ситуация, когда драйвер HDD пишет и считывает блоки по адресам на отформатированном диске. Такие СХД используются многими приложениями, например, большинством реляционных СУБД, в списке которых Oracle, DB2 и др. В сетях доступ к блочным хостам организуется за счет SAN с помощью протоколов Fibre Channel, iSCSI или AoE.

Файловая система — это промежуточное звено между блочной системой хранения и вводом-выводом приложений. Наиболее распространенным примером хранилища файлового типа является NAS. Здесь, данные хранятся как файлы и папки, собранные в иерархическую структуру, и доступны через клиентские интерфейсы по имени, названию каталога и др.

При этом следует отметить, что разделение «SAN — это только сетевые диски, а NAS — сетевая файловая система» искусственно. Когда появился протокол iSCSI, граница между ними начала размываться. Например, в начале нулевых компания NetApp стала предоставлять iSCSI на своих NAS, а EMC — «ставить» NAS-шлюзы на SAN-массивы. Это делалось для повышения удобства использования систем.

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

Марк Горос (Mark Goros), генеральный директор и соучредитель Carnigo, сравнивает такой способ организации со службой парковки, предполагающей выдачу автомобиля. Вы просто оставляете свою машину парковщику, который увозит её на стояночное место. Когда вы приходите забирать транспорт, то просто показываете талон — вам возвращают автомобиль. Вы не знаете, на каком парковочном месте он стоял.

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

/ 1cloud

Применимость систем хранения разных типов

Блочные хранилища

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

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

Файловые хранилища

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

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

Объектные хранилища

Что касается объектных хранилищ, то они хорошо масштабируются, поэтому способны работать с петабайтами информации. По статистике, объем неструктурированных данных во всем мире достигнет 44 зеттабайт к 2020 году — это в 10 раз больше, чем было в 2013. Объектные хранилища, благодаря своей возможности работать с растущими объемами данных, стали стандартом для большинства из самых популярных сервисов в облаке: от Facebook до DropBox.

Такие хранилища, как Haystack Facebook, ежедневно пополняются 350 млн фотографий и хранят 240 млрд медиафайлов. Общий объем этих данных оценивается в 357 петабайт.

Хранение копий данных — это другая функция, с которой хорошо справляются объектные хранилища. По данным исследований, 70% информации лежит в архиве и редко изменяется. Например, такой информацией могут выступать резервные копии системы, необходимые для аварийного восстановления.

Но недостаточно просто хранить неструктурированные данные, иногда их нужно интерпретировать и организовывать. Файловые системы имеют ограничения в этом плане: управление метаданными, иерархией, резервным копированием — все это становится препятствием. Объектные хранилища оснащены внутренними механизмами для проверки корректности файлов и другими функциями, обеспечивающими доступность данных.

Плоское адресное пространство также выступает преимуществом объектных хранилищ — данные, расположенные на локальном или облачном сервере, извлекаются одинаково просто. Поэтому такие хранилища часто применяются для работы с Big Data и медиа. Например, их используют Netflix и Spotify. Кстати, возможности объектного хранилища сейчас доступны и в сервисе 1cloud.

Благодаря встроенным инструментам защиты данных с помощью объектного хранилища можно создать надежный географически распределенный резервный центр. Его API основан на HTTP, поэтому к нему можно получить доступ, например, через браузер или cURL. Чтобы отправить файл в хранилище объектов из браузера, можно прописать следующее:

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

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

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

Источник

Файловые системы хранения данных

Если сделать поиск по изображениям, то на запрос «file storage» одной из первых выдается примерно такая картинка:

Система хранения файлов (в смысле, папок)

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

Виды хранения данных

Существуют три способа хранения данных: блочный, файловый и объектный. Они организуют и предоставляют данные различными способами, каждый из которых имеет свои возможности и ограничения.

Блочное хранилище разбивает данные на блоки (chunks) одинакового размера, организованные по-разному, то есть, разные блоки могут храниться в разных массивах данных.

Файловое хранилище организует и предоставляет данные в виде иерархии файлов в папках.

Объектное хранилище управляет данными при помощи т.н. «метаданных» – коротких информационных «наклеек» на целостном массиве данных (текстовый документ, видеоролик, электронная таблица и пр.), по которому его можно довольно легко найти в общем хранилище.

Что такое файловая система хранения

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

Доступ к данным в файловом хранилище осуществляется по file ID, который содержит имя сервера, путь к директории (папке) и имя искомого файла (server name + directory path + filename) в сети общего пользования NAS (Network Attached Storage). По file ID сервер системы хранения находит данные на диске в NAS.

Протоколы

Наиболее употребительными протоколами доступа к файлам через NAS являются NFS (Network File System) и CIFS (Common Internet File System).

NFS используется в операционных системах Unix и Linux. CIFS используется в операционной системе Windows и является публичным (открытым) вариантом более специализированного протокола SMB (Server Message Block), разработанного компанией Microsoft, который использует сетевой протокол TCP/IP.

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

Ограничения

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

Организация файловых систем хранения

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

В директории может храниться следующая информация:

Уровни директорий

Одноуровневые директории

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

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

Двухуровневые директории

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

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

Древообразная модель директорий

В такой модели директории могут быть организованы в виде дерева.

Древообразная модель директорий

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

Непрерывное размещение

При непрерывном размещении (Continuous Allocation) файла в момент его создания выделяется набор последовательных блоков. В таблице размещения файлов (file allocation table) нужно указать только номер начального блока и длину файла. Этот метод лучше всего подходит для последовательного размещения отдельных файлов в пустом хранилище.

Непрерывное размещение файлов

Преимущества: при таком размещении можно сразу прочитать несколько блоков, что обеспечивает высокую скорость ввода-вывода. Легко также получать доступ к отдельным блокам. Например, если файл начинается на блоке b, и нам нужен блок i, то его положение в хранилище вычисляется просто как b + i – 1.

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

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

Цепочное размещение

При цепочном размещении (Linked Allocation), еще его называют Non-contiguous allocation, размещение производится поблочно. При этом не требуется, чтобы блоки в файле были последовательными по номерам. Каждый блок при этом будет содержать указатель на следующий блок цепочки, в котором продолжается файл.

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

Недостатки: последние блоки файлов могут быть не полностью занятыми. Требуется дополнительная информация (overhead) на управление указателем на следующий блок в каждом предыдущем блоке. Если указатель теряется, то файл может быть разорван и станет недоступным.

Индексированное размещение

Индексированное размещение (Indexed Allocation) призвано решить проблемы непрерывного и цепочного размещения. В этом случае таблица размещения файлов содержит отдельный одноуровневый указатель (индекс) для каждого файла. В индексе последовательно указаны номера блоков, в которых размещен файл. При этом блоки могут иметь как одинаковый размер, так и различные размеры. При этом исключается фрагментация файлов, в то время как размещение при помощи блоков различного размера исключает незанятые «хвосты» в последнем блоке каждого файла, если файл не умещается в определенное число блоков. Этот метод размещения файлов обеспечивает как последовательный, так и прямой доступ к файлам и в настоящее время является наиболее популярным.

Индексированное размещение файлов

Управление свободным пространством диска

Свободным пространством диска, как и занятым, тоже нужно управлять. Для эффективного размещения файлов во всех перечисленных выше методах требуется знать, какие блоки на диске доступны, а какие – заняты. Поэтому необходимо иметь также таблицы размещения дисков (disk allocation table), как и таблицу размещения файлов (file allocation table).

Имеются следующие методы управления свободным пространством диска.

Битовые таблицы (Bit Tables). В этом методе используется вектор, который содержит по одному биту для каждого блока на диске. Если бит равен 0, то это блок свободен, если 1, то занят.

Такой вектор может иметь вид: 00011010111100110001

Список свободный блоков (Free Block List). В этом методе каждому блоку назначается последовательный номер и список номеров свободных блоков сохраняется на специально выделенном блоке на каждом диске.

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

Достоинства и недостатки

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

Система достаточно легко масштабируется (до определенных пределов). Совместный доступ пользователей внутри масштабов системы практически ничем не ограничен. К достоинствам также можно отнести относительно невысокую цену.

Файлы в файловой системе ищутся достаточно быстро, если ее масштаб не запределен. Система имен файлов позволяет разным собственникам иметь файлы с одинаковым именем – с точки зрения системы это будут разные файлы – даже в том случае, если содержимое файлов с разными Owner ID будет одинаковым.

Файлы удобно группировать по типам: например, все программы, написанные на языке Java, все игровые файлы и пр.

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

Бизнес-задачи

Файловая система хранения хорошо подходит для доступа к общим файлам и каталогам через локальную компьютерную сеть предприятия LAN (local area network) или WAN (wide area network). Поэтому практически во всех корпоративных ИТ-системах в том или ином виде можно обнаружить примеры эксплуатации файловых хранилищ:

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

Обзор продуктов NAS

Системы хранения Synology RS

Synology FlashStation FS6400 – это стоечный сервер 2U, предназначенный для чувствительных к задержкам задач с высокой интенсивностью операций ввода-вывода. Он хорошо подходит для постобработки мультимедийных файлов, развертывания виртуальных машин, обработки онлайн-транзакций и приложений баз данных.

Synology FlashStation FS6400 (источник: Synology)

Подходит для:

Synology SA3200D позволяет упростить и централизовать инфраструктуру управления данными в форм-факторе 2U. Избыточность контроллеров хранилища на базе Synology High Availability автоматически сокращает время простоя менее, чем до 1 минуты.

Благодаря архитектуре с двумя контроллерами Synology SA3200D обеспечивается выполнение операций и основных бизнес-функций в случае аварий или незапланированных ситуаций, приводящих к отключению критически важных систем. Аппаратная избыточность контроллеров, источников питания и вентиляторов устраняет возможность сбоев в работе. SA3200D работает на базе интуитивно понятной и многофункциональной операционной системы DiskStation Manager (DSM), которая обеспечивает комплексную защиту сети, файловых служб и приложений.

Synology SA3200D (источник: Synology).

Synology SA3200D – сертифицированное решение по виртуализации с поддержкой VMware® vSphere™, Microsoft® Hyper-V®, Citrix® XenServer™ и OpenStack Cinder. Система поддерживает протоколы iSCSI и NFS и интегрируется с VMware VAAI и Microsoft ODX.

Это позволяет ИТ-администраторам эффективно выполнять развертывание и упрощает операции хранения в различных средах виртуализации. ИТ-администраторы могут эффективно управлять виртуализированными рабочими нагрузками с помощью встроенных функций DSM и подключаемых плагинов для сред VMware и Windows. Такие функции, как быстрое клонирование, NFS v4.1 и Thin Provisioning, обеспечивают большую гибкость для удовлетворения потребностей администрирования.

Без дополнительных лицензионных платежей виртуализированная рабочая нагрузка может быть дополнительно защищена полноценным набором приложений для защиты данных, включая Synology Snapshot Replication, Hyper Backup и Active Backup for Business (в соответствии со сценарием защиты).

Система хранения Synology RackStation RS820+/RS820RP+ – это сетевая СХД для централизованного управления данными. Устройство RS820+/RS820RP+ оснащено четырехъядерным процессором и обеспечивает высокую производительность и масштабируемость хранилища, что хорошо подходит для совместного использования файлов на различных платформах и для резервного копирования данных. На Synology RS820+/RS820RP+ распространяется 3-летняя ограниченная гарантия компании Synology.

Synology RackStation RS820+/RS820RP+ (источник: Synology).

Synology RackStation RS819 – это стоечная сетевая система хранения для рабочих групп в форм-факторе 1U с 4 отсеками. Система хранения с шасси глубиной 12 дюймов для установки в двухопорную стойку обеспечивает высокую гибкость при развертывании серверов. RS819 с 64-разрядным четырехъядерным процессором, памятью DDR4 емкостью 2 ГБ и двумя портами Gigabit LAN обеспечивает пропускную способность последовательного чтения и записи более 225 МБ/с и 169 МБ/с соответственно. RS819 также обеспечивает масштабируемость хранилища до 8 дисков при подключении к одному модулю расширения Synology RX4182.

Synology RackStation RS819 (источник: Synology).

Унифицированный контроллер UC3200 для высокодоступных сред SAN поддерживает архитектуру «активный-активный» для обеспечения непрерывной работы служб iSCSI. Решение обеспечивает надежную защиту данных, обладает простым интерфейсом управления и максимально увеличивает время бесперебойной работы критически важных служб. На UC3200 предоставляется 5-летняя ограниченная гарантия Synology.

Унифицированный контроллер UC3200 (источник: Synology).

UC3200 – это экономичное и надежное решение IP SAN для критически важных сред. Корпус 2U оснащен узлами контроллера «активный-активный» (на базе 4-ядерного процессора Intel® Xeon® D-1521) и памятью DDR4 ECC UDIMM емкостью 8 ГБ (с возможностью увеличения до 64 ГБ). Система обеспечивает производительность свыше 140 000 операций ввода-вывода в секунду при произвольной записи блоками по 4 КБ.

UC3200 позволяет начать с минимальной конфигурации и расширять систему в будущем. По умолчанию сервер вмещает 12 слотов для 3,5-дюймовых или 2,5-дюймовых дисков SAS с возможностью масштабирования до 36 дисков SAS при подключении двух модулей расширения RXD1219sas. Порты RJ-45 – один порт 10GbE и два порта 1GbE (на каждом контроллере) и поддержка установки сетевой карты 10GbE/25GbE благодаря разъему PCIe 3.0 позволяют увеличить пропускную способность сети с помощью Link Aggregation.

Dell EMC NX

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

Система хранения Dell EMC NX3340. Сетевая система хранения данных (NAS) с технологией Cluster Ready, обеспечивающая эффективное развертывание и интеграцию с высокой доступностью для простого управления данными.

Система хранения Dell EMC NX440. Сетевая система хранения данных (NAS) с автоматической настройкой и управлением для эффективного обмена данными.

Конструктив серии Dell EMC NX (источник: Dell EMC).

ПО Dell OpenManage™ с консолью Dell Management Console, iDRAC8 или iDRAC9 Enterprise, встроенным подключаемым модулем Java RDP или интерфейсом управления Windows Server

Функции управления данными в СХД Dell EMC

Дедупликация данных со сжатием, FCI (инфраструктура классификации файлов), FSRM (диспетчер ресурсов файлового сервера).

Серия сетевых файловых хранилищ NAS Dell EMC Storage NX – это решение для малых и средних компаний, удаленных филиалов и офисов, нуждающихся в общем доступе к файлам. Серия базируется на процессорах Intel Xeon, поэтому обеспечивает высокий уровень быстродействия при работе с любыми требовательными нагрузками. Хранилища серии легко адаптируются к различным нагрузкам и обеспечивают низкую совокупную стоимость хранения ТСО.

Серия Dell Storage NX способна повысить эффективность использования емкости сетевой системы хранения данных (NAS) и оптимизировать дисковое пространство с помощью следующих встроенных функций:

NX3340 используется в качестве шлюза NAS к дополнительным массивам сетей хранения данных для масштабного внешнего расширения. Поддержка кластеризации (до 64 узлов) с использованием томов Clustered Shared Volumes (CSV) при подключении к массивам хранения PowerVault MD3, EqualLogic или Dell Compellent.

Источник