| Новые программы oszone.net |  |
По мере развития производства и экономики возникает потребность в чем-то большем, чем доморощенные серверы. Уже хотя бы потому, что накопленные объемы информации давно превышают емкости отдельного накопителя и даже RAID-массива. Именно для этого и нужны системы хранения данных. Abstract Идея хранения данных за пределами отдельного компьютера не нова. Основная цель такого подхода — разделять данные между несколькими приложениями и пользователями. Кроме того, общий дисковый пул может быть использован более эффективно — как правило, одни пользователи и приложения потребляют больше данных, в то время как на других компьютерах дисковое пространство остается неиспользованным. Единое место хранения значительно упрощает обслуживание системы: никогда не возникает вопрос, где именно следует проводить апгрейд носителей данных. Другие полезные возможности — это, например, создание сторонних копий, то есть резервное копирование данных без участия основного процессора. Вообще, провести четкую границу между локальными и удаленными хранилищами данных сложно — если судить по расположению носителей (дисков) в одном корпусе с процессором, то тот же SCSI-интерфейс позволяет как внутренние, так и внешние подключения накопителей. Аналогично могут быть подключены и устройства Fibre Channel, которые, в свою очередь, на некотором уровне абстракции эмулируют SCSI-устройства. Тем не менее, условно существует термин DAS (Direct Attached Storage) для тех устройств, которые напрямую, посредством драйверов, управляются локальной операционной системой. Говоря о хранилищах данных, имеем в виду их выделенное назначение для хранения данных, некоторый уровень специфической программной логики, от RAID-прошивки до универсальной UNIX-платформы, а также оптимизация по критическим параметрам доступа — емкости, масштабируемости и скорости доступа. Sun Microsystems: NFS Если говорить строго, то в качестве сетевых файловых систем можно было бы воспринимать FTP или Gopher и даже протокол x-modem, работающий вообще без IP-стека. Однако отсчет принято начинать с тех методов доступа, которые поддерживают стандартные файловые атрибуты и, следовательно, могут быть унифицированно смонтированы в дерево каталогов. В MS Windows и DOS этому до последнего времени соответствовало создание нового имени устройства. Одной из первых удачных систем этого класса была система NFS (Network Filing System), разработанная, как и много других современных сетевых технологий, в лабораториях Sun Microsystems. Эта система позволяла пользователю работать с удаленными данными так же, как с локальными — то есть абсолютно прозрачно. Не считая, естественно, временных задержек.
У NFS изначально было несколько интересных свойств: был использован, в целях повышения производительности, протокол передачи UDP, внешняя аутентификация и синхронность идентификаторов доступа GID/UID. Кроме того, NFS ориентирована на простоту реализации, что также повышает производительность, хотя и косвенно. В частности, NFS не поддерживает состояния, то есть сервер не отслеживает открытые файлы и сеансы. Не поддерживается и кэширование на стороне клиента. Собственно, NFS состоит из трех основных компонент:
Следует отметить, что многие из этих свойств уже стали настраиваемыми опциями в текущей, четвертой версии NFS. В частности, NFSv4 поддерживает NT-like списки доступа ACL, используются нетривиальные составные команды (вроде открыть-найти-прочитать-и-закрыть), используется TCP для контроля доставки; кроме того, последняя спецификация включает монтирование как часть стандарта NFS. В целях совместимости различных реализаций Sun Microsystems сделала и продолжает делать все для того, чтобы спецификации NFS были доступны всем заинтересованным сторонам. В частности, версии NFS 2, 3 и 4 описаны в RFC 1094, 1813 и 3010 (3530) соответственно. Microsoft: SMB Группа компаний, "застраивающих" рынок PC, пошла своим путем, создав собственный протокол обмена SMB (Server Message Block). Этот протокол впервые был разработан сотрудником IBM, доктором Бэрри Фейгенбау (немало "про-гейцев" доказывает, что во времена PS2/NT именно Майкрософт являлась основным источником идей — хотя я прекрасно помню те времена и то, что было на самом деле), но впоследствии передан на доработку Microsoft, которая в то время выступала как софтверный субподрядчик IBM по созданию NT-OS/2. Создавая SMB, разработчики ориентировались на NetWare Core Protocol, в то время лидировавший на рынке. В частности, поэтому SMB на уровне пакетов порядком похож на NCP. В 1987 году Microsoft выпустила LAN Manager, а в 1988-м IBM запустила OS/2 LAN Server — обе программы работали поверх SMB. Протокол SMB изначально использовал NetBIOS в качестве протокола сеанса, который, в свою очередь, в качестве транспорта поддерживал TCP/IP (NBT), NetWare (IPX), DECNet и Xerox Networking (XNS). Что в SMB отсутствовало, так это аутентификация — то есть любой пользователь мог использовать любые ресурсы, что, конечно, ограничивало область применения малыми локальными сетями.
В разработках принимали активное участие компании 3Com и Intel, дружившие в те времена c IBM. Фактически сам термин "SMB" впервые встречается у IBM в 1985 году. Кроме того, еще раньше IBM (точнее — Sytek по ее заказу) разработала известный стандарт NetBIOS, на котором до самого последнего времени базировались все сетевые возможности MS Windows и еще пара десятков менее известных и/или уже забытых систем. Некоторые из программистов могут помнить NetBIOS как "сервис INT 5C". Функции NetBIOS воспроизводят файловые операции DOS для упрощения трансляции вызовов между этими API. В последнее время, чтобы дистанцироваться от старых версий SMB, был выработан протокол CIFS (Common Internet File System). Он как бы создавался независимым сообществом, для чего были приглашены члены Samba Team,— но фактически все происходило под патронатом Microsoft. После того как новый CIFS-протокол был удачно представлен как "открытый стандарт", финансирование проекта "CIFS для UNIX" и сотрудничество с Samba Team было прекращено. Фактически CIFS явился прекрасным коммерческим хак-эксплойтом самой природы сообщества Open Source, в результате чего Microsoft получила мощное преимущество перед Sun, отвоевав большую часть локальных сетей для SMB. Со стандартизацией CIFS в свое время сложилась довольно непростая ситуация: Microsoft подала спецификацию CIFS в IETF, но эта организация дала заявке "состариться", то есть не удовлетворила просьбу на утверждение нового стандарта. С другой стороны, CIFS был стандартизирован другой организацией, Storage Networking Industry Association. Поскольку стандарт не был совместим со старыми версиями SMB, Microsoft пришлось расширять CIFS до совместимости с SMB (точно так же, как некогда HPFS пришлось расширять для совместимости с FAT, в результате чего появилась NTFS). В итоге есть "версия CIFS от Microsoft", которая для краткости называется SMB. В результате на сегодня существует три диалекта SMB: старый — применяемый в DOS/Windows 3.11 for Workgroups; новый — проприетарный CIFS от Microsoft; и квази-стандартный — применяемый, например, в Samba. "Старые" протоколы SMB также имеют свои варианты, такие как CORE, LANMAN и NT. Не совсем однозначная ситуация сложилась и с NetBIOS. Хотя протокол SMB получил уже собственный IP-порт (445) и не зависит от NetBIOS, тем не менее некоторые существующие системы, например Windows 98, используют NetBIOS запросы для поиска ресурсов в одноранговых сетях. Так что избавиться от NetBIOS пока невозможно, "сервис INT 5C" по прежнему работает, на чем и основывается множество существующих вирусов и других "сервисов" для Windows. Важное наследие NetBIOS, до последнего времени "нависающее" над SMB.— система адресации ресурсов в сети. Фактически в NetBIOS это строка из 15 символов (если нужно — дополненная пробелами), а также байт типа ресурса: сервер, котроллер домена и т.д. Конечно, такая одноранговая система именования подходит скорее для малых локальных сетей и плохо годится для интернета. Новые реализации SMB, начиная с NT5, однако, используют DNS вместо NetBIOS для разрешения сетевых имен. Интересный факт о Samba — проекте SMB для Unix. Исторически создатель Samba, Эндрю Триджелл (Andrew Tridgell), создал клиентскую часть SMB только на основе анализа протокола, даже не зная, что это был SMB, уже стандартный к тому времени. Эта традиция сохранилась и по сей день: разработчики исследуют новые возможности официальных версий только с помощью утилит ethereal и tcpdump — и не производят реверс кода. Итак: несмотря на усилия Microsoft придать протоколу статус открытого стандарта, несмотря на переименования в CIFS и подкуп независимых разработчиков, перед нами все тот же "срисованный" у IBM SMB. На сегодня не существует стандарта SMB, а только реализация секретного протокола MS, изобилующая недокументированными возможностями и прочими характеристиками благоприобретенного кода. Единственный способ узнать истину о протоколе — анализ трафика, чем и занимается группа Samba Team. И тем не менее, SMB продолжает наступление на NFS, поскольку SMB — это часть Windows, а Windows — это, увы, настоящее настольного компьютинга. Что еще добавляет интриги в ситуацию: MS будет уводить SMB с рынка с приходом Longhorn и Blackcomb. Кстати, "пострадает" не только SMB, но даже и NTFS, которая до сих под является одной из лучших журнальных файловых систем. Вместо журнальной NTFS должна появиться реляционная файловая система WinFS на основе MS SQL Server, а вместо старых вызовов RPC — нечто под кодовым именем Indigo. Складывается интересный момент: сообщество разработчиков, в том числе создатели систем хранения на основе SMB, в свое время повозившиеся с адаптацией и настройкой SMB под свои нужды, теперь будут поддерживать эту технологию собственными силами — и, возможно, SMB будет еще долго использоваться в сетях UNIX, в то время как под Windows будет предана забвению. Уровень NAS Итак, немного разобравшись в хитросплетениях доживших до наших дней сетевых файловых систем, поговорим об уровне NAS, что значит Network Attached Storage (хранилище, подключаемое по сети). Термин NAS — сугубо маркетинговый и появился как "рифма" к DAS, то есть непосредственно подключаемым устройствам. Фактически, за сочетанием NAS не стоит ничего нового — это обычный файловый сервер, только очень выделенный. Операционная система в минимальной конфигурации, плюс один или оба из указанных методов доступа: NFS и SMB, иногда — FTP и SCP (SecureCoPy), несколько процессоров, побольше памяти — и ничего лишнего. Часто NAS-серверы могут быть выполнены в "необслуживаемом" варианте, то есть продаются как "бытовая техника" для бизнеса. Существуют NAS под управлением любой из северных операционных систем — от Sun Solaris и до MS Windows Server, включая, разумеется, Linux и BSD. Метод подключения к сети может использоваться какой угодно, но в 99% это Ethernet+IP, часто даже через несколько скоростных интерфейсов, что все равно дешевле, чем оптическое волокно. В последнее время ожидается нашествие беспроводных устройств, однако они долго еще будут проигрывать по пропускной способности, а также благодаря "сомнительной" безопасности доступа.
Кроме уже упоминавшейся эффективности хранения и простого обслуживания, NAS-сервер является естественным решением в гетерогенной среде, обеспечивая доступ к одним данным по SMB и NFS. Конечно, при этом иногда теряется возможность корректного использования файловых атрибутов, поскольку в различных системах они не совпадают. Что обычно отличает настоящий NAS, это аппаратные возможности самих серверов. Это и встроенные аппаратные средства самотестирования, и системы горячей замены, батареи бесперебойного энергоснабжения и, конечно, специальный софт поверх стандартной OS для удаленного управления и диагностики. Короче, все, чем славятся серверы HP и IBM. Форма исполнения — почти всегда стоечная, 19”, тип организации — в целях быстродействия всегда RAID. А вот тип дисков уже не всегда SCSI. В последнее время в качестве базы для NAS-сервера часто можно видеть SATA-RAID — скорость почти та же, а цена за мегабайт выгоднее на двоичный порядок и более. Огромные кэши еще более нивелируют разницу между SCSI и SATA — с большой вероятностью данные поступают из оперативной памяти, а не с дисковых пластин. Из программных возможностей раньше часто упоминались возможности логической организации дисков, разделов, быстрое форматирование. Сегодняшние ведущие операционные системы (по крайней мере, Windows Server и Linux) имеют собственные встроенные возможности логических и динамических томов, горячего подключения, софт RAID и т.д., так что необходимость в заказном софтвере становится все меньшей. Часто устройства NAS имеют все необходимое и для "автоархивации", то есть могут архивировать данные самостоятельно, на собственные носители, такие как ленты, или между двумя NAS-серверами. Если подумать, что NAS — это обычный сервер, например под Linux, то такое "чудо" кажется само собой разумеющимся. Однако, несмотря на кажущуюся простоту, проблема резервного копирования и восстановления данных не имеет пока одного простого решения. По данным IBM, до 20% всех вычислительных ресурсов тратится на обеспечение резервных копий в различных формах. Много это или мало — судите сами. Кроме мегакорпораций, вроде HP, в секторе NAS оперирует еще около ста фирм различной степени надежности и финансовой стабильности — их репрезентативный список можно встретить, например, на сайте www.storagesearch.com/nas.html. Новый виток DAS/SAN: Fibre Channel vs. iSCSI С точки зрения подключения оптоволоконные устройства — это типичный DAS. Для компьютера и операционной системы это обычное SCSI-устройство. Но с точки зрения самой системы это целая сеть, построенная по одной из сетевых топологий. Собственно, топология подключения всегда одна — звезда. Причина проста: эта технология обладает повышенной надежностью физического соединения — раз, и, во-вторых, она позволяет осуществлять hot-plug. Если, например, "вырвать" устройство из шинной или кольцевой сети, то такая сеть, понятно, работать не будет. Для сетей хранения на основе Fibre Channel (хотя и не обязательно — но по факту именно так) применяется термин SAN, Storage Area Network. Такие сети могут взаимодействовать в радиусе километра или около того и, кроме того, динамически выделять дисковое пространство различным серверам. С точки же зрения логики FC почти всегда представляется как замкнутое кольцо, Token Ring. Пакет-инициатор передается от одной узла к другому, так что логика захвата шины определяется физическими характеристиками среды, без программной логики, а значит — мгновенно (буквально со скоростью света). Узел, получивший такой токен (пакет), может инициировать запрос к другому узлу или ответить на такой запрос. Хотя это и работает стремительно быстро, однако с ростом числа узлов задержки все-таки становятся достаточно заметными. Кстати, одна из неафишируемых причин популярности Token Ring — отсутствие приемлемых, быстрых и дешевых коммутаторов светового потока, поэтому коммутатор наподобие обычного для Firbe Channel… не то, чтобы не существует, но в быту не применяется. При этом не надо путать количество адресуемых устройств и реальную пропускную возможность. Например, если адресный префикс состоит из 16 бит и потенциально можно адресовать более 64 тысяч устройств, то в реальности уже 100 устройств "прикроют" пропускной канал намертво. В общем, не стоит верить всему, что пишут в рекламе. Для обхода ограничений пропускной способности FC применяют множество ухищрений, главное из которых — многоконтурное подключение. Каждый узел подключается в несколько контуров, что пропорционально увеличивает потенциальную пропускную способность. Более сложные варианты подразумевают динамическое переключение контуров с целью настройки под загрузку трафика. В последнее время, однако, протокол Fibre Channel был портирован в среду TCP/IP, что называется Fibre Channel over IP, FCOIP. То есть теперь туннелирование протоколов выглядит следующим образом: файловая система — SCSI — Fibre Channel — TCP — IP — Ethernet В результате достигнут важный компромисс между существующими драйверами FC/SCSI и существующими кабельными системами типа "витая пара". Конечно, ситуация сложнее, чем кажется: протокол Ethernet реализован на уровне сетевого адаптера NIC, протокол TCP/IP — на уровне операционной системы, Fibre Channel встроен в специальные адаптеры, вместе с эмулятором SCSI. Иными словами нужно снабжать адаптеры Fibre Channel адаптерами сети Ethernet со встроенной реализацией TCP/IP. Это называется SAN-маршрутизаторами. Другой вариант, когда все протоколы выше Ethernet реализуются на компьютере, не проходит по производительности и может быть использован только в качестве прототипа реальных систем. Эмуляция должна давать цифры, сопоставимые с существующими 1-2 Гбит для сетей FC. Встречаются интересные варианты, когда используется отдельный производительный микрокомпьютер для полной конвертации протоколов по всем стекам, но, конечно, в результате это должно быть "прошито" в железо.
Наконец, последняя версия: iSCSI не использует уровень протоколов FC, то есть транслирует SCSI-вызовы непосредственно в TCP-пакеты. Это вроде бы простое решение, тем не менее, не так уж и просто: уровень FC содержит важные протоколы, которые осуществляют сервисы высокого уровня, вроде поиска ресурсов и их горячего подключения. Теперь эти задачи нужно решать заново — средствами iSCSI. Опять-таки, полная производительная реализация подразумевает перевод протокольных операций на уровень аппаратного обеспечения и в идеале выглядит как PCI-SCSI-TCP-IP-Ethernet адаптер. Функции iSCSI-сервера выполняют такие устройства, как маршрутизатор Cisco SN 5428-2. Реализация стека IP на уровне ОС ставит сложные проблемы "круговой циркуляции" данных и нагрузки на процессор. Полностью софт-решение, вроде http://linux-iscsi.sourceforge.net позволяет производить всю обработку за счет центрального процессора — это подходит для нетребовательных (клиентских) приложений, но не для серверов. Итого: выбор есть, но он непрост В результате современные IT-менеджеры имеют очень сложный выбор между DAS, NAS и SAN. Обычный RAID-массив уже не может служить идеальной отправной точкой для промышленного хранилища данных — приходится анализировать не только настоящие, но и будущие потребности. Полностью "упакованная" система выглядит как доступ высокого уровня по NFS/SMB к серверу NAS, который, в свою очередь, имеет SAN-подключения поверх Fibre Channel, FCOIP или iSCSI, так называемый NAS/SAN. Отдельным вопросом является размещение в этой иерархии серверов баз данных и серверов приложений — вы можете воспользоваться высокопроизводительным сетевым TCP/IP-подключением на каждом из этапов обработки: приложение — БД — файловая система — Fibre Channel — SCSI. В перспективе, однако, роль NAS- (а возможно, и БД, если SQL можно рассматривать как метод доступа NAS) сервера будут выполнять высокопроизводительные аппаратные устройства или даже отдельные адаптеры. Кроме того, ожидается массовое наступление беспроводных NAS-серверов: мощный маршрутизатор SAN будет обслуживать массу портативных WiFi-NAS-серверов — так называемый метод беспроводной клиентской доставки. В любом случае, время TCP-хранилищ наступило, дело за появлением массовых продуктов этой категории.
Теги:
Комментарии посетителей
Комментарии отключены. С вопросами по статьям обращайтесь в форум.
|
|
