Как написать дипломную работу по созданию современной IT-инфраструктуры от анализа до защиты

Смысловой блок: Введение. Постановка проблемы и определение вектора исследования

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

Актуальность исследования заключается в том, что переход к автоматизированному управлению инфраструктурой с помощью современных инструментов и подходов, таких как Infrastructure as Code (IaC), является не просто технологическим трендом, а насущной необходимостью для обеспечения конкурентоспособности, надежности и безопасности. Инженеры и разработчики должны владеть актуальными методами построения IT-систем, чтобы гарантировать их стабильное функционирование и защиту.

Целью данной работы является создание комплекса быстрого развертывания типовой информационной инфраструктуры на основе практик Infrastructure as Code.

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

1. Определить назначение, цели и основные задачи создаваемого комплекса.
2. Описать состав автоматизируемых процедур и процессов.
3. Проанализировать существующие подходы и выбрать оптимальные технические и программные решения.
4. Разработать детальную архитектуру комплекса автоматизированного развертывания.
5. Реализовать прототип системы и доказать его работоспособность.
6. Рассчитать показатели надежности и экономической эффективности внедрения.

Объектом исследования выступают процессы управления жизненным циклом ИТ-инфраструктуры, а предметом исследования — комплекс средств автоматизации, основанный на технологиях Ansible, Docker и Kubernetes, для управления этими процессами.

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

Глава 1. Аналитический обзор современных подходов к управлению ИТ-инфраструктурой

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

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

Концепция Infrastructure as Code (IaC)

Ключевой парадигмой современного управления является Infrastructure as Code (IaC) — подход, при котором управление и предоставление инфраструктуры (серверов, сетей, баз данных) осуществляется через машиночитаемые файлы с кодом, а не через ручную настройку. Это позволяет хранить конфигурацию в системе контроля версий (например, Git), отслеживать изменения, проводить ревью кода и многократно воспроизводить идентичные окружения, что кардинально повышает надежность и скорость работы.

На рынке существует несколько основных инструментов для реализации IaC, каждый со своими особенностями:

• Ansible: Система управления конфигурациями, отличающаяся безагентной архитектурой (не требует установки специального ПО на управляемые узлы) и низким порогом входа благодаря использованию YAML для описания сценариев (плейбуков).
• Terraform: Инструмент для создания и управления инфраструктурой в облачных и локальных средах. Его сильная сторона — управление жизненным циклом ресурсов («создать», «изменить», «удалить»).
• Puppet/Chef: Более старые системы управления конфигурациями, использующие агентную архитектуру и требующие более глубоких знаний для эффективного применения.

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

Контейнеризация и оркестрация

Подход IaC идеально дополняется технологиями контейнеризации и оркестрации. Docker позволяет «упаковывать» приложения и их зависимости в легковесные, изолированные контейнеры, которые гарантированно одинаково работают в любой среде. Kubernetes, в свою очередь, является системой оркестрации, которая управляет жизненным циклом этих контейнеров в масштабе: развертывает, масштабирует, обеспечивает отказоустойчивость и распределяет нагрузку.

Практики CI/CD (Continuous Integration/Continuous Deployment) являются логическим завершением этой экосистемы. Они автоматизируют процесс сборки, тестирования и развертывания кода при каждом изменении, связывая воедино систему контроля версий, инструменты сборки и систему управления инфраструктурой.

Таким образом, по результатам анализа в качестве технологического стека для решения поставленных задач был выбран комплекс из Ansible для управления конфигурациями, Docker для контейнеризации приложений и Kubernetes для их оркестрации, интегрированный в единый CI/CD-процесс.

Глава 2. Формирование требований и разработка технического задания

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

Анализ бизнес-процессов «As Is» (Как есть)

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

• Разработчик пишет код на локальной машине.
• Системный администратор вручную создает виртуальную машину.
• Администратор настраивает на ней операционную систему, веб-сервер, базу данных.
• Разработчик копирует код на сервер и запускает его.

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

Бизнес-требования к системе «To Be» (Как будет)

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

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

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

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

1. Назначение и цели системы: Автоматизация процессов сборки, тестирования и развертывания ПО для повышения скорости и надежности разработки.
2. Характеристики объекта автоматизации: Описание существующей инфраструктуры и процессов предприятия.
3. Требования к системе:
   • Функциональные: Система должна обеспечивать автоматический запуск CI/CD пайплайна по коммиту в Git, сборку Docker-образов, запуск тестов, развертывание в Kubernetes.
   • Нефункциональные: Система должна обеспечивать отказоустойчивость развернутых приложений, возможность горизонтального масштабирования, сбор логов и метрик.
4. Состав и содержание работ по созданию системы: Проектирование архитектуры, реализация компонентов, тестирование, внедрение.
5. Порядок контроля и приемки: Критерии, по которым работа будет считаться выполненной (успешное прохождение тестов, демонстрация полного цикла развертывания).

Глава 3. Проектирование архитектуры комплекса автоматизированного развертывания

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

Общая логическая схема

Решение представляет собой интегрированный CI/CD конвейер. Его работа выглядит следующим образом:

1. Разработчик отправляет код в Git-репозиторий (например, GitLab).
2. GitLab CI автоматически запускает пайплайн.
3. На этапе сборки создается Docker-образ приложения.
4. На этапе тестирования запускаются юнит- и интеграционные тесты внутри контейнера.
5. В случае успеха, на этапе деплоя, Kubernetes получает команду развернуть новую версию приложения, используя свежесобранный образ.

При этом Ansible используется как вспомогательный инструмент для первоначальной подготовки и конфигурации узлов кластера Kubernetes, установки необходимого ПО (Docker, Kubelet) и управления конфигурациями, не входящими в область ответственности Kubernetes.

Компоненты архитектуры

• Сетевая инфраструктура: Проектируется отдельная виртуальная сеть (VLAN) для кластера Kubernetes с подсетями для узлов и сервисов. Настраиваются правила файрвола для контроля трафика.
• Структура Ansible-проекта: Проект организуется с использованием ролей для логического разделения задач (например, роль `common` для базовой настройки ОС, `docker` для установки Docker, `kubernetes` для настройки кластера). Секретные данные (пароли, токены) шифруются с помощью Ansible Vault.
• CI/CD Пайплайн (GitLab CI): Описывается в файле `.gitlab-ci.yml`. Включает стадии: `build`, `test`, `deploy-staging`, `deploy-production`. Переход на production может быть как автоматическим, так и по ручному подтверждению.
• Шаблоны Dockerfile: Создаются стандартизированные Dockerfile для разных типов приложений (например, Python/Django, Node.js), что ускоряет подключение новых сервисов.
• Манифесты Kubernetes: Разрабатываются шаблоны для основных объектов Kubernetes:
  • Deployment: Описывает желаемое состояние приложения (сколько реплик, какой образ использовать).
  • Service: Обеспечивает сетевой доступ к приложению внутри кластера.
  • Ingress: Управляет внешним доступом к сервисам, обычно для HTTP/HTTPS трафика.
  • ConfigMap / Secret: Позволяют отделять конфигурацию и секретные данные от кода приложения.

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

Глава 4. Практическая реализация и описание процесса внедрения

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

Пошаговая инструкция по реализации

1. Настройка базовой инфраструктуры: Создание виртуальных машин для узлов кластера Kubernetes (один мастер, несколько рабочих узлов) и отдельной машины для GitLab Runner, который будет выполнять задачи CI/CD.
2. Конфигурация с помощью Ansible:

   Приводится листинг основного плейбука Ansible, который поочередно применяет роли ко всем хостам. Например, плейбук для установки Docker и компонентов Kubernetes (`kubelet`, `kubeadm`, `kubectl`) содержит задачи на добавление репозиториев, установку пакетов и запуск сервисов. Комментарии в коде объясняют назначение каждого шага.

   # tasks/main.yml — Пример задачи в роли Ansible
   — name: Install required packages
     apt:
       name: [‘docker-ce’, ‘kubelet’, ‘kubeadm’]
       state: present
       update_cache: yes

3. Написание Dockerfile и сборка образов: Демонстрируется создание типового Dockerfile для простого веб-приложения. Показывается, как с помощью команды `docker build` создается образ и загружается в репозиторий образов (Container Registry), встроенный в GitLab.
4. Конфигурация CI/CD пайплайна: Приводится пример файла `.gitlab-ci.yml`. В нем описываются этапы (stages) и задания (jobs). Например, задание `build` выполняет команду `docker build`, а задание `deploy` — `kubectl apply` для применения манифестов Kubernetes.
5. Развертывание приложения в Kubernetes:

   Показаны примеры YAML-манифестов для Deployment и Service. С помощью команды `kubectl apply -f deployment.yml` приложение разворачивается в кластере. Демонстрируется, как проверить статус развертывания командой `kubectl get pods`.

В завершение главы описывается полный цикл работы системы: разработчик делает `git push` в свою ветку, GitLab автоматически запускает пайплайн, собирает образ, прогоняет тесты и, после слияния с основной веткой, выкатывает новую версию на тестовый стенд. Это наглядно доказывает работоспособность созданного комплекса.

Глава 5. Тестирование и оценка надежности разработанного комплекса

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

Методика тестирования

Тестирование включает несколько видов проверок:

1. Функциональное тестирование: Проверяется корректность работы всех функций, заявленных в ТЗ. Создается чек-лист, по которому проверяется каждая функция:
   • Запускается ли пайплайн после коммита?
   • Успешно ли собирается Docker-образ?
   • Корректно ли отрабатывают автотесты?
   • Разворачивается ли приложение в кластере без ошибок?
2. Нагрузочное тестирование: С помощью инструментов, таких как JMeter или k6, на развернутое приложение подается симулированная нагрузка (например, 100 одновременных пользователей). В процессе отслеживаются ключевые метрики: время ответа, количество ошибок, загрузка CPU и памяти на узлах кластера. Это позволяет оценить, как инфраструктура справляется с нагрузкой и где находятся ее узкие места.
3. Тестирование на отказоустойчивость: Это ключевой тест для проверки надежности. Проводится имитация сбоев, чтобы убедиться, что система способна их пережить. Например, выполняется принудительное выключение одной из рабочих нод кластера Kubernetes. Ожидаемый результат: Kubernetes должен автоматически перезапустить поды с упавшей ноды на другой, работающей, и сервис должен остаться доступным для пользователей с минимальным или нулевым простоем.

Расчет показателей надежности

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

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

Глава 6. Расчет экономической эффективности внедрения

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

Расчет затрат

Затраты делятся на две категории:

• Капитальные затраты (CAPEX): Единовременные вложения на этапе создания системы.
  • Стоимость рабочего времени DevOps-инженера на проектирование и реализацию (основная статья расходов).
  • Стоимость лицензий на ПО (в данном случае минимальна, так как используется Open Source).
  • Затраты на облачные ресурсы или оборудование на этапе разработки.
• Операционные затраты (OPEX): Регулярные расходы на поддержание работы системы.
  • Стоимость эксплуатации облачных ресурсов (виртуальных машин кластера).
  • Затраты рабочего времени на поддержку и обновление системы.

Расчет выгод

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

• Прямая экономия: Это наиболее легко измеряемая выгода. Рассчитывается экономия человеко-часов, которые раньше тратились на рутинные задачи.
  

  Пример: Если раньше 2 системных администратора тратили 20% своего времени (8 часов в неделю каждый) на ручное развертывание, то внедрение автоматизации высвобождает 16 часов в неделю. Экономия = 16 часов/неделю * 4 недели/месяц * часовая ставка инженера.

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

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

Смысловой блок: Заключение. Итоги и перспективы развития

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

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

• Проведен детальный анализ современных подходов к управлению инфраструктурой, на основе которого был обоснован выбор технологического стека: Ansible, Docker и Kubernetes.
• Была спроектирована гибкая и масштабируемая архитектура, связывающая систему контроля версий, CI/CD, контейнеризацию и оркестрацию в единый процесс.
• Был реализован практический прототип системы, наглядно демонстрирующий полный цикл автоматизированного развертывания приложения от коммита кода до его появления на стенде.
• Проведенное тестирование подтвердило полную функциональность, надежность и отказоустойчивость разработанного решения.
• Экономический расчет доказал, что внедрение данного комплекса является целесообразным и приносит значительную выгоду за счет экономии ресурсов и ускорения разработки.

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

Перспективы развития

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

1. Интеграция с системами мониторинга и логирования: Внедрение стека Prometheus + Grafana для сбора метрик и ELK Stack (Elasticsearch, Logstash, Kibana) для централизованного сбора и анализа логов.
2. Внедрение продвинутых паттернов безопасности: Использование Service Mesh (например, Istio) для контроля трафика между микросервисами, управления политиками доступа и взаимного шифрования (mTLS).
3. Расширение каталога автоматизированных сервисов: Создание шаблонов и плейбуков для автоматического развертывания более сложных компонентов, таких как кластеры баз данных или брокеры сообщений.

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

1. Федеральный закон от 27 июля 2006 года «Об информации, ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЯХ И О ЗАЩИТЕ ИНФОРМАЦИИ» // «Собрание законодательства РФ», Выпуск № 31, 2006 г., ст. 3448, №149-ФЗ.
2. ГОСТ Р 52448-2005 — Защита информации. Обеспечение безопасности сетей электросвязи. Общие положения.
3. ГОСТ Р 51275-99 – Защита информации. Объект информации. Факторы, воздействующие на информацию. Общие положения.
4. ГОСТ Р ИСО/МЭК 15408-2-2008 – Информационная технология. Методы и средства обеспечения безопасности. Критерии оценки безопасности информационных технологий.
5. Смирнов А.А. Обеспечение информационной безопасности в условиях виртуализации общества. Опыт Европейского Союза [Электронный ресурс]: монография/ Смирнов А.А.— Электрон. текстовые данные. — М.: ЮНИТИ-ДАНА, 2012. — 159 c.— Режим доступа: http://www.iprbookshop.ru/15408.html. — ЭБС «IPRbooks».
6. Савельев А.О. Решения Microsoft для виртуализации ИТ-инфраструктуры предприятий [Электронный ресурс]/ Савельев А.О.— Электрон. текстовые данные.— М.: Интернет-Университет Информационных Технологий (ИНТУИТ), 2011.— 135 c.— Режим доступа: http://www.iprbookshop.ru/16735.— ЭБС «IPRbooks».
7. Клементьев И.П. Введение в облачные вычисления [Электронный ресурс]/ Клементьев И.П., Устинов В.А.— Электрон. текстовые данные.— М.: Интернет-Университет Информационных Технологий (ИНТУИТ), 2011.— 190 c.— Режим доступа: http://www.iprbookshop.ru/16695.— ЭБС «IPRbooks».
8. Федотов Е.А. Администрирование программных и информационных систем [Электронный ресурс]: учебное пособие/ Федотов Е.А.— Электрон. текстовые данные.— Белгород: Белгородский государственный технологический университет им. В.Г. Шухова, ЭБС АСВ, 2012.— 136 c.— Режим доступа: http://www.iprbookshop.ru/27280.— ЭБС «IPRbooks».
9. Михеев М.О. Администрирование VMware vSphere 4.1 [Электронный ресурс]/ Михеев М.О.— Электрон. текстовые данные.— М.: ДМК Пресс, 2011.— 408 c.— Режим доступа: http://www.iprbookshop.ru/8010.— ЭБС «IPRbooks».
10. Михеев М.О. Администрирование VMware vSphere 5. – М.: ДМК Пресс, 2012. -504 с.
11. Скотт Лоу VMware vSphere 4: полное руководство. : Пер. с англ. – М. ООО «И.Д. Вильямс», 2011. -784 с.
12. Никитин В.С. Технологии будущего [Электронный ресурс]: монография/ Никитин В.С.— Электрон. текстовые данные.— М.: Техносфера, 2010.— 264 c.— Режим доступа: http://www.iprbookshop.ru/12736.— ЭБС «IPRbooks»,
13. Головин Ю.А., Информационные сети: Учебник для студ. Учреждений высш. проф. образования Учебник, М: Издательский центр «Академия», 2011. – 384.
14. Чекмарев А. Н. Microsoft Windows 7. Руководство администратора. — СПб.: БХВ-Петербург, 2010. — 896 с.
15. Зрюмов, Е. А. Базы данных для инженеров: учебное пособие / Е. А. Зрюмов, А. Г. Зрюмова; Алт. гос. техн. ун-т им. И. И. Ползунова. – Барнаул : Изд-во АлтГТУ, 2010. – 131 с.
16. Рэнд Моримото, Ноэль Майкл, Омар Драуби, росс Мистри, Крис Амарис, Microsoft Windows Server 2008 R2. Полное руководство.: Пер. с англ. –М. ООО «И.Д. Вильямс»,2011.-1456 с.
17. Блинов А.М. Информационная безопасность: Учебное пособие. Часть 1. – СПб.: Изд-во СПбГУЭФ, 2010. – 96 с.
18. Каторин Ю.Ф., Разумовский А.В., Спивак А.И. Защита информации техническими средствами: Учебное пособие / Под редакцией Ю.Ф. Каторина – СПб: НИУ ИТМО, 2012. – 416 с.
19. Gohar Ahmed Implementing Citrix XenServer Quickstarter. — Packt Publishing Ltd. 2013, 134 p.
20. Esther Barthel MSc Citrix® XenApp® 6.5 Expert Cookb ook. — Packt Publishing Ltd. 2014, 420 p.
21. Jason Langone, Andre Leibovici VMware View 5 Desktop Virtualization Solutions — Packt Publishing Ltd. 2012, 288 p.
22. Nick Marshall, Scott Lowe Mastering VMware vSphere® 5.5. – Sybex 2014, 842 p.
23. Martez Reed Mastering Citrix® XenServer® — Packt Publishing Ltd. 2014, 300 p.
24. Gaspare A. Silvestri Citrix XenDesktop 5.6 Cookbook — Packt Publishing Ltd. 2013, 354 p.
25. Ryan Troy, Matthew Helmke VMware Cookbook, Second Edition — O’Reilly Media 2012, 360 p.
26. Инфраструктура виртуальных рабочих столов. // Windows IT Pro Джон Сэвилл. [Электронный ресурс]. URL: http://www.osp.ru/win2000/2011/07/13010857/ (дата обращения: 20.10.2015).
27. Основы информационной безопасности. // НОУ Интуит Владимир Галатенко [Электронный ресурс]. URL: http://www.intuit.ru/studies/courses/10/10/info (дата обращения: 10.9.2015).
28. О перспективах решений для виртуализации настольных ПК предприятий (VDI) — VMware View и Citrix XenDesktop [Электронный ресурс]. URL: http://www.vmgu.ru/news/vdi-market-morgan-stanley-2010-2011 (дата обращения: 9.9.2015).
29. Уровни RAID — краткие теоретические сведения [Электронный ресурс]. URL: http://www.nix.ru/computer_hardware_news/hardware_news_viewer.html?id=187685 (дата обращения: 18.9.2015).
30. SAN Сеть хранения данных [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/ (дата обращения: 23.9.2015).
31. LAN Локальная вычислительная сеть [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/ (дата обращения: 14.10.2015).
32. Резервное копирование [Электронный ресурс]. URL: https://ru.wikipedia.org/wiki/ (дата обращения: 15.10.2015).
33. ПАО «РусГидро» [Электронный ресурс]. URL: http://www.rushydro.ru/company/history/ (дата обращения: 08.10.2015).
34. Продукты vmware [Электронный ресурс]. URL: http://www.vmware.com/ (дата обращения: 22.10.2015).
35. Продукты компании Citrix [Электронный ресурс]. URL: http://www.citrix.ru/ (дата обращения: 22.10.2015).
36. Сравнение технологий для виртуализации настольных ПК: VMware VDI и Citrix XenDesktop. [Электронный ресурс]. URL: http://www.vmgu.ru/articles/vmware-vdi-comparison (дата обращения: 25.10.2015).
37. Virtual Applications: Сравнение возможностей VDI от Citrix, VMware, Microsoft [Электронный ресурс]. URL: http://www.inspe.kz/article/virtual-applications (дата обращения: 26.10.2015).
38. Сравнение Гипервизоров [Электронный ресурс]. URL: http://www.vmware.com/pdf/hypervisor_performance.pdf (дата обращения: 29.10.2015).
39. Аппаратное решение в виде хранения данных от HP [Электронный ресурс]. URL: http://h20566.www2.hpe.com/portal/site/hpsc (дата обращения: 19.10.2015).
40. Аппаратное решение в виде сервера от HP [Электронный ресурс]. URL:http://h20566.www2.hpe.com/portal/site/hpsc/public/psi/home/?sp4ts.oid=4091412#manuals (дата обращения: 19.10.2015).