CC BY
84
безопасность регионов России (ИБРР-2007)». - Санкт-Петербург, 23-25 октября 2007 г. - Материалы конференции. - СПб, 2007. - С. 57-58.
6. Common Criteria for Information Technology Security Evaluation. Version 2.2. Revision 256. Part 1: Introduction and general model. - January 2004.
7. Common Criteria for Information Technology Security Evaluation. Version 2.2. Revision 256. Part 2: Security functional requirements. - January 2004.
8. Common Criteria for Information Technology Security Evaluation. Version 2.2. Revision 256. Part 3: Security Assurance Requirements. - January 2004.
9. РД Безопасность информационных технологий. Общая методология оценки безопасности информационных технологий (проект). - ФСТЭК России, 2005.
Зайцев Олег Евгеньевич — Санкт-Петербургский государственный универси-
тет информационных технологий, механики и оптики, аспирант, [email protected] Любимов Александр Вилиевич — Санкт-Петербургский государственный универси-
тет информационных технологий, механики и оптики, кандидат технических наук, доцент, [email protected]
УДК 004.75, 004.772, 004.62
АНАЛИЗ ФАКТОРОВ, ВЛИЯЮЩИХ НА КАЧЕСТВЕННЫЕ И КОЛИЧЕСТВЕННЫЕ ПОКАЗАТЕЛИ ФУНКЦИОНИРОВАНИЯ СИСТЕМ РАСПРЕДЕЛЕННОГО ХРАНИЛИЩА ДАННЫХ
Н.М. Лукьянов, В.В. Кириллов
В работе проводится исследование распределенных хранилищ данных, анализ качественных и количественных показателей их функционирования. Результатом исследования является функциональная модель системы распределенного хранилища данных, построенная для работы в составе Интернет-сервисов. Ключевые слова: хранилища, распределенные, показатели, Интернет, сервис.
Введение
Раньше создание распределенной системы хранения данных было специфической задачей, необходимость которой была не очевидна. Сегодня, на совершенно ином техническом уровне, необходимость в распределенных системах хранения очевидна. В сети Интернет широкое распространение получили различные сервисы, предоставляющие услуги размещения, накопления и обмена различной информации, такой как фотографии, видеоматериалы, текстовые документы, электронная почта и т.д. Эти сервисы так или иначе используют в своей работе хранилища данных, которые имеют оригинальные характеристики и свойства. Каждая подобная система имеет свою архитектуру и решает свою конкретную задачу.
Данное исследование направлено на построение и анализ распределенного хранилища данных, предназначенного для работы с интерактивными веб-сервисами.
Постановка задачи
Долгое время распределенные файловые системы использовались в основном в кластерных системах, которые занимались сбором и обработкой большого количества информации, возникающей при решении таких задач, как имитация физических процессов, анализ радиосигналов, генетический анализ, расчет компьютерной графики, финансовое моделирование и т.д. [1].
В области Интернет-приложений вопрос о применении распределенных систем хранения данных для он-лайн сервисов стал рассматриваться относительно недавно, примерно с 2001 г. Сейчас такие системы используются для электронной коммерции, для мультимедийных он-лайн сервисов и самых посещаемых, по данным статистики alexa.com, на сегодняшний день Интернет-сервисов - социальных сетей. В большинстве случаев архитектура и принципы построения таких систем держатся в секрете, так как являются коммерческой тайной.
В данном исследовании распределенное хранилище данных будет рассматриваться в качестве составного элемента в архитектуре крупной Интернет-системы, основная задача которой - предоставление большого количества пользовательских сервисов и агрегация больших объемов разнородных данных. Задачей же распределенного файлового хранилища как составного элемента централизованной системы является хранение программ и данных и предоставление доступа к ним по мере необходимости со стороны сетевых пользовательских сервисов.
Исходя из 1 000 000 планируемых пользователей за первый год работы системы, даже без учета резервирования данных суммарный объем файлового хранилища должен быть около 225 Тб. Для выбора наиболее подходящей из существующих или создания новой распределенной системы хранения необходимо определить, проанализировать и сравнить целый ряд характеристик. Каждая система может обладать всеми или частью этих характеристик, что и создает основу для сравнения различных архитектур между собой. В результате исследования необходимо получить функциональную модель системы с учетом следующих требований [2]:
- открытая архитектура,
- прозрачность размещения файлов,
- независимость размещения файлов,
- мобильность клиента,
- мобильность файлов,
- устойчивость к сбоям,
- расширяемость.
Существующие системы
За довольно большой срок существования такого направления, как распределенные вычисления, было разработано большое число разнообразных файловых систем с различными архитектурами, назначением и уникальными свойствами. Именно поэтому классификация и анализ существующих архитектур распределенных хранилищ позволит выявить их сильные и слабые стороны. Эти знания, с учетом специфики и назначения проектируемой системы, позволят построить ее по описанным требованиям.
По данным энциклопедии «Википедия», насчитывается около сотни распределенных файловых систем различного назначения и архитектуры, которые, впрочем, можно разделить на 3 группы - параллельные файловые системы, симметричные файловые системы с разделяемым диском, гибридные файловые системы с API интерфейсом.
Параллельная файловая система обладает большой производительностью, масштабируемостью и является наиболее успешным примером файловой системы, которая используется в вычислительных кластерах [10]. Система состоит из 3-х компонент:
- сервер метаданных, который отвечает за структуру директорий, а также указывает на положение «объектов», составляющих файл;
- сервер хранения;
- клиент, который находит или загружает необходимый ему файл.
Симметричные файловые системы с доступом к устройству хранения на блочном уровне характеризуются отсутствием функционального разделения узлов. В отличие от
параллельных файловых систем, в симметричных нет управляющего сервера метаданных. Примером симметричной файловой системы может служить Global File System (GFS) от компании RedHat, а также GlusterFS.
Параллельные и симметричные файловые системы являются POSIX-совместимыми и широко используются для различных задач - распределенных вычислений, моделирования, производственных задач [11]. Инженеры Google, Yahoo, разработчик Интернет-дневника LiveJournal и другие пошли несколько иным путем. Они разработали гибридную систему распределенного хранения данных с API доступом, т.е. не файловую систему в классическом понимании. Благодаря наличию API очень легко интегрировать такие файловые системы с любыми Интернет-системами. Гибридные системы построены по принципу, схожему с параллельными файловыми системами, где есть сервер метаданных и серверы хранилища.
Надежность
Надежность систем обработки данных, их способность ежесекундно обеспечивать пользователей оперативной и достоверной информацией - одно из важнейших условий эффективной работы. Одним из решений этой проблемы является кластеризация серверных систем, за счет которой поддерживается высокий уровень готовности (high availability).
Построение отказоустойчивых кластеров предполагает использование в качестве узловых машин высоконадежных серверов с двукратным, а иногда и многократным, дублированием всех основных блоков и компонентов [3]. Так, например, в параллельной файловой системе Lustre, в симметричной файловой системе GFS и GlusterFS надежность данных, хранимых на узлах, практически полностью должна обеспечиваться внутренними средствами резервирования самих узлов, что требует использования дорогостоящих компонентов - как узлов, так и средств коммуникации между ними.
Возможно, при реализации хорошо финансируемого проекта использование промышленных решений могло бы иметь ряд преимуществ. По данным сайтов Mendax.com и ebay.com, хранилище данных объемом 10 Пб можно приобрести менее чем за 10 миллионов долларов, значит, по приблизительным оценкам, хранилище объемом 1 Пб будет стоить примерно 1 миллион долларов.
Противоположный подход, привнесенный из области вычислительных кластерных систем, состоит в том, что сама кластерная архитектура признается единственным необходимым и достаточным условием для обеспечения высокой готовности систем обработки данных, а аппаратная база может не иметь высокой надежности, т. е. может быть представлена обычными бытовыми компонентами, но иметь возможность оперативной замены. Второй подход используют гибридные файловые системы с API GoogleFS, Hadoop и MogileFS [4]. В их окружении нет промышленных решений хранения и обработки данных, используются обычные, предназначенные для бытового использования устройства. Резервирование и обработка данных реализованы на программном уровне.
Для подтверждения рациональности такого подхода инженеры Google сравнили стоимость комплекта 88 серверов, которые суммарно давали 176 процессоров, 176 Гб ОЗУ и 7 Тб дискового пространства, со стоимостью многопроцессорного сервера из 8 процессоров, 64 Гб ОЗУ и 8 Тб дискового пространства. Несмотря на то, что многопроцессорный сервер содержит на 168 процессоров меньше, имеет в 2 раза меньший объем ОЗУ, его стоимость почти в 3 раза выше стоимости всех 88 серверов [5].
Использование бытовых серверов, а также продуманной архитектуры и программного обеспечения позволяет добиваться требуемых показателей, используя при этом значительно меньшие финансовые ресурсы.
Резервирование данных
Исходя из определенных ранее объемов файлового хранилища (225 Тб), общее количество дисков в проектируемой системе должно быть не менее 900 дисков по 250 Гб каждый. Для обеспечения минимальной сохранности данных рассмотрим возможность использования RAID уровня 5. Данные записываются последовательно на все диски, кроме одного, на который записывается контрольная сумма данных остальных дисков. Для такой избыточности будет необходимо еще 100 дисков.
Ожидаемое время отказа бытового жесткого диска - 1000 дней. Время восстановления (копирования) данных при 7% скорости диска займет 1 день (250 Гб на скорости 3,5 МБ/с). Ожидаемое число вышедших из строя дисков при таких условиях будет равна 1000х(1/1000)=1 диск в день. Если хранилище построено на избыточных массивах RAID 5 из 10 дисков, то вероятность выхода из строя второго диска во время восстановления массива будет 9х(1/1000) ~ 0,01. Вероятность выхода из строя сразу 2 жестких дисков, в результате которого потеряются все данные массива, можно рассчитать как произведение вероятностей этих двух событий, т.е. в течение 100 дней может произойти выход из строя сразу двух жестких дисков массива, что приведет к полной потере данных [6].
Во избежание полной потери данных в результате выхода из строя нескольких жестких дисков одного избыточного массива необходимо принять меры, уменьшающие вероятность аварии. Можно, например, использовать алгоритм подсчета двойной контрольной суммы RAID 6, который, впрочем, не очень популярен и недоступен в большинстве аппаратных RAID контроллерах. Для наиболее эффективного резервирования данных, хотя и с 50% избыточностью, рекомендуется использовать RAID 10. Диски массива объединяются парами в «зеркала» (RAID 1), а затем все эти зеркальные пары, в свою очередь, объединяются в общий массив с чередованием (RAID 0). В результате от «зеркалирования» наследуется надежность, от «объединения с чередованием» - производительность как на чтение, так и на запись [7].
Масштабирование
Учитывая специфику работы Интернет-систем, всегда необходимо быть готовым к масштабному расширению как вычислительных, так и накопительных мощностей системы. В этом случае возможны два варианта масштабирования - горизонтальное и вертикальное. Увеличение мощности узлов называется вертикальным масштабированием и позволяет временно улучшить производительность системы. Однако рано или поздно настанет такой момент, когда наращивать мощность узлов станет невозможным [8]. С учетом представленных компанией Google отчетов о соотношении цены и производительности различных платформ становится очевидным, что вертикальное масштабирование - весьма затратное и неэффективное мероприятие [5].
Горизонтальное масштабирование предоставляет возможность добавлять в систему дополнительные компьютеры и распределять работу между ними. Таким образом, производительность новой системы в целом выходит за пределы предыдущей. Горизонтальное масштабирование с возможностью добавления машин в кластер не только устраняет узкие места при обработке электронных операций, но и одновременно предоставляет дополнительную гибкость для дальнейшего роста и адаптации архитектуры под конкретные требования проекта [9].
Параллельная файловая система Lustre изначально создавалась с учетом требований к горизонтальному масштабированию. Благодаря разделению ролей хранения и обработки данных и наличию сервера метаданных становится возможным легкое расширение системы за счет добавления новых узлов хранения. Горизонтальному масштаби-
рованию хорошо поддаются гибридные файловые системы с API GoogleFS и Hadoop. MogileFS, несмотря на ориентированность к расширению системы с помощью добавления узлов, очень часто имеет проблемы, связанные с недостаточно хорошо протестированной программной архитектурой. Симметричные файловые системы GFS и GlusterFS достаточно плохо показали свои возможности динамического расширения. Добавление узлов возможно только с условием остановки работы системы целиком, что неприемлемо с учетом необходимости обеспечения круглосуточного, бесперебойного доступа к данным. Также работа всего комплекса возможна только в пределах одного центра хранения данных, без географической удаленности узлов хранения друг от друга.
Производительность
Производительность системы в целом складывается из производительности отдельных узлов и компонентов. Различные архитектуры предназначены для различных условий эксплуатации, частоты запросов и видов данных. Однако, чтобы иметь единую шкалу оценки производительности, тестирование проводилось в одинаковых условиях и с одинаковыми типами данных для всех систем.
Для проведения испытаний различных файловых систем был собран тестовый стенд, состоящий из следующего оборудования:
- 4 файловых сервера Intel 2x Xeon, 2GE ОЗУ, 4 SATA HDD 250 Гб (использовались 2), ОС CentOS Linux 5;
- 1 сервер метаданных (для Lustre) Intel Xeon, 1 GE ОЗУ, 1 SATA 1б0 Гб, Linux 5;
- 4 клиента Intel P4, 512GE ОЗУ, 1 SATA 40 Гб, ОС CentOS Linux 5.
Инструментом тестирования была свободно распространяемая Bonnie++. Тесты проводились на разном количестве серверов и клиентов. тестирования отражены в табл. l, 2.
Количество серверов / клиентов Скоростные показатели
Чтение (КБ/с)
NFS Lustre GlusterFS GFS
1/1 49510 47753 54В03 55741
2/1 49510 4В7В3 4б2б9 7ВВ57
4/1 49510 93473 95б42 9В224
4/4 35422 27В2б5 2б125В 3202В2
Таблица 1. Зависимость пропускной способности файловой системы на чтение
от количества серверов и клиентов
Количество серверов / клиентов Скоростные показатели
Запись (КБ/с)
NFS Lustre GlusterFS GFS
1/1 30419 3522В 417б3 45452
2/1 30419 45В04 4б010 б73В9
4/1 30419 В55б7 В7б74 ВВВ73
4/4 243б9 210352 195473 29В441
Таблица 2. Зависимость пропускной способности файловой системы на запись
от количества серверов и клиентов
При доступе 1 клиента к 1 серверу все файловые системы показывают одинаковую производительность. Лишь GlusterFS и GFS немного превосходят остальные файловые системы. При доступе 1 клиента к 2 серверам наибольшую производительность показывает GFS - около 78 МБ/с при чтении и 67 МБ/с при записи. Отставание Lustre можно объяснить дополнительными вычислительными затратами, необходимыми для доступа к метаданным.
ОС CentOS
программа Результаты
Использование 4 серверов данных существенно увеличивает скорость доступа к файлам. Здесь наибольшую скорость показывает GFS - около 320 МБ/с на чтение и 298 МБ/с на запись. На втором месте Lustre - 278 МБ/с на чтение и 210 МБ/c на запись. На третьем месте GlusterFS - 261 МБ/с на чтение и 195 МБ/с на запись.
Готовность к работе
В качестве еще одного критерия выбора распределенной системы хранения данных можно выделить такой фактор, как готовность к работе или качество работы системы. Большинство систем, принимающих участие в обзоре, не могут обеспечить высокий уровень надежности и готовности к работе. Так, файловая система MogileFS имеет слабую поддержку со стороны разработчиков, не имеет библиотеки взаимодействия с популярными языками программирования, такими как, например, PHP, и проявляет нестабильность в работе. Очень часто в системе появляются лишние, не удаленные копии файлов. Файловые системы GlusterFS и Hadoop также имеют проблемы с обеспечением стабильной работы системы. В почтовых рассылках и службе технической поддержки часто появляются сообщения о нестабильной работе или проблемах с чтением/записью данных.
Модель системы
Подводя итоги всестороннего обзора и изучения существующих распределенных систем, обратим внимание на сводную таблицу характеристик шести файловых систем (табл. 3). В первом столбце представлена самая распространенная сетевая файловая система NFS, которая служит лишь для иллюстрации отличия обычных файловых систем от систем распределенного хранения данных. По таблице можно увидеть, что наиболее приближенными, обеспечивающими специфические требования работы с Web-сервисами, системами хранения данных, являются Hadoop и MogileFS. На рисунке схематично представлена распределенная система хранения, разработанная с учетом архитектур этих двух систем, а также с учетом проведенных выше исследований.
Свойства Файловые системы
NFS Lustre GlusterFS GFS Hadoop MogileFS
Работа в составе распределенной системы Да Да Да Да Да Да
Наличие головного узла метаданных Нет Да Нет Нет Да Да
Необходимость резервирования головного узла Нет Да Нет Нет Да Да
Posix-совместимая система Да Да Да Да Нет (через API) Нет (через API)
Прозрачность доступа к данным Нет Да Да Да Да Да
Межузловое резервирование данных Нет Зеркали-рование Зеркали-рование Зеркали-рование Многократное Многократное
Необходимость внутри-узлового резервирования Да Да Да Да Нет Нет
Работа в WAN сетях Нет Да Нет Нет Да Да
Горизонтальное масштабирование 0 5 3 3 5 4
Производительность 3 4 5 5 4 2
Стабильность работы 5 5 3 4 3 3
Таблица 3. Характеристики файловых систем
Рисунок. Модель распределенной системы хранения данных
Для совместной работы множества узлов, распределения нагрузки на узлы и контроля целостности системы необходимо присутствие сервера метаданных, содержащего в себе информационную карту распределения файлов по узлам хранения. Отсутствие такого компонента в системе не сможет обеспечить требуемой расширяемости и управляемости, что косвенно подтвердилось в процессе эксплуатации системы GFS без сервера метаданных.
Количество серверов метаданных должно быть более 1, чтобы данный компонент не стал единой точкой отказа системы. В процессе построения системы необходимо учитывать время переключения между основным и запасным сервером метаданных, а также нагрузку на сервер метаданных, которая возникает в процессе работы клиентов с системой хранения.
Минимальной единицей хранения объекта в системе является целый файл, а не его фрагменты. Такое решение увеличит надежность системы, так как в случае полного краха серверов метаданных можно без их участия восстановить файлы, хранимые на серверах хранения.
Следующим элементом системы будет сервер хранения данных, который будет непосредственно взаимодействовать с пользователем, предоставляя доступ к файлам. Внутреннее резервирование данных узла проводится не аппаратными средствами, а программными аналогами, обеспечивающими зеркалирование данных. В дальнейшем будут проведены испытания наиболее эффективного способа резервирования и ускорения чтения/записи данных на узлах хранения.
Средой передачи данных служит Gigabit Ethernet, а протоколом - TCP/IP. Такое решение существенно удешевляет все систему, не ухудшая ее пропускную способность, позволяя географически перемещать узлы хранения и серверы метаданных.
Взаимодействие пользователя с системой хранения происходит по следующей схеме. Пользователь посылает запрос серверам приложений на получение конкретного файла. Серверы приложений, обращаясь к серверу метаданных, получают ответ о местонахождении требуемого файла и передают его пользователю. В момент формирования ответа сервер метаданных анализирует текущую доступность серверов, содержащих необходимый файл, выбирает менее нагруженный сервер и передает ссылку на этот сервер. Пользователь получает прямую ссылку на требуемый файл и обращается к конкретному серверу хранения.
Загрузка файла в распределенную систему хранения происходит по несколько иному сценарию. Пользователь передает загружаемый файл серверу приложений, который помещается в каталог распределителя. Сервер приложений обращается за списком 3 серверов данных, готовых принять файл. Сервер метаданных на основе информации о доступности, текущей загрузки и объема доступного пространства на серверах выдает требуемый список. Происходит загрузка файла на 3 свободных узла распределенного хранилища. После успешной загрузки информация о местоположении 3 копий файла сохраняется на сервере метаданных.
Обладая тремя копиями файла, можно производить балансировку нагрузки при большом числе запросов к узлам хранения данных, а также обеспечивать сохранность данных без использования аппаратных средств резервирования.
Заключение
Основной задачей исследования было определение и анализ основных факторов, влияющих на качественные и количественные показатели функционирования систем хранения данных. Для выполнения этой задачи были сформулированы основные требования к системе, рассмотрены наиболее распространенные методы построения распределенных систем, просчитаны необходимые объем и структура хранилища, вероятность выхода из строя носителей информации в процессе их эксплуатации, а также рассмотрены способы резервирования дискового пространства системы.
По результатам исследования можно сделать вывод, что ни один из рассмотренных в данной статье принципов построения распределенных хранилищ не смог без существенных доработок обеспечить требуемые характеристики. Однако в результате изучения основных характеристик подобных систем были выявлены сильные и слабые стороны архитектуры, определены ключевые параметры системы, которые могли бы повлиять на работу всего комплекса. Эти параметры необходимо учесть при построении функциональной модели новой распределенной системы хранения данных.
На следующем этапе исследования на основе выработанных требований и предложенной архитектуры системы планируется разработать действующий прототип системы с базовой функциональностью, а также провести разноплановое тестирование для подтверждения правильности выбранной архитектуры и логики работы системы.
Литература
1. Качуров В. Современные распределенные файловые системы для Linux: Основные сведения (перевод) // Компьютерра. - 2002. - № 9.
2. Шнитман В., Кузнецов С. Аппаратно-программные платформы корпоративных информационных систем // Информационно-аналитические материалы Центра информационных технологий. - Режим доступа: http://www.citmgu.ru, своб.
3. Николов А. Кластерные системы высокой готовности // БУТБ:Россия. - 2005. - № 8.
4. Hoff Т. Google Architecture. Материалы сайта HighScalability.com, 2008. - Режим доступа: http://highscalability.com/google-architecture, своб.
5. Hammonds K. H. How Google Grows...and Grows...and Grows // Журнал FastCompany. - 2003. - Режим доступа: http://www.fastcompany.com/magazine/69/google.html, своб.
6. Инструкция пользователя Lustre 1.6, 2007. - Режим доступа: http://manual.lustre.org/manual/LustreManual16_HTML/TOC.html, своб.
7. Егоров А. RAID 0, RAID 1, RAID 5, RAID 10, или что такое уровни RAID? Материалы компании «ТИМ», 2005. - Режим доступа: http://www.timcompany.ru/article4.html, своб.
8. Фильчаков А. Кластеры и кластеризация // КомпьютерПресс. - 2000. - № 10.
9. Пресс-релиз Red Hat Enterprise Linux 5 Оптимальное решение для финансовых организаций. Материалы компании Red Hat, 2007. - Режим доступа: http://www.redhat.com, своб.
10. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. -СПб: Питер, 2003. - 877 с.
11. Вахалия Ю. UNIX изнутри. - СПб: Питер, 2003. - 844 с.
Лукьянов Николай Михайлович
Кириллов Владимир Васильевич
— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, аспирант, [email protected], [email protected]
— Санкт-Петербургский государственный университет информационных технологий, механики и оптики, кандидат технических наук, профессор, [email protected]
УДК 681.3.06
МЕТОД РАЗБОРА ИСХОДНЫХ ТЕКСТОВ ПО УПРОЩЕННОЙ ГРАММАТИКЕ ЯЗЫКА
Д.Б. Арефьев, В.Л. Верещагин, А.И. Галанов, А.А. Молдовян
Статья рассматривает метод разбора исходных текстов, основанный на упрощенном множестве порождающих правил грамматики. Приводится концепция метода и сведения об эффективности применения на практике.
Ключевые слова: защита, информация, уязвимости, анализ, грамматика, исходный текст.
Введение
Опыты, приведенные в данной статье, были выполнены в рамках создания специального комплекса, предназначенного для контроля уязвимостей программ. Данный комплекс работает с исходными текстами и создан с целью повышения эффективности существующих методов контроля. Одни методы предполагают прямой поиск заданных выражений, другие используют отладочную информацию, третьи справедливо считают, что для корректного исследования программы необходимо выполнить полный лексический и синтаксический анализы. При разработке нового комплекса был учтен опыт практического применения этих методов, и в данной статье предлагается исследование метода разбора по упрощенной грамматике языка. Для эксперимента был выбран язык ANSI C (99) по нескольким причинам: язык широко применяется в промышленности, достаточно прост для разбора и обладает низкой защищенностью.
Программный комплекс предоставляет эксперту сведения о безопасности программы на основе данных, полученных в результате разбора исходных текстов по правилам грамматики языка. Формирование полной грамматики является достаточно трудоемким занятием. С другой стороны, ни одна из исследованных программ не использовала полную мощность языка, что позволило использовать только такое количество
