CC BY
417
РАСПРЕДЕЛЕННЫЕ СИСТЕМЫ ХРАНЕНИЯ ДАННЫХ: АНАЛИЗ, КЛАССИФИКАЦИЯ И ВЫБОР
© Мазур Э.М.*
Автономная некоммерческая организация высшего образования «Университет Иннополис», г. Иннополис
В данной статье проанализирован ряд решений в области систем распределенного хранения данных, а также их способы решения основных проблем предметной области, а именно: проблемы масштабирования систем, согласованности данных, их доступности и устойчивости к разделению. В ходе анализа были выявлены закономерности, в результате которых была проведена попытка классифицировать системы по различным параметрам, в частности по наличию или отсутствию конкретных функций и механизмов. На основе данных анализа и классификации были сформированы подходы к выбору систем распределенного хранения данных.
Ключевые слова программно-определяемые хранилища; облачное хранилище; объектное хранение; распределенная файловая система; кластерная файловая система; архивное хранение; дедупликация; георепликация; пределы масштабируемости системы; архитектура; окружение рабочей среды; кроссплатформенность; поддержки интерфейсов доступа; аутентификация; обеспечение конфиденциальности данных.
Введение
Объем цифровых данных продолжает расти с колоссальной скоростью. Согласно статистике IBM на 2014 год, ежедневно в мире генерируется около 15 петабайт новой информации, а общее количество цифровых данных удваивается примерно каждые два года.
И с учетом того, что компании не торопятся увеличивать бюджет на их хранение и поддержку, разрыв между ростом объема данных и необходимыми расходами на их сопровождение продолжает увеличиваться [1].
Большинство компаний решают проблему взрывного роста данных закупкой очередного числа дисковых массивов и сетевых компонент, расширяя свои сети хранения данных. Но рано или поздно это приведет к усложнению администрирования системы (резервирование, архивирование и т.д.), и, соответственно, увеличению расходов на поддержание. Так что, можно сказать, что горизонтальное масштабирование никак не уменьшит капитальные и операционные затраты на хранение и сопровождение.
Системный аналитик.
34
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
На фоне этих проблем за последние несколько лет можно наблюдать динамику увеличения в сети информации о новых решениях в области распределенного хранения данных - software defined storage (Программно-определяемые хранилища). SDS предоставляют автоматизированные и политико-ориентированные сервисы хранения, учитывающие особенности клиентов и приложений, использующие базовую инфраструктуру хранения и поддержку в целом программно-определяемой среды. При правильном развертывании SDS становится надежным решением для заказчиков, заваленных огромными объемами данных, которые хранятся на сложном аппаратном оборудовании от разных вендоров [2]. SDS - это тренд и становится очевидным, что производители по-разному определяют, что есть их решение: облачное хранилище, распределенная файловая система, или кластерная файловая система и т.д.
Мы условно объединили все решения, будь то распределенные файловые системы, кластерные файловые системы или облачные платформы в «Системы распределенного хранения данных», и поставили цель - разобраться в огромном числе таких решений и сформировать подходы к выбору систем распределенного хранения данных.
Для достижения нашей цели, был поставлен ряд задач:
1. Сформировать список систем для анализа;
2. Изучить каждую систему и провести сравнительный анализ выбранных систем;
3. Классифицировать системы, определив возможные закономерности;
Телекоммуникационные системы и компьютерные сети
35
4. На основе данных анализа и классификации сформировать подходы к выбору систем распределенного хранения данных.
Статья предназначена в первую очередь для тех, кто также как и мы, начали интересоваться возможностью эффективного хранения данных и хочет определить обоснование выбора того или иного решения, а также для тех, кому в принципе интересна тема распределенного хранения данных.
1. Выборка систем для анализа
Забежим вперед, сказав, что в нашем списке оказалось порядка ста элементов. Для того, чтобы его сформировать, мы использовали интернетстатьи, любые упоминания на форумах, в комментариях к обсуждениям, также очень полезной оказалась статья в Wikipedia [3].
Список получился действительно внушительным и было решено сократить его до приемлемого уровня. Была предложена формула вычисления рейтинга системы, опирающегося на два показателя: количество релевантных ссылок в Google и среднее количество запросов в Google Trends за 2014 год [4]. Формула высчитывает средневзвешенное значение и результат отображается в процентах.
Проранжировав список по рейтингу, удалось сразу определить лидеров рынка:
1. Amazon Simple Storage Service - 29.49 %.
2. Google File System (а точнее 2-я версия GFS - «Colossus») - 27.11 %.
3. Microsoft Azure - 12.00 %.
Во вторую группу можно отнести системы, рейтинг которых оказался от 1 до 10 %:
4. Global File System 2 - 8.43 %.
5. Ceph - 5.22 %.
6. Hadoop FS - 3.75 %.
7. Windows DFS - 2.62 %.
8. Quantcast File System - 2.02 %.
9. Gluster - 1.76 %.
Все остальные системы были определены в третью группу: Self-certifying File System, Server Message Block FS, General Parallel File System, VM-ware Virtual SAN, Openstack SWIFT, ViPR, Microsoft SharePoint Workspace, Data ONTAP, Rackspace Cloud Files, AcroStorage, Chord File System, OdinSto-rage, dCache, GridFS, Elliptic Network, Cassandra File System, ExaFS, Moose File System, Coda, Coherent Remote File System, MogileFS, Apple Filing Protocol, Starfish, Lustre, CloudStore, GLORY-FS, StarFS, SmartCloud Virtual, Far-site, NetWare Core Protocol FS, Chiron FS, Parallel NFS, Oceanstore, OpenAFS, Kyoto Tycoon, Arla, InterMezzo, Panasas ActiveScale File System, HAM-MER/ANVIL, Sheepdog, MapR-FS, OneFS, Cleversafe, OS4000, Gfarm, Tahoe-LAFS, OrangeFS, zFS, XtreemFS, LeoFS, IBRIX Fusion, OriFS, IFS (EMC Isi-
36
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
lon), TerraGrid, Unilium, BeeGFS, PlasmaFS, TorFS, WebDFS, PeerFS, Nim-busFS.
Девять систем - недостаточная выборка для анализа и поэтому было решено выбрать несколько систем из третьей группы, которые представляли интерес для анализа.
Итого в финальную выборку попали следующие 30 систем:
Amazon S3, Google File System, MS Azure, Global File System 2, Ceph, Hadoop FS, Windows DFS, Quantcast File System, Gluster, AcroStorage, OdinS-torage, TorFS, VMware Virtual SAN, OpenStack SWIFT, ViPR, Rackspace, dCache, GridFS, Elliptics Network, MooseFS, CODA, Lustre, OceanStore, Ope-nAFS, Kyoto Tycoon, Arla, Tahoe, zFS, Leo FS, Andrew File System.
2. Анализ систем
В ходе сравнительного анализа были изучены основные функциональные возможности системы (архивное хранение, дедупликация, георепликация и т.д.) и характеристики системы (пределы масштабируемости системы, архитектура, окружение рабочей среды и т.д.). Также были проанализированы механизмы безопасности системы и средства самоорганизации систем.
2.1. Анализ основных функциональных возможностей систем
Проанализировав основные функциональные возможности систем и опираясь на классификацию, данную в «A Taxonomy of Distributed Storage System», были выделены следующие функции и механизмы [5]:
- Функция архивного хранения;
- Функция сжатия данных (Compressing);
- Функция дедупликации данных (Deduplication);
- Механизм регулируемой избыточности по (п,к)-схеме;
- Механизм предоставления пользовательского интерфейса файловой системы;
- Механизм совместного доступа к данным;
- Механизм георепликации;
- Механизм хранения данных на уровне объектов (Object Storage);
2.1.1. Функция архивного хранения
Архивное хранение предоставляет возможность резервного хранения и извлечения данных, основным сценарием использования которых является, так называемое, «холодное хранение», т.е. однократная запись данных с целью их долгосрочного хранения. Обычно к таким данным обращаются в исключительных случаях [6]. На диаграмме (рис. 1) показано процентное соотношение проанализированных систем в разрезе наличия функции архивного хранения.
Телекоммуникационные системы и компьютерные сети
37
Рис. 1. Процентное соотношение проанализированных систем
Хотелось сделать одно важное замечание. Большинство проанализированных систем являются закрытыми, поэтому в данном и во всех последующих случаях, если функционал не был заявлен в явном виде, то мы определяли это, как его отсутствие.
Итак, как видно из диаграммы, функция архивного хранения заявлена более чем в половине проанализированных систем, в том числе ее используют и лидеры рейтинга: Amazon S3, Google FS и MS Azure.
2.1.2. Функция сжатия данных (Compression)
Сжатие данных - алгоритмическое преобразование данных, производимое с целью уменьшения занимаемого ими объёма [7]. Соответственно, в предлагаемой классификации можно выделить 2 группы систем: системы, которые используют такую функцию, и системы, которые не используют такую функцию.
Рис. 2. Использование сжатия данных
38
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
Из анализа видно (рис. 2), что менее четверти систем используют функцию сжатия данных. Стоит обратить внимание на то, что среди них нет ни одной «лидирующей» системы. К отличившимся системам, которые явно определили возможность использования функции сжатия, можно отнести: Ceph, HadoopFS, Gluster, RackSpace и dCashe.
2.1.3. Функция дедупликации данных (Deduplication)
Дедупликация данных - это технология, при помощи которой обнаруживаются и исключаются избыточные данные в дисковом хранилище [8]. Дедупликация бывает на уровне файлов и на уровне блоков.
File-level deduplication (дедупликация на уровне файлов) - единицей дедупликации в данном методе является отдельный файл, когда дублирующие файлы исключаются из системы хранения данных.
Block-level deduplication (дедупликация на уровне блоков) - здесь единицей дедупликации является блок данных произвольной длины, который часто повторяется в различных логических объектах системы хранения данных [9].
Соответственно, в предлагаемой классификации можно выделить 3 группы систем:
- системы, которые используют функцию дедупликации на уровне файлов;
- системы, которые используют функцию дедупликации на уровне блоков;
- системы, которые не используют функцию дедупликации.
Дедупликация данных
10% 7%
83%
'Ч
■ Blocks level ■ No ■ File level
Рис. 3. Использование дедупликации
Телекоммуникационные системы и компьютерные сети
39
Функцию дедупликации, как и функцию сжатия, поддерживают менее четверти проанализированных систем (рис. 3). Системы, поддерживающие дедупликацию на уровне блоков: Ceph, RackSpace. Системы, поддерживающие дедупликацию на уровне файлов: лидер Amazon S3, HadoopFS и Windows DFS.
Лидеры рейтинга: Google FS и MS Azure - не поддерживают дедупликацию.
2.1.4. Механизм регулируемой избыточности по (п,к)-схеме
Речь идет о поддержке, так называемых «erasure codes». Суть таких кодов заключается в том, что после кодирования некоторого файла получается n фрагментов данных. Каждый из фрагментов сохраняется в отдельном облачном хранилище. Для восстановления первоначального файла достаточно собрать k любых фрагментов и декодировать. Необходимо заметить, что n > k. Остальные (n - k) фрагментов могут быть удалены, испорчены, недоступны и т.д. Таким образом, система, использующая «erasure codes» может справиться с появлением ошибок в (n - k) фрагментах (рис. 4) [10, 11].
Рис. 4
Регулируемая избыточность (n,k)
43%
57%
1
■ Yes ■ No
Рис. 5. Диаграмма регулируемой избыточности
40
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
Соответственно, в предлагаемой классификации можно выделить 2 группы систем (рис. 5): системы, которые предоставляют такой механизм, и системы, которые не предоставляют такой механизм.
Как видно из диаграммы, наличие механизма регулируемой избыточности по (n,k)-схеме присутствует менее, чем в половине проанализированных систем. Лидеры систем также разделились: функцию поддерживают только MS Azure и Google FS. Скорее всего, Amazon S3 тоже должен поддерживать эту функцию, в том или ином виде, однако функционал в явном виде заявлен не был.
2.1.5. Механизм совместного доступа к данным
Анализ показал, что не каждая система предоставляет функцию совместного доступа к данным. Также, среди тех систем, которые обладают таким механизмом, можно выделить системы с обязательной авторизацией пользователя (не путать с аутентификацией) и без авторизации [5].
Соответственно, в предлагаемой классификации можно выделить 3 группы систем:
- системы, которые предоставляют совместный доступ с обязательной авторизацией (Sharing-systems);
- системы, которые предоставляют совместный доступ без обязательной авторизации (Anonymity-systems);
- системы, которые не предоставляют совместный доступ.
Совместный доступ к файлам
17%
40%
43%
Г
■ Anonymity ■ Sharing ■ No
Рис. 6. Совместный доступ к файлам
Как видно из диаграммы (рис. 6), больше половины систем предоставляют механизм совместного доступа, в том или ином виде. Все лидеры рейтинга предоставляют доступ без авторизации. Так же в эту группу попали системы: HadoopFS и Rackspace.
Телекоммуникационные системы и компьютерные сети
41
К системам, предоставляющим совместный доступ к файлам с обязательной авторизацией, можно отнести: Global File System 2, Ceph, QFS, Gluster, CODA, dCache, Elliptics Network, Leo FS, Lustre, SWIFT, ViPR, zFS, AFS.
2.1.6. Механизм георепликации
Георепликация - это механизм синхронизации нескольких копий объекта между географически удаленными дата-центрами [12]. Соответственно, в предлагаемой классификации можно выделить 2 группы систем: системы, которые предоставляют такой механизм, и системы, которые не предоставляют такой механизм.
Рис. 7. Применение георепликации в системах
Как видно из диаграммы (рис. 7), механизм георепликации есть почти в половине проанализированных систем, в том числе ее используют и лидеры рейтинга: Amazon S3, Google FS и MS Azure.
2.1.7. Механизм хранения данных на уровне объектов (Object Storage)
Объектное хранилище представляет собой архитектуру хранения данных, которая в отличие от файловой системы, управляет данными на уровне объектов, а не на уровне блоков и секторов [13].
Одним из базовых принципов объектного хранения является абстрагирование от множества низкоуровневых задач хранения. Администраторы не должны выполнять функции управления логическими томами, контроля использования объема диска или настройки RAID-массивов, что уменьшает сложность управления системой хранения, тем самым значительно снижая затраты на поддержку [13].
42
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
Объектное хранилище абстрагирует технологическую часть обеспечения хранения данных, что позволяет легко масштабировать систему, снимает зависимость от ограничения аппаратной части, чего нельзя сказать о классических массивах [14].
Таким образом, объектное хранилище предоставляет сравнительно недорогой масштабируемый инструмент, который отлично подходит для эффективного хранения большого числа неструктурированных данных. Однако эти преимущества достигаются за счет снижения требований к согласованности. Более подробно об этом будет рассказано в разделе 2.6.6.
Возвращаясь к анализу, хранение данных на уровне объектов поддерживает почти половина проанализированных систем, в том числе и все лидеры рейтинга (рис. 8).
Рис. 8. Применение хранения данных на уровне объектов в системах 2.2. Анализ основных характеристик системы
Помимо основных функциональных возможностей системы в ходе сравнительного анализа было проведено исследование нефункциональных характеристик системы. В ходе анализа получилось выделить следующие характеристики:
- архитектура системы;
- масштабируемость (по объему данных, по количеству серверов, по количеству пользователей);
- кроссплатформенность (серверной и клиентской части);
- поддержка интерфейсов доступа NFS, SMB, https, WebDAV, S3 или проприетарный протокол;
- окружение рабочей среды;
- решаемость проблем САР-теоремы.
Телекоммуникационные системы и компьютерные сети
43
2.2.1. Архитектура
Проанализировав архитектуры систем, удалось разделить их на два больших класса: системы с клиент-серверной архитектурой (client-server) и системы с одноранговой архитектурой (peer-to-peer). В первом случае узел может играть роль либо исключительно клиента, либо исключительно сервера, а в одноранговой же наоборот, любой узел может быть одновременно как клиентом, так и сервером.
Суть клиент-серверной архитектуры заключается в сосредоточивании всех функций управления в одном месте, что дает оптимальный уровень безопасности и надежности, а также хорошую производительность. Однако концентрация всех функций управления в одном месте становится и узким звеном - страдает масштабируемость и отказоустойчивость системы - выход из строя сервера, выводит из строя всю систему.
Можно выделить два типа клиент-серверной архитектуры: глобальноцентрализованная (globally-centralized) и локально-централизованная (locally-centralized). В первом случае только один сервер отвечает за предоставление услуг и обслуживание клиентов, и на лицо все проблемы клиент-серверной архитектуры. Во втором случае можно добиться большей масштабируемости и отказоустойчивости за счет того, что функции управления распределены между группой серверов, которые общаются между собой путем репликации данных. Тем не менее, системы с клиент-серверной архитектурой по-прежнему имеют пределы масштабирования.
В противовес клиент-серверной архитектуре одноранговая архитектура более пригодна в ненадежных средах, где функции управления и хранения распределены между всеми узлами. К преимуществам одноранговой архитектуры можно отнести высокую масштабируемость, самоорганизацию и отказоустойчивость. Однако у таких систем есть свои недостатки: это низкий уровень безопасности и сложность управления, по сравнению с клиентсерверной архитектурой.
Можно выделить три типа одноранговой архитектуры: глобальноцентрализованная (globally-centralized), локально-централизованная (locally-centralized) и чисто одноранговая система (pure peer-to-peer). В первом случае один из узлов системы считается центральным сервером, в котором хранится информация о других узлах системах. Как и в случае с клиентсерверной архитектурой, страдает масштабируемость и отказоустойчивость системы. Во втором случае функции центрального сервера распределены между несколькими узлами, обладающими высокой производительностью. Такие узлы называются супер-узлами или супер-серверами и их основная функция заключается в предоставлении клиентам информации, связанной с расположением и доступностью данных.
44
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
И, наконец, в чисто одноранговой архитектуре нет выделенных узлов, которые определяют расположение других узлов. Каждый узел может быть сервером и клиентом, что делает одноранговую систему очень хорошо адаптируемой в динамичной среде, где узлы могут в любое время подключиться или отключиться от сети. К недостаткам можно отнести низкую производительность и асимметрию нагрузки, для решения которой система должна иметь специализированные механизмы. Также в системе должны быть реализованы механизмы безопасности, которые должны уменьшить количество угроз, воздействию которых система подвергается постоянно [15].
Рис. 9. Применение различных типов архитектор в системах
Как видно из диаграммы (рис. 9), более % проанализированных систем имеют клиент-серверную архитектуру, и архитектура большей части этих систем относится к локально-централизованной. Лидеры рынка также относятся к их числу.
Менее 20 % систем имеют одноранговую архитектуру, и среди них мы не обнаружили ни одной глобально-централизованной архитектуры.
2.2.2. Масштабируемость
Мы проанализировали заявленные пределы масштабирования систем по максимальному объему хранимых данных, по количеству серверов и по количеству пользователей, которые могут одновременно работать с системой.
Исследуя системы, мы постарались уйти от качественной шкалы оценки и выяснить числовые показатели масштабирования. Этого удалось достичь не для всех систем, т.к. некоторые указывали абстрактное «Много (а
Телекоммуникационные системы и компьютерные сети
45
lot)», некоторые заявляли, что их возможности безграничны. Также были системы, по которым мы не смогли найти информацию о пределах масштабирования. Итого, мы условились, что «Неограниченно» - это максимальная оценка в шкале, «Много» - это на 1 порядок ниже, чем «Неограниченно», а «Неизвестно» - это минимальная оценка в шкале.
Таким образом, получились следующие шкалы масштабирования:
Объем данных:
Unknown < Petabytes (1015) < Exabytes (1018) < Brontobytes (1027) < Not limited
- Количество серверов:
- Unknown < x 10 < x 102 < x 103 < A lot < Not limited
- Количество пользователей:
- Unknown < x102 < x103 < x104 < x 106 < Not limited
Чтобы увидеть всю картину в целом, ниже представлена диаграмма, объединяющая все три параметра (рис. 10):
Анализируя диаграмму, можно сделать следующие крупноблочные выводы:
- Порядка 7 систем заявляют, что их возможности неограниченны, или, как они уточняют, предел их масштабирования ограничивается лишь бюджетом компании. Также следует заметить, что среди данных систем нет ни одного лидера рейтинга;
- Больше трети систем измеряют свой предел объема данных в петабайтах, буквально единицы - в эксабайтах и бронтобайтах;
46
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
- У шестой части проанализированных систем не удалось найти информацию по пределам масштабирования;
- И, в заключение, можно заметить следующий тренд: ряд систем, в том числе и все лидеры рынка, определяют свои пределы, как «Много серверов», «Миллионы пользователей» и «Пе -табайты данных».
2.2.3. Кроссплатформенность
Анализируя поддержку платформ серверной и клиентской части, получились следующий результаты (рис. 11):
Кроссплатоформенность серверной части
Кроссплатоформенность клиентской части
■ Cross ■ Linux ■ Unknown ■ Windows
■ Cross ■ Linux ■ No ■ Windows
Рис. 11. Поддержка платформ серверной и клиентской части в системах
Больше половины систем отдает предпочтение Unix-платформам, если речь идет о серверной части, к таким системам относятся лидеры Amazon S3 и Google FS. Лидер MS Azure относится к 10 %, чья серверная часть опирается на Windows.
У двух третей проанализированных систем кроссплатформенная клиентская часть, в том числе, и у всех трех лидеров рейтинга.
2.2.4. Поддержка интерфейсов доступа
Одним из критериев анализа систем было наличие поддержки интерфейсов доступа, а именно возможность подключения (монтирования) файловых систем NFS, SMB и протоколов доступа REST API (S3), WebDAV.
Ниже представлена диаграмма (рис. 12) с информацией о распределении систем в разрезе количества поддерживаемых интерфейсов доступа, перечисленных выше.
Телекоммуникационные системы и компьютерные сети
47
Рис. 12. Количество поддерживаемых интерфейсов доступа в системах
Однако на диаграмме выше не учитывались собственные проприетарные интерфейсы доступа, которые есть у большинства систем. Если добавить эту информацию, то получится следующая диаграмма (рис. 13):
Количество поддерживаемыхФС и протоколов
14
Рис. 13. Количество поддерживаемых ФС и протоколов в системах
Как видно из второй диаграммы, у большинства систем есть собственные разработанные интерфейсы доступа. Следует заметить, что всего две системы поддерживают все 4 интерфейса, и это Ceph и HadoopFS, причем Ceph также имеет и свой собственный проприетарный интерфейс. Также есть 5 систем, которые имеют только проприетарные интерфейсы, и это лидер Google FS и системы zFS, TorFS, QFS, OceanStore.
48
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
Лидеры рейтинга Amazon S3 и MS Azure относятся к группе «1 из 4» и это протоколы REST API (S3).
На следующей диаграмме видно, что самым популярными интерфейсами являются NFS и REST API, а также больше половины систем имеют собственные проприетарные интерфейсы доступа (рис. 14).
Поддерживаемые интерфейсы доступа
NFS SMB REST API (S3J WebDAV Proprietary
Поддержи &a еглы e и нтерфей сы доступ а
Рис. 14. Поддерживаемые интерфейсы доступа 2.2.5. Окружение рабочей среды
Окружение рабочей среды - это важный аспект функционирования любой распределенной системы. Доверенная среда обычно изолирована от чужих сетей, что делает ее предсказуемой и легко-управляемой. Контролируемая среда обеспечивает высокий уровень качества обслуживания и доверия, однако, значительно ограничивает масштабирование. Ненадежная среда, наоборот, подразумевает тесное взаимодействие с сетями открытого доступа. В открытой среде сложно, если вообще возможно, вести какой-либо учет и контроль за пользователями. Системы, расположенные в ненадежной среде, подвержены множеству атак, и поэтому они должны быть оснащены дополнительными механизмами обеспечения безопасности.
Анализируя системы, мы выделили 4 основных типа окружающих рабочих сред: доверенная (Trusted), частично-доверенная (Partially trusted), ненадежная (Untrusted), чужая инфраструктура (Alien Infrastructure).
В случае, если система развернута на собственной инфраструктуре, т.е. внутри корпоративной локальной сети, и на собственном аппаратном обеспечении, а также, если на аппаратной платформе не установлено любое другое ПО, то такое окружение будем считать доверенным.
Аналогично предыдущему, в случае, если система развернута на собственной инфраструктуре, т.е. внутри корпоративной локальной сети и на
Телекоммуникационные системы и компьютерные сети
49
собственном аппаратном обеспечении, но при условии, что на аппаратной платформе установлено хотя бы одно отличное ПО, то такое окружение будем считать частично-доверенным.
В случае, если система развернута на собственном аппаратном обеспечении, но связана через чужеродную сеть, в частности сеть Интернет, то такое окружение будем считать ненадежным.
В случае, если система развернута на чужом аппаратном обеспечении, и связана через чужеродную сеть, в частности, сеть Интернет, то такое окружение будем называть чужая инфраструктура.
Окружение рабочей среды
13%
67%
■ Alien Infrastructure ■ Untrusted ■ Partially trusted «Trusted Рис. 15. Окружение рабочей среды
Как видно из диаграммы (рис. 15) лишь треть систем способна работать в недоверенных средах и только Tahoe способна работать в окружении «Чужая инфраструктура». Это достигается, во-первых, за счет того, что все данные в Tahoe шифруются, кодируются по (n - k) схеме и хэшируются, и, во-вторых, за счет использования принципа «Минимальных привилегий» при организации доступа к ресурсам [16].
Лидеры рейтинга Amazon S3 и MS Azure относятся к 67 % систем, которые способны работать только в доверенной среде.
Лидер рейтинга Google FS относится к тем 13 % систем, которые способны работать и в частично-доверенных средах.
2.2.6. Решаемость проблем САР-теоремы
Согласно Википедии, теорема CAP (известная также как теорема Брюера) определяется, как эвристическое утверждение о том, что в любой реали-
50
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
зации распределённых вычислений возможно обеспечить не более двух из трёх следующих свойств:
- согласованность данных (англ. consistency) - во всех вычислительных узлах в один момент времени данные не противоречат друг
другу;
- доступность (англ. availability) - любой запрос к распределённой системе завершается корректным откликом;
- устойчивость к разделению (англ. partition tolerance) - расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций [17].
Во второй половине 2000-х годов сформулирован подход к построению распределённых систем, названый акронимом BASE (от англ. Basically Available, Soft-state, Eventually consistent - базовая доступность, неустойчивое состояние, согласованность в конечном счёте), в которых требования целостности и доступности выполнены не в полной мере.
Существует множество моделей согласованности (консистенции), но среди проанализированных систем встретились только следующие три:
- Строгая согласованность (Сильная, Strong);
- Согласованность в конечном счете (Eventual);
- Слабая согласованность (Weak).
Строгая согласованность - это модель согласованности, гарантирующая, что после завершения обновления, любой последующий доступ к данным вернет обновленное значение [18].
Согласованность в конечном счете - это модель согласованности, гарантирующая, что при отсутствии изменений данных, в конечном счете все запросы будут возвращать последнее обновленное значение.
Слабая согласованность - это модель согласованности, не гарантирующая, что последующие обращения к данным вернут обновленное значение. Перед тем, как будет возвращено обновленное значение, должен выполниться ряд условий. Период между обновлением и моментом, когда каждый наблюдатель всегда гарантированно увидит обновленное значение, называется окном несогласованности (inconsistency window).
Чтобы увидеть всю картину в целом и понять, каким двум из трех параметров САР -теоремы удовлетворяют проанализированные системы, ниже представлена диаграмма, объединяющая все три параметра (рис. 16).
Как видно из диаграммы, больше половины систем являются «PA», т.е. реализованы в ущерб согласованности и являются CAP-доступными и устойчивыми к разделению, причем одна половина этих систем поддерживает согласованность в конечном счете, а вторая половина поддерживает слабую согласованность.
Телекоммуникационные системы и компьютерные сети
51
Рис. 16. Диаграмма согласованности
Лидеры рейтинга также относятся к таким системам: Amazon S3 обеспечивает согласованность в конечном счете, Google FS слабую согласованность. Однако, стоить отметить реализацию системы MS Azure. Создатели Azure утверждают, что они достигли решения всех трех проблем и обеспечивают строгую согласованность вкупе с доступностью и устойчивостью, но с оговоркой, что это действует только для определенных типов падений системы, в частности «node failures» и «top-of-rack» падений. Решение трех проблем достигается за счет того, что задачи обеспечения строгой согласованности и обеспечения доступности разделены на два разных уровня: Stream Layer и Partition Layer соответственно. Stream layer в случае падения узла / стойки переключается на работоспособный узел / стойку и продолжает работу (чтение / запись) с ним. Partition Layer в это время идентифицирует потерянные данные и дублирует их по работоспособным узлам / стойкам [19].
На втором месте оказались «CA»-системы, реализованные в ущерб устойчивости к разделению, но поддерживающие строгую согласованность и доступность. Однако, стоит выделить 2 системы, которые, строго говоря, нельзя отнести к «СА»-системам, т.к. они обеспечивают слабую согласованность.
На третьем месте оказались «РС»-системы, реализованные в ущерб доступности, но поддерживающие строгую согласованность и устойчивость к разделению.
52
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
2.3. Анализ функций безопасности и средств самоорганизации систем
2.3.1. Функции безопасности систем
К основным функциям безопасности распределенных систем можно отнести:
- Аутентификация пользователей;
- Управление доступом к данным;
- Обеспечение конфиденциальности данных;
Аутентификация пользователей может быть реализована, как на основе
локальной базы, расположенной в рамках системы, так и на основе сетевых протоколов авторизации (Kerberos, Radius, LDAP и т.д.).
■ Client side aStorageside ■ No
Рис. 17. Диаграммы аутентификации, списка контроля доступа, шифрования
Телекоммуникационные системы и компьютерные сети
53
Для решения вопроса управления доступом к данным чаще всего используется такой механизм, как списки контроля доступа или access control list (ACL).
Конфиденциальность данных обеспечивается за счет механизма шифрования.
Как видно из диаграмм (рис. 17):
- Большинство систем для аутентификации используют локальную базу пользователей, в том числе и все лидеры рейтинга. Однако, стоит принять во внимание тот факт, что для многих систем не получилось найти какую-либо информацию про механизмы аутентификации;
- Больше трех четвертей проанализированных систем, в том числе и лидеры рейтинга, используют списки контроля доступа;
- Почти две трети систем не используют шифрование. Из всех лидеров рейтинга, только Amazon S3 использует шифрование. Шифрование реализовано на клиентской стороне и использует симметричный алгоритм шифрования AES в режиме GCM с 256-битными ключами шифрования [20].
2.3.2. Анализ средств самоорганизации систем
Под самоорганизацией (Self-management) систем понимается процесс, при котором компьютерные системы управляют своей собственной работой без человеческого вмешательства. Современные распределенные, да и любые компьютерные, системы неоднородны и представляют собой комбинацию различных информационных технологий, сочетая сетевые, мобильные, беспроводные технологии. Ручное управление такими системами сложно и трудозатратно, и это является одним из основных факторов торможения развития таких систем [21].
Наибольший вклад в развитие самоорганизующихся систем внесла компания IBM, создавшая в 2001 году специальную инициативную группу. IBM выделяет 4 основные характеристики самоорганизующихся систем [22]:
- Самонастройка (Self-Configuration). Способность системы ставить в соответствие значения низкоуровневых параметров (например, настройки компонентов и т.д.) сложным верхнеуровневым правилам уровня бизнес-целей, и соответственно применить эти параметры;
- Самооптимизация / Самоадаптация (Self-Optimization / Self-Adaptaion). Способность системы постоянно обеспечивать контроль и управление своими ресурсами для достижения оптимального уровня функционирования в зависимости от определенных требований;
54
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
- Самовосстановление (Self-Healing). Способность системы автоматически обнаруживать и исправлять возникшие ошибки, а также восстанавливаться при отказе отдельных ее компонентов, применив для этого все необходимые действия;
- Самозащита (Self-Protection). Это способность системы защищать себя от вредоносного воздействия или каскадных сбоев. Системы, которые работают в сети Интернет, особенно уязвимы для широкого круга атак, поэтому самозащита для них особенно важна.
На диаграмме ниже видно (рис. 18), что среди проанализированных систем в основном преобладают функции самовосстановления, реже - самооптимизации и буквально единицы - функциями самонастройки и самозащиты.
Рис. 18. Средства самоорганизации систем
Функции самовосстановления можно разделить на:
- Восстановление после отказа диска (Disk failure);
- Восстановление после отказа сервера (Node failure);
- Восстановление после падения дата-центра (Datacenter failure). Результаты анализа систем на наличие функций самовосстановления
можно увидеть на диаграмме ниже (рис. 19). Больше двух третей систем поддерживают функции восстановления после отказов дисков и серверов и менее трети - функцию восстановления после падения дата-центров.
К функциям самооптимизации можно отнести:
- Оптимизацию уровня согласованности (Optimizing consistency level) - выбор эффективного уровня согласованности передаваемых данных, на основе анализа активности пользователей;
КОЛИЧЕСТВО СИСТЕМ
Телекоммуникационные системы и компьютерные сети
55
- Механизм кэширования (Caching mechanism). Название само говорит за себя, под самоадаптацией здесь понимается анализ нагрузки приложения и автонастройка параметров кэширования;
- Адаптацию работы с SSD - определение критичных к скорости элементов (кэши, журналы и т.д.), на основе анализа частоты обращения к данным и времени их считывания / записи и перенос их хранения на SSD накопители;
- Прогнозирование отказа дисков (Predicting disk failure) - использование технологий состояния жёсткого диска, например «SMART», и предсказывание времени выхода диска из строя;
- Балансировку нагрузки (Load balancing) - учет статистики работы сети и принятие решения о распределении передачи данных на другие ноды;
- Контроль электроэнергии (Control of electricity) - отключение электроэнергии из соображений экономии дисков, хранящих избыточную информацию;
- Контроль популярности контента (Control of content popularity) -определение количества обращений к данным и принятие решения об увеличении количества реплик популярного контента, или наоборот, об удалении данных, к которым длительное время не было обращений.
25
20
15
10
5
О
Функции самовосстановления
22
Восстановление после отказа диска
21
Восстановление после отказа сервера
5
Восстановление после падения дата-центра
Рис. 19. Функции самовосстановления
Результаты анализа систем на наличие функций самооптимизации можно увидеть на диаграмме ниже (рис. 20). Как видно, самой распространенной
56
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
функцией является кэширование - ее поддерживают почти половина систем, около трети поддерживают функцию адаптации работы с SSD. Функция контроля электроэнергии не была обнаружена ни у одной системы.
Рынок систем распределенного хранения данных действительно широк, и из анализа видно, что нет единого подхода к их построению. Производители, создавая системы, опираются в первую очередь на задачи бизнеса, и пытаются найти компромисс между высокой производительностью, масштабируемостью, безопасностью и простотой в управлении, что в действительности является сложной задачей.
Ниже приведен ряд выводов о необходимости наличия тех или иных функций и механизмов в распределенных системах, в зависимости от задач бизнеса.
1. Если ваша компания хранит данные, к которым не нужен каждодневный доступ, но которые необходимо хранить в течение длительного времени, например, согласно требованиям законодательства, то имеет смысл использовать механизм архивного хранения. В большинстве случаев, «холодное» хранение данных дешевле «горячего» хранения.
2. Распределенное хранилище де-факто должно быть устойчивым к разделению и согласно САР-теореме выбор остается только между согласованностью данных и их доступностью. И если вы не храните данные, которые должны быть актуальными каждую секунду, то разумнее всего поступиться согласованностью данных и использовать «РА»-модель со слабой согласованностью данных.
Телекоммуникационные системы и компьютерные сети
57
3. Такие механизмы как (щ^-кодирование, сжатие и дедупликация данных значительно сократят объем хранимой информации, однако, скорее всего, такая система будет стоить дороже.
4. Никто не защищен от природных и техногенных катастроф [23] и если вы хотите, чтобы ваша информация была защищена и от этих факторов, то разумнее хранить данные в географически удаленных друг от друга местах, используя механизм георепликации.
5. Если доступ к хранилищу осуществляется через недоверенный канал связи, то очевидно, что для обеспечения конфиденциальности данных необходимо использовать механизмы шифрования, однако если вся обработка и обращение к данным происходит в контролируемой зоне, то можно пренебречь шифрованием, тем самым увеличив производительность.
6. Влиять на такие параметры, как архитектура, кроссплатформен-ность, окружение и объектное хранение, скорее всего, не получится и нет смысла, т.к. они являются концептуальными, системообразующими, от которых будут зависеть остальные функции и механизмы. Что касается масштабируемости, то тут все зависит от бюджета компании.
Очень немногие системы обладают полноценным функционалом самоанализа и самоуправления, хотя на наш взгляд, развитие этих технологий является весьма перспективным. Наличие в системе средств самоорганизации говорит о ее гибкости, что является важным фактором в современных реалиях бизнеса.
Заключение
В рамках данной исследовательской работы было проанализировано порядка 30 систем распределенного хранения данных. В ходе работы стало очевидным, что большинство проанализированных систем являются закрытыми, и было решено, что если функционал не был заявлен в явном виде, то он отсутствует, и поэтому с большой долей вероятности можно сказать, что статистические данные, приведенные в данной работе, не отражают реальную картину на все 100 %.
Не смотря на этот факт, в рамках данной работы удалось классифицировать системы по различным параметрам, в том числе, по основным функциональным возможностям, характеристикам, механизмам безопасности и средствам самоорганизации, на основе которых удалось сформировать подходы к выбору систем распределенного хранения данных. Таким образом, можно смело сказать, что задачи данной исследовательской работы были полностью решены, а цель достигнута.
Статья написана в рамках выполнения работ по Соглашению № 14.612.21.0001 о предоставлении субсидии при поддержке Министерства
58
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
Образования и науки России при выполнении ПНИЭР по теме «Разработка нового поколения облачных технологий хранения и управления данными с интегрированной системой безопасности и гарантированным уровнем доступа и отказоустойчивости».
Уникальный идентификатор ПНИЭР RFMEFI61214X0001.
Список литературы:
1. IBM Platform Computing Edition, Software Defined Storage For Dummies, New Jersey, 2014, pp. 4-5.
2. Software-Defined Storage (SDS) - perspektivy rosta [growth prospects] -Channel For IT. Available at: http://channel4it.com/blogs/Programmno-oprede-lyaemye-hranilishcha-vsyo-bolee-vostrebovany-6787.html (accessed 23 July 2015).
3. List of file systems - Wikipedia, the free encyclopedia. Available at: https://en.wikipedia.org/wiki/List_of_file_systems (accessed 23 July 2015).
4. Google Trends. Available at: https://www.google.com/trends (accessed 23 July 2015).
5. M. Placek, R. Buyya, A taxonomy of distributed storage systems, p. 53.
6. Kak Facebook sekonomil 75 % energii, kotoraya trebuetsya dlya khrane-niya dannykhpol’zovatelei [Fasebook saved 75 % of the energy required to store users' data] / King Servers company’s blog / Habrahabr. Available at: http://hab-rahabr.ru/company/kingservers/blog/257699/ (accessed 23 July 2015).
7. Data compression - Wikipedia, the free encyclopedia. Available at: https://en.wikipedia.org/wiki/Data_compression (accessed 23 July 2015).
8. Deduplikatsiya dannykh - podkhod NetApp [Deduplication - NetApp’s approach] / NetApp Company’s Blog / Habrahabr. Available at: http://habrahabr. ru/company/netapp/blog/110482/ (accessed 23 July 2015).
9. Vvedenie v deduplikatsiyu dannykh [Introducition to data duplication] / Veeam Software company’s blog. Available at: http://habrahabr.ru/company/ veeam/blog/203614/ (accessed 23 July 2015).
10. Erasure code - Wikipedia, the free encyclopedia. Available at: https://en. wikipedia.org/wiki/Erasure_code (accessed 23 July 2015).
11. О chem stoit zadumat’sya, sokhranyaya svoi dannye v oblake. Chast’ 2 [What you should thinking about, when you saving data in cloud. Part 2] / Habrahabr. Available at: http://habrahabr.ru/post/141487/ (accessed 23 July 2015).
12. Vysokaya dostupnost’ web-saita: georeplikatsia failov saita s “lsyncd” [Web site's high availability: file geo-replication of site with “lsyncd”] / Habrahabr. Available at: http://habrahabr.ru/company/infobox/blog/252751/ (accessed 23 July 2015).
13. Object storage - Wikipedia, the free encyclopedia. Available at: https://en. wikipedia.org/wiki/Object_storage (accessed 23 July 2015).
Телекоммуникационные системы и компьютерные сети
59
14. Ob’’ektnaya sistema khraneniya dannykh - konkurent zheleznykh SKHD [Object system of data storage - the competitor of hardware SAN]. Available at: http://www.jetinfo.ru/stati/konkurenty-zheleznykh-skhd (accessed 23 July 2015).
15. Y. R'kaina, Reliable and persistent storage for CoDeS a distributed collaborative system // 2013, p. 40
16. An Overview of Tahoe-LAFS. Secure and fault tolerant distributed storage system. Available at: https://code.google.com/p/nilestore/wiki/TahoeLAFS Basics (accessed 23 July 2015).
17. CAP theorem - Wikipedia, the free encyclopedia. Available at: https://ru. wikipedia.org/wiki/Теорема_CAP (accessed 23 July 2015).
18. Soglassovannye v konechnom schete [Eventually Consistent]. Available at: http://habrahabr.ru/post/100891 (accessed 23 July 2015).
19. B. Calder, J. Wang, A. Ogus, N. Nilakantan, A. Skjolsvold, S. McKelvie, Y Xu, S. Srivastav, J. Wu, H. Simitci, J. Haridas, C. Uddaraju, H. Khatri, A. Edwards, V Bedekar, S. Mainali, R. Abbasi, A. Agarwal, M. Fahim ul Haq, M. Ik-ram ul Haq, D. Bhardwaj, S. Dayanand, A. Adusumilli, M. McNett, S. Sankaran, K. Manivannan, L. Rigas Windows Azure Storage: a highly available cloud storage service with strong consistency // SOSP '11 Proceedings of the Twenty-Third ACM Symposium on Operating Systems Principles, 2011, 143-157.
20. M. Campagna, AWS Key Management Service Cryptographic Details, 2015, p. 28
21. Autonomic computing - Wikipedia, the free encyclopedia. Available at: https://en.wikipedia.org/wiki/Autonomic_computing (accessed 23 July 2015).
22. Self-management (computer science) - Wikipedia, the free encyclopedia. Available at: https://en.wikipedia.org/wiki/Self-management_(computer_science) (accessed 23 July 2015).
23. Google poteryal chast’ dannykh pol’zovatelei iz-za udara molnii - BBC Russkaya sluzhba [Google lost a part of users' data because of a lightning strike -BBC Russian Service]. Available at: http://www.bbc.com/russian/international/ 2015/08/150819_google_lightning_data (accessed 25 August 2015).
Список литературы (для анализа):
1. http://azure.microsoft.com/.
2. http://ceph.com/.
3. http://docs.mongodb.org/manual/core/gridfs.
4. http://fallabs.com/kyototycoon/.
5. http://leo-project.net/leofs/.
6. http://lustre.org/.
7. http://moosefs.com/.
8. http://quantcast.github.io/qfs/.
9. http://reverbrain.com/elliptics/.
10. http://russia.emc.com/cloud/vipr/index.htm.
60
ПЕРСПЕКТИВЫ РАЗВИТИЯ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИИ
11. http://swift.openstack.org/.
12. http://www.acronis.com/ru-ru/provider/software-storage/.
13. http://www.coda.cs.cmu.edu/.
14. http://www.gluster.org/.
15. http://www.odin.com/products/virtuozzo/.
16. http://www.openafs.org/.
17. http://www.rackspace.com/cloud/files.
18. http ://www. sourceware. org/cluster/gfs/.
19. http ://www. stacken.kth. se/project/arla/.
20. http://www.vmware.com/ru/products/virtual-san.
21. https://aws.amazon.com/ru/s3/.
22. https://hadoop.apache.org/.
23. https://oceanstore.cs.berkeley.edu/.
24. https://www.dcache.org/.
25. https://www.research.ibm.com/haifa/projects/storage/zFS/.
26. https://www.tahoe-lafs.org.
27. https://code.google.com/p/nilestore/wiki/TahoeLAFSBasics.
ПРОБЛЕМЫ ПРОЕКТИРОВАНИЯ МОБИЛЬНЫХ СИСТЕМ ДЛЯ ЗАХВАТА ДВИЖЕНИЯ ПАЛЬЦЕВ РУК
© Петухов А.А.*
Московский институт электроники и математики Национального исследовательского университета «Высшая школа экономики», г. Москва
В данной работе рассматриваются проблемы, возникающие при проектировании беспроводных нательных систем для захвата движения пальцев рук человека, работающих в режиме реального времени от автономных источников питания. Учитывается опыт автора, полученный при проектировании подобной системы в рамках программы «УМНИК».
Ключевые слова человеко-машинный интерфейс, система захвата движения, датчики, беспроводные сенсорные сети.
Введение
В настоящее время активно развивается направление виртуальной и дополненной реальности. На рынок выходит всё большее количество устройств,
Аспирант.
