WWW.DISSERS.RU

БЕСПЛАТНАЯ ЭЛЕКТРОННАЯ БИБЛИОТЕКА

   Добро пожаловать!


Pages:     | 1 || 3 | 4 |   ...   | 5 |

Главный сервер сохраняет все операции и изменения своего состояния в logфайле, который автоматически реплицируется на нескольких машинах. При превышении максимального размера log-файла создается резервная копия состояния главного сервера, а log-файл очищается. В случае аварийной остановки главного сервера, он автоматически перезапускается и восстанавливает свое состояние по последней резервной копии и log-файлу. Также некоторое время уходит на получение главным сервером информации о местоположении реплик от chunk-серверов, поскольку данная информация не сохраняется главным сервером. В случае отказа самой машины, главный сервер автоматически запускается на другой машине кластера и восстанавливает состояние с помощью реплицированных файлов. Клиенты автоматически устанавливают соединение с новым сервером по истечении таймаута, поскольку главный сервер адресуется с помощью DNS-имени. В системе также присутствует несколько резервных главных серверов (shadow master), которые предоставляют доступ к системе в режиме чтения, даже если главный сервер недоступен.

В случае аварийной остановки главного сервера, он автоматически перезапускается и восстанавливает свое состояние по хранимым на диске данным. В случае отказа самой машины с chunk-сервером, главный сервер автоматически удаляет ссылки на хранимые сервером реплики и начинает процесс их восстановления с помощью реплик на других серверах. Напомним, что каждый блок по умолчанию хранится на трех серверах. На chunk-серверах также могут случаться сбои жестких дисков, приводящие к частичному повреждению хранимых реплик. Поэтому каждый chunk-сервер выполняет проверку целостности хранимых им данных с помощью контрольных сумм. В случае если контрольная сумма не совпадает, то chunk-сервер сообщает об этом главному серверу, который создает новую реплику блока.

В заключении отметим главные особенности распределенной файловой системы GFS:

Высокая отказоустойчивость системы, автоматическое восстановление после отказов и поддержка кластеров из массовых серверов;

Ориентация на относительно небольшое число крупных файлов, которые записываются однократно;

Оптимизация под операции записи в конец файла, выполняемые одновременно многими клиентами;

Нестандартный интерфейс файловой системы и ослабленная модель целостности данных;

Эффективное использование сетевых ресурсов и оптимизация под высокую агрегированную пропускную способность.

1.2. Hadoop File System Распределенная файловая система Hadoop File System (HDFS) [5] входит в состав свободно распространяемой платформы распределенных вычислений Hadoop (см. раздел 2.2). При создании HDFS было использовано много ключевых идей из системы GFS, описанной в предыдущем разделе. Поэтому, по сути, HDFS является общедоступной альтернативой закрытой технологии GFS. Приведенное ниже описание HDFS соответствует текущей на момент написания статьи версии Hadoop 0.17.0.

Перечислим основные тезисы и предположения, повлиявшие на архитектуру и реализацию HDFS. Во многом эти предположения пересекаются с GFS. HDFS спроектирована для запуска на кластерах из массовых комплектующих, обладает высокой отказоустойчивостью и реализует автоматическое восстановление после отказов. HDFS нацелена на поддержку приложений, связанных с обработкой больших объемов данных. Поэтому акцент делается на обеспечении высокой пропускной способности при доступе к данным в потоковом режиме, а не на низкой задержке (латентности). Большие объемы данных подразумевают большие размеры хранимых файлов, измеряемые в гигабайтах и терабайтах, поэтому HDFS оптимизирована для хранения файлов подобного размера. Отказ от следования стандарту POSIX, накладывающему ряд жестких ограничений, которые не требуются для целевых приложений, позволяет повысить производительность системы. HDFS жестко следует модели однократной записи файла с последующим многократным чтением его (writeonce-read-many). Данная модель соответствует многим приложениям и упрощает обеспечение целостности данных. Текущая версия HDFS поддерживает только однократную запись в файл одним клиентом. В планах разработчиков предусмотрена реализация операции записи данных в конец файла (append), аналогичной функциональности GFS.

Пространство имен HDFS имеет иерархическую структуру с возможностью создания вложенных директорий. Каждый файл хранится в виде последовательности блоков фиксированного размера, составляющего по умолчанию 64 Мб. Копии блоков (реплики) хранятся на нескольких серверах, по умолчанию - трех. Размер блока и число реплик (т.н. фактор репликации) может задаваться индивидуально для каждого файла.

HDFS имеет очень похожую на GFS архитектуру типа “master-slave”. Главный сервер называется namenode, а подчиненные сервера – datanode. Для каждого из серверов в кластере рекомендуется использовать выделенную машину, хотя при отладке они могут быть запущены в рамках одной машины. Namenode-сервер управляет пространством имен файловой системы, репликацией и доступом клиентов к данным. Функции datanode-сервера аналогичны функциям chunk-сервера GFS:

хранение блоков данных на локальном диске, обслуживание запросов клиентов на чтение и запись данных, а также выполнение команд главного сервера по созданию, удалению и репликации блоков. Передача данных осуществляется только между клиентом и datanode-сервером, минуя namenode-сервер. Каждый datanode-сервер периодически отправляет namenode-серверу сообщения с информацией о своем состоянии и хранимых блоках, т.н. heartbeat-сообщения.

Производительность системы, состоящей из большого числа серверов в нескольких стойках (rack), существенно зависит от выбранной стратегии размещения реплик блока. В большинстве случаев, доступная пропускная способность сети между серверами в одной стойке больше, чем между серверами, находящимися в разных стойках. При размещении реплик блока в различных стойках достигается равномерное распределение реплик по кластеру и максимальная пропускная способность для чтения данных. Однако данная стратегия приводит к снижению производительности операций записи, поскольку данные требуется передать сразу в несколько стоек. В качестве альтернативы в HDFS предлагается стратегия, согласно которой первая реплика размещается на локальной машине, вторая – на другой машине в этой же стойки, а оставшиеся реплики равномерно распределяются по машинам за пределами данной стойки. При чтении данных клиент выбирает ближайшую к нему реплику, например, находящуюся с ним в одной стойке.



Namenode-сервер фиксирует все транзакции, связанные с изменением метаданных файловой системы, в log-файле, называемом EditLog. Примерами подобных транзакций могут служить создание нового файла или изменение фактора репликации у существующего файла. Все метаданные файловой системы, включая отображения файлов в блоки и атрибуты файлов, хранятся в файле FsImage. Файлы EditLog и FsImage хранятся на локальном диске namenode-сервера. Для хранения метаданных файловой системы используется компактное представление, позволяющее загружать их целиком в оперативную память namenode-сервера. При запуске namenodeсервер считывает файлы EditLog и FsImage в оперативную память и применяет все транзакции из log-файла к образу файловой системы, после чего сохраняет новую версию FsImage на диск и очищает EditLog. Подобная операция проводится пока только при запуске сервера. Во время работы сервера размер log-файла может стать очень большим, поэтому в системе предусмотрен специальный компонент (т.н.

secondary namenode), который контролирует размер log-файла и периодически обновляет файл FsImage.

Datanode-сервер хранит каждый блок данных в виде файла на локальном жестком диске. При этом серверу ничего не известно о HDFS-файлах. При запуске datanode-сервер сканирует локальную файловую систему, генерирует список хранимых HDFS-блоков и отправляет эту информацию namenode-серверу.

Клиенты и серверы HDFS взаимодействуют друг с другом по протоколу TCP с использованием механизма Remote Procedure Call (RPC). Важной особенностью, характерной также и для GFS, является то, что namenode-сервер никогда не инициирует RPC-вызовы, а только отвечает на вызовы клиентов и datanode-серверов. Все нужные инструкции datanode-серверам namenode-сервер отправляет, используя ответы на приходящие heartbeat-вызовы. Подобная техника, называемая piggybacking, позволяет уменьшить зависимость главного сервера от состояний подчиненных серверов.

Namenode-сервер контролирует состояние datanode-серверов с помощью heartbeat-сообщений. При прекращении поступления сообщений от datanode-сервера, вследствие отказа самого сервера или нарушения связности сети, данный сервер помечается как отказавший и не учитывается при обработке запросов клиентов. Все данные, хранимые на отказавшем сервере, в результате чего уровень репликации некоторых блоков падает ниже установленного значения. Namenode-сервер автоматически инициирует репликацию данных блоков. Аналогичные действия проводятся в случае сбоя жесткого диска на datanode-сервере, повреждения отдельных реплик или увеличения фактора репликации файла.

Со временем размещение данных в HDFS-кластере может оказаться несбалансированным, снижая производительность системы. Связано это может быть, например, с добавлением новых datanode-серверов или заполнением дисков на части серверов. В HDFS реализован механизм балансировки кластера, осуществляющий перераспределение данных между серверами. Процесс балансировки кластера запускается вручную администратором.

Целостность хранимых данных контролируется с помощью контрольных сумм.

При создании файла, HDFS-клиент вычисляет контрольную сумму каждого блока и сохраняет ее в специальном скрытом HDFS-файле в той же директории, что и файл.

При чтении данных клиент проверяет их на целостность с помощью соответствующего checksum-файла. В случае если проверка не проходит, клиент может обратиться за данными к другому datanode-серверу.

Данные, хранимые в файлах EditLog и FsImage на namenode-сервере, являются критичными для функционирования HDSF. Повреждение этих может привести к разрушению файловой системы. Поэтому namenode-сервер поддерживает работу с несколькими копиями данных файлов, которые могут быть размещены на других машинах. В этом случае изменения записываются синхронно в каждую из копий файла.

Данный механизм снижает производительность namenode-сервера, но позволяет увеличить его отказоустойчивость.

В текущей реализации HDFS главный сервер является “слабым местом” системы. При выходе из строя namenode-сервера система требуется ручное вмешательство, до которого система становится неработоспособной. Автоматический перезапуск namenode-сервера и его миграция на другую машину пока не реализованы.

При записи данных в HDFS используется подход, позволяющий достигнуть высокой пропускной способности. Приложение ведет запись в потоковом режиме, при этом HDFS-клиент кэширует записываемые данные во временном локальном файле.

Когда в файле накапливаются данные на один HDFS-блок, клиент обращается к namenode-серверу, который регистрирует новый файл, выделяет блок и возвращает клиенту список datanode-серверов для хранения реплик блока. Клиент начинает передачу данных блока из временного файла первому datanode-серверу из списка.





Datanode-сервер получает данные небольшими порциями, сохраняет их на диске и пересылает следующему datanode-серверу в списке. Таким образом, данные передаются в конвейерном режиме и реплицируются на требуемом количестве серверов. По окончании записи, клиент уведомляет namenode-сервер, который фиксирует транзакцию создания файла, после чего он становится доступным в системе.

Механизм удаления файлов в HDFS реализован аналогично GFS. Файл не удаляется из системы мгновенно, а перемещается в специальную директорию /trash. По истечении настраиваемого периода времени, namenode-сервер удаляет файл из пространства имен HDFS и освобождает связанные с файлом блоки. По умолчанию удаленные файлы хранятся в системе в течение 6 часов, чем объясняется задержка между формальным удалением файла и освобождением дискового пространства.

HDFS реализована на языке Java, что обеспечивает высокую переносимость системы. В то же время, HDFS тесно “привязана” к распространенной на серверах платформе GNU/Linux, что затрудняет запуск системы на ОС Windows (требуется эмулятор shell, например Cygwin).

Для доступа к HDFS из приложений программисты могут использовать прикладной интерфейс программирования (API) на языках Java и С. Также планируется реализовать доступ к HDFS через протокол WebDAV. Пользователям HDFS доступен интерфейс командной строки DFSShell. Для администрирования системы используется набор команд DFSAdmin. HDFS также предоставляет Web-интерфейс, позволяющий пользователям просматривать информацию о системе, структуру файловой системы и содержимое файлов через браузер.

В заключение отметим основные отличия текущей версии HDFS от ее прототипа - GFS:

Отсутствие автоматического восстановления после отказа главного сервера;

Отсутствие поддержки записи в файл после его создания одним или несколькими клиентами одновременно, а также операций append и snapshot;

Реализация на Java, в то время как GFS реализована на C++.

1.3. Google BigTable Система BigTable является закрытой разработкой компании Google, используемой для хранения структурированных данных многочисленными сервисами и проектами Google. Внутри Google функционирует более 500 экземпляров BigTable (т.н.

cells), крупнейший из которых насчитывает более 3 тысяч машин, хранящих свыше петабайт данных [3]. Наиболее загруженные экземпляры BigTable обслуживают в круглосуточном режиме более 500 тысяч запросов в секунду. Описание BigTable было опубликовано в работе [6].

BigTable - распределенная система хранения структурированных данных, позволяющая хранить петабайты данных на тысячах серверов. При создании системы акцент делался на следующих характеристиках: универсальность, масштабируемость, высокая производительность и надежность. Во многом BigTable напоминает базу данных и использует многие стратегии реализации, применяемые в высокопроизводительных СУБД. Однако, как будет ясно из описания, существует ряд принципиальных отличий BigTable от традиционных систем.

В отличие от реляционной модели данных, в BigTable применяется более простая модель разреженной, многомерной, сортированной хэш-таблицы. Каждое значение, хранимое в хэш-таблице, индексируется с помощью ключа строки, ключа столбца и времени: (row:string, column:string, time:int64) string. Само хранимое значение является байтовым массивом, никак не интерпретируемым системой.

Подобную хэш-таблицу можно представить в виде таблицы, каждая строка и столбец которой имеют уникальные ключи. В ячейках таблицы могут содержаться значения, причем у значения может быть несколько версий, с каждой из которых связана временная метка (timestamp). Иными словами, у таблицы есть несколько временных слоев. Выбранная модель данных обусловлена спецификой приложений Google.

Например, Web-страницы могут храниться в таблице, ключами строк в которой являются URL страниц, а в ячейках находятся несколько версий содержимого страницы, загруженных роботом в разные моменты времени. Другой особенностью хранимых данных является то, что в разных строках таблиц могут быть заполнены различные группы столбцов. Зачастую таблицы являются разреженными, что повлияло на выбор модели хранения данных, ориентированной на столбцы (column-oriented).

BigTable-кластер хранит несколько таблиц, созданных пользователями. Строки в таблицах хранятся в лексикографическом порядке значений их ключей. Диапазон значений ключей динамически разбивается на несколько частей, называемых таблетами (tablet). Разбиение на таблеты используется для распределения данных по машинам кластера. При создании таблица состоит из одного таблета. С ростом хранимых в таблице данных, она автоматически разбивается на несколько таблетов таким образом, чтобы каждый таблет был размером около 100-200 Мб.

Ключи столбцов также организованы в группы, называемые семействами столбцов (column family). Ключ столбца имеет вид family:qualifier, где family – имя семейства, а qualifier – уникальное имя столбца в рамках семейства. Перед записью данных в таблице должны быть определены используемые семейства, после чего допускается использовать любые имена для столбцов в рамках семейства.

Предполагается, что в таблице содержится небольшое число семейств, и их состав редко меняется. В то же время в таблице может быть неограниченное число столбцов.

Pages:     | 1 || 3 | 4 |   ...   | 5 |










© 2011 www.dissers.ru - «Бесплатная электронная библиотека»

Материалы этого сайта размещены для ознакомления, все права принадлежат их авторам.
Если Вы не согласны с тем, что Ваш материал размещён на этом сайте, пожалуйста, напишите нам, мы в течении 1-2 рабочих дней удалим его.