Создание центра обработки данных

Размещено на http://www.allbest.ru/

Содержание

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

Введение

1. Постановка задачи на проектирование

1.1 Цель создания центра обработки данных

1.2 Назначение и область применения информационной системы

1.3 Общие требования к центру обработки данных

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

1.5 Требования к организации сетевых сервисов ЦОД

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

1.7 Требования к защите данных в ЦОД

2. Проектирование инфраструктуры и системы защиты ЦОД

2.1 Анализ технического задания и выбор направления решения задачи

2.2 Анализ требований к сетевым сервисам и серверному сегменту

2.3 Анализ требований к подсистеме доступа к внешним сетям

2.4 Планирование применения решений виртуализации

2.5 Планирование сетевой архитектуры ЦОД

2.6 Проектирование вычислительной сети ЦОД

3. Выбор оборудования для реализации проекта

3.1 Выбор серверных платформ и связанных комплектующих

3.1.1 Выбор серверов и сегмента виртуализации

3.1.2 Выбор сервера для подсистемы доступа к внешним сетям

3.2 Выбор систем хранения данных

3.2.1 Комплектация основного хранилища

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

3.3 Выбор сетевого оборудования

3.3.1 Выбор сетевых коммутаторов для серверного сегмента

3.3.2 Выбор коммутаторов для пользовательского сегмента

3.3.3 Выбор маршрутизатора

3.4 Выбор технических устройств защиты ЦОД?

3.4.1 Выбор источника бесперебойного питания

3.4.2 Выбор серверной стойки

3.4.3 Прочие комплектующие расходные материалы

3.4.4 Физическая защита

4. Выбор программных сред для реализации проекта

4.1 Программное обеспечение для работы сетевых сервисов ЦОД

4.1.1 ПО для организации службы каталогов

4.1.2 Файловые сервисы

4.1.3 Веб-сервер

4.1.4 Тернимальные сервисы

4.1.5 Сервисы автоматического присвоения сетевых адресатов хостам

4.1.6. Сервис, обеспечивающий разрешение имен

4.1.7. Сервис для создания резервных копий

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

4.3 Программная среда для реализации системы виртуализации

4.4 Программная защита

5. Реализация безопасной виртуальной инфраструктуры

5.1 Размещение сетевых сервисов в виртуальном пространстве

5.2 Распределение аппаратных ресурсов между гостевыми доменами

5.3 Модель сетевого взаимодействия гостевых доменов в пределах гипервизора

5.4 Сетевое взаимодействие гипервизоров

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

5.6 Обеспечение возобновления работы сетевых сервисов при аппаратных и программных сбоях системы

6. Конфигурирование и настройка

6.1 Конфигурирование сетевого оборудования

6.1.1 Настройка коммутаторов серверном сегменте

6.1.2 Настройка стека маршрутизации

6.1.3 Настройка коммутаторов пользовательского сегмента

6.2 Настройка сетевых хранилищ

6.2.1 Настройка основного сетевого хранилища

6.2.2 Настройка хранилища резервных копий

6.3 Настройка ОС гипервизоров и среды виртуализации XEN

6.3.1 Настройка операционных систем гипервизоров

6.3.2 Настройка среды виртуализации XEN

6.4 Настройка гостевых доменов XEN

6.4.1 Установка паравиртуального гостевого домена

6.4.2 Установка гостевого домена в режиме HVM

6.5 Настройка подсистемы доступа к внешним сетям

7. Организационно экономическая часть

7.1 Составление организационно-календарного плана

7.1.1 Определение общей трудоемкости разработки и этапов ОКП

7.1.2 Распределение трудоемкости по стадиям разработки

7.1.3 Длительность проектных работ

7.2 Расчет себестоимости проекта

7.2.1 Расчет затрат на оплату труда и сопутствующие расходы

7.2.2 Затраты на оборудование

7.2.3 Затраты на программное обеспечение

7.2.4 Затраты на электроэнергию, необходимую для разработки системы

7.2.5 Амортизационные отчисления

7.2.6 Содержание и ремонт оборудования

7.2.7 Накладные расходы

7.2.8 Смета затрат на разработку проекта

7.3 Расчет эффективности проекта

8. Вопросы экологии и безопасности

8.1 Оценка опасных и вредных производственных факторов

8.2 Техника безопасности

8.2.1 Безопасность технологического процесса

8.2.2 Электробезопасность

8.3 Производственная санитария

8.3.1 Микроклимат на рабочем месте

8.3.2 Производственное освещение

8.3.3 Мероприятия по защите от шума

8.3.4 Защита от электромагнитных излучений

8.3.5 Организация рабочего места согласно эргономическим требованиям

8.4 Пожарная безопасность

8.5 Охрана окружающей среды

8.6 Расчет искусственного освещения



Введение

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

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

-Анализ требований к сетевым сервисам и серверному сегменту. В соответствии с ТЗ, ЦОД должен обеспечивать эффективную работу требуемых сервисов, автоматическое восстановление работы сервисов в случае аппаратных или программных сбоев, уменьшить количество непродуктивной работы серверного оборудования.

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

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

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

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

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

1. Постановка задачи на проектирование

1.1 Цель создания центра обработки данных (ЦОД)

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

1.2 Назначение и область применения информационной системы

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

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

Количество отделов может вырасти в процессе работы предприятия.

Количество рабочих мест в каждом отделе так же может увеличиться.

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

1.3 Общие требования к центру обработки данных

ЦОД должен предоставлять возможности эффективного взаимодействия сетевых сервисов предприятия.

ЦОД должен предоставить возможность гибкого масштабирования информационной системы.

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

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

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

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

OОборудование ЦОД должно обеспечиваться электричеством в течение 15 минут после отключения общего электроснабжения.

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

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

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

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

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

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

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

1.5 Требования к организации сетевых сервисов ЦОД

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

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

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

HTTP-сервер для доступа к сайту компании.

Сервисы терминального доступа пользователей компании из внешней сети к внутренним ресурсам предприятия.

Сервисы, обеспечивающие разрешение имен узлов.

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

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

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

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

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

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

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

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

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

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

1.7 Требования к защите данных ЦОД

* Обеспечение непрерывности функционирования всех информационных систем

* Высокая производительность обработки и передачи данных

* Доступность данных и приложений

* Надежность хранения данных, высокая емкость хранения

* Отказоустойчивость

* Катастрофоустойчивость

* Высокая степень масштабируемости всех систем ЦОД (с учетом 5-10 лет активного развития компании)



2. Проектирование инфраструктуры и системы защиты ЦОД

2.1 Анализ технического задания и выбор направления решения задачи

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

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

-Анализ требований к сетевым сервисам и серверному сегменту. В соответствии с ТЗ, ЦОД должен обеспечивать эффективную работу требуемых сервисов, автоматическое восстановление работы сервисов в случае аппаратных или программных сбоев, уменьшить количество непродуктивной работы серверного оборудования.

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

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

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

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

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

2.2 Анализ требований к сетевым сервисам и серверному сегменту

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

-Файловые сервисы для хранения информационных баз с возможностями доступа из внутренней гетерогенной сети компании и из внешних сетей (интернет).

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

-HTTP-сервер для доступа к сайту компании.

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

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

-Сервисы обеспечивающие разрешение имен узлов.

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

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

Служба каталогов - средство иерархического представления ресурсов, принадлежащих некоторой отдельно взятой организации, и информации об этих ресурсах. Имеют распространение следующие службы каталогов: Novell NDS (ОС Novell Netware), OpenLDAP Software (кроссплатформенное ПО), 389 Directory (ОС семейства Red Hat Linux), Active Directory (ОС Microsoft windows). В настоящее время наиболее богатые возможности предоставлены службой каталогов AD DS в серверных ОС Microsoft windows.

Файловые сервисы с открытым исходным кодом для организации доступа в локальных сетях представлены серверами SAMBA и NFS, это программное обеспечение существует для UNIX-подобных ОС.

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

Веб-сервер - это сервер, принимающий HTTP-запросы от клиентов, обычно веб-браузеров, и выдающий им HTTP-ответы, обычно вместе с HTML-страницей, изображением, файлом, медиа-потоком или другими данными. Существует кроссплатформенные реализации HTTP-серверов с открытым исходным кодом.

Так как предприятию нужно использовать терминальный доступ пользователей компании из внешней сети к внутренним ресурсам предприятия, должны быть предоставлены соответствующие сервисы. Такие сервисы представлены множеством служб, например telnet, ssh, vnc, radmin, rdesktop. Существует как проприетарные сервисы терминального доступа, так и ПО с открытым исходным кодом под различные ОС.

Для автоматического присвоения сетевых адресов хостам используются сервисы DHCP (Dynamic Host Configuration Protocol - протокол динамической конфигурации узла) - это сетевой протокол, позволяющий компьютерам автоматически получать IP-адрес и другие параметры, необходимые для работы в сети TCP/IP. Реализации данных серверов существуют под многими операционными системами, включая Linux, Unix, Solaris (с открытым исходным кодом), IOS, windows.

Сервисы, обеспечивающие разрешение имен узлов для IP сетей это сереверы DNS. DNS (Domain Name System - система доменных имён) - компьютерная распределённая система для получения информации о доменах. Чаще всего используется для получения IP-адреса по имени хоста.

Реализации этого сервиса с открытым исходным кодом существует под UNIX-подобными операционными системами.

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

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

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

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

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

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

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

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

- Должен предоставляться единовременный доступ к ресурсу основного хранилища для всех мониторов виртуальных машин.

- Высокое быстродействие основного хранилища для эффективного взаимодействия сервисов.

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

Эти требования исключают возможность использования высокоскоростных DAS-хранилищ, которые могут работать с интерфейсом контроллера дисков напрямую (SAS-контроллер с внешним интерфейсом SFF-8088 поддерживают кабели до 6 метров), так как такой тип подключения предусматривает только монопольный доступ к логическому тому. Решения применения высокоскоростной шины InfinyBand требуют довольно дорогостоящего и специфичного оборудования.

Решения по организации SAN (Storage Area Network, сеть хранения данных) требует для организации дополнительного коммутационного оборудования, организация подобной структуры - обычно довольно дорогостоящая и трудоемкая операция.

Наиболее подходящим решением для организации требуемого хранилища будет использование NAS (Network Attached Storage) хранилища с поддержкой технологии 802.3ad и высокоскоростным дисковым интерфейсом SAS (Serial Attached SCSI), что обеспечит высокое быстродействие и возможности масштабирования системы хранения.

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

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

- Хранилище должно быть территориально удалено от основной информационной системы.

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

Таким образом, для хранилища резервных копий также подходит NAS-хранилище, но с меньшими требованиями к быстродействию.

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

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

2.3 Анализ требований к подсистеме доступа к внешним сетям

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

Функционально подсистема доступа к внешним сетям будет являться шлюзом в интернет с функциями межсетевого экрана (брэндмауэра).

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

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

Доступ в сеть должен предоставляться любому сегменту сети с сокрытием внутренней структуры сети предприятия. Для сокрытия внутренней структуры можно использовать технологию NAT (Network Address Translation - «преобразование сетевых адресов») - это механизм в сетях TCP/IP, позволяющий преобразовывать IP-адреса транзитных пакетов.

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

Для реализации этого функционала можно использовать как аппаратные (например, CISCO PIX Firewall), так и программные решения (Kerio, Netfilter, Uncomplicated Firewall, Outpost и.т.п.).

Наиболее простым и доступным решением для этой роли будет программная реализация данной подсистемы.

Для подобной реализации наиболее подходит надежный межсетевой экран с открытым исходным кодом и широкими возможностями конфигурирования и настройки netfilter/iptables.

С открытым исходным кодом данный сервис представлен мощным и надежным сетевым экраном netfilter и утилитами управления iptables для ОС семейства Linux/Unix. Поддержка других необходимых сетевых протоколов для доступа к сети и маршрутизации так же в полной мере реализована в ОС Linux/Unix.

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

Так же одним из требований было обеспечение отказоустойчивости подключения на уровне каналов связи. Для этого можно добавить и сконфигурировать дополнительный физический сетевой интерфейс и добавить скрипты проверки состояния канала связи. Концепция подключения показана на рисунке 4.1.

Рисунок 4.1 "Концепция изоляции сервисов с подсистемой доступа к внешним сетям"

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

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

2.4 Планирование применения решений виртуализации

Виртуализация - это процесс представления набора вычислительных ресурсов, или их логического объединения, который даёт какие-либо преимущества перед оригинальной конфигурацией. Помимо широко применяемых возможностей виртуализации отдельных вычислительных ресурсов компьютера (виртуальная память, виртуальна файловая система, виртуальный режим работы процессора V86-mode) существует так же возможность преобразовать («виртуализировать») аппаратные ресурсы компьютера, включая ЦП, ОЗУ, жесткий диск и сетевой контроллер, для создания полнофункциональной виртуальной машины, на которой можно установить отдельную ОС и выполнять приложения, как на «физическом» компьютере.

Общий принцип такой виртуализации показан на рисунке 4.2.

Рисунок 4.2 "Модель работы гипервизора"



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

- Повышение отказоустойчивости.

- Возможность плавного обновления и наращивания аппаратной платформы.

- Увеличение возможностей масштабирования информационной системы.

- Изоляция служб.

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

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

Недостатки решений виртуализации:

- Сложность реализации.

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

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

- Снижение производительности гостевых ОС (с применением технологий "паравиртуализации" и "аппаратной виртуализации" потери производительности минимальны).

В структуре ЦОД для достижения описанных преимуществ можно виртуализировать весь серверный сегмент за исключением подсистемы доступа к внешним сетям (что заранее оговорено в ТЗ). Виртуализация сервисов ЦОД должна происходить с учетом отсутствия потерь функциональных качеств сетевых сервисов. С учетом предварительного планирования виртуальной среды недостатки систем виртуализации возможно свести к минимуму.

Таким образом, применение решений виртуализации возможно при использовании ПО мониторов виртуальных машин (гипервизоров) с открытым исходным кодом (согласно требованию ТЗ к сервисам). Подобные решения виртуализации представлены гипервизорами OpenVZ, KVM (Kernel-based Virtual Machine) и XEN, каждый из которых обладает высоким быстродействием и широкими возможностями конфигурирования. Важным требованием к системе виртуализации является поддержка операционных систем, которые будут использованы для выполнения требуемых сервисов.

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

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

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

2.5 Планирование сетевой архитектуры ЦОД

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

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

Исходя из требований сервисов, работа которых необходима согласно требованиям технического задания, для создания сети ЦОД нужно использовать технологию "Ethernet". Ethernet - в настоящее время наиболее популярная в мире технология для передачи данных. Популярность обеспечивается простыми, надежными и недорогими технологиями. Стандарты Ethernet определяют проводные соединения и электрические сигналы на физическом уровне, формат кадров и методы управления доступом к среде (CSMA/CD).

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

На уровне общего логического взаимодействия узлов внутри ЦОД, с учетом узла маршрутизации, который необходим для разделения сети на сегменты, исходя из требований технического задания, топология будет гибридной (древовидной), структура отражена на рисунке 4.3.

Рисунок 4.3 "Логическая топология взаимодействия сетевых сегментов"



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

2.6 Проектирование вычислительной сети ЦОД

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

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

- Снижается загрузка сети: трафик будет сосредоточен внутри одной подсети, разгружая таким образом всю остальную сеть.

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

Деление на подсети обычно выполняют в соответствии с физическим расположением сетевых узлов.

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

Исходя из приведенных условий, в сетевую среду надо добавить еще один уровень сегментации, основанный на технологии VLAN (Virtual Local Area Network, виртуальная локальная компьютерная сеть).

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

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

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

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

В результате должно быть 4-е подсети для пользовательских отделов, каждой из которой присвоен vlan id. И серверные подсети, с собственными уникальными идентификаторами. Пример схемы сегментирования показан на рисунке 4.4.

Рисунок 4.4 "Сегментация сети на уровне VLAN"

В результате деления сети ЦОД на подсети и сегментированию VLAN достигается большая степень административного контроля вследствие наличия устройства, осуществляющего маршрутизацию между сетями VLAN на 3-м уровне OSI. Достигается уменьшение потребление полосы пропускания по сравнению с ситуацией одного широковещательного домена. Сокращается непроизводственное использование CPU за счет сокращения пересылки широковещательных сообщений. Значительно уменьшается вероятность широковещательных штормов в сети и предотвращается возникновение петель между сетевыми узлами.

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

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

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

Можно реализовать отказоустойчивость, используя технологии агрегирования (объединение) каналов либо STP (Spanning Tree Protocol, протокол остовного древа).

STP позволит сделать резервирование коммутатора, однако - у такого решения есть недостаток: в отдельно взятый момент времени будет работать один из каналов.

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

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

Учитывая возможности применения решений виртуализации, сетевые сервисы будут располагаться в отдельном физическом серверном пуле, который будет находиться в отдельном сегменте сети и взаимодействовать с остальной сетью через отдельные линии связи. Коммутационное оборудование на этом участке будет загружено множеством сетевых сессий, как между самими серверами, так и в случае клиент-серверного взаимодействия. Для устранения "узких мест" и изоляции системы виртуализации в этом участке сети надо использовать несколько сетевых интерфейсов для сообщения между собой мониторов виртуализации и виртуальных машин между собой и остальной сетью. Для увеличения быстродействия на этих участках можно использовать агрегацию каналов связи. Агрегация должна быть на участке взаимодействия самих серверов, так и на участке взаимодействия серверов с узлом маршрутизации. Для реализации этих возможностей сервера должны иметь несколько сетевых интерфейсов, ОС системы виртуализации и сетевое оборудование должно поддерживать технологию 802.3ad. Это надо предусмотреть при выборе аппаратной конфигурации оборудования ЦОД.

Управляющие компьютеры операторов могут располагаться в серверном сегменте сети, согласно ТЗ. Это избавит сеть от трансляции запросов с этого оборудования через узел маршрутизации.

Схема логической организации такой сети показана на рисунке 4.5.

Рисунок 4.5 "Упрощенная схема сети ЦОД"

Для того чтобы DHCP сервер обеспечивал автоматическое присвоение IP-адресов хостам надо чтобы DHCP-запросы клиентов транслировались в серверную подсеть к DHCP серверу. Для этого сетевое оборудование на участке клиент - маршрутизатор - DHCP-сервер должно поддерживать технологию "DHCP relay option 82".

Коммутационный стек должен быть создан на уровне узла коммутации (sw1) а так же узла маршрутизации (rt1). Агрегация каналов для реализации отказоустойчивости на уровне каналов связи ЦОД должна быть использована на уровне коммутационного оборудования, подсистемы доступа к внешним сетям, сетевых хранилищ (NAS), а так же серверов виртуализации.



3. Выбор оборудования для реализации проекта

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

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

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

- Выбор серверных платформ и связанных комплектующих.

- Выбор систем хранения данных.

- Выбор сетевого оборудования.

- Выбор дополнительного оборудования.

Примечание: цены всего оборудования для центра обработки данных указаны на период "Май, 2011 год".

3.1 Выбор серверных платформ и связанных комплектующих

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

- надежность;

- гарантированное хранение данных;

- приспосабливаться под растущую нагрузку;

- обеспечение бесперебойной работы.

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

3.1.1 Выбор серверов сегмента виртуализации

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

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

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

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

- Канал данных основного серверного сегмента.

- Канал для взаимодействия гипервизоров (пространство этого сегмента тоже должно быть изолировано).

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

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

Таким образом, для сегмента виртуализации были выбраны две серверные платформы "Intel 2U SR2600URBRPR". Характеристики платформы приведены в таблице 5.1:

Таблица 5.1

"Описание платформы"
Производитель	INTEL
Модель	SR2600URBRP
Описание	Серверный корпус SR2600 с установленной в нем платой S5520UR
Чипсет мат. Платы	Intel 5520 + 82801IJR (ICH10R))
"Процессор"
Гнездо процессора	Socket LGA1366 x2
Поддержка типов процессоров	1 или 2 процессора Intel Xeon серии 55xx, 56xx (Nehalem-EP, Westmere)
"Видео"
Видео	ServerEngines Pilot II, видеопамять 8 Мб.
"Поддержка памяти"
Количество разъемов DDR3	12 (по 6 на каждый процессор)
Тип поддерживаемой памяти	Registered DDR3, DDR3. Максимальная поддерживаемая пропускная способность памяти указана в описании процессора.
"Конфигурация"
Отсеков 2,5 дюйма	Возможна установка 2 HDD при установке приобретаемого отдельно комплекта ASR2600FXDRV. Установленные таким образом устройства подключаются к SATA коннекторам на материнской плате
Внешних отсеков 3,5 дюйма	5 отсеков для SAS или SATA HDD с возможностью горячей замены, с возможностью установки 6-ого отсека при использовании приобретаемого отдельно комплекта ASR2500SIXDRV. Для использования SAS HDD необходим приобретаемый отдельно SAS контроллер.
Оптический привод	Нет. Возможна установка низкопрофильного оптического SATA привода (для ноутбука) AXXSATADVDROM или AXXSATADVDRWR
FDD	Нет. Возможна установка SATA привода для ленточных накопителей при помощи комплекта ASR2500SATAPE
Интегрированный RAID-контроллер	Встроен в чипсет, возможно построение RAID массивов уровней 0, 1, 10 из Serial ATA устройств, возможна поддержка RAID5 при установке приобретаемого отдельно ключа AXXRAKSW5
"Коммуникации"
Сеть	2х канальный контроллер Intel 82575EB 10/100/1000 Мбит/с
"Интерфейс, разъемы и выходы"
Разъем на объединительной плате	SATA
Количество разъемов PCI-X/PCI-64	2, переходная плата ASR26XXFHXR для установки двух полноразмерных карт расширения устанавливается вместо 3 слотов для полноразмерных карт PCI-E. 3 при использовании приобретающейся отдельно переходной платы ASR26XXFH3XR, без возможности использования PCIExpress слотов.
Количество разъемов PCI Express 2.0	1 слот 16x, 2 слота 8x (переходная плата ASR26XXFHR для установки 1 полноразмерной 16х платы, двух полноразмерных 8х слотов в комплекте). Слот 16х работает в режиме 8х. Возможна установка приобретаемой отдельно переходной платы ASR26XXFHLPR для установки 3 полноразмерных (1 16х + 2 8х) и 2 низкопрофильных 8х плат
Serial ATA-II	6 каналов с возможностью подключения 6и устройств. Возможна установка SATA ленточного накопителя при помощи приобретаемого отдельно комплекта ASR2500SATAPE
Разъемы на передней панели	1 USB порт, 1 разъем для подключения VGA монитора (дублирует порт на задней стенке).
Разъемы на задней панели	4x USB 2.0, 1x RJ-45 COM, 2x RJ-45 LAN, 1x VGA монитор
"Питание"
Блок питания	С горячей заменой резервных модулей после установки приобретаемого отдельно резервного модуля AXX750WPS
Мощность блока питания	750 Вт
"Потребительские свойства"
Высота	2U
Охлаждение	3 вентилятора (фиксированных) в центре корпуса. Возможна замена на комплект из 6 вентиляторов с горячей заменой и резервированием ASR2600LXFANS, радиаторы для процессоров в комплекте.
Установка в стойку 19"	Возможна установка корпуса на продающиеся отдельно телескопические рельсы AXXHERAIL2 при этом кабели можно уложить на раскладную опору AXXRACKARM2.
Размеры упаковки	89 x 56.5 x 21.5 см
Вес брутто	20 кг
Рабочая температура	10°C - 35°C

Розничная цена одной такой платформы за наличный расчет по прайсу компании НИКС составляет 36 819 руб.

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

Дополнительным требованием к процессору будет поддержка аппаратной виртуализации. Для серверных процессоров Intel Xeon эта технология называется Intel VT (Intel Virtualization Technology). Серверные платформы двухпроцессорные, поэтому для каждого сервера необходимо приобрести два процессора Intel Xeon, совместимых с сокетом LGA1366.

Все эти цели при умеренной стоимости отлично реализованы в процессоре CPU Intel Xeon X5660. Характеристики процессора:

Таблица 5.2

"Основные характеристики"
Производитель	Intel
Модель	Xeon Processor X5660
Описание	Процессор для двухпроцессорных серверов и рабочих станций.
Частота работы процессора	2.8 ГГц или до 3.2 ГГц в режиме Turbo Boost
Уникальные технологии	наборы инструкций: SSE, SSE2, SSE3, SSE4.2, Аппаратное ускорение шифрования AES, EVP (Enhanced Virus Protection или Execute Disable Bit), Intel Virtualization Technology (VT-x), Intel Trusted Execution Technology
Частота шины CPU	6400 МГц
Ядро	Westmere
Рассеиваемая мощность	95 Вт
Критическая температура	81.3 °C
Технология	0.032 мкм
Гнездо процессора	Socket LGA1366
Кэш L1	64 Кб x6
Кэш L2	256 КБ x6
Кэш L3	12 Мб
Поддержка Hyper Threading	Да
Поддержка 64 бит	Да
Количество ядер	6
"Поддержка памяти"
Тип поддерживаемой памяти	MetaSDRAM, Registered DDR3, DDR3 PC3-6400 (DDR3-800), PC3-8500 (DDR3-1066), PC3-10600 (DDR3-1333), трехканальный контроллер
Официально поддерживаемые стандарты памяти	PC3-10600 (DDR3 1333 МГц), PC3-8500 (DDR3 1066 МГц), PC3-6400 (DDR3 800 МГц)
Max объем оперативной памяти	288 ГБ
Поддержка ECC	Есть (Возможно использование памяти как с поддержкой ECC, так и без)

Примечание: для совместимости процессора с системной платой может потребоваться перепрошивка BIOS.

Розничная цена одного процессора Intel Xeon X5660 за наличный расчет по прайсу компании НИКС, составляет 36 847 руб. Цена двух подобных процессоров (для одной платформы) 73 694 руб.

В комплекте с процессором не поставляется система охлаждения (процессорный кулер), поэтому подобную систему надо приобретать отдельно. Для серверных корпусов необходимы специальные низкопрофильные кулеры. Под используемый разъем процесора типа socket-1366 подойдет кулер модели TITAN <TTC-NK95TZ/NPW[RB]>. Это надежный кулер с тепловыми трубками имеет наработку на отказ более 7 лет.

Розничная цена одной системы охлаждения TITAN <TTC-NK95TZ/NPW[RB]> за наличный расчет по прайсу компании НИКС, составляет 645 руб. Цена двух кулеров (для двух процессоров) 1290 руб.

Требованием к модулям оперативной памяти, приобретаемой для сервера будет опция Registered (такие модули рекомендованы для систем с 4 и более ГБ ОЗУ) и поддержка технологии ECC (Error Correct Code - алгоритм выявления и исправления случайных ошибок ошибок "на лету"). Для серверов актуально использовать модули памяти "проверенных" производителей (что не исключает тесты памяти после приобретения модулей). Для каждого процессора будет использовано по три модуля памяти объемом 8GB модели Kingston ValueRAM <KVR1333D3D4R9S/8G> .

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

Таблица 5.3

"Основные характеристики"
Производитель	Kingston
Модель	KVR1333D3D4R9S/8G
Объем памяти	8 Гб
Частота функционирования	до 1333 МГц
Тип	Registered DDR3
Стандарт памяти	PC3-10600 (DDR3 1333 МГц)
Тайминги	9-9-9
Поддержка ECC	Есть

Итого 48GB ОЗУ для каждого сервера (поддержка подобных объемов памяти должна быть гарантирована программной средой). Это обеспечит отличный запас производительности и масштабируемости виртуального сегмента сети.

Розничная цена одного модуля памяти KVR1333D3D4R9S/8G за наличный расчет по прайсу компании НИКС, составляет 6011 руб. Цена 6-и подобных модулей памяти (для одной платформы) 36 066 руб.

Основные требования к локальным накопителям для серверных платформ, это надежность и производительность. Дополнительным требованием. согласно техническому заданию является отказоустойчивость системы хранения данных. Для этого следует организовать локальные накопители каждого сервера в массив RAID (redundant array of independent disks - избыточный массив независимых жёстких дисков).

Так как основная информация будет храниться в отдельном хранилище данных, локальные накопители серверов будут использоваться только для хранения и загрузки операционных систем мониторов виртуализации, файлов конфигурации, разделов подкачки и прочей связанной информации. Для этого не требуется больших объемов накопителя. Отказоустойчивость можно реализовать путем зеркалирования информации на двух дисках (массив raid-1), выбранная серверная платформа имеет аппаратную поддержку этой технологии. Требования скорости можно удовлетворить, использовав для локальных накопителей относительно небольшие по объему, но имеющие высокое быстродействие SSD (solid-state drive) твердотельные накопители. Для этой цели отлично подойдут очень быстрые и надежные накопители OCZ Vertex 3 <VTX3-25SAT3-120G> объемом 120GB.

Характеристики этого накопителя:

Таблица 5.4

"Основные характеристики"
Производитель	OCZ
Модель	120 Гб Vertex 3 VTX3-25SAT3-120G
Отличительная особенность	Бесшумный, энергоэффективный, с малым тепловыделением
Тип чипов	MLC (Multi Level Cell)
Формат HDD	2.5"
"Параметры производительности"
Скорость чтения	До 550 МБ/сек
Скорость записи	До 500 МБ/сек
IOmeter, скорость записи 4Кб файлов, глубина очереди=32	60000 IOPS
"Интерфейс, разъемы и выходы"
Пропускная способность интерфейса	6 Гбит/сек
"Интерфейс"
Интерфейс SSD	SATA 6Gb/s

Примечание: Крепеж для установки устройства 2.5" в отсек 3.5" идет в комплекте с накопителем.

Выбранный SSD имеет внутреннюю скорость чтения/записи порядка 500 МБ/сек, что более чем в 10 раз больше чем у обычного HDD (78 МБ/сек).

Заявленная производителем наработка на отказ - 2 млн. часов. Для организации массива RAID-1 для каждого сервера нужно 2-а таких накопителя.

Розничная цена одного накопителя OCZ Vertex 3 <VTX3-25SAT3-120G> за наличный расчет по прайсу компании НИКС, составляет 9797 руб. Цена 2-х подобных накопителей (для одной платформы) 19594 руб.

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

Для этого подойдет модель привода DVD±R/RW & CDRW Pioneer DVR-TD10 с SATA интерфейсом.

Розничная цена одного оптического привода Pioneer DVR-TD10 за наличный расчет по прайсу компании НИКС, составляет 870 р.

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

Дополнительно, для доступа к внешнему хранилищу и организации внутренней подсети между мониторами виртуальных машин нужна надежная и быстрая сетевая карта с поддержкой объединения каналов. Для этого подойдет сетевая плата Intel <EXPI9402PT> PRO/1000 PT Dual Port. Плата сделана на чипе Intel 82571EB, имеет два порта 10/100/1000 Мбит/сек и подключается к порту PCI Express x4.

...