RB750Gr3 обеспечит 50 Мбит/сек, но дает их в полудуплексе (это если применить QoS как я в статье писал). Если QoS упростить, то возможно и больше протянет, учитывайте это.
RB1100AHx4 который держит свыше 250 хостов, ОЗУ использовал около 70 МБ, так что RB750Gr3 по этому параметру точно подойдет, 256 МБ хватит.
И конечно, не забывайте сегментировать сеть, если у вас все будут в одном широковещательном домене, то проблем у вас все равно будет.
Если с QoS до 50 мегабит, можно взять RB750Gr3, однако таких больших офисов с этим классом роутеров не держал, сеть на 250 устройств у меня на RB1100AHx4
С агрегацией нет проблем, все зависит от RB. Где-то это в железе, в остальных софтово.
Failover через VRRP, который есть в коробке и настраивается без особых сложностей.
DNS печаль :(
Разве DNS не важная часть работы сети? Почему сегментирование не его работа?
Как раз это все его забота, и сегменты, и QoS и DNS (не полный конечно, но нормальный кэш со split DNS). Единственная железка такое может не вытянуть, мощей может не хватить, тогда строят каскадное решение из разных железок, для разных подзадач, вот к примеру Cisco предлагает такое решение: Borderless Campus 1.0 Design Guide
Он полностью покрывает теоретический придел в 550 Мбит/сек (ограничения вызванные нагрузкой QoS). Судя по офф. тестам от самих Mikrotik, на средней нагрузке он как раз вытянет примерно 500 (микс из мелких, средних и крупных пакетов). В моей ситуации его вполне достаточно (трафик филиалов локализовали по максимуму).
Так как mikrotik у меня маршрутизирует между vlan, а сервера и клиенты в разных, то при падении mikrotik работа встает полностью.
Тут уже фактор скорости запуска является крайне важным, микрот по питанию может перезапустить любой сотрудник по подсказкам по телефону, и уже через десяток секунд все работает (главное, это чтобы он просто завис, а не проблема с обновлением). А контроллер домена стартовать может гораздо дольше.
Я предпочитаю запросы в глобальный интернет не пускать на контроллер домена, пусть он другой работой занимается. Плюс, в случае отказа контроллера (или перезапуска), не пропадет доступ в глобальный интернет (не всегда есть возможность держать два контроллера в каждом филиале).
RB1100 очень близок по производительности, а цена почти та-же. Да портов поболе, двойное питание… Главный плюс, компактный и под любую ОС. Недурно для АТС в филиалы.
Согласен, но не во всем. Реальный пример:
Заметил плохую тенденцию (за пару месяцев до реальных проблем). Сделал анализ, написал подробный отчет с прогнозом (в данном случае рост числа пользователей 1С, сервер уперся в ОЗУ), начались проблемы с умиранием процессов из-за нехватки памяти. Проблема ясна, предложено три варианта решения: с перспективой на рост, без перспективы и костылинг для снижения последствий сбоев (тупо выгонять «не важных» при достижении порога в 90%). Первые два варианта: расширение ОЗУ (все слоты были уже заняты, пришлось бы менять всю память) или дополнительный сервер (по цене, на 40% выше чем замена всей памяти). Но ответ был убийственным: но как-же так, раньше то мы работали, почему так? Объясняешь, добавились сотрудники (это отдельная песня, сообщить о новом человеке в день его выхода на работу, повезет если вспомнят за неделю), серверу не хватает ресурсов на всех. Нет, говорят, сейчас покупать ничего не будем, у нас отчеты, нет времени. Тут уже на отчетах все начинает валится по памяти, все начинают бегать на ушах. Говорю, давайте память хоть купим, её быстро поставить можно, простой минимальный. Нет, тут не до этого, отчеты!!! Ясень пень, после сдачи отчетов проблем стало чуть меньше (запросы чуток похудели), вместо падения каждый час, стали падать каждые три (пользователей то не стало меньше). В конце, когда самый главный узнал, что проблема в экономии, деньги на новый сервер (с конфой «в потолок») нашлись тут-же, и счет оплатили в тот-же день.
Да, это очень серьезный повод для снижения мотивации работать. Когда заранее знаешь, что будет работать плохо, а сделать просто нормально не дают. И другим сотрудникам часто бесполезно объяснять, что ты сделал все, что мог, тебя все равно будут тыкать: вот я работал в другой компании, там все работало, а у вас тут все плохо.
Все верно. Сравнение комбайна — «все в одном» с узко специализированным решением в аспекте стабильности той самой узкой задачи.
Мой опыт показал, что есть момент, после которого комбайн уже плох.
Согласен только в области переключения на другого провайдера. Это связанно с правилами работы DNS клиента. Он не знает, что первый сервер в списке уже недоступен (канал упал) и пытается получить от него ответ. Конечно это не получается и он спрашивает у второго. Тут сложности будут в любой «обычной» конфигурации любого DNS клиента. Нужен такой, который понимает, что после нескольких таймаутов, нужно дать передышку первому серверу, и проверять его доступность с некоторой периодичеостью.
Там аппаратное шифрование, в него вообще не упереться. Основная проблема в сложных правилах для QoS (проблемы я расписывал в другой статье). Имено они нехило грузят проц и маркировка DCSP не бесплатна. На данный момент, работает в пограничном режиме, и трафик в 100 Мбит/сек не грузит его более чем на 10% (и это GRE/IPSec трафик).
Mikrotik давно анонсировал, что RoS 7.x будет с 4-ым ядром. Но разработка идет уже давно. Mikrotik стараются делать все максимально стабильным (это получается не всегда, особенно под давлением пользователей, которые требуют нового и побольше).
В 7-ке обещается много вкусного…
На всем пути: это очень хорошо, но в большинстве случаев, хватает пограничной обработки. Хотя явление микрошторма или перегруженность uplink порта никто не отменял и именно для этого проставляются приоритеты пакетов на layer2 (на оснавании DCSP к примеру) и коммутаторы тогда могут принимать решение о пропускании в нужном порядке пакетов (это если они с мозгами).
Решение с VLAN покрывает не все аспекты. Примеры: VoIP в отдельном VLAN для стационарных телефонов, а VoIP софтфон может быть на мобилке, ПК или ноуте. Это уже как минимум не гуд.
Размечать как VoIP весь udp трафик с пакетами 50-210 байт (специально выбирал несколько разных кодеков) конечно вариант, но не очень точный. Тут проблема в наличии протоколов, у которых нет фиксированного с одного конца порта, и с таким работать без Layer7 крайне трудно (не на всех клиентских устройствах можно политику DCSP выставить, да и только половина маркированного трафика никак не поможет).
RB1100AHx4 который держит свыше 250 хостов, ОЗУ использовал около 70 МБ, так что RB750Gr3 по этому параметру точно подойдет, 256 МБ хватит.
И конечно, не забывайте сегментировать сеть, если у вас все будут в одном широковещательном домене, то проблем у вас все равно будет.
Failover через VRRP, который есть в коробке и настраивается без особых сложностей.
DNS печаль :(
Как раз это все его забота, и сегменты, и QoS и DNS (не полный конечно, но нормальный кэш со split DNS). Единственная железка такое может не вытянуть, мощей может не хватить, тогда строят каскадное решение из разных железок, для разных подзадач, вот к примеру Cisco предлагает такое решение: Borderless Campus 1.0 Design Guide
Тут уже фактор скорости запуска является крайне важным, микрот по питанию может перезапустить любой сотрудник по подсказкам по телефону, и уже через десяток секунд все работает (главное, это чтобы он просто завис, а не проблема с обновлением). А контроллер домена стартовать может гораздо дольше.
Заметил плохую тенденцию (за пару месяцев до реальных проблем). Сделал анализ, написал подробный отчет с прогнозом (в данном случае рост числа пользователей 1С, сервер уперся в ОЗУ), начались проблемы с умиранием процессов из-за нехватки памяти. Проблема ясна, предложено три варианта решения: с перспективой на рост, без перспективы и костылинг для снижения последствий сбоев (тупо выгонять «не важных» при достижении порога в 90%). Первые два варианта: расширение ОЗУ (все слоты были уже заняты, пришлось бы менять всю память) или дополнительный сервер (по цене, на 40% выше чем замена всей памяти). Но ответ был убийственным: но как-же так, раньше то мы работали, почему так? Объясняешь, добавились сотрудники (это отдельная песня, сообщить о новом человеке в день его выхода на работу, повезет если вспомнят за неделю), серверу не хватает ресурсов на всех. Нет, говорят, сейчас покупать ничего не будем, у нас отчеты, нет времени. Тут уже на отчетах все начинает валится по памяти, все начинают бегать на ушах. Говорю, давайте память хоть купим, её быстро поставить можно, простой минимальный. Нет, тут не до этого, отчеты!!! Ясень пень, после сдачи отчетов проблем стало чуть меньше (запросы чуток похудели), вместо падения каждый час, стали падать каждые три (пользователей то не стало меньше). В конце, когда самый главный узнал, что проблема в экономии, деньги на новый сервер (с конфой «в потолок») нашлись тут-же, и счет оплатили в тот-же день.
Мой опыт показал, что есть момент, после которого комбайн уже плох.
В 7-ке обещается много вкусного…
Решение с VLAN покрывает не все аспекты. Примеры: VoIP в отдельном VLAN для стационарных телефонов, а VoIP софтфон может быть на мобилке, ПК или ноуте. Это уже как минимум не гуд.
Размечать как VoIP весь udp трафик с пакетами 50-210 байт (специально выбирал несколько разных кодеков) конечно вариант, но не очень точный. Тут проблема в наличии протоколов, у которых нет фиксированного с одного конца порта, и с таким работать без Layer7 крайне трудно (не на всех клиентских устройствах можно политику DCSP выставить, да и только половина маркированного трафика никак не поможет).