CC BY
69
УДК 004.772, 004.451.52, 004.451.56
Д. Соловьев, Д. В. Иртегов, М. В. Рутман, Ю. М. Маллаева, И. С. Князев
Новосибирский государственный университет ул. Пирогова, 2, Новосибирск, 630090, Россия
ГИБРИДНОЕ ДВУХУРОВНЕВОЕ СЕТЕВОЕ ФАЙЛОВОЕ ХРАНИЛИЩЕ И ЕГО ПРИМЕНЕНИЕ В ОБЛАЧНОМ ХОСТИНГЕ
Описывается гибридное двухуровневое сетевое файловое хранилище, его архитектура, программная реализация и применение в облачном хостинге.
Ключевые слова: Балансировка загрузки, веб-хостинг, двухуровневое хранилище, гибридное хранилище, NFS, iSCSI, параллельный доступ.
Введение
С точки зрения провайдера разделяемого хостинга, задача оптимизации веб-хостинга состоит в обеспечении максимальной плотности размещения клиентских веб-сайтов на заданных аппаратных и сетевых ресурсах при условии, что наблюдаемые клиентом параметры производительности остаются в приемлемых границах. Решение этой задачи заключается не только в использовании эффективного системного и прикладного программного обеспечения, но также в обеспечении равномерной загрузки оборудования, т. е. в реализации балансировки загрузки.
При эксплуатации локальных дисков серверов балансировка загрузки может быть осуществлена путем переноса клиентского веб-сайта с одного сервера (исходного) на другой (целевой) \ Однако при таком переносе размещение данных сайта на локальном диске сервера приводит к возникновению сложно разрешимых проблем (затраты на перемещение файлов, перерыв в обслуживании) [1; 2].
Синхронизация файлов сайта между несколькими серверами может использоваться в качестве альтернативы переносу в случае размещения единичных высоконагруженных сайтов, когда обновление файлов происходит под контролем администратора серверов. Недостатком данного подхода является сложность его реализации в условиях разделяемого хостинга.
Альтернативным решением переносу / синхронизации данных при балансировке загрузки могло бы быть размещение данных клиентских сайтов в файловом хранилище, которое доступно как для исходного, так и для целевого серверов. Существующие сети хранения данных SAN (Storage Area Network), такие как iSCSI, AoE, Parallels Cloud Storage, обеспечивают производительность, сравнимую с производительностью локальных дисков. Но такие сети в силу своей архитектуры не могут обеспечить параллельный доступ нескольких серверов к хранилищу, поэтому использование таких хранилищ требует разработки алгоритма, определяющего целесообразность переключения конкретного раздела хранилища (т. е. некоторой группы данных клиентских сайтов) с одного сервера на другой.
1 rsync. URL: http://rsync.samba.org.
Соловьев Д., Иртегов Д. В., Рутман М. В., Маллаева Ю. М., Князев И.С. Гибридное двухуровневое файловое хранилище и его применение в облачном хостинге // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2014. Т. 12, вып. 4. С. 96-101.
ISSN 1818-7900. Вестник НГУ. Серия: Информационные технологии. 2014. Том 12, выпуск 4 © Д. Соловьев, Д. В. Иртегов, М. В. Рутман, Ю. М. Маллаева, И. С. Князев, 2014
Также для размещения файлов клиентских сайтов возможно использование файлового хранилища с совместным доступом [3; 4]. Такое хранилище позволяет обеспечить параллельный доступ нескольких клиентов к общей файловой системе, включая одновременный доступ к одному и тому же файлу. В схеме любой сервисный узел может обрабатывать запросы к любому из сайтов, расположенных на кластере 2.
Предварительные исследования показывают, что использование стандартных сетевых файловых систем SMB (Server Message Block) и NFS (Network File System) приводит к резкому падению наблюдаемой производительности веб-сайтов. Кластерные файловые системы OCFS2 и GFS2 также показывают низкую производительность при одновременном доступе с нескольких серверов 3.
В настоящей статье описана реализация гибридного хранилища, сочетающего преимущества сетевых файловых систем и сетей хранения данных. Такое хранилище должно обеспечивать параллельный доступ на модификацию со стороны нескольких веб-серверов. При этом задержки доступа должны быть сравнимы с задержками доступа по iSCSI (Internet Small Computer System Interface). Это достигается за счет каскадно-объединенного монтирования двух файловых систем, в начальный момент идентичных по содержанию, доступ к одной из которых на чтение и запись осуществляется по NFS, к другой - только на чтение - по iSCSI.
Гибридное решение
на основе каскадно-объединенного монтирования NFS и iSCSI
Существующие решения каскадно-объединенного монтирования. Наиболее известной файловой системой, обеспечивающей каскадно-объединенное монтирование в Linux, была UnionFS 4. Самое известное применение этой системы было в LiveCD, представляющее собой объединение файловой системы CD диска с доступностью только по чтению (RO-ветвь) и файловой системой на носителе с доступностью по чтению и записи (RW-ветвь).
Идеи UnionFS были развиты в файловой системе AUFS (Another UnionFS) 5. AUFS представляет собой драйвер файловой системы, реализующий принцип каскадно-объединенного монтирования (multilayered unification) для файловых систем Linux. AUFS является продуктом с открытыми исходными текстами, распространяемым на условиях GPL (GNU General Public License). Каскадно-объединенное монтирование позволяет объединить несколько ранее смонтированных файловых систем, называемых ветвями, в одну файловую систему.
Исследования исходного кода и реального поведения AUFS показали, что при каждом открытии или чтении атрибутов файла эта файловая система обращается сначала к RW-ветви, и только в случае отсутствии в ней файла открывает файл на RO-ветви.
Поведение AUFS неприемлемо по двум причинам:
1) oсновная задержка при открытии файла определяется задержкой при работе с RW-ветвью, а именно этого и необходимо избегать при решении задачи;
2) RW-ветвь является мастер-копией хранилища и содержит все файлы. Поэтому все обращения пойдут к RW-ветви, а RO-ветвь вообще не будет использоваться.
Оригинальная архитектура каскадно-объединенного монтирования с синхронизацией таблицы трансляции по сети (PleskFS). В качестве основы технического решения была выбрана разработка драйвера файловой системы с каскадно-объединенным монтированием. Архитектура модели показана на рис. 1 и включает следующие основные компоненты.
1. Драйвер файловой системы PleskFS для ядра Linux, реализующий двухуровневое хранилище с каскадно-объединенным монтированием. Обеспечивает логическое объединение структур каталогов двух или трех файловых хранилищ (называемых ветвями).
2. Файловое хранилище (RW), открыто для доступа на запись. Файл из RW-хранилища имеет приоритет на открытие, если в этом хранилище содержится более новая редакция файла или этот файл отсутствует в остальных ветвях. При попытке открытия файла, удаленного
2 NFS(5). Системное руководство Linux. URL: http://man7.org/linux/man-pages/man5/nfs.5.html; Shepler S. et al. Network File System (NFS) version 4 Protocol, RFC3530. URL: http://www.ietf.org/rfc/rfc3530.txt.
3 Project: OCFS2. URL: https://oss.oracle.com/projects/ocfs2.
4 Unionfs: A Stackable Unification File System. URL: http://www.filesystems.org/project-unionfs.html.
5 Another UnionFS. URL: http://aufs.sourceforge.net.
из Я'-ветви, происходит возврат ЕКОЕКТ независимо от того, присутствует этот файл в какой-либо из других ветвей или нет.
Рис. 1. Двухуровневое хранилище с каскадно-объединенным монтированием и таблицей трансляции
3. Файловое хранилище (ЯО), представляющее собой одну или две ветви файлов, доступные только на чтение. Файл из этого хранилища имеет приоритет на открытие, если он не модифицирован, не модифицированы его атрибуты (права доступа и владелец), и он не был удален с момента создания ЯО-ветви.
4. Таблица трансляции представляет собой хэш-таблицу номеров индексных дескрипторов измененных файлов. При наличии номера индексного дескриптора в таблице трансляции принимается решение на доступ к соответствующему файлу на Я'-ветви. В случае отсутствия номера индексного дескриптора в таблице трансляции проверяются параметры доступа к файлу. Если доступ к файлу не предполагает изменения его содержимого и атрибутов, то файл открывается на ЯО-ветви, в противном случае номер индексного дескриптора заносится в Таблицу трансляции и файл открывается на Я'-ветви. Таблица трансляции должна поддерживаться на каждом из клиентских узлов в актуальном состоянии.
5. Клиент синхронизации обеспечивает поддержку таблицы трансляции в актуальном состоянии на стороне узла кластера. Он обменивается сообщениями об изменении таблицы трансляции с остальными узлами кластера и сервером синхронизации. При монтировании файловой системы получает с сервера параметры подключения к Я'- и ЯО-хранилищам и копию таблицы трансляции, а при обновлении инициирует процесс переключения на новый образ ЯО.
6. Сервер синхронизации обеспечивает синхронизацию таблицы трансляции между узлами кластера и формирует у себя эталонную таблицу трансляции. При каждом новом монтировании Р1е8кБ8 на узле кластера, он передает параметры подключения к Я'- и ЯО-храни-
лищам и копию эталонной таблицы трансляции. При поступлении запроса на обновление RO-хранилища делает новый образ RO-и оповещает об этом узлы кластера.
В качестве RW-ветви используется экспортируемая по NFS файловая система ext4, расположенная на LVM 6 разделе (мастер-раздел) файлового сервера, являющаяся мастер-копией и содержащая копии всех файлов хранилища. RO-ветвь - это LVM-образ (LVM snapshot) мастер-раздела, доступ к которому обеспечивается по iSCSI. С интервалом в одни сутки с помощью LVM (LVM snapshot) фиксируется содержимое мастер-раздела и передается узлам кластера в качестве нового RO-хранилища.
В течение некоторого времени, пока узлы кластера содержат открытые файлы на старой RO-ветке, хранилище использует две RO-ветви. При этом при открытии новых файлов приоритет получает новая ветка. Когда все процессы на всех узлах переходят на новую RO-ветку, старая RO-ветка демонтируется и уничтожается.
Реализации каскадно-объединенного монтирования с синхронизацией таблицы трансляции по сети
Драйвер PleskFS. Решение (см. рис. 1) представляет собой полнофункциональный драйвер файловой системы (Р^к^), поддерживающий каскадно-объединенное монтирование и синхронизацию таблицы трансляции.
Таблица трансляции реализуется как хэш-таблица номеров индексных дескрипторов файлов, которые необходимо открывать на К^ветви. На каждом узле кластера хранится копия этой таблицы.
Реализация таблицы трансляции предполагает ее размещение в памяти ядра. Это обеспечивает высокую скорость доступа к таблице трансляции и исключает задержки. Содержимое таблицы трансляции изменяется при выполнении одним из узлов кластера следующих действий: первое открытие существующего файла на запись, изменение прав доступа, смена владельца, переименование или удаление файла. Удаление объектов из таблицы трансляции возможно только при создании новой версии ЯО-ветви, т. е. происходит кардинальное изменение таблицы трансляции, а не удаление одиночных записей.
Синхронизация таблицы трансляции. Для синхронизации таблицы трансляции требуется поддержка сетевого взаимодействия между узлами кластера. Эту задачу выполняет клиент синхронизации, который является частью драйвер PleskFS.
Рис. 2. Синхронизация таблицы трансляции.
6 lvm(8). Системное руководство Linux. URL: http://man7.org/linux/man-pages/man8/lvm.8.html.
Клиенты синхронизации обмениваются между собой сообщениями об изменении таблицы трансляции с помощью широковещательной UDP-рассылки. Этот механизм обеспечивает высокую скорость оповещения, но не обеспечивает гарантированную доставку. Для обеспечения гарантированной доставки используется сервер синхронизации, с которым клиенты устанавливают TCP соединения и отправляют ему все сообщения об изменении таблицы трансляции. В свою очередь, сервер синхронизации дублирует эти сообщения остальным узлам кластера.
При подключении нового узла кластера или перезагрузке существующего требуется восстановить на нем текущую таблицу трансляции. Для этого сервер синхронизации формирует свою копию таблицы трансляции, которая является эталонной. При подключении нового клиента передает ему эталонную таблицу трансляции (рис. 2).
Клиент синхронизации. Поскольку драйвер PleskFS является модулем ядра Linux и таблица трансляции также хранится в пространстве ядра, есть два возможных варианта реализации клиента синхронизации:
• в качестве самостоятельного приложения в пользовательском пространстве системы;
• в качестве модуля ядра, работающего в составе драйвера хранилища.
• Оба варианта были опробованы в процессе разработки, и большую эффективность показал вариант с реализацией клиента синхронизации в пространстве ядра системы.
• Реализация клиента синхронизации в качестве драйвера PleskFS в составе модуля ядра Linux имеет определенные преимущества в сравнении с реализацией клиента в пространстве пользователя, а именно:
• более высокая производительность за счет исполнения потока клиента с приоритетом ядра и отсутствия избыточного копирования данных между пространством ядра и пространством пользователя, а также за счет отсутствия задержек, вызываемых интерфейсом системных вызовов;
• упрощается взаимодействие с таблицей трансляции и с другими компонентами драйвера.
К минусам такого подхода можно отнести увеличение кода, который работает в контексте ядра системы и требует отладки и тестирования.
Тем не менее вариант реализации клиента как часть драйвера PleskFS выглядит предпочтительней.
В текущей реализации при каждом монтировании файловой системы PleskFS создается поток ядра, в котором запускается клиент синхронизации. Клиент синхронизации содержит:
1) UDP-сокет для широковещательной рассылки;
2) TCP-сокет для соединения с сервером синхронизации;
3) очередь событий об изменении таблицы трансляции для отправки остальным узлам кластера и серверу синхронизации;
4) ссылку на таблицу трансляции для добавления номеров дескрипторов, полученных от других узлов кластера и сервера синхронизации.
При старте клиент синхронизации выполняет следующие действия:
1) соединяется с сервером синхронизации;
2) получает параметры подключения к RO- и RW-хранилищам и инициирует соединение с ними;
3) получает таблицу трансляции и инициирует старт работы файловой системы.
Основной цикл работы клиента синхронизации состоит из ожидания и обработки следующих событий:
1) при добавлении номера дескриптора рассылает соответствующее сообщение узлам кластера и серверу синхронизации;
2) при получении номера дескриптора от других узлов кластера и сервера синхронизации добаляет его в таблицу трансляции;
3) при получении сообщения об обновлении RO-хранилища инициирует процедуру смены RO-ветви.
Сервер синхронизации размещается на файловом сервере вместе с NFS и iSCSI target. Такое размещение не создает дополнительной точки отказа, так как NFS сервер и iSCSI target обязаны размещаться на одном узле и уже представляют собой неустранимую единую точку
отказа. Так как процедура замены RO-ветви предполагает тесное взаимодействие с дисковой подсистемой файлового сервера, то размещение этого компонента на файловом сервере вполне оправдано.
Основной цикл работы сервера синхронизации состоит из ожидания и обработки следующих основных событий.
1. Подключение нового клиента. При возникновении запроса на новое подключение сервер устанавливает соединение с клиентом синхронизации, передает ему параметры подключения к RW- и RO-ветвям хранилища и пересылает таблицу трансляции.
2. Приход сообщения с номером индексного дескриптора от клиента. При получении данного сообщения номер дескриптора сохраняется в эталонной таблице трансляции, а сообщение отправляется остальным клиентам.
3. Получение запроса на обновление RO-ветви. В этом случае сервер создает новый образ RW-ветви и рассылает клиентам синхронизации параметры подключения к новой RO-ветви.
4. Приход сообщения о завершении использования старой RO-ветви. При получении данного сообщения сервер запоминает, что данный клиент больше не использует старую RO-ветвь. Когда все клиенты сообщат о прекращении использования старой RO-ветви, сервер удалит ее.
Выводы
Измерения с использованием Apache Jmeter производительности PleskFS в сравнении с другими файловыми хранилищами: локальный жесткий диск HDD; iSCSI образ; NFS сервер, показали, что ни одна из известных файловых систем в оригинальном ее виде не способна обеспечить доступ к файлам с минимальными задержками. Реализация гибридного хранилища позволяет решить эту задачу и получить малое среднее время, затрачиваемое на открытие файлов.
Список литературы
1. Сметанин А. Г., Тормасов А. Г. Математическая модель эффективных алгоритмов поиска и размещения данных в децентрализованной распределенной файловой системе // Научно-технические ведомости Санкт-Петерб. гос. политехн. ун-та. Информатика. Телекоммуникации. Управление. 2012. Т. 6, № 162. С. 16-22.
2. Петров В. А., Тормасов А. Г., Миркин А. Л. Длительность миграции виртуальных серверов в распределенной системе // Вестн. Новосиб. гос. ун-та. Серия: Информационные технологии. 2009. Т. 7, № 1. С. 26-36.
3. Иртегов Д. В. Введение в операционные системы. 2-е изд. СПб.: БХВ-Петербург, 2008.
4. Таненбаум Э., ван Стеен М. Распределенные системы. Принципы и парадигмы. СПб.: Питер, 2003.
Материал поступил в редколлегию 02.12.2014 D. Solovyov, D. V. Irtegov, M. V. Rutman, Yu. M. Mallaeva, I. S. Knyazev
Novosibirsk State University 2 Pirogov Str., Novosibirsk, 630090, Russian Federation
HYBRID TWO-LEVEL NETWORK FILE STORAGE AND ITS APPLICATION TO CLOUD HOSTING
The article describeslow latency shared network file storage based on the concept of two-levelunionmount of read-only and read-write branches. Also discussed a prototype implementation as Linux VFS driver using iSCSI and NFS brances and application of this storage for shared load-balanced cloud application hosting.
Keywords: load balancing, web hosting, cloud computing, hybrid storage, NFS, iSCSI, shared storage, union mount.
