Новый сервер для 1с. Стоит ли делать RAID 10 на NVMe?
Хотим покупать новый сервер. И возник вопрос ставить 4 шт NVMe в RAID 10 или SSD и просто набить памяти и поставить NVMe на кэш? Сейчас стоит сервер с RAID 10 на SSD и NVMe на кэш. Планируется upgrade.
Почитал статьи. Гилев пишет, что NVMe в рейде не нужен. Но статья старая. Сейчас есть контроллеры с поддержкой NVMe - Broadcom MegaRAID 9460-8i, 12Gb/s SAS/SATA/NVMe, x8 PCIe Gen 3.0.
Поидее должно работать очень быстро, но тестов не нашел.
Может у кого был опыт покупки сервера NVMe в RAID? Как скорость там?
Почитал статьи. Гилев пишет, что NVMe в рейде не нужен. Но статья старая. Сейчас есть контроллеры с поддержкой NVMe - Broadcom MegaRAID 9460-8i, 12Gb/s SAS/SATA/NVMe, x8 PCIe Gen 3.0.
Поидее должно работать очень быстро, но тестов не нашел.
Может у кого был опыт покупки сервера NVMe в RAID? Как скорость там?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
Добрый день.
Конечно NVMe быстрее SSD, поэтому прирост по скорости работы именно жесткого диска будет. Но, как известно, ключевую роль играет баланс сборки. Возможен эффект батл нек от процессора, памяти или неоптимизированного софта, в т.ч. самой платформы 1С.
Так что если у вас очень много денег и вам надо их потратить - можете покупать самые дорогие и крутые NVMe диски. Но может быть по скорости работы 1С вы получите то же самое, как если бы было SSD или SAS. Надо смотреть не только диски, но и всю сборку, а так же делать замеры именно на ваших базах. Какая у вас сборка и базы никто не знает, поэтому точно вам никто не скажет каков будет результат.
Конечно NVMe быстрее SSD, поэтому прирост по скорости работы именно жесткого диска будет. Но, как известно, ключевую роль играет баланс сборки. Возможен эффект батл нек от процессора, памяти или неоптимизированного софта, в т.ч. самой платформы 1С.
Так что если у вас очень много денег и вам надо их потратить - можете покупать самые дорогие и крутые NVMe диски. Но может быть по скорости работы 1С вы получите то же самое, как если бы было SSD или SAS. Надо смотреть не только диски, но и всю сборку, а так же делать замеры именно на ваших базах. Какая у вас сборка и базы никто не знает, поэтому точно вам никто не скажет каков будет результат.
(13) Планируется в будущем переход на ERP или УТ 11.5 на где-то 100 пользователей. На форумах пишут, что ERP очень тяжелая даже в стандарте - "В сервер пару лет назад (это в 2020 году) когда еще УПП была вгрохали 4 ляма"
Вот я и думаю, как максимально производительность поднять у нового сервера. 4 ляма - это перебор.)
Вот я и думаю, как максимально производительность поднять у нового сервера. 4 ляма - это перебор.)
(15) получается у вас вопрос больше подбора сервера для 1С под бюджет. Понятно, что чем дешевле - тем лучше, но всё-таки каков бюджет - не понятно. Врятли вы сможете изобрести велосипед, если просто поставите быстрые диски. Плюс есть вопрос успевания оптимизации софта под новейшие контроллеры и в целом технологии. На вашу тему целые конференции устраивают, есть подбор от 1с и т.д. Можно начать погружаться
В тестах по гилеву разницу между ссд и ссд в рейд 1-0 вообще нет. а с учетом возможного отказа одного из дисков история сомнительная. да и в современной "ванси" современные диски явно не узкое место.
плюс отдельно попадалась инфа что сам по себе рейд становится узким местом. что быстрее просто записать данные чем рейд будет их по дискам распихивать тратя спу, так же с нвме есть архитектурные вопросы по "забыл термин" аля дефрагментация
плюс отдельно попадалась инфа что сам по себе рейд становится узким местом. что быстрее просто записать данные чем рейд будет их по дискам распихивать тратя спу, так же с нвме есть архитектурные вопросы по "забыл термин" аля дефрагментация
Почему не нужен рейд на SSD вообще, включая NVME? Потому, что у них может быть разная скорость записи, например. Почему? Ну, например, от температурного режима - троттлинг, например, начинается, на одном из дисков может упасть скорость записи. В итоге два диска пишут одно и то же с разной скоростью и начинают друг друга ждать. Второе - ресурс. Если писать на два диска, то их ресурс одновременно сокращается. Третье - скорость. Скорость SSD довольно высока, особенно NVME. Поэтому делать реплику на второй диск будет быстрее, чем полностью синхронизировать данные, тем более контроллер диска все-равно будет выбирать для записи те ячейки, которые сочтет нужным - софт на это не влияет никак, по крайней мере не 1С и SQL.
В итоге от рейда нет никакой пользы.
С другой стороны в последнее время напридумывали вариантов, как работат с рейдом на SSD. Про это в интернетах понаписано. Мне удалось найти только "RAID на базе процессора данных" - это 5-й рейд, который работает со специальным процессором данных, но деталей я не уловил - читайте. Также видел я статью про какой-то новый вариант рейда специально для ССД. Найти не смог, но что-то типа 5-го, только несколько дисков с четностью.
Лично я бы сделал реплику системы при изменениях на другой диск. Ну или поточную репликацию базы. Да, операционку можно на зеркальный рейд из SSD поставить - это позволит нивелировать ситуации, если один диск сдохнет. И если вынести файлы подкачки не на зеркало, то уже неплохо.
В итоге от рейда нет никакой пользы.
С другой стороны в последнее время напридумывали вариантов, как работат с рейдом на SSD. Про это в интернетах понаписано. Мне удалось найти только "RAID на базе процессора данных" - это 5-й рейд, который работает со специальным процессором данных, но деталей я не уловил - читайте. Также видел я статью про какой-то новый вариант рейда специально для ССД. Найти не смог, но что-то типа 5-го, только несколько дисков с четностью.
Лично я бы сделал реплику системы при изменениях на другой диск. Ну или поточную репликацию базы. Да, операционку можно на зеркальный рейд из SSD поставить - это позволит нивелировать ситуации, если один диск сдохнет. И если вынести файлы подкачки не на зеркало, то уже неплохо.
(18)
Одиночный диск не может точно так же в тротлинг свалиться? Или если реплика синхронная и там диск затупил?
(18)
В репликой плюс-минус тоже самое же получится, по идее.
Ну, например, от температурного режима - троттлинг, например, начинается, на одном из дисков может упасть скорость записи. В итоге два диска пишут одно и то же с разной скоростью и начинают друг друга ждать.
Одиночный диск не может точно так же в тротлинг свалиться? Или если реплика синхронная и там диск затупил?
(18)
Если писать на два диска, то их ресурс одновременно сокращается.
В репликой плюс-минус тоже самое же получится, по идее.
(20)
Одиночный диск не может точно так же в тротлинг свалиться?
Может, конечно. Тут другое - совместная одновременная запись на оба диска. И если один перегрелся, то второй его начинает ждать. А когда диск один - никто его не ждет, ну кроме ОС.
репликой плюс-минус тоже самое
На реплику можно писать только изменения БД, при том не в моменте, а раз в минуту, например. Или уже состоявшиеся транзакции. Не знаю, как тут ведет себя MS SQL, но постгрес умеет реплицировать WAL-файлы, при том есть настройка времени и размера этих файлов, может быть чего-то еще - не вспомню сразу. Наверное и MS SQL тоже должен что-то такое уметь. У него проблема в том, что файла условно два - лог и данные, а у постгреса эти файлы на каждое изменение свои. Это создает другие проблемы, решая вопросы гранулированной репликации.
(22) Рейд - это не для скорости, а для надежности. Скорость на рейде ушла во времена вертящихся дисков, ибо их IOPS рос пропорционально количеству дисков в рейде, при том на один диск он был в районе 200-500 (в зависимости от скорости вращения: 5400-15к). Сейчас NVME-диски умеют IOPS до 1кк, при том скорость работы с СУБД не сказать вот, что выросла на порядки, ибо все упирается в "атомизацию транзакций", т.е. выделение данных одной транзакции и размещению их на страницах СУБД, что упирается в производительность процессора и памяти больше, чем в производительности дисков. Так что тут скорость дисков - это вторичный фактор. Скорость на RAM-дисках не сильно быстрее, чем на NVME в плане TPS, которая не сильно-то быстрее HDD, т.к. транзакции оборачиваются в пакеты и пишутся пачками всеми этими "бгврайтерами" в отдельном потоке. Сейчас СУБД вообще стараются осуществлять близкое к некому значению количество транзакций в секунду при любой нагрузке. Т.е. в противовес скорости они выбирают предсказуемость количества обращений к БД.
(25) При чем тут документооборот? Например - создание и запись бэкапа - будет долгий сплошной поток чтения/записи. При скоростях NVME - тепла выделится немало. И разница при RAID-0 будет в том - выделится все это тепло на одном диске - или будет "размазано" на несколько дисков.
(21)
При потоковой репликации нагрузка на запись на реплике, при прочих равных, должна быть аналогична мастеру (за минусом временных файлов), что на постгресе, что на мс. Объём валов один в один на диск писать нужно, объем данных в тоже.
Про логическую не скажу, не пользовался. Возможно там по другому.
(21)
Отдельный лог на каждую базу в мсскл это не проблема, это преимущество, как по мне. В том числе и для репликации - можно часть баз исключить, при необходимости
На реплику можно писать только изменения БД, при том не в моменте, а раз в минуту, например. Или уже состоявшиеся транзакции.
При потоковой репликации нагрузка на запись на реплике, при прочих равных, должна быть аналогична мастеру (за минусом временных файлов), что на постгресе, что на мс. Объём валов один в один на диск писать нужно, объем данных в тоже.
Про логическую не скажу, не пользовался. Возможно там по другому.
(21)
Наверное и MS SQL тоже должен что-то такое уметь. У него проблема в том, что файла условно два - лог и данные, а у постгреса эти файлы на каждое изменение свои.
Отдельный лог на каждую базу в мсскл это не проблема, это преимущество, как по мне. В том числе и для репликации - можно часть баз исключить, при необходимости
(30) При потоковой репликации запись идет равными порциями, по крайней мере в постгресе. Там настраивается WAL в части размеров и частей, отправляемых в реплику, и вроде бы периодичности. Точно не вспомню. А запись большими кусками куда производительнее записи маленькими кусочками при попытке собрать порции со всех потоков, подсовывающих данные.
Мне кажется, что тут вы с лог-шиппингом путаете. Там - да, изменения отправляются по мере заполнения wal файлов. При потоковой сразу улетают на реплику. В любом случае, речь-то про равномерный износ обоих дисков шла. Там, думаю, не сильно принципиально - порциями один и тот же объем данных записывается или размазано.
Старенькая на Хабре утверждает, что преимущества с рейдом вы не получите. В том числе в статье тестируется LSI MegaRAID 9460-8i, который, я почти уверен, является аналогом вашего Broadcom MegaRAID 9460-8i. У статьи есть продолжения, но ничего опровергающего/утешающего я не нашёл.
но кроме скорости еще есть и шанс восстановления при сбое или проблемах в массиве
и учтите - это не жесткий диск, который восстановить реальнее., чем ссд и тем более nvme
БЕКАП никто не отменял
и тем более проверять его нужно :)
(1)
Как по мне, то лучше вместо RAID 10 на PCIe Gen 3.0 поставить одиночный NVMe, но на PCIe Gen 4.0
все-таки третье поколения PCIe 3.0 был выпущен в 2010 году, в отличие от PCIe 4.0 — это более поздняя версия, представленная в 2019 году. Она удваивает скорость полосы пропускания PCIe 3.0
Естественно, это для скорости. А для надежности - бэкапы. Не знаю, есть ли сейчас аппаратные решения на RAID на NVMe PCIe 4.0, но PCIe 3.0 - это уже устаревшее.
И, естественно, на такие горячие NVMe PCIe 4.0 радиаторы и хорошее охлаждение. потому что NVMe PCIe 4.0 гораздо горячее NVMe PCIe 3.0
(1)
Сейчас есть контроллеры с поддержкой NVMe - Broadcom MegaRAID 9460-8i, 12Gb/s SAS/SATA/NVMe, x8 PCIe Gen 3.0
Как по мне, то лучше вместо RAID 10 на PCIe Gen 3.0 поставить одиночный NVMe, но на PCIe Gen 4.0
все-таки третье поколения PCIe 3.0 был выпущен в 2010 году, в отличие от PCIe 4.0 — это более поздняя версия, представленная в 2019 году. Она удваивает скорость полосы пропускания PCIe 3.0
Естественно, это для скорости. А для надежности - бэкапы. Не знаю, есть ли сейчас аппаратные решения на RAID на NVMe PCIe 4.0, но PCIe 3.0 - это уже устаревшее.
И, естественно, на такие горячие NVMe PCIe 4.0 радиаторы и хорошее охлаждение. потому что NVMe PCIe 4.0 гораздо горячее NVMe PCIe 3.0
(1)
Хотим покупать новый сервер.
поэтому как минимум покупай сервер, который поддерживает NVMe PCIe 4.0. Даже если сейчас поставишь NVMe PCIe 3.0, то в дальнейшем будет возможность модернизировать дисковую подсистему. А если поддерживает RAID на NVMe PCIe 4.0, то это вообще замечательно.
(41) да я тоже под 1с собираю
2 x Xeon Silver-4516Y+ 2.2-3.7ГГц (48 ядер) / 256Гб RAM / 4x8000Гб NVMe / LSI 9560-16i / IPMI с IP-KVM
Накопители Samsung MZ-QL27T60 PM9A3 обьединяются в RAID10 на контроллере LSI 9560-16i с bbu (батарейка).
Но не покидает мысль, что на другом железе можно и пошустрее сделать сервачок для ms sql. Причем всегда упираюсь в чтение-запись, а не в проц и память
2 x Xeon Silver-4516Y+ 2.2-3.7ГГц (48 ядер) / 256Гб RAM / 4x8000Гб NVMe / LSI 9560-16i / IPMI с IP-KVM
Накопители Samsung MZ-QL27T60 PM9A3 обьединяются в RAID10 на контроллере LSI 9560-16i с bbu (батарейка).
Но не покидает мысль, что на другом железе можно и пошустрее сделать сервачок для ms sql. Причем всегда упираюсь в чтение-запись, а не в проц и память
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот