Мой вопрос касается базы данных, Linux и сети. У меня есть задержка в сети и проблемы, вероятно, из-за проблемы с транкингом и объединением, когда я пытаюсь добавить еще 2 узла данных.
Оба коммутатора на 48 портов соединены между собой двухпортовой магистралью LACP (оптоволокно).
У меня есть кластер Mysql NDB с двумя узлами данных (data1, data2). Они подключены к 2 коммутаторам procurve 1820. На обоих коммутаторах есть магистраль из 2 портов (2x2) с объединенной балансировкой нагрузки на стороне сервера. 2 узла данных имеют 4 порта прямого соединения с командой lacp на стороне сервера.
Я попытался добавить 2 новых узла данных (data3, data4) в кластер с той же топологией, что и существующий. Однако, когда я пытаюсь заставить их присоединиться к кластеру, один узел внезапно теряет связь с менеджментом на несколько секунд, а другой теряет связь с другим узлом данных. Я безопасно удалил новые узлы данных, чтобы кластер мог продолжать работать правильно.
1) Должен ли я заменить 4 порта (на стороне сервера) на 2 порта x2 (на стороне коммутатора) на 2 команды lacp из 2 с общей командой балансировки нагрузки?
например
sw1 = lacp из 2 => team1 lacp -> балансировка нагрузки team3
sw2 = lacp of 2 => team2 lacp -> team3 loadbalancing
2) Если я создам только 1 магистраль из 4 на одном коммутаторе, я полагаю, что коммутатор и команда не будут запутаны, как сейчас, но я теряю преимущество HA, если коммутатор умирает. Как вы думаете, лучше иметь data1 и data3 на коммутаторе 1 (каждая 4-портовая магистраль) и data2 и data4 на коммутаторе 2. Или иметь data1 и data2 на SW1 и data3 & data4 на SW2? Принимая во внимание риск расщепления мозга.
Поскольку между ними есть прямая магистраль lacp, я полагаю, что 1 и 2 и 3 и 4 все еще могут обмениваться статусом, даже если один коммутатор не работает, но я не уверен.
NB: Я купил 2 бывших в употреблении стекируемых коммутатора 2920 HP для тестирования магистрали стека, но замена пары коммутаторов в производстве, безусловно, потребует времени и тестирования, поэтому я предпочитаю заранее найти срочное решение (и не торопиться с новым исследованием коммутации).