Разработка кластера Cloudera CDH в AWS: экземпляры и хранилище
У меня есть некоторые сомнения по поводу развертывания CDH на AWS. Я прочитал справочный документ по архитектуре и другие материалы, которые я нашел в блоге Cloudera Engineering, но мне нужно еще несколько советов по этому поводу.
1) Доступно ли развертывание CDH только для некоторых экземпляров, или я могу развернуть его на всех типах экземпляров AWS?
2) Если я хочу создать кластер, который будет активен 24x7. Для долго работающего кластера я понял, что лучше иметь кластер, основанный на экземплярах локального хранилища. Если мы рассмотрим кластер из 2PB, я думаю, что d2.8xlarge должно быть лучшим выбором для датододов. О мастер-узлах: - если я хочу развернуть только 3 мастер-узла, лучше ли использовать их как экземпляры локального хранилища или как подключенные EBS экземпляры, чтобы иметь возможность быстро реагировать на возможный сбой мастер-узла? - есть ли лучшая практика в отношении типа экземпляра главного узла (EBS или локальное хранилище)? Об узлах данных: - если узел данных выходит из строя, есть ли у CDH какой-то автоматизированный механизм для автоматического раскрутки нового экземпляра и его подключения к кластеру для восстановления кластера без простоев? Должны ли мы создать сценарий с нуля, чтобы сделать это? О пограничных узлах: - есть ли лучшие рекомендации по типу экземпляра (EBS или локальное хранилище)?
3) Если я хочу сделать резервную копию кластера на S3: - когда я выполняю distcp с CDH на S3, могу ли я переместить данные непосредственно на Glacier вместо обычного S3? Если к данным применяется сжатие (например, snappy, gzip и т. Д.), И я выполняю distcp для S3: - Пространство, занимаемое на S3, одинаково или команда distcp распаковывает данные для копии?
Если у меня есть кластер на основе подключенных экземпляров EBS: - возможно ли сделать моментальный снимок дисков и повторно присоединить датодан с дисками EBS, восстановленными из моментального снимка?
4) Если у меня есть узлы данных, развернутые как r4.8xlarge, и мне нужно больше лошадиных сил, возможно ли увеличить кластер с r4.8xlarge до r4.16xlarge на лету? Присоединение и отсоединение дисков за несколько минут?
Большое спасибо за разъяснения, надеюсь, мои сомнения помогут и другим пользователям.
2 ответа
1) Нет явного ограничения на типы экземпляров, где будут работать компоненты CDH, но вам нужно будет выбирать типы с минимальной мощностью. Например, я не ожидаю, что экземпляр микроразмера будет работать для чего угодно. Слишком маленький тип обычно приводит к нехватке памяти у демонов. Эталонная архитектура предложила типы экземпляров для определенных ситуаций.
2) Вы должны придерживаться EBS для корневого тома типов экземпляров. Есть несколько причин, в том числе то, что более новые типы экземпляров даже не поддерживают локальное хранилище экземпляров для корневого диска.
CDH не имеет механизма для замены узлов данных, когда они выходят из строя. Вы можете сделать что-нибудь самостоятельно, возможно, с помощью директора Cloudera.
3) Вы можете настроить правила жизненного цикла для данных в S3, чтобы перенести их из стандартного класса хранения в Glacier с течением времени, или вы можете просто написать напрямую в Glacier; не похоже, что прямой доступ к Glacier может быть осуществлен через разъем s3a. Я уверен, что distcp и S3 не будут возиться со сжатием; то, что вы копируете, непрозрачно для S3. Вы можете сделать снимки томов EBS (root или дополнительно подключенные), затем отсоединить их и повторно присоединить к другому экземпляру; это не обязательно отличный способ для резервного копирования датоданий по сравнению с маршрутом distcp, потому что каждая датодода уникальна и имеет изменяющиеся данные во время работы кластера.
4) Вы можете изменить размер экземпляров EC2, поддерживаемых EBS, без отсоединения и повторного подключения дисков. Вы должны остановить экземпляр, чтобы изменить его размер.
Только пункт 3:
- Вам нужно подключиться к S3 и переместить его на ледник через настройки AWS
- Он ничего не делает с данными, сжатием и т. Д.
- см. (hortonworks doc) Distcp и S3 и прочитайте его предупреждения / предостережения. В частности, инкрементный distcp не основан на контрольной сумме, атомарный distcp - нет, это просто "очень медленный distcp"