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

Обновлено: 07.07.2024

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

Какие основные понятия необходимо знать ИТ-директору или системному администратору, принимая решение о выборе СХД – рассказывает генеральный директор компании «Аэродиск» Вячеслав Володкович.

Ответственный специалист может столкнуться со сложностями ещё на первых этапах выбора СХД – определяя, какой тип системы необходим компании. В целом СХД могут быть реализованы в трёх вариантах: DAS, SAN и NAS. Накопители DAS (Direct Attached Storages) напрямую подключаются к устройствам, управляющим их работой. Например, по такому принципу работает компьютер с жёстким диском или другим внешним устройством, хранящим данные. Однако изначально термин применялся к мейнфреймам – большим высокопроизводительным серверам.

Системы вида DAS появились первыми, но они не обеспечивали необходимую скорость передачи данных – а ещё не могли предоставить условия для их совместного использования. Поэтому сегодня более распространены два других типа СХД, а именно NAS и SAN.

NAS или Network-attached Storage – это сетевое хранилище данных; система хранения, которая предоставляет файловый доступ к сети. Здесь сервер получает доступ к сети, выполненной на определённой файловой системе. И эта файловая система уже установлена на СХД. В случае NAS доступ к сети чаще всего реализован в виде протоколов NFS (Network File System) или SMB (Server Message Block).

В свою очередь SAN – это сети хранения данных. Как правило они представлены в виде внешних хранилищ на нескольких сетевых блочных устройствах и реализованы в виде протокола FC (Fiber Channel) или iSCSI (Internet Small Computer System Interface). Чаще используется Fiber Channel – он основан на оптических сетях и способен обеспечить высокую пропускную способность и низкий уровень задержек. При этом протокол iSCSI основан на классических IP-сетях, и его внедрение связано с меньшими затратами.

Системы SAN предоставляют блочный доступ непосредственно к устройству хранения – диску или наборов дисков в виде RAID-групп или логических устройств. Такие логические устройства называются LUN или Logical Unit Number. И одно логическое устройство доступно одному серверу или кластеру серверов.

Таким образом, сервер (точнее операционная система сервера), который получает блочный доступ к системе хранения, форматирует LUN в свою файловую систему в зависимости от задач. Если он работает на ОС Microsoft Windows, то это файловая система NTFS или ReFS; если продукты VMware – файловая система VMFS. А если сервер работает на Linux, то он может воспроизводить целую «гирлянду» файловых систем Extfs, Ext2, Ext3, XFS и тому подобных.

После того, как специалист разобрался с типами СХД, а также видами доступа к данным и различными протоколами, возникает ещё один вопрос – как правильно оценить производительность системы? Здесь на помощь приходят три ключевых показателя: IOPS, то есть количество операций ввода-вывода в секунду; latencу или задержка, а также MBS – количество мегабайт в секунду.

Количество переданных мегабайт в секунду характеризует скорость потока чтения и записи данных, измеряемого в мегабайтах в секунду. А показатель IOPS (Input/Output Operations Per Second) говорит о том, какое максимальное количество операций чтения или записи может выдержать СХД в зависимости от размера блока данных. Эти операции могут быть очень разными: отличаться размерами блока и глубиной очереди, иметь случайный или последовательный характер.

Что касается показателя latency, то он используется в двух случаях: при чтении и записи информации. Для оценки задержки при чтении он показывает, какое время проходит с момента получения задания до отправки информации. А для оценки задержки при записи – сколько времени занимает весь процесс с момента получения информации до подтверждения записи.

Показатели производительности имеют ключевое значение при тестировании СХД – и акцент на том или ином показателе зависит от задач, которые будут стоять перед системой.

Например, компания создаёт высоконагруженную транзакционную систему управления базами данных – скажем, PostgreSQL или Oracle. В таком случае необходимо воспроизвести характерную для этой СУБД нагрузку. Выполнив тест, можно понять, как примерно будет себя вести система хранения при решении задач СУБД, а также на какие показатели обращать особое внимание, каких значений они будут достигать. Для примера с транзакционными СУБД обычно подходит тест, который эмулирует случайный характер чтения и записи (как правило в соотношении 70 на 30) с небольшим блоком данных (как правило от 4-х до 64-х килобайт в секунду). Выполнив подобный тест, можно в первом приближении сделать вывод о возможности использования СХД для целей транзакционной СУБД.

Приведём ещё один пример. Представим, что заказчик хочет понять, какое максимальное количество операций ввода-вывода в секунду может давать СХД в этой конфигурации, независимо от задержек и количества передаваемых мегабайт в секунду. В таком случае выбирается максимально комфортный для системы размер блока данных – обычно это либо один, либо четыре килобайта; а также последовательный характер записи. Если выбрать случайный характер записи или специфичную глубину, то определить максимальный показатель IOPS не получится. То же касается и других максимальных характеристик.

Универсальный рецепт качественного тестирования СХД заключается в следующей формуле: выбрали задачу, узнали, как правильно её тестировать, подготовили тестовый стенд, протестировали, записали результат.

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

Однако снэпшоты не могут полностью заменить систему резервного копирования и выступают в качестве её дополнения. К примеру, если резервное копирование в компании выполняется раз в сутки, а данные были потеряны, снэпшоты позволяют более «гранулировано» подходить к восстановлению данных. При этом восстановление снэпшотов, в отличие от резервных копий, может проходить довольно быстро. Но если СХД выйдет из строя из-за внутренних проблем, снэпшоты уже не помогут – ведь они сами хранятся на ней.

В целом снэпшоты бывают двух видов: пересылка при записи или redirect on write, а также копирование при записи – copy on write. Снэпшоты вида redirect on write не снижают производительности СХД, при этом не почти не занимают дополнительного объема (они ничего не копируют). Этим они отличаются от copy on write, при которых данные копируются, что создает дополнительную нагрузку на СХД и «съедает» часть полезного объема.

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

Как это работает? Представим ситуацию: на площадке в Московской области были записаны данные, а у системы хранения данных настроена репликация с площадкой в Твери. Если площадка в Московской области выйдет из строя, эти данные можно будет использовать с СХД в Твери.

В синхронном режиме эти данные записываются одновременно на две СХД, и они не будут считаться записанными, пока гарантированно не окажутся записанными на обеих площадках. Это более надёжный подход, однако он приводит к временным задержкам и требует каналов связи с высокой пропускной способностью – а значит, и более высоких затрат. В случае применения асинхронной репликации данные сначала записываются на основную СХД и сразу становятся доступными, а на вторую площадку записываются в позже. В этом случае расходы будут ниже, но данные на другой площадке будут появляться с запозданием. И его уровень зависит от реализации системы.

Однако дополнительные функции СХД могут использоваться не только для защиты данных. Например, технология компрессии позволяет экономить дисковое пространство, а вместе с тем и вычислительные ресурсы СХД. В её основе лежит идея сжатия данных – за счёт этого они и занимают меньше места. Однако компрессия подходит не для всех типов данных: например, хорошо работая для текстовых данных, она практически бесполезна для медиаконтента.

Компрессия часто работает в связке с дедупликацией, устранением дублирующих блоков данных, которая также направлена на экономию пространства в системе. Приведём простой пример: секретарь компании, в которой тысяча человек, разослал всем сотрудникам письмо с PDF-файлом. Каждый сотрудник получил письмо – и в результате в хранилище может попасть тысяча копий файла. Дедупликация позволит предотвратить этот процесс, и вместо тысячи копий сохранить только один файл.

Принцип работы дедупликации заключается в том, что при записи проходит проверка, дублируется ли блок данных. Если данные уникальны, блок записывается и занимает пространство. А если нет – система предоставляет ссылку на существующий блок, чтобы когда он понадобился пользователю или серверу, он мог просто перейти по ссылке. Дедупликация становится оптимальным решением для СХД, которые работают с большим количеством одинаковых данных. Наиболее яркий пример – большая ферма виртуальных машин, где хранятся их шаблоны и образы.

Конечно, это далеко не все понятия, с которыми может столкнуться системный администратор или ИТ-директор при выборе СХД. Характеристик систем намного больше; а вопросы управления и производительности – шире и сложнее. К тому же это только общие термины из мира хранения данных: без внимания остались более узкие вопросы виртуальных RAID-ов, гиперконвергенции, QOS-ов и так далее. Однако всё это другие темы – и разговор для совсем другой статьи.

Какие еще термины важно знать, чтобы правильно выбрать СХД? Делитесь в комментариях!

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

Что такое файловый сервер?

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

Для чего используется файловый сервер?

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

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

Использование файл-сервера даёт ещё несколько важных плюсов:

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

подразделениям, отделам и сотрудникам можно выделить квоты на объём дискового пространства файлового сервера;

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

Типы файловых серверов

Один из критериев деления файловых серверов на типы — их специализация. Существуют:

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

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

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

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

специализированные файл-серверы, «заточенные» под хранение больших объёмов данных. Они оснащаются несколькими дисковыми накопителями (жёсткими дисками или SSD), которые объединяются в RAID-массивы, высокопроизводительными сетевыми картами, ускоряющими обмен, источниками бесперебойного питания, защищающими от нестабильного энергоснабжения. Файл-сервер из этой категории целесообразно использовать в средней или крупной организации;

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

Файловый сервер с web-интерфейсом

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

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

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

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

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

Попробуйте зайти на файловый сервер со стороннего компьютера или мобильного устройства, введя в адресную строку браузера внешний IP-адрес. Узнать его можно, выбрав в HFS «Menu» — «IP address» — «Find external address». Если приложение работает корректно, вы должны увидеть на экране его интерфейс.

Кликните по любой папке, подготовленной к удалённому доступу, правой кнопкой мыши, и выберите «Properties». В появившемся окне обратите внимание на вкладку «Permissions». Здесь вы сможете устанавливать права доступа к данным — наделять пользователей возможностью скачивать файлы, удалять их, а также загружать файлы на сервер через браузер.

Технические характеристики файловых серверов

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

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

Скорость передачи данных. Чем она выше, тем комфортнее пользователям будет работать с файлами на сервере. Зависит от типа используемых накопителей (так, SSD значительно превосходят по скорости обычные жёсткие диски), а также от быстродействия процессоров и объёма и типа оперативной памяти.

Объём оперативной памяти и её тип. Этот критерий особенно важен в некоторых случаях — например, при использовании файлового сервера для хранения базы данных 1С. Если оперативной памяти будет недостаточно, пользователи начнут испытывать затруднения при совместной работе с такой базой.

Характеристики сетевой карты. Чем выше её пропускная способность, тем быстрее будет идти обмен данными между файловым сервером и клиентскими устройствами.

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

TL;DR: Вводная статья с описанием разных вариантов хранения данных. Будут рассмотрены принципы, описаны преимущества и недостатки, а также предпочтительные варианты использования.

Зачем это все?

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

Надежно хранить данные в больших объемах, а также выдерживать отказы физических носителей — весьма интересная и сложная инженерная задача.

Хранение данных

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

По способу подключения есть следующие варианты:

Внутреннее. Сюда относятся классическое подключение дисков в компьютерах, накопители данных устанавливаются непосредственно в том же корпусе, где и будут использоваться. Типовые шины для подключения — SATA, SAS, из устаревших — IDE, SCSI.

подключение дисков в сервере

Внешнее. Подразумевается подключение накопителей с использованием некоторой внешней шины, например FC, SAS, IB, либо с использованием высокоскоростных сетевых карт.

дисковая полка, подключаемая по FC

По типу используемых накопителей возможно выделить:

Дисковые. Предельно простой и вероятно наиболее распространенный вариант до сих пор, в качестве накопителей используются жесткие диски
Ленточные. В качестве накопителей используются запоминающие устройства с носителем на магнитной ленте. Наиболее частое применение — организация резервного копирования.
Flash. В качестве накопителей применяются твердотельные диски, они же SSD. Наиболее перспективный и быстрый способ организации хранилищ, по емкости SSD уже фактически сравнялись с жесткими дисками (местами и более емкие). Однако по стоимости хранения они все еще дороже.
Гибридные. Совмещающие в одной системе как жесткие диски, так и SSD. Являются промежуточным вариантом, совмещающим достоинства и недостатки дисковых и flash хранилищ.

Если рассматривать форму хранения данных, то явно выделяются следующие:

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

По реализации достаточно сложно провести четкие границы, однако можно отметить:

аппаратные, например RAID и HBA контроллеры, специализированные СХД.

RAID контроллер от компании Fujitsu

Программные. Например реализации RAID, включая файловые системы (например, BtrFS), специализированные сетевые файловые системы (NFS) и протоколы (iSCSI), а также SDS

пример организации LVM с шифрованием и избыточностью в виртуальной машине Linux в облаке Azure

Давайте рассмотрим более детально некоторые технологии, их достоинства и недостатки.

Direct Attached Storage — это исторически первый вариант подключения носителей, применяемый до сих пор. Накопитель, с точки зрения компьютера, в котором он установлен, используется монопольно, обращение с накопителем происходит поблочно, обеспечивая максимальную скорость обмена данными с накопителем с минимальными задержками. Также это наиболее дешевый вариант организации системы хранения данных, однако не лишенный своих недостатков. К примеру если нужно организовать хранение данных предприятия на нескольких серверах, то такой способ организации не позволяет совместное использование дисков разных серверов между собой, так что система хранения данных будет не оптимальной: некоторые сервера будут испытывать недостаток дискового пространства, другие же — не будут полностью его утилизировать:

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

Storage area network, она же сеть хранения данных, является технологией организации системы хранения данных с использованием выделенной сети, позволяя таким образом подключать диски к серверам с использованием специализированного оборудования. Так решается вопрос с утилизацией дискового пространства серверами, а также устраняются точки отказа, неизбежно присутствующие в системах хранения данных на основе DAS. Сеть хранения данных чаще всего использует технологию Fibre Channel, однако явной привязки к технологии передачи данных — нет. Накопители используются в блочном режиме, для общения с накопителями используются протоколы SCSI и NVMe, инкапсулируемые в кадры FC, либо в стандартные пакеты TCP, например в случае использования SAN на основе iSCSI.

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

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

Network attached storage, или сетевое файловое хранилище, представляет дисковые ресурсы в виде файлов (или объектов) с использованием сетевых протоколов, например NFS, SMB и прочих. Принципиально базируется на DAS, но ключевым отличием является предоставление общего файлового доступа. Так как работа ведется по сети — сама система хранения может быть сколько угодно далеко от потребителей (в разумных пределах разумеется), но это же является и недостатком в случае организации на предприятиях или в датацентрах, поскольку для работы утилизируется полоса пропускания основной сети — что, однако, может быть нивелировано с использованием выделенных сетевых карт для доступа к NAS. Также по сравнению с SAN упрощается работа клиентов, поскольку сервер NAS берет на себя все вопросы по общему доступу и т.п.

Unified storage

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

Software-defined storage — программно определяемое хранилище данных, основанное на DAS, при котором дисковые подсистемы нескольких серверов логически объединяются между собой в кластер, который дает своим клиентам доступ к общему дисковому пространству.

Наиболее яркими представителями являются GlusterFS и Ceph, но также подобные вещи можно сделать и традиционными средствами (например на основе LVM2, программной реализации iSCSI и NFS).

N.B. редактора: У вас есть возможность изучить технологию сетевого хранилища Ceph, чтобы использовать в своих проектах для повышения отказоустойчивости, на нашем практическим курсе по Ceph. В начале курса вы получите системные знания по базовым понятиям и терминам, а по окончании научитесь полноценно устанавливать, настраивать и управлять Ceph. Детали и полная программа курса здесь.

Пример SDS на основе GlusterFS

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

Гиперконвергентные системы

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

Облака и эфемерные хранилища

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

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

Заключение

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

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

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

Выделенный сервер *, на который системный администратор разворачивает операционную систему (Windows или UNIX) и настраивает роль файлового сервера. Это самый дорогой вариант, но он лишен каких либо ограничений.
Решение под ключ. Представляет из себя оборудование, на котором уже установлена своя система с настроенным сервисом хранения данных. Удобен тем, что его можно достать из коробки и начать пользоваться после 10 минут настройки. Минус в достаточно высокой стоимости и некоторых ограничениях (система позволит настроить только то, что предусмотрено разработчиками). Пример решения — synology.
Выделенный сервер, на который устанавливается операционная система - файловый сервер, например FreeNAS. Она заточена только под организацию системы файлового хранения. Этом метод похож на предыдущий, только можно самостоятельно выбрать оборудование и разворачивание займет больше времени.
Внешний жесткий диск с сетевым интерфейсом. Да, в некоторых случаях так тоже можно организовать общее хранилище файлов. А если купить дисковый бокс с возможностью организации RAID, решение еще и будет достаточно надежным.
Любой компьютер пользователя в сети компании. Самый худший вариант, так как при перезагрузке или выключении компьютера пропадает доступ к данным. Более того, пользовательские операционные системы хуже всего рассчитаны на организацию серверов. Но это самый простой и дешевый метод, поэтому он имеет место быть.

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

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

Читайте также: