Требования к оборудованию

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

В настоящее время поставщики предлагают оборудование для облачных центров обработки данных, предусматривающего снижение цены, потребляемой мощности и веса. Компании Supermicro, Dell и HP поставляют подобные линейки продуктов для провайдеров облачных услуг. Поэтому при покупке оборудования для больших кластеров обращайте внимание на такие минимальные конфигурации "облачных серверов".

Для узла DataNode достаточно единственного источника питания, но для узла NameNode используйте вариант с резервированием. Решение с использованием общих источников питания для нескольких серверов повышает надежность без существенного увеличения стоимости.

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

Это также одна из наиболее значимых систем, поскольку нагрузка в Hadoop очень изменчивая. Очень важны разумные затраты при обеспечении достаточной скорости взаимодействия между узлами. Типовым является подключение каждого узла к коммутатору в рамках одной стойки на 20 позиций с помощью двухканального интерфейса по 1 Гбит/с и межсоединение (interconnect) 2*10 Гбит/с всех стоек через пару центральных коммутаторов.

Хороший сетевой проект принимает в расчет возможность превышения допустимой пропускной способности в критических узлах сети под реальной нагрузкой. Общепринятые коэффициенты превышения возможности сети (oversubscription ratios) составляют приблизительно 4:1 на уровне доступа к серверу и 2:1 между уровнем доступа и уровнем агрегации или ядром сети. При высоких требованиях к производительности снижайте эти коэффициенты. Кроме того, между стойками возможно превышение на 1 Гбит/с.

Критически важно установить выделенные коммутаторы для кластера вместо попыток организовать виртуальные соединения (virtual connect) в уже существующих коммутаторах. В противном случае нагрузка от кластера Hadoop будет влиять на остальных пользователей этого оборудования. Также критически важно работать совместно с командой обслуживания сети при выборе коммутаторов, удовлетворяющих требованиям и со стороны Hadoop, и со стороны средств мониторинга.

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