Большинство программного обеспечения кластерных систем предполагает, что файловая система доступна со всех узлов кластера.
Эта файловая система используется для хранения программного обеспечения, данных, для организации работы некоторых подсистем кластера и т. д. Требования к производительности такой ФС могут сильно различаться для разных задач, однако чем она выше, тем стабильнее и универсальнее кластер.
считается.
Сервер NFS на главном узле — это минимальная версия такой ФС.
Для больших кластеров NFS дополняется развертыванием LusterFS — высокопроизводительной специализированной распределенной файловой системы, которая использует несколько серверов для хранения файлов и несколько серверов метаданных.
Однако эта конфигурация имеет ряд свойств, из-за которых с ней очень сложно работать, когда клиенты используют независимые виртуализированные кластеры.
Система HPC HUB vSC использует известное решение CEPH и файловую систему GFS2 для создания общей ФС.
В рамках работы над проектом HPC HUB на базе OpenStack возникла задача создать отказоустойчивое и высокопроизводительное общее хранилище для нескольких групп виртуальных машин, каждая из которых представляет собой небольшой виртуальный HPC-кластер.
Каждый такой кластер выдается отдельному клиенту, который имеет полный контроль над ним изнутри.
Таким образом, проблему невозможно решить в рамках «обычной» распределенной системы, собранной на физических компьютерах, т.к.
сети Ethernet кластеров изолированы друг от друга на уровне L2 для защиты клиентских данных и их сетевого трафика друг от друга.
При этом данные не могут быть размещены на каждой из виртуальных машин в рамках классической разделяемой системы, поскольку возможностей каждой из машин недостаточно и хочется высвободить ценные ресурсы процессора сразу после завершения вычислений.
, не тратя его на «перенос данных», особенно с учетом использования модели pay-per. К счастью, не все так плохо.
Учитывая тот факт, что общее хранилище предполагается использовать для вычислений HPC, можно сделать несколько предположений относительно нагрузки:
- операции будут осуществляться большими блоками;
- операции записи не будут частыми, но будут перемежаться значительными интервалами времени;
- операции записи могут начинаться со всех узлов сразу практически одновременно, но даже в этом случае хочется закончить запись как можно быстрее, чтобы узлы продолжали считать.
Мы были вынуждены отказаться от него с самого начала.
Было решено построить двухуровневую систему.
Существует несколько подходов к такому хранению:
- Распределенная файловая система, монтируемая на виртуальном хосте через специально организованное сетевое устройство, чтобы избежать потерь производительности из-за виртуализации сети OpenStack.
- Распределенная файловая система, смонтированная на физическом хосте и доступная из гостевой системы через виртуальную файловую систему.
- Классическая распределенная файловая система внутри виртуального кластера поверх гостевого блочного устройства.
- Распределенное блочное устройство, совместно используемое каждым виртуальным узлом, и предварительно настроенная файловая система в виртуальном кластере, работающая поверх этого общего устройства.
В варианте 1) в гостевой ОС монтируется классическая распределенная файловая система (или какое-то поддерево).
В этом случае серверы файловой системы видны из каждой системы и друг другу.
Это нарушает изоляцию сети L2 и потенциально позволяет различным пользователям видеть трафик друг друга с сохраненными данными.
Кроме того, для случая CEPH возможны только совместные квоты (т. е.
пользователь может повторно использовать разрешенное дисковое пространство за счет других пользователей) в режиме монтирования файловой системы через FUSE (файловая система в пользовательском пространстве), а не непосредственно в ядре.
.
При монтировании непосредственно в ядро квоты вообще не поддерживаются.
В варианте 2) - виртуальная файловая система (virtio-9p в QEMU) поверх распределенной файловой системы, смонтированной в хосте - для работы нужно запускать QEMU от имени суперпользователя без понижения привилегий, что снижает общую безопасность системы или настройте определенные списки управления доступом для хранения идентификаторов гостей и прав доступа гостей.
В варианте 3) при отсутствии дискового пространства на физических серверах мы можем использовать только удаленные блочные устройства некоторого распределенного хранилища.
Этот вариант непрактичен по нескольким причинам:
- доступ к данным потребует в 2 раза большей пропускной способности сети.
Данные сначала передаются из распределенного хранилища на конкретный виртуальный узел и только потом отправляются конечному потребителю;
- Как правило, все подобные системы поддерживают избыточность данных, что недопустимо.
Например, при настройках CEPH по умолчанию полезный объем хранилища уже уменьшается в 4 раза по сравнению с доступной емкостью диска.
Все сетевые нагрузки, поддерживающие работу распределенных ФС, также будут находиться внутри пространства виртуальной сети.
И, что самое сложное, последний вариант фактически потребует выделения физических узлов для виртуализации хранения, что приводит к резкому снижению общей эффективности.
На самом деле гость, конечно, видит устройство не как блочное устройство CEPH, а как обычный виртуальный VirtIO SCSI или, опционально, блок VirtIO. Мы выбрали VirtIO SCSI по очень простой причине — из-за поддержки SCSI команды unmap, аналога известной команды SATA TRIM, которая отправляется гостевой системой при удалении файлов и освобождает место в виртуальном хранилище.
Выбор файловой системы для гостя также прост. Здесь есть только два варианта:
- OCFS2
- СГФ2.
Не было желания заниматься кропотливой пересборкой ядра.
Кроме того, GFS2 поддерживает изменение размера файловой системы при монтировании, что может быть полезно в нашем случае.
Конфигурация общего хранилища
Установка CEPH прекрасно описана в документации.docs.ceph.com/docs/master/start и не вызвало никаких проблем.
На данный момент система работает с одной избыточной копией данных и без авторизации.
Сеть CEPH изолирована от клиентской сети.
Создание блочного устройства также не вызвало никаких проблем.
Все стандартно.
Конфигурация GFS2
К сожалению, установка GFS2 заняла гораздо больше времени, чем предполагалось изначально.В Интернете очень мало четких описаний и они сбивают с толку.
Общая идея выглядит примерно так.
Работой общей файловой системы в ядре управляют несколько демонов, правильная настройка которых требует нетривиальных усилий или знаний.
Первое и самое главное, что вам нужно знать, это то, что поднять эту файловую систему на Ubuntu вы, скорее всего, не сможете.
Либо вам придется пересобирать множество малоиспользуемых пакетов за пределами RedHat для Ubuntu, разрешая кучу нетривиальных конфликтов уровня API. В системе, подобной RedHat, последовательность действий более или менее ясна.
Ниже приведены команды для гостевой системы CentOS 7. Прежде всего отключите SELinux. GFS2 с ним не будет работать.
Это официальная информация от производителя.
Теги: #HPC #ceph #gfs2 #lustrefs #nfs #nfs #хранилище #openstack #Высокая производительность #открытый исходный код #Большие данные #Параллельное программированиеvi /etc/sysconfig/selinux
-
Литературный Язык
19 Oct, 24 -
Lenovo Ideapad Y560D
19 Oct, 24 -
Поймай Меня, Если Сможешь
19 Oct, 24 -
Какой Дистрибутив Linux Выбрать?
19 Oct, 24
