Кабельное управление между несколькими стойками
Я нахожусь на этапе планирования перенастройки наших пяти стоек в одном из наших офисов, и я хотел бы попросить некоторых указаний относительно того, как вы работаете, или расскажу об управлении кабелями, проходящими между стойками. В нашей ситуации у нас есть 5 стоек, где крайняя справа - наша основная коммутационная панель на 300 этажных портов. Стойка рядом с ней - это наша основная стойка связи, в которой расположены главные коммутаторы и маршрутизаторы ISP. остальные 3 стойки рядом со стойкой связи должны быть подключены обратно к основной стойке связи.
Я не уверен, что 48-портовая патч-панель в каждой стойке подойдет для этого сценария? главным образом потому, что я не уверен, что это может быть связано с главным выключателем только с 1 кабелем.
Будет ли 48-портовый коммутатор в каждой стойке лучше, так как вы можете подключить их обратно к главному коммутатору?
Или мы должны просто проложить кабели между стойками обратно к главному выключателю?
Надеюсь, кто-то может предложить некоторое руководство.
2 ответа
Мое эмпирическое правило, основанное на годах строительства серверных комнат: максимально минимизируйте межстоечные кабели.
Стойка на 300 портов для периферийных портов далеко не заполнена, поэтому вы можете разместить пограничные коммутаторы в одной стойке. Это удерживает большую часть кабелей в одной стойке.
3 стойки слева: я полагаю, те, которые держат ваши серверы. Установите в каждый дешевый гигабитный коммутатор. Используйте 2, если у вас есть серверы, требующие избыточных ссылок. HP ProCurves или Dells отлично бы подошли. Если вы используете 1, не забудьте подключить его избыточно к вашим ядрам. Если вы используете 2 резервных коммутатора, им нужен только один восходящий канал (для разных ядер) каждый.
Соедините все 4 стойки с медью с вашими ядрами в стойке связи. Расстояния не гарантируют волокна, а медь все еще намного дешевле. Используйте несколько медных каналов 1 ГБ с агрегацией для увеличения пропускной способности, если это необходимо. В зависимости от ваших ядер / коммутаторов вариант может быть медным 10 Гбит / с.
Если у вас есть серверы, которым требуется соединение 1-на-1 с ядром или оборудованием интернет-провайдера, просто подключите дополнительный кабель UTP. Это не собирается тебя убивать.
Если ваши ядра представляют собой большие блейд-коммутаторы, которые также имеют граничные порты для самой правой стойки, серьезно подумайте о том, чтобы перенести эти ядра в эту стойку (если позволяет пространство). Никто в здравом уме не хочет соединить 300 UTP-кабелей между стойками.
Возможно, вам придется потратить немного денег на дополнительные коммутаторы, но это окупится за счет минимизации будущих проблем с поддержкой.
Пожалуйста, не рассматривайте это как ответ, потому что это ваш личный выбор в зависимости от ваших обстоятельств и бюджета. Я могу описать вам то, что мы сделали несколько месяцев назад в структуре в (я думаю) сопоставимом размере с очень низким бюджетом.
Мы должны управлять примерно 5 отдельными сетями и иметь одинаковое количество каналов Ethernet между стойками, распределенными в наших зданиях, что становилось все хуже и хуже в обслуживании. Мы решили заменить 3 старых коммутатора, чтобы они были одного и того же бренда (Dell) и типа, чтобы представить VLAN и использовать оптические соединения для более длинных сетей. Оптоволоконные соединения сегодня очень дешевы и очень просты в установке.
Стойки патч-панели были подключены двумя оптическими линиями (каждый) к двум основным коммутаторам, которые сами подключены друг к другу с помощью 4 медных портов (магистраль). В каждой серверной стойке у нас теперь есть один 48-портовый коммутатор, а на коммутационных панелях имеется 3x 48 портов (у нас есть две стойки для коммутационных панелей) и 1x 24 порта для небольшого отдела. Коммутаторы на коммутационной панели имеют только один восходящий канал к основным коммутаторам и соединены медными портами (также с использованием транкинга портов).
Теперь мы находимся в удобном положении, чтобы иметь возможность определять для каждого порта каждого коммутатора в каждой стойке, к какой сети он принадлежит (VLAN), и не нужно менять физические соединения (большую часть времени). Поскольку мы используем виртуализацию, она становится еще более гибкой, поскольку для виртуальных хостов нам просто нужно 1 физическое соединение для подключения виртуальных машин ко всем сетям. Еще есть над чем поработать (перенести брандмауэры на виртуальные локальные сети вместо физических портов), но мы очень довольны этим решением, и оно было действительно дешевым.