В статье идёт речь о методике построения сетевого хранилища на базе обычного сервера, приводятся нюансы, которые желательно знать и даются рекомендации, в том числе из личного опыта.
Статей вроде "Давайте сделаем сетевое хранилище (NAS) своими руками" написано предостаточно. При этом многие из них выглядят примерно "...нашли интересный дистрибутив, переписали на флешку, вставили в компьютер и радуемся жизни«.При этом упускаются такие интересные моменты как определение роли (проще говоря, для чего это нужно), подбор компонентов, тестирование, особенности будущей эксплуатации и так далее.
В этот раз мы пойдём немного другим путём и сначала опишем, зачем это нужно, потом подумаем, как это будем делать и на что обратить внимание. Попробуем, хоть и «галопом по Европе» обозначить ключевые моменты подобного строительства.
Данная статья носит ознакомительный характер и не претендует на полное пособие по построению сетевых хранилищ (NAS) на любые случаи жизни.
NAS (Network Attached Storage) — один из вариантов системы хранения данных (СХД). Фактически это узкоспециализированный файл-сервер, чьё программное обеспечения (а порой и аппаратное) заточено исключительно на операции обмена и сохранения данных.Обычно работает через стек протоколов TCP/IP, хотя бывают и исключения.
Традиционно NAS поддерживает передачу данных по протоколам файлового доступа: SMB (CIFS), NFS, APF и некоторым другим. Но в последнее время в NAS стали встраивать и поддержку протоколов блочного доступа, например, iSCSI.
Примечание. Строго говоря, работа в режиме блочного доступа — это прерогатива другой группы устройств — SAN (Storage Area Network). Фактически, современный NAS с функциями блочного доступа — это уже гибридное устройство SAN/NAS. Но несмотря на красивое симметричное написание, называть его всё равно будем NAS. Так короче и привычнее.
Есть расхожее мнение, что на создание NAS своими силами решаются энтузиасты-одиночки, которые нашли старый сервер и не знают, что с ним сделать. Однако среди сборщиков собственных NAS довольно много и суровых прагматичных людей, которые точно знают, чего хотят от новой системы и как это будут реализовывать. Какие мотивы двигают людьми, покупающими или арендующими сервер, чтобы сделать из него сетевое хранилище?
Во-первых, это желание построить систему под себя. У большинства известных дистрибутивов для построения NAS — открытый исходный код, доступный для любых проверок и модификаций.
Есть возможность адаптации не только через установки сторонних plugins, но и путём прямого изменения программного обеспечения под свои нужды. Например, добавить агент системы мониторинга и так далее.
Во-вторых, это широкие возможности модернизации аппаратной части. Такие возможности, как заменить процессоры на более мощные, заменить RAID-контроллер или HBA, установить сетевой адаптер — лишь бы поддерживало программное обеспечение и драйверы. Всё это может быть выгодней, чем покупать готовое закрытое устройство.
Цены на оборудование постоянно меняются, поэтому нет смысла приводить конкретные суммы. Но стоит отметить, что готовый NAS от известного производителя на 12 HDD с мощным процессором обойдётся не так уж дёшево. Поэтому приобрести для своих нужд отличный сервер от известного бренда, установить на него проверенный дистрибутив — для многих случаев — это вполне конкурентное решение.
Примечание. С готовыми NAS даже от известных производителей тоже порой приходится повозиться при эксплуатации. Обновить прошивку, связаться с техподдержкой для решения рабочих вопросов, а то и сдать по гарантии. Вариант «купил, поставил, и забыл» — для большинства производителей это совсем необязательная опция.
Очень важный аспект — это получение практического опыта. Можно с уверенностью сказать, что построение сетевого хранилища своими руками даёт шанс гораздо лучше разобраться в системах хранения данных в целом. Даже отучившись на курсах того или иного вендора, можно так и не узнать тех или иных нюансов, которые, что называется, «плавают на поверхности». Так же при разработке никогда не будут лишними знания о том, как выглядит реальное «железо», как взаимодействуют компоненты и так далее.
Во-первых, творческий процесс затягивает. Уже давно пора сдавать в эксплуатацию, а тут не провели ещё тысячу первый тест, не переписали в литературном стиле главу в документации и так далее... :)
Во-вторых, конечно, нужна определённая уверенность в своих действиях. Когда речь идёт о проверке идеи на «старом железе», не так давит груз ответственности. Но когда приходится потратить живые деньги и потом доверить «самоделке» свои данные, иногда бывает сложно на это решиться.
Дальше пойдёт речь об основных этапах создания и о нюансах, которые иногда упускают при построении сетевого хранилища для собственных нужд.
Для этого рассмотрим два варианта использования NAS: в роли самостоятельного файл-сервера и в роли СХД.
Обычно это вспомогательный файл-сервер для разгрузки основного корпоративного сервера. Зачастую это связано ограниченными функциями при интеграции в Active Directory.
Несмотря на то, что большинство современных дистрибутивов открытых систем худо-бедно поддерживают возможность раздачи прав на основе взаимодействия с AD, более тонкие «сущности», такие, как групповые политики, использование специального ПО для мониторинга и безопасности для Windows среды — на платформе NAS, скорее всего, будут недоступны.
Здесь могут преследоваться такие цели как:
Расширение дискового пространства серверов. Проще говоря, стало мало места — добавили сетевое хранилище и на серверах подключили новые тома, например, по iSCSI.
Дополнительный ресурс для резервного копирования. Например, когда объём данных не помещается на ленточные ресурсы, часть некритичных да бизнеса данных сохраняют на сетевом хранилище. И это только один из примеров комбинирования NAS и ленточной библиотеки.
Вспомогательная СХД для виртуальной системы. Далеко не всегда требуется размещать те или иные виртуальные машины на скоростных ресурсах. Иногда вполне достаточно простого NAS c томами, подключёнными по протоколам NFS или iSCSI.
При создании NAS есть два пути: воспользоваться готовым специализированным дистрибутивом или создавать свой вариант на базе универсальной операционной системы.
Если есть желание досконально разобраться во всех тонкостях программного и аппаратного обеспечения и создать уникальную систему под себя с максимально гибкими настройками — имеет смысл взять некий OpenSource дистрибутив, например, одну из сборок Linux, FreeBSD, Open Indiana и, тщательно его переработав, сделать платформу для собственного сетевого хранилища.
Если есть желание сразу запустить и начать работать — стоит воспользоваться готовым популярным дистрибутивом для NAS.
Тот же совет подходит для желающих двигаться от простого к сложному — для начала используйте готовый дистрибутив, чтобы получить первоначальное представление и потом двигаться дальше.
Среди готовых дистрибутивов есть три наиболее известных направления:
на основе FreeBSD — FreeNAS, NAS4Free, ZFSGuru;
на основе Solaris — NexentaStor;
на основе Linux — Open-E, OpenMediaVault, RockStor.
Основной «изюминкой» дистрибутивов FreeNAS, NAS4Free, ZFSGuru, а также NexentaStor и Open-E является поддержка той или иной вариации файловой системе ZFS.
RockStor — экспериментальный дистрибутив, предполагающий использование Btrfs.
OpenMediaVault — заслуженный известный дистрибутив на базе Debian, поддерживающий файловые системы: XFS, JFS, ext2/ext3/ext4 — полная поддержка, NTFS и FAT32 — в режиме «чтение/запись». Следует учесть, что все дистрибутивы с ZFS предъявляют достаточно высокие требования к аппаратному обеспечению.
Народная примета: Если на сервере меньше 16GB RAM — возиться с ZFS особого смысла нет.
Ещё один важный нюанс — откуда планируется запускать саму операционную системы. В этом случае есть два варианта:
система каждый раз стартует с временного носителя, например, с USB-флешки или при загрузке по сети, и потом образ разворачивается оперативной памяти;
стандартная установка на постоянный жёсткий диск.
Например, NAS4Free может быть установлен как на сменный носитель, так и на жёсткий диск, а для OpenMediaVault лучше выбрать жёсткий диск из-за swap раздела. И тут снова вопрос, а есть ли возможность установить жёсткий диск или SSD для системы? После того, как мы разобрались со своими пожеланиями, переходим к выбору аппаратного обеспечения.
Стоит отметить, что большинство современных OpenSource дистрибутивов поддерживает широкий спектр серверных конфигураций. Но до сих пор существуют некоторые пробелы при поддержке оборудования. Ниже идёт описание таких «запланированных сюрпризов».
Важно! Надо понимать, что не получится взять совсем дешёвый сервер минимальной конфигурации и путём установки сверхэкономичного дистрибутива получить высокопроизводительную СХД.
Некоторые RAID-контроллеры, HBA и сетевые карты могут не поддерживаться в том или ином дистрибутиве. Симптом внешне выглядит примерно так — загружается дистрибутива, например, с флешки, а диски система «не видит».
Иногда вопрос решается перепрошивкой Firmware, иногда — установкой свежего драйвера от производителя контроллера, иногда — переходом на новую или другую ветку дистрибутива. В самых тяжёлых случаях не помогают ни сторонние драйверы, ни за замена прошивки.
Проблема примерно та же что и в случае с HBA и RAID-контроллерами. Можно побороться, но иногда можно столкнуться с полным отсутствием поддержки.
Отдельно стоит поговорить о характеристиках передачи данных. Нужно точно представлять, не только какая сеть у вас есть сейчас, но и какая будет в будущем.
Например, если сейчас используется стандарт Gigabit Ethernet на витой паре, а в дальнейшем планируется использовать 10 Gigabit Ethernet SFP (оптоволокно), то нужно проработать вопросы совместимости и в том, и в другом случае.
Как было сказано выше, одна из весомых причин для построения своего сетевого хранилища — возможность его модернизации. Но если возможности для этого уже урезаны производителем оборудования — стоит поискать другой вариант материнской платы или серверной платформы.
Возможность установки в корпусе дополнительных компонентов
Примерно, тот же самый вариант, что и выше, но тут приходится сталкиваться ещё и с отсутствием места для крепления, нехваткой разъёмов питания и так далее.
Примерно, тот же самый вариант, что и выше, но тут приходится сталкиваться ещё и с отсутствием места для крепления, нехваткой разъёмов питания и так далее.
Берём описание конфигурации выбранного сервера, включая чипсет, HBA или RAID-контроллер, сетевой адаптер, etc., и перечень поддерживаемого оборудования в выбранном дистрибутиве и сверяем с тем, что есть в спецификации сервера.
Совет. Иногда проще добавить заведомо поддерживаемый компонент в конфигурацию сервера, например, HBA или сетевую карту, чем долго и нудно выяснять, поддерживается ли модель, встроенная в материнскую плату, или нет.
Если не понятно, поддерживается данное устройство или нет, то идём на сайт производителя и уточняем, есть ли драйвер для данной системы. Например, для NAS4Free подходят драйверы от производителя оборудования для соответствующей версии FreeBSD.
А Если совсем всё плохо — выбираем другой дистрибутив или другую конфигурацию сервера.
Важно! Все щекотливые моменты совместимости крайне желательно проработать до покупки оборудования путём тщательного анализа спецификаций. Чтобы потом не уговаривать дистрибьютора дать возможность что-то поменять или вернуть, а также чтобы не докупать отсутствующее.
Допустим, уже закупили оборудование с тщательно проработанной конфигурацией.
Первая проверка — на совместимость. В первую очередь на совместимость аппаратного и программного обеспечения. Для тех, кто решил воспользоваться готовым дистрибутивом, это просто — скачиваем свежую версию, устанавливаем его на сервер и смотрим что из оборудования «увиделось». Если заработало всё, что хотели — значит переходим к тестированию на производительность. Если нет — решаем вопросы совместимости.
Для проверки на производительность нам понадобится ещё один компьютер желательно с более мощными характеристиками, чтобы протестировать NAS без оглядки на производительность других компонентов обмена данными. Сразу стоит отметить, что тестирование — это целая наука. И далеко не всегда расчётные и ожидаемые значения соответствуют тому, что получается на практике. Поэтому прислушаемся к совету Козьмы Пруткова «невозможно объять необъятное» и выборочно остановимся на интересных нюансах.
Самый простой вид теста — просто копируем набор файлов и засекаем время. Рекомендуется попробовать скопировать очень большой файл фиксированного размера и набор очень мелких файлов того же суммарного объёма. То есть взяли хороший мощный компьютер, примонтировали сетевой ресурс на нашем NAS, засекли время и запустили копирование. Отметили время по завершению. Также следует обратить внимание на такие показатели как загрузка процессора, использование RAM и так далее.
В самых простых случаях можно попробовать просто запустить команду top и посмотреть нагрузку. Для более сложных случаев существуют специальные средства. Стоит учесть, что утилиты, при помощи которых мы наблюдаем нагрузку на процессор, память, скорость обмена по сети сами потребляют системные ресурсы. Для того, чтобы получить полную картину нужно провести контрольные замеры скорости копирования с выключенными средствами наблюдения за системой.
Второй вид тестов — при помощи специализированной программы, например, выполняем различные сочетания.
Методика тестирования — это очень обширная тема, на которую было опубликовано много материалов, остается только выбрать самый удобный способ для себя.
Внимание!Далеко не всегда заявленная скорость обмена по сети соответствует скорости передачи реальных данных в виде файлов.
Поэтому рекомендуется провести тестирование не только на создаваемом NAS, но и на других системах (компьютерах), с целью получить некое усреднённое значение. Тогда легче определиться с результатами в данной среде эксплуатации.
По результатам тестирования может быть три варианта:
Характеристики соответствуют ожидаемым условиям для этой среды эксплуатации.
Характеристики отстают от ожидаемых, но известно узкое место, которое необходимо «расширить». Например, нужен кэширующий SSD.
Характеристики отстают от ожидаемых, но узкое место определить не удалось. Например, все контрольные точки: процессор, память, дисковая подсистема, сетевая подсистема и т. д. — работают в режиме, не дотягивающем до нормальной нагрузки.
Третий случай самый сложный. Наиболее частая рекомендация, которая может помочь — попробовать другое программное обеспечение (другой дистрибутив). Иногда помогает установка другого драйвера на HBA или RAID-контроллер, например, свежий драйвер от производителя. Помимо тестирования на производительность существует ещё тестирование на отказоустойчивость. Например, как поведёт себя RAID (аппаратный или программный) при искусственном сбое диска, сохраняется ли связь на дублированных сетевых каналах при аварии на одном из них и так далее.
Как это часто бывает — получили более-менее приличные данные при тестировании и бегом стали внедрять. И в итоге получаем кучу неприятных «сюрпризов», которые не проявлялись при тестировании.
Как этого избежать? Только путем постепенного ввода в эксплуатацию. Самое главное — все это время пристально наблюдать за новым оборудованием и тщательно контролировать выбранные параметры.
Например, не переносим все выбранные виртуальные машины на новый том iSCSI, а только одну. И проверяем её работу. Если всё нормально, через неделю можно перенести ещё одну. Ещё через две недели — ещё две и так далее.
Основное достоинство такого подхода заключается в том, что появляется время вовремя избавится от этих самых «сюрпризов» и запускать на полную мощность уже проверенную и предсказуемо работающую систему. Кроме того, появляется время написать инструкции, уточнить регламенты, проще говоря, подогнать документальную базу под новые реалии.
Разумеется, рассмотреть все аспекты в рамках одной статьи невозможно. Но нам удалось познакомить вас с основными нюансами, которые стоит учитывать при строительстве сетевых хранилищ.
Устал? Запутался? Жизнь кажется бессмысленной? Затрудняешься с выбором сервера? Пиши нам!
Спасите меня!
