Мы настраиваем несколько виртуальных машин (около 250) для клиента, который в основном использует приложение, написанное на LAMP + Java, с небольшими настройками в каждом из этих 250 экземпляров. По сути, каждое приложение можно рассматривать как веб-приложение, которое может масштабироваться примерно до 200-500 ГБ данных (в основном файлов) и примерно до 1-1,5 ГБ размером базы данных MySQL.
В нашем распоряжении стандартная стойка 42 U, и мы рассматриваем такую архитектуру.
1) Запустите 250 Vms примерно на 14 2x четырехъядерных / 6-ядерных серверах 1U с 32 ГБ RAM 250 ГБ SAS 15 тыс. Об / мин x 2 (RAID 1). Базовое приложение удобно умещается в пределах 2 ГБ, включая операционную систему
2) Иметь выделенный набор серверов баз данных MySQL размером 1 U с включенным SAS 300 ГБ x 3 (RAID 5 H / w). Добавьте больше, если нам нужно увеличить масштаб
3) Иметь кучу JBOD (около 6) емкостью 30 ТБ для хранения с переключением при отказе 1: 1. То есть каждый 30 ТБ JBOD имеет зеркальный 30 ТБ JBOD. Они будут использоваться для хранения файлов, которые в основном состоят из PDF, Word, Excel, JPG и некоторых файлов фильмов.
Каждое приложение будет иметь около 2-10 одновременных пользователей в течение дня, которые будут писать в базу данных, а также загружать файлы. Это бизнес-приложение, в котором ежедневные транзакции каждого отдела хранятся в цифровом виде. Может быть несколько сотен просмотров страниц или попыток загрузить некоторые документы, загруженные для каждого приложения.
Приблизительно это будет составлять на необработанных серверах NAS в течение 10 часов рабочего времени, где-то около 250 000 операций чтения и записи. Аналогичная нагрузка ожидается на серверах MySQL.
Мы не хотим вкладывать средства в ящики для хранения от EMC, NetAPP или других крупных поставщиков хранилищ из-за нехватки средств. Фактически мы рассматриваем возможность использования массивов 30 ТБ на основе RAID 0, при этом каждый массив будет зеркалирован на другой массив. Таким образом, в случае любой неисправности резервная коробка вступает во владение, давая нам достаточно времени для переключения. У нас есть запасные шасси 3 U с 15 отсеками для дисков с возможностью горячей замены. Мы рассматриваем возможность использования процессоров Dual Xeon с 16 ГБ ОЗУ ECC на каждом, а также думаем о программном RAID вместо H / W RAID на каждой коробке. Идея состоит в том, что с мощными процессорами программные RAID должны работать лучше, чем H / W RAID.
Мы получили некоторую критику, в первую очередь, от некоторых поставщиков, которые хотят, чтобы мы купили их специальные ящики для хранения. С какими проблемами производительности мы можем столкнуться. У меня есть друг, бывший системный администратор Amazon, который сказал, что такая архитектура очень похожа на ту, что используют Amazon или Google, и указал, что, поскольку мы фактически не настраиваем общедоступный веб-сайт, который может потенциально иметь миллионы обращений, эта архитектура достаточно хороша. Он также сказал мне, что программный RAID в системах UNIX работает так же хорошо, как H / w RAID. Это причина того, что на большинстве серверов в Google или других местах на самом деле стоят очень недорогие компьютеры.
Я хотел бы получить второе мнение о том же .....
Для 3) я бы использовал HW-Raid 5. Это хороший компромисс между скоростью и доступностью. Вы же не хотите повторно зеркалировать 30 ТБ. Во время этого повторного зеркалирования вы можете потерять дополнительный диск.
Я бы также рекомендовал использовать HW-Raid из-за его способности предупреждать о сбое диска и его способности выполнять автоматическое восстановление.
Кроме того, его намного проще настроить и поддерживать. С HW-Raid я говорю о реальных рейд-контроллерах, которые представляют рейды как диски для ОС.
Фактически мы рассматриваем возможность использования массивов 30 ТБ на основе RAID 0, при этом каждый массив будет зеркалирован на другой массив. Таким образом, в случае любой неисправности резервная коробка вступает во владение, давая нам достаточно времени для переключения.
Если я здесь чего-то не упускаю, это опасная установка. При отказе одного диска во втором массиве будет утерян весь набор данных. Это очень вероятный сценарий, когда вы говорите о массивах, по крайней мере, с 10 дисками каждый.
У Amazon и Google есть свои собственные выделенные технологии хранения, специально разработанные для хорошей работы с их аппаратным обеспечением (множество дешевых разрозненных устройств). В частности, их программное обеспечение обнаруживает сбои в блоке хранения и постоянно гарантирует, что каждый элемент хранится как минимум в x дополнительных местах. Когда устройство хранения выходит из строя, всему его содержимому немедленно добавляется новый дубликат в какой-то другой пул хранения. Если вы не используете подобное программное обеспечение для своего уровня хранения, вы не можете использовать их в качестве основы для сравнения.
Что касается поставщиков - это правда, что вы потенциально можете обойтись без массива от одного из крупных корпоративных игроков - NetApp / EMC или аналогичного. Их хранилище предназначено для таких вещей, как запуск множества одновременных виртуальных машин прямо с них. Однако вы говорите о глупом NAS, обслуживающем плоские файлы ... гораздо более простой вариант использования, а накладные расходы и случайность вашего ввода-вывода значительно уменьшаются. Тем не менее, вы все равно захотите рассмотреть как минимум RAID 6.
Какая у вас стратегия резервного копирования?