Один большой RAID 10 — новый стандарт серверного хранилища

В конце 1990-х годов стандартным правилом при создании нового сервера было размещение операционной системы на отдельном небольшом массиве RAID 1, а приложений и данных — на отдельном массиве RAID 5. Это делалось по ряду причин, многие из которых растворились в песках времени. Главными движущими факторами были чрезвычайно высокая стоимость дискового пространства, небольшой объём дисков, регулярные повреждения файловых систем и очень высокий процент физических отказов жёстких дисков по сравнению с другими типами сбоев. Специалистов волновала необходимость защиты от физических отказов накопителей, защиты от повреждений файловой системы и получения достаточного объёма для удовлетворения потребностей.

Сегодня ситуация с хранилищами кардинально изменилась. Файловые системы невероятно устойчивы, и повреждения непосредственно со стороны файловой системы встречаются крайне редко — а благодаря таким технологиям, как журналирование, их почти всегда можно быстро и эффективно исправить, защитив пользователей от потери данных. Сегодня почти никто не беспокоится о повреждениях файловой системы.

Современные файловые системы также способны работать с гораздо большими объёмами данных, чем прежде. В конце 1990-х и начале 2000-х годов было не редкостью создать дисковый массив большего размера, чем могла обработать любая отдельная файловая система. Сегодня это не актуально: все распространённые файловые системы поддерживают как минимум многие терабайты, а нередко — петабайты, экзабайты и более.

Жёсткие диски стали значительно надёжнее, чем в конце 1990-х. Вероятность полного отказа накопителя очень мала, даже у менее дорогих моделей. Настолько мала, что основной угрозой потери данных в RAID-массивах стали не отказы жёстких дисков, а сбои самих массивов. Мы больше не меняем жёсткие диски бездумно — сегодня не редкость, когда большие массивы проходят весь срок службы без потери ни единого диска.

Объём накопителей вырос кардинально. Вместо дисков ёмкостью 4,3 ГБ мы устанавливаем диски объёмом 3 ТБ. Почти в тысячу раз больше данных на одном шпинделе по сравнению с тем, что было менее пятнадцати лет назад.

Совокупность этих факторов создаёт потребность в принципиально ином подходе к проектированию серверных хранилищ и изменении «правила большого пальца» в отношении отправной точки при проектировании хранилища.

Старый подход можно обозначить как RAID 1 + RAID 5. Пространство RAID 1 использовалось для операционной системы, тогда как пространство RAID 5, предположительно значительно большее, — для данных и приложений. Такая схема разделяла две задачи хранения, направляя максимальные усилия на защиту операционной системы (восстановить которую в случае аварии было крайне сложно и от которой зависела доступность данных) на высоконадёжный RAID 1. RAID 5 с более низкими затратами, несмотря на несколько большие риски, как правило, выбирался для данных, поскольку стоимость хранения данных на RAID 1 в большинстве случаев была слишком высокой. В то время это был разумный компромисс.

Сегодня, с нашими совершенно иными требованиями, нужен новый подход, получивший название «Один большой RAID 10» — то есть единый крупный массив RAID 10, в котором совместно хранятся операционная система, приложения и данные. Конечно, это лишь удобное обозначение: в системе, где нет потребности в производительности или объёме сверх одного диска, говорят «Один большой RAID 1», но поскольку многие включают RAID 1 в группу RAID 10, первый вариант попросту удобнее.

Для краткости мы сокращаем это до OBR10.

Поскольку стоимость хранения значительно снизилась и из дефицитного ресурса превратилась в нечто, как правило, имеющееся в избытке, поскольку файловые системы невероятно надёжны, поскольку RAID 1 и RAID 10 обладают схожими характеристиками производительности, а отказы массивов, не связанные с отказами дисков, превратились из фонового шума в основную причину потери данных — переход к RAID 10 и отказ от разделения массивов стал новым стандартным подходом.

С RAID 10 мы теперь имеем высокодоступное и отказоустойчивое хранилище, прежде предназначавшееся исключительно для операционной системы, для всех наших данных. Мы получаем преимущества производительности зеркального RAID плюс выигрыш от дополнительных шпинделей для всех данных. Мы получаем лучшее использование ёмкости дисков и производительность, обусловленную этим улучшением.

Даже традиционное разделение лог-файлов, обычно применяемое в базах данных (печально известный подход RAID 1 + RAID 5 + RAID 1), больше не нужен, поскольку RAID 10 обеспечивает оптимальные характеристики производительности для всех данных. С RAID 10 мы устраняем почти все факторы, когда-то вынуждавшие нас разбивать массивы.

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

Сегодня конкуренция за диск по-прежнему существует, однако значительно сглажена благодаря использованию больших кэшей RAID. В конце 90-х кэш дисков составлял в лучшем случае несколько мегабайт, а нередко и вовсе отсутствовал. Сегодня 256 МБ — это крошечный кэш, а среднестатистические серверы развёртываются с 1–2 ГБ кэша только на RAID-контроллере. Некоторые системы начинают интегрировать дополнительные кэши на основе твердотельных накопителей, формируя вторичный кэш помимо кэша памяти на контроллере. Они легко добавляют сотни гигабайт чрезвычайно быстрого кэша, способного буферизовать практически любые операции со шпинделями, не беспокоясь о конкуренции. Таким образом, проблема конкуренции за последние годы была решена иными методами, и, как и другие технологические изменения, эффективно освободила нас от традиционных проблем, требовавших разделения массивов.

Как и конкуренция за массив, другая, значительно более редкая причина разделения массивов в конце 1990-х — повышение производительности коммуникационной шины из-за ограничений технологий SCSI и ATA того времени. Они тоже ушли в прошлое с переходом к последовательным механизмам связи — SAS и SATA — в современных массивах. Мы больше не ограничены пропускной способностью единственной шины для каждого массива и можем масштабироваться значительно больше и гибче, чем прежде. Конкуренция за шину практически полностью устранена.

Если необходимо выделить пространство для защиты, например от неконтролируемого роста лог-файлов, это можно реализовать через партиционирование, а не через физическое разделение массивов. В целом следует стремиться к минимизации партиционирования, поскольку оно увеличивает накладные расходы и снижает способность дисков к самонастройке, — однако бывают случаи, когда этот подход предпочтительнее. При этом он не требует разделения лежащего в основе физического хранилища, как это делалось традиционно. Ещё лучше партиционирования, при наличии такой возможности, является управление логическими томами (LVM), обеспечивающее разделение, подобное разделению на разделы, без их ограничений.

Итак, новое правило большого пальца для серверного хранилища — «Один большой RAID 10». Никакого RAID 5, никакого разделения массивов. Это вопрос надёжности, производительности, простоты управления и умеренной экономической эффективности. Как и любое правило большого пальца, оно неприменимо абсолютно в каждом случае, однако охватывает значительно более широкий круг ситуаций, чем прежний стандарт. RAID 1 + RAID 5 в качестве стандарта всегда было попыткой «сделать что-то из ничего» и извлечь максимум из неудовлетворительной ситуации. OBR10 — не такой подход. Новый стандарт — это желаемый стандарт: именно так мы хотим работать, а не то, с чем нам пришлось «смириться».

При проектировании хранилища для нового сервера начинайте с OBR10 и отступайте от него лишь тогда, когда он конкретно не отвечает вашим технологическим потребностям. Вам никогда не придётся обосновывать использование OBR10 — нужно обосновывать лишь отказ от него.