Сие чудо нужно для: хранения статики портала (около 5ТБ) - поэтому и делается для этого файлый архив; обеспечения высокопроизодительности при посещаемости 100К+ хосто в день для портала; обеспечения быстрого и лёгкого техобслуживания системы в случае её краха (замена системы БЕЗ перетаскивания файлового хранилища).
Именно поэтому и дана такая конфигурации, как в первом посте.
...
Лето с задержкой поставки нужных комплектующих вносит свои коррективы: прочтя нужные мануалы, смоделировав на тестовой системе аналогичное окружение и смониторив параметры обнаружил, что:
- система ставится на одиночный диск с коротким временем ответа (выбран SSD на 128ГБ);
- серверы (веб и баз данных) + файлы баз данных + панель хостинга ставятся на RAID массив из 4-х винчестеров (RAID10);
-статика ставится на самый большой и самый быстрый массив из 8-ми винчестеров (RAID10) и подключается в соответствующую папку командой bind.
При этом нагрузка по IO по всем массивам (исключая массив с OS, где она меньше) примерно выравнивается и в итоге получаем высокопроизводительный сервер.
Т.е. между о одним более медленным массивом под систему и более быстрым - под данные этот вариант быстрее по максимальному поличеству IO?
Nunkomm добавил 28.07.2010 в 19:50
На практике всегда можно проверить, только это долго и бессмысленно, если заранее известны все теоретические моменты.
Nunkomm добавил 28.07.2010 в 20:04
Это не имеет значение т.к. нужны результаты при прочих равных параметрах.
Р.S. Ещё раз пишу то, что требуется обосновать: какая дисковая подсистема будет быстрее- при создании из всех винчестеров одного массива, или при создании двух массивов (меньшего - для системы + веб-серверы nginx и apache + MySQL сервер) и большего - для всех данных (баз данных + файлового контента сайтов, подключаемых в соответствующие директории первого массива командой bind)?
Или же, если будет нагляднее в цифрах, то:
Первый вариант:
- первый массив - 4 диска RAID 10;
- второй массив - 8 дисков RAID 10;
Второй вариант: один массив на 12 дисков.
ВАЖНА СУММАРНАЯ пропускная способность на обработку запросов и не станет ли меньший (и более медленный по IO) массив "тормозом" для большего (откуда будут отдаваться данные)?
Нужно теоретическое обоснование.
Всё остальное на сервере в норме: 2xXEON 5450, 64ГБ RAM, RAID контроллер Adaptec 51645.
На обоих массивах будет рейд 10, но одни из массивов будет быстрее (за счёт большего числа дисков и объёмнее).
Нужно знать примерное процентное распределение запросов по массивам?
А теоретически?
Можно, конечно, сделать мегарейд на 16 дисков (благо контроллер подходящий на 16 портов есть).
Но хотелось бы отделить прораммную часть (файлы базы данных и файлы контента сайтов) от управляющих сервесов (веб-сервера, сервер базы данных) и поместить серверы на одном (меньшем) массиве(для возможности простого обновления системы без затрагивания данных), а данные (коих более 5ТБ) подключить bind'om с другого большого и более быстрого массива.
Только не станет ли этот меньший из массивов с веб-серверами (apache+nginx) и сервером базы данных узким местом по операциям ввода/вывода?
Конкретно хотелось бы уточнить на примере:
Если при наличии только основного массива поступил запрос на 100 операций, в каком соотношении распределяться операции по двум массивам (на одном - серверы (веб и баз данных), на другом - файлы данных)?
Да, так и пишет.
Smartd демон контролирует параметры SMART. На данный момент файловая система впорядке.
Если бы только это было причиной - было бы отлично :) Я останавливал все вервисы - не помогает.
Nunkomm добавил 11.06.2010 в 20:22
Защита была.
По крону ставить - хорошая идея. Но сейчас уже не о том речь. Главное - восстановить эту важную таблицу posts.
Таблицы в myisam
Nunkomm добавил 11.06.2010 в 20:04
Я пытался скопировать (сделать бэкап) и подменить данные файлы с данными с помощью myisamchk'oм, но повреждённые таблицы (.frm, MYD, MYI) не копируются (пишет "Ошибка чтения файла").
Таблицы слетели после DDoS атаки. Форум на IPB.
Уже пробовал. Эти таблицы не читаются даже на сервере - при попытки перенести сломанные таблицы выдаёт ошибку чтения.
А при ремонте этих таблиц в phpMyAdmin, ошибка
Corrupt wwwuser_biblio.pfields_data repair Error Incorrect information in file: './путь_к_файлу
Оно и на копирайте и на просто самописном тексте вылетает "на ура" сейчас...Первое апреля🚬
