Техническая эксплуатация и администрирование информационных сетей

Размещено на http://www.allbest.ru/

Министерство образования и науки Украины

Одесская национальная академия связи им. А.С. Попова

Кафедра сетей связи

Контрольная работа

Техническая эксплуатация и администрирование информационных сетей

Одесса 2015



1. Amanda

AMANDA -- название системы, которая позволяет организовать процедуру резервного копирования на одном сервере для множества компьютеров в сети. Система имеет архитектуру клиент-сервер. Клиент -- это машина, которая нуждается в резервном копировании; сервер -- это машина, где находятся внешние системы памяти для хранения резервных копий. В сети может быть большое число клиентов и много серверов. Эта система вполне может использоваться в качестве инструмента для резервного копирования масштаба предприятия. На сервере AMANDA могут использоваться различные внешние устройства:

· магнитофоны;

· жёсткие диски;

· оптические диски;

· облачная память

Перечислим основные технические особенности этой системы:

· AMANDA -- это акроним от Advanced Maryland Automatic Network Disk Archiver (продвинутый автоматический сетевой дисковый архиватор из университета Мериленда);

· Написана на C и Perl.

· Система работает на всех операционных платформах Linux/Unix, а также Windows/XP/Vista/7. Копирование с платформы Windows осуществляется с использованием средств SAMBA.

· Является свободно распространяемым продуктом (исходные тексты и готовые к исполнению программы) в соответствии с лицензией университета в Мериленде и GPL.

· Разработана с использованием стандартных средств архивирования (dump/restore, GNU tar и др.); описаны возможности расширения, чтобы использовать новые (дополнительные) средства архивирования;

программный администрирование аmanda bacula

· Имеет открытый стандартный формат резервной копии на внешнем носителе (на ленте), таким образом при необходимости можно использовать команды mt, GNU tar для восстановления файлов с резервной копии;

· Имеется возможность создания резервной копии и восстановления 32 и 64 битных машин под Windows;

· Запоминает в специальном каталоге все файлы, для которых были созданы резервные копии;

· Проверяет магнитную ленту, кода планируется выводить резервную копию; если лента не предназначена для резервного копирования, то система не будет её использовать;

· При восстановлении сообщает оператору, какую ленту следует установить и найдёт верную версию резервной копии на ленте;

· Может быть легко сконфигурирована для использования практически любой ленточной системы (простой магнитофон, ленточная библиотека, ленточный робот и т.п.);

· Посредством набора API можно использовать как ленточные устройства, включая RAIT (Redundant Arrays of Inexpensive Tape -- избыточный массив недорогих магнитофонов), так и виртуальные ленты и диски, DVD-RW, а также облачную память типа AMAZON S3;

· Поддерживает аутентификацию в сети с использованием OpenSSH;

· Поддерживает шифрование резервной копии с использованием GPG или других средств шифрования;

· По запросу может выполнить уплотнение информации, для которой создаётся резервная копия, посредством gzip или другой программы;

· Поддерживает протокол Kerberos 5, включая зашифрованную передачу данных по сети;

· Детально сообщает о всех выполненных операциях и возникших ошибках по электронной почте;

· Динамически подгоняет расписание резервного копирования с различных клиентских машин, чтобы минимизировать ручное изменение конфигурации при изменении числа машин или дисков на клиентской машине;

· Поддерживает IPv6;

· Если размер резервной копии больше ёмкости одной ленты (тома), то резервная копия распределяется по нескольким лентам; при восстановлении оператор (человек) будет информирован, в какой последовательности потребуются магнитные ленты;

· Набор API позволяет сконфигурировать резервное копирование для специализированных приложений, например, СУБД;

· Можно добавить скрипты, которые будут выполнены до выполнения резервной копии и/или после выполнения резервной копии, например, для проверки согласованности значений в базе данных.

Первые варианты AMANDA начали работать в 1991 году. С тех пор AMANDA активно развивалась (развивается по настоящее время -- 2010) и использовалась во множестве организаций (на сайте sourceforge.net в феврале 2010 года показано более 200 тысяч скачиваний этой системы).

2. Bacula

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

В настоящее время поддерживаются клиентские части для удалённого резервного копирования для Linux (включая zSeries), NetBSD, FreeBSD, OpenBSD, Solaris, HP-UX, Tru64, IRIX, Microsoft Windows, Mac OS X.

Bacula также может выполняться полностью на единственном компьютере или, распределённо, на нескольких, и может записывать резервные копии на различные типы носителей, включая ленты, ленточные библиотеки (autochangers/libraries) и диски.

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

Если Вы используете программу типа tar или dump, чтобы делать резервные копии ваших данных и хотите более гибкое сетевое решение и службу каталога (учёт, поиск и т. п.), то скорее всего Bacula обеспечит вам дополнительные возможности.

Структура

Здесь и далее английские термины даны в соответствии с оригинальной документацией.

Director (DIR) -- осуществляет централизованный контроль и администрирование всего комплекса задач. Планирование и управление заданиями на резервное копирование (Job). Обслуживание Каталога (Catalog) -- центральной БД для хранения метаданных.

File Daemon (FD) -- сервис, выполняющий непосредственное копирование, восстановление и проверку данных по запросу Director. File Daemon должен быть установлен на каждой клиентской машине. File Daemon обменивается информацией с Director и Storage Daemon.

Storage Daemon (SD) -- читает и пишет данные на физический носитель: диск, ленту, DVD, USB.

Console -- управляющая консоль оператора или администратора. Поддерживаются ACL для разных пользователей консоли. Типы консолей: TTY, wxWidgets (GUI) для Linux, Unix, Win32, GNOME (GUI), несколько веб-интерфейсов, Qt4.

Catalog database -- база данных SQL : MySQL, PostgreSQL, или SQLite для хранения метаданных.

Tray Monitor -- апплет GNOME/KDE/Win32 GUI для показа активности Director, File daemons, Storage daemon в реальном времени.

Все указанные компоненты могут находиться как на одном компьютере, так и на нескольких, объединённых в сеть.

Защита информации

· Все сервисы авторизуются с использованием CRAM-MD5.

· Сервисы Director и Storage могут быть запущены от имени обычного пользователя.

· MD5, SHA1 сигнатуры для каждого файла в архиве.

· Контрольная CRC сумма для каждого блока, записанного на Том (Volume).

· Использование ACL для управляющей консоли.

· Шифрование обмена с помощью TLS.

· Шифрование данных с помощью PKI.

· Проверка данных, похожая на систему обнаружения атак Tripwire.

Технические детали

· Поддержка операционных систем: Linux (все версии, включая zSeries), Win32, Solaris, *BSD, Mac OS X, Irix, Tru64, AIX, HP-UX.

· Поддержка Юникода (UTF-16 для Win32 и UTF-8 для UNIX, Linux; имена файлов везде хранятся в UTF-8).

· Резервное копирование с использованием системы спулинга.

· Резервное копирование и восстановление POSIX Access Control Lists (ACL), атрибутов доступа Win32, Mac.

· Поддержка больших файлов >2 ГБ.

· Поддержка 64-битной архитектуры.

· Многопоточная реализация.

· Язык программирования C, C++.

Текущая задача имеет следующие отличительные особенности:

· Небольшое количество альтернатив;

· Задача слабо структурирована, то есть критерии оценки носят в основном не количественный, а качественный характер;

· Критерии альтернатив представляют собой иерархическую структуру, то есть характеристики качества детализируются более конкретными вложенными характеристиками.

Все это указывает на целесообразность использования метода анализа иерархий.

Метод Анализа Иерархий (МАИ, АНР) -- математический инструмент системного подхода к сложным проблемам принятия решений. МАИ не предписывает лицу, принимающему решение (ЛПР), какого-либо «правильного» решения, а позволяет ему в интерактивном режиме найти такой вариант (альтернативу), который наилучшим образом согласуется с его пониманием сути проблемы и требованиями к ее решению. Этот метод разработан американским математиком Томасом Саати, который написал о нем книги, разработал программные продукты и в течение 20 лет проводит симпозиумы ISAHP (англ. International Symposium on Analytic Hierarchy Process). МАИ широко используется на практике и активно развивается учеными всего мира. В его основе наряду с математикой заложены и психологические аспекты. МАИ позволяет понятным и рациональным образом структурировать сложную проблему принятия решений в виде иерархии, сравнить и выполнить количественную оценку альтернативных вариантов решения. Метод Анализа Иерархий используется во всем мире для принятия решений в разнообразных ситуациях: от управления на межгосударственном уровне до решения отраслевых и частных проблем в бизнесе, промышленности, здравоохранении и образовании.

Применяя метод АНР, нужно выполнить следующее:

· Первый шаг заключается в структуризации задачи в виде иерархической структуры с несколькими уровнями: цели-критерии-альтернативы.

· На втором этапе осуществляются попарные сравнения элементов каждого уровня. Результаты сравнений переводятся в числа.

· На третьем шаге вычисляются коэффициенты важности для элементов каждого уровня. При этом проверяется согласованность суждений АНР.

· На четвертом шаге подсчитывается количественный индикатор качества каждой из альтернатив и определяется лучшая альтернатива.

По результатам выполнения последнего шага получаем обоснованный выбор лучшего экземпляра программного обеспечения.

Модель качества, установленная в первой части стандарта ISO 9126-1, классифицирует качество ПО в 6-ти структурных наборах характеристик, которые в свою очередь детализированы субхарактеристиками, такими как:

§ Функциональность -- Набор атрибутов характеризующий, соответствие функциональных возможностей ПО набору требуемой пользователем функциональности. Детализируется следующими субхарактеристиками:

§ Пригодностью для применения

§ Корректностью (правильностью, точностью)

§ Способностью к взаимодействию (в частности сетевому)

§ Защищенностью

§ Надёжность -- Набор атрибутов, относящихся к способности ПО сохранять свой уровень качества функционирования в установленных условиях за определенный период времени. Детализируется следующими субхарактеристиками:

§ Уровнем завершенности (отсутствия ошибок)

§ Устойчивостью к дефектам

§ Восстанавливаемостью

§ Доступностью

§ Готовностью

§ Практичность (применимость) -- Набор атрибутов, относящихся к объему работ, требуемых для исполнения и индивидуальной оценки такого исполнения определенным или предполагаемым кругом пользователей. Детализируется следующими субхарактеристиками:

§ Понятностью

§ Простотой использования

§ Изучаемостью

§ Привлекательностью

§ Эффективность -- Набор атрибутов, относящихся к соотношению между уровнем качества функционирования ПО и объемом используемых ресурсов при установленных условиях. Детализируется следующими субхарактеристиками:

§ Временной эффективностью

§ Используемостью ресурсов

§ Сопровождаемость -- Набор атрибутов, относящихся к объему работ, требуемых для проведения конкретных изменений (модификаций). Детализируется следующими субхарактеристиками:

§ Удобством для анализа;

§ Изменяемостью

§ Стабильностью

§ Тестируемостью

§ Мобильность -- Набор атрибутов, относящихся к способности ПО быть перенесенным из одного окружения в другое. Детализируется следующими субхарактеристиками:

§ Адаптируемостью

§ Простотой установки (инсталляции)

§ Сосуществованием (соответствием)

§ Замещаемостью

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

· Пригодность для применения - критерий описывающий насколько именно данное ПО удовлетворяет поставленным задачам.

· Поддержка RAW-разделов - этот критерий является необходимым, так как при частичных разрушениях файловых систем типа NTFS и FAT32, драйвер системы определяет частично разрушенный раздел как RAW. С такого раздела все ещё можно восстановить часть информации, а в случае резервного копирования это позволяет сделать слепок поврежденного раздела до того, как отформатировать его заново, а сам раздел использовать с новой файловой системой для текущих целей.

· Поддержка больших файлов и файловых систем - данный критерий необходимо учитывать, так как различное ПО может и не поддерживать специфичные файловые системы (например ZFS) как и иметь ограничение на максимальный размер резервируемого файла.

· Поддержка сохранения атрибутов файлов - немаловажный критерий, так как необходим для сохранения разграниченности доступа к тем или иным файлам.

· Возможность управления хранилищем - этот критерий необходимо учитывать, так как некоторое ПО для резервирования данных имеет довольно простую структуру и не предусматривает какого-либо выделенного хранилища резервных копий. В этом критерии кроме, собственно, наличия управления хранилищем, будет учитываться удобство доступа и управления резервными копиями.

· Уровень завершенности - это критерий, оценивающий полноту реализованных функций в ПО. Например: при создании резервной копии файла, программа не осуществляет сжатие.

· Готовность - критерий, показывающий способно ли ПО выполнять требуемые функции сразу, или необходима какая-либо предварительная подготовка.

· Временная эффективность - критерий, учитывающий насколько рационально программа использует процессорное время и насколько быстро программа способна выполнять требуемые функции.

· Использование ресурсов - критерий оценки требуемых для обеспечения выполнения заданных операций ресурсов системы. Подразумевает рациональность использования места на накопителе, необходимый для обработки данных объем оперативной памяти и иных ресурсов.

· Сжатие на стороне клиента - необходимый и важный критерий, подразумевающий возможность сжатия резервируемых данных не на сервере, а ресурсами клиента. Это снижает нагрузку на сеть (если используется резервирование по сети) и освобождает ресурсы сервера.

· Стандартный или уникальный формат хранения - критерий предусматривающий способность ПО использовать стандартный формат хранения, который может быть использован иным программным продуктом или иной версией данного продукта.

Имея множество критериев оценки, нужно делать выбор не по каждому критерию отдельно, а используя некоторую интегральную оценку, полученную аналитическим путем. Осуществим попарные сравнения элементов каждого уровня. Результаты сравнений переведем в числа.

Табл.1 Численные характеристики качества

Уровень	Равные	Умеренное преимущество	Существенное преимущество	Значительное преимущество	Очень большое преимущество
Оценка	1	2	5	7	9

Так же для расчётов необходимо использовать величины случайной согласованности матрицы для разных порядков:



Табл.2 Величины случайной согласованности матрицы для разных порядков

m	1	2	3	4	5	6	7	8	9
Ir	0	0	0,58	0,9	1,12	1,24	1,32	1,41	1,45

Приведем попарное сравнение всех критериев между собой. Пример попарного сравнения:

· Так как функциональность ненамного важнее надежности, ставим оценку 2.

· По отношению к практичности и эффективности, функциональность важна. Ставим оценку 5.

· Функциональность является гораздо более важным критерием, чем сопровождаемость и мобильность, потому ставим оценку 9 в обоих случаях.

· Критерий стоимости для себя посчитаем важным и даже равноценным по отношению к функциональности. Оценка 1.

То же самое проделаем для остальных критериев и приведем в таблице

Табл. 3 Попарные сравнения критериев оценивания ПО

	Функц.	Надежность	Практич.	Эффект.	Сопровожд.	Мобильн.	Стоим.
Функциональность	1	2	5	5	9	9	1
Надежность	0,5	1	5	2	5	7	1
Практичность	0,2	0,2	1	2	5	2	0,2
Эффективность	0,2	0,5	0,5	1	7	1	0,2
Сопровождаемость	0,111	0,2	0,2	0,142	1	1	0,142
Мобильность	0,111111	0,142	0,5	1	1	1	0,111111
Стоимость	1	1	5	5	7	9	1

После произведенного попарного сравнения необходимо вычислить такие величины как:

· Вектор приоритетов;

· Какой объем критерий занимает от общего числа оценки (нормализация);

· Проверка верности предыдущего расчета путем суммирования;

· Индекс согласованности, который дает информацию о степени нарушения согласованности. Вместе с матрицей парных сравнений мы имеем меру оценки степени отклонения от согласованности. Если такие отклонения превышают установленные пределы, то тому, кто проводит суждения, следует перепроверить их в матрице.

· Общую оценку согласованности, значение которой не должно превышать 0,1.

Вектор приоритетов вычисляется по формуле:

(1)

Если подставить значения из таблицы 3, получим следующий результат:

Подобным образом рассчитаем вектор приоритетов для остальных критериев и приведем в таблице 4.

Произведем нормализацию значений по формуле:

(2)

Подставим значения полученные благодаря предыдущему расчету:



Аналогично произведем расчеты для остальных критериев и занесем данные в таблицу 4.

Рассчитаем параметр Р - отношение частичной доли критерия от суммы всех критериев к обратному отношению критерия эффективности к другим критериям.

, (3)

где - обратная оценка отношения

Согласно предыдущим расчетам:

Аналогично произведем расчеты для остальных критериев и занесем данные в таблицу 4.

Рассчитаем индекс согласованности с помощью формулы:

(4)

где - сумма произведений всех обратных оценок и рассчитывается следующим образом:

(5)

Рассчитаем согласно таблице 4.

Подставим полученное значение в формулу 4 и получим:

Сделаем общую оценку согласованности:

(6)

где - поправочный коэффициент, взятый из таблицы 2 для матрицы из таблицы 3.

Рассчитай общую оценку согласованности для матрицы размером m=7:

Все полученные значения заносим в таблицу

Таблица 4 Расчетные значения коэффициента согласованности и необходимых для его вычисления величин при оценке общих критериев

	Функц.	Надежность	Практич.	Эффект.	Сопровожд.	Мобильн.	Стоим.	V	q	P
Функциональность	1	2	5	5	9	9	1	2,824437	0,297916	0,930127
Надежность	0,5	1	5	2	5	7	1	1,907128	0,20116	1,014249
Практичность	0,2	0,2	1	2	5	2	0,2	0,795271	0,083884	1,442798
Эффективность	0,2	0,5	0,5	1	7	1	0,2	0,717195	0,075648	1,221116
Сопровождаемость	0,111	0,2	0,2	0,142	1	1	0,142	0,311885	0,032897	1,151397
Мобильность	0,111111	0,142	0,5	1	1	1	0,111111	0,414808	0,043753	1,312593
Стоимость	1	1	5	5	7	9	1	2,509921	0,264742	0,967131
?	3,122111	5,042	17,2	16,142	35	30	3,653111	9,480644	1	8,039411
R=	0,131239	I=	0,173235

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

Таблица 5 Расчет субкритериев функциональности

Таблица 6 Расчет субкритериев надежности



Таблица 7 Расчет субкритериев практичности

Таблица 8 Расчет субкритериев эффективности

Таблица 9 Расчет субкритериев сопровождаемости

Таблица 10 Расчет субкритериев мобильности

Следующим шагом является расчет количественного индикатора качества каждой альтернативы.

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

Таблица 11 Расчет количественных показателей оценок субкритериев функциональности

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

Для примера рассчитаем интегральную оценку по субкритериям функциональности используя данные из таблиц 5 и 11

Приведем остальные количественных показателей оценок субкритериев

Таблица 12 Расчет количественных показателей оценок субкритериев надежности

Таблица 13 Расчет количественных показателей оценок субкритериев практичности



Таблица 14 Расчет количественных показателей оценок субкритериев эффективности

Таблица 15 Расчет количественных показателей оценок субкритериев сопровождаемости



Таблица 16 Расчет количественных показателей оценок субкритериев мобильности

Таблица 17 Расчет количественных показателей оценок основных критериев

Составим таблицу всех интегральных оценок субкритериев в результате вычисления по формуле 7:



Таблица 18 Интегральные оценки субкритериев

Параметр	Функц.	Надеж.	Практич.	Еффективн.	Сопровожд	Мобильн	Стоим.
Amanda	0,29577	0,24	0,45	0,41	0,40	0,84	0,85
Bacula	0,70423	0,76	0,55	0,59	0,60	0,16	0,14

Последним шагом является вычисление суммарной интегральной оценки используя все вышеперечисленные данные:

(8)

Где - интегральные оценки субкритериев из таблицы 18,

- процентная составляющая суммарных критериев.



Вывод

В данном комплексном задании нашей целью было определить лучшее ПО из предложенных альтернатив. Для достижения этой цели были выбраны необходимые критерии (используя рекомендации RFC и ISO), обосновано использование дополнительных критериев, проведена оценка этих критериев благодаря методу оценки иерархий, оценка критериев и субкритериев для каждой альтернативы и итогом проделанной работы является интегральная оценка следующей величины: для системы резервирования Amanda - 0.47, а для Bacula - 0.52.

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



Список литературы

1. hostobzor.ru/manual/mai.php

2. http://www.cyberforum.ru/ms-excel/thread64203.html

3. http://www.linux-ink.ru/static/Docs/Tutorials/BackupIntro/backupintro/ch02s02.html

4. http://www.tux.in.ua/articles/78

5. https://ru.wikipedia.org/wiki/Bacula

6. Конспект практических занятий по дисциплине «ТЕАИМ» 2015

Размещено на Allbest.ru

...