Компания, в которой я работаю, рассматривает возможность обновления данных в базе данных, чтобы перейти от одной версии приложения к другой (Axapta 3 до Ax 2009). Этот процесс требует большого количества операций ввода-вывода и с нашей текущей настройкой займет несколько дней. В настоящее время у нас есть HP Lefthand SAN с 24 дисками по 450 ГБ 15 КБ. Мы запускаем SAN через iSCSI (2 x 1 ГБ), что ограничивает нас максимальной пропускной способностью около 100 МБ / с.
В настоящее время мы ищем способы повысить производительность ввода-вывода на время обновления. Сервер, на котором будет выполняться обновление, будет HP DL360 G7, который имеет 8 портов SAS и RAID-контроллер HP p410i.
Нам нужно всего около 400 ГБ места для данных и файлов журнала.
Мы думаем о том, чтобы добавить 8 SSD, разместить их на сервере и настроить массив RAID 10 только на выходные. Я читал, что производительность потребительских SSD ухудшается при выполнении большого количества операций записи. Поскольку нам нужно, чтобы это решение работало всего один уик-энд, стоит ли мне беспокоиться об этом, если мы приобретем твердотельные накопители потребительского уровня? Подойдут ли диски серии Intel X25-M или лучше выбрать X25-E.
При интенсивном изменении данных узким местом обычно является файл журнала для базы данных. Также следует ожидать роста файла журнала, если вы работаете в режиме ПОЛНОГО восстановления, а автоматический рост файла журнала (и файла данных) убивает производительность. Рассмотрите возможность перехода на ПРОСТОЕ восстановление на время миграции, это минимизирует требования к пространству для журналов. Это также избавит вас от необходимости часто выполнять резервное копирование журнала транзакций, которое требует чтения файла журнала, перемещения головок диска и замедляет работу. Если у вас есть многоэтапный процесс миграции («Сначала запустите эту программу, затем запустите эту другую программу и т. Д. И т. Д.»), Вы можете просто делать ДИФФЕРЕНЦИАЛЬНЫЕ резервные копии (или даже ПОЛНЫЕ) между шагами.
Я предлагаю вам изолировать файл журнала от файлов данных, переместив файл журнала из SAN и поместив его на пару зеркальных дисков SAS. Причина этого заключается в том, что ввод-вывод в файл журнала является синхронным, в то время как чтение из файла (ов) данных часто кэшируется, а записи по большей части являются асинхронными. Это означает, что ввод-вывод для файла журнала более критичен по времени, чем ввод-вывод для файлов данных. При перемещении файла журнала часть требований к пропускной способности ввода-вывода смещается с левой стороны, но, что более важно, запись в журнал будет выполняться последовательно, с небольшим перемещением головок дисковода. Что касается записи в журнал, перемещение головок приводов снижает производительность.
Кроме того, задержка на паре дисков DAS, вероятно, будет лучше, чем при использовании коммутатора SAN. Это также выигрыш для синхронной записи журнала. Чем больше гаджетов (коммутаторов и т. Д.) Ваши данные должны пройти между ОЗУ на сервере и дисками, тем больше будет задержка. В конце концов, диски со скоростью 15 000 об / мин в SAN не быстрее, чем диски со скоростью 15 000 об / мин, которые вы бы вставили в свой DL360.
Я знаю, что поставщики SAN скажут вам, что в SAN так много кеша записи, что это не имеет значения, и что все записи в журнал будут кэшироваться и деактивироваться позже, а вычисления избыточности (для RAID5 и подобных типов RAID ) работают молниеносно, но сети SAN, похоже, никогда не работают так хорошо, как вы надеялись. Я проходил через такие вещи десятки раз, и реальная производительность всегда разочаровывала. Надейся на лучшее, но планируй худшее.
Я предлагаю использовать для журнала пару зеркальных дисков SAS. Если вы согласны с необходимостью восстановления и повторного запуска миграции в (маловероятном) случае сбоя диска, вы можете перейти на RAID 0 или только с 1 диском, если вы в отчаянии. (Если у вас левша, вы, вероятно, не в отчаянии и у вас есть несколько дисков SAS на 72 или 143 ГБ.) Я бы использовал этот способ только временно, на время миграции. Обычно скорость передачи данных на диски журналов низкая, может быть, 10 МБ / с или меньше, но задержка при множестве небольших операций записи задерживает все. Для этой задачи вы определенно предпочтете диски со скоростью 15 000 об / мин, а не диски с более низкой скоростью вращения, но, возможно, с более высокими значениями средней пропускной способности.
Кроме того, вы захотите увеличить этот файл журнала вручную или заранее или очень внимательно следить за свободным пространством в файле журнала. Если файл журнала начинает почти заполняться, вручную увеличьте размер файла журнала. Если вы сделаете это вручную, процесс миграции продолжится. Если вы полагаетесь на автоматическое увеличение, процесс будет задерживаться на время роста, и всегда кажется, что автоматическое увеличение файла на 1 ГБ занимает больше времени, чем увеличение его на 1 ГБ вручную. После того, как вы закончите с процессом, вы можете снова сжать файл журнала до того, что было до миграции, и переместить его обратно в левую часть.
В зависимости от того, как ваш поставщик написал код миграции, вам также может потребоваться много от tempdb. Трудно узнать, не попробовав ни разу на тестовом сервере. Если это так, вы также можете получить улучшения, переместив файлы данных tempdb на их собственный набор локальных дисков. Для этого я бы определенно хотел RAID10 (не RAID5). Вы можете использовать RAID0, если хотите рискнуть на выходных, опять же с оговоркой, что придется восстанавливать базы данных и повторно запускать миграцию с нуля, если что-то пойдет не так. Не полагайтесь на RAID0 после миграции.
Кроме того, убедитесь, что вы выровняли разделы, когда создаете их на пустых дисках. Это дешевое улучшение производительности.
Что бы вы ни делали, не забывайте, что копирование всех данных из Lefthand и их возврат займет значительное количество времени. Мне часто приходится проталкивать 1 ТБ между серверами и через сетевые адаптеры 1 Гб. На это уйдут часы. Проведите тест с одним или двумя файлами по 10 ГБ, определите ожидаемую скорость передачи данных и вычислите, сколько времени потребуется, чтобы переместить большие файлы. Robocopy работает очень хорошо, пользуюсь им как минимум 16 лет.
Еще 0,02 доллара (если вы дочитали до этого места): я мало знаю о Lefthands. Если бы эти сетевые карты правильно балансировали нагрузку, я бы ожидал что-то более 175 МБ / с. Я могу достичь 115 МБ / с или около того в TCP Ethernet на сетевых адаптерах 1 Гбит / с без каких-либо особых магических действий. Я ожидаю, что iSCSI будет немного быстрее. Если вы можете кормить только Lefthand со скоростью 100 МБ / с или меньше, и эти файлы SQL Server - единственное, что на нем, левый модуль выглядит как $ overkill $. Вероятно, вы могли бы получить такую скорость передачи данных на 2 или 4 дисках SATA 7200 об / мин потребительского уровня. DL360 должен легко обеспечить лучшую скорость передачи данных с набором напрямую подключенных дисков 10K SAS.
Вы запускаете свой MSSQL-модуль по (бессмысленно) объединенной iSCSI-ссылке? Неудивительно, что вам нужна дополнительная производительность - я искренне не понимаю, почему вы так себя калечите. В любом случае, да, переход на DAS значительно увеличит вашу общую производительность, но переход на твердотельные накопители сторонних производителей может вообще не работать, их карты известны тем, что работают только с дисками с прошивкой HP, я бы подумал об использовании обычных вращающиеся диски, возможно, их 146 ГБ 15 оборотов в минуту 2,5 диски, их собственные твердотельные накопители устрашающе дороги (хотя и хорошо). Если вы абсолютно хотите попробовать твердотельные накопители сторонних производителей, я бы посоветовал вам сначала купить один, попробовать его, и, если он распознается, купить еще, и да - тяжелая запись в БД действительно замедлится и в конечном итоге убьет даже лучшие твердотельные накопители. .