По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В одной из статей мы рассказывали Вам, что такое Hadoop и с чем его едят. В этой статье мы подробно разберем, как развернуть кластер Hadoop с помощью сборки Cloudera.
Почему Cloudera?
Почему мы выбрали именно этот дистрибутив? Дело в том, что на текущий момент он является самым популярным и широко распространенным набором инструментов для работы с большими объемами данных. Кроме того, данный дистрибутив имеет в составе такое решение как Cloudera Manager этот инструмент позволяет без лишних телодвижений развернуть новый кластер, а также осуществлять управление и наблюдение за его состоянием.
Стоит отметить, что распространение элементов данной сборки осуществляется в виде так называемых парселов пакетов информации в бинарной кодировке. Преимуществами такого решения являются упрощенная загрузка, взаимная согласованность компонентов, возможность единовременной активации всех необходимых установленных элементов, текущие (не кардинальные) обновления без прерывания рабочего процесса, а также простота восстановления после возникновения неполадок.
Также важно представлять, для каких целей Вы будете использовать кластеры Hadoop. Это связано с тем, что для выполнения различных задач Вам потребуются разные варианты по аппаратной мощности. Как правило, конфигурации, используемые для хранения данных, имеют повышенную мощность, а значит, и более высокую стоимость.
Требования к железу
Проработав вопросы с железом, нужно подготовить для развертки кластера программную часть. Для установки и работы потребуется любая система на основе Ubuntu, а также популярными вариантами являются различные версии CentOS, RHEL и Debian. Эти сборки находятся в открытом доступе на сайте разработчика, поэтому с подготовкой сложностей возникнуть не должно.
При установке на серверах будущего кластера при разбивке дисков стоит выделять около 70Гб под программную часть, около 1Гб для внутреннего участка памяти для выгрузки данных из кэша, остальную емкость можно оставить непосредственно для хранения данных.
Установка
Подготовив почву для установки, можно приступать непосредственно к процессу. Проверив соединение с серверами, их доступность и синхронизацию, а так же имеют одинаковые пароли root, а так же убедившись, что все сервера имеют доступ к сайту разработчика для обновления программной части, можно устанавливать непосредственно Cloudera Manager. Далее наше участие в процессе установки будет минимальным программа сама установит все необходимые компоненты. По ее завершению, можно запускать стандартную базу данных, и собственно саму программу.
Далее приступим к, собственно, развертыванию кластера. Это удобнее делать через веб-интерфейс. В строку браузера вводим адрес сервера, затем войдем в систему по умолчанию логин и пароль admin и admin разумеется, первым делом меняем пароли.
Далее выбираем версию дистрибутива. Есть бесплатный вариант с ограниченным функционалом, 60-дневная пробная версия и платная лицензия, предоставляющая наиболее полный набор функций, включая поддержку от производителя. При выборе базовой бесплатной версии можно будет в будущем активировать любую из оставшихся. Это актуально в случае, если программа Вам понравится, и вы приобретете базовые навыки работы с кластером.
В процессе установки Cloudera Manager устанавливает соединение с серверами, входящими в кластер. По умолчанию используется root и одинаковое имя пользователя, поэтому важно чтобы пароли root на всех серверах были одинаковы.
Следующим шагом станет указание хостов, куда будут устанавливаться рабочие элементы Hadoop, а также проверим, все ли сделано верно, и нет ли потерь. Затем выберем репозиторий, из которого будут скачиваться данные для установки, а также выберем вариант с использованием парселов, как и рекомендуется. Можно еще выбрать установку дополнительных инструментов актуальных версий поисковика SOLR и базы данных на основе Impala. Вводим параметры доступа по SSH и запускаем процесс установки.
По окончании установки получаем отчет о всех установленных элементах и их актуальных версиях, после его изучения переходим к следующему этапу выбору вариантов установки дополнительных компонентов Hadoop. Начинающим специалистам рекомендуется выбирать полную установку со временем конфигурацию программных инструментов можно будет менять, удаляя неиспользуемые компоненты и добавляя необходимые. Также программа установки предложит выбрать, какие элементы будут установлены на серверах. Если все сделано правильно вариант "по умолчанию" будет наилучшим выбором.
Далее нас ждет этап настройки базы данных. Настраиваем базу по умолчанию, либо выбираем альтернативный вариант, а также обязательно проверяем, как она работает. После этого настраиваем отдельные элементы в составе нашего кластера и запускаем процесс настройки по выбранным параметрам. По завершению настройки можно переходить к экрану мониторинга кластера, куда выводятся все данные по входящим в кластер серверам.
Подход DevSecOps с частым систематическим сканированием приложений на наличие уязвимостей значительно увеличивает процент программного обеспечения с исправленными уязвимостями и сокращает время, необходимое для выпуска исправлений, что особенно важно в контексте критических ошибок. Согласно Veracode State of Software Security Vol. 10, по сравнению с 2018 годом процент уязвимых приложений увеличился в 2019 году с 52 до 56%. С другой стороны, в случае приложений, сканируемых один раз в месяц или реже, среднее время обновления составляло 68 дней, в то время как приложения, сканируемые не реже одного раза в день, имели в среднем 19 дней для обновления.
Эти результаты, а также выводы исследования Enterprise Strategy Group подтверждают, насколько сегодня важно последовательно и как можно раньше расширять процесс разработки приложений до стадии тестирования безопасности. В прошлом эта задача входила в обязанности отдела безопасности и выполнялась после завершения программирования. Сегодня сами разработчики также должны продемонстрировать соответствующие компетенции.
Новые модели и способы доставки программного обеспечения - общедоступное облако, контейнеры и микросервисы - положили конец большим выпускам приложений и редким обновлениям. Вместо них у нас есть молниеносные циклы публикации, а приложения разделены на более мелкие, независимо работающие модули. В результате программное обеспечение просто создается слишком быстро, и новые версии приложения, так называемые выпуски могут идти "в производство" в оптовых количествах даже на один день, чтобы проверка безопасности по методологии WaterFall была эффективной. Ситуация дополнительно осложняется тем фактом, что конечный продукт, то есть приложение с определенной функциональностью, содержит как код, созданный внутри компании, так и элементы, заимствованные из открытых бесплатных репозиториев или через менеджеры пакетов).
Следовательно, функционирование разработки, операций и безопасности как отдельных организационных структур не существует и не может существовать. Разработчикам следует понимать, что поддержка и защита программного обеспечения также зависят от них.
Мы продолжаем рассказывать про протокол DHCP (Dynamic Host Configuration Protocol) . Мы уже знаем про принципы работы протокола и про его настройку на оборудовании Cisco, и сегодня речь пойдет о том, как находить и исправлять проблемы (заниматься траблшутингом) при работе с DHCP.
Проблемы с DHCP могут возникать по множеству причин, таких как проблемы программного обеспечения, в операционных системах, драйверов сетевых карт или агентах ретрансляции, но наиболее распространенными являются проблемы с конфигурацией DHCP. Из-за большого числа потенциально проблемных областей требуется систематический подход к устранению неполадок.
Задача 1. Устранение конфликтов IP адресов
Срок действия адреса IPv4 может истекать у клиента, все еще подключенного к сети. Если клиент не возобновляет аренду, то сервер может переназначить этот IP-адрес другому клиенту. Когда клиент перезагружается, то он запрашивает адрес и если DHCP сервер не отвечает быстро, то клиент использует последний IP-адрес. Тогда возникает ситуация, когда два клиента используют один и тот же адрес, создавая конфликт.
Команда show ip dhcp conflict отображает все конфликты адресов, записанные сервером DHCP. Сервер использует команду ping для обнаружения клиентов. Для обнаружения конфликтов клиент использует протокол ARP. Если обнаружен конфликт адресов, адрес удаляется из пула и не назначается, пока администратор не разрешит конфликт.
Выгладит это так:
Router# show ip dhcp conflict
IP address Detection Method Detection time
192.168.1.33 Ping Feb 19 2018 10:33 AM
192.168.1.48 Gratuitous ARP Feb 19 2018 11:29 AM
В столбце IP address указывается конфликтный адрес, в строке Detection Method указывается метод обнаружения (Ping – адрес был обнаружен когда при назначении нового адреса получил положительный ответ на пинг, Gratuitous ARP – конфликт обнаружен в ARP таблице) и Detection time показывает время обнаружения.
Чтобы посмотреть список всех выданных адресов сервером используется команда show ip dhcp binding.
Задача 2. Проверка физического подключения
Сначала нужно проверить, что интерфейс маршрутизатора, действующий как шлюз по умолчанию для клиента, является работоспособным. Для этого используется команда show interface [интерфейс] , и если интерфейс находится в каком либо состоянии кроме как UP, то это означает что порт не передает трафик, включая запросы клиентов DHCP.
Задача 3. Проверка связности, используя статический IP адрес
При поиске проблем DHCP проверить общую работоспособность сети можно задав статический IP адрес у клиента. Если он может достичь сетевых ресурсов со статически настроенным адресом, то основной причиной проблемы является не DHCP.
Задача 4: Проверить конфигурацию порта коммутатора
Если DHCP клиент не может получить IP адрес с сервера, то можно попробовать получить адрес вручную, заставляя клиента отправить DHCP запрос.
Если между клиентом и сервером DHCP есть маршрутизатор и клиент не может получить адрес, то причиной могут быть настройки портов. Эти причины могут включать в себя проблемы, связанные с транками и каналами, STP и RSTP. Конфигурация PortFast и настройка пограничных портов разрешают наиболее распространенные проблемы клиента DHCP, возникающие при первоначальной установке коммутатора.
Задача 5: Проверка работы DHCP в одной и той же подсети или VLAN
Важно различать, правильно ли работает DHCP, когда клиент находится в одной подсети или VLAN, что и DHCP-сервер. Если DHCP работает правильно, когда клиент находится в одной подсети, то проблема может быть ретранслятором DHCP (relay agent). Если проблема сохраняется даже при тестировании в одной подсети, то проблема может быть с сервером DHCP.
Проверка конфигурации DHCP роутера
Когда сервер DHCP находится в отдельной локальной сети от клиента, интерфейс маршрутизатора, обращенный к клиенту, должен быть настроен для ретрансляции запросов DHCP путем настройки helper адреса.
Чтобы проверить конфигурацию маршрутизатора для начала нужно убедиться, что команда ip helper-address настроена на правильном интерфейсе. Она должна присутствовать на входящем интерфейсе локальной сети, содержащей DHCP клиентов, и должна быть направлена на правильный сервер DHCP. Для проверки используется команда show ip interface [интерфейс] . Далее нужно убедиться, что в глобальном режиме не была введена команда no service dhcp . Эта команда отключает все функции сервера DHCP и ретрансляции на маршрутизаторе. Для проверки используется команда show running-config | include no service dhcp. Если команда была введена, то она отобразится в выводе.
Дебаг DHCP
На маршрутизаторах, настроенных как DHCP-сервер, процесс DHCP не выполняется если маршрутизатор не получает запросы от клиента. В качестве задачи по траблшутингу нужно убедиться, что маршрутизатор получает запрос от клиента. Для этого дебага понадобится конфигурация ACL (Access Control List).
Нужно создать расширенный Access List, разрешающий только пакеты с UDP портами назначения 67 или 68. Это типичные порты, используемые клиентами и серверами при отправке сообщений DHCP. Расширенный ACL используется с командой debug ip packet для того чтобы отображать только сообщения DHCP.
Router(config)# access-list 100 permit udp any any eq 67
Router(config)# access-list 100 permit udp any any eq 68
Router(config)# end
Router# debug ip packet 100
IP packet debugging is on for access list 100
*IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, rcvd 2
*IP: s-0.0.0.0 (GigabitEthernet1/1), d-255.255.255.255, len 333, stop process pak for forus packet
*IP: s-192.168.1.1(local), d-255.255.255.255 (GigabitEthernet1/1), len 328, sending broad/multicast
Результат в примере показывает, что маршрутизатор получает запросы DHCP от клиента. IP-адрес источника равен 0.0.0.0, поскольку клиент еще не имеет адреса, адрес назначения - 255.255.255.255, потому что сообщение об обнаружении DHCP от клиента отправляется в виде широковещательной передачи. Этот вывод показывает только сводку пакета, а не сообщение DHCP. Тем не менее, здесь видно, что маршрутизатор получил широковещательный пакет с исходными и целевыми IP-адресами и портами UDP, которые являются правильными для DHCP.
Другой полезной командой для поиска неполадок DHCP является команда событий debug ip dhcp server. Эта команда сообщает о событиях сервера, таких как назначения адресов и обновления баз.
Router(config)#debug ip dhcp server events
DHCPD: returned 192.168.1.11 to address pool POOL-1
DHCPD: assigned IP address 192.168.1.12 to client 0011:ab12:cd34
DHCPD: checking for expired leases
DHCPD: the lease for address 192.168.1.9 has expired
DHCPD: returned 192.168.1.9 to address pool POOL-1