Статья предназначена для администраторов баз данных и хранилищ. Подразумевается, что она облегчит понимание особенностей размещения файлов данных и журналов SQL Server в сетях SAN.
Блочная нагрузка SQL Server
Большим базам данных характерна высокая нагрузка ввода-вывода. При этом сервер баз данных оперирует распределениями страниц по 8 Кб, группами по 8 страниц – экстентами по 64Кб и блоками страниц большего размера. Ниже представлена таблица, в которой указано, какие блоки могут повстречаться в нагрузке:
Характер нагрузки | Доступ: случайный / последовательный | Преобладает: чтение / запись | Размер запроса ввода-вывода |
Журнал транзакций OLTP системы | последовательный | запись | 512 Б – 4 КБ – 64 КБ |
Файлы данных OLTP системы | случайный | чтение - запись | 8 КБ |
Массовая вставка | последовательный | запись | от 8 КБ до 256 КБ |
Упреждающее чтение, просмотр индекса | последовательный | чтение | от 8 КБ до 256 КБ |
Резервное копирование | последовательный | чтение / запись | 1 МБ |
Восстановление из копии | последовательный | чтение / запись | 64 КБ |
CREATE DATABASE | последовательный | запись | 512 КБ |
Упреждающее чтение ColumnStore | последовательный | чтение | 8 МБ |
Инициализация файлов | последовательный | запись | 8 МБ |
In-Memory OLTP Checkpoint | последовательный | запись | 1 МБ |
CHECKDB | последовательный | чтение | 8 КБ - 64 КБ |
DBREINDEX | последовательный | чтение / запись | чтение: от 8 КБ до 256 КБ запись: от 8 КБ до 128 КБ |
SHOWCONTIG | последовательный | чтение | 8 КБ - 64 КБ |
Таблица 1. Характеристики для основных типов нагрузки ввода – вывода SQL Server
Как видно из таблицы, размер блока (запроса ввода-вывода) весьма разнится. Для СУБД важно, чтобы запросы таких размеров имели как можно меньшую задержку. Эта задача не является простой для Систем Хранения Данных – СХД. Практика показывает, что СХД разных вендоров по-разному справляются с этой задачей. Ниже представлен график задержек записи (которые наиболее критичны для журналов транзакций баз данных) нескольких современных AllFlash СХД. Результаты получены при тестировании по методике, которая описана тут: Методика тестирования дисковой подсистемы. Вместо утилиты SQLIO использовалась DiskSpd.
Рисунок 1.
Поскольку результаты у некоторых AllFlash СХД отличаются в три раза, выбор СХД во многом определяет пределы производительности вашего приложения баз данных.
Результаты тестирования для современных AllFlash СХД показаны тут неслучайно. Уже давно не секрет, что использование жёстких дисков для размещения файлов больших баз данных обходится дороже СХД с SSD дисками. Подробности этого факта вам с удовольствием расскажет любой поставщик СХД.
Но мало выбрать наиболее подходящую для вашей нагрузки и ваших задач СХД. Есть ещё и особенности конфигурирования СХД под блочную нагрузку с низкими задержками. Если говорить кратко, то потребуется отключить все функции, которые увеличивают задержки. Это как раз то, что в общих случаях (например, для файловых «помоек») оказывается чрезвычайно полезно и выгодно. Однако, для многих AllFlash СХД сделать это бывает нелегко, а порою и невозможно. Дело в том, что уже сейчас на рынке можно найти гибридные системы, у которых нет жёстких дисков, но есть SSD с разными параметрами производительности. Алгоритмы, применяемые для повышения производительности традиционных гибридных СХД точно так же хорошо работают при оптимизации обслуживания нагрузки за счёт «буферизации» операции на более производительных и обладающих меньшими значениями латентности SSD.
Одной из «модных» нынче тенденций является максимальное упрощение интерфейсов администрирования СХД. Они становятся интуитивно-понятными, простыми в освоении и не перегружены функциями. «Тонкие» настройки, в лучшем случае, оставляют для утилит командной строки или производитель делает их недоступными администратору. Выбирая AllFlash СХД, стоит обращать на этот аспект особое внимание, поскольку возможность отключения ненужных для баз данных слоёв логики СХД позволяет достичь необходимых параметров производительности с меньшими финансовыми затратами.
Ниже вы увидите пример конфигурирования AllFlash СХД, целью которого является показать один из возможных вариантов сайзинга без лишних затрат. Подобные возможности предоставляют многие вендоры, что позволяет получить хорошие показатели по задержкам и производительности оставаясь при этом в рамках бюджета AllFlash СХД средней ценовой категории.
САЙЗИНГ
Давайте рассмотрим на примере, как может выглядеть обустройство массивов в сети SAN для размещения на них файлов баз данных. Для демонстрации будут использованы скриншоты, снятые с СХД среднего ценового класса FUJITSU ETERNUS DX200. Операции, которые будут описаны ниже, очень похожи на операции во многих СХД других вендоров. Есть несколько базовых принципов, которых придерживаются все производители дисковых систем ввода-вывода, поэтому используя представленную ниже демонстрацию можно по аналогии создавать и подключать массивы дисков СХД практически любых из встречающихся на рынке.
Современные СХД используют сравнительно небольшой набор интерфейсов, с помощью которых осуществляется подключение к ним компьютера. В примере используется оптический интерфейс Fiber Chanel (FC). Инициатором подключения выступает компьютер, в котором для поддержания необходимого интерфейса устанавливаются оптические адаптеры. Адаптеров может быть несколько, каждый может иметь несколько оптических портов. Для адаптера необходимо установить соответствующие драйвера операционной системы. Если портов несколько, может потребоваться обеспечить поддержку в операционной системе доступ к целевым устройствам посредством нескольких путей. Для этого могут задействоваться специализированные или входящие в состав операционной системы драйвера MPIO. Компьютер инициатор может подключаться напрямую к СХД или через оптические коммутаторы. Иногда для успешности таких подключений требуется настраивать вид арбитража протокола подключения.
Оптический коммутатор переадресует запросы ввода-вывода и данные между портами, к которым подключены компьютеры-инициаторы и целевые СХД. В целях обеспечения безопасности подключений, для изоляции трафика и сокрытия портов в оптических коммутаторах могут использоваться зоны. Добавление новых портов требует внесения изменений в состав зон, что не всегда возможно делать без перерыва в передаче данных.
СХД состоит из дисковых «корзин» и контроллеров. Набор возможностей взаимодействия дисков и контроллеров СХД определяет как цену, так и степень доступности и готовности СХД по отношению к инициатору. СХД среднего класса представляют собой отказоустойчивый кластер на основании двух контроллеров. Контроллеры в кластере могут быть одновременно активны для обслуживания запросов инициатора, и «подхватывать на лету» нагрузку другого контроллера в случае отказа, за счёт «зеркалирования» кэша соседа. Такая архитектура СХД позволяет достигать уровень доступности в четыре девятки.
Основная цель настройки СХД это: регистрация компьютеров инициаторов; регистрация используемых портов контроллеров СХД; создание дисковых массивов и последующая привязка «нарезанных» на этих массивах LUN через порты СХД к портам инициаторов. Если всё сделано правильно, привязанные таким образом LUN будут доступны для создания на их основе логических дисков операционной системы.
Для привязки используются специальные глобально уникальные идентификаторы WWN. WWN есть у портов HBA, и у портов контроллеров. Часто, WWN для оптических подключений «зашит» в специальный модуль – переходник, т.н. SFP-коннектор. В таких случаях важно не забывать, что при смене SFP изменится и WWN порта. Это означает, что потребуется внести соответствующие изменения в конфигурацию привязки инициатора на СХД, а если используются зоны в оптическом коммутаторе, то нужно изменять и их, поскольку зоны тоже настраиваются с использованием WWN.
Используемая для демонстрации СХД имела два контроллера. В каждом было доступно по два порта FC. На Рисунке 2 показан статус адаптера одного из контроллеров, в котором установлены два оптических SFP модуля 16Гбит.
Рисунок 2.
На Рисунке 3 показан интерфейс СХД, в котором осуществляется регистрация WWN компьютера-инициатора. Обычно, пользователю показывается список всех WWN, которые видны через подключение и можно выбрать те из них, которые относятся к нужному инициатору. В данном случае выбраны четыре порта компьютера-инициатора, которые для удобства работы объединены в одну группу хостов с именем SERVER.
Рисунок 3.
На Рисунке 4 показан интерфейс настройки типа подключения
СХД, в данном случае всем портам был установлен тип подключения – Fabric. Те порты, которые планируется использовать для взаимодействия с группой хостов SERVER, для удобства тоже объединяются в логическую группу портов.
Рисунок 4.
Далее можно приступать к созданию дискового массива. На Рисунке 5. Показан экран конфигурации массива RAID5 из шести дисков с размером страйпа 256Кб. Также, на скриншоте видно, что крайний справа диск уже отмечен как используемый. Этот диск был заведомо выбран в качестве диска горячей подмены. Обычно недорогие СХД позволяют выбирать между настройкой массивов, либо пулов. Если нет необходимости в пулах, стоит выбрать массивы, поскольку у них бывает меньше издержек.
В статье Методика тестирования дисковой подсистемы подробно рассказывалось о том, как выбрать оптимальное для вашей нагрузки сервера баз данных число дисков в массиве, и число таких массивов для размещения файлов данных и журналов. В примере используются жёсткие диски, для которых условием хорошей масштабируемости обслуживания нагрузки больших баз данных является несколько одинаковых массивов. На каждом из таких массивов размещается один файл данных или журнала. Файлы данных делаются одинакового размера с одинаковым приращением.
Также, мы опираемся на тот факт, что производительность RAID5 по записи блоков, характерных для нагрузок SQL Server, при использовании шести дисков в массиве, не хуже чем у RAID10 на том же числе дисков.
Ещё одно правило, к которому лучше прислушаться - это число массивов, которое для удобства администрирования, не стоит доводить до числа, которое превышает число букв в алфавите. Современные СХД позволяют добавлять диски в массивы и этим обеспечить увеличение их объёма. Если же возможности добавления дисков на одной СХД исчерпаны, то всегда можно воспользоваться средствами операционной системы, создав «зеркало» с массивом другой СХД, и после завершения синхронизации зеркала, исключить из зеркала старый массив, место для которого исчерпано. Эту операцию можно проводить без остановки SQL Server и с незначительным воздействием на работу пользователей.
Впрочем, все эти рекомендации были важны для жёстких дисков. Если в СХД все диски SSD, в большинстве применений будет вполне достаточно двух массивов (если «полка» одна, то по половине дисков), только для того, чтобы были задействованы оба контроллера. Необходимость в диске горячей подмены тоже становится неочевидной, поскольку SSD диски с равномерной нагрузкой исчерпают свой ресурс «жизни» практически одновременно, и одним диском ничего не поправить. Потеря же одного диска в массиве из 12-ти SSD дисков не будет столь заметна, как для жёстких дисков. Если неисправный диск заменят в течение нескольких часов – это может быть достаточно безопасно. Примерно также поступают с «планками» оперативной памяти, не часто встретишь зеркалирование «планок» для защиты от отказа.
Рисунок 5.
После создания массива на их основе создаются тома. Из соображений простоты администрирования и мониторинга, лучше создавать том размером в весь массив и с тем же именем (некое подобие само-документирования). Потом это же имя стоит использовать при именовании разделов диска в операционной системе. Такое сквозное именование позволит легко отследить, на что повлияют проблемы с массивом.
На Рисунке 6 показано окно конфигурации нового тома DATA01, который создаётся на всём объёме массива DATA01. У данной СХД возможно на одном массиве создавать до 128 томов, но тут создаётся только один. Тут же можно изменить тип распределения страйпов и другие редко используемые для нагрузки баз данных параметры.
Рисунок 6.
Подключаемые к компьютеру-инициатору тома обязательно объединяются в группу, как это показано на Рисунке 7.
Рисунок 7.
После того как сформированы серверная группа, группа портов и группа томов, нам нужно объединить их в специальную сущность, которая в этой СХД именуется «Host Affinity».
На Рисунке 8 показан экран создания «Host Affinity», где серверная группа SERVER связана с группой портов PRTGROUP и группой томов LUNGroup. Только после того, как будет успешно создана «Host Affinity» входящие в привязанную группу LUNGroup тома будут доступны серверу из группы SERVER по путям доступа ввода-вывода, которые проходят через порты из группы PRTGROUP.
Рисунок 8.
На сервере, в диспетчере дисков останется только настроить разделы для ставших доступными LUN. Размер блока рекомендуется указывать максимальным, на сегодняшний день это 64К. Привычней использовать для обозначения дисков буквы, но большую гибкость позволяют достичь точки монтирования, привязанные к папкам операционной системы. Например, можно создать такую структуру папок: D:\MSSQL\DATA. В папке DATA потом можно создавать папки с номерами подключаемых дисков. Если добавлять созданный выше том DATA01, то путь к подмонтированному к папке 01 диску выглядел бы так: D:\MSSQL\DATA\01. Такой подход полностью отвечает нашему простому правилу само-документирования, и позволяет сопоставить диск тому, а том массиву.
Комментариев нет:
Отправить комментарий