Анонс Red Hat Satellite 6.7 Beta

11 февраля Red Hat анонсировал доступность Red Hat Satellite 6.7 Beta. Данный релиз нацелен на новые и улучшенные интеграции, а также улучшенные возможностей безопасности и управления контентом.

Red Hat Satellite – это масштабируемая платформа управления исправлениями, развертываниями и подписками инфраструктуры Red Hat вне зависимости от того, где она запущена. Satellite 6.7 Beta содержит улучшения отчётов, автоматизации и поддержки.

Несмотря на то, что Satellite 6.7 Beta поддерживает хосты Red Hat Enterprise Linux 8, Satellite 6.7 должен быть установлен на хост Red Hat Enterprise Linux 7. Возможность запуска Satellite на хостах с RHEL 8 планируется в грядущих релизах.

Основные возможности Satellite 6.7 Beta:

• Расширения автоматизации:
• Улучшенная производительность для динамической инвентаризации внутри Ansible Tower, для увеличения скорости обновлений динамической инвентаризации.
• Использование Ansible Runner внутри Satellite для лучшей длительной интеграции Ansible, что в свою очередь поддерживает актуальность Satellite с последними релизами Ansible.
• Расширения интеграции Red Hat Enterprise Linux:
• Возможность открывать и использовать веб-консоль для индивидуальных хостов с Satellite без дополнительной аутентификации.
• Расширения System Purpose для подключения назначенных систем к ключам активации в процессе развертывания. Это спроектировано для предоставления целостных возможностей настройки данных подписок на новых хостах.
• Расширения модуля Stream, содержащие возможность создавать представления контента, отфильтрованные на базе модуля, и возможность гранулировано обновлять представления контента с зависимостями.
• Расширение возможностей безопасности:
• Обновления к HTTP Proxy, разработанные для упрощения использования и обеспечения возможности настроить HTTP Proxy глобально или на базе отдельных репозиториев.
• Олицетворение пользователя, которое позволяет администратору видеть представление другого пользователя в Satellite.
• Поддержка аутентификации Common Access Cards (CAC) через Red Hat SSO для предварительного ознакомления с технологией.
• Расширения управления контентом:
• Новый шаблон отчета для создания отчётов по правам, упрощающих генерацию отчётов, используемым в Satellite.
• Возможность импортировать и экспортировать шаблоны через пользовательский интерфейс Satellite и получение обновлений по статусу импорта/экспорта.
• Поддержка загрузки RPM-пакетов с исходными кодами (файлы типа SRPM) через API или интерфейс командной строки.
• Расширения развертывания:
• Поддержка развертывания Azure, позволяющая создавать вычислительные ресурсы для Azure и разворачивать новые хосты в Azure через Satellite.
• Расширения в вычислительных ресурсах Google Compute Engine (GCE) для добавления конечных точек интерфейса разработки приложений (API) и интерфейса командной строки (CLI).
• Расширения производительности и масштабирования:
• Улучшенный помощник настройки (Tuning Assistant), который добавляет новые средние (Medium) и большие (Large) профили настройки, оптимизирует существующие профили, позволяет упростить процедуру изменения профилей настройки по мере роста окружения и содержит общие улучшения производительности.
• Улучшения производительности в задачах (Tasks), также включающие общую сводку по приостановленным задачам.
• Еще немного нового:
• Представлена опция для рандомизации порядка выполнения удаленных заданий, позволяющая сократить загрузку при выполнении большого числа заданий на большом количестве хостов.
• Улучшения удобства использования, в том числе обновления PatternFly освежившие страницу входа и редактор шаблонов.

Клиенты с активными подписками Red Hat Satellite уже могут протестировать новые возможности Satellite 6.7 Beta.

Дополнительная информация доступна на странице часто задаваемых вопросов Red Hat Satellite 6.7 Beta.

Сплаттинг переменных в Windows PowerShell 5

Вот и подошла к концу группа веб-кастов, посвященных переменным в Windows PowerShell 5. Остался заключительный аккорд – «сплаттинг» переменных.

В веб-касте представлено описание сплаттинга переменных и демонстрируется его использование для передачи позиционных параметров, а также использование хеш таблиц для передачи именованных параметров командлетам. Дополнительно, на примере запросов к серверу DNS, демонстрируется применение сплаттинга в конвейере (Pipeline).

Подробности и видео: LebedevUM.

P.S. Это заключительный веб-каст в группе, если вы не знакомы с переменными, начните свое знакомство с предыдущих веб-кастов группы:

• Переменные в Windows PowerShell 5.
• Синтаксис имен переменных в Windows PowerShell 5.
• Командлеты для работы c переменными в Windows PowerShell 5.

Все веб-касты в хронологическом порядке: Windows PowerShell 5.

Ну а следующая группа веб-кастов станет самой большой в разделе Windows PowerShell 5, она будет посвящена управлению потоком (Flow Control).

Рекомендации по проектированию VMware vSAN: Быстрые устройства хранения или быстрая сеть

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

Многие, архитектуры, построенные на базе гиперконвергентных инфраструктур, дополняют эту тайну. Что наиболее важно для производительности кластера vSAN: быстрые устройства хранения или быстрая сеть? Это популярный вопрос и хотя ответ заключается в том, что они оба важны, требуется некоторое пояснение, чтобы лучше понять, почему влияние на окружение может быть разным.

Обработка ввода/вывода (I/O Processing) в vSAN.

Одна из сильных сторон vSphere – это возможность приоритезации. Ассортимент планировщиков, встроенных в гипервизор управляет процессами на процессоре хоста, входящей и исходящей сетевой активностью и вводом/выводом хранилища. Так как планировщики – это процессы уровня ядра, они выполняют свою работу крайне эффективно.

VMware vSAN использует собственный планировщик для определения и приоритезации различных типов ввода/вывода хранилища, запущенного через стек. Это часть работы, которая делает компонент Adaptive Resync, представленный в vSAN 6.7, столь эффективным. Обратите внимание, что данные механизмы помогают приоритезировать локальные действия ввода/вывода на хосте. 

Устройства хранения (Storage Devices).

Исходная производительность устройств хранения сильно различается, даже если рассматривать только твердотельные накопители. Устройства SATA, SAS и NVMe имеют существенные отличия, выливающиеся, в итоге, в производительность, а также в целостность. Даже самые быстрые устройства NVMe, использующие NAND флеш, не являются лидерами производительности, новые технологии, такие как 3D XPoint (Intel Optane) позволяют преодолеть некоторые препятствия, связанные с NAND. Индустрия хранения развивается очень быстро, но благодаря архитектуре vSAN, новые технологии можно гранулировано встраивать, позволяя инфраструктуре ЦОД эволюционировать.

При планировании высокопроизводительного кластера vSAN, необходимо использовать быстрые устройства хранения на буферном уровне (Buffer Tier) и на уровне ёмкости (Capacity Tier). Устройства хранения – это часть финального отрезка пути данных и менее производительные устройства могут привести к невозможности соответствия необходимым ожиданиям производительности.

Сетевое взаимодействие (Networking).

Сетевые коммутаторы и интерфейсы, подключенные к ним – это то, что связывает все компоненты воедино. Сетевое взаимодействие играет особенно важную роль в гиперконвергентной инфраструктуре (HCI), так как действия ввода/вывода могут быть расширены за пределы локального хоста. К сожалению, промышленная практика ссылки на спецификацию коммутатора просто по максимальной скорости порта отменяет все важные подробности коммутационного оборудования. Возможности коммутационного оборудования зависят от многих факторов, таких как: пропускная способность соединительной платы, доступный объем буферизации портов на коммутаторе, а также являются ли платы ASIC достаточно мощными для соответствия требованиям обработки пактов в окружении. Эти факторы зачастую и являются причинами недостаточной производительности. John Nicholson выпустил отличную серию статей на эту тему и, совместно с Broc Yanda, презентовал сессию на VMworld.

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

Как они опираются друг на друга.

Планировщики на базе хоста, такие как vSAN, приоритезируют ввод/вывод по мере его генерации хостом или поступления на аппаратный стек хоста. Они не поддерживают сеть и не предполагают, что другие пакеты могут ожидать отправки на хост. Но неправильно подобранные коммутаторы, не справляющиеся с нагрузкой, могут привести к падению производительности. Если сеть испытывает перегрузки какой угодно формы (пропускная способность, обработка или буферизация), это может стать аспектом правил TCP. По мере увеличения частоты сброса пакетов увеличивается количество повторных передач. Не смотря на надёжность TCP, шаги обработки при перенасыщении становятся дорогостоящими для пиковой производительности и целостности. Хуже всего то, что перенасыщение оказывает влияние на все системы, подключенные к коммутаторам.

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

Например, если клиент использует скромные коммутаторы 10 Gb и рассматривает 25/100 Gb – это решение приходит не от уровня утилизации коммутаторов, а с целью исключить узкое место на уровне коммутаторов, не позволяющее узлам использовать свой потенциал по максимуму. Вместе с увеличением производительности хостов, необходимо увеличивать и производительность сети.

Итоги.

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

Настройка виртуальных хостов Apache в CentOS 8

Очередной веб-каст на тему Apache HTTP Server в CentOS 8. На этот раз в центре внимания виртуальный хостинг.

В веб-касте представлено описание принципов работы виртуального хостинга веб-серверов и демонстрируется настройка виртуальных хостов Apache на базе заголовка хоста (Host Header), TCP-порта и IP-адреса. Отдельное внимание в веб-касте уделено настройке операционной системы и веб-сервера для обеспечения виртуального хостинга всем необходимым.

Подробности и видео: LebedevUM.

P.S. Это третий веб-каст в группе, поэтому если вы не знакомы с веб-сервера Apache, рекомендую начать свое знакомство с предыдущих веб-кастов группы:

• Установка и настройка Apache в CentOS 8.
• Управление модулями Apache в CentOS 8.

Следующий веб-каст станет заключительным в группе, в нем речь пойдет о настройке шифрования веб-трафика Apache HTTP Server.

Посмотреть эту публикацию в Instagram

Публикация от Yuriy Lebedev (@lebedevum) 21 Фев 2020 в 4:37 PST

Производительность и безопасность приложений, доставляемых в современное рабочее пространство

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

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

Решение – это единая прикладная сетевая платформа, от центра обработки данных до периметра WAN, а также сквозь облако или облака. Платформа должна размещаться в решении, обладать успешным опытом работы, гарантированным масштабированием и проверенной интеграцией для видимости и аналитики. Сетевые решения Citrix могут помочь доставлять приложения с необходимой производительностью и безопасностью.

Производительность.

Технологии доставки приложений, такие как балансировка нагрузки (Load Balancing), разгрузка SSL, WAN, SaaS и веб-оптимизация формируют основу для производительности. Эти технологии должны работать вместе, чтобы позволить службе ИТ доставлять потрясающие возможности пользователям вне зависимости от их расположения в локальном, облачном или гибридном окружении. Интеграция этих распределенных технологий – это то, что делает сетевые решения Citrix особенными, обеспечивая потрясающие возможности и видимость для ИТ этих возможностей.

Рассмотрим для примера компанию, которая начала перенос своего портфолио приложений и рабочих нагрузок в сервисы SaaS, а также в решения с облачным размещением. Чтобы получить лучшую производительность и сократить затраты, она примеряет решение Citrix SD-WAN, которое предоставляет оптимизированную производительность на более чем 4000 приложений SaaS, а также новых решениях компании с облачным размещением и ее локальным центром обработки данных (ЦОД).

Компания оптимизирует производительность не только при помощи качества обслуживания (QoS) на уровне пакетов, но также сокращает затраты, используя менее скоростное подключение к сети интернет для обеспечения производительности.

Компания может извлечь выгоду на другой части интегрированного решения Citrix, развернув Citrix ADC для балансировки рабочих нагрузок. Это подойдет как для традиционного подхода к приложениям, так и для новых облачных (Cloud-native) подходов, использующих Kubernetes и контейнеры. Развертывание Citrix ADC в объединении с Citrix Intelligent Traffic Management позволяет выбрать точки лучшей производительности серверов или сервисов для доставки приложений и обеспечения высококачественных возможностей. Данным сервисом вполне может быть Citrix Workspace в дополнение к прочим веб к традиционным приложениям.

Безопасность.

Необходимо защищать критические активы на удаленных площадках, также как пользователей и важные для них приложения. Интегрированные решения безопасности для Citrix SD-WAN уже встроены в продукт, как например полноценный межсетевой экран.

Расширенная безопасность при помощи Palo Alto и ZScaler добавляет интеграцию к, возможно, уже имеющейся инфраструктуре. Citrix ADC предоставляет безопасность для доставляемых приложений начиная с фундаментального межсетевого экрана веб-приложений (Web App Firewall, WAF). Но присутствуют и новые векторы безопасности, которые оказывают влияние на центр приложений среди ботов и растущее доверие к API. Разрушение сервисов через ботов – это возрастающая проблема информационной безопасности. Управление ботами (Bot Management) Citrix защищает приложения, не оказывая влияния на производительность.

При помощи Gateway API в Citrix ADC, можно получить необходимую защиту для существующих приложений, а также приложений следующего поколения. API между системами и между приложениями являются механизмом по умолчанию для предоставления в общий доступ информации и увеличения надежности и производительности приложений. Защита этих доступов также важна как обеспечение безопасности доступов из сети интернет и от конечных пользователей.

Видимость производительности и безопасности.

Все точки интеграции в рамках портфолио Citrix передают отчёты в центральное решение управления и аналитики, предоставляя видимость одновременно для производительности и безопасности. При помощи Citrix Application and Delivery Management (ADM) можно обеспечить производительность и безопасность пользователей и клиентов, а также соответствие бизнес требованиям. Citrix ADM – это центральная система, которая является единой точкой для всех задач управления и требований к отображению, предоставляющая подробности обнаруженных ошибок и возможности их устранения.

По ссылке можно больше узнать о сетевых решениях Citrix и их возможностях обеспечения производительности и безопасности в соответствии с требованиями цифровой трансформации (Digital Transformation).

Командлеты для работы c переменными в Windows PowerShell 5

Пришло время продолжить изучение переменных в Windows PowerShell.

В веб-касте описываются и демонстрируются командлеты для работы с переменными: New-Variable, Set-Variable, Get-Variable, Clear-Variable и Remove-Variable. Основной упор в веб-касте сделан на преимущества использования командлетов. В частности, рассматриваются способы автоматизации управления переменными, просмотр свойств и методов объекта PSVariable и использование ссылочного типа (Reference Type).

Подробности и видео: LebedevUM.

P.S. Это третий веб-каст в группе, поэтому если вы не знакомы с переменными в Windows PowerShell, начните свое знакомство с предыдущих веб-кастов группы:

• Переменные в Windows PowerShell 5.
• Синтаксис имен переменных в Windows PowerShell 5.

Все веб-касты в хронологическом порядке: Windows PowerShell 5.

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

Посмотреть эту публикацию в Instagram

Публикация от Yuriy Lebedev (@lebedevum) 19 Янв 2020 в 1:28 PST

Возможности на базе Hyper-V

Hyper-V – это технология аппаратной виртуализации Microsoft, впервые вышедшая в 2008-ом году для обеспечения серверной виртуализации и ставшая основой множества продуктов и компонентов Microsoft. Диапазон возможностей простирается от повышения безопасности до расширения возможностей разработчиков и обеспечения наиболее совместимой игровой консоли. Последние добавления в этот список включают песочницу Windows (Windows Sandbox), Windows Defender Application Guard, System Guard и расширенное обнаружение угроз (Advanced Thread Detection), изолированные контейнеры Hyper-V (Hyper-V Isolated Containers), платформу гипервизора Windows (WHP), подсистему Windows для Linux 2 (WSL 2). Дополнительно, приложения, использующие Hyper -V: Kubernetes для Windows и Docker Desktop.

Так как область виртуализации Windows расширяется, становясь интегрированной частью операционной системы, многие новые возможности операционной системы зависят от Hyper-V. Соответственно, это создает ошибки совместимости со множеством популярным сторонних продуктов, которые предоставляют собственные решения виртуализации, заставляя пользователей выбирать между приложениями и потерей функциональности операционной системы. В связи с этим Microsoft объединился с ключевыми производителями программного обеспечения, такими как VMware, VirtualBox и BlueStacks для предоставления решений, которые напрямую используют технологии виртуализации Microsoft, устраняя необходимость выбора.

Песочница Windows (Windows Sandbox).

Песочница Windows (Windows Sandbox) – это изолированное, временное окружение рабочего стола, в котором можно запускать программное обеспечение без страха оказать негативное влияние на персональный компьютер. Любое программное обеспечение, установленное в песочнице Windows, остается только в песочнице и не может повлиять на хост. После закрытия песочницы Windows все состояние, включая файлы, изменения реестра и установленное программное обеспечение мгновенно удаляются. Песочница Windows построена на тех же технологиях, которые разрабатывались для работы мульти-арендных сервисов Azure, таких как Azure Functions, а также предоставляет интеграцию с Windows 10 и поддержку для графических приложений.

Windows Defender Application Guard.

Windows Defender Application Guard (WDAG) – это возможность безопасности Windows 10, представленная в Fall Creators Update (версии 1709), которые защищают от нацеленных угроз при помощи технологий виртуализации Hyper-V. Также WDAG обеспечивает корпоративным пользователям Microsoft Edge и Internet Explorer (IE) защиту от уязвимостей ядра (Zero-day) за счет изоляции не доверенных сессий браузера от операционной системы хоста. Это позволяет команде информационной безопасности при помощи WDAG заблокировать корпоративные хосты, при этом, разрешив корпоративным пользователям просматривать в браузере некорпоративный контент.

Application Guard изолирует не доверенные сайты при помощи нового экземпляра Windows на аппаратном уровне.

Windows Defender System Guard.

Для защиты критических ресурсов, таких как стек аутентификации Windows, ключи единого входа (Single Sign-On), биометрический стек Windows Hello и Virtual Trusted Platform Module (Virtual TPM), а также системной прошивки (Firmware) и оборудование – они должны быть доверенными. Windows Defender System Guard реорганизует существующие возможности целостности системы Windows 10 и поверх них настраивает набор вложений в безопасность Windows. Это спроектировано и разработано для обеспечения следующих гарантий безопасности:

• Защита и поддержка целостности системы во время ее запуска.
• Проверка целостности системы, полностью поддерживающую локальную и удаленную проверку.

Windows Defender Advanced Threat Detection.

Обнаружение и остановка атак, которые вмешиваются через агентов в режиме ядра на уровне гипервизора – это критический компонент универсальной платформы защиты конечных устройств в Microsoft Defender Advanced Thread Protection (ATP). Глубокая интеграция Windows Defender Antivirus с аппаратными возможностями изоляции позволяют обнаруживать признаки подобных атак.

Изолированные Hyper-V контейнеры (Hyper-V Isolated Containers).

Hyper -V играет важную роль в возможностях контейнерной разработки на Windows 10. Контейнеры Windows требуют плотной связи между версией операционной системы контейнера и хоста, на котором они запущены. Hyper-V используется для инкапсуляции контейнеров на Windows 10 внутрь прозрачной, легковесной виртуальной машины. В разговорной речи данную возможность называют «Hyper-V Isolated Containers». Эти контейнеры запускаются в виртуальной машине, которая специально оптимизирована для быстродействия и эффективности использования ресурсов хоста. Изолированные Hyper-V контейнеры позволяют разработчикам вести разработку на множестве дистрибутивов Linux и Windows одновременно, а также управлять контейнерами при помощи привычных инструментов (таких как Docker).

Платформа гипервизора Windows (Windows Hypervisor Platform).

Платформа гипервизора Windows (WHP) добавляет расширенный интерфейс разработки приложений (API) пользовательского режима для сторонних стеков виртуализации и приложений, что позволяет создавать и управлять разделами на уровне гипервизора, настраивать привязку памяти для раздела, а также создавать и управлять работой виртуальных процессоров. Основное назначение – это сосуществование стороннего программного обеспечения (такого как VMware) с Hyper-V и прочими возможностями на базе Hyper-V. Безопасность на базе виртуализации (Virtualization-Based Security, VBS) – это одна из последних технологий, которая возможна благодаря этому сосуществованию.

WHP предоставляет API, похожий на платформу (Framework), которую предоставляет KVM на Linux и гипервизор macOS, и на данный момент опирается на QEMU и VMware.

Подсистема Windows для Linux 2 (Windows Subsystem for Linux 2).

Подсистема Windows для Linux 2 (WSL 2) – это новейшая версия архитектуры, которая позволяет подсистеме Windows для Linux запускать исполняемые файлы ELF64 на Windows. Это обновление возможностей включает в себя увеличенную производительность файловой системы, а также полную совместимость системных вызовов. Новые архитектурные изменения влияют на то, как исполняемые файлы взаимодействуют с Windows и аппаратным обеспечением компьютера, но предоставляют те же пользовательские возможности, что и WSL 1 (на данный момент широко распространенная версия). Основное отличие архитектуры WSL 2 заключается в настоящем ядре Linux, запущенном внутри виртуальной машины. Независимые дистрибутивы Linux могут быть запущены как в WSL 1, так и в WSL 2, могут быть обновлены (Upgrade) или понижены (Downgrade) в любое время, а также запущены в WSL 1 и WSL 2 одновременно.

Поддержка Kubernetes для Windows.

Kubernetes начал официально поддерживать Windows Server в производственной среде, начиная с релиза Kubernetes версии 1.14 (в марте 2019 года). Приложения на базе Windows составляют большую часть рабочих нагрузок во множестве организаций. Контейнеры Windows предоставляют современный путь для приложений Windows чтобы использовать процессы DevOps и изначально облачные подходы. По факту Kubernetes стал стандартом для управления контейнерами; данная поддержка позволяет широкой экосистеме приложений Windows не только использовать возможности Kubernetes, но и широкую, бесшовную и постоянно растущую экосистемы вокруг него. Организации, вкладывающие одновременно в приложения на базе Windows и Linux, больше не нуждаются в отдельных оркестраторах для управления рабочими нагрузками, что в результате приводит к увеличению операционной эффективности развертываний. Разработка, обеспечившая данный релиз опиралась на открытый исходный код и лучшие подходы сообщества, которые и добавили контейнеры Windows Server в Windows Server 2016.

Данные компоненты и инструменты позволяют технологии Microsoft Hyper-V представлять новые пути обеспечения пользовательских возможностей. Песочница Windows (Windows Sandbox), Windows Defender Application Guard, System Guard и Advanced Thread Detection, изолированные Hyper-V контейнеры (Hyper-V Isolated-Containers), Windows Hypervisor Platform (WHP) и подсистема Windows для Linux (WSL 2) – это все новые компоненты Hyper-V, которые обеспечивают гибкость и безопасность Windows. Управление приложениями с использованием Hyper-V, такое как Kubernetes для Windows и Docker Desktop также показывает приверженность Microsoft к потребностям клиентов.

P.S. Тем, кто не знаком с возможностями Hyper-V, я рекомендую начать свое знакомство со статьи «Архитектура Hyper-V» и группы веб-кастов посвященной Hyper-V в Windows 10:

• Установка и управление Hyper-V в Windows 10
• Создание виртуальных машин Hyper-V в Windows 10
• Импорт и экспорт виртуальных машин Hyper-V в Windows 10
• Базовое управление Hyper-V через Windows PowerShell в Windows 10
• Продвинутое управление Hyper-V через Windows PowerShell в Windows 10
• Вложенная виртуализация Hyper-V в Windows 10

Управление модулями Apache в CentOS 8

Не откладывая в долгий ящик продолжаем наше знакомство с Apache HTTP Server в CentOS 8.

Данный веб-каст описывает модули (Modules) веб-сервера Apache, рассказывает о конфигурационных файлах, применении модулей и расположениях по умолчанию. Центральное место в веб-касте занимают демонстрации установки и применения модуля mod_php для обеспечения возможности использования языка PHP веб-сайтом и модуля mod_wsgi, который обеспечивает связь между веб-сервером и приложением, написанным на языке Python. Дополнительно в веб-касте затрагивается вопрос компиляции модулей из исходных кодов при помощи Apache Extension (apxs).

Подробности и видео: LebedevUM.

P.S. Это уже второй веб-каст в группе, поэтому если вы не знакомы с Apache HTTP Server, начните свое знакомство с веб-каста «Установка и настройка Apache в CentOS 8».

Следующий веб-каст будет посвящен виртуальному хостингу на базе веб-сервера Apache.

View this post on Instagram

A post shared by Yuriy Lebedev (@lebedevum) on Feb 3, 2020 at 11:29pm PST

Citrix App Layering и контейнеры профилей Microsoft FSLogix

Rob Zylowski (Citrix Consulting Enterprise Architect), будучи экспертом Citrix App Layering, подeлился своим видением относительно оптимизации Windows и приложений Windows в решениях Citrix Virtual Apps and Desktops. Я же, в свою очередь, адаптирую его видение выработки правильных решений на стыке технологий Microsoft и Citrix.

Ключом к построению наилучшего решения, является хорошее понимание всех доступных инструментов, что позволяет подбирать наилучший вариант в каждой конкретной ситуации. Так же важно понимать, что Microsoft FSLogix часто используется совместно с Citrix App Layering, так как эти инструменты решают разные задачи. Далее будут рассмотрены различия между App Layering и FSLogix, чтобы разобрать ситуации, когда один инструмент предпочтительнее другого, а в каких случаях их необходимо использовать совместно.

Различия FSLogix и App Layering.

Многие полагают, что Microsoft FSLogix и Citrix App Layering полностью идентичные технологии. Из-за того, что в App Layering есть уровень или технология на базе контейнера, которая позволяет пользователям хранить изменения машин VDI без сохранения состояния (Non-persistent VDI) при помощи доступного для записи файла VHD, сохраненного на общем сетевом ресурсе. А FSLogix предоставляет похожую технологию, с собственным решением на базе контейнера для хранения профиля пользователя Windows или файлов, связанных с Office (подобно тем, которые используют Outlook и OneDrive), также при помощи файлов VHD/VHDX в общем сетевом расположении.

Однако, пользовательские уровни (User Layer) App Layering на самом деле предназначены для предоставления практически полного сохранения состояния для платформы VDI без сохранения состояния (Non-persistent). Пользовательский уровень (User Layer) может быть использован для параметров приложений, сохраненных в профиле пользователя, а также для установленных пользователем приложений и сохраненных пользователем файлов где-либо на системе. FSLogix имеет две технологии на базе контейнеров – одна из которых охватывает весь профиль пользователя (Profile Container) и вторая, содержащая часть профиля пользователя имеющую отношение к Microsoft Office и поддерживающим его технологиям, таким как OneDrive (Office Container). Таким образом области применения продуктов существенно отличаются: FSLogix нацелен на профиль или часть профиля пользователя, а пользовательские уровни (User Layer) App Layering охватывают все операции записи на рабочей станции.

Это архитектурное отличие обозначает, что FSLogix и пользовательские уровни (User Layer) соответствуют двум различным наборам клиентских потребностей. Если необходимо решить проблемы, связанные с профилем или запуском Office в окружении VDI без сохранения состояния (Non-persistent) или в окружении служб удаленного рабочего стола (RDS) в таком случае лучше всего подойдут FSLogix или управление профилем Citrix (Citrix Profile Management, начиная с версии 7.18), которые имеют подобные возможности. Если необходимо предоставить пользователю возможности сохранения состояния (Persistent) поверх окружения VDI без сохранения состояния (Non-persistence), что может включать Outlook, OneDrive, индексирование поиска (Search Indexing) и так далее, то в таком случае пользовательские уровни (User Layer) App Layering могут стать правильным решением.

Разумеется, возможности App Layering гораздо шире, чем просто предоставление пользовательского уровня (User Layer). App Layering предоставляет платформу для управления комплексными наборами приложений и образов в окружениях с разными гипервизорами и облаках, в том числе управление облаками и динамическую доставку приложений.

В результате FSLogix прекрасно подходит для управления профилями пользователей и Outlook, а Citrix App Layering – для управления образами и приложениями.

Интеграция Citrix App Layering и Microsoft FSLogix.

На самом деле установка и использование FSLogix довольно проста. Установка состоит из загрузки и развертывания маленького установщика драйверов фильтрации, которые использует FSLogix. Затем используется набор объектов групповой политики (Group Policy), которые разворачиваются за счет вложенного файла ADMX. Для совместного использования с Citrix App Layering, FSLogix может быть установлен в уровень платформы (Platform Layer) или приложения (Application Layer). Если необходимо использовать образы настольной системы (Desktop Image), как с FSLogix, так и без, то рекомендуется использовать уровень приложений (Application Layer).

После запуска машины упаковки (Packaging Machine) уровня приложений (Application Layer), первый шаг установки – это скопировать FSLogixAppSetup.exe и запустить его от имени администратора (Run As Administrator). Следующий шаг очень важен: драйвер фильтрации (Filter Driver) использует концепцию высоты (Altitude), которая определяет порядок, в котором драйвер фильтрации одного типа будет предоставлять доступ к вызовам файловой системы от операционной системы. Производители драйверов фильтрации файловой системы запрашивают назначение высоты у Microsoft, которая управляет этим и назначает высоты. По умолчанию, высоты Citrix App Layering и Microsoft FSLogix не позволяют продуктам корректно работать совместно. Чтобы использовать FSLogix с Citrix App Layering, высота драйвера FSLogix (frxdrvvt) должна быть изменена при помощи следующей правки в реестре:

Отредактировать ключ HKLM\System\CurrentControlSet\Services\frxdrvvt\Instances\frxdrvvt\Altitude установив значение 138010.

Micah Adamson рекомендует использовать это значение высоты (138010) в его посте в msdn. После внесения изменения в реестр, необходимо перезагрузить машину упаковки (Packaging Machine), затем финализировать уровень.

FSLogix создает 4 локальные группы, которые используются для управления тем, какие пользователи FSLogix будут применяться в процессе установки:

• FSLogix Profile Include List.
• FSLogix Profile Exclude List.
• FSLogix ODFC Include List.
• FSLogix ODFC Exclude List.

Если используется Citrix App Layering, то единственный уровень, на котором можно добавить локальные группы – это уровень операционной системы (OS Layer). Это связано с тем, что база данных SAM зашифрована в Windows, и нет возможности собрать ее из разных уровней. Это значит, что даже добавленные при установке FSLogix группы в машину упаковки (Packaging Machine) при создании уровня приложений (Application Layer) останутся только в машине упаковки. Лучший способ решить данную задачу – это создать эти группы и настроить их членство при помощи предпочтений групповой политики (Group Policy Preferences) в доменных службах Active Directory (AD DS). Аналогичный способ используется для обработки членства в группах во время установки VDA в уровень платформы.

В соответствующем объекте групповой политики (GPO) добавьте предпочтение групповой политики в Конфигурация компьютера (Computer Configuration) → Предпочтения (Preferences) → Параметры панели управления (Control Panel Settings) → Локальные пользователи и группы (Local Users and Groups) и добавить группу с именем «FSLogix Profile Include List». Затем добавить в список ее членов необходимую доменную группу.

В группу исключения (FSLogix Profile Include List) необходимо добавить административные учетные записи и локального администратора. Это гарантирует, что при входе под административной учётной записью FSLogix не будет создавать контейнер для профиля, что в последствии может вызвать проблемы при управлении образом.

После публикации образа, который включает уровень FSLogx и развертывания файлов ADMX с корректной конфигурацией, VDA автоматически подключается к контейнеру профиля FSLogix, что позволяет настроить Outlook OST.

Чтобы увидеть список перенаправленного можно воспользоваться командной FSLogix: frx.exe list-redirects.

Последний вопрос – как много времени данные технологии добавляют к процессу входа в систему. Rob Zylowski провел эксперимент с одним и тем же образом опубликованным в трех конфигурациях:

• Совсем без управления профилями.
• С FSLogix и без пользовательских (User Layer) и эластичных уровней (Elastic Layer).
• С пользовательским уровнем (User Layer), без эластичных уровней (Elastic Layer) и без FSLogix.

Пять входов с расчетом среднего времени входа от нажатия иконки в интерфейсе StoreFront до отрисовки иконки файлового менеджера в панели задач показали незначительное преимущество FSLogix над пользовательским уровнем (User Layer). С небольшим отставанием от них показал себя полный вход в систему Windows без управления профилем.

Заключительные рекомендации.

1. Используйте FSLogix для решения проблем, связанных с перемещающимся профилем на VDI без сохранения состояния (Non-persistent).
2. Используйте пользовательские уровни (User Layers), если необходимо предоставить возможности сохраненного состояния (Persistent Experience) пользователю на VDI без сохранения состояния (Non-persistent).
3. При совместном использовании FSLogix и App Layering, необходимо устанавливать FSLogix в уровень приложений (Application Layer).
4. При совместном использовании FSLogix и App Layering, необходимо изменить высоту (Altitude) у драйвера фильтрации FSLogix.
5. При совместном использовании FSLogix и App Layering, необходимо использовать предпочтения групповой политики (GPP) для создания локальных групп FSLogix.

Хотелось бы выразить благодарность Rob Zylowski за предоставленный передовой опыт (Best Practices), надеюсь, он окажется полезным для вас. Возможно, в последствии, мы вернемся к теме совместного использования App Layering и FSLogix в части интеграции маскировки приложений (App Masking).

P.S. Если вы не знакомы с Microsoft FSLogix, то начать свое знакомство можно с моей статьи «Решения Microsoft FSLogix», также я уже ранее писал об интеграции FSLogix и App Layering: «Применение возможностей платформы FSLogix в виртуальном окружении Citrix».