Прямий ефірний зв'язок між двома серверами

13

Скажімо, у мене були два сервери, яким потрібна наднизька затримка (база даних, файл тощо). Чи можна було б безпосередньо з'єднати два сервери з 10GbE, тож кожен сервер мав 1 (у реальному світі це було б 2) підключення до «головної» мережі, але 1 мережеву карту з мережевим кабелем, який підключався безпосередньо до другого сервер, без комутаторів або маршрутизаторів, просто пряме з'єднання

                         Internet/Datacenter
                                 |
                                 |
                                 |
                                 |
                                 |
                                 |
                                 |
                        --------------------
                        |                  |
            ------------|      Switch      |-----------
            |           |                  |          |
            |           --------------------          |
            |                                         |
            |                                         |
            |                                         |
            |                                         |
            |                                         |
            |                                         |
            |                                         |
  Network Card 1 (eth0)                     Network Card 1 (eth0)
            |                                         |
  --------------------                      --------------------
  |                  |                      |                  |
  |     Server 1     |                      |     Server 2     |
  |                  |                      |                  |
  --------------------                      --------------------
            |                                         |
  Network Card 2 (eth1)                     Network Card 2 (eth1)
            |                                         |
            |                                         |
            |               Direct 10GbE              |
            -------------------------------------------

Перше моє запитання: чи це можливо було б можливо? Чи потрібні їм якісь незвичайні / спеціальні сервіси, налаштовані на те, щоб вони могли розмовляти через цю мережу, крім стандартного файлу /etc/sysconfig/network-scripts/? Вони обидва мають статичні IP-адреси на eth1, але як би діяти такі маршрути? Я не фахівець з питань мереж, тому це, мабуть, питання n00b-ish

Друге питання, чи є якийсь момент? Чи були б якісь переваги для цього через просто дозволити їм спілкуватися через стандартне мережеве з'єднання через комутатор або надавати їм другу виділену мережу лише для спілкування внутрішньосерверного сервісу (Оскільки пропускну здатність буде використовуватися в стандартній мережі клієнтами, які отримують доступ до серверів) . Припущення про затримку було пріоритетним.

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

А оскільки затримка є ключовою проблемою, чи буде волокно краще за Ethernet (швидкість не важлива, доки вона може робити пару Гбіт / с)

Я поставив це запитання з Linux POV, тому що це мій фон, але він може стосуватися будь-якого сервера / пристрою

networking ethernet fiber

— Мазати
джерело

1

В якості бічної записки вам слід використовувати UDP, а не TCP, щоб отримати затримку за рахунок втрати гарантії доставки. Залежно від розміру ваших пакетів, jumbo кадри можуть також допомогти, обмеживши кількість пакетів.

— Шадок

@Shadok UDP не ідеально підходить для серверів баз даних, файлових серверів тощо, але для моніторингу, ведення журналів та інших некритичних речей UDP є набагато кращим варіантом, який я погоджуюсь. Я думаю, що будь-яка налаштування мережі, як це, швидше за все, вимагає гарантованої доставки, але пакети UDP через основну мережу мають багато застосувань.

— Мазок

Гаразд, я мав враження, що затримка - це ваша головна проблема, і я вважаю, що, можливо, ви зможете перевірити цілісність або підтвердити доставку пакетів іншим способом, ніж TCP. Однією з ідей у мене була б реалізовувати простий лічильник, що збільшується в кожному пакеті, а потім знову вимагати відсутніх або просто відкинути їх, але я відступаю :)

— Shadok

@Shadok - Якщо вам вдалося встановити з'єднання UDP до бази даних, це може призвести до непередбачуваної поведінки та корупції. Крім того, ви в основному будете перетворювати UDP в TCP шляхом послідовної послідовності пакетів та запиту відсутніх. Ось для чого і TCP. Краще буде відгодовувати Ethernet до 100 г або використовувати з'єднання з волокнами

— гліф

9

Немає причин, чому ви технічно цього не можете зробити.

Я, мабуть, зробив щось подібне, за обставин, насправді. З чисто linux точки зору, це дуже просто, просто надайте з'єднанню IP-адресу з / 30 бітовою маскою, даючи вам 2 IP-адреси, то це просте посилання "точка-точка".

Якщо ви хочете розробити мережу, ви можете отримати комутатор 10GE, а потім мати окрему VLAN для руху між серверами. У діапазоні вимикачів Force10 є дуже блискуча передача, яка може робити лінійну швидкість 10GE, з величезними буферами.

— Том О'Коннор
джерело

5

Я не можу коментувати точку зору Linux, але я просто використаю свої знання та задаю ще кілька питань.

Ви залежні від низької затримки і вам потрібно підтримувати ці сервери в синхронізації? Вони обидва працюють з базою даних або щось таке? 10GbE повинно вистачити більшості потреб 2 серверів, щоб підтримувати їх у синхронізації. Я швидше скоріше витрачую гроші на гідний перемикач посередині 2, а не на маршрут, який ви шукаєте.

Ви можете з гідним тегом переключити ці порти, щоб визначити пріоритетність трафіку та навіть QoS трафіку, який потребує реального часу.

Мої думки.

— Запто
джерело

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

— Мазок

QoS на комутаторі дуже залежить від постачальника, деякі підтримують його, деякі підтримують його дуже власно, деякі підтримують його відповідно до RFC, але вам, мабуть, доведеться мати його на всіх пристроях у мережі, щоб бачити будь-який гідний ефект.

— Tom O'Connor

+1, тому що багато комутаторів працюють на тому, що по суті є провідним. Правильно налаштована мережа буде вигідною у безлічі способів, про які вже говорилося, а також допоможе знайти помилки.

— День

5

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

Встановіть статичні IP-адреси, які не в такому ж діапазоні, як будь-яка інша підмережа, яку ви використовуєте - наприклад, якщо мої системи перебувають у підмережі 192.168.xx, я використовую між ними підмережу 10.0.0.x. В іншому випадку він повинен просто працювати

— Подорожник Geek
джерело

2

Немає переваги в застосуванні таких налаштувань. Сьогодні вимикачі швидко світяться, тому ви ніколи не стикаєтесь із видимими затримками через перемикач. і масштабованість буде великим питанням і для вас. Також може виникнути проблема налаштування маршрутизації, оскільки вам доведеться підтримувати ДВА Окремих мереж замість однієї.

— Фархан
джерело

2

Перевага в моїй ситуації полягала в тому, що пряме з'єднання усувало необхідність використання шифрування SSL для підключення до бази даних, оскільки це відбувається через приватний провід, а не напівприватний комутатор, де можна було б обнюхати паролі.

— гліф

2

Я впевнений, що вам потрібно буде перехрестити кабель для підключення сервера 1 до сервера 2.
У вас буде дуже низька затримка, але затримка в локальній мережі з сучасними комутаторами приблизно наближається до нуля, як ви можете отримати. Я щиро сумніваюся, що ви побачите будь-який вимірюваний приріст продуктивності.

— SBWorks
джерело

10

Gb і 10Gb роблять auto-MDIX, тому вам не потрібен кросовер. Це лише за 10/100.

— MDMarra

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

— SBWorks

2

Безпека проти продуктивності проти грошей.

Якщо трафік зворотного каналу великий, а гроші низькі, використовуйте пряме з'єднання. Це робиться щодня і в багатьох ситуаціях реального світу може мати кращі показники роботи, ніж перевантажений перемикач.
Якщо трафік зворотного каналу низький, а захищеність середня або низька, зв’яжіть NIC для збільшення загальної пропускної здатності в Інтернеті - два з'єднання від кожного сервера до Інтернету, багатодомний NICS для "ізоляції" трафіку реплікації (Окремі IP-простори полегшують брандмауер , аудит, робити діагностику трасування пакетів тощо).
Якщо рівень безпеки і багато грошей, використовуйте перемикач. Простіше розширити. Простіше діагностувати проблеми.

У даному сценарії купівля комутатора не була б виправданою. Використання існуючого комутатора з сегментацією VLAN було б можливим. Хоча я не бачу причин підключатися до комутатора, якщо сервери не є Co-lo'd, тобто не доступні фізично. Це марно використання двох портів комутації, якщо активний захоплення / налагодження пакетів.

— Джо
джерело