Существует ли преимущество производительности для изоляции журналов транзакций базы данных и данных по различным объемам (тот же RAID-массив) через SAN?
Существует только еще одна основная причина, что я могу думать, который подобен дублированию, и это является Магистральным, таким образом, Вы могли настроить трафик для течения по 2x1Gbit порты, дав Вам 2Gbit общей пропускной способности. Некоторые называют это LaCP, Linux знает это как mode=4, как описано ниже.
Режимы связывания интерфейса Linux дают несколько других опций:
mode=0 (RR баланса) Циклическая политика
mode=1 (активно-резервная) Активно-резервная политика
mode=2 (баланс-xor) политика XOR: Передача на основе [(исходный MAC-адрес XOR'd с целевым MAC-адресом) ведомое количество по модулю].
mode=3 (широковещательно передают) Широковещательную политику: передачи все во всех ведомых интерфейсах. Этот режим обеспечивает отказоустойчивость.
mode=4 (802.3ad) агрегирование Динамического канала IEEE 802.3ad. Создает группы агрегирования, которые совместно используют ту же скорость и дуплексные настройки.
mode=5 (баланс-tlb) Адаптивное выравнивание нагрузки передачи: канал связывая, который не требует никакой специальной поддержки коммутаторов.
mode=6 (стихарь баланса) Адаптивное выравнивание нагрузки: включает баланс-tlb плюс, получают выравнивание нагрузки (rlb) для трафика IPv4, и не требует никакой специальной поддержки коммутаторов.
Putting your log file on a separate volume, even if it's on the same raid, should be better performance than having the data and logs in the same volume. Each volume can only be access through one path at a time on most storage systems. This means that your logs and data would share the same controller port, controller cache, queue depth, and FC switch resources. Any of these could become a bottleneck, and putting your logs into another volume that shares as few of them as possible would likely result in a performance increase.
That said, there is both a performance and reliability reason to have logs and data live on separate disks, assuming you're not on one of those newfangled "wide striping" machines that use all the spindles in the array simultaneously. Each time you do a database write, it's logged, and each log takes a write (on top of the actual modification).
- If you lose an entire raid (which is rare, but happens) that hosts both your logs and data, you risk real data loss unless your logs were replicated. Log shipping is not always supported with all databases.
- During normal operation, if you have your logs and data living on the same small set of spindles, you can risk throttling actual database production with disk level performance bottlenecks.
You are on a raid 50. That's generally a sign that you're striping your data across a lot more than 8 or 16 disks. If this is the case, it's also generally true that you'll set up at least two raid-50s per disk type (of which you have one). The best solution for your situation is to put your data on the fastest (ie biggest) raid you have, and your logs on the other one.
В общем, чтобы минимизировать задержку записи для требовательной базы данных, вам нужно разделить журналы и данные на разные тома в разных группах RAID, чтобы не было конфликта ресурсов между журналом и данными на время группы RAID.
Похоже, у вас уже есть диски, сконфигурированные в группы RAID, поэтому вы, вероятно, просто захотите посмотреть, как подготовить различные тома из разных групп и полок.
Это действительно зависит от бренда. Compellent SAN можно настроить на автоматическую оптимизацию чтения и записи san. HP EVA sans фактически снизит общую производительность, если вы начнете выделять шпиндели для определенных приложений. Можете ли вы выделить кеш для определенных имен во всем мире? Независимо от того, находится ли SQL в автономном режиме или в локальном хранилище, применяются одни и те же правила, поэтому, если вы знакомы с Оптимизацией ввода-вывода на сервере, вам просто нужно узнать о возможностях существующего сервера и посмотреть, как их лучше всего использовать.