Единый портал внешнеэкономической информации Минэкономразвития России

Приложение 7

УТВЕРЖДАЮ От Заказчика Заместитель директора Сводного департамента анализа и регулирования внешнеэкономической деятельности Минэкономразвития России ________________________ « » _____________ 2009 г.		УТВЕРЖДАЮ От Исполнителя Генеральный директор Медиа» ________________________ « » _____________ 2009 г.
Единый портал внешнеэкономической информации Минэкономразвития России Спецификация на техническую инфраструктуру
Шифр темы: 1607-05-09
Листов 12
Москва, 2016

Содержание

1 Схема автоматизации. - 3 -

2 Описание комплекса технических средств. - 4 -

2.1. Общие положения. - 4 -

2.2. Структура комплекса технических средств. - 8 -

2.2.1 Обоснование выбора структуры КТС.. - 8 -

2.2.2 Описание функционирования КТС.. - 8 -

2.2.3 Описание размещения КТС.. - 8 -

2.2.4 Обоснование методов защиты ТС.. - 9 -

2.2.5 Результаты проектной оценки надежности КТС.. - 9 -

2.3. Средства вычислительной техники. - 9 -

2.3.1. Выбор типа ЭВМ... - 9 -

2.3.2. Выбор типов периферийных ТС.. - 9 -

2.3.3. Описание структурной схемы ТС.. - 9 -

2.3.4. Расчет числа ТС.. - 9 -

2.3.5. Общесистемное и специализированное программное обеспечение. - 10 -

2.3.6. Программные зависимости. - 10 -

2.3.7 Численность персонала. - 11 -

2.3.8 Особенности функционирования ТС.. - 11 -

2.3.9 Ключевые моменты при работе с КТС.. - 11 -

2.4. Аппаратура передачи данных. - 12 -

1  Схема автоматизации

Таблица 1 - Обозначения схемы

Термин, сокращение	Пояснение
БД	Сервер базы данных
Front end	Сервер кеширования и распределения нагрузки
Web Server	Веб сервер
User station	Пользовательские станции

2  Описание комплекса технических средств

2.1.  Общие положения

Техническое обеспечение спроектировано с учетом возможности роста нагрузки и обеспечением необходимой отказоустойчивости и распределения нагрузки при эксплуатировании объединенного портала.

Данный комплекс технических средств состоит из следующих компонентов:

- База данных — представляет собой кластер из серверов баз данных;

База данных MySQL — свободная система управления базами данных (СУБД). MySQL является собственностью компании Sun Microsystems, осуществляющей разработку и поддержку приложения. Распространяется под GNU General Public License и под собственной коммерческой лицензией, на выбор. Помимо этого компания MySQL AB разрабатывает функциональность по заказу лицензионных пользователей, именно благодаря такому заказу почти в самых ранних версиях появился механизм репликации.

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

Гибкость СУБД MySQL обеспечивается поддержкой большого количества типов таблиц: пользователи могут выбрать как таблицы типа MyISAM, поддерживающие полнотекстовый поиск, так и таблицы InnoDB, поддерживающие транзакции на уровне отдельных записей. Более того, СУБД MySQL поставляется со специальным типом таблиц EXAMPLE, демонстрирующим принципы создания новых типов таблиц. Благодаря открытой архитектуре и GPL-лицензированию, в СУБД MySQL постоянно появляются новые типы таблиц.

Базы данных SQLite3. Раньше SQLite3 использовалась для хранения данных: пользователей, тэгов, описаний и так далее. – Данные хранились на монолитном RAID 10 массиве, состоящем из 10 жестких дисков; – Оборудование арендовалось, что негативно сказывалось на состоянии кредитных карточек. В случае необходимости нового оборудования, на оформление заказа и доставку мог уходить далеко не один день. – Они прошли через весь путь эволюции: сначала был один сервер, затем добавилось несколько дополнительных серверов, обслуживающих операции чтения, после чего они решили разбить базу данных на части, и, наконец, они пришли к полноценной распределенной архитектуре. – Поначалу их система страдала от задержек, связанных с реплицированием. Основной сервер, обрабатывающий операции записи, являлся мощным сервером, работающим в многопоточном режиме, это было необходимо для своевременного выполнения большого объема работы. Второстепенные сервера, которые обрабатывали только операции чтения, асинхронно реплицировали данные в одном потоке, что влекло за собой возможность серьезного отставания некоторых из них. – Обновления были причиной частого отсутствия необходимой информации в кэше, что заставляло сервера читать данные с жестких дисков. Этот факт сильно замедлял процесс чтения и репликации. – Реплицирующая архитектура требует немалых вложений в оборудование, необходимого для поддержания постоянно растущих темпов записи информации. – Основным из кардинальных решений, принятых в архитектуре системы было отделение обеспечения процесса просмотра видео от основного кластера. Основной целью посетителей является просмотр видео, а второстепенные задачи можно возложить и на менее производительный кластер.

Сейчас: – Используются распределенные базы данных;
– Сегментированная система (по аналогии с Flickr);
– Распределенные чтение и запись;
– Более эффективное расположение кэша, что ведет к уменьшению работы с жесткими дисками;
– Такая архитектура привела к 30%-й экономии на оборудовании;
– Задержки в реплицировании сведены к нулю;
– Размеры базы данных могут расти практически неограниченно.

- Веб сервер — представляет собой два веб сервера;

Apache HTTP-сервер — свободный веб-сервер.

Apache является кроссплатформенным ПО, поддерживая операционные системы GNU/Linux, BSD, Mac OS, Microsoft Windows, Novell NetWare, BeOS.

Основными достоинствами Apache считаются надёжность и гибкость конфигурации. Он позволяет подключать внешние модули для предоставления данных, использовать СУБД для аутентификации пользователей, модифицировать сообщения об ошибках и т. д. Поддерживает IPv6.

Ядро

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

Теоретически, ядро apache может функционировать в чистом виде, без использования модулей. Однако, функциональность такого решения крайне ограничена.

Ядро Apache полностью написано на языке программирования C.

Система конфигурации

Система конфигурации Apache основана на текстовых конфигурационных файлах. Имеет три условных уровня конфигурации:

  Конфигурация сервера (httpd. conf).

  Конфигурация виртуального хоста (httpd. conf c версии 2.2 extra/httpd-vhosts. conf).

  Конфигурация уровня директории (.htaccess).

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

Часть модулей использует в своей работе конфигурационные файлы операционной системы (например /etc/passwd и /etc/hosts).

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

Мультипроцессорные модели (MPM)

Для web-сервера Apache существует множество моделей симметричной мультипроцессорности.

Недостатком наиболее часто называется отсутствие удобного стандартного интерфейса для администратора.

Компонент распределения нагрузки — представлен кеширующим веб сервером с возможностью распределения нагрузки и автоматической обработкой событий отказа одного из веб серверов;

Свойство информационной или вычислительной системы сохранять способность правильно функционировать после отказа системы или некоторых ее частей. Основной способ повышения отказоустойчивости — избыточность. Наиболее эффективный метод избыточности — аппаратная избыточность, достигается путем резервирования ЭВМ.

nginx [engine x] — это HTTP-сервер и почтовый прокси-сервер.

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

Основная функциональность HTTP-сервера:

·  обслуживание статических запросов, индексных файлов, автоматическое создание списка файлов, кэш дескрипторов открытых файлов;

·  акселерированное проксирование с кэшированием, простое распределение нагрузки и отказоустойчивость;

·  акселерированная поддержка удалённых FastCGI серверов с кэшированием, простое распределение нагрузки и отказоустойчивость;

·  модульность, фильтры, в том числе сжатие (gzip), byte-ranges (докачка), chunked ответы, XSLT-фильтр, SSI-фильтр, преобразование изображений; несколько подзапросов на одной странице, обрабатываемые в SSI-фильтре через прокси или FastCGI, выполняются параллельно;

поддержка SSL и расширения TLS SNI.

- Рабочие станции — представлены на схеме рабочими станциями;

Рабо́чая ста́нция — комплекс технических и программных средств, предназначенных для решения определенного круга задач.

Рабочая станция как место работы специалиста представляет собой полноценный компьютер или компьютерный терминал (устройства ввода-вывода, отделённые и часто удалённые от управляющего компьютера), набор необходимого ПО, по необходимости дополняемые вспомогательным оборудованием: печатающее устройство, внешнее устройство хранения данных на магнитных и/или оптических носителях, сканер штрих-кода и пр.

В отечественной литературе также использовался термин АРМ (автоматизированное рабочее место), но в более узком смысле, чем «рабочая станция».[1]

Также термином «рабочая станция» обозначают компьютер в составе локальной вычислительной сети (ЛВС) по отношению к серверу. Компьютеры в локальной сети подразделяются на рабочие станции и серверы. На рабочих станциях пользователи решают прикладные задачи (работают в базах данных, создают документы, делают расчёты). Сервер обслуживает сеть и предоставляет собственные ресурсы всем узлам сети, в том числе и рабочим станциям.

Существуют достаточно устойчивые признаки конфигураций рабочих станций, предназначенных для решения определённого круга задач, что позволяет обособлять их в отдельный профессиональный подкласс: мультимедиа (обработка изображений, видео, звука), САПР, ГИС, полевая работа и пр. Каждый такой подкласс может иметь присущие ему особенности и уникальные компоненты (в скобках даны примеры областей использования): большой размер видеомонитора и/или несколько мониторов (САПР, ГИС, биржа), быстродействующая графическая плата (кинематограф и мультипликация, компьютерные игры), большой объём накопителей данных (фотограмметрия, мультипликация), наличие сканера (фотография), защищённое исполнение (вооружённые силы, полевые работы) и пр.

2.2.  Структура комплекса технических средств

2.2.1 Обоснование выбора структуры КТС

Кластер баз данных выбран для обеспечения 100% избыточности информации в базе данных.

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

Количество веб серверов на данную нагрузку рекомендовано 2.

2.2.2 Описание функционирования КТС

Авария на одном элементе компонента (за исключением сервера распределения нагрузки) не приведет к сбою всей системы и будет выражена только 30% снижением скорости у пользователей. У 25% пользователей будет наблюдаться единоразовое кратковременное снижение скорости.

2.2.3 Описание размещения КТС

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

Температура воздуха в помещении — 18-24 о С;

Допустимые отклонения температуры — +/- 2 о С;

Относительная влажность воздуха — 40-50%;

Точность поддержания влажности — +/- 1%.

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

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

2.2.4 Обоснование методов защиты ТС

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

2.2.5 Результаты проектной оценки надежности КТС

Надежность системы составляет 73%.

2.3.  Средства вычислительной техники

2.3.1.Выбор типа ЭВМ

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

2.3.2.  Выбор типов периферийных ТС

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

2.3.3.  Описание структурной схемы ТС

Структурные единицы схемы не должны быть разнесены друг от друга на расстояние более 100 метров.

2.3.4.  Расчет числа ТС

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

1. Серверы Баз данных (2 сервера):

–  4 процессора не менее 2,5 Ghz;

–  Оперативная память не менее 8 Gb;

–  Дисковая подсистема 10 RAID объемом не менее 250 Gb;

2. Веб серверы (2 сервера):

–  4 процессора не менее 3,5 Ghz;

–  Оперативная память не менее 4 Gb;

–  Дисковая подсистема 1 RAID объемом не менее 250 Gb;

3. Сервер распределения нагрузки (1 сервер):

–  4 процессора не менее 2,5 Ghz;

–  Оперативная память не менее 4 Gb;

Дисковая подсистема 1 RAID объемом не менее 250 Gb.

2.3.5.  Общесистемное и специализированное программное обеспечение

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

·  Debian – unix-подобная операционная система

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

·  Ruby – интерпретатор языка программирования, на котором реализована система

·  Passanger – модуль для nginx, правильно интерпретирующий программный код системы для отдачи клиентам.

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

·  Ferret – платформа, обеспечивающая реализацию поиск по материалам сайта, базе данных и файлам в системе

·  Act_as_ferret – программная библиотека, реализующая связь ferret с системой.

·  ImageMagick – программное обеспечение, реализующее быструю и стабильную работу с изображениями – их конвертацию, изменение и масштабирование

·  Rmagick – программная библиотека, реализующая связь ImageMagick с системой

·  Oracle – система управлением базы данных системы

2.3.6.  Программные зависимости

Функционирование сайта обеспечивается интерпретатором Ruby, интегрированным в HTTP-сервер.

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

• nginx httpd server

• Ruby 1.8

• mod_passenger

Реализация сайта поддерживает набор различных СУБД: MySQL, PostgreSQL, SQL Server, Oracle, SQLite. Для работы потребуется любая СУБД из перечисленного списка.

Кроме этого для функционирования потребуются следующие библиотеки:

• imagemagick

• клиент для выбранной СУБД

• ferret

После установки Ruby 1.8 и указанных библиотек, потребуются следующие модульные расширения интерпретатора (называемые далее gem'ы):

• rails 2.3.4

• rmagick

• acts_as_ferret

Далее будут приведены примеры команд по установке зависимостей на дистрибутиве Debian Linux с использованием СУБД SQLite.

2.3.7  Численность персонала

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

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

2.3.8  Особенности функционирования ТС

В пусковом режиме для данных технических средств характерно повышенное потребление электроэнергии (до 2х кратного превышения номинального).

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

2.3.9  Ключевые моменты при работе с КТС

Придерживайтесь принципа: Чем проще — тем лучше;

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

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

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

Не забывайте о случайных доступах к жестким дискам, эту, казалось бы, мелочь тоже стоит настроит

2.4.  Аппаратура передачи данных

Рекомендованная пропускная способность не менее 950 Mb/sec.

Сюда включено 30% резервирование на время пиковых нагрузок.

Для обеспечения безотказной работы рекомендуется аренда 2 аналогичных каналов от разных поставщиков. Также рекомендуется подключение данных каналов к серверу через маршрутизатор с автоматическим переключением на резервный канал в случае потери связи.

В последнее время стал использоваться метод Push: каждый раз, когда происходит какое-либо событие, они помещаются в пользовательский «почтовый ящик», в момент запроса пользователя ему возвращается просто содержимое, уже ожидающее своего звездного часа в специально том самом «ящике»;

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

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

  небольшая часть обработки данных все же производится уже в момент запроса пользователя (например, объединение нескольких обновлений от определенного пользователя в одно);

  обновления хранятся в CLOB'ах: по одному CLOB'у на каждый тип обновления для каждого пользователя (то есть в сумму около 15 CLOB'ов на каждого пользователя);

  сначала использовался размер CLOB'ов равный 8 KB, что было явно больше требуемого и приводило к существенному количеству неиспользуемого дискового пространства.

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

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

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

  Был добавлен буфер: колонки в таблицах типа varchar (4000), в которых данные помещались изначально. При полном заполнении ячейки данные перемещаются в CLOB; это позволило на порядок сократить количество их обновлений.

Уменьшен размер самих сообщений об обновлениях.