iddqda

Спасибо. Как раз собирался этим заняться после НГ
Правда мне на лету это делать не особо и нужно. Производительности хватает пока.
Я думаю просто начать создавать партиций начиная с определенного момента, а потом, через год, отключить housekeeping и начать дропать хвосты.

кстати, как считаете, вот эта хранилка из wiki zabbix-а достаточно надежная для автоматизации обслуживания партицирования?

Просыпался без будильников в районе от 13:30 до 14:30, засыпал до 6:30 утра

Это же ровно +7 часов. Стандартный джетлаг Москва <— Нью-Йорк, Куба, Доминикана, Мексика (канкун)
Мой рецепт очень прост.
— По обычному времени спать не ложишься, тянешь до привычного времени просыпания (13:30-14:30 по местному времени).
— ложишься спать, спишь час-два и встаёшь по будильнику.
— активно заниматься разными делами типа в магазин в гости или просто гуляешь и так тянешь время часов до 10-11 вечера
— принимаешь таблетку мелатонина и ложишься спать

Все. Утром просыпаешься и топаешь на работу. Работоспособность нормальная, никаких последствий давлений и тахикардий и даже сонливости. Но вечером на всякий случай ещё таблеточку.

Многократно проверено на себе.

Спасибо большое за статью!
По результату прочтения уже запланировал сделать партиционирование в своем сетапе.
Есть два вопроса:
1. Отключили housekeeping, графики выровнялись…
И как мы теперь будем убивать устаревшие ненужные данные? Место на диске не бесконечно

2. Если я применяю MySQL и не собираюсь погружаться в Postgres могу ли я использовать TimescaleDB?

раскройте пожалуйста тему XML APIs
и что с поддержкой EVPN и стратегией развития/поддержки SPBm?
спасибо

Шато-Тамань Совиньон за 170р в КБ очень приятное вино, особенно учитывая цену. По соотношению цена/качество уделывает дешевое итальянское в Италии. К слову, в Италии предпочитаю покупать вино за 10+ евро. т.е. породистые нобиле, брунело, бароло, вальполичело-супериоре, амароне, или разные от болгери, т.е такие что у нас от 2тр стоит по акциям.

это про 10/8 или 127/8
а как вам 240/4?

не попытается сбежать с места аварии

вот тут не уверен.
детектирование ДТП, если это легкое касание, технически не такая простая задача.
Как робот может понять что его кто-то задел? По звуку и/или по акселерометру. Звуков вокруг полно, пойди распознай нужный. Дороги кривые и показания акселерометра так же спорные. Допускаю, что алгоритмы такого детектора несовершенны и при этом его тестам уделяют меньше внимания чем пилотированию. Так что если хотите чтобы робот не сбежал, тараньте его как можно сильнее :)

Спасибо, не знал о таком
Теперь можно норм CI/CD делать
конфиги то давно шаблонизируются, а вот как быть с тестами было не понятно
обязательно поиграюсь в эту рыбку
надеюсь EVPN/VxLan оно умеет или скоро научится

Размышления какие то натянутые, но вопросы подняты интересные

Наброшу свои тезисы для решения поднятых проблем:

1. автомобили АА являются общественным транспортом.
Ответственность делегируем государству или крупному перевозчиком.
Автомобили принадлежат им же.
Неибежные жертвы администрируются так же как при авиа-жд-катастрофах или кораблекрушениях
2. АА движутся по выделенной инфраструктуре (лучше рельсовой и в тунелях) и связаны общим контроллером. Скорость движения небольшая чтоб минимизировать повреждения. Интервалы дециметровые.
3. Внешний вид АА сугубо утилитарный. Никаких крашеных бамперов. Допускаются контакты с другими АА. Резинка по кругу как в машинках в парках аттракционов.
4. Грузовой и пассажирский транспорт использует разную инфраструктуру. Грузы так же можно доставлять дронами и пневмопочтой.
5. Внутри города и снаружи инфраструктура и транспорт значительно отличаются. Это хороший задел на будущее. После ядерной войны можно будет использовать паровозы.

про top-of-rack, синхронный-асинхронный ЦОД и SDN чушь
да, возможно, в хуавей эти концепции понимают именно таким образом,
но это совершенно не значит, что все остальные строят ЦОДы неправильно

1. модульные коммутаторы нужны больше продаванам коммутаторов. Сейчас одноюнитовые spine свичи есть с емкостью 32х400G. Для них, как для модульных не нужно выделять стойку. Можно и как top-of-rack ставить и сводить туда все ToR
2. синхронность ЦОДов вообще бред. Синхронными/асинхронными могут быть различные сервисы, но не ЦОД целиком. И задержка на 1000км это в реальности задержка 10мс в одну сторону. Вполне годится для множества сервисов с синхронной репликацией. Просто репликация делается средствами приложения или субд, но не массивом хуавей или гипервизором.
3. А теперь расскажите циске, что ACI это не SDN. Ведь там нет OpenFlow

А вообще тест понравился. Сделан качественно в плане оформления.
Чуть поправить название — «Не кодом единым: тест на знание серверной инфраструктуры Huawei»
— и станет совсем хорошо

Не так давно состоялась ожесточенная битва между IBM и Digital Equipment Corporation (DEC)

wiki говорит, что DEC был поглощен в 1998 году
не так давно да.
надеюсь в следующих выпусках будут подробно расписаны DecNet, AppleTalk, FrameRelay и IPX

к вашему контроллеру наверно можно приделать другие полезные датчики,
влажность можно измерять, протечку или даже проникновение
а для температуры немного оверкил как по мне. Но прикольно да

А у меня в серверной почти в каждой стойке top-of-rack switch есть с датчиками температуры
которые вполне нативно мониторятся тем же заббиксом

эх скукотища
В прошлом году Вы пытали нас бесконечным курсом сетей для продажников (так и не понял почему для продажников тему сети надо объяснять как то особенно)
Теперь тот же курс для всех остальных человеков, правда немного тормозов, судя по заявленной длительности курсов.
В следующем году будут, наверное, опять сети с нуля для водителей трамваев
Учитывая сколько лет существует CCNA, уверен, такие курсы существуют.

Мое, как сетевика с многолетним стажем, ИМХО такое:
1. блистательный сборник статей от linkmeup раскрывает тему сетей с самого нуля и далеко за темы CCNA и местами CCNP
2. получение знаний уровня CCNA полезно, но упарываться на экзамен и сертификат не стоит.

Сейчас в сетевой индустрии можно сказать революция происходит. Столько тем новых вокруг. А вы тратите время и силы на курс, половина которого про STP протокол, использовать который в дизайне давно зашквар.

На самом деле я уважительно отношусь к любому труду, и к Вашему конечно тоже, — перевод вполне качественный, работа грандиозная, — но просто тема унылая и жеваная пережеваная.

Спасибо, прочитал с интересом. Тема мне очень близкая. Тащу примерно такие же задачи, правда в меньшем объеме, но стараюсь по возможности автоматизировать. Для чего использую те же инструменты: zabbix, python, ansible еще.

Отдельное спасибо за рассказ про компьютер под столом, общие папки и IPAM в xls — это прям откровение.
А где же ci/cd и скрам с эджайлом?
Я думал у вас почти Амазон :)

Пара вопросов:
1. Как себя ощущает сервер на виртуалке с 14К хостов и 144K Items?
У меня железный Xeon трудится с 24 ядрами и 32Г памяти, обслуживает около 1К хостов и 60К Items и дышит с трудом

2. «Недостаточная вложенность действий, т.к. часто необходимо вытянуть значение по SNMP и использовать результат в следующем запросе»
LLD неплохо подходит для этого. Там как раз два прохода получается: Discovery rules + Items Prototypes

3. На скринах засветились циски и проприетарный цискин DMVPN. У вас только сеть Заббиксом мониторится? Не пробовали что-нибудь специальное сетевое? LibreNMS например?

4. В чем храните конфиги тех же цисок?

1. серверный истанс не обязан стоять именно на тех же серверах, что и тестовые среды. можно все инстансы собрать на отдельную ферму и в отдельную подсеть и в облако, да куда угодно. А в zabbix-agent-ы разных сред добавить к параметру ServerName, кроме вашего центрального сервера, FQDN инстанса соответствующего среде
2. А кто же те 1000 пользователей вашего централизованного забикса. Они если сейчас не эксперты, то для них мало что изменится. Ну url будут другой писать.
3. Администровать все инстансы будет по прежнему ваше подразделение
4. Конечно его необходимо оставить. Я об этом прямо написал
5. Вот тут согласен :)

И это… я не настаиваю, просто в последнее время начал смотреть на различные ИТ решения под углом: «А насколько это решение масштабируется?»

Спасибо, интересно
Но вот такой вопрос, навеянный цифрой 1500 тестовых сред и затем слайдом с Магнитом, в котором указано 11К прокси:
А не приходила мысль на 1500 тестовых сред создавать 1500 инстансов заббиксов, локальных для каждой тестовой среды? Так же как вы раскатываете zabbix-агентов, тем же ансиблом можно автоконфигурить и раскатывать и zabbix-server-а
В каждом таком инстансе будут свои пользователи со своими метриками от своей тестовой среды. Требования по производительности инстанса минимальны. Можно развернуть на виртуалке или даже в докере.

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

Не знал про «Космический рейс», спасибо
По сюжету очень похоже на недавнего «Марсианина» и местами на «Незнайку на луне»

Что касается вашего произведения, то первый отрывок показался весьма попсовым, что, наверное, неплохо, просто пока ничего научного в этой фантастике не наблюдается

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

Больший интерес для темы данной статьи представляет описание применения программной модели обучения MAC адресов в Overlay сети для сценария включения или отключения порта доступа

И вот тут очень трудно сообразить, что это как раз один из подходов по решению задачи MLAG и был.
Ну еще можно добавить, что в случае с EVPN, MLAG можно реализовать так же и традиционным способом с помощью vPC. И тут же минусы vPC озвучить.
А еще, что в терминах cisco описанный подход называется BGP EVPN Multihoming. Потому что для тех кто захочет копнуть глубже, гугление по словам «применения программной модели обучения MAC адресов в Overlay сети для сценария включения или отключения порта доступа» можно будет найти исключительно Вашу статью :)

Я если что не претендую, сам только начал погружаться в этот удивительный мир фабрики.
Поэтому заодно воспользуюсь случаем и задам вопрос эксперту:

Если мне теперь не нужен vPC и соответственно нет необходимости собирать попарно leaf-ы и соединять их через spine,
то что мне мешает совсем отказаться от spine коммутаторов
при условии что мои портебности в портах доступа закрывают 3-4 leaf-а?

т.е. сделать вот так:

картинка тянута отсюда (прости Ivan)
но используя EVPN Multihoming сделать подключение к серверам active-active

Извиняюсь самую главну опцию то и забыл

iddqd@hostname:~$ iperf --help
--
  -b, --bandwidth #[KM]    for UDP, bandwidth to send at in bits/sec
                           (default 1 Mbit/sec, implies -u)

ну т.е. моя команда часто выглядит так:

iddqd@hostname:~$  sudo iperf -u -c $remote-if-addr -b8M -t600

И я не знаю может udpblast и вправду ничем не хуже
просто встал на защиту любимого iperf :)

Ну не знаю
Для цели ткнуть носом провайдера в несоответствие bandwidth я поступаю следующим образом:

1. iperf -c -u wan-ip-addr-of-remote-device -t600
   2a. Захожу на observium (cacti, prtg, etc) и смотрю realtime загрузку интерфейса
   2b. Захожу на удаленное устройство ( как правило это джунипер) и смотрю monitor interface

А параметры канала в это время меряются вечными тестами cisco ip sla или juniper rpm с сигнализацией в zabbix

Так как задачу «ткнуть носом провайдера» приходится делать нечасто, то автоматизация мне пока не требуется. Но смысл в том, что iperf на udp никакой ответки не требует. Да без ответной части он не посчитает количество принятых пакетов, но и ваш скрипт эту информацтю не из генератора тянет.

Да нет анамнеза. Просто я согласен, что здесь в отрасли адовый зоопарк сейчас.
И bigswitch c Plexxi тоже весьма экхотические зверушки в нем
Но Underlay может быть и простой IP фабрикой (протокол не так важен, тут главное ECMP)
или даже L2 как в решении по той ссылке.

А если даете ссылки на blog.ipspace.net
то наверное согласны в чем то с автором блога
И если согласны с ним по позиции L2 Vlan Stretching
то проблемы DCI решаются очень просто
Убрать Vlan Stretching и выбросить из дизайна всех этих чудищ OTV, SPB, MPLS, VXLAN, EVPN итп,

з.ы. лет 6 назад именно Техносерв нам настойчиво впаривал OTV хотя мы с порога дали понять, что L2 между ЦОДами нам неинтересен. Еле отбились :)

Ну вопрос про DCI отличный, вот только я его не задавал
под склейкой CLOS я имел ввиду внутренний протокол фабрики т.е. чем вязать Leaf-ы и Spine-ы :)
Но мне больше интересно что уважаемый архитектор скажет про вариант по ссылке

помолчу про водную вводную
а дальше, если я правильно уловил суть, то поднимается вопрос
чем склеивать CLOS фабрики
согласен что SPBm, FabricPath и Trill все выродились в вендор-лок-ин
но и EVPN не единственная лошадка
Те же VXLAN-ы на L3 фабрике можно было использовать когда EVPN-а еще не было

а отдельные, чисто облачные блоки, можно строить вообще интересным образом
vincent.bernat.im/en/blog/2018-l3-routing-hypervisor

прошу прощения за несовсем конкретную ссылку

посмотрите еше раз: http://linkmeup.ru/sdsm

А насчет OSI, она все таки меняется
сети разделяются на underlay/overlay со своими слоями
и LinkLayer из L2 по факту исчез для Ethernet

Спасибо за предложение. Но я умею читать по английски, хотя чаще слушаю
Я исходил их того, что переводы хороши для тренировки навыков первода и Вы ради развития этого навыка стараетесь. В таком случае можно было бы совместить пользу для Вас и для остальных выбирая более актуальные темы.
Но я не волен конечно склонять Вас к чему то. Да и не собирался. Просто немного скучно все время про циску читать если честно.

p.s.
Попробуйте в гугл сравнить результаты поиска по таким запросам

• Eddy Martin books
• russ white books

про перевод не скажу, не вникал
но сама статья, простите, усилий по переводу не заслуживает

Catalyst6500, nexus7000, серьезно?
оно давно не продается и даже не поддерживается
уж не говоря о том, что первые nexus-ы, особенно с M1/F1 картами это ужас-ужас

зачем в 2018г читать про то как правильно выбирать коммутаторы из 2012 года

Да и сама серия, похоже, подходит только для определенного контингента

Благодаря ей продавцы способны начать понимать основы сетей и тех продуктов, которые существуют для решения тех или иных задач

Для тех кто хочет изучит тему на хабре есть блестящая серия от Linkme.up

Но если так хочется переводить по теме, возьмите статьи от Russ White или Geof Huston
или если нравится про старье, возьмите что нибудь про историю создания BGP или MPLS

откровением исследование не стало
Организаторам таких гостевых сетей достаточно по минимуму исполнить 97-й ФЗ в части постановления №801. т.е. предусмотреть авторизацию по СМС чтоб не налететь на 300тр штрафа. т.е. угроза в таких случаях исходит больше от разного рода роскомнадзоров, а не от призрачных хакеров.

Вообще я решаю сейчас похожую задачу: организацию гостевого доступа с СМС авторизацией. И не особо понятно как на недорогих точках можно навернуть нечто большее чем авторизацию по маку

может кто подскажет?
У меня схема такая:
AP спрашивает контроллер что мне с новым маком делать?
контроллер редиректит пользователя на external captive portal попутно обогащая HTTP GET запрос параметрами user_mac и ip_mac (а других параметров точка и не сообщает).
captive запрашивает номер телефона, генерирует и высылает пин, запрашивает пин и авторизует на контроллере на определенное время. котнтроллер, соответственно дает команду точке AP и пользователь вываливается в интернет.

ну и как тут можно предусмотреть подмену мак адреса?

Забавная статья. Видно, что идут действительно масштабные проекты по консолидации ИТ инфраструктуры, строительству ЦОДов, модернизации сетей и серверов, объединению с банком Москвы. И на фоне этих мощных процессов ваше VDI решение это такое параллельное действие, которое, впрочем, стоит совершенно дурных денег. Но при этом решает какие то надуманные проблемы и привносит столько же если не больше новых.

Вообще, на мой взгляд VDI это шаг назад
Тонкие клиенты давно стали толстыми. Посмотрите сколько памяти кушает ваш браузер. Тенденция такая, что в целях масштабирования сервиса логика приложений с сервера перемещается к клиенту. Использует его вычислительные ресурсы, прежде всего его оперативную память. С точки зрения затрат на запуск сервиса эта память не стоит ничего. Она уже есть на каждом рабочем месте пользователя
И тут бац… VDI на 2000 клиентов.
Все ресурсы, которые уже были у клиентов мы покупаем еще раз, но уже за другие деньги. Вендоры нам радостно впаривают дорогущее железо и софт с бесконечными лицензиями.

Хотя, конечно кое где VDI может быть полезен. Для задач обучения например, когда виртуальное окружение нужно быстро менять под каждое занятие. Или под совсем совсем удаленные офисы где нибудь в тундре где каналы связи просто золотые. Но между Воронежем и Москвой или Питером можно купить гигабитный канал по цене десятка лицензий на цитрикс в год

Ну и не могу не отметить вот эту на мой взгляд несуразность:

Другие варианты доступа существенно ограничивали бы производительность отдельных приложений (особенно самописных решений с частыми обращениями к серверу) при попытке работы через WAN-каналы с их лимитами по пропускной способности и большим временем отклика

Вы пишите приложение, которое не работает на медленных каналах и вместо того, чтобы переработать архитектуру вашего приложения вы перерабатываете всю ИТ инфраструктуру.
Ну и пассаж по программно-определяемые сети и VXLAN порадовал. Типа у нас их пока нет, но мы знаем что это такое и значит мы крутые.
Забавно, что Джет качество статьи вполне удовлетворяет и они отдельно промо-пост сделали со ссылкой на вашу статью :)

При этом я уверен, что у вас полно весьма продвинутых ИТ специалистов, но руководство всегда идет на поводу у вендоров и интеграторов какой бы треш они не предлагали.

на гитхабе есть такой проект 5-ти летней давности
github.com/cmouse/ip-sla-responder

там на разных портах реализованы респондеры сразу и на SLA и на RPM

Спасибо за публикацию. Не то чтобы узнал что-то новое, но ваша статься натолкнула меня на написание своей статьи по схожей теме habrahabr.ru/post/349128

и в результате я наконец вышел из тени.
т.е. мои комментарии добавляются без премодерации. Ура! :)

Спасибо, статья интересная
Причем интересная в технической части, а не в той, которая заявлена в названии
Согласитесь, причина по которой компании приходят к концепции ОЦОД + РЦОД могут быть совершенно разными,
Но техническая реализация все же больше зависит от требований по надежности, производительности, катастрофоустойчивости и конечно от затрат. А не от того иностранная это компания или местный энтерпрайз переросток

Это я к тому, что информация в статье весьма ценная, но заголовок и водянистое начало статьи могут оттолкнуть целевую аудиторию от дальнейшего прочтения, а там самый жир

Пару вопросов по сетевому дизайну:
1. EIGRP — это такой мощный вендор-лок.
Вы аргументировали применение EIGRP тем что в OSPF необходимо тюнить много таймеров.
Но все перечисленное вами сетевое оборудование поддерживает BFD. OSPF как и остальные реализованные в современном железе протоколы могут использовать BFD вместо keepalive. BFD реализованы прям в ASIC-ах а там субсекунды гораздо субсекундней.

2. тунели и DMVPN — второй вендор-лок и заплесневелая технология.
Если операторы филиальной сети разные то относительно удобно. Иначе используя динамику на стыке с оператором можно получить полносвязную подсеть организации без всяких тунелей. Правда в идеале для этого должен быть единый оператор. Но ведь с интернетом получилось найти 2-х операторов с присутствием на двух площадках

3. GRE тунель между граничными BGP маршрутизаторами. Из рисунка непонятно на чем тунель держится. Если отдельный линк через DCI то зачем GRE. А если тунель через интернет то получается уроборос.
BGP зависит от EIGRP, а EIGRP от BGP. Как такое траблшутить в случае чего?

4. BGP conditional. Я конечно не знаю подробностей задачи. Но почему было не разделить /24 на две /25 и анонсировать с каждого сайта свою половинку, благо оператор один?

з.ы. Картинки красивые. В чем рисовали?

Спасибо, интересно
Но хотелось бы все же больше технической информации
как реализован роуминг поезда между базовыми станциями?

Попробую сделать предположение как это могло быть реализовано:
1. Весь поезд выходит в стационарную сеть через 1 IP адрес и соответственно 1 мак адрес
2. Базовые станции одного тоннеля находятся в одном L2 домене
3. На коммутаторе уровня доступа стационарной сети, в который включены базовые станции одного участка тоннеля, отключен mac-learning. Таким образом обратный трафик классифицируется как unkown-unicast и броадкастится во все порты и соответственно базовые станции. Это не большая проблема, так как в одном участке тунеля, обслуживаеммого одним коммутатором доступа не так много поездов помещается одновременно.

Интересно что происходит дальше на уровне аггрегации
Тут уже броадкастами не отделаешься иначе 10Г аплинки просто убьют уровень доступа.
Как рещается задача при проезде поездом от одного коммутатора доступа к другому?
Если оставить как есть по умолчанию, то получается ситуация когда поезд отправил пакет в сеть в 1-й коммутатор доступа и уехал в другой коммутатор. Обратные пакеты так и будут приходить в 1-й коммутатор и броадкаститься в пустой тунель до тех пор пока любой пользователь в поезде не пошлет новый запрос в сеть и коммутатор аггрегации не словит мак на новом порту в который подключен коммутатор 2.
Для интерактивного трафика это не проблема. Там все время происходит ситуация запрос-ответ. Но если ехать в поезде одному и допустим слушать интернет-радио, то оно просто оборвется и будет молчать до первого пакета от пользователя в сеть. Или от поезда. Поезд ведь мониторится постоянно. В активном режиме мониторинга (когда данные иду со стороны поезда) эта проблема элегантно решается сама

Извините увлекся. Наверное мой комментарий не имеет ничего общего с вашим решением.
В любом случае очень любопытно как вы реализовали роуминг
А так же строите ли свою сеть доступа для наземного транспорта или используете существующие 3G/LTE мобильных операторов

тут так же лишние слова про DHCP-relay
релеем выступает коммутатор
DHCP сервер парсит значения, которые relay вставил в пакет, но сам никаким боком релеем не является.
Это даже из приведенной схемы очевидно

Если на этом интерфейсе висит несколько адресов из разных VLAN

под интерфейсом здесь понимается L3 интерфейс, правильно?
Тогда остальное в предложении звучит странно. И если так и бывает то так делать точно не надо.
Или признайте, что VLAN-ы все таки тут не разные. Разные могут быть адреса в одном VLAN-е, что тоже является bad practices.
Так вот option82 тут никак не поможет.
Вам кажется что Вы выдали адрес на основе option82
Но судя по приведенному конфигу, все происходит вовсе не так

запрос попадает в subnet, на основе адреса релея (того самого L3 интерфейса)
потом dhcp сервер выбирает адрес из pool
а потом на основе вашей option82 происходит тупая фильтрация — выдавать адрес или нет.
Сам option82 никак не определяет из какого диапазона будет этот адрес. Так что Вы и сами заблудились и других заблудили. Проверьте, попробуйте убрать все ваши классы и условия. Ничего не изменится

Ну а что касается репликации статических лизов, то у меня как раз есть решение.
идея очень простая:
Если статическую запись host{} вынести за subnet{}, то сервер все равно сопоставит host с subnet и аккуратно добьет статический IP адрес соответствующими опциями (маска шлюз DNS NTP итп) из subnet.
А значит всю статику можно вынести в отдельный файл и просто использовать директиву Include.

А уж отдельный файл можно легко реплицировать любыми средствами.
Хотя лично я вместо репликации генерирую его из IPAM. Очень удобно.

Ха, а я делал наоборот. Вытаскивал OID-ы из mysql базы observium и добавлял в заббикс тем же pyzabbix.
Обсервер хорош как раз автообнаружением параметров по snmp. Когда нужно было заббиксом мониторить здоровье Nexus-ов, я устал oid-ы выковыривать по одному. Набросал скрипт и разом получил несколько сотен item-ов.

одну разрушает — другую создает
выбирайте любую подходящую концепцию под задачу
зачем с ними бороться?

передать вычислительную мощность на сторону клиента разгрузив сервер и тем самым обслужить больше клиентов меньшими средствами — это замечательная парадигма.
назвать это абсурдом и всячески бороться?
кому и для какой цели нужен по настоящему тонкий клиент и действительно толстый сервер?

а нафига, простите, для векторного гипертекста придумывать новый сетевой протокол?
сетевой протокол решает задачи маршрутизации, а никак не payload