Релиз Citrix Hypervisor 8.0

Как верно подметил Mikael Lindholm, существует большая разница в произношении “Xen”, корректно произносить «зен», нежели «ксен», тем не менее начиная с релиза «8.0», такой вопрос больше не стоит, так как XenServer теперь окончательно переименован в Citrix Hypervisor.

На самом деле в новом релизе гораздо больше всего интересного, чем просто смена имени. Вместе с новой мажорной версией, Citrix адаптировал новое ядро Linux (4.x), которое ляжет в основу для будущих инноваций. Новая платформа открывает дверь для новых возможностей обеспечения лучшего гипервизора для Citrix Virtual Apps and Desktops, а также экономически эффективного и высоко производительного гипервизора для рабочих нагрузок общего назначения.

Улучшения для Citrix Virtual Apps and Desktops.

Независимо от того развернут Citrix Hypervisor только локально или является частью гибридного облака совместно с Citrix Cloud, десятки из тысяч клиентов Citrix Virtual Apps and Desktops выбирают Citrix Hypervisor, чтобы сделать свои развертывания настолько лучшими, насколько это возможно.

Как правило это связано с тем, что клиенты нуждаются в лучшем решении для запуска HDX 3D Pro; для экономии на инфраструктуре при помощи таких компонентов как MCS и PVS Accelerator; для улучшения пользовательских возможностей за счет поддержки Windows Continuum или для минимизации количества вендоров в стеке решения.

Как уже сообщалось ранее Citrix Hypervisor бесплатно входит в состав всех редакций и предложений сервиса Citrix Virtual Apps and Desktops.

Citrix Hypervisor 8.0 продолжает улучшать стек. Все клиенты Citrix, использующие возможности vGPU оценят возможность использования моментальных снимков на виртуальных машинах с vGPU. Также все заинтересованные в развертывании новой операционной системы Windows Server, как части стека решения теперь имеют такую возможность вместе с поддержкой виртуальных машин Windows Server 2019.

Полная поддержка виртуальных машин с Windows Server 2019 также будет добавлена в релиз с длительной поддержкой (LTSR) 7.1 CU2. Те, кто использует агент управления (Management Agent) или центр обновления Windows (Windows Update) автоматически обновят драйверы ввода/вывода, остальные получат поддержку через исправления (Hotfix) которые скоро выйдут.

Улучшения для рабочих нагрузок общего назначения.

Несмотря на то, что основной фокус разработки гипервизора направлен на улучшение развертывания Citrix Virtual Apps and Desktops, Citrix не забывает о своих клиентах, которые используют Citrix Hypervisor в качестве основы для высоко-производительных вычислений (HPC), облачной инфраструктуры или экономически эффективного базового гипервизора инфраструктуры.

Для них Citrix добавил поддержку дисков размером больше 2 терабайт и предоставил обновленный список поддерживаемых гостевых операционных систем Linux, в том числе SUSE Linux Enterprise Server и Desktop 15, а также CentOS и Red Hat Enterprise Linux 7.6. Полный список поддерживаемых гостевых операционных систем доступен на странице документации.

Также Citrix предоставил экспериментальную поддержку загрузки UEFI для виртуальных машин с Windows, которая может существенно улучшить время загрузки виртуальных машин.

Обновление до Citrix Hypervisor 8.0.

Так как это новый мажорный релиз, перед обновлением необходимо убедиться, что имеющееся оборудование поддерживается и изучить инструкции по обновлению пула Citrix XenServer до Citrix Hypervisor на странице документации.

Для клиентов, использующих трек текущих релизов (Current Release), поддерживается обновление с Citrix XenServer 7.5 и 7.6. Также предоставлена возможность обновления релиза с длительной поддержкой (LTSR), но учтите, что это переключит развертывание с LTSR на трек текущих релизов (CR).

Попробовать прямо сейчас.

Если у вас нет Citrix Hypervisor, но вы являетесь клиентом Citrix Virtual Apps and Desktops, программное обеспечение доступно для загрузки на странице загрузок Citrix. Также вам не потребуются дополнительные лицензии, достаточно просто указать на сервер лицензий Citrix Virtual Apps and Desktops.

Для тех, кто хочет попробовать Citrix Hypervisor, можно получить бесплатную пробную версию на 90 дней и 12 сокетов на странице продукта Citrix Hypervisor.

P.S. Я уже записал один веб-каст и в будущем планирую сделать еще несколько на темы которые не демонстрировал ранее.

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

Ну и, возможно, вас заинтересуют мои веб-касты по предыдущим версиям продукта:

• Citrix XenServer 6
• Citrix XenServer 7

Перевод механизма обработки трафика на инфраструктуру расширенных политик (Advanced Policy) в Citrix ADC

Инфраструктура политик Citrix ADC управляет трафиком в рамках устройства. Политики используют логические выражения для оценки запросов (Request) или ответов (Response) и на базе результатов проверки применяют одно или несколько действий.

В Citrix ADC можно использовать инфраструктуры как классических (Classic), так и расширенных (Advanced) политик. Инфраструктура расширенных политик (Advanced Policy) использует выражения, которые похожи на классические политики (Classic Policy), но способны анализировать комплексные данные и поддерживают настройку большего числа операций в выражениях. Например, они могут трансформировать данные в теле запроса в HTTP-запрос.

Расширенные политики (Advanced Policy) обладают большими возможностями, чем классические политики (Classic Policy) и требуются для использования новейших возможностей Citrix ADC. Citrix перевел классические политики (Classic Policy) в категорию устаревших (Deprecated), и если ваше устройство до сих пор использует классические политики (Classic Policy), то сейчас самое подходящее время для перехода на расширенные (Advanced).

Рассмотрим преимущества расширенных политик и причины перехода.

Причины перехода на расширенные политики (Advanced Policies).

Большинство компонентов Citrix ADC генерирует комплексные данные, которые необходимо проверять, что, в свою очередь, делает расширенные политики предпочтительными. Некоторые возможности инфраструктуры расширенных политик (Advanced Policy):

• Гранулированный анализ трафика на уровнях со 2 по 7-ой.
• Проверка любой части заголовка или тела как запроса, так и ответа HTTTP или HTTPS.
• Привязка политики к нескольким точкам привязки, которые поддерживает инфраструктура расширенных политик (Advanced Policy) по умолчанию; переопределение и привязка на уровне виртуальных серверов.
• Выражение «goto» для передачи управления другим политикам и точкам привязки, определяемым результирующим выражением проверки.
• Специальные инструменты, такие как наборы шаблонов (Pattern Sets), заголовки политик (Policy Labels), идентификаторы ограничения скорости (Rate Limit Identifiers), вызовы HTTP (HTTP Callouts), которые позволяют эффективно настраивать политики для комплексной проверки данных.

Создавать и управлять расширенными политиками и выражениями можно при помощи графического пользовательского интерфейса Citrix ADC. Графический интерфейс также обеспечивает, возможность проверки политик, которую можно использовать для оценки расширенных политик (Advanced Policy) и тестирования их поведения перед вводом в эксплуатацию, что позволит избежать ошибок настройки.

Рассмотрим компонент ICAP, который выполняет проверку контента в Citrix ADC. Этот компонент получает запросы HTTP, прерывает трафик и использует политики проверки содержимого (Content Inspection Policy) для оценки необходимости обработки запроса HTTP при помощи ICAP. Если это так, устройство расшифровывает и отправляет сообщение в виде плоского текста на серверы ICAP. При помощи службы трансформации контента (Content Transformation Service) на серверах ICAP запрос обрабатывает и отправляет его обратно на устройство. Устройство должно использовать расширенные политики (Advanced Policy), так как классические политики (Classic Policy) не могут выполнять комплексные операции, такие как: балансировка нагрузки (Load Balancing), преобразование контента (Content Transformation) и встроенное кэширование (Integrated Caching).

Пример:

add ContentInspection policy ci_pol_HTTP –rule HTTP.REQ.URL.CONTAINS(“html”) –action ci_act_svc

Некоторые динамические возможности позволяют использовать выражения расширенных политик (Advanced Policy) вместо классических (Classic Policy). Для этого необходимо обновить Citrix ADC до 12.0 build 56.20 и переключиться на инфраструктуру расширенных политик (Advanced Policy).

Переход на расширенные политики (Advanced Policies).

Рассмотрим вопрос миграции существующих классических политик (Classic Policy), особенно в сценариях с большим количеством (десятки и сотни), на расширенные политики (Advanced Policy).

Можно мигрировать существующие классические политики (Classic Policy) как вручную, так и при помощи инструмента nspepi, который может автоматически конвертировать классические политики (Classic Policy) и их выражения (команды, выражения и настройки) на инфраструктуру расширенных политик (Advanced Policy).

Для получения дополнительной информации об утилите nspepi и ее процессе конвертации обратитесь к разделу документации «Conversation using nspepi». Для получения информации о классических политиках, которые выводятся из эксплуатации (Deprecated) и альтернативных, не устаревших компонентах, обратитесь к странице «Deprecated Features and Functions».

Пример ручной конвертации в расширенные политики (Advanced Policy).

Классическая политика (Classic Policy):

add filter policy f_pol1 -rule “REQ.HTTP.URL == /test” -reqAction RESET

Расширенная политика (Advanced Policy):

add responder policy f_pol1 “HTTP.REQ.URL.EQ(\”/test\”)” RESET

При помощи ручной конвертации, можно менять классические политики (Classic Policy) на расширенные (Advanced Policy) в конфигурационном файле устройства, но это может быть достаточно утомительно в случае с множеством политик. Чтобы избежать этого, можно использовать инструмент nspepi для конвертации всего файла.

Следующие шаги.

Citrix разрабатывает инфраструктуру политик Citrix ADC с быстро настраиваемыми политиками таким образом, чтобы уровень базовых политик и выражений оставался простым и при этом динамическим. Некоторые новые компоненты требуют от устройства Citrix ADC поддержки состояния и запоминания ключей (Tokens) для интеллектуального принятия решений в рамках жизненного цикла сессий. Выражения расширенных политик (Advanced Policy) помогают добиться этого и предоставляют операционные возможности.

Чтобы лучше изучить инфраструктуру расширенных политик (Advanced Policy) и переход с классических политик (Classic Policy) в частном случае – обратитесь к документации или приходите ко мне на курсы: SoftLine Education.

Числа в Windows PowerShell 5

Возвращаемся к типам данных в Windows PowerShell и на очереди у нас – числа. В отличии от предыдущего веб-каста, в котором мы говорили про строки, а точнее про один единственный тип данных – System.String, на этот раз у нас целая батарея числовых типов, состоящая из: System.Int32, System.Int64, System.Double, System.Single (float), System.Decimal и прочих.

В веб-касте вы найдете описание особенностей и демонстрацию способов задания числовых типов данных в Windows PowerShell, отдельно разбирается автоматический выбор типа данных при использовании чисел в Windows PowerShell. Дополнительно в веб-касте вы найдете информацию об использовании умножающих суффиксов (KB, MB, GB, TB и PB) и применении шестнадцатеричных литералов в числовых типах данных.

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

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

• Типы данных в Windows PowerShell 5
• Строки в Windows PowerShell 5

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

Ну а на этом простые типы данных закончились и в следующем веб-касте речь пойдет о словарях и хеш-таблицах в Windows PowerShell 5.

View this post on Instagram

A post shared by Yuriy Lebedev (@lebedevum) on Apr 7, 2019 at 11:50pm PDT

Обновление доменных служб Active Directory (AD DS) до Windows Server 2019

Здравствуйте, коллеги!

В дополнение к моей статье «Новое в доменных служб Active Directory (AD DS) Windows Server 2019», я подготовил веб-каст в котором демонстрируется обновление леса Active Directory, состоящего из одного домена под управлением двух контроллеров домена на базе Windows Server 2008 R2.

В веб-касте вы найдете описание особенностей доменных служб Active Directory (AD DS), описание функциональных уровней домена (DFL) и леса (FFL) и процедуры обновления домена и леса Active Directory. Центральное место в веб-касте занимают демонстрации добавления и вывода контроллеров домена Active Directory, перемещения хозяев операций FSMO, повышения функциональных уровней домена (DFL) и леса (FFL), а также управления репликацией при помощи утилиты repadmin.exe.

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

P.S. В данном веб-касте я не затрагиваю вопрос смены механизма репликация с File Replication Service (FRS) на Distributed File System (DFS-R), так как процесс перехода я подробно демонстрировал в веб-касте «Обновление доменных служб Active Directory (AD DS) до Windows Server 2016». Также, возможно, вам пригодятся веб-касты на эту тему, которые я записывал для Windows Server предыдущих версий:

• Обновление домена на Windows 2000 Server до Windows Server 2008 R2
• Обновление домена на Windows Server 2003 до Windows Server 2012 R2

Дополнительно, полезными могут оказаться следующие веб-касты по теме управления хозяевами операций FSMO и функциональными уровнями домена (DFL) и леса (FFL):

• Захват FSMO-ролей в Windows Server 2012 R2
• Откат функциональных уровней домена и леса в Windows Server 2012 R2

P.S. Я решил сделать небольшой перерыв в записи веб-кастов по Storage Spaces Direct, но планирую вернуться к ним в ближайшее время.

Новое в доменных службах Active Directory (AD DS) Windows Server 2019

В доменных службах Active Directory (AD DS) Windows Server 2019 не добавилось новых функциональных уровней домена и леса, что в свою очередь обеспечивает превосходную совместимость с контроллерами домена на базе Windows Server 2016. Но в самих внутренних процессах контроллера домена, а именно в размере хранилища версий ESE (ESE Version Store), произошли изменения, о которых я сегодня расскажу.

Доменные службы Active Directory (AD DS), также известные как службы каталога NT (NT Directory Service, NTDS), используют технологию Extensible Storage Engine (ESE) для обеспечения собственной базы данных.

Один из компонентов всех экземпляров базы данных ESE известен как хранилище версий (Version Store). Хранилище версий (Version Store) – это расположенное в памяти временное хранилище, где ESE хранит моментальные снимки (Snapshots) базы данных, создаваемых во время открытия транзакций. Это позволяет базе данных откатывать транзакции и возвращать базу данных к предыдущему состоянию в случае, когда транзакция не может быть успешно завершена. Когда хранилище версий переполняется, новые транзакции не могут быть созданы в базе данных, что приводит к завершению работы NTDS с ошибкой (Halt).

Ранее, до Windows Server 2019 для определения размера хранилища версий использовался алгоритм, впервые представленный вместе с Active Directory в Windows 2000. Когда служба NTDS появилась впервые, для вычисления размера хранилища версий использовался комплексный алгоритм. Данный алгоритм использует в расчетах размер простого указателя машины, число процессоров, размер страницы хранилища версий (основанный на потреблении, что не корректно для 64-ех битных операционных систем), максимальное число разрешенных одновременных вызовов RPC, максимальное число разрешенных сессий ESE разрешенных в потоке и так далее.

Так как хранилище версий размещается в памяти, это значит, что наиболее важный фактор в определении оптимального размера хранилища версий ESE – это объем физической памяти на машине. И самое забавное, что объем памяти – это, видимо, единственная переменная, не учтенная в выражении.

На сегодняшний день способ расчета, который Active Directory использует для вычисления размера хранилища версий, устарел. Оригинальный алгоритм был разработан в то время, когда на всех машинах запускались 32-ух битные версии Windows, а самые производительные серверы обладали одним или двумя гигабайтами оперативной памяти.

В результате, много клиентов обращались в поддержку Microsoft с ошибками на контроллерах домена, что могло быть вызвано или, по крайней мере усиленно, слишком маленьким размером хранилища версией ESE. Более того, клиенты зачастую не решаются увеличивать размер хранилища версий ESE по умолчанию через параметр реестра “EDB max ver pages (increment over the minimum)”, так как это сложная тема, требующая более тщательного исследования и работы с документацией, которая не всегда доступна.

Теперь, в Windows Server 2019, алгоритм существенно упрощен.

Когда NTDS впервые запускается, размер хранилища версий ESE вычисляется как 10% от объема физической оперативной памяти, с минимальным размером в 400 Мб и максимальным в 4 Гб.

Одинаковый алгоритм расчета применяется как к физическим машинам, так и к виртуальным. В случае, когда виртуальная машина использует динамическую память, вычисление основывается на начальном размере памяти (Staring RAM), назначенном виртуальной машине. Параметр реестра “EDB max over pages (increment over the minimum)” по-прежнему может быть использован для увеличения объема, сверх расчета по умолчанию (при необходимости даже сверх 4 Гб). Параметр реестра использует блоки (Buckets), не байты. Блок хранилища версий – это 32 Кб на всех 64-ех битных системах (на 32-ух битных системах размер блока составляет 16 Кб, но Microsoft более не поддерживает 32-ух битные серверные операционные системы). Соответственно, если добавить 5000 блоков, установив запись реестра в значение 5000 (Decimal), тогда 156 Мб будет добавлено к размеру хранилища версий по умолчанию. Минимальный размер в 400 Мб был выбран для обратной совместимости, так как при использовании старого алгоритма, размер хранилища версий по умолчанию для контроллера домена с одним 64-ех битным процессором составляет примерно 410 Мб, вне зависимости от объема оперативной памяти (не существует способа назначить меньше 400 Мб, аналогично предыдущим версиям Windows Server). Преимущество нового алгоритма заключается в линейном увеличении размера хранилища версий в соответствии с объемом оперативной памяти контроллера домена, чего раньше не было.

Значения по умолчанию:

Физическая память на контроллере домена	Размер хранилища версий ESE по умолчанию
1GB	400MB
2GB	400MB
3GB	400MB
4GB	400MB
5GB	500MB
6GB	600MB
8GB	800MB
12GB	1.2GB
24GB	2.4GB
48GB	4GB
128GB	4GB

Новый алгоритм расчета в результате гарантирует больший размер хранилища версий ESE для контроллеров домена с объемом оперативной памяти больше 4 Гб, по сравнению со старым алгоритмом. Это значит, что больше пространства хранилища версий будет выделено для обработки транзакций базы данных и меньше проблем будет возникать из-за недостаточного размера.

Обратите внимание, что данное улучшение присутствует только в Windows Server 2019 и на данный момент не планируется его перенос на предыдущие версии Windows Server.

Также следует заметить, что данное улучшение применяется только к Active Directory и не применяется к другим приложениям, которые используют базу данных ESE, таким как Exchange и другие.

P.S. Такие подробности, как правило, не раскрываются в публичных источниках, тем не менее, спасибо Ryan Ries за его оригинальный пост, который лег в основу этой статьи.

Ранее я уже записывал веб-касты, раскрывающие разные аспекты работы с доменными службами Active Directory. Их вы можете найти у меня на сайте в разделах по Windows Server 2008, Windows Server2012 и Windows Server 2016.

Ближайшее время я опубликую уже записанный веб-каст “Обновление доменных служб Active Directory (AD DS) до Windows Server 2019”, где продемонстрирую переход на использование контроллеров домена под управлением Windows Server 2019.