Прямая сеть Ethernet между двумя серверами

13

Скажем, у меня было два сервера, которые требовали сверхнизкой задержки (база данных, файл и т. Д.). Можно ли было напрямую соединить два сервера с 10GbE, чтобы у каждого сервера было 1 (в реальном мире 2) подключения к «основной» сети, но 1 сетевая карта с кабелем Ethernet, который подключался непосредственно ко второму сервер, без коммутаторов или маршрутизаторов, просто прямое соединение

                         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

Второй вопрос, есть ли смысл? Будут ли какие-либо преимущества, если вы сделаете это, просто позволяя им общаться через стандартное сетевое соединение через коммутатор или предоставляя им вторую выделенную сеть только для связи внутри сервера (поскольку пропускная способность будет использоваться в стандартной сети клиентами, обращающимися к серверам) , Предполагая, что задержка была приоритетом.

Я знаю, что у этого метода есть некоторые проблемы, например, когда мы добавляем третий сервер, нам нужно дать каждому серверу по одной сетевой карте и, возможно, установить очень сложный треугольник репликации, но поскольку это гипотетически, давайте проигнорируем это.

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

Я сформулировал этот вопрос из Linux POV, потому что это мой опыт, но он может относиться к любому серверу / устройству

networking ethernet fiber

— мазаться
источник

1

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

— Шадок

@Shadok UDP не идеален для серверов баз данных, файловых серверов и т. Д., Но для мониторинга, ведения журналов и других некритических вещей UDP, я согласен, является гораздо лучшим вариантом. Я думаю, что любая настройка сети, подобная этой, скорее всего, потребует гарантированной доставки, но UDP-пакеты по основной сети имеют много применений.

— Пятно

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

— Шадок

@Shadok - Если вам удалось настроить UDP-соединение с базой данных, это может привести к непредсказуемому поведению и повреждению. Кроме того, вы будете в основном превращать UDP в TCP, упорядочивая пакеты и запрашивая пропущенные. Вот для чего нужен TCP. Было бы лучше, чтобы откармливать Ethernet до 100 г или использовать оптоволоконную связь

— глиф

9

Там нет причин, почему вы технически не можете сделать это.

Я бы, наверное, сделал что-то подобное, в данных обстоятельствах, на самом деле. С точки зрения чисто linux, это действительно просто, просто дайте подключению IP-адрес с битовой маской / 30, давая вам 2 IP-адреса, тогда это простая двухточечная связь.

Если вы хотите расширить сеть, вы можете получить коммутатор 10GE, а затем иметь отдельную VLAN для трафика между серверами. В линейке коммутаторов Force10 есть очень блестящая шестеренка, которая может выполнять линейную коммутацию 10GE с огромными буферами.

— Том О'Коннор
источник

5

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

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

Вы могли бы приличным переключателем пометить эти порты, чтобы расставить приоритеты трафика и даже QoS трафика, который должен быть в реальном времени.

Мои мысли.

— Zapto
источник

Предоставление им их собственного коммутатора / «частной сети» было бы намного лучшим вариантом, чем прямое соединение, поэтому, если бы нам нужно было добавить больше серверов позже, это было бы намного проще. Кроме того, предпочтение отдается трафику, я даже не осознавал, что вы можете это сделать, зависит ли это от характеристик / производителя коммутатора или это довольно стандартная вещь?

— Пятно

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

— Том О'Коннор

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

— Дан

5

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

Установите статические IP-адреса, которые не находятся в том же диапазоне, что и любая другая подсеть, которую вы используете - например, если мои системы находятся в подсети 192.168.xx, я использую подсеть 10.0.0.x между ними. В противном случае, это должно просто работать

— Подмастерье
источник

2

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

— Фархан
источник

2

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

— глиф

2

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

— SBWorks
источник

10

Gb и 10Gb делают авто-MDIX, поэтому вам не нужен кроссовер. Это только на 10/100.

— MDMarra

Я думаю, что вы правы в этом, @MarkM Я не думаю, что когда-либо пробовал это в реальной жизни.

— SBWorks

2

Безопасность против производительности против денег.

Если трафик обратного канала высок, а денег мало, используйте прямое соединение. Это делается каждый день, и во многих реальных ситуациях производительность может быть выше, чем у перегруженного коммутатора.
Если трафик в обратном канале низкий, а уровень безопасности средний или низкий, подключите сетевые адаптеры для увеличения общей пропускной способности Интернета - два подключения от каждого сервера к Интернету, мульти-домашние сетевые адаптеры для «изоляции» трафика репликации (отдельные пространства IP упрощают брандмауэр , аудит, сделать диагностику трассировки пакетов и т. д.).
Если безопасность высока и много денег, используйте переключатель. Проще расширить. Проще диагностировать проблемы.

В данном сценарии покупка переключения не будет гарантирована. Использование существующего коммутатора с VLAN-сегментацией может иметь смысл. Хотя я не вижу причин для подключения к коммутатору, если серверы не совместимы, то есть физически недоступны. Это пустая трата двух портов коммутатора, если не активен захват / отладка пакетов.

— Джо
источник