При установке и настройке нового сервера SQL Server или приложений многие пренебрегают точным планированием объема дисковой памяти, необходимой для проекта. Благодаря постоянному снижению стоимости хранения данных можно запросто попросить администратора системы хранения добавить еще 500 Гбайт дискового пространства. Но о чем идет речь? На какой срок хватит этой добавки? На полгода, три года, или на целое десятилетие? Без ответа на этот вопрос нельзя быть уверенным, что требование обосновано. При этом необходимо учитывать скорость работы накопителя, которая напрямую связана со стоимостью решения. Может быть, в некоторых организациях эти затраты не учитываются слишком строго, но нельзя забывать, что одной из задач подразделения ИТ является эффективное использование выделенного бюджета. Предлагаю вниманию читателей методику определения необходимого дискового пространства, настройки дисков и выбора типа системы хранения из представленных на рынке.
Подготовка требований
Проще всего определить требования к объему, который займет ваша база данных. Просто рассчитаем, сколько байтов потребуется для хранения за период N месяцев. Хотя на первый взгляд это может показаться сложной задачей, если рассматривать базу данных как набор отдельных таблиц, все оказывается не так уж страшно. Сначала суммируем объем всех статических поисковых таблиц. Этот объем практически не меняется с течением времени, так что требуется просто оценить его и не забыть добавить к общему результату. Что касается рабочих таблиц, размер которых будет расти каждый день, месяц, год, то вам потребуются всего несколько величин — размер строки данных и среднее количество строк данных, добавляемых за выбранный период (день, месяц, год). Если речь идет о системе реального времени, например, ввода заказов или бронирования билетов, системы сетевой безопасности, за период логичнее всего взять один день. Размер строки данных вам подскажет разработчик базы. Также следует учитывать срок хранения данных в системе — следует ли хранить данные в системе в течение месяца, года или требуется накапливать полный объем данных за всю историю существования компании. Еще одной расчетной величиной является размер страницы данных на диске — для SQL Server он составляет 8060 байт.
Простейшие арифметические действия позволят нам определить общий объем данных для хранения. Допустим, в систему ежедневно добавляется 20 тыс. строк, каждая строка 187 байт, а сохранять эти данные требуется в течение трех лет. Сначала определим, сколько строк может храниться в странице данных (SQL Server не разбивает данные одной строки между двумя таблицами). Разделив размер страницы на размер строки, получаем 8060/187 = 43,101, как показано в таблице 1.
Полученное значение необходимо округлить до меньшего целого числа. Чтобы получить число добавляемых страниц, делим число ежедневно добавляемых строк на только что посчитанное количество строк на одной странице. 20000/43 = 465,11 — примерно такое число страниц будет добавляться в таблицу (таблица 2).
Это число мы округляем в большую сторону (до 466). Хотя страница может хранить 8060 байт данных, ее физический размер на диске составит 8 Кбайт. Умножив 466 на 8 Кбайт, получим, что в таблицу ежедневно добавляется 3728 Кбайт или 3,64 Мбайт, как показано в таблице 3.
Если считать, что в месяце 30,5 дня, то ежемесячное увеличение базы составит 111,02 Мбайт. Умножив на нормативный срок хранения данных (36 месяцев), получаем 3996,72 Мбайт или 3,9 байт за три года (см. таблицу 4).
Определив таким образом размеры, необходимые для хранения каждой таблицы, сложим все значения и получим размер базы данных на заданный период времени. Если в этот период будут происходить плановые перемещения данных в архивные базы, которые будут использоваться для аналитики и отчетов, действительный размер рабочей базы данных окажется меньше, так как некоторый объем данных будет удаляться из таблиц. После того как требования по объему данных определены, следует уточнить требования к скорости и избыточности дисков, на которых будет размещаться база данных.
Настройка накопителей RAID
Общей рекомендацией является использование RAID 10 для баз данных. RAID 10 обеспечивает быструю запись данных, при этом исключаются дополнительные затраты времени на вычисление контрольных сумм. Но, как правило, не учитывается стоимость предлагаемого решения. Конечно, RAID 10 обеспечивает максимальную производительность, но, кроме того, это и самое дорогое решение. В RAID 10 вдвое больше дисков, которые требуется настроить, и эти диски небесплатные. В некоторых случаях использование RAID 10 является оправданным, но применение RAID 10 для всех имеющихся баз данных может оказаться очень неэффективным использованием ресурсов. Большинство баз данных, которые настроены на применение систем хранения RAID 10, могли бы прекрасно работать и на системах RAID 5.
Чтобы определить, какой уровень RAID требуется для базы данных, давайте вспомним, что они собой представляют. RAID 5 называют также чередующимся набором с контролем четности. При записи данных на диск выполняется расчет контрольной суммы для каждой страницы данных. Эта контрольная сумма также записывается на диск. В случае отказа диска данные могут быть восстановлены по контрольной сумме контроллером дискового массива, а неисправный диск должен быть заменен. Одни поставщики систем хранения размещают всю контрольную информацию на один диск, другие распределяют эти данные по всем дискам в массиве. Хотя оба подхода обеспечивают одинаковый уровень защиты, распределение контрольных данных по всем дискам позволяет увеличить скорость работы массива, поскольку для чтения/записи оказывается доступен дополнительный диск.
RAID 10 называется также зеркальным набором. Количество дисков в массиве делится пополам, каждая половина выделяется под свой набор. Эти наборы зеркально отражают содержимое друг друга. При отказе одного из дисков набор с этого диска становится недоступен, после замены отказавшего диска данные восстанавливаются с зеркальной копии. Поскольку вычисление контрольных сумм при выполнении каждой операции записи при таком подходе не требуется, операция записи выполняется быстрее. С другой стороны, поскольку данные зеркалируются, для их хранения требуется вдвое большее количество дисков. На рисунке изображены варианты размещения наборов данных на физических дисках для систем хранения уровня RAID 5 и RAID 10.
Оптимизация кэширования
При настройке сети хранения SAN следует учитывать, что современные системы SAN оснащаются просто огромными объемами кэш-памяти. Такое решение позволяет кэшировать большое количество операций записи, так что, когда SQL Server выполняет запись данных на диск, в действительности физическая запись данных на диск не производится. На самом деле SAN кэширует эти данные и записывает их на диск позже. Благодаря кэшированию уровень RAID не влияет на скорость работы SQL Server, поскольку операции записи SQL Server и записи на диск оказываются не связанными между собой.
По умолчанию большинство систем SAN настроены на использование 50% кэша под чтение и столько же — под запись. Такая настройка может быть оптимальной для хранилища данных, но не всегда подходит для баз данных OLTP. Система SAN применяет упреждающее чтение данных в буфер, предполагая, какие данные могут быть востребованы хостом при следующей операции еще до того, как хост их действительно затребует. При следующем запросе данных хостом данные могут быть выданы немедленно прямо из кэша. Но для OLTP-приложений (баз данных, файловых и почтовых серверов) чтение большого количества последовательных блоков данных из файла происходит достаточно редко, в большинстве случаев выполняется чтение блоков вразнобой. Может оказаться, что стратегия упреждающего чтения даже снижает производительность системы за счет чтения больших объемов данных, которые оказываются невостребованными. Изменение соотношения объемов кэша чтения к записи с 50/50 на 30/70 или даже 20/80 может заметно повысить производительность системы за счет увеличения скорости записи данных SQL Server.
Такое изменение кэша позволяет добиться большей производительности и для дисков RAID 5. Так как SQL Server будет в действительности обращаться к дискам только для операций чтения, оптимальная производительность будет достигаться при чтении с максимального количества дисков. В случае RAID 10 только половина дисков будет использоваться для чтения данных, а для RAID 5 чтение производится со всех имеющихся дисков (или всех, кроме одного, в зависимости от выбранной производителем технической реализации).
Настройка системы хранения
Кроме настройки кэширования, рост производительности системы может быть достигнут за счет настройки логических томов LUN и уровней дисков. Например, имеет смысл проверить, какое влияние на производительность окажет отключение кэша непосредственно для LUN. Это отключит передачу кэша LUN в кэш SAN, что может оказаться полезным. Дело в том, что SQL Server тоже стремится кэшировать максимальный объем данных в оперативной памяти сервера. Благодаря этому SQL Server значительно сокращает число чтений с диска, а когда необходимость в чтении с диска возникает, вряд ли эти данные могут оказаться в кэше LUN. Данные, которые кэшируются SQL Server, также кэшируются на уровне SAN, так что кэширование на уровне LUN может дать лишь незаметное преимущество. Когда SQL Server запрашивает данные с диска, SAN будет пытаться выполнить упреждающее чтение, чтобы для следующего запроса на чтение побыстрее предоставить данные, не обращаясь к физическому диску. Но из-за того, что в базах данных OLTP запрос блоков носит случайный, а не последовательный характер, шансы на то, что SAN угадает, какие данные потребуются при следующем запросе, очень невелики, и выигрыш от упреждающего чтения стремится к нулю. В системах OLTP, где диск уже обрабатывает запросы, включение кэша чтения может незначительно влиять на производительность; если диск не используется, кэш чтения также не влияет на производительность.
На уровне диска важным элементом настройки системы хранения является корректное выравнивание (aligning) диска. В те времена, когда разрабатывались спецификации главной загрузочной записи (Master Boot Record, MBR), стоимость дисков была значительно выше, чем сейчас. Поэтому MBR была настроена так, чтобы занимать 63 блока на диске, а данные начинаются только с 64-го блока. Такая настройка создает определенные проблемы, так как дисковые операции оптимальны для 64-блочных записей. При смещении данных на один блок операция чтения/записи 64-блочной структуры в действительности требует выполнения 2 операций. Для приложений типа Microsoft Exchange или Oracle ASM дисковые операции используют 8-Кбайт (8-блочные) структуры, и дополнительные операции не оказывают значительного воздействия. Но SQL Server использует страницы 64 Кбайт (64 блока) для чтения и записи. И неправильное выравнивание диска приводит к тому, что при каждой операции чтения/записи вместо одной операции выполняется две.
Эту проблему относительно просто решить с помощью утилиты DISKPART.EXE, которая входит в состав Windows Server 2008 и Windows Server 2003. После того как логический том LUN подключен к серверу, выполните в командной строке команду DISKPART.EXE и в ответ на приглашение введите команду:
SELECT DISK 3
где 3 обозначает номер только что подключенного диска. Затем выполните команду
CREATE PARTITION PRIMARY ALIGN=64
которая создаст на диске основной раздел с выравниванием на 64-й блок физического диска, а не на 63-й (по умолчанию). Далее эти же операции следует выполнить для всех номеров LUN, подключенных к серверу.
Если у вас уже имеются LUN, которые не были корректно выровнены, ситуация осложняется, поскольку выравнивание раздела нельзя выполнить, если раздел уже создан. В этом случае проще всего выполнить резервное копирование базы, удалить раздел и создать его вновь с правильным выравниванием, а после этого восстановить базу на диск из резервной копии. Некоторые производители SAN предлагают собственные средства миграции, доступны также инструменты сторонних разработчиков. Мы не советуем использовать их, так как часто эти средства выполняют полное копирование информации, включая неправильное выравнивание.
Совместное использование — все или ничего
Существует два основных подхода к настройке системы хранения — общий доступ ко всем ресурсам и никакого доступа. Общий доступ ко всем ресурсам выглядит так: все диски SAN могут использоваться каждым LUN. И хотя это кажется удобным, такой подход имеет свои недостатки. При замедлении одного из дисков в массиве происходит замедление всех LUN массива. Поэтому предоставление полного общего доступа оправданно только в том случае, если у вас нет нормального администратора SAN.
При втором подходе — никакого совместного доступа (хотя правильнее говорить об избирательном доступе), LUN создаются для небольших групп RAID на SAN. Небольшие группы физических дисков выделяются в группы RAID, и LUN присваиваются этим группам RAID. Благодаря такому подходу если один из LUN или дисков начинает замедляться, то снижение производительности затрагивает только этот LUN в пределах данной группы RAID. Такой подход требует больше внимания, трудоемких детальных настроек, больше знаний об операциях ввода-вывода и параметров настройки и сопровождения. Зато благодаря этому при необходимости обеспечить большую пропускную способность вы можете перейти на другую группу RAID или подключить дополнительные группы RAID для предоставления большей пропускной способности.
SAN или DAS — что выбрать
На сегодня основной технологией систем хранения является SAN. SAN обеспечивает очень высокую скорость работы и может содержать сотни накопителей, которые подключаются к серверам высокоскоростными соединениями Fibre Channel. Но решения SAN очень дорогостоящие, цены часто начинаются с сотен тысяч долларов. Более приемлемой альтернативой являются системы DAS, которые могут оказаться оптимальным решением, если большое хранилище SAN не требуется. DAS предоставляет почти те же функции, что и SAN, но в несколько меньшем масштабе и с меньшим объемом кэша. Устройства DAS могут содержать от 2 до 45 накопителей SCSI, SAS или SATA с размером кэша от нескольких мегабайтов до гигабайта.
Для DAS годятся все настройки, которые были рекомендованы для SAN, в том числе балансировка кэша чтения/записи. Как и для SAN, накопители DAS нуждаются в выравнивании (как, впрочем, и любые другие массивы RAID). В отличие от SAN, DAS, как правило, не позволяет управлять кэшированием на уровне отдельных дисков. Кроме того, системы DAS подключаются к определенному серверу, так что вы не сможете подключить к DAS несколько серверов, и это самое существенное отличие от SAN.
Самым главным ограничением использования DAS является невозможность наращивания, так как в DAS можно подключить только определенное количество дисков, к тому же при использовании DAS невозможно организовать общий пул ресурсов для группы серверов. Еще одно ограничение — невозможно расширить массив RAID на большее число дисков, чем может быть размещено в одной полке накопителей. В большинстве DAS полка может вмещать 15 дисков, при этом каждая полка обслуживается собственным контроллером RAID. Поскольку контроллеры RAID не взаимодействуют друг с другом, диски одного RAID могут размещаться только на одной полке. Но всеми этими ограничениями можно пренебречь, если принять во внимание стоимость. Системы хранения DAS стоят существенно меньше, чем самые доступные решения SAN.
Использование iSCSI для баз данных
Нельзя не упомянуть об iSCSI как о новой технологии хранения для баз данных. iSCSI позволяет использовать обычные сети Ethernet для подключения баз данных к системам хранения. Многие производители SAN предлагают интерфейс iSCSI в своих решениях SAN. Преимущество iSCSI заключается в том, что вы можете организовать систему хранения класса SAN без дополнительных затрат на дорогостоящее оборудование Fiber Channel. Недостаток этого подхода заключается в том, что обмен сервера баз данных с системой хранения идет по общей сети Ethernet и конкурирует с остальным трафиком за полосу пропускания сети. Если ваша сеть Ethernet недостаточно быстрая, скорее всего, не стоит рассчитывать на решения iSCSI. Еще одна потенциальная проблема при использовании iSCSI состоит в том, что, поскольку трафик обмена с системой хранения идет по сети TCP, необходимо учитывать настройки тайм-аутов для TCP. Если по каким-то причинам массив хранения вдруг даст сбой, Fibre Channel отреагирует очень быстро и сможет переключиться на другой маршрут. А тайм-ауты для TCP значительно больше, так что база данных может оказаться заблокированной или произойдет сбой по тайм-ауту процесса.
Для устранения ограничений пропускной способности сети можно использовать виртуальные локальные сети VLAN для разграничения и изоляции трафика сети iSCSI от общей сети. Такая изоляция обеспечивает логическое разделение сети на сегменты VLAN на уровне 2 базовой модели OSI. VLAN представляет собой логический домен в рамках сетевого коммутатора, который обеспечивает разграничение трафика. Весь трафик VLAN, включая широковещательные запросы, не выходит за пределы данной VLAN. Если часть трафика из данной VLAN должна быть направлена в другую VLAN, она маршрутизируется. Такой подход позволяет полностью разграничить трафик iSCSI и общий, не связанный с iSCSI трафик. VLAN организовывается на уровне 2 и разделяет трафик только на этом уровне. Для дальнейшего разграничения трафика на уровне 3 коммутации и маршрутизации сети VLAN могут быть ассоциированы с подсетями маршрутизации, которые позволяют выпускать трафик из домена VLAN для сообщения с другими сетями VLAN. Более того, уровень 3 маршрутизации позволяет настроить списки контроля доступа ACL для разрешения или запрета определенного трафика в отдельных подсетях. Дополнительные возможности управления доступны также на уровне 4 и уровне 5, но их обсуждение уже выходит за рамки данной статьи.
Настройте SQL Server на максимальную производительность
Правильное планирование и настройка физических дисков имеет очень большое значение для повышения производительности сервера. Если же речь идет об SQL Server (или любом другом сервере баз данных), то это является критически важным фактором, поскольку серверы баз данных выполняют операции чтения/записи значительно большего объема и более интенсивно, чем большинство других корпоративных приложений и серверов. Поэтому к планированию и настройке системы хранения для базы данных следует подходить особенно внимательно, особенно если учесть, что переделка потребует значительно больше времени и усилий.
Денни Черри (dcherry@awarenesstech.com) — старший администратор баз данных и архитектор в компании Awareness Technologies. Имеет несколько сертификатов Microsoft и звание Microsoft MVP
Таблица 1. Определение числа записей базы данных на странице
Таблица 2. Вычисление страниц данных, добавляемых за день
Таблица 3. Определение дискового пространства, занимаемого за день
Таблица 4. Общий объем данных за планируемый период
Рисунок. Физическое размещение наборов на дисках в массивах RAID 5 и RAID 10