Рекомендации по миграции SBC

Поскольку проект SBC оказывает довольно большое влияние на организацию и инфраструктуру, я лично считаю, что это один из самых сложных проектов. После (бесконечных) обсуждений дизайна и технических препятствий на этапе сборки начнутся самые важные и сложные процессы! Как мы можем плавно перевести пользователей на новую инфраструктуру? В этой статье будет описано несколько сценариев.

Текущая ситуация и новая ситуация

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

Поскольку существует так много возможных сценариев, невозможно написать стратегию миграции «Всегда успешная». Я опишу несколько возможностей; выберите то, что вы можете использовать в своей среде, объедините их и создайте собственный идеальный сценарий миграции.

Переход на SBC от традиционной инфраструктуры толстых клиентов

Все больше и больше компаний принимают концепцию SBC для представления приложений конечным пользователям. Сценарии миграции не зависят от способа введения SBC. (Почти) все приложения представлены через SBC (через полный рабочий стол) или только несколько приложений (используя опубликованные приложения)?

На опубликованный рабочий стол

При использовании почти всех приложений через SBC рекомендуется публиковать полный рабочий стол, потому что пользовательский опыт почти такой же, как при локальной работе на рабочей станции. Самая большая проблема может заключаться в том, что настройки пользователей теперь хранятся в профиле на основе Windows XP (или более ранней версии). На самом деле не рекомендуется использовать их на одном из ваших терминальных серверов. Многие компании просто начинают с нового профиля (где пользователю нужно снова настроить свои параметры), но методика, уже описанная в статье «Миграция пользовательских настроек с помощью FPK», также является передовой практикой для такого рода миграции.

Предлагая полноценный рабочий стол, большинство пользователей избавляются от необходимости в толстом клиенте. Вам следует подумать об использовании тонких клиентов или о преобразовании существующих толстых клиентов в тонкие клиенты. Хотя это можно сделать с помощью «обычной» установочной базы Windows, лучше всего использовать управляемое решение на базе Linux, такое как 2X ThinClientServer, MultiFrame или аналогичные продукты. В настоящее время с Citrix Presentation Server веб-интерфейс используется для представления приложений/рабочего стола конечному пользователю. Самым большим преимуществом по сравнению с традиционным PN-клиентом является централизованное управление конфигурацией, недостатком которого является необходимость в дополнительном сервере (компонентах).

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

К опубликованным приложениям

Когда только набор вашего портфолио приложений предоставляется конечному пользователю через службы терминалов, лучше всего использовать опубликованные приложения, которые беспрепятственно представлены на толстых клиентах. Здесь также можно рассмотреть возможность сохранения пользовательских настроек для этих приложений в инфраструктуре SBC по мере необходимости. Представление приложений в основном будет осуществляться с помощью Citrix PNAgent (или аналогичных компонентов в других продуктах), который интегрирует приложения в локальное меню «Пуск» и/или папку на рабочем столе. Поскольку в основном используются все те же толстые клиенты, на всех рабочих станциях должен быть развернут только PNAgent (и не забывайте, что конфигурация PN Agent на сервере доступна со всех клиентов).

Если ваша инфраструктура SBC основана только на сервере терминалов Windows 2003, рекомендуется использовать аппаратный балансировщик нагрузки или балансировщик нагрузки стороннего программного обеспечения вместо Microsoft Network Load Balancer.

Переход от опубликованного приложения к опубликованным рабочим столам

Когда в вашей инфраструктуре уже размещены опубликованные приложения, но следующим шагом является переход к опубликованному рабочему столу, переход сравним с переходом от инфраструктуры толстого клиента к полному рабочему столу SBC. Дополнительными соображениями являются необходимое пространство (хранилище) для размещения (перемещаемых) профилей и ферма, на которой будут размещаться опубликованные рабочие столы. Если это новая ферма, см. раздел ниже «Миграция на новую ферму Citrix». Также в этот метод вписывается сценарий перехода с толстых клиентов на тонкие клиенты. Рекомендуется развертывать полноценный рабочий стол на тонких клиентах вместо опубликованных приложений. Основная причина заключается в том, что тонкий клиент не предлагает каких-либо локальных ресурсов или программ, которые используются конечными пользователями, и пользовательский интерфейс аналогичен полноценному рабочему столу.

Переход на новую версию сервера терминалов Windows

Обычно каждые три-четыре года Microsoft выпускает новую версию своего серверного продукта. Через некоторое время серверы должны быть обновлены этой новой версией. Прежде всего, рекомендуется полностью перестроить сервер, а не обновлять операционную систему. При внедрении новой операционной системы основными проблемами являются (опять же) профили. Хотя иногда это возможно, настоятельно рекомендуется не использовать профили других версий операционной системы. Опять же, настройки могут быть сохранены путем переноса профилей пользователей. Когда меняется только версия операционной системы и чаще всего используется Citrix Presentation Server, серверы остаются в одной ферме. Можно определить временные профили или расположение профилей (используя конфигурацию профиля GPO для каждой организационной единицы) или реализовать гибридные профили. Лучше всего обновлять бункер (или группу с балансировкой нагрузки) за один раз.

Переход на новую версию Citrix Presentation Server

Citrix также выпускает новые версии Citrix Presentation Server. Технически Citrix предлагает возможность добавлять новые версии продукта в текущую ферму (см. статью базы знаний 1068832). Это самая простая миграция, поскольку для клиентов не нужно вносить никаких изменений в конфигурацию. Его можно рассматривать как альтернативную реализацию представления приложений при использовании «обычного» Program Neighborhood (см. следующий абзац).

Но в большинстве случаев лучше начать с новой Citrix Farm. Таким образом, среда может начинаться с чистого состояния, а дизайн может отражать текущие потребности вашей компании/клиента.

Миграция на новую ферму Citrix

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

Тонкие клиенты

При использовании тонких клиентов миграция может быть выполнена довольно легко. Почти каждое решение для тонких клиентов поддерживает несколько ферм. Таким образом, вы можете отобразить два значка на тонком клиенте на этапах миграции и отключить функцию автоматического запуска. Первый значок указывает на текущую ферму, а второй — на новую ферму. Используйте новую группу Active Directory для назначения пользователей в новую ферму, чтобы неперенесенные пользователи не могли запускать новый рабочий стол. Когда все пользователи/местоположения будут перенесены, вы можете удалить первый значок и снова включить функцию автоматического запуска.

Толстые клиенты

При использовании опубликованных приложений на толстых клиентах стратегия миграции должна быть упрощена за счет использования PNAgent. PNAgent поддерживает несколько ферм. При использовании новых групп Active Directory для приложений на новой ферме Citrix только перенесенный пользователь видит новые приложения (удалите пользователей из старых групп, чтобы они не видели «старые» приложения), и наоборот.

Если вы используете Program Neighborhood, вы можете использовать только что выпущенный шаблон ADM или распространять клиентам новые INI-файлы. Но рекомендуется использовать PNAgent для опубликованных приложений. Когда вы решите «обновить» PNAgent, удалите текущую конфигурацию в клиенте PN, чтобы пользователей не беспокоили старые и/или двойные ссылки на приложения.

Вывод

В этой статье описаны несколько сценариев, а также рекомендации и рекомендации. Как описано ранее, выберите то, что вы можете использовать в своей среде, объедините их и создайте собственный идеальный сценарий миграции.