Что такое кластер серверов.

• Служба Network Load Balancing (NLB) .В основном, предназначена для балансирования входящего трафика TCP/IP. NLB обычно используется для веб-серверов.
• Кластеры серверов .Реализуются для обеспечения переходов по отказу ( failover ) среди кластеризованных компьютеров. Служба Cluster обычно используется для приложений, работающих с базами данных.

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

Примечание . Microsoft также предлагает третью кластерную технологию - кластеры Component Load Balancing (CLB). Эта технология входит в состав Microsoft Application Center 2000 и не включается ни в одну из версий Windows Server 2003. CLB-кластеры позволяют распространять приложения COM+ среди нескольких серверов, что гарантирует масштабируемость и высокую готовность приложений.

Кластеры Network Load Balancing

Network Load Balancing (NLB) - это программная разработка, используемая в кластеризации Microsoft Windows для масштабирования работы IP-программ путем распределения клиентских запросов среди нескольких серверов в кластере. NLB используется чаще всего для повышения производительности и уровня готовности веб-приложений, но может также использоваться для повышения производительности множества IP-приложений внутри вашего предприятия.

Примечание . Служба Network Load Balancing в ее текущей форме появилась как переработанная замена службы Windows Load Balancing Service (WLBS), используемой в Windows NT 4. Однако вы увидите, что до сих пор имеются компоненты исходной WLBS, например, запускаемая из командной строки программа управления, wlbs.exe, все еще используется для обратной совместимости.

NLB входит в следующие версии Windows Server 2003:

• Standard Edition;
• Enterprise Edition;
• Datacenter Edition;
• Web Edition.

Преимущества Network Load Balancing

С помощью Network Load Balancing можно создавать кластеры, содержащие до 32 хостов, среди которых могут распределяться запросы клиентов. Служба NLB расширена в Windows Server 2003, позволяя вам создавать несколько виртуальных NLB-кластеров на одном сервере путем задания NLB для нескольких сетевых адаптеров и путем задания нескольких IP-адресов кластера со сбалансированной нагрузкой для одного сетевого адаптера. Два главных достоинства NLB для приложений - это готовность и масштабируемость.

Готовность

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

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

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

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

Масштабируемость

NLB обеспечивает два уровня масштабируемости.

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

Управляемость

Администрирование Network Load Balancing происходит эффективно, поскольку кластер управляется как единое целое из одной точки управления (которая может быть удаленной). Администраторы управляют кластером, используя команды оболочки и скрипты для запуска, прекращения работы и управления кластером. Кроме того, возможность перевода отдельных серверов в автономный режим без снижения производительности кластера упрощает обслуживание и модернизацию операционных систем.

Архитектура NLB

Network Load Balancing запускается как драйвер сетевого обмена Windows, и операции этого драйвера прозрачны для стека TCP/IP. Все компьютеры в кластере можно указывать с помощью IP-адреса данного кластера. Однако каждый компьютер поддерживает также свой собственный уникальный выделенный IP-адрес. Компания Microsoft реализовала NLB как драйвер сетевого обмена, который действует между драйвером сетевого адаптера (сетевой карты) и стеком IP. Все члены NLB-кластера должны находиться в одной подсети IP, чтобы запросы клиентов, направляемые по IP-адресу кластера, могли обрабатываться всеми членами кластера.

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

NLB перехватывает только пакеты TCP и UDP. Пакеты других протоколов IP передаются в стек протоколов и обрабатываются всеми узлами NLB-кластера.

Оборудование и протоколы

Служба NLB разработана таким образом, чтобы обеспечивать кластерную поддержку для серверных программ на основе TCP/IP. Для этого, конечно, требуется, чтобы TCP/IP был протоколом по умолчанию для системы. Версия NLB в Windows Server 2003 действует в локальных сетях на основе FDDI или Ethernet внутри кластера.

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

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

NLB управляет распределением по соединениям для TCP и по дейтаграммам для UDP, применяя фильтрацию входного трафика, прежде чем происходит обращение к программам протокола TCP/IP. В TCP/IP обрабатываются только протоколы TCP и UDP, и все управление применяется на уровне портов.

Примечание .Некоторые программы двухточечных соединений TCP/IP, в особенности ping , будут давать дублированные ответы при указании IP-адреса кластера. Чтобы избежать этого, используйте выделенный IP-адрес хоста, которому вы передаете ping .

NLB можно сконфигурировать для обработки трафика кластера более детально путем использования таких средств, как правила для портов или родственность ( affinity ). Более подробную информацию см. ниже в разделе "Установка и конфигурирование Network Load Balancing ".

Виртуальные кластеры

Служба Network Load Balancing в Windows Server 2003 расширена за счет поддержки виртуальных кластеров со сбалансированной нагрузкой. Для создания виртуального кластера нужно активизировать NLB для нескольких сетевых адаптеров на одном сервере или назначить несколько IP-адресов одному сетевому адаптеру, для которого активизирована NLB. Поскольку различные IP-адреса могут соответствовать различным веб-сайтам или приложениям, разумное использование виртуальных кластеров и соответствующих правил для портов позволяет вам управлять тем, как различные веб-приложения распределяются между физическими серверами со сбалансированной нагрузкой.

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

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

Конфигурирование приложений

Имеется несколько способов конфигурирования приложений в NLB-кластере. Кластер можно сконфигурировать таким образом, чтобы копия серверной программы выполнялась на каждом хосте; или приложение может выполняться на одном хосте, когда все запросы отправляются на этот хост вместо равномерного распределения нагрузки по всему кластеру. Принимаемое решение зависит от типа приложения. Например, приложения, которым требуется централизация, такие как Microsoft Exchange Server, принадлежат какому-либо одному хосту. Кроме того, запросы записи в базу данных могут отправляться на выделенный сервер базы данных в системе. Если нагрузка по базе данных сбалансирована в кластере, то каждый узел кластера может иметь свою собственную копию этих данных. Обновления в содержимом таблицы базы данных должны синхронизироваться путем регулярного слияния в режиме offline. Однако в большинстве случаев критически важные базы данных развертываются в среде кластера серверов, позволяющего выполнять переходы по отказам ( failover ), а не в среде NLB (см. ниже раздел "Кластеры серверов").

NLB в чистом виде наиболее подходит для нецентрализованного хранения данных или для приложений, которые не принимают данных от клиентов, выполняющих доступ к серверу (то есть для доступных только по чтению приложений на основе протокола TCP или UDP). Веб-сайты являются идеальными "кандидатами" для использования с NLB, поскольку это позволяет легко снабжать каждый хост текущей копией страниц (которые обычно являются статическими), обеспечивая простоту и скорость обработки больших объемов трафика. Для веб-клиентов, которым требуется доступ к базе данных, веб-серверы могут направлять запросы на сервер базы данных. Имеются также следующие кандидаты, для которых подходит NLB:

• HTTP, HTTPS, FTP, TFTP и SMTP поверх TCP/IP
• HTTP через SSL - порт 443
• FTP - порт 21, порт 20, порты 1024.65 и порт 535
• SMTP - порт 25
• Terminal Services - порт 3389
• Веб-серверы (такие как Microsoft Internet Information Services) - порт 80
• Веб-серверы, использующие круговую DNS
• Серверы виртуальных частных сетей (VPN)
• Серверы потокового медиа.

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

Серверы приложений и соединения с изменяемым состоянием

Имеется два вида соединений между клиентами и хостами для серверов приложений, и они обычно описываются термином stateful-соединение (соединение с изменяемым состоянием).

• Interclient-состояние (состояние с учетом всех клиентов). Обновления синхронизируются с транзакциями, выполняемыми для других клиентов. Примером является обновление базы данных запасов на сайте e-commerce после продажи товаров через соединение с клиентом.
• Intraclient-состояние (состояние на уровне одного клиента). Состояние, поддерживаемое для конкретного клиента в течение одного сеанса, включающего, например, продажу продуктов (обычно с помощью процесса обработки "торговой тележки") на сайте e-commerce. На самом деле для большинства сайтов e-commerce процесс обработки "торговой тележки" может охватывать несколько отдельных соединений с одним клиентом.

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

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

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

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

Суть вкратце

Кластер серверов - это не просто несколько компьютеров, соединённых друг с другом проводами, «витыми парами». Это, в первую очередь, программное обеспечение , которое управляет всем этим «железом», распределяет запросы, синхронизирует, осуществляет балансировку нагрузки, подключает базу данных... Впрочем, лучше растолковывать суть явления на конкретном примере.

Пример схемы кластера серверов

В качестве примера возьмём весьма популярный софт «1С:Предприятие 8». Упрощённая схема функционирования кластера серверов выглядит примерно следующим образом.

Клиентское приложение (в смысле, приложение на компьютере пользователя) осуществляет запрос по протоколу TCP/IP. Этот запрос приходит на центральный сервер в кластере, где действует программа-менеджер (Cluster Manager) и располагается реестр кластера.

Центральный сервер на лету анализирует обстановку с загруженностью и перенаправляет запрос (тоже по TCP/IP) на тот компьютер в кластере, у которого в этот момент есть возможность наиболее быстро и эффективно обработать обращение пользователя. После чего за обслуживание запроса берётся конкретный рабочий процесс на конкретной машине.

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

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

Microsoft

Для организации кластера серверов на основе софта от корпорации Microsoft требуется операционная система «Microsoft® Windows Server™ 2008», причём, «Enterprise Edition» или «Datacenter Edition». Там есть софт «Windows Server Failover Clustering». (Ранее, в релизе ОС за 2003-й год, программное изделие называлось «Microsoft Cluster Server», сокращённо MSCS.)

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

Кластер в Windows Server создаётся с помощью графического интерфейса «Cluster Control Panel». Десяток диалоговых окошек - и готово.

Oracle

Компания Oracle для создания кластеров производит продукт «WebLogic». Есть версии и для Windows , и для GNU/Linux .

Велосипед изобретать не стали: работой и балансировкой нагрузки руководит сервер-администратор (Admin Server), к которому подключены узлы (Managed Servers). Всё вместе объединяется в единый домен.

Причём, с помощью «WebLogic» в домен можно сгруппировать даже не один, а несколько кластеров. Кроме того, доступны: 1) репликация пользовательских сессий в серверах кластера; 2) балансировка нагрузки (с помощью компонента HttpClusterServlet).

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

Кроме того, имеется продукт «Oracle Real Application Clusters» (сокращённо «Oracle RAC») для синхронизированной работы «Oracle Database» на нескольких узлах, что тоже по своей сути является кластером.

Заключение

Благодаря умному софту кластер выглядит «со стороны», с точки зрения клиента, как один единственный компьютер, к которому осуществляется запрос. В этом отличие кластера от Grid-систем распределённых вычислений, где компьютеры вовсе необязательно объединены в домен, вполне могут быть удалёнными.

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

Предыдущие публикации:

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

Когда стоит устанавливать кластер серверов 1С?

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

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

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

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

Рассмотрим данный алгоритм на примере объединения двух серверов 1С 8.2 в кластер

Допустим, на сегодня у вас имеется два сервера, на одном из которых (S1C-01) установлен сервер 1С и информационные базы. Чтобы настроить отказоустойчивый кластер серверов, необходимо на сервере S1C-02 развернуть сервер 1С:Предприятие и начать рабочий процесс. Убедитесь, что в его свойствах установлен пункт «Использование» в состояние «Использовать». Регистрировать информационные базы нет необходимости.

После этого в консоли администрирования 1С необходимо добавить в раздел «Резервирование кластеров» резервный кластер с именем второго сервера – S1C-02. В аналогичный раздел второго сервера добавляем резервный кластер с именем S1C-01 и перемещаем его на верхнюю позицию. Для этого воспользуйтесь контекстным меню и командой «Переместить вверх». Необходимо добиться одинакового порядка в этих группах обоих серверов.

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

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

Нагрузка на кластер и оптимизация

Тестирование нагрузки

Наиболее распространенными технологиями тестирования кластера серверов 1С считаются:

1. Тест Гилева;
2. Тест центр из 1С:КИП.

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

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

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

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

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

Крайне полезный параметр для серверов, использующихся 24 часа в сутки – «Интервал перезапуска». Обычно его значение устанавливают в 86400 секунд, чтобы раз в день серверы могли перезапуститься автоматически. Это полезно для снижения отрицательных эффектов от утечки памяти и фрагментации данных на дисках при выполнении операций.

Очень важно, чтобы отказоустойчивый кластер серверов 1С был защищен от перерасхода памяти. Один неудачный запрос в цикле может забрать себе всю мощность многоядерных серверов. Чтобы воспрепятствовать этому существует два параметра кластера – «Допустимый объем памяти» и «Интервал превышения допустимого объема». Если вы правильно и точно настроите эти параметры, то обезопасите свои информационные базы от многих распространенных бед.

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

Еще один параметр – «Выключенные процессы останавливать через» отвечает за регулярное отключение подключений к серверу через заданные промежутки времени. В 1С после завершения работы рабочие процессы висят некоторое время, чтобы данные корректно перенеслись на новые процессы. Иногда происходят сбои и на сервере остаются висеть процессы. Они тратят ресурсы и намного полезнее существенно минимизировать их количество.

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

Для грамотной оптимизации воспользуйтесь консолью кластера серверов и для каждого сервера настройте следующие параметры:

• Максимальный объем памяти всех рабочих процессов. Если этот показатель равен 0, то система отводит под процессы 80% оперативной памяти, если же в поле стоит 1, то все 100%. Если на одном сервере стоят вместе 1С и СУБД, то существует вероятность конфликта из-за памяти и необходимо воспользоваться этой настройкой. В ином случае достаточно будет стандартных 80% или рассчитать, сколько необходимо памяти ОС, а оставшееся количество занести в это поле;
• Безопасный расход памяти за 1 вызов. По умолчанию значение «0», означающее, что 1 рабочий процесс будет занимать менее 5% максимального объема оперативной памяти на все процессы. Значение «-1» проставлять не рекомендуется, так как оно снимет все ограничения, что чревато последствиями в виде зависаний;
• Количество информационных баз и соединений на процесс. Эти параметры управляют распределением нагрузки на рабочие процессы. Вы можете настроить их по своим требованиям, чтобы минимизировать потери при излишней нагрузке на сервер. Если установлено значение в 0, то ограничения не действуют, что опасно при большом количестве рабочих мест.

В версии 8.3 еще одной полезной характеристикой для верного распределения нагрузки на сервер является «Менеджер под каждый сервис». Этот параметр дает возможность использовать не один менеджер сервера (rmngr), а множество, каждый из которых отвечает за свою задачу. Это отличная возможность отследить, какой сервис вызывает ухудшение производительности, и измерить количество ресурсов на каждую задачу.

После установки данной характеристики агент сервера ragent перезагрузится и вместо одного rmngr.exe в консоли вы обнаружите целый список. Теперь вы сможете через диспетчер задач найти процесс, загружающий систему и заняться точечной настройкой. Отличить эти процессы друг от друга вам поможет их pid. Однако, так как это нововведение, специалисты 1С рекомендуют осторожно использовать эту возможность.

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

Пресс-центр

Создание кластера на базе Windows 2000/2003. Шаг за шагом

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

Microsoft Windows 2000/2003 поддерживает две технологии кластеризации: кластеры с балансировкой нагрузки (Network Load Balancing) и кластеры серверов.

В первом случае (кластеры с балансировкой нагрузки) служба Network Load Balancing придает службам и приложениям свойства высокого уровня надежности и масштабируемости за счет объединения до 32 серверов в единый кластер. Запросы от клиентов в данном случае распределяются среди узлов кластера прозрачным образом. При отказе узла кластер автоматически изменяет свою конфигурацию и переключает клиента на любой из доступных узлов. Этот режим конфигурации кластера также называется active-active режимом, когда одно приложение работает на нескольких узлах.

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

Кластерный подход к организации внутренней сети дает следующие преимущества:

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

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

Требования к программному обеспечению

• Microsoft Windows 2000 Advanced (Datacenter) Server или Microsoft Windows 2003 Server Enterprise Edition, установленные на всех серверах кластера.
• Установленная служба DNS. Немного поясню. Если вы строите кластер на основе двух контроллеров домена, то намного удобнее использовать службу DNS, которую вы в любом случае устанавливаете при создании Active Directory. Если вы создаете кластер на основе двух серверов, членов Windows NT домена, то вам придется использовать либо службу WINS, либо заносить соответствие имен и адресов машин в файл hosts.
• Terminal Services для удаленного управления серверами. Не обязательно, но при наличии Terminal Services удобно управлять серверами со своего рабочего места.

Требования к аппаратному обеспечению

• Аппаратное обеспечение для узла кластера лучше подбирать, основываясь на Cluster Service Hardware Compatible List (HCL). По рекомендациям Microsoft аппаратное обеспечение должно быть протестировано на совместимость с Cluster Services.
• Соответственно вам понадобятся два сервера, имеющих по два сетевых адаптера; SCSI-адаптер, имеющий внешний интерфейс для подключения внешнего массива данных.
• Внешний массив, имеющий два внешних интерфейса. Каждый из узлов кластера подключается к одному из интерфейсов.

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

Требования к сетевым настройкам

• Уникальное NetBIOS имя для кластера.
• Пять уникальных статических IP-адресов. Два для сетевых адаптеров на кластерную сеть, два для сетевых адаптеров на общую сеть и один для кластера.
• Доменная учетная запись для кластерного сервиса (Cluster service).
• Все узлы кластера должны быть либо member server в домене, либо контроллерами домена.
• Каждый сервер должен иметь два сетевых адаптера. Один для подключения в общую сеть (Public Network), второй для обмена данными между узлами кластера (Private Network).

Замечание: по рекомендациям Microsoft ваш сервер должен иметь два сетевых адаптера, один для общей сети, второй для обмена данными внутри кластера. Можно ли строить кластер на одном интерфейсе - наверное, да, но я не пробовал.

Установка кластера

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

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

Установка двухузлового кластера может быть разделена на 5 шагов

• Установка и настройка узлов в кластере.
• Установка и настройка разделяемого ресурса.
• Проверка дисковой конфигурации.
• Конфигурирование первого узла кластера.
• Конфигурирование второго узла в кластере.

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

Установка и настройка узлов

Мы немного упростим задачу. Поскольку все узлы кластера должны быть либо участниками домена, либо контроллерами домена, то корневым держателем каталога AD (Active Directory) сделаем 1-й узел кластера, на нем же будет работать DNS-служба. 2-й узел кластера будет полноправным контроллером домена.

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

Сетевые настройки

Перед началом установки кластера и Active Directory необходимо выполнить сетевые настройки. Все сетевые настройки хочется разделить на 4 этапа. Для распознавания имен в сети желательно иметь DNS-сервер с уже существующими записями о серверах кластера.

Каждый сервер имеет по две сетевые карты. Одна сетевая карта будет служить для обмена данными между узлами кластера, вторая будет работать на клиентов в нашей сети. Соответственно первый назовем Private Cluster Connection, второй назовем Public Cluster Connection.

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

• My Network Places → Properties

Private Cluster Connection → Properties → Configure → Advanced

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

• Internet Protocol (TCP/IP) → Properties → Use the following IP: 192.168.30.1

  (Для второго узла используйте адрес 192.168.30.2). Введите маску подсети 255.255.255.252 . В качестве адреса DNS-сервера для обоих узлов используйте адрес 192.168.100.1 .

• Дополнительно на вкладке Advanced → WINS выберите пункт Disabled NetBIOS over TCP/IP . Для настроек сетевых адаптеров общей (Public) сети этот пункт опустите.
• Проделайте то же самое с сетевой картой для локальной сети Public Cluster Connection. Используйте адреса, приведенные в таблице. Единственная разница в конфигурации двух сетевых плат состоит в том, что для Public Cluster Connection не требуется выключения режима WINS - NetBIOS over TCP/IP .

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

Установка Active Directory

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

Установка Cluster User Account

• Start → Programs → Administrative Tools → Active Directory Users and Computers
• Добавьте нового пользователя, например, ClusterService.
• Установите флажки на: User Cannot Change Password и Password Never Expires .
• Также добавьте этого пользователя в группу администраторов и дайте ему права Log on as a service (права назначаются в Local Security Policy и Domain Controller Security Policy ).

Настройка внешнего массива данных

Для настройки внешнего массива данных в кластере необходимо помнить, что перед установкой Cluster Service на узлах вы должны сначала сконфигурировать диски на внешнем массиве, только потом устанавливать службу кластера сначала на первом узле, только потом на втором. В случае нарушения порядка установки у вас произойдет сбой, и вы не достигнете цели. Можно ли будет исправить - наверное, да. Когда появится ошибка, у вас будет время, чтобы поправить настройки. Но Microsoft столь загадочная штука, что совсем не знаешь, на какие грабли наступишь. Проще иметь перед глазами пошаговую инструкцию и не забывать нажимать на кнопки. По шагам конфигурирование внешнего массива выглядит так:

1. Оба сервера должны быть выключены, внешний массив включен, подсоединен к обоим серверам.
2. Включаем первый сервер. Получаем доступ к дисковому массиву.
3. Проверяем, чтобы внешний дисковый массив был создан как Basic. Если это не так, то переведем диск с помощью опции Revert to Basic Disk .
4. Создаем на внешнем диске через Computer Manage-ment → Disk Management небольшой раздел. По рекомендациям Microsoft он должен быть не менее 50 Мб. Я рекомендую создать раздел в 500 Мб. или чуть больше. Для размещения кластерных данных этого вполне достаточно. Раздел должен быть отформатирован в NTFS.
5. На обоих узлах кластера этот раздел будет назван одной буквой, например, Q. Соответственно при создании раздела на первом сервере выберем пункт Assign the following drive letter - Q .
6. Оставшуюся часть диска вы можете разметить по своему желанию. Конечно, крайне желательно использовать файловую систему NTFS. Например, при настройке служб DNS, WINS основные базы служб будут перенесены на общий диск (не системный том Q, а второй, созданный вами). И по соображению безопасности вам будет удобнее использовать именно NTFS-тома.
7. Закрываем Disk Management и проверяем доступ к вновь созданному разделу. Например, можно создать на нем текстовый файл test.txt , записать и удалить. Если все прошло нормально, то с конфигурацией внешнего массива на первом узле мы закончили.
8. Теперь выключаем первый сервер. Внешний массив должен быть включен. Включаем второй сервер и проверяем доступ к созданному разделу. Также проверим, чтобы буква, назначенная первому разделу, была идентична выбранной нами, то есть Q.

На этом конфигурация внешнего массива завершена.

Установка Cluster Service Software

Конфигурация первого узла кластера

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

Конфигурация второго узла кластера

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

1. В диалоговом окне Create or Join a Cluster выберите The second or next node in the cluster и нажмите далее.
2. Введите имя кластера, которое мы задали ранее (в примере это MyCluster), и нажмите далее.
3. После подключения второго узла к кластеру Cluster Service Configuration Wizard автоматически заберет все установки с основного узла. Для запуска службы Cluster Service используйте имя, которые мы создавали ранее.
4. Введите пароль вашей учетной записи и нажмите далее.
5. В следующем диалоговом окне нажмите Finish для завершения установки.
6. Cluster service будет запушен на втором узле.
7. Закройте окно Add/Remove Programs .

Для установки дополнительных узлов кластера используйте эту же инструкцию.

Постскриптум, благодарности

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

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 часа.

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

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