статья может оскорбить религиозные чувства многих админов
Яркий пример неудачного массива
В каких случаях RAID-массивы на сервере 1С/СУБД можно использовать:
В каких случаях RAID-массивы на сервере 1С/СУБД не нужны
Почему RAID не является панацеей для отказоустойчивости
Нужен ли RAID-массив
Раньше диски были механическими, а значит медленными и недостаточно надёжными (об их надёжности — ниже по тексту). Но если запихать в массив дисков побольше и позатейливее — можно получить более высокую скорость, и некий шанс пережить выход из строя одного или нескольких дисков (зависит от типа массива, умений админа и существенного фактора везения).
Затем появились SSD, или твердотельные накопители (сокращённо они до сих пор называются “диски”, хотя там уже круглого ничего не осталось 🙂), скорость которых поначалу той же была хоть и выше, чем у механики, но всё равно “не радующей”, а надёжность вызывала сомнения (до сих пор большое количество айтишников уверены, что “SSD ненадёжные”), и эти SSD тоже по привычке запихивались в RAID-массивы. Однако “внезапно” стало проявляться, что далеко не всегда скорость итогового массива из SSD так же хорошо масштабируется, как если бы это был массив механических дисков, и тому есть ряд причин. Наиболее важные для нас минусы:
— если массив собирается из SSD на базе контроллера условно предыдущих поколений, который был изначально рассчитан обслуживать механические диски, то производительность этого массива сразу может быть серьёзнейше ограничена именно возможностями контроллера.
— если в состав массива включены SSD, не предназначенные для использования в составе массива, или не обладающие достаточной производительностью на запись (подробней о расчёте “нужной” производительности SSD можно почитать здесь: http://www.gilev.ru/dwpdssd/).
Для NVMe SSD даже если вы захотите собрать RAID-массив, то вам нужны такой контроллер и такая версия массива, чтобы они учитывали особенности архитектуры NVMe дисков, и позволяли не потерять, а как минимум сохранить скорость на уровне отдельно подключенного диска. Например, таковым является intel VROC (ссылка на https://www.intel.ru/content/www/ru/ru/support/products/122484/memory-and-storage/ssd-software/intel-virtual-raid-on-cpu-intel-vroc.html), опирающийся в свою очередь на intel VMD инструкции процессоров.
Яркий пример неудачного массива
На снимке ниже: пример такого массива, собранного “неправильно”, формата RAID50, в котором 10 (десять) SSD. Причём в этом массиве “хорошо” себя показывает только чтение, и только крупными порциями (верхняя строчка Seq в колонке Read каждого из двух результатов). Запись даже крупными порциями (верхняя строчка Seq в колонке Write) показывает нам всего 142 мегабайта в секунду, а многопоточная запись пакетами по 4 килобайта (нижняя строчка 4K QD32 в колонке Write) даёт нам всего около 16 мегабайт в секунду.
Исключительно для понимания: одиночный диск из состава этого массива имеет показатели записи минимум вдвое выше тех, что показал массив из десяти таких дисков. А поскольку этот массив был предназначен для высокопроизводительной смешанной (чтение+запись) нагрузки сервера 1С/СУБД — очевидно, данный массив для этих целей можно считать непригодным.
В каких случаях RAID-массивы на сервере 1С/СУБД можно использовать:
Для загрузочного носителя как зеркало.
Но не потому что вы получаете реальную отказоустойчивость, а потому что цена такой “игрушки” невысока. Предполагаем, что это будут два недорогих SATA SSD класса read intensive или даже boot (подробней о классах SSD и их предназначении можно почитать здесь: http://www.gilev.ru/dwpdssd/), объединённых в RAID1 (“зеркало”). Если исходить из рисков выхода из строя, то вы скорее износите диск, чем он сломается. Некоторые современные SSD также подвержены перегреву, но рядом расположенные два ssd в рейд маловероятно сработают как надо, так как будут нагреваться примерно одинаково и перегреются почти одновременно. Кроме того надо помнить, что ssd “изнашиваются примерно одинаково”. Поэтому RAID в данном случае будет “для успокоения любителей делать рейд” без тяжелых финансовых последствий. Если вы будете подключать LUN для старта ОС с внешнего хранилища, то с высокой вероятностью там будет RAID “потому что так исторически сложилось”, т.е. нарезают массивы заранее, когда еще точно не знают характер использования и требования к отказоустойчивости 🙂
Для локальных бэкапов для увеличения емкости массива “страйп”.
Для бэкапов часто бывает необходимость места больше, чем есть на одиночном диске и поэтому увеличить общую емкость через рейд может быть полезно. Но хранить бэкапы в одном экземпляре только на зеркале прямо на том же сервере, что и исходная база этих бэкапов — мероприятие малоосмысленное, только зазря себя успокаивать. Если с сервером что-то случится — такой бэкап будет недоступен точно так же, как и исходная база. Гораздо полезней для повышения отказоустойчивости хранения локальных бэкапов сохранять сначала локально, затем тут же копировать (только копировать, не переносить!) полученные файлы бэкапа куда-то наружу сервера на сетевой ресурс. Подробней про бэкапы можно почитать например здесь: http://www.gilev.ru/31march/).
Для базы данных 1С или данных кластера 1С “страйп” в отдельных случаях когда очередей к диску больше порога возможностей. Тут есть одно очень важное уточнение. Порог определяется не чьим-то мнением, а фактическими числовыми показателями времени отклика диска и числа очередей к диску, записанными за длительный период, который можно считать показательным для оценки. Т.е. решение принимается не потому, что вы заранее думаете “надо сделать рейд потому, что это так кажется правильным”, а потому что обладаете собранными с тестового стенда или даже лучше с продуктива данными, подтверждающими что с текущей нагрузкой диск не справляется именно из-за слишком большого числа одновременных операций чтения/записи. Если вы видите, что ваш диск выдерживает условно 128 одновременных активных транзакций (ну или пропорциональное им количество очередей) без потерь по времени отклика, а далее начинает выходить за рамки (ну пусть условно для примера порог будет 30 мс), то при росте числа активных транзакций ну скажем до 180, можно говорить об обоснованности наращивания дисковой подсистемы (например, добавления в RAID 0 второго диска). Ну и так далее. Также надо помнить, что в случае MS SQL Server и наличия квалифицированного админа — есть смысл не RAID 0 собирать под базу данных, а подключить те же два диска из примера отдельно, поместив на каждый по файлу базы данных (поровну распределив размер базы данных на каждый файл). В этом случае MS SQL Server на отдельных операциях может выдавать большую производительность, чем RAID 0.
Большинству админов лень что-либо замерять, и оборудование заказывается “на глаз”. Разумней в этом случае брать минимум дисков, и только по фактической нехватки мощности докупать диски. Если админ “отмазывается” тем, что у него бюджет на год и надо покупать сразу всё, тогда гораздо полезней всё равно сначала закупить один “нужный” диск, замерить практическим экспериментом “сколько он выдержит”, и только после этого составлять калькуляцию на год.
По нашим наблюдениям, в массе случаев и владелец бизнеса, и айти-руководитель подходят к выбору личного автомобиля гораздо вдумчивей, тщательней и придирчивей, чем к вопросу подбора сравнимого по стоимости серверного оборудования “на работу”.
В каких случаях RAID-массивы на сервере 1С/СУБД не нужны
Временные данные 1С или СУБД, а также вторичные данные, потеря которых не остановит работу компании.
Сюда могут включаются например:
— папка кластера 1С, где лежат логи журналов регистрации и файлы полнотекстового поиска 1С (если он используется);
— папка temp профиля пользователя, под которым запущена служба сервера 1С;
— файлы и логи служебной базы tempdb сервера MS SQL (а если у вас PostgreSQL — то это например папки логов pg_clog/pg_xlog/pg_wal/pg_xact, в зависимости от версии постгреса).
Для всех вышеперечисленных целей наиболее рациональным мы видим использование независимых NVMe SSD (не SATA!), подключаемых либо в слоты PCIe, либо по U.2 (если серверная платформа или контроллер предполагают такую возможность). Производительность лидирующих по производительности одиночных NVMe SSD на потоковую запись исчисляется несколькими гигабайтами в секунду, а на случайную запись — многими сотнями мегабайт в секунду, или многими сотнями тысяч так любимых админами и вендорами IOPS. Объём таких одиночных накопителей может достигать например для разных моделей от 6 до 16 терабайт, при этом их же можно подключать несколько (если ваш сервер позволяет, конечно). Ряд серверных платформ позволяет подключить до 8-24 NVMe SSD.
При этом, например, если у вас база 1С почему-то достигла объёма в несколько терабайт, а вы не хотите или не можете предпринимать никаких мер по уменьшению её размера (например http://www.gilev.ru/basereduction/), но при этом знаете, что на дисках сервера СУБД хорошо бы держать про запас свободного места ещё хотя бы на 50% объёма продуктивной базы (например, на случай реструктуризации или вообще внезапного роста), то например для базы в 4 терабайта не обязательно искать SSD на 8 терабайт, можно “размазать” базу средствами СУБД на 2-3 SSD меньшей ёмкости.
Как именно разносить нагрузку tempdb, базы и логов — лучше всего не гадать, не слушать “чужих советов”, а просто “сфотографировать” со своей работающей системы фактические объёмы записи в СУБД например за неделю (подробнее: http://www.gilev.ru/dwpdssd/), и на их основании уже принимать решение вида “нам нужно вот столько SSD такой ёмкости, распределять нагрузку между дисками будем вот таким образом” (конкретный пример разнесения приводить не будем из принципа, чтобы он случайно не отложился в памяти как рекомендация).
Вышедшие NVMe PCIe 4.0 диски типа intel D7-P5600 настолько быстры, что современные сервера на RAM-дисках не дадут сколько-то значимого преимущества, но при этом обладают недостатками надежности при отключении питания. Для малого бизнеса есть бюджетные диски типа Samsung 980 Pro.
Основные данные и файлы лицензирования ключей 1С.
Надежность дисков серии intel p3700, p4800 проверена временем. На таких дисках можно смело размещать основные данные. Вероятность выхода из строя таких дисков меньше чем блока питания к примеру. На некоторых проектах такие диски успешно работают более 5 лет.
Усилия по повышению надежности надо предпринимать на программном уровне (СУБД и т.п.) оперативно передавая данные на резервный сервер. Так как риски словить вирус или испортить данные руками пользователей будут гораздо выше. Оперативно выполняемые бэкапы на отдельный физический локальный диск будут первым шагом, более эффективным чем зеркалирующий рейд. Для бэкапов на физических серверах можно использовать например https://acronis-infoprotect.ru/backup . Если у вас будет резервный сервер для поднятия бэкапа, а также удаленно лежащая копия, то это снимает вопрос по необходимости зеркалирования дисков рейдом.
Почему RAID не является панацеей для отказоустойчивости
Что же касается надёжности — тут наша позиция такая: массив RAID даёт шанс пережить выход из строя условно 1-2 носителей из его состава. Это конечно замечательно, но если мы начинаем изучать, что же на самом деле может “сломаться” (не в порядке параноидального бреда, а по наблюдениям нас и наших клиентов) — выясняется, что это лишь малая часть айсберга! Выходят из строя разные комплектующие внутри сервера, выходят из строя компоненты сети, может “приехать” неудачное обновление Windows или 1С, может “упасть” сервер 1С, может “сломаться” база 1С, может “прилететь шифровальщик”. Будет ли откровением то, что ни от какого из этих факторов риска RAID-массив нас не спасёт? Здесь уже надо говорить о сценариях резервирования, отказоустойчивости и катастрофоустойчивости (но об этом в другой раз).
Почему SSD не “настолько же ненадёжны, как механические диски”: в механическом диске были вращающиеся с бешеной скоростью пластины, были яростно летающие над ними на микронной высоте головки, всё это жужжало, вибрировало, грелось, сильно боялось тряски или сторонних вибраций, внезапных отключений электричества и вообще было нежным и хрупким даже в довольно крепком серверном исполнении. Современные серверные SSD — скучная плата без движущихся деталей, возможно (и даже крайне желательно) с увесистым радиатором (а кто-нибудь может и вентилятор сверху “приколхозить”), по сути там внутри есть флэш-память и контроллер. Внутри SSD есть расходуемый ресурс, а именно флэш-память, которая при записи неизбежно изнашивается, и этот параметр крайне желательно контролировать хотя бы раз в месяц, но если к подбору SSD подошли правильно и вдумчиво — SSD как минимум переживёт период продуктивной эксплуатации, а с очень большой вероятностью доживёт и до полного морального устаревания сервера. Вся остальная электроника внутри — условно такая же, в остальном сервере, и выход из строя хоть и может произойти, но примерно с такой же вероятностью, как у любой другой компоненты серверного оборудования.
В итоге: для сервера 1С/СУБД RAID-массив из NVMe SSD в большинстве случаев не является необходимым ни для ускорения, ни для повышения надёжности.
Смотрите также Зачем аппаратному RAID-контроллеру нужна батарейка?
Подключение дисков с разъемом U.2
Влияние HDD на быстродействие 1С:Предприятие 8
31 марта — Международный день резервного копирования
Про диски для 1С