Выигрыши в производительности добавления второй сети
все это зависит, но можно приблизительно оценить что-то с этим подходом: смотрите на iostat и посмотрите на iops/sec на своем диске. если у Вас есть типичная база данных, Вы по всей вероятности ограничены количеством случайных, ищет/секунда, не пропускная способность.
- в окне обслуживания - выполняет xtrabackup, не регулируя и видят снова, что числа iops/sec могут Ваша система генерировать. скажите, что это - x.
- после того взгляда, сколько iops/sec типичен для системы в течение часов неполной нагрузки. скажите, что это - y.
на основе этого делают некоторую оценку, сколько iops/sec может Вы выделять заданию резервного копирования. я вычислил бы его как x - 2 * y или x - 3 * y для оставления некоторой высоты для скачков.
я думаю, что параметр xtrabackup будет линейно пропорционален iops/sec, но не равен - так по последнему методу проб и ошибок использования шага для настройки значения дросселя, таким образом, iostat покажет желание количества операций/секунда.
использование alternativly ионизирует [немного об этом здесь], дает Ваш низкий приоритет задания резервного копирования и не регулирует его вообще. я делаю, это для rdiff-заданий-резервного-копирования - работает вполне приятно. обратите внимание, что ионизируют [afaik] работы только с некоторыми io планировщиками в Linux.
Выполнение отдельной параллельной сети является почти определенно не лучшим способом заняться этим. Это - довольно мало работы и обслуживания, и, вероятно, не решит Вашу проблему. Следует иметь в виду, что это автоматически не сбалансирует трафик по обеим из Ваших сетей. Так, например, если все клиенты будут использовать вторую сеть для совместного доступа к файлам, то это будет насыщаться, и списки каталогов все еще будут медленными. Ваша первая сеть могла бы все еще быть быстрой, но никто не будет использовать ее для совместного доступа к файлам.
Это - то, что я попробовал бы:
- Измерьте сетевую пропускную способность на файловом сервере. Если это - близкие 80% теоретической проводной скорости, то Вам нужно более быстрое сетевое соединение. Можно использовать второй порт Ethernet на файловом сервере и связать два в один сетевой интерфейс с дважды способностью. Ваш переключатель должен поддерживать это, и существуют некоторые ограничения к тому, как та дополнительная способность на самом деле привыкнет на практике.
- Если сетевая пропускная способность не будет очень высока, то посмотрите на другие факторы файлового сервера, чтобы видеть, являются ли они узким местом, таким как ЦП (вряд ли) или RAM (то больше позволит этому кэшироваться больше).
- Наиболее вероятная причина состоит в том, что диски не работают достаточно быстро. Вы могли изучить лучшую систему RAID, использовать кластерную файловую систему или просто черепок Ваши данные в несколько файловых серверов. Как Вы делаете это очень зависит от Ваших приложений и среды ОС.
Если бы Ваша поддержка коммутаторов SNMP, я не торопился бы для установки Zenoss или чего-то подобного. Это изобразит использование в виде графика на каждом порте, который значительно улучшит Вашу способность точно определить узкое место. Это может также изобразить жизненную статистику в виде графика Ваших машин клиента и сервера.
-
1+1, весь очень разумный совет – James 24 September 2009 в 01:27
Если Вашей проблемой будет конкуренция сетевого устройства, то перемещение передач в другую подсеть поможет. Необходимо будет стараться удостовериться, чтобы передачи отодвинулись вторая сеть а не первое.
Однако, при попытке сделать списки каталогов на серверах, вовлеченных в передачи тех больших файлов, Ваши проблемы могли бы состоять в том, потому что диски на включенных компьютерах слишком заняты для продвижения запросов в быстро. В этом случае дополнительная пропускная способность сети на сервере не поможет.
-
1I' d добавляют, что, если существует какое-либо программное обеспечение AV, сканируя файлы на сервере, поскольку они передаются, это добавит к проблеме горлышка бутылки диска. – John Gardeniers 23 September 2009 в 02:19
Необходимо измерить текущую сеть и использование сервера. Без фактических данных по использованию Ваших существующих ресурсов невозможно сказать окончательно, существует ли проблема производительности и если использование второго NICs было бы полезно.
Другая опция может состоять в том, чтобы сегментировать сеть. Включите половину клиентов и одного сервера на один переключатель и включите переключатели вместе. Магистральные порты между наиболее используемыми клиентами/серверами могут также быть возможностью (хотя не, если оба переключателя неуправляемы).
Доступ к диску на самих файловых серверах мог быть узким местом. Если файлы будут скопированы/к от них, то добавление дополнительной пропускной способности сети вряд ли поможет спискам каталогов и т.д. с тех тех же серверов.
Несколько лет назад (прежде чем переключатели GigE были дешевыми) я раньше выполнял две отдельных подсети. Каждая машина имела два NICs, один для генерала и один для совместного доступа к файлам. Это звучит подобным тому, что Вы предусматриваете.
Поскольку Вы имеете запасной переключатель, даете ему попытку. Возможно, что Ваш текущий переключатель просто не может третировать данные достаточно быстро, когда некоторые порты при их максимальной передаче.
Другая идея: Вы упоминаете, что передаете между несколькими рабочими станциями/серверами. В зависимости от их физических местоположений и доступных портов, Вы могли выполнить кабели Firewire между ними и сделать передачи файлов тот путь (от того, что я помню, можно заставить его быть похожим на сетевой интерфейс на машинах). Ваши диски могут все еще быть узким местом затем, но по крайней мере Вы решили проблемы скорости сети.
Действительно сообщите, что Вы находите.
-
1
Одной вещью, которую можно сделать с отдельной подсетью (принимающий это - весь гигабит) являются крупные кадры использования для дополнительной пропускной способности. Чтобы это работало, все устройства (включая переключатель) должны поддерживать крупные кадры.
У меня есть сеть "бэкенда", настраивает этот путь; серверы и поле NAS, у каждого есть интерфейс в этой сети (набор для крупных кадров), серверы и поле NAS, говорят друг с другом по этой сети, освобождающей интерфейсы "frontend" для клиентов.
Если возможный Вы могли бы всегда устанавливать VLAN, если Ваша текущая поддержка инфраструктуры это и Вы не должно будет выполнять дополнительный сетевой кабель к каждой машине. Но поскольку David сказал выше, если это не будет сетевая проблема, то Это ничего не решит.
-
1VLAN собой won' t помогают, если проблемой является пропускная способность один. – Cian 23 September 2009 в 00:41
-
2