Уважаемые дамы и господа! Для вас сохранен старый форум по адресу http://forum.intersyst.ru

Страницы: 1 2 След.
RSS
Collocated кластер Application Server
 
Здравствуйте,

Есть 2-а физических сервера (HP ProLiant dl380 g6) в роли Application Server.
Сервера расположены рядом, и в одном сегменте LAN. Релиз OXE R9.1.
Вопроc: возможно ли разнести сервисы (Managment и Service) на разные интерфейсы сервера?
То есть Cluster interconnection соединить через cross over кабель?

Спасибо.  
Изменено: Александр Чалый - 16.11.2016 15:41:47
 
Не совсем понятно ЧТО хотите сделать и главное ЗАЧЕМ.
По доке с интерфейсами можно делать:
- базовый режим - один интерфейс втыкаем в IP сеть
- redundancy  - втыкаем в два коммутатора - один интерфей работает, второй в резерве
- load balancing - трафик делится между интерфейсами (воткнуто в один коммутатор, коммутатор должен поддерживать это, требуется специфический менеджмент).
 
Объясняю,
все очень просто - основная идея разделить трафик который относится к Кластеру от трафика который относится к Сервису.
Приведу примеры в работе с другими системами - Avaya, Unify.

У выше озвученных вендоров есть возможность использовать Out Of Band и Service интерефесы (на уровне приложения), которые на уровне физического сервера так же есть разные (eth0 и eth1).

Когда 2-а сервера соединены через прямой кабель, намного спокойнее.
Основной вопрос в том, возможно ли реализовать подобное на софте Alcatel OXE?

> базовый режим - один интерфейс втыкаем в IP сеть - Не интересен.
> redundancy - втыкаем в два коммутатора - один интерфей работает, второй в резерве - это Ethernet redundancy. Он возможен при наличии 2-х коммутаторов.
> - load balancing - трафик делится между интерфейсами (воткнуто в один коммутатор, коммутатор должен поддерживать это, требуется специфический менеджмент).Это балансировка в чистом виде?  
Изменено: Александр Чалый - 16.11.2016 17:31:35
 
У вас путаются аж три понятия: management (OOB), service (telephony) и redundancy и привнесено понятие "кластер", не использующееся в ОХЕ.

В ОХЕ все работает через один и тот же Ethernet интерфейс, который может резервироваться.

А для безопасности используется не разнесение физических интерфейсов, а либо встроенный фаерволл, либо внешние средства, плюс соответствующее построение сети.
Про это дело даже отдельный документ в составе документации есть, "Alcatel-Lucent OmniPCX Enterprise Communication Server Security Common Criteria Deployment Guide", 8AL91015USAD
 
Цитата
Александр Чалый написал:
Приведу примеры в работе с другими системами - Avaya, Unify.
вам не кажется что в этом мире все имеет свое предназначение и место
Пути IP-пакета неисповедимы
 
Цитата
Александр Чалый написал:
Объясняю,
все очень просто - основная идея разделить трафик который относится к Кластеру от трафика который относится к Сервису.
Приведу примеры в работе с другими системами - Avaya, Unify.

У выше озвученных вендоров есть возможность использовать Out Of Band и Service интерефесы (на уровне приложения), которые на уровне физического сервера так же есть разные (eth0 и eth1).

Когда 2-а сервера соединены через прямой кабель, намного спокойнее.
Основной вопрос в том, возможно ли реализовать подобное на софте Alcatel OXE?

> базовый режим - один интерфейс втыкаем в IP сеть - Не интересен.
> redundancy - втыкаем в два коммутатора - один интерфей работает, второй в резерве - это Ethernet redundancy. Он возможен при наличии 2-х коммутаторов.
> - load balancing - трафик делится между интерфейсами (воткнуто в один коммутатор, коммутатор должен поддерживать это, требуется специфический менеджмент).Это балансировка в чистом виде?
По балансировке - да, это именно балансировка в чистом виде.
А насчет сервисного интерфейса в Авайя - то какое это имеет отношение к "соединить два сервера через прямой кабель"? Ну есть отдельный порт, как правило в дефолтных адресах куда можно воткнуться и позаниматься менеджментом не подключаясь к сети заказчика.
В Алкатель - втыкайтесь в iLo порт и делайте что вам надо.
 
Цитата
Андрей написал:
У вас путаются аж три понятия: management (OOB), service (telephony) и redundancy и привнесено понятие "кластер", не использующееся в ОХЕ.
Я не вижу путаницы в пояснении задачи которую хотелось бы реализовать.

Цитата
vad написал:
По балансировке - да, это именно балансировка в чистом виде.
А насчет сервисного интерфейса в Авайя - то какое это имеет отношение к "соединить два сервера через прямой кабель"? Ну есть отдельный порт, как правило в дефолтных адресах куда можно воткнуться и позаниматься менеджментом не подключаясь к сети заказчика.
В Алкатель - втыкайтесь в iLo порт и делайте что вам надо.
Порт iLO как порт Managment сервера, не интересен.

Переформулирую вопрос, возможно использовать отдельный сетевой порт на Application Server для построения redundancy?
Другими словами, например, порт Application сервера eth0 - принимает и обрабатывает запросы (telephony, tftp и т.д), а через порт eth1 - синхронизация 2-х серверов (sync, db, мониторинг состояния)?


Цитата
vad написал:
В Алкатель - втыкайтесь в iLo порт и делайте что вам надо.

Вопрос, в случаи если порты iLO соединены в IP сеть заказчика, и при условии что у нах Duplex система, при возникновении Split Brain, возможна ли передача сигнала STONITH через iLO?
Задача не допустит ситуации когда оба работают в роли - Master Master.  
 
Цитата
vad написал:
А насчет сервисного интерфейса в Авайя - то какое это имеет отношение к "соединить два сервера через прямой кабель"?
Согласен, что никакого отношения. Я привел пример того как разделяют интерфейсы под разные задачи.  
 
Цитата
Александр Чалый написал:
Цитата
 Андрей  написал:
У вас путаются аж три понятия: management (OOB), service (telephony) и redundancy и привнесено понятие "кластер", не использующееся в ОХЕ.
Я не вижу путаницы в пояснении задачи которую хотелось бы реализовать.
А я вижу путаницу в терминологии и вам на нее указываю.

"Переформулирую вопрос, возможно использовать отдельный сетевой порт на Application Server для построения redundancy?
Другими словами, например, порт Application сервера eth0 - принимает и обрабатывает запросы (telephony, tftp и т.д), а через порт eth1 - синхронизация 2-х серверов (sync, db, мониторинг состояния)? "

Нет, нельзя.  
 
Цитата
Андрей написал:
"Переформулирую вопрос, возможно использовать отдельный сетевой порт на Application Server для построения redundancy?
Другими словами, например, порт Application сервера eth0 - принимает и обрабатывает запросы (telephony, tftp и т.д), а через порт eth1 - синхронизация 2-х серверов (sync, db, мониторинг состояния)? "

Нет, нельзя.
Самое главное я понял.

Спасибо.  
 
Цитата
Андрей написал:
А я вижу путаницу в терминологии и вам на нее указываю.
Я отвечу Вам, что бы внести ясность:

Managment (OOB) - используется для управления/конфигурирования системой.
Service (Telephony) - используется для предоставления сервисный услуг в сторону пользователей. Например, SIP, NOE, TFTP.
Redundancy (Cluster redundancy) - в разрезе кластера. Обеспечение отказоустойчивости системы (2-е ноды) при условии, что одна из нод вышла из строя.

Вопрос Redundancy был связан именно с Cluster redundancy.
   
 
Цитата
Александр Чалый написал:
   

Переформулирую вопрос, возможно использовать отдельный сетевой порт на Application Server для построения redundancy?
Другими словами, например, порт Application сервера eth0 - принимает и обрабатывает запросы (telephony, tftp и т.д), а через порт eth1 - синхронизация 2-х серверов (sync, db, мониторинг состояния)?
Нет. Нет ни такой возможности, ни собственно особой необходимости. А насчет разделения и пр. (менеджмент/сервис/дублирование) - посмотрите  в системной документации - что и куда может бегать. Не всех так просто поделить.
 
Если есть желание озадачиться живучестью системы, то можно сервера перевести в виртуальные машины с заменой лицензий. И там уже развлекаться средствами VmWare ESXi. Но надо учитывать, что не все функции во всех релизах работают, надо читать документацию на соответствуюший релиз.
 
Цитата
etc написал:
Если есть желание озадачиться живучестью системы, то можно сервера перевести в виртуальные машины с заменой лицензий. И там уже развлекаться средствами VmWare ESXi. Но надо учитывать, что не все функции во всех релизах работают, надо читать документацию на соответствуюший релиз.
Увы, инфраструктура физическая.  
Изменено: Alexander - 17.11.2016 15:25:25
 
Опять вы путаете и вносите термины.
Нету в терминологии ОХЕ кластера.
Процессор и нода в терминологии ОХЕ - разные вещи. Настолько, что в вашей АТС нода одна, а процессора два.

На физической инфраструктуре безопасность решается физическими методами, см. документ, на который я давал ссылку.
Или даже с развертыванием системы шифрования, через SSM/MSM.
Страницы: 1 2 След.
Читают тему