Поднимаем идеальный файловый сервер

Крис Касперски

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

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

Маленький сервачок и большой сервер

Внешние жесткие диски с Ethernet-интерфейсом активно теснят полноценные файловые сервера, воздвигаемые на базе выделенных PC, встречаясь не только в домашних сетях, но и в офисах самых разных контор. Достоинства: низкая цена (особенно в пересчете на один гигабайт), высокая масштабируемость (закончилось дисковое пространство? просто покупаем еще один винт и втыкаем в сетевой порт), относительная безглючность (работают они под сильно урезанным Linux'ом, который, как известно, не зависает), предельно низкое энергопотребление (а, следовательно, более дешевая UPS, обеспечивающая их бесперебойным питанием, в отсутствии которого говорить о сохранности информации можно только в переносном метафизическом смысле), неприхотливость (внешние жесткие диски не требуют никакого обслуживания), невосприимчивость к большинству хакерских атак. Плюс ко всему вышеперечисленному: компактность (очень важное обстоятельство для мини-офисов и домашних сетей).

Недостатки: полная неуправляемость (внешний диск представляет собой «вещь в себе», работающую на автопилоте и не желающую подчиняться воле администратора), невозможность запуска антивируса внутри «коробки» (а вне «коробки» антивирус съедает всю пропускную способность локальной сети), практически непреодолимые трудности с обновлением ядра и наложением заплаток на него и на Самбу (Linux, конечно, штука хорошая, но дыры в нем все-таки обнаруживаются, и если их не латать, сервачок может заразиться вирусом или руткитом, который способен привести к краху системы; администратор будет вынужден разобрать «коробку», вытянуть оттуда жесткий диск и подключить его к PC – если, конечно, разработчики последнего не отодрали интерфейсный разъем, что частенько случается), низкая производительность при одновременном подключении нескольких десятков клиентов. В эту же корзину попадают аппаратные отказы самого диска (ведь RAID на базе внешних жестких дисков на x86 никак не организуешь), сложности резервирования и поиска информации, связанные с отсутствием служб журналирования и индексирования, которые опять-таки не работают через Ethernet. Про толковое разграничение доступа мы вообще не говорим.
Несмотря на это, внешние жесткие диски – не самый плохой вариант.

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

Воздвигнуть сервер можно и на основе PC. Особенно, если это – сервер файловый. Ему ни к чему большие процессорные мощности и SMP, избыток оперативной памяти превращается в бесполезный балласт, а скоростные RAID-контроллеры упираются в бутылочное горлышко тонкой витой пары. Список ненужных вещей можно продолжать еще долго, поэтому лучше остановиться на формулировке: «нетребовательность к аппаратной конфигурации». Подойдет любое (почти любое!) железо, что есть под рукой. Правда, не обойтись без знания кое-каких тонкостей.

Верность 100-мегабитке

Национальным стандартом де-факто стал 100-мегабитный Ethernet. Гигабитый уже давно не новость, но большого распространения он так и не получил. Что изменяет переход на гигабитные каналы? А ничего! Диск — быстрее, сеть — медленнее. Да, конечно, в гигабитный канал вмещается намного больше данных, и в крупных сетях разница все-таки видна. Однако это должна быть действительно крупная и сильно загруженная сеть, иначе выигрыш в производительности можно зафиксировать только с помощью хронометра. Но крупные сети строятся совсем по другой схеме (разбиваются на сегменты, и администраторы заботятся о балансировке нагрузки).

В 99% случаях правильно спроектированная сеть не испытывает острой потребности в гигабитных каналах – а неправильной и гигабита будет мало! Учитывая, что гигабитная инфрастуктура требует определенных инвестиций как в оборудование, так и в топологию самой сети, целесообразность ее использования — предмет острых дискуссий, которые мы обойдем стороной, оставшись верны старому доброму 100-мегабитному Ethernet'у.

С матрицей и без

Файловому серверу позарез нужна матрица из нескольких дисков, объединенная в общий RAID. Какой же это файловый сервер без RAID'а? И зачем тогда вообще нужны матрицы? Такие мысли есть у народа. Ошибочность этого мнения дорого стоит. RAID'ы они, мягко говоря, для другого предназначены:

• а) для работы с файлами/разделами очень большого размера (ныне неактуально; монтируемые файловые системы и огромные объемы современных винчестеров делают свое дело — и чем дальше, тем больше);
• б) для увеличения пропускной способности дискового ввода/вывода; в первую очередь это актуально для баз данных и станций цифрового видео-монтажа;
• в) для серверов, критичных к отказу в обслуживании, с окном восстановления меньше часа или даже вовсе без такового (тот же самый функционал обеспечивает программный RAID плюс hot-plug на бюджетном SATA).

RAID'ы (в общем случае) практически не уменьшают вероятности потери данных, поскольку отказ жесткого диска не единственная (и не самая частая) причина аварии. Более того, в 9 случаях из 10 винчестер выходит из строя не сразу, а постепенно. Диагностические утилиты позволяют предвидеть возможный выход из строя за несколько дней, недель, а то и месяцев. К тому же RAID'ы все равно не отменяют необходимость резервирования (поскольку не предотвращают логические разрушения, хакерские и вирусные атаки), а если у нас есть свежий бэкап — так ли нам нужен RAID?

Дешевые RAID'ы (особенно те, что встроены в материнскую плату) — весьма вредоносная штука. Они содержат множество ошибок, приводящих к возможным потерям данных и славятся внезапными отказами, а найти плату с совместимым или идентичным RAID'ом не так-то просто. Внешние RAID'ы (контроллеры, вставляемые в слот) более надежны, однако бюджетные модели все равно глючат, а стоимость дорогих соизмерима со стоимостью сервера в целом. Смысл?!
А как насчет программного RAID'а?! Идея, конечно, заманчивая, но винчестеры, посаженные на разные порты контроллера, дадут намного больший выигрыш в производительности, если файлы, запрашиваемые пользователями, равномерно распределены между ними. Так что, чем больше у нас винчестеров, необъединенных в матрицу, тем выше производительность, – реально выше, а не по хронометру (хинт: винчестеры медленно ищут файлы, но быстро их читают, а потому параллельный RAID не увеличивает производительности, тогда как пара независимых жестких дисков — пожалуйста).

Скупой платит дважды

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

Всякий раздел изначально обречен на неуклонную деградацию производительности, и под NTFS еще нет дефрагментаторов, способных восстановить больного на 100%. Единственная мера — реформат с повторной заливкой файлов, временно сохраненных в другом месте. Но это радикальный вариант.

Замедлить темпы падения производительности (Крис, ты прямо как на пленуме ЦК КПСС выступаешь - Прим. ред.) помогает правильный выбор размера кластера. Больше — значит, лучше. Конечно, с увеличением размера кластера возрастают и потери дискового пространства, так как NTFS не умеет использовать пустые хвосты кластеров (UFS, поддерживаемая FreeBSD, – умеет). Но дисковое пространство стоит копейки, а низкая производительность компьютера оборачивается низкой производительностью труда, вылетая в десятки и даже тысячи рублей.

Возврат к первобытнообщинному строю

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

Бедный администратор! Он всю неделю планировал систему разграничения доступа. Ага, Маша и Катя — они у нас в бухгалтерии, и потому члены одной группы (вообще говоря, они лесбиянки и работают попеременно то с одного, то с другого компьютера, а чаще всего – вообще не работают, а ищут себе любовниц на love.mail.ru). А вот Лена уже давно не… В смысле, она шарит в компьютерах, web-дизайне и пишет движок для сайта компании на PHP. Зачем ей доступ к файлам Маши и Кати?! Выделим ее в отдельную группу!

Теперь Борис (он у нас юрист) хочет видеть на сайте компании красивые графики, визуализирующие отчетность Маши с Катей. Что делает Лена? Правильно, пинает администратора, чтобы он ей предоставил доступ к файлам. То же самое делает и Борис. В результате, рано или поздно мы приходим к полному уравнению в правах с незначительными исключениями для администратора.

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

Конечно, понятие конфиденциальности никто не отменял, и далеко не всем сотрудникам дозволено видеть файлы своих соседей. В теории. На практике же, если в компании завелся вредитель, то он их увидит, даже если администратор воздвигнет многоступенчатую систему защиты. Если же вредителей нет — от кого нам тогда защищаться? Вопрос риторический, четкого ответа не имеющий. Умные администраторы отличаются от глупых тем, что не занимаются самодеятельностью, а раздают сотрудникам права, спущенные вышестоящим руководством, которому и приходится отдуваться за все разборки Маши, Кати, Лены и Бориса.

Квоты

И все-таки — кто увел наш любимый чайник? Уже второй день весь отдел без чая. О какой производительности труда тут может идти речь? Наглядное свидетельство того, что если кресло не привязать цепью, стоит только оторвать от него свой зад, как опускать обратно будет уже некуда. Потому как кресло кто-то стащил. Разбирайся потом, кто. Точно так и с дисковым пространством. В отличие от разграничения доступа, дисковые квоты — великое дело!

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

В чем проблема? А проблема в резервировании, обычно осуществляемом на DVD, объем которого намного меньше объема жестких дисков, и потому сохранение всех файлов сервера вылетает в копеечку, способствуя разорению фирмы. С другой стороны, объем реально нужных файлов не так уж и велик. Главное — не резервировать всякий мусор. А то у Маши новая супер-пупер мегапискельная камера, да еще и с записью видео.

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

Игра теней

Как лучше всего проводить резервирование? Разумеется, по расписанию. Когда все пользователи ушли, закрыли все файлы, и ничто не мешает их копированию (файлы, открываемые на запись, обычно блокируются). Вот только нереально это. Кто-то открыл кучу файлов и ушел домой, оставив компьютер включенным. Или фирма работает в три смены. Да мало ли еще что…

Чтобы разрешить проблему, в Win2k3 реализовано так называемое «теневое копирование» (shadow copies). Если говорить просто — это фоновое копирование, осуществляемое на секторном уровне (вообще-то, кластерном, но кого заботят такие мелочи) и работающее в тесном взаимодействии с NTFS. Копируются даже файлы, открытые на запись и заблокированные от совместного чтения.

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

Оборонная инициатива ABE

Аббревиатура ABE расшифровывается как Access Based Enumeration. Это такая секьюрная фича, стоящая на страже безопасности данных. Как и следует из ее названия, ABE позволяет скрывать сам факт существования разделяемых ресурсов от определенных групп пользователей, включая анонимусов (то есть, всех праздношатающихся хакеров).

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

С другой стороны, когда пользователь не видит ресурсов, к которым он не имеет прав доступа, он не нервничает и не задает глупых вопросов администратору (типа: «а почему у меня не открывается папка TopSecret?»). Так что использование ABE даже в мирных целях весьма перспективно.

Заключение

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

INFO

• Подробнее о теневом копировании можно прочитать в статье «Движение в тени», опубликованной в X_03_2008.
• ABE позволяет администратору скрывать хранящиеся на общедоступных ресурсах папки и файлы от тех пользователей, которые не имеют разрешений на доступ к ним на уровне NTFS.
• С помощью политики дисковых квот можно ограничить объем дискового пространства, занимаемого данными пользователя на томе NTFS, и определить реакцию системы на превышение пользователем своей квоты или на достижение им заранее определенного «порога выдачи предупреждений».
• Если поднимаешь файловый сервер на базе Win2k3, не забудь в свойствах сетевого подключения открыть свойства File and Printer Sharing for Microsoft Networks (службы доступа к файлам и принтерам) и отметить пункт Maximize data throughput for file sharing.

WWW

Об особенностях использования ABE можно прочить в блоге blogs.microsoft.co.il.