Надмірність маршрутизатора та серверів

Раніше я використовував NetGear GS724T між маршрутизатором і серверами. Нажаль перемикач раптово помер.

Тепер я змінив його на GS748T, а також придбав ще один, і мені цікаво, як я міг досягти надмірності за допомогою цих двох комутаторів.

• Як мені потрібно налаштувати маршрутизатор для зв'язку з двома комутаторами: двома портами в мостовому режимі?
• Як синхронізувати комутатори, чи потрібно мені налаштувати STP та LAG?
• Що мені потрібно зробити на серверах (HP DL380 G5 з двома портами Ethernet, Linux), чи можу я підключити по одній Ethernet на кожному комутаторі, щоб і кабель був зайвим?
• Якщо я підключую два порти Ethernet від серверів, чи зможу я мати однакові IP адреси на обох інтерфейсах? (контекст в іншому моєму питанні )

Я знаю, що це не однозначне запитання, але я все ще не знаю, з чого почати, більше шукаю вказівники та / або путівники.

Я погоджуюся з @network_ninja, але трохи продовжую.

Як я вирішив би це

Router1--L3--Router2
|              |
|              |
Switch1--L2--Switch2
|    |         |
|    |         |
PC1 PC2--------+

Router1 і Router2 працюють VRRP , HSRP , GLBP або CARP для створення віртуальної IP-адреси GW за замовчуванням у локальній мережі.
Цей протокол переговорить ядро ​​Switch, щоб домовитись, який з маршрутизаторів у будь-який момент має IP-адресу GW за замовчуванням.

PC2 - це надлишковий сервер Linux, який використовує ' bonding ' для надмірного підключення до комутаторів, він повинен бути налаштований так, що якщо віртуальна IP-адреса за замовчуванням gw перестане відповідати ARP WHO HAS, він перейде на резервне з'єднання. Сама IP-адреса не на фізичних інтерфейсах, а на інтерфейсі віртуального зв’язку.
Еквівалентне рішення доступне для інших ОС, але часто не входить в базовий пакет ОС.

PC1 - не надмірний сервер.

Перемикачі не виконують нічого особливого, немає дерева, що охоплює (як немає циклу L2) і немає LACP. Вони можуть бути від різних постачальників і можуть бути зняті для обслуговування окремо.

Маршрутизатори не виконують жодних комутацій, IP-адреси налаштовуються безпосередньо в інтерфейсах L3, звернених до комутаторів.
Якщо ви обрали VRRP в якості своїх протоколів першої перестрибування, маршрутизатори можуть бути від різних постачальників. Кожен маршрутизатор може бути знятий для обслуговування окремо, витончено перемикаючи пріоритет VRRP перед роботою над основним.

Я викину на розгляд те, що більшість вважатиме трохи неортодоксальним рішенням.

Подумайте, як вирішити це за допомогою рівня 3 замість рівня 2.

Поставте обидва перемикачі на свої місця, і НЕ з’єднуйте їх. Підключіть маршрутизатор (и) до обох комутаторів. Підключіть свої сервери HP до обох комутаторів. Використовуйте два різних IP-блоки внутрішньо для того, щоб сервери могли спілкуватися з маршрутизатором (іми) ... по одному блоку на кожному комутаторі (і, отже, інтерфейс на маршрутизаторах (іх) та серверах). Поставте IP-адреси, які ви фактично використовуєте для спілкування з серверами, на інтерфейс зворотного зв'язку. Помістіть quagga на сервери та запустіть OSPF (у вашому масштабі, просто киньте все в області 0, не biggie) ... переконайтеся, що адреси / інтерфейси циклічного включення в конфігурацію OSPF. Покладіть OSPF на маршрутизатор (и).

Voila ', маршрутизатор (и) дізнаються про адреси, які ви насправді використовуєте для розмови з серверами через OSPF як маршрути хоста ... Якщо комутатор загине, відповідні адреси відходять, а трафік перенаправляється на інший комутатор .

Як бонус, якщо ви використовуєте різну IP-адресу для різних служб, які запускаєтесь на ваших серверах Linux, ви можете переміщати служби та пов’язані з ними IP-адреси безперешкодно, а мережа адаптується чисто та легко.

Немає небезпеки в цій установці поганої поведінки в ситуації з розділеним мозком, якщо зв’язок між двома комутаторами не працює ... немає небезпеки поганої поведінки з боку FHRP, таких як VRRP, HSRP тощо), немає небезпеки падіння комутаторів повернутися до неефективно затопленого руху, якщо ви зіткнетеся з асиметричною ситуацією.

Я використовую це рішення в набагато більшій обстановці, і його НЕОБХІДНО працює , він надзвичайно надійний і стійкий як до відмов обладнання, так і до помилок у налаштуваннях людини.

Що стосується серверних речей, якщо ви запускаєте центоси чи подібні, ви просто створите зв’язок між nics .

Що стосується Windows, я вважаю, що ви можете зробити те саме.

Тоді на стороні комутатора всі кабелі, що йдуть від сервера до комутатора, будуть частиною тієї ж влан.

Ще одна річ, яку ви можете зробити, якщо ваші комутатори підтримують це - налаштувати VRRP так, щоб ваш сервер використовував надлишкову адресу шлюзу.

Як заявили інші, зайві підключення до сервера будуть специфічними для платформи. Деякі операційні системи мають інтегрований механізм надмірності ніків, а деякі потребують додаткового програмного забезпечення, але більшість повинні мати можливість досягти активного / пасивного подвійного резервування подвійних нік.

Якщо в маршрутизаторі є інтегрований комутатор (наприклад, перемикач Cisco Wic) та підтримка stp (швидкий перевага), ви можете робити те, що я називаю одно-приєднаним U. Ви підключите порт L2 на маршрутизаторі до кожного перемикача і зробіть маршрутизатор кореня stp. Підключіть вимикачі разом (L2), і ви усунули всі одиничні несправності нижче маршрутизатора.

Іншим рішенням знадобляться перемикачі L3. Ви можете підключити порт L3 від маршрутизатора до порту L3 на кожному комутаторі. Потім підключіть вимикачі разом з портом L2 і L3. Запустіть FHRP між комутаторами, і це усуне всі одиничні збої нижче маршрутизатора без необхідності інтеграції в маршрутизатор.

Враховуючи два маршрутизатори, є деякі додаткові можливості, які можуть усунути маршрутизатор як єдину точку відмови.