Собрание заметок об информационных технологиях
При попытке выполнить миграцию виртуальных машин на новый хост Hyper-V только что добавленный в System Center 2012 R2 Virtual Machine Manager (VMM) возникли ошибки на этапе предварительной проверки хоста на предмет возможности такого переноса. Как следствие мастер миграции VMM не позволял выполнить перенос виртуальных машин на проблемный хост.
При обновлении ОС до Windows Server 2012 R2 на одном из хостов виртуализации Hyper-V столкнулся с загадочной проблемой. При попытке задать параметры Live Migration через консоль Hyper-V Manager получал ошибку "Failed to modify settings"
Завершая тему обновления линейки продуктов Microsoft System Center (SC) 2012 SP1 до уровня System Center 2012 R2, в этой заметке будет рассмотрена процедура обновления SC 2012 SP1 Virtual Machine Manager (VMM). В нашем примере исходный экземпляр VMM Management Server расположен на одном виртуальном сервере под управлением Windows Server 2012 Standard с использованием для хранения базы данных VirtualManagerDB удалённого кластеризованного экземпляра SQL Server 2012 SP1
Рассмотрим процесс обновления существующего экземпляра SC 2012 SP1 VMM до уровня System Center 2012 R2 с параллельным внедрением конфигурации повышенной доступности с использованием двух серверов управления на базе службы кластеризации Windows Server 2012 R2 Standard. В качестве исходных условий принимается то, что БД VMM уже расположена на выделенном кластеризованном экземпляре SQL Server 2012 SP1, а в качестве VMM Library используется отдельный файловый кластер, таким образом, в нашей конфигурации на текущий момент роль VMM Management Server является узким местом - возможной точкой отказа. В ходе дальнейшего описания рассмотрим процесс кластеризации обозначенной роли, чтобы в конечном итоге получить схему инфраструктуры VMM, в которой все основные компоненты выполняются в режиме повышенной доступности - Highly Available
В данной статье попробую рассмотреть три различных варианта публикации виртуальных приложений App-V 5.0 и методы их объединения в группы:
1. С помощью серверов публикации;
2. С помощью SC 2012 SP1 CM;
3. В ручную, используя PowerShell.
Группы соединений виртуальных приложений необходимы для тех приложений, которые работают в связке (одно зависит от другого), т.е. для корректной работы им нужна единая файловая система и реестр. Если администратор желает максимально использовать App-V, который в свою очередь изолирует приложения от системы и друг друга, можно столкнуться с ситуацией когда эти приложения нужно как-то подружить.
Серверы сеансов Remote Desktop Services (RDS) - это многопользовательские среды, для которых, как правило, требуется максимально жёсткая настройка пользовательского окружения. Говоря простым языком, – чем у пользователей меньше отвлекающих "буцок", не имеющих прямого отношения к выполняемым ими задачам, – тем лучше и для администратора, и для них самих в конечном итоге. Здесь мы рассмотрим пример настройки некоторых элементов пользовательского интерфейса по следующим позициям:
- Отключаем отображение Favorites, Libraries и Network
- Скрываем излишние папки в профиле пользователя
- Отключаем мастер добавления сетевых расположений
- Скрываем локальные диски сервера
- Сворачиваем ленту при запуске Windows Explorer
- Включаем отображение расширений файлов
- Ограничиваем набор апплетов в Панели управления
- Настраиваем панель задач (TaskBar)
- Заменяем картинку пользователя по умолчанию
- Настраиваем стартовый экран Windows
- Создаём групповую политику переопределений для администраторов Читать далее...
В процессе тестирования конфигурации описанной в предыдущей статье выявлена странная закономерность в поведении работы высоко-доступного экземпляра RD Connection Broker (RDCB). Обнаружено, что если роль RDCB (в режиме High Availability) добавлена в развёртывании RDS более чем на три сервера (в нашем случае - на пяти серверах), то адекватно работают с общей базой данных RDCB не более трёх серверов, на которые раньше всего была развёрнута эта роль.
Ранее мы рассматривали пример построения фермы Remote Desktop Connection Broker (RDCB) на базе Windows Server 2008 R2. С выходом Windows Server 2012 технологии повышения доступности для служб RDS претерпели определённые изменения, в частности теперь для построения отказоустойчивой фермы RDCB не используются механизмы Windows Failover Cluster. В этой заметке мы попробуем рассмотреть процедуру создания новой фермы RDCB на базе Windows Server 2012 с применением Windows NLB, как средства повышения доступности и балансировки сетевой нагрузки для ролей RD Connection Broker и RD Web Access. После создания фермы RDCB выполним ряд настроек, которые позволят нам считать инфраструктуру RDS минимально подготовленной к использованию в соответствии со следующим планом:
- Среда исполнения
- Подготавливаем виртуальные сервера
- Создаём кластер NLB
- Подготавливаем SQL Server
- Устанавливаем роли Remote Desktop Services
- Создаём высоко-доступный RD Connection Broker
- Добавляем сервера в высоко-доступный RD Connection Broker
- Добавляем на сервера роль RD Web Access
- Создаём коллекцию сеансов – Session Collection
- Настраиваем цифровые сертификаты
- Настраиваем веб-узлы RD Web Access
- Настраиваем Roaming User Profiles и Folder Redirection
- Публикуем приложения RemoteApp
- Устанавливаем языковой пакет
- Настраиваем перенаправление печати
В некоторых ситуациях может потребоваться массовая замена свойств ярлыков. Например в каком-то сетевом каталоге расположено множество ярлыков разгруппированных по подкаталогам и какая-то часть этих ярлыков ссылается на некоторое приложение которое было перемещено в новое месторасположение. В нашем случае имеется несколько серверов RDS в ферме RD Connection Broker с перемещаемыми профилями пользователей, и пользователям со всех серверов RDS доступна общая сетевая папка с ярлыками, ссылающимися на кучу разных мелких бизнес-приложений (АРМ). Большая часть ярлыков ссылается на приложения App-V, для которых после перехода с версии App-V 4.6 на версию App-V 5.0 потребовалось изменить свойства этих ярлыков. Такая ситуация потребует от нас, как минимум, замену таких свойств ярлыков, как ссылка на объект запуска, рабочая папка и иконка приложения.
С выходом новой версии Microsoft Application Virtualization (App-V) 5.0 появился ряд улучшений и нововведений в этой технологии, которые всерьёз заставили задуматься об обновлении, особенно учитывая уже "набившие оскомину" проблемы с используемой нами до этого момента версии 4.6, в частности описанные в заметке SC 2012 Orchestrator — Режим обслуживания SCOM по расписанию. Планируя внедрение новой версии App-V, после ознакомления с материалами TechNet Library - Planning for High Availability with App-V 5.0 и KB2780309 - How to provide fault tolerance and load balancing in Microsoft App-V v5 возникло желание создать такую архитектуру, при которой серверные компоненты App-V имели бы дополнительную отказоустойчивость. Далее мы рассмотрим пошагово процесс создания такой конфигурации… Читать далее...
После перевода серверов виртуализации на Windows Server 2012 возникло желание использовать новый функционал Hyper-V - Shared Nothing Live Migration для хостов, не являющихся членами кластеров. Здесь я опишу практический пример действий, которые были выполнены для того, чтобы отделить трафик миграции от основного трафика управления хостом виртуализации. В рассматриваемом примере имеется два сервера виртуализации HP ProLiant DL380 G5 с дополнительно установленным двух-портовым гигабитным сетевым адаптером HP NC360T. Таким образом каждый сервер имеет по четыре гигабитных сетевых интерфейса, которые мы будем использовать в следующем порядке:
Здравствуйте, Easyme. Сохранить лицензионные ключи можно так: https://wiki.it-kb.ru/hewlett-packard/how-to-backup-and-restore-license-keys-of-storage-features-in-hp-zpar-7200-with-hpe-3par-os Восстановление ключей возможно, насколько я понимаю, только на СХД с тем же…
Здравствуйте, коллеги! Я приобрел старенький 3PAR 7400 с прошивкой 3.2.2 Паролей от него никаких нет. Снял с обеих нод их…
RSS - Записи
Последние комментарии