Приказ Росавиации от 29.05.2009 № 233

«Об утверждении Положения о технической политике в области информационных технологий Федерального агентства воздушного транспорта»

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

ФЕДЕРАЛЬНОЕ АГЕНТСТВО ВОЗДУШНОГО ТРАНСПОРТА

ПРИКАЗ

от 29 мая 2009 г. № 233

ОБ УТВЕРЖДЕНИИ ПОЛОЖЕНИЯ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ В ОБЛАСТИ ИНФОРМАЦИОННЫХ

В соответствии с пунктом 9.9 Положения о Федеральном агентстве воздушного транспорта, утвержденного Постановлением Правительства Российской Федерации от 30 июля 2004 г. № 396, приказываю:

1. Утвердить прилагаемое Положение о технической политике в области информационных технологий Федерального агентства воздушного транспорта.

2. Контроль за выполнением настоящего Приказа возложить на заместителя Руководителя Чертока В.Б.

ПОЛОЖЕНИЕ О ТЕХНИЧЕСКОЙ ПОЛИТИКЕ В ОБЛАСТИ ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ ФЕДЕРАЛЬНОГО АГЕНТСТВА ВОЗДУШНОГО ТРАНСПОРТА

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

Положение о технической политике в области информационных технологий (далее по тексту — Положение) является документом по обеспечению функционирования ИТ-инфраструктуры Федерального агентства воздушного транспорта (Росавиация) (далее по тексту — Росавиация).

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

1. Цели Положения

Целями Положения являются:

• определение основных направлений и требований оптимального развития ИТ-инфраструктуры для повышения эффективности и качества деятельности Росавиации;
• унификация и типизация элементов ИТ-инфраструктуры для снижения общей стоимости владения;
• структуризация ИТ-инфраструктуры на центры обработки данных (ЦОД) различного уровня для повышения надежности, отказоустойчивости и безопасности используемых решений.

2. Использование Положения

Действие настоящего Положения распространяется:

• на руководителей Росавиации различного уровня в части учета вопросов развития ИТ-инфраструктуры в общей стратегии развития Росавиации;
• на подразделение, осуществляющее закупку ИТ-оборудования и услуг для формирования конкурсной документации;
• на подразделения, ответственные за стратегическое планирование, в части учета требований по перспективному развитию ИТ-инфраструктуры;
• на подразделение по работе с персоналом — для составления квалификационных требований к персоналу и программ повышения его квалификации.

3. Актуализация Положения

Положение должно пересматриваться не реже одного раза в 2 года, а Приложения к настоящему документу — не реже 1 раза в год. Ответственность за актуализацию обоих документов несет заместитель Руководителя, в обязанности которого входит эксплуатация ИТ-инфраструктуры Росавиации.

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

Процесс проведения изменений в ИТ-инфраструктуре — это процесс использования стандартизированных методов и процедур для эффективного и своевременного перехода ИТ-инфраструктуры к новому, более совершенному состоянию с минимальными негативными последствиями для деятельности Росавиации.

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

• Требование «разумного консерватизма» при внедрении новых версий ИТ-компонентов.
• Требование автоматизации тиражирования обновлений ПО.
• Обязательное документирование вносимых изменений.

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

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

• внедрение новых версий ПО должно иметь обоснованные преимущества перед используемыми версиями ПО и не должно ухудшать текущего состояния дел;
• для критически важных вычислительных процессов недопустимо внедрение последних версий ПО и/или его компонентов, за исключением используемых в схожей среде более 2 лет и имеющих при этом не менее 2 корректирующих обновлений от производителя (релизов, патчей, сервис-паков, обновлений ПО и т.п.);
• недопустимо использование тестовых версий ИТ-компонентов (альфа-, бета-версии ПО и т.п.) в режиме промышленной эксплуатации;
• при планировании внедрения новых версий ПО рекомендуется учитывать долгосрочные планы производителя по выпуску новых версий/релизов.

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

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

• создание и внедрение решения по автоматизации тиражирования обновлений ПО должно производиться в рамках отдельных проектов с использованием собственной серверной системы тиражирования обновлений. Обновление ПО непосредственно с интернет-портала производителя не допускается;
• функциональные возможности автоматизированной системы тиражирования обновлений должны позволять реализацию полного и упрощенного циклов управления изменениями, проводить автоматическую проверку (аудит) тиражирования обновлений;
• тиражирование обновлений в области безопасности критичных для организации систем (обновления операционных систем, ПО с непосредственным доступом во внешние сети/Интернет, антивирусные системы и т.п.) подлежит обязательной автоматизации;
• тиражирование обновлений в области безопасности и функциональных обновлений на рабочие станции и инфраструктурные ИТ-компоненты (домен-контроллеры, DNS/DHCP-сервера и т.п.) в части системного и офисного ПО подлежит обязательной автоматизации;
• рекомендуется автоматизация тиражирования обновлений клиентской части специфичных для Росавиации приложений.

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

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

С целью снижения номенклатуры и повышения качества ИТ-товаров и услуг, поставляемых для нужд Росавиации, необходимо учитывать требования к следующим категориям ИТ-инфраструктуры:

• рабочим местам пользователей (ПК, периферийное оборудование);
• мультисервисной сети (вычислительная сеть организации, внешние каналы связи);
• прикладному ПО;
• инфраструктуре центров обработки данных (системы хранения и резервирования, серверы).

Общие требования к указанным категориям и их отдельным элементам приведены в главе 5 настоящего документа. При разработке нормативных документов Росавиации в области информационных технологий необходимо учитывать указанные требования.

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

2. Классификация по уровню использования

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

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

• Центр обработки данных Росавиации (ЦОД I уровня) обеспечивает централизованное хранение и обработку данных на уровне всей Росавиации. Ресурсы данного ЦОД используются для консолидации информации с нижележащих уровней, обеспечения информационного взаимодействия географически распределенных подразделений Росавиации.
• Центр обработки данных территориального подразделения (ЦОД II уровня) — основной центр хранения и обработки данных в рамках одного территориального подразделения Росавиации.

В разделе «Требования к инфраструктуре центров обработки данных» содержатся общие требования к оборудованию ЦОД различного уровня. Кроме того, в Приложениях к данному документу приведены текущие рекомендованные минимальные требования к ИТ-конфигурациям и их элементам (программно-аппаратным средствам, системам связи и коммуникаций). ИТ-конфигурации с заявленными характеристиками ниже приведенных минимальных значений не рекомендуется закупать и вводить в эксплуатацию в Росавиации.

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

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

• Системы, работающие в режиме «боевого дежурства». К таким системам относятся: остро критические с точки зрения внутренней деятельности или внешних факторов, работающие в режиме реального времени. Выход из строя этих систем влечет за собой невосполнимые потери, в т.ч. угрозу жизни и здоровью людей. Рекомендованное время восстановления подобных систем после отказа менее 10 минут. Для таких систем должны использоваться специализированные серверные платформы и инфраструктурные уровни с полным многократным резервированием всех компонентов, в том числе с использованием резервных удаленных ЦОД;
• Системы, критические для деятельности Росавиации, с режимом работы 24 х 7 х 365. Выход из строя этих систем влечет за собой значительные потери для Росавиации или связанных организаций. Рекомендованное время восстановления подобных систем после отказа менее 2 часов. Для таких систем должны использоваться кластерные решения и инфраструктурные уровни с частичным резервированием используемых инфраструктурных компонентов.
• Системы, не требующие работы в реальном времени, с режимом работы 8 х 5. Рекомендованное время восстановления подобных систем после отказа 4 — 6 часов. Для таких систем рекомендуется использовать резервирование хранения данных и электропитания;
• Не критические для деятельности Росавиации приложения, персональные данные. Выход из строя этих систем не влияет на работу Росавиации в целом. Рекомендованное время восстановления подобных систем после отказа 1 — 2 рабочих дня.

Необходимо учитывать, что общая непрерывность и отказоустойчивость ИТ-конфигураций определяется соответствующей непрерывностью и отказоустойчивостью ее отдельных элементов: аппаратных, программных средств и инфраструктуры, необходимой для ее успешного функционирования — каналов связи, системы электропитания и т.д. и в конечном итоге зависит от уровня непрерывности и отказоустойчивости его слабейшего компонента (принцип «слабого звена»). Классификация систем с точки зрения обеспечения непрерывности и отказоустойчивости должна быть одним из решающих факторов при выборе уровня инфраструктуры (ЦОД) для размещения ИТ-систем. В разделе «Требования к инфраструктуре центров обработки данных» содержатся общие требования к таким конфигурациям в разрезе ЦОД различного уровня.

IV. Требования к поставщикам, производителям и проведению конкурсов

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

К поставщикам и производителям предъявляются следующие общие требования:

• Деятельность поставщиков и производителей должна быть лицензирована, если таковое предусматривает Российское законодательство.
• При подведении итогов конкурса при прочих равных условиях преимущество имеют те компании, производство которых отвечает требованиям стандарта системы менеджмента качества ISO 9001:2000 (ГОСТ Р ИСО 9001-2001). Причем в приложении к сертификату должна быть указана именно та деятельность, на предоставление которой претендует данная компания.

2. Требования к поставщикам и производителям оборудования

К поставщикам и производителям программно-аппаратного обеспечения предъявляются следующие требования:

• Производитель аппаратного обеспечения должен иметь сертификат, выданный признанным органом по сертификации, на соответствие своей системы менеджмента качества требованиям ISO 9001:2000 (ГОСТ Р ИСО 9001-2001).
• При прочих равных условиях предпочтение должно отдаваться тем поставщикам аппаратного обеспечения, которые имеют сертификат, выданный признанным органом по сертификации, на соответствие своей системы менеджмента качества требованиям ISO 9001:2000 (ГОСТ Р ИСО 9001-2001).
• Аппаратная платформа и программное обеспечение должны быть стандартизованы и сертифицированы на соответствие стандартам, считающимися общепринятыми в предметной области данного программно-аппаратного обеспечения, иметь гибкую и масштабируемую архитектуру.
• Предлагаемое поставщиком оборудование должно быть коммерчески доступно на протяжении не менее трех месяцев, а программное обеспечение — не менее шести месяцев.
• Поставщики сложного программно-аппаратного обеспечения должны своевременно получать сертификаты соответствия на всю гамму поставляемого оборудования и ПО в соответствии с действующими техническими требованиями в полном объеме, а также обновлять сертификаты при появлении новых версий программного и аппаратного обеспечения поставляемой продукции.
• Поставщик должен быть авторизован производителем на тот перечень услуг, которые поставщик будет оказывать заказчику. При прочих равных условиях предпочтение должно отдаваться поставщикам, имеющим более высокий статус (уровень) отношений с производителем.
• Поставщик должен обладать сертифицированным техническим персоналом на ту предметную область, в которой поставщик будет оказывать заказчику услуги.
• При прочих равных условиях предпочтение должно отдаваться производителям, поставляющим оборудование и ПО, адаптированное для использования в Российской Федерации, если таковая адаптация возможна.
• При прочих равных условиях предпочтение должно отдаваться поставщикам, предоставляющим документацию на оборудование и ПО на русском языке и на электронных носителях (в электронном виде).
• Поставщики должны осуществлять гарантийную поддержку поставленного оборудования и ПО согласно требованиям к услугам по эксплуатации и сопровождению, приведенным ниже.

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

3.1. Общие требования к поставщикам услуг

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

• При прочих равных условиях предпочтение должно отдаваться компаниям, предоставляющим услуги в соответствии с международными стандартами, принятыми для данного типа услуг. Данное соответствие рекомендуется документально подтверждать наличием соответствующего сертификата.
• Поставщик услуг должен иметь сертифицированных специалистов как по функционалу предоставляемых услуг, так и с точки зрения процессной организации предоставления услуг. В частности, рекомендуется учитывать соответствие бизнес-процессов поставщика рекомендациям ITIL и COBIT по предоставлению услуг.
• При оказании услуг системной интеграции рекомендуется, чтобы поставщик имел внедренную у себя на производстве систему управления проектами на основе лучших мировых практик, таких как рекомендации PMI и IPMA. Также предпочтение должно отдаваться компаниям, имеющим сертифицированных руководителей проектов, например, по системе PMI.

3.2. Требования к поставщикам услуг по эксплуатации и сопровождению

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

• Сервис-центр поставщика должен находиться в пределах города размещения заказчика, чтобы иметь возможность устранить неисправность с выездом к заказчику в приемлемые сроки.
• Эксплуатация и сопровождение должны осуществляться специалистами, прошедшими соответствующее обучение (что подтверждается сертификатами).

Сервис-центры поставщика услуг по эксплуатации и сопровождению должны обеспечивать:

Поддержку пользователей в соответствии с требованиями непрерывности по телефону и с помощью электронной почты.

• Решение проблем, возникающих при работе программно-аппаратного обеспечения, в объеме, возложенном на данный сервис-центр.
• Возможность внесения оперативных коррекций в программное обеспечение, находящееся в эксплуатации, с использованием современных средств передачи информации (сетей передачи данных и др.).
• Срок ремонта или замены сервис-центром неисправных узлов оборудования не должен превышать двух недель с момента передачи узла на сервис-центр.

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

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

4. Требования к проведению конкурсов

Участники конкурсов, проводимых Росавиацией для поставки программно-аппаратного обеспечения и/или услуг, должны соответствовать всем требованиям, указанным для поставщиков и производителей в данном Положении, а также соответствовать всем требованиям, которые изложены в нормативных актах по организации закупочной деятельности Росавиации.

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

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

V. Технические требования к элементам ИТ-инфраструктуры

Технические требования предъявляются к следующим категориям инфраструктурных элементов:

• Рабочие места пользователей:
• Персональные компьютеры;
• Системное ПО рабочих мест пользователей;
• Периферийные устройства.
• Прикладное ПО.
• Мультисервисная сеть:
• Распределенная мультисервисная сеть уровня организации;
• Внешние каналы связи.
• Инфраструктура центров обработки данных:
• Системы обработки и хранения данных;
• Помещения и инженерные системы.
• Информационная безопасность.

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

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

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

Конкретные минимальные технические требования изложены в разделе «Минимальные требования к характеристикам ПК» Приложения 2.

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

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

Для спецификации технических требований выделяются следующие ключевые параметры ПК:

• Производительность.

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

• Параметров быстродействия процессора;
• Объема оперативной памяти;
• Скорости внутренних шин передачи данных;
• Качества и быстродействия графической подсистемы;
• Удобства использования и скорости работы устройств ввода/вывода.
• Надежность.

Надежность должна обеспечиваться за счет аппаратных средств и программного обеспечения и определяться исходя из среднего времени безотказной работы (MTBF).

• Масштабируемость.

Масштабируемость должна обеспечиваться архитектурой и конструкцией персонального компьютера за счет возможности наращивания:

• Числа и мощности процессоров;
• Объемов оперативной и внешней памяти.

Весь парк ПК Росавиации делится на следующие типовые конфигурации:

• Персональный компьютер для работы с нетребовательным прикладным ПО (офисные, финансовые, бухгалтерские системы и т.п.).
• Графическая рабочая станция для работы с графическими пакетами, пакетами ПО моделирования, САПР, АСУЭИ, АСУТП и пр. Используется для приложений с развитой графикой и высокими требованиями к производительности и функциональности компьютера.
• Мобильный компьютер (ноутбук) для удаленной работы сотрудников.

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

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

ОС офисного назначения должны:

• Соответствовать по типу клиентским ОС.
• Поддерживать все сетевые сервисы, обеспечивающие функционирование сети организации.
• Обеспечивать высокий уровень информационной безопасности.
• Быть совместимыми с используемым офисным ПО.

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

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

Рассматриваются требования к следующим классам периферийных устройств:

• Устройства печати (принтеры):
• Монохромные принтеры (персональные и группового использования);
• Цветные принтеры (персональные и группового использования).
• Устройства сканирования:
• Сканеры персональные.
• Многофункциональные устройства:
• Персональные МФУ;
• МФУ группового использования;
• МФУ уровня организации.
• Факсимильные аппараты.

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

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

• Персональное устройство находится в постоянном использовании одним сотрудником;
• Групповое устройство используется в режиме разделения ресурсов группой сотрудников;
• Устройство уровня организации — высокопроизводительное устройство для оперативного проведения больших объемов работ, доступ к которому имеют все сотрудники.

Периферийное оборудование должно отвечать следующим основным требованиям:

• Производительность. Периферийное оборудование должно обеспечивать потребности Росавиации и удовлетворять требованиям, определенным в количественных показателях (например, количество копий в минуту, разрешение сканируемого изображения и т.д.).
• Надежность. Периферийное оборудование должно позволять обеспечивать непрерывность деятельности Росавиации и удовлетворять требованиям, определенным в количественных показателях.
• Функциональность. В том случае, если рабочее место сотрудника должно быть оборудовано несколькими видами периферийного оборудования, при закупке следует отдавать предпочтение МФУ, которое должно поддерживать все или частично все следующие функции:
• печатного устройства;
• сканирующего устройства;
• копировального устройства;
• факсимильного устройства.
• Совместимость. Периферийное оборудование должно сопрягаться технически и программно с персональными компьютерами независимо от типа процессора и операционной системы. Минимально необходима совместимость с Windows 2000, XP, Vista.
• Безопасность. Выход из строя какого-либо периферийного устройства не должен влиять на устойчивую работу персональных компьютеров с другим периферийным оборудованием.
• Управляемость. Подключение и управление периферийным оборудованием должны быть простыми и не требовать оперативного использования инструкций и описаний работы устройств.
• Низкая стоимость владения. Запчасти и расходные материалы для периферийного оборудования должны быть коммерчески доступны и обладать минимальной добавочной стоимостью печати одного листа.
• Низкий уровень создаваемого акустического шума. Периферийное оборудование в процессе работы не должно создавать помех окружающим. Уровень шума не должен превышать 55 дБ (А). Для эксплуатации шумного оборудования должны быть предусмотрены специально выделенные помещения.

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

Помимо указанных выше общих требований, для устройств уровня организации необходимо:

• Поддержка формата А3.
• Потоковое сканирование документов с поддержкой сетевого сохранения файлов.
• Преимущество отдавать устройствам, в комплекте с которыми поставляется клиентское ПО для приема и рассылки факсов.

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

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

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

• Ориентация на архитектуру сетей следующего поколения (NGN).
• Все сервисы должны предоставляться единой мультисервисной сетью, обеспечивающей качество обслуживания (QoS).
• Распределенная архитектура, обеспечивающая QoS.
• Высокая доступность и надежность сети.
• Производительность, управляемость и масштабируемость сети.
• Мультисервисная сеть должна проектироваться с учетом требований информационной безопасности.

Весь трафик должен быть классифицирован на следующие классы, определяющие приоритет обслуживания:

• Трафик реального времени (голосовой, аудио и видео).
• Трафик передачи пользовательских данных.
• Технологический трафик.

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

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

Архитектура мультисервисной сети должна быть основана на следующих принципах:

• Строиться на трехуровневой модели.
• Иметь резервирование по оборудованию и каналам.
• Поддерживать VLAN .
• Архитектурно разбиваться на демилитаризованные зоны (ДМЗ).
• Сеть должна обеспечивать QoS для разных классов трафика.

Мультисервисная сеть для всех ЦОД должна проектироваться исходя из трехуровневой модели коммутации:

• Уровень доступа (Access Layer) — коммутаторы 2-го уровня модели OSI с интеллектуальностью 3 — 4-го уровней модели OSI (с целью обеспечения требований к сетевой безопасности, QoS и т.д.).
• Уровень распределения (Distribution Layer) — коммутаторы 3 — 4-го уровней модели OSI.
• Магистральный уровень/уровень ядра (Core Layer) — коммутаторы 3 — 4-го уровней модели OSI.

Указанная трехуровневая модель приведена на следующем рисунке (не приводится).

Выбранная архитектура сети должна позволять наращивать сеть путем добавления новых блоков, обеспечивать высокий детерминизм поведения сети, требовать минимальных усилий и средств для поиска и устранения неисправностей. Интеллектуальные сервисы 3-го уровня модели OSI (в том числе протокол OSPF) должны обеспечивать сокращение области, затрагиваемой при возникновении разнообразных проблем с неисправным или неверно настроенным оборудованием, а также балансировку нагрузки между/внутри уровнями иерархии и быструю сходимость.

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

• Любые проблемы с оборудованием и каналами связи на нижележащих уровнях не должны сказываться на верхних уровнях.
• Транзитные резервные маршруты данного уровня не должны проходить через нижележащие уровни.
• Классификация и приоритезация трафика должны происходить только на уровне доступа. Уровень распределения должен только агрегировать трафик. Ядро сети должно только осуществлять быструю коммутацию пакетов.
• Время сходимости таблиц маршрутизации и их объем должны быть оптимизированы для каждого уровня посредством выбора оптимальной схемы резервирования.
• Удаленные пользователи и внешние каналы связи не должны подсоединяться напрямую к ядру сети. Необходимо использовать коммутаторы доступа для предотвращения лавинообразных перестроек таблиц маршрутизации всей сети.

Резервирование для ЦОД I уровня должно, а для ЦОД II уровня рекомендуется организовывать следующим образом:

• В сети должно быть два коммутатора уровня ядра, связанные между собой по GigabitEthernet или 10 GigabitEthernet.
• Каждый коммутатор уровня доступа должен иметь соединения каналами GigabitEthernet с двумя коммутаторами уровня распределения.
• Каждый коммутатор уровня распределения должен быть соединен по каналам GigabitEthernet с двумя коммутаторами уровня ядра.

Производительность сети для ЦОД I и II уровня должна быть обеспечена следующим образом:

• Поэтажные коммутаторы (коммутаторы доступа) должны соединяться с коммутаторами уровня распределения по GigabitEthernet или 10 GigabitEthernet.
• Серверы должны соединяться с коммутаторами уровня распределения по GigabitEthernet или 10 GigabitEthernet.
• Коммутаторы уровня распределения и ядра должны быть выбраны соответствующей производительности. При выборе уровня производительности необходимо учитывать требование поддержки всех требуемых протоколов с требуемым уровнем QoS.

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

• Выход из строя любого устройства сети не должен приводить к отказу в работоспособности более 48 портов.
• Оборудование магистрального уровня должно иметь резервирование.
• Сеть должна быть спроектирована с учетом требований информационной безопасности.

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

• За счет правильного внедрения трехуровневой модели коммутации.
• За счет масштабируемости коммутаторов, которая должна достигаться за счет объединения в группы (стеки). Причем каждый коммутатор в стеке должен работать в двух режимах — как главный коммутатор стека и как процессор коммутации пакетов. Должна обеспечиваться отказоустойчивость системы по схеме 1:N. To есть при выходе из строя одного из коммутаторов стека независимо от выполняемой им функции остальные будут продолжать выполнение своих функций без остановки работы всей сети.
• Рекомендуется использовать для ЦОД I и II уровней динамический протокол внутренней маршрутизации OSPF как обладающий хорошей масштабируемостью, быстрой сходимостью, учитывающий качество каналов связи и занимающий минимальную полосу канала.

Система IP-адресации сети для всех ЦОД должна обеспечивать:

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

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

• Безопасность портов, т.е. должна быть возможность использования порта коммутатора с предварительно заданными физическими адресами пользовательских ПК. При попытке подключения неавторизованного устройства должно производиться отключение этого порта и уведомление системы управления сетью.
• Автоматическое конфигурирование портов коммутаторов, т.е. должна быть автоматизация изменения конфигурации порта на основе логического подключения пользователя к сети.
• Ограничение доступа по IP-адресам с учетом ограничения на доступ к командной строке устройства и системной консоли, а также SNMP-трафика.
• Должна быть автоматическая фильтрация трафика неиспользуемых протоколов на портах коммутаторов.

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

• Поддержка виртуальных частных сетей (VLAN) на уровне алгоритма «связующего дерева» (Spanning Tree), т.е. должна быть возможность работы отдельного алгоритма Spanning Tree в каждой виртуальной сети для управления путями трафика с точностью до отдельной подсети и обеспечения простого механизма отказоустойчивости на канальном уровне. Также должна быть возможность управления параметром веса порта в алгоритме Spanning Tree для виртуальной сети на транковых портах для загрузки обоих каналов соединения Dual Homing (метод подключения устройств, обеспечивающий основное и резервное соединение).
• Поддержка дополнительных функций в коммутаторах для протокола Spanning Tree:
• поддержка множественных групп Spanning Tree в одной сети;
• оптимизация алгоритма Spanning Tree для переключения на резервные каналы за время менее 5 секунд;
• отсутствие задержки алгоритма Spanning Tree при включении пользовательского порта.
• Поддержка возможности объединять в единый логический канал несколько физических соединений между коммутаторами.
• Функции автоматического переключения с основного маршрутизатора на резервный в случае отказа основного.
• Балансировка нагрузки между резервируемыми маршрутизаторами.
• Функции внутреннего программного обеспечения для улучшения времени сходимости протоколов маршрутизации и балансировки нагрузки через равноценные маршруты.

Для поддержки приложений, основанных на технологии многоадресной рассылки IP Multicast, от сетей ЦОД I и II уровня требуется наличие следующих возможностей:

• На уровне доступа/распределения — передача пакетов IP Multicast на канальном уровне на скорости физического канала, динамическая регистрация посредством протоколов IGMP и PIM.
• Магистральный уровень — передача пакетов IP Multicast на канальном и сетевом уровнях на скорости физического канала, масштабируемые протоколы маршрутизации трафика IP Multicast.

Требования к точкам радиодоступа Wi-Fi:

• Точки радиодоступа Wi-Fi должны поддерживать стандарт IEEE 802.11g (2,4 ГГц, 54 Мбит/с).
• Должно быть уделено особое внимание вопросам безопасности. В частности, вопросу аутентификации и защищенности канала.
• Для аутентификации пользователей рекомендуется использовать Radius-сервер.

Основной протокол передачи аудио- и видеоинформации — IP. Допускается использование традиционной аналоговой телефонии в следующих случаях:

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

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

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

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

Оборудование магистрального уровня должно обладать следующей функциональностью:

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

В ЦОД I и II уровня, помимо обеспечения резервирования основных узлов оборудования магистрального уровня, рекомендуется обеспечить такое же резервирование для оборудования уровня распределения.

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

• Должна быть обеспечена возможность сбора статистики RMON с точностью до порта сети для анализа производительности сети.
• Должна быть обеспечена возможность перенаправлять трафик отдельных портов, групп портов и виртуальных портов на анализатор протоколов для детального анализа.
• Должна быть обеспечена возможность углубленного анализа потоков сетевого и транспортного уровней при помощи протокола IPFIX (RFC 3917).
• Должна быть обеспечена возможность расширенного мониторинга событий в реальном времени для расширения возможностей диагностики, помимо внешних анализаторов.
• Должна быть обеспечена возможность сбора и сохранения информации о существенных сетевых событиях, включая изменения конфигураций устройств, изменения топологии, программные и аппаратные ошибки.
• Должна быть обеспечена возможность доступа к интерфейсу управления устройством и отчетам через стандартный WEB-браузер.
• Должна быть обеспечена возможность автоматической конфигурации Fast/Gigabit Ethernet портов, виртуальных сетей, транков VLAN.
• Должна быть обеспечена возможность автоматического распознавания топологии сети посредством агентов распознавания топологии.
• В целях обеспечения производительности локальной сети, ее масштабируемости, удовлетворения требованиям информационной безопасности и обеспечения качества обслуживания мультисервисного трафика запрещается использовать концентраторы (хабы). Вместо них должны использовать только коммутаторы.

Все вновь закупаемое активное оборудование уровня организации должно иметь конструктивное 19» стоечное исполнение.

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

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

При этом должен быть заключен договор, который предусматривает обеспечение QoS для аудио- и видеоданных, если таковые имеются. Требования должны быть указаны в соответствующем соглашении об уровне услуги SLA (Service Level Agreement).

С целью резервирования коммуникаций для ЦОД I желательно наличие подключения к двум независимым операторам. Способ подключения описан в главе 5.2.1.2 «Требования к архитектуре сети».

При подключении ЦОД I и II уровней оператор связи должен обеспечить круглосуточную службу технической поддержки, которая в любое время суток не только принимает заявки, но и устраняет инциденты.

Качество цифровых каналов связи и телематических служб должно соответствовать требованиям, утвержденным в РФ и содержащимся в следующих документах:

• Приказ Минсвязи России от 10.08.96 № 92 «Нормы на электрические параметры цифровых каналов и трактов магистральных и внутризоновых первичных сетей».
• РД 45.128-2000 «Сети и службы передачи данных».
• РД 45.129-2000 «Телематические службы».

2. Прикладное программное обеспечение

Вся совокупность прикладного ПО делится на две группы:

• Универсальное (тиражируемое) ПО — готовое ПО, доступное на рынке и служащее для решения универсальных задач.
• Заказное ПО — ПО, разработанное по заказу Росавиации.

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

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

При выборе и внедрении нового прикладного ПО должны соблюдаться следующие требования:

• ПО клиентских ПК должно быть функционально полным и обеспечивать выполнение как стандартных задач, так и специфических задач данного пользователя.
• ПО должно быть зрелым: производитель (поставщик) должен гарантировать поддержку, сопровождение данного ПО в течение всего нормативного срока жизни данного ПО.
• Рекомендуется использовать платформонезависимое ПО, обеспечивающее свободу выбора программно-аппаратных средств для его эксплуатации и в конечном счете снижение общей стоимости владения системой.
• Рекомендуется использовать производительное, масштабируемое ПО, обеспечивающее гарантии непрерывности деятельности Росавиации при росте объемов обрабатываемой и хранимой информации.
• Рекомендуется использовать только ПО, обладающее способностью к интеграции с другими системами и обладающее открытой архитектурой, т.е. поддерживающее стандарты OSI. При выборе ПО необходимо учитывать возможности его интеграции в существующую ИТ-инфраструктуру.
• При выборе ПО преимущества должны получать системы с подтвержденным положительным опытом использования в органах государственной власти Российской Федерации.
• Для обеспечения деятельности в критических областях рекомендуется использовать отказоустойчивое ПО в комбинации с резервированием серверной платформы и инфраструктуры ЦОД в соответствии с рекомендациями раздела 5.4 настоящего документа.
• Общая стоимость владения ПО, рассчитанная на весь нормативный срок эксплуатации данного ПО, должна служить важнейшим критерием при выборе того или иного поставщика и ПО.
• ПО должно быть надлежащим образом документировано. Минимальные требования к документации — наличие документа «Руководство пользователя» на русском языке.

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

При закупке нового универсального прикладного ПО должны соблюдаться следующие требования:

• При использовании лицензируемого ПО на него должны быть обязательно получены и надлежащим образом зарегистрированы соответствующие лицензии.
• Рекомендовано к использованию ПО производителей, зарекомендовавших себя на рынке в данной области. Желательно, чтобы данный производитель присутствовал на рынке с данным или аналогичным ПО не менее трех лет. Не рекомендуется использование устаревших версий ПО, а также слишком новых, «незрелых» версий ПО;
• При выборе универсального ПО необходимо руководствоваться общими требованиями к прикладному ПО.

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

При разработке нового прикладного ПО должны соблюдаться следующие требования:

• Процесс проектирования, разработки и внедрения заказного ПО должен соответствовать требованиям раздела 5 «Требования к созданию систем и вводу в действие. Требования к документации» настоящего документа.
• При формировании технического задания в соответствии с ГОСТ 34.602-89 в разделе «Требования к системе» необходимо подробно сформулировать и описать требования к заказываемому ПО, в частности, к его основным свойствам, перечисленным выше. Заказчик ПО должен представить технико-экономическое обоснование разработки и внедрения данного ПО.
• При выборе разработчика ПО основное внимание должно уделяться опыту предыдущей работы данного разработчика по созданию (проектированию, реализации и внедрению) подобных систем. Желательно требование реализации не менее трех аналогичных по функционалу и функциональной полноте проектов в течение последних двух лет.
• При выборе разработчика ПО необходимо сформулировать требования к применяемым системам управления качеством. Желательно наличие у разработчика сертификата на соответствие его системы управления качеством процессов разработки ПО стандартам семейства ISO 9000 (ГОСТ Р ИСО 9000).
• Рекомендуется включать в процедуры приемки ПО передачу разработчиком исходных текстов программ и других объектов, необходимых для создания ПО, согласно требованиям ГОСТ Р ИСО/МЭК 12.207-99. Процедура приемки должна обязательно включать в себя контрольную компиляцию переданных исходных текстов с созданием полностью работоспособной версии ПО и выполнение контрольного примера на данной версии;
• В договоре на разработку ПО необходимо отражать распределение авторских и смежных прав на конечный продукт, а также ограничения на его дальнейшее использование сторонами.

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

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

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

Минимальные технические требования изложены в разделе «Минимальные требования к системам обработки и хранения данных» Приложения 4.

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

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

Серверы должны обеспечивать:

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

ОС для обслуживания серверных приложений и промышленных систем должны:

• Быть высоконадежными и защищенными.
• Обеспечивать высокий уровень быстродействия приложений.
• Поддерживать кластеризацию и grid-системы.
• Обладать встроенными возможностями для организации удаленного мониторинга всех основных сервисов ОС.

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

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

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

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

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

Для ЦОД I уровня должно быть организовано, а для ЦОД II уровня рекомендуется организовать автоматическое блочное резервное копирования данных на другое физическое устройство, нежели исходное (data mirroring).

Должен быть принят и утвержден порядок резервного копирования, в котором должны быть регламентированы периоды и окна резервного копирования для полного и инкрементного резервного копирования.

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

Минимальные технические требования изложены в разделе «Минимальные требования к помещениям и инженерным системам» Приложения 4.

Серверные помещения всех ЦОД должны удовлетворять следующим общим требованиям:

• Запрещается размещать серверные помещения в подвалах и иных помещениях, оснащенных большим количеством инженерных сооружений, которые представляют потенциальную опасность для оборудования.
• Запрещается размещать серверные помещения под помещениями столовой, туалетов и других помещений, связанных с потреблением воды.
• Во избежание протечек воды с крыши запрещается размещать серверные помещения на последнем этаже здания.
• Серверная комната должна представлять собой помещение с ограниченным доступом, предназначенное для размещения серверного оборудования.
• Конструкция серверной комнаты должна соответствовать следующим требованиям:
• Поддерживать требуемую непрерывность рабочих процессов;
• Поддерживать требуемый вес оборудования серверной комнаты;
• Защищать ценное оборудование и данные.
• Физический доступ к серверной комнате должны иметь только уполномоченные сотрудники ИТ-подразделений и обслуживающих организаций.
• Для ограничения физического доступа к серверной комнате должны использоваться автоматизированные системы контроля доступа.
• В зависимости от уровня ЦОД серверная комната должна быть оснащена:
• источником бесперебойного питания;
• системой кондиционирования;
• серверными и телекоммуникационными шкафами, стойками;
• системами контроля состояния внутренней среды:
• системой раннего дымообнаружения;

датчиками доступа.

В серверной комнате рекомендуется иметь фальшпол. Фальшпол является необходимым компонентом, т.к. под ним располагаются кабели электроснабжения и слаботочная инфраструктура. Рекомендуется фальшпол из МДФ-плиток на металлической основе с ламинированным покрытием или съемный фальшпол с покрытием «керамогранит» размером 600 х 600 мм. Высота над уровнем пола — от 100 до 800 мм, для серверных помещений наиболее оптимально 350 — 500 мм.

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

Вновь вводимые структурированные кабельные системы (СКС) всех ЦОД, к которым относится вертикальная и горизонтальная разводка кабелей, шкафы и кроссовое оборудование, должны удовлетворять следующим общим требованиям:

• СКС должна включать в себя горизонтальную и вертикальную разводку. Разводка должна позволять состыковывать коммутаторы доступа с коммутаторами уровня распределения (а также соответственно коммутаторы уровня распределения с коммутаторами уровня ядра) по GigabitEthernet или 10 GigabitEthernet.
• На СКС должна предоставляться гарантия производителя на работоспособность на срок не менее 25 лет. Подрядчик должен быть сертифицирован производителем и иметь проверенное измерительное оборудование. При проведении приемочных испытаний подрядчик должен предоставить протоколы тестирования СКС на соответствие установленным нормам.
• Рекомендуется, чтобы каждый шкаф имел высоту не менее 42U (стандартный телекоммуникационный шкаф), а также имел производительную систему вентиляции. При сверхплотном размещении большого количества шкафов с оборудованием, например в ЦОД I уровня, необходимо отдельно просчитывать вопросы, связанные с вентиляцией. В частности, рекомендуется рассмотреть возможность организации холодных и горячих коридоров.
• Рекомендуется, чтобы каждый шкаф имел перфорированные передние и задние двери для лучшего охлаждения от системы кондиционирования.

Требования к системам кондиционирования и холодоснабжения для всех ЦОД:

• Серверные помещения должны быть оборудованы промышленной системой кондиционирования и вентиляции (системы холодоснабжения) согласно СНиП 2.04.05-91.
• В задачи системы холодоснабжения должно входить поддержание внутри помещения рабочей температуры в пределах от 19 до 24 °С и влажности от 40 до 80%.
• Резервирование системы холодоснабжения ЦОД I уровня обязательно, а для ЦОД II уровня рекомендуется осуществлять по схеме с N+1 (с одним запасным кондиционером).
• Для ЦОД I уровня необходимо, а для ЦОД II уровня рекомендуется организовывать приток свежего воздуха с улицы, так как воздух, постоянно циркулирующий через компьютерные шкафы и кондиционеры, «выгорает» и требует обновления. Приток рекомендуется осуществлять через специальную установку, нагревающую и осушающую уличный воздух. Кроме того, она должна создавать внутри помещения дополнительное давление, что препятствует проникновению внутрь пыли.
• Для увлажнения воздуха в ЦОД I и II уровней рекомендуется использовать парогенераторы. Сухой воздух малоэффективен для охлаждения системой хладоснабжения в силу физических принципов кондиционирования. При понижении влажности электростатический потенциал увеличивается, что может быть причиной вывода оборудования из строя.

Требования к системе раннего обнаружения пожара и газового пожаротушения для ЦОД:

• ЦОД должны быть оборудованы системой автоматического пожаротушения (ГОСТ 12.1.004-91. ССБТ). Система пожаротушения не должна наносить вред оборудованию.
• Система газового пожаротушения должна сработать в зачаточной фазе развития пожара, т.е. когда происходит тление нагревающихся элементов или начальное воспламенение, и за время менее одной минуты потушить очаги возгорания.
• Комплекс предупреждения о пожаре и пожаротушения должен сообщить о потенциальной возможности возгорания намного раньше, чем придется задействовать систему тушения. Это должно быть достигнуто установкой высокочувствительных пожарных датчиков и извещателей, увязанных в единую систему оповещения о пожаре и пожаротушения, а также комплексом организационных мероприятий. В него должен входить постоянный визуальный осмотр оборудования, соблюдение пожарных норм и правил, а также правил эксплуатации электроустановок.
• Рекомендуется использовать огнетушащие смеси на основе хладонов либо инертных газов, т.к. они наносят наименьший ущерб оборудованию.
• Требуется предусмотреть систему удаления газа из помещения после срабатывания системы пожаротушения.
• При срабатывании системы газового пожаротушения должны отключаться все системы, нагнетающие воздух в помещение ЦОД.

Комплексные системы безопасности должны состоять из:

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

Требования к системе видеонаблюдения:

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

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

• Должна быть использована система разграничения доступа на основе proximity-карт, которая состоит из сервера управления, системы контроллеров и считывателей, а также индивидуальных карт (ключей).

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

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

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

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

Требования к документации с точки зрения удовлетворения действующим нормативным документам изложены в приложении 6 (не приводится).

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

• Стадия создания «Технического задания».
• Стадия создания «Технорабочего проекта» для объектов ИТ-инфраструктуры.
• Стадия создания «Программ и методик испытаний».
• Стадия создания «Эксплуатационной документации».
• Стадия поставки оборудования и ПО.
• Стадия монтажа, пусконаладочных работ, предварительных (автономных и комплексных) испытаний.
• Стадия опытной эксплуатации.
• Стадии приемочных испытаний в промышленную эксплуатацию.

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

Должно быть выделено два вида задания: задание на проектирование и техническое задание (ГОСТ 34.602-89).

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

Техническое задание (ТЗ) является основным документом, определяющим требования и порядок создания (развития или модернизации) информационной системы или элементов ИТ-инфраструктуры, в соответствии с которым проводится их разработка и приемка при вводе в действие.

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

ТЗ должно обязательно содержать следующие разделы согласно ГОСТу, которые могут быть разделены на подразделы:

• общие сведения;
• назначение и цели создания (развития) системы;
• характеристика объектов автоматизации;
• требования к системе;
• состав и содержание работ по созданию системы;
• порядок контроля и приемки системы;
• требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие;
• требования к документированию;
• источники разработки.

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

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

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

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

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

Рабочая документация должна содержать, как минимум, альбом на каждую площадку (серверное помещение).

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

В этом случае рабочий проект должен содержать, как минимум, следующие документы:

• Пояснительную записку.
• Рабочую документацию.
• Сводный сметный расчет и Локальный сметный расчет.

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

Программы и методики испытаний должны быть разработаны и утверждены до проведения соответствующих работ. Должны быть разработаны следующие программы и методики:

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

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

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

• Руководство по эксплуатации.
• Схему электрическую функциональную.
• Формуляр (на каждый узел связи).
• Схему электрических соединений (перечень элементов и таблица соединений).
• Ведомость эксплуатационных документов.
• Ведомость ЗИП.

Руководство по эксплуатации должно подробно описывать порядок работы с оборудованием вплоть до перечня команд. Назначение руководства по эксплуатации — уменьшение влияния человеческого фактора за счет документирования всей работы с оборудованием и ПО.

Эксплуатационная документация для ПО должна содержать следующие документы:

• «Руководство оператора»;
• «Руководство администратора».

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

Рекомендуется осуществлять все этапы испытаний системы перед ее вводом в действие, т.е.:

• Предварительные (автономные и комплексные) испытания.
• Опытная эксплуатация.
• Приемочные испытания для приема системы в промышленную эксплуатацию.

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

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

• Сертификат соответствия в системе «Связь», если оборудование подсоединяется к сети общего пользования.
• Сертификаты Гостехкомиссии, если оборудование использует криптографические алгоритмы.
• Для заказного программного обеспечения должна быть предусмотрена разработка, поставка и проверка актуальности на момент проведения опытной эксплуатации (контрольная компиляция и сборка).

Приложение № 1

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

Термин	Описание
NGN	Сеть следующего поколения
SOA	Сервис ориентированная архитектура — современная архитектура ИТ-систем
MPLS	Multiprotocol Label Switching — новый стандарт передачи данных в мультисервисных коммуникационных сетях
ITIL	Свод правил и рекомендаций, описывающий лучшие из применяемых на практике способов (best practice) организации работы ИТ-подразделений или ИТ-компаний
COBIT	Результат обобщения мирового опыта, международных и национальных стандартов и руководств в области управления ИТ, аудита и информационной безопасности
PMI и IPMA	Институт управления проектами (PMI) и Международная ассоциация по управлению проектами (IPMA)
MTBF	Среднее время безотказной работы
ERP	Автоматизированная система управления предприятием
OSPF	Один из динамических протоколов маршрутизации
QoS	Качество сетевых услуг
RPO	Целевая точка восстановления, т.е. момент, до которого необходимо восстановить данные или, другими словами, это фактически допустимый объем потерянных данных
RTO	Целевое время восстановления, т.е. время, необходимое на восстановление данных
Softswitch	Пакетный коммутатор для сетей следующего поколения
SNMP	Протокол управления сетевыми устройствами
ТСО	Общая стоимость владения
VLAN	Виртуальная локальная сеть
Wi-Fi	Технология беспроводных сетей
ДМЗ	Демилитаризованные зоны
ИТ	Информационные технологии
МФУ	Многофункциональное периферийное устройство
ОС	Операционная система
ПО	Программное обеспечение
СКС	Структурированные кабельные системы
ЦОД	Центр Обработки Данных

Приложение № 2

МИНИМАЛЬНЫЕ ТРЕБОВАНИЯ К РАБОЧИМ МЕСТАМ ПОЛЬЗОВАТЕЛЕЙ

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

Технические характеристики	Персональный компьютер	Графическая рабочая станция	Мобильный персональный компьютер (ноутбук)
Процессор	Intel 64 или х86 от 2,0 ГГц с кэшем верхнего уровня 2 МБ или аналог по производительности	Intel 64 или х86 от 2,4 ГГц с кэшем верхнего уровня 6 МБ или аналог по производительности	Intel 64 или х86 от 1,8 ГГц с кэшем верхнего уровня 1 МБ или аналог по производительности
Частота системной шины (FSB)	800 МГц	1066 МГц	800 МГц
Оперативная память	1 ГБ DDR2-800 МГц	2 ГБ DDR2-800 МГц	1 ГБ DDR2-667 МГц
Жесткий диск	160 ГБ SATA II	320 ГБ SATA II	100 ГБ SATA
Внешние порты ввода/вывода	4хUSB 2.0, VGA, аудиовход/выход, разъем для микрофона, 2хPS/2, RJ-45	6хUSB 2.0, VGA, HDMI, DVI, аудиовход/выход, разъем для микрофона, IEEE 1394b, eSATA, 2хPS/2, RJ-45	2хUSB 2.0, VGA или DVI, аудиовход/ выход, разъем для микрофона, 2хPS/2, RJ-45
Видео	Поддержка DirectX 9, включая: драйвер WDDM; 128 МБ видеопамяти; аппаратный построитель текстуры версии 2.0; цветность 32 бита на пиксел	ATI Radeon HD 4870 или аналог по производительности	Поддержка DirectX 9, включая: драйвер WDDM; 128 МБ видеопамяти; аппаратный построитель текстуры версии 2.0; цветность 32 бита на пиксел
Монитор	LCD 19»	LCD 21»	LCD 13»
Сетевой адаптер	10/100/1000 Ethernet	10/100/1000 Ethernet	10/100/1000 Ethernet + Wi-Fi 802.11g
Дисковод	DVD-RW	DVD-RW	DVD-RW
Устройства ввода/вывода	Оптическая мышь, Клавиатура	Оптическая мышь, Клавиатура	Оптическая мышь
Система мониторинга	Наличие контроля температуры процессора и оборотов вентилятора	Наличие контроля температуры процессора и оборотов вентилятора	Наличие контроля температуры процессора
Гарантия	3 года	3 года	3 года

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

• Монитор LCD цветной, диагональ — не менее 19»;
• Размер шага между пикселями — не более 0,285 мм;
• Рабочее разрешение — не ниже 1280 х 1024;
• Угол просмотра — не хуже чем:

по горизонтали 150 град., по вертикали 140 град.

• Яркость — не ниже 250 кд/м;
• Контрастность — не ниже чем 700:1;
• Время отклика пикселя — не более 20 мс;
• Интерфейс: аналоговый D-sub 15 pin;
• Энергопотребление — не более 35 Вт;
• При прочих равных условиях предпочтение необходимо отдавать мониторам, поддерживающим DDC 2B, соответствующим стандартам ТСО'03, Energy Star (EPA) и DPMS, а также имеющим встроенную веб-камеру.

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

Рекомендуемый перечень ОС следующий:

• Windows;
• Linux.

Минимальные требования к версиям ОС:

• Windows — версии не ниже Windows XP SP3;
• Linux — версии не ниже SUSE Linux Enterprise Server 11 и Red Hat Enterprise Linux 5.3.

Требования к дистрибутиву ОС Linux:

• Выбранный дистрибутив должен обладать следующими характеристиками ОС Linux:
• Совместим с архитектурами х86, AMD64 и ЕМ64Т.
• Поддерживать многопроцессорные SMP-архитектуры и технологию многопоточности Hyper-Threading.
• Использовать ядро ветки 2.6 с поддержкой библиотеки Native POSIX Threading Library (NPTL).
• Иметь компилятор GCC версии не ниже 4.1.
• Быть совместимым со стандартом Linux Standard Base (LSB) 2.0.
• Поддерживать стандарты Web-based Enterprise Management (WBEM) Common Information Model (CIM), Carrier Grade Linux (CGL) 2.0 и Data Center Linux (DCL).

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

N	Вид	Категория	Характеристика	Минимальное значение
	Принтер лазерный монохромный	Персональный	Скорость монохромной печати А4	16 стр./мин. (формат А4)
			Разрешение при печати	600 х 600 точек на дюйм
			Время выхода первого отпечатка	не более 10 с
			Устройство подачи бумаги	150 листов
			Формат бумаги	А4, В5, А5, LTR, Executive, конверты C5/COM10/DL, Monarch
			Интерфейс с ПК	USB 1.1
	Принтер лазерный монохромный	Групповой	Двусторонняя печать	Да
			Скорость монохромной печати А4	28 стр./мин. (формат А4)
			Разрешение при печати	1200 х 1200 точек на дюйм
			Время выхода первого отпечатка	не более 10 с
			Устройство подачи бумаги	300 листов
			Формат бумаги	А4, В5, А5, LTR, Executive, конверты C5/COM10/DL, Monarch
			Интерфейс	FastEthernet
	Принтер лазерный цветной	Групповой	Скорость печати	цветная печать: 20 стр./мин. (формат А4)
			Двусторонняя печать	Да
			Разрешение при печати	600 х 600 точек на дюйм
			Время выхода первого отпечатка	не более 20 с в монохромном и цветном режиме
			Устройства подачи бумаги	500 листов
			Формат бумаги	А4, В5, А5, Legal, LTR, Executive, конверты C5/COM10/DL/Monarch/В5, каталожные карточки
			Интерфейс	FastEthernet
	Принтер	Уровня организации	Требуется применять МФУ	См. требования к МФУ

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

N	Вид	Категория	Характеристика	Минимальное значение
	Сканер	Персональный офисный	Тип	Настольный планшетный
			Сканирование	Черно-белое и цветное
			Оптическое разрешение	3200 х 3200 точек на дюйм
			Интерфейс	USB 2.0
			Разрядность сканирования	24 бита
			Максимальный формат документа	А4
	Сканер	Групповой/Уровня организации	Необходимо использовать МФУ. См. требования к МФУ

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

N	Вид	Категория	Характеристика	Минимальное значение
	МФУ с лазерной печатью	Персональный	Скорость копирования А4	20 копий/мин.
			Разрешение сканирования	1200 х 2400 dpi
			Разрешение печати	600 х 600 dpi
			Разрешение копирования	600 х 600 dpi
			Функции аппарата	печать, сканирование и копирование
			Тип сканера	планшетный
			Время выхода первого отпечатка	не более 10 с
			Устройство подачи бумаги	150 листов
			Формат бумаги	А4, В5, А5, LTR, Executive, конверты C5/COM10/DL, Monarch
			Глубина цветного сканирования	24 бита
			Максимальное количество копий за один цикл	50
			Интерфейс	USB 1.1
	МФУ с лазерной печатью	Групповой	Скорость копирования (1:1, А4)	30 копий/мин.
			Разрешение сканирования	600 х 600 dpi аппаратное
			Разрешение печати	2400 х 600 dpi с интерполяцией
			Функции аппарата	печать, сканирование, копирование, факс
			Автоподача при сканировании	Да
			Время выхода первой копии (1:1, А4)	8 с
			Устройство подачи бумаги	500 листов
			Формат бумаги	А3, А4, В5, А5, Legal, LTR, Executive, конверты C5/COM10/DL/Monarch/ В5, каталожные карточки
			Глубина цветного сканирования	24 бита
			Максимальное количество копий за один цикл	500
			Языки описания страниц	PCL5c, Adobe PostScript 3
			Двусторонняя печать	Да
			Сортировщик копий	Да
			Интерфейс	Fast Ethernet
	МФУ с лазерной печатью	Уровня организации	Скорость копирования (1:1, А4)	50 копий/мин.
			Разрешение сканирования	600 х 600 dpi аппаратное
			Разрешение печати	2400 х 600 dpi с интерполяцией
			Функции аппарата	печать, сканирование, копирование
			Автоподача при сканировании	Да
			Время выхода первой копии (1:1, А4)	8 с
			Устройство подачи бумаги	2500 листов
			Формат бумаги	А3, А4, В5, А5, Legal, LTR, Executive, конверты C5/COM10/DL/Monarch/ В5, каталожные карточки
			Материалы для копирования	Обычная бумага, пленки (прозрачные, матовые и самоклеющиеся), конверты, трансферные материалы, мелованная и металлизированная бумага
			Максимальное количество копий за один цикл	500
			Языки описания страниц	PCL5c, Adobe PostScript 3
			Жесткий диск	20 Гбайт
			Двусторонняя печать	Да
			Сортировщик копий	Да
			Степлер	Да
			Интерфейс	Fast Ethernet

Требования к факсам

N	Вид	Категория	Характеристика	Минимальное значение
	Факсимильный аппарат с лазерной печатью	Персональный	Тип сканера	Полистовой
			Телефонная линия	Коммутируемая телефонная сеть общего пользования
			Устройство автоматической подачи документов	15 листов
			Формат документа	А4
			Разрешение при печати	600 х 600 dpi
			Полутона	256 оттенков серого
			Устройство подачи бумаги	100 листов
			Скорость модема	14,4 Кбит/с
			Проводная телефонная трубка	Да
			Автоответчик	Да
	Факсимильный аппарат с лазерной печатью	Групповой/ Уровня организации	Необходимо использовать МФУ

Приложение № 3

МИНИМАЛЬНЫЕ ТРЕБОВАНИЯ К МУЛЬТИСЕРВИСНОЙ СЕТИ

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

Закупаемое сетевое оборудование должно поддерживать следующие протоколы:

Основные протоколы	Протоколы управления, мониторинга и сбора статистики	Протоколы безопасности
IP (RFC 791) ICMP (RFC 792, 1256) TCP (RFC 793) UDP (RFC 768) TELNET (RFC 854) BootP (RFC 951, 1542) Telnet Client/Server FTP и/или TFTP	SNMP v1/v2/v3 DHCP Client/Server/Relay Syslog NTP Client RMON 1 (4 groups) Policy MIB	DoS Prevention ACLs AAA RADIUS (RFC 2138) SSH v2 Secure Copy v2 802.1x Client

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

• 802.1p Priorities
• 802.1q VLAN Tagging
• 802.1s Multiple Spanning Tree

802.1w Rapid STP

• 802.1x
• 802.3ad Link Aggregation

802.3ae 10 GbE

• Diff Serv
• ECMP (8 Paths)
• GVRP
• IGMP Snooping
• IGMP v3 (RFC 2236).

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

	Коммутатор доступа	Коммутатор уровня распределения	Коммутатор ядра
Многоуровневая коммутация	Базовая функциональность, уровень 2	Полноценная функциональность, уровни 2 и 3	Базовая функциональность, уровни 2 и 3
Полоса пропускания	3,6 Гбит/с	16 Гбит/с	28 Гбит/с
Производительность	2,7 Mpps	13,1 Mpps	21 Mpps
SDRAM	8 Мб	64 Мб	256 Мб
FLASH	4 Мб	32 Мб	64 Мб
Число одновременных VLAN	64	250	2000
Наработка «на отказ» (MTBF)	от 150,000 часов	от 150,000 часов	от 150,000 часов

Все коммутаторы должны:

• Иметь возможность стекирования.
• Быть неблокируемыми.

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

Маршрутизаторы	Пограничные маршрутизаторы
General Routing (RFC 1812)	General Routing (RFC 1812)
RIP v1/v2 (RFC 2453)	RIP v1/v2 (RFC 2453)
RIP ECMP	RIP ECMP
OSPF v2 (RFC 2328)	OSPF v2 (RFC 2328)
OSPF Graceful Restart	OSPF Graceful Restart
OSPF ECMP	OSPF ECMP
OSPF NSSA (RFC 1587)	OSPF NSSA (RFC 1587)
IS-IS (RFC 1195)	IS-IS (RFC 1195)
IS-IS Graceful Restart	IS-IS Graceful Restart
IS-IS ECMP	IS-IS ECMP
VRRP (RFC 2338)	BGP-4 (RFC 1771)
DVMRP	BGP-4 Graceful Restart
PIM-SM	VRRP (RFC 2338)
Route Redistribution	DVMRP
HSRP	PIM-SM
IGRP/EIGRP	Route Redistribution
CDP	HSRP IGRP/EIGRP CDP

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

	Маршрутизатор
Производительность	30 kpps
DRAM	32 Мб
FLASH	8 Мб
Наработка «на отказ» (MTBF)	от 150,000 часов

Закупаемое оборудование Wi-Fi должно обеспечивать:

• стандарт IEEE 802.11g (2,4 ГГц, 54 Мбит/с);
• виртуальные локальные сети (VLAN) — до 16 сегментов;
• приоритеризация трафика;
• роуминг между точками доступа (Proxy Mobile IP);
• протокол 802.1p QoS;
• управление с помощью HTTP интерфейса, командной строки, FTP, TFTP и Telnet.
• протокол SNMP;
• стандарт 802.1Х;
• протокол ЕАР (Extensible Authentication Protocol);
• протокол TKIP (Temporal Key Integrity Protocol)
• локальное и удаленное питание по витой паре;

Приложение № 4

МИНИМАЛЬНЫЕ ТРЕБОВАНИЯ К ИНФРАСТРУКТУРЕ ЦЕНТРОВ ОБРАБОТКИ ДАННЫХ

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

• CPU — последнего имеющего лучшее соотношение «производительность/Ватт/стоимость» поколения. Количество вычислительных ядер и размеры кэш-памяти разных уровней подбираются под задачу с учетом рекомендаций производителя;
• RAM — минимально 2 Гб с возможностью расширения до минимально 12 Гб;
• Видеоподсистема, поддерживаемая используемой ОС;
• Дисковая подсистема:
• SAS/SATA II контроллер, минимально 2 (два) канала;
• Используются диски только с технологией горячей замены (hot swap);
• Двухканальный RAID-контроллер, кэш-память контроллера с автономным энергообеспечением, аппаратная поддержка RAID 0, 1, 1 + 0,5;
• один привод DVD-ROM;
• минимум 2 USB 2.0 порта;
• минимум два сетевых адаптера — Ethernet 10/100/1000 Мбит/с с автоматическим выбором скорости передачи данных;
• наличие удаленного управления по сети Ethernet — выделенный или разделяемый порт;
• возможность установки избыточного блока питания с горячей заменой;
• дизайн для установки в шкаф 19».

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

ОС для обслуживания серверных приложений и промышленных систем рекомендуется выбирать из следующего списка: Windows, Linux, Solaris.

Если какая-либо прикладная система (приложение) требует использовать определенную ОС, не входящую в рекомендованный список, то данное использование возможно при условии, что производитель не допускает использование рекомендованных ОС.

Windows — версии не ниже Windows Server 2003. Рекомендуются версии: Windows Server 2008 R2.

Linux — версии не ниже SUSE Linux Enterprise Server 11 и Red Hat Enterprise Linux 5.

Замечание:

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

Требования к дистрибутиву ОС Linux:

• При выборе дистрибутива ОС Linux рекомендуется отдавать предпочтение дистрибутиву от Novell (SUSE) и RedHat.
• Выбранный дистрибутив должен обладать следующими характеристиками ОС Linux:
• Совместим с архитектурами х86, AMD64 и ЕМ64Т.
• Поддерживать многопроцессорные SMP-архитектуры и технологию многопоточности Hyper-Threading.
• Использовать ядро ветки 2.6 с поддержкой библиотеки Native POSIX Threading Library (NPTL).
• Иметь компилятор GCC версии 3.4.
• Быть совместимым со стандартом Linux Standard Base (LSB) 2.0.
• Поддерживать стандарты Web-based Enterprise Management (WBEM) Common Information Model (CIM), Carrier Grade Linux (CGL) 2.0 и Data Center Linux (DCL).
• Иметь средство виртуализации и создания VPN.
• Поддерживать InfiniBand.

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

Закупаемые телекоммуникационные шкафы должны соответствовать следующим требованиям:

---