Понедельник. Вопрос 5

[GreenFox]

Каким образом можно объединить несколько физических серверов в один сервер приложения?

Предыдущий вопрос Следущий вопрос

Использовать Кластер серверов 1С

[lanita]

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

[AlexInqMetal]

объединить сервера в кластер

[vlgutv]

собрать в один кластер

[cathrine]

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

[Yana_TAGRONE]

Каким образом можно объединить несколько физических серверов в один сервер приложения?

язык запросов. Построение виртуальных и реальных таблиц

Добавлено: 11 мар 2013, 23:15

Каким образом можно объединить несколько физических серверов в один сервер приложения?

Предыдущий вопрос Следущий вопрос

консолидировать сервера

[AVB]

Посредством создания кластера серверов 1С.

[lena8push]

Сервер приложений 1С - это программа, состоящая из нескольких процессов:

1) ragent.exe (агент сервера) - хранит и идентифицирует кластер ( в нашем случае группы кластеров ) 1С
2) rmngr.exe (кластер 1С) - группа рабочих процессов 1с, которые осуществляют обработку данных.
Сам по себе кластер ничего не обрабатывает, он осуществляет менеджмент рабочих процессов.
3) rphost.exe (рабочий процесс 1С) - обрабатывает сеанс работы пользователя.

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

Управление сервером приложения производится с помощью специальной утилиты "Администрирование серверов 1С" (пуск- 1сПредприятие-

Администрирование).

Чтобы добавить сервер 1С, нажимаем ПКМ на "Центральные серверы 1С", выбираем "Новый сервер".
Имя - IP адрес или имя компьютера, на коором установлен и запущен сервер 1с.

Для входа в добавленные сервера раскрываем ветку слева от имени.
Здесь можно указать администраторов сервера 1С ( ветка "Администраторы"). Они имеют права на упраление сервером ( не кластером).
Если ни один не добавлен - управлять может каждый вошедший. Нехорошо.
А также на ветке "Кластеры" управлять кластерами. (в ветке адм-ры ветки кластеры указ-ся ад-ры кластера).
Также есть ветки "рабочие серверы" и "Информационные базы", соответственно, для изменения рабочих процессов (регулируем
нагрузку), и для работы над подключенными БД (например, можно выгнать пользователей).

[latysh]

Через установку клиент - сервера для 1с

[anechayeva]

1. Вариант кластерных решений:
http://n-t.ru/tp/ts/os.htm
«С совместным использованием диска» – все серверы в кластере используют одно устройство (массив) хранения данных. Преимущество этой модели заключается в возможности переключения при отказе, так как все серверы используют одинаковые данные; недостаток состоит в том, что, например, при обслуживании большой базы данных обмен информацией между компьютерами в кластере (по мере того, как они «обновляют» друг друга) может негативно повлиять на производительность. Устранить этот недостаток позволяет использование таких инструментальных средств, как Oracle Cache Fusion, которое входит в состав Oracle 9i RAC.
«Без совместного использования» – все серверы абсолютно независимы друг от друга и сами управляют своими периферийными устройствами. В случае сбоя данные перераспределяются на другие серверы. Эта модель дает широкие возможности для масштабирования и предполагает минимум «служебного» трафика между серверами, но в то же время может налагать определенные ограничения на устройство базы данных.

И очень удачно описанные варианты объединения серверов в источнике:http://blog.trinitygroup.ru/2009/11/blog-post.html

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

Все дополнительные возможности (с названиями Live Migration, VMotion, DRS, HA и т.п.) служат для управления виртуальными машинами и их перемещением между серверами, но никак не для того, чтобы объединить ресурсы нескольких серверов для распределения между ними одной "тяжелой" задачи.

Если стоит задача именно увеличить процессорную мощность системы по сравнению с имеющимся сервером, то в большинстве случаев решением является приобретение сервера с большим числом процессоров.

Существуют способы объединить серверы через интерфейсы с низкой латентностью и высокой пропускной способностью (например Infiniband), а это, в свою очередь, открывает двери для протокола RMDA (Remote Direct Memory Access). RDMA позволяет приложению, исполняющемуся на одном сервере, получать доступ к оперативной памяти другого сервера, как если бы эта память была его собственная. Казалось бы, стоит сделать небольшой шаг и можно будет именно объединить ресурсы нескольких машин вместе, без необходимости в модернизации приложений и прочих сложностей, но до недавнего времени таких решений не было.

Двое производителей Scale MP и 3leaf Systems предложили свои решения. Оба решения позволяют объединить несколько обычных серверов в один большой виртуальный SMP сервер, выполнение на котором приложений не требует их модификации для работы на кластере. Фактическая реализация очень похожа – для создания "объединительной" среды используется высокоскоростной интерфейс. 3leaf Systems используют свой собственный ASIC, который на текущий момент устанавливается в кастомизированные платы Supermicro для процессоров AMD, но в ближайшее время планируется решение и на процессорах Intel Xeon с поддержкой QPI. Dynamic Data Center Software позволяет выделять приложению ресурсы с гранулярностью на уровне отдельных узлов, либо на уровне процессорного ядра, а в скором времени обещают и динамическое выделение ресурсов без перезагрузки виртуальной машины. Уже сейчас можно использовать вместе до 16ти серверов (до 192 ядер) и суммарно до 1ТБ памяти.

Решение же от Scale MP может работать на самых разных системах, а для связи узлов друг с другом используется Infiniband. Серверы в рамках даже одного кластера могут отличаться друг от друга, наверное в т.ч. и из-за этого технология называется vSMP (v – versatile, универсальный).

Основной продукт – vSMP Foundation for SMP является наиболее "продвинутым" вариантам и позволяет объединить до 255 ядер и 4ТБ памяти в один SMP сервер, поддерживается деление общего процессорного пула между виртуальными машинами (одна VM должна включать минимум два узла), для небольших конфигураций можно обойтись и без Infiniband коммутатора – узлы можно соединять друг с другом напрямую. Более бюджетный вариант vSMP Foundation for Cluster отличается от "старшего" брата ограничением памяти в 512ГБ и использованием процессоров не старше 2.4ГГц. vSMP Foundation for Cloud позволяет динамически вводить машины в общий пул –загрузка производится по сети (а не с флэшки, как в остальных вариантах). Очень интересной возможностью является использование различных конфигураций в рамках одного кластера: для приложений, крайне требовательных к объему памяти, но не столь требовательных к числу процессорных ядер, можно строить систему, в которой часть узлов с быстрыми процессорами предназначена непосредственно для исполнения приложения, а другая часть – со сравнительно медленными процессорами, но большим объемом памяти, используется только для увеличения общей оперативной памяти, выделяемой приложению (процессоры этих узлов не будут использоваться для работы пользовательского ПО):
Конечно же, такое "объединение" ресурсов не является заменой failover кластеру – любая аппаратная проблема внутри такой системы приведет к полной остановке приложения и потребуется перезапуск системы. Возможность изоляции сбойного узла предотвращает длительный простой, но если требуется высокая доступность приложения, то помимо объединения ресурсов в "большой" SMP сервер, необходимо предусмотреть и такие способы резервирования как кластер высокой доступности.

С учетом того, что цены на Infiniband снижаются все сильнее и построение инфраструктуры уже практически эквивалентно стоимости FC SAN, описанные решения по построению больших SMP систем имеют довольно много шансов занять вполне заметную нишу. Причем, от чисто вычислительных задач интерес постепенно будет смещаться в сторону бизнес-приложений (СУБД и т.п.).