По вашему запросу ничего не найдено :(
Убедитесь, что запрос написан правильно, или посмотрите другие
наши статьи:
В одной из статей мы рассказывали Вам, что такое 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. Начинающим специалистам рекомендуется выбирать полную установку со временем конфигурацию программных инструментов можно будет менять, удаляя неиспользуемые компоненты и добавляя необходимые. Также программа установки предложит выбрать, какие элементы будут установлены на серверах. Если все сделано правильно вариант "по умолчанию" будет наилучшим выбором.
Далее нас ждет этап настройки базы данных. Настраиваем базу по умолчанию, либо выбираем альтернативный вариант, а также обязательно проверяем, как она работает. После этого настраиваем отдельные элементы в составе нашего кластера и запускаем процесс настройки по выбранным параметрам. По завершению настройки можно переходить к экрану мониторинга кластера, куда выводятся все данные по входящим в кластер серверам.
Проксирование HTTP и FTP запросов от клиента осуществляется proxy-сервером по средствам сохранения копии (кэширования) запрашиваемых клиентом данных из Интернета на системе, которая расположена ближе к получателю и последующей передачи кэшированных данных получателю с более низкой задержкой. Это может быть страничка сайта, которая расположена на определённом URL'e, например - http://shareit.merionet.ru или же какой-нибудь файл, который лежит на FTP сервере.
Введение
Роутеры MikroTik способны выполнять следующие функции в качестве web-proxy сервера:
Стандартное проксирование HTTP. Когда пользователь сам указывает кто является для него proxy-сервером и настраивает браузер соответствующим образом;
Прозрачное проксирование. Когда пользователь не знает, что его запросы перенаправляются через proxy-сервер;
Настройка списка доступа по адресу источника, назначения, URL и методу передачи запросов (GET, POST др.);
Список кэшируемых объектов. Определяет какие копии каких ресурсов сохранять, а какие нет;
Прямой список доступа. Определяет какие ресурсы доступны без проксирования и для каких нужен proxy-сервер;
Логирование событий и операций proxy-сервера
Поддержка родительских proxy-серверов. В этом случае указывается дополнительный сервер и запрос направляется к нему, если первый сервер не имеет доступа к запрашиваемому объекту.
Proxy-сервер располагается между клиентом и конечным сервером с ресурсом, к которому клиент хочет получить доступ.
Web-proxy сервер случает запросы от клиентов и сохраняет ответы у себя в памяти. Если он получит запрос, содержащий тот же URL, то он может просто отправить имеющуюся копию. Если же копии нет, то он запрашивает её у конечного сервера. То же самое с файлами, если есть сохранённая копия файла, он отправит её клиенту, если нет - скачает с FTP сервера.
Есть несколько целей применения proxy-сервера:
Ускорение получения доступа к ресурсам, которые физически находятся дальше от получателя (большая задержка при передаче пакетов);
Использование в качестве HTTP Firewall'а. Блокирование доступа к нежелательным ресурсам;
Фильтрование web-контента по заданным параметрам, например IP-адрес источника, IP-адрес назначения и порт, URL ресурса, метод HTTP запросов;
Сканирование передаваемого из внутренней сети контента, например, для предотвращения утечек. При этом совсем не обязательно использовать функции кэширования на web-proxy.
Настройка стандартного web-proxy
В роутерах MikroTik, настрока web-proxy через терминал происходит через команду:
/ip proxy set
Ниже приведен список параметров доступных для настройки:
enabled - активирует функционал web-proxy. (yes - включен, no - выключен);
src-address - устанавливает IP-адрес proxy-сервера;
port - задаёт порт, на котором будет работать proxy-сервер;
parent-proxy - задаёт адрес родительского proxy-сервера;
cache-drive - указывает куда складывать кэшируеемых данные.
cache-administrator - email администратора, который будет показан на странице с ошибкой;
max-cache-size - указывает максимальный объём для хранения кэшируемых данных на диске в килобайтах (в случае использования внешнего диска);
max-ram-cache-size - указывает максимальный объём для хранения кэшируемых данных в RAM роутера в килобайтах;
cache-only-on-disk - указывает создавать ли внутреннюю базу данных, описывающую кэшируемый на диске контент. Может сократить потребление памяти, но повлиять на скорость;
maximal-client-connections - максимальное число подключений к proxy-серверу от клиентов. Подключения сверх указанного здесь количества будут отклоняться;
maximal-server-connections - максимальное число подключений к серверам. Подключения от клиентов к другим серверам сверх указанного здесь количества будут находиться в режиме ожидания, пока некоторые текущие подключения не завершатся ;
max-fresh-time - максимальный срок хранения кэшируемого контента;
Настроим стандартный proxy-сервер на адресе 192.168.11.1, для этого через терминал вводим команду:
ip proxy> set enabled=yes port=8080 src-address=192.168.11.1
Для настройки через Winbox открываем IP → Web Proxy ставим галочку напротив Enabled, указываем IP адрес и порт, на котором будет работать наш proxy-сервер, кстати, тут же настраивается родительский прокси в разделе Parent proxy.
При настройке обычного функционала web-proxy, должна быть также выполнена настройка на стороне клиента (браузера) и указан сервер, который выступает в качестве proxy. Для настройки в Google Chrome нужно открыть Settings → Advanced → Confidentiality and Security, крутим в самый низ до пункта System и выбираем Proxy settings. В появившемся окне выбираем LAN settings → ставим галку напротив Use a proxy server for your LAN и заходим в Advanced. В появившемся окне вбиваем параметры нашего proxy-сервера в строку HTTP (в нашем случае 192.168.11.1 и порт 8080) и применяем настройки:
Настройка прозрачного проксирования
Прозрачное проксирование не требует дополнительных настроек на стороне клиентов. Более того, пользователи даже не будут подозревать, что их запросы направляются через proxy-сервер.
Чтобы настроить прозрачное проксирование, необходимо добавить NAT’ирующее правило в Firewall, которое будет определять какие HTTP запросы будут проходить через локальный proxy. Ниже показан пример того, как можно проксировать все запросы пользователей из сети 192.168.11.0/24
ip firewall nat> add chain=dstnat protocol=tcp src-address=192.168.11.0/24
dst-port=80 action=redirect to-ports=8080
Списки доступа или использование Firewall’а на основе proxy
Пожалуй, этот функционал понравится вам больше всего :)
Список доступа работает здесь также, как и в правилах Firewall – сначала читаются самые приоритетные правила, затем, вниз по списку - менее приоритетные. Критерием для применения правил может быть совпадение таких параметров как: адрес источника, порт источника, адрес назначения, порт назначения, запрашиваемый URL или HTTP метод (POST, GET и др.)
В случае совпадения критериев, заданных в правиле и параметров подключения, такое подключение может быть разрешено (allow) или запрещено (deny). Если параметры подключения не подпадают ни под один из критериев правил, то оно по умолчанию разрешается.
Понятно, что использование правил должно применяться вместе с настройками прозрачного проксирования, которые мы рассматривали выше. Итак, допустим мы настроили прозрачное проксирование для сети 192.168.11.0/24 и пустили все HTTP запросы из этой подсети через наш прокси сервер.
ip firewall nat> add chain=dstnat protocol=tcp src-address=192.168.11.0/24
dst-port=80 action=redirect to-ports=8080
Что если мы теперь хотим запретить пользователям в данной подсети сидеть во всеми любимом вконтактике? Очень просто – настроим список доступа. Для этого:
/ip proxy access add src-address=192.168.1.0/24 dst-host=www.vk.com action=deny
Мы также можем заблокировать web-сайты, которые содержат какое-либо ключевое слово или часть слова в названии, например:
/ip proxy access add src-address=192.168.1.0/24 dst-host=:er action=deny
И гуд-бай - Tinder.com, Twitter.com, Viber.com, ну вы поняли :)
Мы даже можем запретить скачивание определённых файлов:
/ip proxy access add src-address=192.168.1.0/24
add path=*.pdf action=deny
add path=*.png action=deny
add path=*.docx action=deny
add path=*.mp3 action=deny
add path=*.zip action=deny
add path=*.rar action=deny
Стоит отдельно рассказать про маски (wildcard), которые позволяют настроить более тонкое соответствие проверяемых URL’лов и других названий.
В dst-host и dst-path можно указывать следующие маски - * - любое количество символов. Например - *ings.docx будет искать .docx файлы, названия которых оканчиваются на ins или же просто файл ings.docx, то есть сюда подходят такие названия файлов – paintings.docx, wings.docx – перед ings может стоять любое количество символов.
Если поставить маску ?, то поиск будет осуществляться по количеству символов. Например маска ??ings.docx найдёт файл wnings.docx, но не найдёт paintings.docx, потому что маска задана на 2 символа.
Также поддерживаются регулярные выражения, но если вы собираетесь их использовать, то перед этим обязательно нужно поставить двоеточие :.
Межплатформенное программное обеспечение – термин, который довольно часто используется в веб-разработке. У него есть много значений в зависимости от контекста, чем он немного сбивает с толку.
Эту статью мы начнем с того, что определим этот термин, и продолжим обсуждением некоторых сценариев использования.
Изучив данную статью, вы сможете лучше вникать в обсуждения со своими коллегами, которые касаются технических и структурных аспектов. Вы также сможете разрабатывать более безопасные и надежные API и потоки данных.
Определение межплатформенного ПО
Межплатформенное ПО – это программное обеспечение, которое служит посредником между двумя приложениями или службами. Оно устраняет различные трудности их взаимодействия.
Вы можете представить, что это некий прокси-сервер, который выступает в роли накопителя данных, преобразователя или просто прокси-сервера, который перенаправляет запросы.
Распространенные сценарии использования межплатформенного ПО
Преобразователь
Существует большое количество форматов обмена данными, например, JSON, XML и Protobuf. Даже с учетом того, что сейчас мы в основном используем JSON, каждый из них имеет свои сценарии использования.
Например, считается, что Proto Buffers более производительны, нежели JSON, но при этом они не удобны для восприятия человеком. Получается, что вы можете использовать Proto Buffers для внутренних служб и JSON для случаев, когда пользователем API является браузер.
А теперь давайте предположим, что нам нужны обе эти службы, которые используют разные протоколы для взаимодействия друг с другом.
Мы можем создать межплатформенное программное обеспечение, которое использует библиотеку преобразования формата данных и преобразует запросы в формат, который будет понятен принимающей службе.
Накопление и дублирование данных
Архитектура на основе микрослужб – это популярный архитектурный шаблон, который в основном применяет в современных приложениях.
Если вы не знакомы с такой архитектурой, то это лишь значит, что ваше приложение состоит из множества независимых друг от друга маленьких приложений и служб, которые взаимодействуют через Интернет.
Например, в проекте, связанном с продажами через Интернет, у вас может быть микрослужба для добавления и извлечения товаров (Product), еще одна микрослужба для поиска (Search) и еще одна для аутентификации и хранения информации о пользователях (User). И при этом у каждой из них своя собственная база данных.
Давайте теперь представим, что мы хотим реализовать наш поиск так, чтобы мы могли найти и пользователей, и товары.
Если бы это было монолитное приложение, то можно было бы просто написать запрос для поиска в каждой таблице и объединить результаты. Но в данном случае наши базы данных работают на разных серверах.
Эту проблему можно решить несколькими способами. Мы рассмотрим два из них.
Накопление данных
Мы можем использовать межплатформенное ПО для того, чтобы отправить запросы на оба сервера и запросить выполнить поиск в их базах данных в соответствии с искомым словом.
В таком случае мы можем накапливать результаты, которые мы получаем c обоих серверов, и возвращать их клиенту. Отметим, что количество запросов увеличивается линейно по мере того, как мы увеличивает количество серверов (и при этом мы также должны объединять эти данные).
Дублирование данных
Мы можем хранить дубликаты данных на нашем поисковом сервере, чтобы он мог выполнять поиск самостоятельно без запросов к серверам, хранящим информацию о товарах и пользователях. Возможно, это менее эффективный способ с точки зрения занимаемой памяти, но он является более быстрым, а для поисковых служб решающее значение имеет именно скорость.
Если нам нужны таблицы Product (Товары) и User (Пользователи), то мы также можем создать эти таблицы на нашем поисковом сервере. В дальнейшем, когда мы будем сохранять информацию о новом пользователе в нашей базе данных пользователей, мы также будем сохранять ее копию и на поисковом сервере.
У нас есть два варианта. Первый заключается в том, что мы можем вызвать методы сохранения сервера Search с серверов User и Product, чтобы продублировать данные. Второй состоит в том, что мы можем создать межплатформенное ПО для того, чтобы хранит там данные. И оно будет делать следующее:
При каждом запросе на сохранение, оно будет вызывать методы сохранения сервера Search и сервера User/Product.
Если первое сохранение выполнилось неудачно, оно не будет вызывать методы сохранения на другом сервере (таким образом обеспечивается согласованность баз данных).
Давайте взглянем на две структурные диаграммы. На одной из них есть межплатформенное ПО, а на второй - нет. Вот так выглядит диаграмма без межплатформенного ПО:
Выглядит не очень, да? Что правда, то правда, это действительно выглядит ужасно, и такой подход сделает ваш код более сложным и сильно связанным.
А вот так выглядит аналогичное решение только с межплатформенным ПО:
В этом случае клиент просто вызывает межплатформенное программное обеспечение, чтобы сохранить информацию о товаре или пользователе, а оно уже делает все остальное.
Код, который выполняет дублирование данных, отсутствует как на серверах User и Product, так и на клиентской стороне. Это теперь забота межплатформенного ПО.
Безопасность API
Мы можем просматривать исходящие запросы для любого кода клиентской стороны. Сделать это можно либо в консоли браузера, либо через прокси-сервер.
Мы уже как-то говорили о пользовательском сервере, который обеспечивает вход в систему и регистрацию. Если наш клиентский код напрямую отправляет запросы на этот сервер, то он тем самым раскрывает адрес нашего сервера аутентификации. А если IP-адрес нашего сервера узнают злоумышленники, то они могут воспользоваться специальными инструментами, чтобы найти наши конечные точки и просканировать наш сервер на наличие уязвимостей.
Для того, чтобы скрыть URL-адрес нашего сервера аутентификации, мы можем использовать межплатформенное ПО в качестве прокси-сервера. Наш клиент будет взаимодействовать с межплатформенным ПО, а оно уже будет перенаправлять запрос на сервер аутентификации и возвращать ответ.
Такой подход также позволит нам блокировать любые запросы на наш сервер аутентификации, кроме тех, которые идут с URL-адреса нашего межплатформенного ПО. Это обезопасит наш сервер аутентификации.
Раньше это было бы невозможно, так как наш внешний интерфейс взаимодействовал с сервером аутентификации, а так как внешний интерфейс – это компьютер клиента, то у нас не было бы возможности применить IP-фильтр.
Предоставление общедоступных API
Их предыдущего пункта мы узнали, что межплатформенное ПО можно использовать в целях ограничения доступа к нашему API.
А теперь давайте взглянем на вторую часть этого уравнения: что если мы хотим предоставить доступ к нашему API, но при этом хотим, чтобы он был ограничен? А вдруг мы являемся системным программистом в банке, а банк планирует устроить хакатон. Ему будет необходимо предоставить доступ к своему API, верно?
Но поскольку это банк, то, очевидно, что он не может предоставить доступ ко всему API и разрешить все операции. Это значит, что необходимо найти такой способ, который позволит предоставить ограниченный доступ.
Для этого можно реализовать межплатформенное ПО, которое предоставит доступ лишь к некоторым конечным точкам и будет перенаправлять запросы в фактическому API банка. Таким образом, банк сможет предоставить этот API разработчикам на хакатоне.
Заключение
Мы начали с определения того, что такое межплатформенное программное обеспечение, и постарались распределить по категориям сценарии использования межплатформенного ПО в веб-разработке.
Имейте в виду, что это далеко не весь список сценариев использования, но я надеюсь, что, несмотря на это, он все-таки оказался для вас полезным.