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

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

ДЕПАРТАМЕНТ ОБРАЗОВАНИЯ ГОРОДА МОСКВЫ

Государственное бюджетное профессиональное образовательное учреждение города Москвы

«Политехнический колледж им. Н.Н. Годовикова»

Пояснительная записка к дипломному проекту на тему:

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



Содержание

Список сокращений

Введение

Общая часть

1.1 Постановка задачи

1.2 Использование виртуализации

1.3 Анализ существующих решений и выбор платформы виртуализации

1.3.1 OpenVZ

1.3.2 Virtual Iron

1.3.3 Xen Express

1.3.4 Microsoft Virtual Server

1.3.5 VMware ESXi

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

1.5 Архитектура VMware ESXi

Специальная часть

2.1 Разработка архитектуры сети учебного класса

2.2 Антивирусная защита

2.3 Системные требования к аппаратной части для выбранной платформы

2.4 Резервное копирование

2.4.1 VMware Consolidated Backup.

2.4.2 VMware Data Recovery

2.4.3 Скрипт ghettoVCB

2.4.4 Acronis vmProtect 6

2.5 Доступ к виртуальным машинам

2.6 Создание макета учебного класса на основе сервера виртуализации VMwareESXi

Экономическая часть

3.1 Определение себестоимости и цены опытно-конструкторской разработки учебного класса

3.2 Оценка экономической эффективности

3.3 Выводы

Заключение

Список используемой литературы и источников

ПРИЛОЖЕНИЕ



Список сокращений

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

ЦП - Центральный процессор;

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

SMB-SmallandMediumBusiness;

SMP - Symmetric Multi-Processing;

SAN - Storage Area Network;

VPS - Virtual Private Servers;

P2V - Physical-to-Virtual;

WMI - Windows Management Instrumentation;

VMFS - Virtual Machine File System;

VCB - VMware Consolidated Backup;

DHCP -DynamicHostConfigurationProtocol (протоколдинамическойконфигурацииузла);

DNS -Domain Name System (системадоменныхимен);

FTP -FileTransferProtocol (протоколпередачифайлов);

HTTP -Hyper Text Transfer Protocol (протоколпередачигипертекста);

HTTPS -Hyper Text Transfer Protocol Secure (расширенныйпротоколпередачигипертекста);

IP - Internet Protocol (межсетевойпротокол);

LAN-LocalAreaNetwork (локальнаявычислительнаясеть);

MAC-MediaAccessControl (управление доступом к среде);

BIOS - Basic Input Output System;

NAS - Network Attached Storage;

SSH - Secure SHell;

HDD-HardDiskDrive.



Введение

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

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

Все больше наблюдается возрастание интереса к тонким клиентам. Это связано со многими причинами, но в данный момент на первое место выходят требования по безопасности.Тонкие вычисления представляют собой использование стратегии мощного центра обработки данных, такого как Облако вычислений или клиентская виртуализация (с использованием CitrixXenApp , XenDesktop, VMware View, Microsoft Windows Remote Desktop или терминальных услуг Hyper-V, UNIX / Linux или HTML приложений), доступного с более простых, энергосберегающих десктопов или мобильных устройств, а не традиционных ПК.

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

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

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

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

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

1. выбор и обоснование наилучшего решения для виртуализации в учебном заведении;

2. разработка архитектуры учебного класса;

3. разработка системных требований к рабочим местам;

4. разработка и тестирование аппаратно-программной инфраструктуры системы виртуализации.

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



1. Основная часть

1.1 Постановка задачи

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

1. излишнее заполнение дискового пространство файлами и программами из-за использования одного и того же компьютера несколькими лицами;

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

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

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

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

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

Архитектура системы учебного процесса разрабатывалась исходя из следующих исходных данных - имеется 3 учебных класса с персональными компьютерами, по 10 компьютеров в каждом, также на кафедре обучается 5 курсов студентов, по 2 группы на курс, по 15 человек в группе. Было принято решение избавиться от перечисленных выше проблем путем разработки учебного класса кафедры на базе технологии виртуализации. Данное решение позволит повысить ответственность пользователей за свою работу на компьютере, облегчить администрирование, использовать технику, которая для обычных задач уже не пригодна или близка к непригодности, облегчить процесс обучения.

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

1. найти наиболее удобную платформу для реализации учебного класса;

2. разработать архитектуру учебного класса;

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

4. найти наиболее удобное решение терминального доступа на виртуальные машины;

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

6. обеспечить обслуживающий персонал средствами управления виртуальными машинами;

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

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

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



1.2 Использование виртуализации

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

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

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

Еще один важный момент - техническая поддержка. Бесплатные платформы виртуализации существуют либо в рамках сообщества OpenSource, где множество энтузиастов занимаются доработкой продукта и его поддержкой, либо поддерживаются разработчиком платформы. Первый вариант предполагает активное участие пользователей в развитии продукта, составление ими отчетов об ошибках и не гарантирует решения ваших проблем при использовании платформы, во втором же случае, чаще всего, техническая поддержка вообще не предоставляется. Поэтому квалификация персонала, разворачивающего бесплатные платформы, должна быть на высоком уровне[8].

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

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

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

виртуализация учебный класс сервер

1.3 Анализ существующих решений и выбор платформы виртуализации

1.3.1 OpenVZ

Проект OpenVZ представляет собой платформу виртуализации с открытым исходным кодом, развитие которого осуществляет сообщество независимых разработчиков, поддерживаемое компанией SWSoft. Распространяется продукт под лицензией GNU GPL. Ядро платформы OpenVZ входит в состав продукта Virtuozzo, коммерческого продукта SWSoft, обладающего большими, нежели OpenVZ, возможностями. Оба продукта используют оригинальную технику виртуализации: виртуализацию на уровне экземпляров операционной системы. Такой способ виртуализации обладает меньшей гибкостью по сравнению с полной виртуализацией (можно запускать только ОС семейства Linux, поскольку используется одно ядро для всех виртуальных окружений), однако позволяет достичь минимальных потерь производительности (около 1-3 процентов). Системы под управлением OpenVZ нельзя назвать полноценными виртуальными машинами, это скорее виртуальные среды (Virtual Environments, VE), в которых не происходит эмуляции компонентов аппаратуры. Такой подход позволяет лишь устанавливать различные дистрибутивы Linux в качестве виртуальных сред на одном физическом сервере. При этом каждое из виртуальных окружений имеет свои собственные деревья процессов, системные библиотеки и пользователей и может по-своему использовать сетевые интерфейсы.

Виртуальные окружения представляются для пользователей и приложений, работающих в них, практически полностью изолированными средами, которые могут управляться независимо от других окружений. Благодаря этим факторам и высокой производительности, продукты OpenVZ и SWSoftVirtuozzo получили наибольшее распространение при поддержке виртуальных частных серверов (Virtual Private Servers, VPS) в системах хостинга. На основе OpenVZ можно предоставлять клиентам несколько выделенных виртуальных серверов на основе одной аппаратной платформы, на каждом из которых могут быть установлены различные приложения и которые могут быть перезагружены отдельно от других виртуальных окружений.

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

1.3.2 Virtual Iron

Virtual Iron представляет собой платформу виртуализации, не требующую хостовой операционной системы (bare-metal платформа), и направлена на использование в корпоративной среде крупных предприятий. Продукты Virtual Iron обладают всеми необходимыми средствами для создания виртуальных машин, управления ими и их интеграции в производственную информационную среду компании. Virtual Iron поддерживает 32-х и 64-х битные гостевые и хостовые операционные системы, а также виртуальный SMP (SymmetricMultiProcessing), предоставляющий возможность использования нескольких процессоров виртуальными машинами.

Изначально Virtual Iron использовала техники паравиртуализации для запуска гостевых систем в виртуальных машинах, так же как и продукты компании XenSource на основе гипервизора Xen. Использование паравиртуализации предполагает использование в виртуальных машинах специальных версий гостевых систем, исходный код которых модифицирован для запуска их платформами виртуализации. При этом требуется внесение изменений в ядро операционной системы, что для ОС с открытым исходным кодом не является большой проблемой, в то время, как для проприетарных закрытых систем, таких как Windows, это неприемлемо. Большого же прироста производительности в системах паравиртуализации не наблюдается. Как показала практика, производители операционных систем неохотно идут на включение поддержки паравиртуализации в свои продукты, поэтому эта технология не завоевала большой популярности. Вследствие этого, компания Virtual Iron одной из первых стала использовать техники аппаратной виртуализации, позволяющие запускать немодифицированные версии гостевых систем. В данный момент, последняя версия платформы Virtual Iron 4.3 позволяет использовать виртуальные машины на серверных платформах только с поддержкой аппаратной виртуализации.

Продукты Virtual Iron существуют в трех изданиях:

1. Single Server Virtualization and Management;

2. Multiple Server Virtualization and Management;

3. Virtual Desktop Infrastructure (VDI) Solution.

На данный момент бесплатным решением является решение Single Server, которое позволяет установить Virtual Iron на одном физическом хосте в инфраструктуре организации. При этом поддерживается протокол iSCSI, сети SAN и локальные системы хранения.

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

1. 2 Гб RAM;

2. Привод CD-ROM;

3. 36 Гб места на диске;

4. Сетевой интерфейс Ethernet;

5. Поддержка аппаратной виртуализации в процессоре.

Virtual Iron позволяет по достоинству оценить все возможности аппаратной виртуализации и средства управления виртуальными машинами. Бесплатное издание в первую очередь предназначено для того, чтобы оценить эффективность и удобство платформы виртуализации и средств управления. Однако и оно может использоваться в производственной среде предприятия для поддержки внутренних серверов компании. Отсутствие отдельной хостовой платформы позволит не тратиться на приобретение лицензии на хостовую ОС и снижает потери производительности на поддержку гостевых систем. Типичные применения бесплатного издания Virtual Iron - развертывание нескольких виртуальных серверов в инфраструктуре небольшой организации сектора SMB в целях отделения от аппаратуры жизненно важных серверов и повышения их управляемости. В дальнейшем, при покупке коммерческой версии платформы инфраструктура виртуальных серверов может быть расширена, а также могут быть использованы такие возможности, как эффективные средства резервного копирования и «горячей» миграции виртуальных серверов между хостами.

1.3.3 Xen Express

Не так давно компания XenSource выпустила бесплатную версию продукта на основе гипервизора Xen, получившую название Xen Express. Этот продукт существует совместно с бесплатным OpenSource решением Xen, поддержкой которого занимается сообщество независимых разработчиков. Основные возможности Xen Express:

1. поддержка до 4 Гб физической RAM хоста;

2. поддержка до 4 Гб RAM для гостевых систем Windows;

3. поддержка до 2 процессорных гнезд;

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

5. поддержкагостевыхсистем Windows Server 2003; Windows XP; Windows 2000 Server; Red Hat EL 3.6, 3.7, 3.8, 4.1, 4.2, 4.3, 4.4, 5.0; SUSE SLES 9.2, 9.3, 10.1; DebianSarge;

6. поддержка одной графической консоли единовременно.

При этом, хотя сама платформа и является бесплатной, техническая поддержка продукта может быть приобретена дополнительно. Компания XenSource недавно провела масштабное тестирование производительности гипервизора Xen в сравнении гипервизором продукта VMware ESX Server, являющегося на данный момент стандартом де-факто для виртуализации серверов к крупных производственных средах. По результатам исследования гипервизор Xen даже опередил гипервизор ESX сервера на 1.5% при 2-х виртуальных процессорах, проиграв на 4-х процессорах менее одного процента. Тестирование производилось одним из стандартных средств тестирования компьютерных систем SPECjbb2005.

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

1.3.4 Microsoft Virtual Server

Компания Microsoft в 2005 году выпустила коммерческую серверную платформу виртуализации Microsoft Virtual Server 2005 на основе ядра Virtual PC. Этот продукт существовал в двух изданиях: StandartEdition (для сектора SMB) и EnterpriseEdition (для крупных компаний), однако продавался он весьма плохо. Вследствие этого, в апреле 2006 года Microsoft объявила об объединении двух изданий в одно (EnterpriseEdition) и сделала продукт бесплатным. Вместе с этим Microsoft объявила о начале глобальной стратегии по виртуализации и включении виртуализации на основе гипервизора под кодовым названием Viridian в новую версию серверной платформы Windows 2008 “Longhorn”. Сейчас Microsoft готовится к выпуску первого пакета обновлений для продукта Microsoft Virtual Server R2 SP1, в который будут включены средства поддержки аппаратной виртуализации Intel VT и AMD-V.

Сама компания Microsoft так определяет основные варианты использования продукта Virtual Server:

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

2. миграция приложений и их отвязывание от оборудования;

3. консолидация серверного парка предприятия.

В данный момент наибольший интерес представляет использование Virtual Server в связке с продуктом SystemCenter Virtual MachineManager (SCVMM), находящимся сейчас в стадии бета-тестирования, окончательная версия которого будет поддерживать как виртуализацию на основе Virtual Server, так и виртуальные сервера семейства Windows “Longhorn”. Пока же можно бесплатно загрузить с сайта Microsoft вторую бету SCVMM.

Еще одним плюсом Virtual Server является возможность управления сервером виртуализации через Windows ManagementInstrumentation (WMI) и тесная его интеграция с другими продуктами и службами Microsoft. Виртуальные машины на основе Virtual Server могут управляться как посредством тонкого, так и толстого клиента.

Безусловно, продукт Virtual Server можно использовать для поддержания внутренней инфраструктуры виртуальных серверов не только в секторе SMB, но и в крупных организациях. Пока неясно, какой же все-таки будет интегрированная виртуализация в платформу Windows Server 2008, но совершенно точно Microsoft составит хорошую конкуренцию платформам VMware.

1.3.5 VMwareESXi

Компания VMware в данный момент является безусловным лидеров в производстве как серверных, так и настольных платформ виртуализации. В секторе виртуализации серверов VMware предлагает сразу два принципиально различных продукта: бесплатный VMwareESXi и коммерческий VMware ESX. Первый нацелен на сегмент виртуализации для малого и среднего бизнеса, второй же является частью решения для построения виртуальной инфраструктуры в крупной организации. Продукт VMwareESXi разрабатывается компанией VMware уже давно, и ранее носил название VMware GSX Server. Став бесплатным в 2006 году, этот продукт приобрел поистине огромную популярность не только как средство виртуализации серверов, но и, зачастую, используется как настольная платформа виртуализации IT-профессионалами и компаниями-разработчиками ПО.

VMwareESXi обладает всеми необходимыми возможностями для внедрения виртуализации в секторе SMB для поддержания виртуальной инфраструктуры в компании. Список поддерживаемых гостевых операционных систем весьма обширен, а удобство использования продукта позволяет применять его самому широкому кругу пользователей. VMware ESXi поддерживает 32-х и 64-х битные гостевые операционные системы и предоставляет возможности по удаленному управлению виртуальными машинами и виртуальным сервером. VMware ESXi включает в себя поддержку Intel VT, программные интерфейсы для взаимодействия сторонних приложений с виртуальными машинами и может быть запущен в качестве сервиса при старте хостовой системы. Виртуальная машина под управлением VMwareESXi может иметь до 4-х виртуальных сетевых интерфейсов, 32 Гб оперативной памяти и управляться несколькими пользователями. При развитой инфраструктуре виртуальных серверов вам могут понадобиться дополнительные средства управления, которые предоставляет продукт VMware Virtual Center.

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

Для упрощения анализа и восприятия приведена сводная таблица основных особенностей бесплатных платформ виртуализации (таблица 1)[9].



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

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

1.5 Архитектура VMwareESXi

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

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

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

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

Особенности ESXi:

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

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

3. высокая производительность общих хранилищ данных достигается через VMware VMFS;

4. возможность запуска интенсивно использующих ресурсы приложений внутри виртуальных машин с высокими пределами использования ресурсов процессора, памяти, запоминающих устройств. Одна виртуальная машина может использовать до 32 физических процессоров за счёт технологии VMware Virtual SMP;

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

6. достигается высокая готовность класса datacenter, за счёт использования общих хранилищ данных, SAN, встроенной возможности передачи по нескольким направлениям (multipathing) и поддержки MicrosoftClustering Services;

7. безопасность ИТ-инфраструктуры контролируется при помощи технологий LUN zoning и LUN masking, разметки и фильтрации сетевого трафика (VLAN tagging), и обеспечения защиты уровня Ethernet[11].

Таблица 1

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

Название платформы, разработчик	Хостовая ОС	Официально поддерживаемые гостевые ОС	Поддержка нескольких виртуальных процессоров (Virtual SMP)	Техника виртуализации	Типичное использование	Производительность
OpenVZ	Открытый проект сообщества OpenSource при поддержке SWSoft Linux	Различные дистрибутивы Linux	Да	Уровня операционной системы	Изоляция виртуальных серверов (в том числе для услуг хостинга)	Без потерь
Virtual Iron 4.3 Virtual Iron Software, Inc	Не требуется	Windows, RedHat, SuSE	Да (до 8)	Нативная и аппаратная	Виртуализация серверов в производственной среде	Близка к нативной
Virtual Server 2005 R2 SP1 Microsoft	Windows	Windows, Linux (Red Hat и SUSE)	Нет	Нативная и аппаратная	Виртуализация внутренних серверов в корпоративной среде	Близка к нативной (при установленных Virtual MachineAdditions)
VMware Server VMware	Windows, Linux	DOS, Windows, Linux, FreeBSD, Netware, Solaris	Да	Нативная и аппаратная	Консолидация серверов небольших предприятий, разработка	Близка к нативной
Xen Express и Xen XenSource (при поддержке Intel и AMD)	NetBSD, Linux, Solaris	Linux, NetBSD, FreeBSD, OpenBSD, Solaris, Windows, Plan 9	Да	Паравиртуализация, аппаратная виртуализация	Разработчики, тестеры, IT-профессионалы, консолидация серверов небольших предприятий	Близка к нативной (некоторые потери при работе с сетью и интенсивном использовании дисков)



2. Специальная часть

2.1 Разработка архитектуры сети учебного класса

Структурная схема обычного учебного класса показана на рисунке 1.

Рисунок 1 Структурная схема компьютерной сети кафедры

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

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

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

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

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

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

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

1. имени машины;

2. IP-адреса машины.

Предлагается в каждом учебном классе выделить дополнительный, ПК, с установленной на него ОС Windows и клиентом гипервизора vSphereClient, который позволит запускать группы виртуальных машин или единичные машины, тех студентов которые занимаются сейчас в классе или останавливать виртуальные машины после занятий во избежание излишней нагрузки на сервер. Также с помощью vSphereClient оператор сможет создавать новые виртуальные машины из эталонной или с нуля. А также, операторский ПК оснастить программным обеспечением для резервного копирования виртуальных машин.

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

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

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

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

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

2.2 Антивирусная защита

Так как, тонкие клиенты, как правило, базируются на ядре Linux, то вирусная угроза для UNIX-подобных систем значительно ниже, чем для систем Windows. Функционал ядра крайне урезан до необходимых для работы команд, что в принципе ставит под сомнение способность запуска вируса на терминале. В добавок, накопители, подключенные к терминалу, либо "пробрасываются" до виртуальной машины, либо неактивны. То есть основные пути проникновения вирусов, в виде съемных накопителей, на терминале не доступны. Пользователь при выходе в сеть Интернет будет выходить по сути с самой виртуальной машины. Следовательно все загружаемые файлы, среди которых могут отказаться и вирусы, будут попадать исключительно на виртуальную машину.

Если терминал будет запускаться с компакт-диска, вирусная опасность терминалу не будет угрожать. Если и каким-то образом вирус и попадет в память терминала, при следующей загрузке его уже не будет, так как вирус не сможет попасть в постоянную память - записать себя на CD.

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

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

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

2.3 Системные требования к аппаратной части для выбранной платформы

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

1. Intel Core i3-4130; (3МБКэш-памяти, 3.40 ГГц)

2. 1 GBDDR3; 1133МГц;

3. Интегрированный видеоадаптер;

4. HDD 200 ГБ.

Так как сервер виртуализации позволяет перераспределять ресурсы между запущенными машинами, а приложения, выполняемые на рабочих местах находятся на достаточно низком уровне системных требований (текстовые редакторы, графические редакторы, программы для вычислений), то вполне маловероятно, что всем 20 пользователям понадобится вычислительная мощность 20 процессоров, и скорее всего, пики нагрузки на центральный процессор будут у разных пользователей в разные моменты времени, так что вполне достаточным будет использование 2х процессоров с 4-мя ядрами Xeon E5-2603; 1.80 ГГц

Оперативной памяти обычно необходимо 1024Мб или более. В отношении памяти сервер виртуализации позволяет также перераспределять ресурсы, но не стоит забывать о возможном запуске большого количества виртуальных машин, каждой из которых постоянно требуется какой-то минимальный объем. Исходя из минимальных требований в 1024 Мб и ориентировочное количество виртуальных машин в 15 штук, требуется 15360 МБ памяти.

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

С учетом некоторой вероятности повышенного потребления памяти в виде сложных расчетов или при большом количестве запущенных виртуальных машин (возможно даже больше чем реальных рабочих мест) разумно использовать 16384МБ памяти (2048МБ x 8планок).

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

Объем дискового пространства минимально необходимый пользователю составляет 30 ГБ. Но и в отношении дискового пространства Гипервизор позволяет осуществлять перераспределение. Пользователю будет виден и доступен тот объем, который будет указан в параметрах виртуальной машины, но на самом деле на реальном, физическом, диске будет занято столько места, сколько реально занято файлами пользователей.

Оценивая минимально необходимый объем дискового пространства, учитывая, что с первого по пятый курсы на каждом курсе есть две группы. Среднее количество человек в группе равно пятнадцати, т.е. суммарное количество студентов и виртуальных машин составляет 150. При выделении 30 ГБ на одну виртуальную машину минимальный объем дискового пространства сервера составляет 4,5 ТБ. С учетом необходимого запаса и возможностей перераспределения места, в качестве носителя информации с виртуальными машинами предлагается использовать 2 жестких диска по 3 Tb. При нехватке места, предлагается использовать внешние сетевые хранилища данных (NAS, iSCSI).

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

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

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

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

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



2.4 Резервное копирование

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

Резервное копирование виртуальной инфраструктуры является неоднозначно решаемой задачей для большинства администраторов VMwareESX/ESXi. С одной стороны - виртуальные машины можно рассматривать как физические системы и делать бэкап "по старинке" с установкой агентов в гостевые ОС. С другой же стороны независимость виртуальных машин от аппаратного обеспечения серверов позволяет более гибко подходить к резервному копированию виртуальных машин на VMware ESX и пробовать различные способы бэкапа.

В процессе работы были выявлены следующие способы резервного в виртуальной инфраструктуры VMware / vSphere :

1. фреймворк VMwareConsolidatedBackup / vSphereDataProtection API и интеграция этих механизмов с продуктами для резервного копирования сторонних производителей (например, Symantec NetBackup или ARCserve);

2. продукт VeeamBackup, который интегрирован со средствами VMwareConsolidatedBackup / vSphereDataProtection API и позволяет производить не только резервное копирование ВМ на уровне образов и восстановление на уровне образов, отдельных дисков и файлов, но и делать реплики виртуальных машин на других хостах ESX;

3. создание снапшотов LUN в SAN напрямую средствами дисковых массивов или репликация томов в SAN;

4. установка агентов резервного копирования для резервного копирования на уровне файлов и ВМ целиком из гостевой ОС;

5. использование ghettoVCB;

6. продукт Acronis vmProtect 6.

2.4.1 VMwareConsolidatedBackup

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

VCB используется для создания резервных копий виртуальных машин, отдельных серверов VMware ESX Server, а также работает в совокупности со средством управления виртуальной инфраструктурой VMwareVirtualCenter. Поскольку VCB является всего лишь фреймворком для резервного копирования в виртуальной инфраструктуре, требуется либо использование ПО для резервного копирования сторонних производителей для автоматизации задач архивирования (которые поддерживают средства VCB), либо вручную писать сценарии командной строки, добавляя их в планировщик задач Windows.

VCB реализует следующие возможности:

1. создание архивных копий виртуальных машин посредством специального прокси-сервера VCB, который снимает нагрузку по созданию резервных копий с серверов производственной сети LAN за счет операций непосредственно в сети хранения данных SAN;

2. не требует установки дополнительных агентов на серверы ESX и в гостевые ОС;

3. предоставляет широкие возможности по интеграции с продуктами сторонних производителей средств резервного копирования. При этом поддержка многих пакетов уже встроена в VCB (а кроме того и, наоборот, эти продукты имеют VCB-поддержку). Книмотносятся: Symantec Backup Exec, Veritas NetBackup, Tivoli Storage Manager, EMC Networker, CA BrightStoreARCServe, Commvault Galaxy.

На рисунке 3 представлена схема резервного копирования VCB.



Рисунок 3 Принцип работы резервного копирования VCB

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

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

На прокси-сервере VCB мы получаем полноценную резервную копию виртуальной машины, при этом в процессе создания копии не загружается сеть производственной среды LAN, поскольку снапшот делается на системе хранения и по FibreChannel или iSCSI загружается на прокси-сервер. Серверы ESX также нагрузки не испытывают, поскольку все делается только на уровне хранилища, не затрагивая серверную часть, поэтому бэкап виртуальных машин можно делать в течение дня, а не только в периоды наименьшей нагрузки.

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

2.4.2 VMwareDataRecovery

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

Рассмотрим продукт и его связь с фреймворком VMwareConsolidatedBackup (VCB). Новый продукт, наследник VMware Consolidated Backup стал называться VMware vStorage API for Data Protection. А продукт VMwareDataRecovery стал надстройкой (GUI) над VMwarevStorageAPIforDataProtection, которая позволяет делать бэкап из графического интерфейса с поддержкой дедупликации и восстановления виртуальных машин и их файлов.

VMwareDataRecovery полностью интегрирован с VMwarevCenter и управлять резервным копированием можно прямо из консоли vSphereClient. При бэкапе виртуальной машины делается ее снапшот средствами vStorage API (VCB), забирается vmdk-диск и конфигурационные файлы, данные дедуплицируются и складываются на хранилище. При этом:

1. не требуется устанавливать агентов ни на ВМ, ни на хосты VMware ESX;

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

Рисунок 4 Особенности резервного копирования VMwareDataRecovery

Рисунок 5 Устройство архитектуры VMwareDataRecovery

То есть, с точки зрения архитектуры, решения VMwareDataRecovery выглядит так: специальная виртуальная машина (Virtual Appliance импортируемый на vCenter) функционирует на хосте VMware ESX и обеспечивает операции по резервному копированию виртуальных машин и их файлов (не только данного хоста ESX, но и всех остальных). На сервере же VMwarevCenter установлена специальная надстройка VMwareDataRecovery, которая обеспечивает управление бэкапом и восстановлением из vSphereClient. Резервные копии виртуальных машин можно хранить на хранилищах любого типа, включая CIFS/SMB ресурсы.

У резервного копирования VMwareDataRecovery есть следующие особенности:

1. все резервные копии виртуальных машин подлежат дедупликации. Технология дедупликации - собственная от VMware. Поддерживается хранилище емкостью до 2 ТБ;

2. первая резервная копия делается полной, все остальные - инкрементальные;

3. для задачи резервного копирования могут быть определены следующие параметры: источник, целевое хранилище, окно резервного копирования и политика хранения по времени (retentionpolicy). Можно управлять целевым хранилищем (Prepare, Mount, Unmount, Extend);

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

5. при резервном копировании и восстановлении можно выбрать отдельные виртуальные диски машин;

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