Учитывая следующие параметры, как я могу оценить требования к дисковой подсистеме?
Среда представляет собой общедоступный веб-сервер для доставки больших файлов множеству одновременно работающих пользователей.
Несмотря на то, что это большие файлы, я полагаю, что мне следует оценить где-то между чисто случайным вводом-выводом и чистым последовательным вводом-выводом. Я думаю, что с более быстрыми / меньшим количеством клиентов он будет иметь тенденцию к последовательному, а с более медленными / большим количеством клиентов он будет иметь тенденцию к случайному. Надеюсь, это правильно?
Поэтому я думаю сначала рассчитать «ожидаемый IOPS». Это то, на чем я застрял. Я предполагаю, что смогу приблизиться, используя следующие параметры: размер рабочего набора, средняя скорость клиента и ожидаемые одновременные клиенты.
Отсюда я могу посмотреть на рейтинги IOPS дисков и RAID-контроллеров и сделать приблизительную оценку дисковой подсистемы, необходимой для обслуживания набора файлов для такого количества пользователей.
Очевидно, что это еще не все, например упреждающее чтение и объем оперативной памяти, доступной для кэширования, а также размер блока файловой системы, ширина полосы RAID и т. Д., Но я полагаю, что если я основываю его на 0 упреждающем чтении и 0 ОЗУ, это должен дать мне грубую пессимистическую оценку.
Может ли кто-нибудь с опытом в этой области сообщить мне, на правильном ли я пути, и / или дать какие-либо советы о том, как рассчитать некоторые из этих значений?
Если есть сайты, которые обсуждают это или книги, которые я могу купить, я очень хочу это сделать, но я искал 2 дня без особого успеха. Когда дело доходит до хранения, я немного не в себе.
Я также понимаю, что мне придется провести сравнительный анализ, чтобы получить правильный ответ, но я хотел бы сначала сделать как можно больше оценок.
Любая помощь приветствуется, пламя приветствуется!
Одна область, которую вы, кажется, упустили, - это ожидаемая максимальная скорость передачи. Кроме того, вы почувствуете, насколько «шумна» ваша кривая IOPS. Если он очень шумный, у вас могут быть длительные периоды значительно превышающих средний показатель IOPS, и это тот случай, когда вам нужно будет спроектировать. По опыту, некоторые из самых больших скачков IOPS происходят при больших передачах, и если эти большие передачи каким-то образом насыщают вашу подсистему ввода-вывода, другие действия во время этих передач пострадают.
Следует учитывать пиковые нагрузки, поскольку вы хотите адекватно работать, когда они возникают. Это может означать, что ваша система постоянно недоиспользуется, но это связано с территорией. Мы создаем минимальную гарантию обслуживания в рамках ожидаемого диапазона нагрузки и управляемого роста, что приводит к определенному количеству неизбежных чрезмерных инженерных решений.
Другая область - это проценты операций чтения / записи ввода-вывода. Вы сказали веб-сервер, поэтому я предполагаю, что будет больше чтения, чем записи, но вам лучше знать. Если процентные значения сильно смещены в сторону чтения (скажем, 80% чтения), это повлияет на то, что вы выберете для подсистемы хранения, так как вы сможете позволить себе дорогостоящую запись, чтобы получить быстрое чтение (RAID5 или Например, RAID6). Но не слишком дорого, так как вы не хотите насыщать что-то огромной записью, которая увязнет в работе всей системы.
Как только вы получите оборудование, проверьте режимы отказа. Выясните, насколько плохо обстоят дела, когда диск вышел из строя и когда один снова добавляется. Если у вас всего пять дисков, это может не иметь большого значения, поскольку частота отказов должен быть достаточно низким, чтобы повреждение дисков происходило очень редко. Но если у вас много шпинделей (скажем ... более 10), ваша частота отказов может быть достаточно высокой, и вам придется учитывать состояние «отказ» в своих оценках. Пару лет назад мы сильно пострадали от этого, так как определенный дисковый массив серьезно ограничивался записью, когда он перестраивал набор четности (он отключал кеш записи, зло, зло), что вызывало хаос, когда кто-то пытался за это время записать на него образ компакт-диска (625 МБ!).
И, наконец, при оценке учитывайте нагрузку во время резервного копирования. Если вы собираетесь предоставлять услуги, когда резервная копия постоянно читает все на сервере, это также повлияет на то, насколько мощная система хранения у вас получится. Итак, рассмотрите служебные операции ввода-вывода, а не только созданные пользователем.
Это должно дать вам еще несколько точек данных для работы!
** изменить: * Пиковая высота ... это зависит от нагрузки. У меня есть система, которая в течение дня в среднем составляет 3-5 МБ / с с пиками в диапазоне 10-15 МБ / с, а резервное копирование может подтолкнуть его до 20-25 МБ / с. Таким образом, среднее значение составляет около 12 МБ / с, а истинный пик чуть более чем вдвое больше. Эта конкретная система не сильно страдает во время перестроения RAID, поэтому она не подлежит планированию. Кроме того, ввод-вывод, управляемый конечным пользователем, минимален в течение периода резервного копирования, поэтому мне не нужно беспокоиться о конкуренции, а это означает, что я могу запускать его во время резервного копирования, не опасаясь звонков.