Безусловно, в каждой географической точке расположены выделенные серверы, которые и обрабатывают клиентские запросы.
Это я прекрасно понимаю, однажды меня заинтересовала anycast тема, в результате написал вот это.
Интересно было как вы решили проблему подключения к интерфейсу управления конкретного сервера, так как для управления вам нужен не любой, а именно конкретный сервер. На сколько я понимаю по вашему ответу, на каждом из серверов по 2 сетевые карты (IP адреса в разных подсетях) первая для управления — IP из подсети провайдера на площадке которого расположен сервер, вторая — отвечает на DNS запросы и анонсирует свою подсеть/24 в BGP. Ну, и наверное, на каждом из серверов есть статический маршрут до подсети из которой производится управление через первую сетевую карту.
Изначально мне представилась не самая правильная схема с дополнительным сервером, расположенным «топологически близко» к обоим серверам, через который осуществляется доступ на управление через IP адреса из подсети анонсируемой в BGP, поэтому и задал вопрос.
На самом деле было бы интересно почитать про «накатывание своей обвязки для управления, запуск репликации и мониторнга». Тут не обойтись без дополнительного сервера расположенного у провайдера, анонсирующего ваши две подсети.
А с какой целью вы бы хотели сделать такого рода сравнение? Просто ради интереса или есть необходимость повысить точность прогнозирования?
На текущий момент — просто ради интереса.
Повышение точности прогноза в рамках фунционирования системы мониторинга вопрос не принципиальный, интересует не точность прогноза а корректность выявления сбоев, хотя это и взаимосвязанные вещи.
Изначально не было уверенности, что адекватный мониторинг прогнозированием в принципе возможен. Однако результат превзошел ожидания. И тем не менее, возможно другие методы дадут лучшие результаты. Я не статистик и слабый математик, для меня слишком сложно разобраться в теории и применять математику для того, чтобы понять какой из методов лучше. Гораздо проще написать или использовать готовое ПО и проанализировать эфективность метода на реальных данных.
Пока я не собираюсь этого делать, но, возможно через год у меня появится свободное время для проведения дополнительных исследований какой из методов более эфективен для VoIP и IP трафика.
Скажите, а Вы используете какие-либо инструменты для быстрой проверки какой из методов прогнозирования подходит для определенных входных данных временных рядов? Имеется ввиду некое программное обеспечение в которое подгружается временной ряд, выбирается модель прогнозирования и коэффициенты для данной модели, в результате получается некий график со значениями и прогнозом, позволяющий оценить адекватность прогноза.
Я написал систему мониторинга VoIP трафика с использованием метода Хольта-Винтерса. Если Вам интересно, вот так выглядят графики прогнозов. В принципе, метод работает замечательно для данной задачи и для задачи мониторинга IP трафика. Так же в моем программном обеспечении реализован инструмент, позволяющий варьировать коэффициенты, влияющие на прогноз и смотреть, что из этого получается, однако инструмент используется достаточно редко в виду адекватности прогнозов с использованием значений по умолчанию.
Просто хотелось бы сравнить адекватность прогнозов метода Хольта-Винтерса с другими методами, не заморачиваясь на написание соответствующего инструмента…
Для того, чтобы мониторить с мохито настройте другую систему мониторинга.
Когда я в отпуске или на выходные я получаю информативные SMS о том что случилось, но в этом случае я не всегда обязан что-либо делать, так как у нас команда и все сразу в отпуск не уходят, а NOC работает без выходных.
Различные потребности — различные системы мониторинга, если под вашей ответственностью несколько десятков серверов, это одно, но если под вашей ответственностью сеть с десятками, сотнями, а то и тысячами сетевых устройств с избыточными связями между ними, это другое.
Все что касается базового мониторинга сети The Dude умеет из коробки, и настраивается это несколькими кликами. Мониторинг серверов и сервисов, которые они предоставляют настроить в The Dude сложнее и не всегда понятно как. Однако это тоже можно сделать, и далее в книге описывается как.
Мы не используем других систем мониторинга, кроме The Dude (ну и кактуса, чтобы иметь исторические графики), так как в такой схеме решаем все наши задачи, связанные с мониторингом.
Веб-интерфейс тоже есть, правда не очень сильный. А так, дело личного вкуса и предпочтений. Больше всего система нравится тем, кто имеет дело в основном с сетями, нежели с серверами. Ну и как написал VolCh, больше возможностей уведомление послать, клиент, когда запущен, постоянно подключен к серверу и алерты выводятся моментально, как только что-то случилось.
К тому же гораздо приятней пользоваться, чем веб интерфейсом.
Я не соглашусь, что результаты предсказуемы. И даже про третий пункт, иначе не имели бы место подобные посты с почти не нулевой кармой.
Предсказуем был только слив кармы. Но я сделал то, что сделал и ничуть не жалею.
Хорошо. Система, как Вы можете убедиться сами, хоть и не опенсорсная, но бесплатная. Я написал книгу по ней объёмом примерно в 250 страниц. Книга тоже будет бесплатная. Зачем был нужен этот опрос, объясню после его окончания. А кармы мне не жалко. Я её не использую практически.
Да, в принципе решение должно работать, можно настроить анализ статистики по количеству звонков и ACD по потокам с интервалом снятия статистики 1 или 2 минуты, в случае атаки резко возрастет количество звонков и, весьма вероятно, упадет ACD. При лавинообразной атаке система сама ее вычислит и через 10-15 минут даст алерт. Кто не в курсе, я имею в виду вот этот метод.
Сама же атака может быть организована различными методами, к примеру вот так. Сложно себе представить как её вычислить другими методами, если атакующий может произвольно менять A номер.
Вы просто rrdtool готовить не умеете.
У меня на сервере (hw.machine: i386 hw.model: Pentium III/Pentium III Xeon/Celeron hw.ncpu: 4) 10000 rrd обновляются двенадцатью потоками за 2 секунды. Что я делаю не так?
Можно ещё, конечно, было взглянуть в сторону rrdcached мне просто не подходит в силу того, что после обновления надо проверять значения, а это значит, что база данных всё равно перед проверкой будет сброшена на диск.
Ещё, в статье порадовало
Почему же мы не выбрали RRD? Ответ прост и печален: RRD не поддерживает bulk insertion — вы не можете за одну операцию сохранить несколько значений. Это означает, что вам придётся делать тысячи раздельных транзакций, каждая из которых больно бъёт по диску.
Тогда утром, на свежую голову, смоделируйте ситуацию по моему сценарию, просто для проверки на сколько хорошо защищены. Дизайнов сети может быть куча, не факт, что все учтено.
Возможно, я и не понял. Объясните, что по вашему есть правильные аццессы? Вы закрываете multicast на портах коммутатора? Ставите на портах коммутатора access-list-ы?
Это я прекрасно понимаю, однажды меня заинтересовала anycast тема, в результате написал вот это.
Интересно было как вы решили проблему подключения к интерфейсу управления конкретного сервера, так как для управления вам нужен не любой, а именно конкретный сервер. На сколько я понимаю по вашему ответу, на каждом из серверов по 2 сетевые карты (IP адреса в разных подсетях) первая для управления — IP из подсети провайдера на площадке которого расположен сервер, вторая — отвечает на DNS запросы и анонсирует свою подсеть/24 в BGP. Ну, и наверное, на каждом из серверов есть статический маршрут до подсети из которой производится управление через первую сетевую карту.
Изначально мне представилась не самая правильная схема с дополнительным сервером, расположенным «топологически близко» к обоим серверам, через который осуществляется доступ на управление через IP адреса из подсети анонсируемой в BGP, поэтому и задал вопрос.
На текущий момент — просто ради интереса.
Повышение точности прогноза в рамках фунционирования системы мониторинга вопрос не принципиальный, интересует не точность прогноза а корректность выявления сбоев, хотя это и взаимосвязанные вещи.
Изначально не было уверенности, что адекватный мониторинг прогнозированием в принципе возможен. Однако результат превзошел ожидания. И тем не менее, возможно другие методы дадут лучшие результаты. Я не статистик и слабый математик, для меня слишком сложно разобраться в теории и применять математику для того, чтобы понять какой из методов лучше. Гораздо проще написать или использовать готовое ПО и проанализировать эфективность метода на реальных данных.
Пока я не собираюсь этого делать, но, возможно через год у меня появится свободное время для проведения дополнительных исследований какой из методов более эфективен для VoIP и IP трафика.
Я написал систему мониторинга VoIP трафика с использованием метода Хольта-Винтерса. Если Вам интересно, вот так выглядят графики прогнозов. В принципе, метод работает замечательно для данной задачи и для задачи мониторинга IP трафика. Так же в моем программном обеспечении реализован инструмент, позволяющий варьировать коэффициенты, влияющие на прогноз и смотреть, что из этого получается, однако инструмент используется достаточно редко в виду адекватности прогнозов с использованием значений по умолчанию.
Просто хотелось бы сравнить адекватность прогнозов метода Хольта-Винтерса с другими методами, не заморачиваясь на написание соответствующего инструмента…
Когда я в отпуске или на выходные я получаю информативные SMS о том что случилось, но в этом случае я не всегда обязан что-либо делать, так как у нас команда и все сразу в отпуск не уходят, а NOC работает без выходных.
Различные потребности — различные системы мониторинга, если под вашей ответственностью несколько десятков серверов, это одно, но если под вашей ответственностью сеть с десятками, сотнями, а то и тысячами сетевых устройств с избыточными связями между ними, это другое.
Все что касается базового мониторинга сети The Dude умеет из коробки, и настраивается это несколькими кликами. Мониторинг серверов и сервисов, которые они предоставляют настроить в The Dude сложнее и не всегда понятно как. Однако это тоже можно сделать, и далее в книге описывается как.
Мы не используем других систем мониторинга, кроме The Dude (ну и кактуса, чтобы иметь исторические графики), так как в такой схеме решаем все наши задачи, связанные с мониторингом.
К тому же гораздо приятней пользоваться, чем веб интерфейсом.
Предсказуем был только слив кармы. Но я сделал то, что сделал и ничуть не жалею.
Сама же атака может быть организована различными методами, к примеру вот так. Сложно себе представить как её вычислить другими методами, если атакующий может произвольно менять A номер.
У меня на сервере (hw.machine: i386 hw.model: Pentium III/Pentium III Xeon/Celeron hw.ncpu: 4) 10000 rrd обновляются двенадцатью потоками за 2 секунды. Что я делаю не так?
Можно ещё, конечно, было взглянуть в сторону rrdcached мне просто не подходит в силу того, что после обновления надо проверять значения, а это значит, что база данных всё равно перед проверкой будет сброшена на диск.
Ещё, в статье порадовало
Почему же мы не выбрали RRD? Ответ прост и печален: RRD не поддерживает bulk insertion — вы не можете за одну операцию сохранить несколько значений. Это означает, что вам придётся делать тысячи раздельных транзакций, каждая из которых больно бъёт по диску.
Может быть стоило почитать маны по rrdupdate
rrdtool update demo2.rrd 887457267:U 887457521:22 887457903:2.7
Update the database file demo2.rrd which expects data from a single data-source, three times.