close

Вход

Забыли?

вход по аккаунту

?

Патент BY 16842

код для вставкиСкачать
ОПИСАНИЕ
ИЗОБРЕТЕНИЯ
К ПАТЕНТУ
РЕСПУБЛИКА БЕЛАРУСЬ
(46) 2013.02.28
(12)
(51) МПК
НАЦИОНАЛЬНЫЙ ЦЕНТР
ИНТЕЛЛЕКТУАЛЬНОЙ
СОБСТВЕННОСТИ
(54)
G 06F 11/00
(2006.01)
СПОСОБ УПРАВЛЕНИЯ СОГЛАСОВАННОСТЬЮ БЛОКОВ
ДАННЫХ В РАСПРЕДЕЛЕННОЙ ФАЙЛОВОЙ СИСТЕМЕ И
УСТРОЙСТВО ДЛЯ ЕГО ОСУЩЕСТВЛЕНИЯ
(21) Номер заявки: a 20110281
(22) 2009.07.30
(31) 200810142291.2 (32) 2008.08.04 (33) CN
(85) 2011.03.04
(86) PCT/CN2009/000855, 2009.07.30
(87) WO 2010/015143, 2010.02.11
(43) 2011.08.30
(71) Заявитель: ЗТЕ Корпорэйшн (CN)
(72) Авторы: ДУ, Шоуфу; ВАН, Руифен;
ЧЕН, Цзян (CN)
BY 16842 C1 2013.02.28
BY (11) 16842
(13) C1
(19)
(73) Патентообладатель: ЗТЕ Корпорэйшн
(CN)
(56) US 7065618 B1, 2006.
RU 2227376 C2, 2004.
RU 2310225 C2, 2007.
SU 1339571 A1, 1987.
(57)
1. Способ управления согласованностью блоков данных CHUNK в распределенной
файловой системе, в котором:
a) первично формируют копии блока CHUNK на основном и резервном серверах доступа к файлу, и одновременно посредством регистра местоположения файла генерируют
начальное значение счетчика, соответствующего формируемому блоку, и сохраняют его
на основном и резервном серверах доступа к файлу, а также в базе данных регистра местоположения файла;
b) записывают данные в указанные копии блока CHUNK посредством клиента доступа
к файлу, и затем в случае успешной записи указанных данных на указанные серверы не
изменяют начальное значение указанного счетчика для этих серверов, а в случае успешной
записи указанных данных только на один из указанных серверов увеличивают начальное значение указанного счетчика для этого сервера с заранее заданным размером шага;
Фиг. 1
BY 16842 C1 2013.02.28
c) в случае успешного изменения указанных данных только на одном из указанных
серверов на основании значений указанного счетчика, принятых регистром местоположения файла с указанных серверов, определяют копию указанного блока CHUNK, значение
счетчика для которой максимально, как нормальную, а затем исправляют другую копию,
определенную как аномальная.
2. Способ по п. 1, отличающийся тем, что при запросе изменения данных в указанных копиях блока CHUNK инициируют это изменение посредством клиента доступа к
файлу на основе информации, возвращенной указанному клиенту регистром местоположения файла с указанных серверов доступа к файлу, и затем в случае успешного изменения указанных данных на указанных серверах не изменяют начальное значение
указанного счетчика для этих серверов, а в случае успешного изменения указанных данных только на одном из указанных серверов увеличивают начальное значение указанного
счетчика для этого сервера с заранее заданным размером шага.
3. Способ по п. 2, отличающийся тем, что шаг изменения значения указанного счетчика задают равным единице.
4. Способ по п. 3, отличающийся тем, что в шаге с) регистром местоположения файла
осуществляют посылку запроса указанным серверам на проверку соответствующих копий
блока CHUNK в начале указанного шага и через заданный временной интервал для возможности дальнейшего сравнения результатов проверки, принятых при первом и втором
запросах.
5. Способ по п. 4, отличающийся тем, что при наличии в файловой системе не менее
двух блоков CHUNK после шага с) осуществляют проверку совпадения копий каждого
блока CHUNK, в ходе которой:
d1) последовательно принимают посредством регистра местоположения файла информацию с указанных серверов о локальных идентификаторах для каждой копии каждого блока CHUNK, создают в регистре местоположения файла хэш-таблицу HASH со
всеми указанными идентификаторами, а затем ищут в указанной таблице для каждого
следующего принятого идентификатора совпадающий с ним идентификатор, и при наличии указанного совпадения определяют копии блока CHUNK, соответствующие совпадающим идентификаторам, как группу из основной и резервной копий блока CHUNK;
d2) осуществляют запись в базу данных регистра местоположения файла всех групп
идентификаторов и сравнивают копии блока CHUNK в каждой из указанных групп.
6. Способ по п. 5, отличающийся тем, что при наличии в системе множества серверов
доступа к файлу определяют посредством регистра местоположения файла каждые основной и резервный серверы доступа к файлу, хранящие указанную группу копий, как одну
группу серверов, с разделением всех серверов на множество групп.
7. Способ по п. 5, отличающийся тем, что шаг d2) включает проверку наличия записи
каждого проверяемого блока CHUNK в базе данных регистра местоположения файла с
немедленным удалением соответствующего блока с серверов доступа к файлу в случае ее
отсутствия; и в ином случае - сравнение всех значений счетчика для каждого проверяемого блока и определение копии блока CHUNK с максимальным значением счетчика в качестве нормальной копии соответствующего блока CHUNK.
8. Способ по п. 7, отличающийся тем, что в случае, когда значение счетчика проверяемого блока CHUNK в базе данных регистра местоположения файла максимально, запись
проверяемого блока CHUNK удаляют из базы данных регистра местоположения файла.
9. Способ по п. 7, отличающийся тем, что в случае наличия сервера доступа к файлу
с максимальным значением счетчика проверяемого блока CHUNK посылают посредством
регистра местоположения файла запрос на исправление блока CHUNK остальным серверам доступа к файлу путем копирования на них блока CHUNK с сервера с максимальным
значением счетчика, а по окончании указанного копирования значение счетчика проверя-
2
BY 16842 C1 2013.02.28
емого блока CHUNK на каждом сервере доступа к файлу изменяют для достижения его
совпадения с указанным максимальным значением.
10. Способ по п. 7, отличающийся тем, что в случае, когда значение счетчика проверяемого блока CHUNK в базе данных регистра местоположения файла является меньшим
указанного максимального, это значение изменяют до максимального синхронно со значениями счетчика на всех указанных серверах.
11. Устройство для управления согласованностью блоков данных CHUNK в распределенной файловой системе, содержащее по меньшей мере один регистр местоположения
файла, связанный посредством сети с подключенными к хранилищу данных по меньшей
мере одним основным сервером доступа к файлу и по меньшей мере одним резервным
сервером доступа к файлу, при этом регистр местоположения файла выполнен с возможностью создания при формировании на указанных серверах копий блока данных CHUNK
счетчика, соответствующего формируемому блоку, генерирования начального значения
указанного счетчика и сохранения его в собственной базе данных и на указанных серверах, а указанные серверы выполнены как с возможностью изменения начального значения
указанного счетчика для каждого из серверов с заранее заданным размером шага в зависимости от результата попытки записи данных на этот сервер, осуществленной после получения пользовательского запроса на запись посредством клиента доступа к файлу, так и
с возможностью передачи итогового значения счетчика регистру местоположения файла
для возможности исправления аномальных копий блока данных CHUNK на основании
результатов сравнения всех значений указанного счетчика.
ОБЛАСТЬ ТЕХНИКИ
Данное изобретение относится к распределенной файловой системе для хранилищ
данных большой емкости и способу управления такой системой в области компьютерных
приложений и, более конкретно, к файловой системе для крупномасштабной распределенной обработки данных и способу проверки согласованности избыточных резервных
блоков данных в такой файловой системе для управления резервированием.
ПРЕДПОСЫЛКИ СОЗДАНИЯ ИЗОБРЕТЕНИЯ
В известном уровне техники, чтобы гарантировать высокую эффективность обработки
данных и централизованное управление метаданными, крупномасштабная файловая система распределенной обработки данных обычно разрабатывается как сервер централизованного управления метаданными (такой как регистр местоположения файла (File
Location Register, FLR)) и множество серверов хранения файлов данных (таких как сервер
доступа к файлу (File Access Server, FAS)).
Когда пользователь обращается к данным, он, прежде всего, запрашивает у регистра
FLR конкретное место хранения данных посредством клиента доступа к файлу (File Access Client, FAC), а затем клиент FAC инициирует запрос на чтение-запись данных конкретному серверу FAS. Сервер FAS управляет файлом данных путем разделения данных
файла на отдельные блоки данных (блоки CHUNK), и каждый файл состоит из множества
блоков CHUNK. Соответствие блока CHUNK файлу указывается универсальным идентификатором FILEID (идентификатор файла), каждый файл имеет идентификатор FILEID,
отличный от других файлов, и идентификатор CHUNKID каждого блока CHUNK состоит
из идентификатора FILEID и номера блока CHUNK. Информация о распределении всех
блоков CHUNK в файле единообразно помещается в базу данных и управляется регистром FLR.
В кластерной системе большой емкости обычно блоки CHUNK избыточно резервируются, то есть копии одного и того же блока CHUNK хранятся на множестве серверов FAS.
Однако в известном уровне техники трудно поддерживать согласованность (совпадение
3
BY 16842 C1 2013.02.28
друг с другом) нескольких копий блока CHUNK, что создает относительно большую проблему, главным образом выраженную в следующем: как гарантировать одновременную
запись соответствующих копий на множестве серверов FAS в процессе операции записи;
если есть один аномальный или отказавший сервер FAS, как восстановить данные на этом
сервере FAS; как гарантировать согласованность записи регистра FLR и сервера FAS во
время процесса записи, если регистр FLR находится в аномальном состоянии.
Так как это касается больших блоков CHUNK, общий способ проверки, такой как алгоритм MD5, не может быть применен к блокам CHUNK в известном уровне техники, так
как он будет отрицательно влиять на быстродействие при обработке.
Следовательно, известный уровень техники должен быть улучшен и развит.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
В настоящем изобретении предлагается распределенная файловая система и способ
управления согласованностью блоков CHUNK для решения вышеупомянутых проблем
известного уровня техники и осуществления проверки и необходимого исправления блоков CHUNK для данных большого объема.
Техническая схема данного изобретения включает способ управления согласованностью блоков CHUNK в распределенной файловой системе, который включает следующие
шаги:
A) при формировании блока CHUNK регистр местоположения файла генерирует значение счетчика, соответствующее формируемому блоку CHUNK, и сохраняет значение
счетчика на серверах доступа к файлу и в регистре местоположения файла;
B) при записи данных в блок CHUNK клиент доступа к файлу записывает данные в
основной и резервный серверы доступа к файлу, и, если данные успешно записаны и в основной, и в резервный серверы доступа к файлу, клиент доступа к файлу не изменяет значения счетчика блока CHUNK; в ином случае клиент доступа к файлу увеличивает с
заранее заданным размером шага значение счетчика CHUNK на тех серверах доступа к
файлу, где данные были записаны успешно;
C) упомянутый регистр местоположения файла на основании значений счетчика соответствующего блока CHUNK, о которых сообщают основной и резервные серверы доступа к файлу, определяет блок CHUNK, значение счетчика которого максимально, как
нормальный и действительный блок CHUNK и исправляет аномальные блоки CHUNK.
Кроме того, способ может включать следующее:
при изменении данных блока CHUNK регистр местоположения файла возвращает
упомянутому клиенту доступа к файлу информацию основного и резервного серверов доступа к файлу, на которых находится блок CHUNK, и упомянутый клиент доступа к файлу
инициирует операцию изменения данных для упомянутых основного и резервного серверов доступа к файлу;
если данные изменены успешно и на основном, и на резервном серверах доступа к
файлу, клиент доступа к файлу не изменяет значение счетчика CHUNK; в ином случае
клиент доступа к файлу увеличивает с заранее заданным размером шага значение счетчика измененного блока CHUNK на том сервере доступа к файлу, где данные были изменены успешно.
Кроме того, в способе упомянутый заранее заданный размер шага может быть равен 1.
Кроме того, в способе упомянутый шаг С может дополнительно включать следующее:
регистр местоположения файла посылает запрос на проверку блока CHUNK упомянутым
серверам доступа к файлу в момент времени запуска и через определенный временной интервал.
Кроме того, упомянутый способ может дополнительно включать процесс проверки
блока CHUNK, при этом процесс проверки блока CHUNK включает следующее:
D1) упомянутые серверы доступа к файлу сообщают обо всех локальных идентификаторах CHUNKID регистру местоположения файла, и регистр местоположения файла со4
BY 16842 C1 2013.02.28
здает хэш-таблицу HASH с идентификаторами CHUNKID, принятыми впервые, и для
принимаемого впоследствии идентификатора CHUNKID ищет в хэш-таблице HASH идентификатор CHUNKID, совпадающий с упомянутым принимаемым впоследствии идентификатором CHUNKID, и если в хэш-таблице HASH есть идентификатор CHUNKID,
совпадающий с принимаемым впоследствии идентификатором CHUNKID, то это означает, что блоки CHUNK являются группой из основного и резервного блоков CHUNK;
D2) регистр местоположения файла записывает все группы идентификаторов CHUNKID и проверяет каждый блок CHUNK.
Кроме того, в способе регистр местоположения файла может определять основной и
резервный серверы доступа к файлу, хранящие копии одного и того же блока CHUNK, как
одну группу и делить все серверы доступа к файлу в системе на множество групп.
Кроме того, в способе упомянутый шаг проверки блоков CHUNK, соответствующих
каждой группе идентификаторов CHUNKID, на шаге D2 может включать:
D21) проверку, имеют ли проверяемые блоки CHUNK запись в регистре местоположения файла; и немедленное удаление проверяемых блоков CHUNK с серверов доступа к
файлу, если не имеют; в ином случае - переход к шагу D22;
D22) сравнение значений счетчика соответствующих блоков CHUNK в базе данных
регистра местоположения файла и каждого сервера доступа к файлу и определение блока
CHUNK с максимальным значением счетчика в качестве действительного блока CHUNK.
Кроме того, в способе шаг D2 может дополнительно включать следующее:
если значение счетчика блока CHUNK в регистре местоположения файла максимально, то запись блока CHUNK из базы данных регистра местоположения удаляют.
Кроме того, в способе шаг D2 может дополнительно включать следующее:
если имеется сервер доступа к файлу, на котором значение счетчика CHUNK является
максимальным, регистр местоположения файла посылает запрос на исправление блока
CHUNK другим серверам доступа к файлу, на которых значение счетчика CHUNK является меньшим, и копирует данные действительного блока CHUNK в аномальный блок
CHUNK;
после того как данные скопированы, значение счетчика блока CHUNK на каждом сервере доступа к файлу изменяется так, чтобы сделать значение счетчика совпадающим с
максимальным значением счетчика.
Кроме того, в способе шаг D2 может дополнительно включать следующее:
если значение счетчика блока CHUNK в регистре местоположения файла является
меньшим, чем на упомянутых серверах доступа к файлу, значение счетчика CHUNK в базе данных регистра местоположения файла изменяют синхронно.
Распределенная файловая система, включающая по меньшей мере один сервер доступа к файлу и по меньшей мере один регистр местоположения файла, связанные посредством сети; упомянутый сервер доступа к файлу подключается к хранилищу данных;
пользователь посылает запрос на запись данных серверу доступа к файлу и регистру местоположения файла посредством клиента доступа к файлу и увеличивает с заранее заданным размером шага значение счетчика блока CHUNK на том файловом сервере, где
данные записаны нормально; причем упомянутый сервер доступа к файлу сконфигурирован по меньшей мере с основным и резервным серверами доступа к файлу, и
регистр местоположения файла используется для генерирования значения счетчика,
соответствующего блоку CHUNK, и управления исправлением для аномальных блоков
CHUNK согласно значению счетчика CHUNK, о котором сообщают основной и резервный серверы доступа к файлу.
Применение счетчика блока CHUNK в распределенной файловой системе и применение способа управления согласованностью блоков CHUNK согласно настоящему изобретению для проверки нормальности и необходимости исправления каждого блока CHUNK
позволяет легко и эффективно управлять резервными блоками CHUNK в большой кла5
BY 16842 C1 2013.02.28
стерной системе и поддерживать ее согласованность, более того, появляется возможность
исправлять аномальный резервный блок CHUNK, при этом данная реализация является
простой и точной.
КРАТКОЕ ОПИСАНИЕ ЧЕРТЕЖЕЙ
Фиг. 1 - блок-схема изменения значения счетчика блока CHUNK согласно способу
настоящего изобретения при записи или изменении данных.
Фиг. 2 - блок-схема приема и проверки регистром FLR блоков CHUNK, о которых сообщает сервер FAS, в соответствии со способом настоящего изобретения.
Фиг. 3 - блок-схема частного способа проверки посредством регистра FLR в соответствии со способом настоящего изобретения.
Фиг. 4 иллюстрирует структуру распределенной файловой системы в соответствии с
настоящим изобретением.
ПРЕДПОЧТИТЕЛЬНЫЕ ФОРМЫ ОСУЩЕСТВЛЕНИЯ НАСТОЯЩЕГО ИЗОБРЕТЕНИЯ
Каждая предпочтительная форма осуществления данного изобретения будет подробно
описана со ссылкой на прилагаемые фигуры.
Данное изобретение раскрывает распределенную файловую систему и способ управления согласованностью блоков CHUNK с использованием концепции счетчика блока
CHUNK, при этом каждый блок CHUNK снабжается счетчиком для указания количества
изменений блока CHUNK. Значение счетчика увеличивается с заранее заданным размером
шага, каждый раз при изменении блока CHUNK, поэтому, если значения счетчика основного и резервного блоков CHUNK не совпадают, это означает, что имеется недействительный блок CHUNK, и аномальные блоки CHUNK соответственно исправляют.
Способ данного изобретения решает проблему управления главным и резервным блоками CHUNK, и его основная реализация включает следующее.
При формировании блоков CHUNK эти блоки единообразно формируются регистром
FLR, и значение счетчика первоначально созданного блока CHUNK равно 1. Это значение
сохраняется также на сервере FAS и в регистре FLR.
Для упрощения описания рассмотрим случай, когда используется один основной и
один резервный серверы FAS. Например, для иллюстрации, как показано на фиг. 1, в процессе инициирования пользователем процесса записи данных блока CHUNK клиент FАС
одновременно записывает две копии данных в основной и резервный серверы FAS соответственно, и, если запись как в основной, так и в резервный серверы FAS является
успешной, процесс изменения счетчика CHUNK не инициируется. Если происходит отклонение при записи данных в некоторый сервер FAS, клиент FAC начинает процесс изменения счетчика для нормального сервера FAS, чтобы изменить текущее значение
счетчика нормального блока CHUNK. Следовательно, значения счетчика блоков CHUNK
на основном и резервном серверах FAS не будут одинаковы, и значение счетчика нормального блока CHUNK будет больше. На более поздней стадии аномальный блок
CHUNK может быть определен простой проверкой, и этот блок CHUNK исправляют на
аномальном сервере FAS.
Когда пользователь инициирует изменение контента файла, регистр FLR возвращает
клиенту FAC информацию двух серверов FAS, на которых располагается соответствующий блок CHUNK, и клиент FAC немедленно начинает операцию изменения данных для
двух серверов FAS. Если и основной, и резервный серверы FAS успешно изменяют данные, процесс изменения счетчика CHUNK не инициируют. Если при записи данных на
некоторый сервер FAS происходит отклонение, клиент FAC инициирует процесс изменения счетчика CHUNK для нормального сервера FAS, чтобы увеличить с заранее заданным
размером шага значение счетчика соответствующего блока CHUNK на упомянутом сервере FAS, и одновременно увеличивает значение счетчика блока CHUNK в регистре FLR.
Таким образом, значения счетчика блоков CHUNK на основном и резервном серверах
6
BY 16842 C1 2013.02.28
FAS становятся неодинаковыми. Аномальный блок CHUNK может быть определен простой проверкой на более поздней стадии путем сравнения значений счетчика, и блок
CHUNK исправляют на аномальном сервере FAS.
С помощью вышеупомянутого процесса можно гарантировать, что в случае сбоя значения счетчика блоков CHUNK на основном и резервном серверах FAS обязательно будут
различными. Регистр FLR инициирует запрос на проверку блока CHUNK серверу FAS в
момент запуска и через определенный временной интервал. В соответствии со значениями
счетчика блоков CHUNK, о которых сообщают основной и резервный серверы FAS, регистр FLR может определить сервер FAS, на котором блок CHUNK является правильным,
с максимальным значением счетчика, в качестве основы для определения, и, таким образом, блоки CHUNK на аномальном сервере FAS могут быть исправлены.
Ниже способ управления согласованностью блоков CHUNK в распределенной файловой системе согласно данному изобретению будет проиллюстрирован примерами.
Определим идентификатор CHUNKID (идентификатор блока CHUNK) как: FILEID
(идентификатор файла, 4-байтовое целое число без знака) + нумерация CHUNK
(2-байтовое целое число без знака) + счетчик (4-байтовое целое число без знака); на стороне регистра FLR имеется база данных для хранения каждого идентификатора
CHUNKID, содержащая значение счетчика CHUNK и информацию о местоположении
сервера FAS, на котором находится упомянутый блок CHUNK; каждый блок CHUNK
хранится на сервере FAS, и значение счетчика CHUNK записывается на стороне сервера
FAS.
Как показано на фиг. 1, когда пользователь начинает процесс записи, клиент FAC,
прежде всего, обращается к регистру FLR для назначения всех серверов FAS, которые
имеют отношение к резервированию. После успешного назначения регистр FLR записывает идентификатор CHUNKID в локальную базу данных, и начальное значение счетчика
CHUNK устанавливается на 1.
Клиент FAC непосредственно посылает запрос на запись данных двум серверам FAS.
Когда клиент FAC записывает данные, он непрерывно отчитывается о состоянии записи
каждого сервера FAS. Сообщаемая информация о состоянии включает идентификатор ID
записываемого в данное время блока CHUNK и состояние записи каждого сервера FAS.
После того как регистр FLR принимает сообщения о состоянии, он сравнивает состояния записи двух серверов FAS, и если все они являются нормальными, то никакая обработка не требуется; если оба сервера FAS является аномальными, значения счетчика
CHUNK в регистре FLR немедленно увеличивают; если обнаружено, что состояние записи одного сервера FAS аномально, в то время как состояние другого является нормальным, регистр FLR инициирует запрос на изменение счетчика CHUNK нормальному
серверу FAS. После того как упомянутый нормальный сервер FAS принимает запрос, он
увеличивает значение счетчика, соответствующее локальному блоку CHUNK, и возвращает сообщение об успехе изменения регистру FLR. После того как регистр FLR принимает сообщение об успехе изменения, он изменяет значение в локальной базе данных на
значение нормального сервера FAS, в то время как сообщаемое аномальным сервером
FAS значение счетчика блока CHUNK не будет изменено.
Когда пользователь инициирует изменение, процедура обработки аналогична вышеописанному процессу. Отличие заключается в том, что когда записываются новые данные,
регистр FLR возвращает информацию того сервера FAS, на котором находится новый
блок CHUNK, или информацию сервера FAS, который уже имеет данные.
Регистр FLR инициирует процесс запроса на проверку блока CHUNK для сервера FAS
в момент запуска и через некоторый интервал времени, как показано на фиг. 2. Способ
проверки заключается в следующем: регистр FLR рассматривает каждые основной и резервный серверы FAS как пару, и полный кластер блоков CHUNK разделяется на несколько пар, например на N пар. Для каждой пары запрос на проверку посылается каждому
7
BY 16842 C1 2013.02.28
члену пары, при этом сервер FAS, который принял запрос, сообщает все локальные идентификаторы CHUNKID регистру FLR, и регистр FLR помещает информацию первого
принятого CHUNKID в хэш-таблицу HASH и выполняет поиск в хэш-таблице HASH после приема последующего идентификатора CHUNKID, и, если он находит идентификатор
CHUNKID в таблице, это означает, что они составляют пару из основного и резервного
блоков CHUNK.
Если регистр FLR не находит принятый идентификатор CHUNKID в хэш-таблице
HASH, это может быть связано с тем, что эти основной и резервный идентификаторы
CHUNKID не комплектны; делают запись всех пар информации CHUNKID одновременно,
и после того, как пара членов успешно проверяется, регистр FLR проверяет информацию
каждого идентификатора CHUNKID. Процесс проверки показан на фиг. 3, и этот процесс
включает:
шаг первый: проверяют наличие записи блока CHUNK в регистре FLR и немедленно
удаляют блок CHUNK, если запись отсутствует, в другом случае продолжают проверку;
шаг второй: вычисляют значение счетчика блока CHUNK в базе данных FLR и на
каждом сервере FAS, сравнивают их для получения максимального значения и принимают
блок CHUNK с максимальным значением счетчика в качестве действительного и нормального;
шаг третий: проверяют значение счетчика CHUNK, и данный процесс включает следующее:
если значение счетчика блока CHUNK в регистре FLR является максимальным, это
означает, что данные блока CHUNK на всех серверах FAS ненадежны и необходимо удалить запись блока CHUNK из базы данных FLR;
если есть сервер FAS, имеющий максимальное значение счетчика блока CHUNK, регистр FLR инициирует запрос на исправление блока CHUNK всем серверам FAS, на которых блок CHUNK имеет меньшее значение счетчика, то есть сообщает серверу FAS, на
котором значение счетчика является максимальным, что определенный блок CHUNK,
находящийся на нем, должен быть скопирован с этого локального сервера на аномальные
серверы FAS. После завершения копирования значение счетчика соответствующего блока
CHUNK на каждом сервере FAS немедленно изменяется, чтобы сделать его совпадающим
с максимальным значением;
если значение счетчика блока CHUNK в регистре FLR меньше этого значения на серверах FAS, регистр FLR должен изменить значение счетчика CHUNK в базе данных FLR.
На фиг. 4 показана структура распределенной файловой системы в соответствии с
настоящим изобретением, и эта система содержит по меньшей мере один сервер 401 доступа к файлу и по меньшей мере один регистр 402 местоположения файла, которые связаны посредством сети, такой как локальная сеть Ethernet, при этом каждый сервер 401
доступа к файлу подключен также к соответствующему хранилищу 411 данных, по меньшей мере один регистр 402 местоположения файла используется для генерирования значения счетчика соответствующего блока CHUNK во время операции записи данных для
сервера 401 доступа к файлу. Пользователь посылает запрос на доступ к данным соответствующему серверу 401 доступа к файлу и регистру 402 местоположения файла посредством упомянутого клиента 403 доступа к файлу; сервер 401 доступа к файлу
конфигурируется по меньшей мере с основным и резервным серверами доступа к файлу, и
клиент 403 доступа к файлу используется для записи данных в соответствующий блок
CHUNK на основном и резервном серверах доступа к файлу и для увеличения значения
счетчика блока CHUNK с заранее заданным размером шага на том сервере доступа к файлу, на котором запись данных является нормальной; регистр 402 местоположения файла
используется для определения, является ли блок CHUNK аномальным, в соответствии с
тем, совпадают ли значения счетчика соответствующих блоков CHUNK, сообщенные ос-
8
BY 16842 C1 2013.02.28
новным и резервным серверами доступа к файлу, а также используется для управления
исправлением аномальных блоков CHUNK.
Распределенная файловая система и способ управления согласованностью блоков
CHUNK, в соответствии с данным изобретением, позволяют легко и эффективно управлять избыточными резервными блоками CHUNK в кластерной системе большой емкости,
чтобы поддерживать их согласованность и исправлять аномальные резервные блоки
CHUNK. Это обеспечено главным образом тем, что:
1. Если в процессе сохранения данных пользователем (дозаписи или изменения данных) один из основного и резервного серверов FAS является аномальным, значение счетчика блока CHUNK на нормальном сервере FAS увеличивают, в то время как значение
счетчика блока CHUNK на аномальном сервере FAS не изменяют; и, когда позже регистр
FLR выполняет проверки синхронизации, он удаляет с сервера FAS блок CHUNK, значение счетчика которого является меньшим, согласно проверке значения счетчика блока
CHUNK, и исправляет соответствующие блоки CHUNK на аномальном сервере FAS на
основе блоков CHUNK нормального сервера FAS.
2. Согласно способу настоящего изобретения, блок CHUNK, значение счетчика которого максимально, принимают в качестве нормального и действительного, и если значение, записанное в регистре FLR, максимально, то это означает, что блоки CHUNK на всех
серверах FAS ненадежны; если значение, записанное на одном сервере FAS, максимально,
то необходимо исправить этот блок CHUNK на тех серверах FAS, на которых это значение меньше, и одновременно изменить запись в регистре FLR.
Из вышеприведенного описания можно видеть, что распределенная файловая система
и способ управления согласованностью блоков CHUNK, в соответствии с данным изобретением, могут быть легко и точно реализованы; проверка и вычисление являются очень
быстрыми и подходящими для обработки больших блоков CHUNK.
Очевидно, что представленное выше описание предпочтительных форм осуществления данного изобретения является описанием конкретных вариантов осуществления и не
должно рассматриваться как ограничение объема настоящего изобретения, который определяется прилагаемой формулой изобретения.
ПРОМЫШЛЕННАЯ ПРИМЕНИМОСТЬ
Распределенная файловая система и способ управления согласованностью блоков
CHUNK, предлагаемые в настоящем изобретении, применяют счетчик блока CHUNK для
определения, является ли блок CHUNK аномальным или должен ли блок CHUNK быть
исправлен, и в большой кластерной системе эти система и способ позволяют легко и эффективно управлять избыточными резервными блоками CHUNK и поддерживать их согласованность, кроме того, появляется возможность исправлять аномальные резервные
блоки CHUNK, при этом реализация предложенных системы и способа является простой
и точной.
Фиг. 2
9
BY 16842 C1 2013.02.28
Фиг. 3
Фиг. 4
Национальный центр интеллектуальной собственности.
220034, г. Минск, ул. Козлова, 20.
10
Документ
Категория
Без категории
Просмотров
0
Размер файла
169 Кб
Теги
патент, 16842
1/--страниц
Пожаловаться на содержимое документа