Не удается обработать файл провижининга
Обновлено: 07.07.2024
Эта технология не требует каких-либо значительных инфраструктурных манипуляций, если оставить за скобками производительность СХД.
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 с большими возможностями и более гибкой конфигурацией.
Попробуем выделить плюсы:
· Гибкость, лёгкость масштабирования при правильном проектировании.
· Возможность доставки образов на физические машины.
Однако, за все надо платить, в том числе и за плюсы. Минусы:
· Сложность внедрения. Сложность управления, высокая квалификация администраторов.
Файлы XML Schema Definition, такие как provisioning_v2.xsd, используют расширение XSD. Файл считается файлом Разработчик (XML Schema Definition) и впервые был создан компанией Microsoft для пакета ПО Windows 10.
Первая версия provisioning_v2.xsd для Windows 8.1 была представлена 10/18/2013 в Windows 8.1. Последнее обновление для Windows 10 состоялось 07/29/2015 [версия файла 10]. Файл provisioning_v2.xsd включен в версии ОС Windows 10 и Windows 8.1.
Совместимость с Windows 10, 8, 7, Vista, XP и 2000
Средняя оценка пользователей
| Сведения о разработчике и ПО | |
|---|---|
| Программа: | Windows 10 |
| Разработчик: | Microsoft |
| Программное обеспечение: | Windows |
| Версия ПО: | 10 |
| Сведения о файле | |
|---|---|
| Размер файла (байты): | 7373 |
| Дата первоначального файла: | 06/18/2013 |
| Дата последнего файла: | 03/18/2017 |
| Информация о файле | Описание |
|---|---|
| Размер файла: | 7.2 kB |
| Дата и время изменения файла: | 2013:06:18 12:35:46+00:00 |
| Дата и время изменения индексного дескриптора файлов: | 2017:11:05 07:04:28+00:00 |
| Ошибка: | Unknown file type |
✻ Фрагменты данных файлов предоставлены участником Exiftool (Phil Harvey) и распространяются под лицензией Perl Artistic.
Общие ошибки выполнения provisioning_v2.xsd
Ошибки файла provisioning_v2.xsd часто возникают на этапе запуска Windows, но также могут возникать во время работы программы. Эти типы ошибок XSD также известны как «ошибки выполнения», поскольку они возникают во время выполнения Windows. К числу наиболее распространенных ошибок выполнения provisioning_v2.xsd относятся:
- Не удается найти provisioning_v2.xsd.
- provisioning_v2.xsd — ошибка.
- Не удалось загрузить provisioning_v2.xsd.
- Ошибка при загрузке provisioning_v2.xsd.
- Не удалось зарегистрировать provisioning_v2.xsd / Не удается зарегистрировать provisioning_v2.xsd.
- Ошибка выполнения — provisioning_v2.xsd.
- Файл provisioning_v2.xsd отсутствует или поврежден.
Программа: C:\Windows\schemas\Provisioning\provisioning_v2.xsd
Среда выполнения получила запрос от этого приложения, чтобы прекратить его необычным способом.
Для получения дополнительной информации обратитесь в службу поддержки приложения.
В большинстве случаев причинами ошибок в XSD являются отсутствующие или поврежденные файлы. Файл provisioning_v2.xsd может отсутствовать из-за случайного удаления, быть удаленным другой программой как общий файл (общий с Windows) или быть удаленным в результате заражения вредоносным программным обеспечением. Кроме того, повреждение файла provisioning_v2.xsd может быть вызвано отключением питания при загрузке Windows, сбоем системы при загрузке или сохранении provisioning_v2.xsd, наличием плохих секторов на запоминающем устройстве (обычно это основной жесткий диск) или заражением вредоносным программным обеспечением. Таким образом, крайне важно, чтобы антивирус постоянно поддерживался в актуальном состоянии и регулярно проводил сканирование системы.
Шаг 1. Восстановите компьютер до последней точки восстановления, «моментального снимка» или образа резервной копии, которые предшествуют появлению ошибки.
Чтобы начать восстановление системы (Windows XP, Vista, 7, 8 и 10):
Если на этапе 1 не удается устранить ошибку provisioning_v2.xsd, перейдите к шагу 2 ниже.
Шаг 2. Запустите средство проверки системных файлов (System File Checker), чтобы восстановить поврежденный или отсутствующий файл provisioning_v2.xsd.
Средство проверки системных файлов (System File Checker) — это утилита, входящая в состав каждой версии Windows, которая позволяет искать и восстанавливать поврежденные системные файлы. Воспользуйтесь средством SFC для исправления отсутствующих или поврежденных файлов provisioning_v2.xsd (Windows XP, Vista, 7, 8 и 10):
Следует понимать, что это сканирование может занять некоторое время, поэтому необходимо терпеливо отнестись к процессу его выполнения.
Если на этапе 2 также не удается устранить ошибку provisioning_v2.xsd, перейдите к шагу 3 ниже.
Шаг 3. Выполните обновление Windows.
Если ни один из предыдущих трех шагов по устранению неполадок не разрешил проблему, можно попробовать более агрессивный подход (примечание: не рекомендуется пользователям ПК начального уровня), загрузив и заменив соответствующую версию файла provisioning_v2.xsd. Мы храним полную базу данных файлов provisioning_v2.xsd со 100%-ной гарантией отсутствия вредоносного программного обеспечения для любой применимой версии Windows . Чтобы загрузить и правильно заменить файл, выполните следующие действия:
Windows 10: C:\Windows\schemas\Provisioning\Windows 8.1: C:\Windows\schemas\Provisioning\
Если этот последний шаг оказался безрезультативным и ошибка по-прежнему не устранена, единственно возможным вариантом остается выполнение чистой установки Windows 10.
СОВЕТ ОТ СПЕЦИАЛИСТА: Мы должны подчеркнуть, что переустановка Windows является достаточно длительной и сложной задачей для решения проблем, связанных с provisioning_v2.xsd. Во избежание потери данных следует убедиться, что перед началом процесса вы создали резервные копии всех важных документов, изображений, установщиков программного обеспечения и других персональных данных. Если вы в настоящее время не создаете резервных копий своих данных, вам необходимо сделать это немедленно.
В рамках данной статьи рассматривается провиженинг телефонных аппаратов Yealink с помощью бесплатного модуля под FreePBX OSS EndPoint Manager. Данные аппараты можно настроить и в ручном режиме, но когда их количество перешагивает рубеж более 10, намного эффективнее данную настройку производить централизовано.
Если в АТС не учтановлен данный модуль, то его возможно установить стандартными средствами через раздел FreePBX Admin > Module Admin. Модуль находится в разделе Connectivity. После установки и настройки модуля можно переходить собственно к формированию конфигурации под выбранную модель телефона.
Далее необходимо перейти в раздел Connectivity > OSS Endpoint Package Manager и в нем произвести установку пакетов под необходимые аппараты. Но в данном разделе не будет файлов под Т21, ничего страшного — можно установить Т20 или Т22, а потом подогнать под необходимый тип аппарата.
Далее перейти в раздел OSS Endpoint Advanced Settings > Product Configuration Editor, выбрать необходимую модель.
В разделе Local File Configs выбрать y0000000000$suffix.cfg — это общий конфигурационный файл для выбранной модели аппаратов. По умолчанию в нем довольно много параметров прописано. Но возможно их сократить. Достаточно прописать подобные строчки:
Далее данный конфигурационный файл стоит сохранить под именем с суфиксом обозначающим модель телефонного аппарата — для Т21 — это y000000000034.cfg
Далее необходимо выбрать $mac.cfg — в нем необходимо внести изменения для шаблона индивидуального конфигурационного файла. В нем будут прописаны настройки для аккаунтов, под конкретный аппарат.
Его также стоит схранить под каким либо именем — отличающимся от стандартного.
Далее в разделе OSS Endpoint Template Manager в поле Add New Template — ввести имя шаблона, выбрать продукт и склонировать шаблон из шаблона модели, которую тоже необходимо выбрать.
Открыть созданный шаблон на редактирование и выбрать в параметрах
Edit File Configurations for: y0000000000$suffix.cfg и
Edit File Configurations for: $mac.cfg в полях Select Alternative File Configurations for для каждого соответственно ранее созданные шаблоны конфигурационных файлов
Заключительным этапом настройки является сопоставление телефонного аппарата по мак-адресу с конкретным пользователем телефонии. Данная настройка производится в разделе OSS Endpoint Device List. Для добавления нового аппарата необходимо в подразделе Add Device прописать мак телефона в поле MAC Address, выбрать из выпадающего списка производителя в поле Brand, Выбрать модель для которой создавался шаблон (в указанном примере T20) в поле Model of Phone, в поле Line — выбрать настраиваемую линию телефонного аппарата, в поле Extension Number — выбрать внутренний номер, а в поле Template указать шаблон созданный на предыдущем шаге. По нажатию кнопки Add — на сервер будет записан индивидуальный файл под телефон. Все ранее заведенные аппараты отображаются списком на данной вкладке, причем если пиктограма вначале строки зеленого цвета — это означает, что телефон онлайн.
На этом настройка провиженинга телефонных аппаратов Yealink T21 средствами модуля FreePBX OSS EndPoint Manager завершена успешно.
Для того чтобы телефоны начали прошиваться, на DHCP-сервере прописать опцию 66 и затем перезагрузить все телефоны
В этом году исполняется 10 лет с момента продажи первой системы хранения данных 3PAR с технологией Thin Provisioning. И несмотря на то что технология стала очень популярной и востребованной, толкового описания того как же это работает на низком уровне мне встретить до сих пор не удалось. В этой статье я попробую осветить наиболее «темные», на мой взгляд, стороны thin provisioning – технические основы данной технологии. То есть, то как именно хост взаимодействует с системой хранения данных. Эти технологии сейчас уже не являются эксклюзивом 3PAR, так как теперь это индустриальные стандарты, но так как технология thin provisioning впервые появилась в 3PAR, то позволю себе отдать все лавры именно этим массивам.
Зачем нужен thin provisioning
Для тех, кто пропустил предыдущие 10 лет, я всё же вкратце напомню, что такое thin provisioning и для чего он нужен, а остальные могут с чистой совесть пропустить этот раздел.
Thin provisioning – это технология виртуализации систем хранения данных, которая позволяет увеличить эффективность использования ресурсов системы хранения. Эта технология необходима для уменьшения использования дискового пространства, которое непосредственно не используется для хранения данных приложений. В частности файловые системы никогда в нормальных условиях не бывают заполнены на 100%. Однако всегда нужно иметь некий запас свободного места для обеспечения нормального функционирования файловой системы и для обеспечения готовности к росту данных. Это фактически не используемое пространство выделяют для всех логических томов на системе хранения данных. Логические тома, дисковое пространство для которых выделяется в полном объеме в момент создания на системе хранения, называют «тостыми». Такая модель использования дисковых ресурсов появилась вместе с первыми устройствами для хранения данных и жива до сих пор.
Как работает и зачем нужен thin provisioning-01
ля решения подобных проблем и были придуманы thin provisioning и thin reclamation о которых мы и поговорим более подробно.
Как работает thin provisioning
Концепция thin provisioning проста и заключается в следующем:
В момент создания логического тома (LUN) на дисковом массиве не происходит полное выделение всего объёма тома. Инициализируется таблица соответствия LUN LBA -> Backend physical address. Администратор системы хранения указывает максимальный возможный размер тома и порог заполненности тома, при котором он получит предупреждение.
Выделение новых блоков данных для логического тома происходит по мере заполнения тома.
При освобождении сервером блоков данных он должен сообщить о освободившихся блоках системе хранения для возврата их в общий пул. Технология называется thin reclamation и описана далее.
Как работает и зачем нужен thin provisioning-02
При запросе сервером размера тома (SCSI Read Capacity) система хранения отдаёт максимальный размер тома, который установил администратор СХД.
Сумма максимальных объемов всех томов на системе хранения может превышать физически доступное пространство на системе хранения.
Как работает и зачем нужен thin provisioning-03
Исходя из вышесказанного, представить схему работы thin provisioning не составляет труда. При получении системой хранения команды SCSI Write (инкапсулированной в стек FC, SAS, iSCSI и пр.) она выделяет очередную порцию данных и записывает туда данные из SCSI Write. В случае с 3PAR блоки выделяются размером в 16К.
Как работает thin reclamation
А теперь обсудим гораздо более интересные и не очевидные моменты – каким образом хост взаимодействует с системой хранения для возврата освободившегося дискового пространства в общий пул. Взаимодействие хоста и системы хранения – крайне важный нюанс, так как только хост знает какие блоки можно удалять, а какие нет. Технология thin reclamation была впервые реализована на массивах 3PAR и сегодня является индустриальным стандартом, утвержденным Международным Комитетом по стандартизации в сфере информационных технологий (INCITS). Документ называется T10 SBC-3 и расширяет стандарт SCSI новыми командами для взаимодействия с системами хранения (эти команды были добавлены в восемнадцатой ревизии документа 23 февраля 2009 года). Аналогичный стандарт есть также для ATA/SATA устройств.
Для реализации thin provisioning стандарт предусматривает 3 SCSI команды:
- UNMAP
- WRITE SAME
- GET LBA STATUS
Стандарт обязывает все системы хранения данных с thin provisioning в обязательном порядке поддерживать как минимум команду UNMAP или же команду WRITE SAME с битом unmap. Рассмотрим описанный протоколом API.
UNMAP
Сообщает системе хранения о необходимости освободить одну или несколько групп последовательных LBA (Logical Block Address). Система хранения должна пометить данные LBA как свободные (unmapped, в терминах SCSI), освободить место на бекэнде и фоновым процессом затереть данные которые там ранее находились на тот случай, если эти блоки будут потом выделены другому хосту. В этой команде передаётся исключительно служебная информация в виде множества пар состоящих из «LBA Address» и «Number of Logical Blocks».
Как работает и зачем нужен thin provisioning-04
Если по каким-то причинам хост не желает использовать команду UNMAP он может получить похожий эффект с помощью команды WRITE SAME. Для этого предусмотрено битовое поле unmap. Если команда WRITE SAME с установленным битом unmap придет на массив с thin provisioning и том на массиве тонкий, то массив сделает тоже что и в случае с командой UNMAP. Отличается от команды UNMAP (42h) тем, что используя WRITE SAME нет возможности указать большое количество блоков для освобождения. Можно указать только одну пару «LBA Address» и «Number of Logical Blocks».
Также не стоит забывать, что команда WRITE SAME это в первую очередь команда для записи данных. В том случае, если бит unmap не установлен, система хранения не поддерживает thin provisioning или том толстый, то будет выполнена обычная операция записи данных по заданным LBA. Из этого следует, что в данных случаях SCSI READ обязан вернуть именно те данные, которые туда были записаны. Тут некоторые производители вроде того же Хьюлета хитрят и вместо последовательной записи однотипных данных (например нулей) помечают в метаданных логического тома эти блоки как выделенные но «заполненные нулями». Называется эта технология – zero detection.
Как работает и зачем нужен thin provisioning-05
Это сервисная операция (специфичная для устройства) и она использует код команды SERVICE ACTION IN (9Eh). Она позволяет узнать серверу:
1. Поддерживает ли том thin provisioning.
2. Статус определенного блока на системе хранения (выделены ли для него реальные ёмкости на бекэнде или нет).
3. Гранулярность thin provisioning для тома.
4. Лимиты (тревожный уровень и максимальный объем).
Команда очень полезна например для фонового поиска со стороны хоста блоков, выделенных на массиве, но не используемых хостом для хранения данных или при переезде с толстых томов на тонкие.
Читайте также: