Перейти к содержимому
Калькуляторы

Кластер HA для биллинга

Здравствуйте,

 

хочется держать биллинг на системе с истинной отказоустойчивостью: синхронизация вызовов ОС, общий разделяемый ресурс дисков, процессов, очередей задач, - доступные всем нодам одновременно, пока лучше VMS (VMScluster) ничего не нашел, интересует нечто аналогичное в nix-системах.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

http://linux-ha.org

 

Кроме того, ищем в Гугле "linux cluster migration failover". Находим:

1) http://www.redhat.com/cluster_suite/

2) http://www.novell.com/products/highavailability/

3) http://en.wikipedia.org/wiki/Veritas_Cluster_Server

 

Моё IMHO - если биллинг небольшой, делать кластеризацию надо не на уровне ОС, а на уровне сервисов: SQL, WWW и т.д. Если большой - то тем более.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Видимо вы не поняли о чем речь. Это скриптовые решения, по сути не имеющие отношения к HA. Может ли быть в представленных вами кластерах 10 нод? Могут ли ноды разделять производительности и балансировать нагрузку одновременно, в независимости от их количества? ответ - нет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Видимо вы не поняли о чем речь. Это скриптовые решения, по сути не имеющие отношения к HA.
Видимо вы не поняли о чем речь. Все сервисы в Линуксе и *BSD по сути имеют скриптовую обвязку, в т.ч. сервисы для обеспечения HA/LB.

 

Может ли быть в представленных вами кластерах 10 нод?
http://www.redhat.com/cluster_suite/

"Support for up to 16 nodes on Red Hat Enterprise Linux 5."

У остальных, по-видимому, количество не лимитировано (open source рулит), т.е. хоть 10, хоть 100.

 

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

Ищем в Гугле: "linux cluster process migration".

Находим:

http://en.wikipedia.org/wiki/Cluster_(computing)

" MOSIX, openMosix, Kerrighed, OpenSSI are full-blown clusters integrated into the kernel that provide for automatic process migration among homogeneous nodes. OpenSSI, openMosix and Kerrighed are single-system image implementations."

 

Плюс кластерные ФС, кластерные СУБД и т.д.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Два готовых варианта сценария HA для биллинга:

http://habrahabr.ru/blogs/sysadm/92221/

http://www.netup.ru/UTM5/articles.php?n=13

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ilia_2s аналога vms cluster нет, были попытки создать нечто подобное, например openmosix, но не в таком объёме как vms

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

ilia_2s аналога vms cluster нет, были попытки создать нечто подобное, например openmosix, но не в таком объёме как vms

 

Спасибо, а как вам костыль "kemari project"?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

хз, не пробовал, да и вряд ли уже попробую, ибо с xen на kvm переезжать собираюсь

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Моё IMHO - если биллинг небольшой, делать кластеризацию надо не на уровне ОС, а на уровне сервисов: SQL, WWW и т.д. Если большой - то тем более.

Эх, золотые слова, Юрий Бенедиктович!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Моё IMHO - если биллинг небольшой, делать кластеризацию надо не на уровне ОС, а на уровне сервисов: SQL, WWW и т.д. Если большой - то тем более.
Эх, золотые слова, Юрий Бенедиктович!

 

большой / небольшой, в цифрах сколько? у вас на уровне сервисов?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

большой / небольшой, в цифрах сколько? у вас на уровне сервисов?
Граница зависит от субъективного опыта.

Для меня средний начинается от 20 тысяч, большой - от 100.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Базу на iSCSI/FC сторадж а ОС виртуализировать и использовать средства вроде VMWare HA

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Базу на iSCSI/FC сторадж а ОС виртуализировать и использовать средства вроде VMWare HA

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

 

Моё IMHO - если биллинг небольшой, делать кластеризацию надо не на уровне ОС, а на уровне сервисов: SQL, WWW и т.д. Если большой - то тем более.

 

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

 

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

 

 

 

 

 

и использовать средства вроде VMWare HA

 

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

а там (в vSphere) еще и Fault Tolerance есть. У меня например радиус сервер на FT виртуалке крутится....

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

да, vSphere похоже подходит под задачу, и ценнк в $ 5k вполне нормален!

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

 

насколько я знаю (могу и ошибатся) при использовании FT сбои ОС (типа BSOD или kernel panic)

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

 

поэтому все же HA, об консистентности данных пусть заботится приложение

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

BSOD и без кластера может возникать, кто тогда поможет? А вот паники ядра бывают не састо в продакшн системах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Многие существующие системы всего-лишь активно зеркалят обновляющееся хранилище, позволяя приложениям произвести восстановление из неконсистентного состояния.
а можно примеры таких систем? хотя бы 3-4 штуки достаточно.

 

 

 

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

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

 

 

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

 

Например "размазать" базу абонентов по нескольким нодам(каждая из которых - сама по себе кластер, например ibm p570) на которой живет оракл. Логику положить на массив машин 1u или несколько блейдцентров.

 

Примерно так устроены платформы онлайн-биллинга у любимых многими ОПСОСов :)

 

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

ага. давайте вложимся в офигенно дорогое оборудование типа e25k или m9000, к ним ещё топовую emc symmetrix(а чтобы совсем-совсем все по взрослому - разнесем по двум ДЦ и сделаем полное дублирование).

 

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

Например, сейчас у одного вендора есть конвергентный биллинг на ~ 300 млн абонентов. В принципе, можно и больше, но пока нет оператора с такой абонентской базой.

 

BSOD и без кластера может возникать, кто тогда поможет? А вот паники ядра бывают не састо в продакшн системах
бывают. да и какая разница, грохнулось ядро или application, которое обрабатывает логику? эффект практически эквивалентен.
Изменено пользователем ^rage^

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

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

то что упало ядро гостевой ОС эту ситуацию механизмы виртуализации научились распознавать

и соответственно могут перезапустить гостевую ОС на другой ноде

 

а вот если упал сервис внутри гостевой ОС тут и приехали,

с точки зрания кластера виртуализации если работает гостевая ОС то все в порядке

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

то что упало ядро гостевой ОС эту ситуацию механизмы виртуализации научились распознавать

и соответственно могут перезапустить гостевую ОС на другой ноде

а толку? все равно мы уже упали.

 

а вот если упал сервис внутри гостевой ОС тут и приехали,

с точки зрания кластера виртуализации если работает гостевая ОС то все в порядке

в случае сервиса все проще: обвешиваемся супервизорами критичных процессов и в случае краха перезапускаем. сильно быстрее чем поднимать ОС+сервис.

 

тут вроде упоминался kemari - оно вообще жестоко по отношению к производительности. А синхронизация между нодами через GE - это слишком долго в таком случае.

Хорошо подходит на роль интерконнекта infiniband - но это уже другие $$

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Многие существующие системы всего-лишь активно зеркалят обновляющееся хранилище, позволяя приложениям произвести восстановление из неконсистентного состояния.
а можно примеры таких систем? хотя бы 3-4 штуки достаточно.

Конечно можно, это стораджи стукующиеся по сети или программные решения, типа DRBD.

 

Тот же VMware до vsphere и аналогичные продукты от citrix и symnantec.

 

 

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

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

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

 

 

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

 

Например "размазать" базу абонентов по нескольким нодам(каждая из которых - сама по себе кластер, например ibm p570) на которой живет оракл. Логику положить на массив машин 1u или несколько блейдцентров.

 

Примерно так устроены платформы онлайн-биллинга у любимых многими ОПСОСов :)

 

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

 

 

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

ага. давайте вложимся в офигенно дорогое оборудование типа e25k или m9000, к ним ещё топовую emc symmetrix(а чтобы совсем-совсем все по взрослому - разнесем по двум ДЦ и сделаем полное дублирование).

 

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

 

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

Например, сейчас у одного вендора есть конвергентный биллинг на ~ 300 млн абонентов. В принципе, можно и больше, но пока нет оператора с такой абонентской базой.

Ну и что???

 

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

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Так вы предлагаете откатиться на этап создания ISP, убить существующие решения нанять программеров и писать писать...
есть готовые решения от Amdocs/CBOSS/Comverse.

 

только опять же правильная кластеризация делается на основе ОС
стоп. что вы подразумеваете под кластеризацией? и чего хотим ей достичь: high availability, load balancing или же все сразу?

пока у меня сложилось впечатление, что вы говорите только о SSI, рассматривая другие варианты как идеологически неверные.

Имхо, SSI надо только там, где есть сильносвязанные данные(что для биллинга совершенно неверно).

 

но на днях я был на конференции HP по новому поколению серверов высокой доступности, так там были представители известных операторов сотовой связи и говорили, что у них используются решения, абсолютно противоположные вышим заявлениям!!!
у хапе? высокой доступности? у них из high end есть только superdome на итаниках(которые, фактически похоронены amd64/emt64).

Выпустить что-то новое они смогут как только интел родит свежих итаников.

Про представителей сотовиков: я писал про realtime billing(некоторые называют это rating'ом). Та часть, о которой упоминаете вы - это скорее всего выставление счетов итп вещи.

Там скучно: high end storage(например, hp eva 8400), sun fire e25k/m9000(на котором живет оракл) + ферма серверов с логикой.

 

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

Телекому на 50к абонентов и не нужны все эти кластеры/СХД. им может хватить двух машин с drbd.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

у хапе? высокой доступности? у них из high end есть только superdome на итаниках(которые, фактически похоронены amd64/emt64).

Выпустить что-то новое они смогут как только интел родит свежих итаников.

Про представителей сотовиков: я писал про realtime billing(некоторые называют это rating'ом). Та часть, о которой упоминаете вы - это скорее всего выставление счетов итп вещи.

Там скучно: high end storage(например, hp eva 8400), sun fire e25k/m9000(на котором живет оракл) + ферма серверов с логикой.

У HP есть NonStop - единственная альтернатива мэйнфреймам IBM с их GDPS.

Кстати, EVA - ничуть не high-end, скорее верхняя часть mid-range. Сравните спецификации хоть с XP24K.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.