Назад | Перейти на главную страницу

RAID-массивы с большим количеством шпинделей - как безопасно использовать «потраченное впустую» пространство

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

Я предполагаю, что это универсальная проблема, поскольку производители предлагают самые маленькие диски емкостью 300 ГБ, но производительность произвольного ввода-вывода на самом деле не сильно выросла с тех пор, как самые маленькие диски были 36 ГБ.

Одним из примеров является база данных, имеющая 300 ГБ и требующая произвольной производительности 3200 операций ввода-вывода в секунду, поэтому она получает 16 дисков (4800 ГБ минус 300 ГБ, а у нас 4,5 ТБ потраченного впустую пространства).

Другой распространенный пример - журналы повторов для базы данных OLTP, которые чувствительны к времени отклика. Журналы повтора получают собственное зеркало на 300 ГБ, но занимают 30 ГБ: 270 ГБ потрачено впустую.

Я хотел бы видеть системный подход как для Linux, так и для Windows. Как настроить пространство, чтобы группа системных администраторов получала напоминания о риске снижения производительности основной базы данных / приложения? Или, что еще лучше, защитить себя от этого риска? Типичная ситуация, которая приходит мне на ум: «О, у меня есть этот очень большой zip-файл, где мне его распаковать? df -h и мы что-то выясним в кратчайшие сроки ... "Я не делаю упор на строгость безопасности (системные администраторы доверяют добросовестным действиям), а на общую простоту подхода.

Для Linux было бы здорово настроить файловую систему для ограничения скорости ввода-вывода на очень низком уровне - возможно ли это?

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

LUN-ы, перегородки и выборочное представление ресурсов ...

Тот факт, что SAN поддерживается 16 дисковыми шпинделями, не означает, что серверу, потребляющему эти данные, необходимо видеть всю емкость массива. То же самое и с хранилищем с прямым подключением. Бывают случаи, когда у меня может быть большое количество дисков в массиве, но я все равно подбираю размер LUN / раздела / устройства, представленного операционной системе.

В приведенном ниже примере контроллера HP ProLiant SmartArray показаны 4 твердотельных накопителя по 480 ГБ в массиве RAID 1 + 0. Это 960 ГБ. Я вырезал LUN на 400 ГБ из этих 960 ГБ. Операционная система видит только 400 ГБ. И даже эти 400 ГБ разбиты на логические части, которые имеют смысл для приложения. Дело в том, что вы можете контролировать, что видят потребители хранилища:

   array B (Solid State SATA, Unused Space: 1012121  MB)


      logicaldrive 3 (400.0 GB, RAID 1+0, OK)

      physicaldrive 1I:1:3 (port 1I:box 1:bay 3, Solid State SATA, 480.1 GB, OK)
      physicaldrive 1I:1:4 (port 1I:box 1:bay 4, Solid State SATA, 480.1 GB, OK)
      physicaldrive 2I:1:7 (port 2I:box 1:bay 7, Solid State SATA, 480.1 GB, OK)
      physicaldrive 2I:1:8 (port 2I:box 1:bay 8, Solid State SATA, 480.1 GB, OK)

Но, в конце концов, если производительность соответствует вашим потребностям и организация может позволить себе текущую конфигурацию, почему вы считаете неиспользуемое пространство «потраченным впустую»?

Кстати - Это является возможно регулирование ввода-вывода в Linux на уровне блочного устройства используя контрольные группы. Но если есть риск для ваших основных приложений или баз данных, почему бы не разделить рабочие нагрузки?