Мы готовимся к реализации нашего первого кластера Hadoop. Таким образом, мы начинаем с малого с установки из четырех узлов. (1 главный узел и 3 рабочих узла) У каждого узла будет 6 ТБ памяти. (6 дисков по 1 ТБ) Мы выбрали 4-узловое шасси SuperMicro, так что все четыре узла используют один блок 4U.
Теперь мы рассмотрим, как сделать резервную копию этого решения для аварийного восстановления. (Подумайте о потере стойки или сайта, а не о потере диска). Лучшее решение - это копирование из кластера в кластер. Хотя я также читал о людях, копирующих данные в общий ресурс NAS или SMB. Кроме того, мы собираемся создать резервную копию главного узла с помощью традиционных средств резервного копирования. Меня беспокоят только данные HDFS. Вот мои вопросы:
1) Могу ли я настроить кластер с одним узлом с большим объемом хранилища для копирования из кластера в кластер, чтобы он работал как моя внешняя реплика? Меня не волнует его производительность, просто его наличие и способность хранить весь набор данных. (Время восстановления не имеет значения, поскольку этот кластер не является критически важным). Можно ли запланировать копию так, чтобы она запускалась только один раз в день и т. Д.?
2) Как это работает для варианта SMB или NAS? Нужно ли форматировать целевой диск в HDFS? Нужно ли мне делать резервную копию каждого из трех рабочих узлов целиком? Или есть какой-то умный сценарий, который может создавать резервные копии набора данных без четности? Я не очень знаком с этим решением и видел только ссылки на него в Интернете. Мне не очень повезло с поиском ресурсов или информации.
Я также открыт для любых других вариантов DR для Hadoop HDFS. Наша цель - получить полную копию набора данных HDFS, чтобы мы могли использовать ее для восстановления после потери стойки или сайта.
Спасибо!
Файлы Hdf по замыслу копируются, как правило, минимум на 3 узла, поэтому, если у вас есть 3 узла, данные реплицируются уже на всех трех.
Конечно, эти узлы должны находиться на разных физических серверах. Тогда маловероятно, что выйдет из строя или все 3 сразу выйдут из строя.
Чтобы реплицировать ваши текущие hdfs, вы можете просто добавить узлы к сервису hdfs на других серверах, и данные будут реплицированы. Чтобы быть уверенным, что данные реплицируются более чем на 3 исходных узла, увеличьте настройку отказоустойчивости до 4 или более узлов. Thrn Выключите другие узлы на одном устройстве, и ваши данные будут на всех узлах, оставшихся активными.
Для варианта 1 вы можете использовать distcp копировать из одного кластера в другой. Резервный кластер, безусловно, может быть сервером с одним узлом, если на нем запущены именной узел и узел данных. По сути, вы смотрите на обкатку псевдораспределенный режим. Чтобы периодически запускать distcp,
Чтобы делать это периодически, я бы создал сценарий оболочки, который делал бы что-то вроде следующего:
Я предлагаю использовать файл блокировки, потому что вы не хотите, чтобы выполнялось несколько distcp. в этой конкретной настройке. В конечном итоге вы перегрузите свой псевдораспределенный кластер. Я бы также установил коэффициент репликации по умолчанию равным 1 в конфигурации псевдораспределенного кластера. Нет необходимости удваивать блоки, если вам это не нужно (хотя я не могу вспомнить, делает ли это по умолчанию псевдокластер; YMMV).
distcp можно заставить работать как тупой rsync, копируя только те вещи, которые меняются.
Для варианта 2 вы можете использовать hadoop fs -copyToLocal. Обратной стороной этого является то, что он каждый раз полностью копируется, поэтому, если вы копируете /, он копирует все при каждом запуске.
Для метаданных hadoop вам нужно скопировать файл fsimage and edits. Этот блог имеет довольно разумный обзор того, что делать. Он ориентирован на использование Cloudera, но должен быть в основном одинаковым для любого кластера Hadoop 1.0 или 2.0.