Сразу скажу, что на Erlangе я ничего не писал, но присматриваюсь, не окажется ли проще реализовать резервируемую систему на нем вместо привычного C++.
Предположим простую задачу — обработка данных: есть 1) вход (пусть это будет всегда работающий сервер, с которого мы всегда можем прочитать число функцией getServerValue()); 2) Erlang программа на N компьютерах, которая должна раз в секунду вызывать getServerValue() и как-то ее обрабатывать (скажем, прибавлять единичку); 3) удаленный GUI на С++, запущенный на дополнительном компьютере (может тут имеет смысл добавить еще один локальный узел Erlang).
Теперь каждый из N компьютеров под Erlang системой может быть выключен в произвольный момент времени, но гарантируется, что хотя бы один работает всегда. Например, включены K1 K2 K3, через минуту работает только K2, еще через минуту K2 K3 (включился), потом К2 выключается и остается только K3, и т.д.
Какие посоветуете стандартные решения для безопасного автоматического распределения задач по компьютерам и переподключения GUI и насколько сложная получается программа и конфигурация супервизоров (мониторов) для перезапуска процессов?
Здравствуйте, mnf, Вы писали:
mnf>Добрый день!
[cut]
OTP Desing Principles читал?
К примеру эту главу?
По кластерам ещё вот эта статья наверное будет интересна.
А по поводу задачи — а сервер — это что? Почему не на Эрланге же? Для C++ можно сишную ноду организовать, на плюсах есть epp для более удобной работы с erl_interface.
Здравствуйте, mnf, Вы писали:
mnf>Добрый день!
mnf>Сразу скажу, что на Erlangе я ничего не писал, но присматриваюсь, не окажется ли проще реализовать резервируемую систему на нем вместо привычного C++.
We want to make a bank server. The bank server models the behaviour of a real bank. You can deposit money with the bank, query the status of your account and take money out of your account.
Banks, being suspicious by nature do not let you take out more money than you have in your account.
Banks are worried about security and like to offer round-the-clock services. If one of their computer fails they still like to serve their customers. In the event of a failure they like everything to work as if the failure had not occurred. In particular even of a failure they do not want you to remove more money from you account than you have deposited ...
Здравствуйте, Курилка, Вы писали:
К>К примеру эту главу?
Правильно ли я понимаю "Все задействованные ноды должны иметь одинаковое значение параметра distributed и параметра sync_nodes_timeout, иначе поведение системы не определено.", что нельзя к запущенной работающей системе добавить еще один резервный компьютер (cp4@cave) без перезапуска всего? Или предлагается заранее сделать config c сотней фиктивных узлов, а запускать на двух-трех? Тут хорошо рассказано про перезапуск всего приложения, но есть еще и контекст, который тоже нужно как-то передавать (в нашем примере, пусть требуется хранить 3 последних результата GetServerValue()).
К>По кластерам ещё вот эта статья наверное будет интересна.
Здесь немного больше про сохранение состояния: "The key idea is that exactly one server process is responsible for dispatching client requests and updating the states of all servers to keep them in sync.", но появляется вопрос про этот "sync" в случае локальных состояний и сообщений (а не только возвращаемых значений, которые, как мне показалось, и запоминаются). Например, в случае краха { sendCommand(1); sendCommand(2) }, нам придется полностью перезапустить этот процесс, и возможно контроллер получит подряд command(1), command(1), command(2), а то и command(1), command(2), command(1), command(2). Еще интереснее ситуация, когда сервер уже получил ответ gen_server_cluster:handle_call, но успел синхронизовать его только с частью узлов (развалился в update_all_server_state), тогда, в зависимости от того, кто возьмет управление, будут вызваны разные процедуры, некоторые дважды. Т.е. не совсем понятно, как организовывать "транзакционность". Может я не все понимаю (точнее ничего не понимаю в Erlang, как и писал раньше), но на этом этапе мне просто хотелось бы выяснить его применимость к данному классу задач не слишком вникая в детали реализации конкретных модулей. Н-р: "да, существует принципиальная возможность в 10-20 строчках кода организовать расширяемый кластер с полным сохранением внутреннего состояния в случае сбоя N-1 компьютеров", т.е. что-нибудь для начинающих.
Кстати, я не случайно упомянул в первоначальной задаче "раз в секунду" — можно ли из "Erlang soft real-time" сделать нормальный "hard real-time" какими-нибудь требованиями к программе и оборудованию (скажем, "если в программе самый длинный путь исполнения request/reply не более 100 команд, OS отдает не меньше 80% 1Ghz СPU на N — 1 гарантировано работающих компьютерах и в задаче нет вызовов внешних библиотек, то гарантирутся время отклика X мс."), и если нельзя, то почему?
К>А по поводу задачи — а сервер — это что? Почему не на Эрланге же?
Это удаленный "ввод", скажем контроллер, с которого можно прочитать данные по ModBus (два канала на два компьютера) или удаленный TCP сервис, и Erlang туда не влезет. Пока для простоты рассматривается теоретическая задача с тремя составляющими ("ввод", "обработка", "вывод"), реальная же будет чуть-чуть сложнее — десятки (может больше) IO контроллеров и управляющих клиентов и нужно понять, как это сделать проще и надежнее, может Erlang и не самый перспективный вариант (это и есть самый главный вопрос — "что же лучше").
Здравствуйте, mnf, Вы писали:
mnf>Здравствуйте, Курилка, Вы писали:
К>>К примеру эту главу? mnf>Правильно ли я понимаю "Все задействованные ноды должны иметь одинаковое значение параметра distributed и параметра sync_nodes_timeout, иначе поведение системы не определено.", что нельзя к запущенной работающей системе добавить еще один резервный компьютер (cp4@cave) без перезапуска всего? Или предлагается заранее сделать config c сотней фиктивных узлов, а запускать на двух-трех? Тут хорошо рассказано про перезапуск всего приложения, но есть еще и контекст, который тоже нужно как-то передавать (в нашем примере, пусть требуется хранить 3 последних результата GetServerValue()).
Если често — сам пока с такой схемой не разбирался. Вообще у меня в текущей задачке проще схема — есть центральный диспетчер/координатор и, скажем так, "рабочие ноды", которые регистрируются в центральном процессе. Делается довольно просто, но всёж самодельная схема. В отличие от приведённого в доках.
Ну а про фиктивные ноды — наверное да. Т.е. делается некий прогноз, до каких масштабов надо масштабировать, типа того.
А вообще лучше спроси в erlang questions, тебе авторы ответят заметно более обстоятельно и авторитетно, я думаю.
К>>По кластерам ещё вот эта статья наверное будет интересна. mnf>Здесь немного больше про сохранение состояния: "The key idea is that exactly one server process is responsible for dispatching client requests and updating the states of all servers to keep them in sync.", но появляется вопрос про этот "sync" в случае локальных состояний и сообщений (а не только возвращаемых значений, которые, как мне показалось, и запоминаются). Например, в случае краха { sendCommand(1); sendCommand(2) }, нам придется полностью перезапустить этот процесс, и возможно контроллер получит подряд command(1), command(1), command(2), а то и command(1), command(2), command(1), command(2). Еще интереснее ситуация, когда сервер уже получил ответ gen_server_cluster:handle_call, но успел синхронизовать его только с частью узлов (развалился в update_all_server_state), тогда, в зависимости от того, кто возьмет управление, будут вызваны разные процедуры, некоторые дважды. Т.е. не совсем понятно, как организовывать "транзакционность". Может я не все понимаю (точнее ничего не понимаю в Erlang, как и писал раньше), но на этом этапе мне просто хотелось бы выяснить его применимость к данному классу задач не слишком вникая в детали реализации конкретных модулей. Н-р: "да, существует принципиальная возможность в 10-20 строчках кода организовать расширяемый кластер с полным сохранением внутреннего состояния в случае сбоя N-1 компьютеров", т.е. что-нибудь для начинающих.
Чтот читал-читал, так и не смог понять описываемую ситуацию. Про 10-20 строчек сомневаюсь.
По поводу синхронизации состояния есть ещё один вариант — mnesia, правда это скорей для заметных его объёмах и там ещё надо решать вопросы подключения новых нод (дабы синхронизовались таблицы).
+ замечание: в эрланге нет по сути понятия компьютеров, есть ноды, в пределах одного хоста может быть их несколько. mnf>Кстати, я не случайно упомянул в первоначальной задаче "раз в секунду" — можно ли из "Erlang soft real-time" сделать нормальный "hard real-time" какими-нибудь требованиями к программе и оборудованию (скажем, "если в программе самый длинный путь исполнения request/reply не более 100 команд, OS отдает не меньше 80% 1Ghz СPU на N — 1 гарантировано работающих компьютерах и в задаче нет вызовов внешних библиотек, то гарантирутся время отклика X мс."), и если нельзя, то почему?
Вопрос поднимался несколько раз, поищи, например, здесь. Насколько помню строго хард сделать не получится, были какие-то заморочки с приоритетами планировщика Эрланга.
К>>А по поводу задачи — а сервер — это что? Почему не на Эрланге же? mnf>Это удаленный "ввод", скажем контроллер, с которого можно прочитать данные по ModBus (два канала на два компьютера) или удаленный TCP сервис, и Erlang туда не влезет. Пока для простоты рассматривается теоретическая задача с тремя составляющими ("ввод", "обработка", "вывод"), реальная же будет чуть-чуть сложнее — десятки (может больше) IO контроллеров и управляющих клиентов и нужно понять, как это сделать проще и надежнее, может Erlang и не самый перспективный вариант (это и есть самый главный вопрос — "что же лучше").
Тут подобными задачами вроде как gandalfgrey занимался и был вроде как очень доволен Эрлангом. Т.к. я не он, то подробностей не скажу.
Здравствуйте, Gaperton, Вы писали:
mnf>>Сразу скажу, что на Erlangе я ничего не писал, но присматриваюсь, не окажется ли проще реализовать резервируемую систему на нем вместо привычного C++.
G>Читай короткий туториал G>http://www.sics.se/~joe/tutorials/robust_server/robust_server.html
Такую систему с двумя полностью независимыми серверами, которые даже не синхронизируют свои внутренние состояния, можно написать практически на чем угодно. В чем преимущества именно Erlang непонятно (а они несомненно должны быть, просто эта статья не о том). os:cmd("rm -rf *") в distributed Erlang вообще пугает, радует, что можно обойтись без него.
G>Читай длинный и исчерпывающий мануал "Making reliable distributed systems in the presence of software errors" G>http://www.erlang.org/download/armstrong_thesis_2003.pdf
eao197>... не дает конкретных рецептов построения систем на Erlang-е.
Не могу не согласиться
Здравствуйте, mnf, Вы писали:
mnf>Здравствуйте, Gaperton, Вы писали:
mnf>>>Сразу скажу, что на Erlangе я ничего не писал, но присматриваюсь, не окажется ли проще реализовать резервируемую систему на нем вместо привычного C++.
G>>Читай короткий туториал G>>http://www.sics.se/~joe/tutorials/robust_server/robust_server.html mnf>Такую систему с двумя полностью независимыми серверами, которые даже не синхронизируют свои внутренние состояния, можно написать практически на чем угодно. В чем преимущества именно Erlang непонятно (а они несомненно должны быть, просто эта статья не о том). os:cmd("rm -rf *") в distributed Erlang вообще пугает, радует, что можно обойтись без него.
Сделать можно все, что угодно и на чем угодно. Преимещество именно Эрланга в том, что на нем отказоустойчивая распределенка делается проще. Пример в туториале простой как раз потому, чтобы вы поняли, и могли повторить на чем угодно, и сравнить — сложный пример вы все равно не поймете. Сервера в этом простом примере, кстати, синхронизируют свое внутреннее состояние. Если вас distributed erlang пугает, и вас радует, что можно обойтись без него — обходитесь без него, в чем проблема . Кто заставляет-то — предметом первой необходимости Erlang у нас не является пока слава богу.
G>>Читай длинный и исчерпывающий мануал "Making reliable distributed systems in the presence of software errors" G>>http://www.erlang.org/download/armstrong_thesis_2003.pdf mnf>eao197>... не дает конкретных рецептов построения систем на Erlang-е. mnf>Не могу не согласиться
Соглашайтесь . Пользуйтесь конкретными рецептами построения отказоустойчивых систем на С++ — их, верно, сильно больше, и головой наверно при этом думать не надо .
Здравствуйте, Курилка, Вы писали:
К>Вопрос поднимался несколько раз, поищи, например, здесь. Насколько помню строго хард сделать не получится, были какие-то заморочки с приоритетами планировщика Эрланга.
Вроде бы есть порты Ерланга под QNX и что-то еще, в которых люди правили планировщик и сборку мусора. Получился, по описанию, ПОЧТИ ХАРД реалтайм.
К>Тут подобными задачами вроде как gandalfgrey занимался и был вроде как очень доволен Эрлангом. Т.к. я не он, то подробностей не скажу.
Гм. Не совсем такими, пожалуй. У меня тоже была распределенная сборка и обработка данных, но организация системы совершенно другая.
1. Есть Ерланговские ноды, непосредственно забирающие данные с прибора по TCP/IP. Они могут отвечать на запрос сервера по архивам, но текущие они заливают сами в сервер.
2. Ежели сервер окочурился по какой-то причине ( питание исчезло, сеть легла, глюки... ), то через некое время происходит переключение на следующий сервер из списка.
3. Если сдохла нода нижнего уровня, то сервер ее перезапускает
4. Перезапуском серверов занимается активный в данный момент сервер-концентратор, с которого и берут данные диспетчеры. В него же заливаются данные от серверов среднего уровня, серверов вычислений и пр.
Это очень упрощенная схема, конечно. Но работает очень устойчиво
Здравствуйте, Gaperton, Вы писали:
G>Сделать можно все, что угодно и на чем угодно. Преимещество именно Эрланга в том, что на нем отказоустойчивая распределенка делается проще. Пример в туториале простой как раз потому, чтобы вы поняли, и могли повторить на чем угодно, и сравнить — сложный пример вы все равно не поймете. Сервера в этом простом примере, кстати, синхронизируют свое внутреннее состояние. Если вас distributed erlang пугает, и вас радует, что можно обойтись без него — обходитесь без него, в чем проблема . Кто заставляет-то — предметом первой необходимости Erlang у нас не является пока слава богу.
Оно конечно ! Если уж гайки отвинчивают при помощи двух отверток, то без Ерланга тем более можно обойтись 8))
G>Соглашайтесь . Пользуйтесь конкретными рецептами построения отказоустойчивых систем на С++ — их, верно, сильно больше, и головой наверно при этом думать не надо .
Извинитття ! Работающих рецептов для С++ маловато, и насколько же они все заморочены ! Вот головой в этом случае точно думать не надо будет — ею надо будет колотиться об стол в расстройстве.
Между прочим, даже на Тикле получается в разы проще, чем на С++, всякая распределенность. Вот на предыдущей работе оставил я скриптик на Тикле ( около 200 строк ), который покрывает значительную часть функциональности софтины, написанной на С++ и весящей под 100 К строк. Причем работает УСТОЙЧИВЕЕ...
Так что не надо давать "Вредных Советов". Г.Остер это сделал уже давно
Здравствуйте, Gaperton, Вы писали:
G>Читай короткий туториал G>http://www.sics.se/~joe/tutorials/robust_server/robust_server.html
Туториал хороший, только не рассматривается одна проблема — "split brain". Если у нас теряется связь между первым и вторым сервером (но сами серверы при этом работают!), то у нас в итоге получится inconsistent база-данных.
Для решения этой проблемы можно использовать такие методы: Кворумный диск — сервер может работать, только если у него есть доступ к этому диску. Добавляет single-point-of-failure, но на практике достаточно надежно.
Работать только если у нас есть связь с более чем 50% узлов в кластере (для этого нужно минимум три узла).
Различные комбинации на эту тему: работать, если у нас есть связь с более чем 50% кворумных дисков, работать только если есть связь с кворумным диском или более 50% узлов и т.п.
Здравствуйте, Gaperton, Вы писали:
G>Сделать можно все, что угодно и на чем угодно. Преимещество именно Эрланга в том, что на нем отказоустойчивая распределенка делается проще. Пример в туториале простой как раз потому, чтобы вы поняли, и могли повторить на чем угодно, и сравнить — сложный пример вы все равно не поймете.
Куда уж нам уж. Мы академиев не кончали.
На Эрланге коммерческих проектов с высокими требованиям по надежности не делали. Как, полагаю, и ты.
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Читай короткий туториал G>>http://www.sics.se/~joe/tutorials/robust_server/robust_server.html C>Туториал хороший, только не рассматривается одна проблема — "split brain". Если у нас теряется связь между первым и вторым сервером (но сами серверы при этом работают!), то у нас в итоге получится inconsistent база-данных.
Интересно, как в этом случае ведет себя мнезия — ведь это она выполняет репликацию. Я думаю, на самом деле все будет в порядке. Но правда любопытно.
C>Для решения этой проблемы можно использовать такие методы: C> C> Кворумный диск — сервер может работать, только если у него есть доступ к этому диску. Добавляет single-point-of-failure, но на практике достаточно надежно.
Ну, дисков они не разделяют. Мнезия реплицирует таблицы через эрланговские сообщения — двухфазным или трехфазным коммитом.
Вообще, в эрланге этому подходу соответствует супервижн три, достаточно грамотно его построить, ничего другого не нужно.
C> Работать только если у нас есть связь с более чем 50% узлов в кластере (для этого нужно минимум три узла).
Узлы кластера можно увязать в супервижн три, и держать резервного супервизора — тогда все просто и понятно — мы трактуем недоступный узел как отвалившийся. Думаю, так будет нормально. Опять же, интересно, как такие проблемы решает мнезия.
C> Различные комбинации на эту тему: работать, если у нас есть связь с более чем 50% кворумных дисков, работать только если есть связь с кворумным диском или более 50% узлов и т.п.
Ну, типа того. В эрланге стратегию фолт-толеранса полностью выбирает программист, тока опять же — супервижн вместо кворумных дисков. C>
Здравствуйте, eao197, Вы писали:
G>>Сделать можно все, что угодно и на чем угодно. Преимещество именно Эрланга в том, что на нем отказоустойчивая распределенка делается проще. Пример в туториале простой как раз потому, чтобы вы поняли, и могли повторить на чем угодно, и сравнить — сложный пример вы все равно не поймете.
E>Куда уж нам уж. Мы академиев не кончали.
Что-то не понял иронии. Тебе что, исходники megaco, inets, и mnesia читать проще простого туториала с задачей, которую ты легко на любом языке повторишь? Да флаг тебе в руки, господи. Бери стандартную либу и читай исходники, умный ты наш. Академиев он блин не кончал.
E>На Эрланге коммерческих проектов с высокими требованиям по надежности не делали. Как, полагаю, и ты.
Не делал, говоришь? Так чего выступаешь? Может — сказать чего хочешь, а?
Здравствуйте, gandalfgrey, Вы писали:
G>>Соглашайтесь . Пользуйтесь конкретными рецептами построения отказоустойчивых систем на С++ — их, верно, сильно больше, и головой наверно при этом думать не надо . G>Извинитття ! Работающих рецептов для С++ маловато, и насколько же они все заморочены ! Вот головой в этом случае точно думать не надо будет — ею надо будет колотиться об стол в расстройстве.
Да лана, пусть себе колотится, а мы, обезьянки, посмотрим! Этож прикольно.
G>Между прочим, даже на Тикле получается в разы проще, чем на С++, всякая распределенность. Вот на предыдущей работе оставил я скриптик на Тикле ( около 200 строк ), который покрывает значительную часть функциональности софтины, написанной на С++ и весящей под 100 К строк. Причем работает УСТОЙЧИВЕЕ... G>Так что не надо давать "Вредных Советов". Г.Остер это сделал уже давно
Почему это не надо? Очень даже надо . Тебе надо, чтобы все подряд на Эрланге писали? Я вот тут, допустим идеи для стартапа обдумываю разные, и в мои планы совершенно не входит массовое проникновение Эрланга в мэйнстрим. Пусть пишут на Сишарпе, или голом С. Вот С++ с Йавой — это, блин, уже хуже, но тоже ничего.
Здравствуйте, Gaperton, Вы писали:
G>Да лана, пусть себе колотится, а мы, обезьянки, посмотрим! Этож прикольно.
Как-то это негуманно...Поглумиться, конечно, тоже неплохо, но надо и меру знать
G>Почему это не надо? Очень даже надо . Тебе надо, чтобы все подряд на Эрланге писали? Я вот тут, допустим идеи для стартапа обдумываю разные, и в мои планы совершенно не входит массовое проникновение Эрланга в мэйнстрим. Пусть пишут на Сишарпе, или голом С. Вот С++ с Йавой — это, блин, уже хуже, но тоже ничего.
А что Жабба ? Она никак не спасет отцов русской демократии. Мой сотоварищ, нынче работающий в другой конторе, недавно писал — у них изваяли CRM на Жабе, так ей не хватает 8 ГИГ памяти ( оперативной ), чтобы запустииться. Не работать, нет — просто запуститься. Так что тот коллектив как бы разработчиков в печали и унынии...
И вообще, Жаба — это "КОБОЛ наносит ответный удар". Таких же зомбей плодит ( или они сами туда тянутся ). "Fresh BRAINS !" (с) Возвращение живых мертвецофф 5
Здравствуйте, gandalfgrey, Вы писали:
G>И вообще, Жаба — это "КОБОЛ наносит ответный удар". Таких же зомбей плодит ( или они сами туда тянутся ). "Fresh BRAINS !" (с) Возвращение живых мертвецофф 5
Здравствуйте, Gaperton, Вы писали:
G>Интересно, как в этом случае ведет себя мнезия — ведь это она выполняет репликацию. Я думаю, на самом деле все будет в порядке. Но правда любопытно.
Я не использовал Мнезию для серьезной работы, так что не смотрел туда особо внимательно.
Сейчас попробовал найти в доке — похоже, что никак не обрабатывает:
There are several occasions when Mnesia may detect that the network has been partitioned due to a
communication failure.
One is when Mnesia already is up and running and the Erlang nodes gain contact again. Then Mnesia
will try to contact Mnesia on the other node to see if it also thinks that the network has been
partitioned for a while. If Mnesia on both nodes has logged mnesia down entries from each other,
Mnesia generates a system event, called inconsistent database, running partitioned network,
Node which is sent to Mnesia’s event handler and other possible subscribers. The default event handler
reports an error to the error logger.
...
C>>Для решения этой проблемы можно использовать такие методы: C>> Кворумный диск — сервер может работать, только если у него есть доступ к этому диску. Добавляет single-point-of-failure, но на практике достаточно надежно. G>Ну, дисков они не разделяют. Мнезия реплицирует таблицы через эрланговские сообщения — двухфазным или трехфазным коммитом. G>Вообще, в эрланге этому подходу соответствует супервижн три, достаточно грамотно его построить, ничего другого не нужно.
Кворумный диск (точнее, вообще любой кворумный ресурс) используется и если нет разделения дисков, он просто позволяет гарантировать, что система находится в consistent state.
C>> Работать только если у нас есть связь с более чем 50% узлов в кластере (для этого нужно минимум три узла). G>Узлы кластера можно увязать в супервижн три, и держать резервного супервизора — тогда все просто и понятно — мы трактуем недоступный узел как отвалившийся. Думаю, так будет нормально. Опять же, интересно, как такие проблемы решает мнезия.
Насколько я понимаю, supervisor tree не решает эту проблему — просто сдвигает ее со стороны worker nodes на сторону супервизоров. То есть, если у нас отказывает корневой супервизор, то нам надо решить кому стать следующим корнем. И там все те же самые проблемы.
Кстати, мы вообще смотрели как проще делать реплицируемую базу. В итоге, остановились на кластерной файловой системе OCFS2 с избыточной связностью хостов. Там сценарий со split-brain возможен, но для этого требуются очень нереальные условия (падение сразу нескольких интерфейсов на разных хостах, причем одновременно).
Здравствуйте, Курилка, Вы писали:
К>Смотрится оригинально после статеек аля Erlang, the next Java
Посмотрел. Мужик пишет, что Ерланг — это круто, и он будет следующей Жабой по ПОПУЛЯРНОСТИ и весомости. То, что на Жабе пишут все, кому не лень — это я и так отчетливо вижу. На КОБОЛе писали еще больше...
А упоминания про ООП, который в Ерланге моделируется процессами — тоже известная и не новая песня, хотя и верная во многом.
Жаба очень хороша для написания монстров, выползших из упокоищ. Ползущих медленно и распадающихся на ходу. Насколько я помню, самый большой проект на Ерланге — 1.2 М строк ( это пресловутый AXD 301 ). 800 К строк на Жабе — это проект среднего размера, или даже меньше.
Здравствуйте, gandalfgrey, Вы писали:
G>Посмотрел. Мужик пишет, что Ерланг — это круто, и он будет следующей Жабой по ПОПУЛЯРНОСТИ и весомости. То, что на Жабе пишут все, кому не лень — это я и так отчетливо вижу. На КОБОЛе писали еще больше...
Эээ, у тебя есть оф. статистика?
Имхо тогда программеров было как минимум на пару порядков меньше G>А упоминания про ООП, который в Ерланге моделируется процессами — тоже известная и не новая песня, хотя и верная во многом. G>Жаба очень хороша для написания монстров, выползших из упокоищ. Ползущих медленно и распадающихся на ходу. Насколько я помню, самый большой проект на Ерланге — 1.2 М строк ( это пресловутый AXD 301 ). 800 К строк на Жабе — это проект среднего размера, или даже меньше.
Ну дак это пока, хотя конечно он более краток, но нет предела индусописательству
А пресловутый вроде 2 млн строк по последним цифрам вроде
Здравствуйте, gandalfgrey, Вы писали:
G>А упоминания про ООП, который в Ерланге моделируется процессами — тоже известная и не новая песня, хотя и верная во многом. G>Жаба очень хороша для написания монстров, выползших из упокоищ. Ползущих медленно и распадающихся на ходу. Насколько я помню, самый большой проект на Ерланге — 1.2 М строк ( это пресловутый AXD 301 ). 800 К строк на Жабе — это проект среднего размера, или даже меньше.
Проблема в том, что на Эрланге нет многих необходимых инструментов. Телефонный свич — это, конечно, круто. Но вот только это практически полностью self-contained система, ей кроме самого Erlang'а ничего больше и не надо.
А как потребуется делать GUI, писать серверы с распределенными транзакциями между разными источниками данных, использовать надежный messaging — тут Эрлангу сразу станет далеко не так все хорошо.
Здравствуйте, Курилка, Вы писали:
К>Эээ, у тебя есть оф. статистика? К>Имхо тогда программеров было как минимум на пару порядков меньше
Понятно, что я имею в виду пропорцию от общего числа. Абсолютные цифры тут действительно никак не сравнимы
К>Ну дак это пока, хотя конечно он более краток, но нет предела индусописательству
Ой, как это верно... Одно радует, что люди с индусскими наклонностями не пишут на Ерланге. По крайней мере, пока не пишут К>А пресловутый вроде 2 млн строк по последним цифрам вроде
Дык, новая версия, поди ? По той старой модели была же подробная раскладка по языкам и строкам
Здравствуйте, Cyberax, Вы писали:
C>Проблема в том, что на Эрланге нет многих необходимых инструментов. Телефонный свич — это, конечно, круто. Но вот только это практически полностью self-contained система, ей кроме самого Erlang'а ничего больше и не надо.
На самом деле — есть очень многое. Не надо забывать, что стандартная поставка в дистрибутиве — это всего лишь наиболее часто используемые библиотеки. Куча всякого добра лежит в Jungerl'е и других сборниках. Конечно, есть и отсутствующие элементы — как и везде
C>А как потребуется делать GUI, писать серверы с распределенными транзакциями между разными источниками данных, использовать надежный messaging — тут Эрлангу сразу станет далеко не так все хорошо.
Для ГУЯ часто используют Тикль, который очень хорошо и легко сопрягается с Ерлангом.
Подменить механизм распределения сообщений — это даже в штатной документации описано.
Вот распределенные транзакции — тут ничего не скажу. Стандартных средств вроде бы действительно нет.
Здравствуйте, gandalfgrey, Вы писали:
G>А что Жабба ? Она никак не спасет отцов русской демократии. Мой сотоварищ, нынче работающий в другой конторе, недавно писал — у них изваяли CRM на Жабе, так ей не хватает 8 ГИГ памяти ( оперативной ), чтобы запустииться. Не работать, нет — просто запуститься. Так что тот коллектив как бы разработчиков в печали и унынии...
Чем больше узнаю про этих замечательных парней, тем больше понимаю, что дело вовсе не в Java. Даже наоборот, Java -- это именно то, что позволяет проекту двигаться дальше. Поскольку если бы они писали на C++, то уже давно бы достигли предела, когда любая попытка компиляции завершается сообщением "Internal Compiler Error".
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Cyberax, Вы писали: C>>Проблема в том, что на Эрланге нет многих необходимых инструментов. Телефонный свич — это, конечно, круто. Но вот только это практически полностью self-contained система, ей кроме самого Erlang'а ничего больше и не надо. G>На самом деле — есть очень многое. Не надо забывать, что стандартная поставка в дистрибутиве — это всего лишь наиболее часто используемые библиотеки. Куча всякого добра лежит в Jungerl'е и других сборниках. Конечно, есть и отсутствующие элементы — как и везде
Не такое уж и многое, на самом деле. Да библиотека неплохая, но вот для специфических случаев — дыры. Скажем вот последнее сообщение из мейллиста — человек хочет BerkleyDB к эрлангу прикрутить, ответа нет и я думаю скорее всего придётся писать обёртку самому. Такие случаи имхо нередки. Ну наверное они более редки для задач родных эрлангу телекома, а вот когда выходим уже в другие области, то увы — обилия либ как для явы не наблюдается.
И ещё — кроме джангерла есть CEAN, имхо заметно удобней
Здравствуйте, eao197, Вы писали:
E>Чем больше узнаю про этих замечательных парней, тем больше понимаю, что дело вовсе не в Java. Даже наоборот, Java -- это именно то, что позволяет проекту двигаться дальше. Поскольку если бы они писали на C++, то уже давно бы достигли предела, когда любая попытка компиляции завершается сообщением "Internal Compiler Error".
Дело не в самой Жабе, а в том, что подобное тянется к подобному. Почему они пишут на Жабе — вот в чем вопрос, и это вопрос психологии. Хотя Жаба тоже, надо заметить, не сильно способствует пониманию Дао. Вот на С++ они бы уже давно уткнулись в 5-ый угол и поняли, что крив их подход. А Жаба позволяет лепить, и лепить, и лепить дальше, нимало не задумываясь хотя бы о физических ограничениях.
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, eao197, Вы писали:
E>>Чем больше узнаю про этих замечательных парней, тем больше понимаю, что дело вовсе не в Java. Даже наоборот, Java -- это именно то, что позволяет проекту двигаться дальше. Поскольку если бы они писали на C++, то уже давно бы достигли предела, когда любая попытка компиляции завершается сообщением "Internal Compiler Error". G>Дело не в самой Жабе, а в том, что подобное тянется к подобному. Почему они пишут на Жабе — вот в чем вопрос, и это вопрос психологии. Хотя Жаба тоже, надо заметить, не сильно способствует пониманию Дао. Вот на С++ они бы уже давно уткнулись в 5-ый угол и поняли, что крив их подход. А Жаба позволяет лепить, и лепить, и лепить дальше, нимало не задумываясь хотя бы о физических ограничениях.
А ты не думаешь, что Эрланг также позволит "лепить, и лепить, и лепить дальше" при наличии соотвтетсвующей раскрутки и т.п.?
Скажем будет не 10 слоёв приложения как в яве, а 100 процессов для реализации одного логического процесса?
Здравствуйте, Курилка, Вы писали:
К>Не такое уж и многое, на самом деле. Да библиотека неплохая, но вот для специфических случаев — дыры. Скажем вот последнее сообщение из мейллиста — человек хочет BerkleyDB к эрлангу прикрутить, ответа нет и я думаю скорее всего придётся писать обёртку самому. Такие случаи имхо нередки. Ну наверное они более редки для задач родных эрлангу телекома, а вот когда выходим уже в другие области, то увы — обилия либ как для явы не наблюдается.
Вообще-то еще весной фирма, которая сделала Беркли back-end к Мнезии, обещалась выложить вскоре либу. Эта контора называется Синапс, ежели я не путаю. А просто либа для БерклиДБ есть в составе тулзы для создания драйверов.
Но, конечно, либ гораздо меньше...
К>И ещё — кроме джангерла есть CEAN, имхо заметно удобней
Видел, но не пробовал
Здравствуйте, Курилка, Вы писали:
К>А ты не думаешь, что Эрланг также позволит "лепить, и лепить, и лепить дальше" при наличии соотвтетсвующей раскрутки и т.п.? К>Скажем будет не 10 слоёв приложения как в яве, а 100 процессов для реализации одного логического процесса?
Я возлагаю большие надежды на психологическую несовместимость индусоидов и немайнстримных языков. Что-то я не слышал про "быдлокодеров" на Лиспе...
Как минимум, я полагаю, что оные индусоерлангеры появятся нескоро
Здравствуйте, gandalfgrey, Вы писали:
К>>И ещё — кроме джангерла есть CEAN, имхо заметно удобней G>Видел, но не пробовал
По мне удобная вещь, и вроде чуть обкаталась (были вначале глючки с зависимостями и т.п.). К примеру установка какого-нибудь модуля (скажем мнезии, по дефолтному минимуму там вроде kernel, stdlib и cean только стоит) выглядит:
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>А ты не думаешь, что Эрланг также позволит "лепить, и лепить, и лепить дальше" при наличии соотвтетсвующей раскрутки и т.п.? К>>Скажем будет не 10 слоёв приложения как в яве, а 100 процессов для реализации одного логического процесса? G>Я возлагаю большие надежды на психологическую несовместимость индусоидов и немайнстримных языков. Что-то я не слышал про "быдлокодеров" на Лиспе... G>Как минимум, я полагаю, что оные индусоерлангеры появятся нескоро
Ну яж говорил "при наличии соотвтетсвующей раскрутки и т.п.", поэтому ситуация гипотетическая (надеюсь такой в ближайшем будущем и останется).
Просто при таком раскладе при всех плюсах Эрланга вырисовывается имхо минусик — многое надо писать руками (при наличии уже опробированных готовых решений на той же яве), как минимум обёртку для сишной либы.
Здравствуйте, gandalfgrey, Вы писали:
G>Я возлагаю большие надежды на психологическую несовместимость индусоидов и немайнстримных языков. Что-то я не слышал про "быдлокодеров" на Лиспе...
Думаю в сырцах промышленных Lisp-ов можно найти такое, что мало не покажется. По крайней мере в VisualWorks Smalltalk всяких гавно-мест вагон и мелкая тележка. Хотя может это и отголоски популярности начала 90-х — вроде бы новый код понятный и аккуратный.
Здравствуйте, Курилка, Вы писали:
К>Ну яж говорил "при наличии соотвтетсвующей раскрутки и т.п.", поэтому ситуация гипотетическая (надеюсь такой в ближайшем будущем и останется).
Подольше бы не помешало сохранить текущее положение вещей
К>Просто при таком раскладе при всех плюсах Эрланга вырисовывается имхо минусик — многое надо писать руками (при наличии уже опробированных готовых решений на той же яве), как минимум обёртку для сишной либы.
Такова селява — либы не берутся из ниоткуда, их кто-то пишет, причем только когда приспичит
Здравствуйте, gandalfgrey, Вы писали:
G>Здравствуйте, Курилка, Вы писали:
К>>Просто при таком раскладе при всех плюсах Эрланга вырисовывается имхо минусик — многое надо писать руками (при наличии уже опробированных готовых решений на той же яве), как минимум обёртку для сишной либы. G>Такова селява — либы не берутся из ниоткуда, их кто-то пишет, причем только когда приспичит
В том и дело. Просто это фактор играющий против Эрланга, другое дело, что нужно рассматривать конкретные ситуации и в них уже выбирать значимые факторы.
Здравствуйте, gandalfgrey, Вы писали:
C>>Проблема в том, что на Эрланге нет многих необходимых инструментов. Телефонный свич — это, конечно, круто. Но вот только это практически полностью self-contained система, ей кроме самого Erlang'а ничего больше и не надо. G>На самом деле — есть очень многое. Не надо забывать, что стандартная поставка в дистрибутиве — это всего лишь наиболее часто используемые библиотеки. Куча всякого добра лежит в Jungerl'е и других сборниках. Конечно, есть и отсутствующие элементы — как и везде
Проблема в том, что этих элементов МНОГО. Недавно нарвался на отсутствие нормального XSLT в Erlang.
В Java же есть библиотеки для всего.
C>>А как потребуется делать GUI, писать серверы с распределенными транзакциями между разными источниками данных, использовать надежный messaging — тут Эрлангу сразу станет далеко не так все хорошо. G>Для ГУЯ часто используют Тикль, который очень хорошо и легко сопрягается с Ерлангом.
TCL многим (в том числе и мне ) не нравится. Хотя недавно для wxWidgets он появился.
G>Подменить механизм распределения сообщений — это даже в штатной документации описано.
Нет. Нужны системы уровня MSMQ или http://activemq.apache.org/ — их для Erlang'а нет. Естественно, на Erlang'е их проще будет написать, чем на Java — но их еще нужно написать.
G>Вот распределенные транзакции — тут ничего не скажу. Стандартных средств вроде бы действительно нет.
И вряд ли будут в разумное время.
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandalfgrey, Вы писали:
G>>Подменить механизм распределения сообщений — это даже в штатной документации описано. C>Нет. Нужны системы уровня MSMQ или http://activemq.apache.org/ — их для Erlang'а нет. Естественно, на Erlang'е их проще будет написать, чем на Java — но их еще нужно написать.
А вот RabbitMQ не пойдёт? (сильно не разбирался с ним)
К>>>Просто при таком раскладе при всех плюсах Эрланга вырисовывается имхо минусик — многое надо писать руками (при наличии уже опробированных готовых решений на той же яве), как минимум обёртку для сишной либы. G>>Такова селява — либы не берутся из ниоткуда, их кто-то пишет, причем только когда приспичит
К>В том и дело. Просто это фактор играющий против Эрланга, другое дело, что нужно рассматривать конкретные ситуации и в них уже выбирать значимые факторы.
Есть надежда, что многое скорее рано, чем поздно для эрланга появится, оставаясь при этом в рамках немейнстримности.
Здравствуйте, Mamut, Вы писали:
К>>>>Просто при таком раскладе при всех плюсах Эрланга вырисовывается имхо минусик — многое надо писать руками (при наличии уже опробированных готовых решений на той же яве), как минимум обёртку для сишной либы. G>>>Такова селява — либы не берутся из ниоткуда, их кто-то пишет, причем только когда приспичит
К>>В том и дело. Просто это фактор играющий против Эрланга, другое дело, что нужно рассматривать конкретные ситуации и в них уже выбирать значимые факторы.
M>Есть надежда, что многое скорее рано, чем поздно для эрланга появится, оставаясь при этом в рамках немейнстримности.
Ну мечтать не вредно
Много что появляется, но до завалов явовских либ ещё ой как далеко...
M>>Есть надежда, что многое скорее рано, чем поздно для эрланга появится, оставаясь при этом в рамках немейнстримности.
К>Ну мечтать не вредно К>Много что появляется, но до завалов явовских либ ещё ой как далеко...
Не спорю, но большая активность на Planet Erlang и немалое количество проектов на Google Code позволяют надеяться
M>Есть надежда, что многое скорее рано, чем поздно для эрланга появится, оставаясь при этом в рамках немейнстримности.
это две противоречащие друг другу вещи. скорее есть надежда на то, что эрланг станет поппулярней и заменит, например, нынешние веб-языки. в самом деле, чем он хуже того же руби (наилучшего из них)?
Здравствуйте, Cyberax, Вы писали:
C>А как потребуется делать GUI, писать серверы с распределенными транзакциями между разными источниками данных, использовать надежный messaging — тут Эрлангу сразу станет далеко не так все хорошо.
Что касается GUI — это некритично (написать его на PyGTK или GTK/С++ мне было бы даже проще). Хотелось бы узнать Ваше мнение по поводу первоначальной задачи, которая в очень упрощенной форме звучала так: "существует ли принципиальная возможность в 10-20 строчках кода организовать расширяемый кластер с полным сохранением внутреннего состояния в случае сбоя N-1 компьютеров" и "требуется хранить 3 последних результата GetServerValue()". Т.е. мы пишем программу для обработки данных у которой есть внутреннее состояние, и его надо синхронизировать между всеми на случай выключения узла. Один из советов был хранить все в mnesia, но, как я понял из Выших сообщений про "brain-split", это нельзя назвать надежным механизмом, и никаких других более-менее стандартных средств тоже нет? Казалось бы не очень сложная задача для "language designed to support robust, reliable, distributed near real-time applications".
Здравствуйте, mnf, Вы писали:
C>>А как потребуется делать GUI, писать серверы с распределенными транзакциями между разными источниками данных, использовать надежный messaging — тут Эрлангу сразу станет далеко не так все хорошо. mnf>Что касается GUI — это некритично (написать его на PyGTK или GTK/С++ мне было бы даже проще). Хотелось бы узнать Ваше мнение по поводу первоначальной задачи, которая в очень упрощенной форме звучала так: "существует ли принципиальная возможность в 10-20 строчках кода организовать расширяемый кластер с полным сохранением внутреннего состояния в случае сбоя N-1 компьютеров" и "требуется хранить 3 последних результата GetServerValue()".
Я такое могу на Java сделать Смотрим: http://www.terracotta.org/
Тут главное, на самом деле, иметь кластерное хранилище. Попробуй сделать расширяемый кластер и прочее бла-бла на Erlang без Mnesia или MySQL в качетсве хранилища.
Сам по себе Erlang с системами супервизоров и передачи сообщений имеет некоторые примитивы для распределенных систем, но не все.
mnf>Т.е. мы пишем программу для обработки данных у которой есть внутреннее состояние, и его надо синхронизировать между всеми на случай выключения узла. Один из советов был хранить все в mnesia, но, как я понял из Выших сообщений про "brain-split", это нельзя назвать надежным механизмом, и никаких других более-менее стандартных средств тоже нет? Казалось бы не очень сложная задача для "language designed to support robust, reliable, distributed near real-time applications".
Brain-split можно достаточно надежно избежать с помощью избыточной связности. Оно более важно, если у нас есть географически отделенные датацентры (у нас есть).
do_call(Tag, C) ->
Fun = the_func(C),
F = fun() ->
case mnesia:read({reply, Tag}) of
[] ->
%% no cached value
Val = Fun(),
mnesia:write(#reply{tag=Tag,val=Val}),
Val;
[C] ->
%% yes - return cached value
C#reply.val
end
end,
mnesia:transaction(F).
Представим, что у нас во время исполнения функции клиент теряет соединение с сервером, и делает failover на второй сервер. Тогда второй сервер тоже начнет исполнять эту функцию (так как в Mnesia еще не лежит результат выполнения), а потом оба сервера могут спокойно положить результат в Mnesia.
Написал об этом Армстронгу, посмотрим что ответит.
Здравствуйте, Cyberax, Вы писали:
[cut] C>Написал об этом Армстронгу, посмотрим что ответит.
Лучшеб в мейллист, но будем надеяться, что отпишешь о результатах
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Gaperton, Вы писали:
G>>Интересно, как в этом случае ведет себя мнезия — ведь это она выполняет репликацию. Я думаю, на самом деле все будет в порядке. Но правда любопытно. C>Я не использовал Мнезию для серьезной работы, так что не смотрел туда особо внимательно.
C>Сейчас попробовал найти в доке — похоже, что никак не обрабатывает:
Зато она обнаруживает эту ситуацию. И генерит перехватываемый event. Уже не мало. А далее все должно быть просто — например, тебе надо выбрать главный репозиторий и грохнуть второй.
C>>>Для решения этой проблемы можно использовать такие методы: C>>> Кворумный диск — сервер может работать, только если у него есть доступ к этому диску. Добавляет single-point-of-failure, но на практике достаточно надежно. G>>Ну, дисков они не разделяют. Мнезия реплицирует таблицы через эрланговские сообщения — двухфазным или трехфазным коммитом. G>>Вообще, в эрланге этому подходу соответствует супервижн три, достаточно грамотно его построить, ничего другого не нужно. C>Кворумный диск (точнее, вообще любой кворумный ресурс) используется и если нет разделения дисков, он просто позволяет гарантировать, что система находится в consistent state.
В эрланге для этого диск не нужен. Там процессные линки двунаправленные, поэтому роль кворумного ресурса играет процесс-супервизор. Подчиненный процесс узнает о том, что он отвалился от дерева. Причем, никто не мешает тебе добавить в систему произвольное количество кворумных процессов — пустышек — это совсем элементарно делается. Просто следишь, когда порвется линк, и все. Кроме этого, можно запускать heartbeat.
C>>> Работать только если у нас есть связь с более чем 50% узлов в кластере (для этого нужно минимум три узла). G>>Узлы кластера можно увязать в супервижн три, и держать резервного супервизора — тогда все просто и понятно — мы трактуем недоступный узел как отвалившийся. Думаю, так будет нормально. Опять же, интересно, как такие проблемы решает мнезия. C>Насколько я понимаю, supervisor tree не решает эту проблему — просто сдвигает ее со стороны worker nodes на сторону супервизоров. То есть, если у нас отказывает корневой супервизор, то нам надо решить кому стать следующим корнем. И там все те же самые проблемы.
Отчего же. Супервизор может понять, кто из детей отвалился. Подчиненный процесс понимает, что его от супервизора отрубили, и он спокойно сворачивает активность. Если грохнулся корневой супервизор, то падает все, и система его перезапускает. Когда ты проектируешь отказоустойчивую систему, ты все равно должен выделить trusted код, который падать не должен, и он должен быть очень простым и хорошо отлаженным. А также — код, который ненадежен, в котором ты "толерэйтишь" ошибки. Вот, супервизор и есть такой trusted код, в нем нет ошибок.
Для пущей надежности можно завести резервное supervision tree. Или еще что-нибудь придумать. Причем, на Эрланге такое написать вполне реально и самому — можно произвольную схему реализовать, кода будет порядка нескольких килобайт, не больше десятка. Делов-то.
C>Кстати, мы вообще смотрели как проще делать реплицируемую базу. В итоге, остановились на кластерной файловой системе OCFS2 с избыточной связностью хостов. Там сценарий со split-brain возможен, но для этого требуются очень нереальные условия (падение сразу нескольких интерфейсов на разных хостах, причем одновременно).
Здравствуйте, Gaperton, Вы писали:
C>>Сейчас попробовал найти в доке — похоже, что никак не обрабатывает: G>Зато она обнаруживает эту ситуацию. И генерит перехватываемый event. Уже не мало. А далее все должно быть просто — например, тебе надо выбрать главный репозиторий и грохнуть второй.
Ага, и потерять свои изменения в локальной копии. Насколько я понял, оно обнаруживает partitioned event только после переподключения к другим нодам.
G>Отчего же. Супервизор может понять, кто из детей отвалился. Подчиненный процесс понимает, что его от супервизора отрубили, и он спокойно сворачивает активность. Если грохнулся корневой супервизор, то падает все, и система его перезапускает. Когда ты проектируешь отказоустойчивую систему, ты все равно должен выделить trusted код, который падать не должен, и он должен быть очень простым и хорошо отлаженным. А также — код, который ненадежен, в котором ты "толерэйтишь" ошибки. Вот, супервизор и есть такой trusted код, в нем нет ошибок.
Проблема в том, что один корень — это плохо в любом случае. Нужно иметь хотя бы один hot spare на другой машине. Но тогда возникнет проблема — если теряем связь между hot spare и основным сервером, то получаем все ту же проблему. Hot spare нужно решить, может ли он перехватить управление.
G>Для пущей надежности можно завести резервное supervision tree. Или еще что-нибудь придумать. Причем, на Эрланге такое написать вполне реально и самому — можно произвольную схему реализовать, кода будет порядка нескольких килобайт, не больше десятка. Делов-то.
Можно, но похоже с Mnesia могут быть проблемы.
C>>Кстати, мы вообще смотрели как проще делать реплицируемую базу. В итоге, остановились на кластерной файловой системе OCFS2 с избыточной связностью хостов. Там сценарий со split-brain возможен, но для этого требуются очень нереальные условия (падение сразу нескольких интерфейсов на разных хостах, причем одновременно). G>Интересно, надо будет посмотреть.
Ага. Мы посчитали — нам требуется одновременно (в течение примерно одной секунды) отключить 22 кабеля, чтобы разбить кластер на два partition'а.
. Кто заставляет-то — предметом первой необходимости Erlang у нас не является пока слава богу. 
