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

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

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

Почему облако?

Облачная инфраструктура имеет ряд преимуществ:

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

Почему своё?

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

• Деятельность компании налагает ограничения на местоположение серверов. Российские гос. учреждения, а также организации, занимающиеся обработкой персональных данных, по закону обязаны хранить всю свою информацию на территории РФ. Соответственно, арендовать заграничные серверы для них не представляется возможным, да и в целом очень нежелательно доверять деликатную информацию подрядчикам. Создание частного хранилища поможет использовать все преимущества облака без нарушения правовых норм.
  
  
• Необходимо полное управление политиками безопасности. Как устроена защита данных в сервисах Microsoft или Amazon, точно узнать невозможно. Полностью обезопасить информацию так, как вы считаете это необходимым, можно только в собственном облаке.
  
  
• Настройка оборудования под себя. При аренде приходится работать с тем, что дает поставщик. Однако имея в распоряжении собственные серверы, можно сконфигурировать их на под решение конкретных задач именно для вашего бизнеса, а также использовать то ПО, которым в совершенстве владеет ваша IT-команда.

Выбор оборудования

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

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

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

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

В среднем для работы с текстовыми файлами, презентациями, PDF и небольшим количеством изображений нужно в среднем 10-15 Гб на сотрудника. Для работы с большими объемами высококачественных картинок и фотографий нужно увеличить минимум до 50-100 Гб, а то и больше. Потребности персонала, занимающегося обработкой видео и аудио, могут достигать нескольких терабайт на человека. В ряде случаев, например, при использовании крупных корпоративных программных пакетов с поддержкой версионности проектов, речь может идти и о 10 терабайтах на одного пользователя облака. Не забудьте учесть емкость под резервные копии файлов и непредвиденные нужды компании.

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

Также необходимо определиться с вычислительной мощностью. Если вы создаёте облачное хранилище на базе нескольких серверов, то рекомендуется подбирать идентичные или очень близкие конфигурации. Это несколько упростит управление распределением нагрузки. И вообще лучше не делать ставку на одну мощную машину, комплектуя её дорогим процессором и оперативной памятью, а купить подешевле 2-3 машины. Почему?

Если ваше хранилище будет только принимать и отдавать статичные файлы, без возможности их запуска, то мощность процессора не слишком важна. Поэтому лучше не гнаться за количеством ядер и выбрать модель с хорошим «тактом». Из недорогих вариантов неплохо подойдут процессоры Intel Xeon серии E56XX с 4 ядрами, из более дорогих моделей можно порекомендовать машины на Intel Core i5.

Примеры моделей серверов

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

Dell PowerEdge T110. Сервер оснащен процессором Intel Core i3 2120 с всего двумя ядрами, но зато каждое из них обладает неплохой тактовой частотой в 3,3 ГГц, что для нашего облака важнее. Начальная конфигурация оперативной памяти не очень велика — 4 Гб, однако может быть расширена до 32 Гб. Сервер поставляется в двух комплектациях — без предустановленного жесткого диска или с HDD-накопителем емкостью в 1 Тб и интерфейсом SATA.

Lenovo ThinkServer RS140. Имеет мощный процессор Intel Xeon E3 с четырьмя ядрами по 3,3 Ггц каждое. Оперативная память «из коробки» — 4 Гб, плюс еще четыре слота для ее расширения. Также в комплект входят два жестких диска по 1 Тб с SATA-интерфейсом.

HP ProLiant ML10 Gen9. Во многом схож с описанной выше моделью — всё тот же Intel Xeon E3 и два терабайтовых HDD. Основное отличие в оперативной памяти — сервер HP имеет две пластины по 4 Гб каждая.

Достаточно ли места для хранения файлов?

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

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

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

Дисковые квоты NTFS

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



Включив квоты для тома, вы можете ограничивать объем файлов, сохраняемых каждым пользователем. В квоту пользователя попадают файлы, для которых на уровне NTFS он является владельцем. Главным недостатком механизма является то, что, во-первых, не так просто определить, какие файлы принадлежат конкретному пользователю, а во-вторых, файлы, созданные администраторами, не будут включены в квоту. Механизм квот редко используется на практике, его практически полностью заместил File Server Resource Manager, впервые появившийся в Windows Server 2003 R2.

File Server Resource Manager

Этот компонент Windows Server позволит квотировать дисковое пространство на уровне конкретной папки. Если вы выделяете для сотрудников персональные домашние каталоги на файловых серверах, а также выделенные папки для общих документов отделов, то FSRM — наилучший выбор.



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

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

Кроме того, FSRM включает в себя механизм «скрининга» (фильтрации) файлов, которые можно сохранять на сервере. Если вы уверены в том, что mp3- и avi- файлам не место на файловом сервере, то можно запретить их сохранения средствами FSRM.

Компрессия NTFS

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

Дедупликация

Windows Server 2012 включает в себя возможность дедупликации данных, расположенных в томе NTFS. Это достаточно продвинутый и гибкий механизм, сочетающий в себе как дедупликацию с переменной длинной блока, так и эффективную компрессию сохраняемых блоков. При этом для разных типов данных механизм может использовать разные алгоритмы сжатия, а если сжатие не эффективно — не использовать её. Такие тонкости недоступны традиционному сжатию средствами NTFS.

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

Оценить потенциальную прибавку свободного места можно утилитой ddpeval. На типичном файловом сервере экономия составляет 30-50%.

Производительность файлового сервера

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

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

Если посмотреть на статистику Perfmon, средняя скорость чтения/записи для 150-200 пользователей достаточно низка и составляет всего лишь несколько мегабайт в секунду. Более интересны пиковые значения. Но следует иметь в виду, что и эти пики ограничены скоростью сетевого интерфейса, а для обычного сервера это 1 Гбит/с (т.е. 100 Мб обмена с дисковой подсистемой).



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

Для 150-200 сотрудников показатели достаточно скромны — 10-20 операций ввода вывода в секунду с дисковой очередью в пределах 1-2.



Этим требованиям удовлетворит любой массив из стандартных SATA дисков.

Для 500-1000 активных пользователей количетсво операции подскакивает до 250-300, а дисковая очередь достигает 5-10. Когда очередь достигает этой величины, пользователи могу заметить, что файловый сервер «подтормаживает».



На практике для достижения производительности в 300 IOPS вам уже потребуется массив как минимум из 3-4 дисков типичных SATA-дисков.

При этом следует учесть не только «сырую производительность», но и задержку, вносимую работой RAID-контроллера — так называемую RAID penalty. Эта тема доступно разъяснена в статье https://habrahabr.ru/post/164325/.

Для определения необходимого количества дисков используем формулу:

Total number of Disks required = ((Total Read IOPS + (Total Write IOPS*RAID Penalty))/Disk Speed IOPS)

RAID-5 с penalty на запись в 4 операции, профилем чтение 50%, запись 50%, скоростью диска в 75 IOPS, целевая производительность в 300 IOPS:

(300*0,5 + (300*0,5*4))/75 = 10 дисков.

Если у вас много активных пользователей, то вам потребуется ёмкий сервер или более производительные диски, такие как SAS со скоростью вращения 10 000 RPM.

Скорость сетевого интерфейса
Низкая скорость сетевого интерфейса — одна из причин задержек при работе с файловым сервером. В 2016 году сервер с 100 Мбит/с сетевой картой — нонсенс.

Типичный сервер оборудован сетевой картой со скоростью 1 Гбит/с, но и это ограничивает дисковый обмен скоростью около 100 Мб/с. Если в сервере несколько сетевых карт, то вы можете объединить их (агрегировать) в один логический интерфейс для увеличения как производительности, так и доступности облака. Хорошая новость в том, что для файлового сервера («много клиентов обращаются к одному серверу») агрегация работает хорошо.

Владельцы серверов HP могут использовать фирменную утилиту HP Network Configuration Utility



Если вы используете Windows Server 2012, то более простым и надежным способом будет использование штатного средства NIC Teaming.



Подробнее об этой настройке и нюансах использования ее в среде Hyper-V вы можете узнать из этой статьи.