BC/NW 2012; №2 (21):4.4

 

ПРОБЛЕМЫ РАЗРАБОТКИ И ИСПОЛЬЗОВАНИЯ  ОБЛАЧНЫХ СИСТЕМ ХРАНЕНИЯ ДАННЫХ

 

Абросимов Л.И., Тютиков Д.А.

 

В настоящее время широкое распространение получают так называемые облачные системы хранения(СХД). Подобные проекты запускают как крупные компании, работающие с информационными технологиями, такие как  Google, Apple, Яндекс.  так и небольшие компании провайдеры, так как облачные системы хранения, разработанные на базе свободного программного обеспечения, гораздо дешевле в развертывании и не требовательны к вычислительной мощности узлов кластера. Бизнес некоторых компаний и вовсе сосредоточен вокруг таких систем хранения, как как скажем, Dropbox.

Облачная СХД — это новый метод организации хранилищ, при котором принадлежащие компании или организации данные хранятся не в ее центрах обработки данных (ЦОД) или на одиночных серверах, а на большом количестве виртуальных серверов. Такие серверы принадлежат компаниям, сдающим в аренду или продающим доступное дисковое пространство другим организациям, у которых нет собственных ЦОД (или потребности в них).

Использование облачных СХД — это исключительно популярная альтернатива созданию дополнительной службы резервного копирования. Если данные будут утеряны или доступ к ним окажется невозможным, их всегда можно извлечь из облачной системы.

Стоимость использования подобных сервисов невелика, а в большинстве случаев частным пользователям бесплатно представляется небольшой объем памяти (порядка 5 Гб).

Подобные сервисы не только обеспечивают  доступ к хранящимся в облаке данным из любого места, где есть доступ к Интернету, но и обеспечивает их сохранность в случае повреждения и утраты физического носителя. В большинстве случаев также поддерживается «история версий», т. е. в облаке сохраняется история правок файла за некоторый период, что позволяет вернуться к более ранней версии, если, скажем, внесенные изменения были ошибочными или даже если файл был удален.

 Проблемы использования публичных облаков и предпосылки к созданию частных СХД

Реализации облачных СХД не лишены и недостатков. С ростом потребности в дисковом пространстве растет и стоимость их использования. Таким образом, использование облачных систем хранения для хранения больших объемов данных, таких как резервные копии серверов и баз данных, видео, научные данные становится неэффективным с экономической точки зрения. Есть еще проблемы, которые могут негативно сказаться на работе с публичными облачными СХД.

Во-первых, это достаточно большое время, за которое можно получить большой файл, хранящийся в облаке, или наоборот загрузить его с пользовательской машины в облако и доступность данных в целом. Для решения этой проблемы в абсолютном большинстве случаев кластеры  облачных СХД размещаются в современных ЦОД, обеспечены высокопроизводительными каналами связи с многократным резервированием. Однако, проблемы сетевого характера могут возникнуть вне зоны ответственности компании, предоставляющей услуги облачного хранения данных. В таком случае, несмотря на полную сохранность данных, возможность их использования может быть ограничена или вовсе отсутствовать. Подобный ход событий может привести к нарушению нормального функционирования процессов, которые используют данные, хранящиеся в облаке, и, как следствие, к финансовым потерям.

Во-вторых это проблема безопасности и доступа к данным. Концепция «публичного облака» подразумевает, что данные, загружаемые в систему хранения и извлекаемые из нее, часть пути проходят через сети общего пользования. Это может быть недостаточно хорошим решением с точки зрения безопасности данных, если передаваемые данные являются корпоративной или государственной тайной, так как  возможность перехвата и подмены данных недопустима. Проблема безопасности частично решается шифрованием передаваемых данных, но необходимость шифровать данные заставляет использовать специфическое программное и аппаратное обеспечение и может приводить к уменьшению скорости доступа к данным. При этом всегда существует возможность попадания учетных данных для доступа к СХД в руки злоумышленников, что ставит под удар конфиденциальность данных.

Все изложенное приводит к необходимости создания частных облачных СХД, обеспечивающих внутренние нужды компаний. Наличие частной облачной СХД позволяет силами системных администраторов организации эффективно ограничивать доступ, а также контролировать качество доступа к данным, хранящимся в нем.

Следует заметить, что для развертывания кластера облачной СХД необходима развитая и весьма дорогостоящая информационная инфраструктура, а так же квалифицированные специалисты, способные ее поддерживать и модернизировать[1].

Отличия облачных СХД от файловых и  FTP серверов.

В чем же коренное отличие таких СХД от привычных файловых серверов, работающих через такие протоколы как FTP? Первое, и, наверное, самое важное отличие — это масштабируемость подобных решений. Облачные СХД изначально ориентированы на развертывание на кластере, что подразумевает простое, с инженерной точки зрения, расширение доступного дискового пространства за счет добавления к кластеру новых хост-машин. Это же свойство позволяет облачным СХД обеспечивать дополнительную надежность и сохранность данных. Копии каждого фрагмента данных хранятся на различных серверах или даже в различных дата-центрах. За счет дублирования данных обеспечивается их сохранность и доступность даже при полном выходе из строя некоторой части серверов кластера системы хранения. Так же максимальный размер файлов, хранящихся в облаке ограничен только объемом дискового пространства, в то время как размер файлов, хранящихся на обычных файловых серверах зачастую ограничен возможностями используемой файловой системы.

Принцип работы Swift

OpenStack Object Storage  Swift[2] — это полностью распределенное, отказоустойчивое высоконадежное хранилище данных, созданное по образу и подобию Amazon S3. Swift почти полностью основан на наработках компании Rackspace[3]. Система состоит из четырех основных компонентов:

- прокси-сервер (Proxy Server), объединяющий все остальные компоненты системы вместе;

- объектный сервер (Object Server), ответственный за хранение данных;

- контейнерный сервер (Container Server), ответственный за предоставление списка объектов;

- сервер учетных записей (Account Server), предоставляющий списки контейнеров для конкретной учетной записи.

Рис. 1. Типичная Swif-инфраструктура

Типичная Swift-инфраструктура представляет собой кластер, одна из машин которого выполняет функции прокси-сервера, несколько машин работают в качестве контейнерных серверов и серверов аккаунтинга, а все остальные (сотни и тысячи машин) представляют собой контейнерные серверы.[4] Прокси-сервер поддерживает внешний ReST-ful API, реализованный в рамках протокола HTTP. Поэтому запрос доступа к объектам внутри хранилища выглядит очень наглядно и просто.

GET http://swift.host.com/v1/account/container/object

Здесь account — это пользовательский аккаунт, container — пространство имен, используемое для классификации данных, а object — непосредственно данные (или, другими словами, файл).

Прокси-сервер использует так называемые кольца (rings), для поиска реального размещения данных в кластере[5]. Это своего рода база данных, описывающая то, где на самом деле расположены данные. Она модифицируется при каждой записи новых данных в хранилище, их удаления или выходе узлов из строя. Для аккаунтов, контейнеров и объектов предусмотрены отдельные кольца.

Объектные серверы — наиболее важный компонент Swift-кластера[6]. Они отвечают за хранение и передачу данных. Любые объекты хранилища в конечном счете записываются на жесткие диски этих серверов, которые записывают данные в обычные файлы, сопровождая их метаданными, записываемыми в расширенные атрибуты файлов (xattr)[7]. Надежность хранения данных достигается за счет дублирования сразу на несколько серверов, так что если один из них выйдет из строя, система сможет восстановить данные с другого сервера и вновь продублировать их [8]. По умолчанию система создает три копии каждого объекта, так что в качестве аппаратной составляющей кластера можно использовать даже самые дешевые машины, не снабженные RAID-контроллерами.

Один из основных плюсов системы состоит в ее прозрачной масштабируемости. Расширить хранилище можно, просто подключив новый узел к кластеру, а всю остальную работу по его синхронизации с хранилищем возьмет на себя Swift. Лучше всего этот кластер подходит для хранения таких данных, как образы виртуальных машин (собственно, для этого он и был создан), банки фотографий, электронные письма, резервные копии и тому подобное.

Проблемы эксплуатации облачных систем хранения

Как уже отмечалось выше, на кластере в каждый момент времени должно существовать как минимум три копии каждого фрагмента данных, таким образом избыточность составляет 200%. Наличие трех копий позволяет, во-первых, контролировать возникновение ошибок и осуществлять их исправление (по мажоритарному принципу), а, во- вторых, в случае выхода из строя узла кластера, наличие копии данных позволяет восстановить его содержимое.

Подобный механизм позволяет обеспечить высокую выживаемость системы, но приводит к возникновению некоторых проблем, как экономического характера (необходимо в три раза больше дисков для хранения данных), так и технического.

Рассмотрим ситуацию, в которой один из серверов-узлов кластера выходит из строя без возможности восстановления, но имеется точно такой же по своим характеристикам резервный сервер.

Если включить резервный сервер в  кластер вместо вышедшего из строя, автоматически стартует процесс восстановления данных. В настоящее время объем дискового пространства на серверах хранения данных может доходить до нескольких террабайт. Так как для восстановления информации будут использоваться данные, хранящиеся на других узлах кластера, возникнет необходимость передачи большого объема данных(сотни гигабайт) через сеть. В соответствие с документацией рекомендуется использовать для связи между объектными серверами гигабитные каналы связи, и соответственно, гигабитные коммутаторы. Это обеспечивает приемлемое быстродействие в штатном режиме, но необходимость передавать внутри кластера такие большие объемы информации может привести к деградации производительности сети передачи данных кластера. Это, в свою очередь, может привести к увеличению времени загрузки данных из облачной системы хранения на рабочие станции пользователей и наоборот.

Кроме увеличения нагрузки на сетевую инфраструктуру кластера, процесс восстановления данных вызовет так же и повышенную нагрузку на внутренние компоненты (процессор, оперативная память и, разумеется, жесткие диски) серверов, задействованных в процессе, что может негативным образом сказаться на их производительности. Особенно это будет заметно на примере кластеров, где порядок количества серверов совпадает с порядком  числа копий данных (их число может изменяться администратором, хотя наиболее широко распространенной и рекомендуемой практикой является наличие трех копий), так как в этом случае в процесс восстановления утерянных данных будет вовлечена большая часть узлов кластера.

Необходимо понять, насколько сильно восстановление данных влияет на скорость передачи данных в и из облачной СХД и как сильно этот процесс влияет на загруженность узлов кластера этой системы.

Возможные подходы  к исследованию влияния процесса восстановления данных на загруженность кластера облачного СХД

Всвязи с тем, что процесс восстановления данных может повлиять на скорость обмена данными с облачной СХД, необходимо оценить, насколько сильно этот процесс скажется на загруженности узлов кластера облака и на загруженности сети передачи данных.

Для этого можно использовать системы мониторинга серверов, обладающие соответствующим функционалом. Например, система Zabbix после установки программы-агента на сервер с некоторой задаваемой администратором  периодичностью отправляет на центральный сервер мониторинга информацию о загруженности узла. Естественно, подобная система сама по себе тоже нагружает сеть, что необходимо учитывать при проведении измерений. Анализ полученных данных позволит оценить динамику изменения загруженности компонентов узлов кластера в процессе восстановления данных.

Для оценки воздействия процесса восстановления данных на скорость обмена данными с облачной системой хранения может быть написана программа-скрипт, с определенной периодичностью загружающая файлы из «облака» или в него.  Следует учитывать, что результаты могут варьироваться в зависимости от числа передаваемых файлов и их размера. т. е. Передача одного файла объемом 10000Мб может занять одно время, а передача 1000 файлов по 10Мб — другое. Также следует провести эксперимент, запустив тестирующую программу скрипт на нескольких «пользовательских» компьютерах, что позволит уменьшить погрешность, связанную с загрузкой канала пользователя.

Литература

1.     OpenStack Object Storage Administration Manual, Why Cloud?, http://docs.openstack.org/trunk/openstack-object-storage/admin/content/why-cloud.html

2.     OpenStack Object Storage Administration Manual, Components of OpenStack, http://docs.openstack.org/trunk/openstack-object-storage/admin/content/components-of-openstack.html

3.     OpenStack Object Storage Administration Manual, What is OpenStack?, http://docs.openstack.org/trunk/openstack-object-storage/admin/content/what-is-openstack.html

4.     OpenStack Object Storage Administration Manual, Example Object Storage Installation Architecture, http://docs.openstack.org/trunk/openstack-object-storage/admin/content/example-object-storage-installation-architecture.html

5.     OpenStack Object Storage Administration Manual, Working with Rings, http://docs.openstack.org/trunk/openstack-object-storage/admin/content/working-with-rings.html

6.     OpenStack Object Storage Administration Manual, Object Store, http://docs.openstack.org/trunk/openstack-object-storage/admin/content/overview-object-store-arch.html

7.     OpenStack Object Storage Administration Manual, Containers and Objects, http://docs.openstack.org/trunk/openstack-object-storage/admin/content/containers-and-objects.html

8.     OpenStack Object Storage Administration Manual, Replication, http://docs.openstack.org/trunk/openstack-object-storage/admin/content/replication.html