jidckii

Вы не представляете масштаб legacy ...

Соответственно вопросам:

1. Концепция изложена в спеке (открывать браузером). В добавок к вопросу, в котором вы меня засуммонили, тут в комментах подробно.
   
2. Делать фрагментированный mp4 и манифест к нему (.mpd). В общих словах есть в ответах, подробнее в стандарте расписано.
   
3. ffmpeg не умеет делать mpd, зато хорошо конвертирует mp4 во фрагментированные.
   
4. Данный модуль специализируется для поддержки DASH, конечно он умеет.
   
5. Лучше всегда иметь исходники, если не планируется строить свой маленький видеохостинг, в котором данные хранятся бесконечно долго.
   

Для того, чтобы сделать такой сферический бенчмарк в вакууме, нужно:
Взять какой-то файл или поток, определиться с выходным форматом (кодек видео и аудио, профиль, fps, битрейт, пресет кодирования, расстановка кадров и длительность GOP, количество выходных битрейтов и т.д.)

Взять определённое голое железо и прогнать этот бенчмарк.

Проблема в том, что правильного ответа на ваш вопрос нет.
Опять же, при наличии казалось бы одинакового ffmpeg, реализации аппаратного ускорения отличаются друг от друга.

Концептуально:
1. CPU транскодирование даст лучшее качество и стабильность, но будет дорогим из-за низкой производительности
2. NVENC/NVDEC даёт умеренное качество и стабильность (если не нагружать в полку) и высокую плотность транскодирования, (а если патчить дрова может и лучшую стоимость на канал)
3. QSV даёт умеренное качество, так себе стабильность и лютый, неистовый геморрой в эксплуатации
4. Транскоднёт 1 SD максимум.

Любую, которую знаете.
Довольно простая тематика и подойдет практически любая CMS.
Советовать будут только то, что знает и любит конкретный разработчик.
А не то, что прям идеально для сайта бухуслуг.

Микротик однозначно. SNMP есть. Мониторинг есть. Файрволл - линуховый iptables, слегка расширенный, можно использовать все линуховые схемы для прохождения пакетов. Правда, без знания как пакеты идут через iptables все равно микротиковский файрволл освоить будет трудновато.

Что же до pfSense, то хрен редьки не слаще - он основан на FreeBSD и pf. Человек, не рубящий в линухе, вряд ли справится с FreeBSD :-)

Купите mikrotik. Шейпинг есть, айпи есть, снмп есть. Скриптинг есть. Вебморда и ГУИ есть для настройки. Куча материала в нете. Стоит не дорого.

pfSense.
там все просто с администрированием.

Ну купите вы какой-нибудь Микротик. И что?
Если коллеги Линух не освоили, то и Микротик не освоят.
Там не сложно, но нужно ориентироваться где и что искать в разветвленнейшем меню.

Гипервизор поднимается на раз-два. Образ виртуальной машины туда закачивается на три-четыре.
Провести небольшие учения, хранить образ в известном месте - и горя не знать.

А что вы будете делать, если аппаратный маршрутизатор выйдет из строя?

Если собираетесь куда-то из города валить, или есть потенциальная возможность устроиться в такое место, где будут нужны юниксовые сервера и прочие нано-технологии, то начать изучать что-то очень просто.

Придумайте себе сеть организации. С доменами Active Directory, с внутренней почтой (сначала, допустим, на linux/FreeBSD/postfix/dovecot, а потом -- на Exchange, или наоборот), с внутренними DNS и DHCP-серверами.

С файловыми серверами, доступ к которым на уровне доменных учётных записей и групп распределяется. И запилите эту сеть на виртуальных машинах. Несколько виртуальных серверов Windows/Unix, парочку клиентских станций с виндой/линуксом.

Поднимите свой веб-сервер, нарисуйте на нём простенький веб-сайт на базе какой-нибудь популярной CMS типа Joomla, Wordpress, чо-там-ещё-нынче-модно.

Потом придумайте этой конторе удалённый филиал, и постройте инфраструктуру для него, и чтобы между ними ещё и VPN был, и с маршрутизацией правильной, чтобы машины из одного филиала видели другой, и наоборот.

А потом сделайте так, чтобы VPN-канал между филиалами был зарезервирован через двух разных провайдеров, да причём переключения производились автоматически и абсолютно прозрачно для клиентов. В этом вам поможет динамическая маршрутизация и протоколы OSPF или BGP.

Факультативно -- можете поднять в удалённом филиале так называемый RoDC -- read-only domain controller :-)

Вот когда всё это запилите, то приходите за новым заданием.

А если же не собираетесь валить из города, или нет никакой вообще возможности устроиться в контору с юниксами и нано-технологиями, то лучше переориентироваться на программерство. Программерам найти удалённую работу значительно проще, чем админам.

Тебе нужено не релей настроивать, а транспорт.
Проверь наличие строчки в main.cf

transport_maps = hash:/etc/postfix/transport

В /etc/postfix/transport

domain.net smtp:[mx.domain.net]
.domain.net smtp:[mx.domain.net]

Применяй изменения:
/usr/sbin/postmap /etc/postfix/transport

да, при relayhost = mx.domain.net вся почта уйдет туда.
сморите Ваш:
transport_maps = hash:/etc/postfix/transport
то есть добавьте туда транспорт для domain.net
domain.net smtp:mx.domain.net
ну и в mydestination естессно тоже.

Опубликовать порт 25 на пограничном роутере ничего страшного в этом по сути нет. (майкрософт ранее предлагала продукт TMG, теперь он признан устаревшим и в блоге Exchange на Technet, сами разработчики уверяют что инфраструктура почтовая MS работает под управлением Exchange 2013 и опубликована без дополнительных средств типа TMG, простым пробросом порта, конечно верить я бы им не стал, но думаю в ваших условиях перестраховываться так не имеет смысла.)
Грубо схема такая:
1. Публикуете (делаете портфорвардинг) 25 порта с белого IP на внутренний IP адрес Exchange 2013 на 25 порт. Для теста можете с домашней машины "telnet myserver.ru 25"
2. У провайдера который держит вашу зону DNS меняете MX запись на свой белый IP (в п.1) ( - тут конечно возможна схема VPS Linux + Postfix -> и только для него открыть порт 25 - но это уже вы реализуете когда отработаете эту схему)
3. В Exchange 2013 - добавляете домен в Accepted Domain, настраиваете Email Address Policy для пользователей

Конечно для всех трёх пунктов не мешает почитать теорию, но в целом схему я вам набросал. Если есть вопросы - задавайте, постараюсь ответить.

для диагностики проблем есть логи - смотрите, читайте, есть софт, в крайней случае, самим можно написать

и вообще изучите блог www.danshin.ms от корки до корки, мужик очень грамотно по продуктам Микрософт пишет

Если хост с engine упадет, hosted-engine на других хостах его профенсит, и поднимет engine на другом хосте. Когда engine поднимется, он увидит отвалившийся хост и поднимет HA-enabled виртуалки на нем на других хостах. Все что бежало на других хостах будет и дальше работать. Упавший engine не означает остановку системы.

Новые ноды ставятся штатно, но без прогона hosted-engine на них в алгоритме HA для hosted engine участвовать не будут. Таким образом можно управлять на каких хостах engine можно понимать а на каких нельзя

Отправная точка для гугления - "Cisco lacp hashing algorithm". На сколько мне известно, хеширование на L4 у циски поддерживается только на нексусах. Даже на шкафах CRS вы будете неприятно удивлены, когда переполнится один линк в агрегате при построении жирного x-connectа через mpls. Такова жизнь(

В этом преимущество джуниперов - их EX-коммутаторы имеют эту поддержку сразу.

И да, смотрите лучше балансировку по графикам MRTG. Вывод в консоли статистики на текущий момент не информативно и может быть ошибочно.

bonding не делает "трубу" больше, он делает ее шире, соответственно, если у вас всего 2 хоста для обмена трафиком, то больше физической скорости одного порта вы не выжмете как не упражняйтесь в алгоритмах распределения трафика, переходите на 10gb карточки, или на fibrechannel :)