Тема ошибок, которые могут допускать специалисты в различных областях, практически неисчерпаема, но некоторые ошибки, вернее, их результаты, могут быть заметны далеко не всем. Так, ненастроенное журналирование событий совершенно незаметно обычным пользователям. И даже взлом, который произошел из‑за этих ненастроенных событий, тоже вряд ли заметят пользователи, если только потом об этом напишут в новостях.
Но вот ошибки при проектировании и эксплуатации сети становятся заметны сразу и всем — в случае если они приводят к проблемам в работе сети. В этой статье мы попробуем сделать разбор наиболее распространенных ошибок, которые могут допустить как проектировщики при планировании архитектуры сети, так и сетевые администраторы при эксплуатации.
Планирование превыше всего
Как хорошо, когда сеть вашей организации проектирует и внедряет интегратор. Вы выставляете им свои верхне‑уровневые требования, они готовят спецификацию, закупают и внедряют сетевое оборудование, пишут необходимую документацию… Что? Не написали проектные документы. А понятно, ваше руководство решило сэкономить и отказалось от разработки проектных документов.
А кто занимался проектированием сети? Интегратор, но они составили слишком жирную спеку и вы в последний вечер, не советуясь с ними ее «немного» порезали. Так, что в итоге от наших изначальных планов мало что осталось…
Да, это ироничную историю создания сети у заказчика я описал с точки зрения интегратора, и среди читателей наверняка найдутся те, кто сможет рассказать что‑то подобное с обратной стороны, когда заказчику потом пришлось вычищать косяки за интегратором. Но суть от этого не меняется — иногда, а скорее даже почти очень часто, сети во многих организациях создаются без должного планирования. Причины этого могут быть различными: от банальной жадности нехватки средств до отсутствия нужных компетенций у проектировщиков.
Давайте возьмем за основу нижние уровни модели OSI и посмотрим, где какие косяки могут скрываться.
Начнем с физики.
Кабель, который забыли
Несмотря на повсеместное развитие беспроводных технологий, проводные каналы связи по прежнему присутствуют в любом офисе. Если вы пришли в здание сразу после строителей то, у вас еще есть уникальный шанс повлиять на строение кабельной инфраструктуры. Если в здании слаботочка уже проложена, то изменить что‑то в кабельной системе бывает не всегда возможно. Особенно это относится к промышленным сетям, где прокладка кабелей между цехами зачастую превращается в нетривиальный квест.
Для того, чтобы избежать хабов, валяющихся у пользователей в кабинетах под ногами заранее возьмите план здания и посчитайте количество рабочих мест, но количество розеток обязательно возьмите с запасом, как минимум +4, а лучше +6 розеток на кабинет. Наверняка потом захотят поставить принтер или посадить кому‑нибудь на голову стажера. Для open space запас розеток должен быть еще больше, потому что они обладают «резиновыми» свойствами и руководство со временем сажает в такие помещения все больше народу.
Итак, розетки запланировали, кабели проложили. Помним, что кабельные каналы тоже могут заполниться и возможны ситуации, когда еще один проводок, про который все забыли, вы потом просунуть уже не сможете.
Идея отказаться от проводных каналов и всех посадить на Wi‑Fi вряд ли в реальности окажется такой замечательной, как вы ее себе представляете: пропускной способности в масштабах сотен пользовательских устройств может попросту не хватить, одинаковые каналы на разных точках могут мешать друг другу, не все пользовательские устройства могут поддерживать выбранный вами протокол и т. д.
Порты, которых вечно не хватает
Дальше проектируем коммутаторы. Здесь у нас скорее всего будут этажные коммутаторы, к которым собственно и будут подключаться пользователи. Здесь важно правильно рассчитать портовую емкость, то есть количество занятых портов должно быть что называется не в притык, иначе обязательно в самый неподходящий момент они закончатся.
Дальше у нас идут коммутаторы распределения и ядра. Здесь не забываем об отказоустойчивости (да, спека становится все жирнее), настраиваем Spanning Tree (если конечно это не промышленная сеть). Ну и не забываем правильно рассчитать портовую емкость, так как здесь замена коммутатора обойдется намного дороже не только по деньгам, но и по необходимым работам по миграции.
Маршрутизаторы, который может все
Неотъемлемой частью любой локальной сети является маршрутизация. Как обычно помним о надежности и отказоустойчивости. Настраиваем адресные пространства для тех сегментов, где нужны фиксированные адреса, и здесь, как и с портами на коммутаторах нам важно рассчитать подсети с запасом.
Например, если у вас в подсети 56 узлов, то идея назначить этой подсети маску /26 обречена на провал, так как оставшиеся несколько адресов вы скоро займете. При таком количестве узлов логичнее было бы назначить маску /24, должно хватить с запасом.
При планировании пулов DHCP также не забываем что адресов должно хватать всем и тоже с хорошим запасом.
Современные маршрутизаторы умеют практически все. На них есть и функционал межсетевого экрана, и VPN (как правило не ГОСТовый, но для удаленного доступа сойдет) и DHCP и многое другое. И в небольших организациях может возникнуть соблазн включить на маршрутизаторе все эти роли и не покупать отдельно ни файрволл ни криптошлюз. Так не надо делать, во‑первых из соображений безопасности: маршрутизатор, смотрящий наружу, пусть даже с включенным файрволлом это не очень хорошая идея, во‑вторых он превращается в единую точку отказа, и в‑третьих, чтобы не писал вендор в своих рекламных листовках, в реальности маршрутизатор будет постоянно перегружен из‑за большой нагрузки, что повлечет за собой как минимум низкую пропускную способность, а как максимум полный отказ в работе.
Так что, МЭ отдельно, VPN отдельно, а маршрутизатор должен отвечать только за маршрутизацию.
Бардак в серверной
Мы плавно переместились в серверную, где у нас живут коммутаторы ядра, маршрутизаторы и сами серверы с приложениями. Начнем с кабельной организации в самом серверном помещении.
Даже если изначально вы вроде бы старались соединять кабели в кроссах и между стойками аккуратно, через кабель каналы, со временем у вас может появиться такая «красота».
Понятно, что поиск неисправности на физическом уровне в таком случае превращается в крайне непростую задачу. Да, это относится уже не столько к планированию, сколько к сопровождению сетевой инфраструктуры, но тем не менее порядок в кабельной организации надо поддерживать с самого начала. Ну хотя бы вот так:
Еще хорошей практикой является использование кабелей разных цветов для разных классов систем. Например:
Желтые кабели — для кроссов
Красные кабели — для серверов, NAS
Синие кабели — для коммутаторов в кабелепроводе для настенных разъемов, а также для настенных разъемов на рабочем столе
Черные кабели используются между коммутаторами, маршрутизаторами и инфраструктурой
Зеленые кабели используются для временных подключений по мере необходимости
Еще одна важная часть этого стандарта — правильная маркировка обоих концов кабеля с указанием информации об устройстве. Знаете ли вы, какое устройство подключено к тому или иному порту вашего коммутатора? Если нет, то неправильная маркировка может стать причиной более длительного процесса поиска и устранения неисправностей. Время — деньги, поэтому чем дольше системы не работают, тем больше денег теряет ваша компания.
Сервер на магистрали
Теперь перейдем к размещению серверов. Как можно неправильно разместить сервер, ведь это же одна сеть, верно? Это момент, который многие упускают из виду при построении сети. Ваши серверы — это центральная точка всей сети, а это значит, что вам нужно как можно быстрее доставлять данные на серверы и обратно.
Давайте посмотрим на это с другой стороны. Допустим, вы отправляетесь в путешествие на автомобиле, и у вас есть два варианта — выехать на магистраль, где вы можете миновать все населенные пункты или выехать на местное шоссе, которое проходит через все деревеньки. Иногда это даже одинаковое расстояние, но что быстрее?
Автострада естественно быстрее, потому что вам не нужно снижать скорость, останавливаться и менять маршрут в каждом городе. То же самое происходит и с вашей сетью: каждый раз, когда вы добавляете коммутатор, концентратор, маршрутизатор или любое другое устройство, физически находящееся между компьютером пользователя и сервером, вы замедляете передачу информации. Поэтому при планировании сетевой топологии избегайте использования лишних устройств между пользователями и серверами с приложениями.
Документирование, которое мы не любим
Да, многие технари не любят заниматься бумажками. Но вести журналы портов на коммутаторах, в которых будут указаны какие порты к какому узлу подключены просто необходимо. Иначе вы рискуете столкнуться с ситуацией, когда вы будете думать, что на коммутаторе еще остались свободные порты, а на самом деле их уже нет. То же самое относится и к сетевым розеткам. Неплохо знать какой пользователь подключен к какой розетке.
Ну и в целом, в организации должны быть актуальные схемы сети на L1/L2/L3 уровнях. Но не стоит все эти уровни пытаться отобразить на одной схеме, рано или поздно вы ее перегрузите, и она станет нечитаемой.
К примеру, вот такая схема уже на грани:
Заключение
Вот собственно основные советы по проектированию и сопровождению сети. Конечно, построение хорошей архитектуры сети и ее последующее обслуживание не ограничивается только этими проблемами, но если вы сможете их избежать, то сеть будет работать намного стабильнее. Да, наверняка, а что‑то забыл) Напишите об этом в комментариях.
Хотите разобраться в проектировании сетей и избежать типичных ошибок?
Присоединяйтесь к открытым урокам — это отличная возможность узнать о ключевых аспектах сетевой инфраструктуры от практикующих экспертов.
OSPF Deep Dive: Практикум по построению карты сети из базы данных маршрутизаторов — 3 июля в 20:00
Особенности балансировки трафика в ЦОД от А до Я, чтобы не случилось «все упало, все пропало — 23 июля в 20:00
Пройдите вступительное тестирование и узнайте, насколько вашего уровня знаний достаточно для поступления на курс «Дизайн сетей ЦОД».