Хорошо, для всех, кто заинтересован,
Мы решили проблему в вопросе пару месяцев назад, просто установив напрямую подключенные SSD-диски на каждый из 3 серверов и переместив данные базы данных и файлы журналов из SAN на эти SSD-диски.
Вот краткое изложение того, что я сделал, чтобы исследовать эту проблему (используя рекомендации из всех публикаций этого вопроса), прежде чем мы решили установить SSD-накопители:
1) начал сбор счетчиков PerfMon для следующих дисков на всех 3 серверах:
Disk F:
логический диск на основе SAN, содержит файлы данных MDF
Disk I:
логический диск на основе SAN, содержит файлы журнала LDF
Disk T:
; напрямую подключается SSD, выделенный исключительно для tempDB
На рисунке ниже приведены средние значения, собранные за 2 недели
Disk I: (LDF)
имеет такой маленький ввод-вывод, и задержка очень мала, поэтому диск I: можно игнорировать.
Вы можете видеть, что Disk T: (TempDB)
ввод-вывод больше, чемDisk F: (MDF)
, и в то же время имеет намного лучшую задержку - 0 мс
Очевидно, что-то не так с диском F: где находятся файлы данных, он имеет высокую задержку и Avg Disk Write Queue, несмотря на низкий IO
2) Проверено время задержки для отдельных баз данных, используя запрос с этого сайта
https://www.brentozar.com/blitz/slow-storage-reads-writes/
Немногие активные базы данных на основном сервере имели задержку чтения 150-250 мс и задержку записи 150-450 мс.
Что интересно, файлы баз данных master и msdb имели задержку чтения до 90 мс, что подозрительно, учитывая небольшой размер их данных и низкий уровень ввода-вывода - еще один признак того, что что-то не так с SAN
3) Не было конкретных сроков
Во время которых появлялись сообщения «SQL Server обнаружил ...».
Когда эти сообщения были зарегистрированы, не было никакого обслуживания или тяжелого ETL на диске.
4) Windows Event Viewer
Не отображались никакие другие записи, которые бы указывали на проблему, кроме «SQL Server обнаружил вхождения ...»
5) Началась проверка топ-10 запросов
От sp_BlitzCache (cpu, reads и т. Д.) И omptimizing, где это возможно.
Никаких тяжелых IO-запросов, которые могли бы сжать тонны данных и сильно повлиять на хранилище, хотя
индексирование в базах данных в порядке, я поддерживаю его
6) У нас нет команды SAN
У нас есть только 1 системный администратор, который помогает в некоторых случаях
Сетевой путь к SAN - он является многопоточным, у каждого из 3 серверов есть 2 сетевых кабеля, ведущих к коммутаторам, а затем к SAN, и он должен составлять 1 гигабайт / сек.
7) не было результатов CrystalDiskMark
Или любые другие результаты тестов производительности, когда серверы были настроены, поэтому я не знаю, какими должны быть скорости , и на данный момент невозможно провести тестирование, чтобы увидеть, какие скорости в настоящее время, так как это повлияло бы на производство.
8) Настройте сеанс расширенных событий на событие контрольной точки для рассматриваемой базы данных
Сессия XE помогла обнаружить, что во время сообщений «SQL Server обнаружил события ...» контрольная точка происходила очень медленно (до 90 секунд)
9) Журнал ошибок SQL Server
Содержит записи FlushCache «Saturation».
Они должны отображаться, когда время контрольной точки для данной базы данных превышает настройки интервала восстановления.
Детали показали, что объем данных, которые пытается очистить контрольная точка, невелик и занимает много времени, а общая скорость составляет около 0,25 МБ / с ... странно
10) Наконец, на этом рисунке показана диаграмма устранения неполадок хранилища:
Кажется, у нас просто есть «Аппаратная проблема: - Работайте с системным администратором / поставщиком оборудования, чтобы исправить любую неправильную конфигурацию SAN, старых / неисправных драйверов, контроллеров, прошивки и т. Д.»
В другом вопросе «Медленная контрольная точка ...» Медленная контрольная точка и 15-секундные предупреждения ввода-вывода на флэш-накопителе У
Шона был очень хороший список того, какие элементы необходимо проверять на аппаратном и программном уровне для устранения неполадок.
Наш системный администратор не смог проверить все вещи из списка, поэтому мы просто решили добавить некоторые аппаратные средства в этом вопросе - это было совсем не дорого
Разрешение:
Мы заказали SSD-накопители емкостью 1 ТБ и установили их непосредственно на серверы.
Поскольку у нас есть группы доступности, перенесены файлы данных БД из SAN в SSD на вторичных репликах, затем выполнен отказоустойчивый и перенесены файлы на прежние первичные. Это позволило за минимальное общее время простоя - менее 1 минуты
Теперь у каждого сервера есть локальная копия данных БД, и полное резервное копирование / diff / log выполняется в упомянутую SAN.
Больше нет сообщений «SQL Server встретился с возникновением ...» в журналах средства просмотра событий Windows, а также выполняются операции резервного копирования, проверки целостности, индекс перестроен, запросы и т. д. значительно увеличилась
Насколько улучшилась производительность с точки зрения задержки ввода-вывода после того, как мы перенесли файлы БД на SSD?
Чтобы оценить влияние, использовалась производительность. Системный журнал Windows Performance Monitor регистрирует за 2 недели до миграции и через 4 недели после миграции:
Также ниже приведено сравнение статистики задержек на уровне БД (используется статистика захваченных виртуальных файлов SQL Server до и после миграции)
Резюме
Миграция с SAN на напрямую подключенные локальные SSD того стоила
Она оказала большое влияние на задержку хранилища и улучшилась в среднем более чем на 90% (особенно операции WRITE), и у нас больше нет 20-50-секундных пиков при вводе-выводе
Переход на локальный SSD решил не только проблемы с производительностью хранилища, но и безопасность данных, о которой я беспокоился (в случае сбоя SAN все 3 сервера теряют свои данные одновременно)