Какую схему raid лучше использовать для хранения данных севера ms sql и почему
Достопочтенные гуру-админы 1С, поделитесь опытом, какую модель RAID правильно будет использовать на сервере 1С ?
Планируется перенос базы с обычного компьютера без RAID, на нём сейчас стоят два SSD накопителя и один хард HDD, на одном SSD установлен Win2016+1C Server 8.3+MS SQL 2017, на другом SSD развернуты базы SQL, ну и на хард производятся регулярные бэкапы через настроенные "Планы Обслуживания" на СУБД.
На период внедрения 1С такая схема устраивала, пользователей было не много,( их и сейчас не сильно больше стало), простой и восстановление из бэкапов представлялись допустимыми издержками.
Но сейчас перспектива неожиданного выхода из строя одного из дисков стала беспокоить больше, база выросла и выросла значимость этих данных, терять время на восстановление из бэкапов уже не очень устраивает.
Короче говоря будут заказывать серверную машину с рейд контроллером, под диски должно быть минимум 6 посадочных мест, а может и 8.
Как на ваш взгляд следовало бы распределить и настроить массив? Сделать 2 отдельных RAID 5 массива по 3 накопителя в каждом, итого 6 шт. дисков, также поставить WinOS+СУБД+1С Сервер на один RAID 5 массив, а на другом развернуть базы SQL ? Либо какой-то иной подход нужен? Поделитесь пожалуйста опытом, какую схему вы используете ?
В случае NVMe дисков восстановление из бэкапа занимает минимум времени.
Ну сделай для баз зеркало из пары SSD и все
Есть RAID или нет его, один фиг бекапы надо делать часто. Чем чаще, тем лучше.
Для меня оптимальный вариант рейда - зеркало.
(2) многие модель восстановления делают simple, а архивы ночью. Представляешь сколько времени займет восстановление документов за весь день?
(1) Ну, 5-й вроде как самый простой и оптимальный вариант по расходу на количество дисков и восстановления (отказоустойчивости). В зеркале RAID 1 нужен такого же размера диск, в RAID 5, на все три диска будет запись. Блоки данных и контрольные суммы записываются циклически на все диски массива.
(3) С этим спору нет, бэкапы не обсуждается, просто когда дохнет диск, то нужен человек, который побежит туда, вскроет компьютер, заменит дохлый на новый и восстановит базу с бэкапа.
А рейд просто всё сделает сам и физически один из дисков можно будет заменить при первой возможности.
Еще если сдохнет диск на котором ОСь стоит и СУБД, так это еще придется заново поднимать, переустанавливать.
(3) Какое зеркало, просто RAID 1 ? RAID 10 ?
Как распределяете ОСь СУБД 1С, базы ? Всё на одном, зеркальном массиве из двух и более дисков? Или 2 диска-зеркала для ОСи и установленных приложений и отдельный зеркальный массив для данных ?
мне кажется raid 1 (зеркало) из двух SSD более чем достаточно, для любой типовой, лучше деньги остальные потратить на резервные харды такие же,
вероятность что сразу сдохнут оба харда крайне мала, ну и про бэкапы не забываем
1. Под базы стоит забыть про рейды отличные от 1 и 10. Я бы 1 рейд собрал под систему и tmpdb или индексы. И 10 или 1 под данные базы.
2. Бекапы в любом случае нужно делать, на случай, если кто-то что-то случайно удалит.
(16): 1 - это резервирование в зеркало, 2/1 устойчивости к поломке. для системника, который и не так часто меняет свое критическое содержимое, и если рухнет - поднять из бэкапа проще но надо быстро - лучше 0 ставить (чередование, двойная скорость без резервирования) - тем паче, что и темпдб тоже в скорости нуждается а при разрушении достаточно перезапустит sql-сервер.
ну и под базы голая единица - наверное, все-таки. медленновато. если финансовый ресурс позволит - все-таки, наверное. лучще 10 (та же единица но скорость вдвое выше).
нэ?
(17) Вообще надо отметить, что из бэкапа на СУБД база довольно быстро поднимается, особенно на SSD, проводил эксперимент, но правда размер был тогда не большой, около 3гб примерно наверное, может и меньше.
По-большому счёту, если через Планы Обслуживания создаются ежедневные бэкапы, а они у меня настроены и создаются, с предварительной проверкой на целостность, индексирование, очистку кеша, вообщем по-букварю настраивал в свое время, то вроде бы и ничего страшного нет, если сдохнет диск с бэкапами, можно просто за несколько минут поднять базу с бэкапа.
Но вот системный диск с ОСью и установленными на этот же диск MS SQL+1C Сервером у меня вообще никак не бэкапится, то есть если этот диск сдохнет и система упадет, то придется все поднимать с нуля на чистый диск ставить и ОСь и СУБД и 1С сервер. Видимо нужно какие-то снэпшоты делать системного диска, хотя бы раз в неделю, чтобы в случае чего можно было восстановиться с этого образа с случае чего.
У вас сейчас оптимальная схема и есть: обычный комп, 2 SSD и HDD для быкапов. Если перенесете на труЪ-сервер с аппаратным RAID-контроллером, готовьтесь к значительному снижению производительности! ИМХО, не стоит. RAID'ы для SSD неактуальны, в них нет движущихся частей.
>>Но вот системный диск с ОСью и установленными на этот же диск MS SQL+1C Сервером у меня вообще никак не бэкапится,
Поставьте бесплатный Veeam Agent и быкапьте диск С куда-нибудь. Восстановление из такого образа идет быстро.
(11) Как вариант - зеркало из двух _разных_ ssd (имеется в виду чип контроллера) - они вряд ли выйдут из строя одновременно.
(22) А мне интересно, проводил ли кто-то эксперименты на скорость, сравнение одиночного ссд и райд10 из таких же?
+(23) И дополнительно, чтобы избежать влияние райд-контроллера - массив должен быть создан средствами винды
Я понимаю, что я не совсем корректные примеры и видео привожу. Но тенденция примерно такая.
Для себя я сдела вывод - либо простые ssd диски в первый рейд, либо nvme.
(17) Я ориентирован строить надежные системы, которые могут работать без простоя. Лучше уже совсем не ставить рейд под систему чем 0. Если 1-й рейд может выдержать поломку 1-го диска, то 0 выйдет из строя при поломке 1-го из двух. То есть 0 рейд повышает веротяность потери данных в 2 раза по сравнению с диском без рейда.
(22) Глупости. 10 рейд почти в 2 раза быстрее чем 1
(27) если говорим о шпинделях - однозначно. Если говорим о SSD, то не так все однозначно. Я не даром про скорость в (22) ничего не написал. Я написал "Смыcла в 10 рейде нет".
(18) //Но вот системный диск с ОСью и установленными на этот же диск MS SQL+1C Сервером у меня вообще никак не бэкапится,
Разверни на виртуалке. Я бы ещё на разные установил.
(31) На этапе внедрения рассматривал такой вариант, в первую очередь именно из-за простоты и удобства восстановления в случаях сбоя и потери данных, виртуальную систему из гипервизора конечно же и бэкапить легко и поднимать. Но честно говоря не решился с гипервизором связываться, железо не достаточно производительное было, старый i5, второго поколения, ну и в частности в плане эффективности разворачивания и работы 1С сервера приложений в виртуальной среде мнения не такие однозначные, довольно много на этот счёт неодобрительных высказываний и статей, немало противников такой модели работы, вроде как-бы производительность теряется и прочее.
(33) Я не сомневаюсь в общем-то, просто как я уже сказал, железо было не особо пригодное для экспериментов, не хотелось разочаровываться, скорее всего производительность не обрадовала бы, а так с приличным железом надо попробовать конечно.
Системный raid1 на ssd и raid1 под базу на NVME. Raid на NVME можно создать с помощью ключа VROC через UEFI (у этих ключей 3 ценника - самый дешевый raid 0-1-10, но только под Intel диски, второй около 10 тыс. - поддержка других производителей, третий - за 20 тыс. добавляется raid5), единственно, что приходится каждый процессор настраивать на UEFI и перенастраивать слоты PCI-E, в которые установлены NVME -платы. А так, когда настраиваешь в биосе UEFI, в биосе появляется возможность управления рейд-массивами, безо всяких Ctrl-A, и настроек визуально больше. Соответственно весь временный контент 1с пишется на системный raid, на NVME - только базы, индексы. Производительность - примерно раз в 5 быстрее, чем на SAS 10.
(0) Обычно делаю следующую схему.
Под ОС - RAID 1
Под данные RAID 10.
Итого 6 дисков минимум.
В идеале, еще RAID 1 под tempdb.
Аппаратные сбои были, но система работала. Заменяешь сломавшийся диск на новый. Несколько часов тормозов пока идет синхронизация, а затем все нормально.
(39)///Аппаратные сбои были, но система работала. Заменяешь сломавшийся диск на новый. Несколько часов тормозов пока идет синхронизация, а затем все нормально.
Да, понимаю вас, спасибо за комментарий, я вот тоже так хотел бы в идеале, чтобы спокойно спать. Чтобы на сбой сломя голову не реагировать, а чтобы всё в массиве подтянулось откуда нужно, а потом в спокойном режиме менять сдохший диск.
(38)
SEQ1M Q8T1 read 5286 write 1954
SEQ1M Q1T1 read 2371 write 181
RND4K Q32T16 read 578 write 682
RND4K Q1T1 read 38 write 94
При установке и настройке нового сервера 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, где диск уже обрабатывает запросы, включение кэша чтения может незначительно влиять на производительность; если диск не используется, кэш чтения также не влияет на производительность.
Эту проблему относительно просто решить с помощью утилиты DISKPART.EXE, которая входит в состав Windows Server 2008 и Windows Server 2003. После того как логический том LUN подключен к серверу, выполните в командной строке команду DISKPART.EXE и в ответ на приглашение введите команду:
где 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 значительно больше, так что база данных может оказаться заблокированной или произойдет сбой по тайм-ауту процесса.
Настройте SQL Server на максимальную производительность
Правильное планирование и настройка физических дисков имеет очень большое значение для повышения производительности сервера. Если же речь идет об SQL Server (или любом другом сервере баз данных), то это является критически важным фактором, поскольку серверы баз данных выполняют операции чтения/записи значительно большего объема и более интенсивно, чем большинство других корпоративных приложений и серверов. Поэтому к планированию и настройке системы хранения для базы данных следует подходить особенно внимательно, особенно если учесть, что переделка потребует значительно больше времени и усилий.
Несомненно, хранилище данных - один из основных компонентов, определяющих производительность и доступность больших и малых экземпляров SQL Server. В условиях возросших вычислительных возможностей серверов и виртуальных серверов и поддержки объемной памяти хранилища данных и подсистема ввода-вывода могут оказаться узкими местами, снижающими общую пропускную способность
Which RAID Level to Use With SQL Server?
But which level or approach is most suitable for your SQL environment? Suprotim Agarwal explains:
The answer to which RAID level to use with SQL Server depends on a variety of factors. Do you want availability, performance or cost? What are your requirements for fault tolerance and performance? …When it comes to a database like SQL Server, no one RAID level will suit your need.
In weighing the decision, you should consider the number of write and read options. RAID 10, for example, would be a good option for those databases with more write operations. Other factors include the other files being stored, including database transaction log files and backup and recovery files. You will also need to consider the possibility more storage might be needed to implement a new storage or backup strategy and the potential costs associated with it.
Data striping (RAID 0) is the RAID configuration with the highest performance, but if one disk fails, all the data on the stripe set becomes inaccessible. A common installation technique for relational database management systems is to configure the database on a RAID 0 drive and then place the transaction log on a mirrored drive (RAID 1). You can get the best disk I/O performance for the database and maintain data recoverability (assuming you perform regular database backups) through a mirrored transaction log.
For any data that has to be rapidly recoverable, RAID 5 is the better option. This level of RAID gives users full redundancy of all the data on the array. This is useful if a single disk happens to fail. The disk can be easily replaced, most often, without any system downtime. Although it does not have the same performance as RAID 0 or RAID 1, using RAID 5 does provide users with higher reliability and faster recovery.
Microsoft explains each RAID level in detail on the TechNet page.
If you need help with performance tuning or reconfiguring your SQL Server storage, please feel free to contact Datavail to discuss a custom solution designed for your enterprise. You can learn more about our remote database services and how our experts can help with your ongoing SharePoint operations. For more solutions to common and advanced database related questions, head over to Datavail’s frequently updated blog.
На этот сервер планируется перенести ещё одну базу размером 38 ГБ, рост базы в год на 3-5 ГБ
Пока на сервере работает 2 пользователя, после переноса БД будет работать 17-20 пользователей.
В связи с грядущим переносом БД имеет ли смысл из имеющихся 4-ёх дисков сделать RAID-10 вместо RAID-6, будет ли прирост производительности?
Iwan777
Если есть возможность, купите пару SSD дисков в зеркало под базы.
Если речь про 4-е диска, то у вас перекос в сторону Раид6. Фактически сейчас работают только 2-а диска, 2-а других под контроль четности. Если переделаете в Р10, то будут работать все 4-е. Но при таком планируемом кол-ве народу и таком размере базы можете получить тормоза. В случае SSD вероятной проблемы не было бы.
На текущий момент приобрести SSD нет возможности.
Получается, что при использовании имеющегося железа, если оставить RAID-6, то будет совсем печально, а при переходе на RAID-10 производительность дисковой подсистемы должна подрасти?
Iwan777 писал(а): Получается, что при использовании имеющегося железа, если оставить RAID-6, то будет совсем печально, а при переходе на RAID-10 производительность дисковой подсистемы должна подрасти?
Тут надо смотреть по месту, возможно Р5 будет лучше. На на 20 человек с базой в 40ГБ дисков маловато.
П.С. Интел 3510 на 100ГБ стоит не таких уж и больших денег. Пары дисков вам бы хватило.
Спасибо!
Сначала попробуем на RAID-10 перейти, посмотрим как будет работать, и по результатам определимся с приобретением SSD.
Stranger03
Уже имеет смысл смотреть на Intel S3520.
Цена такая же, как у S3510, а ресурс записи намного выше.
Tert писал(а): Уже имеет смысл смотреть на Intel S3520.
Цена такая же, как у S3510, а ресурс записи намного выше.
Хм-ммм.
Stranger03 писал(а): Iwan777
Если есть возможность, купите пару SSD дисков в зеркало под базы.
Если речь про 4-е диска, то у вас перекос в сторону Раид6. Фактически сейчас работают только 2-а диска , 2-а других под контроль четности. Если переделаете в Р10, то будут работать все 4-е.
М-ммм. Геннадий, некоторую неточность вижу здесь я.
В R6 же диски под чётность не выделенные, как в R2, R3 или R4 - и Ваше "2-а других под контроль чётности" должно быть переформулировано иначе: что для этой богоугодной цели из всего массива выделяется ("крадётся" у данных) объём, эквивалентный объёму двух дисков (а не два конкретных диска как физ.устройства), по которым и блоки данных, и блоки с КС "размазываются равномерно. Соответственно, в R6 "фактически работают" все диски (здесь - все 4), т.к. блоки данных читаются-пишуться с/на всех дисках R6-го.
Да, WP у R6 естественным образом больше, чем у R10-го, но это, как Вы не хуже меня знаете, не из-за к-ва дисков.
Ну а по чтению имеющийся R6 из 4-х дисков не должен уступать R10 из тех же 4-х дисков - по вышеуказанным причинам.
Stranger03 писал(а): Но при таком планируемом кол-ве народу и таком размере базы можете получить тормоза. В случае SSD вероятной проблемы не было бы.
Базовые уровни производительности
Другой основной подход — подготовить базовые уровни производительности и периодически сравнивать системную производительность с этими базовыми уровнями. Это может быть очень полезным для диагностики неполадок, а также отслеживания роста базы данных и других тенденций. Сопоставление с базовым уровнем — один из лучших способов упреждающего управления системами. Тема измерения производительности SQL Server выходит за рамки данной статьи, но ниже приводится обзор важнейших измеряемых показателей хранилищ данных.
Первая группа счетчиков производительности, которые необходимо отслеживать, представляет собой счетчики, относящиеся к памяти в системном мониторе Windows. Технически это не счетчики хранилища данных, но если памяти недостаточно, то остальные счетчики не имеют значения. Обязательно отслеживайте счетчик Available MBytes объекта Memory. Этот счетчик показывает объем физической памяти, доступной для выделения процессу или системе. Если показатель меньше 100 Мбайт, то полезно увеличить размер памяти. Другой важный счетчик — % Usage объекта Paging File, который показывает используемый объем файла подкачки Windows. Это значение должно быть менее 70%. Если значение выше, то, вероятно, системе требуется больше памяти.
Помимо счетчиков, связанных с памятью Windows, имеется несколько счетчиков производительности хранилища Windows Server. Однако показания этих счетчиков полезны лишь в том случае, если экземпляр SQL Server работает с системой хранения данных с прямым подключением DAS. Если используется SAN, то нужно обращать внимание на метрики производительности SAN.
Если экземпляр SQL Server использует DAS, то в первую очередь убедитесь, что на каждом диске NTFS свободно по крайней мере 20% пространства. Впоследствии можно проверить счетчики хранилища Windows Server с помощью системного монитора. В таблице 1 приведен список нескольких наиболее важных счетчиков; все они связаны с объектом Logical Disk.
SQL Server располагает многочисленными счетчиками производительности, которые помогают управлять экземпляром SQL Server. Некоторые наиболее важные счетчики хранилища SQL Server, показания которых полезно отслеживать, перечислены в таблице 2. Следить за ними можно с помощью системного монитора.
Обеспечиваем доступность и производительность хранилищ данных
Несомненно, хранилище данных — один из основных компонентов, определяющих производительность и доступность больших и малых экземпляров SQL Server. В условиях возросших вычислительных возможностей серверов и виртуальных серверов и поддержки объемной памяти хранилища данных и подсистема ввода-вывода могут оказаться узкими местами, снижающими общую пропускную способность. Неприятностей можно избежать, если иметь общее представление о том, как SQL Server использует хранилища данных, и знать основные приемы оптимальной организации хранилищ SQL Server.
Обеспечиваем доступность и производительность хранилищ данных
Несомненно, хранилище данных — один из основных компонентов, определяющих производительность и доступность больших и малых экземпляров SQL Server. В условиях возросших вычислительных возможностей серверов и виртуальных серверов и поддержки объемной памяти хранилища данных и подсистема ввода-вывода могут оказаться узкими местами, снижающими общую пропускную способность. Неприятностей можно избежать, если иметь общее представление о том, как SQL Server использует хранилища данных, и знать основные приемы оптимальной организации хранилищ SQL Server.
Сохраняем и движемся вперед
Хранилище — высококритичный компонент в производительности базы данных SQL Server. Знание некоторых простых приемов поможет оптимизировать доступность и производительность SQL Server. Более подробные сведения об особенностях хранения данных можно найти в материалах, перечисленных во врезке «Учебная литература».
Учебная литература
Листинг 1. Перенос файла данных базы данных в другое место
Листинг 2. Программный код для определения размера и процента роста файлов данных и журналов tempdb
Although many database administrators don’t consider hardware infrastructure as part of database operations, storage configuration absolutely can impinge upon database performance. The storage options you’re using in association with SQL Server may be affecting its performance. This is particularly possible if you are using a redundant array of independent disks or RAID—a disk system that contains multiple disk drives.
Why Use RAID With SQL Server?
RAID systems are typically used in conjunction with read-write intensive applications to achieve better performance in light of the frequency of I/O operations that are an inherent function of these types of applications. The RAID array used in conjunction with SQL needs to be carefully considered.
There are many RAID arrays available, and each of the six levels uses a different algorithm for fault tolerance. Most often, RAID 0, RAID 1, and RAID 5 are used with SQL Server.
- RAID Level 0 is known as disk striping. RAID 0 uses a disk file system known as a stripe set. The data is divided into blocks and spread among all the disks in an array. Operations are also spread across disks, improving performance, since many operations can be performed both independently and at the same time.
- RAID Level 1 is referred to as disk mirroring. RAID 1 provides a redundant, identical copy of a selected disk. All data written to the main disk in the array is also written to the mirror disk. Microsoft notes that, although RAID Level 1 does provide fault tolerance and generally improves read performance, the write performance may be degraded.
- RAID Level 5 is most frequently used in SQL Server. RAID 5 is known as striping with parity, as the data is “striped” in large blocks across the disks in the array. The parity is also written across all the discs, which also means the data is redundant. Microsoft explains that the data and parity information are arranged such that they are always on different disks. Although the performance is better with RAID 5, it is not perfect. If, notes Microsoft, “a stripe member is missing, read performance is decreased, for example, when a disk fails.”
Данные и файлы журналов
Базовый принцип, который лежит в основе работы SQL Server с хранилищами данных, заключается в том, что базы данных состоят из файлов двух типов:
- Файлы данных. В этих файлах хранится информация базы данных. Файлы данных SQL Server представляют собой файлы NTFS с расширением. mdf. Простейшая база данных обычно состоит из одного файла данных, но может состоять и из многих файлов данных, находящихся на одном или нескольких дисках.
- Файлы журналов. В этих файлах хранятся транзакции базы данных, что позволяет восстановить базу данных на определенный момент времени. Файлы журналов транзакций SQL Server представляют собой файлы NTFS с расширением. ldf. В базе данных может быть много файлов журналов, расположенных на одном или нескольких дисках.
Если для создания базы данных используется среда SQL Server Management Studio (SSMS), то файлы данных и журналов хранятся на том же диске по умолчанию. Если не указано иное, то файлы данных и журналов создаются в том же каталоге, что и системные базы данных SQL Server, то есть :\Program Files\Microsoft SQL Server\MSSQL.MSSQLSERVER\MSSQL\DATA. Например, для экземпляра SQL Server 2014, установленного на диске C, файлы данных и журналов по умолчанию будут находиться в каталоге C:\Program Files\Microsoft SQL Server\MSSQL12.MSSQLSERVER\MSSQL\DATA.
Рекомендуется поместить файлы данных и журналов на различные диски. SQL Server записывает все транзакции базы данных в журнал транзакций, поэтому файлы журналов удобно располагать на дисках с высокой скоростью записи. Файлы данных используются для обслуживания запросов и часто должны выполнять множество операций чтения. При создании базы данных можно указать местоположение файлов данных и журналов с помощью команды T-SQL CREATE DATABASE. Чтобы изменить местонахождение существующих файлов данных и журналов, можно запустить команду ALTER DATABASE с параметром MODIFY FILE. В листинге 1 показан пример переноса файла данных базы данных в другое место.
Не все согласятся с рекомендацией включить режим AutoGrow для баз данных SQL Server. При включении этой функции для базы данных файлы данных и журналов автоматически увеличиваются, если требуется больше места. Этот параметр не допускает остановки системы, если места не хватает.
И все же AutoGrow следует рассматривать как механизм последнего рубежа защиты. Его не следует использовать в качестве основного метода управления ростом базы данных. Ростом всех файлов данных и журналов следует управлять вручную. Активность базы данных прекращается, когда происходят операции AutoGrow. Частые события AutoGrow — хороший индикатор непредвиденного роста данных. Следующая команда показывает, как установить настройку AutoGrow для файлов данных и журналов:
Почти никогда не рекомендуется активировать функцию AutoShrink для базы данных. Как и операции AutoGrow, операции AutoShrink приводят к остановке всех действий базы данных. Кроме того, администратор не может контролировать время запуска AutoShrink. Использование AutoShrink может привести к спирали операций AutoGrow, а затем AutoShrink, а результатом будет снижение производительности базы данных и чрезмерная фрагментация файлов. Запустить AutoShrink можно с помощью команды:
Еще один полезный прием при работе с хранилищами данных — немедленная инициализация файлов Instant File Initiation. В отличие от большинства рассмотренных в статье параметров, Instant File Initialization управляется политикой Windows Server. Instant File Initialization не обнуляет выделенное пространство для файла, а просто выделяет нужное количество места. SQL Server использует Instant File Initialization во время создания базы данных, AutoGrow и операции восстановления базы данных. Можно включить режим Instant File Initialization на сервере через меню Administrative, чтобы открыть Local Security Policy («Локальная политика безопасности»). Затем разверните Local Policies («Локальные политики») и дважды щелкните на пункте Performance volume maintenance tasks, как показано на экране.
Экран. Включение Instant File Initialization |
В результате открывается диалоговое окно свойств Properties для Performance volume maintenance tasks («Выполнение задач по обслуживанию томов»), в котором можно ввести имя учетной записи SQL Server Service.
Твердотельные диски
Благодаря нескольким ядрам увеличилась вычислительная мощь, и многие современные системы поддерживают очень большой объем оперативной памяти, из-за чего подсистема ввода-вывода стала узким местом для многих рабочих нагрузок. Традиционные жесткие диски стали более емкими, но быстродействие практически не увеличилось. Проблему можно решить с помощью твердотельных дисков (SSD). Твердотельные диски — сравнительно новая технология хранения данных, которая начала набирать вес на рынке SQL Server в течение последнего года. В прошлом цена устройств SSD была слишком велика, а информационная емкость слишком мала для многих рабочих баз данных. Одна из причин растущей популярности твердотельных дисков — преимущество в производительности перед традиционными жесткими дисками с вращающимся шпинделем. Например, диск Serial Attached SCSI (SAS) с частотой вращения шпинделя 15 000 об/мин может обеспечить пропускную способность 200 Мбайт/с. Для сравнения, SSD-диск Serial ATA (SATA) с 6-Гбайт соединением может обеспечить последовательную пропускную способность около 550 Мбайт/с. Основная причина превосходства SSD-дисков в быстродействии заключается в резком сокращении времени поиска. Когда нужно получить данные с вращающегося жесткого диска, головка должна переместиться в новое место. У SSD-диска нет движущихся частей, поэтому перемещение к новому месту хранения данных определяется быстродействием ячеек памяти.
Твердотельные и быстродействующие флэш-хранилища можно реализовать несколькими способами. Типичное применение — 2,5-дюймовые диски SSD. Эти устройства подключаются напрямую, как хранилища типа DAS, а электронный интерфейс — такой же, как у стандартного жесткого диска. Другая распространенная реализация SSD — в виде плат PCI Express (PCIe), подключаемых непосредственно к системной шине. В этом подходе используются преимущества быстродействующей шины PCIe, чтобы повысить число операций ввода-вывода в секунду (IOPS) и пропускную способность по сравнению со стандартным интерфейсом диска. Кроме того, многие хранилища SAN располагают разделами SSD и функцией автоматического распределения данных по разделам, что позволяет переместить важные рабочие нагрузки на высокопроизводительный раздел SSD, оставляя менее важные рабочие нагрузки на медленных и менее дорогостоящих жестких дисках.
Существуют хранилища SSD различных типов. Среди них — хранилище SSD на основе DRAM и хранилище SSD на основе технологии флэш-памяти, такой как одноуровневые ячейки (SLC) и многоуровневые ячейки (MLC). У каждого типа есть свои достоинства и недостатки.
- DRAM. Как обычная оперативная память для компьютера, DRAM отличается очень высоким быстродействием, но ненадежна. Для DRAM требуется постоянный элемент питания, чтобы сохранить данные на время отключения данных. Такие хранилища часто выпускаются в виде плат PCIe, устанавливаемых на системной плате сервера.
- SLC. Быстродействие и жизненный цикл хранилищ на SLC выше, чем у MLC, поэтому SLC используется в хранилищах SSD корпоративного уровня. Однако цена устройств SLC существенно выше, чем у MLC.
- MLC. Обычно флэш-память типа MLC используется в потребительских устройствах и обходится дешевле, чем SLC. Однако у MLC более низкая скорость операций записи и существенно более высокий износ, чем у SLC.
По быстродействию устройства SSD превосходят жесткие диски с вращающимся шпинделем, но срок их эксплуатации значительно ниже. Приложения с интенсивным вводом-выводом, такие как SQL Server, сокращают срок жизни накопителя SSD. Кроме того, чем больше используемая часть диска, тем меньше продолжительность жизни. Рекомендуется убедиться, что по крайней мере 20% накопителя SSD не занято. Скорость чтения стабильна в течение всего времени эксплуатации устройства. Однако быстродействие при записи в процессе эксплуатации ухудшается, то есть время, необходимое для записи, увеличивается. Важно также помнить, что нет необходимости дефрагментировать диски SSD, потому что метод доступа к данным иной, чем у жестких дисков. В сущности, дефрагментация этого типа дисков приведет только к сокращению их жизненного цикла.
Если нужно использовать диски SSD, не применяйте единственный накопитель SSD и приготовьтесь заменять диски SSD в течение срока эксплуатации сервера. Перечислим возможности применения SSD в SQL Server.
- Перемещение индексов на диски SSD. Как правило, индексы не очень велики и связаны с интенсивными беспорядочными операциями чтения, поэтому идеально подходят для размещения на дисках SSD.
- Перемещение файлов данных на диски SSD. С файлами данных обычно связано больше операций чтения, чем записи, поэтому в большинстве случаев они подходят для дисков SSD.
- Перемещение файлов журналов на диски SSD. Файлы журналов связаны с большим числом операций записи. Поэтому если для файлов журналов применяются диски SSD, используйте диски SSD корпоративного уровня и конфигурации RAID 1 или RAID 10 с зеркальным отображением.
- Перемещение tempdb на SSD-диск. Как правило, tempdb отличается высоким уровнем неупорядоченных операций записи, что может привести к порче SSD. Поэтому если диски SSD используются для tempdb, то это должны быть SSD корпоративного уровня в конфигурации RAID 1 или RAID 10 с зеркальным отображением, и нужен план замены дисков SSD. Кроме того, обратите внимание на вариант с PCIe DRAM для tempdb. Хранилище DRAM обеспечивает более высокое быстродействие при записи и имеет неограниченный срок эксплуатации. Однако цены хранилищ DRAM могут быть высокими.
Хранение данных и уровни RAID
После того, как освоены хранилища SQL Server, можно приступать к изучению следующей важнейшей концепции — уровней RAID, которые можно использовать для дисков в подсистеме хранения данных. Уровни RAID сильно влияют как на производительность, так и на доступность. Как и следовало ожидать, более дорогостоящие варианты, как правило, обеспечивают лучшую производительность и доступность. Наиболее распространенные уровни RAID следующие:
- RAID 0 (иногда именуется чередованием дисков). На этом уровне RAID данные распределяются между всеми доступными дисками. Он часто используется в различных тестах производительности баз данных. RAID 0 обеспечивает хорошую производительность, но его никогда не следует применять на производственном сервере, так как отказ одного диска приводит к потере данных.
- RAID 1 (иногда именуется зеркальным отображением дисков). В конфигурации RAID 1 данные отображаются на дисках зеркально. Скорость операций чтения и записи хорошая, но общая емкость дисков уменьшается вдвое. RAID 1 часто используется для файлов журналов SQL Server. В случае отказа одного диска данные не теряются.
- RAID 5 (иногда именуется чередованием дисков с контролем четности). В конфигурации RAID 5 данные распределяются по нескольким дискам с целью обеспечить избыточность данных. Часто используется для файлов данных. Этот уровень RAID обеспечивает хорошую производительность чтения и устойчив к отказу одного диска. Однако скорость записи невелика.
- RAID 10 (иногда именуется зеркальным отображением дисков с чередованием). RAID 10 сочетает в себе быстродействие вариантов с чередованием и защиту через зеркальное отображение. RAID 10 обеспечивает самые высокие уровни производительности и доступности среди всех уровней RAID. Для RAID 10 требуется вдвое больше дисков, чем для RAID 5, но конфигурация устойчива к отказу нескольких дисков. Массив RAID 10 продолжает успешно функционировать при отказе половины дисков в наборе. RAID 10 подходит как для файлов данных, так и для журналов.
Tempdb
Еще один важный компонент системы хранения данных SQL Server — tempdb. Это системная база данных SQL Server, которая представляет собой глобальный ресурс, доступный всем пользователям. Tempdb используется для временных объектов пользователя и внутренних операций ядра системы управления базами данных, в том числе объединений, статистической обработки, курсоров, сортировки, хеширования и управления версиями строк. В отличие от данных в типичной пользовательской базе данных, данные в tempdb не сохраняются после отключения экземпляра SQL Server.
Как правило, tempdb — одна из самых активных баз данных в рабочем экземпляре SQL Server, поэтому следующие рекомендации помогут обеспечить хорошую производительность базы данных SQL Server. Прежде всего, файлы данных и журналов tempdb следует разместить на других физических дисках, нежели файлы журналов и данных рабочей базы данных. По причине очень активного использования tempdb полезно защитить диски, организовав массив RAID 1 или массив RAID 10 с чередованием. Специалисты группы Microsoft SQL Server Customer Advisory Team (SQLCAT) рекомендуют, чтобы в tempdb был один файл данных для каждого ядра процессора. Но эта рекомендация эффективна для очень высоких рабочих нагрузок. Чаще рекомендуется, чтобы отношение файлов данных к ядрам процессора составляло 1:2 или 1:4. Как и в большинстве случаев, это общие рекомендации; оптимальные подходы для конкретной системы могут различаться. Если вы не знаете точно, сколько файлов использовать для tempdb, можно начать с четырех файлов данных. Обычно для tempdb достаточно одного файла журнала. Более подробные рекомендации tempdb вы найдете в материалах, перечисленных во врезке «Учебная литература».
Кроме того, размер tempdb должен быть достаточным, чтобы избежать операций AutoGrow. Как и пользовательские базы данных, tempdb будет испытывать задержки из-за операций AutoGrow. По умолчанию tempdb содержит файл данных в 8 Мбайт, файл журналов в 1 Мбайт и 10% пространства для AutoGrow, а это слишком мало для большинства производственных рабочих нагрузок. Также важно помнить, что при перезапуске SQL Server размер tempdb возвращается к последнему заданному значению.
Размер и перемещения файлов данных и журналов tempdb можно определять с помощью программного кода, приведенного в разделе «Данные и файлы журналов». Запрос в листинге 2 (с сайта MSDN) показывает, как определить размер и процент роста файлов данных и журналов tempdb.
Читайте также: