Данные — основа любого бизнеса. Если место их хранения недостаточно надежно или неспособно обеспечить постоянный доступ, то под угрозой будет практически вся деятельность предприятия.
Конечно, можно и нужно обеспечивать сохранность и доступность информации правильным выбором серверного ПО и грамотной конфигурацией. Но не менее важно и железо — оборудование, которое хранит и обрабатывает данные. Если оно не соответствует потребностям компании, то никакой софт не сделает его достаточно надежным и отказоустойчивым.
В этой статье мы рассмотрим один из подходов к выбору железа для создания корпоративного облачного хранилища.
Облачная инфраструктура имеет ряд преимуществ:
Возможность быстрого масштабирования. Увеличение ёмкости и вычислительной мощности хранилища достигается с помощью быстрого подключения дополнительных серверов и СХД. Особенно это актуально для компаний, у которых нагрузка на облако предполагается нерегулярной.
Снижение расходов. Облако позволяет создать единый центр, в котором будут выполняться все вычислительные процессы, в то время как для увеличения дискового пространства будет достаточно простого приобретения накопителей, без необходимости организации установки новых серверов.
Упрощение бизнес-процессов. Облачное хранилище, в отличие от локального, подразумевает возможность постоянного доступа к нему. Это значит, что с файлами можно работать в любое время суток из любого места. Сотрудники смогут получать необходимую для работы информацию проще и быстрее, станет возможным организовать удаленные рабочие места.
Повышенная отказоустойчивость. Вполне очевидно, что, если данные хранятся на нескольких серверах, то их сохранность в случае технических проблем будет выше, чем если бы они находились только на одной машине.
Сейчас на рынке есть множество публичных облачных сервисов. Для многих малых и средних компаний они действительно становятся хорошим выбором, особенно если речь идет об услугах с оплатой только за использованные ресурсы либо проведении тестирования сервиса. Однако свое облачное хранилище также дает ряд преимуществ. Оно придется очень кстати, если:
Деятельность компании налагает ограничения на местоположение серверов. Казахстанские гос. учреждения, а также организации, занимающиеся обработкой персональных данных, по закону обязаны хранить всю свою информацию на территории РФ. Соответственно, арендовать заграничные серверы для них не представляется возможным, да и в целом очень нежелательно доверять деликатную информацию подрядчикам. Создание частного хранилища поможет использовать все преимущества облака без нарушения правовых норм.
Необходимо полное управление политиками безопасности. Как устроена защита данных в сервисах 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 он является владельцем. Главным недостатком механизма является то, что, во-первых, не так просто определить, какие файлы принадлежат конкретному пользователю, а во-вторых, файлы, созданные администраторами, не будут включены в квоту. Механизм квот редко используется на практике, его практически полностью заместил File Server Resource Manager, впервые появившийся в Windows Server 2003 R2.
Этот компонент Windows Server позволит квотировать дисковое пространство на уровне конкретной папки. Если вы выделяете для сотрудников персональные домашние каталоги на файловых серверах, а также выделенные папки для общих документов отделов, то FSRM — наилучший выбор.
Конечно, квотирование само по себе не увеличит объем файлового хранилища. Но пользователи, как правило, лояльно относятся к справедливому (равному) делению ресурсов, а в случае нехватки готовы преодолеть небольшие бюрократические процедуры для расширения дискового пространства.
Квоты помогут и от перегрузки сервера в случае случайного размещения пользователем большого объема информации. По крайнее мере, это не скажется на других сотрудниках или отделах.
Кроме того, FSRM включает в себя механизм «скрининга» (фильтрации) файлов, которые можно сохранять на сервере. Если вы уверены в том, что mp3- и avi- файлам не место на файловом сервере, то можно запретить их сохранения средствами FSRM.
Обычные файлы хорошо поддаются сжатию средствами 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://habr.com/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 вы можете узнать из этой статьи.
ОБРАТИТЬСЯ К КОНСУЛЬТАНТУ ЗА ПОМОЩЬЮ В ПОДБОРЕ СЕРВЕРА
