Распределенные хранилища информации
Лучший способ сохранить информацию — поделиться ею со своими друзьями. Это — общеизвестный факт! В этой главе я дам рекомендации по автоматизации этого процесса и расскажу, как сделать так, чтобы компьютер самостоятельно "распределял" данные по локальной сети.
Давным-давно, когда лазерных дисков и в помине не существовало, а дискеты "осыпались", как ржавчина с трубы, потеря всей информации была обычным делом. Вот и приходилось бегать по друзьям, копируя у них программы, которые они раньше копировали у вас. Исходные коды программ и офисные документы тоже часто отдавались на хранение приятелям в зашифрованном виде.
Естественно, при активном использовании такого подхода возникает то, что в ботанике называется перекрестным опылением, а у хакеров — вирусной эпидемией. Вирусы размножаются с ужасающей скоростью, как лесной пожар! Единожды попав в такой обменник, они прочно обосновываются в нем, да так, что их становится практически невозможно удалить, ведь перезаражение происходит многократно. Правда, сейчас можно упаковывать дистрибутивы любым архиватором с опцией "зашиты от изменений" или использовать контрольные суммы. Стоит только сказать, что проделывать все это вручную — процесс длительный и утомительный. Двадцать первый век на дворе, как-никак! К тому же, распределенное хранилище обычно получается слишком несбалансированным: какой-то файл (программа, музыка, клип) есть у всех, а какого-то нет ни у кого, и его потеря невосполнима.
Раньше приходилось бегать с дискетами и таскать винчестеры в сумке. Теперь же локальные сети позволяют обмениваться файлами, не выходя из дома. Так почему не использовать те преимущества, которые несет прогресс?
Первые шаги
Для создания распределенных хранилищ информации желательно иметь локальную сеть с нелимитированным трафиком, обеспечивающую скорость обмена данными хотя бы 10 Мбит/с. Модем на 33.600 тоже сгодится, но при этом 700-мегабайтный лазерный диск даже на крейсерской скорости (при отличном качестве телефонной линии) будет передаваться двое суток! Быстрее записать его на диск, одеться и добежать до товарища самостоятельно.
Беспроводные технологии значительно упрощают прокладку сетей, и теперь уже не приходится возиться с кабелями и выбивать многочисленные разрешения на прокладку (рис. 12.1). Поэтому будем считать, что локальная сеть у нас уже есть. На худой конец, можно воспользоваться услугами интернет-провайдера, многие из которых за локальный трафик практически не взимают никаких денег.
Рис. 12.1. Ноутбук с беспроводным адаптером тоже стоит зарезервировать
Осталось лишь подобрать программное обеспечение. Минималисты (к числу которых принадлежу и я) могут ограничиться "общим доступом к файлам", встроенным в Windows. Начиная с Windows 2000, система поддерживает квотирование, т.е. позволяет ограничить предельный объем файлов для каждого пользователя. С квотированием уже не приходится бояться, что кто- нибудь войдет в раж и заполнит весь ваш диск целиком. Можно, например, ограничить объем общего хранилища значением 10 Гбайт, и больше не беспокоиться. Остается только назначить права доступа так, чтобы все члены сети видели чужие файлы, но не могли их изменять или удалять. В Windows XP это совсем не сложно сделать! Достаточно открыть свойства папки и указать, что владелец имеет право выполнять любые действия, а остальные пользователи — только читать файлы.
Теперь каждый сможет зарезервировать самые ценные файлы, а то и весь диск целиком, на компьютерах своих соседей по сети! Образуется некое подобие файлообменной сети, к которой могут подключаться и другие пользователи. По действующему законодательству РФ любой потребитель может изготовить столько резервных копий, сколько ему необходимо, причем он не обязан предпринимать никаких дополнительных охранных мер, препятствующих распространению информации.
"Общий доступ" замечательно работает в сетях, насчитывающих до десяти узлов, но затем начинаются проблемы. Вы просто не можете вспомнить, на какой компьютер был зарезервирован тот или иной файл, равно как и то, какие файлы зарезервированы, а какие — нет. К тому же, домашние компьютеры — это все-таки не выделенные файл-серверы, и они доступны не все время. Разбросанный по сотне узлов архив музыки/фильмов/софта практически неуязвим. Если все компьютеры отказали сразу, то это значит, что случилось что-то катастрофическое (например, землетрясение), и тут уже вам станет не до фильмов. Очевидный недостаток этого подхода состоит только в том, что для того, чтобы собрать все нужные файлы обратно на свой компьютер, потребуется длительное время. И все равно окажется, что самого нужного, как назло, не хватает, потому что некий особо ценный файл был зарезервирован в единственном экземпляре, который тоже оказался утерян. Чтобы застраховаться от таких непредвиденных случайностей, подойдем к делу творчески и воспользуемся e-Mule. Программа e-Mule — это клиент крупнейшей файлообменной сети e-Donkey, в которой можно найти все что угодно: от исходных кодов нужной программы до новейших блокбастеров. Система сама следит за целостностью файлов, показывает количество имеющихся источников и тянет со всех активных узлов сразу, равномерно распределяя нагрузку между ними. Мы можем разбивать пользователей на группы, ранжируя их по гибкой системе приоритетов, регламентировать входящий/исходящий трафик и т.д. В классическом e-Mule отсутствует возможность принудительной закачки, и все, что мы можем — просто выложить файлы в общий каталог, дожидаясь, пока их кто-нибудь заберет. Это хорошо работает для обмена музыкой, но для резервирования, увы, не подходит! Приходится договариваться каждый день (или хотя бы раз в неделю) просматривать содержимое общих папок всех членов сети (естественно, просмотр папок должен быть разрешен), находить новые файлы и качать их себе, если, конечно, это уже не сделал кто-то другой. Можно установить любой порог, скажем, забирать только те файлы, которые имеются менее чем у десяти источников (точная цифра зависит от размеров сети — чем больше сеть, тем выше порог). Необязательно делать это вручную! Достаточно слегка доработать e-Mule, исходные тексты которого можно скачать с http://www.emule.ru, или написать плагин.
Очевидный недостаток — привязка к файлообменной сети e-Donkey и к ее серверам, которые и без того перегружены. К тому же, мы не можем выборочно настраивать пропускную способность, и поэтому к нам будет ломиться толпа пользователей изо всех концов сети. Конечно, любой брандмауэр легко отсечет их, но это не решит всех проблем, самая главная из которых состоит в том, что наша маленькая приватная сеть становится видной извне.
Лучше использовать "равноправные" файлообменные сети, обходящиеся без выделенных узлов, т.е. работающие без сервера, например. GNUTELLA (http://www.gnutella.com/connect/). Протокол давно расшифрован, множество клиентов распространяется вместе с исходными текстами на бесплатной основе. Слегка доработав их под собственные нужды, мы получим отличное средство автоматизированного распределенного резервирования, после чего за сохранность наших данных можно будет не волноваться.
Конечно, настоящие программисты могут не извращаться, подгоняя под себя уже существующий софт, а написать его самостоятельно. Подобных программ, насколько мне известно, еще нет. Поэтому такая разработка может иметь оглушительный успех, тем более что пропускная способность каналов связи растет день ото дня, тарифы на трафик дешевеют, а домашние локальные сети сегодня не прокладывает только ленивый. Словом, есть все условия для создания распределенных хранилищ данных, не хватает только специализированного программного обеспечения. Ну же, программисты! И чего же мы ожидаем? Ждем, пока Билл Гейтс не встроит эту возможность в новую Windows, лишая нас возможности заработать?
Сервер FTP или возрождение BBS
Файлообменные системы оправдывают себя только в больших сетях. В сетях среднего размера, насчитывающих несколько десятков узлов, они довольно обременительны. Поэтому для создания распределенного хранилища данных лучше всего использовать FTP-серверы.
Начнем с того, что даже в одноранговой сети не все узлы равноправны. Одни пользователи могут позволить себе держать компьютер включенным все дни и ночи напролет, другие — нет. Одни имеют емкие жесткие диски, мощный процессор и скоростной канал связи, а другие таких возможностей не имеют. Файлообменные системы уравнивают всех своих пользователей в правах, и 90% нагрузки ложится на плечи 10% клиентов. Скажите, а им это надо? Никто не захочет тянуть за собой остальных, ничего не получая взамен.
В крупных сетях ситуация нормализуется за счет естественного притока новых меценатов — бескорыстных парней, стремящихся сделать что-то хорошее в жизни, ничего не ожидая взамен. Правда, со временем это стремление, как правило, проходит. Ведь как бывает? Помогаешь своим ближним, помогаешь, а они не только не поблагодарят, а еще и напакостят. Ладно, не будем о грустном, а лучше перейдем к сути дела.
Крупные узлы небольшой приватной сети могут поддерживать собственные FTP-сервера, открытые на закачку (upload), и на загрузку (download), которые будут доступны всем остальным пользователям. Это — тоже распределенное хранилище, но, в отличие от описанных выше, более надежное и быстрее работающее. Мы можем резервировать данные только на те серверы, которые оснащены источниками бесперебойного питания, отказоустойчивыми массивами RAID и прочими достижениями прогресса. Поскольку квоты на таких серверах, как правило, достаточно велики, никакой необходимости разбрасывать файлы по десяткам узлов уже нет. Достаточно продублировать файлы дважды, или, на худой конец, трижды.
Остается лишь решить один маленький вопрос — с какой стати кто-то будет содержать FTP-сервер? Брать за это деньги нелепо, да и смысла нет. Не окупится. А на чистом энтузиазме далеко не уедешь. На самом деле, собственный FTP-сервер — это лучший способ раздобыть редкую музыку/фильмы/варез. Что резервируют пользователи? Самые ценные файлы, которые жалко потерять, и которые они с большим трудом откопали в сети (или купили за огромные деньги). И все это они добровольно несут нам, только успевай подставлять жесткий диск! Ну, чем жизнь не малина? Давным-давно, когда Интернета еще не существовало, а софт считался общенародным достоянием (но собирать его приходилось буквально по битам), основными "малинниками" были электронные доски (BBS) или, проще говоря, компьютеры с модемом, принимающим входящие звонки и складирующим закачиваемые файлы. Сисоп (системный оператор) отбирал самые "вкусные" файлы, а остальные отправлял в мусорную корзину.
Так почему бы не возродить эту традицию, используя FTP-серверы для обмена файлами?
Массивы RAID
Что такое контроллер RAID, знает каждый (сейчас его можно купить в любом магазине). Упрощенно говоря, это такое устройство, которое позволяет писать сразу на несколько дисков одновременно. Если на диски пишутся разные данные — скорость обмена пропорционально возрастает. Если дублируются те же самые данные — возрастает надежность. Массивы RAID могут быть как программными, так и аппаратными, а сами образующие массив носители не обязаны быть сосредоточены на одном и том же компьютере. Чувствуете, куда я клоню?
С точки зрения программного RAID нет никакой разницы между диском, подключенным к локальному компьютеру через интерфейсы SCSI или IDE, и диском, обменивающимся данными через сеть. Объединив несколько логических дисков в виртуальный массив RAID, мы получим отказоустойчивую систему — практичную и удобную. Мы можем использовать диски различной геометрии и даже различной емкости, причем никто не обязывает нас отводить под RAID-хранилище весь диск целиком! Достаточно выделить любую часть дискового пространства по выбору.
Как это можно реально использовать на практике? Первое, что приходит в голову, — это использовать часть емкости жестких дисков под хранение избыточной информации (например, кодов Рида-Соломона, помогающих восстановить данные в случае аварии). Тогда при относительно небольших накладных расходах мы сможем восстановить любой из жестких дисков членов сети даже при полном его разрушении лишь за счет одной избыточной информации, распределенной между остальными компьютерами. Более надежного хранилища для ваших данных нельзя и придумать! Подобная схема давным-давно была мною реализована в локальных сетях нескольких фирм. Она доказала свою живучесть, гибкость и надежность. Необходимость в постоянном ручном резервировании при этом отпадает, что для домашних пользователей более, чем актуально!
Единственный минус программного RAID — его невысокая производительность. В частности, поставив программный RAID на сервер, обрабатывающий тысячи запросов ежесекундно и интенсивно модифицирующий большое количество файлов, мы не выиграем ничего. Однако, ведь само понятие "производительности" относительно, и при достаточно быстром процессоре кодирование/декодирование информации вполне реально осуществлять и на лету, безо всяких потерь в пропускной способности! Если операции чтения доминируют над операциями записи, то ставить программный RAID очень выгодно, поскольку контроль целостности считываемой информации осуществляется на "железном" уровне самим приводом, и при использовании систематического кодирования (информационные слова — отдельно, байты четности — отдельно), декодеру Рида-Соломона нет никакой нужды как-то вмешиваться в этот процесс. Помощь его помощь требуется лишь тогда, когда часть информации оказывается безнадежно разрушена, что случается, прямо скажем, не так уж часто. Так что, право же, не стоит перекармливать фирмы, специализирующие на выпуске аппаратных RAID, тем более что на они все равно не уделят достаточного внимания домашним пользователям и малым предприятиям.
Варьируя размер блоков корректирующих кодов, мы получим лучшую или худшую защищенность при большей или меньшей избыточности информации. Действительно, пусть у нас есть
NNА как быть, если погибнет весь жесткий диск целиком? Наиболее разумный выход — создать массив из нескольких дисков, хранящих полезную информацию вперемешку с корректирующими кодами. Главный минус такого подхода — его неэффективность на массивах, состоящих из небольшого количества жестких дисков. Разумный минимум: четыре информационных диска и один контрольный, тогда потеря любого из информационных дисков компенсируется оставшимся в живых контрольным. В случае потери контрольного диска, его очень просто заменить на новый, с последующим пересчетом всех контрольных кодов. Правда, одновременный выход двух дисков из строя — это уже серьезно. Массив из пятнадцати дисков, двенадцать из которых — информационные, а оставшиеся три — контрольные, намного более отказоустойчив и допускает одновременный крах двух любых дисков, а при благоприятном стечении обстоятельств — и трех.
Подробнее о кодах Рида-Соломона можно прочитать в моей книге "Техника защиты CD от копирования". Исходные коды простейшего кодера/декодера, который можно использовать для создания собственного драйвера RAID, можно найти на компакт-диске, поставляющемся с этой книгой.
Заключение
Мы рассмотрели только несколько типов распределенных систем резервирования данных. На самом деле, их гораздо больше, и каждый день появляются все новые и новые. Правда, пока только в виде идей. Готовых реализаций крайне мало, да и те в большинстве своем основаны на уже существующих программах (например, e-Mule). Так что, дерзайте!
Приложение
