Сегодня мы продолжаем говорить о дизайне VDI. Первая часть доступна по ссылке: http://blog.vmpress.org/2017/09/vdi-1.html
На практике довольно часто приходится сталкиваться с ситуацией, когда заказчик начинает не с вдумчивого формирования требований, а сразу с постановки задачи вида: "мы слышали о продукте ABC и хотим его внедрить, нам нужно знать бюджет" или "у нас есть X денег, давайте их потратим", после чего в качестве требований фактически фиксируются те функциональные возможности, которыми обладает продукт ABC, что далеко не всегда отражает настоящие задачи и потребности организации. Недостаток подобного подхода можно хорошо наблюдать на примере небольших проектов/пилотов, которые могут успешно завершиться и по бумагам решение будет соответствовать требованиям, но дальнейшее масштабирование и попытка применить решение в практическом ключе наталкивается на различные проблемы (отсутствие действительно нужных функций и наличие большого числа ненужных), в итоге система так и остается в небольшой зоне, постепенно устаревая и в конце концов заменяясь чем-то другим.
При общении с заказчиком будьте готовы к тому, что он выдвигает требования совершенно не в том формате, который ожидают технические специалисты.
Зачастую, когда речь заходит о VDI, то заказчики имеют довольно смутные представления – каким требования должен удовлетворять VDI. Но если вы выступаете в качестве генератора идей, помните, что дополнительные возможности, которые вы предлагаете реализовать, приводят к усложнению системы, что в свою очередь может привести к удорожанию проекта. Простой пример – если спросить у любого заказчика – что он выберет, систему с надежностью 99.99% (1 час простоя в год) или 99.9% (8 часов простоя в год), будьте уверены, что он выберет первый вариант, пока не увидит стоимость этих двух решений, которая может отличаться в разы.
Условно, требования к системе можно разделить на две группы: функциональные и нефункциональные. Функциональные требования описывают то, что система должна делать, например:
Availability определяет требования относящиеся к доступности системы, например:
Пожалуй, самым известным и неприятным ограничением проекта является его бюджет. Другие примеры ограничений:
Помочь в определении требований, рисков, допущений и ограничений может заранее проработанный перечень вопросов. Вот пример некоторых вопросов, которые можно задать на интервью с заказчиком.
Формат ТЗ может быть разным. В качестве основы можно руководствоваться стандартом ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы. Альтернативный вариант – описывать требования в формате, который часто используется зарубежными компаниями. в качестве примера можно привести документ
Для удобства указания на конкретные пункты ТЗ можно использовать сквозную нумерацию абзацев ТЗ, например:
Другой вариант – оформлять требования в виде таблицы и давать им уникальные идентификаторы, например:
Данный формат применяется в VMware SET, содержащим набор различной документации, включая технические требования, инструкции по развертыванию, чек-листы, презентации, инсталляционные профили и многое другое. VMware SET доступен для загрузки с партнерского портала.
В ТЗ описываются не только требования к самой системе, но и к инфраструктуре и смежным системам, с которыми интегрируется VDI. Требования доступа к VDI из Интернет накладывает ограничения на каналы связи м их пропускную способность доступность. Доступность VDI напрямую определяется доступностью ЦОД.
Допущения могут быть оформлены в виде требований к текущей инфраструктуре / к объекту автоматизации до начала работ по внедрению. например:
Отдельно следует помнить о требованиях к численности и квалификации персонала, ответственного за поддержку системы. VDI находится на стыке нескольких зон ответственности, за серверное оборудование и по отвечает отдел системного администрирования, за рабочие места отвечает отдел поддержки пользователей, кроме того, может потребоваться привлечение специалистов по ИБ или сетевых администраторов. Внедрение VDI может потребовать разработку документации – инструкций, регламентов, чек-листов, а также проведения обучения или инструктажа для технических специалистов.
Прописывание соответствующих требований в ТЗ позволит заранее начать обсуждение процесса разделения зон ответственности, определения возможности поддержки своими силами, необходимости обучения специалистов или расширение штата.
Продолжение доступно по ссылкам:
2.1 Требования
Подготовка к внедрению любой инфраструктуры начинается с требований. Правильная постановка и фиксирование задачи, отражающая реальные потребности организации – является ключевым фактором в успешной реализации проекта.На практике довольно часто приходится сталкиваться с ситуацией, когда заказчик начинает не с вдумчивого формирования требований, а сразу с постановки задачи вида: "мы слышали о продукте ABC и хотим его внедрить, нам нужно знать бюджет" или "у нас есть X денег, давайте их потратим", после чего в качестве требований фактически фиксируются те функциональные возможности, которыми обладает продукт ABC, что далеко не всегда отражает настоящие задачи и потребности организации. Недостаток подобного подхода можно хорошо наблюдать на примере небольших проектов/пилотов, которые могут успешно завершиться и по бумагам решение будет соответствовать требованиям, но дальнейшее масштабирование и попытка применить решение в практическом ключе наталкивается на различные проблемы (отсутствие действительно нужных функций и наличие большого числа ненужных), в итоге система так и остается в небольшой зоне, постепенно устаревая и в конце концов заменяясь чем-то другим.
При общении с заказчиком будьте готовы к тому, что он выдвигает требования совершенно не в том формате, который ожидают технические специалисты.
Зачастую, когда речь заходит о VDI, то заказчики имеют довольно смутные представления – каким требования должен удовлетворять VDI. Но если вы выступаете в качестве генератора идей, помните, что дополнительные возможности, которые вы предлагаете реализовать, приводят к усложнению системы, что в свою очередь может привести к удорожанию проекта. Простой пример – если спросить у любого заказчика – что он выберет, систему с надежностью 99.99% (1 час простоя в год) или 99.9% (8 часов простоя в год), будьте уверены, что он выберет первый вариант, пока не увидит стоимость этих двух решений, которая может отличаться в разы.
Условно, требования к системе можно разделить на две группы: функциональные и нефункциональные. Функциональные требования описывают то, что система должна делать, например:
- VDI должен обеспечивать удаленное подключение пользователей к персональным виртуальным рабочим местам с ПК под управлением ОС Windows или MAC OS X, а также тонких клиентов и мобильных устройств под управлением Android или iOS.
- VDI должен предоставлять возможность централизованного развертывания и обновления виртуальных десктопов из единого образа.
- Система должна автоматически выключать виртуальные десктопы без активных сеансов пользователей.
- Хранение данных ВМ должно осуществляться на выделенной системе хранения данных. Все серверы виртуализации должны иметь подключение к системе хранения.
Availability определяет требования относящиеся к доступности системы, например:
- Система должна функционировать в режиме 12x5 (рабочие дни с 8:00 до 20:00). Система должна быть спроектирована с учетом 99.99% доступности.
- Физические серверы должны иметь блоки питания, резервируемые по схеме 1+1.
- Локальные накопители, должны быть объединены в RAID-1 для обеспечения отказоустойчивости.
- Все служебные ВМ и виртуальные десктопы должны быть защищены при помощи технологии VMware HA, обеспечивающей автоматический перезапуск ВМ на других узлах при выходе из строя одного из серверов кластера.
- Подключения серверов к дисковому хранилищу должны быть задублированы, должна использоваться технология multipathing, обеспечивающая автоматическое переключение на резервный путь в случае отказа одного из контроллеров СХД, FC коммутатора, порта FC HBA адаптера или обрыва кабеля.
- В сервере должны присутствовать не менее двух сетевых адаптеров. Порты сетевых адаптеров должны быть объединены в общий логический канал (транк) при помощи протоколов статической (EtherChannel) или динамической (LACP) агрегации каналов.
- VDI должен обеспечивать управление посредством централизованной консоли администрирования HTML5, не требующей установки дополнительных плагинов, доступ к которой осуществляется через web-браузер Google Chrome или Mozilla Firefox.
- VDI должен поддерживать управление из командной строки. VDI должен иметь интеграцию с PowerShell посредством установки и запуска модулей расширения, позволяющих выполнять типовые операции по созданию, удалению, изменению конфигурации виртуальных десктопов из командной строки.
- VDI должен поддерживать интерфейс REST API для интеграции со сторонними системами оркестрации и автоматизации.
- Среднее время загрузки виртуального десктопа после включения не должно превышать 2 минут.
- Средняя утилизация процессора и ОЗУ серверов виртуализации при одновременной работе всех виртуальных десктопов не должно превышать 80%.
- Среднее время отклика при выполнении операций ввода/вывода дисковой подсистемы не должно превышать 15 мс.
- Время входа пользователя в систему с учетом загрузки профиля размером 2 ГБ не должно превышать 30 секунд.
- Каждая виртуальная рабочая станция должна иметь не менее 2х виртуальных процессоров (vCPU), не менее 4 ГБ ОЗУ.
MTD = RTO + WRT
Важно донести до заказчика, что на практике возможно реализовать системы с RPO и RTO близким к 0, стоимость подобных решений может выйти за рамки бюджета проекта.
При формировании требований к восстановлению важно определить перечень аварийных сценариев, от которых требуется защищаться, а также, что к разным компонентам системы, и к системе в целом могут предъявляться разные требования к восстановлению, например:
- В случае отказа системы хранения на основной площадке должна быть предусмотрена возможность запуска системы с использованием системы хранения, расположенной на резервной площадке. Время восстановления не должно превышать 1 часа, допустима потеря данные не более чем за 2 часа до момента отказа.
- Время восстановления одного виртуального десктопа в случае потери данных не должно превышать 2 часов (RTO), данные, хранящиеся в профиле пользователя, должны быть восстановлены за интервал не позднее 48 часов с момента сбоя.
- Для высококритичных ВМ должны использоваться средства, обеспечивающие восстановление работоспособности ВМ в течение 15 минут, без потери данных.
- Для пользователей, подключающихся к виртуальным рабочим станциям из сети Интернет, должна выполняться двухфакторная аутентификация с использованием смарт-карт.
- На рабочих местах пользователей должен быть установлен антивирусный агент, осуществляющий антивирусную проверку файлов, с которыми работает пользователь, в реальном времени и по расписанию один раз в день.
- Для всех служебных учетных записей должны использоваться уникальные пароли, отвечающие критериям безопасности (длина не менее 12 символов, в пароле одновременно должны использоваться заглавные и строчные буквы, цифры и спец. символы).
- Все операции, выполняемые администраторами в консоли управления, должны заноситься в журнал и отправляться на внешний Syslog сервер.
Помимо озвученных выше требований, к нефункциональным требованиям можно отнести требования по использованию определенных версий и редакций ПО. Это может быть продиктовано необходимостью обеспечить совместимость со сторонними системами, например, системой мониторинга или СРК. Однако с указанием конкретных версий (если только это не обусловлено необходимостью использования определенных сертифицированных дистрибутивов) связана проблема того, что постоянно выходят новые версии ПО, и указав старые версии вы сами можете себя ограничить. Более корректным может быть замена это на требования вида:
- На оборудование должны быть установлены последние актуальные версии микропрограммного обеспечения, рекомендуемые вендором/производителем оборудования.
- Для развертывания VDI должны использоваться версии ПО, совместимые с существующим ПО мониторинга и резервного копирования.
2.2 Риски
Риски – это возможные неблагоприятные ситуации, которые могут возникать на различных этапах проекта, и которые могут приводить к затягиванию сроков или увеличению затрат на проект. Примеры рисков:- Подрядчик не успевает закончить работы в срок, из-за чего увеличивается длительность проекта.
- Между ЦОД и офисом организован один канал связи, его падение может повлиять на доступность системы для пользователей.
- Отсутствие расширенной поддержки со стороны производителя с заменой в течение 4 часов или ЗИП фонда не позволит гарантировать RTO в случае отказа оборудования.
- Используется серверное оборудование, которое официально не совместимо с данной версией ПО, что может привести к возникновению проблем с производительностью или доступностью системы.
- Отсутствие процедуры тестирования обновлений может повлечь за собой появления в производственной среде проблем из-за наличия ошибок в ПО.
- У специалистов нет опыта работы с данным оборудованием/ПО, что может привести к увеличению времени выполнения работ по настройке.
2.3 Допущения
Допущения – это утверждения, которые не были проверены на практике, и которые используются в качестве входных данных для проектирования. Примеры допущений:- Между ЦОД и офисом организован канал передачи данных, пропускной способности которого достаточно для работы 1000 пользователей.
- Производительности существующего дискового массива/серверов достаточно для размещения виртуальных рабочих станций.
- В ЦОД есть место для установки нового оборудования, система электропитания и охлаждения рассчитана на дополнительную нагрузку.
- Прикладное ПО и периферийное оборудование, с которым работают пользователи на физических компьютерах, совместимо с VDI.
2.4 Ограничения
У любого проекта есть ограничения. Ограничения – это все то, что уменьшает наши возможности по выбору. С одной стороны ограничения снимают с нас ограничения по выбору между несколькими вариантами решения задачи, с другой – лишают нас возможности использовать те или иные возможности продукта, или же приводят к необходимости усложнять дизайн для реализации требований.Пожалуй, самым известным и неприятным ограничением проекта является его бюджет. Другие примеры ограничений:
- Использование оборудования или ПО определенных производителей, использование определенных моделей/версий, определенных конфигураций.
- Необходимость использования существующего оборудования или ПО для построения системы.
- Ограничения, накладываемые законодательством (например, использование ПО, сертифицированное ФСТЭК или внесенное в Единый реестр российских программ).
2.5 Вопросы
В проектах постоянно возникают ситуации, когда заказчик не может или не желает самостоятельно сформировать техническое задание. В этом случае приходится брать инициативу в свои руки и по крупицам собирать необходимую информацию.Помочь в определении требований, рисков, допущений и ограничений может заранее проработанный перечень вопросов. Вот пример некоторых вопросов, которые можно задать на интервью с заказчиком.
- Для каких целей предназначен VDI? Какие функции будут выполнять пользователи в VDI? Предполагается обеспечить полноценную работу сотрудников, или предполагается работа только с определенным набором ПО?
- Какое количество пользователей планируется перевести в VDI?
- Все пользователи выполняют одинаковые задачи на рабочих станциях? Существует ли разделение пользователей по группам в зависимости от задач, набора установленного ПО или конфигурации рабочей станции (например, оператор call-центра, менеджер, бухгалтер, дизайнер, VIP-пользователь)?
- Работуют ли пользователи с мультимедиа? Прослушивают аудиофайлы, просматривают видео (видео-файлы, flash анимация, 3D анимация)? Запускают ли пользователи приложения для работы с 3D (Google Earth, ГИС системы, CAD/CAM системы)?
- Требования к доступности – какие показатели RTO/RPO для рабочих станций? Какой режим работы сервиса? Требуется ли высокая доступность для рабочих станций, требуется ли обеспечения катастрофоустойчивой защиты VDI? Есть ли вторая и третья площадки? (Когда вы задаете вопрос о допустимом времени простоя, то вероятнее всего ответ будет – ноль. Вместо этого можно задать вопрос – за какое время сейчас выполняется восстановление рабочей станции при отказе? Каким образом выполняется процедура восстановления?)
- Какая конфигурация у существующих рабочих станций? Приведите перечень ПО и периферийного оборудования, которое используют пользователи? (Внедрение VDI может повлиять на выбор тех средств, что используется для физических рабочих станций, например, потребует смены решения для антивирусной защиты или резервного копирования, управления рабочими станциями)
- Определен ли бюджет проекта? (Важно понимать предельную стоимость. Заказчик может долго мечтать о новых блейд-серверах, территориально-распределенных кластерах, графических ускорителях и all-flash массивах, блестящих тонких клиентах и 4K дисплеях, но каждое такое пожелание приводит к увеличению стоимости реализации, важно понимать, когда следует остановиться и начать уменьшать аппетиты).
- Какие подсистемы должны быть включены в проект? Требуется ли модернизировать сетевую инфраструктуру, СХД, СРК, систему мониторинга, закупать дополнительные лицензии на прикладное ПО и т.д.? Какие существующие ресурсы можно задействовать в проекте? (Не стоит ожидать, что у заказчика будет под рукой свободные серверы и СХД, подходящее для внедрения VDI, если только это не небольшой пилотный проект. А вот балансировщики, система резервного копирования, файловый сервер, или же вычислительные ресурсов виртуальной инфраструктуры для размещения служебных ВМ помогут снизить стоимость внедрения)
- Как организовано хранение пользовательских данных (настроек, профиля, документов) на текущий момент? Рассматривается ли вариант с переходом на централизованное хранение данных пользователей на файловом сервере?
- Какие средства антивирусной защиты используются на текущий момент? Готовы ли рассматривать другой продукт/вендора, который интегрируется с VDI?
- Как организована печать? Используется специализированное ПО для печати? Какие модели принтеров используются?
- Какие зоны ответственности в проекте? Кто выполняет настройку тех или иных компонентов, кто выполняет интеграцию с существующими системами заказчика? Кто выполняет миграцию пользователей в VDI и перенос данных с рабочих станций?
- Оборудование и ПО каких производителей предпочитает покупать заказчик? Какие ограничения есть в плане выбора моделей или аппаратной конфигурации?
2.6 Обследование
Одним из вариантов получение информации о существующей инфраструктуре, помимо проведения интервью, является сбор информации при помощи специализированного ПО.
Использование специализированных инструментов позволяет не только получить более точную и полную информацию, касающуюся аппаратной конфигурации рабочих мест, установленного программного обеспечения, используемых периферийный устройств, но также собрать данные по использованию вычислительных ресурсов, которые могут пригодиться на этапе сайзинга.
Помимо решений по управлению конфигурацией серверов и рабочих станций, вроде Microsoft SCCM или CMDB систем, можно использовать VMware Capacity Planner – средство, разрабатываемое VMware, которое доступно для партнеров компании, позволяющее выполнить инвентаризацию, сбор информации об утилизации серверов и рабочих станций, и на основании полученных данных выполнять сайзинг оборудования. Основные компоненты Capacity Planner, включая консоль управления и генератор отчетов размещаются в "облаке" VMware. В инфраструктуре компании развертывается сервер-коллектор, который собирает необходимую информацию, подключаясь к компьютерам по протоколам WMI (для ОС Windows) или SSH (для ОС Linux).
В результате работы Capacity Planner может подготовить отчет, который содержит информацию по показателям консолидации.
Другим распространенным средством является Microsoft Assessment and Planning (MAP) Toolkit. Он также позволяет выполнить сбор данных о конфигурации компьютеров, но что самое полезное - MAP предоставляет средства инвентаризации установленного ПО. В MAPT также присутствует встроенный инструмент для сайзинга, который позволяет определить количество физических серверов, которое потребуется для запуска ВМ.
Для обследования существующих виртуальных сред подойдет средство vSphere Optimization Assessment. VOA представляет собой тестовую версию vRealize Operations Manager – инструмента для мониторинга виртуальной инфраструктуры VMware. VOA может собирать статистику об утилизации вычислительных ресурсов и на основании полученных данных создавать отчеты и выдавать рекомендации по оптимальной конфигурации ВМ. Также VOA содержит инструмент по прогнозированию роста нагрузки на основании статистической информации и планировщик, который может показать достаточно ли в виртуальной инфраструктуре ресурсов для запуска определенного количества ВМ с заданными аппаратными ресурсами.
2.7 Техническое задание
После сбора необходимой информации наступает этап формирования технического задания (technical requirements), в котором фиксируются все требования, ограничения, риски и допущения.Формат ТЗ может быть разным. В качестве основы можно руководствоваться стандартом ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы. Альтернативный вариант – описывать требования в формате, который часто используется зарубежными компаниями. в качестве примера можно привести документ
Для удобства указания на конкретные пункты ТЗ можно использовать сквозную нумерацию абзацев ТЗ, например:
5 Требования к системе5.1 Функциональные требования5.1.1 Система должна обеспечивать подключение...После чего можно ссылаться на данное требование из других документов: "В соответствии с требованиями 5.1.1…".
Другой вариант – оформлять требования в виде таблицы и давать им уникальные идентификаторы, например:
Идентификатор | Требование |
| ФТ1 | Хранилище должно поддерживать протокол Fibre Channel для доступа к данным |
Данный формат применяется в VMware SET, содержащим набор различной документации, включая технические требования, инструкции по развертыванию, чек-листы, презентации, инсталляционные профили и многое другое. VMware SET доступен для загрузки с партнерского портала.
В ТЗ описываются не только требования к самой системе, но и к инфраструктуре и смежным системам, с которыми интегрируется VDI. Требования доступа к VDI из Интернет накладывает ограничения на каналы связи м их пропускную способность доступность. Доступность VDI напрямую определяется доступностью ЦОД.
Допущения могут быть оформлены в виде требований к текущей инфраструктуре / к объекту автоматизации до начала работ по внедрению. например:
Для работы инфраструктуры требуется наличие следующих инфраструктурных сервисов: службы каталога, сервера точного времени, службы динамической конфигурации узлов DHCP, службы разрешения имен.Также можно описать требования к каналам передачи данных – пропускной способности, задержкам, допустимым потерям пакетов, требования к клиентским устройствам с которых осуществляется доступ (версия ОС, требования к периферийному оборудованию, используемому при работе с VDI).
Отдельно следует помнить о требованиях к численности и квалификации персонала, ответственного за поддержку системы. VDI находится на стыке нескольких зон ответственности, за серверное оборудование и по отвечает отдел системного администрирования, за рабочие места отвечает отдел поддержки пользователей, кроме того, может потребоваться привлечение специалистов по ИБ или сетевых администраторов. Внедрение VDI может потребовать разработку документации – инструкций, регламентов, чек-листов, а также проведения обучения или инструктажа для технических специалистов.
Прописывание соответствующих требований в ТЗ позволит заранее начать обсуждение процесса разделения зон ответственности, определения возможности поддержки своими силами, необходимости обучения специалистов или расширение штата.
Продолжение доступно по ссылкам: