Хотя на первый взгляд, архитектура XenApp может показаться сложной в плане поддержки и обеспечения отказоустойчивости основных компонентов и всей платформы в целом. На самом деле, все проще чем кажется.
Если говорить о стандартных ролях Windows Server, таких как Active Directory и DNS, то здесь доступность достигается традиционной репликацией каталога и передачей зон на второстепенный или резервный сервер. Отказоустойчивость SQL-сервера (DataStore) обеспечивается кластеризацией. А постоянную доступность файлового сервера (AppHub) для узлов XenApp можно реализовать разместив копию профилей приложений на другом сервере и настроив DFS (Distributed File System). Все приведенные выше методики, давно известны и применяются повсеместно, не только с продуктами Citrix, по этому говорить об этом особо нечего.
Похожая ситуация и с серверными ролями от Citrix, веб-интерфейсом и Secure Gateway. Здесь для распределения нагрузки и обеспечения отказоустойчивости этих ролей предполагается использование входящих в состав Windows Server средств NLB (Network Load Balancing) или стороннего балансировщика, например NetScaler [1]. Естественно, это означает наличие как минимум двух серверов с этими ролями.
Немного интереснее ситуация со сборщиком данных (Data Collector). По умолчанию это первый сервер с ролью XenApp. Все последующие сервера добавленные в зону, так же могут выполнять эту функцию но делать этого не будут, пока основной сборщик данных функционирует. Но как только он станет недоступным, его функцию автоматически возьмет на себя сервер с наивысшим приоритетом в зоне. В общем, переживать по поводу сборщика данных при наличии нескольких серверов XenApp не стоит. Делегировать данную роль выделенному серверу нет ни какого смысла, т.к. на обслуживание 1000 серверов в зоне, сборщик данных задействует порядка 300 Мб ОЗУ. Единственное где может понадобиться внимание администратора – это установка приоритета серверам в зоне(рис №5).
Рис.№5. Установка приоритета серверам XenApp
Всего доступно четыре уровня приоритетов:
Most Preferred – Наиболее предпочтительный. Его имеет первый сервер в зоне. Он же по определению и является текущим сборщиком данных.
Preferred – предпочтительный. По умолчанию не имеет не один из серверов. Его может присвоить администратор. В случае выхода из строя основного сборщика данных, новый, в первую очередь будет выбран из серверов с этим приоритетом.
Default Preference – Предпочтение по умолчанию. Приоритет по умолчанию для всех серверов в зоне. Если сервера Preferred отсутствуют, то новый сборщик данных будет выбран из серверов с таким приоритетом.
Not Preferred – Не предпочтительный. По сути, отсутствие приоритета. Стоит присвоить серверам на которые не нужно возлагать роль сборщика данных. Например сервера с другими важными ролями. Стоит отметить, что в случае отказа всех серверов с другими приоритетами в зоне, он все равно будет обязан выполнять роль сборщика данных!
Еще запущенней ситуация с функцией XML Broker. Как уже говорилось, это одна из функций XML Service, которая в свою очередь присутствует и на каждом XenApp сервере. Получается, как и в случае со сборщиком данных, функцию брокера XML способен выполнять любой из серверов XenApp, если эта возможность не выключена на этапе подключения сервера к ферме. Но все не так радужно. При том, что брокер XML функционирует на каждом из серверов XenApp, задействован будет только тот который указан в настройках веб-интерфейса! И каких либо встроенных средств обеспечения доступности брокера XML или динамического изменения его адреса в настройках, нет. Эта жесткая привязка к конкретному брокеру, на мой взгляд является недочетом архитектуры. Единственный способ обеспечения доступности данной функции, который я вижу, это опять же NLB, который не совсем изящно смотрится для решения этой задачи.
Что касается тяжеловесов с ролью XenApp, то здесь все просто и прозрачно. В случае выхода из строя одного из серверов фермы, приложения пользователей работающих на этом сервере аварийно завершат работу. Но при их повторном запуске, роль веб-интерфейса, на сколько это возможно, равномерно распределит пользовательские подключения на оставшиеся сервера. По умолчанию, пользователи подключаются к разным серверам, но критерии распределения ресурсов, а так же их приделы тонко настраиваются c помощью правил.
[1] Обзор функционала NetScaler — http://habrahabr.ru/post/177329/
Помогла ли вам статья?
