Забавная статья. Видно, что идут действительно масштабные проекты по консолидации ИТ инфраструктуры, строительству ЦОДов, модернизации сетей и серверов, объединению с банком Москвы. И на фоне этих мощных процессов ваше VDI решение это такое параллельное действие, которое, впрочем, стоит совершенно дурных денег. Но при этом решает какие то надуманные проблемы и привносит столько же если не больше новых.
Вообще, на мой взгляд VDI это шаг назад
Тонкие клиенты давно стали толстыми. Посмотрите сколько памяти кушает ваш браузер. Тенденция такая, что в целях масштабирования сервиса логика приложений с сервера перемещается к клиенту. Использует его вычислительные ресурсы, прежде всего его оперативную память. С точки зрения затрат на запуск сервиса эта память не стоит ничего. Она уже есть на каждом рабочем месте пользователя
И тут бац… VDI на 2000 клиентов.
Все ресурсы, которые уже были у клиентов мы покупаем еще раз, но уже за другие деньги. Вендоры нам радостно впаривают дорогущее железо и софт с бесконечными лицензиями.
Хотя, конечно кое где VDI может быть полезен. Для задач обучения например, когда виртуальное окружение нужно быстро менять под каждое занятие. Или под совсем совсем удаленные офисы где нибудь в тундре где каналы связи просто золотые. Но между Воронежем и Москвой или Питером можно купить гигабитный канал по цене десятка лицензий на цитрикс в год
Ну и не могу не отметить вот эту на мой взгляд несуразность:
Другие варианты доступа существенно ограничивали бы производительность отдельных приложений (особенно самописных решений с частыми обращениями к серверу) при попытке работы через WAN-каналы с их лимитами по пропускной способности и большим временем отклика
Вы пишите приложение, которое не работает на медленных каналах и вместо того, чтобы переработать архитектуру вашего приложения вы перерабатываете всю ИТ инфраструктуру.
Ну и пассаж по программно-определяемые сети и VXLAN порадовал. Типа у нас их пока нет, но мы знаем что это такое и значит мы крутые.
Забавно, что Джет качество статьи вполне удовлетворяет и они отдельно промо-пост сделали со ссылкой на вашу статью :)
При этом я уверен, что у вас полно весьма продвинутых ИТ специалистов, но руководство всегда идет на поводу у вендоров и интеграторов какой бы треш они не предлагали.
Спасибо за публикацию. Не то чтобы узнал что-то новое, но ваша статься натолкнула меня на написание своей статьи по схожей теме 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
Вообще, на мой взгляд VDI это шаг назад
Тонкие клиенты давно стали толстыми. Посмотрите сколько памяти кушает ваш браузер. Тенденция такая, что в целях масштабирования сервиса логика приложений с сервера перемещается к клиенту. Использует его вычислительные ресурсы, прежде всего его оперативную память. С точки зрения затрат на запуск сервиса эта память не стоит ничего. Она уже есть на каждом рабочем месте пользователя
И тут бац… VDI на 2000 клиентов.
Все ресурсы, которые уже были у клиентов мы покупаем еще раз, но уже за другие деньги. Вендоры нам радостно впаривают дорогущее железо и софт с бесконечными лицензиями.
Хотя, конечно кое где VDI может быть полезен. Для задач обучения например, когда виртуальное окружение нужно быстро менять под каждое занятие. Или под совсем совсем удаленные офисы где нибудь в тундре где каналы связи просто золотые. Но между Воронежем и Москвой или Питером можно купить гигабитный канал по цене десятка лицензий на цитрикс в год
Ну и не могу не отметить вот эту на мой взгляд несуразность:
Вы пишите приложение, которое не работает на медленных каналах и вместо того, чтобы переработать архитектуру вашего приложения вы перерабатываете всю ИТ инфраструктуру.
Ну и пассаж по программно-определяемые сети и VXLAN порадовал. Типа у нас их пока нет, но мы знаем что это такое и значит мы крутые.
Забавно, что Джет качество статьи вполне удовлетворяет и они отдельно промо-пост сделали со ссылкой на вашу статью :)
При этом я уверен, что у вас полно весьма продвинутых ИТ специалистов, но руководство всегда идет на поводу у вендоров и интеграторов какой бы треш они не предлагали.
github.com/cmouse/ip-sla-responder
там на разных портах реализованы респондеры сразу и на SLA и на RPM
и в результате я наконец вышел из тени.
т.е. мои комментарии добавляются без премодерации. Ура! :)
Причем интересная в технической части, а не в той, которая заявлена в названии
Согласитесь, причина по которой компании приходят к концепции ОЦОД + РЦОД могут быть совершенно разными,
Но техническая реализация все же больше зависит от требований по надежности, производительности, катастрофоустойчивости и конечно от затрат. А не от того иностранная это компания или местный энтерпрайз переросток
Это я к тому, что информация в статье весьма ценная, но заголовок и водянистое начало статьи могут оттолкнуть целевую аудиторию от дальнейшего прочтения, а там самый жир
Пару вопросов по сетевому дизайну:
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 вставил в пакет, но сам никаким боком релеем не является.
Это даже из приведенной схемы очевидно
под интерфейсом здесь понимается L3 интерфейс, правильно?
Тогда остальное в предложении звучит странно. И если так и бывает то так делать точно не надо.
Или признайте, что VLAN-ы все таки тут не разные. Разные могут быть адреса в одном VLAN-е, что тоже является bad practices.
Так вот option82 тут никак не поможет.
Вам кажется что Вы выдали адрес на основе option82
Но судя по приведенному конфигу, все происходит вовсе не так
запрос попадает в subnet, на основе адреса релея (того самого L3 интерфейса)
потом dhcp сервер выбирает адрес из pool
а потом на основе вашей option82 происходит тупая фильтрация — выдавать адрес или нет.
Сам option82 никак не определяет из какого диапазона будет этот адрес. Так что Вы и сами заблудились и других заблудили. Проверьте, попробуйте убрать все ваши классы и условия. Ничего не изменится
Ну а что касается репликации статических лизов, то у меня как раз есть решение.
идея очень простая:
Если статическую запись host{} вынести за subnet{}, то сервер все равно сопоставит host с subnet и аккуратно добьет статический IP адрес соответствующими опциями (маска шлюз DNS NTP итп) из subnet.
А значит всю статику можно вынести в отдельный файл и просто использовать директиву Include.
А уж отдельный файл можно легко реплицировать любыми средствами.
Хотя лично я вместо репликации генерирую его из IPAM. Очень удобно.
Обсервер хорош как раз автообнаружением параметров по snmp. Когда нужно было заббиксом мониторить здоровье Nexus-ов, я устал oid-ы выковыривать по одному. Набросал скрипт и разом получил несколько сотен item-ов.
выбирайте любую подходящую концепцию под задачу
зачем с ними бороться?
назвать это абсурдом и всячески бороться?
кому и для какой цели нужен по настоящему тонкий клиент и действительно толстый сервер?
а нафига, простите, для векторного гипертекста придумывать новый сетевой протокол?
сетевой протокол решает задачи маршрутизации, а никак не payload