Контрольные вопросы по курсу МИС. Контрольные вопросы по курсу 1-83. Контрольные вопросы по курсу
 Скачать 1.8 Mb.
|
|
I/O (Input/output — ввод/вы- вод) — передача данных и сигналов управления между процессором и периферийным устройством. Термин I/O-подсистема применяется обычно для определения дисковой подсисте- мы ввода/вывода. (стр.129) Современная дисковая подсистема ввода-вывода состоит из адаптеров на материнской плате HBA (Host Bus Adapter), шины (интерфейс), дискового контроллера и непосредственно жест- ких дисков (рис 5.1) [54]. Совокупность этих устройств назы- вают каналом ввода-вывода. ОС может одновременно поддер- живать несколько каналов ввода-вывода, и эта опция может быть различной для разных версий ОС. (стр 130) обычно операционная система может поддерживать более одного канала ввода-вывода, АС должен изучить осо- бенности работы конкретной ОС. С увеличением числа ка- налов ввода-вывода обычно резко растет производительность системы. Перечислите основные интерфейсы дисковых подсистем. (стр. 129) 5.2 Подсистема ввода-вывода (дисковая подсистема). IDE, SCSI, SATA. (уч. Пособие стр. 11) 1.2 Основные протоколы подключения СХД 1.2.1 Протокол АТА ATA (англ. Advanced Technology Attachment) или IDE (англ. Integrated Drive Electronics) — параллельный интерфейс подключения накопителей (гибких дисков, жёстких дисков и оптических дисководов) к компьютеру. В 1990-е годы был стандартом на платформе IBM PC; в настоящее время вытеснен своим последователем — SATA — и с его появлением получил название PATA (Parallel ATA). В настоящее время ATA/IDE выходит из употребления. 1.2.2 Протокол SATA SATA (англ. Serial ATA) — последовательный интерфейс обмена данными с накопителями информации. SATA является развитием параллельного интерфейса ATA (IDE), который после появления SATA был переименован в PATA (Parallel ATA). 1.2.3 Протокол SCSI Протокол SCSI (Small Computer System Interface), произносится как «скáзи», разработанный в середине 1980-х годов для подключения внешних устройств к мини-компьютерам. Его версия SCSI-3 является основой для всех протоколов связи систем хранения данных и использует общую систему команд SCSI. • Преимущества SCSI: независимость от используемого сервера, возможность параллельной работы нескольких устройств, высокая скорость передачи данных. • Недостатки SCSI: ограниченность числа подключённых устройств, дальность соединения сильно ограничена. 1.2.4 Протокол iSCSI Протокол iSCSI (Internet Small Computer System Interface), стандартный протокол для передачи блоков данных поверх широко известного протокола TCP/IP, т.е. «SCSI over IP». iSCSI может рассматриваться как высокоскоростное недорогое решение для систем хранения, подключаемых удалённо, через Интернет. iSCSI инкапсулирует команды SCSI в пакеты TCP/IP для передачи их по IP-сети. 1.2.5 Протокол FC Протокол FC (Fiber/Fibre Channel), внутренний протокол между сервером, контроллером и СХД. Это широко используемый протокол последовательной связи, работающий на скоростях 4 или 8 Гигабит в секунду (Gbps). Как видно из его названия, его средой переноса данных является оптоволокно (fiber), однако, в некоторых случаях, он может работать и по медному кабелю. 1.2.6 Протокол SAS Протокол SAS (Serial Attached SCSI). SAS использует последовательную передачу данных и совместим с жёсткими дисками SATA (Serial Advanced Technology Attachment). SAS может передавать данные со скоростью несколько Гбит/с и поддерживает режим полного дуплекса, т.е. может передавать данные в обе стороны с одинаковой скоростью. Каковы этапы подготовки дисковой подсистемы для установки ОС? (стр. 135) Раздел 5.3. Подготовка дисковой подсистемы содержит три этапа: форматирование низкого уровня, организация разделов (партиций), (диски С:/, D:/ и пр.) форматирование высокого уровня. Разбиение на тома (стр. 137). https://bstudy.net/835937/tehnika/podgotovka_diskovoy_podsistemy_tehnologiya_raid Каковы задачи администрирования данных и администрирования БД? (Стр. 151) Задачи администрирования данных: предварительная оценка возможности — реализации про- ектов и процессов обработки данных; — определение требований организации к используемым данным; — определение стандартов сбора данных и выбор форматов их представления; — оценка объема данных и вероятности их роста; — определение способов и интенсивности использования данных; — определение правил доступа к данным и мер безопасности, отвечающих внутренним нормам и правилам организации; — взаимодействие с администратором базы данных и разработчиками приложений по созданию концептуальной схемы базы данных; — обучение пользователей существующим стандартам обработки данных и юридической ответственности за некорректное их применение; — обеспечение ведения требуемой документации по стандартам, ограничениям, процедурам и использованию словаря данных; — взаимодействие с администратором базы данных по поддержке словаря данных. Задачи администрирования базы данных: — выбор СУБД с учетом требований и возможностей операционной системы; — концептуальное проектирование базы данных совместно с разработчиками приложений и администратором данных; — логическое и физическое проектирование базы данных; — определение и реализация (совместно с прикладными программистами) требований и мер по защите логической и физической целостности данных; — тестирование базы данных с помощью соответствующих утилит и разработка дополнительных средств тестирования целостности данных; — обучение прикладных программистов; — прием в опытную и промышленную эксплуатацию готового приложения; — параметризация системы при установке СУБД; — контроль производительности и соответствующая настройка параметров CУБД; — создание расписания копирования и регулярное архивирование базы данных по выбранным стратегиям; — разработка процедур восстановления и (при необходимости) их реализация; — поддержка актуальности используемого программного обеспечения, включая заказ и установку совместно с системным администратором необходимых аппаратных и программных средств и пакетов обновлений; — поиск, диагностика и устранение ошибок CУБД, операционной системы и прикладных программ совместно с системным администратором и прикладными программистами. Каковы действия по инсталляции СУБД? (стр. 152) Понятие инсталляции СУБД подразумевает следующие действия [23, 49]: — установка на жесткий диск сервера БД программного обеспечения СУБД; — загрузка отдельных компонент СУБД на различные сер- вера БД; — задание параметров размещения будущей базы данных и выделение под ее множества (отношения реляционной СУБД) дискового пространства; — выбор методов доступа к данным; — задание параметров работы ядра СУБД; — задание работы отдельных приложений. Зачем АБД задает параметры запуска ядра СУБД? Для реализации этих операций СУБД обычно предоставляет спе- циальный инструментарий для администратора базы данных. Например, в СУБД DB2 существуют специальные продукты — ассистент конфигурирования и центр управления для реали- зации части этих операций [63]. От того, как АБД выполнит эти операции и, прежде всего, реализует архитектуру работы СУБД с учетом сетевой архитектуры и задаст параметры рабо- ты ядра СУБД, существенно зависит работа ИС [17]. (стр. 153) 6.2.2. Основные параметры запуска ядра СУБД. - Для того, чтобы правильно сконфигурировать работу СУБД и задать режимы ведения журналов. Зачем нужен мониторинг СУБД администратору системы? (Стр. 158) Мониторинг СУБД и баз данных проводится для поддержа- ния работоспособности и производительности СУБД, а также с целью отслеживания аварийных ситуаций и сбора статистики. Реализуется мониторинг с помощью отдельных утилит СУБД, представляющих собой программные продукты, входя- щие в состав СУБД, но загружаемые отдельно от ядра СУБД, либо в виде набора прикладных интерфейсов — API (Application Program Interface). Эту утилиту или группу утилит и в операционной системе, и в СУБД часто называют монитором или системным монитором. Для осуществления мониторинга ядро СУБД собирает ин- формацию от приложений, работающих с базой данных, и от си- стемных средств самой СУБД. Эта информация может использо- ваться администратором баз данных для следующих целей: — обеспечение необходимого объема аппаратных ресурсов (на основе информации об их использовании); — приложений или SQL-запросов; — отслеживание интенсивности использования отноше- ний; — оценка эффективности используемых методов доступа; — настройка параметров ядра СУБД в целях повышения производительности; — оценка последствий вносимых оптимизационных изме- нений. Какую статистику необходимо собирать АБД по БД в целом? По запросам приложений? По отдельным отношения БД? (Стр. 160) Раздел 6.3.2 Сбор статистики. Цель сбора статистики — настроить производительность и параметры, выяснить активность пользователей и затраты по каждому из запросов и операций. Cбор статистики может начинаться вместе с запуском ядра СУБД или с началом сессии данного приложения. Необходи- мо с помощью утилит мониторинга собирать статистику по БД в целом, а именно: (В целом): — статистику открытий БД (open на базу, как говорят про- граммисты); — число операций ввода-вывода и время; — статистику закрытий БД (close на базу); — число установленных соединений в течение работы се- анса ядра СУБД; — число взаимолокировок при локировании записей БД (deadlock); — число транзакций в единицу времени; — статистику по кодам возврата от операций с БД. (По запросам приложений) Необходимо также собирать статистику по отдельным за- просам приложений, работающих с СУБД, таким как: — стоимость процессора (сколько команд процессора, тра- тится на запрос); — стоимость ввода-вывода (сколько команд ввода-вывода тратится на запрос); — число предикатов, используемых в запросе; — избирательность, т. е. вероятность того, что каждая най- денная строка удовлетворяет предикату; обычно избира- тельность должна составлять около 10 %); — число занятых при запросе страниц в буферном пуле СУБД. (По отдельным отношениям БД) Еще один вид статистики, который надо собирать — это статистика по отдельным отношениям БД и по соответствую- щим индексным файлам. Например, какой объем памяти за- нят под индексы, под области переполнения, непосредствен- но под отношение, под рабочую область СУБД (например, процент занятости рабочей области — файла work для СУБД ADABAS). Что означает аббревиатура «ААА» в контексте мер защиты от несанкционированного доступа? (стр. 161) Средства защиты от несанкционированного доступа Под этим подразу- мевается обеспечение защищенности базы данных от любых предумышленных и непредумышленных угроз с помощью различных средств. Защита БД администратором должна охватывать про- граммное обеспечение, персонал, используемое оборудование, сами данные. Обычно проблемы защиты БД рассматриваются администратором с точки зрения таких потенциальных опас- ностей [1], как: — похищение и фальсификация данных; — утрата целостности; — потеря доступности; — утрата конфиденциальности. Администратор системы обязательно должен пользоваться всеми необходимы- ми средствами защиты операционных систем [2] и СУБД [1]. Прежде всего к ним относятся так называемые меры «3А» или «ААА», что означает: Авторизация пользователей, Аутентифи- кация пользователей, Аудит пользователей. Для обеспечения этих мер защиты в ОС и в СУБД всегда существуют специ- альные средства, которые входят в состав ядра ОС или СУБД, либо представляют собой отдельные утилиты. В чем суть автоматического режима устранения ошибок? FCAPS (стр. 36) F – Fault Management (управление при отказах) Управление отказами Эта группа задач включает в себя выявление, определение и устранение последствий сбоев и отказов в работе сети. На этом уровне выполняется не только регистрация сообщений об ошибках, но и их фильтрация и анализ. Фильтрация позволяет выделить из весьма интенсивного потока сообщений об ошиб- ках, только важные сообщения; маршрутизация обеспечивает их доставку нужному элементу системы управления, а анализ позволяет найти причину, породившую поток сообщений. Устранение ошибок может быть как автоматическим, так и полуавтоматическим. В автоматическом режиме система не- посредственно управляет оборудованием или программными комплексами и обходит отказавший элемент, например, за счет резервных каналов. В полуавтоматическом режиме основные решения и действия по устранению неисправности выполня- ют службы администратора системы, а система управления только помогает в организации этого процесса — оформляет квитанции на выполнение работ и отслеживает их поэтапное выполнение (подобно системам групповой работы). В чем заключается проактивная стратегия поиска ошибок? (стр. 204) Стратегия управления ошибками может быть проактивной либо реактивной. С ростом объема ИС возрастает потребность в ее надежности и, соответственно, возрастает потребность в предварительном мониторинге производительности системы, предупреждениях пользователям о возможных проблемах, постоянной бдительности администратора системы. Такая стратегия предупреждения ошибок называется проактивной. Стратегия, при которой АС не предупреждает появление оши- бок, а разбирается с ошибками по мере их возникновения, называется реактивной. АС должен приложить усилия и воспользоваться средствами MS или NMS для перехода от реактив- ной стратегии к проак- тивной. Обычно системы управ- ления отказами (ошиб- ками) — NMS разбивают сложную задачу иденти- фикации и диагностики ошибки на четыре подза- дачи [64]: — определение ошибки; — генерация тревожно- го сигнала; — изоляция ошибки; — коррекция ошибки. Эти подзадачи проил- люстрированы на рис. 8.2. При этом возможны две технологии работы NMS — пассивная и активная. Когда администратором системы применяется пассивная технология работы NMS? (стр. 205) Пассивная технология. С помощью протокола SNMP устройства опове- щают управляющую си- стему о выполнении за- ранее предусмотренного и заданного параметрами системы условия, напри- мер отличие какого-либо параметра от номинально- го значения. Эта техноло- гия должна применяться администратором систе- мы при идентификации проблем, не связанных с аппаратными сбоями, например, при изменении производительности, проблемах ин- терфейсов и т. д. Какие средства диагностики ошибок входят обычно в состав операционной системы? (стр. 207) Помимо управляющих систем (MS и NMS) существует ряд средств диагностики ошибок, необходимых службам админи- стратора системы. Рассмотрим эти средства. Средства ОС и СУБД. В составе любой ОС и СУБД всегда есть специализированные утилиты (возможно, модули ядра) или утилита «Монитор». Это программные продукты, запу- скаемые на файл-сервере либо на сервере БД, либо на спе- циализированных выделенных серверах под управлением ОС. Монитор или мониторы позволяют собирать статистику оши- бок, анализировать их, выдавать предупреждения админи- стратору системы о сбоях и т.д. Эти утилиты частично выпол- няют функции MS или NMS. Загружаются они при загрузке ОС либо при запуске приложения (сессии приложения), либо при запуске ядра СУБД. Перечислите средства эмуляции системной консоли администратора системы, ставшие промышленным стандартом. (трю 207 далее) Средства эмуляции предназначены для эмуляции систем- ной консоли оборудования в удаленном варианте. Они обыч- но входят в состав любой операционной системы и использу- ются, например, для управления консолью любого сетевого оборудования с персонального компьютера администратора системы. Существует промышленный стандарт на такую эму- ляцию, реализованный в программах Telnet (TELEtype NETwork) и SSH (Secure Shell) [52]. Программное обеспечение Telnet первоначально использовалось на UNIX-серверах и пред- назначено для конфигурации и администрирования сетевых устройств с машины администратора системы. Приведите пример основных ошибок адресации протоколов TCP/IP. Срр. 214) Раздел 8.7. Диагностика ошибок в среде TCP|IP |