Добрый день !
Вот появился такой вопрос.
Есть сервер MB Intel SE7501CW2, 2x Xeon 2.4 Гц 533 FSB, ОЗУ 1,5Gb
Контроллер SCSI Adaptec 2120s Cach 64 Mb.
4 HDD U320 Seagate Chita 10K 36Gb.
Собраны в RAID-5 (3 HDD + 1HDD Hot Spare).
Используется как файл-сервер (БД dbf-foxpro) и SQL сервер (Sybase ASA размер БД 40 Gb - прирост небольшой , примерно 5 Gb в год) .
Всего в сети 35 рабочих машин, с SQL работаю примерно 10, остальные с bdf.
Запустил IOMeter на сервере (OS Netware 6SP3). Вот его результаты:
Tue Apr 06 09:01:56 2004
Write statistics for volume SYS:
Writing 5120 * 1KB chunks: 14KB/sec
Writing 1280 * 4KB chunks: 57KB/sec
Writing 640 * 8KB chunks: 209KB/sec
Writing 320 * 16KB chunks: 250KB/sec
Writing 320 * 32KB chunks: 703KB/sec
Writing 160 * 64KB chunks: 737KB/sec
Writing 40 * 256KB chunks: 2164KB/sec
Writing 10 * 1024KB chunks: 3806KB/sec
Writing 10 * 5120KB chunks: 4316KB/sec
Writing 10 * 10240KB chunks: 4427KB/sec
Tue Apr 06 09:01:56 2004
Read statistics for volume SYS:
Reading 5120 * 1KB chunks: 1976KB/sec
Reading 1280 * 4KB chunks: 6243KB/sec
Reading 640 * 8KB chunks: 10239KB/sec
Reading 320 * 16KB chunks: 13128KB/sec
Reading 320 * 32KB chunks: 26256KB/sec
Reading 160 * 64KB chunks: 20479KB/sec
Reading 40 * 256KB chunks: 20897KB/sec
Reading 10 * 1024KB chunks: 31030KB/sec
Reading 10 * 5120KB chunks: 44521KB/sec
Reading 10 * 10240KB chunks: 43389KB/sec
Tue Apr 06 09:02:07 2004
[IO_Test.nlm] IO_Test ended properly
Читал в форуме что на данный контроллер достаточно медленный. Есть ли смысл перестроить конфигураци RAD-5 (ну скажем в raid10), либо при такой нагрузке особой выгоды в производительности я не получу?
P.S. Соединения сети - все клиенты на 100 Мьит, сервер свитч - 1000 Мбит.
Спасибо.[/img]
Оптимальна ли выбрана конфигурация RAID массива ?
Модераторы: Trinity admin`s, Free-lance moderator`s
-
Курдиков Сергей
- Advanced member
- Сообщения: 199
- Зарегистрирован: 27 авг 2002, 14:35
- Контактная информация:
Обратите внимание. Циклы записи выполняются на порядок медленнее, нежели циклы чтения. Это не связано с дисками. Это в основном связано с тем, что контроллер медленно считает сектора контрольных сумм.
При переходе на упаковку R-10 (или как он ещё называется R 0+1), необходимость считать контрольные суммы отпадает. Плюс к этому, подключаем дополнительный четвёртый шпиндель, который участвует в массиве.
Что будет при переходе с R-5 на R-10. Однозначно поднимутся скорости, как на чтение (немного увеличится), так и на запись (будет меньше не на порядок, а примерно в два, два с половиной раза).
Из негатива. Сжираем запасной диск. Расходование дисковых носителей становится менее экономным. Но это и так понятно.
При переходе на упаковку R-10 (или как он ещё называется R 0+1), необходимость считать контрольные суммы отпадает. Плюс к этому, подключаем дополнительный четвёртый шпиндель, который участвует в массиве.
Что будет при переходе с R-5 на R-10. Однозначно поднимутся скорости, как на чтение (немного увеличится), так и на запись (будет меньше не на порядок, а примерно в два, два с половиной раза).
Из негатива. Сжираем запасной диск. Расходование дисковых носителей становится менее экономным. Но это и так понятно.
А по надежности - останется такая же ?
Т.е. в R-5 - при выходе из строя любого диска, подключается Hot Spare. И даже при выходе еще одного - система будет работать на 2-х оставшихся (ну какое-то время по крайней мере).
А вообще для данного контроллера и системы - показания IOMeta нормальные, т.е. не медленно ли ?
Т.е. в R-5 - при выходе из строя любого диска, подключается Hot Spare. И даже при выходе еще одного - система будет работать на 2-х оставшихся (ну какое-то время по крайней мере).
А вообще для данного контроллера и системы - показания IOMeta нормальные, т.е. не медленно ли ?
Вот тут ошибочка !
raid 5 переживает выход из строя лишь одного диска, после чего массив переходит в состояние critical. Выход из строя ещё одного диска переводит массив в состояние offline .
Видимость некоторой работы - операции с кешем.
Raid 10 переживает выход из строя любого одного, и двух перекрёстных винтов.
Не переживает выход из строя двух парных (зеркалирующих друг друга).
raid 5 переживает выход из строя лишь одного диска, после чего массив переходит в состояние critical. Выход из строя ещё одного диска переводит массив в состояние offline .
Видимость некоторой работы - операции с кешем.
Raid 10 переживает выход из строя любого одного, и двух перекрёстных винтов.
Не переживает выход из строя двух парных (зеркалирующих друг друга).
Всё верно. Так всё и будет. Только переход из состояния critical в состояние optimal занимает минут этак 40-60. Понятное дело, что за это время (время ребилда), никаких катастроф с дисками произойти не должно.dingo писал(а): Возможно я что-то не так понимаю. Но если я правильно разобрался, то ситуация следующая:
Имеется Raid-5 на 3-х дисках + 1 Host Spare.
Вылетает 1 диск, массив - в critical. Автоматом подключается Hot Spare - массив в optimal. Затем например летит слдеующий диск в массиве - массив в состояние critical НО работоспособен. И есть время заменить либо Hot Spare либо вылетевший ( а вернее и то и другое).
Может быть я где-то ошибаюсь в расуждениях ?
-
Курдиков Сергей
- Advanced member
- Сообщения: 199
- Зарегистрирован: 27 авг 2002, 14:35
- Контактная информация:
Надёжность, конечно, уменшится. Мы же сожрали запасной диск на организацию R10. Данный уровень выдерживает потерю так же одного винта. У нас хоть и имеется избыточность в два раза, но софтина контроллера не позволяет потерять всю половину зеркала. Только один диск.
При подключении дополнительного винчестера в R-5 наиболее существенный прирост скажется на коротких операциях.
Про кэш Вы ничего не говорили. Конечно, алгоритм write-back даст дополнительный прирост на циклах записи. Мы адаптеком занимается реже, нежели LSI. Но цифири похожи. Игорь Вихренко (GS) из Московского отделения плотненько тестировал эти контроллеры.
Сначала меня подивила низкие показатели по записи. Адаптек хоть и медленнее, но не настолько.
Теперь, когда Вы упомянули про выключенное кэширование, всё становится на места свои.
В принципе, можно включить write-back и без батарейки. Обычно все так и делают. В нормальных, серверных кузовах процент выхода из строя блоков питания торжественно стремится к нулю. Полагаю, что УПС у Вас и так стоит. Так что потеря данных из кэша маловероятно.
При подключении дополнительного винчестера в R-5 наиболее существенный прирост скажется на коротких операциях.
Про кэш Вы ничего не говорили. Конечно, алгоритм write-back даст дополнительный прирост на циклах записи. Мы адаптеком занимается реже, нежели LSI. Но цифири похожи. Игорь Вихренко (GS) из Московского отделения плотненько тестировал эти контроллеры.
Сначала меня подивила низкие показатели по записи. Адаптек хоть и медленнее, но не настолько.
Теперь, когда Вы упомянули про выключенное кэширование, всё становится на места свои.В принципе, можно включить write-back и без батарейки. Обычно все так и делают. В нормальных, серверных кузовах процент выхода из строя блоков питания торжественно стремится к нулю. Полагаю, что УПС у Вас и так стоит.
Так что потеря данных из кэша маловероятно.Корпус используется SC5250-e (вроде бы такой, уж точно не помню).
UPS стоит
А вот такой момент, как долго при включенном кэше на запись контроллер держит инфу. Ну т.е. если мне нужно выключить сервер я даю команду down - Netware закрывает все соединени размонтирует том и вываливается в DOS. Все можно питание гасить или каое-то время нужно ждать чтобы контроллер закончил запись? Как либо можно увидеть что кэш контролера чист (кроме из BIOSa контроллера)?
Извините если не внятно объясняю , я не слишком давно начал заниматься SCSi контьролерами и всем что с ними связано
UPS стоит
А вот такой момент, как долго при включенном кэше на запись контроллер держит инфу. Ну т.е. если мне нужно выключить сервер я даю команду down - Netware закрывает все соединени размонтирует том и вываливается в DOS. Все можно питание гасить или каое-то время нужно ждать чтобы контроллер закончил запись? Как либо можно увидеть что кэш контролера чист (кроме из BIOSa контроллера)?
Извините если не внятно объясняю , я не слишком давно начал заниматься SCSi контьролерами и всем что с ними связано
Абсолютно верно, мы лишь расходимся в исходных данных,dingo писал(а): Возможно я что-то не так понимаю. Но если я правильно разобрался, то ситуация следующая:
Имеется Raid-5 на 3-х дисках + 1 Host Spare.
Вылетает 1 диск, массив - в critical. Автоматом подключается Hot Spare - массив в optimal. Затем например летит слдеующий диск в массиве - массив в состояние critical НО работоспособен. И есть время заменить либо Hot Spare либо вылетевший ( а вернее и то и другое).
Может быть я где-то ошибаюсь в расуждениях ?
я исходил из предположения что оба винта умерли одновременно (ну или с коротким промежутком).
Дело в том, что после подключения Hot Spare массив переходит в состояние optimal минут через 40 (+/- зависит от установок контроллера и ёмкости дисков).
Ага, понятьнеько. Тогда все сходится.setar писал(а): Абсолютно верно, мы лишь расходимся в исходных данных,
я исходил из предположения что оба винта умерли одновременно (ну или с коротким промежутком).
Дело в том, что после подключения Hot Spare массив переходит в состояние optimal минут через 40 (+/- зависит от установок контроллера и ёмкости дисков).
Спасибо за разъяснение
-
Курдиков Сергей
- Advanced member
- Сообщения: 199
- Зарегистрирован: 27 авг 2002, 14:35
- Контактная информация:
Во время исполнения "шатдауна" системы, драйверы устройства принудительно сливают кэш. Таким образом, вырубать машину можно безбоязненно.
Просмотреть состояние кэша невозможно по той простой причине, что его состояние довольно быстро меняется. Скажу лучше так. Я не знаю таких инструментов. Алгоритм write back подразумевает, как основную идею, отложенные операции записи на физ.устройства. Проще говоря, контроллер освободился - слил данные из кэша на диски.
Реально вызвать потерю данных можно только выдернув питание в то время, как идёт интенсивная работа с дисками. Это, конечно, слишком упрощённое описание, но в на самом деле довольно близкое к действительности. Если контроллер не сильно загружен и наблюдаются очевидные паузы в работе дисковой подсистемы, то ему нет нужды хранить данные на запись в кэше.
Просмотреть состояние кэша невозможно по той простой причине, что его состояние довольно быстро меняется. Скажу лучше так. Я не знаю таких инструментов. Алгоритм write back подразумевает, как основную идею, отложенные операции записи на физ.устройства. Проще говоря, контроллер освободился - слил данные из кэша на диски.
Реально вызвать потерю данных можно только выдернув питание в то время, как идёт интенсивная работа с дисками. Это, конечно, слишком упрощённое описание, но в на самом деле довольно близкое к действительности. Если контроллер не сильно загружен и наблюдаются очевидные паузы в работе дисковой подсистемы, то ему нет нужды хранить данные на запись в кэше.
Включил кэш на запись, и вот какая картина получилась. Непонятно почему упала производительность на чтение. Сервер правда работает, может пользователи влияют. Хотя не настолько же.
Tue Apr 13 12:08:43 2004
Write statistics for volume SYS:
Writing 5120 * 1KB chunks: 639KB/sec
Writing 1280 * 4KB chunks: 4413KB/sec
Writing 640 * 8KB chunks: 5818KB/sec
Writing 320 * 16KB chunks: 10239KB/sec
Writing 320 * 32KB chunks: 13298KB/sec
Writing 160 * 64KB chunks: 17066KB/sec
Writing 40 * 256KB chunks: 26256KB/sec
Writing 10 * 1024KB chunks: 26256KB/sec
Writing 10 * 5120KB chunks: 21787KB/sec
Writing 10 * 10240KB chunks: 16814KB/sec
Tue Apr 13 12:08:43 2004
Read statistics for volume SYS:
Reading 5120 * 1KB chunks: 1984KB/sec
Reading 1280 * 4KB chunks: 7111KB/sec
Reading 640 * 8KB chunks: 11636KB/sec
Reading 320 * 16KB chunks: 15515KB/sec
Reading 320 * 32KB chunks: 18618KB/sec
Reading 160 * 64KB chunks: 20479KB/sec
Reading 40 * 256KB chunks: 20479KB/sec
Reading 10 * 1024KB chunks: 23272KB/sec
Reading 10 * 5120KB chunks: 25221KB/sec
Reading 10 * 10240KB chunks: 27089KB/sec
Tue Apr 13 12:08:53 2004
[IO_Test.nlm] IO_Test ended properly
Tue Apr 13 12:08:43 2004
Write statistics for volume SYS:
Writing 5120 * 1KB chunks: 639KB/sec
Writing 1280 * 4KB chunks: 4413KB/sec
Writing 640 * 8KB chunks: 5818KB/sec
Writing 320 * 16KB chunks: 10239KB/sec
Writing 320 * 32KB chunks: 13298KB/sec
Writing 160 * 64KB chunks: 17066KB/sec
Writing 40 * 256KB chunks: 26256KB/sec
Writing 10 * 1024KB chunks: 26256KB/sec
Writing 10 * 5120KB chunks: 21787KB/sec
Writing 10 * 10240KB chunks: 16814KB/sec
Tue Apr 13 12:08:43 2004
Read statistics for volume SYS:
Reading 5120 * 1KB chunks: 1984KB/sec
Reading 1280 * 4KB chunks: 7111KB/sec
Reading 640 * 8KB chunks: 11636KB/sec
Reading 320 * 16KB chunks: 15515KB/sec
Reading 320 * 32KB chunks: 18618KB/sec
Reading 160 * 64KB chunks: 20479KB/sec
Reading 40 * 256KB chunks: 20479KB/sec
Reading 10 * 1024KB chunks: 23272KB/sec
Reading 10 * 5120KB chunks: 25221KB/sec
Reading 10 * 10240KB chunks: 27089KB/sec
Tue Apr 13 12:08:53 2004
[IO_Test.nlm] IO_Test ended properly
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 0 гостей