[ilia_2s]

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

 

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

[Ilya Evseev]

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

[ilia_2s]

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

[Ilya Evseev]

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

 

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

[ixi]

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

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

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

[f13]

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

[ilia_2s]

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

 

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

[f13]

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

[ilia_2s]

http://soft.mail.ru/pressrl_page.php?id=37671

[terrible]

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

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

[ilia_2s]

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

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

 

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

[Ilya Evseev]

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

Граница зависит от субъективного опыта.

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

[packetizer]

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

[ilia_2s]

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

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

 

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

 

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

 

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

 

 

 

 

 

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

 

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

 

 

[martin74]

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

[ilia_2s]

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

[s.lobanov]

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

[packetizer]

 

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

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

 

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

 

 

[ilia_2s]

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

[^rage^]

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

а можно примеры таких систем? хотя бы 3-4 штуки достаточно.

 

 

 

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

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

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

 

 

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

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

 

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

 

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

 

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

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

 

Это создает серьезный барбер в повышении уровня надежности больших или уже существующих приложений.

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

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

 

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

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

Edited May 31, 2010 by ^rage^

[packetizer]

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

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

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

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

 

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

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

[^rage^]

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

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

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

 

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

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

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

 

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

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

 

[ilia_2s]

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

а можно примеры таких систем? хотя бы 3-4 штуки достаточно.

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

 

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

 

 

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

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

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

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

 

 

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

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

 

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

 

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

 

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

 

 

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

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

 

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

 

Это создает серьезный барбер в повышении уровня надежности больших или уже существующих приложений.

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

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

Ну и что???

 

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

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

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

 

[^rage^]

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

[agabekov]

у хапе? высокой доступности? у них из 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.