Диплом: Разработка ЛВС функционирующей под управлением ОС Linux/Windows для сети медицинских центров "Шаттл"

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам
62
блокирует доставку сообщений, сгенерированных программ ным
обеспечением для массовых рассылок;
- На финальном этапе производится проверка сообщения
антивирусной программой ClamAV.
В качестве MDA выбран программный пакет Courier Mail Server,
также являющийся открытым программным обеспечением,
поддерживающим доставку почтовых сообщений по протоколам IMAP и
POP3, а также имеющий возможность интеграции с Active Directory.
3.2.4. Реализация сервиса файлового архива
Сервис общего файлового архива (хранилища) является базовым в
подавляющем большинстве локальных вычислительных сетей. Данный
сервис позволяет не только безопасно обмени ваться файлами в пределах
ЛВС, но и обеспечивает централизованное хранение, что в свою очередь
позволяет реализовать централизованное управление доступом к файлам
пользователей сети и упростить резервное копирование. Д ля организации
доступа к единому ф айловому хранилищу ЛВС в операционных системах
Windows (как серверных, так и предназначенных для рабочих станций)
реализован протокол SMB (англ. Server Message Block)
усовершенствованный диалект протокола CIFS (англ. CIFS - Common
Internet File System, Единая Файловая Си сте ма Интернета). Протокол SMB
позволяет осуществлять удаленный доступ к ф айлам, принтерам и другим
сетевым ресурсам. Начиная с 2008 года, протокол является открытым и
полностью поддерживается на только семейством операционных систем
Windows, но и в других ОС, в том числе Red Hat Enterprise Linux.
Реализация файлового сервера, работающего по протоколу SMB в
операционных системах Linux возможна с использованием пакета SAMBA.
[15] Пакет SAMBA позволяет организовать доступ к сетевым дискам и
принтерам для клиентов Windows абсолютно прозрачным для пользователя
образом. Пользователи, используя сетевое окружение Windows могут
63
подключаться к серверу SAMBA и использовать файлы (создавать,
изменять, удалять) также, как и при использовании файловых служб
Windows Server.
3.3. Система Управления Базами Данных
Работа современного медицинского центра не возможна без
использования автоматизированной информационной системы. В сети
медицинских центров Шаттл планируется использовать медицинскую
информационную систему MGERM, построенну ю на баз е сис те мы
управления базами данных MySQL.
MySQL является самой распространенной системой управления
базами данных в мире. [34] История данной СУБД начинается в 1994 году,
когда в компании TcX, специализирующейся на обработке данных,
стартовал проект п о созданию web-приложений. Имевшийся в
распоряжении компании интерфейс для доступа к хранилищу данных
UNIREG не соответствовал в полной мере техническим требованиям,
главное н есоответствие заключалось в больших накладных расходах при
работе с большими таблицами хранилища. В поисках решения проблем,
автор UNIREG Михаил В идениу с обрати л вни мани е на сущ ествов авш ую
тогда СУБД mSQL, однако она также не могла удовлетворить всех
требований компании. В итоге, в 1995 году, с использованием открытых
(open-source) средств mSQL и наработок, реализованных в UNIREG была
создана новая СУБД MySQL. Изначально предназначенная для
удовлетворения потребностей, возникших в период бурного развития сети
Internet, MySQL достаточно бы стр о обрела популяр нос ть. Отчасти росту
популярности способствовала относительная простота в использовании и
поддержке, однако главным преимуществом стала открытость исходных
кодов системы.
На сегодняшний день MySQL представляет из себя локальную
клиент-серверную СУБД с реляционной моделью хранения данн ых. В
64
качестве языка запросов используется SQL (Structured Query Language)
версии SQL:2003 с некоторыми отличиями, обусловленными
архитектурными особенностями С УБД . [16] [35] Несмотря на то, что
архитектурно MySQL является локальной СУБД, существую т
дополнительные модули (NDB Cluster, InnoDB Cluster, Galera),
позволяющие с некоторыми ограничениями создать распределенное
хранилище данных и превращая MySQL в распределенную СУБД.
СУБД MySQL портирована на большинство операционных систем -
FreeBSD, OpenBSD, MacOS X, Oracle Solaris, Windows, Linux и другие.
Наибольшее распространение получил вариант использования MySQL на
платформе Linux, большая часть литературы ориентирована именно на эту
операционную систему, в виду распространенность самой операционной
системы и простоты администрирования.
3.3.1. Архитектура MySQL
Архитектура MySQL отличается от архитектур других серверов баз
данных и делает эту СУ БД эффективной для ши рокого спектра задач.
MySQL не универсальна, но обладает достаточной гибкостью, чтобы
отлично работать в очень требовательных средах, например в веб-
приложениях. В то же время MySQL может использоваться во встроенных
приложениях, хранилищах данных, программном обеспечении
индексирования и доставки содержимого, высоконадежных системах с
резервированием, системах оперативной обработки транзакций (OLTP) и
других системах. [2, с. 24] Главной архитектурной особенностью, отличием
от других современных реляционных СУБД является возможность выбора
подсистемы хранения для всей базы данных или ее отдельных таблиц.
Фактически, СУБД MySQL позволяет одновременно работать с
несколькими различными по архитектуре базами данных, при этом, т.к.
подсистемы хранения реализованы в виде подключаемых модулей,
подключением новых подсистем хранения, их смена возможна без останова
65
сервера СУБД. Логическая архитектура СУБД MySQL представлена на
рисунке 8.
Архитектура СУБД трехуровневая. Верхний уровень представлен
службами сетевого взаимодействия, реали зующ им и про токол обмен а и
поддержку соединений, обеспечивающими аутентификацию и
безопасность. На втором уровне работают синтаксический анализатор,
служба кеширования запросов, все встроенн ые функц ии не зави симые от
подсистем хранения данных. Третий уровень образован подсистемами
хранения, отвечающими за обработку данных. Фактически, сам сервер
СУБД представляет собой первые два уровня, взаимодействующие с
независимыми подсистемами хранения через интерфейс прикладного
программирования (API). [17] Т.к. стандартизованный API является
уровнем абстракции, он скрывает особенности разных подсистем хранения,
делая работу прозрачной на уровне языка запросов. Подсистемы хранения
не взаимодействуют друг с другом.
Рисунок 8 - Логичес ка я архитектура СУБД
MySQL
66
3.3.2. Обработка соединений
Сервер MySQL, mysqld является многопоточным приложением. Для
каждого соединения выделяется отдельный поток, в рам ках которого
производятся все операции, связанные с этим соединением. В целях
повышения производительности обработки соединений сервер имеет кэш
потоков, что исключает необходимость их создания каждый раз при
подключении клиента. Первым шагом при подключении клиента является
аутентификация, которая производится по имени пользователя, паролю, IP-
адресу или доменному имени компьютера пользователя. При успешном
прохождении аутентификации, СУБД выделяет для клиента необходимые
ресурсы различные буферы в памяти, таблицы для контроля привилегий и
т.д. По окончании процедур соедин ения сервер готов к обработке запросов
клиента. [18]
3.3.3. Синтаксический анализ и оптимизация
При поступлении запроса клиента на языке SQL синтаксическим
анализатором выполняется его си нтаксически й разбо р с целью постр оения
алгоритма выпо лнени я запроса (плана запроса). После построения плана
запроса вып олняется его оптимизация. В ходе оптимизации выполняется
выбор используемых индексов, может меняться порядок обработки таблиц.
По завершении процесса построения и оптимизации плана запроса
происходит его выполнение.
3.3.4. Кэш запросов
Выполнение синтаксического разбора и построение плана запроса не
всегда оправдано с точки зрения использования систем ных ресурсов.
Достаточно часто разные клиенты формируют один и тот же запрос
выборки данных, получая в ответ одну и ту же выборку данных. При
реализации данного сценария крайне эффективным решением, с точки
зрения производительности, является кэширование данных выборки.
Подсистема кэширования MySQL сохраняет результаты выборо к вместе с
67
исходным запросом и при поступлении запроса, идентичного
сохраненному, возвращает кэшированный результат без выполнения
синтаксического разбора, оптимизации и запроса к подсистеме хранения.
Также, подсистема кэширование отслеживает изменения таблиц,
использовавшихся при выполнении первоначального запроса и при
изменении любой из них, удаляет кэшированные данные, обеспечивая
таким образом актуальность результатов выборки.
3.3.5. Установка и настройка
Установка сервера СУБД MySQL является стандартной процедурой
инсталляции программного обеспечения в RHEL, однако т.к. в состав
дистрибутива операционной системы входи т н е сам ая актуальная верси я
СУБД, оптимальным будет использовать дистрибутив, предоставляемый
разработчиком MySQL, компанией Oracle. Планируется подготовить
рабочий экземпляр СУБД MySQL версии 5.6 с использованием,
рекомендуемой разработчиком, подсистемы хранения InnoDB.
План установки:
a) Подготовить операционную систему к установке СУБД.
b) Определить расположение файлов данных сервера MySQL,
подготовить файловую систему.
c) Установить дистрибутив СУБД, выполнить первичную
настройку и запуск.
d) Выполнить создание базы данных и заполнить ее данными
путем их восстановления из резервной копии.
3.3.6. Подготовка операционной системы к установке
В первом приближении для MySQL не требуется каких-либо настроек
ОС для функционирования, однако т.к. файлы данных создаются в момент
первого запуска, а их изменение и перемещение требует останова СУБД,
оптимальным решением является подготовка мест хранение файлов
заранее. При больших нагрузках, на производител ьность сервер а влияю т
68
настройки файловой системы, их изменение также производится
исключительно с остановом сервера и их также логичнее выполнить до
момента запуска в эксплуатацию.
Для правильной настройки важно понимать принципиальную
архитектуру InnoDB.
Подсистема оперирует двумя глобальными буферами в памяти
общий буфер (Buffer pool) и буфер журналов транзакций (Log buffer), через
которые выполняются чтени е и запись файлов данных и файлов журналов
транзакций в файловой системе. С точки зрения производительности и
надежности, является оптимальным разделение данных БД и журналов
транзакций по разным дисковым разделам и физическим дискам (RAID
массивам).
В качестве файловой системы для хранения данных СУБД имеет
смысл выбирать ж урнал иру емые ФС, например, ext4 и XFS. Последняя,
Рисунок 9 - А рхитектура InnoDB
69
рекомендована компанией RedHat для применения с СУБД в условиях
высоких нагрузок. [20]
Таким образом, для установки сервера MySQL желательно выделить
два отдельных раздела, следуя стан дарту FHS 2.3 [36], регламе н ти р у ю щ ег о
месторасположение файлов и каталогов в файловой иерархии
операционных систем Linux, создадим два каталога:
- /srv/database/data точка монтирования для раздела с файлами
данных;
- /srv/database/tlog точка монтирования для раздела с файлами
журнала транзакций.
Отдельно, следует выделить независимый раздел для хранения
резервных копий базы данных:
/srv/database/backupточка монтирования раздела для резервных копий.
3.3.7. Установка дистрибутива MySQL
После подготовки разделов, их форматирования и монтирования
выполняется установка сервера MySQL:
- Подключение репозитария путем создания файла
/etc/yum.repos.d/mysql-community.repo сл едующ его содержания:
[37]
[mysql56-community]
name=MySQL 5.6 Community Server
baseurl=http://repo.mysql.com/yum/mysql-5.6-
community/el/6/$basearch/
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql
- Непосредственно установка MySQL командой:
sudo yum install mysql-community-server
70
3.3.8. Первичная настройка
Несмотря на то, что сервер готов к запуску непосредственно после
установки, для оптимального использования требуется выполнить его
настройку перед первым запуском. Конфигурирование выполняется путем
редактирования файла my.cnf, расположенног о в к ат ал о ге /etc.
Первоначально определим общие параметры работы сервера: [38]
- skip-name-resolveдиректива отключает использование службы
DNS для определения символьных имен узлов при подключении
клиентов.
- memlockдиректива позволяет зафиксировать процессы в памяти,
исключая их выгрузку в область подкачки.
Настройка сетевых параметров: [38]
- bind-address = 10.1.1.30 задает IP адрес
- port = 3306 задает TCP порт для подключения к серверу
- socket = /var/lib/mysql/mysql.sockзадает UNIX сокет, который
может быть использован для локальных подключений, минуя стек
TCP/IP
- max_connections = 50 максимальное количество соединений
- max_connect_errors = 16 максимальное количество ошибок в
течении сессии, при превышении этого количества, сервер
разорвет соединение с клиентом
- max_allowed_packet = 16M максимальный размер блока данных,
который может быть передан между сервером и клиентом.
Настройка мест хранения файлов данных и журналов транзакций: [39]
- innodb_data_home_dir = /srv/database/data/ - директивой
определяется каталог для хранения файлов данных
- innodb_data_file_path = ibdata0:8G;ibdata1:8G:autoextendзадаются
два файла для хранения данн ых, размером по 8 Гб, параметр
71
«autoextend» указывает на возмож ность автоматического
расширения файла ibdata1 в случае необходимости
- innodb_log_group_home_dir = /srv/database/tlog/ - директива задает
место расположения файлов журнала транзакций
- innodb_log_file_size = 128M – определяет размер файла журнала
транзакций
- innodb_log_files_in_group = 2 определяет количество файлов
журнала транзакций
Настройка использования оперативной памяти: [39]
- innodb_buffer_pool_size = 2G – устанавливает размер общего
буфера в 2 Гб
- innodb_additional_mem_pool_size = 8M – помимо общего буфера в
оперативной памяти, InnoDB использует отдельную область
памяти для хранения мета-данных таблиц, индексов и других
внутренних структур. Директива задает размер служебного буфера
- innodb_log_buffer_size = 2M – размер буфера журналов транзакций
- innodb_thread_concurrency = 2 директива определяет количество
одновременно выполняемых потоков чтения и записи, для
достижения опти мальной производительности, их количество
должно соответствовать количеству процессоров сервера.
Настройки локализации: [40]
- character_set_server = utf8 директива задает кодировку, в которой
текстовые данные сохраняются в БД
- collation_server = utf8_general_ciзадает параметры сортировки.
После выполнения первичной настройки, сервер MySQL готов к
первому запуску, однако до момента запуска требуется первичная
инициализация каталогов, выполняемая при помощи запуска скрипта
mysql_install_db. После ин и ц иа л из ац и и , выполн яе тс я первый запуск сервер

Смотрите также:

"Автоматизация обработки заявок ООО "Проектно-Строительная Компания"
"Автоматизация процесса аттестации персонала для ООО "Нэт Бай Нэт Холдинг"
"Анализ интернет-активности конкурентов ( на примере конкурентов "Газпром нефть")
"Бухгалтерский учёт и аудит расчётов с подотчётними лицами в организации на примере ООО "ЛОЦ 10""
«Психологическое сопровождение персонала в организации на примере ООО «Крокус»
Cовершенствование деловой оценки персонала в организации (на примере ООО "Даймонд кейтеринг развитие")
PR как средство продвижения организации (на примере ПАО "Тамбовский завод "Комсомолец им. Н.С. Артемова")
PR-коммуникации в сфере общественного питания (на примере кафе-кондитерской «Cream Cheese»)
SMM как средство повышения эффективности работы учреждений социокультурной сферы (на примере Малого театра)
Value-based education: ценности в системе образования и способы их реализации на уроке английского языка. Опыт Европейских стран