Про дизайны сети (часть 2): Избыточность и надежность

Безусловно, все сети, которые мы создаем, должны быть очень надежными и всегда работоспособными. Но мы-то с тобой знаем, что чудес не бывает, и за все в этом мире приходиться платить. В любой англоязычной литературе (к примеру, Cisco Press), как по дизайнам сети, так и по настройке оборудования, ты найдешь множество упоминаний слов «resiliency» и «redundancy». Конечно, сеть должна быть  надежной и избыточной. Вопрос лишь в том, какая степень этой избыточности необходима, и что произойдет, если какие-то компоненты сети выйдут из строя.

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

Одно последствие содержит в себе результат создания недостаточно надежной сети и наступает в том случае, если мы не оценили в полной мере необходимый уровень доступности определенного сервиса для ведения бизнеса компании. К примеру, мы не продублировали Voice gateway в колл центре компании, занимающейся активными продажами. Причем в данном случае под активными продажами я имею в виду не только то, что продажи осуществляются путем поиска клиентов и звонка им, но и то, что осуществляется более 100-150 телефонных звонков в час. В случае выхода его из строя – у нас намертво становиться возможность принимать / осуществлять звонки. Убытки огромные, и лучше было бы изначально заложить резервный VG, чем во время аварии бегать и искать решения.

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

Поэтому важно помнить, что проектирование сети – это всегда компромисс между техническими решениями «state-of-the-art» и потребностью бизнеса в надежности систем. Под компромиссом я понимаю ситуацию, когда учтены все требования, и они выполняются, а не когда приходиться отходить от каких-то требований в угоду другим. И более того, это не сказка, а реальная возможность. И чтобы подтвердить это тезис я приведу пару хрестоматийных примеров.

Пример №1.

Ты совершенно уверен, что чем больше линков между устройствами, тем надежнее сеть. Проще говоря: фулл меш (full mesh) – это круто.

 

Полносвязная топология

Полносвязная топология

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

Первое — это сложная топология STP. В структуре протокола STP есть такое понятие как root bridge, то есть устройство, от которого строится само «связующее» дерево (англ. Spanning tree). При настройке протокола STP на коммутаторах Cisco Catalyst есть возможность указать основной главный коммутатор (англ. primary root) и резервный главный коммутатор (англ. secondary root). От первого будет строиться дерево в нормальном режиме работы, от второго дерево будет строиться в том случае, если основной выйдет из строя. Понятия third root в настройке STP на коммутаторах  Cisco Catalyst – нет. Безусловно, ручным выставлением параметра bridge-priority можно добиться нужного результата, но это значительно усложнит процесс настройки и траблшутинг в случае аварии.

Второе, большое количество HSRP трафика, в случае настройки быстрой сходимости. А чтобы сделать классический дизайн, который считается лучшим с точки зрения надежности, достаточно двух коммутаторов на уровне агрегации (distribution layer).

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

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

У=Х*(Х-1)/2

В нашем примере количество коммутаторов Cisco Catalyst 6, получается 6*5/2=15. Добавление еще одного коммутатора увеличит количество линков до 7*6/2=21.

Пример №2.

А сейчас мы рассмотрим другой классический случай, на этот раз поговорим о недостаточном резервировании.

 

Подключение к Интернету без резерва

Подключение к Интернету без резерва

Ядро сети и уровень доступа в данном случае выполнено очень хорошо и правильно. Не будем вдаваться в детали настройки, но с точки зрения логической и физической связности здесь все здорово. Но подключение к Интернету выполнено без резерва. Соответственно, если что-то случается с нашим маршрутизатором, линком между нами и провайдером или на сети провайдера, то мы теряем возможность пользоваться Интернетом. Если основная деятельность нашей фирмы не связана с работой в Интернете, то это может быть и хорошо – не будут сотрудники сидеть в социальных сетях. Но вот если мы ведем активную торговлю через Интернет или любую другую деятельность, для которой необходимо постоянно быть online, то такое незарезервированное подключение может стать для нас большой головной болью.

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

 


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

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

Ваш 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