Jump to content
Калькуляторы

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

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

 

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

Share this post


Link to post
Share on other sites

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 и т.д. Если большой - то тем более.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Видимо вы не поняли о чем речь. Это скриптовые решения, по сути не имеющие отношения к 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."

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
ilia_2s аналога vms cluster нет, были попытки создать нечто подобное, например openmosix, но не в таком объёме как vms

 

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

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

Share this post


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

 

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

Share this post


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

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
Базу на iSCSI/FC сторадж а ОС виртуализировать и использовать средства вроде VMWare HA

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

 

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

 

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

 

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

 

 

 

 

 

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

 

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

 

 

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

 

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

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

 

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

 

 

Share this post


Link to post
Share on other sites

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

Share this post


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

 

 

 

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

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

 

 

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

 

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

 

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

 

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

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

 

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

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

 

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

Share this post


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

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

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

 

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

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

Share this post


Link to post
Share on other sites
то что упало ядро гостевой ОС эту ситуацию механизмы виртуализации научились распознавать

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

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

 

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

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

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

 

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

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

 

Share this post


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

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

 

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

 

 

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

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

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

 

 

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

 

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

 

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

 

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

 

 

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

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

 

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

 

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

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

Ну и что???

 

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

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

 

Share this post


Link to post
Share on other sites
Так вы предлагаете откатиться на этап создания 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.

Share this post


Link to post
Share on other sites
у хапе? высокой доступности? у них из 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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this