Дик-ДИ_2018_МУ. Технология построения защищенных распределенных приложений
 Скачать 0.74 Mb.
|
|
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ РОССИЙСКОЙ ФЕДЕРАЦИИ федеральное государственное бюджетное образовательное учреждение высшего образования «Курганский государственный университет» Кафедра «Безопасность информационных и автоматизированных систем» ТЕХНОЛОГИЯ ПОСТРОЕНИЯ ЗАЩИЩЕННЫХ РАСПРЕДЕЛЕННЫХ ПРИЛОЖЕНИЙ Методические указания к выполнению лабораторных работ для студентов направлений 10.05.03 и 10.03.01 Курган 2018 2 Кафедра: «Безопасность информационных и автоматизированных систем». Дисциплина: «Технология построения защищенных распределенных приложений». Составил: канд. техн. наук, доцент Д.И. Дик. Утверждены на заседании кафедры « 24 » ноября 2017 г. Рекомендованы методическим советом университета « 12 » декабря 2016 г. 3 СОДЕРЖАНИЕ 1 Лабораторная работа № 1. Развертывание системы распределенных вычислений Hadoop ..................................................................................................... 5 1.1 Цель работы ........................................................................................................ 5 1.2 Общие сведение ................................................................................................. 5 1.2.1 Архитектура Hadoop ................................................................................... 5 1.2.2 Введение в MapReduce ................................................................................ 7 1.3 Порядок выполнения работы .......................................................................... 11 1.3.1 Установка операционной системы .......................................................... 11 1.3.2 Установка Java ......................................................................................... 112 1.3.3 Создание отдельной учетной записи для запуска Hadoop .................. 112 1.3.4 Настройка статического IP адреса ......................................................... 112 1.3.5 Настройка доменного имени узла .......................................................... 112 1.3.6 Настройка SSH ........................................................................................... 13 1.3.7 Отключение IPv6 ....................................................................................... 13 1.3.8 Установка Apache Hadoop ........................................................................ 13 1.3.9 Обновление $HOME/.bashrc ..................................................................... 14 1.3.10 Настройка Apache Hadoop ...................................................................... 14 1.3.11 Создание на главном узле файл подкачки ............................................ 18 1.3.12 Запуск Hadoop .......................................................................................... 19 1.3.13 Дополнительные команды ...................................................................... 19 1.4 Контрольные вопросы ................................................................................... 200 2 Лабораторная работа № 2. Настройка репликации на СУБД MySQL ............ 211 2.1 Цель работы .................................................................................................... 211 2.2 Общие сведение ............................................................................................. 211 2.2.1 Репликация данных ................................................................................. 211 2.2.2 Master-slave репликация ......................................................................... 211 2.2.3 Master-slave репликация на несколько slave серверов ......................... 222 2.2.4 Задержка репликации .............................................................................. 233 2.2.5 Выход из строя сервера при master-slave репликации ......................... 233 2.2.6 Резервирование ........................................................................................ 233 2.2.7 Master-master репликация ....................................................................... 244 2.2.8 Выход из строя сервера при master-master репликации ...................... 244 2.2.9 Проблемы репликации в MySQL ........................................................... 244 2.2.10 Польза от асинхронной репликации .................................................... 266 2.3 Порядок выполнения работы ........................................................................ 266 2.3.1 Установка операционной системы ........................................................ 266 2.3.2 Настройка статического IP адреса ......................................................... 277 2.3.3 Настройка доменного имени узла .......................................................... 277 2.3.4 Настройка SSH ......................................................................................... 288 2.3.5 Копирование образа виртуальной машины .......................................... 288 2.3.6 Установка MySQL сервера ..................................................................... 288 2.3.7 Настройка master-slave репликация ....................................................... 299 2.3.8 Настройка master-master репликация ...................................................... 33 4 2.4 Контрольные вопросы ..................................................................................... 34 3 Лабораторная работа № 3. Развертывание Percona XtraDB Cluster .................. 35 3.1 Цель работы ...................................................................................................... 35 3.2 Общие сведение ............................................................................................... 35 3.2.1 Общая информация о Percona XtraDB Cluster ........................................ 35 3.2.2 Проблема split-brain и использование кворума ...................................... 37 3.2.3 Особенности репликации в Percona XtraDB Cluster .............................. 38 3.3 Порядок выполнения работы .......................................................................... 39 3.3.1 Установка операционной системы .......................................................... 39 3.3.2 Добавление репозитария Percona ............................................................. 39 3.3.3 Настройка статического IP адреса ........................................................... 40 3.3.4 Установка Percona XtraDB Cluster ........................................................... 41 3.3.5 Добавление узлов в кластер ..................................................................... 43 3.3.6 Проверка работы репликации .................................................................. 44 3.3.7 Установка ProxySQL ................................................................................. 45 3.3.8 Добавление узлов кластера в ProxySQL ................................................. 47 3.3.9 Создание пользования для мониторинга узлов ...................................... 48 3.3.10 Создание пользователя для доступа к узлам кластера ........................ 49 3.3.11 Конфигурирование поддержки Galera .................................................. 50 3.3.12 Тестирование узла с помощью sysbench ............................................... 51 3.3.13 Автоматическое обнаружение отказов ............................................... 552 3.4 Контрольные вопросы ................................................................................... 552 5 ЛАБОРАТОРНАЯ РАБОТА № 1. РАЗВЕРТЫВАНИЕ СИСТЕМЫ РАСПРЕДЕЛЕННЫХ ВЫЧИСЛЕНИЙ HADOOP 1.1 Цель работы Цель лабораторной работы заключается в закреплении теоретических основ курса «Технологии построения распределенных защищенных приложений» и получении первоначальных навыков настройки и использования системы Hadoop. 1.2 Общие сведение Hadoop — популярная программная платформа (software framework) построения распределенных приложений для массово-параллельной обработки (massive parallel processing, MPP) данных в рамках вычислительной парадигмы MapReduce. Hadoop cчитается одним из основополагающих решений в области «больших данных» (big data). Вокруг Hadoop образовалась целая экосистема из связанных проектов и технологий. 1.2.1 Архитектура Hadoop Hadoop состоит из четырёх модулей: связующее программное обеспечение Hadoop Common; распределённая файловая система HDFS; система для планирования заданий и управления кластером; платформа программирования и выполнения распределённых MapReduce вычислений Hadoop MapReduce. В Hadoop Common входят библиотеки управления файловыми системами, поддерживаемыми Hadoop, и сценарии создания необходимой инфраструктуры и управления распределённой обработкой. HDFS (Hadoop Distributed File System) — файловая система, предназначенная для хранения файлов больших размеров, поблочно распределённых между узлами вычислительного кластера. Все блоки в HDFS (кроме последнего блока файла) имеют одинаковый размер, и каждый блок может быть размещён на нескольких узлах, размер блока и коэффициент репликации (количество узлов, на которых должен быть размещён каждый блок) определяются в настройках на уровне файла. Благодаря репликации обеспечивается устойчивость распределённой системы к отказам отдельных узлов. Файлы в HDFS могут быть записаны лишь однажды (модификация не поддерживается), а запись в файл в одно время может вести только один процесс. Организация файлов в пространстве имён — традиционная иерархическая: есть корневой каталог, поддерживается вложение каталогов, в одном каталоге могут располагаться и файлы, и другие каталоги. 6 Развёртывание экземпляра HDFS предусматривает наличие центрального узла имён (name node), хранящего метаданные файловой системы и метаинформацию о распределении блоков, и серии узлов данных (data node), непосредственно хранящих блоки файлов. Узел имён отвечает за обработку операций уровня файлов и каталогов — открытие и закрытие файлов, манипуляция с каталогами, узлы данных непосредственно отрабатывают операции по записи и чтению данных. Узел имён и узлы данных снабжаются веб-серверами, отображающими текущий статус узлов и позволяющими просматривать содержимое файловой системы. HDFS является неотъемлемой частью проекта, однако, Hadoop поддерживает работу и с другими распределёнными файловыми системами без использования HDFS, поддержка Amazon S3 и CloudStore реализована в основном дистрибутиве. С другой стороны, HDFS может использоваться не только для запуска MapReduce-заданий, но и как распределённая файловая система общего назначения, в частности, поверх неё реализована распределённая NoSQL-СУБД HBase, в её среде работает масштабируемая система машинного обучения Apache Mahout. YARN (англ. Yet Another Resource Negotiator — «ещё один ресурсный посредник») — модуль, появившийся с версией 2.0 Hadoop, отвечающий за управление ресурсами кластеров и планирование заданий. Если в предыдущих выпусках эта функция была интегрирована в модуль MapReduce, где была реализована единым компонентом (JobTracker), то в YARN функционирует логически самостоятельный демон — планировщик ресурсов (ResourceManager), абстрагирующий все вычислительные ресурсы кластера и управляющий их предоставлением приложениям распределённой обработки. Работать под управлением YARN могут как MapReduce-программы, так и любые другие распределённые приложения, поддерживающие соответствующие программные интерфейсы. YARN обеспечивает возможность параллельного выполнения нескольких различных задач в рамках кластера и их изоляцию (по принципам мультиарендности). Разработчику распределённого приложения необходимо реализовать специальный класс управления приложением (ApplicationMaster), который отвечает за координацию заданий в рамках тех ресурсов, которые предоставит планировщик ресурсов; планировщик ресурсов же отвечает за создание экземпляров класса управления приложением и взаимодействия с ним через соответствующий сетевой протокол. Hadoop MapReduce — программный каркас для программирования распределённых вычислений в рамках парадигмы MapReduce. Разработчику приложения для Hadoop MapReduce необходимо реализовать базовый обработчик, который на каждом вычислительном узле кластера обеспечит преобразование исходных пар «ключ — значение» в промежуточный набор пар «ключ — значение» (класс, реализующий интерфейс Mapper, назван по функции высшего порядка Map), и обработчик, сводящий промежуточный набор пар в окончательный, сокращённый набор (свёртку, класс, реализующий интерфейс Reducer). Каркас передаёт на вход свёртки отсортированные выводы 7 от базовых обработчиков, сведе́ние состоит из трёх фаз — shuffle (тасовка, выделение нужной секции вывода), sort (сортировка, группировка по ключам выводов от распределителей — досортировка, требующаяся в случае, когда разные атомарные обработчики возвращают наборы с одинаковыми ключами, при этом правила сортировки на этой фазе могут быть заданы программно и использовать какие-либо особенности внутренней структуры ключей) и собственно reduce (свёртка списка) — получения результирующего набора. Для некоторых видов обработки свёртка не требуется, и каркас возвращает в этом случае набор отсортированных пар, полученных базовыми обработчиками. Hadoop MapReduce позволяет создавать задания как с базовыми обработчиками, так и со свёртками, написанными без использования Java: утилиты Hadoop streaming позволяют использовать в качестве базовых обработчиков и свёрток любой исполняемый файл, работающий со стандартным вводом-выводом операционной системы (например, утилиты командной оболочки UNIX), есть также SWIG-совместимый прикладной интерфейс программирования Hadoop pipes на C++. Также, в состав дистрибутивов Hadoop входят реализации различных конкретных базовых обработчиков и свёрток, наиболее типично используемых в распределённой обработке. 1.2.2 Введение в MapReduce Парадигма MapReduce была предложена Google в статье Джефри Дина и Санжая Чемавата «MapReduce: упрощенная обработка данных на больших кластерах» (Jeffrey Dean and Sanjay Ghemawat MapReduce: Simplied Data Processing on Large Clusters). Данная статья носит довольно поверхностный характер. Ее недосказанности компенсирует работа Ральфа Ламмеля из Исследовательского центра Microsoft в Редмонде «И снова модель программирования MapReduce компании Google» (Ralf Lammel Google’s MapReduce Programming Model – Revisited). Во введении Ламмель заявляет, что он проанализировал статью Дина и Чемавата, которую он неоднократно и с почтением называет судьбоносной, используя метод, который называется «обратной инженерией» (reverse engineering). То есть, он постарался раскрыть смысл того, что же в ней на самом деле представлено. Ламмель увязывает MapReduce с функциональным программированием, языками Лисп и Haskell, что естественным образом вводит читателя в контекст. MapReduce – это скорее инфраструктурное решение, способное эффективно использовать сегодня кластерные, а в будущем многоядерные архитектуры. Большинство современных параллельных компьютеров принадлежит к категории «много потоков команд, много потоков данных» (Multiple Program Multiple Data, MPMD). Каждый узел выполняет фрагмент общего задания, работая со своими собственными данными, а в дополнение существует сложная система обмена сообщениями, обеспечивающая согласование совместной работы. Такой вид параллелизма раньше называют параллелизмом на уровне 8 задач (task level parallelism), но иногда его еще называют функциональным параллелизмом или параллелизмом по управлению. Его реализация сводится к распределению заданий по узлам и обеспечению синхронности происходящих процессов. Альтернативный тип параллелизма называют параллелизмом данных (data parallelism), который попадает в категорию «один поток команд, много потоков данных» (Single Program Multiple Data, SPMD). Реализация SPMD предполагает, что сначала данные должны быть каким-то образом распределены между процессорами, обработаны, а затем собраны. Эту совокупность операций можно назвать map-reduce, как принято в функциональном программировании, хотя точнее было бы split-aggregate, то есть разбиение и сборка, но привилось первое. Возможны различные способы реализации SPMD. Реализация SPMD требует выделения ведущей части кода, ее называют Master или Manager (далее менеджер), и подчиненных ей частей Worker (далее исполнитель). Менеджер «раздает» задания исполнителям и потом их собирает. До появления MapReduce эта модель рассматривалась как малоперспективная из-за наличия «бутылочного горла» на тракте обмена между множеством исполнителей и одним менеджером. Создание MapReduce разрешило эту проблему и открыло возможность для обработки огромных массивов данных с использованием архитектуры SPMD. Допустим, что следует решить простейшую задачу: обработать массив, разбив его на подмассивы. В таком случае работа менеджера сводится к тому, что он делит этот массив на части, посылает каждому исполнителю положенный ему подмассив, а затем получает результаты и объединяет их (рисунок 1). В функцию исполнителя входит получение данных, обработка и возврат результатов менеджеру. Распределение нагрузок может быть статическим (static load balancing) или динамическим (dynamic load balancing). Парадигма создана по мотивам комбинации map и reduce в функциональном языке программирования Липс. В нем map использует в качестве входных параметров функцию и набор значений, применяя эту функцию по отношению к каждому из значений, а reduce комбинирует полученные результаты. Канонический пример приложения, написанного с помощью MapReduce это процесс, подсчитывающий, сколько раз различные слова встречаются в наборе документов: // Функция, используемая исполнителями на Map-фазе // для обработки пар ключ-значение из входного потока void map(String name, String document): // Входные данные: // name - название документа // document - содержимое документа for each word w in document: EmitIntermediate(w, "1"); 9 Данные D1 D2 Dn Map() Map() Map() Reduce() Reduce() O1 O2 Фаза Map Фаза Reduce Срезы данных Рисунок 1 — Упрощенная схема потоков данных в парадигме MapReduce // Функция, используемая исполнителями на Reduce-фазе // для обрабоки пар ключ-значение, полученных на Map-шаге void reduce(String word, Iterator partialCounts): // Входные данные: // word - слово // partialCounts - список группированных промежуточных результатов. // Количество записей в partialCounts и есть требуемое значение int result = 0; for each v in partialCounts: result += parseInt(v); Emit(AsString(result)); В этом коде на map-фазе каждый документ разбивается на слова, и возвращаются пары, где ключом является само слово, а значением — «1». Если в документе одно и то же слово встречается несколько раз, то в результате предварительной обработки этого документа будет столько же этих пар, сколько раз встретилось это слово. Далее выполняется объединение всех пар с одинаковым ключом, и они передаются на вход функции reduce, которой остается сложить их, чтобы получить общее количество вхождений данного слова во все документы. Созданная в Google конструкция MapReduce делает примерно то же, но по отношению к гигантским объемам данных. В этом случае map – это функция запроса от пользователя, помещенная в библиотеку MapReduce. Ее работа сводится к выбору входной пары, ее обработке и формированию результата в виде значения и некоторого промежуточного ключа, служащего указателем для reduce. Конструкция MapReduce собирает вместе все значения с одинаковыми промежуточными ключами и передает их в функцию reduce, также написанную пользователем. Эта функция воспринимает промежуточные значения, каким-то образом их собирает и воспроизводит результат, скорее всего выраженный меньшим количеством значений, чем входное множество. Теперь свяжем функциональную идею MapReduce со схемой SPMD. Вызовы map распределяются между множеством машин путем деления входного потока данных на М срезов (splits или shard), каждый срез 10 обрабатывается на отдельной машине. Вызовы reduce распределены на R частей, количество которых определяется пользователем. При вызове функции из библиотеки MapReduce выполняется примерно такая последовательность операций (рисунок 2): 1) входные файлы разбиваются на срезы размером от 16 до 64 Мбайт каждый, и на кластере запускаются копии программы. Одна из них менеджер, а остальные – исполнители. Всего создается M задач map и R задач reduce. Поиском свободных узлов и назначением на них задач занимается менеджер; 2) в процессе исполнения исполнители, назначенные на выполнение задачи map, считывают содержимое соответствующих срезов, осуществляют их грамматический разбор, выделяют отдельные пары «ключ и соответствующее ему значение», а потом передают эти пары в обрабатывающую их функцию map. Промежуточное значение в виде идентификатора и значения буферизуется в памяти; 3) периодически буферизованные пары сбрасываются на локальный диск, разделенный на R областей. Расположение этих пар передается менеджеру, который отвечает за дальнейшую передачу этих адресов исполнителям, выполняющим reduce; 4) исполнители, выполняющие задачу reduce, ждут сообщения от менеджера о местоположении промежуточных пар. По его получении они, используя процедуры удаленного вызова, считывают буферизованные данные с локальных дисков тех исполнителей, которые выполняют map. Загрузив все промежуточные данные, исполнитель сортирует их по промежуточным ключам и, если есть необходимость, группирует; Пользовательская программа Менеджер Исполнитель Исполнитель (4) локальная запись Исполнитель Исполнитель Исполнитель Срез 0 Срез 1 Срез 2 Срез 3 Срез 4 (5) удаленное чтение (3) чтение Выход 0 Выход 1 (6) запись (2) назначение reduce (2) назначение map (1) ветвление (1) ветвление (1) ветвление Входные файлы Фаза Map Промежуточные файлы локальных дисках Фаза Reduce Выходные файлы Рисунок 2 — Ход выполнения вызова MapReduce 11 5) исполнитель обрабатывает данные по промежуточным ключам и передает их в соответствующую функцию reduce для вывода результатов; 6) когда все задачи map и reduce завершаются, конструкция MapReduce возобновляет работу вызывающей программы и та продолжает выполнять пользовательский код. Одно из важнейших преимуществ этой, замысловатой на первый взгляд, конструкции состоит в том, что она позволяет надежно работать на платформах с низкими показателями надежности. Для обнаружения потенциальных сбоев менеджер периодически опрашивает исполнителей, и, если какой-то из них задерживается с ответом сверх заданного норматива, менеджер считает его дефектным и передает исполнение на свободные узлы. Различие между задачами map и reduce в данном случае состоит в том, что map хранит промежуточные результаты на своем диске, и выход из строя такого узла приводит к их потере и требует повторного запуска, а reduce хранит свои данные в глобальном хранилище. |