VoidVolker, создай нагрузку на запись. Такую чтоб все дрожало и свистело. И поставь на сутки.
Попробуй миллиард мелких файлов в директории создать. Потом хардлинков. Потом сим-линков на них.
Короче сделай стресс тест настоящим. Ведь после этого можно говорить что у файловой системы нет проблем.
VoidVolker, возможно ты работаешь давно без нагрузки. Очень часто дефекты
файловых систем воспроизводятся когда работает много потоков на запись
одновременно. И когда был reset.
Я помню в телекомах мы тестировали новый сервер exchange. Нам удалось
его уронить просто двумя резетами. Первый резет - сервер ушел в перезагрузку.
И второй резет - во время процедуры старта еще раз.
После этого мы вернули сервер обратно продавцу на ремонт.
Наблюдение. Я не использовал никогда sympy. Вот что пишут на сайте
SymPy is a Python library for symbolic mathematics.
Символические вычисления - это формульные вычисления. Тоесть вместо того чтобы 2/3 преобразовать
в вещесвтенное 0.6666666666666 такие библиотеки сохраняют семантику выражения и используют
ее до конца вычислений. Я считаю что это не самый быстрый способ считать и его имеет смысл
использовать лишь для доказательства теорем.
Поэтому для разгона я-бы первым делом отказался от Симпи и взять другую более близкую
к численным методам библиотеку.
Отметил ответом. Добавлю. Мне кажется что сама по себе идея формата pdf - противоречит
редактированию.
Такие документы как пресс-релизы. Журналы. Прайсы. Бизнес-отчеты. Все это в принципе
является read-only документом и если у кого-то возникает желаение поредактировать
то надо это желание гасить в зародыше.
Не у кого-же нет желание поредактировать *.exe файл?
Да. Скорее всего так оно и есть. И говорить в пабликах о блокчейне - так же кринжово
как и придя в автосалон начать говорить о термодинамике процессов внутри ДВС двигателя.
Очень научно - но никто вообще не поймет о чем это вообще.
и таким образом вообще ушел бы от вопроса сети и портов.
А мониторинг - прикладной hearbeat как я и предлагал. И hearbeat должен
быть частью технологического цикла самого приложения. Не какой-то отдельный
процесс а именно цикл обработки прикладных сообщений. Только так
ты сможешь детектировать падение или зависание приложения. Других
способов не существует.
Mininara, я-бы предложил тебе во первых ничего не делать.
А во вторых понаблюдать что за проблема. Если у тебя
вычислительный кластер и его ноды периодически
падают то тебе нужен какой-то кластерный протокол.
И этот протокол должен быть отделет от работы приложения.
Грубо говоря приложение не должно заниматься cluster recovery.
Что там происходит с MySQL - это проблемы его. И мы не можем
брать его за образец или считать что так правильно.
Вот щас аудитория отвечающих разделится на 2 лагеря по интерфейсу. Десктов и веб.
Потом она разделится по типу API и базы данных.
А все потому - что автор лентяй и поросенок. Даже не удосужился придумать требования.
Сейчас задача звучит так. Я - ничего не знаю и не понимаю. Придумайте мне задание.
Я считаю что данный вопрос - продуцирует бесполезный флейм на тему что можно было
бы написать. И я прошу модераторов его удалить.
Надеюсь что в следующей инкарнации автор все таки напишет вопрос как полагается.
Поскольку пятница. Я сразу скажу что диаграмма твоя вполне себе рабочая. Мне нравится.
По всем остальным твоим сомнениям. Очень сумбурно.
Надо подумать. Запуск твоей master БД в режиме primary-standby - имеет коробочное решение.
Он технически решен например для Oracle/MS-SQL. Я не знаю что здесь еще добавить.
Запускай две БД и настраивай аварийное переключение.
По поводу сбоя самого балансера. Я не специалист в сетях и я тут не знаю что придумать. А как разработчик
я-бы предложил забить в клиентов 2 имени типа application1.com, application2.com и пускай они
ходят туда где доступно. Такая технология используется в умных драйверах Apache Cassandra.
Попробуй миллиард мелких файлов в директории создать. Потом хардлинков. Потом сим-линков на них.
Короче сделай стресс тест настоящим. Ведь после этого можно говорить что у файловой системы нет проблем.