Технические и технологические требования к элементам инфраструктуры электронного правительства в Республике Коми (2011 год)

Содержание

ИСПОЛЬЗУЕМЫЕ ТЕРМИНЫ И СОКРАЩЕНИЯ

1 ОБЩИЕ ПОЛОЖЕНИЯ

1.1

Цели и задачи технических и технологических требований к элементам

инфраструктуры электронного правительства в Республике Коми

1.2

Нормативно-техническое обеспечение ИТ-деятельности

2 СОВРЕМЕННЫЕ ТЕНДЕНЦИИ В ОБЛАСТИ ИТ

2.1

Консолидация ресурсов

2.2

Виртуализация ресурсов

2.2.1 Логическое деление вычислительных комплексов

2.3

Современная архитектура приложений

2.3.1 Сервис-ориентированная архитектура - SOA

2.3.2 Многоуровневая архитектура клиент-сервер

2.4

Модель SaaS

2.5

Средства интеграции приложений (middleware)

2.6

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

3 РЕКОМЕНДАЦИИ ПО УПРАВЛЕНИЮ ИТ ИНФРАСТРУКТУРОЙ

3.1

Необходимость изменений в ИТ-инфраструктуре

3.2

Рекомендации по проведению изменений в ИТ инфраструктуре

3.2.1 Общие требования к тестированию и приемке изменений

3.2.2 Требования «разумного консерватизма»

3.2.3 Автоматизация тиражирования обновлений ПО

3.3

Рекомендации по планированию ИТ-инфраструктуры

3.3.1 Рекомендации по выбору горизонтов планирования для ИТ-приложений

3.3.2 Рекомендации по расчету производительности и объема хранимой информации для ИТ-

систем (масштабирование ИТ-систем)

4 КАТАЛОГИЗАЦИЯ И КЛАССИФИКАЦИЯ ЭЛЕМЕНТОВ ИТ-ИНФРАСТРУКТУРЫ

4.1

Типизация элементов ИТ-инфраструктуры

4.2

Классификация государственных информационных систем

4.3

Классификация по уровню требуемой непрерывности обслуживания

4.4

Принципы создания КРК

4.5

Документы, рекомендованные к разработке в органах государственной

власти Республики Коми

5 ТРЕБОВАНИЯ К ПОСТАВЩИКАМ, ПРОИЗВОДИТЕЛЯМ И ПРОВЕДЕНИЮ

КОНКУРСОВ

6 ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ К ЭЛЕМЕНТАМ ИТ-ИНФРАСТРУКТУРЫ

6.1

Требования к наименованиям элементов

6.1.1 Требования к наименованиям доменов

6.1.2 Требования к наименованию участников домена

6.1.3 Требования к адресам электронной почты

6.2

Требования к рабочим местам пользователей

6.2.1 Требования к персональным компьютерам

6.2.2 Требования к системному ПО рабочих мест пользователей

6.2.3 Требования к периферийным устройствам

6.3

Требования к мультисервисной сети

6.3.1 Требования к распределенной мультисервисной сети

6.3.2 Требования к внешним каналам связи

6.4

Прикладное программное обеспечение (ПО)

6.4.1 Общие требования к прикладному ПО

6.4.2 Общие требования к универсальному прикладному ПО

6.4.3 Общие требования к заказному прикладному ПО

6.5

Требования к инфраструктуре центров обработки данных

6.5.1 Требования к системам обработки и хранения данных

6.5.2 Требования к помещениям и инженерным системам

6.6

Требования к обеспечению информационной безопасности

6.7

Требования к обеспечению непрерывности предоставления услуг

6.7.1 План обеспечения непрерывности предоставления услуг и восстановления после

аварии 47

6.8

Требования к системе управления и мониторинга

6.8.1 Общие требования

6.8.2 Требования к структуре СУМ ЦОД I и II уровней

6.8.3 Требования к функциональности СУМ ЦОД I и II уровней

6.8.4 Требования к управлению и мониторингу мультисервисной сети

6.9

Требования к созданию и вводу в действие систем. Требования к

документации

6.9.1 Требования к техническому заданию

6.9.2 Требования к технорабочему проекту

6.9.3 Требования к программам и методикам испытаний

6.9.4 Требования к эксплуатационной документации

6.9.5 Требования к поставке оборудования и ПО

6.9.6 Требования к вводу в действие

7 ПРИЛОЖЕНИЯ

7.1

Приложение 1. Минимальные требования к рабочим местам пользователей

7.1.1 Минимальные требования к характеристикам ПК

7.1.2 Минимальные требования к системному ПО рабочих мест пользователей

7.1.3 Минимальные требования к периферийным устройствам

7.2

Приложение 2. Минимальные требования к мультисервисной сети

7.2.1 Минимальные требования к корпоративной распределенной мультисервисной сети

7.3

Приложение

3. Минимальные требования к инфраструктуре центров

обработки данных

7.3.1 Минимальные требования к системам обработки и хранения данных

7.3.2 Минимальные требования к системному ПО

7.3.3 Минимальные требования к помещениям и инженерным системам

7.4

Приложение

4. Минимальные требования к системе управления и

мониторинга

7.4.1 Требования к размещению системы управления и мониторинга ЦОД I и II уровней

7.4.2 Требования к системам управления и мониторинга ЦОД I и II уровней

7.4.3 Требования к рабочим станциям операторов системы управления и мониторинга

7.4.4 Требования к KVM системам

7.5

Приложение 5. Минимальные требования к документации

7.6

Приложение 6. Классификатор объектов ИКТ-инфраструктуры

7.7

Приложение 7. Таблица транслитерации

7.8

Приложение 8. Каталог рекомендованных конфигураций

7.8.1 Рекомендованная конфигурация аппаратного обеспечения рабочих мест пользователей

(Hardware) - энергоэффектиные конфигурации

7.8.2 Рекомендованная конфигурация аппаратного обеспечения рабочих мест пользователей

(Hardware) - производительные конфигурации

7.8.3 Рекомендованная конфигурация системного ПО рабочих мест пользователей (System

software)

7.8.4 Рекомендованная конфигурация прикладного ПО рабочих мест пользователей (Software)

7.8.5 Средства обеспечения безопасности

7.8.6 Рекомендованные конфигурации периферийных устройств

7.9

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

почты и доменов для государственных учреждений Республики Коми

Используемые термины и сокращения

Термин

Описание

АВР

Автомат выбора резерва

ДМЗ

Демилитаризованная зона

ДЭС

Дизель-генераторные электростанции

ИБП

Источник бесперебойного питания

ИТ

Информационные технологии

ИС

Информационная система

КРК

Каталог рекомендованных конфигураций

ЛВС (LAN)

Локальная вычислительная сеть

МСЭ (firewall)

Межсетевой экран

МФУ

Многофункциональное периферийное устройство

ОИВ

Органы исполнительной власти

ОС

Операционная система

ПК

Персональный компьютер

ПО

Программное обеспечение

РК

Республика Коми

РФ

Российская Федерация

СКС

Структурированная кабельная система

СПД

Система передачи данных

СУБД

Система управления базами данных

СУМ

Система управления и мониторинга

СХД

Система хранения данных

ТЗ

Техническое задание

ЦОД

Центр обработки данных

ЭП

Электронное правительство

API

Application programming interface, интерфейс прикладного программирования

COBIT

Control Objectives for Information and

Related Technology

(«Задачи

информационных и смежных технологий»), результат обобщения мирового

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

управления ИТ, аудита и информационной безопасности

D2D

Disk-to-Disk, технология резервного копирования, когда резервное копирование

выполняется с диска хост системы на диск системы резервного копирования.

Служит для сокращения времени, необходимого для резервного копирования.

D2D2T

Disk-to-Disk-to-Tape, технология резервного копирования, когда резервное

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

копирования, откуда переносится на ленту. Служит для сокращения времени,

необходимого для резервного копирования ввиду медленного ввода/вывода с

ленточных носителей.

DRP

Disaster Recovery Plan, план аварийного восстановления

DRS

Disaster Recovery System, система аварийного восстановления

ERP

Enterprise Resource Planning system, автоматизированная система управления

предприятием

IPMA

International Project Management Association, международная ассоциация по

управлению проектами

ITIL

Information Technology Infrastructure Library,

библиотека

инфраструктуры

информационных технологий. Свод правил и рекомендаций, описывающий

лучшие из применяемых на практике способов организации работы ИТ

подразделений или ИТ компаний

LCR

Least Cost Routing («маршрутизация по критерию наименьшей стоимости»),

технология, обеспечивающая прохождение телефонного вызова от одного

абонента к другому по маршруту, обеспечивающему наименьшую стоимость

телефонного соединения (наименьшую стоимость минуты разговора).

Middleware

Программная среда интеграции приложений

MPLS

Multiprotocol Label Switching, новый стандарт передачи данных в

мультисервисных коммуникационных сетях

MTBF

Mean Time Between Failures, среднее время безотказной работы

NAS

Network Attached Storage, сетевая система хранения данных, сетевое

хранилище.

NGN

Next Generation Network, сеть следующего поколения

OSI

Open Systems Interconnection, модель взаимодействия открытых систем

OSPF

Open Shortest Path First, протокол динамической маршрутизации, основанный

на технологии отслеживания состояния канала

PMI

Project Management Institute, институт управления проектами

QoS

Quality of Service

(«качество сервиса»), способность

коммуникационной

системы обеспечивать то или иное качество услуг в зависимости от вида

передаваемых данных

RPO

Recovery Point Objective, целевая точка восстановления, т.е. момент, до

которого необходимо восстановить данные или, другими словами, это

фактически допустимый объем потерянных данных

RTO

Recovery Time Objective, целевое времени восстановления, т.е. время,

необходимое на восстановление данных

SaaS

Software as a service («Программное обеспечение как услуга»), модель продажи

программного обеспечения, при которой поставщик разрабатывает веб-

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

программному обеспечению через Интернет.

SAN

Storage Area Network, сеть хранения данных

SIP

Session Initiation Protocol, протокол установления сеанса. Стандарт на способ

установления и завершения пользовательского интернет-сеанса, включающего

обмен мультимедийным содержимым (видео- и аудиоконференция)

SNMP

Simple Network Management Protocol,

протокол

управления

сетевыми

устройствами

SOA

Service-Oriented Architecture, сервис-ориентированная архитектура. Модульный

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

сервисов со стандартизированными интерфейсами.

TCO

Total Cost of Ownership, совокупная стоимость владения

VLAN

Virtual Local Area Network, виртуальная локальная сеть

WAFS

Wide-Area File Services, файловые службы для глобальных сетей

Wi-Fi

Wireless Fidelity, технология беспроводных сетей

xWDM

Серия технологий передачи данных по оптическим каналам с уплотнением по

длине волны

1 Общие положения

Внедрение элементов электронного правительства (ЭП) требует оптимальной адаптации

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

в рамках ЭП. Оптимальная адаптация ИТ-инфраструктуры к построению ЭП подразумевает

реализацию синтеза методологических и идеологических основ, заложенных в документе

«Концепция информатизации Республики Коми» и современных направлений развития и

реализация эффективной ИТ-инфраструктуры в ОИВ и иных субъектах, использующих ИТ для

повышения эффективности в своей деятельности. Результатом обозначенного синтеза выступает

документ «Технические и технологические требования к элементам инфраструктуры электронного

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

построению, развитию и интеграции ИТ-инфраструктур различных ОИВ в рамках ЭП.

1.1 Цели и задачи технических и технологических требований к элементам

инфраструктуры электронного правительства в Республике Коми

Целью настоящего документа является описание базисных технических и технологических

принципов построения ИТ-инфраструктуры ОИВ в рамках системы ЭП.

Задачи:

Описание системы категорий и понятий, используемых в рамках ИТ-инфраструктуры ЭП.

Определение принципов экономической эффективности создания, функционирования и

динамического изменения ИТ-инфраструктуры ЭП.

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

развития и интеграции ИТ-инфраструктуры органов исполнительной власти в рамках ЭП.

Выделение формальных механизмов технологического взаимодействия уровней ИТ-

инфраструктуры, а также функционального уровня, необходимых для эффективной

реализации ЭП.

Унификации однородных составляющих различных уровней ИТ-инфраструктуры.

1.2 Нормативно-техническое обеспечение ИТ-деятельности

Технические и технологические требования к элементам инфраструктуры ЭП в РК созданы с

учѐ том нормативных документов Российской Федерации, Республики Коми и ГАУ РК ЦИТ.

Нормативные правовые акты Российской Федерации:

Стратегия развития информационного общества в Российской Федерации утверждена

Президентом РФ 7 февраля 2008 г; Федеральный закон от 27 июля 2010 года № 210-ФЗ

«Об организации предоставления государственных и муниципальных услуг»;

Федеральный закон от 9 февраля 2009 года № 8-ФЗ «Об обеспечении доступа к

информации о деятельности государственных органов и органов местного

самоуправления»; Федеральный закон от 27 июля 2006 года № 149-ФЗ «Об информации,

информационных

технологиях и о защите информации»; Федеральный закон от 27 июля 2006

года № 152-ФЗ «О персональных данных»;

Федеральный закон от 10 января 2002 г. № 1-ФЗ «Об электронной цифровой подписи»;

Концепция создания и развития инфраструктуры пространственных данных Российской

Федерации одобрена распоряжением Правительства Российской Федерации от 21 августа

2006 г. № 1157-р;

Федеральная целевая программа «Электронная Россия (2002-2010 годы)» утверждена

Постановлением Правительства Российской Федерации от 28 января 2002 г. № 65;

Типовая программа развития и использования информационных и телекоммуникационных

технологий субъекта Российской Федерации утверждена распоряжением Правительства

Российской Федерации от 3 июля 2007 года № 871-р;

Постановление Правительства Российской Федерации от 28 сентября 2010 г. № 764 «Об

утверждении Правил осуществления контроля за соблюдением субъектами естественных

монополий стандартов раскрытия информации»; Постановление Правительства

Российской Федерации от 8 сентября 2010 г. № 697 «О

единой системе межведомственного электронного взаимодействия»; Постановление

Правительства Российской Федерации от 24 мая 2010 г. № 365 «О

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

технологий в деятельности государственных органов»; Постановление Правительства от

25 декабря 2009 г. № 1088 «О единой вертикально

интегрированной государственной автоматизированной информационной системе

«Управление»; Постановление Правительства Российской Федерации от 3 октября 2009 г.

№ 796 «О

некоторых мерах по повышению качества предоставления государственных

(муниципальных) услуг на базе многофункциональных центров предоставления

государственных (муниципальных) услуг»; Постановление Правительства Российской

Федерации от 15 июня 2009 г. № 478 «О единой

системе информационно-справочной поддержки граждан и организаций по вопросам

взаимодействия с органами исполнительной власти и органами местного самоуправления

с использованием информационно-телекоммуникационной сети Интернет»; Постановление

Правительства Российской Федерации от 25 декабря 2007 г. № 931 «О некоторых мерах по

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

местного самоуправления при оказании государственных услуг гражданам и

организациям»; Постановление Правительства Российской Федерации от 6 ноября 2007 г.

№ 758 «О

государственной аккредитации организаций, осуществляющих деятельность в области

информационных технологий»; Постановление Правительства Российской Федерации от

29 декабря 2007 года № 947 «Об

утверждении Правил разработки, апробации, доработки и реализации типовых

программно-технических решений в сфере региональной информатизации»; Распоряжение

Правительства Российской Федерации от 17 декабря 2009 года № 1993-р «Сводный

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

органами исполнительной власти субъектов Российской Федерации и органами местного

самоуправления в электронном виде, а также услуг, предоставляемых в электронном виде

учреждениями субъектов Российской Федерации и муниципальными учреждениями»;

Доктрина информационной безопасности Российской Федерации от 9 сентября 2000 г. №

Пр-1895

Нормативные правовые акты Республики Коми:

Постановление Правительства Республики Коми от 21.05.2010 г. № 148 «О

Координационном совете по развитию информационного общества и формированию

электронного правительства в Республике Коми»; Постановление Правительства

Республики Коми от 24 сентября 2007 г. № 222 «Об официальном интернет-портале

Республики Коми»;

Постановление Правительства Республики Коми от 23.04.2010 г. N 110 «О портале и

реестре государственных услуг (функций)»; Распоряжение Правительства Республики

Коми «Об определении государственного органа

Республики Коми, ответственного в целом за координацию работ по разработке,

утверждению и контролю за исполнением мероприятий по развитию информационного

общества и формированию электронного правительства на трехлетний период»;

Распоряжение Правительства Республики Коми от 16.08.2010г. №361-р «Об утверждении

Концепции информатизации Республики Коми»; Распоряжение Правительства Республики

Коми от 08 октября 2010 № 463-р «Об

организации предоставления государственных и муниципальных услуг»; Закон Республики

Коми от 29.09.2010 №94-РЗ «О государственных информационных системах Республики

Коми».

Распоряжение Правительства Республики Коми от 24.11.2010 г. № 518-р «Об утверждении

Плана мероприятий по развитию информационного общества и формированию

электронного правительства Республики Коми на 2010 -2012 годы»

Постановление Правительства Республики Коми от 30.12.2010 г. № 499 «О Порядке

организации работ по подготовке, реализации и контролю исполнения плана мероприятий

по развитию информационного общества и формированию электронного правительства в

Республике Коми» Постановление Правительства Республики Коми от 21.03.2011 г. № 60

«О корпоративной

информационно-телекоммуникационной сети органов исполнительной власти Республики

Коми, государственных органов Республики Коми, образованных Главой Республики Коми

или Правительством Республики Коми, государственных учреждений Республики Коми»

Технические и технологические требования к элементам инфраструктуры ЭП в РК развивают

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

рекомендации по вопросам развития ИТ-инфраструктуры;

требования к типизации и унификации ИТ-инфраструктуры;

требования к поставщикам ИТ продукции и услуг; требования к

элементам ИТ-инфраструктуры и их размещению;

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

систем (ГосИС РК); перечень рекомендуемых технических параметров оборудования и

конфигурационных

решений (Приложения к настоящему документу).

2 Современные тенденции в области ИТ

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

вычислительными средами предполагают отказ от понятий «отдельный компьютер», «программа»

или «программно-аппаратный комплекс». Вместо этого современный подход оперирует понятиями

«ИТ-сервис»

(информационная система) и

«ИТ-ресурсы». С точки зрения данного подхода,

основные задачи, стоящие перед современными ИТ-подразделениями - это:

построение ИТ-инфраструктуры, ориентируясь на требования функциональных

заказчиков; сохранение и повышение качества предоставляемых ИТ-сервисов;

обеспечение безопасности функционирования ИТ-сервисов; обеспечение непрерывности

функционирования ИТ-сервисов;

сокращение общей стоимости владения ИТ (далее TCO).

При построении ИТ-инфраструктуры рекомендуется использовать следующие современные

подходы и технологии:

консолидацию ресурсов;

виртуализацию ресурсов;

современную архитектуру приложений;

модель SaaS;

средства интеграции приложений; современную

коммуникационную инфраструктуру.

2.1 Консолидация ресурсов

Современная ИТ-инфраструктура и, прежде всего, коммуникационная среда создают предпосылки

для консолидации приложений и данных в современных Центрах Обработки Данных (ЦОД).

Данная модель построения ИТ-инфраструктуры обеспечивает более высокую:

эффективность за счет снижения ТСО (прежде всего затрат на обслуживание и

сопровождение ИТ систем и снижения капитальных затрат на обеспечивающую

инфраструктуру); непрерывность (доступность) приложений за счет более высокой степени

резервирования

и отказоустойчивости программно-аппаратных средств, применяемых в ЦОД.

При построении и модернизации ИТ-инфраструктуры рекомендуется рассматривать четыре вида

консолидации ресурсов:

1. Централизация — консолидация географически распределенных серверов в одном или

нескольких ЦОД.

2. Консолидация данных

— консолидация баз данных и/или устройств хранения для

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

3. Физическая консолидация — объединение серверов под управлением одной и той же ОС и

с подобными приложениями, на более мощных системах.

4. Консолидация приложений и хранилищ данных — размещение различных приложений на

мощных серверах с разделяемыми разделами, либо на системах виртуализации.

Практика показывает, что TCO консолидированных решений значительно ниже, чем стоимость

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

2.2 Виртуализация ресурсов

Виртуализация — процесс представления набора вычислительных ресурсов, или их логического

объединения, который даѐ т какие-либо преимущества перед оригинальной конфигурацией. Это

новый,

«виртуальный» взгляд на ресурсы, не ограниченных реализацией, географическим

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

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

Виртуализация — это общий термин, охватывающий абстракцию ресурсов для многих аспектов

вычислений. Типы виртуализации:

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

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

общему пулу аппаратных ресурсов; Аппаратная виртуализация позволяет выделить

виртуальной машине нужные

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

устройств.

Области применения виртуализации:

Виртуализация на уровне ОС: виртуализирует физический сервер на уровне ОС, позволяя

запускать изолированные и безопасные виртуальные серверы на одном физическом

сервере. Эта технология не позволяет запускать ОС с ядрами, отличными от типа ядра

базовой ОС. При виртуализации на уровне ОС не существует отдельного слоя

гипервизора. Вместо этого сама хостовая ОС отвечает за разделение аппаратных

ресурсов между несколькими виртуальными серверами и поддержку их независимости друг

от друга; Виртуальные машины: окружение, которое представляется для «гостевой» ОС,

как

аппаратное. Однако на самом деле это программное окружение, которое эмулируется

программным обеспечением хостовой системы. Эта эмуляция должна быть достаточно

надѐ жной, чтобы драйверы гостевой системы могли стабильно работать. При

использовании паравиртуализации, виртуальная машина не эмулирует аппаратное

обеспечение, а, вместо этого, предлагает использовать специальный интерфейс

прикладного программирования (API);

Виртуализация ресурсов: разделение одного физического сервера на несколько частей,

каждая из которых видна для владельца в качестве отдельного сервера. Не является

технологией виртуальных машин, осуществляется на уровне ядра ОС; Виртуализация

приложений: процесс использования приложения преобразованного из

требующего установки в ОС в не требующий этого. Для виртуализации приложений

программное обеспечение виртуализатора определяет при установке виртуализуемого

приложения, какие требуются компоненты ОС и их эмулирует, таким образом, создаѐ тся

необходимая специализированная среда для конкретно этого виртуализируемого

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

Понятие «виртуальные машины» предполагает разделение на:

Виртуализацию серверов: размещение нескольких логических серверов в рамках одного

физического (консолидация); объединение нескольких физических серверов в один

логический для решения определенной задачи; Виртуализацию рабочих станций:

использование на рабочем месте «тонких» клиентов,

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

для каждого клиента виртуализированной ОС.

Основные предпосылки применения технологий серверной виртуализации следующие:

неуклонное повышение мощности единичного сервера, зачастую превышающее

потребности конкретного приложения; аппаратная поддержка виртуализации в

современных процессорах;

большое число наследуемых приложений на устаревающих ОС и аппаратных платформах;

тенденции к консолидации ИТ-инфраструктуры.

Рекомендуется использовать технологии и средства виртуализации ИТ-ресурсов при построении

ИТ-инфраструктуры.

2.2.1 Логическое деление вычислительных комплексов

Технология аппаратных и программных разделов (partitioning)- это архитектурный подход к ИТ-

инфраструктуре, позволяющий виртуализировать аппаратные ресурсы и сделать их доступными

для множества независимых операционных сред. Изначально разработанная для mainframe,

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

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

различиями поддерживается ведущими производителями ИТ-оборудования. Технология

логического деления вычислительных комплексов в сочетании с планами восстановления после

сбоев и восстановления после катастроф (DRS и DRP) и с использованием двух разнесенных ЦОД

(основного и резервного), создают основу катастрофоустойчивой инфраструктуры таким образом,

что приложение и разделы с критическими приложениями, выполняемые в основном ЦОД, могут

переключаться на резервный ЦОД с минимальными потерями.

Современные системы виртуализации позволяют создание кластеров высокой готовности,

позволяющие перемещать сервисы

(виртуальные машины) между узлами

(аппаратными

серверами) для распределения нагрузки единичного узла и для обеспечения функционирования

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

с целью обеспечения высокой доступности сервисов.

2.3 Современная архитектура приложений

Рекомендуется отдавать предпочтение ИТ-решениям, имеющим современную, сервис-

ориентированную многоуровневую архитектуру.

2.3.1 Сервис-ориентированная архитектура - SOA

Наиболее перспективная архитектура построения приложений на настоящее время - Service

Oriented Architecture

(SOA

- сервис-ориентированная архитектура). Основная задача SOA

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

поколений. Архитектура SOA независима от языков программирования, платформ или

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

с помощью чего они развернуты. Практически архитектура SOA требует наличия не только

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

также множества компонентов, таких, как: серверы приложений, связующее ПО, репозиторий и

даже специализированные пакеты централизованного управления SOA.

2.3.2 Многоуровневая архитектура клиент-сервер

Клиент-сервер — вычислительная или сетевая архитектура, в которой задания или сетевая

нагрузка распределены между поставщиками услуг (сервисов), называемыми серверами, и

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

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

обеспечением.

В настоящее время большинство ИС проектируются с использованием трехуровневой архитектуры

«клиент-сервер», представляющей ИС в виде совокупности трех компонент: сервера баз данных,

сервера приложений, отвечающего за выполнение логики приложения, и клиентского приложения

или клиентского интерфейса («тонкий клиент»). Основными преимуществами выделения логики

приложения в отдельную составляющую являются возможность повторного использования кода,

легкость

модификации

централизованно

развѐ рнутых

компонентов,

повышение

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

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

того, системы, построенные в трехуровневой архитектуре, существенно проще и дешевле в

эксплуатации, т.к. все исправления и конфигурационные настройки вносятся централизованно.

Составляющие трехуровневой архитектуры:

уровень представления (реализующий функции ввода и отображения данных); прикладной

уровень (реализующий универсальные сервисы, а также функции, специфичные для

определенной предметной области);

уровень доступа к информационным ресурсам (реализующий фундаментальные функции

хранения и управления информационно-вычислительными ресурсами).

2.4 Модель SaaS

Программное обеспечение как услуга (software as a service, сокр. SaaS) - модель использования

программного обеспечения, при которой поставщик разрабатывает веб-приложение и

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

преимущество модели SaaS для пользователя состоит в отсутствии затрат, связанных с

установкой, обновлением и поддержкой работоспособности оборудования и работающего на нѐ м

ПО. Использование SaaS предпочтительней как более дешевая и простая альтернатива

внутренним информационным ресурсам.

2.5 Средства интеграции приложений (middleware)

Для построения интегрированной ИТ инфраструктуры, особенно при использовании различных

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

средства - Интеграционные платформы. Интеграционная платформа должна обеспечивать доступ

в реальном масштабе времени к различным информационным ресурсам, обмен и синхронизацию

данных между ними, автоматически, по заданным правилам и расписанию - поддержку единого

стандарта обмена информацией между приложениями, независимо от платформ, на которых они

существуют.

Базовые функциональные возможности должны включать в себя средства проверки корректности,

очистки, объединения структурированных и неструктурированных данных, репликации данных и

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

Продукты такого типа, как правило, строятся на принципах сервис-ориентированной архитектуры и

предназначены для решения задач обеспечения достоверности информации в масштабе

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

управления метаданными.

Применение данных технологий позволяет, с помощью соответствующих сервисов,

предоставляемых приложениям, процессам и отдельным пользователям, быстро сопоставить,

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

2.6 Современная коммуникационная инфраструктура

Для построения сетей передачи данных рекомендуется применять технологии построения

виртуальной частной сети на базе MPLS/VPN, с использованием услуг, предоставляемых

крупными телекоммуникационными операторами национального масштаба. При необходимости,

резервирование каналов осуществляется телекоммуникационными операторами, в том числе, с

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

телекоммуникационного оператора необходимо предусмотреть наличие резервного канала с

возможностью переключения на него в случае недоступности основного.

Построение внутренней сетевой инфраструктуры рекомендуется производить на базе

современных принципов построения сети, обеспечивающих гарантированное качество сетевых

услуг (QoS).

Архитектура таких сетей состоит из четырех основных компонентов, а именно:

1. Интеллектуальная сетевая инфраструктура на базе протокола IР;

2. Интеллектуальные клиентские места с поддержкой протокола IР;

3. Служебные серверные приложения;

4. Современные пользовательские приложения.

Основа архитектуры

- ее распределенная природа, благодаря которой система легко

масштабируется. За счет этого, сетью на базе данной архитектуры можно охватить одно здание

или несколько стоящих рядом зданий, объединенных высокоскоростной локальной сетью,

предоставить в сети сервисы телефонии и данных для пользователей удаленных офисов и

подразделений, объединенных IР сетью.

Защита данных в сетях передачи данных, как во внутренних, так и во внешних, должна строиться в

соответствии с «Требованиями к информационной безопасности электронного правительства в

Республике Коми».

3 Рекомендации по управлению ИТ инфраструктурой

3.1 Необходимость изменений в ИТ-инфраструктуре

При решении задач управления ИТ-инфраструктурой существенное значение имеют процессы,

связанные с изменениями ИТ-инфраструктуры. Технические решения, связанные с изменениями

ИТ-инфраструктуры, должны быть обоснованы, в том числе, с учетом оценки их влияния на

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

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

3.2 Рекомендации по проведению изменений в ИТ инфраструктуре

Процесс по проведению изменений в ИТ-инфраструктуре

- это процесс использования

стандартизированных методов и процедур для эффективного и своевременного проведения

изменений в ИТ-инфраструктуре с минимальными негативными последствиями для деловых

процессов.

При изменении ИТ-инфраструктуры необходимо учитывать следующие требования:

Общие требования к тестированию и приемке изменений; Требований «разумного

консерватизма» при внедрении новых версий ИТ-компонентов; Требований

автоматизации тиражирования обновлений ПО; Обязательное документирование

вносимых изменений.

3.2.1 Общие требования к тестированию и приемке изменений

Процесс тестирования и приемки изменений ИТ-инфраструктуры должен

удовлетворять следующим общим требованиям:

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

согласованию с функциональными заказчиками. Служба заказчика вправе разработать

упрощенный порядок принятия решений о проведении некритичных для деловых

процессов изменений; Перед вводом изменений в эксплуатацию необходимо разработать

и протестировать план

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

отказе от внесенных изменений и возврате системы в предыдущее состояние.

Тестирование плана внесения изменений необходимо производить в среде, аналогичной

производственной; Тестирование и приѐ мку изменений необходимо производить в среде,

аналогичной производственной;

Ввод изменений в эксплуатацию предваряется резервным копированием всех элементов

системы, подвергшихся изменению.

3.2.2 Требования «разумного консерватизмаª

При внедрении, модернизации, обновлении ИТ-компонентов должны быть соблюдены следующие

общие требования «разумного консерватизма»:

внедрение новых версий ПО должно иметь обоснованные преимущества перед

используемыми версиями ПО и не должно ухудшать текущего состояния дел; для

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

промышленного ПО и/или его компонентов, за исключением используемых в схожей

промышленной среде более 2 лет и имеющих при этом не менее 2 корректирующих

обновлений от производителя (релизов, патчей, сервис-паков, обновлений ПО и т.п.);

недопустимо использование тестовых версий ИТ-компонентов (альфа, бета версии ПО и

т.п.) в режиме промышленной эксплуатации; при планировании внедрения новых версий

ПО рекомендуется учитывать долгосрочные

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

ПО в промышленную эксплуатацию обязательно

тщательное тестирование функционирования соответствующей системы, с заключениями

соответствующих ключевых специалистов.

3.2.3 Автоматизация тиражирования обновлений ПО

Автоматизация тиражирования обновлений ПО должна выполняться с учетом следующих общих

требований и рекомендаций:

при выборе ПО, при прочих равных функциональных характеристиках, преимущество

следует отдавать системам, имеющим службы централизованного управления и

обновления; создание и внедрение решения по автоматизации тиражирования обновлений

ПО должно

производиться в рамках отдельных проектов ИТ-службы и с использованием собственной

серверной системы тиражирования обновлений. Обновление ПО непосредственно с

Интернет-портала производителя не допускается; функциональные возможности

автоматизированной системы тиражирования обновлений

должны позволять реализацию полного и упрощенного циклов управления изменениями,

проводить автоматическую проверку (аудит) тиражирования обновлений; тиражирование

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

(обновления ОС, ПО с непосредственным доступом во внешние сети / Интернет,

антивирусные системы и т.п.) подлежит обязательной автоматизации; тиражирование

обновлений в области безопасности на рабочие станции и

инфраструктурные ИТ-компоненты (домен-контроллеры, DNS/DHCP/mail-сервера и т.п.) в

части системного и офисного ПО подлежит обязательной автоматизации;

обновление инфраструктурного ПО

(домен-контроллеры, DNS/DHCP/mail-сервера),

включающего смену функциональности, смену версии используемого ПО, за исключением

обновлений в области безопасности, необходимо проводить под контролем

соответствующего специалиста, предварительно проведя тестирование в тестовой среде,

аналогичной производственной;

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

приложений; перед масштабным тиражированием обновлений необходимо провести

тестирование в

локальной тестовой среде.

3.3 Рекомендации по планированию ИТ-инфраструктуры

При планировании ИТ-инфраструктуры должен быть обеспечен экономически обоснованный

уровень соответствия ресурсов ИТ-инфраструктуры текущим и будущим потребностям

потребителей. Для эффективного планирования ИТ-инфраструктуры необходимо учитывать

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

каждого потребителя, важное значение имеет выбор горизонтов планирования для различных ИТ-

приложений и определение базовой методики расчета производительности и объема хранимой

информации для ИТ-систем.

3.3.1 Рекомендации по выбору горизонтов планирования для ИТ-приложений

Выбор горизонтов планирования ИТ-приложений должен определяться горизонтом планирования

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

горизонт планирования ИТ-приложений.

Рекомендуется исходить из следующих горизонтов планирования ИТ-приложений:

8-9 лет для приложений класса ERP и приложений управления ИТ, критичных для деловых

процессов; 5-6 лет для деловых приложений и систем операционного управления ИТ;

3-5 лет для офисных и системных приложений.

При этом для соответствующих элементов ИТ инфраструктуры рекомендуется установить

следующие горизонты планирования:

5-6 лет для приложений класса ERP и приложений управления ИТ, критичных для деловых

процессов; 3-4 года для деловых приложений и систем операционного управления ИТ;

2-3 года для офисных и системных приложений.

3.3.2 Рекомендации по расчету производительности и объема хранимой

информации для ИТ-систем (масштабирование ИТ-систем)

Расчѐ т производительности ИТ-систем должен производиться в терминах ИТ-услуг, исходя из

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

уровня предоставления и производительности услуг.

При расчѐ те производительности подлежат учѐ ту нагрузочные возможности всех

задействованных в предоставлении ИТ-услуг компонентов: ИТ-услуг, ИТ-систем, компонентов

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

При расчѐ те производительности ИТ-систем обязателен учѐ т как средних, так и пиковых

показателей нагрузки. Рекомендуется для расчѐ та производительности использовать

предоставляемый производителем инструментарий

- нагрузочные кривые и разработанные

лучшие методики (bestpractices).

В общем случае, в ходе расчѐ та рекомендуется проводить оценку загрузки по следующим

компонентам:

сервер приложений;

сервер баз данных;

серверные средства информационной безопасности (антивирусное обеспечение,

программный МСЭ, криптографические системы и т.п.);

компоненты мониторинга (агенты и

т.п.); системное ПО;

аппаратная платформа (процессоры, оперативная память, дисковая подсистема, сетевой

интерфейс);

сети хранения данных (SAN, NAS);

сети передачи данных, включая активные устройства (МСЭ, маршрутизаторы и т.п.);

сетевые сервисы (сервисы каталога, DNS, DHCPи т.п.);

клиентские рабочие станции в аппаратной и программной части.

Для оценки объѐ ма хранимой информации рекомендуется использовать собственные

статистические данные по объѐ мам и динамике изменения данных за длительные (от 1 месяца)

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

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

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

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

Последний показатель следует корректировать в ходе последующей эксплуатации систем.

При оценке объѐ ма хранимой информации обязателен учѐ т не только полезного объѐ ма, но и

объѐ мов системной и служебной информации (системы шифрования, файлы логирования, файлы

журналов транзакций и т.п.)

4 Каталогизация

классификация

элементов

ИТ-

инфраструктуры

4.1 Типизация элементов ИТ-инфраструктуры

Унификация и типизация элементов ИТ-инфраструктуры способна значительно снизить расходы и

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

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

снизить общую стоимость владения ИТ- инфраструктурой в целом.

Под типизацией понимается снижение номенклатуры и повышение качества ИТ-элементов и

конфигураций, внедряемых в органах государственной власти РК.

Данные Технические требования в области ИТ выдвигают требования к следующим категориям ИТ

инфраструктуры:

рабочим местам пользователей (ПК, периферийное оборудование);

мультисервисной сети

(корпоративная сеть, внешние каналы

связи); прикладному ПО;

инфраструктуре центров обработки данных (системы хранения и резервирования,

серверы);

Общие требования к указанным категориям и их отдельным элементам приведены в главе 6

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

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

В приложениях к данному документу приведены рекомендуемые минимально допустимые

технические требования к соответствующим категориям. При развитии ИТ-инфраструктуры

органов государственной власти РК, государственных учреждений РК необходимо учитывать

данные рекомендации. Также данные рекомендации, необходимо учитывать при разработке и

внедрении Каталогов Рекомендованных Конфигураций в ЦИТ.

При построении современной ИТ-инфраструктуры для определения места установки (размещения)

ИТ-решения необходимо провести классификацию данного решения в зависимости от

совокупности следующих параметров: состава пользователей данной системы, степени агрегации

информации, хранения и обработки данных; решаемых задач; уровня сложности и т.д.

С точки зрения данной классификации рекомендуется выделить следующие классы или уровни

инфраструктуры для размещения ИТ-систем:

Центр обработки данных - ЦОД I уровня, (уровень Правительства РК, ЦИТ) - обеспечивает

централизованное хранение и обработку данных на уровне Правительства РК. Ресурсы

данного ЦОД используются для консолидации информации с нижележащих уровней,

обеспечения информационного взаимодействия органов государственной власти РК и

оказания ИТ-сервисов всем организациям, финансируемым из республиканского бюджета

РК.

Центр обработки данных - ЦОД II уровня, основной центр хранения и обработки данных в

рамках одного органа государственной власти РК. Услугами данного ЦОД пользуется

большинство сотрудников данного ОГВ и государственных учреждений.

В разделе «6.5. Требования к инфраструктуре центров обработки данных (системы хранения и

резервирования, серверы)» содержатся общие требования к оборудованию ЦОД различного

уровня. Кроме того, в приложениях к данному документу приведены текущие рекомендованные

минимальные требования к ИТ-конфигурациям и их элементам

(программно-аппаратным

средствам, системам связи и коммуникаций). ИТ-конфигурации с заявленными характеристиками

ниже приведенных минимальных значений не рекомендуется закупать и вводить в эксплуатацию в

органах государственной власти РК, государственных учреждений РК.

4.2 Классификация государственных информационных систем

К основным направлениям информатизации в РК относятся следующие группы ИС:

Информационные системы поддержки хозяйствующих субъектов

Информационные системы управления социальной сферой

Информатизация процессов управления в социальной сфере ориентирована, прежде всего, на

внедрение экономических механизмов и ИТ, направленных на:

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

предотвращение социального иждивенчества; расширение рынка и повышение

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

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

социальными услугами.

Системы:

информатизация деятельности территориальных служб социальной защиты

населения; информатизация деятельности центров занятости населения РК;

информатизация деятельности миграционных служб;

информатизация управления потребительским рынком;

информатизация системы образования;

информатизация системы здравоохранения;

информатизация в сфере культуры.

Информатизация деятельности органов исполнительной власти РК.

Анализ основных направлений деятельности органов исполнительной власти РК позволяет

выделить следующие направления информатизации:

Информационные системы предоставления государственных услуг предназначены для

повышения качества и доступности предоставляемых государственных услуг,

упрощения процедур и сокращения сроков их оказания, повышения открытости

информации о деятельности органов государственной власти и органов местного

самоуправления.

Информационные системы электронного правительства. ИС ЭП обеспечивают

переход к новой форме организации деятельности органов государственной власти и

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

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

услуг, а также информации о результатах деятельности органов власти.

Информатизация учрежденческой деятельности органов исполнительной власти;

Информационная поддержка деятельности по вопросам управления

государственной собственностью; Информатизация экономической деятельности

и финансово-кредитного комплекса Республики Коми;

Информатизация международных связей и внешнеэкономической деятельности

Правительства Республики Коми; Информатизация процессов управления по

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

Информатизация органов законодательной и представительной власти РК.

Информатизация законодательной и представительной власти РК проводится в следующих

направлениях:

информационная поддержка проведения заседаний Государственного Совета РК,

информационная поддержка законотворческой деятельности депутатов и депутатских

комиссий; информационная поддержка текущей деятельности депутатов;

информационная поддержка геополитического и социально-экономического

мониторинга РК.

Информационные системы природопользования и охраны окружающей среды

Информатизация процессов эффективного использования природных ресурсов

(природопользования) и охраны окружающей среды направлена на создание необходимых

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

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

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

Направлениями информатизации процессов управления природопользованием и охраной

окружающей среды являются:

информатизация процессов управления использованием минерально-сырьевых

ресурсов; информатизация процессов управления использованием лесных ресурсов;

информатизация процессов управления использованием водных ресурсов;

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

информатизация процессов регулирования в области обращения с отходами.

Информационные системы органов местного самоуправления

Можно выделить следующие основные типовые направления информатизации

органов местного самоуправления:

информатизация финансово-кредитной деятельности;

информационная поддержка управления имуществом;

информационная поддержка управления потребительским рынком;

информатизация процессов социального развития территории;

информатизация процессов градостроительства; информационная

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

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

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

4.3 Классификация по уровню требуемой непрерывности обслуживания

Многие критические управленческие и технологические процессы опираются на компьютерные

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

Поэтому, обеспечение непрерывности обслуживания и доступности ИТ-решений является

важнейшим показателем непрерывности государственного управления в целом, и важным

классифицирующим фактором для элементов ИТ-инфраструктуры. Исходя из предъявляемых

требований к надежности отдельных элементов и конфигураций ИТ-систем в целом и их

восстановлению после сбоев и отказа оборудования, ПО или инфраструктурных элементов,

современные ИТ-технологии предоставляют различные архитектурные и конфигурационные

решения, обеспечивающие данные требования. С точки зрения обеспечения непрерывности

обслуживания управленческих и технологических пользователей и процессов, а также требований

к отказоустойчивости, можно предложить следующую классификацию ИТ-решений:

Mission Critical - системы, работающие в режиме «боевого дежурства». К таким системам

относятся: остро критические с точки зрения государственного управления или внешних

факторов

- например экологии, приложения, а также технологические приложения,

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

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

населения. Рекомендованное время восстановления подобных систем после отказа менее

10 минут. Для таких систем должны использоваться специализированные серверные

платформы и инфраструктурные уровни с полным многократным резервированием всех

компонентов, в том числе с использованием резервных удаленных ЦОД;

Business Critical - системы, критические для управления, с режимом работы 24х7х365.

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

Рекомендованное время восстановления подобных систем после отказа менее 2 часов.

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

уровни с частичным резервированием используемых инфраструктурных компонентов;

Business Operational - обычные деловые приложения - системы, не требующие работы в

реальном времени, с режимом работы 8х5. Рекомендованное время восстановления

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

резервирование хранения данных и электропитания;

Office Production - не критические для управления приложения, персональные данные.

Рекомендованное время восстановления подобных систем после отказа 1-2 рабочих дня.

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

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

аппаратных, программных средств и инфраструктуры, необходимой для ее успешного

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

уровня непрерывности и отказоустойчивости его слабейшего компонента

(принцип

«слабого

звена»). Классификация систем с точки зрения обеспечения непрерывности и отказоустойчивости

должна быть одним из решающих факторов при выборе уровня инфраструктуры (ЦОД) для

размещения ИТ-систем. В разделе «6.5. Требования к инфраструктуре центров обработки данных

(системы хранения и резервирования, серверы)» содержатся общие требования к таким

конфигурациям в разрезе ЦОД различного уровня.

4.4 Принципы создания КРК

Основная цель создания КРК - провести унификацию используемого оборудования и ПО, и

обеспечить целостность и управляемость ИТ-инфраструктуры органов государственной власти РК,

государственных учреждений РК.

При построении и развитии своей ИТ-инфраструктуры все органы государственной власти РК,

государственные учреждения РК должны закупать и внедрять только внесенные в каталог ИТ-

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

исключения.

Унификация ИТ-решений, используемых в рамках конкретного органа государственной власти

позволит добиться снижения общего TCO, что подразумевает снижение расходов на закупки,

внедрение и эксплуатацию элементов ИТ- инфраструктуры.

Каталог создается в каждом органе государственной власти РК и должен содержать следующий

минимальный набор данных о рекомендованной конфигурации:

название конфигурации; класс объекта (функциональный раздел каталога) в соответствии

с приложением - «7.6

Приложение 6. Классификатор объектов ИКТ-инфраструктуры»;

класс конфигурации по уровню использования;

класс конфигурации по уровню непрерывности;

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

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

Для каждой позиции данного каталога необходимо выбрать конкретных производителей и

конкретный перечень моделей их оборудования или ПО, принимая во внимание рекомендации к

требованиям к элементам ИТ-инфраструктуры, приведенные в главе 6 и Приложениях к данному

документу.

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

конфигураций необходимо использовать данные Приложений 2-6 к настоящему документу.

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

следующими основными принципами:

Все конфигурации, включаемые в каталог, должны соответствовать общим требованиям к

оборудованию и ПО, изложенным в главе 6 настоящего документа; В качестве

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

параметров конфигураций необходимо использовать данные Приложений 2-6 к

настоящему документу; Количество унифицированного оборудования и ПО в каждом

функциональном разделе каталога должно быть минимально;

Рекомендуется использовать стандартное оборудование и ПО зарекомендовавшего себя

на рынке производителя в данной области, который постоянно развивает и

совершенствует свой модельный ряд; Каталог должен регулярно (не реже чем раз в год)

пересматриваться и обновляться;

Рекомендуется использовать сложное аппаратно-программное обеспечение разного

назначения одного и того же производителя. Такое решение упрощает управление ИТ-

инфраструктурой, позволяет снизить эксплуатационные затраты, а также стоимость вновь

приобретаемого аппаратно-программного обеспечения; Для массовых, стандартных ИТ-

конфигураций и их элементов рекомендуется включать в

каталог решения не менее чем двух альтернативных производителей.

4.5 Документы, рекомендованные к разработке в органах государственной

власти Республики Коми

1. Технические требования в области ИТ органа государственной власти РК,

государственного учреждения РК;

2. Каталог рекомендованных конфигураций;

3. Периодичность обслуживания МФУ;

4. Требования к информационной безопасности;

5. Требования к резервному копированию;

6. План обеспечения непрерывности предоставления услуг и восстановления после аварии.

5 Требования к поставщикам, производителям и проведению

конкурсов

В соответствии со статьей 11 Федерального закона № 94-ФЗ «О размещении заказов на поставки

товаров, выполнение работ, оказание услуг для государственных и муниципальных нужд» к

участникам размещения заказа могут быть установлены следующие требования:

1. соответствие участников размещения заказа требованиям, устанавливаемым в

соответствии с законодательством Российской Федерации к лицам, осуществляющим

поставки товаров, выполнение работ, оказание услуг, являющихся предметом торгов;

2. непроведение ликвидации участника размещения заказа - юридического лица и отсутствие

решения арбитражного суда о признании участника размещения заказа - юридического

лица, индивидуального предпринимателя банкротом и об открытии конкурсного

производства;

3. неприостановление деятельности участника размещения заказа в порядке,

предусмотренном Кодексом Российской

Федерации об административных

правонарушениях, на день подачи заявки на участие в конкурсе или заявки на участие в

аукционе;

4. отсутствие у участника размещения заказа задолженности по начисленным налогам,

сборам и иным обязательным платежам в бюджеты любого уровня или государственные

внебюджетные фонды за прошедший календарный год, размер которой превышает

двадцать пять процентов балансовой стоимости активов участника размещения заказа по

данным бухгалтерской отчетности за последний завершенный отчетный период. Участник

размещения заказа считается соответствующим установленному требованию в случае,

если он обжалует наличие указанной задолженности в соответствии с законодательством

Российской Федерации и решение по такой жалобе на день рассмотрения заявки на

участие в конкурсе или заявки на участие в аукционе не принято.

При размещении заказа путем проведения торгов заказчик, уполномоченный орган вправе

установить также следующие требования к участникам размещения заказа:

1. обладание участниками размещения заказа исключительными правами на объекты

интеллектуальной собственности, если в связи с исполнением контракта заказчик

приобретает права на объекты интеллектуальной собственности, за исключением случаев

размещения заказа на создание произведения литературы или искусства (за исключением

программ для ЭВМ, баз данных), исполнения, на финансирование проката или показа

национального фильма;

2. отсутствие в предусмотренном Федеральным законом реестре недобросовестных

поставщиков сведений об участниках размещения заказа.

Кроме указанных требований, заказчик, уполномоченный орган не вправе устанавливать иные

требования к участникам размещения заказа.

В соответствии со статьей 34 вышеуказанного закона, не допускается включать в документацию об

аукционе (в том числе в форме требований к качеству, техническим характеристикам товара,

работ, услуг, требований к функциональным характеристикам

(потребительским свойствам)

товара) требования к производителю товара, к участнику размещения заказа

(в том числе

требования к квалификации участника размещения заказа, включая наличие у участника

размещения заказа опыта работы), а также требования к его деловой репутации, требования о

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

оборудования, трудовых, финансовых и других ресурсов, необходимых для производства товара,

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

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

к участнику размещения заказа предусмотрена настоящим Федеральным законом.

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

включение в документацию об аукционе только требований о наличии лицензии, в случае, если

деятельность подлежит лицензированию в соответствии с действующим законодательством.

В документацию необходимо включать требования к качеству, техническим характеристикам

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

(потребительским свойствам) товара, к размерам, упаковке, отгрузке товара, и иные показатели,

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

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

документов, подтверждающих соответствие товара, установленным в соответствии с

законодательством Российской Федерации, если в соответствии с законодательством Российской

Федерации установлены требования к таким товару, работам, услугам. При этом не допускается

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

законодательством Российской Федерации такие документы передаются вместе с товаром.

6 Технические требования к элементам ИТ-инфраструктуры

Данные технические требования рассматриваются в разрезе лучших мировых практик по

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

предъявляются к следующим категориям инфраструктурных элементов:

Элементы инфраструктуры ЭП в РК:

o Домены;

o Участники доменов;

o Электронная почта;

Рабочие места пользователей:

o Персональные компьютеры;

o Системное ПО рабочих мест пользователей;

o Периферийные устройства;

Прикладное ПО;

Мультисервисная сеть:

o Корпоративная распределенная мультисервисная сеть;

o Внешние каналы связи;

Инфраструктура центров обработки данных:

o Системы обработки и хранения данных;

o Помещения и инженерные системы;

Информационная безопасность;

Непрерывность предоставления ИТ-услуг;

Системы управления и мониторинга;

6.1 Требования к наименованиям элементов

Инфраструктура ЭП складывается из ряда элементов, в число которых входит и доменная

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

доменов, участников доменов и адресов электронной почты.

6.1.1 Требования к наименованиям доменов

Доменное имя организации формируется с использованием символов, входящие в стандартный

набор символов, разрешенных для использования в именах DNS узлов Интернета. Допустимые

знаки определены в документе RFC 1123.

Для поддоменов домена rkomi допустимо использовать: английские строчные буквы (a-z), цифры

(0-9) и дефис (-). Имя поддомена не должно превышать 12 символов.

6.1.2 Требования к наименованию участников домена

Шаблон: ТХХХXФ, где:

1. Т — тип устройства (S — Сервер, D - рабочая станция, N — ноутбук, P — прочие portable-

устройства, etc. )

2. ХХХX — учетный номер

3. Ф — функция в сети (PDC/SDC, SQL, ISA, « — для серверов; BU, ZP, SS, BR, MM — для

рабочих станций).

Пример: S0003FS(FQDN - s0001fs.rkomi.local) - это Сервер, третий по счету выполняет функции

файлового сервера

6.1.3 Требования к адресам электронной почты

Электронная почта государственных органов РК и государственных учреждений РК используется

для служебных целей.

Лица, замещающие государственные должности РК, государственные гражданские служащие РК

для официальной электронной переписки используют почтовые адреса в домене rkomi.ru.

Использование для официальной электронной переписки почтовых адресов в публичных сервисах

предоставления адресов электронной почты (в том числе gmail.com, mail.ru, rambler.ru и др.) и

поддоменах, не относящихся к домену rkomi.ru, запрещается.

В адресное пространство электронной почты государственных органов РК и государственных

учреждений РК входят:

1. официальные адреса органов государственных органов РК и государственных учреждений

РК (далее - официальные адреса);

2. служебные адреса структурных подразделений государственных органов РК и

государственных учреждений РК (далее - служебные адреса);

3. персональные адреса работников государственных органов РК и государственных

учреждений РК (далее - персональные адреса).

Официальные адреса органов государственной власти РК устанавливаются, в соответствии с

приложением 9 настоящего документа. Официальные адреса эксплуатируются работниками,

ответственными за ведение делопроизводства в государственном органе РК и государственном

учреждении РК. Порядок регистрации и дальнейшего движения электронного письма,

поступившего на официальный адрес электронной почты, определяется в соответствии с

Инструкцией по делопроизводству государственного органа РК и государственного учреждения РК.

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

органов государственных органов РК и государственных учреждений РК. Служебные адреса

эксплуатируются работниками, ответственными за ведение делопроизводства в структурном

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

либо, по его поручению, другим лицом.

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

далее из первой буквы отчества пользователя, фамилии пользователя целиком, символа "@" и

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

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

разделитель в виде ".". Пример корректного адреса электронной почты: i.i.ivanov@cit.rkomi.ru.

Порядок составления имени пользователя является строгим и не допускает изменений в порядке

символов, изменении знаков пунктуации. Символы указываются строго на латинице, строчными

буквами.

При необходимости использования обезличенного (общего) почтового ящика, например, для

общих вопросов или как почтовый ящик группы пользователей, допускается до знака "@"

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

псевдонимом для существующего

(существующих) адреса

(адресов) электронной почты

конкретного пользователя (пользователей).

Структура именования домена является трехуровневой. При необходимости допускается

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

следующим образом:

1) При принадлежности организации (в данном случае организацией считается организация с

самостоятельной регистрацией юридического лица) к государственным учреждениям РК,

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

ведомству или иному учреждению регионального уровня исполнительной, законодательной,

судебной ветвей власти. Далее указывается домен второго уровня rkomi.ru. Пример:

i.i.ivanov@minfin.rkomi.ru. В случае, если организация является муниципальной структурой, т.е.

функционирует как муниципальный орган, то приоритетом именования является указание

территориальной принадлежности муниципального образования. Пример: i.i.ivanov@ukhta.rkomi.ru.

2) В иных случаях (ГАУ, ГОУ и т.д.) рекомендуется именовать домен почтового адреса и имя

пользователя, при наличии локального почтового сервера, в соответствии с приведенными выше

правилами.

6.2 Требования к рабочим местам пользователей

6.2.1 Требования к персональным компьютерам

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

компьютеров, эксплуатируемых в органах государственной власти РК, государственных

учреждениях.

Конкретные минимальные технические требования изложены в приложении - «7.1.1 Минимальные

требования к характеристикам ПК». Рекомендованные технические требования указаны в КРК.

При несоответствии компьютерного парка конфигурациям, указанным в КРК

(устаревание

компьютерного парка), и при условии, что минимальные технические требования общесистемного

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

компьютерного парка до актуального состояния, указанного в КРК из расчѐ та 20% от общего числа

АРМ в год.

6.2.1.1 Общие требования

При развитии парка персональных компьютеров и выборе закупаемых моделей ПК ИТ-службы

органов государственной власти РК, Государственных учреждений РК должны руководствоваться

следующими положениями:

Аппаратная платформа и ПО персональных компьютеров должны быть стандартизованы и

сертифицированы, иметь гибкую и масштабируемую архитектуру; Аппаратные

характеристики ПК должны соответствовать, либо превосходить минимальные

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

превосходят минимальные системные требования используемого ПО, конфигурация

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

минимальные требования; Для обеспечения общего уровня услуг, управление данными

всех ПК должно быть

унифицировано, т.е. для ПК должно быть организовано централизованное

распространение ПО с помощью единого инструмента распространения обновлений ПО;

ПК с установленным системным и прикладным ПО (рабочая станция) должен иметь

аппаратную либо программную систему удалѐ нного управления; Для повышения качества

и скорости администрирования количество различных

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

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

Для спецификации технических требований выделяются следующие ключевые параметры ПК:

Производительность. Производительность персональных компьютеров должна

обеспечиваться за счет:

o Параметров быстродействия процессора;

o Необходимого и достаточного объема оперативной памяти;

o Скорости внутренних шин передачи данных;

o Качества и быстродействия графической подсистемы;

o Устройств ввода/вывода;

Надежность. Надежность должна обеспечиваться за счет аппаратных средств и ПО и

определяться исходя из среднего времени безотказной работы (MTBF).

Масштабируемость. Масштабируемость должна обеспечиваться архитектурой и

конструкцией персонального компьютера за счет возможности наращивания:

o Числа и мощности процессоров;

o Объемов оперативной и внешней памяти.

6.2.1.2 Требования к типизации конфигураций

Весь парк ПК в органах государственной власти РК, государственных учреждениях РК

предлагается разделить на следующие типовые конфигурации АРМ:

АРМ Типа 1. Персональный компьютер для работы с специализированным прикладным ПО

(офисные системы, финансовые системы, СЭД и т.п.); АРМ Типа 2. Персональный

компьютер повышенной мощности для работы с графическими

пакетами, пакетами ПО моделирования, САПР, АСУЭИ, АСУТП и пр. Используется для

приложений с развитой графикой, высокими требованиями к производительности

процессора и объѐ мам оперативной памяти; АРМ Типа 2. Тонкий клиент. Маломощный

персональный компьютер для работы с

приложениями в терминальной среде, либо с программами - тонкими клиентами в клиент-

серверной архитектуре. При такой работе основные ресурсоѐ мкие операции производятся

на сервере.

Мобильное АРМ. Ноутбук для работы мобильных пользователей.

Каждое АРМ состоит из системного блока, монитора (допускается объединение системного блока

и монитора в моноблок), клавиатуры, манипулятора

«мышь»

(при необходимости) с

установленным и настроенным общесистемный ПО

6.2.2 Требования к системному ПО рабочих мест пользователей

Конкретные минимальные технические требования изложены в приложении - «7.1.2.

Минимальные требования к системному ПО рабочих мест пользователей».

ОС офисного назначения должны:

Соответствовать по типу клиентским ОС; Поддерживать все сетевые сервисы,

обеспечивающие функционирование корпоративной сети;

Обеспечивать необходимый уровень информационной безопасности, в соответствии с

документом «Требования к информационной безопасности электронного правительства в

Республике Коми»; Быть совместимыми с корпоративным стандартом используемого

офисного ПО.

6.2.3 Требования к периферийным устройствам

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

служб Заказчика периферийным устройствам, входящим в ИТ инфраструктуру.

Конкретные минимальные технические требования изложены в приложении - «7.1.3.

Минимальные требования к периферийным устройствам».

Рассматриваются требования к следующим классам периферийных устройств:

Устройства печати (принтеры);

Многофункциональные устройства;

Факсимильные аппараты.

Требования к специализированным устройствам, имеющим узкое технологическое применение

(термопринтеры, принтеры штрих-кодов, наклеек, типографии и т.д.), не рассматриваются.

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

технических требований технологического процесса.

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

следующая классификация устройств:

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

Групповое устройство - используется в режиме разделения ресурсов группой сотрудников;

Корпоративное устройство - используется в задачах подразумевающих использование

высокопроизводительных устройств (графика, большие форматы вывода данных

(A1,A2,A3) и т.д.

6.2.3.1 Общие требования

В данном разделе излагаются общие требования, которые необходимо применять при выборе и

закупке нового периферийного оборудования в целях развития ИТ Заказчика. Периферийное

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

Производительность. Периферийное оборудование должно обеспечивать потребности

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

показателях

(например, количество копий в минуту, разрешение сканируемого

изображения и т.д.).

Надежность. Периферийное оборудование должно позволять обеспечивать непрерывность

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

показателях (MTBF).

Функциональность. В том случае, если рабочее место сотрудника должно быть

оборудовано несколькими видами периферийного оборудования, следует отдавать

предпочтение при закупке МФУ, которое должно поддерживать все или частично все

следующие функции:

o печатного устройства;

o сканирующего устройства; o

копировального устройства;

Совместимость. Периферийное оборудование должно технически и программно

сопрягаться с персональными компьютерами (в случае использования группового или

корпоративного устройства - с серверами) независимо от типа процессора и ОС.

Безопасность. Выход из строя какого-либо периферийного устройства не должен влиять на

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

корпоративного устройства - серверов) с другим периферийным оборудованием.

Управляемость. Подключение и управление персональным периферийным оборудованием

по возможности должны быть простыми и не требовать оперативного использования

инструкций и описаний работы устройств.

Низкая ТСО. Запчасти и расходные материалы для периферийного оборудования должны

быть легко доступны и обладать невысокой стоимостью.

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

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

оборудования должны быть предусмотрены специально выделенные помещения.

Низкое энергопотребление. Рекомендуется приобретение оборудование, имеющее режим

пониженного энергопотребления (режим ожидания).

Следует отдавать предпочтение тем периферийным устройствам, которые в штатном

режиме имеют возможность обмена информацией через локальную сеть.

Те периферийные устройства, которые имеют возможность подключаться как к ПК, так и к

локальной сети следует подключать к локальной сети.

6.2.3.2 Требования к групповым и корпоративным устройствам

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

нежели к персональным устройствам. При выборе групповых и корпоративных устройств

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

данные устройства.

МФУ должны проходить периодическое техническое обслуживание, которое будет

способствовать более высокой доступности устройства и снизит TCO. Периодичность данного

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

конкретного устройства.

См. «7.8 Приложение 8. Каталог рекомендованных конфигураций».

6.3 Требования к мультисервисной сети

6.3.1 Требования к распределенной мультисервисной сети

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

Приводятся требования к архитектуре, протоколам и оборудованию.

Конкретные минимальные технические требования изложены в приложении - «7.2.1.

Минимальные требования к корпоративной распределенной мультисервисной сети».

6.3.1.1 Общие требования

Основные стратегические положения и подходы к организации корпоративной распределенной

мультисервисной сети: ориентация на архитектуру сетей следующего поколения (NGN).

Телефония, аудиоконференцсвязь, видеоконференцсвязь и передача данных должны

основываться на единой конвергентной мультисервисной сети, которая позволяет предоставлять

указанные сервисы, обеспечивая необходимый и достаточный уровень QoS.

Сеть построена на следующих принципах:

Распределенная корпоративная архитектура, обеспечивающая QoS;

Высокая доступность и надежность сети; Производительность,

управляемость и масштабируемость сети;

Мультисервисная сеть должна проектироваться с учетом требований информационной

безопасности.

Весь трафик должен быть классифицирован на следующие классы, определяющие приоритет

обслуживания:

Трафик реального времени (телефонный, аудио и

видео); Трафик передачи пользовательских данных;

Технологический трафик.

Если технологическое оборудование требует наивысшего класса обслуживания, то его трафику

должен быть отдан наивысший приоритет. После этого должен идти трафик реального времени,

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

сети и активное сетевое оборудование должны всегда обеспечивать качество для трафика

реального времени.

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

трафика реального времени и пользовательского трафика в том объеме, в котором это

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

обслуживающего его персонала. Данные правила должны быть реализованы в настройках

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

6.3.1.2 Требования к архитектуре сети

Архитектура мультисервисной сети должна быть основана на следующих принципах:

Строиться на трехуровневой модели; Иметь

резервирование по оборудованию и каналам;

Поддерживать VLAN;

Архитектурно разбиваться на демилитаризованные зоны (ДМЗ); Сеть должна

обеспечивать необходимую для решения задач производительность; Сеть должна

обеспечивать QoS для разных классов трафика.

Мультисервисная сеть для всех ЦОД должна проектироваться, исходя из трехуровневой модели

коммутации:

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

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

для поиска и устранения неисправностей. Интеллектуальные сервисы 3-го уровня модели OSI (в

том числе протоколы маршрутизации) должны обеспечивать сокращение области, затрагиваемой

при возникновении разнообразных проблем с неисправным или неверно настроенным

оборудованием, а также балансировку нагрузки между/внутри уровнями иерархии и быструю

сходимость.

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

Любые проблемы с оборудованием и каналами связи на нижележащих уровнях не должны

сказываться на верхних уровнях; Транзитные резервные маршруты определѐ нного уровня

не должны проходить через нижележащие уровни;

Классификация трафика должны происходить только на уровне доступа. Приоритизация

трафика должна поддерживаться всеми уровнями сети. Уровень распределения должен

только агрегировать трафик. Ядро сети должно только осуществлять быструю коммутацию

и маршрутизацию пакетов; Время сходимости таблиц маршрутизации и их объем должны

быть оптимизированы для

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

пользователи и внешние каналы связи не должны подсоединяться напрямую к

ядру сети. Необходимо использовать коммутаторы доступа для предотвращения

лавинообразных перестроек таблиц маршрутизации всей сети; Запрещается

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

- управляемый коммутатор уровня 2.

Резервирование для ЦОД I уровня должно, а для ЦОД II уровня рекомендуется организовывать

следующим образом:

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

(либо выше) GigabitEthernet, либо объединенных в отказоустойчивый стек с

эквивалентной пропускной способностью;

Каждый коммутатор уровня доступа должен иметь соединения каналами Gigabit Ethernet с

двумя коммутаторами уровня распределения;

Каждый коммутатор уровня распределения должен иметь соединения каналами Gigabit

Ethernet (либо выше) с двумя коммутаторами уровня ядра;

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

маршрутизатора. Маршрутизаторы подключаются каждый к не менее чем двум различным

интернет-провайдерам и осуществляют маршрутизацию пакетов по протоколу BGP.

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

обеспечивающими функциональность МСЭ или IDS/IPS;

Для обеспечения независимости от интернет-провайдеров должна использоваться

автономная системы (AS) с собственным пулом ip-адресов (не менее /22).

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

Поэтажные коммутаторы (коммутаторы доступа) должны соединяться с коммутаторами

уровня распределения по GigabitEthernet или 10 GigabitEthernet;

Серверы должны соединяться с коммутаторами уровня распределения по GigabitEthernet

или 10 GigabitEthernet. При необходимости допускается подключение серверов к

коммутаторам уровня ядра; Коммутаторы уровня распределения и ядра должны быть

выбраны соответствующей

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

требование поддержки всех требуемых протоколов с требуемым уровнем QoS.

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

расстояниях, необходимости пропуска большого объѐ ма трафика и больших скоростей

передачи данных рекомендуется организовывать каналы связи на основе технологии

оптического уплотнения (xWDM) и агрегации каналов.

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

Оборудование магистрального уровня должно иметь резервирование всех компонентов;

Сеть должна быть спроектирована в соответствии с требованиями документа «Требования

к информационной безопасности электронного правительства в Республике Коми»;

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

все ресурсы сети и пользователей, которые имеют повышенную защищенность согласно

документу «Требования к информационной безопасности электронного правительства в

Республике Коми»

Поддержка масштабируемости сети должна быть обеспечена следующим образом:

За счет правильного внедрения трехуровневой модели коммутации.

За счет масштабируемости коммутаторов, которая должна достигаться за счет

объединения коммутаторов в группы (стеки). Причем каждый коммутатор в стеке должен

работать в двух режимах - как главный коммутатор стека и как процессор коммутации

пакетов. Должна обеспечиваться отказоустойчивость системы по схеме 1:N (при выходе из

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

будут продолжать выполнение своих функций без остановки работы всей сети);

Рекомендуется использовать динамический протокол внутренней маршрутизации OSPF

как обладающий хорошей масштабируемостью, быстрой сходимостью, учитывающий

качество каналов связи и занимающий минимальную полосу канала.

Система IP-адресации сети должна обеспечивать:

Разделение адресного пространства на служебный блок (сети, связывающие

маршрутизаторы, виртуальные интерфейсы и т.п.) и блок адресов локальной сети. Такое

разделение позволяет эффективно строить правила доступа к сетевым устройствам;

Распределение адресного пространства локальной сети блоками в соответствии с

территориальным расположением. Такое разделение позволяет производить

агрегирование адресов, что приводит к уменьшению таблиц маршрутизации и упрощает

управление сетью.

Для осуществления аутентификации на уровне доступа для всех устройств, обеспечивающих

функционирование сети, и при доступе к консоли управления всеми устройствами, сеть должна

обладать следующими возможностями:

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

предварительно заданными физическими адресами пользовательских ПК (MAC-адреса).

При попытке подключения неавторизованного устройства должно производиться

отключение этого порта и уведомление системы управления сетью; Автоматическое

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

изменения конфигурации порта на основе логического подключения пользователя к сети;

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

идентификация, авторизация и учет при доступе к командной строке устройства;

Ограничение доступа по IP адресам, с учетом ограничения на доступ к командной строке

устройства и системной консоли, а также SNMP трафика;

Должна быть автоматическая фильтрация трафика неиспользуемых протоколов на портах

коммутаторов.

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

функциональность:

Поддержка протокола RSTP/MSTP или иных протоколов резервирования второго уровня;

Поддержка возможности объединять в единый логический канал несколько физических

соединений между коммутаторами; Функции автоматического переключения с основного

маршрутизатора на резервный в случае отказа основного;

Балансировка нагрузки между резервируемыми маршрутизаторами; Функции внутреннего

ПО для улучшения времени сходимости протоколов маршрутизации и балансировки

нагрузки через равноценные маршруты.

Для поддержки приложений, основанных на технологии многоадресной рассылки IP Multicast, от

сетей требуется наличие следующих возможностей:

На уровне доступа/распределения - передача пакетов IP Multicast на канальном уровне на

скорости физического канала, динамическая регистрация посредством протоколов IGMP и

PIM.

Магистральный уровень - передача пакетов IP Multicast на канальном и сетевом уровнях

на скорости физического канала, масштабируемые протоколы маршрутизации трафика IP

Multicast.

6.3.1.3 Требования к телефонии, аудио- и видео-конференцсвязи

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

- IP. Допускается использование

традиционной аналоговой телефонии в следующих случаях:

Унаследованные существующие телефонные станции; Экономическая целесообразность.

Данное исключение действует до момента, когда

стоимость VoIP телефонов станет сопоставима с ценой аналогового телефона.

VoIP преимущественно должна внедряться по технологии SIP, т.к. данная технология, по

сравнению с H.323, используется в сетях следующего поколения и имеет большую

функциональность. При этом необходимо обращать внимание на совместимость реализации

протокола SIP между оконечными устройствами и программно-аппаратным комплексом,

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

должна выражаться в поддержке основного функционала по обработке поступающих звонков с

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

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

аппаратные комплексы, обеспечивающие функциональность учрежденческой телефонной

станции, одного производителя, либо проводить тщательное лабораторное тестирование

совместимости аппаратуры разных производителей.

Системы видеоконференцсвязи должны поддерживать Web-конференции и интегрироваться с

офисными приложениями.

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

поддержки видеоконференцсвязи.

Видеоконференцсвязь должна организовываться на технологии IP с использованием стандартов

H.323/H.264.

При пакетной передачи за эталон качества речи должен быть принят уровень качества, равный 4

баллам по шкале MOS/PAMS

(Mean Opinion Score, субъективный метод оценки согласно

рекомендации Р.800). Рекомендуется использовать кодек G.729 (MOS = 4.07). Требования к

параметрам качества пакетной передачи: задержка пакетов - до 150 мс, джиттер - до 50 мс.

При наличии двух и более провайдеров, включая традиционную телефонию и VoIP, рекомендуется

использовать LCR. При этом оборудование VoIP должно обеспечивать мониторинг качества

канала связи.

6.3.1.4 Требования к оборудованию

Оборудование уровня доступа должно обладать возможностью классификации трафика (Traffic

Classification), т.е. должна быть обеспечена возможность классифицировать трафик по типам

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

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

уровень приоритета, тем самым давая возможность устройствам сети соответствующим образом

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

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

приоритет своему трафику и передает его в сеть. Этот приоритет может затем быть понижен в

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

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

Оборудование магистрального уровня должно обладать следующей функциональностью:

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

управлять поведением сети при перегрузках, отбрасывая определенные пакеты на основе

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

интерфейсах. Администратор должен устанавливать пороговые значения для различных

уровней приоритета.

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

передачу пакетов, основанную на классификации или политике качества обслуживания,

при помощи нескольких очередей.

Резервирование основных узлов, к которым может относиться: блок питания, блок

вентиляторов, процессорный модуль.

Предоставлять возможность углубленного анализа потоков сетевого и транспортного

уровней при помощи протокола IPFIX (RFC 3917), Netflow, J-Flow или другого протокола

предоставления агрегированной статистики по ip-потокам.

В ЦОД I и II уровня помимо обеспечения резервирования основных узлов оборудования

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

уровня распределения.

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

обслуживания и безопасности, планирования сети и сервисов:

Должна быть обеспечена возможность сбора статистики с точностью до порта сети для

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

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

портов и виртуальных портов на анализатор протоколов для детального анализа.

Должна быть обеспечена возможность расширенного мониторинга событий в реальном

времени для расширения возможностей диагностики, помимо внешних анализаторов.

Должна быть обеспечена возможность сбора и сохранения информации о существенных

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

программные и аппаратные ошибки по технологии syslog.

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

отчетам через стандартный WEB-браузер с использованием протокола HTTPS.

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

протокола ssh.

Должна быть обеспечена возможность автоматической конфигурации Fast/Gigabit Ethernet

портов, виртуальных сетей, транков VLAN.

Должна быть обеспечена возможность автоматического распознавания топологии сети

посредством агентов распознавания топологии.

В целях обеспечения производительности локальной сети, ее масштабируемости,

удовлетворения требованиям информационной безопасности и обеспечения качества

обслуживания мультисервисного трафика, запрещается использовать концентраторы

(hub). Вместо них должны использовать только коммутаторы (switch).

Все активное оборудование должно иметь конструктивное 19” стоечное исполнение.

6.3.2 Требования к внешним каналам связи

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

предоставляются сторонними операторами связи.

6.3.2.1 Общие положения

В целях унификации необходимо выделить следующие используемые виды каналов связи:

Телефонные цифровые потоки E1 PRI.

Выделенные каналы передачи данных.

Арендуемые каналы сети передачи данных.

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

подключаются к сети MPLS оператора, т.к. только сети MPLS в настоящее время эффективно

обеспечивают QoS для мультисервисного трафика при приемлемой стоимости услуги.

Рекомендуемый интерфейс подключения - Ethernet, точка-точка.

Каналы связи для соединений точка-точка или точка-многоточка между ЦОД I и II уровней должны

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

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

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

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

имеются. Требования должны быть указаны в соответствующем SLA.

С целью резервирования коммуникаций для ЦОД I уровня обязательно, а для ЦОД II уровня

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

в главе 4.3.1.2 «Требования к архитектуре сети».

При подключении ЦОД I и II уровней оператор связи должен обеспечить круглосуточную службу

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

инциденты.

6.3.2.2 Цифровые проводные каналы связи

Качество цифровых каналов связи и телематических служб должно соответствовать требованиям,

утвержденным в РФ и содержащимся в следующих документах:

Приказ Минсвязи России от 10.08.96 №92 «Нормы на электрические параметры цифровых

каналов и трактов магистральных и внутризоновых первичных сетей».

РД 45.128-2000 «Сети и службы передачи данных».

РД 45.129-2000 «Телематические службы».

6.3.2.3 Цифровые радиорелейные линии связи

Цифровые радиорелейные линии связи (ЦРРС) применяются в местах, где прокладка ВОЛС

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

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

Использование ЦРРС также целесообразно в тех местах, куда оптоволоконные линии связи

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

потребность все-таки существует, выходом становится применение ЦРРС малой емкости. В таких

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

частоты, которые не требуют высокой точности юстировки антенн, антенны их легко разбираются

для перевозки и занимают мало места, при этом дальность передачи у таких станций превышает

100 км.

Для расширения единой распределѐ нной мультисервисной сети используется радиорелейное

оборудование, которое передает сигнал формата Ethernet 10 BaseT или Ethernet 100 BaseT, с

подключением оконечной станции в локальную сеть. Для подключения оборудования РРЛ

рекомендуется использовать Ethernet-оборудование, поддерживающее принудительное

включение режима Full Duplex, что повышает пропускную способность канала и позволяет

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

различные методы шифрования и аппаратные средства для обеспечения секретности

передаваемой информации.

Технические и технологические требования к элементам инфраструктуры электронного правительства в Республике Коми (2011 год) - часть 1