Файл: В дипломной работе решены следующие задачи.docx

Введение

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

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

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

Целью данной дипломной работы является организация системы хранения данных в ИВЦ КГБОУ СПО КАТТ.

В дипломной работе решены следующие задачи:

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

2. Выбрать программные и аппаратные компоненты системы резервирования данных;

3. Оценить экономическую эффективность разработанной системы резервного копирования;

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

5. Разработать схему системы хранения данных.
1.Общая часть

1.1 Назначение, область применения, классификация, основные параметры и характеристики изделия
Назначение

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

---

Задачи СХД

Должны обеспечивать непосредственно следующие требования:

- Производительность - высокая скорость доступа к данным.

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

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

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

В процессе создания СХД необходимо достичь оптимального соотношения производительности, доступности (надежного хранения и отказоустойчивого доступа) и совокупной стоимости владения.

Одним из наиболее часто используемых методов обеспечения высокой доступности СХД является дублирование, которое повышает стоимость системы. Если не учитывать бизнес-требований заказчика к доступности системы, то система становится неоправданно дорогой. Погоня за ненужной производительностью также приведет к использованию дорогих технических средств. Помимо высоких показателей производительности, доступности и низкой стоимости нужно также обеспечить требуемую функциональность — объем хранения и число подключаемых серверов.

К сожалению, заказчики не всегда могут описать требования по производительности в количественных характеристиках, принятых для систем хранения — пропускной способности (Мбайт/с) или производительности (операций ввода-вывода в секунду — I/O per second (IOPS)). Поэтому, чтобы определить если не количественные характеристики, то хотя бы характер нагрузки, проектировщику необходимо выяснить, работу каких приложений должна обеспечивать СХД.

Различные классы приложений создают разную нагрузку на дисковую подсистему. Например, для СУБД характерны виды нагрузок, зависящие от классов задач — транзакционные системы (Online Transaction Processing (OLTP)) и аналитические системы (Decision Support Systems (DSS)). Для задач класса OLTP характерным является большой поток запросов на ввод-вывод небольших порций данных. Для задач класса DSS, напротив, характерно небольшое число запросов на чтение больших порций информации.

---

От того, какую нагрузку дает приложение, зависит выбор способа распределения данных по дискам и определение объема кэш-памяти дискового массива. Так для OLTP-задач наличие кэш-памяти в дисковом массиве может сыграть существенную роль для повышения производительности ввода-вывода. Напротив, в задачах класса DSS происходит считывание больших объемов данных, что практически исключает их повторное попадание в кэш-память (в отличие от OLTP-задач). Таким образом, кеширование считываемых данных при обработке DSS-задач не всегда увеличивает их производительность.

К типам нагрузки на СХД, производимыми задачами класса OLTP, DSS и файловыми сервисами можно отнести другие известные типы приложений. Так, почтовый сервис, построенный на базе MS Exchange или Lotus Domino, даёт сходную нагрузку на СХД, что и OLTP, поскольку указанные продукты построены на базе СУБД. Почтовый же сервис, основанный на sendmail, производит нагрузку на СХД, характерную для файловой системы с частым изменением метаданных. Средства резервного копирования выполняют последовательное чтение данных, подлежащих резервному копированию, что делает характер их операций схожим с DSS-задачами.

Существует еще один, не упомянутый ранее, тип нагрузки, характерный для процессов журналирования. Примером могут служить записи журналов транзакций СУБД или журналов событий операционных систем. К этому классу также можно отнести задачи загрузки данных в БД или хранилище данных (Data Warehouse). Нагрузка, осуществляемая на СХД этим классом задач, аналогична нагрузке DSS только для операций записи. Здесь наличие кэш-памяти (на запись) в дисковом массиве не увеличивает производительности записи данных. Данный тезис необходимо пояснить. Обычно применение кэш-памяти на запись уменьшает время, которое сервер тратит на операцию записи и ожидание её завершения. Но при записи большого объема информации (загрузка данных в БД) или при записи данных, которые пишутся на новое место, таких как журнал транзакций, существует высокая вероятность возникновения ситуации, когда кэш-память на запись уже будет полностью занята, а новый записываемый блок не соответствует ни одному из уже присутствующих в кэш-памяти. В этом случае массиву придется освободить несколько блоков кэш-памяти, записав их содержимое на диски, прежде чем начать обработку поступившей операции.

Определить классы задач, которые будет обслуживать СХД, необходимо не только для выработки политики работы с кэш, но также для распределения данных по дискам (disk layout). Для обеспечения надежного хранения информации диски организуются в уровни RAID 1, 0+1/1+0 или 5. Самым экономичным с точки зрения использования дополнительного (дублирующего) дискового пространства является уровень RAID 5. Однако производительность RAID 5 ниже, чем у RAID 1 или 0+1 при частых случайных изменениях данных, характерных для OLTP-задач, и высока при считывании данных, что характерно для DSS-задач.

---

Также разные уровни RAID обеспечивают различные уровни отказоустойчивости дисковой памяти к сбоям отдельных дисков. Так RAID 5 не спасает от двух последовательных отказов дисков, впрочем, как и RAID 0+1, если это диски разных половин "зеркала". Наиболее отказоустойчивым является уровень RAID 1+0 (попарное "зеркалирование" дисков и затем их "striping(1)"), поэтому его рекомендуется применять для хранения критичных данных, например, журналов транзакций СУБД. Практика показывает, что для хранения файловых систем и данных DSS-задач достаточно использовать RAID 5. Однако, если файловая система часто изменяется как, например, в почтовых системах sendmail, то имеет смысл использовать журналированную файловую систему или файловую систему с отдельно хранимыми метаданными, например файловую систему Sun QFS. Тогда для хранения журналов или отдельных метаданных лучше применять RAID 1 или 1+0.

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

Для "больших" систем актуальной становится оптимизация настроек СХД, направленная на повышение быстродействия для достижения заданного уровня сервиса. Под "большой" понимается такая система, в которой обрабатывается значительный объем данных — единицы и десятки терабайт, и/или к СХД подключены десятки серверов. Для небольших систем проблемы с быстродействием можно решить применением более производительной аппаратуры. В "больших" системах такой подход может оказаться неприемлемым либо в связи с тем, что потребуется очень дорогая аппаратура, либо в связи с тем, что уже достигнут предел аппаратной производительности. Единственным решением в данном случае является оптимизация. Для оптимизации производительности СХД желательно иметь возможность управлять настройками на всем пути следования данных от процессора к дискам и обратно. Для СУБД ORACLE такая оптимизация заключается в возможности использовать KAIO, а также возможности отключить кэш файловой системы для файлов данных ORACLE (поскольку СУБД ORACLE кэширует данные в собственной области памяти SGA). Для этой цели можно использовать упомянутый ранее пакет VERITAS DBE. Если в системе эксплуатируются OLTP- и DSS-задачи (что является типичным для большинства систем), то для оптимизации производительности дискового массива желательно иметь возможность управлять настройками кэш-памяти для каждого логического диска (LUN) в отдельности. Это необходимо для того, чтобы для тех дисков, где расположены данные OLTP-задачи, использовать кэш (и желательно большого объема), а для дисков с данными DSS-задачи использование кэш-памяти отключить. Однако, если для OLTP- и DSS-задач используются одни и те же таблицы данных, то такие настройки теряют смысл до тех пор, пока не будет решен вопрос о физическом

---

разнесении данных задач по разным дискам, а выполнение самих задач перенесено на разные серверы. Это можно реализовать средствами СУБД, например, с помощью экспорта данных в файл и импорта их в другую базу. Если объем данных велик и синхронизацию баз данных OLTP- и DSS-задач надо проводить достаточно часто, этот вариант может оказаться неэффективным. Здесь может помочь технология создания PIT-копий данных, реализованная в большинстве современных дисковых массивов.

Выше говорилось, что СХД является важным звеном в обеспечении заданного уровня сервисов, предоставляемых информационной системой. Уровень сервиса зависит не только от производительности СХД, вопросы обеспечения которой только что обсуждались, но также от готовности и надежного хранения данных, другими словами, от доступности СХД. Исходя из бизнес-требований к информационной системе, необходимо определить режимы её работы (24х7, 12х5 и т.п.), степень критичности данных в зависимости от степени критичности сервисов, использующих эти данные, требования к готовности и надежности данных в зависимости от степени их критичности и режимов работы системы.

Анализируя бизнес-требования к информационной системе из приведенного примера, получается, что СХД банка должна обеспечивать работу двух типов задач — OLTP и DSS. Данные OLTP-задачи являются критичными для системы в период с 6:00 до 23:00 (учитывается загрузка данных из АБС в аналитическую базу) и должны обеспечивать высокую готовность (простой не более 1 часа). Требования по надежности также высоки — потери не более получаса работы. Напротив, данные DSS-задачи не столь критичны и требования по готовности не столь высоки, но должна быть обеспечена высокая надежность — потери не допустимы.

Суммируя выше сказанное получаем, что для определения требуемых параметров СХД и поддержания их в заданных рамках необходимо четко определить классы, режимы работы и характеристики задач, работу которых должна обеспечить СХД, требуемый объем хранения данных и его возможный прирост, количество и платформы (UNIX, Windows и др.) подключаемых серверов. Иными словами, при создании СХД проектировщик должен исходить от задач и бизнес-требований заказчика.

Структура СХД

Система хранения данных должна включать следующие подсистемы и компоненты:

---