понедельник, 15 апреля 2019 г.

Проброс графического адаптера и режим ускорения графики vDGA

Сегодня я хочу рассказать о некоторых нюансах проброса графических адаптеров внутрь ВМ в режиме VMDirectPath I/O и ускорении графики в режиме vDGA в Horizon.

VMware Horizon поддерживает различные режимы ускорения графики для виртуальных десктопов. Из них три режима так или иначе могут задействовать ресурсы графических адаптеров: vSGA, Shared Pass-Through Graphics (он же NVIDIA vGPU или AMD MxGPU), а также vDGA.

Пример использования ускорителя NVIDIA Quadro P2000 в режиме vDGA можно увидеть по ссылке: http://blog.vmpress.org/2019/02/horizon-blast-h265.html.

vDGA задействует технологию проброса PCI устройства внутрь ВМ (VMDirectPath I/O) и позволяет предоставить одной из ВМ графический адаптер в монопольное использование. После проброса внутри гостевой ОС устанавливаются соответствующие драйверы устройства, и с ним можно работать также, как если бы оно было подключение к обычному настольному компьютеру. Это и является основным преимуществом, равно как и недостатком, данного режима, поскольку позволяет обеспечить максимальный уровень производительности работы графического адаптера, но в то же время накладывает на ВМ ряд ограничений, например, невозможность использования VMware HA, vMotion, снапшотов, необходимость резервирования оперативной памяти ВМ и т.д.

При использовании vDGA в связке с графическими адаптерами производства NVIDIA есть несколько нюансов.

Десктопные графические адаптеры серии GeForce (например, GeForce GTX 1060) не поддерживаются в данном режиме. При пробросе такого адаптера внутрь ВМ после установки соответствующих драйверов в диспетчере устройств будет отображаться сообщение об ошибке:
Windows has stopped this device because it has reported problems. (Code 43)

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

Драйвер можно обмануть, добавив расширенную настройку в конфигурацию ВМ.
hypervisor.cpuid.v0 = "FALSE"

В этом случае графический адаптер сможет работать внутри ВМ. Однако, в связке с VMware Horizon вы все равно не сможете обеспечить корректную работу протоколов PCoIP или BLAST с десктопными адаптерами - при удаленном подключении к такой ВМ вы просто увидите черный экран. Это вызвано ограничениями десктопной версии драйвера NVIDIA GeForce.

Возможности по работе с Horizon доступны только в линейке графических адаптеров серии Quadro и Tesla, причем младшие модели Quadro (400, 600) также не будут работать (error 43). Минимальные поддерживаемые модели, начинаются с 2000, например, M2000, P2000, M4000 и т.д. Если вы планируете использовать vDGA в Production среде, то обязательно проверьте совместимости с HCL на сайте VMware. Если вы хотите, чтобы ваше решение поддерживалось, то вы должны использовать поддерживаемый графический адаптер И поддерживаемую модель сервера И поддерживаемое поколение процессоров И поддерживаемую версию гипервизора ESXi И поддерживаемую версию Horizon. Даже если вы знаете, что какой-нибудь NVIDIA Quadro K5000 будет прекрасно пробрасываться внутрь ВМ с ESXi 6.7, отсутствие поддержки данной версии гипервизора означает, что решение в целом будет неподдерживаемым со стороны вендора.

Существует заблуждение, что при использовании ускорителей NVIDIA Tesla в связке с vDGA не требуется приобретать лицензии NVIDIA GRID (в отличие от vGPU). Это не так, в чем легко можно убедиться, заглянув в документацию по лицензированию NVIDIA.

Требование по лицензированию не распространяется на ускорители серии NVIDIA Quadro, что делает их более привлекательным решением для задач vDGA в сравнении с Tesla.

понедельник, 1 апреля 2019 г.

Factorio - пособие для начинающих автоматизаторов

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

Речь идет об одном приложении, а точнее - видеоигре, под названием Factorio. Если описать игру двумя словами - это "симулятор инженера". Factorio сложно отнести к какому-то определенному игровому жанру, в ней присутствуют геймплейные элементы стратегии в реальном времени, survival, экономического симулятора, экшена, помноженного на процесс сборки конструкторов Lego. Если проводить аналогии, то Factorio чем-то похожа на такие игры, как Minecraft, Subnautica, Terraria, но имеет множество своих уникальных черт.

Вы играете за персонажа, который оказался на далекой и крайне враждебной планете. Цель игры - построить ракету, которая доставит спутник на орбиту. Вот только есть одна "небольшая" загвоздка - из подручных инструментов у вас только пистолет для самообороны от агрессивной фауны и кирка для добычи полезных ископаемых (уже на этом этапе игры возникают некоторые параллели с ИТ в малом бизнесе, когда руководство дает шанс проявить себя, поставив задачу "собрать звездолет из камней и палок"). Как и в реальной жизни, взять и построить ракету с нуля вы не можете - не хватит ни ресурсов, ни знаний/опыта. Благо планета богата всевозможными полезными ископаемыми (железной и медной рудой), а также древесиной, камнем, а на более поздних стадиях игры вы сможете добывать нефть и уран.
Начало игры. При первом прохождении постройка космической ракеты может занять более 40 часов.

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

Кстати, по поводу враждебной планеты, где-то через час после начала игры (в зависимости от настроек сложности), местные представители агрессивной фауны впервые покажутся и начнут в буквальном смысле жрать вашу базу и вас. Чем не аллюзия на современные угрозы кибер-безопасности? Конечно, вы можете самостоятельно отбить несколько первых атак, используя имеющийся в наличии пистолет, но со временем по мере разрастания вашей базы, атаки станут более частыми, а атакующие вас со всех сторон инопланетяне все более смертоносными. У вас не останется выбора, кроме как выстроить надежный защищенный периметр, отгородившись толстыми стенами с кучей разнообразных автоматических турелей (от обычных пулеметов, до лазерных и огнеметных установок на поздних стадиях игры). Но не думайте, что, построив стены и заминировав все подходы, вы сможете полностью защититься от инопланетной угрозы. Лишь вооружившись дробовиком, гранатами, а лучше - танком, вы сможете на корню выжечь поселения инопланетян в непосредственной близости от базы. Я не нашел прямой аналогии с реальной жизнью, но будет считать это поведение аллегорией на то, как современный бизнес полагается на ИТ, чтобы повысить экономическую эффективность, снизать издержки и риски, и, в конечном счете, победить конкурентов.
Режим карты. Здесь можно увидеть основные производственные линии, а также защитный периметр нашего мега-завода. Красные точки, окружающие базу - это враги.

Кое-как обезопасившись от незваных гостей, вы продолжаете развитие своей базы. И в какой-то момент вы столкнетесь с проблемой оптимизации, о которой в свое время писал Э. Голдратт в книге "Цель": "Увеличение мощностей завода достигается за счет увеличения мощностей исключительно бутылочных горлышек."

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

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

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

Помочь с дизайном вам могут типовые конструктивные блоки (blueprint), которые будучи спроектированными один раз, затем могут тиражироваться для масштабирования и распараллеливания производственной нагрузки. Можно пойти еще дальше и не изобретать "велосипед", а воспользоваться опытом других игроков, взяв их наработки, и реализовать в своей "инфраструктуре". В Интернете, на тематических ресурсах и на каналах Reddit, посвященных игре, можно найти кучу разнообразных шаблонов, нередко с многостраничным обоснованием и математическими расчетами, показывающими эффективность того или иного решения.
За счет стандартизации и использования типовых конструктивных блоков можно, фактически, достигнуть неограниченного параллелизма в производстве. Были бы ресурсы.

Ресурсы в игре не безграничны (по крайней мере при использовании стандартных настроек карты) и практически всегда весьма остро стоит вопрос "планирования бюджета". На что потрать свое время - построить еще пару заводов по сбору продвинутых двигателей, либо побыстрее исследовать вон ту технологию, которая откроет доступ к более быстрым конвейерам и позволит ускорить доставку ресурсов на критичных участках производства, либо заняться укреплением обороны, чтобы не приходилось постоянно чинить погрызенное инопланетянами дорогостоящее оборудование.

Но рано или поздно вы истощите имеющиеся в округе запасы полезных ископаемых и вам придется расширять базу, захватывая все большие территории, буквально метр за метром отбивая землю у инопланетян. Поскольку местность и ресурсы генерируются случайным образом, то может так оказаться, что необходимый вам уран находится в нескольких игровых километрах от вашей основной базы. Что делать? - строить удаленные ЦОД аванпосты. Вот только тянуть конвейерные ленты (читай - LAN и оптику) до аванпоста - это весьма дорогостоящий и трудозатратный проект, который также потребуется включить в защищаемый периметр. Выход - использовать WAN (железную дорогу). Проложив рельсы, и подцепив к поезду несколько составов, вы можете загрузить в них необходимые ресурсы на аванпосту и доставить их к заводам на основной базе. Вообще, строительство железной дороги - это своеобразная игра в игре (этакий аналог Railroad Tycoon), вы должны правильно спроектировать сеть железных дорог, станций, семафоров и переходов, а также запрограммировать движение поездов таким образом, чтобы они не сталкивались друг с другом и максимально быстро осуществляли доставку ресурсов, и не сбивали вас, пока вы перебегаете пути в положенном месте.

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

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

Описанный мной free to play - не единственный режим, доступный в Factorio. Помимо него есть несколько сценариев - специально сгенерированных карт, призванных познакомить игроков с определенной игровой концепцией. Хотите лучше разобраться в механизме работы конвейеров и их ограничениях или прочувствовать на себе всю тяжесть работы в стесненных обстоятельствах с минимальными ресурсами, будучи окруженным толпами врагом - пожалуйста. Кроме того, Factorio поддерживает multiplayer режим, с теоретически, неограниченным количеством игроков. Если вы в одиночку не справились с постройкой базы, то можете попробовать взять на себя роль менеджера проекта, управляющего кучкой самоуверенных инженеров, а в случае чего, свалить на них ответственность за проигрыш. Наконец, для творческих личностей, существует режим sandbox, убирающий survival составляющую игры, и позволяющий построить мега-завод своей мечты.

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

Я рекомендую попробовать Factorio всем, кто любит необычные, развивающие и обучающие игры, кому нравится часами что-то строить и создавать, короче - инженерам.

понедельник, 25 февраля 2019 г.

Проблема с совместимостью Persona Management и Windows 10 1809

После настройки и включения Persona Management, входящего в состав Horizon Agent 7.7, на ВМ с Windows 10 1809, гостевая ОС перестает загружаться и попадает в Recovery Mode.

До выхода обновления обновления исправляющего ошибку, в качестве обходного варианта для решения проблемы требуется отклучить Secure Boot в настройках ВМ (VM -> Edit Settings -> VM Options -> Boot Options -> Enable UEFI secure boot: Disable).

понедельник, 18 февраля 2019 г.

Видео: Демонстрация работы Horizon Blast с кодеком h.265

Одним из нововведений VMware Horizon 7.7 стала поддержка нового кодека H.265, используемого для сжатия изображения в протоколе Horizon Blast.

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

По сравнению со старым H.264 кодеком H.265 (он же HEVC - High Efficiency Video Coding) обеспечивает до 50% лучшую компрессию при сохранении того же уровня качества изображения, что в свою очередь, позволяет снизить требования к каналам передачи данных.

В одной из своих старых статей я уже рассказывал об особенностях работы H.264 с BLAST и графическими адаптерами NVIDIA. Использование H.265 тоже имеет ряд особенностей.

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

Кроме того, в отличие от более старого и более распространенного H.264, новый кодек поддерживают далеко не все графические адаптеры. Например, среди ускорителей NVIDIA функция аппаратного кодирования H.265 поддерживается только для последних актуальных поколений графический процессоров Maxwell, Pascal, Volta и Turing, а декодирование - для Pascal, Volta и Turing: https://developer.nvidia.com/video-encode-decode-gpu-support-matrix Для встроенных графических адаптеров Intel поддержка аппаратного декодирования H.265 реализована в процессорах поколения Haswell и более новых.

Наконец, использовать кодек пока что можно только на клиентах Horizon Client for Windows версии 4.10 (https://docs.vmware.com/en/VMware-Horizon-Client-for-Windows/4.10/rn/horizon-client-windows-410-release-notes.html). На других платформах (включая тонкие клиенты) придется довольствоваться старым H.264 кодеком.

понедельник, 21 января 2019 г.

Chromebook - идеальный мобильный клиент?

Среди всего многообразия клиентских устройств, присутствующих на корпоративном рынке, существует отдельная ниша - мобильные тонкие клиенты. Мобильные тонкие клиенты визуально неотличимы от обычных ноутбуков начального уровня, обладают далеко не самым производительным процессором и объемным диском, и отличаются, как правило, установленной операционной системой - Windows 7 Embedded или Windows 10 IoT, либо ОС на базе Linux, а также возможностью централизованного управления и обновления устройств из единой консоли (Wyse Management Suite, HP Device Manager и другие).

Основная задача данных устройств, как и в случае с обычными тонкими клиентами, обеспечивать подключение пользователей к терминальным серверам и виртуальным рабочим станциям, а также веб-сервисам. Благодаря удобному форм-фактору, и из-за того, что все приложения, с которыми работают пользователи, выполняются на удаленных серверах, и на самих мобильных тонких клиентах не хранятся никакие данные, такие устройства могут стать незаменимым спутником для тех сотрудников, кто часто бывает в поездках, и кому требуется доступ к корпоративным сервисам.
С другой стороны, уже давно среди ноутбуков начального уровня большой популярностью пользуются устройства на базе Chrome OS от компании Google. Все ведующие производители ноутбуков (Acer, Asus, Dell, HP, Lenovo) имеют в своем ряду пару-другую моделей с предустановленной Chrome OS. Благодаря невысокой цене (стоимость многих моделей Chromebook находится в районе 200$) и поддержке полноценной версии веб-браузера Google Chrome, они являются отличным вариантом для работы с веб-приложениями.

В моей коллекции устройств есть Chromebook - ASUS C202SA, о котором я и планирую рассказать сегодня.

Это модель начального уровня, обладающая следующими характеристиками:
  • Ноутбук с диагональю экрана 11.6" с разрешением 1366x768.
  • Двухъядерный процессор Intel Celeron N3060, с тактовой частотой 1.6 ГГц.
  • 4 ГБ ОЗУ LPDDR3.
  • 16 ГБ eMMC накопитель для хранения ОС, приложений и документов пользователей.
  • Беспроводной комбинированный адаптер Wi-Fi 802.11ac и Bluetooth 4.2.
  • Веб-камера.
  • Встроенный кард-ридер SD карт.
  • HDMI выход для подключения внешнего монитора, один комбинированный 3.5" аудио-разъем, 2 порта USB 3.0 Type A.
  • Trusted Platform Module для безопасной загрузки и хранения паролей.
Само устройство выполнено в компактном, но весьма крепком пластиковом корпусе, усиленный по краям материалом наподобие резины, способным смягчить удары при падении ноутбука. Встречаются и другие модели Chromebook, в том числе выполненные целиком из алюминия, например Acer Chromebook 14 или Chromebook Pixel.

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

Chrome OS - это основанная на Linux операционная система, с приятным минималистичным интерфейсом, основная задача которой - обеспечивать работу с веб-приложениями посредством браузера Google Chrome. Chrome OS не содержит ничего лишнего - помимо браузера и пары ссылок на веб-сервисы Google, вроде Gmail, Google Drive и Youtube, в системе можно найти, разве что, калькулятор, простой текстовый редактор и файловый менеджер, что не идет ни в какое сравнение с десятками предустановленных приложений и кучей рекламных ссылок в какой-нибудь Windows 10 Home/Professional.

Но не веб-приложениями едиными сможет довольствоваться пользователь, на Chromebook также можно запускать приложения для платформы Android, устанавливаемые через Play Market, что делает его полноценным мобильным устройством.

Начиная с 69 версии Chrome OS, появилась поддержка нативных Linux приложений (пока в бета режиме и не на всех устройствах). После включения данной функции в настройках ОС, на Chromebook загружается и запускается миниатюрная виртуальная машина с Debian и открывается консоль терминала. Краткий FAQ по возможностям работы с Linux приложениями доступен по ссылке.

Более того, Google работает над тем, чтобы добавить Windows 10 в качестве дополнительной ОС, доступной для запуска на Chromebook. Все это открывает широкие возможности по использованию Chromebook в качестве мобильного тонкого клиента, достаточно установить подходящие приложения для удаленного доступа из онлайн-магазина. На Chrome OS можно установить и использовать:
  • VMware Horizon Client
  • Citrix Receiver
  • Microsoft Remote Desktop Client
  • Parallels Client
  • Teradici PCoIP Client
и множество других приложений-клиентов. В моей модели Chromebook используется интегрированное графическое ядро Intel HD Graphics 400, поддерживающее аппаратное декодирование h.264 (и даже h.264 до 4K), а это значит, что при использовании протокола BLAST в Horizon View, данное устройство способно обеспечить приемлемую частоту кадров.

В качестве примера можно посмотреть данное видео, где демонстрируется подключение с Chromebook к виртуальной рабочей станции с графическим адаптером, проброшенном в режиме NVIDIA vGPU.

К недостаткам клиента Horizon Client for Chrome OS можно отнести отсутствие поддержки дополнительных полезных функций, вроде проброса USB устройств и смарт-карт, подключения локальных принтеров, работы в многомониторных конфигурациях и Multi-media Redirection. Это накладывает ограничения, уменьшая количество возможных сценариев работы с Chromebook. Решить эту проблему можно было бы за счет функции запуска нативного Linux клиента Horizon, однако такой вариант на текущий момент не поддерживается.

Что касается удаленного управления устройствами с Chrome OS, то помимо базовых возможностей вроде поиска и обнуления потерянного устройства через привязанный к устройству аккаунт Google, можно воспользоваться одним из доступным на рынке Enterprise Mobility Management решений, например, VMware Workspace ONE UEM (AirWatch), MobileIron, Citrix XenMobile и другие. Пример демонстрации настройки Chromebook с Airwatch.

Возвращаясь к исходной теме статьи - можно ли считать Chromebook идеальным мобильным тонким клиентом? И да, и нет. Если основным ограничивающим фактором для вас является бюджет, то Chromebook - действительно интересный вариант, который работает прямо из коробки и не требует доведения до ума и чистки от кучи предустановленного мусора, в отличие от Windows 10. Также Chromebook предлагает более высокий уровень защищенности за счет использования модуля TPM, обеспечивающего доверенную загрузку и шифрование данных, хранящихся на ноутбуке (хотя с использованием TPM в России есть определенные проблемы).

С другой стороны имеющиеся в ПО для удаленного доступа ограничения не позволяют полностью отказаться от компьютера с Windows. Пускай Chromebook и позволяет мне решать порядка 95% всех возможных задач, я в силу привычки продолжаю использовать ОС от Microsoft. А с "вредными" привычками очень тяжело бороться.

понедельник, 24 декабря 2018 г.

Новогодний ESXi

Близятся новогодние праздники. Однако из-за обилия работы далеко не у всех было время купить елку и развесить украшения в доме. Добавить новогоднего настроения поможет эта нехитрая модификация интерфейса ESXi.

Подключитесь к хосту по ssh под учетной записью root и в командной строке напишите:
cp /etc/motd /etc/motd.backup
echo -e "   *   __       *         *      *    \n*    _|--|_  *     * /\     *         \n  \__ ('') __/ *    /\/\            * \n     (^^^^)        /_/\_\ *    *      \n  * (^^^^^^)      *  ||     *        *\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n~~ Merry Christmas & Happy New Year ~~\n~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~\n" > /etc/motd
Теперь каждый раз при подключении к Service Console или по SSH вы сможете наблюдать незамысловатую ASCII картинку.

А для того, чтобы "убрать елку", достаточно будет заменить содержимое /etc/motd из старого файла /etc/motd.backup.

вторник, 6 ноября 2018 г.

Особенности работы Sparse дисков в VMware ESXi

Сегодня я хотел бы рассказать об особенностях архитектуры "разреженных" (Sparse) дисков, использующихся для виртуальных машин на базе гипервизора ESXi.

Знание аспектов работы Sparse дисков позволит лучше понять преимущества и недостатки при использовании для защиты данных виртуальных машин (снапшоты и бекапы) или для клонирования виртуальных машин (Linked Clones).

Начнем с общей теории. ESXi поддерживает множество различных форматов виртуальных дисков: VMFS, vmfsSparse, vmfsSeSparse, RDM, VVOL, vSAN.

Формат VMFS (также известный как FLAT) имеет простую структуру и используется для thick и thin дисков. Каждый виртуальный диск хранится в виде нескольких файлов - файла дескриптора (.vmdk), бинарного файла с данными (-flat.vmdk) и опционального файла, хранящего информацию об измененных блока ( -ctk.vmdk), используемого для резервиного копирования данных.

Пример файла дескриптора.

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=ec393eec
parentCID=ffffffff
createType="vmfs"

# Extent description
RW 4194304 VMFS "vm01-flat.vmdk"

# The Disk Data Base
#DDB
ddb.adapterType = "lsilogic"
ddb.geometry.cylinders = "261"
ddb.geometry.heads = "255"
ddb.geometry.sectors = "63"
ddb.longContentID = "b67f98419cca278410ca1bd9fffffffe"
ddb.thinProvisioned = "1"
ddb.uuid = "60 00 C2 94 5a a7 a8 8e-d6 41 59 5b b0 06 b3 2b"
ddb.virtualHWVersion = "14"

Бинарный файл с данными имеет плоскую структуру, такую же как файл .dd. Секторы хранятся последовательно, нулевой сектор имеет адрес 0x0000, первый - 0x0200, второй - 0x400 и так далее.

Thin диск в отличие от Thick диска не требует выделения всего дискового простанства при создании, а увеличивается по мере заполнения данными. Гранулярность с которой растет thin диск зависит от размера файлового блока, который использует файловая система VMFS. Для VMFS 5 и VMFS 6 размер файлового блока по умолчанию составляет 1 МБ. Thin диск, по мере записи в него новых данных, будет увеличиваться частями (сегментами) по 1 МБ. Это может приводить к большей фрагментации файлов thin дисков по сравнению с thick дисками, особенно в тех случаях, когда на хранилище VMFS располагается много thin дисков, которые постепенно увеличиваются в размере.

Поскольку thick и thin диски имеют одинаковый внутренний формат (FLAT), отсюда следует первый нюанс - возможность хранения тонких дисков - это свойство файловой системы VMFS (или NFS сервера, если его файловая система поддерживает thin provisioning), а не самого формата. Это можно легко проверить на практике, создав пустой тонкий диск размером 1 ГБ, а затем скопировать его на компьютер с ОС Windows на раздел с файловой системой NTFS, используя File browser или scp. После копирования файл будет занимать ровно 1 ГБ.

Второй нюанс заключается в том, что VMFS является кластерной файловой системой с разделяемым доступом. Для координации доступа используются метаданные файловой системы, в которых указывается - в какие файлы/области диска какой из хостов может выполнять запись. Каждый раз при выделении нового сегмента (при создании нового диска или при увеличении размера существующего тонкого диска) один из хостов ESXi выполняет блокировку всего тома, используя SCSI-3 резервацию, для обновления метаданных, что негативно сказывается на производительности операций ввода-вывода, либо только определенных секторов, используя механизм ATS VAAI (если это поддерживается со стороны СХД).

Sparse диски

Sparse диски (они же delta-диски, Redo Log файлы или снапшоты, как их называют в быту) имеют более сложную структуру по сравнению с thick и thin дисками.

Sparse диск создается "поверх" родительского диска (другого Sparse диска или базового VMFS диска), формируя своеобразную цепочку, или дерево, если из одного родительского диска создано несколько Sparse дисков. Sparse диск аккумулирует в себя все изменения (все операции записи), которые выполняются для данной цепочки, выступая т.н. Redo Log файлом, и растет по мере заполнения.

Но Sparse диски могут использоваться и без снапшотов (те же linked clones ВМ) и даже без родительского диска, например, можно создать пустой SE Sparse диск, выполнив команду:

vmkfstools -c 10g -d sesparse disk.vmdk

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

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

Однако, поскольку Sparse диски хранятся на файловой системе VMFS, то минимальный размер файла связан с размером файлового блока (по умолчанию, 1 МБ для VMFS5). Это не всегда верно, так как я намеренно опускаю ряд технических деталей по хранению файлов маленького размера внутри файловых дискрипторов или суб-блоков, чтобы не перегружать читателей. В реальности размер дискового пространства, с которым растет Sparse диск, составляет 16 МБ. Умудренный читатель спросит - почему для Sparse диска единоразово выделяется больше места, чем для Thin диска (16 МБ против 1 МБ)? Я не нашел достоверной информации по этому поводу, но могу предположить, что это сделано для того, чтобы уменьшить количество блокировок VMFS, которые возникают при увеличении размера файла и необходимости выделения новых файловых блоков - Sparse диски растут гораздо быстрее, т.к. в них записываются не только новые блоки данных, но и изменения в блоках родительских дисков.

Для связи родительского (parent) диска с дочерними используется механизм указателей. В каждом файле дескриптора .vmdk присутствуют два поля:

CID=ec393eec
parentCID=ffffffff

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

Поле parentCID позволяет выстроить цепочку зависимостей между виртуальными дисками. При создании Sparse диска в поле parentCID прописывается значение CID-идентификатора родительского диска. У базового VMFS диска значение parentCID всегда равно 'ffffffff'.

На картинке ниже приведен пример многоуровневого дерева снапшотов и значение идентификаторов.

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

Структура Sparse диска приведена на рисунке.

Заголовок Sparse файла (COW Header) включает в себя следующие поля (это далеко не все поля, присутствующие в заголовке):
  • magicNumber [4 байта] - хранит в себе слово COWD в ASCII формате.
  • version [4 байта] - всегда равна 1.
  • flags [4 байта] - значение равно 3.
  • numSectors [4 байта] - количество секторов базового диска.
  • grainSize [4 байта] - размер блока данных (в секторах), который используется для хранения данных (для Sparse дисков ESXi равен 1 сектору).
  • gdOffset [4 байта] - смещение с которого начинается Granular Directory, равен 4 секторам.
  • numGDEntries - кол-во GDE (равен numSectors / gtCoverage).
  • freeSector - адрес смещения следующего свободного сектора, где может размещаться GT или полезные данные.
Рассмотрим пример заголовка Sparse диска, созданного с базового диска размером 32 МБ.

Более детальная информация по структуре заголовка приведена в документе Virtual Disk Format 5.0.

Sparse файлы используют двухуровневую иерархию метаданных для адресации блоков с данными:
  • L0 - Granular Directory (GD)
  • L1 - Granular Table (GT)
GD идет следом за заголовком COW Header. GD состоит из ячеек Granular Directory Entry (каждая размером 4 байта). Ячейки GDE используются для хранения смещения (в 512 байтный секторах) по которому располагается таблица Granular Table. Ячейки GDE всегда располагаются последовательно. Адрес первой GDE ячейки указан в поле заголовка (gdOffset) и равен 4 секторам = 0x800 = 2048 байтам. Размер/количество ячеек GDE в Granular Directory зависит от максимально возможного размера Sparse диска, а также от размера блока данных, который может адресовать одна запись в таблице (gtcoverage).

Granual Table, на которую ссылается GDE, в свою очередь, состоит из 4096 ячеек Granular Table Entry, каждая из которых хранит смещение, по которому располагается блок данных (Grain Data). Размер блока данных, адресуемого GTE, указывается в заголовке в поле grainsize. Для Sparse дисков, создающихся гипервизором ESXi размер блока данных составляет 1 сектор (512 байт). GT создаются по мере необходимости, при первой операции записи в 2 МБ диапазон данных. Каждая GT адресует свою определенную область данных, первая GT - первые 2 МБ, вторая GT - следующие 2 МБ, и так далее, хотя технически сами GT могут размещаться в любом месте Sparse диска.

Из-за размера ячейки GDE и GTE в 4 байта (32 бита) с учетом использования 512 байт секторов можно легко посчитать максимальный размер Sparse диска = 2^32 * 512 = 2 ТБ.

Максимальное кол-во GDE, которое может быть создано внутри файла, рассчитывается по формуле:

GDE = numSectors * 512 Байт / 2 МБ

Рассмотрим пример с адресацией GDE, GTE и блоков данных внутри Sparse диска. Создадим Sparse диск и с помощью какой-нибудь низкоуровневой утилиты из гостевой ОС запишем в первый сектор диска тестовые данные - 512 байт со значением 0xff. Поскольку мы знаем, что это первый блок на диске, то его адрес будет хранится в первой GTE, в таблице GT, которая адресуется первой GDE. Для того, чтобы найти нужный блок с данными, определим адрес первой GDE по смещению gdOffset (0x800). Далее из GDE определим адрес GT (0x1000). Первая ячейка GTE указывает на расположение первого блок Sparse диска (находится по смещению 0x5000).

Учтите, что сектора, которые в базовом FLAT диске идут последовательно, не обязательно будут последовательно размещаться в Sparse файле. Адрес блока данных зависит от того, когда этот блок был выделен для записи. Таким образом, при случайной записи вполне реальна ситуация, которая изображена на картинке.

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

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

Для примера создадим Thick диск размером 2 ГБ, сделаем снапшот ВМ и перезапишем все блоки в Sparse диске:

2114560 -rw-------    1 root     root     2164269056 Oct 30 18:07 disk-000001-delta.vmdk
2097152 -rw-------    1 root     root     2147483648 Oct 30 17:43 disk-flat.vmdk

Размер Sparse диска больше на ~16 МБ за счет места, которое занимает заголовок, GDE и GTE ячейки.

Операция чтения данных для Sparse дисков выполняются следующим образом. Начиная с последнего файла в цепочке, определяется ячейка GTE, которая адресует блок данных. Если значение ячейки GTE равно 0, то это означает, что блок данных еще не перезаписывался и данные следует прочитать из родительского диска (другого Sparse диска или базового FLAT диска). В случае, если значение GTE равно 1, то вместо чтения блока данных по смещению возвращаются нули. Если же в GTE указано значение отличное от 0 или 1, значит, что по указанному смещению располагается блок, содержащий данные, которые будут прочитаны.

Что касается записи - данные всегда записываются в последний в цепочке файл. Гранулярность записи составляет 512 Байт.

В документации можно встретить упоминание, что снапшоты используют механизм Copy-on-Write (COW) для хранения данных. Это запутывает многих администраторов, которые считают, что использование отдельного файла, хранящего изменения, ближе к механизму Redirect-on-Write (ROW), чем к Copy-on-Write. Sparse диски используют COW, когда выполняют запись данных меньших, чем размер сектора. Например, вам требуется записать в сектор всего 10 изменных байт. Для обеспечения целостности данных, перед тем, как выполнить запись, должен быть инициирован целый сектор - в него будут скопированы данные из родительского диска, и только после этого могут быть записаны измененные блоки данных. Поэтому - Copy-on-Write.

На сегодня это вся информация, которой я хотел поделиться, в следующей части я расскажу о Space Efficient Sparse дисках, которые появились в vSphere 5.1.

При подготовке использовались следующие материалы:
  1. https://kb.vmware.com/s/article/1015180
  2. https://www.vmware.com/support/developer/vddk/vmdk_50_technote.pdf
  3. https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/techpaper/sesparse-vsphere55-perf-white-paper.pdf
  4. http://sanbarrow.com/vmdk-handbook.html