понедельник, 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

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

Замена сертификатов в vSphere Integrated Containers

Работа с сертификатами является важной составной частью процедуры настройки платформы для запуска контейнеров VMware vSphere Integrated Containers. Сертификаты используются в VIC для подключения администраторов к веб-консоли VIC, проверки подлинности хранилища образов Harbor, аутентификации пользователей в Virtual Container Host.

VIC Appliance и VCH могут использовать самозаверенные сертификаты, которые автоматически создаются при развертывании данных компонентов, либо импортированные сертификаты от доверенного Удостоверяющего Центра. Использование сертификатов, выданных доверенным УЦ, позволяет обеспечить больший уровень защищенности и упростить эксплуатацию платформы, избавившись от необходимости повсюду добавлять самозаверенные сертификаты в доверенные или отключать проверку подлинности. Ниже я опишу основные шаги по замене сертификатов для новой и уже существующей инфраструктуры VIC.

Выдача сертификатов

Ниже я рассмотрю пример выдачи сертификатов для VIC Appliance и для VCH на базе УЦ Microsoft Windows Server. Во-первых, требуется включить на сервере поддержку Subject Alternative Name сертификатов, т.к. обращение к компонентам VIC будет осуществляться и по DNS именам, и по IP адресам. Во-вторых, будет проще создать отдельный шаблон сертификата из типового шаблона Web Server и разрешить в нем экспорт закрытого ключа.

При запросе сертификата у УЦ, разрешите экспорт закрытого ключа (Mark key as exportable) и укажите несколько дополнительных имен в поле атрибутов (например, короткое имя и IP адрес сервера VIC), например:
SAN:dns=vic02.company.local&dns=vic02&ipaddress=192.168.1.21

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

Замена сертификатов для VIC Appliance

Замена сертификатов для VIC выполняется путем редактирования настроек vApp Options виртуального апплайнса. Для развертываемого с нуля апплайнса достаточно скопировать содержимое файлов с сертификатом, закрытым ключем и сертификатом УЦ в соответствующие поля в мастере настройке VIC при импорте шаблона.

Сертификаты сервера VIC и удостоверяющего центра должно быть сохранены в PEM формате в стандарте PKCS#12. Для закрытого ключа поддерживаются стандарты PKCS#1 и PKCS#8, при этом сам закрытый ключ не должен быть зашифрован.

Если у вас уже есть PFX файл с закрытым ключом (cert.pfx), то вы можете воспользоваться утилитой OpenSSL для конвертации и экспорта сертификатов и ключей в требуемый формат.

Для экспорта сертификата из PFX файла в PEM формат используйте команду:
openssl pkcs12 -in cert.pfx -clcerts -nokeys -out cert.pem

Для экспорта закрытого ключа используйте команду:
openssl pkcs12 -in cert.pfx  -nocerts -out enckey.pem

Затем для конвертации закрытого ключа в формат PKCS#8 используйте команду:
openssl pkcs8 -topk8 -in enckey.pem -out key.pem -nocrypt

Наконец, сохраните сертификат доверенного УЦ в формате Base64 (ca.pem).

После этого откройте файлы cert.pem, key.pem и ca.pem в любом тестовом редакторе и скопируйте содержимое файлов в соответствующие поля в форме (копируемый текст сертификатов должен начинаться с -----BEGIN CERTIFICATE----- и заканчиваться -----END CERTIFICATE-----).

Для уже развернутого VIC Appliance потребуется предварительно выключить ВМ, затем зайти в ее настройки в vSphere Web Client (Edit Settings -> vApp Options -> 1. Appliance Configuration) и скопировать содержимое сертификатов в нужные поля.

После загрузки ВМ, подключитесь к Web-интерфейсу и проверьте, что новый сертификат отображается корректно.

Замена сертификатов для Virtual Container Host

Экспорт файлов сертификата и закрытого ключа для VCH выполняется теми же командами OpenSSL, что и для VIC Appliance.

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

Заменить сертификаты для существующего VCH можно при помощи утилиты командной строки vic-machine, входящей в состав vSphere Integrated Containers Engine bundle (сам бандл можно загрузить с веб-портала VIC Appliance, подключившись по адресу https://<vic_ip>:9443).

Для замены сертификата вам потребуется определить ID виртуальной машины VCH. Сделать это можно при помощи команды:
vic-machine-windows.exe ls --target vc.vm.local -u administrator@vsphere.local --thumbprint 1B:00:FD:5D:6F:C4:1E:0A:E1:0D:4B:64:1E:D2:BC:2F:12:2C:1B:FC --compute-resource test

, где --target указывает на адрес сервера vCenter, где установлен VIC;
-u задает логин учетной записи для подключения к серверу vCenter;
--thumbprint задает отпечаток сертификата vCenter;
--compute-resource задает имя кластера, на котором установлен VCH.

Для замены сертификата используйте команду:
vic-machine-windows.exe configure --target vc.vm.local -u administrator@vsphere.local --thumbprint 1B:00:FD:5D:6F:C4:1E:0A:E1:0D:4B:64:1E:D2:BC:2F:12:2C:1B:FC --compute-resource test --id "vm-2343" --tls-server-cert cert.pem --tls-server-key key.pem --tls-cname vch03.company.local --tls-ca ca.pem

, где --tls-server-cert указывает путь к файлу сертификата;
--tls-server-key указывает путь к закрытому ключу;
--tls-cname задает FQDN имя для сервера VCH;
--tls-ca указывает путь к сертификату УЦ.

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

Это значит, что каждому Docker клиенту потребуется выдать по сертификату с закрытым ключом для доступа к VCH. Выдаваемый сертификат должен быть предназначен для аутентификации клиентов (Enhanced Key Usage: Client Authentication (1.3.6.1.5.5.7.3.2)).

Сохраните выданный сертификат на клиенте Docker (в виде файлов cert.pem и key.pem), а также сертификат УЦ (в файле ca.pem) в каталоге ~/.docker/ , либо настройте переменные окружения, указав путь к каталогу, где хранятся файлы:
export DOCKER_HOST=<IP VCH:2376>
export DOCKER_CERT_PATH=<путь к папке с cert.pem>
export DOCKER_KEY_PATH=<путь к папке с key.pem>
export DOCKER_CA_PATH=<путь к папке ca.pem>

Теперь запросы к VCH будут работать корректно.