Конечно заинтересует. Работа с оркестратором многим интересна и мало где описана.
Вы бы хотя бы список задач, подлежащих автоматизации, на ваш взгляд, привели в конце (а в последующих статьях их проработали, например), чтоб было понятно, ради чего это всё.
У статьи такой многообещающий заголовок, а промотав портянку полноразмерных скриншотов (с нехилыми тормозами, надо сказать, ввиду технических особенностей моего подключения) я чувствую себя обманутым и немножко негативно воспринимающим veeam.
Статья называется «Автоматизация задач резервного копирования...».
Какие задачи были автоматизированы в ходе этой статьи?
Я вижу только процедуру подключения vCO к Veeam с большим количеством бессмысленных скриншотов, создающих иллюзию объёма статьи.
Отличная идея, отличный сервис, но от формы подачи материала в стиле маркетингового буклета сводит зубы.
«Совершенно бесплатно» (бывает немного бесплатно, бесплатно и совершенно бесплатно?).
«Один из наших недорогих пакетов» (по чьей оценке?)
«Буквально за несколько минут».
«Крайне просто».
Ключевые фразы «магазина на диване».
Не говоря уж о «бесплатном сервисе», на поверку не таком уж и «совершенно бесплатном», а просто «с недорогими пакетами».
Нет, я и не жду халявы, но какие-то очень грубые и примитивные методы заманивания.
Предлагаю не останавливаться на полумерах.
Разделить IT Pro и Development по разным ресурсам.
Отделить сети от операционных систем. Гипервизоры от гостевых ОС. Windows от Linux. Разработчиков разделить по платформам и языкам. Каждой группе свой сайт, и пусть никто не уйдёт обиженным.
Часть терминов режет глаз, ввиду того, что в русском языке они привычнее в другом произношении.
swap — своп.
deduplication — дедупликация.
snapshot — снапшот
performance — перфоманс (а лучше вообще «производительность»).
Но, возможно, это не повсеместно, не уверен, есть ли эти слова в словаре, так что не буду говорить, что это грамматически некорректно. Интересно послушать мнения.
С точки зрения материала статьи, всё верно. И очень подробно. Настолько, что, на мой взгляд, может сбить с толку.
Путаницу в двух типах свопинга вносит именно упоминание этих двух типов в одном источнике. На мой взгляд, говоря о гипервизоре, имеет смысл говорить о других двух типах свопа — первый это vSwap, то есть тип 1 в данной статье, а второй это vmKernel swap — когда гипервизору не хватает памяти (вся занята виртуальными машинами) и он свопится и это влияет на производительность всего хоста. Процессы, происходящие внутри гостевой ОС, по большому счёту, отношения к гипервизору не имеют.
Хотя в рамках данной статьи, имеющей целью оптимизацию настроек для netApp, у которого одна из киллерфич — снапшоты, данное упоминание, конечно, актуально в рамках рассуждений по уменьшению размера снапшота.
Также все рассуждения по vSwap можно свести к одному — не допускать. Хотя из статьи может показаться, что технология как-то может помочь в сложных ситуациях. Как показывает практика, минимальное погружение ВМ в своп парализует её в подавляющем большинстве случаев. Просто потому, что данные, которые система ожидает обнаружить в быстрой памяти, оказываются на оочень медленном диске (в сравнении с RAM даже SAS — улитка). Единственное, что может скрасить ситуацию — SSD и host cache, но на данный момент чипы RAM дешевле SSD, так что обоснованного применения технологий host cache я не видел. Тем более, что даже ssd в разы медленнее.
Под ваше описание балаболов-бездарей попадают все учёные-исследователи. Они ведь тоже не заморачиваются практическим применением горизонта событий, например, а Большой Адронный Коллайдер, так вообще сплошной убыток и растрата ресурсов. В дальнейшем их исследования, однако, могут использоваться в прикладных аспектах. А могут и не использоваться.
Если не прикапываться к личности Криса, а рассматривать статью, то результат — смена привычного распорядка, а методы — как раз описанные пункты. Нужен вам этот результат для достижения своих каких-то результатов — вам решать. Никто не навязывает же.
Мне вот ранние подъёмы помогли значительно. Хотя описанная тут методология для меня была бы неприемлема.
«Ещё чуть-чуть попрограммирую» говорит об отсутствии намерения. Грубо говоря, цель стать «жаворонком» осталась на уровне «нехерово было бы» и не перешла на уровень «я намерен это сделать». Потому что если есть намерение — ищешь способ решения. Например, перестать программировать за час два до полуночи и посвятить последний час планированию, чтению, медитации, мастурбации, в общем чему-то, то способствует расслаблению и отходу ко сну. И если есть намерение, даже будильник не понадобится — я сказал, я сделал.
По поводу включения мозга после пробуждения, не могу ничего утверждать. 4 года назад я перешёл на работу с режимом 8-17, что вынудило меня вставать в 6 утра. Это было мучением, а работу я мог начать лишь после 12 дня. В итоге через пол года я уволился и перешёл туда, где работали с 10. Сейчас я понимаю, что я не был готов тогда к смене привычного режима, а блокировка мозга была вызвана внутренним протестом.
Так что первое, что стоит определить — а надо ли? И зачем? Что изменится? Ради чего себя переделывать? Что я буду делать утром? (это вообще обязательно) Если твёрдого понимания, что это разрешает какие-то проблемы, нет, то организм будет препятствовать изо всех сил, ибо стремится к сохранению порядка вещей. И всё вернётся на круги своя.
Ну или нужна твёрдая воля, жёсткие правила и период их соблюдения не меньше 25 дней.
К сожалению (или к счастью) у меня нет проблем с технологиями Microsoft. Всё что мне в них ещё не известно, я знаю где найти, прочитать и как проверить. Меня интересовали вопросы, связанные с Citrix XenDesktop, Advanced FC-SAN administratoin (FC-Routing) и технической реализацией частного облака на базе VMware (много вопросов возникло на стыке перехода от vCloud Director к vCAC). К сожалению, в большинстве случаев, возникало ощущение, что инструктор сам видит слайды впервые и переводит на лету. А в некоторых случаях ещё и имеет трудности с английским языком и просто вещает свои интерпретации написанного.
Вспоминаю выражения «Облачный директор», «командная линия» и мои уши кровоточат.
Про Кибкало я наслышан и был бы не прочь побывать на его курсах, но трудно объяснить будет руководству, что они мне нужны. Тем более при сложившемся экономическом раскладе.
Хотя от посещения УЦ «Звёзды и С» остались жутковатые впечатления (сдавал там VCP).
Проведите пару дней полный хронометраж (каждые пол часа-час отмечать, чем занимаешься в данный момент) или хотя бы в коце дня попробуйте восстановить всю последовательность событий. Или раз в 4 часа описать каждый пройденный час.
Лечение прокрастинации подменой цели. Ирония в том, что мозг на это ведётся.
Не «заниматься проектом модернизации инфраструктуры», а «подготовить 5 LUN и перенести на них содержимое текущего кластера» (техника «порубить слона на бифштексы»).
Не «написать модуль обработки аудиопотока», а «программировать с 9:30 до 10:00» (техника Pomodoro).
Не «прийти на работу к 8 утра», а «выйти из дома в 7» (официальное название техники, если оно есть, мне неведомо).
Другое дело, что прокрастинация — защитный механизм организма. И без понимания причины, его вызвавшей, бороться с ним — всё равно что глушить симптомы болезни без её лечения. Обеспечивает временное облегчение, но в долгосрочной перспективе может привести к осложнениям. То есть стрессу, неврозу и потребности убивать людей.
Не совсем. Субъективное увеличение продолжительности суток связано с увеличением количества полезных выполненных дел. Так как ранее свободное время было вечерним, большей частью проводимое за играми, интернетом или кино ввиду усталости и нежелания напрягаться.
Однако режим повлиял на накопление недосыпа, так как раньше я в выходные мог спать до обеда, фактически сокращая полезное время дня вдвое. Сейчас встаю даже в выходные не позже 7-8:00, но заставить себя лечь раньше 23:00 тяжело.
Поэтому приходится тщательнее контролировать время сна в будни.
Раньше в будни спал 6 и меньше часов, а в выходные пытался отоспаться. Но такой вариант и объективно и субъективно хуже нынешнего.
Фрейдистские комплексы тут сложно усмотреть. А протест, в общем-то, нормальный. Я и сейчас ловлю себя на том, что собравшись и закончив все утренние процедуры, я за каким-то хреном сажусь за ноутбук, вместо того чтобы направиться в сторону выхода, хотя отчётливо вижу, что время 7:00, а значит каждая следующая минута становится минутой опоздания.
В данный момент я знаю (больше подсознательно), что ничего важного, или интересного, или срочного, что требовало бы моего присутствия ровно в 8:00, на работе нет. В другом месте и в другое время схожее поведение было вызвано именно протестом против требования быть ровно вовремя на работе.
В то же время, если я сам осознаю важность своего присутствия в нужное время или просто увлечён проектом/рабочим процессом, или сам назначил время события, я приду более чем вовремя.
Исправляется и тренируется легко жёсткой установкой времени выхода из дома.
Скажу прямо: восторга не испытываю. В своё время, может, и неплохой был продукт, но сейчас совсем убого.
1. Управление через писанный на Flash web-интерфейс. Ест много памяти, безбожно тормозит, имеет минимум возможностей по управлению.
2. Никаких тонких настроек. Даже «толстых» минимум — только управление пулами VDI и создание кластера. Сами серверы управления — апплаенсы, то есть блэкбоксы. Из доступной документации только он-лайн хелп, очень куцый. Единственный воркэраунд на все проблемы, который мне передал ушедший коллега: «перезагрузить оба сервера одновременно».
3. Буквально сегодня случился инцидент — с часть зеро-клиентов после ребута не смогла подцепиться. Моргали жёлтым глазом, будто не могли получить ip. Так как буквально месяц назад был прецедент с DHCP, наехали на DHCP-мастера и сетевиков, но оказалось, у них всё в порядке. В логах Pano сообщения, что client exited abnormally with exit code 134. Но что бы это значило, тайна великая есть.
Оказалось, место закончилось в рутовом разделе. java дампами забила.
4. Ну и отсутствие поддержки linked-клонов тоже жёсткий минус. Конечно, можно купить view и интегрировать (если новая версия сможет интегрироваться. Citix уже не может), но нелепо покупать два решения VDI только ради зеро-клиентов. Поэтому живём на старом Pano :(
Можно ещё играться с разными длинами очереди, но в подавляющем большинстве случаев лучше не надо.
Неплохая статья для получения представления о разного уровня очередях тут.
Не более 16 машин на датастор — это старые best practices, основанные на проблеме SCSI Reservation Conflicts.
Сейчас, с появлением VAAI и ATS на LUN можно размещать гораздо большее количество ВМ. От неограниченного отделяют возможности дисков и уровня RAID (1), а также очередь одновременных запросов к LUN (2):
1) Исходя из того, что SAS15k = 175 IOPS, SAS10k = 126 IOPS, SATA/NL-SAS = 75 IOPS, Write Penalty выбранного RAID и соотношения записи и чтения, а также средней IO-нагрузки каждой ВМ, считаем количество дисков, необходимых под LUN и создаём, невзирая на размер. В случае умных mid-range и выше массивов, которые виртуализируют дисковые ресурсы и размазывают LUN по максимальному количеству шпинделей, этот расчёт становится неактуальным. Учитывая, что никто толком не знает, как точно они это делают (и как экстендят пулы при добавлении дисков), а также дополнительные примочки типа разных уровней кэша, оптимальный размер LUN познаётся опытным путём, в зависимости от вендора СХД и конфигурации.
2) Очередь одновременных запросов к каждому LUN равна 32, соответственно, число ВМ на LUN зависит от количества OutstandingIO, генерируемых этими машинами и количества хостов, работающих с этим LUN. Например:
outstandingIO=32 — одна машина на LUN.
outstandingIO=16 — две машины, если обе на одном хосте. Четыре, если хоста два. Но такие показатели имеют место у очень нагруженных БД.
Если принять, что хостов у нас 15, а у VDI этот параметр, ну пусть 4 с запасом, то число их на датастор будет 15 * 32 / 4 = 120. Скорее всего раньше упрёмся по iops, а это пункт 1).
У нас под VDI сейчас созданы 4ТБ датасторы по 60-70 машин на каждом. Было плотнее, но latency был выше, поэтому добавил пару новых lun и размазал. Под серверы 6ТБ датасторы и машинами они наполняются пока место позволяет. Несколько особо чувствительных виртуальных серверов размещены на небольших датасторах с Hi-Level Tier.
Что-то ни плюсов ни минусов ни подводных камней я в статье не увидел. Точнее, они есть, но настолько поверхностные и размазанные по тексту, что… в общем, мои ожидания от соответствия заголовка статье не оправдались. Просто обзор формата «есть такое решение — VDI». И под видом развенчания мифов озвучены другие мифы.
Да, все рабочие станции хранятся централизованно в одном-двух ЦОД, но какое в этом преимущество с точки зрения управления?
Экономии ноль — как уже сказали, тонкий клиент стоит примерно столько же (а то и дороже) сколько и офисный компьютер. Эффективность от более долгой, по сравнению с ПК, эксплуатацией нивелируется тем, что в качестве процессорных, дисковых и RAM-ресурсов используются не дешёвые десктопные, а дорогие серверные компоненты.
Плюсы.
Самый существенный — невозможно сделать выемку оборудования при проверке.
Несомненный плюс в скорости развёртывания рабочего места — в худшем случае клон ВМ, в лучшем — подготовка персонального диска и первичная конфигурация — считанные минуты.
Почти устраняются инциденты, связанные с аппаратным обеспечением десктопов (остаются замена мыши, клавы, монитора и самого ТК).
Можно работать с чего угодна и откуда угодно, сохраняя своё рабочее окружение.
Минусы.
Как и в любой централизации, узким местом становятся каналы и оборудование «центра». Тут даже не о надёжности оборудования — да, крутая СХД и две фабрики SAN, резервные каналы, но даже осторожная переконфигурация физических свичей в связке с виртуальными завалила доступ к хостам на 15 минут. 15 минут умножаем на 1500 VDI. делим на 60 и получаем 375 человеко-часов простоя.
Управляемость. Помимо стандартных сетевых сервисов — AD, DNS, DHCP, File Shares и т.д., добавляются брокеры, композеры, управление виртуальной инфраструктурой. Появляется куча непростых в управлении элементов ЦОД — СХД, dvSwitches, FC-SAN etc. Нужно точно балансировать нагрузку по IO, сети, памяти и процессорам. Конечно, DRS помогает, но бут-штормы и прочие всплески активности могут парализовать работу на пол дня.
Это вообще прям вкратце. Я свою ферму VDI полирую уже пол года и всё время выискиваются новые слабые места и пространства для изменений. Притом, что изменения в рабочее время вносить, как правило, нельзя — ещё один минус управления инфраструктурой виртуальных рабочих столов.
Решение называется linked clones, когда все машины для загрузки используют мастер-образ одной машины. Реализуется и citrix и vmware и, наверное, другими решениями VDI, которых я не знаю.
В этом случае обновить нужно только одну ВМ, а остальные (настоящие пользовательские рабочие десктопы) — просто перезагрузить.
Вы бы хотя бы список задач, подлежащих автоматизации, на ваш взгляд, привели в конце (а в последующих статьях их проработали, например), чтоб было понятно, ради чего это всё.
У статьи такой многообещающий заголовок, а промотав портянку полноразмерных скриншотов (с нехилыми тормозами, надо сказать, ввиду технических особенностей моего подключения) я чувствую себя обманутым и немножко негативно воспринимающим veeam.
Какие задачи были автоматизированы в ходе этой статьи?
Я вижу только процедуру подключения vCO к Veeam с большим количеством бессмысленных скриншотов, создающих иллюзию объёма статьи.
«Совершенно бесплатно» (бывает немного бесплатно, бесплатно и совершенно бесплатно?).
«Один из наших недорогих пакетов» (по чьей оценке?)
«Буквально за несколько минут».
«Крайне просто».
Ключевые фразы «магазина на диване».
Не говоря уж о «бесплатном сервисе», на поверку не таком уж и «совершенно бесплатном», а просто «с недорогими пакетами».
Нет, я и не жду халявы, но какие-то очень грубые и примитивные методы заманивания.
Разделить IT Pro и Development по разным ресурсам.
Отделить сети от операционных систем. Гипервизоры от гостевых ОС. Windows от Linux. Разработчиков разделить по платформам и языкам. Каждой группе свой сайт, и пусть никто не уйдёт обиженным.
«доступ к категории веб-сайтов „Uncategorized URLs“. „
Хабр и гиктаймс — нет. Чтива стало на треть меньше.
В любом случае, больше одного ресурса читать и писать тяжело.
swap — своп.
deduplication — дедупликация.
snapshot — снапшот
performance — перфоманс (а лучше вообще «производительность»).
Но, возможно, это не повсеместно, не уверен, есть ли эти слова в словаре, так что не буду говорить, что это грамматически некорректно. Интересно послушать мнения.
С точки зрения материала статьи, всё верно. И очень подробно. Настолько, что, на мой взгляд, может сбить с толку.
Путаницу в двух типах свопинга вносит именно упоминание этих двух типов в одном источнике. На мой взгляд, говоря о гипервизоре, имеет смысл говорить о других двух типах свопа — первый это vSwap, то есть тип 1 в данной статье, а второй это vmKernel swap — когда гипервизору не хватает памяти (вся занята виртуальными машинами) и он свопится и это влияет на производительность всего хоста. Процессы, происходящие внутри гостевой ОС, по большому счёту, отношения к гипервизору не имеют.
Хотя в рамках данной статьи, имеющей целью оптимизацию настроек для netApp, у которого одна из киллерфич — снапшоты, данное упоминание, конечно, актуально в рамках рассуждений по уменьшению размера снапшота.
Также все рассуждения по vSwap можно свести к одному — не допускать. Хотя из статьи может показаться, что технология как-то может помочь в сложных ситуациях. Как показывает практика, минимальное погружение ВМ в своп парализует её в подавляющем большинстве случаев. Просто потому, что данные, которые система ожидает обнаружить в быстрой памяти, оказываются на оочень медленном диске (в сравнении с RAM даже SAS — улитка). Единственное, что может скрасить ситуацию — SSD и host cache, но на данный момент чипы RAM дешевле SSD, так что обоснованного применения технологий host cache я не видел. Тем более, что даже ssd в разы медленнее.
Если не прикапываться к личности Криса, а рассматривать статью, то результат — смена привычного распорядка, а методы — как раз описанные пункты. Нужен вам этот результат для достижения своих каких-то результатов — вам решать. Никто не навязывает же.
Мне вот ранние подъёмы помогли значительно. Хотя описанная тут методология для меня была бы неприемлема.
мастурбации, в общем чему-то, то способствует расслаблению и отходу ко сну. И если есть намерение, даже будильник не понадобится — я сказал, я сделал.По поводу включения мозга после пробуждения, не могу ничего утверждать. 4 года назад я перешёл на работу с режимом 8-17, что вынудило меня вставать в 6 утра. Это было мучением, а работу я мог начать лишь после 12 дня. В итоге через пол года я уволился и перешёл туда, где работали с 10. Сейчас я понимаю, что я не был готов тогда к смене привычного режима, а блокировка мозга была вызвана внутренним протестом.
Так что первое, что стоит определить — а надо ли? И зачем? Что изменится? Ради чего себя переделывать? Что я буду делать утром? (это вообще обязательно) Если твёрдого понимания, что это разрешает какие-то проблемы, нет, то организм будет препятствовать изо всех сил, ибо стремится к сохранению порядка вещей. И всё вернётся на круги своя.
Ну или нужна твёрдая воля, жёсткие правила и период их соблюдения не меньше 25 дней.
Вспоминаю выражения «Облачный директор», «командная линия» и мои уши кровоточат.
Про Кибкало я наслышан и был бы не прочь побывать на его курсах, но трудно объяснить будет руководству, что они мне нужны. Тем более при сложившемся экономическом раскладе.
Хотя от посещения УЦ «Звёзды и С» остались жутковатые впечатления (сдавал там VCP).
Другое дело, что прокрастинация — защитный механизм организма. И без понимания причины, его вызвавшей, бороться с ним — всё равно что глушить симптомы болезни без её лечения. Обеспечивает временное облегчение, но в долгосрочной перспективе может привести к осложнениям. То есть стрессу, неврозу и потребности убивать людей.
Однако режим повлиял на накопление недосыпа, так как раньше я в выходные мог спать до обеда, фактически сокращая полезное время дня вдвое. Сейчас встаю даже в выходные не позже 7-8:00, но заставить себя лечь раньше 23:00 тяжело.
Поэтому приходится тщательнее контролировать время сна в будни.
Раньше в будни спал 6 и меньше часов, а в выходные пытался отоспаться. Но такой вариант и объективно и субъективно хуже нынешнего.
В данный момент я знаю (больше подсознательно), что ничего важного, или интересного, или срочного, что требовало бы моего присутствия ровно в 8:00, на работе нет. В другом месте и в другое время схожее поведение было вызвано именно протестом против требования быть ровно вовремя на работе.
В то же время, если я сам осознаю важность своего присутствия в нужное время или просто увлечён проектом/рабочим процессом, или сам назначил время события, я приду более чем вовремя.
Исправляется и тренируется легко жёсткой установкой времени выхода из дома.
1. Управление через писанный на Flash web-интерфейс. Ест много памяти, безбожно тормозит, имеет минимум возможностей по управлению.
2. Никаких тонких настроек. Даже «толстых» минимум — только управление пулами VDI и создание кластера. Сами серверы управления — апплаенсы, то есть блэкбоксы. Из доступной документации только он-лайн хелп, очень куцый. Единственный воркэраунд на все проблемы, который мне передал ушедший коллега: «перезагрузить оба сервера одновременно».
3. Буквально сегодня случился инцидент — с часть зеро-клиентов после ребута не смогла подцепиться. Моргали жёлтым глазом, будто не могли получить ip. Так как буквально месяц назад был прецедент с DHCP, наехали на DHCP-мастера и сетевиков, но оказалось, у них всё в порядке. В логах Pano сообщения, что client exited abnormally with exit code 134. Но что бы это значило, тайна великая есть.
Оказалось, место закончилось в рутовом разделе. java дампами забила.
4. Ну и отсутствие поддержки linked-клонов тоже жёсткий минус. Конечно, можно купить view и интегрировать (если новая версия сможет интегрироваться. Citix уже не может), но нелепо покупать два решения VDI только ради зеро-клиентов. Поэтому живём на старом Pano :(
Неплохая статья для получения представления о разного уровня очередях тут.
Сейчас, с появлением VAAI и ATS на LUN можно размещать гораздо большее количество ВМ. От неограниченного отделяют возможности дисков и уровня RAID (1), а также очередь одновременных запросов к LUN (2):
1) Исходя из того, что SAS15k = 175 IOPS, SAS10k = 126 IOPS, SATA/NL-SAS = 75 IOPS, Write Penalty выбранного RAID и соотношения записи и чтения, а также средней IO-нагрузки каждой ВМ, считаем количество дисков, необходимых под LUN и создаём, невзирая на размер. В случае умных mid-range и выше массивов, которые виртуализируют дисковые ресурсы и размазывают LUN по максимальному количеству шпинделей, этот расчёт становится неактуальным. Учитывая, что никто толком не знает, как точно они это делают (и как экстендят пулы при добавлении дисков), а также дополнительные примочки типа разных уровней кэша, оптимальный размер LUN познаётся опытным путём, в зависимости от вендора СХД и конфигурации.
2) Очередь одновременных запросов к каждому LUN равна 32, соответственно, число ВМ на LUN зависит от количества OutstandingIO, генерируемых этими машинами и количества хостов, работающих с этим LUN. Например:
outstandingIO=32 — одна машина на LUN.
outstandingIO=16 — две машины, если обе на одном хосте. Четыре, если хоста два. Но такие показатели имеют место у очень нагруженных БД.
Если принять, что хостов у нас 15, а у VDI этот параметр, ну пусть 4 с запасом, то число их на датастор будет 15 * 32 / 4 = 120. Скорее всего раньше упрёмся по iops, а это пункт 1).
У нас под VDI сейчас созданы 4ТБ датасторы по 60-70 машин на каждом. Было плотнее, но latency был выше, поэтому добавил пару новых lun и размазал. Под серверы 6ТБ датасторы и машинами они наполняются пока место позволяет. Несколько особо чувствительных виртуальных серверов размещены на небольших датасторах с Hi-Level Tier.
Да, все рабочие станции хранятся централизованно в одном-двух ЦОД, но какое в этом преимущество с точки зрения управления?
Экономии ноль — как уже сказали, тонкий клиент стоит примерно столько же (а то и дороже) сколько и офисный компьютер. Эффективность от более долгой, по сравнению с ПК, эксплуатацией нивелируется тем, что в качестве процессорных, дисковых и RAM-ресурсов используются не дешёвые десктопные, а дорогие серверные компоненты.
Плюсы.
Самый существенный — невозможно сделать выемку оборудования при проверке.
Несомненный плюс в скорости развёртывания рабочего места — в худшем случае клон ВМ, в лучшем — подготовка персонального диска и первичная конфигурация — считанные минуты.
Почти устраняются инциденты, связанные с аппаратным обеспечением десктопов (остаются замена мыши, клавы, монитора и самого ТК).
Можно работать с чего угодна и откуда угодно, сохраняя своё рабочее окружение.
Минусы.
Как и в любой централизации, узким местом становятся каналы и оборудование «центра». Тут даже не о надёжности оборудования — да, крутая СХД и две фабрики SAN, резервные каналы, но даже осторожная переконфигурация физических свичей в связке с виртуальными завалила доступ к хостам на 15 минут. 15 минут умножаем на 1500 VDI. делим на 60 и получаем 375 человеко-часов простоя.
Управляемость. Помимо стандартных сетевых сервисов — AD, DNS, DHCP, File Shares и т.д., добавляются брокеры, композеры, управление виртуальной инфраструктурой. Появляется куча непростых в управлении элементов ЦОД — СХД, dvSwitches, FC-SAN etc. Нужно точно балансировать нагрузку по IO, сети, памяти и процессорам. Конечно, DRS помогает, но бут-штормы и прочие всплески активности могут парализовать работу на пол дня.
Это вообще прям вкратце. Я свою ферму VDI полирую уже пол года и всё время выискиваются новые слабые места и пространства для изменений. Притом, что изменения в рабочее время вносить, как правило, нельзя — ещё один минус управления инфраструктурой виртуальных рабочих столов.
В этом случае обновить нужно только одну ВМ, а остальные (настоящие пользовательские рабочие десктопы) — просто перезагрузить.