Возникла задача использования High Availability (HA) службы SharedMemory с небольшим временем доступа, после небольшого анализа было принято решение остановиться на Microsoft AppFabric Caching Service. После некоторого количества экспериментов был выработан подход по установке в необходимой конфигурации, который описан ниже.
Задача
Установить HA AppFabric Caching Service Cluster, с отключенной безопасностью (production площадка находится в защищенном сегменте сети), хранилище конфигурации SQL Server (по рекомендации от MS для хранения HA конфигурации необходимо использовать SQL Cluster, что в принципе понятно, исходя из архитектуры сервиса), так же SQL сервер будет выполнять функции Lead Host Management. Если кому нужны подробности, то смотрим Lead Hosts and Cluster Management и High Availability.
Подготовка стенда
Для проведения установки был развернут стенд из 6 компьютеров, на базе VMWareWorkstation (Хост компьютер: Intel i5-2400 CPU@3.1 GHz, 32GB RAM Windows 7 Prof x64)
В gcgec.domain были созданы пользователи:
На GCG-SQL был установлен MS SQL Server 2008 R2, запускающийся под gcgec\sqlservice
Каждый узел кластера должен быть доступен для ping по dns имени. Если такого доступа нет, то необходимо, в настройках Firewall разрешить Inbound правила “File and Printer Sharing (Echo Request – ICMPv4-In)” и “File and Printer Sharing (Echo Request – ICMPv6-In)”
На узлах (ecn1.gcgec.domain - ecn3.gcgec.domain) пользователю gcgec\cacheservice даем права локального администратора (этого конечно много, и об этом нам сообщит конфигуратор AppFabric Cache, но разбираться точнее неохота), такие же права даются пользователю gcgec\domainuser (без этого он не сможет управлять кластером, ну вообщем, разбираться точно с правами лень)
Установка
Подготовка базы данных
На SQL сервере GCG-SQL создаем базу данных AppFabricCacheConfig. Пользователям gcgec\cacheservice и gcgec\domainuser даем права database_owner на созданную базу данных.
Установка AppFabric Caching Service
Производим установку программного обеспечения AppFabric Caching Service на узлах кластера (ecn1.gcgec.domain - ecn3.gcgec.domain).
Устанавливаемое программное обеспечение: AppFabric 1.1 и затем Cumulative update package 4
Установку производим из-под пользователя имеющего права локального администратора.
Установку производим без последующего запуска конфигурации (это мы проделам позже).
Далее процесс установки в картинках
Затем ставим Cumulative Update Package 4, там все просто, даже картинок делать не буду.
Создание кластера
Для создания кластера, последовательно производим конфигурацию AppFabric Caching Service на всех узлах кластера. Конфигурацию необходимо запускать из-под пользователя имеющего права локального администратора и права db_owner для базы созданной ранее (GCG-SQL.AppFabricCacheConfig). Для простоты используем пользователя gcgec\cacheservice.
Конфигурирование узла производится при помощи приложения конфигурации AppFabric
Первый узел (ecn1.gcgec.domain)
Далее картинки, с небольшими комментариями
Ну, вот и все, на всякий случай проверяем настройки Firewall
Последующие узлы (ecn2-3.gcgec.domain)
Действия аналогичны созданию первого узла, за исключение того, что эти узлы у нас не создают кластер, а подключаются к нему.
Все, кластер создан. Осталось его запустить и настроить под наши требования.
Установка рабочего места администратора (Windows 7)
Установка аналогична установке программного обеспечения на узлах кластера, за одним исключением, а именно выбор устанавливаемых продуктов
Запуск кластера
Запуск кластера будем производить с рабочего места администратора (gcgec\domainuser). Для работы с кластером запускаем PowerShell консоль (ВНИМАНИЕ Запуск только с правами администратора)
При первом запуске нас попросят разрешить исполнения скриптов, отвечаем Always run.
Сообщение об ошибке говорит, что консоль не смогла подключиться в конфигурации кластера (в вызове стоит Use-CacheCluster). Закрываем консоль и запускаем еще раз
Как видно, по умолчанию мы так и не подключаемся к кластеру, но использовав команду Connect-AFCacheClusterConfiguration (бывшая Use-CacheCluster) с указанием параметров -Provider и -ConnectionString мы подключились к кластеру и смогли запустить его командой Start-AFCacheCluster. Задача запуска кластера завершена, у нас есть рабочий кластер, осталось его настроить под наши параметры.
Но каждый раз набирать такую длинную команду подключения (ну или копировать) очень не хочется, поэтому внесем небольшие изменения в реестр прописав там значения по умолчанию (как это сделать не через реестр, я не нашел), путь в реестре: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppFabric\V1.0\Configuration
Запускаем консоль еще раз. Все запускается, без каких либо ошибок, ну и для проверки, что у нас есть нормальное подключение - останавливаем кластер, используя команду Stop-AFCacheCluster.
Все, рабочая станция администратора подготовлена для дальнейшей настройки кластера. Да и кластер как раз остановился, что бы можно было вносить изменения в его конфигурацию.
Конечно, если мы будем запускать консоль на одном из узлов, то все эти пляски c ConnectionString нам не нужны, узлы уже настроены и прекрасно знают, куда им нужно подключаться.
Изменение конфигурации
Еще раз вспоминаем задачу:
По умолчанию при установке в кластере уже создан именованный cache с именем default, его мы и будем настраивать.
Далее картинок не будет, будут просто выжимки из PowerShell и куски конфигурации.
Режим безопасности
Для начала изменим режим безопасности (Set-AFCacheClusterSecurity)
Указав в качестве значений: None
High Availability
Смотрим текущие параметры хоста (Get-AFCacheHostConfiguration), для примера - первого узла
Здесь нас не все устраивает, а именно: IsLeadHost = true, мы же планируем в качестве Lead manager использовать SQL, поэтому меняем это значение
Тоже самое повторяем и для остальных узлов (ecn2 и ecn3)
После этого, нам нужно отключить признак наличия lead host на уровне кластера, это можно сделать только через конфигурационный файл.
Экспортируем текущую конфигурацию кластера в файл (Export-AFCacheClusterConfiguration)
Как видим, что параметры узлов leadHost и параметры безопасности соответсвуют действиям, произведенным ранее.
Открываем файл в редакторе. Нам необходимо в тег <advancedProperties> добавить тег <partitionStoreConnectionSettings> указав, что мы работаем без использования leadHost (leadHostManagement="false")
Сохраняем файл и производим импорт настроек в хранилище конфигурации Cache cluster (команда Import-AFCacheClusterConfiguration)
Осталось включить режим HA на уровне cache
Смотрим текущие настройки cache
Необходимо изменить параметер Secondaries, установив его равным "1"
Все готово, запускаем кластер (команда Start-AFCacheCluster)
Кластер настроен в соответствии с нашими задачами и запущен. Все остальные настройки, а так же вопросы использования, находятся за рамками данного поста, ну может позже.
P.S. Все настройки можно было произвести через файл конфигурации, но хотелось показать два метода работы. В реальном окружении конечно удобнее произвести все настройки через конфигурационный файл, заранее подготовив его, что уменьшит время простоя сервиса.
Задача
Установить HA AppFabric Caching Service Cluster, с отключенной безопасностью (production площадка находится в защищенном сегменте сети), хранилище конфигурации SQL Server (по рекомендации от MS для хранения HA конфигурации необходимо использовать SQL Cluster, что в принципе понятно, исходя из архитектуры сервиса), так же SQL сервер будет выполнять функции Lead Host Management. Если кому нужны подробности, то смотрим Lead Hosts and Cluster Management и High Availability.
Подготовка стенда
Для проведения установки был развернут стенд из 6 компьютеров, на базе VMWareWorkstation (Хост компьютер: Intel i5-2400 CPU@3.1 GHz, 32GB RAM Windows 7 Prof x64)
- Active Directory domain controller (GCG-ADS.gcgec.domain@192.168.22.70): Windows Server 2008 R2 Enterprise edition 1GB RAM, 1 CPU, 1 Core per CPU.
- SQL Server (GCG-SQL.gcgec.domain@192.168.22.71): Windows Server 2008 R2 Enterprise edition 2GB RAM, 2 CPU, 2 Core per CPU
- Domain workstation (рабочее место администратора) (WIN7D.gcgec.domain@192.168.22.75): Windows 7 Professional
- Cache cluster node №1 (ECN1.gcgec.domain@192.168.22.81) - Windows Server 2008 R2 Enterprise edition 4GB RAM, 2 CPU, 2 Core per CPU
- Cache cluster node №2 (ECN1.gcgec.domain@192.168.22.82) - Windows Server 2008 R2 Enterprise edition 4GB RAM, 2 CPU, 2 Core per CPU
- Cache cluster node №3 (ECN1.gcgec.domain@192.168.22.83) - Windows Server 2008 R2 Enterprise edition 4GB RAM, 2 CPU, 2 Core per CPU
В gcgec.domain были созданы пользователи:
- Managed Service Accounts
- CacheService (gcgec\cacheservice) – пользователь, под которым запускается сервис AppFabric Cache на узлах
- SQLService (gcgec\sqlservice) – пользователь, под которым запускаются службы SQL Server
- Users
- domainuser (gcgec\domainuser) – будет использоваться как администратор cache
На GCG-SQL был установлен MS SQL Server 2008 R2, запускающийся под gcgec\sqlservice
Каждый узел кластера должен быть доступен для ping по dns имени. Если такого доступа нет, то необходимо, в настройках Firewall разрешить Inbound правила “File and Printer Sharing (Echo Request – ICMPv4-In)” и “File and Printer Sharing (Echo Request – ICMPv6-In)”
На узлах (ecn1.gcgec.domain - ecn3.gcgec.domain) пользователю gcgec\cacheservice даем права локального администратора (этого конечно много, и об этом нам сообщит конфигуратор AppFabric Cache, но разбираться точнее неохота), такие же права даются пользователю gcgec\domainuser (без этого он не сможет управлять кластером, ну вообщем, разбираться точно с правами лень)
Установка
Подготовка базы данных
На SQL сервере GCG-SQL создаем базу данных AppFabricCacheConfig. Пользователям gcgec\cacheservice и gcgec\domainuser даем права database_owner на созданную базу данных.
Установка AppFabric Caching Service
Производим установку программного обеспечения AppFabric Caching Service на узлах кластера (ecn1.gcgec.domain - ecn3.gcgec.domain).
Устанавливаемое программное обеспечение: AppFabric 1.1 и затем Cumulative update package 4
Установку производим из-под пользователя имеющего права локального администратора.
Установку производим без последующего запуска конфигурации (это мы проделам позже).
Далее процесс установки в картинках
 |
| Лицензионное соглашение |
 |
| Ну, тут, как хотите, если не жалко делимся |
 |
| Соглашаемся на установку обновлений |
 |
| Выбираем устанавливаемые продукты |
 |
| Подтверждаем устанавливаемые продукты |
 |
| Результаты установки. Здесь надо отказаться от запуска конфигурирования. |
Затем ставим Cumulative Update Package 4, там все просто, даже картинок делать не буду.
Создание кластера
Для создания кластера, последовательно производим конфигурацию AppFabric Caching Service на всех узлах кластера. Конфигурацию необходимо запускать из-под пользователя имеющего права локального администратора и права db_owner для базы созданной ранее (GCG-SQL.AppFabricCacheConfig). Для простоты используем пользователя gcgec\cacheservice.
Конфигурирование узла производится при помощи приложения конфигурации AppFabric
Первый узел (ecn1.gcgec.domain)
Далее картинки, с небольшими комментариями
 |
| Каждый решает для себя. |
 |
| Включаем режим конфигурации и изменяем пользователя |
 |
| Нас предупреждают, что у пользователя много прав, не обращаем внимания и жмем Yes |
 |
| Конфигуратор любезно дает нашему пользователю дополнительные права |
 |
| После установки пользователя, выбираем провайдера хранения конфигурации (SQL) и настраиваем его, указывая имя сервера и наименование базы данных. Создание базы данных отключено, т.к. она у нас уже есть. |
 |
| Сообщаем, что это у нас первый узел кластера (New cluster) и выбираем размер кластера |
 |
| Отмечаем необходимость создания исключений в Firewall |
Последующие узлы (ecn2-3.gcgec.domain)
Действия аналогичны созданию первого узла, за исключение того, что эти узлы у нас не создают кластер, а подключаются к нему.
Все, кластер создан. Осталось его запустить и настроить под наши требования.
Установка рабочего места администратора (Windows 7)
Установка аналогична установке программного обеспечения на узлах кластера, за одним исключением, а именно выбор устанавливаемых продуктов
Запуск кластера
Запуск кластера будем производить с рабочего места администратора (gcgec\domainuser). Для работы с кластером запускаем PowerShell консоль (ВНИМАНИЕ Запуск только с правами администратора)
При первом запуске нас попросят разрешить исполнения скриптов, отвечаем Always run.
Сообщение об ошибке говорит, что консоль не смогла подключиться в конфигурации кластера (в вызове стоит Use-CacheCluster). Закрываем консоль и запускаем еще раз
Как видно, по умолчанию мы так и не подключаемся к кластеру, но использовав команду Connect-AFCacheClusterConfiguration (бывшая Use-CacheCluster) с указанием параметров -Provider и -ConnectionString мы подключились к кластеру и смогли запустить его командой Start-AFCacheCluster. Задача запуска кластера завершена, у нас есть рабочий кластер, осталось его настроить под наши параметры.
Но каждый раз набирать такую длинную команду подключения (ну или копировать) очень не хочется, поэтому внесем небольшие изменения в реестр прописав там значения по умолчанию (как это сделать не через реестр, я не нашел), путь в реестре: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AppFabric\V1.0\Configuration
Запускаем консоль еще раз. Все запускается, без каких либо ошибок, ну и для проверки, что у нас есть нормальное подключение - останавливаем кластер, используя команду Stop-AFCacheCluster.
Все, рабочая станция администратора подготовлена для дальнейшей настройки кластера. Да и кластер как раз остановился, что бы можно было вносить изменения в его конфигурацию.
Конечно, если мы будем запускать консоль на одном из узлов, то все эти пляски c ConnectionString нам не нужны, узлы уже настроены и прекрасно знают, куда им нужно подключаться.
Изменение конфигурации
Еще раз вспоминаем задачу:
- HA AppFabric Caching Service Cluster
- Безопасность отключена
По умолчанию при установке в кластере уже создан именованный cache с именем default, его мы и будем настраивать.
Далее картинок не будет, будут просто выжимки из PowerShell и куски конфигурации.
Режим безопасности
Для начала изменим режим безопасности (Set-AFCacheClusterSecurity)
Указав в качестве значений: None
High Availability
Смотрим текущие параметры хоста (Get-AFCacheHostConfiguration), для примера - первого узла
Здесь нас не все устраивает, а именно: IsLeadHost = true, мы же планируем в качестве Lead manager использовать SQL, поэтому меняем это значение
Тоже самое повторяем и для остальных узлов (ecn2 и ecn3)
После этого, нам нужно отключить признак наличия lead host на уровне кластера, это можно сделать только через конфигурационный файл.
Экспортируем текущую конфигурацию кластера в файл (Export-AFCacheClusterConfiguration)
Как видим, что параметры узлов leadHost и параметры безопасности соответсвуют действиям, произведенным ранее.
Открываем файл в редакторе. Нам необходимо в тег <advancedProperties> добавить тег <partitionStoreConnectionSettings> указав, что мы работаем без использования leadHost (leadHostManagement="false")
Сохраняем файл и производим импорт настроек в хранилище конфигурации Cache cluster (команда Import-AFCacheClusterConfiguration)
Осталось включить режим HA на уровне cache
Смотрим текущие настройки cache
Необходимо изменить параметер Secondaries, установив его равным "1"
Все готово, запускаем кластер (команда Start-AFCacheCluster)
Кластер настроен в соответствии с нашими задачами и запущен. Все остальные настройки, а так же вопросы использования, находятся за рамками данного поста, ну может позже.
P.S. Все настройки можно было произвести через файл конфигурации, но хотелось показать два метода работы. В реальном окружении конечно удобнее произвести все настройки через конфигурационный файл, заранее подготовив его, что уменьшит время простоя сервиса.
Комментариев нет :
Отправить комментарий