RAID0 вместо RAID1 или 5, это безумие?

Я рассматриваю возможность использования установки RAID0 для одного из наших кластеров SQL Server. Я обрисую ситуацию и ищу, почему это может быть плохой идеей. Кроме того, если кто-то, у вас есть примеры использования, официальные документы или другая документация, вы можете указать мне на эту тему, это было бы здорово.

У нас есть 3 сервера в 2 центрах обработки данных, которые являются частью кластера SQL. Все они работают на SQL Server в группе доступности. У основного объекта есть точная копия, сидящая рядом с ним, а другая - в другом центре обработки данных. Они запускают синхронную репликацию с автоматическим переключением при сбое. Все диски являются твердотельными накопителями корпоративного класса. Они будут работать под управлением SQL Server 2017 или 2019.

Я думаю, что их использование в массивах RAID0 будет иметь множество преимуществ по сравнению с другими методами, но с некоторыми реальными недостатками. Единственный минус, который я сейчас вижу, - это отсутствие избыточности на основном сервере, поэтому сбой увеличивается. Как плюсы:

1. Если диск выходит из строя, а не работает в замедленном, ухудшенном состоянии до тех пор, пока кто-то не получит уведомление и не будет действовать вручную, сервер немедленно перестанет работать на вторичном сервере, поддерживая полную работоспособность. Это даст нам дополнительное преимущество, сообщив нам о сбое, поэтому мы сможем быстрее выяснить причину.

2. Это снижает вероятность отказа в целом по емкости ТБ. Поскольку нам не нужны диски четности или зеркальные диски, мы уменьшаем количество дисков на массив. Чем меньше дисков, тем меньше вероятность отказа диска.

3. Это дешевле. Требование меньшего количества дисков для нашей требуемой емкости, очевидно, стоит меньше.

Я знаю, что это не обычное деловое мышление, но есть ли что-то, что я не рассматриваю? Я хотел бы любой вклад или за или против.

Я не пытаюсь сделать это для повышения производительности запросов, хотя, если есть значимые, не стесняйтесь указывать на них. Моя главная задача - не рассмотреть или не решить проблему надежности или избыточности, о которой я не задумывался.

Операционная система находится на отдельном зеркальном диске, поэтому сам сервер должен работать. Один из этих дисков можно заменить и снова отразить. Он маленький и на нем нет никаких файлов базы данных, кроме системных. Я не могу представить, что это займет больше минуты. В случае сбоя одного из массивов данных мы заменяем диск, перестраиваем массив, восстанавливаем и повторно синхронизируем с AG. По моему личному опыту, восстановление было НАМНОГО быстрее, чем восстановление диска RAID5. У меня никогда не было сбоя RAID1, поэтому я не знаю, будет ли это восстановление быстрее или нет. Восстановление будет происходить из резервной копии и переноситься вперед, чтобы соответствовать первичному, поэтому увеличение нагрузки на первичном сервере должно быть очень минимальным, только синхронизируя последние несколько минут журналов с восстановленной репликой.

Есть один очень важный аспект, который, я думаю, вам не хватает в вашей оценке:

Как вы планируете восстановить?

Когда raid5 теряет диск, он будет работать в ухудшенном состоянии, пока не восстановится автоматически. (По крайней мере, если у вас есть горячий запас под рукой.)

Когда raid0 теряет диск, он вообще не может восстановиться. Это означает, что вы потеряли избыточность, и для ее восстановления вам нужно пересобрать raid0 и скопировать все данные (не только данные на сломанном диске) обратно с вторичного устройства, которое сейчас находится под производственной нагрузкой. То есть, вместо единственного деградированного массива raid5, теперь вся ваша производственная установка получает удар по производительности.

Если вы не можете справиться с ухудшением производительности raid5 (или raid6), вы должны вместо этого выполнить raid 1 + 0 . Да, это стоит дороже, но цены на диски, какими бы они ни были, будут хорошо потрачены.

Может быть, «активно следить за состоянием raid5 и переносить нагрузку с первичной системы в случае отказа диска» - это решение, которое дает вам большинство преимуществ без каких-либо недостатков? (Конечно, кроме потери коэффициента крутости при работе без какой-либо локальной избыточности.) Если восстановление диска raid5 занимает намного больше времени, чем полная синхронизация данных базы данных, либо программное обеспечение raid работает странно, либо у вас серьезно большие диски, Я думаю.

Отказ привода следует принимать во внимание здесь.

Представьте на секунду, что наши диски в любой конкретный день имеют частоту отказов 1/1000. Представьте себе, что у нас есть 20 дисков в каждом из наших 3 массивов.

Следовательно, вероятность сбоя одного диска в массиве составляет 20/1000 = 1/50. Вероятность сбоя двух дисков в одном и том же массиве составляет около 20/1000 * 20/1000 / 2 = 200/1000000 = 1/5000. Таким образом, переключаясь с RAID 0 на RAID 5, мы уже значительно реже убиваем один из наших массивов.

Таким образом, мы можем пойти дальше - если вероятность сбоя массива в день равна 1/50, то вероятность сбоя двух массивов за день составляет 1 / (50 * 50) = 1/2500. Вероятность сбоя двух идентичных массивов RAID 0 в два раза выше, чем одного массива RAID 5, при условии, что один и тот же набор дисков. Это экспоненциальное увеличение шансов на сбой должно беспокоить вас, так как оно значительно увеличивает вероятность сбоя более чем одного массива одновременно.

Поскольку эти диски, вероятно, будут иметь длительный срок службы, вы, вероятно, можете запустить числа, как указано выше, и непосредственно посмотреть, как это повлияет на надежность - если вы можете опубликовать спецификации дисков, я могу добавить этот расчет в этот пост. Приемлемый риск в таком случае или нет - решать вашей организации.

Еще один момент, на который следует обратить внимание, заключается в том, что вероятность сбоя накопителя может быть увеличена за счет использования твердотельных накопителей, изготовленных в одной партии (на одном заводе, в одно и то же время). Если вы не будете осторожны, из-за этой проблемы вы можете потерять все 3 узла.

Отказ от ответственности: приведенные выше расчеты были упрощены - они все еще относительно точны.

Я думаю, что их использование в массивах RAID0 будет иметь множество преимуществ по сравнению с другими методами, но с некоторыми реальными недостатками.

Это довольно распространенная конфигурация при работе AG с внутренними / напрямую подключенными накопителями. Особенно с NVMe или другими флэш-накопителями на основе PCI.

Это просто равносильно лечению сбоя диска как сбоя сервера. При небольшом количестве твердотельных накопителей у вас на самом деле не будет значительно меньше MTBF для накопителей, чем у других твердотельных компонентов сервера, и поэтому вы просто воспринимаете каждый диск как точку отказа для сервер и заменить / восстановить сервер в случае сбоя диска.

Я заинтригован относительно того, что вы пытаетесь достичь? Вы упоминаете, что не пытаетесь получить прирост производительности от этой установки, так какой выигрыш вы пытаетесь получить?

Обратите внимание на проблему производительности: если вы используете твердотельные накопители Enterprise Class, действительно ли ваши вычисления RAID являются узким местом, которое необходимо для их улучшения?

Принимая ваши 3 профи, я не думаю, что вы продумали это достаточно:

1. Будет ли отказоустойчивость SQL сразу? Что приведет к автоматическому срабатыванию аварийного переключения? Будет ли сервер переводить диск в автономный режим, как только кто-нибудь его ударит? Что если это просто плохой сектор на одном диске? Если SQL не ударит по плохому сектору, будет ли он работать при сбое? Я не уверен на 100% в этом.

2. Уменьшает ли это вероятность отказа в целом на емкость ТБ. Ваше мышление кажется, что чем меньше дисков, тем меньше точек отказа, но я не думаю, что это правильно. Вероятность сбоя 1 диска остается той же, если у вас 1 диск или 10 дисков (или 100 дисков), но с RAID 0 это также означает, что это катастрофический сбой.

3. Один дополнительный SSD будет стоить слишком дорого для вас, чтобы получить RAID5? Я понимаю, как RAID1 ИЛИ 1 + 0 может взорвать бюджет, но 1 дополнительный диск?

Без избыточности, если диск выходит из строя и RAID отключается, этот узел будет отключен до тех пор, пока вы не восстановите RAID и не восстановите все свои базы данных с нуля. Какой процесс вы собираетесь предпринять, чтобы это произошло? Вы не можете удалить базу данных из группы доступности, так как это остановит репликацию на DR, но если вы не предпримете никаких действий, два других сервера не смогут обрезать свои файлы журнала. Это нормально? Что произойдет, если это не удастся в пятницу вечером длинных выходных? Это все еще хорошо? Могут ли ваши подчиненные справиться с таким количеством данных?

Мои последние вопросы будут о времени восстановления, которое вы упомянули, будет быстрее. Вы на 100% уверены, что это будет быстрее? Насколько быстрее?

Настройка сервера Brent Ozar все еще является моим руководством по настройке новых экземпляров SQL. Самым первым пунктом в руководстве является подтверждение того, что вы не используете RAID0 для каких-либо дисков.

==== ==== UPDATE

Еще одна мысль, что происходит, когда ваши вторичные серверы не синхронизированы с вашим основным? Даже с синхронной репликацией ваши вторичные серверы могут по-прежнему автоматически переходить в асинхронный режим, и, как только они это сделают, вы теряете возможность автоматического перехода на другой ресурс, так как любой отказоустойчивый сервер приведет к потере данных. Несколько примеров, когда это могло произойти:

1. Восстановление очень большого индекса - репликация может отставать на одном или обоих вторичных серверах
2. Сбой диска на RAID0 при исправлении вторичного. Возможно, сервер, который вы исправляете, не сможет вернуться в оперативный режим из-за того, что основной сервер отключен.

Это крайние случаи, но они могут быть катестрофными в зависимости от того, что было потеряно в те времена.