Bileti_po_AvIS / Avis_bilet_09

Билет №9

1. Проблемы организации конфигураций оборудования и мат. обеспечения модели FCAPS.

2. Дайте инструкцию по администрации вашей СУБД.

1.Проблемы организации конфигураций оборудования и мат. обеспечения модели FCAPS.

На 250(небольшая компания 25 пол-ей, до 800 - средняя) портов в сети должно быть 25 серверов, 9 коммутационных устройств и сетевые ноды (узлы). Каждое устройство имеет приблизительно 300 параметров, таким образом получается около 3000 параметров на сеть среднего масштаба. А еще около 300*25=7500 параметров серверов.

Каждый сервис должен выполняться своим процессом.

Конфигурация – концепция того, как быть уверенным в непротиворечивости, целостности, проверяемости и повторяемости параметров системы.

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

Проблемы конфигурации и связанные с этим задачи:

– проблема конфигурации при инициализации ресурсов (т.е. при установке какого-либо продукта). Инициализируется с помощью ОС должны задать начальные параметры и default записать, worksheet – какая версия BIOS, какой монитор, какие драйверы, сколько жесткий диск, контроллер диска – аппаратные параметры. Записать все параметры инсталлируемой системы, программные параметры ОС - размер памяти, размер буферов вв/вывода, размер буферного пула в ОП. Сервер имеет worksheet перечисление аппаратуры и перечисление софта установленного на нем. Принт-сервер – какие принтера локальные, какие удаленные (remote), какие очереди установлены;

– проблема обеспечения (provision/deprovision). Новые устройства должны легко включаться и удаляться вместе с их параметрами, т.е. это обеспечение работы с ресурсами;

– back-up и восстановление параметров админ должен создать инструкции – четкое руководство к действию, один из элементов регламентных работ;

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

– Обеспечить режим правильный закрытие ядра системы shut down (правильно сбрасывать ОС и прикладные продукты) - админ должен создать инструкцию, как правильно заканчивать работу прикладной системы для служб администратора. Выключение: закрытие прикладной системы -> СУБД -> ОС, когда выключены все сервера -> shut down ОС коммуникационные устройства и после этого выключает компьютеры. Включение: коммуникационное устройство -> сервера (ОС, СУБД)-> прикладные станции (рабочие);

– проблема изменения параметров;

– инвентаризация параметров;

– удалённая конфигурация – с помощью эмулирующих продуктов управления. Консоли сетевой аппаратуры, мейнфрейма, прикладной системы (в состав входит telnet, SSH, Hyperterminal). Удаленное управление нужно, когда только это нужно!!! Меньше ошибок возникает (2,3,4уровня). Применяется, когда измеряем статистику (ее можно делать как угодно);

– проблема автоматической дистрибуции soft-а (распространение на все станции (драйверы));

– автоматическое выполнение работ (jobs) по конфигурации и их отслеживание.

Переход от ручного к автоматическому режиму управления, надо сделать следующие шаги:

Нужно выполнять шаги:

1. Базовая конфигурация (Инсталляция оборудования и soft-а).

Нужно создать work-sheet-ы (на бумаге) и главную книгу, в которой будет вестись перепись оборудования и soft-а, при этом нужно указывать дату установки.

Некая текущая конфигурация, которую фиксируют на определенный момент (момент на определенную дату!). Эта базовая дата является стартовой точкой, после нее начинается обновление конфигурации.

2. Документирование конфигурации.

Должна содержать план и схему сети, связь устройств между собой.

Документирование введется виде БД, создается централизованная БД всех конфигураций, которые имеются. Такую БД ведет NMS собирает конфигурацию ото всех программных продуктов.

3. Контроль изменений.

Нужна такая управляющая система, которая по запросу будет осуществлять изменение параметров (т.е. она решает, нужно ли менять параметры, и фиксирует изменения – записывает их в MIB).

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

4. Аудит.

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

Должны быть в итоге получены функциональные схемы сети, работы и архитектуры прикладных продуктов.

Приёмы администратора конфигурирования:

1. Стандартизация.

Обычно все конфигурации устройств похожи:

– время часового пояса;

– системное время;

– название устройства

– имя host-а (хотя это то же, что и название устройства);

– нода spanning tree;

– имена VLAN-ов;

– версии soft-а.

Должен быть пример такой стандартной конфигурации для любого устройства как форма. Стандартизация имен пользователей сети – по функциям пользователя сети – это делает легкий аудит.

2. Отраслевой (корпоративный) стандарт на конфигурацию.

Любой update делается по правилам данной компании. Весь update должен быть множественным (если меняем конфигурацию на одном устройстве, то придется меня и на других). Если сделано на одном сервере, то нужно сделать на всех серверах.

3. Архив конфигураций (для восстановления).

Он делается или системой автоматически, или администратором по расписанию (делаем квартальные, годовые, месячные, недельные копии).

4. Инвентаризация системы.

Инвентаризация входит в регламентные работы администратора системы.

В регламентные работы по поддержке оборудования также входит: пылесосить, обрабатывать антистатиком, проводить работы по предупреждению ошибок – тесты систем ввода/вывода, устройств передачи данных и т.д., работы по поддержке электротехнической системы (измерение контуров заземления).

В регламентные работы по поддержке soft-а входит: копирование конфигураций, перезапуск сервера (для дефрагментации памяти), тестирование СУБД на целостность.

Регламентные работы по инвентаризации системы:

– карты расположения устройств;

– функциональная схема сети;

– аудит всех протоколов.

5. Аудит по поводу защиты от НСД.

Нужно следить за подключением разрешённых портов, устройств, РС, а также за тем, что делает данное устройство.

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

6. Анализ метрик.

Есть три метрики MTTR (минимальное время на восстановление), Uptime (суммарное время, за которое устраняется проблема), MTBF (время между перерывами в работе оборудования).

Нужно так конфигурировать систему, чтобы можно было восстанавливать параметры и смотреть, как это влияет на MTTR. При этом все параметры должны быть документированы. Это метрика бизнеса. Это не простая задача.

7. Использование специальных управляющих продуктов.

Для конфигурации системы можно использовать программные продукты:

– Telnet;

– HyperTerminal;

– SSH.

Есть также специальные продукты оборудования, которые работают на первом уровне, т.е. через консольный порт (RS-232), поэтому исключаются все ошибки верхних уровней, но при этом нельзя управлять удаленно. Если работаешь удаленно, предпочтительнее не менять параметры, а только наблюдать за ними.

Безопасность связана с параметрами НСД и тесно связана с конфигурацией и заключается в ААА (но для конфигурации не ААА). Вопросы защиты безопасности определяется видом деятельности организации. PCI обслуживание платежных карт - DSS конфигурация безопасности.

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

Создание профайла конфигурации, параметры влияющие на НСД.

Он заключается в следующем:

- установлены и заданы параметры Firewall для защиты устройства принимающих карт;

- не задают default по ролям и параметрам сети;

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

- запускание антивирусного софта;

- ограничения доступа к любому устройству принимающ. PCI для того бизнеса, которому это требуется.

- уникальный номер, имеющий доступ к системе.

- введение процедуры для адресации информации НСД.

- внедрение процедуры мониторинга доступа к ресурсу - NMS

- параметры аппаратные по защите доступа к нему.

Конфигурация определяется бизнесом и для какой организации они строится и определяется видом безопасности. Аудит - любой ручной процесс приводит к ошибкам, обязательно аудит параметров должен проверяться. Не соблюдение стандартов, а пользователь, который уволен.

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

Технологии, которые применяются:

1. создание и запуск продуктов работают по расписанию (back up сервера).

1. защита всех параметров от НСД при помощи сетевых средств (задание параметров и средств сетевой аппаратуры – коммуникационной аппаратуры).

Практические рекомендации администратору системы:

- политика задание паролей – (для пользователей, генерирует система), пароль админа надо задавать руками (механическая память сильнее, не генерировать по правилам)

- политика подключения мобильных устройств

- политика подключения доступа к системе (допуск к внутренней и внешней системе разный). Доступ к общей сети и закрыт к внешней сети. Нет кабельной системы.

- политика антивирусов, антиспамов.

- политика кодирования.

Следует узнать хорошо или плохо сделана сеть – это метрика производительности!!!

- какой получился трафик?

- достигнута ли цель?

- этот ли трафик на авторизованных устройствах, на авторизованных томах?

- трафик идет без изменений?

- Сколько занимает процесс утилизации

- сканирование портов сетевого оборудования (занимает много времени, но это обязательно!)

- предварительный поиск хакера (процедуры тестирования) нет ли в системе лишних пользователей, нет ли изменения параметров вхождения в систему?

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

- убеждаться, чтобы пользователи не поменяли параметры.

2. Дайте инструкцию по администрации вашей СУБД.

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

1. Оценка и выбор СУБД;

2. Стратегия изменения концептуальной (представление админом системы), логической (прикладного программиста представление) и физической модели (системного программиста)) – реорганизация, т.е изменение связи между объектами, объема и т.д.

3. Вопросы целостности:

- сохранение физической целостности - соответствие ссылок методам доступа к самим данным.

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

4. утилиты тестирование БД (соответствие ссылок), проверка целостности.

5. Мониторинг осуществляется либо с помощью утилит СУБД (они находятся вне ядра СУБД), либо в виде набора API (Application Program Interface).

6. Статистика сбора данных

Цель сбора статистики: настроить производительность и выявить нужные параметры, выяснить активность пользователей, выяснить затраты по каждому из запросов и операций.

- open на базу (статистика открытий 1 раз во время работы);

– количество и время операций ввода/вывода;

– close на базу (статистика закрытий 1 раз во время работы);

– установка соединения;

– deadlock (взаимные блокировки);

– начало и конец транзакций;

– статистика по кодам возврата;

1. Статистика на запрос (с помощью total time, system time, process time)

Критерии:

– стоимость процессора (сколько команд тратиться на запрос);

– стоимость ввода/вывода (сколько команд ввода/вывода тратится на запрос);

– сколько предикатов используется;

– какова избирательность (вероятность того, что каждая найденная строка удовлетворяет предикату; должна быть до 10%);

– число занятых страниц (в пуле буферов).

2. Статистика по отношениям (по индексам)

Т.е. какой объем памяти занят под индексы, области переполнения, отношения, системную область и т.д.

7. Восстановление БД - защита от потерь методами созданий резервных копий и восстановление данных по ним.

3 способа восстановления:

1. Утилита в СУБД для восстановления – журнал транзакций. Администратор должен своевременно архивировать БД и журналы транзакций, копии должны совпадать с финансовой отчетностью, т.е годовые, квартальные, месячные.

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

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

Еще важно то, что восстановление и копирование СУБД и БД нужна целостность данных, а в ОС – не нужна.

3. Аварийное восстановление:

- среды (копии и журналы транзакций);

- сбой ядра ОС, СУБД, питания.

При сбое ядра необходимо делать перезагрузку – это автооткат ОС. В ОС откат транзакций физический, а не логический. Откат ОС транзакций не есть отказ СУБД.

Применительно СУБД МySQL используются утилиты:

GUI Tools содержит:

• MySQL Administrator - админинистративный интерфейс MySQL. Способный анализировать логи, отображать нагрузку на сервер, создавать back up и восстанавливать по нему.

• MySQL Query Browser - утилита для создания, выполнения и оптимизации SQL запросов MySQL

• MySQL Migration Toolkit - набор утилит для миграции с других СУБД MySQL

MySQL Workbench - визуальная БД можно использовать, как для дизайнерских целей, управление и документирование схем.