virtualbox disk image что это

VirtualBox. Виртуальные диски. Их типы. Расширение виртуального носителя.

О проблеме

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

Задачи

1. О типах виртуальных носителей

Выдержка из документации, приведена ниже. Ссылка на доку. Искать часть 5.2. Disk Image Files (VDI, VMDK, VHD, HDD)
Файл образа диска виртуальной машины находится на хостиг-системе и воспринимается гостевой системой, как жёсткий диск определённой геометрии. Когда гостевая ОС читает с диска или записывает на него, VBox перенаправляет запрос в файл образа.

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

VBox поддерживает типы виртуальных носителей:

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

2. Решение проблемы

3. Расширение дискового пространства в гостевой системе

Гостевая ОС, Windows

Гостевая ОС, думаю любой дистрибутив GNU/Linux
Я расширял в Debian-Arch подобных

Источник

Какой образ диска следует использовать с VirtualBox, VDI, VMDK, VHD или HDD?

последние версии VirtualBox поддерживают несколько форматов виртуальных дисков, но они забыли провести сравнение между ними.

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

11 ответов

Отвечая На Ваши Соображения

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

все четыре формата поддержка снимков на VirtualBox.

VDI-это собственный формат VirtualBox. Я не искал другого программного обеспечения, которое поддерживает этот формат.

VHD является собственным форматом Microsoft Virtual ПЕРСОНАЛЬНЫЙ КОМПЬЮТЕР. Этот формат популярен среди продуктов Майкрософт.

Я ничего не знаю о HDD. Судя по глядя на этот сайт, Parallels является продуктом Mac OS X и, вероятно, не подходит для вас, особенно учитывая, что VirtualBox поддерживает только старую версию формата HDD.

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

факторы, которые влияют на производительность,:

Я всегда использую VDI, так как это родной формат VirtualBox; однако использование VMDK (формат VMWare) увеличит совместимость с другим программным обеспечением виртуальной машины.

VirtualBox будет отлично работать на Ubuntu, поэтому, если цель-совместимость Windows/Ubuntu, VDI будет вполне допустимым выбором.

оба формата выполнят ваши требования.

Что касается двух других, VHD-это формат, разработанный Microsoft, а HDD-формат, разработанный Apple; эти оба имеют собственную лицензию, поэтому ограничивайте кросс-платформенную поддержку;я бы не рекомендовал их.

Mpack, объясняет ключевую разницу в производительности между VHD и VDI здесь:

недавно изучив формат VHD, я ожидал бы, что будет по крайней мере небольшая разница в пользу VDIs, наиболее заметная, когда вы сравниваете, как с like, т. е. оптимизированный VDI против оптимизированного VHD. Причина в том, что динамический формат VHD имеет эти» растровые » сектора, разбросанные по всему диску. Каждый раз, когда вы изменяете сектор внутри блока, эти растровые блоки, возможно, должны быть обновлено и написано тоже, с участием дополнительных ищет, читает и пишет. Эти растровые сектора также должны быть пропущены при чтении последовательных кластеров из образа диска-more seeks. Формат VDI не имеет этих накладных расходов, особенно если VDI был оптимизирован (блоки на виртуальном диске отсортированы в порядке LBA).

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

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

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

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

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

VMDK: VirtualBox также полностью поддерживает популярный и открытый формат контейнеров VMDK, используемый многими другими продуктами виртуализации, в частности VMware.[25]

VHD: VirtualBox также полностью поддерживает формат VHD, используемых Microsoft.

файлы изображений Parallels версии 2 (формат HDD) также поддерживаются.[26] из-за отсутствия документации формата новые форматы (3 и 4) не поддерживаются. Однако вы можете конвертировать такие файлы изображений в формат версии 2 с помощью инструментов, предоставляемых Parallels.

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

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

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

VDI, кажется, имеет больше вариантов (при использовании с VirtualBox), но как только вы берете VirtualBox из картины, поддержка VDI становится несколько шаткой (по состоянию на конец 2014 года).

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

VMDK-это просто менее безболезненно ИМХО, когда вы хотите работать с любой виртуальной машины на любой рабочей станции, когда вы хотите клонировать его 3 раза с другими системами в сети одновременно, и когда вы хотите, чтобы открыть ее без запуска ВМ экземпляр.

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

Источник

Особенности работы с виртуальными дискaми VirtualBox

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

Начнем с некоторых общих понятий. У VirtualBox существуют 3 основных метода предоставления гостевой операционной системе (ОС) доступа к данным. Сей текст концентрируется на использовании виртуальных дисков.

Виртуальные диски подключаются к виртуальной — гостевой ОС, методом эмуляции подключения через соответствующий контроллер, IDE, SATA (AHCI), SCSI, SAS.

Поведение контроллеров запрограммировано таким образом, чтобы имитировать физические прототипы, следовательно IDE контроллер будет работать медленнее SATA и потреблять больше ресурсов процессора, ОС без соответствующих драйверов и аппаратной поддержки не будут взаимодействовать с виртуальными дисками и т.д. Например, в семействе Windows до Windows Vista нет поддержки Advanced Host Controller Interface (AHCI), к которому относится SATA, поэтому в частности, виртуальная машина с ОС Windows XP с SATA работать не будет.

Файлы виртуальных дисков

VirtualBox позволяет работать с разными форматами файлов виртуальных дисков. Помимо собственного VDI, поддерживаются VMDK (VMware), VHD (Microsoft), Parallels version 2 HDD format (Parallels).

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

Виртуальные диски могут быть, как фиксированного размера, так и динамически выделяемого, причем VirtualBox позволяет увеличить размер дискового пространства, независимо от объёма и формата диска и даже в том случае, если диск содержит данные. Ниже пример, как это сделать с помощью утилиты vboxmanage.

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

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

Управление виртуальными медиа (Virtual Media Manager)

VirtualBox ведет реестр всех виртуальных медиа носителей, которые используются всеми гостевыми ОС. Это так называемые ”known media”, доступ к списку (реестру) которых можно получить используя утилиту Virtual Media Manager (доступно из меню File). Эта утилита показывает детальную информацию о каждом виртуальном диске, включая полный путь к файлу, а также к какой именно виртуальной машине файл прикреплен. Информацию из реестра можно удалить используя встроенную функцию удаления “Remove”

Каждый отдельно взятый образ можно «открепить» от виртуальной машины за которой он закреплен, используя функцию ”Release”

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

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

Snapshots (Снэпшоты)

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

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

Стоить помнить, что при удалении снэпшота, все изменения произведенные после его создания «сливаются» с ранее «замороженным» образом.

Кэширование ввода/вывода

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

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

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

Bandwidth

VirtualBox позволяет ограничивать ширину пропускного канала для одного или нескольких виртуальных дисков.

Создаем группу “Limit” и устанавливаем лимит в 20 Mb/s

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

Суммарный для обоих дисков bandwidth не будет превышать 20 MB/s. Этот лимит можно изменить в любой момент, не выключая виртуальной машины.

Особые режимы записи образов

Для каждого образа виртуального диска, поддерживаемого VirtualBox, не зависимо от формата, можно определить режим поведения при записи данных, будь это следствие операций внутри виртуальной машины или снимка дика (snapshot). Такие режимы называются «нестандартными», в то время, как по умолчанию все образы дисков функционируют в «нормальном» режиме. Для того, что бы перевести режим из «нормального» в «нестандартный» можно воспользоваться вышеупомянутым Virtual Media Manager или консольной утилитой vboxmanage

В «нормальном» режиме записи, гостевая ОС может осуществлять чтение и запись с физического диска без всяких ограничений a при создании снимков диска (snapshot), VirtualBox создает oтдельный файл в котором фиксируются все изменения.

В режиме «write through» функция снэпшотов работать не бует.

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

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

Режим «read only» используется в основном для работы с образами CD/DVD, т.к. предполагает только чтение.

Режим на который стоит обратить внимание называется «Immutable». Как следует из названия immutable образы не меняются с течением времени. Любые изменения в immutable диске актуальны ровно до тех пор, пока виртуальная машина работает. После отключения виртуальной машины все изменения пропадают. Прежде чем перевести диск в режим immutable стоит сначало создатъ «нормальный» диск, установить и настроить систему в оптимальное состояние, желательно не подключаясь к интеренету, и только после того, как гостевая система готова — «откреплять» диск и переводить его в режим immutable.

Одним из сценариев работы может быть схема при которой используются два диска – один в режиме immutable, на котором находится сама система, второй в нормальном или write-through режиме. На первый взгляд вполне безопасный и понятный сценарий работы — каждый раз загружается «свежая» система. Но не все так прозрачно и есть некоторые нюансы.

Во первых, для immutable дисков есть одно важное исключение. Они не “обнуляются” в случае, когда прикреплены к виртуальной машине, снимок диска которой был сделан пока та была запущенна — так называемый online-snapshot. Это означает, что если например, пользователь создал immutable disk, а потом в процессе работы, создал «снэпшот», не завершив работу виртуальной машины, то начиная с упомянутого «снэпшота» все последующие операции и действия внутри системы будут носить необратимый эффект, т.к. все действия будут де-факто происходить в «снэпшоте».

В случае если основной целью является «свежая система» при каждом запуске, то от использования снэпшотов, лучше воздержаться.

Во-вторых, вышеописанное «обнуление» отдельного образа происходит только в случае, когда команда включения/отключения виртуальной машины посылается самой средой VirtualBox, а не происходит внутри гостевой ОС. Проще говоря, если например перезагрузить гостевую ОС Windows стандартным методом (Меню пуск, перезагрзить систему), то обнуление immutable диска не произойдет.

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

После того, как текущий контейнер установлен в режим immutable, VirtualBox перестает использовать этот контейнер и фактически диск переходит в режим «read only». Все операции записи перенаправляются в отдельный образ и каждый раз, когда виртуальная машина начинает работу этот новый «отдельный» образ «обнуляется». В реальности на жестком диске создается временный «снэпшот», который находится в папке Snapshots, соответствующей виртуальной машины, внутри которого и происходит вся работа. После завершения работы виртуальной машины вышеупомянутый временный скриншот остается нетронутым.

Рассмотрим простой пример

Боб создал виртуальную машину, настроил ОС и перевел диск в режим immutable. Боб регулярно использует свою виртуальную машину для тайного общения с Алисой. При каждом запуске, загружается «свежая» система, не содержащая никаких логов предыдущего общения, текстов, видео или фото. В очередной раз закончив переписку, Боб спокойно выключает виртуальную машину и идет спать.
Предположим также, что перед каждым запуском ОС Боб проверяет, что режим диска установлен как “immutable”.

Ева имеет доступ к компьютеру на котором установлена виртуальная машина. Ей достаточно зайти в папку Snapshots внутри директории соответствующей виртуальной машины и там будет требуемый «снэпшот».

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

Решением для Боба в данной ситуации будет после завершения работы, вручную удалять все содержимое папки Snapshots. Не говоря уже о том, что надо постоянно проверять в каком режиме работает диск и желательно, либо вообще заблокировать некоторые элементы GUI, что достаточно просто реализуется

Справедливости ради стоит сказать, что у тех-же Parallels, с самых ранних версий для того, что бы перевести диски из одного режима в другой необходим пароль суперпользователя, а временные «снэпшоты» удаляются моментально, после завершения работы.

Источник

VDI: плюсы, минусы, подводные камни для крупного бизнеса, НПО и КБ

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

VDI — это инфраструктура виртуальных рабочих столов. В отличие от «обычного» терминального доступа, упрощая, речь идёт не о нескольких одновременных пользовательских сессиях на одном сервере с операционной системой, а о нескольких виртуальных машинах на физическом сервере. Каждый пользователь получает свой собственный виртуальный ПК, куда может подключаться хоть с телефона.

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

Не так давно появился пример снижения стоимости рабочего места: есть конструкторское бюро в Москве, и есть заводы по России. Чертежи поступают на заводы в 3D-формате, необходим было вносить небольшие изменения. На заводах не могли вносить изменения без дорогостоящей инфраструктуры. Закупалась очень мощная машина серверного уровня, на неё ставился дорогой комплект ПО. Затем эта машина и это ПО поддерживались администраторами из головной организации — при сложных случаях доходило до неблизкого выезда. С внедрением VDI всё стало происходить в дата-центре в Москве.

Общие моменты

Примерно до 2013 года основной проблемой внедрения VDI была очень высокая цена на инфраструктуру. Примерно половину расходов составляла стоимость СХД. Благодаря снижению стоимости на гибридные технологии HDD+Flash в 2014 году начался своего рода бум VDI-сред.

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

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

Так вот, VDI — это ещё когда тысяча станций может обслуживаться одним человеком из одного места. И это стало вторым фактором выбора VDI-решений для крупного бизнеса. А сегодня в некоторых случаях (чаще всего, как с тем КБ) можно говорить об экономии. Экономия достигается только при просчёте снижения рисков, повышения стабильности инфраструктуры и оценки со стороны безопасников. Сама же VDI по структуре стала сложнее и приобрела больше функций, но суть осталась прежней. В целом.

Несколько лет назад в России как-то внезапно оказалось, что VDI — это своего рода best practice для типовых офисов западного типа, для типовых крупных колл-центров и так далее. А в этом году цены стали более разумными, и те, кто заботится о долговременной экономии, начали присматриваться уже всерьёз.

Железо и ПО пользователей

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

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

Тут обычно приходят безопасники со словами: «Дорогой наш директор по ИТ, у нас плохо защищаются данные. Много мы теряем информации, потому что она уносится. Потому что данные хранятся у пользователей». Потом приходит коммерческий директор: «Дорогой директор по ИТ, я хочу, чтобы наши сотрудники работали по 24 часа в сутки даже на деревне у бабушки. Будем повышать надои! И ещё мне удобно с телефона в командировке заходить, тоже прикрути там заодно». И уже дальше админ, разглядывая систему, приходит к выводу, что с ней жить будет проще. Хотя, конечно, понадобится многому учиться, и не все готовы так быстро поменять мировоззрение и получить новые данные. Чаще боятся потерять рабочее место, потому что их знания «окажутся невостребованными». Сразу скажу, страх вполне обоснованный — с внедрением VDI чаще всего сокращают эникейщиков по ненадобности, но основные лица ИТ-отдела остаются. И получают такой опыт и такой уровень контроля, который делает их ещё более ценными для основного бизнеса.

В роли терминала для доступа к VDI может выступать любое устройство с экраном, процессором и средствами ввода-вывода. Планшет, телефон, обычный ПК, ноутбук и тонкий клиент. По сути, такой моноблок — это ПАК, максимально оптимизированный под удешевление стоимости за единицу и простоту замены.

Вот пример устройства рабочего места с тонким клиентом Dell Wyse D10DP:

По цене сравнимо с современным хорошим внешним жёстким диском. Архитектура железа и софт рассчитаны на работу 24/7 под непрерывной нагрузкой «на убой». Обычные рабочие станции постепенно замусориваются на уровне софта (особенно Win-машины), плюс подвержены износу. Здесь установлены оптимизированные именно под такой режим работы ОС, а железо ставится слабым, но надёжным. Слабым — это потому, что лет 7..10 менять его никто не будет, и надёжность важнее. В корпусе минимум движущихся частей, даже вентилятора нет, только пассивное охлаждение радиатором (видите, сколько отверстий на фото выше?). Пыль тоже не набивается, кстати (не больше чем внутрь монитора), а если набивается — не особо мешает эксплуатации.

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

Наш случай — розница сократила затраты на рабочее место на 47%. Задача была по кассирам, касс — 2000 штук, нужно было одновременно снизить затраты и упростить поддержку. Решение: Citrix XenDesktop + XenServer + Wyse.

Но вернёмся к машине в торговом зале. Если бы вдруг пришлось накатить на неё критичное обновление безопасности, возникла бы масса проблем. Здесь всё решается на сервере, и апдейт происходит в ЦОДе почти мгновенно и для всех в сети.

Как выбирать тонкий клиент? Как правило, под задачи. Есть специализированные заточенные решения под Citrix, есть под другое, кому-то важны тонкие клиенты на Linux из-за особенностей лицензионной политики. В общем, по ситуации. Есть программные характеристики, а есть железные (например, наличие нужных портов, часто специфических). И так по каждому уровню.

Да, кстати, под тонкий клиент необязательно закупать отдельное железо. С ним, конечно, лучше и проще, но в дело идут и все старые (часто уже по документам самортизированные, но ещё рабочие) вторые пентиумы, старые целероны, помнящие ещё разгон в средней полосе, и вообще всё железо со склада. Админ их заботливо протирает тряпочкой и отдаёт в работу. 3–4 года они точно послужат. Потом, конечно, меняют на тонкие клиенты по мере выхода из строя, и система становится гомогенной к ещё большему счастью ИТ-отдела. Но дырки под ордена «За почётную экономию» они все в свитерах крутят.

ЦОД-часть

Вот примерная таблица по нашей практике работы с большим бизнесом для связок ЦОД — терминал:

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

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

Как правило, сегодня для нагруженных задач используется связка из Flash — СХД для горячих данных и дисковой для обычных, либо гибридные СХД Flash+HDD, либо, если совсем маленький бюджет, в последнее время — средства кэша вроде вот такого.

Раньше всё строилось по факту, на HDD — это сложности со случайным чтением, сборка в большие кластеры для обеспечения необходимой скорости, проблемы с резервированием и неожиданными поломками. Сегодня для СХД достаточно уже не шкафа на 150–200 дисков, а полочки. Ну, по факту — двух-трёх (с учётом ИБП) стандартных юнитов для enterprise-уровня.

Самая большая ошибка неопытных проектировщиков — это они слишком сильно перезакладывают СХД. Потому что СХД — это единая точка отказа для всей инфраструктуры. За неё боятся, и ценник резко растёт. В среднем до двух раз возрастает стоимость системы хранения данных из-за неправильного проектирования. Почему? Очень просто: неправильно собрали данные. Не стали анализировать рабочее место. Да там много причин.

Поэтому главный вопрос — посчитать все параметры инфраструктуры. Поэтому до внедрения нужно обследование, чтобы точно выяснить расчётную мощность. Обследование обычно проводится на уровне общения по бизнес-процессам и установки пользователям специального приложения, профилирующего рабочую станцию. Когда все данные за, скажем, месяц работы собираются, становится понятно, что и как делать. Месяца хватает. Да, понятно, что у бухгалтерии есть пики перед сдачей отчётности, разработка активизируется на большие релизы, маркетологи любят смотреть видео при выходе рекламы и так далее. Но эти пики не происходят одновременно, и 10–15% запаса по мощности вполне хватает, чтобы не упираться никуда по ЦОДу.

Каналы

Когда VDI разворачивается локально, всё просто. Когда удалённо – как правило, минимальное требование сегодня — гарантированные 128 Кбит/с на пользователя. Обратите внимание: гарантированные. Конечно, часто говорят про 30–40 Кб/с, но это, скажем так, неправда. Пока пользователь печатает, всё хорошо. Но когда он листает свою ленту «ВКонтакте», трафика генерится ненамного меньше, чем при просмотре видео.

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

Естественно, в Москве куда чаще встречается ситуация с гарантированными 10 Мбит/с на обычный офис, там, как правило, вообще проблем не возникает. На крупные офисы от 200–300 сотрудников (по ситуации и профилю трафика) часто ставим решения по уплотнению трафика, начиная от транспортного уровня и заканчивая дедупликацией, например, от Riverbed (http://habrahabr.ru/company/croc/blog/214693/).

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

Рабочий стол ОС Windows функционирующей на физической рабочей станции:

Рабочий стол ОС Windows, но функционирующей в виртуальной машине, размещённой в ЦОД:

Интерфейс программного VDI-клиента:

Кто использует VDI?

Принцип очень простой. Если вы малый или средний бизнес и администрировать пока всё относительно просто, ваш выбор — терминальный доступ. Там, где вы потратите 500 рублей на него, в VDI пришлось бы потратить 5 тысяч.

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

Например, в колл-центрах важны стабильность работы и меры против высокой текучки персонала. Стабильность — это когда 60 тысяч звонков на КЦ в сутки, и работают три смены без перерывов на одних и тех же местах. Я знаю тонкие клиенты, которые работают 5–6 лет без выключения на таких объектах.

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

Крупный бизнес очень ревностно относится к СХД. Как правило, она резервируется такой же active-active, плюс системой итеративного бэкапа в другом ЦОДе вроде Avamar (http://habrahabr.ru/company/croc/blog/149306/). Потому что в VDI растёт человеческий риск. Знаю случай в одном банке, когда накатили неверный апдейт на 2000 машин. Работа встала. Правда, всего на 12 минут — админы быстро откатились.

Иногда с VDI встают к нам: у нас 3 своих коммерческих ЦОДа, они на разных площадках, есть решения повышенной надёжности (два подтверждения TIER III). Для крупных заказчиков это один контрагент, который берёт на себя весь сервис, резервирование и все вопросы по рутине.

Источник