Не удается обработать файл провижининга citrix

Обновлено: 05.07.2024

Произошла ошибка во время выполнения задачи синхронизации.
Показать подробности внутреннее исключение общую ошибку и описание ошибки: Несоответствие типа коллекции: -> SMS00001

Решение

Сведения об исправлении

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

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

Примечание. Если наблюдаются другие проблемы или необходимо устранить неполадки, вам может понадобиться создать отдельный запрос на обслуживание. Стандартная оплата за поддержку будет взиматься только за дополнительные вопросы и проблемы, которые не соответствуют требованиям конкретного исправления. Для получения полного списка телефонов поддержки и обслуживания клиентов корпорации Майкрософт, или для создания отдельного запроса на обслуживание, посетите следующий веб-сайт Майкрософт:

http://support.microsoft.com/contactus/?ws=supportПримечание. В форме "Пакет исправлений доступен для скачивания" отображаются языки, для которых доступно исправление. Если нужный язык не отображается, значит исправление для данного языка отсутствует.

Предварительные условия

Для установки этого исправления требуется Пакет обновления 2 для System Center 2012 Configuration Manager или Пакет обновления 1 для System Center 2012 R2 Configuration Manager установлен.

Сведения о перезагрузке компьютера

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

Примечание. Рекомендуется закрыть консоль администрирования диспетчера конфигурации перед установкой данного пакета исправлений.

Сведения о замене исправлений

Это исправление не заменяет все ранее выпущенные исправления.

Английская версия данного исправления содержит атрибуты файла (или более поздние атрибуты файлов), приведенные в следующей таблице. Дата и время для этих файлов указаны в формате общего скоординированного времени (UTC). При просмотре сведений о файле, он преобразуется в локальное время. Чтобы узнать разницу между временем по Гринвичу и местным временем, откройте вкладку Часовой пояс элемента Дата и время в панели управления.

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

Machine Creation Service позволяет создавать ВМ из master image, используя возможности систем управления виртуальной инфраструктурой (vCenter, XenCenter, SCVMM).

Особенно хочется отметить, что начиная с версии XenDesktop 7. x появилась возможность развертывания серверов XenApp (терминальных серверов) с помощью этого инструмента.

Создаваемые с помощью MCS ВМ состоят из:

· Базового диска, доступного только для чтения данных;

· difference диска ( thin provision , при наличии поддержки таковых), доступного на запись;

· Identity диска, содержащего идентификационную информацию о виртуальной машине.

При этом, размер ID диска 16 Мб, а размер difference диска теоретически может вырасти до размеров Базового, при условии, что ВМ не будет перезагружаться.

Для Pooled Desktops никакие пользовательские изменения образа не сохраняются, т.к. difference диск, содержащий эти изменения пересоздается при каждой перезагрузке ВМ.

Далее пройдемся по самому процессу создания ВМ.

Итак, в первую очередь создается снапшот ВМ, которую мы выбрали в качестве исходной («золотой образ»). После создания снапшота, производтся полное копирование Базового диска на все доступные хранилища, подключенные в хосту и происходит создание учетных записей ВМ в Active Directory . В завершении всего происходит создание difference и ID дисков.

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

· Отказоустойчивость из коробки .

· Простота. Сюда же относится отсутствие «специальных» требований к инфраструктуре и простота администрирования.

Однако, нельзя не упомянуть и нескольких условно отрицательных аспектов Machine Creation Services:

· Нагрузка на СХД. Имеется в виду, что она выше, чем при использовании Citrix Provisioning Services.

· Относительно долгое время создания/изменения образов. Данный процесс связан с копированием Базового диска и косвенно опять упирается в СХД.

Данная технология является альтернативной ~~формой жизни~~ к Machine Creation Service и представляет собой доставку образов ВМ ( vDisk ) по сетям Ethernet . Отличительной особенностью этой технологии является возможность доставки образов на физические машины (в том числе, и бездисковые станции), используя, например PXE . Кстати, серверы XenApp тоже вполне можно держать на PVS (в том числе и «железные»).

Собственно, Citrix Provisioning Services – классическая клиент-серверная технология, где сервером является Provisioning Server , а клиентом – Target Device . Для целей отказоустойчивости и распределения нагрузки, серверы PVS объединяются в фермы. Кстати будет упомянуть о возможности динамического распределения нагрузки (клиентов) по серверам Provisioning Services .

Попробуем более детально разобраться в архитектуре PVS .

Главной единицей в PVS является vDisk – золотой образ ОС в формате VHD , сконвертированный специальной утилитой. Вскользь упомянем о возможности создания версий vDisk для внесения изменений в Золотой образ.

В нормальных условиях ( Standard ) vDisk доступен пользователям только на чтение, запись же производится в специальную область, называемую Write Cache . Все образы ( vDisk ) кэшируются в оперативной памяти сервера, что позволяет снизить нагрузку на СХД, но приводит к необходимости выделения большого объема оперативной памяти серверу.

Принципиально различаются следующие типы Write Cache :

· Cache on server. Запись происходит в папку на сервер по Ethernet . Обычно это очень медленно.

· Cache in device RAM. Данные хранятся в ОЗУ загруженной машины.

· Cache on device hard drive. Данные хранятся на локальных дисках загруженной машины.

· Cache in device RAM with overflow on hard disk. Данные хранятся в ОЗУ загруженной машины, по мере заполнения которой перетекают на HDD . Данная фича появилась совсем недавно и, по заявлению вендора, позволяет очень сильно сэкономить на СХД ( IOPS ). Более подробно можно почитать тут.

Конечно же, PVS тоже умеет создавать ВМ сотнями из своей консоли, создавать их учетные записи в AD и проч.

Отдельного упоминания заслуживает отказоустойчивость хранилища vDisk . Поскольку, серверов PVS обычно > 1, а vDisk они раздают одни и те же, существует 2 способа хранения этих дисков:

· Distributed Storage . Распределенное хранилище, основано на наборе подключенных к каждому серверу дисков. При такой реализации встает вопрос синхронизации vDisk и особенно версий этих vDisk между разными серверами фермы. Для решения этого вопроса может быть использован механизм DFS - R , однако здесь тоже есть свои особенности. Также можно применять различные скрипты для копирования дисков их версий и метаданных.

· Centralized Storage . Централизованное хранилище, кластер, доступный сразу всем членам фермы. В качестве кластерной ФС может выступать недавно приобретенная Citrix Melio FS . Однако данное решение тоже не может являться панацеей, ведь в случае падения файловой системы мы получаем полный отказ в обслуживании.

Для хранилища могут использоваться протоколы FC , iSCSI , SMB , NFS .

Стоит сказать пару слов о необходимости подготовки сетевой инфраструктуры при внедрении PVS, т.к. это один из критических компонентов для реализации сервиса.

При использовании PXE понадобится DHCP с некоторыми опциями, желательно в отказоустойчивой конфигурации. Приведем некоторые необходимые рекомендации при реализации сети для Provisioning Services:

· Отключение Large Send Offload

· Желательно использование отдельной подсети ( VLAN ) для PVS и Target Devices

· Для VMware необходимо использование сетевого адаптера VMXNet 3

Со всеми рекомендациями Citrix по сетевой инфраструктуре можно ознакомиться в CTX117374.

Как мы видим, Citrix Provisioning Services является несколько более сложной альтернативой Machine Creation Service с большими возможностями и более гибкой конфигурацией.

Попробуем выделить плюсы:

· Гибкость, лёгкость масштабирования при правильном проектировании.

· Возможность доставки образов на физические машины.

Однако, за все надо платить, в том числе и за плюсы. Минусы:

· Сложность внедрения. Сложность управления, высокая квалификация администраторов.

Citrix.Xip.Interfaces.dll это файл библиотеки динамических ссылок, который является частью разработанный Citrix Systems, Inc., Версия программного обеспечения: обычно о по размеру, но версия у вас может отличаться. Файлы DLL - это формат файлов для динамических библиотек, который используется для хранения нескольких кодов и процедур для программ Windows. Файлы DLL были созданы, чтобы позволить нескольким программам использовать их информацию одновременно, тем самым сохраняя память. Это также позволяет пользователю изменять кодировку нескольких приложений одновременно, не изменяя сами приложения. Библиотеки DLL могут быть преобразованы в статические библиотеки с помощью дизассемблирования MSIL или DLL в Lib 3.00. Формат файла .exe файлов аналогичен формату DLL. Файлы DLL, и оба типа файлов содержат код, данные и ресурсы.

Наиболее важные факты о Citrix.Xip.Interfaces.dll:

Citrix.Xip.Interfaces.dll безопасный или это вирус или вредоносное ПО?

Ответ - нет, сам по себе Citrix.Xip.Interfaces.dll не должен повредить ваш компьютер.

В отличие от исполняемых программ, таких как программы с расширением EXE, файлы DLL не могут быть выполнены напрямую, но должны вызываться другим кодом, который уже выполнен. Тем не менее, DLL имеют тот же формат, что и EXE, и некоторые могут даже использовать расширение .EXE. В то время как большинство динамических библиотек заканчиваются расширением .DLL, другие могут использовать .OCX, .CPL или .DRV.

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

С другой стороны, если файл .dll прикреплен к исполняемому файлу, который предназначен для повреждения вашего компьютера, возможно, это опасно. Мы рекомендуем вам запустить сканирование вашей системы с инструмент, подобный этому это может помочь выявить любые проблемы, которые могут существовать.

Вот почему обычно, когда вы видите новый файл .dll на вашем компьютере, где-то будет файл .exe.

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

Могу ли я удалить или удалить Citrix.Xip.Interfaces.dll?

Согласно различным источникам онлайн, 3% людей удаляют этот файл, поэтому он может быть безвредным, но рекомендуется проверить надежность этого исполняемого файла самостоятельно, чтобы определить, является ли он безопасным или вирусом.

Программные программы хранят файлы DLL в одной или нескольких папках во время установки. Эти файлы содержат код, который объясняет работу программ.

Если вы планируете удалить Citrix.Xip.Interfaces.dll, лучше оставить его в покое. Причина этой логики заключается в том, что некоторые программы совместно используют эти файлы, поэтому удаление определенного файла DLL может непреднамеренно вызвать проблемы. Это означает, что удаление Citrix.Xip.Interfaces.dll может привести к прекращению работы одной или нескольких других программ или только в ограниченной степени.

Некоторые программы также могут устанавливать файлы DLL в несколько папок вне папки Program Files (где установлено большинство программ). Поиск этих DLL-файлов может быть очень трудным, а удаление их может быть опасным.

Как уже упоминалось выше, если вы не уверены, что Citrix.Xip.Interfaces.dll используется другой программой, мы рекомендуем оставить ее в покое. Однако, если вам нужно удалить файл, мы рекомендуем сначала сделать копию. Если после этого у вас возникнут проблемы с другой программой, требующей использования недавно удаленного DLL-файла, вы можете восстановить файл из резервной копии.

Не удалось запустить приложение, так как не найден файл Citrix.Xip.Interfaces.dll. Переустановка приложения может решить проблему.
Citrix.Xip.Interfaces.dll не найден
Citrix.Xip.Interfaces.dll отсутствует
Обязательная DLL-библиотека Citrix.Xip.Interfaces.dll не найдена
Приложение или Citrix.Xip.Interfaces.dll не является допустимым образом Windows
Citrix.Xip.Interfaces.dll отсутствует или поврежден
Не удается найти Citrix.Xip.Interfaces.dll
Не удается запустить Citrix.Xip.Interfaces.dll. Отсутствует необходимый компонент: Citrix.Xip.Interfaces.dll. Пожалуйста, установите Citrix.Xip.Interfaces.dll снова.

Обновлено ноябрь 2021 г .:

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

(опциональное предложение для Reimage - Cайт | Лицензионное соглашение | Политика конфиденциальности | Удалить)

Если Citrix.Xip.Interfaces.dll отсутствует или поврежден, это может повлиять на многие приложения, включая операционную систему, что может помешать вам выполнять свою работу или использовать критические функции в критически важных программах.

Запустить SFC

Самый безопасный способ восстановить отсутствующий или поврежденный файл Citrix.Xip.Interfaces.dll, вызванный вашей операционной системой Windows, - запустить встроенную проверку системных файлов, которая заменяет отсутствующие или поврежденные системные файлы.

Для этого щелкните правой кнопкой мыши кнопку «Пуск» на компьютере Windows 10, чтобы открыть меню WinX, и щелкните ссылку «Командная строка (администратор)».

В окне CMD скопируйте следующую команду и нажмите Enter:

Сканирование может занять 10 минут, и если оно успешно завершено, вы должны перезагрузить компьютер. Запуск sfc / scannow в безопасном режиме или при запуске может дать лучшие результаты.

Обновить драйверы

Иногда при использовании аппаратного обеспечения, такого как принтер, вы получаете отсутствующую ошибку файла Citrix.Xip.Interfaces.dll. Эта ошибка может быть связана с более старой версией драйвера, который не совместим с обновленным файлом .dll, поэтому принтер ищет неправильный файл .dll и не может его найти.

Обновите драйверы вашего устройства, чтобы увидеть, решит ли это проблему.

Восстановление при загрузке

Восстановление при загрузке - это еще один способ восстановить все DLL-файлы, такие как Citrix.Xip.Interfaces.dll, до их первоначального рабочего состояния. Однако это исправление может вызвать проблемы в других программах, особенно если программа обновила файлы DLL.

Загрузите или переустановите Citrix.Xip.Interfaces.dll

В большинстве учебников и руководств авторы предупреждают своих читателей, чтобы они не загружали недостающие файлы Citrix.Xip.Interfaces.dll со случайных и непригодных для использования веб-сайтов, которые могут предоставить им вредоносное ПО. Это не без причины, конечно. Правда в том, что в Интернете полно сайтов, которые обещают пользователям решить их проблемы, открыв определенные приложения или программы как можно скорее. К сожалению, очень немногие могут действительно оправдать ваши ожидания.

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

В данной статье я попытаюсь максимально просто описать принципы работы двух основных методов развертывания виртуальных машин в инфраструктуре Citrix.

Принцип работы MCS

Citrix Machine Creation Services является одним из двух типов массового автоматизированного развертывания виртуальных машин и в сравнении с Provisioning Services (PVS) MCS является встроенным функционалом XenDesktop.

Нижеследующие шаги описывают процесс создания каталога виртуальных машин для их дальнейшего развертывания механизмом MCS.

Создание виртуальных машин в каталоге можно условно разделить на следующие этапы:

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

2. На базе основного диска и снепшота будет создана новая версия, так называемый Base Disk. Base Disk является основой для последующего создания виртуальных машин каталога.

3. Средствами гипервизора создается (клонируется) заданное при конфигурации количество виртуальных машин. При применении гипервизора vSphere используется технология Linked Clone.

Каждая созданная виртуальная машина состоит из двух дисков:

a. Difference (Delta) Disk – на этом диске содержится временная информация, используемая операционной системой. После каждой перезагрузки вся записанная информация удаляется. Difference Disk можно считать аналогом Write Cache Disk в PVS.

b. Identity Disk – на нем сохраняется информация, делающую систему уникальной, например SID, имя компьютера, пароль. Размер диска составляет всего 16 MB.

4. Для каждой машины создается учетная запись в Active Directory.4. Для каждой машины создается учетная запись в Active Directory.

5. После перезагрузки, созданные виртуальных машины получают IP-адрес от DHCP-сервера.

Каждая последующая актуализация системы требует повторения шагов от 1 до 3.

Full Clone

MCS Full Clone – создание полноценной копии виртуальной машины

В версии XenDesktop 7.11 появилась возможность выбора, использовать ли Full Clone или Linked Clone. Основное преимущество Full Clone, — это возможность создания резервной копии виртуальной машины, что в свою очередь упрощает процесс миграции виртуальных машин.

Использование технологии Full Clone имеет, к сожалению, и недостатки, а именно: значительно увеличивается время создания / обновления каталогов, требуется больше места на СХД и Full Clone применима только для настольных операционных систем (Windows 10).

Принцип работы PVS

PVS - это технология, которая обеспечивает одновременную загрузку операционной системы по сети с помощью стриминга на множество целевых систем (виртуальных или физических). Целевые компьютеры, в отличие от классического ПК, не имеют жесткого диска с установленной операционной системой и запускаются непосредственно из сети. Передачи нескольких сотен мегабайт уже достаточно для старта операционной системы и регистрации пользователя в ней. Например, окно регистрации в системе Windows 10 появляется после загрузки 250 MB.

Ключевым элементом инфраструктуры PVS является Provisioning Server. Сервер PVS не только отвечает за управление средой PVS, но и является центральной точкой потоковой передачи vDisk-ов. Все настройки конфигурации хранятся в базе данных MS SQL. По сравнению с MCS, PVS не является частью XenApp / XenDesktop.

Для достижения высокой доступности требуется как минимум два сервера PVS. Серверы PVS используют протокол IPC для связи друг с другом.

Следующие шаги описывают принцип работы PVS:

PVS Streaming Service предоставляет файл (PXE-Bootstrap File: ARDBP32.BIN) для начальной загрузки. PXE-Bootstrap File содержит инструкции для запроса виртуального диска.
На основании MAC-адреса проверяется, имеет ли целевая система запись в базе данных PVS.
vDisk передается по сети целевой системе. Передача данных осуществляется по UDP протоколу.

Master Image - vDisk

Для создания vDisk-а необходимо на операционной системе (серверной или настольной) установить PVS Target Device. Задача PVS Target Device сконвертировать диск операционной системы в vhd-файл (с версии 7.7 у вас есть выбор между VHD и VHDX) и сохранить его в соответствующей папке (PVS Store). Для конвертации используется XenConvert Tool.

В папке PVS Store сохраняются файлы следующих типов:

.vhdx (vhd) – диск операционной системы
.lok – файл блокировки доступа, активен если vDisk используется
.pvp – конфигурационный файл vDisk
.avhd - (z.B. .1.avhdx) – файл с последними сохранёнными изменениями (Differencing Disk)

Методы загрузки

Существует три различных способа загрузки целевых систем в среде PVS: DHCP, PXE и BDM:

1. DHCP Метод

DHCP является наиболее широко используемым и пожалуй самым популярным методом. Клиент получает IP-адрес от DHCP-сервера, который включает в себя следующие параметры:- Option 66 – здесь указывается IP-адрес PVS сервера - Option 67 – имя файла загрузки (ARDBP32.bin)

2. PXE Метод

Клиент получает только IP-адрес с сервера DCHP, так как на DHCP-сервере не настроены опции 66 и 67. PVS сервер сам реагирует на запрос клиента и отвечает ему передавая параметры опций 66 / 67. Данный метод крайне редок и не всегда возможен, ввиду определённой зависимости от конфигурации сети.

3. BDM (Boot Device Manager)

В этом случае целевая система запускается непосредственно с физического загрузочного носителя (CD). Этот метод бывает единственно возможным для использования PVS, так как опции 66 / 67 уже используются другими системами (например, SCCM или Matrix42).

Пошаговое описание процесса загрузки

1. Получение IP адреса - целевое устройство получает IP-адрес от DHCP сервера. Вместе с IP-адресом передаются также адрес TFTP-сервера (Option 66) и название файла загрузки (Option 67).

2. Загрузка Bootstrap файла - загрузочный файл (ARDBP32.bin) скачивается с TFTP-сервера на целевое устройство.

3. Процесс входа в систему PVS - после того, как целевое устройство получило IP-адрес и скачало загрузочный файл, оно регистрируется на PVS-сервере, чтобы начать стриминг vDisk-а.

4. Single Read Mode – целевое устройство начинает отправлять запросы на PVS-сервер в так называемом режиме одиночного чтения и делать это до тех пор, пока операционная система не начнет загружать драйверы, и не загрузит BNISTACK-драйвер.

5. BNISTACK / MIO Read Mode – заключительная фаза загрузки системы. BNISTACK загружается в память и продолжает управлять коммуникацией между сервером и целевым устройством. BNISTACK использует параллельно несколько потоков для связи с сервером PVS. Multiple Input/Output - один канал используется для запроса и множество для получения ответа от сервера PVS.

PVS Store

Store – это место физического хранения для vDisk-ов. Данная папка может находиться как на любом из PVS-серверов, так и на общем хранилище (Shared Storage). Важно позаботиться о достаточном количестве места на диске и быстром доступе к нему (IOPS performance).
Использование совместного хранилища (Shared Storage) не требует дополнительных механизмов для синхронизации vDisks-ов.

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

Write Cache

В стандартном режиме (Standard Mode) vDisk доступен только для чтения (read only), и все данные, которые обычно записываются на системный диск виртуальной машины, переносятся в Write Cache. Существует несколько различных режимов настроек Write Cache.

Write Cache - это временная память, содержащая данные, созданные операционной системой во время работы, а также информация, которую следует сохранить после перезагрузки (например, журналы событий, сигнатуры вирусов, кэш App-V). Write Cache Disk также является типичным местом для хранения Pagefile-файла.

Write-Cache файл (vdiskdiff.vhdx) постоянно растет в течении работы системы и обнуляется только после перезагрузки. vdiskdiff фактически и является следующими опциями “Cache on Target Device Hard Drive” и „Cache in device RAM withoverflow on hard disk“

Текущая версия PVS предлагает шесть различных опций для хранения Write-Cache. У каждого варианта есть свои плюсы и минусы. Рекомендуется использовать „Cache in device RAM with overflow on hard disk“

Возможные варианты размещения Write Cache

Кэш на жестком диске целевого устройства (Cache on device hard disk)

В данном случае Write Cache расположен на жестком диски целевого устройства. До недавнего времени данный вариант был самым предпочтительным решением.

Постоянный к эш на жестком диске целевого устройства и сервера (Cache on device hard disk persisted / Cache on server, persistent )

Как следует из названия, речь идет о постоянном, не сбрасываемом после перезагрузки файла кэша.

Write Cache в рабочей памяти целевого устройства (Cache in device RAM)

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

Write Cache на жестком диске PVS сервера (Cache on server)

Данный способ наиболее неэффективный из всех перечисленных. Write Cache расположен на PVS-сервере, доступ к которому осуществляется по сети.

Write Cache в рабочей памяти целевого устройства с переполнением на жесткий диск (Cache in device RAM with overflow on hard disk)

Данная опция представляет собой идеальный баланс между производительностью и стоимостью. Опция имеет два уровня. Вначале все изменения хранятся в памяти виртуальной машины. Размер памяти, вернее его максимальное значение для каждого виртуального диска настраивается в конфигурации. Не забывайте о том, что выделенная память будет взята из общей памяти виртуальной машины. Когда выделенная память будет заполнена, наименее востребованные данные, будут перемещены из области ОЗУ в файл (vdiskdif.vhdx) на жестокий диск виртуальной машины. В настоящее время данная опция является рекомендованной производителем.

Режим доступа к vDisk

Private Mode - в этом случае vDisk находится в состоянии записи и соединен только с одной виртуальной машиной.

Standard Mode - vDisk доступен только для чтения и используется многими виртуальными машинами одновременно.

Иными словами, в Private Mode диск всегда имеет отношение 1:1, в стандартном режиме всегда соотношение 1:n.

Обновление vDisk-а

Как вы можете видеть на приведенных ниже рисунках, целевое устройство может быть загружено с разных версий диска. Differencing Disk (.avhdx) – это всегда зависимый от предыдущей версии снимок файловой системы, по функциональности сравнимый со снапшотом. Все .avhdx-файлы последовательно нумеруются. Differencing Disk используется для установки программного обеспечения, обновлений или исправлений.

Существует три различных метода доступа: обслуживание (Maintenance), тестирование и рабочий (Produktion)

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

Test - это версия, предназначенная только для чтения, используемая для тестирования.

Produktion – рабочая версия, из которой загружены все виртуальные машины каталога

Дополнительная полезная информация

Подробные диаграммы и описание процесса загрузки (постер): Citrix Provisioning Services Boot Process

Best Practices for Configuring Provisioning Services Server on a Network (CTX117374) - Прочитать

Guidance on PVS Ports and Threads - Прочитать

Understanding Write Cache in Provisioning Services Server (CTX119469) - Прочитать

Size Matters: PVS RAM Cache Overflow Sizing - Прочитать

Всегда рад Вашим отзывам, комментариям и конструктивной критике

Читайте также: