ну получается какая-то слабенькая и не масштабируемая фабрика получилась, если нельзя несколько десяток трафика докинуть :)
А во время теста с ласп физические линки из бонда точно не выпадали на коммутаторе и\или со стороны сервера? lacp fast или slow? Может просто при заполнении порта дропались сообщения lacp, физический линк вылетал из бонда, потом обратно добавлялся, на усреднении вышло меньше, чем 20 гбит.
А джуниперу думаю все равно, что 10 потоков, что 100. Надо конечно попытаться понять, в обе ли стороны скорость ограничена, или в какую-то одну, тогда будет ясно, вина на стороне коммутатора или сетевухи.
а что за проблема с ласп, не пробовали разбираться? Ограничение в 16 гбит было в какую сторону, от коммутаторов к серверу или обратно, или в обе стороны, что вдвойне странно?
Да, и правильно я понял, что для кластера отдельную физическую сеть выделили? Какие-то проблемы возникли с подключением к фабрике? Выглядит как-то странновато, на 5 стоек иметь фабрику из лифов и спайнов, а потом еще некоторые кластеры выносить на дополнительные коммутаторы.
Какое-то странное решение, имея дц фабрику — выносить отдельные сервисы на свои собственные коммутаторы. Линки между лифами и спайнами же 40г? Нельзя было новых добавить? QoS никакого нет на фабрике, чтобы прод прикрыть?
Про ЛАСП все-таки интересно, в какую именно сторону ограничение было, от сервера к коммутатору или наоборот. Видимо, если тестировали между двумя серверами только, то ситуация симметричная и понять невозможно, но можно было бы еще с третьего сервера какой-нибудь трафик нагенерировать. А то непонятно, в чем проблема, со стороны коммутатора или со стороны сервера.
Еще по поводу теста, он проводился каким трафиком, юдп или тсп? Результаты приведенные — из iperf только? С загрузкой интерфейсов на коммутаторах и серверах сравнивали? Тому, что на 100 потоках результат сильно хуже, чем на 10 потоках, нашли обьяснение? В производительность сервера уперлись?
В общем насколько я понял из видео, с помощью этого тула мы можем держать всю конфигурацию сети в неком унифицированном виде. Причем вначале мы должны описать топологию каким-то образом, не показанным в примере.
Но смущает то, что эта конфигурация хранится отдельно, на некой виртуалке с CONFD, а на реальное оборудование надо раскладывать вручную. Кроме этого, еще и надо держать открытыми несколько терминальных окон, в одном вводить команды, в другом проверять, что после коммита появилось слово OK. Почему в самом CLI не показывается в случае чего, что не ОК?
С другой стороны, кроме того, что сгенерированные изменения применяются вручную, psefabric так же и не отслеживает актуальное состояние сети. Допустим, из-за ребута конфиг откатился, или из-за какого-то бага команда сохранилась в конфиге не полностью (как например было с privilege на cisco), и в интерфейсе psefabric мы этого никак не увидим.
То есть нельзя пока назвать psefabric полноценной системой управления. Скорее вспомогательный инструментарий для генерирования конфигураций по заранее описанным темплейтам. Возможно, на деле все лучше, но в видео презентации увидел именно так.
хм, как интересно, ну допустим, что стабилизируется на 2\3, а мы возьмем и верхние 1\3 обрежем, в итоге наша новая ванна все-таки заполнится до краев?
очень интересные результаты про окно бесконечности
А во время теста с ласп физические линки из бонда точно не выпадали на коммутаторе и\или со стороны сервера? lacp fast или slow? Может просто при заполнении порта дропались сообщения lacp, физический линк вылетал из бонда, потом обратно добавлялся, на усреднении вышло меньше, чем 20 гбит.
А джуниперу думаю все равно, что 10 потоков, что 100. Надо конечно попытаться понять, в обе ли стороны скорость ограничена, или в какую-то одну, тогда будет ясно, вина на стороне коммутатора или сетевухи.
а что за проблема с ласп, не пробовали разбираться? Ограничение в 16 гбит было в какую сторону, от коммутаторов к серверу или обратно, или в обе стороны, что вдвойне странно?
Да, и правильно я понял, что для кластера отдельную физическую сеть выделили? Какие-то проблемы возникли с подключением к фабрике? Выглядит как-то странновато, на 5 стоек иметь фабрику из лифов и спайнов, а потом еще некоторые кластеры выносить на дополнительные коммутаторы.
Про ЛАСП все-таки интересно, в какую именно сторону ограничение было, от сервера к коммутатору или наоборот. Видимо, если тестировали между двумя серверами только, то ситуация симметричная и понять невозможно, но можно было бы еще с третьего сервера какой-нибудь трафик нагенерировать. А то непонятно, в чем проблема, со стороны коммутатора или со стороны сервера.
Еще по поводу теста, он проводился каким трафиком, юдп или тсп? Результаты приведенные — из iperf только? С загрузкой интерфейсов на коммутаторах и серверах сравнивали? Тому, что на 100 потоках результат сильно хуже, чем на 10 потоках, нашли обьяснение? В производительность сервера уперлись?
Но смущает то, что эта конфигурация хранится отдельно, на некой виртуалке с CONFD, а на реальное оборудование надо раскладывать вручную. Кроме этого, еще и надо держать открытыми несколько терминальных окон, в одном вводить команды, в другом проверять, что после коммита появилось слово OK. Почему в самом CLI не показывается в случае чего, что не ОК?
С другой стороны, кроме того, что сгенерированные изменения применяются вручную, psefabric так же и не отслеживает актуальное состояние сети. Допустим, из-за ребута конфиг откатился, или из-за какого-то бага команда сохранилась в конфиге не полностью (как например было с privilege на cisco), и в интерфейсе psefabric мы этого никак не увидим.
То есть нельзя пока назвать psefabric полноценной системой управления. Скорее вспомогательный инструментарий для генерирования конфигураций по заранее описанным темплейтам. Возможно, на деле все лучше, но в видео презентации увидел именно так.