Система хранения файлов и организации каталогов: Организация хранения личных файлов локально и в облаках / Хабр

Организация хранения личных файлов локально и в облаках / Хабр

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

Найти

1. Единую структуру папок для хранения и «обозрения» всех файлов.
2. Способ реализации такой единой структуры с использованием преимуществ всех облачных хранилищ.

Дано

1. Со временем мы накапливаем все больший объем информации (большая часть которого по-прежнему хранится в файлах). Эти файлы требуют организованного хранения и управления.
2. Сейчас широко распространено не менее 5 основных облачных хранилищ (причем каждое обладает своими преимуществами):
   — Google Drive — интеграция со всеми сервисами Google, распространено среди коллег (людей, с которыми часто приходится обмениваться информацией), удобный облачный офис;
   — DropBox — распространено среди коллег;
   — SkyDrive — распространено среди коллег, удобный облачный офис для работы с документами MS Office;
   — Яндекс.Диск — (UPD) подарили навсегда 200 Гб за ошибку в одной из версий десктопного клиента, подарили 2 Гб на 2014 год;
   — Облако.Mail.ru — подарили 1 Тб навсегда.
3. Файлы единой организованной структуры не могут быть размещены в одном облаке под двум причинам:
   — бесплатные объемы недостаточны, и чем больше бесплатный объем тем беднее функционал и качество работы сервиса,
   — предпочтения коллег также накладывают серьезные ограничения (по одному проекту могут быть одновременно файлы совместно редактируемые на Google Drive и SkyDrive, общие папки на DropBox).
4. Операционные системы
   — десктоп: Windows 8.1,
   — смартфон и планшет: Android 4.4.
5. Имею несколько мест работы, готовлюсь к поступлению в аспирантуру, файловый архив “коплю” уже около 15 лет, то есть информации, с которой приходится работать, достаточно много.
6. Это вопрос, который так или иначе вынуждены решать для себя все, и все явно чувствуют несовершенство получаемых решений. В большой степени статья вдохновлена нижеследующими тщетными поисками:
   — habrahabr.ru/post/68092
   — habrahabr.ru/post/90326
7. Сложность, трудоемкость, необходимость высокой квалификации не приветствуются.

Вариант решения

Файловая структура

Мне кажется, для организации хранения файлов уместна следующая классификация данных (файлов).

1. Хранить вечно, доступ в будущем не предполагается. Эта категория данных, которую я называю “архивом”. Туда попадают документы “для истории”, которые в обозримом будущем нужны не будут, но когда-нибудь будут представлять “историческую ценность”.
2. Хранить вечно, доступ в будущем очень вероятен. Это данные, относящиеся к категории постоянного (перманентного) хранения, доступ к таким данным периодически необходим. Это могут быть книги, музыка, дистрибутивы, сканы личных документов (паспорт, ИНН, прочее) и что угодно еще.
3. Срок хранения не определен, доступ в будущем необходим. Это категория файлов проектов и “входящих” (в терминах GTD). Файлы разделены по папкам, каждая из которых соответствует одному проекту (в терминах GTD), и конечно отдельная папка для “входящих”.

Такое разделение данных позволяет четко понимать, что необходимо “старательно” бэкапить и что, в случае отсутствия потерь данных, будет доступно мне в любой момент в будущем.

Также важно, чтобы данное разделение данных было реализовано на одном уровне папок (без вложений), зачем это нужно — будет понятно из следующего раздела.

Структура каталогов, к которой я пришел, выглядит так (назовем ее базовой структурой каталогов):

\
|-archive (архив)
|-permanent_books (доступ в будущем будет нужен)
|-permanent_music
|-permanent_pics
|-permanent_scans
|-permanent_soft
|-permanent_video
|-project_pr1 (файлы проекта)
|-project_pr2
|-project_pr3
|-project_pr4
|-project_pr5
|-project_pr6
|-temp (“входящие”)
 

Использование облачных хранилищ

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

Для удобства представления данных на компьютере базовую структуру каталогов (не обязательно полностью, по необходимости) предлагается реализовать на уровне библиотек Windows (про библиотеки можно почитать здесь: www.outsidethebox.ms/15096). Именно для этого базовая структура папок должна быть одноуровневой. Библиотеки отображают файлы, расположенные в нескольких папках на диске, и позволяют удобно управлять ими. Кроме того полезно создать библиотеку “Облака”, отображающую содержимое корневых папок всех используемых облачных хранилищ (в этой библиотеке будет несколько папок с одним именем — по одной из каждого облачного хранилища).

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

• “Общие элементы”. Все содержимое папок библиотеки выводится в единой таблице, без группировки по папке библиотеки (в нашем случае по облачному хранилищу).
• “Видео”. Содержимое библиотеки разбито по папкам библиотеки (облачным хранилищам), и представлено в виде крупных значков.

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

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

Кстати, не все файлы нужно хранить на диске (объем доступного пространства в облачных хранилищах как правило больше объема физического диска). Например, папки “permanent_video” и “permanent_music” я вообще не синхронизирую с компьютером, а обмен с этими папками осуществляю через папку “temp” соответствующего облачного хранилища. Посмотрев какое-то видео, если я хочу сохранить его в облаке, я перемещаю его в папку “temp”, а затем через веб-интерфейс облака перемещаю файл в папку “permanent_video” — файл удаляется с диска компьютера, но сохраняется в облаке.

И еще одна небольшая “фишка”. Расположение папки “Рабочий стол” я перенастроил на папку “temp” в моем основном облаке (Google Drive), в эту же папку по умолчанию сохраняются все файлы, скачиваемые через браузер и торрент-клиент. Таким образом все новые файлы автоматически оказываются в одном единственном месте и сразу же попадают в облако.

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

обзор для новичков / Блог компании 1cloud.ru / Хабр

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

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

/ Flickr / Jason Baker / CC

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

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

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

/ Wikimedia / Mennis / CC

При этом следует отметить, что разделение «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. Чтобы отправить файл в хранилище объектов из браузера, можно прописать следующее:

<form action  = "[url_storage/account/container/object]"
      method  = "post"
      enctype = "multipart/form-data">
      <input type="hidden" name="redirect"  value="[url_result]">
      <input type="hidden" name="signature" value="[hmac]">
      <input type="file"   name="file_name">
      <input type="submit">
</form>

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

curl -i [url_storage/account/container/object] -X POST 
-H "X-Auth-Token: [token]" -H "X-Object-Meta-ValueA: [value-a]"

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

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

P.S. Еще несколько материалов о хранении данных из блога 1cloud:

Система хранения файлов на компьютере

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

Что такое локальный диск

Все данные на компьютере хранятся на его внутреннем запоминающем устройстве, которое может состоять из одного или нескольких разделов, называемых логическими разделами или локальными дисками. Локальные диски обозначаются латинскими буквами (C, D, E, F и др.). На каждом таком диске находятся файлы (текстовые документы, фотографии, видео, музыка, программы и др.), которые, как правило, располагаются там не хаотично, а в систематизированном виде. Для систематизации пользователь может «раскладывать» файлы в папки, которые в свою очередь могут помещаться в другие папки (папки более высокого уровня) и т.д. Больше о файлах и папках можно узнать из нашей статьи «Файлы и папки». Таким образом, пользователь создает на своем компьютере четкую, многоуровневую и удобную для себя систему хранения файлов, в которой он всегда может отыскать все необходимое.Например, запоминающее устройство компьютера может состоять из нескольких локальных дисков (логических разделов). В любом из них пользователь может создать папки с названиями «Книги», «Документы», «Фотографии», «Фильмы», «Музыка» и т.д. В каждой из этих папок можно сделать дополнительные папки. Например, в папке «Музыка» создать папки «Рок», «Шансон», «Поп» и др. В каждой такой папке можно хранить файлы или другие папки.

Схематично систему хранения файлов на компьютере можно изобразить так:

В описанной выше системе хранения данных у каждого файла или папки есть своеобразный «адрес». Например, «адрес» папки может выглядеть так: H://Музыка/Рок/Ария. Это значит, что папка с названием «Ария» находится в папке «Рок», которая в свою очередь находится в папке «Музыка», которая лежит в логическом разделе «H» компьютера. Адрес файла (папки) чаще называют путем к файлу (папке). На каждом конкретном компьютере система хранения файлов всегда уникальна, поскольку каждый пользователь создает на запоминающем устройстве собственную структуру папок в зависимости от своих потребностей и предпочтений. Это не касается некоторых системных папок, которые есть на каждом компьютере. Эти папки на всех компьютерах имеют одинаковые названия и расположены всегда по одному и тому же пути. В них содержатся файлы операционной системы и важных программ. Вносить какие-либо изменения в эти папки можно только тогда, когда вы уверены в правильности своих действий. Иначе компьютер может прийти в нерабочее состояние. Вот список этих папок. Запомните их и никогда ничего не изменяйте в них без необходимости: • C://Windows • C://Program Files • C://Documents and Settings.

Перемещение по файловой системе компьютера

Если вам не известен точный путь к искомой на компьютере папке или файлу, лучше воспользоваться поиском. Если же путь известен, самый простой способ «добраться» до папки или файла — пройти по пути его расположения. Например, чтобы открыть папку H://Музыка/Рок/Ария, необходимо открыть сначала локальный диск H, затем открыть находящуюся на нем папку «Музыка», в папке «Музыка» открыть папку «Рок», и уже в ней перейти в папку «Ария».Как это сделать: 1. Открываем раздел с названием «Компьютер» или «Мой компьютер». Для этого необходимо найти на рабочем столе значок с названием «Компьютер» («Мой компьютер»), навести на него указатель мышки (см. изображение справа) и дважды нажать левую кнопку мышки (с максимально коротким перерывом между нажатиями). Напомню, что рабочий стол – это пространство экрана компьютера, когда все программы или окна Windows закрыты либо свернуты. Если на рабочем столе компьютера такого значка нет, его можно найти в меню «Пуск». Для входа в это меню предназначена кнопка, находящаяся в левом нижнем углу экрана. Она может быть прямоугольной с надписью «Пуск» или же в виде круглой эмблемы Windows (см. на изображении справа). На эту кнопку необходимо навести указатель мышки, и нажать левую кнопку мышки. Открыть меню «Пуск» можно другим способом – нажать на клавиатуре кнопку Win. Эта кнопка чаще всего вместо надписи отмечена эмблемой Windows. Находится она в левом ближнем углу клавиатуры, между кнопками Ctrl и Alt.

2. В открытом разделе «Компьютер» отображается список всех локальных дисков и некоторых других устройств компьютера (см. изображение ниже). Чтобы открыть любой из локальных дисков (в нашем случае Локальный диск H) необходимо навести на него указатель мышки и дважды, с минимальным интервалом, нажать левую кнопку мышки.

В открытом локальном диске аналогичным образом (двойным кликом левой кнопки мышки) можно открыть любую папку (в нашем случае папка «Музыка»). В этой папке таким же способом можно открыть другую папку, и так, пока не доберетесь до целевой папки.

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

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

Есть несколько способов сделать навигацию более удобной, среди которых наиболее простыми являются:

1. Использование ярлыков. Подробнее о том, что такое ярлык, читайте в нашей статье «Ярлык и как его создать»;

2. Использование Проводника Windows.

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

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

• навести указатель мышки на значок «Мой компьютер» (о нем речь шла выше), значок логического раздела или любой папки, которую нужно открыть; • нажать правую кнопку мышки; • в открывшемся контекстном меню навести указатель мышки на пункт «проводник» и нажать левую кнопку мышки.

Файловая система NTFS

Операционные системы Microsoft семейства Windows NT нельзя представить без файловой системы NTFS — одной из самых сложных и удачных из существующих на данный момент файловых систем. Данная статья расскажет вам, в чем особенности и недостатки этой системы, на каких принципах основана организация информации, и как поддерживать систему в стабильном состоянии, какие возможности предлагает NTFS и как их можно использовать обычному пользователю.

Часть 1. Физическая структура NTFS

Начнем с общих фактов. Раздел NTFS, теоретически, может быть почти какого угодно размера. Предел, конечно, есть, но я даже не буду указывать его, так как его с запасом хватит на последующие сто лет развития вычислительной техники — при любых темпах роста. Как обстоит с этим дело на практике? Почти так же. Максимальный размер раздела NTFS в данный момент ограничен лишь размерами жестких дисков. NT4, правда, будет испытывать проблемы при попытке установки на раздел, если хоть какая-нибудь его часть отступает более чем на 8 Гб от физического начала диска, но эта проблема касается лишь загрузочного раздела.

Лирическое отступление. Метод инсталляции NT4.0 на пустой диск довольно оригинален и может навести на неправильные мысли о возможностях NTFS. Если вы укажете программе установки, что желаете отформатировать диск в NTFS, максимальный размер, который она вам предложит, будет всего 4 Гб. Почему так мало, если размер раздела NTFS на самом деле практически неограничен? Дело в том, что установочная секция просто не знает этой файловой системы 🙂 Программа установки форматирует этот диск в обычный FAT, максимальный размер которого в NT составляет 4 Гбайт (с использованием не совсем стандартного огромного кластера 64 Кбайта), и на этот FAT устанавливает NT. А вот уже в процессе первой загрузки самой операционной системы (еще в установочной фазе) производится быстрое преобразование раздела в NTFS; так что пользователь ничего и не замечает, кроме странного «ограничения» на размер NTFS при установке. 🙂

Структура раздела — общий взгляд

Как и любая другая система, NTFS делит все полезное место на кластеры — блоки данных, используемые единовременно. NTFS поддерживает почти любые размеры кластеров — от 512 байт до 64 Кбайт, неким стандартом же считается кластер размером 4 Кбайт. Никаких аномалий кластерной структуры NTFS не имеет, поэтому на эту, в общем-то, довольно банальную тему, сказать особо нечего.

Диск NTFS условно делится на две части. Первые 12% диска отводятся под так называемую MFT зону — пространство, в которое растет метафайл MFT (об этом ниже). Запись каких-либо данных в эту область невозможна. MFT-зона всегда держится пустой — это делается для того, чтобы самый главный, служебный файл (MFT) не фрагментировался при своем росте. Остальные 88% диска представляют собой обычное пространство для хранения файлов.

Свободное место диска, однако, включает в себя всё физически свободное место — незаполненные куски MFT-зоны туда тоже включаются. Механизм использования MFT-зоны таков: когда файлы уже нельзя записывать в обычное пространство, MFT-зона просто сокращается (в текущих версиях операционных систем ровно в два раза), освобождая таким образом место для записи файлов. При освобождении места в обычной области MFT зона может снова расширится. При этом не исключена ситуация, когда в этой зоне остались и обычные файлы: никакой аномалии тут нет. Что ж, система старалась оставить её свободной, но ничего не получилось. Жизнь продолжается… Метафайл MFT все-таки может фрагментироваться, хоть это и было бы нежелательно.

MFT и его структура

Файловая система NTFS представляет собой выдающееся достижение структуризации: каждый элемент системы представляет собой файл — даже служебная информация. Самый главный файл на NTFS называется MFT, или Master File Table — общая таблица файлов. Именно он размещается в MFT зоне и представляет собой централизованный каталог всех остальных файлов диска, и, как не парадоксально, себя самого. MFT поделен на записи фиксированного размера (обычно 1 Кбайт), и каждая запись соответствует какому либо файлу (в общем смысле этого слова). Первые 16 файлов носят служебный характер и недоступны операционной системе — они называются метафайлами, причем самый первый метафайл — сам MFT. Эти первые 16 элементов MFT — единственная часть диска, имеющая фиксированное положение. Интересно, что вторая копия первых трех записей, для надежности — они очень важны — хранится ровно посередине диска. Остальной MFT-файл может располагаться, как и любой другой файл, в произвольных местах диска — восстановить его положение можно с помощью его самого, «зацепившись» за самую основу — за первый элемент MFT.

Метафайлы

Первые 16 файлов NTFS (метафайлы) носят служебный характер. Каждый из них отвечает за какой-либо аспект работы системы. Преимущество настолько модульного подхода заключается в поразительной гибкости — например, на FAT-е физическое повреждение в самой области FAT фатально для функционирования всего диска, а NTFS может сместить, даже фрагментировать по диску, все свои служебные области, обойдя любые неисправности поверхности — кроме первых 16 элементов MFT.

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

$MFT	сам MFT
$MFTmirr	копия первых 16 записей MFT, размещенная посередине диска
$LogFile	файл поддержки журналирования (см. ниже)
$Volume	служебная информация — метка тома, версия файловой системы, т. д.
$AttrDef	список стандартных атрибутов файлов на томе
$.	корневой каталог
$Bitmap	карта свободного места тома
$Boot	загрузочный сектор (если раздел загрузочный)
$Quota	файл, в котором записаны права пользователей на использование дискового пространства (начал работать лишь в NT5)
$Upcase	файл — таблица соответствия заглавных и прописных букв в имен файлов на текущем томе. Нужен в основном потому, что в NTFS имена файлов записываются в Unicode, что составляет 65 тысяч различных символов, искать большие и малые эквиваленты которых очень нетривиально.

Файлы и потоки

Итак, у системы есть файлы — и ничего кроме файлов. Что включает в себя это понятие на NTFS?

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

Довольно интересно обстоит дело и с данными файла. Каждый файл на NTFS, в общем-то, имеет несколько абстрактное строение — у него нет как таковых данных, а есть потоки (streams). Один из потоков и носит привычный нам смысл — данные файла. Но большинство атрибутов файла — тоже потоки! Таким образом, получается, что базовая сущность у файла только одна — номер в MFT, а всё остальное опционально. Данная абстракция может использоваться для создания довольно удобных вещей — например, файлу можно «прилепить» еще один поток, записав в него любые данные — например, информацию об авторе и содержании файла, как это сделано в Windows 2000 (самая правая закладка в свойствах файла, просматриваемых из проводника). Интересно, что эти дополнительные потоки не видны стандартными средствами: наблюдаемый размер файла — это лишь размер основного потока, который содержит традиционные данные. Можно, к примеру, иметь файл нулевой длинны, при стирании которого освободится 1 Гбайт свободного места — просто потому, что какая-нибудь хитрая программа или технология прилепила в нему дополнительный поток (альтернативные данные) гигабайтового размера. Но на самом деле в текущий момент потоки практически не используются, так что опасаться подобных ситуаций не следует, хотя гипотетически они возможны. Просто имейте в виду, что файл на NTFS — это более глубокое и глобальное понятие, чем можно себе вообразить просто просматривая каталоги диска. Ну и напоследок: имя файла может содержать любые символы, включая полый набор национальных алфавитов, так как данные представлены в Unicode — 16-битном представлении, которое дает 65535 разных символов. Максимальная длина имени файла — 255 символов.

Каталоги

Каталог на NTFS представляет собой специфический файл, хранящий ссылки на другие файлы и каталоги, создавая иерархическое строение данных на диске. Файл каталога поделен на блоки, каждый из которых содержит имя файла, базовые атрибуты и ссылку на элемент MFT, который уже предоставляет полную информацию об элементе каталога. Внутренняя структура каталога представляет собой бинарное дерево. Вот что это означает: для поиска файла с данным именем в линейном каталоге, таком, например, как у FAT-а, операционной системе приходится просматривать все элементы каталога, пока она не найдет нужный. Бинарное же дерево располагает имена файлов таким образом, чтобы поиск файла осуществлялся более быстрым способом — с помощью получения двухзначных ответов на вопросы о положении файла. Вопрос, на который бинарное дерево способно дать ответ, таков: в какой группе, относительно данного элемента, находится искомое имя — выше или ниже? Мы начинаем с такого вопроса к среднему элементу, и каждый ответ сужает зону поиска в среднем в два раза. Файлы, скажем, просто отсортированы по алфавиту, и ответ на вопрос осуществляется очевидным способом — сравнением начальных букв. Область поиска, суженная в два раза, начинает исследоваться аналогичным образом, начиная опять же со среднего элемента.

Вывод — для поиска одного файла среди 1000, например, FAT придется осуществить в среднем 500 сравнений (наиболее вероятно, что файл будет найден на середине поиска), а системе на основе дерева — всего около 12-ти (2^10 = 1024). Экономия времени поиска налицо. Не стоит, однако думать, что в традиционных системах (FAT) всё так запущено: во-первых, поддержание списка файлов в виде бинарного дерева довольно трудоемко, а во-вторых — даже FAT в исполнении современной системы (Windows2000 или Windows98) использует сходную оптимизацию поиска. Это просто еще один факт в вашу копилку знаний. Хочется также развеять распространенное заблуждение (которое я сам разделял совсем еще недавно) о том, что добавлять файл в каталог в виде дерева труднее, чем в линейный каталог: это достаточно сравнимые по времени операции — дело в том, что для того, чтобы добавить файл в каталог, нужно сначала убедится, что файла с таким именем там еще нет 🙂 — и вот тут-то в линейной системе у нас будут трудности с поиском файла, описанные выше, которые с лихвой компенсируют саму простоту добавления файла в каталог.

Какую информацию можно получить, просто прочитав файл каталога? Ровно то, что выдает команда dir. Для выполнения простейшей навигации по диску не нужно лазить в MFT за каждым файлом, надо лишь читать самую общую информацию о файлах из файлов каталогов. Главный каталог диска — корневой — ничем не отличается об обычных каталогов, кроме специальной ссылки на него из начала метафайла MFT.

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

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

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

Пример 2: более сложный случай — идет запись данных на диск. Вдруг, бах — отключается питание и система перезагружается. На какой фазе остановилась запись, где есть данные, а где чушь? На помощь приходит другой механизм системы — журнал транзакций. Дело в том, что система, осознав свое желание писать на диск, пометила в метафайле $LogFile это свое состояние. При перезагрузке это файл изучается на предмет наличия незавершенных транзакций, которые были прерваны аварией и результат которых непредсказуем — все эти транзакции отменяются: место, в которое осуществлялась запись, помечается снова как свободное, индексы и элементы MFT приводятся в с состояние, в котором они были до сбоя, и система в целом остается стабильна. Ну а если ошибка произошла при записи в журнал? Тоже ничего страшного: транзакция либо еще и не начиналась (идет только попытка записать намерения её произвести), либо уже закончилась — то есть идет попытка записать, что транзакция на самом деле уже выполнена. В последнем случае при следующей загрузке система сама вполне разберется, что на самом деле всё и так записано корректно, и не обратит внимания на «незаконченную» транзакцию.

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

Сжатие

Файлы NTFS имеют один довольно полезный атрибут — «сжатый». Дело в том, что NTFS имеет встроенную поддержку сжатия дисков — то, для чего раньше приходилось использовать Stacker или DoubleSpace. Любой файл или каталог в индивидуальном порядке может хранится на диске в сжатом виде — этот процесс совершенно прозрачен для приложений. Сжатие файлов имеет очень высокую скорость и только одно большое отрицательное свойство — огромная виртуальная фрагментация сжатых файлов, которая, правда, никому особо не мешает. Сжатие осуществляется блоками по 16 кластеров и использует так называемые «виртуальные кластеры» — опять же предельно гибкое решение, позволяющее добиться интересных эффектов — например, половина файла может быть сжата, а половина — нет. Это достигается благодаря тому, что хранение информации о компрессированности определенных фрагментов очень похоже на обычную фрагментацию файлов: например, типичная запись физической раскладки для реального, несжатого, файла:

кластеры файла с 1 по 43-й хранятся в кластерах диска начиная с 400-го

кластеры файла с 44 по 52-й хранятся в кластерах диска начиная с 8530-го…

Физическая раскладка типичного сжатого файла:

кластеры файла с 1 по 9-й хранятся в кластерах диска начиная с 400-го

кластеры файла с 10 по 16-й нигде не хранятся

кластеры файла с 17 по 18-й хранятся в кластерах диска начиная с 409-го

кластеры файла с 19 по 36-й нигде не хранятся

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

Безопасность

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

Права файловой системы NTFS неразрывно связаны с самой системой — то есть они, вообще говоря, необязательны к соблюдению другой системой, если ей дать физический доступ к диску. Для предотвращения физического доступа в Windows2000 (NT5) всё же ввели стандартную возможность — об этом см. ниже. Система прав в своем текущем состоянии достаточно сложна, и я сомневаюсь, что смогу сказать широкому читателю что-нибудь интересное и полезное ему в обычной жизни. Если вас интересует эта тема — вы найдете множество книг по сетевой архитектуре NT, в которых это описано более чем подробно.

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

Hard Links

Эта штука была в NTFS с незапамятных времен, но использовалась очень редко — и тем не менее: Hard Link — это когда один и тот же файл имеет два имени (несколько указателей файла-каталога или разных каталогов указывают на одну и ту же MFT запись). Допустим, один и тот же файл имеет имена 1.txt и 2.txt: если пользователь сотрет файл 1, останется файл 2. Если сотрет 2 — останется файл 1, то есть оба имени, с момента создания, совершенно равноправны. Файл физически стирается лишь тогда, когда будет удалено его последнее имя.

Symbolic Links (NT5)

Гораздо более практичная возможность, позволяющая делать виртуальные каталоги — ровно так же, как и виртуальные диски командой subst в DOSе. Применения достаточно разнообразны: во-первых, упрощение системы каталогов. Если вам не нравится каталог Documents and settingsAdministratorDocuments, вы можете прилинковать его в корневой каталог — система будет по прежнему общаться с каталогом с дремучим путем, а вы — с гораздо более коротким именем, полностью ему эквивалентным. Для создания таких связей можно воспользоваться программой junction (junction.zip, 15 Кб), которую написал известный специалист Mark Russinovich. Программа работает только в NT5 (Windows 2000), как и сама возможность.

Для удаления связи можно воспользоваться стандартной командой rd.
ВНИМАНИЕ: Попытка уделения связи с помощью проводника или других файловых менеджеров, не понимающих виртуальную природу каталога (например, FAR), приведет к удалению данных, на которые ссылается ссылка! Будьте осторожны.

Шифрование (NT5)

Полезная возможность для людей, которые беспокоятся за свои секреты — каждый файл или каталог может также быть зашифрован, что не даст возможность прочесть его другой инсталляцией NT. В сочетании со стандартным и практически непрошибаемым паролем на загрузку самой системы, эта возможность обеспечивает достаточную для большинства применений безопасность избранных вами важных данных.Часть 2. Особенности дефрагментации NTFS

Вернемся к одному достаточно интересному и важному моменту — фрагментации и дефрагментации NTFS. Дело в том, что ситуация, сложившаяся с этими двумя понятиями в настоящий момент, никак не может быть названа удовлетворительной. В самом начале утверждалось, что NTFS не подвержена фрагментации файлов. Это оказалось не совсем так, и утверждение сменили — NTFS препятствует фрагментации. Оказалось, что и это не совсем так. То есть она, конечно, препятствует, но толк от этого близок к нулю… Сейчас уже понятно, что NTFS — система, которая как никакая другая предрасположена к фрагментации, что бы ни утверждалось официально. Единственное что — логически она не очень от этого страдает. Все внутренние структуры построены таким образом, что фрагментация не мешает быстро находить фрагменты данных. Но от физического последствия фрагментации — лишних движений головок — она, конечно, не спасает. И поэтому — вперед и с песней.

К истокам проблемы

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

Диск NTFS поделен на две зоны. В начала диска идет MFT зона — зона, куда растет MFT, Master File Table. Зона занимает минимум 12% диска, и запись данных в эту зону невозможна. Это сделано для того, чтобы не фрагментировался хотя бы MFT. Но когда весь остальной диск заполняется — зона сокращается ровно в два раза :). И так далее. Таким образом мы имеем не один заход окончания диска, а несколько. В результате если NTFS работает при диске, заполненном на около 90% — фрагментация растет как бешенная.

Попутное следствие — диск, заполненный более чем на 88%, дефрагментировать почти невозможно — даже API дефрагментации не может перемещать данные в MFT зону. Может оказаться так, что у нас не будет свободного места для маневра.

Далее. NTFS работает себе и работает, и всё таки фрагментируется — даже в том случае, если свободное место далеко от истощения. Этому способствует странный алгоритм нахождения свободного места для записи файлов — второе серьезное упущение. Алгоритм действий при любой записи такой: берется какой-то определенный объем диска и заполняется файлом до упора. Причем по очень интересному алгоритму: сначала заполняются большие дырки, потом маленькие. Т.е. типичное распределение фрагментов файла по размеру на фрагментированной NTFS выглядит так (размеры фрагментов):

16 — 16 — 16 — 16 — 16 — [скачек назад] — 15 — 15 — 15 — [назад] — 14 — 14 — 14 …. 1 — 1 — 1 -1 — 1…

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

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

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

Средства решения?

В NT существует стандартное API дефрагментации. Обладающее интересным ограничением для перемещения блоков файлов: за один раз можно перемещать не менее 16 кластеров (!), причем начинаться эти кластеры должны с позиции, кратной 16 кластерам в файле. В общем, операция осуществляется исключительно по 16 кластеров. Следствия:

1. В дырку свободного места менее 16 кластеров нельзя ничего переместить (кроме сжатых файлов, но это неинтересные в данный момент тонкости).
2. Файл, будучи перемещенный в другое место, оставляет после себя (на новом месте) «временно занятое место», дополняющее его по размеру до кратности 16 кластерам.
3. При попытке как-то неправильно (»не кратно 16») переместить файл результат часто непредсказуем. Что-то округляется, что-то просто не перемещается… Тем не менее, всё место действия щедро рассыпается «временно занятым местом».

«Временно занятое место» служит для облегчения восстановления системы в случае аппаратного сбоя и освобождается через некоторое время, обычно где-то пол минуты.

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

• Вынимание файлов из MFT зоны. Не специально — просто обратно туда их положить не представляется возможным 🙂 Безобидная фаза, и даже в чем то полезная.
• Дефрагментация файлов. Безусловно, полезный процесс, несколько, правда, осложняемый ограничениями кратности перемещений — файлы часто приходится перекладывать сильнее, чем это было бы логично сделать по уму.
• Дефрагментация MFT, виртуалки (pagefile.sys) и каталогов. Возможна через API только в Windows2000, иначе — при перезагрузке, отдельным процессом, как в старом Diskeeper-е.
• Складывание файлов ближе к началу — так называемая дефрагментация свободного места. Вот это — воистину страшный процесс.

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

Пока есть всего один дефрагментатор, который игнорирует API дефрагментации и работает как-то более напрямую — Norton Speeddisk 5.0 для NT. Когда его пытаются сравнить со всеми остальными — Diskeeper, O&O defrag, т. д. — не упоминают этого главного, самого принципиального, отличия. Просто потому, что эта проблема тщательно скрывается, по крайней мере уж точно не афишируется на каждом шагу. Speeddisk — единственная на сегодняшний день программа, которая может оптимизировать диск полностью, не создавая маленьких незаполненных фрагментов свободного места. Стоит добавить также, что при помощи стандартного API невозможно дефрагментировать тома NTFS с кластером более 4 Кбайт, а SpeedDisk и это может.

К сожалению, в Windows 2000 поместили дефрагментатор, который работает через API, и, соответственно, плодит дырки Как некоторый вывод из всего этого: все остальные дефрагментаторы при одноразовом применении просто вредны. Если вы запускали его хоть раз — нужно запускать его потом хотя бы раз в месяц, чтобы избавится от фрагментации новоприбывающих файлов. В этом основная суть сложности дефрагментации NTFS теми средствами, которые сложились исторически.Часть 3. Что выбрать?

Любая из представленных ныне файловых систем уходит своими корнями в глубокое прошлое — еще к 80-м годам. Да, NTFS, как это не странно — очень старая система! Дело в том, что долгое время персональные компьютеры пользовались лишь операционной системой DOS, которой и обязана своим появлением FAT. Но параллельно разрабатывались и тихо существовали системы, нацеленные на будущее. Две таких системы, получившие всё же широкое признание — NTFS, созданная для операционной системы Windows NT 3.1 еще в незапамятные времена, и HPFS — верная спутница OS/2.

Внедрение новых систем шло трудно — еще в 95м году, с выходом Windows95, ни у кого не было и мыслей о том, что что-то нужно менять — FAT получил второе дыхание посредством налепленной сверху заплатки «длинные имена», реализация которых там хоть и близка к идеально возможной без изменения системы, но всё же довольно бестолкова. Но в последующие годы необходимость перемен назрела окончательно, поскольку естественные ограничения FAT стали давать о себе знать. FAT32, появившаяся в Windows 95 OSR2, просто сдвинула рамки — не изменив сути системы, которая просто не дает возможности организовать эффективную работу с большим количеством данных.

HPFS (High Performance File System), активно применяемая до сих пор пользователями OS/2, показала себя достаточно удачной системой, но и она имела существенные недостатки — полное отсутствие средств автоматической восстанавливаемости, излишнюю сложность организации данных и невысокую гибкость.

NTFS же долго не могла завоевать персональные компьютеры из-за того, что для организации эффективной работы с её структурами данных требовались значительные объемы памяти. Системы с 4 или 8 Мбайт (стандарт 95-96 годов) были просто неспособны получить хоть какой-либо плюс от NTFS, поэтому за ней закрепилась не очень правильная репутация медленной и громоздкой системы. На самом деле это не соответствует действительности — современные компьютерные системы с памятью более 64 Мб получают просто огромный прирост производительности от использования NTFS.

В данной таблице сведены воедино все существенные плюсы и минусы распространенных в наше время систем, таких как FAT32, FAT и NTFS. Вряд ли разумно обсуждать другие системы, так как в настоящее время 97% пользователей делают выбор между Windows98, Windows NT4.0 и Windows 2000 (NT5.0), а других вариантов там просто нет.

	FAT	FAT32	NTFS
Системы, её поддерживающие	DOS, Windows9Х, NT всех версий	Windows98, NT5	NT4, NT5
Максимальный размер тома	2 Гбайт	практически неограничен	практически неограничен
Макс. число файлов на томе	примерно 65 тысяч	практически не ограничено	практически не ограничено
Имя файла	с поддержкой длинных имен — 255 символов, системный набор символов	с поддержкой длинных имен — 255 символов, системный набор символов	255 символов, любые символы любых алфавитов (65 тысяч разных начертаний)
Возможные атрибуты файла	Базовый набор	Базовый набор	всё, что придет в голову производителям программного обеспечения
Безопасность	нет	нет	да (начиная с NT5.0 встроена возможность физически шифровать данные)
Сжатие	нет	нет	да
Устойчивость к сбоям	средняя (система слишком проста и поэтому ломаться особо нечему :))	плохая (средства оптимизации по скорости привели к появлению слабых по надежности мест)	полная — автоматическое восстановление системы при любых сбоях (не считая физические ошибки записи, когда пишется одно, а на самом деле записывается другое)
Экономичность	минимальная (огромные размеры кластеров на больших дисках)	улучшена за счет уменьшения размеров кластеров	максимальна. Очень эффективная и разнообразная система хранения данных
Быстродействие	высокое для малого числа файлов, но быстро уменьшается с появлением большого количества файлов в каталогах. результат — для слабо заполненных дисков — максимальное, для заполненных — плохое	полностью аналогично FAT, но на дисках большого размера (десятки гигабайт) начинаются серьезные проблемы с общей организацией данных	система не очень эффективна для малых и простых разделов (до 1 Гбайт), но работа с огромными массивами данных и внушительными каталогами организована как нельзя более эффективно и очень сильно превосходит по скорости другие системы

Хотелось бы сказать, что если ваша операционная система — NT (Windows 2000), то использовать какую-либо файловую систему, отличную от NTFS — значит существенно ограничивать свое удобство и гибкость работы самой операционной системы. NT, а особенно Windows 2000, составляет с NTFS как бы две части единого целого — множество полезных возможностей NT напрямую завязано на физическую и логическую структуру файловой системы, и использовать там FAT или FAT32 имеет смысл лишь для совместимости — если у вас стоит задача читать эти диски из каких-либо других систем.

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

Продолжение читайте в статье «Надежность дисковой системы NT»

Правильная организация файлов или наше спасение в наших руках / Хабр

Я не открою Америку, если скажу, что способ организации файлов в современных ФС мягко говоря не совсем удобен для конечного пользователя. И действительно: иерархическая модель представления данных на основе файлов и каталогов, не менявшаяся уже несколько десятков лет, просто не способна соответствовать современным потребностям в хранении большого количества разнородного контента. И если с музыкальной информацией все более-менее хорошо, благодаря таким медиа-библиотекам, как iTunes или Amarok, то с файлами остальных форматов ситуация до сих пор остается очень печальной.

Суть проблемы

Я уверен, на компьютере каждого человека, читающего этот топик, наверняка есть хоть один из следующих каталогов: soft, разобрать, временно, всякая всячина, trash, интересное. Обычно в папке софт находится несколько тысяч архивов и экзешников с говорящими названиями «setup.exe» или «589346.zip»; папка «Мои документы» засрана кучей файлов, многие из которых вообще к документам не относятся, а файлы из каталога «Разобрать» так и остаются не разобранными…
При этом, когда у нас возникает потребность отыскать «тот самый дистрибутив visual studio, который я скачивал пару месяцев назад», то гораздо проще за несколько секунд найти ссылку на установщик в гугле, чем долго и тщетно пытаться искать его на своем компьютере. Стандартные утилиты поиска так же не спасают, т.к. для бинарных файлов они могут ориентироваться только на название файла, да жалкую горстку дополнительных атрибутов.

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

Варианты решения

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

Хорошо, но если такую простую и удобную идею до сих пор не внедрили производители операционных систем, то куда же смотрят разработчики сторонних приложений?!
Я полагал, что существует как минимум несколько альтернатив, позволяющих создавать базу данных, на основе тегирования файлов, ведь это так просто для реализации!
К моему разочарованию я обнаружил, что подсуетились лишь программисты под Mac OS: 7 File Tagging Applications for OS X (разумеется, почти все они платные).
Ни для windows, и, тем более, ни для Linux ничего подобного я не нашел. Хотя, возможно, я просто плохо искал — в таком случае очень прошу указать в комментариях ссылки на такой софт.

Разумеется, это воодушевило меня стать «посланцем добра и света», освободив несчастных пользователей от гнета архаичных ФС. А т.к. основной ОС для меня является Linux Ubuntu, то вопрос на чем писать даже не вставал — конечно это python, тем более что связываться с технологиями Microsoft мне совсем не хотелось.
Базовый список требований получился совсем небольшим, и это мотивировало меня еще больше. Итак, чего же я жду от такой программы:

1. Добавление/редактирование тегов к файлам и папкам прямо из контекстного меню файлового менеджера (Nautilus)
2. Интерфейс для поиска и просмотра файлов по указанным тегам
3. Отслеживание изменений в именах и расположении (что, в общем, одно и то же) файлов

Грубо говоря, наша инновационная и нанотехнологичная программа будет состоять из трех компонентов: системная интеграция, база данных и процесс/демон.

Существующие средства

Решив прощупать почву для первого этапа, т.е. добавление своих элементов в контекстное меню программы Nautilus, я наткнулся на один open-source проект, который частично реализует мою идею — это «tags-tabs extension».
Честно говоря, слово «проект» слабо подходит для одного полуработающего .py исходника на 7 кб, и не имеющего никакой документации.
tags-tabs — это расширение для Nautilus, использующее библиотеку «python-nautilus». Оно добавляет в контекстное меню свой пункт, что позволяет назначать файлам теги и выполнять базовый поиск.
В теории, чтобы все заработало, необходимо поместить этот файл в директории ~/.nautilus/extensions/python и дать ему права на исполнение. На практике, в моей Ubuntu 8.10 этот скрипт вызывает крэш приложения, при вызове меню. Говорят, что в ранних версиях убунты все работает нормально.

Также нельзя не упомянуть замечательный проект dhtfs.
DHTFS также проповедует идеологию ФС, основанной на тегах, написан на python и имеет даже краткую пользовательскую документацию! Но есть один минус — это cli-приложение.

Заключение

Так к чему это все? На самом деле, этим топиком я хочу побудить сообщество python-разработчиков, представители которого несомненно присутствуют на хабре, обратить внимание на эту интересную, но вместе с тем практически незамеченную остальными проблему.
Дело в том, что с python я начал дружить совсем недавно, поэтому вряд ли у меня хватит навыков реализовать эту идею, но с вашей помощью, взяв за основу два приведенных выше проекта, вполне можно в очередной раз доказать, что open source — это большая сила, в особенности когда за ней стоят такие энтузиасты как мы.

Пусто. Как навести порядок в файлах, чтобы не превращать десктоп в чулан

Советы по организации рабочего пространства на компьютере.

Пять лет назад уборка на компьютере выглядела для меня так: когда файлов на рабочем столе становилось слишком много, я создавал новую папку, перемещал туда всё из «Рабочего стола» и «Загрузок» и переименовывал её в «Крошки» (то, что остается на столе после еды). В результате жесткий диск больше походил на фрактальную плесень в зеркальном лабиринте: «Крошки» в «Крошках», в «Крошках», в «Крошках» и так далее. Кажется, рекорд вложенности составил порядка 40 итераций. Пришло время что-то менять.

Я решил, что хочу знать про свои файлы всё (а особенно — где что лежит). Прочитал несколько статей по теме и придумал свою систему хранения информации. Неделя ушла на то, чтобы разложить всё по полочкам. Нет, на самом деле просто снёс всё на внешний драйв, переставил систему и решил начать с нуля. Оставалось ждать. Через год и «Рабочий стол», и «Загрузки» оставались девственно чисты.

Выгода: система работала, а статья на «Лайфхакере» набрала несколько сотен репостов (по курсу 2013 года). С тех пор прошло несколько лет, файлы переехали в облако, и пришло время обновить алгоритм.

Всё — в облаке

Первый принцип, который лег в основу новой системы — всё должно быть в облаке. Это особенно очевидно в тот момент, когда теряешь материалы по проектам за год из-за внезапно сгоревшего винта на MacBook. Или когда из отпуска нужно срочно поправить рабочую презентацию.

Структура папок верхнего уровня, которой я пользуюсь:

• Фото (архив фотографий).
• Работа (рабочие файлы).
• Проекты (личные проекты).
• Мудрость (библиотека полезного контента).
• Документы (сканы и таблички).
• Обмен (разное).

Итак, всё хранится в облаке. Каждый компьютер работает только с теми файлами, которые нужны в конкретный момент или которые могут понадобится с большей вероятностью, чем встретить Путина в метро. На рабочем компьютере подключены папки «Работа» за последний год, последние несколько «Проектов» и «Обмен». На домашнем — только последние «Проекты» и «Обмен». Всё остальное извлекается по мере необходимости и тут же удаляется. В «Обмен» попадают файлы с коротким сроком годности. Эту папку можно сносить раз в неделю (например, скриптом).

Сначала — дата

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

Каталог (файловая система) — это… Что такое Каталог (файловая система)?

У этого термина существуют и другие значения, см. Каталог.

Катало́г (англ. directory — справочник, указатель) — объект в файловой системе, упрощающий организацию файлов. Типичная файловая система содержит большое количество файлов и каталоги помогают упорядочить её путём их группировки.

В информатике используется следующее определение: каталог — поименованная совокупность байтов на носителе информации, содержащая название подкаталогов и файлов.^{[источник не указан 923 дня]}

Корневой каталог

Каталог, прямо или косвенно включающий в себя все прочие каталоги и файлы файловой системы, называется корневым. В Unix-подобных ОС он обозначается символом / (дробь, слеш), в DOS и Windows исторически используется символ \ (обратный слеш), но с некоторого времени поддерживается и /.

Текущий каталог

Текущим называется каталог, с которым работает ОС, если ей не указать другого каталога. Он обозначается точкой (.).

Для смены текущего каталога на другой используется команда cd.

Родительский каталог

Родительским каталогом называется каталог, в котором находится текущий. Он обозначается двумя точками (..).

Пример (переход в родительский каталог):

Каталоги в UNIX

Каталог в UNIX — это файл, содержащий несколько inode и привязанные к ним имена.^[1] В современных UNIX-подобных ОС вводится структура каталогов, соответствующая стандарту FHS.

Иерархия каталогов в Windows

Слева направо: системная папка Корзина, обычная папка, ярлык к папке

Каталог, который не является подкаталогом ни одного другого каталога, называется корневым. Это значит, что этот каталог находится на самом верхнем уровне иерархии всех каталогов. В Windows каждый из дисков имеет свой корневой каталог (C:\, D:\ и т. д).

Каталоги в Windows бывают системные (служебные, созданные ОС) и пользовательские (созданные пользователем). Пример системных каталогов: «Рабочий стол», «Корзина», «Сетевое окружение», «Панель управления», каталоги логических дисков и т. п.

Термин «Папка»

Термин папка (англ. folder) был введён для представления объектов файловой системы в графическом пользовательском интерфейсе путём аналогии с офисными папками. Он был впервые использован в Mac OS, а в системах семейства Windows — с выходом Windows 95.^[2] Эта метафора стала использоваться в большом числе операционных систем: Windows NT, Mac OS, Mac OS X, а также в средах рабочего стола для систем семейства UNIX (например, KDE и GNOME).

В этой терминологии папка, находящаяся в другой папке, называется подпапка, вложенная папка или дочерняя папка. Все вместе папки на компьютере представляют иерархическую структуру (дерево каталогов). Подобная древообразная структура возможна в операционных системах, не допускающих существование «физических ссылок» (Windows 3.x и 9x допускали только аналог символических ссылок — ярлыков). В общем случае файловая система представляет собой ориентированный граф.

См. также

Примечания

Что такое файловое хранилище? | IBM

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

Что такое файловое хранилище?

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

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

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

Хранилище файлов, хранилище блоков и хранилище объектов

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

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

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

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

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

В следующем видео Эми Бли разбирает различия между хранилищем блоков и хранилищем файлов:

Хранилище объектов

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

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

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

В разделе «Что такое объектное хранилище?» Анируп Датта описывает архитектуру, преимущества и варианты использования:

Преимущества

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

• Простота : Хранение файлов — это самый простой, наиболее привычный и понятный подход к организации файлов и папок на жестком диске компьютера или NAS-устройства. Вы просто называете файлы, помечаете их метаданными и сохраняете их в папках в иерархии каталогов и подкаталогов. Нет необходимости писать приложения или код для доступа к вашим данным.
• Общий доступ к файлам : Хранилище файлов идеально подходит для централизации и совместного использования файлов в локальной сети (LAN).Файлы, хранящиеся на устройстве NAS, легко доступны для любого компьютера в сети, имеющего соответствующие права доступа.
• Общие протоколы : В хранилище файлов используются общие протоколы уровня файлов, такие как блок сообщений сервера (SMB), общая файловая система Интернета (CIFS) или сетевая файловая система (NFS). Если вы используете операционную систему Windows или Linux (или обе), стандартные протоколы, такие как SMB / CIFS и NFS, позволят вам читать и записывать файлы на сервер на базе Windows или Linux через локальную сеть (LAN).
• Защита данных : Хранение файлов на отдельном запоминающем устройстве, подключенном к локальной сети, обеспечивает определенный уровень защиты данных в случае сбоя сетевого компьютера. Услуги облачного хранения файлов обеспечивают дополнительную защиту данных и аварийное восстановление за счет репликации файлов данных в нескольких географически разнесенных центрах обработки данных.
• Доступность : Хранение файлов с помощью устройства NAS позволяет перемещать файлы с дорогостоящего компьютерного оборудования на более доступное устройство хранения, подключенное к локальной сети.Более того, если вы решите подписаться на услугу облачного хранения файлов, вы избавитесь от затрат на обновление оборудования на месте и связанных с этим текущих затрат на обслуживание и эксплуатацию.

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

Файловое хранилище — хорошее решение для широкого спектра потребностей в данных, включая следующие:

• Локальный общий доступ к файлам : Если ваши потребности в хранении данных в целом единообразны и просты, например, для хранения файлов и обмена ими с членами команды в офисе, подумайте о простоте хранилища на уровне файлов.
• Централизованная совместная работа с файлами : если вы загружаете, храните и обмениваете файлы в централизованной библиотеке, расположенной на месте, за пределами площадки или в облаке, вы можете легко сотрудничать с файлами с внутренними и внешними пользователями или с приглашенными гостями. вне вашей сети.
• Архивирование / хранение : Вы можете экономично архивировать файлы на устройствах NAS в среде небольшого центра обработки данных или подписаться на облачную службу хранения файлов для хранения и архивирования данных.
• Резервное копирование / аварийное восстановление : Вы можете безопасно хранить резервные копии на отдельных устройствах хранения, подключенных к локальной сети. Или вы можете подписаться на облачную службу хранения файлов, чтобы реплицировать файлы данных в нескольких географически распределенных центрах обработки данных и получить дополнительную защиту данных за счет удаленности и избыточности.

Облачное хранилище файлов (или хостинг файлового хранилища)

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

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

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

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

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

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

Решения IBM Cloud File Storage надежны, быстры и гибки.Вы получите защиту от потери данных во время обслуживания или сбоев с помощью шифрования данных в состоянии покоя, а также дублирования томов, моментальных снимков и репликации. Благодаря расположению центров обработки данных IBM по всему миру вы можете быть уверены в высокоуровневой защите данных, репликации и аварийном восстановлении.

IBM Cloud предлагает четыре предопределенных уровня Endurance с ценой за гигабайт (ГБ), которая фиксирует ваши расходы и обеспечивает предсказуемую почасовую или ежемесячную оплату для ваших краткосрочных или долгосрочных потребностей в хранении данных.Уровни долговечности файлового хранилища поддерживают производительность до 10 000 (10 КБ) операций ввода-вывода в секунду / ГБ и могут удовлетворить потребности большинства рабочих нагрузок, независимо от того, требуется ли вам производительность низкой, общей или высокой интенсивности.

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

Узнайте больше об уровнях и вариантах производительности IBM File Storage Endurance.

Подпишитесь на бесплатную двухмесячную пробную версию и начните бесплатно строить в IBM Cloud.

.Обзор

File and Storage Services

• 29.12.2016
• Читать 19 минут

В этой статье

Применимо к: Windows Server 2012 R2, Windows Server 2012

Этот раздел предназначен для специалистов по информационным технологиям (ИТ-специалистов), которые ищут информацию о серверах, на которых запущена роль файловых служб и служб хранения в Windows Server 2012 R2 и Windows Server 2012, в том числе о том, что нового, список служб ролей, а также где найти оценку и информация о развертывании.Для получения информации о Windows Server 2016 см. Хранилище в Windows Server 2016.

Если вам нужна помощь по Windows на ПК или планшете, а не на сервере, см. Справку Windows.

Возможно, вы имели в виду…

Описание роли

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

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

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

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

• Storage Spaces — используется для развертывания отказоустойчивого и масштабируемого хранилища с высокой доступностью за счет использования экономичных стандартных дисков.

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

• Рабочие папки — Используйте, чтобы позволить пользователям хранить и получать доступ к рабочим файлам на персональных компьютерах и устройствах, в дополнение к корпоративным ПК. Пользователи получают удобное место для хранения рабочих файлов и доступа к ним из любого места. Организации поддерживают контроль над корпоративными данными, сохраняя файлы на централизованно управляемых файловых серверах и при необходимости задавая политики пользовательских устройств (такие как шифрование и пароли экрана блокировки). Рабочие папки — это новая служба ролей в Windows Server 2012 R2.

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

• iSCSI Target Server — используется для создания централизованных, программных и аппаратно-независимых дисковых подсистем iSCSI в сетях хранения данных (SAN).

• Server Manager — используется для удаленного управления несколькими файловыми серверами из одного окна.

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

Новый и измененный функционал

Для получения информации о новых функциях файловых служб и служб хранения в Windows Server 2016 см. Что нового в хранилище в Windows Server 2016.

В следующей таблице описаны некоторые из основных изменений функций файловых служб и служб хранения, доступных в Windows Server 2012 R2.

Усовершенствования Усовершенствования Обновления

Особенности / функции	Новое или обновленное?	Описание
Рабочие папки	Новый	Предоставляет пользователям единый способ доступа к своим рабочим файлам со своих персональных компьютеров и устройств.См. Дополнительные сведения в разделе «Рабочие папки».
Блок сообщений сервера	Обновлено	Усовершенствования включают автоматическую перебалансировку клиентов горизонтально масштабируемого файлового сервера, улучшенную производительность SMB Direct и улучшенные сообщения о событиях SMB. Дополнительные сведения см. В разделе Что нового в SMB.
Мест для хранения	Обновлено	включают уровни хранения SSD и HDD, кэш с обратной записью на основе SSD, поддержку пространства с четностью для отказоустойчивых кластеров, поддержку двойной четности и значительное сокращение времени восстановления пространства хранения.Дополнительные сведения см. В разделе «Что нового в дисковых пространствах».
Репликация DFS	Обновлено	включают клонирование базы данных для значительного увеличения производительности во время начальной синхронизации, модуль Windows PowerShell для репликации DFS, новый поставщик WMI репликации DFS, более быструю репликацию при соединениях с высокой пропускной способностью, восстановление конфликтов и ранее существовавших данных, а также поддержку восстановления поврежденных баз данных без неожиданных данных. потеря. Дополнительные сведения см. В разделе «Новые возможности репликации DFS и пространств имен DFS».
Целевой сервер iSCSI	Обновлено	включают усовершенствования виртуальных дисков, улучшения управляемости в размещенном или частном облаке, а также улучшенную оптимизацию для обеспечения кэширования на уровне дисков. Дополнительные сведения см. В разделе Что нового в целевом сервере iSCSI.

В следующей таблице описаны некоторые из основных изменений функций файловых служб и служб хранения, доступных в Windows Server 2012.

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

Дедупликация данных

Используя службу роли дедупликации данных для уменьшения количества повторяющихся блоков данных в хранилище, вы можете хранить гораздо больше данных в заданном объеме хранилища, чем это было возможно в предыдущих выпусках, в которых использовалось хранилище единственного экземпляра (SIS) или файл NTFS. система сжатия. Файловые серверы общего назначения обычно могут уменьшить использование емкости хранилища в соотношении 2: 1 (например, файлы, которые ранее использовали 1 ТБ, будут использовать 500 ГБ после дедупликации данных).Серверы, на которых размещены данные виртуализации (например, файлы VHD), часто уменьшают использование емкости хранилища в соотношении 20: 1, что уменьшает объем данных с 1 ТБ до 50 ГБ.

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

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

Какую ценность добавляет это изменение?

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

Что по-другому работает?

Windows Server 2012 включает дедупликацию данных в качестве службы роли, которую можно установить и которой можно управлять с помощью диспетчера сервера или командлетов Windows PowerShell. Параметры по умолчанию могут быстро уменьшить объем памяти, используемый вашими данными. Вы можете точно настроить параметры, чтобы получить больше преимуществ, или использовать командлеты Windows PowerShell для создания сценариев, которые будут запускать оптимизацию хранилища, когда и где вы этого хотите.

Для получения более подробной информации см. Дедупликация данных.

Целевой сервер iSCSI

iSCSI Target Server обеспечивает блочное хранилище для других серверов и приложений в сети, используя стандарт Internet SCSI (iSCSI). В сочетании с другими постоянно доступными технологиями в Windows Server 2012 iSCSI Target Server обеспечивает постоянно доступное хранилище, которое ранее было доступно только на дорогих устройствах сети хранения данных высокого класса (SAN).

Какую ценность добавляет это изменение?

• Сетевая или бездисковая загрузка Используя сетевые адаптеры с возможностью загрузки или загрузчик программного обеспечения, вы можете развернуть сотни бездисковых серверов.Благодаря iSCSI Target Server развертывание происходит быстро (при тестировании Microsoft 256 компьютеров были развернуты за 34 минуты). Используя разностные виртуальные жесткие диски, вы можете сэкономить до 90% дискового пространства для образов операционной системы. Это идеально подходит для крупных развертываний идентичных образов операционных систем, таких как ферма серверов с Hyper-V или кластерами высокопроизводительных вычислений (HPC).

• Хранилище серверных приложений Некоторым приложениям (например, Hyper-V и Exchange Server) требуется блочное хранилище, которое представляет собой неформатированное хранилище, которое отображается для приложений как неформатированный диск, готовый для прямого управления приложением.iSCSI Target Server может предоставить этим приложениям постоянно доступное блочное хранилище. Поскольку хранилище доступно удаленно, iSCSI Target Server также может консолидировать блочное хранилище для центральных офисов или филиалов.

• Гетерогенное хранилище iSCSI Target Server поддерживает инициаторы iSCSI в операционных системах, отличных от Windows, что упрощает совместное использование хранилища в гетерогенной среде.

• Среды для разработки, тестирования и демонстрации лабораторных работ С iSCSI Target Server любой компьютер под управлением Windows Server 2012 может быть доступным по сети устройством блочного хранения.Это полезно для тестирования приложений перед развертыванием на устройстве хранения SAN.

Что по-другому работает?

В Windows Server 2012 функции управления iSCSI Target Server перемещаются из отдельной загрузки в часть операционной системы Windows Server. Вы можете использовать диспетчер сервера или командлеты Windows PowerShell для установки, настройки и управления целевым сервером iSCSI. Windows Server 2012 также включает изменения в модель ресурсов кластеризации, которые улучшают масштабируемость, чтобы большее количество инициаторов могло подключаться к целевым серверам.

Для получения более подробной информации см. ISCSI Target Server.

Мест для хранения

Storage Spaces — это подсистема хранения, включенная в Windows, которая позволяет группировать стандартные диски (например, диски Serial ATA или Serial Attached SCSI) в один или несколько пулов хранения, а затем создавать виртуальные диски, известные как «пространства хранения», из доступная емкость пулов хранения. Storage Spaces предоставляет возможности отказоустойчивой виртуализации хранилища для критически важных для бизнеса виртуальных или физических развертываний, включая развертывание на масштабируемых многоузловых серверах.

После группировки физических дисков в пулы хранения можно создавать виртуальные диски из доступной емкости без отдельного управления каждым физическим диском. Такое объединение дисков позволяет создавать высокопроизводительные, отказоустойчивые и экономичные решения для хранения данных. В Windows Server вы можете использовать пулы хранения с дисковыми пространствами или с подсистемами хранения, отличными от Microsoft, включая подсистемы, использующие стандарт SMI-S.

Какую ценность добавляет это изменение?

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

Что по-другому работает?

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

Для получения дополнительной информации см. Storage Spaces and Storage Management.

Единое удаленное управление файловыми службами и службами хранения в Server Manager

Роль файловых служб и служб хранения в диспетчере серверов позволяет удаленно управлять несколькими файловыми серверами из одного окна в Windows Server 2012 R2 или Windows Server 2012, включая службы ролей и хранилище. На странице файловых служб и служб хранения в диспетчере сервера представлены следующие разделы для управления всеми серверами под управлением Windows Server 2012 R2 или Windows Server 2012, которые были добавлены в диспетчер сервера:

• Серверы Управление основными функциями сервера на серверах под управлением Windows Server 2012 R2, Windows Server 2012, Windows Server 2008 R2 или Windows Server 2008.Вы можете использовать страницу Servers для выполнения таких задач, как перезапуск серверов и запуск административных инструментов.

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

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

• Общие ресурсы Управление общими ресурсами SMB и NFS, включая создание новых общих ресурсов и установку квот.

• Виртуальные диски iSCSI Управление виртуальными дисками iSCSI, включая создание новых виртуальных дисков iSCSI и целей.

Какую ценность добавляет это изменение?

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

Что по-другому работает?

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

• Управление дисками

• Управление общим доступом и хранилищем

• Диспетчер ресурсов файлового сервера (квоты и назначение свойств управления папками для общих файловых ресурсов)

• Программная цель Microsoft iSCSI (недоступно в Windows Server 2012)

• Диспетчер хранилища для сетей SAN (недоступно в Windows Server 2012)

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

Дополнительные сведения о диспетчере сервера см. В разделе «Управление несколькими удаленными серверами с помощью диспетчера сервера».

Примечание

Хотя роль файловых служб и служб хранения в диспетчере сервера не поддерживает полное управление серверами под управлением Windows Server 2008 R2 или Windows Server 2008, вы можете добавить эти серверы в диспетчер сервера и использовать для просмотра страницы Servers и All Servers подробности о серверах и средствах администрирования запуска. Дополнительные сведения см. В разделе Управление серверами на базе Windows нижнего уровня из диспетчера серверов в Windows Server 2012.

Командлеты Windows PowerShell для файловых служб и служб хранения

Windows Server 2012 R2 и Windows Server 2012 включают командлеты Windows PowerShell для выполнения большинства задач администрирования файловых серверов и серверов хранения.

Какую ценность добавляет это изменение?

Расширенные командлеты Windows PowerShell позволяют администраторам автоматизировать общие задачи администрирования с помощью сценариев Windows PowerShell.

Что по-другому работает?

Вместо использования множества надстроек или разрозненных утилит командной строки администраторы могут управлять своими серверами с помощью командлетов и сценариев Windows PowerShell.Windows Server 2012 R2 и Windows Server 2012 включают командлеты Windows PowerShell для управления следующими технологиями файлов и хранилищ.

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

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

Удаленная или устаревшая функциональность

Следующие функции включены в Windows Server 2012 R2 и Windows Server 2012, но они постепенно прекращаются и, вероятно, будут полностью удалены из будущих версий Windows Server.

Инструменты командной строки диспетчера ресурсов файлового сервера

Устаревшая функция	Замена
Инструмент командной строки пространств имен DFS: Dfscmd	Командлеты Windows PowerShell для пространств имен DFS
Служба репликации файлов (FRS)	Репликация DFS
: Dirquota, Filescrn и Storrept	Командлеты Windows PowerShell для диспетчера ресурсов файлового сервера
Оснастка для управления общими ресурсами и хранилищами	Роль файловых служб и служб хранения в диспетчере серверов
Оснастка общих папок	Роль файловых служб и служб хранения в диспетчере серверов
Поставщик службы виртуальных дисков (VDS)	API управления хранилищем и поставщик хранилища или стандарт SMI-S и соответствующий поставщик хранилища

Следующие функции отсутствуют в Windows Server 2012.

Оснастка

Устаревшая функция	Замена
Storage Manager for SANs	Роль файловых служб и служб хранилища в диспетчере серверов и командлетах Windows PowerShell для управления хранилищем
Драйверы адаптера хост-шины SCSIport	Драйверы Storport или другой адаптер главной шины

Список устаревших функций в Windows Server 2012 см. В разделе Функции, удаленные или устаревшие в Windows Server 2012.

Дополнительные сведения о поддержке службы репликации файлов в Windows Server 2012 и Windows Server 2008 R2 см. В разделе Служба репликации файлов (FRS) не рекомендуется в Windows Server 2008 R2.

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

Нет специальных требований к оборудованию или программному обеспечению для работы файловых служб и служб хранения. Однако диспетчер ресурсов файлового сервера и репликация DFS поддерживают только тома, отформатированные с файловой системой NTFS — отказоустойчивая файловая система (ReFS) и файловая система FAT не поддерживаются.

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

Как развернуть и настроить эту роль в многосерверной среде?

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

Могу ли я запустить эту роль на виртуальных машинах?

Да. Вы можете запускать файловые службы и службы хранилища и все службы их ролей на виртуальных машинах Hyper-V.

Важно

Использование моментальных снимков Hyper-V для восстановления сервера, на котором выполняется репликация DFS, для репликации чего-либо, кроме папки SYSVOL, приводит к сбою репликации DFS, что требует специальных действий по восстановлению базы данных. Дополнительные сведения см. В статье 2517913 в базе знаний Microsoft.

Могу ли я запустить эту роль в кластерной среде?

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

Есть ли рекомендации по удаленному управлению этой ролью?

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

• Менеджер сервера

• Командлеты Windows PowerShell

• Управление DFS

• Диспетчер ресурсов файлового сервера

• Службы для сетевой файловой системы

• Утилиты командной строки DFS

Никаких особых соображений не требуется.

Есть ли рекомендации по управлению ролью в варианте установки Server Core?

Вы можете установить и запустить файловые службы и службы хранения в варианте установки Server Core или минимальном серверном интерфейсе Windows Server 2012. Диспетчер сервера и административные консоли не работают в варианте установки Server Core, хотя их можно использовать с минимальным Серверный интерфейс. Их также можно использовать для удаленного администрирования серверов, использующих опцию Server Core.

Информация о диспетчере сервера

Следующие службы ролей могут быть установлены с ролью сервера служб файлов и хранилища.

Примечание

Диспетчер сервера

нельзя использовать для добавления ролей и компонентов на серверы под управлением Windows Server 2008 R2, Windows Server 2008 или Windows Server 2003. Дополнительные сведения см. В разделе «Удаленное управление несколькими серверами: обзор сценария [Сценарий Pillar]». Кроме того, Server Manager может получать только статус онлайн или офлайн от серверов под управлением Windows Server 2003.

Ролевая служба	Описание
Файловые службы	Обеспечивает группировку служб ролей, связанных с файловыми серверами, при этом ничего не устанавливается.
Файловый сервер	Управляет общими папками и позволяет пользователям получать доступ к файлам на этом компьютере из сети. Дополнительные сведения о файловых ресурсах, использующих протокол SMB, см. В разделе Блок сообщений сервера.
BranchCache для сетевых файлов	Позволяет компьютерам в филиалах кэшировать часто загружаемые файлы из общих файловых ресурсов, на которых включен BranchCache, а затем предоставлять эти файлы другим компьютерам в филиале. Это снижает использование полосы пропускания сети и обеспечивает более быстрый доступ к файлам. Дополнительные сведения о BranchCache см. В разделе BranchCache.
Дедупликация данных	Сохраняет дисковое пространство, сохраняя на томе одну копию идентичных данных.Дополнительные сведения о дедупликации данных см. В разделе «Дедупликация данных».
Пространства имен DFS	Позволяет группировать общие файловые ресурсы, расположенные на разных серверах, в одно или несколько логически структурированных пространств имен. Каждое пространство имен отображается для пользователей как единый файловый ресурс с рядом вложенных папок. Однако базовая структура пространства имен может состоять из множества общих файловых ресурсов, расположенных на разных серверах на нескольких сайтах. Поскольку основная структура общих файловых ресурсов скрыта от пользователей, одна папка в пространстве имен DFS может соответствовать нескольким общим файловым ресурсам на нескольких серверах.Эта структура обеспечивает отказоустойчивость и возможность автоматически подключать пользователей к локальным файловым ресурсам, когда они доступны, вместо маршрутизации пользователей через подключения к глобальной сети (WAN). Дополнительные сведения см. В разделе Пространства имен DFS и репликация DFS.
Репликация DFS	Реплицирует данные между несколькими серверами через сетевые подключения с ограниченной пропускной способностью и подключения к локальной сети. Это механизм репликации с несколькими главными серверами, который использует протокол удаленного разностного сжатия (RDC) для обновления только тех частей файлов, которые изменились с момента последней репликации.Репликация DFS может использоваться вместе с пространствами имен DFS или сама по себе. Дополнительные сведения см. В разделе Пространства имен DFS и репликация DFS.
Диспетчер ресурсов файлового сервера	Помогает вам управлять файлами и папками на файловом сервере и понимать их, путем планирования задач управления файлами и отчетов о хранении, классификации файлов и папок, настройки квот для папок и определения политик проверки файлов. Дополнительные сведения см. В разделе Диспетчер ресурсов файлового сервера.
Служба агента VSS файлового сервера	Позволяет создавать теневые копии томов приложений, хранящих файлы данных на этом файловом сервере.
Целевой сервер iSCSI	Предоставляет инструменты управления для целей iSCSI. Для получения дополнительной информации см. Целевой сервер iSCSI.
Сервер для сетевой файловой системы (NFS)	Позволяет этому компьютеру обмениваться файлами с компьютерами под управлением UNIX и другими компьютерами, которые используют протокол сетевой файловой системы (NFS).
Складские услуги	Обеспечивает всегда установленную функциональность управления хранилищем, включая дисковые пространства и пулы хранения.

См. Также

Для получения дополнительной информации см. Следующие ресурсы.

.

Хранение и управление файлами — CC Doc

Обзор [править]

Compute Canada предоставляет широкий спектр вариантов хранения для удовлетворения потребностей самых разных пользователей. Эти решения для хранения данных варьируются от высокоскоростного временного локального хранилища до различных видов долгосрочного хранения, поэтому вы можете выбрать носитель, который наилучшим образом соответствует вашим потребностям и шаблонам использования. В большинстве случаев файловые системы в системах Compute Canada представляют собой общих ресурсов , и по этой причине их следует использовать ответственно — неразумное поведение может негативно повлиять на десятки или сотни других пользователей.Эти файловые системы также предназначены для хранения ограниченного числа очень больших файлов, которые обычно являются двоичными, поскольку очень большие (сотни МБ и более) текстовые файлы теряют большую часть своего интереса к тому, чтобы быть удобочитаемыми. Поэтому вам следует избегать хранения десятков тысяч маленьких файлов, где маленький означает меньше нескольких мегабайт, особенно в одном каталоге. Лучшим подходом является использование таких команд, как tar или zip, для преобразования каталога, содержащего множество небольших файлов, в один очень большой архивный файл.

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

Обратите внимание, что системы хранения Compute Canada не предназначены для личного использования и должны использоваться только для хранения данных исследований.

Когда ваша учетная запись создается в кластере Compute Canada, ваш домашний каталог не будет полностью пустым. Он будет содержать ссылки на ваши царапины и пробелы проекта через механизм символической ссылки, своего рода ярлык, который обеспечивает легкий доступ к этим другим файловым системам из вашего домашнего каталога. Обратите внимание, что эти символические ссылки могут появиться в течение нескольких часов после первого подключения к кластеру.В то время как ваш дом и рабочие места уникальны для вас как отдельного пользователя, пространство для проекта совместно используется исследовательской группой. Эта группа может состоять из лиц с учетной записью Compute Canada, спонсируемой конкретным преподавателем или участниками распределения RAC. Таким образом, данное лицо может иметь доступ к нескольким различным пространствам проектов, связанным с одним или несколькими преподавателями, с символическими ссылками на эти различные пространства проектов в каталогах проектов вашего дома. У каждой учетной записи есть один или несколько проектов.В папках проектов в своем домашнем каталоге каждый пользователь имеет ссылку на каждый из проектов, к которым у него есть доступ. Для пользователей с одной активной спонсируемой ролью это проект по умолчанию вашего спонсора, в то время как пользователи с более чем одной активной спонсируемой ролью будут иметь проект по умолчанию, который соответствует проекту по умолчанию преподавателя с наиболее спонсируемыми аккаунтами.

Все пользователи могут проверить доступное дисковое пространство и текущее использование диска для файловых систем project , home и scratch с помощью утилиты командной строки diskusage_report , доступной в кластерах Compute Canada.Чтобы использовать эту утилиту, войдите в кластер с помощью SSH, введите в командной строке diskusage_report и нажмите клавишу Enter. Ниже приводится типичный вывод этой утилиты:

 # diskusage_report
                   Описание Пространство Кол-во файлов
                 Home (имя пользователя) 280 kB / 47 GB 25 / 500k
              Scratch (имя пользователя) 4096 B / 18 ТБ 1 / 1000k
       Проект (def-username-ab) 4096 B / 9536 ГБ 2 / 500k
          Проект (def-username) 4096 B / 9536 GB 2 / 500k
  

Типы хранилищ [править]

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

• ДОМ: Хотя ваш домашний каталог может показаться логичным местом для хранения всех ваших файлов и выполнения всей вашей работы, в целом это не так — ваш дом обычно имеет относительно небольшую квоту и не имеет особенно хорошая производительность при записи и чтении больших объемов данных. Наиболее логичным использованием вашего домашнего каталога обычно является исходный код, файлы с небольшими параметрами и сценарии отправки заданий.
• ПРОЕКТ: Пространство проекта имеет значительно большую квоту и хорошо приспособлено для обмена данными между членами исследовательской группы, поскольку оно, в отличие от дома или пустого места, связано с учетной записью профессора, а не с отдельным пользователем.
• SCRATCH : Для интенсивных операций чтения / записи скретч — лучший выбор. Однако помните, что важные файлы необходимо копировать с нуля, поскольку для них не создается резервная копия, а более старые файлы подлежат очистке.Поэтому временное хранилище следует использовать только для временных файлов.

Лучшие практики [править]

• Используйте текстовый формат только для файлов размером менее нескольких мегабайт.
• По возможности используйте временные файлы с нуля и локальное хранилище. Для локального хранилища вы можете использовать временный каталог, созданный для этого планировщиком заданий, с именем $ SLURM_TMPDIR .
• Если ваша программа должна искать в файле, быстрее всего это сделать, предварительно полностью прочитав его перед поиском.
• Регулярно очищайте свои данные в рабочих местах и ​​пространствах проекта, потому что эти файловые системы используются для огромных коллекций данных.
• Если вы больше не используете определенные файлы, но их необходимо сохранить, заархивируйте и сожмите их и, если возможно, скопируйте их в другое место.
• Дополнительные сведения об управлении множеством файлов см. В разделе Работа с большими коллекциями файлов, особенно если вы ограничены квотой на количество файлов.
• Наличие любого вида параллельного доступа на запись к файлу, хранящемуся в общей файловой системе, такой как home, scratch и project, может создать проблемы, если вы не используете специализированный инструмент, такой как MPI-IO.
• Если ваши потребности не удовлетворяются доступными вариантами хранения, обратитесь в службу технической поддержки.

Квоты и политики файловой системы [править]

Чтобы обеспечить достаточное пространство для всех пользователей Compute Canada, существует ряд квот и ограничений политики в отношении резервного копирования и автоматической очистки определенных файловых систем. По умолчанию в наших кластерах каждый пользователь имеет доступ к домашнему и временному пространству, а каждая группа имеет доступ к 1 ТБ пространства проекта.Небольшое увеличение проектного и рабочего пространства доступно через нашу службу быстрого доступа (RAS). Большее увеличение проектных площадей возможно благодаря ежегодным конкурсам на распределение ресурсов (RAC). Вы можете увидеть ваше текущее использование квот для различных файловых систем на Cedar и Graham, используя команду diskusage_report.

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

См. Также [править]

.Обзор

— авторизация на основе удостоверений в файлах Azure

• 29.05.2020
• 11 минут на чтение

В этой статье

Azure Files поддерживает проверку подлинности на основе удостоверений через серверный блок сообщений (SMB) через локальные доменные службы Active Directory (AD DS) и доменные службы Azure Active Directory (Azure AD DS).В этой статье основное внимание уделяется тому, как файловые ресурсы Azure могут использовать доменные службы, локально или в Azure, для поддержки доступа на основе удостоверений к общим файловым ресурсам Azure через SMB. Включение доступа на основе удостоверений для общих файловых ресурсов Azure позволяет заменять существующие файловые серверы на общие файловые ресурсы Azure без замены существующей службы каталогов, обеспечивая беспрепятственный доступ пользователей к общим папкам.

Файлы Azure принудительно авторизуют доступ пользователей как к общему ресурсу, так и к уровням каталога / файла. Назначение разрешений на уровне общего ресурса может выполняться для пользователей или групп Azure Active Directory (Azure AD), управляемых с помощью модели управления доступом на основе ролей (Azure RBAC).При использовании RBAC учетные данные, которые вы используете для доступа к файлам, должны быть доступны или синхронизированы с Azure AD. Вы можете назначить встроенные роли Azure, такие как средство чтения общего ресурса SMB данных файлов хранилища, пользователям или группам в Azure AD, чтобы предоставить доступ для чтения к общей папке Azure.

На уровне каталога / файла служба файлов Azure поддерживает сохранение, наследование и принудительное выполнение списков управления доступом Windows, как и любые файловые серверы Windows. Вы можете сохранить списки DACL Windows при копировании данных по SMB между существующим общим файловым ресурсом и общими файловыми ресурсами Azure.Планируете ли вы принудительную авторизацию или нет, вы можете использовать общие файловые ресурсы Azure для резервного копирования списков управления доступом вместе с вашими данными.

Чтобы узнать, как включить локальную проверку подлинности доменных служб Active Directory для общих файловых ресурсов Azure, см. Раздел Включение локальной проверки подлинности доменных служб Active Directory через SMB для общих файловых ресурсов Azure.

Чтобы узнать, как включить проверку подлинности Azure AD DS для общих файловых ресурсов Azure, см. Включение проверки подлинности доменных служб Azure Active Directory в файлах Azure.

Глоссарий

Полезно понять некоторые ключевые термины, относящиеся к аутентификации доменной службы Azure AD через SMB для общих файловых ресурсов Azure:

• Проверка подлинности Kerberos

  Kerberos — это протокол аутентификации, который используется для проверки личности пользователя или хоста. Дополнительные сведения о Kerberos см. В разделе Обзор проверки подлинности Kerberos.

• Протокол блока сообщений сервера (SMB)

  SMB — это стандартный сетевой протокол обмена файлами.SMB также известен как Common Internet File System или CIFS. Дополнительные сведения о SMB см. В разделах Протокол Microsoft SMB и Обзор протокола CIFS.

• Azure Active Directory (Azure AD)

  Azure Active Directory (Azure AD) — это многопользовательский облачный каталог Microsoft и служба управления удостоверениями. Azure AD объединяет основные службы каталогов, управление доступом к приложениям и защиту удостоверений в одном решении. Присоединенные к Azure AD виртуальные машины Windows (ВМ) могут получать доступ к общим файловым ресурсам Azure с вашими учетными данными Azure AD.Дополнительные сведения см. В разделе Что такое Azure Active Directory?

• Доменные службы Azure Active Directory (Azure AD DS)

  Azure AD DS предоставляет услуги управляемого домена, такие как присоединение к домену, групповые политики, LDAP и проверка подлинности Kerberos / NTLM. Эти службы полностью совместимы с доменными службами Active Directory. Дополнительные сведения см. В разделе Доменные службы Azure Active Directory.

• Локальные доменные службы Active Directory (AD DS)

  Интеграция локальных доменных служб Active Directory (AD DS) с файлами Azure предоставляет методы для хранения данных каталога, делая их доступными для пользователей и администраторов сети.Безопасность интегрирована с AD DS посредством аутентификации при входе и контроля доступа к объектам в каталоге. С помощью единого входа в сеть администраторы могут управлять данными каталога и организацией по всей своей сети, а авторизованные пользователи сети могут получать доступ к ресурсам в любом месте сети. AD DS обычно используется предприятиями в локальных средах, а учетные данные AD DS используются в качестве удостоверения для управления доступом. Дополнительные сведения см. В разделе Обзор доменных служб Active Directory.

• Управление доступом на основе ролей Azure (Azure RBAC)

  Управление доступом на основе ролей Azure (Azure RBAC) обеспечивает детальное управление доступом для Azure. Используя RBAC, вы можете управлять доступом к ресурсам, предоставляя пользователям наименьшее количество разрешений, необходимых для выполнения их работы. Дополнительные сведения о RBAC см. В разделе Что такое управление доступом на основе ролей (Azure RBAC) в Azure ?.

Общие варианты использования

Проверка подлинности на основе идентификаторов и поддержка списков ACL Windows в файлах Azure лучше всего использовать в следующих случаях использования:

Заменить локальные файловые серверы

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

Поднимите и перенесите приложения на Azure

Когда вы переносите приложения в облако, вы хотите сохранить ту же модель аутентификации для своих данных.Поскольку мы расширяем возможности управления доступом на основе удостоверений для общих файловых ресурсов Azure, это избавляет от необходимости переводить ваше приложение на современные методы аутентификации и ускоряет внедрение облака. Файловые ресурсы Azure предоставляют возможность интеграции с Azure AD DS или локальными AD DS для проверки подлинности. Если вы планируете полностью использовать облачные технологии и минимизировать усилия по управлению облачными инфраструктурами, Azure AD DS лучше подходит в качестве полностью управляемой доменной службы. Если вам нужна полная совместимость с возможностями AD DS, вы можете рассмотреть возможность расширения среды AD DS в облако путем самостоятельного размещения контроллеров домена на виртуальных машинах.В любом случае, мы обеспечиваем гибкость в выборе доменных услуг, которые подходят вашему бизнесу.

Резервное копирование и аварийное восстановление (DR)

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

Поддерживаемые сценарии

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

Проверка подлинности Azure AD DS	Локальная проверка подлинности AD DS
Подключенные к Azure AD DS машины Windows могут получать доступ к общим файловым ресурсам Azure с учетными данными Azure AD через SMB.	Локальные компьютеры с Windows, присоединенные к AD DS или к Azure AD DS, могут получать доступ к файловым ресурсам Azure с локальными учетными данными Active Directory, которые синхронизируются с Azure AD через SMB. Ваш клиент должен находиться в прямой видимости от AD DS.

Ограничения

• Azure AD DS и локальная проверка подлинности AD DS не поддерживают проверку подлинности с использованием учетных записей компьютеров. Вместо этого вы можете рассмотреть возможность использования учетной записи для входа в службу.
• Ни аутентификация Azure AD DS, ни локальная аутентификация AD DS не поддерживаются для устройств, присоединенных к Azure AD, или устройств, зарегистрированных в Azure AD.
Файловые ресурсы
• Azure поддерживают проверку подлинности на основе удостоверений только в отношении одной из следующих доменных служб: доменных служб Azure Active Directory (Azure AD DS) или локальных доменных служб Active Directory (AD DS).

Преимущества аутентификации на основе личности

Проверка подлинности на основе удостоверений для файлов Azure предлагает несколько преимуществ по сравнению с проверкой подлинности с общим ключом:

• Расширьте возможности традиционного доступа к общим файловым ресурсам на основе удостоверений в облако с помощью локальных AD DS и Azure AD DS
  Если вы планируете перенести приложение в облако, заменив традиционные файловые серверы на общие файловые ресурсы Azure, тогда вы можете захотеть, чтобы ваше приложение проходило проверку подлинности с помощью локальных учетных данных AD DS или Azure AD DS для доступа к данным файла.Служба файлов Azure поддерживает использование учетных данных как локальных AD DS, так и учетных данных Azure AD DS для доступа к общим файловым ресурсам Azure через SMB с локальных AD DS или виртуальных машин, присоединенных к домену Azure AD DS.

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

• Резервное копирование списков управления доступом Windows (также известных как NTFS) вместе с данными
  Общие файловые ресурсы Azure можно использовать для резервного копирования существующих локальных общих файловых ресурсов. Служба файлов Azure сохраняет ваши ACL вместе с вашими данными при резервном копировании файлового ресурса в общие файловые ресурсы Azure через SMB.

Как это работает

Файловые ресурсы

Azure используют протокол Kerberos для аутентификации с помощью локальных AD DS или Azure AD DS. Когда удостоверение, связанное с пользователем или приложением, запущенным на клиенте, пытается получить доступ к данным в общих файловых ресурсах Azure, запрос отправляется в службу домена, AD DS или Azure AD DS, для проверки подлинности удостоверения.В случае успешной аутентификации возвращается токен Kerberos. Клиент отправляет запрос, содержащий токен Kerberos, и файловые ресурсы Azure используют этот токен для авторизации запроса. Файловые ресурсы Azure получают только токен Kerberos, но не учетные данные.

Прежде чем включить проверку подлинности на основе удостоверений в общих файловых ресурсах Azure, необходимо сначала настроить среду домена.

AD DS

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

На следующей схеме показана локальная проверка подлинности AD DS для общих файловых ресурсов Azure через SMB. Локальные AD DS необходимо синхронизировать с Azure AD с помощью синхронизации Azure AD Connect. Только гибридные пользователи, которые существуют как в локальных AD DS, так и в Azure AD, могут быть аутентифицированы и авторизованы для доступа к общей папке Azure.Это связано с тем, что разрешение на уровне общего ресурса настроено в соответствии с удостоверением, представленным в Azure AD, где разрешение на уровне каталога / файла применяется с разрешением в AD DS. Убедитесь, что вы правильно настроили разрешения для одного и того же гибридного пользователя.

Azure AD DS

Для проверки подлинности Azure AD DS необходимо включить доменные службы Azure AD и присоединить к домену виртуальные машины, с которых вы планируете получать доступ к данным файлов. Ваша виртуальная машина, присоединенная к домену, должна находиться в той же виртуальной сети (VNET), что и ваш Azure AD DS.

На следующей схеме представлен рабочий процесс проверки подлинности Azure AD DS для общих файловых ресурсов Azure через SMB. Он следует схеме, аналогичной локальной аутентификации AD DS для общих файловых ресурсов Azure. Есть два основных отличия:

• Во-первых, вам не нужно создавать удостоверение в Azure AD DS для представления учетной записи хранения. Это выполняется процессом включения в фоновом режиме.

• Во-вторых, все пользователи, существующие в Azure AD, могут быть аутентифицированы и авторизованы.Пользователь может быть только облачным или гибридным. Синхронизация из Azure AD в Azure AD DS управляется платформой без какой-либо настройки пользователя. Однако клиент должен быть присоединен к домену Azure AD DS, он не может быть присоединен к Azure AD или зарегистрирован.

Включить аутентификацию на основе личности

Вы можете включить аутентификацию на основе удостоверений с помощью Azure AD DS или локальных AD DS для общих файловых ресурсов Azure в ваших новых и существующих учетных записях хранения.Для проверки подлинности доступа к файлам в учетной записи хранения может использоваться только одна служба домена, которая применяется ко всем общим файловым ресурсам в учетной записи. Подробное руководство по настройке общих файловых ресурсов для проверки подлинности с помощью Azure AD DS в нашей статье Включение проверки подлинности доменных служб Azure Active Directory в файлах Azure и руководство для локальных AD DS в нашей другой статье, Включение проверки подлинности локальных доменных служб Active Directory через SMB для общих файловых ресурсов Azure.

Настроить разрешения на уровне общего ресурса для файлов Azure

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

Настройка разрешений на уровне каталога или файла для файлов Azure

Файловые ресурсы Azure обеспечивают стандартные разрешения Windows для файлов как на уровне каталога, так и на уровне файла, включая корневой каталог. Конфигурация разрешений на уровне каталога или файла поддерживается как через SMB, так и через REST.Смонтируйте целевой файловый ресурс с вашей виртуальной машины и настройте разрешения с помощью Проводника Windows, Windows icacls или команды Set-ACL.

Используйте ключ учетной записи хранения для прав суперпользователя

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

Важно

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

Сохранять списки управления доступом к каталогам и файлам при импорте данных в общие файловые ресурсы Azure

Azure Files поддерживает сохранение списков управления доступом на уровне каталогов или файлов при копировании данных в общие файловые ресурсы Azure. Вы можете скопировать ACL для каталога или файла в общие файловые ресурсы Azure с помощью службы «Синхронизация файлов» или общих наборов инструментов для перемещения файлов. Например, вы можете использовать robocopy с флагом / copy: s для копирования данных, а также списков ACL в общую папку Azure. Списки ACL сохраняются по умолчанию, вам не требуется включать аутентификацию на основе идентификации в вашей учетной записи хранения для сохранения ACL.

Стоимость

Нет дополнительной платы за обслуживание для включения аутентификации на основе идентификации через SMB для вашей учетной записи хранения. Дополнительные сведения о ценах см. В разделах «Цены на файлы Azure» и «Цены на доменные службы Azure AD».

Следующие шаги

Дополнительные сведения о файлах Azure и проверке подлинности на основе удостоверений через SMB см. В следующих ресурсах:

.