+7 (495) 788 99 99
Публикация  |  1 Ноября 2024

RIP BGP или супер-современное VS проверенное временем: всегда ли обосновано использование новейших технологий в реализации ИТ-проектов

RIP BGP или супер-современное VS проверенное временем: всегда ли обосновано использование новейших технологий в реализации ИТ-проектов

Зачастую технические эксперты стремятся внедрять только самые современные технологии и применять инновационные подходы. Однако стоит задуматься: всегда ли это оправданно и действительно ли необходимо? Иногда проверенные временем решения могут быть не менее, а порой даже более эффективными, чем популярные новинки. В качестве эксперимента я протестировал сеть с использованием старого, но надежного протокола RIP, который был создан 55 лет назад. Этот опыт показал, что даже такие давно существующие технологии могут стать основой для современных и производительных ИТ-инфраструктур, при этом оставаясь надежными и стабильными.

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

С чего все начиналось

Недавно, готовясь к выступлению на конференции linkmeetup в Казахстане, я в качестве эксперимента проанализировал несколько проектов, сделав акцент на сетевых архитектурных решениях. Каждый был уникален и отлично решал конкретные бизнес-задачи заказчиков. Это подтверждает, что для успеха важен не сам факт использования новейших технологий, а правильный выбор архитектуры, соответствующий целям проекта. Любой сложный дизайн, прежде всего, разрабатывается архитектором не как самоцель, а чтобы решить конкретную задачу бизнеса. Стремясь доказать это, я решил пойти «от обратного». В своем эксперименте я не использовал новейшие технологические решения, а попытался найти что-то очень старое и «давно забытое». Такой находкой для меня стал протокол маршрутизации дистанционно-векторного типа RIP (Routing Information Protocol). Он прост в реализации и на протяжении многих лет применялся в небольших сетях. Сегодня он признан устаревшим и практически не используется корпоративными заказчиками.

Эксперимент был призван подтвердить гипотезу: даже если сеть заказчика включает в себя большое количество унаследованных систем, построенных на основе устаревших технологий, эксперты Группы Rubytech смогут предложить ему уникальное и изящное решение.

Что и где я тестировал?

Будучи солидным системным интегратором, Rubytech может похвастаться наличием тестовой лаборатории, где инженеры проверяют работоспособность и производительность оборудования различных вендоров; изучают совместимость программных и аппаратных средств, их возможные конфигурации; разрабатывают целевые модели внедрения выбранных решений в ИТ-ландшафт заказчиков. Демолаборатория Rubytech — это мини-ЦОД, где мы строим стенды, на которых проводим тестирование оборудования и комплектующих для заказчиков, проверяем работоспособность и отказоустойчивость решений под реальной нагрузкой, моделируем различные стандартные и нештатные ситуации.

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

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

Второй проект предусматривал не только модернизацию ЦОД, но и расширение его новым сервисом. Исследования работы сети на стенде показали, что сеть в стандартном дизайне работает не совсем так, как хотелось бы нам и заказчику. Тогда мы добавили стык с MPLS (механизмом, осуществляющим передачу данных от одного узла сети к другому с помощью меток) и поменяли протокол маршрутизации IS-IS (Intermediate System to Intermediate System) на OSPF (Open Shortest Path First). В результате, получили не сверхоригинальный, но и не вполне типовой дизайн.

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

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

Пятый проект был также посвящен импортозамещению, но таил в себе целый ряд технических нюансов.

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

 

Таблица помогла мне сделать следующие выводы:

  • Дизайны реализованных проектов ни разу не дублируются.
  • Каждая архитектура показала хороший результат и полностью удовлетворила требования заказчика.
  • За все время эксплуатации вышеописанных сетей, ни у одного из заказчиков не возникло желания перейти на другой набор технологий и протоколов.

Эти выводы натолкнули меня на размышления:

  • А действительно ли всегда в проекте нужно использовать только новейшие технологии?
  • Будет ли сеть работать стабильно, если применять не самые «хайповые» протоколы и технологии?

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

Данная система, обязательно должна была соответствовать следующим требованиям:

  1. Быть отказоустойчивой и мгновенно реагировать на события внутри себя.
  2. Иметь возможность масштабироваться под требования бизнеса заказчика.
  3. Быть грамотно выстроенной и удобной с точки зрения эксплуатации, поддержки и развития.

Хотя устаревшие технологии могут и не соответствовать современным требованиям, существуют дополнительные опции, позволяющие ускорить работу оборудования и получить требуемый результат. Эксперимент с применением протокола RIP это доказал. В итоге мне удалось получить стабильную рабочую конструкцию. Этот пример продемонстрировал, что мои мысли были правильными!

Роль инженера в выборе технологий и решений

Результаты тестирования позволили сделать выводы не только относительно технологической составляющей проектов. Они также показали, что инженер — это не тот, кто создает решение «под копирку» и дальше тиражирует его, а эксперт, способный помочь заказчику добиться конкретных целей проекта. Причем, сделать это рациональным способом. Системы, которые он строит, должны быть простыми, надежными и выполнять тот функционал, ради которого они и были спроектированы. Если система не удовлетворяет хотя бы одному из этих требований, результат работы инженера нельзя считать удовлетворительным. Важно честно, открыто и доказательно демонстрировать заказчику оптимальные для него варианты решения поставленной задачи, а также делать акценты на возможных ограничениях.

Даже если изначально в технических требованиях обозначен перспективный, но менее подходящий для реализации конкретного проекта стек продуктов и технологий, опытный инженер должен предложить представителям на стороне заказчика другие более выигрышные подходы. Здесь инженер на стороне системного интегратора выступает в роли определенного «технического фильтра» и помогает заказчику выбрать лучший вариант.

Бывают также ситуации, когда заказчик предлагает вполне рабочие и, вроде бы, неплохо зарекомендовавшие себя технологии для дальнейшей реализации проекта. Однако в ходе многочисленных тестирований инженеры на стороне исполнителя убеждаются, что именно этот вариант в конкретном случае демонстрирует не самые идеальные результаты. В этом случае задача инженера показать представителям заказчика наглядные и объективные результаты для принятия дальнейшего решения. В идеале ИТ-инженер должен предлагать варианты, которые позволяют упростить интеграцию и эксплуатацию, сократить количество устройств. Однако все эти предложения должны основываться на практических результатах (тестированиях, подтвержденных конкретными показателями), а также на реальном опыте эксплуатации. Подтверждением всегда должен являться конкретный раздел ПМИ — отчет о результатах тестирования.

И, наконец, главный вывод: инженерия — это не просто знание и не просто искусство, а искусство применения знания!

Зачастую технические эксперты стремятся внедрять только самые современные технологии и применять инновационные подходы. Однако стоит задуматься: всегда ли это оправданно и действительно ли необходимо? Иногда проверенные временем решения могут быть не менее, а порой даже более эффективными, чем популярные новинки. В качестве эксперимента я протестировал сеть с использованием старого, но надежного протокола RIP, который был создан 55 лет назад. Этот опыт показал, что даже такие давно существующие технологии могут стать основой для современных и производительных ИТ-инфраструктур, при этом оставаясь надежными и стабильными.

Сергей Бочарников

Тимлид команды ЦОД Rubytech