По закону «О Связи» решение СОРМ-1, СОРМ-2, СОРМ-3 и по пакету Яровой оператор реализует за собственные деньги. т.е. деньги будут не из налогов, а из тарифов на услуги.
Точнее там значится примерно следующее «Решение СОРМ должно быть согласовано с местным отделением ФСБ». ФСБ железку не купит за свой бюджет и бумагу о согласовании с ними решения не подпишет, пока не купите то, с чем удобно работать им. В каждом регионе ФСБ используют разные версии СОРМ, поэтому приходится покупать то, что удобно местным ФСБшникам.
статические маршруты — вы прописываете, что маршрут к конкретному IP должен идти только через шлюз первого провайдера, а к другому IP через другого провайдера.
В коде это выглядит примерно так(по памяти):
/ip route add dst-address=8.8.8.8 gateway=2.2.2.2
/ip route add dst-address=8.8.4.4 gateway=1.1.1.1
Файловер на скриптах — это попытка использования только одного провайдера в один момент времени. В случае полноценного использования двух каналов одновременно(а в случае падения одного из каналов использовать резервный) требуется подобное решение, которое описано в статье.
Мне правда описанное в статье нравиться немного по другому делать, но этот способ тоже вполне жизнеспособен.
Попробуйте на самом роутере поднять роль DNS-сервера, а в качестве источников для него укажите все DNS-серверы обоих провайдеров. Это костыль, но работать будет. Для внутренних абонентов укажите DNS-сервер, который на роутере.
Второй вариант — статические маршруты.
А что вы имеете ввиду под горизонтальной шкалой? Срочность проблемы по которой обращается пользователь?
У Вас есть шкала субъективной оценки работоспособности СЭД. Эта шкала разбивает приоритет решения проблем от «Назкий» до «Сверхсрочно! Всё пропало!». Этой шкалой Вы позволяете пользователю злоупотреблять, потому что человек по натуре склонен преувеличивать/преуменьшать в свою пользу. На примере провайдеров связи выявлено, что среди абонентов тарифов за 300руб. огромное ко-во людей у которых срываются контракты на миллионы долларов из-за простоев в работе провайдера. Это реалии любой техподдержки, но в случае провайдера это понятней выглядит, т.к. там контингент самый разнообразный.
Я предлагаю делить обращения не от «рядовых» до «срочных», а по типу обращения. Грубо говоря: 1) Технический вопрос 2) Программный вопрос 3) Вопрос по эксплуатации 4) Прочие вопросы. Это позволит пользователям не злоупотреблять приоритетом.
Вы сделали вертикальную шкалу, которая описывает приоритет. Соответственно остановка работы или затруднение в осуществления его работы для одного пользователя, согласно его ЧСВ является проблемой мирового масштаба.
Нужно попробовать сделать горизонтальную систему(к сожалению не знаю продукт Вашей компании и не могу предложить полноценные рабочие варианты):
1) Нет доступа к чему-либо
2) Не создаётся(не обрабатывается документ)
3) Не работает маршрутизация документа
4) Наблюдаются проблемы с производительностью (долго обрабатывается/регистрируется/проходит маршрут)
5) Проблемы с работой интерфейса(не работают кнопочки, не активно поле и пр..)
6) Прочие проблемы(тут нужно обязать заполнить самостоятельно и через некоторое время из этих заголовков сформируете новые пункты для выбора)
Насколько я понял — Вы создали приложение для извлечения данных из однотипных файлов, которое не хранит централизованно данные и для которого нужна отдельная инфраструктура?
Может было проще сделать ещё один макрос в экселе и добавить его в существующие файлы(раз макросы и так неизбежное зло)? Тогда сотрудники(или клиенты) не зависели бы от внутреннего сервера…
Ни в коем случае не осуждаю — каждый решает задачу самым удобным для себя инструментом. Просто на мой взгляд сотрудники были бы оперативнее без внутренних сервисов.
1) Но зачем Вам нужен l2-сегмент с отсутствующими преимуществами l2? Может лучше просто в gre или ipip запихнуть? Это такой стандартный костыль, который уже давно не костыль т.к помогает отслеживать состояние соединения с удалённым офисом.
2) Проблемы с OSPF(если они действительно есть в нынешних версиях, т.к. за последние 3 года их не встречал) в Вашем случае неважны, т.к. у Вас должна быть одна Area и в принципе пофиг на авторизацию в тунельных интерфейсах.
3) OSPF на этих объёмах Вам бы ничего не сократил, т.к. без нетвоча и скриптов он нормально не работает, т.к. ориентируется только на физическое состояние линка, а не на доступность адресов. Но OSPF всё-равно более правильный вариант решения этой проблемы — понять это можно только попробовав и вникнув.
может, как альтернативу, использовать Pin-padы в офисах мобильных операторов?
Проблема «кодовых слов» в том, что их может узнать любой сотрудник опсоса, а пин можно шифровать с хешем номера паспорта…
Я немного не понял…
1) У Вас же входящий трафик на сайт минимальный, а исходящий в 1000 раз больше… Тогда о каких 20Г на балансер идёт речь? А исходящий трафик вроде как распределяется по аплинкам роутером…
Я представлял, что главный узел(балансер) кластера принимает запрос на фильм, этот узел находит на каком из узлов кластера он находиться и перенаправляет на этот узел(если он есть на нескольких, тогда выбирает самый свободный).
2) Все фильмы есть на всех узлах кластера, количество узлов кластера увеличивает пропускную способность?
насколько я знаю: РТКом последние 3-4 года закупал оборудование у одной знаменитой китайской компании, выпускающей сетевое оборудование(инфа из анализа госзакупок).
Может проблема в этом?
Точнее там значится примерно следующее «Решение СОРМ должно быть согласовано с местным отделением ФСБ». ФСБ железку не купит за свой бюджет и бумагу о согласовании с ними решения не подпишет, пока не купите то, с чем удобно работать им. В каждом регионе ФСБ используют разные версии СОРМ, поэтому приходится покупать то, что удобно местным ФСБшникам.
Лично у меня оповещения работают через нетвоч, который дёргает скрипты.
В коде это выглядит примерно так(по памяти):
/ip route add dst-address=8.8.8.8 gateway=2.2.2.2
/ip route add dst-address=8.8.4.4 gateway=1.1.1.1
Файловер на скриптах — это попытка использования только одного провайдера в один момент времени. В случае полноценного использования двух каналов одновременно(а в случае падения одного из каналов использовать резервный) требуется подобное решение, которое описано в статье.
Мне правда описанное в статье нравиться немного по другому делать, но этот способ тоже вполне жизнеспособен.
Второй вариант — статические маршруты.
У Вас есть шкала субъективной оценки работоспособности СЭД. Эта шкала разбивает приоритет решения проблем от «Назкий» до «Сверхсрочно! Всё пропало!». Этой шкалой Вы позволяете пользователю злоупотреблять, потому что человек по натуре склонен преувеличивать/преуменьшать в свою пользу. На примере провайдеров связи выявлено, что среди абонентов тарифов за 300руб. огромное ко-во людей у которых срываются контракты на миллионы долларов из-за простоев в работе провайдера. Это реалии любой техподдержки, но в случае провайдера это понятней выглядит, т.к. там контингент самый разнообразный.
Я предлагаю делить обращения не от «рядовых» до «срочных», а по типу обращения. Грубо говоря: 1) Технический вопрос 2) Программный вопрос 3) Вопрос по эксплуатации 4) Прочие вопросы. Это позволит пользователям не злоупотреблять приоритетом.
Если не знаете этот метод — посмотрите статью Чудина за прошлый год(в гугле «Чудин Mikrotik»)
Нужно попробовать сделать горизонтальную систему(к сожалению не знаю продукт Вашей компании и не могу предложить полноценные рабочие варианты):
1) Нет доступа к чему-либо
2) Не создаётся(не обрабатывается документ)
3) Не работает маршрутизация документа
4) Наблюдаются проблемы с производительностью (долго обрабатывается/регистрируется/проходит маршрут)
5) Проблемы с работой интерфейса(не работают кнопочки, не активно поле и пр..)
6) Прочие проблемы(тут нужно обязать заполнить самостоятельно и через некоторое время из этих заголовков сформируете новые пункты для выбора)
Может было проще сделать ещё один макрос в экселе и добавить его в существующие файлы(раз макросы и так неизбежное зло)? Тогда сотрудники(или клиенты) не зависели бы от внутреннего сервера…
Ни в коем случае не осуждаю — каждый решает задачу самым удобным для себя инструментом. Просто на мой взгляд сотрудники были бы оперативнее без внутренних сервисов.
1) Но зачем Вам нужен l2-сегмент с отсутствующими преимуществами l2? Может лучше просто в gre или ipip запихнуть? Это такой стандартный костыль, который уже давно не костыль т.к помогает отслеживать состояние соединения с удалённым офисом.
2) Проблемы с OSPF(если они действительно есть в нынешних версиях, т.к. за последние 3 года их не встречал) в Вашем случае неважны, т.к. у Вас должна быть одна Area и в принципе пофиг на авторизацию в тунельных интерфейсах.
3) OSPF на этих объёмах Вам бы ничего не сократил, т.к. без нетвоча и скриптов он нормально не работает, т.к. ориентируется только на физическое состояние линка, а не на доступность адресов. Но OSPF всё-равно более правильный вариант решения этой проблемы — понять это можно только попробовав и вникнув.
Проблема «кодовых слов» в том, что их может узнать любой сотрудник опсоса, а пин можно шифровать с хешем номера паспорта…
1) У Вас же входящий трафик на сайт минимальный, а исходящий в 1000 раз больше… Тогда о каких 20Г на балансер идёт речь? А исходящий трафик вроде как распределяется по аплинкам роутером…
Я представлял, что главный узел(балансер) кластера принимает запрос на фильм, этот узел находит на каком из узлов кластера он находиться и перенаправляет на этот узел(если он есть на нескольких, тогда выбирает самый свободный).
2) Все фильмы есть на всех узлах кластера, количество узлов кластера увеличивает пропускную способность?
Может проблема в этом?