Спасибо, не знал о таком
Теперь можно норм 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 например?
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
Ну не знаю
Для цели ткнуть носом провайдера в несоответствие bandwidth я поступаю следующим образом:
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-а еще не было
Спасибо за предложение. Но я умею читать по английски, хотя чаще слушаю
Я исходил их того, что переводы хороши для тренировки навыков первода и Вы ради развития этого навыка стараетесь. В таком случае можно было бы совместить пользу для Вас и для остальных выбирая более актуальные темы.
Но я не волен конечно склонять Вас к чему то. Да и не собирался. Просто немного скучно все время про циску читать если честно.
p.s.
Попробуйте в гугл сравнить результаты поиска по таким запросам
про перевод не скажу, не вникал
но сама статья, простите, усилий по переводу не заслуживает
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 и пользователь вываливается в интернет.
ну и как тут можно предусмотреть подмену мак адреса?
Теперь можно норм CI/CD делать
конфиги то давно шаблонизируются, а вот как быть с тестами было не понятно
обязательно поиграюсь в эту рыбку
надеюсь EVPN/VxLan оно умеет или скоро научится
Наброшу свои тезисы для решения поднятых проблем:
1. автомобили АА являются общественным транспортом.
Ответственность делегируем государству или крупному перевозчиком.
Автомобили принадлежат им же.
Неибежные жертвы администрируются так же как при авиа-жд-катастрофах или кораблекрушениях
2. АА движутся по выделенной инфраструктуре (лучше рельсовой и в тунелях) и связаны общим контроллером. Скорость движения небольшая чтоб минимизировать повреждения. Интервалы дециметровые.
3. Внешний вид АА сугубо утилитарный. Никаких крашеных бамперов. Допускаются контакты с другими АА. Резинка по кругу как в машинках в парках аттракционов.
4. Грузовой и пассажирский транспорт использует разную инфраструктуру. Грузы так же можно доставлять дронами и пневмопочтой.
5. Внутри города и снаружи инфраструктура и транспорт значительно отличаются. Это хороший задел на будущее. После ядерной войны можно будет использовать паровозы.
да, возможно, в хуавей эти концепции понимают именно таким образом,
но это совершенно не значит, что все остальные строят ЦОДы неправильно
1. модульные коммутаторы нужны больше продаванам коммутаторов. Сейчас одноюнитовые spine свичи есть с емкостью 32х400G. Для них, как для модульных не нужно выделять стойку. Можно и как top-of-rack ставить и сводить туда все ToR
2. синхронность ЦОДов вообще бред. Синхронными/асинхронными могут быть различные сервисы, но не ЦОД целиком. И задержка на 1000км это в реальности задержка 10мс в одну сторону. Вполне годится для множества сервисов с синхронной репликацией. Просто репликация делается средствами приложения или субд, но не массивом хуавей или гипервизором.
3. А теперь расскажите циске, что ACI это не SDN. Ведь там нет OpenFlow
А вообще тест понравился. Сделан качественно в плане оформления.
Чуть поправить название — «Не кодом единым: тест на знание серверной инфраструктуры Huawei»
— и станет совсем хорошо
не так давно да.
надеюсь в следующих выпусках будут подробно расписаны DecNet, AppleTalk, FrameRelay и IPX
влажность можно измерять, протечку или даже проникновение
а для температуры немного оверкил как по мне. Но прикольно да
А у меня в серверной почти в каждой стойке top-of-rack switch есть с датчиками температуры
которые вполне нативно мониторятся тем же заббиксом
В прошлом году Вы пытали нас бесконечным курсом сетей для продажников (так и не понял почему для продажников тему сети надо объяснять как то особенно)
Теперь тот же курс для всех остальных человеков, правда немного тормозов, судя по заявленной длительности курсов.
В следующем году будут, наверное, опять сети с нуля для водителей трамваев
Учитывая сколько лет существует CCNA, уверен, такие курсы существуют.
Мое, как сетевика с многолетним стажем, ИМХО такое:
1. блистательный сборник статей от linkmeup раскрывает тему сетей с самого нуля и далеко за темы CCNA и местами CCNP
2. получение знаний уровня CCNA полезно, но упарываться на экзамен и сертификат не стоит.
Сейчас в сетевой индустрии можно сказать революция происходит. Столько тем новых вокруг. А вы тратите время и силы на курс, половина которого про STP протокол, использовать который в дизайне давно зашквар.
На самом деле я уважительно отношусь к любому труду, и к Вашему конечно тоже, — перевод вполне качественный, работа грандиозная, — но просто тема унылая и жеваная пережеваная.
Отдельное спасибо за рассказ про компьютер под столом, общие папки и 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. В чем храните конфиги тех же цисок?
2. А кто же те 1000 пользователей вашего централизованного забикса. Они если сейчас не эксперты, то для них мало что изменится. Ну url будут другой писать.
3. Администровать все инстансы будет по прежнему ваше подразделение
4. Конечно его необходимо оставить. Я об этом прямо написал
5. Вот тут согласен :)
И это… я не настаиваю, просто в последнее время начал смотреть на различные ИТ решения под углом: «А насколько это решение масштабируется?»
Но вот такой вопрос, навеянный цифрой 1500 тестовых сред и затем слайдом с Магнитом, в котором указано 11К прокси:
А не приходила мысль на 1500 тестовых сред создавать 1500 инстансов заббиксов, локальных для каждой тестовой среды? Так же как вы раскатываете zabbix-агентов, тем же ансиблом можно автоконфигурить и раскатывать и zabbix-server-а
В каждом таком инстансе будут свои пользователи со своими метриками от своей тестовой среды. Требования по производительности инстанса минимальны. Можно развернуть на виртуалке или даже в докере.
Конечно, главный Zabbix для мониторинга непосредственно железа и крутых отчетов останется, но нагрузка и количество пользователей радикально уменьшится. А насколько проще будет чистить базу от разобранных тестовых сред
По сюжету очень похоже на недавнего «Марсианина» и местами на «Незнайку на луне»
Что касается вашего произведения, то первый отрывок показался весьма попсовым, что, наверное, неплохо, просто пока ничего научного в этой фантастике не наблюдается
Есть пожелание немного четче структурировать
поначалу очень хорошо разбираются проблемы MLAG
Затем идет теория-теория, читатель засыпает
И потом раз:
И вот тут очень трудно сообразить, что это как раз один из подходов по решению задачи MLAG и был.
Ну еще можно добавить, что в случае с EVPN, MLAG можно реализовать так же и традиционным способом с помощью vPC. И тут же минусы vPC озвучить.
А еще, что в терминах cisco описанный подход называется BGP EVPN Multihoming. Потому что для тех кто захочет копнуть глубже, гугление по словам «применения программной модели обучения MAC адресов в Overlay сети для сценария включения или отключения порта доступа» можно будет найти исключительно Вашу статью :)
Я если что не претендую, сам только начал погружаться в этот удивительный мир фабрики.
Поэтому заодно воспользуюсь случаем и задам вопрос эксперту:
Если мне теперь не нужен vPC и соответственно нет необходимости собирать попарно leaf-ы и соединять их через spine,
то что мне мешает совсем отказаться от spine коммутаторов
при условии что мои портебности в портах доступа закрывают 3-4 leaf-а?
т.е. сделать вот так:
картинка тянута отсюда (прости Ivan)
но используя EVPN Multihoming сделать подключение к серверам active-active
ну т.е. моя команда часто выглядит так:
И я не знаю может udpblast и вправду ничем не хуже
просто встал на защиту любимого iperf :)
Ну не знаю
Для цели ткнуть носом провайдера в несоответствие bandwidth я поступаю следующим образом:
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 между ЦОДами нам неинтересен. Еле отбились :)
под склейкой 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.
Попробуйте в гугл сравнить результаты поиска по таким запросам
но сама статья, простите, усилий по переводу не заслуживает
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 и пользователь вываливается в интернет.
ну и как тут можно предусмотреть подмену мак адреса?