Журналы и диски данных имеют разные шаблоны доступа к данным, которые конфликтуют друг с другом (по крайней мере, теоретически), когда они совместно используют диск.
Журнал пишет
Доступ к журналу состоит из очень большого количества небольших последовательных записей. Несколько упрощенно, журналы БД - это кольцевые буферы, содержащие список инструкций для записи элементов данных в определенные места на диске. Шаблон доступа состоит из большого количества небольших последовательных записей, которые должны быть гарантированно завершены - поэтому они записываются на диск.
В идеале журналы должны находиться на тихом (то есть не разделенном между собой) томе RAID-1 или RAID-10. Логически вы можете рассматривать процесс как основную СУБД, записывающую записи журнала и один или несколько потоков чтения журнала, которые потребляют журналы и записывают изменения на диски данных (на практике процесс оптимизируется так, что записи данных записываются сразу по возможности). Если на дисках журнала есть другой трафик, заголовки перемещаются этими другими доступами, и последовательные записи журнала становятся случайными записями журнала. Это намного медленнее, поэтому занятые диски могут создать горячую точку, которая действует как узкое место во всей системе.
Запись данных
(обновлено) Записи журнала должны быть зафиксированы на диске (называемом стабильным носителем), чтобы транзакция была действительной и имела право на фиксацию. Логически это можно увидеть как записи в журнале, которые затем записываются, а затем используются как инструкции для записи страниц данных на диск с помощью асинхронного процесса. На практике записи на диск на самом деле подготавливаются и буферизируются в момент создания записи в журнале, но их не нужно записывать немедленно для фиксации транзакции. Дисковые буферы записываются на стабильный носитель (диск) с помощью процесса Lazy Writer (спасибо Полу Рэндалу за указание на это), который в этой статье Technet обсуждается более подробно.
Это модель произвольного доступа, поэтому совместное использование одних и тех же физических дисков с журналами может создать искусственное узкое место для производительности системы. Записи журнала должны быть записаны для фиксации транзакции, поэтому случайный поиск замедляет этот процесс (случайный ввод-вывод намного медленнее, чем последовательный ввод-вывод журнала) превратит журнал из последовательного в устройство произвольного доступа. Это создает серьезное узкое место в производительности в загруженной системе, и его следует избегать. То же самое относится и к совместному использованию временных областей с томами журнала.
Роль кеширования
Контроллеры SAN, как правило, имеют большие кэш-памяти ОЗУ, которые могут в определенной степени поглощать трафик произвольного доступа. Однако для обеспечения целостности транзакций желательно иметь запись на диск из СУБД, гарантированно завершенную. Когда контроллер настроен на использование кэширования с обратной записью, грязные блоки кэшируются, и вызов ввода-вывода сообщается хосту как завершенный.
Это может сгладить множество проблем с конкуренцией, поскольку кэш-память может поглощать много операций ввода-вывода, которые в противном случае выходили бы на физический диск. Он также может оптимизировать чтение и запись по четности для RAID-5, что уменьшает влияние на производительность томов RAID-5.
Вот те характеристики, которыми руководствуется школа мысли «Пусть SAN справится с этим», хотя эта точка зрения имеет некоторые ограничения:
Кэширование с обратной записью все еще имеет режимы сбоя, которые могут привести к потере данных, и контроллер подключился к СУБД, заявив, что блоки записаны на диск, а на самом деле их нет. По этой причине вы, возможно, не захотите использовать кэширование с обратной записью для транзакционного приложения, особенно для хранения критически важных или финансовых данных, где проблемы с целостностью данных могут иметь серьезные последствия для бизнеса.
SQL Server (в частности) использует ввод-вывод в режиме, когда флаг (называемый FUA или принудительный доступ с обновлением) принудительно выполняет физическую запись на диск до возврата вызова. У Microsoft есть программа сертификации, и многие поставщики SAN производят оборудование, которое соответствует этой семантике (требования приведены здесь ). В этом случае никакое количество кеша не оптимизирует запись на диск, что означает, что трафик журнала будет зависать, если он находится на занятом общем томе.
Если приложение генерирует много дискового трафика, его рабочий набор может переполнить кэш, что также вызовет проблемы с конфликтами при записи.
Если SAN используется совместно с другими приложениями (особенно на том же диске), трафик из других приложений может создавать узкие места в журнале.
Некоторые приложения (например, хранилища данных) генерируют большие скачки переходной нагрузки, что делает их довольно антисоциальными в сетях SAN.
Даже в больших SAN отдельные тома журналов все еще рекомендуются. Вы можете сойти с рук, не беспокоясь о макете в слабо используемом приложении. В действительно больших приложениях вы можете даже получить выгоду от нескольких контроллеров SAN. Oracle публикует серию тематических исследований по макету хранилища данных, где в некоторых из более крупных конфигураций используются несколько контроллеров.
Возложите ответственность за производительность там, где она принадлежит
На объектах с большими объемами или где производительность может быть проблемой, сделайте команду SAN ответственной за производительность приложения. Если они собираются игнорировать ваши рекомендации по настройке, убедитесь, что руководство осведомлено об этом и что ответственность за производительность системы лежит в соответствующем месте. В частности, установите приемлемые руководящие принципы для ключевой статистики производительности БД, такой как ожидания ввода-вывода или ожидания защелки страниц или приемлемые SLA приложений-ввода-вывода.
Обратите внимание, что ответственность за распределение производительности между несколькими командами создает стимул для того, чтобы уточнить и передать ответственность другой команде. Это известный анти-паттерн управления и формула для проблем, которые тянутся месяцами или годами, так и не решаясь. В идеале должен быть единый архитектор с полномочиями определять изменения приложения, базы данных и конфигурации SAN.
Также проведите тестирование системы под нагрузкой. Если вы можете это организовать, то на Ebay можно купить недорогие серверы и массивы прямого подключения на Ebay. Если вы настроите такую коробку с одним или двумя дисковыми массивами, вы сможете изменить конфигурацию физического диска и измерить влияние на производительность.
В качестве примера я провел сравнение между приложением, работающим в большой сети SAN (IBM Shark), и коробкой с двумя сокетами с массивом U320 с прямым подключением. В этом случае оборудование стоимостью 3000 фунтов стерлингов, приобретенное у ebay, превзошло высокопроизводительную сеть хранения данных стоимостью 1 млн фунтов стерлингов в два раза - на хосте с примерно эквивалентной конфигурацией процессора и памяти.
В связи с этим конкретным инцидентом можно утверждать, что подобные вещи - очень хороший способ сохранить честность администраторов SAN.