для SQL сервера стандартно выделяется отдельный диск для данных, отдельный диск для лог файла.( про темп не важно)
когда появляется СХД, диску на уровне ОС уже не соответствует физический диск и соблюдение исходного правила уже не так очевидно.
(я не рассматриваю вариант когда отдельному логическому диску соответствует отдельный рейд.)
у меня 8 дисков, 1 - горячая замена, 1 - холодный резерв, остальные 6 только для sql сервер.
заранее уточню-анализ стоимости не важен;соотношение запись/чтение не известно; железо качественное; уровень рейда Y - самый оптимальный,
чтобы не было споров; и очень важно чтобы не было фрагментации индексов!!
Например, я на этих 6 дисках делаю рейд Y. а потом его режу на 2 lun, и на уровне операционки ( windows) диски уже не делю.
поскольку мои оба диска размазаны по одному рейду - я не вижу причины выделять отдельные диски для BD и LOG кроме одной:
в случае когда на таком логическом диске лежит только один файл - фрагментация файла минимальная.
но прав ли я, может быть что минимальная фрагментация на уровне логического диска ОС не означает что реальная фрагментация на уровне физических дисков тоже оптимальна?
1) есть ли еще причины (кроме фрагментации) выделять отдельные логические диски для bd и log? или тупо отдавать в ОС одним диском.
2) как, по Вашему, правильно сформулировать требования к организации дисковой полки для SQL сервера ( без дополнительных ньюансов, с учетом только исходных условий)?
И еще докучи 3 вопроса
3) когда рейд делится на диски - физические области под диски всегда резервируются сразу или это зависит от контроллера?
4) если контроллеров на полке 2 и имеется функциия multipath в каком случае это может реально повысить производительность?
5)и совсем глупый: больше дисков в рейде -больше вероятность креша, а что говорит бест практикс?
схд для sql, виртуальный - физический уровни
Модераторы: Trinity admin`s, Free-lance moderator`s
Re: схд для sql, виртуальный - физический уровни
1. это обсуждение сферических коней в вакууме. все зависит от характера нагрузки. в целом, правильным является разнесение логов и данных на разные "логически" шпиндели. т. е. не только на разные LUN'ы, но и на разные рейд группы.4olegn писал(а): 1) есть ли еще причины (кроме фрагментации) выделять отдельные логические диски для bd и log? или тупо отдавать в ОС одним диском.
2) как, по Вашему, правильно сформулировать требования к организации дисковой полки для SQL сервера ( без дополнительных ньюансов, с учетом только исходных условий)?
И еще докучи 3 вопроса
3) когда рейд делится на диски - физические области под диски всегда резервируются сразу или это зависит от контроллера?
4) если контроллеров на полке 2 и имеется функциия multipath в каком случае это может реально повысить производительность?
5)и совсем глупый: больше дисков в рейде -больше вероятность креша, а что говорит бест практикс?
2. правильно сформулировать требования можно, когда известен объем данных, приблизительное количество IOPS, ожидаемое от системы время отклика, характер нагрузки на базу (соотношение RW)
3. обычно - НЕ сразу, но зависит от контроллера.
4. multipath'инг повышает производительность, если контроллеры - Active/Active. в системах, типа DS3k/4k/5k - балансировки по путям на два разных контроллера не получится (впрочем - можно делать балансировку в пределах одного контроллера)
5. бест практис советует иметь хот-спару

Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 5 гостей