Про дизайны сети (часть 1): Варианты создания дизайна

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

Поэтому как сказал много лет назад Юрий Гагарин: «Поехали!»

Дизайн (англ. design) сети – это комплексное понятие: это и технические решения, которые заложены в основе работы сети передачи данных, и документ, который описывает эти самые технические решения. Будем мы говорить в первую очередь про первую часть определения, то есть про технические решения и их выбор, в зависимости от задач.

Дизайн сети передачи данных

Дизайн сети передачи данных

Сетевая модель OSI разбивает процесс передачи данных в сети на 7 уровней. Дизайн сети мы можем разбить на те же 7 уровней, однако в большинстве своем нам достаточно меньше. Уровни, которые нас очень сильно интересуют при создании дизайна, — это:

1)      Физический. Этот уровень описывает физическую связь устройств между собой, то есть физическую топологию сети, определяет среды передачи сигнала, определяет физическое расположение оборудования.

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

3)      Сетевой. То же, что и в предыдущем уровне, только протоколы уже сетевого уровня. Создание IP адресации сети, выбор протоколов маршрутизации, определение маршрутов движения трафика и многое другое – это все задачи данного уровня.

4)      Транспортный – прикладной. Все остальные уровни в абсолютном большинстве своем можно свести в один пункт. Безусловно, в зависимости от назначения создаваемой сети, описание верхних уровней может быть довольно обширным. К примеру, если мы говорим про сеть видеоконференцсвязи, то верхние уровни будут описывать параметры и работу H.323 или SIP в данной сети.

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

Первый подход – «стандартный». Суть его заключается в том, что мы начинаем решать проблему, начиная в лучшем случае с технического задания, а зачастую даже и без него. Очень часто решения задачи начинается с того, что мы хотим улучшить нашу сеть или добавить в нее какой-то сервис, не обладая полной картины, что же мы все-таки хотим сделать. Распространенный пример №1: у нас есть какое-то количество денег, на них мы купим вот этот свитч и маршрутизатор и посмотрим, как мы это можем внедрить в сеть. Распространенный пример №2: у нас было придумано какое-то решение, но деньги в полном объеме под него не выделили, и поэтому мы пытаемся вложиться в отведенный бюджет, при этом страдает качество решения. Распространенный пример №3: нам очень срочно надо расширить сеть и «у нас что-то есть на складе», что мы и пускаем в дело. Распространенный пример №4: мы уже так делали, сделаем и сейчас так же, или у меня так делали знакомые – работать стало лучше! Давай проанализируем все четыре примера: общее у них то, что отправной точкой являются деньги или конкретное оборудование.

Плюсы:

1)      Скорость внедрения решения

2)      Ограниченные затраты

Минусы:

1)      Несоответствие технических решений бизнес задачам компании

2)      Применимость решений в краткосрочной перспективе

3)      Часто нерациональное использование ресурсов

4)      Часто ухудшение масштабируемости и управляемости сети

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

Решение сетевых задач "как обычно"

Решение сетевых задач «как обычно»

Второй подход – «планирование». Суть данного подхода заключается в том, что создание дизайна идет исходя из бизнес задачи компании. Эта формулировка часто встречается в литературе, как официальной Cisco или других производителей, так и в различных презентациях. Не всегда понятно, что это такое и где граница между бизнес задачей и техническим требованием. Попробую объяснить на пальцах, чтобы у тебя эти вопросы прояснились. Пример №1: бизнес-задача – создать возможность сотрудникам работать с внутренними ресурсами компании из любого места, где есть связь. Техническое требование – организация VPN соединения, использование шифрования AES/3DES, количество одновременных сессий 50. Дальнейшая детализация технических требований формируется в техническое задание (ТЗ), что является гайдайном для создания дизайна. Пример №2: бизнес-задача – возможность позвонить каждому сотруднику на рабочее место. Техническое требование – установка VoIP терминалов для использования существующей кабельной инфраструктуры. При таком подходе уместно вспомнить механизм оценки, называемый impact-анализ. Суть его заключается в том, что происходит агрегация бизнес и технических требований и анализ их соответствия друг друга. После положительной оценки impact-анализа уже и формируется ТЗ, на основе которого и происходит создание дизайна сети.

Плюсы:

1)      Соответствие бизнес задач и технического решения

2)      Оптимальное техническое решение конкретной задачи

3)      Использование правильных инструментов для решения задач

4)      Решение создается с учетом удобства масштабирования и управляемости

Минусы:

1)      Большие временные затраты

2)      Возможно большие денежные затраты, по сравнению с предыдущим анализом

3)      На этапе определения бизнес задач и impact-анализа необходимо привлечение дополнительных специально обученных людей, если самостоятельно выполнить сложно

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

Решение сетевых задач "если подумать"

Решение сетевых задач «если подумать»

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


Комментарии:

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Hide me
Получать регулярно свежие материалы, лабораторные и вебинары
Email Имя
Show me