Выравнивание секторов диска по границе 1024 КБ и форматирование с размером блока 64 КБ
Обновлено: 21.11.2024
Производительность SQL Server зависит от доступных ресурсов сервера, и производительность диска, вероятно, является наиболее важным ресурсом. Чтобы максимизировать производительность диска для SQL Server, мне всегда говорили, что смещение раздела диска должно быть установлено на 32 КБ, а размер единицы выделения должен быть установлен на 64 КБ для разделов, содержащих данные, и 8 КБ для разделов, содержащих журналы. Как узнать размер единицы размещения и смещение раздела для моих дисков?
Решение
То, как подготовлен диск, влияет на производительность. Это относится и к напрямую подключенному хранилищу, и к хранилищу SAN. Причина в том, что физические операции ввода-вывода SQL Server выполняются в единицах экстентов по 64 КБ или страниц по 8 КБ. Эти запросы ввода-вывода проходят через различные подсистемы ввода-вывода и должны быть преобразованы в физические операции с дисками или наборами дисков. Количество фактических физических операций ввода-вывода, необходимых для выполнения запроса SQL Server, может варьироваться в зависимости от того, как подготовлен диск.
Windows не всегда помогала. До Windows 2008 диски были разбиты на разделы и выровнены по умолчанию, чтобы использовать каждый возможный байт, пережиток 1980-х и 90-х годов. До недавнего времени большинство дисков имели физические сектора размером 512 байт. Основная загрузочная запись Windows (MBR) занимает шестьдесят три из этих 512-байтовых секторов с начала диска. Windows начинает с создания разделов в следующем секторе, 31,5 КБ от начала диска. Он использует последний 512-байтовый сектор в первых 32 КБ и все, что потребуется, для завершения размера единицы распределения, запрашиваемого при форматировании диска. Из-за того, как ведут себя контроллеры и кэши, а также из-за того, как настроены полосы RAID, иногда необходимо выполнить несколько операций ввода-вывода для чтения или записи полных единиц распределения, что также известно как размер кластера. Пропуск еще одного 512-байтового сектора для выравнивания по 32 КБ сработал бы лучше, потому что кластеры были бы лучше согласованы с тем, как работает диск, и количество операций ввода-вывода было бы уменьшено. Microsoft признала эту проблему, и в Windows 2008 разделы по умолчанию выравниваются по размеру 1024 КБ, оставляя позади один мегабайт, что приводит к лучшему выравниванию и меньшему количеству операций ввода-вывода. Конечно, это описание очень краткое, и то, что происходит под капотом, зависит от точной комбинации контроллера, дисков и конфигурации RAID, а также от подготовки диска.
Наилучший ответ на вопрос об оптимизации производительности дисков — это тестирование дисков под нагрузкой, аналогичной тому, как SQL Server будет использовать диски. Существует несколько инструментов для такого рода бенчмаркинга. Я использую SQLIO, который можно бесплатно загрузить с сайта Microsoft. IOMeter, который был написан Intel, но теперь имеет открытый исходный код, является еще одной бесплатной альтернативой. Сравнительный анализ с SQLIO будет предметом другой статьи.
Прежде чем можно будет начать тестирование, вы должны знать смещение раздела и размер единицы выделения диска. Windows не позволяет легко найти любой из этих элементов информации, но их можно найти с помощью инструментов командной строки, которые рассматриваются ниже.
Размер единицы распределения
Начнем с размера единицы распределения.
Размер единицы размещения задается командой FORMAT и также называется размером кластера. Для дисков в формате NTFS, которые вы должны использовать с SQL Server, Windows поддерживает размеры 512, 1024, 2048, 4096, 8192, 16 КБ, 32 КБ и 64 КБ. Размер кластера указывается параметром /A формата. Единица выделения — это наименьший объем пространства, который может занимать файл, и ИТ-специалисты, заботящиеся о пространстве, иногда используют наименьший возможный размер, чтобы получить как можно больше файлов на дисках. Однако при работе с SQL Server количество файлов очень мало. так что это не должно быть соображением. Если параметр /A не указан в команде FORMAT, Windows будет использовать размер единицы выделения по умолчанию, равный 4096 байтам.
Размер единицы распределения можно определить с помощью встроенной в Windows команды fsutil. fsutil предоставляет все данные, которые вы когда-либо захотите узнать о диске Windows. У него много подкоманд, каждая из которых возвращает специализированный набор информации. Чтобы получить размер единицы размещения, используйте подкоманду «fsinfo ntfsinfo», как показано на снимке экрана ниже, который был взят с диска, который я готовил. Красная стрелка указывает на «Байтов на кластер», который представляет собой размер единицы распределения. В данном случае по умолчанию 4096.
Смещение раздела
Разделы можно создавать либо с помощью подключаемого модуля «Управление дисками» в консоли управления Windows (MMC), либо с помощью программы командной строки DISKPART, которая входит в состав Windows 2003 и более поздних версий.Для Windows 2000 существует предыдущая утилита DISKPAR, входящая в состав Windows 2000 Resource Kit. Обратите внимание, что обновление DISKPART для Windows 2003 можно загрузить на этой странице. DISKPART имеет больше возможностей, чем подключаемый модуль MMC, поэтому я буду использовать его здесь. К сожалению, DISKPART — не лучший инструмент для получения смещения раздела, потому что он округляет смещение до ближайшего килобайта, давая вводящий в заблуждение ответ. Вот DISKPART на Диске 1, Раздел 1.
Смещение указано в 32 КБ, что, вероятно, было бы неплохо. Проблема в том, что фактическое смещение немного отличается.
К сожалению, утилиты Windows не соответствуют нумерации разделов. WMIC над числами начинается с 0, а номера DISKPART — с 1. С этим нам придется смириться, но об этом нужно помнить.
Как видите, смещение Диска 1, Раздел 0 составляет 32 258 байт. Это шестьдесят три блока по 512 байт. 32 КБ будет на 512 байт больше, что составляет 32 768 байт. Раздел смещен, и для удовлетворения типичных запросов SQL Server требуются дополнительные операции ввода-вывода. С этим надо что-то делать! В будущих советах мы расскажем, что следует делать.
В этом примере главы из Администрирование SQL Server 2019 изнутри авторы рассматривают процесс установки и настройки экземпляра Microsoft SQL Server, а также создание или миграцию баз данных. Они уделяют особое внимание новым функциям, представленным в SQL Server 2019, и другим недавним функциям, которые вы, возможно, не заметили в SQL Server 2017. Они просматривают контрольный список после установки, который вы каждый раз проверяете, и, при необходимости, направляют вас туда, где вы Вы можете найти другие источники информации и подробные сведения о важных шагах в других разделах этой книги.
Что нужно сделать перед установкой SQL Server
Установка нового экземпляра
Конфигурация сервера после установки
Настройка других функций после установки
В этой главе мы рассмотрим процесс установки и настройки экземпляра Microsoft SQL Server, а также создание или миграцию баз данных. Мы уделяем особое внимание новым функциям, представленным в SQL Server 2019, и другим недавним функциям, которые вы, возможно, не заметили в SQL Server 2017. Мы просматриваем контрольный список после установки, чтобы вы могли каждый раз проверять его и, при необходимости, направлять вас туда, где вы Вы можете найти другие источники информации и подробные сведения о важных шагах в других разделах этой книги.
Содержимое этой главы, посвященное средству установки SQL Server, главным образом относится к установкам SQL Server в операционных системах Windows. Установка или создание значительно упрощается для базы данных SQL Azure, управляемого экземпляра базы данных SQL Azure, SQL Server в Linux, SQL Server в контейнерах Docker или виртуальных машин Azure, на которых работает SQL Server. Многие рекомендуемые в этой главе настройки по-прежнему применимы к серверным платформам SQL Server, например, в контейнерах Docker или SQL Server в Linux. В конце концов, это все тот же продукт SQL Server, который всегда существовал в Windows.
В главе 6 «Подготовка и настройка баз данных SQL Server» мы рассмотрим начальное создание и настройку баз данных внутри экземпляра SQL Server. Однако в этой главе основное внимание уделяется установке и настройке на уровне сервера.
Что нужно сделать перед установкой SQL Server
Прежде чем запустить установщик SQL Server на Windows Server, необходимо учесть ряд факторов и параметров, некоторые из которых нельзя легко изменить после установки. Например, выбор между экземпляром по умолчанию и именованным экземпляром или выбор сортировки экземпляра — это не тот выбор, который можно легко отменить после установки. (Подробнее о параметрах сортировки на уровне сервера далее в этой главе в разделе «Сортировка экземпляров».)
Однако многие ошибки, допущенные при установке, могут быть устранены впоследствии, вероятно, с некоторой утомительностью и простоями. Например, если пропустить исходные каталоги данных и журналов по умолчанию, все ваши базы данных могут оказаться на томе операционной системы. Позже их можно будет переместить в соответствующие тома, но лучше сделать это правильно с первого раза.
Мы рекомендуем вам получить содержимое этого списка до начала установки SQL Server:
Учетные записи службы Active Directory для службы SQL Server, службы агента SQL и других функций, если это необходимо
Последнее загруженное накопительное обновление для доведения экземпляра до последнего уровня исправления
Решение о лицензировании в отношении количества процессоров и выпуска, который нужно купить
Защищенное корпоративное цифровое хранилище для различных паролей, которые вы будете генерировать, резервных копий сертификатов, ключей
Установить экземпляр по умолчанию или именованный экземпляр
План размещения файлов SQL Server и форматирование каждого тома в соответствии с размером выделяемого дискового блока 64 КБ
Давайте теперь поговорим подробнее о последнем элементе.
Принятие решения об использовании тома
По многим причинам файлы SQL Server различных типов следует размещать на отдельных томах. Несмотря на то, что вы можете переместить пользовательские и системные данные базы данных и файлы журналов в другие места после установки, лучше спланировать свои тома до установки.
В примерах в этой главе предполагается, что ваша операционная система Windows установлена на томе C вашего сервера. У вас должно быть много других томов для файлов SQL Server — вскоре мы рассмотрим образец макета. Один из основных руководящих принципов установки SQL Server заключается в том, что везде, где вы видите «C:\», замените его на другой том. Это помогает свести к минимуму влияние SQL Server на том операционной системы (ОС), особенно если вы устанавливаете несколько экземпляров SQL Server, и может иметь потенциальные последствия аварийного восстановления с точки зрения резервного копирования и восстановления на уровне тома.
Что делать, если у вас мало места на томе ОС после установки SQL Server?
Существует несколько простых и несколько сложных способов минимизировать объем установки SQL Server на томе операционной системы вашего сервера (обычно это том C, как в этом примере). Как правило, программа установки SQL Server и накопительные обновления удаляют временные файлы, участвующие в их установке, но не файлы журналов или файлы конфигурации, которые должны занимать минимум места. Мы рекомендуем не удалять какие-либо файлы, установленные программой установки SQL Server или накопительными обновлениями, кроме файлов журналов. Вместо этого давайте рассмотрим некоторые упреждающие действия по перемещению этих файлов с тома C.
Некоторые части программы установки SQL Server будут установлены на том ОС (обычно, а также в этом и последующих примерах на том Windows C). Эти файлы, представляющие собой промежуточные области для установки SQL Server, создаются на томе ОС в структуре подпапок C:\Program Files\Microsoft SQL Server\150\Setup Bootstrap\, где 150 относится к внутренний номер версии (15.0) SQL 2019. Эта папка используется для будущих накопительных обновлений или изменений функций.
Если у вас очень мало места перед установкой SQL Server, вы также обнаружите, что корневым каталогом установки двоичных файлов по умолчанию будет C:\Program Files\Microsoft SQL Server\. Когда вы используете пользовательский интерфейс программы установки SQL Server, изменить это нельзя. Однако этот путь к папке установочного каталога указан как параметр INSTANCEDIR в файле конфигурации, созданном программой установки SQL Server. Как использовать файл конфигурации для установки SQL Server, более подробно описано в разделе «Автоматизация установки SQL Server с помощью файлов конфигурации» далее в этой главе.
Если это первый экземпляр SQL Server, который вы устанавливаете на сервер, у вас будет возможность изменить расположение файлов общих функций, корневой каталог данных для экземпляра (который содержит системные базы данных), расположения баз данных по умолчанию. для файлов пользовательских баз данных и их резервных копий. Если это не первая установка экземпляра SQL Server 2019 на этом сервере, расположение каталогов общих функций (для Program Files и Program Files x86) уже будет задано для вас, и вы не сможете его изменить.
Вы должны разместить как можно большую часть установки на других томах, а не на томе ОС. Имейте в виду, что полнофункциональная установка SQL Server 2019 может занимать более 14 ГБ.
Что можно сделать с томом D: на виртуальной машине Azure?
Для виртуальных машин Microsoft Azure Windows не задавайте каталоги установки для каких-либо параметров на томе D:\ «Временное хранилище». В виртуальной машине Linux то же самое относится к /dev/sdb1.
Том временного хранилища на виртуальных машинах Azure — это временный диск, который локально присутствует на компьютере, на котором размещена ваша виртуальная машина Azure, поэтому он имеет лучшую производительность и меньшую задержку, чем том C: по умолчанию. Том временного хранилища по умолчанию содержит только файл страницы Windows и стирается при перезапуске сервера, изменении размера или переносе хоста!
Единственно возможное долгосрочное использование тома временного хранилища — это файлы TempDB, которые могут существовать, если принять во внимание некоторые другие соображения. Подробнее об этом см. в Главе 3. Проектирование и реализация локальной инфраструктуры базы данных. В противном случае не храните невременные файлы во временном хранилище.
Следующий пример сценария является хорошей отправной точкой для макета тома для установки SQL Server (буквы тома не имеют значения):
Том C. OS, здесь должны быть установлены некоторые файлы SQL Server.
Том Е.Установочные файлы SQL Server, файлы журналов, файлы данных базы данных SQL Server.
Том F. Файлы журнала базы данных SQL Server.
Том G. Файлы данных TempDB SQL Server и файл журнала. (В качестве альтернативы можно использовать том временного хранилища D: на виртуальных машинах Azure Windows.)
Резервные копии Volume H. SQL Server (если они записаны локально)
А вот еще несколько расширенных решений по объему:
Используйте дополнительные тома для самых больших файлов данных (более 2 ТБ) для удобства управления хранилищем:
Для самых активных баз
Для файловых групп FILESTREAM
Для файлов моментальных снимков репликации базы данных
Для файла подкачки Windows, особенно для серверов с большим объемом памяти
Зачем размещать файлы SQL Server на разных томах?
Есть веские причины для разделения файлов SQL Server на разные тома, и не все они связаны с производительностью. Вам все равно следует разделить файлы на разные тома, даже если вы используете исключительно сеть хранения данных (SAN).
Больше дискретных операций ввода-вывода на физическом сервере с выделенными дисками означает более высокую производительность. Но даже в SAN разделение файлов на разные тома также сделано для стабильности. Думайте о томах как о переборках на подводной лодке. Если том заполнен и не имеет свободного места, для файлов не может быть выделено дополнительное пространство. На томе ОС нехватка свободного места может привести к проблемам со стабильностью Windows Server, по крайней мере, к проблемам с профилями пользователей и удаленными рабочими столами, а также повлиять на другие приложения.
Важные настройки тома SQL Server
Есть некоторые параметры, которые следует учитывать для томов, на которых размещаются файлы данных и журналов SQL Server, и это руководство относится именно к этим томам. Для других томов, например тех, которые содержат ОС, файлы приложений или файлы резервных копий, допустимы параметры Windows по умолчанию, если не указано иное.
При добавлении этих томов в Windows необходимо проверить четыре важных параметра конфигурации тома или обсудить их с администратором хранилища.
При создании новых дисков выберите таблицу разделов GUID (GPT), а не типы дисков с основной загрузочной записью (MBR) для новых установок SQL Server. GPT — это более новая схема разметки диска, чем MBR, и диск GPT поддерживает файлы и тома размером более 2 ТБ, тогда как старый тип диска MBR ограничен 2 ТБ.
Подходящий размер файловой единицы для томов SQL Server составляет 64 КБ, за некоторыми исключениями. Установка этого значения на 64 КБ для каждого тома может существенно повлиять на эффективность и производительность хранилища. Значение по умолчанию для Windows – 4 КБ, что не является оптимальным для файлов данных и журналов SQL Server.
Чтобы проверить размер выделенного файлового блока для тома файловой системы NT (NTFS), запустите от администратора следующую команду: Подсказка, повторяющаяся для каждого тома:
Размер выделенного файла возвращается вместе с числом байтов на кластер; таким образом, желаемые 64 КБ будут отображаться как 65 536 (байт). Если отформатировано по умолчанию, будет отображаться 4096. Для исправления размера выделяемого файла требуется форматирование диска, поэтому важно проверить этот параметр перед установкой.
Если вы заметите это на существующем экземпляре SQL Server, вероятно, вам нужно будет создать новый том с правильным размером файловой единицы, а затем переместить файлы на новый том во время простоя. не форматируйте и не создавайте заново раздел на томах с существующими данными: вы, конечно, потеряете данные.
Современные устройства хранения в настоящее время находятся в процессе перехода между дисками, которые используют размер байтов на физический сектор, равный 512 байтам (старый стандарт), и «4K Native» диски, которые имеют как размер байтов на сектор, так и размер байтов на физический сектор. размером 4 КБ. Обычно администратор баз данных не замечает или даже не знает об этой разнице. Однако при настройке групп доступности или доставки журналов между серверами в разных системах хранения со смешанными режимами «Байт на физический сектор» это может привести к очень низкой производительности, при этом журналы транзакций не могут быть усечены и появляется сообщение об ошибке «Там были nnn неправильно выровненные операции ввода-вывода журнала, что потребовало возврата к синхронному вводу-выводу». Вы можете столкнуться с этим, например, в гибридных группах доступности, охватывающих локальные экземпляры SQL Server и экземпляры SQL Server на базе виртуальных машин Azure.
Это не может быть решено с помощью решения о форматировании, но потенциально может быть решено с помощью хранилища на аппаратном уровне или настроек встроенного ПО. Чтобы избежать этого, все хранилища, в которых размещаются файлы журналов транзакций серверов SQL Server в группе доступности или отношении доставки журналов, должны иметь одинаковые байты на физический сектор.
Обходной путь заключается в применении флага трассировки 1800 в качестве флага запуска для экземпляров SQL Server, которые используют хранилище без параметра «Байт на физический сектор», равного 4 КБ. TF1800 переопределяет поведение диска по умолчанию и записывает журнал транзакций в сектора по 4 КБ, решая проблему.TF1800 должен быть включен в локальных экземплярах SQL Server в случае использования более старой локальной группы и группы доступности виртуальных машин Azure.
Проверьте параметр Байт на физический сектор тома, используя ту же команду Fsutil, что и в предыдущем примере кода.
Существует понятие аппаратного уровня, относящееся к размеру файловой единицы, называемое "начальным смещением диска", которое касается того, как Windows, хранилище, дисковые контроллеры и сегменты кэша выравнивают свои границы. Выравнивание начального смещения диска было гораздо более важным до Windows Server 2008. С тех пор смещение раздела по умолчанию в 1024 КБ было достаточно для выравнивания с размером страйп-блока базового диска, который определяется поставщиком и редко беспокоит пользователей. DBA. Тем не менее, его следует проверить при первом использовании новой системы хранения или переносе дисков на новую систему хранения. Это можно проверить, обратившись к информации поставщика накопителя.
Чтобы получить доступ к информации о начальном смещении диска, запустите от администратора следующее: Подсказка:
Как и в случае с размером файловой единицы, единственный способ изменить начальное смещение раздела диска является деструктивным: вы должны заново создать раздел и переформатировать том, чтобы привести его в соответствие со смещением, предоставленным поставщиком.
Выпуски SQL Server
Ниже приведены краткие описания всех выпусков семейства SQL Server, включая прошлые выпуски, которые вам могут быть знакомы. Важно использовать соответствующие лицензии для SQL Server даже в тестовых системах.
Эта книга не предназначена для использования в качестве справочника по лицензированию или документации по продажам; скорее, выпуски являются ключевой частью знаний для администраторов SQL, чтобы понять, какие функции могут быть или не быть доступными.
Корпоративная версия. Подходит для производственных сред. Не подходит для подготовительных сред, таких как пользовательское приемочное тестирование (UAT), обеспечение качества (QA), тестирование, разработка или песочница. Вместо этого для этих сред используйте бесплатную версию Developer. Вам будет намного проще провести аудит лицензирования, если ваши предварительные установки среды относятся к выпуску Developer.
Версия для разработчиков. Подходит для всех подготовительных сред, особенно для рабочей версии Enterprise. Не допускается для производственных сред. Этот выпуск поддерживает те же функции и возможности, что и выпуск Enterprise, и является бесплатным.
Стандартная версия. Подходит для производственных сред. Не хватает функций масштабирования и соответствия корпоративной версии, которые требуются в некоторых нормативных средах. Ограничено меньшим из 4 сокетов или 24 ядер, а также 128 ГБ памяти буферного пула, тогда как версия Enterprise ограничена только операционной системой для вычислений и памяти.
Веб-издание. Подходит для производственных сред, но ограничен недорогими серверными средами для веб-приложений.
Экспресс-версия. Не подходит для большинства производственных сред или подготовительных сред. Подходит только для сред, в которых размер данных невелик, рост не ожидается и резервное копирование может выполняться с помощью внешних инструментов или сценариев (поскольку в выпуске Express нет агента SQL Server для автоматизации резервного копирования). Бесплатная версия Express идеально подходит для производственной проверки концепции, облегченных приложений или студенческих проектов. В нем отсутствуют некоторые важные функции, и он сильно ограничен по вычислительным ресурсам (меньше 1 сокета или 4 ядер), доступной памяти буферного пула (1410 МБ) и размеру отдельной базы данных (максимум 10 ГБ).
Express с расширенными услугами. Подобно версии Express со всеми предостережениями и ограничениями, эта версия включает некоторые дополнительные функции, включая интеграцию R, полнотекстовый поиск и распределенное воспроизведение.
Оценочная версия. Функционально то же, что и версия Enterprise, и бесплатна с 180-дневным таймером выключения, но не поддерживается. Можно обновить до любой версии, кроме Express. Не используйте его, если вы планируете кластерную установку, так как обновление в этом случае не поддерживается.
Стоит отметить, что аппаратные ограничения редакций SQL Server не изменились со времен SQL Server 2016.
При запуске установщика SQL Server 2019 вам будет предложено установить ряд функций, не входящих в основные функции базы данных. Для установки функций SQL Server на нескольких серверах Windows требуется несколько лицензий на каждый сервер, даже если вы собираетесь установить функции каждого экземпляра SQL Server только один раз.
Из этого правила есть исключение: если вы лицензировали все физические ядра на виртуальном хост-сервере для выпуска SQL Server Enterprise и приобрели Software Assurance, вы можете установить любое количество или комбинацию экземпляров SQL Server и их отдельные функции для виртуальных гостей.
Изменение выпусков и версий SQL Server
Обновление выпусков на месте поддерживается функцией установщика SQL Server 2019. Вы можете выполнить обновление в следующем порядке: Express, Web, Standard и Enterprise.
Важно отметить, что вы не можете понизить версию или лицензионный выпуск SQL Server. Этот тип изменений требует новой установки и миграции. Например, вы не можете понизить версию SQL Server 2019 на месте с версии Enterprise до версии Standard.
Обновления на месте для основных версий (например, с 2017 до 2019) поддерживаются, но не рекомендуются. Вместо этого мы настоятельно рекомендуем выполнить новую установку более новой версии, а затем выполнить миграцию со старых экземпляров на новые. Этот метод предлагает большие преимущества с точки зрения продолжительности запланированного простоя, возможности отката и параллельного надежного тестирования.
Хотя обновления на месте до SQL Server 2019 не рекомендуются, они поддерживаются для таких старых версий, как SQL Server 2012 в Windows Server 2016. SQL Server 2019 — первая версия SQL Server, которая не поддерживает Windows Server 2012 или 2012. R2.
Начиная с SQL Server 2019, обновление SQL Server с SQL Server 2008 больше не поддерживается, хотя отдельные базы данных по-прежнему можно перенести на SQL Server 2019. Вы можете подключить или восстановить его базы данных к SQL Server 2019, хотя они будут обновлен до уровня совместимости 100, уровня версии для SQL 2008.
В своей предыдущей статье я начал с проверки различных параметров, влияющих на производительность, прежде чем переходить к настройке запросов. В этой статье продолжается исследование параметров, влияющих на производительность, и мы сразу переходим к подсистеме хранения. Хотели бы вы внести одно изменение в свои диски и улучшить операции ввода-вывода на 40 %?
Просто переформатируйте диски, содержащие данные вашей базы данных и файлы журналов.
Если вы используете более раннюю версию Windows, чем Windows Server 2008, или если диски были перенесены в новую систему без их переформатирования, вы действительно можете улучшить производительность операций ввода-вывода, просто переформатировав диски. Старые версии Windows будут создавать разделы диска, границы которых по умолчанию основаны на древней схеме адресации цилиндр/головка/сектор, которая была распространена в дисковых контроллерах той эпохи. После того, как эти границы установлены, единственный способ изменить их — переформатировать диск, поэтому перенос этого диска на сервер Windows Server 2008 или более поздней версии сам по себе не решит проблему.
Как переформатирование диска влияет на производительность ввода-вывода
Размер файла
На жестком диске минимальный объем данных, которые могут быть прочитаны или записаны, называется сектором, который исторически составлял всего 512 байт (более новые диски могут иметь размер сектора до 4 КБ). Группа секторов представляет собой кластер (нет, не этот тип кластера). Диск с размером кластера 64 КБ (по 512 байт на кластер) будет иметь 128 секторов, что также называется размером выделяемого файла. Первые 63 сектора диска зарезервированы или скрыты и содержат главную загрузочную запись (MBR). Простое умножение 63 секторов на размер сектора в 512 байт показывает, что эта скрытая область занимает 32 256 байт или 31,5 КБ. Сразу после этого диск корректно начинает сохранять данные.
Операции ввода-вывода SQL Server
Теперь рассмотрим, как SQL Server выполняет операции дискового ввода-вывода — экстент за раз (экстент — это 8 страниц, каждая из которых имеет размер 8 КБ, всего 64 КБ). Чтобы сохранить эту информацию на диске, с настройками по умолчанию эти 64 КБ будут начинаться сразу после 31,5 КБ и продолжаться до 64 КБ… и будут охватывать два кластера. Когда диск переходит к чтению этих данных, ему нужно будет прочитать первый кластер, а затем второй кластер, чтобы получить все данные, необходимые для экстента, считываемого с диска. Когда будет прочитан следующий экстент, будет перечитан второй кластер и прочитан третий кластер. Ненужная операция ввода-вывода должна быть очевидна.
Как улучшить работу SQL Server с диском
Что нам нужно сделать, так это сместить начало данных, хранящихся на диске, в место, более подходящее для работы программы. Это смещение известно как «Смещение выравнивания раздела». Чтобы соответствовать SQL Server, это значение должно быть увеличено на 64 КБ. Однако вам также необходимо учитывать всю подсистему хранения — диски, контроллеры и память. Начиная с Windows Server 2008, это смещение составляет 1024 КБ — хорошее увеличение на 64 КБ, которое также очень хорошо работает с большинством дисков/контроллеров RAID. До Windows Server 2008 смещение выравнивания разделов не выполнялось явно, поэтому это необходимо будет выполнить.
Определение смещения выравнивания раздела диска
Чтобы определить смещение выравнивания раздела для базового диска Windows, можно выполнить очень простую команду wmic:
Эта тема уже давно серьезно обсуждается… в области виртуализации.Я хотел бы добавить несколько идей в эту тему, с новым выпуском vSphere 5.x произошло много изменений в файловой системе VMFS, а также с выпуском Windows 2008, 2008 R2, 2012 и RHEL 6.x, Ubuntu 12.x нет необходимости выполнять выравнивание разделов, но было бы полезно знать, как эти ОС создают разделы и обрабатывают дисковые тома.
Кроме того, устаревшие ОС, такие как Windows 2003, RHEL 5.x, по-прежнему нуждаются в выравнивании разделов с файловой системой vSpehere 5 и VMFS 5. Короче говоря, в целом эта тема относится к физическим гипервизорам других поставщиков, а также к VMWARE.
В Интернете есть много устаревших статей, и приведенная ниже информация даст хорошее представление об этой теме.
Теория и история
Все мы знаем, что физическому серверу или массиву хранения нужны физические жесткие диски, а для виртуальной машины это виртуальный жесткий диск. На изображении ниже показана геометрия жесткого диска
В случае с ранними жесткими дисками IDE/ATA BIOS обеспечивал доступ к жесткому диску через режим адресации, называемый сектором головки цилиндра, также известным как CHS, который был ранним методом присвоения адресов каждому физическому блоку данных. на жестком диске. CHS-адресация — это процесс идентификации отдельных секторов на диске по их положению на дорожке, где дорожка определяется номерами головок и цилиндров.
В старых компьютерных системах максимальный объем адресуемых данных был очень ограничен — из-за ограничений как в BIOS, так и в интерфейсе жесткого диска. Этот метод используется в устаревших ОС, таких как NT, DOS и т. д.
В современных жестких дисках используется последняя версия стандарта ATA, например ATA-7. Доступ к этим дискам осуществляется с использованием другого режима адресации, называемого: адресация логических блоков или LBA, включающая совершенно новый способ адресации секторов. Вместо ссылки на номер цилиндра, головки и сектора каждому сектору присваивается уникальный «номер сектора». По сути, сектора нумеруются от 0, 1, 2 и т. д. до (N-1), где N — количество секторов на диске. Таким образом, доступ ко всем современным дискам теперь осуществляется с использованием схемы логической блочной адресации (LBA), где сектора просто линейно адресуются от 0 до некоторого максимального значения, а границы разделов диска определяются начальным и конечным адресами LBA. В системе адресации LBA, где каждый цилиндр стандартизирован до 255 головок, каждая головка имеет одну дорожку с 63 логическими блоками или секторами, каждая из которых имеет 512 байтов. Вы можете увидеть эту информацию в Linux
Все современные ОС используют метод LBA для чтения/записи данных на жесткий диск.
В прежние времена физический сектор жесткого диска составлял 512 байт, и это было стандартом более 30 лет. Размер этого физического сектора будет соответствовать размеру одного логического блока или сектора ОС, который составляет 512 байт, поэтому проблем нет. В 2009 году IDEMA (Международная ассоциация оборудования и материалов для дисковых накопителей) и ведущие компании по хранению данных внедрили в жесткие диски технологию Advanced Format (AF), так что размер физического сектора составит 4 КБ (4096 байт). Диски с большими физическими секторами позволяют использовать улучшенные алгоритмы защиты и исправления данных, что обеспечивает повышенную надежность данных. Физические сектора большего размера также обеспечивают большую эффективность форматирования, тем самым высвобождая место для дополнительных пользовательских данных.
Одной из проблем, связанных с введением этого изменения в формат мультимедиа, является возможность возникновения проблем совместимости с существующим программным и аппаратным обеспечением. В качестве временного решения для обеспечения совместимости индустрия хранения данных изначально представляет диски, которые эмулируют обычный диск с 512-байтными секторами, но предоставляют информацию о реальном размере сектора с помощью стандартных команд ATA и SCSI. В результате этой эмуляции существует, по сути, два размера сектора:
Логический сектор: единица, используемая для адресации логического блока мультимедиа. Мы также можем думать об этом как о наименьшей единице записи, которую может принять хранилище. Это «эмуляция».
Физический сектор: единица, для которой операции чтения и записи на устройство выполняются за одну операцию. Это фактический размер физического сектора хранения данных на диске.
Исходные типы носителей большого сектора
Индустрия хранения быстро наращивает усилия по переходу на этот новый тип хранилища расширенного формата для носителей с размером физического сектора 4 КБ. На рынок будут выпущены два типа носителей:
Исходный размер 4 КБ: диски, которые напрямую сообщают о размере логического сектора 4 КБ и имеют размер физического сектора 4 КБ. Диск может принимать операции ввода-вывода только 4 КБ на диски. Однако программный стек может поддерживать размер логического сектора 512 байт благодаря поддержке RMW. Этот носитель не имеет уровня эмуляции и напрямую предоставляет 4 КБ в качестве размера своего логического и физического сектора.Общая проблема с этим новым типом носителя заключается в том, что большинство приложений и операционных систем не запрашивают и не выравнивают операции ввода-вывода по размеру физического сектора, что может привести к неожиданным сбоям операций ввода-вывода.
Эмуляция 512 байт (512e): Диски, которые напрямую сообщают о размере логического сектора в 512 байт, но имеют размер физического сектора 4 КБ — встроенное ПО преобразует записи 512 байт в записи 4 КБ RMW (чтение, изменение, запись). В современных накопителях этот перевод приводит к снижению производительности. Этот носитель имеет уровень эмуляции, как обсуждалось в предыдущем разделе, и предоставляет 512 байтов в качестве размера своего логического сектора (аналогично сегодняшнему обычному диску), но делает доступной информацию о размере физического сектора (4 КБ).
Общая поддержка Windows для носителей с большими секторами (4 КБ)
Эта таблица документирует официальную политику поддержки Microsoft для различных носителей и соответствующие размеры секторов. Подробнее см. в этой статье базы знаний.
Windows 8, Windows Server 2012 и начиная с ядра Linux версии 2.6.34 полностью поддерживают чтение и запись 4K для LBA операционной системой. Операционные системы, такие как Windows 7, 2008, 2008 R2, по-прежнему используют 512 байт для каждого логического блока или сектора, поэтому один физический сектор размером 4 КБ содержит 8 логических секторов размером 512 байт.
Эмуляция 512 байт на интерфейсе накопителя
Для обеспечения совместимости Western Digital, Hitachi, Toshiba эмулируют 512-байтовое устройство, сохраняя 512-байтовый сектор на интерфейсе диска, преобразование которого будет выполняться микропрограммой внутри контроллера жесткого диска; и Seagate использует технологию SmartAlign для этой эмуляции (на уровне прошивки). Эти накопители также называются Advanced Format 512e. Посмотрим, как это работает.
Чтение 512 байт
Когда хост запрашивает чтение одного 512-байтового логического блока, жесткий диск фактически считывает весь физический сектор размером 4 КБ, содержащий запрошенные 512 байт. Блок размером 512 байт извлекается и отправляется на хост. Это можно сделать очень быстро.
512-байтовая запись (чтение-изменение-запись)
Когда хост пытается записать один логический блок размером 512 байт, жесткий диск сначала считывает физический сектор размером 4 КБ, содержащий 512 байт, которые необходимо перезаписать. Затем он вставит 512 байт новых данных и запишет весь блок данных размером 4 КБ обратно на носитель. Этот процесс называется «Чтение-изменение-запись». Диск должен прочитать существующие данные, изменить подмножество, а затем записать данные обратно на диск. Этот процесс может потребовать дополнительных оборотов жесткого диска.
Как технология Advanced Format поддерживает производительность?
Чтобы поддерживать максимальную производительность, важно обеспечить выравнивание операций записи на диск. В идеале запись должна выполняться блоками по 4 КБ, а затем каждый блок будет записываться в физический сектор 4 КБ на диске. Этого можно добиться, убедившись, что ОС и приложения записывают данные блоками по 4 КБ, а диск правильно разбит на разделы. Большинство современных операционных систем используют файловую систему, которая распределяет хранилище в блоках или кластерах по 4 КБ (размер блока кластера/файла NTFS или размер блока файловой системы EXT3/4). На традиционном жестком диске блок размером 4 КБ состоит из восьми секторов по 512 байт (см. рис. 4. Размер сектора эмулируемого устройства размером 512 байт).
В производственной среде на первый план выходит уровень RAID, эти физические сектора размером 4 КБ снова объединяются, чтобы сформировать размер RAID STRIP, который может варьироваться от 4 КБ до 256 КБ в зависимости от уровня RAID. В массиве хранения тоже самое. Таким образом, контроллер массива RAID, такой как PERC, Intel, LSI, Smart Array и т. д., будет обрабатывать и предоставлять том RAID для ОС. В обоих случаях необходимо выровнять раздел ОС.
Поскольку большинство современных операционных систем записывают блоки по 4 КБ, важно, чтобы каждый логический блок по 4 КБ был выровнен с физическим блоком по 4 КБ на диске (см. рис. 5).Это особенно важно, потому что функция 512e диска не может помешать утилите создания разделов создать неправильный раздел. При смещении логический блок размером 4 КБ будет располагаться в двух физических секторах.
В этом случае одно чтение или запись блока размером 4 КБ приведет к чтению/записи двух физических секторов. Влияние «чтения» минимально, тогда как одна запись вызовет два «чтения-изменения-записи», что может повлиять на производительность (см. рис. 6).
Итак, что теперь произойдет с такими ОС, как XP, Windows 2003, RHEL5.x и т. д., и зачем нам нужно выравнивание дисков в ФИЗИЧЕСКОМ или ВИРТУАЛЬНОМ мире?
Как я уже упоминал, физические диски имеют физические сектора размером 4 КБ, а том RAID или LUN из массива хранения имеют размер полосы от 4 КБ до 256 КБ, что кратно 4 КБ, а операционная система имеет логический сектор размером 512 байт. Когда мы устанавливаем операционную систему, например 2003, RHEL 5.x. на жестком диске или LUN, в этих ОС первые 62 сектора (первая дорожка) жесткого диска зарезервированы для области BOOT и скрыты для ОС.
Это зарезервированные (скрытые) сектора от 0 до 62, главная загрузочная запись (MBR) находится внутри этих скрытых секторов. Основная загрузочная запись (MBR) находится в этих скрытых секторах. Он использует первый сектор первой дорожки для данных MBR (LBA 0), а первый раздел начинается в последнем секторе первой дорожки, то есть с (логического) адреса блока 63. Вы можете увидеть это ниже;
Здесь, в более ранней версии RHEL 5.x/LINUX, мы видим, что первый раздел начинается с сектора/LBA 63, и если вы добавите еще один жесткий диск или LUN на этот хост, и когда вы создадите раздел, инструмент для создания разделов эти версии Linux снова создают раздел, начиная с сектора 63.
Здесь, в приведенной выше информации из Windows 2003, первый раздел начинается со смещения 32256, в Windows он не показывает LBA/номер сектора, вместо этого он показывает значения в байтах. Это смещение 32256 означает (32256/512) = 63 LBA/сектор, поэтому раздел начинается с сектора 63. Ниже приведен подробный способ подтверждения этого;
Основные корреляции: смещение раздела, размер единицы размещения файлов и размер единицы чередования
Используйте информацию в этом разделе, чтобы подтвердить целостность конфигурации выравнивания разделов диска для существующих разделов и новых реализаций.
Существуют две корреляции, соблюдение которых является фундаментальным предварительным условием для оптимальной производительности дискового ввода-вывода. Результатом следующих вычислений должно быть целочисленное значение:
Partition_Offset ÷ Stripe_Unit_Size (размер физического сектора диска или размер полосы RAID)
Первый из двух наиболее важен для оптимальной производительности. Ниже показан распространенный сценарий смещения: при начальном смещении раздела в 32 256 байт (31,5 КБ) и размере страйпа в 4086 байт (4 КБ) результат равен 31,5/4 = 7,894273127753304. Это не целое число; поэтому размер блока офсета и полосы не коррелирует.
Во втором размере кластера NTFS или единице размещения файла значение по умолчанию равно 4086, и мы можем указать 32 КБ, 64 КБ и т. д. Если это MSSQL и EXCHANGE, рекомендуется указать 64 КБ во время форматирования, и это значение не является проблемой, и оно будет целым числом. Но первое — самое важное .
Итак, у нас есть НЕСООТВЕТСТВИЕ, и нам нужно заново выровнять раздел, как показано на диаграммах ниже;
Таким образом, Windows 7, 8, 2008, 2008 R2, 2012, RHEL 6, Debian 6, Ubuntu 10, 11, 12, SUSE 11 и более поздних версий автоматически выравнивает разделы во время установки. Вы можете увидеть это ниже;
В случае Windows выравнивание раздела по умолчанию равно 1024 КБ или границе 1 МБ (то есть начальное смещение 1 048 576 байт = 1024 КБ).Он хорошо коррелирует (как описано в предыдущем разделе, 1024 КБ/4 КБ = 256 целое число) с распространенными размерами блоков чередования, такими как 4 КБ, 64 КБ, 128 КБ и 256 КБ, а также с менее часто используемыми значениями 512 КБ и 1024 КБ. КБ. То есть просто инструмент создания разделов Windows начинает первый раздел с LBA/сектора 2048 (1 048 576/512 = 2048). Так что здесь нет необходимости в ручном выравнивании, и если мы добавим еще один диск, он также выполнит автоматическое выравнивание.
В RHEL и последних версиях Linux первый раздел начинается с 2048, то есть LBA от 0 до 2047 зарезервирован. То есть ОС выровнена по границе 1 МБ, если мы посчитаем, сектор 2048 будет иметь смещение 1 048 576 байт (1 048 576 байт/512 = 2048), и если мы добавим еще один жесткий диск или LUN, он выполнит выравнивание автоматически.
В следующем посте я расскажу, как выполнить выравнивание дисков в vSphere или любом другом гипервизоре.
Читайте также: