Я хочу создать, назовем его недорогим Ra * san, который будет размещать для нашего социального сайта изображения (многие миллионы), у нас есть 5 размеров каждой фотографии с 3 КБ, 7 КБ, 15 КБ, 25 КБ и 80 КБ на изображение.
Моя идея состоит в том, чтобы создать сервер с 24x потребительскими твердотельными накопителями емкостью 240 ГБ в Raid 6, что даст мне около 5 ТБ дискового пространства для хранения фотографий. Чтобы иметь HA, я могу добавить второй и использовать drdb.
Я хочу получить более 150 000 IOPS (случайное чтение 4K).
Поскольку в большинстве случаев у нас есть доступ только для чтения и мы редко удаляем фотографии, я думаю, что лучше выбрать потребительский MLC SSD. Я прочитал много обзоров на выносливость и не вижу в этом проблемы, пока мы не переписываем ячейки.
Что вы думаете о моей идее? - Я не уверен между Raid 6 или Raid 10 (больше IOPS, стоит SSD). - Подходит ли ext4 для файловой системы - Используете ли вы 1 или 2 контроллера Raid с объединительной платой Extender
Если бы кто-нибудь реализовал что-то подобное, я был бы счастлив получить цифры реального мира.
ОБНОВИТЬ
Мне нужно купить 12 (плюс несколько запасных) SSD-накопителей OCZ Talos 480 ГБ SAS, они будут помещены в DAS с 12 отсеками и подключены к контроллеру PERC H800 (1 ГБ NV Cache, производства LSI с fastpath), я планирую установить Raid 50 с ext4. Если кто-то интересуется некоторыми тестами, дайте мне знать, что вы хотели бы увидеть.
Используйте RAID6 поверх RAID10. Для загрузок ввода-вывода, основанных в основном на чтении, пропускная способность должна быть аналогичной, когда массив не ухудшается, вы получаете лучшую избыточность (любой два диска могут выйти из строя одновременно с R6, R10 не может работать, если оба неисправных диска находятся на одной ноге (так что может выжить только четыре из шести комбинаций сбоя двух дисков в массиве из 4 дисков, я не уверен в верхней части моей головы, как эта цифра 4/6 масштабируется для больших массивов)), и вы получите больший полезный размер массива, если вы не разместите диски в подмассивах с 4 дисками (см. ниже).
Ваш расчет пространства отсутствует, конечно, для RAID10. 24 * 240 ГБ - это 5760 ГБ без избыточности (RAID0 или JBOD). С RAID10 вы получите только 2880 ГБ, так как (обычно) есть две точные копии каждого блока. Если вы используете все диски как один большой массив RAID6, вы получите 5 ТБ (5280 ГБ, два диска с информацией о четности, распределенной по массиву), но я лично был бы более параноиком и создавал бы меньшие массивы RAID6 и присоединял их к RAID0 или JBOD - таким образом у вас будет более короткое время восстановления при замене дисков, и вы можете выжить во многих случаях одновременно с отказом большего количества дисков (два диска на каждую ногу могут умереть, а не два диска из 24, без того, чтобы массив стал бесполезным). С четырьмя дисками на ногу вы получаете такой же объем пространства, как RAID10. Четыре массива по 6 дисков могут быть хорошим компромиссом (4 * 4 * 240 = 3840 ГБ полезного пространства) или три массива по 8 дисков (3 * 6 * 240 = 4320 ГБ полезного пространства).
Что касается контроллеров: они могут быть единственной точкой отказа для RAID. Если контроллер умирает, вы теряете сразу все подключенные к нему диски. Хотя такие сбои довольно редки (чаще встречается случайное повреждение), нет ничего плохого в том, чтобы уменьшить влияние, если оно произойдет с вами. Если вы используете RAID10, убедитесь, что ни одна пара дисков не подключена к одному контроллеру (что означает наличие как минимум двух). При разделении на 4-дисковые массивы RAID-6 используйте четыре контроллера и по одному диску или заданному массиву на каждом. Это, конечно, предполагает, что вы используете программный RAID и простые контроллеры, что может быть маловероятным (вы тратите столько на диски, вы также можете получить несколько приличных аппаратных контроллеров RAID!).
Вам также следует подумать о решении для резервного копирования, если вы еще этого не сделали. RAID защитит вас от определенных аппаратных сбоев, но не от многих человеческих ошибок и других потенциальных проблем.
Я бы рассмотрел гибридное решение, которое можно было бы реализовать с помощью OpenSolaris, SolarisExp 11, OpenIndiana или Nexenta. Гибридный пул будет намного дешевле, а с оперативной памятью на несколько тысяч долларов у вас будет 150 тыс. Операций ввода-вывода в секунду с в основном обычными вращающимися дисками. В Nexenta очень много клиентов, которые делают именно это. ZFS - это надежная файловая система, и при наличии достаточного количества ОЗУ и / или твердотельных накопителей для дополнительного кэширования чтения / записи вы можете получить очень надежное решение по относительно низкой цене. С Nexenta Core, являющейся сообществом, вы получаете 18 ТБ бесплатно. Конечно, новый выпуск OpenIndiana позволит использовать многие из тех же функций. Добавьте к этому моментальные снимки, клонирование, репликацию с использованием ZFS send / recv, и вы сможете построить сеть SAN, которая даст любой EMC возможность заработать за свои деньги по гораздо более низкой цене. Много SSD хороши, но есть и другие варианты, некоторые неплохие.
Отвечая на ваши ключевые вопросы:
RAID 6 против RAID 10: вам почти наверняка не нужно беспокоиться об IOPS, если вы используете SSD в качестве основного хранилища.
SLC против MLC: Есть более тонкие различия. Если вы собираетесь использовать MLC, я бы предложил купить Intel. В серии Intel 320 есть счетчик SMART, который можно использовать для отслеживания степени износа в процентах и замены диска до того, как он выйдет из строя.
Однако вы можете взглянуть на ZFS в ОС Nexenta (или, возможно, на FreeBSD, если вы не уверены в статусе разработки), если хотите использовать твердотельные накопители для повышения производительности хранилища надежным способом:
ZFS позволяет создавать массив «RAID-Z2» (что-то вроде RAID-6) из обычных дисков, которые используют твердотельные накопители в качестве кешей массивного чтения (L2ARC) и записи (ZIL), что позволяет получить желаемые преимущества производительности. для без стоимости массива all-Flash.
Часто используемые блоки будут считываться с твердотельных накопителей, а менее часто используемые блоки по-прежнему будут считываться с диска. Все операции записи сначала будут идти на SSD и фиксироваться на диске, когда это удобно для массива.
Поскольку вам понадобится меньше твердотельных накопителей, вы будете покупать устройства более высокого качества, и у вас не будет катастрофического сбоя, которого можно ожидать, если вы построите RAID-массив из устройств MLC потребительского уровня от OCZ (или чего-то еще).
Даже если вы не используете качественные устройства, последствия будут менее серьезными. Если вы используете устройства MLC для своей ZFS L2ARC и они не работают, ваши данные все равно сохраняются на диске.
Просто купи два FusionIO Octal карты и зеркально отображать их - намного проще и быстрее (однако может быть немного дороже).
150 тыс. Операций ввода-вывода в секунду с блоками 4 тыс. - это пропускная способность 585 Мбит / с. Убедитесь, что ваш контроллер и объединительная плата справятся с этим. Что касается рейда, помните, что защита от сбоев SSD - это все, что вам нужно. Сбой контроллера (или сбой памяти, сбой процессора или сбой любой другой единственной точки отказа на сервере) сделает ваши данные непригодными для использования. Необходимо поддерживать синхронизацию другого идентичного сервера, чтобы избежать простоев и, возможно, необходимости вернуться к ленте.
Этот второй сервер, если он заполнен твердотельными накопителями, такими как первый, может сделать его почти дешевле, если будет почти дешевле купить централизованное устройство хранения, поддерживающее SSD, если у него нет единых точек отказа. Однако если вы синхронизируете второй сервер с использованием реальных жестких дисков, вы можете сохранить большую часть изменений, не влияя на производительность. Поскольку большая часть операций ввода-вывода выполняется при чтении, нагрузка на диски будет минимальной, за исключением случаев, когда основной сервер отключен. Это даст вам финансовую гибкость, чтобы купить более одной цели репликации и, возможно, даже переместить некоторые объекты за пределы площадки в случае отказа сайта.
Вы можете полностью избежать проблемы с RAID-контроллером, используя ZFS - он может обнаруживать И ИСПРАВИТЬ незаметное повреждение (ошибки данных, прошедшие проверки ECC), которые практически ни один RAID-контроллер не может обнаружить (обнаруживать да, но не исправлять) и на больших дисков (2 ТБ +) можно ожидать 1-2 ошибки в год на каждый диск.
К сожалению, если вы хотите этого с поддержкой поставщика, вам необходимо использовать Solaris. Некоторые поставщики Linux поддерживают его, но это все еще бета-продукт (тем не менее, я использую его в Linux, и я обнаружил, что его практически невозможно убить, вплоть до вытаскивания нескольких дисков из их отсеков, пока они горячие. В худшем случае массив закрывается вниз - но нет повреждения данных)
Выполнение всего этого на одном сервере с дорогими дисками может быть не лучшим решением. Учитывая ваш бюджет и потребности, я бы рекомендовал взглянуть на STF. Он был разработан как хранилище изображений для одного из крупнейших сервисов ведения блогов в Японии: