Поднимаем идеальный файловый сервер
Крис Касперски
Администраторы накопили огромный опыт по воздвижению и эксплуатации «бюджетных» файловых серверов, среди которых с большим отрывом лидируют сервера на базе Win2k3, ставшим стандартом де-факто. Никсы в этой роли смотрятся недостаточно убедительно, доставляя техническому персоналу кучу проблем. Впрочем, Win2k3 тоже не идеален, и чтобы раскрыть его потенциал, а заодно помочь начинающим администраторам избежать классических ошибок, и была написана эта статья.
Содержание:
- Введение
- Маленький сервачок
- Большой сервер
- Гига бить или не бить?
- С матрицей и без
- Скупой платит дважды
- Возврат к первобытно-общинному строю
- Квоты
- Игры теней
- Оборонная инициатива ABE
- Заключение
- Боковые выносы
Локальные сети начинались с файловых серверов. Ими же они по сути дела и закончились. Достаточно многие сидят с SQL, WEB, etc, но файловые сервера используют еще больше народу: дома, в офисе, в корпоративной среде и так далее, вплоть до глобальных распределенных систем с кучей точек доступа по всему миру. Заниматься глобализмом мы не будем, переложив решение проблем планетарного масштаба на чужие плечи. В конце-концов, имея деньги, можно купить лучшее оборудование, нанять лучших специалистов: инженеров, администраторов, «белых хакеров»… Лучше обсудим вопросы, связанные с настройкой добротного файлового сервера в рамках скромной локальной сети.
Внешние жесткие диски с Ethernet-интерфейсом активно теснят полноценные файловые сервера, воздвигаемые на базе выделенных PC, встречаясь не только в домашних сетях, но и в офисах самых разных контор.
Достоинства: низкая цена (особенно в пересчете на один гигабайт), высокая масштабируемость (закончилось дисковое пространство? просто покупаем еще один винт и втыкаем в сетевой порт), относительная безглючность (работают они под сильно урезанным Linux’ом, который, как известно, не зависает), предельно низкое энергопотребление (а, следовательно, более дешевая UPS, обеспечивающая их бесперебойным питанием, в отсутствии которого говорить о сохранности информации можно только в переносном метафизическом смысле), неприхотливость (внешние жесткие диски не требуют никакого обслуживания), невосприимчивость к большинству хакерских атак. Плюс ко всему вышеперечисленному: компактность (очень важное обстоятельство для мини-офисов и домашних сетей).
Недостатки: полная неуправляемость (внешний диск представляет собой «вещь в себе», работающую на автопилоте и не желающую подчиняться воле администратора), невозможность запуска антивируса внутри «коробки» (а вне «коробки» антивирус съедает всю пропускную способность локальной сети), практически непреодолимые трудности с обновлением ядра и наложением заплаток на него и на Самбу (Linux, конечно, штука хорошая, но дыры в нем все-таки обнаруживаются, и если их не латать, сервачок может заразиться вирусом или руткитом, которого практически нереально победить, и который может привести к краху системы, в этом случае администратор будет вынужден разобрать «коробку», вытянуть оттуда жесткий диск и подключить его к PC – если, конечно, разработчики последнего не отодрали интерфейсный разъем, что довольно часто случается), низкая производительность при одновременном подключении нескольких десятков клиентов. В эту же корзину попадают аппаратные отказы самого диска (и ведь RAID на базе внешних жестких дисков на x86 никак не организуешь), сложности резервирования и поиска информации, связанные с отсутствием служб журналирования и индексирования, которые опять-таки не работают через Ethernet. Про толковое разграничение доступа мы вообще не говорим.
Не смотря на это, внешние жесткие диски – не самый плохой вариант, и как файловые сервера для домашних сетей и небольших офисов (где все равно никто не заботится ни о разграничении доступа, ни о резервировании) они вполне приемлемы. Какой смысл ставить PC, используя его в режиме «внешнего жесткого диска»?! А ведь именно в таком режиме большинство файловых серверов и работает! Переход на внешние жесткие диски в этом случае экономит деньги и увеличивает надежность, сокращая количество отказов и затрудняя атаки на сервер. Что касается больших корпоративных сетей, то там внешние жесткие диски могут вполне успешно «симбиотить» с настоящими файловыми серверами, используясь для хранения разделяемых данных, некритичных к разрушению.
Рис. 1. Внешний жесткий диск с Ethernet-интерфейсом со снятой крышкой
Воздвигнуть сервер можно и на основе PC. Особенно, если это сервер — файловый. Ему ни к чему большие процессорные мощности и SMP, избыток оперативной памяти превращается в бесполезный балласт, а скоростные RAID-контроллеры упираются в бутылочное горлышко тонкой витой пары. Список ненужных вещей можно продолжать бесконечно, а бесконечность штука коварная, поэтому лучше остановиться на формулировке: нетребовательность к аппаратной конфигурации. Подойдет любое (ну, практически) железо, что есть под рукой. Однако, тут все-таки не обходится без тонкостей…
Рис. 2. Симпатичный сервачок
Национальным стандартом де-факто стал стомегабитный Ethernet. Гигабитый уже давно не новость, но большого распространения он так и не получил. Что изменяет переход на гигабитные каналы? А ничего! Диск — быстрее, сеть — медленнее. Да, конечно, в гигабитный канал вмещается намного больше данных, и в крупных сетях разница все-таки выпирает наружу, однако это должна быть действительно крупная и сильно загруженная сеть, иначе выигрыш в производительности можно зафиксировать только с помощью хронометра. Но! Крупные сети строятся совсем по другой схеме. Они разбиваются на сегменты, администраторы заботятся о балансировке нагрузки…
В 99% случаях правильно спроектированная сеть не испытывает острой потребности в гигабитных каналах. А неправильной и гигабита будет мало. Учитывая, что гигабитная инфрастуктура требует определенных инвестиций как в оборудование, так и в топологию самой сети, целесообразность ее использования — предмет острых дискуссий, которые мы обойдем стороной, оставшись верными старому-доброму стомегабитному 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), а под рабочие файлы ей выделить максимум гигабайт — заодно и дубликаты файлов со временными копиями поудаляет.
Рис. 3. Выставляем квоты
Как лучше всего проводить резервирование? Разумеется, по расписанию. Когда все пользователи ушли, закрыли все файлы, и ничто не мешает их копированию (файлы, открываемые на запись, обычно блокируются). Вот только нереально это. Кто-то открыл кучу файлов и ушел домой, оставив компьютер включенным. Или фирма работает в три смены. Да мало ли еще что…
Вот специально для этого в Win2k3 реализовано так называемое «теневое копирование» (shadow copies). Если говорить просто — то это фоновое копирование, осуществляемое на сектором уровне (вообще-то, кластерном, но кого заботят эти мелочи) и работающее в тесном взаимодействии с NTFS так, что копируются даже файлы, открытые на запись и заблокированные от совместного чтения.
Рис. 4. Включение теневого копирования в Win2k3
Теневое копирование поддерживает множество резервирующих программ (в том числе и штатная утилита MS Backup) и вникать в технические детали реализации для его использования, в общем-то, и не обязательно.
Рис. 5. Служба теневого копирования не свободна от ошибок и иногда не запускается
Аббревиатура ABE расшифровывается как Access Based Enumeration и представляет из себя секьюрную фичу, стоящую на страже безопасности данных. Как и следует из ее названия, ABE позволяет скрывать сам факт существования разделяемых ресурсов от определенных групп пользователей, включая анонимусов (то есть всех праздно шатающихся хакеров).
Теоретически это усложняет взлом, поскольку хакеру необходимо не только подобрать пароль к ресурсу, но еще и угадать имя самого ресурса (например, имя папки с разделяемыми документами). Впрочем, как показывает практика, администраторы склонны давать разделяемым ресурсам вполне предсказуемые имена, а потому ABE не есть панацея.
С другой стороны, когда пользователь не видит ресурсов, к которым он не имеет прав доступа, он не нервничает и не задает глупых вопросов администратору (типа: а почему у меня не открывается папка TopSecret?), так что использование ABE даже в мирных целях весьма перспективно.
Рис. 6. Управление разделяемыми ресурсами
Конец статьи еще не означает конца всех проблем. С воздвижением сервера (не обязательно файлового) проблемы только начинаются. Собственно говоря, администратор представляет собой биокомпьютер, обслуживающий другие биокомпьютеры (пользователей), ну и попутно решающий, стоит ли выливать воду из чайника через вентиляционные отверстия сервера, или пускай пока живет. А вот когда окончательно достанут — точно выльет. Пока его чинят, он хоть немного отдохнет. «Его» — это администратора, «он» — в смысле сервер. Или наоборот?
INFO
-
Подробнее о теневом копировании можно прочитать в статье «Движение в тени», опубликованной в X_03_2008.
-
ABE позволяет администратору скрывать хранящиеся на общедоступных ресурсах папки и файлы от тех пользователей, которые не имеют соответствующих разрешений на доступ к ним на уровне NTFS.
-
С помощью политики дисковых квот можно ограничить объем дискового пространства, занимаемого данными пользователя на томе NTFS, и определить реакцию системы на превышение пользователем своей квоты, или достижение им заранее определенного «порога выдачи предупреждений».
-
Если поднимаешь файловый сервер на базе Win2k3, не забудь в свойствах сетевого подключения открыть свойства File and Printer Sharing for Microsoft Networks (службы доступа к файлам и принтерам) и отметить пункт Maximize data throughput for file sharing.
WWW
- Об особенностях использования ABE можно прочить на блоге .
Статья опубликована в сентябрьском номере журнала «Xakep» за 2008 год.