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

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

Кластерная архитектура

Существует несколько десятков различных кластерных конфигураций, но принято выделять две модели кластеров по принципу взаимодействия узлов с общими подсистемами хранения данных:
- shared nothing model - модель, не разделяющая доступа или не имеющая общих подсистем.
- shared device model - модель с разделяемым (одновременным) доступом к устройствам общих подсистем хранения данных;

Кластеры без общих подсистем хранения данных

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

В качестве примера возьмем кластер, построенный по технологии Network Load Balancing - балансировки сетевой нагрузки (NLB), не имеющий общих подсистем хранения данных. Технология была изначально предложена компанией Valence Research, а затем права на нее приобрела Microsoft. Сейчас это решение входит в состав ОС MS Windows 2000 Advanced Server и Datacenter Server, а так-же в новый продукт Microsoft Application Center 2000. Для работы MS NLB необходим домен Win-dows 2000 с работоспособной службой DNS.

Кластер NLB формируется простым объединением узлов по внутрикластерному каналу. Кро-ме еще одного сетевого адаптера для организации этого межузлового канала, дополнительного обо-рудования узлам не требуется. Разумеется, что узлы уже имеют сетевые адаптеры для работы в кли-ентской сети.

Технология NLB предназначена для балансировки IP-трафика и может быть использована для повышения отказоустойчивости и производительности IP-приложений. Распределение запросов кли-ентов по разным узлам повышает скорость обработки запросов, а за счет автоматического определе-ния отказов узлов и перераспределения запросов между оставшимися узлами происходит повышение отказоустойчивости системы. Для распараллеливания запросов на каждом узле между стеком TCP/IP и драйвером сетевого адаптера устанавливается драйвер NLB. Никаких внешних по отношению к кластеру диспетчеров по распределению запросов не требуется. Для повышения производительности и снижения удельной узловой нагрузки, кластер можно расширять до 32 узлов.

Клиентам для доступа к кластеру NLB предоставляется один или несколько виртуальных IP-адресов, и клиенты считают, что их запросы попадают на один сервер. На каждом узле выполняется своя копия IP-приложения, причем эти копии "не знают" о существовании друг друга.

Технология NLB применима для приложений использующих протоколы стека TCP/IP и вы-полняющих клиентские запросы на чтение данных с кластера. Например, на таком кластере может быть реализована служба Web, служба терминалов или передача потокового мультимедиа. При обра-ботке клиентских запросов, которые занимаются модификацией данных, возникает проблема син-хронизации копий данных, расположенных на разных узлах. Одним из способов решения этой про-блемы может быть установка дополнительного ПО репликации локальных данных на узлах, однако эффективнее, особенно при большом количестве узлов, использование внешних по отношению к NLB кластеру устройств хранения данных.

Кластеры с общими подсистемами хранения данных

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

Кластеры с разделением доступа к общей дисковой подсистеме

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

Чтобы избежать конфликтов и потерь данных при доступе нескольких узлов к одной и той же файловой системе применяется Distributed Lock Manager - распределенный менеджер блокировок (DLM). Он координирует действия узлов при обращении к файлам, блокируя их одновременные модификации и управляя очередностью доступа. Так как операции по распределению доступа к файловым системам создают дополнительную нагрузку на кластер, реализация эффективного, не создающего задержек DLM, представляет собой исключительно сложную задачу. Из-за сложности реализации кластеры с разделяемым доступом к общей дисковой подсистеме достаточно дороги, но имеют целый ряд преимуществ по сравнению с системами, построенными по модели без разделения доступа.

В качестве примера кластера с разделением доступа к общей дисковой подсистеме возьмем Oracle9i Real Application Clusters (ORAC) из Enterprise версии СУБД компании Oracle. Для Intel плат-формы доступны версии этого продукта под ОС Linux и MS Windows NT/2000/XP Pro.

ORAC не использует службы кластеризации имеющиеся в некоторых версиях этих ОС, пол-ностью заменяя их своими средствами. На разделах дисков общей подсистемы используется своя оригинальная файловая система - Oracle Cluster File System (OCFS). Инсталляция организована так, что после установки Oracle9i на один из узлов, ПО СУБД автоматически устанавливается и на другие узлы кластера.

Для эффективного разделения доступа к общей дисковой подсистеме используется передовая технология общей кэш-памяти узлов - Cache Fusion, позволяющая значительно ускорить процесс со-гласованного доступа к общим данным. В основе ее лежит идея использовать межузловой канал - interconnect не только для обмена сообщениями о состоянии узлов, но и для обмена данными, кэши-руемыми при обращении к дискам. Применение технологии Virtual Interface Architecture (VIA) - стан-дартизированных протоколов обмена Intel платформы для каналов "память-память", позволяет передавать через interconnect блоки данных, не используя операций на уровне ядра ОС. Это сохраня-ет процессорные ресурсы и не замедляет работу приложений на узлах. Технология VIA используется и для обмена сообщений между узлами.

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

Традиционно в кластерах с разделением доступа к общим дискам для выяснения того, не за-нят ли соответствующий блок данных в обработке на другом узле был необходим целый цикл опера-ций обмена узлов кластера с дисковой подсистемой, т.к. согласование выполнялось через нее. В Cache Fusion согласование доступа узлов к блокам данных выполняется значительно быстрее за счет того, что информация о блоках требующих координации общего доступа может быть получена узла-ми без дисковых операций - через interconnect. Несмотря на использование алгоритмов сокращающих межузловой обмен, для организации interconnect'а желательно применять высокопроизводительные адаптеры, например Gigabit Ethernet.

Архитектура, при которой каждый узел имеет доступ ко всем данным общей дисковой под-системы, позволяет ускорить процесс переноса приложений с аварийного узла на работоспособный узел, т.к. не нужно тратить время на перезакрепление за приложением дисковых ресурсов. То же ка-сается и масштабируемости, когда добавление дополнительного узла не потребует перераспределе-ния общего дискового пространства, и часть приложений будет переведена на него в горячем режиме. При переключении приложений обеспечивается оптимальный баланс загрузки узлов. ORAC отлича-ется от других известных кластерных решений тем, что он является кластером именно приложений. Это в первую очередь означает, что он умеет распределить работу приложения по нескольким узлам кластера. Фактически, компания Oracle сумела создать такое кластерное решение, которое не требует от приложений никаких специальных операций по переключению между узлами кластера. Приложе-ния не надо переделывать, чтобы они заранее настраивались на работу в кластере, при этом они по-лучают реальное увеличение производительности по сравнению с работой на одиночном сервере.

ORAC полностью оправдывает свое название - настоящий кластер приложения, и обладает всеми преимуществами кластерных технологий. Сам факт того, что сегодня на недорогой Intel плат-форме с использованием распространенных ОС предлагаются столь серьезные кластерные решения говорит о готовности производителей ориентироваться на массового потребителя, о зрелости Intel платформы и стремительном развитии самих кластерных технологий.

Кластеры, не разделяющие доступ к общей дисковой подсистеме

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

В качестве примера возьмем кластер, построенный на базе службы кластеров компании Mi-crosoft - MSCS входящей в комплект ОС MS Windows 2000 Advanced Server и Datacenter Server. MSCS создана в виде отдельного изолированного набора компонентов, которые работают совместно с ОС на каждом узле. Такое решение позволяет избежать сложных зависимостей в последовательно-сти работы, возникающих между службой кластеров и операционной системой. Для осуществления кластеризации операционная система должна обеспечивать поддержку динамического создания и удаления сетевых имен и адресов, а файловая система должна обеспечивать закрытие открытых фай-лов при отсоединении дисков. Именно это и реализовано в ОС MS Windows 2000 Advanced Server и Datacenter Server. Для установки MSCS требуется домен Windows 2000 с работоспособной службой DNS.

Чтобы не использовать DLM и, тем самым, значительно удешевить кластерную реализацию, надо избежать ситуаций одновременного доступа узлов к одним и тем же файловым системам. Это можно сделать, заранее определив узлов-владельцев для отдельных дисков общей дисковой подсис-темы. К отдельному диску в любой момент времени доступ надо разрешить только одному узлу - его владельцу. Таким образом, разделения доступа к файловым системам не происходит, так как каждый узел работает только со своей частью общей дисковой подсистемы. В случае отказа узла, его диск, по определенным заранее правилам, может быть передан во владение другому узлу. Так работает боль-шинство предлагаемых на рынке систем этого класса, хотя в разных кластерных реализациях имеют-ся и свои особенности. Например, продукт NonStop Clusters компании Santa Cruz Operation для ОС UnixWare позволяет узлу получить доступ к непринадлежащим ему дисковым данным косвенным путем, через узел-владелец.

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

Казалось бы, если физический диск разбить на разделы, то в принципе можно раздать во вла-дение узлам не целые диски, а отдельные разделы. К сожалению, разделы одного диска могут пере-даваться другим узлам только вместе с самим диском, т.е. вместе с остальными его разделами. Ми-нимальная часть общих дисков позволяющая организовать смену узла-владельца - это отдельный фи-зический диск. Это связано с тем, что команды шины дисковой подсистемы, например Reserve или Release, предназначены для устройства в целом и шина не может работать с частью устройства. При использовании в общей дисковой подсистеме аппаратной RAID технологии, минимальной переда-ваемой частью будет один из логических RAID томов. В терминологии принятой в MSCS такой том тоже называется физический диск. Однако, используя возможности RAID контроллеров можно обой-ти это ограничение. Дело в том, что большинство SCSI адаптеров представляют logical unit number (LUN) - логический номер устройства, как идентификатор отдельного физического SCSI устройства, поэтому если RAID контроллер умеет, разбив RAID том на части назначить этим частям отдельные LUN'ы, то можно предоставить узлам части логического RAID тома как виртуальные физические диски. Это особенно выгодно при постоянном росте объемов самих накопителей на жестких дисках предлагаемых на рынке (доступны уже не десятки, а сотни Гб).

Microsoft рекомендует выделять отдельный физический диск для размещения специального кластерного ресурса - кворума (quorum resource). Ресурс кворума создается при формировании кла-стера и хранит единую базу данных настроек кластера в форме журналов восстановления. Владель-цем ресурса кворума является узел первым получивший права на этот ресурс. Арбитраж доступа к дисковому ресурсу осуществляется через SCSI протокол и команды захвата и освобождения устрой-ства. Узел может присоединиться к существующему кластеру, только если он поддерживает связь с узлом, контролирующим ресурс кворума. При присоединении к кластеру узел получает собственную локальную копию базы данных настроек кластера. При потере связи между узлами все дисковые ре-сурсы переходят к владельцу ресурса кворума. Если на одном физическом диске вместе с кворумом будут размещены дисковые ресурсы приложения одного из узлов, то возможна ситуация, когда из-за интенсивной работы приложения с диском, будут происходить задержки при обращении узлов к кво-руму. Это может приводить к ложным срабатываниям механизма переназначения ресурсов, т.к., не получая доступа к журналам кворума, узел "решит", что произошла потеря связи с общей дисковой подсистемой и остановит свои кластерные службы, чтобы его приложения были переданы другим узлам. Несмотря на то, что объем базы данных кворума обычно не превышает 100 мегабайт, Microsoft рекомендует использовать для него диск объемом не менее 500 мегабайт. Это связано с тем, что фай-ловая система NTFS неэффективно работает на разделах меньшего объема, а все физические диски общей дисковой подсистемы должны быть определены как основные - basic (не динамические) и должны быть отформатированы под NTFS.

Ресурсами кластера являются все компоненты, которыми управляет служба кластеров, а не только логические диски. Это может быть и виртуальный IP адрес, сетевая служба, диск, очередь пе-чати и т.д. Название ресурс относится к аппаратным и программным компонентам в пределах класте-ра, которыми управляет служба кластеров. Инструментальным механизмом, который служба класте-ров предлагает для управления ресурсами, являются библиотеки ресурсов. Библиотеки ресурсов за-дают абстрактные определения ресурсов, интерфейсы связи и операции управления.

На самом деле, служба кластеров управляет не единичными ресурсами, а группами. Группа ресурсов - это набор ресурсов, которые управляются как одна логическая единица. Когда служба кластеров выполняет операцию над группой ресурсов, например перенос их на другой узел, результаты операции сказываются на каждом ресурсе группы. Именно группа ресурсов в каждый момент времени может принадлежать только одному узлу. Ни в какой момент разные серверы кла-стера не могут владеть различными ресурсами одной и той же группы. Группа создается из логически связанных ресурсов, так чтобы она содержала все элементы, необходимые конкретному серверу приложений и клиенту для успешной работы приложения. Кроме того, каждая группа имеет имя и адрес сетевой службы, чтобы клиенты сети могли подключаться к службе, обеспечиваемой данной группой ресурсов. Группа, в которой содержатся ресурсы "IP адрес" и "Сетевое имя" называется вир-туальным сервером. В случае отказа группа ресурсов может быть восстановлена или целиком перемещена с отказавшего узла на работоспособный.

Для групп и ресурсов определены следующие состояния:
- online - рабочее состояние;
- offline - нерабочее состояние;
- pending online/offline - приведение в рабочее/нерабочее состояние;
- failover - преодоление сбоя - процесс миграции ресурса или группы от недоступного узла к доступному;
- failback - восстановление после сбоя - процесс возвращения полномочий на ресурсы узлу, вновь ставшему доступным;
- failed - состояние сбоя;

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

В свойствах групп и ресурсов определяется и ряд других параметров:
- restart policy - правила рестарта;
- failover policy - правила преодоления сбоя;

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

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

Ограничения Microsoft Cluster Servicе:
Узлы кластера должны быть членом одного Windows домена или быть контроллерами доме-на. Хотя это и возможно, не рекомендуется делать кластерные узлы контроллерами домена (см. Microsoft Knowledge Base Article - Q281662), т.к. настройка узлов как контроллеров до-мена может повлиять на производительность приложений при большой загрузке. При на-стройке узлов как членов домена, функционирование кластер сервиса будет зависеть от дос-тупности контроллера домена, поэтому нужно обеспечить повышенную доступность кон-троллеров домена. - Минимальный мигрируемый дисковый ресурс - диск целиком со всеми его разделами.
- Необходим постоянно доступный сервис разрешения сетевых имен (DNS или WINS).
- Не поддерживаются динамические диски и тома. Поддерживаются только базовые разделы, форматированные под NTFS.
- Нельзя создавать программные RAID разделы.
- Большое количество ресурсов может негативно сказаться на производительности ввиду не-обходимости постоянного мониторинга их состояния.
- На кластерных дисках нельзя использовать шифрованную файловую систему.
- Все узлы кластера должны быть в одной IP сети.
- Кластер на базе MSCS под ОС MS Windows 2000 Advanced Server может поддерживать не более двух узлов, под ОС MS Windows 2000 Datacenter Server не более четырех. В качестве узлов могут выступать серверы самой различной конфигурации, причем Windows 2000 Advanced Server поддерживает до 8 Гбайт оперативной памяти на узле, а Windows 2000 Datacenter - до 64 Гбайт. В новой ОС MS Windows Server 2003 возможности кластеризации были расширены. Так версии Enterprise Edition и Datacenter Edition поддерживают до 8 узлов в кластере, 32 ГБ и 64 ГБ оперативной памяти соответственно.

MSCS поддерживает только режим работы без разделения доступа к общей дисковой подсис-теме, однако если кластеризуемое приложение предоставит свою собственную DLM, то на базе MSCS можно построить и кластер с разделением доступа к общей дисковой подсистеме.

Дополнительная информация доступна на сайте Кластерные технологии Microsoft. Подробное описание MSCS на русском языке доступно в виде файла в формате MS Word. Хорошая подборка ссылок на ресурсы посвященные MSCS http://www.nwnetworks.com/mscslinks.htm.

Приложения

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

Все приложения можно условно разделить на истинно кластерные и некластерные. Истинно кластерное приложение способно при работе через Server Cluster API взаимодействовать с программ-ной средой кластера. Кластеру оно представляется специальными и известными типами кластерных ресурсов. Именно такие приложения наиболее эффективны в кластерной среде. В качестве примеров истинно кластерных приложений можно привести пакеты Microsoft Exchange Server 2000 и Microsoft SQL Server 2000 в их Enterprise версиях. Кластер управляет работой базовых служб Ms Exchange Server 2000 Enterprise Edition через такие типы ресурсов как Information Store, Message Transfer Agent, Routing Service и System Attendant. Также кластеризуются и службы в Ms SQL Server 2000 Enterprise Edition через ресурсы SQL Server, SQL Server Agent, Microsoft Search Service Instance и Microsoft Dis-tributed Transaction Coordinator (MSDTC). Также истинными кластерными являются файловые служ-бы и службы печати. Для них в MSCS предназначены кластерные ресурсы типа File Share и Print Spooler.

Некластерные приложения изначально не предназначены для работы в кластерной среде. Они ничего "не знают" о том, запущены ли они в кластерной системе или на отдельном сервере. Такие приложения не могут взаимодействовать с объектами кластера и менять свое "поведение" получая информацию от кластера. Поэтому они не способны выполнить, например, команду инициализации, что бывает необходимо для поддержания доступности приложения в кластерной среде. Таких прило-жений большинство, т.к. сюда относятся и все старые приложения. Для работы с некластерными приложениями в MSCS предусмотрены так называемые "общие" ресурсы - Generic Application и Ge-neric Service. Эти типы кластерных ресурсов позволяют выполнять лишь простейшие операции по обнаружению отказов в работе некластерных приложений и их завершению. Если приложение ус-тойчиво работает с использованием этих типов ресурсов, то нет необходимости дорабатывать его до истинно кластерного. Но, это возможно не всегда. Минимальным требованием для некластерных приложений при использовании "общих" ресурсов является возможность сохранения данных прило-жения в конфигурируемом месте. В случае если приложение работает в кластерной среде неустойчи-во, т.е. рестарт при переходе с узла на узел происходит некорректно, то единственной возможностью организации работы такого приложения в кластере является его доработка до истинно кластерного.

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

Оборудование и аппаратная реализация кластеров

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

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

Подсистемы внутрикластерных коммуникаций строятся аналогично обычной локальной сети работающей по стандарту Ethernet на витой паре. В каждый узел требуется установить стандартный Ethernet адаптер, и если в кластере только два узла, то для организации межузлового канала, доста-точно перекрестного (crossover) кабеля. В случае трех и более узлов, для создания внутрикластерной сети потребуется концентратор или коммутатор. Требования по производительности адаптеров опре-деляет конкретная реализация системы. Например, для кластера MSCS вполне подойдет Fast Ethernet адаптер, а для ORAC лучше использовать адаптеры Gigabit Ethernet. Выбор концентратора в качестве активного сетевого оборудования оправдан при построении кластера, не разделяющего доступ к об-щим дискам, так как при этом взаимодействие узлов обычно осуществляется по схеме многие к од-ному. Мы не будем рассматривать закрытые решения разных производителей, т.к. именно возмож-ность использования стандартного недорогого оборудования делает кластеры доступными.

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

Общая дисковая подсистема кластера обычно строится на базе избыточной RAID технологии, с использованием отказоустойчивого уровня RAID (RAID 0 или 7 отказоустойчивости не обеспечи-вают). При использовании RAID в дисковой подсистеме имеет смысл предусмотреть возможность горячей замены дисков, для чего разместить их в специальных съемных картриджах (removable rack). Количество и объем дисков общей подсистемы определяется исходя из применяемого уровня RAID и особенностей конкретной кластерной архитектуры. Так при построении кластера, не разделяющего доступ к общим дискам, необходимо учитывать распределение дисков или RAID томов по узлам кла-стера.

========

:filecheck

if exist e:\upload\file.txt goto actionfile

sleep 100

goto filecheck

:actionfile

...

========

Данный командный файл каждые 100 секунд проверяет наличие файла file.txt

Программа sleep.exe содержится в ресурс ките, то есть сам ресурс кит тоже должен быть установлен.

Андрей Харченко

*****