Как лучше разбить внешний массив под БД SQL 2005
Модераторы: Trinity admin`s, Free-lance moderator`s
-
- Advanced member
- Сообщения: 137
- Зарегистрирован: 15 дек 2005, 18:39
- Откуда: Харьков
- Контактная информация:
Как лучше разбить внешний массив под БД SQL 2005
Добрый день, господа! Вопрос у меня к Вам по поводу разбивки внешнего стораджа (EVA) или даже не важно какого внешнего массива...используя преймущества виртуализации EVA и не очень большой размах у нас (да я думаю и везеде вопрос на перепутье какой Raid выбирать 5 или 10)по дисковому протранству как стоит разбивать на LUN-ы? Например, если у нас будет 3 базы SQL стоит разбивать на 3 LUN-ы и что базу что Log-файл ложить в одну и ту же LUN. Или стоит разбить на 6 и разделить по отдельности базу и логи, но так как места мало базу сделать Raid-5 и логи в Raid-10??? Понятное дело со своим количеством шпинделей...И какой придел может быть у одной дисковой группы на EVA (количество шпинделей)?40-50? Что бы не потерять в производительности или в чем то ещё, когда контроллер будет обрабатывать массив с таким количеством винтов...Заранее спасибо! Буду ждать ответ!
-
- Advanced member
- Сообщения: 137
- Зарегистрирован: 15 дек 2005, 18:39
- Откуда: Харьков
- Контактная информация:
На этапе внедрения планируется 2 базы 1С на SQL2005, пользователей от 30 до 50. Объем баз ~100-150Гб (на этапе внедрения-потом будет расти понятноедело). Дисков под данную конфигурацию EVA 4100 пока 20шт (146Гб 15000rpn). Потом в зависимости от нагрузки планируется до 40 винтов (и наверное одна илидве базы...). На этой же полке планируется загружать ОС с SQL серверов (3шт) и наверное будет кластер n+1.
-
- Advanced member
- Сообщения: 137
- Зарегистрирован: 15 дек 2005, 18:39
- Откуда: Харьков
- Контактная информация:
Но ещё планируется бить на LUN-ы массив для ОС, которая будет здесь же находиться (на EVA)...Вопрос в чем...Лучше сам массив бить ВЕСЬ сразу (а потом добавлять, если необходимо), что бы все винты участвовали в работе, а потом разбить на LUN-ы: одна под базу, одна под вторую, и так же разбить для Логов...Или как в предыдущем ответе 12 выделить под данные, а 6 под логи?Как то это не ствкуется...(или это имелось ввиду, что 12 дисков будут входить в состав LUN-ы, но это не правильно в тношении EVA, там же совсем по другому постороена логика разбивки и как такового и нет Spare дисков...они весьма специфическим образом скрыты в дисковой группе). И вопрос самый главный начиная со скольки дисков начинаются проблемы в одной дисковой группе?
P. S. Когда же придут спецы HP?
Хотелось бы услышать их мнение...
Эти впросы направлены, на то что бы определить "политику" разбития такого класса массива с самого начала введения проекта в работу. И если определиться, что проблема в дисковой подсистеме, то будет второй этап проекта в котором будут докуплены винты. На данном этапе желательно услышать мнение как бить?Ну конечно не кувалдой...
Вопрос специфичный, но просто так бы я думаю на форуме вопросы такого плана не задают...Я надеюсь меня поняли, в плане какой вопрос я задаю вообще и в конкретном случае (количество баз и людей...) Жду ответа!И заранее спасибо!
P. S. Когда же придут спецы HP?

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

- exLH
- Сотрудник Тринити
- Сообщения: 5061
- Зарегистрирован: 11 фев 2004, 15:49
- Откуда: Москва
- Контактная информация:
mishanya_f
P. S. Когда же придут спецы HP?
Ничего особенного при таком числе дисков советовать нечего.
Прочитайте документ по ссылке и все станет понятно:
http://h71028.www7.hp.com/ERC/downloads ... 787ENW.pdf
P. S. Когда же придут спецы HP?
Ничего особенного при таком числе дисков советовать нечего.
Прочитайте документ по ссылке и все станет понятно:
http://h71028.www7.hp.com/ERC/downloads ... 787ENW.pdf
1) Самый правильный совет - читать "best practices". Это вообще без вопросов и не обсуждается!
2) я не вчитывался в задачу и не собираюсь это делать, но пару слов скажу.
Максимальный размер дисковый группы в EVA = максимальное кол-во дисков (шпинделей массива). То есть если в массиве 240 дисков, то можно сделать одну большую дисковую группу из 240 шпинделей.
Минимальный размер дисковой группы - 8 дисквов.
И в этой дисковой группе создавать vdisk (виртуальные диски/LUN)
Уровень RAID - это параметр vdisk'а. В одной дисковой группе может быть множество vdisk, с разными уровнями RAID (1,5,0)
При этом каждый vdisk ляжет поперёк всех шпинделей в группе.
Размер vdisk'а вы выбираете с шагом в 1 Гб, от 1Гб до 2 Тб.
Читайте "best practices", там сказано, если Вы хотите наилучшую производительность, Вы должны сделать одну большую дисковую группу.
Если Вы хотите оптимизировать доступность, то дисковых групп может быть (но не обязательно) 2. Одна для датафайлов, другая для журнала базы данных.
Короче - одна большая дисковая группа и будет Вам счастье.
2) я не вчитывался в задачу и не собираюсь это делать, но пару слов скажу.
Максимальный размер дисковый группы в EVA = максимальное кол-во дисков (шпинделей массива). То есть если в массиве 240 дисков, то можно сделать одну большую дисковую группу из 240 шпинделей.
Минимальный размер дисковой группы - 8 дисквов.
И в этой дисковой группе создавать vdisk (виртуальные диски/LUN)
Уровень RAID - это параметр vdisk'а. В одной дисковой группе может быть множество vdisk, с разными уровнями RAID (1,5,0)
При этом каждый vdisk ляжет поперёк всех шпинделей в группе.
Размер vdisk'а вы выбираете с шагом в 1 Гб, от 1Гб до 2 Тб.
Читайте "best practices", там сказано, если Вы хотите наилучшую производительность, Вы должны сделать одну большую дисковую группу.
Если Вы хотите оптимизировать доступность, то дисковых групп может быть (но не обязательно) 2. Одна для датафайлов, другая для журнала базы данных.
Короче - одна большая дисковая группа и будет Вам счастье.
-
- Advanced member
- Сообщения: 137
- Зарегистрирован: 15 дек 2005, 18:39
- Откуда: Харьков
- Контактная информация:
За Best practices спасибо! Знал, что есть, но руки не доходили прочитать. Спасибо Nesk за объяснение как устроена EVA и как с ней работать...Но это я знаю и как разбивать и что такое виртуализация на EVA и все что с ней связано. И что если загнать все в одну дисковую группу, то будем мне счастье и очень хорошая производительность. Но так ли это? Может есть какие то моменты или в самом контроллере или проблема в зеркальном кеше, например, или в чем то ещё, что не позволит получить прирост начиная с какого то количества дисков в дисковой группе...Если такого нет (а я уверен что про это в Best practices не строчки не напишут-а будут слова все в ОДНО), то стоит создавать одну дисковую группу и в нее добавлять по мере поступления диски и так сначала до 56, потом до 112 и потом до 240. Я как бы поднял тему как бы, Best practices людей, которые пользовались данным массивом и имеют какие то наработки по наилучшей оптимизации данного массива.
И кстати ещё на этом массиве в дальнейшем будет лежать база данных Exchange и может файловая помойка...Это различные типы баз данных и по разному оптимизируются в общем случае и работают. Так вот, стоит ли одной группой все делать, а потом бить на Vdisk-и или под каждый тип данных нужен в конечном итоге своя дисковая группа? Или разныие типы данных в реаальности контроллеру до лапмочки и не стоит заморачиваться на это...?
Заранее спасибо!
И надеюсь довел до вас суть вопроса.
И кстати ещё на этом массиве в дальнейшем будет лежать база данных Exchange и может файловая помойка...Это различные типы баз данных и по разному оптимизируются в общем случае и работают. Так вот, стоит ли одной группой все делать, а потом бить на Vdisk-и или под каждый тип данных нужен в конечном итоге своя дисковая группа? Или разныие типы данных в реаальности контроллеру до лапмочки и не стоит заморачиваться на это...?
Заранее спасибо!
И надеюсь довел до вас суть вопроса.
mishanya_f
под обычную нагрузку типа БД ,эксч,файлопомойки и тд и тп , ОДНА большая группа, на которой нарезаются vDIskи. Контроллерам действительно до лампочки( при кол-ве дисков около 120 , HSV 200 может стать узким местом, поэтому в ева 8000 HSV 210)
на моёй практике правило одной группы не действовало только в одном случает, когда собирали SFS, но там очень специфический IO.
под обычную нагрузку типа БД ,эксч,файлопомойки и тд и тп , ОДНА большая группа, на которой нарезаются vDIskи. Контроллерам действительно до лампочки( при кол-ве дисков около 120 , HSV 200 может стать узким местом, поэтому в ева 8000 HSV 210)
на моёй практике правило одной группы не действовало только в одном случает, когда собирали SFS, но там очень специфический IO.
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 7 гостей