Для выполнения выше поставленной задачи нам удалось выбить себе следующее оборудование:

1. Сервер HP ProLiant DL 560 Gen8 4x Xeon 8 core 64 GB RAM 2 шт.
2. SAS Хранилище HP P2000 на 24 2,5» дисков 1 шт.
3. Диски для хранилища 300 Gb 24 шт. //С объемом не густо, но к сожалению бюджеты такие бюджеты…
4. Контроллер для подключения SAS производства HP 2 шт.
5. Сетевой адаптер на 4 1Gb порта 2 шт. //Можно было взять модуль под 4 SFP, но у нас нет оборудования с поддержкой 10 Gb, гигабитного соединения вполне достаточно.

Пока качаются обновления на свежеустановленную Windows Server 2012, настроим дисковое хранилище. Мы планируем развернуть сервер баз данных, посему решили 600 Гб использовать под базы данных, остальное под остальные виртуальные машины, такая вот тавтология.

Создаем виртуальные диски:

• Диск raid10 на основе Raid 1+0 из 4 дисков +1 spare
• Диск raid5 на основе Raid 5 из 16 дисков +1 spare
• 2 диска - ЗИП

Теперь необходимо создать разделы.

• raid5_quorum - Так называемый диск-свидетель (witness). Необходим для организации кластера из 2 нод.
• raid5_store - Здесь мы будем хранить виртуальные машины и их жесткие диски
• raid10_db - Здесь будет хранится жесткий диск виртуальной машины MS SQL сервера

Подключать сервера к хранилищу советую по очереди:

1. Подключили 1 сервер к 1 контроллеру хранилища
2. В хранилище появится 1 подключенный хост - дайте ему имя. Советую называть так: имясервера_номер контроллера (A или B)
3. И так, пока не подключите оба сервера к обоим контроллерам.

На коммутаторах, к которым подключены сервера необходимо создать 3 виртуальных подсети (VLAN):

1. ClusterNetwork - здесь ходит служебная информаци кластера (хэртбит, регулирование записи на хранилище)
2. LiveMigration - тут думаю все ясно
3. Management - сеть для управления

На этом подготовка инфраструктуры закончена. Переходим к настройке серверов и поднятию кластера.

Заводим сервера в домен. Устанавливаем роль Hyper-V, Failover Cluster.
В настройках Multipath IO включаем поддержку SAS устройств.
Обязательно перезагружаем.

Следующие настройки необходимо выполнить на обоих серверах.

Переименуйте все 4 сетевых интерфейса в соответствии их физическим портам (у нас это 1,2,3,4).
Настраиваем NIC Teaming - Добавляем все 4 адаптера в команду, Режим (Teaming-Mode) - Switch Independent, Балансировка нагрузки (Load Balancing) - Hyper-V Port. Даем имя команде, я так и назвал Team.
Теперь необходимо поднять виртуальный коммутатор.
Открываем powershell и пишем:

New-VMSwitch "VSwitch" -MinimumBandwidthMode Weight -NetAdapterName "Team" -AllowManagementOS 0

Add-VMNetworkAdapter –ManagementOS –Name "Management" Add-VMNetworkAdapter –ManagementOS –Name "ClusterNetwork"Add-VMNetworkAdapter –ManagementOS –Name "Live Migration"

Эти виртуальные коммутаторы появятся в центре управления сетями и общим доступом, именно по ним и будет ходить траффик наших серверов.

Настройте адресацию в соответствии с вашими планами.

Переводим наши адапетры в соответствующие VLAN’ы.
В любимом powershell:

Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 2 -VMNetworkAdapterName "Management" -Confirm Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 3 -VMNetworkAdapterName "ClusterNetwork" -Confirm Set-VMNetworkAdapterVlan -ManagementOS -Access -VlanId 4 -VMNetworkAdapterName "Live Migration" -Confirm

Теперь нужно настроить QoS.

При настройке QoS by weight (по весу), что является best practice, по заявлению Microsoft, советую расставить вес так, чтобы в общей сумме получилось 100, тогда можно считать, что значение указанное в настройке есть гарантированный процент полосы пропускания. В любом случае считается процент по формуле:

Процент полосы пропускания = установленный вес * 100 / сумма всех установленных значений веса

Set-VMSwitch “VSwitch” -DefaultFlowMinimumBandwidthWeight 15

Для служебной информации кластера.

Set-VMNetworkAdapter -ManagementOS -Name “Cluster” -MinimumBandwidthWeight 30

Set-VMNetworkAdapter -ManagementOS -Name "Management" -MinimumBandwidthWeight 5

Set-VMNetworkAdapter -ManagementOS -Name “Live Migration” -MinimumBandwidthWeight 50

Давайте так и сделаем.
В нашем ненаглядном:

$n = Get-ClusterNetwork “ClusterNetwork” $n.Metric = 1000 $n = Get-ClusterNetwork “LiveMigration” $n.Metric = 1050$n = Get-ClusterNetwork “Management” $n.Metric = 1100

Монтируем наш диск-свидетель на ноде, с которой будем собирать кластер, форматируем в ntfs.

В оснастке Failover Clustering в разделе Networks переименуйте сети в соответствии с нашими адаптерами.

Все готово к сбору кластера.

В оснастке Failover Clustering жмем validate. Проходим проверку. После чего создаем кластер (create cluster) и выбираем конфигурацию кворума (quorum configuration) Node and Disk majority, что также считается лучшим выбором для кластеров с четным количеством нод, а учитывая, что у нас их всего две - это единственный выбор.

В разделе Storage оснастки Failover Clustering, добавьте ваши диски. А затем по очереди добавляйте их как Cluster Shared Volume (правый клик по диску). После добавления в папке C:\ClusterStorage появится символическая ссылка на диск, переименуйте ее в соответствии с названием диска, добавленного как Cluster Shared Volume.

Теперь можно создавать виртуальные машины и сохранять их на эти разделы. Надеюсь статья была Вам полезна.

Прошу сообщать об ошибках в ПМ.

Советую к прочтению: Microsoft Windows Server 2012 Полное руководство. Рэнд Моримото, Майкл Ноэл, Гай Ярдени, Омар Драуби, Эндрю Аббейт, Крис Амарис.

P.S.: Отдельное спасибо господину Салахову, Загорскому и Разборнову, которые постыдно были забыты мною при написании данного поста. Каюсь >_< XD

Кластеры серверов

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

Высокая доступность
Доступность услуги не ниже 100% даже при простое серверов

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

Надежное техническое обеспечение
Качественное оборудования мирового класса в безопасных дата-центрах

Серверы и системы хранения доступны клиенту полностью оборудованные, с востребованным количеством процессоров, объёмом оперативной памяти и места для жесткого диска, обеспечив также необходимую сетевую инфраструктуру. В основе каждого решения лежат технические требования клиента. Установить кластер серверов, как правило, занимает всего нескольких рабочих дней – система хранения данных в дата-центре уже предустановлены и нуждаются лишь в дополнительных настройках под требования клиента. Важно отметить, что доступ к кластеру возможен из любой точки мира - необходимо лишь иметь стабильное подключение к интернету. Все данные и приложения находятся в серверах, расположенных в безопасных дата-центрах DEAC в Рига, а также в стратегических точках локации в Стокгольме, Киеве, Лондоне, Амстердаме, Москве и Франкфурте.

Своим клиентам предлагаем создавать различные кластеры серверов:

Платформа аналитики «больших данных»

Выберите системы аналитики «больших данных» Hadoop , Apache Spark , Apache Storm или Disco для эффективной обработки больших объемов информации. Данные платформы позволяют анализировать огромные массивы данных параллельно, используя кластеризацию серверов. Платформы распределенных вычислений позволяют распределить «большие данные» на несколько узлов внутри кластера типовых серверов. Тем самым вам не нужно покупать и поддерживать дорогостоящее специализированное оборудование. DEAC предоставляет полностью настроенные кластеры для запуска любого из упомянутых проектов с открытым исходным кодом, а также для других приложений на базе выбранной платформы.

Приобретайте Hadoop-платформу уже сегодня по специальной цене!

Сервер: 1хHP DL320 Gen8, 1xE3-1240v2, 16ГБ RAM, 1x1ТБ SATA, 2x1GE, SPS

Сеть: 1х1GE порт включен

Трафик: 1х100 Мбит/с интернет включен (без лимита и без замеров)

IPv4: 1 включена

Индекс скорости процессора (CPU Score ): 9153

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

Сферы применения
серверных кластеров

Как работает кластер
серверов?

Основные компоненты
кластера серверов

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

• Э-коммерция
• Онлайн казино и букмекеры
• Предприятия, которые содержат базы данных
• Медицинская отрасль
• Финансовые компании и фондовые биржи
• Кредитование и страхование
• Разработка и тестирование программного обеспечения

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

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

Каждый вычислительный кластер отличается компонентами и системой внутреннего контроля. Такие компоненты, как Database manager (менеджер баз данных), Node manager (менеджер узлов) и Failover manager (менеджер аварийного переключения) работают вместе для достижения максимальной производительности.

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

Node manager содержит список локальный список всех узлов, сетей и сетевых интерфейсов и обеспечивает мониторинг узлов на предмет их отказа.

Failover manager управляет зависимостями ресурсов, запуском ресурсов и инициирует аварийное переключение групп ресурсов.

DEAC сертифицирован по стандарту PCI DSS, что подтверждает высокий уровень информационной безопасности компании, обрабатывающих данные кредитных карт. Если Ваша компания принимает, хранит, обрабатывает или пересылает данные кредитных карт онлайн или оффлайн, то у Вас должен быть сертификат PCI DSS. DEAC внедрил комплексную сетевую инфраструктуру для соответствия внедряемой политике PCI DSS. Решения серверных кластеров соответствуют требованиям PCI DSS и обеспечивают соответствие и нашим клиентам.

MTBF (Mean Time Between Failure) — среднее время наработки на отказ.
MTTR (Mean Time To Repair) — среднее время восстановления работоспособности.

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

Что такое кластер высокой готовности?

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

Принципиальная схема кластера высокой готовности приведена на рисунке:

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

Таким образом, все подсистемы кластера имеют резервирование, поэтому при отказе любого элемента кластер в целом останется в работоспособном состоянии. Более того, замена отказавшего элемента возможна без остановки кластера.

На обоих узлах кластера устанавливается операционная система Microsoft Windows Server 2003 Enterprise, которая поддерживает технологию Microsoft Windows Cluster Service (MSCS).

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

Сначала приложение запускается на одном из узлов. Если этот узел по какой-либо причине прекращает функционировать, другой узел перестает получать от него сигнал активности ("heartbeat") и автоматически запускает все приложения отказавшего узла, т.е. приложения вместе со своими группами ресурсов "мигрируют" на исправный узел. Миграция приложения может продолжаться от нескольких секунд до нескольких десятков секунд и в течение этого времени данное приложение недоступно для клиентов. В зависимости от типа приложения после рестарта сеанс возобновляется автоматически либо может потребоваться повторная авторизация клиента. Никаких изменений настроек со стороны клиента не нужно. После восстановления неисправного узла его приложения могут мигрировать обратно.

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

Если приложения работают только на одном узле, а другой узел используется в качестве резерва, то при отказе "рабочего" узла производительность кластера не изменится (при условии, что запасной узел не "слабее").

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

Следует отличать кластеры высокой готовности от отказоустойчивых систем ("fault-tolerant"), которые строятся по принципу полного дублирования. В таких системах серверы работают параллельно в синхронном режиме. Достоинством этих систем является малое (меньше секунды) время восстановления после отказа, а недостатком - высокая стоимость из-за необходимости применения специальных программных и аппаратных решений.

Сравнение кластера высокой готовности с обычным сервером

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

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

Неплановые остановки случаются из-за сбоев программного обеспечения или аппаратуры. В случае сбоя ПО на обычном сервере потребуется перезагрузка операционной системы или приложения, в случае с кластером приложение мигрирует на другой узел и продолжит работу.

Наименее предсказуемым событием является отказ оборудования. Из опыта известно, что сервер является достаточно надежным устройством. Но можно ли получить конкретные цифры, отражающие уровень готовности сервера и кластера?

Производители компьютерных компонентов, как правило, определяют их надежность на основании испытаний партии изделий по следующей формуле:

Например, если тестировалось 100 изделий в течение года и 10 из них вышло из строя, то MTBF, вычисленное по этой формуле, будет равно 10 годам. Т.е. предполагается, что через 10 лет все изделия выйдут из строя.

Отсюда можно сделать следующие важные выводы. Во-первых, такая методика расчета MTBF предполагает, что число отказов в единицу времени постоянно на протяжении всего срока эксплуатации. В "реальной" жизни это, конечно, не так. На самом деле, из теории надежности известно, что кривая отказов имеет следующий вид:

В зоне I проявляются отказы изделий, имеющие дефекты изготовления. В III зоне начинают сказываться усталостные изменения. В зоне II отказы вызываются случайными факторами и их число постоянно в единицу времени. Изготовители компонентов, "распространяют" эту зону на весь срок эксплуатации. Реальная статистика отказов на протяжение всего срока эксплуатации подтверждает, что эта теоретическая модель вполне близка к действительности.

Второй интересный вывод заключается в том, что понятие MTBF отражает совсем не то, что очевидно следует из его названия. "Среднее время наработки на отказ" в буквальном смысле означает время, составляющее только половину MTBF. Так, в нашем примере это "среднее время" будет не 10 лет, а пять, поскольку в среднем все экземпляры изделия проработают не 10 лет, а вполовину меньше. Т.е. MTBF, заявляемый производителем - это время, в течение которого изделие выйдет из строя с вероятностью 100%.

Итак, поскольку вероятность выхода компонента из строя на протяжении MTBF равна 1, и если MTBF измерять в годах, то вероятность выхода компонента из строя в течение одного года составит:

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

Отказ дублированного компонента приведет к отказу сервера только при условии, что компонент-дублер тоже выйдет из строя в течение времени, необходимого для "горячей" замены компонента, отказавшего первым. Если гарантированное время замены компонента составляет 24 часа (1/365 года) (что соответствует сложившейся практике обслуживания серверного оборудования), то вероятность такого события в течение года:

Пояснения к формуле.

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

Случай (1)

1. Выход из строя компонента №1 в любой момент времени в течение года (вероятность P)
2. Выход из строя компонента №2 в течение 24 часов после выхода компонента №1 (вероятность P/365)

Вероятность одновременного наступления этих событий равняется произведению их вероятностей.

Для случая (2), когда сначала откажет компонент №2, а затем компонент №1, вероятность будет такой же.

Поскольку случаи (1) и (2) не могут произойти одновременно, вероятность наступления того или другого случая равна сумме их вероятностей.

Теперь, зная вероятность Pi отказа каждого из N компонентов (дублированных и недублированных) сервера, можно рассчитать вероятность отказа сервера в течение одного года.

Выполним расчет следующим образом.

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

Вероятность безотказной работы любого компонента в течение года равна

Вероятность безотказной работы всех компонентов в течение года равна произведению вероятностей этих независимых событий:

Тогда вероятность выхода сервера из строя в течение года

Теперь можно определить коэффициент готовности:

Перейдем к расчету. Пусть наш сервер состоит из следующих компонентов:

Рисунок 1. Состав сервера

Сведем данные производителей по надежности отдельных компонент, в следующую таблицу:

Вообще, для серверного оборудования нормальным коэффициентом готовности считается величина 99,95%, что примерно соответствует результату наших расчетов.

Выполним аналогичный расчет для кластера.

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

Предположим, что в качестве узла кластера используется рассмотренный нами сервер с коэффициентом готовности K = 99,958%, а время восстановления работоспособности узла - 24 часа.

Рассчитаем параметры надежности внешнего дискового массива:

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

Кластер серверов 1С:Предприятия 8 (1C:Enterprise 8 Server Cluster)

Кластер серверов 1С:Предприятия 8 является основным компонентом платформы, который обеспечивает взаимодействие между системой управления базами данных и пользователем в случае варианта клиент-серверной работы. Кластер дает возможность организовать бесперебойную, устойчивую к отказам, конкурентную работу для значительного количества пользователей с объемными информационными базами.

Кластер серверов 1С:Предприятия 8 – это логическое понятие, которое обозначает совокупность процессов, которые обслуживают один и тот же комплект информационных баз.

Можно выделить следующие возможности кластера серверов, как основные:

• возможность функционировать как на нескольких, так и на одном компьютере (рабочих серверах);
• каждый рабочий сервер может поддерживать функционирование как одного, так и нескольких рабочих процессов, которые обслуживают клиентские соединения в границах этого кластера;
• включение новых клиентов в рабочие процессы кластера происходит, основываясь на долгосрочном анализе статистики загруженности рабочих процессов;
• взаимодействие всех процессов кластера между собой, с клиентскими приложениями и сервером баз данных осуществляется по протоколу TCP/IP;
• запущены процессы кластера, могут быть как сервис, так и как приложение

Клиент-серверный вариант. Схема работы

При этом варианте работы с сервером взаимодействует клиентское приложение. Кластер серверов, в свою очередь, взаимодействует с сервером баз данных.

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

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

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

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

Кластер серверов

Элементарный кластер серверов может представлять собой единственный компьютер и содержать только один рабочий процесс.

На рисунке можно наблюдать все элементы, которые, так или иначе, принимают участие в работе кластера серверов. Это следующие элементы:

• процессы кластера серверов:
  o ragent.exe;
  o rmngr.exe;
  o rphost.exe;
• хранилища данных:
  o список кластеров;
  o реестр кластера.

Процесс ragent.exe, называемый – агент сервера, обеспечивает функционирование компьютера как составной части кластера. Следовательно, компьютер, на котором запущен процесс ragent.exe, следует называть рабочим сервером. В частности одной из функциональных обязанностей ragent.exe является ведение реестра кластеров, которые находятся на конкретном рабочем сервере.

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

Сам кластер серверов состоит из таких элементов:

• один или несколько процессов rmngr.exe
• реестр кластера
• один или несколько процессов rphost.exe.

Менеджер кластера (процесс rmngr.exe). Он служит для управления функционирования всего кластера. В состав кластера может входить несколько процессов rmngr.exe, один их которых всегда будет главным менеджером данного кластера, а остальные процессы – дополнительными менеджерами. Центральным сервером кластера следует называть рабочий сервер, на котором действует главный менеджер кластера, и который содержит список кластера. Именно ведение реестра кластера является одной из функций главного менеджера кластера.

Рабочий процесс (процесс rphost.exe). Именно он, непосредственно, обслуживает клиентские приложения, взаимодействуя с сервером баз данных. В этом процессе могут исполняться некоторые процедуры конфигурации серверных модулей.

Масштабируемость 1С версии 8.3

Масштабируемость кластера серверов осуществляется следующими способами:

• увеличивают количество менеджеров в кластере и распределение сервисов между ними
• увеличивают количество рабочих процессов, которые функционируют на данном рабочем сервере
• увеличивают количество рабочих серверов, из которых состоит кластер.

Использование одновременно нескольких менеджеров.

Функции, которые исполняет менеджер кластера, разделяются на несколько сервисов. Данные сервисы можно назначить разным менеджерам кластера. Это дает возможность равномерно распределить нагрузку по нескольким процессам.

Однако некоторые сервисы могут быть использованы только главным менеджером кластера:

• сервис конфигурации кластера
• сервис управления предметами отладки
• сервис блокировок кластера.

Для прочих сервисов допустимы в назначение произвольные менеджеры кластера:

• сервис журналов регистрации
• сервис блокировки объектов
• сервис заданий
• сервис полнотекстового поиска
• сервис сеансовых данных
• сервис нумерации
• сервис пользовательских настроек
• сервис времени
• сервис транзакционных блокировок.

Использование одновременно нескольких рабочих процессов.

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

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

Отказоустойчивость 1С версии 8.3

Устойчивость к отказам в работе кластера обеспечивается тремя направлениями:

• резервированием самого кластера
• резервированием рабочих процессов
• устойчивостью к обрыву канала связи.

Резервирование кластера 1С версии 8.3

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

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

Резервирование рабочих процессов 1С версии 8.3

Для каждого из рабочих процессов есть возможность указания вариантов его использования:

• использовать
• не использовать
• использовать как резервный.

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

Устойчивость 1С версии 8.3 к обрыву канала связи

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

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

Сеансы работы в 1С версии 8.3

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

• Тонкий клиент, Веб-клиент, Толстый клиент – эти сеансы возникают при обращении соответствующих клиентов к информационной базе
• Соединение типа «Конфигуратор» — оно возникает при обращении к информационной базе конфигуратора
• СОМ-соединение – образовывается при использовании внешнего соединения для обращения к информационной базе
• WS-соединение – возникает в случае обращения к информационной базе веб-сервера, как следствие обращения к опубликованному на веб-сервере Web-сервису
• Фоновое задание – образовывается, когда рабочий процесс кластера обращается к информационной базе. Служит такой сеанс для исполнения кода процедуры фонового задания,
  Консоль кластера – создается, когда утилита администрирования клиент-серверного варианта обращается к рабочему процессу
• СОМ-администратор – возникает в случае обращения к рабочему процессу с использованием внешнего соединения.
• Работа при использовании различных операционных систем

Любые процессы кластера серверов могут функционировать как под операционной системы Linux, так и под операционной системы Windows. Это достигается тем, что взаимодействие кластеров происходит под управлением протокола TCP/IP. Также в состав кластера могут входить рабочие серверы под управлением любой из этих операционных систем.

Утилита администрирования кластера серверов 8.3

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