Gfs что это

Gfs что это

1. GFS (сокр. от Google File System) – это файловая система созданная компанией Google для собственного пользования в 2000 году.

В 2009 году вышла обновленная её версия под кодовым названием Colossus.

Большая часть информации об этой файловой системе и её реализации является коммерческой тайной компании Google.

2. GFS (сокр. от Global File System) – еще одна файловая система, которая была разработана университетом штата Миннесота. Она используется американской компанией Red Hat.

Понравилось? Поделись с друзьями!

Новое

• 5 причин перегрева компьютера
• Вылетают игры на компьютере: причины
• Не открываются страницы в браузерах в Windows 10
• Что делать, если программы из магазина в Windows 10 не подключаются к интернету
• Что делать, если внезапно перестали работать USB в Windows 10

Gfs что это

Оригинал статьи опубликован в Red Hat Magazine 2005 год 6 выпуск
Перевод © Инвента, 2005 Введение Кластерные решения на 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

1. Очень высокая производительность и масштабируемость, которая была недоступна при использовании NFS.
2. Снижение сложности посредством организации общего доступа к данным и разделяемого образа корневого раздела.
3. Балансировка «на лету» нагруженности служб внутри кластера в реальном времени для обеспечения «вычислений по запросу» и производительности, которая требуется для работы приложений.
4. 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.

Распределенная файловая система GFS (Google File System)

Рисунок взят из оригинальной статьи.

В системе существуют мастер-сервера и чанк-сервера, собственно, хранящие данные. Как правило, GFS кластер состоит из одной главной машины мастера (master) и множества машин, хранящих фрагменты файлов чанк-серверы (chunkservers). Клиенты имеют доступ ко всем этим машинам. Файлы в GFS разбиваются на куски — чанки (chunk, можно сказать фрагмент). Чанк имеет фиксированный размер, который может настраиваться. Каждый такой чанк имеет уникальный и глобальный 64 — битный ключ, который выдается мастером при создании чанка. Чанк-серверы хранят чанки, как обычные Linux файлы, на локальном жестком диске. Для надежности каждый чанк может реплицироваться на другие чанк-серверы. Обычно используются три реплики.
Мастер отвечает за работу с метаданными всей файловой системы. Метаданные включают в себя пространства имен, информацию о контроле доступа к данным, отображение файлов в чанки, и текущее положение чанков. Также мастер контролирует всю глобальную деятельность системы такую, как управление свободными чанками, сборка мусора (сбор более ненужных чанков) и перемещение чанков между чанк-серверами. Мастер постоянно обменивается сообщениями (HeartBeat messages) с чанк-серверами, чтобы отдать инструкции, и определить их состояние (узнать, живы ли еще).
Клиент взаимодействует с мастером только для выполнения операций, связанных с метаданными. Все операции с самими данными производятся напрямую с чанк-серверами. GFS — система не поддерживает POSIX API, так что разработчикам не пришлось связываться с VNode уровнем Linux.
Разработчики не используют кеширование данных, правда, клиенты кешируют метаданные. На чанк-серверах операционная система Linux и так кеширует наиболее используемые блоки в памяти. Вообще, отказ от кеширования позволяет не думать о проблеме валидности кеша (cache coherence).

Мастер

Использование одного мастера существенно упрощает архитектуру системы. Позволяет производить сложные перемещения чанков, организовывать репликации, используя глобальные данные. Казалось бы, что наличие только одного мастера должно являться узким местом системы, но это не так. Клиенты никогда не читают и не пишут данные через мастера. Вместо этого они спрашивают у мастера, с каким чанк-сервером они должны контактировать, а далее они общаются с чанк-серверами напрямую.
Рассмотрим, как происходит чтение данных клиентом. Сначала, зная размер чанка,
имя файла и смещение относительно начала файла, клиент определяет номер чанка внутри файла. Затем он шлет запрос мастеру, содержащий имя файла и номер чанка в этом файле. Мастер выдает чанк-серверы, по одному в каждой реплике, которые хранят нужный нам чанк. Также мастер выдает клиенту идентификатор чанка.
Затем клиент решает, какая из реплик ему нравится больше (как правило та, которая ближе), и шлет запрос, состоящий из чанка и смещения относительно начала чанка. Дальнейшее чтения данных, не требует вмешательства мастера. На практике, как правило, клиент в один запрос на чтение включает сразу несколько чанков, и мастер дает координаты каждого из чанков в одном ответе.
Размер чанка является важной характеристикой системы. Как правило, он устанавливается равным 64 мегабайт, что гораздо больше, чем размер блока в обычной файловой системе. Понятно, что если необходимо хранить много файлов, размеры которых меньше размера чанка, то будем расходоваться много лишней памяти. Но выбор такого большого размера чанка обусловлен задачами, которые приходится компании Google решать на своих кластерах. Как правило, что-то считать приходится для всех документов в интернете, и поэтому файлы в этих задачах очень большого размера.

Метаданные

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

Взаимодействия внутри системы

Выше была описана архитектура системы, которая минимизирует вмешательства мастера в выполнение операций. Теперь же рассмотрим, как взаимодействуют клиент, мастер и чанк-серверы для перемещения данных, выполнения атомарных операций записи, и создания резервной копии (snapshot).
Каждое изменение чанка должно дублироваться на всех репликах и изменять метаданные. В GFS мастер дает чанк во владение(lease) одному из серверов, хранящих этот чанк. Такой сервер называется первичной (primary) репликой. Остальные реплики объявляются вторичными (secondary). Первичная реплика собирает последовательные изменения чанка, и все реплики следуют этой последовательности, когда эти изменения происходят.
Механизм владения чанком устроен таким образом, чтобы минимизировать нагрузку на мастера. При выделении памяти сначала выжидается 60 секунд. А затем, если потребуется первичная реплика может запросить мастера на расширение этого интервала и, как правило, получает положительный ответ. В течение этого выжидаемого периода мастер может отменить изменения.
Рассмотрим подробно процесс записи данных. Он изображен по шагам на рисунке, при этом тонким линиям соответствуют потоки управления, а жирным потоки данных.

Этот рисунок также взят из оригинальной статьи.

1. Клиент спрашивает мастера, какой из чанк-серверов владеет чанком, и где находится этот чанк в других репликах. Если необходимо, то мастер отдает чанк кому-то во владение.
2. Мастер в ответ выдает первичную реплику, и остальные (вторичные) реплики. Клиент хранит эти данные для дальнейших действий. Теперь, общение с мастером клиенту может понадобиться только, если первичная реплика станет недоступной.
3. Далее клиент отсылает данные во все реплики. Он может это делать в произвольном порядке. Каждый чанк-сервер будет их хранить в специальном буфере, пока они не понадобятся или не устареют.
4. Когда все реплики примут эти данные, клиент посылает запрос на запись первичной реплике. В этом запросе содержатся идентификация данных, которые были посланы в шаге 3. Теперь первичная реплика устанавливает порядок, в котором должны выполняться все изменения, которые она получила, возможно от нескольких клиентов параллельно. И затем, выполняет эти изменения локально в этом определенном порядке.
5. Первичная реплика пересылает запрос на запись всем вторичным репликам. Каждая вторичная реплика выполняет эти изменения в порядке, определенном первичной репликой.
6. Вторичные реплики рапортуют об успешном выполнении этих операций.
7. Первичная реплика шлет ответ клиенту. Любые ошибки, возникшие в какой-либо реплике, также отсылаются клиенту. Если ошибка возникла при записи в первичной реплике, то и запись во вторичные реплики не происходит, иначе запись произошла в первичной реплике, и подмножестве вторичных. В этом случае клиент обрабатывает ошибку и решает, что ему дальше с ней делать.

Операции, выполняемые мастером

• Желательно поместить новую реплику на чанк-сервер с наименьшей средней загруженностью дисков. Это будет со временем выравнивать загруженность дисков на различных серверах.
• Желательно ограничить число новых создаваемых чанков на каждом чанк-сервере. Несмотря на то, что создание чанка сама по себе быстрая операция, она подразумевает последующую запись данных в этот чанк, что уже является тяжелой операцией, и это может привести к разбалансировке объема трафика данных на разные части системы.
• Как сказано выше, желательно распределить чанки среди разных стоек.

Устойчивость к сбоям и диагностика ошибок

Авторы системы считают одной из наиболее сложных проблем частые сбои работы компонентов системы. Количество и качество компонентов делают эти сбои не просто исключением, а скорее нормой. Сбой компонента может быть вызван недоступностью этого компонента или, что хуже, наличием испорченных данных. GFS поддерживает систему в рабочем виде при помощи двух простых стратегий: быстрое восстановление и репликации.
Быстрое восстановление — это, фактически, перезагрузка машины. При этом время запуска очень маленькое, что приводит к маленькой заминке, а затем работа продолжается штатно. Про репликации чанков уже говорилось выше. Мастер реплицирует чанк, если одна из реплик стала недоступной, либо повредились данные, содержащие реплику чанка. Поврежденные чанки определяется при помощи вычисления контрольных сумм.
Еще один вид репликаций в системе, про который мало было сказано — это репликация мастера. Реплицируется лог операций и контрольные точки (checkpoints). Каждое изменение файлов в системе происходит только после записи лога операций на диски мастером, и диски машин, на которые лог реплицируется. В случае небольших неполадок мастер может перезагрузиться. В случае проблем с жестким диском или другой жизненно важной инфраструктурой мастера, GFS стартует нового мастера, на одной из машин, куда реплицировались данные мастера. Клиенты обращаются к мастеру по DNS, который может быть переназначен новой машине. Новый мастер является тенью старого, а не точной копией. Поэтому у него есть доступ к файлам только для чтения. То есть он не становится полноценным мастером, а лишь поддерживает лог операций и другие структуры мастера.
Важной частью системы является возможность поддерживать целостность данных. Обычный GFS кластер состоит из сотен машин, на которых расположены тысячи жестких дисков, и эти диски при работе с завидным постоянством выходят из строя, что приводит к порче данных. Система может восстановить данные с помощью репликаций, но для этого необходимо понять испортились ли данные. Простое сравнение различных реплик на разных чанк-серверах является неэффективным. Более того, может происходить несогласованность данных между различными репликами, ведущая к различию данных. Поэтому каждый чанк-сервер должен самостоятельно определять целостность данных.
Каждый чанк разбивается на блоки длиной 64 Кбайт. Каждому такому блоку соответствует 32-битная контрольная сумма. Как и другие метаданные эти суммы хранятся в памяти, регулярно сохраняются в лог, отдельно от данных пользователя.
Перед тем как считать данные чанк-сервер проверяет контрольные суммы блоков чанка, которые пересекаются с затребованными данными пользователем или другим чанк-сервером. То есть чанк-сервер не распространяет испорченные данные. В случае несовпадения контрольных сумм, чанк-сервер возвращает ошибку машине, подавшей запрос, и рапортует о ней мастеру. Пользователь может считать данные из другой реплики, а мастер создает еще одну копию из данных другой реплики. После этого мастер дает инструкцию этому чанк-серверу об удалении этой испорченной реплики.
При добавлении новых данных, верификация контрольных сумм не происходит, а для блоков записывается новые контрольные суммы. В случае если диск испорчен, то это определится при попытке чтения этих данных. При записи чанк-сервер сравнивает только первый и последний блоки, пересекающиеся с границами, в которые происходит запись, поскольку часть данных на этих блоках не перезаписывается и необходимо проверить их целостность.

• распределенные вычисления
• файловые системы
• google
• распределенные файловые системы
• gfs

Архивное хранение резервных копий (GFS)

Архивное хранение резервных копий GFS (Grandfather-Father-Son) — это алгоритм долговременного хранения выборочных резервных копий с возможностью настроить несколько независимых сроков хранения. Подробнее о GFS в документации Veeam: Long-Term Retention Policy (GFS).

Для работы GFS требуется регулярное создание полных резервных копий (full backups). Для этого метод бэкапа изменяется на Forward Incremental Method, что увеличивает потребление хранилища. Подробнее о методах бэкапа в документации Veeam: Backup Methods.

Изменить метод бэкапа можно:

• для всех заданий (включая новые). Параметры GFS для каждого задания настраиваются самостоятельно;
• для отдельных заданий. Настроить и изменить параметры GFS можно только через тикет.

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

Включить архивное хранение для всех заданий​

1. Подключите архивное хранение.
2. Настройте архивное хранение резервных копий для нужных заданий.

Подключить архивное хранение​

1. Создайте тикет.
2. Выберите тему Услуги.
3. Выберите услугу VMware.
4. В описании тикета укажите:
   • для каких заданий подключить GFS: для всех заданий (включая новые);
   • тип full backup: Active или Synthetiс;
   • день недели, в который будет создаваться полная резервная копия.

Настроить архивное хранение​

Настраивать архивное хранение нужно после закрытия тикета на подключение.

1. На портале Veeam® Backup Enterprise Manager при создании или редактировании задания откройте вкладку Job Settings.
2. Отметьте чекбокс Keep certain full backups longer for archival purposes.
3. Нажмите Configure.
4. Отметьте нужные правила создания архивных копий и настройте их параметры. Можно настроить несколько правил.
5. Нажмите OK.

Включить архивное хранение для отдельных заданий​

Архивное хранение будет настроено технической поддержкой для выбранных заданий. Изменить параметры хранения или настроить архивное хранение для новых заданий можно будет только через тикет.

1. Создайте тикет.
2. Выберите тему Услуги.
3. Выберите услугу VMware.
4. В описании тикета укажите:
   • тип full backup: Active или Synthetiс;
   • день недели, в который будет создаваться полная резервная копия;
   • задания, для которых нужно настроить архивное хранение;
   • для каждого задания: какие правила и с какими параметрами нужно использовать для архивного хранения.

Правила создания архивных копий​

• Количество лет хранения архивной копии;
• месяц — архивной станет копия, которая была создана в указанный месяц

• Количество месяцев хранения архивной копии;
• неделя месяца — архивной станет копия, созданная в указанную неделю месяца: в первую (First) или последнюю (Last)

• Количество недель хранения архивной копии;
• день недели — если за неделю было создано несколько резервных копий, копия за этот день недели станет архивной

• Включить архивное хранение для всех заданий
  • Подключить архивное хранение
  • Настроить архивное хранение
  Похожие публикации:

  1. 2 dhcp сервера в одной сети как правильно настроить
  2. Как определить метод класса
  3. Как смонтировать папку
  4. Как часто надо чистить ноутбук от пыли и менять термопасту