Кластерные решения на Linux серверах стали важной технологией в обеспечении масштабируемости и высокой доступности для ИТ служб. Эти службы зачастую выдвигают требования доступности данных для нескольких серверов. В дополнение к этому, даже небольшие компании часто имеют много компьютеров, включая рабочие станции и сервера, которым необходим общий доступ к данным. Следовательно, организация общего доступа к данным необходима как малым, так и к крупным компаниям.
Некоторые службы используют статические данные, которые могу быть легко разделены между серверами. Используя дублирование, каждый сервер в кластере хранит полную копию данных. Однако другие службы используют динамические данные, которые быстро меняются, и в этом случае довольно трудно организовать дублирование данных. Для примера, базы данных и файл-сервера (использующие такие протоколы как SQL, NFS или CIFS) должны распространить новую информацию на все сервера после каждой операции записи. Это приведет к очень большому времени отклика и высокой загрузке сети. Еще одно неудобство заключается в высокой стоимости обслуживания дублирующих копий и, как следствие, сложность управления системой. Такие приложения действительно нуждаются в организации доступа к одному хранилищу данных с возможностью читать и записывать одновременно множеством серверов. Использование файлового сервера (подключенный к сети сервер с данными), поддерживающего протоколы NFS и CIFS, является традиционным решением для организации совместного доступа к файлам. Linux, конечно, предлагает такое популярное решение, и это решение подходит для некоторых приложений, но выделенный файл-сервер является узким местом в производительности и единой точкой сбоя (SPoF) для целой системы. Для разрешения трудностей использования традиционных подходов для организации масштабируемого и несложного общего доступа к данным каждый сервер в кластере должен иметь прямой доступ к хранилищу, и каждый сервер должен иметь возможность одновременно читать и записывать данные. Red Hat Global File System (GFS) представляет основу этого решения. Это решение соединяет в себе Linux сервера и сеть хранения данных (SAN), для организации кластера совместного хранения посредством разделяемой файловой системы.
Внутреннее устройство GFS
Global File System была создана как 64-битная кластерная файловая система. Она позволяет нескольким серверам осуществлять подсоединение к сетевому хранилищу данных (SAN) для доступа к общим, совместно используемым файлам одновременно с помощью стандартной UNIX/POSIX семантики файловой системы.
Разработка GFS началась в 1995 году в университете Миннесоты. В это время в университете использовался крупномасштабный вычислительный кластер, где порождалось огромное количество данных, которые эффективно записывались в центральное хранилище данных. Для решения этой проблемы Matthew O'Keefe, в то время профессор университета Миннесоты, начал с группой студентов разработку GFS. В последствии Matthew стал руководителем направления Storage Strategy в Red Hat. Результатом этих усилий стало появление Red Hat GFS кластерной файловой системы, которая выпущена под лицензией GPL. В данный момент GFS доступна только для Linux.
Файловая система GFS является журналируемой файловой системой. Для каждого узла кластера заводится свой собственный журнал. Изменения метаданных в файловой системе записываются сначала в журнал, а затем в файловую систему, как и в других журналируемых файловых системах. В случае сбоя узла, согласованность файловой системы может быть восстановлена путем повторения операций с метаданными. Существует возможность определить будут ли журналироваться только метаданные или в журнал будут попадать также данные содержимого файлов.
GFS сохраняет дискрипторы файловой системы в индексных дескрипторах (inodes), которые выделяются динамически по мере необходимости (далее именуемые dynamic nodes или dinodes). Они занимают полный блок файловой системы (4096 байт - это стандартное значение размера блока файловой системы в ядре Linux). В кластерной файловой системе, несколько серверов обращаются к файловой системе в одно и тоже время; отсюда вытекает, что, объединение нескольких dinodes в одном блоке приведет к доступу к конкурирующим блокам и ложному соперничеству. Для эффективного распределения места и уменьшения доступа к диску, данные файлов сохраняются (внедряются) непосредственно внутри dinode, если файл достаточно мал для размещения целиком в dinode. В этом случае, необходим только доступ к одному блоку для доступа к маленьким файлам. Если файл большой, то GFS использует проскую структуру файла ("flat file"). Все указатели в dinode имеют одинаковую глубину. Существует только три вида указателей: прямые (direct), косвенные (indirect), или дважды косвенные (double indirect) указатели. Высота дерева увеличивается по мере необходимости, на сколько это требуется для хранения файла с данными, как показано на Рисунке 1.
Расширяемое хеширование ("Extendible hashing", ExHash) используется для сохранения индексной структуры для каталогов. Для каждого имени файла multi-bit хеш сохраняется как индекс в хеш-таблице. Соответствующий указатель в таблице указывает на листовой узел ("leaf node"). На каждый листовой узел могут ссылаться несколько указателей. Если хеш-таблица для листовых узлов становится недостаточной для хранения структуры каталогов, то размер всей хеш-таблицы удваивается. Если размера одного листового узла недостаточно, то он разделяется на два узла того же размера. Если имеется небольшое количество записей в каталоге, то информация о нем сохраняется внутри dinode блока, как файл с данными. Такая структура данных позволяет выполнить поиск в каталогах при количестве дисковых операций пропорционально глубине структуры дерева "extendible" хеширования, которая довольно плоская. Для больших каталогов с тысячами и миллионами файлов, требуется только небольшое количество дисковых операций для поиска записи в каталоге.
Последняя версия GFS 6.0 предлагает новые возможности, включая списки управления доступом к файлам (ACL), поддержку квотирования, прямой ввод/вывод (для повышения производительности баз данных), и динамическое увеличении файловой системы без отключения.
Рисунок 1: Структура метаданных GFS
Структура
Рисунок 2 показывает структуру типового кластерного хранилища GFS. Файловая система GFS строится над пулом, который собирается из одного или нескольких независимых хранилищ. Сервера подключаются к сетевому хранилищу (SAN) по одному или нескольким путям к пулу хранения. Отдельные сервера в кластере также подключаются к сети с использованием одного или несколько каналов. Таким образом, каждый сервер может напрямую обращаться к дисковым массивам, из которых собран пул хранения, что значительно повышает производительность ввода/вывода системы и позволяет производить масштабирование, превосходя результат при использовании одного NAS сервера.
Рисунок 2: Кластер хранения данных GFS
Сервера в кластерном хранилище GFS используют Linux в качестве операционной системы. Менеджер томов кластера GFS виртуализует дисковые устройства (/dev/sda) и объединяет их в один логический пул (dev/pool/foo). Множество устройств может быть объединено с помощью чередования (striping) или слияния (concatenation). Изменения в конфигурации пула видны на всех узлах кластера. Менеджер управления пулом позволяет изменять размер пула в реальном времени и предоставляет несколько каналов ввода/вывода, что позволяет выдержать одиночный сбой SAN пути. Однако менеджер пулов не позволяет реализовать зеркалирование и создание снимков (snapshots). Эти функции скоро появятся в CLVM, the Cluster Logical Volume Manager, менеджере кластерных томов, на основе LVM2, который позволяет нескольким серверам организовать общий доступ к тому хранения на SAN.
Сервер блокировок координирует различные сервера, которые обращаются к одним и тем же физическим блокам файловой системы в GFS кластере. Он гарантирует целостность системных данных. В начале, GFS снабжалась уровнем модульных блокировок. В ранних версиях GFS информация о блокировках передавалась через SCSI протокол (DLOCK, DMEP). Начиная с 5-ой версии GFS используется служба блокировок с использованием IP и возможностью дублирования, которая запускается на всех узлах. Red Hat работает над интеграцией распределенного менеджера блокировок (DLM) в GFS версии 6.1, которая выйдет летом 2005 года. Каждый сервер в GFS кластере должен постоянно взаимодействовать с менеджером блокировок. Если сервер не сообщает свое состояние, то менеджер блокировок помечает данный сервер для удаления из кластера, эта операция называется изоляцией (fencing). GFS поддерживает несколько способов изоляции, включая различные сетевые выключатели питания и интерфейс HP's ILO.
Масштабируемость
Классическая IT система состоит из служб и приложений, которые работают на отдельных серверах и обычно их работа ограничена конкретным сервером. Если оборудование, к которому привязано индивидуальное приложение, более не удовлетворяет требованиям, то приложение может столкнуться с проблемой нехватки памяти, процессорной мощности или дискового объема, которые доступны в остальной части кластера. В противоположность этому, приложения, которые могут параллельно выполняться на кластере хранения, значительно проще масштабируются. В случае нехватки ресурсов, новые компоненты (сервер, дисковый массив) могут быть легко интегрированы в систему до достижения нужной производительности. Совместное использование дискового пула позволяет не только отказаться от трудоемкого дублирования данных на несколько серверов, но также предоставляет удобные возможности масштабирования. С возрастающими требованиями к объему дискового хранилища, общий дисковый массив может быть расширен и станет сразу доступен для всех серверов.
Доступность (отказоустойчивость)
Доступность системы в целом является важным аспектом в предоставлении IT услуг. Для получения 3-го класса доступности (от 99% до 99.9%) необходимо устранить единую точку сбоя (SPOF). Для 4-го класса доступности (от 99.9% до 99.99%) необходимо иметь кластер высокой доступности, зеркалирование данных и второй центр обработки данных на случай стихийного бедствия. Службы должны иметь возможность работать на нескольких территориально распределенных серверах. Выход из строя одного сервера или целого вычислительного центра не должен повлиять на их доступность, допускается только потеря доступности на короткое время. Кластер GFS может быть подключен к центральному хранилищу через SAN посредством резервируемых каналов ввода/вывода для преодоления выхода из строя одного из компонентов системы, таких как коммутаторы, адаптеры HBA или кабели. Резервирование каналов ввода/вывода может быть достигнуто c использованием драйвера fibre channel для адаптера HBA или используя GFS пул. К сожалению, GFS кластер не имеет возможности дублировать информацию между дисковыми массивами с узлового сервера, зато можно воспользоваться аппаратным дублированием, которое присутствует в хороших дисковых RAID массивах. Зеркалирование с узлового сервера в GFS кластере появится немного позже, в 2005 году с появлением Cluster Logical Volume Manager (CLVM).
Менеджер блокировок, который является основой GFS, доступен в двух видах. Это упрощенная версия - Единственный менеджер блокировок (Single Lock Manager, или SLM), который является единой точкой сбоя (SPOF) для целой системы и версия с дублированием - Дублируемый менеджер блокировок (Redundant Lock Manager, или RLM). Это вариант позволяет определять несколько серверов с RLM, которые могут прозрачно перехватывать роль активного сервера блокировок в случае сбоя. К тому же, Red Hat Cluster Suite может быть использован для обеспечения отказоустойчивости приложений в GFS кластере.
Резервное копирование без использования сети
Резервирование данных обычно происходит с клиентских машин (которые зачастую являются серверами приложений), через локальную сеть (LAN) на выделенный сервер резервного копирования (с помощью такого ПО, как Legato Networker или Veritas Netbackup) или без использования сети (LAN-free) через сервер приложений сразу на устройство резервного копирования. Из-за того, что каждый подключенный сервер, использующий кластерную файловую систему, имеет доступ ко всем данным появляется возможность преобразовать любой сервер в сервер резервного копирования. Сервер резервного копирования позволяет производить резервирование информации во время работы, не оказывая влияния на сервера приложений. Удобно использовать возможность формирования снимка или клона тома GFS, используя аппаратные возможности дискового массива. Такие снимки томов могут быть подключены к серверу резервного копирования для последующего резервирования. Чтобы задействовать эту возможность, GFS содержит возможность "заморозки" файловой системы для обеспечения согласованного состояния данных. "Заморозка" означает, что все попытки доступа к файловой системе прерываются, после операции сброса (sync) файловой системы, которая гарантирует, что все метаданные и данные согласованно записаны на хранилище до формирования снимка.
Бездисковый кластер с разделяемым корневым разделом
Все сервера в GFS кластере получают доступ к данным через сеть хранения данных (SAN), и для увеличения производительности могут быть легко добавлены дополнительные сервера. Следовательно, каждый сервер может рассматриваться как очередной ресурс в пуле свободных серверов. Системные данные и образ операционной системы хранится в общедоступном хранилище, поэтому сервера и хранилище могут рассматриваться как независимые друг от друга. В результате - это бездисковый кластер с разделяемым корневым разделом, в котором не один сервер не имеет локальных дисков, и загрузка операционной системы происходит через SAN. Образы с приложениями и операционной системой доступны, это означает что раздел root (/) для всех узлов кластера одинаков. Вследствие чего получаем простое управление системой. Изменения вносятся однажды и сразу становятся доступны для всех серверов. Построение бездисковых кластеров с разделяемым корневым разделом с использованием GFS является специфической задачей и зависит от оборудования и версии ядра, и эту возможность можно реализовать только с помощью специалистов компании Red Hat или партнеров Red Hat, таких как ATIX GmbH.
Пример внедрения: IP Tech AG
Внедрение GFS в IP Tech, одной из крупнейших компаний, предлагающих услуги Интернет хостинга в Швейцарии, демонстрирует насколько эффективно кластерные технологии Red Hat используются на предприятиях. В начале 2002 года Red Hat GFS кластер, состоящий из 14 узлов, был введен в эксплуатацию в IP Tech. Этот кластер поддерживает базу данных (MySQL), электронную почту (Qmail) и веб-приложения (Apache) в специальных конфигурациях. В IP Tech размещено более 1500 баз данных MySQL, 10000 почтовых доменов и 28000 доменов Интернета, обслуживающих большую часть Швейцарских компаний. Ежедневная нагрузка в IP Tech составляет 5-7 миллионов веб-обращений, 3-3,5 миллиона pop3 соединений (к почтовым серверам), 1-1,5 миллиона SMTP соединений (пересылка почты) и 3,5-4 миллиона MySQL соединений на реализованную GFS инфраструктуру. Поддерживается более 100000 индивидуальных пользователей электронной почты.
В добавление к классическому веб-сервису, базам данных и почтовому сервису, IP Tech недавно представила хостинг на виртуальных машинах и выделенное размещение серверов в кластерном хранилище GFS. Клиенты сейчас могут динамически выделять GFS сервера "на лету" и запускать множество виртуальных серверов на одном GFS узле. Это превосходный путь для улучшения использования системы и вмещению большей части инфраструктуры внутрь кластера совместного доступа к данным GFS.
Недавно, IP Tech перевела свои сервисы на инфраструктуру, основанную на blade решениях с двумя терабайтами дублированного дискового массива и около 22 бездисковых серверов лезвий (blade). Все приложения, за исключением виртуальных машин, работают на GFS. Такая конфигурация позволяет минимизировать время на ремонт оборудования, путем простой замены вышедших из строя серверов лезвий (blades) и загрузки их с загрузочного образа с разделяемым корневым разделом. Масштабирование серверов и дискового хранилища может быть выполнено без останова комплекса. В дополнение к этому, каждую ночь данные с файловой системы реплицируются на второй дисковый массив без использования сети (Lan-free), используя GFS и SAN. Рисунок 3 иллюстрирует инфраструктуру IP Tech.
Рисунок 3: Инфраструктура IP Tech
IP Tech в начале использовала NFS для организации общего доступа к файлам, необходимого для IP хостинга, но это вызывало большие проблемы при обслуживании, т.к. система работала нестабильно при высокой нагрузке. Файловые службы и точки подключения появлялись и изчезали без предупреждений, останавливая работу в самое критическое время, и довольно часто в моменты высокой нагрузки, когда недоступность ресурса имела максимальный негативный эффект. Два года назад IP Tech перешла на Red Hat GFS и, в противоположность их инфраструктуре с хранилищем, построенным на NFS, кластер работающий на Red Hat GFS "работал сам сбой"
Используя Red Hat Enterprise Linux кластер с Red Hat GFS, IP Tech достигла высокой доступности и производительности. Если один из серверов выйдет из строя или приложение (например, http или qmail) зависнет, то этот сервер может быть быстро перезапущен и включен обратно в кластер без нарушения работоспособности сервисов на других серверах. В дополнение IP Tech использует технологию GFS с разделяемым корневым разделом, которая упрощает процесс обновления программных продуктов и предоставляет возможность распределять нагрузку в кластере для статических служб. Например, когда на IP Tech начинается спам атака, то они быстро переводят часть веб серверов на обслуживание почтовых серверов и тем самым поддерживает работу почты в рабочем режиме, обнаруживают и противостоят спам-атаке, в то время как все сервера в кластере продолжают работать. Они могут масштабировать инфраструктуру в течение нескольких минут, используя новые сервера и дисковые массивы. В заключение, IP Tech производит регулярное резервное копирование снимков томов GFS на определенный момент времени, используя отдельный сервер в кластере. Этот подход позволяет производить резервирование файловой системы GFS, не мешая работе других серверов.
Приведем преимущества, которые IP Tech получила, используя Red Hat GFS:
Очень высокая производительность и масштабируемость, которая была недоступна при использовании NFS.
Снижение сложности посредством организации общего доступа к данным и разделяемого образа корневого раздела.
Балансировка "на лету" нагруженности служб внутри кластера в реальном времени для обеспечения "вычислений по запросу" и производительности, которая требуется для работы приложений.
IP Tech использует возможность Red Hat GFS формировать снимки существующих томов файловых систем и баз данных. Том со снимком монтируется в режиме "только для чтения" и резервируется параллельно c работой файловой системы.
Резюме
Используя Red Hat Enterprise Linux и GFS, IP Tech достигла превосходной производительности и масштабируемости, уменьшенной сложности управления, масштибируемости и доступности, которые были недоступны с использованием NFS. Организация общего доступа через GFS позволила IP Tech снизить сложность управления и увеличивать производительность, отвечая запросам клиентов с минимальными затратами, используя ориентированное на Linux оборудование и программное обеспечение. Red Hat GFS позволяет также увеличить производительность приложений с интенсивным использованием дискового пространства, таких как СУБД Oracle на кластере, разработка программного обеспечения (сборка и компиляция) и высокопроизводительные вычислительные задачи. Узнайте больше о Red Hat GFS на сайте redhat.com.
Об авторе
Марк Гримм (Marc Grimme), научный сотрудник с подготовкой в компьютерной области, и Марк Хлавачек (Mark Hlawatschek), инженер с академической подготовкой, являются двумя из трех основателей ATIX GmbH. Основная направленность их деятельности лежит в разработке и внедрении заказных решений по хранению данных на предприятиях с использованием технологий SAN/NAS. В дополнение, они отвечают за реализацию ИТ инфраструктур с большой масштабируемостью для корпоративных приложений работающих на Linux.
